Zu wenig Speicherplatz: vCenter mehr Storage zuweisen

Thomas Drilling, 07.07.2021
Tags: vCenter, Storage, Troubleshooting

vCenter-Datenbank Geht der vCenter-Appliance der Festplattenspeicher aus, dann ist schnelles Handeln angesagt, um sie funktionsfähig zu halten. Wie bei der Vergrößerung von VM-Storage üblich, muss man den neu zugewiesenen Speicher im Gast-OS einbinden. Dabei lässt sich eine Downtime allerdings nicht vermeiden.

Um den Speicherplatz für eine Disk zu vergrößern, geht man grundsätzlich so vor:

Zuerst müssen Sie die vCenter Server-VM ausschalten. Können Sie aufgrund des Speicherproblems nicht mehr auf die VM zugreifen, müssen Sie die VM im ESXi-Client herunterfahren.
Wählen Sie dann in den Einstellungen der virtuellen Hardware die betreffende Disk aus und erhöhen Sie deren Kapazität. Dabei müssen Sie unbedingt sicherstellen, dass kein Snapshot existiert.
Anschließend verbinden Sie sich per bash oder Appliance Management CLI mit der VM, um die Partition(en) im Gastsystem zu erweitern.

Vollgelaufene Disk identifizieren

Seit der Einführung des Logical Volume Management (LVM) in vSphere 6.0 kann man die vCenter Server-Festplatten dynamisch vergrößern. Da die Appliance allerdings mittlerweile mit 16 VMDKs ausgestattet ist, müssen Sie zunächst die Disk identifizieren. welcher der Speicherplatz ausgeht.

Die für vSphere 7 aktuell geltende Zuordnung der Disks zu Mount-Punkten sieht wie folgt aus:

Disk (VMDK)	Default Size (Tiny with Default Storage Size)	Mount Point	Zweck
VMDK1	48GB	(46GB) /boot (132MB) SWAP (1GB)	Kernel-Images und Bootloader-Konfigurationen
VMDK2	1.8GB	/tmp	Temporäre Dateien, die von vCenter-Diensten generiert oder verwendet werden
VMDK3	25GB	SWAP	Auslagerung
VMDK4	25GB	/storage/core	Verzeichnis, in dem der vCenter-Server Core-Dumps des VPXD-Prozesses speichert
VMDK5	10GB	/storage/log	Protokolle von vCenter-Server und Platform Services Controller
VMDK6	10GB	/storage/db	VMware Postgres-Datenbank
VMDK7	5GB	/storage/dblog	Protokollierung der VMware Postgres-Datenbank
VMDK8	10GB	/storage/seat	Stats, Events, Alarms and Tasks (SEAT)-Verzeichnis für VMware Postgres
VMDK9	1GB	/storage/netdump	VMware Netdump Collector-Repository, das ESXi-Dumps speichert
VMDK10	10GB	/storage/autodeploy	VMware Auto Deploy-Repository. Hier werden die Thin-Packages für das zustandslose Booten von ESXi-Hosts gespeichert
VMDK11	10GB	/storage/imagebuilder	VMware Image Builder-Repository, das die vSphere-Image-Profile, Software-Depots und VIB-Pakete enthält, beispielsweise Treiber-VIBs und Update-VIBs.
VMDK12	100GB	/storage/updatemgr	VMware Update Manager-Repository für Patches und Updates von virtuellen Maschinen und ESXi-Hosts
VMDK13	50GB	/storage/archive	Write-Ahead Logging (WAL)-Speicherort der VMware Postgres-Datenbank
VMDK14	10GB	/storage/vtsdb	VMware vTSDB Service Repository, das die Statistiken speichert
VMDK15	5GB	/storage/vtsdblog	VMware vTSDB Service Repository, das die Protokolle dieses Dienstes speichert
VMDK16	100GB	/storage/lifecycle	Service Stage-Verzeichnis oder Software-Depot der Workload Control Plane. Hier werden die Binärdateien für die Installation und das Update/Upgrade abgelegt.

Um zu ermitteln, bei welcher Festplatte Probleme mit der Kapazität auftreten, nutzen Sie auf der Kommandozeile der Appliance den Befehl

df -h

In der Beispielabbildung haben wir zwar akut kein Speicherproblem, wollen aber für diesen Beitrag vorsorglich die Partition für /storage/log (59 Prozent Belegung) vergrößern.

Geben Sie nun das Kommando

lsblk

ein.

Es zeigt Ihnen die zugehörige Gerätedatei an, hier dev/sde. Nun ermitteln Sie mit

lsscsi

an welchem Controller-Knoten die Disk /dev/sde hängt, in unserem Beispiel [2:0:4:0], was gleichbedeutend ist mit SCSI-Controller 0, Port 0, Target 4.

Mit dieser Information können Sie die richtige Disk in den Einstellungen der VM sicher identifizieren. Es zeigt sich, dass unser Laufwerk im vSphere Client der Festplatte 5 entspricht.

Schalten Sie die vCenter-Appliance aus und vergrößern Sie die Disk im vSphere-Client, der dann von einem anderen (verlinkten) vCenter gestartet werden müsste (alternativ käme der Host-Client auf dem betreffenden ESXi in Frage). Danach fahren sie die vCSA wieder hoch und passen das Dateisystem im Gast dank LVM-Support sehr einfach an:

/usr/lib/applmgmt/support/scripts/autogrow.sh

Das Kommando vergrößert einfach alle Dateisysteme, auf deren Laufwerken das Storage-Subsystem nicht partitionierten Platz findet, in diesem Beispiel also nur bei der Festplatte 5.

Täglich Know-how für IT-Pros mit unserem Newsletter

Thomas Drilling arbeitet seit mehr als 20 Jahren selbständig als Redakteur und Autor für viele ehemalige und aktuelle IT-Magazine sowie Blogs. Thomas ist zudem Buchautor und IT-Consultant.

Seit 5 Jahren ist Thomas neben seiner journalistischen Tätigkeit hauptberuflicher, selbständiger IT-Trainer für VMware und Microsoft.

Seine Themenschwerpunkte sind Virtualisierung und Cloud Computing, speziell VMware, Amazon Web Services, Google Cloud und Microsoft Azure. Thomas ist zertifizierter VMware Professional, Advanced Professional und wurde von VMware in den Jahren 2016, 2017, 2018, 2019 und 2020 mit dem Blogger-Status vExpert ausgezeichnet.

Thomas ist außerdem zertifizierter AWS Solutions Architect, Sysops Engineer und Devops Engineer sowie Microsoft Certified Azure Administrator.

Thomas führt aktuell jeden zweiten Montag einen 4-tägigen Grundlagenkurs in Cloud Computing mit AWS via Zoom-Meeting durch. Weitere Informationen und Anmeldung über sein AWS-Blog.