IBM Db2 für SAP – Planungsanleitung

Anhand der Informationen in dieser Anleitung können Sie die Installation eines IBM Db2 Advanced Enterprise Server Edition-Systems (IBM Db2 AESE) planen, das SAP-Anwendungen in Google Cloud unterstützt.

Informationen zum Bereitstellen von IBM Db2 mit SAP-Produkten in Google Cloud finden Sie unter:

Weitere Informationen von SAP zu IBM Db2 erhalten Sie über die Links auf der Seite SAP auf IBM Db2 für Linux, UNIX und Windows.

Weitere Informationen zu den von SAP für die Ausführung in Google Cloud zertifizierten Produkten, einschließlich IBM Db2, finden Sie unter SAP-Hinweis 2456432 – SAP-Anwendungen in Google Cloud: Unterstützte Produkte und Google Cloud-Maschinentypen

Grundlagen von Google Cloud

Google Cloud setzt sich aus vielen cloudbasierten Diensten und Produkten zusammen. Wenn Sie SAP-Produkte in Google Cloud ausführen, verwenden Sie in erster Linie die IaaS-basierten Dienste, die über Compute Engine und Cloud Storage verfügbar sind, sowie verschiedene plattformweite Features wie etwa Tools.

Wichtige Konzepte und Begriffe finden Sie in der Übersicht zur Google Cloud Platform. Zur Vereinfachung und zum besseren Verständnis werden einige Informationen aus dem Überblick in diesem Leitfaden wiederholt.

Eine Übersicht über Überlegungen, die größere Unternehmen bei der Ausführung in Google Cloud berücksichtigen sollten, finden Sie im Google Cloud-Architektur-Framework.

Mit Google Cloud interagieren

Zur Interaktion mit der Plattform und Ihren Ressourcen in der Cloud bietet Google Cloud vor allem drei Möglichkeiten:

  • Die Google Cloud Console, eine webbasierte Benutzeroberfläche.
  • Das gcloud-Befehlszeilentool, das eine Obermenge der Funktionen darstellt, die die Google Cloud Console bietet.
  • Clientbibliotheken, die APIs für den Zugriff auf Dienste und für die Verwaltung von Ressourcen bereitstellen. Clientbibliotheken sind hilfreich, wenn Sie Ihre eigenen Tools erstellen.

Google Cloud-Dienste

Für SAP-Bereitstellungen werden in der Regel einige oder alle der folgenden Google Cloud-Dienste 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.

Preise und Kontingente

Mit dem Preisrechner können Sie Ihre Nutzungskosten abschätzen. Weitere Preisinformationen finden Sie in der jeweiligen Preisübersicht für Compute Engine, Cloud Storage und Google Cloud Observability.

Für Google Cloud-Ressourcen gelten Kontingente. Wenn Sie Maschinen mit hoher CPU- und Arbeitsspeicherleistung verwenden möchten, müssen Sie unter Umständen zusätzliche Kontingente anfordern. Weitere Informationen finden Sie unter Compute Engine-Ressourcenkontingente.

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.

Bereitstellungsarchitektur

Eine IBM Db2-Installation, die eine Datenbank mit einer einzelnen Partition beinhaltet, setzt sich in Google Cloud aus folgenden Komponenten zusammen:

  • Einer Compute Engine-VM, auf der die IBM Db2-Datenbank ausgeführt wird.

  • Mindestens einem nichtflüchtigen Laufwerk für Folgendes:

    • Root-Laufwerk.
    • Datenbank-ID-Volume (/db2/<DBSID>/),
    • Instanz-Volume (/db2/db2<dbsid>), das das Basisverzeichnis des Nutzers db2<dbsid>, die IBM Db2-Instanzdaten für <DBSID> und die IBM Db2-Software enthält.
    • Log-Volume (/db2/<DBSID>/log_dir), das mindestens die Logdateien der Onlinedatenbank enthält.
    • Dump-/Diagnose-Volume (/db2/<DBSID>/db2dump), das Db2-Diagnoselogdateien, Db2-Dumpdateien und weitere Informationen für Dienstentwickler enthält.
    • Daten-Volume (/db2/<DBSID>/sapdata<n> oder /db2/<DBSID>/sapdata/sapdata<n>). Dies ist der Speicherort für Tablespaces mit dem Containertyp Database Managed Space (DMS) FILE oder Tablespaces mit automatischem Speicher von Db2.
    • Volume für temporäre Tablespaces (/db2/<DBSID>/saptmp<n> oder /db2/ <DBSID>/saptmp/saptmp<n>). Dies ist der Speicherort für temporäre Tablespaces.

Je nach Anforderungen Ihrer Installation müssen Sie möglicherweise auch Folgendes einbeziehen:

  • Ein NAT-Gateway. Mit einem NAT-Gateway können Sie für Ihre VMs eine Internetverbindung bereitstellen und gleichzeitig den direkten Zugriff aus dem Internet auf diese VMs verhindern. Eine VM lässt sich auch als Bastion Host konfigurieren, mit dem Sie SSH-Verbindungen zu den anderen VMs in Ihrem privaten Subnetz einrichten können. Weitere Informationen finden Sie unter NAT-Gateways und Bastion Hosts.
  • Ein Sicherungs-Volume zum Speichern von Warm-Sicherungen.
  • Ein Speicher-Volume zum Speichern von Logarchiven.

Für andere Anwendungsfälle sind möglicherweise zusätzliche Geräte oder Datenbanken erforderlich. Weitere Informationen finden Sie hier:

Ressourcenanforderungen

Das Ausführen von IBM Db2 mit SAP in Google Cloud ist größtenteils mit dem Ausführen in Ihrem eigenen Rechenzentrum vergleichbar. Trotzdem müssen Sie sich Gedanken über Rechenressourcen, Speicher und Netzwerke machen.

Weitere Informationen finden Sie in der entsprechenden Installationsanleitung für Ihr SAP-System mit IBM Db2.

VM-Konfiguration

IBM Db2 ist für das Ausführen auf allen Compute Engine-Maschinentypen zertifiziert, einschließlich benutzerdefinierter Typen. Für die meisten Fälle empfiehlt sich ein Maschinentyp mit zwei oder mehr virtuellen CPUs.

Informationen zu verschiedenen Compute Engine-Maschinentypen und ihren Anwendungsfällen finden Sie unter Maschinentypen in der Compute Engine-Dokumentation.

CPU-Konfiguration

Die Anzahl der erforderlichen vCPUs hängt von der Anwendungslast des IBM Db2 LUW-Systems ab. Sie sollten Ihrer IBM Db2-Installation mindestens zwei vCPUs zuordnen. Folgen Sie der Anleitung in der Dokumentation SAP auf IBM Db2 für Linux, UNIX und Windows, um Ihre Rechenressourcen bedarfsorientiert anzupassen, sodass Ihr IBM Db2-System vorhandene Ressourcen optimal nutzen kann.

Arbeitsspeicherkonfiguration

Ihre IBM Db2-VM sollte mindestens 4 GB RAM pro vCPU haben. Ordnen Sie von dieser RAM-Menge ungefähr 80 % Ihrem IBM Db2-System und den Rest dem Betriebssystem zu, unter dem IBM Db2 ausgeführt wird.

Die optimale Größe für den jeweiligen Anwendungsfall hängt von der Komplexität der ausgeführten Abfragen, der Menge Ihrer Daten, dem Parallelitätsgrad und dem erwarteten Leistungsniveau ab. Weitere Hinweise zur Optimierung Ihrer Arbeitsspeicherkonfiguration finden Sie in der Dokumentation SAP auf IBM Db2 für Linux, UNIX und Windows.

Speicherkonfiguration

Standardmäßig hat jede Compute Engine-VM ein kleines nichtflüchtiges Root-Laufwerk, auf dem sich das Betriebssystem befindet. Darüber hinaus sollten Sie zusätzliche Laufwerke für Ihre Datenbank, Ihre Logs und Ihre gespeicherten Prozeduren erstellen, verbinden, formatieren und bereitstellen.

Ihre Laufwerkgröße und Leistungsanforderungen hängen von Ihrer Anwendung ab. Passen Sie die Größe jedes Geräts an Ihre Bedürfnisse an.

Weitere Informationen zu den Optionen für nichtflüchtige Speicher für IBM Db2 finden Sie unter Nichtflüchtige Speicher.

Hinweise von SAP zur Laufwerksgröße finden Sie unter:

Unterstützte IBM Db2-Versionen

Sie müssen die von SAP zertifizierten Stufen der IBM Db2-Software-Fixpacks (FPs) verwenden. Die Verwendung anderer IBM Db2-Softwarestufen ist nicht zulässig.

Weitere Informationen finden Sie im SAP-Hinweis 101809 – DB6: Unterstützte Db2-Versionen und Fixpack-Stufen.

Unterstützte IBM Db2-Funktionen

SAP unterstützt die meisten IBM Db2-Features in Google Cloud. Die folgenden Funktionen werden jedoch nicht unterstützt:

  • Db2-Datenbanken mit mehreren Partitionen
  • IBM Db2-Funktion pureScale

Unterstützte Betriebssysteme

SAP hat Google Cloud zur Ausführung von IBM Db2 unter den folgenden Images der Betriebssysteme SUSE Linux Enterprise Server (SLES), Red Hat Enterprise Linux (RHEL) und Windows Server zertifiziert:

  • SLES 12 SP2 und höher
  • RHEL 7.4
  • Windows Server 2012 R2 und höher

Weitere Informationen zu Compute Engine-Images finden Sie hier.

Überlegungen zur Bereitstellung

Regionen und Zonen

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, und entspricht dem Standort eines Rechenzentrums. Jede Region hat eine oder mehrere Zonen.

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 Ressourcen zugänglich, die in derselben Zone angesiedelt sind.

Google Cloud-Regionen und -Zonen

Berücksichtigen Sie bei der Auswahl von Regionen und Zonen für Ihre VMs Folgendes:

  • Den Standort Ihrer Nutzer und Ihrer internen Ressourcen, beispielsweise Ihres Rechenzentrums oder Unternehmensnetzwerks. Wählen Sie zum Reduzieren der Latenz einen Standort aus, der sich in unmittelbarer Nähe Ihrer Nutzer und Ressourcen befindet.
  • Den Standort Ihrer anderen SAP-Ressourcen. Ihre SAP-Anwendung und Ihre Datenbank müssen sich in derselben Zone befinden.

Nichtflüchtige Speicher

Nichtflüchtige Speicher sind robuste Blockspeichergeräte, die ähnlich wie physische Laufwerke in Computern oder Servern funktionieren.

Compute Engine bietet verschiedene Arten von nichtflüchtigen Speichern. Jeder Typ hat unterschiedliche Leistungsmerkmale. Google Cloud verwaltet die zugrunde liegende Hardware nichtflüchtiger Speicher, um die Datenredundanz zu gewährleisten und die Leistung zu optimieren.

Sie können einen der folgenden Compute Engine-Typen für nichtflüchtige Speicher verwenden:

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

Die Leistung von SSD- und abgestimmten nichtflüchtigen Speichern wird automatisch mit der Größe skaliert, sodass Sie die Leistung anpassen können, indem Sie die Größe der vorhandenen nichtflüchtigen Speicher anpassen oder einer VM weitere nichtflüchtige Speicher hinzufügen.

Die Art der verwendeten VM und die Anzahl der darin enthaltenen vCPUs wirken sich auch auf die Leistung des nichtflüchtigen Speichers aus.

Nichtflüchtige Speicher sind unabhängig von Ihren VMs. Sie können sie deshalb trennen oder verschieben, wenn Sie Daten aufbewahren möchten, auch wenn Sie die VMs löschen.

Weitere Informationen zu den verschiedenen Arten von nichtflüchtigen Compute Engine-Speichern, ihrer Leistungsmerkmale und ihrer Verwendung finden Sie in der Compute Engine-Dokumentation:

Lokale SSDs (flüchtig)

In Google Cloud stehen auch lokale SSD-Laufwerke zur Verfügung. Obwohl lokale SSDs einige Vorteile gegenüber nichtflüchtigen Speichern bieten, sollten Sie sie nicht als Teil eines IBM Db2-Systems verwenden. VM-Instanzen mit verbundenen lokalen SSDs können nicht beendet und dann wieder gestartet werden.

NAT-Gateways und Bastion Hosts

Falls 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 das Internet erreichen können. Sie können über SSH keine direkte Verbindung zu einer komplett 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 verwenden

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 würde den Rahmen dieses Artikels sprengen. Einige der ersten Schritte können jedoch folgende sein:

  • Einschränken des CIDR-Bereichs der Quell-IP-Adressen, 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 sollten Sie die Ziel-VM über die SSH-Agent-Weiterleitung ansteuern und nicht den privaten Schlüssel der Ziel-VM auf dem Bastion Host 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 ausgehenden Traffic verwenden

Wenn einer VM keine externe IP-Adresse zugewiesen wurde, kann sie keine direkte Verbindung zu externen Diensten herstellen, einschließlich anderer Google Cloud-Dienste. Damit Dienste im Internet für diese VMs erreichbar sind, können Sie ein NAT-Gateway einrichten und konfigurieren. Das NAT-Gateway ist eine VM, die Traffic im Namen von jeder anderen VM im Netzwerk weiterleiten kann. Sie sollten ein NAT-Gateway pro Netzwerk einrichten. Beachten Sie, dass ein aus einer einzigen VM bestehendes NAT-Gateway keine Hochverfügbarkeit bietet und keinen hohen Trafficdurchsatz für mehrere VMs unterstützt. Eine Anleitung zur Einrichtung einer VM als NAT-Gateway finden Sie in der IBM Db2-Bereitstellungsanleitung für SAP NetWeaver.

Benutzerdefinierte Images

Wenn Ihr System einsatzbereit ist, können Sie benutzerdefinierte Images erstellen. Sie sollten dies tun, wenn Sie den Zustand Ihres nichtflüchtigen Root-Laufwerks ändern und in der Lage sein möchten, den neuen Zustand schnell wiederherzustellen. Legen Sie sich außerdem zum Verwalten Ihrer benutzerdefinierten Images einen Plan zurecht. Weitere Informationen finden Sie unter Best Practices für die Image-Verwaltung.

Nutzeridentifizierung und Ressourcenzugriff

Bei der Planung der Sicherheit für eine SAP-Bereitstellung in Google Cloud müssen Sie Folgendes ermitteln:

  • Die Nutzerkonten und Anwendungen, die Zugriff auf die Google Cloud-Ressourcen in Ihrem Google Cloud-Projekt benötigen
  • Die spezifischen Google Cloud-Ressourcen in Ihrem Projekt, auf die jeder Nutzer zugreifen muss

Sie müssen jeden Nutzer Ihrem Projekt hinzufügen, indem Sie dessen Google-Konto-ID in das Projekt als Hauptkonto einfügen. Für ein Anwendungsprogramm, das Google Cloud-Ressourcen verwendet, erstellen Sie ein Dienstkonto, das eine Nutzeridentität für das Programm innerhalb Ihres Projekts bereitstellt.

Compute Engine-VMs haben ein eigenes Dienstkonto. Alle Programme, die auf einer VM ausgeführt werden, können das VM-Dienstkonto verwenden, solange es die Ressourcenberechtigungen hat, die das Programm benötigt.

Nachdem Sie die Google Cloud-Ressourcen ermittelt haben, die jeder Nutzer benötigt, erteilen Sie den Nutzern die Berechtigung, diese Ressourcen zu verwenden. Dazu weisen Sie dem jeweiligen Nutzer ressourcenspezifische Rollen zu. Prüfen Sie die vordefinierten IAM-Rollen, die IAM für jede Ressource bereitstellt, und weisen Sie jedem Nutzer Rollen zu, die genau so viele Berechtigungen enthalten, wie für das Erledigen der Aufgaben oder Funktionen des Nutzers erforderlich sind.

Wenn Sie eine detailliertere oder restriktivere Kontrolle über Berechtigungen benötigen, als die vordefinierten IAM-Rollen bieten, können Sie benutzerdefinierte Rollen erstellen.

Weitere Informationen zu den IAM-Rollen, die SAP-Programme in Google Cloud benötigen, finden Sie unter Identitäts- und Zugriffsverwaltung für SAP-Programme in Google Cloud.

Informationen zur Identitäts- und Zugriffsverwaltung für SAP in Google Cloud finden Sie in der Übersicht über die Identitäts- und Zugriffsverwaltung 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 mithilfe von Firewalls zu beschränken. 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 "default", das für jedes Projekt automatisch erstellt wird und Standardfirewallregeln besitzt.

Mithilfe von 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. So sollten Sie immer einen Bastion Host einrichten und SSH-Verbindungen in das 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 verwenden das IPv4-Protokoll. Für jedes Google Cloud-Projekt wird ein Standardnetzwerk mit vordefinierten Konfigurationen und Firewallregeln bereitgestellt. Sie sollten aber ein benutzerdefiniertes Subnetzwerk sowie Firewallregeln hinzufügen, die auf dem Modell der geringsten Berechtigungen basieren. Standardmäßig hat ein neu erstelltes Netzwerk keine Firewallregeln und somit keinen Netzwerkzugriff.

Je nach Ihren Anforderungen möchten Sie vielleicht zusätzliche Subnetzwerke hinzufügen, um Teile Ihres Netzwerks zu isolieren. In diesem Fall finden Sie weitere Informationen unter Subnetzwerke.

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 bietet der Tagging-Mechanismus die Möglichkeit, Firewalls gezielt für bestimmte VMs zu konfigurieren.

Einige SAP-Produkte wie SAP NetWeaver benötigen Zugriff auf bestimmte Ports. Sie sollten also unbedingt Firewallregeln erstellen, die den Zugriff auf die von SAP beschriebenen Ports zulassen.

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 die Notwendigkeit einer externen IP-Adresse von VM zu VM innerhalb desselben Netzwerks und über Subnetzwerke hinweg weiterleitet.

Damit der externe Zugriff auf Internetressourcen möglich ist, starten Sie eine VM ohne externe IP-Adresse und konfigurieren eine weitere virtuelle Maschine als NAT-Gateway. Für diese Konfiguration müssen Sie das NAT-Gateway als Route für Ihre SAP-Instanz hinzufügen. Weitere Informationen finden Sie unter NAT-Gateways und Bastion Hosts.

Cloud VPN

Mit einer VPN-Verbindung und IPsec können Sie über Cloud VPN eine sichere Verbindung von einem 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, wenn sie über das Internet übertragen werden. Mithilfe von Instanz-Tags auf Routen lässt sich dynamisch steuern, welche VMs Traffic durch das VPN senden können. Cloud VPN-Tunnel werden bei gleichbleibendem Preis monatlich berechnet. Hinzu kommen die Standardpreise für ausgehenden Traffic, die auch dann anfallen, wenn zwei Netzwerke im selben Projekt verbunden werden. Weitere Informationen finden Sie unter VPN-Übersicht und VPN-Routingoption auswählen.

Cloud Storage-Bucket sichern

Wenn Sie Ihre Daten- und Logsicherungen über Cloud Storage hosten, sollten Sie für die Datenübertragung von Ihren VMs zu Cloud Storage unbedingt TLS (HTTPS) verwenden. Damit sind die Daten während der Übertragung geschützt. Cloud Storage verschlüsselt inaktive Daten automatisch. Sie können Ihre eigenen Verschlüsselungsschlüssel angeben, wenn Sie mit einem eigenen Schlüsselverwaltungssystem arbeiten.

Zum Thema Sicherheit für Ihre SAP-Umgebung in Google Cloud stehen Ihnen folgende zusätzliche Ressourcen zur Verfügung:

Sicherung und Wiederherstellung

Sie müssen sich überlegen, wie Sie den Betriebszustand Ihres Systems im Ernstfall wiederherstellen können.

Informationen zur Sicherung und Wiederherstellung von IBM Db2-Systemen, die SAP unterstützen, finden Sie hier:

Allgemeine Hinweise zur Planung einer Notfallwiederherstellung mithilfe von Google Cloud finden Sie hier:

Automatisierung für IBM Db2-Bereitstellungen

Google Cloud bietet eine Terraform-Konfigurationsdatei, mit der Sie die Bereitstellung von Ressourcen für IBM Db2 mit Linux automatisieren können.

Die von Google Cloud für IBM Db2 bereitgestellte Konfiguration sap_db2.tf stellt die folgenden Ressourcen zur Verfügung:

  • Eine Compute Engine-VM-Instanz, die auf dem Maschinentyp Ihrer Wahl basiert
  • Ihr gewähltes Red Hat Enterprise Linux (RHEL)- oder SUSE Linux Enterprise Server (SLES)-Betriebssystem
  • Nichtflüchtige Compute Engine-Speicher
  • Den Google Cloud-Monitoring-Agent für SAP NetWeaver

Eine Anleitung zur Bereitstellungsautomatisierung finden Sie unter Automatisierte VM-Bereitstellung für IBM Db2 unter Linux mit Terraform.

IBM Db2-Cluster mit Hochverfügbarkeit (HA)

Sie können einen hochverfügbaren und ausfallsicheren IBM Db2-Cluster in Google Cloud einrichten, der von SAP unterstützt wird. Der Cluster wird von IBM Tivoli System Automation for Multiplatforms (TSAMP) konfiguriert und verwaltet und verwendet die IBM Db2-Funktion HADR zu Replikationszwecken.

Anwendungen stellen über eine Floating-IP-Adresse eine Verbindung zum primären IBM Db2-Server her. Im Falle eines Failovers ordnet TSAMP diese Adresse dem Standbyserver neu zu.

Die IBM Db2-Funktion HADR unterstützt bis zu drei Standbyserver. In Google Cloud müssen die Host-VMs im Cluster in derselben Region bereitgestellt sein, können sich jedoch in verschiedenen Zonen innerhalb der Region befinden.

Welche Komponenten von SAP für Db2-HA-Custer in Google Cloud unterstützt werden, ist unter SAP-Hinweis 2456432 – SAP-Anwendungen in Google Cloud: Unterstützte Produkte und Google Cloud-Maschinentypen aufgeführt.

Informationen zu den von SAP unterstützten IBM Db2-Funktionen finden Sie im SAP-Hinweis 1555903.

Bereitstellungsarchitekturen

Sie können die Host-VMs in einem IBM Db2-HA-Cluster in mehreren Compute Engine-Zonen in derselben Region oder gegebenenfalls in einer einzelnen Zone bereitstellen.

Die höchste Verfügbarkeit erzielen Sie, wenn Sie jede Host-VM in einer anderen Zone bereitstellen.

Das folgende Diagramm zeigt eine Bereitstellung in mehreren Zonen, bei der die Floating-IP-Adresse über eine statische Route implementiert wird.

Jeder Host eines Db2-HA-Clusters ist in einer anderen Zone bereitgestellt.

Das folgende Diagramm zeigt eine Bereitstellung in einer einzelnen Zone, bei der die Floating-IP-Adresse über eine Alias-IP-Adresse implementiert wird.

Beide Hosts eines Db2-HA-Clusters sind in derselben Zone bereitgestellt.

Erforderliche Dokumentation

Beim Bereitstellen eines IBM Db2-HA-Clusters für SAP sollten Sie sich an der SAP- und Google Cloud-Dokumentation orientieren.

Unter Umständen müssen Sie während der Installation der SAP- und IBM-Komponenten auf zusätzliche SAP- oder IBM-Dokumente zurückgreifen.

Besondere Anforderungen an einen IBM Db2-HA-Cluster in Google Cloud

In Google Cloud unterstützt SAP für IBM Db2-HA-Cluster nur die Betriebssysteme RHEL oder SLES.

Informationen zu den Google Cloud-Softwareanforderungen für die IBM Db2-Instanzen finden Sie unter Ressourcenanforderungen.

Verwenden Sie für IBM TSAMP die neueste verfügbare Version, die von Ihrer IBM Db2-Version und Ihrem Betriebssystem unterstützt wird.

Informationen zu allen anderen Hardware- und Softwareanforderungen finden Sie in der IBM Db2-Hochverfügbarkeitslösung: IBM Tivoli System Automation for Multiplatforms.

Floating-IP-Adressen für IBM Db2-HA-Cluster in Google Cloud

Ein IBM Db2-HA-Cluster für SAP verwendet eine Floating-IP-Adresse, die auch als "virtuelle IP-Adresse" oder "gemeinsame IP-Adresse" bezeichnet wird.

Die Floating-IP-Adresse für einen IBM Db2-HA-Cluster kann in Google Cloud entweder über eine Google Cloud-spezifische statische Route oder über eine Google Cloud-spezifische Alias-IP-Adresse implementiert werden.

Für IBM Db2-HA-Mehrzonencluster wird die Implementierung einer statischen Route empfohlen. Durch die Bereitstellung in mehreren Zonen wird gewährleistet, dass Ihr IBM Db2-System nicht durch einen Ausfall in einer einzelnen Zone lahmgelegt wird.

Wenn Ihre Netzwerkarchitektur jedoch keine statischen Routen unterstützt oder Sie Lösungen wie IP-Overlay oder komplexes Routing vermeiden müssen, können Sie Alias-IP-Adressen für einen IBM Db2-HA-Einzelzonencluster implementieren. Alias-IP-Adressen werden für Bereitstellungen in mehreren Zonen nicht empfohlen, da die Neuzuweisung des Alias im Falle eines zonalen Ausfalls nicht immer garantiert werden kann.

Je nachdem, ob Sie statische Routen oder Alias-IP-Adressen implementieren, unterscheiden sich die Anforderungen an die IP-Adresse, die Sie als Floating-IP-Adresse verwenden.

Bei Verwendung einer statischen Route muss die als Floating-IP-Adresse ausgewählte IP-Adresse folgende Anforderungen erfüllen:

  • Sie muss außerhalb der IP-Bereiche Ihrer vorhandenen VPN-Subnetze liegen, in denen sich die VMs befinden.
  • Sie darf nicht in Konflikt mit externen IP-Adressen in Ihrem erweiterten Netzwerk stehen.

Wenden Sie sich an Ihren Netzwerkadministrator, um eine geeignete IP-Adresse für die Implementierung einer statischen Route zu finden.

Bei Verwendung einer Alias-IP-Adresse müssen Sie eine IP-Adresse aus dem IP-Bereich Ihres Subnetzwerks als Floating-IP-Adresse reservieren.

Weitere Informationen zu Floating-IP-Adressen in Google Cloud finden Sie unter Best Practices für Floating-IP-Adressen.

SAP empfiehlt die Verwendung von Floating-IP-Adressen in IBM Db2-HA-Clustern. Automatic Client Reroute (ACR) wird von SAP unterstützt, sofern Sie alle Anforderungen und Einschränkungen dieser Methode berücksichtigen. Weitere Informationen finden Sie im SAP-Hinweis 1568539.

Netzwerk-Tiebreaker

IBM Db2-HA-Cluster senden gewöhnlich eine ICMP-Anfrage (Ping) an ein Netzwerk-Gateway, das als standardmäßiger Netzwerk-Tiebreaker fungiert und bestimmt, welcher Knoten bei einem Kommunikationsverlust zwischen den Knoten in einem Cluster übernehmen soll.

Da Netzwerk-Gateways in Google Cloud nicht auf ICMP-Anfragen reagieren, sollten Sie eine andere IP-Adresse verwenden, die kontaktiert werden kann und selbst hochverfügbar ist. Sie könnten beispielsweise die virtuelle IP-Adresse der Central Services-Instanz Ihrer Anwendung oder die Google-DNS-Adresse 8.8.8.8 verwenden.

Wenn der Netzwerk-Tiebreaker während der Einrichtung nicht auf ICMP-Anfragen reagieren kann, schlägt die Einrichtung fehl.

Andere Netzwerk-Tiebreaker existieren bereits und werden von IBM definiert. Weitere Informationen finden Sie unter Tiebreaker konfigurieren.

Einrichtungstools für einen Db2-HA-Cluster

Zur Konfiguration eines IBM Db2-HADR-Clusters können Sie eines der folgenden Tools von SAP und IBM verwenden:

  • SAP-Clustereinrichtungstool (sapdb2cluster.sh)
  • Konfigurationsdienstprogramm für IBM Db2-Hochverfügbarkeitsinstanzen (db2haicu)

SAP-Db2-Clustereinrichtungstool (sapdb2cluster.sh)

SAP empfiehlt das von SAP bereitgestellte Clustereinrichtungstool sapdb2cluster.sh zum Konfigurieren und Erstellen eines Db2-HA-Clusters. Dieses Tool wird auch in der Google Cloud-Bereitstellungsanleitung verwendet. Das Clustereinrichtungstool vereinfacht die Clustereinrichtung erheblich und gewährleistet, dass die Anforderungen von SAP erfüllt werden.

Bevor Sie den HA-Cluster mit dem SAP-Clustereinrichtungstool erstellen, wird in einem der Schritte der Google Cloud-Bereitstellungsanleitung eine geringfügige Änderung an diesem Tool vorgenommen, wodurch die Erstellung der Standardressourcenklasse IBM.ServiceIP mit dem Tool übersprungen wird.

Ressourcen, die aus der Ressourcenklasse IBM.ServiceIP von IBM TSAMP erstellt werden, geben Gratuitous-ARP-Anfragen aus, die in VPC-Netzwerken in Google Cloud nicht unterstützt werden. Informationen dazu finden Sie unter Herausforderungen bei der Migration von Floating-IP-Adressen zu Compute Engine.

Informationen zum Download der neuesten Version des Clustereinrichtungstools finden Sie im SAP-Hinweis 960843.

Konfigurationsdienstprogramm für IBM Db2-Hochverfügbarkeitsinstanzen (db2haicu)

Als Alternative zum SAP-Clustereinrichtungstool können Sie das IBM-Dienstprogramm db2haicu verwenden, das ebenfalls eine interaktive Oberfläche bietet. Das SAP-Clustereinrichtungstool verwendet db2haicu zur Clustereinrichtung.

Bei Verwendung des Dienstprogramms db2haicu müssen Sie zuerst die HADR-Beziehung konfigurieren, bevor Sie den Cluster mit dem Dienstprogramm db2haicu einrichten können. Das allgemeine Einrichtungsverfahren mit dem Dienstprogramm db2haicu mag komplizierter sein, ermöglicht jedoch eine bessere Anpassung an komplexe Netzwerkkonfigurationen oder andere umgebungsspezifische Anforderungen.

Folgen Sie immer den SAP- und IBM-Richtlinien, wenn Sie das Dienstprogramm db2haicu verwenden.

Weitere Informationen zu db2haicu finden Sie in der IBM Db2-Dokumentation.

Google Cloud-Hilfsskript für die Einbindung von IBM TSAMP-Clustern

Damit der IBM Db2-HA-Cluster die entsprechenden Google Cloud API-Befehle zum Starten, Stoppen und Überwachen der TSAMP-Ressource für die Floating-IP-Adresse aufrufen kann, müssen Sie ein Hilfsskript von Google Cloud auf die Host-VMs herunterladen. Sie verweisen dann auf dieses Google Cloud-Hilfsskript, wenn Sie die Ressource für die Floating-IP-Adresse in IBM TSAMP erstellen.

Lizenzen

Dieser Abschnitt enthält Informationen zu Lizenzbestimmungen.

IBM Db2-Lizenzen

Wenn Sie IBM Db2 in Google Cloud ausführen, müssen Sie eine eigene Lizenz verwenden (BYOL). Sie können Db2-Lizenzen von SAP oder IBM beziehen. Weitere Informationen zur Lizenzierung und zum Support finden Sie in folgenden SAP-Hinweisen:

Weitere Informationen zur SAP-Lizenzierung erhalten Sie von SAP direkt.

Betriebssystemlizenzen

In Compute Engine gibt es zwei Möglichkeiten, SLES, RHEL und Windows Server zu lizenzieren:

  • Bei der Pay-As-You-Go-Lizenzierung ist die Lizenzierung in den stündlich abgerechneten Kosten für Ihre Compute Engine-VMs inbegriffen. Google verwaltet die Lizenzlogistik. Ihre Kosten pro Stunde sind höher, können jedoch völlig flexibel an den jeweiligen Bedarf angepasst werden. Dies ist das Lizenzmodell für öffentliche Google Cloud-Images, zu denen SLES, RHEL und Windows Server gehören.

  • Mit BYOL sind die Kosten für Ihre Compute Engine-VMs niedriger, da die Lizenzierung nicht inbegriffen ist. Sie müssen eine vorhandene Lizenz migrieren oder eine eigene Lizenz erwerben. Dies bedeutet, dass Sie im Voraus bezahlen müssen und weniger flexibel sind.

Support

Wenden Sie sich bei Problemen mit der Infrastruktur oder den Diensten von Google Cloud an Customer Care. Kontaktdaten finden Sie in der Google Cloud Console auf der Seite Supportübersicht. Wenn Customer Care feststellt, dass sich um ein Problem Ihres SAP-Systems handelt, werden Sie an den SAP-Support verwiesen.

Reichen Sie bei Problemen in Zusammenhang mit SAP-Produkten Ihre Supportanfrage beim SAP-Support ein. SAP wertet das Support-Ticket aus und leitet es, wenn es sich um ein Problem mit der Google Cloud-Infrastruktur handelt, gegebenenfalls an die entsprechende Google Cloud-Komponente in seinem System weiter: BC-OP-LNX-GOOGLE oder BC-OP-NT-GOOGLE.

Supportanforderungen

Bevor Sie Support für SAP-Systeme sowie für die Infrastruktur und Dienste von Google Cloud erhalten können, müssen Sie die Mindestanforderungen für den Supportplan erfüllen.

Weitere Informationen zu den Mindestsupportanforderungen für SAP in Google Cloud finden Sie hier:

Informationen zum SAP-Support für Db2 finden Sie im SAP-Hinweis 1168456 – DB6: Supportprozess und Termine für die Supporteinstellung für IBM Db2 LUW

Nächste Schritte

Informationen zum Bereitstellen von IBM Db2 in Google Cloud finden Sie unter:

Bereitstellungsanleitung für IBM Db2-Hochverfügbarkeitscluster für SAP zum Bereitstellen eines IBM Db2-HA-Clusters in Google Cloud