Haute disponibilité pour SAP HANA sur des machines virtuelles Azure sur SUSE Linux Enterprise Server

Pour établir une haute disponibilité dans un déploiement SAP HANA local, vous pouvez utiliser la réplication du système SAP HANA ou le stockage partagé.

Actuellement sur des machines virtuelles Azure, la réplication du système SAP HANA sur Azure est la seule fonction de haute disponibilité prise en charge.

La réplication du système 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 les machines virtuelles, installer l’infrastructure de cluster et installer et configurer la réplication du système SAP HANA.

Avant de commencer, lisez les notes et documents SAP suivants :

• Note SAP 1928533. La note comprend les éléments suivants :
  • 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.
  • Combinaisons de logiciels SAP, de système d’exploitation et de base de données SAP pris en charge.
  • Versions requises du noyau SAP 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 2205917 recommande des paramètres de système d’exploitation pour SUSE Linux Enterprise Server 12 (SLES 12) pour les applications SAP.
• La note SAP 2684254 recommande des paramètres de système d’exploitation pour SUSE Linux Enterprise Server 15 (SLES 15) pour les applications SAP.
• La note 2235581 présente les systèmes d’exploitation pris en charge par SAP HANA
• La note SAP 2178632 contient des informations détaillées sur toutes les métriques de supervision signalées pour SAP dans Azure.
• La note SAP 2191498 a la version requise de l’agent hôte SAP pour Linux dans Azure.
• La note SAP 2243692 contient des informations sur les licences SAP pour Linux dans Azure.
• La note SAP 1984787 contient des informations sur SUSE Linux Enterprise Server 12.
• La note SAP 1999351 contient des informations supplémentaires sur le dépannage de l’extension Azure Enhanced Monitoring pour SAP.
• La note SAP 401162 contient des informations sur la façon d’éviter les erreurs d'« adresse déjà en cours d’utilisation » lorsque vous configurez la réplication du système HANA.
• Wiki de support de la communauté SAP contient toutes les notes SAP requises pour Linux.
• Plateformes IaaS certifiées SAP HANA.
• Guide Planification et implémentation de machines virtuelles Azure pour SAP sur Linux.
• Déploiement de machines virtuelles Azure pour SAP sur Linux guide.
• Guide de déploiement SGBD de machines virtuelles Azure pour SAP sur Linux.
• Guides des meilleures pratiques de SUSE Linux Enterprise Server pour SAP Applications 15 et Guides des meilleures pratiques de SUSE Linux Enterprise Server pour SAP Applications 12 :
  • Configuration d’une infrastructure SAP HANA SR optimisée pour les performances (SLES pour les applications SAP). Le guide contient toutes les informations requises pour configurer la réplication du système SAP HANA pour le développement local. Utilisez ce guide comme référence.
  • Configuration d’une infrastructure SAP HANA SR à coût optimisé (SLES pour les applications SAP).

Planifier la haute disponibilité DE SAP HANA

Pour obtenir une haute disponibilité, installez SAP HANA sur deux machines virtuelles. Les données sont répliquées à l’aide de la réplication du 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. Dans Azure, vous avez besoin d’un équilibreur de charge pour déployer une adresse IP virtuelle.

La figure précédente montre un exemple d’équilibreur de charge qui a ces configurations :

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

Préparer l’infrastructure

L’agent de ressource pour SAP HANA est inclus dans SUSE Linux Enterprise Server for SAP Applications. Une image pour SUSE Linux Enterprise Server for SAP Applications 12 ou 15 est disponible sur la Place de marché Azure. Vous pouvez utiliser l’image pour déployer de nouvelles machines virtuelles.

Déployer manuellement des machines virtuelles Linux 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 SLES appropriée prise en charge pour le système HANA. Vous pouvez déployer une machine virtuelle dans n’importe laquelle des options de disponibilité : groupe de machines virtuelles identiques, zone de disponibilité ou groupe à haute disponibilité.

Important

Assurez-vous que le système d’exploitation que vous sélectionnez est certifié SAP pour SAP HANA sur les types de machines virtuelles spécifiques que vous envisagez d’utiliser dans votre déploiement. Vous pouvez rechercher les types de machines virtuelles certifiées SAP HANA et leurs versions de système d’exploitation sur la page Plateformes IaaS certifiées SAP HANA. Veillez à consulter les détails du type de machine virtuelle pour obtenir la liste complète des versions de système d’exploitation prises en charge par SAP HANA pour le type de machine virtuelle spécifique.

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.

Azure

Suivez les étapes dans Créer un équilibreur de charge pour configurer un équilibreur de charge standard pour un système SAP à haute disponibilité à l’aide du portail Azure. Pendant la configuration de l’équilibreur de charge, tenez compte des points suivants :

1. Configuration d’une adresse IP front-end : créez une adresse IP front-end. Sélectionnez le même nom de réseau virtuel et de sous-réseau que vos machines virtuelles de base de données.
2. Pool back-end : créez un pool back-end et ajoutez des machines virtuelles de base de données.
3. Règles de trafic entrant : créez une règle d’équilibrage de charge. Suivez les mêmes étapes pour les deux règles d’équilibrage de charge.
   • Adresse IP front-end : sélectionnez une adresse IP front-end.
   • Pool back-end : sélectionnez un pool back-end.
   • Ports haute disponibilité : sélectionnez cette option.
   • Protocole : sélectionnez TCP.
   • Sonde d’intégrité : créez une sonde d’intégrité avec les détails suivants :
     • Protocole : sélectionnez TCP.
     • Port : par exemple, 625<numéro-instance>.
     • Intervalle : entrez 5.
     • Seuil de sonde : entrez 2.
   • Délai d'inactivité (minutes) : entrez 30.
   • Activer l’adresse IP flottante : sélectionnez cette option.

Remarque

La propriété de configuration de la sonde d’intégrité numberOfProbes, également appelée Seuil de défaillance sur le plan de l’intégrité dans le portail, n’est pas respectée. Pour contrôler le nombre de sondes consécutives qui aboutissent ou qui échouent, définissez la propriété probeThreshold sur 2. Il n’est actuellement pas possible de définir cette propriété à l’aide du portail Azure. Utilisez donc l’interface Azure CLI ou la commande PowerShell.

Azure CLI

# 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

Développer pour afficher le code CLI complet

# 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

PowerShell

# 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

Développer pour afficher le code PowerShell complet

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

Remarque

Lorsque les machines virtuelles qui n’ont pas d’adresses IP publiques sont placées dans le pool principal d’une instance standard (aucune adresse IP publique) interne d’Azure Load Balancer, la configuration par défaut n’est pas une connectivité Internet sortante. Vous pouvez effectuer des étapes supplémentaires pour autoriser le routage vers des points de terminaison publics. Pour plus d’informations sur la façon d’obtenir une connectivité sortante, consultez connectivité de point de terminaison public pour les machines virtuelles à l’aide d’Azure Standard Load Balancer dans les scénarios de haute disponibilité SAP.

Important

• N’activez pas les horodatages TCP sur les machines virtuelles Azure placées derrière Azure Load Balancer. L’activation des horodateurs TCP provoque l’échec des sondes d’intégrité. Définissez le paramètre net.ipv4.tcp_timestamps sur 0. Pour plus d’informations, consultez Sondes d’intégrité Load Balancer ou la note SAP 2382421.
• Pour empêcher que saptune redéfinisse sur 1 la valeur net.ipv4.tcp_timestamps qui avait été définie manuellement sur 0, mettez à jour saptune vers la version 3.1.1 ou ultérieure. Pour plus d’informations, consultez saptune 3.1.1 – Do I Need to Update?.

Créez un cluster Pacemaker

Suivez les étapes de Configurer Pacemaker sur SUSE Linux Enterprise Server dans Azure pour créer un cluster Pacemaker de base pour ce serveur HANA. Vous pouvez utiliser le même cluster Pacemaker pour SAP HANA et SAP NetWeaver (A)SCS.

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 s’applique uniquement au nœud 1.
• [2]: l’étape s’applique uniquement au nœud 2 du cluster Pacemaker.

Remplacez <placeholders> par les valeurs de votre installation SAP HANA.

1. [A] Configuration de la disposition des disques à l’aide du gestionnaire de volumes logiques (LVM).

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

   1. Exécutez cette commande pour répertorier tous les disques disponibles :

      /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
      

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

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

      sudo vgcreate vg_hana_data_<HANA SID> /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
      sudo vgcreate vg_hana_log_<HANA SID> /dev/disk/azure/scsi1/lun2
      sudo vgcreate vg_hana_shared_<HANA SID> /dev/disk/azure/scsi1/lun3
      

   4. 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 de bande sur les valeurs décrites dans configurations de stockage de machines virtuelles SAP HANA. L’argument -i doit être le nombre de volumes physiques sous-jacents, et l’argument -I est la taille de bande.

      Par exemple, si deux volumes physiques sont utilisés pour le volume de données, l’argument -i commutateur est défini sur 2, et la taille de bande du volume de données est 256Kio. 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

      Lorsque vous utilisez plusieurs volumes physiques pour chaque volume de données, volume de journal ou volume partagé, utilisez le commutateur -i et définissez-le comme nombre de volumes physiques sous-jacents. Lorsque vous créez un volume à bandes, utilisez le commutateur -I pour spécifier la taille de bande.

      Pour connaître les configurations de stockage recommandées, notamment les tailles de bandes et le nombre de disques, consultez configurations de stockage de machines virtuelles SAP HANA.

      sudo lvcreate <-i number of physical volumes> <-I stripe size for the data volume> -l 100%FREE -n hana_data vg_hana_data_<HANA SID>
      sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_<HANA SID>
      sudo lvcreate -l 100%FREE -n hana_shared vg_hana_shared_<HANA SID>
      sudo mkfs.xfs /dev/vg_hana_data_<HANA SID>/hana_data
      sudo mkfs.xfs /dev/vg_hana_log_<HANA SID>/hana_log
      sudo mkfs.xfs /dev/vg_hana_shared_<HANA SID>/hana_shared
      

   5. Créez les répertoires de montage et copiez l’identificateur universel unique (UUID) de tous les volumes logiques :

      sudo mkdir -p /hana/data/<HANA SID>
      sudo mkdir -p /hana/log/<HANA SID>
      sudo mkdir -p /hana/shared/<HANA SID>
      # Write down the ID of /dev/vg_hana_data_<HANA SID>/hana_data, /dev/vg_hana_log_<HANA SID>/hana_log, and /dev/vg_hana_shared_<HANA SID>/hana_shared
      sudo blkid
      

   6. Modifiez le fichier /etc/fstab pour créer des entrées fstab pour les trois volumes logiques :

      sudo vi /etc/fstab
      

   7. Insérez les lignes suivantes dans le fichier /etc/fstab :

      /dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_data_<HANA SID>-hana_data> /hana/data/<HANA SID> xfs  defaults,nofail  0  2
      /dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_log_<HANA SID>-hana_log> /hana/log/<HANA SID> xfs  defaults,nofail  0  2
      /dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_shared_<HANA SID>-hana_shared> /hana/shared/<HANA SID> xfs  defaults,nofail  0  2
      

   8. Montez les nouveaux volumes :

      sudo mount -a
      

2. [A] configurer la disposition du disque à l’aide de disques bruts.

   Pour les systèmes de démonstration, vous pouvez placer vos données et fichiers journaux HANA sur un disque.

   1. Créez une partition sur /dev/disk/azure/scsi1/lun0 et mettez-la en forme à l’aide de XFS :

      sudo sh -c 'echo -e "n\n\n\n\n\nw\n" | fdisk /dev/disk/azure/scsi1/lun0'
      sudo mkfs.xfs /dev/disk/azure/scsi1/lun0-part1
      
      # Write down the ID of /dev/disk/azure/scsi1/lun0-part1
      sudo /sbin/blkid
      sudo vi /etc/fstab
      

   2. Insérez cette ligne dans le fichier /etc/fstab :

      /dev/disk/by-uuid/<UUID> /hana xfs  defaults,nofail  0  2
      

   3. Créez le répertoire cible et montez le disque :

      sudo mkdir /hana
      sudo mount -a
      

3. [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. Cet exemple montre comment utiliser le fichier /etc/hosts. Remplacez les adresses IP et les noms d’hôtes dans les commandes suivantes.

   1. Modifiez le fichier /etc/hosts :

      sudo vi /etc/hosts
      

   2. Insérez les lignes suivantes dans le fichier /etc/hosts. Modifiez les adresses IP et les noms d’hôte pour qu’ils correspondent à votre environnement.

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

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

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 s’applique uniquement au nœud 1.
• [2]: l’étape s’applique uniquement au nœud 2 du cluster Pacemaker.

Remplacez <placeholders> par les valeurs de votre installation SAP HANA.

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

   Si vous utilisez SAP HANA 2.0 ou SAP HANA MDC, créez une base de données de locataire pour votre système SAP NetWeaver.

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

   hdbsql -u SYSTEM -p "<password>" -i <instance number> -d SYSTEMDB 'CREATE DATABASE <SAP SID> SYSTEM USER PASSWORD "<password>"'
   

2. [1] configurer la réplication système sur le premier nœud :

   Tout d’abord, sauvegardez les bases de données en tant que <HANA SID>adm :

   hdbsql -d SYSTEMDB -u SYSTEM -p "<password>" -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file for SYS>')"
   hdbsql -d <HANA SID> -u SYSTEM -p "<password>" -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file for HANA SID>')"
   hdbsql -d <SAP SID> -u SYSTEM -p "<password>" -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file for SAP SID>')"
   

   Ensuite, copiez les fichiers d’infrastructure à clé publique système (PKI) sur le site secondaire :

   scp /usr/sap/<HANA SID>/SYS/global/security/rsecssfs/data/SSFS_<HANA SID>.DAT   hn1-db-1:/usr/sap/<HANA SID>/SYS/global/security/rsecssfs/data/
   scp /usr/sap/<HANA SID>/SYS/global/security/rsecssfs/key/SSFS_<HANA SID>.KEY  hn1-db-1:/usr/sap/<HANA SID>/SYS/global/security/rsecssfs/key/
   

   Créez le site principal :

   hdbnsutil -sr_enable --name=<site 1>
   

3. [2] configurer la réplication 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 <SID HANA>adm :

   sapcontrol -nr <instance number> -function StopWait 600 10
   hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2> 
   

Implémenter des agents de ressources HANA

SUSE fournit deux packages logiciels différents pour l’agent de ressources Pacemaker permettant de gérer SAP HANA. Les packages logiciels SAPHanaSR et SAPHanaSR-angi utilisent une syntaxe et des paramètres légèrement différents et ne sont pas compatibles. Consultez les notes de publication et la documentation SUSE pour plus d’informations et les différences entre SAPHanaSR et SAPHanaSR-angi. Ce document couvre les deux packages dans des onglets distincts, dans les sections respectives.

Avertissement

Ne remplacez pas le package SAPHanaSR par SAPHanaSR-angi dans un cluster déjà configuré. La mise à niveau de SAPHanaSR vers SAPHanaSR-angi nécessite une procédure spécifique.

1. [A] Installez les packages de haute disponibilité SAP HANA :

SAPHanaSR

Exécutez la commande suivante pour installer les packages de haute disponibilité :

sudo zypper install SAPHanaSR

SAPHanaSR-angi

Important

SAPHanaSR-angi a une configuration minimale requise de SAP HANA 2.0 SPS 05 et SUSE SLES pour les applications SAP 15 SP4 ou ultérieures.

Exécutez la commande suivante pour installer les packages de haute disponibilité :

sudo zypper install SAPHanaSR-angi

Configurer des fournisseurs SAP HANA HA/DR

Les fournisseurs de haute disponibilité ou de récupération d’urgence (HA/DR) SAP HANA optimisent l’intégration au cluster et améliorent la détection lorsqu’un basculement de cluster est nécessaire. Le script de hook principal est SAPHanaSR (pour le package SAPHanaSR) / susHanaSR (pour SAPHanaSR-angi). Nous vous recommandons vivement de configurer le hook Python SAPHanaSR/susHanaSR. Pour HANA 2.0 SPS 05 et les versions ultérieures, nous vous recommandons d’implémenter les hooks sapHanaSR/susHanaSR et susChkSrv.

Le hook susChkSrv étend les fonctionnalités du fournisseur de haute disponibilité SAPHanaSR/susHanaSR principal. Il agit lorsque le processus HANA se bloque. Si un processus unique se bloque, HANA tente généralement de le redémarrer. Le redémarrage du processus indexserver peut prendre du temps, durant lequel la base de données HANA ne répond pas.

Avec susChkSrv implémenté, une action immédiate et configurable est exécutée. L’action déclenche un basculement dans la période d’expiration configurée au lieu d’attendre le redémarrage du processus hdbindexserver sur le même nœud.

1. [A] Arrêtez HANA sur les deux nœuds.

Exécutez le code suivant comme <sap-sid>adm :

sapcontrol -nr <instance number> -function StopSystem

2. [A] Installez les hooks de réplication système HANA. Les hooks doivent être installés sur les deux nœuds de base de données HANA.

   Conseil

   Le hook Python SAPHanaSR peut être implémenté uniquement pour HANA 2.0. Le package SAPHanaSR doit être au moins version 0.153.
   Le hook Python SAPHanaSR-angi ne peut être implémenté que pour HANA 2.0 SPS 05 et les versions ultérieures.
   Le hook Python susChkSrv nécessite SAP HANA 2.0 SPS 05 et la version SAPHanaSR 0.161.1_BF ou ultérieure doivent être installés.

   SAPHanaSR

   1. [A] Ajuster global.ini sur chaque nœud de cluster.

      Si les conditions requises pour le hook susChkSrv ne sont pas remplies, supprimez l’intégralité du bloc [ha_dr_provider_suschksrv] des paramètres suivants. Vous pouvez ajuster le comportement de susChkSrv à l’aide du paramètre action_on_lost. Les valeurs valides sont [ ignore | stop | kill | fence ].

      [ha_dr_provider_SAPHanaSR]
      provider = SAPHanaSR
      path = /usr/share/SAPHanaSR
      execution_order = 1
      
      [ha_dr_provider_suschksrv]
      provider = susChkSrv
      path = /usr/share/SAPHanaSR
      execution_order = 3
      action_on_lost = fence
      
      [trace]
      ha_dr_saphanasr = info
      

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

   2. [A] Le cluster nécessite une configurationsudoers sur chaque nœud de cluster pour <sap-sid>adm. Dans cet exemple, cela est accompli en créant un fichier.

      Exécutez la commande suivante en tant que racine. Remplacez <sid> par l’ID système SAP en minuscule, <SID> par l’ID système SAP en majuscule et <siteA/B> par les noms de site HANA choisis.

      cat << EOF > /etc/sudoers.d/20-saphana
      # Needed for SAPHanaSR and susChkSrv Python hooks
      Cmnd_Alias SOK_SITEA      = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SOK   -t crm_config -s SAPHanaSR
      Cmnd_Alias SFAIL_SITEA    = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SFAIL -t crm_config -s SAPHanaSR
      Cmnd_Alias SOK_SITEB      = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SOK   -t crm_config -s SAPHanaSR
      Cmnd_Alias SFAIL_SITEB    = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SFAIL -t crm_config -s SAPHanaSR
      Cmnd_Alias HELPER_TAKEOVER = /usr/sbin/SAPHanaSR-hookHelper --sid=<SID> --case=checkTakeover
      Cmnd_Alias HELPER_FENCE    = /usr/sbin/SAPHanaSR-hookHelper --sid=<SID> --case=fenceMe
      
      <sid>adm ALL=(ALL) NOPASSWD: SOK_SITEA, SFAIL_SITEA, SOK_SITEB, SFAIL_SITEB, HELPER_TAKEOVER, HELPER_FENCE
      EOF
      

   Pour plus d’informations sur l’implémentation du hook de réplication du système SAP HANA, consultez Configurer des fournisseurs de haute disponibilité/récupération d’urgence HANA.

   SAPHanaSR-angi

   1. [A] Ajuster global.ini sur chaque nœud de cluster.

      Si vous choisissez de ne pas utiliser le hook susChkSrv recommandé, supprimez l’intégralité du bloc [ha_dr_provider_suschksrv] des paramètres suivants. Vous pouvez ajuster le comportement de susChkSrv à l’aide du paramètre action_on_lost. Les valeurs valides sont [ ignore | stop | kill | fence ].

      [ha_dr_provider_sushanasr]
      provider = susHanaSR
      path = /usr/share/SAPHanaSR-angi
      execution_order = 1
      
      [ha_dr_provider_suschksrv]
      provider = susChkSrv
      path = /usr/share/SAPHanaSR-angi
      execution_order = 3
      action_on_lost = fence
      
      [trace]
      ha_dr_sushanasr = info
      ha_dr_saphanasr = info
      

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

   2. [A] Le cluster nécessite une configurationsudoers sur chaque nœud de cluster pour <sap-sid>adm. Dans cet exemple, cela est accompli en créant un fichier.

      Exécutez la commande suivante en tant que racine. Remplacez <sid> par l’ID système SAP en minuscule, <SID> par l’ID système SAP en majuscule et <siteA/B> par les noms de site HANA choisis.

      cat << EOF > /etc/sudoers.d/20-saphana
      # Needed for susHanaSR and susChkSrv Python hooks
      Cmnd_Alias SOK_SITEA    = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SOK   -t crm_config -s SAPHanaSR
      Cmnd_Alias SFAIL_SITEA  = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SFAIL -t crm_config -s SAPHanaSR
      Cmnd_Alias SOK_SITEB    = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SOK   -t crm_config -s SAPHanaSR
      Cmnd_Alias SFAIL_SITEB  = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SFAIL -t crm_config -s SAPHanaSR
      Cmnd_Alias HELPER_TAKEOVER  = /usr/bin/SAPHanaSR-hookHelper --sid=<SID> --case=checkTakeover
      Cmnd_Alias HELPER_FENCE     = /usr/bin/SAPHanaSR-hookHelper --sid=<SID> --case=fenceMe
      
      <sid>adm ALL=(ALL) NOPASSWD: SOK_SITEA, SFAIL_SITEA, SOK_SITEB, SFAIL_SITEB, HELPER_TAKEOVER, HELPER_FENCE
      EOF
      

      Pour plus d’informations sur l’implémentation du hook de réplication du système SAP HANA, consultez Configurer des fournisseurs de haute disponibilité/récupération d’urgence HANA.

---

3. [A] Démarrez SAP HANA sur les deux nœuds. Exécutez la commande suivante en tant que <sap-sid>adm :

   sapcontrol -nr <instance number> -function StartSystem 
   

4. [1] Vérifiez l’installation de hook. Exécutez la commande suivante en tant que <sap-sid>adm sur le site de réplication système HANA actif :

   SAPHanaSR

   cdtrace
   awk '/ha_dr_SAPHanaSR.*crm_attribute/ \
   { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*
   # Example output
   # 2021-04-08 22:18:15.877583 ha_dr_SAPHanaSR SFAIL
   # 2021-04-08 22:18:46.531564 ha_dr_SAPHanaSR SFAIL
   # 2021-04-08 22:21:26.816573 ha_dr_SAPHanaSR SOK
   

   SAPHanaSR-angi

   cdtrace
   grep HADR.*load.*SAPHanaSR nameserver_*.trc
   # Example output
   # ha_dr_provider HADRProviderManager.cpp(00083) : loading HA/DR Provider 'susHanaSR' from /usr/share/SAPHanaSR-angi
   

---

5. [1] Vérifiez l’installation du hook susChkSrv. Exécutez la commande suivante en tant que <sap-sid>adm sur toutes les machines virtuelles HANA :

   cdtrace
   egrep '(LOST:|STOP:|START:|DOWN:|init|load|fail)' nameserver_suschksrv.trc
   # Example output
   # 2022-11-03 18:06:21.116728  susChkSrv.init() version 0.7.7, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9
   # 2022-11-03 18:06:27.613588  START: indexserver event looks like graceful tenant start
   # 2022-11-03 18:07:56.143766  START: indexserver event looks like graceful tenant start (indexserver started)
   

Créer les ressources de cluster SAP HANA

1. [1] Commencez par créer la ressource de topologie HANA.

SAPHanaSR

Exécutez les commandes suivantes sur l’un des nœuds du cluster Pacemaker :

sudo crm configure property maintenance-mode=true

# Replace <placeholders> with your instance number and HANA system ID

sudo crm configure primitive rsc_SAPHanaTopology_<HANA SID>_HDB<instance number> ocf:suse:SAPHanaTopology \
  operations \$id="rsc_sap2_<HANA SID>_HDB<instance number>-operations" \
  op monitor interval="10" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="<HANA SID>" InstanceNumber="<instance number>"

sudo crm configure clone cln_SAPHanaTopology_<HANA SID>_HDB<instance number> rsc_SAPHanaTopology_<HANA SID>_HDB<instance number> \
  meta clone-node-max="1" target-role="Started" interleave="true"

SAPHanaSR-angi

Exécutez les commandes suivantes sur l’un des nœuds du cluster Pacemaker :

sudo crm configure property maintenance-mode=true

# Replace <placeholders> with your instance number and HANA system ID

sudo crm configure primitive rsc_SAPHanaTopology_<HANA SID>_HDB<instance number> ocf:suse:SAPHanaTopology \
  op monitor interval="50" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="<HANA SID>" InstanceNumber="<instance number>"

sudo crm configure clone cln_SAPHanaTopology_<HANA SID>_HDB<instance number> rsc_SAPHanaTopology_<HANA SID>_HDB<instance number> \
  meta clone-node-max="1" interleave="true"

2. [1] Créez ensuite les ressources HANA :

SAPHanaSR

Remarque

Cet article contient des références à des termes que Microsoft n’utilise plus. Lorsque ces termes seront supprimés du logiciel, nous les supprimerons de cet article.

# Replace <placeholders> with your instance number and HANA system ID.

sudo crm configure primitive rsc_SAPHana_<HANA SID>_HDB<instance number> ocf:suse:SAPHana \
  operations \$id="rsc_sap_<HANA SID>_HDB<instance number>-operations" \
  op start interval="0" timeout="3600" \
  op stop interval="0" timeout="3600" \
  op promote interval="0" timeout="3600" \
  op monitor interval="60" role="Master" timeout="700" \
  op monitor interval="61" role="Slave" timeout="700" \
  params SID="<HANA SID>" InstanceNumber="<instance number>" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

# Run the following command if the cluster nodes are running on SLES 12 SP05.
sudo crm configure ms msl_SAPHana_<HANA SID>_HDB<instance number> rsc_SAPHana_<HANA SID>_HDB<instance number> \
  meta notify="true" clone-max="2" clone-node-max="1" \
  target-role="Started" interleave="true"

# Run the following command if the cluster nodes are running on SLES 15 SP03 or later.
sudo crm configure clone msl_SAPHana_<HANA SID>_HDB<instance number> rsc_SAPHana_<HANA SID>_HDB<instance number> \
  meta notify="true" clone-max="2" clone-node-max="1" \
  target-role="Started" interleave="true" promotable="true"

sudo crm resource meta msl_SAPHana_<HANA SID>_HDB<instance number> set priority 100

SAPHanaSR-angi

# Replace <placeholders> with your instance number and HANA system ID. 
sudo crm configure primitive rsc_SAPHanaCon_<HANA SID>_HDB<instance number> ocf:suse:SAPHanaController \
  op start interval="0" timeout="3600" \
  op stop  interval="0" timeout="3600" \
  op promote interval="0" timeout="3600" \
  op demote  interval="0" timeout="320"  \
  op monitor interval="60" role="Promoted" timeout="700" \
  op monitor interval="61" role="Unpromoted" timeout="700" \
  params SID="<HANA SID>" InstanceNumber="<instance number>" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false" \
  meta priority=100

sudo crm configure clone mst_SAPHanaCon_<HANA SID>_HDB<instance number> rsc_SAPHanaCon_<HANA SID>_HDB<instance number> \
  meta clone-node-max="1" interleave="true" promotable="true"

SAPHanaSR-angi ajoute un nouvel agent de ressources SAPHanaFilesystem pour surveiller l’accès en lecture/écriture à /hana/shared/SID. Le système d’exploitation statique monte le filesystem /hana/shared/SID avec chaque hôte ayant des entrées dans /etc/fstab. SAPHanaFilesystem et Pacemaker ne montent pas le filesystem pour HANA.

Nous vous recommandons d’implémenter SAPHanaFilesystem si vous utilisez NFS pour l’emplacement /hana/shared/SID. Lorsque /hana/shared/SID se trouve sur un appareil de bloc, tel qu’un disque managé Azure, l’utilisation de SAPHanaFilesystem est facultative.

# Replace <placeholders> with your instance number and HANA system ID. 
sudo crm configure primitive rsc_SAPHanaFil_<HANA SID>_HDB<instance number> ocf:suse:SAPHanaFilesystem \
  op start interval="0" timeout="10" \
  op stop interval="0" timeout="20" \
  op monitor interval="120" timeout="120" \
  params SID="<HANA SID>" InstanceNumber="<instance number>" ON_FAIL_ACTION="fence"

sudo crm configure clone cln_SAPHanaFil_<HANA SID>_HDB<instance number> rsc_SAPHanaFil_<HANA SID>_HDB<instance number> \
  meta clone-node-max="1" interleave="true"

3. [1] Poursuivez avec les ressources de cluster pour les adresses IP virtuelles, les valeurs par défaut et les contraintes.

SAPHanaSR

# Replace <placeholders> with your instance number, HANA system ID, and the front-end IP address of the Azure load balancer. 
sudo crm configure primitive rsc_ip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
  meta target-role="Started" \
  operations \$id="rsc_ip_<HANA SID>_HDB<instance number>-operations" \
  op monitor interval="10s" timeout="20s" \
  params ip="<front-end IP address>"

sudo crm configure primitive rsc_nc_<HANA SID>_HDB<instance number> azure-lb port=625<instance number> \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0

sudo crm configure group g_ip_<HANA SID>_HDB<instance number> rsc_ip_<HANA SID>_HDB<instance number> rsc_nc_<HANA SID>_HDB<instance number>

sudo crm configure colocation col_saphana_ip_<HANA SID>_HDB<instance number> 4000: g_ip_<HANA SID>_HDB<instance number>:Started \
  msl_SAPHana_<HANA SID>_HDB<instance number>:Master  

sudo crm configure order ord_SAPHana_<HANA SID>_HDB<instance number> Optional: cln_SAPHanaTopology_<HANA SID>_HDB<instance number> \
  msl_SAPHana_<HANA SID>_HDB<instance number>

# Clean up the HANA resources. The HANA resources might have failed because of a known issue.
sudo crm resource cleanup rsc_SAPHana_<HANA SID>_HDB<instance number>

sudo crm configure property priority-fencing-delay=30

sudo crm configure property maintenance-mode=false
sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=5000

SAPHanaSR-angi

# Replace <placeholders> with your instance number, HANA system ID, and the front-end IP address of the Azure load balancer. 
sudo crm configure primitive rsc_ip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
  meta target-role="Started" \
  op monitor interval="10s" timeout="20s" \
  params ip="<front-end IP address>"

sudo crm configure primitive rsc_nc_<HANA SID>_HDB<instance number> azure-lb port=625<instance number> \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0

sudo crm configure group g_ip_<HANA SID>_HDB<instance number> rsc_ip_<HANA SID>_HDB<instance number> rsc_nc_<HANA SID>_HDB<instance number>

sudo crm configure colocation col_saphana_ip_<HANA SID>_HDB<instance number> 4000: g_ip_<HANA SID>_HDB<instance number>:Started \
  mst_SAPHanaCon_<HANA SID>_HDB<instance number>:Promoted  

sudo crm configure order ord_SAPHana_<HANA SID>_HDB<instance number> Optional: cln_SAPHanaTopology_<HANA SID>_HDB<instance number> \
  mst_SAPHanaCon_<HANA SID>_HDB<instance number>

# Clean up the HANA resources. The HANA resources might have failed because of a known issue.
sudo crm resource cleanup rsc_SAPHanaCon_<HANA SID>_HDB<instance number>

sudo crm configure property priority-fencing-delay=30

sudo crm configure property maintenance-mode=false
sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=5000

Important

Nous vous recommandons de définir AUTOMATED_REGISTER sur false uniquement lorsque vous effectuez des tests de basculement complets, afin d’empêcher l’inscription automatique d’une instance principale en tant qu’instance principale ayant échoué. Une fois les tests de basculement terminés, définissez AUTOMATED_REGISTER sur true, de sorte qu’après la prise en charge, la réplication système reprend automatiquement.

Vérifiez que l’état du cluster est OK et que toutes les ressources ont démarré. Il n’importe pas le nœud sur lequel les ressources s’exécutent.

sudo crm_mon -r

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# stonith-sbd     (stonith:external/sbd): Started hn1-db-0
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hn1-db-0 ]
#     Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

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

Dans SAP HANA 2.0 SPS 01 et versions ultérieures, SAP autorise une configuration active/en lecture pour la réplication du système SAP HANA. Dans ce scénario, les systèmes secondaires de la réplication de système SAP HANA peuvent être utilisés activement pour les charges de travail gourmandes en lecture.

Pour prendre en charge cette configuration dans un cluster, une deuxième adresse IP virtuelle est requise pour permettre aux clients d’accéder à la base de données SAP HANA en lecture secondaire. Pour vous assurer que le site de réplication secondaire est toujours accessible après une prise de contrôle, le cluster doit déplacer l’adresse IP virtuelle avec la ressource SAPHana secondaire.

Cette section décrit les étapes supplémentaires requises pour gérer une réplication système active/lecture HANA dans un cluster haute disponibilité SUSE qui utilise une deuxième adresse IP virtuelle.

Avant de continuer, vérifiez que vous avez entièrement configuré le cluster de haute disponibilité SUSE qui gère la base de données SAP HANA, comme décrit dans les sections précédentes.

Configurer l’équilibreur de charge pour la réplication système active/en lecture

Pour suivre des étapes supplémentaires pour provisionner la deuxième adresse IP virtuelle, vérifiez que vous avez configuré Azure Load Balancer comme décrit dans Déployer manuellement des machines virtuelles Linux via le portail Azure.

Pour l’équilibreur de charge standard, effectuez ces étapes supplémentaires sur le même équilibreur de charge que celui que vous avez créé précédemment.

1. Créez un deuxième pool d’adresses IP frontales :
   1. Ouvrez l’équilibrage de charge, sélectionnez le Pool d’adresses IP frontales, puis cliquez sur Ajouter.
   2. Entrez le nom du deuxième pool d’adresses IP frontales (par exemple hana-secondaryIP).
   3. Définissez l’Affectation sur Statique et entrez l’adresse IP (par exemple, 10.0.0.14).
   4. Cliquez sur OK.
   5. Une fois le nouveau pool d’adresses IP frontales créé, notez l’adresse IP frontale.
2. Créez une sonde d’intégrité :
   1. Dans l’équilibreur de charge, sélectionnez sondes d’intégrité, puis sélectionnez Ajouter.
   2. Entrez le nom de la nouvelle sonde d’intégrité (par exemple, hana-secondaryhp).
   3. Sélectionnez TCP en tant que protocole et port 626<numéro d’instance>. Conservez la valeur Intervalle définie sur 5et la valeur seuil non sain définie sur 2.
   4. Cliquez sur OK.
3. Créez les règles d’équilibrage de charge :
   1. Dans l’équilibreur de charge, sélectionnez règles d’équilibrage de charge, puis sélectionnez Ajouter.
   2. Entrez le nom de la nouvelle règle d’équilibrage de charge (par exemple, hana-secondarylb).
   3. 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).
   4. Sélectionnez Ports HA.
   5. Augmenter le délai d’inactivité à 30 minutes.
   6. Assurez-vous que vous activer l'IP flottante.
   7. Cliquez sur OK.

Configurer la réplication système active/en lecture HANA

Les étapes de configuration de la réplication du système HANA sont décrites dans Configurer la réplication système SAP HANA 2.0. Si vous déployez un scénario secondaire en lecture, lorsque vous configurez la réplication système sur le deuxième nœud, exécutez la commande suivante en tant que <SID HANA>adm :

sapcontrol -nr <instance number> -function StopWait 600 10 

hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2> --operationMode=logreplay_readaccess 

Ajouter une ressource d’adresse IP virtuelle secondaire

Vous pouvez configurer la deuxième adresse IP virtuelle et la contrainte de colocation appropriée à l’aide des commandes suivantes :

SAPHanaSR

crm configure property maintenance-mode=true

crm configure primitive rsc_secip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
 meta target-role="Started" \
 operations \$id="rsc_secip_<HANA SID>_HDB<instance number>-operations" \
 op monitor interval="10s" timeout="20s" \
 params ip="<secondary IP address>"

crm configure primitive rsc_secnc_<HANA SID>_HDB<instance number> azure-lb port=626<instance number> \
 op monitor timeout=20s interval=10 \
 meta resource-stickiness=0

crm configure group g_secip_<HANA SID>_HDB<instance number> rsc_secip_<HANA SID>_HDB<instance number> rsc_secnc_<HANA SID>_HDB<instance number>

crm configure colocation col_saphana_secip_<HANA SID>_HDB<instance number> 4000: g_secip_<HANA SID>_HDB<instance number>:Started \
 msl_SAPHana_<HANA SID>_HDB<instance number>:Slave 

crm configure property maintenance-mode=false

SAPHanaSR-angi

crm configure property maintenance-mode=true

crm configure primitive rsc_secip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
 op monitor interval="10s" timeout="20s" \
 params ip="<secondary IP address>"

crm configure primitive rsc_secnc_<HANA SID>_HDB<instance number> azure-lb port=626<instance number> \
 op monitor timeout=20s interval=10 \
 meta resource-stickiness=0

crm configure group g_secip_<HANA SID>_HDB<instance number> rsc_secip_<HANA SID>_HDB<instance number> rsc_secnc_<HANA SID>_HDB<instance number>

crm configure colocation col_saphana_secip_<HANA SID>_HDB<instance number> 4000: g_secip_<HANA SID>_HDB<instance number>:Started \
 mst_SAPHanaCon_<HANA SID>_HDB<instance number>:Unpromoted 

crm configure property maintenance-mode=false

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

sudo crm_mon -r

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# stonith-sbd     (stonith:external/sbd): Started hn1-db-0
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hn1-db-0 ]
#     Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
# Resource Group: g_secip_HN1_HDB03:
#     rsc_secip_HN1_HDB03       (ocf::heartbeat:IPaddr2):        Started hn1-db-1
#     rsc_secnc_HN1_HDB03       (ocf::heartbeat:azure-lb):       Started hn1-db-1

La section suivante décrit l’ensemble classique de tests de basculement à exécuter.

Considérations relatives au test d’un cluster HANA configuré avec une base de données secondaire activée en lecture :

• Lorsque vous migrez la ressource de cluster SAPHana_<HANA SID>_HDB<instance number> vers hn1-db-1, la deuxième adresse IP virtuelle passe à hn1-db-0. Si vous avez configuré AUTOMATED_REGISTER="false" et que la réplication du système HANA n’est pas enregistrée automatiquement, la deuxième adresse IP virtuelle s’exécute sur hn1-db-0, car le serveur est disponible et les services de cluster sont en ligne.

• Lorsque vous testez un incident de serveur, les deuxièmes ressources IP virtuelles (rsc_secip_<HANA SID>_HDB<instance number>) et la ressource de port d’équilibreur de charge Azure (rsc_secnc_<HANA SID>_HDB<instance number>) s’exécutent sur le serveur principal en même temps que les ressources d’adresse IP virtuelle principale. Pendant que le serveur secondaire est arrêté, les applications connectées à une base de données HANA en lecture se connectent à la base de données HANA principale. Le comportement est attendu, car vous ne souhaitez pas que les applications connectées à une base de données HANA compatible en lecture soient inaccessibles pendant que le serveur secondaire n’est pas disponible.

• Lorsque le serveur secondaire est disponible et que les services de cluster sont en ligne, les deuxièmes ressources d’adresse IP virtuelle et de port se déplacent automatiquement vers le serveur secondaire, même si la réplication du système HANA peut ne pas être inscrite en tant que serveur secondaire. Veillez à inscrire la base de données HANA secondaire en lecture activée avant de démarrer les services de cluster sur ce serveur. Vous pouvez configurer la ressource de cluster d’instance HANA pour inscrire automatiquement le serveur secondaire en définissant le paramètre AUTOMATED_REGISTER="true".

• Pendant le basculement et le secours, les connexions existantes pour les applications, qui utilisent ensuite la deuxième adresse IP virtuelle pour se connecter à la base de données HANA, peuvent être interrompues.

Tester la configuration du cluster

Cette section explique comment vous pouvez tester votre configuration. Chaque test suppose que vous êtes connecté en tant que racine et que le maître SAP HANA s’exécute sur la machine virtuelle hn1-db-0.

Tester la migration

Avant de démarrer le test, assurez-vous que Pacemaker n’a pas d’action ayant échoué (exécuter crm_mon -r), qu’il n’existe aucune contrainte d’emplacement inattendue (par exemple, les restes d’un test de migration) et que HANA est en état de synchronisation, par exemple en exécutant SAPHanaSR-showAttr.

SAPHanaSR

hn1-db-0:~ # SAPHanaSR-showAttr
Sites    srHook
----------------
SITE2    SOK
Global cib-time
--------------------------------
global Mon Aug 13 11:26:04 2018
Hosts    clone_state lpa_hn1_lpt node_state op_mode   remoteHost    roles                            score site  srmode sync_state version                vhost
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED    1534159564  online     logreplay nws-hana-vm-1 4:P:master1:master:worker:master 150   SITE1 sync   PRIM       2.00.030.00.1522209842 nws-hana-vm-0
hn1-db-1 DEMOTED     30          online     logreplay nws-hana-vm-0 4:S:master1:master:worker:master 100   SITE2 sync   SOK        2.00.030.00.1522209842 nws-hana-vm-1

SAPHanaSR-angi

hn1-db-0:~ # SAPHanaSR-showAttr
Global cib-update dcid prim      sec sid topology
--------------------------------------------------
global 0.130728.2 1    SITE1 -   HN1 ScaleUp

Resource                      promotable
-----------------------------------------
mst_SAPHanaCon_HN1_HDB03      true
cln_SAPHanaTopology_HN1_HDB03

Site        lpt        lss mns      opMode    srHook srMode srPoll srr
-----------------------------------------------------------------------
SITE1       1722604101 4   hn1-db-0 logreplay PRIM   sync   PRIM   P
SITE2       30         4   hn1-db-1 logreplay SWAIT  sync   SOK    S

Host     clone_state roles                        score site    sra srah version     vhost
---------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED    master1:master:worker:master 150   SITE1   -   -    2.00.074.00 hn1-db-0
hn1-db-1 DEMOTED     master1:master:worker:master 100   SITE2       -    2.00.074.00 hn1-db-1

Host     clone_state roles                        score site      sra srah version     vhost
------------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED    master1:master:worker:master 150   SITE1     -   -    2.00.074.00 hn1-db-0
hn1-db-1                                                SITE2                          hn1-db-1

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

crm resource move msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1 force

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 crm_mon -r ressemble à cet exemple :

Online: [ hn1-db-0 hn1-db-1 ]

Full list of resources:
stonith-sbd     (stonith:external/sbd): Started hn1-db-1
 Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
     Started: [ hn1-db-0 hn1-db-1 ]
 Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
     Masters: [ hn1-db-1 ]
     Stopped: [ hn1-db-0 ]
 Resource Group: g_ip_HN1_HDB03
     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
Failed Actions:
* rsc_SAPHana_HN1_HDB03_start_0 on hn1-db-0 'not running' (7): call=84, status=complete, exitreason='none',
    last-rc-change='Mon Aug 13 11:31:37 2018', queued=0ms, exec=2095ms

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

su - <hana sid>adm

# Stop the HANA instance, just in case it is running
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> sapcontrol -nr <instance number> -function StopWait 600 10
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>

La migration crée des contraintes d’emplacement qui doivent être de nouveau supprimées :

# Switch back to root and clean up the failed state
exit
hn1-db-0:~ # crm resource clear msl_SAPHana_<HANA SID>_HDB<instance number>

Vous devez également nettoyer l’état de la ressource du nœud secondaire :

hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0

Surveillez l’état de la ressource HANA à l’aide de crm_mon -r. Lorsque HANA est démarré sur hn1-db-0, la sortie ressemble à cet exemple :

Online: [ hn1-db-0 hn1-db-1 ]

Full list of resources:
stonith-sbd     (stonith:external/sbd): Started hn1-db-1
 Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
     Started: [ hn1-db-0 hn1-db-1 ]
 Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
     Masters: [ hn1-db-1 ]
     Slaves: [ hn1-db-0 ]
 Resource Group: g_ip_HN1_HDB03
     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

Blocage de la communication réseau

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

Online: [ hn1-db-0 hn1-db-1 ]

Full list of resources:
stonith-sbd     (stonith:external/sbd): Started hn1-db-1
 Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
     Started: [ hn1-db-0 hn1-db-1 ]
 Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
     Masters: [ hn1-db-1 ]
     Slaves: [ hn1-db-0 ]
 Resource Group: g_ip_HN1_HDB03
     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

Exécutez une 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 existe un risque de scénario fractionné-cerveau. Dans de telles situations, les nœuds de cluster essaient de se clôturer simultanément, ce qui entraîne une course de clôture.

Lors de la configuration d’un appareil d’escrime, il est recommandé de configurer pcmk_delay_max propriété. Ainsi, dans le cas d'un scénario de cerveau divisé, le cluster introduit un délai aléatoire jusqu'à la valeur pcmk_delay_max, à l'action de clôture sur chaque nœud. Le nœud avec le délai le plus court est sélectionné pour l’escrime.

En outre, pour vous assurer que le nœud exécutant le maître HANA est prioritaire et gagne la course de clôture dans un scénario de fractionnement du cerveau, il est recommandé de définir priority-fencing-delay propriété dans la configuration du cluster. En activant la propriété priority-fencing-delay, le cluster peut introduire un délai supplémentaire dans l’action d’escrime spécifiquement sur le nœud hébergeant la ressource principale HANA, ce qui permet au nœud de gagner la course de clôture.

Exécutez la commande ci-dessous 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’isolation SBD

Vous pouvez tester la configuration de SBD en tuant le processus d’inquisitor :

hn1-db-0:~ # ps aux | grep sbd
root       1912  0.0  0.0  85420 11740 ?        SL   12:25   0:00 sbd: inquisitor
root       1929  0.0  0.0  85456 11776 ?        SL   12:25   0:00 sbd: watcher: /dev/disk/by-id/scsi-360014056f268462316e4681b704a9f73 - slot: 0 - uuid: 7b862dba-e7f7-4800-92ed-f76a4e3978c8
root       1930  0.0  0.0  85456 11776 ?        SL   12:25   0:00 sbd: watcher: /dev/disk/by-id/scsi-360014059bc9ea4e4bac4b18808299aaf - slot: 0 - uuid: 5813ee04-b75c-482e-805e-3b1e22ba16cd
root       1931  0.0  0.0  85456 11776 ?        SL   12:25   0:00 sbd: watcher: /dev/disk/by-id/scsi-36001405b8dddd44eb3647908def6621c - slot: 0 - uuid: 986ed8f8-947d-4396-8aec-b933b75e904c
root       1932  0.0  0.0  90524 16656 ?        SL   12:25   0:00 sbd: watcher: Pacemaker
root       1933  0.0  0.0 102708 28260 ?        SL   12:25   0:00 sbd: watcher: Cluster
root      13877  0.0  0.0   9292  1572 pts/0    S+   12:27   0:00 grep sbd

hn1-db-0:~ # kill -9 1912

Le nœud de cluster <HANA SID>-db-<database 1> redémarre. Le service Pacemaker peut ne pas redémarrer. Assurez-vous que vous la recommencez.

Tester un basculement manuel

Vous pouvez tester un basculement manuel en arrêtant le service Pacemaker sur le nœud hn1-db-0 :

service pacemaker stop

Après le basculement, vous pouvez démarrer de nouveau le service. Si vous définissez AUTOMATED_REGISTER="false", la ressource SAP HANA sur le nœud hn1-db-0 ne parvient pas à démarrer comme secondaire.

Dans ce cas, configurez l’instance HANA comme secondaire en exécutant cette commande :

service pacemaker start
su - <hana sid>adm

# Stop the HANA instance, just in case it is running
sapcontrol -nr <instance number> -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1> 

# Switch back to root and clean up the failed state
exit
crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0

Tests SUSE

Important

Assurez-vous que le système d’exploitation que vous sélectionnez est certifié SAP pour SAP HANA sur les types de machines virtuelles spécifiques que vous envisagez d’utiliser. Vous pouvez rechercher les types de machines virtuelles certifiées SAP HANA et leurs versions de système d’exploitation sur la page Plateformes IaaS certifiées SAP HANA. Vérifiez que vous examinez les détails du type de machine virtuelle que vous envisagez d’utiliser pour obtenir la liste complète des versions de système d’exploitation prises en charge par SAP HANA pour ce type de machine virtuelle.

Exécutez tous les cas de test répertoriés dans le guide du scénario optimisé pour les performances SAP HANA SR ou dans le guide du scénario optimisé pour les coûts SAP HANA SR, en fonction de votre scénario. Vous trouverez les guides répertoriés dans SLES pour les meilleures pratiques SAP.

Les tests suivants sont une copie des tests décrits dans le guide « SAP HANA SR Performance Optimized Scenario SUSE Linux Enterprise Server for SAP Applications 12 SP1 » (Scénario à performances optimisées de réplication système de SAP HANA SUSE Linux Enterprise Server for SAP Applications 12 SP1). Pour une version à jour, lisez également le guide lui-même. Vérifiez toujours que HANA est synchronisé avant de démarrer le test et vérifiez que la configuration Pacemaker est correcte.

Dans les descriptions de test suivantes, nous supposons PREFER_SITE_TAKEOVER="true" et AUTOMATED_REGISTER="false".

Remarque

Les tests suivants sont conçus pour être exécutés en séquence. Chaque test dépend de l’état de sortie du test précédent.

1. Test 1 : Arrêtez la base de données primaire sur le nœud 1.

   État de la ressource avant de commencer le test :

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

   Exécutez les commandes suivantes en tant que <hana sid>adm sur le nœud hn1-db-0 :

   hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> HDB stop
   

   Pacemaker détecte l’instance HANA arrêtée et bascule vers l’autre nœud. Une fois le basculement terminé, l’instance HANA sur le nœud hn1-db-0 est arrêtée, car Pacemaker n’inscrit pas automatiquement le nœud en tant que nœud secondaire HANA.

   Exécutez les commandes suivantes pour inscrire le nœud hn1-db-0 en tant que nœud secondaire et nettoyer la ressource ayant échoué :

   hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>
   
   # run as root
   hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0
   

   État de la ressource après le test :

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-1 ]
      Slaves: [ hn1-db-0 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
   

2. Test 2 : Arrêtez la base de données primaire sur le nœud 2.

   État de la ressource avant de commencer le test :

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-1 ]
      Slaves: [ hn1-db-0 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
   

   Exécutez les commandes suivantes en tant que <hana sid>adm sur le nœud hn1-db-1 :

   hn1adm@hn1-db-1:/usr/sap/HN1/HDB01> HDB stop
   

   Pacemaker détecte l’instance HANA arrêtée et bascule vers l’autre nœud. Une fois le basculement terminé, l’instance HANA sur le nœud hn1-db-1 est arrêtée, car Pacemaker n’inscrit pas automatiquement le nœud en tant que nœud secondaire HANA.

   Exécutez les commandes suivantes pour inscrire le nœud hn1-db-1 en tant que nœud secondaire et nettoyer la ressource ayant échoué :

   hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>
   
   # run as root
   hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1
   

   État de la ressource après le test :

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

3. Test 3 : Plantez la base de données primaire sur le nœud 1.

   État de la ressource avant de commencer le test :

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

   Exécutez les commandes suivantes en tant que <hana sid>adm sur le nœud hn1-db-0 :

   hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> HDB kill-9
   

   Pacemaker détecte l’instance HANA tuée et bascule vers l’autre nœud. Une fois le basculement terminé, l’instance HANA sur le nœud hn1-db-0 est arrêtée, car Pacemaker n’inscrit pas automatiquement le nœud en tant que nœud secondaire HANA.

   Exécutez les commandes suivantes pour inscrire le nœud hn1-db-0 en tant que nœud secondaire et nettoyer la ressource ayant échoué :

   hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>
   
   # run as root
   hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0
   

   État de la ressource après le test :

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-1 ]
      Slaves: [ hn1-db-0 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
   

4. Test 4 : Plantez la base de données primaire sur le nœud 2.

   État de la ressource avant de commencer le test :

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-1 ]
      Slaves: [ hn1-db-0 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
   

   Exécutez les commandes suivantes en tant que <hana sid>adm sur le nœud hn1-db-1 :

   hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB kill-9
   

   Pacemaker détecte l’instance HANA tuée et bascule vers l’autre nœud. Une fois le basculement terminé, l’instance HANA sur le nœud hn1-db-1 est arrêtée, car Pacemaker n’inscrit pas automatiquement le nœud en tant que nœud secondaire HANA.

   Exécutez les commandes suivantes pour inscrire le nœud hn1-db-1 en tant que nœud secondaire et nettoyer la ressource ayant échoué.

   hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>
   
   # run as root
   hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1
   

   État de la ressource après le test :

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

5. Test 5 : Plantez le nœud de site principal (nœud 1).

   État de la ressource avant de commencer le test :

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

   Exécutez les commandes suivantes en tant que racine sur le nœud hn1-db-0 :

   hn1-db-0:~ #  echo 'b' > /proc/sysrq-trigger
   

   Pacemaker détecte le nœud de cluster tué et clôture le nœud. Lorsque le nœud est clôturé, Pacemaker déclenche une prise de contrôle de l’instance HANA. Lorsque le nœud délimité est redémarré, Pacemaker ne démarre pas automatiquement.

   Exécutez les commandes suivantes pour démarrer Pacemaker, nettoyez les messages SBD du nœud hn1-db-0, inscrivez le nœud hn1-db-0 en tant que nœud secondaire et nettoyez la ressource ayant échoué :

   # run as root
   # list the SBD device(s)
   hn1-db-0:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
   # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"
   
   hn1-db-0:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-0 clear
   
   hn1-db-0:~ # systemctl start pacemaker
   
   # run as <hana sid>adm
   hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>
   
   # run as root
   hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0
   

   État de la ressource après le test :

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-1 ]
      Slaves: [ hn1-db-0 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
   

6. Test 6 : Plantez le nœud de site secondaire (nœud 2).

   État de la ressource avant de commencer le test :

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-1 ]
      Slaves: [ hn1-db-0 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
   

   Exécutez les commandes suivantes en tant que racine sur le nœud hn1-db-1 :

   hn1-db-1:~ #  echo 'b' > /proc/sysrq-trigger
   

   Pacemaker détecte le nœud de cluster tué et clôture le nœud. Lorsque le nœud est clôturé, Pacemaker déclenche une prise de contrôle de l’instance HANA. Lorsque le nœud délimité est redémarré, Pacemaker ne démarre pas automatiquement.

   Exécutez les commandes suivantes pour démarrer Pacemaker, nettoyez les messages SBD du nœud hn1-db-1, inscrivez le nœud hn1-db-1 en tant que nœud secondaire et nettoyez la ressource ayant échoué :

   # run as root
   # list the SBD device(s)
   hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
   # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"
   
   hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear
   
   hn1-db-1:~ # systemctl start pacemaker
   
   # run as <hana sid>adm
   hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>
   
   # run as root
   hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1
   

   État de la ressource après le test :

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   </code></pre>
   

7. Test 7 : Arrêtez la base de données secondaire sur le nœud 2.

   État de la ressource avant de commencer le test :

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

   Exécutez les commandes suivantes en tant que <hana sid>adm sur le nœud hn1-db-1 :

   hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB stop
   

   Pacemaker détecte l’instance HANA arrêtée et marque la ressource comme ayant échoué sur le nœud hn1-db-1. Pacemaker redémarre automatiquement l’instance HANA.

   Exécutez la commande suivante pour nettoyer l’état d’échec :

   # run as root
   hn1-db-1>:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1
   

   État de la ressource après le test :

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

8. Test 8 : Plantez la base de données secondaire sur le nœud 2.

   État de la ressource avant de commencer le test :

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

   Exécutez les commandes suivantes en tant que <hana sid>adm sur le nœud hn1-db-1 :

   hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB kill-9
   

   Pacemaker détecte l’instance HANA tuée et marque la ressource comme ayant échoué sur le nœud hn1-db-1. Exécutez la commande suivante pour nettoyer l’état d’échec. Pacemaker redémarre ensuite automatiquement l’instance HANA.

   # run as root
   hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> HN1-db-1
   

   État de la ressource après le test :

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

9. Test 9 : Plantez le nœud de site secondaire (nœud 2) qui exécute la base de données HANA secondaire.

   État de la ressource avant de commencer le test :

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

   Exécutez les commandes suivantes en tant que racine sur le nœud hn1-db-1 :

   hn1-db-1:~ # echo b > /proc/sysrq-trigger
   

   Pacemaker détecte le nœud de cluster tué et la clôture du nœud. Lorsque le nœud délimité est redémarré, Pacemaker ne démarre pas automatiquement.

   Exécutez les commandes suivantes pour démarrer Pacemaker, nettoyez les messages SBD du nœud hn1-db-1 et nettoyez la ressource ayant échoué :

   # run as root
   # list the SBD device(s)
   hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
   # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"
   
   hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear
   
   hn1-db-1:~ # systemctl start pacemaker  
   
   hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1
   

   État de la ressource après le test :

   Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
      Started: [ hn1-db-0 hn1-db-1 ]
   Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
      Masters: [ hn1-db-0 ]
      Slaves: [ hn1-db-1 ]
   Resource Group: g_ip_HN1_HDB03
      rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
      rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
   

10. Test 10 : Planter le serveur d’index de base de données primaire

    Ce test n’est pertinent que lorsque vous avez configuré le hook susChkSrv comme indiqué dans Implémenter des agents de ressources HANA.

    État de la ressource avant de commencer le test :

    Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
       Started: [ hn1-db-0 hn1-db-1 ]
    Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
       Masters: [ hn1-db-0 ]
       Slaves: [ hn1-db-1 ]
    Resource Group: g_ip_HN1_HDB03
       rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
       rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
    

    Exécutez les commandes suivantes en tant que racine sur le nœud hn1-db-0 :

    hn1-db-0:~ # killall -9 hdbindexserver
    

    Lorsque l’indexserver est arrêté, le hook susChkSrv détecte l’évènement et déclenche une action pour clôturer le nœud « hn1-db-0 » et lancer un processus de prise de contrôle.

    Exécutez les commandes suivantes pour inscrire le nœud hn1-db-0 en tant que nœud secondaire et nettoyer la ressource ayant échoué :

    # run as <hana sid>adm
    hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>
    
    # run as root
    hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0
    

    État de la ressource après le test :

    Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
       Started: [ hn1-db-0 hn1-db-1 ]
    Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
       Masters: [ hn1-db-1 ]
       Slaves: [ hn1-db-0 ]
    Resource Group: g_ip_HN1_HDB03
       rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
       rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
    

    Vous pouvez exécuter un cas de test comparable en provoquant le blocage du serveur d’index sur le nœud secondaire. En cas d’incident de l’indexserver, le hook susChkSrv reconnaît l’occurrence et lance une action pour clôturer le nœud secondaire.

É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