Mit ‘lvm2’ Tagged einträge

Vergrößern eine Partition mit LVM

Montag, November 19th, 2018

Leider kommt es bei VMs immer wieder vor, dass die Festplatte im laufenden Betrieb vergrößert werden muss. Im folgenden Beispiel habe ich eine LVM Partition im laufenden Betrieb vergrößert. Bitte achtet darauf, dass ihr Backups von euren Systemen habt.

Zunächst habe ich die Partition vergrößern müssen:

fdisk /dev/vda

Welcome to fdisk (util-linux 2.29.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): p
Disk /dev/vda: 135 GiB, 144950685696 bytes, 283106808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xec02ef62

Device Boot Start End Sectors Size Id Type
/dev/vda1 * 2048 585727 583680 285M 83 Linux
/dev/vda2 585728 33552383 32966656 15.7G 8e Linux LVM

Dafür habe ich die Partien gelöscht:

Command (m for help): d
Partition number (1,2, default 2): 2

Partition 2 has been deleted.

Anschließend habe ich eine neue Partition angelegt:
Command (m for help): n
Partition type
p primary (1 primary, 0 extended, 3 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2):
First sector (585728-283106807, default 585728):
Last sector, +sectors or +size{K,M,G,T,P} (585728-283106807, default 283106807):

Created a new partition 2 of type 'Linux' and of size 134.7 GiB.
Partition #2 contains a LVM2_member signature.

Do you want to remove the signature? [Y]es/[N]o: n

Achtung: hier unbedingt N für no angeben. Wir wollen die Daten ja nicht löschen.

Den Typen der Partition wieder richtig angeben:
Command (m for help): t
Partition number (1,2, default 2):
Partition type (type L to list all types): 8e

Changed type of partition 'Linux' to 'Linux LVM'.

Mit p noch einmal überprüfen:
Command (m for help): p
Disk /dev/vda: 135 GiB, 144950685696 bytes, 283106808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xec02ef62

Device Boot Start End Sectors Size Id Type
/dev/vda1 * 2048 585727 583680 285M 83 Linux
/dev/vda2 585728 283106807 282521080 134.7G 8e Linux LVM

Wenn man sich sicher ist das alles richtig angegeben wurde kann man die Partition mit w Speicher:
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Device or resource busy

The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).

Jetzt triggern wir den Kernel, dass er die neue Partitionstabelle erkennt:
apt install partprobe
...
partprobe /dev/vda

Anschließend vergrößern wir das PV und dann das VG:
Das PV (Physical Volumes):
pvresize /dev/vda2
Physical volume "/dev/vda2" changed
1 physical volume(s) resized / 0 physical volume(s) not resized

Die VG (Volumen Gruppe):
vgextend VolGroup1
Command failed with status code 5.

Und zum Abschluss noch einmal prüfen, ob alles geht:
vgs
VG #PV #LV #SN Attr VSize VFree
VolGroup1 1 3 0 wz--n- 134.71g 121.36g

Kernel Bug in CentOS 7

Sonntag, Februar 12th, 2017

Nach dem neu starten unserer VServer Plattform mit dem Kernel 3.10.0-514, traten nach sofort nach dem Booten folgende schwerwiegenden Fehler im Log auf:

kernel: Buffer I/O error on dev dm-15, logical block 8892681, lost async page write
kernel: sd 4:0:0:0: [sdc] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
kernel: sd 4:0:0:0: [sdc] Sense Key : Not Ready [current]
kernel: sd 4:0:0:0: [sdc] Add. Sense: Logical unit communication failure
kernel: sd 4:0:0:0: [sdc] CDB: Write(16) 8a 00 00 00 00 00 37 7d 48 00 00 00 40 00 00 00
kernel: blk_update_request: I/O error, dev sdc, sector 930957312
kernel: sd 4:0:0:0: [sdc] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

Aber auch folgende syslog events traten auf, nachdem mittels:

lvmcreate -L 10G -n lv_snapshot -S vg/lv

ein snapshot erzeugt wurde.

kernel: EXT4-fs (dm-28): INFO: recovery required on readonly filesystem
kernel: EXT4-fs (dm-28): write access will be enabled during recovery
kernel: EXT4-fs warning (device dm-28): ext4_clear_journal_err:4718: Filesystem error recorded from previous mount: IO fail
ure
kernel: EXT4-fs warning (device dm-28): ext4_clear_journal_err:4719: Marking fs in need of filesystem check.
kernel: EXT4-fs (dm-28): recovery complete
kernel: EXT4-fs (dm-28): mounted filesystem with ordered data mode. Opts: (null)
kernel: EXT4-fs (dm-28): INFO: recovery required on readonly filesystem
kernel: EXT4-fs (dm-28): write access will be enabled during recovery
kernel: EXT4-fs (dm-28): orphan cleanup on readonly fs
kernel: EXT4-fs (dm-28): 6 orphan inodes deleted
kernel: EXT4-fs (dm-28): recovery complete

Schlimmer noch, die VMs wechselten nach kurzer Zeit in den read only Modus. Und konnten ohne erweitertes Filesystem Check nicht wieder gestart werden.

Zugglück sind wir schnell auf den Kernel Parameter gekommen, der das Problem verursacht hat.

cat /sys/block/sda/queue/max_sectors_kb
32767

Dieser Wert war bei älteren Servern noch auf 512 eingestellt. Bei den von dem Bug betroffenen Server durfte er nicht über 4096 eingestellt sein, stand aber immer wieder auf 8192.

Der CentOS Bug Report 12725, in dem das selbe verhalten mittels:

parted -s /dev/sda unit s print

beschrieben wurdet, half uns den Fehler weiter auf den Kernel einzuschränken. Immer wenn eine Partitionsabfrage, oder eine Änderung am LVM Stattgefunden hat, änderte sich der Wert plötzlich wieder auf 8192.

Folgende udev Regel, die wir unter /etc/udev/rules.d/99-san.rules eingefügt haben, verhinderte das umstellen des wertes:

ACTION=="add|change", ENV{ID_FS_USAGE}!="filesystem", ENV{ID_PATH}=="*-iscsi-*", RUN+="/bin/sh -c 'echo 4096 > /sys$DEVPATH/queue/max_sectors_kb'"

Fazit:
Ein so schwerwiegenden Kernel Bug ist mit schon lange nicht mehr untergekommen. Er hatte für uns zufolge das wir bei einzelnen VMs nur noch teile retten konnten und komplett aus dem Backup wiederhergestellt werden mussten. Auch das Rechercheiren des Bugs ist bei CentOS kaum möglich. Da es zu RedHat binär kompatibel kann man nicht einfach durch ein git repository zu scrolen und sich die Änderungen und Kommentare anschauen. Wo bei mir die Überlegung offen ist, zukünftig auf einen Vanilla-Kernel zu wechseln und/oder CentOS zu vermeiden.

Unser Kernel: 3.10.0-514.6.1.el7.x86_64
Quelle Burgreport: https://bugs.centos.org/view.php?id=12725

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

lvm mounten mit dmsetup

Sonntag, März 6th, 2016

Um die Daten einer Festplatte zu retten auf unter anderem ein LVM Raid1 war, habe ich versucht mit vgchange -ay vg das vg zu starten. Andernfalls waren die LVS nicht unterhalb von /dev/mapper/ nicht aufgeführt.
Nach dem ich aber vgchange -ay vg aufrief war die Festplatte nur noch mit Lesezugriffen beschäftige. Die LVS waren vorhanden aber leisen sich nicht mounten. Somit habe ich den Vorgang mit vgchange -an vg wieder abgebrochen.

Um von hinten am LVM vorbei an die Daten heranzukommen half mir folgende Option mit der ich an die Festplatte bzw. die Position des lvs heran kam:

lvs -a -o +seg_pe_ranges|grep lv
LV   VG Attr       LSize   Convert PE Ranges
WARNING: Device for PV ZfExWH-u4Z9-zuqn-6e8P-ecDe-TYuQ-rBIlQP not found or rejected by a filter.
lv   vg owi-i-s---  40,00g dev/sdc3:38146-48385

In der Datei /etc/lvm/backup/vg fand ich zusätzlich noch folgend Informationen, alle anderen habe ich an dieser stelle ausgelassen:

vg {
        extent_size = 8192              # 4 Megabytes
        physical_volumes {
                pv0 {
                        device = "/dev/sdc3"    # Hint only
                        pe_start = 384          # Ofset

Mit diesen Werten kann man die Position des LVs auf der Festplatte lokalisieren und mit dmsetup einen eigenes device anlegen.

(48385-38146+1)*8192
(Partitionsende – Paritionsanfang + 1) * extent_size = ergibt die gesamt Größe: 83886080

384+38146*8192
pe_start + Paritionsanfang * extent_size begin auf der Parition: 312492416

echo "0 83886080  linear /dev/sdc3 312492416" | dmsetup create -r "lv_ro"

Unter /dev/mepper/lv_ro befindet sich nun das LV das gemountet werden kann.

Wie man an dieser stelle das readonly device mounten kann folgt im nächsten Blog Eintrag.

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.