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.
Architektur
Die folgenden Diagramme zeigen eine allgemeine Ansicht von drei gängigen Bereitstellungsmodellen für SAP S/4HANA: Zentralisiert, Verteilt, und Mit hoher Verfügbarkeit verteilt.
Zentralisierte Bereitstellung
In einer zentralisierten Bereitstellung können Sie SAP 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 SAP S/4HANA auf SAP HANA in einer zentralisierten Bereitstellung dargestellt. SAP ASCS, PAS, WD und die SAP HANA-Datenbank sind alle auf derselben VM-Instanz installiert.
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 SAP S/4HANA in einer verteilten Bereitstellung dargestellt. Beachten Sie, dass SAP ASCS, PAS, WD und HANA auf verschiedenen VW-Instanzen installiert sind.
Verteilte Bereitstellung mit Hochverfügbarkeit
In einer verteilten Bereitstellung mit Hochverfügbarkeit werden Linux-Cluster zonenübergreifend eingerichtet, um Komponentenausfälle in einer bestimmten Region zu 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-VM-Instanzen in separaten Zonen für maximale Redundanz ein, die jeweils eine eigene SAP HANA-Datenbank haben. Das folgende Diagramm zeigt eine SAP S/4HANA-Architektur, die einen Linux-Cluster verwendet, um Hochverfügbarkeit sowohl auf Anwendung als auch auf SAP HANA-Datenbankseite zu erzielen:
Die folgenden Diagramme zeigen eine SAP HANA-Datenbank, die sowohl während des normalen Betriebs als auch während eines Takeover-Vorgangs hochverfügbar ist:
Normaler Betrieb:
Takeover-Vorgang:
Sie können die SAP HANA-Systemreplikation verwenden, um die Hochverfügbarkeit und Notfallwiederherstellung für die Datenbank zu kombinieren. Das folgende Diagramm zeigt eine Kombination aus beiden, um maximale Verfügbarkeit und Fehlertoleranz zu erreichen:
Der Cluster, der die Hochverfügbarkeit verwaltet, umfasst die folgenden Funktionen und Features:
- Zwei Host-VMs mit jeweils einer Instanz von SAP HANA.
- Synchrone SAP HANA-Systemreplikation
- Hochverfügbarkeitsclusterressourcen-Manager von Pacemaker
- Ein Fencing-Mechanismus, der den ausgefallenen Knoten abwehrt.
- Automatischer Neustart der fehlgeschlagenen Instanz als neue sekundäre Instanz
Die Architektur auf der Anwendungsseite ist ähnlich. In diesem Fall verwaltet der Cluster die ABAP SAP Central Services (ASCS) und den Enqueue Replication Server oder Enqueue Replicator (ERS), die verwendet werden, um das SAP S/4HANA-System mit hoher Verfügbarkeit zu versorgen, falls eine der ASCS- und ERS-Instanzen ausfällt.
Je nach verwendeter SAP S/4HANA-Version werden Enqueue Server und Enqueue Replication Server / Enqueue Replicator in einer anderen Version ausgeführt:
- S/4HANA 1709 und früher: ENSA1 und ERS.
- S/4HANA 1809 oder höher: ENSA2 und ERS2.
Das folgende Diagramm zeigt ein SAP S/4HANA-System, das einen Pacemaker-Cluster verwendet, um die Single Points of Failure sowohl vom Message Server als auch vom Enqueue Server zu begrenzen:
Details zur Bereitstellung des Hochverfügbarkeitssystems und zum zonenübergreifenden Linux-Clustering finden Sie weiter unten in diesem Dokument.
Hinweis zu Load-Balancing
In einer verteilten SAP S/4HANA-Umgebung ist das Load-Balancing obligatorisch. Sie können das Load-Balancing von Anwendungen mit einer Kombination aus SAP-Anwendungsebene und Network Load Balancern konfigurieren. Weitere Informationen finden Sie im Abschnitt VIP-Implementierungen für den internen Passthrough-Network Load Balancer im Leitfaden zur Planung der Hochverfügbarkeit für SAP NetWeaver in Google Cloud.
Bereitstellungskomponenten
SAP S/4HANA besteht aus folgenden technischen Komponenten:
- SAP HANA-Datenbank
- ASCS: ABAP SAP Central Services
- Enthält den Message Server und Enqueue Server, die in jedem SAP ABAP-System erforderlich sind.
- Wird entweder auf ihrer eigenen VM-Instanz in Hochverfügbarkeitsbereitstellungen oder auf der VM-Instanz bereitgestellt, auf der der PAS gehostet wird.
- In Hochverfügbarkeitsbereitstellungen werden die ASCS-Ressourcen von einem Linux-Clusterressourcenmanager wie Pacemaker verwaltet.
- ERS: Enqueue Replication Server oder Enqueue Replicator
- Wird in Hochverfügbarkeitsbereitstellungen bereitgestellt, um ein Replikat der Sperrtabelle beizubehalten, falls etwas mit der ASCS-Instanz geschieht.
- Wird von einem Linux-Clusterressourcenmanager wie Pacemaker verwaltet.
- 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-Instanzen installieren, um auch seitens der Anwendungsebene 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
- Wird entweder als eigenständiges System oder als Teil des SAP S/4HANA-Systems bereitgestellt.
- Ermöglicht dem System, Geräte, Umgebungen und Plattformen mithilfe von Open Data Protocol (OData) mit SAP-Systemen zu verbinden.
- SAP Fiori-Frontend-Server
- Wird entweder als eigenständiges System oder als Teil des SAP S/4HANA-Systems bereitgestellt.
- Das ABAP-System SAP Netweaver wird zum Hosten von SAP Fiori-Anwendungen verwendet.
- WD: Web Dispatcher (optional)
- Intelligenter Software-Load Balancer, der HTTP- und HTTPS-Anfragen abhängig vom Anwendungstyp an den PAS und AAS verteilt.
Die folgenden Google Cloud-Dienste werden bei der SAP S/4HANA-Bereitstellung verwendet:
| Dienst | Beschreibung |
|---|---|
| VPC-Netzwerk |
Verbindet Ihre VM-Instanzen miteinander und mit dem Internet. Jede VM gehört entweder zu einem Legacy-Netzwerk mit einem einzelnen globalen IP-Bereich oder zu einem empfohlenen Subnetzwerk. In letzterem Fall gehört die VM-Instanz zu einem einzelnen Subnetzwerk, das wiederum in ein größeres Netzwerk eingebunden ist. Ein VPC-Netzwerk (Virtual Private Cloud) kann nicht mehrere Google Cloud-Projekte umfassen, aber ein Google Cloud-Projekt kann mehrere VPC-Netzwerke haben. Sie können eine freigegebene VPC verwenden, um Ressourcen aus mehreren Projekten mit einem gemeinsamen VPC-Netzwerk zu verbinden. So können die Ressourcen sicher und effizient über die internen IP-Adressen dieses Netzwerks miteinander kommunizieren. Informationen zum Bereitstellen einer freigegebenen VPC, einschließlich Anforderungen, Konfigurationsschritten und Nutzung, finden Sie unter Freigegebene VPC bereitstellen. |
| Compute Engine | Erstellt und verwaltet VMs mit dem Betriebssystem und Softwarepaket Ihrer Wahl. |
| Persistent Disk und Hyperdisk |
Sie können Persistent Disk und Google Cloud Hyperdisk verwenden:
|
| Google Cloud Console |
Browserbasiertes Tool zum Verwalten von Compute Engine-Ressourcen. Mithilfe einer Vorlage können Sie Ihre benötigten Compute Engine-Ressourcen und -Instanzen beschreiben. Die Google Cloud Console übernimmt das Erstellen und Konfigurieren der Ressourcen und kümmert sich außerdem um Abhängigkeiten, sodass Sie dies nicht für jede Ressource einzeln tun müssen. |
| Cloud Storage | Sie können Ihre SAP-Datenbanksicherungen in Cloud Storage speichern, um die Langlebigkeit und Zuverlässigkeit Ihrer Daten durch Replikation weiter zu erhöhen. |
| Cloud Monitoring |
Bietet Einblick in die Bereitstellung, Leistung, Betriebszeit und korrekte Funktion von Compute Engine, Netzwerken und nichtflüchtigem Speicher. Monitoring erfasst Messwerte, Ereignisse und Metadaten von Google Cloud und liefert die daraus gewonnenen Erkenntnisse über Dashboards, Tabellen oder Meldungen. Mit Monitoring können Sie die Messwerte kostenlos überwachen. |
| IAM |
Bietet einheitliche Kontrolle über Berechtigungen für Google Cloud-Ressourcen. Mit IAM steuern Sie, wer Vorgänge auf der Steuerungsebene für Ihre VMs ausführen kann. Dazu gehören das Erstellen, Ändern und Löschen von VMs und nichtflüchtigem Speicher sowie das Erstellen und Ändern von Netzwerken. |
| Filestore |
Leistungsstarker, vollständig verwalteter NFS-Dateispeicher von Google Cloud. Für multizonale Hochverfügbarkeitsbereitstellungen empfehlen wir die Verwendung von Filestore Enterprise mit einem SLA mit einer Verfügbarkeit von 99,99 %. Weitere Informationen zu den Filestore-Dienststufen finden Sie unter Dienststufen. |
| NetApp Cloud Volumes ONTAP |
Eine intelligente Speicherlösung mit komplettem Funktionsumfang, die Sie selbst auf einer Compute Engine-VM-Instanz bereitstellen und verwalten. Weitere Informationen zu NetApp Cloud Volumes OPTAP finden Sie unter Übersicht über Cloud Volumes ONTAP. |
| Google Cloud NetApp Volumes |
Eine vollständig verwaltete NFS- und SMB-Dateispeicherlösung von Google Cloud, die auf NetApp Cloud Volumes ONTAP basiert. Je nach Region können mehrere Dienstebenen zur Auswahl stehen. Weitere Informationen finden Sie unter Dienstebenen. |
Designaspekte
Dieser Abschnitt enthält Anleitungen zur Verwendung dieser Referenzarchitektur, um eine Architektur zu entwickeln, die Ihren spezifischen Anforderungen an Sicherheit, Zuverlässigkeit, operative Effizienz, Kosten und Leistung entspricht.
Netzwerk
Es gibt mehrere Möglichkeiten, ein SAP S/4HANA-System aus Netzwerksicht bereitzustellen, und die Art der Bereitstellung Ihres Netzwerks hat großen Einfluss auf Verfügbarkeit, Robustheit und Leistung. Wie bereits erwähnt, ist eine Virtual Private Cloud (VPC) ein sicheres, isoliertes privates Netzwerk, das in Google Cloud gehostet wird. VPCs sind in Google Cloud global, sodass eine einzelne VPC mehrere Regionen umfassen kann, ohne über das Internet zu kommunizieren.
Bei einer typischen SAP-Bereitstellung werden die Instanzen von HA-Systemen in verschiedenen Zonen derselben Region platziert, um Ausfallsicherheit bei niedriger Latenz zu gewährleisten. Subnetze können sich aufgrund der Google Cloud-Funktionen über mehrere Zonen erstrecken. Diese Funktionen vereinfachen auch das SAP-Clustering, da die virtuelle IP-Adresse (VIP) des Clusters im selben Bereich wie die Instanzen der HA-Systeme liegen kann. Diese Konfiguration schützt die Floating-IP-Adresse mithilfe eines internen Application Load Balancers und gilt für das HA-Clustering der Anwendungsebene (ASCS und ERS) und der SAP HANA-Datenbankebene (primär und sekundär SAP HANA).
Es gibt mehrere Möglichkeiten, Ihr Netzwerk zu erstellen und Ihr SAP S/4HANA-System mit Ihrer Infrastruktur zu verbinden:
Das VPC-Netzwerk-Peering verbindet zwei VPC-Netzwerke, sodass Ressourcen in jedem Netzwerk miteinander kommunizieren können. Die VPC-Netzwerke können im selben Google Cloud-Projekt, in verschiedenen Projekten derselben Organisation oder sogar in verschiedenen Projekten unterschiedlicher Organisationen gehostet werden. Mit dem VPC-Netzwerk-Peering wird eine direkte Verbindung zwischen zwei VPC-Netzwerken hergestellt, die jeweils ihre eigenen Subnetze verwenden. Dies ermöglicht eine private Kommunikation zwischen Ressourcen in den Peering-VPCs.
Eine freigegebene VPC ist ein Feature in Google Cloud, mit dem eine Organisation Ressourcen aus mehreren Projekten mit einem gemeinsamen VPC-Netzwerk verbinden kann. Die Systeme, die eine freigegebene VPC verwenden, können über interne IP-Adressen effizient und sicher kommunizieren. Sie können Netzwerkressourcen wie Subnetze, Routen und Firewalls in einem Hostprojekt zentral verwalten und gleichzeitig die administrativen Aufgaben zum Erstellen und Verwalten einzelner Ressourcen an Dienstprojekte delegieren. Diese Trennung von Belangen vereinfacht die Netzwerkverwaltung und erzwingt konsistente Sicherheitsrichtlinien in der gesamten Organisation.
Für SAP-Systeme wird im Allgemeinen empfohlen, Ressourcen nach Umgebungstyp zu gruppieren. Beispielsweise dürfen Produktionsumgebungen keine Rechenressourcen mit Nicht-Produktionsumgebungen teilen, um eine angemessene Isolation zu ermöglichen. Sie können jedoch eine freigegebene VPC für eine gemeinsame Verbindungsebene zwischen Ihren Projekten verwenden. Sie können auch unabhängige VPCs verwenden und VPC-Peering verwenden, um Projekte zu verbinden.
Beginnen Sie beim Entwerfen Ihres Netzwerks mit einem Hostprojekt, das ein oder mehrere freigegebene VPC-Netzwerke enthält. Sie können weitere Dienstprojekte an ein Hostprojekt anhängen, damit die Dienstprojekte an der freigegebenen VPC teilnehmen können. Je nach Ihren Anforderungen können Sie SAP S/4HANA in einer einzelnen freigegebenen VPC oder in mehreren freigegebenen VPCs bereitstellen. Die beiden Szenarien unterscheiden sich in Bezug auf Netzwerksteuerung, Isolierung der SAP-Umgebung und Netzwerkprüfung:
- Szenario 1: SAP S/4HANA in einer einzelnen freigegebenen VPC bereitstellen Dies vereinfacht die Bereitstellung und reduziert den Verwaltungsaufwand, allerdings auf Kosten einer geringeren Isolation zwischen den Netzwerken.
- Szenario 2: SAP S/4HANA in mehreren freigegebenen VPCs bereitstellen Dies erhöht die Netzwerkisolation und erhöht die Sicherheit, allerdings erhöht sich die Komplexität und der Verwaltungsaufwand.
Es ist auch möglich, einen hybriden Ansatz zu verwenden. Sie können beispielsweise eine freigegebene VPC für die Produktionsumgebung und eine freigegebene VPC für alle Nicht-Produktionsumgebungen verwenden. Weitere Informationen finden Sie im Abschnitt „Netzwerk“ unter Allgemeine Checkliste für SAP in Google Cloud.
Single Points of Failure
Ein SAP S/4HANA-System hat einige häufige Single Points of Failure, die sich auf die Verfügbarkeit des Systems auswirken können:
- SAP Central Services wie Message Server und Enqueue Server
- SAP-Anwendungsserver
- SAP HANA-Datenbank
- SAP Web Dispatcher, wenn als Frontend für den HTTP-/HTTPS-Zugriff auf das System verwendet
- Freigegebenen Speicher wie NFS
Es gibt mehrere Möglichkeiten, die Auswirkungen solcher Single Points of Failure zu reduzieren. Diese Optionen umfassen die Bereitstellung des Systems mit Hochverfügbarkeitslösungen, Replikationsdienste oder die Verwendung anderer Funktionen, die das System vor Ausfällen schützen. Bei der Planung Ihres SAP S/4HANA-Systems sollten Sie solche Single Points of Failure untersuchen und entsprechend planen. In den folgenden Abschnitten dieses Leitfadens finden Sie eine Übersicht über die alternativen Lösungen, mit denen Sie Single Points of Failure verwalten können:
- Verfügbarkeit und Kontinuität
- Bereitstellungsarchitektur für SAP HANA
- Bereitstellungsarchitektur für SAP S/4HANA
Verfügbarkeit und Kontinuität
In der Planungsphase der Implementierung eines SAP S/4HANA-Systems müssen Sie die folgenden Datenpunkte angeben, um die Verfügbarkeit und Kontinuität des Systems zu definieren:
- Service Level Objectives (SLO): Ein Zielwert oder ein Wertebereich für ein Service Level, der von einem Service Level Indicator (SLI) gemessen wird. Beispiel: Leistung, Verfügbarkeit und Zuverlässigkeit.
- Service Level Indicators (SLI): Messwerte wie die Latenz, mit denen die Leistung eines Dienstes gemessen wird. Es handelt sich um ein sorgfältig definiertes quantitatives Maß für einen bestimmten Aspekt des bereitgestellten Service-Levels.
- Service Level Agreement (SLA): Ein Dienstvertrag zwischen zwei Parteien (Anbieter, Kunde), der eine Vereinbarung über den bereitgestellten Dienst in messbaren Bedingungen definiert, die als Service Level Objectives (SLOs) bezeichnet werden.
- Recovery Time Objective (RTO): Die maximal zulässige Dauer zwischen einem Datenverlust und seiner Risikominderung.
- Recovery Point Objective (RPO): Das Recovery Point Objective (RPO) ist die maximale Datenmenge, die verloren gehen kann, gemessen im zeitlichen Verlauf, ohne wesentlichen Schaden zu verursachen. In der Praxis entspricht dies dem Zeitpunkt, zu dem der Status der betroffenen Daten nach einem Datenverlust wiederhergestellt werden muss.
Abhängig von den Datenpunkten und den vereinbarten Werten zwischen allen Beteiligten stützt sich das SAP S/4HANA-System auf Funktionen wie Hochverfügbarkeit oder Notfallwiederherstellung:
- Hochverfügbarkeit (High Availability, HA): Die Fähigkeit eines Systems, das das Ziel der Geschäftskontinuität unterstützt und gleichzeitig dafür sorgt, dass Daten und Dienste für Nutzer bei Bedarf verfügbar sind. Die übliche Methode, diese Funktion zu erreichen, ist die Aktivierung von Redundanz, einschließlich Hardwareredundanz, Netzwerkredundanz und Rechenzentrumsredundanz.
- Notfallwiederherstellung (Disaster Recovery, DR): Die Fähigkeit eines Systems, durch zuverlässige und vorhersehbare Wiederherstellungsmethoden auf einer anderen Hardware und/oder einem anderen physischen Standort vor ungeplanten Ausfällen zu schützen.
Sowohl Hochverfügbarkeit als auch Notfallwiederherstellung sind kompatibel, decken jedoch unterschiedliche Fälle und Situationen ab. Mit einer HA-Lösung können Sie beispielsweise den Betrieb fortsetzen, wenn eines der Elemente des Systems ungeplante Ausfallzeiten oder Ausfälle aufweist, ohne dass es zu einer Unterbrechung für Ihre Nutzer kommt. Dasselbe gilt für eine DR-Lösung, mit der Ausnahme, dass eine Unterbrechung ab dem Zeitpunkt des Ausfalls auftritt, bis die DR-Lösung die fehlerhaften Elemente des Systems an einem anderen Standort startet.
Die folgenden Abschnitte bieten einen Überblick über die verschiedenen Optionen, die Sie bei der Planung und Bereitstellung eines SAP S/4HANA-Systems in Google Cloud haben.
Unterstützte Maschinentypen für SAP S/4HANA
Google Cloud bietet Compute Engine VM-Instanztypen, die von SAP dahingehend zertifiziert sind, dass sie die Größenanforderungen bei der Bereitstellung von SAP S/4HANA erfüllen. Weitere Informationen zur Größenbestimmung in Google Cloud und zu den unterstützten Maschinentypen finden Sie in den folgenden Dokumenten:
- Unterstützte Maschinentypen für SAP HANA in Google Cloud.
- Unterstützte Maschinentypen für SAP NetWeaver in Google Cloud.
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 1: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.
Regionen und Zonen planen
Wenn Sie eine VM bereitstellen, müssen Sie eine Region und eine Zone auswählen. Eine Region ist ein bestimmter Standort, an dem Sie Ihre Ressourcen ausführen können. Sie entspricht einem oder mehreren Rechenzentrumsstandorten, die sich in großer Nähe zueinander befinden. Jede Region hat eine oder mehrere Zonen mit redundanter Konnektivität, Stromversorgung und Kühlung.
Der Zugriff auf globale Ressourcen wie vorkonfigurierte Laufwerk-Images und Laufwerk-Snapshots kann regions- und zonenübergreifend erfolgen. Auf regionale Ressourcen wie statische externe IP-Adressen können nur Ressourcen zugreifen, die sich in derselben Region befinden. Zonale Ressourcen wie VMs und Laufwerke sind nur für Ressourcen zugänglich, die in derselben Zone angesiedelt sind. Weitere Informationen finden Sie unter Globale, regionale und zonale Ressourcen.
Berücksichtigen Sie bei der Auswahl einer Region und Zone für Ihre VMs Folgendes:
- Den Standort der Nutzer und der internen Ressourcen, beispielsweise des Rechenzentrums oder Unternehmensnetzwerks. Wählen Sie zum Reduzieren der Latenz einen Standort aus, der sich in unmittelbarer Nähe Ihrer Nutzer und Ressourcen befindet.
- Die für diese Region und Zone verfügbaren CPU-Plattformen. Beispielsweise werden die Broadwell-, Haswell-, Skylake- und Ice Lake-Prozessoren von Intel für Arbeitslasten von SAP NetWeaver in Google Cloud unterstützt.
- Weitere Informationen finden Sie im SAP-Hinweis SAP-Hinweis 2456432 – SAP-Anwendungen in Google Cloud: Unterstützte Produkte und Google Cloud-Maschinentypen.
- Informationen dazu, für welche Regionen die Haswell-, Broadwell-, Skylake- und Ice Lake-Prozessoren zur Verwendung mit Compute Engine verfügbar sind, finden Sie unter Verfügbare Regionen und Zonen.
- Prüfen Sie, ob sich Ihr SAP-Anwendungsserver und Ihre Datenbank in derselben Region befinden.
Speicheroptionen für SAP S/4HANA
Im Folgenden sind die von Google Cloud angebotenen Speicheroptionen aufgeführt, die von SAP für die Verwendung mit SAP S/4HANA und SAP HANA zertifiziert sind.
Allgemeine Informationen zu Speicheroptionen in Google Cloud finden Sie unter Speicheroptionen.
Persistent Disk
- Standard Persistent Disk (
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. - Nichtflüchtiger SSD-Speicher (
pd-ssd): bietet zuverlässigen, leistungsstarken Blockspeicher, der von Solid-State-Laufwerken (SSD) unterstützt wird. -
Balanced Persistent Disk (
pd-balanced): bietet kostengünstigen und zuverlässigen SSD-basierten Blockspeicher. - Extreme Persistent Disk (
pd-extreme): SSD-basiert; bietet höhere maximale IOPS- und Durchsatzoptionen alspd-ssdfür größere Compute Engine-Maschinentypen. Weitere Informationen finden Sie unter Extrem nichtflüchtige Speicher.
Hyperdisk
Hyperdisk Extreme (
hyperdisk-extreme) bietet höhere IOPS- und Durchsatzoptionen als SSD-basierte Persistent Disk-Typen. Sie wählen die Leistung aus, die durch die Bereitstellung von IOPS benötigt wird, wodurch der Durchsatz bestimmt wird. Es empfiehlt sich, die Verzeichnisse/hana/dataund/hana/logzu hosten. Weitere Informationen finden Sie unter Informationen zu Google Cloud Hyperdisk.Hyperdisk Balanced (
hyperdisk-balanced): Die beste Lösung für die meisten Arbeitslasten. Wir empfehlen diese Option für die Verwendung mit Datenbanken, die nicht die Leistung von Hyperdisk Extreme erfordern. Durch die Bereitstellung der IOPS und des Durchsatzes wählen Sie die gewünschte Leistung aus. Sie können Hyperdisk Balanced-Volumes verwenden, um die Verzeichnisse/hana/dataund/hana/logzu hosten. Weitere Informationen finden Sie unter Informationen zu Google Cloud Hyperdisk.
Persistent Disk und Hyperdisk sind auf eine lange Lebensdauer ausgelegt. Daten werden redundant gespeichert, um die Datenintegrität zu sichern. Jede Persistent Disk können bis zu 64 TB speichern. Deshalb können Sie große logische Volumes erstellen, ohne Laufwerkarrays verwalten zu müssen. Hyperdisk-Volumes bieten auch bis zu 64 TB Speicherplatz, je nach verwendetem Typ. Ein Hauptfeature besteht darin, dass Persistent Disk- und Hyperdisk-Volumes zum Schutz der Daten automatisch verschlüsselt werden.
Bei der Erstellung weist eine Compute Engine-VM-Instanz standardmäßig eine einzige nichtflüchtige Root-Persistent Disk oder Hyperdisk zu, auf der sich das Betriebssystem befindet. Sie können der VM-Instanz bei Bedarf weitere Speicheroptionen hinzufügen.
Prüfen Sie für SAP-Implementierungen die empfohlenen Speicheroptionen in der SAP-Verzeichnisstruktur und den Speicheroptionen.
Dateifreigabelösungen
In Google Cloud sind verschiedene Dateifreigabelösungen verfügbar, darunter:
- Filestore: Leistungsstarker, vollständig verwalteter NFS-Dateispeicher von Google Cloud mit regionaler Verfügbarkeit.
- Google Cloud NetApp Volumes: Eine vollständig verwaltete NFS- oder SMB-Dateispeicherlösung von Google Cloud.
- NetApp Cloud Volumes ONTAP: Eine intelligente Speicherlösung mit vollem Funktionsumfang, die Sie selbst auf einer Compute Engine-VM bereitstellen und verwalten.
- NetApp Cloud Volumes-Dienst für Google Cloud: Eine leistungsstarke, vollständig verwaltete Dateispeicherlösung von NetApp, die Sie über die Google Cloud Console bereitstellen können.
Weitere Informationen zu den Dateifreigabelösungen für SAP S/4HANA in Google Cloud finden Sie unter Dateifreigabelösungen für SAP in Google Cloud.
Cloud Storage für die Objektspeicherung
Cloud Storage ist ein Objektspeicher für Dateien beliebigen Typs oder Formats. Der Speicher ist praktisch unbegrenzt und Sie müssen sich keine Gedanken über die Bereitstellung oder das Hinzufügen weiterer Kapazitäten machen. Ein Objekt in Cloud Storage enthält Dateidaten sowie die zugehörigen Metadaten und kann bis zu 5 Terabyte groß sein. In einem Cloud Storage-Bucket können beliebig viele Objekte gespeichert werden.
Cloud Storage wird üblicherweise zum Speichern von Sicherungsdateien für nahezu jeden Zweck verwendet. Cloud Storage eignet sich beispielsweise gut für die Speicherung von SAP HANA-Datenbanksicherungen. Informationen zur Planung der Datenbanksicherung finden Sie unter Datenbanksicherung und -wiederherstellung. Sie können Cloud Storage auch als Teil eines Migrationsprozesses nutzen.
Darüber hinaus können Sie den Backup- und DR-Dienst als zentrale Lösung für Sicherungs- und Notfallwiederherstellungsvorgänge verwenden. Dieser Dienst unterstützt ein breites Spektrum von Datenbanken, einschließlich SAP HANA. Weitere Informationen finden Sie unter Sicherungs- und Notfallwiederherstellungslösungen mit Google Cloud.
Die Wahl der Cloud Storage-Option sollte darauf basieren, wie häufig Sie auf die Daten zugreifen möchten. Wählen Sie für häufigen Zugriff, z. B. mehrmals im Monat, die Klasse „Standard Storage“ aus. Bei seltenem Zugriff sollten Sie sich für Nearline oder Coldline Storage entscheiden. Wählen Sie für archivierte Daten, auf die Sie wahrscheinlich nicht zugreifen werden, Archive Storage aus.
SAP-Verzeichnisstruktur und -Speicheroptionen
In den folgenden Tabellen sind die Linux-Verzeichnisstrukturen für SAP HANA-Datenbanken und SAP ABAP-Instanzen in Google Cloud beschrieben.
Empfohlene Speicheroptionen für die Linux-Verzeichnisstruktur auf SAP HANA:
SAP HANA-Verzeichnis Empfohlene Speicheroption in Google Cloud /usr/sapAbgestimmter nichtflüchtiger Speicher /hana/dataSSD-basierte Persistent Disk oder Hyperdisk /hana/logSSD-basierte Persistent Disk oder Hyperdisk /hana/shared*Abgestimmter nichtflüchtiger Speicher /hanabackup*Abgestimmter nichtflüchtiger Speicher Bei verteilten Bereitstellungen können
/hana/sharedund/hanabackupauch als Netzwerkdateisystem über eine NFS-Lösung implementiert werden, z. B. mit Filestore.Informationen zum nichtflüchtigen Speicher, den SAP für die Verwendung mit SAP HANA zertifiziert hat, finden Sie unter Nichtflüchtiger Speicher für SAP HANA.
Empfohlene Speicheroptionen für die Linux-Verzeichnisstruktur auf der SAP ABAP-Instanz:
Verzeichnis Empfohlene Speicheroption in Google Cloud /sapmnt†Abgestimmter nichtflüchtiger Speicher /usr/sapAbgestimmter nichtflüchtiger Speicher In verteilten Deployments kann
/sapmntauch als Netzwerkdateisystem über eine NFS-Lösung bereitgestellt werden, z. B. mit Filestore.Informationen zum nichtflüchtigen Speicher, den SAP für die Verwendung mit SAP ABAP-Instanzen zertifiziert hat, finden Sie unter Nichtflüchtiger Speicher für SAP-Anwendungen.
Betriebssystemunterstützung für SAP S/4HANA
Wenn Sie ein Betriebssystem für SAP NetWeaver in Google Cloud auswählen, müssen Sie nicht nur bestätigen, dass die Betriebssystemversion von SAP zertifiziert ist, sondern auch, dass mit SAP, dem Betriebssystemanbieter und Google Cloud alle drei Unternehmen die Betriebssystemversion unterstützen.
Berücksichtigen Sie dabei auch Folgendes:
- Ob eine bestimmte Betriebssystemversion von Google Cloud verfügbar ist. Die von Compute Engine bereitgestellten Betriebssystem-Images sind für die Verwendung mit Google Cloud konfiguriert. Wenn kein Betriebssystem von Google Cloud verfügbar ist, können Sie ein eigenes Betriebssystem-Image (BYOI) und eine eigene Lizenz verwenden. BYOI-Betriebssystem-Images werden von Compute Engine als benutzerdefinierte Images bezeichnet.
- Verfügbare Lizenzierungsoptionen für eine bestimmte Betriebssystemversion. Prüfen Sie, ob die Betriebssystemversion eine On-Demand-Lizenzierungsoption hat oder ob Sie ein eigenes Abo (BYOS) vom Betriebssystemanbieter nutzen müssen.
- Ob die integrierten Hochverfügbarkeitsfunktionen einer bestimmten Betriebssystemversion für Google Cloud aktiviert sind.
- Die Option „Rabatt für zugesicherte Nutzung” für Images von SLES für SAP und RHEL für SAP.
Die folgenden Betriebssysteme sind von SAP für die Verwendung mit SAP NetWeaver in Google Cloud zertifiziert:
Weitere Informationen zu bestimmten Betriebssystemversionen und zu ihrer Kompatibilität mit SAP S/4HANA und SAP HANA finden Sie in den folgenden Anleitungen:
- Betriebssystemsupport für SAP NetWeaver in Google Cloud
- Betriebssystemsupport für SAP HANA in Google Cloud
Option Fast Restart für SAP HANA
Für SAP HANA 2.0 SP04 und höher wird von Google Cloud dringend die Option Fast Restart SAP HANA empfohlen.
Diese Option wird automatisch aktiviert, wenn Sie SAP HANA mit den folgenden von Google Cloud bereitgestellten Terraform-Modulen bereitstellen: Modul sap_hana oder sap_hana_ha, Version 202309280828 oder höher. Informationen zum manuellen Aktivieren von SAP HANA Fast Restart finden Sie unter SAP HANA Fast Restart aktivieren.
SAP HANA Fast Restart verkürzt die Neustartzeit, wenn SAP HANA beendet wird, das Betriebssystem jedoch weiter ausgeführt wird. Um die Neustartzeit zu verkürzen, nutzt SAP HANA die nichtflüchtige Speicherfunktion von SAP HANA, um Hauptdatenfragmente MAIN von Spaltenspeichertabellen in DRAM beizubehalten, die dem tmpfs-Dateisystem zugeordnet sind.
Darüber hinaus verbessert SAP HANA Fast Restart auf VMs der Familien M2 und M3 der speicheroptimierten Maschinentypen von Compute Engine die Wiederherstellungszeit, falls nicht behebbare Fehler im Speicher auftreten. Weitere Informationen finden Sie unter SAP HANA Fast Restart-Option.
Bereitstellungsarchitektur für SAP HANA
SAP HANA ist eine wichtige Komponente eines beliebigen SAP S/4HANA-Systems, da es als Datenbank für das System dient. Es gibt zwei mögliche Architekturen, die Sie beim Bereitstellen der SAP HANA-Datenbank verwenden können: vertikale und horizontale Skalierung.
Vertikal skalierende Architektur
Folgendes Diagramm zeigt eine vertikal skalierende Architektur für SAP HANA in Google Cloud. Achten Sie im Diagramm auf die Bereitstellung in Google Cloud und auf das Laufwerkslayout. Sie können Ihre lokalen Sicherungen, die in /hanabackup verfügbar sind, mit Cloud Storage speichern. Dieses bereitgestellte Verzeichnis muss mindestens so groß sein wie das bereitgestellte Datenverzeichnis.
Architektur mit horizontaler Skalierung
Die Architektur mit horizontaler Skalierung für SAP HANA besteht aus einem Master-Host, mehreren Worker-Hosts und optional einem oder mehreren Standby-Hosts. Die Hosts sind über ein Netzwerk miteinander verbunden, das das Senden von Daten zwischen Hosts mit Raten von bis zu 32 Gbit/s oder bis zu 100 Gbit/s auf ausgewählten Maschinentypen mit Netzwerken mit hoher Bandbreite unterstützt.
Mit steigender Arbeitslast, insbesondere bei Verwendung von OLAP (Online Analytical Processing), kann eine Architektur mit horizontaler Skalierung und mit mehreren Hosts die Last auf alle Hosts verteilen.
Folgendes Diagramm zeigt eine horizontal skalierende Architektur für SAP HANA in Google Cloud:
Bereitstellungsarchitektur für SAP S/4HANA
Wie im Abschnitt Architektur erwähnt, gibt es mehrere Bereitstellungsarchitekturen, die Sie für die Bereitstellung von SAP S/4HANA in Google Cloud verwenden können.
Zweistufige Architektur
Diese Architektur wird im Abschnitt Zentralisierte Bereitstellung dargestellt. Im folgenden Diagramm sind einige Details einer zweistufigen Architektur für SAP S/4HANA dargestellt, die auf einer Compute Engine-VM ausgeführt wird:
Dreistufige Architektur
Diese Architektur wird im Abschnitt Verteilte Bereitstellung dargestellt. Sie können diese Architektur verwenden, um hochverfügbare SAP S/4HANA-Systeme bereitzustellen. Im folgenden Diagramm sind einige Details einer dreistufigen Architektur für SAP S/4HANA dargestellt, die auf Compute Engine-VMs ausgeführt wird:
In dieser Architektur verteilt das SAP S/4HANA-System die Arbeit auf mehrere NetWeaver Application Server (AS), die jeweils auf einer separaten VM gehostet werden. Alle NetWeaver AS-Knoten nutzen dieselbe Datenbank, die auf einer separaten VM gehostet wird. Sie greifen alle auf ein von ihnen bereitgestelltes, freigegebenes Dateisystem zu, auf dem die SAP NetWeaver-Profile gehostet werden. Dieses freigegebene Dateisystem wird auf einem Persistent Disk-Volume gehostet, das von allen Knoten oder auf einer unterstützten Dateifreigabelösung gemeinsam genutzt wird.
Sicherheit, Datenschutz und Compliance
Dieser Abschnitt enthält Informationen zu Sicherheit, Datenschutz und Compliance für die Ausführung von SAP S/4HANA in Google Cloud.
Compliance und Steuerung der Datenhoheit
Wenn Ihre SAP-Arbeitslast die Anforderungen an den Datenstandort, die Zugriffssteuerung oder die Supportmitarbeiter oder gesetzliche Anforderungen erfüllen muss, müssen Sie Assured Workloads verwenden. Dieser Dienst unterstützt Sie bei der Ausführung sicherer und konformer Arbeitslasten in Google Cloud, ohne die Cloud-Funktionen zu beeinträchtigen. Weitere Informationen finden Sie unter Compliance und Steuerung der Datenhoheit für SAP in Google Cloud.
Netzwerke und Sicherheit
Beachten Sie die Informationen in den folgenden Abschnitten, wenn Sie das Netzwerk und die Sicherheit planen.
Modell der geringsten Berechtigung
Eine der wichtigsten Sicherheitsmaßnahmen besteht darin, den Zugang zu Ihrem Netzwerk und Ihren VMs zu beschränken. Dazu verwenden Sie VPC-Firewallregeln. Der gesamte Traffic an VMs, auch der von anderen VMs, wird standardmäßig von der Firewall blockiert, sofern Sie keine Regeln erstellen, die den Zugriff zulassen. Die einzige Ausnahme hiervon ist das Standardnetzwerk, das für jedes Projekt automatisch erstellt wird und Standardfirewallregeln besitzt.
Mithilfe von VPC-Firewallregeln können Sie den gesamten Traffic mit einem bestimmten Satz von Ports auf bestimmte Quell-IP-Adressen beschränken. Folgen Sie dem Modell der geringsten Berechtigung, um den Zugriff auf die jeweiligen IP-Adressen, Protokolle und Ports zu beschränken, die zugänglich sein müssen. Sie sollten beispielsweise immer einen Bastion Host einrichten und SSH-Verbindungen zum SAP NetWeaver-System nur von diesem Host aus zulassen.
Benutzerdefinierte Netzwerke und Firewallregeln
Mithilfe eines Netzwerks können Sie eine Gateway-IP-Adresse und den Netzwerkbereich für die mit diesem Netzwerk verbundenen VMs definieren. Alle Compute Engine-Netzwerke nutzen das Protokoll IPv4. Für jedes Google Cloud-Projekt wird ein Standardnetzwerk mit vordefinierten Konfigurationen und Firewallregeln bereitgestellt. Wir empfehlen jedoch, ein benutzerdefiniertes Subnetzwerk hinzuzufügen und Firewallregeln auf der Grundlage des Modells der geringsten Berechtigungen hinzuzufügen. Standardmäßig hat ein neu erstelltes Netzwerk keine Firewallregeln und somit keinen Netzwerkzugriff.
Möglicherweise sollten Sie mehr als ein Subnetzwerk hinzufügen, wenn Sie Teile Ihres Netzwerks isolieren oder andere Anforderungen erfüllen möchten. Weitere Informationen finden Sie unter Netzwerke und Subnetze.
Die Firewallregeln gelten für das gesamte Netzwerk und alle VMs im Netzwerk. Sie können eine Firewallregel erstellen, die den Traffic zwischen VMs im selben Netzwerk und über Subnetzwerke hinweg zulässt. Außerdem haben Sie die Möglichkeit, Firewalls mithilfe von Netzwerk-Tags auf bestimmte Ziel-VMs zu konfigurieren.
SAP benötigt Zugriff auf bestimmte Ports. Fügen Sie daher Firewallregeln hinzu, um den Zugriff auf die von SAP angegebenen Ports zu ermöglichen.
Routen
Routen sind globale Ressourcen, die mit einem einzelnen Netzwerk verbunden sind. Von Nutzern erstellte Routen gelten für alle VMs in einem Netzwerk. Sie können also eine Route erstellen, die Traffic ohne erforderliche externe IP-Adresse von VM zu VM innerhalb desselben Netzwerks und über Subnetzwerke weiterleitet.
Für den externen Zugriff auf Internetressourcen starten Sie eine VM ohne externe IP-Adresse und konfigurieren eine weitere virtuelle Maschine als NAT-Gateway. Dieser Konfiguration müssen Sie das NAT-Gateway als Route für Ihre SAP-Instanz hinzufügen.
Bastion Hosts und NAT-Gateways
Wenn Ihre Sicherheitsrichtlinien echte interne VM-Instanzen vorschreiben, müssen Sie manuell einen NAT-Proxy für Ihr Netzwerk und eine entsprechende Route einrichten, damit VMs Zugriff auf das Internet haben. Sie können über SSH keine direkte Verbindung zu einer vollständig internen VM-Instanz herstellen.
Zum Herstellen einer Verbindung zu solchen internen VMs müssen Sie eine Bastion-Instanz mit einer externen IP-Adresse einrichten und den Traffic dann darüber leiten. Wenn VMs keine externen IP-Adressen haben, können sie nur von anderen VMs im Netzwerk oder über ein verwaltetes VPN-Gateway erreicht werden. VMs lassen sich in Ihrem Netzwerk als vertrauenswürdige Relais für eingehende Verbindungen (Bastion Hosts) oder ausgehenden Netzwerktraffic (NAT-Gateways) bereitstellen. Wenn Sie mehr Verbindungstransparenz ohne Einrichtung solcher Verbindungen benötigen, können Sie eine verwaltete VPN-Gateway-Ressource verwenden.
Bastion Hosts für eingehende Verbindungen
Bastion Hosts stellen einen Zugangspunkt von außen in ein Netzwerk mit privaten Netzwerk-VMs dar. Dieser Host kann als ein einziger Verteidigungs- oder Prüfpunkt des Netzwerkschutzes dienen und gestartet und gestoppt werden, um die eingehende SSH-Kommunikation aus dem Internet zu aktivieren oder zu deaktivieren.
Wenn Sie zuerst eine Verbindung zu einem Bastion Host herstellen, erhalten Sie SSH-Zugriff auf VMs, die keine externe IP-Adresse haben. Die vollständige Härtung eines Bastion-Hosts ist in diesem Artikel nicht vorgesehen, einige der ersten Schritte können jedoch folgende sein:
- Einschränkung des CIDR-Bereichs der Quell-IPs, die mit dem Bastion-Host kommunizieren können.
- Konfigurieren von Firewallregeln, um nur SSH-Traffic an private VMs zuzulassen, der vom Bastion Host kommt.
SSH ist auf VMs standardmäßig so konfiguriert, dass private Schlüssel für die Authentifizierung verwendet werden. Bei Verwendung eines Bastion Hosts melden Sie sich zuerst beim Bastion Host und dann bei der privaten Ziel-VM an. Aufgrund dieser zweistufigen Anmeldung empfehlen wir die Verwendung der SSH-Agent-Weiterleitung, um die Ziel-VM zu erreichen, anstatt den privaten Schlüssel der Ziel-VM auf dem Bastion Host zu speichern. Sie müssen auch so vorgehen, wenn Sie dasselbe Schlüsselpaar für den Bastion Host und die Ziel-VMs verwenden, da der Bastion Host nur auf die öffentliche Hälfte des Schlüsselpaars direkten Zugriff hat.
NAT-Gateways für die ausgehende Datenübertragung
Wenn einer VM keine externe IP-Adresse zugewiesen wurde, kann sie keine direkte Verbindung zu externen Diensten herstellen, einschließlich anderer Google Cloud-Dienste. Wenn für diese VMs Dienste im Internet erreichbar sein sollen, müssen Sie ein NAT-Gateway einrichten und konfigurieren. Das NAT-Gateway ist eine VM, die Traffic im Namen jeder anderen VM im Netzwerk weiterleiten kann. Verwenden Sie ein NAT-Gateway pro Netzwerk. Ein aus einer einzelnen VM bestehendes NAT-Gateway sollte nicht als hochverfügbar angesehen werden und kann keinen hohen Trafficdurchsatz für mehrere VMs unterstützen. Informationen zur Einrichtung einer VM als NAT-Gateway finden Sie in der Bereitstellungsanleitung für das jeweilige Betriebssystem:
- Bereitstellungsleitfaden für SAP NetWeaver unter Linux
- Bereitstellungsleitfaden für SAP NetWeaver unter Windows
Cloud VPN
Mit einer VPN und IPsec können Sie über Cloud VPN eine sichere Verbindung von Ihrem vorhandenen Netzwerk zu Google Cloud herstellen. Der Traffic zwischen den beiden Netzwerken ist durch ein VPN-Gateway verschlüsselt und wird anschließend von dem anderen VPN-Gateway wieder entschlüsselt. Dies schützt Ihre Daten bei der Übertragung. Mithilfe von Instanztags auf Routen lässt sich dynamisch steuern, welche VMs Traffic über das VPN senden können. Cloud VPN-Tunnel werden bei gleichbleibendem Preis monatlich berechnet. Hinzu kommen die Standardgebühren für die ausgehende Datenübertragung. Diese fallen auch dann an, wenn Sie zwei Netzwerke im selben Projekt miteinander verbinden und die üblichen Gebühren für ausgehende Datenübertragungen anfallen. Weitere Informationen finden Sie unter:
Sicherheit für Cloud Storage-Buckets
Wenn Sie Ihre Daten- und Log-Volumes in Cloud Storage hosten, sollten Sie für die Datenübertragung von Ihren VMs zu Cloud Storage unbedingt TLS (HTTPS) verwenden, um die Daten während der Übertragung zu schützen.
Cloud Storage verschlüsselt inaktive Daten automatisch. Sie können aber auch eigene Verschlüsselungsschlüssel angeben, wenn Sie mit einem eigenen Schlüsselverwaltungssystem arbeiten.
Limits für E-Mail-Benachrichtigungen
Zum Schutz Ihrer Systeme und der Systeme von Google vor Missbrauch, erzwingt Google Cloud Einschränkungen beim Senden von E-Mails über Compute Engine. Dies hat Auswirkungen auf die SCOT-Transaktion auf SAP NetWeaver-ABAP-Systemen, da dafür im Vergleich zu lokalen Systemen eine bestimmte Konfiguration erforderlich ist.
Weitere Informationen, einschließlich Informationen zum Konfigurieren von SCOT, finden Sie unter E-Mails von einer Instanz senden.
Zugehörige Dokumente zum Thema Sicherheit
Weitere Informationen zu Sicherheitsressourcen für Ihre SAP-Umgebung in Google Cloud finden Sie hier:
- Sicher mit VM-Instanzen verbinden
- Sicherheitscenter
- Compliance in Google Cloud
- Sicherheit bei Google
- PDF: Übersicht über das Sicherheitsdesign der Infrastruktur von Google
Zuverlässigkeit
Dieser Abschnitt enthält Informationen zu Aspekten der Zuverlässigkeit für die Ausführung von SAP S/4HANA in Google Cloud.
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.
Im Folgenden finden Sie einige HA- und DR-Tools, die Sie verwenden können:
- Zonenübergreifendes Linux-Clustering: Weitere Informationen finden Sie im Leitfaden zur Planung von Hochverfügbarkeit für SAP NetWeaver in Google Cloud und im Leitfaden zur Planung von Hochverfügbarkeit für SAP HANA.
- Live-Migration
- VM-Hostwartungsrichtlinie
- Automatischen Neustart von Diensten
- Sicherungen
Zonenübergreifendes Linux-Clustering: Durch Einrichten eines zonenübergreifenden Linux-Clusters können Sie Komponentenausfälle in einer bestimmten Region vermeiden.
Auf der SAP NetWeaver-Anwendungsebene können Sie einen Linux-Cluster zonenübergreifend bereitstellen, um die Auswirkungen eines Fehlers auf den ASCS zu reduzieren und für beide Knoten in verschiedenen Zonen hochverfügbar zu machen. Der Linux-Cluster verschiebt die ASCS dann auf den Standby-Knoten für den Fall, dass am primären Knoten ein Problem auftritt oder eine Wartung ausgeführt wird. Sie können auch einen Enqueue Replication Server verwenden, um den Inhalt der Warteschlangentabelle zu replizieren. Dadurch behält der Enqueue Server den Inhalt der Warteschlangentabelle auf dem Standby-Knoten bei, falls der Prozess von der primären zu Standby.
Auf der SAP HANA-Datenbankebene können Sie 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. Weitere Informationen zum Konfigurieren und Einrichten von HANA SR finden Sie unter HANA-Systemreplikation.
- Aktiv/Aktiv-Konfiguration (Lesezugriff): Konfigurieren Sie beide Instanzen als aktiv, den sekundären Knoten jedoch als schreibgeschützt. Diese Konfiguration basiert auf einer kontinuierlichen Log-Wiedergabe. Die virtuelle IP (VIP) ist so konfiguriert, dass sie auf den aktuellen Lese-/Schreibknoten verweist. Weitere Informationen finden Sie unter Aktiv/Aktiv (Lesezugriff aktiviert).
Darüber hinaus ist es möglich, die SAP HANA-Systemreplikation als Notfallwiederherstellungslösung zu verwenden. Die primäre Datenbank repliziert ihren Inhalt in die Standby-Datenbank. Diese kann verwendet werden, wenn die primäre Datenbank offline geht, sodass das SAP-System weiter funktioniert, bis der Dienst in der primären Datenbank wiederhergestellt ist. Das Hochstufen des sekundären Knotens geschieht in diesem Fall nicht automatisch, sondern muss manuell durchgeführt werden. Sie können auch HA und DR auf SAP HANA-Seite kombinieren, um die Ausfallsicherheit und Verfügbarkeit zu erhöhen. Weitere Informationen finden Sie unter:
Live-Migration: Compute Engine bietet Live-Migration, damit Ihre VM-Instanzen auch dann ausgeführt werden, wenn ein Hostsystemereignis auftritt, z. B. ein Software- oder Hardware-Update. In dieser Situation führt Compute Engine eine Live-Migration Ihrer ausgeführten Instanz zu einem anderen Host in derselben Zone durch, ohne dass Ihre ausgeführte Instanz neu gestartet werden muss. 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-Migrationsprozess während Wartungsereignissen.
Kostenoptimierung
Dieser Abschnitt enthält Informationen zur Lizenzierung, zu Rabatten und zur Schätzung der Arbeitslastgröße.
Lizenzierung
Als SAP-Kunde können Sie SAP S/4HANA 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 Lizenzen verwenden. Weitere Informationen finden Sie unter Benutzerdefinierte Betriebssystem-Images.
Rabatte
Mit den „Pay as you go“-Preisen von Google Cloud bezahlen Sie nur für die Dienste, die Sie nutzen. Sie müssen sich nicht auf eine bestimmte Größe oder einen bestimmten Dienst festlegen; Sie können Ihre Nutzung nach Bedarf ändern oder einstellen. Für vorhersehbare Arbeitslasten bietet Compute Engine Rabatte für zugesicherte Nutzung (CUDs). Sie können damit die Kosten Ihrer Infrastruktur senken, indem sie einen Vertrag abschließen und im Gegenzug erhebliche Rabatte auf die VM-Nutzung erhalten.
Google Cloud bietet diese Rabatte im Gegenzug für den Kauf von Verträgen über zugesicherte Nutzung, die auch als Zusicherungen bezeichnet werden. Wenn Sie eine Zusicherung erwerben, verpflichten Sie sich entweder zu einer minimalen Ressourcennutzung oder zu einem Mindestausgabenbetrag für einen bestimmten Zeitraum von einem oder drei Jahren. Mit diesen Rabatten können Sie Ihre monatliche Rechnung für die von Ihrem SAP S/4HANA-System verwendeten Ressourcen senken. Weitere Informationen finden Sie unter Rabatte für zugesicherte Nutzung.
Größenschätzungen
Die folgenden Ressourcen enthalten Informationen dazu, wie Sie Größenschätzungen für Ihre SAP-Systeme vornehmen können, bevor Sie sie zu Google Cloud migrieren:
Operative Effizienz
In diesem Abschnitt wird beschrieben, wie Sie die betriebliche Effizienz von SAP S/4HANA in Google Cloud optimieren können.
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 einem anderen Problem eine Wiederherstellung durchführen können.
Für die Sicherung von SAP HANA-Daten stehen Ihnen in Google Cloud verschiedene Möglichkeiten zur Verfügung, wie etwa:
- Sicherungen mit dem Backup- und DR-Dienst von Google Weitere Informationen finden Sie unter Erkannte SAP HANA-Datenbank und zugehörige Logs sichern.
- Mit dem von SAP zertifizierten Backint-Feature des Google Cloud-Agents für SAP können Sie direkt in Cloud Storage sichern.
- Sichern Sie auf einem Laufwerk und laden Sie dann die Sicherungen in Cloud Storage hoch.
- Sichern Sie Laufwerke mit Snapshots.
In Cloud Storage sichern
Ab Version 3.0 unterstützt der Google Cloud-Agent für SAP das Backint-Feature, mit dem SAP HANA Datenbanksicherungen direkt aus Cloud Storage sichern und wiederherstellen kann. Diese neue Funktion ist für SAP HANA-Instanzen verfügbar, die auf Compute Engine VM-Instanzen, Bare Metal Solution-Servern, lokalen Servern oder anderen Cloud-Plattformen ausgeführt werden. So können Sie direkt auf Cloud Storage sichern und von dort wiederherstellen, ohne dass Sie nichtflüchtige Laufwerke für Ihre Sicherungen benötigen. Weitere Informationen finden Sie in der Betriebsanleitung für SAP HANA.
Informationen zur SAP-Zertifizierung dieser Funktion des Agents finden Sie im SAP-Hinweis 2031547 – Übersicht über SAP-zertifizierte Sicherungstools von Drittanbietern und den zugehörigen Supportprozess.
Das folgende Diagramm zeigt den Sicherungsablauf bei Verwendung des Backint-Features des Google Cloud-Agents für SAP:
Auf Laufwerken sichern
Sie können die native SAP HANA-Sicherungs- und Wiederherstellungsfunktion mit Compute Engine-Persistent Disk-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 in SAP HANA 2.0 und höher SAP HANA Cockpit, um SAP HANA-Sicherungen zu erstellen.
Das folgende Diagramm zeigt den Ablauf bei Verwendung des Sicherungsfeatures für SAP HANA:
Laufwerke 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 Laufwerken. Sie können beispielsweise geplante Snapshots des Laufwerks erstellen, das das Verzeichnis /hanabackup hostet, um sie bei einer Notfallwiederherstellung zu verwenden. Es ist auch möglich, Laufwerk-Snapshots zu verwenden, um Ihr SAP HANA-Datenvolume zu sichern und wiederherzustellen. 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.
Wenn Sie Version 3.0 oder höher des Google Cloud-Agents für SAP verwenden, können Sie Sicherungen erstellen und eine Wiederherstellung für SAP HANA mit dem Laufwerk-Snapshot-Feature des Agents durchführen. Weitere Informationen finden Sie unter Laufwerk-Snapshot-basierte Sicherung und Wiederherstellung für SAP HANA.
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. Sie können eine geeignete Option aus den folgenden Optionen auswählen:
- 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
Monitoring
Zum Monitoring und für Support für SAP-Arbeitslasten, die auf Compute Engine-VM-Instanzen und Bare-Metal-Lösungsservern ausgeführt werden, stellt Google Cloud den Agent für SAP bereit.
Gemäß den Anweisungen müssen Sie, um Support von SAP zu erhalten und die Service Level Agreements (SLAs) einzuhalten, den Google Cloud-Agent für SAP auf allen Compute Engine-VM-Instanzen und Bare-Metal-Lösungsservern installieren, die ein beliebiges SAP-System ausführen. Weitere Informationen zu den Supportvoraussetzungen finden Sie im SAP-Hinweis SAP-Hinweis 2456406 – SAP auf der Google Cloud Platform: Voraussetzungen für den Support.
Zusätzlich zur obligatorischen Erfassung von SAP Host Agent-Messwerten enthält der Google Cloud-Agent für SAP unter Linux optionale Funktionen wie die Erfassung von Prozessmonitoring-Messwerten und Workload Manager-Bewertungsmesswerten. Sie können diese Funktionen aktivieren, um Produkte und Dienste wie die Arbeitslastverwaltung für Ihre SAP-Arbeitslasten zu nutzen.
Leistungsoptimierung
Dieser Abschnitt enthält Informationen zur Optimierung der Leistung von SAP S/4HANA-Arbeitslasten durch Größenanpassung und Netzwerkkonfiguration.
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 im SAP-Hinweis SAP-Hinweis 2456432 – SAP-Anwendungen in Google Cloud: Unterstützte Produkte und Google Cloud-Maschinentypen. SAP und Google Cloud verwenden unterschiedliche Einheiten für die Messung von IOPS (Eingabe- und Ausgabevorgänge pro Sekunde). Wenden Sie sich an Ihren Systemintegrator, um die Größenanforderungen für SAP in eine Google Cloud-Infrastruktur mit der entsprechenden Größe umzuwandeln.
Bevor Sie vorhandene Systeme von SAP ECC zu S/4HANA migrieren, empfiehlt SAP, den Bericht/SDF/HDB_SIZING auszuführen, wie im SAP-Hinweis 1872170 – ABAP auf HANA-Größenbericht (S/4HANA, Suite auf HANA...) 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.
Netzwerkkonfiguration
Die Netzwerkfunktionen Ihrer Compute Engine-VM werden durch ihre Maschinenfamilie, nicht durch die Netzwerkschnittstelle (NIC) oder IP-Adresse bestimmt.
Abhängig vom Maschinentyp kann Ihre VM-Instanz einen Netzwerkdurchsatz von 2–32 Gbit/s haben. Bestimmte Maschinentypen unterstützen auch Durchsätze von bis zu 100 Gbit/s. Dazu ist die Verwendung des Schnittstellentyps Google Virtual NIC (gVNIC) mit einer Tier_1-Netzwerkkonfiguration erforderlich. Die Möglichkeit, diese Durchsatzraten zu erreichen, hängt weiter von der Trafficrichtung und dem Typ der Ziel-IP-Adresse ab.
Compute Engine-VM-Netzwerkschnittstellen werden von einer redundanten und robusten Netzwerkinfrastruktur mit physischen und softwarebasierten Netzwerkkomponenten unterstützt. Diese Schnittstellen übernehmen Redundanz und Ausfallsicherheit von der zugrunde liegenden Plattform. Mehrere virtuelle NICs können für die Traffictrennung verwendet werden, dies bietet aber keine zusätzlichen Leistungsvorteile.
Eine einzelne NIC bietet die erforderliche Leistung für SAP HANA-Bereitstellungen in Compute Engine. Ihr spezieller Anwendungsfall, die Sicherheitsanforderungen oder -einstellungen erfordern möglicherweise auch zusätzliche Schnittstellen zur Trennung des Traffics, z. B. Internettraffic, interner Traffic der SAP HANA-Systemreplikation oder andere Abläufe, die von bestimmten Netzwerkrichtlinienregeln profitieren könnten. Sie sollten Trafficverschlüsselung der Anwendung verwenden und anhand einer Firewallrichtlinie mit geringsten Berechtigungen den Netzwerkzugriff sichern.
Berücksichtigen Sie die Notwendigkeit einer Traffictrennung frühzeitig als Teil Ihres Netzwerkdesigns und weisen Sie zusätzliche NICs zu, wenn Sie VMs bereitstellen. Sie müssen jede Netzwerkschnittstelle an ein anderes VPC-Netzwerk anhängen. Ihre Auswahl für die Anzahl der Netzwerkschnittstellen hängt von der erforderlichen Isolationsebene ab, mit bis zu 8 Schnittstellen für VMs mit 8 vCPUs oder mehr.
Sie können beispielsweise ein VPC-Netzwerk für Ihre SAP HANA SQL-Anwendungsclients, wie SAP NetWeaver-Anwendungsserver und benutzerdefinierte Anwendungen, und ein separates VPC-Netzwerk für den Traffic zwischen den Servern, wie SAP HANA System Replication, definieren. Beachten Sie, dass zu viele Segmente die Verwaltung und Fehlerbehebung von Netzwerkproblemen erschweren. Wenn Sie Ihre Meinung später ändern, können Sie Ihre VM-Instanz mithilfe von Compute Engine-Maschinen-Images neu erstellen und dabei alle zugehörigen Konfigurationen, Metadaten und Daten beibehalten.Weitere Informationen finden Sie unter:
Bereitstellung
Dieser Abschnitt enthält Informationen zur Bereitstellung von SAP S/4HANA in Google Cloud.
Wichtige SAP-Hinweise vor der Bereitstellung
Lesen Sie vor dem Bereitstellen eines SAP S/4HANA-Systems in Google Cloud die folgenden SAP-Hinweise. Prüfen Sie außerdem vor dem Start einer SAP-Implementierung den SAP Marketplace, ob es aktualisierte Anleitungen und Hinweise für Produktinstallationen gibt.
- SAP-Hinweis 2456432 – SAP-Anwendungen in Google Cloud: Unterstützte Produkte und Google Cloud-Maschinentypen
- 2446441 – Linux in Google Cloud (IaaS): Anpassung Ihrer SAP-Lizenz
- 2456953 – Windows in Google Cloud (IaaS): Anpassung Ihrer SAP-Lizenz
- 1380654 – SAP-Support in öffentlichen Cloudumgebungen
- SAP-Hinweis 2456406 – SAP auf der Google Cloud Platform: Voraussetzungen für den Support
Automatisierung der Bereitstellung
Zum Installieren von SAP S/4HANA in Google Cloud können Sie die folgenden Bereitstellungsoptionen verwenden:- Wenn Sie die Bereitstellung eines verteilten oder verteilten Systems mit Hochverfügbarkeit (High Availability, HA) automatisieren möchten, können Sie das interaktive Bereitstellungsautomatisierungstool im Workload Manager verwenden. Mit diesem Tool können Sie unterstützte SAP-Arbeitslasten direkt über die Google Cloud Console konfigurieren und bereitstellen oder den entsprechenden Terraform- und Ansible-Code generieren und herunterladen. Weitere Informationen finden Sie unter Geführte Bereitstellungsautomatisierung.
- Um die Bereitstellung eines zentralisierten oder verteilten SAP HANA-Systems zu automatisieren, können Sie die von Google Cloud bereitgestellten Terraform-Konfigurationen verwenden. Weitere Informationen finden Sie im Bereitstellungsleitfaden für Ihr SAP HANA-Szenario.
Nächste Schritte
- Weitere Informationen zu den in diesem Leitfaden verwendeten Google Cloud-Diensten:
- VPC-Netzwerke
- Compute Engine
- Speicheroptionen: Persistent Disk, Hyperdisk und Cloud Storage
- Google Cloud Console
- Cloud Monitoring
- Identity and Access Management
- Filestore
- NetApp Cloud Volumes ONTAP
- Google Cloud NetApp Volumes
- Sicherung und Notfallwiederherstellung
- Weitere Referenzarchitekturen, Designleitfäden und Best Practices finden Sie im Cloud-Architekturcenter