Tr-4891 : reprise après incident de SAP HANA avec Azure NetApp Files
Nils Bauer, NetApp Ralf Klahr, Microsoft
Des études ont montré que les temps d'indisponibilité des applications d'entreprise ont un impact négatif considérable sur le business des entreprises. En plus de l’impact financier, les temps d’arrêt peuvent également nuire à la réputation de l’entreprise, au moral du personnel et à la fidélité des clients. Il est surprenant que toutes les entreprises ne disposent pas d'une politique globale de reprise après incident.
L'exécution de SAP HANA sur Azure NetApp Files (ANF) permet aux clients d'accéder à des fonctionnalités supplémentaires qui étendent et améliorent la protection des données intégrée et les fonctionnalités de reprise après incident de SAP HANA. Cette section de présentation explique ces options afin d'aider les clients à sélectionner les options qui répondent à leurs besoins.
Pour développer une stratégie complète de reprise sur incident, les clients doivent comprendre les exigences des applications métier et les fonctionnalités techniques dont ils ont besoin pour la protection des données et la reprise sur incident. La figure suivante fournit une présentation de la protection des données.
![Erreur : image graphique manquante](saphana-dr-anf_image2.png)
Aux exigences des applications d'entreprise
Il existe deux indicateurs clés pour les applications d'entreprise :
-
L'objectif de point de récupération (RPO) ou la perte de données maximale tolérable
-
L'objectif de durée de restauration (RTO) ou l'interruption maximale tolérable des applications d'entreprise
Ces besoins sont définis par le type d'application utilisé et la nature de vos données d'entreprise. L'objectif RPO et l'objectif RTO peuvent différer si vous protégez-vous contre les défaillances dans une seule région Azure. Elles peuvent également différer si vous préparez des incidents catastrophiques, tels que la perte d'une région Azure complète. Il est important d'évaluer les exigences de l'entreprise qui définissent le RPO et RTO, car ces exigences ont un impact significatif sur les options techniques disponibles.
Haute disponibilité
L'infrastructure pour SAP HANA, telles que les machines virtuelles, le réseau et le stockage, doit disposer de composants redondants pour s'assurer qu'il n'y a pas de point de défaillance unique. MS Azure assure la redondance des différents composants de l'infrastructure.
Pour assurer une haute disponibilité côté applications et calcul, les hôtes SAP HANA en attente peuvent être configurés pour une haute disponibilité intégrée avec un système multihôte SAP HANA. En cas de panne d'un serveur ou d'un service SAP HANA, le service SAP HANA bascule vers l'hôte de secours, ce qui entraîne les interruptions des applications.
Si vous ne pouvez pas profiter de la continuité de l'activité de vos applications ou de vos serveurs, vous pouvez également utiliser la réplication du système SAP HANA comme solution haute disponibilité qui permet un basculement dans des délais très courts. Les clients SAP utilisent la réplication système HANA pour traiter la haute disponibilité en cas de défaillance non planifiée et réduire au maximum les interruptions pour les opérations planifiées, telles que les mises à niveau logicielles HANA.
Corruption logique
Une corruption logique peut être provoquée par des erreurs logicielles, des erreurs humaines ou du sabotage. Malheureusement, la corruption logique ne peut souvent pas être abordée avec les solutions standard de haute disponibilité et de reprise après incident. Par conséquent, selon la couche, l'application, le système de fichiers ou le stockage où la corruption logique s'est produite, les exigences RTO et RPO ne peuvent parfois pas être satisfaites.
Le pire cas étant la corruption logique d'une application SAP. Les applications SAP fonctionnent souvent dans un environnement dans lequel les différentes applications communiquent entre elles et échangent des données. Par conséquent, la restauration et la récupération d'un système SAP dans lequel une corruption logique s'est produite n'est pas l'approche recommandée. La restauration du système à un point dans le temps avant l'altération entraîne une perte de données. L'objectif de point de récupération dépasse ainsi zéro. Par ailleurs, le paysage SAP ne serait plus synchronisé et devrait nécessiter un post-traitement supplémentaire.
Au lieu de restaurer le système SAP, la meilleure approche consiste à essayer de corriger l'erreur logique dans le système, en analysant le problème dans un système de réparation distinct. L'analyse de la cause première nécessite la participation du processus métier et du propriétaire des applications. Dans ce cas, vous créez un système de réparation (clone du système de production) basé sur les données stockées avant l'altération logique. Dans le système de réparation, les données requises peuvent être exportées et importées dans le système de production. Avec cette approche, le système productif n'a pas besoin d'être arrêté et, dans le meilleur des cas, aucune donnée ou seulement une petite fraction des données n'est perdue.
|
Les étapes requises pour configurer un système de réparation sont identiques à celles d'un scénario de test de reprise après incident décrit dans ce document. La solution de reprise sur incident décrite peut donc facilement être étendue pour gérer la corruption logique. |
Sauvegardes
Des sauvegardes sont créées pour permettre la restauration et la restauration à partir de différents jeux de données ponctuelles. Ces sauvegardes sont généralement conservées pendant quelques jours à quelques semaines.
Selon le type de corruption, il est possible d'effectuer des restaurations et des restaurations avec ou sans perte de données. Si le RPO doit être nul, même en cas de perte du stockage primaire et de sauvegarde, la sauvegarde doit être combinée avec la réplication synchrone des données.
Le RTO pour la restauration et la récupération est défini par le temps de restauration requis, le temps de restauration (démarrage de base de données inclus) et le chargement des données dans la mémoire. Pour les bases de données volumineuses et les approches de sauvegarde classiques, l'RTO peut facilement prendre plusieurs heures, ce qui n'est pas acceptable. Pour atteindre de très faibles valeurs RTO, une sauvegarde doit être combinée à une solution de secours, qui comprend le préchargement des données dans la mémoire.
En revanche, une solution de sauvegarde doit traiter la corruption logique, car les solutions de réplication des données ne peuvent pas couvrir tous les types de corruption logique.
La réplication des données synchrone ou asynchrone
L'objectif RPO détermine principalement la méthode de réplication des données que vous devez utiliser. Si le RPO doit être nul, même en cas de perte du stockage principal et de sauvegarde, les données doivent être répliquées de manière synchrone. Cependant, la réplication synchrone est limitée de manière technique, comme la distance entre deux régions Azure. Dans la plupart des cas, la réplication synchrone n'est pas adaptée aux distances supérieures à 100 km en raison de la latence. Il ne s'agit donc pas d'une option de réplication des données entre les régions Azure.
Si un RPO plus important est acceptable, la réplication asynchrone peut être utilisée sur de grandes distances. L'objectif RPO dans ce cas est défini par la fréquence de réplication.
Réplication du système HANA avec ou sans préchargement des données
La durée de démarrage d'une base de données SAP HANA est bien plus longue que celle des bases de données classiques, car une quantité importante de données doit être chargée dans la mémoire avant que la base de données puisse fournir les performances attendues. Par conséquent, une partie importante du RTO est le temps nécessaire au démarrage de la base de données. Avec une réplication basée sur le stockage et la réplication système HANA sans précharger les données, la base de données SAP HANA doit être démarrée en cas de basculement vers le site de reprise d'activité.
La réplication du système SAP HANA offre un mode de fonctionnement dans lequel les données sont préchargées et mises à jour en continu sur l'hôte secondaire. Ce mode assure des valeurs RTO très faibles, mais il requiert également un serveur dédié qui n'est utilisé que pour recevoir les données de réplication du système source.