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

Ce guide explique comment automatiser le déploiement d'un cluster à haute disponibilité (HA) SUSE Linux Enterprise Server (SLES) optimisé pour les performances pour SAP NetWeaver. La configuration Simple Mount est également fournie pour SLES 15 pour SAP et versions ultérieures.

Ce guide utilise Terraform pour déployer deux machines virtuelles (VM) Compute Engine, une adresse IP virtuelle avec implémentation d'un équilibreur de charge réseau passthrough interne et un cluster à haute disponibilité basé sur un système d'exploitation, le tout conformément aux bonnes pratiques de Google Cloud, de SAP et du fournisseur du système d'exploitation.

À 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.

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 HANA sur Red Hat Enterprise Linux (RHEL), consultez le guide de configuration d'un cluster à haute disponibilité pour un système SAP NetWeaver sur RHEL.

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 SLES. 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

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, spécifiez un tag réseau pour chaque VM à utiliser dans les règles de routage et de pare-feu. Lorsque vous utilisez le fichier de configuration Terraform fourni par Google Cloud, spécifiez un tag avec network_tags = "TAG".

Informations connexes sur SUSE

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

• Cluster haute disponibilité 1 de réplication de mise en file d'attente SAP NetWeaver – Guide de configuration pour SAP NetWeaver 7.40 et 7.50 | SUSE Linux Enterprise Server for SAP Applications 12
• Cluster haute disponibilité 1 de réplication de mise en file d'attente SAP NetWeaver – Guide de configuration pour SAP NetWeaver 7.40 et 7.50 | SUSE Linux Enterprise Server pour SAP Applications 15
• Cluster haute disponibilité 2 de réplication de mise en file d'attente SAP S/4 HANA – Guide de configuration | SUSE Linux Enterprise Server for SAP Applications 12
• Cluster haute disponibilité 2 de réplication de mise en file d'attente SAP S/4 HANA – Guide de configuration | SUSE Linux Enterprise Server for SAP Applications 15

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 créer un réseau VPC pour votre projet, procédez comme suit :

1. Créez un réseau en mode personnalisé. Pour plus d'informations, consultez la section Créer un réseau en mode personnalisé.

2. Créez un sous-réseau, puis spécifiez la région et la plage d'adresses IP. Pour plus d'informations, consultez la section Ajouter 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.

Consultez la section Créer des règles de pare-feu pour créer les règles de pare-feu de votre projet.

Créer un cluster Linux à haute disponibilité pour SAP NetWeaver

Les instructions suivantes utilisent un fichier de configuration Terraform pour créer un cluster SLES avec deux systèmes SAP NetWeaver, un système SAP NetWeaver principal sur une instance de VM et un système SAP NetWeaver de secours sur une autre instance de VM de la même région Compute Engine.

Vous définissez les options de configuration du cluster à haute disponibilité SAP NetWeaver dans un fichier de configuration Terraform.

1. Ouvrez Cloud Shell.

   Accéder à Cloud Shell

2. Téléchargez dans votre répertoire de travail le fichier de configuration sap_nw_ha.tf du cluster SAP NetWeaver à haute disponibilité :

   $ wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_nw_ha/terraform/sap_nw_ha.tf

   Remarque : Assurez-vous de ne disposer que d'un seul fichier de configuration Terraform dans votre répertoire de travail.

3. Ouvrez le fichier sap_nw_ha.tf dans l'éditeur de code Cloud Shell.

   Pour ce faire, cliquez sur l'icône en forme de crayon située dans l'angle supérieur droit de la fenêtre du terminal Cloud Shell.

4. Dans le fichier sap_nw_ha.tf, mettez à jour les valeurs d'argument en remplaçant le contenu entre guillemets doubles par les valeurs de votre installation. Les arguments sont décrits dans le tableau suivant.

   Argument	Type de données	Description
   source	Chaîne	Spécifie l'emplacement et la version du module Terraform à utiliser lors du déploiement. Le fichier de configuration sap_nw_ha.tf comprend deux instances de l'argument source : l'une active et l'autre incluse en tant que commentaire. L'argument source actif par défaut spécifie latest comme version de module. La deuxième instance de l'argument source, qui est désactivée par défaut par un caractère # de début, spécifie un horodatage qui identifie une version de module. Si vous avez besoin que tous vos déploiements utilisent la même version de module, supprimez le caractère # de début de l'argument source qui spécifie l'horodatage de la version, puis ajoutez-le à l'argument source spécifiant latest.
   project_id	Chaîne	Indiquez l'ID de votre projet Google Cloud dans lequel vous déployez ce système. Par exemple, my-project-x.
   machine_type	Chaîne	Spécifiez le type de machine virtuelle (VM) Compute Engine sur lequel vous devez exécuter votre système SAP. Si vous avez besoin d'un type de VM personnalisé, spécifiez un type de VM prédéfini avec un nombre de processeurs virtuels le plus proche possible de la quantité dont vous avez besoin tout en étant légèrement supérieur. Une fois le déploiement terminé, modifiez le nombre de processeurs virtuels et la quantité de mémoire. Par exemple, n1-highmem-32.
   network	Chaîne	Indiquez le nom du réseau dans lequel vous devez créer l'équilibreur de charge qui gère l'adresse IP virtuelle. Si vous utilisez un réseau VPC partagé, vous devez ajouter l'ID du projet hôte en guise de répertoire parent du nom de réseau. Par exemple : HOST_PROJECT_ID/NETWORK_NAME.
   subnetwork	Chaîne	Spécifiez le 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 SHARED_VPC_PROJECT_ID/SUBNETWORK. Exemple : myproject/network1.
   linux_image	Chaîne	Indiquez le nom de l'image du système d'exploitation Linux sur laquelle vous souhaitez déployer votre système SAP. Par exemple, sles-15-sp5-sap. Pour obtenir la liste des images de système d'exploitation disponibles, consultez la page Images dans la console Google Cloud.
   linux_image_project	Chaîne	Spécifiez le projet Google Cloud qui contient l'image que vous avez spécifiée pour l'argument linux_image. Ce projet peut être votre propre projet ou un projet d'image Google Cloud. Pour une image Compute Engine, spécifiez suse-sap-cloud. Pour trouver le projet d'image correspondant à votre système d'exploitation, consultez la page Détails des systèmes d'exploitation.
   sap_primary_instance	Chaîne	Spécifiez le nom de l'instance de VM pour le système SAP NetWeaver principal. Il s'agit de votre emplacement ASCS initial. Ce nom peut contenir des lettres minuscules, des chiffres ou des traits d'union. Il ne doit pas dépasser 13 caractères.
   sap_primary_zone	Chaîne	Spécifiez une zone dans laquelle le système SAP NetWeaver principal est déployé. Les zones principale et secondaire doivent être dans la même région. Par exemple : us-east1-b
   sap_secondary_instance	Chaîne	Spécifiez un nom pour l'instance de VM du système SAP NetWeaver secondaire. Il s'agit de votre emplacement ERS initial. Ce nom peut contenir des lettres minuscules, des chiffres ou des traits d'union. Il ne doit pas dépasser 13 caractères.
   sap_secondary_zone	Chaîne	Spécifiez une zone dans laquelle le système SAP NetWeaver secondaire est déployé. Les zones principale et secondaire doivent être dans la même région. Par exemple : us-east1-c
   nfs_path	Chaîne	Spécifiez le point d'installation NFS pour le système de fichiers partagé. Par exemple, 10.163.58.114:/ssd_nfs. Remarque : Le point d'installation NFS du système de fichiers partagé doit être vide avant d'appliquer la configuration Terraform.
   sap_sid	Chaîne	Spécifiez un ID pour le système SAP. L'ID doit comporter trois caractères alphanumériques et commencer par une lettre. Toutes les lettres doivent être en majuscules. Par exemple, ED1.
   hc_firewall_rule_name	Chaîne	Facultatif. Spécifiez un nom pour la règle de pare-feu de vérification de l'état. La valeur par défaut est SAP_SID-hc-allow.
   hc_network_tag	Chaîne	Facultatif. Spécifiez un ou plusieurs tags réseau séparés par une virgule que vous souhaitez associer à vos instances de VM pour la règle de pare-feu de vérification de l'état. La valeur par défaut est SAP_SID-hc-allow-tag.
   scs_inst_group_name	Chaîne	Facultatif. Spécifiez un nom pour le groupe d'instances ASCS. La valeur par défaut est SAP_SID-scs-ig.
   scs_hc_name	Chaîne	Facultatif. Spécifiez un nom pour la vérification de l'état ASCS. La valeur par défaut est SAP_SID-scs-hc.
   scs_hc_port	Chaîne	Facultatif. Spécifiez un nom pour la vérification de l'état ASCS. Pour éviter tout conflit avec d'autres services, indiquez le numéro de port de la vérification d'état ASCS dans la plage privée (49152-65535). La valeur par défaut est 60000.
   scs_vip_address	Chaîne	Facultatif. Spécifiez une adresse IP non utilisée dans le sous-réseau spécifié dans subnetwork précédemment à utiliser comme adresse IP virtuelle pour l'instance ASCS. Si rien n'est spécifié, les scripts de déploiement sélectionnent automatiquement une adresse IP non utilisée dans le sous-réseau spécifié.
   scs_vip_name	Chaîne	Facultatif. Spécifiez un nom pour l'adresse IP virtuelle ASCS. La valeur par défaut est SAP_SID-scs-vip.
   scs_backend_svc_name	Chaîne	Facultatif. Spécifiez un nom pour le service de backend ASCS. La valeur par défaut est SAP_SID-scs-backend-svc.
   scs_forw_rule_name	Chaîne	Facultatif. Spécifiez un nom pour la règle de transfert ASCS. La valeur par défaut est SAP_SID-scs-fwd-rule.
   ers_inst_group_name	Chaîne	Facultatif. Indiquez le nom du groupe d'instances ERS. La valeur par défaut est SAP_SID-ers-ig.
   ers_hc_name	Chaîne	Facultatif. Indiquez un nom pour la vérification de l'état ERS. La valeur par défaut est SAP_SID-ers-hc.
   ers_hc_port	Chaîne	Facultatif. Indiquez un nom pour la vérification de l'état ERS. Pour éviter tout conflit avec d'autres services, indiquez le numéro de port de la vérification d'état ERS dans la plage privée (49152-65535). La valeur par défaut est 60010.
   ers_vip_address	Chaîne	Facultatif. Spécifiez une adresse IP non utilisée dans le sous-réseau spécifié dans subnetwork précédemment à utiliser comme adresse IP virtuelle pour l'instance ERS. Si rien n'est spécifié, les scripts de déploiement sélectionnent automatiquement une adresse IP non utilisée dans le sous-réseau spécifié.
   ers_vip_name	Chaîne	Facultatif. Spécifiez un nom pour l'adresse IP virtuelle ERS. La valeur par défaut est SAP_SID-ers-vip.
   ers_backend_svc_name	Chaîne	Facultatif. Indiquez le nom du service de backend ERS. La valeur par défaut est SAP_SID-ers-backend-svc.
   ers_forw_rule_name	Chaîne	Facultatif. Indiquez un nom pour la règle de transfert ERS. La valeur par défaut est SAP_SID-ers-fwd-rule.
   usr_sap_size	Entier	Facultatif. Spécifiez la taille du disque /usr/sap en Go. La taille minimale est de 8 Go. La valeur par défaut est 8.
   swap_size	Entier	Facultatif. Spécifiez la taille du volume en Go. La taille minimale est de 8 Go. La valeur par défaut est 8.
   sap_scs_instance_number	Chaîne	Facultatif. Spécifiez le numéro d'instance ASCS. La valeur sap_scs_instance_number doit être un nombre à deux chiffres. Si vous devez spécifier un numéro à un seul chiffre, ajoutez un caractère 0 devant le nombre. Par exemple, 07. La valeur par défaut est 00.
   sap_ers_instance_number	Chaîne	Facultatif. Spécifiez le numéro d'instance ERS. La valeur sap_ers_instance_number doit être un nombre à deux chiffres. Si vous devez spécifier un numéro à un seul chiffre, ajoutez un caractère 0 devant le nombre. Par exemple, 07. La valeur par défaut est 10.
   sap_nw_abap	Booléen	Facultatif. Indiquez si vous déployez une pile ABAP ou une pile Java de SAP NetWeaver. Pour une pile Java de SAP NetWeaver, spécifiez false. La valeur par défaut est true.
   pacemaker_cluster_name	Chaîne	Facultatif. Spécifiez un nom pour le cluster Pacemaker. La valeur par défaut est SAP_SID-cluster.
   public_ip	Booléen	Facultatif. Pour créer une adresse IP publique éphémère pour les instances de VM, définissez public_ip sur true. La valeur par défaut est false. Attention : Lorsque le champ public_ip est défini sur false, assurez-vous d'avoir configuré une passerelle NAT avec un tag réseau défini pour la VM ou d'avoir fourni à la VM une autre route vers Internet. Si aucun moyen d'accès à Internet n'est disponible, l'installation échoue.
   service_account	Chaîne	Facultatif. Spécifiez l'adresse e-mail d'un compte de service géré par l'utilisateur qui sera utilisée par les VM hôtes et par les programmes qui s'exécutent sur celles-ci. Par exemple, [e-mail]. Si vous spécifiez cet argument sans valeur ou si vous l'omettez, le script d'installation utilise le compte de service Compute Engine par défaut. Pour en savoir plus, consultez la page Gestion de l'authentification et des accès pour les programmes SAP sur Google Cloud.
   network_tags	Chaîne	Facultatif. Spécifiez un ou plusieurs tags réseau séparés par une virgule que vous souhaitez associer à vos instances de VM à des fins de routage ou de pare-feu. Un tag réseau pour les composants ILB est automatiquement ajouté aux tags réseau de la VM. Si vous spécifiez public_ip = false et ne spécifiez pas de tag réseau, veillez à fournir un autre moyen d'accès à Internet.
   sap_deployment_debug	Booléen	Facultatif. Lorsque Cloud Customer Care vous demande d'activer le débogage pour votre déploiement, spécifiez true, qui permet au déploiement de générer des journaux de déploiement détaillés. La valeur par défaut est false.
   primary_reservation_name	Chaîne	Facultatif. Si vous souhaitez utiliser une réservation de VM Compute Engine spécifique pour le provisionnement de l'instance de VM qui héberge l'instance SAP HANA principale de votre cluster à haute disponibilité, spécifiez le nom de la réservation. Par défaut, le script d'installation sélectionne toute réservation Compute Engine disponible en fonction des conditions suivantes. Que vous définissiez son nom ou que le script d'installation le sélectionne automatiquement, la réservation doit être définie comme suit pour être utilisable : L'option specificReservationRequired est définie sur true ou, dans la console Google Cloud, l'option Sélectionner une réservation spécifique est sélectionnée. Certains types de machines Compute Engine sont compatibles avec les plates-formes de processeur qui ne sont pas couvertes par la certification SAP de ce type de machine. Si la réservation cible concerne l'un des types de machines suivants, la réservation doit spécifier les plates-formes de processeur minimales, comme indiqué : n1-highmem-32 : Intel Broadwell n1-highmem-64 : Intel Broadwell n1-highmem-96 : Intel Skylake m1-megamem-96 : Intel Skylake Les plates-formes de processeur minimales pour tous les autres types de machines certifiés par SAP pour une utilisation sur Google Cloud sont conformes à la configuration minimale requise de processeur SAP.
   secondary_reservation_name	Chaîne	Facultatif. Si vous souhaitez utiliser une réservation de VM Compute Engine spécifique pour le provisionnement de l'instance de VM qui héberge l'instance SAP HANA secondaire de votre cluster à haute disponibilité, spécifiez le nom de la réservation. Par défaut, le script d'installation sélectionne toute réservation Compute Engine disponible en fonction des conditions suivantes. Que vous définissiez son nom ou que le script d'installation le sélectionne automatiquement, la réservation doit être définie comme suit pour être utilisable : L'option specificReservationRequired est définie sur true ou, dans la console Google Cloud, l'option Sélectionner une réservation spécifique est sélectionnée. Certains types de machines Compute Engine sont compatibles avec les plates-formes de processeur qui ne sont pas couvertes par la certification SAP de ce type de machine. Si la réservation cible concerne l'un des types de machines suivants, la réservation doit spécifier les plates-formes de processeur minimales, comme indiqué : n1-highmem-32 : Intel Broadwell n1-highmem-64 : Intel Broadwell n1-highmem-96 : Intel Skylake m1-megamem-96 : Intel Skylake Les plates-formes de processeur minimales pour tous les autres types de machines certifiés par SAP pour une utilisation sur Google Cloud sont conformes à la configuration minimale requise de processeur SAP.
   can_ip_forward	Booléen	Indiquez si l'envoi et la réception des paquets avec des adresses IP sources ou de destination qui ne correspondent pas sont autorisés, ce qui permet à une VM de se comporter comme un routeur. La valeur par défaut est true. Si vous ne prévoyez d'utiliser que les équilibreurs de charge internes de Google pour gérer les adresses IP virtuelles des VM déployées, définissez la valeur sur false. Un équilibreur de charge interne est automatiquement déployé dans le cadre des modèles haute disponibilité.

   L'exemple suivant montre un fichier de configuration terminé qui définit un cluster à haute disponibilité pour SAP NetWeaver. Le cluster gère les adresses IP virtuelles à l'aide d'un équilibreur de charge réseau passthrough interne.

   Terraform déploie les ressources Google Cloud définies dans le fichier de configuration, puis les scripts prennent le relais pour configurer le système d'exploitation et configurer le cluster Linux haute disponibilité.

   Pour plus de clarté, les commentaires du fichier de configuration sont omis dans l'exemple.

      # ...
        module "sap_nw_ha" {
        source = "https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_nw_ha/sap_nw_ha_module.zip"
      #
      # By default, this source file uses the latest release of the terraform module
      # for SAP on Google Cloud.  To fix your deployments to a specific release
      # of the module, comment out the source argument above and uncomment the source argument below.
      #
      # source = "https://storage.googleapis.com/cloudsapdeploy/terraform/202201240926/terraform/sap_nw_ha/sap_nw_ha_module.zip"
      #
      # ...
      #
      project_id = "example-project-123456"
      machine_type = "n2-highmem-32"
      network = "example-network"
      subnetwork = "example-subnet-us-central1"
      linux_image = "sles-15-sp3-sap"
      linux_image_project = "suse-sap-cloud"
   
      sap_primary_instance = "example-nw1"
      sap_primary_zone = "us-central1-a"
   
      sap_secondary_instance = "example-nw2"
      sap_secondary_zone = "us-central1-c"
   
      nfs_path = "10.223.55.130:/pr1_nw"
   
      sap_sid = "PR1"
      # ...
   }

5. Initialisez votre répertoire de travail actuel et téléchargez les fichiers de modules et le plug-in du fournisseur Terraform pour Google Cloud :

   terraform init

   La commande terraform init prépare votre répertoire de travail pour d'autres commandes Terraform.

   Pour forcer l'actualisation du plug-in du fournisseur et des fichiers de configuration dans votre répertoire de travail, spécifiez l'option --upgrade. Si l'option --upgrade est omise et que vous n'apportez aucune modification à votre répertoire de travail, Terraform utilise les copies mises en cache localement, même si latest est spécifié dans l'URL source.

   terraform init --upgrade 

6. Vous pouvez également créer le plan d'exécution Terraform :

   terraform plan

   La commande terraform plan affiche les modifications requises par votre configuration actuelle. Si vous ignorez cette étape, la commande terraform apply crée automatiquement un plan et vous invite à l'approuver.

7. Appliquez le plan d'exécution :

   terraform apply

   Lorsque vous êtes invité à approuver les actions, saisissez yes.

   La commande terraform apply configure l'infrastructure Google Cloud, puis donne le contrôle à un script qui configure le cluster HA en fonction des arguments définis dans le fichier de configuration Terraform.

   Lorsque Terraform a le contrôle, les messages d'état sont écrits dans Cloud Shell. Une fois les scripts appelés, les messages d'état sont écrits dans Logging et peuvent être consultés dans la console Google Cloud, comme décrit dans la section Vérifier les journaux Logging.

   La durée d'exécution peut varier, mais l'ensemble du processus prend généralement moins de 30 minutes.

Vérifier le déploiement de votre système SAP NetWeaver à haute disponibilité

La vérification d'un cluster à haute disponibilité SAP NetWeaver implique plusieurs procédures différentes :

• Vérifier les journaux
• Vérifier la configuration de la VM

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 :

   Explorateur de journaux

   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. Ouvrez Cloud Shell.

        Accéder à Cloud Shell

     3. Accédez à votre répertoire de travail et supprimez le déploiement pour nettoyer les VM et les disques persistants de l'installation ayant échoué :

        terraform destroy

        Lorsque vous êtes invité à approuver l'action, saisissez yes.

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

Vérifier la configuration de la VM

1. Une fois l'instance de VM déployée sans erreur, connectez-vous à chaque VM à l'aide du protocole SSH. Pour ce faire, vous pouvez cliquer sur le bouton "SSH" de votre instance de VM depuis la page VM Instances (Instances de VM) de Compute Engine, ou bien utiliser la méthode SSH de votre choix.

2. Connectez-vous en tant qu'utilisateur racine.

   sudo su -

3. À l'invite de commande, saisissez df -h. Assurez-vous d'obtenir un résultat comprenant les répertoires /usr/sap, par exemple /usr/sap/trans.

   example-nw1:~ # df -h
     Filesystem                             Size  Used Avail Use% Mounted on
     ...
     /dev/mapper/vg_usrsap-vol              8.0G   41M  8.0G   1% /usr/sap
     /dev/mapper/vg_sapmnt-vol              8.0G   41M  8.0G   1% /sapmnt
     10.233.55.130:/pr1_nw/sapmntPR1       1007G     0  956G   0% /sapmnt/PR1
     10.223.55.130:/pr1_nw/usrsaptrans     1007G     0  956G   0% /usr/sap/trans
     10.223.55.130:/pr1_nw/usrsapPR1       1007G     0  956G   0% /usr/sap/PR1
     ...
     

   autofs est automatiquement configuré lors du déploiement 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, qui est également configuré lors du déploiement.

4. Vérifiez l'état du nouveau cluster en saisissant la commande d'état:

   crm status

   Un résultat semblable à l'exemple suivant devrait s'afficher, dans lequel les deux instances de VM sont démarrées, et où example-nw1 correspond à l'instance principale active :

   example-nw1:~ # crm status
   Cluster Summary:
     * Stack: corosync
     * Current DC: example-nw1 (version 2.0.4+20200616.2deceaa3a-3.6.1-2.0.4+20200616.2deceaa3a) - partition with quorum
     * Last updated: Fri Jun 18 05:47:48 2021
     * Last change:  Fri Jun 18 05:41:32 2021 by root via cibadmin on example-nw1
     * 2 nodes configured
     * 8 resource instances configured
   Node List:
     * Online: [ example-nw1 example-nw2 ]
   Full List of Resources:
     * fence-PR1-example-nw1     (stonith:fence_gce):           Started example-nw2
     * fence-PR1-example-nw2     (stonith:fence_gce):           Started example-nw1
     * file-system-PR1-ASCS00    (ocf::heartbeat:Filesystem):      Started example-nw1
     * file-system-PR1-ERS10     (ocf::heartbeat:Filesystem):      Started example-nw2
     * health-check-PR1-ASCS00   (ocf::heartbeat:anything):        Started example-nw1
     * health-check-PR1-ERS10    (ocf::heartbeat:anything):        Started example-nw2
     * vip-PR1-ASCS00      (ocf::heartbeat:IPaddr2):             Started example-nw1
     * vip-PR1-ERS10       (ocf::heartbeat:IPaddr2):             Started example-nw2

   Si vous utilisez une configuration Simple Mount (Installation simple), un résultat semblable à l'exemple suivant s'affiche:

   Stack: corosync
   Current DC: example-nw1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum
   Last updated: Wed Sep 26 19:10:10 2024
   Last change: Tue Sep 25 23:48:35 2024 by root via cibadmin on example-nw1
   2 nodes configured
   8 resource instances configured
   Node List:
     * Online: [ example-nw1 example-nw2 ]
   Full list of resources:
    * fence-PR1-example-nw1     (stonith:fence_gce):           Started example-nw2
     * fence-PR1-example-nw2     (stonith:fence_gce):           Started example-nw1
     * health-check-PR1-ASCS00   (ocf::heartbeat:anything):        Started example-nw1
     * health-check-PR1-ERS10    (ocf::heartbeat:anything):        Started example-nw2
     * vip-PR1-ASCS00      (ocf::heartbeat:IPaddr2):             Started example-nw1
     * vip-PR1-ERS10       (ocf::heartbeat:IPaddr2):             Started example-nw2

5. Testez la configuration de l'équilibreur de charge ASCS et ERS à l'aide de l'utilitaire socat :

   1. Sur chaque instance de VM, démarrez temporairement un processus socat qui renvoie son propre nom d'hôte :

      socat TCP-LISTEN:80,bind=0.0.0.0,fork,reuseaddr,crlf SYSTEM:"echo HTTP/1.0 200; echo Content-Type\: text/plain; echo; echo $(hostname)" & 

   2. Sur chaque nœud, utilisez curl et essayez d'atteindre les adresses IP et les noms d'hôtes suivants. Les adresses IP et les noms d'hôte se trouvent dans /etc/hosts.

      • 127.0.0.1
      • localhost
      • ASCS_VIRTUAL_HOST_NAME
      • ASCS_IP_ADDRESS
      • ERS_VIRTUAL_HOST_NAME
      • ERS_IP_ADDRESS
      • Nom d'adresse IP virtuelle SCS spécifié pour le paramètre scs_vip_name
      • Adresse IP virtuelle SCS, spécifiée pour le paramètre scs_vip_address
      • Nom d'adresse IP virtuelle ERS spécifié pour le paramètre ers_vip_name
      • Adresse IP virtuelle ERS, spécifiée pour le paramètre ers_vip_address

   Voici un exemple de résultat d'un tel test :

   example-nw1:~ # cat /etc/hosts
   ...
   10.128.1.182 example-nw1.c.myproject.internal example-nw1
   10.128.1.169 example-nw2.c.myproject.internal example-nw2
   10.128.1.46 pr1-scs-vip.c.myproject.internal pr1-scs-vip
   10.128.0.75 pr1-ers-vip.c.myproject.internal pr1-ers-vip
   example-nw1:~ # curl 127.0.0.1
   example-nw1
   example-nw1:~ # curl localhost
   example-nw1
   example-nw1:~ # curl example-nw1
   example-nw1
   example-nw1:~ # curl 10.128.1.182
   example-nw1
   example-nw1:~ # curl example-nw2
   example-nw2
   example-nw1:~ # curl 10.128.1.169
   example-nw2
   example-nw1:~ # curl pr1-scs-vip
   example-nw1
   example-nw1:~ # curl 10.128.1.46
   example-nw1
   example-nw1:~ # curl pr1-ers-vip
   example-nw2
   example-nw1:~ # curl 10.128.0.75
   example-nw2

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

1. Corrigez les erreurs.

2. Ouvrez Cloud Shell.

   Accéder à Cloud Shell

3. Accédez au répertoire contenant le fichier de configuration Terraform.

4. Supprimez le déploiement :

   terraform destroy

   Lorsque vous êtes invité à approuver l'action, saisissez yes.

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

Vérifier l'installation de l'agent Google Cloud pour SAP

Après avoir déployé une VM et installé le système SAP, vérifiez que l'agent Google Cloud pour SAP fonctionne correctement.

Vérifier que l'agent Google Cloud pour SAP est en cours d'exécution

Pour vérifier que l'agent est en cours d'exécution, procédez comme suit :

1. Établissez une connexion SSH avec votre instance Compute Engine.

2. Exécutez la commande suivante :

   systemctl status google-cloud-sap-agent

   Si l'agent fonctionne correctement, la sortie contient active (running). Exemple :

   google-cloud-sap-agent.service - Google Cloud Agent for SAP
   Loaded: loaded (/usr/lib/systemd/system/google-cloud-sap-agent.service; enabled; vendor preset: disabled)
   Active:  active (running)  since Fri 2022-12-02 07:21:42 UTC; 4 days ago
   Main PID: 1337673 (google-cloud-sa)
   Tasks: 9 (limit: 100427)
   Memory: 22.4 M (max: 1.0G limit: 1.0G)
   CGroup: /system.slice/google-cloud-sap-agent.service
          └─1337673 /usr/bin/google-cloud-sap-agent
   

Si l'agent n'est pas en cours d'exécution, redémarrez-le.

Vérifier que l'agent hôte SAP reçoit les métriques

Pour vérifier que les métriques d'infrastructure sont collectées par l'agent Google Cloud pour SAP et envoyées correctement à l'agent hôte SAP, procédez comme suit :

1. Dans votre système SAP, saisissez la transaction ST06.

2. Dans le volet de synthèse, vérifiez la disponibilité et le contenu des champs suivants pour vous assurer de la configuration de façon correcte et complète de l'infrastructure de surveillance SAP et Google :

   • Fournisseur cloud : Google Cloud Platform
   • Accès à la surveillance améliorée : TRUE
   • Détails de la surveillance améliorée : ACTIVE

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 :

   # crm configure property 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

   Si vous utilisez une configuration Simple Mount, exécutez plutôt les commandes suivantes sur les deux serveurs en tant que root. Spécifiez 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
   # chown SID_LCadm:sapsys /sapmnt/SID -R
   # chown SID_LCadm:sapsys /usr/sap/trans -R
   # chown SID_LCadm:sapsys /usr/sap/SID -R
   # chown SID_LCadm:sapsys /usr/sap/SID/SYS

   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 :

   # crm_standby -v on -N ${HOSTNAME};

   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 :

   # crm status

   Le résultat ressemble à celui de l'exemple ci-dessous.

   Stack: corosync
    Current DC: nw-ha-vm-1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum
    Last updated: Thu May 27 17:45:16 2021
    Last change: Thu May 27 17:45:09 2021 by root via crm_attribute on nw-ha-vm-2
   
    2 nodes configured
    8 resource instances configured
   
    Node nw-ha-vm-2: standby
    Online: [ nw-ha-vm-1 ]
   
    Full list of resources:
   
     fencing-rsc-nw-aha-vm-1        (stonith:fence_gce):    Stopped
     fencing-rsc-nw-aha-vm-2        (stonith:fence_gce):    Started nw-ha-vm-1
     filesystem-rsc-nw-aha-scs      (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
     filesystem-rsc-nw-aha-ers      (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
     health-check-rsc-nw-ha-scs     (ocf::heartbeat:anything):      Started nw-ha-vm-1
     health-check-rsc-nw-ha-ers     (ocf::heartbeat:anything):      Started nw-ha-vm-1
     vip-rsc-nw-aha-scs     (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
     vip-rsc-nw-aha-ers     (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
   

   Si vous utilisez une configuration Simple Mount, le résultat ressemble à ceci:

   Stack: corosync
    Current DC: nw-ha-vm-1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum
    Last updated: Wed Sep 26 19:30:10 2024
    Last change: Tue Sep 25 23:58:35 2024 by root via crm_attribute on nw-ha-vm-2
   
    2 nodes configured
    8 resource instances configured
   
    Node nw-ha-vm-2: standby
    Online: [ nw-ha-vm-1 ]
   
    Full list of resources:
   
     fencing-rsc-nw-aha-vm-1        (stonith:fence_gce):    Stopped
     fencing-rsc-nw-aha-vm-2        (stonith:fence_gce):    Started nw-ha-vm-1
     health-check-rsc-nw-ha-scs     (ocf::heartbeat:anything):      Started nw-ha-vm-1
     health-check-rsc-nw-ha-ers     (ocf::heartbeat:anything):      Started nw-ha-vm-1
     vip-rsc-nw-aha-scs     (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
     vip-rsc-nw-aha-ers     (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
   

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 :

   # crm_standby -v off -N ${HOSTNAME}; # On SECONDARY

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 :

   # crm_standby -v on -N ${HOSTNAME};

   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 :

   # crm 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 :

   # crm_standby -v off -N ${HOSTNAME};

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

      Pour plus d'informations, consultez le document SUSE Désactiver les services systemd des instances SAP ASCS et ERS.

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()

Activer sapping et sappong

Étant donné que les procédures de démarrage et d'arrêt du cluster sont gérées par Pacemaker, vous devez vous assurer que sapstartsrv ne démarre pas automatiquement au démarrage du système. Lors du démarrage du système, sapping s'exécute avant sapinit, ce qui masque les fichiers sapservices. Une fois sapinit terminé, sappong affiche les fichiers sapservices.

Pour activer ce flux, vous devez activer les services systemd sapping et sappong à l'aide des commandes suivantes:

# systemctl enable sapping sappong
# systemctl status sapping sappong

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. Activez le package sap-suse-cluster-connector en ajoutant les lignes suivantes aux profils d'instances ASCS et ERS :

   #-----------------------------------------------------------------------
   # SUSE HA library
   #-----------------------------------------------------------------------
   service/halib = $(DIR_CT_RUN)/saphascriptco.so
   service/halib_cluster_connector = /usr/bin/sap_suse_cluster_connector
   

4. 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.

5. 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) ...

Ajouter l'utilisateur sidadm au groupe d'utilisateurs haclient

Lorsque vous avez installé le sap-suse-cluster-connector, le processus d'installation a créé un groupe d'utilisateurs haclient. Pour permettre à l'utilisateur SID_LCadm de travailler avec le cluster, ajoutez-le au groupe d'utilisateurs haclient.

1. Sur les deux serveurs, ajoutez l'utilisateur SID_LCadm au groupe d'utilisateurs haclient :

   # usermod -aG haclient SID_LCadm

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 :

   # crm configure property maintenance-mode="true"

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

   # crm status

   Si le cluster est en mode de maintenance, l'état inclut les lignes suivantes :

                 *** Resource management is DISABLED ***
   The cluster will not attempt to start, stop or recover services

3. Si vous utilisez une configuration Simple Mount (Installation simple), créez les ressources de cluster sapstartsrv pour les services ASCS et ERS. Si vous n'utilisez pas de configuration Simple Mount, ignorez cette étape.

   1. Pour ASCS, créez un fichier de configuration nommé sapstartsrv_scs.txt avec le contenu suivant:

      primitive rsc_SAPStartSrv_SID_ASCSINSTANCENUMBER ocf:suse:SAPStartSrv \
      params InstanceName=SID_ASCSINSTANCE_NUMBER_ASCS_VIRTUAL_HOSTNAME

   2. Pour charger la configuration de l'ASCS, exécutez la commande suivante:

      # crm configure load update sapstartsrv_scs.txt

   3. Pour ERS, créez un fichier de configuration nommé sapstartsrv_ers.txt avec le contenu suivant:

      primitive rsc_SAPStartSrv_SID_ERSINSTANCENUMBER ocf:suse:SAPStartSrv \
      params InstanceName=SID_ERSINSTANCE_NUMBER_ERS_VIRTUAL_HOSTNAME

   4. Pour charger la configuration de l'ERS, exécutez la commande suivante:

      # crm configure load update sapstartsrv_ers.txt

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

   ENSA1

   1. 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.

      # crm configure primitive ASCS_INSTANCE_RESOURCE SAPInstance \
        operations \$id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
           START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" \
           AUTOMATIC_RECOVER=false \
        meta resource-stickiness=5000 failure-timeout=60 \
           migration-threshold=1 priority=10

      Si vous utilisez une configuration Simple Mount, exécutez plutôt la commande suivante:

      # crm configure primitive ASCS_INSTANCE_RESOURCE SAPInstance \
        operations \$id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
           START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" \
           AUTOMATIC_RECOVER=false MINIMAL_PROBE=true \
        meta resource-stickiness=5000 failure-timeout=60 \
           migration-threshold=1 priority=10

   2. 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.

      # crm configure primitive ERS_INSTANCE_RESOURCE SAPInstance \
        operations \$id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME  \
           START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" \
           AUTOMATIC_RECOVER=false IS_ERS=true \
        meta priority=1000

      Si vous utilisez une configuration Simple Mount, exécutez plutôt la commande suivante:

      # crm configure primitive ERS_INSTANCE_RESOURCE SAPInstance \
        operations \$id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME  \
           START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" \
           AUTOMATIC_RECOVER=false MINIMAL_PROBE=true IS_ERS=true \
        meta priority=1000

   3. Confirmez la configuration nouvellement créée :

      # crm configure show ASCS_INSTANCE_RESOURCE ERS_INSTANCE_RESOURCE

      Le résultat ressemble à l'exemple suivant:

      primitive ASCS_INSTANCE_RESOURCE SAPInstance \
      operations $id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
      op monitor interval=11 timeout=60 on-fail=restart \
      params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false \
      meta resource-stickiness=5000 failure-timeout=60 migration-threshold=1 priority=10
      
      
      primitive ERS_INSTANCE_RESOURCE SAPInstance \
      operations $id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
      op monitor interval=11 timeout=60 on-fail=restart \
      params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false IS_ERS=true \
      meta priority=1000
      

      Si vous utilisez une configuration Simple Mount (Installation simple), le résultat ressemble à l'exemple suivant:

      primitive ASCS_INSTANCE_RESOURCE SAPInstance \
      operations $id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
      op monitor interval=11 timeout=60 on-fail=restart \
      params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false MINIMAL_PROBE=true \
      meta resource-stickiness=5000 failure-timeout=60 migration-threshold=1 priority=10
      
      
      primitive ERS_INSTANCE_RESOURCE SAPInstance \
      operations $id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
      op monitor interval=11 timeout=60 on-fail=restart \
      params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false MINIMAL_PROBE=true IS_ERS=true \
      meta priority=1000
      

   ENSA2

   1. 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.

      # crm configure primitive ASCS_INSTANCE_RESOURCE SAPInstance \
        operations \$id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
           START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" \
           AUTOMATIC_RECOVER=false \
        meta resource-stickiness=5000 failure-timeout=60

      Si vous utilisez une configuration Simple Mount, exécutez plutôt la commande suivante:

      # crm configure primitive ASCS_INSTANCE_RESOURCE SAPInstance \
        operations \$id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
           START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" \
           AUTOMATIC_RECOVER=false MINIMAL_PROBE=true \
        meta resource-stickiness=5000 failure-timeout=60

   2. 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.

      # crm configure primitive ERS_INSTANCE_RESOURCE SAPInstance \
        operations \$id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME  \
           START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" \
           AUTOMATIC_RECOVER=false IS_ERS=true

      Si vous utilisez une configuration Simple Mount, exécutez plutôt la commande suivante:

      # crm configure primitive ERS_INSTANCE_RESOURCE SAPInstance \
        operations \$id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME  \
           START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" \
           AUTOMATIC_RECOVER=false IS_ERS=true MINIMAL_PROBE=true \
           meta priority=1000

   3. Confirmez la configuration nouvellement créée :

      # crm configure show ASCS_INSTANCE_RESOURCE ERS_INSTANCE_RESOURCE

      Le résultat ressemble à celui de l'exemple ci-dessous:

      primitive ASCS_INSTANCE_RESOURCE SAPInstance \
      operations $id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
      op monitor interval=11 timeout=60 on-fail=restart \
      params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false \
      meta resource-stickiness=5000 failure-timeout=60
      
      
      primitive ERS_INSTANCE_RESOURCE SAPInstance \
      operations $id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
      op monitor interval=11 timeout=60 on-fail=restart \
      params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false IS_ERS=true \
      

      Si vous utilisez une configuration Simple Mount, le résultat ressemble à ceci:

      primitive ASCS_INSTANCE_RESOURCE SAPInstance \
      operations $id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
      op monitor interval=11 timeout=60 on-fail=restart \
      params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false MINIMAL_PROBE=true \
      meta resource-stickiness=5000 failure-timeout=60 \
      migration-threshold=1 priority=10
      
      
      primitive ERS_INSTANCE_RESOURCE SAPInstance \
      operations $id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
      op monitor interval=11 timeout=60 on-fail=restart \
      params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false MINIMAL_PROBE=true IS_ERS=true \
      meta priority=1000

Configurer les groupes de ressources et les contraintes d'emplacement

1. Regroupez les ressources ASCS et ERS. Vous pouvez afficher les noms de toutes vos ressources précédemment définies en saisissant la commande crm resource status :

   • # crm configure group ASCS_RESOURCE_GROUP ASCS_FILE_SYSTEM_RESOURCE \
       ASCS_HEALTH_CHECK_RESOURCE ASCS_VIP_RESOURCE \
       ASCS_INSTANCE_RESOURCE \
       meta resource-stickiness=3000

     Si vous utilisez une configuration Simple Mount (Installation simple), exécutez plutôt la commande suivante:

     # crm configure group ASCS_RESOURCE_GROUP ASCS_SAPSTARTSRV_RESOURCE \
       ASCS_HEALTH_CHECK_RESOURCE ASCS_VIP_RESOURCE \
       ASCS_INSTANCE_RESOURCE \
       meta resource-stickiness=3000

     Remplacez les éléments suivants :
     • 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_LC_ASCSINSTANCE_NUMBER_group. Par exemple, nw1_ASCS00_group.
     • ASCS_FILE_SYSTEM_RESOURCE : spécifiez le nom de la ressource de cluster que vous avez défini précédemment pour le système de fichiers ASCS. Cette variable d'espace réservé n'est pas applicable lorsque vous utilisez une configuration de montage simple.
     • ASCS_SAPSTARTSRV_RESOURCE: spécifiez le nom de la ressource de cluster que vous avez défini précédemment pour le service ASCS "sapstartsrv". Cette variable d'espace réservé ne s'applique que lorsque vous utilisez une configuration de montage simple.
     • ASCS_HEALTH_CHECK_RESOURCE : spécifiez le nom de la ressource de cluster que vous avez défini précédemment pour la vérification d'état ASCS.
     • ASCS_VIP_RESOURCE : spécifiez le nom de la ressource de cluster que vous avez défini précédemment pour l'adresse IP virtuelle ASCS.
     • ASCS_INSTANCE_RESOURCE : spécifiez le nom de la ressource de cluster que vous avez défini précédemment pour l'instance ASCS.
   • # crm configure group ERS_RESOURCE_GROUP ERS_FILE_SYSTEM_RESOURCE \
       ERS_HEALTH_CHECK_RESOURCE ERS_VIP_RESOURCE \
       ERS_INSTANCE_RESOURCE

     Si vous utilisez une configuration Simple Mount (Installation simple), exécutez plutôt la commande suivante:

     # crm configure group ERS_RESOURCE_GROUP ERS_SAPSTARTSRV_RESOURCE \
       ERS_HEALTH_CHECK_RESOURCE ERS_VIP_RESOURCE \
       ERS_INSTANCE_RESOURCE

     Remplacez les éléments suivants :
     • 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, nw1_ERS10_group.
     • ERS_SAPSTARTSRV_RESOURCE: spécifiez le nom de la ressource de cluster que vous avez défini précédemment pour le service ERS "sapstartsrv". Cette variable d'espace réservé ne s'applique que lorsque vous utilisez une configuration de montage simple.
     • ERS_FILE_SYSTEM_RESOURCE : spécifiez le nom de la ressource de cluster que vous avez défini précédemment pour le système de fichiers ERS. Cette variable d'espace réservé n'est pas applicable lorsque vous utilisez une configuration de montage simple.
     • ERS_HEALTH_CHECK_RESOURCE : spécifiez le nom de la ressource de cluster que vous avez défini précédemment pour la vérification d'état ERS.
     • ERS_VIP_RESOURCE : spécifiez le nom de la ressource de cluster que vous avez défini précédemment pour l'adresse IP virtuelle ERS.
     • ERS_INSTANCE_RESOURCE : spécifiez le nom de la ressource de cluster que vous avez défini précédemment pour l'instance ERS.

2. Confirmez la configuration nouvellement créée :

   # crm configure show type:group

   Le résultat ressemble à l'exemple suivant:

   group ERS_RESOURCE_GROUP ERS_FILE_SYSTEM_RESOURCE ERS_HEALTH_CHECK_RESOURCE ERS_VIP_RESOURCE ERS_INSTANCE_RESOURCE
   group ASCS_RESOURCE_GROUP ASCS_FILE_SYSTEM_RESOURCE ASCS_HEALTH_CHECK_RESOURCE ASCS_VIP_RESOURCE ASCS_INSTANCE_RESOURCE \
           meta resource-stickiness=3000

   Si vous utilisez une configuration Simple Mount, le résultat ressemble à l'exemple suivant:

   group ERS_RESOURCE_GROUP ERS_SAPSTARTSRV_RESOURCE ERS_HEALTH_CHECK_RESOURCE ERS_VIP_RESOURCE ERS_INSTANCE_RESOURCE
   group ASCS_RESOURCE_GROUP ASCS_SAPSTARTSRV_RESOURCE ASCS_HEALTH_CHECK_RESOURCE ASCS_VIP_RESOURCE ASCS_INSTANCE_RESOURCE

3. Créez les contraintes de colocation :

   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 :

      # crm configure colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP

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

      # crm configure location LOC_SCS_SID_FAILOVER_TO_ERS ASCS_INSTANCE_RESOURCE \
      rule 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 :

      # crm configure order ORD_SAP_SID_FIRST_START_ASCS \
       Optional: ASCS_INSTANCE_RESOURCE:start \
       ERS_INSTANCE_RESOURCE:stop symmetrical=false

   4. Confirmez la configuration nouvellement créée :

      # crm configure show type:colocation type:location type:order

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

      order ORD_SAP_SID_FIRST_START_ASCS Optional: ASCS_INSTANCE_RESOURCE:start ERS_INSTANCE_RESOURCE:stop symmetrical=false
      colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP
      location LOC_SCS_SID_FAILOVER_TO_ERS ASCS_INSTANCE_RESOURCE \
      rule 2000: runs_ers_SID eq 1

   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 :

      # crm configure colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP

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

      # crm configure order ORD_SAP_SID_FIRST_START_ASCS \
       Optional: ASCS_INSTANCE_RESOURCE:start \
       ERS_INSTANCE_RESOURCE:stop symmetrical=false

   3. Confirmez la configuration nouvellement créée :

      # crm configure show type:colocation type:order

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

      colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP
      order ORD_SAP_SID_FIRST_START_ASCS  Optional: ASCS_INSTANCE_RESOURCE:start ERS_INSTANCE_RESOURCE:stop symmetrical=false

4. Désactivez le mode de maintenance.

   # crm configure property maintenance-mode="false"

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 :

   # crm status

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

   Cluster Summary:
     * Stack: corosync
     * Current DC: nw-ha-vm-2 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum
     * Last updated: Thu May 20 16:58:46 2021
     * Last change:  Thu May 20 16:57:31 2021 by ahaadm via crm_resource on nw-ha-vm-2
     * 2 nodes configured
     * 10 resource instances configured
   
   Node List:
     * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
   Active Resources:
     * fencing-rsc-nw-aha-vm-1     (stonith:fence_gce):     Started nw-ha-vm-2
     * fencing-rsc-nw-aha-vm-2     (stonith:fence_gce):     Started nw-ha-vm-1
     * Resource Group: ascs-aha-rsc-group-name:
       * filesystem-rsc-nw-aha-ascs (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
       * health-check-rsc-nw-ha-ascs        (ocf::heartbeat:anything):       Started nw-ha-vm-1
       * vip-rsc-nw-aha-ascs        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-1
       * ascs-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-1
     * Resource Group: ers-aha-rsc-group-name:
       * filesystem-rsc-nw-aha-ers (ocf::heartbeat:Filesystem):     Started nw-ha-vm-2
       * health-check-rsc-nw-ha-ers        (ocf::heartbeat:anything):       Started nw-ha-vm-2
       * vip-rsc-nw-aha-ers        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-2
       * ers-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-2

   Si vous utilisez une configuration Simple Mount (Installation simple), le résultat ressemble à l'exemple suivant:

   Cluster Summary:
     * Stack: corosync
     * Current DC: nw-ha-vm-2 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum
     * Last updated: Thu Sep 20 19:44:26 2024
     * Last change:  Thu Sep 20 19:53:41 2024 by ahaadm via crm_resource on nw-ha-vm-2
     * 2 nodes configured
     * 10 resource instances configured
   
   Node List:
     * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
   Active Resources:
     * fencing-rsc-nw-aha-vm-1     (stonith:fence_gce):     Started nw-ha-vm-2
     * fencing-rsc-nw-aha-vm-2     (stonith:fence_gce):     Started nw-ha-vm-1
     * Resource Group: ascs-aha-rsc-group-name:
       * SAPStartSrv-rsc-nw-aha-ascs (ocf::heartbeat:SAPStartSrv):     Started nw-ha-vm-1
       * health-check-rsc-nw-ha-ascs        (ocf::heartbeat:anything):       Started nw-ha-vm-1
       * vip-rsc-nw-aha-ascs        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-1
       * ascs-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-1
     * Resource Group: ers-aha-rsc-group-name:
       * SAPStartSrv-rsc-nw-aha-ers (ocf::heartbeat:SAPStartSrv):     Started nw-ha-vm-2
       * health-check-rsc-nw-ha-ers        (ocf::heartbeat:anything):       Started nw-ha-vm-2
       * vip-rsc-nw-aha-ers        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-2
       * ers-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started 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 :

   20.05.2021 01:33:25
   HAGetFailoverConfig
   OK
   HAActive: TRUE
   HAProductVersion: SUSE Linux Enterprise Server for SAP Applications 15 SP2
   HASAPInterfaceVersion: SUSE Linux Enterprise Server for SAP Applications 15 SP2 (sap_suse_cluster_connector 3.1.2)
   HADocumentation: https://www.suse.com/products/sles-for-sap/resource-library/sap-best-practices/
   HAActiveNode: nw-ha-vm-1
   HANodes: nw-ha-vm-1, nw-ha-vm-2

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 :

   20.05.2021 01:37:19
   HACheckConfig
   OK
   state, category, description, comment
   SUCCESS, SAP CONFIGURATION, Redundant ABAP instance configuration, 0 ABAP instances detected
   SUCCESS, SAP CONFIGURATION, Redundant Java instance configuration, 0 Java 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 (vh-ascs-aha_AHA_00), SAPInstance includes is-ers patch
   SUCCESS, SAP CONFIGURATION, Enqueue replication (vh-ascs-aha_AHA_00), Enqueue replication enabled
   SUCCESS, SAP STATE, Enqueue replication state (vh-ascs-aha_AHA_00), Enqueue replication active

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 crm 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.

   Cluster Summary:
   * Stack: corosync
   * Current DC: nw-ha-vm-2 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum
   * Last updated: Fri May 21 22:31:32 2021
   * Last change:  Thu May 20 20:36:36 2021 by ahaadm via crm_resource on nw-ha-vm-1
   * 2 nodes configured
   * 10 resource instances configured
   
   Node List:
   * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
   Full List of Resources:
   * fencing-rsc-nw-aha-vm-1     (stonith:fence_gce):     Started nw-ha-vm-2
   * fencing-rsc-nw-aha-vm-2     (stonith:fence_gce):     Started nw-ha-vm-1
   * Resource Group: scs-aha-rsc-group-name:
     * filesystem-rsc-nw-aha-scs (ocf::heartbeat:Filesystem):     Started nw-ha-vm-2
     * health-check-rsc-nw-ha-scs        (ocf::heartbeat:anything):       Started nw-ha-vm-2
     * vip-rsc-nw-aha-scs        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-2
     * scs-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-2
   * Resource Group: ers-aha-rsc-group-name:
     * filesystem-rsc-nw-aha-ers (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
     * health-check-rsc-nw-ha-ers        (ocf::heartbeat:anything):       Started nw-ha-vm-1
     * vip-rsc-nw-aha-ers        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-1
     * ers-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-1

   Si vous utilisez une configuration Simple Mount (Installation simple), un résultat semblable à celui-ci s'affiche:

   Cluster Summary:
    * Stack: corosync
    * Current DC: nw-ha-vm-2 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum
    * Last updated: Wed Sep 26 19:10:10 2024
    * Last change:  Tue Sep 25 23:48:35 2024 by ahaadm via crm_resource on nw-ha-vm-1
    * 2 nodes configured
    * 10 resource instances configured
   
   Node List:
    * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
   Full List of Resources:
    * fencing-rsc-nw-aha-vm-1     (stonith:fence_gce):     Started nw-ha-vm-2
    * fencing-rsc-nw-aha-vm-2     (stonith:fence_gce):     Started nw-ha-vm-1
    * Resource Group: scs-aha-rsc-group-name:
      * SAPStartSrv-rsc-nw-aha-scs (ocf::heartbeat:SAPStartSrv):     Started nw-ha-vm-2
      * health-check-rsc-nw-ha-scs        (ocf::heartbeat:anything):       Started nw-ha-vm-2
      * vip-rsc-nw-aha-scs        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-2
      * scs-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-2
    * Resource Group: ers-aha-rsc-group-name:
      * SAPStartSrv-rsc-nw-aha-ers (ocf::heartbeat:SAPStartSrv):     Started nw-ha-vm-1
      * health-check-rsc-nw-ha-ers        (ocf::heartbeat:anything):       Started nw-ha-vm-1
      * vip-rsc-nw-aha-ers        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-1
      * ers-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-1
   

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 :

   # crm 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é SLES.

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 :

• Bonnes pratiques SUSE

• 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.