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

Ce guide vous explique comment déployer et configurer un cluster à haute disponibilité (HA) SUSE Linux Enterprise Server (SLES) optimisé pour les performances pour un système SAP HANA à évolutivité horizontale sur Google Cloud.

Ce guide comprend les étapes suivantes :

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

Ce guide comprend également les étapes de configuration 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 modèle Deployment Manager fourni par Google Cloud, spécifiez un tag avec networkTag: [TAG].
  • Créez les VM sans adresse IP externe. Si vous utilisez les modèles Deployment Manager fournis par Google Cloud, spécifiez publicIP: No.

Créer un réseau

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

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

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

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

Console

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

   Accéder aux réseaux VPC

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

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

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

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

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

gcloud

1. Accédez à Cloud Shell.

   Accéder à Cloud Shell

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

   gcloud compute networks create NETWORK_NAME --subnet-mode custom

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

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

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

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

   Remplacez les éléments suivants :

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

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

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

Configurer une passerelle NAT

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

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

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

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

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

Ajouter des règles de pare-feu

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

Remarque : La procédure suivante est une version simplifiée des instructions permettant de créer des règles de pare-feu. Pour obtenir des instructions plus détaillées, consultez la section Créer des règles de pare-feu.

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

Console

1. Dans la console Google Cloud, accédez à la page Pare-feu de Compute Engine.

   Accéder à la page "Pare-feu"

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

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

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

gcloud

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

$ gcloud compute firewall-rules create firewall-name
--direction=INGRESS --priority=1000 \
--network=network-name --action=ALLOW --rules=protocol:port \
--source-ranges ip-range --target-tags=network-tags

Déployer les VM et SAP HANA

Pour déployer un système SAP HANA multinœuds à haute disponibilité configuré pour une redondance complète des zones, utilisez le modèle Cloud Deployment Manager pour SAP HANA comme base pour la configuration, ainsi qu'un modèle supplémentaire pour déployer une instance créatrice de majorité.

Le déploiement comprend les éléments suivants :

• Deux systèmes SAP HANA concordants, chacun avec au moins deux nœuds de calcul.
• 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.

Vous ajoutez une définition pour tous les systèmes au même fichier YAML, de sorte que Deployment Manager déploie toutes les ressources sous un même déploiement. Une fois les systèmes SAP HANA et l'instance créatrice de majorité déployés, définissez et configurez le cluster à haute disponibilité.

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

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

   Accéder à la page "Quotas"

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

   Accéder à Cloud Shell

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

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

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

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

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

6. Dans le fichier template.yaml, terminez la définition du système SAP HANA principal. Spécifiez les valeurs des propriétés en remplaçant les crochets et leur contenu par les valeurs de votre installation. Ces propriétés sont décrites dans le tableau ci-dessous.

   Pour créer des instances de VM sans installer SAP HANA, supprimez ou commentez toutes les lignes commençant par sap_hana_.

   Valeur	Type de données	Description
   type	Chaîne	Spécifie l'emplacement, le type et la version du modèle Deployment Manager à utiliser lors du déploiement. Le fichier YAML comprend deux spécifications type, dont l'une est laissée en commentaire. La spécification type qui est active par défaut spécifie la version du modèle en tant que latest. La spécification type qui est laissée en commentaire spécifie une version de modèle spécifique avec un horodatage. Si tous vos déploiements doivent utiliser la même version de modèle, utilisez la spécification type qui inclut l'horodatage.
   instanceName	Chaîne	Nom de l'instance de VM en cours de définition. Spécifiez des noms différents dans les définitions des VM principale et secondaire. Ces noms ne doivent contenir que des lettres minuscules, des chiffres ou des traits d'union.
   instanceType	Chaîne	Type de machine virtuelle Compute Engine nécessaire à l'exécution de SAP HANA. Si vous avez besoin d'un type de VM personnalisé, spécifiez un type de VM prédéfini avec un nombre de processeurs virtuels le plus proche possible de la quantité dont vous avez besoin tout en étant légèrement supérieur. Une fois le déploiement terminé, modifiez le nombre de processeurs virtuels et la quantité de mémoire La valeur minimale recommandée d'instanceType pour l'instance créatrice de majorité est n1-standard-2 ou l'équivalent d'au moins 2 cœurs de processeur et de 2 Go de mémoire.
   zone	String	Zone Google Cloud dans laquelle déployer l'instance de VM que vous définissez. Spécifiez des zones différentes de la même région pour les définitions des instances HANA principales et secondaires, et de l'instance créatrice de majorité. Ces zones doivent se trouver dans la même région que celle que vous avez sélectionnée pour votre sous-réseau.
   subnetwork	Chaîne	Nom du sous-réseau que vous avez créé précédemment. Si vous procédez au déploiement sur un VPC partagé, spécifiez cette valeur en tant que [SHAREDVPC_PROJECT]/[SUBNETWORK]. Exemple :myproject/network1
   linuxImage	Chaîne	Nom de la famille d'images ou de l'image du système d'exploitation Linux que vous utilisez avec SAP HANA. Pour spécifier une famille d'images, ajoutez le préfixe family/ au nom de la famille. Exemple :family/sles-15-sp1-sap Pour spécifier une image spécifique, indiquez uniquement le nom de l'image. Pour obtenir la liste des images et des familles disponibles, consultez la page Images dans la console Google Cloud.
   linuxImageProject	String	Le projet Google Cloud qui contient l'image que vous allez utiliser. Ce projet peut être votre propre projet ou un projet d'image Google Cloud, tel que suse-sap-cloud. Pour en savoir plus sur les projets d'image Google Cloud, consultez la page Images dans la documentation Compute Engine.
   sap_hana_deployment_bucket	String	Nom du bucket Google Cloud Storage de votre projet contenant les fichiers d'installation et de révision de SAP HANA que vous avez importés précédemment. Tous les fichiers de révision de mise à niveau du bucket sont appliqués à SAP HANA au cours du processus de déploiement.
   sap_hana_sid	Chaîne	ID système (SID) SAP HANA. L'ID doit comporter trois caractères alphanumériques et commencer par une lettre. Les lettres doivent être saisies en majuscules.
   sap_hana_instance_number	Entier	Numéro d'instance (0 à 99) du système SAP HANA. La valeur par défaut est 0.
   sap_hana_sidadm_password	Chaîne	Mot de passe de l'administrateur du système d'exploitation (OS). Les mots de passe doivent comporter au moins huit caractères et inclure au moins une lettre majuscule, une lettre minuscule et un chiffre. Attention : Modifiez le mot de passe une fois l'installation terminée.
   sap_hana_system_password	Chaîne	Mot de passe du super-utilisateur de la base de données. Les mots de passe doivent comporter au moins huit caractères et inclure au moins une lettre majuscule, une lettre minuscule et un chiffre. Attention : Modifiez le mot de passe une fois l'installation terminée.
   sap_hana_sidadm_uid	Integer	La valeur par défaut pour l'ID utilisateur SID_LCadm est 900 afin d'éviter les conflits entre les groupes créés par les utilisateurs et SAP HANA. Vous pouvez modifier cette valeur si nécessaire.
   sap_hana_sapsys_gid	Entier	L'ID de groupe par défaut pour sapsys est 79. En spécifiant une valeur supérieure, vous pouvez remplacer cette valeur selon vos besoins.
   sap_hana_scaleout_nodes	Integer	Spécifiez 1 ou une valeur supérieure.
   sap_hana_shared_nfs	String	Point de montage NFS du volume /hana/shared. Par exemple, 10.151.91.122:/hana_shared_nfs. Remarque : Le point d'installation NFS du volume /hana/shared doit être vide et ne doit être utilisé par aucun autre déploiement avant d'exécuter Deployment Manager.
   sap_hana_backup_nfs	String	Point de montage NFS du volume /hanabackup. Exemple :10.216.41.122:/hana_backup_nfs
   networkTag	String	Tag réseau qui représente votre instance de VM à des fins de routage ou d'établissement/application de règles de pare-feu. Si vous spécifiez publicIP: No et ne spécifiez pas de tag réseau, veillez à fournir un autre moyen d'accès à Internet.
   nic_type	String	Facultatif, mais recommandé si disponible pour la machine cible et la version de l'OS. Spécifie l'interface réseau à utiliser avec l'instance de VM. Vous pouvez spécifier la valeur GVNIC ou VIRTIO_NET. Pour utiliser une carte d'interface réseau virtuelle Google (gVNIC), vous devez spécifier une image de l'OS compatible avec gVNIC comme valeur de la propriété linuxImage. Pour obtenir la liste des images de l'OS, consultez la section Détails des systèmes d'exploitation. Si vous ne spécifiez pas de valeur pour cette propriété, l'interface réseau est automatiquement sélectionnée en fonction du type de machine que vous spécifiez pour la propriété instanceType. Cet argument est disponible dans les versions 202302060649 du modèle Deployment Manager ou ultérieures.
   publicIP	Booléen	Facultatif. Détermine si une adresse IP publique est ajoutée à votre instance de VM. La valeur par défaut est Yes. Remarque : Ne spécifiez No que si vous avez configuré une passerelle NAT avec un tag réseau défini pour la VM ou si vous avez fourni à la VM une autre route vers Internet. Si aucun moyen d'accès à Internet n'est disponible, l'installation échoue.
   serviceAccount	Chaîne	Facultatif. Spécifie un compte de service destiné à être utilisé par les VM hôtes et par les programmes exécutés sur celles-ci. Spécifiez l'adresse e-mail du compte de service. Par exemple, [e-mail]. Par défaut, le compte de service Compute Engine par défaut est utilisé. Pour en savoir plus, consultez la page Gestion de l'authentification et des accès pour les programmes SAP sur Google Cloud.

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

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

   • name
   • instanceName
   • zone

9. Téléchargez le fichier de configuration de l'instance créatrice de majorité sap_majoritymaker.yaml :

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

10. Copiez et collez la spécification YAML à partir du fichier sap_majoritymaker.yaml, en partant de la ligne 6 jusqu'au bas du fichier template.yaml SAP HANA.

11. Terminez la définition de l'instance créatrice de majorité :

    • Spécifiez une zone différente des deux systèmes SAP HANA.
    • La valeur minimale recommandée d'instanceType est n1-standard-2 ou l'équivalent d'au moins 2 cœurs de processeur et de 2 Go de mémoire.

    Vous devez maintenant posséder trois ressources regroupées dans votre fichier YAML, deux clusters SAP HANA et une instance créatrice de majorité, ainsi que leurs propriétés configurables.

12. Créez les instances :

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

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

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

Exemple de fichier de configuration template.yaml complet

L'exemple suivant montre un fichier de configuration template.yaml terminé qui déploie deux clusters à évolutivité horizontale avec un système SAP HANA installé, et une seule instance de VM agissant en tant que créatrice de majorité.

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

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

Les propriétés networkTag, serviceAccount, sap_hana_sidadm_uid et sap_hana_sapsys_gid proviennent de la section "Options avancées" du modèle de fichier de configuration. Les propriétés sap_hana_sidadm_uid et sap_hana_sapsys_gid sont incluses pour afficher leurs valeurs par défaut, qui sont utilisées car les propriétés sont commentées.

resources:
- name: sap_hana_primary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/yyyymmddhhmm/dm-templates/sap_hana/sap_hana.py
  #
  properties:
    instanceName: hana-ha-vm-1
    instanceType: n2-highmem-32
    zone: us-central1-a
    subnetwork: example-subnet-us-central1
    linuxImage: family/sles-15-sp1-sap
    linuxImageProject: suse-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Tempa55word
    sap_hana_system_password: Tempa55word
    sap_hana_scaleout_nodes: 2
    sap_hana_shared_nfs: 10.151.91.123:/hana_shared_nfs
    sap_hana_backup_nfs: 10.216.41.123:/hana_backup_nfs
    networkTag: cluster-ntwk-tag
    serviceAccount: [e-mail]
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79

- name: sap_hana_secondary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/yyyymmddhhmm/dm-templates/sap_hana/sap_hana.py
  #
  properties:
    instanceName: hana-ha-vm-2
    instanceType: n2-highmem-32
    zone: us-central1-c
    subnetwork: example-subnet-us-central1
    linuxImage: family/sles-15-sp1-sap
    linuxImageProject: suse-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Google123
    sap_hana_system_password: Google123
    sap_hana_scaleout_nodes: 2
    sap_hana_shared_nfs: 10.141.91.124:/hana_shared_nfs
    sap_hana_backup_nfs: 10.106.41.124:/hana_backup_nfs
    networkTag: cluster-ntwk-tag
    serviceAccount: [e-mail]
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79
    
- name: sap_majoritymaker
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_majoritymaker/sap_majoritymaker.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/202208181245/dm-templates/sap_majoritymaker/sap_majoritymaker.py
  properties:
    instanceName: sap-majoritymaker
    instanceType: n1-standard-2
    zone: us-central1-b
    subnetwork: example-subnet-us-central1
    linuxImage: family/sles-15-sp1-sap
    linuxImageProject: suse-sap-cloud
    publicIP: No
    

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

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

• À des fins de configuration, votre poste de travail local, un hôte bastion ou un serveur de saut
• Pour l'accès entre les nœuds du cluster, les autres VM hôtes dans le cluster à haute disponibilité

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

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

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

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

Vérifier le déploiement des VM et de SAP HANA

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

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

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

   Accéder à CloudLogging

2. Filtrez les journaux :

   Logs Explorer

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

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

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

      resource.type="global"
      "Deployment"
      

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

   Ancienne visionneuse de journaux

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

3. Analysez les journaux filtrés :

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

   • Si vous rencontrez une erreur de quota :

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

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

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

Vérifier l'état du déploiement de l'instance créatrice de majorité

Vous pouvez vérifier l'état du déploiement de l'instance créatrice de majorité à l'aide de la commande suivante.

gcloud compute instances describe MAJORITY_MAKER_HOSTNAME --zone MAJORITY_MAKER_ZONE --format="table[box,title='Deployment Status'](name:label=Instance_Name,metadata.items.status:label=Status)"

Si l'état Complete s'affiche, le traitement du déploiement a réussi pour l'instance créatrice de majorité. Pour un déploiement en cours, l'état <blank> s'affiche.

Vérifier la configuration des VM et de SAP HANA

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

   

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

   $ sudo su -

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

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

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

   # su - SID_LCadm

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

   > HDB info

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

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

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

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

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

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

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

2. Exécutez la commande ci-dessous :

   systemctl status google-cloud-sap-agent

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

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

   .

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

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

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

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

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

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

Configurer la surveillance pour SAP HANA

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

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

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

Télécharger des packages SUSE

Désinstallez les agents de ressources utilisés pour les déploiements à scaling vertical et remplacez-les par les agents de ressources utilisés pour le scaling horizontal.

Étapes manuelles

Procédez comme suit sur tous les hôtes, y compris sur l'instance créatrice de majorité :

1. Désinstallez les agents de ressources HANA à scaling vertical :

   zypper remove SAPHanaSR SAPHanaSR-doc

2. Installez les agents de ressources à scaling horizontal HANA :

   zypper in SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc

3. Installez socat :

   zypper install socat

4. Installez les derniers correctifs du système d'exploitation :

   zypper patch

É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 --zone $HOST -- "sudo zypper remove -y SAPHanaSR SAPHanaSR-doc; sudo zypper in -y SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc socat; sudo zypper patch -y"; 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

SUSE 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_saphanasrmultitarget]
   provider = SAPHanaSrMultiTarget
   path = /usr/share/SAPHanaSR-ScaleOut/
   execution_order = 1
   
   [ha_dr_provider_sustkover]
   provider = susTkOver
   path = /usr/share/SAPHanaSR-ScaleOut/
   execution_order = 2
   sustkover_timeout = 30
   
   [ha_dr_provider_suschksrv]
   provider = susChkSrv
   path = /usr/share/SAPHanaSR-ScaleOut/
   execution_order = 3
   action_on_lost = stop
   
   [trace]
   ha_dr_saphanasrmultitarget = info
   ha_dr_sustkover = 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/SAPHanaSR

4. Dans le fichier /etc/sudoers.d/SAPHanaSR, ajoutez le texte suivant :

   Remplacez SID_LC par le SID, en lettres minuscules.

   SID_LCadm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_*
   SID_LCadm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_SID_LC_gsh *
   SID_LCadm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=SID_LC *

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

   • Pour SLES pour SAP 15 SP3 et versions ultérieures :

     @includedir /etc/sudoers.d

   • Pour les versions jusqu'à SLES pour SAP 15 SP2 :

     #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 SUSE, 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. Une fois la configuration du cluster SAP HANA terminée, vous pouvez vérifier que le hook fonctionne correctement lors d'un test de basculement, comme décrit dans les sections Dépannage du hook Python SAPHanaSR et La reprise du cluster à haute disponibilité prend trop de temps en cas de défaillance du serveur d'index HANA.

Configurer la prise en charge du basculement Cloud Load Balancing

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

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

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

1. Ouvrez Cloud Shell.

   Accéder à Cloud Shell

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

   $ gcloud compute addresses create VIP_NAME \
     --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
     --addresses VIP_ADDRESS

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

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

   $ gcloud compute addresses describe VIP_NAME \
     --region CLUSTER_REGION

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

   address: 10.0.0.19
   addressType: INTERNAL
   creationTimestamp: '2020-05-20T14:19:03.109-07:00'
   description: ''
   id: '8961491304398200872'
   kind: compute#address
   name: vip-for-hana-ha
   networkTier: PREMIUM
   purpose: GCE_ENDPOINT
   region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1
   selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/addresses/vip-for-hana-ha
   status: RESERVED
   subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-subnet-us-central1

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

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

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

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

   $ gcloud compute instance-groups unmanaged list

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

   NAME          ZONE           NETWORK          NETWORK_PROJECT        MANAGED  INSTANCES
   hana-ha-ig-1  us-central1-a  example-network  example-project-123456 No       1
   hana-ha-ig-2  us-central1-c  example-network  example-project-123456 No       1

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

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

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

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

   $ gcloud compute health-checks describe HEALTH_CHECK_NAME

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

   checkIntervalSec: 10
   creationTimestamp: '2020-05-20T21:03:06.924-07:00'
   healthyThreshold: 2
   id: '4963070308818371477'
   kind: compute#healthCheck
   name: hana-health-check
   selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/hana-health-check
   tcpHealthCheck:
    port: 60000
    portSpecification: USE_FIXED_PORT
    proxyHeader: NONE
   timeoutSec: 10
   type: TCP
   unhealthyThreshold: 2

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

Définissez une règle de pare-feu pour un port situé dans la plage privée qui permet d'accéder à vos VM hôtes à partir des plages d'adresses IP utilisées par les vérifications d'état de Compute Engine, 35.191.0.0/16 et 130.211.0.0/22. Pour en savoir plus, consultez la section Créer des règles de pare-feu pour les vérifications d'état.

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

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

2. Si vous n'en avez pas encore, créez une règle de pare-feu pour autoriser les vérifications de l'état :

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

   Exemple :

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

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

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

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

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

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

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

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

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

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

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

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

1. Installez l'utilitaire socat sur les VM hôtes principales et secondaires en tant qu'utilisateur racine :

   # zypper install -y socat

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

   # 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 l'implémentation SUSE d'un cluster Pacemaker sur des VM Compute Engine pour SAP HANA.

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

Télécharger les scripts d'agent de ressources

Étapes manuelles

En tant qu'utilisateur racine sur tous les hôtes principaux et secondaires, ainsi que sur l'instance créatrice de majorité, téléchargez les scripts d'agent de ressources requis :

# mkdir -p /usr/lib64/stonith/plugins/external
# curl https://storage.googleapis.com/sapdeploy/pacemaker-gcp/gcpstonith -o /usr/lib64/stonith/plugins/external/gcpstonith
# chmod +x /usr/lib64/stonith/plugins/external/gcpstonith

Étapes automatisées

Sinon, pour télécharger les scripts d'agent de ressources requis pour toutes les instances regroupées dans nodes.txt, exécutez le script suivant à partir de la console Google Cloud :

while read -u10 HOST ;  do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST -- "echo 'CLOUDSDK_PYTHON=/usr/bin/python' | sudo tee -a /etc/sysconfig/pacemaker; sudo curl --silent https://storage.googleapis.com/sapdeploy/pacemaker-gcp/gcpstonith -o /usr/lib64/stonith/plugins/external/gcpstonith; sudo chmod +x /usr/lib64/stonith/plugins/external/gcpstonith"; done 10< nodes.txt

Initialiser le cluster

Sur l'hôte principal, en tant qu'utilisateur racine, initialisez le cluster :

SLES 15

crm cluster init -y

SLES 12

ha-cluster-init -y

Ignorez les avertissements liés au SBD et au mot de passe par défaut. Le SBD et le mot de passe par défaut ne sont pas utilisés dans ce déploiement.

Configurer le cluster

Procédez comme suit sur l'hôte principal en tant qu'utilisateur racine :

Activer le mode de maintenance

Faites passer le cluster Pacemaker en mode de maintenance :

crm configure property maintenance-mode="true"

Configurer les propriétés générales du cluster

Configurez les propriétés générales du cluster suivantes :

crm configure property stonith-timeout="300s"
crm configure property stonith-action="reboot"
crm configure property stonith-enabled="true"
crm configure property cluster-infrastructure="corosync"
crm configure property cluster-name="hacluster"
crm configure property placement-strategy="balanced"
crm configure property no-quorum-policy="freeze"
crm configure property concurrent-fencing="true"

crm configure rsc_defaults migration-threshold="50"
crm configure rsc_defaults resource-stickiness="1000"

crm configure op_defaults timeout="600"

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

Associer tous les hôtes au cluster Pacemaker

Associez tous les autres hôtes, y compris l'instance créatrice de majorité, au cluster Pacemaker sur l'hôte principal :

Étapes manuelles

SLES 15

crm cluster join -y -c PRIMARY_HOST_NAME

SLES 12

ha-cluster-join -y -c PRIMARY_HOST_NAME

É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 echo "Joining $HOST to Pacemaker cluster";
gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST -- sudo ha-cluster-join -y -c PRIMARY_HOST_NAME;
done 10< nodes.txt

Ignorez le message d'erreur ERROR: cluster.join: Abort: Cluster is currently active qui est déclenché en associant le nœud principal à lui-même.

Depuis n'importe quel hôte, en tant qu'utilisateur racine, vérifiez que le cluster affiche tous les nœuds :

# crm_mon -s

La sortie obtenue doit ressembler à ceci :

CLUSTER OK: 5 nodes online, 0 resources configured

Configurer le cloisonnement

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

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

Créer les ressources de l'appareil de cloisonnement

Étapes manuelles

Sur l'hôte principal, en tant qu'utilisateur racine, créez les ressources de cloisonnement pour tous les nœuds du cluster principal et secondaire :

1. Exécutez la commande suivante après avoir remplacé PRIMARY_HOST_NAME par le nom d'hôte d'un nœud du cluster principal :

   # crm configure primitive STONITH-"PRIMARY_HOST_NAME" stonith:external/gcpstonith \
       op monitor interval="300s" timeout="120s" \
       op start interval="0" timeout="60s" \
       params instance_name="PRIMARY_HOST_NAME" gcloud_path="/usr/bin/gcloud" logging="yes" \
       pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30

2. Répétez l'étape précédente pour tous les autres nœuds du cluster principal.

3. Exécutez la commande suivante après avoir remplacé SECONDARY_HOST_NAME par le nom d'hôte d'un nœud du cluster secondaire.

   # crm configure primitive STONITH-"SECONDARY_HOST_NAME" stonith:external/gcpstonith \
       op monitor interval="300s" timeout="120s" \
       op start interval="0" timeout="60s" \
       params instance_name="SECONDARY_HOST_NAME" gcloud_path="/usr/bin/gcloud" logging="yes" \
       pcmk_reboot_timeout=300 pcmk_monitor_retries=4

4. Répétez l'étape précédente pour tous les autres nœuds du cluster secondaire.

5. Exécutez la commande suivante après avoir remplacé MAJORITY_MAKER_HOSTNAME par le nom d'hôte de l'instance majoritaire :

   # crm configure primitive STONITH-"MAJORITY_MAKER_HOSTNAME" stonith:external/gcpstonith \
       op monitor interval="300s" timeout="120s" \
       op start interval="0" timeout="60s" \
       params instance_name="MAJORITY_MAKER_HOSTNAME" gcloud_path="/usr/bin/gcloud" logging="yes" \
       pcmk_reboot_timeout=300 pcmk_monitor_retries=4

6. Définissez l'emplacement de l'appareil de cloisonnement :

   # crm configure location LOC_STONITH_"PRIMARY_HOST_NAME" \
       STONITH-"PRIMARY_HOST_NAME" -inf: "PRIMARY_HOST_NAME"

7. Répétez les étapes précédentes pour tous les autres hôtes des clusters principaux et secondaires, y compris l'hôte créateur de majorité.

Étapes automatisées

Sinon, pour configurer le cloisonnement pour toutes les instances regroupées dans nodes.txt, exécutez le script suivant à partir de la console Google Cloud :

while read -u10 HOST;  do gcloud compute ssh --tunnel-through-iap --quiet --zone $HOST   -- "sudo crm configure primitive STONITH-\$HOSTNAME stonith:external/gcpstonith op monitor interval=\"300s\" timeout=\"60s\" on-fail=\"restart\" op start interval=\"0\" timeout=\"60s\" onfail=\"restart\" params instance_name=\$HOSTNAME gcloud_path=\"/usr/bin/gcloud\" logging=\"yes\" pcmk_reboot_timeout=300 pcmk_monitor_retries=4; sudo crm configure location LOC_STONITH_\$HOSTNAME STONITH-\$HOSTNAME -inf: \$HOSTNAME"; done 10< nodes.txt

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

Créer une ressource IP de cluster local pour l'adresse IP virtuelle

Pour configurer l'adresse IP virtuelle dans le système d'exploitation, créez une ressource IP de cluster locale pour l'adresse IP virtuelle que vous avez réservée précédemment :

# crm configure primitive rsc_vip_int-primary IPaddr2 \
     params ip=VIP_ADDRESS cidr_netmask=32 nic="eth0" op monitor interval=3600s timeout=60s

Configurer le service d'aide de vérification de l'état

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.

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

Ces instructions utilisent l'utilitaire socat comme écouteur.

1. Sur les deux hôtes en mode root, installez socat utility :

   # zypper in -y socat

2. Sur l'hôte principal, créez une ressource pour le service de vérification d'état de l'outil d'aide :

   crm configure primitive rsc_healthcheck-primary anything \
   params binfile="/usr/bin/socat" \
   cmdline_options="-U TCP-LISTEN:HEALTHCHECK_PORT_NUM,backlog=10,fork,reuseaddr /dev/null" \
   op monitor timeout=20s interval=10s \
   op_params depth=0

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

   # crm configure group g-primary rsc_vip_int-primary rsc_healthcheck-primary meta resource-stickiness="0"

Créer la ressource primitive SAPHanaTopology

Vous définissez la ressource primitive SAPHanaTopology dans un fichier de configuration temporaire, que vous importez ensuite dans Corosync.

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

1. Créez un fichier de configuration temporaire pour les paramètres de configuration SAPHanaTopology :

   # vi /tmp/cluster.tmp

2. Effectuez un copier/coller des définitions de ressources SAPHanaTopology dans le fichier /tmp/cluster.tmp :

   primitive rsc_SAPHanaTopology_SID_HDBINST_NUM ocf:suse:SAPHanaTopology \
    operations \$id="rsc_sap2_SID_HDBINST_NUM-operations" \
    op monitor interval="10" timeout="600" \
    op start interval="0" timeout="600" \
    op stop interval="0" timeout="300" \
    params SID="SID" InstanceNumber="INST_NUM"
   
   clone cln_SAPHanaTopology_SID_HDBINST_NUM rsc_SAPHanaTopology_SID_HDBINST_NUM \
    meta clone-node-max="1" target-role="Started" interleave="true"
   location SAPHanaTop_not_on_majority_maker cln_SAPHanaTopology_SID_HDBINST_NUM -inf: MAJORITY_MAKER_HOSTNAME

3. Modifiez le fichier /tmp/cluster.tmp pour remplacer les variables par le SID et le numéro d'instance de votre système SAP HANA.

4. Sur l'hôte principal, en mode root, chargez le contenu du fichier /tmp/cluster.tmp dans Corosync :

   crm configure load update /tmp/cluster.tmp

Créer la ressource primitive SAPHana

Vous définissez la ressource primitive SAPHana à l'aide de la même méthode que celle utilisée pour la ressource SAPHanaTopology, à savoir un fichier de configuration temporaire, que vous importez ensuite dans Corosync.

1. Remplacez le fichier de configuration temporaire :

   # rm /tmp/cluster.tmp
   # vi /tmp/cluster.tmp

2. Effectuez un copier/coller des définitions de ressources SAPHana dans le fichier /tmp/cluster.tmp :

   primitive rsc_SAPHana_SID_HDBINST_NUM ocf:suse:SAPHanaController \
    operations \$id="rsc_sap_SID_HDBINST_NUM-operations" \
    op start interval="0" timeout="3600" \
    op stop interval="0" timeout="3600" \
    op promote interval="0" timeout="3600" \
    op demote interval="0" timeout="3600" \
    op monitor interval="60" role="Master" timeout="700" \
    op monitor interval="61" role="Slave" timeout="700" \
    params SID="SID" InstanceNumber="INST_NUM" PREFER_SITE_TAKEOVER="true" \
    DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="true"
   
   ms msl_SAPHana_SID_HDBINST_NUM rsc_SAPHana_SID_HDBINST_NUM \
    meta master-node-max="1" master-max="1" clone-node-max="1" \
    target-role="Started" interleave="true"
   
   colocation col_saphana_ip_SID_HDBINST_NUM 4000: g-primary:Started \
    msl_SAPHana_SID_HDBINST_NUM:Master
   order ord_SAPHana_SID_HDBINST_NUM Optional: cln_SAPHanaTopology_SID_HDBINST_NUM \
    msl_SAPHana_SID_HDBINST_NUM
   location SAPHanaCon_not_on_majority_maker  msl_SAPHana_SID_HDBINST_NUM -inf: MAJORITY_MAKER_HOSTNAME

   Pour un cluster HA SAP HANA à niveaux multiples, 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. Pour en savoir plus, consultez les pages suivantes :

   • Scaling à la hausse de la réplication du système SAP HANA
   • Cluster HA de scaling à la hausse HANA avec réplication du système et basculement automatique

3. Sur l'hôte principal, en mode root, chargez le contenu du fichier /tmp/cluster.tmp dans Corosync :

   crm configure load update /tmp/cluster.tmp

Vérifier que la réplication du système SAP HANA est active

Sur l'hôte principal, en tant que SID_LCadm, vérifiez l'état de la réplication :

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

Activer le cluster

1. Sur l'hôte principal, en mode root, désactivez le mode de maintenance pour le cluster :

   # crm configure property maintenance-mode="false"

   Si vous êtes invité à supprimer "maintenance", saisissez y.

2. Patientez 15 secondes, puis vérifiez l'état du cluster sur l'hôte principal en tant qu'utilisateur racine :

   # crm status

   Les exemples suivants montrent l'état d'un cluster actif et correctement configuré :

7 nodes configured
21 resources configured
Online: [   hana-ha-vm-1 hana-ha-vm-1w1 hana-ha-vm-1w2 hana-ha-vm-2 hana-ha-vm-2w1 hana-ha-vm-2w2 sap-majoritymaker ]


Full list of resources:


 STONITH-hana-ha-vm-1   (stonith:external/gcpstonith):  Started hana-ha-vm-1w2
 STONITH-hana-ha-vm-1w1 (stonith:external/gcpstonith):  Started hana-ha-vm-1
 STONITH-hana-ha-vm-1w2 (stonith:external/gcpstonith):  Started hana-ha-vm-2
 STONITH-sap-majoritymaker      (stonith:external/gcpstonith):  Started hana-ha-vm-1w2
 STONITH-hana-ha-vm-2   (stonith:external/gcpstonith):  Started hana-ha-vm-2w1
 STONITH-hana-ha-vm-2w1 (stonith:external/gcpstonith):  Started hana-ha-vm-2w2
 STONITH-hana-ha-vm-2w2 (stonith:external/gcpstonith):  Started sap-majoritymaker
 Clone Set: cln_SAPHanaTopology_HA1_HDB22 [rsc_SAPHanaTopology_HA1_HDB22]
     Started: [ hana-ha-vm-1 hana-ha-vm-1w1 hana-ha-vm-1w2 hana-ha-vm-2 hana-ha-vm-2w1 hana-ha-vm-2w2 ]
     Stopped: [ sap-majoritymaker ]
 Resource Group: g-primary
     rsc_vip_int-primary        (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
     rsc_healthcheck-primary    (ocf::heartbeat:anything):      Started hana-ha-vm-1
 Clone Set: msl_SAPHana_HA1_HDB22 [rsc_SAPHana_HA1_HDB22] (promotable)
     Masters: [ hana-ha-vm-1 ]
     Slaves: [ hana-ha-vm-1w1 hana-ha-vm-1w2 hana-ha-vm-2 hana-ha-vm-2w1 hana-ha-vm-2w2 ]
     Stopped: [ sap-majoritymaker ]

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 crm status pour vérifier que l'hôte principal est désormais actif sur la VM qui contenait l'hôte secondaire. Le redémarrage automatique est activé dans le cluster. Par conséquent, l'hôte arrêté redémarre et prend le rôle d'hôte secondaire, comme illustré dans l'exemple suivant.

   Stack: corosync
   Current DC: hana-ha-vm-2 (version 2.0.1+20190417.13d370ca9-3.9.1-2.0.1+20190417.13d370ca9) - partition with quorum
   Last updated: Fri Jun 12 16:46:07 2020
   Last change: Fri Jun 12 16:46:07 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:external/gcpstonith):  Started hana-ha-vm-2
   STONITH-hana-ha-vm-2   (stonith:external/gcpstonith):  Started hana-ha-vm-1
   STONITH-hana-ha-vm-1w1   (stonith:external/gcpstonith):    Started hana-ha-vm-2w1
   STONITH-hana-ha-vm-1w1   (stonith:external/gcpstonith):    Started hana-ha-vm-mm
   STONITH-hana-ha-vm-mm   (stonith:external/gcpstonith):    Started hana-ha-vm-1w1
   Clone Set: cln_SAPHanaTopology_HA1_HDB22 [rsc_SAPHanaTopology_HA1_HDB22]
       Started: [ hana-ha-vm-1 hana-ha-vm-2 hana-ha-vm-1w1 hana-ha-vm-2w1
       Stopped: [ hana-ha-vm-mm ]]
   Resource Group: g-primary
       rsc_vip_int-primary        (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-2
       rsc_healthcheck-primary        (ocf::heartbeat:anything):      Started hana-ha-vm-2
   Clone Set: msl_SAPHana_HA1_HDB22 [rsc_SAPHana_HA1_HDB22] (promotable)
       Masters: [ hana-ha-vm-2 ]
       Slaves: [ hana-ha-vm-1 hana-ha-vm-1w1 hana-ha-vm-2w1
       Stopped: [ hana-ha-vm-mm ]]

Évaluer votre charge de travail SAP HANA

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

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

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

Dépannage

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

Obtenir de l'aide concernant SAP HANA sur SLES

Si vous avez besoin d'aide pour résoudre un problème lié à des clusters à haute disponibilité pour SAP HANA sur SLES, rassemblez les informations de diagnostic requises et contactez Cloud Customer Care. Pour en savoir plus, consultez la page Informations de diagnostic sur les clusters à haute disponibilité SLES.

Assistance

Pour les problèmes liés à l'infrastructure ou aux services Google Cloud, contactez l'assistance Customer Care. Ses coordonnées sont disponibles sur la page de présentation de l'assistance dans 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

Obtenez davantage d'informations en consultant les ressources suivantes :

Réplication automatique du système SAP HANA avec scaling à la hausse dans un cluster Pacemaker

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.