フェンスデバイスを使用した SUSE での高可用性セットアップ

[アーティクル]
06/01/2023

この記事では、SUSE オペレーティングシステムでフェンスデバイスを使用して、HANA L インスタンスの高可用性 (HA) を設定する手順を説明します。

注意

このガイドは、Microsoft HANA L インスタンス環境の設定を適切にテストすることで得られたものです。 HANA L インスタンスの Microsoft サービス管理チームは、このオペレーティングシステムをサポートしていません。オペレーティングシステムレイヤーに関するトラブルシューティングと説明については、SUSE にお問い合わせください。

Microsoft サービス管理チームは、フェンスデバイスの設定とフルサポートを担当しています。フェンスデバイスに関する問題のトラブルシューティングについても支援します。

必須コンポーネント

SUSE のクラスタリングを使用して高可用性を設定するには、次のことを行う必要があります。

HANA L インスタンスをプロビジョニングする。
最新のパッチを適用したオペレーティングシステムをインストールして登録する。
HANA L インスタンスサーバーを SMT サーバーに接続し、パッチとパッケージを取得する。
ネットワークタイムプロトコル (NTP タイムサーバー) を設定する。
最新の SUSE のドキュメントで HA のセットアップに関する情報を読み、理解する。

セットアップの詳細

このガイドでは、次のセットアップを使用します。

オペレーティングシステム: SLES 12 SP1 for SAP
HANA L インスタンス:2xS192 (4 ソケット、2 TB)
HANA のバージョン: HANA 2.0 SP1
サーバー名: sapprdhdb95 (node1) および sapprdhdb96 (node2)
フェンスデバイス: iSCSI ベース
HANA L インスタンスノードのいずれかでの NTP

HANA システムレプリケーションを有効にして HANA L インスタンスを設定するときは、Microsoft サービス管理チームにフェンスデバイスの設定を依頼できます。これは、プロビジョニング時に行います。

既に HANA L インスタンスのプロビジョニングを行った方も、フェンスデバイスをセットアップできます。サービス依頼フォーム (SRF) に次の情報を入力して Microsoft サービス管理チームに渡します。 SRF は、テクニカルアカウントマネージャーか、HANA Large Instances のオンボーディングを担当する Microsoft の連絡先に連絡して取得できます。

サーバー名とサーバーの IP アドレス (例: myhanaserver1、10.35.0.1)
場所 (例: 米国東部)
顧客名 (例: Microsoft)
HANA システム識別子 (SID) (例: H11)

フェンスデバイスの設定が終わったら、Microsoft サービス管理チームから、SBD 名と iSCSI ストレージの IP アドレスが提供されます。この情報を使用してフェンスのセットアップの設定ができます。

次のセクションの手順に従い、フェンスデバイスを使用して HA を設定します。

SBD デバイスを識別する

注意

このセクションの内容は既存のお客様にのみ当てはまります。新規顧客には Microsoft サービス管理チームから SBD デバイス名を提供しますので、このセクションは飛ばしてください。

/etc/iscsi/initiatorname.isci を次のように変更します。
```
iqn.1996-04.de.suse:01:<Tenant><Location><SID><NodeNumber> 
```
Microsoft サービス管理からこの文字列を受け取ります。両ノードのファイルを変更します。ただし、ノード番号はノードによって異なります。
node.session.timeo.replacement_timeout=5 と node.startup = automatic を設定して、 /etc/iscsi/iscsid.conf を変更します。両ノードのファイルを変更します。
"両方" のノード上で次の discovery コマンドを実行します。
```
iscsiadm -m discovery -t st -p <IP address provided by Service Management>:3260
```
結果には 4 つのセッションが表示されます。
"両方" のノード上で次のコマンドを実行し、iSCSI デバイスにサインインします。
```
iscsiadm -m node -l
```
結果には 4 つのセッションが表示されます。
次のコマンドを使用して、rescan-scsi-bus.sh rescan スクリプトを実行します。自動的に作成された新しいディスクが表示されます。両ノードでこれを実行します。
```
rescan-scsi-bus.sh
```
結果には、0 より大きい LUN 番号が表示されます (例: 1、2 など)。
デバイス名を取得するには、"両方" のノード上で次のコマンドを実行します。
```
  fdisk –l
```
結果で、178 MiB のサイズのデバイスを選択します。

SBD デバイスを初期化する

"両方" のノード上で次のコマンドを使用して、SBD デバイスを初期化します。
```
sbd -d <SBD Device Name> create
```
"両方" のノード上で次のコマンドを使用して、デバイスに書き込まれた内容を確認します。
```
sbd -d <SBD Device Name> dump
```

SUSE HA クラスターを構成する

"両方" のノード上で次のコマンドを使用して、ha_sles と SAPHanaSR-doc パターンがインストールされているかどうかを確認します。インストールされていない場合はインストールします。
```
zypper in -t pattern ha_sles
zypper in SAPHanaSR SAPHanaSR-doc
```
ha-cluster-init コマンドまたは yast2 ウィザードのいずれかを使用してクラスターを設定します。この例では、yast2 ウィザードを使用しています。この手順は "プライマリノード" でのみ実施します。
1. [yast2]>[High Availability](高可用性)>[Cluster](クラスター) に移動します
  
  $YaST Control Center のスクリーンショット。[High Availability]$高可用性$ と [Cluster]$クラスター$ が選択されている。$
2. halk2 パッケージは既にインストールされているため、表示される hawk パッケージのインストールに関するダイアログで [キャンセル] を選択します。
  
  $[Install]$インストール$ と [Cancel]$キャンセル$ ボタンが存在するダイアログを示すスクリーンショット。$
3. 表示される続行に関するダイアログで、 [Continue](続行) を選択します。
4. 予期される値は、デプロイされたノード数 (この場合は 2) です。 [次へ] を選択します。
5. ノード名を追加し、 [Add suggested files](示されたファイルを追加する) を選択します。
  
  $[Sync Host]$同期ホスト$ と [Sync File]$同期ファイル$ 一覧が表示されたクラスターの構成ウィンドウを示すスクリーンショット。$
6. [Turn csync2 ON](csync2 をオンにする) を選択します。
7. [Generate Pre-Shared-Keys](事前共有キーを生成する) を選択します。
8. 表示されるポップアップメッセージで、 [OK] を選択します。
9. Csync2 で IP アドレスと事前共有キーを使って認証が実行されます。キーファイルは、csync2 -k /etc/csync2/key_hagroup を使用して生成されます。
  
  ファイル key_hagroup が作成されたら、クラスターの全メンバーに手動でコピーします。必ずファイルを node1 から node2 にコピーします。 [次へ] を選択します。
10. 既定のオプションでは、 [Booting](ブート) オプションは [Off](オフ) です。これを [On](オン) に変更すると、起動時に pacemaker サービスが開始されます。セットアップの要件に基づいて選ぶことができます。
  
  $[Booting]$ブート$ が有効な Cluster Service ウィンドウを示すスクリーンショット。$
11. [Next](次へ) をクリックしてクラスターの設定を完了します。

softdog ウォッチドッグをセットアップします

"両方" のノードの /etc/init.d/boot.local に次の行を追加します。
```
modprobe softdog
```
"両方" のノード上で次のコマンドを使用して、ファイル /etc/sysconfig/sbd を更新します。
```
SBD_DEVICE="<SBD Device Name>"
```
"両方" のノード上で次のコマンドを実行して、カーネルモジュールを読み込みます。
```
modprobe softdog
```
"両方" のノード上で次のコマンドを使用して、softdog が実行されていることを確認します。
```
lsmod | grep dog
```
"両方" のノード上で次のコマンドを使用して、SBD デバイスを起動します。
```
/usr/share/sbd/sbd.sh start
```
"両方" のノード上で次のコマンドを使用して、SBD デーモンをテストします。
```
sbd -d <SBD Device Name> list
```
両方のノードの構成後の結果には、2 つのエントリが表示されます。
次のテストメッセージをノードの "いずれか" に送信します。
```
sbd  -d <SBD Device Name> message <node2> <message>
```
"2 つ目" のノード (node2) 上で次のコマンドを使用して、メッセージの状態を確認します。
```
sbd  -d <SBD Device Name> list
```
SBD の構成を採用するには、"両方" のノード上のファイル /etc/sysconfig/SBD を次のように更新します。
```
SBD_DEVICE=" <SBD Device Name>" 
SBD_WATCHDOG="yes" 
SBD_PACEMAKER="yes" 
SBD_STARTMODE="clean" 
SBD_OPTS=""
```
"プライマリノード" (node1) 上で次のコマンドを使用して、pacemaker サービスを開始します。
```
systemctl start pacemaker
```
pacemaker サービスが失敗する場合は、後述の「シナリオ 5: Pacemaker サービスが失敗する」セクションを参照してください。

クラスターにノードを参加させる

node2 上で次のコマンドを実行して、ノードをクラスターに参加させます。

ha-cluster-join

クラスターの参加中にエラーが発生した場合は、この記事で後述する「シナリオ 6: Node2 がクラスターに参加できない」セクションを参照してください。

クラスターを検証する

次のコマンドを使用して確認し、必要に応じて "両方" のノード上でクラスターを初めて開始します。
```
systemctl status pacemaker
systemctl start pacemaker
```
次のコマンドを実行して、"両方" のノードがオンラインであることを確認します。これは、クラスターのどのノードでも実行できます。
```
crm_mon
```
hawk にサインインして、クラスターの状態 https://\<node IP>:7630 を確認することもできます。既定のユーザーは hacluster であり、パスワードは linux です。必要であれば、passwd コマンドでパスワードを変更できます。

クラスターのプロパティとリソースを構成する

このセクションでは、クラスターリソースを構成する手順について説明します。この例では、次のリソースを設定しています。残りの部分は (必要に応じて) SUSE HA のガイドを参照して構成できます。

クラスターのブートストラップ
フェンスデバイス
Virtual IP address

この構成は "プライマリノード" でのみ行います。

クラスターのブートストラップファイルを作成し、次のテキストを追加して構成します。

sapprdhdb95:~ # vi crm-bs.txt
# enter the following to crm-bs.txt
property $id="cib-bootstrap-options" \
no-quorum-policy="ignore" \
stonith-enabled="true" \
stonith-action="reboot" \
stonith-timeout="150s"
rsc_defaults $id="rsc-options" \
resource-stickiness="1000" \
migration-threshold="5000"
op_defaults $id="op-options" \
timeout="600"

次のコマンドを使用して、構成をクラスターに追加します。
```
crm configure load update crm-bs.txt
```
次のようにリソースを追加し、ファイルを作成し、テキストを追加して、フェンスデバイスを構成します。
```
# vi crm-sbd.txt
# enter the following to crm-sbd.txt
primitive stonith-sbd stonith:external/sbd \
params pcmk_delay_max="15"
```
次のコマンドを使用して、構成をクラスターに追加します。
```
crm configure load update crm-sbd.txt
```

ファイルを作成して次のテキストを追加することで、リソースの仮想 IP アドレスを追加します。

# vi crm-vip.txt
primitive rsc_ip_HA1_HDB10 ocf:heartbeat:IPaddr2 \
operations $id="rsc_ip_HA1_HDB10-operations" \
op monitor interval="10s" timeout="20s" \
params ip="10.35.0.197"

次のコマンドを使用して、構成をクラスターに追加します。

crm configure load update crm-vip.txt

crm_mon コマンドを使用してリソースを検証します。

結果には、2 つのリソースが表示されます。

また、https://<ノード IP アドレス>:7630/cib/live/state で状態を確認することもできます

フェールオーバープロセスをテストする

フェールオーバープロセスをテストするには、次のコマンドを使用して node1 上の pacemaker サービスを停止します。
```
Service pacemaker stop
```
リソースは node2 にフェールオーバーされます。
pacemaker のサービスを node2 で停止します。するとリソースが node1 にフェールオーバーします。

フェールオーバー前の状態は次のとおりです。

フェールオーバー後の状態は次のとおりです。

トラブルシューティング

このセクションでは、設定時に発生する可能性のあるエラーシナリオについて説明します。

シナリオ 1:クラスターノードがオンラインではない

クラスターマネージャーでオンラインと表示されないノードがある場合は、これをオンラインにするために次の手順を試すことができます。

次のコマンドを使用して iSCSI サービスを開始します。
```
service iscsid start
```

次のコマンドを使用してその iSCSI ノードにサインインします。

iscsiadm -m node -l

次のような出力が表示されます。

sapprdhdb45:~ # iscsiadm -m node -l
Logging in to [iface: default, target: iqn.1992-08.com.netapp:hanadc11:1:t020, portal: 10.250.22.11,3260] (multiple)
Logging in to [iface: default, target: iqn.1992-08.com.netapp:hanadc11:1:t020, portal: 10.250.22.12,3260] (multiple)
Logging in to [iface: default, target: iqn.1992-08.com.netapp:hanadc11:1:t020, portal: 10.250.22.22,3260] (multiple)
Logging in to [iface: default, target: iqn.1992-08.com.netapp:hanadc11:1:t020, portal: 10.250.22.21,3260] (multiple)
Login to [iface: default, target: iqn.1992-08.com.netapp:hanadc11:1:t020, portal: 10.250.22.11,3260] successful.
Login to [iface: default, target: iqn.1992-08.com.netapp:hanadc11:1:t020, portal: 10.250.22.12,3260] successful.
Login to [iface: default, target: iqn.1992-08.com.netapp:hanadc11:1:t020, portal: 10.250.22.22,3260] successful.
Login to [iface: default, target: iqn.1992-08.com.netapp:hanadc11:1:t020, portal: 10.250.22.21,3260] successful.

シナリオ 2: yast2 で GUI が表示されない

この記事では、yast2 の GUI 画面で高可用性クラスターを設定します。 yast2 が図のような GUI ウィンドウで開かず、Qt エラーがスローされる場合は、次の手順で必要なパッケージをインストールします。グラフィカルウィンドウが開く場合は、この手順を省略できます。

Qt エラーの例を次に示します。

エラーメッセージが表示されたコンソールウィンドウの部分を示すスクリーンショット。

想定される出力の例を次に示します。

$[High Availability]$高可用性) と [Cluster]\(クラスター$ が強調表示された YaST Control Center を示すスクリーンショット。$

必ず "root" ユーザーとしてログインし、SMT セットアップでパッケージをダウンロードしてインストールします。
[yast]>[Software](ソフトウェア)>[Software Management](ソフトウェア管理)>[Dependencies](依存関係) に移動し、 [Install recommended packages](推奨パッケージのインストール) を選択します。

注意

両方のノードから yast2 の GUI を利用できるように、"両方" のノード上でこの手順を実行します。

次のスクリーンショットは、想定される画面を示しています。
[Dependencies](依存関係) で、 [Install Recommended Packages](推奨パッケージのインストール) を選択します。

$コンソールウィンドウのスクリーンショット。[Install Recommended Packages]$推奨パッケージのインストール$ が選択されている。$
変更内容を確認し [OK] を選択します。

パッケージのインストールが続行されます。
[次へ] を選択します。
[Installation Successfully Finished](インストールが正常に完了しました) 画面が表示されたら、 [Finish](完了) を選択します。
次のコマンドを使用して、libqt4 および libyui-qt パッケージをインストールします。
```
zypper -n install libqt4
```
```
zypper -n install libyui-qt
```
yast2 で GUI を表示できるようになります。

$[Software]$ソフトウェア$ と [Online Update]$オンライン更新$ が選択された YaST Control Center を示すスクリーンショット。$

シナリオ 3: yast2 に高可用性オプションが表示されない

高可用性オプションを yast2 Control Center に表示するには、他のパッケージもインストールする必要があります。

[Yast2]>[Software](ソフトウェア)>[Software Management](ソフトウェア管理) に移動します。次に、 [Software](ソフトウェア)>[Online Update](オンライン更新) を選択します。

$[Software]$ソフトウェア$ と [Online Update]$オンライン更新$ が選択された YaST Control Center を示すスクリーンショット。$
次の項目のパターンを選択します。次に [Accept](承認) を選択します。
- SAP HANA サーバーベース
- C/C++ コンパイラとツール
- 高可用性
- SAP アプリケーションサーバーベース
依存関係を解決するように変更されたパッケージの一覧で、 [Continue](続行) を選択します。

$依存関係を解決するように変更されたパッケージが表示された [Changed Packages]$変更されたパッケージ$ ダイアログを示すスクリーンショット。$
[Performing Installation](インストールの実行中) 状態ページで、 [Next](次へ) を選択します。

$[Performing Installation]$インストールの実行中$ 状態ページが示されたスクリーンショット。$
インストールが完了すると、インストールレポートが表示されます。 [完了] を選択します。

シナリオ 4: gcc アセンブリエラーが出て HANA のインストールが失敗する

HANA のインストールに失敗すると、次のようなエラーが発生することがあります。

オペレーティングシステムが gcc 5 のアセンブリを実行できる状態でないことを表すエラーのスクリーンショット。

この問題を解決するには、次のスクリーンショットに示すように、libgcc_sl と libstdc++6 のライブラリをインストールします。

必要なライブラリをインストールするコンソールウィンドウを示すスクリーンショット。

シナリオ 5: Pacemaker サービスが失敗する

pacemaker サービスを開始できない場合は、次の情報が表示されます。

sapprdhdb95:/ # systemctl start pacemaker
A dependency job for pacemaker.service failed. See 'journalctl -xn' for details.

sapprdhdb95:/ # journalctl -xn
-- Logs begin at Thu 2017-09-28 09:28:14 EDT, end at Thu 2017-09-28 21:48:27 EDT. --
Sep 28 21:48:27 sapprdhdb95 corosync[68812]: [SERV  ] Service engine unloaded: corosync configuration map
Sep 28 21:48:27 sapprdhdb95 corosync[68812]: [QB    ] withdrawing server sockets
Sep 28 21:48:27 sapprdhdb95 corosync[68812]: [SERV  ] Service engine unloaded: corosync configuration ser
Sep 28 21:48:27 sapprdhdb95 corosync[68812]: [QB    ] withdrawing server sockets
Sep 28 21:48:27 sapprdhdb95 corosync[68812]: [SERV  ] Service engine unloaded: corosync cluster closed pr
Sep 28 21:48:27 sapprdhdb95 corosync[68812]: [QB    ] withdrawing server sockets
Sep 28 21:48:27 sapprdhdb95 corosync[68812]: [SERV  ] Service engine unloaded: corosync cluster quorum se
Sep 28 21:48:27 sapprdhdb95 corosync[68812]: [SERV  ] Service engine unloaded: corosync profile loading s
Sep 28 21:48:27 sapprdhdb95 corosync[68812]: [MAIN  ] Corosync Cluster Engine exiting normally
Sep 28 21:48:27 sapprdhdb95 systemd[1]: Dependency failed for Pacemaker High Availability Cluster Manager
-- Subject: Unit pacemaker.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit pacemaker.service has failed.
--
-- The result is dependency.

sapprdhdb95:/ # tail -f /var/log/messages
2017-09-28T18:44:29.675814-04:00 sapprdhdb95 corosync[57600]:   [QB    ] withdrawing server sockets
2017-09-28T18:44:29.676023-04:00 sapprdhdb95 corosync[57600]:   [SERV  ] Service engine unloaded: corosync cluster closed process group service v1.01
2017-09-28T18:44:29.725885-04:00 sapprdhdb95 corosync[57600]:   [QB    ] withdrawing server sockets
2017-09-28T18:44:29.726069-04:00 sapprdhdb95 corosync[57600]:   [SERV  ] Service engine unloaded: corosync cluster quorum service v0.1
2017-09-28T18:44:29.726164-04:00 sapprdhdb95 corosync[57600]:   [SERV  ] Service engine unloaded: corosync profile loading service
2017-09-28T18:44:29.776349-04:00 sapprdhdb95 corosync[57600]:   [MAIN  ] Corosync Cluster Engine exiting normally
2017-09-28T18:44:29.778177-04:00 sapprdhdb95 systemd[1]: Dependency failed for Pacemaker High Availability Cluster Manager.
2017-09-28T18:44:40.141030-04:00 sapprdhdb95 systemd[1]: [/usr/lib/systemd/system/fstrim.timer:8] Unknown lvalue 'Persistent' in section 'Timer'
2017-09-28T18:45:01.275038-04:00 sapprdhdb95 cron[57995]: pam_unix(crond:session): session opened for user root by (uid=0)
2017-09-28T18:45:01.308066-04:00 sapprdhdb95 CRON[57995]: pam_unix(crond:session): session closed for user root

これを修正するには、 /usr/lib/systemd/system/fstrim.timer ファイルから次の行を削除します。

Persistent=true

削除される値 Persistent=true が含まれている fstrim ファイルを示すスクリーンショット。

シナリオ 6: Node2 がクラスターに参加できない

ha-cluster-join コマンドを使用して node2 を既存のクラスターに参加させる操作に問題がある場合は、次のようなエラーが表示されます。

ERROR: Can’t retrieve SSH keys from <Primary Node>

SSH キーが特定の IP アドレスから取得できないというエラーメッセージが表示されたコンソールウィンドウを示すスクリーンショット。

これを修正するには:

"両方のノード" 上で次のコマンドを実行します。

ssh-keygen -q -f /root/.ssh/id_rsa -C 'Cluster Internal' -N ''
cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys

1 つ目のノード上でコマンドを実行するコンソールウィンドウの部分を示すスクリーンショット。

2 つ目のノード上でコマンドを実行するコンソールウィンドウの部分を示すスクリーンショット。

node2 がクラスターに追加されたことを確認します。

次のステップ

SUSE HA のセットアップについて詳しくは、次の記事をご覧ください。

フェンス デバイスを使用した SUSE での高可用性セットアップ