CMS Journal
Nr. 33
Juni 2010
Service
Metadaten
Hinweise
Weitere Artikel aus dem cms-Journal Nr. 33 finden Sie auf dem edoc-Server der Humboldt-Universität zu Berlin unter http://edoc.hu-berlin.de/cmsj/33
Copyright
Dieser Artikel ist ein Open Access Artikel und steht unter der Creative Commons Lizenz BY (siehe...).

Virtualisierter Speicher im Storage Area Network der HU


Frank Sittel
sittel@cms.hu-berlin.de

Abstract

Vor zehn Jahren begann an der HU der Aufbau eines Speichernetzwerkes und seit sieben Jahren wird die darin befindliche Plattenkapazität virtualisiert. Es ist Zeit für ein Resümee.


Das SAN der HU

Das SAN (Storage Area Network) der Humboldt-Universität wurde bereits 2004 in [1] beschrieben. Wie dort ausgeführt, sind im unserem SAN eine Reihe von Designprinzipien verwirklicht worden, die eine hohe Verfügbarkeit der dort erhältlichen virtuellen Festplatten garantieren sollen. Hervorheben möchte ich an dieser Stelle die Dual-Fabric-Struktur des Fiber-Channel-Netzwerkes und die „Dezentralisierung“ von Speichertürmen und Virtualisierungsservern. Was hat sich nun seit 2004 geändert? Darauf gibt es genau zwei treffende Antworten:

  • nichts
  • alles

Nichts?

An der Struktur hat sich überhaupt nichts geändert. Das FC-Netzwerk ist nach wie vor in zwei Fabrics und nach dem Core-Edge-Prinzip organisiert. Wir virtualisieren weiterhin (fast) den gesamten Plattenbestand mit IPStor von FalconStor. Speicher und Virtualisierungsserver werden heute wie damals über unterschiedliche Standorte verteilt. Alle an unsere Klienten herausgegebenen Platten werden – genau wie vor sechs Jahren – standortübergreifend gespiegelt. Wir verlangen von allen Klienten, mit Multipathing-Treibern die Platten über beide Fabrics in ihr Betriebssystem zu integrieren.

Vor zehn Jahren begann an der HU der Aufbau eines Speichernetzwerkes und seit sieben Jahren wird die darin befindliche Plattenkapazität virtualisiert. Es ist Zeit für ein Resümee. Tabelle 1: Entwicklung der Portzahl

Alles?

Keine einzige aktive Komponente, die im Jahr 2004 ihren Dienst tat, ist heute noch in Betrieb. Das SAN wurde in den letzten sechs Jahren qualitativ und quantitativ kräftig umgestaltet. So hat sich die Geschwindigkeit der Ports vervierfacht, die Anzahl der Ports verdreifacht und das Speichervolumen um den Faktor 16 vergrößert. Jetzt bedienen vier Virtualisierungscluster etwa 250 Klienten mit rund 250 TByte virtuellen Platten. Wie das im Einzelnen aussieht, wird im Folgenden beschrieben.

Das Netzwerk

Die FC-Switche des Jahres 2004 besaßen durchgängig eine Transferrate von 2 GBit/s pro Port. Diese haben einen Upgrade in Richtung 4- und 8-GBit/s erfahren. Eine Übersicht zur Steigerung der Switch- und Portzahl sowie deren Verteilung kann der Tabelle 1 entnommen werden.

Die in den beiden Standorten Mitte und Adlershof eingesetzten Core-Switche sind jetzt vier Brocade DCX (Abb. 1), die auch schon zukünftige 16-GBit/s-Bleche aufnehmen können.

Die kleinen Edge-Switche, die zur Erschließung der Institutsgebäude genutzt werden, sind noch zwei SW4100, ansonsten 20 SW5000, 10 SW5100 und zwei SW5300.

Die Verbindung zwischen Adlershof und Mitte war im Jahre 2004 noch auf 4 × 2 GBit/s beschränkt – derzeit haben wir 4 × 8 GBit/s zwischen den Core-Switchen und aus Redundanzgründen 4 × 4 GBit/s zwischen Edge-Switchen beider Standorte. Für die Verbindungen werden zwei getrennte Glasfaserleitungen benutzt, deren aktive Endgeräte in unterschiedlichen Gebäuden stehen. Es gibt eine Leitung vom Erwin Schrödinger-Zentrum zum Hauptgebäude und eine vom Johann von Neumann-Haus zum Jakob-und-Wilhelm-Grimm-Zentrum. Jede Fabric ist mit je einer 8-GBit/s- und einer 4-GBit/s-Verbindung auf jedem der beiden Einstiegspunkte vertreten. Das sichert bei Ausfall einer Strecke, dass beide Fabrics mit halber Leitungskapazität standortübergreifend verbunden bleiben.

image

Tabelle 1: Entwicklung der Portzahl

image

Abb.1 : DCX und ein Virtualisierungsserver

Die Arrays

Im Jahre 2004 wurden in unserem SAN ausschließlich Platten-Arrays mit Parallel-ATA-Disks (IDE) verwendet. Diese sind inzwischen durch 75 SATA- und 20 SAS-Arrays abgelöst worden. Nach wie vor werden diese als RAID-5 plus eine Reserve-Platte betrieben. Zudem verzichten wir bewusst auf Doppel-Con-troller-Systeme in den Arrays, da das (a) Geld spart und wir (b) ohnehin alle Daten von einem Array in ein zweites, entfernt untergebrachtes Array synchron spiegeln – es besteht immer aus einem RAID-1 über zwei RAID-5-Sets. Die Systeme von Infortrend (Abb. 2) werden auch weiterhin von uns benutzt, da sie ein sehr gutes Preis-Leitungs-Verhältnis besitzen.

image

Abb. 2: Infortrend-Arrays und zwei SW5000

Im Gegensatz zu damals haben aber jetzt alle Arrays eigene FC-Kanäle und die ersten von ihnen auch schon 8 GBit/s. Die im SAN zur Verfügung stehende Festplattenkapazität hat sich in den vergangenen Jahren auch geringfügig von 60 auf etwas mehr als 1000 TByte erhöht. Die Speichertürme, die 80 bis 350 TByte umfassen, sind auf fünf Gebäude verteilt. Alle Daten werden so gespiegelt, dass auch der Totalausfall eines Standortes nicht zum Verlust der Verfügbarkeit führt.

Die Virtualisierungsserver

Die IPStor-Server sind für die Bereitstellung virtueller Platten an unsere Klienten zuständig. Ihre Struktur ist einheitlich und simpel. Sie besitzen vier FC-Adapter-Ports im Initiator-Mode, die so konfiguriert sind, dass nur sie die realen Arrays sehen können. Die Klienten-Adapter ihrerseits verbinden sich mit vier weiteren FC-Ports der IPStor-Server, die sich im Target-Mode befinden, d. h. jeder Klient sieht jede ihm zugewiesene virtuelle Platte viermal. Man kann den Weg der Daten in der Abbildung 3 verfolgen. Als Vorlage diente das Bild von 2004 mit einigen gravierenden Unterschieden.

image

Abb. 3: Datenpfade in der Speichervirtualisierung

Jetzt werden alle Pfade vom Virtualisierungsserver zu den Disks per Multipath benutzt – 2004 gab es nur einen benutzten Pfad, der im Fehlerfall gewechselt wurde. Aber der wichtigste Unterschied ist wohl der, dass als zweiter Teil des synchronen Spiegels jetzt nicht mehr ein Array dient, sondern ein weiterer Virtualisierungsserver. Die Frontend-Systeme V0/V1 bedienen die Klienten mit virtuellen Disks und bauen für diese Platten den Spiegel zwischen

einem ihrer Arrays und dem Backend-Server V2 … und Schluss – mehr machen V0/V1 nicht mehr: spiegeln, Platte herausgeben, fertig. Die CDP-Maschine (CDP steht für die Funktion der Maschine und bedeutet in der Langform „Continuous Data Protection”) ist für das Abspeichern der Mirror-Daten zuständig und für alle Mehrwertdienste wie Snapshots, alte Plattenzustände zurückzuholen, Daten auf andere Standorte zu replizieren usw. Der Sinn von diesem Gebilde liegt in einer Funktionsteilung. Der erweiterte Snapshot-Mechanismus und Replikationen sind Hauptspeicher- und CPU-intensive Aufgaben, die die Virtualisierungsserver bei einem eventuellen Failover der Maschinen schwer behindert haben. So wurden diese Funktionen an einen Backend-Server ausgelagert.

Während vor sechs Jahren nur diskrete Snapshots in Intervallen von 1 Minute bis 1 Tag möglich waren, kann man nun zusätzlich einen „Continuous“Knopf drücken und der CDP-Server merkt sich dann alle geänderten Blöcke und deren genauen Änderungszeitpunkt. Dieses Feature ermöglicht nun, die Platte im Snapshot-Zeitraum zu jedem x-beliebigen Zeitpunkt im Millisekundenraster zu rekonstruieren. Im Moment benutzen wir dieses Feature nicht, da gerade länger laufenden Snapshots auf diese Weise gewaltige Snapshot-Volumen produzieren können, die deutlich größer sind als die Platte, von der sie kommen. Schließlich muss das System sich ja alle geänderten Blöcke merken.

Die größten Feinde unseres SAN sind der lokale Stromversorger, Klimaanlagen- und USV-Betreiber und Baumaßnahmen. So hat es uns schon oft gerettet, dass die beiden Frontendserver eines Clusters prinzipiell in verschiedenen Gebäuden untergebracht sind. Zusammen mit einer geschickten Verkabelung und Verteilung der Arrays ist so eine Weiterführung unseres Dienstes auch dann möglich, wenn ganze Straßenzüge stundenlang stromlos werden. Selbstverständlich haben unsere neuen Virtualisierungsserver jetzt 8-GBit/s-Adapter.

Unsere Klienten

Wie schon oben beschrieben, erhalten unsere Klienten alle ihre virtuellen Platten auf vier Pfaden, d. h. sie sehen vier Ansichten exakt der gleichen Platte im Betriebssystem. Die lokalen Administratoren sind also gezwungen (bzw. werden von uns genötigt), mit einem aktiv-aktiv-Multipath-Treiber diese vier Ansichten wieder zu einer zu vereinigen. Für die Betriebssystemklassiker Windows, Solaris und AIX steht DynaPath von FalconStor zur Verfügung, der außerdem noch den Vorteil bietet, durch seine internen Timeout-Einstellungen den Klienten robust gegen Failover der Virtualisierungsserver zu machen. Vor sechs Jahren waren Linux-Systeme in diesem Punkt noch problematisch – aber inzwischen ist Linux ein Stück erwachsener und unsere Kenntnisse um Kernel und FC-Treiber sind besser geworden. Wir besitzen jetzt für die gängigsten Linux-Derivate Anleitungen zur Konfiguration der Multipathing-Tools und der Parameter in der Fiber-Channel-Transportebene, so dass auch Linux-Systeme ein robuster Bestandteil unseres SANs geworden sind.

Inhaltsverzeichnis

Das SAN der HU...

Zu guter Letzt ...

Literatur ...


Zu guter Letzt

Sinngemäß schrieb ich vor sechs Jahren, dass wir uns in Tests mit iSCSI beschäftigen wollen – glücklicherweise fehlten uns dafür die personellen Ressourcen. Diese Technologie konnte sich nicht durchsetzen, vermuten wir mal, weil sie weder performant noch robust ist? Wir werden uns jetzt vornehmen, einen Blick auf das neue Protokoll FCoE (Fiber Channel over Ethernet) zu werfen. Ich bin gespannt, was wir in sechs Jahren darüber schreiben werden.

 

Literatur

[1]Sittel, F.: Institute ans SAN. cmsjournal 25, Mai 2004 bzw. http://edoc.hu-berlin.de/e_rzm/25/sittelfrank-2004-05-II/PDF/21.pdf