Il existe deux indicateurs clés pour les 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.

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.

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.

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.

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.

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.