RE: ZODB/ZSS High Availablity, was: RE: [Zope] Zope Myths?
I can't remember who all is doing it, but I think network-replicated block devices are pretty popular for this kind of thing; I distinctly remember someone on a mailing list mentioning they were doing this with Zope and/or ZEO (might be worth a search of archives, perhaps on ZODB-dev?). I think that in some circles, DRBD is preferred to NBD, but I don't claim to be an expert on that (check out links on the Linux-HA.org site, perhaps). The downside to doing this is that you can't keep two distinct copies of the storage (the last good known copy, and the last replicated copy), since you are replicating at a much lower level. In this sense, you will need to rely on consistency checks alone to get a partially messed-up storage working on the failure of the primary node, and startup of the secondary node resources and IP takeover. Sean -----Original Message----- From: Oliver Bleutgen [mailto:myzope@gmx.net] Sent: Friday, September 13, 2002 1:00 AM To: sean.upton@uniontrib.com Cc: pw_lists@slinkp.com; zope@zope.org Subject: Re: ZODB/ZSS High Availablity, was: RE: [Zope] Zope Myths? sean.upton@uniontrib.com wrote:
Thought about this using Intermezzo - basically the same idea. I think the problem is that these are on-demand replication mechanisms that get the file when they need it instead of push-to-other-node-on-write sort of deals. I'm not posive about that. The other problem is how these filesystems handle changes to large files (like FileStorage).
There, might, in theory, be a way to integrate this with something like DirectoryStorage, but I think you would need to do some heavy scripting to get things to work just right (perhaps to the point that you might as well manually set up scripts to low-tech replicate files?).
Hmm, has someone taken a look a ndb (network block device) for linux? This might be a cheap (low tech) solution for doing "push-to-other-node-on-write". I'm asking, because I have not tried it, but always wanted to. http://nbd.sourceforge.net/ http://www.it.uc3m.es/~ptb/nbd/ """The intended use is for RAID over the net. You can make an NBD device part of a RAID mirror in order to get real time mirroring to a distant (and safe!) backup. To make it clear: start up an NBD connection to a distant ENBD server, and use its local device (probably /dev/nda) where you would normally use a local partition in a RAID setup. The original kernel device has been hardened in many ways: The ENBD uses block-journaled multichannel communications; there is internal failover and automatic balancing between the channels; the client and server daemons restart, authenticate and reconnect after dying or loss of contact; the code can be compiled to take the networking transparantly over SSL channels (see the Makefile for the compilation options). """ cheers, oliver
On Fri, 2002-09-13 at 08:30, sean.upton@uniontrib.com wrote:
I can't remember who all is doing it, but I think network-replicated block devices are pretty popular for this kind of thing; I distinctly remember someone on a mailing list mentioning they were doing this with Zope and/or ZEO (might be worth a search of archives, perhaps on ZODB-dev?). I think that in some circles, DRBD is preferred to NBD, but I don't claim to be an expert on that (check out links on the Linux-HA.org site, perhaps).
The downside to doing this is that you can't keep two distinct copies of the storage (the last good known copy, and the last replicated copy), since you are replicating at a much lower level. In this sense, you will need to rely on consistency checks alone to get a partially messed-up storage working on the failure of the primary node, and startup of the secondary node resources and IP takeover.
Well, you can if you periodically rsync to another spindle locally :-) Seriously, I think you're talking apples and oranges of fault-tolerance design. An NBD tool (or for that matter a NAS mount if it weren't for locking Data.fs) is a proper solution if you want to spread load across many boxes which are all simultaneously capable of doing the same things. Classically this is the model used for a web farm. As you point out, it's really only a good idea if the data is relatively static because consistency checks, ACID-compliance, and access locking issues get ugly when the data is being modified all the time. Where that's the case, you're much more likely to see an active/passive pair that may use the same storage for speedy recovery, but utilize log-shipping and data check-pointing snap-shots to facilitate easy rollbacks. That's why enterprise solutions don't put the database, application server, and web server in the same box :-) On a side note, I can't help but wonder what will happen to performance when one write of a RAID-1 goes to a local UW/SCSI-3 disk and the other one goes traipsing across three thousand miles of network... Jack <snip> -- Jack Coates Monkeynoodle: A Scientific Venture...
participants (2)
-
Jack Coates -
sean.upton＠uniontrib.com