SAP-HANA-Systemreplikation einrichten

Ab SAP HANA 2.0 sind zusätzliche Konfigurationsschritte erforderlich, um die SAP-HANA-Systemreplikation einzurichten, da Replikationsverbindungen nun die zertifikatsbasierte Authentifizierung verwenden.

Die Systemreplikation mit SAP HANA 2.0 erfordert eine Authentifizierung für die Daten- und Protokollversandkanäle. Die Authentifizierung erfolgt über die Zertifikate im System PKI SSFS Store. Ein zusätzlicher manueller Einrichtungsschritt ist erforderlich, um Zertifikate im System-PKI-SSFS-Speicher zwischen Primär- und Sekundär-Sites auszutauschen. Weitere Informationen finden Sie im SAP-Hinweis 2369981.

Weitere Informationen finden Sie im SAP-Hinweis 2369981 - Erforderliche Konfigurationsschritte für die Authentifizierung mit SAP-HANA-Systemreplikation.

Die kopierten Dateien werden beim Systemneustart aktiv. Daher wird empfohlen, die Dateien zu kopieren, wenn das sekundäre SAP-HANA-System offline ist, z.B. vor der Registrierung.

Es gibt zwei Möglichkeiten, die SAP-HANA-Systemreplikation im SAP HANA Cockpit einzurichten:

• Aktivieren Sie das Primärsystem, und registrieren Sie dann das Sekundärsystem aus dem Primärsystem in einem Konfigurationsschritt.

• Aktivieren Sie die Systemreplikation im Primärsystem, und registrieren Sie dann das Sekundärsystem in einem zweiten Schritt.

Die Schritte zum Konfigurieren des Primär- und Sekundärsystems mit dem SAP HANA Cockpit sind in der Abbildung „Systemreplikation aktivieren" dargestellt.

Sie haben die Systemreplikation aktiviert und das Sekundärsystem beim Primärsystem registriert. Das Sekundärsystem arbeitet im Wiederherstellungsmodus. Alle sekundären Systemservices kommunizieren ständig mit ihren primären Gegenstücken, replizieren und persistieren Daten und Protokolle und laden Daten in den Speicher. Das Sekundärsystem akzeptiert jedoch keine SQL-Verbindungen.

Um die SAP-HANA-Systemreplikation zwischen zwei identischen SAP-HANA-Systemen einzurichten, müssen Sie zuerst die Systemreplikation im Primärsystem aktivieren und dann das Sekundärsystem registrieren.

Es ist auch möglich, die SAP-HANA-Systemreplikation mit dem Befehlszeilenwerkzeug hdbnsutil als <sid>adm auf Betriebssystemebene zu konfigurieren. Das Befehlszeilentool kann Teil eines Skripts sein, das weitere Schritte über die Systemreplikation hinaus ausführt.

1. Legen Sie eine Datensicherung des Primärsystems an.

2. Aktivieren Sie das Primärsystem, und geben Sie dem Primärsystem einen logischen Namen:

   hdbnsutil -sr_enable --name=PRIMARY

3. Stoppen Sie das Sekundärsystem:

   sapcontrol –nr <instance_number> -function StopSystem HDB

4. Registrieren Sie das Sekundärsystem (wählen Sie Replikations- und Betriebsart):

   Code Snippet

   Copy codeSwitch to dark mode

   12345
   hdbnsutil -sr_register --remoteHost=<primary hostname> 
   --remoteInstance=<instance number> 
   --replicationMode=<sync|syncmem|async> 
   --operationMode=<delta_datashipping|logreplay> 
   --name=SECONDARY

5. Starten Sie das Sekundärsystem, um die Replikation zu starten:

   sapcontrol –nr <instance_number> -function StartSystem HDB

Sobald das Sekundärsystem gestartet wurde, wird der Replikationsprozess automatisch gestartet.

Wenn diese Option aktiviert ist, stellt die Option für die vollständige Synchronisierung für die SAP-HANA-Systemreplikation sicher, dass ein Protokollpuffer an das Sekundärsystem gesendet wird, bevor ein Commit auf dem lokalen Primärsystem erfolgt.

Die Option für die vollständige Synchronisierung kann für die SYNC-Replikation aktiviert werden (d.h. nicht für SYNCMEM). Wenn die Option für die vollständige Synchronisierung aktiviert ist, findet die Transaktionsverarbeitung in den Primärblöcken statt. Wenn das Sekundärsystem derzeit nicht verbunden ist, können die neu angelegten Protokollpuffer nicht an das Sekundärsystem gesendet werden. Dieses Verhalten stellt sicher, dass keine Transaktion lokal festgeschrieben werden kann, ohne dass die Protokollpuffer an die Sekundärsite gesendet werden. Die Option für die vollständige Synchronisierung kann mit dem folgenden Befehl ein- und ausgeschaltet werden: hdbnsutil -sr_fullsync --enable|--disable

Dieser Befehl ändert die Einstellung des Parameters enable_full_sync im Systemreplikationsabschnitt der Datei global.ini entsprechend. In einem laufenden System wird die vollständige Synchronisierung jedoch nicht sofort aktiv. Dadurch wird verhindert, dass das System Transaktionen sofort sperrt, wenn der Parameter auf true gesetzt wird. Stattdessen muss die vollständige Synchronisierung zuerst vom Administrator aktiviert werden. In einem zweiten Schritt wird sie intern aktiviert, wenn das Sekundärsystem verbunden ist, und wird AKTIV.

In der Systemsicht M_SERVICE_REPLICATION kann die Einstellung der Option für die vollständige Synchronisierung in mithilfe von SQL angezeigt werden.

Die Option für die vollständige Synchronisierung kann folgende Werte haben:

• DISABLED: Vollständige Synchronisierung ist überhaupt nicht konfiguriert. Der Parameter ist enable_full_sync = false im Systemreplikationsabschnitt der Datei global.ini.

• AKTIVIERT: Vollständige Synchronisierung ist konfiguriert, aber noch nicht aktiv, daher blockieren Transaktionen in diesem Zustand nicht. Um aktiv zu werden, muss sich das Sekundärsystem verbinden, und REPLICATION_STATUS muss AKTIV sein.

• AKTIV: Vollständiger Synchronisationsmodus ist konfiguriert und aktiv. Wenn die Netzwerkverbindung zu einem verbundenen Sekundärsystem geschlossen ist, blockieren Transaktionen auf der Primärseite in diesem Zustand.

Wenn die vollständige Synchronisierung aktiviert ist, wenn derzeit ein aktives Sekundärsystem verbunden ist, wird FULL_SYNC sofort auf ACTIVE gesetzt.

Die SAP-HANA-Systemreplikation unterstützt eine Reihe von Komprimierungsmethoden für Protokoll- und Datenversand.

Folgende Komprimierungsarten für Protokoll- und Datenversand werden unterstützt:

Log

Protokollpuffer-Tail-Komprimierung (standardmäßig)

Komprimierung des Protokollpufferinhalts

Daten

Datenseitenkomprimierung

Die Protokollpuffer-Tail-Komprimierung ist standardmäßig aktiviert. Alle Protokollpuffer werden durch einen Fülleintrag an 4 KB-Grenzen ausgerichtet. Bei der Protokollpuffer-Tail-Komprimierung wird der Füllereintrag vor dem Senden über das Netzwerk vom Puffer abgeschnitten und wieder hinzugefügt, wenn der Puffer das Sekundärsystem erreicht hat. Daher wird nur die Nettopuffergröße an das Sekundärsystem übertragen.

Die Größe des Fülleintrags ist kleiner als 4 KB. Dies ist die maximale Größenreduzierung pro gesendetem Protokollpuffer. Wenn die Größe der Protokollpuffer recht groß ist, ist das Komprimierungsverhältnis recht begrenzt.

Die Komprimierung des Protokollpuffers und des Seiteninhalts kann über Parametereinstellungen aktiviert werden.

Protokollpuffer und Datenseiten, die an das Sekundärsystem geliefert werden, können mit einem verlustfreien Komprimierungsalgorithmus (LZ4) komprimiert werden. Standardmäßig ist die Inhaltskomprimierung deaktiviert. Sie können sie aktivieren, indem Sie die folgenden Konfigurationsparameter auf der Sekundärsite im Abschnitt system_replication der Datei global.ini festlegen.

Die Protokoll- und Datenkomprimierung ist besonders nützlich, wenn die Systemreplikation über weite Entfernungen verwendet wird, z.B. mit dem ASYNC-Replikationsmodus.

Der Open-Source-Komprimierungsalgorithmus LZ4 wurde aufgrund seiner Geschwindigkeits- und Komprimierungsverhältnisse und des relativ geringen Zeitaufwands für die Komprimierung/Dekompression ausgewählt. Die Komprimierung des Protokollpufferinhalts funktioniert auch in Kombination mit der Protokollpuffer-Tail-Komprimierung. Daher wird nur der Inhaltsteil des Protokollpuffers komprimiert, ohne den Füllereintrag zu berücksichtigen.

Durch die Aktivierung der Komprimierung wird die erforderliche Netzwerkbandbreite reduziert, aber gleichzeitig entsteht ein CPU-Overhead für das Komprimieren und Dekomprimieren der Informationen. Die Verwendung der Komprimierung ist insbesondere bei langen Entfernungen zwischen Primär- und Sekundärstandort oder bei Bandbreitenbeschränkungen sinnvoll.

Um die SAP-HANA-Systemreplikation zu überwachen, können Sie die Kachel Systemreplikation im SAP HANA Cockpit verwenden.

Wenn die Systemreplikation konfiguriert ist, enthält die Kachel Systemreplikation Informationen über den Typ der Landschaft (zwei- oder dreistufig), den Replikationsmodus zwischen dem Primärsystem und dem Sekundärsystem der Stufe 2, den Betriebsmodus und den Gesamtreplikationsstatus.

Die Kachel Systemreplikation zeigt die folgenden Status auf einen Blick an:

• Nicht konfiguriert (d.h. Systemreplikation ist nicht konfiguriert)

• Alle Services sind aktiv und synchron

• Alle Services sind aktiv, aber noch nicht synchron

• Fehler bei der Replikation

Um den Status der Replikation im Detail zu prüfen, wählen Sie die Kachel Systemreplikation. Das Übersichtsbild Systemreplikation zeigt eine grafische Darstellung der Systemlandschaft, Konfiguration und des Status der Systemreplikation an. Oben wird die „Kette" von Systemen mit ihren Replikationsmodi angezeigt, die weitere Informationen über die Standorte und die Netzwerkverbindungen zwischen ihnen enthält.

Das Bild Systemreplikation enthält folgende Informationen:

• Name und Rolle des Systems sowie die ausgewählte Betriebsart.

  Für die Betriebsarten logreplay und logreplay_readaccesswird zusätzlich eine Schätzung der Verweildauer angezeigt. Dies ist eine Schätzung der verbleibenden Zeit, bevor das Primärsystem beginnt, die mit RetainedFree markierten Protokollsegmente zu überschreiben, und es ist eine vollständige Datenlieferung erforderlich, um die Primär- und Sekundärsysteme nach einer Unterbrechungssituation wieder synchron zu halten. Die geschätzte Protokoll-Vollzeit ist eine Schätzung der verbleibenden Zeit, bevor das Primärsystem ein Protokoll voll wird. Der im Kopf angezeigte Wert zeigt die Situation an, in der das System zuerst laufen könnte: Protokollaufbewahrung oder Protokoll voll.

• Wenn die SQL-Ports des Sekundärsystems für Lesezugriffe geöffnet sind.

• Der zwischen den Systemen verwendete Replikationsmodus.

• Die aktuelle durchschnittliche Redo-Log-Versandzeit und die durchschnittliche Größe der versendeten Redo-Log-Puffer.

  Hier wird beschrieben, wie lange es durchschnittlich gedauert hat, Redo-Log-Puffer an den Sekundärstandort zu senden, basierend auf Messungen in den letzten 24 Stunden.

Darüber hinaus finden Sie detaillierte Informationen zur Systemreplikation auf den Registerkarten in der Abbildung „Details zum Status eines bestimmten Service".

Wenn Sie auf der Registerkarte Replizierte Services eine Zeile auswählen, werden die Details für den entsprechenden Service thematisch gruppiert, wie im folgenden Beispiel für den Index-Server. Da diese Informationen kontextsensitiv sind, sehen Sie nur die für dieses System erforderlichen Informationen. Da dieses Beispielsystem in der Betriebsart logreplay läuft, werden daher hier keine Informationen zum Delta-Datenversand angezeigt. Die kontextsensitiven Informationen zur Verzögerung der Protokollwiedergabe werden jedoch angezeigt. Das Delta zwischen der letzten Protokollposition und der wiedergegebenen Protokollposition gibt an, wie weit die Protokollwiedergabe im Sekundärsystem zurückliegt.

Das SAP HANA Cockpit unterscheidet zwischen einem Primär- und einem Sekundärsystem. Im SAP HANA Cockpit des Sekundärsystems bietet die Kachel Systemreplikation eine erste Übersicht über den Status dieser Site. In der Systemreplikationsübersicht können Sie eine Übernahme initiieren.

Die Python-Skripte befinden sich im Verzeichnis $DIR_INSTANCE/exe/python_support.

Sie können auch Informationen über den Gesamtstatus der Sites und die Systemreplikation mithilfe von Python-Skripten sammeln.

Das Skript landcapeHostConfiguration.py zeigt den Status des Primärsystems an:

• SAP HANA ist in Ordnung.

• SAP HANA ist beispielsweise nach einem automatischen Host-Failover in Ordnung.

• Es werden nicht genügend Instanzen gestartet, und eine Übernahme wäre nützlich.

Das Skript stellt einen Gesamtstatus und einen Rückgabewert bereit, der mit dem Gesamthoststatus übereinstimmt.

Eine Übernahme wird nur empfohlen, wenn der Rückgabewert aus dem Skript 1 (Fehler) ist.

1234567
<sid>adm># python $DIR_INSTANCE/exe/python_support/landscapeHostConfiguration.py
| Host  | Host   | Host   |    ...    | NameServer | NameServer  | ...
|       | Active | Status |           | Config Role| Actual Role |
| ----- | ------ | ------ | --------- | ---------- | ----------- | ------
| host1 | yes    | ok     |    ...    | master 1   | master      | ...
| host2 | yes    | ok     |    ...    | master 2   | slave       | ...
overall host status: ok

Folgende Host-Zustände sind möglich:

• OK: System ist OK.

• WARNUNG: Es findet ein automatischer Host-Failover auf einen Standby-Host statt.

• INFORMATION: Die Landschaft ist voll funktionsfähig, aber die aktuelle (tatsächliche) Rolle des Hosts weicht von der konfigurierten Rolle ab.

• FEHLER: Es gibt nicht genug aktive Hosts.

Das Skript systemReplicationStatus.py zeigt den Status der Systemreplikation an.

Die Verwendung von systemReplicationStatus.py hat den Vorteil, dass angezeigt wird, ob die Sekundärsysteme synchron sind oder nicht. Dies bietet mehr Konfidenz, wenn eine Übernahme gerechtfertigt ist, da es zu unerwartetem Datenverlust kommen kann, wenn die Systemreplikation nie synchron war oder veraltet ist.

Beispiel:

123456789101112131415161718
h10adm@wdflbmt7346:/> python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py
| Database | Host        | Service Name | Site Name   | Secondary   | Secondary     | Replication |
|          |             |              |             | Host        | Site Name     | Status      |
| -------- | ----------- | ------------ | ----------- | ----------- | ------------- | ----------- |
| SYSTEMDB | wdflbmt7346 | nameserver   | PrimarySite | wdflbmt7347 | SecondarySite | ACTIVE      |
| H10      | wdflbmt7346 | xsengine     | PrimarySite | wdflbmt7347 | SecondarySite | ACTIVE      |
| H10      | wdflbmt7346 | indexserver  | PrimarySite | wdflbmt7347 | SecondarySite | ACTIVE      |

status system replication site "2": ACTIVE
overall system replication status: ACTIVE

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mode: PRIMARY
site id: 1
site name: PrimarySite

Der zusätzliche Parameter systemReplicationStatus.py --localhost schränkt die Ausführung des Python-Skripts auf den Host ein, auf dem es ausgeführt wird.

Das Skript stellt die folgenden Rückgabewerte bereit:

• 10: Keine Systemreplikation

• 11: Fehler

• 12: Unbekannt

• 13: Initialisierung

• 14: Synchronisierung

• 15: Aktiv

Sie können systemreplikationsspezifische Informationen auch direkt aus Systemsichten abrufen.

Bestimmte Alerts werden vom Primärsystem ausgegeben, um Sie vor potenziellen Problemen zu warnen.

Die Alerts Verbindung geschlossen und Nichtübereinstimmung der Konfigurationsparameter werden ausgelöst, wenn eine Systemreplikationsverbindung geschlossen wird oder wenn es eine Nichtübereinstimmung des Konfigurationsparameters für die Systemreplikation gibt.

Der Alert Logreplay Backlog wird ausgelöst, wenn der Logreplay-Backlog der Systemreplikation erhöht wird. In diesem Fall verzögert sich logreplay am Sekundärstandort, was zu einer längeren Übernahmezeit führt.

Um den Grund für den erhöhten Logreplay-Backlog der Systemreplikation zu ermitteln, prüfen Sie den Status der Services im Sekundärsystem. Um weitere Informationen zu erhalten, überwachen Sie den Sekundärstandort. Mögliche Ursachen für den erhöhten Logreplay-Backlog der Systemreplikation können z.B. eine langsame oder nicht funktionierende Protokollwiedergabe oder ein nicht laufender Service auf dem Sekundärsystem sein.

Der Alert Erhöhter Logversandrückstand wird ausgelöst, wenn der Versandrückstand des Systemreplikationsprotokolls erhöht wird. In diesem Fall wird der Protokollversand an das Sekundärsystem verzögert oder funktioniert nicht ordnungsgemäß, was zu einem Datenverlust im Sekundärsystem führt, wenn eine Übernahme ausgeführt wird.

Um den Grund für den erhöhten Rückstand des Systemreplikationsprotokolls zu ermitteln, prüfen Sie den Status des Sekundärsystems. Mögliche Ursachen für den erhöhten Rückstand beim Versand des Systemreplikationsprotokolls können eine langsame Netzwerk-Performance, Verbindungsprobleme oder andere interne Probleme sein (z.B. im Replikationsmodus sync oder syncmem).

Datenbankparameter sollten im Primär- und Sekundärsystem identisch sein und werden automatisch geprüft. Der Konfigurationsparameter checker meldet alle Unterschiede zwischen Primärsystemen, Sekundärsystemen und Sekundärsystemen der Schicht 3. In einem solchen Fall erzeugt der Parameterchecker einen Alert.

Wenn die Parameterreplikation aktiviert ist, werden alle Änderungen, die am Primärsystem vorgenommen wurden, automatisch an die Sekundärstandorte repliziert. Wenn dieser Parameter nicht aktiviert ist, sollten Änderungen manuell im anderen System dupliziert werden.

Die Parameterreplikation ist standardmäßig deaktiviert. Sie kann auf der Primärsite mit dem folgenden Parameter aktiviert und deaktiviert werden:

[inifile_checker]/replicate = true | false

Der Parameter checker ist standardmäßig aktiviert. Sie kann auf der Primärsite mit dem folgenden Parameter aktiviert und deaktiviert werden:

[inifile_checker]/enable = true | false

Einige Parameter haben absichtlich unterschiedliche Einstellungen auf dem Primär- und dem Sekundärstandort. Ein Beispiel ist der Parameter global_allocation_limit , bei dem das Sekundärsystem für andere Systeme verwendet wird. Indem Sie diese Parameter zur Ausschlussliste hinzufügen, können Sie sie von der Prüfung ausschließen.