Guide de configuration d'un cluster à haute disponibilité pour SAP NetWeaver sur RHEL

Ce guide explique comment déployer et configurer un cluster Red Hat Enterprise Linux (RHEL) à haute disponibilité et hautes performances pour un système SAP NetWeaver.

À l'exception des procédures spécifiques au serveur autonome de mise en file d'attente 2 (ENSA2), qui n'est disponible que dans ABAP, ce guide s'applique aux piles SAP NetWeaver ABAP et Java.

Sauf indication contraire dans le guide, les exemples utilisant "ASCS" sont valides pour les services centraux SAP ABAP (ASCS) et les services centraux SAP (SCS) Java.

Si vous utilisez une pile Java, remplacez toutes les instances de "ASCS" par "SCS" avant d'utiliser les commandes ou les exemples de ce guide.

Ce guide comprend les étapes suivantes :

• Configurer un équilibreur de charge réseau interne à stratégie directe pour rediriger le trafic en cas de défaillance
• Configurer un cluster Pacemaker sur RHEL pour gérer les systèmes SAP et d'autres ressources lors d'un basculement

Ce guide comprend également les étapes de configuration du système SAP NetWeaver pour la haute disponibilité, mais reportez-vous à la documentation SAP pour obtenir les instructions définitives.

Pour en savoir plus sur le déploiement de VM Compute Engine pour SAP NetWeaver non spécifiques à la haute disponibilité, consultez le guide de déploiement de SAP NetWeaver spécifique à votre système d'exploitation.

Pour configurer un cluster à haute disponibilité pour SAP NetWeaver sur SUSE Linux Enterprise Server (SLES), consultez le guide de configuration manuelle d'un cluster à haute disponibilité pour SAP NetWeaver sur SLES.

Ce guide est destiné aux utilisateurs avancés de SAP NetWeaver qui connaissent bien les configurations Linux à haute disponibilité pour SAP NetWeaver.

Système déployé dans ce guide

En suivant ce guide, vous allez déployer deux instances SAP NetWeaver et configurer un cluster à haute disponibilité sur RHEL. Chacune de ces instances SAP NetWeaver va être déployée sur des VM Compute Engine situées dans des zones différentes, mais au sein de la même région. Ce guide ne traite pas de l'installation à haute disponibilité de la base de données sous-jacente.

Le cluster déployé inclut les fonctions et fonctionnalités suivantes :

• Deux VM hôtes, l'une pour l'instance ASCS active et l'autre pour l'instance active d'un serveur de réplication de mise en file d'attente ENSA2 ou ENSA1. Les instances ENSA2 et ENSA1 sont appelées ERS.
• Le gestionnaire de ressources de cluster à haute disponibilité Pacemaker
• Un mécanisme de cloisonnement STONITH
• Le redémarrage automatique de l'instance ayant échoué en tant que nouvelle instance secondaire

Ce guide utilise les modèles Cloud Deployment Manager fournis par Google Cloud pour déployer les machines virtuelles (VM) Compute Engine, ce qui garantit que les VM répondent aux exigences de compatibilité de SAP et sont conformes aux meilleures pratiques actuelles.

Pour automatiser le déploiement d'un système SAP NetWeaver à haute disponibilité, utilisez Terraform : guide de configuration d'un cluster à haute disponibilité pour SAP NetWeaver sur RHEL.

Prérequis

Avant de créer le cluster à haute disponibilité SAP NetWeaver, assurez-vous que les conditions préalables suivantes sont remplies :

• Vous avez lu le guide de planification SAP NetWeaver et le guide de planification de la haute disponibilité pour SAP NetWeaver sur Google Cloud.
• Vous ou votre organisation disposez d'un compte Google Cloud et avez créé un projet pour le déploiement de SAP NetWeaver. Pour en savoir plus sur la création de comptes et de projets Google Cloud, consultez la section Créer un projet dans le guide de déploiement de SAP NetWeaver pour Linux.
• Si vous souhaitez que votre charge de travail SAP s'exécute conformément aux exigences liées à la résidence des données, au contrôle des accès, au personnel d'assistance ou à la réglementation, vous devez créer le dossier Assured Workloads requis. Pour en savoir plus, consultez la page Contrôles de conformité et de souveraineté pour SAP sur Google Cloud.

• Si vous utilisez un DNS interne de VPC, la valeur de la variable vmDnsSetting dans les métadonnées de votre projet doit être GlobalOnly ou ZonalPreferred afin de permettre la résolution des noms de nœuds entre zones. La valeur par défaut de vmDnsSetting est ZonalOnly. Pour en savoir plus, consultez les pages suivantes :

  • Configurer des noms DNS pour votre projet ou vos instances
  • Interroger les métadonnées personnalisées
  • Définir des métadonnées personnalisées à l'échelle du projet

• Vous avez configuré un partage de fichiers à l'aide d'une solution de stockage de fichiers partagée NFS, telle que Filestore Enterprise.

• Si OS Login est activé dans les métadonnées de votre projet, vous devrez le désactiver temporairement jusqu'à la fin du déploiement. Pour le déploiement, cette procédure configure les clés SSH dans les métadonnées d'instance. Lorsque OS Login est activé, les configurations de clé SSH basées sur les métadonnées sont désactivées et le déploiement échoue. Une fois le déploiement terminé, vous pouvez réactiver OS Login.

  Pour en savoir plus, consultez les pages suivantes :

  • Activer ou désactiver OS Login
  • Ajouter des clés SSH aux VM qui utilisent des clés SSH basées sur des métadonnées

Pour éviter d'exposer involontairement votre instance de VM sur Internet, suivez les recommandations ci-dessous :

• Utilisez une passerelle NAT.
• Créez des règles de pare-feu qui bloquent tous les accès externes dont vous n'avez pas besoin.
• Lorsque vous créez vos VM, effectuez les opérations suivantes :
  • Spécifiez pour chaque VM un tag réseau à utiliser dans les règles de routage et de pare-feu. Si vous utilisez le modèle Deployment Manager fourni par Google Cloud, spécifiez un tag avec networkTag: [TAG].
  • Créez les VM sans adresse IP externe. Si vous utilisez les modèles Deployment Manager fournis par Google Cloud, spécifiez publicIP: No.

Informations associées provenant de RHEL

Sauf indication contraire pour l'environnement Google Cloud, les informations de ce guide sont cohérentes avec les guides associés Red Hat et SAP :

• Configurer SAP NetWeaver ASCS/ERS ENSA1 avec des ressources autonomes dans RHEL 7.5+ et RHEL 8
• Configurer SAP S/4HANA ASCS/ERS avec le serveur autonome de mise en file d'attente 2 (ENSA2) dans Pacemaker
• Note SAP 2002167 – Red Hat Enterprise Linux 7.x : installation et mise à niveau
• Note SAP 2772999 – Red Hat Enterprise Linux 8.x : installation et configuration
• Note SAP 3108316 – Red Hat Enterprise Linux 9.x : installation et configuration
• Note SAP 2641322 – Installation de ENSA2 et mise à jour de ENSA1 vers ENSA2 lors de l'utilisation des solutions Red Hat à haute disponibilité pour SAP

Créer un réseau

Pour des raisons de sécurité, nous vous recommandons de créer un réseau, dont vous contrôlez les accès en ajoutant des règles de pare-feu ou toute autre méthode.

Si votre projet dispose d'un réseau VPC par défaut, ne l'utilisez pas. À la place, créez votre propre réseau VPC afin que les seules règles de pare-feu appliquées soient celles que vous créez explicitement.

Lors du déploiement, les instances de VM nécessitent généralement un accès à Internet pour télécharger l'agent Google Cloud pour SAP. Si vous utilisez l'une des images Linux certifiées SAP disponibles dans Google Cloud, l'instance de VM requiert également l'accès à Internet pour enregistrer la licence et accéder aux dépôts des fournisseurs d'OS. Une configuration comprenant une passerelle NAT et des tags réseau de VM permet aux VM cibles d'accéder à Internet même si elles ne possèdent pas d'adresses IP externes.

Pour configurer la mise en réseau, procédez comme suit :

Console

1. Dans Google Cloud Console, accédez à la page Réseaux VPC.

   Accéder aux réseaux VPC

2. Cliquez sur Créer un réseau VPC.
3. Saisissez un Nom pour le réseau.

   Le nom doit respecter la convention d'attribution de noms. Les réseaux VPC utilisent la convention d'attribution de noms de Compute Engine.

4. Dans le champ Mode de création du sous-réseau, sélectionnez Custom.
5. Dans la section Nouveau sous-réseau, spécifiez les paramètres de configuration de sous-réseau suivants :
   1. Saisissez un nom pour le sous-réseau.
   2. Dans le champ Région, sélectionnez la région Compute Engine dans laquelle vous souhaitez créer le sous-réseau.
   3. Pour Type de pile IP, sélectionnez IPv4 (pile unique), puis saisissez une plage d'adresses IP au format CIDR, telle que 10.1.0.0/24.

      Il s'agit de la plage IPv4 principale du sous-réseau. Si vous envisagez d'ajouter plusieurs sous-réseaux, attribuez à chacun d'eux des plages d'adresses IP CIDR qui ne se chevauchent pas dans le réseau. Notez que chaque sous-réseau et ses plages d'adresses IP internes sont mappés sur une seule région.

   4. Cliquez sur OK.
6. Pour ajouter d'autres sous-réseaux, cliquez sur Ajouter un sous-réseau et répétez les étapes ci-dessus. Vous pouvez ajouter d'autres sous-réseaux au réseau après sa création.
7. Cliquez sur Create (Créer).

gcloud

1. Accédez à Cloud Shell.

   Accéder à Cloud Shell

2. Pour créer un réseau en mode de sous-réseau personnalisé, exécutez la commande suivante :

   gcloud compute networks create NETWORK_NAME --subnet-mode custom

   Remplacez NETWORK_NAME par le nom du nouveau réseau. Le nom doit respecter la convention d'attribution de noms. Les réseaux VPC utilisent la convention de dénomination de Compute Engine.

   Spécifiez --subnet-mode custom pour éviter d'utiliser le mode automatique par défaut, qui crée automatiquement un sous-réseau dans chaque région Compute Engine. Pour en savoir plus, consultez la section Mode de création du sous-réseau.

3. Créez un sous-réseau, et spécifiez la région et la plage d'adresses IP :

   gcloud compute networks subnets create SUBNETWORK_NAME \
       --network NETWORK_NAME --region REGION --range RANGE

   Remplacez les éléments suivants :

   • SUBNETWORK_NAME : nom du nouveau sous-réseau
   • NETWORK_NAME : nom du réseau que vous avez créé à l'étape précédente
   • REGION : région dans laquelle vous souhaitez créer le sous-réseau
   • RANGE : plage d'adresses IP spécifiée au format CIDR (par exemple, 10.1.0.0/24)

     Si vous envisagez d'ajouter plusieurs sous-réseaux, attribuez à chacun d'eux des plages d'adresses IP CIDR qui ne se chevauchent pas. Notez que chaque sous-réseau et ses plages d'adresses IP internes sont mappés sur une seule région.

4. Si vous le souhaitez, répétez l'étape précédente et ajoutez des sous-réseaux.

Configurer une passerelle NAT

Si vous avez besoin de créer une ou plusieurs VM sans adresse IP publique, vous devez utiliser la traduction d'adresse réseau (NAT) pour permettre aux VM d'accéder à Internet. Utilisez Cloud NAT, un service géré distribué et défini par logiciel de Google Cloud, qui permet aux VM d'envoyer des paquets sortants vers Internet et de recevoir tous les paquets de réponses entrants établis correspondants. Vous pouvez également configurer une VM distincte en tant que passerelle NAT.

Point clé : Lorsque vous configurez Cloud NAT, spécifiez le nombre minimal de ports par VM sur au moins 160. Certaines mises à jour du système d'exploitation exécutent des processus simultanés qui peuvent dépasser la valeur par défaut de Cloud NAT pour le nombre de ports, ce qui peut entraîner des erreurs d'activation ou de téléchargement.

Lorsque vous créez une instance Cloud NAT à partir de la page "Créer une passerelle NAT" de la console Google Cloud, spécifiez le nombre de ports dans le champ Nombre minimal de ports par VM situé sous Configurations avancées.

Pour créer une instance Cloud NAT pour votre projet, consultez la page Utiliser Cloud NAT.

Une fois que vous avez configuré Cloud NAT pour votre projet, vos instances de VM peuvent accéder en toute sécurité à Internet sans adresse IP publique.

Ajouter des règles de pare-feu

Par défaut, les connexions entrantes extérieures au réseau Google Cloud sont bloquées. Pour autoriser les connexions entrantes, configurez une règle de pare-feu pour votre VM. Les règles de pare-feu ne régulent que les nouvelles connexions entrantes vers une VM. Une fois la connexion avec une VM établie, le trafic est autorisé dans les deux directions via cette connexion.

Vous pouvez créer une règle de pare-feu qui autorise l'accès à des ports spécifiés ou pour autoriser l'accès entre plusieurs VM d'un même sous-réseau.

Créez des règles de pare-feu pour autoriser l'accès à des éléments tels que :

• Les ports par défaut utilisés par SAP NetWeaver, comme indiqué dans le document Ports TCP/IP de tous les produits SAP.
• Les connexions de votre ordinateur ou votre environnement de réseau d'entreprise vers votre instance de VM Compute Engine. Si vous ne savez pas quelle adresse IP utiliser, contactez l'administrateur réseau de votre entreprise.
• Communication entre VM dans une configuration à trois niveaux, évolutive ou à haute disponibilité. Par exemple, si vous déployez un système à trois niveaux, votre sous-réseau comprend au moins deux VM : une VM pour SAP NetWeaver et une autre pour le serveur de base de données. Pour activer la communication entre deux VM, vous devez créer une règle de pare-feu autorisant le trafic provenant du sous-réseau.
• Vérifications d'état de Cloud Load Balancing. Pour en savoir plus, consultez la section Créer une règle de pare-feu pour les vérifications d'état.

Remarque : La procédure suivante est une version simplifiée des instructions permettant de créer des règles de pare-feu. Pour obtenir des informations plus détaillées, consultez la documentation sur le cloud privé virtuel.

Pour créer une règle de pare-feu, procédez comme suit :

1. Dans la console Google Cloud, accédez à la page Pare-feu du réseau VPC.

   Accéder à la page "Pare-feu"

2. En haut de la page, cliquez sur Créer une règle de pare-feu.

   • Dans le champ Réseau, sélectionnez le réseau sur lequel se trouve votre machine virtuelle.
   • Dans le champ Cibles, sélectionnez Toutes les instances du réseau.
   • Dans le champ Filtre source, sélectionnez l'une des options suivantes :
     • Plages d'adresses IP pour autoriser le trafic entrant provenant d'adresses IP spécifiques. Indiquez la plage d'adresses IP dans le champ Plages d'adresses IP sources.
     • Sous-réseaux pour autoriser le trafic entrant provenant d'un sous-réseau spécifique. Spécifiez le nom du sous-réseau dans le champ du sous-réseau suivant. Vous pouvez utiliser cette option pour autoriser l'accès entre plusieurs VM dans une organisation évolutive ou à trois niveaux.
   • Dans la section Protocoles et ports, sélectionnez Protocoles et ports spécifiés et spécifiez tcp:PORT_NUMBER;.

3. Cliquez sur Créer pour créer la règle de pare-feu.

Déployer les VM pour SAP NetWeaver

Avant de commencer à configurer le cluster à haute disponibilité, vous devez définir et déployer les instances de VM qui serviront de nœuds principal et secondaire dans le cluster à haute disponibilité.

Pour définir et déployer les VM, utilisez le même modèle Cloud Deployment Manager que celui qui a servi à déployer une VM pour un système SAP NetWeaver dans le déploiement automatisé de VM pour SAP NetWeaver sous Linux.

Toutefois, pour déployer deux VM au lieu d'une, vous devez ajouter la définition de la seconde VM au fichier de configuration en copiant et en collant la définition de la première VM. Après avoir créé la seconde définition, vous devez modifier les noms des ressources et des instances dans celle-ci. Pour vous protéger contre une défaillance de zone, spécifiez une zone différente de la même région. Toutes les autres propriétés des deux définitions conservent la même valeur.

Une fois les VM déployées, vous installez SAP NetWeaver avant de définir et de configurer le cluster à haute disponibilité.

Les instructions suivantes utilisent Cloud Shell, mais sont généralement applicables à Google Cloud CLI.

1. Ouvrez Cloud Shell.

   Accéder à Cloud Shell

2. Téléchargez le modèle de fichier de configuration template.yaml dans votre répertoire de travail :

   wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/template.yaml

3. Renommez éventuellement le fichier template.yaml pour identifier la configuration qu'il définit. Exemple :nw-ha-rhel-8-4.yaml

4. Pour ouvrir le fichier de configuration YAML dans l'éditeur de code Cloud Shell, cliquez sur l'icône en forme de crayon () située en haut à droite de la fenêtre du terminal Cloud Shell pour lancer l'éditeur.

5. Dans le modèle de fichier de configuration YAML, définissez la première instance de VM. Vous définissez la seconde instance de VM à l'étape suivante après le tableau ci-dessous.

   Spécifiez les valeurs des propriétés en remplaçant les crochets et leur contenu par les valeurs de votre installation. Ces propriétés sont décrites dans le tableau ci-dessous. Pour obtenir un exemple de fichier de configuration complet, consultez la section Exemple de fichier de configuration YAML complet.

   Valeur	Type de données	Description
   name	String	Nom arbitraire qui identifie la ressource de déploiement définie par l'ensemble de propriétés suivant.
   type	String	Spécifie l'emplacement, le type et la version du modèle Deployment Manager à utiliser lors du déploiement. Le fichier YAML comprend deux spécifications type, dont l'une est laissée en commentaire. La spécification type qui est active par défaut spécifie la version du modèle en tant que latest. La spécification type qui est laissée en commentaire spécifie une version de modèle spécifique avec un horodatage. Si tous vos déploiements doivent utiliser la même version de modèle, utilisez la spécification type qui inclut l'horodatage.
   instanceName	String	Nom de l'instance de VM que vous définissez. Spécifiez des noms différents dans les définitions des VM principale et secondaire. Pensez à utiliser des noms qui identifient les instances comme appartenant au même cluster à haute disponibilité. Les noms d'instances ne doivent pas comporter plus de 13 caractères et doivent être composés de minuscules, de chiffres ou de traits d'union. Choisissez un nom unique dans votre projet.
   instanceType	String	Type de VM Compute Engine dont vous avez besoin Spécifiez le même type d'instance pour les VM principale et secondaire. Si vous avez besoin d'un type de VM personnalisé, spécifiez un petit type de VM prédéfini et, une fois le déploiement terminé, personnalisez la VM selon les besoins.
   zone	String	Zone Google Cloud dans laquelle déployer l'instance de VM que vous définissez. Spécifiez des zones différentes de la même région pour les définitions des VM principale et secondaire. Ces zones doivent se trouver dans la même région que celle que vous avez sélectionnée pour votre sous-réseau.
   subnetwork	String	Nom du sous-réseau que vous avez créé à une étape précédente. Si vous procédez au déploiement sur un VPC partagé, spécifiez cette valeur en tant que SHAREDVPC_PROJECT/SUBNETWORK. Exemple :myproject/network1
   linuxImage	String	Nom de l'image du système d'exploitation Linux ou de la famille d'images que vous utilisez avec SAP NetWeaver. Pour spécifier une famille d'images, ajoutez le préfixe family/ au nom de la famille. Par exemple, family/rhel-8-4-sap-ha. Pour obtenir la liste des familles d'images disponibles, consultez la page Images dans la console Google Cloud.
   linuxImageProject	String	Le projet Google Cloud qui contient l'image que vous allez utiliser. Ce projet peut être votre propre projet ou le projet d'image Google Cloud rhel-sap-cloud. Pour obtenir la liste des projets d'image Google Cloud, consultez la page Images dans la documentation Compute Engine.
   usrsapSize	Entier	Taille du disque /usr/sap. La taille minimale est de 8 Go.
   sapmntSize	Entier	Taille du disque /sapmnt. La taille minimale est de 8 Go.
   swapSize	Entier	Taille du volume d'échange. La taille minimale est de 1 Go.
   networkTag	String	Facultatif. Un ou plusieurs tags réseau séparés par une virgule représentant votre instance de VM à des fins de routage ou de pare-feu. Pour les configurations à haute disponibilité, spécifiez un tag réseau à utiliser pour une règle de pare-feu qui autorise la communication entre les nœuds du cluster et un tag réseau à utiliser dans une règle de pare-feu autorisant les vérifications d'état de Cloud Load Balancing à accéder aux nœuds du cluster. Si vous spécifiez publicIP: No et ne spécifiez pas de tag réseau, veillez à fournir un autre moyen d'accès à Internet.
   serviceAccount	String	Facultatif. Spécifie un compte de service personnalisé à utiliser pour la VM déployée. Le compte de service doit bénéficier des autorisations requises pour configurer la VM pour SAP lors du déploiement. Si serviceAccount n'est pas spécifié, le compte de service Compute Engine par défaut est utilisé. Spécifiez l'adresse complète du compte de service. Exemple : [e-mail]
   publicIP	Booléen	Facultatif. Détermine si une adresse IP publique est ajoutée à votre instance de VM. La valeur par défaut est Yes. Remarque : Ne spécifiez No que si vous avez configuré une passerelle NAT avec un tag réseau défini pour la VM ou si vous avez fourni à la VM une autre route vers Internet. Si aucun moyen d'accès à Internet n'est disponible, l'installation échoue.
   sap_deployment_debug	Booléen	Facultatif. Si cette valeur est définie sur Yes, le déploiement génère des journaux de déploiement détaillés. Vous ne devez activer ce paramètre que si un ingénieur de l'assistance Google vous demande d'activer le débogage.

6. Dans le fichier de configuration YAML, créez la définition de la deuxième VM en faisant un copier-coller de la définition de la première VM après la première définition. Pour obtenir un exemple, consultez Exemple de fichier de configuration YAML complet.

7. Dans la définition de la deuxiène VM, spécifiez des valeurs différentes de celles spécifiées dans la première définition pour les propriétés suivantes :

   • name
   • instanceName
   • zone

8. Créez les instances de VM :

   gcloud deployment-manager deployments create DEPLOYMENT_NAME --config TEMPLATE_NAME.yaml

   où :

   • DEPLOYMENT_NAME représente le nom de votre déploiement.
   • TEMPLATE_NAME représente le nom de votre fichier de configuration YAML.

   La commande précédente appelle Deployment Manager qui déploie les VM conformément aux spécifications du fichier de configuration YAML.

   Le processus de déploiement comprend deux étapes. Tout d'abord, Deployment Manager écrit son état dans la console. Ensuite, les scripts de déploiement écrivent leur état dans Cloud Logging.

Exemple de fichier de configuration YAML complet

L'exemple suivant est un fichier de configuration YAML complet qui déploie deux instances de VM pour une configuration à haute disponibilité pour SAP NetWeaver à l'aide de la dernière version des modèles Deployment Manager. L'exemple omet les commentaires insérés dans le modèle lorsque vous le téléchargez pour la première fois.

Le fichier contient les définitions des deux ressources à déployer : sap_nw_node_1 et sap_nw_node_2. Chaque définition de ressource contient les définitions d'une VM.

La définition de la ressource sap_nw_node_2 a été créée en copiant et en collant la première définition, puis en modifiant les valeurs des propriétés name, instanceName et zone. Les valeurs de toutes les autres propriétés dans les deux définitions de ressources sont identiques.

Les propriétés networkTag et serviceAccount proviennent de la section "Options avancées" du modèle de fichier de configuration.

resources:
- name: sap_nw_node_1
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py
  properties:
    instanceName: nw-ha-vm-1
    instanceType: n2-standard-4
    zone: us-central1-b
    subnetwork: example-sub-network-sap
    linuxImage: family/rhel-8-4-sap-ha
    linuxImageProject: rhel-sap-cloud
    usrsapSize: 15
    sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: [e-mail]
- name: sap_nw_node_2
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py
  properties:
    instanceName: nw-ha-vm-2
    instanceType: n2-standard-4
    zone: us-central1-c
    subnetwork: example-sub-network-sap
    linuxImage: family/rhel-8-4-sap-ha
    linuxImageProject: rhel-sap-cloud
    usrsapSize: 15
    sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: [e-mail]

Créer des règles de pare-feu autorisant l'accès aux VM hôtes

Si vous ne l'avez pas déjà fait, créez des règles de pare-feu autorisant l'accès à chaque VM hôte à partir des sources suivantes :

• À des fins de configuration, votre poste de travail local, un hôte bastion ou un serveur de saut
• Pour l'accès entre les nœuds du cluster, les autres VM hôtes dans le cluster à haute disponibilité
• Vérifications d'état utilisées par Cloud Load Balancing, comme décrit dans l'étape ultérieure Créer une règle de pare-feu pour les vérifications d'état.

Lorsque vous créez des règles de pare-feu VPC, vous spécifiez les tags réseau que vous avez définis dans le fichier de configuration template.yaml pour désigner vos VM hôtes comme cibles de la règle.

Pour vérifier le déploiement, définissez une règle autorisant les connexions SSH sur le port 22 à partir d'un hôte bastion ou de votre poste de travail local.

Pour l'accès entre les nœuds du cluster, ajoutez une règle de pare-feu qui autorise tous les types de connexion sur n'importe quel port d'autres VM du même sous-réseau.

Assurez-vous que les règles de pare-feu pour la vérification du déploiement et la communication au sein du cluster sont créées avant de passer à la section suivante. Pour obtenir des instructions, consultez la section Ajouter des règles de pare-feu.

Vérifier le déploiement des VM

Avant d'installer SAP NetWeaver ou de commencer à configurer le cluster à haute disponibilité, vérifiez que les VM ont été déployées correctement en vérifiant les journaux et le mappage de stockage du système d'exploitation.

Vérifier les journaux

1. Dans la console Google Cloud, ouvrez Cloud Logging pour surveiller la progression de l'installation et rechercher les erreurs.

   Remarque : L'exécution de cette étape dans Cloud Logging peut engendrer des coûts. Pour en savoir plus, consultez la section sur les tarifs de Cloud Logging.

   Accéder à CloudLogging

2. Filtrez les journaux :

   Logs Explorer

   1. Sur la page Explorateur de journaux, accédez au volet Requête.

   2. Dans le menu déroulant Ressource, sélectionnez Global, puis cliquez sur Ajouter.

      Si l'option Global n'apparaît pas, saisissez la requête suivante dans l'éditeur de requête :

      resource.type="global"
      "Deployment"
      

   3. Cliquez sur Exécuter la requête.

   Ancienne visionneuse de journaux

   • Sur la page Ancienne visionneuse de journaux, dans le menu de sélection de base, sélectionnez Global comme ressource de journalisation.

3. Analysez les journaux filtrés :

   • Si "--- Finished" s'affiche, le traitement du déploiement est terminé, et vous pouvez passer à l'étape suivante.

   • Si vous rencontrez une erreur de quota :

     1. Sur la page Quotas de IAM & Admin, augmentez les quotas qui ne répondent pas aux exigences de SAP NetWeaver décrites dans le guide de planification SAP NetWeaver.

     2. Sur la page Déploiements de Deployment Manager, supprimez le déploiement pour nettoyer les VM et les disques persistants de l'installation ayant échoué.

     3. Réexécutez le déploiement.

Vérifier la configuration des VM

1. Une fois les instances de VM déployées, connectez-vous aux VM à l'aide de ssh.

   1. Si ce n'est pas déjà fait, créez une règle de pare-feu pour autoriser une connexion SSH sur le port 22.

   2. Accédez à la page Instances de VM.

      Accéder à la page "Instances de VM"

   3. Connectez-vous à chaque instance de VM en cliquant sur le bouton SSH figurant sur la ligne correspondant à chaque instance de VM, ou utilisez votre méthode SSH favorite.

      

2. Affichez le système de fichiers :

   ~> df -h

   Assurez-vous d'obtenir un résultat semblable à celui-ci :

   Filesystem                 Size  Used Avail Use% Mounted on
   devtmpfs                    32G  8.0K   32G   1% /dev
   tmpfs                       48G     0   48G   0% /dev/shm
   tmpfs                       32G  402M   32G   2% /run
   tmpfs                       32G     0   32G   0% /sys/fs/cgroup
   /dev/sda3                   30G  3.4G   27G  12% /
   /dev/sda2                   20M  3.7M   17M  19% /boot/efi
   /dev/mapper/vg_usrsap-vol   15G   48M   15G   1% /usr/sap
   /dev/mapper/vg_sapmnt-vol   15G   48M   15G   1% /sapmnt
   tmpfs                      6.3G     0  6.3G   0% /run/user/1002
   tmpfs                      6.3G     0  6.3G   0% /run/user/0

3. Vérifiez que l'espace d'échange a bien été créé :

   ~> cat /proc/meminfo | grep Swap

   Un résultat semblable à l'exemple suivant doit s'afficher :

   SwapCached:            0 kB
   SwapTotal:      25161724 kB
   SwapFree:       25161724 kB

Si l'une des étapes de validation indique que l'installation a échoué, procédez comme suit :

1. Corrigez l'erreur.
2. Sur la page Déploiements, supprimez le déploiement pour nettoyer les VM et les disques persistants de l'installation défaillante.
3. Réexécutez le déploiement.

Activer la communication backend de l'équilibreur de charge entre les VM

Une fois que vous avez confirmé que les VM ont bien été déployées, activez la communication backend entre les VM qui serviront de nœuds dans votre cluster à haute disponibilité.

Vous activez la communication backend entre les VM en modifiant la configuration de google-guest-agent, qui est incluse dans l'environnement invité Linux pour toutes les images publiques Linux fournies par Google Cloud.

Pour activer les communications backend de l'équilibreur de charge, procédez comme suit sur chaque VM de votre cluster :

1. Arrêtez l'agent :

   sudo service google-guest-agent stop

2. Ouvrez ou créez le fichier /etc/default/instance_configs.cfg pour le modifier. Exemple :

   sudo vi /etc/default/instance_configs.cfg

3. Dans le fichier /etc/default/instance_configs.cfg, spécifiez les propriétés de configuration suivantes comme indiqué. Si les sections n'existent pas, créez-les. Assurez-vous tout particulièrement que les propriétés target_instance_ips et ip_forwarding sont définies sur false :

   [IpForwarding]
   ethernet_proto_id = 66
   ip_aliases = true
   target_instance_ips = false
   
   [NetworkInterfaces]
   dhclient_script = /sbin/google-dhclient-script
   dhcp_command =
   ip_forwarding = false
   setup = true
   

4. Démarrez le service de l'agent invité :

   sudo service google-guest-agent start

Pour configurer la vérification d'état de l'équilibreur de charge, vous devez disposer d'un port cible d'écoute et attribuer l'adresse IP virtuelle à une interface. Pour en savoir plus, consultez la section Tester la configuration de l'équilibreur de charge.

Configurer les clés SSH sur les VM principale et secondaire

Pour permettre la copie de fichiers entre les hôtes du cluster à haute disponibilité, les étapes de cette section créent des connexions SSH racine entre les deux hôtes.

Les modèles Deployment Manager fournis par Google Cloud génèrent une clé pour vous, mais vous pouvez la remplacer par une clé que vous générez si nécessaire.

Votre organisation dispose probablement de consignes régissant les communications réseau internes. Si nécessaire, une fois le déploiement terminé, vous pouvez supprimer les métadonnées des VM et les clés du répertoire authorized_keys.

Si la configuration de connexions SSH directes ne respecte pas les consignes de votre organisation, vous pouvez transférer des fichiers à l'aide d'autres méthodes, par exemple :

• Transférez des fichiers plus petits via votre poste de travail local à l'aide des options de menu Importer un fichier et Télécharger un fichier de Cloud Shell. Consultez la page Gérer des fichiers avec Cloud Shell.
• Échangez des fichiers à l'aide d'un bucket Cloud Storage. Consultez la section Importations et téléchargements.
• Utilisez une solution de stockage de fichiers telle que Filestore ou NetApp Cloud Volumes Service pour créer un dossier partagé. Consultez la page Solutions de partage de fichiers.

Pour activer les connexions SSH entre les instances principale et secondaire, procédez comme indiqué ci-dessous. Les étapes supposent que vous utilisez la clé SSH générée par les modèles Deployment Manager pour SAP.

1. Sur la VM hôte principale :

   1. Connectez-vous à la VM via SSH

   2. Passez en mode root :

      $ sudo su -

   3. Vérifiez que la clé SSH existe :

      # ls -l /root/.ssh/

      Vous devez voir les fichiers de clé id_rsa comme dans l'exemple suivant :

      -rw-r--r-- 1 root root  569 May  4 23:07 authorized_keys
      -rw------- 1 root root 2459 May  4 23:07 id_rsa
      -rw-r--r-- 1 root root  569 May  4 23:07 id_rsa.pub

   4. Mettez à jour les métadonnées de la VM principale avec les informations sur la clé SSH de la VM secondaire.

      # gcloud compute instances add-metadata SECONDARY_VM_NAME \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
      --zone SECONDARY_VM_ZONE

   5. Afin de vérifier que les clés SSH sont configurées correctement, ouvrez une connexion SSH depuis le système secondaire vers le système principal.

      # ssh SECONDARY_VM_NAME

2. Sur la VM hôte secondaire :

   1. Connectez-vous en SSH à la VM.

   2. Passez en mode root :

      $ sudo su -

   3. Vérifiez que la clé SSH existe :

      # ls -l /root/.ssh/

      Vous devez voir les fichiers de clé id_rsa comme dans l'exemple suivant :

      -rw-r--r-- 1 root root  569 May  4 23:07 authorized_keys
      -rw------- 1 root root 2459 May  4 23:07 id_rsa
      -rw-r--r-- 1 root root  569 May  4 23:07 id_rsa.pub

   4. Mettez à jour les métadonnées de la VM secondaire avec les informations sur la clé SSH de la VM principale.

      # gcloud compute instances add-metadata PRIMARY_VM_NAME \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
      --zone PRIMARY_VM_ZONE

      # cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

   5. Afin de vérifier que les clés SSH sont configurées correctement, ouvrez une connexion SSH du système secondaire au système principal.

      # ssh PRIMARY_VM_NAME

Configurer le stockage de fichiers partagés et les répertoires partagés

Vous devez configurer une solution de partage de fichiers NFS fournissant un stockage de fichiers partagé à haute disponibilité auquel les deux nœuds de votre cluster HA peuvent accéder. Vous créez ensuite des répertoires sur les deux nœuds qui correspondent au stockage de fichiers partagé. Le logiciel de cluster garantit que les répertoires appropriés sont installés uniquement sur les instances correctes.

La configuration d'une solution de partage de fichiers n'est pas abordée dans ce guide. Pour obtenir des instructions sur la configuration du système de partage de fichiers, consultez les instructions fournies par le fournisseur de la solution de votre choix. Si vous choisissez d'utiliser Filestore pour votre solution de partage de fichiers, nous vous recommandons d'utiliser le niveau Enterprise de Filestore. Pour savoir comment créer une instance Filestore, consultez la section Créer des instances.

Pour en savoir plus sur les solutions de partage de fichiers disponibles sur Google Cloud, consultez la section Options de stockage partagé pour les systèmes SAP à haute disponibilité sur Google Cloud.

Pour configurer les répertoires partagés, procédez comme suit :

1. Si vous n'avez pas encore configuré de solution de stockage de fichiers NFS partagés à haute disponibilité, faites-le maintenant.

2. Installez le stockage partagé NFS sur les deux serveurs pour la configuration initiale.

   ~> sudo mkdir /mnt/nfs
   ~> sudo mount -t nfs NFS_PATH /mnt/nfs

   Remplacez NFS_PATH par le chemin d'accès à votre solution de partage de fichiers NFS. Par exemple, 10.49.153.26:/nfs_share_nw_ha.

3. Depuis l'un ou l'autre serveur, créez des répertoires pour sapmnt, le répertoire de transport central et le répertoire spécifique à l'instance. Si vous utilisez une pile Java, remplacez "ASCS" par "SCS" avant d'utiliser les commandes suivantes et d'autres exemples de commandes :

   ~> sudo mkdir /mnt/nfs/sapmntSID
   ~> sudo mkdir /mnt/nfs/usrsap{trans,SIDASCSASCS_INSTANCE_NUMBER,SIDERSERS_INSTANCE_NUMBER}

   Remplacez les éléments suivants :

   • SID : ID du système SAP (SID). Utilisez des majuscules pour toutes les lettres. Par exemple, AHA.
   • ASCS_INSTANCE_NUMBER : numéro d'instance du système ASCS. Exemple :00
   • ERS_INSTANCE_NUMBER : numéro d'instance du système ERS. Exemple :10

4. Sur les deux serveurs, créez les points d'installation nécessaires :

   ~> sudo mkdir -p /sapmnt/SID
   ~> sudo mkdir -p /usr/sap/trans
   ~> sudo mkdir -p /usr/sap/SID/ASCSASCS_INSTANCE_NUMBER
   ~> sudo mkdir -p /usr/sap/SID/ERSERS_INSTANCE_NUMBER

5. Configurez autofs pour installer les répertoires de fichiers partagés communs lors du premier accès aux répertoires de fichiers. L'installation des répertoires ASCSASCS_INSTANCE_NUMBER et ERSERS_INSTANCE_NUMBER est gérée par le logiciel du cluster que vous configurerez ultérieurement.

   Ajustez les options NFS dans les commandes en fonction des besoins liés à votre solution de partage de fichiers.

   Sur les deux serveurs, configurez autofs :

   ~> echo "/- /etc/auto.sap" | sudo tee -a /etc/auto.master
   ~> NFS_OPTS="-rw,relatime,vers=3,hard,proto=tcp,timeo=600,retrans=2,mountvers=3,mountport=2050,mountproto=tcp"
   ~> echo "/sapmnt/SID ${NFS_OPTS} NFS_PATH/sapmntSID" | sudo tee -a /etc/auto.sap
   ~> echo "/usr/sap/trans ${NFS_OPTS} NFS_PATH/usrsaptrans" | sudo tee -a /etc/auto.sap

   Pour en savoir plus sur autofs, consultez autofs : fonctionnement.

6. Sur les deux serveurs, démarrez le service autofs :

   ~> sudo systemctl enable autofs
   ~> sudo systemctl restart autofs
   ~> sudo automount -v

7. Déclenchez autofs afin d'installer les répertoires partagés en accédant à chaque répertoire à l'aide de la commande cd. Exemple :

   ~> cd /sapmnt/SID
   ~> cd /usr/sap/trans
   

8. Une fois que vous avez accédé à tous les répertoires, exécutez la commande df -Th pour vérifier que les répertoires sont installés.

   ~> df -Th | grep FILE_SHARE_NAME

   Remplacez FILE_SHARE_NAME par le nom de votre solution de partage de fichiers NFS. Exemple :nfs_share_nw_ha

   Vous devriez voir des points d'installation et des répertoires semblables à ce qui suit :

   10.49.153.26:/nfs_share_nw_ha              nfs      1007G   76M  956G   1% /mnt/nfs
   10.49.153.26:/nfs_share_nw_ha/usrsaptrans  nfs      1007G   76M  956G   1% /usr/sap/trans
   10.49.153.26:/nfs_share_nw_ha/sapmntAHA    nfs      1007G   76M  956G   1% /sapmnt/AHA

Configurer la prise en charge du basculement Cloud Load Balancing

Le service de l'équilibreur de charge réseau interne à stratégie directe compatible avec le basculement achemine le trafic ASCS et ERS vers les instances actives respectives dans un cluster SAP NetWeaver. Les équilibreurs de charge réseau internes à stratégie directe utilisent des adresses IP virtuelles, des services de backend, des groupes d'instances et des vérifications d'état pour acheminer le trafic de manière appropriée.

Réserver des adresses IP pour les adresses IP virtuelles

Pour un cluster SAP NetWeaver à haute disponibilité, vous créez deux adresses IP virtuelles, parfois appelées adresses IP flottantes. Une adresse IP virtuelle suit l'instance active des services centraux SAP (SCS) et l'autre suit l'instance du serveur de réplication de mise en file d'attente (Enqueue Replication Server, ERS). L'équilibreur de charge achemine le trafic envoyé à chaque adresse IP virtuelle vers la VM qui héberge actuellement l'instance active du composant ASCS ou ERS de cette adresse IP virtuelle.

1. Ouvrez Cloud Shell.

   Accéder à Cloud Shell

2. Réservez une adresse IP pour l'adresse IP virtuelle du composant ASCS et pour l'adresse IP virtuelle du composant ERS. Pour ASCS, l'adresse IP est celle utilisée par les applications pour accéder à SAP NetWeaver. Pour ERS, l'adresse IP est celle utilisée pour la réplication du serveur de mise en file d'attente. Si vous omettez l'option --addresses, une adresse IP du sous-réseau spécifié est choisie pour vous :

   ~ gcloud compute addresses create ASCS_VIP_NAME \
     --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
     --addresses ASCS_VIP_ADDRESS
   
   ~ gcloud compute addresses create ERS_VIP_NAME \
     --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
     --addresses ERS_VIP_ADDRESS

   Remplacez les éléments suivants :

   • ASCS_VIP_NAME : spécifiez un nom pour l'adresse IP virtuelle de l'instance ASCS. Par exemple, ascs-aha-vip.
   • CLUSTER_REGION : spécifiez la région Google Cloud dans laquelle se trouve votre cluster. Par exemple, us-central1.
   • CLUSTER_SUBNET : spécifiez le sous-réseau que vous utilisez avec le cluster. Par exemple, example-sub-network-sap.
   • ASCS_VIP_ADDRESS : vous pouvez éventuellement spécifier une adresse IP pour l'adresse IP virtuelle ASCS au format CIDR. Par exemple, 10.1.0.2.
   • ERS_VIP_NAME : nom de l'adresse IP virtuelle de l'instance ERS. Par exemple, ers-aha-vip.
   • ERS_VIP_ADDRESS : vous pouvez éventuellement spécifier une adresse IP pour l'adresse IP virtuelle ERS au format CIDR. Par exemple, 10.1.0.4.

   Pour en savoir plus sur la réservation d'une adresse IP statique, consultez la page Réserver une adresse IP interne statique.

3. Confirmez la réservation d'adresse IP :

   ~ gcloud compute addresses describe VIP_NAME \
     --region CLUSTER_REGION

   Un résultat semblable aux lignes suivantes doit s'afficher :

   address: 10.1.0.2
   addressType: INTERNAL
   creationTimestamp: '2022-04-04T15:04:25.872-07:00'
   description: ''
   id: '555067171183973766'
   kind: compute#address
   name: ascs-aha-vip
   networkTier: PREMIUM
   purpose: GCE_ENDPOINT
   region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1
   selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/addresses/ascs-aha-vip
   status: RESERVED
   subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-sub-network-sap

Définir les noms d'hôte pour l'adresse IP virtuelle dans /etc/hosts

Définissez un nom d'hôte pour chaque adresse IP virtuelle, puis ajoutez les adresses IP et les noms d'hôte des VM et des adresses IP virtuelles au fichier /etc/hosts sur chaque VM.

Les noms d'hôte VIP ne sont pas connus en dehors des VM, sauf si vous les ajoutez également à votre service DNS. L'ajout de ces entrées au fichier /etc/hosts local protège votre cluster contre toute interruption de votre service DNS.

Vos mises à jour du fichier /etc/hosts doivent ressembler à l'exemple suivant :

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.1.0.113 nw-ha-vm-2.us-central1-c.c.example-project-123456.internal nw-ha-vm-2
10.1.0.2   ascs-aha-vip
10.1.0.4   ers-aha-vip
10.1.0.114 nw-ha-vm-1.us-central1-b.c.example-project-123456.internal nw-ha-vm-1  # Added by Google
169.254.169.254 metadata.google.internal  # Added by Google

Créer les vérifications d'état de Cloud Load Balancing

Créez des vérifications d'état : une pour l'instance ASCS active et une pour l'instance ERS active.

1. Dans Cloud Shell, créez les vérifications d'état. Pour éviter tout conflit avec d'autres services, indiquez les numéros de port des instances ASCS et ERS dans la plage privée (49152-65535). Les valeurs de l'intervalle entre deux vérifications et du délai avant expiration dans les commandes suivantes sont légèrement supérieures aux valeurs par défaut afin d'augmenter la tolérance au basculement lors des événements de migration à chaud de Compute Engine. Vous pouvez ajuster les valeurs, si nécessaire :

   1. ~ gcloud compute health-checks create tcp ASCS_HEALTH_CHECK_NAME \
      --port=ASCS_HEALTHCHECK_PORT_NUM --proxy-header=NONE --check-interval=10 --timeout=10 \
      --unhealthy-threshold=2 --healthy-threshold=2

   2. ~ gcloud compute health-checks create tcp ERS_HEALTH_CHECK_NAME \
      --port=ERS_HEALTHCHECK_PORT_NUM --proxy-header=NONE --check-interval=10 --timeout=10 \
      --unhealthy-threshold=2 --healthy-threshold=2

2. Confirmez la création de chaque vérification d'état :

   ~ gcloud compute health-checks describe HEALTH_CHECK_NAME

   Un résultat semblable aux lignes suivantes doit s'afficher :

   checkIntervalSec: 10
   creationTimestamp: '2021-05-12T15:12:21.892-07:00'
   healthyThreshold: 2
   id: '1981070199800065066'
   kind: compute#healthCheck
   name: ascs-aha-health-check-name
   selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/scs-aha-health-check-name
   tcpHealthCheck:
     port: 60000
     portSpecification: USE_FIXED_PORT
     proxyHeader: NONE
   timeoutSec: 10
   type: TCP
   unhealthyThreshold: 2

Créer une règle de pare-feu pour les vérifications d'état

Si ce n'est pas déjà fait, définissez une règle de pare-feu pour un port situé dans la plage privée qui permet d'accéder à vos VM hôtes à partir des plages d'adresses IP utilisées par les vérifications d'état de Cloud Load Balancing, 35.191.0.0/16 et 130.211.0.0/22. Pour en savoir plus sur les règles de pare-feu pour les équilibreurs de charge, consultez la section Créer des règles de pare-feu pour les vérifications d'état.

1. Si ce n'est pas déjà fait, ajoutez un tag réseau à vos VM hôtes. Ce tag réseau est utilisé par la règle de pare-feu pour les vérifications d'état.

   • ~ gcloud compute instances add-tags  PRIMARY_VM_NAME \
     --zone=PRIMARY_ZONE \
     --tags NETWORK_TAGS

   • ~ gcloud compute instances add-tags  SECONDARY_VM_NAME \
     --zone=SECONDARY_ZONE \
     --tags NETWORK_TAGS

2. Créez une règle de pare-feu qui utilise le tag réseau pour autoriser les vérifications d'état :

   ~ gcloud compute firewall-rules create  RULE_NAME \
     --network=NETWORK_NAME \
     --action=ALLOW \
     --direction=INGRESS \
     --source-ranges=35.191.0.0/16,130.211.0.0/22 \
     --target-tags=NETWORK_TAGS \
     --rules=tcp:ASCS_HEALTHCHECK_PORT_NUM,tcp:ERS_HEALTHCHECK_PORT_NUM

   Exemple :

   gcloud compute firewall-rules create  nw-ha-cluster-health-checks \
   --network=example-network \
   --action=ALLOW \
   --direction=INGRESS \
   --source-ranges=35.191.0.0/16,130.211.0.0/22 \
   --target-tags=allow-health-check \
   --rules=tcp:60000,tcp:60010

Créer des groupes d'instances Compute Engine

Vous devez créer un groupe d'instances dans chaque zone qui contient une VM de nœud de cluster, puis ajouter la VM de cette zone au groupe d'instances.

1. Dans Cloud Shell, créez le groupe d'instances principal et ajoutez-y la VM principale :

   1. ~ gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \
      --zone=PRIMARY_ZONE

   2. ~ gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \
      --zone=PRIMARY_ZONE \
      --instances=PRIMARY_VM_NAME

2. Dans Cloud Shell, créez le groupe d'instances secondaire et ajoutez-y la VM secondaire :

   1. ~ gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \
      --zone=SECONDARY_ZONE

   2. ~ gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \
      --zone=SECONDARY_ZONE \
      --instances=SECONDARY_VM_NAME

3. Confirmez la création des groupes d'instances :

   ~ gcloud compute instance-groups unmanaged list

   Un résultat semblable aux lignes suivantes doit s'afficher :

   NAME                              ZONE           NETWORK              NETWORK_PROJECT        MANAGED  INSTANCES
   sap-aha-primary-instance-group    us-central1-b  example-network-sap  example-project-123456  No       1
   sap-aha-secondary-instance-group  us-central1-c  example-network-sap  example-project-123456  No       1
   

Configurer les services de backend

Créez deux services de backend, un pour ASCS et l'autre pour ERS. Ajoutez les deux groupes d'instances à chaque service de backend, en spécifiant l'autre groupe d'instances comme groupe d'instances de basculement dans chaque service de backend. Enfin, créez des règles de transfert entre les adresses IP virtuelles et les services de backend.

1. Dans Cloud Shell, créez le service de backend et le groupe de basculement pour ASCS :

   1. Créez le service de backend pour ASCS :

      ~ gcloud compute backend-services create ASCS_BACKEND_SERVICE_NAME \
         --load-balancing-scheme internal \
         --health-checks ASCS_HEALTH_CHECK_NAME \
         --no-connection-drain-on-failover \
         --drop-traffic-if-unhealthy \
         --failover-ratio 1.0 \
         --region CLUSTER_REGION \
         --global-health-checks

   2. Ajoutez le groupe d'instances principal au service de backend ASCS :

      ~ gcloud compute backend-services add-backend ASCS_BACKEND_SERVICE_NAME \
        --instance-group PRIMARY_IG_NAME \
        --instance-group-zone PRIMARY_ZONE \
        --region CLUSTER_REGION

   3. Ajoutez le groupe d'instances secondaire en tant que groupe d'instances de basculement pour le service de backend ASCS :

      ~ gcloud compute backend-services add-backend ASCS_BACKEND_SERVICE_NAME \
        --instance-group SECONDARY_IG_NAME \
        --instance-group-zone SECONDARY_ZONE \
        --failover \
        --region CLUSTER_REGION

2. Dans Cloud Shell, créez le service de backend et le groupe de basculement pour ERS :

   1. Créez le service de backend pour le service ERS :

      ~ gcloud compute backend-services create ERS_BACKEND_SERVICE_NAME \
      --load-balancing-scheme internal \
      --health-checks ERS_HEALTH_CHECK_NAME \
      --no-connection-drain-on-failover \
      --drop-traffic-if-unhealthy \
      --failover-ratio 1.0 \
      --region CLUSTER_REGION \
      --global-health-checks

   2. Ajoutez le groupe d'instances secondaire au service de backend ERS :

      ~ gcloud compute backend-services add-backend ERS_BACKEND_SERVICE_NAME \
        --instance-group SECONDARY_IG_NAME \
        --instance-group-zone SECONDARY_ZONE \
        --region CLUSTER_REGION

   3. Ajoutez le groupe d'instances principal en tant que groupe d'instances de basculement pour le service de backend ERS :

      ~ gcloud compute backend-services add-backend ERS_BACKEND_SERVICE_NAME \
        --instance-group PRIMARY_IG_NAME \
        --instance-group-zone PRIMARY_ZONE \
        --failover \
        --region CLUSTER_REGION

3. Si vous le souhaitez, vérifiez que les services de backend contiennent les groupes d'instances comme prévu :

   ~ gcloud compute backend-services describe BACKEND_SERVICE_NAME \
    --region=CLUSTER_REGION

   Un résultat semblable à l'exemple suivant doit s'afficher pour le service de backend ASCS. Pour ERS, failover: true s'affiche sur le groupe d'instances principal :

   backends:
   - balancingMode: CONNECTION
     group: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group
   - balancingMode: CONNECTION
     failover: true
     group: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
   connectionDraining:
     drainingTimeoutSec: 0
   creationTimestamp: '2022-04-06T10:58:37.744-07:00'
   description: ''
   failoverPolicy:
     disableConnectionDrainOnFailover: true
     dropTrafficIfUnhealthy: true
     failoverRatio: 1.0
   fingerprint: s4qMEAyhrV0=
   healthChecks:
   - https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/ascs-aha-health-check-name
   id: '6695034709671438882'
   kind: compute#backendService
   loadBalancingScheme: INTERNAL
   name: ascs-aha-backend-service-name
   protocol: TCP
   region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1
   selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/backendServices/ascs-aha-backend-service-name
   sessionAffinity: NONE
   timeoutSec: 30

4. Dans Cloud Shell, créez des règles de transfert pour les services de backend ASCS et ERS :

   1. Créez la règle de transfert de l'adresse IP virtuelle ASCS vers le service de backend ASCS :

      ~ gcloud compute forwarding-rules create ASCS_FORWARDING_RULE_NAME \
      --load-balancing-scheme internal \
      --address ASCS_VIP_ADDRESS \
      --subnet CLUSTER_SUBNET \
      --region CLUSTER_REGION \
      --backend-service ASCS_BACKEND_SERVICE_NAME \
      --ports ALL

   2. Créez la règle de transfert depuis l'adresse IP virtuelle ERS vers le service de backend ERS :

      ~ gcloud compute forwarding-rules create ERS_FORWARDING_RULE_NAME \
      --load-balancing-scheme internal \
      --address ERS_VIP_ADDRESS \
      --subnet CLUSTER_SUBNET \
      --region CLUSTER_REGION \
      --backend-service ERS_BACKEND_SERVICE_NAME \
      --ports ALL

Remarque : Vos groupes d'instances backend ne seront pas considérés comme opérationnels tant que vous n'aurez pas terminé la configuration du cluster Pacemaker.

Tester la configuration de l'équilibreur de charge

Même si vos groupes d'instances backend ne seront considérés comme opérationnels que plus tard, vous pouvez tester la configuration de l'équilibreur de charge en configurant un écouteur pour répondre aux vérifications d'état. Une fois un écouteur configuré, si l'équilibreur de charge est correctement configuré, les groupes d'instances backend deviennent opérationnels.

Les sections suivantes présentent différentes méthodes que vous pouvez utiliser pour tester la configuration.

Tester l'équilibreur de charge avec l'utilitaire socat

Vous pouvez utiliser l'utilitaire socat pour écouter temporairement un port de vérification de l'état.

1. Sur les deux VM hôtes, installez l'utilitaire socat :

   $ sudo yum install socat

2. Sur la VM principale, attribuez temporairement l'adresse IP virtuelle à la carte réseau eth0 :

   ip addr add VIP_ADDRESS dev eth0

3. Sur la VM principale, démarrez un processus socat pour écouter le port de vérification d'état ASCS pendant 60 secondes :

   $ timeout 60s socat - TCP-LISTEN:ASCS_HEALTHCHECK_PORT_NUM,fork

4. Dans Cloud Shell, après avoir attendu quelques secondes pour que la vérification de l'état détecte l'écouteur, vérifiez l'état de votre groupe d'instances backend ASCS :

   ~ gcloud compute backend-services get-health ASCS_BACKEND_SERVICE_NAME \
     --region CLUSTER_REGION

   Un résultat semblable à l'exemple suivant doit s'afficher pour ASCS :

   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group
   status:
     healthStatus:
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
       forwardingRuleIp: 10.1.0.90
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instances/nw-ha-vm-1
       ipAddress: 10.1.0.89
       port: 80
     kind: compute#backendServiceGroupHealth
   ---
   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
   status:
     healthStatus:
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
       forwardingRuleIp: 10.1.0.90
       healthState: UNHEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/nw-ha-vm-2
       ipAddress: 10.1.0.88
       port: 80
     kind: compute#backendServiceGroupHealth

5. Supprimez l'adresse IP virtuelle de l'interface eth0 :

   ip addr del VIP_ADDRESS dev eth0

6. Répétez les étapes pour ERS, en remplaçant les valeurs des variables ASCS par celles d'ERS.

Tester l'équilibreur de charge à l'aide du port 22

Si le port 22 est ouvert pour les connexions SSH sur vos VM hôtes, vous pouvez modifier temporairement le vérificateur de l'état afin d'utiliser ce port 22, qui dispose d'un écouteur capable de lui répondre.

Pour utiliser temporairement le port 22, procédez comme suit :

1. Dans la console Google Cloud, accédez à la page Vérifications d'état de Compute Engine :

   Accéder à la page "Vérifications d'état"

2. Cliquez sur le nom de votre vérification d'état.

3. Cliquez sur Modifier.

4. Dans le champ Port, remplacez le numéro de port par 22.

5. Cliquez sur Enregistrer, puis patientez une minute ou deux.

6. Dans Cloud Shell, après avoir attendu quelques secondes pour que la vérification de l'état détecte l'écouteur, vérifiez l'état de vos groupes d'instances backend :

   ~ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
     --region CLUSTER_REGION

   La sortie obtenue doit ressembler à ceci :

   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group
   status:
     healthStatus:
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
       forwardingRuleIp: 10.1.0.85
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instances/nw-ha-vm-1
       ipAddress: 10.1.0.79
       port: 80
     kind: compute#backendServiceGroupHealth
   ---
   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
   status:
     healthStatus:
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
       forwardingRuleIp: 10.1.0.85
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/nw-ha-vm-2
       ipAddress: 10.1.0.78
       port: 80
     kind: compute#backendServiceGroupHealth

7. Lorsque vous avez terminé, rétablissez le numéro de port d'origine de la vérification de l'état.

Installer des écouteurs pour les vérifications d'état

Pour configurer une ressource de vérification de l'état, vous devez d'abord installer les écouteurs.

L'équilibreur de charge utilise un écouteur sur le port de vérification de l'état de chaque hôte afin de déterminer où l'instance principale du cluster SAP HANA est exécutée.

Sur chaque hôte du cluster, installez un écouteur en procédant comme suit :

1. En tant qu'utilisateur racine, installez un écouteur TCP simple. Ces instructions permettent d'installer et d'utiliser HAProxy comme écouteur.

   # yum install haproxy

2. Copiez et renommez le fichier de configuration haproxy.cfg par défaut afin de le transformer en fichier de modèle pour plusieurs instances haproxy :

   # cp /usr/lib/systemd/system/haproxy.service \
       /etc/systemd/system/haproxy@.service
   

3. Modifiez les sections [Unit] et [Service] du fichier haproxy@.service pour inclure le paramètre d'instance %i, comme indiqué dans l'exemple suivant :

   [Unit]
   Description=HAProxy Load Balancer %i
   After=network-online.target
   Wants=network-online.target
   
   [Service]
   Environment="CONFIG=/etc/haproxy/haproxy-%i.cfg" "PIDFILE=/run/haproxy-%i.pid"
   ...
   

   Pour plus d'informations Red Hat sur les modèles d'unités systemd, consultez la section Utiliser des unités instanciées.

4. Créez un fichier de configuration haproxy.cfg pour l'instance ASCS. Exemple :

   # vi /etc/haproxy/haproxy-SIDscs.cfg

   Remplacez SID par l'ID du système SAP (SID). Utilisez des majuscules pour toutes les lettres. Exemple :AHA

5. Dans le fichier de configuration ASCS haproxy-SIDscs.cfg, ajoutez la configuration suivante et remplacez ASCS_HEALTHCHECK_PORT_NUM par le numéro de port que vous avez spécifié lors de la création de la vérification d'état Compute Engine pour ASCS :

   global
       chroot      /var/lib/haproxy
       pidfile     /var/run/haproxy-%i.pid
       user        haproxy
       group       haproxy
       daemon
   defaults
       mode                    tcp
       log                     global
       option                  dontlognull
       option                  redispatch
       retries                 3
       timeout queue           1m
       timeout connect         10s
       timeout client          1m
       timeout server          1m
       timeout check           10s
       maxconn                 3000
   
   # Listener for SAP healthcheck
   listen healthcheck
      bind *:ASCS_HEALTHCHECK_PORT_NUM

6. Créez un fichier de configuration haproxy.cfg pour l'instance ERS. Exemple :

   # vi /etc/haproxy/haproxy-SIDers.cfg

7. Dans le fichier de configuration ERS haproxy-SIDers.cfg, ajoutez la configuration suivante et remplacez ERS_HEALTHCHECK_PORT_NUM par le numéro de port que vous avez spécifié lors de la création de la vérification d'état Compute Engine pour ERS :

   global
       chroot      /var/lib/haproxy
       pidfile     /var/run/haproxy-%i.pid
       user        haproxy
       group       haproxy
       daemon
   defaults
       mode                    tcp
       log                     global
       option                  dontlognull
       option                  redispatch
       retries                 3
       timeout queue           1m
       timeout connect         10s
       timeout client          1m
       timeout server          1m
       timeout check           10s
       maxconn                 3000
   
   # Listener for SAP healthcheck
   listen healthcheck
      bind *:ERS_HEALTHCHECK_PORT_NUM

8. Rechargez les services systemd :

   # systemctl daemon-reload

9. Vérifiez que le service haproxy est correctement configuré :

    # systemctl start haproxy
    # systemctl status haproxy
    # systemctl | grep haproxy

   L'état du service haproxy.service renvoyé doit être défini sur active (running).

   ● haproxy.service - HAProxy Load Balancer
      Loaded: loaded (/usr/lib/systemd/system/haproxy.service; enabled; vendor preset: disabled)
      Active: active (running) since Sun 2022-04-10 16:48:10 UTC; 2 days ago
    Main PID: 1079 (haproxy)
       Tasks: 2 (limit: 100996)
      Memory: 5.1M
      CGroup: /system.slice/haproxy.service
              ├─1079 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
              └─1083 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
   
   Apr 10 16:48:10 dru-hanw-ascs systemd[1]: Starting HAProxy Load Balancer...
   Apr 10 16:48:10 dru-hanw-ascs systemd[1]: Started HAProxy Load Balancer.

10. Répétez les étapes précédentes sur chaque hôte du cluster.

Configurer Pacemaker

La procédure suivante configure la mise en œuvre RHEL d'un cluster Pacemaker sur des VM Compute Engine pour SAP NetWeaver.

Elle repose sur la documentation Red Hat pour la configuration des clusters à haute disponibilité, y compris les publications suivantes (un abonnement Red Hat est requis) :

• Configurer SAP NetWeaver ASCS/ERS ENSA1 avec des ressources autonomes dans RHEL 7.5+ et RHEL 8
• Configurer SAP S/4HANA ASCS/ERS avec le serveur autonome de mise en file d'attente 2 (ENSA2) dans Pacemaker

Pour plus d'informations SAP sur l'installation et la configuration de RHEL, consultez les ressources SAP suivantes :

• Note SAP 3108316 – Red Hat Enterprise Linux 9.x : installation et configuration
• Note SAP 2772999 – Red Hat Enterprise Linux 8.x : installation et configuration
• Note SAP 2002167 – Red Hat Enterprise Linux 7.x : installation et mise à niveau

Configurer les packages de cluster requis et le pare-feu de l'OS sur les deux hôtes

En tant qu'utilisateur racine, sur les hôtes principal et secondaire, installez et mettez à jour les packages de cluster requis, configurez hacluster, puis configurez le service de pare-feu de l'OS.

1. Installez les packages de cluster requis suivants :

   # yum install pcs pacemaker
   # yum install fence-agents-gce
   # yum install resource-agents-gcp
   # yum install resource-agents-sap
   # yum install sap-cluster-connector

2. Mettez à jour les packages installés :

   # yum update -y

3. Définissez le mot de passe de l'utilisateur hacluster, qui est installé dans les packages de cluster :

   # passwd hacluster

4. Lorsque vous y êtes invité, spécifiez un mot de passe pour hacluster.

5. Dans les images RHEL fournies par Google Cloud, le service de pare-feu du système d'exploitation est actif par défaut. Configurez le service de pare-feu pour autoriser le trafic à haute disponibilité :

   # firewall-cmd --permanent --add-service=high-availability

   # firewall-cmd --reload

6. Démarrez le service PCS et configurez-le pour qu'il se lance au démarrage :

   # systemctl start pcsd.service
   # systemctl enable pcsd.service

7. Vérifiez l'état du service PCS :

   # systemctl status pcsd.service

   La sortie obtenue doit ressembler à ceci :

   ● pcsd.service - PCS GUI and remote configuration interface
     Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled)
     Active: active (running) since Sat 2020-06-13 21:17:05 UTC; 25s ago
       Docs: man:pcsd(8)
             man:pcs(8)
   Main PID: 31627 (pcsd)
     CGroup: /system.slice/pcsd.service
             └─31627 /usr/bin/ruby /usr/lib/pcsd/pcsd
   Jun 13 21:17:03 hana-ha-vm-1 systemd[1]: Starting PCS GUI and remote configuration interface...
   Jun 13 21:17:05 hana-ha-vm-1 systemd[1]: Started PCS GUI and remote configuration interface.

Créer le cluster

1. En tant qu'utilisateur racine, sur l'un ou l'autre des nœuds, autorisez l'utilisateur hacluster. Cliquez sur l'onglet de votre version de RHEL pour afficher la commande suivante :

   RHEL 8 et versions ultérieures

   # pcs host auth PRIMARY_VM_NAME SECONDARY_VM_NAME

   RHEL 7

   # pcs cluster auth PRIMARY_VM_NAME SECONDARY_VM_NAME

2. Lorsque vous y êtes invité, saisissez le nom d'utilisateur hacluster et le mot de passe que vous avez défini pour l'utilisateur hacluster.

3. Créez le cluster :

   RHEL 8 et versions ultérieures

   # pcs cluster setup CLUSTER_NAME PRIMARY_VM_NAME SECONDARY_VM_NAME

   RHEL 7

   # pcs cluster setup --name CLUSTER_NAME PRIMARY_VM_NAME SECONDARY_VM_NAME

Mettre à jour les fichiers de configuration Corosync

La procédure suivante permet de définir les valeurs de cluster recommandées pour Corosync. Si le fichier de configuration Corosync /etc/corosync/corosync.conf n'existe pas encore ou est vide, vous pouvez utiliser l'exemple de fichier dans le répertoire /etc/corosync/ comme base pour votre configuration.

1. Ouvrez le fichier corosync.conf pour le modifier :

   # vi /etc/corosync/corosync.conf

2. Dans la section totem du fichier corosync.conf, définissez les paramètres de l'exemple suivant sur les valeurs affichées. Il est possible que certains paramètres soient déjà définis sur les valeurs appropriées :

   RHEL 8

   totem {
   ...
     transport: knet
     token: 20000
     token_retransmits_before_loss_const: 10
     join: 60
     max_messages: 20
   ...
   }

   RHEL 7

   totem {
   ...
     transport: udpu
     token: 20000
     token_retransmits_before_loss_const: 10
     join: 60
     max_messages: 20
   ...
   }

3. Synchronisez la configuration avec votre deuxième serveur :

   RHEL 8 et versions ultérieures

   # pcs cluster sync corosync

   RHEL 7

   # pcs cluster sync

4. Dans la VM principale, activez et démarrez le cluster.

   # pcs cluster enable --all
   # pcs cluster start --all

5. Vérifiez que les nouveaux paramètres Corosync sont actifs dans le cluster à l'aide de l'utilitaire corosync-cmapctl :

   # corosync-cmapctl

6. Vérifiez l'état du cluster :

   # pcs status

   Un résultat semblable aux lignes suivantes doit s'afficher :

   Cluster name: nwha
   
   WARNINGS:
   No stonith devices and stonith-enabled is not false
   
   Cluster Summary:
   * Stack: corosync
   * Current DC: nw-ha-vm-2 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum
   * 2 nodes configured
   * 0 resource instances configured
   
   Node List:
   * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
   Full List of Resources:
   * No resources
   
   Daemon Status:
   corosync: active/enabled
   pacemaker: active/enabled
   pcsd: active/enabled

Configurer les ressources du cluster pour l'infrastructure

Vous devez définir les ressources Pacemaker pour l'infrastructure de cluster suivante :

• Le dispositif de cloisonnement, qui empêche les scénarios de split-brain
• Les répertoires ASCS et ERS dans le système de fichiers partagé
• Les vérifications d'état
• Les adresses IP virtuelles
• Les composants ASCS et ERS

Vous définissez d'abord les ressources de l'appareil de cloisonnement, du système de fichiers partagé, des vérifications d'état et des adresses IP virtuelles. Vous installez ensuite SAP NetWeaver. Une fois SAP NetWeaver installé, vous définissez les ressources de cluster pour les composants ASCS et ERS.

Configurer le cloisonnement

Pour configurer le cloisonnement, vous devez définir une ressource de cluster avec l'agent fence_gce pour chaque VM hôte.

Pour garantir la séquence correcte d'événements après une action de cloisonnement, vous devez également configurer le système d'exploitation pour retarder le redémarrage de Corosync après la fermeture d'une VM. Vous pouvez également ajuster le délai avant expiration de Pacemaker pour les redémarrages afin de tenir compte de ce délai.

Créer les ressources de l'appareil de cloisonnement

Pour chaque VM du cluster, créez une ressource de cluster pour l'appareil de cloisonnement afin que le cluster puisse redémarrer la VM. L'appareil de cloisonnement d'une VM doit s'exécuter sur une autre VM. Vous devez donc configurer l'emplacement de la ressource de cluster pour qu'elle s'exécute sur n'importe quelle VM, à l'exception de la VM qu'elle peut redémarrer.

1. Sur l'hôte principal, en tant qu'utilisateur racine, créez une ressource de cluster pour un appareil de cloisonnement associé à la VM principale :

   # pcs stonith create FENCING_RESOURCE_PRIMARY_VM fence_gce \
       port="PRIMARY_VM_NAME" \
       zone="PRIMARY_ZONE" \
       project="CLUSTER_PROJECT_ID" \
       pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
       op monitor interval="300s" timeout="120s" \
       op start interval="0" timeout="60s"

2. Configurez l'emplacement de l'appareil de cloisonnement de la VM principale afin qu'il ne soit actif que sur la VM secondaire :

   # pcs constraint location FENCING_RESOURCE_PRIMARY_VM avoids PRIMARY_VM_NAME

3. Sur l'hôte principal, en tant qu'utilisateur racine, créez une ressource de cluster pour un appareil de cloisonnement associé à la VM secondaire :

   # pcs stonith create FENCING_RESOURCE_SECONDARY_VM fence_gce \
       port="SECONDARY_VM_NAME" \
       zone="SECONDARY_ZONE" \
       project="CLUSTER_PROJECT_ID" \
       pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
       op monitor interval="300s" timeout="120s" \
       op start interval="0" timeout="60s"

4. Configurez l'emplacement de l'appareil de cloisonnement de la VM secondaire afin qu'il ne soit actif que sur la VM principale :

   # pcs constraint location FENCING_RESOURCE_SECONDARY_VM avoids SECONDARY_VM_NAME

Définir un délai pour le redémarrage de Corosync

1. Sur les deux hôtes, en tant qu'utilisateur racine, créez un fichier de dépôt systemd qui retarde le démarrage de Corosync pour garantir le bon déroulement de la séquence d'événements après le redémarrage d'une VM cloisonnée :

   systemctl edit corosync.service

2. Ajoutez les lignes suivantes au fichier :

   [Service]
   ExecStartPre=/bin/sleep 60

3. Enregistrez le fichier et quittez l'éditeur.

4. Rechargez la configuration du gestionnaire systemd.

   systemctl daemon-reload

5. Vérifiez que le fichier de dépôt a été créé :

   service corosync status

   Une ligne correspondant au fichier de dépôt doit s'afficher, comme illustré dans l'exemple suivant :

   ● corosync.service - Corosync Cluster Engine
      Loaded: loaded (/usr/lib/systemd/system/corosync.service; disabled; vendor preset: disabled)
     Drop-In: /etc/systemd/system/corosync.service.d
              └─override.conf
      Active: active (running) since Tue 2021-07-20 23:45:52 UTC; 2 days ago

Créer les ressources du système de fichiers

Définissez les ressources de cluster pour les répertoires ASCS et ERS dans le système de fichiers partagé.

1. Configurez une ressource de système de fichiers pour le répertoire ASCS.

   # pcs resource create ASCS_FILE_SYSTEM_RESOURCE Filesystem \
       device="NFS_PATH/usrsapSIDASCSASCS_INSTANCE_NUMBER" \
       directory="/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER" \
       fstype=nfs force_unmount=safe \
       --group ASCS_RESOURCE_GROUP \
       op start interval=0 timeout=60 \
       op stop interval=0 timeout=120 \
       op monitor interval=200 timeout=40

   Remplacez les éléments suivants :

   • ASCS_FILE_SYSTEM_RESOURCE : spécifiez le nom de la ressource de cluster pour le système de fichiers ASCS.
   • NFS_PATH : spécifiez le chemin d'accès du répertoire au système de fichiers NFS.
   • SID : spécifiez l'ID système (SID). Utilisez des majuscules pour toutes les lettres.
   • ASCS_INSTANCE_NUMBER : spécifiez le numéro d'instance ASCS.
   • ASCS_RESOURCE_GROUP : spécifiez un nom de groupe unique pour les ressources de cluster ASCS. Vous pouvez garantir l'unicité en utilisant une convention telle que "SID_ASCSinstance_number_group". Par exemple, nw8_ASCS00_group.

     Comme aucun groupe n'existe encore, Pacemaker en crée un maintenant. Lorsque vous créez d'autres ressources ASCS, vous les ajoutez à ce groupe.

2. Configurez une ressource de système de fichiers pour le répertoire ERS.

   # pcs resource create ERS_FILE_SYSTEM_RESOURCE Filesystem \
       device="NFS_PATH/usrsapSIDERSERS_INSTANCE_NUMBER" \
       directory="/usr/sap/SID/ERSERS_INSTANCE_NUMBER" \
       fstype=nfs force_unmount=safe \
       --group ERS_RESOURCE_GROUP \
       op start interval=0 timeout=60 \
       op stop interval=0 timeout=120 \
       op monitor interval=200 timeout=40

   Remplacez les éléments suivants :

   • ERS_FILE_SYSTEM_RESOURCE : spécifiez le nom de la ressource du système de fichiers.
   • NFS_PATH : spécifiez le chemin d'accès du répertoire au système de fichiers NFS.
   • SID : spécifiez l'ID système (SID). Utilisez des majuscules pour toutes les lettres.
   • ERS_INSTANCE_NUMBER : spécifiez le numéro d'instance ERS.
   • ERS_RESOURCE_GROUP : spécifiez un nom de groupe unique pour les ressources de cluster ERS. Vous pouvez garantir l'unicité en utilisant une convention telle que "SID_ERSinstance_number_group". Par exemple, nw8_ERS10_group.

     Comme aucun groupe n'existe encore, Pacemaker en crée un maintenant. Lorsque vous créez d'autres ressources ERS, vous les ajoutez à ce groupe.

Créer une ressource d'adresse IP virtuelle

Définissez les ressources du cluster pour les adresses IP virtuelles.

1. Si vous avez besoin de rechercher l'adresse IP virtuelle, vous pouvez utiliser :

   • gcloud compute addresses describe ASCS_VIP_NAME
--region=CLUSTER_REGION --format="value(address)"
   • gcloud compute addresses describe ERS_VIP_NAME
--region=CLUSTER_REGION --format="value(address)"

2. Créez les ressources de cluster pour les adresses IP virtuelles ASCS et ERS.

   # pcs resource create ASCS_VIP_RESOURCE IPaddr2 \
       ip=ASCS_VIP_ADDRESS cidr_netmask=32 nic=eth0 \
       op monitor interval=3600 timeout=60 \
       --group ASCS_RESOURCE_GROUP

   # pcs resource create ERS_VIP_RESOURCE IPaddr2 \
       ip=ERS_VIP_ADDRESS cidr_netmask=32 nic=eth0 \
       op monitor interval=3600 timeout=60 \
       --group ERS_RESOURCE_GROUP

Créer les ressources des vérifications d'état

1. Configurez la ressource de cluster pour la vérification d'état ASCS :

   # pcs resource create _HEALTHCHECK_SCS service:haproxy@SIDascs \
      op monitor interval=10s timeout=20s \
      --group ASCS_RESOURCE_GROUP

2. Configurez la ressource de cluster pour la vérification d'état ERS :

   # pcs resource create _HEALTHCHECK_ERS service:haproxy@SIDers \
      op monitor interval=10s timeout=20s \
      --group ERS_RESOURCE_GROUP

Définir d'autres propriétés par défaut pour le cluster

1. Définissez des propriétés de cluster supplémentaires :

   # pcs resource defaults resource-stickiness=1
   # pcs resource defaults migration-threshold=3

Afficher les ressources définies

Affichez les ressources de cluster que vous avez définies jusqu'à présent pour vous assurer qu'elles sont correctes.

1. Affichez l'état du cluster :

   # pcs status

   Un résultat semblable aux lignes suivantes doit s'afficher :

   Cluster name: nwha
   Cluster Summary:
     * Stack: corosync
     * Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum
     * 2 nodes configured
     * 8 resource instances configured
   
   Node List:
     * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
   Full List of Resources:
     * fence-nw-ha-vm-2    (stonith:fence_gce):     Started nw-ha-vm-1
     * fence-nw-ha-vm-1    (stonith:fence_gce):     Started nw-ha-vm-2
     * Resource Group: nw8_ascs00_group:
       * nw8_vip_ascs00    (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
       * nw8_healthcheck_scs   (service:haproxy@nw8scs):    Started nw-ha-vm-1
       * nw8_fs_ascs00 (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
     * Resource Group: nw8_ers10_group:
       * nw8_vip_ers10 (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-2
       * nw8_healthcheck_ers   (service:haproxy@nw8ers):    Started nw-ha-vm-2
       * nw8_fs_ers10  (ocf::heartbeat:Filesystem):     Started nw-ha-vm-2
   
   Daemon Status:
     corosync: active/enabled
     pacemaker: active/enabled
     pcsd: active/enabled
   

Installer ASCS et ERS

La section suivante n'aborde que les exigences et les recommandations spécifiques à l'installation de SAP NetWeaver sur Google Cloud.

Pour obtenir des instructions d'installation complètes, consultez la documentation de SAP NetWeaver.

Préparer l'installation

Pour assurer la cohérence entre les clusters et simplifier l'installation, définissez les utilisateurs, les groupes et les autorisations puis mettez le serveur secondaire en mode veille avant d'installer les composants SAP NetWeaver ASCS et ERS.

1. Désactivez le mode de maintenance pour le cluster :

   # sudo pcs property set maintenance-mode="false"

2. Sur les deux serveurs, en tant qu'utilisateur racine, saisissez les commandes suivantes en spécifiant les ID d'utilisateur et de groupe adaptés à votre environnement :

   # groupadd -g GID_SAPINST sapinst
   # groupadd -g GID_SAPSYS sapsys
   # useradd -u UID_SIDADM SID_LCadm -g sapsys
   # usermod -a -G sapinst SID_LCadm
   # useradd -u UID_SAPADM sapadm -g sapinst
   
   # chown SID_LCadm:sapsys /usr/sap/SID/SYS
   # chown SID_LCadm:sapsys /sapmnt/SID -R
   # chown SID_LCadm:sapsys /usr/sap/trans -R
   # chown SID_LCadm:sapsys /usr/sap/SID/SYS -R
   # chown SID_LCadm:sapsys /usr/sap/SID -R

   Remplacez les éléments suivants :

   • GID_SAPINST : spécifiez l'ID de groupe Linux pour l'outil de provisionnement SAP.
   • GID_SAPSYS : spécifiez l'ID de groupe Linux pour l'utilisateur SAPSYS.
   • UID_SIDADM : spécifiez l'ID utilisateur Linux pour l'administrateur du système SAP (SID).
   • SID_LC : spécifiez l'ID système (SID). Utilisez des minuscules pour toutes les lettres.
   • UID_SAPADM : spécifiez l'ID utilisateur de l'agent hôte SAP.
   • SID : spécifiez l'ID système (SID). Utilisez des majuscules pour toutes les lettres.

   Par exemple, voici un schéma pratique de numérotation GID et UID :

   Group sapinst      1001
   Group sapsys       1002
   Group dbhshm       1003
   
   User  en2adm       2001
   User  sapadm       2002
   User  dbhadm       2003

Installer le composant ASCS

1. Sur le serveur secondaire, entrez la commande suivante pour mettre le serveur secondaire en mode veille :

   # pcs node standby

   Le fait de placer le serveur secondaire en mode veille consolide toutes les ressources de cluster sur le serveur principal, ce qui simplifie l'installation.

2. Vérifiez que le serveur secondaire est en mode veille :

   # pcs status

   Un résultat semblable aux lignes suivantes doit s'afficher :

   Cluster name: nwha
      Cluster Summary:
        * Stack: corosync
        * Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum
        * 2 nodes configured
        * 8 resource instances configured
   
      Node List:
        * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
      Full List of Resources:
        * fence-nw-ha-vm-2  (stonith:fence_gce):     Started nw-ha-vm-1
        * fence-nw-ha-vm-1  (stonith:fence_gce):     Stopped
        * Resource Group: nw8_ascs00_group:
          * nw8_vip_ascs00  (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
          * nw8_healthcheck_scs (service:haproxy@nw8scs):    Started nw-ha-vm-1
          * nw8_fs_ascs00   (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
        * Resource Group: nw8_ers10_group:
          * nw8_vip_ers10   (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
          * nw8_healthcheck_ers (service:haproxy@nw8ers):    Started nw-ha-vm-1
          * nw8_fs_ers10    (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
   
      Daemon Status:
        corosync: active/enabled
   

3. Sur le serveur principal, en tant qu'utilisateur racine, accédez à un répertoire d'installation temporaire, tel que /tmp, pour installer l'instance ASCS en exécutant l'outil Software Provisioning Manager (SWPM) de SAP.

   • Pour accéder à l'interface Web de SWPM, vous devez disposer du mot de passe de l'utilisateur root. Si votre politique informatique n'autorise pas l'administrateur SAP à avoir accès au mot de passe racine, vous pouvez utiliser SAPINST_REMOTE_ACCESS_USER.

   • Lorsque vous démarrez SWPM, utilisez le paramètre SAPINST_USE_HOSTNAME pour spécifier le nom d'hôte virtuel que vous avez défini pour l'adresse IP virtuelle ASCS dans le fichier /etc/hosts.

     Exemple :

     cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-scs

   • Sur la dernière page de confirmation SWPM, assurez-vous que le nom d'hôte virtuel est correct.

4. Une fois la configuration terminée, retirez la VM secondaire du mode veille :

   # pcs node unstandby

Installer le composant ERS

1. Sur le serveur principal, en tant qu'utilisateur racine ou SID_LCadm, arrêtez le service ASCS.

   # su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function Stop"
   # su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService"

2. Sur le serveur principal, saisissez la commande suivante pour mettre le serveur principal en mode veille :

   # pcs node standby

   Le fait de placer le serveur principal en mode veille consolide toutes les ressources de cluster sur le serveur secondaire, ce qui simplifie l'installation.

3. Vérifiez que le serveur principal est en mode veille :

   # pcs status

4. Sur le serveur secondaire, en tant qu'utilisateur racine, accédez à un répertoire d'installation temporaire, tel que /tmp, pour installer l'instance ERS en exécutant l'outil Software Provisioning Manager (SWPM) de SAP.

   • Utilisez les mêmes nom d'utilisateur et mot de passe que lorsque vous avez installé le composant ASCS pour accéder à SWPM.

   • Lorsque vous démarrez SWPM, utilisez le paramètre SAPINST_USE_HOSTNAME pour spécifier le nom d'hôte virtuel que vous avez défini pour l'adresse IP virtuelle ERS dans le fichier /etc/hosts.

     Exemple :

     cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-ers

   • Sur la dernière page de confirmation SWPM, assurez-vous que le nom d'hôte virtuel est correct.

5. Retirez la VM principale du mode veille pour que les deux instances soient actives :

   # pcs node unstandby

Configurer les services SAP

Vous devez vérifier que les services sont correctement configurés, vérifier les paramètres des profils ASCS et ERS, et ajouter l'utilisateur SID_LCadm au groupe d'utilisateurs haclient.

Vérifier les entrées de service SAP

1. Sur les deux serveurs, vérifiez que votre fichier /usr/sap/sapservices contient bien des entrées pour les services ASCS et ERS. Pour ce faire, vous pouvez utiliser l'intégration systemV ou systemd.

   Vous pouvez ajouter toutes les entrées manquantes à l'aide de la commande sapstartsrv avec les options pf=PROFILE_OF_THE_SAP_INSTANCE et -reg.

   Pour en savoir plus sur ces intégrations, consultez les notes SAP suivantes :

   • 3139184 - Linux : intégration de systemd pour sapstartsrv et l'agent hôte SAP

   • 3115048 - sapstartsrv avec compatibilité systemd Linux native

   systemV

   Voici un exemple de la façon dont les entrées des services ASCS et ERS se présentent dans le fichier /usr/sap/sapservices lorsque vous utilisez l'intégration systemV :

   # LD_LIBRARY_PATH=/usr/sap/hostctrl/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
   /usr/sap/hostctrl/exe/sapstartsrv \
   pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
   -D -u SID_LCadm
   /usr/sap/hostctrl/exe/sapstartsrv \
   pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
   -D -u SID_LCadm

   systemd

   1. Vérifiez que votre fichier /usr/sap/sapservices contient des entrées pour les services ASCS et ERS. Voici un exemple de la façon dont ces entrées apparaissent dans le fichier /usr/sap/sapservices lorsque vous utilisez l'intégration systemd :

      systemctl --no-ask-password start SAPSID_ASCS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_SID_LCascs
      systemctl --no-ask-password start SAPSID_ERS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_SID_LCers

   2. Désactivez l'intégration systemd sur les instances ASCS et ERS :

      Attention : La désactivation de l'intégration systemd arrête également les instances SAP.

      # systemctl disable SAPSID_ASCS_INSTANCE_NUMBER.service
      # systemctl stop SAPSID_ASCS_INSTANCE_NUMBER.service
      # systemctl disable SAPSID_ERS_INSTANCE_NUMBER.service
      # systemctl stop SAPSID_ERS_INSTANCE_NUMBER.service
      

   3. Vérifiez que l'intégration systemd est désactivée :

      # systemctl list-unit-files | grep sap

      Un résultat semblable à l'exemple suivant signifie que l'intégration systemd est désactivée. Notez que certains services, tels que saphostagent et saptune, sont activés, et que d'autres sont désactivés.

      SAPSID_ASCS_INSTANCE_NUMBER.service disabled
      SAPSID_ERS_INSTANCE_NUMBER.service disabled
      saphostagent.service enabled
      sapinit.service generated
      saprouter.service disabled
      saptune.service enabled

Arrêter les services SAP

1. Sur le serveur secondaire, arrêtez le service ERS :

   # su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function Stop"
   # su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService"

2. Sur chaque serveur, vérifiez que tous les services sont arrêtés :

   # su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function GetSystemInstanceList"
   # su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function GetSystemInstanceList"

   Un résultat semblable aux lignes suivantes doit s'afficher :

   GetSystemInstanceList
   FAIL: NIECONN_REFUSED (Connection refused), NiRawConnect failed in plugin_fopen()

Désactiver le redémarrage automatique du service dans SAP

Point clé : Cette section est requise UNIQUEMENT pour systemV.

Étant donné que le logiciel du cluster gère le redémarrage des services SAP lors d'un basculement, pour éviter les conflits, désactivez la capacité du logiciel SAP à redémarrer automatiquement les services.

1. Sur les deux nœuds, modifiez le fichier /usr/sap/sapservices pour désactiver le redémarrage automatique dans le logiciel SAP en ajoutant un caractère de commentaire # au début de la commande sapstartsrv pour les composants ASCS et ERS.

   Exemple :

   #!/bin/sh
   
    #LD_LIBRARY_PATH=/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/SID/ASCSASCS_INSTANCE_NUMBER/exe/sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME -D -u SID_LCadm
    #LD_LIBRARY_PATH=/usr/sap/SID/ERSERS_INSTANCE_NUMBER/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/SID/ERSERS_INSTANCE_NUMBER/exe/sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME -D -u SID_LCadm
    

Modifier les profils ASCS et ERS

1. Sur l'un ou l'autre des serveurs, basculez vers le répertoire du profil en utilisant l'une des commandes suivantes :

   # cd /usr/sap/SID/SYS/profile

   # cd /sapmnt/SID/profile

2. Si nécessaire, vous pouvez rechercher les noms de vos profils ASCS et ERS en répertoriant les fichiers dans le répertoire de profil ou en utilisant les formats suivants :

   SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME

   SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME

3. Si vous utilisez ENSA1, activez la fonction keepalive en définissant les éléments suivants dans le profil ASCS :

   enque/encni/set_so_keepalive = true

   Pour plus d'informations, consultez la Note SAP 1410736 - TCP/IP : définition de l'intervalle keepalive.

4. Si nécessaire, modifiez les profils ASCS et ERS pour modifier le comportement de démarrage du serveur de mise en file d'attente et du serveur de réplication de mise en file d'attente.

   ENSA1

   Dans la section Start SAP enqueue server du profil ASCS, si Restart_Program_NN s'affiche, remplacez Restart par Start, comme illustré dans l'exemple suivant.

   Start_Program_01 = local $(_EN) pf=$(_PF)

   Dans la section Start enqueue replication server (Démarrer le serveur de réplication de mise en file d'attente) du profil ERS, si vous voyez Restart_Program_NN, remplacez "Restart" par "Start", comme illustré dans l'exemple suivant.

   Start_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID)

   ENSA2

   Dans la section Start SAP enqueue server du profil ASCS, si Restart_Program_NN s'affiche, remplacez Restart par Start, comme illustré dans l'exemple suivant.

   Start_Program_01 = local $(_ENQ) pf=$(_PF)

   Dans la section Start enqueue replicator du profil ERS, si vous voyez Restart_Program_NN, remplacez "Restart" par "Start", comme illustré dans l'exemple suivant.

   Start_Program_00 = local $(_ENQR) pf=$(_PF) ...

Configurer les ressources de cluster pour ASCS et ERS

1. En mode root depuis l'un ou l'autre des serveurs, placez le cluster en mode de maintenance :

   # pcs property set maintenance-mode="true"

2. Vérifiez que le cluster est en mode de maintenance :

   # pcs status

3. Créez les ressources de cluster pour les services ASCS et ERS :

   ENSA1

   • Créez la ressource de cluster pour l'instance ASCS. La valeur de InstanceName est le nom du profil d'instance généré par SWPM lors de l'installation d'ASCS.

     # pcs resource create ASCS_INSTANCE_RESOURCE SAPInstance \
         InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
         START_PROFILE=/sapmnt/SID/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
         AUTOMATIC_RECOVER=false meta resource-stickiness=5000 migration-threshold=1 \
         failure-timeout=60  --group ASCS_RESOURCE_GROUP \
         op monitor interval=20 on-fail=restart timeout=60 \
         op start interval=0 timeout=600 \
         op stop interval=0 timeout=600
     

     # pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000
     

   • Créez la ressource de cluster pour l'instance ERS. La valeur de InstanceName est le nom du profil d'instance généré par SWPM lors de l'installation d'ERS. Le paramètre IS_ERS=true indique à Pacemaker de définir l'option runsersSID sur 1 pour le nœud sur lequel ERS est actif.

     # pcs resource create ERS_INSTANCE_RESOURCE SAPInstance \
         InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
         START_PROFILE=/sapmnt/SID/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
         AUTOMATIC_RECOVER=false IS_ERS=true --group ERS_RESOURCE_GROUP \
         op monitor interval=20 on-fail=restart timeout=60 \
         op start interval=0 timeout=600 \
         op stop interval=0 timeout=600
     

   ENSA2

   • Créez la ressource de cluster pour l'instance ASCS. La valeur de InstanceName est le nom du profil d'instance généré par SWPM lors de l'installation d'ASCS.

     # pcs resource create ASCS_INSTANCE_RESOURCE SAPInstance \
         InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
         START_PROFILE=/sapmnt/SID/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
         AUTOMATIC_RECOVER=false meta resource-stickiness=5000 \
         --group ASCS_RESOURCE_GROUP \
         op monitor interval=20 on-fail=restart timeout=60 \
         op start interval=0 timeout=600 \
         op stop interval=0 timeout=600
     

     # pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000
     

   • Créez la ressource de cluster pour l'instance ERS. La valeur de InstanceName est le nom du profil d'instance généré par SWPM lors de l'installation d'ERS.

     # pcs resource create ERS_INSTANCE_RESOURCE SAPInstance \
         InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
         START_PROFILE=/sapmnt/SID/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
         AUTOMATIC_RECOVER=false IS_ERS=true --group ERS_RESOURCE_GROUP \
         op monitor interval=20 on-fail=restart timeout=60 \
         op start interval=0 timeout=600 \
         op stop interval=0 timeout=600
     

Configurer les contraintes d'emplacement et de tri

Créez des contraintes pour définir quels services doivent démarrer en premier et quels services doivent s'exécuter ensemble sur le même hôte. Par exemple, l'adresse IP doit se trouver sur le même hôte que l'instance SAP Central Services principale.

1. Définissez la contrainte d'ordre de démarrage :

ENSA1

1. Créez une contrainte de colocation qui empêche les ressources ASCS de s'exécuter sur le même serveur que les ressources ERS :

   # pcs constraint colocation add ERS_RESOURCE_GROUP with \
       ASCS_RESOURCE_GROUP -5000
   

2. Configurez ASCS pour basculer vers le serveur sur lequel ERS est exécuté, comme déterminé par l'option runsersSID égale à 1 :

   # pcs constraint location ASCS_INSTANCE \
       rule score=2000 runs_ers_SID eq 1

3. Configurez ASCS pour qu'il démarre avant que ERS ne soit déplacé vers l'autre serveur après un basculement :

   # pcs constraint order start ASCS_RESOURCE_GROUP then \
       stop ERS_RESOURCE_GROUP symmetrical=false kind=Optional
   

ENSA2

1. Créez une contrainte de colocation qui empêche les ressources ASCS de s'exécuter sur le même serveur que les ressources ERS :

   # pcs constraint colocation add ERS_RESOURCE_GROUP  with \
       ASCS_RESOURCE_GROUP -5000
   

2. Configurez ASCS pour qu'il démarre avant que ERS ne soit déplacé vers l'autre serveur après un basculement :

   # pcs constraint order start ASCS_RESOURCE_GROUP then \
       stop ERS_RESOURCE_GROUP symmetrical=false kind=Optional
   

1. Vérifiez les contraintes :

   # pcs constraint

   La sortie obtenue doit ressembler à ceci :

   Location Constraints:
     Resource: ascs-aha-instance
       Constraint: location-ascs-instance
         Rule: score=2000
           Expression: runs_ers_HKN eq 1
     Resource: fence-nw-ha-vm-1
       Disabled on: nw-ha-vm-1 (score:-INFINITY)
     Resource: fence-nw-ha-vm-2
       Disabled on: nw-ha-vm-2 (score:-INFINITY)
   Ordering Constraints:
     start ascs-group then stop ers-group (kind:Optional) (non-symmetrical)
   Colocation Constraints:
     ascs-group with ers-group (score:-5000)
   Ticket Constraints:

2. En tant qu'utilisateur racine, depuis l'un ou l'autre des serveurs, désactivez le mode de maintenance du cluster :

   # pcs property set maintenance-mode="false"

Configurer le connecteur de cluster Red Hat pour SAP

Sur chaque hôte du cluster, configurez le service de démarrage SAP sapstartsrv pour communiquer avec le logiciel du cluster Pacemaker via l'interface haute disponibilité.

1. Ajoutez l'administrateur SAP au groupe haclient :

   usermod -a -G haclient SID_LCadm

2. Modifiez les profils des instances SAP en ajoutant les lignes suivantes à la fin de chaque profil. Les profils se trouvent dans le répertoire /sapmnt/SID/profiles.

   service/halib = $(DIR_CT_RUN)/saphascriptco.so
   service/halib_cluster_connector = /usr/bin/sap_cluster_connector

3. Si les ressources d'instances ASCS et ERS sont actuellement en cours d'exécution dans le cluster, désactivez-les :

   pcs resource disable ERS_INSTANCE_RESOURCE
   pcs resource disable ASCS_INSTANCE_RESOURCE

4. Arrêtez les services sur l'hôte ASCS :

   sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService

5. Arrêtez les services sur l'hôte ERS :

   sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService

6. Activez les ressources :

   pcs resource enable ERS_INSTANCE_RESOURCE
   pcs resource enable ASCS_INSTANCE_RESOURCE

7. Répétez les étapes précédentes sur chaque hôte du cluster.

Pour plus d'informations Red Hat, consultez la page Configurer SAP halib pour les ressources SAPInstance sur RHEL 7 et 8.

Installer des serveurs de base de données et d'application sur des hôtes situés en dehors du cluster

Dans la configuration de la haute disponibilité, nous vous recommandons d'installer les serveurs de base de données et d'application sur des hôtes différents des hôtes ASCS et ERS du cluster.

En utilisant des hôtes distincts pour chaque serveur, vous réduisez la complexité, réduisez le risque de défaillance affectant plusieurs serveurs et vous pouvez adapter la taille des instances Compute Engine à chaque type de serveur.

Vous pouvez ainsi choisir la taille de machine certifiée la plus appropriée, éviter les défaillances et réduire la complexité.

L'installation des serveurs de base de données et d'application n'est pas traitée dans ce guide.

Pour en savoir plus sur l'installation des serveurs de base de données, consultez les pages suivantes :

• SAP HANA sur Google Cloud
• SAP ASE sur Google Cloud
• SAP MaxDB sur Google Cloud
• IBM Db2 pour SAP sur Google Cloud

Valider et tester le cluster

Cette section vous explique comment exécuter les tests suivants :

• Recherchez les erreurs de configuration.
• Vérifiez que les ressources ASCS et ERS basculent correctement les serveurs lors des basculements.
• Vérifiez que les verrous sont conservés.
• Simuler un événement de maintenance Compute Engine pour vérifier que la migration à chaud ne déclenche pas de basculement

Vérifier la configuration du cluster

1. En tant qu'utilisateur racine, sur l'un ou l'autre des serveurs, vérifiez les nœuds sur lesquels vos ressources s'exécutent :

   # pcs status

   Dans l'exemple suivant, les ressources ASCS s'exécutent sur le serveur nw-ha-vm-2 et les ressources ERS sur le serveur nw-ha-vm-1.

   Stack: corosync
     Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
     Last updated: Wed Apr 13 05:21:21 2022
     Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2
   
     2 nodes configured
     10 resource instances configured
   
     Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
     Full list of resources:
   
     fence-nw-ha-vm-1     (stonith:fence_gce):    Started nw-ha-vm-2
     fence-nw-ha-vm-2     (stonith:fence_gce):    Started nw-ha-vm-1
      Resource Group: ascs-group
          ascs-file-system   (ocf::heartbeat:Filesystem):    Started nw-ha-vm-2
          ascs-vip   (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-2
          ascs-healthcheck   (service:haproxy@AHAascs):      Started nw-ha-vm-2
          ascs-aha-instance      (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-2
      Resource Group: ers-group
          ers-file-system    (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
          ers-vip    (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
          ers-healthcheck    (service:haproxy@AHAers):       Started nw-ha-vm-1
          ers-aha-instance       (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-1
   
     Migration Summary:
     * Node nw-ha-vm-1:
     * Node nw-ha-vm-2:

2. Passez à l'utilisateur SID_LCadm :

   # su - SID_LCadm

3. Vérifiez la configuration du cluster. Pour INSTANCE_NUMBER, spécifiez le numéro de l'instance ASCS ou ERS active sur le serveur sur lequel vous saisissez la commande :

   > sapcontrol -nr INSTANCE_NUMBER -function HAGetFailoverConfig

   HAActive doit être TRUE, comme illustré dans l'exemple suivant :

   HAGetFailoverConfig
   
   14.04.2022 17:25:45
   HAGetFailoverConfig
   OK
   HAActive: TRUE
   HAProductVersion: Pacemaker
   HASAPInterfaceVersion: sap_cluster_connector
   HADocumentation: https://github.com/ClusterLabs/sap_cluster_connector
   HAActiveNode:
   HANodes:

4. En tant que SID_LCadm, recherchez les erreurs dans la configuration :

   > sapcontrol -nr INSTANCE_NUMBER -function HACheckConfig

   Un résultat semblable aux lignes suivantes doit s'afficher :

   14.04.2022 21:43:39
   HACheckConfig
   OK
   state, category, description, comment
   SUCCESS, SAP CONFIGURATION, Redundant ABAP instance configuration, 0 ABAP instances detected
   SUCCESS, SAP CONFIGURATION, Enqueue separation, All Enqueue server separated from application server
   SUCCESS, SAP CONFIGURATION, MessageServer separation, All MessageServer separated from application server
   SUCCESS, SAP STATE, SCS instance running, SCS instance status ok
   SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vip-ascs_NWT_00), SAPInstance includes is-ers patch
   SUCCESS, SAP CONFIGURATION, Enqueue replication (vip-ascs_NWT_00), Enqueue replication enabled
   SUCCESS, SAP STATE, Enqueue replication state (vip-ascs_NWT_00), Enqueue replication active
   SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vip-ers_NWT_10), SAPInstance includes is-ers patch

5. Sur le serveur où ASCS est actif, en tant que SID_LCadm, simulez un basculement :

   > sapcontrol -nr ASCS_INSTANCE_NUMBER -function HAFailoverToNode ""

6. En tant qu'utilisateur racine, si vous suivez le basculement à l'aide de crm_mon, vous devriez voir ASCS se déplacer vers l'autre serveur, ERS s'arrêter sur ce serveur, puis passer au serveur sur lequel ASCS s'exécutait.

Simuler un basculement

Testez votre cluster en simulant une défaillance sur l'hôte principal. Utilisez un système de test ou exécutez le test sur votre système de production avant de mettre le système en service.

Vous pouvez simuler une défaillance de différentes manières, par exemple :

• shutdown -r (sur le nœud actif)
• ip link set eth0 down
• echo c > /proc/sysrq-trigger

Ces instructions utilisent ip link set eth0 down pour déconnecter l'interface réseau, car cette commande valide à la fois le basculement et le cloisonnement.

1. Sauvegardez votre système.

2. En tant qu'utilisateur racine sur l'hôte avec l'instance SCS active, déconnectez l'interface réseau :

   $ ip link set eth0 down

3. Reconnectez-vous à l'un des hôtes à l'aide de SSH, puis connectez-vous en tant qu'utilisateur racine.

4. Saisissez pcs status pour vérifier que l'hôte principal est désormais actif sur la VM qui contenait l'hôte secondaire. Le redémarrage automatique est activé dans le cluster. Par conséquent, l'hôte arrêté redémarre et prend le rôle d'hôte secondaire, comme illustré dans l'exemple suivant.

    Stack: corosync
     Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
     Last updated: Wed Apr 13 05:21:21 2022
     Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2
   
     2 nodes configured
     10 resource instances configured
   
     Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
     Full list of resources:
   
     fence-nw-ha-vm-1     (stonith:fence_gce):    Started nw-ha-vm-2
     fence-nw-ha-vm-2     (stonith:fence_gce):    Started nw-ha-vm-1
      Resource Group: ascs-group
          ascs-file-system   (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
          ascs-vip   (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
          ascs-healthcheck   (service:haproxy@AHAascs):      Started nw-ha-vm-1
          ascs-aha-instance      (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-1
      Resource Group: ers-group
          ers-file-system    (ocf::heartbeat:Filesystem):    Started nw-ha-vm-2
          ers-vip    (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-2
          ers-healthcheck    (service:haproxy@AHAers):       Started nw-ha-vm-2
          ers-aha-instance       (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-2
   
     Migration Summary:
     * Node nw-ha-vm-1:
     * Node nw-ha-vm-2:

Vérifier que les entrées de verrou sont conservées

Pour vérifier que les entrées de verrou sont conservées lors d'un basculement, sélectionnez d'abord l'onglet correspondant à votre version du serveur de mise en file d'attente et suivez la procédure permettant de générer des entrées de verrou, simulez un basculement et vérifiez que les entrées de verrou sont conservés après la réactivation de ASCS.

ENSA1

1. En tant que SID_LCadm, sur le serveur sur lequel ERS est actif, générez des entrées de verrou à l'aide du programme enqt :

   > enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 11 NUMBER_OF_LOCKS

2. En tant que SID_LCadm, sur le serveur sur lequel ASCS est actif, vérifiez que les entrées de verrou sont enregistrées :

   > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

   Si vous avez créé 10 verrous, vous devriez obtenir un résultat semblable à celui-ci :

   locks_now: 10

3. En tant que SID_LCadm, sur le serveur sur lequel ERS est actif, démarrez la fonction de surveillance, OpCode=20, du programme enqt :

   > enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 20 1 1 9999

   Exemple :

   > enqt pf=/sapmnt/AHA/profile/AHA_ERS10_vh-ers-aha 20 1 1 9999

4. Si ASCS est actif, redémarrez le serveur.

   Sur le serveur de surveillance, au moment où Pacemaker arrête ERS pour le déplacer vers l'autre serveur, un résultat semblable à ce qui suit doit s'afficher.

   Number of selected entries: 10
   Number of selected entries: 10
   Number of selected entries: 10
   Number of selected entries: 10
   Number of selected entries: 10

5. Lorsque la surveillance enqt s'arrête, quittez en saisissant Ctrl + c.

6. Vous pouvez éventuellement surveiller le basculement du cluster en tant qu'utilisateur racine :

   # crm_mon

7. En tant que SID_LCadm, après avoir confirmé que les verrous ont été conservés, libérez-les :

   > enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 12 NUMBER_OF_LOCKS

8. En tant que SID_LCadm, sur le serveur sur lequel ASCS est actif, vérifiez que les entrées de verrou sont supprimées :

   > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

ENSA2

1. En tant que SID_LCadm, sur le serveur sur lequel ASCS est actif, générez des entrées de verrou à l'aide du programme enq_adm :

   > enq_admin --set_locks=NUMBER_OF_LOCKS:X:DIAG::TAB:%u pf=/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME

2. En tant que SID_LCadm, sur le serveur sur lequel ASCS est actif, vérifiez que les entrées de verrou sont enregistrées :

   > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

   Si vous avez créé 10 verrous, vous devriez obtenir un résultat semblable à celui-ci :

   locks_now: 10

3. Lorsque ERS est actif, vérifiez que les entrées de verrou ont bien été répliquées :

   > sapcontrol -nr ERS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

   Le nombre de verrous renvoyés doit être identique à celui de l'instance ASCS.

4. Si ASCS est actif, redémarrez le serveur.

5. Vous pouvez éventuellement surveiller le basculement du cluster en tant qu'utilisateur racine :

   # crm_mon

6. En tant que SID_LCadm, sur le serveur sur lequel ASCS a redémarré, vérifiez que les entrées de verrou ont été conservées :

   > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

7. En tant que SID_LCadm, sur le serveur sur lequel ERS est actif, libérez les verrous après avoir confirmé qu'ils ont été conservés :

   > enq_admin --release_locks=NUMBER_OF_LOCKS:X:DIAG::TAB:%u pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME

8. En tant que SID_LCadm, sur le serveur sur lequel ASCS est actif, vérifiez que les entrées de verrou sont supprimées :

   > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

   Un résultat semblable à l'exemple suivant doit s'afficher :

   locks_now: 0

Simuler un événement de maintenance Compute Engine

Simulez un événement de maintenance Compute Engine pour vous assurer que la migration à chaud ne déclenche pas de basculement.

Les valeurs de délai avant expiration et d'intervalle utilisées dans ces instructions tiennent compte de la durée des migrations à chaud. Si vous utilisez des valeurs plus courtes dans la configuration de votre cluster, le risque de déclenchement d'un basculement par la migration à chaud augmente.

Pour tester la tolérance de votre cluster pour la migration à chaud, procédez comme suit :

1. Sur le nœud principal, déclenchez un événement de maintenance simulé à l'aide de la commande CLI gcloud suivante :

   $ gcloud compute instances simulate-maintenance-event PRIMARY_VM_NAME

2. Vérifiez que le nœud principal ne change pas :

   $ pcs status

Évaluer votre charge de travail SAP NetWeaver

Pour automatiser les vérifications de validation continues pour vos charges de travail à haute disponibilité SAP NetWeaver exécutées sur Google Cloud, vous pouvez utiliser le gestionnaire de charges de travail.

Le gestionnaire de charges de travail vous permet d'analyser et d'évaluer automatiquement vos charges de travail SAP NetWeaver à haute disponibilité par rapport aux bonnes pratiques des fournisseurs SAP, Google Cloud et OS. Cela permet d'améliorer la qualité, les performances et la fiabilité de vos charges de travail.

Pour en savoir plus sur les bonnes pratiques compatibles avec le gestionnaire de charges de travail pour évaluer les charges de travail SAP NetWeaver à haute disponibilité exécutées sur Google Cloud, consultez la page Bonnes pratiques pour le gestionnaire de charges de travail SAP. Pour en savoir plus sur la création et l'exécution d'une évaluation à l'aide du gestionnaire de charges de travail, consultez la page Créer et exécuter une évaluation.

Dépannage

Pour résoudre les problèmes liés aux configurations à haute disponibilité pour SAP NetWeaver, consultez la page Dépannage des configurations à haute disponibilité pour SAP.

Collecter des informations de diagnostic pour les clusters SAP NetWeaver à haute disponibilité

Si vous avez besoin d'aide pour résoudre un problème lié à des clusters à haute disponibilité pour SAP NetWeaver, rassemblez les informations de diagnostic requises et contactez Cloud Customer Care.

Pour collecter des informations de diagnostic, consultez la page Informations de diagnostic sur les clusters à haute disponibilité RHEL.

Assistance

Pour les problèmes liés à l'infrastructure ou aux services Google Cloud, contactez l'assistance Customer Care. Ses coordonnées sont disponibles sur la page de présentation de l'assistance dans la console Google Cloud. Si l'assistance Customer Care détecte un problème dans vos systèmes SAP, vous serez redirigé vers l'assistance SAP.

Pour les problèmes liés au produit SAP, entrez votre demande d'assistance avec l'outil de l'assistance SAP. SAP évalue la demande d'assistance puis, s'il semble s'agir d'un problème d'infrastructure Google Cloud, la transfère au composant Google Cloud approprié dans son système : BC-OP-LNX-GOOGLE ou BC-OP-NT-GOOGLE.

Exigences liées à l'assistance

Pour bénéficier d'une assistance pour les systèmes SAP ainsi que pour l'infrastructure et les services Google Cloud que ces systèmes utilisent, vous devez satisfaire aux exigences minimales de la formule d'assistance.

Pour en savoir plus sur les exigences minimales concernant l'assistance pour SAP sur Google Cloud, consultez les ressources suivantes :

• Obtenir de l'aide concernant SAP sur Google Cloud
• Note SAP 2456406 – SAP sur Google Cloud Platform : prérequis pour l'assistance (un compte utilisateur SAP est requis)

Effectuer des tâches post-déploiement

Avant d'utiliser votre système SAP NetWeaver, nous vous recommandons de sauvegarder votre nouveau système à haute disponibilité SAP NetWeaver.

Pour en savoir plus, consultez le guide d'utilisation de SAP NetWeaver.

Étapes suivantes

Pour en savoir plus sur la haute disponibilité, SAP NetWeaver et Google Cloud, consultez les ressources suivantes :

• Installer et configurer un cluster à haute disponibilité Red Hat Enterprise Linux 7.6 (et versions ultérieures) sur Google Compute Cloud

• Règles de prise en charge pour les clusters à haute disponibilité RHEL - Exigences générales pour le cloisonnement/STONITH

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

• Pour en savoir plus sur l'administration et la surveillance des VM, consultez le guide d'utilisation de SAP NetWeaver.