On Mon, 2007-01-08 at 17:14 -0200, Marco Sinhoreli wrote:
I'm going to do a lot of [snips] here ..
> Tim Post wrote:
> > On Mon, 2007-01-08 at 12:18 -0200, Marco Sinhoreli wrote:
> >
> >> Hello everybody,
> >>
[snip]
> >> P = primary | S = Secondary
> >> ------------------------------------
> >> Host A
> >> ------------------------------------
> >> vm1 vm2 vm3 vm4 vm5 vm6
> >> | | | | | |
> >> drbd1 drbd2 drbd3 drbd4 drbd5 drbd6
> >> P S P S P S
> >> ------------------------------------
> >> | | | | | |
> >> | | NETWORK | |
> >> | | | | | |
> >> ------------------------------------
> >> S P S P S P
> >> drbd1 drbd2 drbd3 drbd4 drbd5 drbd6
> >> | | | | | |
> >> vm1 vm2 vm3 vm4 vm5 vm6
> >> ------------------------------------
> >> Host B
> >> ------------------------------------
[snip]
> No, not is correct. In etch of the 6 componets (vm{1-6}) I have one drbd
> connection for mirroring between 2 Logicals Volume LVM. Example: vm1 use
> the drbd1 that is attached in /dev/vg/vm1-disk in each hosts. The LV
> /dev/vg/vm1-disk exist in each host and has the same size. The drbd
> block is active only in host A or B. Supposed that the vm1 is actived at
> host A. If host A was crashed, the heartbeat at host B detect it and
> active the drbd1 and boot the vm1.
>
I wasn't quite clear enough, my apologies. I did understand you
correctly (and the diagram) however :)
I'm not sure what your using for each of the two physical hosts, however
I think you could get better availability using a NAS. Your design is
great, straight forward .. and would probably work very well. I'm one
who likes to have as few moving parts as possible, so that its easy for
any of the admins other than myself to support the setup and less things
that can go wrong.
> Other possibility is scheduler shutdown, in this case the host A stop
> the services and the heartbeat service do a live-migration of the vm1
> and desactive the drbd1. At host B, the heartbeat service receive the
> call for active the resource vm1 and active the drbd1 and verifies if
> vm1 is active, in afirmative case, finishes the script, in negative
> case, call the boot of the vm1.
Yes, its (as I described it over-simply) very much like a single pole
double throw switch.
> Other alternative is to use drbd8. It allows the drbd work with block
> devices active in 2 hosts as in the NAS. But drbd8 is an alfa version.
It would be neat if you had some time, and could at least play with it..
would be useful data to contribute to the Xen wiki as well.
[snip]
> You have done a similar configuration of HA and Xen using DRBD and
> heartbeat?
Yes. I found that it worked well but became an administrative nightmare
as things scaled. We ended up going with a few NAS boxes (dual opteron
246's with Areca RAID controllers) and using AoE, tossing in ocfs2 for
the rare occasion that we needed a shared FS between the guests.
This proved to be much more versatile and easier to scale. The older
system had a single point of failure, me. The problem was I was the only
one who knew exactly how it was setup, and had to be found in the event
of any problem and rush to a place to get on line to fix things. Moving
over to the NAS, I have not been as married to the network as I was
before.
You can still use heartbeat, everything stays (basically) the same, with
the exception of centralized storage. We ended up moving away from
heartbeat and making something of our own, a bit more custom tailored to
what we needed.. built with Xen in mind.
Again, your design is perfectly fine *as is* and will work well. I'm
just sharing my experiences with something similar. Most people I know
who have used Xen for HA setups have ended up crafting their own unique
scripts and applications to simplify things, using the RH cluster suite
and similar as a starting point.
Best,
--Tim
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home