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

この記事では、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 Note 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 ノードが表示されているのに加え、スプリット ブレイン シナリオを防ぐためのマジョリティ メーカー ノードが表示されています。 この手順は、HANA データベース (DB) ノードとしてより多くの VM を含むように調整できます。

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

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

重要

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

警告

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

上の図では、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。

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

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

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

1. 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 HANA 認定 IaaS プラットフォームに記載されているように、SAP HANA 認定の VM サイズを使用して、VM を SAP DB ノードとしてデプロイします。 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 のリリースの完全な一覧が表示されます。
• /hana/sharedを Azure Files 上の NFS にデプロイする場合は、SUSE Linux Enterprise Server (SLES) 15 SP2 以降にデプロイすることをお勧めします。

2. 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 とします)。

3. 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 とします)。

4. 新しく作成した仮想ネットワーク インターフェイスを、対応する仮想マシンに接続します。

   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. 今のところ、仮想マシンは停止状態のままにしておきます。 次に、新しく接続されたすべてのネットワーク インターフェイスに対して高速ネットワークを有効にします。

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

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

   2. 次のコマンドを実行して、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 ノードに Azure CLI パッケージをインストール az 必要はありません。 CLI がインストールされている任意のマシンから実行することも、Azure Cloud Shell を使用することもできます。

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

Azure Load Balancer の構成

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

メモ

• HANA スケールアウトの場合は、バックエンド プールに仮想マシンを追加するときに、 client サブネットのネットワーク インターフェイスを選択します。
• Azure CLI と PowerShell のコマンドの完全なセットにより、プライマリ ネットワーク インターフェイスを持つ VM がバックエンド プールに追加されます。

Azure Portal

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

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

メモ

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

Azure CLI

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の

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

メモ

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

重要

• 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 の構成と準備を行います。

1. [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
   

2. [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 をご覧ください。

3. [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 を使用している場合にのみ、このセクションの手順に従います。

1. [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
   

2. [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
   

3. [AH] HANA データベース ボリュームのマウント ポイントを作成します。

   mkdir -p /hana/shared
   

4. [AH] NFS ドメイン設定を確認します。 ドメインが既定の Azure NetApp Files ドメイン (すなわち defaultv4iddomain.com) として構成され、マッピングが nobody に設定されていることを確認します。
   この手順は、Azure NetAppFiles NFSv4.1 を使用する場合にのみ必要です。

   重要

   Azure NetApp Files の既定のドメイン構成 ( /etc/idmapd.conf ) と一致するように、VM 上の defaultv4iddomain.com に 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
   

5. [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
   

6. [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 
   

7. [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 
   

8. [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 を使用している場合にのみ、このセクションの手順に従います。

1. [AH] HANA データベース ボリュームのマウント ポイントを作成します。

   mkdir -p /hana/shared
   

2. [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 
   

3. [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 
   

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

   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 つのボリュームを作成することを前提としています。

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

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

   出力例:

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

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

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

3. [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
   

4. [AH] 論理ボリュームを作成します。

   lvcreate スイッチを指定せずに -i を使用すると、線形のボリュームが作成されます。 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
   

5. [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
   

6. [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=true が設定されていることを確認します。
• stonith-sbd リソースには、逆シリアル化された stonith アクションを許可するために、値が負の 1 (無制限) のパラメーター pcmk_action_limit=-1 を含める必要があります。

インストール

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

HANA のインストールの準備

1. [AH] HANA をインストールする前に、ルート パスワードを設定します。 インストールが完了したら、ルート パスワードを無効にすることができます。 root として passwd コマンドを実行します。

2. [1,2]/hana/shared のアクセス許可を変更します

   chmod 775 /hana/shared
   

3. [1] パスワードの入力を求められることなく、このサイトの HANA DB VM である hana-s1-db2 および hana-s1-db3 に SSH 経由でログインできることを確認します。 そうでない場合は、公開キーを使用した SSH アクセスの有効化に関する記事の説明に従って、SSH キーを交換します。

   ssh root@hana-s1-db2
   ssh root@hana-s1-db3
   

4. [2] パスワードの入力を求められることなく、このサイトの HANA DB VM である hana-s2-db2 および hana-s2-db3 に SSH 経由でログインできることを確認します。
   そうでない場合は、SSH キーを交換します。

   ssh root@hana-s2-db2
   ssh root@hana-s2-db3
   

5. [AH] HANA 2.0 SP4 以降に必要な追加のパッケージをインストールします。 詳細については、ご使用の SLES バージョンについて SAP ノート 2593824 を参照してください。

   # In this example, using SLES12 SP5
   sudo zypper install libgcc_s1 libstdc++6 libatomic1
   

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

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

   ある。 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」と入力します
   • ホスト 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. [2] 上記の手順を繰り返して、SITE 2 の最初のノードに SAP HANA をインストールします。

3. [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
   

4. [1,2] SAP note global.ini の説明に従って、共有されていない環境でのインストールのための を準備します。

    sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
    [persistence]
    basepath_shared = no
   

5. [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
   

6. [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 内部ネットワークの構成」を参照してください。

7. [AH] HANA のインストール エラーを回避するために、データ ディレクトリとログ ディレクトリのアクセス許可を変更します。

    sudo chmod o+w -R /hana/data /hana/log
   

8. [1] セカンダリ HANA ノードをインストールします。 このステップでは、例として SITE 1 での手順を示します。

   ある。 常駐の 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」と入力します

9. [2] 上記の手順を繰り返して、SITE 2 にセカンダリ SAP HANA ノードをインストールします。

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

1. [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')"
   

   システムのセキュリティで保護されたストレージ キー ファイルをセカンダリ サイトにコピーします。

   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. [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
   

3. [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
   

4. [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
     

   詳細については、システム レプリケーションのホスト名前解決に関するページを参照してください。

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

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

警告

既に構成されているクラスター内の SAPHanaSR-angi によって SAPHanaSR-ScaleOut パッケージを置き換えないでください。 SAPHanaSR から SAPHanaSR-angi にアップグレードするには、特定の手順が必要です。 詳細については、SUSE のブログ投稿 「SAPHanaSR-angi にアップグレードする方法」を参照してください。

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

SAPHanaSR-angi

メモ

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

マジョリティ メーカーを含むすべてのクラスター VM で次のコマンドを実行して、高可用性パッケージをインストールします。

sudo zypper install SAPHanaSR-angi
sudo zypper in -t pattern ha_sles

SAPHanaSR-ScaleOut

メモ

SAPHanaSR-ScaleOut バージョン 0.181 以上がインストールされている必要があります。

SUSE は SAP HANA 用の特別なリソース エージェントを提供し、既定では SAP HANA スケールアップ用のエージェントがインストールされます。 スケールアップ用のパッケージがインストールされている場合はアンインストールし、シナリオ SAP HANA スケールアウト用のパッケージをインストールします。マジョリティ メーカーを含むすべてのクラスター VM で次のコマンドを実行して、高可用性パッケージをインストールします。

sudo zypper in SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc 
sudo zypper in -t pattern ha_sles

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

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

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

susChkSrv が実装されるとすぐに、構成可能なアクションが実行されます。 このアクションは、hdbindexserver プロセスが同じノードで再起動するのを待たず、構成されたタイムアウト期間にフェールオーバーをトリガーします。 HANA スケールアウトでは、susChkSrv は HANA を個別に実行するすべてのクラスター ノードに対して機能します。 構成されたアクションによって HANA が強制終了されるか、影響を受ける VM がフェンス処理され、構成されたタイムアウト期間内にフェールオーバーがトリガーされます。

1. [1,2] 両方のシステム レプリケーション サイトで HANA を停止します。 <sid>adm として実行します。

   sapcontrol -nr 03 -function StopSystem
   

2. [1,2] HANA HA プロバイダー フックをインストールします。 フックは両方の HANA データベース サイトにインストールする必要があります。

   SAPHanaSR-angi

   1. [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_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 = kill
      
      [trace]
      ha_dr_sushanasr = info
      ha_dr_suschksrv = info
      

      SUSE は、 /usr/share/SAPHanaSR-angi ディレクトリに既定で HA フックを配信します。 標準の場所を使用すると、OS パッケージの更新によって Python フック コードが自動的に更新され、HANA は次回の再起動時に更新されたコードを使用します。 または、 /hana/shared/myHooksなどの独自のパスを指定して、使用するフック バージョンから OS 更新プログラムを切り離すこともできます。

   2. [AH] このクラスターでは、<sid>adm のための sudoers 構成がクラスター ノード上に必要です。 この例では、新しいファイルを作成することで実現します。 root として次のコマンドを実行します。 <sid> を小文字の SAP システム ID、<SID> を大文字の SAP システム ID、<siteA/B> を、選択した HANA サイト名に置き換えます。

      cat << EOF > /etc/sudoers.d/20-saphana
      # SAPHanaSR-angi requirements for HA/DR hook scripts
      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
      

      SAP HANA システム レプリケーション フックの実装の詳細については、HANA HA/DR プロバイダーの設定に関するページを参照してください。

   SAPHanaSR-ScaleOut

   両方の 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. [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 は、 /usr/share/SAPHanaSR-ScaleOut ディレクトリに既定で HA フックを配信します。 標準の場所を使用すると、OS パッケージの更新によって Python フック コードが自動的に更新され、HANA は次回の再起動時に更新されたコードを使用します。 または、 /hana/shared/myHooksなどの独自のパスを指定して、使用するフック バージョンから OS 更新プログラムを切り離すこともできます。

   2. [AH] このクラスターでは、<sid>adm のための sudoers 構成がクラスター ノード上に必要です。 この例では、新しいファイルを作成することで実現します。 root として次のコマンドを実行します。 <sid>を小文字の SAP システム ID で置き換えます。

      cat << EOF > /etc/sudoers.d/20-saphana
      # SAPHanaSR-ScaleOut requirements for HA/DR hook scripts
      <sid>adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_*
      <sid>adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_<sid>_gsh *
      <sid>adm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=<sid> *
      EOF
      

      SAP HANA システム レプリケーション フックの実装の詳細については、HANA HA/DR プロバイダーの設定に関するページを参照してください。

---

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

sapcontrol -nr 03 -function StartSystem 

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

SAPHanaSR-angi

cdtrace    
grep HADR.*load.*susHanaSR nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.30301.453.trc:[140145]{-1}[-1/-1] 2025-05-26 07:51:34.677221 i ha_dr_provider   HADRProviderManager.cpp(00083) : loading HA/DR Provider 'susHanaSR' from /usr/share/SAPHanaSR-angi
grep susHanaSR.*init nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.30301.453.trc:[140157]{-1}[-1/-1] 2025-05-26 07:51:34.724422 i ha_dr_susHanaSR  susHanaSR.py(00042) : susHanaSR.init() version 1.001.1

SAPHanaSR-ScaleOut

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

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

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. [1] HANA トポロジ リソースを作成します。 クラスターがメンテナンス モードであることを確認します。

SAPHanaSR-angi

sudo crm configure property maintenance-mode=true

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

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

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

SAPHanaSR-ScaleOut

sudo crm configure property maintenance-mode=true

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

sudo crm configure primitive rsc_SAPHanaTopology_<SID>_HDB<InstNum> ocf:suse:SAPHanaTopology \
  op monitor interval="10" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="<SID>" InstanceNumber="<InstNum>"
  
sudo crm configure clone cln_SAPHanaTopology_<SID>_HDB<InstNum> rsc_SAPHanaTopology_<SID>_HDB<InstNum> \
  meta clone-node-max="1" target-role="Started" interleave="true"

2. [1] 次に、HANA インスタンス リソースを作成します。

SAPHanaSR-angi

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

sudo crm configure primitive rsc_SAPHanaController_<SID>_HDB<InstNum> ocf:suse:SAPHanaController \
  op start interval="0" timeout="3600" \
  op stop interval="0" timeout="3600" \
  op promote interval="0" timeout="900" \
  op demote interval="0" timeout="320" \
  op monitor interval="60" role="Promoted" timeout="700" \
  op monitor interval="61" role="Unpromoted" timeout="700" \
  params SID="<SID>" InstanceNumber="<InstNum>" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false" \
  HANA_CALL_TIMEOUT="120"

sudo crm configure clone mst_SAPHanaController_<SID>_HDB<InstNum> rsc_SAPHanaController_<SID>_HDB<InstNum> \
  meta clone-node-max="1" interleave="true" promotable="true"

SAPHanaSR-ScaleOut

メモ

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

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

sudo crm configure primitive rsc_SAPHana_<SID>_HDB<InstNum> 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="<SID>" InstanceNumber="<InstNum>" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

sudo crm configure ms msl_SAPHana_<SID>_HDB<InstNum> rsc_SAPHana_<SID>_HDB<InstNum> \
  meta clone-node-max="1" master-max="1" interleave="true"

重要

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

3. [1] /hana/shared 用のファイル システム リソース エージェントを作成する

SAPHanaSR-angi

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

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

sudo crm configure primitive rsc_SAPHanaFilesystem_<SID>_HDB<InstNum> ocf:suse:SAPHanaFilesystem \
  op start interval="0" timeout="10" \
  op stop interval="0" timeout="20" \
  op monitor interval="120" timeout="120" \
  params SID="<SID>" InstanceNumber="<InstNum>" ON_FAIL_ACTION="fence"

sudo crm configure clone cln_SAPHanaFilesystem_<SID>_HDB<InstNum> rsc_SAPHanaFilesystem_<SID>_HDB<InstNum> \
  meta clone-node-max="1" interleave="true"

# Add a location constraint to not run filesystem check on majority maker VM
sudo crm configure location loc_SAPHanaFilesystem_not_on_majority_maker cln_SAPHanaFilesystem_<SID>_HDB<InstNum> -inf: hana-s-mm

SAPHanaSR-ScaleOut

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

• [1、2] NFS マウント ファイル システム /hana/shared にディレクトリを作成します。これは、ファイル システムの特別な監視リソースで使用されます。 このディレクトリは、両方のサイトに作成する必要があります。

  mkdir -p /hana/shared/HN1/check
  

• [AH] 特別なファイル システム監視リソースをマウントするために使用されるディレクトリを作成します。 このディレクトリは、すべての HANA クラスター ノード上に作成する必要があります。

  mkdir -p /hana/check
  

• [1] ファイル システムのクラスター リソースを作成します。

  # Replace <placeholders> with your instance number and HANA system ID
  
  crm configure primitive fs_<SID>_HDB<InstNum>_fscheck Filesystem \
    params device="/hana/shared/<SID>/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_<SID>_HDB<InstNum>_fscheck fs_<SID>_HDB<InstNum>_fscheck \
    meta clone-node-max=1 interleave=true
  # Add a location constraint to not run filesystem check on majority maker VM
  crm configure location loc_cln_fs_<SID>_HDB<InstNum>_fscheck_not_on_mm \
    cln_fs_<SID>_HDB<InstNum>_fscheck -inf: hana-s-mm    
  

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

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

4. [1] 仮想 IP と制約のクラスター リソースを続行します。

SAPHanaSR-angi

# Replace <placeholders> with your instance number and HANA system ID, and respective IP address and load balancer port  

sudo crm configure primitive rsc_ip_<SID>_HDB<InstNum> ocf:heartbeat:IPaddr2 \
  op start timeout=60s on-fail=fence \
  op monitor interval="10s" timeout="20s" \
  params ip="10.23.0.27"
  
sudo crm configure primitive rsc_nc_<SID>_HDB<InstNum> azure-lb port=62503 \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0
  
sudo crm configure group g_ip_<SID>_HDB<InstNum> rsc_ip_<SID>_HDB<InstNum> rsc_nc_<SID>_HDB<InstNum>

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

# Colocate the IP with primary HANA node
sudo crm configure colocation col_saphana_ip_<SID>_HDB<InstNum> 4000: g_ip_<SID>_HDB<InstNum>:Started \
  mst_SAPHanaController_<SID>_HDB<InstNum>:Promoted  
  
# Start HANA Topology before HANA  instance
sudo crm configure order ord_SAPHana_<SID>_HDB<InstNum> Optional: cln_SAPHanaTopology_<SID>_HDB<InstNum> \
  mst_SAPHanaController_<SID>_HDB<InstNum>
  
# HANA resources don't run on the majority maker node
sudo crm configure location loc_SAPHanaController_not_on_majority_maker mst_SAPHanaController_<SID>_HDB<InstNum> -inf: hana-s-mm
sudo crm configure location loc_SAPHanaTopology_not_on_majority_maker cln_SAPHanaTopology_<SID>_HDB<InstNum> -inf: hana-s-mm

SAPHanaSR-ScaleOut

# Replace <placeholders> with your instance number and HANA system ID, and respective IP address and load balancer port  

sudo crm configure primitive rsc_ip_<SID>_HDB<InstNum> ocf:heartbeat:IPaddr2 \
  op start timeout=60s on-fail=fence \
  op monitor interval="10s" timeout="20s" \
  params ip="10.23.0.27"
  
sudo crm configure primitive rsc_nc_<SID>_HDB<InstNum> azure-lb port=62503 \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0
  
sudo crm configure group g_ip_<SID>_HDB<InstNum> rsc_ip_<SID>_HDB<InstNum> rsc_nc_<SID>_HDB<InstNum>

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

# Colocate the IP with primary HANA node
sudo crm configure colocation col_saphana_ip_<SID>_HDB<InstNum> 4000: g_ip_<SID>_HDB<InstNum>:Started \
  msl_SAPHana_<SID>_HDB<InstNum>:Master  
  
# Start HANA Topology before HANA  instance
sudo crm configure order ord_SAPHana_<SID>_HDB<InstNum> Optional: cln_SAPHanaTopology_<SID>_HDB<InstNum> \
  msl_SAPHana_<SID>_HDB<InstNum>
  
# HANA resources don't run on the majority maker node
sudo crm configure location loc_SAPHanaCon_not_on_majority_maker msl_SAPHana_<SID>_HDB<InstNum> -inf: hana-s-mm
sudo crm configure location loc_SAPHanaTop_not_on_majority_maker cln_SAPHanaTopology_<SID>_HDB<InstNum> -inf: hana-s-mm

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

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

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

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

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

7. [1] HANA HA フックとクラスターとの間の通信を確認します。SID の状態は SOK、両方のレプリケーション サイトの状態は P(rimary) または S(econdary) と表示されます。

SAPHanaSR-angi

sudo SAPHanaSR-showAttr
Global cib-update dcid prim       sec        sid topology
----------------------------------------------------------
global 0.165361.0 7    HANA_S2 HANA_S1    HN1 ScaleOut

Resource                        promotable
-------------------------------------------
msl_SAPHanaController_HN1_HDB03 true
cln_SAPHanaTopology_HN1_HDB03

Site        lpt        lss mns     opMode    srHook srMode srPoll srr
----------------------------------------------------------------------
HANA_S2  1748611494 4   hana-s2-db1 logreplay PRIM   sync   PRIM   P
HANA_S1  10         4   hana-s1-db1 logreplay SOK    sync   SFAIL  S

Host     clone_state roles                        score  site       srah version     vhost
----------------------------------------------------------------------------------------------
hana-s1-db1  DEMOTED     master1:master:worker:master 100    HANA_S1 -    2.00.074.00 hana-s1-db1
hana-s1-db2  DEMOTED     slave:slave:worker:slave     -12200 HANA_S1 -    2.00.074.00 hana-s1-db2
hana-s1-db3  DEMOTED     slave:slave:worker:slave     -12200 HANA_S1 -    2.00.074.00 hana-s1-db3
hana-s2-db1  PROMOTED    master1:master:worker:master 150    HANA_S2 -    2.00.074.00 hana-s2-db1
hana-s2-db2  DEMOTED     slave:slave:worker:slave     -10000 HANA_S2 -    2.00.074.00 hana-s2-db2
hana-s2-db3  DEMOTED     slave:slave:worker:slave     -10000 HANA_S2 -    2.00.074.00 hana-s2-db3
hana-mm                                                                               hana-mm

SAPHanaSR-ScaleOut

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

メモ

上記の構成のタイムアウトはほんの一例であり、特定の HANA のセットアップに適合させる必要がある場合があります。 たとえば、SAP HANA データベースの起動により時間がかかる場合は、開始タイムアウトを長くする必要がある可能性があります。 SAPHanaSR-angi を使用すると、クラスター イベント中にすばやくアクションを実行するためのオプションがさらに追加されます。 SAPHanaController の ON_FAIL_ACTION パラメーター、省略可能なエージェント SAPHanaSR-alert-fencing、およびその他のオプションの詳細については、SUSE ドキュメントを参照してください。 実装は、環境内での追加の広範なクラスター テストに続けて行う必要があります。

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

メモ

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

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

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

   #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
   

2. SLES での Azure VM 上の SAP HANA の HA と SLES レプリケーションのスケールアウトでのパフォーマンス最適化シナリオに関する記事に記載されているテストを実行して、SAP HANA クラスター構成を十分に検証することをお勧めします。

3. ノードが NFS 共有 (/hana/shared) へのアクセスを失ったときの障害シナリオに備えてクラスター構成を検証します。

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

   予期される結果: プライマリ サイト VM の 1 つで 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
   

   クラスター リソースは、他の 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 の高可用性」を参照してください。