Datacore SANsymphony-V R8 im Test, Teil 1 Speichervirtualisierung für anspruchsvolle Umgebungen

Autor / Redakteur: Dr. Götz Güttich / Nico Litzel

Mit SANsymphony-V bietet Datacore eine leistungsfähige Softwareplattform zum Bereitstellen, Teilen, Migrieren, Replizieren, Erweitern, Umkonfigurieren und Upgraden von Speicher ohne Verzögerungen und Downtime. Storage-Insider.de hat sich angesehen, was die aktuelle Version der Lösung in der Praxis leistet.

Firma zum Thema

Storage-Insider.de hat SANsymphony-V von Datacore getestet, eine leistungsfähige Softwareplattform zur Speichervirtualisierung.
Storage-Insider.de hat SANsymphony-V von Datacore getestet, eine leistungsfähige Softwareplattform zur Speichervirtualisierung.
( Archiv: Vogel Business Media )

SANsymphony-V R8 ist ein Speichervirtualisierungsprodukt, das beliebigen Hosts im Unternehmen schnell und einfach virtuellen Speicher zur Verfügung stellt. Die Lösung arbeitet mit Fibre-Channel- und iSCSI-Verbindungen und kann praktisch jede Art von Storage verwalten und virtualisieren.

Darüber hinaus lassen sich mit SANsymphony-V Speichersysteme spiegeln und über weite Strecken replizieren, Snapshots erstellen sowie eine Continuous Data Protection realisieren. Das Thin-Provisioning stellt ebenfalls kein Problem dar.

Bildergalerie

Generell lässt sich sagen, dass SANsymphony-V als eine Art „Speicherhypervisor“ arbeitet und im Storage-Bereich die gleiche Aufgabe erfüllt, wie VMware vSphere oder Microsoft Hyper-V bei der Virtualisierung von Serverhardware.

Datacore hat SANsymphony-V in der aktuellen Version 8 mit einem neuen Konfigurationsinterface ausgestattet, das Administratoren in die Lage versetzen soll, sämtliche Aufgaben des Storage-Managements schnell und einfach durchzuführen. In diesem Test werden wir die Software in unserem Testlabor installieren, Speicher auf iSCSI-Basis im Netz bereitstellen, eine Mirror-Konfiguration des Storage Servers einrichten, die Continuous Data Protection aktivieren und einen dritten Speicher-Server bereitstellen, auf den wir die Storage-Daten unserer Mirror-Server-Group replizieren.

Darüber hinaus werden wir den Replikationsweg auch umdrehen, sodass die Virtualisierungslösung die Daten von unserem dritten Server in die Mirror-Group einspielt. Zum Schluss gehen wir noch im Detail auf das neue Managementwerkzeug von SANsymphony-V und den Funktionsumfang des Produkts ein.

Die Testumgebung

Was die Hardwareanforderungen angeht, so verlangt SANsymphony-V einen Rechner mit zwei oder mehr CPU-Cores mit mindestens 2,0 Gigahertz Taktfrequenz, vier GigabyteRAM, 20 Gigabyte freiem Festplattenplatz und einen Netzwerkport für Kommunikation und Management.

Dazu kommen noch zwei oder mehr weitere Netzwerkanschlüsse für iSCSI oder (beziehungsweise und) zwei oder mehr Host-Bus-Adapter für Fibre Channel.

Als Betriebssystem sollte Windows Server 2008 R2 mit dem .NET-Framework 3.5.1 Verwendung finden. Der Speicherserver lässt sich sowohl als physikalische Maschine als auch als virtuelles System betreiben.

Weiter mit: Getestet auf Windows-Server-2008-R2-Systemen

Getestet auf Windows-Server-2008-R2-Systemen

Für unseren Test haben wir drei Windows-Server-2008-R2-Systeme aufgesetzt, die jeweils zwei CPU-Cores, vier GigabyteRAM und 60 Gigabyte Festplattenplatz hatten. Zwei der Systeme wurden mit drei Netzwerkkarten ausgestattet – für das Management, die Mirror-Verbindung und die Anbindung der Hosts via iSCSI.

Der dritte Rechner – der als Replikationsziel diente – arbeitete nur mit zwei Netzwerkanschlüssen, da er keinen Mirror-Port benötigte. Als Speichermedien für den von SANsymphony-V verwalteten Storage-Pool kamen Festplatten zum Einsatz, die in den Servern vorhanden waren, es ist bei Bedarf aber auch problemlos möglich, externe Speichersysteme einzusetzen.

Konkret liefen in den Servern jeweils drei HDDs: auf der ersten befanden sich das Betriebssystem und die Software, die zweite wurde in den Storage Pool integriert und die dritte arbeitete als Buffer für die Replikation.

Was die Netzwerkkonfiguration anging, so arbeiteten bei uns die Management- und iSCSI-Interfaces im gleichen Subnetz, da wir den virtuellen Speicher von allen Rechnern im LAN aus erreichen wollten. In Produktivumgebungen dürfte es sinnvoller sein, separate Speichernetze aufzusetzen. Die Mirror-Verbindung realisierten wir für den Test als separates Netzwerk, das nur zwischen den beiden beteiligten Servern existierte.

Vor der Installation von SANsymphony-V ist es in iSCSI-Umgebungen wichtig, auf den Speicher-Servern den Microsoft-Hotfix zu installieren, der sich unter http://support.microsoft.com/kb/979711/en-us findet, da es ohne diesen in seltenen Fällen zu Bluescreens kommen kann.

Als Host, der auf den von SANsymphony-V bereitgestellten Speicher zugriff, verwendeten wir im Test übrigens einen Rechner, der unter Windows Server 2008 lief.

Die Installation

Um SANsymphony-V R8 auf einem Server einzuspielen, reicht es, die Setup-Routine aufzurufen und den Installationswizard abzuarbeiten. Der Wizard möchte lediglich wissen, welche Komponenten er einspielen soll, danach läuft das Setup durch (es ist dabei nur erforderlich, diversen Treiberinstallationen zuzustimmen).

Sobald die Software eingespielt wurde, fragt der Assistent nach einem Passwort für das „DcsAdmin“-Konto, das den Superuser-Account für SANsymphony-V darstellt, und schließt danach die Installation durch einen Neustart ab.

Noch kurz zur Komponentenauswahl: SANsymphony-V besteht aus den Komponenten „Managementkonsole“ und „Server“. Die Managementkonsole kann auf einem beliebigen System laufen, Administratoren haben also die Möglichkeit, entfernte Server von einer dedizierten Managementstation aus zu verwalten. Genauso existiert auch die Option, die Managementkonsole zusammen mit der Serverkomponente auf einem System zu installieren.

Für unseren Test spielten wir die Konsole und den Server auf Node eins ein, auf den beiden anderen Rechnern begnügten wir uns mit der Serverkomponente. Die Verwaltung des gesamten Systems lief dann über den ersten Node ab.

Weiter mit: Die Erstkonfiguration

Die Erstkonfiguration

Nachdem der Neustart abgeschlossen und SANsymphony-V auf allen Servern in Betrieb war, riefen wir die Verwaltungskonsole auf und verbanden uns mit dem lokalen Node. Dazu reichte es, als Zielserver „localhost“ anzugeben und das Häkchen bei „Use default credentials“ gesetzt zu lassen. Dann verbindet sich die Konsole über das Standardanmeldekonto „DcsAdmin“ mit dem Server.

Nach dem Login landet der Administrator in einem Verwaltungswerkzeug, das vom Aufbau her stark an aktuelle Microsoft-Office-Versionen, vor allem an Outlook 2010, erinnert. Am oberen Bildschirmrand befindet sich ein Ribbon, über das die Benutzer einen schnellen Zugriff auf die im jeweiligen Kontext relevanten Befehle erhalten.

Links finden sich Baumstrukturen, die die Speicherserver und die Hosts umfassen, die den virtualisierten Speicher nutzen (ähnlich wie die Postfächer bei Outlook). So ist es möglich, schnell auf einzelne Systeme zuzugreifen.

Ähnlich wie neuere Windows-Server-Systeme begrüßt SANsymphony-V die zuständigen Mitarbeiter nach dem ersten Login mit einer Getting-Started-Page, auf der die Schritte aufgeführt werden, die nötig sind, um die Speichervirtualisierungslösung in Betrieb zu nehmen. Arbeiten die Administratoren diese Liste durch, so verfügen sie am Ende über eine Server-Group mit Mirror-Funktion und mindestens einen Host, der auf eine virtuelle Festplatte zugreift.

Die einzelnen Punkte der Startseite lassen sich später im laufenden Betrieb jederzeit erneut aufrufen, sie spielt also durchaus auch eine wichtige Rolle bei der täglichen Arbeit mit der Virtualisierungsplattform.

Sieben Arbeitsschritte

Konkret umfasst die Getting-Started-Page sieben Arbeitsschritte. Der erste Schritt besteht darin, zunächst einmal zusätzliche Benutzerkonten zum Zugriff auf das Managementwerkzeug anzulegen, damit die Anwender nicht immer mit dem DcsAdmin-Account arbeiten müssen.

SANsymphony-V unterscheidet bei den Benutzerrechten zwischen „Owner“ und „Reader“, es ist also auch möglich, User zu definieren, die die Speicherkonfiguration zwar einsehen, aber nicht modifizieren können. Beim Anlegen der Benutzerkonten müssen die entsprechenden Windows-Accounts übrigens bereits auf dem Server vorhanden sein – entweder als lokale oder als Domänenkonten.

Wenn die Konfiguration der Benutzerkonten abgeschlossen wurde, geht es an das Anbinden des zweiten Servers für das Mirroring. Dieser Schritt ist demzufolge nur erforderlich, wenn eine Mirror-Konfiguration gewünscht wird. Auf unserem dritten System, das lediglich für die Replikation zum Einsatz kam, verzichteten wir darauf.

Um den Mirror-Server hinzuzufügen, genügt es, den jeweiligen Servernamen oder die dazugehörige IP-Adresse anzugeben. Zum Zeitpunkt der Mirror-Konfiguration muss allerdings bereits ein Fibre-Channel- oder iSCSI-Link zwischen den beiden betroffenen Rechnern existieren.

Weiter mit: Festlegen der Port-Roles

Festlegen der Port-Roles

Jetzt geht es daran, die Port-Roles für die einzelnen Interfaces auf den Systemen (also dem ersten Node und dem Mirror, denn diese beiden Rechner sind dem Konfigurationsinterface zu diesem Zeitpunkt bekannt) festzulegen. Der dafür vorgesehene Konfigurationspunkt bietet eine tabellarische Übersicht der vorhandenen Interfaces und der dafür vorgesehenen Funktionen.

In dieser Liste legen die zuständigen Mitarbeiter fest, welche Aufgabe welches Netzwerkinterface übernimmt. Zur Wahl stehen hier Mirror-Port, Management-NIC, Frontend oder Backend. In unserer Testumgebung definierten wir den LAN-Anschluss als Management-Port, den iSCSI-Anschluss als Frontend und den iSCSI-Initiator sowie den Mirror-Port als Mirror.

Im nächsten Schritt machten wir uns daran, über „Register a Host“ den Windows-Server-2008-Rechner anzubinden, mit dem wir auf den virtuellen Speicher zugreifen wollten. Dazu war es nötig, das Betriebssystem des Hosts zu spezifizieren (die von SANsymphony-V unterstützten Host-Betriebssysteme stellen wir später noch im Detail vor).

Multipath und Asymmetric Logical Unit Access

Gleichzeitig kann man auch angeben, ob Multipath und ALUA (Asymmetric Logical Unit Access) aktiv sein sollen. Damit der Host-Zugriff funktioniert, ist auf dem Client auch noch etwas Konfigurationsarbeit erforderlich, darauf gehen wir gleich noch genauer ein, wenn wir die erste virtuelle Disk verbinden.

Nach dem Abschluss der Host-Konfiguration kommt das Anlegen des ersten Disk Pools an die Reihe. Dieser umfasst die physikalischen Festplatten, mit deren Hilfe SANsymphony-V später dynamisch die virtuellen Drives für die Hosts erzeugt. Wir verwendeten an dieser Stelle die oben erwähnten internen Speicherplatten. Generell gilt, dass die HDDs in einem Disk Pool von der Größe und Leistung her vergleichbar sein sollten.

Anlegen der virtuellen Disks

Sobald der Disk Pool existiert, geht es an das Anlegen der virtuellen Disks. Diese ließen sich in unserer gespiegelten Speichergruppe entweder als „mirrored“ oder als „non-mirrored“ Disks erzeugen. An gleicher Stelle ist es auch möglich, für eine virtuelle Disk die Continuous Data Protection (CDP) zu aktivieren.

Letztere versetzt einen Administratoren in die Lage, bei Bedarf mithilfe einer Zeitleiste sogenannte Rollback-Points zu erzeugen, die die Daten auf der virtuellen Disk zu einem bestimmten Zeitpunkt in der Vergangenheit abbilden.

Auf diese Weise lassen sich ungewünschte Änderungen an den Daten rückgängig machen. Im praktischen Betrieb ist es dann möglich, die Rollback-Points den Hosts wie virtuelle Festplatten als Speichermedium zuzuweisen. Im Test legten wir zu diesem Zeitpunkt zunächst einmal eine virtuelle Disk mit Mirror-Funktion und CDP an.

Weiter mit: Virtual Disks den Hosts zur Verfügung stellen

Virtual Disks den Hosts zur Verfügung stellen

Der letzte Punkt der Getting-Started-Page übernimmt schließlich die Aufgabe, die gerade erzeugte Virtual Disk den Hosts zur Verfügung zu stellen. Im Test selektierten wir an dieser Stelle den zuvor angelegten Host und wiesen ihm die virtuelle Platte als Speichermedium zu. Damit war die Initialkonfiguration der ersten beiden Server abgeschlossen und wir hatten eine gespiegelte Server-Group mit einem virtuellen Speichermedium, auf das wir mit unserem Host zugreifen konnten.

Zusammenfassend können wir sagen, dass die Startseite einen Administratoren mit Speichererfahrung schnell und gezielt durch die Erstkonfiguration führt. Sie ist auch später wichtig, da sie einen direkten Zugang zu häufig benötigten Befehlen, wie etwa dem Registrieren von Hosts und Usern, bietet.

Die Host-Konfiguration

Um die virtuelle Festplatte nun via iSCSI wie eine lokale Festplatte auf dem Host einzubinden, ist es zunächst erforderlich, auf dem Host den iSCSI-Initiator zu starten. Danach müssen die Administratoren im Initiator auf den Suche-Reiter wechseln und auf „Portal hinzufügen“ gehen. Dort können sie dann die Speicherserver mit ihren IP-Adressen eintragen. Danach sollten Sie den Reiter „Ziele“ auswählen und sich bei den angebotenen Zielen anmelden. Wenn Multipath-Unterstützung gewünscht wird, müssen Sie auf dem Host auch noch den Datacore-Multipath-I/O-Treiber (MPIO) installieren. Dieser Vorgang läuft über einen Setup-Assistenten ab und dürfte keinen IT-Verantwortlichen vor unüberwindbare Schwierigkeiten stellen.

Sobald der Treiber eingespielt wurde, bietet er in der MPIO-Konsole unter „Volumes“ Informationen darüber, welche Verbindungen zu welchen Hosts aktiv und welche passiv sind.

Fällt nun der aktive Speicherserver aus (im Test deaktivierten wir ihn einfach über das Konfigurationsinterface), so wechselt der passive Server automatisch in den aktiven Modus, was sich jederzeit in der MPIO-Konsole auf dem Host verfolgen lässt.

Kommt der ursprüngliche Storage-Server wieder ins Netz, so übernimmt er auch wieder die aktive Host-Verbindung. Welcher Server aus der Mirror-Group für welchen Host als bevorzugter Storage-Anbieter fungiert, ist über das SANsymphony-V-Managementinterface konfigurierbar.

Verbindungsübersicht

Die MPIO-Konsole bietet den IT-Verantwortlichen noch weitere interessante Informationen: So sehen sie beispielsweise unter „Adapters / iSCSI Initiator“, welche Verbindungen zu welchen Servern bestehen. Unter „Datacore Storage Servers“ bietet das Tool im Gegensatz dazu Details darüber an, welche Server mit wie vielen Pfaden und wie vielen Volumes verbunden sind und welche Komponenten sich in einem aktiven beziehungsweise passiven Modus befinden.

Sobald die iSCSI-Konfiguration auf den Hosts abgeschlossen wurde, lassen sich die Connections zu den virtuellen Disks „on-the-fly“ verbinden und trennen.

Unter dem Strich bleibt für uns der Eindruck bestehen, dass das Zuweisen von Speicher an die Hosts über das SANsymphony-V Konfigurationswerkzeug schnell und einfach vonstattengeht. Speicheradministratoren werden beim Einsatz der Lösung keine Probleme bekommen.

Im zweiten und letzten Teil, der am Freitag erscheint, werfen wir einen Blick auf die Einrichtung der Replikation auf den dritten Server, nehmen den Leistungsumfang des Konfigurationsinterfaces unter die Lupe und schauen und das Konfigurations-Tool der Remote Group näher an.

(ID:2050534)