Referenzarchitektur: SAP S/4HANA auf der Google Cloud Platform

Übersicht

Dieses Dokument richtet sich an Personen, die Google Cloud als Plattform für die Bereitstellung von SAP S/4HANA ins Auge fassen, und dabei insbesondere an Mitarbeiter mit folgenden Aufgaben:

  • Technischer SAP-Architekt
  • Cloudarchitekt
  • SAP-Basisadministrator
  • Unternehmensarchitekt

In diesem Dokument werden auch Themen behandelt, die vor der Installation berücksichtigt werden müssen, und es sind Links zu SAP-Hinweisen und anderen Dokumenten aufgeführt, um die Bereitstellung zu vereinfachen.

Google Cloud bietet eine kostengünstige, zuverlässige, sichere und leistungsstarke SAP-zertifizierte Infrastruktur zum Ausführen von SAP S/4HANA auf SAP HANA. Eine vollständige Liste der unterstützten SAP-Lösungen in Google Cloud finden Sie unter SAP auf Google Cloud.

Lizenzen

Als SAP-Kunde können Sie die SAP Business Suite in Google Cloud im Rahmen eines BYOL-Modells (Bring-Your-Own-License, Eigene Lizenz verwenden) mit Ihrer vorhandenen Lizenz bereitstellen. Google Cloud unterstützt das BYOL-Modell sowohl für die Produktion als auch für andere Anwendungsfälle. Die Betriebssystemlizenzen sind in den Compute Engine-Preisen enthalten. Alternativ können Sie auch ein eigenes Betriebssystem-Image und eigene Betriebssystemlizenzen verwenden.

Größe

Abhängig vom Implementierungstyp sind mehrere Größenoptionen verfügbar. Für Greenfield-Implementierungen empfehlen wir die Verwendung des SAP Quick Sizer-Tools. Ausführliche Informationen dazu finden Sie auf der SAP-Seite zur Größenbestimmung. SAP erleichtert die Migration aktueller lokaler Lösungen zu Google Cloud außerdem mit T-Shirt-Größen für spezifische Lösungen und Tools. (Siehe hierzu etwa Verzeichnis für zertifizierte und unterstützte SAP HANA-Hardware und SAP-Anwendungen in Google Cloud: Unterstützte Produkte und Google VM-Typen.) In SAP und Google Cloud werden IOPs (Eingabe- und Ausgabevorgänge pro Sekunde) in unterschiedlichen Einheiten gemessen. Wenden Sie sich an Ihren Systemintegrator, um die Größenanforderungen für SAP in richtig bemessene Google Cloud-Infrastruktur umzusetzen.

Bevor Sie vorhandene Systeme von SAP ECC nach S/4HANA migrieren, empfiehlt SAP, den Bericht /SDF/HDB_SIZING auszuführen, wie im SAP-Hinweis 1872170, Bericht zur Größenbestimmung der Business Suite auf HANA und S/4HANA, beschrieben. Dieser Bericht zur Größenbestimmung analysiert den aktuellen Speicher- und Verarbeitungsbedarf Ihres Quellsystems und enthält Informationen zu den Anforderungen für den Wechsel zu S/4HANA.

Unterstützte Maschinentypen

Google Cloud bietet Compute Engine-Instanztypen, die von SAP dahingehend zertifiziert sind, dass sie die Größenanforderungen bei der Bereitstellung von S/4HANA erfüllen. Weitere Informationen zur Größenbemessung in Google Cloud und zu den unterstützten Maschinentypen finden Sie auf den folgenden Seiten:

Benutzerdefinierte Maschinentypen für SAP HANA in Google Cloud sind ebenfalls von SAP zertifiziert. Sie können SAP HANA-Instanzen mit weniger als 64 vCPUs ausführen, sofern Sie ein Verhältnis von mindestens 6,5 zwischen vCPU und Arbeitsspeicher beibehalten.

Die SAPS-Nummern für die virtuellen Compute Engine-Maschinen, die für SAP-Anwendungen zertifiziert sind, finden Sie unter Zertifizierte Compute Engine-Maschinentypen.

Auf der SAP-Website steht auch eine Liste zertifizierter Google Cloud-Konfigurationen für SAP HANA bereit. Weitere Informationen finden Sie unter Verzeichnis für zertifizierte und unterstützte SAP HANA-Hardware.

Laufwerke und Dateisysteme für S/4HANA

Google Cloud bietet folgende Speichertypen:

  • Nichtflüchtige Standardspeicher (HDD): preisgünstiger Blockspeicher für große Geräte
  • Nichtflüchtige SSD-Speicher: schneller und zuverlässiger Blockspeicher mit hohem IOPS-Wert und niedriger Latenz
  • Lokale SSDs: lokaler Hochleistungs-Blockspeicher
  • Cloud Storage-Buckets: erschwinglicher Objektspeicher

Weitere Informationen dazu finden Sie unter Speicheroptionen.

Die nichtflüchtigen Speicher von Google Cloud sind auf eine lange Lebensdauer ausgelegt. Daten werden redundant gespeichert, um die Datenintegrität zu sichern. Nichtflüchtige Speicher können bis zu 64 TB speichern. Deshalb können Sie große logische Volumes erstellen, ohne Laufwerkarrays verwalten zu müssen. Ein Hauptfeature von nichtflüchtigen Speichern besteht darin, dass sie zum Schutz der Daten automatisch verschlüsselt werden.

Bei der Erstellung weist eine Compute Engine-Instanz standardmäßig ein einziges nichtflüchtiges Root-Laufwerk zu, auf dem sich das Betriebssystem befindet. Sie können der Instanz bei Bedarf weitere Speicheroptionen hinzufügen. Bei SAP-Implementierungen empfehlen wir die Verwendung von nichtflüchtigen Speichern, da diese auf eine lange Lebensdauer ausgelegt sind und Computing-Instanzen wie auf physische Laufwerke auf einem lokalen Computer darauf zugreifen können.

In den folgenden Tabellen sind die Linux-Verzeichnisstrukturen für SAP HANA und ABAP in Google Cloud beschrieben.

SAP HANA-Verzeichnisstruktur Speichertyp
/usr/sap Nichtflüchtiger SSD-Speicher
/hana/data Nichtflüchtiger SSD-Speicher
/hana/log Nichtflüchtiger SSD-Speicher
/hana/shared Nichtflüchtiger SSD-Speicher
/hanabackup Nichtflüchtiger Standardspeicher (HDD)
ABAP-Verzeichnisstruktur Speichertyp
/sapmnt Nichtflüchtiger Standardspeicher (HDD)
/usr/sap/ Nichtflüchtiger Standardspeicher (HDD)

Bereitstellung

SAP S/4HANA besteht aus folgenden technischen Komponenten:

  • SAP HANA
  • PAS: primärer Anwendungsserver
    • Der erste oder einzige Anwendungsserver für das SAP-System.
  • AAS: weiterer Anwendungsserver
    • Wird normalerweise für das Load-Balancing in der Anwendungsschicht bereitgestellt. Sie können mehrere AAS installieren, um auch seitens der Anwendungsschicht eine höhere Verfügbarkeit zu erzielen. Wenn einer der Anwendungsserver ausfällt, werden alle damit verbundenen Nutzersitzungen beendet. Nutzer können sich jedoch bei dem anderen verknüpften AAS neu anmelden.
  • SAP NetWeaver-Gateway
  • Fiori-Front-End
  • WD: Web Dispatcher (optional)
    • Intelligenter Software-Load-Balancer, der HTTP- und HTTPS-Anfragen abhängig vom Anwendungstyp an den PAS und AAS verteilt.

Bereitstellungsmodelle

Sie können S/4HANA in Google Cloud entweder nach dem Modell der zentralisierten oder der verteilten Bereitstellung implementieren.

Verwenden Sie das Bereitstellungsskript, um SAP HANA in einer zentralisierten oder verteilten Bereitstellung zu installieren. Weitere Informationen finden Sie in der SAP HANA-Bereitstellungsanleitung.

Zentralisierte Bereitstellung

In einer zentralisierten Bereitstellung können Sie S/4HANA und die SAP HANA-Datenbank auf derselben Compute Engine-Instanz installieren. Wir empfehlen diesen Ansatz für Umgebungen, die keine Produktionsumgebungen sind, wie Sandbox- und Entwicklungsumgebungen.

Im folgenden Diagramm wird eine Referenzarchitektur für S/4HANA in einem zentralisierten Bereitstellungsmodell dargestellt. Beachten Sie, dass SAP ASCS, PAS, WD und HANA alle auf derselben Instanz installiert sind.

Das Diagramm zeigt ASCS, PAS, Web Dispatcher und HANA auf einer einzigen VM

Verteilte Bereitstellung

In einer verteilten Bereitstellung können Sie die unterschiedlichen Komponenten auf verschiedenen Compute Engine-Instanzen installieren. Wir empfehlen diesen Ansatz für Produktionsumgebungen oder Umgebungen, die eine hohe Rechenleistung für die Verarbeitung hoher Transaktionslasten erfordern.

Im folgenden Diagramm wird eine Referenzarchitektur für S/4HANA in einem verteilten Bereitstellungsmodell dargestellt. Beachten Sie, dass SAP ASCS, PAS, WD und HANA auf verschiedenen Instanzen installiert sind.

Das Diagramm zeigt Web Dispatcher, Fiori, S/4 PAS, ASCS und HANA auf separaten VMs.

Hinweis zu Load-Balancing

In einer verteilten S/4HANA-Umgebung ist das Load-Balancing obligatorisch. Sie können das Load-Balancing von Anwendungen mithilfe der SAP-Anwendungsebene konfigurieren.

Hochverfügbarkeit und Notfallwiederherstellung

Die Hochverfügbarkeit (High Availability, HA) und Notfallwiederherstellung (Disaster Recovery, DR) umfassen jeweils verschiedene Methoden, Entwicklungspraktiken und Entwurfsprinzipien, mit denen bei Ausfällen Geschäftskontinuität ermöglicht wird. Bei diesen Ansätzen werden Single Points of Failure beseitigt und Möglichkeiten geschaffen, den Betrieb nach dem Ausfall einer Komponente mit einer minimalen Unterbrechung der Geschäftsabläufe schnell wieder aufzunehmen. Die Fehlerbehebung umfasst die Wiederherstellung und Fortsetzung des Betriebs nach einem Ausfall infolge einer fehlerhaften Komponente.

Es gibt u. a. HA- und DR-Tools für Folgendes:

Einige weitere Informationen zu einigen dieser Artikel:

Zonenübergreifendes Linux-Clustering: Durch Einrichten eines zonenübergreifenden Linux-Clusters können Sie Komponentenausfälle in einer bestimmten Region vermeiden. Sie können einen Linux-Cluster zonenübergreifend mit einer Aktiv/Passiv-Konfiguration oder einer Aktiv/Aktiv-Konfiguration bereitstellen. In beiden Fällen richten Sie zuerst zwei Compute Engine-Instanzen in separaten Zonen mit jeweils einer eigenen SAP HANA-Datenbank ein.

  • Aktiv/Passiv-Konfiguration: Konfigurieren Sie eine Instanz als primären Knoten des Clusters (aktiv) und die andere als sekundären Knoten (passiv). Verwenden Sie SAP HANA-Systemreplikation (SR), um den sekundären Knoten so zu konfigurieren, dass er bei einem Ausfall des primären Knotens als Primärknoten fungiert (siehe folgende Abbildung). Weitere Informationen zum Konfigurieren und Einrichten von HANA SR finden Sie unter HANA-Systemreplikation.

Ein SAP HANA-HA-Cluster befindet sich in einer GCP-Region. Bei asynchroner Replikation bleibt ein einzelnes HANA-System in einer anderen Region auf dem aktuellen Stand.

Live-Migration: Compute Engine bietet Live-Migration, damit Ihre Compute Engine-Instanzen auch dann ausgeführt werden, wenn ein Hostsystemereignis auftritt, z. B. ein Software- oder Hardware-Update. In dieser Situation migriert Compute Engine Ihre ausgeführte Instanz live auf einen anderen Host in derselben Zone. Ein Neustart Ihrer ausgeführten Instanz erübrigt sich dadurch. Der Mechanismus repliziert den VM-Status der ursprünglichen Instanz. Wenn die neue Instanz gestartet wird, ist bereits der Arbeitsspeicher der ursprünglichen Instanz geladen.

In dem seltenen Fall, dass keine Live-Migration stattfindet, wird die ausgefallene virtuelle Maschine auf der neuen Hardware in derselben Zone automatisch neu gestartet.

Weitere Informationen finden Sie unter Live-Migration.

Sicherung und Wiederherstellung

Erstellen Sie in regelmäßigen Abständen Sicherungen des Anwendungsservers und der Datenbank, damit Sie bei einem Systemausfall, bei Datenbeschädigung oder bei anderen Problemen eine Wiederherstellung durchführen können.

Sicherungen

Für die Sicherung von SAP HANA-Daten stehen Ihnen in Google Cloud verschiedene Möglichkeiten zur Verfügung, wie etwa:

  • Direktes Sichern in Cloud Storage mit dem SAP-zertifizierten Cloud Storage Backint-Agent für SAP HANA (Backint-Agent)
  • Sichern auf nichtflüchtigem Speicher und anschließendes Hochladen der Sicherungen in Cloud Storage
  • Erstellen von Snapshots des gesamten Laufwerks mit dem Verzeichnis "/hanabackup" mit der Compute Engine-Snapshot-Funktion

Cloud Storage Backint-Agent für SAP HANA

Der Backint-Agent ist in die nativen SAP HANA-Sicherungs- und Wiederherstellungsfunktionen integriert. Deshalb können Sie direkt in Cloud Storage sichern und von dort wiederherstellen und benötigen für die Sicherungen keinen nichtflüchtigen Speicher. Weitere Informationen finden Sie im Leitfaden für den SAP HANA-Betrieb.

Informationen zur SAP-Zertifizierung des Cloud Storage Backint-Agents für SAP HANA finden Sie im SAP-Hinweis 2031547.

Das folgende Diagramm zeigt den Sicherungsablauf bei Verwendung des Backint-Agents.

Im Diagramm wird gezeigt, wie in SAP HANA mit dem Backint-Agent eine Sicherung direkt in Cloud Storage erfolgt.

Auf nichtflüchtigen Speichern sichern

Sie können die native SAP HANA-Sicherungs- und Wiederherstellungsfunktion mit nichtflüchtigen Compute Engine-Laufwerken verwenden und einen Cloud Storage-Bucket für die längerfristige Speicherung der Sicherungen verwenden.

Während des normalen Betriebs werden Daten von SAP HANA an regelmäßigen Speicherpunkten automatisch aus dem Arbeitsspeicher auf dem Laufwerk gespeichert. Darüber hinaus werden alle Datenänderungen in Redo-Logeinträgen erfasst. Nach jeder per Commit durchgeführten Datenbanktransaktion wird ein Redo-Logeintrag geschrieben.

Verwenden Sie ab SAP HANA 2.0 das SAP HANA-Cockpit, um SAP HANA zu sichern.

Das folgende Diagramm zeigt den Ablauf bei Verwendung des Sicherungsfeatures für SAP HANA.

Sicherungen werden auf nichtflüchtigem Speicher erstellt und dann in Cloud Storage gespeichert.

Nichtflüchtige Speicher mit Snapshots sichern

Eine weitere Option für Sicherungen ist die Aufnahme von Snapshots ganzer Laufwerke mit dem Compute Engine-Feature für Snapshots von nichtflüchtigem Speicher. Sie können beispielsweise geplante Snapshots des Laufwerks mit dem Sicherungsverzeichnis erstellen und in Notfallwiederherstellungsszenarien verwenden. Erstellen Sie die Snapshots nur dann, wenn keine Änderungen am Ziel-Volume vorgenommen werden, um die Anwendungskonsistenz nicht zu gefährden. Snapshots werden auf Blockebene erstellt.

Nach dem ersten Snapshot werden alle folgenden Snapshots inkrementell erstellt und enthalten lediglich inkrementelle Blockänderungen, wie im folgenden Diagramm dargestellt.

Das Diagramm zeigt vollständige und inkrementelle Snapshots von HANA-Daten auf einem nichtflüchtigen Speicher.

Wiederherstellung

Mit den Wiederherstellungstools in SAP HANA kann eine Wiederherstellung zum letzten oder zu einem bestimmten Zeitpunkt erfolgen. Sie können die Wiederherstellung auf einem neuen System durchführen oder eine Kopie der Datenbank erstellen. Im Gegensatz zu Sicherungen, die Sie ausführen können, während die Datenbank verwendet wird, können Sie Wiederherstellungstools nur verwenden, wenn die Datenbank heruntergefahren worden. Wählen Sie eine geeignete Wiederherstellungsoption aus der folgenden Liste der verfügbaren Optionen aus.

  • Wiederherstellung des letzten Zustands mit einer der folgenden Ressourcen:
    • Vollständige Sicherung bzw. vollständiger Snapshot
    • Logsicherungen
    • Noch verfügbare Redo-Logeinträge
  • Wiederherstellung des Zustands zu einem Zeitpunkt in der Vergangenheit
  • Wiederherstellung des Zustands in einer bestimmten vollständigen Sicherung

Wichtige SAP-Hinweise vor der Bereitstellung

Lesen Sie die folgenden SAP-Hinweise, bevor Sie mit der Bereitstellung von SAP S/4HANA in Google Cloud beginnen. Prüfen Sie vor jeder SAP-Produktimplementierung im SAP Marketplace, ob es aktualisierte Anleitungen und Hinweise für Produktinstallationen gibt.