Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Fri, May 16, 2008 at 12:24:57PM +0200, Marco Prandini wrote: > Hello, I found this ML thread while preparing the same kind of > operation, I'd like to ask for a confirmation of what I think I learned, > since deviating from a recipe suggested by Lars Ellenberg makes me > uneasy :-) > > He said: > > if you just replace the disks, > > you need to create new drbd meta data, > > and you need to do a drbd full sync. > > > > depends on the actual setup whether > > * full sync of local disk, then incremental sync of drbd, > > * or just a full sync of drbd > > will be less efford. > > so, let's suppose that waiting for a full sync is not a problem (since I > can't sync the new local disk from the old any way. > > I'm planning to follow this procedure, that I already successfully > tested on a couple of virtual machines (steps marked with * are those I > have questions about): > > 1) failover the services on server A > 2) replace the disk on server B > 3*) restart drbd on server B, with the bigger local devices > 4) wait for A->B resync end > 5) transfer all the services on server B > 6) replace the disk on server A > 7*) restart drbd on server A, with the bigger local devices > 8) wait for B->A resync end > 9*) live grow the (etx3) filesystem on server B with resize2fs > > First question: step 3 causes a full resync, that's ok for me, but > obviously drbd still reports the original size (constrained by A's > disk), however I suppose that the internal metadata in the new B's disk > is correctly allocated at the end of the bigger local device? yes. during 2), you need to "drbdadm create-md" new meta data on the new hardware. with "internal", that is then located at the very end of the new (bigger) storage. during 6), you again need to "drbdadm create-md", on the other node. that again will be located to the very end of the new device, and again mark it as "just created, inconsistent, want-to-receive a full sync" > After step 7, as anticipated in the "Growing off-line" section of > http://www.drbd.org/users-guide/s-resizing.html > drbd automagically recognizes the new device size, and performs another > full sync. However, the guide refers to the case when "the backing block > devices on both nodes are grown while DRBD is inactive". What I did is > not exactly the same. Do you see any risk with this procedure? nope. it is just "different". > Would you suggest to "drbadm disconnect" server A before the step 9 , to > keep a copy of the data on server A's local disk in case there are > problems with resizing on server B? It certainly won't hurt to use it as a "snapshot node". It may even speed up the file-system resize process (because of reduced latency). it adds a possible "rollback" scenario 10a, which you should write down as well (answer yourself the "what if there are problems during resize") and it adds the reconnect and wait for resync again for the optimistic case 10b, after the file-system resize was successfull. -- : commercial DRBD/HA support and consulting: sales at linbit.com : : Lars Ellenberg Tel +43-1-8178292-0 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Vivenotgasse 48, A-1120 Vienna/Europe http://www.linbit.com : __ please use the "List-Reply" function of your email client.