DevOps

VMware vCenter-Störung dank voller Festplatte und LDAP

Durch eine Verkettung unglücklicher Zustände war bei einem unserer Kunden der zugrundeliegende Speicher der vCenter-Appliance zu 100% gefüllt. Dies wiederum hat dazu geführt, dass das vCenter sowie der vSphere Webclient nicht mehr reagierten.

Der perfekte Start in einen Montagmorgen.

Nachdem unsere Überwachung uns auf den vollen Speicher hingewiesen hatte, standen bereits alle virtuellen Maschinen, die auf dem Speicher liefen, still. Zuerst wurde also der verfügbare Speicher erhöht. Die vCenter-Appliance war leider nicht wieder automatisch verfügbar, also musste sie über den VM-Host neugestartet werden.

Nach dem Neustart war zumindest der Vsphere Webclient wieder verfügbar, es wurden aber keine VMs oder Storages gefunden. Auch gab es eine prominente Fehlermeldung im Frontend, die anzeigte, dass noch nicht alles wieder stimmte:

Es konnte keine Verbindung zu einem oder mehreren vCenter Server-Systemen hergestellt werden: https://192.168.100.10:443/sdk

Ein Blick in das Frontend der VMWare vCenter Server Appliance zeigte schnell das Problem:

vcenter_server_appliance

Der vCenter Server lief nicht und er ließ sich auch nicht starten.

Zumindest war die Appliance per SSH erreichbar, so konnten wir in den diversen Logfiles der Appliance nach Anhaltspunkten suchen, warum sie nicht startete. Nach kurzer Zeit wurden wir auch fündig, ein Backtrace im vpxd-Log:

Die Meldung deutete auf ein Problem im internen LDAP-Server hin. Aufgrund der SSL-Meldungen vermuteten wir, dass Zertifikat könnte abgelaufen sein. Dem war jedoch nicht so.

Der nächste Schritt war, in den LDAP-Logfiles nach Fehlern zu suchen. In den ldapmessages hatten wir unseren nächsten Anhaltspunkt:

Anscheinend wurde die LDAP-Datenbank beim Volllaufen der Festplatte korrumpiert.

Um die Datenbank wieder in einen konsistenten Zustand zu bringen, haben wir sie zuerst gestoppt. Dann konnten wir mittels slapcat einen Dump der Daten erstellen, welchen wir mittels slapadd wieder eingespielt haben. Dann kam der spannende Moment: Würde die Datenbank nach dem Einspielen sauber und ohne Fehler hochfahren? Ergebnis: ja, tat sie!

Die technische Umsetzung sieht wie folgt aus:

Nachdem die Datenbank repariert wurde, startete das vCenter ebenfalls erfolgreich und der Montag gerettet.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.