Clustering sorgt für konsistente Daten

Feature | 24. Januar 2007 von admin 0

Der Zusammenbruch eines Servers, ein Systemabsturz oder der Verlust geschäftskritischer Daten – das sind Horrorszenarien für jedes Unternehmen. Meist kann das Geschäft nur fortgeführt werden, wenn sowohl der Datenbestand als auch die Applikationen, die die Daten bearbeiten, hochverfügbar sind. Ganz gleich ob geplant oder nicht – Ausfallzeiten in der IT-Umgebung sind ein realer und messbarer Schaden für Unternehmen. Im SAP-Umfeld besteht eine Applikation aus einer großen Anzahl von Diensten wie Messaging-, Enqueue- und NFS- (Network File System) oder CIFS-Service (Common Internet File System). Sie sind über mehrere Server verteilt. Dabei stellt jeder Dienst eine potenzielle Schwachstelle dar, die auf Anwendungsebene durch Einbau von Redundanzen geschützt werden muss. Diese Redundanzen erhöhen jedoch die Komplexität der Umgebung und erschweren ihre Verwaltung. Da SAP-Anwendungen häufig für wichtige Geschäftsprozesse verwendet werden, kann gerade bei ihrem Einsatz eine Unterbrechung zum Teil hohe Verluste zur Folge haben. Ihre permanente Verfügbarkeit, Verwaltung und Wiederherstellbarkeit sind daher essentiell für einen kontinuierlichen Geschäftsbetrieb.
Technologien wie die synchrone oder asynchrone Replikation der SAP-Umgebung beziehungsweise lokales oder globales Clustering – ein Modell aus mehreren einzelnen Serversystemen – beugen Gefahren wie Ausfallzeiten und Datenverlust vor. Sie ermöglichen es, SAP-Applikationen schnell zwischen Rechenzentren an verschiedenen Standorten hin- und herzuschalten. Business-Continuity-Pläne ergänzen die technischen Schutzmaßnahmen für die SAP-Umgebung um organisatorische Aspekte wie Kommunikations- und Eskalationswege in bestimmten Notfallszenarien. Hier beginnt das Sicherstellen von Business Continuity auf lokaler Ebene gleichermaßen wie für Nicht-SAP-Umgebungen bekannt.

Synchrone und asynchrone Replikation

Bei einer Replikation werden Daten der lokalen Platte parallel auch auf eine oder mehrere andere Platten geschrieben. Dabei können die lokale und die entfernte Platte über verschiedene Netze mit unterschiedlichen Kommunikationsprotokollen, etwa IP-Kapselung über ATM, Frame Relay oder X.25, und Geschwindigkeiten angesprochen werden.
Bei der synchronen Datenreplikation erhalten gleichzeitig die Platten des Primärserver als auch sämtliche entfernten Platten blockweise alle Änderungen. Dieser Vorgang ist abgeschlossen, wenn alle Plattensysteme eine positive Rückmeldung gesendet haben. Erst dann wird der nächste Block geschrieben. Abhängig von Entfernung, Geschwindigkeit sowie Anzahl und Größe der zu übertragenden Blöcke kann es bei diesem Vorgang zu kleinen Verzögerungen kommen. Der Vorteil der synchronen Übertragung ist jedoch, dass ein identischer Datenbestand entsteht, der einen Datenverlust, etwa beim Zusammenbruch eines Servers, verhindert. Die synchrone Datenreplikation empfiehlt sich daher besonders für überschaubare Entfernungen und Applikationen, bei denen es nicht auf die Geschwindigkeit, sondern auf die Vollständigkeit aller Daten ankommt.
Für die Planung einer weltweiten Ausfallsicherung verwenden Unternehmen oft die asynchrone Replikation. Mit ihr werden Replikationsvorgänge nach Netzwerkverfügbarkeit vorgenommen. Das sichert zwar eine hohe Leistung, bietet aber keinen umfassenden Schutz vor Datenverlust. Zunächst sammelt die Replikationssoftware die Schreibbefehle für die entfernte Platte auf lokaler Seite in einer so genannten Replikations-Logdatei. Ist das Schreiben in dieser Datei erfolgreich abgeschlossen, wird das an die Applikation gemeldet, und die Software sendet die Daten an den oder die jeweiligen Zweitserver. Ein Unternehmen muss dabei zwischen dem Vorteil der hohen Geschwindigkeit und dem Risiko möglicher Verluste abwägen. Im Fall einer Rekonstruktion kann es sein, dass Daten fehlen, weil bei der Übertragung noch nicht alle Daten die zweite Platte erreicht hatten. Auch sind bei der asynchronen Variante Übertragungssteuerung, Überwachung der Bandbreite und Fehlerhandling sehr aufwändig. Doch für Replikationen über große Entfernungen ist sie häufig die einzige Alternative.

Nur wenige Hersteller am Markt bieten heute eine erweiterte asynchrone Replikation an, bei der auf der replizierten Seite die Schreibreihenfolge der Blöcke eingehalten wird. Die richtige Reihenfolge jedoch sichert die Integrität und Konsistenz der Daten und garantiert, dass sich diese am zweiten Standort wiederherstellen lassen. Die Daten müssen die Sicherungsplatte stets in exakt der Reihenfolge erreichen, in der sie geschrieben wurden (“Write Order Fidelity”). Inkonsistente oder fehlerhafte Daten auf einer der Zweitplatten würden im Ernstfall den Gesamteffekt zunichte machen. Replikationslösungen auf Hardwareebene fehlt häufig die Fähigkeit, die Write Order Fidelity zu gewährleisten, wenn sie im asynchronen Modus laufen, denn die Änderungen werden nicht durchgängig und kontinuierlich übertragen. Die richtige Reihenfolge muss hier durch entsprechende Maßnahmen sichergestellt werden, damit die gespiegelten Daten nicht sinnlos werden.
Je nach Konfiguration besteht die Möglichkeit, zwischen synchroner und asynchroner Replikation zu wechseln. Erkennt die Replikationssoftware, dass die Übertragungsgüte für eine synchrone Replikation nicht mehr gewährleistet ist und die “Leitung” zu langsam für die aktuellen Anforderungen wird, schaltet sie automatisch in den asychronen Modus. Ist die notwendige Übertragungsgüte wieder erreicht, schaltet die Software zurück in das synchrone Übertragungsverfahren.

Lokales und globales Clustering

Automatisierte, applikationsspezifische Überwachung und Ausfallsicherung verbessern die Verfügbarkeit der Prozesse. Lokales Clustering und die Virtualisierung geschäftskritischer Dienste, die durch Entkoppelung der für die SAP-Anwendung notwendigen Komponenten, etwa Platten, Filesysteme, IP-Adressen oder NFS-Freigaben, von dedizierten Rechner erfolgt, helfen dem Unternehmen, Server zu konsolidieren, bestehende Ressourcen besser zu nutzen und sich vor potenziellen Ausfällen zu schützen. Bricht beispielsweise ein Server zusammen, so gewährleistet eine Cluster-Lösung, dass ein anderer Server einspringt, und alle Prozesse weiterlaufen. Die replizierten Daten verarbeitet der Reserveserver beim Ausfall des Primärservers mit minimalem Zeitverlust sofort weiter.
Die leistungsfähigste Cluster-Variante ist das globale Clustering, auch WAN Clustering genannt. Hierbei werden Cluster verschiedener Standorte und SAP-Applikationen miteinander verbunden. Moderne Clustering-Lösungen überwachen die jeweiligen SAP-Applikationen und die bestehenden Abhängigkeiten zwischen ihnen. Auf diese Weise wird sichergestellt, dass bei einem Ausfall die betroffenen Dienste einer Applikation oder gesamte Applikationen in der korrekten Reihenfolge auf anderen Systemen im selben Cluster oder, falls ein gesamter Cluster ausfällt, auf einem anderen gestartet werden. Ist die Applikation dann online, werden die Clients automatisch auf die gestartete Anwendung im anderen Server umgeleitet. Das sorgt nicht nur für die Verfügbarkeit von SAP-Systemen bei einem Ausfall, sondern verbessert auch die Verwaltung, da sich die gesamte Applikation zentral steuern lässt. Werden Replikation und WAN-Cluster gekoppelt, kann sogar beim Totalausfall eines kompletten Rechenzentrums ein anderes im Ausland einspringen. Nachdem die Cluster-Software ein Update der DNS-Server vorgenommen hat, leiten diese die Zugriffe der Anwender automatisch auf den neuen Standort um.

Kontinuität richtig planen

Application Performance Management mit SAP-Zertifikat

Application Performance Management mit SAP-Zertifikat

Technische Lösungen wie Clustering und Replikation unterstützen die Automatisierung kritischer Prozesse, senken administrative Kosten und steigern gleichzeitig die Effizienz und helfen beim Vermeiden potenzieller Fehler. Sie werden im Idealfall durch einen Business-Continuity-Plan ergänzt, der Best Practices für den Umgang mit Risikofaktoren, die Implementierung einer Disaster-Recovery-Strategie und die Einschätzung von Technologien und Maßnahmen für den Schutz geschäftskritischer Dienste beinhaltet. Ein solcher Plan liefert Vorgaben für die strukturierte Herangehensweise an Architektur, Prozesse und Verfahren zur Identifizierung und Einhaltung von Wiederherstellungszeiten und -zielen. Damit Strategie und Plan möglichst umfassend und effektiv entwickelt werden können, haben Unternehmen die Möglichkeit, sich von darauf geschulten Beratern unterstützen zu lassen. Diese setzen Benchmarks, identifizieren Schwachstellen und schlagen Lösungen vor. Auf diese Weise werden die Anforderungen von Rechnungsprüfern, Aktionären und Geschäftsführung an die fortwährende Systemverfügbarkeit möglichst gut erfüllt.
Für den Schutz vor Systemausfällen kann ein alternativer Standort für die Gewährleistung der Redundanz und Disaster Recovery sinnvoll sein. Dennoch schrecken viele Unternehmen vor den Kosten zurück. Übliche Wiederherstellungslösungen für SAP setzen meist voraus, dass identische, teure Hardware an jedem Standort vorhanden ist. Eine Applikation auf einen Ausweichstandort umzuleiten, erfordert es, Sicherungsbänder und Personal dorthin zu verlegen, Server aufzubauen, Betriebssysteme zu laden sowie aktuelle Backups der Software zu erstellen. Wird der Betrieb am Ausweichstandort aufgenommen, müssen komplizierte und potenziell fehleranfällige Prozesse gestartet werden, um die voneinander abhängigen SAP-Komponenten wieder zum Laufen zu bringen.
Einsparungen im Storage-Bereich lassen sich erzielen, wenn die sekundäre Platte nicht unbedingt der primären entsprechen muss. Unternehmen sparen häufig deutlich, wenn sie ihren Ausweichstandort überwiegend für andere, weniger wichtige Geschäftsprozesse nutzen. Diese werden dann abgeschaltet oder reduziert, wenn bei einem Ausfall des Hauptrechenzentrums die komplette Infrastruktur für die Sicherung der wirklich kritischen Systeme benötigt wird. Preisvergleiche zwischen verschiedenen Hard- und Softwareanbietern lohnen sich, wenn ein Unternehmen nicht an eine Umgebung gebunden ist, und senken die Total Cost of Ownership für eine SAP-Umgebung oftmals deutlich.

Manuel  Braun

Manuel Braun

Leave a Reply