Red Hat Enterprise Linux 上の Azure VM でのSAP HANAの高可用性

オンプレミス開発では、HANA システムレプリケーションまたは共有ストレージを使用して、SAP HANAの高可用性 (HA) を確立できます。 Azure 仮想マシンでは、現在、Azure上の HANA システムレプリケーションが唯一サポートされている HA 関数です。

SAP HANA レプリケーションは、1 つのプライマリノードと少なくとも 1 つのセカンダリノードで構成されます。プライマリノードのデータに対する変更は、セカンダリノードに同期的または非同期的にレプリケートされます。

この記事では、仮想マシン (VM) のデプロイと構成、クラスターフレームワークのインストール、システムレプリケーションSAP HANAインストールおよび構成する方法について説明します。

サンプルの構成では、インストールのコマンドで、インスタンス番号として 03、HANA システム ID として HN1 が使用されています。

前提条件

次の SAP ノートと文書をまず確認してください。

SAP Note 1928533: 次の情報が含まれています。
- SAP ソフトウェアのデプロイでサポートされているAzure VM サイズの一覧。
- Azure VM サイズの重要な容量情報。
- サポートされる SAP ソフトウェア、およびオペレーティングシステム (OS) とデータベースの組み合わせ。
- Microsoft Azure上の Windows および Linux に必要な SAP カーネルバージョン。
SAP Note 2015553 Azure での SAP でサポートされる SAP ソフトウェアの展開の前提条件を示します。
SAP Note 2002167: Red Hat Enterprise Linux 用の OS 設定が推奨されています。
SAP Note 2009879 には、Red Hat Enterprise Linux のSAP HANAガイドラインがあります。
SAP Note 3108302 には、Red Hat Enterprise Linux 9.x のSAP HANAガイドラインがあります。
SAP Note 2178632 には、Azureで SAP について報告されたすべての監視メトリックに関する詳細情報が含まれています。
SAP Note 2191498 には、Azureの Linux に必要な SAP ホストエージェントのバージョンがあります。
SAP Note 2243692 には、Azureの Linux での SAP ライセンスに関する情報が含まれます。
SAP Note 1999351 には、AZURE Enhanced Monitoring Extension for SAP のトラブルシューティング情報が含まれています。
Azure 仮想マシン Linux 上の SAP の計画と実装
Azure 仮想マシン Linux 上の SAP のデプロイ (この記事)
Azure 仮想マシン Linux 上の SAP の DBMS デプロイ
SAP HANA Pacemaker クラスターでのシステムレプリケーション
RHEL HA のドキュメント:
Azure固有の RHEL ドキュメント:

概要

HA を実現するために、SAP HANAは 2 つの VM にインストールされます。データは、HANA システムレプリケーションを使用してレプリケートされます。

SAP HANAの高可用性概要を示す図。

SAP HANA システムレプリケーションのセットアップでは、専用の仮想ホスト名と仮想 IP アドレスが使用されます。 Azureでは、仮想 IP アドレスを使用するためにロードバランサーが必要です。表示されている構成は、次のものを含むロードバランサーを示しています。

フロントエンド IP アドレス: 10.0.0.13 (hn1-db)
プローブポート: 62503

インフラストラクチャの準備

Azure Marketplaceには、高可用性アドオンを使用したSAP HANAに限定されたイメージが含まれています。このイメージを使用して、さまざまなバージョンの Red Hat を使用して新しい VM をデプロイできます。

Azure ポータルを使用して Linux VM を手動でデプロイする

このドキュメントでは、リソースグループ、>Azureサブネットが既にデプロイされていることを前提としています。

SAP HANA用の VM をデプロイします。 HANA システムでサポートされている適切な RHEL イメージを選択します。 VM は、仮想マシンスケールセット、可用性ゾーン、可用性セットのいずれかの可用性オプションでデプロイできます。

重要

選択した OS が、デプロイで使用する予定の特定の VM の種類のSAP HANAに対して SAP 認定されていることを確認します。 SAP HANA認定 VM の種類とその OS リリースは、SAP HANA Certified IaaS Platforms で検索できます。 VM の種類の詳細を確認して、特定の VM の種類SAP HANAサポートされている OS リリースの完全な一覧を取得してください。

Azureロードバランサーを構成する

VM 構成中に、ネットワークセクションでロードバランサーを作成するか既存のものを選択する選択肢もあります。 HANA データベースの高可用性セットアップ用に Standard Load Balancer を設定するには、次の手順に従います。

Azure ポータルを使用して、Create ロードバランサーの手順に従って、高可用性 SAP システム用の Standard ロードバランサーを設定します。ロードバランサーのセットアップ時には、以下の点を考慮してください。

フロントエンド IP 構成: フロントエンド IP を作成します。お使いのデータベース仮想マシンと同じ仮想ネットワークとサブネットを選択します。
バックエンドプール: バックエンドプールを作成し、データベース VM を追加します。
インバウンド規則: 負荷分散規則を作成します。両方の負荷分散規則で同じ手順に従います。
- フロントエンド IP アドレス: フロントエンド IP を選択します。
- バックエンドプール: バックエンドプールを選択します。
- 高可用性ポート: このオプションを選択します。
- [プロトコル]: [TCP] を選択します。
- 正常性プローブ: 次の詳細を使って正常性プローブを作成します。
  - [プロトコル]: [TCP] を選択します。
  - ポート: 例: 625<インスタンス番号>。
  - サイクル間隔: 「5」と入力します。
  - プローブしきい値: 「2」と入力します。
- アイドルタイムアウト (分): 30を入力します。
- フローティング IP を有効にする: このオプションを選択します。

注

正常性プローブ構成プロパティ numberOfProbes (ポータルでは [異常なしきい値] とも呼ばれます) は考慮されません。成功または失敗した連続プローブの数を制御するには、プロパティ probeThreshold を 2 に設定します。現在、Azure ポータルを使用してこのプロパティを設定することはできないため、Azure CLI または PowerShell コマンドを使用します。

注

azure-cli v2.63.0 以降を使用します。 az versionを使用してバージョンを確認できます。

Azure CLI を使用して高可用性セットアップ用のスタンダードロードバランサーを作成するには、次の手順に従います。

# 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

展開して完全な 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

# 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

展開して完全な 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

SAP HANAに必要なポートの詳細については、「< テナントデータベースへの接続SAP HANAテナントデータベースガイドまたは SAP Note 2388694 の章を参照してください。

注

パブリック IP アドレスを持たない VM が Standard Azure Load Balancer の内部 (パブリック IP アドレスなし) インスタンスのバックエンドプールに配置されている場合、パブリックエンドポイントへのルーティングを許可する構成を増やさない限り、送信インターネット接続はありません。送信接続を実現する方法の詳細については、「 SAP 高可用性シナリオでのAzure Standard Load Balancerを使用した VM のエンドポイント接続の公開に関するページを参照してください。

重要

Azure Load Balancerの背後に配置Azure VM で TCP タイムスタンプを有効にしないでください。 TCP タイムスタンプを有効にすると正常性プローブが失敗する可能性があります。パラメーター net.ipv4.tcp_timestamps を 0 に設定します。詳細については、Load Balancerのヘルスプローブおよび SAP Note 2382421 を参照してください。

SAP HANAのインストール

このセクションの手順では、次のプレフィックスを使用します。

[A] :この手順はすべてのノードに適用されます。
[1] :この手順はノード 1 にのみ適用されます。
[2] :この手順は Pacemaker クラスターのノード 2 にのみ適用されます。

[A] ディスクレイアウトの設定:論理ボリュームマネージャー (LVM) 。

データおよびログファイルを格納するボリュームには、LVM を使用することをお勧めします。次の例は、VM に 4 つのデータディスクがアタッチされていて、これを使用して 2 つのボリュームを作成することを前提としています。

すべての使用できるディスクの一覧を出力します。
```
ls /dev/disk/azure/scsi1/lun*
```
出力例:
```
/dev/disk/azure/scsi1/lun0  /dev/disk/azure/scsi1/lun1  /dev/disk/azure/scsi1/lun2  /dev/disk/azure/scsi1/lun3
```
使用するすべてのディスクの物理ボリュームを作成します。
```
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
```
データファイル用のボリュームグループを作成します。ログファイルには 1 つのボリュームグループを使用し、1 つはSAP HANAの共有ディレクトリに使用します。
```
sudo vgcreate vg_hana_data_HN1 /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
sudo vgcreate vg_hana_log_HN1 /dev/disk/azure/scsi1/lun2
sudo vgcreate vg_hana_shared_HN1 /dev/disk/azure/scsi1/lun3
```
論理ボリュームを作成します。 lvcreate スイッチを指定せずに -i を使用すると、線形のボリュームが作成されます。 I/O パフォーマンスが向上するように、"ストライプ" ボリュームを作成することお勧めします。ストライプサイズを、SAP HANA VM ストレージ構成に記載されている値に合わせます。 -i 引数は、基になる物理ボリュームの数、-I 引数はストライプサイズにする必要があります。

このドキュメントでは、2 つの物理ボリュームが使用されるため、-i スイッチ引数は 2 に設定されます。データボリュームのストライプサイズは 256KiB です。ログボリューム用に物理ボリュームが 1 つ使用されるため、ログボリュームコマンドに対して -i および -I スイッチは明示的には使用されません。

重要

データ、ログ、または共有ボリュームごとに複数の物理ボリュームを使用する場合は、-i スイッチを使用して基になる物理ボリュームの番号に設定します。ストライプボリュームを作成するときにストライプサイズを指定するには、-I スイッチを使用します。ストライプサイズやディスク数など、推奨されるストレージ構成については、SAP HANA VM ストレージ構成を参照してください。次のレイアウト例は、特定のシステムサイズのパフォーマンスガイドラインを必ずしも満たしているとは限りません。これらは説明のみを目的としています。
```
sudo lvcreate -i 2 -I 256 -l 100%FREE -n hana_data vg_hana_data_HN1
sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_HN1
sudo lvcreate -l 100%FREE -n hana_shared vg_hana_shared_HN1
sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data
sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
sudo mkfs.xfs /dev/vg_hana_shared_HN1/hana_shared
```
マウントコマンドを発行してディレクトリをマウントしないでください。代わりに、 fstab に構成を入力し、構文を検証する最後の mount -a を発行します。まず、各ボリュームのマウントディレクトリを作成します。
```
sudo mkdir -p /hana/data
sudo mkdir -p /hana/log
sudo mkdir -p /hana/shared
```
次に、 fstab ファイルに次の行を挿入して、3 つの論理ボリュームの /etc/fstab エントリを作成します。
```
/dev/mapper/vg_hana_data_HN1-hana_data    /hana/data    xfs  defaults,nofail  0  2
/dev/mapper/vg_hana_log_HN1-hana_log    /hana/log    xfs  defaults,nofail  0  2
/dev/mapper/vg_hana_shared_HN1-hana_shared    /hana/shared    xfs  defaults,nofail  0  2
```
最後に、新しいボリュームをすべて一度にマウントします。
```
sudo mount -a
```
[A] すべてのホストにホスト名解決を設定します。

/etc/hosts で次のようなすべてのノードのエントリを作成することで、DNS サーバーを使用するか、すべてのノードで /etc/hosts ファイルを変更することができます。
```
10.0.0.5 hn1-db-0
10.0.0.6 hn1-db-1
```
[A] HANA 構成のための RHEL を実行します。

次のメモで説明されているように RHEL を構成します。
- 2777782 - SAP HANA DB: RHEL 8に推奨されるOS設定
- 3108302 - SAP HANA DB: RHEL 9 に推奨される OS 設定
- 3562919 - SAP HANA DB: RHEL 10 の推奨 OS 設定
- 3057467 - SAP on RHEL に必要な compat-sap-c++ パッケージはどれですか？
[A]SAP のドキュメントに従ってSAP HANAをインストールします。
[A] ファイアウォールを構成します。

Azure Load Balancer プローブポートのファイアウォール規則を作成します。
```
sudo firewall-cmd --zone=public --add-port=62503/tcp
sudo firewall-cmd --zone=public --add-port=62503/tcp --permanent
```

SAP HANA 2.0 システムレプリケーションの構成

このセクションの手順では、次のプレフィックスを使用します。

[A] :この手順はすべてのノードに適用されます。
[1] :この手順はノード 1 にのみ適用されます。
[2] :この手順は Pacemaker クラスターのノード 2 にのみ適用されます。

[A] ファイアウォールを構成します。

HANA システムレプリケーションおよびクライアントトラフィックを許可するファイアウォール規則を作成します。必要なポートは、すべての SAP 製品の TCP/IP ポートのページにあります。次のコマンドは、HANA 2.0 システムレプリケーションと、データベース SYSTEMDB、HN1 および NW1 へのクライアントトラフィックを許可する 1 つの例です。
```
 sudo firewall-cmd --zone=public --add-port={1128,1129,40302,40301,40307,40306,40303,40340,30340,30341,30342}/tcp --permanent
 sudo firewall-cmd --zone=public --add-port={1128,1129,40302,40301,40307,40306,40303,40340,30340,30341,30342}/tcp
```
[1] テナントデータベースを作成します。

<hanasid>adm として次のコマンドを実行します。
```
hdbsql -u SYSTEM -p "[passwd]" -i 03 -d SYSTEMDB 'CREATE DATABASE NW1 SYSTEM USER PASSWORD "<passwd>"'
```
[1] 最初のノードでシステムレプリケーションを構成します。

<hanasid>adm としてデータベースをバックアップします。
```
hdbsql -d SYSTEMDB -u SYSTEM -p "<passwd>" -i 03 "BACKUP DATA USING FILE ('initialbackupSYS')"
hdbsql -d HN1 -u SYSTEM -p "<passwd>" -i 03 "BACKUP DATA USING FILE ('initialbackupHN1')"
hdbsql -d NW1 -u SYSTEM -p "<passwd>" -i 03 "BACKUP DATA USING FILE ('initialbackupNW1')"
```
注

ローカルセキュアストア (LSS) を使用する場合、SAP HANAバックアップは自己完結型であり、暗号化ルートキーのバックアップパスワードを設定する必要があります。詳細な手順については、SAP Note 3571561 を参照してください。パスワードは、SYSTEMDB と個々のテナントデータベースに設定する必要があります。

システム PKI ファイルをセカンダリサイトにコピーします。
```
scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT   hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY  hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/
```
プライマリサイトを作成します。
```
hdbnsutil -sr_enable --name=SITE1
```
[2] 2 番目のノードでシステムレプリケーションを構成します。

2 番目のノードを登録して、システムレプリケーションを開始します。 <hanasid>adm として次のコマンドを実行します。
```
sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2
```
[2] HANA を開始します。

<hanasid>adm として次のコマンドを実行して、HANA を開始します。
```
sapcontrol -nr 03 -function StartSystem
```

[1] レプリケーションの状態をチェックします。

レプリケーションの状態をチェックし、すべてのデータベースが同期されるまで待機します。状態が不明な場合、ファイアウォール設定を確認します。

sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
# | Database | Host     | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
# |          |          |       |              |           |         |           | Host      | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
# | -------- | -------- | ----- | ------------ | --------- | ------- | --------- | --------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
# | SYSTEMDB | hn1-db-0 | 30301 | nameserver   |         1 |       1 | SITE1     | hn1-db-1  |     30301 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hn1-db-0 | 30307 | xsengine     |         2 |       1 | SITE1     | hn1-db-1  |     30307 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
# | NW1      | hn1-db-0 | 30340 | indexserver  |         2 |       1 | SITE1     | hn1-db-1  |     30340 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hn1-db-0 | 30303 | indexserver  |         3 |       1 | SITE1     | hn1-db-1  |     30303 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
#
# status system replication site "2": ACTIVE
# overall system replication status: ACTIVE
#
# Local System Replication State
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
# mode: PRIMARY
# site id: 1
# site name: SITE1

Pacemaker クラスターの作成

Azureの手順に従って、この HANA サーバー用の基本的な Pacemaker クラスターを作成します。

重要

systemd ベースの SAP Startup Framework を使用すると、SAP HANA インスタンスを systemd で管理できるようになりました。必要な Red Hat Enterprise Linux (RHEL) の最小バージョンは RHEL 8 for SAP です。 SAP Note 3189534 で説明されているように、SAP HANA SPS07 リビジョン 70 以降の新規インストール、または HANA システムの HANA 2.0 SPS07 リビジョン 70 以降への更新により、SAP Startup フレームワークは systemd に自動的に登録されます。

HA ソリューションを使用してシステム対応SAP HANA インスタンスと組み合わせてSAP HANAシステムレプリケーションを管理する場合 (SAP Note 3189534 を参照)、HA クラスターがシステム干渉なしで SAP インスタンスを管理できるようにするために追加の手順が必要です。そのため、systemd と統合SAP HANAシステムの場合は、すべてのクラスターノードで、Red Hat KBA 7029705 で説明されている追加の手順に従う必要があります。

SAP HANAのシステムレプリケーションフックを実装する

Red Hat には、RHEL で HANA システムレプリケーション HA クラスターを構成するための 2 世代のリソースエージェントが用意されています。構成手順が異なるため、このドキュメントでは、リソースエージェントの生成に基づいて、それらを個別のタブに分割します。

[クラシック] タブ: "resource-agents-sap-hana" (スケールアップ) パッケージで提供される、クラシック世代のリソースエージェントについて説明します。
[新しい世代] タブ: "sap-hana-ha" パッケージで提供される、新しい世代のリソースエージェントについて説明します。アップストリームでは、この世代は "SAPHanaSR-angi" と呼ばれます。

クラシックパッケージと新世代パッケージは相互に排他的であり、システム上で一度に構成できるパッケージは 1 つだけです。特定の構成には、以下の対応するタブを使用します。

注

クラシックリソースエージェントから新しい世代のリソースエージェントにアップグレードするには、「SAP HANA HA セットアップを新しい世代のリソースエージェントにアップグレードする」の詳細なガイダンスに従ってください。

[A] SAP HANA HA パッケージをインストールする

新しい世代
クラシック

重要

新しい世代のセットアップでは、パッケージ sap-hana-ha は RHEL 9.4 以降から入手できます。

sudo dnf install sap-hana-ha

注

RHEL 8.x と RHEL 9.x の場合は、インストールされている resource-agents-sap-hana パッケージがバージョン 0.162.3-5 以降であることを確認します。

sudo dnf install resource-agents-sap-hana

SAP HANA HA/DR プロバイダーを設定する

SAP HANA HA/DR プロバイダーは、クラスター統合を改善し、フェールオーバー条件の検出を強化します。プライマリフックスクリプトは、SAPHanaSR (resource-agents-sap-hana パッケージの場合) または HanaSR (sap-hana-ha パッケージの場合) です。 SAPHanaSR または HanaSR Python フックを ChkSrv フックと共に構成することを強くお勧めします。

ChkSrv フックは、HANA hdbindexserver プロセスがクラッシュするシナリオを処理することで、SAPHanaSR/HanaSR プロバイダーの機能を拡張します。このような場合、HANA は通常、ローカル再起動を試みます。これにより、データのオフロードと再読み込みが行われ、パフォーマンスが低下します。

ChkSrv を有効にすると、構成可能なアクションが直ちにトリガーされ、hdbindexserver プロセスが同じノードで再起動するのを待つのではなく、定義されたタイムアウト内でフェールオーバーが開始されます。

[A] 両方でSAP HANAを停止します。次のコマンドを <sid>adm として実行します。
```
sapcontrol -nr 03 -function StopSystem
```
[A] HANA システムレプリケーションフックをインストールします。フックは両方の HANA データベースノードにインストールする必要があります。
- 新しい世代
- クラシック
1. [A] 各クラスターノードで global.ini を調整します。
  
  推奨される ChkSrv フックを使用しないことを選択した場合は、次のパラメーターから [ha_dr_provider_chksrv] ブロック全体を削除します。 action_on_lost パラメーターを使用して、ChkSrv の動作を調整できます。有効な値は、[ ignore | stop | kill | fence ] です。
```
[ha_dr_provider_hanasr]
provider = HanaSR
path = /usr/share/sap-hana-ha/
execution_order = 1

[ha_dr_provider_chksrv]
provider = ChkSrv
path = /usr/share/sap-hana-ha/
execution_order = 2
action_on_lost = fence

[trace]
ha_dr_hanasr = info
ha_dr_chksrv = info
```
2. [A] 次の内容の各クラスターノードに、ルートユーザーとして /etc/sudoers.d/20-saphana ファイルを作成します。これらのコマンド特権を使用すると、 <sap-sid>adm ユーザーは、HanaSR フック実行の一部として特定のクラスターノード属性を更新できます。
```
cat << EOF > /etc/sudoers.d/20-saphana
hn1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_*
hn1adm ALL=(ALL) NOPASSWD: /usr/bin/SAPHanaSR-hookHelper
Defaults:hn1adm !requiretty
EOF
```
HanaSR HA/DR プロバイダーの実装の詳細については、srConnectionChanged() フックメソッド用の HanaSR HA/DR プロバイダーの構成、および srServiceStateChanged() フックメソッドの ChkSrv HA/DR プロバイダーの構成を参照してください。
1. [A] 各クラスターノードで global.ini を調整します。
  
  推奨される ChkSrv フックを使用しないことを選択した場合は、次のパラメーターから [ha_dr_provider_chksrv] ブロック全体を削除します。 action_on_lost パラメーターを使用して、ChkSrv の動作を調整できます。有効な値は [ ignore | stop | kill ] です。
```
[ha_dr_provider_SAPHanaSR]
provider = SAPHanaSR
path = /usr/share/SAPHanaSR/srHook
execution_order = 1

[ha_dr_provider_chksrv]
provider = ChkSrv
path = /usr/share/SAPHanaSR/srHook
execution_order = 2
action_on_lost = kill

[trace]
ha_dr_saphanasr = info
ha_dr_chksrv = info
```
2. [A] 次の内容の各クラスターノードに、ルートユーザーとして /etc/sudoers.d/20-saphana ファイルを作成します。これらのコマンド特権を使用すると、 <sap-sid>adm ユーザーは、SAPHanaSR フック実行の一部として特定のクラスターノード属性を更新できます。
```
Cmnd_Alias SITE1_SOK   = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE1 -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias SITE1_SFAIL = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE1 -v SFAIL -t crm_config -s SAPHanaSR
Cmnd_Alias SITE2_SOK   = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE2 -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias SITE2_SFAIL = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE2 -v SFAIL -t crm_config -s SAPHanaSR
hn1adm ALL=(ALL) NOPASSWD: SITE1_SOK, SITE1_SFAIL, SITE2_SOK, SITE2_SFAIL
Defaults!SITE1_SOK, SITE1_SFAIL, SITE2_SOK, SITE2_SFAIL !requiretty
```
SAPHanaSR HA/DR プロバイダーの実装の詳細については、「SAP HANA srConnectionChanged() フックの有効化」および「hdbindexserver プロセス障害アクションのSAP HANA srServiceStateChanged() フックの有効化 (省略可能)」を参照してください。
[A]両方のノードでSAP HANAを開始します。 <sap-sid>adm として次のコマンドを実行します。
```
sapcontrol -nr 03 -function StartSystem
```
[1] フックのインストールを確認します。
- 新しい世代
- クラシック
1. [1] HanaSR フックと ChkSrv フックが構成されていることを確認します。アクティブな HANA システムレプリケーションサイト <sap-sid>adm として次のコマンドを実行します。
```
cdtrace
grep -he "loading HA/DR Provider.*" nameserver_*
# Example output
# [480845]{-1}[-1/-1] i ha_dr_provider   HADRProviderManager.cpp(00080) : loading HA/DR Provider 'ChkSrv' from /usr/share/sap-hana-ha/
# [480845]{-1}[-1/-1] i ha_dr_provider   HADRProviderManager.cpp(00080) : loading HA/DR Provider 'HanaSR' from /usr/share/sap-hana-ha/
```
2. [1] ユーザールートとして、プライマリノード (node1 など) でシステムのセキュリティで保護されたログを確認し、エラーなしで sudo コマンドが実行されたことを確認します。 sudoers ファイルが正しく構成されていないと、実行時にエラーエントリが生成されます。
```
[root]# grep -e 'sudo.*crm_attribute.*' /var/log/secure
# Feb 25 21:48:06 <hostname> sudo[483654]:  hn1adm : PWD=/hana/shared/HN1/HDB03/<hostname> ; USER=root ; COMMAND=/usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE2 -v SFAIL -t crm_config -s SAPHanaSR
# Feb 25 21:48:49 <hostname> sudo[483960]:  hn1adm : PWD=/hana/shared/HN1/HDB03/<hostname> ; USER=root ; COMMAND=/usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE2 -v SOK -t crm_config -s SAPHanaSR
```
  HANA インスタンスが両方のノードで起動すると、srHook 属性は通常、いくつかの更新を実行します。起動直後にプライマリがまだセカンダリと同期していないため、SFAIL が最初に表示されます。システムレプリケーションが完全同期に達すると、HANA は、属性を SOK に更新する最終的なフックイベントをトリガーします。
1. [1] SAPHanaSR フックが構成されていることを確認します。アクティブな HANA システムレプリケーションサイト <sap-sid>adm として次のコマンドを実行します。
```
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
```

[1] ChkSrv フックが正しい構成で読み込まれているかどうかを確認します。 <sap-sid>adm として次のコマンドを実行します。

cdtrace
cat nameserver_chksrv.trc 
# Example output
# [1781280827-14237] init called
# [1781280827-14237] ChkSrv.init() version 1.001.1, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9
# [1781280866-11350] ChkSrv version 1.001.1. Method srServiceStateChanged method called.

SAP HANAクラスターリソースを作成する

[1] SAP HANA トポロジリソースの作成

新しい世代
クラシック

sudo pcs property set maintenance-mode=true

sudo pcs resource create rsc_SAPHanaTopology_HN1_HDB03 \
    ocf:heartbeat:SAPHanaTopology \
    SID=HN1 \
    InstanceNumber=03 \
    op start timeout=600 \
    op stop timeout=300 \
    op monitor interval=30 timeout=300 \
    clone cln_SAPHanaTopology_HN1_HDB03 \
    meta clone-max=2 clone-node-max=1 interleave=true

sudo pcs property set maintenance-mode=true

sudo pcs resource create SAPHanaTopology_HN1_03 SAPHanaTopology SID=HN1 InstanceNumber=03 \
    op start timeout=600 op stop timeout=300 op monitor interval=10 timeout=600 \
    clone clone-max=2 clone-node-max=1 interleave=true

[1] SAP HANA リソースを作成する

新しい世代
クラシック

sudo pcs resource create rsc_SAPHanaController_HN1_HDB03 \
    ocf:heartbeat:SAPHanaController \
    SID=HN1 \
    InstanceNumber=03 \
    PREFER_SITE_TAKEOVER=true \
    DUPLICATE_PRIMARY_TIMEOUT=7200 \
    AUTOMATED_REGISTER=false \
    op stop timeout=3600 \
    op monitor interval=59 role=Promoted timeout=700 \
    op monitor interval=61 role=Unpromoted timeout=700 \
    meta priority=100 \
    promotable cln_SAPHanaController_HN1_HDB03 \
    meta clone-max=2 clone-node-max=1 interleave=true --future

新しい世代のパッケージには、/hana/shared/<SID> パスへの読み取り/書き込みアクセスを監視する新しいリソースエージェント SAPHanaFilesystem が導入されています。ファイルシステムは OS レベルで静的にマウントされ、各ホストは /etc/fstab を介して構成されます。 SAPHanaFilesystem も Pacemaker も、HANA 用にこのファイルシステムをマウントする責任を負いません。

/hana/shared/<SID> が NFS でホストされている場合は、SAPHanaFilesystem を使用することをお勧めします。 Azureマネージドディスクなどのブロックデバイスにパスが存在する場合、SAPHanaFilesystem の使用は省略可能です。

sudo pcs resource create rsc_SAPHanaFilesystem_HN1_HDB03 \
    ocf:heartbeat:SAPHanaFilesystem \
    SID=HN1 \
    InstanceNumber=03 \
    ON_FAIL_ACTION="fence" \
    op start interval=0 timeout=10 \
    op stop interval=0 timeout=20 \
    op monitor interval=120 timeout=120 \
    clone cln_SAPHanaFilesystem_HN1_HDB03 \
    meta clone-node-max=1 interleave=true --future

# On RHEL 10.x
sudo pcs resource create SAPHana_HN1_03 SAPHana SID=HN1 InstanceNumber=03 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=false \
    op start timeout=3600 op stop timeout=3600 \
    op monitor interval=61 role="Unpromoted" timeout=700 \
    op monitor interval=59 role="Promoted" timeout=700 \
    op promote timeout=3600 op demote timeout=3600 \
    promotable meta notify=true clone-max=2 clone-node-max=1 interleave=true

# On RHEL 9.x/8.x
sudo pcs resource create SAPHana_HN1_03 SAPHana SID=HN1 InstanceNumber=03 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=false \
    op start timeout=3600 op stop timeout=3600 \ 
    op monitor interval=61 role="Slave" timeout=700 \
    op monitor interval=59 role="Master" timeout=700 \
    op promote timeout=3600 \
    op demote timeout=3600 \
    promotable notify=true clone-max=2 clone-node-max=1 interleave=true

priority-fencing-delay では、スプリットブレインシナリオ中にリソース優先度が低いノードで意図的なフェンス遅延が発生します。 2 ノードクラスターでは、HANA リソースクローンに優先順位を高く割り当てると、プライマリ HANA インスタンスを実行しているノードが最後にフェンスされます。これにより、フェンスレースが存続する可能性が最も高くなります。詳細については、「Pacemaker は実行中のリソースが最も少ないクラスターノードをフェンスできますか?」を参照してください。

sudo pcs resource defaults update priority=1
sudo pcs resource update SAPHana_HN1_03-clone meta priority=100

[1] 仮想 IP リソースを作成する

sudo pcs resource create vip_HN1_03 IPaddr2 ip="<front end IP address>"
sudo pcs resource create nc_HN1_03 azure-lb port=62503
sudo pcs resource group add g_ip_HN1_03 nc_HN1_03 vip_HN1_03

[1] リソース制約を作成する

新しい世代
クラシック

sudo pcs constraint order cln_SAPHanaTopology_HN1_HDB03 then cln_SAPHanaController_HN1_HDB03 symmetrical=false
sudo pcs constraint colocation add g_ip_HN1_03 with Promoted cln_SAPHanaController_HN1_HDB03 score=4000

sudo pcs constraint order SAPHanaTopology_HN1_03-clone then SAPHana_HN1_03-clone symmetrical=false

# On RHEL 10.x
sudo pcs constraint colocation add g_ip_HN1_03 with Promoted SAPHana_HN1_03-clone score=4000
# On RHEL 9.x/8.x
sudo pcs constraint colocation add g_ip_HN1_03 with master SAPHana_HN1_03-clone 4000

[1] リソースの既定値の設定

sudo pcs resource defaults update resource-stickiness=1000
sudo pcs resource defaults update migration-threshold=5000

[1] priority-fencing-delay プロパティを構成する
```
sudo pcs property set priority-fencing-delay=15s
```

重要

フェールオーバーテストの実行中に AUTOMATED_REGISTER を false に設定して、失敗したプライマリインスタンスが自動的にセカンダリとして登録されないようにすることをお勧めします。ベストプラクティスとして、テストが終わったら AUTOMATED_REGISTER を true に設定し、引き継ぎ後にシステムレプリケーションが自動的に再開できるようにします。

クラスターの状態が正常であることと、すべてのリソースが起動されていることを確認します。リソースがどのノードで実行されているかは重要ではありません。

注

上記の構成のタイムアウトはほんの一例であり、特定の HANA のセットアップに適合させる必要がある場合があります。たとえば、SAP HANA データベースの起動に時間がかかる場合は、開始タイムアウトを増やす必要がある場合があります。

sudo pcs status コマンドを使用して、作成されたクラスターリソースの状態をチェックします。

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# azure_fence     (stonith:fence_azure_arm):      Started hn1-db-0
#  Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
#      Started: [ hn1-db-0 hn1-db-1 ]
#  Primary/Secondary Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
#      Primaries: [ hn1-db-0 ]
#      Secondaries: [ hn1-db-1 ]
#  Resource Group: g_ip_HN1_03
#      nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
#      vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

Pacemaker クラスターで HANA アクティブ/読み取り可能のシステムレプリケーションを構成する

SAP HANA 2.0 SPS 01 以降、SAP では、SAP HANA システムレプリケーションのアクティブ/読み取りが有効なセットアップが可能になり、SAP HANA システムレプリケーションのセカンダリシステムを読み取り負荷の高いワークロードにアクティブに使用できます。

クラスターでこのようなセットアップをサポートするには、2 つ目の仮想 IP アドレスが必要です。これにより、クライアントはセカンダリの読み取り対応SAP HANA データベースにアクセスできます。引き継ぎの実行後もセカンダリレプリケーションサイトにアクセスできるようにするために、クラスターが仮想 IP アドレスをセカンダリ SAPHana リソースに移行する必要があります。

このセクションでは、2 番目の仮想 IP を使用して Red Hat HA クラスターで HANA のアクティブ/読み取り可能のシステムレプリケーションを管理するために必要な追加の手順について説明します。

先に進む前に、ドキュメントの前のセグメントで説明したように、SAP HANA データベースを管理する Red Hat HA クラスターが完全に構成されていることを確認してください。

SAP HANA HA の一部として読み取りが有効なセカンダリを示すダイアグラム

Azure Load Balancerのアクティブ/読み取り可能なセットアップにおける追加設定

2 つ目の仮想 IP のプロビジョニングに関するその他の手順を続行するには、「 Azure ポータルを使用して Linux VM を手動でデプロイする」セクションで説明されているようにAzure Load Balancerを構成していることを確認します。

標準ロードバランサーの場合は、前のセクションで作成したのと同じロードバランサーで、次の手順に従います。

a. 2 番目のフロントエンド IP プールを作成する:
- ロードバランサーを開き、 [frontend IP pool](フロントエンド IP プール) を選択して [Add](追加) を選択します
- この 2 番目のフロントエンド IP プールの名前を入力します (例: hana-secondaryIP)。
- [割り当て] を [静的] に設定し、IP アドレスを入力します (例: 10.0.0.14)。
- [OK] を選択.
- 新しいフロントエンド IP プールが作成されたら、プールの IP アドレスを書き留めます。 b。ヘルスプローブを作成する:
- ロードバランサーを開き、「正常性プローブ」を選択して、「追加」をクリックします。
- 新しい正常性プローブの名前を入力します (例: hana-secondaryhp)。
- プロトコルとして [TCP] を、ポートは 62603 を選択します。 [Interval] (間隔) の値を 5 に設定し、[Unhealthy threshold] (異常しきい値) の値を 2 に設定します。
- OK を選択します。負荷分散規則を作成します。
- ロードバランサーを開き、 [load balancing rules](負荷分散規則) を選択して [Add](追加) を選択します。
- 新しいロードバランサー規則の名前を入力します (例: hana-secondarylb)。
- 前の手順で作成したフロントエンド IP アドレス、バックエンドプール、正常性プローブを選択します (例: hana-secondaryIP、hana-backend、hana-secondaryhp)。
- [HA ポート] を選択します。
- Floating IP を有効にします。
- [OK] を選択.

HANA のアクティブかつ読み取り可能のシステムレプリケーションの構成

HANA システムレプリケーションを構成する手順については、「Configure SAP HANA 2.0 システムレプリケーション」セクションで説明します。読み取り対応のセカンダリシナリオをデプロイする場合は、2 番目のノードでシステムレプリケーションを構成するときに、hanasidadm として次のコマンドを実行します。

sapcontrol -nr 03 -function StopWait 600 10 

hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2 --operationMode=logreplay_readaccess

アクティブかつ読み取り可能のセットアップ用のセカンダリ仮想 IP アドレスリソースを追加する

仮想 IP リソースを作成します。

sudo pcs property set maintenance-mode=true

sudo pcs resource create sec_vip_HN1_03 ocf:heartbeat:IPaddr2 ip="10.40.0.16"
sudo pcs resource create sec_nc_HN1_03 ocf:heartbeat:azure-lb port=62603
sudo pcs resource group add g_sec_ip_HN1_03 sec_nc_HN1_03 sec_vip_HN1_03

通常の操作中にセカンダリ IP リソースがセカンダリサイトに確実に割り当てられるように、場所の制約ルールを作成します。

新しい世代
クラシック

sudo pcs constraint location g_sec_ip_HN1_03 \
    rule score=INFINITY master-rsc_SAPHanaController_HN1_HDB03 eq 100 \
    and hana_HN1_clone_state eq DEMOTED

# On RHEL 10.x
sudo pcs constraint location g_sec_ip_HN1_03 \ 
    rule score=INFINITY "hana_hn1_sync_state eq SOK \
    and hana_hn1_roles eq 4:S:master1:master:worker:master"

# On RHEL 9.x/8.x
sudo pcs constraint location g_sec_ip_HN1_03 \ 
    rule score=INFINITY "hana_hn1_sync_state eq SOK \
    and hana_hn1_roles eq 4:S:master1:master:worker:master"

必要に応じて、セカンダリ仮想 IP をプライマリサイトで実行できるように、場所の制約を作成します。

新しい世代
クラシック

sudo pcs constraint location g_sec_ip_HN1_03 \
    rule score=4000 master-rsc_SAPHanaController_HN1_HDB03 eq 150 \
    and hana_hn1_clone_state eq PROMOTED

# On RHEL 10.x
sudo pcs constraint location g_sec_ip_HN1_03 \ 
    rule score=4000 "hana_hn1_sync_state eq PRIM \
    and hana_hn1_roles eq 4:P:master1:master:worker:master"

# On RHEL 9.x/8.x
sudo pcs constraint location g_sec_ip_HN1_03 \ 
    rule score=4000 hana_hn1_sync_state eq PRIM \
    and hana_hn1_roles eq 4:P:master1:master:worker:master

メンテナンスモードからクラスターを削除する
```
sudo pcs property set maintenance-mode=false
```

クラスターの状態が正常であることと、すべてのリソースが起動されていることを確認します。 2 番目の仮想 IP は、SAPHana セカンダリリソースと共にセカンダリサイトで実行されます。

sudo pcs status

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full List of Resources:
#   rsc_hdb_azr_agt     (stonith:fence_azure_arm):      Started hn1-db-0
#   Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]:
#     Started: [ hn1-db-0 hn1-db-1 ]
#   Clone Set: SAPHana_HN1_03-clone [SAPHana_HN1_03] (promotable):
#     Primaries: [ hn1-db-0 ]
#     Secondaries: [ hn1-db-1 ]
#   Resource Group: g_ip_HN1_03:
#     nc_HN1_03         (ocf::heartbeat:azure-lb):      Started hn1-db-0
#     vip_HN1_03        (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#   Resource Group: g_secip_HN1_03:
#     secnc_HN1_03      (ocf::heartbeat:azure-lb):      Started hn1-db-1
#     secvip_HN1_03     (ocf::heartbeat:IPaddr2):       Started hn1-db-1

次のセクションでは、実行する典型的なフェールオーバーテストのセットを示します。

読み取り可能なセカンダリが構成されている HANA クラスターをテストするときに、2 番目の仮想 IP の動作に注意してください。

SAPHana_HN1_03 クラスターリソースをセカンダリサイト hn1-db-1 に移行すると、2 番目の仮想 IP は引き続き同じサイト hn1-db-1 で実行されます。リソースに AUTOMATED_REGISTER="true" を設定していて、HANA システムレプリケーションが hn1-db-0 に自動的に登録されている場合は、2 番目の仮想 IP も hn1-db-0 に移動します。
サーバーのクラッシュをテストすると、プライマリサーバー上で 2 番目の仮想 IP リソース (secvip_HN1_03) とAzure Load Balancer ポートリソース (secnc_HN1_03) がプライマリ仮想 IP リソースと共に実行されます。そのため、セカンダリサーバーがダウンするまで、読み取り可能な HANA データベースに接続されているアプリケーションはプライマリ HANA データベースに接続します。セカンダリサーバーが使用できなくなるまで、読み取り可能な HANA データベースに接続されているアプリケーションにアクセスできないようにするため、この動作が想定されます。
2番目の仮想 IP アドレスのフェールオーバーとフォールバック中に、HANA データベースへの接続に 2 番目の仮想 IP を使用するアプリケーション上の既存の接続が中断される可能性があります。

セットアップにより、正常なSAP HANA インスタンスが実行されているノードに 2 番目の仮想 IP リソースが割り当てられる時間が最大化されます。

クラスターの設定をテストする

ここでは、設定をテストする方法について説明します。テストを開始する前に、Pacemaker に失敗したアクション (pcs 状態を使用) がなく、予期しない場所の制約 (移行テストの残りなど) がなく、HANA が systemReplicationStatus などと同期状態であることを確認します。

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

移行をテストする

テスト開始前のリソースの状態:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Primary/Secondary Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Primaries: [ hn1-db-0 ]
    Secondaries: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

ルートとして次のコマンドを実行して、SAP HANA マスターノードを移行できます。

# On RHEL 10.x
pcs resource move SAPHana_HN1_03-clone --Promoted

# On RHEL 9.x/8.x
pcs resource move SAPHana_HN1_03-clone --master

クラスターは、SAP HANA マスターノードと仮想 IP アドレスを含むグループを hn1-db-1 に移行します。

移行が完了すると、sudo pcs status の出力は次のようになります。

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Primary/Secondary Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Primaries: [ hn1-db-1 ]
    Stopped: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

AUTOMATED_REGISTER="false" では、クラスターは障害が発生した HANA データベースを再起動したり、hn1-db-0 の新しいプライマリに対して登録したりしません。この場合は、次のコマンドを hn1adm として実行して、HANA インスタンスをセカンダリとして構成します。

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1

移行では場所の制約が作成されますが、これは再度削除する必要があります。 root として、または sudo を使用して、次の操作を行います。

pcs resource clear SAPHana_HN1_03-master

pcs status を使用して HANA リソースの状態を監視します。 hn1-db-0 上で HANA が起動されている場合、出力は次のようになります。

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Primary/Secondary Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Primaries: [ hn1-db-1 ]
    Secondaries: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

ネットワーク通信のブロック

テスト開始前のリソースの状態:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Primary/Secondary Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Primaries: [ hn1-db-1 ]
    Secondaries: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

ファイアウォール規則を実行して、いずれかのノードでの通信をブロックします。

# 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

クラスターノードが相互に通信できない場合は、スプリットブレインシナリオのリスクがあります。このような状況では、クラスターノードは互いに同時にフェンスを試行し、フェンスレースを引き起こします。このような状況を回避するには、クラスター構成で priority-fencing-delay プロパティを設定することをお勧めします (pacemaker-2.0.4-6.el8 以降にのみ適用されます)。

priority-fencing-delay プロパティを有効にすると、クラスターでは、特に HANA マスターリソースをホストしているノードに対してフェンスアクションに遅延が発生し、ノードがフェンスレースに勝つことができます。

次のコマンドを実行して、ファイアウォール規則を削除します。

# 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

Azureフェンスエージェントをテストする

注

この記事には、Microsoft が使用しなくなった用語への言及が含まれています。ソフトウェアからこの用語が削除された時点で、この記事から削除します。

テスト開始前のリソースの状態:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Primary/Secondary Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Primaries: [ hn1-db-1 ]
    Secondaries: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

SAP HANAがプライマリとして実行されているノードでネットワークインターフェイスを無効にすることで、Azure フェンスエージェントのセットアップをテストできます。ネットワークエラーをシミュレートする方法の説明については、Red Hat のサポート情報記事 79523 を参照してください。

この例では net_breaker スクリプトを root として使用して、ネットワークへのすべてのアクセスをブロックします。

sh ./net_breaker.sh BreakCommCmd 10.0.0.6

クラスターの構成によっては、VM が再起動するか停止します。 stonith-action 設定を off に設定すると、VM が停止し、実行中の VM にリソースが移行されます。

VM を再度起動した後、SAP HANA リソースは、AUTOMATED_REGISTER="false" を設定した場合、セカンダリとして開始できません。この場合は、次のコマンドを hn1adm ユーザーとして実行して、 HANA インスタンスをセカンダリとして構成します。

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2

root に戻り、失敗した状態をクリーンします。

pcs resource cleanup SAPHana_HN1_03 node=<hostname on which the resource needs to be cleaned>

テスト後のリソースの状態:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Primary/Secondary Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Primaries: [ hn1-db-0 ]
    Secondaries: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

手動フェールオーバーをテストする

テスト開始前のリソースの状態:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Primary/Secondary Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Primaries: [ hn1-db-0 ]
    Secondaries: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

手動フェールオーバーをテストするには、hn1-db-0 ノードでクラスターを root として停止します。

pcs cluster stop

フェールオーバー後、クラスターを再度開始できます。 AUTOMATED_REGISTER="false" を設定した場合、hn1-db-0 ノードのSAP HANA リソースはセカンダリとして開始できません。この場合は、root として次のコマンドを実行して、HANA インスタンスをセカンダリとして構成します。

pcs cluster start

hn1adm として次を実行します。

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1

次に root として実行してください。

pcs resource cleanup SAPHana_HN1_03 node=<hostname on which the resource needs to be cleaned>

テスト後のリソースの状態:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Primary/Secondary Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Primaries: [ hn1-db-1 ]
     Secondaries: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

次のステップ

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-06-24

Red Hat Enterprise Linux 上の Azure VM でのSAP HANAの高可用性

前提条件

概要

インフラストラクチャの準備

Azure ポータルを使用して Linux VM を手動でデプロイする

Azureロードバランサーを構成する

SAP HANAのインストール

SAP HANA 2.0 システム レプリケーションの構成

Pacemaker クラスターの作成

SAP HANAのシステムレプリケーションフックを実装する

SAP HANA HA/DR プロバイダーを設定する

SAP HANAクラスターリソースを作成する

Pacemaker クラスターで HANA アクティブ/読み取り可能のシステム レプリケーションを構成する

Azure Load Balancerのアクティブ/読み取り可能なセットアップにおける追加設定

HANA のアクティブかつ読み取り可能のシステム レプリケーションの構成

アクティブかつ読み取り可能のセットアップ用のセカンダリ仮想 IP アドレス リソースを追加する

クラスターの設定をテストする

移行をテストする

ネットワーク通信のブロック

Azureフェンス エージェントをテストする

手動フェールオーバーをテストする

次のステップ

フィードバック

その他のリソース

SAP HANA 2.0 システムレプリケーションの構成

Pacemaker クラスターで HANA アクティブ/読み取り可能のシステムレプリケーションを構成する

HANA のアクティブかつ読み取り可能のシステムレプリケーションの構成

アクティブかつ読み取り可能のセットアップ用のセカンダリ仮想 IP アドレスリソースを追加する

Azureフェンスエージェントをテストする