Planungsleitfaden für SAP HANA

Dieser Leitfaden bietet einen Überblick darüber, was für die Ausführung von SAP HANA in Google Cloud erforderlich ist, und enthält nützliche Details für die Planung der Implementierung eines neuen SAP HANA-Systems.

Weitere Informationen zum Bereitstellen von SAP HANA in Google Cloud finden Sie unter:

• Informationen zur Bereitstellung einzelner Hosts mit vertikaler Skalierung sowie mehrerer Hosts mit horizontaler Skalierung finden Sie unter:
  • Terraform: Bereitstellungsanleitung für SAP HANA mit vertikaler Skalierung
  • Deployment Manager: SAP HANA-Bereitstellungsanleitung für die vertikale Skalierung
• Informationen zu Systemen mit horizontaler Skalierung und automatischem Host-Failover finden Sie unter:
  • Terraform: Bereitstellungsanleitung für SAP HANA-Systeme zur horizontalen Skalierung mit automatischem Host-Failover
  • Deployment Manager: Bereitstellungsleitfaden für SAP HANA-Systeme mit horizontaler Skalierung und automatischem Host-Failover
• Informationen zu Konfigurationen von Hochverfügbarkeitsclustern mit vertikaler Skalierung finden Sie unter:
  • Terraform: Konfigurationsleitfaden für SAP HANA-Hochverfügbarkeitscluster mit vertikaler Skalierung
  • Deployment Manager: Konfigurationsanleitung für SAP HANA-Hochverfügbarkeitscluster
  • Manuelle Konfiguration eines vertikal skalierbaren HA-Clusters in RHEL
  • Manuelle Konfiguration eines vertikal skalierbaren HA-Clusters in SLES
• Informationen zu Konfigurationen von Hochverfügbarkeitsclustern mit horizontaler Skalierung finden Sie unter:
  • Terraform: Konfigurationsanleitung für SAP HANA-Hochverfügbarkeitscluster mit horizontaler Skalierung
  • Manuelle Konfiguration eines horizontal skalierbaren HA-Clusters in SLES

Informationen zu SAP HANA in Google Cloud

SAP HANA ist eine spaltenorientierte, relationale In-Memory-Datenbank, die leistungsstarke Analysen und Echtzeitdatenverarbeitung bietet. Kunden können auf einfache Bereitstellung, hohe Skalierbarkeit und redundante Google Cloud-Infrastrukturfunktionen zurückgreifen, um geschäftskritische Arbeitslasten auszuführen. Google Cloud bietet eine Reihe physischer Assets wie Computer und Laufwerke sowie virtuelle Ressourcen wie Compute Engine-VMs in Google-Rechenzentren auf der ganzen Welt.

SAP HANA wird in Google Cloud auf virtuellen Maschinen bereitgestellt, die in Compute Engine ausgeführt werden. Compute Engine-VMs stellen nichtflüchtige Speicher bereit, die ähnlich funktionieren wie physische Festplatten in einem Desktop oder Server. Sie werden jedoch automatisch von Compute Engine verwaltet, um Datenredundanz und optimale Leistung sicherzustellen.

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.

Wichtig: Achten Sie bei Verwendung der gcloud CLI darauf, dass Sie immer die aktuelle Version verwenden. Eine Anleitung zur Installation der aktuellen Version der gcloud CLI finden Sie in der gcloud-Installationsanleitung.

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.

Ressourcenanforderungen

Zertifizierte Maschinentypen für SAP HANA

Für SAP HANA zertifiziert SAP nur einen Teil der Maschinentypen, die in Google Cloud verfügbar sind.

Die von SAP für SAP HANA zertifizierten Maschinentypen umfassen sowohl Compute Engine-VMs als auch Bare Metal-Maschinen für Bare-Metal-Lösung.

Benutzerdefinierte Konfigurationen der VM-Typen n1- und n2-highmem für allgemeine Zwecke sind ebenfalls von SAP zertifiziert. Weitere Informationen finden Sie unter Zertifizierte benutzerdefinierte VM-Typen für SAP HANA.

Die Betriebssysteme, die für die Verwendung mit HANA auf den einzelnen Maschinentypen zertifiziert sind, finden Sie unter Zertifizierte Betriebssysteme für SAP HANA.

Einige Maschinentypen sind möglicherweise nicht in allen Google Cloud-Regionen verfügbar. Unter Verfügbare Regionen und Zonen können Sie die regionale Verfügbarkeit einer virtuellen Compute Engine-Maschine prüfen. Bare Metal Solution-Maschinen, die für SAP HANA zertifiziert sind, finden Sie unter Regionale Verfügbarkeit von Bare Metal Solution-Maschinen für SAP HANA.

SAP listet die zertifizierten Instanztypen für SAP HANA im Verzeichnis zertifizierter und unterstützter SAP HANA-Hardware auf.

Weitere Informationen zu verschiedenen Compute Enginge-VM-Typen und ihren Anwendungsfällen finden Sie unter Maschinentypen.

Zertifizierte Compute Engine-VMs für SAP HANA

In der folgenden Tabelle sind die von SAP für SAP HANA zertifizierten Compute Engine-VMs aufgeführt:

Hinweis: Das Präfix in den folgenden Maschinennamen wurde von "n1" in "m1" geändert, damit deutlicher erkennbar ist, dass die Familie speicheroptimierter Maschinentypen gemeint ist:

• n1-megamem-96 ist jetzt m1-megamem-96
• n1-ultramem-40 ist jetzt m1-ultramem-40
• n1-ultramem-80 ist jetzt m1-ultramem-80
• n1-ultramem-160 ist jetzt m1-ultramem-160

Die Maschinen selbst sind gleich geblieben. Auch die alten Namen werden weiterhin als Alias für die Maschinen unterstützt.

In der folgenden Tabelle sind alle Google Cloud-Maschinentypen aufgeführt, die von SAP für die Produktion von SAP HANA zertifiziert sind.

Die Tabelle enthält keine Maschinentypen, die SAP für SAP Business One auf SAP HANA zertifiziert hat. Die Maschinentypen, die SAP für SAP Business One auf SAP HANA zertifiziert hat, finden Sie unter Zertifizierte SAP-Anwendungen in Google Cloud.

Maschinentypen	vCPUs	Speicher	Betriebssystem	CPU-Plattform	Anwendungstyp	Hinweise
N1-Allzweck-VM-Typen mit großem Arbeitsspeicher
n1-highmem-32	32	208 GB	RHEL, SUSE	Intel Broadwell	OLAP oder OLTP	Blockspeicher: nichtflüchtige Compute Engine-Speicher oder, nur zur vertikalen Skalierung, NetApp CVS-Performance.
n1-highmem-64	64	416 GB	RHEL, SUSE	Intel Broadwell	OLAP oder OLTP	Blockspeicher: nichtflüchtige Compute Engine-Speicher oder, nur zur vertikalen Skalierung, NetApp CVS-Performance.
n1-highmem-96	96	624 GB	RHEL, SUSE	Intel Skylake	OLAP oder OLTP	Blockspeicher: nichtflüchtige Compute Engine-Speicher oder, nur zur vertikalen Skalierung, NetApp CVS-Performance.
N2-VM-Typen für allgemeine Zwecke mit großem Arbeitsspeicher
n2-highmem-32	32	256 GB	RHEL, SUSE	Intel Ice Lake, Intel Cascade Lake	OLAP oder OLTP	Nur vertikale Skalierung. Blockspeicher: nichtflüchtiger Speicher in Compute Engine oder NetApp CVS-Leistung.
n2-highmem-48	48	384 GB	RHEL, SUSE	Intel Ice Lake, Intel Cascade Lake	OLAP oder OLTP	Nur vertikale Skalierung. Blockspeicher: nichtflüchtiger Speicher in Compute Engine oder NetApp CVS-Leistung.
n2-highmem-64	64	512 GB	RHEL, SUSE	Intel Ice Lake, Intel Cascade Lake	OLAP oder OLTP	Nur vertikale Skalierung. Blockspeicher: nichtflüchtiger Speicher in Compute Engine oder NetApp CVS-Leistung.
n2-highmem-80	80	640 GB	RHEL, SUSE	Intel Ice Lake, Intel Cascade Lake	OLAP oder OLTP	Nur vertikale Skalierung. Blockspeicher: nichtflüchtige Compute Engine-Speicher, Hyperdisk Extrem oder NetApp CVS-Leistung.
n2-highmem-96	96	768 GB	RHEL, SUSE	Intel Ice Lake	OLAP oder OLTP	Nur vertikale Skalierung. Blockspeicher: nichtflüchtige Compute Engine-Speicher, Hyperdisk Extrem oder NetApp CVS-Leistung.
n2-highmem-128	128	864 GB	RHEL, SUSE	Intel Ice Lake	OLAP oder OLTP	Nur vertikale Skalierung. Blockspeicher: nichtflüchtige Compute Engine-Speicher, Hyperdisk Extrem oder NetApp CVS-Leistung.
C3-VM-Typen für allgemeine Zwecke
c3-standard-44	44	176 GB	RHEL, SUSE	Intel Sapphire Rapids	OLAP oder OLTP	Nur vertikale Skalierung. Blockspeicher: nichtflüchtige Compute Engine-Speicher, Hyperdisk Balanced oder NetApp CVS-Leistung.
c3-highmem-44	44	352 GB	RHEL, SUSE	Intel Sapphire Rapids	OLAP oder OLTP	Nur vertikale Skalierung. Blockspeicher: nichtflüchtige Compute Engine-Speicher, Hyperdisk Balanced oder NetApp CVS-Leistung.
c3-highmem-88	88	704 GB	RHEL, SUSE	Intel Sapphire Rapids	OLAP oder OLTP	Nur vertikale Skalierung. Blockspeicher: nichtflüchtiger Compute Engine-Speicher, Hyperdisk Extrem, Hyperdisk abgestimmt oder NetApp CVS-Leistung.
c3-highmem-176	176	1.408 GB	RHEL, SUSE	Intel Sapphire Rapids	OLAP oder OLTP	Nur vertikale Skalierung. Blockspeicher: nichtflüchtiger Compute Engine-Speicher, Hyperdisk Extrem, Hyperdisk abgestimmt oder NetApp CVS-Leistung.
C3-Bare-Metal-Maschinentypen für allgemeine Zwecke
c3-highmem-192-metal	192	1.536 GB	RHEL, SUSE	Intel Sapphire Rapids	OLAP oder OLTP	Nur vertikale Skalierung. Blockspeicher: Hyperdisk Extreme, Hyperdisk Balanced.
C4-VM-Typen für allgemeine Zwecke
c4-highmem-32	32	248 GB	RHEL, SUSE	Intel Emerald Rapids	OLAP oder OLTP	Nur vertikale Skalierung. Blockspeicher: Hyperdisk Extrem, Hyperdisk Balanced oder NetApp CVS-Leistung.
c4-highmem-48	48	372 GB	RHEL, SUSE	Intel Emerald Rapids	OLAP oder OLTP	Nur vertikale Skalierung. Blockspeicher: Hyperdisk Extrem, Hyperdisk Balanced oder NetApp CVS-Leistung.
c4-highmem-96	96	744 GB	RHEL, SUSE	Intel Emerald Rapids	OLAP oder OLTP	Nur vertikale Skalierung. Blockspeicher: Hyperdisk Extrem, Hyperdisk Balanced oder NetApp CVS-Leistung.
c4-highmem-192	192	1.488 GB	RHEL, SUSE	Intel Emerald Rapids	OLAP oder OLTP	Nur vertikale Skalierung. Blockspeicher: Hyperdisk Extrem, Hyperdisk Balanced oder NetApp CVS-Leistung.
Speicheroptimierte VM-Typen M1
m1-megamem-96	96	1.433 GB	RHEL, SUSE	Intel Skylake	OLAP oder OLTP	OLAP: Skalieren Sie hoch oder horizontal auf bis zu 16 Knoten. OLTP: Nur vertikale Skalierung. Blockspeicher: nichtflüchtiger Compute Engine-Speicher, Hyperdisk Extrem, Hyperdisk Balanced oder, nur zur vertikalen OLTP-Skalierung, NetApp CVS-Performance.
m1-ultramem-40	40	961 GB	RHEL, SUSE	Intel Broadwell	Nur OLTP	Nur vertikale Skalierung. Blockspeicher: nichtflüchtige Compute Engine-Speicher, Hyperdisk Balanced oder NetApp CVS-Leistung.
m1-ultramem-80	80	1.922 GB	RHEL, SUSE	Intel Broadwell	Nur OLTP	Nur vertikale Skalierung. Blockspeicher: nichtflüchtiger Compute Engine-Speicher, Hyperdisk Extreme, Hyperdisk Balanced oder NetApp CVS-Leistung.
m1-ultramem-160	160	3.844 GB	RHEL, SUSE	Intel Broadwell	OLAP oder OLTP	2 TB OLAP-Arbeitslasten, die für das vertikal und horizontal skalieren auf bis zu 16 Knoten zertifiziert sind. Bis zu 4 TB OLAP-Arbeitslasten, die von der arbeitslastbasierten Größenanpassung unterstützt werden. OLTP-Arbeitslasten, die nur für die vertikale Skalierung zertifiziert sind. Blockspeicher: nichtflüchtiger Compute Engine-Speicher, Hyperdisk Extrem, Hyperdisk Balanced oder, nur zur vertikalen OLTP-Skalierung, NetApp CVS-Performance.
Speicheroptimierte VM-Typen M2
m2-megamem-416	416	5.888 GB	RHEL, SUSE	Intel Cascade Lake	OLAP oder OLTP	OLAP-Arbeitslasten, die für die vertikale und horizontale Skalierung von bis zu 16 Knoten konzipiert sind. OLTP-Arbeitslasten sind für das vertikale Skalieren oder das horizontale Hochskalieren auf bis zu 4 Knoten zertifiziert. Die Zertifizierung für die horizontale OLTP-Skalierung umfasst SAP S/4HANA. Informationen zur horizontalen Skalierung mit S/4 HANA finden Sie im SAP-Hinweis 2408419. Blockspeicher: nichtflüchtige Compute Engine-Speicher, Hyperdisk Extrem, Hyperdisk Balanced oder, nur zur vertikalen Skalierung, NetApp CVS-Leistung.
m2-ultramem-208	208	5.888 GB	RHEL, SUSE	Intel Cascade Lake	Nur OLTP	Nur vertikale Skalierung. Blockspeicher: nichtflüchtiger Compute Engine-Speicher, Hyperdisk Extrem, Hyperdisk abgestimmt oder NetApp CVS-Leistung.
m2-ultramem-416	416	11.776 GB	RHEL, SUSE	Intel Cascade Lake-SP	OLAP oder OLTP	OLAP-Arbeitslasten sind mit arbeitslastbasierter Größenanpassung für vertikale und horizontale Skalierung auf bis zu 16 Knoten zertifiziert. OLTP-Arbeitslasten sind für das vertikale Skalieren oder das horizontale Hochskalieren auf bis zu 4 Knoten zertifiziert. Die Zertifizierung für die horizontale OLTP-Skalierung umfasst SAP S/4HANA. Blockspeicher: nichtflüchtige Compute Engine-Speicher, Hyperdisk Extreme, Hyperdisk Balanced oder, nur zur vertikalen Skalierung, NetApp CVS-Leistung. Informationen zur horizontalen Skalierung mit S/4 HANA finden Sie im SAP-Hinweis 2408419.
m2-hypermem-416	416	8.832 GB	RHEL, SUSE	Intel Cascade Lake	Nur OLTP	OLTP-Arbeitslasten sind für das vertikale Skalieren oder das horizontale Hochskalieren auf bis zu 4 Knoten zertifiziert. Die Zertifizierung für die horizontale OLTP-Skalierung umfasst SAP S/4HANA. Blockspeicher: nichtflüchtige Compute Engine-Speicher, Hyperdisk Extreme, Hyperdisk Balanced oder, nur zur vertikalen Skalierung, NetApp CVS-Leistung. Informationen zur horizontalen Skalierung mit S/4 HANA finden Sie im SAP-Hinweis 2408419.
Speicheroptimierte M3-VM-Typen
m3-ultramem-32	32	976 GB	RHEL, SUSE	Intel Ice Lake	Nur OLTP	Nur vertikale Skalierung. Blockspeicher: nichtflüchtige Compute Engine-Speicher, Hyperdisk Balanced oder NetApp CVS-Leistung.
m3-ultramem-64	64	1.952 GB	RHEL, SUSE	Intel Ice Lake	Nur OLTP	Nur vertikale Skalierung. Blockspeicher: nichtflüchtiger Compute Engine-Speicher, Hyperdisk Extrem, Hyperdisk abgestimmt oder NetApp CVS-Leistung.
m3-ultramem-128	128	3.904 GB	RHEL, SUSE	Intel Ice Lake	OLAP oder OLTP	OLAP-Arbeitslasten sind mit arbeitslastbasierter Größenanpassung für die vertikale Skalierung zertifiziert. OLTP-Arbeitslasten, die für die vertikale Skalierung zertifiziert sind. Blockspeicher: nichtflüchtiger Compute Engine-Speicher, Hyperdisk Extrem, Hyperdisk abgestimmt oder NetApp CVS-Leistung.
m3-megamem-64	64	976 GB	RHEL, SUSE	Intel Ice Lake	OLAP oder OLTP	Nur vertikale Skalierung. Blockspeicher: nichtflüchtiger Compute Engine-Speicher, Hyperdisk Extrem, Hyperdisk abgestimmt oder NetApp CVS-Leistung.
m3-megamem-128	128	1.952 GB	RHEL, SUSE	Intel Ice Lake	OLAP oder OLTP	Vertikale oder horizontale Skalierung für bis zu 16 Knoten. Blockspeicher: nichtflüchtige Compute Engine-Speicher, Hyperdisk Extreme, Hyperdisk abgestimmt oder NetApp CVS-Leistung (nur vertikale Skalierung).
Speicheroptimierte X4-Bare-Metal-Maschinentypen Wichtig: Informationen zum Kauf von Kontingenten für X4-Instanzen oder zu On-Demand-Preisen für das Testen von X4-Instanzen erhalten Sie von Ihrem Google Cloud-Kundenbetreuer.
x4-megamem-960-metal	960	16.384 GB	SUSE	Intel Sapphire Rapids	OLAP oder OLTP	OLAP- und OLTP-Arbeitslasten sind für das horizontale Hochskalieren auf bis zu 4 Knoten und die vertikale Skalierung zertifiziert. Blockspeicher: Hyperdisk Extreme, Hyperdisk Balanced
x4-megamem-1440-metal	1.440	24.576 GB	SUSE	Intel Sapphire Rapids	OLAP oder OLTP	OLTP-Arbeitslasten sind für das horizontale Hochskalieren auf bis zu 4 Knoten zertifiziert. OLAP-Arbeitslasten sind nur für die vertikale Skalierung zertifiziert. Blockspeicher: Hyperdisk Extreme, Hyperdisk Balanced
x4-megamem-1920-metal	1.920	32.768 GB	SUSE	Intel Sapphire Rapids	OLAP oder OLTP	OLTP-Arbeitslasten sind für das horizontale Hochskalieren auf bis zu 4 Knoten zertifiziert. OLAP-Arbeitslasten sind nur für die vertikale Skalierung zertifiziert. Blockspeicher: Hyperdisk Extreme, Hyperdisk Balanced

Zertifizierte Bare Metal Solution-Maschinen für SAP HANA

Die folgende Tabelle zeigt Bare Metal Solution-Maschinen, die von SAP für SAP HANA ausschließlich in einer dreistufigen Architektur zertifiziert sind.

Informationen dazu, in welchen Regionen diese zertifizierten Maschinentypen verfügbar sind, finden Sie unter Regionale Verfügbarkeit von Bare-Metal-Lösung-Maschinen für SAP HANA.

Bare-Metal-Lösung-Maschinentyp	CPU-Kerne	vCPU	Sockets	Speicher	CPU-Plattform	Betriebssystem	Anwendungstyp	Hinweise
Speicheroptimierte Bare Metal Solution-Maschinentypen O2
o2-ultramem-672-metal	336	672	12	18 TB	Intel Cascade Lake	RHEL, SUSE	Nur OLTP	Skalieren Sie nur in einer dreistufigen Architektur vertikal. Standardgröße.
o2-ultramem-896-metal	448	896	16	24 TB	Intel Cascade Lake	RHEL, SUSE	Nur OLTP	Skalieren Sie in einer dreistufigen Architektur vertikal. Standardgröße.

Zertifizierte benutzerdefinierte Maschinentypen für SAP HANA

Die folgende Tabelle zeigt die benutzerdefinierten Maschinentypen von Compute Engine, die von SAP für den Produktionsbetrieb von SAP HANA in Google Cloud zertifiziert sind.

SAP zertifiziert nur einen Teil der benutzerdefinierten Maschinentypen, die in Compute Engine verfügbar sind.

Benutzerdefinierte Maschinentypen unterliegen den von Compute Engine definierten Anpassungsregeln. Die Regeln variieren je nach dem Maschinentyp, den Sie anpassen. Unter Benutzerdefinierte VM-Instanz erstellen sind alle Anpassungsregeln aufgeführt.

Basismaschinentyp	vCPUs	Arbeitsspeicher (GB)	Betriebssystem	CPU-Plattformen
N1-highmem	Eine Anzahl von vCPUs von 32 bis 64, die durch 2 teilbar ist	6,5 GB pro vCPU	RHEL, SUSE	Intel Broadwell
N2-highmem (nur vertikale Skalierung)	Auf Intel Ice Lake, eine Anzahl von vCPUs von 32 bis 80, die durch 4 teilbar ist. Auf Intel Cascade Lake, eine Anzahl von vCPUs von 32 bis 80, die durch 4 teilbar ist.	Bis zu 8 GB pro vCPU	RHEL, SUSE	Intel Ice Lake, Intel Cascade Lake

Regionale Verfügbarkeit von Bare Metal Solution-Maschinen für SAP HANA

Die folgende Tabelle zeigt die aktuellen Google Cloud-Regionen, die SAP HANA auf der Bare-Metal-Lösung unterstützen.

Region	Standort
europe-west3	Frankfurt, Deutschland, Europa
europe-west4	Eemshaven, Niederlande, Europa
us-central1	Council Bluffs, Iowa, USA, Nordamerika
us-east4	Ashburn, Virginia, USA, Nordamerika

Wenn die gewünschte Region in der obigen Tabelle nicht aufgeführt ist, wenden Sie sich an den Google Cloud-Vertrieb.

Arbeitsspeicherkonfiguration

Die verfügbaren Optionen für die Arbeitsspeicherkonfiguration werden durch den ausgewählten VM-Instanztyp von Compute Engine bestimmt. Weitere Informationen finden Sie in der Tabelle Zertifizierte Maschinentypen für SAP HANA.

Netzwerkkonfiguration

Die Netzwerkfunktionen Ihrer Compute Engine-VM werden durch ihre Maschinenfamilie, nicht durch die Netzwerkschnittstelle (NIC) oder IP-Adresse bestimmt.

Abhängig vom Maschinentyp kann Ihre VM-Instanz einen Netzwerkdurchsatz von 2–32 Gbit/s haben. Bestimmte Maschinentypen unterstützen auch Durchsätze von bis zu 100 Gbit/s. Dazu ist die Verwendung des Schnittstellentyps Google Virtual NIC (gVNIC) mit einer Tier_1-Netzwerkkonfiguration erforderlich. Die Möglichkeit, diese Durchsatzraten zu erreichen, hängt weiter von der Trafficrichtung und dem Typ der Ziel-IP-Adresse ab.

Compute Engine-VM-Netzwerkschnittstellen werden von einer redundanten und robusten Netzwerkinfrastruktur mit physischen und softwarebasierten Netzwerkkomponenten unterstützt. Diese Schnittstellen übernehmen Redundanz und Ausfallsicherheit von der zugrunde liegenden Plattform. Mehrere virtuelle NICs können für die Traffictrennung verwendet werden, dies bietet aber keine zusätzlichen Leistungsvorteile.

Eine einzelne NIC bietet die erforderliche Leistung für SAP HANA-Bereitstellungen in Compute Engine. Ihr spezieller Anwendungsfall, die Sicherheitsanforderungen oder -einstellungen erfordern möglicherweise auch zusätzliche Schnittstellen zur Trennung des Traffics, z. B. Internettraffic, interner Traffic der SAP HANA-Systemreplikation oder andere Abläufe, die von bestimmten Netzwerkrichtlinienregeln profitieren könnten. Sie sollten Trafficverschlüsselung der Anwendung verwenden und anhand einer Firewallrichtlinie mit geringsten Berechtigungen den Netzwerkzugriff sichern.

Je nach Ihren Anforderungen können Sie die Sicherheit auf verschiedene Arten verbessern, wie im SAP HANA-Sicherheitsleitfaden für die SAP HANA-Plattform beschrieben. Sie können beispielsweise die Netzwerkisolation implementieren, aber sie bietet eine geringere Sicherheit ohne Verschlüsselung oder port- und IP-spezifische Zulassungslisten.

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 Virtual Private Cloud-Netzwerk anhängen. Ihre Auswahl für die Anzahl der Netzwerkschnittstellen hängt von der erforderlichen Isolationsebene ab, mit bis zu 8 Schnittstellen für VMs mit 8 vCPUs oder mehr.

Sie können beispielsweise ein Virtual Private Cloud-Netzwerk für Ihre SAP HANA SQL-Anwendungsclients (SAP NetWeaver-Anwendungsserver, benutzerdefinierte Anwendungen usw.) und ein separates Netzwerk für Traffic zwischen Servern wie SAP HANA-Systemreplikation definieren. Beachten Sie, dass zu viele Segmente die Verwaltung und Fehlerbehebung von Netzwerkproblemen erschweren. Wenn Sie Ihre Meinung später ändern, können Sie Ihre VM-Instanz mithilfe von Compute Engine-Maschinen-Images neu erstellen und dabei alle zugehörigen Konfigurationen, Metadaten und Daten beibehalten.

Weitere Informationen finden Sie unter Netzwerkübersicht für VMs, Mehrere Netzwerkschnittstellen und Netzwerkbandbreite der VM.

Zertifizierte Betriebssysteme für SAP HANA

In der folgenden Tabelle sind die Betriebssysteme von Red Hat Enterprise Linux (RHEL) und SUSE Linux Enterprise Server (SLES) aufgeführt, die von SAP für die Produktion mit SAP HANA in Google Cloud zertifiziert wurden.

Wenn in der Tabelle nicht anders angegeben, wird jedes Betriebssystem von SAP HANA auf allen zertifizierten Compute Engine-VM-Typen unterstützt.

Informationen zum aktuellen Supportstatus der einzelnen Betriebssysteme und zu den in Google Cloud verfügbaren Betriebssystemen finden Sie unter Betriebssystemunterstützung für SAP HANA in Google Cloud.

Welche Betriebssysteme SAP mit SAP HANA in Google Cloud unterstützt, erfahren Sie unter Verzeichnis zertifizierter und unterstützter SAP HANA-Hardware. Klicken Sie dort auf den erforderlichen Maschinentyp und rufen Sie das Betriebssystem auf.

Folgende Betriebssysteme sind in der Tabelle nicht angegeben:

• Zertifizierte Betriebssystemversionen, die nicht mehr im Mainstream-Support unterstützt werden
• Betriebssystemversionen, die nicht SAP-spezifisch sind

Betriebssystem	Version	Nicht unterstützte Maschinentypen
RHEL für SAP	9.4 ^Hinweis	x4-megamem
	9.2 ^Hinweis	x4-megamem C3-metal
	9.0 ^Hinweis	x4-megamem C3-metal
	8.10	x4-megamem
	8.8	x4-megamem C3-metal
	8.6	x4-megamem C3-metal
	8.4	x4-megamem C3-metal
	8.2	x4-megamem C3-metal
	8.1	x4-megamem C3-metal c3-standard c3-highmem m3-ultramem m3-megamem
	7.9	c4-highmem x4-megamem C3-metal
	7.7	c4-highmem x4-megamem C3-metal c3-standard c3-highmem m3-ultramem m3-megamem
SLES für SAP	15 SP6
	15 SP5
	15 SP4
	15 SP3	x4-megamem C3-metal
	15 SP2	x4-megamem C3-metal
	15 SP1	c4-highmem x4-megamem C3-metal c3-standard c3-highmem m3-ultramem m3-megamem
	12 SP5	x4-megamem C3-metal

Hinweis: Bevor Sie eine SAP-Software unter RHEL für SAP 9.x installieren, müssen Sie zusätzliche Pakete auf Ihren Hostcomputern installieren, insbesondere chkconfig und compat-openssl11. Wenn Sie ein von Compute Engine bereitgestelltes Image verwenden, werden diese Pakete automatisch für Sie installiert. Weitere Informationen von SAP finden Sie im SAP-Hinweis 3108316 – Red Hat Enterprise Linux 9.x: Installation und Konfiguration.

Benutzerdefinierte Betriebssystem-Images

Sie können ein von Google Cloud bereitgestelltes und verwaltetes Linux-Image (öffentliches Image) verwenden oder ein eigenes Linux-Image (benutzerdefiniertes Image) bereitstellen und verwalten.

Verwenden Sie ein benutzerdefiniertes Image, wenn die von Ihnen benötigte Version des von SAP zertifizierten Betriebssystems nicht auf Google Cloud als öffentliches Image verfügbar ist. Die folgenden Schritte, die unter Bootlaufwerks-Images in Compute Engine importieren ausführlich beschrieben sind, fassen das Verfahren zur Verwendung eines benutzerdefinierten Images zusammen:

1. Bereiten Sie das Bootlaufwerk so vor, dass es in der Google Cloud Compute Engine-Umgebung gestartet werden kann und Sie nach dem Starten darauf zugreifen können.
2. Erstellen und komprimieren Sie die Image-Datei des Bootlaufwerks.
3. Laden Sie die Image-Datei in Cloud Storage hoch und importieren Sie das Image als neues benutzerdefiniertes Image in Compute Engine.
4. Erstellen Sie mithilfe des importierten Images eine VM-Instanz und überprüfen Sie, ob sie ordnungsgemäß gestartet werden kann.
5. Optimieren Sie das Image und installieren Sie die Linux-Gastumgebung, damit das importierte Betriebssystem-Image mit dem Metadatenserver kommunizieren und weitere Compute Engine-Features verwenden kann.

Sobald Ihr benutzerdefiniertes Image bereit ist, können Sie es beim Erstellen von VMs für Ihr SAP HANA-System verwenden.

Wenn Sie ein RHEL-Betriebssystem von einer lokalen Installation auf Google Cloud verschieben, müssen Sie Ihrem Red Hat-Abo Red Hat Cloud Access hinzufügen. Weitere Informationen finden Sie unter Red Hat Cloud Access.

Weitere Informationen zu den von Google Cloud bereitgestellten Betriebssystem-Imagesfinden Sie unter Images.

Weitere Informationen zum Importieren eines Betriebssystems in Google Cloud als benutzerdefiniertes Image finden Sie unter Bootlaufwerk-Images in Compute Engine importieren.

Weitere Informationen zu den von SAP HANA unterstützten Betriebssystemen finden Sie in folgenden Artikeln:

• Verzeichnis für zertifizierte und unterstützte SAP HANA-Hardware
• SAP-Hinweis 2235581 – SAP HANA: Unterstützte Betriebssysteme

Betriebssystem-Taktquelle auf Compute Engine-VMs

Die standardmäßige Taktquelle des Betriebssystems ist kvm-clock für SLES und TSC für RHEL-Images.

Das Ändern der Betriebssystem-Taktquelle ist nicht erforderlich, wenn SAP HANA auf einer Compute Engine-VM ausgeführt wird. Es gibt keinen Unterschied in der Leistung bei Verwendung von kvm-clock oder TSC als Taktquelle für Compute Engine VMs mit SAP HANA.

Wenn Sie die Betriebssystem-Taktquelle auf TSC ändern müssen, stellen Sie eine SSH-Verbindung zu Ihrer VM her und führen Sie die folgenden Befehle aus:

echo "tsc" | sudo tee /sys/devices/system/clocksource/*/current_clocksource
sudo cp /etc/default/grub /etc/default/grub.backup
sudo sed -i '/GRUB_CMDLINE_LINUX/ s|"| clocksource=tsc"|2' /etc/default/grub
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Persistenter Festplattenspeicher

Bei nichtflüchtigem Speicher können Sie nichtflüchtige Compute Engine-Speicher oder Hyperdisks hinzufügen, wenn Sie Ihre VMs erstellen oder sie Ihren VMs später hinzufügen.

Unterstützte Laufwerktypen

Compute Engine bietet verschiedene Arten von Persistent Disk und Hyperdisk, die auf der SSD-Technologie (Solid-State Drive) oder der Standard-Festplatten-Technologie (HDD) basieren. Jeder Typ hat unterschiedliche Leistungsmerkmale. Google Cloud verwaltet die zugrunde liegende Hardware der Speicher, um die Datenredundanz zu gewährleisten und die Leistung zu optimieren.

Aus Leistungsgründen benötigen SAP HANA-Volumes vom Typ /hana/data und /hana/log SSD-basierte nichtflüchtige Speichervolumen. SSD-basierte Persistent Disk- und Hyperdisk-Typen, die von SAP für die Verwendung mit SAP HANA zertifiziert sind, umfassen Folgende Elemente:

• SSD-basierte Persistent Disk-Typen: Ausgeglichen (pd-balanced), Leistung oder SSD (pd-ssd) und Extreme (pd-extreme)

  • Diese Laufwerkstypen bieten kostengünstigen und zuverlässigen Blockspeicher.
  • Der auf Leistung ausgelegte Persistent Disk SSD-Speicher (pd-ssd) bietet eine höhere Leistung als abgestimmter nichtflüchtiger Speicher (pd-balanced).
  • Verwenden Sie abgestimmten nichtflüchtigen Speicher als empfohlenes Laufwerk für das Hosting der folgenden Elemente für VM-Instanzen:
    • Das VM-Boot-Volume.
    • Das /usr/sap-Volumen.
    • Das /hana/shared-Volumen, wenn Sie es auf einem eigenen Laufwerk hosten.
    • Das /hanabackup-Volume, wenn Sie Ihre Sicherungen auf einem Laufwerk speichern. Wenn Sie die Sicherungskosten reduzieren möchten, können Sie einen Persistent Disk HDD-Standardspeicher (pd-standard) verwenden. Abgestimmter nichtflüchtiger Speicher bietet schnellere Sicherungen als nichtflüchtiger HDD-Standardspeicher. Prüfen Sie bei der Auswahl des Laufwerks, ob der VM-Typ den Laufwerkstyp unterstützt.
  • Ausgeglichene und leistungsoptimierte nichtflüchtige SSD-Speicher unterstützen die asynchrone Replikation von nichtflüchtigen Speichern. Sie können dieses Feature für die regionenübergreifende Aktiv-Passiv-Notfallwiederherstellung verwenden. Weitere Informationen finden Sie unter Notfallwiederherstellung mit PD Async Replication.
  • Obwohl extrem nichtflüchtiger Speicher (pd-extreme) für die Verwendung mit SAP HANA zertifiziert ist, empfehlen wir stattdessen die Verwendung von Hyperdisk Extrem (hyperdisk-extreme), da es eine höhere Leistung bietet. Wenn Sie Extrem Persistent Disk verwenden möchten, müssen Sie die Laufwerke gemäß den Informationen unter Mindestgrößen für SSD-basierte Persistent Disk- und Hyperdisk-Volumes bereitstellen.

• Hyperdisk-Typen: Hyperdisk Extreme (hyperdisk-extreme) und Hyperdisk abgestimmt (hyperdisk-balanced)

  • Hyperdisk Extreme bietet höhere IOPS- und Durchsatzoptionen als SSD-basierte Persistent Disk-Typen.
  • Eine Liste der Maschinentypen, die Hyperdisk Extrem und Hyperdisk abgestimmt unterstützen, finden Sie unter Unterstützung für Maschinentypen.
  • „Hyperdisk Balanced“ als empfohlenes Laufwerk für das Hosting der folgenden Bare-Metal-Instanzen von Compute Engine wie X4:
    • Das Bootlaufwerk.
    • Das /usr/sap-Volumen.
    • Das /hana/shared-Volumen, wenn Sie es auf einem eigenen Laufwerk hosten.
    • Das /hanabackup-Volume, wenn Sie Ihre Sicherungen auf einem Laufwerk speichern.
  • Für Hyperdisk Extreme wählen Sie durch die Bereitstellung von IOPS die gewünschte Leistung aus, wodurch auch Ihr Durchsatz bestimmt wird. Weitere Informationen finden Sie unter Durchsatz.
  • Für Hyperdisk Balanced wählen Sie die gewünschte Leistung aus, indem Sie IOPS und Durchsatz bereitstellen. Weitere Informationen finden Sie unter Informationen zu IOPS- und Durchsatzbereitstellung für Hyperdisk.
  • Sie können Hyperdisk Extrem für die Volumes /hana/data und /hana/log verwenden, wenn Sie die höchste Leistung benötigen.
  • Um die beste Leistung von Hyperdisk Extrem für SAP HANA zu erzielen, aktualisieren Sie Ihre SAP HANA-Systemattribute, wie unter Leistung von Hyperdisk Extrem empfohlen.

Unterstützte Laufwerkslayouts

Die folgende Abbildung zeigt das Laufwerksspeicherlayout in vorgeschlagenen Architekturen für SAP HANA in Google Cloud.

In der vorherigen Abbildung wird in der Konfiguration auf der linken Seite ein Layout mit geteilten Laufwerken verwendet. Die Volumes /hana/data und /hana/log befinden sich auf separaten Hyperdisks. Das Volume /hana/data kann auf mehreren Laufwerken gehostet werden. Die Volumes /hana/shared und /usr/sap, die keine hohe Leistung erfordern, befinden sich auf einzelnen abgestimmten nichtflüchtigen Speichern, die weniger als ein Hyperdisk Extrem kosten.

Auf der rechten Seite wird ein einheitliches Layout verwendet, bei dem die Volumes /hana/data, /hana/log, /hana/shared und /usr/sap alle auf einem einzigen Hyperdisk Extrem bereitgestellt werden.

Nichtflüchtige Speicher und Hyperdisks sind unabhängig von Ihren VMs, sodass Sie diese Laufwerke zur Aufbewahrung Ihrer Daten trennen oder verschieben können, auch nachdem Sie die VMs gelöscht haben.

In der Google Cloud Console finden Sie die nichtflüchtigen Speicher und Hyperdisks, die Ihren VM-Instanzen zugeordnet sind, unter Zusätzliche Laufwerke auf der Seite VM-Instanzdetails für jede VM-Instanz. Weitere Informationen zu den verschiedenen Arten von Persistent Disk- und Hyperdisk-Volumes von Compute Engine, ihren Leistungsmerkmalen und ihrer Arbeit finden Sie in der folgenden Dokumentation:

• Speicheroptionen
• Informationen zu Hyperdisk
• Blockspeicherleistung
• Andere Faktoren, die sich auf die Leistung auswirken
• Nichtflüchtigen Speicher zu VM hinzufügen
• Laufwerk-Snapshots erstellen und verwalten
• SAP HANA Persistent Disk-Volumes zu Hyperdisk-Volumes migrieren

Mindestgrößen für SSD-basierte Persistent Disk- und Hyperdisk-Volumes

Wenn Sie die Größe bestimmter Compute Engine-SSD-basierter nichtflüchtiger Speicher für SAP HANA festlegen, müssen Sie nicht nur die Speicheranforderungen Ihrer SAP HANA-Instanz, sondern auch die Leistung des nichtflüchtigen Speichers berücksichtigen.

Innerhalb der Limits steigt die Leistung eines SSD- oder abgestimmten nichtflüchtigen Speichers, wenn die Größe des Laufwerks und die Anzahl der vCPUs zunimmt. Wenn ein SSD- oder abgestimmter nichtflüchtiger Speicher zu klein ist, bietet er möglicherweise nicht die von SAP HANA benötigte Leistung.

Die Leistung von Hyperdisk wird von der Laufwerksgröße nicht beeinflusst. Die Leistung wird durch die bereitgestellten IOPS oder den bereitgestellten Durchsatz bestimmt. Informationen zur Leistung von Hyperdisk finden Sie unter Informationen zu Hyperdisks.

Ein SSD-Speicher mit 550 GB oder ein abgestimmter nichtflüchtiger Speicher mit 943 GB bietet einen kontinuierlichen Durchsatz von 400 MB pro Sekunde für Lese- und Schreibvorgänge. Dies ist das Minimum. Allgemeine Informationen zur Leistung nichtflüchtiger Speicher finden Sie unter Blockspeicherleistung.

In der folgenden Tabelle sind die empfohlenen Größen für nichtflüchtige SSD-Speicher (pd-ssd), abgestimmte nichtflüchtige Speicher (pd-balanced) und Hyperdisk Extrem (hyperdisk-extreme) und Hyperdisk Balanced (hyperdisk-balanced) aufgeführt, um die Leistungsanforderungen von SAP HANA in einer Produktionsumgebung für jeden Compute Engine-Maschinentyp zu erfüllen, der für SAP HANA zertifiziert ist. Die Mindestgrößen für Hyperdisk, die ausschließlich auf der Größe des Arbeitsspeichers basieren, sind in der Tabelle als Referenz angegeben.

Informationen zur empfohlenen Speicherkonfiguration für SAP HANA-Systeme, die auf X4-Instanzen ausgeführt werden, finden Sie unter Unterstützter Blockspeicher für X4.

Bei den Größen in der folgenden Tabelle wird davon ausgegangen, dass Sie alle SAP HANA-Volumes auf einzelnen Laufwerken bereitstellen.

Abgestimmter nichtflüchtiger Speicher

Wenn Sie mehr als ein Volume mit abgestimmtem nichtflüchtigem Speicher zum Hosten Ihres /hana/data-Volumes verwenden möchten, müssen Sie den in der Spalte „/hana/data-Größe (GB)“ angegebenen Größerwert gleichmäßig auf die von Ihnen bereitgestellten Laufwerkvolumes verteilen.

Compute Engine-VM-Typ	/hana/data-Größe (GB)	/hana/log-Größe (GB)	/hana/shared Größe (GB)	/usr/sap Größe (GB)	Gesamtgröße (GB)
n1-highmem-32	599	104	208	32	943
n1-highmem-64	499	208	416	32	1.155
n1-highmem-96	748	312	624	32	1.716
n2-highmem-32	527	128	256	32	943
n2-highmem-48	460	192	384	32	1.068
n2-highmem-64	614	256	512	32	1.414
n2-highmem-80	768	320	640	32	1.760
n2-highmem-96	921	384	768	32	2.105
n2-highmem-128	1.036	432	864	32	2.364
c3-standard-44	647	88	176	32	943
c3-highmem-44	422	176	352	32	982
c3-highmem-88	844	352	704	32	1.932
c3-highmem-176	1.689	512	1.024	32	3.257
m1-megamem-96	1.719	512	1.024	32	3.287
m1-ultramem-40	1.153	480	961	32	2.626
m1-ultramem-80	2.306	512	1.024	32	3.874
m1-ultramem-160	4.612	512	1.024	32	6.180
m2-megamem-416	7.065	512	1.024	32	8.633
m2-ultramem-208	7.065	512	1.024	32	8.633
m2-ultramem-416	14.092	512	1.024	32	15.660
m2-hypermem-416	10.598	512	1.024	32	12.166
m3-ultramem-32	1.171	488	976	32	2.667
m3-ultramem-64	2.342	512	1.024	32	3.910
m3-ultramem-128	4.684	512	1.024	32	6.252
m3-megamem-64	1.171	488	976	32	2.667
m3-megamem-128	2.342	512	1.024	32	3.910

Nichtflüchtiger SSD-Speicher

Wenn Sie mehr als ein SSD-Volume für nichtflüchtigen Speicher zum Hosten Ihres /hana/data-Volumes verwenden möchten, müssen Sie den in der Spalte „/hana/data-Größe (GB)“ angegebenen Größerwert gleichmäßig auf die von Ihnen bereitgestellten Laufwerkvolumes verteilen.

Compute Engine-VM-Typ	/hana/data-Größe (GB)	/hana/log-Größe (GB)	/hana/shared Größe (GB)	/usr/sap Größe (GB)	Gesamtgröße (GB)
n1-highmem-32	249	104	208	32	593
n1-highmem-64	499	208	416	32	1.155
n1-highmem-96	748	312	624	32	1.716
n2-highmem-32	307	128	256	32	723
n2-highmem-48	460	192	384	32	1.068
n2-highmem-64	614	256	512	32	1.414
n2-highmem-80	768	320	640	32	1.760
n2-highmem-96	921	384	768	32	2.105
n2-highmem-128	1.036	432	864	32	2.364
c3-standard-44	254	88	176	32	550
c3-highmem-44	422	176	352	32	982
c3-highmem-88	844	352	704	32	1.932
c3-highmem-176	1.689	512	1.024	32	3.257
m1-megamem-96	1.719	512	1.024	32	3.287
m1-ultramem-40	1.153	480	961	32	2.626
m1-ultramem-80	2.306	512	1.024	32	3.874
m1-ultramem-160	4.612	512	1.024	32	6.180
m2-megamem-416	7.065	512	1.024	32	8.633
m2-ultramem-208	7.065	512	1.024	32	8.633
m2-ultramem-416	14.092	512	1.024	32	15.660
m2-hypermem-416	10.598	512	1.024	32	12.166
m3-ultramem-32	1.171	488	976	32	2.667
m3-ultramem-64	2.342	512	1.024	32	3.910
m3-ultramem-128	4.684	512	1.024	32	6.252
m3-megamem-64	1.171	488	976	32	2.667
m3-megamem-128	2.342	512	1.024	32	3.910

Hyperdisk Extrem

Wenn Sie die Volumes /hana/data und /hana/log mit Hyperdisk Extrem hosten, müssen Sie die Volumes /hana/shared und /usr/sap auf separaten abgestimmten nichtflüchtigen Speichern hosten. Das liegt daran, dass die Volumes /hana/shared und /usr/sap nicht so hoch wie die Daten- und Logvolumen sind.

Wenn Sie mehrere Hyperdisk Extreme-Volumes zum Hosten Ihres /hana/data-Volumes verwenden möchten, müssen Sie die in der Spalte „/hana/data (GB) – Größe und IOPS“ angegebenen Werte für Größe und IOPS gleichmäßig auf die von Ihnen bereitgestellten Laufwerkvolumes verteilen.

Compute Engine-VM-Typ	/hana/data-Größe (GB) und IOPS	/hana/log-Größe (GB) und IOPS	/hana/shared Größe (GB)	/usr/sap Größe (GB)	Gesamtgröße (GB)
n2-highmem-80	768 GB mit 10.000 IOPS	320 GB mit 10.000 IOPS	640	32	1.760
n2-highmem-96	921 GB mit 10.000 IOPS	384 GB mit 10.000 IOPS	768	32	2.105
n2-highmem-128	1.036 GB mit 10.000 IOPS	432 GB mit 10.000 IOPS	864	32	2.364
c3-highmem-88	844 GB mit 10.000 IOPS	352 GB mit 10.000 IOPS	704	32	1.932
c3-highmem-176	1.689 GB mit 10.000 IOPS	512 GB mit 10.000 IOPS	1.024	32	3.257
c3-highmem-192-metal	1.843 GB mit 10.000 IOPS	512 GB mit 10.000 IOPS	1.024	32	3.411
c4-highmem-32	297 GB mit 10.000 IOPS	124 GB mit 10.000 IOPS	248	32	701
c4-highmem-48	446 GB mit 10.000 IOPS	186 GB mit 10.000 IOPS	372	32	1.036
c4-highmem-96	892 GB mit 10.000 IOPS	372 GB mit 10.000 IOPS	744	32	2.040
c4-highmem-192	1.785 GB mit 10.000 IOPS	512 GB mit 10.000 IOPS	1.024	32	3.353
m1-megamem-96	1.719 GB mit 10.000 IOPS	512 GB mit 10.000 IOPS	1.024	32	3.287
m1-ultramem-80	2.306 GB mit 10000 IOPS	512 GB mit 10.000 IOPS	1.024	32	3.874
m1-ultramem-160	4.612 GB mit 10.000 IOPS	512 GB mit 10.000 IOPS	1.024	32	6.180
m2-megamem-416	7.065 GB mit 14.130 IOPS	512 GB mit 31.196 IOPS	1.024	32	8.633
m2-ultramem-208	7.065 GB mit 14.130 IOPS	512 GB mit 10.000 IOPS	1.024	32	8.633
m2-ultramem-416	14.092 GB mit 28.184 IOPS	512 GB mit 10.000 IOPS	1.024	32	15.660
m2-hypermem-416	10.598 GB mit 21.196 IOPS	512 GB mit 10.000 IOPS	1.024	32	12.166
m3-ultramem-64	2.342 GB mit 10.000 IOPS	512 GB mit 10.000 IOPS	1.024	32	3.910
m3-ultramem-128	4.684 GB mit 10.000 IOPS	512 GB mit 10.000 IOPS	1.024	32	6.252
m3-megamem-64	1.171 GB mit 10.000 IOPS	488 GB mit 10.000 IOPS	976	32	2.667
m3-megamem-128	2.342 GB mit 10.000 IOPS	512 GB mit 10.000 IOPS	1.024	32	3.910

Hyperdisk Balanced

Für SAP HANA beträgt die mindestens unterstützte bereitgestellte IOPS 3.000 und der Durchsatz 400 MB/s. Sie können diese Werte jedoch an Ihre spezifischen Leistungsanforderungen anpassen. Wir empfehlen einen Startwert von 3.000 IOPS und 750 Mbit/s Durchsatz, da dies die Standardwerte sind, die in den Terraform-Konfigurationsdateien verwendet werden, die Google Cloud für die automatisierte Bereitstellung von SAP HANA bereitstellt.

Wenn Sie mehrere Hyperdisk Balanced-Volumes zum Hosten Ihres /hana/data-Volumes verwenden möchten, müssen Sie die in der Spalte „/hana/data-Größe (GB), IOPS und Durchsatz“ angegebenen Werte für Größe, IOPS und Durchsatz gleichmäßig auf die von Ihnen bereitgestellten Laufwerkvolumes verteilen.

Compute Engine-VM-Typ	/hana/data-Größe (GB), IOPS und Durchsatz	/hana/log-Größe (GB), IOPS und Durchsatz	/hana/shared Größe (GB)	/usr/sap Größe (GB)	Gesamtgröße (GB)
c3-standard-44	211 GB mit 10.000 IOPS und 400 Mbit/s Durchsatz	88 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	176	32	507
c3-highmem-44	422 GB mit 10.000 IOPS und 400 Mbit/s Durchsatz	176 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	352	32	982
c3-highmem-88	844 GB mit 10.000 IOPS und 1.200 Mbit/s Durchsatz	352 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	704	32	1.932
c3-highmem-176	1.689 GB mit 10.000 IOPS und 1.200 Mbit/s Durchsatz	512 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	1.024	32	3.257
c3-highmem-192-metal	1.843 GB mit 10.000 IOPS und 1.200 Mbit/s Durchsatz	512 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	1.024	32	3.411
c4-highmem-32	297 GB mit 10.000 IOPS und 400 Mbit/s Durchsatz	124 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	248	32	701
c4-highmem-48	446 GB mit 10.000 IOPS und 400 Mbit/s Durchsatz	186 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	372	32	1.036
c4-highmem-96	892 GB mit 10.000 IOPS und 800 Mbit/s Durchsatz	372 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	744	32	2.040
c4-highmem-192	1.785 GB mit 10.000 IOPS und 800 Mbit/s Durchsatz	512 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	1.024	32	3.353
m1-megamem-96	1.719 GB mit 8.000 IOPS und 1.000 Mbit/s Durchsatz	512 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	1.024	32	3.287
m1-ultramem-40	1.153 GB mit 8.000 IOPS und 900 Mbit/s Durchsatz	480 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	961	32	2.626
m1-ultramem-80	2.306 GB mit 10.000 IOPS und 1.200 Mbit/s Durchsatz	512 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	1.024	32	3.874
m1-ultramem-160	4.612 GB mit 15.000 IOPS und 1.200 Mbit/s Durchsatz	512 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	1.024	32	6.180
m2-megamem-416	7.065 GB mit 20.000 IOPS und 1.200 Mbit/s Durchsatz	512 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	1.024	32	8.633
m2-ultramem-208	7.065 GB mit 20.000 IOPS und 1.200 Mbit/s Durchsatz	512 GB mit 3000 IOPS und 400 Mbit/s Durchsatz	1.024	32	8.633
m2-ultramem-416	14.092 GB mit 20.000 IOPS und 1.200 Mbit/s Durchsatz	512 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	1.024	32	15.660
m2-hypermem-416	10.598 GB mit 20.000 IOPS und 1.200 Mbit/s Durchsatz	512 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	1.024	32	12.166
m3-ultramem-32	1.171 GB mit 10.000 IOPS und 900 Mbit/s Durchsatz	488 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	976	32	2.667
m3-ultramem-64	2.342 GB mit 10.000 IOPS und 1.200 Mbit/s Durchsatz	512 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	1.024	32	3.910
m3-ultramem-128	4.684 GB mit 10.000 IOPS und 1.200 Mbit/s Durchsatz	512 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	1.024	32	6.252
m3-megamem-64	1.171 GB mit 10.000 IOPS und 900 Mbit/s Durchsatz	488 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	976	32	2.667
m3-megamem-128	2.342 GB mit 10.000 IOPS und 1.200 Mbit/s Durchsatz	512 GB mit 3.000 IOPS und 400 Mbit/s Durchsatz	1.024	32	3.910

Laufwerksgrößen zum Bereitstellen aller SAP HANA-Volumes auf einem einzelnen Laufwerk

Bei den Größen in der folgenden Tabelle wird davon ausgegangen, dass Sie ein einzelnes Laufwerk zum Hosten aller folgenden Volumes verwenden: /hana/data-,/hana/log-,/hana/shared- und /usr/sap-Volumes.

Abgestimmter nichtflüchtiger Speicher

Compute Engine-VM-Typ	Größe (GB)
n1-highmem-32	943
n1-highmem-64	1.155
n1-highmem-96	1.716
n2-highmem-32	943
n2-highmem-48	1.068
n2-highmem-64	1.414
n2-highmem-80	1.760
n2-highmem-96	2.105
n2-highmem-128	2.364
c3-standard-44	943
c3-highmem-44	982
c3-highmem-88	1.932
c3-highmem-176	3.257
m1-megamem-96	3.287
m1-ultramem-40	2.626
m1-ultramem-80	3.874
m1-ultramem-160	6.180
m2-megamem-416	8.633
m2-ultramem-208	8.633
m2-ultramem-416	15.660
m2-hypermem-416	12.166
m3-ultramem-32	2.667
m3-ultramem-64	3.910
m3-ultramem-128	6.252
m3-megamem-64	2.667
m3-megamem-128	3.910

Nichtflüchtiger SSD-Speicher

Compute Engine-VM-Typ	Größe (GB)
n1-highmem-32	593
n1-highmem-64	1.155
n1-highmem-96	1.716
n2-highmem-32	723
n2-highmem-48	1.068
n2-highmem-64	1.414
n2-highmem-80	1.760
n2-highmem-96	2.105
n2-highmem-128	2.364
c3-standard-44	550
c3-highmem-44	982
c3-highmem-88	1.932
c3-highmem-176	3.257
m1-megamem-96	3.287
m1-ultramem-40	2.626
m1-ultramem-80	3.874
m1-ultramem-160	6.180
m2-megamem-416	8.633
m2-ultramem-208	8.633
m2-ultramem-416	15.660
m2-hypermem-416	12.166
m3-ultramem-32	2.667
m3-ultramem-64	3.910
m3-ultramem-128	6.252
m3-megamem-64	2.667
m3-megamem-128	3.910

Hyperdisk Extrem

Compute Engine-VM-Typ	Größe (GB) und IOPS
n2-highmem-80	1.760 GB mit 20.000 IOPS
n2-highmem-96	2.105 GB mit 20.000 IOPS
n2-highmem-128	2.364 GB mit 20.000 IOPS
c3-highmem-88	1.932 GB mit 20.000 IOPS
c3-highmem-176	3.257 GB mit 20.000 IOPS
c3-highmem-192-metal	3.411 GB mit 20.000 IOPS
c4-highmem-32	701 GB mit 20.000 IOPS
c4-highmem-48	1.036 GB mit 20.000 IOPS
c4-highmem-96	2.040 GB mit 20.000 IOPS
c4-highmem-192	3.353 GB mit 20.000 IOPS
m1-megamem-96	3.287 GB mit 20.000 IOPS
m1-ultramem-80	3.874 GB mit 20.000 IOPS
m1-ultramem-160	6.180 GB mit 20.000 IOPS
m2-megamem-416	8.633 GB mit 24.130 IOPS
m2-ultramem-208	8.633 GB mit 24.130 IOPS
m2-ultramem-416	15.660 GB mit 38.184 IOPS
m2-hypermem-416	12.166 GB mit 31.196 IOPS
m3-ultramem-64	3.910 GB mit 20.000 IOPS
m3-ultramem-128	6.252 GB mit 20.000 IOPS
m3-megamem-64	2.667 GB mit 20.000 IOPS
m3-megamem-128	3.910 GB mit 20.000 IOPS

Hyperdisk Balanced

Compute Engine-VM-Typ	Größe (GB), IOPS und Durchsatz
c3-standard-44	507 GB mit 13.000 IOPS und 800 Mbit/s Durchsatz
c3-highmem-44	982 GB mit 13.000 IOPS und 800 Mbit/s Durchsatz
c3-highmem-88	1.932 GB mit 13.000 IOPS und 1.600 Mbit/s Durchsatz
c3-highmem-176	3.257 GB mit 13.000 IOPS und 1.600 MB/s Durchsatz
c3-highmem-192-metal	3.411 GB mit 13.000 IOPS und 1.600 Mbit/s Durchsatz
c4-highmem-32	701 GB mit 13.000 IOPS und 800 Mbit/s Durchsatz
c4-highmem-48	1.036 GB mit 13.000 IOPS und 800 Mbit/s Durchsatz
c4-highmem-96	2.040 GB mit 13.000 IOPS und 1.200 Mbit/s Durchsatz
c4-highmem-192	3.353 GB mit 13.000 IOPS und 1.200 MB/s Durchsatz
m1-megamem-96	3.287 GB mit 11.000 IOPS und 1.400 Mbit/s Durchsatz
m1-ultramem-40	2.626 GB mit 11.000 IOPS und 1.300 Mbit/s Durchsatz
m1-ultramem-80	3.874 GB mit 13.000 IOPS und 1.600 Mbit/s Durchsatz
m1-ultramem-160	6.180 GB mit 18.000 IOPS und 1.600 Mbit/s Durchsatz
m2-megamem-416	8.633 GB mit 23.000 IOPS und 1.600 Mbit/s Durchsatz
m2-ultramem-208	8.633 GB mit 23.000 IOPS und 1.600 Mbit/s Durchsatz
m2-ultramem-416	15.660 GB mit 23.000 IOPS und 1.600 Mbit/s Durchsatz
m2-hypermem-416	12.166 GB mit 23.000 IOPS und 1.600 Mbit/s Durchsatz
m3-ultramem-32	2.667 GB mit 13.000 IOPS und 1.300 Mbit/s Durchsatz
m3-ultramem-64	3.910 GB mit 13.000 IOPS und 1.600 Mbit/s Durchsatz
m3-ultramem-128	6.252 GB mit 13.000 IOPS und 1.600 MB/s Durchsatz
m3-megamem-64	2.667 GB mit 13.000 IOPS und 1.300 Mbit/s Durchsatz
m3-megamem-128	3.910 GB mit 13.000 IOPS und 1.600 Mbit/s Durchsatz

Größe des nichtflüchtigen Speichers oder Hyperdisk ermitteln

Berechnen Sie die Größe des nichtflüchtigen Speichers, den Sie für die SAP HANA-Volumes benötigen, auf der Grundlage des Arbeitsspeichers, den der ausgewählte Compute Engine-Maschinentyp enthält.

Die folgende Anleitung zu Laufwerksgrößen bezieht sich auf die Mindestgrößen, die Google Cloud für Ihre Bereitstellungen empfiehlt. Diese Empfehlungen überschreiten zwar die Mindestanforderungen von SAP, sind aber so konzipiert, dass die Speicheranforderungen Ihres SAP HANA-Systems, die Leistungsanforderungen der Laufwerke und die Gesamtbetriebskosten ausgeglichen werden. Sie können die Laufwerksgrößen bis zum Limit erhöhen, das von den zugrunde liegenden Laufwerkstypen unterstützt wird. Informationen zu den erforderlichen Mindestlaufwerksgrößen finden Sie unter Mindestgrößen für SSD-basierte nichtflüchtige Speicher.

Anforderungen an die Größe des nichtflüchtigen Speichers für Systeme mit vertikaler Skalierung

Verwenden Sie bei SAP HANA-Systemen mit vertikaler Skalierung die folgenden Formeln für jedes Volume:

• /hana/data: 1.2 x Speicher
• /hana/log: entweder 0,5 x Arbeitsspeicher oder 512 GB, je nachdem, welcher Wert kleiner ist
• /hana/shared: entweder 1 x Arbeitsspeicher oder 1.024 GB, je nachdem, welcher Wert kleiner ist
• /usr/sap: 32 GB
• /hanabackup: 2 x Speicher, optionale Zuordnung

Anforderungen an die Größe des nichtflüchtigen Speichers für Systeme mit horizontaler Skalierung

Verwenden Sie für SAP HANA-Systeme mit horizontaler Skalierung die gleiche Formel wie für SAP HANA-Systeme mit vertikaler Skalierung für die Volumes /hana/data, /hana/log und /usr/sap. Berechnen Sie für das Volume /hana/shared die Größe des nichtflüchtigen Speichers oder der Hyperdisks anhand der Anzahl der Worker-Hosts in Ihrer Bereitstellung. Erhöhen Sie für jeweils vier Worker-Hosts die Laufwerksgröße um das 1-Fache des Arbeitsspeichers oder um 1 TB, je nachdem, welcher Wert kleiner ist. Beispiel:

• Von 1 bis 4 Worker-Hosts: 1 x Arbeitsspeicher oder 1 TB, je nachdem, welcher Wert kleiner ist
• Von 5 bis 8 Worker-Hosts: 2 x Arbeitsspeicher oder 2 TB, je nachdem, welcher Wert kleiner ist
• Von 9 bis 12 Worker-Hosts: 3 x Arbeitsspeicher oder 3 TB, je nachdem, welcher Wert kleiner ist
• Von 13 bis 16 Worker-Hosts: 4 x Arbeitsspeicher oder 4 TB, je nachdem, welcher Wert kleiner ist

Um die Gesamtanforderungen für das Speicherkontingent für SAP HANA-Systeme mit horizontaler Skalierung zu ermitteln, müssen Sie die Laufwerksgrößen für jeden Laufwerkstyp addieren, der auf allen Hosts im System mit horizontaler Skalierung verwendet wird. Wenn Sie beispielsweise /hana/data und /hana/log auf nichtflüchtige pd-ssd-Speicher speichern, aber /hana/shared und /usr/sap auf nichtflüchtige pd-balanced-Speicher, benötigen Sie separate Summen für pd-ssd und pd-balanced, um separate Kontingente anzufordern.

Bei einem SAP HANA-System mit horizontaler Skalierung und automatischem Host-Failover müssen Sie die Größe des nichtflüchtigen Speichers nur für Master- und Worker-Hosts berechnen. Die Standby-Hosts haben keine eigenen Volumes vom Typ /hana/data, /hana/log und /usr/sap. Wenn ein Fehler auftritt, trennt das automatische Failover von SAP HANA die Volumes /hana/data, /hana/log und /usr/sap vom fehlerhaften Host und stellt sie auf dem Standby-Host bereit. Die Volumes /hana/shared und /hanabackup für einen Standbyhost werden auf einer separat bereitgestellten NFS-Lösung bereitgestellt.

Zusätzlichen nichtflüchtigen Speicher zuweisen

Wählen Sie eine Persistent Disk- oder Hyperdisk-Größe aus, die über der Mindestgröße liegt, die für Ihren Persistent Disk- oder Hyperdisk-Typ in Mindestgrößen für SSD-basierte Persistent Disk- und Hyperdisk-Volumes aufgeführt ist.

Wenn Sie SSD- oder abgestimmte nichtflüchtige Speicher verwenden, wird die Mindestgröße möglicherweise von den Leistungsanforderungen von SAP HANA und nicht von den Anforderungen des SAP HANA-Speichers bestimmt.

Beispiel: Wenn Sie SAP HANA auf einer n2-highmem-32-VM-Instanz mit 256 GB Arbeitsspeicher ausführen, beträgt die Gesamtspeicheranforderung für die SAP HANA-Volumes 723 GB: 307 GB für das Daten-Volume , 128 GB für das Logvolume, 256 GB für das freigegebene Volume und 32 GB für das Volume /usr/sap. Wenn Sie jedoch einen abgestimmten nichtflüchtigen Speicher verwenden, beträgt die erforderliche Mindestgröße 943 GB. Dabei werden dem Datenvolumen weitere 220 GB zugewiesen, um die erforderliche Leistung zu erzielen. Wenn Sie eine n2-highmem-32-VM-Instanz mit abgestimmten nichtflüchtigen Speichern verwenden, um SAP HANA auszuführen, müssen Sie einen nichtflüchtigen Speicher mit mindestens 943 GB bereitstellen.

Sie müssen also die Größe Ihres nichtflüchtigen Speichers auf mindestens 943 GB festlegen. Die zusätzliche Bereitstellung von 220 GB wird auf das Datenvolumen angewendet, um die erforderliche Leistung zu erzielen.

Wenden Sie den zusätzlichen nichtflüchtigen Speicher auf das Volume /hana/data an.

Informationen von SAP zur Größenanpassung für SAP HANA finden Sie unter Größe von SAP HANA anpassen.

Hyperdisk-Leistung

Hyperdisk bietet höhere IOPS- und Durchsatzoptionen für die Volumes /hana/log und /hana/data als die anderen SSD-basierten nichtflüchtigen Speicher. Weitere Informationen zur Bereitstellung von IOPS- und Durchsatzoptionen für Hyperdisk finden Sie unter Informationen zu IOPS- und Durchsatzbereitstellung für Hyperdisk.

Im Gegensatz zu SSD-basierten nichtflüchtigen Speichern müssen Sie sich bei der Verwendung von Hyperdisk mit SAP HANA nicht um die Leistung kümmern, wenn Sie die Größe des Hyperlaufwerks festlegen. Die Größe für Hyperdisk basiert ausschließlich auf den Speicheranforderungen von SAP HANA. Weitere Informationen zur Größenanpassung von nichtflüchtigen Speichern oder Hyperdisk finden Sie unter Größe nichtflüchtiger Speicher ermitteln.

Wenn Sie Hyperdisk mit SAP HANA verwenden, empfehlen wir Ihnen, Ihre SAP HANA-Systemattribute so zu aktualisieren, um die beste Leistung zu erzielen:

• Aktualisieren Sie Ihre global.ini-Datei:
  • Legen Sie im Abschnitt fileio den Wert num_completion_queues = 12 fest.
  • Legen Sie im Abschnitt fileio den Wert num_submit_queues = 12 fest.
• Aktualisieren Sie Ihre indexserver.ini-Datei:
  • Legen Sie im Abschnitt parallel den Wert tables_preloaded_in_parallel = 32 fest.
  • Legen Sie im Abschnitt global den Wert load_table_numa_aware = true fest.

Wenn Sie ein Hyperdisk Extrem-Volume erstellen, bestimmt die Anzahl der bereitgestellten IOPS den maximalen Durchsatz. Die folgende Formel kann als Ausgangspunkt verwendet werden. Er bietet einen Durchsatz von mindestens 2.500 MB/s (256 KB pro IOPS * 10.000 IOPS) und mehr für größere Maschinentypen mit größeren Laufwerken.

• Bei Verwendung der Standardbereitstellung mit separaten Laufwerken für /hana/log und /hana/data:
  • IOPS für das Datenlaufwerk: maximum(10,000, size of data disk in GB * 2)
  • IOPS für das Protokolllaufwerk: maximum(10,000, size of log disk in GB * 2)
• Wenn ein einzelnes Laufwerk für /hana/data, /hana/log, /hana/shared und /usr/sap verwendet wird:
  • IOPS für Laufwerk: maximum(10,000, size of data disk GB * 2) + maximum(10,000, size of log disk in GB * 2)

Die maximale Anzahl von IOPS, die Sie bereitstellen können, kann je nach verwendetem Maschinentyp variieren. Eine Liste der Maschinentypen, die Hyperdisk Extrem unterstützen, sowie den maximalen IOPS- und Durchsatz, der von Hyperdisk Extrem für jeden Maschinentyp bereitgestellt werden kann, finden Sie unter Unterstützung von Maschinentypen.

Wenn Sie ein Hyperdisk Balanced-Volume erstellen, können Sie die IOPS und den Durchsatz bereitstellen, um die Leistungsanforderungen Ihrer Arbeitslast zu erfüllen. Berücksichtigen Sie dabei die Regeln fürIOPS-Bereitstellung und Durchsatzbereitstellung “ Für SAP HANA beträgt die mindestens unterstützte bereitgestellte IOPS 3.000 und der Durchsatz 400 MB/s.

Nichtflüchtige Speicher und Hyperdisk Extrem, die von Skripts zur Bereitstellungsautomatisierung bereitgestellt werden

Wenn Sie ein SAP HANA-System mit den von Google Cloud bereitgestellten Terraform-Konfigurationen bereitstellen, weist das Bereitstellungsskript den SAP-Volumes nichtflüchtige Speicher oder Hyperdisks so zu:

• Standardmäßig werden für jedes der folgenden Verzeichnisse separate Laufwerke bereitgestellt: /hana/data, /hana/log, /hana/shared und /usr/sap.

  Optional können Sie ein Layout mit einem einzelnen Laufwerk bereitstellen, in dem ein einzelner nichtflüchtiger Speicher oder ein Hyperdisk diese SAP-Verzeichnisse hostet. Bei SAP HANA-Bereitstellungen mit horizontaler Skalierung wird das Verzeichnis /hana/shared auch von einer NFS-Lösung gehostet.

• Optional: ein Laufwerk für das Verzeichnis /hanabackup

Folgendes Beispiel zeigt, wie Terraform die Volumes für SAP HANA auf einer Compute Engine-n2-highmem-32-VM mit 256 GB Speicher zuordnet.

hana-ssd-example:~ # lvs
  LV     VG             Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data   vg_hana_data   -wi-ao---- 308.00g
  log    vg_hana_log    -wi-ao---- 128.00g
  shared vg_hana_shared -wi-ao---- 256.00g
  usrsap vg_hana_usrsap -wi-ao----  32.00g
  backup vg_hanabackup  -wi-ao---- 512.00g

Die Größe Ihrer Volumes für denselben Maschinentyp kann geringfügig von der Angabe in diesem Beispiel abweichen.

Wenn Sie die von Google Cloud für SAP HANA bereitgestellten Deployment Manager-Vorlagen verwenden oder ein Layout mit einem einzelnen Laufwerk mit den Terraform-Konfigurationen bereitstellen, ordnet das Bereitstellungsskript die SAP HANA-Verzeichnisse /hana/data, /hana/log, /usr/sap und /hana/shared jeweils einem eigenen logischen Volume zu, um die Größenänderung zu erleichtern, und ordnet sie dem SSD-basierten nichtflüchtigen Speicher oder Hyperdisk in einer einzigen Volume-Gruppe zu. Terraform oder Deployment Manager ordnet das Verzeichnis /hanabackup einem logischen Volume in einer separaten Volume-Gruppe zu, die es dann einem abgestimmten nichtflüchtigen Speicher zuordnet (pd-balanced).

Optionaler nichtflüchtiger Speicher für Sicherungen

Beim Speichern von SAP HANA-Sicherungen auf einem Laufwerk empfehlen wir die Verwendung einer Balanced Persistent Disk (pd-balanced).

Wenn Sie die Kosten senken möchten, können Sie einen nichtflüchtigen HDD-Standardspeicher (pd-standard) verwenden. Verwenden Sie jedoch eine Balanced Persistent Disk, wenn ein höherer Durchsatz oder eine höhere Gleichzeitigkeit erforderlich ist.

Die Volume-Größe für SAP HANA-Sicherungen bietet einen optimalen Basis- und Burst-Durchsatz sowie die Möglichkeit, mehrere Sicherungssätze zu speichern. Wenn mehrere Sicherungssätze auf dem Sicherungs-Volume gespeichert sind, können Sie Ihre Datenbank bei Bedarf einfacher wiederherstellen.

Wenn Sie die SAP HANA-Sicherungen als regionale Ressource für die Notfallwiederherstellung verfügbar machen möchten, können Sie die Compute Engine-Snapshots des nichtflüchtigen Speichers verwenden. Sie können Snapshots planen, um Ihren nichtflüchtigen Speicher regelmäßig und automatisch zu sichern. Weitere Informationen finden Sie unter Snapshots von nichtflüchtigem Speicher.

Wenn Sie SAP HANA Dynamic Tiering verwenden, muss der Sicherungsspeicher groß genug sein, um sowohl die In-Memory-Daten als auch die Daten zu speichern, die vom Dynamic Tiering-Server auf dem Laufwerk verwaltet werden.

Sie können auch andere Mechanismen zum Speichern von SAP HANA-Sicherungen nutzen. Wenn Sie das Backint-Feature des Google Cloud-Agents für SAP verwenden, können Sie SAP HANA direkt in einem Cloud Storage-Bucket sichern. Dadurch ist die Verwendung eines nichtflüchtigen Speichers zum Speichern von Sicherungen optional.

SAP HANA Dynamic Tiering

SAP HANA Dynamic Tiering ist von SAP für den Einsatz in Produktionsumgebungen auf Google Cloud zertifiziert. SAP HANA Dynamic Tiering erweitert den SAP HANA-Datenspeicher durch das Speichern von Daten, auf die selten zugegriffen wird, auf der Festplatte statt im Arbeitsspeicher.

Weitere Informationen finden Sie unter SAP HANA Dynamic Tiering in Google Cloud.

Option Fast Restart für SAP HANA

Für SAP HANA 2.0 SP04 und höher wird von Google Cloud dringend die Option Fast Restart SAP HANA empfohlen.

Diese Option wird automatisch aktiviert, wenn Sie SAP HANA mit dem Terraform-Modul sap_hana oder sap_hana_ha von Google Cloud, Version 202309280828 oder höher, bereitstellen. Informationen zum manuellen Aktivieren von SAP HANA Fast Restart finden Sie unter SAP HANA Fast Restart aktivieren.

SAP HANA Fast Restart verkürzt die Neustartzeit, wenn SAP HANA beendet wird, das Betriebssystem jedoch weiter ausgeführt wird. Um die Neustartzeit zu verkürzen, nutzt SAP HANA die nichtflüchtige Speicherfunktion von SAP HANA, um Hauptdatenfragmente von Spaltenspeichertabellen in DRAM beizubehalten, die dem tmpfs-Dateisystem zugeordnet sind.

Darüber hinaus verbessert SAP HANA Fast Restart auf VMs der Familien M2 und M3 der speicheroptimierten Maschinentypen von Compute Engine die Wiederherstellungszeit, falls nicht behebbare Fehler im Speicher auftreten. Weitere Informationen finden Sie unter Wiederherstellung von Speicherfehlern mit Fast Restart auf Compute Engine-VMs.

Erforderliche Betriebssystemeinstellungen für SAP HANA Fast Restart

Um SAP HANA Fast Restart zu verwenden, muss das Betriebssystem von SAP entsprechend angepasst werden.

Wenn Sie die von Google Cloud bereitgestellten Terraform-Konfigurationsdateien oder Deployment Manager-Vorlagen verwenden, werden die Kernel-Einstellungen für Sie festgelegt.

Wenn Sie nicht die von Google Cloud bereitgestellten Bereitstellungsdateien verwenden, bietet SAP eine Anleitung zum Konfigurieren der Betriebssysteme RHEL und SLES für SAP HANA. Achten Sie beim schnellen Neustart von SAP HANA besonders auf die korrekte Einstellung von numa_balancing und transparent_hugepage.

Wenn Sie RHEL verwenden, verwenden Sie das abgestimmte Profil sap-hana, falls verfügbar. Die Konfigurationsschritte finden Sie unter:

• SAP-Hinweis 2292690 – SAP HANA-DB: Empfohlene Betriebssystemeinstellungen für RHEL 7
• SAP-Hinweis 2777782 – SAP HANA-DB: Empfohlene Betriebssystemeinstellungen für RHEL 8
• SAP-Hinweis 3108302 – SAP HANA-DB: Empfohlene Betriebssystemeinstellungen für RHEL 9

Wenn Sie SLES verwenden, wenden Sie die erforderliche Konfiguration mit dem saptune-Tool von SUSE an. Geben Sie folgenden saptune-Befehl an, um alle empfohlenen SAP HANA-Einstellungen anzuwenden, einschließlich der beiden vorherigen Kernelparameter:

saptune solution apply HANA

Weitere Informationen zum Konfigurieren von SLES für SAP HANA finden Sie unter:

• SAP-Hinweis 2205917 – SAP HANA-DB: Empfohlene Betriebssystemeinstellungen für SLES 12 / SLES for SAP Applications 12
• SAP-Hinweis 2684254 – SAP HANA-DB: Empfohlene Betriebssystemeinstellungen für SLES 15 / SLES for SAP Applications 15

Wiederherstellung von Speicherfehlern mit Fast Restart auf Compute Engine-VMs

Das Aktivieren von SAP HANA Fast Restart auf VMs in den Familien M2 und M3 von speicheroptimierten Maschinentypen führt zu einer Reduzierung der Zeit, die SAP HANA zur Wiederherstellung nach nicht korrigierbaren Speicherfehlern benötigt.

Durch die Nutzung von Intel-Prozessorfunktionen können die M2/M3-Maschinentypen auch dann weiter ausgeführt werden, wenn im Speichersubsystem nicht korrigierbare Fehler auftreten. Ist SAP HANA Fast Restart beim Auftreten des Speicherfehlers aktiviert, so wird der betroffene SAP HANA-Prozess neu gestartet, aber es muss nicht die gesamte Datenbank neu geladen werden, sondern nur den betroffenen Dateiblock.

Maschinentypen, die die Wiederherstellung nach Speicherfehlern unterstützen

Die Wiederherstellung nach Speicherfehlern von folgenden Compute Engine-Maschinentypen wird nicht unterstützt:

• m3-ultramem-32
• m3-ultramem-64
• m3-ultramem-128
• m3-megamem-64
• m3-megamem-128
• m2-ultramem-208
• m2-ultramem-416
• m2-megamem-416
• m2-hypermem-416

Erforderliche Betriebssysteme für die Wiederherstellung nach Speicherfehlern

Mit den erforderlichen Kernel-Patches unterstützen die folgenden Betriebssysteme die Wiederherstellung von Speicherfehlern mit SAP HANA Fast Restart:

• SUSE Linux Enterprise Server (SLES) für SAP, 12 SP3 oder höher
  • Ist in öffentlichen Compute Engine-Images mit dem Build-Datum v202103* oder höher enthalten.
  • Wenn Sie die neuesten Kernel-Patches auf eine vorhandene Bereitstellung anwenden müssen, folgen Sie dem Standardaktualisierungsprozess. Führen Sie beispielsweise die folgenden Befehle aus:
    • sudo zypper refresh
    • sudo zypper update
• Red Hat Enterprise Linux (RHEL) für SAP 8.4 oder höher

Dateiserveroptionen

Die Dateiserveroptionen für SAP HANA in Google Cloud umfassen Filestore und NetApp Cloud Volumes-Dienst für Google Cloud.

Weitere Informationen zu allen Dateiserveroptionen für SAP in Google Cloud finden Sie unter Dateifreigabelösungen für SAP in Google Cloud.

Filestore

Für das Volume /hana/shared in einer Konfiguration mit horizontaler Skalierung und einzelner Zone empfehlen wir die Verwendung der Dienststufe Filestore Basic, die für zonale Ressourcen bestimmt ist. Für Szenarien, in denen zusätzliche Ausfallsicherheit erforderlich ist, können Sie Filestore Enterprise verwenden. Weitere Informationen finden Sie unter Komponenten in einem SAP HANA-System mit horizontaler Skalierung in Google Cloud.

NetApp Cloud Volumes-Dienst für Google Cloud

NetApp Cloud Volumes-Dienst für Google Cloud ist eine vollständig verwaltete, cloudnative Datendienstplattform, mit der Sie ein NFS-Dateisystem für SAP HANA-Systeme mit vertikaler Skalierung auf allen Compute Engine-Instanztypen erstellen können, die für SAP HANA zertifiziert sind. Informationen zur Verwendung des NetApp Cloud Volumes-Diensts für Google Cloud mit Ihrer SAP HANA-Bereitstellung finden Sie unter NetApp Cloud Volumes-Dienst für Google Cloud.

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.

Bare-Metal-Maschinentypen für SAP HANA

Dieser Abschnitt enthält Informationen zum Ausführen von SAP HANA auf den von Compute Engine bereitgestellten Bare-Metal-Maschinentypen, darunter:

• C3-Bare-Metal-Maschinentypen: Die C3-Serie von Maschinen für allgemeine Zwecke umfasst Bare-Metal-Maschinentypen.

  • Informationen zu den C3-Bare-Metal-Maschinentypen, die von SAP für die Verwendung mit SAP HANA zertifiziert sind, finden Sie unter C3-Bare-Metal-Maschinentypen für allgemeine Zwecke.
  • Informationen zu den Betriebssystemversionen, die Sie mit den C3-Bare-Metal-Maschinentypen für die Ausführung von SAP HANA-Arbeitslasten verwenden können, finden Sie unter Zertifizierte Betriebssysteme für SAP HANA.
  • Informationen zum erforderlichen Mindestblockspeicher für die Ausführung von SAP HANA auf C3-Bare-Metal-Maschinentypen finden Sie unter Mindestgrößen für SSD-basierte Persistent Disk- und Hyperdisk-Volumes.
  • Weitere Informationen zur C3-Maschinenreihe finden Sie unter C3-Maschinenreihe.

• X4: Die vierte Generation speicheroptimierter Maschinentypen, die von der Compute Engine angeboten wird. Diese Maschinen wurden hauptsächlich für SAP-Arbeitslasten entwickelt, die bis zu 32 TB Arbeitsspeicher benötigen.

  • Informationen zu den X4-Maschinentypen, die von SAP für die Verwendung mit SAP HANA zertifiziert sind, finden Sie unter Speicheroptimierte Bare Metal X4-Maschinentypen.
  • Informationen zu den Betriebssystemversionen, die Sie mit den X4-Maschinentypen für die Ausführung von SAP HANA-Arbeitslasten verwenden können, finden Sie unter Zertifizierte Betriebssysteme für SAP HANA.
  • Informationen zum unterstützten Blockspeicher für die Ausführung von SAP HANA auf X4-Maschinentypen finden Sie unter Unterstützter Blockspeicher für X4.
  • Weitere Informationen zur X4-Maschinenserie finden Sie unter X4-Maschinenserie.

Unterstützter Blockspeicher für X4

Sie können Hyperdisk Extreme- oder Hyperdisk Balanced-Volumes verwenden, um Blockspeicher für die Ausführung von SAP HANA-Arbeitslasten auf X4-Maschinen bereitzustellen.

Informationen zu den von Google Cloud für X4-Instanzen empfohlenen Speicherkonfigurationen finden Sie in den folgenden Abschnitten:

• Kostenoptimierte Konfiguration
• Konfiguration zur Leistungsoptimierung
• Flexible Leistungskonfiguration

Hinweis: Die folgenden Speicherkonfigurationen sind nur erste Empfehlungen. Wir empfehlen Ihnen dringend, die Größe Ihrer Arbeitslasten zu bestimmen und Validierungen durchzuführen, um eine optimale Leistung zu erzielen.

Kostenoptimierte Konfiguration

In der folgenden Tabelle ist eine kostenoptimierte Speicherkonfiguration für die Ausführung von SAP HANA auf X4-Maschinentypen zu sehen. Bei den Größen in der folgenden Tabelle wird davon ausgegangen, dass Sie alle SAP HANA-Volumes auf einzelnen Laufwerken bereitstellen.

Maschinentyp	Boot-Volume (GB)	/usr/sap (GB)	/hana/shared (GB)	/hana/log-Größe (GB), IOPS und Durchsatz	/hana/data (GB), IOPS und Durchsatz
	Hyperdisk Balanced
x4-megamem-960-metal	50	32	1.024	512 GB mit 10.000 IOPS und 2.400 Mbit/s Durchsatz	16.384 GB mit 16.384 IOPS und 2.400 Mbit/s Durchsatz
x4-megamem-1440-metal	50	32	1.024	512 GB mit 10.000 IOPS und 2.400 Mbit/s Durchsatz	24.576 GB mit 24.576 IOPS und 2.400 Mbit/s Durchsatz
x4-megamem-1920-metal	50	32	1.024	512 GB mit 10.000 IOPS und 2.400 Mbit/s Durchsatz	32.768 GB mit 32.768 IOPS und 2.400 Mbit/s Durchsatz

Konfiguration zur Leistungsoptimierung

In der folgenden Tabelle ist eine leistungsoptimierte Speicherkonfiguration für das Ausführen von SAP HANA auf X4-Maschinentypen zu sehen. Bei den Größen in der folgenden Tabelle wird davon ausgegangen, dass Sie alle SAP HANA-Volumes auf einzelnen Laufwerken bereitstellen.

Maschinentyp	Boot-Volume (GB)	/usr/sap (GB)	/hana/shared (GB)	/hana/log-Größe (GB), IOPS und Durchsatz	/hana/data (GB), IOPS und Durchsatz
	Hyperdisk Balanced				Hyperdisk Extrem
x4-megamem-960-metal	50	32	1.024	512 GB mit 10.000 IOPS und 2.400 Mbit/s Durchsatz	16.384 GB mit 32.768 IOPS und 5.000 Mbit/s Durchsatz
x4-megamem-1440-metal	50	32	1.024	512 GB mit 10.000 IOPS und 2.400 MB/s Durchsatz	24.576 GB mit 49.152 IOPS und 5.000 Mbit/s Durchsatz
x4-megamem-1920-metal	50	32	1.024	512 GB mit 10.000 IOPS und 2.400 Mbit/s Durchsatz	32.768 GB mit 65.536 IOPS und 5.000 Mbit/s Durchsatz

Flexible Leistungskonfiguration

In der folgenden Tabelle ist eine Speicherkonfiguration zu sehen, die eine flexible Leistung für die Ausführung von SAP HANA auf X4-Maschinentypen bietet. Bei den Größen in der folgenden Tabelle wird davon ausgegangen, dass Sie alle SAP HANA-Volumes auf einzelnen Laufwerken bereitstellen.

Maschinentyp	Boot-Volume (GB)	/usr/sap (GB)	/hana/shared (GB)	/hana/log-Größe (GB), IOPS und Durchsatz	/hana/data (GB), IOPS und Durchsatz
	Hyperdisk Balanced			Hyperdisk Extrem
x4-megamem-960-metal	50	32	1.024	512 GB mit 10.000 IOPS und 2.500 Mbit/s Durchsatz	16.384 GB mit 32.768 IOPS und 5.000 Mbit/s Durchsatz
x4-megamem-1440-metal	50	32	1.024	512 GB mit 10.000 IOPS und 2.500 Mbit/s Durchsatz	24.576 GB mit 49.152 IOPS und 5.000 Mbit/s Durchsatz
x4-megamem-1920-metal	50	32	1.024	512 GB mit 10.000 IOPS und 2.500 Mbit/s Durchsatz	32.768 GB mit 65.536 IOPS und 5.000 Mbit/s Durchsatz

Automatisierung der Bereitstellung

Zum Ausführen von SAP HANA können Sie die Bare-Metal-Instanzen mithilfe der von Google Cloud bereitgestellten Terraform-Konfigurationen bereitstellen. Diese Konfigurationen sind für folgende Aufgaben gedacht:

• Hyperdisk Extreme-Volumes bereitstellen, um die SAP HANA-Daten- und -Log-Volumes zu hosten. Wenn Sie stattdessen Hyperdisk Balanced-Volumes bereitstellen möchten, verwenden Sie das Terraform-Argument disk_type.
• Aktivieren Sie die Option „Schneller SAP HANA-Neustart“.
• Wenn Sie das SAP HANA-Sicherungsvolume auf einem Laufwerk hosten, wird mit diesen Terraform-Konfigurationen standardmäßig ein Hyperdisk Balanced-Volume bereitgestellt. Diese Laufwerkbereitstellung wird durch das Terraform-Argument backup_disk_type bestimmt.

Informationen zu den Terraform-Konfigurationen, die Google Cloud für die Bereitstellung von SAP HANA bereitstellt, finden Sie unter Unterstützte SAP-Lösungen.

Aufgaben nach der Bereitstellung

Nachdem Sie eine Bare-Metal-Instanz bereitgestellt haben, um SAP HANA auszuführen, sollten Sie Folgendes tun:

• Prüfen Sie, ob Version 3.6 (aktuell) des Google Cloud-Agents für SAP installiert ist. Informationen zum Installieren des Agents finden Sie unter Google Cloud-Agent für SAP auf einer Compute Engine-Instanz installieren und konfigurieren. Informationen zum Aktualisieren auf die neueste Version finden Sie unter Google Cloud-Agent für SAP aktualisieren.
• Optimieren Sie die Betriebssystemkonfiguration auf X4-Instanzen, um SAP HANA-Arbeitslasten optimal zu unterstützen. Verwenden Sie dazu den Google Cloud-Agent für SAP. Weitere Informationen finden Sie unter Gastbetriebssystem auf Bare-Metal-Instanzen konfigurieren.
• SAP-Arbeitslast mit Workload Manager bewerten, einem regelbasierten Validierungsdienst, mit dem Sie Ihre Arbeitslasten scannen und Abweichungen von Standards, Regeln und Best Practices erkennen können, die von SAP, Google Cloud und Betriebssystemanbietern vorgegeben werden. Informationen zum Bewerten Ihrer SAP-Arbeitslast finden Sie unter Evaluierung erstellen und ausführen. Informationen zu den unterstützten Bewertungen für SAP-Arbeitslasten finden Sie unter Best Practices von Workload Manager für SAP.

Hyperthreading

Hyperthreading ist standardmäßig aktiviert und die empfohlene Einstellung für alle Compute Engine-Maschinentypen.

Für eine optimale Leistung von SAP HANA auf Compute-Instanzen mit mehr als 1.000 vCPUs empfehlen wir dringend die Verwendung von SAP HANA 2.0 SPS7 Version 76 oder höher.

Wenn Sie eine ältere Version von SAP HANA mit einer OLTP-Arbeitslast auf Compute-Instanzen mit mehr als 1.000 vCPUs ausführen, kann das Deaktivieren des Hyperthreadings zu einem geringfügigen Leistungsvorteil führen. Wir empfehlen, dies während eines Lasttests zu testen. Informationen zum Deaktivieren des Hyperthreadings für Ihre X4-Instanz mit dem Google Cloud-Agent für SAP finden Sie unter Hyperthreading für eine X4-Instanz deaktivieren.

Überlegungen zu Preisen und Kontingenten für SAP HANA

Sie sind für die Kosten verantwortlich, die durch die Verwendung der Ressourcen entstehen, die durch das Befolgen dieser Bereitstellungsanleitung erstellt wurden. Verwenden Sie den Preisrechner, um Ihre tatsächlichen Kosten abzuschätzen.

Wichtig: RHEL und SLES sind Premium-Images. Alle Preise für Premium-Images gelten zusätzlich zu den Gebühren für die Nutzung eines Maschinentyps. Weitere Informationen zu Preisen für Premium-Images finden Sie unter Premium-Images.

Hinweis: Es gibt die Möglichkeit eines Rabatts für kontinuierliche Nutzung von bis zu 30 % für Ihre Compute Engine-Instanzen.

Kontingente

SAP HANA benötigt mehr CPU und Arbeitsspeicher als viele Arbeitslasten in Google Cloud. Wenn Sie ein neues Google Cloud-Konto erstellt oder noch kein höheres Kontingent angefordert haben, müssen Sie dies tun, um SAP HANA bereitstellen zu können.

Die folgende Tabelle zeigt Kontingentwerte für SAP HANA-Systeme mit einzelnem Host und vertikaler Skalierung nach VM-Instanztyp.

Bei einem SAP HANA-System mit horizontaler Skalierung oder mehreren Systemen mit vertikaler Skalierung müssen Sie die Gesamtressourcenmenge für alle Systeme angeben. Informationen zum Bestimmen der Speicheranforderungen für Systeme mit horizontaler Skalierung finden Sie unter Größe des nichtflüchtigen Speichers bestimmen.

Sehen Sie sich Ihr vorhandenes Kontingent an und vergleichen Sie es mit Ihren Ressourcenanforderungen (CPU, Arbeitsspeicher und Speicher), um zu bestimmen, in welchem Umfang Sie eine Erhöhung anfordern sollten. Anschließend können Sie ein höheres Kontingent anfordern.

Extrem nichtflüchtiger Speicher (pd-extreme) ist weiterhin für die Verwendung mit SAP HANA zertifiziert, wir empfehlen jedoch stattdessen die Verwendung von Hyperdisk Extrem, das eine höhere Leistung bietet. Wenn Sie extrem nichtflüchtige Speicher verwenden möchten, müssen Sie sie mit Hyperdisk Extrem-Größen bereitstellen.

Abgestimmter nichtflüchtiger Speicher

Compute Engine-VM-Typ	vCPU	Arbeitsspeicher (GB)	Kontingent (GB)
n1-highmem-32	32	208	943
n1-highmem-64	64	416	1.155
n1-highmem-96	96	624	1.716
n2-highmem-32	32	256	943
n2-highmem-48	48	384	1.068
n2-highmem-64	64	512	1.414
n2-highmem-80	80	640	1.760
n2-highmem-96	96	768	2.105
n2-highmem-128	128	864	2.364
c3-standard-44	44	176	507
c3-highmem-44	44	352	982
c3-highmem-88	88	704	1.932
c3-highmem-176	176	1.408	3.257
m1-megamem-96	96	1.433	3.287
m1-ultramem-40	40	961	2.626
m1-ultramem-80	80	1.922	3.874
m1-ultramem-160	160	3.844	6.180
m2-megamem-416	416	5.888	8.633
m2-ultramem-208	208	5.888	8.633
m2-ultramem-416	416	11.766	15.660
m2-hypermem-416	416	8.832	12.166
m3-ultramem-32	32	976	2.667
m3-ultramem-64	64	1.952	3.910
m3-ultramem-128	128	3.904	6.252
m3-megamem-64	64	976	2.667
m3-megamem-128	128	1.952	3.910

Nichtflüchtiger SSD-Speicher

Compute Engine-VM-Typ	vCPU	Arbeitsspeicher (GB)	Kontingent (GB)
n1-highmem-32	32	208	593
n1-highmem-64	64	416	1.155
n1-highmem-96	96	624	1.716
n2-highmem-32	32	256	723
n2-highmem-48	48	384	1.068
n2-highmem-64	64	512	1.414
n2-highmem-80	80	640	1.760
n2-highmem-96	96	768	2.105
n2-highmem-128	128	864	2.364
c3-standard-44	44	176	507
c3-highmem-44	44	352	982
c3-highmem-88	88	704	1.932
c3-highmem-176	176	1.408	3.257
m1-megamem-96	96	1.433	3.287
m1-ultramem-40	40	961	2.626
m1-ultramem-80	80	1.922	3.874
m1-ultramem-160	160	3.844	6.180
m2-megamem-416	416	5.888	8.633
m2-ultramem-208	208	5.888	8.633
m2-ultramem-416	416	11.766	15.660
m2-hypermem-416	416	8.832	12.166
m3-ultramem-32	32	976	2.667
m3-ultramem-64	64	1.952	3.910
m3-ultramem-128	128	3.904	6.252
m3-megamem-64	64	976	2.667
m3-megamem-128	128	1.952	3.910

Hyperdisk Extrem

Compute Engine-VM-Typ	vCPU	Arbeitsspeicher (GB)	Kontingent (GB)
n2-highmem-80	80	640	1.760
n2-highmem-96	96	768	2.105
n2-highmem-128	128	864	2.364
c3-highmem-88	88	704	1.932
c3-highmem-176	176	1.408	3.257
c3-highmem-192-metal	192	1.536	3.411
c4-highmem-32	32	248	701
c4-highmem-48	48	372	1.036
c4-highmem-96	96	744	2.040
c4-highmem-192	192	1.488	3.353
m1-megamem-96	96	1.433	3.287
m1-ultramem-80	80	1.922	3.874
m1-ultramem-160	160	3.844	6.180
m2-megamem-416	416	5.888	8.633
m2-ultramem-208	208	5.888	8.633
m2-ultramem-416	416	11.766	15.660
m2-hypermem-416	416	8.832	12.166
m3-ultramem-64	64	1.952	3.910
m3-ultramem-128	128	3.904	6.252
m3-megamem-64	64	976	2.667
m3-megamem-128	128	1.952	3.910
Wichtig: Informationen zum Kauf von Kontingenten für X4-Instanzen oder zu On-Demand-Preisen für das Testen von X4-Instanzen erhalten Sie von Ihrem Google Cloud-Kundenbetreuer.
x4-megamem-960-metal	960	16.384	17.952
x4-megamem-1440-metal	1.440	24.576	26.144
x4-megamem-1920-metal	1.920	32.768	34.336

Hyperdisk Balanced

Compute Engine-VM-Typ	vCPU	Arbeitsspeicher (GB)	Kontingent (GB)
c3-standard-44	44	176	507
c3-highmem-44	44	352	982
c3-highmem-88	88	704	1.932
c3-highmem-176	176	1.408	3.257
c3-highmem-192-metal	192	1.536	3.411
c4-highmem-32	32	248	701
c4-highmem-48	48	372	1.036
c4-highmem-96	96	744	2.040
c4-highmem-192	192	1.488	3.353
m1-megamem-96	96	1.433	3.287
m1-ultramem-40	40	961	2.626
m1-ultramem-80	80	1.922	3.874
m1-ultramem-160	160	3.844	6.180
m2-megamem-416	416	5.888	8.633
m2-ultramem-208	208	5.888	8.633
m2-ultramem-416	416	11.766	15.660
m2-hypermem-416	416	8.832	12.166
m3-ultramem-32	32	976	2.667
m3-ultramem-64	64	1.952	3.910
m3-ultramem-128	128	3.904	6.252
m3-megamem-64	64	976	2.667
m3-megamem-128	128	1.952	3.910
Wichtig: Informationen zum Kauf von Kontingenten für X4-Instanzen oder zu On-Demand-Preisen für das Testen von X4-Instanzen erhalten Sie von Ihrem Google Cloud-Kundenbetreuer.
x4-megamem-960-metal	960	16.384	17.952
x4-megamem-1440-metal	1.440	24.576	26.144
x4-megamem-1920-metal	1.920	32.768	34.336

Nichtflüchtiger Standardspeicher

Compute Engine-VM-Typ	vCPU	Arbeitsspeicher (GB)	Kontingent (GB)
n1-highmem-32	32	208	448
n1-highmem-64	64	416	864
n1-highmem-96	96	624	1.280
n2-highmem-32	32	256	544
n2-highmem-48	48	384	800
n2-highmem-64	64	512	1.056
n2-highmem-80	80	640	1.312
n2-highmem-96	96	768	1.568
n2-highmem-128	128	864	1.760
m1-megamem-96	96	1.433	2.898
m1-ultramem-40	40	961	1.954
m1-ultramem-80	80	1.922	3.876
m1-ultramem-160	160	3.844	7.720
m2-megamem-416	416	5.888	11.832
m2-ultramem-208	208	5.888	11.832
m2-ultramem-416	416	11.766	23.564
m2-hypermem-416	416	8.832	17.696

Lizenzierung

Wenn Sie SAP HANA in Google Cloud ausführen, müssen Sie eine eigene Lizenz haben (BYOL).

Hinweis: Nach der Bereitstellung von SAP HANA auf Google Cloud müssen Sie Ihre permanente SAP HANA-Lizenz installieren, bevor die temporäre Lizenz für SAP HANA abläuft. Andernfalls wird SAP HANA möglicherweise nach Ablauf der temporären Lizenz die Datenbank sperren.

Weitere Informationen von SAP über das Verwalten Ihrer SAP HANA-Lizenzen finden Sie unter Lizenzschlüssel für die SAP HANA-Datenbank.

Deployment-Architekturen

In Google Cloud können Sie SAP HANA in Architekturen mit vertikaler und horizontaler Skalierung bereitstellen.

Vertikal skalierende Architektur

Das folgende Diagramm zeigt die vertikal skalierende Architektur. Achten Sie im Diagramm auf die Bereitstellung in Google Cloud und auf das Laufwerkslayout. Sie können Ihre lokalen Sicherungen, die in /hanabackup verfügbar sind, mit Cloud Storage speichern. Dieses bereitgestellte Verzeichnis muss mindestens so groß sein wie das bereitgestellte Datenverzeichnis.

In Google Cloud kann eine SAP HANA-Architektur mit einzelnem Host und vertikaler Skalierung folgende Komponenten enthalten:

• Eine Compute Engine-Instanz für die SAP HANA-Datenbank mit einer Netzwerkbandbreite von bis zu 32 Gbit/s oder bis zu 100 Gbit/s auf ausgewählten Maschinentypen mit Netzwerk mit hoher Bandbreite. Informationen zu den Maschinentypen, die für die Verwendung mit SAP HANA zertifiziert sind, finden Sie unter Zertifizierte Maschinentypen für SAP HANA.

• SSD-basierte nichtflüchtige Compute Engine-Speicher- oder Hyperdisk-Volumes:

  • Ein Laufwerk für jedes der folgenden Verzeichnisse: /hana/data, /hana/log, /hana/shared und /usr/sap. Informationen zu Empfehlungen für Laufwerke für SAP HANA finden Sie unter Nichtflüchtiger Speicher. Für eine optimale Leistung müssen die Volumes von Persistent Disks oder Hyperdisks gemäß der Tabelle unter Mindestgrößen für SSD-basierte Persistent Disk- und Hyperlaufwerk-Volumes dimensioniert werden.

  • Ein abgestimmter nichtflüchtiger Speicher für das Bootlaufwerk.

  • Optional ein Laufwerk für die Sicherung der SAP HANA-Datenbank.

• Compute Engine-Firewallregeln, die den Zugriff auf Instanzen einschränken.

• Google Cloud-Agent für SAP. Ab Version 2.0 können Sie diesen Agent so konfigurieren, dass er die SAP HANA-Monitoringmesswerte erfasst, sodass Sie Ihre SAP HANA-Instanzen überwachen können. Ab Version  3.0 können Sie auch das Backint-Feature verwenden, um SAP HANA-Sicherungen direkt im Cloud Storage-Bucket zu speichern und bei Bedarf abzurufen.

• Ein optionales, aber empfohlenes Subnetz mit benutzerdefinierter Topologie und IP-Bereichen in der Google Cloud-Region Ihrer Wahl. Innerhalb dieses Subnetzwerks werden die SAP HANA-Datenbank und die anderen Compute Engine-Instanzen gestartet. Sie können für SAP HANA ein vorhandenes Subnetz verwenden.

• Optionale Komponenten:

  • SAP HANA Cockpit oder SAP HANA Studio auf kleinen Compute Engine-VMs.

Wenn Sie Ihr SAP HANA-System ohne öffentliche IP-Adresse bereitstellen, kann es nicht direkt über das öffentliche Internet eine Verbindung zu Ressourcen herstellen. Daher müssen Sie eine indirekte Methode für den Internetzugriff mithilfe der folgenden Optionen bereitstellen:

• Konfigurieren Sie den privaten Google-Zugriff, damit Ihre VM auf die Google Cloud APIs zugreifen kann.

• Verwenden Sie Cloud NAT oder konfigurieren Sie eine VM als NAT-Gateway für den Zugriff auf das öffentliche Internet.

• Für Verwaltungszwecke können Sie die TCP-Weiterleitung nutzen, um eine Verbindung zu den Systemen herzustellen. Informationen zur Verwendung von Identity-Aware Proxy für die TCP-Weiterleitung finden Sie unter IAP für TCP-Weiterleitung nutzen.

• Die als Bastion Host konfigurierte Compute Engine-VM nutzen, um auf das öffentliche Internet zuzugreifen.

Horizontal skalierende Architekturen

Die Architektur mit horizontaler Skalierung besteht aus einem Master-Host, mehreren Worker-Hosts und optional einem oder mehreren Standby-Hosts. Die Hosts sind über ein Netzwerk miteinander verbunden, das das Senden von Daten zwischen Hosts mit Raten von bis zu 32 Gbit/s oder bis zu 100 Gbit/s auf ausgewählten Maschinentypen mit Netzwerken mit hoher Bandbreite unterstützt.

Mit steigender Arbeitslast, insbesondere bei Verwendung von OLAP (Online Analytical Processing), kann eine Architektur mit horizontaler Skalierung und mit mehreren Hosts die Last auf alle Hosts verteilen.

Das folgende Diagramm zeigt eine horizontal skalierende Architektur für SAP HANA in Google Cloud:

Standbyhosts unterstützen die Fehlerwiederherstellungslösung mit automatischem Failover für den SAP HANA-Host. Weitere Informationen zum automatischen Host-Failover in Google Cloud finden Sie unter Automatischer SAP HANA-Host-Failover in Google Cloud.

Folgendes Diagramm zeigt eine horizontal skalierende Architektur mit automatischem Host-Failover in Google Cloud.

Laufwerksstrukturen für SAP HANA-Systeme mit horizontaler Skalierung in Google Cloud

Mit Ausnahme von Standbyhosts hat jeder Host eigene /hana/data-, /hana/log- und normalerweise /usr/sap-Volumes auf SSD-basierten nichtflüchtigen Speichern oder Hyperdisks, die konsistente E/A-Dienste mit hohen IOPS bereitstellen. Der Masterhost dient auch als NFS-Master für die Volumes /hana/shared und /hanabackup, die auf jedem Worker- und Standbyhost bereitgestellt werden.

Bei einem Standbyhost werden die Volumes /hana/data und /hana/log erst dann bereitgestellt, wenn ein Takeover erfolgt.

Komponenten in einem SAP HANA-System mit horizontaler Skalierung in Google Cloud

Eine SAP HANA-Architektur mit mehreren Hosts und horizontaler Skalierung in Google Cloud enthält die folgenden Komponenten:

• 1 Compute Engine-VM-Instanz für jeden SAP HANA-Host im System, einschließlich 1 Master-Host, bis zu 15 Worker-Hosts und bis zu 3 optionalen Standby-Hosts.

  Jede VM verwendet denselben Compute Engine-Maschinentyp. Informationen zu den Maschinentypen, die für die Verwendung mit SAP HANA zertifiziert sind, finden Sie unter Zertifizierte Maschinentypen für SAP HANA.

• SSD-basierte Persistent Disk- oder Hyperdisk-Volumes:

  • Jede VM muss ein Laufwerk enthalten, das am richtigen Speicherort bereitgestellt ist.
  • Wenn Sie kein System für das automatische Failover des SAP HANA-Hosts bereitstellen, kann optional ein Laufwerk für das lokale Volume /hanabackup für jede VM-Instanz genutzt werden.

• Eine separat bereitgestellte NFS-Lösung zur Freigabe der Volumes /hana/shared und /hanabackup für die Worker- und Standbyhosts. Sie können Filestore oder eine andere NFS-Lösung verwenden.

• Compute Engine-Firewallregeln oder andere Optionen für Netzwerkzugriffssteuerung, die den Zugriff auf Compute Engine-Instanzen einschränken und gleichzeitig die Kommunikation zwischen den Instanzen und mit anderen verteilten oder externen Ressourcen, die Ihr SAP HANA-System benötigt, ermöglichen.

• Google Cloud-Agent für SAP. Ab Version 2.0 können Sie diesen Agent so konfigurieren, dass er die SAP HANA-Monitoringmesswerte erfasst, sodass Sie Ihre SAP HANA-Instanzen überwachen können. Ab Version  3.0 können Sie auch das Backint-Feature verwenden, um SAP HANA-Sicherungen direkt im Cloud Storage-Bucket zu speichern und bei Bedarf abzurufen.

• Ein optionales, aber empfohlenes Subnetz mit benutzerdefinierter Topologie und IP-Bereichen in der Google Cloud-Region Ihrer Wahl. Innerhalb dieses Subnetzwerks werden die SAP HANA-Datenbank und die anderen Compute Engine-Instanzen gestartet. Sie können ein vorhandenes Subnetzwerk verwenden, wenn Sie möchten.

• Optionale Komponenten:

  • SAP HANA Cockpit oder SAP HANA Studio auf kleinen Compute Engine-VMs.

Wenn Sie Ihr SAP HANA-System ohne öffentliche IP-Adresse bereitstellen, kann es nicht direkt über das öffentliche Internet eine Verbindung zu Ressourcen herstellen. Daher müssen Sie eine indirekte Methode für den Internetzugriff mithilfe der folgenden Optionen bereitstellen:

• Konfigurieren Sie den privaten Google-Zugriff, damit Ihre VM auf die Google Cloud APIs zugreifen kann.

• Verwenden Sie Cloud NAT oder konfigurieren Sie eine VM als NAT-Gateway für den Zugriff auf das öffentliche Internet.

• Für Verwaltungszwecke können Sie die TCP-Weiterleitung nutzen, um eine Verbindung zu den Systemen herzustellen. Informationen zur Verwendung von Identity-Aware Proxy für die TCP-Weiterleitung finden Sie unter IAP für TCP-Weiterleitung nutzen.

• Die als Bastion Host konfigurierte Compute Engine-VM nutzen, um auf das öffentliche Internet zuzugreifen.

Hochverfügbarkeit für SAP HANA in Google Cloud

Zum Entwerfen einer Hochverfügbarkeitskonfiguration für SAP HANA in Google Cloud können Sie eine Kombination aus Google Cloud, SAP und nativen Betriebssystemfunktionen verwenden.

Informationen zu den Hochverfügbarkeitsoptionen finden Sie im Leitfaden zur Planung der Hochverfügbarkeit für SAP HANA.

Automatisierung für SAP HANA-Bereitstellungen

Google Cloud bietet Terraform-Konfigurationsdateien und Deployment Manager-Vorlagen, mit denen Sie die Bereitstellung der Google Cloud-Infrastruktur und (optional) SAP HANA automatisieren können.

Die von Google Cloud bereitgestellten Optionen zur Bereitstellungsautomatisierung unterstützen die folgenden SAP HANA-Bereitstellungsszenarien:

• Hochskalieren
• Vertikal in einem Hochverfügbarkeitscluster mit zwei Knoten skalieren
• Horizontal ohne Standby-Knoten skalieren
• Horizontal ohne Standby-Knoten in einem Hochverfügbarkeitscluster skalieren
• Horizontal mit SAP HANA Host Auto-Failover Standby-Knoten skalieren

Weitere Informationen zur Automatisierung für Deployment-Szenarien mit vertikaler oder horizontaler Skalierung finden Sie unter:

• Bereitstellungsautomatisierung für Systeme mit vertikaler Skalierung
• Bereitstellungsautomatisierung für Systeme mit horizontaler Skalierung

Bereitstellung der SAP HANA-Instanz automatisieren

Optional können Sie die Installation von SAP HANA in die automatisierte Bereitstellung der Google Cloud-Infrastruktur einbeziehen.

Die von Google Cloud bereitgestellten Installationsskripte installieren SAP HANA nach der Bereitstellung der Infrastruktur.

Wenn Probleme die Installation einer SAP HANA-Instanz verhindern, wird die Infrastruktur normalerweise noch bereitgestellt und konfiguriert. Sie können dann die bereitgestellte Infrastruktur verwenden und SAP HANA manuell installieren oder die Infrastruktur löschen, das Problem beheben und die Bereitstellungsautomatisierung noch einmal ausführen, bis die SAP HANA-Instanz erfolgreich installiert ist.

Wenn Sie die Installationsskripts verwenden, die Google Cloud zur Installation von SAP HANA verwendet, müssen Sie Werte für bestimmte Parameter angeben. Wenn Sie diese Parameter weglassen oder keine gültigen Werte für alle angeben, kann das Installationsskript die SAP HANA-Instanz nicht auf der bereitgestellten Infrastruktur installieren.

• Wenn Sie die von Google Cloud bereitgestellten Terraform-Konfigurationsdateien zum Installieren von SAP HANA verwenden, müssen Sie für die folgenden Argumente gültige Werte angeben: sap_hana_deployment_bucket, sap_hana_sid, sap_hana_sidadm_uid. sap_hana_sidadm_password und sap_hana_system_password. Weitere Informationen zu den Terraform-Argumenten finden Sie unter Terraform: SAP HANA-Bereitstellungsanleitung für vertikale Skalierung.

• Wenn Sie die von Google Cloud bereitgestellten Deployment Manager-Vorlagen zur Installation von SAP HANA verwenden, müssen Sie gültige Werte für die folgenden Konfigurationsparameter angeben: sap_hana_deployment_bucket, sap_hana_sid, sap_hana_instance_number, sap_hana_sidadm_password, sap_hana_system_password und sap_hana_scaleout_nodes. Weitere Informationen zu den Deployment Manager-Attributen finden Sie unter Bereitstellungsleitfaden für Deployment Manager: SAP HANA mit vertikaler Skalierung.

Passwortverwaltung

Wenn Sie die Installation von SAP HANA auf den bereitgestellten Compute Engine-VMs automatisieren möchten, müssen Sie die Passwörter für den Nutzer SIDadm und den Datenbanknutzer angeben. Sie können diese Passwörter in Ihrer Terraform-Konfigurationsdatei so angeben:

• (Empfohlen) Um die Passwörter für die Installationsskripts sicher bereitzustellen, können Sie Secrets mit Secret Manager erstellen, einem kostenpflichtigen Dienst von Google Cloud, und dann die Namen der Secrets als Werte für die Argumente sap_hana_sidadm_password_secret und sap_hana_system_password_secret angeben.

  Informationen zu den Preisen für Secret Manager finden Sie unter Secret Manager – Preise.

• Alternativ können Sie die Passwörter im Nur-Text-Format in den Argumenten sap_hana_sidadm_password und sap_hana_system_password angeben.

Hinweis: Sie müssen für beide Passwörter entweder Secrets verwenden oder beide direkt im Nur-Text-Format angeben. Außerdem müssen die Secrets in dem Google Cloud-Projekt vorhanden sein, in dem Sie das SAP-System bereitstellen.

Bereitstellung von Laufwerken mit Terraform

Wenn Sie die Bereitstellung von SAP HANA mit der von Google Cloud bereitgestellten Terraform-Konfiguration automatisieren, erfolgt die Standardbereitstellung von Laufwerken so:

Laufwerk oder Verzeichnis	Für X4-Instanzen bereitgestelltes Standardlaufwerk	Für C3-Bare-Metal-Instanzen bereitgestelltes Standardlaufwerk	Für VM-Instanzen bereitgestelltes Standardlaufwerk
Boot-Volume	Hyperdisk Balanced	Hyperdisk Balanced	Abgestimmter nichtflüchtiger Speicher
/hana/data	Hyperdisk Extrem	Hyperdisk Balanced	Nichtflüchtiger SSD-Speicher
/hana/log	Hyperdisk Extrem	Hyperdisk Balanced	Nichtflüchtiger SSD-Speicher
/hana/shared	Hyperdisk Balanced	Hyperdisk Balanced	SSD-persistenter Datenträger, wenn Sie in der Terraform-Konfigurationsdatei disk_type = "pd-ssd" angeben. Abgestimmter nichtflüchtiger Speicher (in allen anderen Szenarien).
/hanabackup	Hyperdisk Balanced	Hyperdisk Balanced	Abgestimmter nichtflüchtiger Speicher
/usr/sap	Hyperdisk Balanced	Hyperdisk Balanced	SSD-persistenter Datenträger, wenn Sie in der Terraform-Konfigurationsdatei disk_type = "pd-ssd" angeben. Abgestimmter nichtflüchtiger Speicher (in allen anderen Szenarien).

Benutzerdefinierte VMs und automatisierte Bereitstellungen

Die Terraform-Konfigurationsdateien und Deployment Manager-Vorlagen unterstützen die Spezifikation benutzerdefinierter Compute Engine-VMs nicht.

Wenn Sie einen benutzerdefinierten VM-Typ verwenden müssen, stellen Sie zuerst einen kleinen vordefinierten VM-Typ bereit und passen Sie die VM nach der Bereitstellung entsprechend an.

Weitere Informationen zum Ändern von VMs finden Sie unter VM-Konfigurationen für SAP-Systeme ändern.

Bereitstellungsautomatisierung für Systeme mit vertikaler Skalierung

Google Cloud bietet Terraform-Konfigurationsdateien und Deployment Manager-Konfigurationsvorlagen, mit denen Sie die Bereitstellung von SAP HANA-Systemen mit einzelnem Host und vertikaler Skalierung automatisieren können.

Die Terraform- oder Deployment Manager-Skripts können für die folgenden Szenarien verwendet werden:

• Ein eigenständiges SAP-HANA-System mit vertikaler Skalierung.

  Weitere Informationen finden Sie in der Terraform-Bereitstellungsanleitung oder in der Deployment Manager-Bereitstellungsanleitung.

• Ein aktives und ein Standby-SAP HANA-System mit vertikaler Skalierung auf einem Linux-Hochverfügbarkeitscluster.

  Weitere Informationen finden Sie in der Terraform-Bereitstellungsanleitung oder in der Deployment Manager-Bereitstellungsanleitung.

Sie können über die Terraform- oder Deployment Manager-Skripts die VMs, nichtflüchtigen Speicher, SAP HANA und im Fall des Linux-Hochverfügbarkeitsclusters die erforderlichen Hochverfügbarkeitskomponenten bereitstellen.

Die folgenden Systemkomponenten werden nicht über Deployment Manager-Skripts bereitgestellt:

• Netzwerk und Subnetzwerk
• Firewallregeln
• NAT-Gateways, Bastion Hosts oder deren VMs
• SAP HANA Studio oder seine VM

Mit Ausnahme von SAP HANA Studio oder seiner VM können Sie Terraform für die Bereitstellung all dieser Systemkomponenten verwenden.

Informationen zum Erstellen dieser Komponenten finden Sie im Abschnitt „Voraussetzungen“ in den folgenden Anleitungen:

• Terraform: SAP HANA-Bereitstellungsanleitung für die vertikale Skalierung
• Deployment Manager: SAP HANA-Bereitstellungsanleitung für die vertikale Skalierung

Bereitstellungsautomatisierung für Systeme mit horizontaler Skalierung

Google Cloud bietet Terraform-Konfigurationsdateien und Deployment Manager-Konfigurationsvorlagen, mit denen Sie die Bereitstellung der SAP HANA-Systeme mit mehreren Hosts und horizontaler Skalierung automatisieren können.

• Informationen zum Bereitstellen eines Systems mit horizontaler Skalierung ohne automatisches Failover des SAP HANA-Hosts finden Sie unter Terraform: SAP HANA-Bereitstellungsanleitung oder Deployment Manager: SAP HANA-Bereitstellungsanleitung.
• Informationen zum Bereitstellen eines Systems mit horizontaler Skalierung ohne Standby-Hosts in einem Linux-Hochverfügbarkeitscluster finden Sie unter Terraform: Konfigurationsanleitung für SAP HANA-Hochverfügbarkeitscluster.
• Informationen zum Bereitstellen eines Systems mit horizontaler Skalierung und Standbyhosts finden Sie unterTerraform: Bereitstellungsanleitung für SAP HANA-Systeme zur horizontalen Skalierung mit automatischem Host-Failover oderDeployment Manager: Bereitstellungsanleitung für SAP HANA-Systeme zur horizontalen Skalierung mit automatischem Host-Failover.

Mit den Terraform-Konfigurationen oder Deployment Manager-Vorlagen können die VMs, nichtflüchtige Speicher und SAP HANA bereitgestellt werden. Außerdem können sie NFS-Einhängepunkte den gemeinsam genutzten und Sicherungsvolumes von SAP HANA zuordnen. Bei Bereitstellungen mit horizontaler Skalierung mit mehreren Hosts können mit der Terraform-Konfiguration oder der Deployment Manager-Vorlage auch neue Filestore-Instanzen bereitgestellt werden, um die freigegebenen und Sicherungsvolumes von SAP HANA zu hosten.

Die folgenden Systemkomponenten werden nicht über Deployment Manager-Skripts bereitgestellt:

• Netzwerk und Subnetzwerk
• Firewallregeln
• NAT-Gateways, Bastion Hosts oder deren VMs
• SAP HANA Studio oder seine VM

Mit Ausnahme von SAP HANA Studio oder seiner VM können Sie Terraform für die Bereitstellung all dieser Systemkomponenten verwenden.

Dateifreigabelösungen für Bereitstellungen mit mehreren Hosts und horizontaler Skalierung

Die von Google Cloud für die SAP-HA-Bereitstellung mit mehreren Hosts und horizontaler Skalierung bereitgestellte Terraform-Konfiguration erstellt standardmäßig NFS-Exporte für die Volumes /hana/shared und /hanabackup auf der primären SAP HANA-VM-Instanz und gibt die Volumes für die Worker-Knoten frei.

Wenn Sie jedoch eine NFS-Lösung zum Freigeben der Volumes /hana/shared und /hanabackup für Ihre Worker-Hosts verwenden möchten, haben Sie folgende Möglichkeiten:

• Zum Verknüpfen einer vorhandenen NFS-Lösung, die Sie in Google Cloud bereitgestellt haben, müssen Sie die NFS-Bereitstellungspunkte der Volumes /hana/shared und /hanabackup für sap_hana_shared_nfs- und sap_hana_backup_nfs-Argumente in der Terraform-Konfigurationsdatei angeben.

• Wenn Sie neue Filestore-Instanzen bereitstellen und ihre Dateifreigaben mit den Volumes /hana/shared und /hanabackup verknüpfen möchten, müssen Sie eine google_filestore_instance-Ressource definieren und dann die Namen der Dateifreigaben für die Argumente sap_hana_shared_nfs_resource und sap_hana_backup_nfs_resource für die Terraform-Konfigurationsdatei angeben.

Ein Beispiel finden Sie in der Beispielkonfiguration.

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:

• Support für SAP in Google Cloud
• SAP-Hinweis 2456406 – SAP auf der Google Cloud Platform: Support-Voraussetzungen (SAP-Nutzerkonto erforderlich)

Nächste Schritte

• Unter SAP HANA Dynamic Tiering finden Sie weitere Informationen von SAP zum dynamischen Tiering von SAP HANA.