Vysoká dostupnost SAP HANA na virtuálních počítačích Azure v systému Red Hat Enterprise Linux
Článek
Pro místní vývoj můžete použít replikaci systému HANA nebo sdílené úložiště k vytvoření vysoké dostupnosti (HA) pro SAP HANA. Na virtuálních počítačích Azure je replikace systému HANA v Azure aktuálně jedinou podporovanou funkcí vysoké dostupnosti.
Replikace SAP HANA se skládá z jednoho primárního uzlu a nejméně jednoho sekundárního uzlu. Změny dat v primárním uzlu se replikují do sekundárního uzlu synchronně nebo asynchronně.
Tento článek popisuje, jak nasadit a nakonfigurovat virtuální počítače, nainstalovat architekturu clusteru a nainstalovat a nakonfigurovat replikaci systému SAP HANA.
V ukázkových konfiguracích se používají instalační příkazy, číslo instance 03 a ID systému HANA HN1 .
Požadavky
Nejprve si přečtěte následující poznámky a dokumenty SAP:
K dosažení vysoké dostupnosti se SAP HANA nainstaluje na dva virtuální počítače. Data se replikují pomocí systémové replikace HANA.
Nastavení replikace systému SAP HANA používá vyhrazený název virtuálního hostitele a virtuální IP adresy. V Azure se k použití virtuální IP adresy vyžaduje nástroj pro vyrovnávání zatížení. Zobrazená konfigurace ukazuje nástroj pro vyrovnávání zatížení s:
Front-endová IP adresa: 10.0.0.13 pro hn1-db
Port sondy: 62503
Příprava infrastruktury
Azure Marketplace obsahuje image kvalifikované pro SAP HANA s doplňkem Pro vysokou dostupnost, který můžete použít k nasazení nových virtuálních počítačů pomocí různých verzí Red Hatu.
Ruční nasazení virtuálních počítačů s Linuxem prostřednictvím webu Azure Portal
Tento dokument předpokládá, že jste už nasadili skupinu prostředků, virtuální síť Azure a podsíť.
Nasazení virtuálních počítačů pro SAP HANA Zvolte vhodný obrázek RHEL, který je podporovaný pro systém HANA. Virtuální počítač můžete nasadit v libovolné z možností dostupnosti: škálovací sada virtuálních počítačů, zóna dostupnosti nebo skupina dostupnosti.
Důležité
Ujistěte se, že vybraný operační systém má certifikaci SAP pro SAP HANA na konkrétních typech virtuálních počítačů, které plánujete použít ve svém nasazení. V platformách SAP HANA Certified IaaS můžete vyhledat typy virtuálních počítačů certifikovaných pro SAP HANA a jejich vydání operačního systému. Ujistěte se, že se podíváte na podrobnosti o typu virtuálního počítače, abyste získali úplný seznam vydaných verzí operačního systému podporovaných SAP HANA pro konkrétní typ virtuálního počítače.
Konfigurace nástroje pro vyrovnávání zatížení Azure
Během konfigurace virtuálního počítače máte možnost vytvořit nebo vybrat ukončení nástroje pro vyrovnávání zatížení v části Sítě. Pokud chcete nastavit standardní nástroj pro vyrovnávání zatížení pro nastavení databáze HANA s vysokou dostupností, postupujte podle následujících kroků.
Postupujte podle kroků v tématu Vytvoření nástroje pro vyrovnávání zatížení a nastavte standardní nástroj pro vyrovnávání zatížení pro systém SAP s vysokou dostupností pomocí webu Azure Portal. Při nastavování nástroje pro vyrovnávání zatížení zvažte následující body:
Konfigurace front-endové IP adresy: Vytvořte front-endovou IP adresu. Vyberte stejnou virtuální síť a název podsítě jako vaše databázové virtuální počítače.
Back-endový fond: Vytvořte back-endový fond a přidejte databázové virtuální počítače.
Příchozí pravidla: Vytvořte pravidlo vyrovnávání zatížení. U obou pravidel vyrovnávání zatížení postupujte stejně.
IP adresa front-endu: Vyberte front-endovou IP adresu.
Back-endový fond: Vyberte back-endový fond.
Porty s vysokou dostupností: Tuto možnost vyberte.
Protokol: Vyberte TCP.
Sonda stavu: Vytvořte sondu stavu s následujícími podrobnostmi:
Protokol: Vyberte TCP.
Port: Například 625<instance-no.>.
Interval: Zadejte 5.
Prahová hodnota sondy: Zadejte 2.
Časový limit nečinnosti (minuty):Zadejte 30.
Povolit plovoucí IP adresu: Vyberte tuto možnost.
Poznámka
Vlastnost numberOfProbeskonfigurace sondy stavu , jinak označovaná jako prahová hodnota není v pořádku na portálu, se nerespektuje. Chcete-li řídit počet úspěšných nebo neúspěšných po sobě jdoucích sond, nastavte vlastnost probeThreshold na 2hodnotu . V současné době není možné tuto vlastnost nastavit pomocí webu Azure Portal, takže použijte buď Azure CLI, nebo příkaz PowerShellu.
# 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
Rozbalení pro zobrazení úplného kódu rozhraní příkazového řádku
# 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
# 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
Další informace o požadovaných 2388694 portch
Poznámka
Pokud jsou virtuální počítače bez veřejných IP adres umístěny do back-endového fondu interní instance (bez veřejné IP adresy) služby Azure Load Balancer úrovně Standard, neexistuje odchozí připojení k internetu, pokud se neprovádí další konfigurace umožňující směrování do veřejných koncových bodů. Další informace o tom, jak dosáhnout odchozího připojení, najdete v tématu Připojení k veřejnému koncovému bodu pro virtuální počítače využívající Azure Standard Load Balancer ve scénářích s vysokou dostupností SAP.
Důležité
Nepovolujte časové razítka PROTOKOLU TCP na virtuálních počítačích Azure umístěných za Azure Load Balancerem. Povolení časových razítek PROTOKOLU TCP může způsobit selhání sond stavu. Nastavte parametr net.ipv4.tcp_timestamps na 0. Další informace najdete v tématu Sondy stavu Load Balanceru a 2382421 SAP Note.
Instalace SAP HANA
Kroky v této části používají následující předpony:
[A]: Tento krok platí pro všechny uzly.
[1]: Krok se vztahuje pouze na uzel 1.
[2]: Krok se vztahuje pouze na uzel 2 clusteru Pacemaker.
Doporučujeme použít LVM pro svazky, které ukládají data a soubory protokolů. Následující příklad předpokládá, že virtuální počítače mají připojené čtyři datové disky, které se používají k vytvoření dvou svazků.
Vytvořte logické svazky. Lineární svazek se vytvoří, když použijete lvcreate bez -i přepínače. Doporučujeme vytvořit pruhovaný svazek pro lepší výkon vstupně-výstupních operací. Zarovnejte velikosti pruhů s hodnotami zdokumentovanými v konfiguracích úložiště virtuálních počítačů SAP HANA. Argumentem -i by měl být počet základních fyzických svazků a -I argumentem je velikost pruhu.
V tomto dokumentu se pro datový svazek používají dva fyzické svazky, takže -i je argument přepínače nastavený na hodnotu 2. Velikost pruhu datového svazku je 256KiB. Jeden fyzický svazek se používá pro svazek protokolu, takže pro příkazy svazku protokolu se explicitně nepoužívají žádné -i nebo -I přepínače.
Důležité
-i Přepínač použijte a nastavte ho na počet podkladových fyzických svazků, pokud pro každou data, protokol nebo sdílené svazky použijete více než jeden fyzický svazek. -I Pomocí přepínače určete velikost pruhu při vytváření prokládání svazku.
Doporučené konfigurace úložiště, včetně velikostí prokládání a počtu disků, najdete v tématu Konfigurace úložiště virtuálního počítače SAP HANA. Následující příklady rozložení nemusí nutně splňovat pokyny k výkonu pro konkrétní velikost systému. Jsou určené jenom pro ilustraci.
Nenamontujte adresáře tak, že vydáte příkazy pro připojení. Místo toho zadejte do konfigurace fstab a zadejte konečnou mount -a verzi, abyste ověřili syntaxi. Začněte vytvořením adresářů připojení pro každý svazek:
Kroky v této části používají následující předpony:
[A]: Tento krok platí pro všechny uzly.
[1]: Krok se vztahuje pouze na uzel 1.
[2]: Krok se vztahuje pouze na uzel 2 clusteru Pacemaker.
[A] Nakonfigurujte bránu firewall.
Vytvořte pravidla brány firewall, která povolí replikaci systému HANA a klientský provoz. Požadované porty jsou uvedené na portech TCP/IP všech produktů SAP. Následující příkazy jsou jen příkladem, jak povolit replikaci systému HANA 2.0 a klientský provoz do databáze SYSTEMDB, HN1 a NW1.
hdbsql -u SYSTEM -p "[passwd]" -i 03 -d SYSTEMDB 'CREATE DATABASE NW1 SYSTEM USER PASSWORD "<passwd>"'
[1] Nakonfigurujte replikaci systému na prvním uzlu.
Zálohujte databáze jako <adm hanasid>:
hdbsql -d SYSTEMDB -u SYSTEM -p "<passwd>" -i 03 "BACKUP DATA USING FILE ('initialbackupSYS')"
hdbsql -d HN1 -u SYSTEM -p "<passwd>" -i 03 "BACKUP DATA USING FILE ('initialbackupHN1')"
hdbsql -d NW1 -u SYSTEM -p "<passwd>" -i 03 "BACKUP DATA USING FILE ('initialbackupNW1')"
Zkopírujte systémové soubory PKI do sekundární lokality:
Se systémem založeným na platformě SAP Startup Framework je teď možné spravovat instance SAP HANA systémem. Minimální požadovaná verze Red Hat Enterprise Linuxu (RHEL) je RHEL 8 pro SAP. Jak je uvedeno v sap Note 3189534, všechny nové instalace SAP HANA SPS07 revize 70 nebo vyšší nebo aktualizace systémů HANA na HANA 2.0 SPS07 revize 70 nebo vyšší, architektura SAP Startup se automaticky zaregistruje se systémem.
Pokud ke správě replikace systému SAP HANA používáte řešení pro zajištění vysoké dostupnosti v kombinaci s instancemi SAP HANA s povoleným systémem (viz SAP Note 3189534), jsou potřeba další kroky k zajištění toho, aby cluster s vysokou dostupností mohl spravovat instanci SAP bez zásahu systému. Takže pro systém SAP HANA integrovaný se systémem, další kroky popsané v nástroji Red Hat KBA 7029705 musí následovat na všech uzlech clusteru.
Implementace háků replikace systému SAP HANA
Tento důležitý krok optimalizuje integraci s clusterem a zlepšuje detekci v případě potřeby převzetí služeb při selhání clusteru. Pro správnou operaci clusteru je povinné povolit háček SAPHanaSR. Důrazně doporučujeme nakonfigurovat háky PYTHONu SAPHanaSR i ChkSrv.
[A] Nainstalujte agenty prostředků SAP HANA na všechny uzly. Nezapomeňte povolit úložiště, které obsahuje balíček. Pokud používáte image s podporou vysoké dostupnosti RHEL 8.x nebo novější, nemusíte povolovat další úložiště.
# Enable repository that contains SAP HANA resource agents
sudo subscription-manager repos --enable="rhel-sap-hana-for-rhel-7-server-rpms"
sudo dnf install -y resource-agents-sap-hana
Poznámka
V případě RHEL 8.x a RHEL 9.x ověřte, jestli je nainstalovaný balíček resource-agents-sap-hana verze 0.162.3-5 nebo novější.
[A] Nainstalujte HANA system replication hooks. Konfigurace pro připojení replikace musí být nainstalovaná na obou uzlech DATABÁZE HANA.
Zastavte HANA na obou uzlech. Spustit jako <sid>adm.
Pokud odkazujete na výchozí path/usr/share/SAPHanaSR/srHook umístění, kód háku Pythonu se automaticky aktualizuje prostřednictvím aktualizací operačního systému nebo aktualizací balíčků. HANA při příštím restartování používá aktualizace kódu hooku. S volitelnou vlastní cestou, jako /hana/shared/myHooksje , můžete oddělit aktualizace operačního systému od verze háku, kterou bude HANA používat.
Chování ChkSrv háku můžete upravit pomocí parametru action_on_lost . Platné hodnoty jsou [ ignore | | stopkill ].
[A] Cluster vyžaduje sudoers konfiguraci na každém uzlu clusteru pro <sid>adm. V tomto příkladu toho dosáhnete vytvořením nového souboru. visudo Pomocí příkazu upravte soubor v rozevíracím 20-saphana seznamu jako root.
Vytvořte topologii HANA. Na jednom z uzlů clusteru Pacemaker spusťte následující příkazy. V těchto pokynech nezapomeňte v případě potřeby nahradit vaše číslo instance, ID systému HANA, IP adresy a systémové názvy.
sudo pcs property set maintenance-mode=true
sudo pcs resource create SAPHanaTopology_HN1_03 SAPHanaTopology SID=HN1 InstanceNumber=03 \
op start timeout=600 op stop timeout=300 op monitor interval=10 timeout=600 \
clone clone-max=2 clone-node-max=1 interleave=true
Dále vytvořte prostředky HANA.
Poznámka
Tento článek obsahuje odkazy na termín, který už Microsoft nepoužívá. Když se termín odebere ze softwaru, odebereme ho z tohoto článku.
Pokud vytváříte cluster na RHEL 7.x, použijte následující příkazy:
sudo pcs resource create SAPHana_HN1_03 SAPHana SID=HN1 InstanceNumber=03 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=false \
op start timeout=3600 op stop timeout=3600 \
op monitor interval=61 role="Slave" timeout=700 \
op monitor interval=59 role="Master" timeout=700 \
op promote timeout=3600 op demote timeout=3600 \
master notify=true clone-max=2 clone-node-max=1 interleave=true
sudo pcs resource create vip_HN1_03 IPaddr2 ip="10.0.0.13"
sudo pcs resource create nc_HN1_03 azure-lb port=62503
sudo pcs resource group add g_ip_HN1_03 nc_HN1_03 vip_HN1_03
sudo pcs constraint order SAPHanaTopology_HN1_03-clone then SAPHana_HN1_03-master symmetrical=false
sudo pcs constraint colocation add g_ip_HN1_03 with master SAPHana_HN1_03-master 4000
sudo pcs resource defaults resource-stickiness=1000
sudo pcs resource defaults migration-threshold=5000
sudo pcs property set maintenance-mode=false
Pokud vytváříte cluster na RHEL 8.x/9.x, použijte následující příkazy:
sudo pcs resource create SAPHana_HN1_03 SAPHana SID=HN1 InstanceNumber=03 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=false \
op start timeout=3600 op stop timeout=3600 \
op monitor interval=61 role="Slave" timeout=700 \
op monitor interval=59 role="Master" timeout=700 \
op promote timeout=3600 op demote timeout=3600 \
promotable notify=true clone-max=2 clone-node-max=1 interleave=true
sudo pcs resource create vip_HN1_03 IPaddr2 ip="10.0.0.13"
sudo pcs resource create nc_HN1_03 azure-lb port=62503
sudo pcs resource group add g_ip_HN1_03 nc_HN1_03 vip_HN1_03
sudo pcs constraint order SAPHanaTopology_HN1_03-clone then SAPHana_HN1_03-clone symmetrical=false
sudo pcs constraint colocation add g_ip_HN1_03 with master SAPHana_HN1_03-clone 4000
sudo pcs resource defaults update resource-stickiness=1000
sudo pcs resource defaults update migration-threshold=5000
sudo pcs property set maintenance-mode=false
Pokud chcete nakonfigurovat priority-fencing-delay SAP HANA (platí jenom pro pacemaker-2.0.4-6.el8 nebo vyšší), je potřeba spustit následující příkazy.
Poznámka
Pokud máte cluster se dvěma uzly, můžete nakonfigurovat vlastnost clusteru priority-fencing-delay . Tato vlastnost představuje zpoždění při dělení uzlu, který má vyšší celkovou prioritu zdroje, když dojde ke scénáři rozděleného mozku. Další informace najdete v tématu Může Pacemaker ohražovat uzel clusteru s nejmenšími spuštěnými prostředky?.
Vlastnost priority-fencing-delay se vztahuje na pacemaker-2.0.4-6.el8 verze nebo vyšší. Pokud nastavujete priority-fencing-delay na existujícím clusteru, nezapomeňte zrušit nastavení pcmk_delay_max možnosti v zařízení pro ohraničení.
sudo pcs property set maintenance-mode=true
sudo pcs resource defaults update priority=1
sudo pcs resource update SAPHana_HN1_03-clone meta priority=10
sudo pcs property set priority-fencing-delay=15s
sudo pcs property set maintenance-mode=false
Důležité
Při provádění testů převzetí služeb při selhání je vhodné nastavit AUTOMATED_REGISTERfalse, aby se primární instance, která selhala, automaticky zaregistrovala jako sekundární. Po otestování je jako osvědčený postup nastavený AUTOMATED_REGISTER tak true , aby po převzetí mohl replikace systému pokračovat automaticky.
Ujistěte se, že je stav clusteru v pořádku a že jsou spuštěné všechny prostředky. Na kterém uzlu jsou prostředky spuštěné, není důležité.
Poznámka
Časové limity v předchozí konfiguraci jsou pouze příklady a může být potřeba je přizpůsobit konkrétnímu nastavení HANA. Pokud například spuštění databáze SAP HANA trvá déle, může být potřeba zvýšit časový limit spuštění.
Pomocí příkazu sudo pcs status zkontrolujte stav vytvořených prostředků clusteru:
# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# azure_fence (stonith:fence_azure_arm): Started hn1-db-0
# Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
# Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
# Masters: [ hn1-db-0 ]
# Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_03
# nc_HN1_03 (ocf::heartbeat:azure-lb): Started hn1-db-0
# vip_HN1_03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
Konfigurace replikace systému s podporou aktivní/čtení HANA v clusteru Pacemaker
Počínaje SAP HANA 2.0 SPS 01 umožňuje SAP nastavení pro replikaci systému SAP HANA s podporou aktivního a čtení, kde sekundární systémy replikace systému SAP HANA je možné aktivně používat pro úlohy náročné na čtení.
Aby bylo možné takové nastavení podporovat v clusteru, vyžaduje se druhá virtuální IP adresa, která klientům umožňuje přístup k sekundární databázi SAP HANA s podporou čtení. Aby se zajistilo, že sekundární replikační lokalita bude mít přístup i po převzetí, cluster musí přesunout virtuální IP adresu s sekundárním prostředkem SAPHana.
Tato část popisuje další kroky potřebné ke správě replikace systému s podporou aktivní/čtení HANA v clusteru s vysokou dostupností pro Red Hat s druhou virtuální IP adresou.
Než budete pokračovat, ujistěte se, že jste plně nakonfigurovali cluster Red Hat HA, který spravuje databázi SAP HANA, jak je popsáno v předchozích segmentech dokumentace.
Další nastavení v Azure Load Balanceru pro aktivní/čtení s povoleným nastavením
Pro nástroj pro vyrovnávání zatížení úrovně Standard postupujte podle těchto kroků na stejném nástroji pro vyrovnávání zatížení, který jste vytvořili v předchozí části.
a. Vytvořte druhý front-endový fond IP adres:
Otevřete nástroj pro vyrovnávání zatížení, vyberte front-endový fond IP adres a vyberte Přidat.
Zadejte název druhého front-endového fondu IP adres (například hana-secondaryIP).
Nastavte přiřazení na Static a zadejte IP adresu (například 10.0.0.14).
Vyberte OK.
Po vytvoření nového front-endového fondu IP adres si poznamenejte IP adresu fondu.
b. Vytvoření sondy stavu:
Otevřete nástroj pro vyrovnávání zatížení, vyberte sondy stavu a vyberte Přidat.
Zadejte název nové sondy stavu (například hana-secondaryhp).
Jako protokol a port 62603 vyberte tcp. Ponechte hodnotu Interval nastavenou na 5 a prahovou hodnotu není v pořádku nastavená na hodnotu 2.
Vyberte OK.
c. Vytvořte pravidla vyrovnávání zatížení:
Otevřete nástroj pro vyrovnávání zatížení, vyberte pravidla vyrovnávání zatížení a vyberte Přidat.
Zadejte název nového pravidla nástroje pro vyrovnávání zatížení (například hana-secondarylb).
Vyberte front-endovou IP adresu, back-endový fond a sondu stavu, kterou jste vytvořili dříve (například hana-secondaryIP, hana-backend a hana-secondaryhp).
Vyberte porty vysoké dostupnosti.
Nezapomeňte povolit plovoucí IP adresu.
Vyberte OK.
Konfigurace replikace systému s podporou aktivní/čtení hana
Postup konfigurace systémové replikace HANA najdete v části Konfigurace systémové replikace SAP HANA 2.0. Pokud při konfiguraci replikace systému na druhém uzlu nasazujete sekundární scénář s podporou čtení, spusťte následující příkaz jako hanasidadm:
Přidání sekundárního prostředku virtuální IP adresy pro nastavení s podporou aktivního nebo čtení
Druhou virtuální IP adresu a příslušné omezení kolokace je možné nakonfigurovat pomocí následujících příkazů:
pcs property set maintenance-mode=true
pcs resource create secvip_HN1_03 ocf:heartbeat:IPaddr2 ip="10.40.0.16"
pcs resource create secnc_HN1_03 ocf:heartbeat:azure-lb port=62603
pcs resource group add g_secip_HN1_03 secnc_HN1_03 secvip_HN1_03
pcs constraint location g_secip_HN1_03 rule score=INFINITY hana_hn1_sync_state eq SOK and hana_hn1_roles eq 4:S:master1:master:worker:master
pcs constraint location g_secip_HN1_03 rule score=4000 hana_hn1_sync_state eq PRIM and hana_hn1_roles eq 4:P:master1:master:worker:master
# Set the priority to primary IPaddr2 and azure-lb resource if priority-fencing-delay is configured
sudo pcs resource update vip_HN1_03 meta priority=5
sudo pcs resource update nc_HN1_03 meta priority=5
pcs property set maintenance-mode=false
Ujistěte se, že je stav clusteru v pořádku a že jsou spuštěné všechny prostředky. Druhá virtuální IP adresa běží v sekundární lokalitě spolu s sekundárním prostředkem SAPHana.
sudo pcs status
# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full List of Resources:
# rsc_hdb_azr_agt (stonith:fence_azure_arm): Started hn1-db-0
# Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]:
# Started: [ hn1-db-0 hn1-db-1 ]
# Clone Set: SAPHana_HN1_03-clone [SAPHana_HN1_03] (promotable):
# Masters: [ hn1-db-0 ]
# Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_03:
# nc_HN1_03 (ocf::heartbeat:azure-lb): Started hn1-db-0
# vip_HN1_03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
# Resource Group: g_secip_HN1_03:
# secnc_HN1_03 (ocf::heartbeat:azure-lb): Started hn1-db-1
# secvip_HN1_03 (ocf::heartbeat:IPaddr2): Started hn1-db-1
V další části najdete typickou sadu testů převzetí služeb při selhání, které se mají spustit.
Při testování clusteru HANA s nakonfigurovaným sekundárním čtením mějte na paměti druhé chování virtuálníCH IP adres:
Při migraci prostředku clusteru SAPHana_HN1_03 do sekundární lokality hn1-db-1 se druhá virtuální IP adresa bude dál spouštět ve stejné lokalitě hn1-db-1. Pokud jste nastavili AUTOMATED_REGISTER="true" replikaci prostředků a systému HANA se automaticky zaregistrují na serveru hn1-db-0, vaše druhá virtuální IP adresa se také přesune na hn1-db-0.
Při testování chybového ukončení serveru běží na primárním serveru spolu s primárními prostředky virtuálníCH IP adres druhý virtuální IP prostředek (secvip_HN1_03) a prostředek portu Azure Load Balanceru (secnc_HN1_03). Takže až do doby, kdy je sekundární server mimo provoz, se aplikace připojené k databázi HANA s podporou čtení připojují k primární databázi HANA. Toto chování se očekává, protože nechcete, aby aplikace, které jsou připojené k databázi HANA s podporou čtení, byly nedostupné, dokud sekundární server není k dispozici.
Během převzetí služeb při selhání a náhradní virtuální IP adresy může dojít k přerušení stávajících připojení k aplikacím, které používají druhou virtuální IP adresu pro připojení k databázi HANA.
Nastavení maximalizuje dobu, po kterou je druhý prostředek virtuální IP adresy přiřazený k uzlu, na kterém je spuštěná instance SAP HANA, která je v pořádku.
Otestování nastavení clusteru
Tato část popisuje, jak můžete otestovat nastavení. Než začnete testovat, ujistěte se, že Pacemaker nemá žádnou neúspěšnou akci (prostřednictvím stavu pcs), neexistují žádná neočekávaná omezení umístění (například zbývající přechody testu migrace) a že hana je například ve stavu synchronizace.systemReplicationStatus
sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
V AUTOMATED_REGISTER="false"případě, že cluster nerestartuje neúspěšnou databázi HANA nebo ji zaregistruje v nové primární databázi hn1-db-0. V tomto případě nakonfigurujte instanci HANA jako sekundární spuštěním těchto příkazů jako hn1adm:
Spuštěním pravidla brány firewall zablokujte komunikaci na jednom z uzlů.
# Execute iptable rule on hn1-db-1 (10.0.0.6) to block the incoming and outgoing traffic to hn1-db-0 (10.0.0.5)
iptables -A INPUT -s 10.0.0.5 -j DROP; iptables -A OUTPUT -d 10.0.0.5 -j DROP
Pokud uzly clusteru mezi sebou nemůžou komunikovat, existuje riziko rozděleného scénáře mozku. V takových situacích se uzly clusteru snaží vzájemně ohražovat, což vede k plotu. Pokud se chcete takové situaci vyhnout, doporučujeme nastavit vlastnost priority-fencing-delay v konfiguraci clusteru (platí pouze pro pacemaker-2.0.4-6.el8 nebo vyšší).
Když tuto vlastnost povolíte priority-fencing-delay , cluster zavádí zpoždění v akci ohraničení speciálně na uzlu, který je hostitelem hlavního prostředku HANA, což umožňuje uzlu vyhrát závod plotu.
Spuštěním následujícího příkazu odstraňte pravidlo brány firewall:
# If the iptables rule set on the server gets reset after a reboot, the rules will be cleared out. In case they have not been reset, please proceed to remove the iptables rule using the following command.
iptables -D INPUT -s 10.0.0.5 -j DROP; iptables -D OUTPUT -d 10.0.0.5 -j DROP
Otestování agenta ohraničení Azure
Poznámka
Tento článek obsahuje odkazy na termín, který už Microsoft nepoužívá. Když se termín odebere ze softwaru, odebereme ho z tohoto článku.
Nastavení agenta ohraničení Azure můžete otestovat zakázáním síťového rozhraní na uzlu, na kterém je SAP HANA spuštěný jako hlavní. Popis, jak simulovat selhání sítě, najdete v článku 79523 znalostní báze Red Hat Knowledge Base.
V tomto příkladu net_breaker pomocí skriptu jako kořenového adresáře zablokujeme veškerý přístup k síti:
sh ./net_breaker.sh BreakCommCmd 10.0.0.6
Virtuální počítač by se teď měl restartovat nebo zastavit v závislosti na konfiguraci clusteru.
Pokud nastavíte stonith-action nastavení offna , virtuální počítač se zastaví a prostředky se migrují na spuštěný virtuální počítač.
Po opětovném spuštění virtuálního počítače se prostředek SAP HANA nepodaří spustit jako sekundární, pokud nastavíte AUTOMATED_REGISTER="false". V tomto případě nakonfigurujte instanci HANA jako sekundární spuštěním tohoto příkazu jako uživatele hn1adm :
Přepněte zpět do kořenového adresáře a vyčistíte stav selhání:
# On RHEL 7.x
pcs resource cleanup SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource cleanup SAPHana_HN1_03 node=<hostname on which the resource needs to be cleaned>
Ruční převzetí služeb při selhání můžete otestovat zastavením clusteru hn1-db-0 na uzlu jako kořen:
pcs cluster stop
Po převzetí služeb při selhání můžete cluster spustit znovu. Pokud nastavíte AUTOMATED_REGISTER="false", prostředek SAP HANA na hn1-db-0 uzlu se nespustí jako sekundární. V tomto případě nakonfigurujte instanci HANA jako sekundární spuštěním tohoto příkazu jako kořenového adresáře:
# On RHEL 7.x
pcs resource cleanup SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource cleanup SAPHana_HN1_03 node=<hostname on which the resource needs to be cleaned>
Odborníci na SAP potřebují vyhodnotit nasazení řešení SAP v Azure. Tento modul zkoumá přípravu na nasazení AnyDB s vysokou dostupností SAP NetWeaver v Azure. Příprava na zkoušku AZ-120 Plánování a správa Microsoft Azure pro úlohy SAP