m.watts at eris
Nov 4, 2009, 2:15 AM
Post #3 of 3
(175 views)
Permalink
|
>
> 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
|
signature.asc
