Die meisten IT-Projekte in Unternehmen betreffen derzeit die Virtualisierung. Doch viele Unternehmen beschränken ihre Projekte auf die Servervirtualisierung und verschenken damit die Möglichkeit, den Storage-Bereich nicht nur zentral verwaltbar, sondern auch flexibel und weitgehend herstellerunabhängig zu gestalten. Je nach konkreter Anforderung vor Ort bieten sich hierzu zwei grundsätzliche Techniken an: die In- und die Out-of-Band-Virtualisierung.
Sehr oft wird in Virtualisierungsprojekten zunächst ein einfaches, kleines SAN angeschafft, um
den neuen Vmware-Servern ausreichend Platz für die Ablage der Virtuellen Maschinen (VMs) zu bieten.
Diese "Mini-SANs" bestehen häufig aus ein oder zwei FC-Switches und einem Storage-System, auf das
die Vmware-Server zugreifen können. Das würde sich bereits für eine Storage-Virtualisierung eignen.
Dass Unternehmen sie trotzdem nicht umsetzen, liegt vermutlich daran, dass kein Budget mehr dafür
vorgesehen wurde oder der Systempartner zwar ein Vmware-Spezialist ist, aber kaum Erfahrung mit
Storage-Virtualisierung hat und deshalb das Thema nicht anspricht.
So bleiben diese Mini-SANs nichts weiter als eine DAS-Lösung (Direct Attached Storage) mit
erweiterter Hardware und Technik. Die Speicherkapazitäten sind zwar physisch nicht mehr an einen
Server gebunden, logisch aber sehr wohl. Weiterhin weist das Storage-System einem spezifischen
Server die Kapazitäten einer Logical Unit (LU) 1:1 zu, und es ergibt sich wieder ein statisches
Abbild von Server-Speicher-Zugehörigkeiten. Auch der Vorteil der zentralisierten Verwaltung
verflüchtigt sich, sobald das SAN erweitert wird. Denn dann verwaltet der Administrator schnell
verschiedene Systeme mit unterschiedlichen Managementoberflächen und hat mehr Verwaltungsaufwand
als früher mit dem reinen DAS.
Dennoch empfiehlt sich ein SAN, genauer die Ausgliederung von Speicherkapazitäten aus dem
Server, damit der Administrator die Speicherkapazitäten flexibel nutzen und dabei die benötigte
Verfügbarkeit, Skalierbarkeit, Sicherheit und Managebarkeit verwirklichen kann. Doch das SAN stellt
dazu nur die Infrastruktur bereit, die Funktionen liefern zum Beispiel entsprechende
Appliances.
Hier kommt die Storage-Virtualisierung ins Spiel. Wie bei der Servervirtualisierung werden dabei
die zur Verfügung stehenden Ressourcen nicht mehr 1:1 den entsprechenden Servern zugeordnet,
sondern in Pools gleicher Charakteristik verwaltet, also ein High-Performance-Pool mit schnellen
FC-basierten Festplatten und ein Archiv- oder Fileserver-Pool mit SATA-Festplatten. Aus diesen
Pools heraus bedient das System dann die Server.
Entscheidend ist hier die Umsetzung von physischen in virtuelle Ressourcen. Die
Virtualisierungssoftware setzt reale Blockadressen in virtuelle um. Da diese Umsetzung bei einer
Storage-Virtualisierung völlig unabhängig von den sich darunter befindlichen Storage-Systemen und
-techniken geschieht, entsteht dadurch ein zentraler Punkt, an dem der Administrator auf alle
Informationen über die zur Verfügung stehenden und genutzten Bereiche zugreifen kann. An diesem
zentralen Punkt fügt der Administrator nun die Funktionen ein, die er sich von einem SAN
verspricht: Spiegelungen, Snapshots, Kopien oder auch Multipathing. Diese Funktionen sind dann
völlig unabhängig vom Hersteller oder Modell der genutzten Storage-Systeme.
Virtualisierungstechniken sind als In-Band-, Out-of-Band- sowie als Storage-System-basierte
Lösungen erhältlich. Bei der In-Band-Appliance laufen die Daten sowie die Kontrolldaten über eine
einzelne Appliance. Diese Appliances setzen auf Standardhardware auf und nutzen als Betriebssystem
Linux, Windows oder ein Unix-Derivat. Demgegenüber nutzen Out-of-Band-Appliances eine spezifische,
auf den einen Aufgabenzweck hin entwickelte Hardware, vergleichbar mit den ASICs in einem
FC-Switch. Es handelt dabei um hochperformante Komponenten, die die Adressumsetzung übernehmen.
In-Band-Appliances arbeiten nach dem Store-and-Forward-Prinzip. Das heißt, ein I/O durchläuft
den gesamten I/O-Stack bis zur CPU. Dort wird der I/O bearbeitet und als komplett neuer I/O
initiiert. Dies führt zwangsläufig zu langen Bearbeitungs- und somit Latenzzeiten. Um diesen
Nachteil zu kompensieren, führen die Hersteller ein Caching in der Appliance durch. Ein Cache
wiederum löst zwar das Latenzzeitproblem, bringt aber zum Beispiel ein Cache-Koheränzproblem mit
sich. Da nur maximal zwei Caches zu jedem Zeitpunkt kohärent gehalten werden können, unterliegen
diese Lösungen bei der Skalierung starken Einschränkungen. So kann der Administrator nicht ohne
Weiteres zusätzliche Paare von In-Band-Appliances hinzufügen. Denn damit gelangen weitere
Caching-Paare, die jeweils nicht kohärent zueinander sind, in die Gesamtlösung. Er muss die
Virtualisierungslösung separieren und erhält Virtualisierungsinseln, deren Sichtbarkeit und
Interoperabilität untereinander eingeschränkt ist. Somit wird die In-Band-Lösung durch Skalierung
komplexer und der Verwaltungsaufwand steigt. Doch die Speichervirtualisierung im SAN soll ja gerade
das Gegenteil erreichen, und das Caching dient lediglich dazu, das Latenzzeitproblem zu lösen.
Zudem muss das Caching in vielen Ausnahmesituationen ausgeschaltet werden, etwa wenn eine Appliance
ausfällt. Die verbleibende Appliance muss die Last des ausgefallenen Geräts übernehmen, und das
ohne Caching. Dies destabilisiert die gesamte Produktion und führt zu massiven Engpässen bei
Bandbreite und Performance. Sind an die Virtualisierungslösung sehr viele Server angeschlossen,
führt das Caching außerdem zu einer starken Defragmentierung des Caches: Die Lösung weist jedem
Server nur noch einen sehr kleinen Anteil des Caches zu. Weiterhin unterliegt der Cache dem Problem
der Blockgrößen. Wie bei den meisten RAID-Systemen unterstützen auch bei den
Virtualisierungs-Appliances die Caches nur eine Blockgröße. I/O-intensive Anwendungen benötigen
aber, um die beste Performance zu erreichen, meist kleinere Blockgrößen im Cache als beispielsweise
Fileserver. Wer also eine In-Band-Appliance einsetzen will, sollte darauf achten, dass der Cache
mehrere Blockgrößen unterstützt. Darüber hinaus sollte sich ein IT-Leiter überlegen, ob er möchte,
dass die produktiven Live-Daten des Unternehmens nicht nur im RAID-System, sondern auch in der
In-Band-Appliance zwischengespeichert werden. Darüber hinaus verpufft der Cache-Effekt bei den
Cache-feindlichen Datenbankanwendungen. Diese I/Os unterliegen dann dem Latenzproblem dieses
Ansatzes.
Für diese Anwendungen eignen sich besser Out-of-Band-Lösungen. Denn diese arbeiten wie Switches
nach dem Cut-Through-Prinzip. Es kommen hoch spezialisierte Frame-Cracker-ASICs zum Einsatz, die
ein Aufbrechen und Verändern des Daten-Frames auf Layer 2 mit "Wire-Speed" durchführen. Die
Appliances vollziehen die Virtualisierungsaufgaben über die Hardware. Die Geräte arbeiten stateless
und kommen ganz ohne Caching aus. Die Latenzzeit liegt hier zwischen Eingangs- und Ausgangs-Port
bei vier bis sieben Mikrosekunden gegenüber mehreren 100 Mikrosekunden bei CPU-basierten
In-Band-Appliances.
Virtualisierungslösungen innerhalb von Storage-Systemen arbeiten meist nach dem
Out-of-Band-Prinzip, obwohl der komplette Traffic durch das System geht. Der entscheidende
Unterschied zu Appliances ist, dass die Hardware durchgängig auf Performance ausgelegt ist.
Innerhalb des Systems laufen die reinen Datenströme getrennt von den Kontrolldaten.
Bei der Auswahl des geeigneten Systemes sollte der Anwender aber darauf achten, dass die
Virtualisierung ihn nicht in seiner Unabhängigkeit einschränkt. Es gibt derzeit nur wenige
Hersteller, die eine von den Funktionen her vollständige Virtualisierung anbieten, die gleichzeitig
für Storage-Systeme anderer Hersteller offen ist. Dazu zählen zum Beispiel Hitachi Data Systems
(HDS) mit der USP-Reihe oder LSI mit dem Produkt SVM. Bei diesen Lösungen macht sich der Anwender
nicht von ihrer Speicherlösung abhängig, weil sie eine große Anzahl an Speichersystemen von anderen
Herstellern unterstützen.
Bei der Auswahl der richtigen Virtualisierung müssen also die Kriterien und Bedürfnisse des
Anwenders berücksichtigt werden. Wer Performance, Skalierbarkeit, Flexibilität und einfaches
Management in den Vordergrund stellt, ist mit einer Out-of-Band- oder einer offenen
Storage-System-basierten Lösung am besten bedient. Anwender mit geringeren Anforderungen in Bezug
auf Skalierbarkeit und/oder Performance finden bei den In-Band-Appliances, wie sie von Datacore,
Falconstor oder IBM angeboten werden, sicher einen guten Einstieg. Eine scharfe Schnittlinie ist
hier nicht zu ziehen. Wichtig ist, dass sich die Technik den geschäftlichen Anforderungen anpasst –
und nicht umgekehrt.