VMware Validated Designs does not exclude Stretched Cluster in general

Working as an architect in the VMware space you will sooner or later come across the VMware Validated Designs (VVD). Just a few weeks ago the latest version 4.0 was released to make adjustments for vSphere 6.5. It can be found here:

VMware Validate Designs Documentation

The designs are a great source for building your own architectures or building architectures for customers. The incorporated component architectures are natively built for availability, reliability and scalability. These are exactly the main goals I try to put in the designs I create for customers. The VVDs show up a good practise for a detailed setup that can be used for several use cases like Private Cloud or VDI deployments. VMware Cloud Foundation also makes use of the VVDs for its implementations.

But apart from this I also like to treat them as a framework which gives me the chance to keep the setup supported by VMware but also adjust it to the customer needs and make it fit like a second skin based on customers requirements.

Across their history they mainly relied/rely on a two region concept with one primary and fail-over region. This is a quite common architecture for U.S. setups. In the European space and especially in Germany customers often stick their existing architectures based a two datacenters setup working as an active/active pair. If you see this also as a two region setup or you would aggregate this into one region like me, is up to you. I prefer one region because the datacenters are in a short distance because of their synchronous replication/mirroring and so they build up a logical domain because for their active/active style.  This is why I split the region down to two physical availability zones (AWS term) and one virtual across two datacenters. This does not need to be undestand now, it will get clearer in later chapter.

In my understanding the VVD framework needs some extension in regards to Stretched Clusters and this is why I like to set up a series which guides through a forked version of the VVDs I personally use for customer designs:

  1. General thoughts
  2. Additions/Changes to physical architecture
  3. Additions/Changes to virtual architecture
  4. Additions/Changes to cloud management architecture
  5. Additions/Changes to operations management architecture
  6. Additions/Changes to business continuity architecture

Stay tuned!

 

 

 

 

 

Set up vCenter HA in advanced mode with different heartbeat networks

Setting up vCenter HA in basic mode is pretty straight forward.

Doing the same in advanced mode is a little bit more tricky. But first, why I need to go with the advanced vCenter HA mode?

  • the VCSA is managed by another vCenter (for example if the setup is according to the VMware Validated Design 3.0)
  • the heartbeat vNICs are not in the same IP subnet

Luckily I to cater with both in a project.

I don’t want to create much content by copying from VMware documentation, so I only like to give some hints and describe some pitfalls you might get into, when setting this up and last but not least describe what VMware missed in there official documentation:

https://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.avail.doc/GUID-13E2EEB3-4DD7-43CC-99C8-73A98676C15E.html

Preparation pitfalls

DNS reverse lookup

Basics, basics, basics. Ensure that you have a proper DNS reverse lookup implemented. Also take care of the exact writing of the host names. Don’t maintain a hostname entry in the DNS system with capital letters and use a non-capital or mixed one in your VCSA. This basically does not work, because the self-lockup fails. The GUI won’t tell you that, but if you run the preparing with prepare-vcha cmd line interface I will show up some more info.

 

Procedure pitfalls

When have you clicked through the first step in GUI, the next step is to clone the VCSA two times, once for the passive node and second one for the witness node. Very important is, that you don’t clone before the first step has finished. Otherwise the communication between the appliances won’t work because they use the wrong SSH keys. This is also valid, if you try to use the same cloned appliances for setting this up a second time – this won’t work. You need to throw them away and clone new ones at the right point in time.

Customization

The official documentation does not describe the customization stuff in much detail. Maybe that is not necessary, but if something is not totally clear to you, here some hints:

Passive node: documentation is clear, but really, you need to configure the first NIC (NIC 0) with the same IP config like the primary vNIC of your original VCSA. The adapter gets automatically shut down while first boot, so there is no IP conflict in your network – or better only for a short moment. NIC 1 set to the heartbeat network info you have prepared. Ensure that you really don’t set a gateway on this adapter.

Witness node: the documentation stated here to also leave the gateway out for the required heartbeat NIC. I have not done this, as I set the first adapter unused or shut it down. The second one I set to the heartbeat IP and used also a gateway. The gotcha was, that the witness had an IP in a totally different subnet than the active and the passive VCSAs. Static routes might also do the job, but I had some trouble with that.

First start

Start up the appliances. The IP conflict resolves as described above. Before to click the next step in the GUI, ensure that you do the following:

Go to both active and passive VCSA and add a static route so they can reach the witness via the heartbeat interface:

Edit /etc/systemd/network/10-eth1.network and add the following lines at the end:

[Route]
Destination=10.xxx.yyy.zzz/32
Gateway=10.sss.ttt.1

The destination can be limited to the heartbeat IP of the witness VM. The gateway must be the gateway of the IP subnet used for the heartbeat in the local VCSA appliance. Repeat this on the passive appliance (best is to SSH to it via the active one).

Now and only now hit “Finish” in the GUI and all should go well. You can check the log /var/log/vmware/vcha/vcha.log for further info.

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 😀