Wysoka dostępność platformy SAP HANA skalowana w górę za pomocą usługi Azure NetApp Files w systemie RHEL

W tym artykule opisano sposób konfigurowania replikacji systemu SAP HANA we wdrożeniu skalowalnym w górę, gdy systemy plików HANA są instalowane za pośrednictwem systemu plików NFS przy użyciu usługi Azure NetApp Files. W przykładowych konfiguracjach i poleceniach instalacji używane są wystąpienia o numerze 03 i identyfikatorze systemu HANA HN1 . Replikacja systemu SAP HANA składa się z jednego węzła podstawowego i co najmniej jednego węzła pomocniczego.

Gdy kroki w tym dokumencie są oznaczone następującymi prefiksami, znaczenie jest następujące:

• [A]: Krok dotyczy wszystkich węzłów
• [1]: Krok dotyczy tylko węzła Node1
• [2]: Krok dotyczy tylko węzła Node2

Wymagania wstępne

Najpierw przeczytaj następujące uwagi i dokumenty SAP:

• Notatka SAP 1928533, która zawiera:
  • Lista rozmiarów maszyn wirtualnych platformy Azure obsługiwanych na potrzeby wdrażania oprogramowania SAP.
  • Ważne informacje o pojemności dla rozmiarów maszyn wirtualnych platformy Azure.
  • Obsługiwane kombinacje oprogramowania SAP i systemu operacyjnego (OS) i bazy danych.
  • Wymagana wersja jądra SAP dla systemów Windows i Linux na platformie Microsoft Azure.
• Program SAP Note 2015553 zawiera listę wymagań wstępnych dotyczących wdrożeń oprogramowania SAP obsługiwanych przez oprogramowanie SAP na platformie Azure.
• Program SAP Note 405827 zawiera listę zalecanych systemów plików dla środowisk HANA.
• Program SAP Note 2002167 ma zalecane ustawienia systemu operacyjnego dla systemu Red Hat Enterprise Linux.
• Oprogramowanie SAP Note 2009879 zawiera wytyczne dotyczące oprogramowania SAP HANA dla systemu Red Hat Enterprise Linux.
• Program SAP Note 3108302 zawiera wytyczne dotyczące oprogramowania SAP HANA dla systemu Red Hat Enterprise Linux 9.x.
• Program SAP Note 2178632 zawiera szczegółowe informacje o wszystkich metrykach monitorowania zgłoszonych dla oprogramowania SAP na platformie Azure.
• Program SAP Note 2191498 ma wymaganą wersję agenta hosta SAP dla systemu Linux na platformie Azure.
• Program SAP Note 2243692 zawiera informacje o licencjonowaniu oprogramowania SAP w systemie Linux na platformie Azure.
• Program SAP Note 1999351 zawiera więcej informacji dotyczących rozwiązywania problemów z rozszerzeniem rozszerzonego monitorowania platformy Azure dla oprogramowania SAP.
• Witryna SAP Community Wiki zawiera wszystkie wymagane uwagi SAP dla systemu Linux.
• Planowanie i implementacja usługi Azure Virtual Machines dla oprogramowania SAP w systemie Linux
• Wdrażanie usługi Azure Virtual Machines dla oprogramowania SAP w systemie Linux
• Wdrażanie baz danych DBMS na platformie Azure Virtual Machines dla systemu SAP na Linux
• Replikacja systemu SAP HANA w klastrze Pacemaker
• Ogólna dokumentacja systemu Red Hat Enterprise Linux (RHEL):
  • Omówienie dodatku wysokiej dostępności
  • Administracja dodatku wysokiej dostępności
  • Dokumentacja dodatku wysokiej dostępności
  • Skonfiguruj replikację systemu SAP HANA w Scale-Up w klastrze Pacemaker, gdy systemy plików HANA znajdują się na udostępnieniach NFS
• Dokumentacja systemu RHEL specyficzna dla platformy Azure:
  • Zasady obsługi klastrów wysokiej dostępności RHEL — Maszyny wirtualne platformy Microsoft Azure jako elementy członkowskie klastra
  • Instalowanie i konfigurowanie klastra wysokiej dostępności systemu Red Hat Enterprise Linux 7.4 (i nowszych) na platformie Microsoft Azure
  • Skonfiguruj rozszerzoną replikację systemu SAP HANA w klastrze Pacemaker, gdy systemy plików HANA znajdują się na udziałach NFS
• Wolumeny NFS v4.1 na platformie Azure NetApp Files dla SAP HANA

Przegląd

Tradycyjnie w środowisku skalowalnym w górę wszystkie systemy plików platformy SAP HANA są instalowane z magazynu lokalnego. Konfigurowanie wysokiej dostępności replikacji systemu SAP HANA w systemie Red Hat Enterprise Linux jest publikowane w temacie Konfigurowanie replikacji systemu SAP HANA w systemie RHEL.

Aby osiągnąć wysoką dostępność systemu SAP HANA w konfiguracji skalowania w górę na udziałach NFS Azure NetApp Files, potrzebujemy dodatkowej konfiguracji zasobów w klastrze, aby zasoby HANA mogły zostać odzyskane, gdy jeden węzeł utraci dostęp do udziałów NFS na Azure NetApp Files. Klaster zarządza instalacjami systemu plików NFS, umożliwiając monitorowanie kondycji zasobów. Zależności między instalacjami systemu plików a zasobami sap HANA są wymuszane.

.

Systemy plików SAP HANA są instalowane w udziałach NFS przy użyciu usługi Azure NetApp Files w każdym węźle. Systemy /hana/dataplików , /hana/logi /hana/shared są unikatowe dla każdego węzła.

Zamontowane na node1 (hanadb1):

• 10.32.2.4:/hanadb1-data-mnt00001 na /hana/data
• 10.32.2.4:/hanadb1-log-mnt00001 na /hana/log
• 10.32.2.4:/hanadb1-shared-mnt00001 na /hana/shared

Zainstalowane w węźle Node2 (hanadb2):

• 10.32.2.4:/hanadb2-data-mnt00001 na /hana/data
• 10.32.2.4:/hanadb2-log-mnt00001 na /hana/log
• 10.32.2.4:/hanadb2-shared-mnt00001 na /hana/shared

Uwaga / Notatka

Systemy /hana/sharedplików , /hana/datai /hana/log nie są współużytkowane między dwoma węzłami. Każdy węzeł klastra ma własne oddzielne systemy plików.

Konfiguracja replikacji systemu SAP HANA używa dedykowanej wirtualnej nazwy hosta i wirtualnych adresów IP. Na platformie Azure moduł równoważenia obciążenia jest wymagany do korzystania z wirtualnego adresu IP. Konfiguracja pokazana tutaj zawiera moduł równoważenia obciążenia z:

• Adres IP wejściowy: 10.32.0.10 dla hn1-db
• Port sondy: 62503

Konfigurowanie infrastruktury usługi Azure NetApp Files

Przed przystąpieniem do konfigurowania infrastruktury usługi Azure NetApp Files zapoznaj się z dokumentacją usługi Azure NetApp Files.

Usługa Azure NetApp Files jest dostępna w kilku regionach świadczenia usługi Azure. Sprawdź, czy wybrany region platformy Azure oferuje usługę Azure NetApp Files.

Aby uzyskać informacje na temat dostępności usługi Azure NetApp Files według regionu platformy Azure, zobacz Dostępność usługi Azure NetApp Files według regionu świadczenia usługi Azure.

Ważne uwagi

Podczas tworzenia woluminów usługi Azure NetApp Files dla systemów typu scale-up SAP HANA, należy pamiętać o ważnych zagadnieniach opisanych w woluminach NFS w wersji 4.1 w usłudze Azure NetApp Files dla SAP HANA.

Ustalanie rozmiaru bazy danych HANA w usłudze Azure NetApp Files

Przepływność woluminu usługi Azure NetApp Files jest funkcją rozmiaru woluminu i poziomu usługi, zgodnie z opisem w artykule Poziom usługi dla usługi Azure NetApp Files.

Podczas projektowania infrastruktury dla platformy SAP HANA na platformie Azure przy użyciu usługi Azure NetApp Files należy pamiętać o zaleceniach w woluminach NFS w wersji 4.1 w usłudze Azure NetApp Files for SAP HANA.

Konfiguracja w tym artykule jest przedstawiona przy użyciu prostych woluminów usługi Azure NetApp Files.

Ważne

W przypadku systemów produkcyjnych, w których wydajność jest kluczem, zalecamy ocenę i rozważenie użycia grupy woluminów aplikacji usługi Azure NetApp Files dla platformy SAP HANA.

Wdrażanie zasobów usługi Azure NetApp Files

W poniższych instrukcjach założono, że sieć wirtualna platformy Azure została już wdrożona. Zasoby i maszyny wirtualne usługi Azure NetApp Files, w których zostaną zainstalowane zasoby usługi Azure NetApp Files, muszą zostać wdrożone w tej samej sieci wirtualnej platformy Azure lub w równorzędnych sieciach wirtualnych platformy Azure.

1. Utwórz konto usługi NetApp w wybranym regionie platformy Azure, postępując zgodnie z instrukcjami w temacie Tworzenie konta usługi NetApp.

2. Skonfiguruj pulę pojemności usługi Azure NetApp Files, postępując zgodnie z instrukcjami w temacie Konfigurowanie puli pojemności usługi Azure NetApp Files.

   Architektura platformy HANA przedstawiona w tym artykule używa pojedynczej puli pojemności usługi Azure NetApp Files na poziomie usługi Ultra . W przypadku obciążeń HANA na platformie Azure zalecamy użycie usługi Azure NetApp Files na poziomie Ultra lub Premiumservice Level.

3. Delegowanie podsieci do usługi Azure NetApp Files zgodnie z opisem w instrukcjach w temacie Delegowanie podsieci do usługi Azure NetApp Files.

4. Wdróż woluminy usługi Azure NetApp Files, postępując zgodnie z instrukcjami w temacie Tworzenie woluminu NFS dla usługi Azure NetApp Files.

   Podczas wdrażania woluminów pamiętaj, aby wybrać wersję NFSv4.1. Wdróż woluminy w wyznaczonej podsieci dla usługi Azure NetApp Files. Adresy IP woluminów usługi Azure NetApp są przypisywane automatycznie.

   Należy pamiętać, że zasoby usługi Azure NetApp Files i maszyny wirtualne platformy Azure muszą znajdować się w tej samej sieci wirtualnej platformy Azure lub w równorzędnych sieciach wirtualnych platformy Azure. Na przykład hanadb1-data-mnt00001 i hanadb1-log-mnt00001 są nazwami woluminów i nfs://10.32.2.4/hanadb1-data-mnt00001nfs://10.32.2.4/hanadb1-log-mnt00001 ścieżkami plików dla woluminów usługi Azure NetApp Files.

   Na hanadb1:

   • Volume hanadb1-data-mnt00001 (nfs://10.32.2.4:/hanadb1-data-mnt00001)
   • Volume hanadb1-log-mnt00001 (nfs://10.32.2.4:/hanadb1-log-mnt00001)
   • Volume hanadb1-shared-mnt00001 (nfs://10.32.2.4:/hanadb1-shared-mnt00001)

   Na hanadb2:

   • Volume hanadb2-data-mnt00001 (nfs://10.32.2.4:/hanadb2-data-mnt00001)
   • Volume hanadb2-log-mnt00001 (nfs://10.32.2.4:/hanadb2-log-mnt00001)
   • Volume hanadb2-shared-mnt00001 (nfs://10.32.2.4:/hanadb2-shared-mnt00001)

Uwaga / Notatka

Wszystkie polecenia do zainstalowania /hana/shared w tym artykule są prezentowane dla woluminów NFSv4.1 /hana/shared . Jeśli woluminy /hana/shared zostały wdrożone jako woluminy NFSv3, nie zapomnij dostosować polecenia montowania dla /hana/shared dla NFSv3.

Przygotowywanie infrastruktury

Witryna Azure Marketplace zawiera obrazy kwalifikowane dla platformy SAP HANA z dodatkiem wysokiej dostępności, którego można użyć do wdrażania nowych maszyn wirtualnych przy użyciu różnych wersji oprogramowania Red Hat.

Ręczne wdrażanie maszyn wirtualnych z systemem Linux za pośrednictwem witryny Azure Portal

W tym dokumencie założono, że grupa zasobów, sieć wirtualna platformy Azure i podsieć zostały już wdrożone.

Wdrażanie maszyn wirtualnych dla platformy SAP HANA. Wybierz odpowiedni obraz systemu RHEL, który jest obsługiwany przez system HANA. Maszynę wirtualną można wdrożyć w dowolnej z opcji dostępności: zestawu skalowania maszyn wirtualnych, strefy dostępności lub zestawu dostępności.

Ważne

Upewnij się, że wybrany system operacyjny ma certyfikat SAP dla platformy SAP HANA na określonych typach maszyn wirtualnych, które mają być używane we wdrożeniu. Możesz wyszukać typy maszyn wirtualnych z certyfikatem SAP HANA i ich wersje systemu operacyjnego w platformach IaaS certyfikowanych dla SAP HANA. Upewnij się, że zapoznasz się ze szczegółami typu maszyny wirtualnej, aby uzyskać pełną listę wersji systemu operacyjnego obsługiwanych przez platformę SAP HANA dla określonego typu maszyny wirtualnej.

Konfigurowanie modułu równoważenia obciążenia platformy Azure

Podczas konfigurowania maszyny wirtualnej masz możliwość utworzenia nowego lub wybrania istniejącego modułu równoważenia obciążenia w sekcji sieciowej. Wykonaj poniższe kroki, aby skonfigurować standardowy moduł równoważenia obciążenia na potrzeby konfiguracji bazy danych HANA o wysokiej dostępności.

Portal Azure

Wykonaj kroki opisane w temacie Tworzenie modułu równoważenia obciążenia, aby skonfigurować standardowy moduł równoważenia obciążenia dla systemu SAP o wysokiej dostępności przy użyciu witryny Azure Portal. Podczas konfigurowania modułu równoważenia obciążenia należy wziąć pod uwagę następujące kwestie:

1. Konfiguracja adresu IP front-endu: Utwórz adres IP front-endu. Wybierz tę samą sieć wirtualną i nazwę podsieci co maszyny wirtualne bazy danych.
2. Pula zaplecza: utwórz pulę zaplecza i dodaj maszyny wirtualne bazy danych.
3. Reguły ruchu przychodzącego: utwórz regułę równoważenia obciążenia. Wykonaj te same kroki dla obu reguł równoważenia obciążenia.
   • Adres IP frontonu: wybierz adres IP frontonu.
   • Pula zaplecza: Wybierz pulę zaplecza.
   • Porty wysokiej dostępności: wybierz tę opcję.
   • Protokół: wybierz pozycję TCP.
   • Sonda kondycji: utwórz sondę kondycji z następującymi szczegółami:
     • Protokół: wybierz pozycję TCP.
     • Port: na przykład 625<nr instancji>.
     • Interwał: wprowadź wartość 5.
     • Próg sondy: wprowadź 2.
   • Limit czasu bezczynności (w minutach): wprowadź wartość 30.
   • Włącz pływający adres IP: wybierz tę opcję.

Uwaga / Notatka

Właściwość konfiguracji sondy zdrowotnej numberOfProbes, znana w portalu jako próg niezdrowości, nie jest uwzględniana. Aby kontrolować liczbę pomyślnych lub nieudanych kolejnych sond, ustaw właściwość probeThreshold na wartość 2. Obecnie nie można ustawić tej właściwości przy użyciu portalu Azure, dlatego użyj Azure CLI lub polecenia PowerShell.

Interfejs wiersza polecenia platformy Azure

# 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

Rozwiń, aby zobaczyć pełny kod CLI

# Define variables for Resource Group, and Database VMs.

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

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

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

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

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

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

PowerShell

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

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

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

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

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

Rozwiń, aby wyświetlić pełny kod programu PowerShell

# Define variables for Resource Group, and Database VMs.

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

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

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

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

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

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

Aby uzyskać więcej informacji na temat wymaganych portów dla platformy SAP HANA, przeczytaj rozdział Połączenia z bazami danych dzierżaw w przewodniku Bazy danych dzierżaw SAP HANA lub SAP Nota 2388694.

Uwaga / Notatka

Jeśli maszyny wirtualne bez publicznych adresów IP są umieszczane w wewnętrznym wystąpieniu Standardowej usługi Azure Load Balancer w puli zaplecza, nie ma wychodzącej łączności z Internetem, chyba że zostanie wykonana dodatkowa konfiguracja umożliwiająca routing do publicznych punktów końcowych. Aby uzyskać więcej informacji na temat uzyskania łączności wychodzącej, zobacz Łączność publicznego punktu końcowego dla maszyn wirtualnych za pomocą standardowej usługi Azure Load Balancer w scenariuszach wysokiej dostępności SAP.

Ważne

Nie włączaj znaczników czasu TCP na maszynach wirtualnych umieszczonych za Azure Load Balancerem. Włączenie sygnatur czasowych protokołu TCP może spowodować niepowodzenie sond kondycji. Ustaw parametr net.ipv4.tcp_timestamps na wartość 0. Aby uzyskać więcej informacji, zobacz sondy kondycyjne Load Balancer oraz notę SAP 2382421.

Instalowanie woluminu usługi Azure NetApp Files

1. [A] Tworzenie punktów instalacji dla woluminów bazy danych HANA.

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

2. [A] Sprawdź ustawienie domeny NFS. Upewnij się, że domena jest skonfigurowana jako domyślna domena usługi Azure NetApp Files, czyli defaultv4iddomain.com, a mapowanie jest ustawione na nikogo.

   sudo cat /etc/idmapd.conf
   

   Przykładowy wynik:

   [General]
   Domain = defaultv4iddomain.com
   [Mapping]
   Nobody-User = nobody
   Nobody-Group = nobody
   

   Ważne

   Upewnij się, że domena systemu plików NFS na /etc/idmapd.conf maszynie wirtualnej jest zgodna z domyślną konfiguracją domeny w usłudze Azure NetApp Files: defaultv4iddomain.com. Jeśli istnieje niezgodność między konfiguracją domeny na kliencie NFS (czyli maszyną wirtualną) i serwerem NFS (czyli konfiguracją usługi Azure NetApp Files), wówczas uprawnienia do plików na woluminach usługi Azure NetApp Files zainstalowanych na maszynach wirtualnych są wyświetlane jako nobody.

3. [1] Zainstaluj woluminy specyficzne dla węzła w węźle 1 (hanadb1).

   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-shared-mnt00001 /hana/shared
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-log-mnt00001 /hana/log
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-data-mnt00001 /hana/data
   

4. [2] Zainstaluj woluminy specyficzne dla węzła w węźle Node2 (hanadb2).

   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-shared-mnt00001 /hana/shared
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-log-mnt00001 /hana/log
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-data-mnt00001 /hana/data
   

5. [A] Sprawdź, czy wszystkie woluminy HANA są zainstalowane przy użyciu protokołu NFS w wersji NFSv4.

   sudo nfsstat -m
   

   Sprawdź, czy flaga vers jest ustawiona na 4.1. Przykład z bazy danych hanadb1:

   /hana/log from 10.32.2.4:/hanadb1-log-mnt00001
   Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4
   /hana/data from 10.32.2.4:/hanadb1-data-mnt00001
   Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4
   /hana/shared from 10.32.2.4:/hanadb1-shared-mnt00001
   Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4
   

6. [A] Sprawdź nfs4_disable_idmapping. Powinna być ustawiona wartość Y. Aby utworzyć strukturę katalogów, w której znajduje się nfs4_disable_idmapping , uruchom polecenie instalacji. Nie można ręcznie utworzyć katalogu w obszarze /sys/modules , ponieważ dostęp jest zarezerwowany dla jądra i sterowników.

   Sprawdź element nfs4_disable_idmapping.

   sudo cat /sys/module/nfs/parameters/nfs4_disable_idmapping
   

   Jeśli musisz ustawić wartość nfs4_disable_idmapping na:

   sudo echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
   

   Ustaw konfigurację na stałą.

   sudo echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
   

   Aby uzyskać więcej informacji na temat zmiany parametru nfs_disable_idmapping , zobacz Bazę wiedzy Red Hat.

Instalacja oprogramowania SAP HANA

1. [A] Skonfiguruj rozpoznawanie nazw hostów dla wszystkich hostów.

   Możesz użyć serwera DNS lub zmodyfikować /etc/hosts plik na wszystkich węzłach. W tym przykładzie pokazano, jak używać /etc/hosts pliku. Zastąp adres IP i nazwę hosta w następujących poleceniach:

   sudo vi /etc/hosts
   

   Wstaw następujące wiersze w /etc/hosts pliku. Zmień adres IP i nazwę hosta, aby pasować do twojego środowiska.

   10.32.0.4   hanadb1
   10.32.0.5   hanadb2
   

2. [A] Przygotowanie systemu operacyjnego do uruchamiania oprogramowania SAP HANA w usłudze Azure NetApp z systemem plików NFS zgodnie z opisem w temacie SAP Note 3024346 — Linux Kernel Settings for NetApp NFS (Ustawienia jądra systemu Linux dla systemu plików NetApp NFS). Utwórz plik /etc/sysctl.d/91-NetApp-HANA.conf konfiguracji dla ustawień konfiguracji usługi NetApp.

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

   Dodaj następujące wpisy w pliku konfiguracji.

   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
   

3. [A] Utwórz plik konfiguracji /etc/sysctl.d/ms-az.conf z większą liczbą ustawień optymalizacji.

   sudo vi /etc/sysctl.d/ms-az.conf
   

   Dodaj następujące wpisy w pliku konfiguracji.

   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
   

   Wskazówka

   Unikaj jawnego ustawiania net.ipv4.ip_local_port_range i net.ipv4.ip_local_reserved_ports w plikach konfiguracyjnych sysctl, aby umożliwić agentowi hosta SAP zarządzanie zakresami portów. Aby uzyskać więcej informacji, zobacz SAP Uwaga 2382421.

4. [A] Dostosuj sunrpc ustawienia zgodnie z zaleceniami w temacie SAP Note 3024346 — Ustawienia jądra systemu Linux dla systemu plików NetApp NFS.

   sudo vi /etc/modprobe.d/sunrpc.conf
   

   Wstaw następujący wiersz:

   options sunrpc tcp_max_slot_table_entries=128
   

5. [A] Wykonaj konfigurację systemu operacyjnego RHEL dla platformy HANA.

   Skonfiguruj system operacyjny zgodnie z opisem w następujących informacjach SAP na podstawie wersji systemu RHEL:

   • 2292690 — SAP HANA DB: zalecane ustawienia systemu operacyjnego dla RHEL 7
   • 2777782 — SAP HANA DB: zalecane ustawienia systemu operacyjnego dla systemu RHEL 8
   • 3108302 — SAP HANA DB: zalecane ustawienia systemu operacyjnego dla systemu RHEL 9
   • 3057467 — który pakiet compat-sap-c++ jest potrzebny dla oprogramowania SAP w systemie RHEL?

6. [A] Zainstaluj oprogramowanie SAP HANA, postępując zgodnie z dokumentacją systemu SAP.

7. [A] Konfigurowanie zapory.

   Utwórz regułę zapory dla portu probe usługi Azure Load Balancer.

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

Konfigurowanie replikacji systemu SAP HANA

Wykonaj kroki opisane w temacie Konfigurowanie replikacji systemu SAP HANA w celu skonfigurowania replikacji systemu SAP HANA.

Konfiguracja klastra

W tej sekcji opisano kroki wymagane do bezproblemowego działania klastra, gdy platforma SAP HANA jest zainstalowana w udziałach NFS przy użyciu usługi Azure NetApp Files.

Utwórz klaster Pacemaker

Wykonaj kroki opisane w temacie Konfigurowanie programu Pacemaker w systemie Red Hat Enterprise Linux na platformie Azure, aby utworzyć podstawowy klaster Pacemaker dla tego serwera HANA.

Ważne

Za pomocą systemowego programu SAP Startup Framework wystąpienia SAP HANA mogą być teraz zarządzane przez systemd. Minimalna wymagana wersja systemu Red Hat Enterprise Linux (RHEL) to RHEL 8 dla systemu SAP. Jak opisano w artykule SAP Note 3189534, wszelkie nowe instalacje SAP HANA SPS07 rewizji 70 lub nowszej albo aktualizacje systemów HANA do HANA 2.0 SPS07 rewizji 70 lub nowszej, platforma SAP Startup framework zostanie automatycznie zarejestrowana z systemd.

W przypadku korzystania z rozwiązań wysokiej dostępności do zarządzania replikacją systemu SAP HANA w połączeniu z wystąpieniami SAP HANA obsługiwanymi przez systemd (zapoznaj się z artykułem SAP Note 3189534), należy wykonać dodatkowe kroki, aby zapewnić, że klaster wysokiej dostępności może zarządzać wystąpieniem SAP bez zakłóceń ze strony systemd. Dlatego w przypadku systemu SAP HANA zintegrowanego z systemd, dodatkowe kroki opisane w artykule Red Hat KBA 7029705 należy wykonać we wszystkich węzłach klastra.

Implementowanie haka replikacji systemu Python SAPHanaSR

Ten krok jest ważny, aby zoptymalizować integrację z klastrem i poprawić wykrywanie, kiedy potrzebne jest przełączenie awaryjne klastra. Zdecydowanie zalecamy skonfigurowanie haka języka Python SAPHanaSR. Wykonaj kroki opisane w temacie Implement the Python system replication hook SAPHanaSR.

Konfigurowanie zasobów systemu plików

W tym przykładzie każdy węzeł klastra ma własne systemy /hana/sharedplików NFS HANA , /hana/datai /hana/log.

1. [1] Przełącz klaster w tryb konserwacji.

   sudo pcs property set maintenance-mode=true
   

2. [1] Utwórz zasoby systemu plików dla instalacji hanadb1 .

   sudo pcs resource create hana_data1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-data-mnt00001 directory=/hana/data fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs
   sudo pcs resource create hana_log1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-log-mnt00001 directory=/hana/log fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs
   sudo pcs resource create hana_shared1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-shared-mnt00001 directory=/hana/shared fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs
   

3. [2] Utwórz zasoby systemu plików dla instalacji hanadb2 .

   sudo pcs resource create hana_data2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-data-mnt00001 directory=/hana/data fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs
   sudo pcs resource create hana_log2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-log-mnt00001 directory=/hana/log fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs
   sudo pcs resource create hana_shared2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-shared-mnt00001 directory=/hana/shared fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs
   

   Atrybut OCF_CHECK_LEVEL=20 jest dodawany do operacji monitorowania, dzięki czemu każdy monitor wykonuje test odczytu/zapisu w systemie plików. Bez tego atrybutu operacja monitorowania sprawdza tylko, czy system plików jest zainstalowany. Może to być problem, ponieważ w przypadku utraty łączności system plików może pozostać zainstalowany, mimo że jest niedostępny.

   Atrybut on-fail=fence jest również dodawany do operacji monitorowania. W przypadku tej opcji, jeśli operacja monitorowania zakończy się niepowodzeniem w węźle, ten węzeł jest natychmiast ogrodzony. Bez tej opcji domyślne zachowanie polega na zatrzymaniu wszystkich zasobów, które zależą od zasobu, którego działanie zakończyło się niepowodzeniem, ponowne uruchomienie zasobu, a następnie uruchomienie wszystkich zasobów, które zależą od zasobu, który zakończył się niepowodzeniem.

   Nie tylko to zachowanie może trwać długo, gdy zasób SAPHana zależy od zasobu, który zakończył się niepowodzeniem, ale może również całkowicie zakończyć się niepowodzeniem. Zasób SAPHana nie może zatrzymać się pomyślnie, jeśli serwer NFS, który przechowuje pliki wykonywalne HANA, jest niedostępny.

   Sugerowane wartości limitu czasu umożliwiają zasobom klastra wytrzymanie wstrzymania specyficznego dla protokołu związanego z odnawianiem dzierżawy NFSv4.1. Aby uzyskać więcej informacji, zobacz NFS in NetApp Best Practice (Najlepsze praktyki). Limity czasu w poprzedniej konfiguracji mogą wymagać dostosowania do określonego ustawienia SAP.

   W przypadku obciążeń wymagających wyższej przepływności rozważ użycie opcji montowania nconnect, jak opisano w woluminach NFS w wersji 4.1 na Azure NetApp Files dla SAP HANA. Sprawdź, czy nconnect obsługuje w wersji systemu Linux.

4. [1] Konfigurowanie ograniczeń lokalizacji.

   Skonfiguruj ograniczenia lokalizacji, aby upewnić się, że zasoby, które zarządzają unikatowymi punktami montowania hanadb1, nigdy nie mogą być uruchomione na hanadb2 i odwrotnie.

   sudo pcs constraint location hanadb1_nfs rule score=-INFINITY resource-discovery=never \#uname eq hanadb2
   sudo pcs constraint location hanadb2_nfs rule score=-INFINITY resource-discovery=never \#uname eq hanadb1
   

   Opcja resource-discovery=never jest ustawiona, ponieważ unikatowe monty dla każdego węzła dzielą ten sam punkt montowania. Na przykład hana_data1 używa punktu instalacji /hana/data, a hana_data2 także używa punktu instalacji /hana/data. Współużytkowanie tego samego punktu instalacji może spowodować wynik fałszywie dodatni dla operacji sondy, gdy stan zasobu jest sprawdzany podczas uruchamiania klastra, co z kolei może spowodować niepotrzebne zachowanie odzyskiwania. Aby uniknąć tego scenariusza, ustaw wartość resource-discovery=never.

5. [1] Konfigurowanie zasobów atrybutów.

   Konfigurowanie zasobów atrybutów. Te atrybuty są ustawione na wartość true, jeśli są zainstalowane wszystkie instalacji systemu plików NFS węzła (/hana/data, /hana/log, i /hana/data). W przeciwnym razie są one ustawione na wartość false.

   sudo pcs resource create hana_nfs1_active ocf:pacemaker:attribute active_value=true inactive_value=false name=hana_nfs1_active
   sudo pcs resource create hana_nfs2_active ocf:pacemaker:attribute active_value=true inactive_value=false name=hana_nfs2_active
   

6. [1] Konfigurowanie ograniczeń lokalizacji.

   Skonfiguruj ograniczenia lokalizacji, aby upewnić się, że zasób atrybutu hanadb1 nigdy nie działa w bazie danych hanadb2 i odwrotnie.

   sudo pcs constraint location hana_nfs1_active avoids hanadb2
   sudo pcs constraint location hana_nfs2_active avoids hanadb1
   

7. [1] Tworzenie ograniczeń kolejności.

   Skonfiguruj ograniczenia porządkowania, aby zasoby atrybutów węzła uruchamiały się dopiero po zamontowaniu wszystkich montowań NFS węzła.

   sudo pcs constraint order hanadb1_nfs then hana_nfs1_active
   sudo pcs constraint order hanadb2_nfs then hana_nfs2_active
   

   Wskazówka

   Jeśli konfiguracja obejmuje systemy plików, poza grupą hanadb1_nfs lub hanadb2_nfs, dołącz sequential=false opcję , aby nie było zależności porządkowania między systemami plików. Wszystkie systemy plików muszą zaczynać się przed hana_nfs1_active, ale nie muszą uruchamiać się w żadnej kolejności względem siebie. Aby uzyskać więcej informacji, zobacz How do I configure SAP HANA System Replication in Scale-Up in a Pacemaker cluster when the HANA file systems are on NFS shares (Jak skonfigurować replikację systemu SAP HANA w Scale-Up w klastrze Pacemaker, gdy systemy plików HANA znajdują się w udziałach NFS

Konfigurowanie zasobów klastra SAP HANA

1. Wykonaj kroki opisane w temacie Tworzenie zasobów klastra SAP HANA , aby utworzyć zasoby sap HANA w klastrze. Po utworzeniu zasobów SAP HANA należy utworzyć ograniczenie reguły lokalizacji między zasobami SAP HANA a systemami plików (montowanie NFS).

2. [1] Konfigurowanie ograniczeń między zasobami sap HANA a instalacjami systemu plików NFS.

   Ograniczenia reguły lokalizacji są ustawiane tak, aby zasoby SAP HANA mogły być uruchamiane w węźle tylko wtedy, gdy są zamontowane wszystkie punkty montowania NFS węzła.

   sudo pcs constraint location SAPHanaTopology_HN1_03-clone rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
   

   W systemie RHEL 7.x:

   sudo pcs constraint location SAPHana_HN1_03-master rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
   

   W systemie RHEL 8.x/9.x:

   sudo pcs constraint location SAPHana_HN1_03-clone rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
   

3. [1] Skonfiguruj ograniczenia kolejności, tak aby zasoby SAP w węźle zatrzymały się przed zatrzymaniem dowolnego z punktów montowania NFS.

   pcs constraint order stop SAPHanaTopology_HN1_03-clone then stop hanadb1_nfs
   pcs constraint order stop SAPHanaTopology_HN1_03-clone then stop hanadb2_nfs
   

   W systemie RHEL 7.x:

   pcs constraint order stop SAPHana_HN1_03-master then stop hanadb1_nfs
   pcs constraint order stop SAPHana_HN1_03-master then stop hanadb2_nfs
   

   W systemie RHEL 8.x/9.x:

   pcs constraint order stop SAPHana_HN1_03-clone then stop hanadb1_nfs
   pcs constraint order stop SAPHana_HN1_03-clone then stop hanadb2_nfs
   

   Wyjmij klaster z trybu konserwacji.

   sudo pcs property set maintenance-mode=false
   

   Sprawdź stan klastra i wszystkie zasoby.

   Uwaga / Notatka

   Ten artykuł zawiera odwołania do terminu, którego firma Microsoft już nie używa. Po usunięciu terminu z oprogramowania usuniemy go z tego artykułu.

   sudo pcs status
   

   Przykładowy wynik:

   Online: [ hanadb1 hanadb2 ]
   
   Full list of resources:
   
   rsc_hdb_azr_agt(stonith:fence_azure_arm):  Started hanadb1
   
   Resource Group: hanadb1_nfs
   hana_data1 (ocf::heartbeat:Filesystem):Started hanadb1
   hana_log1  (ocf::heartbeat:Filesystem):Started hanadb1
   hana_shared1   (ocf::heartbeat:Filesystem):Started hanadb1
   
   Resource Group: hanadb2_nfs
   hana_data2 (ocf::heartbeat:Filesystem):Started hanadb2
   hana_log2  (ocf::heartbeat:Filesystem):Started hanadb2
   hana_shared2   (ocf::heartbeat:Filesystem):Started hanadb2
   
   hana_nfs1_active   (ocf::pacemaker:attribute): Started hanadb1
   hana_nfs2_active   (ocf::pacemaker:attribute): Started hanadb2
   
   Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
   Started: [ hanadb1 hanadb2 ]
   
   Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
   Masters: [ hanadb1 ]
   Slaves: [ hanadb2 ]
   
   Resource Group: g_ip_HN1_03
   nc_HN1_03  (ocf::heartbeat:azure-lb):  Started hanadb1
   vip_HN1_03 (ocf::heartbeat:IPaddr2):   Started hanadb1
   

Konfigurowanie replikacji systemu z obsługą aktywnego/odczytu platformy HANA w klastrze Pacemaker

Począwszy od SAP HANA 2.0 SPS 01, SAP umożliwia aktywne/opcje odczytu dla replikacji systemu SAP HANA, gdzie systemy pomocnicze mogą być aktywnie wykorzystywane do obsługi obciążeń intensywnych w odczycie. Aby obsługiwać taką konfigurację w klastrze, wymagany jest drugi wirtualny adres IP, który umożliwia klientom dostęp do pomocniczej bazy danych SAP HANA z obsługą odczytu.

Aby upewnić się, że dodatkowa lokalizacja replikacji będzie nadal dostępna po przejęciu zasobów, klaster musi przenieść wirtualny adres IP wraz z dodatkowym zasobem SAPHana.

Dodatkowa konfiguracja, która jest wymagana do zarządzania HANA aktywną/odczytującą replikacją systemu z dodatkowym wirtualnym adresem IP w klastrze Red Hat HA, jest opisana w instrukcji Konfigurowania replikacji systemu HANA Active/Read-Enabled w klastrze Pacemaker.

Przed kontynuowaniem upewnij się, że w pełni skonfigurowałeś klaster Red Hat High Availability Cluster zarządzający bazą danych SAP HANA zgodnie z opisem w poprzednich sekcjach dokumentacji.

Testowanie konfiguracji klastra

W tej sekcji opisano sposób testowania konfiguracji.

1. Przed rozpoczęciem testu upewnij się, że Pacemaker nie wykazuje żadnych nieudanych akcji (sprawdź status za pomocą pcs), nie ma żadnych nieoczekiwanych ograniczeń lokalizacji (na przykład pozostałości po teście migracji) oraz że replikacja systemu HANA jest w stanie synchronizacji, na przykład z systemReplicationStatus:

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

2. Sprawdź konfigurację klastra pod kątem scenariusza awarii, gdy węzeł utraci dostęp do udziału NFS (/hana/shared).

   Agenci zasobów SAP HANA zależą od plików binarnych, które są przechowywane na /hana/shared, aby przeprowadzać procesy failover. System /hana/shared plików jest instalowany za pośrednictwem systemu plików NFS w przedstawionym scenariuszu.

   Trudno jest zasymulować sytuację, w której jeden z serwerów traci dostęp do zasobu NFS. Jako test można ponownie zainstalować system plików jako tylko do odczytu. To podejście sprawdza, czy klaster może przejść w tryb failover, jeśli dostęp do /hana/shared zostanie utracony w aktywnym węźle.

   Oczekiwany wynik: Podczas tworzenia /hana/shared jako systemu plików tylko do odczytu atrybut zasobu OCF_CHECK_LEVEL, hana_shared1 który wykonuje operacje odczytu/zapisu w systemach plików, kończy się niepowodzeniem. System nie może zapisywać niczego w systemie plików ani przeprowadzać przełączenia zasobów HANA. Ten sam wynik jest oczekiwany, gdy węzeł HANA utraci dostęp do udziałów NFS.

   Stan zasobu przed rozpoczęciem testu:

   sudo pcs status
   

   Przykładowy wynik:

   Full list of resources:
    rsc_hdb_azr_agt        (stonith:fence_azure_arm):      Started hanadb1
   
    Resource Group: hanadb1_nfs
        hana_data1 (ocf::heartbeat:Filesystem):    Started hanadb1
        hana_log1  (ocf::heartbeat:Filesystem):    Started hanadb1
        hana_shared1       (ocf::heartbeat:Filesystem):    Started hanadb1
   
   Resource Group: hanadb2_nfs
        hana_data2 (ocf::heartbeat:Filesystem):    Started hanadb2
        hana_log2  (ocf::heartbeat:Filesystem):    Started hanadb2
        hana_shared2       (ocf::heartbeat:Filesystem):    Started hanadb2
   
    hana_nfs1_active       (ocf::pacemaker:attribute):     Started hanadb1
    hana_nfs2_active       (ocf::pacemaker:attribute):     Started hanadb2
   
    Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
        Started: [ hanadb1 hanadb2 ]
   
    Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
        Masters: [ hanadb1 ]
        Slaves: [ hanadb2 ]
   
    Resource Group: g_ip_HN1_03
        nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hanadb1
        vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hanadb1
   

   Możesz umieścić /hana/shared w trybie tylko do odczytu w aktywnym węźle klastra, używając następującego polecenia:

   sudo mount -o ro 10.32.2.4:/hanadb1-shared-mnt00001 /hana/shared
   

   hanadb spowoduje ponowne uruchomienie lub wyłączenie zasilania w oparciu o akcję ustawioną na stonith (pcs property show stonith-action). Gdy serwer (hanadb1) nie działa, zasób platformy HANA zostanie przeniesiony do hanadb2. Stan klastra można sprawdzić z poziomu hanadb2.

   sudo pcs status
   

   Przykładowy wynik:

   Full list of resources:
   
    rsc_hdb_azr_agt        (stonith:fence_azure_arm):      Started hanadb2
   
    Resource Group: hanadb1_nfs
        hana_data1 (ocf::heartbeat:Filesystem):    Stopped
        hana_log1  (ocf::heartbeat:Filesystem):    Stopped
        hana_shared1       (ocf::heartbeat:Filesystem):    Stopped
   
    Resource Group: hanadb2_nfs
        hana_data2 (ocf::heartbeat:Filesystem):    Started hanadb2
        hana_log2  (ocf::heartbeat:Filesystem):    Started hanadb2
        hana_shared2       (ocf::heartbeat:Filesystem):    Started hanadb2
   
    hana_nfs1_active       (ocf::pacemaker:attribute):     Stopped
    hana_nfs2_active       (ocf::pacemaker:attribute):     Started hanadb2
   
    Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
        Started: [ hanadb2 ]
        Stopped: [ hanadb1 ]
   
    Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
        Masters: [ hanadb2 ]
        Stopped: [ hanadb1 ]
   
    Resource Group: g_ip_HN1_03
        nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hanadb2
        vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hanadb2
   

   Zalecamy dokładne przetestowanie konfiguracji klastra SAP HANA, wykonując również testy opisane w temacie Konfigurowanie replikacji systemu SAP HANA w systemie RHEL.

Dalsze kroki

• Planowanie i implementacja usługi Azure Virtual Machines dla oprogramowania SAP
• Wdrażanie usługi Azure Virtual Machines dla oprogramowania SAP
• Wdrażanie usługi Azure Virtual Machines DBMS dla oprogramowania SAP
• Wolumeny NFS v4.1 na platformie Azure NetApp Files dla SAP HANA