Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 2009-08-19 23:22, Jürgen Scholz wrote: > Hello! > >> I was thinking I could make sure once system has all the volumes on one >> disk in secondary, detach DRBD and remove the Disks. Put in new disks, >> create a new logical volume group recreate logical volumes of the same >> size and let DRBD synch back to the new disks. > What you're suggesting would take a full resync. I suggest: > 1. Let one machine be the secondary for all drbd resources. See that > it stays this way by disabling your CRM. Work on this machine. > 2. Put in your new disks. > 3. Make a raw copy of your old disk to the new one with dd. > 4. Remove the old disk. > 5. Extend your LVM partition. > 6. pvextend your PV. > 7. lvextend your LVs. (If you're using internal meta-data you'll have > to move that first. Perhaps somebody else can help determining the > necessary parameters for dd. I use externat metadata and never had > to deal with this.) > 8. Do: drbdadm adjust all > > 9. Do the same for the other machine. > > Drbd will then notice that the underlying blockdevice grew and a partial > sync will start. > I've done this a few times. It always worked. I hope I did not forget > anything. Please double check and test in a lab first! If you have additional slots available in those boxes, then the approach can be greatly simplified. - Pop in new disks - Initialize new disks as LVM PV (pvcreate) - Add PV to existing volume group (vgextend) - Move physical extents from old PV to new PV (pvmove) - Remove old PV from group (vgreduce) - (Optional) wipe PV signature from old disks (pvremove) - Pop out old disks No need to fiddle with DRBD or Pacemaker at all. The only thing you might want to do is either move resources off the machine while you're doing your pvmove, or put the node in standby mode altogether during that time, as you may be suffering an I/O performance hit as the system is busy shuffling data. > @LINBIT: I've always wondered with how little consideration internal > metadata is recommended for new systems. I've read here for quite a while > and it seems many people run into problems with internal metadata which > wouldn't exist with external md. > Addistionaly an external meta-data disk can be moved to another spindle > for performance reasons. This doesn't work with internal, or does it? As this idea is repeatedly being regurgitated here for apparently no reason, I've created a blog post about it. You can get it from Planet HA (http://www.planet-ha.org/#Internal+metadata%2C+and+why+we+recommend+it). > Maybe you could think about suggesting external meta-data for all setups, > where the creation of a separate partition/LV is no problem. > - Even if you don't agree with me i would like to hear about why internal > is recommended. Read my blog. :) Cheers, Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20090820/d4551c78/attachment.pgp>