Mit ‘drbd’ Tagged einträge

drbd: storage live migration

Montag, August 1st, 2016

Um VMs zwischen HDD und SSD zu migrieren wäre ein „lvmove“ äquivalent ganz praktisch. Dies kann es aber nicht geben, da der Pfad zum lv dann auch angepasst werden muss. Um meine Master Slave Setup dennoch Live migrieren zu können, habe ich ein neues gleich großes lv erstellt, die Platte ausgehangen und die neue wie folgt eingegangen.

Zunächst habe ich geprüft ob ich Master oder Slave bin (ro:Secondary)

grep -A1 '^11:' /proc/drbd 
11: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
    ns:1176552 nr:236 dw:1176788 dr:233640 al:194 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Dann habe ich dem DRBD Verbund die Storage aus gehangen:

drbdadm detach drbdvm11
grep -A1 '^11:' /proc/drbd 
11: cs:Connected ro:Secondary/Primary ds:Diskless/UpToDate C r-----
    ns:1176552 nr:272 dw:1176824 dr:233640 al:194 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Dies DRBD Config Datei editiert und bei der localen node das neue lv auf der neuen vg eingetragen.

vim /etc/drbd.d/drbdvm11.res
disk       /dev/mapper/vg2-drbdvm11;

Danach muss das neue lv von DRBD initialisiert werden:

drbdadm create-md drbdvm11
initializing activity log
NOT initializing bitmap
Writing meta data...
New drbd meta data block successfully created.
success

Anschließend wird alles wieder gestartet und die Synchronisation begibt automatisch.

drbdadm attach drbdvm11
grep -A2 '^11:' /proc/drbd 
11: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r-----
    ns:0 nr:184320 dw:184320 dr:0 al:194 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:7155452
         [>...................] sync'ed:  9.4% (116080/127996)M
grep -A1 '^11:' /proc/drbd 
11: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
    ns:0 nr:7339804 dw:7339804 dr:0 al:194 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

drbd online resize

Sonntag, Januar 24th, 2016

Heute musst ich einer VM mehr Speicherplatz zuweisen. Da die VM auf einem DRBD Cluster lag bin ich folgendermaßen vorgegangen.

lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
vm1 vg1 -wi-ao--- 67,00g

1. auf beiden VM Host Systemen habe ich das LV vergrößert.

lvresize vg1/vm1 -L 135g

2. Anschließend habe ich auf dem Primary DRBD Konten das DRBD Online vergrößert.

drbdadm resize vm1

cat /proc/drbd
4: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r---a-
ns:86370276 nr:9144 dw:86259976 dr:3566560 al:274 bm:129 lo:2 pe:8 ua:8 ap:1 ep:1 wo:f oos:71188220
[>....................] sync'ed: 0.2% (69516/69628)Mfinish: 0:42:04 speed: 28,192 (28,192) K/sec

Schon während der Synchronisation stand der vergrößerte Platz in der VM zur Verfügung.

DRBD wait IO

Sonntag, August 16th, 2015

In einem KVM DRBD Setup hatte sich auf Dauer eine Menge wait I/O angesammelt.

waitio3

Zunächst habe ich herausgefunden, dass die einzelnen VMs sehr viel write barriers erzeugen. Dies konnte ich bei den VMs, bei denen ich root Zugang habe, mit der Option barrier=0 in der /etc/fstab einstellen.
Bei den VMs, bei denen ich keinen root Zugang habe, ging das leider nur auf der DRBD Schicht. Dazu habe ich in den /etc/drbd.d/.res folgende Einstellung hinzugefügt:

disk {
    disk-barrier no;
    disk-flushes no;
}

Quelle: drbd.linbit.com

Die hieraus resultierende bessere IO Permanenz für alle VMs entnimmt man den oben aufgeführten Zabbix Graph.