IBM Cloud Docs
Hinweise zum Speicherdesign

Hinweise zum Speicherdesign

Die SAP-Systeme in einer Umgebung stellen spezifische Anforderungen an Server, Betriebssysteme, Netzkonfiguration und unterstützten Speicher.

Für SAP-Workloads, die einen Cloud-Service-Provider nutzen, hat Infrastructure as a Service Ähnlichkeit mit den bestehenden Verfahren, die zur Ausführung von SAP-Workloads in externen Rechenzentren oder durch einen Rechenzentrumsprovider verwendet werden. Eine SAP-Umgebung hat bestimmte Anforderungen an die Konnektivität zwischen Hosts in Cloud IaaS und externen Systemen. IBM Cloud® for SAP stellt eine Vielzahl von Funktionen bereit, um Ihre SAP-Umgebung über das Hosting von SAP-Systemen hinaus zu verbessern.

Die folgenden Abschnitte enthalten Hinweise zum Design des IBM Cloud® for SAP-Portfolios für Speicher und unterstützen Sie in der Planungsphase Ihres Projekts.

Vorbemerkungen - Maßeinheiten für Daten/Informationen

Die Speicherleistung bezieht sich auf die Leistung bei Lese-/Schreibvorgängen für das Speicherdateisystem. Der Durchsatz wird für den Netzspeicher häufig in Mb/s oder Gb/s angegeben, für den lokalen Plattenspeicher hingegen in MiB/s.

Dabei ist zu beachten, dass Mb (Megabit) ein Dezimalpräfix darstellt, MiB (Mebibyte) dagegen ein Binärpräfix. Diese Einheiten sind somit in verschiedenen Größenordnungen angesiedelt. Noch verwirrender wird es angesichts der Tatsache, dass für MiB (Mebibyte) in Microsoft Windows allgemein die Langform Megabyte verwendet wurde.

Bei Verweisen in der Speicherdokumentation werden Mb (Megabit) und MiB (Mebibyte) künftig gemäß dem Einheitensystem (SI) verwendet, das von IEC definiert wurde und von IEEE, ISO und NIST übernommen worden ist.

Beispiel:

  • 100 Mb/s (Megabit pro Sekunde) entsprechen 12 MiB/s (Mebibyte pro Sekunde)
  • 1000 Mb/s (Megabit pro Sekunde), auch als 1 Gb/s (Gigabit pro Sekunde) bezeichnet, entsprechen 120 MiB/s (Mebibyte pro Sekunde)
  • 10 Gb/s (Gigabit pro Sekunde) entsprechen 1200 MiB/s (Mebibyte pro Sekunde)

Speicherkonfiguration für SAP HANA

Bei jedem für SAP HANA zertifizierten und als Appliance aufgelisteten Profil ist der Speicher bereits eingerichtet oder muss exakt wie beschrieben angehängt werden.

Wenn Sie für eine SAP HANA-Instanz zusätzlichen Speicher einrichten, müssen Sie obligatorische TDI-Speicheranforderungen beachten. Siehe SAP HANA TDI Overview, SAP HANA TDI FAQ, SAP Note 2493172 - SAP HANA Hardware and Cloud Measurement Tools, und befolgen Sie die Anweisungen des HCMT-Leitfadens. Weitere Hinweise finden Sie hier.

Weitere Informationen für IBM Power Virtual Server finden Sie unter IBM System Storage Architecture and Configuration Guide für SAP HANA TDI v2.31.pdf.

Zu den Anforderungen gehören mehrere Datenträger, die den LVM-Instanzen für Daten und Protokolle zugeordnet sind und durch das einheitenübergreifende Lesen und Schreiben von Daten (Striping) und Multipath-Erweiterungen die Leistung bei der Ein-/Ausgabe erhöhen. Weitere Informationen finden Sie in den folgenden Dokumenten:

Hinweise zur Speicherleistung

Bevor Sie sich für eine Speicherlösung entscheiden, müssen Sie unbedingt Ihre Projektanforderungen berechnen. Diese Berechnung ist für die Auswahl des Netzspeichers aufgrund von Speichervariationen und Leistungserwägungen von entscheidender Bedeutung.

Einfluss des Speichers auf RTO (Recovery Time Objective, Zielsetzung für Wiederherstellungszeit) von SAP HANA-Sicherungen

Wenn Sie ein SAP HANA-System wiederherstellen müssen, wird Ihr Wiederherstellungsfenster maßgeblich durch die Rate der E/A-Operationen pro Sekunde beeinflusst. Sicherungsfenster sind bei SAP HANA weniger kritisch, da ungeachtet der Konfiguration von SAP HANA alle Sicherungen stets als Onlinesicherungen ausgeführt werden.

Bei Verwendung von IBM Cloud Block Storage for Classic können Sie beispielsweise für eine Wiederherstellung von SAP HANA in einer Größe von ungefähr 12 TB mit maximaler Geschwindigkeit rechnen. Sie müssen drei physische Speichereinheiten (iSCSI-Blockspeicher-LUNs) erstellen, da die maximale Größe pro Einheit 4 TB beträgt. Mit Linux® Logical Volume Manager können Sie eine Konfiguration für einheitenübergreifendes Lesen und Schreiben für diese drei Einheiten erstellen und 1 logische Einheit mit 12 TB erstellen.

Die 12 TB stellen 3 x 10 IOPS/GB zur Verfügung, also insgesamt 122.880 IOPS/GB bei 16 KB. Diese Menge ergibt für Sie eine Wiederherstellungszeit von 1,875 GB pro Sekunde bzw. eine Gesamtwiederherstellungszeit von unter 2 Stunden. Da die Messung der E/A-Operationen pro Sekunde (IOPS) mit einer 50:50-Verteilung auf Lese- und Schreibvorgänge erfolgt, können Sie die Werte als Untergrenze für die Wiederherstellungsleistung betrachten. Falls Sie von einem bestimmten Wiederherstellungsfenster abhängig sind, empfiehlt es sich, Sicherungs- und Wiederherstellungstests durchzuführen.

Hinweise zum Netzblockspeicher

Die folgenden Abschnitte enthalten Hinweise zum Speicher bei der Verwendung von Netzblockspeicher für SAP-Workloadszenarios, die verschiedene Optionen der IBM Cloud-Infrastruktur nutzen.

Netzblock- oder Dateispeicher für VMware bei Classic Infrastructure

Die Verwendung von VMware für SAP-Workloads unter IBM Cloud ist zertifiziert. Sie macht jedoch die Auswahl des Speichers erforderlich und nutzt das TDI-Übermittlungsmodell, für das Sie Validierungsprüfungen durchführen müssen, um Support von SAP zu erhalten. Sie müssen daher unbedingt den richtigen Speicher für Ihre VMware-Hosts beachten, wenn diese Hosts SAP-Workloads ausführen.

Bei VMware-Clustern, in denen SAP-Workloads auf mehreren VMware vSphere-Hypervisorknoten ausgeführt werden, muss Speicher auf diesen Hypervisorknoten gemeinsam genutzt werden.

VMware ist für die Arbeit mit Blockspeicher oder Dateispeicher aus IBM Cloud verfügbar. Um Ihnen bei der Auswahl von Block- oder Dateispeichern für die Ausführung von SAP auf VMware zu helfen, lesen Sie bitte das technische Papier VMware zum Vergleich von Speicherprotokollen.

Bei Verwendung von Netzblock- oder Dateispeicher dürfen Sie nicht erwarten, dass die Leistungsbenchmarks der Zertifizierung gleich bleiben. Dies gilt insbesondere nach einem Factoring im Hypervisoraufwand, das im Abschnitt Datenverarbeitungsprofile - von SAP-zertifizierte VMware in Classic Infrastructure beschrieben ist.

Für VMware-Datenspeicher (auf denen sich die virtuellen VMDK-Platten der virtuellen Maschine befinden) gelten die folgenden Empfehlungen:

  • Verwenden Sie für SAP HANA lokale SDD-Platten für den Datenspeicher in einer RAID10-Konfiguration.
  • Verwenden Sie für SAP HANA mit Netzspeicher 10 IOPS/GB bei jedem vSphere-Knoten, der SAP hostet und eine Netzschnittstellenkarte mit einer 10-Gb/s-Verbindung verwendet.
  • Verwenden Sie für SAP NetWeaver oder SAP AnyDB mit Netzspeicher mindestens 4 IOPS/GB bei jedem vSphere-Knoten, der SAP hostet und eine Netzschnittstellenkarte mit 10-Gb/s-Verbindung verwendet.

Zur Erzielung des Maximums von E/A-Operationen pro Sekunde (IOPS) auf einem Datenträger müssen adäquate Netzressourcen vorhanden sein. Weitere Gesichtspunkte sind unter anderem die Nutzung des privaten Netzes außerhalb der Speicher- und Hostseite sowie anwendungsspezifische Optimierungen (z. B. IP-Stacks und Warteschlangenlängen). Zusätzliche Informationen zu Speichertiers und Leistung erhalten Sie unter Einführung in Blockspeicher und Einführung in Dateispeicher.

Der Speicher, der entweder bei manueller VMware-Konfiguration (Bare-Metal-Server mit VMware-Betriebssystemimage) oder automatisierter VMware-Konfiguration (IBM Cloud for VMware Solutions Dedicated) zu verwenden ist, ist in den folgenden Abschnitten beschrieben:

Block Storage für Virtual Servers auf VPC-Infrastruktur

Beim Netzspeicher ist die Rate der E/A-Operationen pro Sekunde und GB begrenzt und die Leistung von der Workload abhängig. Bei Managementsystemen für relationale Datenbanken (RDBMS) kann es ratsam sein, denselben Datenträger sowohl für den Protokoll- als auch für den Datenspeicher der Datenbank zu verwenden. Diese Konfiguration hängt vom Verhalten Ihrer Anwendung ab.

Für typische RDBMS-basierte Anwendungen ist im Allgemeinen ein Profil von 5 IOPS/GB angemessen.

Wenn Ihre Anwendung dedizierte KPIs (Key Performance Indicators) für die Speicherleistung verwendet, testen Sie den Speicherdurchsatz, bevor Sie mit der Softwarebereitstellung beginnen. Durch die Verwendung von Volume Manager-basiertem Software-RAID (wie LVM) erreichen Sie nahezu jeden KPI.

Beispielspeicherkonfigurationen bei Classic Infrastructure

Die folgenden Abschnitte zeigen Speicherkonfigurationen in mehreren unterschiedlichen SAP-Workloadszenarios, die Classic Infrastructure verwenden.

Beispielspeicherkonfiguration für IBM Db2 mit Verwendung von Intel Bare Metal

Tabelle 1 zeigt eine Beispielspeicherkonfiguration für einen 256-GB-Server mit 50.000 SAPS, 1,5 TB mit 6.000 IOPS für ein zentrales System mit SAP. Das System nutzt eine IBM Db2-Datenbank mit externer IBM Cloud Block Storage for Classic- oder IBM Cloud File Storage for Classic-Instanz (4 IOPS/GB). Der IOPS-Wert wird folgendermaßen berechnet:

  • 6.000 IOPS/1.500 GB = 4 IOPS/GB benötigt für externen Speicher. Es wird davon ausgegangen, dass 3.000 GB für die Sicherung mit 2 IOPS/GB (mittlere Leistung) dienen.
Beispiel für die Anordnung der Speicher auf der Grundlage der IOPS-Berechnung
Dateisystem Anzahl Datenträger Speichertyp IOPS/GB GB IOPS
/ 1 Intern Nicht zutreffend 150 GB Nicht zutreffend
/boot 1 Intern Nicht zutreffend 0,25 GB Nicht zutreffend
swap 1 Intern Nicht zutreffend 256 GB Nicht zutreffend
/db2 (inklusive Protokolle) 1 Intern Nicht zutreffend 250 GB Nicht zutreffend
sapdata 1 Extern 4 IOPS/GB 1.500 GB 6.000
backup/log and backup 1 Extern 2 IOPS/GB 3.000 GB 6.000

Beispielspeicherkonfigurationen für VPC Infrastructure

Die folgenden Abschnitte zeigen Speicherkonfigurationen in mehreren unterschiedlichen SAP-Workloadszenarios bei Verwendung von VPC Infrastructure.

Beispielspeicherkonfiguration für SAP AnyDB mit IBM Db2, die Intel Virtual Server verwendet

Für SAP AnyDB mit Verwendung von IBM Db2 unter dem Profil mx2-32x256 werden folgende Datenträger benötigt:

  • 1 x 500-GB-Datenträger; ein Blockspeicherdatenträger mit einer Größe von 500 GB und einem angepassten Datenträgerprofil, das bis zu 10.000 maximale IOPS unterstützt, angehängt an den virtuellen Server
  • 1 x 2.000-GB-Datenträger; ein Blockspeicherdatenträger mit einer Größe von 2.000 GB und einem niedrigeren IOPS-Wert von 4.000 (mittlere Leistung), angehängt an den virtuellen Server, für Sicherungen

Plattenmountpunkte und Datenträger für IBM Db2

Nachdem Sie die beiden Datenträger angehängt haben, werden zwei neue virtuelle Platten im virtuellen Server angezeigt (siehe folgende Tabelle). In diesem Beispiel sind dies die Platten vdd, vde und vdf.

Beispiel für eine Speicherkonfiguration
Dateisystem Datenträger Speichertyp IOPS/GB GB IOPS
/ vdal Vorkonfigurierter Bootdatenträger Nicht zutreffend 100 GB 3.000
/boot vda2 Vorkonfigurierter Bootdatenträger Nicht zutreffend 0,25 GB 3.000
/db2 vdd (kann variieren) Datenvolumen 20 IOPS/GB 500 GB 10.000
backup/log und backup vde (kann variieren) Datenvolumen 5 IOPS/GB 2.000 GB 4.000

Tabelle 1 zeigt das grundlegende Layout eines Dateisystems, das eine Db2-Installation unterstützt. In der Regel nutzt eine Db2-Installation Unterverzeichnisse, die in unabhängige Datenträger segmentiert werden können.

Beispiel: "/db2/<DBSID>", "/db2/<DBSID>/log_dir" und mehrere "sapdata<n>", wobei der Ordner "log_dir" die Onlineprotokolldateien der Datenbank und der "sapdata<n>" die Daten selbst enthält. Siehe zum Beispiel die Dokumentation Db2 hier: Erforderliche Dateisysteme für IBM Db2 für Linux, UNIX, und Windows.

Beispielspeicherkonfigurationen für SAP HANA

Weitere Informationen zu Speicherspezifikationen für Virtual Server-Instanzen sind verfügbar; nachfolgend sind lediglich die erforderlichen Konfigurationsschritte dargestellt.

mx2-8x64, mx2-16x128 und mx2-32x256 Profile

Das Profil mx2-8x64 ist nur für SAP Business One on HANA zertifiziert.

Für virtuelle Server, die auf der Grundlage des mx2-8x64, mx2-16x128 und mx2-32x256 profilen erstellt wurden, gibt es:

  • 3 x 500-GB-Datenträger; drei Blockspeicherdatenträger mit einer Größe von 500 GB und einem angepassten Datenträgerprofil, das bis zu 10.000 maximale IOPS unterstützt, angehängt an den virtuellen Server
  • 1 x 2.000-GB-Datenträger; ein Blockspeicherdatenträger mit einer Größe von 2.000 GB und einem niedrigeren IOPS-Wert von 4.000 (mittlere Leistung), angehängt an den virtuellen Server, für Sicherungen

Nachdem Sie die drei Datenträger angehängt haben, werden drei neue virtuelle Platten im virtuellen Server angezeigt (siehe folgende Tabelle). In diesem Beispiel sind dies die Platten vdd, vde und vdf.

Die Platten sind im Betriebssystem des virtuellen Servers wie folgt sichtbar:

[root@hana256-vsi ~]# fdisk -l

Disk /dev/vdd: 536.9 GB, 536870912000 bytes, 1048576000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/vde: 536.9 GB, 536870912000 bytes, 1048576000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/vdf: 536.9 GB, 536870912000 bytes, 1048576000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Diese drei Platten müssen unter Linux® Logical Volume Manager (LVM) verwaltet und als logische Datenträger bereitgestellt werden. Hierzu müssen Sie zunächst die drei Einheiten unter LVM-Steuerung stellen. Machen Sie sie beispielsweise zu physischen Datenträgern:

[root@hana256-vsi ~]# pvcreate /dev/vdd /dev/vde /dev/vdf

Erstellen Sie anschließend aus den physischen Datenträgern eine Datenträgergruppe. Den Namen der Datenträgergruppe können Sie frei wählen; im Beispiel heißt sie hana_vg:

[root@hana256-vsi ~]# vgcreate hana_vg /dev/vdd /dev/vde /dev/vdf

Nachdem die Datenträgergruppe erstellt worden ist, müssen drei logische Datenträger zusätzlich definiert werden. Diese logischen Datenträger setzen die Anforderungen an die Dateisystemgröße für SAP HANA um. Für einen virtuellen Server mit 256 GB werden die folgenden Befehle verwendet:

[root@hana256-vsi ~]# lvcreate -i 3 -I 64K -L 256GB -n hana_log_lv hana_vg
[root@hana256-vsi ~]# lvcreate -i 3 -I 64K -L 256GB -n hana_shared_lv hana_vg
[root@hana256-vsi ~]# lvcreate -i 3 -I 64K -l 100%FREE -n hana_data_lv hana_vg

Für einen virtuellen Server mit 128 GB muss im obigen Beispiel -L 256GB durch -L 128GB und für 64 GB durch -L 64GB ersetzt werden. Diese Befehle führen nicht zur kleinstmöglichen Dateisystemgröße, erstellen jedoch die kleinste Konfiguration, von der die SAP HANA-KPIs erfüllt werden. Abschließend muss zusätzlich zu jeder Datenträgergruppe ein Dateisystem erstellt werden:

[root@hana256-vsi ~]# mkfs.xfs /dev/mapper/hana_vg-hana_log_lv
[root@hana256-vsi ~]# mkfs.xfs /dev/mapper/hana_vg-hana_data_lv
[root@hana256-vsi ~]# mkfs.xfs /dev/mapper/hana_vg-hana_shared_lv

Die folgenden Einträge in /etc/fstab hängen die Dateisysteme an, nachdem ihre Mountpunkte (/hana/data, /hana/log und /hana/shared) erstellt worden sind:

/dev/mapper/hana_vg-hana_log_lv    /hana/log xfs defaults,swalloc,nobarrier,inode64
/dev/mapper/hana_vg-hana_shared_lv /hana/shared xfs defaults,inode64 0 0
/dev/mapper/hana_vg-hana_data_lv   /hana/data xfs defaults,largeio,swalloc,inode64 0 0

Profil 'mx2-48x384'

Für Virtual Server-Instanzen, die basierend auf dem Profil mx2-48x384 erstellt wurden, gilt Folgendes:

  • 3 x 500-GB-Datenträger; erforderlich sind drei Blockspeicherdatenträger mit einer Größe von 500 GB und einem angepassten Datenträgerprofil, das bis zu 10.000 maximale IOPS unterstützt, angehängt an den virtuellen Server
  • 4 x 100-GB-Datenträger; erforderlich sind vier Blockspeicherdatenträger mit einer Größe von 100 GB und einem angepassten Datenträgerprofil, das bis zu 6.000 maximale IOPS unterstützt, angehängt an den virtuellen Server
  • Optional: 1 x 2.000 GB Datenträger; ein Blockspeicherdatenträger mit einer Größe von 2.000 GB mit weniger als 4.000 IOPS (mittlere Leistung), die dem virtuellen Server für Sicherungen zugeordnet sind

Nachdem Sie die sieben Datenträger angehängt haben, werden sieben neue virtuelle Platten im virtuellen Server angezeigt (siehe folgende Tabelle). In diesem Beispiel sind dies die Platten vdd, vde, vdf, vdg, vdh, vdi, vdj.

Diese drei Platten müssen unter Linux® Logical Volume Manager (LVM) verwaltet und als logische Datenträger bereitgestellt werden. Hierzu müssen Sie zunächst die drei Einheiten unter LVM-Steuerung stellen. Machen Sie sie beispielsweise zu physischen Datenträgern:

[root@hana384-vsi ~]# pvcreate /dev/vd[d,e,f,g,h,i,j]

Anschließend müssen zwei separate Datenträgergruppen erstellt werden:

[root@hana384-vsi ~]# vgcreate hana_vg /dev/vdh /dev/vdi /dev/vdj
[root@hana384-vsi ~]# vgcreate hana_log_vg /dev/vdd /dev/vde /dev/vdf /dev/vdg

Danach müssen zusätzlich drei logische Datenträger definiert werden. Diese logischen Datenträger setzen die Anforderungen an die Dateisystemgröße für SAP HANA um. Für einen virtuellen Server mit 384 GB werden die folgenden Befehle verwendet:

[root@hana384-vsi ~]# lvcreate -l 100%VG -i 4 -I 64K  -n hana_log_lv hana_log_vg
[root@hana384-vsi ~]# lvcreate -i 3 -L 384G -I 64K -n hana_shared_lv hana_vg
[root@hana384-vsi ~]# lvcreate -i 3 -l 100%FREE  -I 64K -n hana_data_lv hana_vg

Abschließend muss zusätzlich zu jeder Datenträgergruppe ein Dateisystem erstellt werden:

[root@hana384-vsi ~]# mkfs.xfs /dev/mapper/hana_log_vg-hana_log_lv
[root@hana384-vsi ~]# mkfs.xfs /dev/mapper/hana_vg-hana_data_lv
[root@hana384-vsi ~]# mkfs.xfs /dev/mapper/hana_vg-hana_shared_lv

Die folgenden Einträge in /etc/fstab hängen die Dateisysteme an, nachdem ihre Mountpunkte (/hana/data, /hana/log und /hana/shared) erstellt worden sind:

/dev/mapper/hana_log_vg-hana_log_lv    /hana/log xfs defaults,swalloc,nobarrier,inode64
/dev/mapper/hana_vg-hana_shared_lv /hana/shared xfs defaults,inode64 0 0
/dev/mapper/hana_vg-hana_data_lv   /hana/data xfs defaults,largeio,swalloc,inode64 0 0

Allgemeine Speicherkonfigurationen auf IBM Power Virtual Server Infrastruktur

In den folgenden Abschnitten finden Sie allgemeine Empfehlungen für Speicherkonfigurationen verschiedener SAP-Arbeitslasten auf IBM Power Virtual Server s.

Allgemeine Aufbewahrungsrichtlinien für die SAP-Anwendung auf IBM Power Virtual Server

  • Für das Boot-Volume wird empfohlen, Fixed IOPs oder Tier 0 zu verwenden.
  • Es wird empfohlen, eine zusätzliche Kapazität für /usr/sap unter Verwendung von Fixed IOPs oder Tier 0 auf einem separaten Speichervolumen bereitzustellen.

Allgemeine Aufbewahrungsrichtlinien für SAP HANA auf IBM Power Virtual Server

  • Verwenden Sie Block-Speichervolumes mit mindestens 12,000 IOPS für SAP HANA log Dateisystem. SAP HANA die Größe des Log-Dateisystems beträgt in der Regel bis zu 512 GB. Wir empfehlen, das Dateisystem über die Speichervolumes von 4 zu streifen.
  • Verwenden Sie Block-Speichervolumes mit mindestens 8,000 IOPS für das SAP HANA-Dateisystem. SAP HANA data die Größe des Dateisystems hängt von der Speichergröße ab. SAP empfiehlt, 120-150% des für die virtuelle Maschine konfigurierten Speichers sicherzustellen. Wir empfehlen, das Dateisystem über die Speichervolumes von 4 zu streifen.
  • SAP es gibt keine Leistungsanforderungen für das Dateisystem SAP HANA shared. Wir empfehlen, mindestens 3000 IOPS für das Dateisystem zu konfigurieren. Eine Blockierung der Speichervolumen-Striping ist nicht erforderlich. Als Alternative kann sich das gemeinsam genutzte Dateisystem von SAP HANA auf dem NFS-Datenträger befinden.
  • Für das Betriebssystem-Boot-Volume empfehlen wir die Verwendung von Fixed IOPs oder Tier 0.
  • Es wird empfohlen, eine zusätzliche Kapazität für /usr/sap auf Fixed IOPs oder Tier 0 auf einem separaten Speichervolumen bereitzustellen.
  • In der folgenden Dokumentation finden Sie Beispielspeicherkonfigurationen für SAP HANA-zertifizierte Profile auf IBM Power Virtual Server.

Beispielhafte Speicherkonfiguration für Oracle DB auf IBM AIX, die die IBM verwenden Power Virtual Server

Tabelle 2 zeigt die Beispielkonfiguration einer IBM Power Virtual Server-Instanz unter AIX für eine SAP NetWeaver Application Server-Instanz, in der Oracle genutzt wird.

Der Speicher kann nicht innerhalb desselben IBM Power Virtual Servers kombiniert werden und kann entweder Tier 1 oder Tier 3 sein. Es wird empfohlen, drei weitere Platten bereitzustellen, um die Trennung zwischen Betriebssystem, Datenbank und Anwendungsschicht zu ermöglichen. Die Plattengröße hängt davon ab, ob es sich um eine Neuinstallation handelt oder der Server eine Kopie eines 'lokalen' AIX-Servers ist, der als Referenz für die Dimensionierung verwendet werden soll.

Die Namenskonvention für die LVM-Einträge ist optional. Es wird jedoch empfohlen, die SID Ihres SAP NetWeaver-Systems einzuschließen, insbesondere wenn die Installation von Instanzen geplant ist.

Beispiel für die Anordnung der Probenlagerung für Oracle
Speicher Datenträgergruppe Logischer Datenträger Mountpunkt
Betriebssystemplatte Standardkonfiguration Standardkonfiguration Standardkonfiguration
Anwendungsplatte app<sid>vg lvusrsap /usr/sap
lvusrsap{SID} /usr/sap/{SID}
lvusrsapmnt /sapmnt/{SID}
lvusrsaptrans /usr/sap/trans
lvsapDAH /usr/sap/DAH
Datenbankspeicher db<sid>vg lv{SID}arch /oracle/{SID}/oraarch
lv{SID}reorg /oracle/{SID}/sapreorg
lv{SID}origlogA /oracle/{SID}/origlogA
lv{SID}origlogB /oracle/{SID}/origlogA
lv{SID}ora /oracle/{SID}
lv{SID}sapdata1 /oracle/{SID}/sapdata1
lv{SID}sapdata2 /oracle/{SID}/sapdata2
lvorastage /oracle/stage
lv{SID}sapdata3 /oracle/{SID}/sapdata3
lv{SID}sapdata4 /oracle/{SID}/sapdata4
lv{SID}oraclient /oracle/client

Weitere Informationen finden Sie unter SAP Hinweis 2172935.

Beispiel für eine Speicherkonfiguration für IBM Db2 SaaS auf IBM AIX, die IBM verwenden Power Virtual Server

Tabelle 3 ist ein Beispiel für eine Speicherkonfiguration für einen AIX IBM Power Virtual Server für einen IBM Db2 SaaS Server.

Der Speicher kann nicht innerhalb desselben IBM Power Virtual Servers kombiniert werden und kann entweder Tier 1 oder Tier 3 sein. Die Empfehlungen lauten, drei weitere Datenträger bereitzustellen, um die Trennung zwischen Betriebssystem, Datenbank und Anwendungsschicht zu ermöglichen. Die Plattengröße hängt davon ab, ob es sich um eine Neuinstallation handelt oder der Server eine Kopie eines 'lokalen' AIX-Servers ist, der als Referenz für die Dimensionierung verwendet werden soll.

Die Namenskonvention für die LVM-Einträge ist optional. Es wird jedoch empfohlen, die SID Ihres SAP NetWeaver-Systems einzuschließen, insbesondere wenn die Installation von Instanzen geplant ist.

Beispiel für die Anordnung der Probenlagerung für Db2 on Cloud
Speicher Datenträgergruppe Logischer Datenträger Mountpunkt
Betriebssystemplatte Standardkonfiguration Standardkonfiguration Standardkonfiguration
Anwendungsplatte app<sid>vg lvusrsap /usr/sap
lvusrsap{SID} /usr/sap/{SID}
lvusrsapmnt /sapmnt/{SID}
lvusrsaptrans /usr/sap/trans
lvsapDAH /usr/sap/DAH
Db2-Datenbankspeicher I <sid>db2vg loglv{SID} Nicht zutreffend
lv{SID}db2 /db2/{SID}
lvhome{SID} /db2/db2{SID}
lv{SID}db2dump /db2/{SID}/db2dump
lv{SID}logdir /db2/{SID}/log_dir
lv{SID}log_archive /db2/{SID}/log_archive
lv{SID}saptmp /db2/{SID}/saptemp1
lv{SID}db2sw /db2/db2/<DBSID>/db2_sw
Db2-Datenbankspeicher II <sid>db2datvg lv{SID}sapdata1 /db2/{SID}/sapdata1
lv{SID}sapdata2 /db2/{SID}/sapdata2
lv{SID}sapdata3 /db2/{SID}/sapdata3
lv{SID}sapdata4 /db2/{SID}/sapdata4

Weitere Informationen finden Sie unter Erforderliche Dateisysteme für IBM Db2 für Linux, UNIX und Windows und SAP Hinweis 1707361.