[DRBD-user] Recommendations for cold standby server

Andrew McGill list2008 at lunch.za.net
Tue Aug 26 22:09:06 CEST 2008

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

I'm about to set up a luke-warm standby server - with DRBD and/or another form 
of synchronisation.  The server will be running a general-purpose web hosting 
environment (LAMP + mail) for up to 100 domains.  A second server will be at 
another data centre, ready to take over, should the first fail - either in 
terms of network infrastructure or hardware.  The switchover will be done 
manually with a script and a DNS update by a real person.

The bandwidth is relatively expensive, so I will try to keep the synchronised 
data to a minimum (i.e. no syncing /tmp, /var/run ...).  The data would be a 
partition of around 100Gb.  Once the system is in place, we won't be able to 
economically do a full sync - ever.   (For the price of the bandwidth of a 
full sync we could hire two drivers for a month to ferry the disk between 
data centres).  I am considering running DRBD over openvpn with lzo 

Is DRBD an overkill for this application?  Will it work?  Will it work well?

I would be grateful to hear recommendations on best practices for this kind of 
arrangement.  Some things I've wondered about ...

 - How it worked for you ...

 - Whether splitting the volume into sub-volumes would be sensible 

 - The best filesystem (ext3?)

 - Which files would be better rsync'd (or that the entire job should be)

 - Excluding database files from drbd, and using mysql active-active 
replication for those

 - Whether temporarily turning off synchronisation (drbdadm disconnect all) 
would be a good idea when the load is high, since that would somewhat reduce 

 - Tuning for better bandwidth usage for the common case of disconnects due to 
network interuption.... while not killing the disk to too-regularly update 
its (internal) meta-data.

I also wondered if it would be feasable to take lvm snapshots on the drbd 
secondary ...

More information about the drbd-user mailing list