Partager via

Continuité d’activité et reprise d’activité pour une migration SAP

  • Article

Cet article s’appuie sur certaines des considérations et des suggestions qui sont définies dans le domaine de conception des zones d’atterrissage Azure pour BCDR. L’article a pour but de vous aider à comprendre les contraintes uniques qui pèsent sur une zone d’atterrissage prenant en charge une plateforme SAP. Étant donné que SAP est une plateforme stratégique, vous devez également consulter les autres conseils présentés dans la section Domaines de conception de la zone d’atterrissage Azure de cette documentation et les incorporer dans votre conception.

Scénario et portée

Votre architecture doit incorporer des principes qui répondent aux scénarios de continuité d’activité et de reprise d’activité (BCDR) locaux. Ces principes sont également applicables à Azure. La principale différence réside dans le fait qu’Azure peut avoir plus de capacité matérielle que votre environnement local pour compenser une défaillance de l’hôte. Vous pouvez récupérer automatiquement les machines virtuelles Azure les plus importantes en les configurant pour qu’elles redémarrent sur un autre serveur. Configurez vos déploiements Azure pour utiliser les mêmes conditions que vos déploiements locaux. Si vous avez déployé des systèmes locaux ou du matériel nu en utilisant des configurations de cluster de basculement automatique, déployez-les de la même façon sur Azure. Les applications SAP qui exécutent les processus métier les plus critiques d’une organisation ont les besoins suivants :

  • Disponibilité des processus métier et de service.
  • Objectifs de délai de récupération (RTO) pour les scénarios de défaillance ou de sinistre.
  • Objectifs de point de récupération (RPO) dans les scénarios d’échec.
  • Tâches de gestion opérationnelle et de cycle de vie, et technologie qui comble les lacunes dans les scénarios d’échec. Ces tâches de gestion incluent la mise à jour corrective des systèmes d’exploitation invités et des systèmes de gestion de base de données, le clonage et l’actualisation des systèmes SAP.

Conseil

Acceptez une solution de haute disponibilité et de récupération d’urgence (HADR) pour chacun des archétypes de votre paysage SAP de manière anticipée. Assurez-vous que tous les composants SAP sont couverts par une solution appropriée.

Configurez HADR sur Azure de manière anticipée, dans au moins un paysage, et continuez à l’exécuter à cet endroit. Cela donne l’occasion à vos équipes d’acquérir de l’expérience sur les technologies impliquées, qui peuvent être différentes des technologies existantes. Configurer HADR de manière anticipée peut également vous aider à développer et à faire évoluer vos procédures d’exploitation standard (SOP).

Prévoyez d’avoir une haute disponibilité, une récupération d’urgence et une protection de sauvegarde complètes pour les charges de travail de production dès que le système est actif.

Cet article aborde les aspects suivants de la continuité d’activité et reprise d’activité pour un scénario SAP à l’échelle de l’entreprise :

  • Haute disponibilité au sein d’une région Azure.
  • Considérations relatives à la sauvegarde et la restauration.
  • Critères de choix entre la récupération d’urgence interrégionale et régionale.

Haute disponibilité au sein d’une région Azure

Les sections suivantes fournissent des considérations et des suggestions relatives à la haute disponibilité dans une région Azure pour un scénario d’entreprise SAP.

Considérations relatives à la conception de la haute disponibilité

Pour la haute disponibilité, le but est de fournir une disponibilité pour le point de défaillance unique du logiciel SAP, comme par exemple :

  • Systèmes de gestion de base de données.
  • Points de défaillance uniques dans l’application, comme ABAP SAP et ASCS + SCS. SAP NetWeaver et l’architecture SAP S/4HANA en sont des exemples.
  • Autres outils, comme SAP Web Dispatcher.

Pour les autres scénarios, ne limitez pas la disponibilité à l’infrastructure ni aux défaillances logicielles. Appliquez la disponibilité à toutes les tâches de gestion de cycle de vie nécessaires, comme la mise à jour corrective du système d’exploitation sur les machines virtuelles, le système de gestion de base de données et le logiciel SAP. Pour réduire au minimum les pannes pouvant se produire pendant les temps d’arrêt planifiés et les opérations de gestion de cycle de vie, utilisez des outils communs qui protègent vos systèmes contre les interruptions de service non planifiées.

SAP et les bases de données SAP prennent en charge les clusters à basculement automatique. Sur Windows, le clustering de basculement Windows Server prend en charge le basculement. Sur Linux, Linux Pacemaker ou des outils tiers comme SIOS Protection Suite et Veritas InfoScale prennent en charge le basculement. Avec Azure, vous pouvez uniquement déployer la configuration de la haute disponibilité d’un sous-ensemble dans votre propre centre de données.

Pour en savoir plus sur la manière dont Azure prend en charge SAP, consultez Scénarios pris en charge pour les charges de travail SAP sur des machines virtuelles Azure et Scénarios pris en charge pour SAP HANA sur Azure (grandes instances).

Pour la couche SGBD, le modèle d’architecture courante consiste à répliquer les bases de données en même temps et avec des piles de stockage différentes de celles que les machines virtuelles principales et secondaires utilisent. Azure ne prend pas en charge les architectures dans lesquelles les machines virtuelles principales et secondaires partagent le stockage des données SGBD. Azure ne prend pas non plus en charge les journaux des transactions et de phase de restauration par progression. Le principe directeur consiste à utiliser deux piles de stockage indépendantes, même si elles s’appuient sur des partages NFS (Network File System). Cette approche est la principale limitation quand vous comparez ce qui est possible localement à ce qui est possible sur Azure.

Azure fournit d’autres options du fait de sa prise en charge des partages NFS ou SMB (Server Message Block). Vous pouvez utiliser des disques partagés Azure dans Windows pour les composants ASCS + SCS et des scénarios de haute disponibilité spécifiques. Configurez vos clusters de basculement séparément pour les composants de la couche Application SAP et la couche SGBD. Azure ne prend pas en charge pour le moment les architectures de haute disponibilité qui associent les composants de la couche Application SAP et la couche SGBD dans un seul cluster de basculement.

La plupart des clusters de basculement pour les composants de couche Application SAP et la couche SGBD requièrent une adresse IP virtuelle pour un cluster de basculement. Une exception courante concerne l’utilisation d’Oracle Data Guard. qui ne nécessite pas d’adresse IP virtuelle. Azure Load Balancer doit gérer l’adresse IP virtuelle pour tous les autres cas. Un principe de conception consiste à utiliser un seul équilibreur de charge par configuration de cluster. Nous vous recommandons d’utiliser la version standard de l’équilibreur de charge. Pour plus d’informations, consultez Connectivité de point de terminaison public pour les machines virtuelles avec Azure Standard Load Balancer dans les scénarios de haute disponibilité SAP.

Pour plus d’informations et d’options, consultez Scénarios et architecture de haute disponibilité pour SAP NetWeaver.

Voici les contrats SLA au niveau de la plateforme pour les différentes options de déploiement à haute disponibilité. Les partenaires qui offrent les services managés fournissent le contrat SLA au niveau de l’application.

Niveau Scénario HA Contrat SLA de plateforme
Niveau 1 Zone de disponibilité 99,99 %
Niveau 2 Groupe à haute disponibilité 99,95 %
Niveau 3 Une seule machine virtuelle (auto-adaptation) 99,9 %

Pour plus d'informations, consultez la section suivante.

Groupes à haute disponibilité Azure et zones de disponibilité

Avant de déployer votre infrastructure à haute disponibilité et en fonction de la région que vous avez choisie, déterminez si vous voulez effectuer un déploiement avec un groupe à haute disponibilité Azure ou une zone de disponibilité. Les principales différences pour les machines virtuelles déployées avec un groupe à haute disponibilité sont les suivantes :

  • Les machines virtuelles ne sont pas réparties entre différentes zones de disponibilité.
  • Le type de machines virtuelles que vous pouvez déployer par le biais d’un groupe à haute disponibilité est restreint, car l’hôte est défini par la première machine virtuelle qui est déployée dans le groupe. Par exemple, vous ne pouvez pas combiner les machines virtuelles de série M et E à un seul groupe à haute disponibilité.

Un avantage de déployer votre architecture de haute disponibilité dans différentes zones de disponibilité est que votre contrat de niveau de service (SLA) peut être plus élevé pour les machines virtuelles. Pour plus d’informations, voir les contrats SLA des machines virtuelles Azure. Selon la région Azure, vous pouvez découvrir différentes conditions de latence réseau dans le trafic réseau entre les machines virtuelles. Pour plus d’informations, voir les Configurations de la charge de travail SAP avec des zones de disponibilité Azure

Si vous choisissez une approche de déploiement zonal, tenez compte des effets de la latence interzone pour la région Azure choisie, entre le serveur d’applications et la base de données et entre les deux nœuds de base de données, sur les choix de conception des performances et de l’architecture.

Si vous utilisez un déploiement zonal actif/passif pour le niveau de serveur d’applications (les serveurs d’applications doivent se connecter à la base de données dans la même zone de disponibilité), générez une automatisation et une SOP pour activer la récupération rapide et automatisée en cas de basculement de base de données.

Si vous utilisez des zones de disponibilité dans votre solution SAP, concevez tous les autres services et composants d’infrastructure Azure dans votre paysage SAP pour la redondance de zone, afin de pouvoir obtenir une véritable redondance de zone. Voici quelques exemples de services et de composants à prendre en compte : passerelles Azure ExpressRoute, Azure Load Balancer, Azure Files, Azure NetApp Files, proxy inverse, pares-feux, antivirus et infrastructure de sauvegarde.

Recommandations de conception pour la haute disponibilité

  • Azure propose plusieurs options pour vous aider à respecter les contrats de niveau de service en lien avec l’infrastructure de vos applications. Vous devez choisir la même option pour les trois composants SAP : services centraux, serveur d’applications et base de données. Pour plus d’informations sur les contrats de niveau de service pour les machines virtuelles, les groupes à haute disponibilité et les zones de disponibilité, consultez Contrat de niveau de service pour machines virtuelles.

  • Lorsque vous déployez des machines virtuelles dans un groupe à haute disponibilité, l’alignement avec les domaines d’erreur et de mise à jour empêche les machines virtuelles d’être sur le même matériel hôte, ce qui offre une protection contre les défaillances matérielles. Lorsque vous déployez des machines virtuelles via des zones de disponibilité et utilisez des zones différentes, les machines virtuelles sont créées dans différents emplacements physiques. Cette configuration offre une protection supplémentaire contre les problèmes d’alimentation, de refroidissement ou de mise en réseau qui affectent les centres de données de la zone dans son ensemble. Toutefois, vous ne pouvez pas déployer de groupes à haute disponibilité Azure au sein d’une zone de disponibilité Azure, sauf si vous utilisez des groupes de placements de proximité.

    Si vous choisissez une approche de déploiement zonale, le SGBD SAP, les services centraux et les couches d’application s’exécutent dans différentes zones de disponibilité. Toutefois, chaque zone de disponibilité aura probablement des serveurs d’applications multiples. Dans ce scénario, les serveurs d’applications de chaque zone ne bénéficient pas automatiquement des domaines d’erreur et des domaines de mise à jour. Vous pouvez bénéficier de ces avantages en utilisant des groupes à haute disponibilité, comme décrit dans Groupes de placement de proximité Azure pour une latence réseau optimale avec SAP.

  • Lorsque vous créez des groupes à haute disponibilité, utilisez le nombre maximal de domaines d’erreur et de domaines de mise à jour disponibles. Par exemple, si vous déployez plus de deux machines virtuelles dans un groupe à haute disponibilité, utilisez le nombre maximal de domaines d’erreur (trois) et suffisamment de domaines de mise à jour pour limiter l’effet des défaillances matérielles physiques potentielles, des pannes réseau ou des interruptions d’alimentation, en plus de la maintenance planifiée Azure. Le nombre par défaut de domaines d’erreur est de deux, et vous ne pouvez pas le modifier en ligne ultérieurement.

  • Dans un déploiement de groupe à haute disponibilité, chaque composant d’un système SAP doit être situé dans son propre groupe à haute disponibilité. Les services centraux, les bases de données et les machines virtuelles SAP doivent être regroupés dans leurs propres groupes à haute disponibilité.

  • Quand vous utilisez des groupes de placement de proximité Azure dans un déploiement de groupe à haute disponibilité, les trois composants SAP (services centraux, serveur d’applications et base de données) doivent se trouver dans le même groupe de placement de proximité.

  • Si vous utilisez des groupes de placement de proximité, utilisez-en un par SID SAP. Les groupes ne s’étendent pas au-delà des zones de disponibilité ni des régions Azure.

  • Quand vous utilisez des groupes de placement de proximité Azure dans un déploiement de zone de disponibilité, les deux composants SAP (services centraux et serveur d’applications) doivent se trouver dans le même groupe de placement de proximité. Les machines virtuelles de base de données dans les deux zones ne font plus partie des groupes de placement de proximité. Les groupes de placement de proximité par zone sont étendus avec le déploiement de la machine virtuelle qui exécute les instances SAP ASCS + SCS. L’avantage de cette configuration est que vous disposez d’une plus grande flexibilité pour redimensionner les machines virtuelles. Il est également plus facile de passer aux nouveaux types de machines virtuelles dans la couche SGBD ou la couche Application du système SAP.

  • Actuellement, Azure ne prend pas en charge la combinaison ASCS et haute disponibilité de base de données dans un seul cluster Pacemaker Linux. Séparez-les en clusters individuels. Vous pouvez combiner jusqu’à cinq clusters de services centraux multiples dans une paire de machines virtuelles.

  • Utilisez une référence SKU Standard Load Balancer avec des clusters ASCS et de bases de données.

  • Exécutez tous les systèmes de production sur des disques SSD managés Premium et utilisez Azure NetApp Files ou des disques de stockage Ultra. Au moins le disque de système d’exploitation doit être de niveau Premium pour obtenir de meilleures performances et le meilleur contrat de niveau de service.

  • Déployez les deux machines virtuelles de la paire de haute disponibilité dans un groupe à haute disponibilité ou dans des zones de disponibilité. Ces machines virtuelles doivent avoir la même taille et la même configuration de stockage.

  • Utilisez la technologie de réplication de base de données native pour synchroniser la base de données dans une paire de haute disponibilité.

  • Utilisez un des services suivants pour exécuter des clusters de services centraux SAP, en fonction du système d’exploitation :

  • Configurez les paramètres de délai d’attente de cluster, tels que recommandés dans la documentation pour les clusters de services centraux et de base de données.

Stockage pour les charges de travail SAP

  • Choisir les options de stockage appropriées est un aspect de la conception pour la résilience de votre charge de travail SAP. La conception des charges de travail SAP sur le stockage Azure est destinée à maintenir la latence au minimum et à optimiser le débit. Prenez en compte votre implémentation et en quoi les conseils ci-dessous peuvent participer à la prise de décisions architecturales pour votre implémentation SAP sur Azure. Pour plus d’informations sur les différents types de stockage et leur compatibilité avec les charges de travail et les composants SAP, consultez Types de stockage Azure pour les charges de travail SAP.

  • Vous devez exécuter SAP HANA sur Azure uniquement sur les types de stockage qui sont certifiés par SAP. Notez que certains volumes doivent être exécutés sur des configurations de disque spécifiques, le cas échéant. Ces configurations sont l’activation de l’accélérateur d’écriture et l’utilisation du stockage Premium. Vous devez également vérifier que le système de fichiers qui s’exécute sur le stockage est compatible avec le SGBD qui s’exécute sur la machine. Pour plus d’informations, consultez Configurations de stockage pour SAP HANA.

  • En plus des disques de données managés Azure attachés aux machines virtuelles, diverses solutions de stockage partagé natif Azure sont utilisées pour exécuter des applications SAP sur Azure. Votre configuration de haute disponibilité peut différer, car certains services de stockage disponibles sur Azure ne sont pas pris en charge par Azure Site Recovery. Les types de stockage suivants sont généralement utilisés pour les charges de travail SAP.

    Type de stockage Prise en charge de la configuration de haute disponibilité
    Disques partagés Azure (LRS ou ZRS) Cluster de basculement Windows Server. Pour plus d’informations sur la configuration, consultez Concevoir la haute disponibilité SAP avec le clustering de basculement Windows Server.
    NFS sur Azure Files (LRS ou ZRS) Cluster basé sur Pacemaker dans les environnements Linux. Veillez à vérifier la disponibilité de NFS dans différentes régions.
    NFS sur Azure NetApp Files Cluster basé sur Pacemaker dans les environnements Linux. Pour plus d’informations, consultez Azure NetApp Files pour les machines virtuelles SAP.
    SMB sur Azure Files (LRS ou ZRS) Cluster de basculement Windows Server. Pour plus d’informations sur la configuration, consultez Haute disponibilité pour SAP NetWeaver sur des machines virtuelles Azure sur Windows avec partage SMB Azure Files Premium pour les applications SAP.
    SMB sur Azure NetApp Files Cluster de basculement Windows Server. Pour plus d’informations sur la configuration, consultez Haute disponibilité pour SAP NetWeaver sur des machines virtuelles Azure sur Windows avec Azure NetApp Files (SMB) pour les applications SAP.

  • Au lieu des services de stockage partagé natif Azure, vous pouvez utiliser des clusters NFS traditionnels (basés sur la réplication DRBD), GlusterFS ou un volume partagé de cluster avec les espaces de stockage direct comme autre solution de stockage partagé afin d’exécuter des charges de travail SAP sur Azure. Ces choix sont particulièrement utiles quand les services de stockage partagé natif Azure ne sont pas disponibles dans la région Azure ciblée ou ne prennent pas en charge l’architecture cible. Pour plus d’informations sur la disponibilité du service de stockage, consultez Produits Azure par région.

  • Pour en savoir plus sur les options de stockage disponibles pour les charges de travail SAP sur Azure, consultez les recommandations et instructions de stockage pour la configuration de la reprise d’activité.

Sauvegarde et restauration

Les sections suivantes décrivent les considérations et suggestions relatives à la sauvegarde et à la restauration dans un scénario SAP.

Bien que la sauvegarde et la restauration ne soient généralement pas considérées comme une solution de haute disponibilité adéquate pour une charge de travail SAP de production, la technologie procure d’autres avantages. La plupart des entreprises qui utilisent des applications SAP doivent suivre les réglementations de conformité qui nécessitent le stockage des sauvegardes pendant de nombreuses années. Il est également essentiel d’avoir une sauvegarde et de pouvoir effectuer une restauration à partir de celle-ci dans d’autres scénarios. L’hypothèse est que vous avez déjà mis en place et que vous suivez les bonnes pratiques de sauvegarde et de restauration pour les applications SAP. Vous pouvez ainsi effectuer les tâches suivantes :

  • Effectuer une restauration à un instant dans le passé pour vos bases de données de production à tout moment et dans un laps de temps qui répond à votre RTO. La restauration à un instant dans le passé protège généralement des erreurs d’opérateur, comme la suppression de données, soit sur la couche SGBD, soit par le biais de SAP.

  • Gérer un magasin dans lequel vous conservez vos sauvegardes à long terme pour respecter les réglementations de conformité.

  • Utiliser les sauvegardes de base de données pour cloner le système SAP et les restaurer sur un autre serveur ou une autre machine virtuelle.

  • Utilisez les données de la base de données de production des sauvegardes de base de données pour actualiser les systèmes hors production.

  • Sauvegarder des serveurs d’applications SAP et des machines virtuelles, disques ou instantanés de machines virtuelles.

Quand vous sauvegardez et restaurez localement, vous devez apporter ces fonctionnalités aux systèmes SAP dans Azure.

Si vous êtes satisfait de votre solution actuelle, vérifiez si votre fournisseur de sauvegarde prend en charge les déploiements Azure ou s’il a une solution SaaS pour Azure.

Azure propose un service SaaS de sauvegarde, Sauvegarde Azure, qui prend des instantanés de machine virtuelle et gère le streaming SQL Server et les sauvegardes SAP HANA. Si vous utilisez Azure NetApp Files pour stocker vos bases de données SAP HANA, vous pouvez exécuter des sauvegardes basées sur des captures instantanées de stockage HANA.

Recommandations de conception pour la sauvegarde et la restauration

  • Vous pouvez utiliser Sauvegarde Azure pour sauvegarder des machines virtuelles de serveurs d’applications SAP et de services centraux.

  • Vous pouvez utiliser une sauvegarde SAP HANA pour des déploiements HANA allant jusqu’à 8 To. Pour plus d’informations, voir le tableau de prise en charge pour la sauvegarde des bases de données SAP HANA sur des machines virtuelles Azure.

  • Si vous utilisez une solution de sauvegarde IaaS, dimensionnez l’infrastructure de sauvegarde pour vous assurer qu’elle peut sauvegarder tous les systèmes de taille de production simultanément ou comme dans un scénario réel, dans les délais prévus et à l’aide d’une configuration de production ou d’une configuration similaire en termes de mise en réseau, de sécurité, etc.

  • Testez les délais de sauvegarde et de récupération pour vérifier qu’ils répondent à vos exigences en matière de RTO pour la restauration simultanée de tous les systèmes après un sinistre.

  • Idéalement, évitez d’extraire vos sauvegardes d’Azure vers votre infrastructure de sauvegarde locale, en particulier avec les bases de données volumineuses. Cela affecte la quantité de bande passante utilisée par les circuits ExpressRoute.

  • Testez la charge des outils de sauvegarde et de récupération dans le cadre du plan de test des performances.

Récupération d'urgence

Les sections suivantes décrivent les considérations et suggestions de conception pour la récupération d'urgence dans un scénario SAP.

Considérations de conception pour la reprise d’activité

La carte des régions Azure affiche plus de 65 régions Azure, qui n’exécutent pas toutes les mêmes services. Dans les déploiements de logiciels SAP plus importants, plus particulièrement ceux qui utilisent SAP HANA, recherchez les régions Azure qui offrent des machines virtuelles Azure de série M ou de série Mv2. Le stockage Azure associe également différentes régions pour répliquer un plus petit sous-ensemble de types de stockage dans une autre région. Pour plus d’informations, consultez la présentation des régions jumelées Azure.

Les principaux défis liés au jumelage des régions Azure pour les charges de travail SAP sont les suivants :

  • Les paires ne sont pas toujours cohérentes avec les services de machine virtuelle de série M ou MV2. De nombreuses organisations qui déploient leurs systèmes SAP n’utilisent pas les régions jumelées Azure. Au lieu de cela, elles choisissent des régions en fonction de la disponibilité des types de machines virtuelles requises.

  • Vous pouvez répliquer le stockage standard entre des régions jumelées, mais vous ne pouvez pas utiliser le stockage standard pour stocker vos bases de données ou vos disques durs virtuels. Vous pouvez répliquer des sauvegardes uniquement entre les régions jumelées que vous utilisez. Pour toutes vos autres données, exécutez votre réplication avec des fonctionnalités SGBD natives comme SQL Server Always On ou SAP HANA System Replication. Utilisez une combinaison de Site Recovery, rsync ou robocopy, et d’autres logiciels tiers pour la couche Application SAP.

  • En cas de sinistre, plusieurs clients affectés dans une région Azure veulent basculer vers la région DR jumelée correspondante. Cette situation conduit à la concurrence des ressources pour activer les machines virtuelles dormantes dans la région DR. La solution de contournement est d’exécuter des systèmes hors production dans la région DR et d’utiliser les mêmes ressources pour héberger les réplicas DR des systèmes de production. Cette utilisation à double objectif des infrastructures Azure dans la région DR vous permet d’éviter les contraintes de capacité de ressources.

Une autre point important à prendre en compte est la sécurisation de la capacité d’exploitation nécessaire dans la région sinistrée. Si un sinistre se produit, vous pouvez avoir besoin d’exécuter l’application SAP pendant une courte période avec une capacité informatique minimale et des ressources humaines critiques uniquement le temps de récupérer un fonctionnement normal dans la région primaire. Pour cela, vous devez avoir une infrastructure informatique minimale disponible dans la région DR.

Après avoir défini vos régions Azure, vous devez choisir un modèle de déploiement :

  • Allez-vous déployer des systèmes de production dans votre région primaire ?
  • Allez-vous déployer des systèmes SAP hors production dans la région de récupération d'urgence ?
  • Allez-vous utiliser une architecture qui regroupe tous les systèmes SAP dans la région primaire ? Cette configuration garantit que la région de récupération d'urgence est utilisée uniquement pour la récupération d'urgence.

La plupart des organisations utilisent les deux régions pour l’exploitation des systèmes SAP. Les organisations qui exécutent des copies complètes des systèmes de production en tant que systèmes de test de régression métier envisagent généralement d’utiliser le système de test de régression métier de la gamme de produits SAP comme cible de récupération d'urgence.

Quand vous choisissez une région de reprise d’activité, veillez à avoir une connectivité ExpressRoute établie sur cette région. Si plusieurs circuits ExpressRoute se connectent à Azure, au moins l’un d’eux doit se connecter à la région Azure primaire. Les autres doivent se connecter à la région de récupération d'urgence. Ce type d’architecture vous connecte au réseau Azure dans une autre zone géographique/géopolitique et permet de protéger votre connexion en cas de catastrophe dans une autre région Azure.

Certaines organisations utilisent une architecture de haute disponibilité et de reprise d’activité qui regroupe la haute disponibilité et la reprise d’activité dans la même région Azure. Mais ce regroupement de la haute disponibilité et de la reprise d’activité n’est pas idéal. Les zones de disponibilité Azure prennent en charge cette architecture. Comme la distance entre les zones de disponibilité au sein d’une région Azure n’est pas aussi importante que la distance entre deux régions Azure, une catastrophe naturelle peut mettre en péril les services d’application dans la région où elle se produit. Vous devez également prendre en compte la latence entre les serveurs d’application et les serveurs de base de données SAP. D’après la Note SAP 1100926, une durée d’aller-retour inférieure ou égale à 0,3 ms est une bonne valeur, et une durée inférieure ou égale à 0,7 ms est une valeur modérée. Par conséquent, pour les zones avec des latences élevées, vous devez mettre en place des procédures opérationnelles pour garantir que les serveurs d’application et les serveurs de base de données SAP s’exécutent tout le temps dans la même zone. Les organisations choisissent cette architecture pour les raisons suivantes :

  • La compatibilité est suffisante avec les configurations qui prennent en charge des distances plus petites entre le déploiement de production et une cible de récupération d'urgence.
  • La souveraineté des données est un facteur.
  • Des facteurs géopolitiques sont impliqués.
  • Il s’agit d’une option à faible coût qui prend en charge les défaillances zonales, elle est parfois combinée avec le transfert de sauvegarde vers la région secondaire pour les catastrophes naturelles qui ont un grand rayon d’impact.

Un autre facteur à prendre en compte lorsque vous choisissez votre région de récupération d'urgence est le RPO et le RTO du basculement vers le site de récupération d'urgence. Plus la distance entre les régions de production et de reprise d’activité est grande, plus la latence du réseau est élevée. Bien que vous répliquiez de façon asynchrone entre des régions Azure, une latence du réseau peut avoir un impact sur le débit que vous pouvez répliquer et la cible RPO. Il est souvent possible de réduire votre RPO à l’aide d’une combinaison de l’architecture de haute disponibilité et de la récupération d’urgence. Mais cette configuration présente un risque potentiellement plus élevé en cas de catastrophes naturelles à grande échelle.

Recommandations de conception pour la reprise d’activité

  • Veillez à ce que le routage CIDR (Classless InterDomain Routing) pour le réseau virtuel principal n’entre pas en conflit avec le CIDR du réseau virtuel du site de récupération d'urgence, ni le chevaucher.
  • Configurez des connexions ExpressRoute à partir d’un emplacement local vers les régions de récupération d'urgence Azure primaire et secondaire.
  • Une alternative à l’utilisation d’ExpressRoute est la configuration de connexions VPN du site local vers les régions Azure primaire et secondaire de reprise d’activité.
  • Utilisez Site Recovery pour répliquer un serveur d’applications sur un site de reprise d’activité. Site Recovery peut aussi vous aider à répliquer les machines virtuelles du cluster des services centraux sur le site de reprise d’activité. Quand vous invoquez la récupération d'urgence, vous devez reconfigurer le cluster Linux Pacemaker sur le site de récupération d'urgence. Par exemple, vous devez remplacer l’adresse IP virtuelle ou le SBD, exécuter corosync.conf, etc.
  • Répliquez le contenu du coffre de clés comme les certificats, les secrets ou les clés dans différentes régions afin de pouvoir déchiffrer les données dans la région DR.
  • Utilisez la réplication entre régions dans Azure NetApp Files (actuellement disponible en préversion publique) pour synchroniser les volumes de fichiers entre la région primaire et la région de reprise d’activité.
  • Utilisez la réplication native de la base de données, plutôt que Site Recovery, pour synchroniser les données sur le site de récupération d'urgence.
  • Appairez les réseaux virtuels principal et de reprise d’activité. Par exemple, pour la réplication de système HANA, un réseau virtuel SAP HANA DB a besoin d’être appairé avec le réseau virtuel SAP HANA DB du site de reprise d’activité.
  • Si vous utilisez le stockage Azure NetApp Files pour vos déploiements SAP, créez au moins deux comptes Azure NetApp Files au niveau Premium, dans deux régions.
  • Envisagez de regrouper les systèmes en fonction de leur importance métier et de leur dépendance de proximité en fonction des performances de l’application. Déployez chaque groupe dans une région distincte dans une construction de région jumelée pour réduire l’impact d’une panne régionale sur l’entreprise. Par exemple, deux systèmes ECC critiques desservant deux unités commerciales différentes peuvent être déployés au Royaume-Uni Sud et au Royaume-Uni Ouest pour réduire l’impact d’une panne régionale.

Étapes suivantes

Options de déploiement pour SAP dans Azure