Utiliser facilement la fonctionnalité de cluster Hana HA

Sans un traitement approfondi des questions d'infrastructure ou d'exploitation informatique, les projets Hana ont des pieds d'argile.

Les entreprises doivent veiller à ce que les applications SAP critiques, telles que S/4 ou BW/4 Hana, puissent être utilisées pratiquement à tout moment. En effet, la continuité de l'activité ne doit pas être interrompue pendant une longue période, ni même être totalement inactive.

Dans l'agenda de l'infrastructure IT/Hana, le complexe de thèmes High Availability (HA) est toujours en tête et, soit dit en passant, il est par exemple discuté d'une manière ou d'une autre pratiquement à chaque atelier Suse-SAP.

Comme dans les versions précédentes, la version 12 de Suse Linux Enterprise (SLES) for SAP Applications offre d'emblée aux clients SAP Suse la fonction High Availability Extension (HAE), y compris la fonctionnalité Disaster Recovery (DR). Utilisable aussi bien pour l'utilisation Any-DB que pour l'utilisation Hana-DB.

Important :

High Availability Extension in SLES for SAP Applications est un package complet de solutions HA open source, disponible gratuitement pour les clients SAP Suse.

Il n'est donc pas nécessaire d'engager des dépenses supplémentaires pour une solution de gestion des ressources de cluster supplémentaire lors des déploiements Hana.

Suse HAE for SAP Applications est d'ailleurs basé sur la solution open source Pacemaker.

Bien entendu, la solution Suse-HA est intégrée dans la gestion des systèmes SAP (Solution Manager), tout comme la plate-forme de système d'exploitation Suse Linux Enterprise Server for SAP Applications.

La réplication du système Hana (SR) est au cœur du concept Hana HA de SAP. Toutefois, la manipulation/utilisation se fait généralement manuellement.

L'automatisation du SR présente bien sûr des avantages, ce qui permet d'augmenter les SLA.

Une réplication de système Hana fonctionne via un Memory Preload dans un cluster (au minimum un cluster à 2 nœuds). En cas de besoin, la commutation automatique s'effectue au moyen de Suse HAE for SAP Applications.

Récupération après sinistre

Dans le cas d'un scénario de reprise après sinistre nécessaire, il est possible qu'une réplication de système Hana soit effectuée par une réplication asynchrone supplémentaire sur un autre site (par ex. un autre centre de données) afin d'obtenir ainsi une couverture DR.

Il existe en outre une approche "cost-optimized". Ici, on renonce à un Memory Preload (sur un système fonctionnant constamment en parallèle). Ici aussi, on utilise un deuxième nœud (node).

Toutefois, il fonctionne principalement comme système de test et de développement et une réplication de système Hana est exécutée ou utilisée sur le deuxième nœud uniquement en cas de HA.

Par rapport à un environnement de haute disponibilité avec Memory Preload synchrone, la disponibilité de Hana dure ici bien entendu plus longtemps.

Cette approche permet néanmoins de minimiser les coûts d'investissement et d'exploitation. Dans le cas d'un éventuel scénario DR, la réplication vers le "secondary site" se fait également de manière asynchrone.

Sur la base de Hana Resource Agents (RA) de Suse, il est possible d'administrer et de gérer des instances et des réplications de bases de données Hana.

Ces agents de ressources permettent en outre une utilisation à la fois intelligente et simplifiée des configurations de clusters. Et ce, beaucoup plus facilement que par le passé.

Conclusion

En résumé, on peut dire que depuis des années maintenant, la Suse High Availability Extension (HAE) mise à disposition avec SLES for SAP Applications constitue une solution de haute disponibilité éprouvée et de premier plan pour l'amélioration de la continuité des activités/haute disponibilité, y compris la fonctionnalité de reprise après sinistre pour les solutions SAP.

Elle a été optimisée en collaboration avec SAP pour l'utilisation de Hana grâce à des développements supplémentaires.

Elle augmente les SLA lors de l'exploitation de Hana, simplifie le traitement des configurations de clusters et peut être utilisée aussi bien pour les environnements de systèmes scale-up que scale-out. Pour l'utilisation scale-out, il existe une "disponibilité contrôlée" (cA).