Backint-basierte Sicherung und Wiederherstellung für SAP HANA

Dieser Planungsleitfaden konzentriert sich ausschließlich auf das Backint-Feature des Google Cloud-Agents für SAP, mit dem Sie Sicherungs- und Wiederherstellungsvorgänge für SAP HANA ausführen können. Informationen zum Agent und allen seinen Features finden Sie im Planungsleitfaden für den Google Cloud-Agent für SAP.

Für Ihre SAP HANA-Systeme können Sie Sicherungs- und Wiederherstellungsvorgänge mit dem Backint-Feature des Agents von Google Cloud für SAP ausführen. Dieses Feature ist für SAP HANA-Systeme verfügbar, die in Google Cloud, in der Bare-Metal-Lösung, lokal oder bei anderen Cloudanbietern ausgeführt werden.

Das Backint-Feature des Agents ist von SAP zertifiziert. Dieses Feature ist in SAP HANA eingebunden, sodass Sie Sicherungen mithilfe von SAP-nativen Sicherungs- und Wiederherstellungsfunktionen direkt in Cloud Storage speichern und abrufen können.

Informationen zum Konfigurieren dieses Features finden Sie unter Backint-basierte Sicherung und Wiederherstellung für SAP HANA konfigurieren.

Informationen zum Ausführen von Sicherungs- und Wiederherstellungsvorgängen für SAP HANA mit Backint finden Sie unter Sicherung und Wiederherstellung mit Backint ausführen.

Informationen zur SAP-Zertifizierung des Backint-Features finden Sie unter:

Schätzung monatliche Kosten

Für die Speicherung in Cloud Storage fallen Gebühren an. Weitere Informationen zu den Preisen finden Sie unter Cloud Storage – Preise.

Sie können die geschätzten monatlichen Cloud Storage-Kosten mit dem Google Cloud-Preisrechner berechnen.

Verwenden Sie die folgenden Informationen, um die Kosten besser einschätzen zu können:

  • Gesamtgröße für vollständige, Delta- und inkrementelle Sicherungen, die in einem Monat erforderlich sind, einschließlich einer geplanten Wachstumsrate.
  • Die tägliche Änderungsrate in Bezug auf die von Ihrer SAP HANA-Datenbank erstellten SAP HANA-Logvolumen-Sicherungen. Sie müssen diese Rate mit der Anzahl der Tage multipliziert, die Sie die Logsicherungen gemäß Ihrer Sicherungsstrategie planen.
  • Der Speicherort und der Typ des Cloud Storage-Buckets, der Ihrer Sicherungsstrategie entspricht. Buckets mit nur einer Region dürfen nur zu Testzwecken verwendet werden.
  • Die Speicherklasse des Cloud Storage-Buckets. Wählen Sie eine Klasse aus, die der Häufigkeit entspricht, mit der Sie auf die Daten zugreifen müssen.
  • Die geschätzte Menge der Klasse A und Klasse B mit Cloud Storage für die Sicherung und Wiederherstellung in einem Monat. Weitere Informationen zu diesen Vorgängen finden Sie unter Vorgänge der einzelnen Klassen.

  • Der geschätzte ausgehende Netzwerktraffic für interregionale, intra- und multiregionale Vorgänge, z. B. beim Wiederherstellen einer Datenbank mit einer Sicherung. Weitere Informationen finden Sie unter Datenübertragung in Google Cloud.

    Eingehender Netzwerktraffic zu Cloud Storage ist kostenlos. Sie müssen daher nicht in die Schätzung einbezogen werden.

Backint-Konfigurationsdatei

Sie konfigurieren das Backint-Feature des Google Cloud-Agents für SAP. Dazu geben Sie Parameter in einer separaten Konfigurationsdatei an, die der Agent erstellt, wenn Sie das Feature aktivieren.

Standardmäßig hat die Konfigurationsdatei den Namen parameters.json und der Standardspeicherort ist /usr/sap/SID/SYS/global/hdb/opt/backint/backint-gcs/parameters.json.

SID ist eine Platzhaltervariable für die SID Ihres SAP-Systems.

Sie können entweder eine einzelne Konfiguration oder separate Konfigurationsdateien für jede der folgenden Optionen verwenden: SAP HANA-Datenvolume, SAP HANA-Logvolumen und SAP HANA-Sicherungskatalog. Sie können auch andere Anpassungen vornehmen, z. B. die Dateien umbenennen und in andere Verzeichnisse verschieben. Eine Anleitung zum Ausführen dieser Anpassungen finden Sie unter Backint-Konfigurationsdatei anpassen.

Sicherungen in Cloud Storage-Buckets speichern

Das Backint-Feature des Agents von Google Cloud für SAP speichert Ihre SAP HANA-Sicherungen in einem Cloud Storage-Bucket. In den folgenden Abschnitten erfahren Sie, wie Sie Cloud Storage-Buckets erstellen und wie der Agent von Google Cloud für SAP Sicherungen in den Buckets speichert.

Cloud Storage-Buckets erstellen

Wenn Sie einen Bucket erstellen, müssen Sie den Bucket-Standort und die Bucket-Speicherklasse auswählen.

Ein Bucket-Standort kann regional, dual-regional oder multiregional sein. Sie müssen einen Bucket auswählen, abhängig davon, ob Sie den Standort Ihrer Daten, die Latenzanforderungen für Sicherungen und Wiederherstellungen sowie den Schutz vor regionalen Ausfällen einschränken müssen. Weitere Informationen finden Sie unter Bucket-Standorte.

Wählen Sie dual- oder multiregionale Buckets in Regionen aus, die mit den Regionen identisch sind, in denen Ihre SAP HANA-Instanzen ausgeführt werden, oder sich in deren Nähe befinden.

Wählen Sie die Speicherklasse danach aus, wie lange Sie Ihre Sicherungen aufbewahren müssen, wie oft Sie darauf zugreifen werden und welche Kosten anfallen. Weitere Informationen finden Sie unter Speicherklassen.

Sicherungsorganisation im Bucket sichern

Der Google Cloud-Agent für SAP verwendet Ordner in Ihrem Cloud Storage-Bucket, um Ihre SAP HANA-Sicherungen zu organisieren.

Der Agent erstellt für jede SAP HANA-Datenbank, jedes System oder jeden Mandanten einen Ordner. den Sie mithilfe des Backint-Features sichern. Im Ordner einer Datenbank erstellt der Agent separate Ordner zum Speichern der Sicherungen des SAP HANA-Daten-Volumes, des SAP HANA-Log-Volumes und des SAP HANA-Sicherungskatalogs.

Zur Benennung der Sicherungen folgt der Agent den HANA-Namenskonventionen von SAP HANA.

Im Folgenden finden Sie Beispielpfade für SAP HANA-Sicherungen in einem Cloud Storage-Bucket:

  • Für die Sicherungen der Systemdatenbank:

    BUCKET_NAME/SID/usr/sap/SID/SYS/global/hdb/backint/SYSTEMDB

  • Für die Sicherungen einer Mandantendatenbank:

    BUCKET_NAME/SID/usr/sap/SID/SYS/global/hdb/backint/DB_TENANT_SID

    Ersetzen Sie Folgendes:

    • BUCKET_NAME: der Name Ihres Cloud Storage-Buckets
    • SID: die System-ID Ihres SAP-Systems
    • TENANT_SID: ist die System-ID Ihrer Mandantendatenbank

Best Practices zum Organisieren von Sicherungen

Verwenden Sie die folgenden Best Practices zum Organisieren von Sicherungen in Ihrem Cloud Storage-Bucket:

  • Benennen Sie die Ordner oder Dateien in Ihrem Cloud Storage-Bucket nicht um.

    Das Umbenennen eines Ordners oder einer Datei ändert effektiv den Sicherungspfad. Dies ist eine Aktion, die gegen die Standards verstößt, die von SAP für Sicherungstools von Drittanbietern erzwungen werden. Das Umbenennen eines Ordners oder einer Datei führt dazu, dass der Backint-Mechanismus während der Wiederherstellung der Datenbank fehlschlägt, bis Sie den Ordner oder die Datei auf den Namen zurücksetzen, den sie beim Erstellen der Sicherung hatten.

  • Verwenden Sie nicht denselben Cloud Storage-Bucket, um die Sicherungen von zwei oder mehr SAP HANA-Datenbanken mit derselben SAP-System-ID (SID) zu speichern.

    In Cloud Storage organisiert der Agent von Google Cloud für SAP die SAP HANA-Sicherungen in SID-spezifischen Ordnern. Wenn Sie also denselben Bucket zum Speichern von Sicherungen von SAP HANA-Datenbanken mit derselben SID verwenden, können Sicherungsvorgänge Sicherungen überschreiben oder löschen.

    Ausnahmen von dieser Best Practice sind SAP HANA-Datenbanken, die in Hochverfügbarkeits- (HA), DR- (Disaster Recovery) oder Bereitstellungen mit horizontaler Skalierung installiert sind. Dabei haben alle SAP HANA-Knoten dieselbe SID. Für diese Systeme werden die Sicherungen im selben Cloud Storage-Bucket gespeichert, da während des normalen Betriebs nur eine SAP HANA-Instanz aktiv ist und in Sicherungen schreibt. Weitere Informationen finden Sie unter Backint in SAP HANA-Bereitstellungen verwenden.

Verschlüsselungsoptionen für Sicherungen

Cloud Storage verschlüsselt Ihre Daten immer, bevor sie in einem Bucket gespeichert werden. Sie können eine der folgenden Optionen nutzen, um eine weitere Verschlüsselungsebene auf die Daten anzuwenden:

Verschlüsselungsoption Beschreibung
Verwenden Sie einen vom Kunden verwalteten Verschlüsselungsschlüssel mit dem Backint-Feature des Agents von Google Cloud für SAP. Wenn Sie einen vom Kunden verwalteten Verschlüsselungsschlüssel verwenden möchten, müssen Sie den Pfad zum Schlüssel im Parameter kms_key in der Datei PARAMETERS.json angeben. Außerdem müssen Sie dem vom Agent verwendeten Dienstkonto Zugriff auf den Schlüssel gewähren. Informationen dazu, wie Sie einem Dienstkonto Zugriff auf einen Verschlüsselungsschlüssel gewähren, finden Sie unter Cloud Key Management Service-Schlüssel einem Dienst-Agent zuweisen.
Verwenden Sie einen vom Kunden bereitgestellten Verschlüsselungsschlüssel mit dem Backint-Feature des Agents von Google für SAP. Wenn Sie einen vom Kunden bereitgestellten Verschlüsselungsschlüssel verwenden möchten, geben Sie den Pfad zum Schlüssel im Parameter encryption_key in der Datei PARAMETERS.json an. Der Schlüssel muss ein base64-codierter AES-256-Schlüsselstring sein, wie unter Vom Kunden bereitgestellte Verschlüsselungsschlüssel beschrieben.
Verwenden Sie SAP HANA Backup Encryption.

Diese Option ist ab SAP HANA 2.0 SP01 verfügbar. Sie können die Sicherungen Ihrer SAP HANA-Daten und Log-Volumes mit AES 256-Bit-Verschlüsselung verschlüsseln. Sicherungen des SAP HANA-Sicherungskatalogs werden nie verschlüsselt. Für diese Verschlüsselung müssen Sie einen Root-Schlüssel für die Sicherungsverschlüsselung erstellen und zusätzliche Konfigurationen vornehmen, wie im SAP HANA-Dokument Verschlüsselungskonfiguration beschrieben.

Ab SAP HANA 2.0 SPS07 ist die Verschlüsselung für die Volumes /hana/data, /hana/log und /hanabackup während der Installation standardmäßig aktiviert, sofern Sie sie nicht deaktivieren.

Informationen zum Erstellen einer Sicherung des Stammschlüssels finden Sie im SAP-Dokument Root-Schlüssel sichern.

Die Sicherungsverschlüsselung erfordert zusätzliche Speicher- und CPU-Ressourcen während der Sicherungs- und Wiederherstellungsvorgänge. Die Verschlüsselung von Sicherungen hat in der Regel keine Auswirkungen auf die Datenbankleistung während Sicherungs- oder Wiederherstellungsvorgängen, kann jedoch je nach Größe der SAP HANA-Datenbank und der erwarteten höheren CPU-Auslastung auf die Gesamtsystemleistung auswirken.

Einschränkungen der Verschlüsselung

Für die Verwendung von Back-up-Verschlüsselung gelten folgende Einschränkungen:

  • Wenn Sie sowohl die Parameter kms_key als auch encryption_key angeben, schlägt der Agent von Google Cloud für SAP fehl und wird mit dem Status 1 beendet.
  • Wenn Sie den Parameter parallel_streams entweder mit dem Parameter kms_key oder dem Parameter encryption_key angeben, schlägt der Google Cloud-Agent für SAP fehl und wird mit dem Status 1 beendet.

Komprimierungsoptionen für Sicherungen

Durch das Komprimieren von Sicherungen werden ihre Größe und der Speicherplatz im Cloud Storage-Bucket reduziert. Dies reduziert wiederum Ihre Speicherkosten. Das Komprimieren von Sicherungen erfordert jedoch mehr CPU-Nutzung während Sicherungsvorgängen und kann sich bei sowohl Sicherungs- als auch Wiederherstellungsvorgängen auf die Gesamtleistung auswirken.

Als Alternative zur Komprimierung von Sicherungen können Sie das Autoclass-Feature von Cloud Storage verwenden, das Objekte in Ihrem Bucket basierend auf dem Zugriffsmuster des Objekts automatisch auf die entsprechende Speicherklasse umstellt.

Für die Komprimierung Ihrer SAP HANA-Sicherungen stehen Ihnen folgende Optionen zur Verfügung:

Komprimierungsoption Beschreibung
SAP HANA-Datensicherungskomprimierung verwenden

Dies ist die empfohlene Option, wenn Sie eine Sicherungskomprimierung benötigen.

Ab SAP HANA 2.0 SPS06 unterstützt SAP HANA bei der Durchführung von Sicherungsvorgängen LZ4-Komprimierungsalgorithmen. Standardmäßig ist die Komprimierung deaktiviert. Anleitungen zum Aktivieren dieser Komprimierung finden Sie im SAP HANA-Dokument Datensicherungskomprimierung konfigurieren.
Cloud Storage-Komprimierung verwenden

Wenn Sie die integrierte Komprimierung verwenden möchten, die der Agent beim Schreiben von Sicherungen in Ihren Cloud Storage-Bucket ausführen kann, verwenden Sie in PARAMETERS.json den Parameter compress.

Wir empfehlen, diese Komprimierung nicht zu aktivieren.

Multistreaming-Datensicherungen

Für Versionen vor SAP HANA 2.0 SP05 unterstützt SAP HANA Multi-Streaming für Datenbanken mit mehr als 128 GB. Ab SAP HANA 2.0 SP05 kann dieser Schwellenwert mit dem SAP HANA-Parameter parallel_data_backup_backint_size_threshold konfiguriert werden. Dieser gibt die Mindestgröße der Datenbanksicherung in GB an, damit Multistreaming aktiviert werden kann.

Multistreaming ist nützlich, um den Durchsatz zu erhöhen und Datenbanken zu sichern, die größer als 5 TB sind. Dies ist die maximale Größe für ein einzelnes Objekt in Cloud Storage.

Zum Aktivieren von Multistreaming legen Sie den SAP HANA-Parameter parallel_data_backup_backint_channels mit der Anzahl der zu verwendenden Kanäle fest. Die optimale Anzahl von Kanälen, die Sie für Multistreaming verwenden, hängt davon ab, welche SAP HANA ausgeführt wird.

Berücksichtigen Sie auch die Durchsatzleistung des mit Ihrer HANA-Instanz verbundenen Datenlaufwerks sowie die Bandbreite, die Ihr Administrator für Sicherungsaktivitäten zuweist. Sie können den Durchsatz anpassen, wenn Sie die Anzahl der Streams ändern oder den Durchsatz mithilfe des Parameters rate_limit_mb in PARAMETERS.json begrenzen.

Bei einem multiregionalen Cloud Storage-Bucket beginnen Sie mit acht Kanälen. Bei einem regionalen Bucket beginnen Sie mit zwölf Kanälen. Nach Bedarf passen Sie die Anzahl der Kanäle an, um Ihre Ziele in der Sicherungsleistung zu erreichen.

Wie in der SAP HANA-Dokumentation angegeben, benötigt jeder zusätzliche Kanal einen E/A-Puffer von 512 MB. Dazu geben Sie die Größe des E/A-Puffers an und verwenden dafür den Parameter data_backup_buffer_size im Abschnitt backup der Datei global.ini. Weitere Informationen zum Einfluss der E/A-Puffergröße auf die Sicherungszeiten finden Sie im SAP-Hinweis 2657261 – Lange Sicherungsdauer mit Backint in HANA-DB. Ab HANA 2.0 SP05 gibt SAP für diesen Parameter einen Höchstwert von 4 GB an. Tests in Google Cloud haben keinen Vorteil darin gezeigt, die Puffergröße erheblich über die Standardeinstellung hinaus zu erhöhen. Das kann jedoch für Ihre Arbeitslast variieren.

Weitere Informationen zum Multistreaming finden Sie im Administratorhandbuch für SAP HANA, das für Ihre SAP HANA-Version spezifisch ist, unter Multistreaming-Datensicherungen mit Sicherungstools von Drittanbietern.

Parallele Uploads

Für die SAP HANA-Logsicherungsdateien können Sie die Uploadleistung verbessern, indem Sie das Feature für parallele Uploads des Google Cloud-Agents für SAP aktivieren. Dieses Feature ist besonders nützlich für die SAP HANA-Logsicherungsdateien, da sie nicht von SAP HANA als Multistreaming gestreamt werden können.

Für die SAP HANA-Datensicherungen können Sie die Anzahl der SAP HANA-Sicherungskanäle mit dem SAP HANA-Parameter parallel_data_backup_backint_channels optimieren.

Wenn der parallele Upload aktiviert ist, teilt der Google Cloud-Agent für SAP jede einzelne Sicherungsdatei von SAP HANA in mehrere Teile auf, die parallel hochgeladen werden. Dadurch verbessert sich die Uploadleistung. Wenn die Teile von Cloud Storage empfangen werden, werden sie wieder zusammengesetzt und als eine einzelne Originaldatei gespeichert, die vom Google Cloud-Agent für SAP von SAP HANA empfangen wurde. Für eine einzelne Datei gilt die Größenbeschränkung von 5 TB für Objekte in Cloud Storage.

Parallelen Upload konfigurieren

Sie aktivieren das Feature für parallele Uploads. Geben Sie dazu die Parameter parallel_streams in Ihrer PARAMETERS.json-Datei an.

Informationen zu diesem Parameter finden Sie unter Konfigurationsparameter.

Beschränkungen des parallelen Uploads

Für parallele Uploads gelten folgende Einschränkungen:

  • Wenn Sie die Verschlüsselung mit dem Parameter encryption_key oder kms_key aktivieren, können Sie keinen parallelen Upload verwenden. Die Verschlüsselung ist mit dem parallelen Upload nicht kompatibel. Wenn Sie den Parameter parallel_streams mit einem dieser Verschlüsselungsparameter angeben, schlägt der Agent von Google Cloud für SAP fehl und wird mit dem Status 1 beendet.
  • Wenn Sie die Komprimierung aktivieren, können Sie keinen parallelen Upload verwenden. Die Komprimierung ist mit dem parallelen Upload nicht kompatibel. Wenn Sie den Parameter parallel_streams angeben und den Parameter compress in der Konfiguration weglassen, schlägt der Google Cloud-Agent für SAP fehl und wird mit dem Status 1 beendet.
  • Wenn Ihr Cloud Storage-Bucket eine Aufbewahrungsrichtlinie implementiert, unterstützt der Bucket keine parallelen Uploads. Die Aufbewahrungsrichtlinie verhindert, dass die Teile in einer einzelnen Datei wieder zusammengefügt werden, wodurch der Upload fehlschlägt.

Parallele Uploads optimieren

Bei SAP HANA-Logvolumensicherungen können parallele Uploads den Sicherungsdurchsatz erheblich verbessern, da SAP HANA die Logsicherungen nicht multistreamt.

In den meisten Fällen reicht es aus, den Parameter parallel_streams in Ihrer Backint-Konfigurationsdatei mit einem Wert von 32 oder weniger anzugeben. Bei sehr großen Logvolumen können Sie den Durchsatz mit einem hohen Wert wie 32 für parallel_streams erhöhen und die Werte für die SAP HANA-Parameter log_segment_size_mb und max_log_backup_size erhöhen.

Zur Begrenzung der Netzwerkbandbreite, die von Ihren Sicherungen verwendet wird, legen Sie mit dem Backint-Konfigurationsparameter rate_limit_mb die maximale Bandbreite fest, die parallele Uploads verwenden können.

Authentifizierung und Zugriffssteuerung

Google Cloud verwendet Dienstkonten, um Programme wie den Google Cloud-Agent für SAP zu identifizieren und zu steuern, auf welche Google Cloud-Ressourcen die Programme zugreifen können.

Erforderliche Cloud Storage-Berechtigungen

Damit der Agent von Google Cloud für SAP Speicher und Sicherungen aus einem Cloud Storage-Bucket abrufen kann, muss dem vom Host verwendeten Dienstkonto die IAM-Rolle Storage-Objekt-Administrator (storage.objectAdmin) zugewiesen werden. .

Eine Anleitung zum Festlegen der IAM-Rolle finden Sie unter IAM-Rollen festlegen.

Überlegungen zu Dienstkonten

Wenn SAP HANA auf einer Compute Engine-VM ausgeführt wird, verwendet der Agent von Google Cloud für SAP standardmäßig das Dienstkonto der VM. Wenn Sie das VM-Dienstkonto verwenden, hat der Agent dieselben Berechtigungen auf Projektebene wie alle anderen Programme und Prozesse, die das VM-Dienstkonto verwenden.

Für die strengste Zugriffssteuerung erstellen Sie für den Agent ein separates Dienstkonto und gewähren Sie dem Dienstkonto Zugriff auf den Cloud Storage-Bucket auf Bucket-Ebene.

Wenn SAP HANA nicht auf einer Compute Engine-VM ausgeführt wird, müssen Sie für den Agent ein Dienstkonto erstellen. Erstellen Sie das Dienstkonto im Google Cloud-Projekt, das den Cloud Storage-Bucket enthält, den der Agent von Google Cloud für SAP für Sicherungen und Wiederherstellungen verwendet.

Wenn Sie ein Dienstkonto für den Google Cloud-Agent für SAP erstellen, müssen Sie auch einen Dienstkontoschlüssel erstellen. Sie speichern den Schlüssel auf dem SAP HANA-Host und geben den Pfad zum Schlüssel zum Parameter service_account_key in PARAMETERS.json an. Wenn SAP HANA auf einer Compute Engine-VM ausgeführt wird und der Pfad zu einem Schlüssel angegeben wird, wird der Agent von Google Cloud für SAP angewiesen, das mit dem Schlüssel verknüpfte Dienstkonto anstelle des VM-Dienstkontos zu verwenden.

Wenn Sie ein dediziertes Dienstkonto für den Agent verwenden, sollten Sie Ihre Schlüssel regelmäßig rotieren, um sich vor unbefugtem Zugriff zu schützen.

Wenn Sie einen vom Kunden verwalteten Verschlüsselungsschlüssel verwenden, der vom Cloud Key Management Service zum Verschlüsseln Ihrer Sicherungen in Cloud Storage generiert wird, müssen Sie Ihrem Dienstkonto Zugriff auf den Verschlüsselungsschlüssel gewähren. Weitere Informationen finden Sie unter Cloud KMS-Schlüssel einem Dienst-Agent zuweisen.

Zugriff auf Cloud APIs und Metadatenserver

Der Agent von Google Cloud für SAP benötigt während der Sicherungs- und Wiederherstellungsvorgänge Zugriff auf Google Cloud-IP-Adressen und -Hosts.

Weitere Informationen finden Sie unter Zugriff auf Cloud APIs und Metadatenserver aktivieren.

Proxyserver und Agent

Standardmäßig umgeht der Agent von Google Cloud HTTP-Proxys und liest keine Proxy-Umgebungsvariablen wie http_proxy, https_proxy oder no_proxy im Betriebssystem.

Wenn Sie keine Alternative haben oder Ihre Organisation die Auswirkungen auf die Leistung versteht und das für die Weiterleitung von Back-ups über einen Proxyserver erforderliche Fachwissen hat, können Sie den Agent so konfigurieren, dass er einen Proxy verwendet.

Die Proxyeinstellungen für den Google Cloud-Agent für SAP sind in der Datei net.properties enthalten:

/usr/sap/SID/SYS/global/hdb/opt/backint/backint-gcs/jre/conf/net.properties

Proxyserver für Back-ups und Wiederherstellungen umgehen

Obwohl der Agent von Google Cloud für SAP standardmäßig Proxyserver umgeht, können Sie die Umgehung explizit machen. Dazu geben Sie die erforderlichen Google Cloud-Domainnamen und IP-Adressen im http.nonProxyHosts-Parameter in der net.properties-Datei an: /usr/sap/SID/SYS/global/hdb/opt/backint/backint-gcs/jre/conf/net.properties. Beispiel:

http.nonProxyHosts=localhost|127.*|[::1]|*.googleapis.com|169.254.169.254|metadata.google.internal

Proxyserver für Back-ups und Wiederherstellungen verwenden

Wenn Sie den Google Cloud-Agent für SAP so konfigurieren möchten, dass Sicherungen über einen Proxyserver gesendet werden, geben Sie in der Datei net.properties den Proxyhost- und die Portnummerparameter an: /usr/sap/SID/SYS/global/hdb/opt/backint/backint-gcs/jre/conf/net.properties.

Bei Abfragen an die Compute Engine-VM-Instanzmetadaten kann der Agent von Google Cloud für SAP keinen Proxy verwenden. Daher müssen Sie den Domainnamen und die IP-Adresse für die Instanzmetadaten im http.nonProxyHosts-Parameter angeben.

Das folgende Beispiel zeigt eine gültige Proxykonfiguration für den Google Cloud-Agent für SAP in der Datei net.properties:

http.proxyHost=PROXY_HOST
http.proxyPort=PROXY_PORT
http.nonProxyHosts=localhost|127.*|[::1]|169.254.169.254|metadata.google.internal
https.proxyHost=PROXY_HOST
https.proxyPort=PROXY_PORT

Feinabstimmung der Leistung

Die Leistung der Sicherung und Wiederherstellung Ihrer SAP HANA-Datenbanken hängt von der Gesamtgröße der Datenbank und den für Ihren SAP HANA-Host verfügbaren Ressourcen ab. Sie können die Leistung verbessern, indem Sie die folgenden Konfigurationsoptionen verwenden, die in SAP HANA und dem Agent von Google Cloud für SAP verfügbar sind:

  • Aktivieren Sie Multistreaming mit dem SAP HANA-Parameter parallel_data_backup_backint_channels. Geben Sie außerdem die Größe des E/A-Puffers mit dem SAP HANA-Parameter data_backup_buffer_size an. Weitere Informationen finden Sie unter Multistreaming-Datensicherungen.
  • Aktivieren Sie parallele Uploads, indem Sie einen Wert für den Parameter parallel_streams in Ihrer Backint-Konfigurationsdatei PARAMETERS.json angeben. Diese Konfiguration kann die Leistung beim Senden der SAP HANA-Logsicherungen an Cloud Storage erheblich verbessern. Weitere Informationen finden Sie unter Parallele Uploads.
  • Wenn Sie Sicherungen komprimieren müssen, verwenden Sie die integrierte Komprimierung von SAP HANA. Dies ist die empfohlene Komprimierungsoption. Weitere Informationen finden Sie unter Komprimierungsoptionen für Sicherungen.
  • Optimieren Sie die Konfiguration im Zusammenhang mit SAP HANA-Logsicherungen, wie im SAP HANA-Dokument Optimale Logsicherungskonfiguration finden beschrieben. Weitere Informationen finden Sie im SAP HANA-Administratorhandbuch für Ihre SAP HANA-Version.
  • Wenn Ihr SAP HANA-System auf einer Compute Engine-VM-Instanz ausgeführt wird, müssen Sie prüfen, ob es SAP-zertifizierte nichtflüchtige Speicher- oder Hyperdisk-Volumes verwendet. Die Verwendung eines anderen Laufwerkstyps kann sich negativ auf die Sicherungsleistung auswirken, insbesondere beim SAP HANA-Datenvolumen. Informationen zu den zertifizierten Laufwerkstypen finden Sie unter Unterstützte Laufwerkstypen.

Selbstdiagnose

Damit Sie Ihre Netzwerkverbindung und den Zugriff auf den Cloud Storage-Bucket testen können, enthält der Agent von Google Cloud für SAP ab Version 3.0 ein Tool für die Selbstdiagnose.

Wenn Sie dieses Tool ausführen, werden mehrere temporäre Dateien in Ihrem Dateisystem erstellt. Diese Dateien werden dann in Ihren Cloud Storage-Bucket hochgeladen, wiederhergestellt, verifiziert und gelöscht. Dieses Tool gibt alle Probleme mit Ihrem API-Zugriff aus. Sie können die Sicherungsleistung auch testen, indem Sie die Parameter compress aktivieren und verschiedene Werte für Parameter wie parallel_streams und threads angeben.

Eine Anleitung zur Selbstdiagnose für den Google Cloud-Agent für SAP finden Sie unter Sicherung und Wiederherstellung validieren.

Logging

Zusätzlich zu den von SAP HANA in backup.log gespeicherten Logs schreibt das Backint-Feature des Agents von Google Cloud für SAP operative und Kommunikationsfehlerereignisse in Logdateien im folgenden Verzeichnis: /usr/sap/SID/SYS/global/hdb/opt/backint/backint-gcs/logs.

Diese Logs finden Sie auch in der Hauptlogdatei des Google Cloud-Agents für SAP, die sich im Verzeichnis /var/log/google-cloud-sap-agent/ befindet.

Wenn die Größe einer Logdatei 25 MB erreicht, rotiert der Google Cloud-Agent für SAP die Logdateien.

Standardmäßig sendet der Google Cloud-Agent für SAP die Backint-bezogenen Logdateien an Cloud Logging. Sie können dies deaktivieren, indem Sie in Ihrer PARAMETERS.json-Datei den Parameter log_to_cloud mit dem Wert false festlegen.

Backint in SAP HANA-Bereitstellungen verwenden

Die folgenden Abschnitte enthalten szenarienspezifische Planungsinformationen zur Verwendung des Backint-Features des Google Cloud-Agents für SAP mit SAP HANA.

Backint in HA-Bereitstellungen verwenden

In einem SAP HANA-Hochverfügbarkeitscluster müssen Sie den Google Cloud-Agent für SAP auf jedem Knoten im Cluster installieren und das Backint-Feature aktivieren.

Verwenden Sie für jede SAP HANA-Instanz im HA-Cluster dieselbe Backint-Konfiguration und dieselben Cloud Storage-Bucket-Spezifikationen. Sie können dieselben Bucket-Spezifikationen verwenden, da während der normalen Vorgänge nur die aktive SAP HANA-Instanz in einer Hochverfügbarkeitskonfiguration in Cloud Storage schreibt und sich das sekundäre System im Replikationsmodus befindet. Dies gilt für die Sicherungen des SAP HANA-Datenvolumes, des SAP HANA-Logvolumens und des SAP HANA-Sicherungskatalogs. Darüber hinaus verhindert Anwendungs-Clustering-Software, wie z. B. Pacemaker, Split-Brain-Szenarien, in denen mehrere SAP HANA-Instanzen in einem Cluster davon ausgehen, dass es sich bei ihnen um die primäre Instanz handelt.

Wenn jedoch bei Wartungsaktivitäten das Clustering eventuell deaktiviert wird und die Standby-Datenbank aus der Replikation entfernt und dann wieder online bereitgestellt wird, müssen Sie dafür sorgen, dass Sicherungen nur für die primäre Datenbank ausgelöst werden. Sie können die folgenden Optionen dafür verwenden:

  • Aktualisieren Sie in der Datei PARAMETERS.json den Parameter bucket so, dass er auf einen anderen Cloud Storage-Bucket verweist.
  • Deaktivieren Sie den symbolischen Link für /usr/sap/SID/SYS/global/hdb/opt/hdbbackint, damit das Senden von Sicherungen an Cloud Storage fehlschlägt. Diese Option ist kurzfristig nützlicher, wenn Sie die neue Datenbank als Standby-Datenbank neu konfigurieren möchten.

Da der Google Cloud-Agent für SAP nicht weiß, welche SAP HANA-Instanz die aktive Instanz ist, und da der Agent keinen Mechanismus zum Planen oder Auslösen von Sicherungen hat, müssen Sie SAP-Mechanismen wie die SAP ABAP-Transaktion DB13 zum Verwalten der Planung und der Trigger für Sicherungen verwenden. SAP ABAP-Anwendungen stellen über die virtuelle IP-Adresse eine Verbindung zum HA-Cluster her, sodass der Sicherungstrigger immer an die aktive SAP HANA-Instanz weitergeleitet wird.

Wenn der Sicherungstrigger lokal auf jedem Server definiert ist (z. B. als lokales Betriebssystemskript) und sowohl das primäre als auch das sekundäre System der Meinung sind, dass es sich bei ihnen um das aktive System handelt, versuchen evtl. beide, Sicherungen in den Cloud Storage-Bucket zu schreiben.

Wenn Sie diese Situationen nicht verwalten, kann es vorkommen, dass mehr als eine SAP HANA-Instanz in Ihrem Hochverfügbarkeitscluster Sicherungen in Cloud Storage schreibt. Dadurch können Sicherungen überschrieben oder sogar gelöscht werden.

Backint in DR-Szenarien verwenden

Verwenden Sie in einer Konfiguration für die Notfallwiederherstellung, bei der eine Wiederherstellungsinstanz von SAP HANA in einer anderen Google Cloud-Region mithilfe der asynchronen SAP HANA-Systemreplikation synchronisiert wird, verschiedene Cloud Storage-Buckets für die Sicherung und Wiederherstellungsvorgänge. Geben Sie dazu die Bucket-Namen für die Parameter bucket und recovery_bucket in der Datei PARAMETERS.json an.

Das DR-System befindet sich normalerweise im Replikationsmodus und kann deshalb keine Sicherung selbst ausführen. Während der regelmäßigen Notfallwiederherstellungstests wird die Wiederherstellungsinstanz jedoch online geschaltet und kann Sicherungen auslösen. Wenn dies der Fall ist und für das Wiederherstellungssystem kein anderer Cloud Storage-Bucket verwendet wird, überschreiben die Sicherungen möglicherweise Daten aus der primären Datenbank.

Im Falle eines Notfalls, bei dem eine Sicherung in einer DR-Region wiederhergestellt werden muss, können Sie die Backint-Feature-Konfiguration so aktualisieren, dass sie auf den multiregionalen Cloud Storage-Bucket verweist, den Ihr primäres HA-System verwendet.

Backint in Systemen mit horizontaler Skalierung verwenden

In SAP HANA-Systemen mit horizontaler Skalierung müssen Sie den Agent von Google Cloud für SAP auf jedem Knoten im System installieren.

Sie können diese Dateien in einem freigegebenen NFS-Verzeichnis ablegen, um die Verwaltung der PARAMETERS.json-Dateien sowie des Agent-Dienstkontoschlüssels, wenn Sie einen verwenden, zu vereinfachen.

Informationen von SAP zu Empfehlungen für das Dateisystemlayout für SAP HANA finden Sie in der Anleitung zur Installation und Aktualisierung von SAP HANA für Ihre SAP HANA-Version unter Empfohlenes Dateisystemlayout.