Haute disponibilité pour système scale-out SAP HANA avec montée en puissance parallèle avec HSR sur SUSE Linux Enterprise Server

Article
06/18/2024

Cet article explique comment déployer un système SAP HANA à haut niveau de disponibilité dans une configuration de montée en charge avec réplication de système HANA (HSR) et Pacemaker sur les machines virtuelles Azure SUSE Linux Enterprise Server. Les systèmes de fichiers partagés dans l’architecture présentée sont montés sur NFS et sont fournis par Azure NetApp Files ou le partage NFS sur Azure Files.

Dans les exemples de configuration, de commandes d’installation, etc., l’instance HANA est 03 et l’ID de système HANA est HN1.

Avant de commencer, reportez-vous aux notes et documents SAP suivants :

Documentation Azure NetApp Files
Documentation Azure Files
La note SAP 1928533 comprend :
- une 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 logiciels SAP pris en charge et les combinaisons entre système d’exploitation et base de données
- la version du noyau SAP requise pour Windows et Linux sur Microsoft Azure
Note SAP 2015553 : répertorie les conditions préalables au déploiement de logiciels SAP pris en charge par SAP sur Azure
Note SAP 2205917 : contient les paramètres de système d’exploitation recommandés pour SUSE Linux Enterprise Server pour les applications SAP
Note SAP 1944799 : contient des instructions SAP pour SUSE Linux Enterprise Server pour les applications SAP
Note SAP 2178632 : contient des informations détaillées sur toutes les métriques de supervision rapportées pour SAP dans Azure
Note SAP 2191498 : contient la version requise de l’agent hôte SAP pour Linux dans Azure
Note SAP 2243692 : contient des informations sur les licences SAP sur Linux dans Azure
Note SAP 1984787 : contient des informations générales sur SUSE Linux Enterprise Server 12
Note SAP 1999351 : contient des informations supplémentaires relatives à la résolution des problèmes pour l’extension d’analyse Azure améliorée pour SAP
Note SAP 1900823 : contient des informations sur les exigences de stockage SAP HANA
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
Déploiement SGBD de machines virtuelles Azure pour SAP sur Linux
Guides sur les meilleures pratiques de haute disponibilité SAP pour SUSE : contient toutes les informations nécessaires pour configurer la haute disponibilité NetWeaver et la réplication de système SAP HANA localement (à utiliser comme ligne de base générale ; elles fournissent des informations beaucoup plus détaillées)
Notes de publication de SUSE High Availability Extension 12 SP5
La gestion du partage NFS échoue lors de la réplication d’un cluster haute disponibilité SUSE pour système HANA
Volumes NFS v4.1 sur Azure NetApp Files pour SAP HANA

Vue d’ensemble

Une méthode pour obtenir une haute disponibilité HANA pour les installations de montée en charge HANA consiste à configurer la réplication de système HANA et à protéger la solution avec le cluster Pacemaker afin d’autoriser le basculement automatique. En cas de défaillance d’un nœud actif, le cluster bascule les ressources HANA vers l’autre site.
La configuration présentée montre trois nœuds HANA sur chaque site, ainsi qu’un nœud de créateur de majorité pour empêcher le scénario de split-brain. Les instructions peuvent être adaptées pour inclure plus de machines virtuelles en tant que nœuds de base de données HANA.

Le système de fichiers partagé HANA /hana/shared dans l’architecture présentée peut être fourni par Azure NetApp Files ou le partage NFS sur Azure Files. Le système de fichiers partagé HANA est monté sur NFS sur chaque nœud HANA dans le même site de réplication système HANA. Les systèmes de fichiers /hana/data et /hana/log sont des systèmes de fichiers locaux et ne sont pas partagés entre les nœuds de base de données HANA. SAP HANA sera installé en mode non partagé.

Pour des configurations de stockage recommandées SAP HANA, consultez Configurations de stockage SAP HANA des machines virtuelles Azure.

Important

Si vous déployez tous les systèmes de fichiers HANA sur Azure NetApp Files pour des systèmes de production pour lesquels les performances sont essentielles, nous vous recommandons d’évaluer et d’envisager d’utiliser le groupe de volumes d’application Azure NetApp Files pour SAP HANA.

Avertissement

Le déploiement de /hana/data et de /hana/log sur NFS sur Azure Files n’est pas pris en charge.

Dans le diagramme ci-dessus, trois sous-réseaux sont représentés au sein d’un réseau virtuel Azure, qui suit les recommandations de réseau SAP HANA :

pour la communication client - client 10.23.0.0/24
pour la communication interne HANA entre les nœuds - inter 10.23.1.128/26
pour la réplication de système HANA - hsr 10.23.1.192/26

Étant donné que /hana/data et /hana/log sont déployés sur des disques locaux, il n’est pas nécessaire de déployer un sous-réseau et des cartes réseau virtuelles distincts pour la communication avec le stockage.

Si vous utilisez Azure NetApp Files, les volumes NFS pour /hana/shared sont déployés dans un sous-réseau distinct, délégué à Azure NetApp Files : anf 10.23.1.0/26.

Préparer l’infrastructure

Les instructions suivantes supposent que vous avez déjà créé le groupe de ressources, le réseau virtuel Azure avec les trois sous-réseaux de réseau Azure : client, inter et hsr.

Déployer des machines virtuelles Linux via le Portail Azure

Déployer les machines virtuelles Azure.

Pour la configuration présentée dans ce document, déployez sept machines virtuelles :
- trois machines virtuelles à servir de nœuds de base de données HANA pour le site de réplication HANA 1 : hana-s1-db1, hana-s1-db2 et hana-s1-db3
- trois machines virtuelles à servir de nœuds de base de données HANA pour le site de réplication HANA 2 : hana-s2-db1, hana-s2-db2 et hana-s2-db3
- une petite machine virtuelle à servir de créateur de majorité : hana-s-mm
Les machines virtuelles, déployées en tant que nœuds HANA de base de données SAP doivent être certifiées par SAP pour HANA, telles qu’elles sont publiées dans le Répertoire matériel SAP HANA. Lors du déploiement des nœuds de base de données HANA, assurez-vous que Accelerated Network (réseau accélérée) est sélectionné.

Pour le nœud de créateur de majorité, vous pouvez déployer une petite machine virtuelle, car cette machine virtuelle n’exécute aucune des ressources SAP HANA. La machine virtuelle de créateur de majorité est utilisée dans la configuration du cluster pour obtenir un nombre impair de nœuds de cluster dans un scénario de split-brain. La machine virtuelle de créateur de majorité n’a besoin que d’une seule interface réseau virtuelle dans le sous-réseau client dans cet exemple.

Déployer des disques managés locaux pour /hana/data et /hana/log. La configuration de stockage minimale recommandée pour /hana/data et /hana/log est décrite dans Configurations de stockage SAP HANA des machines virtuelles Azure.

Déployez l’interface réseau principale pour chaque machine virtuelle dans le sous-réseau du réseau virtuel client.
Lorsque la machine virtuelle est déployée via le Portail Azure, le nom de l’interface réseau est généré automatiquement. Dans ces instructions, par soucis de simplicité, nous allons faire référence aux interfaces réseau principales générées automatiquement, qui sont attachées au sous-réseau client du réseau virtuel Azure, en tant que hana-s1-db1-client, hana-s1-db2-client, hana-s1-db3-client, etc.
Important
- Vérifiez que le système d’exploitation que vous sélectionnez est certifié SAP pour SAP HANA sur les types de machine virtuelle spécifiques que vous utilisez. Pour obtenir la liste des types de machines virtuelles certifiés SAP HANA et des versions de système d’exploitation correspondants, accédez au site SAP HANA Certified IaaS platforms. Cliquez sur les détails du type de machine virtuelle répertorié pour obtenir la liste complète des versions de système d’exploitation prises en charge par SAP HANA pour ce type.
- Si vous choisissez de déployer /hana/shared sur NFS sur Azure Files, nous vous recommandons de déployer sur SLES 15 SP2 et versions ultérieures.
Créez six interfaces réseau, une pour chaque machine virtuelle de base de données HANA, dans le sous-réseau inter du réseau virtuel (dans cet exemple, hana-s1-db1-inter, hana-s1-db2-inter, hana-s1-db3-inter, hana-s2-db1-inter, hana-s2-db2-inter, et hana-s2-db3-inter).
Créez six interfaces réseau, une pour chaque machine virtuelle de base de données HANA, dans le sous-réseau hsr du réseau virtuel (dans cet exemple, hana-s1-db1-hsr, hana-s1-db2-hsr, hana-s1-db3-hsr, hana-s2-db1-hsr, hana-s2-db2-hsr, et hana-s2-db3-hsr).
Attachez les interfaces réseau virtuelles nouvellement créées aux machines virtuelles correspondantes :
1. Accédez à la machine virtuelle sur le Portail Azure.
2. Dans le volet gauche, sélectionnez Machines virtuelles. Filtrez sur le nom de la machine virtuelle (par exemple, hana-s1-db1), puis sélectionnez la machine virtuelle.
3. Dans le volet Vue d’ensemble, sélectionnez Arrêter pour libérer la machine virtuelle.
4. Sélectionnez Mise en réseau, puis attachez l’interface réseau. Dans la liste déroulante sous Attacher l’interface réseau, sélectionnez les interfaces réseau déjà créées pour les sous-réseaux inter et hsr.
5. Sélectionnez Enregistrer.
6. Répétez les étapes b à e pour les machines virtuelles restantes (dans notre exemple, hana-s1-db2, hana-s1-db3, hana-s2-db1, hana-s2-db2 et hana-s2-db3).
7. Laissez les machines virtuelles dans l’état arrêté pour l’instant. Ensuite, nous allons activer Mise en réseau accélérée pour toutes les interfaces réseau qui viennent d’être attachées.

Activez la mise en réseau accélérée pour les interfaces réseau supplémentaires pour les sous-réseaux inter et hsr en procédant comme suit :

Ouvrez Azure Cloud Shell dans le Portail Azure.

Exécutez les commandes suivantes pour activer la mise en réseau accélérée pour les interfaces réseau supplémentaires, qui sont attachées aux sous-réseaux inter et hsr.

az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-inter --accelerated-networking true

az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-hsr --accelerated-networking true

Démarrer les machines virtuelles de base de données HANA

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.

Remarque

Pour le scale-out HANA, sélectionnez la carte réseau du sous-réseau client lors de l’ajout des machines virtuelles dans le pool de back-ends.
L’ensemble complet de commandes dans Azure CLI et PowerShell ajoute les machines virtuelles avec une carte réseau principale dans le pool de back-ends.

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 :

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.
Pool back-end : créez un pool back-end et ajoutez des machines virtuelles de base de données.
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.

L’ensemble complet du code Azure CLI affiche la configuration de l’équilibreur de charge, qui inclut deux machines virtuelles dans le pool de back-ends. En fonction du nombre de machines virtuelles dans votre scale-out HANA, vous pouvez ajouter d’autres machines virtuelles dans le pool de back-ends.

# 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 l’intégralité du code CLI

# 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

L’ensemble complet du code PowerShell affiche la configuration de l’équilibreur de charge, qui inclut deux machines virtuelles dans le pool de back-ends. En fonction du nombre de machines virtuelles dans votre scale-out HANA, vous pouvez ajouter d’autres machines virtuelles dans le pool de back-ends.

# 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 l’intégralité du code PowerShell

# 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

Remarque

Lorsque des machines virtuelles sans adresse IP publique sont placées dans le pool principal d’Azure Standard Load Balancer interne (aucune adresse IP publique), il n’y a pas de connectivité Internet sortante, sauf si une configuration supplémentaire est effectuée pour autoriser le routage vers des points de terminaison publics. Pour savoir plus en détails comment bénéficier d’une connectivité sortante, voir Connectivité des points de terminaison publics pour les machines virtuelles avec Azure Standard Load Balancer dans les scénarios de haute disponibilité SAP.

Important

N’activez pas les timestamps TCP sur des machines virtuelles Azure placées derrière Azure Load Balancer. L’activation des timestamps TCP entraîne l’échec des sondes d’intégrité. Affectez la valeur 0 au paramètre net.ipv4.tcp_timestamps. Pour plus d’informations, consultez Sondes d’intégrité de l’Équilibreur de charge et 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?.

Déployer NFS

Deux options permettent de déployer le NFS natif Azure pour /hana/shared. Vous pouvez déployer un volume NFS sur Azure NetApp Files ou le partage NFS sur Azure Files. Azure Files prend en charge le protocole NFSv4.1, NFS sur NetApp Azure Files prend en charge NFSv4.1 et NFSv3.

Les sections suivantes décrivent les étapes de déploiement de NFS : vous devez sélectionner une seule des options.

Conseil

Vous avez choisi de déployer /hana/shared sur le partage NFS sur Azure Files ou le volume NFS sur Azure NetApp Files.

Déployer l’infrastructure Azure NetApp Files

Déployez des volumes Azure NetApp Files pour le système de fichiers /hana/shared. Vous avez besoin d’un volume /hana/shared distinct pour chaque site de réplication du système HANA. Pour plus d’informations, consultez Configurer l’infrastructure Azure NetApp Files.

Dans cet exemple, les volumes Azure NetApp Files suivants ont été utilisés :

volume HN1-shared-s1 (nfs://10.23.1.7/HN1-shared-s1)
volume HN1-shared-s2 (nfs://10.23.1.7/HN1-shared-s2)

Déployer le NFS sur l’infrastructure Azure Files

Déployez des partages NFS Azure Files pour le système de fichiers /hana/shared. Vous avez besoin d’un partage NFS Azure Files /hana/shared distinct pour chaque site de réplication de système HANA. Pour plus d’informations, consultez Comment créer un partage NFS.

Dans cet exemple, les partages NFS Azure Files suivants ont été utilisés :

share hn1-shared-s1 (sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1)
share hn1-shared-s2 (sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2)

Configuration et préparation du système d’exploitation

Les instructions des sections suivantes sont précédées de l’une des abréviations suivantes :

[A] : applicable à tous les nœuds, y compris majority maker
[AH] : applicable à tous les nœuds de base de données HANA
[M] : applicable au nœud majority maker uniquement
[AH1] : applicable à tous les nœuds de base de données HANA sur le SITE 1
[AH2] : applicable à tous les nœuds de base de données HANA sur le SITE 2
[1] : applicable uniquement au nœud de base de données HANA 1, SITE 1
[2] : applicable uniquement au nœud de base de données HANA 1, SITE 2

Configurez et préparez votre système d’exploitation en procédant comme suit :

[A] Conservez les fichiers hôtes sur les machines virtuelles. Incluez des entrées pour tous les sous-réseaux. Les entrées suivantes ont été ajoutées à /etc/hosts pour cet exemple.

# Client subnet
10.23.0.19      hana-s1-db1
10.23.0.20      hana-s1-db2
10.23.0.21      hana-s1-db3
10.23.0.22      hana-s2-db1
10.23.0.23      hana-s2-db2
10.23.0.24      hana-s2-db3
10.23.0.25      hana-s-mm    

# Internode subnet
10.23.1.132     hana-s1-db1-inter
10.23.1.133     hana-s1-db2-inter
10.23.1.134     hana-s1-db3-inter
10.23.1.135     hana-s2-db1-inter
10.23.1.136     hana-s2-db2-inter
10.23.1.137     hana-s2-db3-inter

# HSR subnet
10.23.1.196     hana-s1-db1-hsr
10.23.1.197     hana-s1-db2-hsr
10.23.1.198     hana-s1-db3-hsr
10.23.1.199     hana-s2-db1-hsr
10.23.1.200     hana-s2-db2-hsr
10.23.1.201     hana-s2-db3-hsr

[A] Créez un fichier de configuration /etc/sysctl.d/ms-az.conf avec les paramètres de configuration Microsoft Azure.
```
vi /etc/sysctl.d/ms-az.conf

# Add the following entries in the configuration file
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv4.tcp_max_syn_backlog = 16348
net.ipv4.conf.all.rp_filter = 0
sunrpc.tcp_slot_table_entries = 128
vm.swappiness=10
```
Conseil

Évitez de définir net.ipv4.ip_local_port_range et net.ipv4.ip_local_reserved_ports explicitement dans les fichiers config sysctl pour permettre à l’agent hôte SAP de gérer les plages de ports. Pour plus d’informations, consultez la note SAP 2382421.
[A] SUSE offre des agents de ressource spéciaux pour SAP HANA et des agents par défaut pour un scale-up SAP HANA sont installés. Désinstallez les packages pour le scale-up, s’ils sont installés, puis installez les packages pour le scénario de scale-out SAP HANA. L’étape doit être effectuée sur toutes les machines virtuelles de cluster, y compris le créateur de majorité.

Notes

SAPHanaSR-ScaleOut version 0.181 ou ultérieure doit être installé.
```
# Uninstall scale-up packages and patterns
sudo zypper remove patterns-sap-hana
sudo zypper remove SAPHanaSR SAPHanaSR-doc yast2-sap-ha

# Install the scale-out packages and patterns
sudo zypper in SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc 
sudo zypper in -t pattern ha_sles
```
[AH] Préparez les machines virtuelles : appliquez les paramètres recommandés par la note SAP 2205917 pour SUSE Linux Enterprise Server pour les applications SAP.

Préparer les systèmes de fichiers

Vous avez choisi de déployer les répertoires partagés SAP sur le partage NFS sur Azure Files ou le volume NFS sur Azure NetApp Files.

Monter les systèmes de fichiers partagés (NFS Azure NetApp Files)

Dans cet exemple, les systèmes de fichiers HANA partagés sont déployés sur Azure NetApp Files et montés sur NFSv4.1. Suivez les étapes décrites dans cette section uniquement si vous utilisez NFS sur Azure NetApp Files.

[AH] Préparez le système d’exploitation pour l’exécution de SAP HANA sur les systèmes NetApp avec NFS, comme indiqué dans la note SAP 3024346 - Paramètres du noyau Linux pour NetApp NFS. Créez un fichier de configuration /etc/sysctl.d/91-NetApp-HANA.conf pour les paramètres de configuration de NetApp.

vi /etc/sysctl.d/91-NetApp-HANA.conf

# Add the following entries in the configuration file
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1

[AH] Réglez les paramètres de sunrpc, comme recommandé dans la note SAP 3024346 - Paramètres du noyau Linux pour NetApp NFS.
```
vi /etc/modprobe.d/sunrpc.conf

# Insert the following line
options sunrpc tcp_max_slot_table_entries=128
```
[AH] Créez des points de montage pour les volumes de base de données HANA.
```
mkdir -p /hana/shared
```
[AH] Vérifiez le paramètre de domaine NFS. Assurez-vous que le domaine est configuré en tant que domaine par défaut Azure NetApp Files, autrement dit, defaultv4iddomain.com et que le mappage est défini sur nobody.
Cette étape n’est nécessaire que si vous utilisez Azure NetAppFiles NFSv4.1.

Important

Veillez à définir le domaine NFS dans /etc/idmapd.conf sur la machine virtuelle pour qu’elle corresponde à la configuration de domaine par défaut sur Azure NetApp Files : defaultv4iddomain.com . En cas d’incompatibilité entre la configuration de domaine sur le client NFS (c’est-à-dire la machine virtuelle) et le serveur NFS, par exemple la configuration Azure NetApp, les autorisations pour les fichiers sur les volumes Azure NetApp montés sur les machines virtuelles s’affichent en tant que nobody.
```
sudo cat /etc/idmapd.conf
# Example
[General]
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
```
[AH] Vérifiez nfs4_disable_idmapping. Cette option doit avoir la valeur Y. Pour créer la structure de répertoire où se trouve nfs4_disable_idmapping, exécutez la commande de montage. Vous ne serez pas en mesure de créer manuellement le répertoire sous /sys/modules, car l’accès est réservé pour le noyau/les pilotes.
Cette étape n’est nécessaire que si vous utilisez Azure NetAppFiles NFSv4.1.
```
# Check nfs4_disable_idmapping 
cat /sys/module/nfs/parameters/nfs4_disable_idmapping
# If you need to set nfs4_disable_idmapping to Y
mkdir /mnt/tmp
mount 10.23.1.7:/HN1-share-s1 /mnt/tmp
umount  /mnt/tmp
echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
# Make the configuration permanent
echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
```

[AH1] Montez les volumes Azure NetApp Files partagés sur les machines virtuelles du SITE 1 de base de données HANA.

sudo vi /etc/fstab
# Add the following entry
10.23.1.7:/HN1-shared-s1 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
# Mount all volumes
sudo mount -a

[AH2] Montez les volumes Azure NetApp Files partagés sur les machines virtuelles du SITE 2 de base de données HANA.

sudo vi /etc/fstab
# Add the following entry
10.23.1.7:/HN1-shared-s2 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
# Mount the volume
sudo mount -a

[AH] Vérifiez que les systèmes de fichiers /hana/shared/ correspondants sont montés sur toutes les machines virtuelles de base de données HANA avec la version de protocole NFS NFSv4.1.

sudo nfsstat -m
# Verify that flag vers is set to 4.1 
# Example from SITE 1, hana-s1-db1
/hana/shared from 10.23.1.7:/HN1-shared-s1
 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.1.7
# Example from SITE 2, hana-s2-db1
/hana/shared from 10.23.1.7:/HN1-shared-s2
 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.1.7

Monter les systèmes de fichiers partagés (NFS Azure Files)

Dans cet exemple, les systèmes de fichiers HANA partagés sont déployés sur NFS sur Azure Files. Suivez les étapes décrites dans cette section uniquement si vous utilisez NFS sur Azure Files.

[AH] Créez des points de montage pour les volumes de base de données HANA.
```
mkdir -p /hana/shared
```

[AH1] Montez les volumes Azure NetApp Files partagés sur les machines virtuelles du SITE 1 de base de données HANA.

sudo vi /etc/fstab
# Add the following entry
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
# Mount all volumes
sudo mount -a

[AH2] Montez les volumes Azure NetApp Files partagés sur les machines virtuelles du SITE 2 de base de données HANA.

sudo vi /etc/fstab
# Add the following entries
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
# Mount the volume
sudo mount -a

[AH] Vérifiez que les systèmes de fichiers /hana/shared/ correspondants sont montés sur toutes les machines virtuelles de base de données HANA avec la version de protocole NFS NFSv4.1.

sudo nfsstat -m
# Example from SITE 1, hana-s1-db1
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.0.35
# Example from SITE 2, hana-s2-db1
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.0.35

Préparer les données et enregistrer les systèmes de fichiers locaux

Dans la configuration présentée, les systèmes de fichiers /hana/data et /hana/log sont déployés sur un disque managé et sont attachés localement à chaque machine virtuelle de base de données HANA. Vous devez exécuter les étapes pour créer les volumes de données et de fichier journal locaux sur chaque machine virtuelle de base de données HANA.

Configurez la disposition du disque avec le Gestionnaire de volumes logiques (LVM) . L’exemple suivant part du principe que chaque machine virtuelle HANA dispose de trois disques de données joints qui sont utilisés pour utilisés deux volumes.

[AH] 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

[AH] 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

[AH] 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
```
[AH] 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 obtenir de meilleures performances d’E/S, et d’aligner les tailles des bandes sur les valeurs décrites dans Configurations de stockage de machines virtuelles SAP HANA. L’argument -i doit indiquer le nombre de volumes physiques sous-jacents et l’argument -I 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 ou de journal. 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.
```
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 mkfs.xfs /dev/vg_hana_data_HN1/hana_data
sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
```

[AH] Créez les répertoires de montage et copiez l’UUID de tous les volumes logiques :

sudo mkdir -p /hana/data/HN1
sudo mkdir -p /hana/log/HN1
# Write down the ID of /dev/vg_hana_data_HN1/hana_data and /dev/vg_hana_log_HN1/hana_log
sudo blkid

[AH] Créez des entrées fstab pour les volumes logiques et le montage :

sudo vi /etc/fstab

Insérez la ligne suivante dans le fichier /etc/fstab :

/dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_data_HN1-hana_data /hana/data/HN1 xfs  defaults,nofail  0  2
/dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_log_HN1-hana_log /hana/log/HN1 xfs  defaults,nofail  0  2

Montez les nouveaux volumes :

sudo mount -a

Créez un cluster Pacemaker

Suivez les étapes décrites à la page Configuration de Pacemaker sur SUSE Linux Enterprise Server dans Azure pour créer un cluster Pacemaker de base pour ce serveur HANA. Incluez toutes les machines virtuelles, y compris le créateur de majorité dans le cluster.

Important

Ne définissez pas quorum expected-votes à 2, car il ne s’agit pas d’un cluster à deux nœuds.
Vérifiez que la propriété de cluster concurrent-fencing est activée de manière à ce que le délimiteur de nœud soit désérialisé.

Installation

Dans cet exemple, pour le déploiement de SAP HANA dans une configuration de scale-out avec HSR sur des machines virtuelles Azure, nous avons utilisé HANA 2.0 SP5.

Préparer l’installation de HANA

[AH] Avant l’installation de HANA, définissez le mot de passe racine. Vous pouvez désactiver le mot de passe racine une fois l’installation terminée. Exécutez en tant que commande rootpasswd.
[1,2] Changez les autorisations sur /hana/shared
```
chmod 775 /hana/shared
```
[1] Vérifiez que vous pouvez vous connecter via SSH sur les machines virtuelles de base de données HANA dans ce site hana-s1-db2 et hana-s1-db3 sans être invité à entrer un mot de passe. Si ce n’est pas le cas, échangez les clés SSH comme décrit dans Activer l’accès SSH via la clé publique.
```
ssh root@hana-s1-db2
ssh root@hana-s1-db3
```
[2] Vérifiez que vous pouvez vous connecter via SSH sur les machines virtuelles de base de données HANA dans ce site hana-s2-db2 et hana-s2-db3 sans être invité à entrer un mot de passe.
Si ce n’est pas le cas, échangez les clés SSH.
```
ssh root@hana-s2-db2
ssh root@hana-s2-db3
```
[AH] Installez des packages supplémentaires, qui sont nécessaires pour HANA 2.0 SP4 et versions ultérieures. Pour plus d’informations, consultez la note SAP 2593824 pour votre version de SLES.
```
# In this example, using SLES12 SP5
sudo zypper install libgcc_s1 libstdc++6 libatomic1
```

Installation de HANA sur le premier nœud de chaque site

[1] Installez SAP HANA en suivant les instructions fournies dans le Guide d’installation et de mise à jour de SAP HANA 2.0. Dans les instructions qui suivent, nous présentons l’installation de SAP HANA sur le premier nœud sur le SITE 1.

a. Démarrez le programme hdblcm en tant que root à partir du répertoire du logiciel d’installation HANA. Utilisez le paramètre internal_network et transmettez l’espace d’adressage pour le sous-réseau, qui est utilisé pour la communication interne HANA entre les nœuds.
```
./hdblcm --internal_network=10.23.1.128/26
```
b. À l’invite, entrez les valeurs suivantes :
- Pour Choisir une action : entrer 1 (pour l’installation)
- Pour Composants supplémentaires pour l’installation : entrer 2, 3
- Pour le chemin d’accès de l’installation : appuyer sur Entrée (utilise par défaut /hana/shared)
- Pour Nom d’hôte local : appuyer sur Entrée pour accepter la valeur par défaut
- Pour Voulez-vous ajouter des hôtes au système ? : entrer n
- Pour ID système SAP HANA : entrer HN1
- Pour Numéro d’instance [00] : entrer 03
- Pour Groupe Worker hôte local [par défaut] : appuyer sur Entrée pour accepter la valeur par défaut
- Pour Sélectionner Utilisation du système/Entrer l’index [4] : entrer 4 (pour personnalisé)
- Pour Emplacement des volumes de données [/hana/data/HN1] : appuyer sur Entrée pour accepter la valeur par défaut
- Pour Emplacement des volumes de journaux [/hana/log/HN1] : appuyer sur Entrée pour accepter la valeur par défaut
- Pour Restreindre l’allocation de mémoire maximale ? [n] : entrez n.
- Pour Nom d’hôte du certificat pour l’hôte hana-s1-db1 [hana-s1-db1] : appuyer sur Entrée pour accepter la valeur par défaut
- Pour Mot de passe (sapadm) utilisateur de l’agent hôte SAP : entrer le mot de passe
- Pour Confirmer le mot de passe (sapadm) utilisateur de l’agent hôte SAP : entrer le mot de passe
- Pour Mot de passe de l’administrateur système (hn1adm) : entrer le mot de passe
- Pour Répertoire de base de l’administrateur système[/usr/sap/HN1/home] : appuyer sur Entrée pour accepter la valeur par défaut
- Pour Environnement de connexion de l’administrateur système [/bin/sh] : appuyer sur Entrée pour accepter la valeur par défaut
- Pour ID utilisateur de l’administrateur système [1001] : appuyer sur Entrée pour accepter la valeur par défaut
- Pour Entrer l’ID du groupe d’utilisateurs (sapsys) [79] : appuyrz sur Entrée pour accepter la valeur par défaut
- Pour Mot de passe utilisateur de la base de données système (système) : entrer le mot de passe du système
- Pour Confirmer le mot de passe utilisateur de la base de données système (système) : entrer le mot de passe du système
- Pour Redémarrer le système après le redémarrage de la machine ? [n] : entrez n.
- Pour Voulez-vous continuer (y/n) : valider le résumé et si tout semble correct, entrer y
[2] Répétez l’étape précédente pour installer SAP HANA sur le premier nœud sur le SITE 2.
[1,2] Vérifiez global. ini

Affichez global.ini et assurez-vous que la configuration de la communication interne SAP HANA entre les nœuds est en place. Vérifiez la section communication. Elle doit comporter un espace d’adressage pour le sous-réseau inter et listeninterface doit être défini sur .internal. Vérifiez la section internal_hostname_resolution. Elle doit comporter les adresses IP des machines virtuelles HANA qui appartiennent au sous-réseau inter.
```
  sudo cat /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
  # Example from SITE1 
  [communication]
  internal_network = 10.23.1.128/26
  listeninterface = .internal
  [internal_hostname_resolution]
  10.23.1.132 = hana-s1-db1
  10.23.1.133 = hana-s1-db2
  10.23.1.134 = hana-s1-db3
```
[1, 2] Préparez global.ini pour l’installation dans un environnement non partagé, comme décrit dans la note SAP 2080991.
```
 sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
 [persistence]
 basepath_shared = no
```

[1,2] Redémarrez SAP HANA pour activer les modifications.

 sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem
 sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem

[1,2] Vérifiez que l’interface client utilise les adresses IP du sous-réseau client pour les communications.
```
# Execute as hn1adm
/usr/sap/HN1/HDB03/exe/hdbsql -u SYSTEM -p "password" -i 03 -d SYSTEMDB 'select * from SYS.M_HOST_INFORMATION'|grep net_publicname
# Expected result - example from SITE 2
"hana-s2-db1","net_publicname","10.23.0.22"
```
Pour plus d’informations sur la vérification de la configuration, consultez la note SAP 2183363 – Configuration du réseau interne SAP HANA.
[AH] Modifiez les autorisations sur les répertoires de données et de journaux pour éviter une erreur d’installation de HANA.
```
 sudo chmod o+w -R /hana/data /hana/log
```
[1] Installez les nœuds HANA secondaires. Les exemples d’instructions de cette étape sont pour le SITE 1.

a. Démarrez le programme hdblcm résident comme root.
```
 cd /hana/shared/HN1/hdblcm
 ./hdblcm 
```
b. À l’invite, entrez les valeurs suivantes :
- Pour Choisir une action : entrer 2 (pour ajouter des hôtes)
- Pour Entrer les noms d’hôte séparés par une virgule à ajouter : hana-s1-db2, hana-s1-db3
- Pour Composants supplémentaires pour l’installation : entrer 2, 3
- Pour Entrer le nom d’utilisateur racine [root] : appuyer sur Entrée pour accepter la valeur par défaut
- Pour Sélectionner des rôles pour l’hôte 'hana-s1-db2' [1] : 1 (pour le Worker)
- Pour Entrer le groupe de basculement hôte pour l’hôte 'hana-s1-db2' [par défaut] : appuyer sur Entrée pour accepter la valeur par défaut
- Pour Entrer le numéro de partition de stockage pour l’hôte 'hana-s1-db2' [<<attribuer automatiquement>>] : appuyez sur Entrée pour accepter la valeur par défaut.
- Pour Entrer le groupe de basculement hôte pour l’hôte 'hana-s1-db2' [par défaut] : appuyer sur Entrée pour accepter la valeur par défaut
- Pour Sélectionner des rôles pour l’hôte 'hana-s1-db3' [1] : 1 (pour le Worker)
- Pour Entrer le groupe de basculement hôte pour l’hôte 'hana-s1-db3' [par défaut] : appuyer sur Entrée pour accepter la valeur par défaut
- Pour Entrer le numéro de partition de stockage pour l’hôte 'hana-s1-db3' [<<attribuer automatiquement>>] : appuyez sur Entrée pour accepter la valeur par défaut.
- Pour Entrer le groupe de Worker hôte pour l’hôte 'hana-s1-db3' [par défaut] : appuyer sur Entrée pour accepter la valeur par défaut
- Pour Mot de passe de l’administrateur système (hn1adm) : entrer le mot de passe
- Pour Entrer le mot de passe (sapadm) utilisateur de l’agent hôte SAP : entrer le mot de passe
- Pour Confirmer le mot de passe (sapadm) utilisateur de l’agent hôte SAP : entrer le mot de passe
- Pour Nom d’hôte du certificat pour l’hôte hana-s1-db2 [hana-s1-db2] : appuyer sur Entrée pour accepter la valeur par défaut
- Pour Nom d’hôte du certificat pour l’hôte hana-s1-db3 [hana-s1-db3] : appuyer sur Entrée pour accepter la valeur par défaut
- Pour Voulez-vous continuer (y/n) : valider le résumé et si tout semble correct, entrer y
[2] Répétez l’étape précédente pour installer les nœuds SAP HANA secondaires sur le SITE 2.

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

[1] Configurez la réplication de système sur le SITE 1 :

Sauvegardez les bases de données en tant que hn1adm :

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')"

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 hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY  hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/

Créez le site principal :

hdbnsutil -sr_enable --name=HANA_S1

[2] Configurez la réplication de système sur le SITE 2 :

Inscrivez le second site 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=hana-s1-db1 --remoteInstance=03 --replicationMode=sync --name=HANA_S2
sapcontrol -nr 03 -function StartSystem

[1] Vérifier 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.

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 |
# | -------- | ------------- | ----- | ------------ | --------- | ------- | --------- | ------------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
# | HN1      | hana-s1-db3   | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db3   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | SYSTEMDB | hana-s1-db1   | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1   |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db1   | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1   |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db1   | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db2   | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db2   |     30303 |         2 | HANA_S2   | 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: HANA_S1

[1,2] Modifiez la configuration HANA afin que la communication pour la réplication du système HANA soit dirigée via les interfaces de réseau virtuel de réplication du système HANA.
- Arrêter HANA sur les deux sites
```
sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem HDB
```
- Modifiez global. ini pour ajouter le mappage d’hôte pour la réplication de système HANA : utilisez les adresses IP du sous-réseau hsr.
```
sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
#Add the section
[system_replication_hostname_resolution]
10.23.1.196 = hana-s1-db1
10.23.1.197 = hana-s1-db2
10.23.1.198 = hana-s1-db3
10.23.1.199 = hana-s2-db1
10.23.1.200 = hana-s2-db2
10.23.1.201 = hana-s2-db3
```
- Démarrer HANA sur les deux sites
```
sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem HDB
```
Pour plus d’informations, consultez Résolution de noms d’hôtes pour la réplication de système.

Créer des ressources de système de fichiers

Créez une ressource de cluster de système de fichiers factice, qui supervise et signale les échecs en cas de problème d’accès au système de fichiers monté sur NFS /hana/shared. Cela permet au cluster de déclencher le basculement en cas de problème d’accès à /hana/shared. Pour plus d’informations, consultez Gestion de l’échec du partage NFS lors de la réplication d’un cluster haute disponibilité SUSE pour système HANA

[1] Placez Pacemaker en mode maintenance, en vue de la création des ressources de cluster HANA.
```
crm configure property maintenance-mode=true
```
[1,2] Créez le répertoire sur le système de fichiers monté sur NFS /hana/shared, qui sera utilisé dans la ressource de surveillance du système de fichiers spécial. Les répertoires doivent être créés sur les deux sites.
```
mkdir -p /hana/shared/HN1/check
```
[AH] Créez le répertoire qui sera utilisé pour monter la ressource de surveillance du système de fichiers spécial. Le répertoire doit être créé sur tous les nœuds de cluster HANA.
```
mkdir -p /hana/check
```
[1] Créez les ressources de cluster du système de fichiers.
```
crm configure primitive fs_HN1_HDB03_fscheck Filesystem \
  params device="/hana/shared/HN1/check" \
  directory="/hana/check" fstype=nfs4 \
  options="bind,defaults,rw,hard,proto=tcp,noatime,nfsvers=4.1,lock" \
  op monitor interval=120 timeout=120 on-fail=fence \
  op_params OCF_CHECK_LEVEL=20 \
  op start interval=0 timeout=120 op stop interval=0 timeout=120

crm configure clone cln_fs_HN1_HDB03_fscheck fs_HN1_HDB03_fscheck \
  meta clone-node-max=1 interleave=true

crm configure location loc_cln_fs_HN1_HDB03_fscheck_not_on_mm \
  cln_fs_HN1_HDB03_fscheck -inf: hana-s-mm    
```
L’attribut OCF_CHECK_LEVEL=20 est ajouté à l’opération d’analyse afin que les opérations d’analyse effectuent un test en lecture/écriture sur le système de fichiers. Sans cet attribut, l’opération d’analyse vérifie uniquement que le système de fichiers est monté. Cela peut être un problème, car, en cas de perte de connectivité, le système de fichiers peut rester monté bien qu’il soit inaccessible.

L’attribut on-fail=fence est également ajouté à l’opération d’analyse. Avec cette option, si l’opération d’analyse échoue sur un nœud, ce dernier est immédiatement isolé.

Implémenter les hooks HANA HA SAPHanaSrMultiTarget et susChkSrv

Cette étape importante a pour but d’optimiser l’intégration au cluster et la détection lorsqu’un basculement de cluster est possible. Nous vous recommandons vivement de configurer le raccordement Python SAPHanaSrMultiTarget. Pour HANA 2.0 SP5 et versions ultérieures, nous vous recommandons d’implémenter les hooks SAPHanaSrMultiTarget et susChkSrv.

Notes

Le fournisseur SAPHanaSrMultiTarget HA remplace SAPHanaSR pour le scale-out HANA. SAPHanaSR a été décrit dans la version antérieure de ce document.
Consultez le billet de blog SUSE sur les changements du nouveau hook HANA HA.

Les étapes fournies pour le hook SAPHanaSrMultiTarget concernent une nouvelle installation. La mise à niveau d’un environnement existant de SAPHanaSR vers le fournisseur SAPHanaSrMultiTarget nécessite plusieurs changements et n’est PAS décrite dans ce document. Si l’environnement existant n’utilise pas de troisième site pour la reprise d’activité et que la réplication de système multicible HANA n’est pas utilisée, vous pouvez continuer à utiliser le fournisseur SAPHanaSR HA.

SusChkSrv étend les fonctionnalités du principal fournisseur SAPHanaSrMultiTarget HA. Il agit dans la situation où le processus HANA hdbindexserver se bloque. Si un seul processus 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 le hook susChkSrv implémenté, une action immédiate et configurable est exécutée, au lieu d’attendre que le processus hdbindexserver redémarre sur le même nœud. Dans un scale-out HANA, susChkSrv agit indépendamment pour chaque machine virtuelle HANA. L’action configurée tue HANA ou clôture la machine virtuelle affectée, ce qui déclenche un basculement dans le délai d’expiration configuré.

SUSE SLES 15 SP1 ou version ultérieure est nécessaire pour le fonctionnement des deux hooks HANA HA. Le tableau suivant montre d’autres dépendances.

Hook SAP HANA HA	Version HANA nécessaire	SAPHanaSR-ScaleOut nécessaire
SAPHanaSrMultiTarget	HANA 2.0 SPS4 ou version ultérieure	0.180 ou ultérieur
susChkSrv	HANA 2.0 SPS5 ou version ultérieure	0.184.1 ou ultérieur

Étapes pour implémenter les deux hooks :

[1,2] Arrêtez HANA sur les deux sites de réplication de système. Exécutez en tant que <sid>adm :
```
sapcontrol -nr 03 -function StopSystem
```
[1,2] Ajustez global.ini sur chaque site de cluster. Si les prérequis du hook susChkSrv ne sont pas remplis, le bloc [ha_dr_provider_suschksrv] entier ne doit pas être configuré.
Vous pouvez ajuster le comportement de susChkSrv avec le paramètre action_on_lost. Les valeurs valides sont [ ignore | stop | kill | fence ].
```
# add to global.ini on both sites. Do not copy global.ini between sites.
[ha_dr_provider_saphanasrmultitarget]
provider = SAPHanaSrMultiTarget
path = /usr/share/SAPHanaSR-ScaleOut
execution_order = 1

[ha_dr_provider_suschksrv]
provider = susChkSrv
path = /usr/share/SAPHanaSR-ScaleOut
execution_order = 3
action_on_lost = kill

[trace]
ha_dr_saphanasrmultitarget = info
```
L’emplacement par défaut des raccordements HA livré par SUSE est /usr/share/SAPHanaSR-ScaleOut. L’utilisation de l’emplacement standard offre un avantage : le code du hook Python est automatiquement mis à jour avec les mises à jour de package ou de système d’exploitation, et il est utilisé par HANA au prochain redémarrage. Avec un chemin propre facultatif, comme /hana/shared/myHooks, vous pouvez dissocier les mises à jour de système d’exploitation de la version de hook utilisée.

[AH] Le cluster nécessite une configuration de sudoers sur les nœuds de cluster pour <sid>adm. Dans cet exemple, il est possible de créer un nouveau fichier. Exécutez les commandes sous root et adaptez les valeurs de hn1 avec le SID en minuscules approprié.

cat << EOF > /etc/sudoers.d/20-saphana
# SAPHanaSR-ScaleOut needs for HA/DR hook scripts
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_site_srHook_*
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_gsh *
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=hn1 *
EOF

[1,2] Démarrez SAP HANA sur les deux sites de réplication. Exécutez en tant que <sid>adm.
```
sapcontrol -nr 03 -function StartSystem 
```

[A] Vérifiez que l’installation du hook est active sur tous les nœuds de cluster. Exécutez en tant que <sid>adm.

cdtrace
grep HADR.*load.*SAPHanaSrMultiTarget nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.31001.000.trc:[14162]{-1}[-1/-1] 2023-01-26 12:53:55.728027 i ha_dr_provider   HADRProviderManager.cpp(00083) : loading HA/DR Provider 'SAPHanaSrMultiTarget' from /usr/share/SAPHanaSR-ScaleOut/
grep SAPHanaSr.*init nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.31001.000.trc:[17636]{-1}[-1/-1] 2023-01-26 16:30:19.256705 i ha_dr_SAPHanaSrM SAPHanaSrMultiTarget.py(00080) : SAPHanaSrMultiTarget.init() CALLING CRM: <sudo /usr/sbin/crm_attribute -n hana_hn1_gsh -v 2.2  -l reboot> rc=0
# nameserver_hana-s1-db1.31001.000.trc:[17636]{-1}[-1/-1] 2023-01-26 16:30:19.256739 i ha_dr_SAPHanaSrM SAPHanaSrMultiTarget.py(00081) : SAPHanaSrMultiTarget.init() Running srHookGeneration 2.2, see attribute hana_hn1_gsh too

Vérifiez l’installation du hook susChkSrv. Exécutez en tant que <sid>adm.

cdtrace
egrep '(LOST:|STOP:|START:|DOWN:|init|load|fail)' nameserver_suschksrv.trc
# Example output
# 2023-01-19 08:23:10.581529  [1674116590-10005] susChkSrv.init() version 0.7.7, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9
# 2023-01-19 08:23:31.553566  [1674116611-14022] START: indexserver event looks like graceful tenant start
# 2023-01-19 08:23:52.834813  [1674116632-15235] START: indexserver event looks like graceful tenant start (indexserver started)

Créer les ressources de cluster SAP HANA

[1] Créez les ressources de cluster HANA. Exécutez les commandes suivantes en tant que root.

Assurez-vous que le cluster est déjà en mode maintenance.

Ensuite, créez la ressource de topologie HANA.

sudo crm configure primitive rsc_SAPHanaTopology_HN1_HDB03 ocf:suse:SAPHanaTopology \
  op monitor interval="10" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="HN1" InstanceNumber="03"

sudo crm configure clone cln_SAPHanaTopology_HN1_HDB03 rsc_SAPHanaTopology_HN1_HDB03 \
 meta clone-node-max="1" target-role="Started" interleave="true"

Ensuite, créez la ressource d’instance HANA.

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.
```
sudo crm configure primitive rsc_SAPHana_HN1_HDB03 ocf:suse:SAPHanaController \
  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="HN1" InstanceNumber="03" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

sudo crm configure ms msl_SAPHana_HN1_HDB03 rsc_SAPHana_HN1_HDB03 \
  meta clone-node-max="1" master-max="1" interleave="true"
```
Important

Nous vous recommandons, comme meilleure pratique, de définir AUTOMATED_REGISTER uniquement sur non, tout en effectuant des tests de basculement détaillés, afin d’éviter l’échec de l’inscription automatique de l’instance principale comme secondaire. Une fois les tests de basculement terminés, définissez AUTOMATED_REGISTER sur oui, afin qu’après la réplication du système de prise en charge, la réplication puisse reprendre automatiquement.

Créez une adresse IP virtuelle et les ressources associées.

sudo crm configure primitive rsc_ip_HN1_HDB03 ocf:heartbeat:IPaddr2 \
  op monitor interval="10s" timeout="20s" \
  params ip="10.23.0.27"

sudo crm configure primitive rsc_nc_HN1_HDB03 azure-lb port=62503 \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0

sudo crm configure group g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 rsc_nc_HN1_HDB03

Créer les contraintes de cluster

# Colocate the IP with HANA master
sudo crm configure colocation col_saphana_ip_HN1_HDB03 4000: g_ip_HN1_HDB03:Started \
  msl_SAPHana_HN1_HDB03:Master  

# Start HANA Topology before HANA  instance
sudo crm configure order ord_SAPHana_HN1_HDB03 Optional: cln_SAPHanaTopology_HN1_HDB03 \
  msl_SAPHana_HN1_HDB03

# HANA resources don't run on the majority maker node
sudo crm configure location loc_SAPHanaCon_not_on_majority_maker msl_SAPHana_HN1_HDB03 -inf: hana-s-mm
sudo crm configure location loc_SAPHanaTop_not_on_majority_maker cln_SAPHanaTopology_HN1_HDB03 -inf: hana-s-mm

[1] Configurer des propriétés de cluster supplémentaires

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

[1] Placez le cluster en mode maintenance. Vérifiez que l’état du cluster est OK et que toutes les ressources sont démarrées.

# Cleanup any failed resources - the following command is example 
crm resource cleanup rsc_SAPHana_HN1_HDB03

# Place the cluster out of maintenance mode
sudo crm configure property maintenance-mode=false

[1] Vérifiez la communication entre le hook HANA HA et le cluster, en affichant la clé SOK d’état pour le SID, et les deux sites de réplication avec l’état P(rincipal) ou S(econdaire).
```
sudo /usr/sbin/SAPHanaSR-showAttr
# Expected result
# Global cib-time                 maintenance prim  sec sync_state upd
# ---------------------------------------------------------------------
# HN1    Fri Jan 27 10:38:46 2023 false       HANA_S1 -   SOK        ok
# 
# Sites     lpt        lss mns        srHook srr
# -----------------------------------------------
# HANA_S1     1674815869 4   hana-s1-db1 PRIM   P
# HANA_S2     30         4   hana-s2-db1 SWAIT  S
```
Notes

Les délais d’expiration de la configuration ci-dessus sont simplement des exemples et doivent être adaptés à la configuration HANA spécifique. Par exemple, vous devrez peut-être augmenter le délai de démarrage, si le démarrage de la base de données SAP HANA prend plus de temps.

Test de basculement SAP HANA

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.

Avant de commencer un test, vérifiez l’état du cluster et de la réplication de système SAP HANA.

a. Vérifier qu’il n’y a pas d’actions de cluster ayant échoué

#Verify that there are no failed cluster actions
crm status
# Example 
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Full list of resources:
#
# stonith-sbd    (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s1-db1 ]
#     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s1-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s1-db1

b. Vérifier que la réplication de système SAP HANA est synchronisée

# Verify HANA HSR is in sync
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 | hana-s1-db1  | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1  |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db1  | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1  |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db1  | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db3  | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db3  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db2  | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db2  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#
#status system replication site "1": ACTIVE
#overall system replication status: ACTIVE
#
#Local System Replication State
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
#mode: PRIMARY
#site id: 1
#site name: HANA_S1

Nous vous recommandons de valider minutieusement la configuration du cluster SAP HANA, en effectuant les tests documentés dans Haute disponibilité pour SAP HANA sur les machines virtuelles Azure sur SLES et dans le Scénario d’optimisation des performances de réplication SLES.
Vérifiez la configuration du cluster pour un scénario d’échec lorsqu’un nœud perd l’accès au partage NFS (/hana/shared).

Les agents de ressource SAP HANA dépendent de binaires, qui sont stockés sur /hana/shared pour effectuer des opérations pendant le basculement. Le système de fichiers /hana/shared est monté sur NFS dans la configuration présentée. Un test qui peut être effectué consiste à créer une règle de pare-feu temporaire pour bloquer l’accès au système de fichiers monté sur NFS /hana/shared et sur une des machines virtuelles du site principal. Cette approche valide le basculement du cluster en cas de perte de l’accès à /hana/shared sur le site de réplication de système actif.

Résultat attendu : lorsque vous bloquez l’accès au système de fichiers monté sur NFS /hana/shared sur l’une des machines virtuelles du site principal, l’opération d’analyse qui effectue une opération de lecture/écriture sur le système de fichiers échoue, car elle n’est pas en mesure d’accéder au système de fichiers et déclenche le basculement de ressource HANA. Le même résultat est attendu lorsque votre nœud HANA perd l’accès au partage NFS.

Vous pouvez vérifier l’état des ressources de cluster en exécutant crm_mon ou crm status. État des ressources avant le début du test :
```
# Output of crm_mon
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Active resources:
#
#stonith-sbd     (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s1-db1 ]
#     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1     
```
Pour simuler une défaillance pour /hana/shared :
- Si vous utilisez NFS sur Azure NetApp Files, commencez par confirmer l’adresse IP du volume Azure NetApp Files /hana/shared sur le site principal. Pour ce faire, exécutez df -kh|grep /hana/shared.
- Si vous utilisez NFS sur Azure Files, commencez par déterminer l’adresse IP du point de terminaison privé de votre compte de stockage.
Ensuite, configurez une règle de pare-feu temporaire pour bloquer l’accès à l’adresse IP du système de fichiers NFS /hana/shared en exécutant la commande suivante sur l’une des machines virtuelles du site de réplication de système HANA principal.

Dans cet exemple, la commande a été exécutée sur hana-s1-db1 pour le volume Azure NetApp Files /hana/shared.
```
iptables -A INPUT -s 10.23.1.7 -j DROP; iptables -A OUTPUT -d 10.23.1.7 -j DROP
```
Les ressources de cluster seront migrées vers l’autre site de réplication de système HANA.

Si vous définissez AUTOMATED_REGISTER="false", vous devrez configurer la réplication de système SAP HANA sur le site secondaire. Dans ce cas, vous pouvez exécuter ces commandes pour reconfigurer SAP HANA comme secondaire.
```
# Execute on the secondary 
su - hn1adm
# Make sure HANA is not running on the secondary site. If it is started, stop HANA
sapcontrol -nr 03 -function StopWait 600 10
# Register the HANA secondary site
hdbnsutil -sr_register --name=HANA_S1 --remoteHost=hana-s2-db1 --remoteInstance=03 --replicationMode=sync
# Switch back to root and cleanup failed resources
crm resource cleanup SAPHana_HN1_HDB03
```
État des ressources, après le test :
```
# Output of crm_mon
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Active resources:
#
#stonith-sbd     (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s2-db1 ]
#     Slaves: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db2 hana-s2-db3 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1
```

É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
Volumes NFS v4.1 sur Azure NetApp Files pour SAP HANA
Pour savoir comment établir une haute disponibilité et planifier la récupération d’urgence de SAP HANA sur des machines virtuelles Azure, consultez Haute disponibilité de SAP HANA sur des machines virtuelles Azure.

Partager via

Haute disponibilité pour système scale-out SAP HANA avec montée en puissance parallèle avec HSR sur SUSE Linux Enterprise Server

Vue d’ensemble

Préparer l’infrastructure

Déployer des machines virtuelles Linux via le Portail Azure

Configurer l’équilibrage de charge Azure

Déployer NFS

Déployer l’infrastructure Azure NetApp Files

Déployer le NFS sur l’infrastructure Azure Files

Configuration et préparation du système d’exploitation

Préparer les systèmes de fichiers

Monter les systèmes de fichiers partagés (NFS Azure NetApp Files)

Monter les systèmes de fichiers partagés (NFS Azure Files)

Préparer les données et enregistrer les systèmes de fichiers locaux

Créez un cluster Pacemaker

Installation

Préparer l’installation de HANA

Installation de HANA sur le premier nœud de chaque site

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

Créer des ressources de système de fichiers

Implémenter les hooks HANA HA SAPHanaSrMultiTarget et susChkSrv

Créer les ressources de cluster SAP HANA

Test de basculement SAP HANA

Étapes suivantes

Commentaires

Ressources supplémentaires