Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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