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 のノートとホワイトペーパーを参照してください。

概要

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

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

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

重要

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

警告

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

SAP HANA scale-out with HSR and Pacemaker cluster on SLES

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

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

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

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

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

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

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

  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 DB HANA ノードとして展開される VM は、SAP HANA ハードウェア ディレクトリで公開されているように、SAP for HANA によって認定されている必要があります。 HANA DB ノードを展開するときは、高速ネットワークが選択されていることを確認してください。

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

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

    各 VM のプライマリ ネットワーク インターフェイスを client 仮想ネットワーク サブネット内に展開します。
    Azure portal 経由で VM が展開されると、ネットワーク インターフェイス名が自動的に生成されます。 ここではわかりやすくするために、自動的に生成された client Azure 仮想ネットワーク サブネットに接続されたプライマリ ネットワーク インターフェイスを、hana-s1-db1-client、hana-s1-db2-client、hana-s1-db3-client などのように呼びます。

    重要

    • 選択した OS が、使用している特定の VM の種類の SAP HANA に対して認定されていることを確認してください。 SAP HANA 認定 VM の種類と、その種類に対応する OS リリースの一覧については、SAP HANA 認定 IaaS プラットフォームに関するページをご覧ください。 一覧表示されている VM の種類の詳細をクリックすると、その種類に対して SAP HANA でサポートされている OS のリリースの完全な一覧が表示されます。
    • Azure Files の NFS に /hana/shared をデプロイする場合は、SLES 15 SP2 以降にデプロイすることをお勧めします。

  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

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

Azure Load Balancer の構成

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

Note

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

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 コマンドを使用してください。

重要

フローティング IP は、負荷分散シナリオの NIC セカンダリ IP 構成ではサポートされていません。 詳細については、Azure Load Balancer の制限事項に関する記事を参照してください。 VM に追加の IP アドレスが必要な場合は、2 つ目の NIC をデプロイします。

Note

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

重要

  • Azure Load Balancer の背後に配置された Azure VM では TCP タイムスタンプを有効にしないでください。 TCP タイムスタンプを有効にすると正常性プローブが失敗することになります。 パラメータ net.ipv4.tcp_timestamps を 0 にセットします。 詳しくは、Load Balancer の正常性プローブに関する記事と、SAP Note 2382421 を参照してください。
  • 手動で設定した net.ipv4.tcp_timestamps の値 0 が、saptune によって 1 に戻されないようにするには、saptune のバージョンを 3.1.1 以降に更新します。 詳細については、「saptune 3.1.1 – 更新する必要がありますか?」を参照してください。

NFS の展開

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

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

ヒント

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

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

/hana/shared ファイル システムの ANF ボリュームをデプロイします。 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. [A] SUSE では SAP HANA 用の特別なリソース エージェントが提供され、既定では SAP HANA スケールアップ用のエージェントがインストールされます。 スケールアップ用のパッケージがインストールされている場合はアンインストールし、SAP HANA スケールアウト シナリオ用のパッケージをインストールします。この手順は、マジョリティ メーカーを含むすべてのクラスター VM で実行する必要があります。

    注意

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

    # Uninstall scale-up packages and patterns
sudo zypper remove patterns-sap-hana
sudo zypper remove SAPHanaSR SAPHanaSR-doc yast2-sap-ha

# Install the scale-out packages and patterns
sudo zypper in SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc 
sudo zypper in -t pattern ha_sles

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

    sudo cat /etc/idmapd.conf
# Example
[General]
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody

  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] 論理ボリュームを作成します。

    -i スイッチを指定せずに lvcreate を使用すると、線形のボリュームが作成されます。 I/O パフォーマンスを向上させるためにストライプ ボリュームを作成し、SAP HANA VM のストーレジ構成に関する記事に記載されている値にストライプ サイズを合わせることをお勧めします。 -i 引数は、基になる物理ボリュームの数、-I 引数はストライプ サイズにする必要があります。 このドキュメントでは、2 つの物理ボリュームが使用されるため、-i スイッチ引数は 2 に設定されます。 データ ボリュームのストライプ サイズは 256 KiB です。 ログ ボリューム用に物理ボリュームが 1 つ使用されるため、ログ ボリューム コマンドに対して -i および -I スイッチは明示的には使用されません。

    重要

    データまたはログ ボリュームごとに複数の物理ボリュームを使用する場合は、-i スイッチを使用して基になる物理ボリュームの数を設定します。 ストライプ ボリュームを作成するときにストライプ サイズを指定するには、-I スイッチを使用します。
    ストライプ サイズやディスク数など、推奨されるストレージ構成については、SAP HANA VM ストレージ構成に関する記事を参照してください。

    sudo lvcreate -i 2 -I 256 -l 100%FREE -n hana_data vg_hana_data_HN1
sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_HN1
sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data
sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log

  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 が有効になっていることを確認します。

インストール

この例では、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 のインストールを示します。

    a. HANA のインストール ソフトウェア ディレクトリから、hdblcm プログラムを root で起動します。 internal_network パラメーターを使用して、内部 HANA のノード間通信に使用されるサブネットのアドレス空間を渡します。

    ./hdblcm --internal_network=10.23.1.128/26

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

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

  2. [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 2080991 の説明に従って、共有されていない環境でのインストールのための 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 での手順を示します。

    a. 常駐の hdblcm プログラムを root で開始します。

     cd /hana/shared/HN1/hdblcm
 ./hdblcm

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

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

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

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

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

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

    hdbnsutil -sr_enable --name=HANA_S1

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

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

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

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

  1. [1] HANA クラスター リソースの作成準備として、pacemaker をメンテナンス モードにします。

    crm configure property maintenance-mode=true

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

    mkdir -p /hana/shared/HN1/check

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

    mkdir -p /hana/check

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

    crm configure primitive fs_HN1_HDB03_fscheck Filesystem \
  params device="/hana/shared/HN1/check" \
  directory="/hana/check" fstype=nfs4 \
  options="bind,defaults,rw,hard,proto=tcp,noatime,nfsvers=4.1,lock" \
  op monitor interval=120 timeout=120 on-fail=fence \
  op_params OCF_CHECK_LEVEL=20 \
  op start interval=0 timeout=120 op stop interval=0 timeout=120

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

crm configure location loc_cln_fs_HN1_HDB03_fscheck_not_on_mm \
  cln_fs_HN1_HDB03_fscheck -inf: hana-s-mm

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

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

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

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

Note

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

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

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

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

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

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

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

    sapcontrol -nr 03 -function StopSystem

  2. [1,2] 各クラスター サイトで global.ini を調整します。 susChkSrv フックの前提条件が満たされていない場合は、ブロック [ha_dr_provider_suschksrv] を一切構成しないでください。
    susChkSrv の動作は、パラメーター action_on_lost を使用して調整できます。 有効な値は [ ignore | stop | kill | fence ] です。

    # add to global.ini on both sites. Do not copy global.ini between sites.
[ha_dr_provider_saphanasrmultitarget]
provider = SAPHanaSrMultiTarget
path = /usr/share/SAPHanaSR-ScaleOut
execution_order = 1

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

[trace]
ha_dr_saphanasrmultitarget = info

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

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

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

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

    sapcontrol -nr 03 -function StartSystem

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

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

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

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

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

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

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

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

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

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

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

      Note

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

      sudo crm configure primitive rsc_SAPHana_HN1_HDB03 ocf:suse:SAPHanaController \
  op start interval="0" timeout="3600" \
  op stop interval="0" timeout="3600" \
  op promote interval="0" timeout="3600" \
  op monitor interval="60" role="Master" timeout="700" \
  op monitor interval="61" role="Slave" timeout="700" \
  params SID="HN1" InstanceNumber="03" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

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

      重要

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

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

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

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

sudo crm configure group g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 rsc_nc_HN1_HDB03

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

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

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

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

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

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

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

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

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

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

    sudo /usr/sbin/SAPHanaSR-showAttr
# Expected result
# Global cib-time                 maintenance prim  sec sync_state upd
# ---------------------------------------------------------------------
# HN1    Fri Jan 27 10:38:46 2023 false       HANA_S1 -   SOK        ok
# 
# Sites     lpt        lss mns        srHook srr
# -----------------------------------------------
# HANA_S1     1674815869 4   hana-s1-db1 PRIM   P
# HANA_S2     30         4   hana-s2-db1 SWAIT  S

    Note

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

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

Note

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

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

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

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

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

    # Verify HANA HSR is in sync
sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
#| Database | Host         | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary    | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
#|          |              |       |              |           |         |           | Host         | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
#| -------- | ------------ | ----- | ------------ | --------- | ------- | --------- | ------------ | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
#| SYSTEMDB | hana-s1-db1  | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1  |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db1  | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1  |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db1  | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db3  | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db3  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db2  | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db2  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#
#status system replication site "1": ACTIVE
#overall system replication status: ACTIVE
#
#Local System Replication State
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
#mode: PRIMARY
#site id: 1
#site name: HANA_S1

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

    クラスター リソースの状態を確認するには、crm_mon または crm status を実行します。 テスト開始前のリソースの状態:

    # Output of crm_mon
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Active resources:
#
#stonith-sbd     (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s1-db1 ]
#     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1

    /hana/shared のエラーをシミュレートするには:

    • ANF で NFS を使用している場合は、最初にプライマリ サイトの /hana/shared ANF ボリュームの IP アドレスを確認します。 これを行うには、df -kh|grep /hana/shared を実行します。
    • Azure Files で NFS を使用している場合は、最初にストレージ アカウントのプライベート エンドポイントの IP アドレスを確認します。

    次に、いずれかのプライマリ HANA システム レプリケーション サイト VM で次のコマンドを実行して、/hana/shared NFS ファイル システムの IP アドレスへのアクセスをブロックする一時的なファイアウォール規則を設定します。

    この例では、ANF ボリューム /hana/shared の hana-s1-db1 でコマンドが実行されました。

    iptables -A INPUT -s 10.23.1.7 -j DROP; iptables -A OUTPUT -d 10.23.1.7 -j DROP

    クラスター リソースは、もう 1 つの HANA システム レプリケーション サイトに移行されます。

    AUTOMATED_REGISTER="false" に設定した場合は、セカンダリ サイトで SAP HANA システム レプリケーションを構成する必要があります。 この場合、次のコマンドを実行して、SAP HANA をセカンダリとして再構成することができます。

    # Execute on the secondary 
su - hn1adm
# Make sure HANA is not running on the secondary site. If it is started, stop HANA
sapcontrol -nr 03 -function StopWait 600 10
# Register the HANA secondary site
hdbnsutil -sr_register --name=HANA_S1 --remoteHost=hana-s2-db1 --remoteInstance=03 --replicationMode=sync
# Switch back to root and cleanup failed resources
crm resource cleanup SAPHana_HN1_HDB03

    テスト後のリソースの状態は次のようになります。

    # Output of crm_mon
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Active resources:
#
#stonith-sbd     (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s2-db1 ]
#     Slaves: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db2 hana-s2-db3 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1

次のステップ