Zusätzlich zu Unternehmensfusionen und Konsolidierungsmaßnahmen sorgt noch eine dritte Entwicklung dafür, dass die Datenspiegelung in heterogenen Netzen ständig an Bedeutung gewinnt: Highend-Enterprise-Speicher-Arrays sind in Umgebungen unverzichtbar, die hohe Leistungsfähigkeit, Zuverlässigkeit und Datensicherheit benötigen. Gleichzeitig stellen sie aber für Anwendungen mit geringeren Anforderungen an die Datenverfügbarkeit eine zu teure Lösung dar. Darüber hinaus verhindern sie den Einsatz preisgünstiger Mittelklassesysteme, da diese in der Regel nicht mit den Highend-Arrays kommunizieren können. Deswegen müssen die Administratoren eine Methode zur Datenreplikation implementieren, die völlig unabhängig von einer bestimmten Speicherplattform ist. Nur so lässt sich eine Lifecycle-Strategie realisieren, die gleichzeitig Kosten spart und die Effizienz der IT-Umgebung verbessert.
Egal welche Technik für die Datenspiegelung zum Einsatz kommt, zunächst müssen die Verantwortlichen festlegen, welcher Replikationsmodus die Anforderungen der zu schützenden Anwendung am besten erfüllt. Dafür ist eine Klassifizierung der Applikationen wichtig. Das bedeutet, es muss untersucht werden, welche Ausfallzeiten für die einzelnen Anwendungen tolerierbar sind. Das Gleiche gilt für die Auswirkungen, die der Replikationsvorgang auf die Programmleistung hat.
Drei Alternativen zur Auswahl
Die Point-in-Time-Replikation generiert ein Snapshot-Image des Speicher-Volumens zu dem Zeitpunkt, an dem das Replikationswerkzeug aufgerufen wurde. Mit dieser Methode lassen sich zum Beispiel zeitgesteuert mehrere Replika einer Datenbank anlegen. Um ein konsistentes Image für die Replikation vorzubereiten, stehen Datenbank-Agents zur Verfügung, die mit der jeweiligen Applikation zusammenarbeiten. Beispielsweise kann ein Exchange-Agent die Exchange-Datenbank eines Unternehmens zu einem bestimmten Zeitpunkt stoppen, für die Erstellung des Snapshots sorgen und dann die Datenbank wieder starten. Da beim Erstellen der Replik keine Daten, sondern nur Pointer übertragen werden, dauert dieser Vorgang nur einen Sekundenbruchteil. Im nächsten Schritt wird der Snapshot dann auf ein sekundäres Speichermedium kopiert, um eine entfernte Kopie des primären Volume zu generieren. Die Auswirkungen der Point-in-Time-Methode auf die Applikationsleistung sind vernachlässigbar. Im Problemfall ist die Datenverfügbarkeit bei der Point-in-Time-Replikation aber am niedrigsten. Wird der Zu-griff auf das primäre Speicher-Volume unterbrochen, gehen alle Daten verloren, die seit dem letzten Snapshot generiert wurden.
Bei der asynchronen Replizierung ist das Risko, Daten zu verlieren, deutlich geringer. Jede Datenübertragung zum primären Speicher-Volume wird bei dieser Methode unverzüglich auf ein zweites Speichermedium repliziert. Das heißt, die Kopie bleibt fast in Echtzeit auf dem aktuellen Stand. Idealerweise laufen die primären und sekundären Schreibvorgänge unabhängig voneinander, da damit die Gefahr eines Leistungsrückgangs bei der Applikation reduziert wird. Allerdings tritt das Problem der "Lost-in-Flight-I/Os" auf. Damit bezeichnet man Schreibvorgänge, die auf dem ersten Volume erfolgreich abgeschlossen wurden, auf dem zweiten aber noch nicht. Fällt eine Komponente aus, so müssen die Speicheradministratoren zunächst die Datenintegrität herstellen, bevor sie den Anwendungen das zweite Volume zur Verfügung stellen können.
Leistung versus Sicherheit
Die synchrone Datenreplikation schließt das Fenster für Datenverluste vollständig. Bei dieser Methode schreibt die Anwendung die Daten simultan auf beide Volumes und wartet mit dem Fortfahren, bis beide Schreibvorgänge erfolgreich abgeschlossen wurden. Die synchrone Replikation bringt also die höchste Datensicherheit mit sich, hat gleichzeitig aber auch die größten Auswirkungen auf die Leistung der betroffenen Programme, da die Schreibzyklen länger werden.
Die Auswahl des richtigen Replikationsmodus für eine spezifische Plattform setzt folglich ein detailliertes Verständnis der jeweiligen Applikation und ihrer Wichtigkeit für die Business Continuity voraus. Die Verantwortlichen müssen die Anforderungen an Leistung und Datensicherheit genau gegeneinander abwägen und sich dann für die richtige Methode entscheiden.
Wer spiegelt die Daten?
Steht der einzusetzende Modus einmal fest, so können für die Datenspiegelung drei verschiedene Techniken zum Einsatz kommen, je nachdem, ob die Replikation im Subsystem, im Server oder im SAN erfolgt. Bei der Array-basierenden Replikation kommt die Spiegelungstechnik des jeweiligen Anbieters zum Einsatz. Alle Hersteller von Enterprise-Speichern bieten dafür eine Lösung an. Dazu gehören beispielsweise SRDF von EMC, PPRC von IBM, True-Copy von Hitachi Data Systems und Continuous-Access von HP. Diese Lösungen bieten eine sehr gute Failover-Funktionalität und erfüllen die Anforderungen hochverfügbarer Applikationen. Diese Art der Replikation verwendet den Controller des Speicher-Arrays als Plattform für die Datenspiegelung und wird deshalb auch oft als Controller-basierende Replikation bezeichnet. Mit ihr lassen sich Service-Level-Garantien erzielen, die mit anderen Methoden kaum erreichbar sind. Der Nachteil dieser Technik liegt in den hohen Kosten, denn sie funktioniert nur mit zwei ähnlich konfigurierten Highend-Storage-Arrays. Dadurch steigen sowohl der Aufwand für Anschaffung und Wartung als auch die Lizenzgebühren und die Bindung an den jeweiligen Hersteller.
Lösung für heterogene Systeme
Bei der Server-basierenden Replikation kommt in der Regel eine Software zum Einsatz, die mit jeder Speicherhardware funktioniert, die an den betroffenen Rechner angeschlossen wurde. Das bedeutet, diese Lösung bietet bereits eine heterogene Speicherunterstützung. Der Nachteil liegt darin, dass die Lizenzen für solche Produkte teuer und die Handhabung schwierig ist, denn die Replikationsprogramme müssen auf jedem Server und Backup-Server installiert werden. Steht eine homogene Server-Landschaft zur Verfügung, reicht unter Umständen ein Programm aus. Je unterschiedlicher die zu spiegelnden Server aussehen, desto wahrscheinlicher wird es, dass mehrere Replikationsprodukte benötigt werden, um alle Anforderungen der Betriebssysteme und Hardwarekonfigurationen zu erfüllen. In solchen Fällen müssen die Speicheradministratoren auf allen verwendeten Produkten geschult werden und zudem deren Kompatibilität sicherstellen.
Eher für Lowend geeignet
Folglich sind Server-basierende Lösungen schwer zu administrieren und nur begrenzt skalierbar. Darüber hinaus teilen sie sich die Rechenpower des Hosts mit der darauf laufenden Anwendung, was zu Leistungsengpässen führen kann. Dieser Ansatz eignet sich demzufolge nur für Lowend-Applikationen.
Anders sieht es bei der Replikation auf SAN-Basis aus: Sie schließt die Lücke zwischen Server-basierenden Lowend- und Array-basierenden Highend-Produkten. Derzeit sind sie nur über eigene Appliances zu realisieren. In Zukunft sollen sie in intelligenten Netzwerk-Switches integriert werden.
Bei der Replikation auf SAN-Basis können sowohl Speichersysteme als auch Server-Plattformen unterschiedlicher Hersteller zum Einsatz kommen. Damit unterstützt dieser Ansatz eine große Zahl möglicher Konfigurationen. Durch die Any-to-Any-Connectivity erhalten die Speicheradministratoren die Flexibilität, die sie brauchen, um umfangreiche Speichermodelle zu verwirklichen. So lassen sich damit zum Beispiel Geschäftsanwendungen herstellerunabhängig auf den jeweils kostengünstigsten Speicherlösungen abbilden.
Das SAN gewährt Freiheit
SAN-basierende Replikationslösungen stehen in zwei unterschiedlichen Ausprägungen zur Verfügung: In-Band (symmetrisch) und Out-of-Band (asymmetrisch). Bei In-Band-Produkten arbeitet die Hardware, auf der die Replikationslogik läuft, im Pfad der Ein- und Ausgabe der zu spiegelnden Anwendungsdaten. Das bedeutet: Initiiert ein Host eine Datenübertragung, laufen die Daten durch die Replikations-Appliance. Jeder Schreibvorgang generiert zwei Datenströme, einen zum primären Speicher-Volume und einen zum sekundären. Der Vorteil dieses Ansatzes liegt darin, dass das Produkt ohne zusätzliche Software auf dem Anwendungs-Server auskommt. Damit senkt man im Vergleich zu Out-of-Band-Produkten den Lizenz- und Verwaltungsaufwand.
Die Out-of-Band-Replikation verwendet eine kleine Softwarekomponente einen Agenten auf dem jeweiligen Applikations-Server. Dieser Agent kommu-niziert mit einem Metadaten-Server im Netz und erhält von ihm die Informationen zum Steuern der Replikation. Wenn die Replikationskonfiguration feststeht, veranlasst der Agent die Datenübertragungen an die primären und sekundären Speicher-Volumes. Die Agentensoftware beansprucht auf dem Anwendungs-Server Rechenleistung, Speicher und I/O-Ressourcen.
Manche Replikationslösungen beispielsweise die Produkte von IBM und Datacore verlangen, dass der Speicher vor dem Spiegeln virtualisiert wird. Dabei sind Implementierung und Konfiguration der Produkte auf Virtualisierungsbasis in der Regel ein aufwändiger und für das Tagesgeschäft hinderlicher Vorgang. Generell setzen sie voraus, dass alle Kopien der Daten also sowohl Quellen- als auch Zieldaten mit einem proprietären Header virtualisiert werden. Deshalb ist es schwierig, das Virtualisierungsprodukt später zu wechseln oder gar abzuschaffen. Meistens müssen die Verantwortlichen in so einem Fall die nervtötende und fehlerträchtige Aufgabe übernehmen, alle LUNs (Logical Unit Numbers) manuell zurückzusetzen.
An die Zukunft denken
Allerdings setzen nicht alle Lösungen Virtualisierungstechniken ein. Leistungsfähige Produkte, insbesondere solche, die die Daten auf physische LUNs replizieren, bieten den Speicheradministratoren einen einfachen Installationsprozess sowie die Möglichkeit, das Produkt später schnell und ohne große Änderungen an der Infrastruktur zu modifizieren. (kk)