SUSE Enterprise Linux で Azure NetApp Files を使用した SAP HANA スケールアップの高可用性

この記事では、HANA ファイル システムが Azure NetApp Files を使用して NFS 経由でマウントされている場合に、SAP HANA システム レプリケーションをスケールアップ デプロイで構成する方法について説明します。 サンプルの構成およびインストール コマンドでは、インスタンス番号として 03、HANA システム ID として HN1 が使用されています。 SAP HANA レプリケーション は、1 つのプライマリ ノードと、少なくとも 1 つのセカンダリ ノードで構成されています。

このドキュメントの各手順にプレフィックスが付いている場合、その意味は次のとおりです。

• [A] :この手順はすべてのノードに適用されます。
• [1]: この手順は node1 にのみ適用されます。
• [2]: この手順は node2 にのみ適用されます。

はじめに、次の SAP Note およびガイドを確認してください

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

Note

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

概要

従来、スケールアップ環境では、SAP HANA のすべてのファイル システムはローカル ストレージからマウントされていました。 SUSE Enterprise Linux での SAP HANA システム レプリケーションの HA の設定は、SLES での SAP HANA システムレプリケーションの設定に関するガイドで公開されています。

Azure NetApp Files の NFS 共有でスケールアップ システムの SAP HANA HA を実現するには、クラスターに追加のリソース構成が必要になります。 この構成が必要なのは、1 つのノードが Azure NetApp Files 上の NFS 共有へのアクセスを失ったときに HANA リソースを回復できるようにするためです。

SAP HANA ファイル システムは、各ノードで Azure NetApp Files を使用して NFS 共有にマウントされます。 ファイル システム /hana/data、/hana/log、/hana/shared は各ノードに固有です。

node1 にマウント (hanadb1):

• /hana/data の 10.3.1.4:/hanadb1-data-mnt00001
• /hana/log の 10.3.1.4:/hanadb1-log-mnt00001
• /hana/shared の 10.3.1.4:/hanadb1-shared-mnt00001

node2 にマウント (hanadb2):

• /hana/data の 10.3.1.4:/hanadb2-data-mnt00001
• /hana/log の 10.3.1.4:/hanadb2-log-mnt00001
• /hana/shared の 10.3.1.4:/hanadb2-shared-mnt0001

Note

/hana/shared、/hana/data、/hana/log の各ファイル システムは 2 つのノード間で共有されません。 各クラスター ノードには、独自の独立したファイル システムがあります。

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

• フロントエンド構成の IP アドレス: 10.3.0.50 (hn1-db)
• プローブ ポート: 62503

Azure NetApp Files インフラストラクチャを設定する

Azure NetApp Files インフラストラクチャの設定を続行する前に、Azure NetApp Files のドキュメントの内容をよく理解しておいてください。

Azure NetApp Files はいくつかの Azure リージョンで利用できます。 選択した Azure リージョンで Azure NetApp Files が提供されているかどうかを確認してください。

Azure リージョン別の Azure NetApp Files の利用可能性については、Azure リージョン別の Azure NetApp Files の利用可能性に関するページを参照してください。

重要な考慮事項

SAP HANA スケールアップ システム用の Azure NetApp Files を作成するときは、「SAP HANA 用 Azure NetApp Files 上の NFS v4.1 ボリューム」に記載されている重要な考慮事項に注意してください。

Azure NetApp Files での HANA データベースのサイズ指定

Azure NetApp Files ボリュームのスループットは、「Azure NetApp Files のサービス レベル」に記載されているように、ボリューム サイズとサービス レベルの機能です。

Azure NetApp Files を使用して SAP HANA on Azure 用のインフラストラクチャを設計するときは、「SAP HANA 用 Azure NetApp Files 上の NFS v4.1 ボリューム」に記載されている推奨事項に注意してください。

この記事の構成には、単純な Azure NetApp Files ボリュームが含まれています。

重要

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

この記事で /hana/shared をマウントするすべてのコマンドは、NFSv4.1 の /hana/shared ボリュームに対して示されています。 /hana/shared ボリュームを NFSv3 ボリュームとしてデプロイした場合は、必ず /hana/shared のマウント コマンドを NFSv3 用に調整してください。

Azure NetApp Files リソースのデプロイ

以下の手順では、ご使用の Azure 仮想ネットワークが既にデプロイされていることを前提としています。 Azure NetApp Files のリソースと、そのリソースがマウントされる VM は、同じ Azure 仮想ネットワーク内またはピアリングされた Azure 仮想ネットワーク内にデプロイする必要があります。

1. 「NetApp アカウントを作成する」の手順に従って、選択した Azure リージョンに NetApp アカウントを作成します。

2. Azure NetApp Files の容量プールの設定に関するページの手順に従って、Azure NetApp Files の容量プールを設定します。

   この記事で示されている HANA アーキテクチャでは、Ultra サービス レベルで 1 つの Azure NetApp Files 容量プールを使用しています。 Azure 上の HANA ワークロードの場合、Azure NetApp Files の Ultra または Premium サービス レベルを使用することをお勧めします。

3. 「サブネットを Azure NetApp Files に委任する」の手順に従って、サブネットを Azure NetApp Files に委任します。

4. 「Azure NetApp Files の NFS ボリュームを作成する」の手順に従って、Azure NetApp Files のボリュームをデプロイします。

   ボリュームをデプロイするときは、NFSv4.1 バージョンを必ず選択してください。 指定された Azure NetApp Files のサブネット内にボリュームをデプロイします。 Azure NetApp Files の IP アドレスは、自動的に割り当てられます。

   Azure NetApp Files のリソースと Azure VM は、同じ Azure 仮想ネットワーク内またはピアリングされた Azure 仮想ネットワーク内に存在する必要があります。 たとえば、hanadb1-data-mnt00001、hanadb1-log-mnt00001 などはボリューム名で、nfs://10.3.1.4/hanadb1-data-mnt00001、nfs://10.3.1.4/hanadb1-log-mnt00001 などは Azure NetApp Files ボリュームのファイル パスです。

   hanadb1:

   • ボリューム hanadb1-data-mnt00001 (nfs://10.3.1.4:/hanadb1-data-mnt00001)
   • ボリューム hanadb1-log-mnt00001 (nfs://10.3.1.4:/hanadb1-log-mnt00001)
   • ボリューム hanadb1-shared-mnt00001 (nfs://10.3.1.4:/hanadb1-shared-mnt00001)

   hanadb2:

   • ボリューム hanadb2-data-mnt00001 (nfs://10.3.1.4:/hanadb2-data-mnt00001)
   • ボリューム hanadb2-log-mnt00001 (nfs://10.3.1.4:/hanadb2-log-mnt00001)
   • ボリューム hanadb2-shared-mnt00001 (nfs://10.3.1.4:/hanadb2-shared-mnt00001)

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

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

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

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

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

重要

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

Azure Load Balancer を構成する

VM 構成中に、ネットワーク セクションでロード バランサーを作成するか、既存のものを選択するかを選択できます。 次の手順に従って、HANA データベースの HA セットアップ用の Standard ロード バランサーを設定します。

Azure Portal

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

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

Note

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

Azure CLI

# Create the load balancer resource with frontend IP. Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address.
az network lb create -g MyResourceGroup -n MyLB --sku Standard --vnet-name MyVMsVirtualNetwork --subnet MyVMsSubnet --backend-pool-name MyBackendPool --frontend-ip-name MyDBFrontendIpName

# Create the health probe
az network lb probe create -g MyResourceGroup --lb-name MyLB -n MyDBHealthProbe --protocol tcp --port MyDBHealthProbePort --interval 5 --probe-threshold 2
 
# Create load balancing rule
az network lb rule create -g MyResourceGroup --lb-name MyLB -n MyDBRuleName --protocol All --frontend-ip-name MyDBFrontendIpName --frontend-port 0 --backend-pool-name MyBackendPool --backend-port 0 --probe-name MyDBHealthProbe --idle-timeout-in-minutes 30 --enable-floating-ip 

# Add database VMs in backend pool
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm1IpConfigName --nic-name DBVm1NicName -g MyResourceGroup --lb-name MyLB
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm2IpConfigName --nic-name DBVm2NicName -g MyResourceGroup --lb-name MyLB

展開して完全な CLI コードを表示する

# Define variables for Resource Group, and Database VMs.

rg_name="resourcegroup-name"
vm1_name="db1-name"
vm2_name="db2-name"

# Define variables for the load balancer that will be utilized in the creation of the load balancer resource.

lb_name="sap-db-sid-ilb"
bkp_name="db-backendpool"
db_fip_name="db-frontendip"

db_hp_name="db-healthprobe"
db_hp_port="625<instance-no>"

db_rule_name="db-lb-rule"
 
# Command to get VMs network information like primary NIC name, primary IP configuration name, virtual network name, and subnet name. 
 
vm1_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm1_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm1_nic_name=$(basename $vm1_primary_nic)
vm1_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm1_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vm2_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm2_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm2_nic_name=$(basename $vm2_primary_nic)
vm2_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm2_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vnet_subnet_id=$(az network nic show -g $rg_name -n $vm1_nic_name --query ipConfigurations[0].subnet.id -o tsv)
vnet_name=$(basename $(dirname $(dirname $vnet_subnet_id)))
subnet_name=$(basename $vnet_subnet_id)
 
# Create the load balancer resource with frontend IP.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address. 
  
az network lb create -g $rg_name -n $lb_name --sku Standard --vnet-name $vnet_name --subnet $subnet_name --backend-pool-name $bkp_name --frontend-ip-name $db_fip_name
 
# Create the health probe
 
az network lb probe create -g $rg_name --lb-name $lb_name -n $db_hp_name --protocol tcp --port $db_hp_port --interval 5 --probe-threshold 2
 
# Create load balancing rule
  
az network lb rule create -g $rg_name --lb-name $lb_name -n  $db_rule_name --protocol All --frontend-ip-name $db_fip_name --frontend-port 0 --backend-pool-name $bkp_name --backend-port 0 --probe-name $db_hp_name --idle-timeout-in-minutes 30 --enable-floating-ip 
 
# Add database VMs in backend pool
 
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm1_ipconfig --nic-name $vm1_nic_name -g $rg_name --lb-name $lb_name
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm2_ipconfig --nic-name $vm2_nic_name -g $rg_name --lb-name $lb_name

# [OPTIONAL] Change the assignment of frontend IP address from dynamic to static
dbfip=$(az network lb frontend-ip show --lb-name $lb_name -g $rg_name -n $db_fip_name --query "{privateIPAddress:privateIPAddress}" -o tsv)
az network lb frontend-ip update --lb-name $lb_name -g $rg_name -n $db_fip_name --private-ip-address $dbfip

PowerShell

# Create frontend IP configurations
$db_fip = New-AzLoadBalancerFrontendIpConfig -Name MyDBFrontendIpName -SubnetId MyDBSubnetName

# Create backend pool
$bePool = New-AzLoadBalancerBackendAddressPoolConfig -Name MyBackendPool

# Create health probe
$db_healthprobe = New-AzLoadBalancerProbeConfig -Name MyDBHealthProbe -Protocol 'tcp' -Port MyDBHealthProbePort -IntervalInSeconds 5 -ProbeThreshold 2 -ProbeCount 1

# Create load balancing rule
$db_rule = New-AzLoadBalancerRuleConfig -Name MyDBRuleName -Probe $db_healthprobe -Protocol 'All' -IdleTimeoutInMinutes 30 -FrontendIpConfiguration $db_fip -BackendAddressPool $bePool -EnableFloatingIP

# Create the load balancer resource
$lb = New-AzLoadBalancer -ResourceGroupName MyResourceGroup -Name MyLB -Location MyRegion -Sku 'Standard' -FrontendIpConfiguration $db_fip -BackendAddressPool $bePool -LoadBalancingRule $db_rule -Probe $db_healthprobe

展開して完全な PowerShell コードを表示する

# Define variables for Resource Group, and Database VMs.

$rg_name = 'resourcegroup-name'
$vm1_name = 'db1-name'
$vm2_name = 'db2-name'

# Define variables for the load balancer that will be utilized in the creation of the load balancer resource.

$lb_name = 'sap-db-sid-ilb'
$bkp_name = 'db-backendpool'
$db_fip_name = 'db-frontendip'
 
$db_hp_name = 'db-healthprobe'
$db_hp_port = '625<instance-no>'
 
$db_rule_name = 'db-lb-rule'
 
# Command to get VMs network information like primary NIC name, primary IP configuration name, virtual network name, and subnet name.
 
$vm1 = Get-AzVM -ResourceGroupName $rg_name -Name $vm1_name
$vm1_primarynic = $vm1.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm1_nic_name = $vm1_primarynic.Id.Split('/')[-1]
 
$vm1_nic_info = Get-AzNetworkInterface -Name $vm1_nic_name -ResourceGroupName $rg_name
$vm1_primaryip = $vm1_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm1_ipconfig_name = ($vm1_primaryip).Name
 
$vm2 = Get-AzVM -ResourceGroupName $rg_name -Name $vm2_name
$vm2_primarynic = $vm2.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm2_nic_name = $vm2_primarynic.Id.Split('/')[-1]
 
$vm2_nic_info = Get-AzNetworkInterface -Name $vm2_nic_name -ResourceGroupName $rg_name
$vm2_primaryip = $vm2_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm2_ipconfig_name = ($vm2_primaryip).Name
 
$vnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-3]
$subnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-1]
$location = $vm1.Location
 
# Create frontend IP resource.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter -PrivateIpAddress
 
$db_lb_fip = @{
    Name = $db_fip_name
    SubnetId = $vm1_primaryip.Subnet.Id
}
$db_fip = New-AzLoadBalancerFrontendIpConfig @db_lb_fip

# Create backend pool
 
$bepool = New-AzLoadBalancerBackendAddressPoolConfig -Name $bkp_name

# Create the health probe
 
$db_probe = @{
    Name = $db_hp_name
    Protocol = 'tcp'
    Port = $db_hp_port
    IntervalInSeconds = '5'
    ProbeThreshold = '2'
    ProbeCount = '1'
}
$db_healthprobe = New-AzLoadBalancerProbeConfig @db_probe
    
# Create load balancing rule
 
$db_lbrule = @{
    Name = $db_rule_name
    Probe = $db_healthprobe
    Protocol = 'All'
    IdleTimeoutInMinutes = '30'
    FrontendIpConfiguration = $db_fip
    BackendAddressPool = $bePool 
} 
$db_rule = New-AzLoadBalancerRuleConfig @db_lbrule -EnableFloatingIP 
 
# Create the load balancer resource
 
$loadbalancer = @{
    ResourceGroupName = $rg_name
    Name = $lb_name
    Location = $location
    Sku = 'Standard'
    FrontendIpConfiguration = $db_fip
    BackendAddressPool = $bePool
    LoadBalancingRule = $db_rule
    Probe = $db_healthprobe
} 
$lb = New-AzLoadBalancer @loadbalancer

# Add DB VMs in backend pool
 
$vm1_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm2_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm1_nic_info | Set-AzNetworkInterface
$vm2_nic_info | Set-AzNetworkInterface

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

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

重要

• 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 – Do I Need to Update? (saptune 3.1.1 – 更新する必要があるか)」を参照してください。

Azure NetApp Files ボリュームのマウント

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

   sudo mkdir -p /hana/data/HN1/mnt00001
   sudo mkdir -p /hana/log/HN1/mnt00001
   sudo mkdir -p /hana/shared/HN1
   

2. [A] NFS ドメイン設定を確認します。 ドメインが既定の Azure NetApp Files ドメイン (つまり、defaultv4iddomain.com) として構成され、マッピングが nobody に設定されていることを確認します。

   sudo cat /etc/idmapd.conf
   

   出力例:

   [General]
   Domain = defaultv4iddomain.com
   [Mapping]
   Nobody-User = nobody
   Nobody-Group = nobody
   

   重要

   Azure NetApp Files の既定のドメイン構成 (defaultv4iddomain.com) と一致するように、VM 上の /etc/idmapd.conf に NFS ドメインを設定していることを確認します。 NFS クライアント (つまり、VM) と NFS サーバー (つまり、Azure NetApp Files 構成) のドメイン構成が一致しない場合、VM にマウントされている Azure NetApp Files ボリューム上のファイルに対するアクセス許可は nobody と表示されます。

3. [A] 両方のノードで /etc/fstab を編集して、各ノードに関連するボリュームを永続的にマウントします。 次の例は、ボリュームを永続的にマウントする方法を示しています。

   sudo vi /etc/fstab
   

   両方のノードで /etc/fstab に次のエントリを追加します。

   hanadb1 の例:

   10.3.1.4:/hanadb1-data-mnt00001 /hana/data/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
   10.3.1.4:/hanadb1-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
   10.3.1.4:/hanadb1-shared-mnt00001 /hana/shared/HN1  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
   

   hanadb2 の例:

   10.3.1.4:/hanadb2-data-mnt00001 /hana/data/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
   10.3.1.4:/hanadb2-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
   10.3.1.4:/hanadb2-shared-mnt00001 /hana/shared/HN1  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
   

   すべてのボリュームをマウントします。

   sudo mount -a
   

   より高いスループットを必要とするワークロードの場合は、「SAP HANA 用 Azure NetApp Files 上の NFS v4.1 ボリューム」で説明されているように nconnect マウント オプションの使用を検討してください。 nconnect が、ご使用の Linux リリースの Azure NetApp Files でサポートされているかどうかを確認します。

4. [A] すべての HANA ボリュームが NFS プロトコル バージョン NFSv4 でマウントされていることを確認します。

   sudo nfsstat -m
   

   フラグ vers が 4.1 に設定されていることを確認します。

   hanadb1 の例:

   /hana/log/HN1/mnt00001 from 10.3.1.4:/hanadb1-log-mnt00001
   Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.3.0.4,local_lock=none,addr=10.3.1.4
   /hana/data/HN1/mnt00001 from 10.3.1.4:/hanadb1-data-mnt00001
   Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.3.0.4,local_lock=none,addr=10.3.1.4
   /hana/shared/HN1 from 10.3.1.4:/hanadb1-shared-mnt00001
   Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.3.0.4,local_lock=none,addr=10.3.1.4
   

5. [A]nfs4_disable_idmapping を確認します。 これは、Y に設定されている必要があります。nfs4_disable_idmapping が配置されるディレクトリ構造を作成するには、mount コマンドを実行します。 アクセスはカーネルとドライバー用に予約されるため、/sys/modules の下に手動でディレクトリを作成できなくなります。

   #Check nfs4_disable_idmapping
   sudo cat /sys/module/nfs/parameters/nfs4_disable_idmapping
   
   #If you need to set nfs4_disable_idmapping to Y
   sudo echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
   
   #Make the configuration permanent
   sudo echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
   

SAP HANA のインストール

1. [A] すべてのホストにホスト名解決を設定します。

   DNS サーバーを使用するか、すべてのノードの /etc/hosts ファイルを変更することができます。 この例では、/etc/hosts ファイルを使用する方法を示します。 以下のコマンドでは IP アドレスとホスト名を置き換えてください。

   sudo vi /etc/hosts
   

   /etc/hosts ファイルに次の行を挿入します。 お使いの環境に合わせて IP アドレスとホスト名を変更します。

   10.3.0.4   hanadb1
   10.3.0.5   hanadb2
   

2. [A] SAP ノート 3024346 - Linux Kernel Settings for NetApp NFS の説明に従って、NFS を使用して Azure NetApp 上で SAP HANA を実行する目的で OS を準備します。 NetApp 構成設定用の構成ファイル /etc/sysctl.d/91-NetApp-HANA.conf を作成します。

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

   構成ファイルに次のエントリを追加します。

   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
   

3. [A] より多くの最適化設定を含む構成ファイル /etc/sysctl.d/ms-az.conf を作成します。

   sudo vi /etc/sysctl.d/ms-az.conf
   

   構成ファイルに次のエントリを追加します。

   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 Host Agent がポート範囲を管理できるように、sysctl 構成ファイルでは明示的に net.ipv4.ip_local_port_range と net.ipv4.ip_local_reserved_ports を設定しないでください。 詳細については、SAP ノート 2382421 を参照してください。

4. [A] SAP ノート 3024346 - Linux Kernel Settings for NetApp NFS で推奨されているように、sunrpc 設定を調整します。

   sudo vi /etc/modprobe.d/sunrpc.conf
   

   次の行を挿入します。

   options sunrpc tcp_max_slot_table_entries=128
   

5. [A] HANA 用に SLES を構成します。

   SLES のバージョンに基づいて、次の SAP Note の説明に従って SLES を構成します。

   • 2684254 推奨される SLES 15/SLES for SAP Applications 15 向け OS 設定
   • 2205917 推奨される SLES 12/SLES for SAP Applications 12 向け OS 設定
   • 2455582 Linux: GCC 6.x でコンパイルされた SAP アプリケーションの実行
   • 2593824 Linux: GCC 7.x でコンパイルされた SAP アプリケーションの実行
   • 2886607 Linux: GCC 9.x でコンパイルされた SAP アプリケーションの実行

6. [A] SAP HANA をインストールします。

   HANA 2.0 SPS 01 以降では、マルチテナント データベース コンテナー (MDC) が既定のオプションです。 HANA システムをインストールすると、SYSTEMDB と、同じ SID を持つテナントが一緒に作成されます。 既定のテナントが必要ない場合もあります。 インストール時に初期テナントを作成しない場合は、SAP Note 2629711 の指示に従ってください。

   1. HANA のインストール ソフトウェア ディレクトリから hdblcm プログラムを起動します。

      ./hdblcm
      

   2. プロンプトで次の値を入力します。

      • [Choose installation] (インストールの選択): 「1」と入力します (インストール)。
      • [Select additional components for installation] (追加でインストールするコンポーネントの選択): 「1」と入力します。
      • [Enter Installation Path] (インストール パスの入力) [/hana/shared]: Enter キーを押して既定値をそのまま使用します。
      • [Enter Local Host Name] (ローカル ホスト名の入力) [..]: Enter キーを押して既定値をそのまま使用します。
      • [Do you want to add additional hosts to the system?] (システムに別のホストを追加しますか?) (y/n) [n]: [n] を選択します。
      • [Enter SAP HANA System ID] (SAP HANA システム ID の入力): 「HN1」と入力します。
      • [Enter Instance Number] (インスタンス番号の入力) [00]: 「03」と入力します。
      • [Select Database Mode / Enter Index] (データベース モードの選択/インデックスを入力) [1]: Enter キーを押して既定値をそのまま使用します。
      • [Select System Usage / Enter Index] (システム用途の選択/インデックスを入力) [4]: 「4」と入力します (カスタム)。
      • [Enter Location of Data Volumes] (データ ボリュームの場所を入力) [/hana/data]: Enter キーを押して既定値をそのまま使用します。
      • [Enter Location of Log Volumes] (ログ ボリュームの場所を入力) [/hana/log]: Enter キーを押して既定値をそのまま使用します。
      • [Restrict maximum memory allocation?] (メモリの最大割り当てを制限しますか?) [n]: Enter キーを押して既定値をそのまま使用します。
      • [Enter Certificate Host Name For Host '...'] (ホスト '...' の証明書ホスト名を入力) [...]: Enter キーを押して既定値をそのまま使用します。
      • [Enter SAP Host Agent User (sapadm) Password] (SAP ホスト エージェント ユーザー (sapadm) のパスワードの入力): ホスト エージェントのユーザー パスワードを入力します。
      • [Confirm SAP Host Agent User (sapadm) Password] (SAP ホスト エージェント ユーザー (sapadm) のパスワードの確認入力): 確認のためにホスト エージェントのユーザー パスワードをもう一度入力します。
      • [Enter System Administrator (hn1adm) Password] (システム管理者 (hn1adm) のパスワードの入力): システム管理者パスワードを入力します。
      • [Confirm System Administrator (hn1adm) Password] (システム管理者 (hn1adm) のパスワードの確認入力): 確認のためにシステム管理者パスワードをもう一度入力します。
      • [Enter System Administrator Home Directory] (システム管理者のホーム ディレクトリを入力) [/usr/sap/HN1/home]: Enter キーを押して既定値をそのまま使用します。
      • [Enter System Administrator Login Shell] (システム管理者のログイン シェルを入力) [/bin/sh]: Enter キーを押して既定値をそのまま使用します。
      • [Enter System Administrator User ID] (システム管理者のユーザー ID を入力) [1001]: Enter キーを押して既定値をそのまま使用します。
      • [Enter ID of User Group (sapsys)] (ユーザー グループ (sapsys) の ID を入力) [79]: Enter キーを押して既定値をそのまま使用します。
      • [Enter Database User (SYSTEM) Password] (データベース ユーザー (SYSTEM) のパスワードの入力): データベース ユーザーのパスワードを入力します。
      • [Confirm Database User (SYSTEM) Password] (データベース ユーザー (SYSTEM) のパスワードの確認入力): 確認のためにデータベース ユーザーのパスワードをもう一度入力します。
      • [Restart system after machine reboot?] (コンピューターの再起動後にシステムを再起動しますか?) [n]: Enter キーを押して既定値をそのまま使用します。
      • [Do you want to continue?] (続行しますか?) (y/n): 概要を確認します。 「y」と入力して続行します。

7. [A] SAP Host Agent をアップグレードします。

   SAP Software Center から最新の SAP Host Agent アーカイブをダウンロードし、次のコマンドを実行してエージェントをアップグレードします。 アーカイブのパスを置き換えて、ダウンロードしたファイルを示すようにします。

   sudo /usr/sap/hostctrl/exe/saphostexec -upgrade -archive <path to SAP Host Agent SAR>
   

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

SAP HANA システム レプリケーションに関する記事の手順に従って、SAP HANA システム レプリケーションを構成します。

クラスター構成

このセクションでは、Azure NetApp Files を使用して NFS 共有に SAP HANA をインストールしている場合に、クラスターをシームレスに運用するために必要な手順について説明します。

Pacemaker クラスターの作成

Azure での SUSE Enterprise Linux の Pacemaker の設定に関する記事の手順に従って、この HANA サーバーに対して基本的な Pacemaker クラスターを作成します。

HANA フック SAPHanaSR と susChkSrv を実装する

これは、クラスターとの統合を最適化し、クラスターのフェールオーバーが必要になった場合の検出を改善するための重要なステップです。 SAPHanaSR フックと susChkSrv Python フックの両方を構成することを強くお勧めします。 Python システム レプリケーション フック SAPHanaSR/SAPHanaSR-angi と susChkSrv の実装に関する記事の手順に従ってください。

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

このセクションでは、SAP HANA クラスター リソースの構成に必要な手順について説明します。

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

SAP HANA クラスター リソースの作成に関する記事の手順に従って、HANA サーバー用のクラスター リソースを作成します。 リソースが作成されたら、次のコマンドを使ってクラスターの状態を確認してください。

sudo crm_mon -r

出力例:

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

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

ファイル システム /hana/shared/SID は、HANA の操作と、HANA の状態を決定する Pacemaker 監視アクションの両方に必要です。 リソース エージェントを実装して、監視を行い障害が発生した場合に対処します。 このセクションには、SAPHanaSR 用と SAPHanaSR-angi 用の 2 つのオプションがあります。

SAPHanaSR

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

1. [A] 両方のノードでディレクトリ構造を作成します。

   sudo mkdir -p /hana/shared/HN1/check
   sudo mkdir -p /hana/shared/check
   

2. [1] クラスターを構成して監視用のディレクトリ構造を追加します。

   sudo crm configure primitive rsc_fs_check_HN1_HDB03 Filesystem params \
       device="/hana/shared/HN1/check/" \
       directory="/hana/shared/check/" fstype=nfs  \
       options="bind,defaults,rw,hard,rsize=262144,wsize=262144,proto=tcp,noatime,_netdev,nfsvers=4.1,lock,sec=sys" \
       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
   

3. [1] クラスター内の新しく構成されたボリュームをクローンして確認します。

   sudo crm configure clone cln_fs_check_HN1_HDB03 rsc_fs_check_HN1_HDB03 meta clone-node-max=1 interleave=true
   

   出力例:

   sudo crm status
   
   # Cluster Summary:
   # Stack: corosync
   # Current DC: hanadb1 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
   # Last updated: Tue Nov  2 17:57:39 2021
   # Last change:  Tue Nov  2 17:57:38 2021 by root via crm_attribute on hanadb1
   # 2 nodes configured
   # 11 resource instances configured
   
   # Node List:
   # Online: [ hanadb1 hanadb2 ]
   
   # Full List of Resources:
   # Clone Set: cln_azure-events [rsc_azure-events]:
   #  Started: [ hanadb1 hanadb2 ]
   # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
   #  rsc_SAPHanaTopology_HN1_HDB03     (ocf::suse:SAPHanaTopology):     Started hanadb1 (Monitoring)
   #  rsc_SAPHanaTopology_HN1_HDB03     (ocf::suse:SAPHanaTopology):     Started hanadb2 (Monitoring)
   # Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
   #  rsc_SAPHana_HN1_HDB03     (ocf::suse:SAPHana):     Master hanadb1 (Monitoring)
   #  Slaves: [ hanadb2 ]
   # Resource Group: g_ip_HN1_HDB03:
   #  rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb1
   #  rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb1
   # rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
   # Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
   #  Started: [ hanadb1 hanadb2 ]
   

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

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

SAPHanaSR-angi

SAPHanaSR-angi パッケージとリソース エージェントを使用する場合、新しいエージェント SAPHanaFilesystem を追加して、/hana/shared/SID への読み取りと書き込みアクセスを監視します。 ファイルシステム /hana/shared は、各ホストの /etc/fstab のエントリと共に既にマウントされています。 SAPHanaFilesystem と Pacemaker は HANA のファイルシステムをマウントせず、追加のマウントまたはサブディレクトリを事前に作成する必要はありません。

1. [1] SAPHanaFilesystem エージェントを構成する

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

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

重要

上記の構成のタイムアウトは、不要なフェンス アクションを回避するために、特定の HANA 設定に合わせて調整する必要がある場合があります。 タイムアウト値を小さすぎる値に設定しないでください。 ファイル システムのモニターは HANA システム レプリケーションには関連していない点に注意してください。 詳しくは、SUSE のドキュメントを参照してください。

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

ここでは、設定をテストする方法について説明します。

1. テストを開始する前に、Pacemaker に失敗したアクションがなく (crm status を使用)、予期しない場所の制約 (移行テストの残りなど) がないことを確認してください。 また、HANA システム レプリケーションが同期状態であることを確認してください (例: systemReplicationStatus)。

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

2. 次のコマンドを使って、HANA リソースの状態を確認します。

   SAPHanaSR-showAttr
   
   # You should see something like below
   # hanadb1:~ SAPHanaSR-showAttr
   # Global cib-time                 maintenance
   # --------------------------------------------
   # global Mon Nov  8 22:50:30 2021 false
   # Sites srHook
   # -------------
   # SITE1 PRIM
   # SITE2 SOK
   # Site2 SOK
   # Hosts   clone_state lpa_hn1_lpt node_state op_mode   remoteHost roles                            score site  srmode sync_state version                vhost
   # --------------------------------------------------------------------------------------------------------------------------------------------------------------
   # hanadb1 PROMOTED    1636411810  online     logreplay hanadb2    4:P:master1:master:worker:master 150   SITE1 sync   PRIM       2.00.058.00.1634122452 hanadb1
   # hanadb2 DEMOTED     30          online     logreplay hanadb1    4:S:master1:master:worker:master 100   SITE2 sync   SOK        2.00.058.00.1634122452 hanadb2
   

3. ノードがシャットダウンされる障害シナリオのクラスター構成を検証します。 次の例は、ノード 1 のシャットダウンを示しています。

   sudo crm status
   sudo crm resource move msl_SAPHana_HN1_HDB03 hanadb2 force
   sudo crm resource cleanup
   

   出力例:

   sudo crm status
   
   #Cluster Summary:
   # Stack: corosync
   # Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
   # Last updated: Mon Nov  8 23:25:36 2021
   # Last change:  Mon Nov  8 23:25:19 2021 by root via crm_attribute on hanadb2
   # 2 nodes configured
   # 11 resource instances configured
   
   # Node List:
   # Online: [ hanadb1 hanadb2 ]
   # Full List of Resources:
   # Clone Set: cln_azure-events [rsc_azure-events]:
   #  Started: [ hanadb1 hanadb2 ]
   # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
   #  Started: [ hanadb1 hanadb2 ]
   # Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
   #  Masters: [ hanadb2 ]
   #  Stopped: [ hanadb1 ]
   # Resource Group: g_ip_HN1_HDB03:
   #  rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb2
   #  rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb2
   # rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
   # Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
   #  Started: [ hanadb1 hanadb2 ]
   

   ノード 1 で HANA を停止します。

   sudo su - hn1adm
   sapcontrol -nr 03 -function StopWait 600 10
   

   ノード 1 をセカンダリ ノードとして登録し、状態をチェックします。

   hdbnsutil -sr_register --remoteHost=hanadb2 --remoteInstance=03 --replicationMode=sync --name=SITE1 --operationMode=logreplay
   

   出力例:

   #adding site ...
   #nameserver hanadb1:30301 not responding.
   #collecting information ...
   #updating local ini files ...
   #done.
   

   sudo crm status
   

   sudo SAPHanaSR-showAttr
   

4. ノードが NFS 共有 (/hana/shared) へのアクセスを失う障害シナリオのクラスター構成を検証します。

   SAP HANA リソース エージェントは、フェールオーバー中の操作の実行を /hana/shared に格納されているバイナリに依存しています。 提示されているシナリオでは、ファイル システム /hana/shared は NFS 経由でマウントされます。

   サーバーの 1 つが NFS 共有へのアクセスを失う失敗をシミュレートすることは困難です。 テストとして、ファイル システムを読み取り専用として再マウントできます。 この方法では、アクティブ ノードで /hana/shared へのアクセスが失われた場合にクラスターがフェールオーバーできることを検証できます。

   予想される結果: /hana/shared を読み取り専用ファイル システムにすると、ファイル システムに対して読み取りと書き込み操作を実行する、リソース hana_shared1 の OCF_CHECK_LEVEL 属性は失敗します。 失敗する理由は、ファイル システムに何も書き込むことができず、HANA リソースのフェールオーバーを実行するためです。 HANA ノードが NFS 共有へのアクセスを失った場合も、同じ結果が予想されます。

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

   sudo crm  status
   
   #Cluster Summary:
    # Stack: corosync
    # Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
    # Last updated: Mon Nov  8 23:01:27 2021
    # Last change:  Mon Nov  8 23:00:46 2021 by root via crm_attribute on hanadb1
    # 2 nodes configured
    # 11 resource instances configured
   
    #Node List:
    # Online: [ hanadb1 hanadb2 ]
   
    #Full List of Resources:
    # Clone Set: cln_azure-events [rsc_azure-events]:
      # Started: [ hanadb1 hanadb2 ]
    # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
      # Started: [ hanadb1 hanadb2 ]
    # Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
      # Masters: [ hanadb1 ]
      # Slaves: [ hanadb2 ]
    # Resource Group: g_ip_HN1_HDB03:
      # rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb1
      # rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb1
    # rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
    # Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
      # Started: [ hanadb1 hanadb2 ]
   

   次のコマンドを使用して、アクティブなクラスター ノードで /hana/shared を読み取り専用モードにできます。

   sudo mount -o ro 10.3.1.4:/hanadb1-shared-mnt00001 /hana/sharedb
   

   サーバー hanadb1 は、設定されているアクションに基づいて、再起動するか電源がオフになります。 サーバー hanadb1 がダウンすると、HANA リソースは hanadb2 に移動します。 クラスターの状態は hanadb2 から確認できます。

   sudo crm status
   
   #Cluster Summary:
    # Stack: corosync
    # Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
    # Last updated: Wed Nov 10 22:00:27 2021
    # Last change:  Wed Nov 10 21:59:47 2021 by root via crm_attribute on hanadb2
    # 2 nodes configured
    # 11 resource instances configured
   
    #Node List:
    # Online: [ hanadb1 hanadb2 ]
   
    #Full List of Resources:
    # Clone Set: cln_azure-events [rsc_azure-events]:
      # Started: [ hanadb1 hanadb2 ]
    # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
      # Started: [ hanadb1 hanadb2 ]
    # Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
      # Masters: [ hanadb2 ]
      # Stopped: [ hanadb1 ]
    # Resource Group: g_ip_HN1_HDB03:
         # rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb2
      # rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb2
    # rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
    # Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
      # Started: [ hanadb1 hanadb2 ]
   

   SAP HANA システム レプリケーションに関する記事で説明されているテストを実行して、SAP HANA クラスター構成を十分にテストすることをお勧めします。

次のステップ

• SAP のための Azure Virtual Machines の計画と実装
• SAP のための Azure Virtual Machines のデプロイ
• SAP のための Azure Virtual Machines DBMS のデプロイ
• SAP HANA 用 Azure NetApp Files 上の NFS v4.1 ボリューム