Von: DIRK PELZER, Christoph Lange
In den meisten Unternehmen ist Direct Attached Storage (DAS), also Speicher, der direkt per SCSI- oder Fibre-Channel-Verbindung einem Server zugeordnet ist, nach wie vor weit verbreitet. Dieser Ansatz hat jedoch den Nachteil, dass sich der Plattenspeicher nicht ohne weiteres dem Server zuordnen lässt, der diesen gerade benötigt. Stattdessen verfügt jedes System über seinen eigenen, individuellen Pool von Ressourcen. Ist dieser erschöpft, muss ihn der Administrator aufwändig erweitern. Dies geschieht in der Regel, indem vorhandene Festplatten gegen größere ausgetauscht oder weitere Speichersubsysteme hinzugefügt werden, soweit dies technisch möglich ist.
Bessere Speicherauslastung durch Storage-Pooling
Eine deutlich effizientere Nutzung versprechen Storage Area Networks (SAN), in denen Server über Fibre Channel auf einen Pool von Hochleistungs-Speichersubsystemen zugreifen. Doch auch hier steigen die Herausforderungen an die Verwaltbarkeit solcher SANs. Mechanismen wie LUN-Masking oder Zoning sind erforderlich, um den Zugriff der Host-Systeme auf den Speicher zu regeln. Dies ist vor allem in heterogenen Umgebungen, in denen Host-Bus-Adapter (HBA), Fibre-Channel-Switches und Speichersubsysteme unterschiedlicher Hersteller zum Einsatz kommen, mit einer höheren Komplexität verbunden.
Einen umfassenden Lösungsansatz nicht nur für diese Problematik verspricht Datacore mit "SAN Symphony 5". Das Produkt wird auf einem Windows-NT/2000-Server installiert und virtualisiert Platten-ressourcen für Hostsysteme unter Windows NT/2000, Unix, Linux, Netware und Mac OS. Die einzige Voraussetzung, die auf der Seite der Hosts erfüllt sein muss, um an dem Speicherpool zu partizipieren, ist ein von Datacore unterstützter Fibre-Channel-HBA. Ansonsten sind außer der Installation eines Treibers für den HBA keinerlei Modifikationen am Betriebssystem erforderlich. Die physikalische Anbindung der am Speicherpool beteiligten Server, der Plattenspeicher und der von SAN Symphony angelegten Storage Domain Server (SDS) erfolgt entweder per Hub in einem Fibre Channel Arbitrated Loop (FC-AL) oder per Switch in einer Fibre Channel Fabric.
Neben dem klassischen Fibre-Channel-Protokoll unterstützt Datacore mit SAN Symphony 5 auch neuere Technologien wie Fibre Channel over IP (FCIP). Unter den von Datacore zertifizierten Speichersubsystemen finden sich die meisten Produkte bekannter Hersteller wie EMC, IBM, Compaq, Sun oder Hitachi. Der Storage Domain Server, der für die Virtualisierung zuständig ist, liegt im Datenpfad zwischen den Hostsystemen und den jeweiligen Speichersubsystemen. Dieses Prinzip wird auch als symmetrische beziehungsweise In-Band-Virtualisierung bezeichnet.
Unbegrenzter Speicher dank Network Managed Volumes
Eine Besonderheit bei der Virtualisierung von SAN Symphony sind die so genannten Network Managed Volumes (NMV). Diese sorgen für eine dynamische Zuweisung von Speicher für einen Host. Die NMV-Technologie geht dabei so vor, dass sie dem Host pro zugewiesener Logical Unit (LUN) den größtmöglichen vom Betriebssystem verwaltbaren Speicher anzeigt. In Wirklichkeit wird jedoch nur ein Bruchteil dieses in der Regel 2 TByte großen Speicherbereichs auch physikalisch beansprucht. Stattdessen belegt NMV auf den Storage-Subsystemen nur den tatsächlich benötigten Plattenplatz. Sobald das Betriebssystem mehr Speicher benötigt, sorgt NMV automatisch dafür, dass dieser entsprechend bereitgestellt wird. Durch diesen Ansatz kann bei allen von Datacore unterstützten Betriebssystemen auf zusätzliche Werkzeuge und Softwarehilfsmittel verzichtet werden, die sonst zur Erweiterung des Plattenplatzes notwendig gewesen wären. Eine Alarmierungsfunktion erinnert den Systemverwalter rechtzeitig da-ran, neue Platten zu bestellen, sobald der physikalische Speicher zu Ende geht. Leider unterstützt SAN-Symphony kein SNMP, sodass der Systemverwalter die Meldung dem Eventlog des SDS-Systems oder der SAN-Symphony-Konsole entnehmen muss.
Mit der Version 5 von SAN Symphony hat Datacore erstmals auch ein Policy-gestütztes Management von SAN-Ressourcen eingeführt. So ist der Administrator in der Lage, mehrere Storage Domains aufzubauen. Innerhalb einer solchen Domain wird eine Beziehung zwischen Speicher-Pool-Ressourcen und den entsprechenden Hostsystemen definiert, die von einem Verwalter administriert werden. Dadurch lassen sich unterschiedliche Domains von verschiedenen Administratoren mit individuell abgestuften Berechtigungen verwalten.
Policy-gestütztes Speichermanagement
Policies, die für das Management einer Storage Domain herangezogen werden können, beruhen auf einer überschaubaren Anzahl von einigen wenigen Kriterien. Diese umfassen beispielsweise die Performance und die Class-of-Service, aber auch Zugriffsrechte. Mithilfe dieser Policies sind mehrere für einen reibungslosen Betrieb wichtige Ziele erreichbar. Die Software lässt sich beispielsweise so konfigurieren, dass den wichtigsten Applikationen immer genügend Bandbreite zur Verfügung steht und diese niemals unter einem überlasteten SAN zu leiden haben. Weiterhin stehen zahlreiche Kennzahlen zur Verfügung, die sich zur Kapazitätsplanung ebenso eignen wie für eine Abrechnung der benutzten Speicherkapazitäten oder eine Trend-analyse.
Ausfallsicherheit wird groß geschrieben
Was die Datensicherheit und Verfügbarkeit auch im Katastrophenfall anbelangt, hat Datacore als eine weitere Option eine Remote-Mirror-Funktion im Programm. Mit dieser lassen sich komplette Datenbestände von einem Plattenpool auf einen anderen spiegeln. Die redundante Speicherung an unterschiedlichen Standorten trägt zu einer deutlichen Verbesserung der Ausfallsicherheit bei.
Für Backups großer Datenbestände in kleinen Zeitfenstern bietet sich zudem die Snapshot-Funktion an, die den Zustand der Daten zu einer bestimmten Zeit einfrieren und sie anschließend sichern kann, während der Produktivbetrieb weiterläuft.
Schließlich bietet Datacore noch an, die Storage-Domain-Server selbst hochverfügbar zu machen, indem ähnlich wie bei einer Raid-5-Konfiguration N+1 Server in einem Verbund zusammengeschaltet werden. In dieser Konfiguration übernimmt bei Bedarf ein System die Funktion eines ausgefallenen Kollegen und stellt damit einen unterbrechungsfreien Betrieb und die ständige Verfügbarkeit der Daten sicher. Bei einigen Hostbetriebssystemen ist hierfür die Installation einer Softwarekomponente erforderlich, die den Datenpfad nach Ausfall eines Kommunikationspfades transparent umschaltet.
Für Client-Systeme auf Basis von Windows 98, Me, XP und 2000 bietet Datacore zusätzlich eine Funktion namens Asynchronous IP Mirroring (AIM). Storage-Domain-Server können AIM bereits seit Version 4 nutzen. Nach der Installation einer entsprechenden Software sind die genannten Clients in der Lage, Backups lokaler Daten im SAN abzulegen. Die gleiche Funktion steht natürlich auch für Server auf Basis von Windows NT/2000 zur Verfügung, die nicht an ein SAN angeschlossen sind. Der AIM-Client versetzt diese in die Lage, ihre Daten über eine TCP/IP-Verbindung für ein schnelles Backup und Recovery im SAN abzulegen. Wenn nicht nur eine Kopie eines Datenbestandes gewünscht ist, kann der Systemverwalter den AIM-Client so konfigurieren, dass er die Daten an mehrere unterschiedliche Ziele spiegelt. Diese Funktion lässt sich also sowohl für Online-Backups nutzen als auch für die Verteilung von Daten an mehrere unterschiedliche Standorte.
Höchstleistung durch Caching
Neben der reinen Virtualisierung bietet SAN Symphony noch weitere interessante Funktionen, wie zum Beispiel das Caching auf den Sto-rage-Domain-Server. Damit ist der Systemverwalter in der Lage, große und preisgünstige Schreib-/Lese-Caches mit einer Maximalgröße von knapp 32 GByte auch für solche Storage-Systeme zu implementieren, die normalerweise nicht über ein eigenes nennenswertes Caching verfügen. Als Mindestgröße empfiehlt Datacore 512 MByte Cache. Wird SAN Symphony für das Caching benutzt, muss der entsprechende Storage-Domain-Server natürlich auf jeden Fall mit einer unterbrechungsfreien Stromversorgung ausgerüstet sein, um Datenverluste bei Stromausfällen oder Spannungsspitzen zu vermeiden. Um etwaigen Datenverlusten bei einem drohenden Stromausfall vorzubeugen, schaltet SAN Symphony die eigene Cache-Policy von Write-Back auf Write-Through um, sobald der Storage-Domain-Server von einer USV versorgt wird. Im Write-Back-Modus erhält das Betriebssystem die Bestätigung, dass die Daten erfolgreich geschrieben wurden, sobald sie im Cache stehen. Das deutlich langsamere, dafür aber sicherere Write-Through-Verfahren dagegen sendet die Bestätigung erst, wenn die Daten tatsächlich auf die Festplatte geschrieben wurden.
Ähnlich wie beim Mirroring gibt es auch beim Caching eine optionale Clientkomponente für Windows-Systeme. In Verbindung mit dem von Datacore implementierten SCSI Transport Protocol over IP (STP/IP) dienen lokale Platten als Zwischenspeicher für den Transport von Blocklevel-Daten über das IP-Protokoll. STP/IP, das Datacore durch iSCSI ersetzen möchte, sobald der entsprechende Standard endgültig ratifiziert ist, unterstützt Unternehmen dabei, das Einsatzgebiet ihres SAN erheblich auszudehnen. Da heutige 100-MBit/s-IP-Verbindungen signifikant langsamer sind als entsprechende Fibre-Channel-Verbindungen, müssen größere zu übertragende Datenmengen lokal zwischengespeichert werden, um Performanceverluste zu vermeiden. Andererseits lassen sich SAN-Ressourcen nun bei Bedarf direkt bis zum Desktop oder Notebook nutzen.
Die Anforderungen an den Sto-rage-Domain-Server selbst sind nicht sonderlich hoch gesteckt. Dieser muss mit mindestens zwei Pentium-Prozessoren ab 500 MHz und 192 Megabyte Hauptspeicher ausgerüstet sein, damit sich SAN Symphony überhaupt installieren lässt. Deutlich mehr Speicher und schnellere Prozessoren sind jedoch anzuraten, wenn der SDS nicht zum Flaschenhals werden soll. Als Host-Betriebssysteme für SAN Symphony unterstützt der Hersteller Windows NT 4.0 oder Windows 2000. Zudem ist ein PCI-gestützter Fibre-Channel-HBA von Qlogic oder Atto für den Betrieb notwendig, da Datacore einen eigenen Treiber für diese bereitstellt. Aus Gründen der Ausfallsicherheit und einer besseren Performance empfiehlt Datacore, mindestens zwei Fibre-Channel-HBA pro SDS einzubauen. Prinzipiell können pro SDS so viele HBA eingesetzt werden, wie PCI-Slots vorhanden sind.
Um die Virtualisierung durchzuführen, benutzt der Systemverwalter entweder den von Windows-NT bekannten Festplatten-Manager oder den Logical Disk Manager von Windows 2000. Mit dessen Hilfe erzeugt er Partitionen in der gewünschten Größe, ohne diese jedoch zu formatieren. Die zu diesem Zweck verwendeten Platten können dabei nicht nur auf externen Subsystemen im SAN existieren, sondern auch lokal am Storage-Domain-Server über EIDE, SCSI, SSA oder IEE1394 (Firewire) angeschlossen sein. Dadurch kann der Administrator bestehende Systeme mit Direct Attached Storage per SAN Symphony problemlos in einen virtuellen Plattenpool aufnehmen und so bereits getätigte Investitionen schützen.
Speicherzuordnung per Drag-and-Drop
Sobald die Partitionierung über den Festplatten-Manager abgeschlossen ist, müssen die erzeugten Partitionen unter Zuhilfenahme der "SAN-Central"-Tools von SAN Symphony mit Namen beziehungsweise Labels versehen werden. Diese sind für die nachfolgende Zuordnung des Speicherplatzes zu einem Zielserver nötig. Dabei kommt der "SAN Manager" von SAN Symphony zum Einsatz, über den die Zuordnung des Plattenplatzes zum gewünschten Zielsystem erfolgt. Sobald dies durchgeführt ist, kann der Administrator auf den Zielsystemen damit beginnen, den bereitgestellten Plattenplatz, der sich für das Betriebssystem wie eine lokale Festplatte präsentiert, zu partitionieren und mit dem gewünschten Dateisystem zu formatieren. Network Managed Volumes (NMV), die eine Größe von maximal zwei Terabyte haben können, werden dagegen anders verwaltet. Hier bleiben der Disk Administrator beziehungsweise der Logical Disk Manager außen vor. Die gesamte Administration erfolgt stattdessen über die Software SAN Symphony.
SAN Symphony im Test
Um die Leistungsfähigkeit der Virtualisierungssoftware von Datacore zu testen, installierten wir im Labor unseres Testpartners Onsite Computer GmbH in Hallbergmoos zwei Storage-Domain-Server. Diese bestanden aus zwei "PowerEdge-2450"-Servern von Dell mit je zwei Pentium-III-Prozessoren. Die Systeme waren mit 733 MHz getaktet und verfügten über 512 MByte RAM sowie je zwei "Qlogic 2200"Fibre-Channel-HBA. Auf der Storage-Seite hatten wir ein "Storageworks -MA-8000"-Subsystem von Compaq mit HSG-80 Controller und 256 MByte Cache sowie ein "Nstor- 3100F"-Fibre-Channel-Raid-System mit einem "Mylex FFX Controller" und 128 MByte Cache installiert. Das Compaq-MA-8000 war mit insgesamt sechs SCSI-Platten mit einer Kapazität von jeweils 9 GByte und einer Drehzahl von 10 000 Umdrehungen bestückt. Im Nstor 3100F waren acht 36-GByte-Fibre-Channel-Platten eingebaut, die ebenfalls mit 10 000 Umdrehungen rotierten. Somit war sichergestellt, dass genügend Spindeln für einen aussagekräftigen Performancetest zu Verfügung standen. Die Platten waren in einer Raid-0-Konfiguration zusammengefasst, um optimale Datendurchsätze zu erzielen. Für den Performance-Test verwendeten wir eine so genannte "Wall of Servers", die aus insgesamt acht Compaq-Proliant-Systemen bestand. Die Server waren jeweils mit mindestens 256 MByte RAM und einer Intel-Pentium-II- oder Pentium-III-CPU mit mindestens 350 MHz Taktfrequenz bestückt. Auf den Servern war "Windows 2000 Server" mit Service Pack 2 installiert. Für die Performancemessung verwendeten wir "Intel IO Meter" in der Version 1999.10.20. Die Anbindung an das SAN erfolgte über Fibre-Channel-HBA von Emulex vom Typ "LP 8000". Die SAN-Fabric selbst bestand aus zwei "Brocade-Silkworm- 2400"-Switches, die über einen Inter Switch Link miteinander verbunden waren. Alle Fibre-Channel-Komponenten wurden mit einer Geschwindigkeit von 1 GBit/s betrieben. SAN Symphony unterstützt auch Fibre-Channel-Netze mit der neuen 2-GBit/s-Technik. Da Datacore bestimmte Anforderungen sowohl an die Firmware der verwendeten Fibre-Channel-HBA als auch des Switches stellt, waren alle Komponenten mit entsprechend zertifizierten Firmware-Releases versehen.
Virtualisierung schnell in Betrieb
Um den Testservern virtualisierten Speicher zuweisen zu können, richteten wir auf den Brocade-Switches insgesamt drei Zonen ein. Die erste Zone umfasste die acht Testserver; die zweite Zone enthielt einen Storage-Domain-Server und den Compaq-Speicher; die dritte bestand aus dem anderen Storage-Domain-Server mit dem Nstor-Raid-System. Über den Logical Disk Manager von Windows 2000 und SAN Symphony konfigurierten wir anschließend acht virtuelle Platten mit einer Größe von jeweils 512 MByte und wiesen sie den Servern zu. Die Konfiguration von SAN Symphony erwies sich hierbei als relativ einfach. Für den ersten Test wiesen wir alle acht Testserver einem SDS zu. Dieser verfügte dabei über eine Cachegröße von 256 MByte. Aufgrund der Zonendefinition wurden zudem alle Speicherzugriffe ausschließlich über den Speicher von Nstor abgewickelt.
Pro Testdurchlauf stressten wir die Storage-Domain-Server mit insgesamt 20 unterschiedlichen Lastprofilen, wobei wir die Art des Zugriffs und die Blockgröße der jeweils zu übertragenden Daten variierten. Alle Profile waren so ausgelegt, dass sie die SAN-Ressourcen auf das Höchste belasteten. Insbesondere waren zwischen den gesendeten Daten-Bursts keinerlei Pausen konfiguriert, sodass eine kontinuierliche Belastung sichergestellt war.
Anhand der Messergebnisse wurde deutlich, dass die Virtualisierung nicht zum Nulltarif erhältlich ist und wir an der Hardwarekonfiguration der SDS Veränderungen vornehmen mussten, um bessere Resultate zu erzielen. Die einfachste Möglichkeit hierfür bestand darin, den zweiten, identisch ausgestatteten SDS hinzuzufügen. Anschließend verteilten wir die Last gleichermaßen auf beide Systeme, sodass nun jeder SDS über 256 MByte Cache und zwei dedizierte Fibre-Channel-HBA verfügte. Außerdem wurden die Speicherzugriffe nun auf zwei Storage-Systeme verteilt, was sicherlich ebenfalls zu einem besseren Durchsatz beigetragen hat.
Die insgesamt mit dieser Konfiguration erzielte Performance lag deutlich höher als bei den vorherigen Messungen. Die Leistungsgewinne zeigen, dass mit verhältnismäßig geringem Aufwand große Performancesteigerungen von bis zu 90 Prozent gegenüber einem einzelnen Storage-Domain-Server erzielbar sind. Mit mehr Cache-Speicher und zusätzlichen Fibre-Channel-HBA pro SDS wären die Resultate vermutlich noch besser ausgefallen.
Da uns zum Vergleich Produkte von Mitbewerbern fehlten, die zwar zum Test eingeladen waren, aber nicht teilnehmen konnten, standen für die Beurteilung der Performancedaten keine direkten Vergleichswerte zur Verfügung. Erschwerend kommt hinzu, dass die Performance sich als stark konfigurationsabhängig erwiesen hatte. Für die Bewertung der von SAN Symphony erzielten Leistungsdaten legten wir deshalb die maximal mit IO Meter erzielbaren Durchsätze der beiden Storage-Systeme zugrunde, die wir bei früheren Messungen ermittelt hatten. Beim MA8000 lagen die Durchschnittswerte für das Lesen bei 46 MByte/s und die für das Schreiben bei 37 MByte/s. BeimnStor ermittelten wir 47 MByte/s für das Lesen und 40 MByte/s für das Schreiben. Daraus errechnet sich ein Durchschnittswert von 47 MByte/s für das Lesen und 39 MByte/s für das Schreiben. Mit den 36 MByte/s für das Lesen und 32 MByte/s fürs Schreiben im zweiten Durchgang lagen die mit SAN Symphony erzielbaren Werte knappe 30 beziehungsweise 20 Prozent unter dem theoretisch Machbaren. Das reichte für ein sehr gutes Ergebnis bei der Performance.
Fazit
Die Messergebnisse zeigen, dass das Umfeld, in dem eine Virtualisierungslösung eingesetzt werden soll, genau zu analysieren ist. Insbesondere Art und Umfang der erwarteten Datenzugriffe sind hierbei von entscheidender Bedeutung. Nur durch eine sorgfältige Planung lässt sich erreichen, dass die Last auf eine ausreichend große Anzahl von Storage-Domain-Servern, Host-Bus-Adaptern und Storage-Subsystemen verteilt wird und der dazugehörige Cache-Speicher optimal dimensioniert wird. Auf diese Weise kann der Systemverantwortliche sicherstellen, dass die umfangreichen und überaus nützlichen Funktionen, die Datacore in SAN Symphony implementiert hat, in jeder Hinsicht voll zur Geltung kommen.
Das Produkt ist in der Lage, dem Administrator einige Kopfschmerzen beim Speicherplatzmanagement zu ersparen. Installation und Konfiguration der Software sind vergleichsweise einfach und mit wenigen Vorkenntnissen zu bewerkstelligen. Ansonsten vermissten wir in der umfangreichen Ausstattungsliste eigentlich nur die SNMP-Unterstützung. Sehr gut gefallen haben uns zudem die Network Managed Volumes. Eine einfachere Möglichkeit des Plattenplatzmanagements dürfte derzeit nur schwer zu finden sein.
Zur Person
DIPL.-ING. DIRK PELZER
arbeitet als Consultant und Journalist in München. Er ist NetworkWorld-Testpartner und betreibt das Storage-Labor der NetworkWorld. Zudem beschäftigt er sich mit Speichernetzen und Hochverfügbarkeit.
Testergebnisse und technische Daten
SAN Symphony 5
Hersteller:
Datacore Software GmbH
www.datacore.com
Preis:
Die für diesen Test verwendete Softwareinstallation mit zwei redundant ausgelegten Storage-Domain-Servern kostet etwa 80 000 Euro. Darin sind enthalten: zwei Lizenzen "SAN Symphony Network Edition", zwei Lizenzen "Network Mirroring" inklusive "Alternate Pathing", zwei Lizenzen "Network Managed Volumes" sowie Support-Services. Die Serverhardware ist nicht enthalten.
Da Datacore die optionalen Features im Rahmen einer Gesamtlösung verkauft, können keine Einzelpreise angegeben werden. Als weitere Optionen sind verfügbar: "AIM Client", "AIM Server", "STP/IP Client", "AP-Client", "Disk Mirroring Client", "SDK", "Snapshot".
Technische Daten:
Storage-Management-Werkzeug mit folgenden Funktionen:
Dynamische Zuweisung von Plattenplatz im SAN im laufenden Betrieb; Aufbau virtueller Plattenpools mit heterogenen Plattensubsystemen; Erhöhung des Datendurchsatzes durch Caching; synchrone und asynchrone Datenspiegelung lokal und remote (über IP-Netzwerke).
Testergebnis:
+ Network Managed Volumes bieten höchste Flexibilität beim Storage-Management
+ Synchrone und asynchrone Replikation für heterogene Storage-Systeme
+ Replikation über IP-Netze möglich
+ N+1-Redundanz für Hochverfügbarkeit
- Keine Unterstützung für SNMP
- Unter Umständen aufwändige Maßnahmen zur Optimierung der Performance notwendig