Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

25.07.2003 - 

Speichernetze/Storage-Virtualisierung in der Praxis

Expresszustellung für Gigabytes

Jeder will''s, keiner bekommt genug davon: Speicherplatz ist ein knappes Gut und die Quelle für anhaltende Kopfschmerzen bei IT-Planern in Unternehmen, Behörden und öffentlichen Einrichtungen. Dagegen sorgt beim Computer- und Medienservice der Humboldt-Universität Berlin ein virtuelles Speicher-Management für ganz reale Entlastung.Von Stefan Müller-Ivok*

Das Land Berlin baut in Berlin-Adlershof eine "Stadt für Wissenschaft, Wirtschaft und Medien" auf. In diesem Rahmen verlegt die Humboldt-Universität zu Berlin (HU) ihre mathematisch-naturwissenschaftlichen Fakultäten seit 1998 sukzessive in den Südosten der Hauptstadt. Auf dem 420 Hektar großen Gelände tummeln sich rund 570 Unternehmen mit etwa 8000 Beschäftigten. Die HU-Institute für Mathematik, Informatik, Chemie und Physik sind inzwischen dort heimisch geworden, ebenso der zentrale Computer- und Medienservice, der im Februar dieses Jahres zusammen mit der Zentralbibliothek Naturwissenschaften das neu erbaute Erwin Schrödinger-Zentrum bezog.

Nicht nur räumlich wurde es eng an der altehrwürdigen Wissenschaftsstätte, auch die IT-Landschaft umwehte verstärkt der Atem Humboldtscher Tradition. Das galt insbesondere im Storage-Bereich, jetzt einer der Hauptaufgaben für den Computer- und Medienservice der HU. "Vor ein paar Jahren tendierten die Institute dahin, ihre Speicher- und File-Server-Infrastrukturen selbst zu betreuen", sagt Günther Kroß, Abteilungsleiter Systemsoftware und Kommunikation des Computer- und Medienservice, "heute geht der Trend in die andere Richtung, zur zentralisierten Storage-Verwaltung. Die Institute wären auch gar nicht mehr in der Lage, sich personell und finanziell selbst um diesen komplexen Bereich zu kümmern. Auch nicht darum, was hinsichtlich der geeigneten klimatisierten Unterbringung zu tun ist."

Schuld daran sind in erster Linie die exorbitanten Steigerungsraten in Sachen Speicherplatz. Marktbeobachter sind sich einig, dass sich die installierte Storage-Kapazität jedes Jahr verdoppelt, nicht nur in großen Unternehmen. Wer heute mit 250 GB Festplattenplatz haushalten kann, sieht sich in fünf Jahren 8 TB gegenüber, die verwaltet und gesichert werden müssen. Das bringt einen entsprechenden Personalaufwand mit sich, der angesichts leerer Kassen allerorten immer weniger zu verantworten ist.

Die rasante Entwicklung im Storage-Segment ging natürlich auch an der HU nicht spurlos vorbei. Das Dienstleistungssegment Storage wuchs kontinuierlich, selbst wenn zunächst nur die naturwissenschaftlichen Fakultäten in Adlershof mit Server- und Speicherdiensten seitens des Computer- und Medienservice versorgt werden sollten. Diese Fakultäten machen nicht einmal ein Drittel des Universitätsangebots aus. "Noch vor ein paar Jahren standen in den einzelnen Instituten File-Server mit Plattenkapazitäten von 10 bis 30 GB. Was dort ,überlief'', haben wir im Rechenzentrum, dem Vorgänger des Computer- und Medienservice, mit einem hierarchischen Convex-Speichersystem plus Video Tape Library und Backup-System aufgefangen", fasst Frank Sittel zusammen. Der Physiker ist beim Computer- und Medienservice für die zentrale Storage-Verwaltung zuständig. "Allerdings war das Convex-System nicht für die Jahr-2000-Umstellung gerüstet", ergänzt Sittel, "und der Trend ging ohnehin immer mehr in Richtung Windows 2000 Server. Auch unter diesem Aspekt mussten wir eine Alternative zu unseren Unix/Samba-basierenden Konzepten finden."

Große Distanzen überwinden

Hinzu kommen die räumlichen Dimensionen. Der Standort Adlershof liegt rund 30 Kilometer vom Humboldt-Zentralgebäude in Berlin Mitte entfernt, das Erwin-Schrödinger-Zentrum und die anderen Einrichtungen auf dem Campus trennen bis zu 800 Meter. Die Speicherzuteilung und -verwaltung musste also auf relativ große Distanzen ausgelegt werden.

Eines war damit klar: Mit dem alten Jahrtausend würde auch die bisherige Server-zentrierte IT-Architektur zu Grabe getragen werden. Dort sind die Speicherkomponenten (Platten, Tapes, Disk-Subsysteme) direkt an einen Server (oder zwei, für die Ausfallsicherheit) angeschlossen. Hierfür werden SCSI-Kabel verwendet, die allerdings auf wenige Meter Übertragungsweite beschränkt sind. Diesen Mangel beheben Speichernetze (SANs = Storage Area Networks), indem sie die starren SCSI-Verbindungen zwischen Speicher und Server abtrennen und durch ein serielles Lichtwellenleiter-Netz ersetzen, worüber mehrere Server auf dieselbe Speicherressource zugreifen können. Die Speicherplatten sind also in einem eigenen Pool zusammengefasst.

In solchen speicherzentrierten Architekturen wird in der Regel über das Fibre-Channel-Protokoll kommuniziert. Fibre Channel bietet einige Vorteile gegenüber dem TCP/IP/Ethernet-basierenden LAN (Local Area Network): hohe Übertragungsraten (bidirektional 200 MB/s) über größere Entfernungen (bis zehn Kilometer ohne Repeater und ähnliches), wenig Übertragungsfehler, Entlastung der Server-CPUs durch die Implementierung des Protokolls auf den Hostbus-Adaptern. Die Geräte sind in den meisten SAN-Implementierungen über die Fabric-Topologie miteinander verbunden und können darin parallel Daten austauschen. Zusammengehalten wird das Ganze über Fibre-Channel-Switches mit - je nach Größe - zwischen acht und rund 250 Ports, so dass sich zusätzliche Endgeräte und Switches flexibel anschließen lassen.

Die Planungen für das HU-SAN begannen 1999, ein Jahr später war die Basisinstallation mit zwei File-Servern und RSS-Speichersystemen von IBM betriebsbereit. Die SAN-Installation an den HU-Standorten Mitte und Adlershof ruht auf jeweils zwei Core Fabric Switches "Silkworm 12000" von Brocade mit je 64 Ports, erweiterbar auf 128. In den Instituten sind insgesamt acht Switches der Reihe "Silkworm 3800" verteilt. Da gerade in einer so komplexen Infrastruktur vorbeugen leichter ist als heilen, wurde die Fabric für die Vernetzung redundant ausgelegt. Das heißt, jeder Teilnehmer im SAN hängt an beiden Fabrics und sollte den Ausfall einer davon ohne Blessuren überstehen.

Das Kostenargument

Ein SAN gehört typischerweise zu den IT-Installationen, die mit relativ hohem finanziellen Anfangsaufwand verbunden sind. Da gilt es die Geldgeber mit guten Argumenten zu gewinnen, gerade wenn es um ein Großprojekt an einer öffentlichen Einrichtung wie der HU geht. "Wir haben insbesondere auf die flexible Speicherverteilung an den Standortkomplexen und auf die Notwendigkeit der ausfallsicheren Verwaltung der immer größeren Speicherkapazitäten hingewiesen und was das für die Entlastung des IT-Fachpersonals und die Verfügbarkeit der Server-Systeme der Universität bedeutet", erklärt Abteilungsleiter Kroß. "Diese Argumente sind für die Entscheidungsträger nachvollziehbar."

Einsparungspotenziale entstanden auch an anderer Stelle. Die IT-Planer der HU entschieden sich für den Einsatz von IDE-Festplatten im SAN-Pool. Diese erreichen nicht die Performance von SCSI-Platten, kosten dafür nur rund ein Viertel. Mehrere Arrays sind mit je acht 120-GB-IDE-Platten in Raid-5-Konfiguration bestückt. Die Arrays präsentieren nach außen eine SCSI-Schnittstelle. Ein SAN-Head-Controller von Chaparral verbindet die Arrays über ein 2-Gbit/s-FC-Interface mit dem SAN.

Schlechte Auslastung

Auf diese Weise wird das Performance-Defizit der IDE-Platten wettgemacht, ohne an Verfügbarkeit und Sicherheit zu sparen. Dafür umso mehr bei der Anschaffung neuen Plattenplatzes. "Da bisher für viele Server SCSI-Platten eingesetzt wurden, konnten wir durch die IDE-Variante beträchtliche Einsparungen erzielen und in entsprechend mehr Speicher investieren", fasst Kroß zusammen. Derzeit verfügt der den Instituten zur Verfügung stehende Storage-Pool des Computer- und Medienservice über 40 TB "netto" (gespiegelt 20 TB), 56 TB "brutto". Die Differenz ergibt sich aus der Raid-5-Konfiguration. Von den 40 TB sind 16 TB in Mitte und 24 TB in Adlershof untergebracht.

Die Möglichkeit, den Storage-Pool weitgehend herstellerübergreifend und damit flexibel in Preis und Leistung zu gestalten, ist sicher der Hauptvorteil im SAN-Konzept. Die Praxis zeigt allerdings, dass viele Ressourcen ungenutzt bleiben. Die Storage Networking Industry Association (Snia), eine Vereinigung zur Etablierung von Storage-Standards, schätzt die durchschnittliche Auslastung der SAN-Pools gerade einmal auf 50 bis 70 Prozent. Ursache sind nicht etwa überdimensionierte Systeme, sondern Speicherinseln, die durch "angebrochene" Platten entstehen und nicht mehr anderweitig belegt werden können. Das gilt beispielsweise für die Boot-Vorgänge bei Servern. Obwohl der Prozess selbst nur einen Bruchteil der Platte beansprucht, liegt der Rest brach und kann nicht ohne weiteres anderen Servern zugewiesen werden, deren Pool-Kontingent im SAN zur Neige geht.

Königsweg Virtualisierung

In diesem Fall heißt die Lösung wohl oder übel Plattenzukauf. Das macht auf lange Sicht auch bei relativ günstigen IDE-Systemen einen schönen Batzen Geld aus. Zumal der Storage-Bedarf einzelner Bereiche nicht immer langfristig vorhersagbar ist. Und das Auffüllen des Platten-Pools grenzt in Installationen der HU-Größenordnung auf lange Sicht an schwere körperliche Arbeit.

Diese Erfahrungen machten auch die SAN-Experten in Adlershof. Und schafften Abhilfe in Form einer zusätzlichen Management-Ebene für das Speichernetz, die unter dem Stichwort Storage-Virtualisierung gehandelt wird. Das Konzept ist zwar seit einigen Jahren in aller Munde, gilt in der Praxis aber immer noch als Neuland. Bei der Storage-Virtualisierung präsentieren sich mehrere physikalische Speichergeräte als eine oder mehrere logische Speicherressourcen, so genannte logische Volumes. Der Host sieht auch die logischen (virtuellen) Einheiten als normale SCSI-Disks. Die virtuellen Laufwerke lassen sich in Größe, Schnelligkeit und Ausfallsicherheit ohne Ausfallzeiten an die Bedürfnisse des Anwenders anpassen. Benötigt er größere Plattenkapazitäten, erstellt der Administrator weitere Volumes oder vergrößert die bereits zugewiesenen. Der Verweis auf freie physikalische Einheiten (Block-Aggregation) läuft unsichtbar im Hintergrund ab. Eine Strukturänderung der logischen Volumes sorgt für die schnellere Performance: Datenblöcke werden "zerlegt" und parallel auf verschiedene physikalische Disks geschrieben (Striping). Größere Ausfallsicherheit entsteht durch mehrfaches Schreiben des gleichen logischen Volumes auf mehrere physikalisch unabhängige Disks (Mirroring). Alle Konfigurationsänderungen erfolgen online, ohne Stoppen der Server und Anwendungen. Der Anwender arbeitet mit seinem logischen Volume und den darin enthaltenen Daten weiter.

Nachdem sich die Storage-Experten der HU für dieses Konzept entschieden hatten, stand die Suche nach einer geeigneten Virtualisierungslösung an. Unterstützt wurden die HU-Mitarbeiter dabei vom Systemhaus Controlware, mit dem schon in der Vergangenheit Projekte realisiert worden waren. Die Wahl fiel schließlich auf "IP-Stor" des amerikanischen Herstellers Falconstor. Zunächst wurde die Software in einer rudimentären Konfiguration mit einem Switch, zwei IDE-Raid-Systemen, und zwei PC-Servern gegen ein Konkurrenzprodukt auf Herz und Nieren getestet. "Entscheidend war die Performance der Software unter verschiedenen Aspekten: Kann der Client mit IP-Stor generierte Platten ohne Reboot importieren? Was ist mit der Plattenspiegelung? Wie funktioniert das Failover?", fasst Speicherverwalter Sittel die Testphase zusammen. Die letzten beiden Punkte unterzog das SAN-Team am Computer- und Medienservice einer besonders genauen Prüfung. Schließlich ging es um die Verwaltung einer komplexen SAN-Infrastruktur zwischen vielen Standorten. "Anfangs gefiel uns das Failover-Konzept der Konkurrenz besser", erläutert Sittel, "dort wird der Plattenspiegel auf einem zweiten Virtualisierungs-Server aufgesetzt; der Client verfügt über einen Pfad zu jedem Server und kommt so auch beim Ausfall des Failover-Mechanismus an die Platte heran. IP-Stor spiegelt auf dasselbe Stück Hardware. Da dauert es länger, bis die Umstellung beim Client nachvollzogen ist." Da in der Installation des HU-SAN ohnehin mehrere Virtualisierungs-Server für das Failover zum Einsatz kommen sollten und weitere Hardware für den Plattenspiegel demnach nicht nötig war, konnte dieser Aspekt vernachlässigt werden. "Die Falconstor-Lösung hat einfach bessere Ergebnisse erzielt", fasst Sittel die Testphase zusammen, "endlich können wir in den Speicher-Pool reingucken, genau bestimmen, wer wie viel Kapazität bekommen soll, und das Ganze per Mausklick zuteilen. Das ist im SAN ohne Virtualisierung nicht ohne weiteres möglich. Immerhin geht es hier um 700 Platten in der Größenordnung zwischen 36 und 120 GB."

Die ersten virtualisierten Storage-Portionen wurden an zentrale Datenbank- und Mail-Server sowie an einen Katalog-Server der Universitätsbibliothek verteilt. Anfang April 2003 startete der Betrieb. "Die Virtualisierung dauerte nur einige Minuten", berichtet Sittel. Auch das dynamische Vergrößern der Platten unter der Virtualisierungssoftware funktionierte einwandfrei. Weitere Features von IP-Stor wie die Snapshot- und Timemark-Option (punktuelle Abbilder geänderter Datenblöcke eines unter IP-Stor verwalteten Laufwerks für Backup- und Restore-Prozesse) sind bereits in Lizenz genommen, warten aber noch auf ihren Einsatz. (kk)

*Stefan Müller-Ivok ist Redakteur der P-Age die Presse-Agentur GmbH in München.

Angeklickt

Der Computer- und Medienservice der Humboldt-Universität in Berlin bezog im Februar dieses Jahres das Erwin Schrödinger-Zentrum in Berlin Adlershof. Die Uni-Abteilung erledigt für immer mehr Fakultäten die Speicherverwaltung und hat dazu ein Storage Area Network (SAN) aufgebaut, das mit dem 30 Kilometer entfernten Hauptgebäude verbunden ist.