vSphere Replication mit eigenen Zertifikaten

Der Einsatz von vertrauenswürdigen Zertifikaten für die Absicherung von internen Diensten wird in vielen Unternehmen stark vernachlässigt. Viele Unternehmen setzen sie ausschließlich für extern gehostete Dienste bzw. Dienste, die über die hauseigene DMZ bereitstellt werden, ein. Fragt man nach den Gründen, warum intern genutzte Dienste vernachlässigt werden, wird oft der Aufwand der Implementation und die fehlende Certificate Authority (CA)-Infrastruktur angeführt. Nahezu alle Unternehmen nutzen das Microsoft Active Directory (AD) zur Bereitstellung von Verzeichnisdiensten. Viele wissen jedoch nicht, dass dies die ideale Methode zur Verbreitung von unternehmensweiten Zertifikaten ist. Am Anfang steht jedoch der Aufbau einer internen CA, da die Unternehmen zumeist eigene DNS-Namensräume (Domänen) verwenden bzw. die Kosten alle internen Client/Server mit einem Zertifikat zu versorgen, unterverhältnismäßig sind. Microsoft bietet im Lieferumfang des Windows Server 2008 R2 eine Rolle an mit der sich eine CA betreiben lässt, was somit für fast alle Unternehmen kostenfrei ist. Über das AD kann dann das erstellte Root-CA-Zeritifkat bzw. auch die erstellten Intermediate-CA-Zertifikate an die Client-Truststores ausgerollt werden. Somit sind alle von der Root- oder Intermediate-CA ausgestellten Zertifikate innerhalb des Unternehmens-AD vertrauenswürdig. Für spezielle Dienste wie z. B. das VMware vCenter können dann zusätzlich zu den dann bereits vorhandenen Client-Zertifikat weitere Server-Zertifikate bei der CA beantragt werden. Dies garantiert eine gesicherte Kommunikation auch innerhalb des Unternehmens. Für Server, unabhängig ob physikalisch oder virtuell, die mit Unix/Linux-Derivaten betrieben werden ist ein manueller Import der CA-Zertifikate nötig. So auch bei den Appliances von VMware. Im Fall der vSphere Replication Appliance wird das Root-CA-Zertifikat und ein eventuell vorhandenes Intermediate-CA-Zeritifkat einerseits in den Java-Truststore der Anwendung als auch in den Linux-System-Truststore importiert. Zusätzlich machen wir beide CA-Zertifikate auch dem Webserver für die Managementoberfläche bekannt. 1. Vorbereitungen a) Root-CA-Zertifikat (bspw. “root.crt”) und Intermediate-CA-Zertifikat (bspw. “intermediate.crt”) per SCP auf die vSphere Replication Appliance kopieren b) aus beiden Zertifikaten wird nun eine Zertifikatskette (Chain) erzeugt: 2. Zertifikat in den Java-Truststore von vSphere Replication importieren: 3. Zertifikat in den Linux-Truststore importieren: 4. Zertifikat dem Webserver der Managementoberfläche bekannt machen: Im Anschluss kann das vorbereitete Server-Zertifikat im PFX-Format über die Managementoberfläche https://myreplicationappliance:5480/ > Configuration eingespielt werden.

1. Teil – vCenter Dienstestatus

Mit dieser Reihe will ich mich mit Ihnen durch die VMware Infrastruktur durchwühlen und die typischen immer wieder gern gesehen Problemstellen aufzeigen. Öffnen SIe dazu mal Ihren vCenter Client und verbinden sich mit Ihrem vCenter Server. Das ganze sieht dann wie folgt aus.
vCenter Server - Home Ansicht

vCenter Server – Home Ansicht

Das rot umrandete ICON ist der vCenter Dienstestatus, auf den Sie jetzt mal klicken..
vCenter Dienstestatus

vCenter Dienstestatus

Ups, da sind ja Warnung, die sind wohl durchgegangen. So oder so ähnlich ist das in 90% aller Fälle wenn ich das erstemal bei einem Kunden den vCenter Client nutze. Die häufigsten Warnung stammen – von einem nicht deinstallierten VMware Converter vor dem Update auf eine neue vCenter Server Version – von nicht laufenden Jobs des SQL-Server Agent – von alten nicht mehr genutzten oder aus Demozwecken installierten Plugins In diesem Fall lag die Situation etwas anders aber vielleicht habt Ihr eine Lösung. Ich würde mich freuen wenn Ihr schreibt. Schaut wieder rein und haltet den vCenter Dienstestatus grün.

Basics Basics Basics

Hallo@all, wie ich in den letzten Monaten, im Rahmen von HealthCheks immer wieder feststellen muss, sind Basics für viele Betreiber von VMware Umgebungen ein Fremdword. Aus diesem Grund werde ich in den nächsten Wochen dies mal hier thematisieren und Euch aufwecken. Also schaut regelmässig rein und prüft mal Eure Umgebung. Lasst Euch nicht erwischen sonst müsst Ihr einen Kaffee ausgeben… In diesem Sinn und lässt Euch nicht erwischen 😀

Erneute Probleme mit SSO in vCenter 5.1 U1a

Auch mit vCenter 5.1 U1a kann es erneut zu Probleme mit der SSO-Komponente kommen. Diese scheinen im Gegensatz zu den vorherigen Versionen anders gelagert zu sein. Bei Tests ergab ich ein Problem mit Benutzern, die in einer Active Directory Group sind, die wiederum zu den lokalen Administratoren hinzugefügt wurde. Wurde nun bei der Installation des vCenter’s die lokale Administratorengruppe mit der Rolle “Administrator” auf das Inventory-Root (vCenter Objekt) berechtigt, kann dies dazu führen, dass der Benutzer der AD-Gruppe die Meldung bekommt, der er keine Rechte auf die nötigen Objekte hat. Der Web Client ermöglicht zwar einen Login, jedoch sind keine vSphere Ressourcen aufgrund ebenfalls fehlender Rechte sichtbar. Einigen Nutzern der AD-Gruppe kann ein Login trotzdem möglich sein, wenn diese schon über eine andere AD-Gruppe zu den lokalen Administratoren hinzugefügt wurden. Es gibt zwei Möglichkeiten um dieses Problem zu umgehen, da es bisher noch keinen Patch seitens VMware gibt:
  1. Es wird eine zweite lokale Gruppe hinzugefügt und die AD-Gruppe dort als Mitglied aufgenommen. Achtung: Die zweite lokale Gruppe muss danach noch gesondert auf das Inventory berechtigt werden.
  2. Es wird eine SSO-Gruppe angelegt und die AD-Gruppe als Mitglied aufgenommen. Achtung: Die SSO-Gruppe muss danach noch gesondert auf das Inventory berechtigt werden.
Beide Workarounds setzen voraus, dass noch Zugriff aus das vCenter Inventory besteht. Alternativ sollte man bei der Installation stattdessen einen Service-AD-Account berechtigen oder direkt eine AD-Gruppe. Beide Methoden umgehen ebenfalls das Problem. Die Problem werden ebenfalls von Magnus Andersson hier beschrieben: http://vcdx56.com/2013/06/24/vcenter-server-and-vcenter-single-sign-on-authentication-problem/

vCenter Hochverfügbarkeit mit vSphere Replication

Das Management ist in IT-Infrastrukturen oft das schwächste Glied in der Umgebung und wird in vielen Desaster-Plänen nicht beachtet. Fällt in einer vSphere-Infrastruktur beispielsweise das vCenter aus, können wichtige Funktionen, welche zum Betrieb und Management der Infrastruktur notwendig sind, nicht mehr ausgeführt werden.  Hierzu zählt z.b. Dynamic Resource Scheduling (DRS), vMotion oder auch Storage vMotion. Genauso ist der Zugriff auf die Distributed Switche eingeschränkt. Unter anderen aus diesen Gründen besteht bei Kunden immer wieder die Notwendigkeit, Lösungsszenarien dazustellen,  welche die wichtigen Management Komponenten hochverfügbar machen. Wo liegt das Problem? Grundlegend gibt es vier Fehlerszenarien, die den Betrieb des vCenter unterbrechen können. Dabei wird jeweils der Betrieb des Applikationsservers mit allen vCenter-Komponenten (vCenter Server, Inventory Service, Orchestrator, SSO, Update Manager) sowie einer externen MSSQL-Datenbank angenommen. Alle Szenarien lassen sich aber ebenso für verteilte vCenter-Komponenten, sprich verteilt auf verschiedenen Server, anwenden. Folgende Ausfallszenarien können eintreten:
  1. Probleme auf Betriebssystem- und Software-Komponentenebene (Update)
  2. Ausfall oder Störung eines Blades im Enclosure
  3. Ausfall oder Störung des gesamten Enclosures
  4. Ausfall oder Störung des gesamten Datacenters
Szenario Eins kann beispielsweise beim Einspielen von Windows Patches und dem Update von vCenter-Komponenten auf einen neuen Release-Stand eintreten. Hiergegen sollte man sich vor einem Updat,e mit Backups der Datenbanken (SQL und ADAM) sowie einem zusätzlichen Snapshot der VM’s, vor dem Update absichern. Szenario Zwei skizziert den Wegfall des ESXi-Host, der im dem Moment des Ausfalls die vCenter-VM(s) oder die Datenbank bzw. mehrere vCenter Komponenten ausführt. Um die Komponenten in diesen Fall möglichst schnell wieder in den normalen Betrieb zu nehmen, sollte man auf ein, bei der Inbetriebnahme des Clusters aktiviertes, vSphere HA setzen. Dieser startet nach dem Ausfall die VM’s des ESXi-Hosts auf anderen Hosts im Cluster neu solange die nötigen Ressourcen hierfür vorhanden sind. Für Szenario Drei muss bei Blade-Umgebungen auf das vorliegende Cluster-Design geachtet werden. Bestmöglichst, erstreckt sich ein vSphere Cluster über mindestens zwei Blade-Enclosures. Weiterhin ist darauf zu achten, das die nicht ausgefallenen Enclosures genug Failover-Kapazität (Admission Control) bereit halten. So lassen sich die ausgefallenen VM’s, wie in Szenario 2, dort neustarten und so eine möglichst geringe Ausfallzeit garantieren. Vorsicht ist geboten, wenn alle vSphere Hosts (Blades) im Cluster in nur einen Enclosure sind. In diesen Fall muss über eine andere Lösung zur schnellen Wiederaufnahme des Betriebs gesetzt werden, da vSphere HA in dieser Situation nicht greift. Erschwerend kann hinzukommen, dass die Datastores/LUN’s auf denen die entsprechenden VM’s liegen, lediglich den ESXi-Hosts dieses Clusters präsentiert werden (z. B. Fibre Channel Zoning). Für dieses Szenario muss also eine Replikation der Daten auf ESXi-Host-Ebene (Block-based; Host based Replication) oder auf Applikationsebene erfolgen. Für beide Szenarien bietet VMware jeweils ein Produkt an. Für beide Ansätze wird kein zusätzliche Array-basierte Replikation (z.B. EMC SRDF) benötigt. Eine Lösung ist VMware vCenter Server Heartbeat. VMware vCenter Server Heartbeat arbeitet auf Applikationsebene und spiegelt die Dienste auf eine “Failover”-VM. Im Falle des Ausfalls der primären Seite, kann die Failover-Seite nahezu unterbrechungsfrei den Betrieb aufnehmen. Eine kostengünstigere Alternative mit einer etwas höheren Wiederherstellungszeit und manuellen Eingriff bietet die Lösung “vSphere Replication”. Diese ist bereits in allen vSphere-Paketen ab der “Essentials Plus”-Variante mit Lizenziert. Weitere Details zu dieser Lösung finden sich im zweiten Abschnitt. Szenario vier, bspw. verursacht durch einen Stromausfall im gesamten Datacenter, stellt eine Situation dar, in der zumeist der Betrieb des vCenter’s obsolet ist, da alle verwalteten Ressourcen auch ausgefallen sind. vSphere Replication Eine Replikation mit vSphere Replication unterscheidet sich gegenüber vCenter Server Heartbeat (nachfolgend Heartbeat genannt) grundlegend in zwei Merkmalen. Es findet entgegen Heartbeat eine Replikation von Speicherblöcken auf vSphere Hypervisor-Ebene statt und zusätzlich ist die Replikation nicht synchron. Im Unterschied zu Heartbeat kann diese Replikation aber für alle VM’s angewendet werden, da sie für das Betriebssystem transparent ist. VMware Heartbeat beschränkt zusätzlich nur auf Windows-Systeme. vSphere Replication erlaubt eine periodische Replikation der geänderten Speicherblöcke einer VM in einem Abstand von 15 min bis zu 24 h, der sogenannten RPO (Recovery Point Objective). Dabei werden am Ende der Periodendauer mittels CBT (Changed Block Tracking) alle geänderten Blöcke aus dem CBT-Log auf eine “Failover”-Seite übertragen. Diese Mthode entlastet die Replikationsstrecke und ermöglicht kürzere Replikations-Zyklen. Voraussetzung für die Replikation der vCenter-Komponenten sind zwei vCenter-Instanzen, die sich später idealerweise über Kreuz replizierten. Zusätzlich wird für beide vCenter-Instanzen jeweils eine vSphere Replication Appliance benötigt, die an das vCenter als vService gebunden wird. Beide vCenter müssen vSphere-Ressourcen verwalten, die später als Quelle und Ziel für die Replikationen dienen. Dabei werden die Blöcke einer VM vom ESXi-Host auf dem die VM ausgeführt zur vSphere Replication-Appliance des zweiten vCenters repliziert, die wiederum die Blöcke über einen ESXi-Host auf den gewählten Datastore der anderen Seite herunterschreibt. Nachfolgende Grafik soll dies verdeutlichen: vSphere Replication architecture Der Hauptgrund für das Vorhandensein einer zweiten vCenter-Instanz ist der Recovery-Prozess. Für die Inbetriebnahme der ausgefallenen VM’s ist das vSphere Replication-Plugin im Webclient nötig. Ist dies gegeben, lässt sich relativ einfach über den Webclient der Betrieb der VM’s wieder aufnehmen. Nutzt man man nur ein vCenter und eine vSphere Replication-Appliance kann man zwar die VM’s auf andere Datastores und Cluster replizieren, jedoch hat man das Henne-Ei-Problem, der Dienste die zum Wiederherstellen der VM’s gebraucht werden. Man sollte nicht unerwähnt lassen, dass solange die VM-Dateien (VMX, VMDK) vorhanden sind sich der Betrieb auch wieder per Hand aufnehmen lässt. Nur ist diese Möglichkeit wesentlich komplizierter und erfordert eine gut dokumentierte Anleitung. vSphere Replication ist nicht auf Szenario drei begrenzt. Es eignet sich auch für Szenario eins. Hier kann die Replikation, der zu aktualisierenden VM’s auch pausiert werden, sodass etwaige Fehler nicht in das Replikat übertragen werden. In diesem Falle kann ein einfach Rollback über die Recovery-Funktion des vSphere Replication gemacht werden. Dies stellt eine weitere Alternative zu Snapshots dar. Die Einrichtung sowie die spätere Konfiguration erfolgt ausschließlich über den vSphere Webclient. Über das Plugin, im vCenter “1”, lässt sich das gegenüberliegende “vCenter 2” als zweite “Site” hinzufügen und umgekehrt. Die Konfiguration der Replikation auf VM-Basis erfolgt über das Kontextmenü in der gewohnten Inventory-Sicht. Besonders zu erwähnen ist im Falle von SQL-Datenbankservern die VSS-Funktionalität. Mit dieser lassen sich die Datenbanken zum Zeitpunkt der Replikation in einen konsistenten Zustand versetzten. Der Status und die initiale Synchronisation der eingerichtete Replikation kann dann wieder über das vSphere Replication-Plugin im Webclient begutachtet werden. Nachfolgende Videos sollen die Installation und Konfiguration der Umgebung verdeutlichen. Diese Lösung wurde durch VMware validiert und wird nach der Veröffentlichung eines Whitepapers/KB-Artikel als “supported” gekennzeichnet werden.

vCenter Operations Management Suite III

Gruppierung von Objekten

Der 3. Teil der Serie über die vCenter Operations Management Suite befasst sich mit dem vCenter Operations Manager und dem Thema „Gruppierung von Objekten“.

Diese Funktion ermöglicht eine granulare Anpassung des vCenter Operations Manager an eine Umgebung sowie das Erstellen von individuellen Containern zur Gruppierung von Objekten vorzunehmen.

Wie wir in den vorherigen Abschnitten gesehen haben, liefert uns vCOPS wertvolle Informationen über den Zustand unserer Umgebung. Wie schön wäre es wenn es möglich wäre individuelle Teilmengen zu bilden um bestimmte Objekte zu gruppieren.

Ein gutes Beispiel hierfür ist es die Server, welche eine Anwendung hosten zu gruppieren und somit schnell einen Überblick über diese Anwendung zu erhalten. Mit vCOPS ist das wie folgt realisierbar.

Oberhalb des Dropdown Bereich gibt es drei Symbole. Eins für Cluster und Hosts, eins für Gruppen und eins für Datastores.

Host&Clusters, Gruppen und Datastores

Host&Clusters, Gruppen und Datastores

Default Gruppen

Default Gruppen

Vielfach wird allein die Registerkarte Hosts und Cluster genutzt. Schaltet man jedoch auf die Registerkarte Gruppen um, so bietet sich hier genau hier die Möglichkeit. Links im Bild sehen wir die von vCOPS per Deault angelegten Gruppen welche bei der Installation mitgebracht werden. Hinzu kommen die im vCenter vorhandenen Gruppen-Objekte d.h. Folder. Folder sind also im Sinne von vCOPS Gruppen weswegen sie hier auftauchen. Um nun eine neue Gruppe zu erstellen ist ein zweistufiger Prozess erforderlich. Einige werden sagen “das stimmt garnicht” oder “das geht auch einfacher” doch warum ich das so mache werden Sie in einem der nächsten Artikel noch sehen. Fangen wir also mit dem ersten Schritt an und erstellen einen Gruppentyp über die Konfiguration die sich oben im Menü befindet.

In der Konfiguration wechsele auf Gruppentyp verwalten und erstelle einen neuen Gruppentypen.

Gruppentypen verwalten

Gruppentypen verwalten

Gruppentyp anlegen

Gruppentyp anlegen

Danach beende diesen Teil mit FERTIG.

Im zweiten Teil wird die eigentliche für uns Sichtbare Gruppe in vCOPS erstellt. Klicke hierzu auf das Gruppensymbol unten links.

Anlegen einer Gruppe

Anlegen einer Gruppe

Es öffnet sich der folgende Wizard.
Neue Gruppe anlegen

Neue Gruppe anlegen

Der Name sowie die Beschreibung ist individuell zu gestalte jedoch ist beim Feld-TYP darauf zu achten das der im ersten Schritt erstellte Gruppentyp ausgewählt wird. Im weiteren Teil werden Suchkriterien definiert da als Mitgliedschaftstyp Dynamisch ausgewählt wurde.

Definieren der Mitgliedschaft

Definieren der Mitgliedschaft

Gruppenvorschau

Gruppenvorschau

Die hier gewählten Suchkriterien enthalten alle VM die im Namen den Begriff view enthalten und diese VMs müssen eingeschaltet sein. Bei Klick auf den VORSCHAU Button erhält man die den Suchkriterien entsprechenden VMs.

Im unteren Bereich können noch explizit includes und excludes definiert werden auf die hier verzichtet wird. Final wird die Gruppendefinition in einem Fenster zusammengefasst.

Einstellungen der Gruppe

Einstellungen der Gruppe

Somit wurde eine individuelle Gruppe erzeugt, die dynamisch alle VMs enthält die im Namen view enthalten. Als weiteres Kriterium der Gruppenmitgliedschaft habe ich definiert das die VM den Betriebszustand eingeschaltethaben muss nur dann taucht sie in dieser Gruppe auf.

Dashboard Ansicht der Gruppe

Dashboard Ansicht der Gruppe

Unsere Gruppe enthält aktuell 3 VMs und ihr ist die Richtlinie Default Policy zugeteilt.

Warum und wieso ich die Gruppe auf die gezeigte Art und Weise erstellt habe erfahren Sie in der nächsten Woche in der Reihe vCenter Operations Management Suite wenn wir uns mit dem Thema Richtlinien beschäftigen.

Sollten Sie weitere Fragen zu den in diesem Artikel dargestellten Informationen oder Produkten haben, so posten Sie gerne unter diesem Artikel.

vCenter Operations Management Suite II

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.
vCenter Operations Manager Dashboard

vCenter Operations Manager Dashboard

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.

Dashboard Systemzustand

Dashboard Systemzustand

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.

Dashboard Risiko

Dashboard Risiko

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.

Dashboard Effizienz

Dashboard Effizienz

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.

Warnungsvolumen

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.

Alarme

Alarme

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.

vCenter Operations Manager Dashboard

vCenter Operations Manager Dashboard

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.

Dashboard Systemzustand

Dashboard Systemzustand

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.

Dashboard Systemzustand

Dashboard Systemzustand

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

Systemzustand

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

Risiko

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

Effizienz

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.

Zusammenfassung

Unsere drei Super-Metriken SYSTEMZUSTAND, RISIKO und EFFIZIENZ bieten uns alle Informationen, die es uns ermöglichen auf einen Blick zu erkennen, wie es unserer Umgebung geht.
Die Dashboards Systemzustand, Risiko und Effizienz

Die Dashboards Systemzustand, Risiko und Effizienz

Der SYSTEMZUSTAND zeigt uns ob aktuelle Probleme vorhanden sind und ermöglicht über die Unterkategorien eine weitere Detaillierung und den Einstieg in ein sofortiges Trouble Shooting. RISIKO zeigt uns potentielle Probleme der nächsten Zukunft und EFFIZENZ informiert über das vorhandene Optimierungspotential. Das Dashboard ist flexibel und zeigt auch individuell die oben besprochenen Werte für jedes Objekt das für vCOPS erreichbar ist. Hier z. B: für eine einzelne VM.
Die Dashboards Systemzustand, Risiko und Effizienz

Die Dashboards Systemzustand, Risiko und Effizienz

Zusammenfassend lässt sich feststellen, dass vCOPS Performance, Kapazität und Konfigurationsmanagement in einer Oberfläche vereint. Hierdurch gelangen wir zu einem besseren Verständnis für unsere Umgebung. Bereitgestellte Informationen werden in 3 Dringlichkeitsstufen aufgeteilt. Der Systemzustand zeigt aktuell vorhandene Probleme, Risiko zeigt in der Zukunft auftretende Probleme und Effizienz zeigt und das mögliche Optimierungs-Potential unserer Umgebung. Wie es in der Reihe vCenter Operations Management Suite weiter geht erfahren Sie im nächsten Artikel dieser Reihe. Nächste Woche werde ich mich mit dem Thema Gruppierung von Objekten beschäftigen und zeigen wie sie in der Praxis gewinnbringend eingesetzt warden können. Sollten Sie weitere Fragen zu den in diesem Artikel dargestellten Informationen oder Produkten haben, so posten Sie gerne unter dem Artikel.

Login Passthrough vSphere Web Client 5.1

Durch die Anbindung des vCenter’s an das firmeninterne Active Directory bietet der vSphere Client sowie der vSphere Web Client die Möglichkeit durch setzen der Checkbox “Windows-Sitzungsanmeldedaten verwenden” ein Passthrough der Windows-Anmeldung zur SSO-Komponente zu nutzen. Mit der Version 5.1 bzw. 5.1 U1(a) kann es nun passieren, dass diese Variante der Anmeldung im Web Client nicht mehr funktioniert. Ursache dafür können unzureichende Rechte für das Starten des RSA SSPI-Service  durch den Network Service sein. Um dies zu prüfen, reicht es festzustellen ob im Task-Manager unter Prozesse der Eintrag “sspiservice.exe” aufgeführt wird. Ist dies nicht der Fall, lässt sich das Problem wie folgt behandeln:
  1. im Windows Explorer in das folgende Verzeichnis wechseln:
  2. in das Eigenschaftsmenü des Ordners “windows-x86_64” wechseln
  3. die Rechte des Ordners für den “Netzwerkdienst” bzw. “Network Service” auf “Lesen und Ausführen” bzw. “Read and Execute” setzen, nur lesend ist nicht ausreichend (ggf. muss der Dienst explizit hinzugefügt werden)
  4. der SSPI-Service muss danach neuinstalliert werden mit folgendem Kommando: der Port kann aus folgenden Datei entnommen werden:
Der SSPI-Service sollte danach automatisch gestartet werden und der Login mittels Passthrough funktionieren.

vCenter Update Manager 5.1 U1(a) und das signierte Zertifikate-Problem

Es gibt mehrere Fallstricke, wenn man die VMware Installer-Zertifikate durch intern oder öffentlich signierte austauschen möchte. vSphere 5.1 verlangt ein eindeutiges Zertifikat für alle Dienste, wie z. B. vCenter Server, Inventory Service oder Update Manager um die Vertrauensstellung zur SSO-Komponente abzubilden. Alle diese Zertifikate können mit dem VMware SSL Certificate Automation Tool (http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2041600) oder auf dem manuellen Weg ausgetauschet werden. Stellen Sie auf jeden Fall sicher, dass Sie die Version 1.0.1 des Tools einsetzen, welches zahlreiche Fehlerbereinigungen enthält. Vor dem Austausch der ersten Zertifikate sollte der integrierte Steps Planner ausgeführt werden, der eine detaillierte Liste der nötige Schritte erstellt und ausgibt. Das Austauschen des Update Manager-Zertifikats ist dabei der letzte Schritt. Wenn Sie alle Schritte des Plans korrekt ausführen und die verwendeten Zertifikate den Vorgaben von VMware entsprechen, sollte der Austausch leicht von der Hand gehen. Meldet man sich nun erfolgreichem Austausch des Zertifikats des Update Managers am vSphere Web Client an und wechselt auf den “Monitor” und “Update Manager”-Tab eines Clusters oder Hosts erhält man folgende Meldung: vum Hinweis: Seit vSphere 5.1 U1 existiert ein vSphere Web Client Plugin mit dem sich Baselines zu Hosts und Clustern zuordnen lassen und sich diese Objekte auf neue Updates scannen lassen.  Nach dem Login über den Web Client lassen sich mehrere Fehler mit dem Text “SSL handshake errors” im Log des Update Managers finden. Diese gelten nur für den Web Client. Ausführen von Funktionen mit dem Update Manager im vSphere Client lösen keinerlei SSL-Fehler aus. Parallele Tests die Zertifikate mittels des VMwareUpdateManagerUtility.exe auszutauschen, verliefen ebenfalls erfolgreich, jedoch verschwinden die Fehlermeldungen nicht aus dem Log-File. VMware  arbeitet zur Zeit an einer Lösung. Ich hoffe, dass Sie relativ schnell einen Hotfix bzw. ein Update für das Problem herausbringen. Bis dahin sind folgende Workarounds möglich: 1. Neuregistrieren des Update Managers mit dem vCenter Server. Dies hilft nicht bei allen Kunden, aber bei einigen (Information von VMware). Das VMwareUpdateManagerUtility.exe kann im Programm Ordner des Update Managers gefunden werden. vum_utility 2. Deaktivieren des Update Manager Web Client Plugins. Melden Sie sich dazu am Web Client mit dem SSO admin (admin@System-Domain) an und wechseln Sie zu  “Administration” und “Plugin Management” und deaktivieren Sie über das Kontextmemü das entsprechende Plugin. Nach einem erneuten Login sind alle Update Manager Widgets verschwunden. Von hier an, kann der Update Manager nur noch vom vSphere Client gesteuert werden. Das Plugin kann auch auf dem selben Weg auch wieder aktiviert werden. vum_webclient

vCenter Operations Manager 5.7.1

vCenter Operations Manager 5.7.1 gelauncht

6 Wochen nach dem Realse der Version 5.7 schiebt VMware das Update 5.7.1 nach. Sofort stellt sich die Frage ob es sich hierbei um ein Bugfix handelt oder wie in den Realase Notes angekündigt auch neue Features/Funktionen freigeschaltet werden. Die in den Release Notes genannten Featureliste sind die folgenden:
  • Performance Report Pack
  • Launch in Context
  • vCenter Log Insight Integration
  • Neue Dashboards in der Custom-UI
  • Balanced Metric Profile
  • Security Hardening
Schauen wir die Punkte mal der Reihe nach an.

Performance Report Pack

Die Berichte, welche ab der Version 5.7.1 im vCenter Operations Manager integriert sind (ab der Standard Edition), enthalten neue Statusberichte sowie Erweiterungen um die in der Trendanalyse bereits enthaltenen Informationen. Interessant ist die Erweiterung der Gruppierung von Objekten (Gruppierung von Objekten wurde mit vCenter Operations Manager 5.6 eingeführt) was sich jetzt auch für die Berichte nutzen lässt. Wie die Gruppierung von Objekten genutzt werden kann lesen Sie in einem der nächsten Artikel.

Launch in Context

“Nice..” dachte ich, als das lass und “..endlich hat mal jemand zugehört” 🙂 Das öfnnen der vCOPS WebUI über einen Button und damit Zugriff auf ein definiertes Objekt in einem Browser. Das wird viele Kunden freuen und mehr Integrationsoptionen in bestehende Plattformen ermöglichen. Fraglich ist noch wie die Berechtigungssteuerung hier umgesetzt wurde.

vCenter Log Insight Integration

Integration oder Interaktion mit vCenter Log Insight das im 3. Quartal offizell verfügbar sein wird. Eine neue Datenquelle für vCenter Operations Manager das von vCenter Log Insight Integration per Mail Infos bekommt die einen Link enthalten die uns von vCenter Operations Manager auf den vCenter Log Insihgt zurück führt.

Neue Dashbaords in der CustomUI

Eine ganze Reihe von Dashboards werden in der CustomUI (Advanced und Enterprise Edition) mitgeliefert.
  • Troubleshooting Dashboard
  • VM Utilization Dashboard
  • VM Performance Dashboard
  • Host Utilization Dashboard
  • Cluster Utilization Dashboard
  • Datastore Performance Dashboard
  • Datastore Space Dashboard
  • Heatmaps Dashboard
  • Alerts Dashboard
  • Host Memory Dashboard
Kommen mir die ein oder anderen Dashboardbezeichnungen auch bekannt vor, so werde ich sie in den nächsten Wochen im Detail vorstellen.

Balanced Metric Profile

Das Balanced Metric Profile, das mit der Version 5.7 schon eigeführt wurde um die FLut an Daten und den damit benötigten Terrabytes großen Plattenplatz der Analytics_VM einhalt zu gebieten, wird hier erneut als Feature benannt. Vielfach entstand mit der Einführung des Balanced Profile der Eindruck, das einfach ein Großteil der Daten des vCenter Servers garnicht mehr gesammelt respektive vom vCenter Server abgerufen wurden. Also ein Fix und kein Feature!?

Security Hardening

Wesentlicher Bestandteil und Anpassung ist für viele die Unterstützung des JRE 1.7.

Fazit

Für mich ist das Minor Update auf die Version 5.7.1 mit einem lachenden und weinem weinenden Auge zu betrachten. Der Teil “Know Issues” und “Installation and Upgrade” ließt sich wie die Beilage zu einem Medikament also Augen zu und durch. Die Release Notes können Sie im Detail hier lesen. Nächste Woche werde ich mich mit den vCenter Operations Manager Dashboards beschäftigen und Ihnen die Konzepte dahinter verständlich machen. Sollten Sie weitere Fragen zu den in diesem Artikel dargestellten Informationen oder Produkten haben, so posten Sie gerne unter dem Artikel.