Mit dem »Windows Server 2008 Release 2« ist das »Cluster Shared Volume« (CSV) eingeführt worden – das allerdings nur für den Einsatz mit dem Hyper-V freigegeben ist. Beim »Failover Clustering« kann der Administrator ein Cluster-Volume (also die gemeinsame LUN) zu einem Cluster Shared Volume konvertieren.

Im Bereich der Speicherverwaltung für den »Hyper-« ergeben sich vor allem bei größeren Unternehmen einige Reibungspunkte. Denn üblicherweise sind die Rollen für die Administratoren verteilt: Es gibt Netzwerk-, Server- und Storage-Admins, von denen eine jede Gruppe ihren Teilbereich nach besten Wissen und Gewissen zu verwalten hat. Bei den »Speicherverwaltern« sind die Anfragen nach zusätzlichen Speicherplatz aufgehoben und dabei ist es durchaus üblich, dass eine Anfrage etwa nach zusätzlichen  RAID-10-LUNs zu einer zeitraubenden Angelegenheit wird – je nachdem wie strikt die Vorgehensweise zu derartigen Bedarfsfällen gehandhabt wird.

Fixe Abläufe verhindern Agilität

 Doch im Umfeld der Server-Virtualisierung ist es ein großer Vorteil, dass ein System in Form einer VM sehr schnell bereitgestellt werden kann. Da kommt es dann zu Problemen, wenn die Storage-Gruppe diese Agilität ausbremst. Daher sollte man versuchen, die internen Prozesse entsprechend zu verschlanken und weniger Verwaltungsaufwand fordern.

Ein weiterer wichtiger Aspekt ist die Komplexität – denn damit steigt auch die Wahrscheinlichkeit, dass bei der Verwaltung der Systeme Fehler passieren. Angenommen man hat 1.000 VMs im Einsatz und eine jede verfügt über eine LUN. Falls man eine dieser VMs nicht länger benötigt, kann sie der Administrator löschen und den zugehörigen Speicher wieder zurück geben, so dass er anderweitig Verwendung finden kann. Dann lautet der typische Arbeitsablauf: Der Administrator löscht erst die VM und anschließend die zugehörige LUN. Für diese Aufgabe muss er in die Verwaltungskonsole für das Speichernetzwerk gehen und dort die richtige LUN löschen.

Doch was passiert, wenn es nicht die richtige LUN trifft? Dann sollte die Wiederherstellung aus dem Backup aber unbedingt funktionieren. Selbst wenn man bei derartige vielen LUNs jede LUN, jedes Volume und jedes Cluster-Objekt genau nach der zugehörigen VM benennt – es wird im realen Leben doch vorkommen, dass aufgrund der schieren Menge an Informationen der GAU eintritt.

Wer mit dem Einsatz des Cloud-Computing im eigenen Haus – also mit einer Private-Cloud – liebäugelt, der wird das Thema »Self Service Portal« angehen müssen. Denn mit einer derartigen Funktionalität sind nicht mehr der Speicher- oder Server-Administrator das Einsetzen von neuen VMs abhandeln – das wird Aufgabe der Endanwender. Sie stoßen dazu eine zutreffende Richtlinie an und dann wird mit den entsprechenden Berechtigungen die VM (mit den benötigten Ressourcen) gestartet.

Dazu bietet zum Beispiel der SCVMM eine geeignete Funktionalität. Aber auch hier muss die Einbindung in das komplette Cluster-Konzept gegeben sein und auch die Zuteilung von passend konfiguriertem Speicherplatz ist hier eine wichtige Aufgabe. Denn die Komplexität der kompletten Speicherarchitektur muss hier vor dem Anwender verborgen werden – er wird keine Nachfragen zu LUNs und Volumes verstehen.

Vor diesem Hintergrund wird deutlich, dass eine Verbesserung beim Speicher-Subsystem für den Hyper-V nötig ist. Mit dem »Windows Server 2008 Release 2« ist daher das »Cluster Shared Volume« (CSV) eingeführt worden – das allerdings nur für den Einsatz mit dem Hyper-V freigegeben ist. Beim »Failover Clustering« auf der Basis von Windows Server 2008 R2 kann der Administrator ein Cluster-Volume (also die gemeinsame LUN) zu einem Cluster Shared Volume konvertieren. Dabei handelt es sich sozusagen um eine spezielle Art eines Volumes.

Kunstgriff behält das Prinzip »Shared Nothing« bei

 Damit kann man mehr als nur eine VM auf einem einzigen Volume speichern. Die VMs können dabei auf jedem beliebigen CSV-Volume im Cluster laufen. Und dennoch wurde das grundlegende Prinzip des »Shared Nothing« beibehalten. Dazu hat sich Microsoft eines Tricks bedient. Ein einziger Knoten (Host) des Clusters agiert als der Besitzer des CSV. Dieser Knoten trägt die Bezeichnung »Coordinator«. Nur dieser Knoten darf die gesamten Aktionen über das komplette Dateisystem auf dem CSV ausführen – einschließlich der Operationen, die sich an die Metadaten des Dateisystems wenden- das sind üblicherweise alles »Low-Level-Operationen«, die tief in das Dateisystem eingreifen. Jeder andere Knoten im Cluster, der VMs beherbergt, die auf dem CSV liegen, darf Schreib- und Lesevorgänge auf die Dateien und Ordner dieser VMs ausführen und bekommt dazu vom Coordinator diese Berechtigungen auf zugeteilt.

Danach wird jeder Knoten üblicherweise seine eigene Verbindung zum Speicher nutzen, um die Operationen auf den Speicher der VMs auszuführen. In Sachen CSV gibt es keine Einschränkungen, wie viele CSVs in einem Cluster zum Einsatz kommen dürfen: In manchen Fällen sind sogar mehr als ein CSV sinnvoll beziehungsweise nötig.

Beim Coordinator hat man allerdings auf den ersten Blick einen »Single Point of Failure«, den es vor allem bei einer Hochverfügbarkeitslösung unbedingt zu vermeiden gilt. Falls das System mit der Coordinator-Rolle ausfällt oder auch nur aus einem wichtigen Grund herunter gefahren wird. Doch beim Failover Clustering wird diese Rolle automatisch »geclustert«, sprich diese Rolle wird automatisch an einen anderen Knoten übergeben, wenn dieser Bedarf eintritt. Dieser Failover-Vorgang kann auch von Hand gestartet werden – das macht zum Beispiel Sinn, wenn man schon vorab weiß, dass das betreffende System nach einer Wartungsaktion neugestartet werden muss. 

Damit hat der Administrator die zuvor angesprochenen Herausforderungen gemeistert. Mit Hilfe des CSV  kann der Speicher automatisch und ohne großen Aufwand für die Endanwender bereitgestellt werden, die Verwaltungsaktionen müssen nicht mehr auf GUID-Level oder über die Laufwerksbuchstaben erfolgen, denn beim CSV liegen alle gemounteten Volumes unter dem Verzeichnis C:\ClusterStorage.