SAP HANA prend en charge les solutions de tolérance aux catastrophes sur la base de la réplication à l'aide du sous-système d'E/S du disque dur. La solution de tolérance aux catastrophes est basée sur les mécanismes de réplication du sous-système E/S du disque dur. Toutes les données écrites dans la persistance (volume de données et volume de journal) par le système SAP HANA primaire sont répliquées dans un deuxième emplacement (secondaire). L'instance SAP HANA du deuxième emplacement n'est pas active (veille à froid).
La mise en miroir est proposée au niveau du système de stockage. Il est proposé avec l'appareil en tant qu'offre spéciale par nos partenaires. Le partenaire matériel définit comment ce concept est finalement réalisé avec ses possibilités d'exploitation.
En règle générale, les demandes d'écriture sont répliquées dans le sous-système E/S du disque dur de manière synchrone. Lorsqu'il y a de longues distances entre les sites, les temps de latence pour l'écriture du journal de restauration peuvent augmenter. Cela signifie que la réplication synchrone ne peut être utilisée que jusqu'à certaines distances. La distance maximale dépend des exigences de performance du système SAP HANA, de la solution respective du partenaire matériel et de la configuration réseau dans l'environnement client.
Certains partenaires matériels prennent en charge un transfert asynchrone des demandes d'écriture, tandis que la cohérence des données et des transactions au sein de la base de données SAP HANA est garantie. Lors d'une reprise dans ce cas, les dernières modifications apportées peuvent être perdues. Dans certains scénarios d'application, cette perte peut être acceptée, mais dans d'autres, elle ne le peut pas.
Par exemple, dans une solution Data Mart SAP HANA, les données sont répliquées depuis un système source vers la base de données SAP HANA à l'aide de SAP Landscape Transformation (SLT). Si la base de données SAP HANA perd les données insérées en dernier en raison d'un basculement, SLT ne transfère pas à nouveau les données manquantes. Par conséquent, les données doivent être rechargées dans les tables de la base de données SAP HANA. Dans cet environnement, seule une réplication synchrone entre le système SAP HANA primaire et le système SAP HANA secondaire est utile.
Les solutions avec réplication asynchrone peuvent être utilisées pour des distances plus longues entre les sites car les temps de latence ne sont pas significativement affectés lors de l'écriture du journal de rétablissement.
Vous pouvez vous attendre à un impact sur les performances pour les opérations de modification des données dès que la mise en miroir synchrone est activée. L'impact dépend fortement de divers facteurs externes tels que la distance, la connexion entre les centres de données, etc. L'écriture synchrone du journal avec les COMMIT finaux est cruciale.
En cas d'urgence, le centre de données principal n'est plus disponible et vous devez lancer un processus pour la reprise. Jusqu'à présent, de nombreux clients ont demandé un processus manuel, mais un processus automatisé peut également être implémenté. Ce processus de reprise met officiellement fin à la mise en miroir, monte les disques sur le logiciel et les instances SAP HANA déjà installés et lance la base de données secondaire du cluster. Si les noms d'hôte et d'instance des deux côtés du cluster sont identiques, aucune autre étape avec HDBRENAME n'est nécessaire.
Solutions de stockage prises en charge
Les fournisseurs de matériel et de solutions de stockage prennent en charge la réplication de stockage SAP HANA. Par conséquent, aucune autre certification de ces solutions de réplication de stockage de SAP n'est requise pour une utilisation avec SAP HANA.
Toutes les certifications existantes de la solution de réplication de stockage pour les appliance SAP HANA poursuivent leur validité. Ces solutions sont mentionnées dans la note SAP 1755396 - Solutions de tolérance aux sinistres validées pour SAP HANA avec réplication de disque.
Toutes les nouvelles solutions sont prises en charge directement par les fournisseurs de matériel ou les partenaires de stockage correspondants.
Utilisation de serveurs secondaires pour les systèmes non productifs
Avec la réplication du stockage SAP HANA, vous pouvez utiliser les serveurs du système secondaire pour les systèmes SAP HANA non productifs.
Selon la solution matérielle, vous pouvez utiliser les serveurs du système secondaire pour d'autres systèmes SAP HANA (tels que les systèmes de test) jusqu'à la reprise. Lors d'une reprise, les autres systèmes en cours d'exécution sont désactivés, la réplication entre les sites est interrompue, les points de montage du site répliqué sont mis à disposition pour les serveurs secondaires et le système SAP HANA est lancé. Lors de l'utilisation de serveurs du système secondaire pour d'autres systèmes SAP HANA, ceux-ci n'utilisent pas le système de stockage sur disque dur qui contient la réplication du système principal.
Vous pouvez exécuter une instance de développement ou d'assurance qualité de l'installation à trois niveaux sur ce matériel de cluster secondaire, simplement pour l'utiliser jusqu'à ce que la reprise soit exécutée. La reprise arrête alors ces instances de développement ou d'assurance qualité et monte les disques de production sur les hôtes. Il nécessite un ensemble supplémentaire de disques pour le développement et l'instance d'assurance qualité.
Il en va de même pour les solutions de mise en miroir asynchrone pour les centres de données distants (> 100 km). Certains partenaires matériels ont des concepts disponibles pour proposer cette réplication de stockage asynchrone. Pour plus d'informations, voir la note SAP 1755396.
