Mettre en cluster une instance SAP ASCS/SCS sur un cluster de basculement Windows en utilisant un disque partagé dans Azure
Windows
Le clustering de basculement Windows Server (WSFC) est la base d’une installation SAP ASCS/SCS haute disponibilité (HA) et de systèmes de gestion de base de données (SGBD) dans Windows.
Un cluster de basculement est un groupe de 1 + n serveurs indépendants (nœuds) qui fonctionnent ensemble pour accroître la disponibilité des applications et des services. Si une défaillance de nœud se produit, WSFC calcule le nombre de défaillances qui peuvent se produire sans que le cluster ne perde son intégrité, de sorte que les applications et les services puissent être fournis. Vous pouvez choisir parmi différents modes de quorum pour obtenir un clustering de basculement.
Prérequis
Avant de commencer les tâches de cet article, consultez l’article Architecture et scénarios de haute disponibilité pour SAP NetWeaver.
Clustering de basculement Windows Server dans Azure
WSFC avec des machines virtuelles (VM) Azure nécessite des étapes de configuration supplémentaires. Quand vous créez un cluster, vous devez définir plusieurs adresses IP et noms d’hôtes virtuels pour l’instance SAP ASCS/SCS.
Résolution de noms dans Azure et nom d’hôte virtuel du cluster
La plateforme cloud Azure ne permet pas de configurer des adresses IP virtuelles telles que des adresses IP flottantes. Vous avez besoin d’une autre solution pour configurer une adresse IP virtuelle afin d’atteindre la ressource de cluster dans le cloud.
Le service Azure Load Balancer fournit un équilibreur de charge interne pour Azure. Avec l’équilibreur de charge interne, les clients atteignent le cluster via son adresse IP virtuelle.
Déployez l’équilibreur de charge interne dans le groupe de ressources qui contient les nœuds de cluster. Ensuite, configurez toutes les règles de réacheminement de port nécessaires en utilisant les ports de sondage de l’équilibreur de charge interne. Les clients peuvent se connecter avec le nom d’hôte virtuel. Le serveur DNS résout l’adresse IP du cluster et l’équilibrage de charge interne gère le réacheminement de port vers le nœud actif du cluster.
Haute disponibilité SAP ASCS/SCS avec des disques partagés de cluster
Dans Windows, une instance SAP ASCS/SCS contient des services SAP centraux, le serveur de messages SAP, des processus de serveur de mise en file d’attente et des fichiers d’hôte global SAP. Les fichiers d’hôte global SAP stockent les fichiers centraux pour l’ensemble du système SAP.
Une instance SAP ASCS/SCS inclut les composants suivants :
Services centraux SAP :
- Deux processus (pour un serveur de messages et un serveur d’empilage) et un nom d’hôte virtuel ASCS/SCS utilisé pour accéder aux deux processus
- Structure de fichiers : S:\usr\sap\<SID>\ASCS/SCS<numéro d’instance>
Fichiers d’hôte global SAP :
Structure de fichiers : S:\usr\sap\<SID>\SYS...
Le partage de fichiers sapmnt, qui autorise l’accès à ces fichiers S:\usr\sap\<SID>\SYS... en utilisant le chemin UNC suivant :
\\<nom d’hôte virtuel ASCS/SCS>\sapmnt\<SID>\SYS...
Dans un paramètre de haute disponibilité, vous mettez en cluster les instances SAP ASCS/SCS. Vous utilisez des disques partagés de cluster (lecteur S dans l’exemple de cet article) pour placer les fichiers SAP ASCS/SCS et d’hôte global SAP.
Avec une architecture ERS1 (Enqueue Replication Server 1) :
- Le même nom d’hôte virtuel ASCS/SCS est utilisé pour accéder aux processus du serveur de messages et du serveur d’empilage SAP, en plus des fichiers d’hôte global SAP via le partage de fichiers sapmnt.
- Le même disque partagé de cluster (lecteur S) est partagé entre eux.
Avec l’architecture ERS2 (Enqueue Replication Server 2) :
- Le même nom d’hôte virtuel ASCS/SCS est utilisé pour accéder au processus du serveur de messages SAP, en plus des fichiers d’hôte global SAP via le partage de fichiers sapmnt.
- Le même disque partagé de cluster (lecteur S) est partagé entre eux.
- Il existe un nom d’hôte virtuel ERS distinct pour accéder au processus du serveur d’empilage.
Disques partagés et ERS (Enqueue Replication Server)
Les disques partagés sont pris en charge avec une architecture ERS1, où l’instance ERS1 :
- N’est pas mise en cluster.
- Utilise un nom
localhost. - Est déployée sur des disques locaux sur chacun des nœuds de cluster.
Les disques partagés sont également pris en charge avec une architecture ERS2, où l’instance ERS2 :
- Est mise en cluster.
- Utilise un nom d’hôte virtuel ou réseau dédié.
- L’adresse IP du nom d’hôte virtuel ERS doit être configurée sur un équilibreur de charge interne Azure, en plus de l’adresse IP (A)SCS.
- Est déployée sur des disques locaux sur chacun des nœuds en cluster. Il n’est donc pas nécessaire d’utiliser un disque partagé.
Pour plus d’informations sur ERS1 et ERS2, consultez Enqueue Replication Server dans un cluster de basculement Microsoft et Nouveau réplicateur d’empilage dans les environnements de cluster de basculement sur le site web SAP.
Options de disques partagés dans Azure pour les charges de travail SAP
Il existe deux options pour les disques partagés dans un cluster de basculement Windows dans Azure :
- Utiliser des disques partagés Azure pour attacher simultanément des disques managés Azure à plusieurs machines virtuelles.
- Utiliser SIOS DataKeeper Cluster Edition pour créer un stockage en miroir qui simule un stockage partagé de cluster.
Lorsque vous sélectionnez la technologie utilisée pour les disques partagés, gardez à l’esprit les considérations suivantes sur les disques partagés Azure pour les charges de travail SAP :
- L’utilisation de disques partagés Azure avec des disques SSD Premium Azure est prise en charge pour le déploiement SAP dans les groupes de disponibilité et les zones de disponibilité.
- Les disques de stockage Ultra Azure et les disques SSD Standard Azure ne sont pas pris en charge en tant que disques partagés Azure pour les charges de travail SAP.
- Veillez à approvisionner des disques SSD Premium Azure avec une taille de disque minimale, comme indiqué dans Plages des disques SSD Premium, pour pouvoir attacher simultanément le nombre de machines virtuelles requis. Vous avez généralement besoin de deux machines virtuelles pour les clusters de basculement Windows SAP ASCS.
Gardez à l’esprit les considérations suivantes en ce qui concerne SIOS :
- La solution SIOS assure une réplication synchrone et en temps réel des données entre deux disques.
- Avec la solution SIOS, vous utilisez deux disques managés. Si vous utilisez des groupes de disponibilité ou des zones de disponibilité, les disques managés se trouvent sur différents clusters de stockage.
- Le déploiement dans les zones de disponibilité est pris en charge.
- La solution SIOS nécessite l’installation et l’exploitation de logiciels tiers, que vous devez acheter séparément.
Disques partagés Azure
Vous pouvez implémenter la haute disponibilité SAP ASCS/SCS avec les disques partagés Azure.
Conditions préalables et limitations
Actuellement, il est possible d’utiliser des disques SSD Premium Azure comme disque partagé Azure pour l'instance SAP ASCS/SCS. Quelques limitations s'appliquent pour le moment :
- Les disques de stockage Ultra Azure et les disques SSD Standard ne sont pas pris en charge en tant que disque partagé Azure pour les charges de travail SAP.
- Les disques partagés Azure avec disques SSD Premium sont pris en charge pour le déploiement SAP dans les groupes de disponibilité et les zones de disponibilité.
- Les disques partagés Azure avec disques SSD Premium sont fournis avec deux options de stockage :
- Le stockage localement redondant (LRS) pour les disques partagés SSD Premium (valeur de
skuNameégale àPremium_LRS) est pris en charge pour le déploiement dans les groupes de disponibilité. - Le stockage redondant interzone (ZRS) pour les disques partagés SSD Premium (valeur de
skuNameégale àPremium_ZRS) est pris en charge pour le déploiement dans les zones de disponibilité.
- Le stockage localement redondant (LRS) pour les disques partagés SSD Premium (valeur de
- La valeur maxShares du disque partagé Azure détermine combien de nœuds de cluster peuvent utiliser le disque partagé. Pour une instance SAP ASCS/SCS, vous configurez généralement deux nœuds dans WSFC. Vous définissez ensuite la valeur de
maxSharessur2. - Un groupe de placement de proximité Azure (PPG) n’est pas nécessaire pour les disques partagés Azure. Toutefois, pour les déploiements SAP avec des groupes de placement de proximité, suivez ces instructions :
- Si vous utilisez des groupes de placement de proximité pour un système SAP déployé dans une région, toutes les machines virtuelles qui partagent un disque doivent faire partie du même groupe de placement de proximité.
- Si vous utilisez des groupes de placement de proximité pour le système SAP déployé sur plusieurs zones, comme décrit dans Groupes de placement de proximité avec des déploiements sur plusieurs zones, vous pouvez attacher le stockage
Premium_ZRSaux machines virtuelles qui partagent un disque.
Pour plus d’informations, consultez la section Limitations de la documentation relative aux disques partagés Azure.
Considérations importantes pour les disques partagés SSD Premium
Tenez compte de ces points importants sur les disques partagés SSD Premium Azure :
LRS pour les disques partagés SSD Premium :
- Le déploiement SAP avec LRS pour les disques partagés SSD Premium fonctionne avec un seul disque partagé Azure sur un cluster de stockage. En cas de problème avec le cluster de stockage où le disque partagé Azure est déployé, cela affecte votre instance SAP ASCS/SCS.
ZRS pour les disques partagés SSD Premium :
- La latence d’écriture pour ZRS est supérieure à celle de LRS en raison de la copie des données entre les zones.
- La distance entre les zones de disponibilité de différentes régions varie, la latence des disques ZRS entre les zones de disponibilité varie donc aussi. Évaluez vos disques pour identifier la latence des disques ZRS dans votre région.
- ZRS pour les disques partagés SSD Premium réplique les données de façon synchrone dans trois zones de disponibilité de la région. En cas de problème dans l’un des clusters de stockage, votre instance SAP ASCS/SCS continue à s’exécuter, car le basculement du stockage est transparent pour la couche application.
- Pour plus d’informations, consultez la section Limitations de la documentation relative à ZRS pour les disques managés.
Pour d’autres considérations importantes sur la planification de votre déploiement SAP, étudiez Planifier et implémenter un déploiement SAP sur Azure et Types de Stockage Azure pour les charges de travail SAP.
Versions du système d'exploitation prises en charge
Windows Server 2016, 2019 et les versions ultérieures sont pris en charge. Utilisez les images de centre de données les plus récentes.
Nous vous recommandons vivement d’utiliser au moins Windows Server 2019 Datacenter, pour ces raisons :
- WSFC dans Windows Server 2019 reconnaît Azure.
- Windows Server 2019 Datacenter inclut l’intégration et la reconnaissance de la maintenance de l’hôte Azure, et une expérience améliorée grâce à l’analyse des évènements planifiés Azure.
- Vous pouvez utiliser des noms de réseau distribué. (Il s’agit de l’option par défaut.) Il n’est pas nécessaire de disposer d’une adresse IP dédiée pour le nom réseau du cluster. En outre, vous n’avez pas besoin de configurer d’adresse IP sur un équilibreur de charge interne Azure.
Disques partagés dans Azure avec SIOS DataKeeper
Une autre option, pour les disques partagés, consiste à utiliser le logiciel tiers SIOS DataKeeper Cluster Edition pour créer un stockage en miroir qui simule un stockage partagé de cluster. La solution SIOS assure la réplication synchrone des données en temps réel.
Pour créer une ressource de disque partagé pour un cluster :
- Attachez un disque supplémentaire à chaque machine virtuelle se trouvant dans une configuration de cluster Windows.
- Exécutez SIOS DataKeeper Cluster Edition sur les deux nœuds de machine virtuelle.
- Configurez SIOS DataKeeper Cluster Edition de sorte qu’il mette en miroir le contenu du volume attaché au disque supplémentaire depuis la machine virtuelle source vers le volume attaché au disque supplémentaire de la machine virtuelle cible. SIOS DataKeeper extrait les volumes locaux source et cible, puis les présente à WSFC en tant que disque partagé.
Remarque
Avec certains SGBD, tels que SQL Server, vous n’avez pas besoin de disques partagés pour atteindre une haute disponibilité. SQL Server Always On assure la réplication des données et des fichiers de journaux du SGBD à partir du disque local d’un nœud du cluster vers le disque local d’un autre nœud du cluster. Dans ce cas, la configuration du cluster Windows ne nécessite pas de disque partagé.
Configurations facultatives
Les diagrammes suivants montrent plusieurs instances SAP sur des machines virtuelles Azure exécutant le clustering de basculement Windows Server pour réduire le nombre total de machines virtuelles.
Cette configuration peut être des serveurs d’applications SAP locaux sur un cluster SAP ASCS/SCS, ou un rôle de cluster SAP ASCS/SCS sur des nœuds Always On Microsoft SQL Server.
Important
L’installation d’un serveur d’applications SAP local sur un nœud Always On SQL Server n’est pas prise en charge.
SAP ASCS/SCS et la base de données Microsoft SQL Server sont tous deux des points de défaillance uniques (SPOF). WSFC permet de protéger ces SPOF dans un environnement Windows.
Bien que la consommation de ressources SAP ASCS/SCS soit relativement faible, nous vous recommandons de réduire de 2 Go la configuration de la mémoire pour SQL Server ou le serveur d’applications SAP.
Ce diagramme illustre les serveurs d’applications SAP sur les nœuds WSFC avec l’utilisation de SIOS DataKeeper :
Les serveurs d’applications SAP étant installés localement, il n’est pas nécessaire de configurer de synchronisation.
Ce diagramme illustre SAP ASCS/SCS sur des nœuds Always On SQL Server avec l’utilisation de SIOS DataKeeper :
Pour plus d’informations sur d’autres configurations, consultez les ressources suivantes :