Guide de configuration d'un scaling à la hausse sur un cluster à haute disponibilité pour SAP HANA sur RHEL

Ce guide explique comment déployer et configurer un cluster à haute disponibilité Red Hat Enterprise Linux (RHEL) pour un système avec scaling à la hausse SAP HANA 1.0 SPS 12 ou versions ultérieures sur Google Cloud.

Ce guide comprend les étapes suivantes :

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

Pour déployer un système SAP HANA sans cluster Linux à haute disponibilité ni hôte de nœud de secours, suivez le guide de déploiement de SAP HANA.

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

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

Système déployé dans ce guide

En suivant ce guide, vous allez déployer deux instances SAP HANA et configurer un cluster à haute disponibilité sur RHEL. Vous allez déployer chaque instance SAP HANA sur une VM Compute Engine dans une zone différente de la même région. Ce guide ne traite pas de l'installation à haute disponibilité de SAP NetWeaver.

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

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

  • Deux VM hôtes, chacune avec une instance de SAP HANA
  • La réplication du système SAP HANA synchrone
  • 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 et les instances SAP HANA, ce qui garantit que les VM et les systèmes de base SAP HANA répondent aux exigences de compatibilité de SAP et sont conformes aux bonnes pratiques actuelles.

SAP HANA Studio est utilisé dans ce guide pour tester la réplication du système SAP HANA. Si vous préférez, vous pouvez utiliser SAP HANA Cockpit. Pour plus d'informations sur l'installation de SAP HANA Studio, consultez les pages suivantes :

Prérequis

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

Créer un réseau

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

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

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

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

Console

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

    Accéder aux réseaux VPC

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

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

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

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

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

gcloud

  1. Accédez à Cloud Shell.

    Accéder à Cloud Shell

  2. Pour créer un réseau en mode de sous-réseau personnalisé, exécutez la commande suivante : 
    gcloud compute networks create NETWORK_NAME --subnet-mode custom

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

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

  3. Créez un sous-réseau, et spécifiez la région et la plage d'adresses IP : 
    gcloud compute networks subnets create SUBNETWORK_NAME \
    --network NETWORK_NAME --region REGION --range RANGE

    Remplacez les éléments suivants :

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

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

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

Configurer une passerelle NAT

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

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, une règle de pare-feu implicite bloque les connexions entrantes provenant de l'extérieur de votre réseau VPC (Virtual Private Cloud, cloud privé virtuel). Pour autoriser les connexions entrantes, configurez une règle de pare-feu pour votre VM. Une fois qu'une connexion entrante est établie avec une VM, le trafic est autorisé dans les deux sens via cette connexion.

Vous pouvez également créer une règle de pare-feu pour autoriser l'accès externe à des ports spécifiés ou pour limiter l'accès entre plusieurs VM d'un même réseau. Si le type de réseau VPC default est utilisé, d'autres règles par défaut s'appliquent également, telles que la règle default-allow-internal, qui permet la connectivité entre les VM d'un même réseau sur tous les ports.

En fonction de la stratégie informatique applicable à votre environnement, vous devrez peut-être isoler votre hôte de base de données, ou en restreindre la connectivité, en créant des règles de pare-feu.

Selon votre scénario, vous pouvez créer des règles de pare-feu afin d'autoriser l'accès pour ce qui suit :

  • Ports SAP par défaut répertoriés dans le tableau listant les ports TCP/IP de tous les produits SAP.
  • Connexions à partir de votre ordinateur ou de votre environnement de réseau d'entreprise à 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 sur le sous-réseau SAP HANA, y compris la communication entre les nœuds d'un système à évolutivité horizontale SAP HANA ou la communication entre le serveur de base de données et les serveurs d'applications dans une architecture à trois niveaux. Pour activer la communication entre VM, vous pouvez créer une règle de pare-feu autorisant le trafic provenant du sous-réseau.

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

Console

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

    Accéder à la page "Pare-feu"

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

    • Dans le champ Réseau, sélectionnez le réseau sur lequel se trouve votre VM.
    • Dans le champ Cibles, spécifiez les ressources Google Cloud auxquelles cette règle s'applique. Par exemple, spécifiez Toutes les instances du réseau. Pour limiter la règle à des instances spécifiques sur Google Cloud, saisissez des tags dans le champ Tags cibles spécifiés.
    • Dans le champ Filtre source, sélectionnez l'une des options suivantes :
      • Plages 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 depuis un sous-réseau particulier. Spécifiez le nom du sous-réseau dans le champ Sous-réseaux qui s'affiche. Utilisez cette option pour autoriser l'accès entre plusieurs VM dans une configuration à trois niveaux ou évolutive.
    • Dans la section Protocoles et ports, sélectionnez Protocoles et ports spécifiés, puis saisissez tcp:PORT_NUMBER.

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

gcloud

Créez une règle de pare-feu à l'aide de la commande suivante :

$ gcloud compute firewall-rules create FIREWALL_NAME
--direction=INGRESS --priority=1000 \
--network=NETWORK_NAME --action=ALLOW --rules=PROTOCOL:PORT \
--source-ranges IP_RANGE --target-tags=NETWORK_TAGS

Déployer les VM et SAP HANA

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

Pour définir et déployer les systèmes, utilisez le même modèle Cloud Deployment Manager que celui qui a servi à déployer un système SAP HANA dans le guide de déploiement de SAP HANA.

Toutefois, pour déployer deux systèmes au lieu d'un, vous devez ajouter la définition du second système au fichier de configuration en copiant et en collant la définition du premier système. 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 systèmes SAP HANA déployés, définissez et configurez le cluster à haute disponibilité.

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

  1. Vérifiez que vos quotas actuels pour les ressources, telles que les disques persistants et les processeurs, sont suffisants pour les systèmes SAP HANA que vous allez installer. Si vos quotas sont insuffisants, le déploiement échoue. Pour connaître les exigences en matière de quotas de SAP HANA, consultez la section Remarques relatives aux tarifs et aux quotas applicables à SAP HANA.

    Accéder à la page "Quotas"

  2. Ouvrez Cloud Shell ou, si vous avez installé gcloud CLI sur votre poste de travail local, ouvrez un terminal.

    Accéder à Cloud Shell

  3. Téléchargez dans votre répertoire de travail le modèle de fichier de configuration template.yaml pour le cluster SAP HANA à haute disponibilité. Pour ce faire, saisissez la commande suivante dans Cloud Shell ou gcloud CLI :

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

  4. Renommez éventuellement le fichier template.yaml pour identifier la configuration qu'il définit.

  5. Ouvrez le fichier template.yaml dans l'éditeur de code Cloud Shell ou, si vous utilisez gcloud CLI, dans l'éditeur de texte de votre choix.

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

  6. Dans le fichier template.yaml, terminez la définition du système SAP HANA principal. 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 créer des instances de VM sans installer SAP HANA, supprimez ou commentez toutes les lignes commençant par sap_hana_.

    Valeur Type de données Description
    type 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 en cours de définition. Spécifiez des noms différents dans les définitions des VM principale et secondaire. Ces noms ne doivent contenir que des lettres minuscules, des chiffres ou des traits d'union.
    instanceType Chaîne Type de machine virtuelle Compute Engine nécessaire à l'exécution de SAP HANA. Si vous avez besoin d'un type de VM personnalisé, spécifiez un type de VM prédéfini avec un nombre de processeurs virtuels le plus proche possible de la quantité dont vous avez besoin tout en étant légèrement supérieur. Une fois le déploiement terminé, modifiez le nombre de processeurs virtuels et la quantité de mémoire.
    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 HANA principales et secondaires. 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éé précédemment. 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 la famille d'images ou de l'image du système d'exploitation Linux que vous utilisez avec SAP HANA. Pour spécifier une famille d'images, ajoutez le préfixe family/ au nom de la famille. Exemple :family/rhel-7-6-sap-ha Pour spécifier une image spécifique, indiquez uniquement le nom de l'image. Pour obtenir la liste des images et des familles disponibles, consultez la page Images dans la console Google Cloud.
    linuxImageProject Chaîne Le projet Google Cloud qui contient l'image que vous allez utiliser. Ce projet peut être votre propre projet ou un projet d'image Google Cloud, tel que rhel-sap-cloud. Pour en savoir plus sur les projets d'image Google Cloud, consultez la page Images dans la documentation Compute Engine.
    sap_hana_deployment_bucket Chaîne Nom du bucket Google Cloud Storage de votre projet contenant les fichiers d'installation et de révision de SAP HANA que vous avez importés précédemment. Tous les fichiers de révision de mise à niveau du bucket sont appliqués à SAP HANA au cours du processus de déploiement.
    sap_hana_sid Chaîne ID système (SID) SAP HANA. L'ID doit comporter trois caractères alphanumériques et commencer par une lettre. Les lettres doivent être saisies en majuscules.
    sap_hana_instance_number Entier Numéro d'instance (0 à 99) du système SAP HANA. La valeur par défaut est 0.
    sap_hana_sidadm_password Chaîne Mot de passe de l'administrateur du système d'exploitation (OS). Les mots de passe doivent comporter au moins huit caractères et inclure au moins une lettre majuscule, une lettre minuscule et un chiffre.
    sap_hana_system_password Chaîne Mot de passe du super-utilisateur de la base de données. Les mots de passe doivent comporter au moins huit caractères et inclure au moins une lettre majuscule, une lettre minuscule et un chiffre.
    sap_hana_sidadm_uid Entier La valeur par défaut pour l'ID utilisateur SID_LCadm est 900 afin d'éviter les conflits entre les groupes créés par les utilisateurs et SAP HANA. Vous pouvez modifier cette valeur si nécessaire.
    sap_hana_sapsys_gid Entier L'ID de groupe par défaut pour sapsys est 79. En spécifiant une valeur supérieure, vous pouvez remplacer cette valeur selon vos besoins.
    sap_hana_scaleout_nodes Entier Spécifiez 0. Ces instructions sont destinées uniquement aux systèmes avec scaling à la hausse SAP HANA.
    networkTag Chaîne Tag réseau qui représente votre instance de VM à des fins de routage ou d'établissement/application de règles de pare-feu. Si vous spécifiez publicIP: No et ne spécifiez pas de tag réseau, veillez à fournir un autre moyen d'accès à Internet.
    nic_type Chaîne Facultatif, mais recommandé si disponible pour la machine cible et la version de l'OS. Spécifie l'interface réseau à utiliser avec l'instance de VM. Vous pouvez spécifier la valeur GVNIC ou VIRTIO_NET. Pour utiliser une carte d'interface réseau virtuelle Google (gVNIC), vous devez spécifier une image de l'OS compatible avec gVNIC comme valeur de la propriété linuxImage. Pour obtenir la liste des images de l'OS, consultez la section Détails des systèmes d'exploitation.

    Si vous ne spécifiez pas de valeur pour cette propriété, l'interface réseau est automatiquement sélectionnée en fonction du type de machine que vous spécifiez pour la propriété instanceType.

    Cet argument est disponible dans les versions 202302060649 du modèle Deployment Manager ou ultérieures.
    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.
    serviceAccount Chaîne Facultatif. Spécifie un compte de service destiné à être utilisé par les VM hôtes et par les programmes exécutés sur celles-ci. Spécifiez l'adresse e-mail du compte de service. Par exemple, svc-acct-name@project-id.iam.gserviceaccount.com. Par défaut, le compte de service Compute Engine par défaut est utilisé. Pour en savoir plus, consultez la page Gestion de l'authentification et des accès pour les programmes SAP sur Google Cloud.

  7. Créez la définition du système SAP HANA secondaire en copiant la définition du système SAP HANA principal et en collant la copie après la définition principale du système SAP HANA. Reportez-vous à l'exemple qui suit ces étapes.

  8. Dans la définition du système SAP HANA secondaire, spécifiez des valeurs différentes de celles spécifiées dans la définition principale du système SAP HANA pour les propriétés suivantes :

    • name
    • instanceName
    • zone

  9. Créez les instances :

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

    La commande ci-dessus appelle Deployment Manager, lequel déploie les VM, télécharge le logiciel SAP HANA à partir de votre bucket de stockage, puis l'installe, conformément aux spécifications de votre fichier template.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 template.yaml complet

L'exemple suivant montre un fichier de configuration template.yaml terminé qui déploie deux instances de VM avec un système SAP HANA installé.

Le fichier contient les définitions des deux ressources à déployer : sap_hana_primary et sap_hana_secondary. Chaque définition de ressource contient les définitions d'une VM et d'une instance SAP HANA.

La définition de la ressource sap_hana_secondary 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, serviceAccount, sap_hana_sidadm_uid et sap_hana_sapsys_gid proviennent de la section "Options avancées" du modèle de fichier de configuration. Les propriétés sap_hana_sidadm_uid et sap_hana_sapsys_gid sont incluses pour afficher leurs valeurs par défaut, qui sont utilisées car les propriétés sont commentées.

resources:
- name: sap_hana_primary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/yyyymmddhhmm/dm-templates/sap_hana/sap_hana.py
  #
  properties:
    instanceName: hana-ha-vm-1
    instanceType: n2-highmem-32
    zone: us-central1-a
    subnetwork: example-subnet-us-central1
    linuxImage: family/rhel-8-1-sap-ha
    linuxImageProject: rhel-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Tempa55word
    sap_hana_system_password: Tempa55word
    sap_hana_scaleout_nodes: 0
    networkTag: cluster-ntwk-tag
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79

- name: sap_hana_secondary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/yyyymmddhhmm/dm-templates/sap_hana/sap_hana.py
  #
  properties:
    instanceName: hana-ha-vm-2
    instanceType: n2-highmem-32
    zone: us-central1-c
    subnetwork: example-subnet-us-central1
    linuxImage: family/rhel-8-1-sap-ha
    linuxImageProject: rhel-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Google123
    sap_hana_system_password: Google123
    sap_hana_scaleout_nodes: 0
    networkTag: cluster-ntwk-tag
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79

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é

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 et de SAP HANA

Pour vérifier le déploiement, vérifiez les journaux de déploiement dans Cloud Logging, ainsi que les disques et les services sur les VM des hôtes principaux et secondaires.

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

    Accéder à CloudLogging

  2. Filtrez les journaux :

    Explorateur de journaux

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

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

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

      resource.type="global"
"Deployment"

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

    Ancienne visionneuse de journaux

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

  3. Analysez les journaux filtrés :

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

    • Si vous rencontrez une erreur de quota :

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

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

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

Vérifier la configuration des VM et de SAP HANA

  1. Une fois le système SAP HANA déployé sans erreur, connectez-vous à chaque VM à l'aide du protocole SSH. Sur la page VM instances (Instances de VM) de Compute Engine, cliquez sur le bouton SSH de votre instance de VM ou utilisez la méthode SSH de votre choix.

    Bouton SSH sur la page "VM instances" (Instances de VM) de Compute Engine

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

    $ sudo su -

  3. À l'invite de commande, saisissez df -h. Sur chaque VM, assurez-vous que les répertoires /hana s'affichent, par exemple /hana/data.

    Filesystem                        Size  Used Avail Use% Mounted on
/dev/sda2                          30G  4.0G   26G  14% /
devtmpfs                          126G     0  126G   0% /dev
tmpfs                             126G     0  126G   0% /dev/shm
tmpfs                             126G   17M  126G   1% /run
tmpfs                             126G     0  126G   0% /sys/fs/cgroup
/dev/sda1                         200M  9.7M  191M   5% /boot/efi
/dev/mapper/vg_hana-shared        251G   49G  203G  20% /hana/shared
/dev/mapper/vg_hana-sap            32G  240M   32G   1% /usr/sap
/dev/mapper/vg_hana-data          426G  7.0G  419G   2% /hana/data
/dev/mapper/vg_hana-log           125G  4.2G  121G   4% /hana/log
/dev/mapper/vg_hanabackup-backup  512G   33M  512G   1% /hanabackup
tmpfs                              26G     0   26G   0% /run/user/900
tmpfs                              26G     0   26G   0% /run/user/899
tmpfs                              26G     0   26G   0% /run/user/1000

  4. Connectez-vous en tant qu'administrateur SAP en remplaçant SID_LC dans la commande suivante par l'ID système que vous avez spécifié dans le modèle de fichier de configuration. Utilisez des minuscules pour toutes les lettres.

    # su - SID_LCadm

  5. Assurez-vous que les services SAP HANA, tels que hdbnameserver, hdbindexserver et autres services, s'exécutent sur l'instance en saisissant la commande suivante :

    > HDB info

  6. Si vous utilisez RHEL pour SAP 9.0 ou une version ultérieure, assurez-vous que les packages chkconfig et compat-openssl11 sont installés sur votre instance de VM.

    Pour en savoir plus, consultez la note SAP 3108316 – Red Hat Enterprise Linux 9.x : installation et configuration.

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

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

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

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

  1. Établissez une connexion SSH avec votre instance de VM hôte.

  2. Exécutez la commande ci-dessous : 

    systemctl status google-cloud-sap-agent

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

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

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

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

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

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

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

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

Configurer la surveillance pour SAP HANA

Vous pouvez éventuellement surveiller vos instances SAP HANA à l'aide de l'agent Google Cloud pour SAP. À partir de la version 2.0, vous pouvez configurer l'agent de sorte qu'il collecte les métriques de surveillance SAP HANA et les envoie à Cloud Monitoring. Cloud Monitoring vous permet de créer des tableaux de bord pour visualiser ces métriques, de configurer des alertes en fonction de seuils de métriques, etc.

Pour en savoir plus sur la collecte des métriques de surveillance SAP HANA à l'aide de l'agent Google Cloud pour SAP, consultez Collecte des métriques de surveillance SAP HANA.

Activer le redémarrage rapide de SAP HANA

Google Cloud recommande fortement d'activer le redémarrage rapide SAP HANA pour chaque instance de SAP HANA, en particulier pour les instances de grande capacité. Le redémarrage rapide de SAP HANA réduit le temps de redémarrage en cas d'arrêt de SAP HANA, mais le système d'exploitation reste en cours d'exécution.

Comme configuré par les scripts d'automatisation fournis par Google Cloud, les paramètres du système d'exploitation et du noyau sont déjà compatibles avec le redémarrage rapide de SAP HANA. Vous devez définir le système de fichiers tmpfs et configurer SAP HANA.

Pour définir le système de fichiers tmpfs et configurer SAP HANA, vous pouvez suivre les étapes manuelles ou utiliser le script d'automatisation fourni par Google Cloud pour activer le redémarrage rapide de SAP HANA. Pour en savoir plus, consultez les pages suivantes :

Pour obtenir des instructions faisant autorité sur la fonction de redémarrage rapide SAP HANA, consultez la documentation sur les options de redémarrage rapide de SAP HANA.

Étapes manuelles

Configurer le système de fichiers tmpfs

Une fois les VM hôtes et les systèmes SAP HANA de base déployés, vous devez créer et installer des répertoires pour les nœuds NUMA du système de fichiers tmpfs.

Afficher la topologie NUMA de votre VM

Pour pouvoir mapper le système de fichiers tmpfs requis, vous devez connaître la quantité de nœuds NUMA dont dispose votre VM. Pour afficher les nœuds NUMA disponibles sur une VM Compute Engine, saisissez la commande suivante :

lscpu | grep NUMA

Par exemple, un type de VM m2-ultramem-208 comporte quatre nœuds NUMA, numérotés de 0 à 3, comme illustré dans l'exemple suivant :

NUMA node(s):        4
NUMA node0 CPU(s):   0-25,104-129
NUMA node1 CPU(s):   26-51,130-155
NUMA node2 CPU(s):   52-77,156-181
NUMA node3 CPU(s):   78-103,182-207
Créer les répertoires de nœuds NUMA

Créez un répertoire pour chaque nœud NUMA de votre VM et définissez les autorisations.

Par exemple, pour quatre nœuds NUMA numérotés de 0 à 3 :

mkdir -pv /hana/tmpfs{0..3}/SID
chown -R SID_LCadm:sapsys /hana/tmpfs*/SID
chmod 777 -R /hana/tmpfs*/SID
Installer les répertoires de nœuds NUMA dans tmpfs

Montez les répertoires du système de fichiers tmpfs et spécifiez une préférence de nœud NUMA pour chacun avec mpol=prefer :

SID : spécifiez le SID en majuscules.

mount tmpfsSID0 -t tmpfs -o mpol=prefer:0 /hana/tmpfs0/SID
mount tmpfsSID1 -t tmpfs -o mpol=prefer:1 /hana/tmpfs1/SID
mount tmpfsSID2 -t tmpfs -o mpol=prefer:2 /hana/tmpfs2/SID
mount tmpfsSID3 -t tmpfs -o mpol=prefer:3 /hana/tmpfs3/SID
Mettre à jour /etc/fstab

Pour vous assurer que les points d'installation sont disponibles après un redémarrage du système d'exploitation, ajoutez des entrées dans la table du système de fichiers, /etc/fstab :

tmpfsSID0 /hana/tmpfs0/SID tmpfs rw,relatime,mpol=prefer:0
tmpfsSID1 /hana/tmpfs1/SID tmpfs rw,relatime,mpol=prefer:1
tmpfsSID1 /hana/tmpfs2/SID tmpfs rw,relatime,mpol=prefer:2
tmpfsSID1 /hana/tmpfs3/SID tmpfs rw,relatime,mpol=prefer:3

Facultatif : définir des limites à l'utilisation de la mémoire

Le système de fichiers tmpfs peut augmenter ou diminuer de manière dynamique.

Pour limiter la mémoire utilisée par le système de fichiers tmpfs, vous pouvez définir une limite de taille pour un volume de nœuds NUMA en utilisant l'option size. Exemple :

mount tmpfsSID0 -t tmpfs -o mpol=prefer:0,size=250G /hana/tmpfs0/SID

Vous pouvez également limiter l'utilisation globale de la mémoire tmpfs pour tous les nœuds NUMA d'une instance SAP HANA donnée et d'un nœud de serveur donné en définissant le paramètre persistent_memory_global_allocation_limit dans la section [memorymanager] du fichier global.ini.

Configuration de SAP HANA pour le redémarrage rapide

Pour configurer SAP HANA pour le redémarrage rapide, mettez à jour le fichier global.ini et spécifiez les tables à stocker dans la mémoire persistante.

Mettre à jour la section [persistence] du fichier global.ini

Configurez la section [persistence] du fichier SAP HANA global.ini de manière à référencer les emplacements tmpfs. Séparez chaque emplacement tmpfs par un point-virgule :

[persistence]
basepath_datavolumes = /hana/data
basepath_logvolumes = /hana/log
basepath_persistent_memory_volumes = /hana/tmpfs0/SID;/hana/tmpfs1/SID;/hana/tmpfs2/SID;/hana/tmpfs3/SID

L'exemple précédent spécifie quatre volumes de mémoire pour quatre nœuds NUMA, ce qui correspond à m2-ultramem-208. Si vous l'exécutez sur m2-ultramem-416, vous devez configurer huit volumes de mémoire (de 0 à 7).

Redémarrez SAP HANA après avoir modifié le fichier global.ini.

SAP HANA peut désormais utiliser l'emplacement tmpfs comme espace de mémoire persistant.

Spécifier les tables à stocker en mémoire persistante

Spécifiez des tables ou partitions de colonne spécifiques à stocker en mémoire persistante.

Par exemple, pour activer la mémoire persistante pour une table existante, exécutez la requête SQL :

ALTER TABLE exampletable persistent memory ON immediate CASCADE

Pour modifier la valeur par défaut des nouvelles tables, ajoutez le paramètre table_default dans le fichier indexserver.ini. Exemple :

[persistent_memory]
table_default = ON

Pour en savoir plus sur le contrôle des colonnes et des tables ainsi que sur les vues de surveillance qui fournissent des informations détaillées, consultez la page Mémoire persistante SAP HANA.

Étapes automatisées

Le script d'automatisation fourni par Google Cloud pour activer le redémarrage rapide de SAP HANA apporte des modifications aux répertoires /hana/tmpfs*, au fichier /etc/fstab et à la configuration de SAP HANA. Lorsque vous exécuterez le script, vous devrez peut-être effectuer des étapes supplémentaires selon qu'il s'agit du déploiement initial de votre système SAP HANA ou que vous redimensionnez votre machine sur une autre taille NUMA.

Pour le déploiement initial de votre système SAP HANA ou le redimensionnement de la machine pour augmenter le nombre de nœuds NUMA, assurez-vous que SAP HANA est en cours d'exécution pendant l'exécution du script d'automatisation fourni par Google Cloud pour activer le redémarrage rapide de SAP HANA.

Lorsque vous redimensionnez votre machine pour réduire le nombre de nœuds NUMA, assurez-vous que SAP HANA est arrêté pendant l'exécution du script d'automatisation fourni par Google Cloud pour permettre le redémarrage rapide de SAP HANA. Une fois le script exécuté, vous devez mettre à jour manuellement la configuration SAP HANA pour terminer la configuration du redémarrage rapide de SAP HANA. Pour en savoir plus, consultez la section Configuration de SAP HANA pour le redémarrage rapide.

Pour activer le redémarrage rapide de SAP HANA, procédez comme suit :

  1. Établissez une connexion SSH avec votre VM hôte.

  2. Passez en mode root : 

    sudo su -

  3. Téléchargez le script sap_lib_hdbfr.sh :

    wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/lib/sap_lib_hdbfr.sh

  4. Rendez le fichier exécutable :

    chmod +x sap_lib_hdbfr.sh

  5. Vérifiez que le script ne comporte aucune erreur : 

    vi sap_lib_hdbfr.sh
./sap_lib_hdbfr.sh -help

    Si la commande renvoie une erreur, contactez le Cloud Customer Care. Pour en savoir plus sur la procédure à suivre pour contacter le service client, consultez la page Obtenir de l'aide concernant SAP sur Google Cloud.

  6. Exécutez le script après avoir remplacé l'ID système (SID) et le mot de passe SAP HANA de l'utilisateur système de la base de données SAP HANA. Pour fournir le mot de passe en toute sécurité, nous vous recommandons d'utiliser un secret dans Secret Manager.

    Exécutez le script en utilisant le nom d'un secret dans Secret Manager. Ce secret doit exister dans le projet Google Cloud qui contient votre instance de VM hôte.

    sudo ./sap_lib_hdbfr.sh -h 'SID' -s SECRET_NAME

    Remplacez les éléments suivants :

    • SID : spécifiez le SID en majuscules. Par exemple, AHA.
    • SECRET_NAME : spécifiez le nom du secret correspondant au mot de passe de l'utilisateur système de la base de données SAP HANA. Ce secret doit exister dans le projet Google Cloud qui contient votre instance de VM hôte.

    Vous pouvez également exécuter le script en utilisant un mot de passe en texte brut. Une fois le redémarrage rapide de SAP HANA activé, veillez à modifier votre mot de passe. L'utilisation d'un mot de passe en texte brut n'est pas recommandée, car celui-ci serait enregistré dans l'historique de ligne de commande de votre VM.

    sudo ./sap_lib_hdbfr.sh -h 'SID' -p 'PASSWORD'

    Remplacez les éléments suivants :

    • SID : spécifiez le SID en majuscules. Par exemple, AHA.
    • PASSWORD : spécifiez le mot de passe de l'utilisateur système de la base de données SAP HANA.

Dans le cas d'une exécution initiale réussie, vous devez obtenir une sortie semblable à celle-ci :

INFO - Script is running in standalone mode
ls: cannot access '/hana/tmpfs*': No such file or directory
INFO - Setting up HANA Fast Restart for system 'TST/00'.
INFO - Number of NUMA nodes is 2
INFO - Number of directories /hana/tmpfs* is 0
INFO - HANA version 2.57
INFO - No directories /hana/tmpfs* exist. Assuming initial setup.
INFO - Creating 2 directories /hana/tmpfs* and mounting them
INFO - Adding /hana/tmpfs* entries to /etc/fstab. Copy is in /etc/fstab.20220625_030839
INFO - Updating the HANA configuration.
INFO - Running command: select * from dummy
DUMMY
"X"
1 row selected (overall time 4124 usec; server time 130 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistence', 'basepath_persistent_memory_volumes') = '/hana/tmpfs0/TST;/hana/tmpfs1/TST;'
0 rows affected (overall time 3570 usec; server time 2239 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistent_memory', 'table_unload_action') = 'retain';
0 rows affected (overall time 4308 usec; server time 2441 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'SYSTEM') SET ('persistent_memory', 'table_default') = 'ON';
0 rows affected (overall time 3422 usec; server time 2152 usec)

Facultatif : Configurer des clés SSH sur les VM principale et secondaire

Les clés du magasin sécurisé SAP HANA (SSFS) doivent être synchronisées entre les hôtes du cluster à haute disponibilité. Pour simplifier la synchronisation et permettre la copie de fichiers tels que des sauvegardes entre les hôtes du cluster à haute disponibilité, ces instructions autorisent les connexions SSH directes entre les deux hôtes.

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 synchroniser les clés SSFS et 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 l'agent Backint de Cloud Storage pour SAP HANA afin de sauvegarder et de restaurer des bases de données HANA. Consultez la section Agent Backint de Cloud Storage pour SAP HANA.
  • Utilisez une solution de stockage de fichiers telle que Filestore ou NetApp Cloud Volumes Service pour créer un dossier partagé. Consultez la section Options de serveur de fichiers.

Pour activer les connexions SSH entre les instances principale et secondaire, procédez comme indiqué ci-dessous.

  1. Sur la VM hôte principale :

    1. Connectez-vous en SSH à la VM.

    2. Générez une clé SSH pour l'utilisateur qui a besoin de la connexion SSH hôte à hôte. Il s'agit généralement de vous.

      $ ssh-keygen

    3. Lorsque vous y êtes invité, acceptez les valeurs par défaut en appuyant sur Entrée.

    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-host-name \
     --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
     --zone secondary-zone

    5. Autorisez la VM principale sur elle-même.

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

  2. Sur la VM hôte secondaire :

    1. Connectez-vous en SSH à la VM.

    2. Générez une clé SSH pour l'utilisateur qui a besoin de la connexion SSH hôte à hôte.

      $ ssh-keygen

    3. 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-host-name \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
      --zone primary-zone

    4. Autorisez la VM secondaire sur elle-même.

      $ 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-host-name

  3. Sur la VM hôte principale, confirmez la connexion en ouvrant une connexion SSH à la VM hôte secondaire :

    $ ssh secondary-host-name

Sauvegarder les bases de données

Créez des sauvegardes de vos bases de données afin de lancer la journalisation des bases de données pour la réplication du système SAP HANA et créer un point de récupération.

Si vous avez plusieurs bases de données locataires dans une configuration MDC, sauvegardez chacune de ces bases de données.

Le modèle Deployment Manager utilise /hanabackup/data/SID comme répertoire de sauvegarde par défaut.

Pour créer des sauvegardes de nouvelles bases de données SAP HANA, procédez comme suit :

  1. Sur l'hôte principal, passez en SID_LCadm. Selon votre image de système d'exploitation, la commande peut être différente.

    sudo -i -u SID_LCadm

  2. Créez des sauvegardes de bases de données :

    • Pour un système à conteneur de bases de données unique SAP HANA :

      > hdbsql -t -u system -p SYSTEM_PASSWORD -i INST_NUM \
  "backup data using file ('full')"

      L'exemple suivant montre une réponse positive d'un nouveau système SAP HANA :

      0 rows affected (overall time 18.416058 sec; server time 18.414209 sec)

    • Pour un système à conteneurs de bases de données multiples (MDC, multi-database-container) SAP HANA, créez une sauvegarde de la base de données système ainsi que des bases de données locataires :

      > hdbsql -t -d SYSTEMDB -u system -p SYSTEM_PASSWORD -i INST_NUM \
  "backup data using file ('full')"
      > hdbsql -t -d SID -u system -p SYSTEM_PASSWORD -i INST_NUM \
  "backup data using file ('full')"

    L'exemple suivant montre une réponse positive d'un nouveau système SAP HANA :

    0 rows affected (overall time 16.590498 sec; server time 16.588806 sec)

  3. Vérifiez que le mode de journalisation est défini sur "normal" :

    > hdbsql -u system -p SYSTEM_PASSWORD -i INST_NUM \
  "select value from "SYS"."M_INIFILE_CONTENTS" where key='log_mode'"

    Vous devriez voir les éléments suivants :

    VALUE
"normal"

Activer la réplication du système SAP HANA

Dans le cadre de l'activation de la réplication du système SAP HANA, vous devez copier les données et les fichiers de clés pour les magasins sécurisés SAP HANA du système de fichiers (SSFS) de l'hôte principal vers l'hôte secondaire. La méthode utilisée dans cette procédure pour copier les fichiers n'est que l'une des méthodes possibles.

  1. Sur l'hôte principal, en tant que SID_LCadm, activez la réplication du système :

    > hdbnsutil -sr_enable --name=primary-host-name

  2. Sur l'hôte secondaire, en tant que SID_LCadm, arrêtez SAP HANA :

    > HDB stop

  3. Sur l'hôte principal, avec le même compte utilisateur que celui utilisé pour configurer SSH entre les VM hôtes, copiez les fichiers de clés sur l'hôte secondaire. Pour plus de commodité, les commandes suivantes définissent également une variable d'environnement pour votre ID de compte utilisateur :

    $ sudo cp /usr/sap/SID/SYS/global/security/rsecssfs ~/rsecssfs -r
$ myid=$(whoami)
$ sudo chown ${myid} -R /home/"${myid}"/rsecssfs
$ scp -r rsecssfs $(whoami)@secondary-host-name:rsecssfs
$ rm -r /home/"${myid}"/rsecssfs

  4. Sur l'hôte secondaire, avec le même utilisateur qu'à l'étape précédente :

    1. Remplacez les fichiers de clés existants dans les répertoires rsecssfs par les fichiers de l'hôte principal, puis définissez des autorisations pour limiter l'accès à ce fichier :

      $ SAPSID=SID
$ sudo rm /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
$ sudo rm /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
$ myid=$(whoami)
$ sudo cp /home/"${myid}"/rsecssfs/data/SSFS_"${SAPSID}".DAT \
  /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
$ sudo cp /home/"${myid}"/rsecssfs/key/SSFS_"${SAPSID}".KEY \
  /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
$ sudo chown "${SAPSID,,}"adm:sapsys \
  /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
$ sudo chown "${SAPSID,,}"adm:sapsys \
  /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY
$ sudo chmod 644 \
  /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/data/SSFS_"${SAPSID}".DAT
$ sudo chmod 640 \
  /usr/sap/"${SAPSID}"/SYS/global/security/rsecssfs/key/SSFS_"${SAPSID}".KEY

    2. Nettoyez les fichiers de votre répertoire d'accueil.

      $ rm -r /home/"${myid}"/rsecssfs

    3. En tant que SID_LCadm, enregistrez le système SAP HANA secondaire avec la réplication du système SAP HANA active :

      > hdbnsutil -sr_register --remoteHost=primary-host-name --remoteInstance=inst_num \
--replicationMode=syncmem --operationMode=logreplay --name=secondary-host-name

    4. En tant que SID_LCadm, démarrez SAP HANA :

      > HDB start

Valider la réplication du système

Sur l'hôte principal, en tant que SID_LCadm, vérifiez que la réplication du système SAP HANA est active en exécutant le script Python suivant :

$ python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py

Si la réplication est correctement configurée, entre autres indicateurs, les valeurs suivantes s'affichent pour les services xsengine, nameserver et indexserver :

  • Secondary Active Status est défini sur YES.
  • Replication Status est défini sur ACTIVE.

En outre, l'état overall system replication status est défini sur ACTIVE.

Configurer la prise en charge du basculement Cloud Load Balancing

Le service d'équilibrage de charge réseau interne à stratégie directe avec prise en charge du basculement achemine le trafic vers l'hôte actif dans un cluster SAP HANA en fonction d'un service de vérification de l'état.

Réserver une adresse IP pour l'adresse IP virtuelle

L'adresse IP virtuelle, parfois appelée adresse IP flottante, suit le système SAP HANA actif. L'équilibreur de charge achemine le trafic envoyé à l'adresse IP virtuelle vers la VM qui héberge actuellement le système SAP HANA actif.

  1. Ouvrez Cloud Shell.

    Accéder à Cloud Shell

  2. Réservez une adresse IP pour l'adresse IP virtuelle. Il s'agit de l'adresse IP utilisée par les applications pour accéder à SAP HANA. Si vous omettez l'option --addresses, une adresse IP du sous-réseau spécifié est choisie pour vous :

    $ gcloud compute addresses create VIP_NAME \
  --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
  --addresses 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.0.0.19
addressType: INTERNAL
creationTimestamp: '2020-05-20T14:19:03.109-07:00'
description: ''
id: '8961491304398200872'
kind: compute#address
name: vip-for-hana-ha
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/vip-for-hana-ha
status: RESERVED
subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-subnet-us-central1

Créer des groupes d'instances pour vos VM hôtes

  1. Dans Cloud Shell, créez deux groupes d'instances non gérés, puis attribuez la VM hôte maître principale à l'un et la VM hôte maître secondaire à l'autre :

    $ gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \
  --zone=PRIMARY_ZONE
$ gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \
  --zone=PRIMARY_ZONE \
  --instances=PRIMARY_HOST_NAME
$ gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \
  --zone=SECONDARY_ZONE
$ gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \
  --zone=SECONDARY_ZONE \
  --instances=SECONDARY_HOST_NAME

  2. 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
hana-ha-ig-1  us-central1-a  example-network  example-project-123456 No       1
hana-ha-ig-2  us-central1-c  example-network  example-project-123456 No       1

Créer une vérification de l'état Compute Engine

  1. Dans Cloud Shell, créez la vérification de l'état. Pour le port utilisé par la vérification de l'état, choisissez un port situé dans la plage privée (49152-65535) afin d'éviter tout conflit avec d'autres services. Les valeurs de l'intervalle entre deux tests et du délai avant expiration 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 :

    $ gcloud compute health-checks create tcp HEALTH_CHECK_NAME --port=HEALTHCHECK_PORT_NUM \
  --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
  --healthy-threshold=2

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

    $ gcloud compute health-checks describe HEALTH_CHECK_NAME

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

    checkIntervalSec: 10
creationTimestamp: '2020-05-20T21:03:06.924-07:00'
healthyThreshold: 2
id: '4963070308818371477'
kind: compute#healthCheck
name: hana-health-check
selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/hana-health-check
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

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 Compute Engine, 35.191.0.0/16 et 130.211.0.0/22. Pour en savoir plus, consultez la section Créer des règles de pare-feu pour les vérifications d'état.

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

    $ gcloud compute instances add-tags PRIMARY_HOST_NAME \
  --tags NETWORK_TAGS \
  --zone PRIMARY_ZONE
$ gcloud compute instances add-tags SECONDARY_HOST_NAME \
  --tags NETWORK_TAGS \
  --zone SECONDARY_ZONE

  2. Si vous n'en avez pas encore, créez une règle de pare-feu pour autoriser les vérifications de l'é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:HLTH_CHK_PORT_NUM

    Exemple :

    gcloud compute firewall-rules create  fw-allow-health-checks \
--network example-network \
--action ALLOW \
--direction INGRESS \
--source-ranges 35.191.0.0/16,130.211.0.0/22 \
--target-tags cluster-ntwk-tag \
--rules tcp:60000

Configurer l'équilibreur de charge et le groupe de basculement

  1. Créez le service de backend de l'équilibreur de charge :

    $ gcloud compute backend-services create BACKEND_SERVICE_NAME \
  --load-balancing-scheme internal \
  --health-checks 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 :

    $ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --instance-group PRIMARY_IG_NAME \
  --instance-group-zone PRIMARY_ZONE \
  --region CLUSTER_REGION

  3. Ajoutez le groupe d'instances de basculement secondaire au service de backend :

    $ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --instance-group SECONDARY_IG_NAME \
  --instance-group-zone SECONDARY_ZONE \
  --failover \
  --region CLUSTER_REGION

  4. Créez une règle de transfert. Pour l'adresse IP, spécifiez celle que vous avez réservée pour l'adresse IP virtuelle : Si vous devez accéder au système SAP HANA en dehors de la région spécifiée ci-dessous, incluez l'indicateur --allow-global-access dans la définition :

    $ gcloud compute forwarding-rules create RULE_NAME \
  --load-balancing-scheme internal \
  --address VIP_ADDRESS \
  --subnet CLUSTER_SUBNET \
  --region CLUSTER_REGION \
  --backend-service BACKEND_SERVICE_NAME \
  --ports ALL

    Pour en savoir plus sur l'accès interrégional à votre système SAP HANA à haute disponibilité, consultez la page Équilibrage de charge TCP/UDP interne.

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 vous servir de l'utilitaire socat pour écouter temporairement le port de vérification de l'état.

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

    $ sudo yum install -y socat

  2. Démarrez un processus socat pour écouter le port de vérification de l'état pendant 60 secondes :

    $ sudo timeout 60s socat - TCP-LISTEN:HLTH_CHK_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 vos groupes d'instances backend :

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

    Le résultat doit être semblable à ceci :

    ---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
   ipAddress: 10.0.0.35
   port: 80
 kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2
   ipAddress: 10.0.0.34
   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, vérifiez l'état de vos groupes d'instances backend :

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

    Le résultat doit être semblable à ceci :

    ---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
   ipAddress: 10.0.0.35
   port: 80
 kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2
   ipAddress: 10.0.0.34
   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 Red Hat d'un cluster Pacemaker sur les VM Compute Engine pour SAP HANA.

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

Installer les agents de cluster sur les deux nœuds

Procédez comme indiqué ci-dessous sur les deux nœuds.

  1. En tant qu'utilisateur racine, installez les composants Pacemaker :

    # yum -y install pcs pacemaker fence-agents-gce resource-agents-gcp resource-agents-sap-hana
# yum update -y

    Si vous utilisez une image RHEL pour SAP fournie par Google, ces packages sont déjà installés, mais certaines mises à jour peuvent être nécessaires.

  2. Définissez le mot de passe de l'utilisateur hacluster, qui est installé dans le cadre des packages :

    # passwd hacluster

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

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

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

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

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

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

    # systemctl status pcsd.service

    Le résultat doit être semblable à ceci :

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

  7. Dans le fichier /etc/hosts, ajoutez le nom d'hôte complet et les adresses IP internes des deux hôtes du cluster. Exemple :

    127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.0.40 hana-ha-vm-1.us-central1-a.c.example-project-123456.internal hana-ha-vm-1  # Added by Google
10.0.0.41 hana-ha-vm-2.us-central1-c.c.example-project-123456.internal hana-ha-vm-2
169.254.169.254 metadata.google.internal  # Added by Google

    Pour plus d'informations Red Hat sur la configuration du fichier /etc/hosts sur les nœuds de cluster RHEL, consultez la page https://access.redhat.com/solutions/81123.

Créer le cluster

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

    RHEL 8 et versions ultérieures

    # pcs host auth primary-host-name secondary-host-name

    RHEL 7

    # pcs cluster auth primary-host-name secondary-host-name

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

  3. Créez le cluster :

    RHEL 8 et versions ultérieures

    # pcs cluster setup cluster-name primary-host-name secondary-host-name

    RHEL 7

    # pcs cluster setup --name cluster-name primary-host-name secondary-host-name

Modifier les paramètres par défaut du fichier corosync.conf

Modifiez le fichier /etc/corosync/corosync.conf sur l'hôte principal afin de définir un point de départ plus approprié pour tester la tolérance aux pannes de votre cluster à haute disponibilité sur Google Cloud.

  1. Sur l'un ou l'autre des hôtes, utilisez l'éditeur de texte de votre choix pour ouvrir le fichier /etc/corosync/corosync.conf afin de le modifier :

    # /etc/corosync/corosync.conf

  2. Si /etc/corosync/corosync.conf est un nouveau fichier ou est vide, vous pouvez consulter le répertoire /etc/corosync/ pour obtenir un exemple de fichier à utiliser comme base pour le fichier Corosync.

  3. Dans la section totem du fichier corosync.conf, ajoutez les propriétés suivantes avec les valeurs suggérées pour votre version de RHEL :

    RHEL 8 et versions ultérieures

    • transport: knet
    • token: 20000
    • token_retransmits_before_loss_const: 10
    • join: 60
    • max_messages: 20

    Exemple :

    totem {
version: 2
cluster_name: hacluster
secauth: off
transport: knet
token: 20000
token_retransmits_before_loss_const: 10
join: 60
max_messages: 20
}
...

    RHEL 7

    • transport: udpu
    • token: 20000
    • token_retransmits_before_loss_const: 10
    • join: 60
    • max_messages: 20

    Exemple :

    totem {
version: 2
cluster_name: hacluster
secauth: off
transport: udpu
token: 20000
token_retransmits_before_loss_const: 10
join: 60
max_messages: 20
}
...

  4. Depuis l'hôte qui contient le fichier corosync.conf modifié, synchronisez la configuration Corosync dans l'ensemble du cluster :

    RHEL 8 et versions ultérieures

    # pcs cluster sync corosync

    RHEL 7

    # pcs cluster sync

  5. Configurez le cluster pour qu'il démarre automatiquement :

    1. # pcs cluster enable --all
    2. # pcs cluster start --all

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

    # corosync-cmapctl

Configurer le cloisonnement

Les images RHEL fournies par Google Cloud incluent un agent de cloisonnement fence_gce spécifique à Google Cloud. Vous utilisez fence_gce afin de créer des appareils de cloisonnement pour chaque VM hôte.

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

Pour afficher toutes les options disponibles avec l'agent de cloisonnement fence_gce, exécutez la commande fence_gce -h.

Créer les ressources de l'appareil de cloisonnement

  1. Sur l'hôte principal, en mode root :

    1. Créez un appareil de cloisonnement pour chaque VM hôte :

      # pcs stonith create primary-fence-name fence_gce \
  port=primary-host-name \
  zone=primary-host-zone \
  project=project-id \
  pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
  op monitor interval="300s" timeout="120s" \
  op start interval="0" timeout="60s"
# pcs stonith create secondary-fence-name fence_gce \
  port=secondary-host-name \
  zone=secondary-host-zone \
  project=project-id \
  pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \
  op monitor interval="300s" timeout="120s" \
  op start interval="0" timeout="60s"

    2. Restreignez chaque appareil de cloisonnement à l'autre VM hôte :

      # pcs constraint location primary-fence-name avoids primary-host-name
# pcs constraint location secondary-fence-name avoids secondary-host-name

  2. Sur l'hôte principal, en tant qu'utilisateur racine, testez l'appareil de cloisonnement secondaire :

    1. Arrêtez la VM hôte secondaire :

      # fence_gce -o off -n secondary-host-name --zone=secondary-host-zone

      Si la commande aboutit, vous perdez la connectivité à la VM hôte secondaire, qui apparaît comme arrêtée sur la page Instances de VM de la console Google Cloud. Vous devrez peut-être actualiser la page.

    2. Redémarrez la VM hôte secondaire :

      # fence_gce -o on -n secondary-host-name --zone=secondary-host-zone

  3. Sur l'hôte secondaire, en tant qu'utilisateur racine, testez l'appareil de cloisonnement principal. Pour ce faire, répétez les étapes précédentes en utilisant les valeurs de l'hôte principal dans les commandes.

  4. Sur l'un ou l'autre des hôtes, en tant qu'utilisateur racine, vérifiez l'état du cluster :

    # pcs status

    Les ressources de cloisonnement apparaissent dans la section des ressources de l'état du cluster, comme dans l'exemple suivant :

    [root@hana-ha-vm-2 ~]# pcs status
Cluster name: hana-ha-cluster
Stack: corosync
Current DC: hana-ha-vm-1 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
Last updated: Mon Jun 15 17:19:07 2020
Last change: Mon Jun 15 17:18:33 2020 by root via cibadmin on hana-ha-vm-1

2 nodes configured
2 resources configured

Online: [ hana-ha-vm-1 hana-ha-vm-2 ]

Full list of resources:

 STONITH-hana-ha-vm-1   (stonith:fence_gce):    Started hana-ha-vm-2
 STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

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

Activer les hooks de fournisseur HA/DR SAP HANA

Red Hat vous recommande d'activer les hooks de fournisseur HA/DR (haute disponibilité/reprise après sinistre) SAP HANA, qui permet à SAP HANA d'envoyer des notifications pour certains événements et améliore la détection des défaillances. Les hooks de fournisseur de haute disponibilité/reprise après sinistre (HA/DR, High Availability/Disaster Recovery) nécessitent SAP HANA 2.0 SPS 03 ou une version ultérieure.

Sur le site principal et le site secondaire, procédez comme suit :

  1. En tant que SID_LCadm, arrêtez SAP HANA :

    > HDB stop

  1. En tant qu'utilisateur racine ou SID_LCadm, ouvrez le fichier global.ini pour le modifier :

    > vi /hana/shared/SID/global/hdb/custom/config/global.ini

  2. Ajoutez les définitions suivantes au fichier global.ini :

    [ha_dr_provider_SAPHanaSR]
provider = SAPHanaSR
path = /usr/share/SAPHanaSR/srHook
execution_order = 1

[trace]
ha_dr_saphanasr = info

  3. En tant qu'utilisateur racine, créez un fichier de configuration personnalisé dans le répertoire /etc/sudoers.d en exécutant la commande suivante. Ce nouveau fichier de configuration permet à l'utilisateur SID_LCadm d'accéder aux attributs de nœud du cluster lorsque la méthode de hook srConnectionChanged() est appelée.

    > sudo visudo -f /etc/sudoers.d/20-saphana

  4. Dans le fichier /etc/sudoers.d/20-saphana, ajoutez le texte suivant :

    Remplacez les éléments suivants :

    • SITE_A : nom du site du serveur SAP HANA principal
    • SITE_B : nom du site du serveur SAP HANA secondaire
    • SID_LC : le SID doit être spécifié en lettres minuscules.
    Pour afficher les noms des sites, vous pouvez exécuter la commande crm_mon -A1 | grep site en tant qu'utilisateur racine, sur le serveur principal SAP HANA ou sur le serveur secondaire. 
    Cmnd_Alias SITEA_SOK = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_A -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias SITEA_SFAIL = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_A -v SFAIL -t crm_config -s SAPHanaSR
Cmnd_Alias SITEB_SOK = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_B -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias SITEB_SFAIL = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_B -v SFAIL -t crm_config -s SAPHanaSR
SID_LCadm ALL=(ALL) NOPASSWD: SITEA_SOK, SITEA_SFAIL, SITEB_SOK, SITEB_SFAIL
Defaults!SITEA_SOK, SITEA_SFAIL, SITEB_SOK, SITEB_SFAIL !requiretty

  5. Dans votre fichier /etc/sudoers, assurez-vous que le texte suivant est inclus :

    #includedir /etc/sudoers.d

    Notez que # dans ce texte fait partie de la syntaxe et ne signifie pas que la ligne est un commentaire.

  6. En tant que SID_LCadm, démarrez SAP HANA :

    > HDB start

  7. Sur l'hôte principal, en tant que SID_LCadm, testez l'état signalé par le script de hook :

    > cdtrace
> awk '/ha_dr_SAPHanaSR.*crm_attribute/ { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*

Définir les valeurs par défaut du cluster

Définissez des seuils de migration et la persistance pour déterminer le nombre de tentatives de basculement à effectuer avant une défaillance et configurer le système de sorte qu'il tente d'abord de redémarrer sur l'hôte actuel. Pour être appliquées au cluster, ces valeurs n'ont besoin d'être définies que sur un nœud.

  1. En tant qu'utilisateur racine, sur l'un ou l'autre des hôtes, démarrez le cluster :

    # pcs cluster start --all #start the cluster

  2. Définissez les valeurs par défaut de la ressource :

    # pcs resource defaults resource-stickiness=1000
# pcs resource defaults migration-threshold=5000

    La propriété resource-stickiness contrôle la probabilité qu'un service continue à s'exécuter là où il se trouve. Plus la valeur est élevée, plus le service est persistant. La valeur 1000 signifie que le service est très persistant.

    La propriété migration-threshold spécifie le nombre de défaillances qui doivent se produire avant qu'un service bascule vers un autre hôte. Une valeur de 5000 est suffisamment élevée pour empêcher le basculement en cas d'erreurs de courte durée.

    Vous pouvez vérifier les valeurs par défaut des ressources en saisissant pcs resource defaults.

  3. Définissez les délais avant expiration d'une opération de ressource par défaut :

    # pcs resource op defaults timeout=600s

    Vous pouvez vérifier les valeurs d'opération par défaut des ressources en saisissant pcs resource op defaults.

  4. Définissez les propriétés de cluster suivantes :

    # pcs property set stonith-enabled="true"
# pcs property set stonith-timeout="300s"

    Vous pouvez vérifier vos paramètres de propriété avec pcs property list.

Créer la ressource SAPHanaTopology

La ressource SAPHanaTopology obtient l'état et la configuration de la réplication du système HANA sur les nœuds. Elle vérifie également l'agent hôte SAP.

  1. En tant qu'utilisateur racine, sur l'un ou l'autre des hôtes, créez la ressource SAPHanaTopology :

    # pcs resource create topology_resource_name SAPHanaTopology SID=SID \
   InstanceNumber=inst_num \
   op start timeout=600 \
   op stop timeout=300 \
   op monitor interval=10 timeout=600 \
   clone clone-max=2 clone-node-max=1 interleave=true

  2. Une fois la ressource créée, vérifiez la configuration. Ajoutez -clone au nom de la ressource pour inclure les informations sur l'ensemble de clones dans la réponse :

    RHEL 8 et versions ultérieures

    # pcs resource config topology_resource_name-clone

    RHEL 7

    # pcs resource show topology_resource_name-clone

    La sortie obtenue doit ressembler à ceci :

    Clone: SAPHanaTopology_HA1_22-clone
Meta Attrs: clone-max=2 clone-node-max=1 interleave=true
Resource: SAPHanaTopology_HA1_22 (class=ocf provider=heartbeat type=SAPHanaTopology)
 Attributes: InstanceNumber=22 SID=HA1
 Operations: methods interval=0s timeout=5 (SAPHanaTopology_HA1_22-methods-interval-0s)
             monitor interval=10 timeout=600 (SAPHanaTopology_HA1_22-monitor-interval-10)
             reload interval=0s timeout=5 (SAPHanaTopology_HA1_22-reload-interval-0s)
             start interval=0s timeout=600 (SAPHanaTopology_HA1_22-start-interval-0s)
             stop interval=0s timeout=300 (SAPHanaTopology_HA1_22-stop-interval-0s)

Vous pouvez également vérifier les attributs du cluster à l'aide de la commande crm_mon -A1.

Créer la ressource SAPHana

L'agent de ressources SAPHana gère les bases de données configurées pour la réplication du système SAP HANA.

Les paramètres suivants de la définition de ressource SAPHana sont facultatifs :

  • AUTOMATED_REGISTER. Lorsque ce paramètre est défini sur true, il enregistre automatiquement l'ancien nœud principal comme nœud secondaire quand DUPLICATE_PRIMARY_TIMEOUT expire après une prise de relais. La valeur par défaut est false.

    Pour un cluster à plusieurs niveaux, si vous utilisez une version antérieure à SAP HANA 2.0 SP03, définissez AUTOMATED_REGISTER sur false. Cela permet d'empêcher une instance récupérée d'essayer de s'enregistrer automatiquement pour la réplication vers un système HANA sur lequel une cible de réplication est déjà configurée. Pour SAP HANA 2.0 SP03 ou pour les versions ultérieures, vous pouvez définir AUTOMATED_REGISTER sur true pour les configurations SAP HANA qui utilisent la réplication système à plusieurs niveaux.

  • DUPLICATE_PRIMARY_TIMEOUT. Ce paramètre définit la différence temporelle entre deux horodatages principaux, en secondes, en cas de doubles nœuds principaux. La valeur par défaut est 7200.

  • PREFER_SITE_TAKEOVER. Ce paramètre détermine si des tentatives de redémarrage local sont effectuées avant le basculement. La valeur par défaut est false.

Pour en savoir plus sur ces paramètres, consultez la page Installer et configurer un cluster à haute disponibilité Red Hat Enterprise Linux 7.6 (et versions ultérieures) sur Google Cloud. Un abonnement Red Hat est requis.

  1. En tant qu'utilisateur racine, sur l'un ou l'autre des hôtes, créez la ressource SAP HANA :

    RHEL 8 et versions ultérieures

    # pcs resource create sap_hana_resource_name SAPHana SID=SID \
InstanceNumber=inst_num \
PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
op start timeout=3600 \
op stop timeout=3600 \
op monitor interval=61 role="Slave" timeout=700 \
op monitor interval=59 role="Master" timeout=700 \
op promote timeout=3600 \
op demote timeout=3600 \
promotable meta notify=true clone-max=2 clone-node-max=1 interleave=true

    RHEL 7

    # pcs resource create sap_hana_resource_name SAPHana SID=SID \
InstanceNumber=inst_num \
PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
op start timeout=3600 \
op stop timeout=3600 \
op monitor interval=61 role="Slave" timeout=700 \
op monitor interval=59 role="Master" timeout=700 \
op promote timeout=3600 \
op demote timeout=3600 \
master meta notify=true clone-max=2 clone-node-max=1 interleave=true

  2. Vérifiez les attributs de ressource générés :

    RHEL 8 et versions ultérieures

    # pcs resource config sap_hana_resource_name

    RHEL 7

    # pcs resource show sap_hana_resource_name

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

     Resource: SAPHana_HA1_22 (class=ocf provider=heartbeat type=SAPHana)
  Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=22 PREFER_SITE_TAKEOVER=true SID=HA1
  Meta Attrs: clone-max=2 clone-node-max=1 interleave=true notify=true
  Operations: demote interval=0s timeout=3600 (SAPHana_HA1_22-demote-interval-0s)
              methods interval=0s timeout=5 (SAPHana_HA1_22-methods-interval-0s)
              monitor interval=61 role=Slave timeout=700 (SAPHana_HA1_22-monitor-interval-61)
              monitor interval=59 role=Master timeout=700 (SAPHana_HA1_22-monitor-interval-59)
              promote interval=0s timeout=3600 (SAPHana_HA1_22-promote-interval-0s)
              reload interval=0s timeout=5 (SAPHana_HA1_22-reload-interval-0s)
              start interval=0s timeout=3600 (SAPHana_HA1_22-start-interval-0s)
              stop interval=0s timeout=3600 (SAPHana_HA1_22-stop-interval-0s)

  3. Une fois la ressource démarrée, vérifiez les attributs de nœud pour voir l'état actuel des bases de données SAP HANA sur les nœuds :

    # crm_mon -A1

    Le résultat doit être semblable à ceci :

    Stack: corosync
Current DC: hana-ha-vm-2 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
Last updated: Tue Jun 16 20:07:51 2020
Last change: Tue Jun 16 20:07:26 2020 by root via crm_attribute on hana-ha-vm-1

2 nodes configured
6 resources configured

Online: [ hana-ha-vm-1 hana-ha-vm-2 ]

Active resources:

STONITH-hana-ha-vm-1   (stonith:fence_gce):    Started hana-ha-vm-2
STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1
Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
    Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
    Masters: [ hana-ha-vm-1 ]
    Slaves: [ hana-ha-vm-2 ]

Node Attributes:
* Node hana-ha-vm-1:
   + hana_ha1_clone_state              : PROMOTED
   + hana_ha1_op_mode                  : logreplay
   + hana_ha1_remoteHost               : hana-ha-vm-2
   + hana_ha1_roles                    : 4:P:master1:master:worker:master
   + hana_ha1_site                     : hana-ha-vm-1
   + hana_ha1_srmode                   : syncmem
   + hana_ha1_sync_state               : PRIM
   + hana_ha1_version                  : 1.00.122.27.1568902538
   + hana_ha1_vhost                    : hana-ha-vm-1
   + lpa_ha1_lpt                       : 1592338046
   + master-SAPHana_HA1_22             : 150
* Node hana-ha-vm-2:
   + hana_ha1_clone_state              : DEMOTED
   + hana_ha1_op_mode                  : logreplay
   + hana_ha1_remoteHost               : hana-ha-vm-1
   + hana_ha1_roles                    : 4:S:master1:master:worker:master
   + hana_ha1_site                     : hana-ha-vm-2
   + hana_ha1_srmode                   : syncmem
   + hana_ha1_sync_state               : SOK
   + hana_ha1_version                  : 1.00.122.27.1568902538
   + hana_ha1_vhost                    : hana-ha-vm-2
   + lpa_ha1_lpt                       : 30
   + master-SAPHana_HA1_22             : 100

Créer une ressource d'adresse IP virtuelle

Vous devez créer une ressource de cluster pour l'adresse IP virtuelle. La ressource d'adresse IP virtuelle est localisée sur le système d'exploitation principal et n'est pas routable par d'autres hôtes. L'équilibreur de charge achemine le trafic envoyé à l'adresse IP virtuelle vers l'hôte de backend en fonction de la vérification de l'état.

En tant qu'utilisateur racine, sur l'un ou l'autre des hôtes :

# pcs resource create resource_name \
  IPaddr2 ip="vip-address" nic=eth0 cidr_netmask=32 \
  op monitor interval=3600s timeout=60s

La valeur vip-address est la même adresse IP que celle que vous avez réservée précédemment et que vous avez spécifiée dans la règle de transfert pour le frontend de votre équilibreur de charge. Modifiez l'interface réseau en fonction de votre configuration.

Créer les contraintes

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

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

    RHEL 8 et versions ultérieures

    # pcs constraint order topology_resource_name-clone \
then sap_hana_resource_name-clone symmetrical=false

    RHEL 7

    # pcs constraint order topology_resource_name-clone \
then sap_hana_resource_name-master symmetrical=false

    La spécification de symmetrical=false signifie que la contrainte ne s'applique qu'au démarrage et non à l'arrêt.

    Cependant, comme vous avez défini interleave=true pour ces ressources à une étape précédente, les processus peuvent démarrer en parallèle. En d'autres termes, vous pouvez démarrer SAPHana sur n'importe quel nœud dès lors que SAPHanaTopology est en cours d'exécution.

  2. Vérifiez les contraintes :

    # pcs constraint

    Le résultat doit être semblable à ceci :

    Location Constraints:
 Resource: STONITH-hana-ha-vm-1
   Disabled on:
     Node: hana-ha-vm-1 (score:-INFINITY)
 Resource: STONITH-hana-ha-vm-2
   Disabled on:
     Node: hana-ha-vm-2 (score:-INFINITY)
Ordering Constraints:
 start SAPHanaTopology_HA1_22-clone then start SAPHana_HA1_22-master (kind:Mandatory) (non-symmetrical)
Colocation Constraints:
Ticket Constraints:

Installer des écouteurs et créer une ressource de vérification de l'état

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

Installer un écouteur

L'équilibreur de charge utilise un écouteur sur le port de vérification de l'état de chaque hôte afin de déterminer où l'instance principale du cluster SAP HANA est exécutée. 1. Installez un écouteur TCP en mode root sur l'instance maître du système principal et celle du système secondaire. Ces instructions permettent d'installer et d'utiliser HAProxy comme écouteur. 

# yum install haproxy

  1. Ouvrez le fichier de configuration haproxy.cfg pour le modifier :

    # vi /etc/haproxy/haproxy.cfg

    1. Dans la section defaults du fichier haproxy.cfg, remplacez mode par tcp.

    2. Après la section defaults, créez une section en ajoutant :

      #---------------------------------------------------------------------
# Health check listener port for SAP HANA HA cluster
#---------------------------------------------------------------------
listen healthcheck
  bind *:healthcheck-port-num

      Le port de liaison est le même que celui utilisé lors de la création de la vérification de l'état.

      Lorsque vous avez terminé, vos modifications doivent ressembler à l'exemple suivant :

      #---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
  mode                    tcp
  log                     global
  option                  tcplog
  option                  dontlognull
  option http-server-close
  # option forwardfor       except 127.0.0.0/8
  option                  redispatch
  retries                 3
  timeout http-request    10s
  timeout queue           1m
  timeout connect         10s
  timeout client          1m
  timeout server          1m
  timeout http-keep-alive 10s
  timeout check           10s
  maxconn                 3000

#---------------------------------------------------------------------
# Set up health check listener for SAP HANA HA cluster
#---------------------------------------------------------------------
listen healthcheck
 bind *:60000

  2. Sur chaque hôte, en tant qu'utilisateur racine, démarrez le service pour vérifier qu'il est correctement configuré :

    # systemctl start haproxy.service

  3. Sur la page "Équilibrage de charge" de la console Google Cloud, cliquez sur l'entrée de l'équilibreur de charge :

    Page "Équilibrage de charge"

    Dans la section Backend de la page Détails de l'équilibreur de charge, si le service HAProxy est actif sur les deux hôtes, 1/1 s'affiche dans la colonne Healthy (Opérationnel) de chaque entrée de groupe d'instances.

    La capture d'écran affiche "1/1" dans la colonne "Healthy" (Opérationnel) des deux groupes d'instances, ce qui indique qu'ils sont tous les deux opérationnels.

  4. Sur chaque hôte, arrêtez le service HAProxy :

    # systemctl stop haproxy.service

    Une fois que vous avez arrêté le service HAProxy sur chaque hôte, 0/1 s'affiche dans la colonne Healthy (Opérationnel) de chaque groupe d'instances.

    La capture d'écran affiche "0/1" dans la colonne "Healthy" (Opérationnel) de chaque groupe d'instances, ce qui indique qu'il n'y a pas d'écouteur actif.

    Plus tard, lorsque la vérification de l'état sera configurée, le cluster relancera l'écouteur sur le nœud maître.

Créer la ressource de vérification de l'état

  1. Sur l'un ou l'autre des hôtes en mode root, créez une ressource de vérification de l'état pour le service HAProxy :

    # pcs resource create healthcheck_resource_name service:haproxy op monitor interval=10s timeout=20s

  2. Vérifiez que le service de vérification de l'état est actif sur le même hôte que votre instance SAP HANA maître et votre ressource d'adresse IP virtuelle :

    # pcs status

    Si la ressource de vérification de l'état ne se trouve pas sur l'hôte principal, déplacez-la à l'aide de la commande suivante :

    # pcs resource move healthcheck_resource_name target_host_name
# pcs resource clear healthcheck_resource_name

    La commande pcs resource clear laisse la ressource à son nouvel emplacement, mais supprime la contrainte d'emplacement indésirable créée par la commande pcs resource move.

    Dans l'état, la section des ressources doit ressembler à l'exemple suivant :

    Full list of resources:

STONITH-hana-ha-vm-1   (stonith:fence_gce):    Started hana-ha-vm-2
STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1
Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
    Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
    Masters: [ hana-ha-vm-1 ]
    Slaves: [ hana-ha-vm-2 ]
rsc_vip_HA1_22 (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
rsc_healthcheck_HA1    (service:haproxy):      Started hana-ha-vm-2

  3. Regroupez les ressources d'adresse IP virtuelle et de vérification de l'état :

    # pcs resource group add rsc-group-name healthcheck_resource_name vip_resource_name

    Dans l'état du cluster, la section des ressources doit ressembler à l'exemple suivant :

    Full list of resources:

STONITH-hana-ha-vm-1   (stonith:fence_gce):    Started hana-ha-vm-2
STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1
Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
    Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
    Masters: [ hana-ha-vm-1 ]
    Slaves: [ hana-ha-vm-2 ]
Resource Group: g-primary
    rsc_healthcheck_HA1        (service:haproxy):      Started hana-ha-vm-1
    rsc_vip_HA1_22     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1

  4. Créez une contrainte qui situe le nouveau groupe sur le même nœud que l'instance SAP HANA maître.

    RHEL 8 et versions ultérieures

    # pcs constraint colocation add rsc-group-name with master sap_hana_resource_name-clone 4000

    RHEL 7

    # pcs constraint colocation add rsc-group-name with master sap_hana_resource_name-master 4000

    Vos contraintes finales doivent ressembler à l'exemple suivant :

    # pcs constraint
Location Constraints:
 Resource: STONITH-hana-ha-vm-1
   Disabled on:
     Node: hana-ha-vm-1 (score:-INFINITY)
 Resource: STONITH-hana-ha-vm-2
   Disabled on:
     Node: hana-ha-vm-2 (score:-INFINITY)
Ordering Constraints:
 start SAPHanaTopology_HA1_22-clone then start SAPHana_HA1_22-master (kind:Mandatory) (non-symmetrical)
Colocation Constraints:
 g-primary with SAPHana_HA1_22-master (score:4000) (rsc-role:Started) (with-rsc-role:Master)
Ticket Constraints:

Tester le basculement

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

Sauvegardez le système avant le test.

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

  • HDB stop
  • HDB kill
  • reboot (sur le nœud actif)
  • ip link set eth0 down pour les instances avec une seule interface réseau
  • iptables ... DROP pour les instances avec plusieurs interfaces réseau
  • echo c > /proc/sysrq-trigger

Ces instructions utilisent ip link set eth0 down ou iptables pour simuler une interruption du réseau entre vos deux hôtes du cluster. Exécutez la commande ip link sur une instance dotée d'une seule interface réseau, et la commande iptables sur les instances possédant une ou plusieurs interfaces réseau. Le test valide le basculement et le cloisonnement. Si plusieurs interfaces réseau sont définies sur vos instances, utilisez la commande iptables sur l'hôte secondaire pour abandonner le trafic entrant et sortant en fonction de l'adresse IP utilisée par l'hôte principal pour la communication des clusters, ce qui simule ainsi une perte de connexion réseau à l'instance principale.

  1. Sur l'hôte actif, en tant qu'utilisateur racine, déconnectez l'interface réseau :

    # ip link set eth0 down

    Ou, si plusieurs interfaces réseau sont actives, à l'aide de iptables sur l'hôte secondaire :

    # iptables -A INPUT -s PRIMARY_CLUSTER_IP -j DROP; iptables -A OUTPUT -d PRIMARY_CLUSTER_IP -j DROP

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

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

    Cluster name: hana-ha-cluster
Stack: corosync
Current DC: hana-ha-vm-2 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
Last updated: Wed Jun 17 01:04:36 2020
Last change: Wed Jun 17 01:03:58 2020 by root via crm_attribute on hana-ha-vm-2

2 nodes configured
8 resources configured

Online: [ hana-ha-vm-1 hana-ha-vm-2 ]

Full list of resources:

STONITH-hana-ha-vm-1   (stonith:fence_gce):    Started hana-ha-vm-2
STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1

Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
    Started: [ hana-ha-vm-1 hana-ha-vm-2  ]
Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
    Masters: [ hana-ha-vm-2 ]
    Slaves: [ hana-ha-vm-1  ]
Resource Group: g-primary
    rsc_healthcheck_HA1        (service:haproxy):      Started hana-ha-vm-2
    rsc_vip_HA1_22     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-2

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

Configurer HANA actif/actif (lecture activée)

À partir de SAP HANA 2.0 SPS1, vous pouvez configurer HANA actif/actif (lecture activée) dans un cluster Pacemaker. Cette opération est facultative.

Pour configurer HANA actif/actif (lecture activée) dans un cluster Pacemaker, procédez comme suit :

Configurer la prise en charge du basculement Cloud Load Balancing pour l'hôte secondaire

Le service d'équilibrage de charge réseau interne à stratégie directe avec prise en charge du basculement achemine le trafic vers l'hôte secondaire dans un cluster SAP HANA en fonction d'un service de vérification de l'état.

Pour configurer la prise en charge du basculement de l'hôte secondaire, procédez comme suit :

  1. Ouvrez Cloud Shell.

    Accéder à Cloud Shell

  2. Réservez une adresse IP pour l'adresse IP virtuelle en exécutant la commande suivante.

    L'adresse IP virtuelle (VIP) suit le système SAP HANA secondaire. Il s'agit de l'adresse IP utilisée par les applications pour accéder à votre système SAP HANA secondaire. L'équilibreur de charge achemine le trafic envoyé à l'adresse IP virtuelle vers l'instance de VM qui héberge actuellement le système secondaire.

    Si vous omettez l'option --addresses dans la commande suivante, une adresse IP du sous-réseau spécifié est choisie pour vous. Pour en savoir plus sur la réservation d'une adresse IP statique, consultez la page Réserver une adresse IP interne statique.

    $ gcloud compute addresses create secondary-vip-name \
  --region cluster-region --subnet cluster-subnet \
  --addresses secondary-vip-address

  3. Créez une vérification d'état Compute Engine en exécutant la commande suivante.

    Pour le port utilisé par la vérification d'état, choisissez un port situé dans la plage privée (49152-65535) afin d'éviter tout conflit avec d'autres services. Le port doit être différent de celui configuré pour la vérification d'état utilisée pour l'accès au système principal HANA. Les valeurs de l'intervalle entre deux tests et du délai avant expiration 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.

    $ gcloud compute health-checks create tcp secondary-health-check-name \
  --port=secondary-healthcheck-port-num \
  --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
  --healthy-threshold=2

  4. Configurez l'équilibreur de charge et le groupe de basculement en exécutant les commandes suivantes.

    Ici, vous créez un service de backend supplémentaire et utilisez les mêmes groupes d'instances que ceux créés précédemment pour le service de backend derrière l'équilibreur de charge TCP/UDP interne de votre système principal SAP HANA.

    1. Créez le service de backend de l'équilibreur de charge :

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

      $ gcloud compute backend-services add-backend secondary-backend-service-name \
  --instance-group primary-ig-name \
  --instance-group-zone primary-zone \
  --region cluster-region

    3. Ajoutez le groupe d'instances de basculement secondaire au service de backend :

      $ gcloud compute backend-services add-backend secondary-backend-service-name \
  --instance-group secondary-ig-name \
  --instance-group-zone secondary-zone \
  --failover \
  --region cluster-region

    4. Créez une règle de transfert.

      Pour l'option d'adresse IP, spécifiez celle que vous avez réservée pour l'adresse IP virtuelle. Si vous devez accéder au système secondaire HANA en dehors de la région spécifiée dans la commande suivante, incluez l'option --allow-global-access dans la définition de la règle de transfert.

      $ gcloud compute forwarding-rules create secondary-rule-name \
  --load-balancing-scheme internal \
  --address secondary-vip-name \
  --subnet cluster-subnet \
  --region cluster-region \
  --backend-service secondary-backend-service-name \
  --ports ALL

      Pour en savoir plus sur l'accès interrégional à votre système SAP HANA à haute disponibilité, consultez la page Équilibrage de charge TCP/UDP interne.

Activer HANA actif/actif (lecture activée)

Sur votre hôte secondaire, activez le mode actif/actif (lecture activée) pour la réplication du système SAP HANA en procédant comme suit :

  1. En tant qu'utilisateur racine, placez le cluster en mode de maintenance :

    $ pcs property set maintenance-mode=true

  2. En tant que SID_LCadm, arrêtez SAP HANA :

    > HDB stop

  3. En tant que SID_LCadm, réenregistrez le système secondaire HANA avec la réplication du système SAP HANA à l'aide du mode d'opération logreplay_readaccess :

    > hdbnsutil -sr_register --remoteHost=primary-host-name --remoteInstance=inst_num \
 --replicationMode=syncmem --operationMode=logreplay_readaccess --name=secondary-host-name

  4. En tant que SID_LCadm, démarrez SAP HANA :

    > HDB start

  5. En tant que SID_LCadm, confirmez que l'état de la synchronisation HANA est bien ACTIVE :

    > cdpy; python systemReplicationStatus.py --sapcontrol=1 | grep overall_replication_status

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

    overall_replication_status=ACTIVE

Configurer Pacemaker

Configurez votre cluster à haute disponibilité Pacemaker en mode actif/actif (lecture activée) en exécutant les commandes suivantes en tant qu'utilisateur racine :

  1. Configurez des écouteurs pour les vérifications d'état :

    1. Copiez et renommez le fichier de configuration haproxy.service par défaut afin d'en faire un fichier de modèle pour plusieurs instances haproxy :

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

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

      RHEL 7

      [Unit]
Description=HAProxy Load Balancer %i
After=network-online.target
      


      [Service]
EnvironmentFile=/etc/sysconfig/haproxy
ExecStart=/usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy-%i.cfg -p /run/haproxy-%i.pid $OPTIONS
...

      RHEL 8

      [Unit]
Description=HAProxy Load Balancer %i
After=network-online.target
Wants=network-online.target
      


      [Service]
Environment="CONFIG=/etc/haproxy/haproxy-%i.cfg" "PIDFILE=/run/haproxy-%i.pid"
...

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

    3. Créez un fichier de configuration haproxy.cfg pour votre système principal SAP HANA. Exemple :

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

    4. Dans le fichier de configuration haproxy-primary.cfg de votre système principal SAP HANA, ajoutez la configuration suivante et remplacez healthcheck-port-num par le numéro de port que vous avez spécifié lors de la création de la vérification d'état Compute Engine pour le système principal HANA :

      global
  chroot      /var/lib/haproxy
  pidfile     /var/run/haproxy-%i.pid
  user        haproxy
  group       haproxy
  daemon
defaults
  mode                    tcp
  log                     global
  option                  dontlognull
  option                  redispatch
  retries                 3
  timeout queue           1m
  timeout connect         10s
  timeout client          1m
  timeout server          1m
  timeout check           10s
  maxconn                 3000

# Listener for SAP healthcheck
listen healthcheck
  bind *:healthcheck-port-num

    5. Créez un fichier de configuration haproxy.cfg pour votre système secondaire SAP HANA. Exemple :

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

    6. Dans le fichier de configuration haproxy-secondary.cfg de votre système secondaire SAP HANA, ajoutez la configuration suivante et remplacez secondary-healthcheck-port-num par le numéro de port que vous avez spécifié lors de la création de la vérification d'état Compute Engine pour le système secondaire HANA :

      global
  chroot      /var/lib/haproxy
  pidfile     /var/run/haproxy-%i.pid
  user        haproxy
  group       haproxy
  daemon
defaults
  mode                    tcp
  log                     global
  option                  dontlognull
  option                  redispatch
  retries                 3
  timeout queue           1m
  timeout connect         10s
  timeout client          1m
  timeout server          1m
  timeout check           10s
  maxconn                 3000

# Listener for SAP healthcheck
listen healthcheck
  bind *:secondary-healthcheck-port-num

    7. Supprimez la configuration d'écouteur existante de /etc/haproxy/haproxy.cfg :

      #---------------------------------------------------------------------
# Health check listener port for SAP HANA HA cluster
#---------------------------------------------------------------------
listen healthcheck
  bind *:healthcheck-port-num

    8. Actualisez les services systemd pour charger les modifications :

      # systemctl daemon-reload

    9. Vérifiez que les deux services haproxy sont correctement configurés :

      # systemctl start haproxy@primary
# systemctl start haproxy@secondary

# systemctl status haproxy@primary
# systemctl status haproxy@secondary

      L'état renvoyé doit afficher haproxy@primary.service et haproxy@secondary.service en tant que active (running). Voici un exemple de résultat pour haproxy@primary.service :

      ● haproxy@primary.service - Cluster Controlled haproxy@primary
  Loaded: loaded (/etc/systemd/system/haproxy@.service; disabled; vendor preset: disabled)
  Drop-In: /run/systemd/system/haproxy@primary.service.d
           └─50-pacemaker.conf
  Active: active (running) since Fri 2022-10-07 23:36:09 UTC; 1h 13min ago
Main PID: 21064 (haproxy-systemd)
  CGroup: /system.slice/system-haproxy.slice/haproxy@primary.service
          ├─21064 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy-primary.cfg -p /run/hapro...
          ├─21066 /usr/sbin/haproxy -f /etc/haproxy/haproxy-primary.cfg -p /run/haproxy-primary.pid -...
          └─21067 /usr/sbin/haproxy -f /etc/haproxy/haproxy-primary.cfg -p /run/haproxy-primary.pid -...

Oct 07 23:36:09 hana-ha-vm-1 systemd[1]: Started Cluster Controlled haproxy@primary.

    10. 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 dans les services de backend principal et secondaire :

      $ gcloud compute backend-services get-health backend-service-name \
  --region cluster-region
      $ gcloud compute backend-services get-health secondary-backend-service-name \
  --region cluster-region

      Un résultat semblable au suivant doit s'afficher, indiquant la VM sur laquelle vous travaillez actuellement avec le healthState HEALTHY :

      ---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1
status:
healthStatus:
‐ healthState: HEALTHY
  instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
  ipAddress: 10.0.0.35
  port: 80
kind: compute#backendServiceGroupHealth

    11. Arrêtez les deux services pour laisser Pacemaker les gérer :

      # systemctl stop haproxy@primary
# systemctl stop haproxy@secondary

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

  2. Créez une ressource IP de cluster locale pour l'adresse IP virtuelle que vous avez réservée pour le système secondaire :

    # pcs resource create secondary_vip_resource_name \
  IPaddr2 ip="secondary-vip-address" nic=eth0 cidr_netmask=32 \
  op monitor interval=3600s timeout=60s

  3. Configurez le service de vérification d'état de l'outil d'aide en exécutant les commandes suivantes.

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

    1. Pour gérer les écouteurs dans le cluster, vous devez créer une ressource pour l'écouteur :

      1. Supprimez la ressource pour le service de vérification d'état pour le système principal HANA :

        # pcs resource delete healthcheck_resource_name --force

      2. Ajoutez une nouvelle ressource pour le service de vérification d'état pour le système principal HANA :

        # pcs resource create primary_healthcheck_resource_name \
 service:haproxy@primary op monitor interval=10s timeout=20s

      3. Ajoutez une nouvelle ressource pour le service de vérification d'état pour le système secondaire HANA :

        # pcs resource create secondary_healthcheck_resource_name \
 service:haproxy@secondary op monitor interval=10s timeout=20s

    2. Regroupez les ressources de l'adresse IP virtuelle et du service de vérification d'état de l'outil d'aide

      1. Ajoutez la nouvelle ressource de vérification d'état au groupe de ressources existant pour les ressources d'adresse IP virtuelle principale :

        # pcs resource group add rsc-group-name primary_healthcheck_resource_name \
 --before vip_resource_name

      2. Ajoutez un nouveau groupe de ressources afin de regrouper les ressources de l'adresse IP virtuelle et du service de vérification d'état de l'outil d'aide pour le système secondaire HANA :

        # pcs resource group add secondary-rsc-group-name \
 secondary_healthcheck_resource_name secondary_vip_resource_name

  4. Créez deux contraintes d'emplacement en exécutant les commandes suivantes :

    Ces contraintes permettent de s'assurer que le groupe de ressources d'adresse IP virtuelle secondaire est placé sur le nœud de cluster approprié :

    # pcs constraint location secondary-rsc-group-name rule score=INFINITY \
  hana_sid_sync_state eq SOK and hana_sid_roles eq 4:S:master1:master:worker:master
    # pcs constraint location secondary-rsc-group-name rule score=2000 \
  hana_sid_sync_state eq PRIM and hana_sid_roles eq 4:P:master1:master:worker:master

  5. Quittez le mode de maintenance du cluster :

    # pcs property set maintenance-mode=false

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

    # pcs status

    Les exemples suivants montrent l'état d'un cluster actif et correctement configuré pour la réplication du système SAP HANA en mode actif/actif (lecture activée). Un groupe de ressources supplémentaire doit s'afficher pour les ressources VIP du système secondaire. Dans l'exemple suivant, le nom de ce groupe de ressources est g-secondary.

    Cluster name: hacluster
  Stack: corosync
  Current DC: hana-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
  Last updated: Sat Oct  8 00:37:08 2022
  Last change: Sat Oct  8 00:36:57 2022 by root via crm_attribute on hana-test-2

  2 nodes configured
  10 resource instances configured

Online: [ hana-ha-vm-1 hana-ha-vm-2 ]

Full list of resources:
  STONITH-hana-ha-vm-1    (stonith:fence_gce):    Started hana-ha-vm-2
  STONITH-hana-ha-vm-2    (stonith:fence_gce):    Started hana-ha-vm-1
  Resource Group: g-primary
    rsc_healthcheck_HA1-primary        (service:haproxy@primary):      Started hana-ha-vm-1
    rsc_vip_HA1_00     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
  Clone Set: SAPHanaTopology_HA1_00-clone [SAPHanaTopology_HA1_00]
    Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
  Master/Slave Set: SAPHana_HA1_00-master [SAPHana_HA1_00]
    Masters: [ hana-ha-vm-1 ]
    Slaves: [ hana-ha-vm-2 ]
  Clone Set: msl_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00] (promotable):
    Masters: [ hana-ha-vm-1 ]
    Slaves: [ hana-ha-vm-2 ]
  Resource Group: g-secondary
    rsc_healthcheck_HA1-secondary        (service:haproxy@secondary):      Started hana-ha-vm-2
    rsc_vip_HA1_00-secondary     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-2

Évaluer votre charge de travail SAP HANA

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

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

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

Dépannage

Pour résoudre les problèmes liés aux configurations à haute disponibilité pour SAP HANA sur RHEL, consultez la section Résoudre les problèmes de configuration à haute disponibilité pour SAP.

Obtenir de l'aide concernant SAP HANA sur RHEL

Si vous avez besoin d'aide pour résoudre un problème lié à des clusters à haute disponibilité pour SAP HANA sur RHEL, 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é RHEL.

Assistance

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

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

Exigences liées à l'assistance

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

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

Se connecter à SAP HANA

Si les VM hôtes ne disposent pas d'adresse IP externe pour SAP HANA, vous ne pouvez vous connecter aux instances SAP HANA que via l'instance bastion à l'aide de SSH ou via le serveur Windows à l'aide de SAP HANA Studio.

  • Pour vous connecter à SAP HANA via l'instance bastion, connectez-vous à l'hôte bastion, puis aux instances SAP HANA à l'aide du client SSH de votre choix.

  • Pour vous connecter à la base de données SAP HANA via SAP HANA Studio, utilisez un client Bureau à distance pour vous connecter à l'instance Windows Server. Une fois la connexion établie, installez SAP HANA Studio manuellement, puis accédez à votre base de données SAP HANA.

Tâches post-déploiement

Une fois le déploiement terminé, procédez comme suit :

  1. Modifiez les mots de passe temporaires de l'administrateur système et du super-utilisateur du système SAP HANA. Exemple :

    sudo passwd SID_LCadm

    Pour en savoir plus sur la modification du mot de passe, consultez la section Réinitialiser le mot de passe utilisateur SYSTEM du système de base de données.

  2. Avant d'utiliser votre instance SAP HANA, configurez et sauvegardez votre nouvelle base de données SAP HANA.

  3. Si votre système SAP HANA est déployé sur une interface réseau VirtIO, nous vous recommandons de vous assurer que la valeur du paramètre TCP /proc/sys/net/ipv4/tcp_limit_output_bytes est définie sur 1048576. Cette modification permet d'améliorer le débit réseau global sur l'interface réseau VirtIO sans affecter la latence du réseau.

Pour en savoir plus, consultez les pages suivantes :

Étapes suivantes

Pour en savoir plus, consultez les ressources suivantes :