Cisco Hyperflex 3.0 im Praxistest
Flexibel skalierbare HCI-Plattform
Cisco bietet mit Hyperflex 3.0 eine hyperkonvergente Lösung auf Basis der hauseigenen UCS-Plattform an. Die HCI-Appliances sind als Converged Nodes mit integriertem Storage sowie als reine Compute-Nodes erhältlich. Über den UCS Manager lassen sich die Systeme weitgehend automatisiert bereitstellen und verwalten.
Im stark wachsenden Marktsegment der HCI-Lösungen (Hyperconverged Infrastructure) mischt seit einiger Zeit auch Cisco mit. Das Unternehmen hat sich an dem HCI-Startup Springpath beteiligt und die Firma im Jahr 2017 übernommen. Hyperkonvergente Systeme stellen auf Basis von x86-Standard-Servern Rechenleistung, Speicherkapazitäten und Netzwerkanbindung ausfallsicher zur Verfügung. Je nach Hersteller werden für einen HCI-Cluster mindestens zwei oder drei Appliances benötigt. Vor einem Datenverlust schützen Mechanismen, die jeden Datenblock auf zwei oder mehr Knoten des HCI-Verbundes redundant speichern. Wichtigstes Einsatzgebiet für HCI-Lösungen ist die Server- und Desktop-Virtualisierung.
Cisco hat die Hyperflex-Software sehr eng in die eigene UCS-Plattform (Unified Computing System) integriert und bietet die Lösung ausschließlich mit UCS-Server-Hardware an. Als Hypervisor-Plattform unterstützt Hyperflex derzeit VMware ESXi und Microsoft Hyper-V. Die Hyperflex Data Platform stellt den Software-Layer für HCI bereit. Über UCS lassen sich die Systeme automatisiert ausrollen und verwalten. Beide Komponenten zusammen bilden die Hyperflex Dynamic Data Fabric. Die Hyperflex-Appliances müssen über Fabric-Interconnect-Switches von Cisco mit dem Netz verbunden werden. Wenn ein Unternehmen bereits UCS einsetzt und noch genügend freie Fabric-Interconnect-Ports hat, kann es die Hyperflex-Systeme an die vorhandenen Switches anschließen.
Intent-Based Data Center
Die Hyperflex-Appliances sind Teil der übergreifenden Cisco-Strategie des "Intent-Based Data Centers", die viele Bereiche wie Switches, Server, Software und Analytics umfasst. Ein wichtiger Teil dieses Ansatzes ist der sogenannte Desired State der jeweiligen Komponenten. Das Intent-Based Data Center soll automatisch dafür sorgen, dass alle beteiligten Elemente dem gewünschten Zielzustand entsprechen. Intelligente Analysealgorithmen sollen dabei helfen, Infrastrukturprobleme bei Bedarf schneller zu lösen.
Für die Verwaltung der Hyperflex-Systeme spielt der UCS-Manager eine zentrale Rolle. Die USC-Software läuft direkt auf den Fabric-Interconnect-Switches und verwaltet alle daran angeschlossenen UCS-Systeme. Mit den UCS-Service-Profilen erhalten neu hinzugefügte Hyperflex-Appliances automatisch die vom Administrator im jeweiligen Profil definierte Konfiguration.
Um mehrere HX-Cluster zu managen, bietet Cisco die relativ neue Lösung Intersight an. Sie soll mittelfristig die bisherigen Einzeltools ersetzen. Eine umfassende Automatisierung der kompletten RZ-Infrastruktur ist mit der Management-Plattform UCS Director möglich. Cisco treibt zudem die Integration der Hyperflex-Appliances mit anderen Plattformen voran. Zu nennen sind hier beispielsweise Kubernetes, der SAP Data Hub oder Security-Lösungen.
Mit Converged- und Compute-Nodes flexibel skalierbar
HCI-Lösungen sollen die Komplexität der RZ-Infrastruktur reduzieren und in der Lage sein, die jeweils benötigten Ressourcen schnell bereitzustellen. Die Hyperflex-Software verfolgt diese Ziele, indem sie zum einen auf der HX-Plattform möglichst viele Funktionen anbietet und sich gut in die UCS-Infrastruktur integriert.
Zum anderen kann man zu einem Hyperflex-Verbund reine Compute-Nodes hinzufügen, um die Rechenleistung bedarfsgerecht zu erhöhen. Die CPU- und RAM-Ausstattung lässt sich auf diese Weise unabhängig von der Speicherkapazität skalieren. VMs mit einem hohen Ressourcenbedarf können auf leistungsfähigen Compute-Nodes laufen, während die Lösung die zugehörigen Daten weiterhin auf den Converged Nodes des Clusters speichert.
Cisco nennt die Hyperflex-Rack-Server, die Storage und Compute bereitstellen, Converged Nodes und nicht Hyperconverged, weil die externe Netzwerk-Anbindung über die Fabric Interconnects erfolgt. Die virtuellen Switches für die Netzwerkkommunikation der VMs laufen aber auch hier wie bei HCI-Lösungen üblich in der auf den Hyperflex-Nodes installierten ESX- oder Hyper-V-Software. Die Compute-Nodes werden an die Fabric-Interconnect-Swiches angeschlossen und stellen ihre Rechenleistung dem Hyperflex-Verbund zur Verfügung.
Für die Converged Nodes sollte man Server mit identischer Hardwareausstattung einsetzen, um eine gleichbleibende Performance über den Gesamtverbund hinweg zu gewährleisten. Bei den Compute-Nodes ist ein Mix aus unterschiedlichen Rack- und Blade-Modelle zulässig.
All-Flash- und Hybrid-Modelle
Der Einstieg in die Hyperflex-Welt beginnt bei drei Appliances. Im Maximalausbau unterstützt die Lösung derzeit 64 Nodes, die sich auf 32 Converged Nodes und 32 Compute Nodes verteilen. Die aktuelle UCS-Hardware besteht aus M5-Servern mit Skylake-Prozessoren. Für Converged Nodes bietet Cisco die Rack-Modelle HX220c mit einer Höheneinheit und HX240c mit zwei Höheneinheiten an. Dieselben Modelle sind bislang auch mit der älteren M4-Hardware erhältlich. Als Compute-Nodes unterstützt Cisco Rack- und Blade-Server der M4- und M5-Generation.
Die Converged Nodes lassen sich als All-Flash- oder als Hybrid-System konfigurieren. Hybrid bedeutet bei Hyperflex, dass das System die Daten immer auf HDD speichert und die SSDs nur für das Caching nutzt. In der kleinsten Konfiguration bietet ein HX-Cluster mit drei Nodes eine nutzbare Speicherkapazität von etwa 5 TByte. Im Maximalausbau kann ein HX-Verbund je nach gewähltem Laufwerkmodell mehrere hundert TByte zur Verfügung stellen. Die standardmäßig durchgeführte Komprimierung und Deduplizierung erhöht die tatsächliche Speicherkapazität abhängig von den eingesetzten Anwendungen zum Teil beträchtlich.
Für kleinere Außenstellen bietet Cisco mit dem HX220c Edge Cluster eine Variante an, die keinen Fabric Interconnect Switch vor Ort benötigt. Die Edge-Systeme muss der IT-Verantwortliche über das WAN an die Hyperflex-Lösung in der Zentrale anbinden.
Hyperflex Data Platform
Den LANline-Test der Hyperflex-3.0-Lösung führten wir im Cisco Demolab in Garching bei München durch. Der Hyperflex-Test-Cluster bestand aus vier All-Flash-Appliances vom Typ HXAF240C, die mit jeweils elf SSDs bestückt waren und eine nutzbare Speicherkapazität von knapp 11 TByte bereitstellten. Als Hypervisor-Plattform kam VMware ESXi zum Einsatz. Cisco liefert die HX-Appliances mit vorinstalliertem ESXi- oder Hyper-V-Betriebssystem aus. Die Installation der HX-Software erfolgt bei der VMware-Variante über das vCenter, indem die HX-Installer-VM als OVA-Datei importiert wird. Im Setup-Wizard dieser VM konfiguriert der Administrator zunächst die Verbindung zum UCS-Manager und installiert anschließend mithilfe der vom Installer angelegten Service-Profile die HX-Nodes.
Anschließend konfiguriert er auch die IP-Adressen und die vCenter-Anbindung. Zudem erhält jede Appliance eine HX-Controller-VM, die sich eng in den darunter liegenden Hypervisor integriert. Die Verwaltung des Hyperflex-Clusters erfolgt über diese Controller-VMs. Sie liegen auf demselben RAID-1-Volume, auf dem der Hypervisor läuft. Für Hyper-V gibt es ebenfalls eine Installer-VM, um das HX-Setup analog zu dem mit ESXi beschriebenen Vorgehen durchzuführen.
Für das Management der Hyperflex-Systeme steht die grafische Oberfläche HX Connect zur Verfügung, die auch Kommandozeilen-Tools und REST-APIs unterstützt. Es ist zudem eine Integration mit dem VMware vCenter sowie mit dem Hyper-V-Manager und dem SCVMM (System Center Virtual Machine Manager) von Microsoft möglich.
Objektbasiertes Filesystem
Die Hyperflex-Appliances verwenden ein objektbasiertes Distributed Filesystem. Das HX Log Structured Filesystem ist für Scale-out-Szenarien konzipiert und stellt zahlreiche Datendienste zur Verfügung, die für moderne Anwendungen wie zum Beispiel Container optimiert sind. Vor einem Verlust von Daten schützt die HX Dynamic Data Distribution. Die Controller-VMs verteilen die zu schreibenden Daten als kleine Chunks gleichmäßig über alle Nodes. Dabei legen sie von jedem Daten-Chunk eine oder zwei Kopien auf anderen HX-Nodes ab. Mit drei Chunk-Versionen kann das System den Ausfall von zwei Appliances kompensieren, ohne dass Daten verloren gehen. Neue HX-Nodes lassen sich im laufenden Betrieb ohne Unterbrechung hinzufügen. Die HX-Software konfiguriert ein hinzugefügtes System automatisch und führt ein Rebalancing der verteilten Daten durch.
Die Daten werden während des Schreibvorgangs automatisch inline komprimiert und dedupliziert. Die verteilte Datenhaltung hat zudem den Vorteil, dass bei einer Migration von VMs innerhalb eines Clusters nicht nötig ist, Daten zu migrieren, weil sie bereits gleichmäßig über alle Nodes verteilt sind. Ein weiterer Vorteil besteht darin, dass nach dem Ausfall einer HDD oder SSD sowie beim Rebuild keine höheren Latenzzeiten auftreten, weil die Daten verteilt gespeichert sind. Die HX-Software führt auch in diesem Fall automatisch ein Rebalancing durch.
Hochverfügbarkeitszonen
Mit den Automated Availability Zones stellt Hyperflex 3.0 einen Mechanismus bereit, der sogar bei einem Ausfall von drei Nodes vor Datenverlusten schützt. Möglich wird dies durch eine logische Gruppierung der HX-Systeme. Wenn ein Cluster beispielsweise aus neun Nodes besteht, kann der Administrator drei Availability-Gruppen mit je drei Nodes einrichten. Die HX-Software speichert dann die erste Kopie der Daten in einer anderen Zone als das Original und die zweite Kopie in einer anderen Zone als die erste Kopie.
Eine weitere HX-3.0-Neuerung sind Stretched Cluster über zwei Standorte hinweg. Die WAN-Verbindung muss über eine Bandbreite von 10 GBit/s verfügen, die Round Trip Time darf fünf Millisekunden nicht übersteigen. Der Cluster läuft im Active-Active-Modus und führt eine synchrone Replikation der gespeicherten Daten durch. Die Daten-Chunks werden auf jeder Seite doppelt gespeichert. Pro Standort sind derzeit maximal acht HX-Nodes möglich, die alle identisch konfiguriert sein müssen. Die Stretched-Cluster-Funktion steht bisher nur für HX-Systeme mit ESXi-Hypervisor zur Verfügung.
Für die Notfallvorsorge unterstützt Hyperflex zudem eine asymmetrische Datenreplikation zu einem entfernten Standort, die sich für einzelne VMs oder für Protection Groups aktivieren lässt. Eine Replikation ist auch zwischen unterschiedlichen HX-Modellen möglich. Alternativ kann der Administrator die Backup- und Recovery-Produkte von Commvault und Veeam nutzen, die Cisco mit Hyperflex integriert hat.
Leistungsfähige Clone- und Snapshot-Funktionen
Um die Hyperflex-Funktionen zu testen, verwendeten wir das HX-Connect-Tool und das vCenter-Plugin. Damit lassen sich unter anderem Snapshots und Clones erstellen, neue VMs bereitstellen sowie vorhandene VMs ein- und ausschalten. Zunächst rollten wir über das vCenter eine neue VM per Template aus. Die VM wurde erfolgreich auf dem Hyperflex-Cluster erstellt und automatisch gestartet. Anschließend erzeugten wir von dieser VM einen nativen Hyperflex-Snapshot. Dieser verwendet einen Pointer-basierten Mechanismus und ist dadurch effizienter und schneller als die Log-basierten VMware-Snapshots. Sobald das System für eine VM den ersten HX-Snapshot erstellt hat, verwendet Hyperflex für alle künftigen Snapshots den HX-Mechanismus. Mit der Ready-Clones-Funktion kann Hyperflex zudem von einer bestehenden VM innerhalb kurzer Zeit eine größere Zahl an Clones erstellen, die sich als eigenständige VMs nutzen lassen. Im LANline-Test konnten wir sowohl native HX-Snapshots als auch Clones erfolgreich erstellen.
Um die Redundanzmechanismen von Hyperflex zu testen, schalteten wir einen HX-Node über den UCS-Manager hart aus. Die vom Ausfall betroffenen VMs wurden nach einigen Sekunden von den verbliebenen drei HX-Systemen neu gestartet. Wenn ein ausgefallener Node länger als zwei Stunden offline ist, führt die HX-Software automatisch ein Rebalancing der Chunks durch. Der Administrator kann den Rebalance-Vorgang auch manuell per Kommandozeile anstoßen, zum Beispiel wenn absehbar ist, dass die Reparatur des ausgefallenen Nodes mehrere Stunden dauert. Nachdem wir den ausgefallenen HX-Node eine halbe Stunde später wieder online gebracht hatten, stand der HX-Cluster wieder normal zur Verfügung.
Fazit
Die Hyperflex-Lösung von Cisco ermöglicht durch ihre Integration mit dem UCS Manager und seinen Service-Profilen eine weitgehend automatisierte Bereitstellung und Skalierung der HX-Appliances. Die CPU- und RAM-Ressourcen eines HX-Clusters lassen sich durch das Hinzufügen reiner Compute-Nodes bedarfsgerecht ausbauen. Um die Sicherheit der gespeicherten Daten zu gewährleisten, speichert Hyperflex bis zu zwei Kopien auf unterschiedlichen Nodes. Der neue Stretched Cluster und die Replikationsfunktionen können die Verfügbarkeit der Daten auch bei Standortausfällen sicherstellen. Das bei Platten- oder Appliance-Ausfällen sowie nach dem Hinzufügen neuer Nodes automatisch durchgeführte Rebalancing reduziert den Administrationsaufwand deutlich.
Die Kosten für eine Hyperflex-Lösung von Cisco dürften meist höher liegen als bei anderen Anbietern, weil für die Netzanbindung der Appliances zwei Fabric-Interconnect-Switches mit integriertem UCS Manager nötig sind. Cisco bietet Hyperflex in drei Editionen als Standard, Enterprise und Edge an. Preisinformationen sind auf Anfrage erhältlich.
Lesen Sie mehr zum Thema
