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

Ce guide explique comment déployer et configurer un cluster SUSE Linux Enterprise Server (SLES) à haute disponibilité (HA) et aux performances optimisées dans un système SAP NetWeaver.

Ce guide comprend les étapes suivantes :

  • Configurer l'équilibrage de charge TCP/UDP interne pour réacheminer le trafic en cas de défaillance
  • Configurer un cluster Pacemaker sur SLES 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.

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.

Présentation d'un cluster Linux à haute disponibilité pour un système SAP NetWeaver à nœud unique.

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

  • Deux VM hôtes, l'une avec un service central SAP actif et l'autre avec un serveur de mise en file d'attente autonome actif
  • 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.

Prérequis

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

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

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 Monitoring de Google. 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 :

  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. Seuls les minuscules, les chiffres et le tiret (-) sont autorisés.

    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 l'élément suivant :

    • 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 d'autres 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.

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.

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

  1. Dans Cloud Console, accédez à la page Règles de pare-feu.

    Ouvrir la page Règles de 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 au SDK Cloud.

  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-sles15sp1.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
    nom Chaîne Nom arbitraire qui identifie la ressource de déploiement définie par l'ensemble de propriétés suivant.
    saisir Chaîne

    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 Chaîne 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 Chaîne 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 Chaîne 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 Chaîne 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 Chaîne 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/sles-15-sp1-sap. Pour obtenir la liste des familles d'images disponibles, consultez la page Images dans Cloud Console.
    linuxImageProject Chaîne 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 suse-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 Chaîne

    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" mais pas de tag réseau, veillez à fournir un autre moyen d'accès à Internet.

    serviceAccount Chaîne

    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 : sap-ha-example@example-project-123456.iam.gserviceaccount.com

    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.
    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/sles-15-sp2-sap
    linuxImageProject: suse-sap-cloud
    usrsapSize: 15
    sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
- 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/sles-15-sp2-sap
    linuxImageProject: suse-sap-cloud
    usrsapSize: 15
    sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com

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

Les étapes suivantes utilisent Cloud Logging, ce qui peut entraîner des frais. Pour en savoir plus, consultez la section sur les tarifs de Cloud Logging.

  1. Ouvrez Cloud Logging pour vérifier les erreurs et surveiller la progression de l'installation.

    Accéder à Stackdriver Logging

  2. Dans l'onglet Ressources, sélectionnez Global comme ressource de journalisation. Si INSTANCE DEPLOYMENT COMPLETE s'affiche pour une VM, le traitement de Deployment Manager est terminé pour cette VM.

    Affichage de Logging

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.

      Bouton SSH sur la page "Instances de VM" de Compute Engine

  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. Relancez le déploiement.

Mettre à jour le SDK Cloud

Le modèle Deployment Manager a installé le SDK Cloud sur les VM lors du déploiement. Mettez à jour le SDK Cloud pour vous assurer qu'il inclut toutes les dernières mises à jour.

  1. Connectez-vous en SSH à la VM principale.

  2. Mettez à jour le SDK Cloud :

    ~>  sudo gcloud components update
  3. Suivez les invites.

  4. Répétez ces étapes sur la VM secondaire.

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

  1. Sur chaque VM du cluster à haute disponibilité, activez le routage local.

    1. Connectez-vous en SSH à chaque VM de votre cluster planifié.
    2. Passez à l'utilisateur racine.
    3. Sur chaque machine, activez le routage local sur l'interface principale en exécutant la commande suivante. Si vous utilisez une interface différente de eth0, spécifiez cette interface dans la commande en lieu et place de eth0.

      echo net.ipv4.conf.eth0.accept_local=1 >> /etc/sysctl.conf
      sysctl -p

      La commande précédente écrit le paramètre dans le fichier de configuration.

  2. Sur chaque VM, créez un script de démarrage pour activer la communication backend vers backend :

    Cloud Console

    1. Accédez à la page Instances de VM dans Cloud Console.

      Accéder à la page Instances de VM

    2. Cliquez sur le nom de la VM principale.

    3. Sur la page Informations sur l'instance de VM, cliquez sur le bouton MODIFIER.

    4. Dans la section Métadonnées personnalisées, cliquez sur Ajouter un élément.

    5. Dans le champ Clé, spécifiez startup-script.

    6. Dans le champ Value (Valeur), collez le script bash suivant :

      #! /bin/bash
      # VM startup script
      
      nic0_mac="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/mac)"
      
      nic0_ip="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/ip)"
      
      for nic in $(ls /sys/class/net); do
      nic_addr=$(cat /sys/class/net/"${nic}"/address)
      if [ "$nic_addr" == "$nic0_mac" ]; then
        nic0_name="$nic"
        break
      fi
      done
      
      [[ -n $nic0_name ]] && [[ -n $nic0_ip ]] \
      && logger -i "gce-startup-script: INFO adding IP configuration for ILB client" \
      || logger -i "gce-startup-script: ERROR could not determine IP or interface name"
      
      if [ -n "$nic0_name" ]; then
      ip rule del from all lookup local
      ip rule add pref 0 from all iif "${nic0_name}" lookup local
      ip route add local "${nic0_ip}" dev "${nic0_name}" proto kernel \
        scope host src "${nic0_ip}" table main
      ip route add local 127.0.0.0/8 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add local 127.0.0.1 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add broadcast 127.0.0.0 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      ip route add broadcast 127.255.255.255 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      fi
    7. Cliquez sur Enregistrer au bas de la page.

    8. Redémarrez le serveur pour que le script de démarrage prenne effet.

      Lorsque vous avez terminé, vos métadonnées personnalisées doivent ressembler à l'exemple suivant :

      La capture d'écran montre "startup-script" et d'autres entrées dans la section "Métadonnées personnalisées" de la page d'informations sur la VM dans Cloud Console.

    9. Répétez les étapes précédentes pour le serveur secondaire.

    gcloud

    1. Dans Cloud Shell ou partout où le SDK Cloud est installé, utilisez la commande gcloud suivante avec le script de démarrage inclus afin d'ajouter un script de démarrage aux métadonnées d'instance pour chaque VM. Remplacez les variables par le nom et la zone de la VM avant de saisir la commande.

      gcloud compute instances add-metadata primary-vm-name \
      --zone=primary-vm-zone --metadata=startup-script='#! /bin/bash
      # VM startup script
      
      nic0_mac="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/mac)"
      
      nic0_ip="$(curl -H "Metadata-Flavor:Google" \
      --connect-timeout 5 --retry 5 --retry-max-time 60 \
      http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/ip)"
      
      for nic in $(ls /sys/class/net); do
      nic_addr=$(cat /sys/class/net/"${nic}"/address)
      if [ "$nic_addr" == "$nic0_mac" ]; then
        nic0_name="$nic"
        break
      fi
      done
      
      [[ -n $nic0_name ]] && [[ -n $nic0_ip ]] \
      && logger -i "gce-startup-script: INFO adding IP configuration for ILB client" \
      || logger -i "gce-startup-script: ERROR could not determine IP or interface name"
      
      if [ -n "$nic0_name" ]; then
      ip rule add pref 0 from all iif "${nic0_name}" lookup local
      ip rule del from all lookup local
      ip route add local "${nic0_ip}" dev "${nic0_name}" proto kernel \
        scope host src "${nic0_ip}" table main
      ip route add local 127.0.0.0/8 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add local 127.0.0.1 dev lo proto kernel \
        scope host src 127.0.0.1 table main
      ip route add broadcast 127.0.0.0 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      ip route add broadcast 127.255.255.255 dev lo proto kernel \
        scope link src 127.0.0.1 table main
      fi'
    2. Redémarrez le serveur pour que le script de démarrage prenne effet.

    3. Pour vérifier que le script de démarrage est bien stocké dans les métadonnées de l'instance, exécutez la commande suivante :

      gcloud compute instances describe primary-vm-name \
      --zone=primary-vm-zone

      Le script de démarrage apparaît dans le résultat sous metadata, comme illustré dans l'exemple tronqué suivant :

      metadata:
      fingerprint: Tbuij9k-knk=
      items:
      - key: post_deployment_script
      value: ''
      - key: sap_deployment_debug
      value: 'False'
      - key: status
      value: completed
      - key: startup-script
      value: |-
        #! /bin/bash
        # VM startup script
        ...
        [example truncated]
    4. Pour la VM secondaire, répétez les étapes précédentes après avoir remplacé les valeurs des variables par les valeurs de l'instance de VM secondaire.

Pour en savoir plus sur la création de scripts de démarrage pour les VM Compute Engine, consultez la page Exécuter des scripts de démarrage.

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 Google Cloud Storage. Consultez la page Travailler avec des objets dans la documentation Cloud Storage.
  • 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 principal vers le système secondaire.

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

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
  3. Depuis l'un ou l'autre serveur, créez des répertoires pour sapmnt, le répertoire de transport central, le répertoire système 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,SIDSYS,SIDASCSscs-instance-number,SIDERSers-instance-number}
  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/SYS
    ~> sudo mkdir -p /usr/sap/SID/ASCSscs-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 ASCSscs-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
    ~> echo "/usr/sap/SID/SYS ${NFS_OPTS} nfs-path/usrsapSIDSYS" | 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
    ~> cd /usr/sap/SID/SYS
    
  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

    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/usrsapAHASYS nfs      1007G   76M  956G   1% /usr/sap/AHA/SYS
    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 d'équilibrage de charge TCP/UDP interne compatible avec le basculement achemine le trafic SCS et ERS vers les instances actives respectives dans un cluster SAP NetWeaver. L'équilibrage de charge TCP/UDP interne utilise 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 SCS 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 SCS et pour l'adresse IP virtuelle du composant ERS. Pour SCS, 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 scs-vip-name \
      --region cluster-region --subnet cluster-subnet \
      --addresses scs-vip-address
    
    ~ gcloud compute addresses create ers-vip-name \
      --region cluster-region --subnet cluster-subnet \
      --addresses ers-vip-address

    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.85
    addressType: INTERNAL
    creationTimestamp: '2021-05-12T13:30:29.991-07:00'
    description: ''
    id: '1740813556077659146'
    kind: compute#address
    name: scs-aha-vip-name
    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/scs-aha-vip-name
    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 :

#
# IP-Address  Full-Qualified-Hostname  Short-Hostname
#
127.0.0.1       localhost
10.1.0.89       nw-ha-vm-1
10.1.0.88       nw-ha-vm-2
10.1.0.90       vh-scs-aha
10.1.0.91       vh-ers-aha

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

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

  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 SCS 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 scs-health-check-name \
      --port=scs-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: scs-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.

  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:scs-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-vm-zone
    2. ~ gcloud compute instance-groups unmanaged add-instances primary-ig-name \
      --zone=primary-vm-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-vm-zone
    2. ~ gcloud compute instance-groups unmanaged add-instances secondary-ig-name \
      --zone=secondary-vm-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 SCS et un 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 SCS :

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

      ~ gcloud compute backend-services create scs-backend-service-name \
         --load-balancing-scheme internal \
         --health-checks scs-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 SCS :

      ~ gcloud compute backend-services add-backend scs-backend-service-name \
        --instance-group primary-ig-name \
        --instance-group-zone primary-vm-zone \
        --region cluster-region
    3. Ajoutez le groupe d'instances secondaire en tant que groupe d'instances de basculement pour le service de backend SCS :

      ~ gcloud compute backend-services add-backend scs-backend-service-name \
        --instance-group secondary-ig-name \
        --instance-group-zone secondary-vm-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-vm-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-vm-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 SCS. 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: '2021-05-25T08:30:58.424-07:00'
    description: ''
    failoverPolicy:
      disableConnectionDrainOnFailover: true
      dropTrafficIfUnhealthy: true
      failoverRatio: 1.0
    fingerprint: n44gVc1VVQE=
    healthChecks:
    - https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/scs-aha-health-check-name
    id: '4940777952116778717'
    kind: compute#backendService
    loadBalancingScheme: INTERNAL
    name: scs-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/scs-aha-backend-service-name
    sessionAffinity: NONE
    timeoutSec: 30
  4. Dans Cloud Shell, créez des règles de transfert pour les services de backend SCS et ERS :

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

      ~ gcloud compute forwarding-rules create scs-forwarding-rule-name \
      --load-balancing-scheme internal \
      --address scs-vip-address \
      --subnet cluster-subnet \
      --region cluster-region \
      --backend-service scs-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

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. Vous devez tout de même installer l'utilitaire socat, car vous l'utiliserez plus tard lors de la configuration des ressources du cluster.

  1. En tant qu'utilisateur racine, installez sur les deux VM hôtes l'utilitaire socat :

    # zypper install -y socat

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

    # timeout 60s socat - TCP-LISTEN:scs-healthcheck-port-num,fork

  3. 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 SCS :

    ~ gcloud compute backend-services get-health scs-backend-service-name \
      --region cluster-region
  4. Répétez les étapes pour ERS, en remplaçant les valeurs des variables SCS par celles d'ERS.

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

    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

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, qui dispose d'un écouteur capable de lui répondre.

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

  1. Cliquez sur votre vérification de l'état dans la console :

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

  2. Cliquez sur Modifier.

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

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

  5. 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
  6. Lorsque vous avez terminé, rétablissez le numéro de port d'origine de la vérification de l'état.

Configurer Pacemaker

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

Pour en savoir plus sur la configuration des clusters à haute disponibilité sur SLES, consultez la documentation de l'extension SUSE Linux Enterprise High Availability Extension correspondant à votre version de SLES.

Installer les packages de cluster requis

  1. En tant qu'utilisateur racine, sur les hôtes principal et secondaire, téléchargez les packages de cluster requis suivants :

    • Le modèle ha_sles :

      # zypper install -t pattern ha_sles
    • Le package sap-suse-cluster-connector :

      # zypper install -y sap-suse-cluster-connector
    • Si ce n'est pas déjà fait, installez l'utilitaire socat :

      # zypper install -y socat

  2. Vérifiez que les derniers agents à haute disponibilité sont chargés :

    # zypper se -t patch SUSE-SLE-HA

Initialiser, configurer et démarrer le cluster sur la VM principale

Vous initialisez le cluster à l'aide du script SUSE ha-cluster-init. Vous devez ensuite modifier le fichier de configuration Corosync et le synchroniser avec le nœud secondaire. Après avoir démarré le cluster, vous pouvez définir d'autres propriétés et valeurs par défaut du cluster à l'aide des commandes crm.

Initialiser le cluster

Pour initialiser le cluster, procédez comme suit :

  1. Sur l'hôte principal, en tant qu'utilisateur racine, initialisez le cluster à l'aide du script SUSE ha-cluster-init. Les commandes suivantes nomment le cluster et créent le fichier de configuration corosync.conf : configurez-le ainsi que la synchronisation entre les nœuds du cluster.

    # ha-cluster-init --name cluster-name --yes --interface eth0 csync2
    # ha-cluster-init --name cluster-name --yes --interface eth0 corosync

Mettre à jour les fichiers de configuration Corosync

  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 :

    totem {
            ...
            token: 20000
            token_retransmits_before_loss_const: 10
            join: 60
            consensus: 24000
            max_messages: 20
            ...
    }
  3. Démarrez le cluster :

    # ha-cluster-init --name cluster-name cluster

Définir les propriétés de cluster supplémentaires

  1. Définissez les propriétés générales du cluster :

    # crm configure property no-quorum-policy="stop"
    # crm configure property startup-fencing="true"
    # crm configure property stonith-timeout="300s"
    # crm configure property stonith-enabled="true"
    # crm configure rsc_defaults resource-stickiness="1"
    # crm configure rsc_defaults migration-threshold="3"
    # crm configure op_defaults timeout="600"

    Lorsque vous définissez les ressources de cluster individuelles, les valeurs que vous définissez pour resource-stickiness et migration-threshold remplacent les valeurs par défaut que vous définissez ici.

    Vous pouvez afficher les valeurs par défaut de la ressource ainsi que les valeurs de toutes les ressources définies en saisissant crm config show.

  2. Démarrez Pacemaker sur l'hôte principal :

    # systemctl enable pacemaker
    # systemctl start pacemaker

Associer la VM secondaire au cluster

Depuis le terminal ouvert de la VM principale, associez et démarrez le cluster sur la VM secondaire via SSH.

  1. À partir de la VM principale, exécutez les options de script ha-cluster-join suivantes sur la VM secondaire via SSH. Si vous avez configuré votre cluster HA comme décrit dans les présentes instructions, vous pouvez ignorer les avertissements relatifs au watchdog.

    1. Exécutez l'option --interface eth0 csync2 :

      # ssh secondary-vm-name 'ha-cluster-join --cluster-node primary-vm-name --yes --interface eth0 csync2'
    2. Exécutez l'option ssh_merge :

      # ssh secondary-vm-name 'ha-cluster-join --cluster-node primary-vm-name --yes ssh_merge'
    3. Exécutez l'option cluster :

      # ssh secondary-vm-name 'ha-cluster-join --cluster-node primary-vm-name --yes cluster'
  2. Démarrez Pacemaker sur l'hôte secondaire :

    1. Activez Pacemaker :

      # ssh secondary-vm-name systemctl enable pacemaker
    2. Démarrez Pacemaker :

      # ssh secondary-vm-name systemctl start pacemaker
  3. Sur l'un de ces hôtes, en mode root, vérifiez que le cluster affiche les deux nœuds :

    # crm_mon -s

    La sortie obtenue doit ressembler à ceci :

    CLUSTER OK: 2 nodes online, 0 resource instances configured

Configurer les ressources du cluster pour l'infrastructure

Vous définissez les ressources gérées par Pacemaker dans un cluster à haute disponibilité. Vous devez définir des ressources pour les composants de cluster suivants :

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

Vous définissez les ressources des composants SCS et ERS après le reste des ressources car vous devez d'abord installer SAP NetWeaver.

Activer le mode de maintenance

  1. Sur l'un des hôtes, en mode root, passez le cluster en mode de maintenance :

    # crm configure property maintenance-mode="true"
  2. Confirmez le mode de maintenance :

    # crm status

    Le résultat doit indiquer que la gestion des ressources est désactivée, comme illustré dans l'exemple suivant :

    Cluster Summary:
    * Stack: corosync
    * Current DC: nw-ha-vm-1 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum
    * Last updated: Fri May 14 15:26:08 2021
    * Last change:  Thu May 13 19:02:33 2021 by root via cibadmin on nw-ha-vm-1
    * 2 nodes configured
    * 0 resource instances configured
    
                *** Resource management is DISABLED ***
    The cluster will not attempt to start, stop or recover services
    
    Node List:
    * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
    Full List of Resources:
    * No resources

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, vous créez pour l'appareil de cloisonnement une ressource de cluster qui peut 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 :

    # crm configure primitive fencing-rsc-name-primary-vm stonith:fence_gce \
      op monitor interval="300s" timeout="120s" on-fail="restart" \
      op start interval="0" timeout="60s" on-fail="restart" \
      params port="primary-vm-name" zone="primary-vm-zone" \
      project="cluster-project-id"
  2. Configurez l'emplacement de l'appareil de cloisonnement de la VM principale afin qu'il ne soit actif que sur la VM secondaire :

    # crm configure location fencing-location-name-primary-vm \
      fencing-rsc-name-primary-vm -inf: "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 :

    # crm configure primitive fencing-rsc-name-secondary-vm stonith:fence_gce \
      op monitor interval="300s" timeout="120s" on-fail="restart" \
      op start interval="0" timeout="60s" on-fail="restart" \
      params port="secondary-vm-name" zone="secondary-vm-zone" \
      project="cluster-project-id"
  4. Configurez l'emplacement de l'appareil de cloisonnement de la VM secondaire afin qu'il ne soit actif que sur la VM principale :

    # crm configure location fencing-location-name-secondary-vm \
      fencing-rsc-name-secondary-vm -inf: "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

Augmenter la valeur du délai d'expiration de Pacemaker pour les redémarrages

  1. Sur chaque hôte, en tant qu'utilisateur racine, augmentez la valeur du délai avant expiration de Pacemaker pour les redémarrages afin de tenir compte du délai de démarrage.

    crm_resource --resource STONITH-host-name --set-parameter=pcmk_reboot_timeout --parameter-value=300

    La valeur pcmk_reboot_timeout doit être supérieure à la somme des éléments suivants :

    • Délai avant expiration de token dans Corosync
    • Délai avant expiration de consensus dans Corosync
    • Durée d'exécution d'une opération de redémarrage, en incluant tout délai applicable.

    Sur Google Cloud, 300 secondes suffisent pour la plupart des clusters.

  2. Confirmez la nouvelle valeur pcmk_reboot_timeout :

    crm_resource --resource STONITH-host-name --get-parameter=pcmk_reboot_timeout

Créer les ressources du système de fichiers

Maintenant que vous avez créé les répertoires du système de fichiers partagé, vous pouvez définir les ressources du cluster.

  1. Configurez les ressources du système de fichiers pour les répertoires spécifiques de l'instance.

    # crm configure primitive scs-file-system-rsc-name Filesystem \
    device="nfs-path/usrsapSIDASCSscs-instance-number" \
    directory="/usr/sap/SID/ASCSscs-instance-number" fstype="nfs" \
    op start timeout=60s interval=0 \
    op stop timeout=60s interval=0 \
    op monitor interval=20s timeout=40s
    # crm configure primitive ers-file-system-rsc-name Filesystem \
    device="nfs-path/usrsapSIDERSers-instance-number" \
    directory="/usr/sap/SID/ERSers-instance-number" fstype="nfs" \
    op start timeout=60s interval=0 \
    op stop timeout=60s interval=0 \
    op monitor interval=20s timeout=40s

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

  1. Configurez les ressources du cluster pour les vérifications d'état SCS et ERS :
# crm configure primitive scs-health-check-rsc-name anything \
  params binfile="/usr/bin/socat" \
  cmdline_options="-U TCP-LISTEN:scs-healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null" \
  op monitor timeout=20s interval=10 \
  op_params depth=0
# crm configure primitive ers-health-check-rsc-name anything \
  params binfile="/usr/bin/socat" \
  cmdline_options="-U TCP-LISTEN:ers-healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null" \
  op monitor timeout=20s interval=10 \
  op_params depth=0

Créer les ressources des adresses IP virtuelles

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

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

    • gcloud compute addresses describe scs-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 SCS et ERS.

    # crm configure primitive scs-vip-rsc-name IPaddr2 \
     params ip=scs-vip-address cidr_netmask=32 nic="eth0" \
     op monitor interval=10s timeout=20s
    # crm configure primitive ers-vip-rsc-name IPaddr2 \
     params ip=ers-vip-address cidr_netmask=32 nic="eth0" \
     op monitor interval=10s timeout=20s

Afficher les ressources définies

  1. Pour afficher toutes les ressources que vous avez définies jusqu'à présent, saisissez la commande suivante :

    # crm status

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

    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 May 26 19:10:10 2021
    Last change: Tue May 25 23:48:35 2021 by root via cibadmin on nw-ha-vm-1
    
    2 nodes configured
    8 resource instances configured
    
                  *** Resource management is DISABLED ***
      The cluster will not attempt to start, stop or recover services
    
    Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
    Full list of resources:
    
     fencing-rsc-nw-aha-vm-1        (stonith:fence_gce):    Stopped (unmanaged)
     fencing-rsc-nw-aha-vm-2        (stonith:fence_gce):    Stopped (unmanaged)
     filesystem-rsc-nw-aha-scs      (ocf::heartbeat:Filesystem):    Stopped (unmanaged)
     filesystem-rsc-nw-aha-ers      (ocf::heartbeat:Filesystem):    Stopped (unmanaged)
     health-check-rsc-nw-ha-scs     (ocf::heartbeat:anything):      Stopped (unmanaged)
     health-check-rsc-nw-ha-ers     (ocf::heartbeat:anything):      Stopped (unmanaged)
     vip-rsc-nw-aha-scs     (ocf::heartbeat:IPaddr2):       Stopped (unmanaged)
     vip-rsc-nw-aha-ers     (ocf::heartbeat:IPaddr2):       Stopped (unmanaged)

Installer SCS 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 SCS 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-loweradm -g sapsys
    # usermod -a -G sapinst sid-loweradm
    # useradd -u uid-sapadm sapadm -g sapinst
    
    # chown sid-loweradm:sapsys /usr/sap/SID/SYS
    # chown sid-loweradm:sapsys /sapmnt/SID -R
    # chown sid-loweradm:sapsys /usr/sap/trans -R
    # chown sid-loweradm:sapsys /usr/sap/SID/SYS -R
    # chown sid-loweradm:sapsys /usr/sap/SID -R

Installer le composant SCS

  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

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

    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
  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 SCS 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 SCS 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 sidadm, arrêtez le service SCS.

    # su - sid-loweradm -c "sapcontrol -nr scs-instance-number -function Stop"
    # su - sid-loweradm -c "sapcontrol -nr scs-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 SCS 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 sidadm au groupe d'utilisateurs haclient.

Vérifier les entrées de service SAP

  1. Sur les deux serveurs, vérifiez que /usr/sap/sapservices contient bien des entrées pour les services SCS et ERS. Vous pouvez ajouter toutes les entrées manquantes à l'aide de sapstartsrv command, en utilisant les options pf=profile-of-the-sap-instance et -reg. Exemple :

    # 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 \
     -reg
    /usr/sap/hostctrl/exe/sapstartsrv \
     pf=/usr/sap/SID/SYS/profile/SID_ASCSscs-instance-number_scs-virtual-host-name \
     -reg

Arrêter les services SAP

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

    # su - sid-loweradm -c "sapcontrol -nr ers-instance-number -function Stop"
    # su - sid-loweradm -c "sapcontrol -nr ers-instance-number -function StopService"
  2. Sur chaque serveur, vérifiez que tous les services sont arrêtés :

    # su - sid-loweradm -c "sapcontrol -nr scs-instance-number -function GetSystemInstanceList"
    # su - sid-loweradm -c "sapcontrol -nr ers-instance-number -function GetSystemInstanceList"

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

    18.05.2021 17:39:18
    GetSystemInstanceList
    FAIL: NIECONN_REFUSED (Connection refused), NiRawConnect failed in plugin_fopen()

Modifier les profils SCS 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_ASCSscs-instance-number_scs-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 sidadm de travailler avec le cluster, ajoutez-le au groupe d'utilisateurs haclient.

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

    # usermod -aG haclient sid-loweradm

Configurer les ressources de cluster pour SCS 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 de 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. Créez les ressources de cluster pour les services SCS et ERS :

    ENSA1

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

      # crm configure primitive scs-instance-rsc-name SAPInstance \
        operations \$id=scs-instance-rsc-operations-name \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSscs-instance-number_scs-virtual-host-name \
           START_PROFILE="/path-to-profile/SID_ASCSscs-instance-number_scs-virtual-host-name" \
           AUTOMATIC_RECOVER=false \
        meta resource-stickiness=5000 failure-timeout=60 \
           migration-threshold=1 priority=10
    • 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-rsc-name 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

    ENSA2

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

      # crm configure primitive scs-instance-rsc-name SAPInstance \
        operations \$id=scs-instance-rsc-operations-name \
        op monitor interval=11 timeout=60 on-fail=restart \
        params InstanceName=SID_ASCSscs-instance-number_scs-virtual-host-name \
           START_PROFILE="/path-to-profile/SID_ASCSscs-instance-number_scs-virtual-host-name" \
           AUTOMATIC_RECOVER=false \
        meta resource-stickiness=5000 failure-timeout=60
    • 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-rsc-name 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

Configurer les groupes de ressources et les contraintes d'emplacement

  1. Regroupez les ressources SCS 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 scs-rsc-group-name scs-file-system-rsc-name \
      scs-health-check-rsc-name scs-vip-rsc-name \
      scs-instance-rsc-name \
      meta resource-stickiness=3000
    # crm configure group ers-rsc-group-name ers-file-system-rsc-name \
      ers-health-check-rsc-name ers-vip-rsc-name \
      ers-instance-rsc-name
  2. Créez les contraintes de colocation :

    ENSA1

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

      # crm configure colocation prevent-scs-ers-coloc -5000: ers-rsc-group-name scs-rsc-group-name
    2. Configurez SCS 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 scs-instance-rsc-name \
      rule 2000: runs_ers_SID eq 1
    3. Configurez SCS 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: scs-instance-rsc-name:start \
       ers-instance-rsc-name:stop symmetrical=false

    ENSA2

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

      # crm configure colocation prevent-scs-ers-coloc -5000: ers-rsc-group-name scs-rsc-group-name
    2. Configurez SCS 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: scs-instance-rsc-name:start \
       ers-instance-rsc-name:stop symmetrical=false
  3. Désactivez le mode de maintenance.

    # crm configure property maintenance-mode="false"
  4. Vérifiez la configuration des groupes, les contraintes de colocation et l'ordre de priorité :

    # crm config show

    Le résultat doit inclure des lignes semblables à celles de l'exemple suivant :

    ENSA1

    group ers-aha-rsc-group-name filesystem-rsc-nw-aha-ers health-check-rsc-nw-ha-ers vip-rsc-nw-aha-ers ers-aha-instance-rsc-name
    group scs-aha-rsc-group-name filesystem-rsc-nw-aha-scs health-check-rsc-nw-ha-scs vip-rsc-nw-aha-scs scs-aha-instance-rsc-name \
            meta resource-stickiness=3000
    colocation prevent-aha-scs-ers-coloc -5000: ers-aha-rsc-group-name scs-aha-rsc-group-name
    location fencing-rsc-nw-aha-vm-1-loc fencing-rsc-nw-aha-vm-1 -inf: nw-ha-vm-1
    location fencing-rsc-nw-aha-vm-2-loc fencing-rsc-nw-aha-vm-2 -inf: nw-ha-vm-2
    location loc-sap-AHA-failover-to-ers scs-aha-instance-rsc-name \
            rule 2000: runs_ers_AHA eq 1

    ENSA2

    group ers-aha-rsc-group-name filesystem-rsc-nw-aha-ers health-check-rsc-nw-ha-ers vip-rsc-nw-aha-ers ers-aha-instance-rsc-name
    group scs-aha-rsc-group-name filesystem-rsc-nw-aha-scs health-check-rsc-nw-ha-scs vip-rsc-nw-aha-scs scs-aha-instance-rsc-name \
            meta resource-stickiness=3000
    location fencing-location-nw-aha-vm-1 fencing-rsc-nw-aha-vm-1 -inf: nw-ha-vm-1
    location fencing-location-nw-aha-vm-2 fencing-rsc-nw-aha-vm-2 -inf: nw-ha-vm-2
    order ord-sap-AHA-first-start-ascs Optional: scs-aha-instance-rsc-name:start ers-aha-instance-rsc-name:stop symmetrical=false
    colocation prevent-aha-scs-ers-coloc -5000: ers-aha-rsc-group-name scs-aha-rsc-group-name

Tester le cluster

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

  • Recherchez les erreurs de configuration.
  • Vérifiez que les ressources SCS et ERS basculent correctement les serveurs lors des basculements.
  • Vérifiez que les verrous sont conservés.
  • Vérifiez que Compute Engine ne déclenche pas de basculement pour les événements de maintenance.

Vérifier la configuration du cluster dans SAP

  1. En tant qu'utilisateur racine, sur l'un ou l'autre des serveurs, découvrez quelles instances sont actives sur le serveur :

    # crm status
  2. Passez à l'utilisateur sidadm.

    # su - sid-loweradm
  3. Vérifiez la configuration du cluster. Pour le numéro d'instance, spécifiez le numéro de l'instance SCS 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 sidadm, 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-scs-aha_AHA_00), SAPInstance includes is-ers patch
    SUCCESS, SAP CONFIGURATION, Enqueue replication (vh-scs-aha_AHA_00), Enqueue replication enabled
    SUCCESS, SAP STATE, Enqueue replication state (vh-scs-aha_AHA_00), Enqueue replication active
  5. 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 SCS 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: scs-aha-rsc-group-name:
        * filesystem-rsc-nw-aha-scs (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
        * health-check-rsc-nw-ha-scs        (ocf::heartbeat:anything):       Started nw-ha-vm-1
        * vip-rsc-nw-aha-scs        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-1
        * scs-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
  6. En tant que sidadm sur le serveur où SCS est actif, simulez un basculement :

    > sapcontrol -nr scs-instance-number -function HAFailoverToNode ""
  7. En tant qu'utilisateur racine, si vous suivez le basculement à l'aide de crm_mon, vous devriez voir SCS se déplacer vers l'autre serveur, ERS s'arrêter sur ce serveur, puis passer au serveur sur lequel SCS s'exécutait.

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

ENSA1

  1. En tant que sidadm, sur le serveur où 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 sidadm, sur le serveur sur lequel SCS est actif, vérifiez que les entrées de verrou sont enregistrées :

    > sapcontrol -nr scs-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 sidadm, sur le serveur où 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 SCS 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 sidadm, 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 sidadm, sur le serveur où SCS est actif, vérifiez que les entrées de verrou sont supprimées :

    > sapcontrol -nr scs-instance-number -function EnqGetStatistic | grep locks_now

ENSA2

  1. En tant que sidadm, sur le serveur où ERS 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_ERSers-instance-number_ers-virtual-host-name
  2. En tant que sidadm, sur le serveur sur lequel SCS est actif, vérifiez que les entrées de verrou sont enregistrées :

    > sapcontrol -nr scs-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. Si SCS est actif, redémarrez le serveur.

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

    # crm_mon
  5. En tant que sidadm, sur le serveur où SCS a redémarré, vérifiez que les entrées de verrou ont été conservées :

    > sapcontrol -nr scs-instance-number -function EnqGetStatistic | grep locks_now
  6. En tant que sidadm sur le serveur où ERS est actif, après avoir confirmé que les verrous ont été conservés, libérez les verrous :

    > enq_admin --release_locks=number-of-locks:X:DIAG::TAB:%u pf=/path-to-profile/SID_ERSers-instance-number_ers-virtual-host-name
  7. En tant que sidadm, sur le serveur où SCS est actif, vérifiez que les entrées de verrou sont supprimées :

    > sapcontrol -nr scs-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, le risque que la migration à chaud déclenche un basculement est plus élevé.

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 SDK Cloud suivante :

    # gcloud compute instances simulate-maintenance-event primary-instance-name
  2. Vérifiez que le nœud principal ne change pas :

    # crm status

Dépannage

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

Obtenir de l'aide concernant SAP NetWeaver sur SLES

Si vous avez besoin d'aide pour résoudre un problème lié à des clusters à haute disponibilité pour SAP NetWeaver sur SLES, rassemblez les informations de diagnostic requises et contactez Cloud Customer Care. Pour en savoir plus, 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 Google Cloud Console. 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 et, s'il semble s'agir d'un problème d'infrastructure Google Cloud, la transfère au composant Google Cloud 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 :

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 les pages suivantes :

Étape suivante

Obtenez davantage d'informations en consultant les ressources suivantes :

+ Guide de planification de la haute disponibilité pour SAP NetWeaver sur Google Cloud +SAP sur Google Cloud : livre blanc sur la haute disponibilité + Pour en savoir plus sur l'administration et la surveillance des VM, consultez le guide d'utilisation de SAP NetWeaver.