[DRBD-user] DRBD with KVM for live migrations

Trey Dockendorf treydock at gmail.com
Sun Oct 30 21:18:19 CET 2011

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


I do need live migration but not as a failover.  So the migration will be
manual and not automatic.  In that case I would at some point have to run
in primary/primary.  Is the cluster fs only for shared storage
configurations?  Also what ensures that the VMs disk is only being accesses
by one hypervisor node at a time?  Would libvirt or drbd controll/ensurs
that or is it up to me?  Thats my main concern once I know this is feasible
and the best route.

Thanks
- Trey
On Oct 30, 2011 2:41 PM, "Bart Coninckx" <bart.coninckx at telenet.be> wrote:

> On 10/30/11 20:34, Trey Dockendorf wrote:
>
>>
>>
>>    Hi,
>>
>>    a cluster software like Pacemaker could serve your purpose very
>>    well. Do incorporate STONITH though, as you will need dual primary
>> DRBD.
>>    Mind you Pacemaker is NOT easy, requires a lot of study and reading.
>>
>>    Share image files could be done with OCFS2 for example (or any
>>    clustering file system). You then need to create a Pacemaker
>>    resource handling this. Personally I never used OCFS2, but there are
>>    lots of eaxmples around.
>>
>>    HTH,
>>
>>    B.
>>
>> Looking at the man page for STONITH I'm not sure I understand how to
>> incorporate that into this particular situation.  When I put DRBD in
>> dual primary that will be only for the purpose of live migration, but I
>> don't really plan to use live migrations at first for failover.  My
>> initial purpose is for maintenance, to allow me to reboot one node
>> (after kernel update) and move all the VMs to the other node.  Once I've
>> got all that working smoothly then I'd move to having it serve a
>> failover function.
>>
>
> If you don't need live migration, you can safely forget about dual
> primary. It is actually even better since it is (or rather can be) a can or
> worms.
>
> No reason to go for OCFS2 either, unless you want shared storage for your
> config files (though NFS might serve that purpose too).
> LVM with a regular file system is fine, very good for backup.
>
> But do keep in mind that a master/slave system (or primary/secondary DRBD)
> will in no way allow you to live migrate. You can however always add it
> later, though converting from ext4 to OCFS2 probably will require backup
> and restore.
>
>  Would OCFS2 be used in conjunction with DRBD?  From a few articles I've
>> found, I thought that what could be done is create a LVM that stores all
>> the qcow2 images (part of my current deployment already) named
>> lv_vmstore.  Since I'm running CentOS 6 I've been formatting that ext4.
>>  Would I not then use DRBD to replicate lv_vmstore across both nodes?
>>
>> One catch to all this I think I forgot to include in my initial email is
>> I have no shared storage.  I only have 2 physical hosts with
>> approximately 1TB isolated for lv_vmstore.  Someday once budgets allow I
>> may have a SAN, but for now I am trying to facilitate live migration
>> without one.
>>
>
> DRBD is a technology that would allow you to be without a SAN.
> But do you or don't you need live migration (as you now mention you do)?
>
>  Thanks
>> - Trey
>>
>
> B.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20111030/4bbea63b/attachment.htm>


More information about the drbd-user mailing list