vROps 8.2 mit Management Pack for vCloud Director 5.4.0 führt zu CPU Peaks

Ein Update vom Managment Pack for vCloud Director hat fatale Folgen.

Nach dem Update von vROps auf Version 8.2 und dem Management Pack for vCloud Director stieg plötzlich die CPU Last auf den einzelnen Zellen an. Das führte auch dazu, dass die Performance des WebInterface massiv schlechter wurde.

Nach dem deaktivieren der VCD-Connectoren nahm diese wieder merklich ab.

An der roten Linie erkennt man den Zeitpunkt, an dem der Connector für diese Zelle deaktiviert wurde und das Verhalten nach dem deaktivieren. Der Fall ist bei VMware aktuell in der Überprüfung, da scheint mit dem letzten Managment Packet irgendwas nicht ganz sauber zu laufen, oder es wird eine Metrik neu abgefragt, die den VMware Cloud Director dermassen lange beschäftig, dass dieser blockiert.

Sobald hier mehr Infos vorhanden sind, versuche ich die zu teilen. Bis dahin ist ein downgrade ratsam oder das deaktivieren des Connectors.

Ein Vacum der DB war zwar wieder einmal gut für die allgemeine Performance, aber hat in diesem Fall leider keinen Vorteil erbracht.

Update 1:

Anpassen der Collecting Metrics

VMware hat den Fall adressiert und unter folgendem KB eine mögliche Lösung aufgezeigt:

https://kb.vmware.com/s/article/81977

Wichtig dabei ist zu beachte, dass man zuerst die Änderung auf dem Master Node vornimmt, da dieser die Settings auf den RemoteCollector wieder herunterdrücken kann. Danach wird der Collector-Service neu gestartet und die Änderungen sollten erhalten bleiben.

In meinem Fall hat die Änderung leider nicht wirklich eine Änderung hervorgebracht, der Fall wird nach wie vor bearbeitet.

Update 2:

Erhöhen der vCD Ressourcen

VMware hat nun den Tipp gegeben, man soll in diesem Ausnahmefall die CPU Kapazitäten verdoppeln. Sprich da mehr Ressourcen benötigt werden, soll doch von 4 vCPUs auf 8 vCPUs ausgebaut werden.

Das wurde soweit durchgeführt, aber leider nur mit mässigem Erfolg. Während dem Kollekten schwillt der Wert nach wie vor auf 80 – 100% an.

Update 3:

Verursacher ist das Kollekten der Organization VDC Networks

Nach ein paar Analysen fanden wir heraus, dass das Kollekten eigentlich relativ schnell vonstatten geht, aber sobald in der Datenbanktabelle Zugriffe auf die OrgVDC Networks gemacht wurde, sprang der CPU an die Decke. Die Vermutung, da ist entweder ein API Call nicht ganz sauber implementiert oder in der Datenbank ist eine View nicht ganz ideal hinterlegt. Damit gings zurück an VMware.

Kurz darauf kam die Antwort: Im Adapter unter Advanced das Kollekten der Organization VCD Networks abschalten und das Verhalten prüfen. Tatsächlich, dass Problem war verschwunden.

Da das Problem der VMware Cloud Director beinhaltet, wurde dies an das Entwicklerteam weitergegeben und der Fehler sollte in der Version 10.3 dann auch gefixed worden sein. Bis dahin muss man auf die Metriken einfach verzichten.

Leave a Reply

Your email address will not be published. Required fields are marked *