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

Sittel, Frank

edoc Publication server

Virtualisierter Speicher im Storage Area Network der HU

Dokumenten-Publikationsserver der Humboldt-Universität zu Berlin

26 cms-journal 33 / Juni 2010Virtualisierter Speicher im Storage Area Network der HUFrank Sittel | sittel@cms.hu-berlin.deDas SAN der HU Das SAN (Storage Area Network) der Humboldt-Universität wurde bereits 2004 in [1] beschrieben. Wie dort ausge-führt, sind im unserem SAN eine Reihe von Designprinzipien verwirklicht wor-den, die eine hohe Verfügbarkeit der dort erhältlichen virtuellen Festplatten garan-tieren 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 Ant- worten: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 Virtuali-sierungsserver werden heute wie da- mals über unterschiedliche Standorte verteilt. Alle an unsere Klienten heraus-gegebenen 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.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 quan-titativ 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 Virtuali-sierungscluster etwa 250 Klienten mit rund 250 TByte virtuellen Platten. Wie das im Einzelnen aussieht, wird im Folgenden beschrieben.Das NetzwerkDie 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 entnom-men 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 ge-nutzt 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 2004 2010Standort Zahl Switche Ports 2GBit/s Zahl Switche Ports 8GBit/s Ports 4GBit/sAdlershof 14 368 24 528 416Mitte 6 176 14 544 64Gesamt 20 544  38 1072 480Tabelle 1: Entwicklung der PortzahlVor 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.27Virtualisierter Speicher im Storage Area Network der HUwir 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 unter-schiedlichen 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 Leitungs-kapazität standortübergreifend verbun-den bleiben.Die ArraysIm Jahre 2004 wurden in unserem SAN  ausschließlich Platten-Arrays mit Paral- lel-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.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 ver- gangenen 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 VirtualisierungsserverDie IPStor-Server sind für die Bereitstel- lung virtueller Platten an unsere Klienten  zuständig. Ihre Struktur ist einheitlich und simpel. Sie besitzen vier FC-Adap- ter-Ports im Initiator-Mode, die so kon-figuriert 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 ver-folgen. Als Vorlage diente das Bild von 2004 mit einigen gravierenden Unter-schieden.Jetzt werden alle Pfade vom Vir-tualisierungsserver 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 zwei-ter 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 Abb.1 : DCX und ein VirtualisierungsserverAbb. 2: Infortrend-Arrays und zwei SW5000Abb. 3: Datenpfade in der Speichervirtualisierung28 cms-journal 33 / Juni 2010einem ihrer Arrays und dem Backend-Server V2 … und Schluss – mehr machen  V0/V1 nicht mehr: spiegeln, Platte her- ausgeben, fertig. Die CDP-Maschine (CDP steht für die Funktion der Maschine  und bedeutet in der Langform „Contin-uous Data Protection”) ist für das Abspei-chern der Mirror-Daten zuständig und für alle Mehrwertdienste wie Snapshots, alte Plattenzustände zurückzuholen,  Daten auf andere Standorte zu replizie-ren usw. Der Sinn von diesem Gebilde liegt in einer Funktionsteilung. Der er- weiterte Snapshot-Mechanismus und Replikationen sind Hauptspeicher- und CPU-intensive Aufgaben, die die Virtu-alisierungsserver bei einem eventuellen Failover der Maschinen schwer behindert  haben. So wurden diese Funktionen an einen Backend-Server ausgelagert.Während vor sechs Jahren nur dis- krete Snapshots in Intervallen von 1 Mi- nute 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 Änderungszeit-punkt. Dieses Feature ermöglicht nun, die Platte im Snapshot-Zeitraum zu jedem x-beliebigen Zeitpunkt im Milli-sekundenraster zu rekonstruieren. Im Moment benutzen wir dieses Feature nicht, da gerade länger laufenden Snap- shots auf diese Weise gewaltige Snap- shot-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, Klima-anlagen- und USV-Betreiber und Bau- maßnahmen. So hat es uns schon oft  gerettet, dass die beiden Frontendserver eines Clusters prinzipiell in verschie-denen Gebäuden untergebracht sind. Zusammen mit einer geschickten Ver-kabelung 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 KlientenWie 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 Admi-nistratoren 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 Win-dows, 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 erwach-sener und unsere Kenntnisse um Kernel und FC-Treiber sind besser geworden. Wir besitzen jetzt für die gängigsten Linux-Derivate Anleitungen zur Konfi-guration der Multipathing-Tools und der Parameter in der Fiber-Channel-Trans-portebene, so dass auch Linux-Systeme ein robuster Bestandteil unseres SANs geworden sind.Zu guter LetztSinngemäß schrieb ich vor sechs Jahren, dass wir uns in Tests mit iSCSI beschäf-tigen 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. cms-journal 25, Mai 2004 bzw. http://edoc.hu-berlin.de/e_rzm/25/sittel-frank-2004-05-II/PDF/21.pdf

https://edoc.hu-berlin.de/bitstream/18452/7249/1/sittel.pdf

Virtualisierter Speicher im Storage Area Network der HU

Abstract

Similar works

Full text

Available Versions

edoc Publication server

Dokumenten-Publikationsserver der Humboldt-Universität zu Berlin