DRBD is great.
The good things:
- It does a magnificent job at replicating data
- DRBD has in a couple of cases prevented disaster, where it has discovered that the volume was already mounted on the other node, which the raw volumes we get from a SAN are unable to tell us.
- Heartbeat already has great support for DRBD.
The challenges:
- Remember to monitor it properly, so you discover split brains when they happen - and can deal with it.
- DRBD can't be mounted on both servers without a cluster-enabled filesystem on top - I don't have any experience with that part.
- It is easy to "DOS" the servers by configuring DRBD to use all the available bandwidth for syncing disks. Just configure for lower throughput, and you're OK.
For mounting "the same" filesystem on several nodes, we keep going back to NFS, even though we keep testing various solutions for it. A setup I have no problem with having in production is NFS on top of EXT4 on top of DRBD. I wouldn't dare to do this with the database filesystems, but it's OK for the wwwroot.
I had the same question 2 months ago. After sending in a failed disk, the replacement disk failed in my NAS after 3 days.
So I decided I would now test the new replacement before putting it in production.
I do not test every new disk I buy, only on 'refurbished' disks, which I do not completely trust.
If you decide you want to test these disks I would recommend running a badblocks scan and an extended SMART test on the brand new hard disk.
On a 2TB disk this takes up to 48 hours,
The badblock command writes the disk full with a pattern, then reads the blocks again to see if the pattern is actually there, and will repeat this with 4 different patterns.
This command will probably not actually show up any bad blocks on a new disk, since
disks reallocate bad blocks these days.
So before and after this I ran a smart test, and check the reallocated and current pending sector count.
If any of these have gone up, your disk has some bad blocks already and so might prove untrustworthy.
After this I run an extended SMART test again.
You might want to install smartctl or smartmontools first.
Warning, the badblocks -w flag will overwrite all data on your disk,
if you just want to do a read check, without overwriting the disk, use badblocks -vs /dev/sdX
sudo smartctl -a /dev/sdX
# record these numbers
sudo badblocks -wvs /dev/sdX
# let it run for 48 hours
sudo smartctl -a /dev/sdX
# compare numbers
sudo smartctl -t long /dev/sdX
# this might take another hour or 2, check results periodically with
sudo smartctl -a /dev/sdX
If after this your smart values seem ok I would trust the disk.
To know what each smart value means, you can start looking here
http://en.wikipedia.org/wiki/Self-Monitoring,_Analysis,_and_Reporting_Technology
Best Answer
How are you given access to the SAN? Are they just creating the volume on the SAN then giving you the target name etc to add to the iscsi connectors on Windows? You shouldn't really have any issues using a SAN between multiple servers as long as you setup how it's being accessed correctly.
What are you trying to do with shared storage between web servers? You may want to look into setting up a proxy which that web servers can use and then have the proxy use the shared storage.