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

Article
10/15/2024

Cet article s’appuie sur certaines des considérations et des recommandations dans le domaine de conception de zones d’atterrissage Azure pour BCDR. Cet article décrit les contraintes uniques sur les zones d’atterrissage qui prennent en charge une plateforme SAP. SAP est une plateforme stratégique. Vous devez donc également incorporer d’autres conseils stratégiques dans votre conception.

Scénario et portée

Incorporez dans votre architecture des principes pour traiter les scénarios de continuité d’activité et de reprise d’activité (BCDR) en local. Ces principes sont également applicables à Azure. Azure peut toutefois disposer d’une capacité matérielle supérieure à celle de votre environnement local pour compenser une défaillance de l’hôte. Pour récupérer automatiquement les machines virtuelles Azure les plus volumineuses, vous pouvez les configurer 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 utilisez des configurations de cluster de basculement automatique pour déployer des systèmes locaux ou du matériel nu, déployez-les de la même manière sur Azure. Les applications SAP qui exécutent les processus métier les plus critiques de votre organisation nécessitent :

Disponibilité des processus métier et de service.
Des objectifs de délai de récupération (RTO) pour les scénarios d'échec ou d'urgence.
Objectifs de point de récupération (RPO) dans les scénarios d’échec.
Des tâches de gestion opérationnelle et de gestion de cycle de vie et une technologie qui s'exécute lors de 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

Déterminez dès le départ une solution de haute disponibilité et de reprise d’activité (HADR) pour chacun des archétypes de votre paysage SAP. Assurez-vous que la solution couvre tous les composants SAP.

Configurez une solution HADR sur Azure à l'avance dans au moins un paysage et maintenez-la active. Vos équipes peuvent ensuite se familiariser avec les technologies de la solution, qui peuvent différer des technologies existantes. Configurez HADR à l’avance pour 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 permettant de choisir entre la reprise d’activité après sinistre 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é

Lorsque vous implémentez une haute disponibilité, l’objectif est de fournir une disponibilité pour le point de défaillance unique du logiciel SAP, par exemple :

Systèmes de gestion de base de données.
Points de défaillance uniques dans une application, tels que SAP Advanced Business Application Programming (ABAP), ABAP SAP Central Services (ASCS) et SAP Central Services (SCS). Parmi les exemples de haute disponibilité, citons SAP NetWeaver et l’architecture SAP S/4HANA.
Autres outils, comme SAP Web Dispatcher.

Pour d'autres scénarios, ne limitez pas la disponibilité aux défaillances d’infrastructure ou aux défaillances logicielles. Appliquez une disponibilité à toutes les tâches de gestion du cycle de vie nécessaires. Par exemple, vous pouvez corriger le système d’exploitation des machines virtuelles, le système de gestion de base de données (SGBD) 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, la fonctionnalité de clustering de basculement Windows Server 2022 prend en charge le basculement. Dans Linux, Linux Pacemaker ou d'autres outils partenaires tels que SIOS Protection Suite et Veritas InfoScale prennent en charge le basculement. Dans Azure, vous pouvez uniquement déployer une configuration à haute disponibilité de sous-ensemble dans votre propre centre de données.

Pour plus d’informations, consultez Scénarios pris en charge pour les charges de travail SAP sur les machines virtuelles Azure et Scénarios pris en charge pour les grandes instances SAP HANA.

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 de transactions ou les journaux de restauration. Le principe directeur consiste à utiliser deux piles de stockage indépendantes, même si elles s’appuient sur des partages NFS (Network File System). Ces limites sont propres aux solutions Azure et non aux solutions locales.

Azure propose d’autres options, car il prend en charge les protocoles de partage NFS et SMB (Server Message Block). Vous pouvez utiliser des disques partagés Azure dans Windows pour les composants ASCS et SCS et des scénarios de haute disponibilité spécifiques. Configurez vos clusters de basculement séparément pour les composants de la couche d'application SAP et la couche SGBD. Azure ne prend pas en charge les architectures de haute disponibilité qui combinent les composants de la couche d'application SAP et la couche SGBD dans un seul cluster de basculement.

La plupart des clusters de basculement pour les composants de la couche d'application SAP et de 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 requiert pas d’adresse IP virtuelle. Azure Load Balancer doit gérer l’adresse IP virtuelle pour tous les autres cas. Vous pouvez utiliser un équilibreur de charge pour chaque 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 Load Balancer Standard dans des scénarios de haute disponibilité SAP.

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

Le tableau ci-dessous présente les contrats de niveau de service (SLA) au niveau de la plateforme pour différentes options de déploiement à haute disponibilité. Les partenaires qui fournissent les services managés fournissent également le contrat SLA au niveau de l’application.

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

Groupes à haute disponibilité Azure et zones de disponibilité

Avant de déployer votre infrastructure à haute disponibilité, déterminez si vous effectuez un déploiement avec un groupe à haute disponibilité ou une zone de disponibilité Azure, en fonction de la région que vous avez choisie. Les principales différences pour les machines virtuelles que vous déployez 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 via un groupe à haute disponibilité est restreint, car l’hôte est défini par la première machine virtuelle que vous déployez dans le groupe. Par exemple, vous ne pouvez pas combiner des machines virtuelles de série M et des machines virtuelles de série E dans un seul groupe à haute disponibilité.

Lorsque vous déployez votre architecture de haute disponibilité dans différentes zones de disponibilité, vous pouvez disposer d’un contrat SLA plus élevé pour les machines virtuelles. Pour plus d’informations, consultez 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 optez pour un déploiement zonal, réfléchissez à la façon dont la latence inter-zone de la région Azure choisie peut affecter les performances et les choix de conception de l’architecture. Tenez compte de la latence entre le serveur d’application et la base de données, mais également entre les deux nœuds de base de données.

Si vous utilisez un déploiement zonal actif/passif pour la couche serveur d’applications dans lequel les serveurs d’application doivent se connecter à la base de données dans la même zone de disponibilité, configurez l’automatisation et créez une SOP pour permettre une récupération rapide et automatisée en cas de basculement d'une 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. Les services et composants à prendre en compte comprennent par exemple les passerelles Azure ExpressRoute, Load Balancer, Azure Files, Azure NetApp Files, les proxys inverses, les pare-feu, les services antivirus et l’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’application et base de données. Pour plus d’informations sur les contrats SLA pour les machines virtuelles, les groupes à haute disponibilité et les zones de disponibilité, consultez SLA pour les services en ligne.
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 par l'intermédiaire de zones de disponibilité et que vous utilisez différentes zones, vous créez les machines virtuelles sur différents emplacements physiques. Cette configuration offre une protection supplémentaire contre les problèmes d’alimentation, de refroidissement ou de réseau qui affectent les centres de données de la zone dans son ensemble. Vous ne pouvez toutefois 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é. Cependant, chaque zone de disponibilité dispose très probablement de plusieurs serveurs d’application. 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 utiliser des groupes à haute disponibilité pour bénéficier de ces avantages. Pour plus d’informations, consultez Groupes de placements 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 seul groupe à haute disponibilité, utilisez le nombre maximal de domaines d’erreur (trois). En outre, utilisez suffisamment de domaines de mise à jour pour limiter l’effet des éventuelles défaillances du matériel physique, des pannes réseau ou des coupures de courant, 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é.
Lorsque vous utilisez des groupes de placement de proximité Azure dans un déploiement de groupe à haute disponibilité, assurez-vous que les trois composants SAP (services centraux, serveur d’application et base de données) se trouvent dans le même groupe de placement de proximité.
Si vous utilisez des groupes de placement de proximité, utilisez-en un pour chaque SID (identification de système SAP). Les groupes ne s’étendent pas au-delà des zones de disponibilité ni des régions Azure.
Lorsque vous utilisez des groupes de placement de proximité Azure dans un déploiement de zones de disponibilité, assurez-vous que les deux composants SAP (services centraux et serveur d’application) se trouvent 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é pour chaque zone sont étendus avec le déploiement de la machine virtuelle qui exécute les instances SAP ASCS et SCS. L’avantage de cette configuration est que vous disposez d’une plus grande flexibilité pour redimensionner les machines virtuelles. Vous pouvez également basculer facilement à de nouveaux types de machines virtuelles dans la couche SGBD ou la couche d'application du système SAP.
Azure ne prend pas en charge la combinaison de haute disponibilité ASCS et DB dans le même cluster Linux Pacemaker. Séparez-les en clusters individuels. Vous pouvez combiner jusqu’à cinq clusters de services centraux multiples dans une paire de machines virtuelles.
Utilisez Standard Load Balancer avec des clusters ASCS et des clusters de base de données.
Exécutez tous les systèmes de production sur des disques SSD Azure Premium et utiliser Azure NetApp Files ou des disques de stockage Ultra Azure. Au minimum, assurez-vous que le disque du système d’exploitation se trouve sur le niveau Premium afin que vous puissiez améliorer les performances et obtenir le meilleur contrat SLA.
Déployez les deux machines virtuelles de la paire de haute disponibilité dans un groupe à haute disponibilité ou dans des zones de disponibilité. Assurez-vous que ces machines virtuelles ont 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 l’un des services suivants pour exécuter des clusters de services centraux SAP, en fonction du système d’exploitation :
- Un cluster Pacemaker SUSE Linux Enterprise Server prend en charge un agent de clôture Azure et trois appareils d’isolation de nœud.
- Un cluster Pacemaker Red Hat Enterprise Linux prend en charge un agent de clôture Azure mais ne prend pas en charge les appareils d’isolation de nœud.
- Un cluster Windows.
- Un logiciel de cluster non Microsoft certifié SAP.
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

Choisissez les options de stockage appropriées lorsque vous concevez la résilience de votre charge de travail SAP. Une conception appropriée du stockage Azure pour les charges de travail SAP permet de réduire la latence et d’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, consultez Types de stockage Azure pour les charges de travail SAP.
Vous devez exécuter SAP HANA sur Azure uniquement sur des types de stockage certifiés SAP. Vous devez exécuter certains volumes sur certaines configurations de disque. Par exemple, certaines configurations peuvent activer l’accélérateur d’écriture ou utiliser le stockage SSD 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.

Outre les disques de données managés Azure attachés aux machines virtuelles, diverses solutions de stockage partagé natives Azure permettent d'exécuter des applications SAP sur Azure. Votre configuration de haute disponibilité peut différer, car Azure Site Recovery ne prend pas en charge certains services de stockage disponibles sur Azure. Utilisez les types de stockage suivants pour les charges de travail SAP.

Type de stockage	Prise en charge de la configuration de haute disponibilité
Disques partagés Azure (stockage localement redondant (LRS) ou stockage redondant interzone (ZRS))	Cluster de basculement Windows Server 2022. Pour plus d’informations sur la configuration, consultez Concevoir une haute disponibilité SAP avec le cluster de basculement Windows Server 2022.
NFS sur Azure Files (LRS ou ZRS)	Cluster basé sur Pacemaker dans les environnements Linux. Assurez-vous de 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 2022. Pour plus d’informations sur la configuration, consultez Installer SAP NetWeaver à haute disponibilité avec Azure Files SMB.
SMB sur Azure NetApp Files	Cluster de basculement Windows Server 2022. Pour plus d’informations sur la configuration, consultez Haute disponibilité pour SAP NetWeaver avec Azure NetApp Files (SMB) pour les applications SAP.

Au lieu des services de stockage partagé natifs Azure, vous pouvez utiliser des clusters NFS traditionnels (basés sur la réplication Distributed Replicated Block Device), GlusterFS ou un volume partagé de cluster avec des espaces de stockage direct en tant que solution alternative de stockage partagé pour 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 plus d’informations sur les options de stockage disponibles pour les charges de travail SAP sur Azure, consultez Recommandations et instructions de stockage pour configurer la reprise d’activité après sinistre.

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 à long terme des sauvegardes. Dans d’autres scénarios, vous devez également disposer d’une sauvegarde à partir de laquelle vous pouvez effectuer une restauration. Ce guide part du principe que vous avez déjà établi une sauvegarde et une restauration et que vous suivez les bonnes pratiques pour les applications SAP, ce qui signifie que vous pouvez :

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.
Sauvegarder un système SAP HANA avec la réplication activée.
Sauvegarder des instantanés d’instance de base de données SAP HANA.

Lorsque vous effectuez une sauvegarde et une restauration en local, 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 dispose d'une solution SaaS dans Azure.

Azure fournit un service SaaS de sauvegarde, appelé Azure Backup, 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.

Vous pouvez également utiliser Azure Backup pour sauvegarder des bases de données sur lesquelles la réplication de système SAP HANA (HSR) est activée. Azure Backup gère automatiquement les sauvegardes lorsqu’un basculement se produit, remplaçant ainsi les interventions manuelles. Azure Backup fournit également :

Une protection immédiate sans sauvegarde complète corrective, ce qui vous permet de protéger les instances HANA ou les nœuds des configurations HSR comme un conteneur HSR unique.
Une sauvegarde instantanée et une restauration instantanée.
Une approche basée sur des captures instantanées cohérente avec HANA qui s’intègre à Backint pour SAP HANA. Vous pouvez utiliser la sauvegarde en tant que produit unique pour l’ensemble de votre paysage HANA et pour n’importe quelle taille de base de données.

Pour plus d’informations, consultez Système de base de données SAP HANA avec la réplication activée et Sauvegarde d’instantanés d’instance SAP HANA.

Recommandations de conception pour la sauvegarde et la restauration

Vous pouvez utiliser Azure Backup pour sauvegarder les machines virtuelles de serveurs d’application SAP et de services centraux.
Vous pouvez utiliser une sauvegarde SAP HANA pour les déploiements HANA d’une capacité maximale de 8 To. Pour plus d’informations, consultez Matrice 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 Infrastructure as a Service, dimensionnez l’infrastructure de sauvegarde de manière à ce qu'elle puisse sauvegarder tous les systèmes de production simultanément ou, comme dans un scénario réel, dans les délais prévus. Utilisez une configuration de production ou une configuration similaire pour des domaines tels que la mise en réseau et la sécurité.
Testez les temps de sauvegarde et de récupération pour vérifier qu’ils répondent à vos exigences RTO, c'est-à-dire qu'ils doivent pouvoir restaurer tous les systèmes simultanément 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. Cette approche peut affecter 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 comprend plus de 65 régions Azure qui n’exécutent pas toutes les mêmes services. Pour des 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 les autres données, exécutez votre réplication à l’aide de fonctionnalités SGBD natives telles que SQL Server Always On ou la réplication de système SAP HANA. Utilisez une combinaison constituée de Site Recovery, d'outils tels que rsync ou robocopy et d’autres logiciels non Microsoft pour la couche d’application SAP.
En cas de sinistre, les clients affectés dans une région Azure basculent vers la région de reprise d’activité couplée correspondante. Cette situation entraîne une concurrence entre les ressources pour réactiver les machines virtuelles dormantes dans la région de reprise d’activité après sinistre. La solution de contournement consiste à exécuter des systèmes de non-production dans la région de reprise d'activité et à utiliser les mêmes ressources pour héberger les réplicas de récupération d’urgence des systèmes de production. Cette double utilisation des infrastructures Azure dans la région de reprise d'activité après sinistre vous permet d’éviter les contraintes de capacité des 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. Cette stratégie nécessite que vous disposiez d’une infrastructure informatique minimale dans la région de reprise d'activité après sinistre.

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 d'une zone géographique ou géopolitique différente et permet de protéger votre connexion si une catastrophe affecte l’une des régions 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. 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. Par conséquent, 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. Selon la note SAP 1100926, un temps d’aller-retour inférieur ou égal à 0,3 ms est considéré comme idéal, tandis qu'un temps inférieur ou égal à 0,7 ms est considéré comme acceptable. Par conséquent, pour les zones à latences élevées, vous devez disposer de procédures opérationnelles pour vous assurer que les serveurs d’application SAP et les serveurs de bases de données s’exécutent toujours 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 et qui est parfois associée à un transfert de sauvegarde vers la région secondaire, en cas de catastrophes naturelles affectant une large zone.

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 la région de production et les régions de reprise d’activité après sinistre est grande, plus la latence du réseau est élevée. Vous effectuez une réplication de manière asynchrone entre les régions Azure, mais la latence du réseau peut affecter le débit que vous pouvez répliquer et l'objectif de RPO. Pour réduire votre RPO, vous pouvez utiliser une architecture combinant la haute disponibilité et la reprise d'activité après sinistre. 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.
Envisagez de configurer des connexions VPN à partir d’un site local vers les régions de reprise d'activité Azure principales et secondaires. Cette méthode est une alternative à l'utilisation d'ExpressRoute.
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 devrez peut-être remplacer l’adresse IP virtuelle ou le SBD, ou bien exécuter corosync.conf.
Répliquez dans plusieurs régions le contenu du coffre de clés, comme les certificats, les secrets ou les clés, afin de pouvoir déchiffrer les données dans la région de reprise d'activité.
Utilisez la réplication entre régions dans Azure NetApp Files pour synchroniser les volumes de fichiers entre la région primaire et la région de récupération d'urgence.
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, vous devez appairer les besoins d’un réseau virtuel SAP HANA DB avec le réseau virtuel SAP HANA DB du site de récupération d’urgence.
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. Pour réduire l’impact commercial d’une panne régionale, déployez chaque groupe dans une région distincte au sein d'une construction de régions appariées. Par exemple, pour réduire l’effet d’une panne régionale, vous pouvez déployer deux systèmes ERP Central Component critiques qui desservent deux unités commerciales différentes, dans le sud et l’ouest du Royaume-Uni.

Étape suivante

Options de déploiement pour SAP dans Azure

Partager via