Configurer la reprise d’activité pour un déploiement d’application SAP NetWeaver multiniveau

La plupart des déploiements SAP, de moyenne et grande taille, utilisent une forme de solution de reprise d’activité après sinistre. Disposer de solutions de reprise d’activité fiables et testables est de plus en plus important, d’autant qu’un nombre croissant de processus métier essentiels sont déplacés vers des applications telles que SAP. Azure Site Recovery a été testé et intégré aux applications SAP. Site Recovery dépasse les capacités de la plupart des solutions locales de récupération d’urgence, et à un coût total de possession moins élevé que les solutions concurrentes.

Avec Site Recovery, vous pouvez effectuer les actions décrites ici.

  • Activer la protection des applications de production SAP NetWeaver et non-NetWeaver qui s’exécutent localement par la réplication des composants vers Azure.
  • Activer la protection des applications de production SAP NetWeaver et non-NetWeaver qui s’exécutent sur Azure par la réplication des composants sur un autre centre de données Azure.
  • Simplifier la migration vers le cloud en utilisant Site Recovery pour migrer votre déploiement SAP vers Azure.
  • Simplifier les mises à niveau, les tests et la création de prototypes de projet SAP par la création d’un clone de production à la demande pour tester les applications SAP.

Vous pouvez protéger les déploiements d’applications SAP NetWeaver à l’aide d’Azure Site Recovery. Cet article traite des meilleures pratiques permettant de protéger un déploiement SAP NetWeaver à trois niveaux sur Azure lorsque vous répliquez vers un autre centre de données Azure à l’aide de Site Recovery. Il décrit les configurations et scénarios pris en charge ainsi que la façon de réaliser des tests de basculement (tests de récupération d’urgence) et des basculements réels.

Prérequis

Avant de commencer, assurez-vous que vous savez accomplir les tâches suivantes :

Scénarios pris en charge

Vous pouvez utiliser Site Recovery pour implémenter une solution de reprise d’activité dans les scénarios décrits ici.

  • Vous disposez de systèmes SAP qui s’exécutent dans un centre de données Azure et que vous répliquez dans un autre centre de données Azure (récupération d’urgence Azure vers Azure). Pour plus d’informations, consultez Architecture de réplication Azure vers Azure.
  • Les systèmes SAP s’exécutent sur des serveurs VMware (ou physiques) locaux. Vous répliquez également les systèmes SAP sur un site de récupération d’urgence dans un centre de centres Azure (récupération d’urgence VMware vers Azure). Ce scénario nécessite quelques composants supplémentaires. Pour plus d’informations, consultez Architecture de réplication VMware vers Azure.
  • Vous disposez de systèmes SAP s’exécutant sur Hyper-V localement. Vous répliquez également les systèmes SAP sur un site de récupération d’urgence dans un centre de centres Azure (récupération d’urgence Hyper-V vers Azure). Ce scénario nécessite quelques composants supplémentaires. Pour plus d’informations, consultez Architecture de réplication Hyper-V vers Azure.

Dans cet article, nous utilisons une scénario de récupération d’urgence Azure vers Azure. Le scénario vous montre les fonctionnalités de récupération d’urgence SAP de Site Recovery. La réplication Site Recovery n’étant pas propre à l’application, le processus qui est décrit est censé s’appliquer également à d’autres scénarios.

Services de base nécessaires

Dans le scénario que cet article développe, les services de base suivants sont déployés :

  • Azure ExpressRoute ou Passerelle VPN Azure
  • Au moins un contrôleur de domaine Microsoft Entra et un serveur DNS, s’exécutant dans Azure

Nous vous recommandons de mettre en place cette infrastructure avant de déployer Site Recovery.

Déploiement des applications SAP de référence

Cette architecture de référence exécute SAP NetWeaver dans un environnement Windows sur Azure avec une haute disponibilité. Cette architecture est déployée avec des tailles de machine virtuelle spécifiques que vous pouvez modifier en fonction des besoins de votre organisation.

Diagram of a typical SAP deployment pattern

Considérations relatives à la récupération d’urgence

Pour la récupération d’urgence, vous devez être en mesure de basculer vers une région secondaire. Chaque couche utilise une stratégie différente pour protéger la récupération d’urgence.

Machines virtuelles exécutant des pools SAP Web Dispatcher

Le composant Web Dispatcher fonctionne comme un équilibreur de charge pour le trafic SAP entre les serveurs d’applications SAP. Afin d’assurer la haute disponibilité pour le composant Web Dispatcher, Azure Load Balancer implémente l’installation parallèle de Web Dispatcher. Web Dispatcher utilise une configuration de tourniquet (round robin) pour la distribution du trafic HTTP(S) entre les instances Web Dispatcher disponibles dans le pool d’équilibreurs.

Machines virtuelles exécutant des pools de serveurs d’applications

La transaction SMLG gère les groupes de connexion des serveurs d’applications ABAP. Elle s’appuie sur la fonction d’équilibrage de charge au sein du serveur de messages des services centraux pour répartir la charge de travail entre les pools de serveurs d’applications SAP pour les clients SAPGUI et le trafic RFC. Vous pouvez répliquer cette gestion à l’aide de Site Recovery.

Machines virtuelles exécutant des clusters de services centraux SAP

Cette architecture de référence exécute les services centraux sur les machines virtuelles de la couche application. Les services centraux constituent un potentiel point de défaillance unique lorsqu’ils se trouvent dans une seule machine virtuelle. Un déploiement classique et la haute disponibilité ne sont pas des exigences.

Pour implémenter une solution à haute disponibilité, vous pouvez utiliser soit un cluster de disque partagé, soit un cluster de partage de fichiers. Pour configurer des machines virtuelles pour un cluster de disque partagé, utilisez le cluster de basculement Windows Server. Nous vous recommandons d’utiliser le témoin cloud comme témoin de quorum.

Notes

Étant donné que Site Recovery ne réplique pas le témoin cloud, nous vous recommandons de déployer le témoin cloud dans la région de récupération d’urgence.

Pour prendre en charge l’environnement de cluster de basculement, SIOS DataKeeper Cluster Edition assure la fonction de volume partagé du cluster. Dans la fonction, SIOS DataKeeper Cluster réplique les disques indépendants détenus par les nœuds de cluster.

Vous pouvez également gérer le clustering en implémentant un cluster de partage de fichiers. SAP a récemment modifié le modèle de déploiement des services centraux pour accéder aux répertoires globaux /sapmnt via un chemin d’accès UNC. Nous vous recommandons toutefois de vous assurer que le partage UNC /sapmnt est hautement disponible. Vous pouvez vérifier votre instance des services centraux. Utilisez le cluster de basculement Windows Server avec le serveur de fichiers Scale Out (SOFS) et la fonctionnalité d’espaces de stockage direct (S2D) de Windows Server 2016.

Notes

Site Recovery prend actuellement en charge uniquement la réplication de points cohérents en cas d’incident de machines virtuelles qui utilisent des espaces de stockage direct et le nœud passif de SIOS Datakeeper.

Autres considérations relatives à la récupération d’urgence

Vous pouvez utiliser Site Recovery pour orchestrer le basculement d’un déploiement SAP complet entre des régions Azure. Voici les étapes de configuration de la récupération d’urgence :

  1. Répliquer des machines virtuelles
  2. Constituer un réseau de récupération
  3. Répliquer un contrôleur de domaine
  4. Répliquer le niveau de base de données
  5. Exécuter un test de basculement
  6. Effectuer un basculement

Voici la recommandation pour la récupération d’urgence de chaque niveau utilisé dans cet exemple.

Niveaux SAP Recommandation
Pool SAP Web Dispatcher Répliquer à l’aide de Site Recovery
Pool de serveurs d’applications SAP Répliquer à l’aide de Site Recovery
Cluster des services centraux SAP Répliquer à l’aide de Site Recovery
Machines virtuelles Active directory Utiliser la réplication Active Directory
Serveurs SQL Database Utiliser la réplication SQL Server Always On

Répliquer des machines virtuelles

Pour commencer la réplication de toutes les machines virtuelles d’application SAP vers le centre de données de reprise d’activité Azure, suivez les instructions dans Répliquer une machine virtuelle vers Azure.

Configuration de la mise en réseau

Si vous utilisez une adresse IP statique, vous pouvez spécifier l’adresse IP que vous souhaitez attribuer à la machine virtuelle. Pour définir l’adresse IP, accédez à Paramètres réseau>Carte d’interface réseau.

Screenshot that shows how to set a private IP address in the Site Recovery Network interface card pane

Créer un plan de récupération

Lors d’un basculement, un plan de récupération prend en charge le séquencement des différents niveaux d’une application multiniveau. La mise en séquence permet d’assurer la cohérence de l’application. Lorsque vous créez un plan de récupération pour une application web multiniveau, suivez les étapes décrites dans Créer un plan de récupération à l’aide de Site Recovery.

Ajouter des machines virtuelles à des groupes de basculement

  1. Créez un plan de récupération en ajoutant le serveur d’applications, Web Dispatcher et des machines virtuelles de services centraux SAP.
  2. Sélectionnez Personnaliser pour regrouper les machines virtuelles. Par défaut, toutes les machines virtuelles font partie du groupe 1.

Ajouter des scripts au plan de récupération

Afin de vous assurer du bon fonctionnement de vos applications, vous pouvez être amené à effectuer certaines opérations sur les machines virtuelles Azure. Effectuez ces opérations après le basculement ou pendant un test de basculement. Vous pouvez également automatiser certaines opérations après le basculement. Par exemple, mettez à jour l’entrée DNS, puis modifiez les liaisons et les connexions en ajoutant au plan de récupération les scripts correspondants.

Vous pouvez déployer les scripts Site Recovery les plus utilisés dans votre compte Azure Automation en sélectionnant Déployer dans Azure. Lorsque vous utilisez un script publié, suivez les instructions du script.

Deploy to Azure

  1. Ajoutez un script d’action préalable au groupe 1 pour basculer le groupe de disponibilité SQL Server. Utilisez le script ASR-SQL-FailoverAG publié dans les exemples de script. Suivez les instructions du script et apportez les modifications requises dans le script en conséquence.
  2. Ajoutez un script d’action postérieure pour attribuer un équilibreur de charge aux machines virtuelles basculées de niveau web (Groupe 1). Utilisez le script ASR-AddSingleLoadBalancer publié dans les exemples de script. Suivez les instructions du script et apportez les modifications requises dans le script le cas échéant.

SAP Recovery Plan

Exécuter un test de basculement

  1. Dans le portail Azure, sélectionnez votre coffre Recovery Services.
  2. Sélectionnez le plan de récupération que vous avez créé pour les applications SAP.
  3. Sélectionnez Test de basculement.
  4. Pour démarrer le test de basculement, sélectionnez le point de récupération et le réseau virtuel Azure.
  5. Lorsque l’environnement secondaire est opérationnel, procédez aux validations.
  6. Lorsque les validations sont terminées, nettoyez l’environnement de basculement en sélectionnant Nettoyer le test de basculement.

Pour plus d’informations, consultez Tester le basculement vers Azure dans Site Recovery.

Exécuter un basculement

  1. Dans le portail Azure, sélectionnez votre coffre Recovery Services.
  2. Sélectionnez le plan de récupération que vous avez créé pour les applications SAP.
  3. Sélectionnez Basculement.
  4. Pour démarrer le processus de basculement, sélectionnez le point de récupération.

Pour plus d’informations, consultez Basculement dans Site Recovery.

Étapes suivantes