Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2004-03-23 11:34:10 +0100 \ armin langhofer: > hi > > what i want > =========== > i'm looking for a solution that my pop boxes become high avalibility. > > therefore i dont want to depend on a single internet connection only. > the internet connection is a spof (single point of failure). if it fails > the net will become unreachable. > > i want to setup up several hosts spreadded on the internet. each of them > should be mostly available and serve the pop/imap boxes. Hm. You have to be carefull to get the locking right then... > what i (think to) need > ====================== > > so what i need for this is a kind of "network raid". Not exactly. You need a shared backing storage. > i found your project and could not figure out if it would be possible > to sync the data between two hosts IN EACH DIRECTION? Yes, though not in the way you mean it. > Many projects offering high avalibility only replicates in one direction > which is uninteressting for me due to the service on the backup server > should be able to change the data. The changed data should be > syncronized to the primary server back again as it comes up. > > Could you please tell me if DRDB offers a "TWO-WAY" synchronisation? > Is it restricted to one-way only? Well. Please read on. Strictly speaking, each DRBD *pair* of devices consists of exactly *two* boxes, not "several hosts spreaded on the internet". Each of the two peers has its own stable storage attached. Each of the peers can have several DRBDs, each of which can have a different peer. At any given time, only *one* of the peers is allowed to access the data. Actually the limiting factor is not DRBD, but the typical file systems. We expect to have GFS working on DRBD in maybe summer 2005. So as long as you do the "typical" Linux-HA setup, you should be fine: You have one of the peers be "active" on (one of) its DRBD, and serving client requests. The other is "non-active", mirroring the write access on its local backing storage. If the "active" one goes down, or can no longer be reached , the up to now "non-active" becomes active (this is what the clustermanager, typically heartbeat, is for), mounts the data, starts the services, and now can answer client requests.  *CAUTION* you should have redundant communication paths, to be able to distinguish these cases, and you should read about fencing (STONITH) and some other HA concepts on http://linuxha.trick.ca and http://www.linux-ha.org When the former active, now crashed, node comes back, it will look for its peer, find it, connect, exchange some metadata, sees the other node took over service, remain "non-active" and become sync target, mirroring the changes that happend on the other node. "Active" and "Passive", or "Primary" and "Secondary" are NOT hosts, but roles, that each node can take on. During normal operation, using two or more DRBDs, you can have one node serve one set of data, the other node serve an other set of data. Then each one is the "backup server" for the other one, but each one is "active" in a way. If you find some highly available shared backing storage allowing concurrent access by several servers from all over the internet, let us know, whether it is comercial or a free project. I don't know of such a thing. Lars Ellenberg