vCenter warten: vpx-Daten-Provider zurücksetzen, Coredumps und Logs löschen

    ESXi PSODEin über­mäßiges An­wachsen der Daten­bank kann nega­tive Folgen im Betrieb und bei der Mig­ration von vCenter haben. Mit dem Reset der vpx-Provider lässt sich aber nicht nur die Inventory-Daten­bank be­reinigen, viel­mehr kann diese Maß­nahme auch andere Pro­bleme mit vCenter und dem Web Client beheben.

    Wenn das Daten­volumen auf einem vCenter-Server reduziert werden muss, dann kann dies mehrere Gründe haben:

    • Allgemein sehr große Tabellen in der vCenter Server-Datenbank
    • die Inventory Service Datenbank
    • Core Dumps
    • Logging

    Ich habe bereits in einem eigenen Beitrag beschrieben, wie man Tasks, Events und historische Performance-Daten mit einem SQL-Client selektiv bereinigt. Darüber hinaus kann und muss man sich noch Gedanken um die Datenbank des Inventory Service sowie das Speichern von Coredumps und Log-Dateien machen.

    vpx-Datenprovider zurücksetzen

    Um die Größe der Datenbank für den Inventory Service zu reduzieren, ist ein Rücksetzen der vpx-Daten-Provider erforderlich.

    Diese Maßnahme kann übrigens auch dann erforderlich sein, wenn

    • sich die Objekte im vSphere Web Client oder vSphere Client nicht nach vCenter Server durchsuchen lassen
    • das Inventar im vSphere Web Client überhaupt nicht mehr angezeigt wird
    • der Hardware-Überwachungs­dienst auf dem Host nicht ver­fügbar ist oder nicht antwortet

    Mit Version 6.0 hat VMware die Möglich­keit eingeführt, auch einzelne Provider zurück­zusetzen, die in der Datenbank des Inventory Service (xDB) gespeichert sind. Dies ist im Vergleich zur Version 5.x, bei der man in jedem Fall die gesamte Datenbank zurücksetzen musste, weniger aufwändig.

    Die neue Methode stellt außerdem sicher, dass Tags, Speicherprofile, Speicher­richtlinien und Ver­knüpfungen von vCenter Site Recovery Manager oder vCloud Director intakt bleiben. Allerdings kann es nach dem Reset der Provider bei der Synchro­nisierung von Objekten zu einer merklichen Ver­zögerung bei der Weiter­gabe von Inhalten im vSphere Web Client kommen.

    Das Vorgehen gestaltet sich wie folgt:

    1. Zuerst meldet man sich am als admini­strativer SSO-User am Managed Object Browser unter der URL
      https://<vCenter_Server_FQDN>/invsvc/mob1 an.
    2. Anschließend klickt man unter Methods auf den Link RetrieveAllProviderConfigs und dann im sich öffnenden Popup auf Invoke Method. Hier sucht man dann die ProviderUuid des zurück­zu­setzenden Daten-Providers, wozu man die Tabelle unter dem Abschnitt Additional Information ver­wenden kann.
    3. Dann kopiert man die ein­deutige Zeichen­folge für die ProviderUuid in die Zwischen­ablage und schließt das Popup-Fenster wieder.
    4. Danach kehrt man zurück zu
      https://<vCenter_Server_FQDN>/invsvc/mob1
      und klickt auf den Link ResetProviderContent unter Methods
    5. und fügt im sich öffnenden Dialog die kopierte UUID ein. Dann klickt man zum Schluss auf Invoke Method.

    Coredumps und Dump-Collector

    Coredumps und Log-Dateien belegen zwar keinen Daten­bankspeicher, aber abhängig von den konfigurierten Pfaden für temporäre Daten mitunter Festplattenplatz auf der Appliance. Das kann wiederum zulasten des Speicher­platzes für die Datenbank gehen und ebenfalls die skizzierten Probleme verursachen.

    Um zu verstehen, inwieweit Coredumps von ESXi ein vCenter betreffen, ist etwas Hinter­grund­wissen erforderlich. Der VMware vSphere Network Dump Collector ermöglicht es einem Host, Diagnose­informa­tionen über das Netzwerk an einen Remote-netdump-Dienst zu übertragen, der sie dann seinerseits auf einem ihm zugäng­lichen Datenträger speichert.

    Coredumps mit vSphere Dump-Collector auf Remote-Hosts speichern

    Die Netzwerk-­basierte Coredump-Collection kann zusätzlich zur oder anstelle der standardmäßig vorhandenen Coredump-Collection  konfiguriert werden, welche die Daten auf lokalen Festplatten der ESXi-Hosts speichert.

    Dies kann in zustands­losen Umgebungen nützlich sein, in denen keine lokalen Festplatten für eine Diagnose-Partition existieren, etwa wenn ESXi-Hosts mittels Auto-Deploy über das Netz booten oder von einem USB-Stick starten.

    Der vSphere ESXi Dump Collector-Dienst (für die Remote-Collection von Coredumps) ist in zwei Darreichungs­formen verfügbar: Er wird entweder am selben Speicherort wie der vSphere vCenter Server für Windows installiert oder kann bei der Installation von vCenter Server in diesen integriert werden. In der vCenter Server Virtual Appliance (vCSA) ist der vSphere ESXi Dump Collector als Dienst standard­mäßig vorhanden und muss nur aktiviert werden.

    Unter Windows werden IP-Adresse und Portnummer des Dump Collector-Servers im Dump Collector vCenter Server-Plug-in angezeigt, allerdings nicht bei einer eigenständigen Installation von vSphere Dump.

    Um einen ESXi-Host zu überreden, Coredumps an einen als Remote-Collector konfigurierten vCenter-Server zu übermitteln, kann man SSH oder die ESXui-Shell bemühen und das Kommando

    esxcli system syslog config set –loghost <vCenter>

    absetzen, was in der Regel schneller erledigt ist, als das Installieren der vCLI.

    Coredumps werden standardmäßig unter /storage/core  gespeichert.

    Coredump-Files werden dann unter /storage/core abgelegt, von wo ist sich dann ggf. auch mittels SSH/Bash oder einer direkten Shell-Anmeldung an vCenter bzw. einem grafischen Client wie winscp entfernen lassen.

    Wenn man Log-Dateien löschen möchte, dann finden sich diese unter /var/log/vmware

    Log-Dateien hingegen werden bei der vCenter-Appliance unter /var/log/vmware bzw. den darin befindlichen dienst­spezifischen Unter­verzeichnissen gespeichert. Neben dem Bereinigen der genannten Orte kann es eventuell nützlich sind, die Log-Rotation den eigenen Bedürfnissen anzupassen.

    Keine Kommentare