Instructions de récupération d’urgence pour une application SAP
Pour configurer la récupération d’urgence pour une charge de travail SAP sur Azure, vous devez tester, affiner et mettre à jour le processus régulièrement. En testant la reprise d’activité après sinistre, vous pouvez mieux identifier la séquence des services dépendants nécessaires avant de déclencher le basculement de reprise d’activité de la charge de travail SAP ou de démarrer le système sur le site secondaire. Les organisations ont généralement leurs systèmes SAP connectés aux services Active Directory (AD) et DNS (Domain Name System) pour fonctionner correctement. Quand vous configurez la reprise d’activité pour votre charge de travail SAP, vérifiez que les services AD et DNS fonctionnent avant de récupérer SAP. Vous pourrez ainsi vous assurer que l’application fonctionne correctement. Pour obtenir des conseils sur la protection d’Active Directory et de DNS, découvrez comment protéger Active Directory et DNS. La recommandation de reprise d’activité pour l’application SAP décrite dans ce document est à un niveau abstrait. Vous devez concevoir votre stratégie de reprise d’activité en fonction de votre configuration spécifique et documenter le scénario de bout en bout.
Recommandation de récupération d’urgence pour les charges de travail SAP
Généralement, dans les systèmes SAP NetWeaver distribués ; les services centraux, la base de données et le stockage partagé (NFS/SMB) sont des points de défaillance uniques (SPOF). Pour atténuer l’effet de différents points de défaillance uniques, il est nécessaire de configurer la redondance de ces composants. La redondance de ces points de défaillance uniques dans la région primaire est obtenue en configurant la haute disponibilité. La configuration de haute disponibilité du composant protège le système SAP contre les défaillances locales ou les catastrophes. Toutefois, pour protéger les applications SAP contre les sinistres géographiquement dispersés, la stratégie de récupération d’urgence doit être implémentée pour tous les composants SAP.
Pour les systèmes SAP s’exécutant sur des machines virtuelles, vous pouvez utiliser Azure Site Recovery pour créer un plan de récupération d’urgence. Voici l’approche de récupération d’urgence recommandée pour chaque composant d’un système SAP. Les moteurs SAP non NetWeaver autonomes, comme les applications TREX et non SAP, ne sont pas couverts dans ce document.
| Composants | Recommandation |
|---|---|
| SAP Web Dispatcher | Répliquer une machine virtuelle à l’aide d’Azure Site Recovery |
| Services centraux SAP | Répliquer une machine virtuelle à l’aide d’Azure Site Recovery |
| Serveur d’applications SAP | Répliquer une machine virtuelle à l’aide d’Azure Site Recovery |
| Base de données SAP | Utiliser la méthode de réplication proposée par la base de données |
| Stockage partagé | Répliquer du contenu à l’aide de la méthode appropriée par type de stockage |
SAP Web Dispatcher
Le composant SAP Web Dispatcher fonctionne comme un équilibreur de charge pour le trafic SAP entre les serveurs d’applications SAP. Vous disposez de différentes options pour obtenir une haute disponibilité du composant SAP Web Dispatcher dans la région primaire. Pour plus d’informations sur cette option, consultez Haute disponibilité de SAP Web Dispatcher et Configuration haute disponibilité de SAP Web Dispatcher sur Azure.
- Option 1 : Haute disponibilité en utilisant une solution de cluster.
- Option 2 : Haute disponibilité avec des dispatchers web SAP parallèles.
Pour obtenir une récupération d’urgence pour la configuration de SAP Web Dispatcher hautement disponible dans la région primaire, vous pouvez utiliser Azure Site Recovery. Pour les dispatchers web parallèles (option 2) s’exécutant dans la région primaire, vous pouvez configurer Azure Site Recovery de façon à assurer la reprise d’activité. Mais si vous avez configuré le dispatcher web SAP en utilisant l’option 1 dans la région primaire, vous devez apporter des modifications supplémentaires après le basculement pour avoir une configuration de haute disponibilité similaire dans la région de reprise d’activité. La configuration de haute disponibilité de SAP Web Dispatcher avec la solution de cluster est configurée de la même manière que les services centraux SAP. Suivez les mêmes instructions que celles mentionnées pour les services centraux SAP.
Services centraux SAP
Les services centraux SAP contiennent le serveur de mise en file d’attente et de messages, qui est l’un des points de défaillance unique de votre application SAP. Dans un système SAP, il ne peut y avoir qu’une seule instance de ce type et elle peut être configurée pour la haute disponibilité. Consultez Haute disponibilité pour services centraux SAP pour comprendre les différentes solutions de haute disponibilité pour la charge de travail SAP sur Azure.
La configuration de la haute disponibilité pour les services centraux SAP protège les ressources et les processus contre les incidents locaux. Pour obtenir la récupération d’urgence pour les services centraux SAP, vous pouvez utiliser Azure Site Recovery. Azure Site Recovery réplique les machines virtuelles et les disques managés attachés, mais il existe d’autres considérations pour la stratégie de reprise d’activité. Consultez la section ci-dessous pour plus d’informations, en fonction du système d’exploitation utilisé pour les services centraux SAP.
Pour le système SAP, la redondance des points de défaillance uniques dans la région primaire est obtenue en configurant la haute disponibilité. Pour bénéficier d’une configuration de haute disponibilité similaire dans la région de reprise d’activité après le basculement, vous devez prendre en compte des points supplémentaires comme la reconfiguration du cluster, la disponibilité des répertoires partagés SAP ainsi que la réplication des machines virtuelles et du disque managé attaché sur le site de reprise d’activité à l’aide d’Azure Site Recovery. Sur Linux, la haute disponibilité de l’application SAP peut être obtenue à l’aide de la solution de cluster Pacemaker. Le diagramme ci-dessous montre les différents composants impliqués dans la configuration de la haute disponibilité pour les services centraux SAP avec Pacemaker. Chaque composant doit être pris en compte pour disposer d’une configuration de haute disponibilité similaire sur le site de reprise d’activité. Si vous avez configuré SAP Web Dispatcher à l’aide d’une solution de cluster Pacemaker, une considération similaire s’applique également.
Équilibreur de charge interne
Azure Site Recovery réplique les machines virtuelles sur le site de récupération d’urgence, mais il ne réplique pas l’équilibreur de charge Azure. Vous devez créer un équilibreur de charge interne distinct sur le site de récupération d’urgence au préalable ou après le basculement. Si vous créez un équilibreur de charge interne au préalable, créez un pool principal vide et ajoutez des machines virtuelles après l’événement de basculement.
Solution de cluster Pacemaker
Les configurations d’un cluster Pacemaker résident dans des fichiers locaux sur les machines virtuelles, et sont répliqués sur le site de récupération d’urgence avec Azure Site Recovery. La configuration du cluster Pacemaker en l’état ne fonctionnera telle quelle sur les machines virtuelles après le basculement. Une reconfiguration de cluster supplémentaire est nécessaire pour que la solution fonctionne.
Lisez ces billets de blog pour en savoir plus sur la reconfiguration du cluster Pacemaker dans la région de récupération d’urgence, en fonction du type de votre mécanisme de stockage et d’isolation.
- Cluster SAP ASCS/ERS haute disponibilité avec basculement d’appareil SBD (en utilisant un serveur cible iSCSI) vers la région de récupération d’urgence à l’aide d’Azure Site Recovery.
- Basculement de cluster SAP ASCS haute disponibilité (sur système d’exploitation Linux) vers la région de récupération d’urgence à l’aide d’Azure Site Recovery.
Répertoires partagés SAP pour Linux
La configuration de la haute disponibilité de la plateforme SAP NetWeaver ou ABAP utilise le serveur de réplication en file d’attente pour obtenir la redondance au niveau de l’application pour le service de mise en file d’attente du système SAP avec la configuration du cluster Pacemaker. La configuration de la haute disponibilité des services centraux SAP (ASCS et ERS) utilise des montages NFS. Vous devez donc vous assurer que les binaires et les données SAP dans ces montages NFS sont répliqués sur le site de récupération d’urgence. Azure Site Recovery réplique les machines virtuelles et le disque managé local attachés, mais pas les montages NFS. En fonction du type de stockage NFS que vous avez configuré pour l’installation, vous devez vous assurer que les données sont répliquées et disponibles dans le site de récupération d’urgence. La méthodologie de réplication inter-région pour chaque stockage est présentée à un niveau abstrait. Vous devez confirmer les étapes exactes pour répliquer le stockage et effectuer des tests.
| Répertoires partagés SAP | Réplication inter-région |
|---|---|
| NFS sur Azure Files | Personnalisé (comme rsync) |
| NFS sur ANF | Oui (réplication inter-région) |
| Cluster NFS | Custom |
Conseil
Nous vous recommandons de déployer l’un des services NFS tiers Azure : NFS sur Azure Files ou des volumes ANF NFS pour stocker des données partagées dans un système SAP hautement disponible. Sachez que nous mettons l’accent sur les architectures de référence SAP, en utilisant des clusters NFS.
Mécanisme d’isolation
Quel que soit le système d’exploitation (SLES ou RHEL) et sa version, Pacemaker nécessite un mécanisme d’isolation valide pour que l’ensemble de la solution fonctionne correctement. En fonction du type de mécanisme d’isolation que vous avez configuré dans votre région principale, vous devez vous assurer que le même mécanisme est configuré sur le site de récupération d’urgence après le basculement.
| Mécanisme d’isolation | Recommandations de récupération d’urgence inter-région |
|---|---|
| SBD utilisant un serveur cible iSCSI | Répliquez le serveur cible iSCSI à l’aide d’Azure Site Recovery. Sur les machines virtuelles de récupération d’urgence, découvrez à nouveau le disque iSCSI. |
| Agent de clôture Azure | Activez les identités système managées (MSI) sur les machines virtuelles de récupération d’urgence. Attribuez des rôles personnalisés. Mettez à jour la ressource de l’agent d’isolation dans le cluster. |
| SBD utilisant un disque partagé Azure* | Configurez un nouveau disque partagé Azure sur la région de récupération d’urgence. Attachez un disque partagé Azure à des machines virtuelles de récupération d’urgence après le basculement. Configurez un appareil SBD à disque partagé Azure. |
*Le stockage redondant interzone pour disque partagé Azure est disponible dans des régions limitées.
Notes
Nous vous recommandons d’avoir le même mécanisme d’isolation pour la région principale et la région de récupération d’urgence pour faciliter l’utilisation et le basculement. Il n’est pas recommandé d’avoir un mécanisme d’isolation différent après le basculement vers le site de récupération d’urgence.
Serveurs d’application SAP
Dans la région primaire, la redondance des serveurs d’applications SAP est obtenue en installant des instances dans plusieurs machines virtuelles. Pour avoir une récupération d’urgence pour les serveurs d’applications SAP, Azure Site Recovery peut être configuré pour chaque machine virtuelle du serveur d’applications. Pour les stockages partagés (système de fichiers de transport, système de fichiers de données d’interface) qui sont attachés aux serveurs d’applications, suivez la pratique de reprise d’activité appropriée en fonction du type de stockage partagé.
Serveurs de base de données SAP
Pour les bases de données exécutant une charge de travail SAP, utilisez la technologie de réplication de SGBD native pour configurer la récupération d’urgence. L’utilisation d’Azure Site Recovery pour les bases de données n’est pas recommandée, car elle ne garantit pas la cohérence de la base de données et présente des limitation d’attrition de données. La technologie de réplication de chaque base de données étant différente, suivez les instructions de la base de données respective. Le tableau ci-dessous présente la liste des bases de données utilisées pour les charges de travail SAP et la recommandation de récupération d’urgence correspondante.
| Base de données | Recommandation de récupération d’urgence |
|---|---|
| SAP HANA | Réplication du système HANA (HSR) |
| Oracle | Oracle Data Guard (FarSync) |
| IBM DB2 | Haute disponibilité et reprise d’activité après sinistre (HADR) |
| Microsoft SQL | Microsoft SQL Always On |
| SAP ASE | ASE HADR Always On |
| SAP MaxDB | Base de données de secours |
Pour une solution à coût optimisé, vous pouvez même utiliser l’option de sauvegarde et de restauration pour la stratégie de récupération d’urgence de base de données.
Sauvegarde et restauration
La sauvegarde et la restauration sont une autre solution que vous pouvez utiliser pour effectuer la récupération d’urgence de vos charges de travail SAP si le RTO et le RPO métier ne sont pas critiques. Vous pouvez utiliser la Sauvegarde Azure, un service de sauvegarde basé sur le cloud pour effectuer des copies de différents composants de votre charge de travail SAP, comme les machines virtuelles, les disques managés et les bases de données prises en charge. Pour en savoir plus sur les paramètres de prise en charge généraux et les limitations des scénarios et déploiements de Sauvegarde Azure, consultez Matrice de prise en charge de Sauvegarde Azure.
| Services | Composant | Support Sauvegarde Azure |
|---|---|---|
| Calcul | Machines virtuelles Azure | Prise en charge |
| Stockage | Disques managés Azure, y compris les disques partagés | Pris en charge |
| Stockage | Partage de fichiers Azure - SMB (Standard ou Premium) | Pris en charge |
| Stockage | Blobs Azure | Prise en charge |
| Stockage | Partage de fichiers Azure - NFS (Standard ou Premium) | Non pris en charge |
| Stockage | Azure NetApp Files | Non pris en charge |
| Base de données | Base de données SAP HANA dans les machines virtuelles Azure. | Pris en charge |
| Base de données | SQL Server sur des machines virtuelles Azure | Pris en charge |
| Base de données | Oracle | Pris en charge* |
| Base de données | IBM DB2, SAP ASE | Non pris en charge |
Notes
*La Sauvegarde Azure prend en charge les bases de données Oracle avec la sauvegarde de machines virtuelles Azure pour les instantanés cohérents de base de données.
La Sauvegarde Azure ne prend pas en charge tous les stockages et bases de données Azure utilisés pour la charge de travail SAP.
La Sauvegarde Azure stocke les sauvegardes dans le coffre du service de récupération, qui réplique vos données en fonction du type de réplication choisi (LRS, ZRS ou GRS). Pour le stockage géoredondant (GRS), vos données de sauvegarde sont répliquées dans une région secondaire jumelée. Avec la fonctionnalité de restauration inter-région activée, vous pouvez restaurer des données du type de gestion pris en charge sur la région secondaire.
La sauvegarde et la restauration sont une approche traditionnelle à coût optimisé, mais elles s’accompagnent d’un RTO plus élevé, car vous devez restaurer toutes les applications à partir de la sauvegarde en cas de basculement vers la région de récupération d’urgence. Vous devez donc analyser les besoins de votre entreprise et concevoir une stratégie de récupération d’urgence en conséquence.