Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
> > Idea was to replace our current 2 Server setups which use mysql > replication by something > that cant break, Also the need to deploy code to only one machine > would have been nice. > > Primary/Secondary DRBD using heartbeat to mount an EXT3 file > system and > manage a single instance of MySQL, is a very reliable way of > achieving a > redundant database server, and neither KVM or GFS is required. > > we have a couple of Primary/Secondary setups where load is not heavy, > this method is well establihed here. > > Of course, running KVM guests and storing their disk images on > GFS > (Primary/Primary DRBD) is a valid way forward but its not > quite clear > what you're actually aiming for. > > > > Reading and testing some more brought me to thinking my idea of > storing a VM inside a GFS wont work, or are there option for the whole > OS > to handle with filelocks? > I have a 2node DRBD GFS setup where i am running a mysql server inside > the GFS, this seems to work fine, > I also tried editing files simultaniousliy on both nodes and got the > usual "file changed on disk" message while editing. > This lead me to thinking putting the whole root filesystem on such a > GFS share wouldnt work. > Reading this > http://www.mysqlperformanceblog.com/2008/04/28/mysql-replication-vs-drbd-battles/ helped a bit too, > someone there mentioned the google pathces for mysql, this would be a > way to go, maybe. Ok, how about this: 2-node OpenAIS + GFS cluster (RedHat Cluster Suite) with Pri/Pri DRBD as the backing-device for the GFS filesystem. Run KVM guests for your services with the disk image stored on the GFS filesystem. These KVM guests are managed by cluster.conf and get restarted on the second cluster node should the first one fail. You won't need to do anything special in MySQL since it will be running as a single stand-alone node, and the KVM guest will be using EXT3 internally; the redundancy comes from being able to restart that KVM guest on a different cluster member should it die for any reason. (This approach scales to many cluster nodes, if you have true shared-storage, like a SAN). Storing virtual machine disk images on GFS is valid and works, but I suspect (from personal experience with Xen disk images stored on local EXT3) that disk performance won't be great, simply due to the number of layers involved (DRBD->GFS->KVM->EXT3, not to mention LVM if its used). I've had much better performance (with Xen) directly using DRBD block devices as the backing-store for the VM disk image. Whatever you choose, I suspect DRBD will be the least of your troubles :) Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer, Managed Services Manpower www.QinetiQ.com QinetiQ - Delivering customer-focused solutions GPG Key: http://www.linux-corner.info/mwatts.gpg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20091104/78b6df16/attachment.pgp>