Die Rolle von Appliance-basierter Storage-Virtualisierung

Peter Kruth

Executive Solution Principal
Huawei Deutschland

Pit’s IT Architecture Talk

#1 Die Rolle von Appliance-basierter Storage-Virtualisierung

Hinweis: Die in diesem Artikel zum Ausdruck gebrachten Ansichten und Meinungen sind die des Autors und spiegeln nicht notwendigerweise die offizielle Politik, Position, Produkte und Technologien der Huawei Deutschland GmbH wider. Wenn Sie mehr über die Produkte und Technologien der Huawei Deutschland GmbH erfahren möchten, besuchen Sie bitte unsere Produktseiten oder kontaktieren Sie uns.

Storage-Virtualisierung ist ein weit gefasstes Feld beim Speichern und Lesen von Daten. Es gibt Datei- und Block-basierte Technologien und man kann sie auf dem gesamten Weg zwischen RAM und permanentem Speicher einsetzen. Hier möchte ich mich auf das Enterprise-SAN, also auf Block-basierten Speicher konzentrieren.

Seit etwas mehr als 15 Jahren gibt es Lösungen, die physikalisch zwischen dem oder den Storage-System(en) und den Compute-Servern (Hosts) eingesetzt werden. Das heisst, dass die Host-Systeme sich auf die Virtualisierungs-Appliance verbinden und diese die Storage-IO-Requests beantwortet. Im Hintergrund kommuniziert die Appliance mit dem Storage-System. Für den Host ist das Storage-System unsichtbar.

Ein Read-Request geht vom Host zum SAN-Switch und von dort zur Virtualisierungs-Appliance. Sofern die angeforderten Daten sich im Appliance-Cache befinden, kann die Appliance den Request direkt beantworten. Im anderen Fall muss die Appliance die Daten beim Storage-System anfordern und kann anschließend den Request zum Host beantworten.

Ein Write-Request verhält sich ähnlich. Sofern genügend Cache in der Appliance zur Verfügung steht, wird der Write-Request sofort zum Host beantwortet und später zum Storage-System weitergegeben – delayed write. Im anderen Fall, also wenn der Cache in der Appliance bereits gefüllt ist, muss der Write-Request zum Storage-System weitergegeben werden, auf die Antwort gewartete werden und kann danach zum Host bestätigt werden.

Bei der Einführung dieser Virtualisierungs-Appliances wurden folgende Ziele verfolgt:

- Hersteller-Neutralität bei Storage-Systemen

- Vereinfachter Storage-Betrieb

- Bereitstellung von höheren Storage-Funktionen wie synchrone und asynchrone Spiegelung, Kompression, Deduplizierung etc.

- Geringere Latenz und höherer Durchsatz

Fangen wir mit der Hersteller-Neutralität an. Da diese Virtualisierung die Storage-Systeme zum Host abstrahiert, können prinzipiell alle zertifizierten Storage-Systeme transparent für die Compute-Systeme ans SAN angebunden werden. Preisvorteile bei der Beschaffung der Storage-Systeme wage ich zu bezweifeln, da heute übliche RfP-Prozesse optimale Preise erzielen.

Allerdings erkauft man sich diese Abstraktion mit der Abhängigkeit vom Anbieter der Appliance. Diese bekommt man nicht geschenkt und die zusätzlich benötigten SAN-Ports sind auch nicht zu unterschätzen. Den Anbieter einer Virtualisierung zu wechseln, ist eine sehr viel komplexere Aufgabe. Dies kann man gut im Compute-Umfeld sehen. Der größte Teil der im eigenen Rechenzentrum installierten und virtualisierten Server nutzt die Virtualisierung von einem Hersteller. Interessant dabei ist, dass alle Hyperscaler dafür Open-Source-Software einsetzen. Warum nur? Dies ist ein anderes Thema für einen meiner nächsten Posts.

Der vereinfachte Betrieb entsteht dadurch, dass das Storage-Betriebs-Team sich im Wesentlichen nur noch mit der Virtualisierungs-Appliance beschäftigen muss. Das gilt auch so lange, wie im Backend kein neuer Storage provisioniert werden muss. Das Risiko steigt allerdings erheblich, wenn Fehler auftreten. Zusätzliche Anbieter, die involviert werden müssen, verkürzen die Fehlerbehebung eher nicht. Vorteile verspricht man sich auch bei Daten-Migrationen, z.B. wenn Storage-Systeme gewechselt werden. Heute bieten allerdings viel Storage-Hersteller entsprechende Virtualisierungs-Funktionen an, die eine für Anwendungen transparente Migration ermöglichen.

Anfang dieses Jahrtausends stellten viele Storage-Systeme noch weniger Funktionen bereit. Besonders synchrone Spiegelung war damals eine Domäne von wenigen Anbietern im High-End-Bereich. Heute bieten allerdings viele Storage-Hersteller eine Menge von Funktionen an. Diese reichen über verschiedene DR-Funktion, Funktionen zur Speicheroptimierung, Backup, Cloning, Migration, Virtualisierung etc. Diese Funktionen können unter einer Virtualisierungs-Appliance nicht genutzt werden. Im Gegenteil, bestimmte Optimierungen z.B. für eine erhöhte Lebensdauer können nicht genutzt werden, da die Datenströme durch die zusätzliche Virtualisierungs-Schicht verfälscht werden.

Jetzt kommen wir zu meinem Lieblingsthema – Performance. In Zeiten von drehenden Spindeln und Latenzen von um die 10ms konnte die zusätzliche Cache-Schicht der Appliance noch Vorteile erreichen. Heute reden wir aber von Zugriffszeiten von weit unter einer Millisekunde.
Wenn man in das Storage-Engineering noch nicht so tief eingestiegen ist, kann man sich nicht vorstellen, wie viel Aufwand in die Performance-Optimierung einfließt. Da werden u.a. neue Prozessoren, optimierte Betriebssystem-Architekturen und modernste AI-Algorithmen entwickelt und eingesetzt. Verkürzte Latenzen können riesige Vorteile für Kunden bedeuten und sind die Basis verschiedener Innovation. Hier zusätzliche Hops im SAN einzufügen oder aktuelle NVMe End-to-End Protokolle zu ignorieren konterkariert dieses Ziel direkt.

Neben all diesen Argumenten gibt es sicher noch andere, wie z.B. Strom-, Kühlungs- und Platzbedarf.

Historisch betrachtet war die Appliance-basierte Storage-Virtualisierung eine gute Möglichkeit den damaligen Herausforderungen zu begegnen. Heute hat die Welt sich ein Stück weiter gedreht und eine geradlinige einfache Storage-Architektur sieht doch viel besser aus. Die guten Ideen sind immer die einfachen :)

Bis bald!

Pit