vCenter-Datenbank bereinigen: Tasks, Events und Performance-Daten löschen

Eine über­volle Daten­bank kann die Dienste von vCenter erheb­lich beein­trächtigen. Idealer­weise beugt man dem über­mäßigen Anwachsen des Daten­volumens durch ent­sprechende Maß­nahmen vor. Wenn dieser Fall aber trotz­dem ein­tritt, dann lässt sich die Daten­bank mit Hilfe von VMware-eigenen Scripts be­reinigen.

Bei der Bereitstellung des vCSA kann es zu Problemen kommen, wenn die Datenbank des Quell-Systems zu groß ist. Ein Symptom beim vCSA-Upgrade besteht dann darin, dass die die Tiny- oder Small-Konfiguration für die Ziel-Appliance nicht angeboten wird. Das Gleiche kann auch bei der Migration von einem Windows-vCenter passieren. In beiden Fällen ist ein Bereinigen der Quell-vCSA notwendig

Zu viele historische Daten

Als Problem erweist sich in der Regel eine zu große Menge von histo­rischen Daten, etwa für Ereignisse, Aufgaben oder Statistiken. Sind die Protokoll­daten in der vCenter Server-Datenbank zu umfang­reich, dann wird der vCenter Server-Dienst möglicher­weise gar nicht gestartet.

VMware empfiehlt daher, historische Datensätze selektiv zu bereinigen, und stellt dazu passende SQL-Scripte für den jeweiligen Datenbanktyp (SQL Server, Oracle, PostgresQL) zum Download  bereit.

Datenbank sichern

Für die vCenter-Appliance 6.0 geht man dazu wie folgt vor. Zunächst stoppt man den Center-Server an der Appliance-Shell mittels:

service-control --stop vmware-vpxd

Danach empfiehlt es sich, die komplette Quell­daten­bank zu sichern. Hierzu bietet VMware ein passendes Backup-Tool für Windows vCenter sowie die Appliance in Form einer ZIP-Datei zum Download an, hier die Linux-Variante. Diese speichert und entpackt man in einem beschreib­baren Verzeichnis, etwa in /tmp.

Danach macht das darin enthaltene Python-Programm backup_lin.py ausführbar:

chmod 700 /tmp/backup_lin.py

Dieses lässt man dann laufen und gibt als Ziel eine Backup-Datei an, zum Beispiel

python /tmp/backup_lin.py -f /tmp/backup_VCDB.bak

Das zugehörige Restore-Script liegt für alle Fälle im gleichen Pfad. In der Praxis würde man vermutlich aber eher einen externen Pfad für die Backup-Datei wählen, schon um etwaigen Problemen mit der Festplatten­größe aus dem Weg zu gehen.

Datensätze mit SQL-Scripts löschen

Nun ist es gefahrlos möglich, die Daten­bereinigung mit Hilfe der von VMware bereit­gestellten SQL-Scripts auszu­probieren, hier am Beispiel von PostgresQL. Das zugehörige Script findet sich hier.

Die SQL-Scripts von VMware  enthalten drei Hauptparameter:

TaskMaxAgeInDays: Alle Aufgaben (Tasks), die älter sind als der Tag TaskMaxAgeInDays“, werden gelöscht.

EventMaxAgeInDays: Alle Ereignisse, die älter als EventMaxAgeInDays sind, werden gelöscht.

StatMaxAgeInDays: Alle Statistiken, die älter als StatMaxAgeInDays sind, werden gelöscht.

Die möglichen Werte sind:

Zum Ausführen des Scripts braucht man den psql-Client. Hier übergeben wir gleich alle drei Parameter:

/opt/vmware/vpostgres/current/bin/psql -U <vCenter-Server-database-user> -v TaskMaxAgeInDays=task-days -v EventMaxAgeInDays=event-days-v StatMaxAgeInDays=stat-days -d <database-name> -t -q -f <download-path/>2110031_Postgres_task_event_stat.sql

Passwort für die Datenbank auslesen

Um das Kommando ausführen zu können, bedarf es außerdem der Datenbank-Credentials. Hierzu sucht man (als User root) die Datei vcdb.properties (in der Regel unter /etc/vmware-vpx) und öffnet sie in einem Texteditor oder schaut einfach mit less oder cat hinein. Das File enthält das Password für den Database-User (vc).

Man kann durch die Kombination mit grep und awk auch direkt das Password extrahieren:

cat /etc/vmware-vpx/vcdb.properties | grep "password =" | awk '{print $3}'

Den Datenbank­namen (in der Regel VCDB) bekommt man durch Blick in die Datei /etc/vmware-vpx/embedded_db.cfg heraus:

cat /etc/vmware-vpx/embedded_db.cfg

Danach steht einem Test der Bereinigung nichts im Wege:

/opt/vmware/vpostgres/current/bin/psql -U vc -v TaskMaxAgeInDay=10 -v EventMaxAgeInDays=10 -v StatMaxDaysInDays=10 -d VCDB -t -q -f /tmp/2110031_Postgres_task_event_stat.sql

Abschließend kann man den vpxd-Daemon wieder starten:

service-control –start vmware-vpxd