SAP sur Google Cloud : bonnes pratiques pour une haute disponibilité

Ces deux dernières années, les entreprises de tous les secteurs ont dû relever des défis imprévus pour garantir la disponibilité de leur système d’information tout en fiabilisant et sécurisant les transactions. Beaucoup ont dû faire face à des pics de charge, ou au contraire à des baisses soudaines, et elles sont nombreuses à avoir opté pour des environnements de travail hybrides. Dans un climat aussi changeant, avec des exigences et des attentes métier en constante évolution, il est important de contrôler périodiquement les objectifs de niveau de service (SLO) et les accords de niveau de service (SLA) de votre système informatique afin de vous assurer qu'ils sont toujours alignés sur les besoins de votre entreprise.

S’adapter à ce contexte incertain est particulièrement complexe pour les entreprises exécutant leurs applications SAP en interne. De fait, nombre d’elles avaient déjà du mal à gérer leurs instances SAP critiques car la maintenance peut être à la fois complexe et coûteuse.  D’autant qu’elles sont tout à fait conscientes du fait que leurs utilisateurs sont dépendants de ces systèmes et que la moindre panne ou indisponibilité peut perturber considérablement leurs activités.
Partant de ces principes, beaucoup d’entreprises considèrent que l’installation sur site - soutenue par des investissements importants en systèmes et infrastructure haute disponibilité (HA) – reste la meilleure façon de garantir la sécurité et la disponibilité de ces applications essentielles. Or, dans de nombreux cas, les services informatiques chargés d'exploiter les environnements SAP sur site doivent également gérer un nombre croissant d'autres applications critiques. Autant dire qu’ils subissent une forte pression avec l’obligation de toujours faire plus avec moins. 

Pour beaucoup d’entreprises, cette approche est devenue insoutenable. Une étude réalisée par SIOS avant la pandémie sur les tendances en matière de solutions à haute disponibilité indiquait déjà que les entreprises rencontraient des difficultés dans ce domaine pour leurs applications hébergées en interne :

• 95 % des entreprises interrogées signalaient des défaillances au minima occasionnelles sur les services HA supportant leurs applications.

• 98 % signalaient des problèmes de performance applicative réguliers ou occasionnels, et 71 % les ont signalés une fois ou plus par mois.

• Les entreprises interrogées ont passé 3 à 5 heures, en moyenne, pour identifier et résoudre la cause d’un problème.

La situation ne va pas en s’améliorant pour ces entreprises. Le paysage informatique actuel est en effet dominé par l’incertitude, l’essor de nouveaux risques et la perspective de restrictions budgétaires alors qu’il est plus que jamais essentiel de préserver la sécurité, la productivité et la disponibilité des applications SAP.

Chez Google Cloud, nous avons longuement réfléchi à la manière de résoudre les problèmes de haute disponibilité des environnements SAP. Nous sommes conscients qu'il s'agit d'une question cruciale pour nos clients et nous nous efforçons de leur fournir une solution : un environnement SAP fiable, évolutif et rentable, construit sur une plateforme cloud conçue pour offrir la haute disponibilité et des performances élevées.

Lorsque vous utilisez Google Cloud, vous bénéficiez de nombreux services conçus pour être tolérants aux pannes et hautement disponibles. Les concepts de notre solution pour SAP sont similaires, mais comprendre la différence peut vous faire gagner du temps et des efforts lors de la conception de votre architecture.

Nous considérons les composants tolérants aux pannes comme des mécanismes entièrement redondants : toute défaillance de ces composants est conçue pour ne pas affecter la disponibilité du système. Cela inclut des composants tels que le stockage (Google Cloud Storage, Persistent Disks) et le réseau (Google Network, Cloud DNS, Cloud Load Balancer).

Les services à haute disponibilité disposent d'un mécanisme de récupération automatique de tous les composants architecturaux pertinents également appelés points de défaillance uniques. Ce mécanisme réduit la durée maximale d’interruption admissible (ou RTO pour Recovery Time Objective) et la durée maximum d’enregistrement des données qu’il est acceptable de perdre lors d’une panne (ou RPO pour Recovery Point Objective). Cette approche hautement résiliente implique généralement la réplication des composants et l'automatisation du processus de basculement entre eux.

Quatre niveaux de haute disponibilité SAP sur Google Cloud

La solution unique et universelle répondant aux besoins de haute de disponibilité n’existe pas pour la simple raison que chaque client SAP contracte des accords SLA, notamment en termes de haute disponibilité, qui lui sont propres et ses objectifs varient en fonction de ses besoins métier, de son budget ou encore de son utilisation des applications.

Examinons l'infrastructure d’un environnement de haute disponibilité SAP, les composants de disponibilité des systèmes d'exploitation et des applications, et ce que vous devez prendre en compte pour mettre en place une stratégie globale de disponibilité de votre système SAP.

Niveau 1 : Infrastructure

De nombreux clients constatent que le simple fait de déplacer leur système SAP interne vers Google Cloud permet d’en augmenter significativement la disponibilité : ils bénéficient automatiquement des fonctions intégrées de sécurité, de mise en réseau, de calcul et de stockage de la plateforme GCP, qui, par défaut, sont hautement disponibles.

Services de calcul

Les services de calcul de Google Cloud Compute Engine proposent trois fonctionnalités particulièrement importantes. Elles permettent de réduire, voire d'éliminer, les interruptions des applications dues à des défaillances matérielles :

Live Migration : Lorsque les instances VM d'un client sont exécutées sur un système hôte qui nécessite une maintenance planifiée, Live Migration (migration à chaud) déplace l'instance VM d'un hôte à un autre, sans déclencher de redémarrage ou perturber l'application. La fonctionnalité est intégrée à la plateforme : chaque utilisateur de Google Cloud en dispose sans frais supplémentaires. Elle fonctionne de manière transparente et automatique, quelle que soit la taille ou la complexité des workloads. Preuve de sa résilience, Google Cloud effectue la maintenance du matériel et applique les correctifs et les mises à jour de sécurité de l'hyperviseur à l'échelle mondiale et de manière transparente, sans jamais demander à un seul client de redémarrer sa VM. De fait, notre maintenance n'a aucune incidence sur vos applications en cours d'exécution grâce à la puissance de notre solution Live Migration.

Memory Poisoning Recovery (MPR) : aussi fiable soit-elle, une infrastructure de très haute qualité peut connaitre une panne. Ainsi, l’erreur mémoire reste un des dysfonctionnements matériels les plus courants, comme le montre notre étude sur la fiabilité de la mémoire.
Les architectures des CPU modernes disposent de fonctionnalités natives, telles que la fonction ECC (pour Error Correction Code) qui permet aux hôtes de récupérer les erreurs les plus courantes de corruption de données en mémoire. Les erreurs non corrigibles, en revanche, provoquent le crash et le redémarrage de toutes les VM de l'hôte, ce qui entraîne des arrêts imprévus.

Si vous disposez de bases de données HANA, vous devez également tenir compte du temps nécessaire pour recharger les données en mémoire. Dans ce cas, une panne de l'hôte peut entraîner des heures d'interruption de service critique pour l'entreprise, en fonction de la taille de la base de données.

Google Cloud a développé une solution qui combine les capacités de traitement des erreurs natives aux CPU, les capacités de SAP HANA et celles de Google Cloud pour réduire les perturbations et les temps d'arrêt dus aux erreurs de mémoire. Avec Memory Poisoning Recovery (MPR ou récupération de l’empoisonnement de la mémoire), l'erreur de mémoire non corrigible est détectée et isolée jusqu'à ce que les VM puissent être « live migrées » hors de l'hôte affecté.

Si l'erreur non corrigible est détectée sur une VM hébergeant SAP HANA, Google Cloud MPR envoie un signal à SAP HANA, avec l'option Fast Restart activée, pour recharger uniquement la mémoire affectée à partir du disque, résolvant ainsi le problème sans interruption de service dans la plupart des cas. Par la suite, toutes les machines virtuelles de l'hôte affecté sont migrées en direct vers un hôte sain afin d'éviter toute interruption de service ou perturbation des applications du client fonctionnant sur ces machines virtuelles.

Automatic Restart : Dans les rares cas où un arrêt non planifié ne peut être évité, la fonction Automatic Restart (Redémarrage automatique) entre en action. Elle redémarre automatiquement l'instance de la VM sur un autre hôte. Si nécessaire, elle appelle un script de démarrage défini par l'utilisateur pour s'assurer que l'application exécutée au-dessus de la VM redémarre en même temps. L'objectif est de garantir la reprise la plus rapide possible après un arrêt non planifié, tout en proposant un processus aussi simple et fiable que possible pour les utilisateurs.  

L’objectif de tous ces services de haute disponibilité est d’augmenter le temps de fonctionnement d’un nœud unique. Mais les workloads hautement critiques ont besoin de résilience contre des défaillances plus globales, y compris une panne complète de la zone GCP ! Pour couvrir ce besoin, Google Cloud Compute Engine garantit un SLA mensuel de 99,99 % pour des instances distribuées sur de multiples zones.

Stockage NFS (Network File System)

Autre composant important d’une infrastructure SAP hautement disponible, le stockage NFS est utilisé pour les fichiers partagés SAP, tels le répertoire des interfaces et la gestion du transport. Google Cloud offre plusieurs solutions de partage de fichiers qu’ils s’agissent de son propre outil Filestore Enterprise ou de solutions tierces telles que NetApp CVS-Performance, les deux solutions offrant une disponibilité de 99,99%. (Si vous avez besoin de plus d'informations pour comparer les solutions NFS sur Google Cloud, veuillez consulter la documentation disponible en ligne).

Niveau 2 : Système d’exploitation

Une partie critique du mécanisme de failover repose sur la gestion au niveau des systèmes d’exploitation du cluster des serveurs de calcul. Celle-ci permet de détecter rapidement les défaillances des composants et de déclencher les procédures de basculement afin de réduire au maximum les interruptions de services.

La mise en cluster au niveau du système d'exploitation sur Google Cloud est très similaire à celle sur site. Nous avons toutefois amélioré certaines fonctionnalités.

SUSE Enterprise Linux (SLES) et Red Hat Enterprise Linux (RHEL) implémentent tous deux Pacemaker en tant que gestionnaire des ressources mises en cluster. Tous deux intègrent des agents de mise en cluster conçus pour Google Cloud, ce qui leur permet de gérer de manière transparente des fonctions et des caractéristiques telles que la clôture STONITH, les routes VIP et les actions de stockage. Lors du déploiement de clusters OS sur Google Cloud, les clients peuvent tirer profit des « hooks » du fournisseur HA/DR qui permettent à SAP HANA d'envoyer des notifications pour garantir un basculement réussi sans perte de données. Pour plus d'informations, consultez la documentation détaillée sur la configuration des clusters HA sur RHEL et sur SLES dans nos guides de déploiement de SAP en environnement de haute disponibilité.

Les workloads exécutés sur Windows utilisent la technologie de « failover clustering » de Microsoft et disposent de fonctionnalités spéciales sur Google Cloud pour activer et configurer le cluster. Référez-vous à notre documentation détaillée pour en savoir plus.

Niveau 3 : Base de données

Chaque environnement SAP repose sur un système de base de données central qui stocke et gère les données essentielles à l'entreprise. Tout environnement SAP hautement disponible doit prendre en compte la disponibilité et l’intégrité de cette couche de base de données. Les systèmes SAP supportent une grande variété de systèmes de base de données, chacun proposant ses propres mécanismes pour optimiser les performances et garantir une haute disponibilité. Google Cloud prend en charge et documente l'utilisation des architectures HA pour les workloads SAP HANA, MaxDB, SAP ASE, IBM Db2, Microsoft SQL Server et Oracle (grâce à notre solution Bare Metal, vous pouvez utiliser du matériel certifié HA et même installer la solution Oracle RAC). Les clients ont ainsi la possibilité d’équilibrer les coûts et les avantages de la haute disponibilité pour leurs bases de données SAP.

SAP ​HANA System Replication​ (HSR) fait partie des technologies natives les plus importantes pour garantir la haute disponibilité de tout système SAP HANA. Elle fonctionne par réplication des données en continu d'un système primaire vers un ou plusieurs systèmes secondaires. Les données peuvent aussi être préchargées en mémoire pour permettre un basculement rapide en cas de sinistre.

Google Cloud prend en charge HSR et le complète avec l'utilisation de la réplication synchrone pour les instances SAP qui résident dans n'importe quelle zone de la même région. Les utilisateurs peuvent ainsi placer leurs instances primaires et secondaires dans des zones différentes pour les protéger contre un point de défaillance unique dans l'une ou l'autre zone.

D'autres systèmes de bases de données, tels que SAP ASE ou IBM Db2, offrent des fonctionnalités similaires et sont également compatibles avec l'infrastructure Google Cloud. Grâce à la faible latence du réseau entre les zones d'une même région et à nos outils de déploiement automatisé, les entreprises peuvent utiliser diverses options d'hébergement pour les bases de données en fonction de leurs besoins. Consultez notre documentation pour obtenir la liste actuelle des systèmes de bases de données pris en charge et des architectures de référence.

Niveau 4 : Serveur d’application

Les goulets d'étranglement au niveau du serveur d'applications peuvent impacter les temps de réponse. L'architecture NetWeaver de SAP permet de les éviter. Google Cloud tire parti de cet avantage en offrant aux clients des capacités de calcul et de mise en réseau hautement disponibles dont ils ont besoin pour se protéger contre la perte de données due à la synchronisation et pour tirer le maximum de fiabilité et de performances de SAP NetWeaver. Cette fonctionnalité repose sur un cluster au niveau du système d'exploitation (SLES ou RHEL), avec le gestionnaire de ressources de cluster Pacemaker et la clôture STONITH pour les services centraux ABAP SAP (ASCS) et le serveur de réplication Enqueue (ERS), chacun avec son propre load balancer interne (ILB) pour IP virtuelle. Vous trouverez une documentation détaillée sur le déploiement et la configuration des clusters HA pour RHEL et SLES dans nos guides de planification de haute disponibilité avec NetWeaver.

La répartition des instances de serveur d'application sur plusieurs zones d'une même région offre la meilleure protection contre les défaillances de zone tout en fournissant de bonnes performances à l'utilisateur final. Grâce à des déploiements automatisés, votre équipe informatique peut réagir rapidement aux évolutions de la demande et lancer des instances supplémentaires en quelques instants afin de maintenir le système SAP opérationnel, y compris pendant les pointes de trafic.

Autres avantages de Google Cloud pour la haute disponibilité des architectures SAP

Google Cloud peut contribuer à optimiser la disponibilité des systèmes SAP de bien d’autres façons, y compris face à des situations très complexes. Nous vous proposons ci-après quelques exemples. Nous attirons votre attention sur le fait que même certains grands comptes dotés de moyens considérables n’ont pas toujours la possibilité de déployer des fonctionnalités similaires à un coût abordable :

Distribution géographique et redondance. L'empreinte mondiale de Google Cloud comprend actuellement 30 régions, divisées en 91 zones et plus de 140 points de présence. En répartissant les principaux services Google Cloud sur plusieurs zones d'une même région, la plupart des utilisateurs SAP peuvent atteindre leurs objectifs de disponibilité sans sacrifier les performances ou exploser leur budget.

Des fonctionnalités d'équilibrage de charge puissantes et polyvalentes. Pour de nombreuses entreprises, l'équilibrage et la distribution de la charge constituent une façon de préserver la disponibilité de leurs applications SAP. Google Cloud est également présent sur ce terrain avec une large gamme d’options de load balancing. Le Load Balancing global peut notamment diriger le trafic vers une région saine la plus proche des utilisateurs. Nos fonctionnalités sont prévues pour réagir instantanément aux changements d'utilisateurs, de trafic, de réseau, d’état de santé du backend et autres conditions connexes. De plus, notre service Google Cloud Load Balancing est défini par le logiciel : il permet d’éviter les problèmes d'évolutivité et de gestion rencontrés par de nombreuses entreprises gérant l’équilibrage de charge de leurs infrastructures « physiquement ». Enfin, autre service important, le Load Balancing interne permet d'automatiser la mise en œuvre d'IP virtuelles (VIP) entre les systèmes primaires et secondaires.

Des outils qui optimisent la productivité des développeurs. La plateforme serverless de Google Cloud propose des solutions de calcul et de base de données managées intégrant des fonctionnalités de redondance et d’équilibrage de charge. Elle permet ainsi aux développeurs d’enrichir les systèmes SAP sans avoir à se soucier de l'infrastructure sous-jacente. Parallèlement, l’utilisation d’Apigee API Management leur permet de bénéficier d’interfaces évolutives pour accéder aux extensions développées. Avantage : l’architecture centrale est protégée des pics de trafics et des attaques malveillantes. Google Cloud prend également en charge le CI/CD grâce à des outils natifs et à des intégrations avec des technologies open source populaires, offrant ainsi aux organisations DevOps modernes les outils dont elles ont besoin pour livrer des logiciels plus rapidement et de manière plus sécurisée. En outre, Cortex Framework de Google Cloud fournit des accélérateurs ainsi que des bonnes pratiques pour réduire les risques, la complexité et les coûts des innovations associées à SAP. De plus, ce framework permet également aux utilisateurs SAP d’exploiter facilement et rapidement le meilleur de Google Cloud Analytics afin d’apporter toujours plus de valeur à l’entreprise.

Supervision flexible et complète. Google Cloud Monitoring offre aux entreprises une visibilité approfondie sur les performances, la disponibilité et l’état global des environnements SAP. Il enregistre des mesures, des événements et des métadonnées à partir de Google Cloud, d'Amazon Web Services, de sondes de fonctionnement hébergées, de superviseur d'applications et autres composants applicatifs tel que Cassandra, Nginx, Apache Web Server, Elasticsearch et bien d'autres. Avec un agent de surveillance personnalisé pour SAP HANA et l'agent Ops de Cloud Operation, Cloud Monitoring utilise ces données pour alimenter des tableaux de bord flexibles et des outils de visualisation riches, aidant ainsi les équipes SAP à identifier et à résoudre les problèmes avant qu'ils n'affectent votre entreprise.

Découvrez plus d’options HA