Hög tillgänglighet för SAP HANA-utskalningssystem med HSR på SUSE Linux Enterprise Server

Artikel
06/18/2024

Den här artikeln beskriver hur du distribuerar ett SAP HANA-system med hög tillgänglighet i en utskalningskonfiguration med HANA-systemreplikering (HSR) och Pacemaker på virtuella Azure SUSE Linux Enterprise Server-datorer (VM). De delade filsystemen i den presenterade arkitekturen är NFS-monterade och tillhandahålls av Azure NetApp Files eller NFS-resursen i Azure Files.

I exempelkonfigurationer, installationskommandon och så vidare är HANA-instansen 03 och HANA-system-ID är HN1.

Innan du börjar kan du läsa följande SAP-anteckningar och dokument:

Dokumentation om Azure NetApp Files
Dokumentation om Azure Files
SAP Note 1928533 innehåller:
- En lista över storlekar på virtuella Azure-datorer som stöds för distribution av SAP-programvara
- Viktig kapacitetsinformation för vm-storlekar i Azure
- SAP-programvara och kombinationer av operativsystem (OS) och databaser som stöds
- Den nödvändiga SAP-kernelversionen för Windows och Linux på Microsoft Azure
SAP Note 2015553: Listar krav för SAP-stödda SAP-programvarudistributioner i Azure
SAP Note 2205917: Innehåller rekommenderade OS-inställningar för SUSE Linux Enterprise Server för SAP-program
SAP Note 1944799: Innehåller SAP-riktlinjer för SUSE Linux Enterprise Server för SAP-program
SAP Note 2178632: Innehåller detaljerad information om alla övervakningsmått som rapporterats för SAP i Azure
SAP Note 2191498: Innehåller den sap-värdagentversion som krävs för Linux i Azure
SAP Note 2243692: Innehåller information om SAP-licensiering i Linux i Azure
SAP Note 1984787: Innehåller allmän information om SUSE Linux Enterprise Server 12
SAP Note 1999351: Innehåller ytterligare felsökningsinformation för Azure Enhanced Monitoring Extension för SAP
SAP Note 1900823: Innehåller information om SAP HANA-lagringskrav
SAP Community Wiki: Innehåller alla nödvändiga SAP-anteckningar för Linux
Planering och implementering av Azure Virtual Machines för SAP i Linux
Distribution av virtuella Azure-datorer för SAP i Linux
Azure Virtual Machines DBMS-distribution för SAP på Linux
SUSE SAP HA Best Practice Guides: Innehåller all nödvändig information för att konfigurera NetWeaver High Availability och SAP HANA System Replication lokalt (som ska användas som en allmän baslinje; de ger mycket mer detaljerad information)
Viktig information om SUSE-tillägg med hög tillgänglighet 12 SP5
Hantera misslyckad NFS-resurs i SUSE HA-kluster för HANA-systemreplikering
NFS v4.1-volymer på Azure NetApp Files för SAP HANA

Översikt

En metod för att uppnå HANA-hög tillgänglighet för HANA-utskalningsinstallationer är att konfigurera HANA-systemreplikering och skydda lösningen med Pacemaker-klustret för att tillåta automatisk redundans. När en aktiv nod misslyckas redundansväxlar klustret HANA-resurserna till den andra platsen.
Den presenterade konfigurationen visar tre HANA-noder på varje plats, plus majoritetsskaparnod för att förhindra scenario med delad hjärna. Instruktionerna kan anpassas för att inkludera fler virtuella datorer som HANA DB-noder.

Det HANA-delade filsystemet /hana/shared i den presenterade arkitekturen kan tillhandahållas av Azure NetApp Files eller NFS-resursen i Azure Files. DET HANA-delade filsystemet är NFS monterat på varje HANA-nod på samma HANA-systemreplikeringsplats. Filsystem /hana/data och /hana/log är lokala filsystem och delas inte mellan HANA DB-noderna. SAP HANA installeras i icke-delat läge.

Rekommenderade SAP HANA-lagringskonfigurationer finns i Lagringskonfigurationer för virtuella SAP HANA Azure-datorer.

Viktigt!

Om du distribuerar alla HANA-filsystem i Azure NetApp Files, för produktionssystem, där prestanda är en nyckel, rekommenderar vi att du utvärderar och överväger att använda Azure NetApp Files-programvolymgruppen för SAP HANA.

Varning

/hana/data Distribution och /hana/log på NFS på Azure Files stöds inte.

I föregående diagram representeras tre undernät i ett virtuellt Azure-nätverk enligt SAP HANA-nätverksrekommendationerna:

för klientkommunikation – client 10.23.0.0/24
för intern HANA-kommunikation mellan noder – inter 10.23.1.128/26
för HANA-systemreplikering – hsr 10.23.1.192/26

När /hana/data och /hana/log distribueras på lokala diskar är det inte nödvändigt att distribuera separata undernät och separata virtuella nätverkskort för kommunikation till lagringen.

Om du använder Azure NetApp Files distribueras NFS-volymerna för /hana/shared, i ett separat undernät som delegeras till Azure NetApp Files: anf 10.23.1.0/26.

Förbered infrastrukturen

I anvisningarna nedan antar vi att du redan har skapat resursgruppen, det virtuella Azure-nätverket med tre Azure-nätverksundernät: clientoch inter hsr.

Distribuera virtuella Linux-datorer via Azure-portalen

Distribuera de virtuella Azure-datorerna.

För konfigurationen som visas i det här dokumentet distribuerar du sju virtuella datorer:
- tre virtuella datorer som fungerar som HANA DB-noder för HANA-replikeringsplats 1: hana-s1-db1, hana-s1-db2 och hana-s1-db3
- tre virtuella datorer som fungerar som HANA DB-noder för HANA-replikeringsplats 2: hana-s2-db1, hana-s2-db2 och hana-s2-db3
- en liten virtuell dator som fungerar som majoritetstillverkare: hana-s-mm
De virtuella datorerna som distribueras som SAP DB HANA-noder bör certifieras av SAP för HANA enligt publicerad i katalogen SAP HANA Hardware. När du distribuerar HANA DB-noderna kontrollerar du att Accelererat nätverk har valts.

För majoritetsnoden kan du distribuera en liten virtuell dator eftersom den här virtuella datorn inte kör någon av SAP HANA-resurserna. Den virtuella majoritetstillverkarens virtuella dator används i klusterkonfigurationen för att uppnå ett udda antal klusternoder i ett scenario med delad hjärna. Den virtuella majoritetstillverkarens virtuella dator behöver bara ett virtuellt nätverksgränssnitt i client undernätet i det här exemplet.

Distribuera lokala hanterade diskar för /hana/data och /hana/log. Den minsta rekommenderade lagringskonfigurationen för /hana/data och beskrivs i SAP HANA Azure VM-lagringskonfigurationer/hana/log.

Distribuera det primära nätverksgränssnittet för varje virtuell dator i det virtuella nätverkets client undernät.
När den virtuella datorn distribueras via Azure-portalen genereras nätverksgränssnittets namn automatiskt. I de här instruktionerna för enkelhetens skull refererar vi till de automatiskt genererade primära nätverksgränssnitten som är anslutna till det client virtuella Azure-nätverksundernätet som hana-s1-db1-client, hana-s1-db2-client, hana-s1-db3-client och så vidare.
Viktigt!
- Kontrollera att det operativsystem som du väljer är SAP-certifierat för SAP HANA på de specifika vm-typer som du använder. En lista över SAP HANA-certifierade VM-typer och OS-versioner för dessa typer finns på webbplatsen för SAP HANA-certifierade IaaS-plattformar . Klicka på information om den angivna VM-typen för att hämta den fullständiga listan över SAP HANA-versioner som stöds av operativsystemet för den typen.
- Om du väljer att distribuera /hana/shared på NFS på Azure Files rekommenderar vi att du distribuerar på SLES 15 SP2 och senare.
Skapa sex nätverksgränssnitt, ett för varje virtuell HANA DB-dator, i det inter virtuella nätverksundernätet (i det här exemplet hana-s1-db1-inter, hana-s1-db2-inter, hana-s1-db3-inter, hana-s2-db1-inter, hana-s2-db2-inter och hana-s2-db3-inter).
Skapa sex nätverksgränssnitt, ett för varje virtuell HANA DB-dator, i det hsr virtuella nätverksundernätet (i det här exemplet hana-s1-db1-hsr, hana-s1-db2-hsr, hana-s1-db3-hsr, hana-s2-db1-hsr, hana-s2-db2-hsr och hana-s2-db3-hsr).
Koppla de nyligen skapade virtuella nätverksgränssnitten till motsvarande virtuella datorer:
1. Gå till den virtuella datorn i Azure-portalen.
2. I den vänstra rutan väljer du Virtuella datorer. Filtrera på namnet på den virtuella datorn (till exempel hana-s1-db1) och välj sedan den virtuella datorn.
3. I fönstret Översikt väljer du Stoppa för att frigöra den virtuella datorn.
4. Välj Nätverk och anslut sedan nätverksgränssnittet. I listrutan Anslut nätverksgränssnitt väljer du de redan skapade nätverksgränssnitten för undernäten inter och hsr .
5. Välj Spara.
6. Upprepa steg b till e för de återstående virtuella datorerna (i vårt exempel hana-s1-db2, hana-s1-db3, hana-s2-db1, hana-s2-db2 och hana-s2-db3).
7. Låt de virtuella datorerna vara i stoppat tillstånd för tillfället. Nu ska vi aktivera accelererat nätverk för alla nyligen anslutna nätverksgränssnitt.

Aktivera accelererat nätverk för de ytterligare nätverksgränssnitten för undernäten inter och hsr genom att utföra följande steg:

Öppna Azure Cloud Shell i Azure-portalen.

Kör följande kommandon för att aktivera accelererat nätverk för de ytterligare nätverksgränssnitten, som är anslutna till undernäten inter och 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

Starta de virtuella HANA DB-datorerna

Konfigurera Azure-lastbalanserare

Under konfigurationen av den virtuella datorn kan du skapa eller välja att avsluta lastbalanseraren i nätverksavsnittet. Följ stegen nedan för att konfigurera standardlastbalanserare för installation av HANA-databas med hög tillgänglighet.

Kommentar

För HANA-utskalning väljer du nätverkskortet för client undernätet när du lägger till de virtuella datorerna i serverdelspoolen.
Den fullständiga uppsättningen kommandon i Azure CLI och PowerShell lägger till de virtuella datorerna med primärt nätverkskort i serverdelspoolen.

Följ stegen i Skapa lastbalanserare för att konfigurera en standardlastbalanserare för ett SAP-system med hög tillgänglighet med hjälp av Azure-portalen. Tänk på följande under installationen av lastbalanseraren:

IP-konfiguration för klientdelen: Skapa en klientdels-IP-adress. Välj samma virtuella nätverk och undernätsnamn som dina virtuella databasdatorer.
Serverdelspool: Skapa en serverdelspool och lägg till virtuella databasdatorer.
Regler för inkommande trafik: Skapa en belastningsutjämningsregel. Följ samma steg för båda belastningsutjämningsreglerna.
- Klientdels-IP-adress: Välj en klientdels-IP-adress.
- Serverdelspool: Välj en serverdelspool.
- Portar med hög tillgänglighet: Välj det här alternativet.
- Protokoll: Välj TCP.
- Hälsoavsökning: Skapa en hälsoavsökning med följande information:
  - Protokoll: Välj TCP.
  - Port: Till exempel 625<instans-no.>.
  - Intervall: Ange 5.
  - Tröskelvärde för avsökning: Ange 2.
- Tidsgräns för inaktivitet (minuter): Ange 30.
- Aktivera flytande IP: Välj det här alternativet.

Kommentar

Konfigurationsegenskapen numberOfProbesför hälsoavsökningen , även kallad Tröskelvärde för fel i portalen, respekteras inte. Om du vill kontrollera antalet lyckade eller misslyckade efterföljande avsökningar anger du egenskapen probeThreshold till 2. Det går för närvarande inte att ange den här egenskapen med hjälp av Azure-portalen, så använd antingen Azure CLI eller PowerShell-kommandot .

Den fullständiga uppsättningen Azure CLI-koder visar konfigurationen av lastbalanseraren, som innehåller två virtuella datorer i serverdelspoolen. Beroende på antalet virtuella datorer i HANA-utskalningen kan du lägga till fler virtuella datorer i serverdelspoolen.

# 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

Expandera för att visa fullständig CLI-kod

# 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

Den fullständiga uppsättningen PowerShell-kod visar konfigurationen av lastbalanseraren, som innehåller två virtuella datorer i serverdelspoolen. Beroende på antalet virtuella datorer i HANA-utskalningen kan du lägga till fler virtuella datorer i serverdelspoolen.

# 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

Expandera för att visa fullständig PowerShell-kod

# 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

Kommentar

När virtuella datorer utan offentliga IP-adresser placeras i serverdelspoolen för intern (ingen offentlig IP-adress) Standard Azure-lastbalanserare, kommer det inte att finnas någon utgående Internetanslutning, såvida inte ytterligare konfiguration utförs för att tillåta routning till offentliga slutpunkter. Mer information om hur du uppnår utgående anslutning finns i Offentlig slutpunktsanslutning för virtuella datorer med Azure Standard Load Balancer i SAP-scenarier med hög tillgänglighet.

Viktigt!

Aktivera inte TCP-tidsstämplar på virtuella Azure-datorer som placeras bakom Azure Load Balancer. Om du aktiverar TCP-tidsstämplar misslyckas hälsoavsökningarna. Ange parametern net.ipv4.tcp_timestamps till 0. Mer information finns i Load Balancer-hälsoavsökningar och SAP-anteckning 2382421.
Om du vill förhindra att saptune ändrar värdet manuellt net.ipv4.tcp_timestamps från 0 tillbaka till 1uppdaterar du saptune-versionen till 3.1.1 eller senare. Mer information finns i saptune 3.1.1 – Behöver jag uppdatera?.

Distribuera NFS

Det finns två alternativ för att distribuera azure-inbyggda NFS för /hana/shared. Du kan distribuera NFS-volymer på Azure NetApp Files eller NFS-resurs på Azure Files. Azure-filer stöder NFSv4.1-protokoll, NFS på Azure NetApp-filer stöder både NFSv4.1 och NFSv3.

I nästa avsnitt beskrivs stegen för att distribuera NFS – du behöver bara välja ett av alternativen.

Dricks

Du valde att distribuera /hana/shared på NFS-resursen på Azure Files - eller NFS-volymen på Azure NetApp Files.

Distribuera Azure NetApp Files-infrastrukturen

Distribuera Azure NetApp Files-volymer för /hana/shared filsystemet. Du behöver en separat /hana/shared volym för varje HANA-systemreplikeringsplats. Mer information finns i Konfigurera Azure NetApp Files-infrastrukturen.

I det här exemplet användes följande Azure NetApp Files-volymer:

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

Distribuera NFS i Azure Files-infrastrukturen

Distribuera Azure Files NFS-resurser för /hana/shared filsystemet. Du behöver en separat /hana/shared Azure Files NFS-resurs för varje HANA-systemreplikeringsplats. Mer information finns i Skapa en NFS-resurs.

I det här exemplet användes följande Azure Files NFS-resurser:

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

Konfiguration och förberedelse av operativsystem

Anvisningarna i nästa avsnitt är prefixet med någon av följande förkortningar:

[A]: Gäller för alla noder, inklusive majoritetsskapare
[AH]: Gäller för alla HANA DB-noder
[M]: Gäller endast för majoritetsskaparnoden
[AH1]: Gäller för alla HANA DB-noder på PLATS 1
[AH2]: Gäller för alla HANA DB-noder på SITE 2
[1]: Gäller endast för HANA DB-noden 1, SITE 1
[2]: Gäller endast för HANA DB-noden 1, SITE 2

Konfigurera och förbereda operativsystemet genom att göra följande:

[A] Underhålla värdfilerna på de virtuella datorerna. Inkludera poster för alla undernät. Följande poster har lagts till /etc/hosts i för det här exemplet.

# 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] Skapa konfigurationsfilen /etc/sysctl.d/ms-az.conf med konfigurationsinställningarna för Microsoft för 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
```
Dricks

Undvik att ange net.ipv4.ip_local_port_range och net.ipv4.ip_local_reserved_ports explicit i sysctl-konfigurationsfilerna så att SAP-värdagenten kan hantera portintervallen. Mer information finns i SAP-2382421.
[A] SUSE levererar särskilda resursagenter för SAP HANA och som standard installeras agenter för SAP HANA-uppskalning. Avinstallera paketen för uppskalning om de är installerade och installera paketen för sap hana-utskalning. Steget måste utföras på alla virtuella klusterdatorer, inklusive majoritetstillverkaren.

Kommentar

SAPHanaSR-ScaleOut version 0.181 eller senare måste vara installerad.
```
# 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] Förbered de virtuella datorerna – tillämpa de rekommenderade inställningarna per SAP-anteckning 2205917 för SUSE Linux Enterprise Server för SAP-program.

Förbereda filsystemen

Du valde att distribuera SAP-delade kataloger på NFS-resursen på Azure Files - eller NFS-volymen på Azure NetApp Files.

Montera de delade filsystemen (Azure NetApp Files NFS)

I det här exemplet distribueras de delade HANA-filsystemen på Azure NetApp Files och monteras över NFSv4.1. Följ stegen i det här avsnittet, endast om du använder NFS på Azure NetApp Files.

[AH] Förbered operativsystemet för att köra SAP HANA på NetApp Systems med NFS, enligt beskrivningen i SAP-anmärkningen 3024346 – Linux Kernel-inställningar för NetApp NFS. Skapa konfigurationsfilen /etc/sysctl.d/91-NetApp-HANA.conf för NetApp-konfigurationsinställningarna.

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] Justera sunrpc-inställningarna enligt rekommendationerna i SAP-3024346 – Linux Kernel-inställningar för NetApp NFS.
```
vi /etc/modprobe.d/sunrpc.conf

# Insert the following line
options sunrpc tcp_max_slot_table_entries=128
```
[AH] Skapa monteringspunkter för HANA-databasvolymerna.
```
mkdir -p /hana/shared
```
[AH] Verifiera NFS-domäninställningen. Kontrollera att domänen har konfigurerats som standarddomänen För Azure NetApp Files, d.v.s. defaultv4iddomain.com och att mappningen är inställd på ingen.
Det här steget behövs bara om du använder Azure NetAppFiles NFSv4.1.

Viktigt!

Se till att ange NFS-domänen /etc/idmapd.conf på den virtuella datorn så att den matchar standarddomänkonfigurationen på Azure NetApp Files: defaultv4iddomain.com. Om det finns ett matchningsfel mellan domänkonfigurationen på NFS-klienten (dvs. den virtuella datorn) och NFS-servern, d.v.s. Azure NetApp-konfigurationen, visas behörigheterna för filer på Azure NetApp-volymer som är monterade på de virtuella datorerna som nobody.
```
sudo cat /etc/idmapd.conf
# Example
[General]
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
```

[AH] Verifiera nfs4_disable_idmapping. Den ska vara inställd på Y. Kör monteringskommandot för att skapa katalogstrukturen där nfs4_disable_idmapping den finns. Du kommer inte att kunna skapa katalogen manuellt under /sys/modules, eftersom åtkomst är reserverad för kerneln/drivrutinerna.
Det här steget behövs bara om du använder 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] Montera de delade Azure NetApp Files-volymerna på de virtuella DATORERna SITE1 HANA DB.

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] Montera de delade Azure NetApp Files-volymerna på de virtuella DATORERna SITE2 HANA DB.

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] Kontrollera att motsvarande /hana/shared/ filsystem är monterade på alla virtuella HANA DB-datorer med NFS-protokollversionen 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

Montera de delade filsystemen (Azure Files NFS)

I det här exemplet distribueras de delade HANA-filsystemen på NFS på Azure Files. Följ stegen i det här avsnittet, endast om du använder NFS på Azure Files.

[AH] Skapa monteringspunkter för HANA-databasvolymerna.
```
mkdir -p /hana/shared
```

[AH1] Montera de delade Azure NetApp Files-volymerna på de virtuella DATORERna SITE1 HANA DB.

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] Montera de delade Azure NetApp Files-volymerna på de virtuella DATORERna SITE2 HANA DB.

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] Kontrollera att motsvarande /hana/shared/ filsystem är monterade på alla virtuella HANA DB-datorer med NFS-protokollversionen 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

Förbereda data- och logglokala filsystem

I den presenterade konfigurationen är filsystem /hana/data och /hana/log distribuerade på en hanterad disk och är lokalt anslutna till varje HANA DB VM. Du måste utföra stegen för att skapa lokala data och logga volymer på varje virtuell HANA DB-dator.

Konfigurera disklayouten med Logical Volume Manager (LVM). I följande exempel förutsätts att varje virtuell HANA-dator har tre anslutna datadiskar som används för att skapa två volymer.

[AH] Visa en lista över alla tillgängliga diskar:

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

Exempel på utdata>

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

[AH] Skapa fysiska volymer för alla diskar som du vill använda:

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

[AH] Skapa en volymgrupp för datafilerna. Använd en volymgrupp för loggfilerna och en för den delade katalogen för 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] Skapa de logiska volymerna.

En linjär volym skapas när du använder lvcreate utan växeln -i . Vi rekommenderar att du skapar en randig volym för bättre I/O-prestanda och justerar randstorlekarna efter de värden som dokumenteras i SAP HANA VM-lagringskonfigurationer. Argumentet -i ska vara antalet underliggande fysiska volymer och -I argumentet är randstorleken. I det här dokumentet används två fysiska volymer för datavolymen, så växelargumentet -i är inställt på 2. Randstorleken för datavolymen är 256 KiB. En fysisk volym används för loggvolymen, så inga -i eller -I växlar används uttryckligen för loggvolymkommandona.

Viktigt!

Använd växeln -i och ange den till antalet underliggande fysiska volymer när du använder mer än en fysisk volym för varje data eller loggvolymer. Använd växeln -I för att ange randstorleken när du skapar en randig volym.
Se SAP HANA VM-lagringskonfigurationer för rekommenderade lagringskonfigurationer, inklusive randstorlekar och antal diskar.
```
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] Skapa monteringskatalogerna och kopiera UUID för alla logiska volymer:

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] Skapa fstab poster för de logiska volymerna och montera:

sudo vi /etc/fstab

Infoga följande rad i /etc/fstab filen:

/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

Montera de nya volymerna:

sudo mount -a

Skapa ett Pacemaker-kluster

Följ stegen i Konfigurera Pacemaker på SUSE Linux Enterprise Server i Azure för att skapa ett grundläggande Pacemaker-kluster för den här HANA-servern. Inkludera alla virtuella datorer, inklusive majoritetstillverkaren i klustret.

Viktigt!

Ange inte quorum expected-votes till 2 eftersom det inte är ett kluster med två noder.
Kontrollera att klusteregenskapen concurrent-fencing är aktiverad så att nodstängsel deserialiseras.

Installation

I det här exemplet för att distribuera SAP HANA i utskalningskonfiguration med HSR på virtuella Azure-datorer har vi använt HANA 2.0 SP5.

Förbereda för HANA-installation

[AH] Innan HANA-installationen anger du rotlösenordet. Du kan inaktivera rotlösenordet när installationen har slutförts. Kör som root kommando passwd.
[1,2] Ändra behörigheterna på /hana/shared
```
chmod 775 /hana/shared
```
[1] Kontrollera att du kan logga in via SSH till de virtuella HANA DB-datorerna på den här webbplatsen hana-s1-db2 och hana-s1-db3, utan att behöva ange något lösenord. Om så inte är fallet byter du ssh-nycklar enligt beskrivningen i Aktivera SSH-åtkomst via offentlig nyckel.
```
ssh root@hana-s1-db2
ssh root@hana-s1-db3
```
[2] Kontrollera att du kan logga in via SSH till de virtuella HANA DB-datorerna på den här webbplatsen hana-s2-db2 och hana-s2-db3, utan att behöva ange något lösenord.
Om så inte är fallet byter du ssh-nycklar.
```
ssh root@hana-s2-db2
ssh root@hana-s2-db3
```
[AH] Installera ytterligare paket som krävs för HANA 2.0 SP4 och senare. Mer information finns i SAP Note 2593824 för din SLES-version.
```
# In this example, using SLES12 SP5
sudo zypper install libgcc_s1 libstdc++6 libatomic1
```

HANA-installation på den första noden på varje plats

[1] Installera SAP HANA genom att följa anvisningarna i installations- och uppdateringsguiden för SAP HANA 2.0. I anvisningarna nedan visar vi SAP HANA-installationen på den första noden på SITE 1.

a. Starta hdblcm-programmet root från hana-installationsprogramvarans katalog. Använd parametern internal_network och skicka adressutrymmet för undernätet, som används för intern HANA-kommunikation mellan noder.
```
./hdblcm --internal_network=10.23.1.128/26
```
b. Ange följande värden i prompten:
- För Välj en åtgärd: ange 1 (för installation)
- För Ytterligare komponenter för installation: ange 2, 3
- För installationssökväg: tryck på Retur (standardvärdet /hana/shared)
- För Lokalt värdnamn: tryck på Retur för att acceptera standardvärdet
- För Vill du lägga till värdar i systemet?: ange n
- För SAP HANA-system-ID: ange HN1
- För Instansnummer [00]: ange 03
- För Lokal värdarbetsgrupp [standard]: tryck på Retur för att acceptera standardvärdet
- För Välj systemanvändning/Ange index [4]: ange 4 (för anpassad)
- För Plats för datavolymer [/hana/data/HN1]: tryck på Retur för att acceptera standardvärdet
- För Plats för loggvolymer [/hana/log/HN1]: tryck på Retur för att acceptera standardvärdet
- För Begränsa maximal minnesallokering? [n]: ange n
- För Certifikatvärdnamn för värd hana-s1-db1 [hana-s1-db1]: tryck på Retur för att acceptera standardvärdet
- För SAP-värdagentanvändare (sapadm) Lösenord: ange lösenordet
- För Bekräfta SAP-värdagentens användarlösenord (sapadm): ange lösenordet
- För systemadministratörslösenord (hn1adm) anger du lösenordet
- För System Administrator Home Directory [/usr/sap/HN1/home]: tryck på Retur för att acceptera standardinställningen
- För systemadministratörsinloggningsgränssnittet [/bin/sh]: tryck på Retur för att acceptera standardvärdet
- För systemadministratörens användar-ID [1001]: tryck på Retur för att acceptera standardvärdet
- För Ange ID för användargrupp (sapsys) [79]: tryck på Retur för att acceptera standardvärdet
- För System Database User (system) Lösenord: ange systemets lösenord
- För Bekräfta systemdatabasanvändarens (system) lösenord: ange systemets lösenord
- För Starta om systemet efter omstart av datorn? [n]: ange n
- För Vill du fortsätta (y/n): verifiera sammanfattningen och om allt ser bra ut anger du y
[2] Upprepa föregående steg för att installera SAP HANA på den första noden på SITE 2.
[1,2] Verifiera global.ini

Visa global.ini och se till att konfigurationen för den interna SAP HANA-kommunikationen mellan noder är på plats. Kontrollera kommunikationsavsnittet. Den bör ha adressutrymmet för inter undernätet och listeninterface ska vara inställt på .internal. Kontrollera avsnittet internal_hostname_resolution . Den bör ha IP-adresserna för de virtuella HANA-datorer som tillhör inter undernätet.
```
  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] Förbered för global.ini installation i en icke-delad miljö enligt beskrivningen i SAP-2080991.

 sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
 [persistence]
 basepath_shared = no

[1,2] Starta om SAP HANA för att aktivera ändringarna.

 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] Kontrollera att klientgränssnittet använder IP-adresserna från client undernätet för kommunikation.

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

Information om hur du verifierar konfigurationen finns i SAP Note 2183363 – Konfiguration av det interna SAP HANA-nätverket.

[AH] Ändra behörigheter för data- och loggkatalogerna för att undvika HANA-installationsfel.
```
 sudo chmod o+w -R /hana/data /hana/log
```
[1] Installera de sekundära HANA-noderna. Exempelinstruktionerna i det här steget är för SITE 1.

a. Starta det bosatta hdblcm-programmet som root.
```
 cd /hana/shared/HN1/hdblcm
 ./hdblcm 
```
b. Ange följande värden i prompten:
- För Välj en åtgärd: ange 2 (för att lägga till värdar)
- För Ange kommaavgränsade värdnamn att lägga till: hana-s1-db2, hana-s1-db3
- För Ytterligare komponenter för installation: ange 2, 3
- För Ange rotanvändarnamn [root]: tryck på Retur för att acceptera standardvärdet
- För Välj roller för värden "hana-s1-db2" [1]: 1 (för arbetare)
- För Ange värdredundansgrupp för värden "hana-s1-db2" [standard]: tryck på Retur för att acceptera standardvärdet
- För Ange lagringspartitionsnummer för värden "hana-s1-db2" [<<tilldela automatiskt>>]: tryck på Retur för att acceptera standardvärdet
- För Enter Worker Group for host 'hana-s1-db2' [default]: tryck på Retur för att acceptera standardvärdet
- För Välj roller för värden "hana-s1-db3" [1]: 1 (för arbetare)
- För Ange värdredundansgrupp för värden "hana-s1-db3" [standard]: tryck på Retur för att acceptera standardvärdet
- För Ange lagringspartitionsnummer för värden "hana-s1-db3" [<<tilldela automatiskt>>]: tryck på Retur för att acceptera standardvärdet
- För Enter Worker Group for host 'hana-s1-db3' [default]: tryck på Retur för att acceptera standardvärdet
- För systemadministratörslösenord (hn1adm) anger du lösenordet
- För Ange SAP-värdagentens användarlösenord (sapadm) anger du lösenordet
- För Bekräfta SAP-värdagentens användarlösenord (sapadm): ange lösenordet
- För Certifikatvärdnamn för värd hana-s1-db2 [hana-s1-db2]: tryck på Retur för att acceptera standardvärdet
- För Certifikatvärdnamn för värd hana-s1-db3 [hana-s1-db3]: tryck på Retur för att acceptera standardvärdet
- För Vill du fortsätta (y/n): verifiera sammanfattningen och om allt ser bra ut anger du y
[2] Upprepa föregående steg för att installera de sekundära SAP HANA-noderna på SITE 2.

Konfigurera SAP HANA 2.0-systemreplikering

[1] Konfigurera systemreplikering på PLATS 1:

Säkerhetskopiera databaserna som 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')"

Kopiera systemets PKI-filer till den sekundära platsen:

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/

Skapa den primära platsen:

hdbnsutil -sr_enable --name=HANA_S1

[2] Konfigurera systemreplikering på PLATS 2:

Registrera den andra platsen för att starta systemreplikeringen. Kör följande kommando som <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] Kontrollera replikeringsstatus

Kontrollera replikeringsstatusen och vänta tills alla databaser är synkroniserade.

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] Ändra HANA-konfigurationen så att kommunikationen för HANA-systemreplikering dirigeras via de virtuella nätverksgränssnitten för HANA-systemreplikering.

Stoppa HANA på båda webbplatserna

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

Redigera global.ini för att lägga till värdmappningen för HANA-systemreplikering: använd IP-adresserna från hsr undernätet.

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

Starta HANA på båda webbplatserna

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

Mer information finns i Matchning av värdnamn för systemreplikering.

Skapa filsystemresurser

Skapa en dummyfilsystemklusterresurs, som övervakar och rapporterar fel, om det uppstår problem med att komma åt det NFS-monterade filsystemet /hana/shared. Det gör att klustret kan utlösa redundans, om det skulle uppstå problem med att /hana/sharedkomma åt . Mer information finns i Hantera misslyckad NFS-resurs i SUSE HA-kluster för HANA-systemreplikering

[1] Placera pacemakern i underhållsläge inför skapandet av HANA-klusterresurserna.
```
crm configure property maintenance-mode=true
```
[1,2] Skapa katalogen på det NFS-monterade filsystemet /hana/shared, som ska användas i den särskilda filsystemövervakningsresursen. Katalogerna måste skapas på båda webbplatserna.
```
mkdir -p /hana/shared/HN1/check
```
[AH] Skapa katalogen som ska användas för att montera den särskilda filsystemövervakningsresursen. Katalogen måste skapas på alla HANA-klusternoder.
```
mkdir -p /hana/check
```

[1] Skapa filsystemklusterresurserna.

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

OCF_CHECK_LEVEL=20 -attributet läggs till i övervakningsåtgärden, så att övervakningsåtgärder utför ett läs-/skrivtest i filsystemet. Utan det här attributet verifierar övervakningsåtgärden endast att filsystemet är monterat. Detta kan vara ett problem eftersom filsystemet kan förbli monterat när anslutningen går förlorad, trots att det är otillgängligt.

on-fail=fence -attributet läggs också till i övervakningsåtgärden. Med det här alternativet stängs den noden omedelbart om övervakningsåtgärden misslyckas på en nod.

Implementera HANA HA-krokar SAPHanaSrMultiTarget och susChkSrv

Det här viktiga steget är att optimera integreringen med klustret och identifieringen när ett kluster redundans är möjligt. Vi rekommenderar starkt att du konfigurerar SAPHanaSrMultiTarget Python-hook. För HANA 2.0 SP5 och senare rekommenderar vi att du implementerar både SAPHanaSrMultiTarget- och susChkSrv-krokar.

Kommentar

SAPHanaSrMultiTarget HA-providern ersätter SAPHanaSR för HANA-utskalning. SAPHanaSR beskrevs i tidigare version av det här dokumentet.
Se SUSE-blogginlägg om ändringar med den nya HANA HA-kroken.

Angivna steg för SAPHanaSrMultiTarget hook är för en ny installation. Uppgradering av en befintlig miljö från SAPHanaSR till SAPHanaSrMultiTarget-providern kräver flera ändringar och beskrivs INTE i det här dokumentet. Om den befintliga miljön inte använder någon tredje plats för haveriberedskap och HANA-systemreplikering med flera mål inte används, kan SAPHanaSR HA-providern fortsätta att användas.

SusChkSrv utökar funktionerna i huvudleverantören SAPHanaSrMultiTarget HA. Den fungerar i situationen när HANA-processen hdbindexserver kraschar. Om en enskild process kraschar försöker HANA vanligtvis starta om den. Det kan ta lång tid att starta om indexserverprocessen, under vilken HANA-databasen inte svarar. När susChkSrv har implementerats körs en omedelbar och konfigurerbar åtgärd i stället för att vänta på att hdbindexserverprocessen ska startas om på samma nod. I HANA fungerar utskalnings-susChkSrv för varje HANA VM oberoende av varandra. Den konfigurerade åtgärden stoppar HANA eller stängs av den berörda virtuella datorn, vilket utlöser en redundans under den konfigurerade tidsgränsen.

SUSE SLES 15 SP1 eller senare krävs för drift av båda HANA HA-krokarna. I följande tabell visas andra beroenden.

SAP HANA HA hook	HANA-version krävs	SAPHanaSR-ScaleOut krävs
SAPHanaSrMultiTarget	HANA 2.0 SPS4 eller senare	0,180 eller högre
susChkSrv	HANA 2.0 SPS5 eller senare	0.184.1 eller senare

Steg för att implementera båda krokarna:

[1,2] Stoppa HANA på båda systemreplikeringsplatserna. Kör som <sid-adm>:
```
sapcontrol -nr 03 -function StopSystem
```
[1,2] Justera global.ini på varje klusterplats. Om kraven för susChkSrv-kroken inte uppfylls bör inte hela blocket [ha_dr_provider_suschksrv] konfigureras.
Du kan justera beteendet för susChkSrv med parametern action_on_lost. Giltiga värden är [ 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
```
Standardplatsen för HA-krokarna som levereras av SUSE är /usr/share/SAPHanaSR-ScaleOut. Att använda standardplatsen ger en fördel, att python-hookkoden uppdateras automatiskt via os- eller paketuppdateringar och används av HANA vid nästa omstart. Med en valfri egen sökväg, till exempel /hana/shared/myHooks, kan du frikoppla OS-uppdateringar från den använda hookversionen.

[AH] Klustret kräver sudoers-konfiguration på klusternoderna för <sid-adm>. I det här exemplet som uppnås genom att skapa en ny fil. Kör kommandona som root anpassar värdena för hn1 med rätt gemenER SID.

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] Starta SAP HANA på båda replikeringsplatserna. Kör som <sid-adm>.
```
sapcontrol -nr 03 -function StartSystem 
```

[A] Kontrollera att hookinstallationen är aktiv på alla klusternoder. Kör som <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

Kontrollera installationen av susChkSrv-kroken. Kör som <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)

Skapa SAP HANA-klusterresurser

[1] Skapa HANA-klusterresurserna. Kör följande kommandon som root.

Kontrollera att klustret redan är underhållsläge.

Skapa sedan HANA-topologiresursen.

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"

Skapa sedan HANA-instansresursen.

Kommentar

Den här artikeln innehåller referenser till termer som Microsoft inte längre använder. När dessa villkor tas bort från programvaran tar vi bort dem från den här artikeln.
```
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"
```
Viktigt!

Vi rekommenderar som bästa praxis att du bara anger AUTOMATED_REGISTER till nej, när du utför noggranna redundanstester, för att förhindra att den primära instansen misslyckas så att den registreras automatiskt som sekundär. När redundanstesterna har slutförts ställer du in AUTOMATED_REGISTER på ja, så att systemreplikeringen efter övertagandet kan återupptas automatiskt.

Skapa virtuell IP-adress och associerade resurser.

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

Skapa klusterbegränsningarna

# 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] Konfigurera ytterligare klusteregenskaper

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

[1] Placera klustret ur underhållsläge. Kontrollera att klusterstatusen är ok och att alla resurser har startats.

# 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] Verifiera kommunikationen mellan HANA HA-kroken och klustret och visa status-SOK för SID och båda replikeringsplatserna med statusen P(rimary) eller S(econdary).

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

Kommentar

Tidsgränserna i ovanstående konfiguration är bara exempel och kan behöva anpassas till den specifika HANA-installationen. Du kan till exempel behöva öka tidsgränsen för start om det tar längre tid att starta SAP HANA-databasen.

Testa SAP HANA-redundans

Kommentar

Den här artikeln innehåller referenser till termer som Microsoft inte längre använder. När dessa villkor tas bort från programvaran tar vi bort dem från den här artikeln.

Innan du startar ett test kontrollerar du replikeringsstatusen för klustret och SAP HANA-systemet.

a. Kontrollera att det inte finns några misslyckade klusteråtgärder

#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. Kontrollera att SAP HANA-systemreplikeringen är synkroniserad

# 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

Vi rekommenderar att du noggrant verifierar KONFIGURATIONen av SAP HANA-klustret genom att utföra testerna, som dokumenteras i HA för SAP HANA på virtuella Azure-datorer på SLES och i utskalningsscenariot för SLES Replication.

Kontrollera klusterkonfigurationen för ett felscenario när en nod förlorar åtkomsten till NFS-resursen (/hana/shared).

SAP HANA-resursagenterna är beroende av binärfiler som lagras på /hana/shared för att utföra åtgärder under redundansväxling. Filsystemet /hana/shared monteras över NFS i den konfiguration som visas. Ett test som kan utföras är att skapa en tillfällig brandväggsregel för att blockera åtkomst till det /hana/shared NFS-monterade filsystemet på en av de primära virtuella platsdatorerna. Den här metoden verifierar att klustret redundansväxlar om åtkomsten till /hana/shared går förlorad på den aktiva systemreplikeringsplatsen.

Förväntat resultat: När du blockerar åtkomsten till det /hana/shared NFS-monterade filsystemet på en av de virtuella datorerna på den primära platsen kommer övervakningsåtgärden som utför läs-/skrivåtgärden i filsystemet att misslyckas eftersom den inte kan komma åt filsystemet och utlöser HANA-resursredundans. Samma resultat förväntas när HANA-noden förlorar åtkomsten till NFS-resursen.

Du kan kontrollera tillståndet för klusterresurserna genom att crm_mon köra eller crm status. Resurstillstånd innan testet startas:

# 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

Så här simulerar du fel för /hana/shared:

Om du använder NFS på Azure NetApp Files bekräftar du först IP-adressen för /hana/shared Azure NetApp Files-volymen på den primära platsen. Du kan göra det genom att köra df -kh|grep /hana/shared.
Om du använder NFS på Azure Files måste du först fastställa IP-adressen för den privata slutpunkten för ditt lagringskonto.

Konfigurera sedan en tillfällig brandväggsregel för att blockera åtkomst till IP-adressen /hana/shared för NFS-filsystemet genom att köra följande kommando på en av de primära virtuella datorerna för HANA-systemreplikeringsplats.

I det här exemplet kördes kommandot på volymen hana-s1-db1 för 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

Klusterresurserna migreras till den andra HANA-systemreplikeringsplatsen.

Om du anger AUTOMATED_REGISTER="false" måste du konfigurera SAP HANA-systemreplikering på den sekundära platsen. I det här fallet kan du köra dessa kommandon för att konfigurera om SAP HANA som sekundärt.

# 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

Tillståndet för resurserna efter testet:

# 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

Nästa steg

Planering och implementering av Azure Virtual Machines för SAP
Distribution av virtuella Azure-datorer för SAP
Azure Virtual Machines DBMS-distribution för SAP
NFS v4.1-volymer på Azure NetApp Files för SAP HANA
Mer information om hur du etablerar hög tillgänglighet och planerar för haveriberedskap för SAP HANA på virtuella Azure-datorer finns i Hög tillgänglighet för SAP HANA på virtuella Azure-datorer (VM).

Dela via

Hög tillgänglighet för SAP HANA-utskalningssystem med HSR på SUSE Linux Enterprise Server

Översikt

Förbered infrastrukturen

Distribuera virtuella Linux-datorer via Azure-portalen

Konfigurera Azure-lastbalanserare

Distribuera NFS

Distribuera Azure NetApp Files-infrastrukturen

Distribuera NFS i Azure Files-infrastrukturen

Konfiguration och förberedelse av operativsystem

Förbereda filsystemen

Montera de delade filsystemen (Azure NetApp Files NFS)

Montera de delade filsystemen (Azure Files NFS)

Förbereda data- och logglokala filsystem

Skapa ett Pacemaker-kluster

Installation

Förbereda för HANA-installation

HANA-installation på den första noden på varje plats

Konfigurera SAP HANA 2.0-systemreplikering

Skapa filsystemresurser

Implementera HANA HA-krokar SAPHanaSrMultiTarget och susChkSrv

Skapa SAP HANA-klusterresurser

Testa SAP HANA-redundans

Nästa steg

Feedback

Ytterligare resurser