Web-artige Skalierbarkeit für Hyper-V-Umgebungen

Die Unterstützung von SMB 3.0 für die Virtualisierungs-Plattform Hyper-V auf Nutanix-Clustern ist ab der Version 3.5.2 des NOS gegeben. Der Lösungsansatz mit der Virtual Computing Platform eliminiert dabei einen wichtigen Flaschenhals: Die traditionelle Schnittstelle zwischen den Servern und dem Storage-Subsystem entfällt – und das gilt nun auch im Umfeld des Hyper-V.

Bei der „Virtual Computing Platform“ von Nutanix handelt es sich um einen Infrastruktur-Ansatz. Bei dem die Server- und die Storage-Schicht in einer einzigen Appliance zusammengelegt – konsolidiert – sind. Diese Plattform hat ihre extreme Skalierbarkeit – der Hersteller spricht sogar von einer Web-artigen Skalierbarkeit – bereits in VMwares ESXi- und den KVM-basierten Umgebungen unter Beweis gestellt.

Mit der aktuellen Version NOS 3.5.2 bringt Nutanix diese Vorteile nun auch in die Hyper-V-Welt (auf der Basis von Windows Server 2012 Release 2). Dabei wird auch das Protokoll SMB 3.0 (Server Message Block) im Speichersubsystem unterstützt.

Mit dieser Neuerung bietet Nutanix den Anwendern eine umfangreiche Wahl an Hypervisor-Umgebungen auf Appliance-Basis. Anwender sind somit in der Lage, auf verschiedenen Hypervisoren ihre Anwendungen und Arbeitslasten laufen zu lassen, wobei sie immer die passende Virtualisierungs-Plattform, Betriebssystemumgebung und Applikations-Lizenzmodell verwenden können.

Das Protokoll SMB war ursprünglich dazu gedacht, den netzwerkweiten Zugriff auf Dateifreigaben und andere Ressourcen im Netzwerk zu ermöglichen. In den Anfangszeiten der PCs wurde bei IBM das NetBIOS entwickelt – ein relativ einfaches Netzwerksystem für kleinere LANs. Microsoft hat dazu noch die Funktionalität der Disk-Ein-Ausgabeoperationen über das NetBIOS-Interface dazu gebracht. Damit wurden letztendlich die Festplatten über das LAN zugängig und – teilbar. Dieses Filesharing-Protokoll wurde als SMB bekannt – es gab aber auch die Bezeichnung CIFS (Common Internet File System).

Die Version 3.0 von SMB wurde bereits 2012 vorgestellt – und es war ein langer Weg von der ersten, doch recht beschränkten Version. Mit SMB 3.0 ist nun Funktionalität ins Spiel gekommen, um Dateiserver-Storage für den Hyper-V und Server-Anwendungen wie etwa den SQL Server zu unterstützen. Dabei ist von der Konzeption her auch vorgesehen, dass SMB  3.0 in hochvirtualisierten Umgebung mit entsprechend hoher Belastung eine vernünftige Performance offeriert wird.

Hochverfügbarkeit und SMB

Dazu gehören auch Hochverfügbarkeits-Funktionen und eine weite Skalierbarkeit in Bezug auf den Datendurchsatz. Auch wenn Netzwerkverbindungen ausfallen, ist über redundante Pfade sichergestellt, dass die Anbindung bestehen bleibt und eine Applikation somit weiter läuft. Eine detaillierte Übersicht ist von NT4ADMINS zu bekommen  — dazu muss ein Interessent nur eine Mail mit dem Betreff „Leseprobe SMB 3.0“ an service@nt4admins.de senden und bekommt dann einen ausführlichen Beitrag in Form eines PDFs zugesandt.

Betrachtet man die Speicherhardware, so eignet sich SMB 3.0 für verschiedenste Gerätegattungen – von einfachen JBODs (Just a Bunch of Disks) bis hin zu teuren SAN- oder Fibre-Channel-Lösungen. Doch egal welchen Ansatz man wählt, es bleibt immer der Flaschenhals beim Zugriff auf traditionelle Speichersubsysteme über das Netzwerk. Damit wird die Skalierbarkeit im Bereich des Datenspeichers massiv eingeschränkt.

Problembereiche traditioneller Storage-Ansätze

Die traditionellen Lösungen haben mit verschiedensten Problembereichen zu kämpfen – das geht von Overhead der Netzwerkprotokoll über die geteilte Bandbreite unter womöglich Hunderten von laufenden VMs (Virtual Machines), die auf den Datenspeicher zugreifen wollen, bis hin zu hohen Kosten für die einzelnen Storage-Arrays oder das einfache und inkrementelle Erweitern des Speicher-Subsystems.

Wer nicht über ein fast schon unbegrenztes IT-Budget verfügt und wer zudem viel Zeit für das Einsetzen und Verwalten der Speichersysteme aufbringen kann, der sieht sich recht schnell mit unüberwindbaren Problemen konfrontiert, wenn er traditionelle Speicherarchitekturen verwenden will. Denn diese Konzepte sind kaum in der Lage, die Zugriffsmöglichkeiten und Skalierbarkeit der Speicheranforderungen in virtualisierten Umgebungen zu erfüllen – vor allem wenn dazu noch Einsatzbereiche mit Big Data-Charakter dazu kommen.

Flaschenhals wird eliminiert

Der Lösungsansatz mit der Virtual Computing Platform dagegen eliminiert einen wichtigen Flaschenhals: Die traditionelle Schnittstelle zwischen den Servern und dem Storage-Subsystem entfällt – an ihre Stelle tritt eine Lösung, bei der ein Unified Storage Pool bereits auf der Server-Seite angelegt wird, der aus Flash-Speicher und lokal angeschlossenen Festplattenlaufwerken besteht.

Mit der Version 3.5.2 des NOS ist dieser Ansatz nun für alle relevanten Hypervisor-Umgebungen auf den Nutanix-Clustern einsatzfähig – also auch für den Hyper-V. Hier folgt die Konfiguration einem bekannten Konzept: Ein jeder Knoten im Cluster verwendet den Hyper-V als Virtualisierungs-Plattform und ein eigenständiger „Nutanix Controller“ – in einer eigenständigen virtuellen Maschine (VM) – wickelt sämtliche Ein- Ausgabeoperationen für den lokalen Hypervisor ab.

Damit steht ein hochverfügbares, zuverlässiges und durchsatzstarkes „Software defined Speichersubsystem“ zur Verfügung. Diese Komponente lässt sich nun auch als SMB-3.0-Freigabe ansprechen – zusätzlich zu den bereits seit längerem unterstützten NFS- und iSCSI-Schnittstellen. Ein jeder dieser Knoten stellt einen Server dar, der als Host einen Hyper-V beherbergt, der seinerseits über SMB 3.0 auf den Speicher zugreifen kann, um virtualisierten Speicher für die VMs der Benutzer (User Virtual Machines, UVM) bereitstellt.

Für die Anwender hat das zur Folge, dass sie hochskalierbare Server-Virtualisierungsprojekte und Virtual Desktop Infrastructure-Konfigurationen auf der Basis des Hyper-V und der Virtual Computing Platform realisieren können, aber auch Test- und Entwicklungsumgebungen sowie Big Data-Anwendungen (wie Hadoop– und Splunk-Umgebungen) profitieren davon. Denn es wird dabei kein traditionelles Storage-Subsystem über ein Netzwerk-Interface angeschlossen.

Dagegen werden die Funktionalitäten von SMB 3.0 – wie etwa der transparente Failover-Vorgang beim Client-Zugriff oder das ODX (Offloaded Data Transfer) sowie TRIM-Funktionalität (mit dem TRIM-Befehl teilt ein Betriebssystem dem Datenträger mit, welche Datenbereiche bereits als gelöscht markiert wurden).

Mit Hilfe des transparenten Failover-Vorgangs beim Client-Zugriff sind die UVMs auf einem Host mit Hyper-V inbder Lage, mit dem Speicher verbunden zu bleiben und weiter zu arbeiten, selbst wenn die Server mit einem ausgefallener Speicherkomponente kommunizieren wollen. Mit dem Failover-Mechanismus kann ein Hyper-V-Server sich selbst wieder „fangen“ und die Kommunikation mit einem anderen SMB-Server in einem Cluster initiieren, wenn der ursprüngliche ausgefallen ist.

Mit der Unterstützung der ODX-Funktionalität auf einem Nutanix-basierten Hyper-V-Cluster werden Kopier- und Verschiebeoperationen beschleunigt. Dazu lagert der Server die komplette Operation an das Speicher-Subsystem aus. Das ordnet die Lese- und Schreibzugriffe dann entsprechend an und muss dabei auch keine Daten mehr aus dem Server selbst lesen, sie zwischenspeichern und dann wieder zurückschreiben. so ergeben sich Geschwindigkeitsvorteile, aber dadurch wird auch die Serverbelastung (weniger CPU-Zyklen fallen für die Aufgabe an) reduziert, und es fällt deutlich weniger Server-Client-Netzwerkverkehr an.

Die bereits angesprochene TRIM-Funktionalität gehört auch zum Umfang von Nutanix-basierten Hyper-V-Clustern. Dabei ist das Betriebssystem in der Lage, die nicht aktiven Block-IDs an das Speicher-Subsystem zu melden. Dies versetzt den Speicher in die Lage, diese unbenützten Blöcke zu löschen. Diese Art der Garbage Collection spielt ihre Vorteile vor allem bei SSD-Laufwerken aus.

Rainer Huttenloher