Tag Archives: Vmware

Docker Remote Management mit vRealize Orchestrator

Docker oder Applikations- bzw. Containervirtualisierung erfreut sich quer durch alle Branchen und Unternehmensgrößen immer höherer Beliebtheit. Hat man nun vor Docker im größeren Stil z. B. im Enterprise zu nutzen (darüber lässt sich natürlich genüßlich streiten – Kommentar auf TheNewStack), so macht sich eine Orchestrierung der aufkommenden Verwaltungsaufgaben schnell bezahlt und letztendlich auch unerlässlich. Auf dem OpenSource-Markt gibt es einige Produkte zum Cluster-Management. Zu nennen wären hier Docker Swarm, Mesos oder Kubernetes bzw. alles zusammen im Photon Controller. Möchte man nun seine Container Hosts etwas freier betreiben oder z. B. in den Deployment-Prozess von vRealize Automation einbinden, bietet sich der vRealize Orchestrator an. Läuft ein Docker Container Host als VM z. B. mit Photon, so ergeben sich grundlegend drei Wege Docker Befehle gegen diesen Container Host auszuführen:
  • SSH, Authentifizierung per SSH, Ausführen der Aktionen über die docker CLI Pros: Linux native, keine weiteren Tools notwendig Cons: SSH offen (besonders in der DMZ problematisch), Rückgabewerte auswerten
  • VMware Tools (VMCI), Authentifizierung über das Host-Guest-Interface, Ausführen der Aktionen über die docker CLI Pros: keine Netzwerkverbindung nötig Cons: VMCI Modul in den VMware Tools als Sicherheitsrisiko, Rückgabewerte auswerten
  • Docker Remote API, Authentifizierung über Docker Daemon (Achtung: standardmäßig ist diese deaktiviert), REST-API Aufrufe Pros: standardisiertes API (REST), keine weiteren Tools notwendig Cons: exposed Port
Der wohl eleganteste Weg ist das Docker Remote API. Dieser Artikel beschreibt für Photon, wie man das Remote API freischaltet: http://the-virtualizer.com/2016/05/expose-docker-remote-api-on-photon/ Nun zur eigentlich Orchestrierung. Will man einen Docker Container nun über einen vRA-Request bereitstellen, so ist der vRO das Mittel der Wahl um den Docker Host anzusprechen und einen Container zu instanziieren. Möchte man gerne Docker Swarm einsetzen um die Aufgaben über mehrere Hosts eines Cluster zu verteilen, so sehen die Schritte analog aus, da das Swarm API an das Docker API angelehnt ist. Der folgende Workflow zeigt das Instanziieren und Starten eines Containers aus einem vorgegebenen Image anhand der Docker API: Screen Shot 2016-05-16 at 12.29.16   In dieser Variante akzeptiert dieser Workflow folgende Eingabe-Parameter: Screen Shot 2016-05-16 at 12.34.34 Dies kann belieb erweitert werden, z. B. um Port- und/oder Volumemappings. Dafür muss entsprechend der Payload für den Create Docker Container Workflow erweitert werden. Die möglichen Parameter können hier nachvollzogen werden: https://docs.docker.com/engine/reference/api/docker_remote_api_v1.23/#start-a-container Download: vCO Workflow: Run Docker Container (Remote API)  

Expose Docker Remote API on Photon

Es kann sinnvoll sein die Docker Remote API nicht nur von localhost erreichbar zu machen. Fälle dafür sind z. B.:
  • Orchestrierung der Docker Runtime von extern (z. B. durch den vCenter Orchestrator bzw. vRealize Orchestrator)
  • Monitoring der Docker Runtime durch vRealize Operations mit Docker Management Pack
Dazu muss im Falle von Docker die systemd-Konfiguration für den Docker Daemon editieren:
vi /etc/systemd/system/multi-user.target.wants/docker.service
ExecStart=/usr/bin/docker daemon \
          --containerd /run/containerd.sock --insecure-registry=192.168.5.20:5000 -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock
-H bestimmt dabei, wo der Deamon lauschen soll. tcp://0.0.0.0:2375 exposed den Port auf 2375/tcp nach außen unix:///var/run/docker.sock lässt auch weiterhin den lokalen Unix-Socket laufen, sodass die CLI-Kommandos wie gewöhnlich genutzt werden können   Von außen lassen sich nun entsprechende Abfragen gegen die Rest-API absetzen:
GET http://192.168.5.20:2375/containers/json
POST http://192.168.5.20:2375/containers/create
 

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 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