SAP HANA Hochverfügbarkeit: System Replication und Cluster im Zusammenspiel
Zwei Parameter im Registrierungsbefehl entscheiden darüber, wie viel Datenverlust im Ernstfall möglich ist und wie lange die Umschaltung dauert. Der Cluster darüber automatisiert den Schwenk, ersetzt aber weder das Backup noch den Test.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Ein Cluster, der nie unter Last geschwenkt ist, ist eine Annahme
Hochverfügbarkeit wird gern als Zustand beschrieben, den man einkauft. Tatsächlich ist sie eine Kette aus Bausteinen, die einzeln unauffällig aussehen und gemeinsam entscheiden, was im Ernstfall passiert. Die Datenbank repliziert, ein Cluster überwacht, ein Fencing-Verfahren sorgt für eindeutige Verhältnisse, eine virtuelle IP-Adresse führt die Anwendungen zum richtigen Knoten, und die Clients müssen die abgebrochene Verbindung überhaupt bemerken. Fällt ein Glied aus, merkt ihr das nicht im Betrieb, sondern genau in dem Moment, in dem alles funktionieren müsste.
Der häufigste Irrtum betrifft dabei die Rolle des Backups. Die Replikation überträgt das Redo-Log kontinuierlich und spielt es auf der zweiten Seite ein. Genau deshalb ist eine versehentlich gelöschte Tabelle auf der zweiten Seite ebenfalls gelöscht, und zwar innerhalb von Sekunden. SAP bietet für diesen Fall mit Secondary Time Travel eine eigene Funktion an, die den sekundären Stand auf einen früheren Zeitpunkt zurückstellt, aber sie ist im Standard ausgeschaltet und muss vorher eingerichtet werden. Ohne diese Vorbereitung führt der Weg zurück über die Sicherung und die Protokollsicherungen, wie bei jeder anderen Datenbank auch.
Der zweite Irrtum betrifft den Schwenk selbst. Ein Takeover stoppt das alte Primärsystem nicht, das steht ausdrücklich in der SAP-Dokumentation. Wenn beide Knoten laufen und die Verbindung zwischen ihnen abreißt, hält sich jeder Knoten für das Primärsystem, und ohne ein Verfahren, das den anderen zuverlässig ausschaltet, schreiben zwei Systeme in denselben Datenbestand. SUSE formuliert das für seine Cluster unmissverständlich: Ohne gültige STONITH-Methode ist der gesamte Cluster nicht unterstützt und arbeitet nicht richtig.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Registrierungsbefehl, Stück für Stück
Alle Entscheidungen über Datenverlust und Umschaltzeit stecken in einer einzigen Zeile, die auf dem sekundären System läuft. Genau daran lässt sich zeigen, welcher Parameter welche Wirkung hat und was er voraussetzt.
Der Aufbau
hdbnsutil -sr_register --remoteHost=<primary-host> --remoteInstance=<nr> --replicationMode=syncmem --operationMode=logreplay --name=<site> - 01 Die Registrierung auf der zweiten Seite
-sr_registerDer Befehl läuft auf dem künftigen sekundären System und nur dann, wenn dieses System gestoppt ist. Zuvor wird das Primärsystem mit hdbnsutil -sr_enable als Quelle freigeschaltet. Ab diesem Moment baut jeder Serverprozess der zweiten Seite eine Verbindung zu seinem Gegenstück auf und fordert einen Abzug der Daten an.
- 02 Der Einstiegspunkt in das Primärsystem
--remoteHost=<primary-host>Anzugeben ist der Host des primären Namensservers, bei verteilten Systemen also nicht irgendein Knoten, sondern der mit dem führenden Namensserver. Die Verbindung zwischen den Standorten läuft ab SAP HANA 2.0 verschlüsselt, deshalb müssen die Schlüsseldateien des Systems vorher vom primären auf das sekundäre System kopiert worden sein.
- 03 Die Instanznummer der Quelle
--remoteInstance=<nr>Das sekundäre System muss dieselbe System-ID und dieselbe Instanznummer tragen wie das primäre. Für die Replikation wird zusätzlich die nächsthöhere Nummer belegt, weil die Kommunikation über einen festen Portversatz läuft. Wer die Instanznummern in der Landschaft dicht nebeneinander vergibt, stößt deshalb später auf Konflikte.
- 04 Wie viel Datenverlust ihr zulasst
--replicationMode=syncmemBei sync bestätigt das Primärsystem eine Transaktion erst, wenn das Log auf der zweiten Seite auf Platte liegt. Bei syncmem reicht der Empfang im Hauptspeicher, was die Verzögerung senkt und die Plattengeschwindigkeit der zweiten Seite herausnimmt, dafür aber Datenverlust ermöglicht, wenn beide Seiten gleichzeitig ausfallen. Bei async wartet das Primärsystem gar nicht. Für einen Cluster, der selbstständig schwenkt, unterstützt SUSE nur sync und syncmem.
- 05 Wie lange die Umschaltung dauert
--operationMode=logreplayMit logreplay wird das Redo-Log auf der zweiten Seite sofort nach Ankunft eingespielt, sodass beim Takeover nichts mehr nachzuziehen ist und die Umschaltung unmittelbar erfolgen kann. delta_datashipping schickt stattdessen in Abständen zusätzliche Datenpakete und verschiebt das Einspielen in den Ernstfall. logreplay_readaccess entspricht logreplay und erlaubt zusätzlich lesenden Zugriff auf das sekundäre System.
- 06 Der Standortname, auf den sich alles bezieht
--name=<site>Der Name kennzeichnet den Standort in der Replikationslandschaft und taucht in jeder Statusabfrage wieder auf. Sobald ein Cluster im Spiel ist, muss genau dieser Name auch bei jeder späteren Registrierung von Hand verwendet werden, sonst passen die Attribute im Cluster nicht mehr zur Wirklichkeit der Datenbank.
Wenn es nicht funktioniert
Das siehst du
Die Registrierung des sekundären Systems bricht ab oder das System startet danach nicht.
Warum
Eine der Voraussetzungen fehlt. Häufig weichen System-ID oder Instanznummer voneinander ab, der Parameter log_mode steht nicht auf normal, es fehlt die Datensicherung, die vor dem Einschalten der Replikation nötig ist, oder die Schlüsseldateien des Systems wurden nicht vom primären auf das sekundäre System kopiert.
Was hilft
Geh die Voraussetzungen in der Reihenfolge durch: gleiche SID und Instanznummer, log_mode auf normal im Bereich persistence der global.ini, eine erfolgreiche Datensicherung des Primärsystems, kopierte Schlüsseldateien, und ein sekundäres System, das für die Registrierung gestoppt ist.
Das siehst du
Nach dem Takeover läuft die Datenbank, aber die Anwendungen hängen weiter und kommen nicht zurück.
Warum
Zwei getrennte Gründe. Entweder fehlt die Umlenkung, also die virtuelle IP-Adresse wandert nicht mit oder der Namenseintrag zeigt weiter auf den alten Knoten. Oder die Clients halten an einer Verbindung fest, die es nicht mehr gibt, weil die Voreinstellung des Betriebssystems für TCP-Keepalive bei zwei Stunden liegt.
Was hilft
Leg fest, ob die Umlenkung über eine virtuelle IP-Adresse oder über den Namensdienst läuft, und mach sie zum festen Bestandteil des Schwenks. Passe zusätzlich die Keepalive-Einstellungen auf Client-Seite an, sonst wartet die Anwendung deutlich länger als die Datenbank braucht.
Das siehst du
Nach einem Netzwerkausfall halten sich beide Knoten für das Primärsystem.
Warum
Es fehlt ein wirksames Fencing. Der Takeover stoppt das frühere Primärsystem nicht, das ist ausdrücklich so dokumentiert. Ohne ein Verfahren, das den anderen Knoten sicher abschaltet, sind zwei schreibende Systeme möglich, sobald die Cluster-Kommunikation abreißt.
Was hilft
Richte eine unterstützte STONITH-Methode ein, für SUSE üblicherweise SBD, in Produktionsumgebungen mit mehr als einem Gerät oder als plattenloses SBD mit mindestens drei Knoten. Ohne gültige Methode ist der Cluster nicht unterstützt. In Cloud-Umgebungen gilt der Leitfaden des jeweiligen Anbieters dafür, welches Verfahren unterstützt ist.
Das siehst du
Die Replikation ist abgerissen, der Cluster schwenkt aber trotzdem auf ein nicht aktuelles sekundäres System.
Warum
Der HA/DR-Provider-Hook ist nicht eingerichtet. Ohne ihn erfährt der Cluster erst über seine regelmäßige Überwachung, dass die Replikation nicht mehr synchron ist, und das kann zu spät sein.
Was hilft
Trag den Hook für srConnectionChanged in die globale SAP-HANA-Konfiguration ein, im Hauptspeicher und dauerhaft in der Persistenz, und gib dem Betriebssystembenutzer der Instanz das Recht, crm_attribute auszuführen. Bei mehrstufiger oder mehrzieliger Replikation ist der Hook ohnehin Pflicht.
Das siehst du
Nach einer längeren Trennung wird beim Wiederanschluss eine vollständige Datenübertragung nötig.
Warum
Im Betriebsmodus logreplay hält das Primärsystem die noch nicht replizierten Log-Segmente zurück, aber nur bis zu einer einstellbaren Obergrenze. Ist sie erreicht, werden die Segmente wieder freigegeben und überschrieben, damit das Primärsystem nicht stehen bleibt.
Was hilft
Stimme die Obergrenze auf die realistische Dauer einer Trennung ab und überwache den Füllstand. Rechne bei längeren Wartungsarbeiten am sekundären System von vornherein mit einer vollständigen Übertragung und plane das Zeitfenster dafür ein.
Das siehst du
Ein fehlerhafter Löschlauf ist auf beiden Seiten wirksam, und der Cluster hat nichts gemeldet.
Warum
Genau so soll es sein. Die Replikation überträgt jede bestätigte Änderung, und ein logischer Fehler ist eine bestätigte Änderung. Hochverfügbarkeit schützt gegen Ausfall, nicht gegen falsche Inhalte.
Was hilft
Halte ein Wiederanlaufkonzept mit Datensicherung und Protokollsicherungen vor und übe die Wiederherstellung auf einen Zeitpunkt. Wer den Weg zurück beschleunigen will, kann auf dem sekundären System Secondary Time Travel einrichten, womit sich der Stand auf einen früheren Zeitpunkt öffnen lässt. Sie ist im Standard ausgeschaltet und braucht zusätzlichen Platz für Log und Daten.
Fünf Ebenen, die im Ernstfall zusammenspielen müssen
- 01 Die Datenbank repliziert das Redo-Log fortlaufend auf ein baugleiches zweites System.
- 02 Der Betriebsmodus entscheidet, ob das Log dort sofort eingespielt oder erst beim Schwenk nachgezogen wird.
- 03 Der Cluster erkennt den Ausfall und löst den Takeover aus, statt auf eine Person zu warten.
- 04 Das Fencing schaltet den ausgefallenen Knoten sicher ab, damit nicht zwei Systeme schreiben.
- 05 Eine virtuelle IP-Adresse oder ein Eintrag im Namensdienst führt die Anwendungen zum neuen Primärsystem.
- 06 Sicherung und Protokollsicherung decken alles ab, was die Replikation gehorsam mitkopiert.
Was du danach ohne Nachschlagen entscheidest
Die Einrichtung ist gut dokumentiert und in einem Tag gemacht. Die Entscheidungen, die den Unterschied machen, betreffen zwei Parameter, ein Fencing-Verfahren und die Frage, welche Ausfälle ihr überhaupt abdecken wollt.
Replikationsmodus bewusst wählen
Du weißt, warum sync, syncmem und async unterschiedlich viel Datenverlust zulassen, warum async die Antwortzeiten des Primärsystems schont und warum ein Cluster für den automatisierten Schwenk nur sync oder syncmem verträgt.
Betriebsmodus nach der gewünschten Umschaltzeit setzen
Du kannst begründen, warum logreplay das Redo-Log fortlaufend einspielt und den Takeover damit sofort möglich macht, während delta_datashipping die Nacharbeit in den Ernstfall verschiebt.
Voraussetzungen vorher prüfen
Du kennst die Bedingungen, an denen eine Registrierung sonst scheitert: gleiche SID und Instanznummer, log_mode auf normal, eine vorhandene Datensicherung und die kopierten Schlüsseldateien für die verschlüsselte Verbindung.
Den Cluster als eigene Ebene verstehen
Du weißt, welche Aufgabe die Ressourcenagenten und die HA/DR-Provider-Hooks übernehmen, warum der Cluster ohne Fencing keine Zusage geben kann und warum manuelle Eingriffe an der Datenbank in dieser Konstruktion verboten sind.
Den Weg der Clients mitplanen
Du entscheidest zwischen Umlenkung über eine virtuelle IP-Adresse und Umlenkung über den Namensdienst und weißt, warum ein Client ohne angepasste Keepalive-Einstellung nach einem Takeover sehr lange auf eine Antwort wartet.
Die Lücke zum Wiederanlaufkonzept benennen
Du kannst sagen, welche Ausfälle die Replikation abdeckt und welche nicht, und leitest daraus ab, welche Sicherungen, welche Aufbewahrung und welche Wiederherstellungstests ihr trotzdem braucht.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was System Replication zusagt und was sie voraussetzt
SAP beschreibt System Replication als den empfohlenen Aufbau, um Ausfallzeiten von SAP HANA zu verringern, und zwar für geplante Wartung, für Störungen und für Katastrophenfälle gleichermaßen. Die Zusage ist konkret: ein Wiederherstellungspunkt von null Sekunden und eine Wiederanlaufzeit im Minutenbereich. Dafür steht ein sekundäres System bereit, das als exakte Kopie des aktiven Systems eingerichtet ist, mit derselben Anzahl aktiver Hosts. Jeder Dienst des primären Systems spricht paarweise mit seinem Gegenstück, und das sekundäre System nimmt im Normalbetrieb keine Anfragen an.
Die Voraussetzungen sind übersichtlich, aber unnachgiebig. Das sekundäre System braucht dieselbe System-ID und dieselbe Instanznummer. Der Parameter log_mode muss im Bereich persistence der global.ini auf normal stehen, denn nur dann werden die Log-Segmente automatisch gesichert und die Datenbank lässt sich auf den letztmöglichen Zeitpunkt zurückholen. Vor dem Einschalten der Replikation braucht es eine Datensicherung des Primärsystems. Die Konfigurationsdateien beider Seiten sollen gleich aussehen, weshalb ein eingebauter Vergleich Abweichungen meldet. Und ab SAP HANA 2.0 läuft die Verbindung verschlüsselt, wofür die Schlüsseldateien des Systems vor der Registrierung auf die zweite Seite kopiert werden.
Ein Detail, das bei Wartungsarbeiten regelmäßig auffällt: Beim Aktualisieren der Landschaft muss die Softwareversion des aktuellen sekundären Systems gleich oder neuer sein als die des primären. Wer das umdreht, steht bei einem späteren Rücktausch der Rollen mit einem Primärsystem da, das neuer ist als sein Ziel. Und die Lizenz zieht mit: Weil beide Seiten dieselbe System-ID tragen, repliziert das Primärsystem die relevanten Lizenzinformationen, sodass für das sekundäre System keine zusätzliche Lizenz installiert werden muss.
Replikationsmodus und Betriebsmodus: zwei Stellschrauben, zwei Wirkungen
Der Replikationsmodus entscheidet, wie viel Datenverlust im Ernstfall möglich ist. Bei sync wartet das Primärsystem mit der Bestätigung einer Transaktion, bis das Log auf der zweiten Seite dauerhaft geschrieben ist. Das garantiert sofortige Übereinstimmung, kostet aber die Zeit für Übertragung und Schreibvorgang. Bei syncmem genügt es, dass das Log auf der zweiten Seite im Hauptspeicher angekommen ist, wodurch die Plattengeschwindigkeit dort keine Rolle mehr spielt, dafür ist der Aufbau anfälliger für Datenverlust, wenn beide Seiten gleichzeitig ausfallen. Bei async schickt das Primärsystem das Log und bestätigt sofort, was die beste Antwortzeit ergibt und Datenverlust beim Schwenk ausdrücklich einschließt.
In allen drei Modi gilt: Reißt die Verbindung ab, arbeitet das Primärsystem nach einer kurzen, einstellbaren Wartezeit weiter und schreibt nur noch lokal. Wer das nicht will, kann für sync die Vollsynchronisation einschalten. Dann setzt das Primärsystem die Verarbeitung aus, bis die Verbindung wieder steht, und Datenverlust ist ausgeschlossen. Das ist genau die Einstellung, die bei einer Netzstörung dazu führt, dass auf der produktiven Seite nichts mehr geschrieben werden kann, und deshalb eine bewusste Entscheidung und keine Voreinstellung.
Der Betriebsmodus entscheidet unabhängig davon über die Umschaltzeit. Bei logreplay wird das Redo-Log auf der zweiten Seite fortlaufend eingespielt, sodass beim Takeover nichts mehr nachzuholen ist und außerdem weniger Daten über die Leitung gehen, weil die zusätzlichen Datenpakete entfallen. Bei delta_datashipping werden die Log-Einträge zwar entgegengenommen, aber erst beim Takeover eingespielt, weshalb in Abständen zusätzlich Datenpakete geschickt werden, um die Nacharbeit zu verkürzen. logreplay_readaccess arbeitet wie logreplay und öffnet das sekundäre System zusätzlich für lesende Zugriffe, was eine eigene Lizenzfrage aufwirft und im Cluster eine zweite virtuelle IP-Adresse für die lesende Seite verlangt.
Was der Linux-Cluster hinzufügt
System Replication hält die Daten aktuell, schwenkt aber nicht von selbst. Der Takeover ist ein Kommando, das jemand oder etwas auslösen muss. Diese Rolle übernimmt ein Cluster auf Betriebssystemebene. Bei SUSE Linux Enterprise Server for SAP Applications geschieht das mit zwei Ressourcenagenten: Einer prüft und steuert die Datenbankinstanzen und entscheidet, welche Seite die primäre Rolle hat, der andere läuft auf allen Knoten und sammelt Zustand und Konfiguration der Replikation ein. Für neue Installationen empfiehlt SUSE inzwischen das Paket SAPHanaSR-angi, das ältere Paket wird für bestehende Cluster weiter unterstützt.
Damit der Cluster rechtzeitig erfährt, was in der Datenbank passiert, kommen HA/DR-Provider-Hooks dazu. Ein Hook meldet, wenn die Replikationsverbindung ihren Zustand ändert, ein weiterer wird vor einem Takeover aufgerufen, ein dritter meldet den Ausfall einzelner Dienste. Ohne diese Rückmeldungen erfährt der Cluster von einer abgerissenen Replikation erst über seine regelmäßige Überwachung, und in dieser Zeitspanne sind Entscheidungen möglich, die auf veralteten Annahmen beruhen. Für mehrstufige und mehrzielige Aufbauten ist der Hook für die Replikationsverbindung ohnehin Pflicht.
Zwei Randbedingungen entscheiden über den Erfolg. Erstens das Fencing: Der Cluster braucht eine gültige STONITH-Methode, sonst ist er nach SUSE-Aussage insgesamt nicht unterstützt und arbeitet nicht richtig. Üblich ist SBD, in Produktionsumgebungen mit mehr als einem Gerät, alternativ plattenlos mit mindestens drei Knoten. Zweitens die Disziplin im Betrieb: An einer Datenbank, die der Cluster steuert, dürfen keine manuellen Aktionen mehr vorgenommen werden. Wer die Instanz von Hand stoppt, um kurz etwas zu prüfen, löst genau die Reaktion aus, für die der Cluster gebaut wurde. Und zum Cluster gehört die virtuelle IP-Adresse, die beim Schwenk mitwandert, denn ohne sie findet keine Anwendung die neue primäre Seite.
Was weder Replikation noch Cluster abfangen
Abgedeckt sind Ausfälle von Knoten, Speicher und Standort, planbare Wartung mit sehr kurzer Umschaltzeit und, je nach Aufbau, der Verlust eines ganzen Rechenzentrums. Nicht abgedeckt ist alles, was als gültige Transaktion in die Datenbank läuft. Ein fehlerhafter Massenlauf, ein Transport mit falschem Customizing, eine versehentlich geleerte Tabelle: Jede dieser Änderungen wird ordnungsgemäß repliziert und ist Sekunden später auf beiden Seiten wirksam. Dass SAP für genau diesen Fall mit Secondary Time Travel eine eigene Funktion auf dem sekundären System anbietet, ist das deutlichste Eingeständnis, dass Replikation und Sicherung zwei verschiedene Dinge sind.
Secondary Time Travel ist ein nützliches, aber schmales Werkzeug. Es stellt das sekundäre System oder den Wiedereinspielvorgang auf einen früheren Zeitpunkt zurück und ist damit ein zeitlich begrenzter Takeover in die Vergangenheit. Voraussetzung ist einer der logreplay-Betriebsmodi, und im Standard ist sie ausgeschaltet, weil die maximale Rückhaltezeit auf null steht. Wer sie einschalten will, muss zusätzlichen Platz für Log und Datenbestand auf der zweiten Seite einplanen, denn beides wächst dort, solange die Funktion aktiv ist.
Der ehrliche Schluss daraus ist unspektakulär: Ihr braucht weiterhin ein Wiederanlaufkonzept mit Datensicherung, mit Protokollsicherungen und mit Aufbewahrungsfristen, die zu euren fachlichen Anforderungen passen. Und ihr braucht Wiederherstellungstests, die nicht nur prüfen, ob die Sicherung existiert, sondern ob die Wiederherstellung auf einen bestimmten Zeitpunkt in der zugesagten Zeit gelingt. Ein Schwenktest unter Last gehört in dieselbe Kategorie: Er ist die einzige Aussage über den Cluster, die im Ernstfall trägt.
Betriebsformen: wer baut, wer schwenkt, wer testet
Im Eigenbetrieb liegt die ganze Kette bei euch, und dazu gehört die Auswahl der unterstützten Kombination aus Datenbankstand, Betriebssystem und Cluster-Paketen. Die konkreten Bausteine unterscheiden sich je nach Linux-Distribution: Ressourcenagenten, Hooks und Fencing-Verfahren sind bei SUSE anders benannt und anders zu konfigurieren als bei anderen Anbietern, und maßgeblich ist immer der Leitfaden des Anbieters, dessen Unterstützung ihr in Anspruch nehmen wollt. Welche Maschinen und Speicherklassen auf einer bestimmten Cloud-Plattform für SAP zugelassen sind, ist eine eigene Frage und gehört in die Planung der Zielarchitektur, nicht in die Cluster-Konfiguration.
In der SAP S/4HANA Cloud Private Edition, also im RISE-Vertrag, ist die Aufteilung fein und lohnt einen Blick in das Dokument Roles and Responsibilities. Die Verwaltung von Standby-Datenbanken über SAP HANA System Replication ist dort Standardleistung, allerdings nur für produktive Systeme und nur dann, wenn eigens dafür vorgesehene Standby-Datenbanken ausdrücklich Teil des vereinbarten Aufbaus sind. Im selben Eintrag steht der wichtige Zusatz, dass Schwenktests nicht regelmäßig je System durchgeführt werden. Der Aufbau eines Pacemaker-Clusters ist eine Zusatzleistung, die im Einzelfall von Architekten geprüft und freigegeben wird und für die ein Änderungsantrag nötig ist, wenn daran ein Servicegrad hängen soll.
Ähnlich sieht es bei den Sicherungen aus. Regelmäßige vollständige Sicherungen und Protokollsicherungen sind Standardleistung nach der vereinbarten Sicherungsrichtlinie, ebenso die Überwachung der Sicherungsläufe und die Wiederherstellung nach einem Systemausfall. Die regelmäßige Prüfung der Wiederherstellungsverfahren führt der Anbieter allerdings für repräsentative Szenarien durch und nicht für jedes einzelne System, und sie lässt sich von Kundenseite auch nicht beauftragen. Wer für ein bestimmtes System eine belastbare Aussage über die Wiederanlaufzeit braucht, muss diesen Test also selbst verabreden. In der Public Edition stellt sich die Frage nicht: Dort betreibt SAP die Datenbank, und Hochverfügbarkeit ist Teil des Dienstes und keine Konfiguration, die ihr verantwortet.
Dazu passende Kurse
Weil die Datenbankseite und die Anwendungsseite im Ernstfall zusammen gedacht werden müssen, gibt es bei cmt SAP-Kurse zum Betrieb der HANA-Datenbank .
Der automatische Schwenk entsteht auf Betriebssystemebene, deshalb gehören SUSE-Kurse für Cluster und Systemreplikation in dieselbe Planung.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Häufige Fragen
Ersetzt System Replication das Backup?
sync oder syncmem, was nehmen wir?
Braucht der Cluster wirklich ein Fencing-Gerät?
Warum hängen unsere Anwendungen nach einem Takeover so lange?
Können wir das sekundäre System zum Lesen nutzen?
Wer kümmert sich unter RISE with SAP um die Hochverfügbarkeit?
Passt thematisch dazu
Weil ein logischer Fehler sauber mitrepliziert wird, hängt die Rettung nicht am Cluster, sondern an der Sicherung, und die belastbare Zahl dafür liefert nur der gemessene Test einer echten Wiederherstellung .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem SAP-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Einmal schwenken, bevor es der Ernstfall tut
Wie Replikation, Cluster, Fencing und Umlenkung zusammenspielen und woran ein Schwenk in der Praxis scheitert, gehst du bei cmt an einem aufgebauten Cluster durch und nicht an einem Schaubild.