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 :
Si vous utilisez un DNS interne de VPC, la valeur de la variable
vmDnsSettingdans les métadonnées de votre projet doit êtreGlobalOnlyouZonalPreferredafin de permettre la résolution des noms de nœuds entre zones. La valeur par défaut devmDnsSettingestZonalOnly. Pour en savoir plus, consultez les pages suivantes :Vous disposez d'une solution NFS, telle que la solution Filestore, pour partager les volumes SAP HANA
/hana/sharedet/hanabackupentre 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.
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
- Dans la console Google Cloud, accédez à la page Réseaux VPC.
- Cliquez sur Créer un réseau VPC.
- 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.
- Dans le champ Mode de création du sous-réseau, sélectionnez Custom.
- Dans la section Nouveau sous-réseau, spécifiez les paramètres de configuration de sous-réseau suivants :
- Saisissez un nom pour le sous-réseau.
- Dans le champ Région, sélectionnez la région Compute Engine dans laquelle vous souhaitez créer le sous-réseau.
- 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.
- Cliquez sur OK.
- 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.
- Cliquez sur Créer.
gcloud
- Accédez à Cloud Shell.
- 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_NAMEpar 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 custompour é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. - 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 RANGERemplacez les éléments suivants :
SUBNETWORK_NAME: nom du nouveau sous-réseauNETWORK_NAME: nom du réseau que vous avez créé à l'étape précédenteREGION: région dans laquelle vous souhaitez créer le sous-réseauRANGE: 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.
- Si vous le souhaitez, répétez l'étape précédente et ajoutez des sous-réseaux.
Configurer une passerelle NAT
Si vous avez besoin de créer une ou plusieurs VM sans adresse IP publique, vous devez utiliser la traduction d'adresse réseau (NAT) pour permettre aux VM d'accéder à Internet. Utilisez Cloud NAT, un service géré distribué et défini par logiciel de Google Cloud, qui permet aux VM d'envoyer des paquets sortants vers Internet et de recevoir tous les paquets de réponses entrants établis correspondants. Vous pouvez également configurer une VM distincte en tant que passerelle NAT.
Pour créer une instance Cloud NAT pour votre projet, consultez la page Utiliser Cloud NAT.
Une fois que vous avez configuré Cloud NAT pour votre projet, vos instances de VM peuvent accéder en toute sécurité à Internet sans adresse IP publique.
Ajouter des règles de pare-feu
Par défaut, une règle de pare-feu implicite bloque les connexions entrantes provenant de l'extérieur de votre réseau VPC (Virtual Private Cloud, cloud privé virtuel). Pour autoriser les connexions entrantes, configurez une règle de pare-feu pour votre VM. Une fois qu'une connexion entrante est établie avec une VM, le trafic est autorisé dans les deux sens via cette connexion.
Vous pouvez également créer une règle de pare-feu pour autoriser l'accès externe à des ports spécifiés ou pour limiter l'accès entre plusieurs VM d'un même réseau. Si le type de réseau VPC default est utilisé, d'autres règles par défaut s'appliquent également, telles que la règle default-allow-internal, qui permet la connectivité entre les VM d'un même réseau sur tous les ports.
En fonction de la stratégie informatique applicable à votre environnement, vous devrez peut-être isoler votre hôte de base de données, ou en restreindre la connectivité, en créant des règles de pare-feu.
Selon votre scénario, vous pouvez créer des règles de pare-feu afin d'autoriser l'accès pour ce qui suit :
- Ports SAP par défaut répertoriés dans le tableau listant les ports TCP/IP de tous les produits SAP.
- Connexions à partir de votre ordinateur ou de votre environnement de réseau d'entreprise à votre instance de VM Compute Engine. Si vous ne savez pas quelle adresse IP utiliser, contactez l'administrateur réseau de votre entreprise.
Pour créer une règle de pare-feu, procédez comme suit :
Console
Dans la console Google Cloud, accédez à la page Pare-feu de Compute Engine.
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.
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-tagsDé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.
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.
Ouvrez Cloud Shell ou, si vous avez installé gcloud CLI sur votre poste de travail local, ouvrez un terminal.
Téléchargez dans votre répertoire de travail le modèle de fichier de configuration
template.yamlpour 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
Renommez éventuellement le fichier
template.yamlpour identifier la configuration qu'il définit.Ouvrez le fichier
template.yamldans 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.
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_.Propriété 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écificationtypequi est active par défaut spécifie la version du modèle en tant quelatest. La spécificationtypequi 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
typequi inclut l'horodatage.instanceNameChaî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. instanceTypeChaî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' instanceTypepour l'instance créatrice de majorité estn1-standard-2ou l'équivalent d'au moins 2 cœurs de processeur et de 2 Go de mémoire.zoneChaîne Zone Google Cloud dans laquelle déployer l'instance de VM que vous définissez. Spécifiez des zones différentes de la même région pour les définitions des 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. subnetworkChaî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/network1linuxImageChaî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-sapPour 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.linuxImageProjectChaîne Le projet Google Cloud qui contient l'image que vous allez utiliser. Ce projet peut être votre propre projet ou un projet d'image Google Cloud, tel que 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_bucketChaîne Nom du bucket Google Cloud Storage de votre projet contenant les fichiers d'installation et de révision de SAP HANA que vous avez importés précédemment. Tous les fichiers de révision de mise à niveau du bucket sont appliqués à SAP HANA au cours du processus de déploiement. sap_hana_sidChaî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_numberEntier Numéro d'instance (0 à 99) du système SAP HANA. La valeur par défaut est 0. sap_hana_sidadm_passwordChaîne Mot de passe de l'administrateur du système d'exploitation (OS). Les mots de passe doivent comporter au moins huit caractères et inclure au moins une lettre majuscule, une lettre minuscule et un chiffre. sap_hana_system_passwordChaîne Mot de passe du super-utilisateur de la base de données. Les mots de passe doivent comporter au moins huit caractères et inclure au moins une lettre majuscule, une lettre minuscule et un chiffre. sap_hana_sidadm_uidEntier La valeur par défaut pour l'ID utilisateur SID_LCadmest900afin 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_gidEntier 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_nodesEntier Spécifiez 1ou une valeur supérieure.sap_hana_shared_nfsChaîne Point de montage NFS du volume /hana/shared. Par exemple,10.151.91.122:/hana_shared_nfs.sap_hana_backup_nfsChaîne Point de montage NFS du volume /hanabackup. Exemple :10.216.41.122:/hana_backup_nfsnetworkTagChaîne Tag réseau qui représente votre instance de VM à des fins de routage ou d'établissement/application de règles de pare-feu. Si vous spécifiez publicIP: Noet ne spécifiez pas de tag réseau, veillez à fournir un autre moyen d'accès à Internet.nic_typeChaîne Facultatif, mais recommandé si disponible pour la machine cible et la version de l'OS. Spécifie l'interface réseau à utiliser avec l'instance de VM. Vous pouvez spécifier la valeur GVNICouVIRTIO_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é
Cet argument est disponible dans les versionsinstanceType.202302060649du modèle Deployment Manager ou ultérieures.publicIPBooléen Facultatif. Détermine si une adresse IP publique est ajoutée à votre instance de VM. La valeur par défaut est Yes.serviceAccountChaîne Facultatif. Spécifie un compte de service destiné à être utilisé par les VM hôtes et par les programmes exécutés sur celles-ci. Spécifiez l'adresse e-mail du compte de service. Par exemple, svc-acct-name@project-id.iam.gserviceaccount.com. Par défaut, le compte de service Compute Engine par défaut est utilisé. Pour en savoir plus, consultez la page Gestion de l'authentification et des accès pour les programmes SAP sur Google Cloud. 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.
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 :
nameinstanceNamezone
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
Copiez et collez la spécification YAML à partir du fichier
sap_majoritymaker.yaml, en partant de la ligne 6 jusqu'au bas du fichiertemplate.yamlSAP HANA.Terminez la définition de l'instance créatrice de majorité :
- Spécifiez une
zonedifférente des deux systèmes SAP HANA. - La valeur minimale recommandée d'
instanceTypeestn1-standard-2ou 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.
- Spécifiez une
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: limited-roles@example-project-123456.iam.gserviceaccount.com
# sap_hana_sidadm_uid: 900
# sap_hana_sapsys_gid: 79
- name: sap_hana_secondary
type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.py
#
# By default, this configuration file uses the latest release of the deployment
# scripts for SAP on Google Cloud. To fix your deployments to a specific release
# of the scripts, comment out the type property above and uncomment the type property below.
#
# type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/yyyymmddhhmm/dm-templates/sap_hana/sap_hana.py
#
properties:
instanceName: hana-ha-vm-2
instanceType: n2-highmem-32
zone: us-central1-c
subnetwork: example-subnet-us-central1
linuxImage: family/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: limited-roles@example-project-123456.iam.gserviceaccount.com
# 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.
Dans la console Google Cloud, ouvrez Cloud Logging pour surveiller la progression de l'installation et rechercher les erreurs.
Filtrez les journaux :
Explorateur de journaux
Sur la page Explorateur de journaux, accédez au volet Requête.
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"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.
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 :
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.
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é.
Réexécutez le déploiement.
- Si
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
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.
Connectez-vous en tant qu'utilisateur racine.
$sudo su -À l'invite de commande, saisissez
df -h. Sur chaque VM, assurez-vous que les répertoires/hanas'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
Connectez-vous en tant qu'administrateur SAP en remplaçant
SID_LCdans 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_LCadmAssurez-vous que les services SAP HANA, tels que
hdbnameserver,hdbindexserveret autres services, s'exécutent sur l'instance en saisissant la commande suivante :>HDB infoSi vous utilisez RHEL pour SAP 9.0 ou une version ultérieure, assurez-vous que les packages
chkconfigetcompat-openssl11sont 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 :
Établissez une connexion SSH avec votre instance de VM hôte.
Exécutez la commande suivante :
systemctl status google-cloud-sap-agent
Si l'agent fonctionne correctement, la sortie contient
active (running). Exemple :google-cloud-sap-agent.service - Google Cloud Agent for SAP Loaded: loaded (/usr/lib/systemd/system/google-cloud-sap-agent.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2022-12-02 07:21:42 UTC; 4 days ago Main PID: 1337673 (google-cloud-sa) Tasks: 9 (limit: 100427) Memory: 22.4 M (max: 1.0G limit: 1.0G) CGroup: /system.slice/google-cloud-sap-agent.service └─1337673 /usr/bin/google-cloud-sap-agent
Si l'agent n'est pas en cours d'exécution, redémarrez-le.
Vérifier que l'agent hôte SAP reçoit les métriques
Pour vérifier que les métriques d'infrastructure sont collectées par l'agent Google Cloud pour SAP et envoyées correctement à l'agent hôte SAP, procédez comme suit :
- Dans votre système SAP, saisissez la transaction
ST06. 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
- Fournisseur cloud :
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
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
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
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 :
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.txtAttribuez 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.
Sur chaque hôte, en tant que SID_LCadm, arrêtez SAP HANA :
>HDB stopSur 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
Définissez la propriété
Autostartsur0:Autostart=0
Enregistrez le profil.
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
Activer le redémarrage rapide de SAP HANA
Google Cloud recommande fortement d'activer le redémarrage rapide SAP HANA pour chaque instance de SAP HANA, en particulier pour les instances de grande capacité. Le redémarrage rapide de SAP HANA réduit le temps de redémarrage en cas d'arrêt de SAP HANA, mais le système d'exploitation reste en cours d'exécution.
Comme configuré par les scripts d'automatisation fournis par Google Cloud, les paramètres du système d'exploitation et du noyau sont déjà compatibles avec le redémarrage rapide de SAP HANA.
Vous devez définir le système de fichiers tmpfs et configurer SAP HANA.
Pour définir le système de fichiers tmpfs et configurer SAP HANA, vous pouvez suivre les étapes manuelles ou utiliser le script d'automatisation fourni par Google Cloud pour activer le redémarrage rapide de SAP HANA. Pour en savoir plus, consultez les pages suivantes :
- É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*/SIDInstaller les répertoires de nœuds NUMA dans tmpfs
Montez les répertoires du système de fichiers tmpfs et spécifiez une préférence de nœud NUMA pour chacun avec mpol=prefer :
SID : spécifiez le SID en majuscules.
mount tmpfsSID0 -t tmpfs -o mpol=prefer:0 /hana/tmpfs0/SID mount tmpfsSID1 -t tmpfs -o mpol=prefer:1 /hana/tmpfs1/SID mount tmpfsSID2 -t tmpfs -o mpol=prefer:2 /hana/tmpfs2/SID mount tmpfsSID3 -t tmpfs -o mpol=prefer:3 /hana/tmpfs3/SID
Mettre à jour /etc/fstab
Pour vous assurer que les points d'installation sont disponibles après un redémarrage du système d'exploitation, ajoutez des entrées dans la table du système de fichiers, /etc/fstab :
tmpfsSID0 /hana/tmpfs0/SID tmpfs rw,relatime,mpol=prefer:0 tmpfsSID1 /hana/tmpfs1/SID tmpfs rw,relatime,mpol=prefer:1 tmpfsSID1 /hana/tmpfs2/SID tmpfs rw,relatime,mpol=prefer:2 tmpfsSID1 /hana/tmpfs3/SID tmpfs rw,relatime,mpol=prefer:3
Facultatif : définir des limites à l'utilisation de la mémoire
Le système de fichiers tmpfs peut augmenter ou diminuer de manière dynamique.
Pour limiter la mémoire utilisée par le système de fichiers tmpfs, vous pouvez définir une limite de taille pour un volume de nœuds NUMA en utilisant l'option size.
Exemple :
mount tmpfsSID0 -t tmpfs -o mpol=prefer:0,size=250G /hana/tmpfs0/SID
Vous pouvez également limiter l'utilisation globale de la mémoire tmpfs pour tous les nœuds NUMA d'une instance SAP HANA donnée et d'un nœud de serveur donné en définissant le paramètre persistent_memory_global_allocation_limit dans la section [memorymanager] du fichier global.ini.
Configuration de SAP HANA pour le redémarrage rapide
Pour configurer SAP HANA pour le redémarrage rapide, mettez à jour le fichier global.ini et spécifiez les tables à stocker dans la mémoire persistante.
Mettre à jour la section [persistence] du fichier global.ini
Configurez la section [persistence] du fichier SAP HANA global.ini de manière à référencer les emplacements tmpfs. Séparez chaque emplacement tmpfs par un point-virgule :
[persistence] basepath_datavolumes = /hana/data basepath_logvolumes = /hana/log basepath_persistent_memory_volumes = /hana/tmpfs0/SID;/hana/tmpfs1/SID;/hana/tmpfs2/SID;/hana/tmpfs3/SID
L'exemple précédent spécifie quatre volumes de mémoire pour quatre nœuds NUMA, ce qui correspond à m2-ultramem-208. Si vous l'exécutez sur m2-ultramem-416, vous devez configurer huit volumes de mémoire (de 0 à 7).
Redémarrez SAP HANA après avoir modifié le fichier global.ini.
SAP HANA peut désormais utiliser l'emplacement tmpfs comme espace de mémoire persistant.
Spécifier les tables à stocker en mémoire persistante
Spécifiez des tables ou partitions de colonne spécifiques à stocker en mémoire persistante.
Par exemple, pour activer la mémoire persistante pour une table existante, exécutez la requête SQL :
ALTER TABLE exampletable persistent memory ON immediate CASCADE
Pour modifier la valeur par défaut des nouvelles tables, ajoutez le paramètre table_default dans le fichier indexserver.ini. Exemple :
[persistent_memory] table_default = ON
Pour en savoir plus sur le contrôle des colonnes et des tables ainsi que sur les vues de surveillance qui fournissent des informations détaillées, consultez la page Mémoire persistante SAP HANA.
Étapes automatisées
Le script d'automatisation fourni par Google Cloud pour activer le redémarrage rapide de SAP HANA apporte des modifications aux répertoires /hana/tmpfs*, au fichier /etc/fstab et à la configuration de SAP HANA. Lorsque vous exécuterez le script, vous devrez peut-être effectuer des étapes supplémentaires selon qu'il s'agit du déploiement initial de votre système SAP HANA ou que vous redimensionnez votre machine sur une autre taille NUMA.
Pour le déploiement initial de votre système SAP HANA ou le redimensionnement de la machine pour augmenter le nombre de nœuds NUMA, assurez-vous que SAP HANA est en cours d'exécution pendant l'exécution du script d'automatisation fourni par Google Cloud pour activer le redémarrage rapide de SAP HANA.
Lorsque vous redimensionnez votre machine pour réduire le nombre de nœuds NUMA, assurez-vous que SAP HANA est arrêté pendant l'exécution du script d'automatisation fourni par Google Cloud pour permettre le redémarrage rapide de SAP HANA. Une fois le script exécuté, vous devez mettre à jour manuellement la configuration SAP HANA pour terminer la configuration du redémarrage rapide de SAP HANA. Pour en savoir plus, consultez la section Configuration de SAP HANA pour le redémarrage rapide.
Pour activer le redémarrage rapide de SAP HANA, procédez comme suit :
Établissez une connexion SSH avec votre VM hôte.
Passez en mode root :
sudo su -
Téléchargez le script
sap_lib_hdbfr.sh:wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/lib/sap_lib_hdbfr.sh
Rendez le fichier exécutable :
chmod +x sap_lib_hdbfr.sh
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.
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é :
Désinstallez les agents de ressources HANA à scaling vertical :
zypper remove SAPHanaSR SAPHanaSR-doc
Installez les agents de ressources à scaling horizontal HANA :
zypper in SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc
Installez
socat:zypper install socat
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 :
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
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)
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.
Sur l'hôte principal, en tant que
SID_LCadm, activez la réplication du système :>hdbnsutil -sr_enable --name=PRIMARY_HOST_NAMESur l'hôte secondaire :
En tant que
SID_LCadm, arrêtez SAP HANA :>sapcontrol -nr INST_NUM -function StopSystemEn 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-ARCCopiez 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.DATCopiez 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.KEYMettez à 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.KEYMettez à 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.KEYEn 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_NAMEEn 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.pySi la réplication est correctement configurée, entre autres indicateurs, les valeurs suivantes s'affichent pour les services xsengine, nameserver et indexserver :
Secondary Active Statusest défini surYES.Replication Statusest défini surACTIVE.
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.
Sur le site principal et le site secondaire, procédez comme suit :
En tant que
SID_LCadm, arrêtez SAP HANA :>sapcontrol -nr 00 -function StopSystem
En tant qu'utilisateur racine ou
SID_LCadm, ouvrez le fichierglobal.inipour le modifier :>vi /hana/shared/SID/global/hdb/custom/config/global.iniAjoutez 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
En tant qu'utilisateur racine, créez un fichier de configuration personnalisé dans le répertoire
/etc/sudoers.den exécutant la commande suivante. Ce nouveau fichier de configuration permet à l'utilisateurSID_LCadmd'accéder aux attributs de nœud du cluster lorsque la méthode de hooksrConnectionChanged()est appelée.>sudo visudo -f /etc/sudoers.d/SAPHanaSRDans le fichier
/etc/sudoers.d/SAPHanaSR, ajoutez le texte suivant :Remplacez
SID_LCpar 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 *
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.
En tant que
SID_LCadm, démarrez SAP HANA :>sapcontrol -nr 00 -function StartSystemUne 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 passthrough interne avec prise en charge du basculement achemine le trafic vers l'hôte actif dans un cluster SAP HANA en fonction d'un service de vérification de l'état.
Réserver une adresse IP pour l'adresse IP virtuelle
L'adresse IP virtuelle, parfois appelée adresse IP flottante, suit le système SAP HANA actif. L'équilibreur de charge achemine le trafic envoyé à l'adresse IP virtuelle vers la VM qui héberge actuellement le système SAP HANA actif.
Ouvrez Cloud Shell.
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_ADDRESSPour en savoir plus sur la réservation d'une adresse IP statique, consultez la page Réserver une adresse IP interne statique.
Confirmez la réservation d'adresse IP :
$gcloud compute addresses describe VIP_NAME \ --region CLUSTER_REGIONUn 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
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_NAMEConfirmez la création des groupes d'instances :
$gcloud compute instance-groups unmanaged listUn 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
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=2Confirmez la création de la vérification de l'état :
$gcloud compute health-checks describe HEALTH_CHECK_NAMEUn 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.
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_ZONESi 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_NUMExemple :
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
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-checksAjoutez 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_REGIONAjoutez 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_REGIONCré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-accessdans 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 ALLPour en savoir plus sur l'accès interrégional à votre système SAP HANA à haute disponibilité, consultez la page Équilibrage de charge TCP/UDP interne.
Tester la configuration de l'équilibreur de charge
Même si vos groupes d'instances backend ne seront considérés comme opérationnels que plus tard, vous pouvez tester la configuration de l'équilibreur de charge en configurant un écouteur pour répondre aux vérifications d'état. Une fois un écouteur configuré, si l'équilibreur de charge est correctement configuré, les groupes d'instances backend deviennent opérationnels.
Les sections suivantes présentent différentes méthodes que vous pouvez utiliser pour tester la configuration.
Tester l'équilibreur de charge avec l'utilitaire socat
Vous pouvez vous servir de l'utilitaire socat pour écouter temporairement le port de vérification de l'état. Vous devez tout de même installer l'utilitaire socat, car vous l'utiliserez plus tard lors de la configuration des ressources du cluster.
Installez l'utilitaire
socatsur les VM hôtes principales et secondaires en tant qu'utilisateur racine :#zypper install -y socatDémarrez un processus
socatpour écouter le port de vérification de l'état pendant 60 secondes :#timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,forkDans 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_REGIONLe 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 :
Cliquez sur votre vérification de l'état dans la console :
Cliquez sur Modifier.
Dans le champ Port, remplacez le numéro de port par 22.
Cliquez sur Enregistrer, puis patientez une minute ou deux.
Dans Cloud Shell, vérifiez l'état de vos groupes d'instances backend :
$gcloud compute backend-services get-health BACKEND_SERVICE_NAME \ --region CLUSTER_REGIONLe 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
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.
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
Ouvrez le fichier
/etc/corosync/corosync.confà l'aide de l'éditeur de votre choix.Supprimez le paramètre
consensus.Modifiez les paramètres restants en suivant les recommandations de Google Cloud.
Le tableau suivant présente les paramètrestotempour lesquels Google Cloud recommande des valeurs, ainsi que l'impact de la modification de ces valeurs. Pour connaître les valeurs par défaut de ces paramètres, qui peuvent différer entre les distributions Linux, consultez la documentation de votre distribution Linux.Paramètre Valeur recommandée Impact de la modification de la valeur secauthoffDésactive l'authentification et le chiffrement de tous les messages totem.join60 (ms) Augmente la durée pendant laquelle le nœud attend des messages joindans le protocole de souscription.max_messages20 Augmente le nombre maximal de messages pouvant être envoyés par le nœud après réception du jeton. token20 000 (ms) Augmente la durée pendant laquelle le nœud attend un jeton de protocole
totemavant 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
tokenrend 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
tokendétermine également la valeur par défaut du paramètreconsensus, 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.consensusN/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
Si vous spécifiez explicitement une valeur pour le paramètreconsensusn'est pas spécifié, Corosync définit sa valeur sur 1,2 fois la valeur du paramètretoken. Si vous appliquez la valeur recommandée du paramètretokende20000, le paramètreconsesusest défini avec la valeur24000.consensus, assurez-vous que cette valeur est24000ou1.2*token, selon la valeur la plus élevée.token_retransmits_before_loss_const10 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. - Pour SLES :
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 -sLa 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 :
Exécutez la commande suivante après avoir remplacé
PRIMARY_HOST_NAMEpar le nom d'hôte d'un nœud du cluster principal :#crm configure primitive STONITH-"PRIMARY_HOST_NAME" stonith:fence_gce \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s" \ params port="PRIMARY_HOST_NAME" zone="PRIMARY_ZONE" project="PROJECT_ID" \ pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30Répétez l'étape précédente pour tous les autres nœuds du cluster principal.
Exécutez la commande suivante après avoir remplacé
SECONDARY_HOST_NAMEpar le nom d'hôte d'un nœud du cluster secondaire.#crm configure primitive STONITH-"SECONDARY_HOST_NAME" stonith:fence_gce \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s" \ params port="SECONDARY_HOST_NAME" zone="SECONDARY_ZONE" project="PROJECT_ID" \ pcmk_reboot_timeout=300 pcmk_monitor_retries=4Répétez l'étape précédente pour tous les autres nœuds du cluster secondaire.
Exécutez la commande suivante après avoir remplacé
MAJORITY_MAKER_HOSTNAMEpar le nom d'hôte de l'instance majoritaire :#crm configure primitive STONITH-"MAJORITY_MAKER_HOSTNAME" stonith:fence_gce \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s" \ params port="MAJORITY_MAKER_HOSTNAME" zone="MAJORITY_MAKER_ZONE" project="PROJECT_ID" \ pcmk_reboot_timeout=300 pcmk_monitor_retries=4Définissez l'emplacement de l'appareil de cloisonnement :
#crm configure location LOC_STONITH_"PRIMARY_HOST_NAME" \ STONITH-"PRIMARY_HOST_NAME" -inf: "PRIMARY_HOST_NAME"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é.
Définir un délai pour le redémarrage de Corosync
Étapes manuelles
Sur tous les hôtes, en tant qu'utilisateur racine, créez un fichier de dépôt
systemdqui 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
Ajoutez les lignes suivantes au fichier :
[Service] ExecStartPre=/bin/sleep 60
Enregistrez le fichier et quittez l'éditeur.
Rechargez la configuration du gestionnaire systemd.
systemctl daemon-reload
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=60sConfigurer 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.
Sur les deux hôtes en mode root, installez
socat utility:#zypper in -y socatSur 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
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 :
Créez un fichier de configuration temporaire pour les paramètres de configuration SAPHanaTopology :
#vi /tmp/cluster.tmpEffectuez 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
Modifiez le fichier
/tmp/cluster.tmppour remplacer les variables par le SID et le numéro d'instance de votre système SAP HANA.Sur l'hôte principal, en mode root, chargez le contenu du fichier
/tmp/cluster.tmpdans 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.
Remplacez le fichier de configuration temporaire :
#rm /tmp/cluster.tmp#vi /tmp/cluster.tmpEffectuez 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_REGISTERsurfalse. 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éfinirAUTOMATED_REGISTERsurtruepour les configurations SAP HANA qui utilisent la réplication système à plusieurs niveaux. Pour en savoir plus, consultez les pages suivantes :Sur l'hôte principal, en mode root, chargez le contenu du fichier
/tmp/cluster.tmpdans 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.pyActiver le cluster
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.Patientez 15 secondes, puis vérifiez l'état du cluster sur l'hôte principal en tant qu'utilisateur racine :
#crm statusLes 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:fence_gce): Started hana-ha-vm-1w2
STONITH-hana-ha-vm-1w1 (stonith:fence_gce): Started hana-ha-vm-1
STONITH-hana-ha-vm-1w2 (stonith:fence_gce): Started hana-ha-vm-2
STONITH-sap-majoritymaker (stonith:fence_gce): Started hana-ha-vm-1w2
STONITH-hana-ha-vm-2 (stonith:fence_gce): Started hana-ha-vm-2w1
STONITH-hana-ha-vm-2w1 (stonith:fence_gce): Started hana-ha-vm-2w2
STONITH-hana-ha-vm-2w2 (stonith:fence_gce): 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 stopHDB killreboot(sur le nœud actif)ip link set eth0 downpour les instances avec une seule interface réseauiptables ... DROPpour les instances avec plusieurs interfaces réseauecho 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.
Sur l'hôte actif, en tant qu'utilisateur racine, déconnectez l'interface réseau :
#ip link set eth0 downOu, si plusieurs interfaces réseau sont actives, à l'aide de
iptablessur l'hôte secondaire :#iptables -A INPUT -s PRIMARY_CLUSTER_IP -j DROP; iptables -A OUTPUT -d PRIMARY_CLUSTER_IP -j DROPReconnectez-vous à l'un des hôtes à l'aide de SSH, puis connectez-vous en tant qu'utilisateur racine.
Saisissez
crm statuspour 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:fence_gce): Started hana-ha-vm-2 STONITH-hana-ha-vm-2 (stonith:fence_gce): Started hana-ha-vm-1 STONITH-hana-ha-vm-1w1 (stonith:fence_gce): Started hana-ha-vm-2w1 STONITH-hana-ha-vm-1w1 (stonith:fence_gce): Started hana-ha-vm-mm STONITH-hana-ha-vm-mm (stonith:fence_gce): Started hana-ha-vm-1w1 Clone Set: 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 :
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.
Avant d'utiliser votre instance SAP HANA, configurez et sauvegardez votre nouvelle base de données SAP HANA.
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_bytesest définie sur1048576. Cette modification permet d'améliorer le débit réseau global sur l'interface réseau VirtIO sans affecter la latence du réseau.
Pour en savoir plus, consultez les pages suivantes :
Étapes suivantes
Obtenez davantage d'informations en consultant les ressources suivantes :