Das gewisse Extra oder die Dashboards des vCenter Operations Managers
Zielsetzung des zweiten Teil der Reihe zur vCenter Operations Management Suite ist es zu verdeutlichen, wie wir unsere Virtualisierungs-Umgebung besser verstehen lernen. Das dabei kennengelernte Konzept ermöglicht es uns Ansätze zu finden, wie wir in ein Trouble Shooting einsteigen können.
Wir werden uns also erst mal auf das Produkt vCenter Operations Manager, nachfolgend vCOPS genannt, fokussieren und lernen wie eine Fülle von Informationen und Daten in einem einzigen Dashboard vereint einen Single View of Operations bereitstellt. Hierdurch haben wir alle wichtigen Informationen wie Performance, Kapazität und Konfiguration auf einen Blick.
Öffnen wir vCOPS, so erhalten wir das nachfolgende Bild, den sog. Single View of Operations.Dashboards
Nachfolgend werden wir uns die Konzepte, die hinter den Dashboards stehen ansehen und besprechen die Zahlen und Grafiken die angeboten werden. Ergänzend sei noch erwähnt, dass diese Dashboard Ansicht, die hier beschrieben wird erst ab der Standard Edition von vCOPS verfügbar ist. Grundlegend ist das Dashboard von vCOPS in drei Spalten untergliedert, die mit Systemzustand, Risiko und Effizienz betitelt sind. Gehen wir diese der Reihe nach einmal durch.
Die linke Spalte, als SYSTEMZUSTAND bezeichnet (engl. HEALTH), informiert uns über aktuelle unmittelbare Probleme der virtuellen Infrastruktur. Hier finden wir alle Komponenten, die unserer unmittelbaren Aufmerksamkeit bedürfen weil Sie bereits zu einem Problem geworden sind oder dies gerade beginnen zu werden.
Die mittlere Spalte , als RISIKO bezeichnet (engl. RISK), informiert uns über bevorstehende in der Zukunft liegende Ereignisse. In diesem Bereich haben wir keinen akuten Handlungsbedarf und müssen direkt etwas unternehmen vielmehr wird auf Ereignisse hingewiesen die in der nahen Zukunft zu einem Problem führen.
Die rechte Spalte, als EFFIZENZ bezeichnet (engl. EFFICIENCY), informiert uns nicht über Probleme vielmehr zeigt sie uns Möglichkeiten auf wie Ressourcen wieder zurück gewonnen werden können.
Diese drei Spalten sind unsere Hauptkategorien, in der Fachsprache auch Super Metriken genannt, die uns in die Lage versetzen zu verstehen wie es unserer virtuellen Umgebung tickt. Links auftretende Ereignisse sind kritisch und bedürfen einer sofortigen Handlung. Mittig auftretende Ereignisse sind in naher Zukunft ein Problem bedürfen somit keiner sofortigen Handlung. Rechts auftretende Ereignisse ist das sog. Optimierungspotential das uns langfristig interessiert.

Unter dem Systemzustand sehen wir die Kachel WARNUNGSVOLUMEN. Wir sehen das vCOPS Alarme in unterschiedliche Schweregrade einteilt wenn es ein Problem feststellt. Bei unserem System sehen wir das viele rote Alarme vorhanden sind die kritisch sind und somit unsere sofortige Aufmerksamkeit verlangen.
Die Alarme sind auch rechts an der Seite nochmal dargestellt und somit immer in für uns sichtbar. Unten rechts finden wir eine Übersicht die mit UMGEBUNG bezeichnet ist, die alle von vCOPS überwachten Systeme summiert aufzählt.
Das tolle an dieser Dashboard Ansicht ist, das sie für jedes Objekt der Umgebung funktioniert. Unser Ausgangspunkt war WORLD d.h. die gesamte Umgebung. Wir können uns aber auch weiter nach unten durchklicken und so diese Ansicht für jedes Objekt erhalten. Klicken wir also auf ein Objekt weiter unten, so wird die Dashboard Ansicht nach einem Reload für dieses Objekt angezeigt.
Schauen wir uns den SYSTEMZUSTAND mal genauer an. Er bildet quasi unsere Wetterkarte für das von uns ausgewählte Objekt und alle dazu gehörigen Child-Objekte.
Fahren wir mit der Maus über diese Wetterkarte, so erhalten wir weitere Detailinformationen zu dem jeweiligen Objekt. In diesem Beispiel die LUN mit dem Namen ESX_LAB_LUN1, die einen Systemzustand von 71 und eine Arbeitslast von 52 hat sowie 16 Anomalien aufweist.
Außerdem wird der Systemzustand der Objekte rückwirkend für die letzten 6 Stunden anzeigt. Klicken wir z.B. auf die grau hinterlegte -1 unter der Wetterkarte, so wird der Systemzustand von vor einer Stunde angezeigt (Bild links).
Wir könnten auch einfach auf eines der Objekte klicken um weitere detailliertere Informationen zu erhalten.
Systemzustand
Haben wir ein Problem im Bereich SYSTEMZUSTAND festgestellt, so klicken wir auf den Pfeil neben „Warum ist der Systemzustand XX?“ und erhalten folgende weiteren Detail-Informationen zu unserem ausgewählten System und können mit dem Trouble Shooting beginnen.
Unsere Supermetrik SYSTEMZUSTAND ist gelb, sie wird aus den folgenden Metriken bestimmt. Die erste dieser drei den Systemzustand bestimmenden Kategorien ist die ARBEITSLAST (engl. WORKLOAD). Arbeitslast ist ein Teil im Bereich Performance und ermittelt wie stark ist das Objekt belastet oder am Arbeiten ist. In unserem Beispiel ist die CPU also auch die Platten-E/A und der Netzwerk E/A verhältnismäßig gering im Vergleich zur Belastung des Arbeitsspeichers.
Die nächste Kategorie sind die ANOMALIEN (engl. ANOMALIES) d.h. wie normal bzw. unnormal verhält sich das ausgewählte Objekt. Wir sehen auch den ermittelten Problemschwellenwert von 100, der das sog. Grundrauschen des Rechenzentrums für dieses Objekt berücksichtigt.
Zu guter Letzt haben wir noch die Kategorie FEHLER (engl. FAULTS) die Informationen über Verfügbarkeits- und Konfigurationsprobleme liefert.
Zusammenfassend lässt sich festhalten. Anomalien und Arbeitslast sind mehr in den Bereich der Performance einzuordnen. Fehler hingegen sind Probleme die auf verlorene Redundanzen von Komponenten (Netzwerkkarte, SAN etc.) hinweisen oder einfach ein Konfigurationsproblem vorliegt das wir umgehend beheben sollten.
Risiko
Schauen wir uns den Bereich RISIKO an und klappen die Unterkategorien auf so sehen wir hier 3 Stück, Verbleibende Zeit, Verbleibende Kapazität und Stress (in der Enterprise Edition finden wir hier noch Compliance).
VERBLEIBENDE ZEIT (engl. Time Remaining) gibt an wie viel Zeit verbleibt bis alle Ressourcen verbraucht sind.
In diesem Beispiel steht bereits kein Speicherplatz und Arbeitsspeicher mehr zur Verfügung. Hingegen sind noch für 132 Tage (von heute an gerechnet) CPU-Ressourcen verfügbar und die Kapazität im Bereich Netzwerk respektive die Platten-E/A ist noch für mehr als 1 Jahr ausreichend. Dies führt jedoch zum Ergebnis das noch 0 Tage Ressourcen zur Verfügung stehen und somit zum Status Rot für die verbleibende Zeit.
VERBLEIBENDE KAPAZITÄT (engl. Remaining Capacity) zeigt uns wie viele VMs bereitgestellt sind und wie viel davon eingeschaltet.
Wir bereits 12 VMs mehr bereitgestellt als wir Ressourcen zur Verfügung haben. Der dunkelblaue Balken zeigt dass die Ressourcen der virtuellen Infrastruktur zu 100% vergeben sind.
BELASTUNG (engl. Stress) ist ähnlich wie die im Bereich des Systemzustandes vorhandene Arbeitslast. Der Unterschied ist jedoch in der zeitlichen Perspektive zu finden d.h. Belastung ist die Arbeitslast über einen längeren Zeitraum. Arbeitslast ist eine aktuelle Aufnahme (jetzt und nicht vor einer Woche) über den Zustand des Objekts. Hierüber können wir auch sog. Hotspots erkennen die in den letzten Wochen auftreten und wir sehen auch wann diese auftreten.
In diesem Beispiel sehen wir einen Hotspot für den kommenden Freitag gegen 12 Uhr und einen regelmäßig Nachts zwischen 21 und 22 Uhr auftretenden Hotspot. Hierüber haben wir einen weiteren Ansatz in ein Trouble Shooting einzusteigen.
Effizienz
Zu guter Letzt den Bereich EFFIZENZ, der sich durch die Unterkategorien Zurückgewinnbare Verschwendung und der Dichte ermittelt. Wir erinnern uns dass die Effizienz eine Größe ist, die zurückgewinnbare Ressourcen aufzeigt und uns somit Geld einsparen hilft. In unserem Beispiel sehen wir das 97% der Ressourcen verschwendet werden. Welche das konkret sind erfahren wir in den folgenden Metriken.
Die Unterkategorie ZURÜCKGEWINNBARE VERSCHWENDUNG (engl. Reclaimable Waiste) zeigt dass 16% der VMs im Leerlauf sind, 31% ausgeschaltet und 53% sind überdimensioniert. All dies bietet uns die Möglichkeit Ressourcen zurückzugewinnen und diese anders nutzbar zu machen.
Das Potential beläuft sich in unserem Beispiel auf 29 vCPUs, 1.2 TB Festplattenplatz und fast 74 GB Arbeitsspeicher. Rechnen wir das in Physik um, so ist das ein Server mit 2 CPUs, 74 GB RAM und eine kleine Storage Box mit 1.2 TB also rund 50.000 Euro.
Die Unterkategorie DICHTE (engl. Density) ist ein Wert für die Konsolidierungsrate unseres Systems und gibt eine Empfehlung in Bezug auf das mögliche Optimum.
Sind wir unter dem Optimalen Wert wie im Beispiel des VM pro Host Verhältnis so können wir mehr VMs pro Host provisionieren und somit physikalische Server einsparen. Dasselbe Bild zeigt sich für das Verhältnis von vCPU zu pCPU dessen Wert auch deutlich unter dem Optimal Wert liegt. Für den Arbeitsspeicher gilt entsprechendes.