Dieser Leitfaden bietet einen Überblick darüber, was für die Ausführung von SAP HANA in Google Cloud erforderlich ist, und enthält nützliche Details für die Planung der Implementierung eines neuen SAP HANA-Systems.
Weitere Informationen zum Bereitstellen von SAP HANA in Google Cloud finden Sie unter:
- Informationen zur Bereitstellung einzelner Hosts mit vertikaler Skalierung sowie mehrerer Hosts mit horizontaler Skalierung finden Sie unter:
- Informationen zu Systemen mit horizontaler Skalierung und automatischem Host-Failover finden Sie unter:
- Informationen zu Konfigurationen von Hochverfügbarkeitsclustern mit vertikaler Skalierung finden Sie unter:
- Terraform: Konfigurationsleitfaden für SAP HANA-Hochverfügbarkeitscluster mit vertikaler Skalierung
- Deployment Manager: Konfigurationsanleitung für SAP HANA-Hochverfügbarkeitscluster
- Manuelle Konfiguration eines vertikal skalierbaren HA-Clusters in RHEL
- Manuelle Konfiguration eines vertikal skalierbaren HA-Clusters in SLES
- Informationen zu Konfigurationen von Hochverfügbarkeitsclustern mit horizontaler Skalierung finden Sie unter:
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:
|
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:
- 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.
- Erstellen und komprimieren Sie die Image-Datei des Bootlaufwerks.
- Laden Sie die Image-Datei in Cloud Storage hoch und importieren Sie das Image als neues benutzerdefiniertes Image in Compute Engine.
- Erstellen Sie mithilfe des importierten Images eine VM-Instanz und überprüfen Sie, ob sie ordnungsgemäß gestartet werden kann.
- Optimieren Sie das Image und installieren Sie die Linux-Gastumgebung, damit das importierte Betriebssystem-Image mit dem Metadatenserver kommunizieren und weitere Compute Engine-Features verwenden kann.
Sobald Ihr benutzerdefiniertes Image bereit ist, können Sie es beim Erstellen von VMs für Ihr SAP HANA-System verwenden.
Wenn Sie ein RHEL-Betriebssystem von einer lokalen Installation auf Google Cloud verschieben, müssen Sie Ihrem Red Hat-Abo Red Hat Cloud Access hinzufügen. Weitere Informationen finden Sie unter Red Hat Cloud Access.
Weitere Informationen zu den von Google Cloud bereitgestellten Betriebssystem-Imagesfinden Sie unter Images.
Weitere Informationen zum Importieren eines Betriebssystems in Google Cloud als benutzerdefiniertes Image finden Sie unter Bootlaufwerk-Images in Compute Engine importieren.
Weitere Informationen zu den von SAP HANA unterstützten Betriebssystemen finden Sie in folgenden Artikeln:
- Verzeichnis für zertifizierte und unterstützte SAP HANA-Hardware
- SAP-Hinweis 2235581 – SAP HANA: Unterstützte Betriebssysteme
Betriebssystem-Taktquelle auf Compute Engine-VMs
Die standardmäßige Taktquelle des Betriebssystems ist kvm-clock für SLES und TSC für RHEL-Images.
Das Ändern der Betriebssystem-Taktquelle ist nicht erforderlich, wenn SAP HANA auf einer Compute Engine-VM ausgeführt wird. Es gibt keinen Unterschied in der Leistung bei Verwendung von kvm-clock oder TSC als Taktquelle für Compute Engine VMs mit SAP HANA.
Wenn Sie die Betriebssystem-Taktquelle auf TSC ändern müssen, stellen Sie ü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.
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:
- Speicheroptionen
- Informationen zu Hyperdisk
- Blockspeicherleistung
- Andere Faktoren, die sich auf die Leistung auswirken
- Nichtflüchtigen Speicher zu VM hinzufügen
- Laufwerk-Snapshots erstellen und verwalten
- Vorhandene SAP HANA Persistent Disk-Volumes zu Hyperdisk Extreme-Volumes migrieren
Mindestgrößen für SSD-basierte Persistent Disk- und Hyperdisk-Volumes
Wenn Sie die Größe bestimmter Compute Engine-SSD-basierter nichtflüchtiger Speicher für SAP HANA festlegen, müssen Sie nicht nur die Speicheranforderungen Ihrer SAP HANA-Instanz, sondern auch die Leistung des nichtflüchtigen Speichers berücksichtigen.
Innerhalb der Limits steigt die Leistung eines SSD- oder abgestimmten nichtflüchtigen Speichers, wenn die Größe des Laufwerks und die Anzahl der vCPUs zunimmt. Wenn ein SSD- oder abgestimmter nichtflüchtiger Speicher zu klein ist, bietet er möglicherweise nicht die von SAP HANA benötigte Leistung.
Die Leistung von Hyperdisk wird von der Laufwerksgröße nicht beeinflusst. Die Leistung wird durch die bereitgestellten IOPS oder den bereitgestellten Durchsatz bestimmt. Informationen zur Leistung von Hyperdisk finden Sie unter Informationen zu Hyperdisks.
Ein SSD-Speicher mit 550 GB oder ein abgestimmter nichtflüchtiger Speicher mit 943 GB bietet einen kontinuierlichen Durchsatz von 400 MB pro Sekunde für Lese- und Schreibvorgänge. Dies ist das Minimum. Allgemeine Informationen zur Leistung nichtflüchtiger Speicher finden Sie unter Blockspeicherleistung.
In der folgenden Tabelle sind die empfohlenen Größen für nichtflüchtige SSD-Speicher (pd-ssd
), abgestimmte nichtflüchtige Speicher (pd-balanced
) und Hyperdisk Extrem (hyperdisk-extreme
) und Hyperdisk Balanced (hyperdisk-balanced
) aufgeführt, um die Leistungsanforderungen von SAP HANA in einer Produktionsumgebung für jeden Compute Engine-Maschinentyp zu erfüllen, der für SAP HANA zertifiziert ist. Die Mindestgrößen für Hyperdisk, die ausschließlich auf der Größe des Arbeitsspeichers basieren, sind in der Tabelle als Referenz angegeben.
Informationen zur empfohlenen Speicherkonfiguration für SAP HANA-Systeme, die auf X4-Instanzen ausgeführt werden, finden Sie unter Unterstützter Blockspeicher für X4.
Bei den Größen in der folgenden Tabelle wird davon ausgegangen, dass Sie alle SAP HANA-Volumes auf einzelnen Laufwerken bereitstellen.
Abgestimmter nichtflüchtiger Speicher
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 Wertnum_completion_queues = 12
fest. - Legen Sie im Abschnitt
fileio
den Wertnum_submit_queues = 12
fest.
- Legen Sie im Abschnitt
- Aktualisieren Sie Ihre
indexserver.ini
-Datei:- Legen Sie im Abschnitt
parallel
den Werttables_preloaded_in_parallel = 32
fest. - Legen Sie im Abschnitt
global
den Wertload_table_numa_aware = true
fest.
- Legen Sie im Abschnitt
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)
- IOPS für das Datenlaufwerk:
- 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)
- IOPS für Laufwerk:
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:
- SAP-Hinweis 2292690 – SAP HANA-DB: Empfohlene Betriebssystemeinstellungen für RHEL 7
- SAP-Hinweis 2777782 – SAP HANA-DB: Empfohlene Betriebssystemeinstellungen für RHEL 8
- SAP-Hinweis 3108302 – SAP HANA-DB: Empfohlene Betriebssystemeinstellungen für RHEL 9
Wenn Sie SLES verwenden, wenden Sie die erforderliche Konfiguration mit dem saptune
-Tool von SUSE an. Geben Sie folgenden saptune
-Befehl an, um alle empfohlenen SAP HANA-Einstellungen anzuwenden, einschließlich der beiden vorherigen Kernelparameter:
saptune solution apply HANA
Weitere Informationen zum Konfigurieren von SLES für SAP HANA finden Sie unter:
- SAP-Hinweis 2205917 – SAP HANA-DB: Empfohlene Betriebssystemeinstellungen für SLES 12 / SLES for SAP Applications 12
- SAP-Hinweis 2684254 – SAP HANA-DB: Empfohlene Betriebssystemeinstellungen für SLES 15 / SLES for SAP Applications 15
Wiederherstellung von Speicherfehlern mit Fast Restart auf Compute Engine-VMs
Das Aktivieren von SAP HANA Fast Restart auf VMs in den Familien M2 und M3 von speicheroptimierten Maschinentypen führt zu einer Reduzierung der Zeit, die SAP HANA zur Wiederherstellung nach nicht korrigierbaren Speicherfehlern benötigt.
Durch die Nutzung von Intel-Prozessorfunktionen können die M2/M3-Maschinentypen auch dann weiter ausgeführt werden, wenn im Speichersubsystem nicht korrigierbare Fehler auftreten. Ist SAP HANA Fast Restart beim Auftreten des Speicherfehlers aktiviert, so wird der betroffene SAP HANA-Prozess neu gestartet, aber es muss nicht die gesamte Datenbank neu geladen werden, sondern nur den betroffenen Dateiblock.
Maschinentypen, die die Wiederherstellung nach Speicherfehlern unterstützen
Die Wiederherstellung nach Speicherfehlern von folgenden Compute Engine-Maschinentypen wird nicht unterstützt:
m3-ultramem-32
m3-ultramem-64
m3-ultramem-128
m3-megamem-64
m3-megamem-128
m2-ultramem-208
m2-ultramem-416
m2-megamem-416
m2-hypermem-416
Erforderliche Betriebssysteme für die Wiederherstellung nach Speicherfehlern
Mit den erforderlichen Kernel-Patches unterstützen die folgenden Betriebssysteme die Wiederherstellung von Speicherfehlern mit SAP HANA Fast Restart:
- SUSE Linux Enterprise Server (SLES) für SAP, 12 SP3 oder höher
- Ist in öffentlichen Compute Engine-Images mit dem Build-Datum v202103* oder höher enthalten.
- Wenn Sie die neuesten Kernel-Patches auf eine vorhandene Bereitstellung anwenden müssen, folgen Sie dem Standardaktualisierungsprozess. Führen Sie beispielsweise die folgenden Befehle aus:
- sudo zypper refresh
- sudo zypper update
- Red Hat Enterprise Linux (RHEL) für SAP 8.4 oder höher
Dateiserveroptionen
Die Dateiserveroptionen für SAP HANA in Google Cloud umfassen Filestore und NetApp Cloud Volumes-Dienst für Google Cloud.
Weitere Informationen zu allen Dateiserveroptionen für SAP in Google Cloud finden Sie unter Dateifreigabelösungen für SAP in Google Cloud.
Filestore
Für das Volume /hana/shared
in einer Konfiguration mit horizontaler Skalierung und einzelner Zone empfehlen wir die Verwendung der Dienststufe Filestore Basic, die für zonale Ressourcen bestimmt ist. Für Szenarien, in denen zusätzliche Ausfallsicherheit erforderlich ist, können Sie Filestore Enterprise verwenden. Weitere Informationen finden Sie unter Komponenten in einem SAP HANA-System mit horizontaler Skalierung in Google Cloud.
NetApp Cloud Volumes-Dienst für Google Cloud
NetApp Cloud Volumes-Dienst für Google Cloud ist eine vollständig verwaltete, cloudnative Datendienstplattform, mit der Sie ein NFS-Dateisystem für SAP HANA-Systeme mit vertikaler Skalierung auf allen Compute Engine-Instanztypen erstellen können, die für SAP HANA zertifiziert sind. Informationen zur Verwendung des NetApp Cloud Volumes-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.
- Informationen zu den C3-Bare-Metal-Maschinentypen, die von SAP für die Verwendung mit SAP HANA zertifiziert sind, finden Sie unter C3-Bare-Metal-Maschinentypen für allgemeine Zwecke.
- Informationen zu den Betriebssystemversionen, die Sie mit den C3-Bare-Metal-Maschinentypen für die Ausführung von SAP HANA-Arbeitslasten verwenden können, finden Sie unter Zertifizierte Betriebssysteme für SAP HANA.
- Informationen zum erforderlichen Mindestblockspeicher für die Ausführung von SAP HANA auf C3-Bare-Metal-Maschinentypen finden Sie unter Mindestgrößen für SSD-basierte Persistent Disk- und Hyperdisk-Volumes.
- Weitere Informationen zur C3-Maschinenserie finden Sie unter C3-Maschinenserie.
X4: Die vierte Generation speicheroptimierter Maschinentypen, die von der Compute Engine angeboten wird. Diese Maschinen wurden hauptsächlich für SAP-Arbeitslasten entwickelt, die bis zu 32 TB Arbeitsspeicher benötigen.
- Informationen zu den X4-Maschinentypen, die von SAP für die Verwendung mit SAP HANA zertifiziert sind, finden Sie unter Speicheroptimierte Bare Metal X4-Maschinentypen.
- Informationen zu den Betriebssystemversionen, die Sie mit den X4-Maschinentypen für die Ausführung von SAP HANA-Arbeitslasten verwenden können, finden Sie unter Zertifizierte Betriebssysteme für SAP HANA.
- Informationen zum unterstützten Blockspeicher für die Ausführung von SAP HANA auf X4-Maschinentypen finden Sie unter Unterstützter Blockspeicher für X4.
- Weitere Informationen zur X4-Maschinenreihe finden Sie unter X4-Maschinenreihe.
Unterstützter Blockspeicher für X4
Sie können Hyperdisk Extreme- oder Hyperdisk Balanced-Volumes verwenden, um Blockspeicher für die Ausführung von SAP HANA-Arbeitslasten auf X4-Maschinen bereitzustellen.
Informationen zu den von Google Cloud für X4-Instanzen empfohlenen Speicherkonfigurationen finden Sie in den folgenden Abschnitten:
- Kostenoptimierte Konfiguration
- Konfiguration zur Leistungsoptimierung
- Flexible Leistungskonfiguration
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:
- Prüfen Sie, ob Version 3.5 (aktuell) des Google Cloud-Agents für SAP installiert ist. Informationen zum Installieren des Agents finden Sie unter Google Cloud-Agent für SAP auf einer Compute Engine-Instanz installieren und konfigurieren. Informationen zum Aktualisieren auf die neueste Version finden Sie unter Google Cloud-Agent für SAP aktualisieren.
- Optimieren Sie die Betriebssystemkonfiguration auf X4-Instanzen, um SAP HANA-Arbeitslasten optimal zu unterstützen. Verwenden Sie dazu den Google Cloud-Agent für SAP. Weitere Informationen finden Sie unter Gastbetriebssystem auf Bare-Metal-Instanzen konfigurieren.
- SAP-Arbeitslast mit Workload Manager bewerten, einem regelbasierten Validierungsdienst, mit dem Sie Ihre Arbeitslasten scannen und Abweichungen von Standards, Regeln und Best Practices erkennen können, die von SAP, Google Cloud und Betriebssystemanbietern vorgegeben werden. Informationen zum Evaluieren Ihrer SAP-Arbeitslast finden Sie unter Evaluierung erstellen und ausführen. Informationen zu den unterstützten Bewertungen für SAP-Arbeitslasten finden Sie unter Best Practices von Workload Manager für SAP.
Hyperthreading
Hyperthreading ist standardmäßig aktiviert und die empfohlene Einstellung für alle Compute Engine-Maschinentypen.
Für eine optimale Leistung von SAP HANA auf Compute-Instanzen mit mehr als 1.000 vCPUs empfehlen wir dringend die Verwendung von SAP HANA 2.0 SPS7 Version 76 oder höher.
Wenn Sie eine ältere Version von SAP HANA mit einer OLTP-Arbeitslast auf Compute-Instanzen mit mehr als 1.000 vCPUs ausführen, kann das Deaktivieren des Hyperthreadings zu einem geringfügigen Leistungsvorteil führen. Wir empfehlen, dies während eines Lasttests zu testen. Informationen zum Deaktivieren des Hyperthreadings für Ihre X4-Instanz mit dem Google Cloud-Agent für SAP finden Sie unter Hyperthreading für eine X4-Instanz deaktivieren.
Überlegungen zu Preisen und Kontingenten für SAP HANA
Sie sind für die Kosten verantwortlich, die durch die Verwendung der Ressourcen entstehen, die durch das Befolgen dieser Bereitstellungsanleitung erstellt wurden. Verwenden Sie den Preisrechner, um Ihre tatsächlichen Kosten abzuschätzen.
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.
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:
Standbyhosts unterstützen die Fehlerwiederherstellungslösung mit automatischem Failover für den SAP HANA-Host. Weitere Informationen zum automatischen Host-Failover in Google Cloud finden Sie unter Automatischer SAP HANA-Host-Failover in Google Cloud.
Folgendes Diagramm zeigt eine horizontal skalierende Architektur mit automatischem Host-Failover in Google Cloud.
Laufwerksstrukturen für SAP HANA-Systeme mit horizontaler Skalierung in Google Cloud
Mit Ausnahme von Standbyhosts hat jeder Host eigene /hana/data
-, /hana/log
- und normalerweise /usr/sap
-Volumes auf SSD-basierten nichtflüchtigen Speichern oder Hyperdisks, die konsistente E/A-Dienste mit hohen IOPS bereitstellen. Der Masterhost dient auch als NFS-Master für die Volumes /hana/shared
und /hanabackup
. 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:
- Bereitstellungsautomatisierung für Systeme mit vertikaler Skalierung
- Bereitstellungsautomatisierung für Systeme mit horizontaler Skalierung
Bereitstellung der SAP HANA-Instanz automatisieren
Optional können Sie die Installation von SAP HANA in die automatisierte Bereitstellung der Google Cloud-Infrastruktur einbeziehen.
Die von Google Cloud bereitgestellten Installationsskripte installieren SAP HANA nach der Bereitstellung der Infrastruktur.
Wenn Probleme die Installation einer SAP HANA-Instanz verhindern, wird die Infrastruktur normalerweise noch bereitgestellt und konfiguriert. Sie können dann die bereitgestellte Infrastruktur verwenden und SAP HANA manuell installieren oder die Infrastruktur löschen, das Problem beheben und die Bereitstellungsautomatisierung noch einmal ausführen, bis die SAP HANA-Instanz erfolgreich installiert ist.
Wenn Sie die Installationsskripts verwenden, die Google Cloud zur Installation von SAP HANA verwendet, müssen Sie Werte für bestimmte Parameter angeben. Wenn Sie diese Parameter weglassen oder keine gültigen Werte für alle angeben, kann das Installationsskript die SAP HANA-Instanz nicht auf der bereitgestellten Infrastruktur installieren.
Wenn Sie die von Google Cloud bereitgestellten Terraform-Konfigurationsdateien zum Installieren von SAP HANA verwenden, müssen Sie für die folgenden Argumente gültige Werte angeben:
sap_hana_deployment_bucket
,sap_hana_sid
,sap_hana_sidadm_uid
.sap_hana_sidadm_password
undsap_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
undsap_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
undsap_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
undsap_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 |
|
/hanabackup |
Hyperdisk Balanced | Hyperdisk Balanced | Abgestimmter nichtflüchtiger Speicher |
/usr/sap |
Hyperdisk Balanced | Hyperdisk Balanced |
|
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:
- Terraform: SAP HANA-Bereitstellungsanleitung für die vertikale Skalierung
- Deployment Manager: SAP HANA-Bereitstellungsanleitung für die vertikale Skalierung
Bereitstellungsautomatisierung für Systeme mit horizontaler Skalierung
Google Cloud bietet Terraform-Konfigurationsdateien und Deployment Manager-Konfigurationsvorlagen, mit denen Sie die Bereitstellung der SAP HANA-Systeme mit mehreren Hosts und horizontaler Skalierung automatisieren können.
- Informationen zum Bereitstellen eines Systems mit horizontaler Skalierung ohne automatisches Failover des SAP HANA-Hosts finden Sie unter Terraform: SAP HANA-Bereitstellungsanleitung oder Deployment Manager: SAP HANA-Bereitstellungsanleitung.
- Informationen zum Bereitstellen eines Systems mit horizontaler Skalierung ohne Standby-Hosts in einem Linux-Hochverfügbarkeitscluster finden Sie unter Terraform: Konfigurationsanleitung für SAP HANA-Hochverfügbarkeitscluster.
- Informationen zum Bereitstellen eines Systems mit horizontaler Skalierung und Standbyhosts finden Sie unterTerraform: Bereitstellungsanleitung für SAP HANA-Systeme zur horizontalen Skalierung mit automatischem Host-Failover oderDeployment Manager: Bereitstellungsanleitung für SAP HANA-Systeme zur horizontalen Skalierung mit automatischem Host-Failover.
Mit den Terraform-Konfigurationen oder Deployment Manager-Vorlagen können die VMs, nichtflüchtige Speicher und SAP HANA bereitgestellt werden. 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ürsap_hana_shared_nfs
- undsap_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 einegoogle_filestore_instance
-Ressource definieren und dann die Namen der Dateifreigaben für die Argumentesap_hana_shared_nfs_resource
undsap_hana_backup_nfs_resource
für die Terraform-Konfigurationsdatei angeben.
Ein Beispiel finden Sie in der Beispielkonfiguration.
Support
Wenden Sie sich bei Problemen mit der Infrastruktur oder den Diensten von Google Cloud an Customer Care. Kontaktdaten finden Sie in der Google Cloud Console auf der Seite Supportübersicht. Wenn Customer Care feststellt, dass sich um ein Problem Ihres SAP-Systems handelt, werden Sie an den SAP-Support verwiesen.
Reichen Sie bei Problemen in Zusammenhang mit SAP-Produkten Ihre Supportanfrage beim SAP-Support ein.
SAP wertet das Support-Ticket aus und leitet es, wenn es sich um ein Problem mit der Google Cloud-Infrastruktur handelt, gegebenenfalls an die entsprechende Google Cloud-Komponente in seinem System weiter: BC-OP-LNX-GOOGLE
oder BC-OP-NT-GOOGLE
.
Supportanforderungen
Bevor Sie Support für SAP-Systeme sowie für die Infrastruktur und Dienste von Google Cloud erhalten können, müssen Sie die Mindestanforderungen für den Supportplan erfüllen.
Weitere Informationen zu den Mindestsupportanforderungen für SAP in Google Cloud finden Sie hier:
- Support für SAP in Google Cloud
- SAP-Hinweis 2456406 – SAP auf der Google Cloud Platform: Support-Voraussetzungen (SAP-Nutzerkonto erforderlich)
Nächste Schritte
- Unter SAP HANA Dynamic Tiering finden Sie weitere Informationen von SAP zum dynamischen Tiering von SAP HANA.