Hi Jason,
> > A better approach is to use clustering - for example with DRBD and
> > Heartbeat. While a "do it yourself" approach is of course possible,
> > there is also a commercial software available which does this out of the
> > box.
>
> Happy to pay but I'm not convinced such a solution would work with the
> servers geographically separate and connected via slowish Internet only.
> What do you think?
That depends on the quality of the connection and this can ideed be a limiting
factor for a couple of reasons. That's true.
Ideally the suggested way for clustering two nodes is a direct gigabit
crossover connection between the two nodes. That way you get the maximum
throughput without any interference (i.e.: broadcasts from random network
devices or network traffic from other devices). 100MBit FastEthernet has a
maximum (theoretical) bandwidth of 12.5MB/s. With gigabit Ethernet you'd
(theoretically) get ten times that much, but usually the speed of the
harddisks is then the limiting factor. With SATA disks it commonly tops out
at 50MB/s.
But yes, it also works over a regular TCP/IP connection that's shared with
other devices and routed half around the globe via the Internet. But then
it's of course slower and the actual speed depends on the quality of the
network connection. If your servers just share a 10MBit line with a few
dozend other servers which happen to be on the same switch or router, then I
wouldn't suggest to cluster through DRBD to a remote location. A complete
sync would simply take ages and even the periodic but steady updates between
both nodes would have a hard time catching up. If you're on a 100MBit line
and both ISP's aren't that far apart (hop wise), then it could be worth
taking it into consideration.
It should also be kept in mind that clustering through DRBD can generate an
tremendous amount of traffic between the different cluster nodes as they're
constantly synchronizing the data. If both nodes are in different datacenters
with different ISPs and both charge you for the traffic by the the megabyte
or gigabyte, then you could be in for two quite steep traffic bills at the
end of each month. That of course also depends on how much data changes on a
daily basis and needs to be synchronized.
Like I said in my initial post: There are several ways to achieve one form or
another of redundancy by maintaining geographical diversity of assets. Not
all of them come cheap (and I'm not just talking costs for software).
Choosing the right ISPs and the right gear can also be an important factor -
as well as how you set up the assets that need to be clustered or mirrored.
The closer you want to get to zero downtime the more expensive it'll get. DRBD
can get you quite close to zero downtime, but if it's the right tool to make
your ends meet is something that I can't say.
--
With best regards,
Michael Stauber