SUSE Linux Enterprise Server での HSR を使用した SAP HANA スケールアウトシステムの高可用性

[アーティクル]
06/18/2024

この記事では、Azure SUSE Linux Enterprise Server 仮想マシン (VM) 上の HANA システムレプリケーション (HSR) と Pacemaker を使用したスケールアウト構成で高可用性 SAP HANA システムをデプロイする方法について説明します。提示されたアーキテクチャの共有ファイルシステムは NFS でマウントされており、Azure NetApp Files または Azure Files の NFS 共有によって提供されます。

構成例やインストールコマンドなどでは、HANA インスタンスは 03、HANA システム ID は HN1 です。

始める前に、次の SAP のノートとホワイトペーパーを参照してください。

Azure NetApp Files のドキュメント
Azure Files のドキュメント
SAP ノート 1928533 には次のものが含まれます。
- SAP ソフトウェアのデプロイでサポートされる Azure VM サイズの一覧
- Azure VM サイズの容量に関する重要な情報
- サポートされる SAP ソフトウェア、およびオペレーティングシステム (OS) とデータベースの組み合わせ
- Microsoft Azure 上の Windows と Linux に必要な SAP カーネルバージョン
SAP ノート 2015553: SAP でサポートされる Azure 上の SAP ソフトウェアデプロイの前提条件が記載されています
SAP ノート 2205917: SUSE Linux Enterprise Server for SAP Applications 向けの推奨の OS 設定が含まれます
SAP ノート 1944799: SUSE Linux Enterprise Server for SAP Applications の SAP ガイドラインが含まれます
SAP ノート 2178632: Azure 上の SAP について報告されるすべての監視メトリックに関する詳細情報が含まれます
SAP ノート 2191498: Azure 上の Linux に必要な SAP Host Agent のバージョンが含まれます
SAP ノート 2243692: Azure 上の Linux で動作する SAP のライセンスに関する情報が含まれます
SAP ノート 1984787: SUSE Linux Enterprise Server 12 に関する一般情報が含まれます
SAP ノート 1999351: Azure Enhanced Monitoring Extension for SAP に関するその他のトラブルシューティング情報が含まれます
SAP ノート 1900823: SAP HANA ストレージ要件に関する情報が含まれます
SAP Community Wiki:Linux に関するすべての必要な SAP ノートが含まれます
Linux 上の SAP のための Azure Virtual Machines の計画と実装
Linux 上の SAP のための Azure Virtual Machines のデプロイ
Linux 上の SAP のための Azure Virtual Machines DBMS のデプロイ
SUSE SAP HA ベストプラクティスガイド: NetWeaver の高可用性および SAP HANA システムレプリケーションをオンプレミスに設定するために必要なすべての情報が含まれています (一般的なベースラインとして使用します。より詳細な情報が提供されます)
SUSE High Availability Extension 12 SP5 リリースノート
HANA システムレプリケーションに関する SUSE HA クラスターでの NFS 共有エラーの処理
SAP HANA 用 Azure NetApp Files 上の NFS v4.1 ボリューム

概要

HANA スケールアウトのインストールで HANA の高可用性を実現する方法の 1 つは、HANA システムレプリケーションを構成し、Pacemaker クラスターでの自動フェールオーバーの許可によりソリューションを保護することです。アクティブノードで障害が発生すると、クラスターは HANA リソースを他のサイトにフェールオーバーします。
提示されている構成では、各サイトに 3 つの HANA ノードが表示されているのに加え、スプリットブレインシナリオを防ぐためのマジョリティメーカーノードが表示されています。より多くの VM を HANA DB ノードとして含めるように、手順を調整できます。

提示されたアーキテクチャの HANA 共有ファイルシステム /hana/shared は、Azure NetApp Files または Azure Files の NFS 共有によって提供できます。 HANA 共有ファイルシステムは、同じ HANA システムレプリケーションサイト内の各 HANA ノードにマウントされた NFS です。ファイルシステム /hana/data と /hana/log はローカルファイルシステムであり、HANA DB ノード間で共有されません。 SAP HANA は非共有モードでインストールされます。

推奨される SAP HANA のストレージ構成については、「SAP HANA Azure VM のストレージ構成」を参照してください。

重要

パフォーマンスが重要な運用システムの場合、すべての HANA ファイルシステムを Azure NetApp Files にデプロイする場合は、SAP HANA 用の Azure NetApp Files アプリケーションボリュームグループを使用することを評価し、検討することをお勧めします。

警告

/hana/data と /hana/log を Azure Files の NFS にデプロイすることはサポートされていません。

上の図では、1 つの Azure 仮想ネットワーク内に次の 3 つのサブネットが表示されており、これは次に示す SAP HANA ネットワークの推奨事項に従っています。

クライアント通信用 - client 10.23.0.0/24
HANA 内部のノード間通信用 - inter 10.23.1.128/26
SAP HANA システムレプリケーション用 - hsr 10.23.1.192/26

/hana/data と /hana/log はローカルディスク上にデプロイされるため、ストレージとの通信用に別のサブネットと仮想ネットワークカードをデプロイする必要はありません。

Azure NetApp Files を使用している場合、 /hana/shared の NFS ボリュームは別のサブネットにデプロイされ、Azure NetApp Filesに委任されます: anf 10.23.1.0/26。

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

これ以降の手順は、リソースグループおよび 3 つの Azure ネットワークサブネット (client、inter、hsr) を持つ Azure 仮想ネットワークが既に作成されていることを前提としています。

Azure portal を使用して Linux 仮想マシンをデプロイする

Azure VM を展開します。

このドキュメントに示されている構成の場合は、次の 7 台の仮想マシンを展開します。
- HANA レプリケーションサイト 1 の HANA DB ノードとして機能する 3 台の仮想マシン: hana-s1-db1、hana-s1-db2、hana-s1-db3
- HANA レプリケーションサイト 2 の HANA DB ノードとして機能する 3 台の仮想マシン: hana-s2-db1、hana-s2-db2、hana-s2-db3
- マジョリティメーカーとして機能する小規模な仮想マシン: hana-s-mm
SAP DB HANA ノードとして展開される VM は、SAP HANA ハードウェアディレクトリで公開されているように、SAP for HANA によって認定されている必要があります。 HANA DB ノードを展開するときは、高速ネットワークが選択されていることを確認してください。

マジョリティメーカーノードに展開する VM では SAP HANA リソースが実行されないため、小規模の VM を展開できます。マジョリティメーカー VM は、スプリットブレインシナリオで奇数個のクラスターノードを実現するためのクラスター構成として使用されます。今回の例では、マジョリティメーカー VM には client サブネットに 1 つの仮想ネットワークインターフェイスが必要となるだけです。

/hana/data および /hana/log 用のローカルマネージドディスクを展開します。 /hana/data と /hana/log に推奨される最小ストレージ構成については、「SAP HANA Azure VM のストレージ構成」を参照してください。

各 VM のプライマリネットワークインターフェイスを client 仮想ネットワークサブネット内に展開します。
Azure portal 経由で VM が展開されると、ネットワークインターフェイス名が自動的に生成されます。ここではわかりやすくするために、自動的に生成された client Azure 仮想ネットワークサブネットに接続されたプライマリネットワークインターフェイスを、hana-s1-db1-client、hana-s1-db2-client、hana-s1-db3-client などのように呼びます。
重要
- 選択した OS が、使用している特定の VM の種類の SAP HANA に対して認定されていることを確認してください。 SAP HANA 認定 VM の種類と、その種類に対応する OS リリースの一覧については、SAP HANA 認定 IaaS プラットフォームに関するページをご覧ください。一覧表示されている VM の種類の詳細をクリックすると、その種類に対して SAP HANA でサポートされている OS のリリースの完全な一覧が表示されます。
- Azure Files の NFS に /hana/shared をデプロイする場合は、SLES 15 SP2 以降にデプロイすることをお勧めします。
HANA DB 仮想マシンごとに 1 つずつ、6 つのネットワークインターフェイスを inter 仮想ネットワークサブネットに作成します (この例では、hana-s1-db1-inter、hana-s1-db2-inter、hana-s1-db3-inter、hana-s2-db1-inter、hana-s2-db2-inter、hana-s2-db3-inter とします)。
HANA DB 仮想マシンごとに 1 つずつ、6 つのネットワークインターフェイスを hsr 仮想ネットワークサブネットに作成します (この例では、hana-s1-db1-hsr、hana-s1-db2-hsr、hana-s1-db3-hsr、hana-s2-db1-hsr、hana-s2-db2-hsr、hana-s2-db3-hsr とします)。
新しく作成した仮想ネットワークインターフェイスを、対応する仮想マシンに接続します。
1. Azure portal で仮想マシンに移動します。
2. 左側のペインで、 [Virtual Machines] を選択します。仮想マシン名でフィルター処理し (たとえば hana-s1-db1)、その仮想マシンを選択します。
3. [概要] ペインで、 [停止] を選択して仮想マシンの割り当てを解除します。
4. [ネットワーク] を選択してから、ネットワークインターフェイスを接続します。 [ネットワークインターフェイスの接続] ドロップダウンリストで、inter および hsr サブネットに対して既に作成したネットワークインターフェイスを選択します。
5. [保存] を選択します。
6. 残りの仮想マシン (この例では hana-s1-db2、hana-s1-db3、hana-s2-db1、hana-s2-db2、hana-s2-db3) に対して、手順 b から e を繰り返します。
7. 今のところ、仮想マシンは停止状態のままにしておきます。次に、新しく接続されたすべてのネットワークインターフェイスに対して高速ネットワークを有効にします。

次の手順を行って、inter および hsr サブネット用の追加のネットワークインターフェイスに対して高速ネットワークを有効にします。

Azure portal で Azure Cloud Shell を開きます。

次のコマンドを実行して、inter および hsr サブネットに接続された、追加のネットワークインターフェイスに対して高速ネットワークを有効にします。

az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-inter --accelerated-networking true

az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-hsr --accelerated-networking true

HANA DB 仮想マシンを起動します

Azure Load Balancer の構成

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

Note

HANA スケールアウトの場合は、バックエンドプールに仮想マシンを追加する際に、client サブネット用の NIC を選択します。
Azure CLI と PowerShell のコマンドの完全なセットを実行すると、プライマリ NIC を備えた VM がバックエンドプールに追加されます。

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

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

Note

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

Azure CLI コードの完全なセットを実行すると、ロードバランサーのセットアップが表示されます。これには、バックエンドプール内の 2 つの VM が含まれます。ご利用の HANA スケールアウト内の VM の数に応じて、バックエンドプールに VM をさらに追加できます。

# 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

PowerShell コードの完全なセットを実行すると、ロードバランサーのセットアップが表示されます。これには、バックエンドプール内の 2 つの VM が含まれます。ご利用の HANA スケールアウト内の VM の数に応じて、バックエンドプールに VM をさらに追加できます。

# 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

Note

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

重要

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 – 更新する必要がありますか?」を参照してください。

NFS の展開

/hana/shared に Azure ネイティブ NFS をデプロイするには、2 つのオプションがあります。 NFS ボリュームは、Azure NetApp Files または、Azure Files の NFS 共有にデプロイできます。 Azure ファイルは NFSv4.1 プロトコルをサポートし、Azure NetApp ファイル上の NFS は NFSv4.1 と NFSv3 の両方をサポートします。

次のセクションでは、NFS をデプロイする手順について説明します。1 つのオプションのみを選択する必要があります。

ヒント

/hana/shared を Azure Files の NFS 共有または Azure NetApp Files の NFS ボリュームのいずれかにデプロイすることを選択しました。

Azure NetApp Files インフラストラクチャを展開する

/hana/shared ファイルシステムの Azure NetApp Files ボリュームをデプロイします。 HANA システムレプリケーションサイトごとに、個別の /hana/shared ボリュームが必要になります。詳細については、「Azure NetApp Files インフラストラクチャを設定する」を参照してください。

この例では、次の Azure NetApp Files ボリュームが使用されています。

ボリューム HN1-shared-s1 (nfs://10.23.1.7/HN1-shared-s1)
ボリューム HN1-shared-s2 (nfs://10.23.1.7/HN1-shared-s2)

Azure Files インフラストラクチャに NFS をデプロイする

/hana/shared ファイルシステム用に Azure Files NFS 共有をデプロイします。 HANA システムレプリケーションサイトごとに、個別の /hana/shared Azure Files NFS 共有が必要になります。詳細については、NFS 共有の作成方法に関するページをご覧ください。

この例では、次の Azure Files NFS 共有が使用されています。

share hn1-shared-s1 (sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1)
share hn1-shared-s2 (sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2)

オペレーティングシステムの構成と準備

次のセクションの手順には、次の省略形のいずれかを表すプレフィックスが付いています。

[A]: すべてのノードに適用できます (これにはマジョリティメーカーも含まれます)
[AH]: すべての HANA DB ノードに適用できます
[M]: マジョリティメーカーノードのみに適用できます
[AH1]: SITE 1 のすべての HANA DB ノードに適用できます
[AH2]: SITE 2 のすべての HANA DB ノードに適用できます
[1]: HANA DB ノード 1、SITE 1 のみに適用できます
[2]: HANA DB ノード 1、SITE 2 のみに適用できます

次の手順を行って、OS の構成と準備を行います。

[A] 仮想マシン上にホストファイルを維持します。すべてのサブネットのエントリを含めます。この例では、次のエントリが /etc/hosts に追加されています。

# Client subnet
10.23.0.19      hana-s1-db1
10.23.0.20      hana-s1-db2
10.23.0.21      hana-s1-db3
10.23.0.22      hana-s2-db1
10.23.0.23      hana-s2-db2
10.23.0.24      hana-s2-db3
10.23.0.25      hana-s-mm    

# Internode subnet
10.23.1.132     hana-s1-db1-inter
10.23.1.133     hana-s1-db2-inter
10.23.1.134     hana-s1-db3-inter
10.23.1.135     hana-s2-db1-inter
10.23.1.136     hana-s2-db2-inter
10.23.1.137     hana-s2-db3-inter

# HSR subnet
10.23.1.196     hana-s1-db1-hsr
10.23.1.197     hana-s1-db2-hsr
10.23.1.198     hana-s1-db3-hsr
10.23.1.199     hana-s2-db1-hsr
10.23.1.200     hana-s2-db2-hsr
10.23.1.201     hana-s2-db3-hsr

[A] Azure 用の Microsoft の構成設定を使用して、構成ファイル /etc/sysctl.d/ms-az.conf を作成します。
```
vi /etc/sysctl.d/ms-az.conf

# Add the following entries in the configuration file
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv4.tcp_max_syn_backlog = 16348
net.ipv4.conf.all.rp_filter = 0
sunrpc.tcp_slot_table_entries = 128
vm.swappiness=10
```
ヒント

SAP ホストエージェントからポート範囲を管理できるように、sysctl 構成ファイルで明示的に net.ipv4.ip_local_port_range と net.ipv4.ip_local_reserved_ports を設定しないようにしてください。詳細については、SAP ノート 2382421 をご覧ください。
[A] SUSE では SAP HANA 用の特別なリソースエージェントが提供され、既定では SAP HANA スケールアップ用のエージェントがインストールされます。スケールアップ用のパッケージがインストールされている場合はアンインストールし、SAP HANA スケールアウトシナリオ用のパッケージをインストールします。この手順は、マジョリティメーカーを含むすべてのクラスター VM で実行する必要があります。

注意

SAPHanaSR-ScaleOut バージョン 0.181 以上がインストールされている必要があります。
```
# Uninstall scale-up packages and patterns
sudo zypper remove patterns-sap-hana
sudo zypper remove SAPHanaSR SAPHanaSR-doc yast2-sap-ha

# Install the scale-out packages and patterns
sudo zypper in SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc 
sudo zypper in -t pattern ha_sles
```
[AH] VM を準備する - SUSE Linux Enterprise Server for SAP Applications に対する SAP ノート 2205917 の推奨設定を適用します。

ファイルシステムを準備する

Azure Files 上の NFS 共有または Azure NetApp Files 上の NFS ボリュームの SAP 共有ディレクトリをデプロイすることを選択しました。

共有ファイルシステムをマウントする (NFS Azure NetApp Files)

この例では、共有 HANA ファイルシステムが Azure NetApp Files にデプロイされ、NFSv4.1 経由でマウントされています。 Azure NetApp Files で NFS を使用している場合にのみ、このセクションの手順に従います。

[AH] SAP Note 3024346 - Linux Kernel Settings for NetApp NFS に記載されているように、NFS を使用して NetApp システムで SAP HANA を実行する目的で OS を準備します。 NetApp 構成設定用の構成ファイル /etc/sysctl.d/91-NetApp-HANA.conf を作成します。

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

# Add the following entries in the configuration file
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1

[AH] SAP Note 3024346 - Linux Kernel Settings for NetApp NFS での推奨のとおりに sunrpc の設定を調整します。
```
vi /etc/modprobe.d/sunrpc.conf

# Insert the following line
options sunrpc tcp_max_slot_table_entries=128
```
[AH] HANA データベースボリュームのマウントポイントを作成します。
```
mkdir -p /hana/shared
```
[AH] NFS ドメイン設定を確認します。ドメインが既定の Azure NetApp Files ドメイン (すなわち defaultv4iddomain.com) として構成され、マッピングが nobody に設定されていることを確認します。
この手順は、Azure NetAppFiles NFSv4.1 を使用する場合にのみ必要です。

重要

Azure NetApp Files の既定のドメイン構成 ( defaultv4iddomain.com ) と一致するように、VM 上の /etc/idmapd.conf に NFS ドメインを設定していることを確認します。 NFS クライアント (つまり、VM) と NFS サーバー (つまり、Azure NetApp 構成) のドメイン構成が一致しない場合、VM にマウントされている Azure NetApp ボリューム上のファイルのアクセス許可は nobody と表示されます。
```
sudo cat /etc/idmapd.conf
# Example
[General]
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
```
[AH]nfs4_disable_idmapping を確認します。これは、Y に設定されている必要があります。nfs4_disable_idmapping が配置されるディレクトリ構造を作成するには、mount コマンドを実行します。アクセスがカーネル/ドライバー用に予約されるため、/sys/modules の下に手動でディレクトリを作成することはできなくなります。
この手順は、Azure NetAppFiles NFSv4.1 を使用する場合にのみ必要です。
```
# Check nfs4_disable_idmapping 
cat /sys/module/nfs/parameters/nfs4_disable_idmapping
# If you need to set nfs4_disable_idmapping to Y
mkdir /mnt/tmp
mount 10.23.1.7:/HN1-share-s1 /mnt/tmp
umount  /mnt/tmp
echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
# Make the configuration permanent
echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
```

[AH1] SITE1 HANA DB VM に共有 Azure NetApp Files ボリュームをマウントします。

sudo vi /etc/fstab
# Add the following entry
10.23.1.7:/HN1-shared-s1 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
# Mount all volumes
sudo mount -a

[AH2] SITE2 HANA DB VM に共有 Azure NetApp Files ボリュームをマウントします。

sudo vi /etc/fstab
# Add the following entry
10.23.1.7:/HN1-shared-s2 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
# Mount the volume
sudo mount -a

[AH] 対応する /hana/shared/ ファイルシステムが、NFS プロトコルバージョン NFSv4.1 を使用しているすべての HANA DB VM にマウントされていることを確認します。

sudo nfsstat -m
# Verify that flag vers is set to 4.1 
# Example from SITE 1, hana-s1-db1
/hana/shared from 10.23.1.7:/HN1-shared-s1
 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.1.7
# Example from SITE 2, hana-s2-db1
/hana/shared from 10.23.1.7:/HN1-shared-s2
 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.1.7

共有ファイルシステムをマウントする (Azure Files NFS)

この例では、共有 HANA ファイルシステムが Azure Files の NFS にデプロイされます。 Azure Files で NFS を使用している場合にのみ、このセクションの手順に従います。

[AH] HANA データベースボリュームのマウントポイントを作成します。
```
mkdir -p /hana/shared
```

[AH1] SITE1 HANA DB VM に共有 Azure NetApp Files ボリュームをマウントします。

sudo vi /etc/fstab
# Add the following entry
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
# Mount all volumes
sudo mount -a

[AH2] SITE2 HANA DB VM に共有 Azure NetApp Files ボリュームをマウントします。

sudo vi /etc/fstab
# Add the following entries
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
# Mount the volume
sudo mount -a

sudo nfsstat -m
# Example from SITE 1, hana-s1-db1
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.0.35
# Example from SITE 2, hana-s2-db1
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.0.35

データおよびログのローカルファイルシステムを準備する

提示されている構成では、ファイルシステム /hana/data と /hana/log はマネージドディスクに展開され、各 HANA DB VM にローカルでアタッチされます。各 HANA DB 仮想マシンで、ローカルのデータとログのボリュームを作成する手順を実行する必要があります。

論理ボリュームマネージャー (LVM) を使用してディスクレイアウトを設定します。次の例は、各 HANA 仮想マシンに 3 つのデータディスクがアタッチされていて、これを使用して 2 つのボリュームを作成することを前提としています。

[AH] すべての使用できるディスクの一覧を出力します。

ls /dev/disk/azure/scsi1/lun*

出力例:

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

[AH] 使用するすべてのディスクの物理ボリュームを作成します。

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

[AH] データファイル用のボリュームグループを作成します。ログファイル用に 1 つ、SAP HANA の共有ディレクトリ用に 1 つのボリュームグループを作成します。
```
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
```
[AH] 論理ボリュームを作成します。

-i スイッチを指定せずに lvcreate を使用すると、線形のボリュームが作成されます。 I/O パフォーマンスを向上させるためにストライプボリュームを作成し、SAP HANA VM のストーレジ構成に関する記事に記載されている値にストライプサイズを合わせることをお勧めします。 -i 引数は、基になる物理ボリュームの数、-I 引数はストライプサイズにする必要があります。このドキュメントでは、2 つの物理ボリュームが使用されるため、-i スイッチ引数は 2 に設定されます。データボリュームのストライプサイズは 256 KiB です。ログボリューム用に物理ボリュームが 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 mkfs.xfs /dev/vg_hana_data_HN1/hana_data
sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
```

[AH] マウントディレクトリを作成し、すべての論理ボリュームの UUID をコピーします。

sudo mkdir -p /hana/data/HN1
sudo mkdir -p /hana/log/HN1
# Write down the ID of /dev/vg_hana_data_HN1/hana_data and /dev/vg_hana_log_HN1/hana_log
sudo blkid

[AH] 論理ボリュームの fstab エントリを作成してマウントします。

sudo vi /etc/fstab

/etc/fstab ファイルに次の行を挿入します。

/dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_data_HN1-hana_data /hana/data/HN1 xfs  defaults,nofail  0  2
/dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_log_HN1-hana_log /hana/log/HN1 xfs  defaults,nofail  0  2

新しいボリュームをマウントします。

sudo mount -a

Pacemaker クラスターの作成

「Setting up Pacemaker on SUSE Linux Enterprise Server in Azure (Azure で SUSE Linux Enterprise Server に Pacemaker を設定する)」の手順に従って、この HANA サーバーに対して基本的な Pacemaker クラスターを作成します。クラスターのマジョリティメーカーを含む、すべての仮想マシンを含めます。

重要

2 ノードクラスターではないため、quorum expected-votes を 2 に設定しないでください。
ノードフェンシングが逆シリアル化されるように、クラスタープロパティ concurrent-fencing が有効になっていることを確認します。

インストール

この例では、Azure VM で HSR を使用してスケールアウト構成で SAP HANA を展開するために、HANA 2.0 SP5 を使用しました。

HANA のインストールの準備

[AH] HANA をインストールする前に、ルートパスワードを設定します。インストールが完了した後で、ルートパスワードを無効にすることができます。 root として passwd コマンドを実行します。
[1,2]/hana/shared のアクセス許可を変更します
```
chmod 775 /hana/shared
```
[1] パスワードの入力を求められることなく、このサイトの HANA DB VM である hana-s1-db2 および hana-s1-db3 に SSH 経由でログインできることを確認します。そうでない場合は、公開キーを使用した SSH アクセスの有効化に関する記事の説明に従って、SSH キーを交換します。
```
ssh root@hana-s1-db2
ssh root@hana-s1-db3
```
[2] パスワードの入力を求められることなく、このサイトの HANA DB VM である hana-s2-db2 および hana-s2-db3 に SSH 経由でログインできることを確認します。
そうでない場合は、SSH キーを交換します。
```
ssh root@hana-s2-db2
ssh root@hana-s2-db3
```
[AH] HANA 2.0 SP4 以降に必要な追加のパッケージをインストールします。詳細については、ご使用の SLES バージョンについて SAP ノート 2593824 を参照してください。
```
# In this example, using SLES12 SP5
sudo zypper install libgcc_s1 libstdc++6 libatomic1
```

各サイトの最初のノードへの HANA のインストール

[1] 「SAP HANA 2.0 のインストールと更新ガイド」の指示に従って、SAP HANA をインストールします。次の手順では、SITE 1 の最初のノードへの SAP HANA のインストールを示します。

a. HANA のインストールソフトウェアディレクトリから、hdblcm プログラムを root で起動します。 internal_network パラメーターを使用して、内部 HANA のノード間通信に使用されるサブネットのアドレス空間を渡します。
```
./hdblcm --internal_network=10.23.1.128/26
```
b. プロンプトで次の値を入力します。
- [Choose an action](アクションを選択する) : 「1」と入力します (インストールの場合)。
- [Additional components for installation](追加でインストールするコンポーネント) : 「2, 3」と入力します。
- [installation path](インストールパス): Enter キーを押します (既定値は /hana/shared)
- [Local Host Name](ローカルホスト名) : Enter キーを押して既定値をそのまま使用します
- [Do you want to add hosts to the system?](システムにホストを追加しますか?) : 「n」と入力します
- [SAP HANA System ID](SAP HANA システム ID) : 「HN1」と入力します
- [Instance number](インスタンス番号) [00]: 「03」と入力します
- [Local Host Worker Group](ローカルホストワーカーグループ) [既定値]: Enter キーを押して既定値をそのまま使用します
- [Select System Usage / Enter index [4](システム用途の選択/インデックスを入力 [4]) \: 「4」と入力します (カスタム)
- [Location of Data Volumes](データボリュームの場所) [/hana/data/HN1]: Enter キーを押して既定値をそのまま使用します
- [Location of Log Volumes](ログボリュームの場所) [/hana/log/HN1]: Enter キーを押して既定値をそのまま使用します
- [Restrict maximum memory allocation?](メモリの最大割り当てを制限しますか?) [n]: 「n」と入力します
- [Certificate Host Name For Host hana-s1-db1](ホスト hana-s1-db1 の証明書ホスト名) [hana-s1-db1]: Enter キーを押して既定値をそのまま使用します
- [SAP Host Agent User (sapadm) Password](SAP ホストエージェントユーザー (sapadm) のパスワード) : パスワードを入力します
- [Confirm SAP Host Agent User (sapadm) Password](SAP ホストエージェントユーザー (sapadm) のパスワードの確認) : パスワードを入力します
- [System Administrator (hn1adm) Password](システム管理者 (hn1adm) のパスワード) : パスワードを入力します
- [System Administrator Home Directory](システム管理者のホームディレクトリ) [/usr/sap/HN1/home]: Enter キーを押して既定値をそのまま使用します
- [System Administrator Login Shell](システム管理者のログインシェル) [/bin/sh]: Enter キーを押して既定値をそのまま使用します
- [System Administrator User ID](システム管理者のユーザー ID) [1001]: Enter キーを押して既定値をそのまま使用します
- [Enter ID of User Group (sapsys)](ユーザーグループ (sapsys) の ID を入力) [79]: Enter キーを押して既定値をそのまま使用します
- [System Database User (system) Password](システムデータベースユーザー (system) のパスワード) : システムのパスワードを入力します
- [Confirm System Database User (system) Password](システムデータベースユーザー (system) のパスワードの確認) : システムのパスワードを入力します
- [Restart system after machine reboot?](コンピューターの再起動後にシステムを再起動しますか?) [n]: 「n」と入力します
- [Do you want to continue (y/n)](続行しますか? (y/n)) : 概要を検証し、すべて問題がなさそうな場合は「y」と入力します
[2] 上記の手順を繰り返して、SITE 2 の最初のノードに SAP HANA をインストールします。
[1,2] global.ini を確認します

global.ini を表示し、内部 SAP HANA のノード間通信が正しく構成されていることを確認します。 communication セクションを確認します。 inter サブネットに対するアドレス空間があり、listeninterface が .internal に設定されている必要があります。 internal_hostname_resolution セクションを確認します。 inter サブネットに属する HANA 仮想マシンの IP アドレスが含まれている必要があります。
```
  sudo cat /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
  # Example from SITE1 
  [communication]
  internal_network = 10.23.1.128/26
  listeninterface = .internal
  [internal_hostname_resolution]
  10.23.1.132 = hana-s1-db1
  10.23.1.133 = hana-s1-db2
  10.23.1.134 = hana-s1-db3
```
[1,2] SAP note 2080991 の説明に従って、共有されていない環境でのインストールのための global.ini を準備します。
```
 sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
 [persistence]
 basepath_shared = no
```

[1,2] SAP HANA を再起動して、変更をアクティブにします。

 sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem
 sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem

[1,2] クライアントインターフェイスが client サブネットの IP アドレスを使用して通信するようになっていることを確認します。
```
# Execute as hn1adm
/usr/sap/HN1/HDB03/exe/hdbsql -u SYSTEM -p "password" -i 03 -d SYSTEMDB 'select * from SYS.M_HOST_INFORMATION'|grep net_publicname
# Expected result - example from SITE 2
"hana-s2-db1","net_publicname","10.23.0.22"
```
構成を確認する方法については、SAP ノート「2183363 - SAP HANA 内部ネットワークの構成」を参照してください。
[AH] HANA のインストールエラーを回避するために、データディレクトリとログディレクトリのアクセス許可を変更します。
```
 sudo chmod o+w -R /hana/data /hana/log
```
[1] セカンダリ HANA ノードをインストールします。このステップでは、例として SITE 1 での手順を示します。

a. 常駐の hdblcm プログラムを root で開始します。
```
 cd /hana/shared/HN1/hdblcm
 ./hdblcm 
```
b. プロンプトで次の値を入力します。
- [Choose an action](アクションを選択する) : 「2」と入力します (ホストの追加)
- [Enter comma separated host names to add](追加するホストの名前をコンマ区切りで入力) : hana-s1-db2, hana-s1-db3
- [Additional components for installation](追加でインストールするコンポーネント) : 「2, 3」と入力します。
- [Enter Root User Name](ルートユーザー名を入力) [root] : Enter キーを押して既定値をそのまま使用します
- [Select roles for host 'hana-s1-db2'](ホスト 'hana-s1-db2' のロールを選択) [1] :1 (worker)
- [Enter Host Failover Group for host 'hana-s1-db2'](ホスト 'hana-s1-db2' のホストフェールオーバーグループを入力) [既定値] : Enter キーを押して既定値をそのまま使用します
- [Enter Storage Partition Number for host 'hana-s1-db2' [<<assign automatically>>]](ホスト 'hana-s1-db2' のストレージパーティション番号を入力 [<<自動割り当て>>]): Enter キーを押して既定値をそのまま使用します
- [Enter Worker Group for host 'hana-s1-db2'](ホスト 'hana-s1-db2' のワーカーグループを入力) [既定値] : Enter キーを押して既定値をそのまま使用します
- [Select roles for host 'hana-s1-db3'](ホスト 'hana-s1-db3' のロールを選択) [1] :1 (worker)
- [Enter Host Failover Group for host 'hana-s1-db3'](ホスト 'hana-s1-db3' のホストフェールオーバーグループを入力) [既定値] : Enter キーを押して既定値をそのまま使用します
- [Enter Storage Partition Number for host 'hana-s1-db3' [<<assign automatically>>]](ホスト 'hana-s1-db3' のストレージパーティション番号を入力 [<<自動割り当て>>]): Enter キーを押して既定値をそのまま使用します
- [Enter Worker Group for host 'hana-s1-db3'](ホスト 'hana-s1-db3' のワーカーグループを入力) [既定値] : Enter キーを押して既定値をそのまま使用します
- [System Administrator (hn1adm) Password](システム管理者 (hn1adm) のパスワード) : パスワードを入力します
- [Enter SAP Host Agent User (sapadm) Password](SAP ホストエージェントユーザー (sapadm) のパスワードを入力) : パスワードを入力します
- [Confirm SAP Host Agent User (sapadm) Password](SAP ホストエージェントユーザー (sapadm) のパスワードの確認) : パスワードを入力します
- [Certificate Host Name For Host hana-s1-db2](ホスト hana-s1-db2 の証明書ホスト名) [hana-s1-db2]: Enter キーを押して既定値をそのまま使用します
- [Certificate Host Name For Host hana-s1-db3](ホスト hana-s1-db3 の証明書ホスト名) [hana-s1-db3]: Enter キーを押して既定値をそのまま使用します
- [Do you want to continue (y/n)](続行しますか? (y/n)) : 概要を検証し、すべて問題がなさそうな場合は「y」と入力します
[2] 上記の手順を繰り返して、SITE 2 にセカンダリ SAP HANA ノードをインストールします。

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

[1] SITE 1 でシステムレプリケーションを構成します。

hn1adm としてデータベースをバックアップします。

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

システム PKI ファイルをセカンダリサイトにコピーします。

scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY  hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/

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

hdbnsutil -sr_enable --name=HANA_S1

[2] SITE 2 でシステムレプリケーションを構成します。

2 番目のサイトを登録して、システムレプリケーションを開始します。 <hanasid>adm として次のコマンドを実行します。
```
sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hana-s1-db1 --remoteInstance=03 --replicationMode=sync --name=HANA_S2
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 |
# | -------- | ------------- | ----- | ------------ | --------- | ------- | --------- | ------------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
# | HN1      | hana-s1-db3   | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db3   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | SYSTEMDB | hana-s1-db1   | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1   |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db1   | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1   |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db1   | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db2   | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db2   |     30303 |         2 | HANA_S2   | 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: HANA_S1

[1,2] HANA システムレプリケーション仮想ネットワークインターフェイスを通じて、HANA システムレプリケーションの通信が行われるように、HANA の構成を変更します。
- 両方のサイトで HANA を停止します
```
sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem HDB
```
- global.ini を編集して、HANA システムレプリケーションのホストマッピングを追加します。hsr サブネットの IP アドレスを使用します。
```
sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
#Add the section
[system_replication_hostname_resolution]
10.23.1.196 = hana-s1-db1
10.23.1.197 = hana-s1-db2
10.23.1.198 = hana-s1-db3
10.23.1.199 = hana-s2-db1
10.23.1.200 = hana-s2-db2
10.23.1.201 = hana-s2-db3
```
- 両方のサイトで HANA を開始します
```
sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem HDB
```
詳細については、システムレプリケーションのホスト名前解決に関するページを参照してください。

ファイルシステムリソースの作成

ダミーファイルシステムクラスターリソースを作成します。これは、NFS でマウントされたファイルシステム /hana/shared へのアクセスに問題がある場合に失敗の監視と報告を行います。これにより、/hana/shared へのアクセスで問題が発生した場合、クラスターがフェールオーバーをトリガーできます。詳細については、HANA システムレプリケーションに関する SUSE HA クラスターでの NFS 共有エラーの処理に関する記事を参照ください

[1] HANA クラスターリソースの作成準備として、pacemaker をメンテナンスモードにします。
```
crm configure property maintenance-mode=true
```
[1、2] NFS マウントファイルシステム /hana/shared にディレクトリを作成します。これは、ファイルシステムの特別な監視リソースで使用されます。このディレクトリは、両方のサイトに作成する必要があります。
```
mkdir -p /hana/shared/HN1/check
```
[AH] 特別なファイルシステム監視リソースをマウントするために使用されるディレクトリを作成します。このディレクトリは、すべての HANA クラスターノード上に作成する必要があります。
```
mkdir -p /hana/check
```
[1] ファイルシステムのクラスターリソースを作成します。
```
crm configure primitive fs_HN1_HDB03_fscheck Filesystem \
  params device="/hana/shared/HN1/check" \
  directory="/hana/check" fstype=nfs4 \
  options="bind,defaults,rw,hard,proto=tcp,noatime,nfsvers=4.1,lock" \
  op monitor interval=120 timeout=120 on-fail=fence \
  op_params OCF_CHECK_LEVEL=20 \
  op start interval=0 timeout=120 op stop interval=0 timeout=120

crm configure clone cln_fs_HN1_HDB03_fscheck fs_HN1_HDB03_fscheck \
  meta clone-node-max=1 interleave=true

crm configure location loc_cln_fs_HN1_HDB03_fscheck_not_on_mm \
  cln_fs_HN1_HDB03_fscheck -inf: hana-s-mm    
```
監視操作に OCF_CHECK_LEVEL=20 属性を追加して、監視操作でファイルシステムの読み取り/書き込みテストを実行できるようにします。この属性がない場合、監視操作ではファイルシステムがマウントされていることのみを確認します。接続が失われると、アクセス不可能であるにもかかわらずファイルシステムがマウントされたままになる場合があるため、これは問題になる可能性があります。

on-fail=fence 属性も監視操作に追加されます。このオプションを使用すると、ノードで監視操作が失敗した場合、そのノードはすぐにフェンスされます。

HANA HA フック SAPHanaSrMultiTarget と susChkSrv を実装する

これは、クラスターとの統合と、クラスターのフェールオーバーが可能になった場合の検出を最適化するための重要な手順です。 SAPHanaSrMultiTarget Python フックを構成することを強くお勧めします。 HANA 2.0 SP5 以上では、SAPHanaSrMultiTarget と susChkSrv の両方のフックを実装することをお勧めします。

Note

SAPHanaSrMultiTarget HA プロバイダーは、HANA スケールアウトのための SAPHanaSR に代わるものです。SAPHanaSR については、このドキュメントの以前のバージョンで説明されていました。
新しい HANA HA フックに伴う変更については、SUSE のブログ記事を参照してください。

SAPHanaSrMultiTarget フックに関して示している手順は、新規インストール用です。既存の環境を SAPHanaSR から SAPHanaSrMultiTarget プロバイダーにアップグレードするにはいくつかの変更が必要ですが、このドキュメントでは説明しません。既存の環境でディザスターリカバリー用の第 3 のサイトが使用されておらず、HANA マルチターゲットシステムレプリケーションが使用されていない場合は、SAPHanaSR HA プロバイダーを引き続き使用できます。

SusChkSrv によって主要 SAPHanaSrMultiTarget HA プロバイダーの機能が拡張されます。これは、HANA プロセス hdbindexserver がクラッシュする状況で動作します。 1 つのプロセスがクラッシュした場合、通常、HANA は再起動を試みます。 indexserver プロセスの再起動には長時間かかる場合があり、その間は HANA データベースが応答しません。 susChkSrv が実装されている場合は、hdbindexserver プロセスが同じノードで再起動するのを待つ代わりに、構成可能な即時のアクションが実行されます。 HANA スケールアウトの susChkSrv は、すべての HANA VM に対して個別に動作します。構成済みのアクションによって、HANA が強制終了されるか、影響を受ける VM がフェンスされ、これで構成済みのタイムアウト期間内にフェールオーバーがトリガーされます。

両方の HANA HA フックの運用には、SUSE SLES 15 SP1 以上が必要です。その他の依存関係を次の表に示します。

SAP HANA HA フック	必要な HANA のバージョン	必要な SAPHanaSR-ScaleOut
SAPHanaSrMultiTarget	HANA 2.0 SPS4 以上	0.180 以上
susChkSrv	HANA 2.0 SPS5 以上	0.184.1 以上

両方のフックを実装する手順:

[1,2] 両方のシステムレプリケーションサイトで HANA を停止します。 <sid>adm として実行します。
```
sapcontrol -nr 03 -function StopSystem
```
[1,2] 各クラスターサイトで global.ini を調整します。 susChkSrv フックの前提条件が満たされていない場合は、ブロック [ha_dr_provider_suschksrv] を一切構成しないでください。
susChkSrv の動作は、パラメーター action_on_lost を使用して調整できます。有効な値は [ ignore | stop | kill | fence ] です。
```
# add to global.ini on both sites. Do not copy global.ini between sites.
[ha_dr_provider_saphanasrmultitarget]
provider = SAPHanaSrMultiTarget
path = /usr/share/SAPHanaSR-ScaleOut
execution_order = 1

[ha_dr_provider_suschksrv]
provider = susChkSrv
path = /usr/share/SAPHanaSR-ScaleOut
execution_order = 3
action_on_lost = kill

[trace]
ha_dr_saphanasrmultitarget = info
```
SUSE によって配信される HA フックの既定の場所は /usr/share/SAPHanaSR-ScaleOut です。この標準の場所を使うことには利点があります。python フックコードの更新が OS またはパッケージの更新を通じて自動的に行われ、HANA によって次回の再起動時に使用されるからです。必要に応じて独自のパス、たとえば /hana/shared/myHooks を使用すると、OS の更新と使用されているフックバージョンとを切り離すことができます。

[AH] このクラスターでは、<sid>adm のための sudoers 構成がクラスターノード上に必要です。この例では、新しいファイルを作成することで実現します。 root としてコマンドを実行し、hn1 の値を正しい小文字の SID に変更してください。

cat << EOF > /etc/sudoers.d/20-saphana
# SAPHanaSR-ScaleOut needs for HA/DR hook scripts
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_site_srHook_*
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_gsh *
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=hn1 *
EOF

[1,2] 両方のレプリケーションサイトで SAP HANA を開始します。 <sid>adm として実行します。
```
sapcontrol -nr 03 -function StartSystem 
```

[A] フックのインストールがすべてのクラスターノードでアクティブであることを確認します。 <sid>adm として実行します。

cdtrace
grep HADR.*load.*SAPHanaSrMultiTarget nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.31001.000.trc:[14162]{-1}[-1/-1] 2023-01-26 12:53:55.728027 i ha_dr_provider   HADRProviderManager.cpp(00083) : loading HA/DR Provider 'SAPHanaSrMultiTarget' from /usr/share/SAPHanaSR-ScaleOut/
grep SAPHanaSr.*init nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.31001.000.trc:[17636]{-1}[-1/-1] 2023-01-26 16:30:19.256705 i ha_dr_SAPHanaSrM SAPHanaSrMultiTarget.py(00080) : SAPHanaSrMultiTarget.init() CALLING CRM: <sudo /usr/sbin/crm_attribute -n hana_hn1_gsh -v 2.2  -l reboot> rc=0
# nameserver_hana-s1-db1.31001.000.trc:[17636]{-1}[-1/-1] 2023-01-26 16:30:19.256739 i ha_dr_SAPHanaSrM SAPHanaSrMultiTarget.py(00081) : SAPHanaSrMultiTarget.init() Running srHookGeneration 2.2, see attribute hana_hn1_gsh too

susChkSrv フックのインストールを確認します。 <sid>adm として実行します。

cdtrace
egrep '(LOST:|STOP:|START:|DOWN:|init|load|fail)' nameserver_suschksrv.trc
# Example output
# 2023-01-19 08:23:10.581529  [1674116590-10005] susChkSrv.init() version 0.7.7, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9
# 2023-01-19 08:23:31.553566  [1674116611-14022] START: indexserver event looks like graceful tenant start
# 2023-01-19 08:23:52.834813  [1674116632-15235] START: indexserver event looks like graceful tenant start (indexserver started)

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

[1] HANA クラスターリソースを作成します。次のコマンドを root で実行します。

クラスターが既にメンテナンスモードになっていることを確認します。

次に、HANA トポロジリソースを作成します。

sudo crm configure primitive rsc_SAPHanaTopology_HN1_HDB03 ocf:suse:SAPHanaTopology \
  op monitor interval="10" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="HN1" InstanceNumber="03"

sudo crm configure clone cln_SAPHanaTopology_HN1_HDB03 rsc_SAPHanaTopology_HN1_HDB03 \
 meta clone-node-max="1" target-role="Started" interleave="true"

次に、HANA インスタンスリソースを作成します。

Note

この記事には、Microsoft が使用しなくなった用語への言及が含まれています。ソフトウェアからこれらの用語が削除された時点で、この記事から削除します。
```
sudo crm configure primitive rsc_SAPHana_HN1_HDB03 ocf:suse:SAPHanaController \
  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="HN1" InstanceNumber="03" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

sudo crm configure ms msl_SAPHana_HN1_HDB03 rsc_SAPHana_HN1_HDB03 \
  meta clone-node-max="1" master-max="1" interleave="true"
```
重要

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

仮想 IP と関連するリソースを作成します。

sudo crm configure primitive rsc_ip_HN1_HDB03 ocf:heartbeat:IPaddr2 \
  op monitor interval="10s" timeout="20s" \
  params ip="10.23.0.27"

sudo crm configure primitive rsc_nc_HN1_HDB03 azure-lb port=62503 \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0

sudo crm configure group g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 rsc_nc_HN1_HDB03

クラスターの制約を作成します

# Colocate the IP with HANA master
sudo crm configure colocation col_saphana_ip_HN1_HDB03 4000: g_ip_HN1_HDB03:Started \
  msl_SAPHana_HN1_HDB03:Master  

# Start HANA Topology before HANA  instance
sudo crm configure order ord_SAPHana_HN1_HDB03 Optional: cln_SAPHanaTopology_HN1_HDB03 \
  msl_SAPHana_HN1_HDB03

# HANA resources don't run on the majority maker node
sudo crm configure location loc_SAPHanaCon_not_on_majority_maker msl_SAPHana_HN1_HDB03 -inf: hana-s-mm
sudo crm configure location loc_SAPHanaTop_not_on_majority_maker cln_SAPHanaTopology_HN1_HDB03 -inf: hana-s-mm

[1] 追加のクラスタープロパティを構成します

sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=50

[1] クラスターのメンテナンスモードを解除します。クラスターの状態が正常であることと、すべてのリソースが起動されていることを確認します。

# Cleanup any failed resources - the following command is example 
crm resource cleanup rsc_SAPHana_HN1_HDB03

# Place the cluster out of maintenance mode
sudo crm configure property maintenance-mode=false

[1] HANA HA フックとクラスターとの間の通信を確認します。SID の状態は SOK、両方のレプリケーションサイトの状態は P(rimary) または S(econdary) と表示されます。
```
sudo /usr/sbin/SAPHanaSR-showAttr
# Expected result
# Global cib-time                 maintenance prim  sec sync_state upd
# ---------------------------------------------------------------------
# HN1    Fri Jan 27 10:38:46 2023 false       HANA_S1 -   SOK        ok
# 
# Sites     lpt        lss mns        srHook srr
# -----------------------------------------------
# HANA_S1     1674815869 4   hana-s1-db1 PRIM   P
# HANA_S2     30         4   hana-s2-db1 SWAIT  S
```
Note

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

SAP HANA フェールオーバーのテスト

Note

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

テストを開始する前に、クラスターと SAP HANA システムのレプリケーション状態を確認します。

a. 失敗したクラスターアクションがないことを確認します

#Verify that there are no failed cluster actions
crm status
# Example 
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Full list of resources:
#
# stonith-sbd    (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s1-db1 ]
#     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s1-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s1-db1

b. SAP HANA システムレプリケーションが同期されていることを確認します

# Verify HANA HSR is in sync
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 | hana-s1-db1  | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1  |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db1  | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1  |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db1  | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db3  | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db3  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db2  | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db2  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#
#status system replication site "1": ACTIVE
#overall system replication status: ACTIVE
#
#Local System Replication State
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
#mode: PRIMARY
#site id: 1
#site name: HANA_S1

SLES での Azure VM 上の SAP HANA の HA と SLES レプリケーションのスケールアウトでのパフォーマンス最適化シナリオに関する記事に記載されているテストを実行して、SAP HANA クラスター構成を十分に検証することをお勧めします。
ノードが NFS 共有 (/hana/shared) へのアクセスを失ったときの障害シナリオに備えてクラスター構成を検証します。

SAP HANA リソースエージェントでは、フェールオーバー中の操作の実行は /hana/shared に保存されるバイナリに依存しています。提示されている構成では、ファイルシステム /hana/shared は NFS 経由でマウントされています。実行可能なテストは、プライマリサイト VM の 1 つで /hana/shared NFS マウントファイルシステムへのアクセスをブロックする一時的なファイアウォール規則を作成することです。この方法では、アクティブなシステムレプリケーションサイトで /hana/shared へのアクセスが失われた場合に、クラスターがフェールオーバーされることを検証します。

予想される結果: プライマリサイト VM の 1 つで /hana/shared NFS マウントファイルシステムへのアクセスをブロックすると、ファイルシステムに対して読み取り/書き込み操作を実行する監視操作は失敗します。これは、ファイルシステムにアクセスできず、HANA リソースのフェールオーバーがトリガーされるためです。 HANA ノードが NFS 共有へのアクセスを失った場合も、同じ結果が予想されます。

クラスターリソースの状態を確認するには、crm_mon または crm status を実行します。テスト開始前のリソースの状態:
```
# Output of crm_mon
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Active resources:
#
#stonith-sbd     (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s1-db1 ]
#     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1     
```
/hana/shared のエラーをシミュレートするには:
- Azure NetApp Files で NFS を使用している場合は、最初にプライマリサイトの /hana/shared Azure NetApp Files ボリュームの IP アドレスを確認します。これを行うには、df -kh|grep /hana/shared を実行します。
- Azure Files で NFS を使用している場合は、最初にストレージアカウントのプライベートエンドポイントの IP アドレスを確認します。
次に、いずれかのプライマリ HANA システムレプリケーションサイト VM で次のコマンドを実行して、/hana/shared NFS ファイルシステムの IP アドレスへのアクセスをブロックする一時的なファイアウォール規則を設定します。

この例では、Azure NetApp Files ボリューム /hana/shared の hana-s1-db1 でコマンドが実行されました。
```
iptables -A INPUT -s 10.23.1.7 -j DROP; iptables -A OUTPUT -d 10.23.1.7 -j DROP
```
クラスターリソースは、もう 1 つの HANA システムレプリケーションサイトに移行されます。

AUTOMATED_REGISTER="false" に設定した場合は、セカンダリサイトで SAP HANA システムレプリケーションを構成する必要があります。この場合、次のコマンドを実行して、SAP HANA をセカンダリとして再構成することができます。
```
# Execute on the secondary 
su - hn1adm
# Make sure HANA is not running on the secondary site. If it is started, stop HANA
sapcontrol -nr 03 -function StopWait 600 10
# Register the HANA secondary site
hdbnsutil -sr_register --name=HANA_S1 --remoteHost=hana-s2-db1 --remoteInstance=03 --replicationMode=sync
# Switch back to root and cleanup failed resources
crm resource cleanup SAPHana_HN1_HDB03
```
テスト後のリソースの状態は次のようになります。
```
# Output of crm_mon
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Active resources:
#
#stonith-sbd     (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s2-db1 ]
#     Slaves: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db2 hana-s2-db3 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1
```

次のステップ

SAP のための Azure Virtual Machines の計画と実装
SAP のための Azure Virtual Machines のデプロイ
SAP のための Azure Virtual Machines DBMS のデプロイ
SAP HANA 用 Azure NetApp Files 上の NFS v4.1 ボリューム
Azure VM 上の SAP HANA の高可用性を確保し、ディザスターリカバリーを計画する方法を確認するには、「Azure Virtual Machines (VM) 上の SAP HANA の高可用性」を参照してください。

次の方法で共有

SUSE Linux Enterprise Server での HSR を使用した SAP HANA スケールアウトシステムの高可用性

概要

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

Azure portal を使用して Linux 仮想マシンをデプロイする

Azure Load Balancer の構成

NFS の展開

Azure NetApp Files インフラストラクチャを展開する

Azure Files インフラストラクチャに NFS をデプロイする

オペレーティングシステムの構成と準備

ファイルシステムを準備する

共有ファイルシステムをマウントする (NFS Azure NetApp Files)

共有ファイルシステムをマウントする (Azure Files NFS)

データおよびログのローカルファイルシステムを準備する

Pacemaker クラスターの作成

インストール

HANA のインストールの準備

各サイトの最初のノードへの HANA のインストール

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

ファイルシステムリソースの作成

HANA HA フック SAPHanaSrMultiTarget と susChkSrv を実装する

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

SAP HANA フェールオーバーのテスト

次のステップ

フィードバック

その他のリソース

次の方法で共有

SUSE Linux Enterprise Server での HSR を使用した SAP HANA スケールアウト システムの高可用性

概要

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

Azure portal を使用して Linux 仮想マシンをデプロイする

Azure Load Balancer の構成

NFS の展開

Azure NetApp Files インフラストラクチャを展開する

Azure Files インフラストラクチャに NFS をデプロイする

オペレーティング システムの構成と準備

ファイル システムを準備する

共有ファイル システムをマウントする (NFS Azure NetApp Files)

共有ファイル システムをマウントする (Azure Files NFS)

データおよびログのローカル ファイル システムを準備する

Pacemaker クラスターの作成

インストール

HANA のインストールの準備

各サイトの最初のノードへの HANA のインストール

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

ファイル システム リソースの作成

HANA HA フック SAPHanaSrMultiTarget と susChkSrv を実装する

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

SAP HANA フェールオーバーのテスト

次のステップ

フィードバック

その他のリソース

SUSE Linux Enterprise Server での HSR を使用した SAP HANA スケールアウトシステムの高可用性

オペレーティングシステムの構成と準備

ファイルシステムを準備する

共有ファイルシステムをマウントする (NFS Azure NetApp Files)

共有ファイルシステムをマウントする (Azure Files NFS)

データおよびログのローカルファイルシステムを準備する

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

ファイルシステムリソースの作成

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