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:
- Bei VMware vSphere auf Bare-Metal-Servern von IBM Cloud zu verwendender Speicher (hier finden Sie weitergehende Anleitungen zur Integation von Speicher in einer ESX-Umgebung)
- Bei IBM Cloud for VMware Solutions Dedicated zu verwendender Speicher
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.
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
.
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
oderTier 0
zu verwenden. - Es wird empfohlen, eine zusätzliche Kapazität für
/usr/sap
unter Verwendung vonFixed IOPs
oderTier 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 HANAlog
Dateisystem. SAP HANA die Größe des Log-Dateisystems beträgt in der Regel bis zu512 GB
. Wir empfehlen, das Dateisystem über die Speichervolumes von4
zu streifen. - Verwenden Sie Block-Speichervolumes mit mindestens
8,000 IOPS
für das SAP HANA-Dateisystem. SAP HANAdata
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 von4
zu streifen. - SAP es gibt keine Leistungsanforderungen für das Dateisystem SAP HANA
shared
. Wir empfehlen, mindestens3000 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
oderTier 0
. - Es wird empfohlen, eine zusätzliche Kapazität für /usr/sap auf
Fixed IOPs
oderTier 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.
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.
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.