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 [1],
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.
[1] *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