Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi Gionatan, On Thu, Jul 27, 2017 at 12:14 AM, Gionatan Danti <g.danti at assyoma.it> wrote: > Hi all, > I have a possibly naive question about a dual primary setup involving LVM > devices on top of DRBD. > > The main question is: using cLVM or native LVM locking, can I safely use a > LV block device on the first node, *close it*, and reopen it on the second > one? No filesystem is involved and no host is expected to concurrently use > the same LV. > > Scenario: two CentOS 7 + DRBD 8.4 nodes with LVs on top of DRBD on top of > a physical RAID array. Basically, DRBD replicate anything written to the > specific hardware array. > > Goal: having a redundant virtual machine setup, where vms can be live > migrated between the two hosts. > > Current setup: I currently run a single-primary, dual nodes setup, where > the second host has no access at all to any LV. This setup worked very well > in the past years, but it forbid using live migration (the secondary host > has no access to the LV-based vdisk attached to the vms, so it is > impossible to live migrate the running vms). > > I thought to use a dual-primary setup to have the LVs available on *both* > nodes, using a lock manager to arbitrate access to them. > > How do you see such a solution? It is workable? Or would you recommend to > use a clustered filesystem on top of the dual-primary DRBD device? > > I would recommend going through this lengthy post http://lists.linbit.com/pipermail/drbd-user/2011-January/015236.html covering all pros and cons of several possible scenarios. The easiest scenario for dual-primary DRBD would be a DRBD device per VM, so something like this RAID -> PV -> VG -> LV -> DRBD -> VM, where you don't even need LVM locking (since that layer is not even exposed to the user) and is great for dual-primary KVM clusters. You get live migration and also keep the resizing functionality too since you can grow the underlying LV and then the DRBD it self to increase the VM disk size lets say. The VM needs to be started on one node only of course so you (or your software) need to make sure this is always the case. One huge drawback of this approach though is the large number of DRBD device to maintain in case of hundreds of VM's! Although since you have already committed to different approach this might not be possible at this point. Note: In this case though you don't even need dual primary since the DRBD for each VM can be independently promoted to primary on any node at any time. In case of single DRBD it is all-or-nothing so no possibility of migrating individual VMs. Now adding LV on top of DRBD is bit more complicated. I guess your current setup is something like this? LV1 -> VM1 RAID -> DRBD -> PV -> VG -> LV2 -> VM2 LV3 -> VM3 ... In this case when DRBD is in dual-primary the DLM/cLVM setup is imperative so the LVMs know who has the write access. But then on VM migration "something" needs to shutdown the VM on Node1 to release the LVM lock and start the VM on Node2. Same as above, as long as each VM is running on *only one* node you should be fine, the moment you start it on both you will probably corrupt your VM. Software like Proxmox should be able to help you on both points. Which brings me to an important question I should have asked at the very beginning actually: what do you use to manage the cluster?? (if anything) Regards, Igor -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20170727/d989634d/attachment.htm>