Partager via

Déploiement SGBD de machines virtuelles SQL Server Azure pour SAP NetWeaver

  • Article

Ce document décrit les différents domaines à prendre en compte lors du déploiement de SQL Server pour une charge de travail SAP dans Azure IaaS. Comme condition préalable à ce document, vous devez avoir lu le document Considerations for Azure Virtual Machines DBMS deployment for SAP workload (Facteurs à prendre en compte pour le déploiement SGBD des machines virtuelles Azure pour la charge de travail SAP) et d’autres guides de la documentation sur la charge de travail SAP sur Azure.

Important

Ce document est consacré à la version de Windows sur SQL Server. Le protocole SAP ne prend en charge la version Linux de SQL Server avec aucun logiciel SAP. Le document ne traite pas ici de Microsoft Azure SQL Database, qui est une offre Platform as a Service (PaaS) de la plateforme Microsoft Azure. Ce document porte sur l’exécution du produit SQL Server tel qu’il existe pour les déploiements locaux dans Machines Virtuelles Azure, en tirant profit de la capacité IaaS (infrastructure as a service) d’Azure. Les capacités et fonctionnalités de base de données de ces deux offres sont différentes et ne doivent pas être confondues. Pour plus d’informations, consultez Azure SQL Database.

En général, vous devez penser à utiliser les versions de SQL Server les plus récentes pour exécuter une charge de travail SAP dans Azure IaaS. Les dernières versions de SQL Server offrent une meilleure intégration à certains des services et fonctionnalités Azure. Et elles comportent des modifications qui optimisent les opérations dans une infrastructure Azure IaaS.

La documentation générale sur SQL Server exécuté dans des machines virtuelles Azure est disponible dans les articles suivants :

Le contenu et les instructions de la documentation générale sur SQL Server dans les machines virtuelles Azure ne concernent pas seulement la charge de travail SAP. Toutefois, la documentation donne un bon aperçu des principes. Une des fonctionnalités non prises en charge pour la charge de travail SAP est, par exemple, l’utilisation du clustering FCI.

Avant de continuer, il y a certaines informations spécifiques sur SQL Server dans IaaS que vous devez connaître :

  • Prise en charge des versions SQL : même avec la note SAP #1928533 indiquant que la version minimale de SQL Server prise en charge est SQL Server 2008 R2, la fenêtre des versions SQL Server prises en charge sur Azure est également dictée par le cycle de vie de SQL Server. La maintenance étendue de SQL Server 2012 a pris fin vers le milieu de l’année 2022. Par conséquent, la version minimale actuelle des systèmes nouvellement déployés doit être SQL Server 2014. Plus la version est récente, mieux c’est. Les dernières versions de SQL Server offrent une meilleure intégration à certains des services et fonctionnalités Azure. Et elles comportent des modifications qui optimisent les opérations dans une infrastructure Azure IaaS.
  • Utilisation d’images de la Place de marché Azure : La méthode la plus rapide pour déployer une nouvelle machine virtuelle Microsoft Azure est d’utiliser une image de la Place de marché Microsoft Azure. En effet, cette plateforme propose des images qui contiennent les versions les plus récentes de SQL Server. Les images hébergeant déjà SQL Server ne peuvent pas être directement utilisées pour les applications SAP NetWeaver. En effet, le classement par défaut installé au sein de ces images correspond à celui de SQL Server, et non au classement requis par les systèmes SAP NetWeaver. Pour pouvoir utiliser ces images, suivez la procédure décrite dans le chapitre Utilisation d'images SQL Server issues de la Place de marché Microsoft Azure.
  • Prise en charge de plusieurs instances SQL Server dans une seule machine virtuelle Azure : cette méthode de déploiement est prise en charge. Cependant, soyez conscient des limitations de ressources, en particulier en matière de bande passante de réseau et de stockage du type de machine virtuelle que vous utilisez. Des informations détaillées sont disponibles dans l’articleTailles pour les machines virtuelles dans Azure. Ces limitations de quota peuvent vous empêcher d’implémenter la même architecture multi-instance que vous pouvez implémenter localement. À partir de la configuration et de l’interférence du partage des ressources disponibles dans une seule machine virtuelle, les mêmes considérations qu’à l’échelle locale doivent être prises en compte.
  • Plusieurs bases de données SAP dans une instance SQL Server sur une machine virtuelle : ce type de configuration est pris en charge. Les considérations relatives à plusieurs bases de données SAP qui partagent les ressources partagées d’une instance de SQL Server unique sont les mêmes que pour les déploiements locaux. Tenez compte des autres limites, comme le nombre de disques qui peuvent être attachés à un type VM spécifique. Ou les limites de quota de réseau et de stockage de types de machines virtuelles spécifiques Tailles pour les machines virtuelles dans Azure.

Conformément à la description générale, le système d’exploitation, les exécutables SQL Server et les exécutables SAP doivent se situer ou être installés sur des disques Azure distincts. Bien souvent, la plupart des bases de données système SQL Server ne sont pas pleinement exploitées par les charges de travail SAP NetWeaver. Néanmoins, les bases de données système de SQL Server doivent être, avec les autres répertoires SQL Server, sur un disque Azure distinct. La base de données tempdb de SQL Server doit se trouver sur le lecteur D:\ non persistant ou sur un disque distinct.

  • Avec tous les types VM certifiés SAP (voir la note SAP #1928533), les données tempdb et les fichiers journaux peuvent être placés sur le lecteur D:\ non persistant.
  • Avec des versions de SQL Server où tempdb est installé avec un fichier de données par défaut, il est recommandé d’utiliser plusieurs fichiers de données tempdb. Pour rappel, les volumes de lecteur D:\ n’ont pas la même taille et la même capacité selon le type VM. Pour connaître les tailles exactes du lecteur D:\ des différentes machines virtuelles, consultez l’article Tailles des machines virtuelles Windows dans Azure.

Ces configurations permettent à la base de données tempdb de consommer davantage d’espace et, plus important, davantage d’IOPS (opérations d’entrée/sortie par seconde) et de bande passante de stockage que ce que peut proposer le lecteur système. Le lecteur D:\ non persistant offre également une meilleure latence d’E/S et un meilleur débit. Pour déterminer la taille de base de données tempdb appropriée, vous pouvez consulter les tailles des bases de données tempdb sur les systèmes existants.

Notes

Si vous placez un fichier journal et les fichiers de données tempdb dans un dossier sur le lecteur D:\ que vous avez créé, vous devez vous assurer que le dossier existe après un redémarrage de la machine virtuelle. Comme le lecteur D:\ peut être réinitialisé après le redémarrage d’une machine virtuelle, toutes les structures de répertoires et de fichiers peuvent être effacées. La possibilité de recréer des structures de répertoires sur le lecteur D:\ avant le démarrage du service SQL Server est documentée dans cet article.

Voici un exemple de configuration VM qui exécute SQL Server avec une base de données SAP, et où les données et le fichier journal tempdb sont placés sur le lecteur D:\ et un stockage Premium Azure v1 ou v2 :

Diagram of simple VM disk configuration for SQL Server

Le diagramme affiche un cas simple. Comme l’évoque l’article Facteurs à prendre en compte pour le déploiement SGBD des machines virtuelles Azure pour la charge de travail SAP, le type, le nombre et la taille des disques du stockage Azure dépendent de différents facteurs. Cependant, en général, nous recommandons :

  • Pour les déploiements plus petits et intermédiaires, utilisez un grand volume qui contient les fichiers de données SQL Server. La raison de cette configuration est qu’il est plus facile de gérer différentes charges de travail d’E/S quand les fichiers de données SQL Server n’ont pas le même espace libre. Alors que dans les grands déploiements, en particulier les déploiements où le client a effectué une migration de base de données hétérogène vers SQL Server dans Azure, nous avons utilisé des disques distincts pour distribuer les fichiers de données. Ce type d’architecture fonctionne seulement quand chaque disque a le même nombre de fichiers de données, que tous les fichiers de données ont la même taille et ont à peu près le même espace libre.
  • D’utiliser le lecteur D:\ pour tempdb tant que les performances sont suffisantes. Si la charge de travail générale est limitée en performances par tempdb qui se trouve sur le lecteur D:\, vous devez déplacer tempdb sur un disque de stockage Premium Azure v1 ou v2 ou un disque Ultra, comme recommandé dans cet article.

Le mécanisme de remplissage proportionnel de SQL Server distribue les lectures et les écritures entre tous les fichiers de données de manière égale, à condition que tous les fichiers de données SQL Server aient la même taille et le même espace libre. SAP sur SQL Server offre les meilleures performances lorsque les lectures et les écritures sont distribuées de manière égale entre tous les fichiers de données disponibles. Si une base de données a trop peu de fichiers de données ou si les fichiers de données existants sont fortement déséquilibrés, la meilleure méthode est de faire une exportation et une importation R3load. Une exportation et une importation R3load impliquent un temps d’arrêt et doivent être effectuées uniquement si un problème de performance évident a besoin d’être résolu. Si les tailles des fichiers de données sont modérément différentes, augmentez toutes les tailles des fichiers de données pour qu’elles soient identiques. De cette façon SQL Server peut rééquilibrer les données au fil du temps. SQL Server augmente automatiquement la taille des fichiers de données de manière égale si l’indicateur de trace 1117 est défini, ou si SQL Server 2016 ou version ultérieure est utilisé.

Remarque relative aux machines virtuelles de la série M

Pour une machine virtuelle Azure de la série M, la latence d’écriture dans le journal de transactions peut être réduite, par rapport aux performances du stockage Premium Azure v1, avec l’utilisation de l’accélérateur d’écriture Azure. Si la latence fournie par le stockage Premium v1 limite la scalabilité de la charge de travail SAP, vous pouvez activer l’accélérateur d'écriture sur le disque qui stocke le fichier journal des transactions SQL Server. Les détails peuvent être consultés dans le document Accélérateur des écritures. L’accélérateur d’écriture Azure ne fonctionne pas avec le stockage Premium Azure v2 et les disques Ultra. Dans les deux cas, la latence est meilleure que celle du stockage Premium Azure v1.

Formatage des disques

Dans le cas de SQL Server, la taille du bloc NTFS des disques contenant des données et des fichiers journaux SQL Server doit être de 64 ko. Il est inutile de formater le lecteur D:\. En effet, ce lecteur est déjà mis en forme.

Pour que la restauration ou la création de bases de données n’initialise pas les fichiers de données en supprimant le contenu des fichiers, vérifiez que le contexte utilisateur dans lequel s’exécute le service SQL Server a le droit d’utilisateur Effectuer des tâches de maintenance de volume. Pour plus d’informations, consultez Initialisation instantanée des fichiers de base de données.

SQL Server 2014 et ultérieur : Stockage des fichiers de base de données directement dans le Stockage Blob Azure

Les versions SQL Server 2014 et ultérieures permettent de stocker les fichiers de base de données directement dans le stockage d’objets blob Azure, sans qu’il soit nécessaire d’utiliser un disque VHD pour « envelopper » ces fichiers. Cette fonctionnalité avait pour but de résoudre les lacunes du stockage de bloc Azure il y a des années. De nos jours, il n’est pas recommandé d’utiliser cette méthode de déploiement. Il vaut mieux choisir le stockage Premium Azure v1, le stockage Premium v2 ou un disque Ultra. Dépendant des exigences.

Fonctionnalité d’extension du pool de mémoires tampons de SQL Server 2014

SQL Server 2014 propose une nouvelle fonctionnalité appelée extension du pool de mémoires tampons. Cette fonctionnalité, bien que testée sous la charge de travail SAP sur Azure, n’a pas apporté d’amélioration dans l’hébergement de la charge de travail. Par conséquent, elle ne doit pas être utilisée

Considérations relatives à la sauvegarde/restauration pour SQL Server

Quand vous déployez SQL Server sur Azure, vous devez passer en revue votre architecture de sauvegarde. Même si le système n’est pas un système de production, la base de données SAP hébergée par SQL Server doit être sauvegardée régulièrement. Comme Azure Storage conserve trois images, la sauvegarde joue désormais un rôle moins important en matière de compensation des pannes du stockage. La raison principale du maintien d’un plan de sauvegarde et de récupération approprié réside davantage dans le fait que vous pouvez compenser les erreurs logiques/manuelles en fournissant des fonctionnalités de récupération jusqu’à une date et heure. Le but est d’utiliser les sauvegardes pour restaurer la base de données à un certain point dans le temps ou d’utiliser les sauvegardes dans Azure pour amorcer un autre système en copiant la base de données existante.

Il existe plusieurs façons de sauvegarder et de restaurer des bases de données SQL Server dans Azure. Pour plus d’informations, lisez le document Sauvegarde et restauration de SQL Server sur des machines virtuelles Azure. Cet article présente plusieurs possibilités.

Utilisation d’une image SQL Server issue de la Place de marché Microsoft Azure

Dans la Place de marché Azure, Microsoft propose des machines virtuelles qui contiennent déjà des versions de SQL Server. Pour les clients SAP qui requièrent des licences pour SQL Server et Windows, l’utilisation de ces images peut être l’occasion de répondre aux besoins en termes de licences, en configurant des machines virtuelles déjà dotées de SQL Server. Pour pouvoir utiliser ces images pour SAP, vous devez tenir compte des considérations suivantes :

  • Les versions de SQL Server autres que les versions d’évaluation nécessitent des frais d’acquisition plus élevés que les machines virtuelles « Windows uniquement » qui sont déployées à partir de la Place de marché Azure. Pour comparer les prix, consultez Tarification Machines virtuelles Windows et Tarification Machines virtuelles SQL Server Entreprise.
  • Vous pouvez uniquement utiliser les versions de SQL Server qui sont prises en charge par SAP.
  • Le classement de l’instance SQL Server qui est installée dans les machines virtuelles proposées par la Place de marché ne correspond pas à celui que nécessite SAP NetWeaver pour l’instance SQL Server. Toutefois, vous pouvez modifier ce classement, en suivant les instructions de la section suivante.

Modification du classement SQL Server d’une machine virtuelle Microsoft Windows/SQL Server

Étant donné que les images SQL Server figurant dans la Place de marché Microsoft Azure ne sont pas configurées pour utiliser le classement exigé par les applications SAP NetWeaver, elles doivent être modifiées immédiatement après le déploiement. Pour SQL Server, cette modification de classement peut être exécutée en suivant la procédure ci-après dès que la machine virtuelle est déployée et qu’un administrateur peut se connecter à cette dernière :

  • Ouvrez une fenêtre de commande Windows en tant qu’administrateur.
  • Remplacez le répertoire par celui-ci : C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\SQLServer2012.
  • Exécutez la commande : Setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=<local_admin_account_name> /SQLCOLLATION=SQL_Latin1_General_Cp850_BIN2
    • <local_admin_account_name> correspond au compte qui a été défini en tant que compte d’administrateur lors du déploiement de la machine virtuelle pour la première fois, via la galerie.

Le processus doit prendre quelques minutes seulement. Pour vérifier que le résultat attendu a été obtenu, effectuez les étapes suivantes :

  • Ouvrez SQL Server Management Studio.
  • Ouvrez une fenêtre Requête.
  • Exécutez la commande sp_helpsort dans la base de données MASTER de SQL Server.

Le résultat doit être similaire à ce qui suit :

Latin1-General, binary code point comparison sort for Unicode Data, SQL Server Sort Order 40 on Code Page 850 for non-Unicode Data

Si le résultat est différent, ARRÊTEZ immédiatement le déploiement et investiguez la raison pour laquelle la commande n’a pas fonctionné comme prévu. Le déploiement d’applications SAP NetWeaver sur une instance SQL Server avec des pages de codes SQL Server autres que celle indiquée n’est PAS pris en charge dans les déploiements NetWeaver.

Solutions SQL Server haute disponibilité pour SAP dans Azure

En utilisant SQL Server dans les déploiements IaaS Azure pour SAP, plusieurs méthodes sont à votre disposition pour déployer la couche SGBD à haute disponibilité. Azure fournit différents contrats SLA de disponibilité pour chaque machine virtuelle en utilisant différents stockages de bloc Azure, une paire de machines virtuelles déployées dans un groupe à haute disponibilité Azure ou une paire de machines virtuelles déployées dans des zones de disponibilité Azure. Pour les systèmes de production, nous vous attendons à déployer une paire de machines virtuelles au sein d’un groupe de machines virtuelles identiques avec une orchestration flexible entre deux zones de disponibilité. Pour plus d’informations, consultez la comparaison des différents types de déploiement pour la charge de travail SAP. Une machine virtuelle exécute l’instance SQL Server active. L’autre machine virtuelle exécute l’instance passive

Clustering de SQL Server à l’aide du serveur de fichiers avec Scale-out de Windows ou d’un disque partagé Azure

Avec Windows Server 2016, Microsoft a introduit les espaces de stockage direct. La prise en charge du clustering FCI de SQL Server dépend du déploiement des espaces de stockage direct. Azure propose également des disques partagés Azure qui peuvent être utilisés pour le clustering Windows. Pour la charge de travail SAP, nous ne prenons pas en charge ces options de haute disponibilité.

Copie des journaux de transaction SQL Server

La copie des journaux de transaction SQL Server est une des fonctionnalités de haute disponibilité. Si la résolution de noms des machines virtuelles participant à la configuration HA fonctionne normalement, il n’y a aucun problème. La configuration dans Azure ne diffère pas de la configuration locale concernant la copie des journaux de transaction et les principes qui l’entourent. Pour plus d’informations sur la copie des journaux de transaction SQL Server, consultez l’article À propos de la copie des journaux de transaction (SQL Server).

La fonctionnalité de copie des journaux de transaction de SQL Server a été rarement utilisée dans Azure pour atteindre la haute disponibilité dans une région Azure. Toutefois, dans les scénarios suivants, les clients SAP utilisaient la copie des journaux de transaction avec succès avec Azure :

  • Scénarios de récupération d’urgence d’une région Azure dans une autre région Azure.
  • Configuration de la reprise d’activité après sinistre à partir d’un environnement local dans une région Azure.
  • Scénarios de basculement à partir d’un environnement local vers Azure. Dans ces cas, la copie des journaux de transaction est utilisée pour synchroniser le nouveau déploiement de SGBD dans Azure avec le système de production en cours en local. Au moment du basculement, la production est arrêtée, et il convient de vérifier que les dernières sauvegardes des journaux de transactions ont été transférées vers le déploiement SGBD Azure. Le déploiement SGBD Azure est ouvert pour la production.

SQL Server AlwaysOn

Comme Always On est pris en charge pour les systèmes SAP locaux (voir la note SAP #1772688), il est pris en charge en association avec SAP dans Azure. Vous devez être particulièrement attentif quand vous déployez l’écouteur de groupe de disponibilité SQL Server (à ne pas confondre avec le groupe à haute disponibilité Azure). Certaines étapes d’installation différentes sont nécessaires.

Lors de l’utilisation de l’écouteur de groupe de disponibilité, tenez compte des considérations suivantes :

  • L’utilisation de l’écouteur de groupe de disponibilité n’est possible que sur un système Windows Server 2012 ou version ultérieure, utilisé en tant que SE invité de la machine virtuelle. Pour Windows Server 2012, vérifiez que la mise à jour permettant d’activer les écouteurs de groupe de disponibilité SQL Server sur Windows Server 2008 R2 et les machines virtuelles Microsoft Azure basées sur Windows Server 2012 a été appliquée.
  • Pour Windows Server 2008 R2, ce correctif n’existe pas. Dans ce cas, Always On doit être utilisé de la même manière que la mise en miroir de bases de données. En spécifiant un partenaire de basculement dans la chaîne de connexion (avec le paramètre SAP default.pfl dbs/mss/server - voir la note SAP #965908).
  • Quand vous utilisez un écouteur de groupe de disponibilité, vous devez connecter les machines virtuelles de base de données à un équilibreur de charge dédié. Vous devez attribuer des adresses IP statiques aux interfaces réseau des machines au sein de la configuration Always On (la définition d’une adresse IP statique est décrite dans cet article). Les adresses IP statiques comparées à DHCP empêchent l’attribution de nouvelles adresses IP si les deux machines virtuelles sont arrêtées.
  • La création d’une configuration de cluster WSFC requiert certaines étapes spécifiques lorsque ce cluster doit se voir affecter une adresse IP spécifique, car la fonctionnalité actuelle d’Azure affecte au nom du cluster la même adresse IP que celle du nœud sur lequel le cluster est créé. Ce comportement signifie que l’attribution d’une adresse IP différente au cluster doit faire l’objet d’une étape manuelle.
  • L’écouteur de groupe de disponibilité va être créé dans Azure avec les points de terminaison TCP/IP qui sont affectés aux machines virtuelles exécutant les réplicas principaux et secondaires du groupe de disponibilité.
  • Il peut être nécessaire de sécuriser ces points de terminaison avec des ACL.

Documentation détaillée sur le déploiement de la solution Always On avec SQL Server sur des machines virtuelles Azure :

Notes

En lisant la présentation des groupes de disponibilité SQL Server Always On sur des machines virtuelles Azure, vous allez découvrir l’écouteur DNN (Direct Network Name) de SQL Server. Cette nouvelle fonctionnalité a été introduite avec SQL Server 2019 CU8. Cette nouvelle fonctionnalité permet d’utiliser un équilibreur de charge Azure qui gère l’adresse IP virtuelle de l’écouteur de groupe de disponibilité obsolète.

SQL Server Always On est la fonctionnalité de récupération d’urgence et haute disponibilité la plus couramment utilisée dans Azure pour les déploiements de charge de travail SAP. La plupart des clients utilisent Always On pour la haute disponibilité au sein d’une seule région Azure. Si le déploiement est limité à deux nœuds uniquement, vous avez deux possibilités pour la connectivité :

  • Utilisation de l’écouteur de groupe de disponibilité. Avec l’écouteur de groupe de disponibilité, vous devez déployer un équilibreur de charge Azure.
  • Avec SQL Server 2016 SP3, SQL Server 2017 CU 25 ou SQL Server 2019 CU8, ou des versions plus récentes de SQL Server sur Windows Server 2016 ou version ultérieure, vous pouvez utiliser l’écouteur DNN (Direct Network Name) à la place d’un équilibreur de charge Azure. Un DNN élimine la nécessité d’utiliser un équilibreur de charge Azure.

L’utilisation des paramètres de connectivité de la mise en miroir de bases de données SQL Server doit être envisagée seulement pour investiguer les problèmes liés aux deux autres méthodes. Dans ce cas, vous devez configurer la connectivité des applications SAP d’une manière où les deux noms de nœud sont désignés. Les détails précis de cette configuration côté SAP sont documentés dans la note SAP n°965908. Si vous utilisez cette option, vous n’avez pas besoin de configurer un écouteur de groupe de disponibilité Sans équilibreur de charge Azure, vous pouvez investiguer les problèmes de ces composants. Cependant, souvenez-vous que cette option fonctionne uniquement si vous limitez votre groupe de disponibilité pour couvrir deux instances.

Certains clients utilisent la fonctionnalité SQL Server Always On pour la reprise d’activité entre régions Azure. Plusieurs clients utilisent également la possibilité d’effectuer des sauvegardes à partir d’un réplica secondaire.

SQL Server Transparent Data Encryption

De nombreux clients utilisent Transparent Data Encryption (TDE) sur SQL Server quand ils déploient leurs bases de données SQL Server SAP sur Azure. La fonctionnalité SQL Server TDE est entièrement prise en charge par SAP (voir la note SAP n°1380493).

Application de SQL Server TDE

Dans les cas où vous effectuez une migration hétérogène à partir d’un autre système SGBD, qui s’exécute localement, vers Windows/SQL Server exécuté dans Azure, vous devez créer votre base de données cible vide dans SQL Server à l’avance. Ensuite, vous appliquez la fonctionnalité SQL Server TDE sur cette base de données vide. La raison pour laquelle vous souhaitez effectuer cette procédure dans cette séquence est que le processus de chiffrement de la base de données vide peut prendre beaucoup de temps. Les processus d’importation SAP importent ensuite les données dans la base de données chiffrée pendant la phase de temps d’arrêt. Le traitement de l’importation dans une base de données chiffrée a un impact sur le temps plus faible que le chiffrement de la base de données après la phase d’exportation au cours du temps d’arrêt. Des expériences ont été négatives lors de la tentative d’application du chiffrement TDE avec charge de travail SAP exécutée sur la base de données. Nous vous recommandons donc de traiter le déploiement de TDE comme une activité devant être effectuée avec une charge de travail SAP faible ou nulle sur la base de données particulière. À partir de SQL Server 2016, vous pouvez arrêter et reprendre l’analyse TDE qui effectue le chiffrement initial. Le document Transparent Data Encryption (TDE) décrit la commande et les détails.

Dans les cas où vous déplacez des bases de données SQL Server SAP d’un environnement local vers Azure, il est recommandé de vérifier sur quelle infrastructure vous pouvez obtenir le plus rapidement le chiffrement appliqué. Dans ce cas, gardez ces faits à l’esprit :

  • Vous ne pouvez pas définir le nombre de threads utilisés pour appliquer le chiffrement de données à la base de données. Le nombre de threads dépend principalement du nombre de volumes de disque sur lesquels les fichiers journaux et les fichiers de données SQL Server sont distribués. Cela signifie que plus les volumes sont distincts (lettres de lecteur), plus les threads sont engagés en parallèle pour effectuer le chiffrement. Une telle configuration est en légère contradiction avec la suggestion de configuration de disque indiquée plus haut, préconisant la création d’un ou de quelques espaces de stockage pour les fichiers de base de données SQL Server sur des machines virtuelles Azure. Une configuration avec peu de volumes entraînerait l’exécution du chiffrement par peu de threads. Un chiffrement à un seul thread lit les étendues de 64 ko, les chiffre, puis écrit un enregistrement dans le fichier journal de transactions, ce qui indique que l’étendue a été chiffrée. Par conséquent, la charge sur le journal des transactions est modérée.
  • Dans les versions antérieures de SQL Server, la compression de sauvegarde n’était plus efficace lorsque vous aviez chiffré votre base de données SQL Server. Ce comportement pouvait se transformer en problème si vous envisagiez de chiffrer votre base de données SQL Server en local, puis de copier une sauvegarde dans Azure pour restaurer la base de données dans Azure. La compression de sauvegarde SQL Server permet d’obtenir un taux de compression de facteur 4.
  • SQL Server 2016 introduit de nouvelles fonctionnalités qui permettent de compresser la sauvegarde des bases de données chiffrées de manière efficace. Pour plus d’informations, consultez ce blog.

Utilisation d’Azure Key Vault

Azure propose le service Key Vault pour stocker les clés de chiffrement. Parallèlement, SQL Server propose un connecteur pour utiliser Azure Key Vault comme magasin pour les certificats TDE.

Vous trouverez plus d’informations sur l’utilisation d’Azure Key Vault pour SQL Server TDE dans les articles suivants :

Important

Quand vous utilisez SQL Server TDE, notamment avec Azure Key Vault, nous vous recommandons d’utiliser les derniers correctifs de SQL Server 2014, SQL Server 2016 et SQL Server 2017. En effet, des optimisations et correctifs ont été appliqués au code suite aux commentaires de clients. À titre d’exemple, consultez l’article de la Base de connaissances KBA n°4058175.

Configurations de déploiement minimales

Dans cette section, nous vous suggérons un ensemble de configurations minimales pour différentes tailles de bases de données sous la charge de travail SAP. Il est trop difficile d’évaluer si ces tailles correspondent à votre charge de travail spécifique. Dans certains cas, nous pouvons être généreux en mémoire par rapport à la taille de la base de données. De l’autre côté, le dimensionnement du disque peut être trop faible pour certaines charges de travail. Par conséquent, ces configurations doivent être traitées pour ce qu’elles sont. Ce sont des configurations qui doivent vous donner un point de départ. Configurations à ajuster selon votre charge de travail spécifique et vos exigences de rentabilité.

Voici un exemple de configuration pour une petite instance SQL Server avec une taille de base de données entre 50 Go et 250 Go :

Configuration la machine virtuelle du SGBD Commentaires
Type de machine virtuelle E4s_v3/v4/v5 (4 vCPU/32 Gio RAM)
Mise en réseau accélérée Activer
Version de SQL Server SQL Server 2019 ou plus récent
Nb de fichiers de données 4
Nb de fichiers journaux 1
Nb de fichiers de données temp 4 ou valeur par défaut à partir de SQL Server 2016
Système d’exploitation Windows Server 2019 ou plus récent
Agrégation de disques Espaces de stockage si vous le souhaitez
Système de fichiers NTFS
Taille de bloc de format 64 Ko
Nombre et type de disques de données Stockage Premium v1 : 2 x P10 (RAID0)
Stockage Premium v2 : 2 x 150 Gio (RAID0) - IOPS et débit par défaut		 Cache = Lecture seule pour le stockage Premium v1
Nombre et type de disques de données Stockage Premium v1 : 1 x P20
Stockage Premium v2 : 1 x 128 Gio - IOPS et débit par défaut		 Cache = AUCUN
Paramètre de mémoire maximale SQL Server 90 % de RAM physique En supposant une instance unique

Voici un exemple de configuration pour une petite instance SQL Server avec une taille de base de données entre 250 Go et 750 Go, comme un petit système SAP Business Suite :

Configuration la machine virtuelle du SGBD Commentaires
Type de machine virtuelle E16s_v3/v4/v5 (16 vCPU/128 Gio RAM)
Mise en réseau accélérée Activer
Version de SQL Server SQL Server 2019 ou plus récent
Nb de fichiers de données 8
Nb de fichiers journaux 1
Nb de fichiers de données temp 8 ou valeur par défaut à partir de SQL Server 2016
Système d’exploitation Windows Server 2019 ou plus récent
Agrégation de disques Espaces de stockage si vous le souhaitez
Système de fichiers NTFS
Taille de bloc de format 64 Ko
Nombre et type de disques de données Stockage Premium v1 : 4 x P20 (RAID0)
Stockage Premium v2 : 4 x 100 Gio - 200 Gio (RAID0) - IOPS par défaut et débit supplémentaire de 25 Mo/s par disque		 Cache = Lecture seule pour le stockage Premium v1
Nombre et type de disques de données Stockage Premium v1 : 1 x P20
Stockage Premium v2 : 1 x 200 Gio - IOPS et débit par défaut		 Cache = AUCUN
Paramètre de mémoire maximale SQL Server 90 % de RAM physique En supposant une instance unique

Voici un exemple de configuration pour une instance SQL Server moyenne avec une taille de base de données entre 750 Go et 2 000 Go, comme un système SAP Business Suite moyen :

Configuration la machine virtuelle du SGBD Commentaires
Type de machine virtuelle E64s_v3/v4/v5 (64 vCPU/432 Gio RAM)
Mise en réseau accélérée Activer
Version de SQL Server SQL Server 2019 ou plus récent
Nombre d’unités de données 16
Nombre d’unités de journaux 1
Nb de fichiers de données temp 8 ou valeur par défaut à partir de SQL Server 2016
Système d’exploitation Windows Server 2019 ou plus récent
Agrégation de disques Espaces de stockage si vous le souhaitez
Système de fichiers NTFS
Taille de bloc de format 64 Ko
Nombre et type de disques de données Stockage Premium v1 : 4 x P30 (RAID0)
Stockage Premium v2 : 4 x 250 Gio - 500 Gio - plus 2 000 IOPS et 75 Mo/sec de débit par disque		 Cache = Lecture seule pour le stockage Premium v1
Nombre et type de disques de données Stockage Premium v1 : 1 x P20
Stockage Premium v2 : 1 x 400 Gio - IOPS et 75 Mo/s de débit supplémentaire par défaut		 Cache = AUCUN
Paramètre de mémoire maximale SQL Server 90 % de RAM physique En supposant une instance unique

Voici un exemple de configuration pour une grande instance SQL Server avec une taille de base de données entre 2 000 Go et 4 000 Go, comme un système SAP Business Suite plus grand :

Configuration la machine virtuelle du SGBD Commentaires
Type de machine virtuelle E96(d)s_v5 (96 vCPU/672 Gio RAM)
Mise en réseau accélérée Activer
Version de SQL Server SQL Server 2019 ou plus récent
Nombre d’unités de données 24
Nombre d’unités de journaux 1
Nb de fichiers de données temp 8 ou valeur par défaut à partir de SQL Server 2016
Système d’exploitation Windows Server 2019 ou plus récent
Agrégation de disques Espaces de stockage si vous le souhaitez
Système de fichiers NTFS
Taille de bloc de format 64 Ko
Nombre et type de disques de données Stockage Premium v1 : 4 x P30 (RAID0)
Stockage Premium v2 : 4 x 500 Gio - 800 Gio - plus 2500 IOPS et 100 Mo/sec de débit par disque		 Cache = Lecture seule pour le stockage Premium v1
Nombre et type de disques de données Stockage Premium v1 : 1 x P20
Stockage Premium v2 : 1 x 400 Gio - plus 1 000 IOPS et 75 Mo/sec de débit supplémentaire		 Cache = AUCUN
Paramètre de mémoire maximale SQL Server 90 % de RAM physique En supposant une instance unique

Voici un exemple de configuration pour une grande instance SQL Server avec une taille de base de données de plus de 4 To, comme un grand système SAP Business Suite utilisé de manière globale :

Configuration la machine virtuelle du SGBD Commentaires
Type de machine virtuelle Série M (1,0 à 4,0 To de RAM)
Mise en réseau accélérée Activer
Version de SQL Server SQL Server 2019 ou plus récent
Nombre d’unités de données 32
Nombre d’unités de journaux 1
Nb de fichiers de données temp 8 ou valeur par défaut à partir de SQL Server 2016
Système d’exploitation Windows Server 2019 ou plus récent
Agrégation de disques Espaces de stockage si vous le souhaitez
Système de fichiers NTFS
Taille de bloc de format 64 Ko
Nombre et type de disques de données Stockage Premium v1 : 4+ x P40 (RAID0)
Stockage Premium v2 : 4+ x 1 000 Gio - 4 000 Gio - plus 4 500 IOPS et 125 Mo/sec de débit par disque		 Cache = Lecture seule pour le stockage Premium v1
Nombre et type de disques de données Stockage Premium v1 : 1 x P30
Stockage Premium v2 : 1 x 500 Gio - plus 2 000 IOPS et 125 Mo/s de débit		 Cache = AUCUN
Paramètre de mémoire maximale SQL Server 90 % de RAM physique En supposant une instance unique

Par exemple, cette configuration est celle de la machine virtuelle SGBD d’une instance SAP Business Suite sur SQL Server. Cette machine virtuelle héberge la base de données de 30 To de la seule instance SAP Business Suite globale d’une entreprise internationale avec un chiffre d’affaires annuel de plus de 200 milliards de dollars et plus de 200 000 employés à temps plein. Le système exécute tous les processus de traitement financier, de vente et de distribution, ainsi que bien d’autres processus métier dans différents domaines, notamment les fiches de paie de la zone Amérique du Nord. Le système s’exécute dans Azure depuis début 2018 avec des machines virtuelles Azure de la série M comme machines virtuelles SGBD. Pour la haute disponibilité, le système utilise Always On avec un réplica synchrone dans une autre zone de disponibilité de la même région Azure et un autre réplica asynchrone dans une autre région Azure. La couche application NetWeaver est déployée sur des machines virtuelles Ev4.

Configuration la machine virtuelle du SGBD Commentaires
Type de machine virtuelle M192dms_v2 (192 vCPU/4 196 Gio RAM)
Mise en réseau accélérée activé
Version de SQL Server SQL Server 2019
Nb de fichiers de données 32
Nb de fichiers journaux 1
Nb de fichiers de données temp 8
Système d’exploitation Windows Server 2019
Agrégation de disques Espaces de stockage
Système de fichiers NTFS
Taille de bloc de format 64 Ko
Nombre et type de disques de données Stockage Premium v1 : 16 x P40 Cache = Lecture seule
Nombre et type de disques de données Stockage Premium v1 : 1 x P60 Utilisation de l’accélérateur d’écriture
Nb et type de disques tempdb Stockage Premium v1 : 1 x P30 Aucune mise en cache
Paramètre de mémoire maximale SQL Server 90 % de RAM physique

Résumé général : SQL Server pour SAP dans Azure

Ce guide offre de nombreuses recommandations. Nous vous invitons à les parcourir plusieurs fois avant de planifier votre déploiement Azure. Cependant, de manière générale, vous devez suivre les principales recommandations générales propres à la fonction SGBD sur Azure :

  1. Utilisez la dernière version SGBD, comme SQL Server 2019, qui a le plus d’avantages dans Azure.
  2. Planifiez soigneusement votre paysage système SAP dans Azure pour équilibrer la disposition des fichiers de données et les restrictions Azure :
    • Évitez d’utiliser un trop grand nombre de disques. Cependant, vous devez en configurer suffisamment pour atteindre le nombre d’E/S par seconde nécessaire.
      • N’effectuez une agrégation par bandes que si vous devez obtenir un débit supérieur.
  3. N’installez jamais de logiciels et ne placez jamais de fichiers qui nécessitent une persistance sur le lecteur D:\, car il n’est pas permanent. Tout ce qui est sur ce lecteur n’est pas conservé après le redémarrage de Windows ou de la machine virtuelle.
  4. Utilisez la solution de haute disponibilité/récupération d’urgence de votre fournisseur SGBD (système de gestion de base de données) pour répliquer les données des bases de données.
  5. Utilisez toujours la fonction de résolution de noms ; ne vous fiez pas aux adresses IP.
  6. À l’aide de SQL Server TDE, appliquez les derniers correctifs de SQL Server.
  7. Veillez à recourir à des images SQL Server de Microsoft Azure Marketplace. Si vous utilisez le serveur SQL numéro un, vous devez modifier le classement de l’instance avant d’installer un système SAP NetWeaver sur ce serveur.
  8. Installez et configurez la surveillance d'hôte SAP pour Azure comme décrit dans le Guide de déploiement.

Étapes suivantes

Lire l’article