Déploiement SGBD de machines virtuelles Azure IBM Db2 pour charge de travail SAP
Avec Microsoft Azure, vous pouvez migrer votre application SAP existante exécutée sur IBM Db2 pour Linux, UNIX et Windows (LUW) vers les machines virtuelles Azure. Avec SAP sur IBM Db2 pour LUW, les administrateurs et les développeurs peuvent utiliser les outils de développement et d’administration disponibles en local. Des informations générales sur l’exécution de SAP Business Suite sur IBM Db2 pour LUW sont disponibles via SAP Community Network (SCN) dans SAP sur IBM Db2 pour Linux, UNIX et Windows.
Pour des informations et des mises à jour supplémentaires de SAP sur Db2 pour LUW sur Azure, voir la Note de SAP 2233094.
Il existe différents articles pour la charge de travail SAP sur Azure. Nous vous recommandons de commencer par Bien démarrer avec SAP sur des machines virtuelles Azure, puis d’en découvrir plus sur d’autres domaines d’intérêt.
Les notes SAP suivantes sont en lien avec SAP sur Azure quant au domaine traité dans ce document :
| Numéro de la note | Intitulé |
|---|---|
| 1928533 | Applications SAP sur Azure : produits et types de machines virtuelles Azure pris en charge |
| 2015553 | SAP sur Microsoft Azure : prérequis pour le support |
| 1999351 | Résolution des problèmes de surveillance Azure améliorée pour SAP |
| 2178632 | Métriques de surveillance clés pour SAP sur Microsoft Azure |
| 1409604 | Virtualisation sur Windows : supervision améliorée |
| 2191498 | SAP sur Linux avec Azure : supervision améliorée |
| 2233094 | DB6 : exécution d’applications SAP sur Azure à l’aide d’IBM DB2 pour Linux, UNIX et Windows - Informations supplémentaires |
| 2243692 | Linux sur machine virtuelle Microsoft Azure (IaaS) : problèmes de licence SAP |
| 1984787 | SUSE LINUX Enterprise Server 12 Notes d'installation |
| 2002167 | Red Hat Enterprise Linux 7.x : installation et mise à niveau |
| 1597355 | Recommandations relatives à l’espace d’échange pour Linux |
En guise de préversion de ce document, passez en revue le document Facteurs à prendre en compte pour le déploiement SGBD des machines virtuelles Azure pour la charge de travail SAP. Passez en revue d’autres guides dans la charge de travail SAP sur Azure.
Prise en charge des versions IBM Db2 pour Linux, UNIX et Windows
SAP sur IBM Db2 pour LUW est pris en charge sur les services de machines virtuelles Microsoft Azure à compter de la version Db2 10.5.
Pour plus d’informations sur les produits SAP et les types de machines virtuelles Azure pris en charge, consultez la note SAP 1928533.
Instructions de configuration IBM Db2 pour Linux, UNIX et Windows pour les installations SAP sur des machines virtuelles Azure
Configuration du stockage
Pour obtenir une vue d’ensemble des types de stockage Azure pour la charge de travail SAP, consultez l’article Types de stockage Azure pour une charge de travail SAP. Tous les fichiers de base de données doivent être stockés sur les disques montés du stockage de blocs Azure (Windows : NTFS, Linux : xfs, pris en charge à compter de Db2 11.1, ou ext3).
Les volumes partagés distants comme les services Azure dans les scénarios répertoriés NE sont PAS pris en charge pour les fichiers de base de données Db2 :
Service de fichiers Microsoft Azure pour tous les systèmes d’exploitation invités.
Azure NetApp Files pour Db2 exécuté dans le système d’exploitation invité Windows.
Les volumes partagés distants comme les services Azure dans les scénarios répertoriés sont pris en charge pour les fichiers de base de données Db2 :
- L’hébergement de fichiers journaux et de données Db2 basés sur un système d’exploitation invité Linux sur des partages NFS hébergés sur Azure NetApp Files est pris en charge.
Si vous utilisez des disques basés sur le stockage d’objets blob de pages Azure ou de la fonctionnalité Disques managés, les instructions figurant dans Facteurs à prendre en compte pour le déploiement SGBD des machines virtuelles Azure pour la charge de travail SAP s’appliquent également aux déploiements avec le SGBD Db2.
Comme expliqué précédemment dans la partie générale du document, des quotas existent en ce qui concerne le débit d’E/S par seconde pour les disques Azure. Les quotas exacts dépendent du type de machine virtuelle utilisé. La liste des types de machines virtuelles et de leurs quotas est disponible ici (pour Linux) et ici (pour Windows).
Tant que le quota IOPS actuel par disque est suffisant, il est possible de stocker tous les fichiers de base de données sur un seul disque monté. Alors que vous devez toujours séparer les fichiers de données et les fichiers journaux de transactions sur différents disques/disques durs virtuels.
Pour en savoir plus sur les considérations relatives aux performances, consultez également, dans les guides d’installation SAP, le chapitre portant sur la sécurité des données et les considérations sur les performances pour les répertoires de base de données.
Vous pouvez également utiliser des pools de stockage Windows, qui sont disponibles uniquement dans Windows Server 2012 et versions ultérieures, comme décrit dans l’article Facteurs à prendre en compte pour le déploiement SGBD des machines virtuelles Azure pour la charge de travail SAP. Sur Linux, vous pouvez utiliser LVM ou mdadm pour créer un appareil logique volumineux sur plusieurs disques.
Pour une machine virtuelle Azure de la série M, vous pouvez réduire la latence d’écriture dans les journaux d’activité de transactions par plusieurs facteurs, comparée aux performances du stockage Premium Azure, lors de l’utilisation de l’Accélérateur d’écriture Azure. Par conséquent, vous devez déployer l’Accélérateur d’écriture Azure pour un ou plusieurs disques durs virtuels qui constituent le volume des journaux des transactions Db2. Les détails peuvent être consultés dans le document Accélérateur des écritures.
IBM Db2 LUW 11.5 propose la prise en charge d’une taille de secteur de 4 ko. Vous devez cependant activer l’utilisation d’une taille de secteur de 4 Ko avec 11.5 via le paramètre de configuration de db2set DB2_4K_DEVICE_SUPPORT = ON, comme indiqué dans :
Pour les anciennes versions de Db2, une taille de secteur de 512 octets doit être utilisée. Les disques SSD Premium sont de 4 ko en natif et ont une émulation de 512 octets. Le disque Ultra utilise une taille de secteur de 4 ko par défaut. Vous pouvez activer une taille de secteur de 512 octets lors de la création d’un disque Ultra. Les détails sont disponibles dans Utilisation de disques Ultra Azure. Cette taille de secteur de 512 octets est requise pour les versions d’IBM Db2 LUW inférieures à 11.5.
Sur Windows et pour des pools de stockage pour les chemins de stockage Db2 pour vos répertoires log_dir, sapdata et saptmp, vous devez spécifier une taille de secteur de disque physique de 512 octets. Quand vous utilisez des pools de stockage Windows, vous devez créer les pools de stockage manuellement par le biais de l’interface de ligne de commande en utilisant le paramètre -LogicalSectorSizeDefault. Pour plus d’informations, consultez New-StoragePool.
Recommandation relative à la structure des machines virtuelles et des disques pour le déploiement IBM Db2
Les applications IBM Db2 pour SAP NetWeaver sont prises en charge sur tous les types de machines virtuelles figurant dans la note de support SAP 1928533. Les familles de machines virtuelles recommandées pour l’exécution de la base de données IBM Db2 sont Esd_v4/Eas_v4/Es_v3 et la série M/M_v2 pour les bases de données de plusieurs téraoctets. Les performances d’écriture sur le disque du journal des transactions IBM Db2 peuvent être améliorées en activant l’accélérateur d’écriture de la série M.
Voici une configuration de base pour différentes tailles et utilisations de SAP sur des déploiements Db2 de petite à grande taille. La liste est basée sur le stockage Premium Azure. Toutefois, Azure ultra Disk est aussi entièrement pris en charge avec DB2 et peut également être utilisé. Utilisez les valeurs pour la capacité, le débit en rafale et les IOPS en rafale pour définir la configuration de disque Ultra. Vous pouvez limiter le nombre d’IOPS pour /db2/<SID>/log_dir à environ 5 000 IOPS.
Système SAP très petit : taille de base de données de 50 à 200 Go : exemple d’un gestionnaire de solutions
| Nom/taille de machine virtuelle | Point de montage Db2 | Disque Premium Azure | Nombre de disques | E/S par seconde | Débit [Mo/s] |
Taille [Go] | IOPS en rafale | Débit de rafale [Go] |
Taille de l’entrelacement | Mise en cache |
|---|---|---|---|---|---|---|---|---|---|---|
| E4ds_v4 | /db2 | P6 | 1 | 240 | 50 | 64 | 3 500 | 170 | ||
| Processeur virtuel : 4 | /db2/<SID>/sapdata |
P10 | 2 | 1 000 | 200 | 256 | 7 000 | 340 | 256 Ko |
Lecture seule |
| RAM : 32 Gio | /db2/<SID>/saptmp |
P6 | 1 | 240 | 50 | 128 | 3 500 | 170 | ||
/db2/<SID>/log_dir |
P6 | 2 | 480 | 100 | 128 | 7 000 | 340 | 64 Ko |
||
/db2/<SID>/offline_log_dir |
P10 | 1 | 500 | 100 | 128 | 3 500 | 170 |
Petit système SAP : taille de base de données 200 à 750 Go : Small Business Suite
| Nom/taille de machine virtuelle | Point de montage Db2 | Disque Premium Azure | Nombre de disques | E/S par seconde | Débit [Mo/s] |
Taille [Go] | IOPS en rafale | Débit de rafale [Go] |
Taille de l’entrelacement | Mise en cache |
|---|---|---|---|---|---|---|---|---|---|---|
| E16ds_v4 | /db2 | P6 | 1 | 240 | 50 | 64 | 3 500 | 170 | ||
| Processeur virtuel : 16 | /db2/<SID>/sapdata |
P15 | 4 | 4 400 | 500 | 1 024 | 14 000 | 680 | 256 Ko | Lecture seule |
| RAM : 128 Go | /db2/<SID>/saptmp |
P6 | 2 | 480 | 100 | 128 | 7 000 | 340 | 128 Ko | |
/db2/<SID>/log_dir |
P15 | 2 | 2 200 | 250 | 512 | 7 000 | 340 | 64 Ko |
||
/db2/<SID>/offline_log_dir |
P10 | 1 | 500 | 100 | 128 | 3 500 | 170 |
Système SAP moyen : taille de base de données 500 à 1 000 Go : Small Business Suite
| Nom/taille de machine virtuelle | Point de montage Db2 | Disque Premium Azure | Nombre de disques | E/S par seconde | Débit [Mo/s] |
Taille [Go] | IOPS en rafale | Débit de rafale [Go] |
Taille de l’entrelacement | Mise en cache |
|---|---|---|---|---|---|---|---|---|---|---|
| E32ds_v4 | /db2 | P6 | 1 | 240 | 50 | 64 | 3 500 | 170 | ||
| Processeur virtuel : 32 | /db2/<SID>/sapdata |
P30 | 2 | 10 000 | 400 | 2 048 | 10 000 | 400 | 256 Ko | Lecture seule |
| RAM : 256 Gio | /db2/<SID>/saptmp |
P10 | 2 | 1 000 | 200 | 256 | 7 000 | 340 | 128 Ko | |
/db2/<SID>/log_dir |
P20 | 2 | 4 600 | 300 | 1 024 | 7 000 | 340 | 64 Ko |
||
/db2/<SID>/offline_log_dir |
P15 | 1 | 1 100 | 125 | 256 | 3 500 | 170 |
Système SAP volumineux : taille de base de données 750 à 2 000 Go : Business Suite
| Nom/taille de machine virtuelle | Point de montage Db2 | Disque Premium Azure | Nombre de disques | E/S par seconde | Débit [Mo/s] |
Taille [Go] | IOPS en rafale | Débit de rafale [Go] |
Taille de l’entrelacement | Mise en cache |
|---|---|---|---|---|---|---|---|---|---|---|
| E64ds_v4 | /db2 | P6 | 1 | 240 | 50 | 64 | 3 500 | 170 | ||
| Processeur virtuel : 64 | /db2/<SID>/sapdata |
P30 | 4 | 20 000 | 800 | 4.096 | 20 000 | 800 | 256 Ko | Lecture seule |
| RAM : 504 Gio | /db2/<SID>/saptmp |
P15 | 2 | 2 200 | 250 | 512 | 7 000 | 340 | 128 Ko | |
/db2/<SID>/log_dir |
P20 | 4 | 9 200 | 600 | 2 048 | 14 000 | 680 | 64 Ko |
||
/db2/<SID>/offline_log_dir |
P20 | 1 | 2 300 | 150 | 512 | 3 500 | 170 |
Système SAP volumineux de plusieurs téraoctets : base de données de 2 To et plus : système Global Business Suite
| Nom/taille de machine virtuelle | Point de montage Db2 | Disque Premium Azure | Nombre de disques | E/S par seconde | Débit [Mo/s] |
Taille [Go] | IOPS en rafale | Débit de rafale [Go] |
Taille de l’entrelacement | Mise en cache |
|---|---|---|---|---|---|---|---|---|---|---|
| M128s | /db2 | P10 | 1 | 500 | 100 | 128 | 3 500 | 170 | ||
| Processeur virtuel : 128 | /db2/<SID>/sapdata |
P40 | 4 | 30,000 | 1 000 | 8 192 | 30,000 | 1 000 | 256 Ko | Lecture seule |
| RAM : 2048 Gio | /db2/<SID>/saptmp |
P20 | 2 | 4 600 | 300 | 1 024 | 7 000 | 340 | 128 Ko | |
/db2/<SID>/log_dir |
P30 | 4 | 20 000 | 800 | 4.096 | 20 000 | 800 | 64 Ko |
Écriture Accélérateur |
|
/db2/<SID>/offline_log_dir |
P30 | 1 | 5 000 | 200 | 1 024 | 5 000 | 200 |
Utilisation d’Azure NetApp Files
L’utilisation de volumes NFS v4.1 basés sur Azure NetApp Files (ANF) est prise en charge avec IBM Db2, hébergé sur un système d’exploitation invité Suse ou Red Hat Linux. Vous devez créer au moins quatre volumes différents, comme suit :
- Volume partagé pour saptmp1, sapmnt, usr_sap,
<sid>_home, db2<sid>_home, db2_software - Un volume de données pour les fichiers sapdata1 à sapdatan
- Un volume de fichier journal pour le répertoire des journaux de restauration par progression
- Un volume pour les archives et les sauvegardes des journaux
Un cinquième volume potentiel peut être un volume ANF que vous utilisez pour des sauvegardes à long terme supplémentaires que vous utilisez pour l’instantané et le stockage des captures instantanées dans le magasin d’objets blob Azure.
La configuration peut ressembler à ce qui suit :
Le niveau de performance et la taille des volumes hébergés ANF doivent être choisis en fonction des exigences de performances. Toutefois, nous vous recommandons d’utiliser le niveau de performance Ultra pour le volume de données et de journaux. La combinaison de types de stockage de bloc et de stockage partagé pour le volume de données et de journaux n’est pas prise en charge.
En ce qui concerne les options de montage, le montage de ces volumes peut ressembler à ce qui suit (vous devez remplacer <SID> et <sid> par le SID de votre système SAP) :
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
Notes
Les options de montage Hard et Sync sont requises.
Sauvegarde/restauration
La fonctionnalité de sauvegarde/restauration d’IBM Db2 pour LUW est prise en charge de la même façon que sur les systèmes d’exploitation Windows Server et Hyper-V standard.
Assurez-vous de disposer d’une stratégie de sauvegarde de base de données valide en place.
À l’instar des déploiements sur système nu, les performances de sauvegarde/restauration dépendent du nombre de volumes pouvant être lus en parallèle et du débit éventuel de ces volumes. En outre, la consommation d’UC par la compression de sauvegarde peut jouer un rôle significatif sur les machines virtuelles ayant jusqu’à huit threads d’UC. Par conséquent, on peut partir des hypothèses suivantes :
- Moins il y a de disques utilisés pour stocker les unités de base de données, plus le débit global de lecture est réduit
- Moins il y a de threads UC dans la machine virtuelle, plus l’impact de la compression de sauvegarde est grave
- Moins il y a de cibles (répertoires d’agrégation, disques) d’écriture de la sauvegarde, plus le débit est faible
Pour augmenter le nombre de cibles d’écriture, il est possible d’utiliser/de combiner deux options selon vos besoins :
- Agréger le volume cible de sauvegarde sur plusieurs disques pour améliorer le débit d’E/S par seconde sur ce volume agrégé par bandes
- Utiliser plusieurs répertoires cible d’écriture de la sauvegarde
Remarque
Db2 sur Windows ne prend pas en charge la technologie Windows VSS. Par conséquent, la sauvegarde de machine virtuelle cohérente par rapport à l’application du service de sauvegarde Azure ne peut pas être exploitée pour les machines virtuelles dans lequel le SGBD Db2 est déployé.
Haute disponibilité et récupération d’urgence
Linux Pacemaker
Important
Pour db2 versions 11.5.6 et ultérieures, nous vous recommandons vivement d’utiliser la solution intégrée à l’aide de Pacemaker d’IBM.
- Solution intégrée utilisant Pacemaker
- Configurations alternatives ou supplémentaires disponibles sur Microsoft Azure La fonctionnalité HADR (haute disponibilité et récupération d’urgence) Db2 avec Pacemaker est prise en charge. Les systèmes d’exploitation SLES et RHEL sont pris en charge. Cette configuration active la haute disponibilité d’IBM Db2 pour SAP. Guides de déploiement :
- SLES : Haute disponibilité d’IBM Db2 LUW sur les machines virtuelles Azure sur SUSE Linux Enterprise Server avec Pacemaker
- RHEL : Haute disponibilité d’IBM Db2 LUW sur les machines virtuelles Azure sur Red Hat Enterprise Linux Server
Windows Cluster Server
Microsoft Cluster Server (MSCS) n’est pas pris en charge.
La fonction HADR (haute disponibilité et récupération d’urgence) Db2 est prise en charge. Si les machines virtuelles de la configuration haute disponibilité disposent de la résolution de noms de travail, l’installation dans Azure ne diffère pas d’une installation effectuée en local. Il est déconseillé de se fier uniquement à la résolution IP.
N’utilisez pas la géoréplication pour les comptes de stockage qui stockent les disques de base de données. Pour plus d’informations, consultez le document Facteurs à prendre en compte pour le déploiement SGBD des machines virtuelles Azure pour la charge de travail SAP.
Mise en réseau accélérée
Pour les déploiements Db2 sur Windows, il est fortement recommandé d’utiliser la fonctionnalité Azure de performances réseau accélérées, comme décrit dans le document Performances réseau accélérées Azure. Consultez aussi les recommandations dans Facteurs à prendre en compte pour le déploiement SGBD des machines virtuelles Azure pour la charge de travail SAP.
Caractéristiques pour les déploiements Linux
Tant que le quota IOPS actuel par disque est suffisant, il est possible de stocker tous les fichiers de base de données sur un seul disque. Alors que vous devez toujours séparer les fichiers de données et les fichiers journaux de transactions sur différents disques.
Si le débit d’E/S ou IOPS d’un seul disque dur virtuel Azure n’est pas suffisant, vous pouvez utiliser MDADM ou LVM (gestionnaire de volume logique) comme décrit dans le document Facteurs à prendre en compte pour le déploiement SGBD des machines virtuelles Azure pour la charge de travail SAP pour créer une unité logique volumineuse sur plusieurs disques.
Pour les disques contenant les chemins de stockage Db2 pour vos répertoires sapdata et saptmp, vous devez spécifier une taille de secteur de disque physique de 512 Ko.
Autres
Tous les autres sujets généraux, notamment les groupes à haute disponibilité Azure ou la surveillance SAP, s’appliquent également aux déploiements de machines virtuelles avec la base de données IBM. Ces domaines généraux sont décrits dans l’article Facteurs à prendre en compte pour le déploiement SGBD des machines virtuelles Azure pour la charge de travail SAP.
Étapes suivantes
Lisez l’article suivant :