Haute disponibilité de SAP HANA sur les machines virtuelles Azure dans le système Red Hat Enterprise Linux

En développement local, vous pouvez utiliser soit la réplication du système HANA soit un stockage partagé pour établir la haute disponibilité (HA) pour SAP HANA. Sur les machines virtuelles Azure, la réplication du système HANA dans Azure est la seule fonction HA actuellement prise en charge.

La réplication SAP HANA se compose d’un nœud principal et d’au moins un nœud secondaire. Les modifications apportées aux données sur le nœud principal sont répliquées vers les nœuds secondaires de manière synchrone ou asynchrone.

Cet article explique comment déployer et configurer des machines virtuelles, installer l’infrastructure de cluster, et installer et configurer la réplication du système SAP HANA.

Les exemples de configuration et les commandes d’installation utilisent le numéro d’instance 03 et l’ID système HANA HN1.

Prérequis

Commencez par lire les notes et publications SAP suivantes :

• Note SAP 1928533, qui contient :
  • La liste des tailles de machines virtuelles Azure prises en charge pour le déploiement de logiciels SAP.
  • Des informations importantes sur la capacité en fonction de la taille des machines virtuelles Azure.
  • Les combinaisons prises en charge de logiciels SAP, de systèmes d’exploitation et de bases de données.
  • La version du noyau SAP requise pour Windows et Linux sur Microsoft Azure.
• La note SAP 2015553 répertorie les conditions préalables au déploiement de logiciels SAP pris en charge par SAP sur Azure.
• La note SAP 2002167 recommande des paramètres de système d’exploitation pour Red Hat Enterprise Linux.
• La note SAP 2009879 conseille sur SAP HANA pour Red Hat Enterprise Linux.
• La note SAP 3108302 contient des recommandations SAP HANA pour Red Hat Enterprise Linux 9.x.
• La note SAP 2178632 contient des informations détaillées sur toutes les métriques de surveillance rapportées pour SAP sur Azure.
• La note SAP 2191498 contient la version requise de l’agent hôte SAP pour Linux sur Azure.
• La note SAP 2243692 contient des informations sur les licences SAP sur Linux dans Azure.
• La note SAP 1999351 contient des informations supplémentaires sur le dépannage de l’extension Azure Enhanced Monitoring pour SAP.
• Le WIKI de la communauté SAP contient toutes les notes SAP requises pour Linux.
• Planification et implémentation de machines virtuelles Azure pour SAP sur Linux
• Déploiement de machines virtuelles Azure pour SAP sur Linux (cet article)
• Déploiement SGBD de machines virtuelles Azure pour SAP sur Linux
• Réplication du système SAP HANA dans un cluster Pacemaker
• Documentation RHEL générale :
  • Vue d’ensemble des modules complémentaires de haute disponibilité
  • Administration des modules complémentaires de haute disponibilité
  • Référence des modules complémentaires de haute disponibilité
  • Réplication du système de scale-up HANA avec le module complémentaire HA RHEL
• Documentation RHEL spécifique à Azure :
  • Stratégies de prise en charge des clusters à haute disponibilité RHEL - Machines virtuelles Microsoft Azure en tant que membres du cluster
  • Installation et configuration d’un cluster à haute disponibilité Red Hat Enterprise Linux 7.4 (et versions ultérieures) sur Microsoft Azure
  • Installation de SAP HANA sur Red Hat Enterprise Linux pour une utilisation dans Microsoft Azure

Vue d’ensemble

Pour les besoins de la haute disponibilité, SAP HANA est installé sur deux machines virtuelles. Les données sont répliquées à l’aide de la réplication de système HANA.

La configuration de la réplication du système SAP HANA utilise un nom d’hôte virtuel dédié et des adresses IP virtuelles. Sur Azure, un équilibreur de charge est nécessaire pour utiliser une adresse IP virtuelle. La configuration présentée montre un équilibreur de charge avec :

• Adresse IP frontale : 10.0.0.13 pour hn1-db
• Port de la sonde : 62503

Préparer l’infrastructure

La Place de marché Azure contient des images qualifiées pour SAP HANA avec le module complémentaire de haute disponibilité, que vous pouvez utiliser pour déployer de nouvelles machines virtuelles en utilisant différentes versions de Red Hat.

Déployer des machines virtuelles Linux manuellement via le portail Azure

Ce document part du principe que vous avez déjà déployé un groupe de ressources, un réseau virtuel Azure et un sous-réseau.

Déployez des machines virtuelles pour SAP HANA. Choisissez une image RHEL appropriée et prise en charge pour le système HANA. Vous pouvez déployer une machine virtuelle dans l’une des options de disponibilité : groupe de machines virtuelles identiques, zone de disponibilité ou groupe à haute disponibilité.

Configurer l’équilibrage de charge Azure

Pendant la configuration de la machine virtuelle, vous avez la possibilité de créer ou de sélectionner un équilibreur de charge existant dans la section réseau. Suivez les étapes ci-dessous pour configurer l’équilibreur de charge standard pour la configuration de la haute disponibilité de la base de données HANA.

# Create the load balancer resource with frontend IP. Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address.
az network lb create -g MyResourceGroup -n MyLB --sku Standard --vnet-name MyVMsVirtualNetwork --subnet MyVMsSubnet --backend-pool-name MyBackendPool --frontend-ip-name MyDBFrontendIpName

# Create the health probe
az network lb probe create -g MyResourceGroup --lb-name MyLB -n MyDBHealthProbe --protocol tcp --port MyDBHealthProbePort --interval 5 --probe-threshold 2
 
# Create load balancing rule
az network lb rule create -g MyResourceGroup --lb-name MyLB -n MyDBRuleName --protocol All --frontend-ip-name MyDBFrontendIpName --frontend-port 0 --backend-pool-name MyBackendPool --backend-port 0 --probe-name MyDBHealthProbe --idle-timeout-in-minutes 30 --enable-floating-ip 

# Add database VMs in backend pool
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm1IpConfigName --nic-name DBVm1NicName -g MyResourceGroup --lb-name MyLB
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm2IpConfigName --nic-name DBVm2NicName -g MyResourceGroup --lb-name MyLB

# Define variables for Resource Group, and Database VMs.

rg_name="resourcegroup-name"
vm1_name="db1-name"
vm2_name="db2-name"

# Define variables for the load balancer that will be utilized in the creation of the load balancer resource.

lb_name="sap-db-sid-ilb"
bkp_name="db-backendpool"
db_fip_name="db-frontendip"

db_hp_name="db-healthprobe"
db_hp_port="625<instance-no>"

db_rule_name="db-lb-rule"
 
# Command to get VMs network information like primary NIC name, primary IP configuration name, virtual network name, and subnet name. 
 
vm1_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm1_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm1_nic_name=$(basename $vm1_primary_nic)
vm1_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm1_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vm2_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm2_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm2_nic_name=$(basename $vm2_primary_nic)
vm2_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm2_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vnet_subnet_id=$(az network nic show -g $rg_name -n $vm1_nic_name --query ipConfigurations[0].subnet.id -o tsv)
vnet_name=$(basename $(dirname $(dirname $vnet_subnet_id)))
subnet_name=$(basename $vnet_subnet_id)
 
# Create the load balancer resource with frontend IP.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address. 
  
az network lb create -g $rg_name -n $lb_name --sku Standard --vnet-name $vnet_name --subnet $subnet_name --backend-pool-name $bkp_name --frontend-ip-name $db_fip_name
 
# Create the health probe
 
az network lb probe create -g $rg_name --lb-name $lb_name -n $db_hp_name --protocol tcp --port $db_hp_port --interval 5 --probe-threshold 2
 
# Create load balancing rule
  
az network lb rule create -g $rg_name --lb-name $lb_name -n  $db_rule_name --protocol All --frontend-ip-name $db_fip_name --frontend-port 0 --backend-pool-name $bkp_name --backend-port 0 --probe-name $db_hp_name --idle-timeout-in-minutes 30 --enable-floating-ip 
 
# Add database VMs in backend pool
 
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm1_ipconfig --nic-name $vm1_nic_name -g $rg_name --lb-name $lb_name
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm2_ipconfig --nic-name $vm2_nic_name -g $rg_name --lb-name $lb_name

# [OPTIONAL] Change the assignment of frontend IP address from dynamic to static
dbfip=$(az network lb frontend-ip show --lb-name $lb_name -g $rg_name -n $db_fip_name --query "{privateIPAddress:privateIPAddress}" -o tsv)
az network lb frontend-ip update --lb-name $lb_name -g $rg_name -n $db_fip_name --private-ip-address $dbfip

# Create frontend IP configurations
$db_fip = New-AzLoadBalancerFrontendIpConfig -Name MyDBFrontendIpName -SubnetId MyDBSubnetName

# Create backend pool
$bePool = New-AzLoadBalancerBackendAddressPoolConfig -Name MyBackendPool

# Create health probe
$db_healthprobe = New-AzLoadBalancerProbeConfig -Name MyDBHealthProbe -Protocol 'tcp' -Port MyDBHealthProbePort -IntervalInSeconds 5 -ProbeThreshold 2 -ProbeCount 1

# Create load balancing rule
$db_rule = New-AzLoadBalancerRuleConfig -Name MyDBRuleName -Probe $db_healthprobe -Protocol 'All' -IdleTimeoutInMinutes 30 -FrontendIpConfiguration $db_fip -BackendAddressPool $bePool -EnableFloatingIP

# Create the load balancer resource
$lb = New-AzLoadBalancer -ResourceGroupName MyResourceGroup -Name MyLB -Location MyRegion -Sku 'Standard' -FrontendIpConfiguration $db_fip -BackendAddressPool $bePool -LoadBalancingRule $db_rule -Probe $db_healthprobe

# Define variables for Resource Group, and Database VMs.

$rg_name = 'resourcegroup-name'
$vm1_name = 'db1-name'
$vm2_name = 'db2-name'

# Define variables for the load balancer that will be utilized in the creation of the load balancer resource.

$lb_name = 'sap-db-sid-ilb'
$bkp_name = 'db-backendpool'
$db_fip_name = 'db-frontendip'
 
$db_hp_name = 'db-healthprobe'
$db_hp_port = '625<instance-no>'
 
$db_rule_name = 'db-lb-rule'
 
# Command to get VMs network information like primary NIC name, primary IP configuration name, virtual network name, and subnet name.
 
$vm1 = Get-AzVM -ResourceGroupName $rg_name -Name $vm1_name
$vm1_primarynic = $vm1.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm1_nic_name = $vm1_primarynic.Id.Split('/')[-1]
 
$vm1_nic_info = Get-AzNetworkInterface -Name $vm1_nic_name -ResourceGroupName $rg_name
$vm1_primaryip = $vm1_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm1_ipconfig_name = ($vm1_primaryip).Name
 
$vm2 = Get-AzVM -ResourceGroupName $rg_name -Name $vm2_name
$vm2_primarynic = $vm2.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm2_nic_name = $vm2_primarynic.Id.Split('/')[-1]
 
$vm2_nic_info = Get-AzNetworkInterface -Name $vm2_nic_name -ResourceGroupName $rg_name
$vm2_primaryip = $vm2_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm2_ipconfig_name = ($vm2_primaryip).Name
 
$vnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-3]
$subnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-1]
$location = $vm1.Location
 
# Create frontend IP resource.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter -PrivateIpAddress
 
$db_lb_fip = @{
    Name = $db_fip_name
    SubnetId = $vm1_primaryip.Subnet.Id
}
$db_fip = New-AzLoadBalancerFrontendIpConfig @db_lb_fip

# Create backend pool
 
$bepool = New-AzLoadBalancerBackendAddressPoolConfig -Name $bkp_name

# Create the health probe
 
$db_probe = @{
    Name = $db_hp_name
    Protocol = 'tcp'
    Port = $db_hp_port
    IntervalInSeconds = '5'
    ProbeThreshold = '2'
    ProbeCount = '1'
}
$db_healthprobe = New-AzLoadBalancerProbeConfig @db_probe
    
# Create load balancing rule
 
$db_lbrule = @{
    Name = $db_rule_name
    Probe = $db_healthprobe
    Protocol = 'All'
    IdleTimeoutInMinutes = '30'
    FrontendIpConfiguration = $db_fip
    BackendAddressPool = $bePool 
} 
$db_rule = New-AzLoadBalancerRuleConfig @db_lbrule -EnableFloatingIP 
 
# Create the load balancer resource
 
$loadbalancer = @{
    ResourceGroupName = $rg_name
    Name = $lb_name
    Location = $location
    Sku = 'Standard'
    FrontendIpConfiguration = $db_fip
    BackendAddressPool = $bePool
    LoadBalancingRule = $db_rule
    Probe = $db_healthprobe
} 
$lb = New-AzLoadBalancer @loadbalancer

# Add DB VMs in backend pool
 
$vm1_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm2_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm1_nic_info | Set-AzNetworkInterface
$vm2_nic_info | Set-AzNetworkInterface

Pour plus d’informations sur les ports requis pour SAP HANA, consultez le chapitre Connections to Tenant Databases (Connexions aux bases de données locataires) dans le guide SAP HANA Tenant Databases (Bases de données locataires SAP HANA) ou la Note SAP 2388694.

Installer SAP HANA

Les étapes de cette section utilisent les préfixes suivants :

• [A] : l’étape s’applique à tous les nœuds.
• [1] : l’étape ne s’applique qu’au nœud 1.
• [2] : l’étape s’applique uniquement au nœud 2 du cluster Pacemaker.

1. [A] Configurez la disposition du disque : Logical Volume Manager (LVM) .

   Nous recommandons d’utiliser LVM pour les volumes qui stockent des données et des fichiers journaux. L’exemple suivant suppose que quatre disques de données sont attachés aux machines virtuelles et utilisés pour créer deux volumes.

   Répertoriez tous les disques disponibles :

   ls /dev/disk/azure/scsi1/lun*
   

   Exemple de sortie :

   /dev/disk/azure/scsi1/lun0  /dev/disk/azure/scsi1/lun1  /dev/disk/azure/scsi1/lun2  /dev/disk/azure/scsi1/lun3
   

   Créez des volumes physiques pour tous les disques que vous souhaitez utiliser :

   sudo pvcreate /dev/disk/azure/scsi1/lun0
   sudo pvcreate /dev/disk/azure/scsi1/lun1
   sudo pvcreate /dev/disk/azure/scsi1/lun2
   sudo pvcreate /dev/disk/azure/scsi1/lun3
   

   Créez un groupe de volume pour les fichiers de données. Utilisez un groupe de volume pour les fichiers journaux et un autre pour le répertoire partagé de SAP HANA :

   sudo vgcreate vg_hana_data_HN1 /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
   sudo vgcreate vg_hana_log_HN1 /dev/disk/azure/scsi1/lun2
   sudo vgcreate vg_hana_shared_HN1 /dev/disk/azure/scsi1/lun3
   

   Créez les volumes logiques. Un volume linéaire est créé lorsque vous utilisez lvcreate sans le commutateur -i. Nous vous suggérons de créer un volume agrégé par bandes pour améliorer les performances d’E/S. Alignez les tailles des bandes sur les valeurs documentées dans les configurations de stockage de machine virtuelle SAP HANA. L’argument -i doit correspondre au nombre de volumes physiques sous-jacents, et l’argument -I représente la taille de bande.

   Dans ce document, deux volumes physiques sont utilisés pour le volume de données. Par conséquent, l’argument de commutateur -i est défini sur 2. La taille de bande pour le volume de données est de 256 Kio. Un volume physique étant utilisé pour le volume du fichier journal, aucun commutateur -i ou -I n’est utilisé explicitement pour les commandes de volume du fichier journal.

   Important

   Utilisez le commutateur -i et définissez sa valeur sur le nombre de volumes physiques sous-jacents lorsque vous utilisez plusieurs volumes physiques pour chaque volume de données, volume de journal ou volume partagé. Utilisez le commutateur -I pour spécifier la taille de bande lors de la création d’un volume agrégé par bandes. Pour connaître les configurations de stockage recommandées, notamment les tailles de bande et le nombre de disques, consultez Configurations de stockage de machines virtuelles SAP HANA. Les exemples de disposition suivants ne répondent pas nécessairement aux recommandations en matière de performances pour une taille de système déterminée. Ils sont fournis à titre d’illustration uniquement.

   sudo lvcreate -i 2 -I 256 -l 100%FREE -n hana_data vg_hana_data_HN1
   sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_HN1
   sudo lvcreate -l 100%FREE -n hana_shared vg_hana_shared_HN1
   sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data
   sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
   sudo mkfs.xfs /dev/vg_hana_shared_HN1/hana_shared
   

   Ne montez pas les répertoires en émettant des commandes mount. Au lieu de cela, entrez les configurations dans le fichier fstab et émettez une commande mount -a finale pour valider la syntaxe. Commencez par créer les répertoires de montage pour chaque volume :

   sudo mkdir -p /hana/data
   sudo mkdir -p /hana/log
   sudo mkdir -p /hana/shared
   

   Ensuite, créez des entrées fstab pour les trois volumes logiques en insérant les lignes suivantes dans le fichier /etc/fstab :

   /dev/mapper/vg_hana_data_HN1-hana_data /hana/data xfs defaults,nofail 0 2 /dev/mapper/vg_hana_log_HN1-hana_log /hana/log xfs defaults,nofail 0 2 /dev/mapper/vg_hana_shared_HN1-hana_shared /hana/shared xfs defaults,nofail 0 2

   Enfin, montez tous les nouveaux volumes à la fois :

   sudo mount -a
   

2. [A] Configurez la résolution de nom d’hôte pour tous les hôtes.

   Vous pouvez utiliser un serveur DNS ou modifier le fichier /etc/hosts sur tous les nœuds en créant des entrées pour tous les nœuds comme ceci dans /etc/hosts :

   10.0.0.5 hn1-db-0 10.0.0.6 hn1-db-1

3. [A] Procédez à la configuration de RHEL pour HANA.

   Configurez RHEL tel que décrit dans les notes suivantes :

   • 2447641 - Packages supplémentaires requis pour installer SAP HANA SPS 12 sur RHEL 7.X
   • 2292690 - SAP HANA DB: Recommended OS settings for RHEL 7 (SAP HANA DB : Paramètres de système d’exploitation recommandés pour RHEL 7)
   • 2777782 – Base de données SAP HANA : paramètres de système d’exploitation recommandés pour RHEL 8
   • 2455582 – Linux : Exécution d’applications SAP compilées avec GCC 6.x
   • 2593824 – Linux : Exécution d’applications SAP compilées avec GCC 7.x
   • 2886607 – Linux : Exécution d’applications SAP compilées avec GCC 9.x

4. [A] Installez SAP HANA, en suivant la documentation de SAP.

5. [A] Configurez le pare-feu.

   Créez la règle de pare-feu pour le port de la sonde Azure Load Balancer.

   sudo firewall-cmd --zone=public --add-port=62503/tcp
   sudo firewall-cmd --zone=public --add-port=62503/tcp --permanent
   

Configurer la réplication de système SAP HANA 2.0

Les étapes de cette section utilisent les préfixes suivants :

• [A] : l’étape s’applique à tous les nœuds.
• [1] : l’étape ne s’applique qu’au nœud 1.
• [2] : l’étape s’applique uniquement au nœud 2 du cluster Pacemaker.

1. [A] Configurez le pare-feu.

   Créez des règles de pare-feu pour autoriser le trafic de réplication de système HANA et client. Les ports indispensables sont répertoriés ici : Ports TCP/IP de tous les produits SAP. Les commandes suivantes sont simplement un exemple pour autoriser la réplication du système HANA 2.0 et le trafic client vers la base de données SYSTEMDB, HN1 et NW1.

    sudo firewall-cmd --zone=public --add-port={40302,40301,40307,40303,40340,30340,30341,30342}/tcp --permanent
    sudo firewall-cmd --zone=public --add-port={40302,40301,40307,40303,40340,30340,30341,30342}/tcp
   
   

2. [1] Créer une base de données locataire.

   Exécutez la commande suivante en tant que <hanasid>adm :

   hdbsql -u SYSTEM -p "[passwd]" -i 03 -d SYSTEMDB 'CREATE DATABASE NW1 SYSTEM USER PASSWORD "<passwd>"'
   

3. [1] Configurez la réplication du système sur le premier nœud.

   Sauvegardez les bases de données en tant que <hanasid>adm :

   hdbsql -d SYSTEMDB -u SYSTEM -p "<passwd>" -i 03 "BACKUP DATA USING FILE ('initialbackupSYS')"
   hdbsql -d HN1 -u SYSTEM -p "<passwd>" -i 03 "BACKUP DATA USING FILE ('initialbackupHN1')"
   hdbsql -d NW1 -u SYSTEM -p "<passwd>" -i 03 "BACKUP DATA USING FILE ('initialbackupNW1')"
   

   Copiez les fichiers d’infrastructure à clé publique du système sur le site secondaire :

   scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT   hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
   scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY  hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/
   

   Créez le site principal :

   hdbnsutil -sr_enable --name=SITE1
   

4. [2] Configurez la réplication du système sur le deuxième nœud.

   Inscrivez le second nœud pour démarrer la réplication de système. Exécutez la commande suivante en tant que <hanasid>adm :

   sapcontrol -nr 03 -function StopWait 600 10
   hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2
   

5. [2] Démarrez HANA.

   Exécutez la commande suivante en tant que <hanasid>adm pour démarrer HANA :

   sapcontrol -nr 03 -function StartSystem
   

6. [1] Vérifiez l’état de la réplication.

   Vérifiez l’état de la réplication et attendez que toutes les bases de données soient synchronisées. Si l’état demeure INCONNU, vérifiez vos paramètres de pare-feu.

   sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
   # | Database | Host     | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
   # |          |          |       |              |           |         |           | Host      | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
   # | -------- | -------- | ----- | ------------ | --------- | ------- | --------- | --------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
   # | SYSTEMDB | hn1-db-0 | 30301 | nameserver   |         1 |       1 | SITE1     | hn1-db-1  |     30301 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
   # | HN1      | hn1-db-0 | 30307 | xsengine     |         2 |       1 | SITE1     | hn1-db-1  |     30307 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
   # | NW1      | hn1-db-0 | 30340 | indexserver  |         2 |       1 | SITE1     | hn1-db-1  |     30340 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
   # | HN1      | hn1-db-0 | 30303 | indexserver  |         3 |       1 | SITE1     | hn1-db-1  |     30303 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
   #
   # status system replication site "2": ACTIVE
   # overall system replication status: ACTIVE
   #
   # Local System Replication State
   # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   #
   # mode: PRIMARY
   # site id: 1
   # site name: SITE1
   

Créez un cluster Pacemaker

Suivez les étapes décrites sur la page Configurer Pacemaker sur Red Hat Enterprise Linux dans Azure pour créer un cluster Pacemaker de base pour ce serveur HANA.

Implémentez les hooks de réplication du système SAP HANA

Cette étape importante permet d’optimiser l’intégration au cluster et de mieux détecter le moment où un basculement s’avère nécessaire. Il est obligatoire pour le bon fonctionnement du cluster d'activer le hook SAPHanaSR. Nous vous recommandons fortement de configurer les hooks Python SAPHanaSR et ChkSrv.

1. [A] Installez les agents de la ressource SAP HANA sur tous les nœuds. N’oubliez pas d’activer un référentiel qui contient le package. Vous n’avez pas besoin d’activer davantage de référentiels si vous utilisez une image RHEL 8.x ou supérieure compatible HA.

   # Enable repository that contains SAP HANA resource agents
   sudo subscription-manager repos --enable="rhel-sap-hana-for-rhel-7-server-rpms"
   
   sudo dnf install -y resource-agents-sap-hana
   

   Remarque

   Pour RHEL 8.x et RHEL 9.x, vérifiez que le package resource-agents-sap-hana installé est la version 0.162.3-5 ou ultérieure.

2. [A] Installez system replication hooks HANA. La configuration des hooks de réplication doit être installée sur les deux nœuds HANA DB.

   1. Arrêter HANA sur les deux nœuds. Exécutez en tant que <sid>adm.

      sapcontrol -nr 03 -function StopSystem
      

   2. Réglez global.ini sur chaque nœud du cluster.

      [ha_dr_provider_SAPHanaSR]
      provider = SAPHanaSR
      path = /usr/share/SAPHanaSR/srHook
      execution_order = 1
      
      [ha_dr_provider_chksrv]
      provider = ChkSrv
      path = /usr/share/SAPHanaSR/srHook
      execution_order = 2
      action_on_lost = kill
      
      [trace]
      ha_dr_saphanasr = info
      ha_dr_chksrv = info
      

   Si vous pointez le paramètre path vers l'emplacement /usr/share/SAPHanaSR/srHook par défaut, le code du hook Python est mis à jour automatiquement via les mises à jour du système d'exploitation ou les mises à jour du package. HANA utilise les mises à jour du code de hook lors du redémarrage suivant. Avec un chemin propre facultatif comme /hana/shared/myHooks, vous pouvez découpler les mises à jour du système d'exploitation de la version du hook que HANA utilisera.

   Vous pouvez ajuster le comportement du hook ChkSrv en utilisant le paramètre action_on_lost. Les valeurs valides sont [ ignore | stop | kill ].

3. [A] Le cluster nécessite une configuration de sudoers sur chaque nœud de cluster pour <sid>adm. Dans cet exemple, cela est accompli en créant un fichier. Utilisez la commande visudo pour modifier le fichier déposé 20-saphana en tant que root.

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

   Insérez les lignes suivantes, puis enregistrez :

   Cmnd_Alias SITE1_SOK   = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE1 -v SOK -t crm_config -s SAPHanaSR
   Cmnd_Alias SITE1_SFAIL = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE1 -v SFAIL -t crm_config -s SAPHanaSR
   Cmnd_Alias SITE2_SOK   = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE2 -v SOK -t crm_config -s SAPHanaSR
   Cmnd_Alias SITE2_SFAIL = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE2 -v SFAIL -t crm_config -s SAPHanaSR
   hn1adm ALL=(ALL) NOPASSWD: SITE1_SOK, SITE1_SFAIL, SITE2_SOK, SITE2_SFAIL
   Defaults!SITE1_SOK, SITE1_SFAIL, SITE2_SOK, SITE2_SFAIL !requiretty
   

4. [A] Démarrez SAP HANA sur les deux nœuds. Exécutez en tant que <sid>adm.

   sapcontrol -nr 03 -function StartSystem 
   

5. [1] Vérifiez l’installation du hook SRHanaSR. Exécutez en tant que <sid>adm sur le site de réplication du système HANA actif.

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

    # 2021-04-12 21:36:16.911343 ha_dr_SAPHanaSR SFAIL
    # 2021-04-12 21:36:29.147808 ha_dr_SAPHanaSR SFAIL
    # 2021-04-12 21:37:04.898680 ha_dr_SAPHanaSR SOK
   

6. [1] Vérifiez l’installation du hook ChkSrv. Exécutez en tant que <sid>adm sur le site de réplication du système HANA actif.

    cdtrace
    tail -20 nameserver_chksrv.trc
   

Pour plus d'informations sur l'implémentation des hooks SAP HANA, voir Activation du hook SAP HANA srConnectionChanged() et Activation du hook SAP HANA srServiceStateChanged() pour l'action d'échec du processus hdbindexserver (facultatif).

Créer les ressources de cluster SAP HANA

Créez la topologie HANA. Exécutez les commandes suivantes sur l’un des nœuds du cluster Pacemaker. Tout au long de ces instructions, veillez à remplacer votre numéro d’instance, l’ID du système HANA, les adresses IP et les noms de système, le cas échéant.

sudo pcs property set maintenance-mode=true

sudo pcs resource create SAPHanaTopology_HN1_03 SAPHanaTopology SID=HN1 InstanceNumber=03 \
op start timeout=600 op stop timeout=300 op monitor interval=10 timeout=600 \
clone clone-max=2 clone-node-max=1 interleave=true

Ensuite, créez les ressources HANA.

Si vous créez un cluster sur RHEL 7.x, utilisez les commandes suivantes :

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

sudo pcs resource create vip_HN1_03 IPaddr2 ip="10.0.0.13"
sudo pcs resource create nc_HN1_03 azure-lb port=62503
sudo pcs resource group add g_ip_HN1_03 nc_HN1_03 vip_HN1_03

sudo pcs constraint order SAPHanaTopology_HN1_03-clone then SAPHana_HN1_03-master symmetrical=false
sudo pcs constraint colocation add g_ip_HN1_03 with master SAPHana_HN1_03-master 4000

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

sudo pcs property set maintenance-mode=false

Si vous créez un cluster sur RHEL 8.x/9.x, utilisez les commandes suivantes :

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

sudo pcs resource create vip_HN1_03 IPaddr2 ip="10.0.0.13"
sudo pcs resource create nc_HN1_03 azure-lb port=62503
sudo pcs resource group add g_ip_HN1_03 nc_HN1_03 vip_HN1_03

sudo pcs constraint order SAPHanaTopology_HN1_03-clone then SAPHana_HN1_03-clone symmetrical=false
sudo pcs constraint colocation add g_ip_HN1_03 with master SAPHana_HN1_03-clone 4000

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

sudo pcs property set maintenance-mode=false

Pour configurer priority-fencing-delay pour SAP HANA (valable uniquement à partir de pacemaker-2.0.4-6.el8 ou version ultérieure), les commandes suivantes doivent être exécutées.

sudo pcs property set maintenance-mode=true

sudo pcs resource defaults update priority=1
sudo pcs resource update SAPHana_HN1_03-clone meta priority=10

sudo pcs property set priority-fencing-delay=15s

sudo pcs property set maintenance-mode=false

Vérifiez que l’état du cluster est convenable et que toutes les ressources sont démarrées. Le nœud sur lequel les ressources s’exécutent n’est pas important.

Utilisez la commande sudo pcs status pour vérifier l’état des ressources de cluster créées :

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# azure_fence     (stonith:fence_azure_arm):      Started hn1-db-0
#  Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
#      Started: [ hn1-db-0 hn1-db-1 ]
#  Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
#      Masters: [ hn1-db-0 ]
#      Slaves: [ hn1-db-1 ]
#  Resource Group: g_ip_HN1_03
#      nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
#      vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

Configurer la réplication du système active/accessible en lecture HANA dans le cluster Pacemaker

À compter de SAP HANA 2.0 SPS 01, SAP autorise les configurations actives/accessibles en lecture pour la réplication du système SAP HANA, où les systèmes secondaires de réplication du système SAP HANA peuvent être utilisés activement pour les charges de travail à forte intensité de lecture.

Pour prendre en charge une telle configuration dans un cluster, une deuxième adresse IP virtuelle est nécessaire, ce qui permet aux clients d’accéder à la base de données SAP HANA secondaire accessible en lecture. Pour que le site de réplication secondaire reste accessible après une prise de contrôle, le cluster doit faire suivre l’adresse IP virtuelle avec la ressource SAPHana secondaire.

Cette section décrit les autres étapes nécessaires pour gérer la réplication du système active/accessible en lecture HANA dans un cluster HA Red Hat avec une deuxième adresse IP virtuelle.

Avant d’aller plus loin, vérifiez que vous avez entièrement configuré le cluster HA Red Hat gérant une base de données SAP HANA, comme décrit dans les sections précédentes de la documentation.

Configuration supplémentaire dans l’Équilibreur de charge Azure pour une installation active/en lecture activée

Pour passer à des étapes supplémentaires en vue d’approvisionner une deuxième adresse IP virtuelle, vérifiez que vous avez configuré Azure Load Balancer comme décrit dans la section Déployer manuellement des machines virtuelles Linux via le portail Azure.

1. Pour un équilibreur de charge standard, suivez ces étapes sur l’équilibreur de charge que vous avez créé dans une section précédente.

   a. Créez un deuxième pool d’adresses IP frontales :

   • Ouvrez l’équilibrage de charge, sélectionnez le Pool d’adresses IP frontales, puis cliquez sur Ajouter.
   • Entrez le nom du deuxième pool d’adresses IP frontales (par exemple hana-secondaryIP).
   • Définissez Affectation sur Statique et entrez l’adresse IP (par exemple, 10.0.0.14).
   • Cliquez sur OK.
   • Une fois le pool d’adresses IP frontal créé, notez son adresse IP.

   b. Créez une sonde d’intégrité :

   • Ouvrez l’équilibrage de charge, sélectionnez les sondes d’intégrité, puis cliquez sur Ajouter.
   • Entrez le nom de la nouvelle sonde d’intégrité (par exemple, hana-secondaryhp).
   • Sélectionnez TCP comme protocole et le port 62603. Conservez la valeur du paramètre Intervalle définie sur 5 et celle du Seuil de défaillance sur le plan de l’intégrité sur 2.
   • Cliquez sur OK.

   c. Créez les règles d’équilibrage de charge :

   • Ouvrez l’équilibrage de charge, sélectionnez Règles d’équilibrage de charge, puis cliquez sur Ajouter.
   • Entrez le nom de la nouvelle règle d’équilibrage de charge (par exemple, hana-secondarylb).
   • Sélectionnez l’adresse IP frontale, le pool principal et la sonde d’intégrité que vous avez créés (par exemple,hana-secondaryIP, hana-backend et hana-secondaryhp).
   • Sélectionnez Ports HA.
   • Veillez à activer l’IP flottante .
   • Sélectionnez OK.

Configurez la réplication du système HANA actif/en lecture activée

La procédure de configuration de la réplication du système HANA est décrite dans la section Configurer la réplication du système SAP HANA 2.0. Si vous déployez un scénario secondaire avec accès en lecture pendant que vous configurez la réplication du système sur le deuxième nœud, exécutez la commande suivante en tant que hanasidadm :

sapcontrol -nr 03 -function StopWait 600 10 

hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2 --operationMode=logreplay_readaccess 

Ajoutez une ressource d’adresse IP virtuelle secondaire pour une installation active/en lecture activée

La deuxième adresse IP virtuelle et la contrainte de colocation appropriée peuvent être configurées avec les commandes suivantes :

pcs property set maintenance-mode=true

pcs resource create secvip_HN1_03 ocf:heartbeat:IPaddr2 ip="10.40.0.16"

pcs resource create secnc_HN1_03 ocf:heartbeat:azure-lb port=62603

pcs resource group add g_secip_HN1_03 secnc_HN1_03 secvip_HN1_03

pcs constraint location g_secip_HN1_03 rule score=INFINITY hana_hn1_sync_state eq SOK and hana_hn1_roles eq 4:S:master1:master:worker:master

pcs constraint location g_secip_HN1_03 rule score=4000 hana_hn1_sync_state eq PRIM and hana_hn1_roles eq 4:P:master1:master:worker:master

pcs property set maintenance-mode=false

Vérifiez que l’état du cluster convient et que toutes les ressources sont démarrées. La deuxième adresse IP virtuelle s’exécute sur le site secondaire avec la ressource secondaire SAPHana.

sudo pcs status

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full List of Resources:
#   rsc_hdb_azr_agt     (stonith:fence_azure_arm):      Started hn1-db-0
#   Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]:
#     Started: [ hn1-db-0 hn1-db-1 ]
#   Clone Set: SAPHana_HN1_03-clone [SAPHana_HN1_03] (promotable):
#     Masters: [ hn1-db-0 ]
#     Slaves: [ hn1-db-1 ]
#   Resource Group: g_ip_HN1_03:
#     nc_HN1_03         (ocf::heartbeat:azure-lb):      Started hn1-db-0
#     vip_HN1_03        (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#   Resource Group: g_secip_HN1_03:
#     secnc_HN1_03      (ocf::heartbeat:azure-lb):      Started hn1-db-1
#     secvip_HN1_03     (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Dans la section suivante, vous trouverez l’ensemble typique de tests de basculement à exécuter.

Soyez attentif au comportement de la deuxième adresse IP virtuelle pendant que vous testez un cluster HANA configuré avec le secondaire accessible en lecture :

1. Lorsque vous migrez la ressource de cluster SAPHana_HN1_03 vers le site secondaire hn1-db-1, la deuxième adresse IP virtuelle continue de s’exécuter sur le même site hn1-db-1. Si vous avez défini AUTOMATED_REGISTER="true" pour la ressource et que la réplication du système HANA est inscrite automatiquement sur hn1-db-0, votre deuxième adresse IP virtuelle se déplace également vers hn1-db-0.

2. Lorsque vous testez une panne de serveur, les ressources de la deuxième adresse IP virtuelle (secvip_HN1_03) et les ressources de port Azure Load Balancer (secnc_HN1_03) s’exécutent sur le serveur principal en même temps que les ressources IP virtuelles principales. Ainsi, tant que le serveur secondaire n’est pas hors service, les applications connectées à la base de données HANA accessible en lecture se connectent à la base de données HANA primaire. Ce comportement est attendu, car il n’est pas souhaitable que les applications connectées à la base de données HANA accessible en lecture soient inaccessibles tant que le serveur secondaire n’est pas indisponible.

3. Pendant le basculement et la restauration de la deuxième adresse IP virtuelle, il peut arriver que les connexions existantes sur des applications qui utilisent la deuxième adresse IP virtuelle pour se connecter à la base de données HANA soient interrompues.

La configuration maximise le temps d’affectation de la deuxième ressource d’adresse IP virtuelle à un nœud sur lequel une instance SAP HANA saine s’exécute.

Tester la configuration du cluster

Cette section explique comment vous pouvez tester votre configuration. Avant de lancer un test, vérifiez que Pacemaker ne présente pas d’action en échec (via psc status), qu’il n’existe pas de contraintes d’emplacement inattendues (par exemple, les restes d’un test de migration) et que HANA est en état de synchronisation, par exemple avec systemReplicationStatus.

sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"

Tester la migration

État des ressources avant le début du test :

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-0 ]
    Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

Vous pouvez migrer le nœud maître SAP HANA en exécutant la commande suivante en tant que racine :

# On RHEL 7.x
pcs resource move SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource move SAPHana_HN1_03-clone --master

Le cluster ferait migrer le nœud principal SAP HANA et le groupe qui contient l’adresse IP virtuelle vers hn1-db-1.

Une fois la migration terminée, la sortie sudo pcs status se présente comme suit :

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Stopped: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Avec AUTOMATED_REGISTER="false", le cluster ne redémarre pas la base de données HANA ayant échoué et ne l’inscrit pas auprès du nouveau serveur principal sur hn1-db-0. Dans ce cas, configurez l’instance HANA comme étant secondaire en exécutant ces commandes en tant que hh1adm :

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1

La migration crée des contraintes d’emplacement qui doivent être de nouveau supprimées. Exécutez la commande suivante en tant que racine ou via sudo :

pcs resource clear SAPHana_HN1_03-master

Surveillez l’état de la ressource HANA à l’aide de pcs status. Une fois que HANA est lancé sur hn1-db-0, la sortie doit se présenter comme suit :

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Bloquer la communication réseau

État des ressources avant le début du test :

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Exécutez la règle de pare-feu pour bloquer la communication sur l’un des nœuds.

# Execute iptable rule on hn1-db-1 (10.0.0.6) to block the incoming and outgoing traffic to hn1-db-0 (10.0.0.5)
iptables -A INPUT -s 10.0.0.5 -j DROP; iptables -A OUTPUT -d 10.0.0.5 -j DROP

Lorsque les nœuds de cluster ne peuvent pas communiquer entre eux, il y a un risque de scénario « split-brain ». En pareil cas, les nœuds de cluster essaient de se clôturer les uns les autres, ce qui entraîne une course au clôturage. Pour éviter une telle situation, nous vous recommandons de définir la propriété priority-fencing-delay dans la configuration du cluster (valable uniquement pour pacemaker-2.0.4-6.el8 ou version supérieure).

En activant la propriété priority-fencing-delay, le cluster introduit un délai dans l’action de clôturage précisément sur le nœud hébergeant la ressource principale HANA, ce qui permet au nœud de gagner la course au clôturage.

Exécutez la commande suivante pour supprimer la règle de pare-feu :

# If the iptables rule set on the server gets reset after a reboot, the rules will be cleared out. In case they have not been reset, please proceed to remove the iptables rule using the following command.
iptables -D INPUT -s 10.0.0.5 -j DROP; iptables -D OUTPUT -d 10.0.0.5 -j DROP

Tester l’agent de délimitation Azure

État des ressources avant le début du test :

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Vous pouvez tester l’installation de l’agent de délimitation Azure en désactivant l’interface réseau sur le nœud sur lequel SAP HANA s’exécute en tant que nœud principal. Pour savoir comment simuler une défaillance réseau, consultez l’article de la base de connaissances Red Hat 79523.

Dans cet exemple, nous utilisons le script net_breaker en tant que racine pour bloquer tout accès au réseau :

sh ./net_breaker.sh BreakCommCmd 10.0.0.6

La machine virtuelle doit maintenant redémarrer ou s’arrêter en fonction de la configuration de votre cluster. Si vous définissez le paramètre stonith-action sur off, la machine virtuelle s’arrête et les ressources sont migrées vers la machine virtuelle en cours d’exécution.

Après avoir redémarré la machine virtuelle, la ressource SAP HANA ne peut pas démarrer en tant que ressource secondaire si vous définissez AUTOMATED_REGISTER="false". Dans ce cas, configurez l’instance HANA comme étant secondaire en exécutant cette commande en tant qu’utilisateur hn1adm :

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2

Revenez à la racine et nettoyez l’état en échec :

# On RHEL 7.x
pcs resource cleanup SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource cleanup SAPHana_HN1_03 node=<hostname on which the resource needs to be cleaned>

État des ressources après le test :

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-0 ]
    Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

Tester un basculement manuel

État des ressources avant le début du test :

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-0 ]
    Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

Vous pouvez tester un basculement manuel en arrêtant le cluster sur le nœud hn1-db-0, en tant que racine :

pcs cluster stop

Après le basculement, redémarrez le cluster. Si vous définissez AUTOMATED_REGISTER="false", la ressource SAP HANA sur le nœud hn1-db-0 ne parvient pas à démarrer en tant que ressource secondaire. Dans ce cas, configurez l’instance HANA comme étant secondaire en exécutant cette commande en tant que racine :

pcs cluster start

Exécutez ce qui suit en tant que hn1adm :

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1

Puis en tant que racine :

# On RHEL 7.x
pcs resource cleanup SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource cleanup SAPHana_HN1_03 node=<hostname on which the resource needs to be cleaned>

État des ressources après le test :

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
     Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Étapes suivantes

• Planification et implémentation de machines virtuelles Azure pour SAP
• Déploiement de machines virtuelles Azure pour SAP
• Déploiement SGBD de machines virtuelles Azure pour SAP
• Configurations de stockage de machines virtuelles SAP HANA