Azure Virtual Machines – IBM DB2-DBMS-Bereitstellung für SAP-Workload
Mit Microsoft Azure können Sie Ihre bestehende SAP-Anwendung unter IBM Db2 für Linux, UNIX und Windows (LUW) zu Azure-VMs migrieren. Bei SAP unter IBM Db2 für LUW stehen Administratoren und Entwicklern die vertrauten Entwicklungs- und Verwaltungstools aus der lokalen Umgebung zur Verfügung. Allgemeine Informationen zum Ausführen der SAP Business Suite in IBM Db2 für LUW sind über das SAP Community Network (SCN) in SAP auf IBM Db2 für Linux, UNIX und Windows verfügbar.
Weitere Informationen und Updates zu SAP unter Db2 für LUW in Azure finden Sie im SAP-Hinweis 2233094.
Es gibt verschiedene Artikel für SAP-Workload in Azure. Es wird empfohlen, mit Erste Schritte mit SAP auf Azure-VMs zu beginnen und sich dann über weitere Interessenbereiche zu informieren.
Die nachstehenden SAP-Hinweise beziehen sich auf SAP in Azure und die in diesem Dokument behandelten Themen:
| Hinweisnummer | Titel |
|---|---|
| 1928533 | SAP-Anwendungen auf Azure: Unterstützte Produkte und Azure VM-Typen |
| 2015553 | SAP auf Microsoft Azure: Voraussetzungen für die Unterstützung |
| 1999351 | Problembehandlung für die erweiterte Azure-Überwachung für SAP |
| 2178632 | Wichtige Überwachungsmetriken für SAP in Microsoft Azure |
| 1409604 | Virtualisierung unter Windows: Erweiterte Überwachung |
| 2191498 | SAP unter Linux mit Azure: Erweiterte Überwachung |
| 2233094 | DB6: SAP-Anwendungen auf Azure mit IBM DB2 für Linux, UNIX und Windows – Weitere Informationen |
| 2243692 | Microsoft Azure (IaaS)-VM: SAP-Lizenzprobleme |
| 1984787 | SUSE LINUX Enterprise Server 12: Installationshinweise |
| 2002167 | Red Hat Enterprise Linux 7.x: Installation und Upgrade |
| 1597355 | Empfehlung zu Auslagerungsbereichen für Linux |
Als Vorgelesen in diesem Dokument lesen Sie Überlegungen zur DBMS-Bereitstellung von Azure Virtual Machines für SAP-Workload. Überprüfen Sie weitere Leitfäden in der SAP-Workload in Azure.
Versionsunterstützung für IBM Db2 für Linux, UNIX und Windows
SAP unter IBM Db2 für LUW auf Microsoft Azure Virtual Machine Services wird seit Db2 Version 10.5 unterstützt.
Informationen zu den unterstützten SAP-Produkten und Typen der Azure-VM (Virtual Machines) erhalten Sie in SAP-Hinweis [1928533].1928533.
Konfigurationsrichtlinien für IBM Db2 für Linux, UNIX und Windows für SAP-Installationen in Azure-VMs
Speicherkonfiguration
Einen Überblick über die Azure-Speichertypen für SAP-Workloads finden Sie im Artikel Azure-Speichertypen für SAP-Workloads. Alle Datenbankdateien müssen auf gemounteten Festplatten des Azure-Blockspeichers (Windows: NTFS, Linux: xfs, unterstützt ab Db2 11.1, oder ext3) gespeichert werden.
Freigegebene Remotevolumes wie die Azure-Dienste in den aufgeführten Szenarien werden für Db2-Datenbankdateien NICHT unterstützt:
Microsoft Azure-Dateidienst für alle Gastbetriebssysteme
Azure NetApp Files für Db2, ausgeführt in Windows Gastbetriebssystem.
Freigegebene Remotevolumes wie die Azure-Dienste in den aufgeführten Szenarien werden für Db2-Datenbankdateien unterstützt:
- Das Hosten von auf dem Linux-Gastbetriebssystem basierenden Db2-Daten- und -Protokolldateien auf NFS-Freigaben, die unter Azure NetApp Files gehostet werden, wird unterstützt!
Die in Artikel Azure Virtual Machines – DBMS-Bereitstellung für SAP-Workload getroffenen Aussagen gelten auch für Bereitstellungen mit dem Db2-DBMS, wenn Sie Datenträger auf Basis von Azure Page Blob Storage oder Managed Disks verwenden.
Wie weiter oben im allgemeinen Teil dieses Dokuments erläutert wurde, gelten für Azure-Datenträger Kontingente für den IOPS-Durchsatz. Die jeweilige Größe der Kontingente hängt vom Typ der verwendeten VM ab. Eine Liste mit VM-Typen und den entsprechenden Kontingenten finden Sie hier (Linux) und hier (Windows).
Solange das bestehende IOPS-Kontingent pro Datenträger ausreicht, ist es möglich, alle Datenbankdateien auf einem einzelnen eingebundenen Datenträger zu speichern. Dabei sollten Sie immer die Datendateien und Transaktionsprotokolldateien auf unterschiedlichen Datenträgern/VHDs speichern.
Weitere Informationen zur Leistung finden Sie auch im Kapitel „Datensicherheit und Leistung bei Datenbankverzeichnissen“ (in englischer Sprache) in den SAP-Installationshandbüchern.
Alternativ können Sie Windows Storage Pools verwenden, die nur in Windows Server 2012 und höher verfügbar sind, wie beschrieben Überlegungen zur Bereitstellung virtueller Azure-Computer für SAP-Workload. Unter Linux können Sie LVM oder mdadm verwenden, um ein großes logisches Gerät über mehrere Datenträger zu erstellen.
Bei Azure-VMs der M-Serie kann die Latenz beim Schreiben in die Transaktionsprotokolle im Vergleich zur Azure Storage Premium-Leistung um Faktoren reduziert werden, wenn Azure-Schreibbeschleunigung verwendet wird. Daher sollten Sie Azure-Schreibbeschleunigung für die VHD(s) bereitstellen, die das Volume für die Db2-Transaktionsprotokolle bilden. Details finden Sie im Dokument Schreibbeschleunigung.
IBM Db2 LUW 11.5 mit Unterstützung für Sektoren der Größe 4 KB. Sie müssen jedoch die Verwendung der Sektorgröße von 4 KB mit 11.5 durch die Konfigurationseinstellung „db2set DB2_4K_DEVICE_SUPPORT=ON“ wie in den folgenden Dokumentationen beschrieben aktivieren:
Bei älteren Db2-Versionen muss eine Sektorgröße von 512 Byte verwendet werden. SSD Premium-Datenträger haben nativ eine Sektorgröße von 4 KB und emulieren 512 Byte. Bei Ultra-Datenträgern wird standardmäßig eine Sektorgröße von 4 KB verwendet. Sie können eine Sektorgröße von 512 Byte bei der Erstellung eines Ultra-Datenträgers aktivieren. Details finden Sie unter Verwenden von Azure Ultra-Datenträgern. Diese Sektorgröße von 512 Byte ist eine Voraussetzung für IBM Db2 LUW-Versionen vor 11.5.
Legen Sie unter Windows für Speicherpools, die die Db2-Speicherpfade für die Verzeichnisse log_dir, sapdata und saptmp enthalten, eine Sektorgröße für physische Datenträger von 512 KB fest. Wenn Sie Windows-Speicherpools verwenden, müssen die Speicherpools manuell über die Befehlszeilenschnittstelle erstellt werden. Der Parameter hierfür lautet -LogicalSectorSizeDefault. Weitere Informationen finden Sie unter New-StoragePool.
Empfehlung zur VM- und Datenträgerstruktur für die Bereitstellung von IBM Db2
IBM Db2 für SAP NetWeaver-Anwendungen wird auf allen VM-Typen unterstützt, die im SAP-Supporthinweis 1928533 aufgeführt sind. Empfohlene VM-Familien für die Ausführung der IBM Db2-Datenbank sind die Esd_v4/Eas_v4/Es_v3- und M/M_v2-Serie für große Datenbanken mit mehreren Terabyte. Die Leistung des Datenträgers beim Schreiben des IBM Db2-Transaktionsprotokolls kann durch Aktivieren der Schreibbeschleunigung für die M-Serie verbessert werden.
Im Folgenden finden Sie eine Baselinekonfiguration für verschiedene Größen und Verwendungsmöglichkeiten von SAP-Bereitstellungen für Db2, von klein bis groß. Die Liste basiert auf Azure Storage Premium. Azure Ultra Disk wird jedoch auch vollständig mit DB2 unterstützt und kann ebenfalls verwendet werden. Verwenden Sie die Werte für Kapazität, Burstdurchsatz und Burst-IOPS, um die Konfiguration von Ultra-Datenträgern zu definieren. Sie können den IOPS-Wert für „/db2/<SID>/log_dir“ bei ungefähr 5.000 IOPS einschränken.
Besonders kleines SAP-System: Datenbankgröße 50–200 GB: Beispiel-Lösungs-Manager
| Name/Größe des virtuellen Computers | Db2-Bereitstellungspunkt | Azure-Premium-Datenträger | Anzahl von Datenträgern | IOPS | Durch- satz [MB/s] |
Größe [GB] | Burst-IOPS | Burstdurch- satz [GB] |
Stripegröße | Caching |
|---|---|---|---|---|---|---|---|---|---|---|
| E4ds_v4 | /db2 | P6 | 1 | 240 | 50 | 64 | 3\.500 | 170 | ||
| vCPU: 4 | /db2/<SID>/sapdata |
P10 | 2 | 1\.000 | 200 | 256 | 7\.000 | 340 | 256 KB |
ReadOnly |
| RAM: 32 GiB | /db2/<SID>/saptmp |
P6 | 1 | 240 | 50 | 128 | 3\.500 | 170 | ||
/db2/<SID>/log_dir |
P6 | 2 | 480 | 100 | 128 | 7\.000 | 340 | 64 KB |
||
/db2/<SID>/offline_log_dir |
P10 | 1 | 500 | 100 | 128 | 3\.500 | 170 |
Kleines SAP-System: Datenbankgröße 200–750 GB: kleine Business Suite
| Name/Größe des virtuellen Computers | Db2-Bereitstellungspunkt | Azure-Premium-Datenträger | Anzahl von Datenträgern | IOPS | Durch- satz [MB/s] |
Größe [GB] | Burst-IOPS | Burstdurch- satz [GB] |
Stripegröße | Caching |
|---|---|---|---|---|---|---|---|---|---|---|
| E16ds_v4 | /db2 | P6 | 1 | 240 | 50 | 64 | 3\.500 | 170 | ||
| vCPU: 16 | /db2/<SID>/sapdata |
P15 | 4 | 4\.400 | 500 | 1.024 | 14.000 | 680 | 256 KB | ReadOnly |
| RAM: 128 GB | /db2/<SID>/saptmp |
P6 | 2 | 480 | 100 | 128 | 7\.000 | 340 | 128 KB | |
/db2/<SID>/log_dir |
P15 | 2 | 2.200 | 250 | 512 | 7\.000 | 340 | 64 KB |
||
/db2/<SID>/offline_log_dir |
P10 | 1 | 500 | 100 | 128 | 3\.500 | 170 |
Mittleres SAP-System: Datenbankgröße 500–1000 GB: kleine Business Suite
| Name/Größe des virtuellen Computers | Db2-Bereitstellungspunkt | Azure-Premium-Datenträger | Anzahl von Datenträgern | IOPS | Durch- satz [MB/s] |
Größe [GB] | Burst-IOPS | Burstdurch- satz [GB] |
Stripegröße | Caching |
|---|---|---|---|---|---|---|---|---|---|---|
| E32ds_v4 | /db2 | P6 | 1 | 240 | 50 | 64 | 3\.500 | 170 | ||
| vCPU: 32 | /db2/<SID>/sapdata |
P30 | 2 | 10.000 | 400 | 2.048 | 10.000 | 400 | 256 KB | ReadOnly |
| RAM: 256 GiB | /db2/<SID>/saptmp |
P10 | 2 | 1\.000 | 200 | 256 | 7\.000 | 340 | 128 KB | |
/db2/<SID>/log_dir |
P20 | 2 | 4\.600 | 300 | 1.024 | 7\.000 | 340 | 64 KB |
||
/db2/<SID>/offline_log_dir |
P15 | 1 | 1.100 | 125 | 256 | 3\.500 | 170 |
Großes SAP-System: Datenbankgröße 750–2000 GB: Business Suite
| Name/Größe des virtuellen Computers | Db2-Bereitstellungspunkt | Azure-Premium-Datenträger | Anzahl von Datenträgern | IOPS | Durch- satz [MB/s] |
Größe [GB] | Burst-IOPS | Burstdurch- satz [GB] |
Stripegröße | Caching |
|---|---|---|---|---|---|---|---|---|---|---|
| E64ds_v4 | /db2 | P6 | 1 | 240 | 50 | 64 | 3\.500 | 170 | ||
| vCPU: 64 | /db2/<SID>/sapdata |
P30 | 4 | 20.000 | 800 | 4.096 | 20.000 | 800 | 256 KB | ReadOnly |
| RAM: 504 GiB | /db2/<SID>/saptmp |
P15 | 2 | 2.200 | 250 | 512 | 7\.000 | 340 | 128 KB | |
/db2/<SID>/log_dir |
P20 | 4 | 9\.200 | 600 | 2.048 | 14.000 | 680 | 64 KB |
||
/db2/<SID>/offline_log_dir |
P20 | 1 | 2\.300 | 150 | 512 | 3\.500 | 170 |
Großes SAP-System mit mehreren Terabyte: Datenbankgröße mindestens 2 TB: Globales Business Suite-System
| Name/Größe des virtuellen Computers | Db2-Bereitstellungspunkt | Azure-Premium-Datenträger | Anzahl von Datenträgern | IOPS | Durch- satz [MB/s] |
Größe [GB] | Burst-IOPS | Burstdurch- satz [GB] |
Stripegröße | Caching |
|---|---|---|---|---|---|---|---|---|---|---|
| M128s | /db2 | P10 | 1 | 500 | 100 | 128 | 3\.500 | 170 | ||
| vCPU: 128 | /db2/<SID>/sapdata |
P40 | 4 | 30.000 | 1,000 | 8.192 | 30.000 | 1,000 | 256 KB | ReadOnly |
| RAM: 2,048 GiB | /db2/<SID>/saptmp |
P20 | 2 | 4\.600 | 300 | 1.024 | 7\.000 | 340 | 128 KB | |
/db2/<SID>/log_dir |
P30 | 4 | 20.000 | 800 | 4.096 | 20.000 | 800 | 64 KB |
Schreib- Accelerator |
|
/db2/<SID>/offline_log_dir |
P30 | 1 | 5\.000 | 200 | 1.024 | 5\.000 | 200 |
Verwenden von Azure NetApp Files
Die Verwendung von NFS v4.1-Volumes auf Basis von Azure NetApp Files (ANF) wird mit IBM Db2 unterstützt, das im Suse- oder Red Hat Linux-Gastbetriebssystem gehostet wird. Sie sollten mindestens vier verschiedene Volumes erstellen, die wie folgt aufgelistet sind:
- Freigegebenes Volume für saptmp1, sapmnt, usr_sap,
<sid>_home, db2<sid>_home, db2_software - Ein Datenvolume für sapdata1 bis sapdatan
- Ein Protokollvolume für das Verzeichnis für Wiederholungsprotokolle
- Ein Volume für die Protokollarchive und Sicherungen
Ein fünftes potenzielles Volume könnte ein ANF-Volume sein, das Sie für längerfristige Sicherungen verwenden und die Momentaufnahmen im Azure Blob-Speicher speichern.
Die Konfiguration könnte wie folgt aussehen
Die Leistungsstufe und die Größe der von ANF gehosteten Volumes müssen auf der Grundlage der Leistungsanforderungen ausgewählt werden. Wir empfehlen jedoch, für die Daten und das Protokollvolumen die Leistungsstufe „Ultra“ zu wählen. Es wird nicht unterstützt, Blockspeicher und gemeinsam genutzte Speichertypen für das Daten- und Protokollvolume zu mischen.
Mit den Einbindungsoptionen könnte das Einbinden dieser Volumes wie folgt aussehen (Sie müssen <SID> und <sid> durch die SID Ihres SAP-Systems ersetzen):
vi /etc/idmapd.conf
# Example
[General]
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2shared /mnt
mkdir -p /db2/Software /db2/AN1/saptmp /usr/sap/<SID> /sapmnt/<SID> /home/<sid>adm /db2/db2<sid> /db2/<SID>/db2_software
mkdir -p /mnt/Software /mnt/saptmp /mnt/usr_sap /mnt/sapmnt /mnt/<sid>_home /mnt/db2_software /mnt/db2<sid>
umount /mnt
mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2data /mnt
mkdir -p /db2/AN1/sapdata/sapdata1 /db2/AN1/sapdata/sapdata2 /db2/AN1/sapdata/sapdata3 /db2/AN1/sapdata/sapdata4
mkdir -p /mnt/sapdata1 /mnt/sapdata2 /mnt/sapdata3 /mnt/sapdata4
umount /mnt
mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2log /mnt
mkdir /db2/AN1/log_dir
mkdir /mnt/log_dir
umount /mnt
mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2backup /mnt
mkdir /db2/AN1/backup
mkdir /mnt/backup
mkdir /db2/AN1/offline_log_dir /db2/AN1/db2dump
mkdir /mnt/offline_log_dir /mnt/db2dump
umount /mnt
Hinweis
Die Einbindungsoptionen „hard“ und „sync“ sind erforderlich.
Sichern und Wiederherstellen
Die Funktionen zum Sichern und Wiederherstellen werden für IBM Db2 für LUW genauso unterstützt wie auf standardmäßigen Windows Server-Betriebssystemen und Hyper-V.
Stellen Sie sicher, dass eine gültige Strategie für die Datenbanksicherung vorhanden ist.
Wie bei der Bare-Metal-Bereitstellung hängt die Leistung bei der Sicherung und Wiederherstellung davon ab, wie viele Volumes parallel ausgelesen werden können und wie hoch deren Durchsatz ist. Bei virtuellen Computern mit bis zu acht CPU-Threads sollte unter Umständen auch der CPU-Verbrauch durch die Sicherungskomprimierung beachtet werden. Es gilt also Folgendes:
- Je geringer die Anzahl an Datenträgern, auf denen sich Datenbankgeräte befinden, desto geringer der Durchsatz beim Auslesen insgesamt.
- Je weniger CPU-Threads in der VM, desto schwerwiegender der Einfluss der Sicherungskomprimierung.
- Je weniger Ziele (Stripesetverzeichnisse, Datenträger), in bzw. auf die die Sicherung geschrieben wird, desto geringer der Durchsatz.
Wenn Sie die Anzahl der Ziele erhöhen möchten, stehen Ihnen je nach Anforderungen zwei Optionen zur Verfügung, die Sie verwenden bzw. kombinieren können:
- Striping des Zielvolumes der Sicherung auf mehrere Datenträger, wodurch der IOPS-Durchsatz auf den betreffenden Datenträgervolumes verbessert wird
- Verwenden von mehr als einem Zielverzeichnis für das Sichern
Hinweis
Db2 für Windows unterstützt nicht die Windows VSS-Technologie. Daher kann nicht die anwendungskonsistente VM-Sicherung des Azure Backup-Diensts nicht für VMs genutzt werden, in denen Db2-DBMS bereitgestellt wird.
Hochverfügbarkeit und Notfallwiederherstellung
Linux Pacemaker
Wichtig
Für Db2-Versionen 11.5.6 und höher wird dringend eine integrierte Lösung empfohlen, die Pacemaker von IBM verwendet.
- Integrierte Lösung mithilfe von Pacemaker
- Alternative oder zusätzliche Konfigurationen, die in Microsoft Azure Db2 High HADR (High Availability Disaster Recovery) mit Pacemaker verfügbar sind, werden unterstützt. Die Betriebssysteme SLES und RHEL werden unterstützt. Diese Konfiguration ermöglicht die Hochverfügbarkeit von IBM Db2 für SAP. Bereitstellungsrichtlinien:
- SLES: Hochverfügbarkeit von IBM Db2 LUW auf Azure-VMs unter SUSE Linux Enterprise Server mit Pacemaker
- RHEL: Hochverfügbarkeit von IBM Db2 LUW auf Azure-VMs unter Red Hat Enterprise Linux Server
Windows Cluster Server
Microsoft Cluster Server (MSCS) wird nicht unterstützt.
Hochverfügbarkeit und Notfallwiederherstellung (HADR) in Db2 wird unterstützt. Wenn die an der Hochverfügbarkeitskonfiguration teilnehmenden virtuellen Computer über eine funktionierende Namensauflösung verfügen, unterscheidet sich die Einrichtung in Azure nicht von anderen, lokal ausgeführten Einrichtungen. Es wird nicht empfohlen, ausschließlich die IP-Auflösung zugrunde zu legen.
Verwenden Sie nicht die geografische Replikation für die Speicherkonten, in denen die Datenbankdatenträger gespeichert werden. Weitere Informationen finden Sie im Artikel Azure Virtual Machines – DBMS-Bereitstellung für SAP-Workload.
Beschleunigter Netzwerkbetrieb
Für Db2-Bereitstellungen unter Windows wird dringend empfohlen, die Azure-Funktionalität des beschleunigten Netzwerkbetriebs zu nutzen, wie in Artikel VM-Leistungssteigerung mit beschleunigtem Netzwerkbetrieb – jetzt verfügbar für Windows und Linux (in englischer Sprache) beschrieben. Nützlich sind auch die Empfehlungen unter Azure Virtual Machines – DBMS-Bereitstellung für SAP-Workload.
Besonderheiten von Linux-Bereitstellungen
Solange das bestehende IOPS-Kontingent pro Datenträger ausreicht, ist es möglich, alle Datenbankdateien auf einem einzelnen Datenträger zu speichern. Dabei sollten Sie immer die Datendateien und Transaktionsprotokolldateien auf unterschiedlichen Datenträgern speichern.
Wenn der IOPS- oder E/A-Durchsatz einer einzelnen Azure-VHD nicht ausreicht, können Sie LVM oder MDADM verwenden (siehe Azure Virtual Machines – DBMS-Bereitstellung für SAP-Workload), um ein einziges großes, logisches Gerät aus mehreren Datenträgern zu erstellen.
Legen Sie für die Datenträger, die die Db2-Speicherpfade für die Verzeichnisse sapdata und saptmp enthalten, eine Sektorgröße für physische Datenträger von 512 KB fest.
Andere
Alle anderen allgemeinen Bereiche wie Azure Availability Sets oder SAP Monitoring gelten auch für Bereitstellungen von VMs mit der IBM-Datenbank. Diese allgemeinen Bereiche beschreiben wir in Überlegungen zur DBMS-Bereitstellung für virtuelle Azure-Computer für SAP-Workload.
Nächste Schritte
Lesen Sie diesen Artikel: