Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Thank you for your great exhaustive answer! At the moment I'm testing some HA solutions. We have many different critical applications in company and only safety is backup and Raids. I dream about fully replicated operating system - if whole server crashes, then another is working in few second break. Solution which doesn't depend on application (I know that it is difficult but finding solution for every application is more difficult ;) ). At the moment the best looks visualization + DRBD for that purpose - if I am right, I can use /dev/drbd as drive for virtual machine and if primary host crashes, then start secondary virtual machine with its synchronized drive... Lars Ellenberg wrote: > > On Thu, May 31, 2012 at 07:19:28AM -0700, agag wrote: >> >> Did you had also database in /ha directory? >> For WWW servers usually better looks some GFS + loadbalancing sollution >> in >> my opinion. Loadbalancer check if servers are available and split load. >> I'm >> starting to loos ideas what DRBD can give me. I looked at the beginning >> very >> good but now I can't find big profits. The biggest problem is that data >> is >> not visible in both hosts without remount. >> >> Virtua machine - interesting solution... bit virtual machine is usualy >> one >> big file. Isn't that a problem? Isn't synchronizing open file problem? > > Typical Linux IO stack: > appplication > filesystem > page cache > block device > > IO stack with DRBD: > > appplication > filesystem > page cache > DRBD ---- REPLICATION LINK ----- DRBD > block device block device on peer node > > > DRBD does not know or care for files, or wether they are open or what > happens to them. > It only knows and cares for the blocks which are submitted. > > What do you need to be able to > have some arbitrary service highly available? > > You need the *data* that service operates on available > in more than one place. > > If you have that data in some central location, > SAN/NAS or shared SCSI or similar, > you can access it from several cluster nodes, > so no cluster node is a single point of failure (SPOF). > With redundand networking you can eliminate most SPOFs. > > Still, the centralized data location itself remains a SPOF. > > DRBD live-replicates your data online to an other node. > No SPOF at all, all standard off-the-shelf hardware, > performance typically close to what you get with the direct attached > storage (DAS), especially READ performance is that of your local IO > subsystem. > > > DRBD enables you to do failover clustering for ha (high-availability), > without the need for a (typically costly) SAN, while at the same time > eliminating that last SPOF (the SAN box itself), and giving you the > oportunity to put your cluster nodes in two different protection areas > or buildings, or even several kilometers appart, > for desaster recovery purposes. > > > You can combine it with its asyncrhonous mode to even replicate to > an other continent, just in case, or so your colleagues 10 time zones > further have local latencies during their working hours, then migrate > back once you start working on this side of the world again. > > > DRBD + Pacemaker + Linux iSCSI target and/or NFS server > can *replace* a SAN box. This is commonly used to build a highly > resilient highly available replication enabled iSCSI SAN/NAS solution, > all with open source software and standard COTS hardware. > > Or use it as virtualization host cluster. > Or for databases. > Or any other service you want HA. > > It gives you a lot of flexibility. > > > DRBD does not do everything for you, though. > DRBD does not do IP address takeover, service monitoring, > service restarting, or load balancing. > > It also can not make your not-even-crash-safe application > suddenly work more reliable, or magically make your normal > single-host file system into a cluster file system, > or let you run multiple instances of some database or service > with the same data on two nodes, where that database or service > can not even do the same with two instances on the same dataset on a > single node, without replication or clustering involved. > > In fact it does only data replication. Just that. > It is a replicated block device. > > You need to combine it with a cluster manager (e.g. Pacemaker), > to actually pull off the service monitoring, IP address takeover, > service restarts and other things you need fo the automatic failovers. > > Load balancers do work well with Pacemaker, > and don't care if their backends sit on DRBD or not. > > > DRBD is certainly not the best tool for everything ;-) > > Rather than judging tools with limited understanding of their > purpose, over mislead expectations or general misconceptions, > > maybe you should first describe what you think you want, > from a birds perspective, > and we then can zoom in, > and suggest the right tools for the job as we go? > > > -- > : Lars Ellenberg > : LINBIT | Your Way to High Availability > : DRBD/HA support and consulting http://www.linbit.com > > DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. > __ > please don't Cc me, but send to list -- I'm subscribed > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user > > -- View this message in context: http://old.nabble.com/see-replicated-data-tp33895972p33941134.html Sent from the DRBD - User mailing list archive at Nabble.com.