Evgenij Smirnov – IT Pro aus Berlin …because IT matters :)

Ab dem 01. April wird VMware die Zertifizierungspreise „anpassen„. Und während man vielleicht die Erhöhung von $400 auf $450 (12,5%) für Advanced-Zertifizierungen noch verschmerzen kann, tun mir die besten der besten armen Schweine leid, die vorhatten, ihre VMware-Recognition mit einem VCDX-Titel zu krönen. Statt $1200 (300 Registrierung + 900 Verteidigung) müssen sie nun $3900 löhnen (900 Registrierung + 3000 Verteidigung). Das ist eine Erhöhung um 225%. Und dass man dafür von Duncan Epping persönlich zerlegt wird, lindert den Schmerz vermutlich nur marginal.

Einmal ausnahmsweise ist es ein gutes Gefühl, nicht zu den besten auf einem Gebiet zu gehören…

*seufz*

… und ich musste meinen VCP erneuern. Diesmal beschloss ich, dies im Wege eines Delta Exams zu tun. Das ging gut, aber ich denke, nächstes Mal mache ich mal wieder eine volle Prüfung. Der Aufwand ist derselbe und der Stressfaktr etwas weniger 😉

Für Leute mit Platz an der Wand und einem Großformatdrucker: https://blogs.vmware.com/PowerCLI/2017/02/powercli-65-poster.html

Das ist wohl eher ein Kuriosum als ein produktiv einsetzbares Merkmal. Dennoch möchte ich es nicht unerwähnt lassen:

Man kann einen auf kostenfreie Version lizentzierten ESXi 4 (in dem vorliegenden Beispiel 4.0.0 Build 208167) zu einem vCenter 5 (in dem vorliegenden Beispiel vCenter Appliance 5.0.0 Build 455964) hinzufügen.

Nach dem Kurs im Dezember und einiger Vorbereitung bin ich ab heute VCP auf vSphere 5. Yay!

Ich hatte ja schon über die grundlegenden Eckdaten der VSA geschrieben (hier). Seither sind einige Wochen vergangen, in denen ich anderes zu tun hatte, aber nun möchte ich den VSA-Thread endlich fortführen.

Heute wollen wir die Installation der VSA live ausprobieren. VMWare verspricht eine Installation in 15 Minuten, was durchaus zutreffen kann, wenn die Voraussetzungen (über welche ich in dem o.g. früheren Beitrag schon ausführlich schrieb) geschaffen wurden – was freilich gut und gerne eine Stunde in Anspruch nehmen kann.

Als erstes wird auf dem vCenter Server die Installations-CD eingelegt. Ohne größere Abfragen oder bunte Splash-Screens startet der Installationsvorgang, der übrigens gleich die über das Netzwerk erreichbare vSphere-Infrastruktur inventarisiert. Sie muß in diesem Augenblick noch nicht vollständig stehen, aber es erleichtert die Sache.

Danach ist im vSphere Client (im Datacenter-Knoten) ein neuer Tab verfügbar: VSA Manager. Dieser benötigt Flash, im Gegensatz zu den anderen Komponenten des vSphere Clients. Es ist noch keine aktive VSA konfiguriert, daher erscheint beim Aufruf des Plug-Ins die Aufforderung, eine zu installieren:

Wir wollen eine Neuinstallation riskieren und lassen die Auswahl daher bei „New Installation“. Es folgt ein kurzer Überblick darüber, was alles eingerichtet wird und warum es ganz toll ist:

Danach folgt die Auswahl und Untersuch des gewünschten Datacenters für den VSA Cluster. In dem „Essentials Plus + 3er VSA“ – Szenario, welches VMWare als DAS Einsatzszenario für die VSA anzusehen scheint, ist freilich nur ein Datacenter hier möglich. Implementiert man die VSA mit den „großen“ Produkten, können hier sicher auch weitere Datacenter erscheinen.

Hier sieht man die CPU-Kompatibilität der Hosts im zukünftigen Cluster. Bei diesen beiden handelt es sich um Maschinen unterschiedlicher Leistungsklassen – ein Athlon und ein Opteron, daher auch der recht bescheidene Grad an Übereinstimmung, wie man sieht:

Manchmal sind beim ersten Durchlauf ein oder mehrere Hosts im „Degraded“-Status. Einen Schritt zurück gehen und den Host rebooten hat ab und zu geholfen – immer unter der Annahme, daß die übrigen Voraussetzungen stimmen.

Nun wir das Netzwerk für den VSA-Cluster konfiguriert, sie muß im selben Subnetz liegen wie der VSA Cluster Manager-Rechner, in diesem Fall also der vCenter-Server.

Mit der Eingabe der beiden ersten IP-Adressen werden automatisch auch weitere Adressen auf die Hosts verteilt:

Das sieht dann so aus:

und für den zweiten Host:

Ein Wort der Warnung, was das Networking auf den Hosts angeht: Im Moment haben die Hosts noch ihre Management-Interfaces schön mit einer IP-Adresse versehen. Wenn es an die Konfiguration des Clusters geht, wird der Installer die Netzwerkschnittstellen neu mischen. Die Adressen bleiben zwar erhalten, es kann aber sein, daß sie plötzlich einer anderen Netzwerkkarte zugewiesen werden! Daher sollte die Kommunikation zwischen den 4 NICs in jedem Host und dem vCenter in diesem Augenblick noch „flach“ sein, d.h. jede Netzwerkkarte muß jede andere erreichen können. Später kann man sie dann trennen, sei es um den Traffic zu isolieren oder um Ausfallsicherheit gegenüber dem Defekt eines Switches zu erhöhen.

Nun die letzte Frage, bevor’s losgeht – jetzt oder später formatieren. Meine Erfahrung hier ist so:

• formatiert man gleich, dauert es lange
• formatiert man später, merkt man es gar nicht.

Daher rate ich, die Formatierung nicht als Teil der Installation vorzunehmen.

Jetzt noch mal die Konfiguration überprüfen…

…und schon wird einem der erschreckende Hinweis präsentiert, daß alle Daten gleich futsch sind:

Die Erfahrung zeigt, dem ist nicht so, jedenfalls nicht in diesem Release. Trotzdem ist es nicht gut, Daten im Datastore zu haben:

1. da VMWare das offensichtlich so vorgesehen hat, wird es vermutlich in einem der späteren Releases umgesetzt
2. eben weil die bestehenden Daten erhalten bleiben, reduzieren sie die Gesamtkapazität der VSA. Zur Erinnerung: alle von der VSA präsentierten Shares sind gleich groß, und zwar etwa halb so groß wie der kleinste verfügbare Platz auf einem der Hosts!

Nun aber wird tatsächlich installiert. Das sind die berühmten 15 Minuten:

… man sieht schon ein wenig vom Cluster:

… und die beiden Appliances (das wären bei 3 Hosts natürlich auch drei):

… nun ist der Cluster auch per TCP/IP zu erreichen:

… und fertig!

Jetzt zeigt der VSA Cluster Manager auch sinnvolle Daten zum Zustand des Clusters an:

Die VSA ist fertig und läuft. Herzlichen Glückwunsch!

Zwei Anmerkungen an dieser Stelle noch:

1.  obwohl der VSA Installer recht tiefgreifende Einstellungen am vCenter vornimmt, stellt er an den physischen Datastores der Hosts (die ja dann durch die VMDKSs der VSA-Appliances ja richtig voll sind!) die Alarmaktionen nicht ab, die dann auch immer anschlagen. Allerdings ist es bei der HP-Appliance und bei manch anderen, die ich gesehen habe, auch nicht anders
2. Will man die VSA wieder deinstallieren, so darf man nicht anfangen, den Cluster aufzulösen, die Appliance-VMs händisch zu entfernen usw. Dafür gibt es einen Skript, der mit der VSA zusammen installiert wird. Die Benutzung wird hier in der VMWare-KB beschrieben. In meinem Fall mußte im Unterschied zum KB-Artikel der Pfad zur Java-Umgebung manuell gesetzt werden (systemweite Umgebungsvariable).

Mit dem Erscheinen von vSphere 5 ist nun auch der Versuch von VMWare erhältlich, produktionsfähige Installationen ohne Shared Storage zu ermöglichen – die vSphere Storage Appliance, oder VSA. Der Anspruch ist es, eine hochverfügbare Storage-Lösung für die Unterbringung virtueller Maschinen auf Grundlage des in den Hosts verbauten internen Festplattenspeichers zu schaffen. Die offizielle Resource von VMWare ist hier: http://www.vmware.com/products/datacenter-virtualization/vsphere/vsphere-storage-appliance/overview.html

Was wird benötigt?

Man braucht wahlweise zwei oder drei ESXi5-Hosts, die folgenden Anforderungen entsprechen:

• CPU: Die VSA verbraucht kaum CPU, d.h. man muß vom Bedarf der später auf der Infrastruktur zu hostenden VMs ausgehen. Die Hosts werden jedoch zwangsläufig in einem Cluster zusammengefaßt, daher sollten die CPUs möglichst identisch sein, um EVC nicht zu bemühen
• RAM: Auch hier gilt: Die VSA selbst ist nicht besonders hungrig. Dennoch nimmt sie vRAM auf jedem Host in Anspruch, und dieser kostet bei vSphere 5 nun mal Geld.
• Storage: Jeder Host muß über einen fertig eingerichteten Datastore verfügen, und zwar über genau einen. Die offizielle Systemvoraussetzung lautet außerdem, daß sich dieser Datastore auf einem RAID10 mit mindestens 8 Platten befinden muß, dies wird aber nicht überprüft (wie auch). Die RAID-Einrichtung der Hosts ist auch gleichzeitig die einzige Sicherung gegenüber Ausfall einzelner Festplatten in diesem Konzept. Wichtig – Bei der Installation wird angedroht, die auf den Datastores befindlichen Daten zu löschen. In der jetzt ausgelieferten Fassung geschieht dies dann zwar doch nicht, man sollte sich aber nicht darauf verlassen! Die Datastores müssen übrigens nicht zwangsläufig gleich groß sein. Sind sie jedoch unterschiedlich groß, wird Speicherplatz verschenkt (s.u.)
• Network: Jeder Host benötigt 4 Netzwerkkarten. Alle müssen angeschlossen sein. Wichtig – Alle NICs an allen Hosts müssen zum Zeitpunkt der Installation untereinander und mit dem vCenter kommunizieren können, denn der VSA Cluster Installer wird sie nach eigenem Gutdünken teamen und auf Back Edn und Front End verteilen. Wenn man sie später durch physisch separate Switche oder portbasierte VLANs isolieren möchte, kann man das freilich tun. Es darf nur die Standard-Netzwerkeinrichtung vorgenommen worden sein – alle Änderungen zum Default-Networking führen zum Abbruch der Installation. VMWare spricht hier von einem „Greenfield-Host“.
• VMs: Es dürfen keine VMs auf den Hosts registriert sein.

Außerdem braucht man einen fertig eingerichteten vCenter 5 Server. Dieser muß unter Windows laufen (der VSA Cluster Manager ist ein Windows-Dienst!) und darf zum Zeitpunkt der Installation des Storage-Clusters nicht auf der Cluster-Infrastruktur virtualisiert sein. Also entweder eine physische Maschine oder eine VM, dann aber auf einem vierten Host virtualisiert. Später kann der vCenter Server durchaus auf den VSA Cluster verschoben werden. Die zukünftigen Cluster-Hosts sollten idealerweise bereits in das vCenter eingebunden sein, dies ist jedoch lt. VMWare nicht Bedingung (diese Konstellation habe ich nicht getestet).

Was bekommt man am Ende?

Nach der Installation des VSA bekommt man einen fertig konfigurierten HA Cluster, der die obigen Hosts umfaßt. Auf jedem Host läuft eine VSA-Instanz als VM. Jede VSA-Instanz exportiert einen NFS-Datastore, welcher auf allen Hosts im Cluster schon gemountet ist, und hostet außerdem eine Replica von dem anderen (oder einem der beiden anderen) Datastores.

• Die exportierten NFS-Datastores sind gleich groß, und zwar genau halb so groß wie der kleinste lokale Datastore auf den Hosts.
• Weitere Hosts, die nicht Bestandteil des Clusters sind, dürfen und können auf die NFS-Exports zugreifen, müssen dafür aber von derselben vCenter-Instanz wie der Cluster verwaltet werden. Dies hat ggfls. Auswirkungen auf die Lizenzierung, s. weiter unten.

Was kostet das Ganze? (Preisangaben natürlich ohne jegliche Gewähr und nur Listenpreise!)

Es kommt darauf an. Klar ist, daß die kleinste Lizenz, die diese Einrichtung überhaupt zuläßt, eine Essentials Plus ist. VMWare hat die beiden Produkte im Bundle für knapp 7.500 €, was für das, was man kriegt, ja ziemlich günstig ist. Einzeln kostet das Add-On knapp 6.000 – 9.000 €, je nach gebuchtem Support-Level, unabhängig von der zugrunde liegenden vSphere- und vCenter-Lizenz. Bei der Essentials Plus-Einrichtung mit drei Hosts darf na kein weiterer Host auf die VSA zugreifen (s.o.).

Mein Fazit: Auf jeden Fall interessant. Nächste Woche schreibe ich ausführlich über die Installation und den Betrieb der Lösung, zumindest hier im Labor.