SUSE Linux Enterprise Server 上の Azure VM での NFS の高可用性
Note
高可用性 SAP システムに共有データを格納するには、Azure ファースト パーティ NFS サービス (Azure Files 上の NFS または NFS ANF ボリューム) のいずれかをデプロイすることをお勧めします。 SAP 参照アーキテクチャを重視しなくなり、NFS クラスターを利用していることに注意してください。
この記事では、仮想マシンのデプロイと構成、クラスター フレームワークのインストール、可用性の高い SAP システムの共有データを格納するために使用できる高可用性 NFS サーバーのインストールの方法について説明します。 このガイドでは、NW1 と NW2 の 2 つの SAP システムで使用される高可用性 NFS サーバーを設定する方法について説明します。 この例のリソース (仮想マシン、仮想ネットワークなど) の名前は、リソース プレフィックスが prod の SAP ファイル サーバー テンプレートを使用していることを想定しています。
Note
この記事には、Microsoft が使用しなくなった用語への言及が含まれています。 ソフトウェアからこれらの用語が削除された時点で、この記事から削除します。
はじめに、次の SAP Note およびガイドを確認してください
SAP Note 1928533: 次の情報が含まれています。
- SAP ソフトウェアのデプロイでサポートされる Azure VM サイズの一覧
- Azure VM サイズの容量に関する重要な情報
- サポートされる SAP ソフトウェア、およびオペレーティング システム (OS) とデータベースの組み合わせ
- Microsoft Azure 上の Windows と Linux に必要な SAP カーネル バージョン
SAP Note 2015553: SAP でサポートされる Azure 上の SAP ソフトウェア デプロイの前提条件が記載されています。
SAP Note 2205917: SUSE Linux Enterprise Server for SAP Applications 向けの推奨の OS 設定が記載されています。
SAP Note 1944799: SUSE Linux Enterprise Server for SAP Applications の SAP HANA ガイドラインが記載されています。
SAP Note 2178632: Azure 上の SAP について報告されるすべての監視メトリックに関する詳細情報が記載されています。
SAP Note 2191498: Azure 上の Linux に必要な SAP Host Agent のバージョンが記載されています。
SAP Note 2243692: Azure 上の Linux で動作する SAP のライセンスに関する情報が記載されています。
SAP Note 1984787: SUSE Linux Enterprise Server 12 に関する一般情報が記載されています。
SAP Note 1999351: Azure Enhanced Monitoring Extension for SAP に関するその他のトラブルシューティング情報が記載されています。
SAP Community WIKI: Linux に必要なすべての SAP Note を参照できます。
SUSE Linux Enterprise High Availability Extension 12 SP5 の DRBD と Pacemaker を使用する高可用性 NFS ストレージ
SUSE Linux Enterprise Server for SAP Applications 12 SP5 のベスト プラクティス ガイド
SUSE Linux Enterprise Server for SAP Applications 12 SP5 リリース ノート
概要
高可用性を実現するため、SAP NetWeaver には NFS サーバーが必要です。 NFS サーバーは別のクラスターで構成されており、複数の SAP システムが使用できます。
NFS サーバーは、この NFS サーバーを使用するすべての SAP システムに専用の仮想ホスト名と仮想 IP アドレスを使用します。 Azure では、仮想 IP アドレスを使用するためにロード バランサーが必要になります。 表示されている構成は、次を含むロード バランサーを示しています。
- NW1 のフロントエンド IP アドレス 10.0.0.4
- NW2 のフロントエンド IP アドレス 10.0.0.5
- NW1 のプローブ ポート 61000
- NW2 のプローブ ポート 61001
高可用性 NFS サーバーの設定
Azure Portal を使用した手動による Linux のデプロイ
このドキュメントは、リソース グループ、Azure Virtual Network、サブネットが既にデプロイ済みであることを前提としています。
NFS サーバー用の 2 つの仮想マシンをデプロイします。 SAP システムでサポートされている適切な SLES イメージを選択します。 VM を、スケール セット、可用性ゾーン、可用性セットのいずれかの可用性オプションでデプロイできます。
Azure Load Balancer の構成
「ロード バランサーの作成」のガイドに従い、NFS サーバーの高可用性用に Standard Load Balancer を構成します。 ロード バランサーの構成においては、以下の点を考慮してください。
- フロントエンド IP 構成: 2 つのフロントエンド IP を作成します。 NFS サーバーと同じ仮想ネットワークとサブネットを選択します。
- バックエンド プール: バックエンド プールを作成し、NFS サーバーの VM を追加します。
- 受信規則: 2 つの負荷分散規則を作成します。1 つは NW1 用で、もう 1 つは NW2 用です。 両方の負荷分散規則に対して同じ手順を実行します。
- フロントエンド IP アドレス: フロントエンド IP を選択します
- バックエンド プール: バックエンド プールを選択します
- [High availability ports] (高可用性ポート) をオンにします
- プロトコル: TCP
- 正常性プローブ: 以下の詳細を使用して正常性プローブを作成します (NW1 と NW2 の両方に適用されます)
- プロトコル: TCP
- ポート: [例: NW1 の場合は 61000、NW2 の場合は 61001]
- 間隔: 5
- プローブしきい値: 2
- アイドル タイムアウト (分): 30
- [Floating IP を有効にする] をオンにします
Note
正常性プローブ構成プロパティ numberOfProbes (ポータルでは [異常のしきい値] と呼ばれます) が順守されていません。 このため、成功または失敗した連続プローブの数を制御するには、プロパティ "probeThreshold" を 2 に設定します。 現在、このプロパティは Azure portal を使用して設定できないため、Azure CLI または PowerShell コマンドを使用してください。
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 の正常性プローブ」を参照してください。 - saptune が手動で設定した
net.ipv4.tcp_timestamps
値を0
から1
に変更するのを防ぐには、saptune バージョンを 3.1.1 以上に更新する必要があります。 詳細については、「saptune 3.1.1 – 更新する必要がありますか?」を参照してください。
Pacemaker クラスターの作成
「Azure の SUSE Linux Enterprise Server に Pacemaker をセットアップする」の手順に従って、この NFS サーバーに対して基本的な Pacemaker クラスターを作成します。
NFS サーバーの構成
次の各手順の先頭には、 [A] - 全ノードが該当、 [1] - ノード 1 のみ該当、 [2] - ノード 2 のみ該当、のいずれかが付いています。
[A] ホスト名解決を設定します
DNS サーバーを使用するか、すべてのノードの /etc/hosts を変更します。 この例では、/etc/hosts ファイルを使用する方法を示しています。 次のコマンドの IP アドレスとホスト名を置き換えます
sudo vi /etc/hosts
次の行を /etc/hosts に挿入します。 お使いの環境に合わせて IP アドレスとホスト名を変更します
# IP address of the load balancer frontend configuration for NFS 10.0.0.4 nw1-nfs 10.0.0.5 nw2-nfs
[A] NFS サーバーを有効にします
ルートの NFS エクスポート エントリを作成します
sudo sh -c 'echo /srv/nfs/ *\(rw,no_root_squash,fsid=0\)>/etc/exports' sudo mkdir /srv/nfs/
[A] drbd コンポーネントをインストールします
sudo zypper install drbd drbd-kmp-default drbd-utils
[A] drbd デバイス用のパーティションを作成します
使用可能なすべてのデータ ディスクを表示します
sudo ls /dev/disk/azure/scsi1/ # Example output # lun0 lun1
すべてのデータ ディスクのパーティションを作成します
sudo sh -c 'echo -e "n\n\n\n\n\nw\n" | fdisk /dev/disk/azure/scsi1/lun0' sudo sh -c 'echo -e "n\n\n\n\n\nw\n" | fdisk /dev/disk/azure/scsi1/lun1'
[A] LVM 構成を作成します
使用可能なすべてのパーティションを表示します
ls /dev/disk/azure/scsi1/lun*-part* # Example output # /dev/disk/azure/scsi1/lun0-part1 /dev/disk/azure/scsi1/lun1-part1
すべてのパーティションに LVM ボリュームを作成します
sudo pvcreate /dev/disk/azure/scsi1/lun0-part1 sudo vgcreate vg-NW1-NFS /dev/disk/azure/scsi1/lun0-part1 sudo lvcreate -l 100%FREE -n NW1 vg-NW1-NFS sudo pvcreate /dev/disk/azure/scsi1/lun1-part1 sudo vgcreate vg-NW2-NFS /dev/disk/azure/scsi1/lun1-part1 sudo lvcreate -l 100%FREE -n NW2 vg-NW2-NFS
[A] drbd を構成します
sudo vi /etc/drbd.conf
drbd.conf ファイルに次の 2 行が含まれていることを確認します
include "drbd.d/global_common.conf"; include "drbd.d/*.res";
グローバルな drbd 構成を変更します
sudo vi /etc/drbd.d/global_common.conf
ハンドラーと net セクションに次のエントリを追加します。
global { usage-count no; } common { handlers { fence-peer "/usr/lib/drbd/crm-fence-peer.9.sh"; after-resync-target "/usr/lib/drbd/crm-unfence-peer.9.sh"; split-brain "/usr/lib/drbd/notify-split-brain.sh root"; pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f"; } startup { wfc-timeout 0; } options { } disk { md-flushes yes; disk-flushes yes; c-plan-ahead 1; c-min-rate 100M; c-fill-target 20M; c-max-rate 4G; } net { after-sb-0pri discard-younger-primary; after-sb-1pri discard-secondary; after-sb-2pri call-pri-lost-after-sb; protocol C; tcp-cork yes; max-buffers 20000; max-epoch-size 20000; sndbuf-size 0; rcvbuf-size 0; } }
[A] NFS drbd デバイスを作成します
sudo vi /etc/drbd.d/NW1-nfs.res
新しい drbd デバイスの構成を挿入し、終了します
resource NW1-nfs { protocol C; disk { on-io-error detach; } net { fencing resource-and-stonith; } on prod-nfs-0 { address 10.0.0.6:7790; device /dev/drbd0; disk /dev/vg-NW1-NFS/NW1; meta-disk internal; } on prod-nfs-1 { address 10.0.0.7:7790; device /dev/drbd0; disk /dev/vg-NW1-NFS/NW1; meta-disk internal; } }
sudo vi /etc/drbd.d/NW2-nfs.res
新しい drbd デバイスの構成を挿入し、終了します
resource NW2-nfs { protocol C; disk { on-io-error detach; } net { fencing resource-and-stonith; } on prod-nfs-0 { address 10.0.0.6:7791; device /dev/drbd1; disk /dev/vg-NW2-NFS/NW2; meta-disk internal; } on prod-nfs-1 { address 10.0.0.7:7791; device /dev/drbd1; disk /dev/vg-NW2-NFS/NW2; meta-disk internal; } }
drbd デバイスを作成し、起動します
sudo drbdadm create-md NW1-nfs sudo drbdadm create-md NW2-nfs sudo drbdadm up NW1-nfs sudo drbdadm up NW2-nfs
[1] 初期同期をスキップします
sudo drbdadm new-current-uuid --clear-bitmap NW1-nfs sudo drbdadm new-current-uuid --clear-bitmap NW2-nfs
[1] プライマリ ノードを設定します
sudo drbdadm primary --force NW1-nfs sudo drbdadm primary --force NW2-nfs
[1] 新しい drbd デバイスが同期されるまで待ちます
sudo drbdsetup wait-sync-resource NW1-nfs sudo drbdsetup wait-sync-resource NW2-nfs
[1] drbd デバイス上にファイル システムを作成します
sudo mkfs.xfs /dev/drbd0 sudo mkdir /srv/nfs/NW1 sudo chattr +i /srv/nfs/NW1 sudo mount -t xfs /dev/drbd0 /srv/nfs/NW1 sudo mkdir /srv/nfs/NW1/sidsys sudo mkdir /srv/nfs/NW1/sapmntsid sudo mkdir /srv/nfs/NW1/trans sudo mkdir /srv/nfs/NW1/ASCS sudo mkdir /srv/nfs/NW1/ASCSERS sudo mkdir /srv/nfs/NW1/SCS sudo mkdir /srv/nfs/NW1/SCSERS sudo umount /srv/nfs/NW1 sudo mkfs.xfs /dev/drbd1 sudo mkdir /srv/nfs/NW2 sudo chattr +i /srv/nfs/NW2 sudo mount -t xfs /dev/drbd1 /srv/nfs/NW2 sudo mkdir /srv/nfs/NW2/sidsys sudo mkdir /srv/nfs/NW2/sapmntsid sudo mkdir /srv/nfs/NW2/trans sudo mkdir /srv/nfs/NW2/ASCS sudo mkdir /srv/nfs/NW2/ASCSERS sudo mkdir /srv/nfs/NW2/SCS sudo mkdir /srv/nfs/NW2/SCSERS sudo umount /srv/nfs/NW2
[A] drbd スプリット ブレイン検出を設定します
drbd を使用してあるホストから別のホストにデータを同期するときに、スプリット ブレインと呼ばれる状況が発生することがあります。 スプリット ブレインは、両方のクラスター ノードの drbd デバイスがプライマリに昇格され、非同期になるシナリオです。これはまれな状況かもしれませんが、スプリット ブレインをできるだけ早く処理して解決する必要があります。 したがって、スプリット ブレインが発生したときに通知を受け取ることが重要です。
スプリット ブレインの通知を設定する方法については、drbd の公式ドキュメントを参照してください。
さらに、スプリット ブレイン シナリオから自動的に復旧することも可能です。 詳細については、「Automatic split brain recovery policies (自動スプリット ブレイン復旧ポリシー)」を参照してください
クラスター フレームワークの構成
[1] SAP システム NW1 の NFS drbd デバイスをクラスター構成に追加します
重要
最近のテストで、バックログと 1 つの接続のみを処理するという制限があるため、netcat によって要求への応答が停止される状況があることが明らかになりました。 netcat リソースでは、Azure ロード バランサー要求のリッスンを停止し、フローティング IP は使用できなくなります。
既存の Pacemaker クラスターについては、以前、netcat を socat に置き換えることをお勧めしました。 現時点では、resource-agents パッケージの一部である azure-lb リソース エージェントを使用することをお勧めしています。パッケージのバージョン要件は次のとおりです。- SLES 12 SP4/SP5 の場合、バージョンは resource-agents-4.3.018.a7fb5035-3.30.1 以上である必要があります。
- SLES 15/15 SP1 の場合、バージョンは resource-agents-4.3.0184.6ee15eb2-4.13.1 以上である必要があります。
変更には短時間のダウンタイムが必要であることに注意してください。
既存の Pacemaker クラスターについては、「Azure Load-Balancer の検出のセキュリティ強化」で説明されているように、socat を使用するよう構成が既に変更されていた場合は、すぐに azure-lb リソース エージェントに切り替える必要はありません。sudo crm configure rsc_defaults resource-stickiness="200" # Enable maintenance mode sudo crm configure property maintenance-mode=true sudo crm configure primitive drbd_NW1_nfs \ ocf:linbit:drbd \ params drbd_resource="NW1-nfs" \ op monitor interval="15" role="Master" \ op monitor interval="30" role="Slave" sudo crm configure ms ms-drbd_NW1_nfs drbd_NW1_nfs \ meta master-max="1" master-node-max="1" clone-max="2" \ clone-node-max="1" notify="true" interleave="true" sudo crm configure primitive fs_NW1_sapmnt \ ocf:heartbeat:Filesystem \ params device=/dev/drbd0 \ directory=/srv/nfs/NW1 \ fstype=xfs \ op monitor interval="10s" sudo crm configure primitive nfsserver systemd:nfs-server \ op monitor interval="30s" sudo crm configure clone cl-nfsserver nfsserver sudo crm configure primitive exportfs_NW1 \ ocf:heartbeat:exportfs \ params directory="/srv/nfs/NW1" \ options="rw,no_root_squash,crossmnt" clientspec="*" fsid=1 wait_for_leasetime_on_stop=true op monitor interval="30s" sudo crm configure primitive vip_NW1_nfs IPaddr2 \ params ip=10.0.0.4 op monitor interval=10 timeout=20 sudo crm configure primitive nc_NW1_nfs azure-lb port=61000 \ op monitor timeout=20s interval=10 sudo crm configure group g-NW1_nfs \ fs_NW1_sapmnt exportfs_NW1 nc_NW1_nfs vip_NW1_nfs sudo crm configure order o-NW1_drbd_before_nfs inf: \ ms-drbd_NW1_nfs:promote g-NW1_nfs:start sudo crm configure colocation col-NW1_nfs_on_drbd inf: \ g-NW1_nfs ms-drbd_NW1_nfs:Master
[1] SAP システム NW2 の NFS drbd デバイスをクラスター構成に追加します
# Enable maintenance mode sudo crm configure property maintenance-mode=true sudo crm configure primitive drbd_NW2_nfs \ ocf:linbit:drbd \ params drbd_resource="NW2-nfs" \ op monitor interval="15" role="Master" \ op monitor interval="30" role="Slave" sudo crm configure ms ms-drbd_NW2_nfs drbd_NW2_nfs \ meta master-max="1" master-node-max="1" clone-max="2" \ clone-node-max="1" notify="true" interleave="true" sudo crm configure primitive fs_NW2_sapmnt \ ocf:heartbeat:Filesystem \ params device=/dev/drbd1 \ directory=/srv/nfs/NW2 \ fstype=xfs \ op monitor interval="10s" sudo crm configure primitive exportfs_NW2 \ ocf:heartbeat:exportfs \ params directory="/srv/nfs/NW2" \ options="rw,no_root_squash,crossmnt" clientspec="*" fsid=2 wait_for_leasetime_on_stop=true op monitor interval="30s" sudo crm configure primitive vip_NW2_nfs IPaddr2 \ params ip=10.0.0.5 op monitor interval=10 timeout=20 sudo crm configure primitive nc_NW2_nfs azure-lb port=61001 \ op monitor timeout=20s interval=10 sudo crm configure group g-NW2_nfs \ fs_NW2_sapmnt exportfs_NW2 nc_NW2_nfs vip_NW2_nfs sudo crm configure order o-NW2_drbd_before_nfs inf: \ ms-drbd_NW2_nfs:promote g-NW2_nfs:start sudo crm configure colocation col-NW2_nfs_on_drbd inf: \ g-NW2_nfs ms-drbd_NW2_nfs:Master
exportfs
クラスター リソースのcrossmnt
オプションは、旧バージョンの SLES との下位互換性を維持するために、ドキュメントに含まれています。[1] メンテナンス モードを無効にします
sudo crm configure property maintenance-mode=false
次の手順
- SAP ASCS とデータベースのインストール
- SAP のための Azure Virtual Machines の計画と実装
- SAP のための Azure Virtual Machines のデプロイ
- SAP のための Azure Virtual Machines DBMS のデプロイ
- Azure VM 上の SAP HANA の高可用性を確保し、ディザスター リカバリーを計画する方法を確認するには、「Azure Virtual Machines (VM) 上の SAP HANA の高可用性」を参照してください。