Musings on Hyperconverged Infrastructure

Nachdem die letzten Postings eher an der Oberfläche gekratzt haben, jetzt mal ein paar Grundsätzliche Gedanken zum Thema Hyperkonvergenz und einiger Ableitungen.

Noch einmal die strategischen Ziele: Hyper- converged – die gleichzeitige Virtualisierung von Server und Storage Ressourcen in einem in jeder Hinsicht Software gesteuerten Hypervisor Umfeld. Die erste Ausprägung des Software Defined Datacenter (SDD). Wesentliche Merkmale sind die Flexibilisierung der Ressourcen vereint mit einer granularen Skalierbarkeit. Redundanzen werden auf der Ebene der jeweiligen Virtualisierung geschaffen. Die Systeme sind recht “moderat” zugeschnitten und bei einem wachsenden Bedarf an …entweder Storage, I/O oder CPU – Memory wird einfach ein weiterer Knoten in die jeweilige Farm mit hinzu gefügt.

Heute betrachtete Storage Volumen liegen typischerweise im Bereich aktueller Server Ausstattung. Großer monolithischer Storage Bedarf bleibt meiner bescheidenen Meinung nach, eigentlich wenigen wirklich großen Server- Landschaften vorbehalten. Und nahezu jeder Hardware Hersteller hat ein so breites Portfolio, dass man den Ausstattungsregler von Storage zu CPU zu Memory zu Bandbreite so schieben kann, wir man es im Individuellen Zuschnitt braucht.

Darauf setzen moderne Betriebskonzepte mit “Storage” integriertem Snapshot Backup, remote Replikation der Snapshots, online Failover auf einen zweiten (dritten …) Server- Knoten und granulare Skalierbarkeit des Storage sowie unabhängig davon der CPU und Memory Ressourcen.

Bleiben drei wesentliche Ressourcen Bereiche zu betrachten:

  1. Virtualisierung und Verteilung der Server- Ressourcen CPU und Hauptspeicher.
  2. Virtualisierung der Kommunikation und Netzwerkanbindung.
  3. Virtualisierung der zu Grunde liegenden Speicher Ressourcen.

Im Bereich der Server Virtualisierung  sind die wesentlichen Technologien mittlerweile Allgemeingut. VMWare bietet mit vMotion den online Umzug eines virtuellen Gastes von System zu System an, Microsoft nennt die Funktion live migration und Linux KVM bzw. artverwandte Distributionen kennen das Feature unter gleichem Namen. Damit ist die mehr oder minder automatische Lastverteilung der Gast- Systeme gegeben.

Virtualisierung der Netzwerkanbindung bzw. der I/O Kanäle: Netzwerk- Virtualisierung ist lange nicht so genannt worden, aber im Grunde seit der Einführung von VLANs mit IEEE 802.1q ein “alter Hut”. Die konsequente Fortsetzung der Technologie für voneinander unabhängige VLAN Wolken, wie sie in Multi- Mandanten Umgebungen benötigt werden, sind unter dem Stichwort QinQ bei diversen Herstellern zu finden. Die Hypervisor Hersteller tragen dem Thema mit verschiedenen virtuellen Switches Rechnung, wie z.B. dem distributed vSwitch von VMWare oder auch der Öffnung der Plattform für klassische Netzwerkausrüster, die mit eigenen virtuellen Switches wie z.B. dem CISCO Nexus 1000v, verschiedene Hypervisor versorgen können. Die Storage Anbindung erfolgt meist ohnehin abstrahiert auf Basis des Hypervisor.

Bleibt als kritischer Faktor die Versorgung mit Storage Ressourcen, und hier liegt im wesentlichen “der Hase im Pfeffer”. Warum? Weil – Flacher Freitag ist morgen – weil Daten leben.

Motivation Software Defined Storage

Und diese Veränderung muss zeitnah, da sonst die Anwendungen leiden, langsam werden und die User unzufrieden machen, auf ein persistentes Medium – die Festplatte gebracht werden. Um die Unabhängigkeit der Host Hardware aus Punkt 1 zu gewährleisten, müssen sich alle in Frage kommenden Hosts einen Speicherpool teilen, so das andere Server- Knoten im Falle der Übernahme eines virtuellen Server- Gastes auf dessen Daten und Installation zu greifen können. Je monolithischer der Speicher, um so teurer meistens der Storage. Damit aber nicht genug, um dem Ausfall dieses großen zentralen Elementes vor zu beugen, muss dieser Storage meistens online auf ein zweites System – oder eine räumlich getrennte Hälfte des selben Systems, gespiegelt werden. Und damit hat man noch keinen Medienbruch herbei geführt, der ein ganz wesentliches Element eines belastbaren zuverlässigen Backups ist und der vor wirklich elementaren Schäden schützt.

Dieses mehrmalige kopieren der Daten, wirkt normalerweise (in unterschiedlichem Umfang) bis in die Anwendung, da diese insbesondere bei transaktionalen Anwendungen (Datenbanken, eMail, …) in einem konsistenten Zustand für eine mögliche Wiederherstellung sein müssen und dies mit einer Unterbrechung oder zumindest Zwischenspeicherung in der Zeit des Synchronisierens einher geht.

Storages die so etwas können sind groß und teuer und meistens eben wenig flexibel. Kommt die Forderung nach granularer Skalierbarkeit hinzu, macht es das meist nicht besser.

An der Stelle kommt ein wesentliches Element der Virtualisierung zum Tragen. Die Hypervisor kennen schon ein Abstraktionsebene des bereit gestellten Speicherplatzes und können auf dieser Schicht referenzielle Stände einfrieren – sogenannte Snapshots – bei welchen neu geschriebene Daten auf einen neuen Speicherblock geschrieben werden und der vorherige, eingefrorene Stand bis auf Weiteres aufbewahrt wird.

Findet dies ausschließlich auf der Virtualisierungs- Ebene statt, erzeugt dies beim “Abtransport” der Daten auf ein unabhängiges Medium Leistungsspitzen die oft und mit wachsender Größe der Installationen problematisch werden.

Daher haben alle Storage- Hersteller zwischenzeitlich eine direkte Unterstützung solcher Verfahren in ihre Systeme integriert. VMWare stellte hierfür über die sogenannte Array Integration VAAI als erster Virtualisierer eine Schnittstelle zur Verfügung, alle anderen zogen nach. Aus Sicht der Storage Hersteller ein lohnendes Geschäft, da hierfür noch mehr Speicherplatz benötigt wird.

Paradigmenwechsel Storage Virtualisierung

Wurden die funktionalen Fallstricke der Storage Bereitstellung in virtuellen Umgebungen in den letzten zehn Jahren nach und nach gelöst und Technologien entwickelt, welche zuvor ungeahnte Möglichkeiten erlauben, läuft die traditionelle Variante der Storage Konsolidierung dem tagesaktuellen Bedarf zu wider.

Grundsätzlich steigt der Speicherplatz- Bedarf tatsächlich und kontinuierlich weiter. So dass die realen Anforderungen an monolithische Systeme die Aufwände und Kosten hier ins Grenzenlose treiben. Damit erreicht man in einer entsprechenden Wachstumsstrategie sehr unangenehme Szenarien, in welchen man entweder große Leerstände zu betreiben hat, immense Sprungfixe Kosten bei Erweiterungen der großen Storage Systeme abdecken muss und auch technologisch in Sackgassen gerät die sich darin Begründen dass, auch die Volumen transaktionaler Daten so groß werden, dass sie im Bereich Backup, oder zumindest Restore in Zeitrahmen nicht mit dem Betrieb der umgebenden Systeme vereinbar sind. Dabei entstehen Kosten die weder mit dem Datenwachstum noch mit den landläufig bekannten Preisen für Speichermedien / Festplatten irgendwie vereinbar sind.

Die Antwort heißt schon analog zur Server- Virtualisierung scale out. Das ginge sicher auch mit kleineren funktional entkoppelten Speichersystemen, aber hier überholt sich die Technologie selbst. Im Bereich der Server- Hardware haben sich in den letzten drei Jahren Packungsdichten und I/O Leistung entwickelt, welche die Trendwende hin zur Datenhaltung direkt am Ort ihrer Verarbeitung, bewirkt haben.

Man muss die Daten nicht mehr umständlich irgendwohin transportieren um sie zu verarbeiten. Die Virtualisierung der Speicher- Ebene im Hypervisor liegt seit geraumer Zeit vor und die typischen Storage Funktionen werden hier zusehends durch Erweiterungen einzelner Eigenschaften eingebracht. Die Virtualisierung des Storage ergibt sich hier aus der Notwendigkeit dies grundsätzlich zunächst ohnehin zu tun. Damit kann man diesen Weg grundsätzlich auch zu Ende gehen und sich von traditionellen Storage- Konzepten verabschieden und die vollständige Funktionalität in die Virtualisierungs- Schicht legen.

Das entlastet die Performance Budgets der einzelnen Systeme, und man kann seinen Storage Bedarf in ähnlich kleinen Schritten erweitern, wie man es zuvor mit den Servern schon getan hat.

Alleine die etablierten Hypervisor Hersteller haben hier bisher keine allzu etablierten Lösungen. VMWare ist auch hier mit vSAN der Vorreiter, jedoch sind die Anforderungen an den Cluster mit vier Knoten zunächst recht hoch und die Funktionalität ist im aktuellen vSphere 5.5. noch nicht so umfangreich wie es wünschenswert wäre um vollständige Funktionalität her zu stellen.

An der Stelle knüpfen aktuell die Newcomer an und mischen den Markt gründlich auf. Hersteller wie Nutanix und Simplivity haben den Markt stark aufgemischt und konnten Trend der hyper- convergence Nutzen, indem sie als Erste granulare Server Technologie, IO Virtualisierung und verteilte Storage Konzepte miteinander verheiraten konnten. Insbesondere in Umfeldern, welche keine weiteren Lizenzkosten durch VMWare oder Microsoft erzeugen – wie zum Beispiel große Linux basierende Web Farmen, haben diese Lösungen einen extremen Charme.

Rückt man in den Bereich eher klassischen IT Betriebes, mit einseitigen Last Szenarien auf der Storage Seite und einer klassisch gemischten Lizensierung verschiedener Software Ebenen nach unterschiedlichen Kostenmodellen (wer gerne verzweifeln möchte, darf gerne das Kleingedruckte bei Oracle zum Thema Lizenzierung in virtuellen Umgebungen lesen), werden die Use- Cases der reinrassigen Appliances schnell ebenfalls negativ in der Kosten Nutzen Bewertung.

Damit haben die klassischen Server Hersteller, bzw. diejenigen welche auf ein flexibles Storage Konzept setzen, die Möglichkeit erhalten auf zu schließen. HP konnte mit dem System 200-HC die Lücke zwischen traditionellen Servern und Hyper- konvergenten Appliances schließen, bringt zugleich den Vorteil der Erweiterungen aus seinem reichhaltigen Server Portfolio mit.

Parallel dazu hat der Hersteller aus Cupertino eine eigene Software zur Storage- Virtualisierung am Start, die HP Virtual Storage Appliance – VSA. Der Charme diese Lösung ist, dass sie keine komplette Neuentwicklung ist, sondern das virtualisierte Betriebssystem der HP P4000 Storage Systeme. Die Funktionen entsprechen denjenigen eines vollwertigen Storage Systeme, alleine sie laufen als zusätzliche Software Schicht auf dem Hypervisor und abstrahieren den lokalen Storage.

Snapshot- Funktionen sowie deren Export auf gegebenenfalls sogar physische Storage Systeme kommen eben so mit wie die Cluster- Funktionen anderer Appliances im Server Verbund. Die vollständige Integration in VMWare Management und vCenter auch über die Storage Management Konsole ist Stand heute gegeben.

Mir ist kein anderer Hersteller bekannt, der das so vollständig integriert, auch wenn es erste andere unabhängige Storage- Virtualisierer gibt, die in verschiedenem Maß klassische Storage Architektur auf Commodity Hardware nach bauen.

Fazit 

Hyper- Konvergenz in der Infrastruktur ist ein Fakt und nicht mehr nur eine Hype einiger Nischenprodukte. Die dahinter stehenden Software Konzepte sind weit gereift und funktionieren in vielen verschiedenen Anwendungsfällen sehr gut und gegebenenfalls auch sehr spezifischen Vorteilen.

Der wesentliche Aspekt ist dabei meistens die Storage Architektur, da hier die Virtualisierungs- Konzepte noch am jüngsten sind, aber gleichzeitig die Architektur bestimmenden Anforderungen und Eckdaten den häufig größten Einfluss auf Leistung, Funktionalität und Kosten haben.

Die Technologie Software definierter Speicher Systeme hat dabei einen hohen Reifegrad erreicht, der in Teilen aus der Übertragung etablierter langjähriger Entwicklung her rührt. Dem Gegenüber stehen die Implementierungen völlig neuer Konzepte, die frei von alten Architekturen und Bedürfnissen auf heutigem Stand der Technik schon auf einige Jahre am Markt zurück blicken können.

In jedem Fall lohnt sich der Blick auf Software definierten Storage, selbst wenn man mit einer traditionellen Lösung den Einstieg in eine granular skalierbare Lösung sucht, auch wenn die Klassiker FalconStor und DataCore sowie der nicht ganz so klassische Kandidat Nexenta hier nicht im Detail berücksichtigt wurden.

Kombinationen der Technologien sind im Software Definierten Umfeld ja durchaus denkbar.

Kyp.F.

p.s. Ich habe bewusst alle Automatisierungs- Aspekte außen vor gelassen. Diese kommen dann in einem eigenen Post.

Leave a Reply