ESXi Bootmedium – Neuerungen in v7 und Altlasten aus v6.x

Mit vSphere7 kamen grundlegende Veränderungen im Aufbau des ESXi Bootmediums. Eine starre Partitionsstruktur musste einer flexibleren Partitionierung weichen. Dazu später mehr.

Mit vSphere 7 Update 3 kam auch eine schlechte Nachricht für alle, die USB- oder SDCard-Flashmedien als Bootdevice nutzen. Steigende Lese- und Schreibaktivität führte zu schneller Alterung und Ausfall dieser Medien, da sie für ein solches Lastprofil nie ausgelegt waren. VMware hat diese Medien auf die Rote Liste gesetzt und der vSphere Client wirft Warnmeldungen, sollte ein soches Medium noch verwendet werden. Wir werden uns ansehen, wie man USB- oder SDCard-Bootmedien ersetzen kann.

ESXi Bootmedium: Gestern und heute

In der Vergangenheit bis Version 6.x war das Bootmedium relativ statisch. War der Bootvorgang erst einmal abgeschlossen, so war das Medium nicht mehr wichtig. Es gab allenfalls eine gelegentliche Leseanfrage einer VM auf das VM-Tools Verzeichnis. Selbst ein Medium, das im laufenden Betrieb kaputt ging, beeinträchtigte den ESXi Host nicht. Problematisch wurde nur ein Neustart. So konnte man beispielsweise auch bei defektem Bootmedium noch die aktuelle ESXi Konfiguration sichern.

Aufbau eines ESXi Bootmediums vor Version 7

Aufbau des Bootmediums bis ESXi 6.7

Der Aufbau war im Prinzip fast immer gleich: Ein Bootloader von 4 MB Größe (FAT16), gefolgt von zwei Bootbänken mit je 250 MB. Diese enthalten die komprimierten Kernelmodule, die beim Systemstart entpackt und ins RAM geladen werden. Eine zweite Bootbank ermöglicht ein Rollback im Falle eines fehlgeschlagenen Updates. Es folgt eine “Diagnostic Partition” von 110 MB für kleine Coredumps im Falle eines PSOD. Die Locker oder Store Partition enthält z.B. ISO Images mit VM-Tools für alle unterstützten Gast-OS. Von hier aus werden VM-Tools ins die Gast VM eingebunden. Eine häufige Fehlerquelle bei der Tools Installation war ein beschädigtes oder verlorenes Locker Verzeichnis.

Die folgenden Partitionen unterscheiden sich je nach Größe und Art des Bootmediums. Die zweite Diagnostic-Partition von 2,5 GB wurde nur angelegt, wenn das Bootmedium mindestens 3,4 GB groß ist (4MB + 250MB + 250MB + 110MB + 286MB = 900MB). Zusammen mit den 2,5 GB der zweiten Diagnostic Partition erfordert das 3,4 GB.

Eine 4 GB Scratch Partition wurde nur auf Medien mit mindestens 8,5 GB angelegt. Sie enthält Informationen für den VMware Support. Alles darüber hinaus wurde als VMFS-Datenspeicher bereitgestellt. Scatch und VMFS Partition wurden jedoch nur angelegt, wenn das Medium kein USB-Flash oder SDCard Speicher war. In diesem Fall wurde die Scratchpartition im RAM des Hosts angelegt. Mit der Folge, dass bei einem Host Crash auch alle für den Support wertvollen Informationen verloren gingen.

Aufbau des Bootmedium ab ESXi 7

Das oben skizzierte Layout machte die Verwendung großer Module oder Fremdanbietermodule schwierig. Folglich musste das Design des Bootmedium grundlegend verändert werden.

Veränderung des Partitionslayouts zwischen Version 6.x und 7.x

Zunächst wurde die Bootpartition von 4 MB auf 100 MB vergrößert. Auch die beiden Bootbänke wurden auf mindestens 500 MB angehoben. Die Größe gestaltet sich flexibel, abhängig von der Gesamtgröße des Mediums. Die beiden Diagnose-Partitionen (Small Core Dump und Large Core Dump), sowie Locker und Scratch wurden zusammengeführt in eine gemeinsame ESX-OSData Partition mit flexibler Größe zwischen 2,9 GB und 128 GB. Übriger Speicherplatz kann optional als VMFS-6 Datenspeicher bereitgestellt werden.

Unterschieden werden bei vSphere 7 vier Größenklassen für Bootmedien:

  • 4 GB – 10 GB
  • 10 GB – 32 GB
  • 32 GB – 128 GB
  • > 128 GB
Dynamische Partitionierung unter vSphere 7 in Anhängigkeit von der Medienkapazität.

Die oben dargestellten Partitionsgrößen gelten für neu installierte Bootmedien unter ESXi 7.0. Doch wie sieht es für Bootmedien aus, die von Version 6.7 migriert wurden?

„ESXi Bootmedium – Neuerungen in v7 und Altlasten aus v6.x“ weiterlesen

Backup & Restore VCSA 6.0 embedded Postgres Database

Wenn die Datenbank einer vCenter Server Appliance (VCSA) wiederhergestellt oder auf einen älteren Stand zurückgesetzt werden muss, sollte man ein Backup zur Hand haben. VMware bietet Hilfsmittel, um die integrierte Postgres DB zu sichern und wieder herzustellen.

Backup

Login in VCSA als root user.

Bash Shell freischalten

shell.set --enabled true
shell

Speicherort für Backups erstellen

mkdir ~/backups

Download der Skript Files von KB 2091961 (Seitenende) und mit WinSCP auf die vCenter Appliance übertragen. Ziel ist der zuvor erstellte Ordner “backups”.

cd ~/backups
ls -la
unzip <scriptfile>.zip

Skriptdateien ausführbar machen

chmod 700 backup_lin.py
chmod 700 restore_lin.py

Backupskript ausführen

python backup_lin.py -f backup_VCDB.bak

Das Backupfile “backup_VCDB.bak” mittels WinSCP von der Appliance laden.

Restore

Login in VCSA als root user und ins Verzeichnis backups wechseln.

cd ~/backups

Mit WinSCP das Datenbank Backupfile in die Appliance (backups) transferieren. Überprüfen, ob das Restore Skript im ‘backups’ Verzeichnis vorhanden ist und ob es ausführbar ist.

ls -la

Dienste beenden

Zunächst müssen der Inventory Service und der Content Library Service beendet werden.

service vmware-vpxd stop
service vmware-vcds stop

Restore Skript ausführen

python restore_lin.py -f backup_VCDB.bak

Es folgt ein längerer Restore Prozess.

Dienste starten

Die oben beendeten Dienste müssen nun wieder neu gestartet werden.

service vmware-vpxd start
service vmware-vcds start

Wer es noch etwas ausführlicher haben möchte, kann sich das Video auf YouTube ansehen.

Links

vmware KB 2091961 – Back up and restore vCenter Server Appliance/vCenter Server 6.0 vPostgres database.

 

Veeam Restore Point Simulator

Eine sehr wichtige Frage bei der Planung von Backup Datenspeicher, ist die Abschätzung des Backupvolumens und die damit verbundene Dimensionierung des Speichersystems.

Restore Point Simulator

Veeam stellt hierfür mit dem Restore Point Simulator ein nützliches Onlinetool bereit, mit dem sich der Speicherbedarf abschätzen lässt.

http://vee.am/rps

Diesen Kurzlink sollte man sich merken. Ist ja auch nicht wirklich schwer. 😉

Die Eingabe ist einfach gehalten. In den Quick Presetz kann man die Art des Backups wählen. Also Reverse-Incremental, Incremental, Incremental mit Synthetic Full, Backup Copjob etc.

RPS01

Durch aktivieren des “Simulate” Buttons wird das Ergebnis geschätzt.

rps02

ESXi 5.5 VAAI unmap

Thin-Provisioning – also die schrittweise Zuteilung von Speicherressourcen – gibt es nicht nur in Form von VMDK Diskfiles, sondern auch auf Storage-Ebene. Hier werden Volumes nicht 1:1 als LUN an den Host übergeben, sondern das (reale) Speichervolume ist von der (virtuellen) LUN entkoppelt. Man kann so Datenspeicher effizienter ausnutzen und dynamisch zuteilen. Da der ESX Host nun keinen physischen Zugriff auf das Speichervolume mehr hat, sondern nur auf die virtuelle LUN, muss es eine Möglichkeit geben, mit welcher der Host der Storage Rückmeldung über gelöschte oder verschobene Speicherbereiche geben kann. Um diese Funktion wurde die “vStorage APIs for Array Integration” (VAAI) unter vSphere 5.0 erweitert. Die VAAI Funktionen heissen “primitives” und jene, die für die Rückgabe von Speicher verantwortlich ist nennt sich UNMAP.

Leider gab es damit einige Probleme in Verbindung mit Storage Geräten, weswegen diese Funktion von VMware schnell wieder zurückgezogen wurde. Bis zum Stand 5.5 wurde sie nicht wieder aktiviert. Man kann sie aber dennoch nutzen – wenn auch nicht komfortabel.

„ESXi 5.5 VAAI unmap“ weiterlesen