[PVE-User] Setting up DRBD for OpenVZ containers

[Daniel Pittman]

Patryk Benderz <Patryk.Benderz at esp.pl> writes:
> [cut]
>> Apologies if this has been covered recently/elsewhere, but I’ve had a
>> good search on the web and can’t find the details I’m looking for – so
>> any advice/details would be much appreciated.
> [cut]
>
> I am in similar situation. in 2009-09 I wanted to set up almost identical
> environment (OpenVZ on A/A DRBD). Below you can find Martin's answer for my
> 1st questions, which is similar to yours:
> http://pve.proxmox.com/pipermail/pve-user/2009-September/000847.html
>
> Unluckily for us, looks like this setup isn't going to born any time
> soon. :(

Sad but true.  In the meantime, I can offer a possible work-around for you,
which is that we hit the same issue and resolved it as follows:

1. Configure two PVE machines with DRBD, which are capable of running KVM
   virtual machines, using the 2.6.32 kernel option.

2. Configure one KVM on each physical machine, using all the RAM and with one
   "virtual" CPU per physical CPU.  Use virtio net and block to an LVM LV on
   the DRBD disk; set 'cache=none' in the KVM block device configuration.

3. Install PVE in the KVM virtual machines.  This can't do KVM, but it can do
   OpenVZ virtualization inside the container.

4. Run our OpenVZ systems inside the KVM PVE instance.

This gives us the working fail-over, at a fairly crude level, which is all we
needed: both systems can be active when all is well, and can bring up a single
system with both "virtual" PVE instances if we have a hardware failure.

If you wanted finer grained load-balancing you could obviously run multiple
KVM-PVE instances on each machine, and switch those between the nodes to
achieve appropriate load.


A word of caution: this is so far in "beta" stage, in that we have production
systems running successfully, but nothing that would stop the business if it
fell over.  We hope to have enough testing data in the next week or two to
class the machines as production-ready however.

In the longer term we may approach this, together with AoE or iSCSI storage,
as a viable approach to having more than two machines in a cluster with
balancing across them.

        Daniel
-- 
✣ Daniel Pittman            ✉ daniel at rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons