Share via

Mettre en cluster une instance SAP ASCS/SCS sur un cluster de basculement Windows à l’aide du partage de fichiers dans Azure

  • Article

Windows logo. Windows

Le clustering de basculement Windows Server constitue la base d’une installation de SGBD et de SAP ASCS/SCS à haute disponibilité 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. En cas d’échec d’un nœud, le clustering de basculement Windows Server calcule le nombre d’échecs qui peuvent se produire sans que le cluster ne perde son intégrité, de sorte que les applications et les services puissent être fournis. Différents modes de quorum sont disponibles pour obtenir un clustering de basculement.

Prérequis

Avant d’aborder les tâches décrites dans cet article, consultez les articles et notes SAP suivants :

  • Scénarios et architecture de haute disponibilité de machines virtuelles Azure pour SAP NetWeaver
  • Note SAP 1928533, qui contient :
    • une liste des tailles de machines virtuelles Azure prises en charge pour le déploiement de logiciels SAP
    • des informations importantes sur la capacité en fonction de la taille des machines virtuelles Azure
    • les logiciels SAP pris en charge et les combinaisons entre système d’exploitation et base de données
    • la version du noyau SAP requise pour Windows sur Microsoft Azure
  • La note SAP 2015553 répertorie les conditions préalables au déploiement de logiciels SAP pris en charge par SAP sur Azure.
  • La note SAP 2178632 contient des informations détaillées sur toutes les métriques de surveillance rapportées pour SAP sur Azure.
  • La note SAP 1999351 contient des informations de dépannage supplémentaires pour l’extension d’analyse Azure améliorée pour SAP.
  • La note SAP 2287140 répertorie les conditions préalables pour la fonctionnalité d’autorité de certification prise en charge par SAP du protocole SMB 3.x.
  • La note SAP 2802770 contient des informations sur la résolution des problèmes liés à l’exécution lente de la transaction SAP AL11 sur Windows 2012 et 2016.
  • La note SAP 1911507 contient des informations sur la fonctionnalité de basculement transparent pour un partage de fichiers sur Windows Server avec le protocole SMB 3.0.
  • La note SAP 662452 offre une recommandation (désactivation de la génération de noms 8.3) pour résoudre les erreurs/performances médiocres du système de fichiers lors des accès aux données.
  • Installer la haute disponibilité SAP NetWeaver sur un cluster de basculement Windows et un partage de fichiers pour des instances SAP ASCS/SCS sur Azure

Remarque

Le clustering d’instances SAP ASCS/SCS à l’aide d’un partage de fichiers est pris en charge pour les systèmes SAP avec SAP Kernel 7.22 (et versions ultérieures). Pour plus d’informations, consultez la note SAP 2698948.

Clustering de basculement Windows Server dans Azure

Par rapport aux déploiements complets ou de cloud privé, le service Machines virtuelles Azure requiert des étapes supplémentaires pour configurer le clustering de basculement Windows Server. 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’équilibrage 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. L’équilibreur de charge interne gère le réacheminement de port vers le nœud actif du cluster.

Figure 1: Windows Server Failover Clustering configuration in Azure without a shared disk

Figure 1 : Configuration du clustering de basculement Windows Server dans Azure sans disque partagé

Haute disponibilité SAP ASCS/SCS avec partage de fichiers

SAP a développé une nouvelle approche et une alternative aux disques partagés pour le clustering d’une instance SAP ASCS/SCS sur un cluster de basculement Windows. Au lieu d’utiliser des disques partagés de cluster, vous pouvez utiliser un partage de fichiers SMB pour déployer des fichiers d’hôte global SAP.

Notes

Le partage de fichiers SMB est une alternative aux disques partagés de cluster pour le clustering d’instances SAP ASCS/SCS.

Voici les spécificités de cette architecture :

  • Les services centraux SAP (avec une structure de fichiers et des processus de messages et d’empilement propres) sont séparés des fichiers d’hôte global SAP.
  • Les services centraux SAP s’exécutent sous une instance SAP ASCS/SCS.
  • L’instance SAP ASCS/SCS est en cluster et est accessible à l’aide du nom d’hôte virtuel <nom d’hôte virtuel ASCS/SCS>.
  • Les fichiers globaux SAP sont placés sur le partage de fichiers SMB et sont accessibles à l’aide du nom d’hôte <Hôte global SAP> : \\<Hôte global SAP>\sapmnt\<SID>\SYS...
  • L’instance SAP ASCS/SCS est installée sur un disque local sur les deux nœuds de cluster
  • Le nom de réseau <nom d’hôte virtuel ASCS/SCS> est différent de <l’hôte global SAP>.

Figure 2: SAP ASCS/SCS HA architecture with SMB file share

Figure 2 : Nouvelle architecture à haute disponibilité SAP ASCS/SCS avec partage de fichiers SMB

Conditions préalables pour un partage de fichiers SMB :

  • Protocole SMB 3.0 (ou version ultérieure)
  • Possibilité de définir les listes de contrôle d’accès (ACL, access control list) Active Directory pour les groupes d’utilisateurs Active Directory et l’objet Ordinateur computer$
  • Le partage de fichiers doit être activé à haute disponibilité :
    • Les disques utilisés pour stocker des fichiers ne doivent pas constituer un point de défaillance unique.
    • Les temps d’arrêt de serveur ou de machine virtuelle n’entraînent pas de temps d’arrêt du partage de fichiers.

Le rôle de cluster SAP <SID> ne contient aucun disque partagé de cluster et aucune ressource de cluster de partage de fichiers générique.

Figure 3: SAP <SID> cluster role resources for using a file share

Figure 3 : Ressources du rôle de cluster SAP <SID> pour l’utilisation d’un partage de fichiers

Partages de fichiers avec montée en puissance parallèle avec les espaces de stockage direct dans Azure en tant que partage de fichiers SAPMNT

Vous pouvez utiliser un partage de fichiers avec montée en puissance parallèle pour héberger et protéger des fichiers d’hôte global SAP. Un partage de fichiers avec montée en puissance parallèle offre également un service de partage de fichiers SAPMNT hautement disponible.

Figure 4: Scale-out file share used to protect SAP global host files

Figure 4 : Partage de fichiers avec scale-out utilisé pour protéger les fichiers d’hôte global SAP

Important

Les partages de fichiers avec montée en puissance parallèle sont entièrement pris en charge dans le cloud Microsoft Azure et dans les environnements locaux.

Un partage de fichiers avec montée en puissance parallèle offre un partage de fichiers SAPMNT hautement disponible et scalable horizontalement.

Les espaces de stockage direct sont utilisés en tant que disque partagé pour un partage de fichiers avec montée en puissance parallèle. Vous pouvez utiliser les espaces de stockage direct pour générer un stockage hautement disponible et évolutif à l’aide de serveurs à stockage local. Le stockage partagé utilisé pour un partage de fichiers avec montée en puissance parallèle, comme pour les fichiers d’hôte global SAP, ne constitue pas un point de défaillance unique.

Lorsque vous choisissez les espaces de stockage direct, tenez compte des cas d’utilisation suivants :

  • Les machines virtuelles utilisées pour créer le cluster d’espaces de stockage direct doivent être déployées dans un groupe à haute disponibilité Azure.
  • Pour la récupération d’urgence d’un cluster d’espaces de stockage direct, vous pouvez utiliser les services Azure Site Recovery.
  • Il n’est pas possible de déployer le cluster d’espaces de stockage direct sur différentes Zones de disponibilité Azure.

Conditions préalables liées à SAP pour les partages de fichiers avec montée en puissance parallèle dans Azure

Si vous souhaitez utiliser un partage de fichiers avec montée en puissance parallèle, votre système doit répondre aux exigences suivantes :

  • Au moins deux nœuds de cluster doivent être disponibles pour un partage de fichiers avec montée en puissance parallèle.
  • Chaque nœud doit disposer d’au moins deux disques locaux.
  • Pour des raisons de performances, vous devez utiliser miroir résilience :
    • Mise en miroir double pour un partage de fichiers avec montée en puissance parallèle avec deux nœuds de cluster
    • Mise en miroir triple pour un partage de fichiers avec montée en puissance parallèle avec trois nœuds de cluster (ou plus)
  • Nous vous recommandons de prévoir trois nœuds de cluster (ou plus) pour un partage de fichiers avec montée en puissance parallèle, avec une mise en miroir triple. Cette configuration offre une meilleure extensibilité et une meilleure résilience du stockage que la configuration basée sur un partage de fichiers avec montée en puissance parallèle avec deux nœuds de cluster et une mise en miroir double.
  • Vous devez utiliser des disques Azure Premium.
  • Nous vous recommandons d’utiliser Azure Disques managés.
  • Nous vous recommandons de formater les volumes à l’aide du système ReFS (Resilient File System).
  • Vous pouvez utiliser les tailles de machines virtuelles Azure séries DS ou séries DSv2.
  • Pour obtenir de bonnes performances réseau entre les machines virtuelles (nécessaires pour la synchronisation des disques d’espaces de stockage direct), utilisez un type de machine virtuelle disposant au moins d’une bande passante réseau élevée. Pour plus d’informations, consultez les spécifications des séries DSv2 et des séries DS.
  • Nous vous recommandons de réserver une capacité non allouée dans le pool de stockage. Vous laisserez ainsi aux volumes suffisamment d’espace pour effectuer une réparation « sur place » en cas d’échec d’un disque. Cette méthode améliore les performances et la sécurité des données. Pour plus d’informations, consultez la rubrique Choix de la taille des volumes.
  • Vous n’avez pas besoin de configurer l’équilibreur de charge interne Azure avec le nom réseau du partage de fichiers avec montée en puissance parallèle, comme pour <l’hôte global SAP>. Cette opération s’effectue pour le <nom d’hôte virtuel ASCS/SCS> de l’instance SAP ASCS/SCS ou pour le système de gestion de base de données (SGBD). Un partage de fichiers avec montée en puissance parallèle fait monter en charge l’ensemble des nœuds de cluster. <L’hôte global SAP> utilise l’adresse IP locale pour tous les nœuds de cluster.

Important

Vous ne pouvez pas renommer le partage de fichiers SAPMNT, qui pointe vers <l’hôte global SAP>. SAP prend en charge uniquement le nom de partage « sapmnt ».

Pour plus d’informations, reportez-vous au document SAP Note 2492395 - Can the share name sapmnt be changed? (Note SAP n° 2492395 : Le nom de partage sapmnt peut-il être modifié ?).

Configurer des instances SAP ASCS/SCS et un partage de fichiers avec montée en puissance parallèle dans deux clusters

Vous devez déployer les instances SAP ASCS/SCS dans un cluster distinct, avec leur propre rôle de cluster SAP <SID>. Dans ce cas, vous devez configurer le partage de fichiers avec montée en puissance parallèle sur un autre cluster, avec un autre rôle de cluster.

Important

L’installation doit remplir les conditions suivantes : les instances SAP ASCS/SCS et le partage SOFS doivent être déployés dans des clusters distincts.

Important

Dans ce scénario, l’instance SAP ASCS/SCS est configurée pour accéder à l’hôte global SAP à l’aide du chemin UNC \\<Hôte global SAP>\sapmnt\<SID>\SYS.

Figure 5: SAP ASCS/SCS instance and a scale-out file share deployed in two clusters

Figure 5 : Instance SAP ASCS/SCS et partage de fichiers avec scale-out dans deux clusters

Configurations facultatives

Les diagrammes suivants montrent plusieurs instances SAP sur des machines virtuelles Azure exécutant le cluster de basculement Microsoft Windows pour réduire le nombre total de machines virtuelles.

Il peut s’agir de serveurs d’applications SAP locaux sur un cluster ASCS/SCS SAP ou d’un rôle de cluster ASCS/SCS SAP 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.

ASCS/SCS SAP et la base de données Microsoft SQL Server sont tous deux des points de défaillance uniques (SPOF). Pour protéger ces SPOF dans un environnement Windows, WSFC est utilisé.

Bien que la consommation de ressources ASCS/SCS SAP soit relativement faible, il est recommandé de réduire de 2 Go la configuration de la mémoire pour SQL Server ou le serveur d’applications SAP.

Serveurs d’applications SAP sur des nœuds WSFC utilisant SIOS DataKeeper

Figure 6: Windows Server failover clustering configuration in Azure with Windows SOFS and locally installed SAP Application Server

Remarque

L’image montre l’utilisation de disques locaux supplémentaires. Cela est facultatif pour les clients qui n’installent pas les logiciels d’application sur le lecteur du système d’exploitation (C:)

ASCS/SCS SAP sur des nœuds Always On SQL Server utilisant Windows SOFS

Figure 7: SAP ASCS/SCS on SQL Server Always On nodes using Windows SOFS

Remarque

L’image montre l’utilisation de disques locaux supplémentaires. Cela est facultatif pour les clients qui n’installent pas les logiciels d’application sur le lecteur du système d’exploitation (C:)

Important

Dans le cloud Azure, chaque cluster utilisé pour les partage de fichiers scale-out et SAP doit être déployé dans son propre groupe à haute disponibilité Azure ou dans les Zones de disponibilité Azure. Ceci garantit une sélection élective distribuée des machines virtuelles du cluster dans toute l’infrastructure Azure sous-jacente. Les déploiements de zones de disponibilité sont pris en charge avec cette technologie.

Partage de fichiers générique avec SIOS DataKeeper en tant que disques partagés de cluster

Un partage de fichiers générique constitue une alternative au partage de fichiers hautement disponible.

Dans ce cas, vous pouvez utiliser une solution SIOS tierce en tant que disque partagé de cluster.

Étapes suivantes