Cette page a été traduite par l'API Cloud Translation.

Guide de configuration d'un cluster à haute disponibilité pour SAP MaxDB sur RHEL

Ce guide explique comment déployer un système SAP MaxDB dans un cluster haute disponibilité Red Hat Enterprise Linux (RHEL) sur Google Cloud, avec une configuration de cluster actif/passif.

Pour déployer un système SAP MaxDB à nœud unique sous Linux, consultez le guide de déploiement de SAP MaxDB.

Ce guide est destiné aux utilisateurs avancés de SAP MaxDB qui connaissent bien les configurations Linux HA pour les systèmes SAP.

Système déployé dans ce guide

Ce guide comprend les étapes suivantes :

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

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

Deux VM Compute Engine dans différentes zones, capables d'exécuter une instance de SAP MaxDB
Un disque persistant régional pour l'installation de SAP MaxDB.
Le gestionnaire de ressources de cluster à haute disponibilité Pacemaker
Un mécanisme de cloisonnement STONITH

Ce guide ne traite pas de l'installation à haute disponibilité de SAP NetWeaver.

Prérequis

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

Vous avez lu le guide de planification de SAP MaxDB.
Vous disposez d'un abonnement Red Hat.
Vous ou votre organisation disposez d'un compte Google Cloud et vous avez créé un projet pour le déploiement de SAP MaxDB.
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.
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

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 Cloudpour 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.
Accéder aux 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 :
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.
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.
Accéder à 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_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.
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.
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.

Accéder à la page "Pare-feu"
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 sur Google Cloudauxquelles 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 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-tags

Déployer les VM et installer MaxDB

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

Créer une VM pour le déploiement de MaxDB

Dans le cadre du déploiement de la haute disponibilité, deux Google Cloud VM Compute Engine doivent être créées. Pour en savoir plus, consultez le guide Créer et démarrer une instance Compute Engine.

Notez que les disques persistants régionaux ne sont compatibles qu'avec les types de machines E2, N1, N2 et N2D. Pour en savoir plus, consultez le guide sur les disques persistants régionaux.

Consultez la note SAP 2456432 - Applications SAP sur Google Cloud: produits compatibles et types de machines Google Cloud pour sélectionner le type de machine approprié en fonction de votre dimensionnement.

Créez les deux VM dans des zones distinctes pour obtenir une résilience zonale, avec les conditions minimales requises suivantes:

Détails de la VM:
- Instance Name
- Zone : zone préférée
- Machine Type : basé sur le dimensionnement
- Subnet : nom du sous-réseau créé pour cette région
Compte de service disposant au moins d'niveau d'accès aux API suivantes:
- https://www.googleapis.com/auth/compute
- https://www.googleapis.com/auth/servicecontrol
- https://www.googleapis.com/auth/service.management.readonly
- https://www.googleapis.com/auth/logging.write
- https://www.googleapis.com/auth/monitoring.write
- https://www.googleapis.com/auth/trace.append
- https://www.googleapis.com/auth/devstorage.read_write
Disque supplémentaire de 20 Go minimum sur chaque VM à utiliser pour /usr/sap

Créer un seul disque régional pour SAP MaxDB

Pour ce déploiement, un disque régional sera utilisé pour stocker les fichiers MaxDB dans le répertoire /sapdb.

Créez le disque, en vous assurant que les zones de réplication du disque régional correspondent aux zones dans lesquelles vous avez créé les deux VM.

Associez le disque régional à l'une des VM sur lesquelles vous allez effectuer l'installation et les tâches de configuration de MaxDB.

Préparer l'OS RHEL pour l'installation de SAP

Le produit SAP nécessite l'installation de paramètres et de packages spécifiques du système d'exploitation. Suivez les instructions de la note SAP 2772999 – Red Hat Enterprise Linux 8.x : installation et configuration .

Cette tâche doit être effectuée sur les deux nœuds.

Créer des systèmes de fichiers

Connectez-vous aux deux instances via SSH et créez les points d'installation /usr/sap/SID et /sapdb.
```
# sudo mkdir -p /usr/sap/SID
# sudo mkdir -p /sapdb
```
Créez les systèmes de fichiers sur les deux disques supplémentaires associés aux VM à l'aide de mkfs.

Notez qu'à ce stade, le disque régional ne sera associé qu'à l'une des VM. Par conséquent, la création du système de fichiers /sapdb ne sera effectuée qu'une seule fois.
Modifiez le fichier /etc/fstab pour que /usr/sap/SID soit toujours installé au redémarrage sur les deux nœuds.
Installez manuellement le système de fichiers /sapdb dans le nœud où vous effectuerez l'installation de MaxDB.

Pour en savoir plus sur la création et l'installation des systèmes de fichiers, consultez le guide Formater et installer un disque non amorçable sur une VM Linux.

Modifier la configuration LVM

Vous devez modifier la configuration de la gestion des volumes logiques (LVM) afin que le groupe de volumes partagé (VG) ne soit toujours connecté et accessible que par un seul nœud.

Pour ce faire, procédez comme suit sur les deux nœuds:

En tant qu'utilisateur racine, modifiez le fichier /etc/lvm/lvm.conf et remplacez la valeur system_id_source par uname à partir de none.

Vérifiez les résultats :

# grep -i system_id_source /etc/lvm/lvm.conf

Le résultat doit se présenter comme suit:

# Configuration option global/system_id_source.
        system_id_source = "uname"

Pour empêcher les VM d'activer les VG gérés par le cluster lorsqu'un nœud redémarre, conservez le paramètre suivant dans le fichier de configuration /etc/lvm/lvm.conf avec les noms complets des VG séparés par une virgule qui ne sont pas gérés par le cluster.

Remarque :Par défaut, aucune valeur n'est conservée dans ce fichier. Vous devez donc accéder à la section décrivant l'utilisation du paramètre auto_activation_volume_list et l'ajouter manuellement.

Par exemple, lorsque usrsap est un nom de VG qui n'est pas géré par le cluster:
```
auto_activation_volume_list = [ usrsap ]
```
Par exemple, si aucun VG n'est géré par le cluster, ce paramètre doit être ajouté avec des valeurs vides:
```
auto_activation_volume_list = [  ]
```

Installer la base de données et l'agent hôte SAP

Une fois votre système d'exploitation configuré, vous pouvez installer votre base de données SAP MaxDB et l'agent hôte SAP. Le système MaxDB est généralement installé avec le produit SAP auquel il est intégré.

Notez que l'installation ne sera effectuée qu'une seule fois, dans l'instance à laquelle vous avez associé le disque persistant régional.

Pour installer le système SAP MaxDB sur votre VM, procédez comme suit :

Établissez une connexion SSH avec votre VM basée sur Linux.
Téléchargez le Software Provisioning Manager (SWPM) de SAP, le support d'installation du produit SAP et le support d'installation de MaxDB en suivant les guides d'installation de SAP.
Installez le produit SAP et la base de données SAP MaxDB en suivant les guides d'installation de SAP pour votre produit SAP. Pour obtenir des conseils supplémentaires, reportez-vous à la documentation SAP MaxDB.

Le produit SAP fournit des informations supplémentaires concernant l'installation sur la page Note SAP 1020175 – Questions fréquentes sur l'installation, la mise à jour ou l'application d'un correctif pour SAP MaxDB (en anglais).

Une fois l'installation terminée, exécutez les validations suivantes:

En tant qu'utilisateur sidadm, vérifiez l'état de MaxDB.
```
# dbmcli -d  SID -u control,password db_state
```
Un résultat semblable aux lignes suivantes doit s'afficher :
```
>dbmcli -d  MDB -u control, my_p4$$w0rd db_state
OK
State
ONLINE
```

Vérifiez également l'état de x_server:

# x_server

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

>x_server
2024-10-23 19:01:43 11968 19744 INF  12916          Found running XServer on port 7200
2024-10-23 19:01:43 11968 19744 INF  13011            version 'U64/LIX86 7.9.10   Build 004-123-265-969'
2024-10-23 19:01:43 11968 19744 INF  13010            installation MDB  - path: /sapdb/MDB/db
2024-10-23 19:01:45 11971 13344 INF  12916          Found running sdbgloballistener on port 7210
2024-10-23 19:01:45 11971 13344 INF  13011            version 'U64/LIX86 7.9.10   Build 004-123-265-969'

Vérifiez si l'agent hôte SAP est en cours d'exécution:

# ps -ef | grep -i hostctrl

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

>ps -ef | grep -i hostctrl
root      1543     1  0 Oct18 ?        00:00:15 /usr/sap/hostctrl/exe/saphostexec pf=/usr/sap/hostctrl/exe/host_profile
sapadm    1550     1  0 Oct18 ?        00:03:00 /usr/sap/hostctrl/exe/sapstartsrv pf=/usr/sap/hostctrl/exe/host_profile -D
root      1618     1  0 Oct18 ?        00:03:48 /usr/sap/hostctrl/exe/saposcol -l -w60 pf=/usr/sap/hostctrl/exe/host_profile
mdbadm   12751 11261  0 19:03 pts/0    00:00:00 grep --color=auto -i hostctrl

Une fois l'installation validée, arrêtez l'instance MaxDB et x_server.

# dbmcli -d SID -u control, and password db_offline
# x_server stop

Effectuer les tâches post-installation

Avant d'utiliser votre instance SAP MaxDB, nous vous recommandons d'effectuer les étapes de post-déploiement suivantes :

Mettez à jour votre logiciel SAP MaxDB avec la dernière version des correctifs, si disponible.
Installez tous les composants supplémentaires.
Configurez et sauvegardez votre nouvelle base de données SAP MaxDB.

Pour en savoir plus, reportez-vous à la page Administration des bases de données SAP MaxDB (en anglais).

Une fois les systèmes SAP MaxDB déployés, définissez et configurez le cluster à haute disponibilité.

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 MaxDB en fonction d'un service de vérification de l'état'état.

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

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

Ouvrez Cloud Shell.

Accéder à 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 MaxDB. 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.

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: '2024-10-23T14:19:03.109-07:00'
description: ''
id: '8961491304398200872'
kind: compute#address
name: vip-for-maxdb-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-maxdb-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 principale à l'un et la VM hôte 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

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
maxdb-ha-ig-1  us-central1-a  example-network  example-project-123456 No       1
maxdb-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=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: '2023-10-23T21:03:06.924-07:00'
healthyThreshold: 2
id: '4963070308818371477'
kind: compute#healthCheck
name: maxdb-health-check
selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/maxdb-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_ZONE

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

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

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

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

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

Sur les deux VM hôtes, installez l'utilitaire socat :
```
$ sudo yum install -y socat
```
Démarrez un processus socat pour écouter le port de vérification de l'état pendant 60 secondes :
```
$ sudo timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,fork
```

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/maxdb-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/maxdb-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/maxdb-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/maxdb-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 :

Accéder à la page "Vérifications d'état"
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_REGION

Le résultat doit être semblable à ceci :

---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/maxdb-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/maxdb-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/maxdb-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/maxdb-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 la mise en œuvre Red Hat d'un cluster Pacemaker sur les VM Compute Engine pour SAP MaxDB.

Elle repose sur la documentation Red Hat pour la configuration des clusters à haute disponibilité, y compris:

Installer et configurer un cluster à haute disponibilité Red Hat Enterprise Linux 7.6 (et versions ultérieures) sur Google Cloud

Installer les agents de cluster sur les deux nœuds

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

En tant qu'utilisateur racine, installez les composants Pacemaker :
```
# yum -y install pcs pacemaker fence-agents-gce resource-agents-gcp resource-agents-sap-hana
# yum update -y
```
Si vous utilisez une image RHEL pour SAP fournie par Google, ces packages sont déjà installés, mais certaines mises à jour peuvent être nécessaires.
Définissez le mot de passe de l'utilisateur hacluster, qui est installé dans le cadre des packages :
```
# passwd hacluster
```
Lorsque vous y êtes invité, spécifiez un mot de passe pour hacluster.
Dans les images RHEL fournies par Google Cloud, le service de pare-feu du système d'exploitation est actif par défaut. Configurez le service de pare-feu pour autoriser le trafic à haute disponibilité :
```
# firewall-cmd --permanent --add-service=high-availability
```
```
# firewall-cmd --reload
```
Démarrez le service PCS et configurez-le pour qu'il se lance au démarrage :
```
# systemctl start pcsd.service
# systemctl enable pcsd.service
```

Vérifiez l'état du service PCS :

# systemctl status pcsd.service

La sortie obtenue doit ressembler à ceci :

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

Assurez-vous que tous les services de haute disponibilité requis sont activés et opérationnels sur les deux nœuds.
```
# systemctl enable pcsd.service pacemaker.service corosync.service
```

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

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

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

Créer le cluster

En tant qu'utilisateur racine, sur l'un ou l'autre des nœuds, autorisez l'utilisateur hacluster. Cliquez sur l'onglet de votre version de RHEL pour afficher la commande suivante :
RHEL 8 et versions ultérieures
```
# pcs host auth primary-host-name secondary-host-name
```
RHEL 7
```
# pcs cluster auth primary-host-name secondary-host-name
```
Lorsque vous y êtes invité, saisissez le nom d'utilisateur hacluster et le mot de passe que vous avez défini pour l'utilisateur hacluster.

Créez le cluster :

RHEL 8 et versions ultérieures

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

RHEL 7

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

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

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

Sur l'un ou l'autre des hôtes, utilisez l'éditeur de texte de votre choix pour ouvrir le fichier /etc/corosync/corosync.conf afin de le modifier :
```
# /etc/corosync/corosync.conf
```
Si /etc/corosync/corosync.conf est un nouveau fichier ou est vide, vous pouvez consulter le répertoire /etc/corosync/ pour obtenir un exemple de fichier à utiliser comme base pour le fichier Corosync.
Dans la section totem du fichier corosync.conf, ajoutez les propriétés suivantes avec les valeurs suggérées pour votre version de RHEL :
RHEL 8 et versions ultérieures
- transport: knet
- token: 20000
- token_retransmits_before_loss_const: 10
- join: 60
- max_messages: 20
Exemple :
```
totem {
version: 2
cluster_name: hacluster
secauth: off
transport: knet
token: 20000
token_retransmits_before_loss_const: 10
join: 60
max_messages: 20
}
...
```
RHEL 7
- transport: udpu
- token: 20000
- token_retransmits_before_loss_const: 10
- join: 60
- max_messages: 20
Exemple :
```
totem {
version: 2
cluster_name: hacluster
secauth: off
transport: udpu
token: 20000
token_retransmits_before_loss_const: 10
join: 60
max_messages: 20
}
...
```
Depuis l'hôte qui contient le fichier corosync.conf modifié, synchronisez la configuration Corosync dans l'ensemble du cluster :
RHEL 8 et versions ultérieures
```
# pcs cluster sync corosync
```
RHEL 7
```
# pcs cluster sync
```
Configurez le cluster pour qu'il démarre automatiquement :
```
# pcs cluster enable --all
```
```
# pcs cluster start --all
```
Vérifiez que les nouveaux paramètres Corosync sont actifs dans le cluster à l'aide de l'utilitaire corosync-cmapctl :
```
# corosync-cmapctl
```

Configurer le cloisonnement

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

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

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

Créer les ressources de l'appareil de cloisonnement

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

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

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

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

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

Sur l'hôte principal, en tant qu'utilisateur racine, testez l'appareil de cloisonnement secondaire :
1. Arrêtez la VM hôte secondaire :
```
# fence_gce -o off -n secondary-host-name --zone=secondary-host-zone
```
  Si la commande aboutit, vous perdez la connectivité à la VM hôte secondaire, qui apparaît comme arrêtée sur la page Instances de VM de la console Google Cloud . Vous devrez peut-être actualiser la page.
2. Redémarrez la VM hôte secondaire :
```
# fence_gce -o on -n secondary-host-name --zone=secondary-host-zone
```
Sur l'hôte secondaire, en tant qu'utilisateur racine, testez l'appareil de cloisonnement principal. Pour ce faire, répétez les étapes précédentes en utilisant les valeurs de l'hôte principal dans les commandes.

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

# pcs status

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

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

2 nodes configured
2 resources configured

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

Full list of resources:

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

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

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

Sur les deux hôtes, en tant qu'utilisateur racine, créez un fichier de dépôt systemd qui retarde le démarrage de Corosync pour garantir le bon déroulement de la séquence d'événements après le redémarrage d'une VM cloisonnée :
```
systemctl edit corosync.service
```
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

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

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

Installer un écouteur

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

En tant qu'utilisateur racine sur les deux hôtes, installez un écouteur TCP. Ces instructions permettent d'installer et d'utiliser HAProxy comme écouteur.
```
# yum install haproxy
```

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

# vi /etc/haproxy/haproxy.cfg

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

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

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

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

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

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

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

Sur chaque hôte, en tant qu'utilisateur racine, démarrez le service pour vérifier qu'il est correctement configuré :
```
# systemctl start haproxy.service
```
Sur la page "Équilibrage de charge" de la console Google Cloud , cliquez sur l'entrée de l'équilibreur de charge:

Page "Équilibrage de charge"

Dans la section Backend de la page Détails de l'équilibreur de charge, si le service HAProxy est actif sur les deux hôtes, 1/1 s'affiche dans la colonne Healthy (Opérationnel) de chaque entrée de groupe d'instances.
Sur chaque hôte, arrêtez le service HAProxy :
```
# systemctl stop haproxy.service
```
Une fois que vous avez arrêté le service HAProxy sur chaque hôte, 0/1 s'affiche dans la colonne Healthy (Opérationnel) de chaque groupe d'instances.

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

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

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

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

Vérifiez que le service de vérification de l'état est actif sur le même hôte que votre instance SAP MaxDB:
```
# pcs status
```
Si la ressource de vérification de l'état ne se trouve pas sur le même hôte que MaxDB, déplacez-la à l'aide de la commande suivante:
```
# pcs resource move healthcheck_resource_name target_host_name
# pcs resource clear healthcheck_resource_name
```
La commande pcs resource clear laisse la ressource à son nouvel emplacement, mais supprime la contrainte d'emplacement indésirable créée par la commande pcs resource move.

Dans l'état, la section des ressources doit ressembler à l'exemple suivant :
```
Full list of resources:

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

Resource Group: SAPMaxDB_Group
  rsc_healthcheck_MDB    (service:haproxy):      Started maxdb-ha-vm-1
```

Définir les valeurs par défaut du cluster

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

En tant qu'utilisateur racine, sur l'un ou l'autre des hôtes, définissez les valeurs par défaut de la ressource:
```
# pcs resource defaults resource-stickiness=1000
# pcs resource defaults migration-threshold=5000
```
La propriété resource-stickiness contrôle la probabilité qu'un service continue à s'exécuter là où il se trouve. Plus la valeur est élevée, plus le service est persistant. La valeur 1000 signifie que le service est très persistant.

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

Vous pouvez vérifier les valeurs par défaut des ressources en saisissant pcs resource defaults.
Définissez les délais avant expiration d'une opération de ressource par défaut :
```
# pcs resource op defaults timeout=600s
```
Vous pouvez vérifier les valeurs d'opération par défaut des ressources en saisissant pcs resource op defaults.
Définissez les propriétés de cluster suivantes:
```
# pcs property set stonith-enabled="true"
# pcs property set stonith-timeout="300s"
```
Vous pouvez vérifier les paramètres de votre propriété avec pcs property list.

Créer des ressources MaxDB dans le cluster

Avant de suivre cette procédure, assurez-vous que MaxDB et x_server sont arrêtés et que le système de fichiers /sapdb est démonté.

Créer une ressource gcp-pd-move

La ressource gcp-pd-move est un agent de ressources qui permet de déplacer le disque persistant d'un nœud à un autre lors d'un basculement de cluster.

Créez la ressource en tant qu'utilisateur racine sur l'un des nœuds à l'aide de la commande suivante:

# pcs resource create pd_move_resource_name gcp-pd-move \
  disk_name=regional_pd_name mode="READ_WRITE" disk_scope=regional \
  op monitor interval=10s timeout=15s \
  op start interval=0s timeout=300s \
  op stop interval=0s timeout=15s \
  --group SAPMaxDB_Group

Créer une ressource LVM

Un agent de ressources activé par LVM est utilisé pour activer le LVM une fois le disque déplacé vers l'autre nœud.

Créez la ressource LVM à l'aide de la commande suivante en tant qu'utilisateur racine sur l'un des nœuds:

# pcs resource create lvm_resource_name LVM-activate \
  vgname=vgname_for_maxdb \
  vg_access_mode=system_id activation_mode=exclusive \
  --group SAPMaxDB_Group

Exemple :

# pcs resource create sapdb_lvm LVM-activate \
  vgname=sapdb vg_access_mode=system_id \
  activation_mode=exclusive \
  --group SAPMaxDB_Group

Créer la ressource du système de fichiers

La ressource de système de fichiers est utilisée dans le cluster pour désinstaller /sapdb et l'installer sur un autre nœud lors de l'opération de basculement.

Créez la ressource de système de fichiers en tant que racine sur l'un des nœuds à l'aide de la commande suivante:

# pcs resource create fs_resource_name Filesystem \
  device=filesystem directory=/sapdb fstype=fs_type \
  --group SAPMaxDB_Group

Exemple :

# pcs resource create sapdb_FS Filesystem \
  device=/dev/mapper/sapdb-sapdblv directory=/sapdb fstype=ext4 \
  --group SAPMaxDB_Group

Préparation du groupe de ressources MaxDB

Pour activer le groupe de ressources MaxDB, procédez comme suit.

Synchronisez les utilisateurs et les groupes du nœud sur lequel vous avez effectué l'installation de MaxDB avec l'autre nœud.
1. Les utilisateurs SAP MaxDB doivent être synchronisés entre les nœuds en copiant les entrées dans /etc/passwd, par exemple:
```
 sdb:x:1002:1003:MaxDB User:/home/sdb:/bin/false
 madbadm:x:1003:1005:SAP System Administrator:/home/mdbadm:/bin/csh
```
2. De même, les groupes SAP doivent également être synchronisés en copiant les entrées dans /etc/group d'un nœud à l'autre, par exemple:
```
 dba:x:1003:mdbadm
 sapsys:x:1005:
```

Synchronisez les fichiers spécifiques à MaxDB stockés dans les répertoires du système d'exploitation. En tant qu'utilisateur racine, exécutez les commandes suivantes:

# rsync -av /etc/services target_host:/etc/services
# rsync -av /home/* target_host:/home
# rsync -av --exclude=sapservices /usr/sap/* target_host:/usr/sap
# rsync -av --ignore-existing /usr/sap/sapservicestarget_host:/usr/sap/sapservices
# rsync -av /etc/init.d/sapinittarget_host:/etc/init.d/

# MaxDB specific files
# rsync -av /etc/opttarget_host:/etc
# rsync -av /var/lib/sdbtarget_host:/var/lib

Pour les utilisateurs de l'OS SAP sur le deuxième nœud, renommez les fichiers d'environnement suivants pour utiliser leur nom d'hôte respectif dans leurs répertoires d'accueil, par exemple:

mv .sapenv_maxdb-ha-vm-1.sh .sapenv_maxdb-ha-vm-2.sh
mv .sapenv_maxdb-ha-vm-1.csh .sapenv_maxdb-ha-vm-2.csh
mv .sapsrc_maxdb-ha-vm-1.sh  .sapsrc_maxdb-ha-vm-2.sh
mv .sapsrc_maxdb-ha-vm-1.csh  .sapsrc_maxdb-ha-vm-2.csh
mv .dbenv_maxdb-ha-vm-1.sh .sapenv_maxdb-ha-vm-2.sh
mv .dbenv_maxdb-ha-vm-1.csh .dbenv_maxdb-ha-vm-2.csh

L'agent de ressources SAPDatabase n'utilise aucune commande spécifique à la base de données pour arrêter ou démarrer la base de données, mais s'appuie sur les commandes saphostctrl pour effectuer la même chose. L'agent hôte SAP nécessite la création d'entrées xuser pour la surveillance et le contrôle de MAXDB à l'aide de saphostctrl. Pour en savoir plus, consultez la note SAP 2435938 – SAP Host Agent SAP MaxDB: DBCredentials for DB connect (en anglais).

En tant que root, exécutez la commande suivante pour SetDatabaseProperty sur le nœud actif:

/usr/sap/hostctrl/exe/saphostctrl -host primary-host-name -user sapadm password \
  -dbname SID -dbtype ada -function SetDatabaseProperty DBCredentials=SET \
  -dboption User=SUPERDBA -dboption Password=password

Testez les entrées à l'aide de la commande suivante. Même si la base de données est arrêtée, la commande devrait pouvoir rétablir l'état:

/usr/sap/hostctrl/exe/saphostctrl -host secondary-host-name -dbname SID \
  -dbtype ada -function GetDatabaseStatus

La commande de l'agent saphostctrl utilise le programme xuser de l'installation MaxDB. Par conséquent, pour préparer le deuxième nœud maintenant, vous devez déplacer SAPMaxDB_group vers maxdb-node-b.

Sur n'importe quel nœud, exécutez la commande suivante en tant que root:
```
pcs resource move SAPMaxDB_group
```

Notez que les quatre ressources créées, la vérification de l'état, gcp-pd-move, LVM et le système de fichiers sont maintenant migrées et démarrées sur le deuxième nœud.

Vous pouvez utiliser la commande suivante sur n'importe quel nœud pour surveiller les actions effectuées:
```
watch pcs status
```

Une fois les quatre ressources démarrées sur le deuxième nœud, exécutez la commande saphostctrl.

En tant que root, exécutez la commande suivante pour définir SetDatabaseProperty sur le nœud désormais actif:

/usr/sap/hostctrl/exe/saphostctrl -host secondary-host-name -user sapadm password \
  -dbname SID -dbtype ada -function SetDatabaseProperty DBCredentials=SET \
  -dboption User=SUPERDBA -dboption Password=password

Sur le nœud b, démarrez manuellement MaxDB et x_server pour vérifier s'ils peuvent être démarrés correctement:
```
# dbmcli -d SID -u control, and password db_online
# x_server start
```

Passez à l'étape suivante, qui consiste à créer une ressource pour la base de données SAP. Si des erreurs sont détectées à ce stade, ne créez pas la ressource de base de données.

Créer une ressource pour SAP MaxDB

RHEL Pacemaker utilise l'agent de ressources de base de données SAP pour surveiller et contrôler la base de données SAP.

Créez la ressource de base de données sur le nœud où SAPMaxDB_group est actif à l'aide de la commande suivante:

# pcs resource create SAPDatabase_resource_name SAPDatabase \
  DBTYPE="ADA" SID="SID" STRICT_MONITORING="TRUE" \
  MONITOR_SERVICES="Database|x_server" AUTOMATIC_RECOVER="TRUE"
  --group SAPMaxDB_Group

Les ressources de cluster finales peuvent être consultées à l'aide de pcs status. Le résultat attendu est le suivant:

# pcs status
  Cluster name: maxdb-cluster
  Stack: corosync
  Current DC: maxdb-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
  Last updated: Wed Oct 23 02:04:32 2024
  Last change: Wed Oct 23 02:01:41 2024 by hacluster via crmd on maxdb-ha-vm-1

  2 nodes configured
  7 resource instances configured

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

  Full list of resources:

  STONITH-maxdb-ha-vm-1  (stonith:fence_gce):    Started maxdb-ha-vm-2
  STONITH-maxdb-ha-vm-2  (stonith:fence_gce):    Started maxdb-ha-vm-1
  Resource Group: SAPMaxDB_Group
     healthcheck_maxdb  (service:haproxy):      Started maxdb-ha-vm-1
     sapdb_regpd        (ocf::heartbeat:gcp-pd-move):   Started maxdb-ha-vm-1
     lvm_sapdb  (ocf::heartbeat:LVM-activate):  Started maxdb-ha-vm-1
     sapdb_fs   (ocf::heartbeat:Filesystem):    Started maxdb-ha-vm-1
     MDB_SAPMaxDB       (ocf::heartbeat:SAPDatabase):   Started maxdb-ha-vm-1

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

Tester le basculement

Testez votre cluster en simulant une défaillance sur l'hôte actif. 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 :

Arrêter manuellement MaxDB ou x_server
Arrêter le processus MaxDB ou x_server
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.

Sur l'hôte actif, en tant qu'utilisateur racine, déconnectez l'interface réseau :
```
# ip link set eth0 down
```
Reconnectez-vous à l'un des hôtes à l'aide de SSH, puis connectez-vous en tant qu'utilisateur racine.

Saisissez pcs status pour vérifier que l'hôte précédemment passif est désormais associé au disque persistant régional et qu'il exécute les services MaxDB. Le redémarrage automatique est activé dans le cluster. L'hôte arrêté redémarre donc et prend le rôle d'hôte passif, comme illustré dans l'exemple suivant:

Cluster name: maxdb-ha-cluster
Stack: corosync
Current DC: maxdb-ha-vm-2 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
Last updated: Wed Oct 23 02:01:45 2024
Last change: Wed Oct 23 02:01:41 2024 by hacluster via crmdon maxdb-ha-vm-2

2 nodes configured
7 resources configured

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

Full list of resources:

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

Resource Group: SAPMaxDB_Group
 healthcheck_maxdb  (service:haproxy):      Started maxdb-ha-vm-2
 sapdb_regpd        (ocf::heartbeat:gcp-pd-move):   Started maxdb-ha-vm-2
 lvm_sapdb  (ocf::heartbeat:LVM-activate):  Started maxdb-ha-vm-2
 sapdb_fs   (ocf::heartbeat:Filesystem):    Started maxdb-ha-vm-2
 MDB_SAPMaxDB       (ocf::heartbeat:SAPDatabase):   Started maxdb-ha-vm-2

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

Résoudre les problèmes

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

Obtenir de l'aide concernant SAP HANA sur RHEL

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

Guide de configuration d'un cluster à haute disponibilité pour SAP MaxDB sur RHEL

Système déployé dans ce guide

Prérequis

Créer un réseau

Console

gcloud

Configurer une passerelle NAT

Ajouter des règles de pare-feu

Console

gcloud

Déployer les VM et installer MaxDB

Créer une VM pour le déploiement de MaxDB

Créer un seul disque régional pour SAP MaxDB

Préparer l'OS RHEL pour l'installation de SAP

Créer des systèmes de fichiers

Modifier la configuration LVM

Installer la base de données et l'agent hôte SAP

Effectuer les tâches post-installation

Configurer la prise en charge du basculement Cloud Load Balancing

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

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

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

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

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

Tester la configuration de l'équilibreur de charge

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

Tester l'équilibreur de charge à l'aide du port 22

Configurer Pacemaker

Installer les agents de cluster sur les deux nœuds

Créer le cluster

RHEL 8 et versions ultérieures

RHEL 7

RHEL 8 et versions ultérieures

RHEL 7

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

RHEL 8 et versions ultérieures

RHEL 7

RHEL 8 et versions ultérieures

RHEL 7

Configurer le cloisonnement

Créer les ressources de l'appareil de cloisonnement

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

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

Installer un écouteur

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

Définir les valeurs par défaut du cluster

Créer des ressources MaxDB dans le cluster

Créer une ressource gcp-pd-move

Créer une ressource LVM

Créer la ressource du système de fichiers

Préparation du groupe de ressources MaxDB

Créer une ressource pour SAP MaxDB

Tester le basculement

Résoudre les problèmes

Obtenir de l'aide concernant SAP HANA sur RHEL

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