iSCSI im Testnetz: DataCore SANmelody
Die so erstellten Volumes sind anschließend beim Knoten Storage Server sichtbar. Damit sie von SANmelody verwaltet werden können, muss im Kontextmenü des Eintrags für den Storage Server der Befehl Protect All Volumes eingegeben werden. Damit werden alle zusätzlich Volumes ohne Laufwerksnamen und Formatierung unter die Kontrolle von SANmelody erstellt.
Nach Konfigurationsänderungen müssen diese über das zusätzliche Symbol Apply in der Symbolleiste aktiviert werden. Das ist sinnvoll, weil Änderungen an den Einstellungen für die produktive Nutzung der Geräte erhebliche Auswirkungen haben können. Sie werden daher nicht sofort umgesetzt, sondern müssen explizit aktiviert werden.
Der nächste Konfigurationsschritt ist die Erstellung virtueller Volumes, die auf den automatisch erkannten Volumes basieren. Jedes virtuelle Volume erhält einen Namen und wird mit einem physischen Volume verknüpft. Bei den Eigenschaften der virtuellen Volumes kann konfiguriert werden, dass diese nicht den gesamten Speicherplatz des Volumes auf Systemebene konsumieren. Das bringt aber wenig, da ein physisches Volume nur mit einem virtuellen Volume verbunden sein kann. Daher müssen auf Systemebene gegebenenfalls kleinere Partitionen erstellt werden, falls mehr virtuelle Volumes erforderlich sind.
Der nächste Schritt ist die Konfiguration der Application Servers. Dabei handelt es sich um die iSCSI-Initiators, die auf das über SANmelody erstellte iSCSI-Target zugreifen. Diese Zielsysteme werden in der Regel mit dem Computernamen bezeichnet. Das Betriebssystem muss explizit ausgewählt werden. Bei den Eigenschaften muss diesenSystemen außerdem gegebenenfalls der korrekte iSCSI-Channel zugeordnet werden. Das ist einfach, weil dieser den Computernamen enthält.
Der abschließende Schritt ist die Zuordnung von virtuellen Volumes zu den Anwendungsservern. Damit erfolgt die eigentliche Freigabe. Falls ein Volume mehreren Servern zugeordnet wird, erscheint eine Warnmeldung. Für die gemeinsame Nutzung von Datenträgern in einem Cluster ist das aber erforderlich. Durch den Shared Nothing- Ansatz der Clusterdienste von Windows werden Konflikte ohnehin vermieden, da zu einem Zeitpunkt immer nur ein Knoten die Kontrolle über die Ressourcen hat. Nachdem alle Änderungen übernommen wurden, kann von den iSCSI-Initiators aus auf das iSCSI-Target zugegriffen werden.
Etwas kritisch ist das Produkt in Bezug auf abgebrochene Startvorgänge. Es ist wichtig, den Boot-Prozess von Servern nicht zu unterbrechen, da fehlerhafte Starts registriert werden und dazu führen, dass der Dienst anschließend nicht mehr automatisch startet. Gerade in Umgebungen mit virtuellen Maschinen lässt sich das Problem aber beispielsweise durch die Definition von Snapshots mit einem stabilen Status des Servers umgehen, auf die bei Bedarf zurückgegriffen wird.