SUSE Linux Enterprise Server 上の Azure VM での SAP HANA の高可用性

[アーティクル]
10/17/2024

オンプレミスの SAP HANA デプロイで高可用性を確立するために、SAP HANA システムレプリケーションまたは共有ストレージを使用することができます。

現在、Azure 仮想マシン (VM) 上では、Azure 上の SAP HANA システムレプリケーションがサポートされている唯一の高可用性機能です。

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

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

始める前に、次の SAP のノートとペーパーをお読みください:

SAP ノート 1928533。ノートには次のものが含まれます。
- SAP ソフトウェアのデプロイでサポートされる Azure VM サイズの一覧。
- Azure VM サイズの容量に関する重要な情報。
- サポートされる SAP ソフトウェア、およびオペレーティングシステム (OS) とデータベースの組み合わせ。
- Microsoft Azure 上の Windows と Linux に必要な SAP カーネルバージョン
SAP Note 2015553: SAP でサポートされる Azure 上の SAP ソフトウェアデプロイの前提条件が記載されています。
SAP Note 2205917: SUSE Linux Enterprise Server 12 (SLES 12) for SAP Applications 向けの推奨 OS 設定が記載されています。
SAP Note 2684254: SUSE Linux Enterprise Server 15 (SLES 15) for SAP Applications 向けの推奨 OS 設定が記載されています。
SAP Note 2235581: SAP HANA でサポートされているオペレーティングシステムが記載されています
SAP Note 2178632: Azure 上の SAP について報告されるすべての監視メトリックに関する詳細情報が記載されています。
SAP Note 2191498: Azure 上の Linux に必要な SAP ホストエージェントのバージョンが記載されています。
SAP Note 2243692: Azure の Linux で動作する SAP のライセンスに関する情報が記載されています。
SAP Note 1984787: SUSE Linux Enterprise Server 12 に関する一般情報が記載されています。
SAP Note 1999351はAzure Enhanced モニタリング拡張機能 for SAP に関するその他のトラブルシューティング情報が記載されています。
SAP Note 401162: HANA システムレプリケーションを設定するときに "アドレスは既に使用中です" というエラーを回避する方法に関する情報が記載されています。
SAP Community Support Wiki: Linux に必要なすべての SAP Note が記載されています。
SAP HANA 認定 IaaS プラットフォーム。
Linux 上の SAP のための Azure Virtual Machines の計画と実装に関するガイド
Linux 上の SAP のための Azure Virtual Machines のデプロイガイド。
Linux 上の SAP のための Azure Virtual Machines DBMS のデプロイに関するガイド
SUSE Linux Enterprise Server for SAP Applications 15 ベストプラクティスガイドおよび SUSE Linux Enterprise Server for SAP Applications 12 ベストプラクティスガイド:
- SAP HANA SR パフォーマンス最適化インフラストラクチャの設定 (SLES for SAP Applications) に関するガイド。このガイドには、SAP HANA システムレプリケーションをオンプレミス開発で設定するときに必要なすべての情報が記載されています。このガイドをベースラインとして使用します。
- SAP HANA SR コスト最適化インフラストラクチャの設定 (SLES for SAP Applications) に関するガイド。

SAP HANA の高可用性の計画

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

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

SAP HANA システム要件の設定では、専用の仮想ホスト名と仮想 IP アドレスが使用されます。 Azure では、仮想 IP アドレスをデプロイするためのロードバランサーが必要です。

上の図は、これらが構成されたロードバランサーの例を示しています。

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

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

SAP HANA のリソースエージェントは、SUSE Linux Enterprise Server for SAP Applications に含まれています。 Azure Marketplace には、SUSE Linux Enterprise Server for SAP Applications 12 または 15 の画像が掲載されています。この画像を使用して新しい VM をデプロイできます。

Azure portal 経由での手動による Linux VM のデプロイ

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

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

重要

選択した OS が、デプロイで使用する予定の特定の種類の VM 上の SAP HANA に対して SAP 認定されていることを確認してください。 SAP HANA 認定されている VM の種類とその OS リリースは、「SAP HANA 認定されている IaaS プラットフォーム」で調べることができます。特定の VM の種類に対して SAP HANA でサポートされている OS のリリースの完全な一覧を取得するために、VM の種類の詳細を確認するように注意してください。

Azure Load Balancer の構成

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

Azure portal を使って高可用性 SAP システム用の標準ロードバランサーを設定するには、「ロードバランサーの作成」の手順に従います。ロードバランサーのセットアップ時には、以下の点を考慮してください。

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

Note

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

# 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 を参照してください。

Note

パブリック IP アドレスを持たない VM が 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 を参照してください。
手動で設定した net.ipv4.tcp_timestamps の値 0 が、saptune によって 1 に戻されないようにするには、saptune のバージョンを 3.1.1 以降に更新します。詳細については、「saptune 3.1.1 – 更新する必要がありますか?」を参照してください。

Pacemaker クラスターの作成

「Set up Pacemaker on SUSE Linux Enterprise Server in Azure (Azure で SUSE Linux Enterprise Server に Pacemaker を設定する)」の手順に従って、この HANA サーバーに対して基本的な Pacemaker クラスターを作成します。 SAP HANA および SAP NetWeaver (A) SCS に対して同じ Pacemaker クラスターを使用することができます。

SAP HANA のインストール

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

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

<placeholders> を SAP HANA インストールの値に置き換えます。

[A] 論理ボリュームマネージャー (LVM) を使用してディスクのレイアウトを設定します。

データおよびログファイルを格納するボリュームには、LVM を使用することをお勧めします。次の例は、VM に 4 つのデータディスクがアタッチされていて、これを使用して 2 つのボリュームを作成することを前提としています。
1. 次のコマンドを実行して、使用可能なすべてのディスクを一覧表示します。
```
/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
```
2. 使用するすべてのディスクの物理ボリュームを作成します。
```
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. データファイル用のボリュームグループを作成します。ログファイル用に 1 つ、SAP HANA の共有ディレクトリ用に 1 つのボリュームグループを作成します。
```
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. 論理ボリュームを作成します。
  
  -i スイッチを指定せずに lvcreate を使用すると、線形のボリュームが作成されます。 I/O パフォーマンスが向上するように、"ストライプ" ボリュームを作成することお勧めします。ストライプサイズは、SAP HANA VM ストレージ構成に関するページ説明されている値に合わせます。 -i 引数は、基になる物理ボリュームの数、-I 引数はストライプサイズにする必要があります。
  
  たとえば、データボリュームに 2 つの物理ボリュームが使用されている場合、-i スイッチ引数は 2 に設定され、データボリュームのストライプサイズは 256KiB に設定されます。ログボリューム用に物理ボリュームが 1 つ使用されるため、ログボリュームコマンドに対して -i および -I スイッチは明示的には使用されません。
  
  重要
  
  データボリューム、ログボリューム、または共有ボリュームごとに複数の物理ボリュームを使用する場合は、-i スイッチを使用して基になる物理ボリュームの数を設定します。ストライプボリュームを作成する場合は、-I スイッチを使用してストライプサイズを指定します。
  
  ストライプサイズやディスク数など、推奨されるストレージ構成については、SAP HANA VM のストレージ構成に関する記事を参照してください。
```
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. マウントディレクトリを作成し、すべての論理ボリュームの UUID をコピーします。
```
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. /etc/fstab ファイルを編集して、3 つの論理ボリュームの fstab エントリを作成します。
```
sudo vi /etc/fstab
```
7. /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. 新しいボリュームをマウントします。
```
sudo mount -a
```
[A] プレーンディスクを使用してディスクレイアウトを設定します。

デモシステムの場合、ご自身の HANA のデータとログファイルを 1 つのディスクに配置することができます。
1. /dev/disk/azure/scsi1/lun0 にパーティションを作成し、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. /etc/fstab ファイルにこの行を挿入します。
```
/dev/disk/by-uuid/<UUID> /hana xfs  defaults,nofail  0  2
```
3. ターゲットディレクトリを作成してディスクをマウントします。
```
sudo mkdir /hana
sudo mount -a
```
[A] すべてのホストにホスト名解決を設定します。

DNS サーバーを使用するか、すべてのノードの /etc/hosts ファイルを変更することができます。この例では、/etc/hosts ファイルを使用する方法を示します。次のコマンドで、IP アドレスとホスト名を置き換えます。
1. /etc/hosts ファイルを編集します。
```
sudo vi /etc/hosts
```
2. 次の行を /etc/hosts ファイルに挿入します。お使いの環境に合わせて IP アドレスとホスト名を変更します。
```
10.0.0.5 hn1-db-0
10.0.0.6 hn1-db-1
```
[A] SAP のドキュメントに従って、SAP HANA をインストールします。

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

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

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

<placeholders> を SAP HANA インストールの値に置き換えます。

[1] テナントデータベースを作成します。

SAP HANA 2.0 または SAP HANA MDC を使用している場合は、ご自身の SAP NetWeaver システムに対してテナントデータベースを作成します。

<HANA SID>adm として次のコマンドを実行します。
```
hdbsql -u SYSTEM -p "<password>" -i <instance number> -d SYSTEMDB 'CREATE DATABASE <SAP SID> SYSTEM USER PASSWORD "<password>"'
```

[1] 最初のノードでシステムレプリケーションを構成します。

まず、<HANA SID>adm としてデータベースをバックアップします。

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>')"

次に、システム公開キー基盤 (PKI) ファイルをセカンダリサイトにコピーします。

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/

プライマリサイトを作成します。

hdbnsutil -sr_enable --name=<site 1>

[2] 2 番目のノードでシステムレプリケーションを構成します。

2 番目のノードを登録して、システムレプリケーションを開始します。

<HANA SID>adm として次のコマンドを実行します。
```
sapcontrol -nr <instance number> -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2> 
```

HANA リソースエージェントを実装する

SUSE には、SAP HANA を管理するために、2 つの異なる Pacemaker リソースエージェント向けソフトウェアパッケージが用意されています。ソフトウェアパッケージ SAPHanaSR と SAPHanaSR-angi では、使用されている構文が若干異なっており、互換性がありません。 SAPHanaSR と SAPHanaSR-angi の詳細と相違点については、SUSE のリリースノートとドキュメントを参照してください。このドキュメントでは、両方のパッケージについて、各セクションの個別のタブで説明します。

警告

既に構成済みのクラスターでは、パッケージ SAPHanaSR を SAPHanaSR-angi に置き換えないでください。 SAPHanaSR から SAPHanaSR-angi にアップグレードするには、特定の手順が必要です。

[A] SAP HANA 高可用性パッケージをインストールします。

SAPHanaSR
SAPHanaSR-angi

次のコマンドを実行して、高可用性パッケージをインストールします。

sudo zypper install SAPHanaSR

重要

SAPHanaSR-angi の最小バージョン要件は、SAP HANA 2.0 SPS 05 および SUSE SLES for SAP Applications 15 SP4 以降です。

次のコマンドを実行して、高可用性パッケージをインストールします。

sudo zypper install SAPHanaSR-angi

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

SAP HANA HA/DR プロバイダーにより、クラスターとの統合が最適化され、クラスターのフェールオーバーが必要になった場合の検出が向上します。主なフックスクリプトは、SAPHanaSR (SAPHanaSR パッケージの場合)/susHanaSR (SAPHanaSR-angi の場合) です。 SAPHanaSR/susHanaSR Python フックを構成することを強くお勧めします。 HANA 2.0 SPS 05 以降では、SAPHanaSR/susHanaSR フックと susChkSrv フックの両方を実装することをお勧めします。

susChkSrv は、主要 SAPHanaSR/susHanaSR HA プロバイダーの機能を拡張します。これは、HANA プロセス hdbindexserver がクラッシュした場合に機能します。 1 つのプロセスがクラッシュした場合、通常、HANA は再起動を試みます。 indexserver プロセスの再起動には長時間かかる場合があり、その間は HANA データベースが応答しません。

susChkSrv が実装されるとすぐに、構成可能なアクションが実行されます。このアクションは、hdbindexserver プロセスが同じノードで再起動するのを待たず、構成されたタイムアウト期間にフェールオーバーをトリガーします。

[A] 両方のノードで HANA を停止します。

次のコードを <sap-sid>adm として実行します。

sapcontrol -nr <instance number> -function StopSystem

[A] HANA システムレプリケーションフックをインストールします。フックは両方の HANA データベースノードにインストールする必要があります。

ヒント

SAPHanaSR Python フックは、HANA 2.0 にのみ実装できます。 SAPHanaSR パッケージは、バージョン 0.153 以上である必要があります。
SAPHanaSR-angi Python フックは、HANA 2.0 SPS 05 以降にのみ実装できます。
susChkSrv Python フックには SAP HANA 2.0 SPS 05 が必要です。さらに、SAPHanaSR バージョン 0.161.1_BF 以降がインストールされている必要があります。
- SAPHanaSR
- SAPHanaSR-angi
1. [A] 各クラスターノードで global.ini を調整します。
  
  susChkSrv フックの要件が満たされていない場合は、次のパラメータから [ha_dr_provider_suschksrv] ブロック全体を削除します。 action_on_lost パラメータを使用して、susChkSrv の動作を調整できます。有効な値は [ ignore | stop | kill | fence ] です。
```
[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
```
  既定の場所 /usr/share/SAPHanaSR へのパラメーターパスをポイントすると、OS の更新プログラムまたはパッケージの更新によって Python フックコードの更新が自動的に行われます。 HANA は、次回再起動するときにフックコードの更新を使用します。 /hana/shared/myHooks などの省略可能な独自のパスを使用すると、使用するフックバージョンから OS 更新プログラムを切り離すことができます。
2. [A] クラスターでは、<sap-sid>adm の各クラスターノードで sudoers を構成する必要があります。この例では、新しいファイルを作成することでそれを実現します。
  
  root として次のコマンドを実行します。 <sid> を小文字の SAP システム ID、<SID> を大文字の SAP システム ID、<siteA/B> を、選択した 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
```
SAP HANA システムレプリケーションフックの実装の詳細については、HANA HA/DR プロバイダーの設定に関するページを参照してください。
1. [A] 各クラスターノードで global.ini を調整します。
  
  推奨される susChkSrv フックを使用しないことを選択した場合は、次のパラメーターから [ha_dr_provider_suschksrv] ブロック全体を削除します。 action_on_lost パラメータを使用して、susChkSrv の動作を調整できます。有効な値は [ ignore | stop | kill | fence ] です。
```
[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
```
  既定の場所 /usr/share/SAPHanaSR-angi へのパラメーターパスをポイントすると、OS の更新プログラムまたはパッケージの更新によって Python フックコードの更新が自動的に行われます。 HANA は、次回再起動するときにフックコードの更新を使用します。 /hana/shared/myHooks などの省略可能な独自のパスを使用すると、使用するフックバージョンから OS 更新プログラムを切り離すことができます。
2. [A] クラスターでは、<sap-sid>adm の各クラスターノードで sudoers を構成する必要があります。この例では、新しいファイルを作成することでそれを実現します。
  
  root として次のコマンドを実行します。 <sid> を小文字の SAP システム ID、<SID> を大文字の SAP システム ID、<siteA/B> を、選択した 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
```
  SAP HANA システムレプリケーションフックの実装の詳細については、HANA HA/DR プロバイダーの設定に関するページを参照してください。

[A] 両方のノードで SAP HANA を開始します。 <sap-sid>adm として次のコマンドを実行します。
```
sapcontrol -nr <instance number> -function StartSystem 
```

[1] フックのインストールを確認します。アクティブな HANA システムレプリケーションサイト <sap-sid>adm として次のコマンドを実行します。

SAPHanaSR
SAPHanaSR-angi

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

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

[1] susChkSrv フックのインストールを確認します。 HANA VM で次のコマンドを <sap-sid>adm として実行します。

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)

SAP HANA クラスターリソースの作成

[1] 最初に、HANA トポロジリソースを作成します。

SAPHanaSR
SAPHanaSR-angi

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"

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"

[1] 次に、HANA リソースを作成します。

SAPHanaSR
SAPHanaSR-angi

Note

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

# 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

# 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 によって、/hana/shared/SID への読み取りと書き込みアクセスを監視するためのリソースエージェント SAPHanaFilesystem が新しく追加されます。 OS により、/etc/fstab にエントリがある各ホストで、/hana/shared/SID ファイルシステムが静的にマウントされます。 SAPHanaFilesystem と Pacemaker では、HANA のファイルシステムはマウントされません。

/hana/shared/SID に対して NFS を使用する場合は、SAPHanaFilesystem を実装することをお勧めします。 Azure マネージドディスクなどのブロックデバイスに /hana/shared/SID がある場合、SAPHanaFilesystem の使用はオプションです。

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

[1] 仮想 IP、既定値、制約のクラスターリソースに進みます。

SAPHanaSR
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" \
  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

# 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

重要

AUTOMATED_REGISTER の false への設定は、フェールオーバーテストの完了中にのみ行うことをお勧めします。これにより、失敗したプライマリインスタンスがセカンダリとして自動的に登録されるのを防ぐことができます。フェールオーバーテストが正常に完了したら、AUTOMATED_REGISTER を trueに設定して、引き継ぎ後にシステムレプリケーションが自動的に再開されるようにします。

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

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

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

SAP HANA 2.0 SPS 01 以降のバージョンでは、SAP では SAP HANA システムレプリケーションに対してアクティブかつ読み取り可能なセットアップが可能になりました。このシナリオでは、読み取りを集中的に行うワークロードに対して、SAP HANA システムレプリケーションのセカンダリシステムをアクティブに使用できます。

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

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

先に進む前に、前のセクションで説明されているように、SAP HANA データベースを管理する SUSE 高可用性クラスターが完全に構成されていることを確認してください。

読み取り可能なセカンダリ IP を使用した SAP HANA の高可用性の例を示す図。

アクティブかつ読み取り可能なシステムレプリケーション用にロードバランサーを設定する

2 つ目の仮想 IP をプロビジョニングする追加の手順を続行するには、「Azure portal を使用して Linux VM を手動でデプロイする」の説明に従って Azure Load Balancer を構成していることを確認します。

Standard ロードバランサーの場合は、前に作成したのと同じロードバランサーでこれらの追加の手順を実行します。

2 番目のフロントエンド IP プールを作成する:
1. ロードバランサーを開き、 [frontend IP pool](フロントエンド IP プール) を選択して [Add](追加) を選択します
2. この 2 番目のフロントエンド IP プールの名前を入力します (例: hana-secondaryIP)。
3. [割り当て] を [静的] に設定し、IP アドレスを入力します (例: 10.0.0.14)。
4. [OK] を選択します。
5. 新しいフロントエンド IP プールが作成されたら、フロントエンド IP アドレスを書き留めます。
正常性プローブを作成する:
1. ロードバランサーで、[Health probes] (正常性プローブ) を選択して [追加] を選びます。
2. 新しい正常性プローブの名前を入力します (例: hana-secondaryhp)。
3. プロトコルとして TCP を、ポートは 626<インスタンス番号>を選択します。 [Interval]\(間隔\) の値を 5 に設定し、[Unhealthy threshold]\(異常しきい値\) の値を 2 に設定します。
4. [OK] を選択します。
負荷分散規則を作成します。
1. ロードバランサーで、[load balancing rules] (負荷分散規則) を選択して [追加] を選択します。
2. 新しいロードバランサー規則の名前を入力します (例: hana-secondarylb)。
3. 前の手順で作成したフロントエンド IP アドレス、バックエンドプール、正常性プローブを選択します (例: hana-secondaryIP、hana-backend、hana-secondaryhp)。
4. [HA ポート] を選択します。
5. アイドルタイムアウトを 30 分に増やします。
6. フローティング IP を有効にしていることを確認します。
7. [OK] を選択します。

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

HANA システムレプリケーションを構成する手順については、「SAP HANA 2.0 システムレプリケーションの構成」を参照してください。読み取り可能なセカンダリシナリオをデプロイする場合、2 番目のノードでシステムレプリケーションを設定するときに、次のコマンドを <HANA SID>adm として実行します。

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

セカンダリ仮想 IP アドレスリソースを追加する

次のコマンドを使用して、2 番目の仮想 IP と適切なコロケーション制約を設定できます。

SAPHanaSR
SAPHanaSR-angi

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

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

クラスターの状態が OK であること、すべてのリソースが起動されていることを確認します。 2 番目の仮想 IP は、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

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

読み取りが可能なセカンダリで構成された HANA クラスターをテストする場合の考慮事項:

SAPHana_<HANA SID>_HDB<instance number> クラスターリソースを hn1-db-1 に移行すると、2 つ目の仮想 IP は hn1-db-0 に移動します。 AUTOMATED_REGISTER="false" を構成していて、HANA システムレプリケーションが自動的に登録されていない場合は、2 番目の仮想 IP がサーバーが hn1-db-0 で実行されます。このサーバーが使用可能であり、クラスターサービスがオンラインであるためです。
サーバーのクラッシュをテストする場合、2 番目の仮想 IP リソース (rsc_secip_<HANA SID>_HDB<instance number>) と Azure ロードバランサーのポートリソース (rsc_secnc_<HANA SID>_HDB<instance number>) は、プライマリ仮想 IP リソースと共にプライマリサーバー上で実行されます。セカンダリサーバーが停止している間、読み取り可能な HANA データベースに接続されているアプリケーションは、プライマリ HANA データベースに接続します。この動作は想定どおりです。セカンダリサーバーが使用できない間も、読み取り可能な HANA データベースに接続されているアプリケーションにアクセスできるようにするためです。
セカンダリサーバーが使用可能で、クラスターサービスがオンラインになっているときは、HANA システムレプリケーションがセカンダリとして登録されていなくても、2 番目の仮想 IP とポートリソースが自動的にセカンダリサーバーに移行します。そのサーバーでクラスターサービスを開始する前に、セカンダリ HANA データベースを読み取り可能として登録しておいてください。パラメータ AUTOMATED_REGISTER="true" を設定することで、セカンダリを自動的に登録するように HANA インスタンスのクラスターリソースを構成できます。
フェールオーバーとフォールバックの間は、2 番目の仮想 IP を使用して HANA データベースに接続するアプリケーションの既存の接続が中断される場合があります。

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

ここでは、設定をテストする方法について説明します。すべてのテストでは、ルートとしてサインインしていること、SAP HANA マスターが hn1-db-0 VM で実行されていることを前提としています。

移行をテストする

テストを開始する前に、Pacemaker に (crm_mon -r を実行して) 失敗したアクションがないこと、予期しない場所の制約 (たとえば移行テストの残り物) がないこと、HANA が (たとえば SAPHanaSR-showAttr を実行して) 同期していることを確認します。

SAPHanaSR
SAPHanaSR-angi

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

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

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

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

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

移行が完了すると、crm_mon -r 出力は次の例のようになります。

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

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

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>

移行では場所の制約が作成されますが、これは再度削除する必要があります。

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

また、セカンダリノードのリソースの状態をクリーンアップする必要があります。

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

crm_mon -r を使用して HANA リソースの状態を監視します。 hn1-db-0 で HANA を起動すると、出力は次の例のようになります。

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

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

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

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

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

# 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

クラスターノードが相互に通信できない場合、スプリットブレインシナリオのリスクがあります。このような状況では、クラスターノードは互いに同時にフェンスを試行し、フェンスレースを引き起こします。

フェンスデバイスを構成する場合は、pcmk_delay_max プロパティを構成することをお勧めします。そのため、スプリットブレインシナリオの場合、クラスターでは、各ノードのフェンシングアクションに、pcmk_delay_max 値までのランダムな遅延が発生します。最も短い遅延を持つノードがフェンシング用に選択されます。

さらに、HANA マスターを実行しているノードが優先され、スプリットブレインシナリオでフェンスレースに勝つよう、クラスター構成でプロパティ priority-fencing-delay 設定することをお勧めします。 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

SBD フェンスをテストする

SBD の設定をテストするには、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

<HANA SID>-db-<database 1> クラスターノードが再起動します。 Pacemaker サービスが再起動しない可能性があります。その場合、もう一度起動してください。

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

手動フェールオーバーをテストするには、hn1-db-0 ノードで Pacemaker サービスを停止します。

service pacemaker stop

フェールオーバー後、サービスを再度開始できます。 AUTOMATED_REGISTER="false" を設定した場合、hn1-db-0 ノードの SAP HANA リソースはセカンダリとして起動できません。

その場合は、次のコマンドを実行して HANA のインスタンスをセカンダリとして構成してください。

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

SUSE のテスト

重要

選択した OS が、使用する予定の特定の VM の種類で SAP HANA に対して SAP から認定されていることを確認してください。 SAP HANA 認定されている VM の種類とその OS リリースは、「SAP HANA 認定されている IaaS プラットフォーム」で調べることができます。使用する VM の種類に対して SAP HANA でサポートされている OS のリリースの完全な一覧を取得するために、VM の種類の詳細を確認するように注意してください。

シナリオに応じて、「SAP HANA SR Performance Optimized Scenario」(SAP HANA SR パフォーマンス最適化シナリオ) ガイドまたは「SAP HANA SR Cost Optimized Scenario」(SAP HANA SR コスト最適化シナリオ) ガイドに記載されているすべてのテストケースを実行します。 SLES for SAP のベストプラクティスに関するページに記載されているガイドを参照してください。

次のテストは、「SAP HANA SR Performance Optimized Scenario SUSE Linux Enterprise Server for SAP Applications 12 SP1」(SAP HANA SR パフォーマンス最適化シナリオ SUSE Linux Enterprise Server for SAP Applications 12 SP1) ガイドのテストに関する説明のコピーです。最新バージョンについては、ガイドも参照してください。テストを開始する前に常に HANA が同期していることを確認し、Pacemaker の設定が正しいことを確認してください。

次のテストの説明は、PREFER_SITE_TAKEOVER="true" と AUTOMATED_REGISTER="false" を想定しています。

Note

次のテストは、順番に実行するように設計されています。各テストは、前のテストの終了状態によって異なります。

テスト 1: ノード 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-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

hn1-db-0 ノード上で <hana sid>adm として次のコマンドを実行します。

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

停止した HANA インスタンスが Pacemaker によって検出され、他のノードにフェールオーバーされます。 Pacemaker によってノードが HANA セカンダリとして自動的に登録されないため、フェールオーバーが完了すると、hn1-db-0 ノード上の HANA インスタンスは停止します。

次のコマンドを実行して、hn1-db-0 ノードをセカンダリとして登録し、失敗したリソースをクリーンアップします。

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

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

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: ノード 2 上のプライマリデータベースを停止します。

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

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

hn1-db-1 ノード上で <hana sid>adm として次のコマンドを実行します。

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

停止した HANA インスタンスが Pacemaker によって検出され、他のノードにフェールオーバーされます。 Pacemaker によってノードが HANA セカンダリとして自動的に登録されないため、フェールオーバーが完了すると、hn1-db-1 ノード上の HANA インスタンスは停止します。

次のコマンドを実行して、hn1-db-1 ノードをセカンダリとして登録し、失敗したリソースをクリーンアップします。

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

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

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: ノード 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-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

hn1-db-0 ノード上で <hana sid>adm として次のコマンドを実行します。

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

強制停止された HANA インスタンスが Pacemaker によって検出され、他のノードにフェールオーバーされます。 Pacemaker によってノードが HANA セカンダリとして自動的に登録されないため、フェールオーバーが完了すると、hn1-db-0 ノード上の HANA インスタンスは停止します。

次のコマンドを実行して、hn1-db-0 ノードをセカンダリとして登録し、失敗したリソースをクリーンアップします。

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

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

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: ノード 2 上のプライマリデータベースをクラッシュさせます。

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

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

hn1-db-1 ノード上で <hana sid>adm として次のコマンドを実行します。

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

強制停止された HANA インスタンスが Pacemaker によって検出され、他のノードにフェールオーバーされます。 Pacemaker によってノードが HANA セカンダリとして自動的に登録されないため、フェールオーバーが完了すると、hn1-db-1 ノード上の HANA インスタンスは停止します。

次のコマンドを実行して、hn1-db-1 ノードをセカンダリとして登録し、失敗したリソースをクリーンアップします。

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

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

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: プライマリサイトノード (ノード 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-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

hn1-db-0 ノードでルートとして次のコマンドを実行します。

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

強制終了されたクラスターノードが Pacemaker によって検出され、ノードがフェンスされます。ノードがフェンスされると、Pacemaker で HANA インスタンスの引き継ぎがトリガーされます。フェンスノードが再起動されるときに、Pacemaker は自動的に起動しません。

次のコマンドを実行して Pacemaker を起動し、hn1-db-0 ノードの SBD メッセージを消去し、hn1-db-0 ノードをセカンダリとして登録し、失敗したリソースをクリーンアップします。

# 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

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

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: セカンダリサイトノード (ノード 2) をクラッシュさせます。

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

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

hn1-db-1 ノードでルートとして次のコマンドを実行します。

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

次のコマンドを実行して Pacemaker を起動し、hn1-db-1 ノードの SBD メッセージを消去し、hn1-db-1 ノードをセカンダリとして登録し、失敗したリソースをクリーンアップします。

# 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

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

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: ノード 2 上のセカンダリデータベースを停止する

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

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

hn1-db-1 ノード上で <hana sid>adm として次のコマンドを実行します。

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

停止した HANA インスタンスが Pacemaker によって検出され、hn1-db-1 ノード上のリソースは失敗とマークされます。 Pacemaker によって HANA インスタンスが自動的に再起動されます。

次のコマンドを実行して、失敗した状態をクリーンアップします。

# run as root
hn1-db-1>:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> 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-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: ノード 2 上のセカンダリデータベースをクラッシュさせる

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

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

hn1-db-1 ノード上で <hana sid>adm として次のコマンドを実行します。

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

強制終了された HANA インスタンスが Pacemaker によって検出され、hn1-db-1 ノード上のリソースは失敗とマークされます。次のコマンドを実行して、失敗した状態をクリーンアップします。その後、Pacemaker によって HANA インスタンスが自動的に再起動されます。

# run as root
hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> 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-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: セカンダリ HANA データベースを実行しているセカンダリサイトノード (ノード 2) をクラッシュさせます。

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

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

hn1-db-1 ノードでルートとして次のコマンドを実行します。

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

強制終了されたクラスターノードが Pacemaker によって検出され、ノードがフェンスされます。フェンスノードが再起動されるときに、Pacemaker は自動的に起動しません。

次のコマンドを実行して Pacemaker を起動し、hn1-db-1 ノードの SBD メッセージを消去し、失敗したリソースをクリーンアップします。

# 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

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

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: プライマリデータベースインデックスサーバーをクラッシュさせる

このテストは、「HANA リソースエージェントを実装する」で説明されているように、susChkSrv フックを設定した場合にのみ関連します。

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

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

hn1-db-0 ノードでルートとして次のコマンドを実行します。

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

indexserver が終了すると、susChkSrv フックはイベントを検出し、'hn1-db-0' ノードをフェンスして引き継ぎプロセスを開始するアクションをトリガーします。

次のコマンドを実行して、hn1-db-0 ノードをセカンダリとして登録し、失敗したリソースをクリーンアップします。

# 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

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

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

セカンダリノード上の indexserver をクラッシュさせることで、同等のテストケースを実行できます。 indexserver がクラッシュした場合、susChkSrv フックは発生を認識し、セカンダリノードをフェンスするアクションを開始します。

次の方法で共有

SUSE Linux Enterprise Server 上の Azure VM での SAP HANA の高可用性

SAP HANA の高可用性の計画

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

Azure portal 経由での手動による Linux VM のデプロイ

Azure Load Balancer の構成

Pacemaker クラスターの作成

SAP HANA のインストール

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

HANA リソースエージェントを実装する

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

SAP HANA クラスターリソースの作成

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

アクティブかつ読み取り可能なシステムレプリケーション用にロードバランサーを設定する

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

セカンダリ仮想 IP アドレスリソースを追加する

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

移行をテストする

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

SBD フェンスをテストする

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

SUSE のテスト

次のステップ

フィードバック

その他のリソース

次の方法で共有

SUSE Linux Enterprise Server 上の Azure VM での SAP HANA の高可用性

SAP HANA の高可用性の計画

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

Azure portal 経由での手動による Linux VM のデプロイ

Azure Load Balancer の構成

Pacemaker クラスターの作成

SAP HANA のインストール

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

HANA リソース エージェントを実装する

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

SAP HANA クラスター リソースの作成

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

アクティブかつ読み取り可能なシステム レプリケーション用にロード バランサーを設定する

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

セカンダリ仮想 IP アドレス リソースを追加する

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

移行をテストする

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

SBD フェンスをテストする

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

SUSE のテスト

次のステップ

フィードバック

その他のリソース

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

HANA リソースエージェントを実装する

SAP HANA クラスターリソースの作成

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

アクティブかつ読み取り可能なシステムレプリケーション用にロードバランサーを設定する

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

セカンダリ仮想 IP アドレスリソースを追加する