Referenzarchitektur: SAP Business Suite auf SAP HANA in Google Cloud

Übersicht

Dieses Dokument richtet sich an Personen, die Google Cloud als Plattform für die Bereitstellung von SAP Business Suite auf SAP HANA prüfen, insbesondere an Personen mit Funktionen wie den folgenden:

  • 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.

SAP Business Suite auf SAP HANA ist eine Suite von SAP-Systemen (einschließlich SAP ECC), die auf einer SAP HANA-Datenbank ausgeführt wird. ECC (Enterprise Core Component) ist eine Anwendungssuite mit grundlegenden geschäftlichen Funktionen, z. B. für Finanzen, Logistik, Lagerverwaltung sowie Vertrieb und Verteilung. EECC wurde für die Ausführung auf verschiedenen Datenbanken konzipiert, etwa Sybase ASE, MS SQL Server, Oracle und jetzt auch SAP HANA. In diesem Dokument werden nur die Architektur und die Bereitstellung von SAP Business Suite auf der SAP HANA-Datenbank erläutert.

DieGoogle Cloud bietet eine kostengünstige, zuverlässige, sichere und leistungsstarke SAP-zertifizierte Infrastruktur für die Ausführung von SAP Business Suite auf SAP HANA. Eine vollständige Liste der unterstützten SAP-Lösungen in Google Cloud finden Sie unter Zertifizierungen für SAP-Anwendungen in Google Cloud und Zertifizierungen für SAP HANA in Google Cloud.

Lizenzen

Wenn Sie SAP-Kunde sind, können Sie Ihre vorhandenen Lizenzen für SAP HANA und andere SAP-Anwendungen nutzen, um SAP Business Suite nach dem BYOL-Modell (Bring Your Own License, Eigene Lizenz verwenden) in Google Cloud bereitzustellen. 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. Beispiele finden Sie im Verzeichnis für zertifizierte und unterstützte SAP HANA-Hardware und unter SAP-Hinweis 2456432 – SAP-Anwendungen in Google Cloud: Unterstützte Produkte und Google Cloud-Maschinentypen 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.

Unterstützte Maschinentypen

Google Cloud bietet Compute Engine-Instanztypen, die von SAP dahingehend zertifiziert sind, dass sie die Größenanforderungen bei der Bereitstellung von SAP HANA 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, wenn Sie ein Verhältnis von mindestens 6,5 zwischen vCPU und Arbeitsspeicher beibehalten.

Informationen zu den SAPS-Nummern für die virtuellen Compute Engine-Maschinen, die für SAP-Anwendungen zertifiziert sind, finden Sie unter SAP-Hinweis 2456432 – SAP-Anwendungen in Google Cloud Unterstützte Produkte und Google Cloud-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 SAP Business Suite auf SAP HANA

Google Cloud bietet folgende Speichertypen:

  • Nichtflüchtige Speicher für Blockspeicher
    • Nichtflüchtige Standardspeicher (pd-standard): Effizienter und kostengünstiger Blockspeicher, der auf Standardfestplattenlaufwerken (HDD) basiert und sequenzielle Lese-/Schreibvorgänge verarbeitet. Der Speicher ist aber nicht für die Verarbeitung hoher Raten zufälliger Ein-/Ausgabevorgänge pro Sekunde (IOPS) optimiert.
    • SSD (pd-ssd): Zuverlässiger, leistungsstarker Blockspeicher, der auf Solid-State-Laufwerken (SSD) basiert.
    • Abgestimmter Speicher (pd-balanced): Kostengünstiger und zuverlässiger, SSD-basierter Blockspeicher.
    • Extrem (pd-extreme): SSD-basierter Speicher mit höheren maximalen IOPS- und Durchsatzoptionen als pd-ssd, für größere Compute Engine-Maschinentypen. Weitere Informationen finden Sie unter Extrem nichtflüchtige Speicher.
    • Lokale SSDs: Lokaler Hochleistungs-Blockspeicher.
  • Cloud Storage-Buckets: Erschwinglicher Objektspeicher.
  • Filestore-Instanzen: Vollständig verwaltete NFS-Dateiserver in Google Cloud.

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 Hauptmerkmal von nichtflüchtigen Speichern besteht darin, dass sie zum Schutz der Daten automatisch verschlüsselt werden.

Bei der Erstellung weist eine Compute Engine-VM 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.

Die folgenden Tabellen enthalten eine Beschreibung der Linux-Verzeichnisstrukturen einer typischen SAP-Bereitstellung.

Typische Linux-Verzeichnisstruktur für eine generische SAP ABAP-Instanz

Struktur des SAP-Anwendungsverzeichnisses Speichertyp
/sapmntHinweis Nichtflüchtiger Standardspeicher (HDD)
/usr/sap Nichtflüchtiger Standardspeicher (HDD)

Hinweis: In verteilten Deployments kann /sapmnt auch als Netzwerkdateisystem über eine NFS-Lösung bereitgestellt werden, z. B. mit Filestore.

Typische Linux-Verzeichnisstruktur für SAP HANA

SAP HANA-Verzeichnisstruktur Speichertyp
/usr/sap SSD-basierter nichtflüchtiger Speicher
/hana/data SSD-basierter nichtflüchtiger Speicher
/hana/log SSD-basierter nichtflüchtiger Speicher
/hana/sharedHinweis SSD-basierter nichtflüchtiger Speicher
/hanabackupHinweis Nichtflüchtiger Standardspeicher (HDD)

Hinweis: Bei verteilten Bereitstellungen können /hana/shared und /hanabackup auch als Netzwerkdateisystem über eine NFS-Lösung implementiert werden, z. B. mit Filestore.

Erstellen Sie alle Verzeichnisse für SAP HANA- und SAP Business Suite-Instanzen, indem Sie die in den Google Cloud-Bereitstellungsanleitungen beschriebenen Prozesse befolgen. Wir empfehlen die Verwendung von Deployment Manager für die Bereitstellung einer unterstützten und zertifizierten Instanz. Informationen zu den SAP NetWeaver-Bereitstellungsanleitungen finden Sie unter Alle SAP NetWeaver-Anleitungen. Informationen zur SAP HANA-Bereitstellung finden Sie im Bereitstellungsleitfaden für SAP HANA.

Bereitstellung

SAP Business Suite auf SAP HANA besteht aus den folgenden technischen Komponenten:

Anwendungsschicht:

  • ASCS: ABAP SAP Central Services. Enthält die folgenden Komponenten:
    • Nachrichtenserver (Message Server, MS): dient als Kommunikationskanal zwischen Anwendungsservern. Übernimmt außerdem die Lastverteilung.
    • Warteschlangenserver (Enqueue Server, ES): steuert den Sperrmechanismus.
  • 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.
  • WD: Web Dispatcher (optional).
    • Intelligenter Software-Load-Balancer, der HTTP- und HTTPS-Anfragen abhängig vom Anwendungstyp an den PAS und AAS verteilt.

Datenbankschicht:

  • SAP HANA

Bereitstellungsmodelle

Sie können SAP Business Suite auf SAP HANA in Google Cloud in einem von zwei Modellen bereitstellen, entweder in einer zentralisierten Bereitstellung oder in einer verteilten Bereitstellung.

Zentralisierte Bereitstellung

In einer zentralisierten Bereitstellung können Sie SAP Business Suite und die 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 SAP Business Suite auf SAP HANA in einem zentralisierten Bereitstellungsmodell dargestellt. Beachten Sie, dass SAP ASCS, PAS und HANA alle auf derselben Instanz installiert sind.

SAP ASCS, PAS und HANA sind auf einer einzigen VM installiert

Verteilte Bereitstellung

In einer verteilten Umgebung können Sie die SAP Business Suite-Anwendungen und die SAP HANA-Datenbank 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. Jede der zuvor (unter "Bereitstellung") beschriebenen Komponenten der SAP-Anwendungsschicht kann unabhängig auf verschiedenen Instanzen installiert werden.

Optional und abhängig von den geschäftlichen Anforderungen können Sie auch einen oder mehrere weitere Anwendungsserver (AAS) installieren.

Im folgenden Diagramm wird eine Referenzarchitektur für SAP Business Suite auf SAP HANA in einem verteilten Bereitstellungsmodell dargestellt.

SAP Business Suite, PAS und ASCS sind auf einer VM installiert, SAP HANA ist auf einer anderen installiert

SAP Business Suite und die SAP HANA-Datenbank sind auf verschiedenen Compute Engine-Instanzen installiert. Die Datenbank muss mit der von Google Cloud zertifizierten Bereitstellungsmethode installiert werden. Informationen zum Installieren einer SAP HANA-Datenbank für die vertikale oder horizontale Skalierung von SAP HANA finden Sie im Bereitstellungsleitfaden für SAP HANA. Derzeit wird SAP Business Suite auf SAP HANA nur in einem Modell mit Hochskalierung unterstützt.

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:

Hochverfügbarkeit

Ziehen Sie die folgenden Komponenten in Betracht, wenn Sie Hochverfügbarkeit für SAP Business Suite auf SAP HANA benötigen:

  • SAP HANA-Datenbank (HDB)
  • ABAP Central Services (ASCS)
  • Primären Anwendungsserver (PAS)

SAP-HANA-Datenbank: Wir empfehlen die SAP HANA-Systemreplikationslösung (HSR), wenn Hochverfügbarkeit für die Datenbank erzielt werden soll. In diesem Szenario wird die Systemreplikation zwischen dem primären und dem sekundären Knoten konfiguriert. Die Daten werden vom primären auf den sekundären nichtflüchtigen Speicher repliziert. Weitere Informationen finden Sie unter SAP HANA-Systemreplikation konfigurieren im SAP HANA-Administratorhandbuch, das im SAP-Hilfeportal verfügbar ist.

Bei der SAP HANA-Systemreplikation ist der Failover nicht standardmäßig automatisiert. Sie können den Failover mit Clustering auf Betriebssystemebene implementieren. Dort werden Komponentenausfälle verwaltet. Das Clustering umfasst die Verwendung mehrerer Server, Speichergeräte und Verbindungen zur Schaffung eines einzigen hochverfügbaren Systems. Weitere Informationen zum Konfigurieren von HA für SAP HANA finden Sie im Leitfaden zur Planung der Hochverfügbarkeit für SAP HANA.

ABAP Central Services: ASCS besteht aus einem Nachrichtenserver (Message Server, MS) und einem Warteschlangenserver (Enqueue Server, ES). Der Nachrichtenserver dient als Kommunikationskanal zwischen den Anwendungsservern und übernimmt die Lastverteilung, während der Warteschlangenserver den Sperrmechanismus steuert. Es empfiehlt sich, eine Clustering-Lösung einzusetzen, um Hochverfügbarkeit für ASCS zu erzielen. Installieren Sie ABAP Central Services (ASCS) und den Warteschlangenreplikationsdienst (Enqueue Replication Service, ERS) auf dem primären und sekundären Knoten, um Hochverfügbarkeit zu implementieren. Wenn der primäre Knoten ausfällt, wird für den Nachrichtendienst (Message Service, MS) und den Warteschlangendienst (Enqueue Service, ES) automatisch ein Failover zum zweiten Knoten ausgeführt. Sobald der primäre Knoten wieder verfügbar ist, kann ein automatischer oder manueller Failover zum ursprünglichen primären Knoten ausgeführt werden. Weitere Informationen finden Sie in der SUSE-Einrichtungsanleitung für einen SAP ASCS-Hochverfügbarkeitscluster.

Im folgenden Diagramm wird eine Architektur für die Implementierung von HA für ASCS dargestellt.

Auf einer VM werden aktive ASCS und inaktive ERS gehostet, auf einer anderen VM inaktive ASCS und aktive ERS. Das VM-Paar und das ERS-Paar haben jeweils eine eigene VIP.

Primärer Anwendungsserver: Sie können Hochverfügbarkeit für den primären Anwendungsserver erzielen, indem Sie zusätzliche Anwendungsserver (AAS) installieren. Dabei können Sie mehrere AAS installieren, um eine höhere Verfügbarkeit zu ermöglichen. Wenn einer der Anwendungsserver ausfällt, werden alle damit verbundenen Nutzersitzungen beendet. Nutzer können sich jedoch bei den anderen Anwendungsservern anmelden. Google Cloud bietet ein Feature zur Live-Migration, das für PAS HA verwendet werden kann. Weitere Informationen finden Sie unter Live-Migration.

Notfallwiederherstellung

Verwenden Sie die folgenden Methoden, um ein SAP Business Suite auf SAP HANA-System nach einem Notfall wiederherzustellen:

  • SAP HANA-Systemreplikation
  • SAP HANA-Sicherung

SAP HANA-Systemreplikation

Bei DR-Szenarien empfiehlt es sich, das Standby-System in einer anderen Region als das primäre System zu erstellen. Verwenden Sie außerdem die asynchrone Replikation.

Wählen Sie eine SAP HANA-Systemreplikationsoption aus, die am besten für Ihre geschäftlichen Anforderungen in Bezug auf RPOs (Recovery Point Objectives) geeignet ist und Ihren Kosten-Nutzen-Präferenzen entspricht.

Im folgenden Diagramm wird der Replikationsfluss gezeigt. Insbesondere gilt:

  1. Die virtuelle IP-Adresse (VIP) ist so konfiguriert, dass sie nur auf den aktiven Knoten zum Lesen/Schreiben verweist.
  2. In diesem Szenario spielt Knoten 1 die Hauptrolle. Wenn ein Failover ausgelöst wird, übernimmt Knoten 2 und fungiert als primärer Knoten, wobei die virtuelle IP-Adresse auf Knoten 2 verschoben wird.

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

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

Sie können den Cloud Storage Backint-Agent für SAP HANA (Backint-Agent) installieren und die Sicherungsspeicherung so vereinfachen. 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 Sicherungen mit den nativen SAP HANA-Sicherungs- und Wiederherstellungsfunktionen auf nichtflüchtigen Compute Engine-Speichern speichern. Für eine längerfristige Speicherung der Sicherungen eignet sich ein Cloud Storage-Bucket.

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. Sie können die Redo-Logs in regelmäßigen Abständen durch längerfristige Speicherung sichern.

Ab SAP HANA 2.0 müssen Sie SAP HANA Cockpit verwenden, 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.

Ein vollständiger Snapshot von SAP HANA-Daten und Anwendungsdaten wird erstellt. Nachfolgende Snapshots werden inkrementell erstellt.

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
    • 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 vor der Bereitstellung Ihrer SAP-Systeme in Google Cloud die SAP-Hinweise in der folgenden Liste, die für Ihre geplante Konfiguration relevant sind. Prüfen Sie immer in SAP Marketplace, ob es aktualisierte Anleitungen und Hinweise für Produktinstallationen gibt, bevor Sie mit einer SAP-Produktimplementierung fortfahren.