Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
We just went through this exercise and went with AOE instead of iSCSI because we found the current crop of iSCSI target and initiators to be lacking in terms selectively bringing a LUN 'up' and 'down'. Specifically the iSCSI target implementations do not release the backstoring device when the LUN is marked as offline. Thus preventing DRBD from going secondary. (I posted a patch to the tgtd mailing list to add the functionality, but it was rejected). Do you plan on having the VM guests access the iSCSI server directly or use iSCSI to connect the LUNs to the VM host and then the host hands them to the guests as directly connected block devices? We choose the latter to try and keep the guests as simple as possible. On Fri, Sep 23, 2011 at 02:47:33PM +0200, Maciej Gałkiewicz wrote: > Hello, > > I would like to implement DRBD with LVM volumes exported by iSCSI to > virtual machines. Here (http://dl.dropbox.com/u/5820195/storage.svg) > are two stacks which I am considering. I have tens of virtual > machines. Each of them mounts 5GB partition(s) (the size may change) > accessible through iSCSI. > > In the first case (#1) I have one big drbd volume which stores LVM > volumes for instances. When primary node crashes all I have to do is > to promote the other one. The problem is that in case of maintenance > when I need to shutdown primary node I have to migrate all LVM volumes > at once. All VMs do not have access to remote partition. > > The second stack (#2) is more flexible. I can migrate one volume > without interrupting the rest. I am concerned about network traffic > during initial drbd synchronization. Each resource will have about 5GB > so when I add a new one the synchronization generates high traffic. Is > there any way to avoid it? What about resizing LVM volume? How much > data drbd will transfer assuming that the volume size will be +/- 1GB? > > Could you please advice me which implementation would be better and > point any expected inconveniences? > > -- > Regards > Maciej Galkiewicz > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user -- James R. Leu Software Architect INOC 608.204.0203 608.663.4555 fax jleu at inoc.com www.inoc.com *** DELIVERING UPTIME *** -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20110923/8e79a01a/attachment.pgp>