Vue d’ensemble de la récupération d’urgence et instructions d’infrastructure pour la charge de travail SAP

  • Article

De nombreuses organisations qui exécutent des applications métier critiques sur Azure configurent une stratégie de haute disponibilité (HA) et de récupération d’urgence (DR). L’objectif de la haute disponibilité est d’augmenter le contrat SLA des systèmes métier en éliminant les points de défaillance uniques dans l’infrastructure système sous-jacente. Les technologies de haute disponibilité réduisent l’effet des défaillances d’infrastructure non planifiées et facilitent la maintenance planifiée. La récupération d’urgence est définie comme un ensemble de stratégies, d’outils et de procédures qui permettent la récupération ou la poursuite de l’infrastructure et des systèmes de la technologie vitale suite à une catastrophe naturelle ou humaine à grande échelle géographique.

Pour obtenir une haute disponibilité pour la charge de travail SAP sur Azure, les machines virtuelles sont généralement déployées dans un groupe à haute disponibilité, des zones de disponibilité ou dans un groupe identique flexible pour protéger les applications contre la maintenance ou l’échec de l’infrastructure au sein de la région. Mais le déploiement ne protège pas les applications contre les sinistres généralisés au sein de la région. Par conséquent, pour protéger les applications contre les sinistres régionaux, une stratégie de récupération d’urgence pour les applications doit être en place. La récupération d’urgence est une approche documentée et structurée conçue pour aider une organisation à exécuter les processus de récupération en réponse à un sinistre, ainsi que pour protéger ou réduire les interruptions des services informatiques et promouvoir la récupération.

Ce document fournit des détails sur la protection des charges de travail SAP contre les catastrophes à grande échelle en implémentant une approche de récupération d’urgence structurée. Les détails de ce document sont présentés à un niveau abstrait, basé sur différents services Azure et composants SAP. La stratégie de récupération d’urgence exacte et l’ordre de récupération de votre charge de travail SAP doivent être testés, documentés et ajustés régulièrement. En outre, le document se concentre sur la stratégie de récupération d’urgence Azure vers Azure pour la charge de travail SAP.

Considérations générales relatives au plan de récupération d’urgence

La charge de travail SAP sur Azure s’exécute sur des machines virtuelles en combinaison avec différents services Azure pour déployer différentes couches (services centraux, serveurs d’applications, serveur de base de données) d’une application SAP NetWeaver classique. En général, une stratégie de récupération d’urgence doit être planifiée pour l’ensemble du paysage informatique s’exécutant sur Azure, ce qui signifie de prendre également en compte les applications non SAP. La solution métier s’exécutant dans les systèmes SAP peut ne pas s’exécuter dans son ensemble si les services ou ressources dépendants ne sont pas récupérés sur le site de récupération d’urgence. Vous devez donc proposer un plan de récupération d’urgence complet bien défini en tenant compte de tous les composants et systèmes.

Pour la récupération d’urgence sur Azure, les organisations doivent envisager différents scénarios qui peuvent déclencher un basculement.

  • Disponibilité des applications SAP ou des processus métier.
  • Les services Azure (comme les machines virtuelles, le stockage, l’équilibreur de charge, etc.) sont indisponibles dans une région en raison d’une défaillance généralisée.
  • Menaces et vulnérabilités potentielles pour l’application (par exemple, attaque DDoS de la couche application)
  • La conformité métier exigeait des tâches opérationnelles pour tester la stratégie de récupération d’urgence (par exemple, exercice d’échec de récupération d’urgence à effectuer chaque année pour la conformité).

Pour atteindre l’objectif de récupération pour différents scénarios, l’organisation doit décrire l’objectif de temps de récupération (RTO) et l’objectif de point de récupération (RPO) pour sa charge de travail en fonction des besoins de l’entreprise. Le RTO décrit la durée pendant laquelle l’application peut être arrêtée, généralement mesurée en heures, minutes ou secondes. Le RPO quant à lui décrit la quantité de données transactionnelles que l’entreprise peut accepter de perdre pour que les opérations normales reprennent. Il est essentiel d’identifier le RTO et le RPO de votre entreprise, car cela vous aidera à concevoir votre stratégie de récupération d’urgence de manière optimale. Les composants (calcul, stockage, base de données, etc.) impliqués dans la charge de travail SAP sont répliqués dans la région de récupération d’urgence à l’aide de différentes techniques (services natifs Azure, technologie de réplication de base de données native, scripts personnalisés). Chaque technique offre un RPO différent, qui doit être pris en compte lors de la conception d’une stratégie de récupération d’urgence. Sur Azure, vous pouvez utiliser certains des services natifs Azure, comme Azure Site Recovery ou Sauvegarde Azure, qui peuvent vous aider à répondre au RTO et au RPO de vos charges de travail SAP. Reportez-vous aux contrats SLA d’Azure Site Recovery et Sauvegarde Azure pour aligner de manière optimale votre RTO et votre RPO.

Considérations de conception pour la récupération d’urgence sur Azure

Il existe différents éléments à prendre en compte lors de la conception d’une solution de récupération d’urgence sur Azure. Les principes et concepts qui sont pris en compte pour concevoir des solutions de récupération d’urgence locales s’appliquent également à Azure. Toutefois, dans Azure, la sélection de régions est un élément clé de la stratégie de conception pour la récupération d’urgence. Par conséquent, gardez à l’esprit les points suivants lorsque vous choisissez la région de récupération d’urgence sur Azure.

  • Les exigences de conformité commerciales ou réglementaires peuvent spécifier une exigence de distance entre un site principal et un site de récupération d’urgence. Une exigence en matière de distance permet de proposer un certain niveau de disponibilité si une catastrophe naturelle touche un vaste emplacement géographique. Dans ce cas, une organisation peut choisir une autre région Azure comme site de récupération d’urgence. Les régions Azure sont souvent séparées par une grande distance qui peut être de centaines, voire de milliers de kilomètres, comme aux États-Unis. En raison de la distance, la latence d’aller-retour réseau est plus élevée, ce qui peut entraîner un RPO plus élevé.

  • Les clients qui souhaitent imiter leur stratégie de récupération d’urgence de métro locale sur Azure peuvent utiliser des zones de disponibilité pour la récupération d’urgence. Mais la stratégie de récupération d’urgence de zone à zone peut ne pas respecter les exigences de résilience en cas de catastrophe naturelle à grande échelle géographiquement.

  • Sur Azure, chaque région est jumelée à une autre région dans la même zone géographique (à l’exception de Brésil Sud). Cette approche permet la réplication des ressources fournies par la plateforme dans l’ensemble de la région. L’avantage du choix d’une région jumelée se trouve dans le document des paires de régions. Lorsqu’une organisation choisit d’utiliser des régions jumelées Azure, plusieurs points supplémentaires pour une charge de travail SAP doivent être pris en compte :

    • Tous les services Azure n’offrent pas de réplication interrégionale dans une région jumelée.

    • Les services et fonctionnalités Azure dans les régions Azure jumelées peuvent ne pas être symétriques. Par exemple, Azure NetApp Files, les références SKU de machine virtuelle comme la série M disponibles dans la région principale peuvent ne pas être disponibles dans la région jumelée. Pour vérifier si le produit ou les services Azure sont disponibles dans une région, consultez Produits Azure par région.

    • L’option GRS est disponible pour le compte de stockage avec un type de stockage standard qui réplique les données dans une région jumelée. Toutefois, le stockage standard n’est pas adapté aux disques de données virtuels ou aux SGBD SAP.

    • Le service de sauvegarde Azure utilisé pour sauvegarder les solutions prises en charge ne peut répliquer les sauvegardes qu’entre les régions jumelées. Pour toutes vos autres données, exécutez vos propres réplications avec des fonctionnalités SGBD natives comme SQL Server Always On, SAP HANA System Replication et d’autres services. Utilisez une combinaison constituée d’Azure Site Recovery, de rsync ou robocopy et d’autres logiciels tiers pour la couche Application SAP.

Déploiement de la charge de travail SAP de référence

Après avoir identifié une région de récupération d’urgence, il est important que l’étendue des services principaux Azure (comme le réseau, le calcul, le stockage) que vous avez configurés dans la région principale soit disponible et puisse être configurée dans la région de récupération d’urgence. L’organisation doit développer un modèle de déploiement de récupération d’urgence pour la charge de travail SAP. Le modèle de déploiement varie et doit s’aligner sur les besoins de l’organisation.

  • Déployez la charge de travail SAP de production dans votre région principale et la charge de travail hors production dans la région de récupération d’urgence.
  • Déployez toute la charge de travail SAP (production et hors production) dans votre région principale. La région de récupération d’urgence n’est utilisée qu’en cas de basculement.

L’architecture de référence suivante montre le système SAP NetWeaver classique s’exécutant sur Azure, ainsi que la haute disponibilité dans la région primaire. Le site secondaire indiqué ci-dessous est le site de récupération d’urgence où les systèmes SAP seront restaurés après un sinistre. Les régions principales et de récupération d’urgence font partie du même abonnement. Pour obtenir la récupération d’urgence pour la charge de travail SAP, vous devez identifier la stratégie de récupération pour chaque couche SAP ainsi que les différents services Azure que l’application utilise.

Les organisations doivent planifier et concevoir une stratégie de récupération d’urgence pour l’ensemble de leur paysage informatique. En règle générale, les systèmes SAP s’exécutant dans un environnement de production sont intégrés à différents services et interfaces, comme Active Directory, DNS, des applications tierces, etc. Vous devez donc également inclure les systèmes non SAP et autres services dans votre planification de récupération d’urgence. Ce document se concentre sur la planification de la récupération pour les applications SAP. Toutefois, vous pouvez étendre la taille et l’étendue de la planification de récupération d’urgence pour les composants dépendants en fonction de vos besoins.

Disaster Recovery reference architecture for SAP workload

Composants d’infrastructure de la solution de récupération d’urgence pour une charge de travail SAP

Une charge de travail SAP s’exécutant sur Azure utilise différents composants d’infrastructure pour exécuter une solution métier. Pour planifier la récupération d’urgence pour une telle solution, il est essentiel que tous les composants d’infrastructure configurés dans la région primaire soient disponibles et puissent également être configurés dans la région de récupération d’urgence. Les composants d’infrastructure suivants doivent être pris en compte lors de la conception d’une solution de récupération d’urgence pour la charge de travail SAP sur Azure.

  • Réseau
  • Calcul
  • Stockage

Réseau

  • ExpressRoute étend vos réseaux locaux dans le cloud Microsoft via une connexion privée avec l’aide d’un fournisseur de connectivité. Lors de la conception de l’architecture de récupération d’urgence, vous devez tenir compte de la création d’une connectivité réseau back-end robuste à l’aide d’un circuit ExpressRoute géoredondant. Il est conseillé de configurer au moins un circuit ExpressRoute de l’emplacement local vers la région primaire. Et les autres doivent se connecter à la région de reprise d’activité. Reportez-vous à l’article Conception d’Azure ExpressRoute pour la récupération d’urgence, qui décrit différents scénarios de conception de la récupération d’urgence pour ExpressRoute.

    Remarque

    Envisagez de configurer un VPN de site à site (S2S) comme sauvegarde d’Azure ExpressRoute. Pour plus d’informations, consultez Utiliser un VPN S2S comme sauvegarde pour le peering privé Azure ExpressRoute.

  • Les réseaux virtuels et les sous-réseaux couvrent toutes les zones de disponibilité d’une région. Pour la récupération d’urgence dans deux régions, vous devez configurer des réseaux virtuels et des sous-réseaux distincts sur la région de récupération d’urgence. Pour en savoir plus sur la configuration réseau dans la région de récupération d’urgence des machines virtuelles Azure, consultez Informations sur les réseaux dans la récupération d’urgence de machines virtuelles Azure.

  • Azure Standard Load Balancer fournit des éléments de mise en réseau pour la conception de haute disponibilité de vos systèmes SAP. Pour les systèmes en cluster, Standard Load Balancer fournit l’adresse IP virtuelle du service de cluster, comme les instances asCS/SCS et les bases de données s’exécutant sur des machines virtuelles. Pour exécuter un système SAP hautement disponible sur le site de récupération d’urgence, un équilibreur de charge distinct doit être créé et la configuration du cluster doit être ajustée en conséquence.

  • Azure Application Gateway est un équilibreur de charge de trafic web. Avec sa fonctionnalité Web Application Firewall, il s’agit d’un service adapté pour exposer des applications web à Internet avec une sécurité améliorée. Azure Application Gateway peut servir des clients publics (Internet) ou privés, ou les deux, en fonction de la configuration. Après le basculement, pour accepter le trafic HTTP(S) entrant similaire sur la région de récupération d’urgence, une instance Azure Application Gateway distincte doit être configurée dans la région de récupération d’urgence.

  • Comme les composants réseau (réseau virtuel, pare-feu, etc.) sont créés séparément dans la région de récupération d’urgence, vous devez vous assurer que la charge de travail SAP sur la région de récupération d’urgence est adaptée aux modifications réseau, comme la mise à jour du DNS, le pare-feu, etc.

  • Les réseaux virtuels dans les deux régions sont indépendants et, pour établir la communication entre les deux, vous devez activer le peering de réseau virtuel entre les deux régions.

Machines virtuelles

  • Sur Azure, différents composants d’un système SAP unique s’exécutent sur des machines virtuelles avec différents types de référence SKU. Pour la récupération d’urgence, la protection d’une application (SAP NetWeaver et non SAP) s’exécutant sur des machines virtuelles Azure peut être activée en répliquant des composants avec Azure Site Recovery vers une autre région ou zone Azure. Avec Azure Site Recovery, les machines virtuelles Azure sont répliquées en continu du site principal vers le site de récupération d’urgence. Selon la région de récupération d’urgence Azure sélectionnée, le type de référence SKU de machine virtuelle peut ne pas être disponible sur le site de récupération d’urgence. Vous devez vous assurer que les types de référence SKU de machine virtuelle requis sont également disponibles dans la région Azure DR. Consultez Produits Azure par région pour voir si le type de référence SKU de la famille de machines virtuelles requis est disponible ou non.

    Important

    Si le système SAP est configuré avec un groupe identique flexible avec FD=1, vous devez utiliser PowerShell pour configurer Azure Site Recovery pour la récupération d’urgence. Actuellement, il s’agit de la seule méthode disponible pour configurer la récupération d’urgence pour les machines virtuelles déployées dans un groupe identique.

  • Pour les bases de données s’exécutant sur des machines virtuelles Azure, il est recommandé d’utiliser la technologie de réplication de base de données native pour synchroniser les données avec le site de récupération d’urgence. Les grandes machines virtuelles sur lesquelles les bases de données s’exécutent peuvent ne pas être disponibles dans toutes les régions. Si vous utilisez des zones de disponibilité pour la récupération d’urgence, vous devez vérifier que les références SKU de machine virtuelle respectives sont disponibles dans la zone de votre site de récupération d’urgence.

    Notes

    Il n’est pas recommandé d’utiliser Azure Site Recovery pour les bases de données, car il ne garantit pas la cohérence de la base de données et présente des limitations d’attrition de données.

  • Avec les applications de production exécutées sur la région primaire à tout moment, des instances de réserve sont généralement utilisées pour économiser sur les coûts d’Azure. Si vous utilisez des instances réservées, vous devez vous inscrire pour un engagement d’un an ou d’une durée de 3 ans, ce qui peut ne pas être rentable pour le site de récupération d’urgence. La configuration d’Azure Site Recovery ne garantit pas la capacité de la référence SKU de machine virtuelle requise pendant votre basculement. Pour vous assurer que la capacité de référence SKU de machine virtuelle est disponible, vous pouvez envisager une option permettant d’activer la réservation de capacité à la demande. Cela réserve la capacité de calcul dans une région Azure ou une zone de disponibilité Azure pour toute durée sans engagement. Azure Site Recovery est intégré à la réservation de capacité à la demande. Avec cette intégration, vous pouvez utiliser la puissance des réservations de capacité avec Azure Site Recovery pour réserver la capacité de calcul dans la région de reprise d’activité après sinistre et garantir vos basculements. Pour plus d’informations, consultez les Limitations et restrictions de la réservation de capacité à la demande.

  • Un abonnement Azure a des quotas pour les familles de machines virtuelles (par exemple, la famille Mv2) et d’autres ressources. Parfois, les organisations souhaitent utiliser un autre abonnement Azure pour la récupération d’urgence. Chaque abonnement (principal et récupération d’urgence) peut avoir des quotas différents attribués pour chaque famille de machines virtuelles. Assurez-vous que l’abonnement utilisé pour le site de récupération d’urgence a suffisamment de quotas de calcul disponibles.

Stockage

  • Lors de l’activation d’Azure Site Recovery pour qu’une machine virtuelle configure la récupération d’urgence, le système d’exploitation et les disques de données locaux attachés aux machines virtuelles sont répliqués sur le site de récupération d’urgence. Pendant la réplication, les écritures réalisées sur les disques de machine virtuelle sont envoyées à un compte de stockage de cache de la région source. Les données sont envoyées de cet emplacement vers la région cible, et des points de récupération sont générés à partir des données. Lorsque vous basculez une machine virtuelle pendant une reprise d’activité après sinistre, un point de récupération est utilisé pour restaurer la machine virtuelle dans la région cible. Mais Azure Site Recovery ne prend pas en charge tous les types de stockage disponibles dans Azure. Pour plus d’informations, consultez Matrice de prise en charge d’Azure Site Recovery pour les stockages.

  • En plus des disques de données managés Azure attachés aux machines virtuelles, différentes solutions de stockage natif Azure sont utilisées pour exécuter une application SAP sur Azure. L’approche de récupération d’urgence pour chaque solution de stockage Azure peut différer, car tous les services de stockage disponibles dans Azure ne sont pas pris en charge avec Azure Site Recovery. Vous trouverez ci-dessous la liste des types de stockage généralement utilisés pour la charge de travail SAP.

    Type de stockage Recommandation de stratégie de récupération d’urgence
    Disque managé Azure Site Recovery
    NFS sur les fichiers Azure (LRS ou ZRS) Script personnalisé pour répliquer des données entre deux sites (par exemple rsync)
    NFS sur Azure NetApp Files Utiliser la Réplication inter-région des volumes Azure NetApp Files
    Disque partagé Azure (LRS ou ZRS) Solution personnalisée pour répliquer des données entre deux sites
    SMB sur les fichiers Azure (LRS ou ZRS) Utiliser RoboCopy pour copier des fichiers entre deux sites
    SMB sur Azure NetApp Files Utiliser la Réplication inter-région des volumes Azure NetApp Files

  • Pour les solutions de stockage personnalisées, comme le cluster NFS, vous devez vous assurer que la stratégie de récupération d’urgence appropriée est en place.

  • Différents services de stockage Azure natifs (comme Azure Files, Azure NetApp Files, disques partagés Azure) peuvent ne pas être disponibles dans toutes les régions. Ainsi, pour avoir une configuration SAP similaire sur la région de récupération d’urgence après le basculement, assurez-vous que le service de stockage respectif est proposé dans le site de récupération d’urgence. Pour plus d’informations, consultez les Produits Azure par région.

  • Si vous utilisez des zones de disponibilité pour la récupération d’urgence, gardez à l’esprit les points suivants :

    • La fonctionnalité Azure NetApp Files ne tient pas encore compte des zones. Actuellement, la fonctionnalité Azure NetApp Files n’est pas déployée dans toutes les zones de disponibilité d’une région Azure. Il peut donc arriver que le service Azure NetApp Files ne soit pas disponible dans la zone de disponibilité choisie pour votre stratégie de récupération d’urgence.
    • La réplication entre régions de volumes Azure NetApp File n’est disponible que dans des paires de régions fixes, pas entre zones.

  • Si vous avez configuré votre stockage avec l’intégration d’Active Directory, une configuration similaire doit également être effectuée sur le compte de stockage du site de récupération d’urgence.

  • Les disques partagés Azure nécessitent un logiciel de cluster comme le cluster de basculement Windows Server (WSFC) qui gère la communication entre les nœuds du cluster et le verrouillage en écriture. Par conséquent, pour avoir une stratégie de récupération d’urgence pour un disque partagé Azure, vous devez également disposer d’un disque partagé géré par le logiciel de cluster dans le site de récupération d’urgence. Vous pouvez ensuite utiliser un script pour copier des données d’un disque partagé attaché à un cluster dans la région primaire vers le disque partagé attaché à un autre cluster dans la région de récupération d’urgence.

Étapes suivantes