Cluster d’une instance SAP ASCS/SCS sur un cluster de basculement Windows à l’aide d’un disque partagé dans Azure

  • Article

Windows OS Windows

Le clustering de basculement Windows Server (WSFC) est la base d’une installation SAP ASCS/SCS SAP ASCS/SCS 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 d’échecs qui peuvent se produire et conservent un cluster sain pour fournir des applications et des services. Vous pouvez choisir parmi différents modes de quorum pour obtenir le clustering de basculement.

Prérequis

Avant de commencer les tâches décrites dans 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 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 l’adresse IP virtuelle du cluster.

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 transfert de port nécessaires à l’aide des ports de sonde 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.

Important

Les adresses IP flottantes ne sont pas prises en charge sur une configuration IP secondaire pour une carte réseau dans les scénarios d’équilibrage de charge. Pour plus d’informations, consultez es Limitations relatives à l’Équilibreur de charge Azure. Si vous avez besoin d’une adresse IP supplémentaire pour la machine virtuelle, déployez une deuxième carte d’interface réseau.

Diagram of a Windows Server Failover Clustering configuration in Azure without a shared disk.

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 de file d’attente) et un nom d’hôte virtuel ASCS/SCS utilisé pour accéder aux deux processus
    • Structure de fichier : 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 permet d’accéder à ces fichiers S :\usr\sap\<SID>\SYS... globaux à l’aide du chemin UNC suivant :

      \\<ASCS/SCS nom> d’hôte virtuel\sapmnt\<SID>\SYS...

Diagram of processes, file structure, and global host file share of an SAP ASCS/SCS instance.

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 hôtes globaux SAP ASCS/SCS et SAP.

Diagram that shows an SAP ASCS/SCS high-availability architecture with shared disks.

Avec une architecture ERS1 (Enqueue Replication Server 1) :

  • Le même nom d’hôte virtuel ASCS/SCS est utilisé pour accéder au serveur de messages SAP et aux processus du serveur de file d’attente, en plus des fichiers hôtes globaux 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 hôtes globaux 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 de serveur en file d’attente.

Diagram of an SAP ASCS/SCS high-availability architecture with a shared disk.

Disques partagés et serveur de réplication en file d’attente

Les disques partagés sont pris en charge avec une architecture ERS1, où l’instance ERS1 :

  • N’est pas cluster.
  • Utilise un localhost nom.
  • Est déployé sur des disques locaux sur chacun des nœuds du cluster.

Les disques partagés sont également pris en charge avec une architecture ERS2, où l’instance ERS2 :

  • Est 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é 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 Le serveur de réplication en file d’attente dans un cluster de basculement Microsoft et le nouveau réplica en file d’attente dans les environnements de cluster de basculement sur le site web SAP.

Options pour les 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 :

Lorsque vous sélectionnez la technologie 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 Azure Premium est prise en charge pour le déploiement SAP dans les groupes à haute disponibilité et les zones de disponibilité.
  • Les disques Azure Ultra Stockage et les disques SSD Azure Standard ne sont pas pris en charge en tant que disques partagés Azure pour les charges de travail SAP.
  • Veillez à provisionner des disques SSD Azure Premium avec une taille de disque minimale, comme indiqué dans les plages de 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 sur SIOS :

  • La solution SIOS fournit une réplication de données synchrone en temps réel entre deux disques.
  • Avec la solution SIOS, vous utilisez deux disques managés. Si vous utilisez des groupes à haute 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 des disques partagés Azure.

Conditions préalables et limitations

Actuellement, vous pouvez utiliser des disques SSD Azure Premium en tant que disques partagés Azure pour l’instance SAP ASCS/SCS. Quelques limitations s'appliquent pour le moment :

  • Les disques azure Ultra Stockage et les disques SSD Standard ne sont pas pris en charge en tant que disques partagés 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 à haute disponibilité et les zones de disponibilité.
  • Les disques partagés Azure avec des disques SSD Premium sont fournis avec deux options de stockage :
    • Le stockage localement redondant (LRS) pour les disques partagés SSD Premium (skuName valeur de Premium_LRS) est pris en charge avec le déploiement dans les groupes à haute disponibilité.
    • Le stockage redondant interzone (ZRS) pour les disques partagés SSD Premium (skuName valeur de ) est pris en charge avec le déploiement dans les zones de Premium_ZRSdisponibilité.
  • La valeur de disque partagé Azure maxShares détermine le nombre de nœuds de cluster pouvant 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 sur maxShares2.
  • Un groupe de placement de proximité Azure (PPG) n’est pas requis pour les disques partagés Azure. Toutefois, pour le déploiement SAP avec des PPG, suivez ces instructions :

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 Azure Premium :

  • LRS pour disques partagés SSD Premium :

    • Le déploiement SAP avec LRS pour disques partagés SSD Premium fonctionne avec un seul disque partagé Azure sur un cluster de stockage. S’il existe un problème avec le cluster de stockage où le disque partagé Azure est déployé, il affecte votre instance SAP ASCS/SCS.

  • Disques partagés ZRS pour SSD Premium :

    • La latence d’écriture pour ZRS est supérieure à celle de LRS en raison de la copie zonale croisée des données.
    • La distance entre les zones de disponibilité dans différentes régions varie, et la latence de disque ZRS entre les zones de disponibilité est donc différente. Évaluez vos disques pour identifier la latence des disques ZRS dans votre région.
    • ZRS pour disques partagés SSD Premium réplique de manière synchrone les données entre 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 de stockage est transparent pour la couche application.
    • Pour plus d’informations, consultez la section Limitations de la documentation sur ZRS pour les disques managés.

Pour d’autres considérations importantes sur la planification de votre déploiement SAP, passez en revue plan et implémentez un déploiement SAP sur Azure et Stockage Azure types pour les charges de travail SAP.

Versions du système d'exploitation prises en charge

Windows Server 2016, 2019 et versions ultérieures sont pris en charge. Utilisez les dernières images de centre de données.

Nous vous recommandons vivement d’utiliser au moins Windows Server 2019 Datacenter pour ces raisons :

  • WSFC dans Windows Server 2019 est conscient d’Azure.
  • Windows Server 2019 Datacenter inclut l’intégration et la sensibilisation à la maintenance de l’hôte Azure et une expérience améliorée en surveillance des événements planifiés Azure.
  • Vous pouvez utiliser des noms de réseau distribués. (Il s’agit de l’option par défaut.) Il n’est pas nécessaire d’avoir une adresse IP dédiée pour le nom du réseau de cluster. En outre, vous n’avez pas besoin de configurer une 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 SIOS DataKeeper Cluster Edition pour créer un stockage miroir ed qui simule le 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 :

  1. Attachez un disque supplémentaire à chaque machine virtuelle se trouvant dans une configuration de cluster Windows.
  2. Exécutez SIOS DataKeeper Cluster Edition sur les deux nœuds de machine virtuelle.
  3. Configurez SIOS DataKeeper Cluster Edition pour qu’il miroir le contenu du volume supplémentaire attaché au disque à partir de la machine virtuelle source vers le volume supplémentaire attaché au disque de la machine virtuelle cible. SIOS DataKeeper extrait les volumes locaux source et cible, puis les présente à WSFC en tant que disque partagé.

Diagram of a Windows Server Failover Clustering configuration in Azure with SIOS DataKeeper.

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 SQL Server Always On n’est pas prise en charge.

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

Bien que la consommation de ressources de SAP ASCS/SCS soit assez petite, nous vous recommandons de réduire la configuration de la mémoire pour SQL Server ou le serveur d’applications SAP de 2 Go.

Ce diagramme illustre les serveurs d’applications SAP sur les nœuds WSFC avec l’utilisation de SIOS DataKeeper :

Diagram of a Windows Server Failover Clustering configuration in Azure with SIOS DataKeeper and locally installed SAP application servers.

Étant donné que les serveurs d’applications SAP sont installés localement, il n’est pas nécessaire de configurer une synchronisation.

Ce diagramme illustre les nœuds SAP ASCS/SCS sur SQL Server Always On avec l’utilisation de SIOS DataKeeper :

Diagram of SAP ASCS/SCS on SQL Server Always On nodes with SIOS DataKeeper.

Pour plus d’informations sur d’autres configurations, consultez les ressources suivantes :

Étapes suivantes