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

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:

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üchtiger Compute Engine-Speicher, Hyperdisk Extreme, Hyperdisk Balanced oder, nur zur vertikalen Skalierung, NetApp CVS-Performance.
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
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.

Abhängig von Ihren Anforderungen können Sie die Sicherheit auf verschiedene Arten verbessern, wie im SAP HANA-Sicherheitsleitfaden für die SAP HANA Platform 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 im Rahmen Ihres Netzwerkdesigns und weisen Sie beim Bereitstellen von VMs zusätzliche NICs zu. 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 können. 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 VM-Netzwerkbandbreite.

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

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:

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 über SSH eine 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 folgender 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.

Layoutoptionen für Laufwerksspeicher 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 und 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:

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

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

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.

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.

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 und SAP für Ihre Bereitstellungen empfehlen, um sowohl Leistung als auch Gesamtbetriebskosten auszugleichen. Laufwerksgrößen können bis zum Limit erhöht werden, 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 Loglaufwerk: maximum(10,000, size of log disk in GB * 2)
  • Wenn für /hana/data, /hana/log, /hana/shared und /usr/sap ein einzelnes Laufwerk 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 die Backint-Funktion 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:

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:

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-Dienstes für Google Cloud mit Ihrer SAP HANA-Bereitstellung finden Sie unter Informationen zum 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.

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

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

Die folgende Tabelle zeigt eine kostenoptimierte Speicherkonfiguration zum Ausführen von SAP HANA auf X4-Maschinentypen. 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

Die folgende Tabelle zeigt eine leistungsoptimierte Speicherkonfiguration zum Ausführen von SAP HANA auf X4-Maschinentypen. 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

Die folgende Tabelle zeigt eine Speicherkonfiguration, die eine flexible Leistung zum Ausführen 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 mit den von Google Cloud bereitgestellten Terraform-Konfigurationen bereitstellen. Diese Konfigurationen sind für folgende Aufgaben gedacht:

  • Stellen Sie Hyperdisk Extreme-Volumes bereit, um die SAP HANA-Daten- und -Log-Volumes zu hosten. Verwenden Sie stattdessen das Terraform-Argument disk_type, um Hyperdisk Balanced-Volumes bereitzustellen.
  • Aktivieren Sie die Option Fast Restart SAP HANA.
  • Wenn Sie das SAP HANA-Sicherungs-Volume auf einem Laufwerk hosten, stellen diese Terraform-Konfigurationen standardmäßig ein Hyperdisk Balanced-Volume bereit. Diese Laufwerksbereitstellung 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:

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.

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

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.

Architekturdiagramm für die Bereitstellung eines SAP HANA-Systems mit vertikaler Skalierung in Google Cloud.

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 Persistent Disk- oder Hyperdisk-Volumes von Compute Engine:

    • Ein Laufwerk für jedes der folgenden Verzeichnisse: /hana/data, /hana/log, /hana/shared und /usr/sap. Informationen zu Laufwerksempfehlungen 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 mithilfe der folgenden Optionen eine indirekte Methode für den Internetzugriff 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.

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

Architekturdiagramm für die Bereitstellung eines SAP HANA-Systems mit horizontaler Skalierung 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.

Architekturdiagramm für die Bereitstellung eines SAP HANA-Systems mit horizontaler Skalierung in Google Cloud mit automatischem Host-Failover.

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. Dieser NFS-Master wird auf jedem Worker- und Standbyhost bereitgestellt.

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 Standort bereitgestellt ist.
    • Wenn Sie kein System für das automatisches Failover des SAP HANA-Hosts bereitstellen, kann optional ein Laufwerk für das lokale Volume /hanabackup für jede VM-Instanz verwendet 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 mithilfe der folgenden Optionen eine indirekte Methode für den Internetzugriff 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:

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.

Laufwerksbereitstellung mit Terraform

Wenn Sie die Bereitstellung von SAP HANA mithilfe der von Google Cloud bereitgestellten Terraform-Konfiguration automatisieren, sieht die Standardbereitstellung des Laufwerks so aus:

Volume 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
  • Nichtflüchtiger SSD-Speicher, wenn Sie in Ihrer 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
  • Nichtflüchtiger SSD-Speicher, wenn Sie in Ihrer 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 Bereitstellungsanleitung für Terraform oder Deployment Manager.

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

    Weitere Informationen finden Sie in der Bereitstellungsanleitung für Terraform oder Deployment Manager.

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:

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.

Mit den Terraform-Konfigurationen oder Deployment Manager-Vorlagen können die VMs, nichtflüchtige Speicher und SAP HANA bereitgestellt werden. Sie können auch NFS-Bereitstellungspunkte den freigegebenen SAP HANA-Volumes und den Sicherungs-Volumes zuordnen. Bei Bereitstellungen mit mehreren Hosts und horizontaler Skalierung kann die Terraform-Konfiguration oder Deployment Manager-Vorlage auch neue Filestore-Instanzen bereitstellen, um die freigegebenen SAP HANA-Volumes und die Sicherungs-Volumes 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 zur Freigabe der Volumes /hana/shared und /hanabackup für Ihre Worker-Hosts verwenden möchten, können Sie eine der folgenden Optionen verwenden:

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

Nächste Schritte