Azure の Red Hat Enterprise Linux に Pacemaker を設定する
この記事では、Red Hat Enterprise Server (RHEL) で基本的な Pacemaker クラスターを構成する方法について説明します。 この手順では、RHEL 7、RHEL 8、RHEL 9 について説明します。
前提条件
はじめに、次の 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 2002167: Red Hat Enterprise Linux 用の OS 設定が推奨されています。
- SAP Note 3108316: Red Hat Enterprise Linux 9.x 用の OS 設定が推奨されています。
- SAP Note 2009879: Red Hat Enterprise Linux 用の SAP HANA ガイドラインが記載されています。
- SAP Note 3108302 には、Red Hat Enterprise Linux 9.x 用の 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 モニタリング拡張機能 for SAP に関するその他のトラブルシューティング情報が記載されています。
- SAP Community WIKI: Linux に必要なすべての SAP Note を参照できます。
- Linux 上の SAP のための Azure Virtual Machines の計画と実装
- Linux 上の SAP のための Azure Virtual Machines のデプロイ (この記事)
- Linux 上の SAP のための Azure Virtual Machines DBMS のデプロイ
- Pacemaker クラスターでの SAP HANA システム レプリケーション
- 一般的な RHEL ドキュメント:
- Azure 固有の RHEL ドキュメント:
- RHEL 高可用性クラスターに関するポリシーをサポート - クラスター メンバーとしての Microsoft Azure Virtual Machines
- Microsoft Azure 上で Red Hat Enterprise Linux 7.4 (およびそれ以降) の高可用性クラスターをインストールして構成する
- RHEL 8 の導入に関する考慮事項 - 高可用性とクラスター
- RHEL 7.6 上の Pacemaker で SAP S/4HANA ASCS/ERS と Standalone Enqueue Server 2 (ENSA2) を構成する
- Azure 上の RHEL for SAP オファリング
クラスターのインストール
Note
Red Hat では、ソフトウェアでエミュレートするウォッチドッグはサポートしていません。 Red Hat では、クラウド プラットフォームの SBD はサポートしていません。 詳細については、「Support Policies for RHEL High Availability Clusters - sbd and fence_sbd」(RHEL 高可用性クラスターのサポートポリシー - sbd と fence_sbd) に関するページを参照してください。
Azure 上の Pacemaker が使用された RHEL クラスターでサポートされるフェンス メカニズムは、Azure フェンス エージェントのみです。
以下の項目には、次のいずれかのプレフィックスが付いています:
- [A] :すべてのノードに適用できます
- [1]: ノード 1 にのみ当てはまる
- [2]: ノード 2 にのみ当てはまる
コマンドまたは RHEL 7 と RHEL 8/RHEL 9 の構成の違いは、ドキュメントでマークされています。
[A] 登録します。 この手順は省略可能です。 RHEL SAP の HA が有効になっているイメージを使用する場合、この手順は必要ありません。
たとえば、RHEL 7 にデプロイする場合は、VM を登録し、RHEL 7 のリポジトリを含むプールにアタッチします。
sudo subscription-manager register # List the available pools sudo subscription-manager list --available --matches '*SAP*' sudo subscription-manager attach --pool=<pool id>
Azure Marketplace の従量課金制 RHEL イメージにプールをアタッチすると、RHEL の使用量に対して実質的に 2 倍の課金が行われます。 従量課金制イメージに対して 1 回、アタッチするプールの RHEL エンタイトルメントに対して 1 回課金されます。 この状況を防ぐ目的で、Azure では Bring-Your-Own-Subscription (BYOS) RHEL イメージが提供されるようになりました。 詳細については、Red Hat Enterprise Linux のサブスクリプション持ち込み Azure イメージに関するページを参照してください。
[A] SAP のリポジトリ用に RHEL を有効にします。 この手順は省略可能です。 RHEL SAP の HA が有効になっているイメージを使用する場合、この手順は必要ありません。
必要なパッケージを RHEL 7 にインストールするには、次のリポジトリを有効にします。
sudo subscription-manager repos --disable "*" sudo subscription-manager repos --enable=rhel-7-server-rpms sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms sudo subscription-manager repos --enable=rhel-sap-for-rhel-7-server-rpms sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-eus-rpms
[A] RHEL HA アドオンをインストールします。
sudo yum install -y pcs pacemaker fence-agents-azure-arm nmap-ncat
重要
リソースの停止に失敗した場合や、クラスター ノードが互いに通信できなくなった場合に、お客様がフェールオーバー時間の高速化の恩恵を受けられるよう、次のバージョン (またはこれら以降) の Azure Fence Agent をおすすめします。
RHEL 7.7 以降では、使用可能な最新バージョンの fence-agents パッケージが使用されます。
RHEL 7.6: fence-agents-4.2.1-11.el7_6.8
RHEL 7.5: fence-agents-4.0.11-86.el7_5.8
RHEL 7.4: fence-agents-4.0.11-66.el7_4.12
詳細については、「Azure VM running as a RHEL High-Availability cluster member take a very long time to be fenced, or fencing fails/times out before the VM shuts down」 (RHEL 高可用性クラスターのメンバーを実行している Azure VM のフェンシングに非常に長い時間がかかる、フェンシングが失敗する、VM がシャットダウンする前にタイムアウトする) をご覧ください。
重要
フェンス エージェントのサービス プリンシパル名ではなく、Azure リソースのマネージド ID を使用することを希望するお客様には、次のバージョンの Azure Fence Agent (またはそれ以降) をおすすめします。
RHEL 8.4: fence-agents-4.2.1-54.el8.
RHEL 8.2: fence-agents-4.2.1-41.el8_2.4
RHEL 8.1: fence-agents-4.2.1-30.el8_1.4
RHEL 7.9: fence-agents-4.2.1-41.el7_9.4.
重要
RHEL 9 では、Azure Fence Agent の問題を回避するために、次のパッケージ バージョン (またはそれ以降) をおすすめします。
fence-agents-4.10.0-20.el9_0.7
fence-agents-common-4.10.0-20.el9_0.6
ha-cloud-support-4.10.0-20.el9_0.6.x86_64.rpm
Azure Fence Agent のバージョンを確認します。 必要に応じて、最低限必要なバージョン以降に更新します。
# Check the version of the Azure Fence Agent sudo yum info fence-agents-azure-arm
重要
Azure Fence Agent を更新する必要があり、カスタム ロールを使用している場合は、カスタム ロールを更新してアクション powerOff を含めるようにします。 詳細については、「フェンス エージェントのカスタム ロールを作成する」を参照してください。
RHEL 9 にデプロイしている場合は、クラウド デプロイ用のリソース エージェントもインストールします。
sudo yum install -y resource-agents-cloud
[A] ホスト名解決を設定します。
DNS サーバーを使用するか、すべてのノードの
/etc/hosts
ファイルを変更することができます。 この例では、/etc/hosts
ファイルを使用する方法を示します。 次のコマンドの IP アドレスとホスト名を置き換えます。重要
クラスター構成でホスト名を使用している場合は、信頼性の高いホスト名解決が不可欠です。 名前が使用できず、クラスターのフェールオーバーの遅延につながる可能性がある場合、クラスター通信は失敗します。
/etc/hosts
を使用する利点は、単一障害点になる可能性もある DNS からクラスターを独立させられることです。sudo vi /etc/hosts
/etc/hosts
に次の行を挿入します。 お使いの環境に合わせて IP アドレスとホスト名を変更します。# IP address of the first cluster node 10.0.0.6 prod-cl1-0 # IP address of the second cluster node 10.0.0.7 prod-cl1-1
[A]
hacluster
のパスワードを同じパスワードに変更します。sudo passwd hacluster
[A] Pacemaker のファイアウォール規則を追加します。
クラスター ノード間のすべてのクラスターの通信用に、次のファイアウォール規則を追加します。
sudo firewall-cmd --add-service=high-availability --permanent sudo firewall-cmd --add-service=high-availability
[A] 基本的なクラスター サービスを有効にします。
次のコマンドを実行し、Pacemaker サービスを有効にして、それを開始します。
sudo systemctl start pcsd.service sudo systemctl enable pcsd.service
[1] Pacemaker クラスターを作成します。
次のコマンドを実行し、ノードを認証してクラスターを作成します。 トークンを 30000 に設定してメモリ保持メンテナンスを可能にします。 詳細については、Linux のこの記事を参照してください。
RHEL 7.x でクラスターをビルドしている場合は、次のコマンドを使用します。
sudo pcs cluster auth prod-cl1-0 prod-cl1-1 -u hacluster sudo pcs cluster setup --name nw1-azr prod-cl1-0 prod-cl1-1 --token 30000 sudo pcs cluster start --all
RHEL 8.x/RHEL 9.x でクラスターをビルドしている場合は、次のコマンドを使用します。
sudo pcs host auth prod-cl1-0 prod-cl1-1 -u hacluster sudo pcs cluster setup nw1-azr prod-cl1-0 prod-cl1-1 totem token=30000 sudo pcs cluster start --all
次のコマンドを実行して、クラスターの状態を確認します。
# Run the following command until the status of both nodes is online sudo pcs status # Cluster name: nw1-azr # WARNING: no stonith devices and stonith-enabled is not false # Stack: corosync # Current DC: prod-cl1-1 (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum # Last updated: Fri Aug 17 09:18:24 2018 # Last change: Fri Aug 17 09:17:46 2018 by hacluster via crmd on prod-cl1-1 # # 2 nodes configured # 0 resources configured # # Online: [ prod-cl1-0 prod-cl1-1 ] # # No resources # # Daemon Status: # corosync: active/disabled # pacemaker: active/disabled # pcsd: active/enabled
[A] 予想される票を設定します。
# Check the quorum votes pcs quorum status # If the quorum votes are not set to 2, execute the next command sudo pcs quorum expected-votes 2
ヒント
マルチノード クラスター (2 つ以上のノードを持つクラスター) をビルドしている場合は、投票を 2 に設定しないでください。
[1] 同時フェンス アクションを許可します。
sudo pcs property set concurrent-fencing=true
フェンス デバイスを作成する
フェンス デバイスは、Azure リソースのマネージド IDまたはサービス プリンシパルのいずれかを使用して、Azure に対する認可を行います。
マネージド ID (MSI) を作成するには、クラスター内の VM ごとにシステム割り当てマネージド ID を作成します。 システム割り当てマネージド ID が既に存在する場合は、それが使用されます。 現時点では、Pacemaker でユーザー割り当てマネージド ID を使用しないでください。 マネージド ID に基づくフェンス デバイスは、RHEL 7.9 および RHEL 8.x/RHEL 9.x でサポートされています。
[1] フェンス エージェントのカスタム ロールを作成する
既定では、マネージド ID とサービス プリンシパルのどちらにも、Azure リソースにアクセスするためのアクセス許可はありません。 クラスターのすべての VM を開始および停止 (電源オフ) するアクセス許可をマネージド ID またはサービス プリンシパルに付与する必要があります。 まだカスタム ロールを作成していない場合は、PowerShell または Azure CLI を使って作成できます。
入力ファイルには次の内容を使用します。 コンテンツをサブスクリプションに合わせる必要があります。つまり、xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
と yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
をサブスクリプションの ID に置き換えます。 ご利用のサブスクリプションが 1 つしかない場合は、AssignableScopes
の 2 つ目のエントリは削除してください。
{
"Name": "Linux Fence Agent Role",
"description": "Allows to power-off and start virtual machines",
"assignableScopes": [
"/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"/subscriptions/yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"
],
"actions": [
"Microsoft.Compute/*/read",
"Microsoft.Compute/virtualMachines/powerOff/action",
"Microsoft.Compute/virtualMachines/start/action"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
[A] カスタム ロールを割り当てる
マネージド ID またはサービス プリンシパルを使用します。
最後のセクションで作成したカスタム ロール Linux Fence Agent Role
をクラスター VM の各マネージド ID に割り当てます。 各 VM のシステム割り当てマネージド ID には、クラスター VM のリソースごとにロールを割り当てる必要があります。 詳細については、[Azure portal を使用してリソースにマネージド ID アクセスを割り当てる] を参照してください。 各 VM のマネージド ID ロールの割り当てにすべてのクラスター VM が含まれていることを確認します。
重要
マネージド ID による認可の割り当てと削除は、有効になるまで遅延する場合があることに注意してください。
[1] フェンス デバイスを作成する
VM のアクセス許可を編集した後で、クラスターのフェンス デバイスを構成できます。
sudo pcs property set stonith-timeout=900
Note
pcmk_host_map
のオプションは、RHEL ホスト名と Azure VM 名が同一でない場合のみ、このコマンドで必要です。 hostname:vm-name の形式でマッピングを指定します。
このコマンドの太字のセクションを参照してください。 詳細については、pcmk_host_map でフェンス デバイスへのノード マッピングを指定する場合に使用する形式に関するページを参照してください。
RHEL 7.x の場合は、次のコマンドを使用してフェンス デバイスを構成します。
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
op monitor interval=3600
RHEL 8.x/9.x の場合は、次のコマンドを使用してフェンス デバイスを構成します。
# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version greater than 2.0.4-6.el8) OR (HANA scale out)
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 \
op monitor interval=3600
# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version less than 2.0.4-6.el8)
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
op monitor interval=3600
サービス プリンシパルの構成に基づいてフェンス デバイスを使用している場合は、「Azure フェンシングを使用した Pacemaker クラスターの SPN から MSI への変更」を参照し、マネージド ID 構成に変換する方法について学習します。
ヒント
- 2 ノードの Pacemaker クラスター内でのフェンス レースを回避するには、
priority-fencing-delay
クラスター プロパティを構成します。 このプロパティを使用すると、スプリット ブレイン シナリオが発生したときに、リソースの優先度の合計が高いノードをフェンスする際に、さらに遅延が発生するようになります。 詳細については、実行中のリソースが最も少ないクラスター ノードの Pacemaker によるフェンスに関するページを参照してください。 priority-fencing-delay
プロパティは、Pacemaker バージョン 2.0.4-6.el8 以降および 2 ノード クラスターに適用されます。priority-fencing-delay
クラスター プロパティを構成する場合は、pcmk_delay_max
プロパティを設定する必要はありません。 ただし、Pacemaker のバージョンが 2.0.4-6.el8 未満の場合は、pcmk_delay_max
プロパティを設定する必要があります。priority-fencing-delay
クラスター プロパティを設定する方法については、SAP ASCS/ERS および SAP HANA スケールアップ HA のそれぞれのドキュメントを参照してください。
監視およびフェンス操作は逆シリアル化されます。 その結果、長時間実行されている監視操作と同時フェンス イベントがある場合、既に実行されている監視操作により、クラスターのフェールオーバーに遅延は発生しません。
[1] フェンス デバイスの使用を有効にする
sudo pcs property set stonith-enabled=true
ヒント
Azure フェンス エージェントには、パブリック エンドポイントへの送信接続が必要です。 考えられる解決策と詳細については、「標準 ILB を使用した VM のパブリック エンドポイント接続」を参照してください。
Azure のスケジュール化されたイベント用に Pacemaker を構成する
Azure では、スケジュール化されたイベントが提供されています。 スケジュール化されたイベントは、メタデータ サービスを介して送信され、このようなイベントに対して準備する時間をアプリケーションに与えます。
Pacemaker リソース エージェント azure-events-az
では、スケジュール化された Azure イベントが監視されます。 イベントが検出され、リソース エージェントが別のクラスター ノードが使用可能であると判断した場合は、クラスター正常性属性が設定されます。
ノードにクラスター正常性属性が設定されると、場所制約がトリガーされ、health-
で始まらない名前を持つすべてのリソースが、スケジュール化されたイベントを含むノードから移行されます。 影響を受けるクラスター ノードが実行中のクラスター リソースを解放すると、スケジュール化されたイベントが確認され、再起動などのアクションを実行できます。
[A]
azure-events-az
エージェントのパッケージが既にインストールされ、最新であることを確認します。RHEL 8.x: sudo dnf info resource-agents RHEL 9.x: sudo dnf info resource-agents-cloud
最小バージョンの要件:
- RHEL 8.4:
resource-agents-4.1.1-90.13
- RHEL 8.6:
resource-agents-4.9.0-16.9
- RHEL 8.8:
resource-agents-4.9.0-40.1
- RHEL 9.0:
resource-agents-cloud-4.10.0-9.6
- RHEL 9.2 以降:
resource-agents-cloud-4.10.0-34.1
- RHEL 8.4:
[1] Pacemaker 内でリソースを構成します。
#Place the cluster in maintenance mode sudo pcs property set maintenance-mode=true
[1] Pacemaker クラスター正常性ノードの戦略と制約を設定します。
sudo pcs property set node-health-strategy=custom sudo pcs constraint location 'regexp%!health-.*' \ rule score-attribute='#health-azure' \ defined '#uname'
重要
次の手順で説明するリソース以外に、
health-
で始まるクラスター内の他のリソースは定義しないでください。[1] クラスター属性の初期値を設定します。 各クラスター ノードおよびマジョリティ メーカー VM を含むスケールアウト環境に対して実行します。
sudo crm_attribute --node prod-cl1-0 --name '#health-azure' --update 0 sudo crm_attribute --node prod-cl1-1 --name '#health-azure' --update 0
[1] Pacemaker 内でリソースを構成します。 リソースが
health-azure
で始まることを確認します。sudo pcs resource create health-azure-events \ ocf:heartbeat:azure-events-az op monitor interval=10s sudo pcs resource clone health-azure-events allow-unhealthy-nodes=true
Pacemaker クラスターのメンテナンス モードを解除します。
sudo pcs property set maintenance-mode=false
有効化中にエラーをクリアし、
health-azure-events
リソースがすべてのクラスター ノードで正常に開始されたことを確認します。sudo pcs resource cleanup
スケジュール化されたイベントに対する初回クエリの実行には、最大 2 分かかることがあります。 スケジュール化されたイベントを使用した Pacemaker テストでは、クラスター VM の再起動または再デプロイ アクションを使用できます。 詳細については、「スケジュールされたイベント」を参照してください。
オプションのフェンス構成
ヒント
このセクションは、特殊なフェンス デバイス fence_kdump
を構成する必要がある場合にのみ適用されます。
VM 内で診断情報を収集する必要がある場合は、フェンス エージェント fence_kdump
に基づいて別のフェンス デバイスを構成すると有用な場合があります。 fence_kdump
エージェントでは、他のフェンス メソッドが呼び出される前に、kdump クラッシュ復旧に入ったノードを検出してクラッシュ復旧サービスを完了できるようにすることができます。 fence_kdump
は、Azure VM 使用時の Azure Fence Agent のような、従来のフェンス メカニズムに代わるものではないことに注意してください。
重要
fence_kdump
が第 1 レベルのフェンス デバイスとして構成されている場合、それによってフェンス操作で遅延が発生し、アプリケーション リソースのフェールオーバーでそれぞれ遅延が発生することに注意してください。
クラッシュ ダンプが正常に検出された場合、フェンスはクラッシュ復旧サービスが完了するまで遅延されます。 失敗したノードが到達不能な場合や応答しない場合は、構成されている繰り返しの回数と、fence_kdump
のタイムアウトによって決まる時間だけフェンスが遅延されます。 詳細については、「Red Hat Pacemaker クラスターで fence_kdump を構成する方法」を参照してください。
提案されている fence_kdump
のタイムアウトは、実際の環境に合わせて調整する必要がある場合があります。
fence_kdump
フェンスを構成するのは、VM 内で診断情報を収集する必要がある場合のみとし、必ず Azure Fence Agent のような従来のフェンス方式と組み合わせることをおすすめします。
以下の Red Hat KB には、fence_kdump
フェンスの構成に関する重要な情報が含まれています。
- 「Red Hat Pacemaker クラスターで fence_kdump を構成する方法」を参照してください。
- 「Pacemaker を使用する RHEL クラスターでフェンス レベルを構成および管理する方法」を参照してください。
- 「2.0.14 よりも古い kexec-tools を使用すると "X 秒後にタイムアウトします" と表示されて RHEL 6 または 7 HA クラスターで fence_kdump が失敗する」を参照してください。
- 既定のタイムアウトを変更する方法については、「RHEL 6、7、8 HA アドオンで使用するために kdump を構成する方法」を参照してください。
fence_kdump
の使用時にフェールオーバーの遅延を減らす方法については、「fence_kdump 構成の追加時に予想されるフェールオーバーの遅延を減らすことができるか」を参照してください。
Azure Fence Agent の構成に加えて以下のオプションの手順を実行し、第 1 レベルのフェンス構成として fence_kdump
を追加します。
[A]
kdump
がアクティブになっていて、構成されていることを確認します。systemctl is-active kdump # Expected result # active
[A]
fence_kdump
フェンス エージェントをインストールします。yum install fence-agents-kdump
[1] クラスター内に
fence_kdump
フェンス デバイスを作成します。pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1" timeout=30
[1] フェンス レベルを構成して、
fence_kdump
フェンス メカニズムが最初に動作するようにします。pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1" pcs stonith level add 1 prod-cl1-0 rsc_st_kdump pcs stonith level add 1 prod-cl1-1 rsc_st_kdump pcs stonith level add 2 prod-cl1-0 rsc_st_azure pcs stonith level add 2 prod-cl1-1 rsc_st_azure # Check the fencing level configuration pcs stonith level # Example output # Target: prod-cl1-0 # Level 1 - rsc_st_kdump # Level 2 - rsc_st_azure # Target: prod-cl1-1 # Level 1 - rsc_st_kdump # Level 2 - rsc_st_azure
[A] ファイアウォールを通過する
fence_kdump
のために必要なポートを許可します。firewall-cmd --add-port=7410/udp firewall-cmd --add-port=7410/udp --permanent
[A]
initramfs
イメージ ファイルにfence_kdump
とhosts
のファイルが含まれることを確認します。 詳細については、「Red Hat Pacemaker クラスターで fence_kdump を構成する方法」を参照してください。lsinitrd /boot/initramfs-$(uname -r)kdump.img | egrep "fence|hosts" # Example output # -rw-r--r-- 1 root root 208 Jun 7 21:42 etc/hosts # -rwxr-xr-x 1 root root 15560 Jun 17 14:59 usr/libexec/fence_kdump_send
[A]
kexec-tools
の一部のバージョンでタイムアウトによるfence_kdump
の失敗が発生しないように、/etc/kdump.conf
でfence_kdump_nodes
の構成を実行します。 詳細については、「kexec-tools バージョン 2.0.15 以降の使用時に fence_kdump_nodes が指定されていないと fence_kdump がタイムアウトする」と、「2.0.14 より前のバージョンの kexec-tools の使用時に RHEL 6 または 7 の高可用性クラスターで "X 秒後にタイムアウトします" と表示されて fence_kdump が失敗する」を参照してください。 ここでは、2 ノード クラスターの構成例を示します。/etc/kdump.conf
で変更を加えた後に、kdump イメージを再生成する必要があります。 再生成するには、kdump
サービスを再起動します。vi /etc/kdump.conf # On node prod-cl1-0 make sure the following line is added fence_kdump_nodes prod-cl1-1 # On node prod-cl1-1 make sure the following line is added fence_kdump_nodes prod-cl1-0 # Restart the service on each node systemctl restart kdump
ノードをクラッシュさせて構成をテストします。 詳細については、「Red Hat Pacemaker クラスターで fence_kdump を構成する方法」を参照してください。
重要
クラスターが既に運用環境で使用中の場合は、ノードをクラッシュさせるとアプリケーションに影響があるため、それに応じてテストを計画します。
echo c > /proc/sysrq-trigger
次のステップ
- 「SAP のための Azure Virtual Machines の計画と実装」を参照してください。
- 「SAP のための Azure Virtual Machines のデプロイ」を参照してください。
- 「SAP のための Azure Virtual Machines DBMS のデプロイ」を参照してください。
- Azure VM 上の SAP HANA の HA を確保し、ディザスター リカバリーを計画する方法を確認するには、「Azure Virtual Machines 上の SAP HANA の高可用性」を参照してください。