Migration der vCenter Server Appliance Datenpartitionen auf LVM-Volumes

Vor einigen Tagen bin ich im vCenter-Dienststatus auf folgenden Hinweis gestoßen:

Ldap backup task monitor warning

Ldap backup task monitor warning

Hier lag offensichtlich ein Problem mit dem integrierten LDAP-Dienstes der vCenter Server Appliance vor – unter Angabe der Fehlermeldung bin ich leider nicht direkt im Internet fündig geworden:

Fehler bei Unterkomponente der LDAP-Datensicherung: Status des JoinTool-Vorgangs: FAILED

Ein erster Blick auf das System lieferte jedoch gleich einen sachdienlichen Hinweis auf eine mögliche Fehlerursache:

# df -h|grep log
/dev/sdb2        20G   20G  0  100% /storage/log

Bedingt durch das zentralisierte Sammeln von Systemmeldungen aller verbundenen ESXi-Hosts war hier einfach der Speicherplatz erschöpft. Die Lösung war banal: ein Aufräumen der entsprechenden Festplatte löste das Problem und die Warnung im vCenter verschwand.

Zeit, die ursprüngliche Fehlerursache nachhaltig zu beheben: also das Anpassen der zu klein geratenen Partition.

Das vCSA-Partitionslayout

Die vCSA verfügt im Wesentlichen aus zwei Festplatten:

  • Festplatte 1 (SCSI 0:0): 25 GB – Betriebssystem (SLES 11 SP2)
  • Festplatte 2 (SCSI 0:1): 100 GB – Datenbank und Logs/Dumps

Leider wurde beim Partitionslayout kein LVM verwendet, weswegen das nachträgliche Anpassen der Partitionsgrößen Downtime der Anwendung bedeuten würde. Ich persönliche habe auch nicht nur positive Erfahrungen beim manuellen Anpassen von konventionellen Partitionslayouts gemacht. LVM würde hier gleich mehrere Vorteile bringen:

  • flexiblere Verteilung von Speicher (kein manuelles Anpassen von Partitionstabellen, etc.)
  • Volumes können online erweitert werden (kein Stoppen der VMware-Dienste notwendig)
  • deutlich einfachere und „schönere“ Lösung

Das Layout sieht standardmäßig wie folgt aus:

# df -h|grep -i sd
/dev/sda3       9.8G  3.8G  5.5G  41% /
/dev/sda1       128M   21M  101M  18% /boot
/dev/sdb1        20G  3.4G   16G  18% /storage/core
/dev/sdb2        20G   16G  3.7G  81% /storage/log
/dev/sdb3        60G  1.8G   55G   4% /storage/db

Die erste Festplatte beinhaltet neben einer Swap-Partition lediglich die Boot- und Root-Partition. Die zweite Festplatte (100 GB) teilt sich in eine großzügige Datenbank-Partition und zwei Partitionen für Coredumps und Logs auf. Letztere ist mit 20 GB oftmals recht knapp bemessen.

Das fehlende LVM-Design lässt sich schnell nachholen.

[alert style=“red“]Das von mir geschilderte Vorhaben benötigt für die erste Einrichtung auch eine Downtime, zukünftige Erweiterungen sind dann aber „online“ möglich. Darüber hinaus wird diese Anpassung nicht von VMware unterstützt.[/alert]

Zuerst wird der VM eine weitere Festplatte hinzugefügt, ich habe hier auch wieder 100 GB gewählt. Diese Größe reicht prinzipiell aus (siehe oben), ist im Standard-Partitionslayout nur nicht immer sinnhaft verteilt. In meinem Fall wird das vCenter mit einer kleinen Datenbank verwendet, da ich damit auch nur eine kleine Umgebung verwalte – hier benötige ich also nicht die vorhergesehenen 60 GB für Datenbank-Dateien (/storage/db). Wird eine größere Umgebung verwaltet, benötigt man hier jedoch u.U. den vollen Speicherplatz. Die Partition für Core-Dumps (/storage/core) würde ich nicht oder nur mit Vorbehalt verkleinern – tritt ein ernstes Problem mit der vCenter Server Appliance auf, können keine vollständigen Coredumps mehr generiert werden.

Mein Plan zur Optimierung des Layout sieht wie folgt aus (bitte bedenken, dass dieses Layout je nach Systemlandschaft nicht unbedingt direkt übernommen werden kann!):

  • neue Festplatte (100 GB) als physikalisches LVM-Volume partitionieren
  • neue LVM-VG „vg_storage“ erstellen
  • neue LVM-LVs „lv_core“ (20 GB), „lv_log“ (40 GB) und „lv_db“ (40 GB) erstellen
  • neu angelegte LVM-LVs mit ext3 (wie vorher) formattieren und temporär einhängen
  • In den Single-User-Mode wechseln und Datenstände kopieren
  • /etc/fstab anpassen

Ich verwende übrigens die VMware vCenter Server Appliance in der Version 5.5 – vermutlich lässt sich das geschilderte Vorgehen jedoch auch auf ältere Versionen adaptieren. Bevor die nachfolgenden Schritte ausgeführt werden, empfehle ich die Erstellung eines Klons (oder zumindest eines Snapshots) der virtuellen Appliance. Es kann auch nicht schaden, gemäß der folgenden KB-Artikel ein Backup der Datenbank und Anwendungskonfigurationen zu erstellen:

Wichtig ist auch, mein oben erwähntes Layout genau zu überprüfen und, wenn notwendig, den eigenen Anforderungen anzupassen! Idealerweise wirft man hier einen Blick auf die Auslastung der zweiten Festplatte. Ich übernehme keinerlei Garantie für Schäden aufgrund falsch gewählter Volumengrößen.

Vorab muss noch dafür gesorgt werden, dass das auf SUSE Linux Enterprise Server 11 SP2 basierende System LVM-Volumes beim Booten erkennt und automatisch aktiviert – ansonsten endet der nächste Boot-Vorgang mit fsck, das die neu angelegten Volumes nicht überprüfen kann. Hierzu muss die folgende Konfigurationsdatei angepasst werden:

# cp /etc/sysconfig/lvm /etc/sysconfig/lvm.initial
# vi /etc/sysconfig/lvm
...
#LVM_ACTIVATED_ON_DISCOVERED="disable"
LVM_ACTIVATED_ON_DISCOVERED="enable"

Damit werden alle erkannten LVM-Volumes beim Booten aktiviert bevor die in der /etc/fstab vermerkten Dateisysteme eingehängt werden. Wer möchte, kann stattdessen auch den folgenden Parameter auf den Namen der anzulegenden Volumengruppe setzen, damit nur diese beim Booten aktiviert wird:

#LVM_VGS_ACTIVATED_ON_BOOT=""
LVM_VGS_ACTIVATED_ON_BOOT="vg_storage"
...
LVM_ACTIVATED_ON_DISCOVERED="disable"

Somit werden nicht alle verfügbaren LVM-Volumengruppen sondern nur die angelegte (vg_storage) beim Booten automatisch aktiviert.

Auf der neu hinzugefügten 100 GB-Festplatte wird nun eine LVM-Partition angelegt und initialisiert:


# fdisk /dev/sdc <<EOF
n
p
1

t
8e
p
w
EOF

Anschließend werden die LVM-Volumengruppe und die logischen Volumes angelegt. Ich habe hier die Größe des Datenbankvolumes auf 40 GB reduziert und dafür die Größe des Log-Volumes verdoppelt:

# vgcreate --name vg_storage /dev/sdc1
# lvcreate --size 20G --name lv_core vg_storage
# lvcreate --size 40G --name lv_log vg_storage
# lvcreate --extents 100%FREE --name lv_db vg_storage

Als nächstes werden ext3-Dateisysteme auf den neu angelegten logischen Volumes erstellt:

# mkfs.ext3 /dev/mapper/vg_storage/lv_core
# mkfs.ext3 /dev/mapper/vg_storage/lv_log
# mkfs.ext3 /dev/mapper/vg_storage/lv_db

Anschließend ist es empfehlenswert die initial ramdisk zu aktualisieren, damit sichergestellt ist, dass der Kernel schon zu Boot-Zeiten über den notwendigen lvm2-Treiber verfügt:

# mkinitrd_setup
# file /lib/mkinitrd/scripts/setup-lvm2.sh
# mkinitrd -f lvm2
Scanning scripts ...
Resolve dependencies ...
Install symlinks in /lib/mkinitrd/setup ...
Install symlinks in /lib/mkinitrd/boot ...

Kernel image:   /boot/vmlinuz-3.0.101-0.5-default
Initrd image:   /boot/initrd-3.0.101-0.5-default
Root device:    /dev/sda3 /mounted on / as ext3)
Resume device:  /dev/sda2
Kernel Modules: hwmon thermal_sys thermal processor fan scsi_mod scsi_transport_spi mptbase mptscsih mptspi libara ata_piix ata_generic vmxnet scsi_dh scsi_dh_rdac scsi_dh_alua scsi_dh_hp_sw scsi_dh_emc mbcache jbd ext3 crc-t10dif sd_mod
Features:       acpi dm block lvm2
27535 blocks

Anschließend werden temporäre Mountpoints für die neuen Dateisysteme angelegt und die Volumes eingehängt:

# mkdir -p /new/{core,log,db}
# mount /dev/mapper/vg_storage-lv_core /new/core
# mount /dev/mapper/vg_storage-lv_log /new/log
# mount /dev/mapper/vg_storage-lv_db /new/db

Bei der letztendlichen Kopie der Dateien habe ich mich an einem KB-Artikel von VMware orientiert (2056764 – „Increase the disk space in vCenter Server Appliance“). Zuerst wird in den Single-User-Mode gewechselt, um sicherzustellen, dass keiner der VMware-Dienste noch aktiv ist – somit werden etwaige File-Locks aufgehoben und ein konsistenter Zustand der Anwendung sichergestellt. Anschließend werden die Daten mittels cp kopiert und die /etc/fstab (nach erfolgter Sicherung) angepasst. Zuletzt werden die temporären Mountpoints gelöscht und die neuen Partitionen unter dem alten Pfad eingehängt:

# init 1
# cp -a /storage/db/* /new/db
# cp -a /storage/log/* /new/log
# cp -a /storage/core/* /new/core
# umount /{new,storage}/{db,log,core}
# cp /etc/fstab /etc/fstab.copy
# sed -i -e 's#/dev/sdb1#/dev/mapper/vg_storage-lv_core#' /etc/fstab
# sed -i -e 's#/dev/sdb2#/dev/mapper/vg_storage-lv_log#' /etc/fstab
# sed -i -e 's#/dev/sdb3#/dev/mapper/vg_storage-lv_db#' /etc/fstab
# mount /storage/{db,log,core}
# rmdir -p /new/{db,core,log}

Ein Blick in die Ausgabe von df zeigt, dass die Anpassung übernommen wurde:

# df -h|grep storage
/dev/mapper/vg_storage-lv_core   20G  3.4G   16G  18% /stoage/core
/dev/mapper/vg_storage-lv_log    40G   15G   23G  40% /stoage/log
/dev/mapper/vg_storage-lv_db     40G  1.7G   36G   5% /stoage/db

Nun sollte einem erfolgreichen Wechsel in den Standard-Runlevel 3 nichts mehr im Wege stehen:

# init 3

Es empfiehlt sich jedoch, vorher auch testweise einen Reboot durchzuführen, um sicherzustellen, dass die LVM-Volumes auch nach einem Neustart noch zur Verfügung stehen. Nachdem sichergestellt wurde, dass VMware vCenter fehlerfrei funktioniert, kann die vorherige Daten-Festplatte aus der Konfiguration der virtuellen Maschine entfernt werden.

6 Kommentare Schreibe einen Kommentar

  1. An sich eine schöne Anleitung – aber – gibts bei Euch so viele Admins, daß 5 Minuten Downtime eines vCenters ein Problem sind?
    Lieber mal nen Wartungsfenster als unsupportete Software.

    Überhaupt wird heut um die Verfügbarkeit m.E. ein riesen Buhei gemacht.

    Jetzt müssen selbst schon Management-Systeme höchstverfügbar sein!?

    Was war das Leben in den 80ern doch noch entspannt 😉

    • Hallo Roland,
      vielen Dank für das Feedback!

      Eine kurze Downtime ist für unsere Umgebung kein Problem, weswegen wir auch die wartungsarmere vCenter Server Appliance einsetzen. Wäre das nicht hinnehmbar, wäre vCenter Server Heartbeat wohl das bessere (Zusatz-)Produkt für uns geewesen. Ich vermute solche „HA-Managementlösungen“ sind vermutlich primär für sehr große Umgebungen (100+ ESXi-Hosts) und Teams gedacht. Mich würde mal interessieren, wie das genau bei Hostern und Providern aussieht. 🙂

      Es ging mir mehr darum, dass die Partitionierung der Datenfestplatte „schöner“ implementiert werden kann. Aktuell muss man recht viel manuelle Handarbeit verrichten, die man vermeiden könnte.

      Nicht unterstützte Erweiterungen zu nutzen ist keine vernünftige Option, da stimme ich Dir voll und ganz zu – deswegen ja auch der offizielle Request beim Product Engineering. Ich bin gespannt, wie die Jungs bei VMware darauf reagieren. 🙂

      Beste Grüße!

  2. Danke dir für den Artikel.
    Bei einem solchen LVM Layout lasse ich aber die Partition auf sdc normalerweise weg.
    Vergrössern der VG geht dann mit 3 Schritten:
    – Disk unter VMware vergrössern
    – Rescan des Scsi Geräts innerhalb der VM
    – pvresize /dev/

  3. Thanks, this was helpful. I had the same error and while your df command didn’t direclty help me, this one did. but same problem essentially – out of log space.
    # df -h|grep storage
    /dev/sdb1 20G 173M 19G 1% /storage/core
    /dev/sdb2 20G 560M 19G 3% /storage/log
    /dev/sdb3 60G 2.7G 54G 5% /storage/db
    storagesrvr:/vCenter-SYSLOG 80G 80G 0 100% /storage/nfs.log.L5ZXIF5w
    STORAGESRVR:/corefiles 80G 80G 0 100% /storage/nfs.core.fesdwa5d

Schreibe einen Kommentar