Referenzarchitektur: SAP Business Suite auf SAP ASE oder IBM Db2 in Google Cloud

Diese Referenzarchitektur richtet sich an Personen, die Google Cloud als Plattform für die Bereitstellung von SAP Business Suite-Anwendungen in SAP ASE oder IBM Db2 prüfen. Dazu gehören Überlegungen während der Planungsphase, Bereitstellungsmodelle und Automatisierung sowie allgemeine operative Verfahren wie Sicherungs- und DR-Aufgaben.

Die Google Cloud bietet eine kostengünstige, zuverlässige, sichere und leistungsstarke SAP-zertifizierte Infrastruktur für die Ausführung von SAP Business Suite auf SAP ASE oder IBM Db2. 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 die SAP Business Suite: Zentralisiert, Verteilt, und Verteilt mit Hochverfügbarkeit.

Zentralisierte Bereitstellung

Bei einer zentralisierten Bereitstellung können Sie SAP Business Suite und die SAP ASE- oder IBM Db2-Datenbank auf derselben Compute Engine-VM-Instanz installieren. Wir empfehlen diesen Ansatz für Umgebungen, die keine Produktionsumgebungen sind, wie Sandbox- und Entwicklungsumgebungen.

In den folgenden Abschnitten werden Referenzarchitekturen für die SAP Business Suite auf SAP ASE und IBM Db2 in zentralisierten Bereitstellungen gezeigt.

Zentralisierte Bereitstellung der SAP Business Suite mit SAP ASE

Das folgende Diagramm zeigt eine Referenzarchitektur für eine zentralisierte Bereitstellung der SAP Business Suite auf SAP ASE. Beachten Sie, dass SAP ASCS, PAS, WD und die Datenbank alle auf derselben VW-Instanz installiert sind.

Architekturdiagramm für SAP Business Suite auf SAP ASE in Google Cloud in einer zentralisierten Bereitstellung

Zentralisierte Bereitstellung der SAP Business Suite mit IBM Db2

Das folgende Diagramm zeigt eine Referenzarchitektur für eine zentralisierte Bereitstellung der SAP Business Suite auf IBM Db2. Beachten Sie, dass SAP ASCS, PAS, WD und die Datenbank alle auf derselben VW-Instanz installiert sind.

Architekturdiagramm für SAP Business Suite auf IBM Db2 in Google Cloud in einer zentralisierten Bereitstellung

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.

Verteilte Bereitstellung der SAP Business Suite mit SAP ASE

Im folgenden Diagramm wird eine Referenzarchitektur für SAP Business Suite auf SAP ASE in einer verteilten Bereitstellung dargestellt. Beachten Sie, dass SAP ASCS, PAS, WD und ASE auf verschiedenen VW-Instanzen installiert sind.

Architekturdiagramm für die SAP Business Suite auf SAP ASE in Google Cloud in einer verteilten Bereitstellung.

Verteilte Bereitstellung der SAP Business Suite mit IBM Db2

Das folgende Diagramm zeigt eine Referenzarchitektur für SAP Business Suite auf IB Db2 in einem verteilten Bereitstellungsmodell. Beachten Sie, dass SAP ASCS, PAS, WD und IBM Db2 auf verschiedenen VM-Instanzen installiert sind.

Architekturdiagramm für die SAP Business Suite auf IBM Db2 in Google Cloud in einer verteilten Bereitstellung

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 bereitstellen. In beiden Fällen richten Sie für maximale Redundanz zuerst zwei Compute Engine-VM-Instanzen in separaten Zonen ein, die jeweils eine eigene SAP ASE- oder IBM Db2-Datenbank haben.

  • Verteilte Bereitstellung von SAP ASE mit Hochverfügbarkeit: Sie können eine von SAP unterstützte hochverfügbare und ausfallsichere (HADR, High Availability Disaster Recovery) SAP ASE-Datenbank in Google Cloud bereitstellen. Weitere Informationen finden Sie im Planungsleitfaden: SAP ASE.

    Das folgende Diagramm veranschaulicht eine Architektur für die SAP Business Suite auf SAP ASE, die einen Linux-Cluster verwendet, um Hochverfügbarkeit sowohl auf Anwendungs- als auch auf Datenbankseite zu erreichen:

    Architekturdiagramm für die SAP Business Suite in SAP ASE in Google Cloud in einer verteilten Hochverfügbarkeitsbereitstellung

    Der Cluster, der die Hochverfügbarkeit verwaltet, umfasst die folgenden Funktionen und Features:

    • Drei Host-VMs, zwei mit jeweils einer Datenbankinstanz und eine mit dem Fault Manager.
    • Synchrone SAP ASE-Replikation.
    • Hochverfügbarkeitsclusterressourcen-Manager von Pacemaker
    • Einen Fencing-Mechanismus, der Fault Manager verwendet, um fehlgeschlagenen oder fehlschlagende Ressourcen zu isolieren.
    • Automatischer Neustart der fehlgeschlagenen Instanz als neue sekundäre Instanz und automatische erneute Registrierung für die SAP ASE-Replikation

  • Verteilte Bereitstellung von IBM Db2 mit Hochverfügbarkeit: Sie können eine hochverfügbare und ausfallsichere (HADR) IBM Db2-Datenbank in Google Cloud bereitstellen, die von SAP unterstützt wird. Weitere Informationen finden Sie in der Anleitung zur Planung von IBM Db2 für SAP.

    Sie können einen HADR-Pacemaker-Cluster mit zwei Hosts mithilfe der von IBM für Db2 bereitgestellten Clustering-Lösung konfigurieren. Weitere Informationen finden Sie in der SAP-PDF-Datei Database Administration Guide for SAP on IBM Db2 for Linux, Unix, and Windows (Leitfaden zur Datenbankverwaltung für SAP auf IBM Db2 für Linux, Unix und Windows).

    Das folgende Diagramm veranschaulicht eine Architektur für die SAP Business Suite auf SAP Db2, die einen Linux-Cluster verwendet, um Hochverfügbarkeit sowohl auf Anwendungs- als auch auf Datenbankseite zu erreichen:

    Architekturdiagramm für die SAP Business Suite auf IBM Db2 in Google Cloud in einer verteilten Hochverfügbarkeitsbereitstellung.

    Der Cluster, der die Hochverfügbarkeit verwaltet, umfasst die folgenden Funktionen und Features:

    • Zwei Host-VMs mit jeweils einer IBM Db2-Instanz.
    • Synchrone IBM Db2 HADR-Replikation.
    • Ein Linux-Hochverfügbarkeitsclusterressourcenmanager, z. B. Pacemaker.
    • Ein Fencing-Mechanismus, der den ausgefallenen Knoten abwehrt.
    • Einen internen Application Load Balancer, um das VIP an den aktiven Knoten weiterzuleiten.
    • Automatischer Neustart der fehlgeschlagenen Instanz als neue sekundäre Instanz und automatische erneute Registrierung für IBM Db2 HADR

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 S/4HANA-System mit hoher Verfügbarkeit zu versorgen, falls eine der ASCS- und ERS-Instanzen ausfällt.

Abhängig von der SAP NetWeaver-Version, die Sie mit Ihrem SAP Business Suite-System verwenden, werden Enqueue Server und Enqueue Replication Server/Enqueue Replicator in einer anderen Version ausgeführt:

Das folgende Diagramm zeigt ein SAP Business Suite-System, das einen Pacemaker-Cluster verwendet, um die Single Points of Failure sowohl vom Message Server als auch vom Enqueue Server zu begrenzen:

Architekturdiagramm für SAP NetWeaver mit einer Datenbank in einer Bereitstellung mit Hochverfügbarkeit in Google Cloud.

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 Business Suite in einer SAP ASE- oder IBM Db2-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

Die SAP Business Suite auf SAP ASE oder IBM Db2 besteht aus den folgenden technischen Komponenten:

  • SAP ASE- oder IBM Db2-Datenbank
  • Fault Manager, nur in SAP ASE
    • Dies hat einen eigenen Hostserver und überwacht den primären Server und den Standbyserver. Fault Manager sorgt durch automatisches Failover für eine hohe Verfügbarkeit von SAP ASE. Fault Manager überwacht die folgenden Komponenten: Replication Management Agent, Replikationsserver, Anwendungen, Datenbanken und Betriebssystem. Außerdem können Sie damit den Status der Datenbank prüfen und sie bei Bedarf neu starten.
  • 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 Business Suite-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 Business Suite-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 Bereitstellung der SAP Business Suite auf SAP ASE oder IBM Db2 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:

  • Persistent Disk-Volumes stehen in Form von Standardlaufwerken (HDDs) oder Solid-State-Laufwerken (SSDs) zur Verfügung. Für abgestimmten nichtflüchtigen Speicher und nichtflüchtigen SSD-Speicher bietet PD Async Replication die asynchrone Replikation von SAP-Daten zwischen zwei Google Cloud-Regionen.
  • Hyperdisk Extreme-Volumes bieten höhere maximale IOPS- und Durchsatzoptionen als Persistent Disk-Volumes vom Typ SSD.
  • Standardmäßig verschlüsselt Compute Engine inaktive Kundeninhalte, einschließlich Inhalte auf Persistent Disk- und Hyperdisk-Volumes. Weitere Informationen zur Laufwerksverschlüsselung und möglichen Verschlüsselungsoptionen finden Sie unter Laufwerkverschlüsselung.
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 Business Suite-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 ASE- oder IBM Db2-Datenbankebene (primär und sekundär).

Es gibt mehrere Möglichkeiten, Ihr Netzwerk zu erstellen und Ihr SAP Business Suite-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 die SAP Business Suite in einer einzelnen freigegebene 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 Business Suite auf 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 Business Suite auf 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 Business Suite-System auf SAP ASE oder IBM Db2 hat einige übliche 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 ASE- oder IBM Db2-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 eines SAP Business Suite-Systems auf SAP ASE oder IBM Db2 empfehlen wir Ihnen, diese Single Points of Failure zu untersuchen und entsprechend zu 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

In der Planungsphase der Implementierung eines SAP Business Suite-Systems auf SAP ASE oder IBM Db2 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 Business Suite-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 Business Suite-Systems in SAP ASE oder IBM Db2 in Google Cloud haben.

Unterstützte Maschinentypen für SAP Business Suite-Instanzen

Google Cloud bietet Compute Engine VM-Instanztypen, die von SAP dahingehend zertifiziert sind, dass sie die Größenanforderungen bei der Bereitstellung einer SAP Business Suite mit SAP ASE oder IBM Db2 erfüllen. Weitere Informationen zur Größenbemessung in Google Cloud und zu den unterstützten Maschinentypen finden Sie in den folgenden Dokumenten:

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.

Google Cloud-Regionen und -Zonen

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.
  • Prüfen Sie, ob sich Ihr SAP-Anwendungsserver und Ihre Datenbank in derselben Region befinden.

Speicheroptionen für SAP Business Suite

Die folgenden Speicheroptionen von Google Cloud sind von SAP für die Verwendung mit der SAP Business Suite und SAP ASE oder IBM Db2 zertifiziert.

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 als pd-ssd fü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. 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. 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 Business Suite 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 ASE- oder IBM Db2-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 ASE oder IBM Db2. 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 ASE-Verzeichnisstruktur und -Speicheroptionen

In den folgenden Tabellen werden die Verzeichnisstrukturen für das SAP Business Suite-System in der SAP ASE-Datenbank in Google Cloud beschrieben.

  • Empfohlene Linux-Verzeichnisstruktur für eine generische SAP ABAP-Instanz

    Linux-Verzeichnis Empfohlene Speicheroption in Google Cloud
    /sapmnt* Abgestimmter nichtflüchtiger Speicher
    /usr/sap Abgestimmter nichtflüchtiger Speicher

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

  • Nachfolgend wird die empfohlene Linux-Verzeichnisstruktur für SAP Business Suite auf SAP ASE in Google Cloud dargestellt.

    Alle Daten- und Logdateien der SAP ASE-Datenbank müssen sich im Verzeichnis /sybase/SAP_SID befinden. Ersetzen Sie SAP_SID durch die SAP-System-ID (SID), also die SAP-Instanznummer, die Sie bei der Datenbankinstallation verwendet haben.

    SAP ASE-Verzeichnis Empfohlene Speicheroption in Google Cloud
    /usr/sap Abgestimmter nichtflüchtiger Speicher
    /sybase/SAP_SID/sapdata1 SSD-basierte Persistent Disk oder Hyperdisk
    /sybase/SAP_SID/log_dir SSD-basierte Persistent Disk oder Hyperdisk
    /sybase/SAP_SID/saptemp Abgestimmter nichtflüchtiger Speicher
    /sybase/SAP_SID/sapdiag Abgestimmter nichtflüchtiger Speicher

    Informationen von SAP über die Ausführung von SAP ASE finden Sie unter SAP-Anwendungen auf SAP Adaptive Server Enterprise – Best Practices für Migration und Laufzeit.

  • Nachfolgend wird die empfohlene Windows-Verzeichnisstruktur für SAP Business Suite auf SAP ASE in Google Cloud dargestellt. Die folgende Verzeichnisstruktur gilt für die Installation des zentralen Servers.

    Drive Beschreibung Empfohlene Speicheroption in Google Cloud
    C:\ Bootlaufwerk Abgestimmter nichtflüchtiger Speicher
    D:\ Datenbank-Binärprogramme Abgestimmter nichtflüchtiger Speicher
    E:\ Datendateien der Datenbank SSD-basierte Persistent Disk oder Hyperdisk
    L:\ Datenbankprotokolldateien SSD-basierte Persistent Disk oder Hyperdisk
    P:\ Auslagerungsdatei Abgestimmter nichtflüchtiger Speicher
    S:\ /usr/sap- und /sapmnt-Verzeichnisse Abgestimmter nichtflüchtiger Speicher
    T:\ temp- und saptemp-Verzeichnisse Abgestimmter nichtflüchtiger Speicher
    X:\ Sicherung Abgestimmter nichtflüchtiger Speicher

    Informationen von SAP über die Ausführung von SAP ASE finden Sie unter SAP-Anwendungen auf SAP Adaptive Server Enterprise – Best Practices für Migration und Laufzeit.

IBM Db2-Verzeichnisstruktur und -Speicheroptionen

In den folgenden Tabellen werden die Verzeichnisstrukturen für das SAP Business Suite-System in der SAP Db2-Datenbank in Google Cloud beschrieben.

  • Empfohlene Linux-Verzeichnisstruktur für SAP Business Suite auf IBM Db2 in Google Cloud:

    IBM Db2-Verzeichnisstruktur Empfohlene Speicheroption in Google Cloud
    /sapmnt Abgestimmter nichtflüchtiger Speicher
    /usr/sap Abgestimmter nichtflüchtiger Speicher
    /db2/DB_SID Abgestimmter nichtflüchtiger Speicher
    /db2/DB_SID/db2dump Abgestimmter nichtflüchtiger Speicher
    /db2/DB_SID/sapdata1 SSD-basierte Persistent Disk oder Hyperdisk
    /db2/DB_SID/log_dir SSD-basierte Persistent Disk oder Hyperdisk
    /db2/DB_SID/saptmp1 Abgestimmter nichtflüchtiger Speicher
    /db2backup Abgestimmter nichtflüchtiger Speicher

    Informationen von SAP zum Ausführen von SAP-Systemen auf IBM Db2 finden Sie unter SAP auf IBM Db2 für Linux, UNIX und Windows.

  • Nachfolgend wird die empfohlene Windows-Verzeichnisstruktur für SAP Business Suite auf IBM Db2 in Google Cloud dargestellt. Diese Verzeichnisstruktur gilt für die Installation des zentralen Servers.

    Drive Beschreibung Empfohlene Speicheroption in Google Cloud
    C:\ Bootlaufwerk Abgestimmter nichtflüchtiger Speicher
    D:\ Datenbank-Binärprogramme Abgestimmter nichtflüchtiger Speicher
    E:\ Datendateien der Datenbank SSD-basierte Persistent Disk oder Hyperdisk
    L:\ Datenbankprotokolldateien SSD-basierte Persistent Disk oder Hyperdisk
    P:\ Auslagerungsdatei Abgestimmter nichtflüchtiger Speicher
    S:\ /usr/sap- und /sapmnt-Verzeichnisse Abgestimmter nichtflüchtiger Speicher
    T:\ temp- und saptemp-Verzeichnisse Abgestimmter nichtflüchtiger Speicher
    X:\ Sicherung Abgestimmter nichtflüchtiger Speicher

    Weitere Informationen zu den Verzeichnisstrukturen finden Sie im Planungsleitfaden für SAP NetWeaver. Informationen zur Berechnung der Größe der Auslagerungsdatei finden Sie im SAP-Hinweis 1518419: Vom SAP-System benötigte Page-Datei und virtueller Speicher.

Betriebssystemsupport für die SAP Business Suite

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 der SAP Business Suite und SAP ASE oder IBM Db2 finden Sie in den folgenden Anleitungen:

Bereitstellungsarchitektur für SAP ASE

SAP ASE ist eine wichtige Komponente jedes SAP Business Suite-Systems, da es als einer der möglichen Datenbanktypen für das System dient.

Das folgende Diagramm zeigt eine Bereitstellungsarchitektur für SAP ASE in Google Cloud. Beachten Sie im Diagramm die Bereitstellung in Google Cloud und das Laufwerkslayout. Sie können Ihre lokalen Sicherungen, die in /sybasebackup verfügbar sind, mit Cloud Storage speichern. Dieses bereitgestellte Verzeichnis muss mindestens so groß sein wie das bereitgestellte Datenverzeichnis.

Architekturdiagramm für die Bereitstellung von SAP ASE in Google Cloud

Bereitstellungsarchitektur für IBM Db2

IBM Db2 ist eine wichtige Komponente jedes SAP Business Suite-Systems, da es als einer der möglichen Datenbanktypen für das System dient.

Das folgende Diagramm zeigt eine Bereitstellungsarchitektur für IBM Db2 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 /db2backup verfügbar sind, mit Cloud Storage speichern. Dieses bereitgestellte Verzeichnis muss mindestens so groß sein wie das bereitgestellte Datenverzeichnis.

Architekturdiagramm für die Bereitstellung von IBM Db2 in Google Cloud

Bereitstellungsarchitektur für die SAP Business Suite

Wie im Abschnitt Architektur erwähnt, gibt es mehrere Bereitstellungsarchitekturen, die Sie für die Bereitstellung der SAP Business Suite in SAP ASE oder IBM Db2 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 Business Suit dargestellt, die auf einer Compute Engine-VM ausgeführt wird:

Zweistufige Architektur für SAP Business Suite auf SAP ASE oder IBM Db2 auf einer Compute Engine-VM in Google Cloud.

Dreistufige Architektur

Diese Architektur wird im Abschnitt Zentralisierte Bereitstellung dargestellt. Sie können diese Architektur verwenden, um hochverfügbare SAP Business Suite-Systeme bereitzustellen. Im folgenden Diagramm sind einige Details einer dreistufigen Architektur für die SAP Business Suite dargestellt, die auf Compute Engine-VMs ausgeführt wird:

Dreistufige Architektur für SAP Business Suite auf SAP ASE oder IBM Db2 auf einer Compute Engine-VM in Google Cloud.

In dieser Architektur verteilt das SAP Business Suite-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 beim Ausführen von SAP Business Suite auf SAP ASE oder IBM Db2 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.

Bastion Host im SSH-Szenario

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:

Cloud VPN

Mit einer VPN-Verbindung 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.

Weitere Informationen zu Sicherheitsressourcen für Ihre SAP-Umgebung in Google Cloud finden Sie hier:

Zuverlässigkeit

Dieser Abschnitt enthält Informationen zu Aspekten der Zuverlässigkeit für die Ausführung von SAP Business Suite auf SAP ASE oder IBM Db2 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:

SAP ASE-Hochverfügbarkeit

Sie können Hochverfügbarkeit für Ihre SAP ASE-Datenbank in Google Cloud erreichen, wenn Sie die synchrone Replikation zwischen dem primären Server und dem Standby-Server so konfigurieren, dass die beiden Server durchgängig ohne Datenverlust synchronisiert werden. Die Option immer aktiv von SAP ASE, einem HADR-System (High Availability and Disaster Recovery), wird in Google Cloud unterstützt. Weitere Informationen finden Sie im Planungsleitfaden für SAP ASE.

Die VM-Instanzen, auf denen die primären und Standby-Server gehostet werden, müssen die folgenden Komponenten haben:

  • SAP ASE
  • SAP Host Agent, der die CPU-, Arbeitsspeicher- und andere Ressourcennutzung des Servers überwacht.
  • Replication Management Agent (RMA)
  • SAP ASE Cockpit – führt Datenbankaktivitäten aus.
  • Fault Manager, der einen eigenen Hostserver hat. Es überwacht die primären und Standby-SAP ASE-Server. Fault Manager sorgt durch automatisches Failover für eine hohe Verfügbarkeit von SAP ASE. Fault Manager überwacht die folgenden Komponenten: RMA, Replikationsserver, Anwendungen, Datenbanken und Betriebssystem. Außerdem können Sie damit den Status der Datenbank prüfen und sie bei Bedarf neu starten.

Zur Verbesserung der Systemverfügbarkeit ermöglicht ein SAP ASE-Cluster das Verschieben von Arbeitslasten auf den sekundären Knoten, da der primäre Knoten auf Ausfall überwacht wird. Im folgenden Diagramm ist eine allgemeine Referenzarchitektur dargestellt, die zeigt, wie die beschriebenen SAP ASE-Komponenten in Google Cloud installiert werden können.

Architektur für ein SAP ASE-Hochverfügbarkeitssystem in Google Cloud

Notfallwiederherstellung für SAP ASE

Das SAP ASE-HADR-System mit einem Knotensystem zur Notfallwiederherstellung (DR, Disaster Recovery) besteht aus drei SAP ASE-Servern:

  • Primärer Server: Dieser Server übernimmt die gesamte Transaktionsverarbeitung.
  • Standby-Knoten: Dieser Server dient als Warmstandby für den primären Server und enthält Kopien der ausgewählten Datenbanken des primären Servers.
  • DR-Knoten: Dieser Server ist geografisch weit entfernt und sichert designierte Datenbanken des primären Servers.

Das folgende Diagramm zeigt den Ablauf der SAP ASE-Notfallwiederherstellung:

Architektur für ein SAP ASE-System in Google Cloud mit Notfallwiederherstellung

IBM Db2-Hochverfügbarkeit und Notfallwiederherstellung

So erreichen Sie Hochverfügbarkeit und Notfallwiederherstellung (High Availability and Disaster Recovery, HADR) für Ihre IBM Db2-Datenbank:

  • Sie müssen zwei separate Instanzen Ihrer IBM Db2-Datenbank bereitstellen, eine primäre und eine als Standby. Sie müssen sie synchronisieren. Wenn die primäre Instanz ausfällt, übernimmt die Standby-Instanz die Arbeitslast.

    Die primäre Instanz verarbeitet Clientverbindungen und Transaktionen und zeichnet diese in Protokollen auf. Diese Protokolle werden über TCP/IP an den Standby-Server gesendet, der damit seine Datenbank aktualisiert und so mit der primären Instanz synchronisiert bleibt.

  • Da HADR selbst weder über Fehlererkennung noch Automatisierung verfügt, müssen Sie auch Pacemaker bereitstellen. Pacemaker überwacht beide Instanzen. Wenn die primäre Instanz abstürzt, löst Pacemaker die Übernahme durch die Standby-Instanz aus und sorgt dafür, dass die Floating-IP-Adresse der neuen primären Instanz zugewiesen wird.

    Pacemaker übernimmt die Clusterverwaltung und eine VIP wird zusammen mit einem internen Application Load Balancer verwendet, um Anwendungsanfragen an die primäre Instanz weiterzuleiten.

Architektur für ein IBM Db2-System in Google Cloud mit Hochverfügbarkeit und Notfallwiederherstellung

Kostenoptimierung

Dieser Abschnitt enthält Informationen zur Lizenzierung, zu Rabatten und zur Schätzung der Arbeitslastgröße.

Lizenzierung

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 Lizenzen verwenden. Weitere Informationen finden Sie unter Benutzerdefinierte Betriebssystem-Images.

Informationen zu Lizenzen für SAP ASE in Google Cloud finden Sie im Abschnitt „SAP-Lizenzen“ im Planungsleitfaden für SAP ASE.

Für die Bereitstellung von IBM Db2 for SAP in Google Cloud benötigen Sie eine eigene Lizenz. Sie können eine Lizenz von SAP oder IBM erwerben. Weitere Informationen zur Lizenzierung und zum Support finden Sie im SAP-Hinweis 1168456 – DB6: Supportprozess und Termine für die Supporteinstellung für IBM Db2 LUW.

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 Business Suite-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 Business Suite auf SAP ASE oder IBM Db2 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 ASE- oder IBM Db2-Daten in Google Cloud haben Sie folgende Möglichkeiten:

  • Sicherungen mit dem Backup- und DR-Dienst von Google Weitere Informationen finden Sie unter Datenbank oder Instanz und deren Logs schützen.
  • Sichern Sie auf einem Persistent Disk- oder Hyperdisk-Volume und laden Sie die Sicherungen dann in Cloud Storage hoch.
  • Erstellen Sie Snapshots des Laufwerks, auf dem das Verzeichnis /sybasebackup für SAP ASE oder das Verzeichnis /db2backup für IBM Db2 gehostet wird.
SAP ASE sichern und wiederherstellen

Sie haben folgende Möglichkeiten, um eine IBM Db2-Datenbank in Google Cloud zu sichern und wiederherzustellen:

  • Sicherung und Wiederherstellung mit Laufwerken: Sie können die flexiblen Sicherungs- und Wiederherstellungsmechanismen von SAP ASE in Kombination mit den von der Compute Engine bereitgestellten nichtflüchtigen Speicher- und Hyperdisk-Typen verwenden. Wenn Sie Sicherungen für einen längeren Zeitraum speichern möchten, können Sie Cloud Storage verwenden.

    Das folgende Diagramm zeigt, wie Sicherungen einer SAP ASE-Datenbank auf Laufwerken und in Cloud Storage gespeichert werden:

    Diagramm zur Sicherung von SAP ASE-Daten auf Laufwerken und Cloud Storage

  • Sicherung und Wiederherstellung mit Laufwerks-Snapshots: Eine weitere Option für Sicherungen ist die Aufnahme von Snapshots ganzer Laufwerke mit dem Compute Engine-Feature für Laufwerks-Snapshots. Sie können beispielsweise geplante Snapshots des Laufwerks erstellen, das das Verzeichnis /sybasebackup hostet, um sie bei einer Notfallwiederherstellung zu verwenden. Es ist auch möglich, Laufwerk-Snapshots zu verwenden, um Ihr SAP ASE-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:

    Diagramm zur Sicherung von SAP ASE-Daten mit Laufwerk-Snapshots.

IBM Db2-Datenbank sichern

Sie haben folgende Möglichkeiten, eine IBM Db2-Datenbank zu sichern:

  • Verwenden Sie die von IBM bereitgestellten Online- und Offlinemodi:
    • Online-Modus: In diesem Modus können Nutzer weiterarbeiten, während die Datenbanksicherung erstellt wird.
    • Offline-Modus: In diesem Modus wird die Datenbank vollständig heruntergefahren, sodass sie für Nutzer nicht verfügbar ist, während die Sicherung erstellt wird.

  • IBM Db2-Datenbank mithilfe von Laufwerk-Snapshots sichern und wiederherstellen: Eine weitere Option für Sicherungen ist die Aufnahme von Snapshots ganzer Laufwerke mit dem Compute Engine-Feature für Laufwerks-Snapshots. Sie können beispielsweise geplante Snapshots des Laufwerks erstellen, das das Verzeichnis /db2backup hostet, um sie bei einer Notfallwiederherstellung zu verwenden. Sie können Laufwerk-Snapshots auch verwenden, um Ihr IBM Db2-Daten-Volume 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:

    Diagramm zur Sicherung von SAP ASE-Daten mit Laufwerk-Snapshots.

Der Vorgang zum Erstellen der Datenbanksicherung hängt davon ab, wie viele Partitionen Ihre IBM Db2-Datenbank hat:

  • Datenbank mit einer Partition: In dieser Konfiguration können Sie eine Sicherung erstellen, indem Sie die folgenden Schritte ausführen:

    1. Melden Sie sich als db2DB_SID-Nutzer bei Ihrem Datenbankserver an.

    2. Führen Sie dazu diesen Befehl aus:

      db2 backup db DB_SID

      Ersetzen Sie DB_SID durch die Datenbanksystem-ID (SID).

  • Datenbank mit mehreren Partitionen: In dieser Konfiguration können Sie eine Sicherung erstellen, indem Sie die folgenden Schritte ausführen:

    1. Melden Sie sich als db2DB_SID-Nutzer bei Ihrem Datenbankserver an.

    2. Führen Sie dazu diesen Befehl aus:

      db2 "backup db DB_SID on ALL DBPARTITIONNUMS..."

      Ersetzen Sie DB_SID durch die Datenbanksystem-ID (SID).

    Sie können auch das von IBM bereitgestellte Tool „DBA Cockpit“ verwenden, um eine Datenbanksicherung zu erstellen. Weitere Informationen zum Sichern einer IBM Db2-Datenbank finden Sie im SAP-Dokument Datenbanksicherung ausführen.

IBM Db2-Datenbank wiederherstellen

Sie können Ihre IBM Db2-Datenbank aus einer erfolgreichen Sicherung wiederherstellen. Die Wiederherstellung der Datenbank hängt vom Zugriff auf eine aktuelle Verlaufsdatei ab, da von dort aus auf alle Informationen zu Sicherungs-Images und Logdateien zugegriffen wird.

  • Führen Sie die folgenden Schritte aus, um Ihre IBM Db2-Datenbank aus einer Sicherung wiederherzustellen:

    1. Melden Sie sich als db2DB_SID- oder SAP_SIDadm-Nutzer beim Datenbankserver an.

    2. Führen Sie dazu diesen Befehl aus:

      db2 RECOVER DB DB_SID

      Ersetzen Sie DB_SID durch die Datenbanksystem-ID (SID).

  • So stellen Sie Ihre IBM Db2-Datenbank zu einer bestimmten Zeit wieder her:

    1. Melden Sie sich als db2DB_SID- oder SAP_SIDadm-Nutzer beim Datenbankserver an.

    2. Führen Sie dazu diesen Befehl aus:

      db2 RECOVER DB DB_SID to LOCAL_TIME_ON_DB_SERVER

      Ersetzen Sie Folgendes:

      • DB_SID: die Datenbanksystem-ID (SID)
      • LOCAL_TIME_ON_DB_SERVER: die lokale Zeit auf Ihrem Datenbankserver

    Weitere Informationen zum Wiederherstellen einer IBM Db2-Datenbank finden Sie im SAP-Dokument Datenbankwiederherstellung mit dem Befehl RECOVER.

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 Business Suite-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. Weitere Informationen finden Sie 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.

Informationen zur Dimensionierung einer SAP ASE-Datenbank finden Sie im SAP-Dokument SAP ASE-Größenanpassung.

Informationen zur Größenanpassung einer IBM Db2-Datenbank finden Sie in der SAP-Größenbenchmark.

Informationen zu den Hardwareanforderungen für den Betrieb von SAP ASE oder IBM Db2 mit verschiedenen Betriebssystem- und SAP NetWeaver-Versionen finden Sie im SAP-Dokument Leitfaden-Finder für SAP NetWeaver und ABAP-Plattform.

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 ASE- oder IBM Db2-Bereitstellungen in Compute Engine. Es ist auch möglich, dass ihr spezieller Anwendungsfall, die Sicherheitsanforderungen oder -einstellungen zusätzliche Schnittstellen zur Trennung des Traffics benötigen, z. B. Internettraffic, interner Traffic der SAP ASE- oder IBM Db2-HADR-Replikation 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.

Weitere Informationen finden Sie unter:

Bereitstellung

Dieser Abschnitt enthält Informationen zur Bereitstellung von SAP Business Suite in SAP ASE oder IBM Db2 in Google Cloud.

Wichtige SAP-Hinweise vor der Bereitstellung

Lesen Sie vor dem Bereitstellen eines SAP Business Suite-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.

Weitere Informationen zur Installation von SAP ASE oder IBM Db2 finden Sie hier:

Bereitstellungsautomatisierung

SAP ASE-Bereitstellung automatisieren

Mit den von Google Cloud bereitgestellten Terraform-Konfigurationen können Sie die Bereitstellung der Infrastruktur automatisieren, die zum Ausführen von SAP ASE und SAP NetWeaver unter Linux in Google Cloud erforderlich ist. Weitere Informationen finden Sie in den Bereitstellungsleitfäden für Ihr Szenario.

Informationen zur Planung Ihrer SAP ASE-Bereitstellung finden Sie unter:

IBM Db2-Bereitstellung automatisieren

Sie können die Bereitstellung der Infrastruktur, die zum Ausführen von IBM Db2 und SAP NetWeaver unter Linux in Google Cloud erforderlich ist, mithilfe der von Google Cloud bereitgestellten Terraform-Konfigurationen automatisieren. Weitere Informationen finden Sie in den Bereitstellungsleitfäden für Ihr Szenario.

Informationen zur Planung Ihrer SAP ASE-Bereitstellung finden Sie unter:

Nächste Schritte