Creating Docker Adapter Instance in vROps with vRO

Das neue Docker Management Pack für vROps ermöglich die Einbindung von Docker-Metriken das Monitoring. Problematisch ist, dass für jeden Docker Host eine eigene Adapter-Instanz erstellt werden muss. Eine perfekte Gelegenheit um mal wieder den vRealize Orchestrator zum Einsatz zu bringen.

vROps bietet ein REST-API. Hierzu findet sich unter https://<vrops host>/suite-api/docs/rest/index.html eine schöne Dokumentation.

Screen Shot 2016-05-18 at 22.10.10

 

Download: vCO Workflow: CreateVropsDockerAdapterInstance

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

 

VMware Photon und eine private Docker Registry

In einer DEV-/Test-Umgebung kommt es häufig vor, dass die Docker Registry nur über HTTP und nicht über HTTPS verwendet wird. Die Docker Runtime geht standardmäßig davon aus, dass die Verbindung SSL verschlüsselt und das ausstellende CA-Zertifikat lokal vorhanden ist. Ist dies nicht der Fall, erhält man folgende Fehlermeldung:

root@photon01 [ ~ ]# docker run -it 192.168.5.20:5000/corp/centos7base:7.2
Unable to find image '192.168.5.20:5000/corp/centos7base:7.2' locally
docker: Error response from daemon: Get https://192.168.5.20:5000/v1/_ping: tls: oversized record received with length 20527.
See 'docker run --help'.

Der Docker-Daemon kennt zum Ignorieren der SSL-Verschlüsselung den Parameter –insecure-registry . Dieses lässt sich manuell beim Starten des Daemons mitgeben oder als fester Parameter für den automatischen Start festlegen. Hier ist noch zu unterscheiden ob systemd verwendet wird oder nicht. Photon setzt systemd ein, daher kann folgender Weg angewendet werden:

systemctl enable docker
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

Der Parameter –insecure-registry gibt dabei die Adresse plus den Port der privaten Docker Registry an. Sollen mehrere Registries eingetragen werden, so wird der Parameter in der oben angegeben Form mehrmals hintereinander mit je einem Server angegeben.

Nach dem Änderung durchgeführt wurde, muss die systemd-Konfiguration von der Platte neueingelesen werden:

systemctl daemon-reload
systemctl restart docker

HINWEIS: Die systemd-Konfigurationsdatei könnte bei einem Update wieder überschrieben werden.

CentOS Base Image für Docker erstellen

Im öffentlichen Docker Hub Image Repository finden sich einige fertige CentOS-Basisimages, darunter auch die vom CentOS-Projekt gepflegten.

Wer diesen nun misstraut oder gerne sein eigenes Basisimage erzeugen möchte, kann zu mehreren Optionen greifen. Folgt man dem Hinweis für CentOS auf docker.com, gelangt man zu einem Skript, der die Arbeit für einen erledigt. Manchmal ist es sinnvoll auch zu verstehen, was dort getan wird und somit macht man es auch gerne per Hand. Das Erstellen eines Docker-Basisimages ist vergleichbar mit dem Erstellen einer CHROOT-Umgebung. So fangen wir auch an (hier am Beispiel einer CentOS 7-Installation):

  1. Zuerst erstellen man einen temporären Ordner für die CHROOT-Umgebung:
  2. Danach baut man eine RPM-Datenbank für die spätere Paketinstallation in der CHROOT-Umgebung:
  3. Nun teilt man dem lokalen RPM mit, welches OS installiert werden soll. Dies geschieht über das centos-release Paket, welches die nötigen Metainformationen für z. B. Repositories enthält:
  4. Es fehlen noch die Pakete für die CHROOT-Umgebung. YUM und RPM ziehen alle nötigen Abhängigkeiten für die CHROOT-Umgebung:
  5. Überprüfen sollte man seine Arbeit auch noch:
  6. Nun importieren wir das Image noch in unsere private Docker Registry:

Die Anleitung funktioniert analog auch für CentOS 6 oder den entsprechenden RHEL-Versionen. Einfach die Repository-Pfade anpassen und gut.

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.