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

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:

1# df -h|grep log
2/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:

1# df -h|grep -i sd
2/dev/sda3       9.8G  3.8G  5.5G  41% /
3/dev/sda1       128M   21M  101M  18% /boot
4/dev/sdb1        20G  3.4G   16G  18% /storage/core
5/dev/sdb2        20G   16G  3.7G  81% /storage/log
6/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.

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:

• KB 2034505: "Backing up and restoring the vCenter Server Appliance vPostgres database"
• KB 2063260: "Backing up and restoring the vCenter Single Sign-On 5.5 configuration for the vCenter Server Appliance"
• KB 2062682: "Backing up and restoring the vCenter Server Appliance Inventory Service database"

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:

1# cp /etc/sysconfig/lvm /etc/sysconfig/lvm.initial
2# vi /etc/sysconfig/lvm
3...
4#LVM_ACTIVATED_ON_DISCOVERED="disable"
5LVM_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:

1#LVM_VGS_ACTIVATED_ON_BOOT=""
2LVM_VGS_ACTIVATED_ON_BOOT="vg_storage"
3...
4LVM_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:

1# fdisk /dev/sdc <<EOF
2n
3p
41
5t
68e
7p
8w
9EOF

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:

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

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

1# mkfs.ext3 /dev/mapper/vg_storage/lv_core
2# mkfs.ext3 /dev/mapper/vg_storage/lv_log
3# 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:

 1# mkinitrd_setup
 2# file /lib/mkinitrd/scripts/setup-lvm2.sh
 3# mkinitrd -f lvm2
 4Scanning scripts ...
 5Resolve dependencies ...
 6Install symlinks in /lib/mkinitrd/setup ...
 7Install symlinks in /lib/mkinitrd/boot ...
 8
 9Kernel image:   /boot/vmlinuz-3.0.101-0.5-default
10Initrd image:   /boot/initrd-3.0.101-0.5-default
11Root device:    /dev/sda3 /mounted on / as ext3)
12Resume device:  /dev/sda2
13Kernel 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
14Features:       acpi dm block lvm2
1527535 blocks

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

1# mkdir -p /new/{core,log,db}
2# mount /dev/mapper/vg_storage-lv_core /new/core
3# mount /dev/mapper/vg_storage-lv_log /new/log
4# 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:

 1# init 1
 2# cp -a /storage/db/* /new/db
 3# cp -a /storage/log/* /new/log
 4# cp -a /storage/core/* /new/core
 5# umount /{new,storage}/{db,log,core}
 6# cp /etc/fstab /etc/fstab.copy
 7# sed -i -e 's#/dev/sdb1#/dev/mapper/vg_storage-lv_core#' /etc/fstab
 8# sed -i -e 's#/dev/sdb2#/dev/mapper/vg_storage-lv_log#' /etc/fstab
 9# sed -i -e 's#/dev/sdb3#/dev/mapper/vg_storage-lv_db#' /etc/fstab
10# mount /storage/{db,log,core}
11# rmdir -p /new/{db,core,log}

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

1# df -h|grep storage
2/dev/mapper/vg_storage-lv_core   20G  3.4G   16G  18% /stoage/core
3/dev/mapper/vg_storage-lv_log    40G   15G   23G  40% /stoage/log
4/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:

1# 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.