Facteurs à prendre en compte pour le déploiement SGBD des machines virtuelles Azure pour la charge de travail SAP

  • Article

Ce guide fait partie de la documentation sur l’implémentation et le déploiement des logiciels SAP sur Microsoft Azure. Avant de lire ce guide, consultez le Guide de planification et d’implémentation et les articles proposés par le guide de planification. Ce document décrit les aspects généraux du déploiement de systèmes SGBD de type SAP sur des machines virtuelles Microsoft Azure à l’aide des fonctionnalités Azure IaaS.

Ce document vient compléter la documentation sur l’installation SAP et les notes SAP, qui constituent les principales ressources à consulter pour installer et déployer des logiciels SAP sur des plateformes.

Ce document aborde l’exécution des systèmes SGBD de type SAP sur les machines virtuelles Azure. Il y a peu de références aux systèmes SGBD spécifiques dans ce document. À la place, les systèmes SGBD spécifiques sont gérés dans d’autres documents propres au système de base de données.

Ressources

D’autres articles sont disponibles sur la charge de travail SAP sur Azure. Commencez par lire Charge de travail SAP sur Azure : bien démarrer, puis choisissez le domaine qui vous intéresse.

Les notes SAP suivantes concernent SAP sur Azure et s’appliquent au domaine traité dans ce document.

Numéro de la note Intitulé
1928533 Applications SAP sur Azure : Produits et types de machines virtuelles pris en charge
2015553 SAP sur Microsoft Azure : Prérequis pour la prise en charge
1999351 Résolution des problèmes de la surveillance Azure améliorée pour SAP
2178632 Métriques de surveillance clés pour SAP sur Microsoft Azure
1409604 Virtualisation sur Windows : Surveillance améliorée
2191498 SAP sur Linux avec Azure : Surveillance améliorée
2039619 Applications SAP sur Microsoft Azure avec la base de données Oracle : Produits et versions pris en charge
2233094 DB6 : Applications SAP sur Azure avec IBM DB2 pour Linux, UNIX et Windows : Informations supplémentaires
2243692 Linux sur machine virtuelle Microsoft Azure (IaaS) : problèmes de licence SAP
2578899 SUSE Linux Enterprise Server 15 : Note d’installation
1984787 SUSE LINUX Enterprise Server 12 Notes d'installation
2772999 Red Hat Enterprise Linux 8.x : Installation et configuration
2002167 Red Hat Enterprise Linux 7.x : Installation et mise à niveau
2069760 Installation et mise à niveau de SAP pour Oracle Linux 7.x
1597355 Recommandations relatives à l’espace d’échange pour Linux
2799900 Note technique centrale pour Oracle Database 19c
2171857 Oracle Database 12c : Prise en charge du système de fichiers sur Linux
1114181 Oracle Database 11g : Prise en charge du système de fichiers sur Linux
2969063 Échec de la validation du microcode dans HCMT sur Azure
3246210 Azure - HCMT échoue pendant certains tests de performances de disque

Pour plus d’informations sur l’ensemble des notes SAP pour Linux, consultez le Wiki de la communauté SAP.

Vous devez avoir une connaissance pratique de l’architecture Microsoft Azure ainsi que du déploiement et du fonctionnement des machines virtuelles Microsoft Azure. Pour plus d’informations, consultez la documentation Azure.

En règle générale, les processus d’installation et de configuration sur Windows, Linux ou SGBD sont globalement les mêmes que pour une machine virtuelle ou un système nu que vous installez en local. Les décisions relatives à l’implémentation de l’architecture et de la gestion des systèmes diffèrent sur certains points lorsque vous utilisez Azure IaaS. Ce document explique les différences spécifiques de l’architecture et de la gestion des systèmes que vous devez prendre en compte quand vous utilisez Azure IaaS.

Structure du stockage d’une machine virtuelle pour les déploiements SGBDR

Pour suivre le présent chapitre, lisez d’abord attentivement :

Pour le stockage de bloc Azure, l’utilisation de disques managés Azure est obligatoire. Pour plus d’informations sur les disques managés Azure, consultez l’article Introduction aux disques managés pour les machines virtuelles Azure.

Dans une configuration de base, nous privilégions généralement une structure de déploiement dans laquelle le système d’exploitation, le SGBD et les fichiers binaires SAP éventuels sont séparés des fichiers de base de données. Nous vous conseillons des disques Azure distincts pour :

  • Système d’exploitation (disque dur virtuel de base ou disque dur virtuel de système d’exploitation)
  • Exécutables du système de gestion de base de données
  • Exécutables SAP comme /usr/SAP
  • Fichiers de données SGBD
  • Fichiers journaux de restauration SGBD

Une configuration qui sépare ces composants en cinq volumes différents peut entraîner une plus grande résilience, car une utilisation excessive sur un volume n’interfère pas nécessairement avec l’utilisation d’autres volumes tant que le quota et les limites de stockage VM ne sont pas dépassés.

Les fichiers de données SGBD et les fichiers journaux de transactions/restaurations sont stockés dans le stockage par blocs pris en charge par Azure ou Azure NetApp Files. Azure Files ou Azure Premium Files n’est pas pris en charge comme stockage pour les données SGDB et/ou les fichiers journaux de restauration avec la charge de travail SAP. Ils sont stockés sur des disques distincts et attachés en tant que disques logiques à la machine virtuelle image du système d’exploitation Azure d’origine. Pour les déploiements Linux, différentes recommandations sont documentées. Lisez l’article Types de stockage Azure pour la charge de travail SAP sur les fonctionnalités et la prise en charge des différents types de stockage pour votre scénario. Pour SAP HANA en particulier, commencez par l’article Configurations du stockage des machines virtuelles Azure SAP HANA.

Quand vous planifiez la disposition des disques, essayez de trouver le meilleur compromis entre ces éléments :

  • Le nombre de fichiers de données.
  • Le nombre de disques qui contiennent les fichiers
  • Les quotas d’IOPS pour un même disque ou un même partage NFS.
  • Le débit de données par disque ou partage NFS.
  • Le nombre de disques supplémentaires possibles par taille de machine virtuelle
  • Le débit global de stockage ou de réseau qu’une machine virtuelle peut fournir.
  • Le temps de latence entre les différents types de stockage Azure.
  • IOPS de stockage de VM et quota de débit.
  • Quota de réseau VM si vous utilisez NFS : le trafic vers les partages NFS est décompté du quota de réseau de la machine virtuelle et PAS du quota de stockage.
  • Contrats SLA de machine virtuelle.

Azure applique un quota IOPS pour chaque disque de données ou partage NFS. Ces quotas sont différents pour les disques hébergés sur les solutions ou partages différents de stockage de bloc Azure. La latence d’E/S est également différente entre ces différents types de stockage.

Pour chaque type de machine virtuelle, vous ne pouvez attacher qu’un nombre limité de disques de données. Une autre restriction est que seuls certains types de machine virtuelle peuvent utiliser le stockage Premium, par exemple. En règle générale, vous choisissez le type de machine virtuelle à utiliser en fonction des exigences en mémoire et processeur. Vous pouvez également prendre en compte les exigences d’IOPS, de latence et de débit de disque qui sont généralement adaptées au nombre de disques ou au type des disques de stockage Premium v1. Le nombre d’IOPS et le débit à obtenir par disque peuvent déterminer le choix de la taille de disque, en particulier avec le stockage Premium v1. Avec le stockage Premium v2 ou un disque Ultra, vous pouvez sélectionner le débit et les IOPS provisionnés indépendamment de la capacité du disque.

Notes

Pour les déploiements SGBD, nous recommandons fortement le stockage Premium Azure (v1 et v2), les disques Ultra ou les partages NFS basés sur Azure NetApp Files pour les fichiers de données, les fichiers journaux de transactions ou les fichiers de restauration. Peu importe que vous vouliez déployer des systèmes dans des environnements de production ou hors production. La latence des disques HDD ou SSD standard Azure n’est acceptable pour aucun type de système de production.

Notes

Pour maximiser le contrat SLA de chaque machine virtuelle d’Azure, tous les disques attachés doivent avoir le type Stockage Premium Azure (v1 ou v2) ou disque Ultra Azure, qui comprend le VHD de base (stockage Premium Azure).

Notes

Les fichiers principaux des bases de données SAP (comme les fichiers de données et les fichiers journaux) ne peuvent pas être hébergés sur du matériel de stockage qui se trouve dans des centres de données tiers colocalisés adjacents aux centres de données Azure. Dans ce cas d’usage, le stockage fourni via les appliances logicielles hébergées sur des machines virtuelles Azure n’est pas non plus pris en charge. Pour les charges de travail de SGBD SAP, seul le stockage représenté en tant que service Azure natif est pris en charge pour les fichiers de données et les fichiers journaux de transactions des bases de données SAP en général. Les types de stockage Azure pris en charge peuvent être différents selon les SGBD. Pour plus d’informations, consultez l’article Types de stockage Azure pour une charge de travail SAP

L’emplacement des fichiers de base de données, des fichiers journaux et des fichiers de restauration ainsi que le type de stockage Azure utilisé sont dictés par les exigences en IOPS, en latence et en débit. Dans le cas particulier du stockage Premium Azure v1, pour obtenir une quantité d’IOPS suffisante, vous pouvez être obligé d’utiliser plusieurs disques ou un disque de stockage Premium plus grand. Si vous utilisez plusieurs disques, créez une bande logicielle sur les disques qui contiennent les fichiers de données ou les fichiers journaux et de restauration. Dans ce cas, les contrats SLA relatifs aux IOPS et au débit des disques de stockage Premium sous-jacents ou la limite maximale d’IOPS des disques de stockage Standard se cumulent pour la bande ainsi créée.

Si vos exigences d’IOPS dépassent ce qu’un seul VHD peut fournir, répartissez les IOPS nécessaires des fichiers de base de données sur plusieurs VHD. Le moyen le plus simple pour distribuer la charge IOPS entre les disques consiste à créer une bande logicielle sur les différents disques. Ensuite, vous placez un certain nombre de fichiers de données du SGBD SAP sur les LUN issus de la bande logicielle. Le nombre de disques dans la bande est dicté par les exigences en IOPS, en débit de disque et en volume.

Windows storage striping Windows

Nous vous recommandons d’utiliser Windows Storage Spaces pour créer des agrégats par bandes sur plusieurs disques durs virtuels Azure. Utilisez Windows Server 2012 R2 ou Windows Server 2016 au minimum.

Linux storage striping Linux

Seuls MDADM et LVM (Logical Volume Manager) sont pris en charge pour créer un RAID logiciel sur Linux. Pour plus d'informations, consultez les pages suivantes :

Pour le stockage Premium v2 et les disques Ultra, l’agrégation n’est pas nécessaire, car vous pouvez définir les IOPS et le débit de disque indépendamment de la taille du disque.

Notes

Dans la mesure où le stockage Azure conserve trois images des disques durs virtuels, il est inutile de configurer une redondance si vous utilisez des agrégats par bandes. Vous devez uniquement configurer des agrégats par bandes afin que les E/S soient distribuées entre les différents disques durs virtuels.

Disques managés ou non managés

Un compte de stockage Azure est une construction administrative qui, par ailleurs, fait également l’objet de limitations. Pour avoir des informations sur les fonctionnalités et les limitations, consultez Objectifs de performance et de scalabilité du stockage Azure. Pour le stockage Standard, n’oubliez pas qu’il y a une limite d’IOPS par compte de stockage. Reportez-vous à la ligne Taux de requêtes maximal dans l’article Objectifs de performance et de scalabilité du stockage Azure. Il y a également une limite initiale du nombre de comptes de stockage par abonnement Azure. Depuis 2017, Azure a introduit le concept des disques managés Azure, qui vous libèrent de l’administration des comptes de stockage. L’utilisation de disques managés Azure est la méthode de déploiement par défaut pour la charge de travail SAP dans Azure.

Important

Étant donné les avantages des disques managés Azure, vous devez les utiliser pour vos déploiements SGBD et SAP en général.

Si vous avez une charge de travail SAP qui n’utilise pas encore de disques managés, pour convertir les disques non managés en disques managés, consultez :

Mise en cache pour les machines virtuelles et les disques de données

Lorsque vous montez des disques sur des machines virtuelles, vous pouvez choisir de mettre ou non en cache le trafic d’E/S entre la machine virtuelle et les disques situés dans le stockage Azure.

Les recommandations qui suivent s’appliquent à ces caractéristiques d’E/S dans les environnements SGBD standard :

  • Il s’agit la plupart du temps d’une charge de travail de lecture dans les fichiers de données d’une base de données. Ces lectures sont un facteur critique des performances du système SGBD.
  • Les points de contrôle ou un flux constant donnent lieu à des écritures en rafales dans les fichiers de données. Si l’on établit une moyenne quotidienne, les écritures sont moins nombreuses que les lectures. Contrairement aux lectures à partir de fichiers de données, ces écritures sont asynchrones et ne bloquent pas les transactions utilisateur.
  • Il n’y a pratiquement pas de lectures à partir de fichiers journaux ou de fichiers de restauration. Les exceptions sont les E/S volumineuses quand vous effectuez des sauvegardes des journaux des transactions.
  • Les écritures constituent la charge principale portant sur les fichiers journaux des transactions ou de restauration. Selon la nature de la charge de travail, la taille des E/S peut aller de 4 Ko à 1 Mo, voire plus.
  • Toutes les écritures doivent être rendues persistantes sur le disque de manière fiable.

Pour le stockage Premium Azure v1, les options de mise en cache suivantes sont disponibles :

  • None
  • Lire
  • Lecture/écriture
  • Aucun + Accélérateur d’écriture, option uniquement disponible pour les machines virtuelles Azure de série M
  • Lecture + Accélérateur d’écriture, option uniquement disponible pour les machines virtuelles Azure de série M

Pour le stockage Premium v1, nous vous recommandons d’utiliser la Mise en cache de lecture pour les fichiers de données de la base de données SAP et de choisir Aucune mise en cache pour les disques des fichiers journaux.

Pour les déploiements de la série M, nous vous recommandons d’utiliser l’accélérateur d’écriture Azure uniquement pour les disques de vos fichiers journaux. Pour en savoir plus sur les restrictions et le déploiement de l’Accélérateur d’écriture Azure, consultez Activer l’Accélérateur d’écriture.

Aucune option de mise en cache n’est proposée pour le stockage Premium v2, le disque Ultra et Azure NetApp Files.

Disques Azure non persistants

Les machines virtuelles Azure fournissent des disques non persistants après le déploiement d’une machine virtuelle. Si une machine virtuelle est redémarrée, tout le contenu de ces disques est effacé. Les fichiers de données, les fichiers journaux et les fichiers de restauration ne doivent dont pas se trouver sur ces disques non persistants. Il peut exister des exceptions pour certaines bases de données, où ces disques non persistants sont parfois appropriés pour les espaces de stockage tempdb et temp.

Pour plus d’informations, consultez Understand the temporary drive on Windows VMs in Azure, qui décrit le disque temporaire sur les machines virtuelles Windows dans Azure.

Windows nonpersisted disk Windows

Sur une machine virtuelle Azure, le disque D est un disque non persistant soutenu par des disques locaux présents sur le nœud de calcul Azure. Comme le disque n’est pas persistant, toutes les modifications apportées au contenu du disque D sont perdues au redémarrage de la machine virtuelle. Les modifications incluent les fichiers stockés, les répertoires créés et les applications installées.

Linuxnonpersisted disk Linux

Les machines virtuelles Linux dans Azure montent automatiquement un disque à l’emplacement /mnt/resource. Il s’agit d’un disque non persistant soutenu par des disques locaux présents sur le nœud de calcul Azure. Comme le disque n’est pas persistant, toutes les modifications apportées au contenu de l’emplacement /mnt/resource sont perdues au redémarrage de la machine virtuelle. Les modifications incluent les fichiers stockés, les répertoires créés et les applications installées.

Résilience du Stockage Microsoft Azure

Le stockage Microsoft Azure stocke le disque dur virtuel de base, avec le système d’exploitation et les disques ou objets blob associés, sur au moins trois nœuds de stockage distincts. Ce type de stockage est appelé stockage localement redondant (LRS). Il s’agit du type de stockage par défaut pour tous les stockages dans Azure.

Il existe d’autres méthodes de redondance. Pour plus d’informations, consultez l’article Réplication de Stockage Azure.

Notes

Stockage Premium Azure v1 et v2, disque Ultra et Azure NetApp Files sont les types de stockage recommandés pour les machines virtuelles SGBD et les disques qui stockent les fichiers de base de données et les fichiers journaux/de restauration. À l’exception du stockage Premium v1, la seule méthode de redondance disponible pour ces types de stockage est LRS. Par conséquent, vous devez configurer les méthodes de base de données afin d’activer la réplication des données de base de données dans une autre région ou zone de disponibilité Azure. Les méthodes de base de données incluent SQL Server Always On, Oracle Data Guard et la réplication de système HANA.

Résilience des nœuds de machine virtuelle

Azure propose plusieurs contrats SLA différents pour les machines virtuelles. Pour plus d’informations, consultez la dernière mise à jour du SLA pour Machines virtuelles. Étant donné que la couche SGBD est essentielle à la disponibilité dans un système SAP, vous devez comprendre différents types de déploiement et événements de maintenance. Pour plus d’informations sur ces concepts, consultez Gérer la disponibilité des machines virtuelles dans Azure.

Les recommandations minimales pour les scénarios de SGBD de production avec une charge de travail SAP sont les suivantes :

  • Déployez deux machines virtuelles à l’aide du type de déploiement choisi dans la même région Azure.
  • Exécutez ces deux machines virtuelles dans le même réseau virtuel Azure et attacher des cartes réseau issues des mêmes sous-réseaux.
  • Utilisez les méthodes de base de données pour conserver un serveur de secours avec la deuxième machine virtuelle. Il peut s’agir des méthodes SQL Server Always On, Oracle Data Guard ou HANA System Replication.

Vous pouvez aussi déployer une troisième machine virtuelle dans une autre région Azure et utiliser les mêmes méthodes de base de données pour fournir un réplica asynchrone dans une autre région Azure.

Considérations relatives au réseau Azure

Dans les déploiements SAP à grande échelle, utilisez le blueprint du Centre de données virtuel Azure. Utilisez-le pour configurer votre réseau virtuel, et attribuer les autorisations et rôles réseau appropriés aux différentes parties de votre organisation.

Ces bonnes pratiques sont le résultat de milliers de déploiements clients :

  • Les réseaux virtuels sur lesquels l’application SAP est déployée n’ont pas accès à Internet.
  • Les machines virtuelles de base de données s’exécutent dans le même réseau virtuel que la couche application, séparées dans un sous-réseau différent de la couche application SAP.
  • Les machines virtuelles du réseau virtuel ont une allocation statique de l’adresse IP privée. Pour plus d’informations, consultez Types d’adresses IP et méthodes d’allocation dans Azure.
  • Les restrictions de routage à destination et à partir des machines virtuelles SGBD ne sont pas définies avec des pare-feu installés sur les machines virtuelles SGBD locales. À la place, le routage du trafic est défini avec des groupes de sécurité réseau (NSG).
  • Pour séparer et isoler le trafic à destination des machines virtuelles SGBD, attribuez des cartes réseau distinctes aux machines virtuelles. Chaque carte réseau obtient une adresse IP différente et est attribuée à un sous-réseau virtuel différent. Chaque sous-réseau a ses propres règles NSG. L’isolation ou la séparation du trafic réseau est une méthode de routage. Elle ne permet pas de définir des quotas de débit réseau.

Notes

Quand vous attribuez des adresses IP statiques dans Azure, vous devez les attribuer individuellement aux cartes réseau virtuelles. N’attribuez pas d’adresses IP statiques utilisées au sein du système d’exploitation invité à une carte réseau virtuelle. Certains services Azure, comme la Sauvegarde Azure, s’appuient sur le fait qu’au moins la carte réseau virtuelle principale dans le système d’exploitation invité est définie sur DHCP et non sur des adresses IP statiques. Pour plus d’informations, consultez Résoudre les problèmes de sauvegarde des machines virtuelles Azure. Pour attribuer plusieurs adresses IP statiques à une machine virtuelle, attribuez plusieurs cartes réseau virtuelles à une machine virtuelle.

Avertissement

Il n’est pas possible de configurer des appliances virtuelles réseau dans le chemin de communication entre l’application SAP et la couche SGBD d’un système SAP NetWeaver, Hybris ou S/4HANA basé sur SAP. Cette restriction est implémentée pour des raisons de performances et de fonctionnalités. Le chemin de communication entre la couche Application SAP et la couche SGBD doit être direct. La restriction n’inclut pas les règles NSG et règles de groupe de sécurité d’application (ASG) si ces règles ASG et NSG autorisent un chemin de communication direct. Cela comprend également le trafic vers les partages NFS qui hébergent les données SGBD et les fichiers journaux de restauration.

Voici d’autres scénarios où les appliances réseau virtuelles ne sont pas prises en charge :

Les appliances réseau virtuelles dans les chemins de communication peuvent facilement doubler la latence du réseau entre deux partenaires de communication. Elles peuvent également limiter le débit dans les chemins critiques entre la couche Application SAP et la couche SGBD. Dans certains scénarios clients, les appliances réseau virtuelles sont susceptibles de provoquer des défaillances de clusters Pacemaker Linux. Cela se produit notamment si les communications entre les nœuds de cluster Linux Pacemaker communiquent avec l’appareil SBD associé par le biais d’une appliance réseau virtuelle.

Important

Une autre conception qui n’est pas prise en charge est la séparation de la couche Application SAP et de la couche SGBD sur des réseaux virtuels Azure distincts qui ne sont pas appairés l’un avec l’autre. Nous vous recommandons de séparer la couche Application SAP et la couche SGBD en utilisant des sous-réseaux au sein d’un seul réseau virtuel Azure plutôt que plusieurs réseaux virtuels Azure.

Si vous choisissez de ne pas suivre cette recommandation et de séparer les deux couches sur des réseaux virtuels distincts, ces deux réseaux virtuels doivent être appairés.

N’oubliez pas que le trafic réseau entre deux réseaux virtuels Azure appairés engage des coûts de transfert. Un énorme volume de données de plusieurs téraoctets est échangé entre la couche Application SAP et la couche SGBD. Vous risquez donc de voir vos coûts augmenter de façon significative si la couche Application SAP et la couche SGBD sont séparées sur deux réseaux virtuels Azure appairés.

Utiliser Azure Load Balancer pour rediriger le trafic

L’emploi d’adresses IP virtuelles privées utilisées dans des fonctionnalités comme la réplication SQL Server Always On ou la réplication HANA System nécessite la configuration d’un équilibreur de charge Azure. L’équilibreur de charge utilise des ports probe pour déterminer le nœud SGBD actif et router le trafic exclusivement vers ce nœud de base de données actif.

S’il y a basculement du nœud de base de données, la reconfiguration de l’application SAP est inutile. En fait, les architectures d’application SAP les plus courantes se reconnectent à l’adresse IP virtuelle privée. Quant à l’équilibreur de charge, il répond au basculement du nœud en redirigeant le trafic envoyé à l’adresse IP virtuelle privée vers le second nœud.

Azure fournit deux références SKU d’équilibreur de charge différentes : une référence SKU de base et une référence SKU standard. En fonction des avantages de l’installation et des fonctionnalités, vous devez utiliser la référence SKU standard d’Azure Load Balancer. L’un des grands avantages de la version standard de l’équilibreur de charge est que le trafic de données ne passe pas par lui.

Un exemple de configuration d’un équilibreur de charge interne figure dans l’article Tutoriel : Configurer manuellement un groupe de disponibilité SQL Server sur des machines virtuelles Azure

Notes

Il existe des différences de comportement entre la référence SKU de base et la référence SKU standard en ce qui concerne l'accès aux adresses IP publiques. Le contournement des restrictions de la référence SKU standard pour accéder aux adresses IP publiques est décrite dans le document Connectivité des points de terminaison publics pour les machines virtuelles avec Azure Standard Load Balancer dans les scénarios de haute disponibilité SAP.

Déploiement de la supervision d’hôte

Pour une utilisation en production des applications SAP sur des machines virtuelles Azure, SAP doit pouvoir collecter des données de supervision d’hôte auprès des hôtes physiques qui exécutent les machines virtuelles Azure. Un niveau de correctif logiciel SAP HostAgent spécifique est nécessaire pour activer cette fonctionnalité dans SAPOSCOL et SAP HostAgent. Le niveau de correctif logiciel exact est indiqué dans la Note de SAP 1409604.

Pour plus d’informations sur le déploiement de composants qui fournissent des données d’hôte à SAPOSCOL et à SAP Host Agent, et sur la gestion du cycle de vie de ces composants, commencez par l’article Implémenter l’extension VM Azure pour les solutions SAP.

Étapes suivantes

Pour plus d’informations sur un système SGBD particulier, consultez :