Mit der Storage-Virtualisierungsschicht haben IT-Verantwortliche und Administratoren zusätzliche Speicher-Services bereit zu stellen. Dazu gehören Snapshots, Local und Remote Mirroring, Online-Migration ebenso wie das Thin Provisioning.

Heutige virtuelle Server-Umgebungen bieten eine höhere Ausnutzung der Server-Ressourcen. In den allermeisten Fällen kommt aber bei Server-Virtualisierungsprojekten eine Umstellung im Speicherbereich ins Spiel: wer noch keinen gemeinsamen Speicher verwendet hat, der wird im Zuge einer Migration auf virtuelle Server-Umgebungen in aller Regel auch einen gemeinsamen Speicher – sprich ein Speichernetzwerk anschaffen. Verbunden mit virtuellen Server-Welten lassen sich viele Funktionen am besten mit einem Speichernetzwerk realisieren – vor allem der Bereich der Hochverfügbarkeit profitiert davon massiv.

In derartigen Konfigurationen kommt dann auch die  Storage-Virtualisierung zum Einsatz. In einem SAN werden damit Funktionen machbar,  die einerseits dem IT-Verantwortlichen und dem Administrator das Leben erleichtern und andererseits den Fachabteilungen weitaus flexiblere Services bieten.

Zum Beispiel ermöglicht die Storage-Virtualisierung die geplante Online-Migration von Volumes von einem Storage-Array zu einem anderen, und zwar ohne Ausfallzeiten und Betriebsunterbrechungen in Kauf nehmen zu müssen. Der Administrator ist dabei in der Lage,  eine konsistente Gruppe von Volumes zu erstellen, die sich über mehrere Arrays erstrecken, und sie für Disaster-Recovery-Zwecke zusammen replizieren.

Da Storage-Virtualisierung die Einzelheiten des Arrays verbirgt, entstehen neue Funktionen, wie zum Beispiel die Möglichkeit, neue Arrays in die virtuelle Umgebung einzubinden, ohne die Server neu konfigurieren zu müssen, die den Speicher verwenden werden. Dieser Ansatz vermeidet  teure Ausfallzeiten und Arbeitskosten und die Wahrscheinlichkeit, Fehler zu machen, reduziert sich.

Storage-Virtualisierung senkt die Kosten

 Virtualisierung ermöglicht es den Anwendern, Dutzende oder sogar Hunderte von virtuellen Rechnern mit nur einer Handvoll physischer Server zu betreiben. Wenn ein Anwender über Hunderte virtuelle Rechner verfügt, bei denen jeder Server etwa zehn Volumes benötigt, ginge die Zahl der erforderlichen Volumes in die Tausende. Kommt ein SAN-basierter Volume Manager am Backend der Server-Virtualisierung zum Einsatz, können Anwender effizient Volumes für jeden einzelnen virtuellen Rechner erstellen, ohne sich mit dem LUN-Management auf der Speicher-Array-Ebene befassen zu müssen.

Da es sehr leicht ist, virtuelle Rechner und Applikationen hinzuzufügen und zu entfernen, wird die virtuelle Umgebung auch sehr dynamisch. Es ist aber auch wichtig, dass der Speicher mit der gleichen Leichtigkeit provisioniert und nach der Verwendung reallokiert wird, wie die virtuellen Server.

Point-in-Time-Snapshots ermöglichen die Erstellung mehrerer Snapshot-Kopien jedes Volumes in der virtualisierten Umgebung, die sich auch dann anderen virtuellen Rechnern zuordnen lassen. So entstehen Testumgebungen sehr einfach, braucht der Administrator doch nur Snapshot-Kopien der Produktionsdaten nehmen und sie dann dedizierten virtuellen Rechnern zuweisen. Snapshots lassen sich auch als Quelle für den Backup-Prozess heranziehen. Bei dieser Methode kann das Backup jederzeit im Laufe des Tages stattfinden, ohne dass die Applikationen offline genommen werden müssten.

Verringerung von Ausfallzeiten

 Bei den heutigen Anforderungen an die IT-Umgebungen sind Ausfallzeiten extrem teuer. Snapshots können der gesamten Backup-Strategie noch einen weiteren Vorteil bringen, da sie es ermöglichen, Snapshots für lange Zeit online zu halten. Müssen die Daten wiederhergestellt werden, kann dies innerhalb von Sekunden geschehen. Um Daten nach logischen Fehlern wiederherzustellen (etwa nach einem versehentlichen Löschen von Dateien oder nach einem Viren-Befall), braucht der Administrator einfach nur den letzten Snapshot laden und kann dann direkt auf die Daten zugreifen, statt sie von Band wiederherstellen zu müssen. So verkürzen sich die Wiederherstellungszeiten von Stunden auf Sekunden.

Disaster Recovery ist heute auch für sehr kleine Unternehmen erforderlich geworden. Doch stehen kleinen und mittelgroßen Unternehmen häufig nicht die gleichen Ressourcen wie Großunternehmen  zur Verfügung. Damit sind sie durch lokale Katastrophen stark gefährdet. Ein Remote Mirroring auf Virtualisierungsebene bietet Anwender sogar die Option, eine Konsistenz von Daten mehrerer Arrays zu gewährleisten. Im Katastrophenfall kann der Failover zu einem entfernten Standort viel schneller erfolgen, als wenn jedes Array seine eigenen Daten spiegeln würde und die Daten am entfernten Standort zwischen den Arrays nicht konsistent wären.

»Der Storage Virtualization Manager (siehe Kasten unten) beherrscht auch synchrones und asynchrones Local und Remote Mirroring. Mit ihm ist es möglich, Arrays verschiedener Schichten und sogar von verschiedenen Herstellern zu spiegeln«, erklärt  Nelson Nahum, Vice President Engineering of Software and Solutions bei LSI.

»Mit dem asynchronen Mirroring von SVM können katastrophentolerante Lösungen erstellt werden, die die Ausfallzeit und die Gefahr von Datenverlusten im Katastrophenfall drastisch reduzieren. Weil der SVM Datenbewegungen mit dem Hochleistungs-DPM im SAN handhabt, entstehen keine Perfomance-Einbußen für die Arrays«, verspricht Nahum.

Darüber hinaus müssen die Applikationen bei einem Ausfall lediglich des lokalen Arrays (nicht des gesamten Standorts) nicht zum entfernten Standort umgeschaltet werden; die Server am lokalen Standort können transparent mit dem Speicher am externen Standort weiterarbeiten, so der LSI-Manager. Dadurch erreiche die Storage-Infrastruktur ein neues Niveau von Verfügbarkeit im Vergleich zu Array-basiertem Mirroring, bei dem die gesamten Applikationen zum externen Standort verschoben werden müssen, wenn das lokale Array ausgefallen ist.

 Mit dem asynchronen Mirroring des SVM können konsistente Snapshots erstellt werden, die sich an einen externen Standort überspielenlassen. Dies ermöglicht eine Senkung der Recovery Time Objective (RTO), also die Zeit, die benötigt wird, um im Ernstfall die Umgebung am entfernten Standort wiederherzustellen. Das wird dadurch möglich, dass die Kopie am externen Standort mit der Applikation konsistent ist.

Zudem erlaubt SVM, mehrere Point-in-Time-Versionen am entfernten Standort zu behalten. Dies ist in den Fällen hilfreich, in denen die Katastrophe nicht ein augenblickliches Ereignis ist, sondern sich über einen längeren Zeitraum erstreckt.

Zum Beispiel können Überflutungen oder teilweise Stromausfälle zeitweilige Ausfälle über mehrere Minuten verursachen, in denen nur ein Teil der lokalen Anlagen funktioniert. In solchen Fällen ist es sehr wahrscheinlich, dass Daten am lokalen Standort beschädigt werden, und wenn die Spiegelung weiterläuft, könnte auch die externe Kopie der Daten beschädigt werden; es würde lange dauern, bis der Betrieb weiterlaufen kann. Da SVM mehrere Point-in-Time-Versionen am Ziel behalten kann, kann der Anwender zu einer früheren Point-in-Time-Kopie (nicht zur letzten, die beschädigt wurde) gehen und so sicherstellen, dass er die Umgebung schnell wiederherstellen kann.

Besondere Merkmale des SVM

• Split-Path-Virtualisierungssystem: hier sind Daten- und Steuerpfade getrennt, das ermöglicht einen höheren Durchsatz und eine größere Skalierbarkeit.
• Er kann verschiedene Storage-Arrays von verschiedenen Herstellern virtualisieren, um eine gemeinsame Storage-Infrastruktur zu schaffen.
• Augenblickliche Allokation/Löschung von Volumes.
• Augenblickliche Vergrößerung von Volumes.
• Thin-Provisioned Volumes
• Snapshots mit geringen Platzbedarf
• Bis zu 64 Point-In-Time-Snapshots desselben Volumes.
• Für jeden Zeitpunkt können mehrere Read/Write-Views erstellt werden, die sich an verschiedene Server mounten lassen.
• Aufgrund der Redirect-on-Write-Architektur ist die Performance des Snapshots die gleiche wie die des Hauptvolumes, so dass Snapshots für den produktiven Betrieb gemountet werden können.
• Neben Snapshots mit geringen Platzbedarf ermöglicht der SVM auch Snapshots in voller Größe, bei denen komplette Volumes von einem Array auf ein anderes kopiert werden können, aber dennoch augenblicklich für den Anwender verfügbar sind.
• Möglichkeit, Volumes völlig transparent für die Applikation von einem Array auf ein anderes zu migrieren.
• Synchrones Mirroring zwischen Standorten.
• Asynchrones Mirroring zwischen Standorten.
• Möglichkeit, mehrere Point-In-Time-Versionen an beiden Standorten zu behalten.