Wysoka dostępność oprogramowania SAP HANA na maszynach wirtualnych platformy Azure na serwerze SUSE Linux Enterprise Server

Aby ustanowić wysoką dostępność w lokalnym wdrożeniu sap HANA, możesz użyć replikacji systemu SAP HANA lub magazynu udostępnionego.

Obecnie na maszynach wirtualnych platformy Azure replikacja systemu SAP HANA na platformie Azure jest jedyną obsługiwaną funkcją wysokiej dostępności.

Replikacja systemu SAP HANA składa się z jednego węzła podstawowego i co najmniej jednego węzła pomocniczego. Zmiany danych w węźle podstawowym są replikowane synchronicznie lub asynchronicznie do węzła pomocniczego.

W tym artykule opisano sposób wdrażania i konfigurowania maszyn wirtualnych, instalowania struktury klastra oraz instalowania i konfigurowania replikacji systemu SAP HANA.

Przed rozpoczęciem zapoznaj się z następującymi uwagami i dokumentami sap:

• 1928533 notatek SAP. Uwaga 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, systemu operacyjnego i bazy danych.
  • Wymagane wersje 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 2205917 ma zalecane ustawienia systemu operacyjnego dla systemu SUSE Linux Enterprise Server 12 (SLES 12) dla aplikacji SAP.
• Firma SAP Note 2684254 ma zalecane ustawienia systemu operacyjnego dla systemu operacyjnego SUSE Linux Enterprise Server 15 (SLES 15) dla aplikacji SAP.
• Oprogramowanie SAP Note 2235581 ma obsługiwane systemy operacyjne SAP HANA
• Program SAP Note 2178632 zawiera szczegółowe informacje o wszystkich metrykach monitorowania zgłaszanych 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 dla systemu Linux na platformie Azure.
• Program SAP Note 1984787 zawiera ogólne informacje o systemie SUSE Linux Enterprise Server 12.
• Program SAP Note 1999351 zawiera więcej informacji dotyczących rozwiązywania problemów z rozszerzeniem rozszerzonego monitorowania platformy Azure dla oprogramowania SAP.
• Program SAP Note 401162 zawiera informacje o sposobie unikania błędów "adres już używany" podczas konfigurowania replikacji systemu HANA.
• Witryna wiki pomocy technicznej sap community zawiera wszystkie wymagane uwagi SAP dla systemu Linux.
• Certyfikowane platformy IaaS oprogramowania SAP HANA.
• Przewodnik planowania i implementacji usługi Azure Virtual Machines dla oprogramowania SAP w systemie Linux .
• Przewodnik wdrażania usługi Azure Virtual Machines dla oprogramowania SAP w systemie Linux .
• Wdrażanie systemu SAP w systemie Linux w usłudze Azure Virtual Machines DBMS.
• Przewodniki dotyczące najlepszych rozwiązań systemu SUSE Linux Enterprise Server for SAP Applications 15 oraz przewodniki dotyczące najlepszych rozwiązań dla systemu SUSE Linux Enterprise Server for SAP Applications 12:
  • Konfigurowanie infrastruktury zoptymalizowanej pod kątem wydajności usługi SAP HANA SR (SLES dla aplikacji SAP). Ten przewodnik zawiera wszystkie informacje wymagane do skonfigurowania replikacji systemu SAP HANA na potrzeby programowania lokalnego. Skorzystaj z tego przewodnika jako punktu odniesienia.
  • Konfigurowanie infrastruktury zoptymalizowanej pod kątem kosztów (SLES dla aplikacji SAP HANA SR).

Planowanie wysokiej dostępności oprogramowania SAP HANA

Aby uzyskać wysoką dostępność, zainstaluj platformę SAP HANA na dwóch maszynach wirtualnych. Dane są replikowane przy użyciu replikacji systemu HANA.

Konfiguracja replikacji systemu SAP HANA używa dedykowanej nazwy hosta wirtualnego i wirtualnych adresów IP. Na platformie Azure potrzebny jest moduł równoważenia obciążenia do wdrożenia wirtualnego adresu IP.

Na powyższej ilustracji przedstawiono przykładowy moduł równoważenia obciążenia, który ma następujące konfiguracje:

• Adres IP frontonu: 10.0.0.13 dla HN1-db
• Port sondy: 62503

Przygotowywanie infrastruktury

Agent zasobów dla platformy SAP HANA jest zawarty w systemie SUSE Linux Enterprise Server for SAP Applications. Obraz dla systemu SUSE Linux Enterprise Server dla aplikacji SAP 12 lub 15 jest dostępny w witrynie Azure Marketplace. Możesz użyć obrazu do wdrożenia nowych maszyn wirtualnych.

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

W tym dokumencie przyjęto założenie, że grupa zasobów, usługa Azure Virtual Network i podsieć zostały już wdrożone.

Wdrażanie maszyn wirtualnych dla platformy SAP HANA. Wybierz odpowiedni obraz SLES obsługiwany dla systemu 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 na platformach IaaS certyfikowanych na platformie 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 lub wybrania wyjścia z modułu równoważenia obciążenia w sekcji dotyczącej sieci. Wykonaj poniższe kroki, aby skonfigurować standardowy moduł równoważenia obciążenia na potrzeby konfiguracji bazy danych HANA o wysokiej dostępności.

Witryna Azure Portal

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 frontonu: utwórz adres IP frontonu. 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<instance-no.>.
     • Interwał: wprowadź wartość 5.
     • Próg sondy: wprowadź wartość 2.
   • Limit czasu bezczynności (w minutach): wprowadź wartość 30.
   • Włącz pływający adres IP: wybierz tę opcję.

Uwaga

Właściwość numberOfProbeskonfiguracji sondy kondycji , inaczej znana jako próg złej kondycji w portalu, nie jest uwzględniana. Aby kontrolować liczbę pomyślnych lub zakończonych niepowodzeniem kolejnych sond, ustaw właściwość probeThreshold na 2wartość . Obecnie nie można ustawić tej właściwości przy użyciu witryny Azure Portal, dlatego użyj interfejsu wiersza polecenia platformy Azure lub polecenia programu 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 wyświetlić pełny kod interfejsu wiersza polecenia

# 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

Program 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żawy w przewodniku Bazy danych dzierżaw sap HANA lub 2388694 sap Note.

Uwaga

Jeśli maszyny wirtualne, które nie mają publicznych adresów IP, są umieszczane w puli zaplecza wewnętrznego (bez publicznego adresu IP) standardowego wystąpienia usługi Azure Load Balancer, domyślna konfiguracja nie jest wychodzącą łącznością internetową. Aby zezwolić na routing do publicznych punktów końcowych, możesz wykonać dodatkowe kroki. Aby uzyskać szczegółowe informacje na temat uzyskiwania łączności wychodzącej, zobacz Publiczna łączność punktów końcowych dla maszyn wirtualnych przy użyciu usługi Azure usługa Load Balancer w warstwie Standardowa w scenariuszach wysokiej dostępności oprogramowania SAP.

Ważne

• Nie włączaj sygnatur czasowych PROTOKOŁU TCP na maszynach wirtualnych platformy Azure, które znajdują się za usługą Azure Load Balancer. Włączenie sygnatur czasowych protokołu TCP powoduje niepowodzenie sond kondycji. Ustaw parametr net.ipv4.tcp_timestamps na 0. Aby uzyskać szczegółowe informacje, zobacz Load Balancer health probes or SAP note 2382421 (Sondy kondycji usługi Load Balancer lub sap) 2382421.
• Aby zapobiec zmianie ręcznie ustawionej net.ipv4.tcp_timestamps wartości z 0 powrotem na 1, zaktualizuj program saptune do wersji 3.1.1 lub nowszej. Aby uzyskać więcej informacji, zobacz saptune 3.1.1 — Czy muszę zaktualizować?.

Tworzenie klastra Pacemaker

Wykonaj kroki opisane w temacie Konfigurowanie programu Pacemaker na serwerze SUSE Linux Enterprise Server na platformie Azure , aby utworzyć podstawowy klaster Pacemaker dla tego serwera HANA. Możesz użyć tego samego klastra Pacemaker dla systemów SAP HANA i SAP NetWeaver (A)SCS.

Instalowanie platformy SAP HANA

Kroki opisane w tej sekcji korzystają z następujących prefiksów:

• [A]: Krok dotyczy wszystkich węzłów.
• [1]: Krok dotyczy tylko węzła 1.
• [2]: Krok dotyczy tylko węzła 2 klastra Pacemaker.

Zastąp <placeholders> wartościami instalacji oprogramowania SAP HANA.

1. [A] Skonfiguruj układ dysku przy użyciu Menedżera woluminów logicznych (LVM).

   Zalecamy używanie lvm dla woluminów, które przechowują dane i pliki dziennika. W poniższym przykładzie przyjęto założenie, że maszyny wirtualne mają cztery dołączone dyski danych używane do tworzenia dwóch woluminów.

   1. Uruchom to polecenie, aby wyświetlić listę wszystkich dostępnych dysków:

      /dev/disk/azure/scsi1/lun*
      

      Przykładowe wyjście:

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

   2. Utwórz woluminy fizyczne dla wszystkich dysków, których chcesz użyć:

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

   3. Utwórz grupę woluminów dla plików danych. Użyj jednej grupy woluminów dla plików dziennika i jednej grupy woluminów dla udostępnionego katalogu sap HANA:

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

   4. Utwórz woluminy logiczne.

      Wolumin liniowy jest tworzony podczas używania lvcreate bez przełącznika -i . Zalecamy utworzenie woluminu rozłożonego w celu uzyskania lepszej wydajności operacji we/wy. Wyrównuj rozmiary pasków do wartości opisanych w konfiguracjach magazynu maszyn wirtualnych SAP HANA. Argument -i powinien być liczbą bazowych woluminów fizycznych, a -I argumentem jest rozmiar paska.

      Jeśli na przykład dwa woluminy fizyczne są używane dla woluminu danych, -i argument przełącznika jest ustawiony na 2, a rozmiar paska dla woluminu danych to 256KiB. Jeden wolumin fizyczny jest używany dla woluminu dziennika, więc żadne przełączniki nie -i -I są jawnie używane dla poleceń woluminu dziennika.

      Ważne

      Jeśli używasz więcej niż jednego woluminu fizycznego dla każdego woluminu danych, woluminu dziennika lub udostępnionego woluminu, użyj przełącznika -i i ustaw go jako liczbę woluminów fizycznych bazowych. Podczas tworzenia woluminu rozłożonego użyj przełącznika -I , aby określić rozmiar paska.

      Aby uzyskać zalecane konfiguracje magazynu, w tym rozmiary rozłożone i liczbę dysków, zobacz Konfiguracje magazynu maszyn wirtualnych SAP HANA.

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

   5. Utwórz katalogi instalacji i skopiuj unikatowy identyfikator (UUID) wszystkich woluminów logicznych:

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

   6. Edytuj plik /etc/fstab, aby utworzyć fstab wpisy dla trzech woluminów logicznych:

      sudo vi /etc/fstab
      

   7. Wstaw następujące wiersze w pliku /etc/fstab :

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

   8. Zainstaluj nowe woluminy:

      sudo mount -a
      

2. [A] Skonfiguruj układ dysku przy użyciu dysków zwykłych.

   W przypadku systemów demonstracyjnych można umieścić dane i pliki dziennika HANA na jednym dysku.

   1. Utwórz partycję na /dev/disk/azure/scsi1/lun0 i sformatuj ją przy użyciu systemu XFS:

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

   2. Wstaw ten wiersz w pliku /etc/fstab :

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

   3. Utwórz katalog docelowy i zainstaluj dysk:

      sudo mkdir /hana
      sudo mount -a
      

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

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

   1. Edytuj plik /etc/hosts:

      sudo vi /etc/hosts
      

   2. Wstaw następujące wiersze w pliku /etc/hosts . Zmień adresy IP i nazwy hostów, aby odpowiadały twojemu środowisku.

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

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

Konfigurowanie replikacji systemu SAP HANA 2.0

Kroki opisane w tej sekcji korzystają z następujących prefiksów:

• [A]: Krok dotyczy wszystkich węzłów.
• [1]: Krok dotyczy tylko węzła 1.
• [2]: Krok dotyczy tylko węzła 2 klastra Pacemaker.

Zastąp <placeholders> wartościami instalacji oprogramowania SAP HANA.

1. [1] Utwórz bazę danych dzierżawy.

   Jeśli używasz oprogramowania SAP HANA 2.0 lub SAP HANA MDC, utwórz bazę danych dzierżawy dla systemu SAP NetWeaver.

   Uruchom następujące polecenie jako <adm sid>platformy HANA:

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

2. [1] Konfigurowanie replikacji systemu w pierwszym węźle:

   Najpierw wykonaj kopię zapasową baz danych jako <adm identyfikatora SID>platformy HANA:

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

   Następnie skopiuj pliki infrastruktury kluczy publicznych (PKI) systemu do lokacji dodatkowej:

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

   Utwórz lokację główną:

   hdbnsutil -sr_enable --name=<site 1>
   

3. [2] Konfigurowanie replikacji systemu w drugim węźle:

   Zarejestruj drugi węzeł, aby rozpocząć replikację systemu.

   Uruchom następujące polecenie jako <adm sid>platformy HANA:

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

Implementowanie agentów zasobów platformy HANA

SusE udostępnia dwa różne pakiety oprogramowania dla agenta zasobów Pacemaker do zarządzania platformą SAP HANA. Pakiety oprogramowania SAPHanaSR i SAPHanaSR-angi używają nieco innej składni i parametrów i nie są zgodne. Aby uzyskać szczegółowe informacje i różnice między platformami SAPHanaSR i SAPHanaSR-angi, zobacz informacje o wersji systemu SUSE i dokumentację . Ten dokument obejmuje oba pakiety na osobnych kartach w odpowiednich sekcjach.

Ostrzeżenie

Nie zamieniaj pakietu SAPHanaSR przez sapHanaSR-angi w już skonfigurowanym klastrze. Uaktualnienie z platformy SAPHanaSR do platformy SAPHanaSR-angi wymaga określonej procedury.

1. [A] Zainstaluj pakiety wysokiej dostępności oprogramowania SAP HANA:

SAPHanaSR

Uruchom następujące polecenie, aby zainstalować pakiety wysokiej dostępności:

sudo zypper install SAPHanaSR

SAPHanaSR-angi

Ważne

Oprogramowanie SAPHanaSR-angi ma minimalne wymaganie dotyczące wersji oprogramowania SAP HANA 2.0 SPS 05 i SUSE SLES dla aplikacji SAP 15 z dodatkiem SP4 lub nowszym.

Uruchom następujące polecenie, aby zainstalować pakiety wysokiej dostępności:

sudo zypper install SAPHanaSR-angi

Konfigurowanie dostawców wysokiej dostępności/odzyskiwania po awarii platformy SAP HANA

Dostawcy wysokiej dostępności/odzyskiwania po awarii platformy SAP HANA optymalizują integrację z klastrem i poprawiają wykrywanie, gdy potrzebny jest tryb failover klastra. Główny skrypt zaczepienia to SAPHanaSR (dla pakietu SAPHanaSR) / susHanaSR (dla platformy SAPHanaSR-angi). Zdecydowanie zalecamy skonfigurowanie haka języka Python SAPHanaSR/susHanaSR. W przypadku platformy HANA 2.0 SPS 05 lub nowszej zalecamy zaimplementowanie zarówno oprogramowania SAPHanaSR/susHanaSR, jak i haków susChkSrv.

Hak susChkSrv rozszerza funkcjonalność głównego dostawcy SAPHanaSR/susHanaSR HA. Działa, gdy proces HANA hdbindexserver ulega awarii. W przypadku awarii pojedynczego procesu platforma HANA zwykle próbuje go uruchomić ponownie. Ponowne uruchomienie procesu indexserver może zająć dużo czasu, podczas którego baza danych HANA nie odpowiada.

W przypadku zaimplementowania polecenia susChkSrv wykonywana jest natychmiastowa i konfigurowalna akcja. Akcja wyzwala przejście w tryb failover w skonfigurowanym przedziale czasu zamiast oczekiwania na ponowne uruchomienie procesu hdbindexserver w tym samym węźle.

1. [A] Zatrzymaj platformę HANA w obu węzłach.

Uruchom następujący kod jako <sap-sid>adm:

sapcontrol -nr <instance number> -function StopSystem

2. [A] Zainstaluj haki replikacji systemu HANA. Punkty zaczepienia muszą być zainstalowane w obu węzłach bazy danych HANA.

   Napiwek

   Hak języka Python SAPHanaSR można zaimplementować tylko dla platformy HANA 2.0. Pakiet SAPHanaSR musi być co najmniej w wersji 0.153.
   Hak SAPHanaSR-angi Python można zaimplementować tylko dla platformy HANA 2.0 SPS 05 lub nowszej.
   Element susChkSrv Python hook wymaga zainstalowania oprogramowania SAP HANA 2.0 SPS 05 oraz 0.161.1_BF lub nowszej wersji sapHanaSR.

   SAPHanaSR

   1. [A] Dostosuj global.ini w każdym węźle klastra.

      Jeśli wymagania dotyczące haka susChkSrv nie są spełnione, usuń cały [ha_dr_provider_suschksrv] blok z następujących parametrów. Zachowanie można dostosować susChkSrv za pomocą parametru action_on_lost . Prawidłowe wartości to [ ignorefence | | stop | kill].

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

      Jeśli wskażesz ścieżkę parametru do lokalizacji domyślnej /usr/share/SAPHanaSR , kod punktu zaczepienia języka Python zostanie automatycznie zaktualizowany za pośrednictwem aktualizacji systemu operacyjnego lub aktualizacji pakietów. Platforma HANA używa aktualizacji kodu zaczepienia po następnym ponownym uruchomieniu. Za pomocą opcjonalnej własnej ścieżki, takiej jak /hana/shared/myHooks, można rozdzielić aktualizacje systemu operacyjnego z używanej wersji punktu zaczepienia.

   2. [A] Klaster wymaga konfiguracji sudoers w każdym węźle klastra dla <sap-sid>adm. W tym przykładzie jest to osiągane przez utworzenie nowego pliku.

      Uruchom następujące polecenie jako katalog główny. Zastąp <wartość sid> małymi literami IDENTYFIKATOR systemu SAP, <identyfikator SID> według wielkich liter identyfikatora systemu SAP i <lokacjiA/B> wybranymi nazwami lokacji HANA.

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

   Aby uzyskać szczegółowe informacje na temat implementowania haka replikacji systemu SAP HANA, zobacz Konfigurowanie dostawców wysokiej dostępności/odzyskiwania po awarii platformy HANA.

   SAPHanaSR-angi

   1. [A] Dostosuj global.ini w każdym węźle klastra.

      Jeśli zdecydujesz się nie używać zalecanego haka susChkSrv, usuń cały [ha_dr_provider_suschksrv] blok z następujących parametrów. Zachowanie można dostosować susChkSrv za pomocą parametru action_on_lost . Prawidłowe wartości to [ ignorefence | | stop | kill].

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

      Jeśli wskażesz ścieżkę parametru do lokalizacji domyślnej /usr/share/SAPHanaSR-angi , kod punktu zaczepienia języka Python zostanie automatycznie zaktualizowany za pośrednictwem aktualizacji systemu operacyjnego lub aktualizacji pakietów. Platforma HANA używa aktualizacji kodu zaczepienia po następnym ponownym uruchomieniu. Za pomocą opcjonalnej własnej ścieżki, takiej jak /hana/shared/myHooks, można rozdzielić aktualizacje systemu operacyjnego z używanej wersji punktu zaczepienia.

   2. [A] Klaster wymaga konfiguracji sudoers w każdym węźle klastra dla <sap-sid>adm. W tym przykładzie jest to osiągane przez utworzenie nowego pliku.

      Uruchom następujące polecenie jako katalog główny. Zastąp <wartość sid> małymi literami IDENTYFIKATOR systemu SAP, <identyfikator SID> według wielkich liter identyfikatora systemu SAP i <lokacjiA/B> wybranymi nazwami lokacji HANA.

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

      Aby uzyskać szczegółowe informacje na temat implementowania haka replikacji systemu SAP HANA, zobacz Konfigurowanie dostawców wysokiej dostępności/odzyskiwania po awarii platformy HANA.

---

3. [A] Uruchom platformę SAP HANA w obu węzłach. Uruchom następujące polecenie jako <sap-sid>adm:

   sapcontrol -nr <instance number> -function StartSystem 
   

4. [1] Sprawdź instalację haka. Uruchom następujące polecenie jako <sap-sid>adm w aktywnej lokacji replikacji systemu HANA:

   SAPHanaSR

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

   SAPHanaSR-angi

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

---

5. [1] Sprawdź instalację haka susChkSrv. Uruchom następujące polecenie jako <sap-sid>adm na maszynach wirtualnych HANA:

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

Tworzenie zasobów klastra SAP HANA

1. [1] Najpierw utwórz zasób topologii HANA.

SAPHanaSR

Uruchom następujące polecenia w jednym z węzłów klastra Pacemaker:

sudo crm configure property maintenance-mode=true

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

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

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

SAPHanaSR-angi

Uruchom następujące polecenia w jednym z węzłów klastra Pacemaker:

sudo crm configure property maintenance-mode=true

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

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

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

2. [1] Następnie utwórz zasoby platformy HANA:

SAPHanaSR

Uwaga

Ten artykuł zawiera odwołania do terminów, których firma Microsoft już nie używa. Po usunięciu tych warunków z oprogramowania usuniemy je z tego artykułu.

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

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

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

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

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

SAPHanaSR-angi

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

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

SapHanaSR-angi dodaje nowego agenta zasobów SAPHanaFilesystem do monitorowania dostępu do odczytu/zapisu do /hana/shared/SID. System operacyjny statyczny instaluje system plików /hana/shared/SID z każdym hostem zawierającym wpisy w pliku /etc/fstab. System SAPHanaFilesystem i pacemaker nie instaluje systemu plików dla platformy HANA.

Zalecamy zaimplementowanie systemu SAPHanaFilesystem w przypadku używania systemu plików NFS dla lokalizacji /hana/shared/SID. Gdy /hana/shared/SID znajduje się na urządzeniu blokowym, takim jak dysk zarządzany platformy Azure, użycie systemu SAPHanaFilesystem jest opcjonalne.

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

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

3. [1] Kontynuuj korzystanie z zasobów klastra dla wirtualnych adresów IP, wartości domyślnych i ograniczeń.

SAPHanaSR

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

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

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

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

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

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

sudo crm configure property priority-fencing-delay=30

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

SAPHanaSR-angi

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

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

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

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

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

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

sudo crm configure property priority-fencing-delay=30

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

Ważne

Zalecamy ustawienie wartości AUTOMATED_REGISTER na false wartość tylko podczas wykonywania dokładnych testów pracy w trybie failover, aby zapobiec automatycznemu zarejestrowaniu wystąpienia podstawowego w trybie failed jako pomocniczego. Po pomyślnym zakończeniu testów trybu failover ustaw wartość AUTOMATED_REGISTER true, aby po przejęciu replikacja systemu została automatycznie wznowione.

Upewnij się, że stan klastra to OK i że uruchomiono wszystkie zasoby. Nie ma znaczenia, w którym węźle działają zasoby.

sudo crm_mon -r

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

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

W systemie SAP HANA 2.0 SPS 01 i nowszych wersjach system SAP umożliwia aktywną/odczytową konfigurację replikacji systemu SAP HANA. W tym scenariuszu pomocnicze systemy replikacji systemu SAP HANA mogą być aktywnie używane na potrzeby obciążeń intensywnie korzystających z odczytu.

Aby obsługiwać tę konfigurację w klastrze, wymagany jest drugi wirtualny adres IP, aby klienci mogli uzyskać dostęp do pomocniczej bazy danych SAP HANA z obsługą odczytu. Aby upewnić się, że lokacja replikacji dodatkowej będzie nadal dostępna po przejęciu, klaster musi przenieść wirtualny adres IP wokół z pomocniczym zasobem SAPHana.

W tej sekcji opisano dodatkowe kroki wymagane do zarządzania replikacją systemu z obsługą aktywnego/odczytu platformy HANA w klastrze wysokiej dostępności SUSE, który używa drugiego wirtualnego adresu IP.

Przed kontynuowaniem upewnij się, że został w pełni skonfigurowany klaster wysokiej dostępności SUSE, który zarządza bazą danych SAP HANA zgodnie z opisem we wcześniejszych sekcjach.

Konfigurowanie modułu równoważenia obciążenia na potrzeby replikacji systemu z włączoną obsługą aktywnego/odczytu

Aby wykonać dodatkowe kroki aprowizacji drugiego wirtualnego adresu IP, upewnij się, że skonfigurowano usługę Azure Load Balancer zgodnie z opisem w temacie Ręczne wdrażanie maszyn wirtualnych z systemem Linux za pośrednictwem witryny Azure Portal.

W przypadku modułu równoważenia obciążenia w warstwie Standardowa wykonaj te dodatkowe kroki dla tego samego modułu równoważenia obciążenia, który został utworzony wcześniej.

1. Utwórz drugą pulę adresów IP frontonu:
   1. Otwórz moduł równoważenia obciążenia, wybierz pulę adresów IP frontonu i wybierz pozycję Dodaj.
   2. Wprowadź nazwę drugiej puli adresów IP frontonu (na przykład hana-secondaryIP).
   3. Ustaw wartość Przypisanie na Statyczne i wprowadź adres IP (na przykład 10.0.0.14).
   4. Wybierz przycisk OK.
   5. Po utworzeniu nowej puli adresów IP frontonu zanotuj adres IP frontonu.
2. Utwórz sondę kondycji:
   1. W module równoważenia obciążenia wybierz pozycję Sondy kondycji i wybierz pozycję Dodaj.
   2. Wprowadź nazwę nowej sondy kondycji (na przykład hana-secondaryhp).
   3. Wybierz tcp jako protokół i numer> wystąpienia portu 626.< Zachowaj wartość Interwał ustawioną na 5, a wartość progu złej kondycji ustawiona na 2.
   4. Wybierz przycisk OK.
3. Utwórz reguły równoważenia obciążenia:
   1. W module równoważenia obciążenia wybierz pozycję Reguły równoważenia obciążenia, a następnie wybierz pozycję Dodaj.
   2. Wprowadź nazwę nowej reguły modułu równoważenia obciążenia (na przykład hana-secondarylb).
   3. Wybierz adres IP frontonu, pulę zaplecza i utworzoną wcześniej sondę kondycji (na przykład hana-secondaryIP, hana-backend i hana-secondaryhp).
   4. Wybierz pozycję Porty wysokiej dostępności.
   5. Zwiększ limit czasu bezczynności do 30 minut.
   6. Upewnij się, że włączono pływający adres IP.
   7. Wybierz przycisk OK.

Konfigurowanie replikacji systemu z obsługą aktywnego/odczytu na platformie HANA

Kroki konfigurowania replikacji systemu HANA zostały opisane w temacie Konfigurowanie replikacji systemu SAP HANA 2.0. Jeśli wdrażasz pomocniczy scenariusz z obsługą odczytu, podczas konfigurowania replikacji systemu w drugim węźle uruchom następujące polecenie jako <adm identyfikatora SID>platformy HANA:

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

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

Dodawanie pomocniczego zasobu wirtualnego adresu IP

Drugi wirtualny adres IP i odpowiednie ograniczenie kolokacji można skonfigurować przy użyciu następujących poleceń:

SAPHanaSR

crm configure property maintenance-mode=true

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

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

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

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

crm configure property maintenance-mode=false

SAPHanaSR-angi

crm configure property maintenance-mode=true

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

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

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

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

crm configure property maintenance-mode=false

Upewnij się, że stan klastra to OK i że uruchomiono wszystkie zasoby. Drugi wirtualny adres IP działa w lokacji dodatkowej wraz z zasobem pomocniczym SAPHana.

sudo crm_mon -r

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

W następnej sekcji opisano typowy zestaw testów trybu failover do wykonania.

Zagadnienia dotyczące testowania klastra HANA skonfigurowanego przy użyciu pomocniczego z obsługą odczytu:

• Podczas migracji zasobu klastra SAPHana_<HANA SID>_HDB<instance number> do hn1-db-1programu drugi wirtualny adres IP jest przenoszony do .hn1-db-0 Jeśli skonfigurowano AUTOMATED_REGISTER="false" i replikacja systemu HANA nie jest rejestrowana automatycznie, drugi wirtualny adres IP jest uruchamiany, hn1-db-0 ponieważ serwer jest dostępny, a usługi klastra są w trybie online.

• Podczas testowania awarii serwera drugie zasoby wirtualnego adresu IP (rsc_secip_<HANA SID>_HDB<instance number>) i zasób portu modułu równoważenia obciążenia platformy Azure (rsc_secnc_<HANA SID>_HDB<instance number>) są uruchamiane na serwerze podstawowym wraz z podstawowymi zasobami wirtualnego adresu IP. Gdy serwer pomocniczy nie działa, aplikacje połączone z bazą danych HANA z włączoną obsługą odczytu łączą się z podstawową bazą danych HANA. Zachowanie jest oczekiwane, ponieważ nie chcesz, aby aplikacje połączone z bazą danych HANA z włączoną obsługą odczytu mogły być niedostępne, gdy serwer pomocniczy jest niedostępny.

• Gdy serwer pomocniczy jest dostępny, a usługi klastra są w trybie online, drugi wirtualny adres IP i zasoby portów są automatycznie przenoszone do serwera pomocniczego, mimo że replikacja systemu HANA może nie być zarejestrowana jako pomocnicza. Przed uruchomieniem usług klastra na tym serwerze upewnij się, że zarejestrowano pomocniczą bazę danych HANA jako włączoną do odczytu. Zasób klastra wystąpień platformy HANA można skonfigurować tak, aby automatycznie zarejestrował pomocniczą, ustawiając parametr AUTOMATED_REGISTER="true".

• Podczas pracy w trybie failover i powrotu istniejące połączenia dla aplikacji, które następnie używają drugiego wirtualnego adresu IP do nawiązania połączenia z bazą danych HANA, mogą zostać przerwane.

Testowanie konfiguracji klastra

W tej sekcji opisano sposób testowania konfiguracji. Każdy test zakłada, że użytkownik jest zalogowany jako użytkownik główny i że główny serwer sap HANA jest uruchomiony na maszynie hn1-db-0 wirtualnej.

Testowanie migracji

Przed rozpoczęciem testu upewnij się, że program Pacemaker nie ma żadnych nieudanych akcji (uruchom crm_mon -r), że nie ma żadnych nieoczekiwanych ograniczeń lokalizacji (na przykład pozostawienia testu migracji) i że platforma HANA jest w stanie synchronizacji, na przykład przez uruchomienie polecenia SAPHanaSR-showAttr.

SAPHanaSR

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

SAPHanaSR-angi

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

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

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

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

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

Aby przeprowadzić migrację węzła głównego platformy SAP HANA, uruchom następujące polecenie:

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

Klaster przeprowadzi migrację węzła głównego platformy SAP HANA i grupy zawierającej wirtualny adres IP do hn1-db-1.

Po zakończeniu crm_mon -r migracji dane wyjściowe wyglądają następująco:

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

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

W przypadku AUTOMATED_REGISTER="false"klastra nie można ponownie uruchomić bazy danych HANA, która zakończyła się niepowodzeniem, ani zarejestrować jej względem nowego podstawowego elementu w systemie hn1-db-0. W takim przypadku skonfiguruj wystąpienie platformy HANA jako pomocnicze, uruchamiając następujące polecenie:

su - <hana sid>adm

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

Migracja tworzy ograniczenia lokalizacji, które należy usunąć ponownie:

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

Należy również wyczyścić stan zasobu węzła pomocniczego:

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

Monitoruj stan zasobu platformy HANA przy użyciu polecenia crm_mon -r. Po uruchomieniu platformy hn1-db-0HANA dane wyjściowe wyglądają następująco:

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

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

Blokowanie komunikacji sieciowej

Stan zasobu przed rozpoczęciem testu:

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

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

Wykonaj regułę zapory, aby zablokować komunikację w jednym z węzłów.

# 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

Gdy węzły klastra nie mogą komunikować się ze sobą, istnieje ryzyko scenariusza podzielonego mózgu. W takich sytuacjach węzły klastra będą próbować jednocześnie ogrodzenia, co spowoduje wyścig ogrodzenia.

Podczas konfigurowania urządzenia ogrodzeniowego zaleca się skonfigurowanie pcmk_delay_max właściwości. Dlatego w przypadku scenariusza podziału mózgu klaster wprowadza losowe opóźnienie do pcmk_delay_max wartości, do akcji ogrodzenia w każdym węźle. Węzeł z najkrótszym opóźnieniem zostanie wybrany do ogrodzenia.

Ponadto, aby upewnić się, że węzeł z systemem głównym platformy HANA ma priorytet i wygra wyścig ogrodzenia w scenariuszu podzielonym mózgu, zaleca się ustawienie priority-fencing-delay właściwości w konfiguracji klastra. Dzięki włączeniu właściwości priority-fencing-delay klaster może wprowadzić dodatkowe opóźnienie w akcji ogrodzenia specjalnie na węźle hostujący zasób główny HANA, dzięki czemu węzeł może wygrać wyścig ogrodzenia.

Wykonaj poniższe polecenie, aby usunąć regułę zapory.

# 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

Testowanie ogrodzenia SBD

Konfigurację usługi SBD można przetestować, zabijając proces inquisitor:

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

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

Węzeł klastra <HANA SID>-db-<database 1> zostanie uruchomiony ponownie. Usługa Pacemaker może nie zostać ponownie uruchomiona. Upewnij się, że uruchamiasz go ponownie.

Testowanie ręcznego przejścia w tryb failover

Ręczne przejście w tryb failover można przetestować, zatrzymując usługę Pacemaker w węźle hn1-db-0 :

service pacemaker stop

Po przejściu w tryb failover możesz ponownie uruchomić usługę. Jeśli ustawisz wartość AUTOMATED_REGISTER="false", zasób SAP HANA w węźle hn1-db-0 nie może uruchomić się jako pomocniczy.

W takim przypadku skonfiguruj wystąpienie platformy HANA jako pomocnicze, uruchamiając następujące polecenie:

service pacemaker start
su - <hana sid>adm

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

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

Testy SUSE

Ważne

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

Uruchom wszystkie przypadki testowe wymienione w przewodniku Scenariusz zoptymalizowany pod kątem wydajności programu SAP HANA lub Przewodnik scenariusza zoptymalizowanego pod kątem kosztów platformy SAP HANA w zależności od scenariusza. Przewodniki wymienione w usłudze SLES można znaleźć na potrzeby najlepszych rozwiązań dotyczących oprogramowania SAP.

Poniższe testy to kopia opisów testów przewodnika SAP HANA SR Performance Optimized Scenario SUSE Linux Enterprise Server for SAP Applications 12 z dodatkiem SP1. Aby zapoznać się z aktualną wersją, zapoznaj się również z przewodnikiem. Przed rozpoczęciem testu upewnij się, że platforma HANA jest zsynchronizowana i upewnij się, że konfiguracja programu Pacemaker jest poprawna.

W poniższych opisach testów zakładamy PREFER_SITE_TAKEOVER="true" , że i AUTOMATED_REGISTER="false".

Uwaga

Następujące testy są przeznaczone do uruchamiania w sekwencji. Każdy test zależy od stanu wyjścia poprzedniego testu.

1. Test 1. Zatrzymaj podstawową bazę danych w węźle 1.

   Stan zasobu przed rozpoczęciem testu:

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

   Uruchom następujące polecenia jako <hana sid>adm w węźle hn1-db-0 :

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

   Program Pacemaker wykrywa zatrzymane wystąpienie platformy HANA i przechodzi w tryb failover do innego węzła. Po zakończeniu pracy w trybie failover wystąpienie platformy HANA w węźle hn1-db-0 zostanie zatrzymane, ponieważ program Pacemaker nie rejestruje węzła automatycznie jako pomocniczego oprogramowania HANA.

   Uruchom następujące polecenia, aby zarejestrować hn1-db-0 węzeł jako pomocniczy i wyczyścić zasób, który zakończył się niepowodzeniem:

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

   Stan zasobu po teście:

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

2. Test 2. Zatrzymaj podstawową bazę danych w węźle 2.

   Stan zasobu przed rozpoczęciem testu:

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

   Uruchom następujące polecenia jako <hana sid>adm w węźle hn1-db-1 :

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

   Program Pacemaker wykrywa zatrzymane wystąpienie platformy HANA i przechodzi w tryb failover do innego węzła. Po zakończeniu pracy w trybie failover wystąpienie platformy HANA w węźle hn1-db-1 zostanie zatrzymane, ponieważ program Pacemaker nie rejestruje węzła automatycznie jako pomocniczego oprogramowania HANA.

   Uruchom następujące polecenia, aby zarejestrować hn1-db-1 węzeł jako pomocniczy i wyczyścić zasób, który zakończył się niepowodzeniem:

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

   Stan zasobu po teście:

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

3. Test 3. Awaria podstawowej bazy danych w węźle 1.

   Stan zasobu przed rozpoczęciem testu:

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

   Uruchom następujące polecenia jako <hana sid>adm w węźle hn1-db-0 :

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

   Program Pacemaker wykrywa zabite wystąpienie platformy HANA i przechodzi w tryb failover do innego węzła. Po zakończeniu pracy w trybie failover wystąpienie platformy HANA w węźle hn1-db-0 zostanie zatrzymane, ponieważ program Pacemaker nie rejestruje węzła automatycznie jako pomocniczego oprogramowania HANA.

   Uruchom następujące polecenia, aby zarejestrować hn1-db-0 węzeł jako pomocniczy i wyczyścić zasób, który zakończył się niepowodzeniem:

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

   Stan zasobu po teście:

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

4. Test 4. Awaria podstawowej bazy danych w węźle 2.

   Stan zasobu przed rozpoczęciem testu:

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

   Uruchom następujące polecenia jako <hana sid>adm w węźle hn1-db-1 :

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

   Program Pacemaker wykrywa zabite wystąpienie platformy HANA i przechodzi w tryb failover do innego węzła. Po zakończeniu pracy w trybie failover wystąpienie platformy HANA w węźle hn1-db-1 zostanie zatrzymane, ponieważ program Pacemaker nie rejestruje węzła automatycznie jako pomocniczego oprogramowania HANA.

   Uruchom następujące polecenia, aby zarejestrować hn1-db-1 węzeł jako pomocniczy i wyczyścić zasób, który zakończył się niepowodzeniem.

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

   Stan zasobu po teście:

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

5. Test 5. Awaria węzła lokacji głównej (węzeł 1).

   Stan zasobu przed rozpoczęciem testu:

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

   Uruchom następujące polecenia jako katalog główny w węźle hn1-db-0 :

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

   Program Pacemaker wykrywa zabity węzeł klastra i ogrodzenia węzła. Gdy węzeł jest ogrodzony, program Pacemaker wyzwala przejęcie wystąpienia platformy HANA. Po ponownym uruchomieniu ogrodzonego węzła program Pacemaker nie uruchamia się automatycznie.

   Uruchom następujące polecenia, aby uruchomić narzędzie Pacemaker, wyczyścić komunikaty SBD dla hn1-db-0 węzła, zarejestrować hn1-db-0 węzeł jako pomocniczy i wyczyścić zasób, który zakończył się niepowodzeniem:

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

   Stan zasobu po teście:

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

6. Test 6. Awaria węzła lokacji dodatkowej (węzeł 2).

   Stan zasobu przed rozpoczęciem testu:

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

   Uruchom następujące polecenia jako katalog główny w węźle hn1-db-1 :

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

   Program Pacemaker wykrywa zabity węzeł klastra i ogrodzenia węzła. Gdy węzeł jest ogrodzony, program Pacemaker wyzwala przejęcie wystąpienia platformy HANA. Po ponownym uruchomieniu ogrodzonego węzła program Pacemaker nie uruchamia się automatycznie.

   Uruchom następujące polecenia, aby uruchomić narzędzie Pacemaker, wyczyścić komunikaty SBD dla hn1-db-1 węzła, zarejestrować hn1-db-1 węzeł jako pomocniczy i wyczyścić zasób, który zakończył się niepowodzeniem:

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

   Stan zasobu po teście:

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

7. Test 7. Zatrzymaj pomocniczą bazę danych w węźle 2.

   Stan zasobu przed rozpoczęciem testu:

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

   Uruchom następujące polecenia jako <hana sid>adm w węźle hn1-db-1 :

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

   Narzędzie Pacemaker wykrywa zatrzymane wystąpienie platformy HANA i oznacza zasób jako niepowodzenie w węźle hn1-db-1 . Program Pacemaker automatycznie uruchamia ponownie wystąpienie platformy HANA.

   Uruchom następujące polecenie, aby wyczyścić stan niepowodzenia:

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

   Stan zasobu po teście:

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

8. Test 8. Awaria pomocniczej bazy danych w węźle 2.

   Stan zasobu przed rozpoczęciem testu:

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

   Uruchom następujące polecenia jako <hana sid>adm w węźle hn1-db-1 :

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

   Narzędzie Pacemaker wykrywa zabite wystąpienie platformy HANA i oznacza zasób jako niepowodzenie w węźle hn1-db-1 . Uruchom następujące polecenie, aby wyczyścić stan niepowodzenia. Program Pacemaker automatycznie uruchamia ponownie wystąpienie platformy HANA.

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

   Stan zasobu po teście:

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

9. Test 9. Awaria węzła lokacji dodatkowej (węzeł 2) z dodatkową bazą danych HANA.

   Stan zasobu przed rozpoczęciem testu:

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

   Uruchom następujące polecenia jako katalog główny w węźle hn1-db-1 :

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

   Program Pacemaker wykrywa zabity węzeł klastra i ogrodzony węzeł. Po ponownym uruchomieniu ogrodzonego węzła program Pacemaker nie uruchamia się automatycznie.

   Uruchom następujące polecenia, aby uruchomić narzędzie Pacemaker, wyczyścić komunikaty SBD dla hn1-db-1 węzła i wyczyścić zasób, który zakończył się niepowodzeniem:

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

   Stan zasobu po teście:

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

10. Test 10: Awaria podstawowego serwera indeksowania bazy danych

    Ten test jest istotny tylko wtedy, gdy skonfigurowano punkt zaczepienia susChkSrv zgodnie z opisem w temacie Implementowanie agentów zasobów HANA.

    Stan zasobu przed rozpoczęciem testu:

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

    Uruchom następujące polecenia jako katalog główny w węźle hn1-db-0 :

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

    Po zakończeniu indeksowania serwer susChkSrv wykrywa zdarzenie i wyzwala akcję w węźle "hn1-db-0" i inicjuje proces przejęcia.

    Uruchom następujące polecenia, aby zarejestrować hn1-db-0 węzeł jako pomocniczy i wyczyścić zasób, który zakończył się niepowodzeniem:

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

    Stan zasobu po teście:

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

    Można wykonać porównywalny przypadek testowy, powodując awarię serwera indexserver w węźle pomocniczym. W przypadku awarii serwera indexserver hak susChkSrv rozpoznaje wystąpienie i inicjuje akcję w celu ogrodzenia węzła pomocniczego.

Następne 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