Heute mal wieder etwas für Geeks:

Hyperconverged light – als Fazit meiner erfolgreichen Prototypen- Installation – ist durchaus eine Option und hier das HowTo: Auf Basis eines DL320e G8v2 mit vSphere 5.5 und HP VSA– der virtuellen Storage Appliance auf Basis der Lefthand Storage Systeme aus der P4000 Serie.

Test Hardware Definition

Der DL320e ist dabei mit kompatiblem Kingston Speicher ausgestattet – KTH-PL316E/8G und mit zwei 2TB WD Red platten für günstigen Platz, aber zwei Spindeln IO. Wunder sind von der Konfiguration nicht zu erwarten, aber es ist zunächst einmal reichlich Platz für zu virtualisierenden Storage vorhanden. Der Kingston Speichertyp ist wichtig, damit das System die Memories auch nimmt, eBay ist voll mit Kingston Speicherriegeln leicht anderer Bauart, die in DL380e nicht gangbar zu machen waren.

ProLiant Preparation

Vorbereitung des ProLiant mit dem HP ProLiant Service Pack, aktuell noch immer die Version 2014.09. Das ist kein größeres Drama,

da sich der HP Smart Update Manager (HP SUM) die weiteren notwendigen Updates online aus dem Internet zieht. Das heisst auch dass in dem Netz der Installation sowohl ein DHCP aktiv sein sollte, als auch ein Weg ins Internet existieren. Offline Vorbereitung des HP SUM ist sicher ein ganz eigenes Thema.

Dringend darauf achten dass insbesondere ILO4 und auch der on Board Smart Array Controller – B120i aktualisiert werden. Die erste Installation auf dem System schlug zwar nicht fehl, aber beim durchreichen der im RAID Konfigurierten LUNs vom vSphere hin zur VSA hat letztere nur die physikalischen Platten und nicht die im RAID frei gegebenen Volumes erkannt.

Aus verschiedenen Iterationen hat sich ergeben das ProLiant customized Image für die vSphere 5.5-U2 Installation zu verwenden. Die Installation der vSphere erfolgt dann auf eine Micro SD Card, die auf dem Motherboard des DL liegt und durch ILO durch gereicht wird. Eine vanilla Installation der vSphere mit anschließendem Patch sollte zwar ebenfalls funktionieren, aber nach den diversen LUN Konfigurationen und Neustarts, braucht der Arbeitsschritt nicht aufwändiger sein als notwendig. Da das Image direkt durch VMWare gepflegt wird habe ich hier auch keine weiteren Bedenken.

RAID Configuration and Considerations

Nachdem sowohl VMWare als auch die VSA ihre LUNs als solche finden, bleibt mit dem doch recht sparsamen RAID Controller der Effekt, dass LUN Null – 0 auf beiden Ebenen nicht korrekt angezeigt wird. Eine Dummy LUN 0 mit 2 MB Größe bereinigt das Problem Effektiv und der wesentliche Teil der Netto Kapazität kann im Hypervisor und der Storage Appliance verwendet werden. Im konkreten Fall wurden drei LUNs a 1 TiB – gemäß der HP Array Configuration Utility (HP ACU) – F5 im ProLiant Splash Screen – angelegt. Die erste LUN als regulärer Datastore, die zwei Weiteren als Pool für die Virtualisierung – in diesem Fall als nicht unbedingt empfohlenes RAID 0 aber es soll ja auch nur ein Test sein.

Bei der Anlage der RAID LUNs ist zu beachten, damit die VSA Installation durch läuft, benötigt diese mindestens zwei zu Grunde liegende Platten, Raw Devices oder Datastores, die ein RAID aufspannen. Dabei erfolgt die eigentliche Installation der VSA durchaus korrekt, aber bei der Inbetriebnahme der Central Management Console wird zur Verwaltung der einzelnen VSA Systeme ein Management Cluster gebildet, der sich wiederum bei fehlendem RAID- Status nicht aktivieren lässt. Damit hätte man die VSA zwar installiert, aber ein Management ist nicht möglich.

Aus diesem Grund empfiehlt es sich hier direkt zwei LUNs identischer Größe an zu legen um auch in einer kleinen Testumgebung einen RAID Status zu haben der in der CMC akzeptiert wird. Dabei darf dieser RAID- Statue wieder ein Striping mit RAID 0 sein, so dass kein netto- Datenvolumen verloren geht.

vSphere Installation

So weit vorbereitet kann mit dem o.g. Image kurz ein vSphere Hypervisor auf der SD-Karte installiert werden. IP Konfiguration durchführen, Passwörter vergeben und fertig. Danach mit dem vCenter Client von einem normalen PC auf den Host zugreifen und die Datastores vorbereiten.

Im hiesigen Fall wurden also drei VMFS-5 Datastores mit jeweils einem Terrabyte angelegt. Der erste Datastore dient tatsächlich als Kickstart Zone in der die VSA- Appliance später installiert wird.

Darüber hinaus bietet sich der Datastore auch zur Unterbringung des vCenter Management Servers an, auf dem später auch die Management Console der VSA liegen wird, so dass man mit Bordmitteln, die Systeme  so weit wieder hoch fahren kann, dass der virtualisierte Storage auch verfügbar wird. Im Gegebenen Szenario liegt hier auch eine Backup- Instanz der Active Directory Domain Controller, die ich in einem Produktiven Umfeld würde ich hierzu eine dedizierte Physik als “Lebensversicherung” vorsehen. Um diese beiden Infrastruktur- VMs unter zu bringen reicht normalerweise ein Datastore von ca. 128 Gigabyte.

vCenter Server Installation

Um die Umgebung auch sauber auf zu setzen, jetzt zunächst zwei Windows 2012R2 Server aufgesetzt. Diese beherbergen dann die zuvor erwähnten vCenter Installation und eine AD- Instanz.

Im vCenter Server das Installations- Image mounten und die Installation durchlaufen per default durchlaufen lassen. Ich empfehle zumindest aktuell noch auch die lokale Installation des vCenter Clients (vSphere 6 soll nur noch mit Webfrontend kommen). Mit diesem auf den localhost und den Standard Credentials Administrator@vsphere.local auf den vCenter Server verbinden. Danach den “first steps” folgen, ein Datacenter anlegen und den Host einbinden. Schön kann man die Installation später noch immer machen.

vCenter Network Configuration

Aus dem vCenter heraus die Netzwerk- Konfiguration des Hosts abschließen. In der aktuellen Installation sind vmKernel und das VM Network auf einem vSwitch, der sich die redundanten Netzwerkkarten teilt. Da hier weder mit VLANs noch mit unterschiedlichen IP Segmenten gearbeitet wird, ist das für den Test auch ausreichend. In einer produktiven Umgebung würde ich hier auf jeden Fall für mindestens zwei getrennte distributed vSwitches plädieren und den User- Datenverkehr von iSCSI gegebenenfalls trennen. Das wird um so wichtiger, wenn die VSA Appliances als Cluster konfiguriert werden und bei einem NetRAID 1 synchron auf die benachbarten Cluster- Knoten schreiben sollen.

HP VSA Installation

Zur HP VSA Installation, das entsprechende Image auf dem vCenter Server mounten und den Autorun- Installer laufen lassen. VSA Installation für “VMWare ESX Server” auswählen, es gibt auch eine Version für Hyper V. Danach erfolgt eine geführte Installation durch den Installation Wizard.

Der erste wesentliche Punkt ist die Installation der Management Konsole CMC – die man ggfs. hier abwählen kann. Grundsätzlich kann diese auch auf jedem beliebigen Management Server oder PC laufen. Da aber in dieser Umgebung auch noch weitere Tests hinsichtlich VAAI Integration und Implementierung des CMC PlugIns ins vCenter vorgesehen sind, hier die Installation direkt auf dem vCenter Server.

Danach selektiert man den Host und die Zugangskoordinaten, auf welchen die VSA ausgerollt werden soll und in Kombination, auch den entsprechenden Datastore. In der hier bereit gestellten Liste, zeigen sich schon die später zur Virtualisierung zur Verfügung stehenden LUNs. In der Testumgebung ist es mir bisher nicht gelungen hier später noch einmal Modifikationen vor zu nehmen. Insofern ist dies die Stelle an der das LUN Design der vorangegangenen Schritte in Erscheinung tritt. Es sollte hier passen und den ursprünglichen Annahmen entsprechen.

Das betrifft auch den System Datastore, auf dem die VSA vorgehalten werden soll. Bei größeren Server- Systemen bietet sich hier gegebenenfalls auch die Installation auf eine SD- Karte an. Danach trifft man noch die notwendigen Netzwerkeinstellungen und setzt die User Credentials. Bei vorhandener Domänen- Integration kann man hier auch schon AD- User, z.B. den hier im Lab verwendeten RFC821/vsaadmin verwenden. Im Hinblick auf Management personalisierter administrativer Zugriffsrechte eine sehr charmante Option.

Zu guter Letzt erhält man die Rückfrage nach weiteren zu installierenden VSA- Appliances, die man in einem einzigen Rollout Vorgang verteilen könnte. Schließt man die System- Vorbereitung ab erhält man eine Summary der vorgesehenen Installationsschritte und kann diese final bestätigen. Danach kann man entspannt eine Tasse Kaffee Trinken gehen und den Wizzard die Arbeit erledigen lassen. Der Fortschritt wird dabei ebenso protokolliert wie das Endergebnis.

Nach Beendigung der Installation steht auf dem Management System ebenfalls die CMC Management Konsole zur Verfügung. In der alle weiteren Konfigurationen vorgenommen werden. Ein direkter Zugriff auf die VSA Appliance ist augenscheinlich zu nächst nicht möglich.

Central Management Console – System Initialisation

Nach dem Login auf der CMC findet man zunächst eine sehr leere Ansicht vor, die unter “getting started” dazu einlädt zunächst die zu verwaltenden Systeme zu finden und diese danach in einer Management Gruppe zu organisieren.

 

Zunächst also die Suche der VSA Appliances durch Bereitstellung der IP- Adressen und der entsprechenden Admin User. Das ist auch an dieser Stelle gegebenenfalls ein amdinistrativer Storage- Funktionsuser aus dem Aktive Directory.

Ist das System gefunden, kann es hier in die Verwaltung übernommen werden. Bis auf Weiteres steht hier jedoch nur eine Basis- Funktionalität zur Verfügung. Aufsetzend auf die erste Appliance kann jetzt die Management Gruppe angelegt werden.

In diese muss sich der geneigte Storage- Admin dann bei der weiteren Verwaltung auch jeweils neu anmelden, um tatsächlichen Zugriff auf die Appliances zu erhalten. Alle Konfigurationen erfolgen innerhalb der Management Gruppe. Hat die VSA zu diesem Zeitpunkt keinen “grünen” RAID Status, bricht die Anlage der Management Gruppe mit einem Fehler ab.

Ist der Status grün und läuft die Erzeugung der Management Gruppe fehlerfrei durch, sollte in der CMC danach linker Hand ein etwas umfangreicheres Management Menü sichtbar werden, in dem weitere Konfigurationen, insbesondere wie die Anlage von Ziel- Servern für iSCSI Verbindungen oder die Bereitstellung von Storage Volumen erfolgen.

In den Übergeordneten Funktionen stehen eine granularere Rechteverwaltung und die Software Release Kontrolle, bzw. die Firmware Maintenance zur Verfügung. Während der Installation ist jetzt ein guter Zeitpunkt sowohl die CMC als auch die angeschlossenen VSAs zu aktualisieren.

Preparing iSCSI Connections and attaching a virtualized LUN

Um den bereitgestellten Storage auch nutzen zu können müssen zunächst iSCSI Verbindungen zwischen ESX und VSA zu gelassen werden. Dazu erzeugt man zunächst auf dem VMWare Host unter Konfiguration – Speicheradapter einen iSCSI Software Adapter.

Dieser erhält in seinem Kontext sowohl eine gegebenenfalls individuelle Netzwerk Konfiguration und sollten genügend Ethernet Portgruppen zur Verfügung stehen auch eine eigene externe Netzwerk Anbindung.

Dabei wird auch die sogenannte iqn vergeben, eine iSCSI spezifische Adresse mit der dieser Konnektor später authentifiziert werden kann. Für eine verschlüsselte Authentifizierung steht dabei noch CHAP als Option zur Verfügung.

Mit dieser iqn legt man in der CMC der VSA im Kontext der Management Gruppe den jeweiligen Server an.

Hat man auch schon ein Storage Volume vorbereitet, kann man dieses im Server Kontext gleich auch dem jeweiligen Host zuweisen.

Im Kontext des einzelnen Volumen wird dabei die Art des Provisioning – Thin oder statisch – sowie die verschiedenen Network RAID Level definiert. Hier wird nach dessen Erzeugung auch fest gelegt, welche der zuvor angelegten Server eine Verbindung zu dem Volumen herstellen dürfen.

Stehen die Ressourcen bereit, kann auf der ESX Seite der iSCSI Adapter über eine statische oder dynamische Erkennung den iSCSI Host der VSA verbunden werden.

Ist diese Verbindung etabliert,  kann in der Hostkonfiguration unter Speicher / Datastores mit “Speicher Hinzufügen” die Suche nach neuen Storage Volumen gestartet werden. Das eben angelegte Volumen wird hier gefunden,

Und kann damit als Datastore angelegt, mit VMFS-5 formatiert und dem Host als Storage- Ressource zur Verfügung gestellt werden. Das führt zu dem seltsamen Nebeneffekt, dass natürlich die virtualisierten Datastores in regulären Datastores liegen, die damit von Beginn an voll sind. Entsprechend sollte die Alarmierung auf diesen Bereichen deaktiviert werden.

Der virtualisierte Storage gibt sich als “LEFTHAND iSCSI….” zu erkennen und kann regulär genutzt werden.

Ab diesem Punkt kann man effektiv mit Testen beginnen und zum Beispiel eine Erste virtuelle Maschine vom klassischen Datastore in den Virtualisierten verlegen.

Test bestanden. Anlage läuft.

WTF ???

Warum der Aufriss? Ich mache aus völlig intakten Datastores, volle Datastores, die ich mit einem rechten Aufwand dann doch wieder den gleichen Hosts zur Verfügung stelle?

Erst einmal ist das nicht wirklich ersichtlich. Der Mehrwert entsteht wenn mehrere dieser Appliances im Einsatz sind, oder eben gegebenenfalls ein physikalischer Storage aus der gleichen Familie.

Über die VAAI Integration mit VMWare, bzw. die Anwendungsintegration über die einschlägigen Backup Mechanismen, können konsistente Snapshot Backups auch von online Daten mit jetzt “Bordmitteln” erzeugt und weg geschrieben werden. Die verschiedenen Netzwerk RAID Modi, erlauben es online Daten auf verschiedenen Hosts synchron zu halten, ohne einen teuren Enterprise Shared Storage zu verwenden. Diese Daten liegen dabei sehr nahe am Ort der Verarbeitung und üblicherweise profitieren die Anwendungen hinsichtlich Performance von diesen Mechanismen.

Steigt der Bedarf an Sicherheit können die am Host angelegten Snashots per Snapshot export auf weitere Appliances oder gegebenenfalls auf einen physischen Storage exportiert werden. Damit ergeben sich drastisch vereinfachte und in der Anlaufzeit teils extrem verkürzte Desaster- Szenarien.

Und  das unter Beibehaltung aller Anforderung an Konsistenz und Medienbrüche.

Im täglichen Leben können kurzfristig und einfach Systemkopien für Test und Entwicklung oder zur Qualitätssicherung online erzeugt werden.

All diese Funktionen, die bisher den klassischen Storage Systemen vorbehalten waren, da VMWare Snapshots in diversen Fällen doch wieder eine physische Kopie erzeugen, wandern in ihrer Funktionalität in den Host mit seinem direkt angeschlossenen Storage.

Meiner Meinung nach wirklich “the next big thing!”. Und es ist gar nicht so schwer. Der Prototyp mit dem steilen Teil der Lernkurve und wirklich diversen Iterationen, war in maximal drei Tagen fertig gestellt und dabei waren insbesondere die Firmware Themen durchaus Laufzeit behaftet.

Insofern, viel Spaß beim nachbauen

… kyp. F.