Der Schutz für den SAN-Betrieb beginnt bei der Wahl der Topologie. Man unterscheidet physikalische und logische Topologien. Im physikalischen Konzept bildet man die tatsächlich verwendeten Switches, Datenpfade, Server und Speichersysteme ab. Bei der Frage nach Ausfallsicherheit und Verfügbarkeit im SAN sollte allerdings der logische Aufbau des Speichernetzes im Mittelpunkt stehen. Das Kriterium ist dabei die Anzahl der Hops (Weiterleitung von einem Router zum nächsten) oder Inter Switch Links (ISLs), die ein Datenpaket zwischen Rechner und Storage-Array passieren muss. ISLs sind spezielle Verbindungen zum Datenaustausch zwischen Switches. Als Faustregel gilt: Je kleiner die Zahl der Hops und ISLs, desto besser ist das für Verfügbarkeit und Ausfallsicherheit.

Im "Full Mesh Design" etwa sind alle Switches miteinander verbunden. Das Datenpaket muss damit höchstens einen ISL zwischen Rechner und Storage passieren. Diese Komponenten können sich an beliebigen Stellen im SAN befinden, wodurch sich die Architektur flexibel aufbauen und erweitern lässt.

Prioritäten beim Design setzen

Das "Core Edge Design" wird verwendet, wenn deutlich mehr Rechner als Speicher in das SAN einzubinden sind. Dabei sind der Storage-Seite meistens zwei oder mehr untereinander verbundene Directors vorgeschaltet (Core), also FC-Switches mit besonders hoher Port-Dichte und Fehlertoleranz. Vor den Rechnern liegen vier oder mehr nicht verschaltete Switches (Edge). Diese Architektur bietet die Voraussetzungen dafür, die Rechner im SAN nach unterschiedlichen Schutzstufen zu klassifizieren. Wird Hochverfügbarkeit benötigt, lassen sich die entsprechenden Rechner direkt mit den Core-Directors verbinden. Sie können dann mit hoher Bandbreite auf den Speicher zugreifen, ohne einen ISL passieren zu müssen. Die restlichen Geräte werden über die Edge-Switches zugänglich gemacht.

Sicherheit hat ihren Preis

Egal, welcher SAN-Aufbau letztlich gewählt wird: Wer Ausfallsicherheit und Verfügbarkeit über die Topologie herstellen will, muss mit hohen Anschaffungs- und Administrationskosten rechnen. Der Director etwa kommt auf deutlich höhere Verfügbarkeitswerte als der Switch und sollte dann eingesetzt werden, wenn das Maximum an Verfügbarkeit - 99,999 Prozent - erforderlich ist. Erhebliche Unterschiede gibt es beim Preis. Über den Daumen gepeilt, kann man für einen Director die vier- bis sechsfachen Kosten eines Switches veranschlagen. Dafür erfordert jeder zusätzliche Switch ungleich mehr Management-Aufwand als der Director. Bei der SAN-Planung muss das Unternehmen also nicht nur das verfügbare Budget, sondern auch die vorhandenen personellen und fachlichen Ressourcen genau ins Kalkül ziehen.

Stichwort Planung: Jede zusätzliche SAN-Komponente erhöht die Zahl der ISLs und verringert entsprechend die verfügbaren Ports. Ergänzungen im Speichernetz sind irgendwann nur noch sehr schwer oder gar nicht mehr möglich. Die Port-Kapazität von Switches und Directors muss also so kalkuliert werden, dass die nötige Skalierbarkeit für langfristiges Wachstum gewährleistet ist und weitere Standorte in das SAN eingebunden werden können. Dieser Punkt wird oft vernachlässigt, oder in der Planung nicht ausreichend berücksichtigt, so dass in Zukunft Engpässe entstehen.

Ausfallquelle Disk-Subsystem

Auch wenn die Wahl der Topologie schon wesentlich die Weichen für Ausfallsicherheit und Verfügbarkeit im SAN stellt, genügt es nicht, das Thema nur von der Designseite her anzugehen. Wie die Praxis zeigt, hat selbst die komplexeste Redundanzarchitektur ihre Achillesferse.

Sie liegt allerdings meistens nicht dort, wo man sie erwarten würde, nämlich auf der Switch-Ebene. Störungen und Ausfälle entstehen vielmehr in der Regel auf der Storage-Seite. Exemplarisch kann man das an Subsystemen mit SATA-Raid beobachten: Fällt eine Disk im Verbund aus, kann die Hot-Spare-Platte oft nicht eingebunden werden, weil sie selbst fehlerbehaftet ist, was aber nicht bemerkt wurde. Bleibt es bei dem einen Ausfall, läuft der Speicherbetrieb zwar weiter, das Raid-System aber ist kritisch geworden: Steigt eine weitere Disk aus, ist es um das Platten-Cluster geschehen. Das Rebuild eines SATA-Verbundes dauert wegen der großkapazitativen Platten besonders lange; man kann durchaus mit einem ganzen Tag rechnen.

Solche Probleme liegen aber nicht an grundsätzlichen Schwächen des SATA-Standards. Die meisten Ausfälle entstehen wegen schlecht gedämpfter Subsystem-Gehäuse. In diesem Fall greifen die Vibrationen, die durch die Spindeldrehungen einer Platte entstehen, ungebremst zuerst auf die Nachbar-Disk und dann auf alle Platten im Verbund über. Die Schreib- und Leseköpfe werden durch die Schwingungen sprichwörtlich aus der Spur geworfen und können die Daten nicht mehr korrekt auslesen und schreiben. Die Operationen müssen dann wiederholt werden, was zu signifikanten Leistungseinbußen und schließlich zum Ausfall des gesamten Plattenverbundes führen kann.

Security fängt beim Hersteller an

Warum gerade SATA-Subsysteme davon betroffen sind, ist leicht zu erklären. Viele Hersteller verhalten sich noch so, als würden die Platten nach wie vor nur als billiges Medium für das Backup eingesetzt werden. Ob sie beispielsweise für den 24x7-Betrieb geeignet sind, spielt bei der Produktentwicklung häufig keine oder nur eine untergeordnete Rolle. SATA-Disks haben jedoch mittlerweile einen großen Anteil an der Speicherlandschaft und werden durchaus für Storage-Aufgaben genutzt, die bislang den vergleichsweise teuren SCSI- oder FC-Pendants vorbehalten waren. Die Berliner Humboldt-Universität etwa verwaltet bereits 57 TB Daten auf SATA-Raid-Systemen.

Wer Ausfälle im Speichernetz vermeiden will, sollte sich also auch danach erkundigen, wie umfassend Hersteller ihre Plattensysteme testen. Ein aussagekräftiges Qualitätsmerkmal ist zum Beispiel, ob nicht nur die Platten selbst unter die Lupe genommen, sondern auch Schwachstellen im Gehäusedesign aufgedeckt werden, etwa durch Wärmebildkameras. Dann ist die Gefahr eines Ausfalls durch ungedämpfte Vibrationen von vornherein verringert. Wichtig sind auch Burn-in Tests, bei denen die Platten von den Herstellern im Dauereinsatz über einen längeren Zeitraum bei unterschiedlichen Temperaturen und Feuchtigkeitsverhältnissen auf fehlerhafte Sektoren geprüft werden.

Raid-Controller sollen reifen

Was für die Platten-Subsysteme gilt, gilt auch für Raid-Controller: Sie fallen aus, weil die einzelnen Komponenten wie PCI-Bus, DDR-RAM und Speicheradressierung nicht optimal aufeinander abgestimmt sind. Neue Produkte kommen in möglichst kurzen Entwicklungszyklen auf den Markt, ohne dass sie mit der nötigen Intensität getestet worden sind. Dabei sollte gerade bei SAN-kritischen Komponenten wie dem Raid-Controller die "Reifezeit" besonders lang sein. Oft haben Modelle, die bereits seit fünf Jahren verkauft werden, erst heute einen genügenden Stabilitätsgrad erreicht, genügen aber schon nicht mehr gängigen Performance-Anforderungen.

Um derartige Überraschungen im SAN-Betrieb zu vermeiden, hilft auch hier ein Blick hinter die Kulissen des Herstellers: Beschränkt er sich auf die reine Produktion, oder verfügt er über eigene Testeinrichtungen? Wenn ja, nutzt er sie nur für die eigenen Produkte, oder stellt er die Infrastruktur und das Know-how auch als Dienstleister zur Verfügung? Kann man also davon ausgehen, dass er ein gewisses Renommee am Markt besitzt?

Wer hamoniert mit wem?

Bei neuen Technologien dreht sich in der Regel zunächst alles um die Interoperabilität mit den Storage-Lösungen der großen Hersteller. Das ist nachvollziehbar, denn gerade Anbieter spezieller Add-on-Produkte müssen sich zuerst an den Flaggschiffen ausrichten, wenn sie auch an größeren Projekten partizipieren wollen. Für Anwender, die die Lösungen der "A-Brands" aus Budget- und Komplexitätsgründen nicht einsetzen wollen, ergibt sich ein Problem: Sie können nicht immer sicher sein, dass die Alternativangebote untereinander harmonieren, da Tests zur Interoperabilität auf dieser Ebene häufig vernachlässigt werden.

Aber auch wenn es Zertifizierungs-Matrizes gibt, ist nicht garantiert, dass die auf dem Papier getesteten Produkte im tatsächlichen SAN reibungsfrei agieren. Schuld daran ist in den meisten Fällen fehlerhaft programmierte Firmware. Dass Mängel gerade dort auftreten, lässt sich auf die heutige Komplexität der zugehörigen Produkte zurückführen. Es ist einfacher, eine Firmware für einen FC-Hostbus-Adapter zu schreiben, als für einen Switch, der nicht nur SAN-Verbindungen herstellt, sondern zusätzlich komplexe Management-Funktionen wie Speichervirtualisierung übernimmt.

Diesen Fallstricken kann man entgehen, indem man entweder beim Hersteller nachfragt, welche Firmware-Versionen der in der Matrix angegebenen Zertifizierung tatsächlich zugrunde lagen, oder Lösungen von Herstellern nutzt, die von sich aus möglichst lange bei einer bewährten Firmwareversion bleiben. Ein dritter Weg ist die Zusammenarbeit mit Dienstleistern, die Lösungen aus Komponenten unterschiedlicher Hersteller für bestimmte Einsatzfelder selbst integrieren und in Kooperation mit spezialisierten Servicepartnern umfassend testen.

Gespiegelt - gesichert?

Im folgenden Abschnitt geht es um die wichtigsten softwareseitigen Mechanismen, die im täglichen Speicherbetrieb vor unliebsamen Überraschungen schützen. Eine weit verbreitete Option ist das Mirroring: Um zwei konsistente Datenträger zu erhalten, werden zunächst die Daten einer Festplatte auf eine andere gespiegelt. Bei der synchronen Variante werden dann die Schreibanforderungen des angebundenen Applikations-Servers gleichzeitig an beide Festplattensysteme gesendet. Fällt die Primärdisk aus, führt die gespiegelte den Speicherbetrieb ohne Unterbrechung weiter.

Haupt- und Ersatzdisk können auf demselben Storage-System liegen, beispielsweise auf separaten Laufwerken im Raid- oder JBOD-Verbund, aber auch räumlich getrennt sein. Dann empfiehlt es sich, den Spiegel in den nächsten Brandabschnitt zu legen und dafür zu sorgen, dass beide Speicherorte über getrennte Stromkreise gespeist werden. Die synchrone Spiegelung ist auch nützlich, wenn ein Plattenaustausch ansteht. Er kann ohne Downtime erfolgen, da die Ersatz-Disk so lange den Speicherbetrieb übernimmt.

Synchron oder asynchron?

Noch mehr Sicherheit entsteht, wenn die beiden Speicherorte in verschiedenen Gebäuden liegen. Dann bietet sich die asynchrone Spiegelung an: Nach der Synchronisation von primärer und sekundärer Disk werden die Schreibanfragen des Applikations-Servers zunächst in einem separaten Bereich am primären Standort zwischengelagert und von dort aus in definierten Intervallen an den Ersatzort übermittelt. Die Verzögerung führt zu mehr Performance auf der primären Speicherseite, da die Haupt-Disk nicht mit dem Speichern warten muss, bis die Schreibanforderung auch von der sekundären Platte bestätigt ist.

Die asynchrone Spiegelung empfiehlt sich auch aus einem anderen Grund für größere Distanzen: Sollen größere Datenmengen synchron gespiegelt werden, braucht es mit zunehmender Entfernung immer höhere Durchsatzraten, oder die Übertragung dauert entsprechend lange. Den nötigen Durchsatz bekommt man am ehesten über dedizierte Standleitungen. Das ist ökonomisch aber selten sinnvoll, denn die zu transportierende Datenmenge ist nicht immer so groß, dass sie die teure Leitung wirklich ausschöpft.

Die zweite Möglichkeit ist die Anschaffung einer Appliance für die Bandbreitenzuteilung. Sie räumt dem Transfer der Spiegeldaten gegenüber anderen Anwendungen im Netz immer genügend Platz ein. Aber auch das sind zusätzliche Investitionen. Wer also nicht auf höchste Verfügbarkeit im SAN angewiesen ist, fährt mit der asynchronen Variante langfristig günstiger und genauso sicher.

Snapshot als Zeitgedächtnis

Das Mirroring-Konzept schützt das SAN nur bei einwandfreier Datenqualität. Sind die Daten bereits auf der Hauptspeicherseite beschädigt, liefert auch der Spiegelstandort korruptes Material. Deshalb benötigt das Mirroring eine Absicherung gegen den "schleichenden" Datenverlust, der in der Praxis eher Regel als Ausnahme ist. Die Absicherung besteht darin, auf Laufwerkszustände vor Beginn der Datenkorruption zuzugreifen. Das geht mit Hilfe der Snapshot-Methode. Dabei werden in bestimmten Intervallen exakte Abbilder von Datenträgern oder Dateisystemen genommen und gesichert. Ist der Beginn eines Zwischenfalls erkannt, wird eines der "gesunden" Abbilder aus der Zeit davor eingespielt, und der Speicherbetrieb läuft auf dieser Basis weiter.

Eine sinnvolle Variante des Snapshot-Prinzips besteht darin, nur die Änderungen an den Datenblöcken zu erfassen und mit einem Zeitstempel als Journal abzuspeichern. Das spart Speicherplatz und Einspiel-Zeit. Ein schleichendes Ausfallszenario und das entsprechende Recovery kann so aussehen: Um 15 Uhr stellt der Administrator fest, dass eine Viren-Attacke die Disk beschädigt hat. Als Ursache ermittelt er ein um 13 Uhr aufgerufenes infiziertes Programm. Kommt Mirroring zum Einsatz, wurden die letzten zwei Stunden korrupte Daten also auch vom primären an den sekundären Speicherort übertragen. Um das Problem zu beheben, muss der Administrator nur den Journaleintrag mit den Block-Änderungen einspielen, der unmittelbar vor dem Zwischenfall erstellt wurde. Die Kombination des Eintrags mit einer gespeicherten Kopie des ursprünglichen Laufwerks stellt ein exaktes Abbild des Storage-Zustands vor der Virenattacke her. Das Abbild wird beiden Standorten verfügbar gemacht. Damit geht der Speicherbetrieb so weiter, als hätte die Datenkorruption nie stattgefunden, während die beschädigten Festplatten in aller Ruhe repariert werden können. Die Rekonstruktion des Laufwerkszustands bewältigen Storage-Management-Lösungen heute in Sekunden.

Auch der Snapshot hat sein "Aber". Gerade in Anwendungsfeldern mit hohem Performance-Zwang ist das Verfahren nur wirksam, wenn dafür gesorgt wird, dass die Abbilder im Ernstfall ohne jede Verzögerung beigebracht werden können. Das ist auf den normalen Backup-Wegen via LAN und Bandbibliothek eher nicht gegeben.

Virtuelle Beschleuniger

Abhilfe schafft hier eine Virtual Tape Library (VTL), die gängige Bandbibliotheken auf einem Disk Array emuliert. Die Snapshot-Daten werden über schnelle Fibre-Channel- oder iSCSI-Verbindungen dorthin übertragen beziehungsweise von dort zurückgeholt. Das File-System der VTL ordnet die Disk Volumes als virtuelle Ressourcen an und weist sie den Backup-Hosts nach Bedarf zu. Jeder Server kommuniziert so mit einem festgelegten Laufwerk, das er nicht mit anderen teilen muss. Dort abgelegte Snapshots lassen sich also ohne Beeinträchtigung durch weitere simultane Restore-Anforderungen bereitstellen. (kk)