Description des fonctionnalités de haute disponibilité de SAP HANA

La plate-forme de base de données SAP HANA est conçue pour la haute disponibilité et la tolérance aux sinistres. SAP HANA prend en charge un large éventail de scénarios de restauration, des erreurs logicielles simples ou des pannes matérielles aux catastrophes qui sortent un site entier.

La disponibilité est généralement indiquée en pourcentage du temps de fonctionnement opérationnel d'un système, mesuré au cours d'une année. Par exemple, si un système est conçu pour être disponible 99,99 % du temps (parfois appelé « quatre neuf »), son temps d'arrêt par an doit être inférieur à 0,01 %, soit 52 minutes et 56 secondes.

Cela signifie moins d'une heure de temps d'arrêt par an. Il peut s'agir d'un objectif très difficile. Pour atteindre ces objectifs ambitieux, la haute disponibilité et la tolérance aux catastrophes devraient faire partie intégrante de la conception architecturale, c'est-à-dire mise en œuvre sur toutes les couches de l'infrastructure.

Le temps d'arrêt est la conséquence de pannes, qui peuvent être des temps d'arrêt planifiés (par exemple, pour les montées de version du système ou les remplacements de matériel) ou causés par des temps d'arrêt non planifiés (par exemple, pour des pannes logicielles ou matérielles). Les temps d'arrêt non planifiés peuvent être déclenchés par une panne d'équipement, des défaillances de logiciel ou de réseau, ou une catastrophe majeure telle qu'un incendie, un tremblement de terre, une perte de puissance régionale ou un accident de construction pouvant mettre hors service l'ensemble du centre de données.

La haute disponibilité est un ensemble de techniques, de pratiques d'ingénierie et de principes de conception pour la continuité des activités. Pour ce faire, il suffit d'éliminer les points de défaillance uniques (tolérance aux pannes) et d'offrir la possibilité de reprendre rapidement les opérations après une panne du système avec une perte d'activité minimale (résilience des pannes).

La récupération des pannes est le processus de récupération et de reprise des opérations normales après une panne due à une panne.

La restauration après sinistre est le processus de récupération des opérations après une panne due à une panne prolongée du centre de données ou du site. La préparation aux catastrophes peut nécessiter une sauvegarde des données sur de plus longues distances et peut donc être plus complexe et coûteuse.

Les clients utilisent généralement deux mesures clés pour spécifier les paramètres de récupération d'un système suite à une panne, l'Objectif de point de récupération (RPO) et l'Objectif de temps de récupération (RTO). L'Objectif de point de récupération et l'Objectif de temps de récupération d'un système sont illustrés dans la figure, Objectif de point de récupération et Objectif de temps de récupération.

• L'Objectif de point de récupération est la durée maximale autorisée pendant laquelle les données opérationnelles peuvent être perdues sans pouvoir être récupérées. Il s'agit du temps écoulé entre la dernière sauvegarde (données ou journal) et le crash. Presque tous les clients tentent d'atteindre un Objectif de point de récupération de 0, car la perte de données commerciales est inacceptable.

• L'OTR est la durée maximale autorisée pour la restauration du système, afin que les opérations normales puissent reprendre. De nombreuses entreprises visent un objectif de temps de récupération proche de zéro, car pendant la période d'Objectif de temps de récupération, les activités normales sont interrompues. L'interruption de l'activité entraîne une perte de chiffre d'affaires, qui doit être évitée autant que possible.

La clé pour atteindre la tolérance aux pannes est d'éliminer les points de défaillance uniques en introduisant la redondance. Les fournisseurs de matériel SAP HANA fournissent plusieurs niveaux de redondance pour éviter les pannes dues à une panne de composant.

De manière générale, ces techniques sont transparentes pour le fonctionnement de SAP HANA. Néanmoins, ils forment une ligne de défense cruciale contre les pannes de système évitables et contribuent donc grandement à la continuité des activités.

Redondance matérielle

Les fournisseurs de matériel SAP HANA conçoivent plusieurs couches de redondance dans leurs composants matériels et sous-systèmes. Il s'agit notamment d'unités d'alimentation redondantes et échangeables à chaud (PSU), de ventilateurs, de cartes d'interface réseau et de mémoire de code de qualité professionnelle et correctrice d'erreurs.

Ces sous-systèmes sont conçus de manière à ce que les composants redondants puissent supporter le fonctionnement du système même en cas de défaillance d'autres composants.

Le système de stockage est particulièrement critique. Les systèmes de stockage d'entreprise combinent plusieurs lecteurs physiques en unités logiques, avec des techniques RAID (Redundant Array of Independent Disks) standard intégrées pour la redondance et la récupération des erreurs. Il s'agit notamment de la mise en miroir (écriture des mêmes données sur deux lecteurs différents en parallèle) et de la parité (écriture de bits supplémentaires pour permettre la détection et la correction automatique des erreurs).

Redondance réseau

Les réseaux redondants, l'équipement réseau et la connectivité réseau sont nécessaires pour éviter que des pannes de réseau n'affectent la disponibilité du système. Ceci est généralement réalisé en déployant une topologie de commutation complètement redondante, en utilisant le protocole Spanning Tree Protocol (STP) pour éviter les boucles.

Les routeurs peuvent être configurés avec le protocole HSRP (Hot Standby Router Protocol) pour le basculement automatique. Le Border Gateway Protocol (BGP) est couramment utilisé pour gérer les connexions double WAN.

Redondance des centres de données

Les centres de données qui hébergent les solutions SAP HANA sont équipés d'unités d'alimentation électrique ininterrompue (UPS) et de générateurs électriques de secours, de systèmes de refroidissement redondants et de fournisseurs multisources de connectivité réseau et d'électricité. Cela permet d'atteindre la disponibilité opérationnelle en présence de défaillances individuelles et la réduction significative de la probabilité qu'une panne ait un impact sur l'activité. Certaines entreprises exploitent des centres de données entièrement dupliqués, offrant un niveau élevé de tolérance aux catastrophes.

En tant que base de données in-memory, SAP HANA ne doit pas seulement se préoccuper de maintenir la fiabilité de ses données en cas de défaillance. Il doit également s'occuper de reprendre les opérations le plus rapidement possible avec la plupart de ses données rechargées en mémoire.

La figure « SAP HANA RPO and RTO Support » illustre les phases de la prise en charge de la haute disponibilité de SAP HANA.

Phase de préparation

Cette première phase signifie être prête pour la catastrophe. Pendant ce temps, la base de données est régulièrement sauvegardée (sauvegardes de données et de journaux). Les systèmes de secours locaux ou distants sont opérationnels et prêts à prendre le relais.

Cette phase est souvent considérée comme acquise, car tout fonctionne dans les paramètres définis. En raison de cette attitude détendue, certaines procédures de contrôle peuvent être ignorées. C'est un désastre qui attend d'arriver. Assurez-vous que des contrôles sont en place.

Détecter la phase

Avant qu'une reprise puisse être initiée, une faute doit être détectée. Cette détection de défaut peut être effectuée automatiquement ou manuellement. Dans les deux cas, il faut éviter les faux positifs, il faut donc retester un échec.

Essayez de maintenir la phase de détection aussi courte que possible pour éviter la perte de chiffre d'affaires pendant que les systèmes sont à l'arrêt.

Phase de restauration

Lorsqu'une défaillance réelle a été détectée, la reprise est déclenchée. En fonction de l'erreur, différents processus de restauration peuvent être déclenchés. Les différents processus de restauration ont des durées d'exécution de restauration différentes. La durée d'exécution dépend également fortement des ressources matérielles disponibles.

Phase de ramp-up

Dès que la récupération est terminée, le système est disponible dans un état de ramp-up. Cela est dû au fait que toutes les données ne sont pas encore chargées dans la mémoire et que des interfaces externes peuvent encore être en cours d'initialisation.

Pour optimiser cette phase, vous pouvez rechercher les données les plus nécessaires pour que ces données puissent d'abord être chargées.

Phase de défaillance

Lorsque toutes les autres phases sont terminées, la panne doit être réparée. Il peut s'agir d'une réparation matérielle ou de mises à jour logicielles. Les deux prennent du temps et peuvent nécessiter des tests supplémentaires avant d'être appliqués au système de production.

Lorsque ces réparations sont effectuées, le système peut avoir besoin de revenir au centre de données et au matériel d'origine. Cela peut être déclenché immédiatement ou lors de la prochaine période de maintenance du centre de données. Si et quand ce basculement est déclenché est à la charge du client, car cela dépend des contrats et des accords sur le niveau de service avec des fournisseurs tiers et peut entraîner des coûts supplémentaires.

Différentes valeurs RPO et RTO peuvent être associées à différents types de défauts. Les systèmes critiques pour l'activité doivent fonctionner avec un Objectif de point de récupération de zéro perte de données en cas de défaillances locales, et souvent même en cas de sinistre.

Les défis de la reprise après sinistre sont différents pour les défaillances récupérables localement par rapport aux catastrophes totales. Pour atteindre un Objectif de point de récupération nul et un Objectif de temps de récupération faible en cas de sinistre total, les données doivent être répliquées de manière synchrone sur des distances plus longues, ce qui a un impact sur les performances régulières du système et peut nécessiter des solutions de secours et de basculement plus coûteuses.

Tout cela conduit à des décisions de compromis autour des attributs de la fonctionnalité de recouvrement des pannes, du coût et de la complexité. SAP propose des options de conception complémentaires, notamment trois niveaux de support de restauration après sinistre et trois niveaux de support de restauration automatique des pannes. Celles-ci sont résumées dans la figure Fonctionnalités de restauration de SAP HANA. Des détails supplémentaires sur la restauration après sinistre et la restauration après sinistre sont fournis dans les unités suivantes de ce cours.

Les défaillances locales, telles que les pannes matérielles et logicielles, peuvent souvent être traitées dans le même centre de données et le même matériel. Les solutions possibles pour réparer l'erreur incluent le redémarrage d'un service défaillant sur le même serveur ou le passage à un nouvel hôte dans le même centre de données. Ces solutions peuvent être implémentées presque sans frais supplémentaires, car elles font souvent partie par défaut de la solution logicielle et matérielle fournie par les fournisseurs de matériel.

Redémarrage automatique du service

En cas d'échec logiciel de l'un des services SAP HANA configurés (serveur d'index, serveur de noms, etc.), le service défaillant est redémarré par la fonction de surveillance de redémarrage automatique du service SAP HANA.

Cette fonction de surveillance est fournie par le processus démon SAP HANA, qui détecte automatiquement l'échec et relance le processus de service arrêté. Au redémarrage, le service charge les données dans la mémoire et reprend sa fonction. Bien que toutes les données restent sûres, la récupération du service prend un certain temps.

Redémarrage automatique de SAP HANA

Le système de base de données SAP HANA peut être configuré en mode de redémarrage automatique. Cela peut être utile après une panne de courant. Lorsque l'alimentation est retournée et que le système d'exploitation Linux a été démarré avec succès, le système de base de données SAP HANA effectue automatiquement un démarrage et une récupération. Le système de base de données SAP HANA est à nouveau disponible pour des opérations normales dès que le démarrage et la restauration sont terminés.

Basculement automatique de l'hôte

Il s'agit d'une solution locale de récupération des erreurs qui peut être utilisée en plus de la réplication du système ou comme mesure alternative à celle-ci. Un ou plusieurs hôtes sont ajoutés à un système de base de données SAP HANA. Ces hôtes supplémentaires sont configurés pour fonctionner en mode veille.

Tant qu'elles sont en mode veille, les bases de données sur ces hôtes ne contiennent aucune donnée et n'acceptent pas les requêtes. Cela signifie que ces hôtes de secours supplémentaires ne peuvent pas être utilisés à d'autres fins, telles que les systèmes de qualité ou de test.

Les catastrophes peuvent être divisées en éléments naturels et humains. Les catastrophes naturelles sont les tremblements de terre, les volcans, les ouragans, les inondations et les incendies. Catastrophes causées par l'homme, par exemple suppression accidentelle de fichiers de données ou de données de table, erreurs d'utilisateur logiques, pannes de courant ou perte de connectivité Internet dans le centre de données principal.

Le rétablissement de ces catastrophes d'origine humaine est plus complexe et prend du temps. Le passage au centre de données secondaire encore intact est souvent la solution la plus rapide pour garantir le rétablissement de la continuité des activités le plus rapidement possible.

Sauvegardes

SAP HANA est une base de données in-memory, mais toutes les données sont également conservées sur le disque. Les données sont conservées sur le disque au moyen de points de sauvegarde réguliers. Ces points de sauvegarde sont effectués par défaut toutes les cinq minutes. Entre ces points de sauvegarde, toutes les modifications sont enregistrées dans les journaux de transaction redo.

Pour garantir la restauration de SAP HANA à partir de pannes matérielles, des sauvegardes de données et de journaux doivent être effectuées régulièrement. Ces sauvegardes de données et de journaux doivent être expédiées sur le site secondaire pour s'assurer que le système peut récupérer à partir d'un sinistre total.

Réplication du stockage

Il s'agit d'une méthode permettant de répliquer en continu toutes les données rendues persistantes et de journaliser les informations sur le site secondaire. Plusieurs partenaires matériels SAP HANA proposent une solution de réplication au niveau du stockage, qui fournit une sauvegarde des volumes ou du système de fichiers à un système de stockage distant et en réseau.

Réplication du système

Il s'agit d'une solution native de haute disponibilité SAP HANA qui fournit un système SAP HANA continuellement répliqué sur le site secondaire. Les données sont déjà chargées dans la mémoire, de sorte que les temps de reprise sont courts par rapport aux solutions de sauvegarde et de réplication de stockage.

Réplication système active/active

Il s'agit d'une deuxième solution de réplication du système SAP HANA natif qui permet de lire les données à partir du système secondaire. Dans cette configuration, le système secondaire peut être utilisé pour gérer la charge de travail de reporting sans perturber le système principal.

Réplication du système sans préchargement des données

Il s'agit d'un troisième scénario natif SAP HANA. Dans cette solution, le système secondaire ne précharge pas les données et consomme donc très peu de mémoire. Cela permet aux hôtes du système secondaire de servir à deux fins. Par exemple, pour le développement, le test unitaire ou l'assurance qualité avec stockage distinct. Avant la reprise, ces activités doivent bien entendu être désactivées. Le compromis dans ce scénario est un objectif de temps de récupération plus long en cas de basculement.