Guide de planification de la haute disponibilité pour SAP NetWeaver sur Google Cloud

Ce guide présente les options, les recommandations et les concepts généraux à connaître avant de déployer un système SAP NetWeaver à haute disponibilité (HA) sur Google Cloud.

Dans ce guide, nous supposons que vous avez assimilé les concepts et les pratiques généralement nécessaires à la mise en œuvre d'un système SAP NetWeaver à haute disponibilité. Par conséquent, le guide traitera principalement des informations à connaître pour mettre en œuvre un système de ce type sur Google Cloud.

Pour en savoir plus sur les concepts et les pratiques d'ordre général nécessaires à la mise en œuvre d'un système SAP NetWeaver à haute disponibilité, consultez les articles suivants :

Ce guide de planification couvre uniquement la haute disponibilité pour SAP NetWeaver, et non pour les systèmes de base de données. Pour plus d'informations sur la haute disponibilité pour SAP HANA, consultez le Guide de planification de haute disponibilité SAP HANA.

Architecture de déploiement

Le schéma suivant présente un cluster Linux HA de base utilisant le logiciel de cluster Pacemaker.

Le cluster contient deux hôtes : un hôte principal et un hôte secondaire. Chaque hôte est situé dans une zone différente de la même région.

Le cluster utilise le serveur SAP Standalone Enqueue Server 2 (ENSA2). Pour obtenir une description d'un cluster qui utilise la version antérieure du serveur Standalone Enqueue Server (ENSA1), consultez la section Architecture Standalone Enqueue Server (ENSA1).

L'instance active des services centraux (Central Services) se trouve sur l'hôte principal. L'instance active ERS (Enqueue Replication Server) se trouve sur l'hôte secondaire. Les services centraux et le service ERS possèdent chacun leur propre adresse IP virtuelle (VIP). Dans le schéma, "Central Services" peut représenter les services centraux SAP ABAP ou, pour une pile Java, les services centraux SAP.

Pour en savoir plus sur le serveur autonome 2 en configuration haute disponibilité, consultez la note SAP 2711036 - Usage of the Standalone Enqueue Server 2 in a HA Environment.

Une configuration HA de base pour SAP NetWeaver sur Google Cloud avec deux hôtes, situés chacun dans une zone différente

Architecture du serveur de file d'attente autonome (ENSA1)

Dans le schéma suivant, l'instance Central Services active, qui contient le service de gestion des verrous, ou Enqueue Service, et l'instance inactive du service de réplication de mise en file d'attente (Enqueue Replication Server, ERS) se trouvent sur l'hôte principal. L'instance ERS active et l'instance Central Services inactive se trouvent sur l'hôte secondaire. Chaque paire d'instances Central Services et ERS possède sa propre adresse IP virtuelle (VIP). Dans le schéma, "Central Services" peut représenter les services centraux SAP ABAP ou, pour une pile Java, les services centraux SAP.

En cas de défaillance, le logiciel de clustering à haute disponibilité doit déplacer le serveur de mise en file d'attente autonome vers le nœud sur lequel le serveur de mise en file d'attente de réplication est en cours d'exécution afin de conserver les informations de verrouillage. Pensez à mettre à jour votre système pour utiliser le serveur autonome de mise en file d'attente 2, si votre version du logiciel le permet. Pour plus d'informations, consultez la note SAP 2630416 - Support for Standalone Enqueue Server 2.

Une configuration HA de base pour SAP NetWeaver sur Google Cloud avec deux hôtes, situés chacun dans une zone différente

La haute disponibilité de l'infrastructure Google Cloud

Google Cloud est hautement disponible par essence, avec une infrastructure axée sur la forte redondance des centres de données, lesquels sont situés dans le monde entier et composés de zones conçues pour être indépendantes les unes des autres. Les zones disposent généralement de plans d'alimentation, de refroidissement, de mise en réseau et de contrôle isolés des autres zones. Dans la plupart des cas, les événements à défaillance unique n'affectent qu'une seule zone.

Dans certains cas, vous pouvez répondre à vos besoins de disponibilité sans mettre en œuvre toutes les protections traditionnelles sur site contre les défaillances matérielles, de stockage et de réseau, afin d'économiser du temps et de l'argent.

Avant de concevoir et de mettre en œuvre votre stratégie de haute disponibilité sur Google Cloud, consultez les contrats de niveau de service de Google Cloud.

Pour obtenir des informations générales sur la fiabilité, la confidentialité et la sécurité de Google Cloud, consultez la page Fiabilité.

Options de clustering à haute disponibilité pour les systèmes SAP sur Google Cloud

Pour définir un cluster à haute disponibilité pour SAP NetWeaver sur Google Cloud, vous devez utiliser les mêmes types de logiciels tiers de cluster à haute disponibilité que lors d'une installation sur site. Le logiciel de cluster HA surveille l'état des systèmes et gère le basculement en cas de problème.

Il existe plusieurs solutions logicielles de cluster HA. En voici quelques-unes :

  • Red Hat Enterprise Linux (RHEL) pour les solutions SAP
  • SUSE Linux Enterprise Server (SLES) pour les applications SAP
  • Clustering de basculement Windows Server

Logiciel de clustering à haute disponibilité Linux

Les versions récentes de RHEL et de SLES sont compatibles avec la haute disponibilité, activée spécifiquement pour Google Cloud. Pour vérifier si votre version de Linux inclut la haute disponibilité pour Google Cloud, recherchez "GCP-HA" dans le tableau de la section Compatibilité du système d'exploitation avec SAP NetWeaver sur Google Cloud.

Logiciel de clustering à haute disponibilité Windows

Sous Windows Server, c'est le clustering de basculement Windows Server (WSFC) qui permet de créer le cluster HA, comme indiqué dans la section Exécuter un clustering de basculement Windows Server.

Sur Google Cloud, l'acheminement du trafic entrant vers le nœud actif d'un cluster WSFC est géré par Cloud Load Balancing, qui ne nécessite pas la mise œuvre d'une adresse IP d'alias, ni d'une adresse IP virtuelle de route statique.

Cloud Load Balancing détermine le nœud actif à l'aide des vérifications de l'état.

Déploiements à haute disponibilité de SAP NetWeaver et de zones et régions Google Cloud

Déployez les nœuds de votre cluster HA sur au moins deux zones Compute Engine au sein d'une même région. Le déploiement des nœuds dans différentes zones permet de s'assurer qu'ils se trouvent sur des machines physiques différentes et assure une protection dans le cas improbable d'une défaillance de zone.

Conserver les zones au sein d'une même région garantit la proximité géographique des nœuds, et ainsi le respect des exigences de SAP en termes de latence pour les systèmes à haute disponibilité.

Déploiements à haute disponibilité de SAP NetWeaver et de machines virtuelles Compute Engine

Pour assurer la haute disponibilité, les VM Compute Engine sont protégées par la migration à chaud et le redémarrage automatique.

Migration à chaud de Compute Engine

Compute Engine contrôle l'état de l'infrastructure sous-jacente. Lorsqu'un événement de maintenance de l'infrastructure se produit, Compute Engine migre automatiquement l'instance hors de l'événement. Si possible, celle-ci reste en cours d'exécution pendant la migration. Aucune intervention n'est requise de la part de l'utilisateur.

En cas de pannes majeures, il peut s'écouler quelques instants entre le moment de défaillance de l'instance et sa disponibilité.

Dans la plupart des cas, les événements de migration à chaud se produisent sans affecter le cluster HA. Toutefois, il est recommandé de tester ce dernier en simulant une migration à chaud de l'hôte actif après la configuration du cluster HA et l'exécution des systèmes, en particulier si le cluster HA est configuré avec un seuil de basculement faible. Pour en savoir plus sur la simulation d'un événement de migration à chaud, consultez la section Tester les règles de disponibilité.

Une instance migrée est identique à l'instance d'origine et conserve les éléments associés suivants : ID d'instance, adresse IP privée, métadonnées et stockage.

Par défaut, les instances standards sont configurées pour une migration à chaud. Nous vous recommandons de ne pas modifier ce paramètre.

Pour en savoir plus, consultez la section Migrer à chaud.

Redémarrage automatique de Compute Engine

Si l'instance est configurée de manière à s'arrêter en cas d'événement de maintenance ou de plantage lié à un problème matériel sous-jacent, vous pouvez configurer Compute Engine pour qu'il la redémarre automatiquement. Par défaut, les instances sont configurées pour redémarrer automatiquement. Nous vous recommandons de ne pas modifier ce paramètre.

Pour en savoir plus sur le redémarrage automatique, consultez la section Redémarrage automatique.

Options de stockage partagé pour les systèmes SAP à haute disponibilité sur Google Cloud

Le système de fichiers global SAP NetWeaver est un point de défaillance unique qui doit être disponible pour toutes les instances SAP NetWeaver de votre système à haute disponibilité. Pour garantir la disponibilité du système de fichiers global sur Google Cloud, vous pouvez utiliser un espace de stockage partagé à haute disponibilité ou des disques persistants zonaux répliqués.

Pour disposer d'une solution de stockage partagé à haute disponibilité, vous pouvez utiliser Cloud Filestore ou des solutions tierces de partage de fichiers, telles que NetApp Cloud Volumes Service pour Google Cloud ou NetApp Cloud Volumes ONTAP.

Le niveau Enterprise de Filestore peut être utilisé pour les déploiements multizones à haute disponibilité et le niveau de base de Filestore peut être utilisé pour les déploiements sur zones uniques.

Pour la réplication de disques persistants zonaux pour les systèmes Linux, vous pouvez utiliser un périphérique DRBD (en mode bloc répliqué et distribué) afin de répliquer les disques persistants contenant le système de fichiers global SAP entre les nœuds de votre cluster à haute disponibilité.

Même si les disques persistants régionaux Compute Engine offrent un stockage de blocs répliqué de manière synchrone sur plusieurs zones, ils ne sont pas compatibles avec les systèmes SAP NetWeaver à haute disponibilité.

Pour en savoir plus sur les options de stockage sur Google Cloud, consultez les pages suivantes :

Options de mise en réseau pour les systèmes SAP à haute disponibilité

Lors de la configuration du réseau pour le cluster HA, vous devez suivre la procédure décrite dans la section Créer un réseau et effectuer les tâches suivantes spécifiques à la haute disponibilité :

  • Mettre en œuvre une adresse IP virtuelle (VIP) pour les systèmes Linux, comme décrit dans la section suivante. Les systèmes Windows utilisent un équilibreur de charge interne, qui nécessite des solutions VIP différentes de celles utilisées par les systèmes Linux.
  • Définir le chemin de communication entre l'instance SAP Central Services et l'instance Enqueue Replication Server.
  • Spécifier des règles de pare-feu compatibles avec les chemins de communication définis.

Mise en œuvre d'une adresse IP virtuelle sur Google Cloud

Un cluster à haute disponibilité utilise une adresse IP flottante ou virtuelle (IPV) pour déplacer sa charge de travail d'un nœud de cluster à un autre en cas de défaillance inattendue ou de maintenance planifiée. L'adresse IP de l'IPV ne changeant pas, les applications clientes ne savent pas que le travail est servi par un autre nœud.

Une adresse IP virtuelle est également appelée adresse IP flottante.

La mise en œuvre des adresses VIP sur Google Cloud est légèrement différente de celle des installations sur site. Lorsqu'un basculement a lieu, il n'est pas possible de l'annoncer à l'aide des requêtes ARP gratuites. À la place, vous pouvez mettre en œuvre une adresse VIP pour un cluster SAP HA en utilisant l'une des méthodes suivantes :

Implémentations IPV pour équilibreur de charge réseau passthrough interne

Un équilibreur de charge répartit généralement le trafic utilisateur entre plusieurs instances de vos applications, à la fois pour répartir la charge de travail sur plusieurs systèmes actifs et pour vous protéger contre un ralentissement ou une défaillance du traitement sur une instance.

L'équilibreur de charge réseau passthrough interne fournit également une assistance de basculement que vous pouvez utiliser avec les vérifications d'état de Compute Engine pour détecter les défaillances, déclencher le basculement et rediriger le trafic vers un nouveau système SAP principal dans un cluster haute disponibilité natif au système d'exploitation.

La prise en charge du basculement est la mise en œuvre IPV recommandée pour diverses raisons, y compris :

  • L'équilibrage de charge sur Compute Engine offre un SLA avec une disponibilité de 99,99 %.
  • L'équilibrage de charge est compatible avec les clusters à haute disponibilité multizones, ce qui vous protège contre les défaillances de zone avec des temps de basculement interzone prévisibles.
  • L'utilisation de l'équilibrage de charge réduit le temps nécessaire à la détection et au déclenchement d'un basculement, généralement quelques secondes après l'échec. Les temps de basculement globaux dépendent des temps de basculement de chacun des composants du système à haute disponibilité, qui peuvent inclure les hôtes, les systèmes de base de données, les systèmes d'application, etc.
  • L'utilisation de l'équilibrage de charge simplifie la configuration du cluster et réduit les dépendances.
  • Contrairement à une implémentation VIP utilisant des routes, avec l'équilibrage de charge, vous pouvez utiliser des plages d'adresses IP de votre propre réseau VPC, ce qui vous permet de les réserver et de les configurer selon vos besoins.
  • L'équilibrage de charge peut facilement être utilisé pour réacheminer le trafic vers un système secondaire en cas d'interruption de maintenance planifiée.

Lorsque vous créez une vérification de l'état pour la mise en œuvre d'un équilibreur de charge d'une adresse IP virtuelle, vous spécifiez le port hôte que la vérification de l'état sonde pour déterminer l'état de l'hôte. Pour un cluster SAP HA, spécifiez un port hôte cible situé dans la plage privée (49152 à 65535) afin d'éviter toute interférence avec d'autres services. Sur la VM hôte, configurez le port cible avec un service d'assistance secondaire, tel que l'utilitaire Socat ou HAProxy.

Pour les clusters de base de données dans lesquels le système de secours secondaire reste en ligne, la vérification de l'état et le service d'aide permettent à l'équilibrage de charge de diriger le trafic vers le système en ligne qui sert actuellement de système principal dans le cluster.

À l'aide du service d'aide et de la redirection de port, vous pouvez déclencher un basculement pour une maintenance logicielle planifiée sur vos systèmes SAP.

Pour en savoir plus sur la prise en charge du basculement, consultez la page Configurer le basculement pour les équilibreurs de charge réseau passthrough internes.

Pour déployer un cluster à haute disponibilité avec une mise en œuvre d'une IPV par équilibreur de charge, consultez les pages suivantes :

Mise en œuvre d'une IPV de routes statiques

La mise en œuvre de la route statique offre également une protection contre les défaillances de zone, mais vous oblige à utiliser une adresse IP virtuelle en dehors des plages d'adresses IP de vos sous-réseaux VPC existants. Par conséquent, vous devez également vous assurer que l'adresse IP virtuelle n'entre pas en conflit avec les adresses IP externes de votre réseau étendu.

Les mises en œuvre de routes statiques peuvent également compliquer l'utilisation de configurations VPC partagées, destinées à séparer la configuration réseau d'un projet hôte.

Si vous utilisez une mise en œuvre de route statique pour votre adresse IP virtuelle, consultez votre administrateur réseau afin de déterminer une adresse IP appropriée pour une mise en œuvre de route statique.

Mise en œuvre d'une IPV des adresses IP d'alias

Les implémentations IPV d'adresses IP d'alias ne sont pas recommandées pour les déploiements multizones haute disponibilité, car en cas de défaillance d'une zone, l'emplacement réel de l'adresse IP d'alias sur un nœud situé dans une zone différente peut être retardé. Mettez en œuvre votre adresse IP virtuelle avec un équilibreur de charge réseau passthrough interne compatible avec le basculement.

Si vous déployez tous les nœuds de votre cluster SAP HA dans la même zone, vous pouvez utiliser une adresse IP d'alias afin de mettre en œuvre une adresse IP virtuelle pour le cluster.

Si vous possédez des clusters SAP HA multizones qui utilisent une mise en œuvre d'IP d'alias pour l'adresse IP virtuelle, vous pouvez migrer vers une implémentation d'équilibreur de charge réseau passthrough interne sans modifier votre adresse IP virtuelle. Les adresses IP d'alias et les équilibreurs de charge réseau passthrough interne utilisent des plages d'adresses IP de votre réseau VPC.

Bien que les adresses IP d'alias ne soient pas recommandées pour les implémentations d'adresses IP virtuelles dans les clusters multizones à haute disponibilité, elles ont d'autres cas d'utilisation dans les déploiements SAP. Par exemple, elles peuvent être utilisées pour fournir un nom d'hôte logique et des attributions d'adresses IP pour les déploiements SAP flexibles, tels que ceux gérés par SAP Landscape Management.

Bonnes pratiques générales pour les adresses IP virtuelles sur Google Cloud

Pour en savoir plus sur les adresses IP virtuelles sur Google Cloud, consultez la page Bonnes pratiques pour les adresses IP flottantes.

Configurer des clusters à haute disponibilité pour SAP NetWeaver sur Google Cloud

Google Cloud fournit un fichier de configuration Terraform que vous pouvez utiliser pour automatiser le déploiement de systèmes SAP NetWeaver à haute disponibilité, ou vous pouvez déployer et configurer vos systèmes SAP NetWeaver à haute disponibilité manuellement.

Pour automatiser le déploiement des systèmes SAP NetWeaver à haute disponibilité, vous devez renseigner le fichier de configuration Terraform et utiliser les commandes Terraform standards pour appliquer les configurations. Consultez les pages suivantes pour obtenir des instructions sur le déploiement :

La méthode de déploiement automatisé déploie l'infrastructure Google Cloud pour un système SAP NetWeaver entièrement compatible avec SAP et conforme aux bonnes pratiques de SAP et de Google Cloud.

Pour SAP NetWeaver, la méthode de déploiement automatisé déploie un cluster Linux à haute disponibilité et aux performances optimisées, qui comprend :

  • Le basculement automatique
  • Le redémarrage automatique
  • Une réservation de l'adresse IP virtuelle (VIP) que vous spécifiez
  • La compatibilité de basculement à l'aide de l'équilibrage de charge TCP/UDP interne, qui gère le routage depuis l'adresse IP virtuelle (VIP) vers les nœuds du cluster à haute disponibilité
  • Une règle de pare-feu qui permet aux vérifications de l'état de Compute Engine de surveiller les instances de VM du cluster.
  • Le gestionnaire de ressources de cluster à haute disponibilité Pacemaker
  • Un mécanisme de cloisonnement Google Cloud, l'agent de cloisonnement fence_gce
  • Une VM dotée des disques persistants requis pour chaque instance SAP NetWeaver

Consultez les pages suivantes pour obtenir des instructions sur le déploiement et la configuration manuelle d'un cluster à haute disponibilité sur Google Cloud pour SAP NetWeaver :