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.

22.03.2006

Verschlungene Netzpfade ohne Fallstricke

Andreas Müller
Die Ausfallsicherheit im komplexen Storage Area Network zu garantieren, gehört heute zu den größten Herausforderungen für IT-Planer. Schon kleinste Störungen können fatale Folgen haben.
Snapshots stellen eine Momentaufnahme der Laufwerkszustände dar.
Snapshots stellen eine Momentaufnahme der Laufwerkszustände dar.

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.

Hier lesen Sie …

Checkliste vor dem Start und im Betrieb

Reporting-Software installieren:

Für Raid-Controller sehr wichtig, um die häufigste Störungsquelle, die Plattenausfälle, frühzeitig zu erkennen.

Snapshot-Intervalle definieren:

Ein- bis zweimal pro Tag sollten die Laufwerksabbilder genommen werden.

LUN-Zuweisung für Sekundärspeicher:

Frühzeitig Logical Unit Numbers (LUNs) für sekundären Storage definieren, damit Applikations-Server bei Bedarf sofort darauf zugreifen können.

Störungen beim Mirroring vorbeugen:

Daten am Sekundärort zwischenspeichern, erst auf Replika-Disk schreiben, wenn Datenset fehlerfrei übertragen wurde.

Checkliste für Architektur und Ausstattung

Grad an notwendiger Verfügbarkeit, Backup/Restore-Performance für jeden Anwendungsbereich bestimmen:

• Kriterium: 24x7-Betrieb oder nicht?

• Wo müssen Daten kurzzeitig, wo über lange Zeiträume vorgehalten werden?

• Welche Daten werden häufig, welche seltener angefordert?

Erweiterbarkeit und Skalierbarkeit der Komponenten berücksichtigen:

• Neue Standorte und Abteilungen kommen im SAN dazu, also Switches/Direktoren mit genügend Ports anschaffen, um Erweiterungen später redundant verschalten zu können.

Speicherressourcen auf ihre tatsächliche Verwendung hin planen:

• Storage-Kapazitäten auf geplante Management-Optionen abstimmen. Beispiel Mirroring: Nur die Hälfte der nominellen Vorräte ist de facto nutzbar.

• Plattenpool-Design: Unterschiedliche Plattenstandards nutzen und nach Performance-Aspekten zuweisen.

Interoperabilität der Komponenten sicherstellen:

• Zertifizierungs-Matritzen auf Build- und Firmware-Versionen prüfen.

• Vor SAN-Erweiterung: Aktuelle Versions-Zertifizierungen prüfen.

• Testverfahren für Komponenten bei Hersteller/Anbieter erfragen.

• Teststellung vor Ort aufbauen.

Fazit

Es gibt heute viele Wege, sich vor Ausfällen im SAN zu schützen. Welche letztlich gewählt werden, richtet sich immer nach zwei Faktoren, die bei der Planung des Speichernetzes geklärt sein müssen: Wie viel Systemausfall kann das Unternehmen verkraften, und wie groß darf der maximale Datenverlust sein? Diese Fragen werden anhand der Kenngrößen Recovery Time Objective (RTO) für die Ausfallzeit und Recovery Point Objective (RPO) für den tolerierbaren Datenverlust beantwortet. Ein Print-Server muss in der Regel bei weitem nicht so gut vor Ausfällen und Datenverlust geschützt sein wie eine Kundendatenbank oder ein von mehreren Niederlassungen gemeinsam genutztes Online-Buchungssystem. Ein Web-Server muss ständig verfügbar sein, verträgt aber verlorene Daten vergleichsweise gut. In diesem Fall ist also der RTO-Faktor hoch, der RPO-Faktor niedrig.

Diese Überlegungen erhöhen nicht nur von Beginn an die Sicherheit im SAN-Betrieb, sondern zeigen auch auf, welche Speicher-Management-Funktionen eingesetzt werden sollten, um den nötigen Schutz zu gewährleisten, und in welchem Maß dafür vorhandene Ressourcen genutzt und damit teure Neuinvestitionen vermieden werden können.

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)