Info2soft verwendet Cookies, um Ihnen ein besseres und angenehmeres Surferlebnis auf unserer Website zu ermöglichen. Datenschutzerklärung
Wird geladen...
Von:
Die Warnung „Log Disk Exhaustion“ bedeutet, dass die Partition /storage/log auf Ihrer vCenter Server Appliance (VCSA) nahezu vollständig belegt ist – in der Regel ab einer Auslastung von 75 %. Auf dieser Partition werden Protokolle aller zentralen vCenter-Dienste gespeichert, darunter SSO, der VMware-Verzeichnisdienst sowie vpxd.
Sobald die Partition vollständig belegt ist, stoppt vCenter das Schreiben von Protokollen und schaltet kritische Dienste ab, um Datenbeschädigungen zu vermeiden. Der Zugriff auf den vSphere-Client geht verloren und Sie können Ihre ESXi-Hosts nicht mehr verwalten, bis Speicherplatz freigegeben oder die Partition vergrößert wurde.
Die Ermittlung der Quelle des Speicheraufwuchses ist der erste Schritt zur dauerhaften Behebung. Im Folgenden die sechs häufigsten Gründe für eine überfüllte /storage/log-Partition:
Bei vCenter 7.0 und 8.0 liegt ein bekannter Fehler im VMware Authentication Framework Daemon (vmafdd) vor.
Ein Registrierungskonflikt bewirkt, dass der Dienst die Regeln für die Protokollrotation ignoriert. Dadurch entsteht eine einzelne riesige Protokolldatei, die die gesamte Partition belegen kann.
In vCenter 8.0-Versionen vor Update 3 werden zur Fehleranalyse erstellte Support-Bundles teilweise nicht automatisch entfernt. Diese Bundles sind große komprimierte Dateien, die bei Anhäufung schnell eine volle Log-Partition auf der VCSA verursachen.
In vCenter 7.0-Umgebungen vor Update 3c kann ein Zertifikatvalidierungsfehler eine endlose Protokollschleife auslösen. Das System erstellt wiederholt pod-startup.log-Dateien und füllt den Datenträger rasch mit redundanten Fehlermeldungen.
In Umgebungen mit hohem Datenverkehr oder häufigen API-Aufrufen wachsen die Dateien localhost_access.log und catalina.log stark an.
Diese befinden sich in den Verzeichnissen des Single Sign-On (SSO) und des Lookup-Dienstes. Bei älteren Versionen von 6.x und 7.x funktioniert deren automatische Rotation teilweise nicht ordnungsgemäß.
Die standardmäßig zugewiesenen 10 GB für /storage/log reichen oft nicht für große Umgebungen mit Hunderten von Hosts oder Tausenden von virtuellen Maschinen aus. Hoher Protokollierungsgrad oder häufige Objektänderungen lassen den Speicherbedarf schneller als erwartet ansteigen.
vCenter nutzt eine integrierte PostgreSQL-Datenbank zur Speicherung von Inventar- und Konfigurationsdaten. Bei Umgebungen mit STIG-Härtung wird ggf. pgaudit für diese Datenbank aktiviert.
Bei fehlerhafter Konfiguration wird jede Datenbanktransaktion protokolliert, wodurch die Log-Partition extrem schnell belegt wird.
Bevor Sie Dateien löschen oder Datenträger vergrößern, ermitteln Sie genau, welche Dateien den Speicher belegen. Handlungen ohne klare Diagnose riskieren das Entfernen kritischer Systemdaten oder das Übersehen eines wiederkehrenden zugrundeliegenden Fehlers.
Erstellen Sie vor allen Datenträgeroperationen oder Dateilöschungen einen VM-Snapshot oder ein aktuelles Backup der VCSA. Das Ändern von Datenträgergrößen ohne Sicherung kann eine Beschädigung der Partitionstabelle zur Folge haben und die VCSA unbootbar machen. Wenn vCenter Teil einer Linked-Mode-Gruppe ist, prüfen Sie vor dem Vorgehen die Auswirkungen einer Wiederherstellung.
Falls die Benutzeroberfläche noch erreichbar ist, melden Sie sich über die vCenter Appliance Management Interface (VAMI) unter https://<vcenter-fqdn>:5480 an.
/storage/log. Ein kritischer Gesundheitsstatus oder eine Auslastung über 75 % bestätigt die Warnung.Falls die VAMI nicht reagiert, melden Sie sich per SSH als Benutzer root an der VCSA an. Wenn Sie die Appliance-Shell öffnen, geben Sie shell ein, um zur Bash-Oberfläche zu wechseln.
Führen Sie folgenden Befehl aus, um die Datenträgerauslastung in leserlichem Format anzuzeigen:
df -h
Um nur Partitionen mit einer Auslastung über 78 % anzuzeigen, führen Sie aus:
df -h | awk '0+$5 >= 78 {print}'
Nachdem bestätigt wurde, dass /storage/log das Problem darstellt, führen Sie diesen Befehl aus, um die 20 größten Dateien und Verzeichnisse aufzulisten:
du -ah /storage/log/ | sort -h -r | head -n 20
Achten Sie auf ungewöhnlich große Dateien (mehrere GB) oder eine hohe Anzahl kleiner, wiederholter Protokolldateien.
-h bei sort wird nicht von allen VCSA-Versionen unterstützt. Bei einem Befehlsfehler verwenden Sie stattdessen sort -r und vergleichen die Rohbyte-Werte.Eine Partition kann als voll angezeigt werden, obwohl noch freier Speicher vorhanden ist. Dies tritt auf, wenn die Partition keine Inodes mehr hat – das sind Indexknoten, die das Dateisystem zur Verwaltung einzelner Dateien nutzt. Millionen kleiner Protokolldateien können Inodes aufbrauchen, ohne den Datenträger nach Größe zu füllen.
Prüfen Sie die Inode-Auslastung mit folgendem Befehl:
df -i
Wenn der Wert IUse% bei /storage/log bei 100 % oder nahe 100 % liegt, ist eine Inode-Erschöpfung die wahrscheinliche Ursache.
Wenn Schritt 4 eine hohe Inode-Auslastung ergab, führen Sie diesen Befehl aus, um das Verzeichnis mit den meisten Dateien zu finden:
find /storage/log -type d -exec sh -c "echo -n '{}: '; ls -1 '{}' | wc -l" \; | sort -n -k 2
Nach Ermittlung der Ursache können Sie das Problem entweder durch das Bereinigen unnötiger Protokolldaten oder das Erweitern des verfügbaren Speichers beheben. Wählen Sie die Methode entsprechend Ihren Diagnoseergebnissen aus.
Viele Fälle einer vollen Log-Partition bei vCenter 7 und 8 gehen auf Softwarefehler zurück, die eine korrekte Rotation oder Kompression von Protokollen verhindern. Prüfen Sie vor dem weiteren Vorgehen die nachfolgende Tabelle – falls Ihre Version einem bekannten Fehler entspricht, wenden Sie zuerst die passende Lösung an.
| vCenter-Version | Bekannter Fehler | Lösung |
|---|---|---|
| vCenter 6.0 vor U3 | Rotation von cloudvm-ram-size.log defekt | Aktualisierung auf die aktuelle 6.0/6.5-Version |
| vCenter 7.0 vor U1 | SSO-Protokolle werden nicht komprimiert | Aktualisierung auf 7.0 U1 oder neuer |
| vCenter 7.0 vor U3c | Endloswachstum von pod-startup.log | KB-Lösung oder Aktualisierung auf 7.0 U3c |
| vCenter 7.0 / 8.0 vor U1 | Registrierungskonflikt bei vmafdd.log | Registrierungsfix (KB 318575) |
| vCenter 8.0 vor U3 | Support-Bundles werden nicht automatisch gelöscht | Manuelle Bereinigung oder Aktualisierung auf 8.0 U3 |
Diese Methode verschafft sofort Abhilfe durch das Entfernen alter rotierter Protokollarchive. Löschen Sie ausschließlich komprimierte oder nummerierte Archivdateien mit den Endungen .gz, .zip oder .log.1. Aktive Protokolldateien mit der Endung .log dürfen nicht gelöscht werden.
find /storage/log -name "*.gz" -mtime +7 -type f -delete
du-Ausgabe Ihrer Diagnose große Dateien unter /storage/log/vc-support-bundles/ anzeigt, entfernen Sie diese mit folgendem Befehl:rm -rf /storage/log/vc-support-bundles/*
service-control --stop --all && service-control --start --all
.gz-Dateien manuell, bis die Auslastung unter 95 % sinkt, und versuchen Sie es erneut.Wenn die Umgebung die standardmäßigen 10 GB Kapazität überholt hat, ist die Erweiterung des virtuellen Datenträgers die dauerhaftere Lösung.
/storage/log. Bestätigen Sie dies aber vor Änderungen über die VAMI oder per Befehl lsblk in der Shell./usr/lib/applmgmt/support/scripts/autogrow.shdf -h aus, um zu bestätigen, dass /storage/log die neue Größe anzeigt.
Ein VM-Snapshot ist ein erster Sicherungsschritt, ersetzt aber kein ordnungsgemäßes Backup. Snapshots werden auf demselben Datastore wie die VCSA gespeichert und können durch dieselben Speicherprobleme ungültig werden, die Sie beheben möchten. Für eine produktive vCenter-Umgebung bietet eine dedizierte Backup-Lösung einen zuverlässigen, unabhängigen Wiederherstellungspunkt, bevor Sie Datenträger oder Dateien verändern.
i2Backup ist eine Enterprise-Backup-Lösung, die agentenlose Sicherungen von VMware-VMs über native Virtualisierungs-APIs unterstützt – ohne Installation von Agents auf der VCSA selbst.
Bevor Sie fortfahren
Erstellen Sie vor jeder Datenträgervergrößerung oder Dateilöschung ein vollständiges Backup der VCSA mit der Lösung Info2soft i2Backup. Sollte während der Reparatur ein Fehler auftreten, entscheidet ein sauberer Wiederherstellungspunkt über eine schnelle Wiederherstellung oder einen kompletten Neuaufbau von vCenter.
F1: Ist das Löschen von Dateien in /storage/log sicher?
Das hängt von den Dateien ab. Komprimierte Archivdateien mit den Endungen .gz, .zip oder .log.1 können bedenkenlos entfernt werden. Aktive Protokolldateien mit Endung .log dürfen nicht angefasst werden – deren Löschung kann laufende Dienste stören oder unvorhersehbares Verhalten von vCenter verursachen.
F2: Kann ich Log Disk Exhaustion ohne SSH-Zugriff beheben?
In den meisten Fällen nein. Die VAMI zeigt zwar die Datenträgerauslastung an, bietet aber keine Werkzeuge zum Löschen von Protokolldateien oder direkten Vergrößern von Partitionen.
SSH-Zugriff ist für die in diesem Leitfaden beschriebenen Bereinigungs- und Erweiterungsschritte erforderlich. Falls SSH deaktiviert ist, aktivieren Sie es vor dem Vorgehen vorübergehend über die VAMI unter Zugriff > Bearbeiten.
F3: Was ist der Unterschied zwischen Log-Datenträger- und SEAT-Datenträger-Erschöpfung?
Die Partition /storage/log speichert Dienstprotokolle aller vCenter-Komponenten. Der SEAT-Datenträger (Statistics, Events, Alarms, and Tasks), üblicherweise /storage/seat, speichert historische Leistungsdaten und Ereignisprotokolle.
Beide können unabhängig voneinander voll laufen. Die Symptome sehen ähnlich aus, die Lösungen zielen aber auf unterschiedliche Partitionen und Dateisätze ab.
F4: Warum ist /storage/archive immer zu 100 % belegt? Ist das normal?
Ja. Die Partition /storage/archive ist dafür ausgelegt, mit einer Auslastung von nahezu 100 % zu arbeiten. vCenter nutzt sie als Zwischenspeicher für Protokollarchive und verwaltet deren Inhalt automatisch. Eine volle /storage/archive löst keine Warnung aus und erfordert keine Maßnahmen.
F5: Verursacht die Datenträgererweiterung Ausfallzeit?
Die VCSA unterstützt das Hot-Resize von Datenträgern, Sie können die Größe des virtuellen Datenträgers also ohne Herunterfahren der Appliance erhöhen. Ausfallzeit kann trotzdem auftreten, wenn die Partition bereits vollständig belegt ist und Dienste abgeschaltet wurden.
In diesem Fall befreien Sie zuerst ausreichend Speicherplatz mit Methode 1, bevor Sie die Erweiterung durchführen.
F6: Was tun, wenn vCenter bereits nicht erreichbar ist (503-Fehler)?
Wenn der vSphere-Client einen 503-Fehler zurückgibt und SSH nicht reagiert, hat die Appliance aufgrund des vollen Datenträgers die meisten Dienste angehalten. Greifen Sie direkt über die VM-Konsole auf der ESXi-Host-Ebene auf die VCSA zu (ohne Umweg über vCenter), indem Sie Ihren vSphere-Client direkt mit der IP des ESXi-Hosts verbinden.
Melden Sie sich über die Konsole an, befreien Sie Speicherplatz durch das Löschen von .gz-Dateien und starten Sie anschließend die Dienste mit service-control –start –all neu. Ist der Datenträger zu voll, um Schreibvorgänge auszuführen, müssen Sie die VMDK-Datei auf ESXi-Ebene vergrößern, bevor sich die Appliance wiederherstellen kann.
Eine volle Log-Partition bei vCenter ist behebbar, erfordert aber schnelles Handeln. Eine vollständig belegte /storage/log schaltet Ihre gesamte Verwaltungsebene ab – auch wenn Ihre virtuellen Maschinen weiterlaufen.
Die Lösung folgt einer einfachen Reihenfolge: Erstellen Sie ein Backup, ermitteln Sie die speicherbelegenden Dateien, prüfen Sie, ob ein versionsspezifischer bekannter Fehler auf Ihre Umgebung zutrifft, und bereinigen Sie anschließend entweder die Protokolldateien oder erweitern Sie die Partition. Für Umgebungen, die die standardmäßigen 10 GB überholt haben, ist die Datenträgererweiterung die dauerhaftere Lösung.
Nach Behebung des Problems empfehlen wir die Einrichtung eines regelmäßigen Backup-Zeitplans für die VCSA mit einem dedizierten Tool wie i2Backup. Dadurch verfügen Sie stets über einen sauberen Wiederherstellungspunkt vor Ihrem nächsten Wartungsfenster.
