Guide de configuration d'un cluster à haute disponibilité et à évolutivité horizontale pour SAP HANA sur RHEL

Ce guide explique comment déployer et configurer manuellement un cluster à haute disponibilité Red Hat Enterprise Linux (RHEL) pour un système SAP HANA à scaling horizontal sur Google Cloud utilisant un équilibreur de charge réseau passthrough interne pour gérer l'adresse IP virtuelle.

Ce guide comprend les étapes suivantes :

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

Ce guide comprend également les étapes de configuration 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.

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 un système SAP HANA multinœud à haute disponibilité configuré pour une redondance complète de la zone avec une instance supplémentaire agissant en tant que créatrice de majorité, également appelée nœud de départage, ce qui garantit que le quorum du cluster est maintenu en cas de perte d'une zone.

Le déploiement final comprend les ressources suivantes :

• Un site principal et un site secondaire sur lesquels chaque instance possède un équivalent zonal.
• Deux sites configurés pour la réplication synchrone.
• Une instance de calcul unique agissant en tant que créatrice de majorité.
• Un gestionnaire de ressources de cluster Pacemaker à haute disponibilité avec un mécanisme de cloisonnement
• Un ou des disques persistants pour les données SAP HANA et les volumes de journaux associés à chaque instance SAP HANA.

Ce guide utilise les modèles Terraform 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 :

• Installer SAP HANA Studio sur une VM Compute Engine pour Windows
• Guide d'installation et de mise à jour de SAP HANA Studio

Prérequis

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

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

• Le support d'installation de SAP HANA se trouve dans un bucket Cloud Storage disponible dans votre projet et votre région de déploiement. Pour savoir comment importer le support d'installation de SAP HANA dans un bucket Cloud Storage, consultez la section relative au téléchargement de SAP HANA dans le Guide de déploiement de SAP HANA.

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

  Pour en savoir plus, consultez les pages suivantes :

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

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

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

• Vous disposez d'une solution NFS, telle que la solution Filestore, pour partager les volumes SAP HANA /hana/shared et /hanabackup entre les hôtes du système à évolutivité horizontale SAP HANA. Pour déployer des serveurs Filestore NFS, consultez la page Créer des instances.

  • Notez que les sites principal et secondaire doivent avoir accès à leurs propres chemins NFS dédiés afin d'éviter d'écraser des données. Pour utiliser une seule instance Filestore, vous devez configurer le déploiement de sorte que des sous-répertoires distincts soient utilisés comme chemin d'installation.

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

• Utilisez une passerelle NAT.
• Créez des règles de pare-feu qui bloquent tous les accès externes dont vous n'avez pas besoin.
• Lorsque vous créez vos VM, effectuez les opérations suivantes :
  • Spécifiez pour chaque VM un tag réseau à utiliser dans les règles de routage et de pare-feu. Si vous utilisez le fichier de configuration Terraform fourni par Google Cloud, spécifiez un tag avec network_tags = "TAG".
  • Créez les VM sans adresse IP externe. Si vous utilisez le fichier de configuration Terraform fourni par Google Cloud, spécifiez public_ip = false.

Créer un réseau

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

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

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

Pour créer un réseau VPC pour votre projet, procédez comme suit :

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

2. Créez un sous-réseau, puis spécifiez la région et la plage d'adresses IP. Pour plus d'informations, consultez la section Ajouter des sous-réseaux.

Configurer une passerelle NAT

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

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

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

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

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

Ajouter des règles de pare-feu

Par défaut, 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.

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

Déployer les VM et SAP HANA

Ce guide utilise un fichier de configuration Terraform fourni par Google Cloud pour déployer les éléments suivants :

• Deux systèmes SAP HANA concordants, chacun avec au moins deux instances de VM.
• Une instance créatrice de majorité, également appelée nœud de départage, qui garantit que le quorum du cluster est maintenu en cas de perte d'une zone.

Les systèmes SAP HANA utilisent la réplication de système asynchrone, de sorte que l'un des systèmes SAP HANA fonctionne en tant que système principal, c'est-à-dire le système actif, et l'autre en tant que système secondaire, c'est-à-dire le système de secours. Vous déployez les deux systèmes SAP HANA dans la même région, de préférence dans différentes zones.

Si vous avez besoin d'un système à évolutivité horizontale avec des hôtes de secours pour le basculement automatique de l'hôte SAP HANA, vous devez consulter :Terraform: Guide de déploiement du système SAP HANA à scaling horizontal avec basculement automatique des hôtes.

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

Les instructions suivantes utilisent Cloud Shell, mais sont généralement applicables à un terminal local sur lequel Terraform est installé et configuré avec le fournisseur Google.

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 les quotas sont insuffisants, votre déploiement échoue.

   Pour connaître les exigences de quotas de SAP HANA, consultez la section Remarques concernant les tarifs et les quotas applicables à SAP HANA.

   Accéder à la section "Quotas"

2. Ouvrez Cloud Shell ou votre terminal local.

   Ouvrir Cloud Shell

3. Téléchargez le fichier de configuration manual_sap_hana_scaleout_ha.tf dans votre répertoire de travail en exécutant la commande suivante dans Cloud Shell ou dans votre terminal :

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

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

4. Ouvrez le fichier manual_sap_hana_scaleout_ha.tf dans l'éditeur de code Cloud Shell ou, si vous utilisez votre terminal, ouvrez-le 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.

5. Dans le fichier manual_sap_hana_scaleout_ha.tf, mettez à jour les valeurs d'argument pour sap_hana_primary et sap_hana_secondary en remplaçant le contenu entre guillemets doubles par les valeurs correspondant à votre installation. Les arguments sont décrits dans le tableau suivant.

   Argument	Type de données	Description
   source	Chaîne	Spécifie l'emplacement et la version du module Terraform à utiliser lors du déploiement. Le fichier de configuration manual_sap_hana_scaleout_ha.tf comprend deux instances de l'argument source : l'une active et l'autre incluse en tant que commentaire. L'argument source actif par défaut spécifie latest comme version de module. La deuxième instance de l'argument source, qui est désactivée par défaut par un caractère # de début, spécifie un horodatage qui identifie une version de module. Si vous avez besoin que tous vos déploiements utilisent la même version de module, supprimez le caractère # de début de l'argument source qui spécifie l'horodatage de la version, puis ajoutez-le à l'argument source spécifiant latest.
   project_id	Chaîne	Indiquez l'ID de votre projet Google Cloud dans lequel vous déployez ce système. Par exemple, my-project-x.
   machine_type	Chaîne	Spécifiez le type de machine virtuelle (VM) Compute Engine sur lequel vous devez exécuter votre système SAP. Si vous avez besoin d'un type de VM personnalisé, spécifiez un type de VM prédéfini avec un nombre de processeurs virtuels le plus proche possible de la quantité dont vous avez besoin tout en étant légèrement supérieur. Une fois le déploiement terminé, modifiez le nombre de processeurs virtuels et la quantité de mémoire. Par exemple, n1-highmem-32.
   network	Chaîne	Indiquez le nom du réseau dans lequel vous devez créer l'équilibreur de charge qui gère l'adresse IP virtuelle. Si vous utilisez un réseau VPC partagé, vous devez ajouter l'ID du projet hôte en guise de répertoire parent du nom de réseau. Par exemple : HOST_PROJECT_ID/NETWORK_NAME.
   subnetwork	Chaîne	Spécifiez le nom du sous-réseau que vous avez créé à une étape précédente. Si vous procédez au déploiement sur un VPC partagé, spécifiez cette valeur en tant que SHARED_VPC_PROJECT_ID/SUBNETWORK. Exemple : myproject/network1.
   linux_image	Chaîne	Indiquez le nom de l'image du système d'exploitation Linux sur laquelle vous souhaitez déployer votre système SAP. Par exemple, rhel-9-2-sap-ha ou sles-15-sp5-sap. Pour obtenir la liste des images de système d'exploitation disponibles, consultez la page Images dans la console Google Cloud.
   linux_image_project	Chaîne	Spécifiez le projet Google Cloud qui contient l'image que vous avez spécifiée pour l'argument linux_image. Ce projet peut être votre propre projet ou un projet d'image Google Cloud. Pour une image Compute Engine, spécifiez rhel-sap-cloud ou suse-sap-cloud. Pour trouver le projet d'image correspondant à votre système d'exploitation, consultez la page Détails des systèmes d'exploitation.
   primary_instance_name	Chaîne	Spécifiez le nom de l'instance de VM pour le système SAP HANA principal. Le nom peut contenir des lettres minuscules, des chiffres et des traits d'union.
   primary_zone	Chaîne	Spécifiez la zone dans laquelle le système SAP HANA principal est déployé. Les zones principale et secondaire doivent être dans la même région. Par exemple : us-east1-c
   secondary_instance_name	Chaîne	Spécifiez le nom de l'instance de VM pour le système SAP HANA secondaire. Le nom peut contenir des lettres minuscules, des chiffres et des traits d'union.
   secondary_zone	Chaîne	Spécifiez la zone dans laquelle le système SAP HANA secondaire est déployé. Les zones principale et secondaire doivent être dans la même région. Par exemple : us-east1-b
   sap_hana_deployment_bucket	Chaîne	Pour installer automatiquement SAP HANA sur les VM déployées, spécifiez le chemin du bucket Cloud Storage contenant les fichiers d'installation de SAP HANA. N'incluez pas gs:// dans le chemin. Incluez uniquement le nom du bucket et celui des dossiers. Exemple : my-bucket-name/my-folder. Le bucket Cloud Storage doit exister dans le projet Google Cloud que vous spécifiez pour l'argument project_id.
   sap_hana_scaleout_nodes	Entier	Spécifiez le nombre d'hôtes de calcul dont vous avez besoin dans votre système à évolutivité horizontale. Pour déployer un système à évolutivité horizontale, vous devez disposer d'au moins un hôte de calcul. Terraform crée les hôtes de calcul en plus de l'instance SAP HANA principale. Par exemple, si vous spécifiez 3, quatre instances SAP HANA sont déployées dans votre système à évolutivité horizontale.
   sap_hana_sid	Chaîne	Pour installer automatiquement SAP HANA sur les VM déployées, spécifiez l'ID système SAP HANA. L'ID doit comporter trois caractères alphanumériques et commencer par une lettre. Toutes les lettres doivent être en majuscules. Par exemple, ED1.
   sap_hana_instance_number	Entier	Facultatif. Spécifiez le numéro d'instance (0 à 99) du système SAP HANA. La valeur par défaut est 0.
   sap_hana_sidadm_password	Chaîne	Pour installer automatiquement SAP HANA sur les VM déployées, spécifiez un mot de passe SIDadm temporaire pour les scripts d'installation à utiliser lors du déploiement. Le mot de passe doit contenir au moins huit caractères et inclure au moins une lettre majuscule, une lettre minuscule et un chiffre. Important : Une fois l'installation terminée, veillez à modifier le mot de passe. Au lieu de spécifier le mot de passe en texte brut, nous vous recommandons d'utiliser un secret. Pour en savoir plus, consultez la section Gestion des mots de passe.
   sap_hana_sidadm_password_secret	Chaîne	Facultatif. Si vous utilisez Secret Manager pour stocker le mot de passe SIDadm, spécifiez le nom du secret correspondant à ce mot de passe. Dans Secret Manager, assurez-vous que la valeur du secret, qui correspond au mot de passe, contient au moins huit caractères et au moins une lettre majuscule, une lettre minuscule et un chiffre. Important : Le secret doit se trouver dans le projet Google Cloud que vous spécifiez pour l'argument project_id. Pour en savoir plus, consultez la section Gestion des mots de passe.
   sap_hana_system_password	Chaîne	Pour installer automatiquement SAP HANA sur les VM déployées, spécifiez le mot de passe temporaire d'un super-utilisateur de base de données pour les scripts d'installation à utiliser lors du déploiement. Le mot de passe doit contenir au moins huit caractères et inclure au moins une lettre majuscule, une lettre minuscule et un chiffre. Important : Une fois l'installation terminée, veillez à modifier le mot de passe. Au lieu de spécifier le mot de passe en texte brut, nous vous recommandons d'utiliser un secret. Pour en savoir plus, consultez la section Gestion des mots de passe.
   sap_hana_system_password_secret	Chaîne	Facultatif. Si vous utilisez Secret Manager pour stocker le mot de passe du super-utilisateur de la base de données, spécifiez le nom du secret correspondant à ce mot de passe. Dans Secret Manager, assurez-vous que la valeur du secret, qui correspond au mot de passe, contient au moins huit caractères et au moins une lettre majuscule, une lettre minuscule et un chiffre. Important : Le secret doit se trouver dans le projet Google Cloud que vous spécifiez pour l'argument project_id. Pour en savoir plus, consultez la section Gestion des mots de passe.
   sap_hana_double_volume_size	Booléen	Facultatif. Pour doubler la taille du volume HANA, spécifiez true. Cet argument est utile lorsque vous souhaitez déployer plusieurs instances SAP HANA ou une instance SAP HANA de reprise après sinistre sur la même VM. Par défaut, la taille du volume est calculée automatiquement pour correspondre à la taille minimale requise pour votre VM, tout en respectant les exigences de certification et de compatibilité SAP. La valeur par défaut est false.
   sap_hana_backup_size	Entier	Facultatif. Spécifiez la taille du volume /hanabackup en Go. Si vous ne spécifiez pas cet argument ou si vous le définissez sur 0, le script d'installation provisionne l'instance Compute Engine avec un volume de sauvegarde HANA de deux fois la mémoire totale.
   sap_hana_sidadm_uid	Entier	Facultatif. Spécifiez une valeur pour remplacer la valeur par défaut de l'ID de l'utilisateur administrateur SID_LC. La valeur par défaut est 900. Vous pouvez la remplacer par une autre valeur pour garantir la cohérence dans votre environnement SAP.
   sap_hana_sapsys_gid	Entier	Facultatif. Remplace l'ID de groupe par défaut défini pour sapsys. La valeur par défaut est 79.
   sap_vip	Chaîne	Adresse IP utilisée en guise d'adresse IP virtuelle. L'adresse IP doit être comprise dans la plage d'adresses IP qui sont attribuées à votre sous-réseau. Le fichier de configuration Terraform réserve cette adresse IP pour vous.
   primary_instance_group_name	Chaîne	Facultatif. Spécifiez le nom du groupe d'instances non géré pour le nœud principal. Le nom par défaut est ig-PRIMARY_INSTANCE_NAME.
   secondary_instance_group_name	Chaîne	Facultatif. Spécifiez le nom du groupe d'instances non géré pour le nœud secondaire. Le nom par défaut est ig-SECONDARY_INSTANCE_NAME.
   loadbalancer_name	Chaîne	Facultatif. Spécifiez le nom de l'équilibreur de charge réseau passthrough interne. Le nom par défaut est lb-SAP_HANA_SID-ilb.
   network_tags	Chaîne	Facultatif. Spécifiez un ou plusieurs tags réseau séparés par une virgule que vous souhaitez associer à vos instances de VM à des fins de routage ou de pare-feu. Si vous spécifiez public_ip = false et ne spécifiez pas de tag réseau, veillez à fournir un autre moyen d'accès à Internet.
   nic_type	Chaîne	Facultatif. 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 l'argument linux_image. 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 cet argument, l'interface réseau est automatiquement sélectionnée en fonction du type de machine que vous spécifiez pour l'argument machine_type. Cet argument est disponible dans la version 202302060649, ou ultérieure, du module sap_hana.
   disk_type	Chaîne	Facultatif. Spécifiez le type de volume Persistent Disk ou Hyperdisk par défaut que vous souhaitez déployer pour les volumes de données et de journaux SAP de votre déploiement. Pour en savoir plus sur le déploiement de disque par défaut effectué par les configurations Terraform fournies par Google Cloud, consultez la section Déploiement de disque par Terraform. Voici des valeurs valides pour cet argument : pd-ssd, pd-balanced, hyperdisk-extreme, hyperdisk-balanced et pd-extreme. Dans les déploiements SAP HANA avec scaling à la hausse, un disque persistant avec équilibrage distinct est également déployé pour le répertoire /hana/shared. Vous pouvez remplacer ce type de disque par défaut, ainsi que la taille de disque par défaut et les IOPS par défaut à l'aide de certains arguments avancés. Pour en savoir plus, accédez à votre répertoire de travail, exécutez la commande terraform init, puis consultez le fichier /.terraform/modules/manual_sap_hana_scaleout_ha/variables.tf. Avant d'utiliser ces arguments en production, veillez à les tester dans un environnement hors production.
   use_single_shared_data_log_disk	Booléen	Facultatif. La valeur par défaut est false, qui indique à Terraform de déployer un disque persistant ou un hyperdisque distinct pour chacun des volumes SAP suivants : /hana/data ,/hana/log ,/hana/shared et/usr/sap. Pour installer ces volumes SAP sur le même disque persistant ou hyperdisque, spécifiez true.
   include_backup_disk	Booléen	Facultatif. Cet argument s'applique aux déploiements SAP HANA à scaling à la hausse. La valeur par défaut est true, ce qui indique à Terraform de déployer un disque distinct pour héberger le répertoire /hanabackup. Le type de disque est déterminé par l'argument backup_disk_type. La taille de ce disque est déterminée par l'argument sap_hana_backup_size. Si vous définissez la valeur de include_backup_disk sur false, aucun disque n'est déployé pour le répertoire /hanabackup.
   public_ip	Booléen	Facultatif. Détermine si une adresse IP publique est ajoutée ou non à votre instance de VM. La valeur par défaut est true. Attention : Ne spécifiez false que si vous avez configuré une passerelle NAT avec un tag réseau défini pour la VM ou si vous avez fourni à la VM une autre route d'accès à Internet. Si aucun moyen d'accès à Internet n'est disponible, l'installation échoue.
   service_account	Chaîne	Facultatif. Spécifiez l'adresse e-mail d'un compte de service géré par l'utilisateur qui sera utilisée par les VM hôtes et par les programmes qui s'exécutent sur celles-ci. Par exemple, [e-mail]. Si vous spécifiez cet argument sans valeur ou si vous l'omettez, le script d'installation utilise le compte de service Compute Engine par défaut. Pour en savoir plus, consultez la page Gestion de l'authentification et des accès pour les programmes SAP sur Google Cloud.
   sap_deployment_debug	Booléen	Facultatif. Lorsque Cloud Customer Care vous demande d'activer le débogage pour votre déploiement, spécifiez true, qui permet au déploiement de générer des journaux de déploiement détaillés. La valeur par défaut est false.
   primary_reservation_name	Chaîne	Facultatif. Si vous souhaitez utiliser une réservation de VM Compute Engine spécifique pour le provisionnement de l'instance de VM qui héberge l'instance SAP HANA principale de votre cluster à haute disponibilité, spécifiez le nom de la réservation. Par défaut, le script d'installation sélectionne toute réservation Compute Engine disponible en fonction des conditions suivantes. Que vous définissiez son nom ou que le script d'installation le sélectionne automatiquement, la réservation doit être définie comme suit pour être utilisable : L'option specificReservationRequired est définie sur true ou, dans la console Google Cloud, l'option Sélectionner une réservation spécifique est sélectionnée. Certains types de machines Compute Engine sont compatibles avec les plates-formes de processeur qui ne sont pas couvertes par la certification SAP de ce type de machine. Si la réservation cible concerne l'un des types de machines suivants, la réservation doit spécifier les plates-formes de processeur minimales, comme indiqué : n1-highmem-32 : Intel Broadwell n1-highmem-64 : Intel Broadwell n1-highmem-96 : Intel Skylake m1-megamem-96 : Intel Skylake Les plates-formes de processeur minimales pour tous les autres types de machines certifiés par SAP pour une utilisation sur Google Cloud sont conformes à la configuration minimale requise de processeur SAP.
   secondary_reservation_name	Chaîne	Facultatif. Si vous souhaitez utiliser une réservation de VM Compute Engine spécifique pour le provisionnement de l'instance de VM qui héberge l'instance SAP HANA secondaire de votre cluster à haute disponibilité, spécifiez le nom de la réservation. Par défaut, le script d'installation sélectionne toute réservation Compute Engine disponible en fonction des conditions suivantes. Que vous définissiez son nom ou que le script d'installation le sélectionne automatiquement, la réservation doit être définie comme suit pour être utilisable : L'option specificReservationRequired est définie sur true ou, dans la console Google Cloud, l'option Sélectionner une réservation spécifique est sélectionnée. Certains types de machines Compute Engine sont compatibles avec les plates-formes de processeur qui ne sont pas couvertes par la certification SAP de ce type de machine. Si la réservation cible concerne l'un des types de machines suivants, la réservation doit spécifier les plates-formes de processeur minimales, comme indiqué : n1-highmem-32 : Intel Broadwell n1-highmem-64 : Intel Broadwell n1-highmem-96 : Intel Skylake m1-megamem-96 : Intel Skylake Les plates-formes de processeur minimales pour tous les autres types de machines certifiés par SAP pour une utilisation sur Google Cloud sont conformes à la configuration minimale requise de processeur SAP.
   primary_static_ip	Chaîne	Facultatif. Spécifiez une adresse IP statique valide pour l'instance de VM principale dans votre cluster à haute disponibilité. Si vous n'en spécifiez pas, une adresse IP est automatiquement générée pour votre instance de VM. Par exemple, 128.10.10.10. Cet argument est disponible dans la version 202306120959, ou ultérieure, du module sap_hana_ha.
   secondary_static_ip	Chaîne	Facultatif. Spécifiez une adresse IP statique valide pour l'instance de VM secondaire dans votre cluster à haute disponibilité. Si vous n'en spécifiez pas, une adresse IP est automatiquement générée pour votre instance de VM. Par exemple, 128.11.11.11. Cet argument est disponible dans la version 202306120959, ou ultérieure, du module sap_hana_ha.
   primary_worker_static_ips	List(String)	Facultatif. Spécifiez un tableau d'adresses IP statiques valides pour les instances de nœuds de calcul dans l'instance principale de votre système SAP HANA à haute disponibilité à scaling horizontal. Si vous ne spécifiez pas de valeur pour cet argument, une adresse IP est automatiquement générée pour chaque instance de VM de nœud de calcul. Par exemple, [ "1.0.0.1", "2.3.3.4" ]. Les adresses IP statiques sont attribuées dans l'ordre de création des instances. Par exemple, si vous choisissez de déployer trois instances de nœud de calcul, mais ne spécifiez que deux adresses IP pour l'argument primary_worker_static_ips, ces adresses IP sont attribuées aux deux premières instances de VM que la configuration Terraform déploie. Pour la troisième instance de VM de nœud de calcul, l'adresse IP est générée automatiquement. Cet argument est disponible dans la version 202307270727, ou ultérieure, du module sap_hana_ha.
   secondary_worker_static_ips	List(String)	Facultatif. Spécifiez un tableau d'adresses IP statiques valides pour les instances de nœuds de calcul dans l'instance secondaire de votre système SAP HANA à haute disponibilité à scaling horizontal. Si vous ne spécifiez pas de valeur pour cet argument, une adresse IP est automatiquement générée pour chaque instance de VM de nœud de calcul. Par exemple, [ "1.0.0.2", "2.3.3.5" ]. Les adresses IP statiques sont attribuées dans l'ordre de création des instances. Par exemple, si vous choisissez de déployer trois instances de nœud de calcul, mais ne spécifiez que deux adresses IP pour l'argument secondary_worker_static_ips, ces adresses IP sont attribuées aux deux premières instances de VM que la configuration Terraform déploie. Pour la troisième instance de VM de nœud de calcul, l'adresse IP est générée automatiquement. Cet argument est disponible dans la version 202307270727, ou ultérieure, du module sap_hana_ha.

   Les exemples suivants montrent des fichiers de configuration terminés qui définissent un cluster à haute disponibilité pour un système SAP HANA à scaling horizontal. Le cluster gère l'adresse IP virtuelle à l'aide d'un équilibreur de charge réseau passthrough interne.

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

   Remarque:Les scripts de déploiement n'installent SAP HANA que si les arguments appropriés sont spécifiés dans le fichier de configuration Terraform. Pour installer automatiquement SAP HANA sur les VM déployées, vous devez spécifier les arguments suivants :

   • sap_hana_deployment_bucket
   • sap_hana_sid
   • sap_hana_sidadm_password ou sap_hana_sidadm_password_secret
   • sap_hana_system_password ou sap_hana_system_password_secret

6. Dans le même fichier manual_sap_hana_scaleout_ha.tf, mettez à jour les valeurs d'argument pour majority_maker. Les arguments sont décrits dans le tableau suivant.

   Argument	Type de données	Description
   project	Chaîne	Indiquez l'ID de votre projet Google Cloud dans lequel vous déployez ce système.
   majority_maker_instance_name	Chaîne	Indiquez un nom pour l'instance de VM Compute Engine qui sert de créateur majoritaire. Cet argument est disponible dans la version 202307270727, ou ultérieure, du module sap_hana_ha.
   majority_maker_instance_type	Chaîne	Spécifiez le type de machine virtuelle (VM) Compute Engine que vous souhaitez utiliser pour l'instance du créateur de majorité. Exemple : n1-highmem-32. Si vous souhaitez utiliser 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. Cet argument est disponible dans la version 202307270727, ou ultérieure, du module sap_hana_ha.
   majority_maker_zone	Chaîne	Spécifiez la zone dans laquelle l'instance de VM du créateur de majorité est déployée. Cette zone doit se trouver dans la même région que les zones principale et secondaire. Par exemple, us-east1-d. Google Cloud recommande de déployer l'instance de VM de créateur de majorité dans une zone différente de celle des systèmes SAP HANA principal et secondaire. Cet argument est disponible dans la version 202307270727, ou ultérieure, du module sap_hana_ha.
   majority_maker_linux_image	Chaîne	En utilisant les mêmes valeurs qu'à l'étape précédente, spécifiez le chemin d'accès complet à l'image comme suit : "linux_image_project/linux_image". Par exemple, "rhel-sap-cloud/rhel-9-0-sap-v20230708".
   subnetwork	Chaîne	Spécifiez le nom du sous-réseau que vous avez créé à une étape précédente. Si vous procédez au déploiement sur un VPC partagé, spécifiez cette valeur en tant que SHARED_VPC_PROJECT_ID/SUBNETWORK. Exemple : myproject/network1.
   service_account	Chaîne	Facultatif. Spécifiez l'adresse e-mail d'un compte de service géré par l'utilisateur qui sera utilisée par les VM hôtes et par les programmes qui s'exécutent sur celles-ci. Par exemple, [e-mail]. Si vous spécifiez cet argument sans valeur ou si vous l'omettez, le script d'installation utilise le compte de service Compute Engine par défaut. Pour en savoir plus, consultez la page Gestion de l'authentification et des accès pour les programmes SAP sur Google Cloud.
   metadata_startup_script	Chaîne	Ne modifiez pas cet argument. Par défaut, le créateur de majorité va télécharger le dernier script de démarrage pour préparer l'instance au clustering Pacemaker.

   Pour plus de clarté, les commentaires de l'exemple de configuration suivant sont omis.

  module "sap_hana_primary" {
    source = "https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_hana/sap_hana_module.zip"

    project_id                     = "example-project-123456"
    zone                           = "us-west1-a"
    machine_type                   = "n1-highmem-32"
    subnetwork                     = "default"
    linux_image                    = "rhel-9-0-sap-v20230711"
    linux_image_project            = "rhel-sap-cloud"
    instance_name                  = "hana-ha-1"
    sap_hana_sid                   = "HA1"

    sap_hana_deployment_bucket      = "my-hana-bucket"
    sap_hana_sidadm_password_secret = "hana_sid_adm_pwd"
    sap_hana_system_password_secret = "hana_sys_pwd"
    sap_hana_scaleout_nodes         = 1
    sap_hana_shared_nfs             = "10.10.10.1:/hana_scaleout/hana_a/shared"
    sap_hana_backup_nfs             = "10.10.10.1:/hana_scaleout/hana_a/backup"

  }
  module "sap_hana_secondary" {
    source = "https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_hana/sap_hana_module.zip"

    project_id                     = "example-project-123456"
    zone                           = "us-west1-b"
    machine_type                   = "n1-highmem-32"
    subnetwork                     = "default"
    linux_image                    = "rhel-9-0-sap-v20230711"
    linux_image_project            = "rhel-sap-cloud"
    instance_name                  = "hana-ha-2"
    sap_hana_sid                   = "HA1"

    sap_hana_deployment_bucket      = "my-hana-bucket"
    sap_hana_sidadm_password_secret = "hana_sid_adm_pwd"
    sap_hana_system_password_secret = "hana_sys_pwd"
    sap_hana_scaleout_nodes         = 1
    sap_hana_shared_nfs             = "10.10.10.2:/hana_scaleout/hana_b/shared"
    sap_hana_backup_nfs             = "10.10.10.2:/hana_scaleout/hana_b/backup"
  }

  resource "google_compute_instance" "majority_maker" {

    project =  "example-project-123456"

    # majority_maker_instance_name
    name         = "majority-maker"

    # majority_maker_instance_type
    machine_type = "n1-standard-8"

    # majority_maker_zone
    zone         = "us-west1-c"

    boot_disk {
      initialize_params {
        # majority_maker_linux_image
        image = "rhel-sap-cloud/rhel-9-0-sap-v20230711"
      }
    }

    network_interface {
      # network or subnetwork
      network = "default"
    }

      service_account {
      # service_account (Optional)
      # email  = [e-mail].
      scopes = ["cloud-platform"]
    }

    # Do not edit
    metadata_startup_script = "curl -s https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_majoritymaker/startup.sh | bash -s https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_majoritymaker/startup.sh"

  }

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

   terraform init

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

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

   terraform init --upgrade 

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

   terraform plan

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

3. Appliquez le plan d'exécution :

   terraform apply

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

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

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

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

Vérifier les journaux

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

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

   Accéder à CloudLogging

2. Filtrez les journaux :

   Explorateur de journaux

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

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

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

      resource.type="global"
      "Deployment"
      

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

   Ancienne visionneuse de journaux

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

3. Analysez les journaux filtrés :

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

   • Si vous rencontrez une erreur de quota :

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

     2. Ouvrez Cloud Shell.

        Accéder à Cloud Shell

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

        terraform destroy

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

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

Vérifier la configuration de la VM et l'installation de SAP HANA

Remarque : Les scripts de déploiement n'installent SAP HANA que si les arguments appropriés ont été spécifiés dans le fichier de configuration Terraform. Dans le cas contraire, vous pouvez ignorer cette étape.

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.

   

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

   sudo su -

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

   [root@example-ha-vm1 ~]# df -h
     Filesystem                        Size  Used Avail Use% Mounted on
     devtmpfs                          126G     0  126G   0% /dev
     tmpfs                             126G   54M  126G   1% /dev/shm
     tmpfs                             126G   25M  126G   1% /run
     tmpfs                             126G     0  126G   0% /sys/fs/cgroup
     /dev/sda2                          30G  5.4G   25G  18% /
     /dev/sda1                         200M  6.9M  193M   4% /boot/efi
     /dev/mapper/vg_hana-shared        251G   52G  200G  21% /hana/shared
     /dev/mapper/vg_hana-sap            32G  477M   32G   2% /usr/sap
     /dev/mapper/vg_hana-data          426G  9.8G  417G   3% /hana/data
     /dev/mapper/vg_hana-log           125G  7.0G  118G   6% /hana/log
     /dev/mapper/vg_hanabackup-backup  512G  9.3G  503G   2% /hanabackup
     tmpfs                              26G     0   26G   0% /run/user/900
     tmpfs                              26G     0   26G   0% /run/user/899
     tmpfs                              26G     0   26G   0% /run/user/1003

Nettoyer et réessayer le déploiement

Si l'une des étapes de vérification du déploiement des sections précédentes indique que l'installation a échoué, vous devez annuler votre déploiement et réessayer en procédant comme suit :

1. Corrigez les erreurs pour vous assurer que votre déploiement n'échouera pas à nouveau pour la même raison. Pour en savoir plus sur la vérification des journaux ou la résolution des erreurs liées aux quotas, consultez la section Vérifier les journaux.

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

   Ouvrir Cloud Shell

3. Accédez au répertoire contenant le fichier de configuration Terraform que vous avez utilisé pour ce déploiement.

4. Supprimez toutes les ressources faisant partie de votre déploiement en exécutant la commande suivante :

   terraform destroy

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

5. Relancez le déploiement comme indiqué précédemment dans ce guide.

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

Après avoir déployé toutes les instances et installé votre 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.

(Facultatif) Créer une liste d'instances pour l'automatisation du script

Pour automatiser partiellement certaines des tâches répétitives lors de la configuration du système SAP HANA et du cluster Pacemaker, vous pouvez utiliser des scripts bash. De tels scripts bash sont utilisés tout au long de ce guide pour accélérer la configuration de votre système SAP HANA et du cluster Pacemaker. Ces scripts nécessitent comme entrée une liste de toutes les instances de VM déployées et des zones correspondantes.

Pour activer cette automatisation, créez un fichier nommé nodes.txt et incluez les détails de toutes les instances de VM déployées au format suivant : nom de zone, espace blanc, puis nom d'instance de VM. L'exemple de fichier suivant est utilisé tout au long de ce guide :

# cat nodes.txt
  us-west1-a hana-ha-vm-1
  us-west1-a hana-ha-vm-1w1
  us-west1-a hana-ha-vm-1w2
  us-west1-b hana-majoritymaker
  us-west1-c hana-ha-vm-2
  us-west1-c hana-ha-vm-2w1
  us-west1-c hana-ha-vm-2w2
 

Configurer un accès SSH sans mot de passe

Pour configurer le cluster Pacemaker et synchroniser les clés du magasin sécurisé SAP HANA (SSFS), un accès SSH sans mot de passe est requis entre tous les nœuds, y compris l'instance créatrice de majorité. Pour un accès SSH sans mot de passe, vous devez ajouter les clés publiques SSH aux métadonnées de toutes les instances déployées.

Les métadonnées respectent le format suivant : USERNAME: PUBLIC-KEY-VALUE.

Pour en savoir plus sur l'ajout de clés SSH aux VM, consultez la section Ajouter des clés SSH aux VM qui utilisent des clés SSH basées sur des métadonnées.

Étapes manuelles

1. Pour chaque instance des systèmes principaux et secondaires, y compris pour l'instance créatrice de majorité, collectez la clé publique pour l'utilisateur root.

   gcloud compute ssh --quiet --zone ZONE_ID INSTANCE_NAME -- sudo cat /root/.ssh/id_rsa.pub

2. Ajoutez la chaîne root: en tant que préfixe à la clé et écrivez la clé dans une nouvelle ligne dans le fichier nommé public-ssh-keys.txt, par exemple :

   root:ssh-rsa AAAAB3NzaC1JfuYnOI1vutCs= root@INSTANCE_NAME

3. Après avoir collecté toutes les clés publiques SSH, importez les clés en tant que métadonnées dans toutes les instances :

   gcloud compute instances add-metadata --metadata-from-file ssh-keys=public-ssh-keys.txt --zone ZONE_ID INSTANCE_NAME

Étapes automatisées

Pour automatiser le processus de configuration de l'accès SSH sans mot de passe pour toutes les instances regroupées dans nodes.txt, vous pouvez également effectuer les étapes suivantes à partir de la console Google Cloud :

1. Créez une liste de clés publiques à partir de toutes les instances déployées :

   while read -u10 ZONE HOST ;  do echo "Collecting public-key from $HOST"; { echo 'root:'; gcloud compute ssh --quiet --zone $ZONE $HOST --tunnel-through-iap -- sudo cat /root/.ssh/id_rsa.pub; } | tr -ds '\n' " " >> public-ssh-keys.txt; done 10< nodes.txt

2. Attribuez les clés publiques SSH en tant qu'entrées de métadonnées à toutes les instances :

   while read -u10 ZONE HOST ;  do echo "Adding public keys to $HOST"; gcloud compute instances add-metadata --metadata-from-file ssh-keys=public-ssh-keys.txt --zone $ZONE $HOST; done 10< nodes.txt 

Désactiver le démarrage automatique de SAP HANA

Étapes manuelles

Pour chaque instance SAP HANA du cluster, assurez-vous que le démarrage automatique de SAP HANA est désactivé. Pour les basculements, Pacemaker gère le démarrage et l'arrêt des instances SAP HANA dans un cluster.

1. Sur chaque hôte, en tant que SID_LCadm, arrêtez SAP HANA :

   > HDB stop

2. Sur chaque hôte, ouvrez le profil SAP HANA à l'aide d'un éditeur, tel que vi :

   vi /usr/sap/SID/SYS/profile/SID_HDBINST_NUM_HOST_NAME

3. Définissez la propriété Autostart sur 0 :

   Autostart=0

4. Enregistrez le profil.

5. Sur chaque hôte, en tant que SID_LCadm, démarrez SAP HANA :

   > HDB start

Étapes automatisées

Sinon, pour désactiver le démarrage automatique de SAP HANA pour toutes les instances regroupées dans nodes.txt, exécutez le script suivant à partir de la console Google Cloud :

while read -u10 ZONE HOST ;
 do gcloud compute ssh --verbosity=none --zone $ZONE $HOST -- "echo Setting Autostart=0 on \$HOSTNAME;
 sudo sed -i 's/Autostart=1/Autostart=0/g' /usr/sap/SID/SYS/profile/SID_HDBINST_NUM_\$HOSTNAME";
 done 10< nodes.txt
 

Remarque : Ignorez l'erreur "No such file or directory" (Fichier ou répertoire inexistant) qui s'affiche lorsque le script d'automatisation accède à l'instance créatrice de majorité. Cette erreur s'affiche, car SAP HANA n'est pas installé sur l'instance créatrice de majorité.

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.

Remarque : Si vous déployez SAP HANA à l'aide du module Terraform de Google Cloud sap_hana ou sap_hana_ha, version 202309280828 ou ultérieure, alors le redémarrage rapide est automatiquement activé.

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 :

• Étapes manuelles : Activer le redémarrage rapide de SAP HANA
• Étapes automatisées : Activer le redémarrage rapide de SAP HANA

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

Remarque : Si vous modifiez les types de machines et que les NUMA nœuds augmentent ou diminuent, vous devez modifier le système de fichiers tmpfs et la section [persistence] du fichier INI SAP HANA, présentés dans la section suivante, en fonction du nouveau nombre de nœuds NUMA

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.

Remarque : Nous vous recommandons vivement d'exécuter le script fourni par Google Cloud pour activer le redémarrage rapide de SAP HANA dans un environnement hors production et de vérifier minutieusement les résultats avant d'exécuter le script dans les environnements de production. Vous êtes responsable de l'activation correcte du redémarrage rapide de SAP HANA.

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)

Étapes automatisées

Pour automatiser ce processus, utilisez le fichier nodes.txt et les scripts suivants dans la console Google Cloud :

1. Générez un fichier hosts.txt contenant une liste d'adresses IP et de noms d'hôte :

   while read -u10 ZONE HOST ; do gcloud compute instances list --filter="name=( 'NAME' $HOST )" --format="csv[separator=' ',no-heading](networkInterfaces[0].networkIP,name)" >> hosts.txt; done 10< nodes.txt

2. Vérifiez que votre fichier hosts.txt ressemble à l'exemple suivant :

   10.138.0.1 rhel-hana-primary
   10.138.0.2 rhel-hana-primaryw1
   10.138.0.3 rhel-hana-secondary
   10.138.0.4 rhel-hana-secondaryw1
   10.138.0.5 rhel-sap-mm
   

3. Sur tous les hôtes du cluster, y compris le créateur de majorité, mettez à jour le fichier /etc/hosts pour inclure les noms d'hôte et les adresses IP internes de toutes les instances du cluster Pacemaker.

   while read -u10 ZONE HOST ;  do gcloud compute ssh --tunnel-through-iap --quiet $HOST --zone $ZONE -- "sudo tee -a /etc/hosts" < hosts.txt; done 10< nodes.txt

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 :

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

      > sapcontrol -nr INST_NUM -function StopSystem

   2. En mode root, archivez les données SSFS et les fichiers de clés existants :

      # cd /usr/sap/SID/SYS/global/security/rsecssfs/
      # mv data/SSFS_SID.DAT data/SSFS_SID.DAT-ARC
      # mv key/SSFS_SID.KEY key/SSFS_SID.KEY-ARC

   3. Copiez le fichier de données de l'hôte principal :

      # scp -o StrictHostKeyChecking=no \
      PRIMARY_HOST_NAME:/usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT \
      /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT

   4. Copiez le fichier de clé de l'hôte principal :

      # scp -o StrictHostKeyChecking=no \
      PRIMARY_HOST_NAME:/usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY \
      /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

   5. Mettez à jour la propriété des fichiers :

      # chown SID_LCadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT
      # chown SID_LCadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

   6. Mettez à jour les autorisations pour les fichiers :

      # chmod 644 /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT
      # chmod 640 /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

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

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

      > sapcontrol -nr INST_NUM -function StartSystem

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, overall system replication status affiche ACTIVE.

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.

Remarque : Si vous souhaitez mettre en œuvre les hooks de fournisseur HA/DR sur un système SAP HANA préexistant avec un temps d'arrêt quasiment nul, reportez-vous plutôt à la section Guide d'utilisation de SAP HANA

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

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

   > sapcontrol -nr 00 -function StopSystem

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-ScaleOut/
   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 SID_LC par le SID, en lettres minuscules.

   Cmnd_Alias SOK = /usr/sbin/crm_attribute -n hana_SID_LC_glob_srHook -v SOK -t crm_config -s SAPHanaSR
   Cmnd_Alias SFAIL = /usr/sbin/crm_attribute -n hana_SID_LC_glob_srHook -v SFAIL -t crm_config -s SAPHanaSR
   SID_LCadm ALL=(ALL) NOPASSWD: SOK, SFAIL
   Defaults!SOK, 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.

Remarque : Bien que la procédure décrite dans cette section soit recommandée par Red Hat, vous pouvez utiliser une autre approche. Au lieu de créer un fichier de configuration prêt à l'emploi, vous pouvez ajouter l'accès requis directement à votre fichier /etc/sudoers.

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

   > sapcontrol -nr 00 -function StartSystem

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_*

Configurer la prise en charge du basculement Cloud Load Balancing

Le service d'équilibrage de charge réseau passthrough interne 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.

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

Tester la configuration de l'équilibreur de charge

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

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

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

Vous pouvez vous servir de l'utilitaire socat pour écouter temporairement le port de vérification de l'état.

1. Sur les deux VM hôtes maîtres, la principale et la secondaire, 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 et configurer un cluster à haute disponibilité Red Hat Enterprise Linux 7.6 (et versions ultérieures) sur Google Cloud
• Réplication automatique du système SAP HANA avec scaling horizontal dans un cluster Pacemaker

Étapes manuelles

Effectuez les étapes suivantes sur tous les hôtes. Sur l'image RHEL pour SAP fournie par Google, certains packages sont déjà installés, mais des modifications supplémentaires sont nécessaires.

1. En tant qu'utilisateur root, supprimez l'agent de ressources avec scaling à la hausse SAP HANA, qui est préinstallé sur l'image :

   # yum -y remove resource-agents-sap-hana

2. Installez Pacemaker et les agents de ressources manquants :

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

3. Update packages to latest version:

   # yum update -y

4. Définissez le mot de passe de l'utilisateur hacluster, qui a été créé pour les packages :

   # passwd hacluster

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

6. Dans les images RHEL pour SAP 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

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

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

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

   # systemctl status pcsd.service

   La sortie obtenue doit ressembler à ceci :

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

Étapes automatisées

Pour automatiser ce processus, vous pouvez utiliser le fichier nodes.txt et le script suivant dans la console Google Cloud.

Lorsque vous y êtes invité, saisissez le mot de passe de l'utilisateur hacluster, qui a été défini lors de l'installation des agents de ressources Pacemaker.

echo "Set password for hacluster user:"; read -r HA_PASSWD; while read -u10 HOST ;  do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST -- "sudo yum -y remove resource-agents-sap-hana; sudo yum -y install pcs pacemaker fence-agents-gce resource-agents-sap-hana-scaleout resource-agents-gcp; sudo yum update -y; sudo firewall-cmd --permanent --add-service=high-availability; sudo firewall-cmd --reload; sudo systemctl start pcsd.service; sudo systemctl enable pcsd.service; yes $HA_PASSWD | sudo passwd hacluster"; done 10< nodes.txt

Mettre à jour le fichier /etc/hosts

Sur tous les hôtes du cluster, y compris le créateur de majorité, mettez à jour le fichier /etc/hosts pour inclure les noms d'hôte et les adresses IP internes de toutes les instances du cluster Pacemaker.

La sortie du fichier /etc/hosts doit ressembler à l'exemple ci-dessous :

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1                localhost localhost.localdomain localhost6 localhost6.localdomain6
10.138.0.1 rhel-hana-primary.us-west1-a.c.project-name.internal rhel-hana-primary # Added by Google
169.254.169.254 metadata.google.internal # Added by Google
10.138.0.1 rhel-hana-primary
10.138.0.2 rhel-hana-primaryw1
10.138.0.3 rhel-hana-secondary
10.138.0.4 rhel-hana-secondaryw1
10.138.0.5 rhel-sap-mm

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'hôte principal, autorisez l'utilisateur hacluster. Il est important d'inclure tous les hôtes du cluster dans cette commande, qui doit faire partie du cluster.

   RHEL 8.0 et versions ultérieures

   pcs host auth primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-name
   

   RHEL 7.6 et versions ultérieures

   pcs cluster auth primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-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 dans la section précédente.

3. Placez le cluster en mode maintenance.

   pcs property set maintenance-mode=true

4. Générez et synchronisez la configuration Corosync

   RHEL 8 et versions ultérieures

   pcs cluster setup scale_out_hsr primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-name

   RHEL 7.6 et versions ultérieures

   pcs cluster setup --start --name hanascaleoutsr primary-master-name primary-worker-name(s) secondary-master-name secondary-worker-name(s) majority-maker-name

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

1. Ouvrez le fichier /etc/corosync/corosync.conf à l'aide de l'éditeur de votre choix.

2. Supprimez le paramètre consensus.

3. Modifiez les paramètres restants en suivant les recommandations de Google Cloud.

   Le tableau suivant présente les paramètres totem pour lesquels Google Cloud recommande des valeurs, ainsi que l'impact de la modification de ces valeurs. Pour connaître les valeurs par défaut de ces paramètres, qui peuvent différer entre les distributions Linux, consultez la documentation de votre distribution Linux.

   Paramètre	Valeur recommandée	Impact de la modification de la valeur
   secauth	off	Désactive l'authentification et le chiffrement de tous les messages totem.
   join	60 (ms)	Augmente la durée pendant laquelle le nœud attend des messages join dans le protocole de souscription.
   max_messages	20	Augmente le nombre maximal de messages pouvant être envoyés par le nœud après réception du jeton.
   token	20 000 (ms)	Augmente la durée pendant laquelle le nœud attend un jeton de protocole totem avant de déclarer sa perte, suppose une défaillance de nœud et commence à prendre des mesures. L'augmentation de la valeur du paramètre token rend le cluster plus tolérant aux événements d'infrastructure momentanés, tels qu'une migration à chaud. Toutefois, le cluster peut mettre plus de temps à détecter et à corriger une défaillance de nœud. La valeur du paramètre token détermine également la valeur par défaut du paramètre consensus, qui contrôle la durée pendant laquelle un nœud attend que le consensus soit atteint avant de tenter de rétablir l'abonnement à la configuration.
   consensus	N/A	Indique en millisecondes le délai d'attente avant d'obtenir un consensus avant de lancer une nouvelle série de configurations d'abonnements. Nous vous recommandons d'omettre ce paramètre. Lorsque le paramètre consensus n'est pas spécifié, Corosync définit sa valeur sur 1,2 fois la valeur du paramètre token. Si vous appliquez la valeur recommandée du paramètre token de 20000, le paramètre consesus est défini avec la valeur 24000. Si vous spécifiez explicitement une valeur pour le paramètre consensus, assurez-vous que cette valeur est 24000 ou 1.2*token, selon la valeur la plus élevée.
   token_retransmits_before_loss_const	10	Augmente le nombre de retransmissions de jetons effectuées par le nœud avant de conclure que le nœud destinataire a échoué et prend les mesures nécessaires.
   transport	Pour SLES : udpu Pour RHEL 8 ou version ultérieure : knet Pour RHEL 7 : udpu	Spécifie le mécanisme de transport utilisé par Corosync.

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 :

   # pcs cluster enable --all
   # 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

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

Étapes manuelles

1. Sur tous les 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

Étapes automatisées

Pour automatiser ce processus pour toutes les instances regroupées dans nodes.txt, vous pouvez également exécuter le script suivant depuis la console Google Cloud.

while read -u10 HOST;  do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST   --  "sudo mkdir -p /etc/systemd/system/corosync.service.d/; sudo echo -e '[Service]\nExecStartPre=/bin/sleep 60' | sudo tee -a /etc/systemd/system/corosync.service.d/override.conf; sudo systemctl daemon-reload"; done 10< nodes.txt

Configurer le cloisonnement

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

Pour vous assurer que la séquence correcte d'événements se produit après une action de cloisonnement, vous devez configurer le système d'exploitation pour retarder le redémarrage de Corosync après la fermeture d'une VM. Vous devez é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.

Remarque : Si vous avez modifié les noms d'hôte de sorte qu'ils ne soient plus identiques aux noms des instances de VM, consultez la page Installer et configurer un cluster à haute disponibilité Red Hat Enterprise Linux 7.6 (et versions ultérieures) sur Google Compute Cloud. Les étapes suivantes nécessitent que les noms d'hôte soient identiques aux noms d'instance de VM.

Étapes manuelles

1. Sur l'hôte principal, en tant qu'utilisateur racine, créez les appareils de cloisonnement pour tous les hôtes, y compris le créateur de majorité :

   pcs stonith create STONITH-host-name fence_gce \
   port=host-name \
   zone=host-zone \
   project=project-id \
   pcmk_host_list=host-name pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \
   op monitor interval="300s" timeout="120s" \
   op start interval="0" timeout="60s"

2. Définissez la contrainte d'emplacement pour les appareils de cloisonnement :

   pcs constraint location STONITH-host-name avoids host-name

3. Répétez les deux étapes précédentes pour tous les autres hôtes des clusters principal et secondaire, et de l'hôte du créateur de majorité, en saisissant les valeurs appropriées pour les variables host-name et host-zone.

Étapes automatisées

Pour automatiser ce processus, vous devez utiliser le fichier nodes.txt et le script suivant dans la console Google Cloud :

while read -u10 ZONE HOST; do gcloud compute ssh $HOST --tunnel-through-iap --quiet --zone $ZONE -- "sudo pcs stonith create STONITH-$HOST fence_gce project=project-id port=$HOST zone=$ZONE pcmk_host_list=$HOST pcmk_reboot_timeout=300 pcmk_monitor_retries=4 op monitor interval=300s timeout=120s op start interval=0 timeout=60s && sudo pcs constraint location STONITH-$HOST avoids $HOST"; done 10< nodes.txt

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, à partir de n'importe quel hôte, définissez les valeurs par défaut de la ressource :

   RHEL 8 et versions ultérieures

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

   RHEL 7.6 et versions ultérieures

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

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

   RHEL 8 et versions ultérieures

   # pcs resource op defaults update timeout=600s

   RHEL 7.6 et versions ultérieures

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

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

   RHEL 8 et versions ultérieures

   # pcs resource create rsc_SAPHanaTopology_SID_HDBinstNr SAPHanaTopology SID=SID \
   InstanceNumber=inst_num \
   op methods interval=0s timeout=5 \
   op monitor interval=10 timeout=600 \
   clone meta clone-node-max=1 interleave=true

   RHEL 7.6 et versions ultérieures

   # pcs resource create rsc_SAPHanaTopology_SID_HDBinstNr SAPHanaTopologyScaleOut SID=SID \
   InstanceNumber=inst_num \
   op start timeout=600 \
   op stop timeout=300 \
   op monitor interval=10 timeout=600

   # pcs resource clone  rsc_SAPHanaTopology_SID_HDBinstNr meta 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 rsc_SAPHanaTopology_SID_HDBinstNr-clone

   La sortie obtenue doit ressembler à ceci :

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

   RHEL 7.6 et versions ultérieures

   # pcs resource show rsc_SAPHanaTopology_SID_HDBinstNr-clone

   La sortie obtenue doit ressembler à ceci :

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

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

Créer la ressource SAPHanaController

L'agent de ressources SAPHanaController 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 SAPHanaController :

   RHEL 8 et versions ultérieures

   # pcs resource create rsc_SAPHana_SID_HDBinstNr SAPHanaController SID=SID \
   InstanceNumber=inst_num \
   PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
   op demote interval=0s timeout=320 \
   op methods interval=0s timeout=5 \
   op monitor interval=59 \
   role="Master" timeout=700 \
   op monitor interval=61 \
   role="Slave" timeout=700 \
   op promote interval=0 timeout=3600 \
   op start interval=0 timeout=3600 \
   op stop interval=0 timeout=3600e

   # pcs resource promotable rsc_SAPHana_SID_HDBinstNr meta master-max="1" clone-node-max=1 interleave=true

   RHEL 7.6 et versions ultérieures

   # pcs resource create rsc_SAPHana_SID_HDBinstNr SAPHanaController SID=SID \
   InstanceNumber=inst_num \
   PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true \
   op start interval=0 timeout=3600 \
   op stop interval=0 timeout=3600 \
   op promote interval=0 timeout=3600 \
   op monitor interval=60 \
   role="Master" timeout=700 \
   op monitor interval=61 \
   role="Slave" timeout=700

   # pcs resource master msl_rsc_SAPHana_SID_HDBinstNr rsc_SAPHana_SID_HDBinstNr master-max="1" 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 rsc_SAPHana_SID_HDBinstNr-clone

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

   Resource: SAPHana_HA1_00 (class=ocf provider=heartbeat type=SAPHanaController)
   Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=00 PREFER_SITE_TAKEOVER=true SID=HA1
   Operations: demote interval=0s timeout=320 (SAPHana_HA1_00-demote-interval-0s)
         methods interval=0s timeout=5 (SAPHana_HA1_00-methods-interval-0s)
         monitor interval=59 role=Master timeout=700 (SAPHana_HA1_00-monitor-interval-59)
         promote interval=0 timeout=3600 (SAPHana_HA1_00-promote-interval-0)
         reload interval=0s timeout=5 (SAPHana_HA1_00-reload-interval-0s)
         start interval=0 timeout=3600 (SAPHana_HA1_00-start-interval-0)
         stop interval=0 timeout=3600 (SAPHana_HA1_00-stop-interval-0)
         monitor interval=61 role=Slave timeout=700 (SAPHana_HA1_00-monitor-interval-61)

   RHEL 7.6 et versions ultérieures

   # pcs resource show msl_rsc_SAPHana_SID_HDBinstNr

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

   Master: msl_rsc_SAPHana_HA1_HDB00
   Meta Attrs: clone-node-max=1 interleave=true master-max=1
   Resource: rsc_SAPHana_HA1_HDB00 (class=ocf provider=heartbeat type=SAPHanaController)
   Attributes: AUTOMATED_REGISTER=true DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=00 PREFER_SITE_TAKEOVER=true SID=HA1
   Operations: demote interval=0s timeout=320 (rsc_SAPHana_HA1_HDB00-demote-interval-0s)
          methods interval=0s timeout=5 (rsc_SAPHana_HA1_HDB00-methods-interval-0s)
          monitor interval=60 role=Master timeout=700 (rsc_SAPHana_HA1_HDB00-monitor-interval-60)
          monitor interval=61 role=Slave timeout=700 (rsc_SAPHana_HA1_HDB00-monitor-interval-61)
          promote interval=0 timeout=3600 (rsc_SAPHana_HA1_HDB00-promote-interval-0)
          start interval=0 timeout=3600 (rsc_SAPHana_HA1_HDB00-start-interval-0)
          stop interval=0 timeout=3600 (rsc_SAPHana_HA1_HDB00-stop-interval-0)

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 rsc_ip_SAPHANA_SID_HDBinstNr \
  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.

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

   RHEL 8 et versions ultérieures

   # pcs constraint order start rsc_SAPHanaTopology_SID_HDBinstNr-clone then start rsc_SAPHana_SID_HDBinstNr-clone
   

   RHEL 7.6

   # pcs constraint order rsc_SAPHanaTopology_SID_HDBinstNr-clone then rsc_SAPHana_SID_HDBinstNr-master
   

2. Configure the majority maker to avoid taking an an active role in the cluster environment:

   RHEL 8.0 and later

   # pcs constraint location rsc_SAPHana_SID_HDBinstNr-clone avoids majority-maker-name
   
   # pcs constraint location rsc_SAPHanaTopology_SID_HDBinstNr-clone avoids majoritymaker

   RHEL 7.6

   # pcs constraint location msl_rsc_SAPHana_SID_HDBinstNr avoids majoritymaker
   
   # pcs constraint location rsc_SAPHanaTopology_SID_HDBinstNr-clone avoids majoritymaker

3. Vérifiez les contraintes :

   # pcs constraint

   Le résultat doit être semblable à ceci :

   Location Constraints:
   Resource: STONITH-hana-ha-1
     Disabled on: hana-ha-1 (score:-INFINITY)
   Resource: STONITH-hana-ha-1w1
     Disabled on: hana-ha-1w1 (score:-INFINITY)
   Resource: STONITH-hana-ha-2
     Disabled on: hana-ha-2 (score:-INFINITY)
   Resource: STONITH-hana-ha-2w1
     Disabled on: hana-ha-2w1 (score:-INFINITY)
   Resource: STONITH-majority-maker
     Disabled on: majority-maker (score:-INFINITY)
   Resource: rsc_SAPHanaTopology_HA1_HDB00-clone
     Disabled on: majority-maker (score:-INFINITY)
   Resource: rsc_SAPHana_HA1_HDB00-master
     Disabled on: majority-maker (score:-INFINITY)
   Ordering Constraints:
     start rsc_SAPHanaTopology_HA1_HDB00-clone then start rsc_SAPHana_HA1_HDB00-master (kind:Mandatory)

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.

   

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.

   

   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. Depuis n'importe quel hôte, en tant qu'utilisateur racine, créez une ressource de vérification de l'état pour le service HAProxy :

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

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

   # pcs resource group add rsc-group-name hc_SID_HDBinstNr rsc_ip_SAPHANA_SID_HDBinstNr

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

   RHEL 8.0 et versions ultérieures

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

   RHEL 7.6 et versions ultérieures

   # pcs constraint colocation add rsc-group-name with master msl_rsc_SAPHana_SID_HDBinstNr

4. Créez une contrainte d'ordre pour démarrer le groupe uniquement après la promotion de HANA :

   # pcs constraint order promote rsc_SAPHana_SID_HDBinstNr-clone then start rsc-group-name

   Vos contraintes finales doivent ressembler à l'exemple suivant :

   # pcs constraint
   
   Location Constraints:
   Resource: STONITH-hana-ha-1
    Disabled on: hana-ha-1 (score:-INFINITY)
   Resource: STONITH-hana-ha-1w1
    Disabled on: hana-ha-1w1 (score:-INFINITY)
   Resource: STONITH-hana-ha-2
    Disabled on: hana-ha-2 (score:-INFINITY)
   Resource: STONITH-hana-ha-2w1
    Disabled on: hana-ha-2w1 (score:-INFINITY)
   Resource: STONITH-majority-maker
    Disabled on: majority-maker (score:-INFINITY)
   Resource: rsc_SAPHanaTopology_HA1_HDB00-clone
    Disabled on: majority-maker (score:-INFINITY)
   Resource: rsc_SAPHana_HA1_HDB00-master
    Disabled on: majority-maker (score:-INFINITY)
   Ordering Constraints:
    start rsc_SAPHanaTopology_HA1_HDB00-clone then start rsc_SAPHana_HA1_HDB00-master (kind:Mandatory)
    promote rsc_SAPHana_HA1_HDB00-clone then start g-primary (kind:Mandatory) (id:order-rsc_SAPHana_HA1_HDB00-clone-g-primary-mandatory)
   Colocation Constraints:
    g-primary with rsc_SAPHana_HA1_HDB00-master (score:INFINITY) (rsc-role:Started) (with-rsc-role:Master)
   Ticket Constraints:

Terminer la configuration

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

   pcs property set maintenance-mode=false

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

   La sortie obtenue doit ressembler à ceci :

   RHEL 8 et versions ultérieures

   Cluster Summary:
   Stack: corosync
   Current DC: hana-ha-2w1 (version 2.0.5-9.el8_4.7-ba59be7122) - partition with quorum
   Last updated: Wed Oct 11 17:59:51 2023
   Last change:  Wed Oct 11 17:59:48 2023 by hacluster via crmd on hana-ha-2
   5 nodes configured
   17 resource instances configured
   
   Node List:
   Online: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 dru-somm ]
   
   Active Resources:
   STONITH-hana-ha-1     (stonith:fence_gce):     Started hana-ha-2
   STONITH-hana-ha-1w1   (stonith:fence_gce):     Started hana-ha-1
   STONITH-hana-ha-2     (stonith:fence_gce):     Started hana-ha-2w1
   STONITH-hana-ha-2w1   (stonith:fence_gce):     Started dru-somm
   STONITH-dru-somm    (stonith:fence_gce):     Started hana-ha-1
   Clone Set: SAPHanaTopology_HA1_00-clone [SAPHanaTopology_HA1_00]:
    Started: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 ]
   Clone Set: SAPHana_HA1_00-clone [SAPHana_HA1_00]-(promotable):
    Slaves: [ hana-ha-1w1 hana-ha-2w1 ]
   Resource Group: g-primary:
    healthcheck_HA1   (service:haproxy):       Started hana-ha-1
    ip_SAPHANA_HA1_00 (ocf::heartbeat:IPaddr2):        Started hana-ha-1
   
   Node Attributes:
   Node: hana-ha-1:
    hana_ha1_clone_state              : PROMOTED
    hana_ha1_gra                      : 2.0
    hana_ha1_remoteHost               : hana-ha-2w1
    hana_ha1_roles                    : master1:master:worker:master
    hana_ha1_site                     : hana-ha-1
    hana_ha1_sra                      : -
    hana_ha1_srmode                   : syncmem
    hana_ha1_vhost                    : hana-ha-1
    master-SAPHana_HA1_00             : 5
   Node: hana-ha-1w1:
    hana_ha1_clone_state              : DEMOTED
    hana_ha1_gra                      : 2.0
    hana_ha1_remoteHost               : hana-ha-2w1
    hana_ha1_roles                    : slave:slave:worker:slave
    hana_ha1_site                     : hana-ha-1
    hana_ha1_srmode                   : syncmem
    hana_ha1_vhost                    : hana-ha-1w1
    master-SAPHana_HA1_00             : -INFINITY
   Node: hana-ha-2:
    hana_ha1_clone_state              : DEMOTED
    hana_ha1_gra                      : 2.0
    hana_ha1_remoteHost               : hana-ha-1w1
    hana_ha1_roles                    : master1:master:worker:master
    hana_ha1_site                     : hana-ha-2
    hana_ha1_sra                      : -
    hana_ha1_srmode                   : syncmem
    hana_ha1_vhost                    : hana-ha-2
    master-SAPHana_HA1_00             : 100
   Node: hana-ha-2w1:
    hana_ha1_clone_state              : DEMOTED
    hana_ha1_gra                      : 2.0
    hana_ha1_remoteHost               : hana-ha-1w1
    hana_ha1_roles                    : slave:slave:worker:slave
    hana_ha1_site                     : hana-ha-2
    hana_ha1_srmode                   : syncmem
    hana_ha1_vhost                    : hana-ha-2w1
    master-SAPHana_HA1_00             : -12200
   Node: dru-somm:
    hana_ha1_remoteHost               : hana-ha-2w1
    hana_ha1_srmode                   : syncmem

   RHEL 7.6 et versions ultérieures

   Stack: corosync
   Current DC: majority-maker (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
   Last updated: Wed Oct 11 17:58:07 2023
   Last change: Wed Oct 11 17:57:57 2023 by hacluster via crmd on hana-ha-2w1
   
   5 nodes configured
   17 resource instances configured
   
   Online: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 majority-maker ]
   
   Active resources:
   
   STONITH-hana-ha-1 (stonith:fence_gce):    Started hana-ha-1w1
   STONITH-hana-ha-1w1       (stonith:fence_gce):    Started hana-ha-2
   STONITH-hana-ha-2 (stonith:fence_gce):    Started hana-ha-1
   STONITH-hana-ha-2w1       (stonith:fence_gce):    Started majority-maker
   STONITH-majority-maker (stonith:fence_gce):    Started hana-ha-1w1
   Master/Slave Set: msl_rsc_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00]
    rsc_SAPHana_HA1_HDB00      (ocf::heartbeat:SAPHanaController):     Master hana-ha-1 (Monitoring)
    Slaves: [ hana-ha-1w1 hana-ha-2 hana-ha-2w1 ]
   Clone Set: rsc_SAPHanaTopology_HA1_HDB00-clone [rsc_SAPHanaTopology_HA1_HDB00]
    Started: [ hana-ha-1 hana-ha-1w1 hana-ha-2 hana-ha-2w1 ]
   Resource Group: g-primary
    hc_HA1_HDB00       (service:haproxy):      Started hana-ha-1
    rsc_ip_SAPHANA_HA1_HDB00   (ocf::heartbeat:IPaddr2):       Started hana-ha-1
   
   Node Attributes:
   Node hana-ha-1:
     hana_ha1_clone_state              : PROMOTED
     hana_ha1_remoteHost               : hana-ha-2
     hana_ha1_roles                    : master1:master:worker:master
     hana_ha1_site                     : hana-ha-1
     hana_ha1_srmode                   : syncmem
     hana_ha1_vhost                    : hana-ha-1
     master-rsc_SAPHana_HA1_HDB00      : 150
   Node hana-ha-1w1:
     hana_ha1_clone_state              : DEMOTED
     hana_ha1_remoteHost               : hana-ha-2w1
     hana_ha1_roles                    : slave:slave:worker:slave
     hana_ha1_site                     : hana-ha-1
     hana_ha1_srmode                   : syncmem
     hana_ha1_version                  : 2.00.052.00.1599235305
     hana_ha1_vhost                    : hana-ha-1w1
     master-rsc_SAPHana_HA1_HDB00      : -10000
   Node hana-ha-2:
     hana_ha1_clone_state              : DEMOTED
     hana_ha1_remoteHost               : hana-ha-2w1
     hana_ha1_roles                    : master1:master:worker:master
     hana_ha1_site                     : hana-ha-2
     hana_ha1_srmode                   : syncmem
     hana_ha1_vhost                    : hana-ha-2
     master-rsc_SAPHana_HA1_HDB00      : 100
   Node hana-ha-2w1:
     hana_ha1_clone_state              : DEMOTED
     hana_ha1_remoteHost               : hana-ha-1
     hana_ha1_roles                    : slave:slave:worker:slave
     hana_ha1_site                     : hana-ha-2
     hana_ha1_srmode                   : syncmem
     hana_ha1_vhost                    : hana-ha-2w1
     master-rsc_SAPHana_HA1_HDB00      : -12200
   Node majority-maker:
     hana_ha1_srmode                   : syncmem

3. En cas de défaillance des ressources du cluster, vous devrez peut-être exécuter la commande suivante :

   pcs resource cleanup

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 hana-ha-vm-1w1 hana-ha-vm-2w1]
   
   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
   STONITH-hana-ha-vm-1w1   (stonith:fence_gce):    Started hana-ha-vm-2w1
   STONITH-hana-ha-vm-1w1   (stonith:fence_gce):    Started hana-ha-vm-mm
   STONITH-hana-ha-vm-mm   (stonith:fence_gce):    Started hana-ha-vm-1w1
   Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
       Started: [ hana-ha-vm-1 hana-ha-vm-2 hana-ha-vm-1w1 hana-ha-vm-2w1
       Stopped: [ hana-ha-vm-mm ] ]
   Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
       Masters: [ hana-ha-vm-2 ]
       Slaves: [ hana-ha-vm-1 hana-ha-vm-1w1 hana-ha-vm-2w1
       Stopped: [ hana-ha-vm-mm ] ]
   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

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 :

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

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 :

• Guide d'utilisation de SAP HANA
• Guide d'installation et de mise à jour de SAP HANA

Étapes suivantes

Pour en savoir plus, consultez les ressources suivantes :

• Installer et configurer un cluster à haute disponibilité Red Hat Enterprise Linux 7.6 (et versions ultérieures) sur Google Compute Cloud
• Réplication automatique du système SAP HANA avec scaling à la hausse dans un cluster Pacemaker
• Règles de prise en charge pour les clusters à haute disponibilité RHEL - Exigences générales pour le cloisonnement/STONITH
• Guide de planification de haute disponibilité SAP HANA
• Guide de planification de reprise après sinistre SAP HANA
• Pour en savoir plus sur l'administration et la surveillance des VM, consultez le guide d'utilisation de SAP HANA.