障害復旧のための SAP HANA スケールアップマルチターゲットシステムレプリケーションの設定
概要
多様性を受け入れるオープンソースの強化 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat では、コード、ドキュメントにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。多様性を受け入れる用語に変更する取り組みの詳細は、Red Hat CTO である Chris Wright のメッセージ を参照してください。
Red Hat ドキュメントへのフィードバック (英語のみ) リンクのコピーリンクがクリップボードにコピーされました!
Red Hat ドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。
Jira からのフィードバック送信 (アカウントが必要)
第1章 概要 リンクのコピーリンクがクリップボードにコピーされました!
可用性に対する要求が高まっているため、データのコピーは 1 つだけでは十分ではありません。
ビジネスの継続性を確保するには、信頼性と可用性の高いアーキテクチャーを使用し、複数のシステム間でデータをレプリケートする必要があります。マルチターゲットシステムレプリケーションを使用すると、プライマリーシステムのデータ変更を複数のセカンダリーシステムにレプリケートできます。詳細は、SAP HANA Multitarget System Replication を参照してください。
このドキュメントでは、Automating SAP HANA Scale-Up System Replication using the RHEL HA Add-On の説明に従ってインストールされた 2 ノードクラスター上で、SAP HANA マルチターゲットシステムレプリケーションを使用して障害復旧用に追加のレプリケーションサイトを設定する方法について説明します。
設定の例を以下に示します。
初期設定は次のとおりです。
- プライマリーサイト 1 (DC1) をセカンダリーサイト 2 (DC2) にレプリケート
- プライマリーサイト 1 (DC1) をセカンダリーサイト 3 (DC3) にレプリケート
プライマリーサイトに障害が発生した場合、プライマリーサイトはセカンダリーサイト 2 (DC2)に切り替わり、以前のプライマリーサイト 1 (DC1)がセカンダリーサイトになります。
フェイルオーバーが発生すると、設定されたプライマリーサイトが 3 番目のサイトでも確実に切り替えられます。フェイルオーバー後の設定は次のとおりです。
- プライマリーが DC2 で稼働
- セカンダリーが DC1 で稼働 (DC2 から同期)
- セカンダリーが DC3 で稼働 (DC2 から同期)
node3 上の SAP HANA インスタンスは、フェイルオーバー中にこのインスタンスが実行されている限り、新しいプライマリーに自動的に再登録されます。
このドキュメントでは、プライマリーデータベースを 3 番目のサイトに切り替える例についても説明します。
クライアントをデータベースに接続するには、さらにネットワーク設定が必要であることに注意してください。ネットワーク設定はこのドキュメントの範囲外です。
詳細は、以下を参照してください。
第2章 パラメーター リンクのコピーリンクがクリップボードにコピーされました!
既存の 2 ノードクラスターの次のパラメーターが、3 番目のサイトのセットアップに使用されます。
| パラメーター | 例 | 説明 |
|---|---|---|
| SID | RH2 | HANA データベースのシステム ID |
| First SITE | DC1 | 1 番目のデータセンター/サイトの名前 |
| Second SITE | DC2 | 2 番目のデータセンター/サイトの名前 |
| Third SITE | DC3 | 3 番目のデータセンター/サイトの名前 |
| InstanceNr | 02 | HANA インスタンス番号 |
| <SID>adm uid | 1000 | SAP HANA 管理者ユーザーのユーザー ID (rh2adm) |
| sapsys gid | 980 | sapsys のグループ ID |
3 つの HANA インスタンスすべてが以下に同じ値を使用する必要があります。
- SID
- InstanceNr
- <SID>adm uid
- sapsys gid
第3章 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
ソリューションが機能するには、次の要件を満たす必要があります。
次のものがすべてのノードで同じである必要があります。
- CPU と RAM の数
- ソフトウェア設定
- RHEL リリース(少なくとも RHEL 8.6 が必要であることに注意してください)
- ファイアウォールの設定
- SAP HANA リリース (SAP HANA 2.0 SPS04 以降)
Pacemaker パッケージはクラスターノードにのみインストールされ、同じバージョンの resource-agents-sap-hana (0.162.1 以降) を使用する必要があります。
SAP HANA マルチターゲットシステムレプリケーション をサポートできるようにするには、SAP HANA マルチターゲットシステムレプリケーションの自動登録サポートの追加 を参照してください。また、以下を設定してください。
-
register_secondaries_on_takeover=trueの使用 -
log_mode=normalの使用
初期設定は、インストールガイド Automating SAP HANA Scale-Up System Replication using the RHEL HA Add-On に基づいています。
すべての SAP HANA インスタンスのシステムレプリケーション設定は、SAP 要件に基づいています。詳細は、SAP HANA Administration Guide に基づく SAP のガイドラインを参照してください。
第4章 インストール リンクのコピーリンクがクリップボードにコピーされました!
この章では、追加の SAP HANA インスタンスのインストールについて説明します。
4.1. フェイルオーバーテストで 2 ノードの基本インストールを確認する リンクのコピーリンクがクリップボードにコピーされました!
Automating SAP HANA Scale-Up System Replication using the RHEL HA Add-On に基づいてインストールを行ったことを確認します。
SAP HANA マルチターゲットシステムレプリケーション を使用できるようにするには、resource-agents-sap-hana のバージョンが 0.162.1 以降である必要があります。これは、以下のコマンドで確認できます。
rpm -q resource-agents-sap-hana
# rpm -q resource-agents-sap-hana
フェイルオーバーテストを実行すると、環境が機能していることを確認できます。SAPHana リソースを移動することもできます。これについては、move を使用した SAPHana リソースのフェイルオーバー でも説明されています。
4.2. 3 番目のサイトに SAP HANA をインストールする リンクのコピーリンクがクリップボードにコピーされました!
3 番目のサイトで、以下に示すように 2 ノード Pacemaker クラスター上の SAP HANA インスタンスと同じバージョンとパラメーターを使用して SAP HANA をインストールする必要もあります。
| パラメーター | 値 |
|---|---|
| SID | RH2 |
| InstanceNumber | 02 |
| <SID>adm user ID | rh2adm 999 |
| sapsys group ID | sapsys 999 |
SAP HANA のインストールは hdblcm を使用して行います。詳細は、hdbclm を使用した SAP HANA のインストール を参照してください。必要に応じて、Ansible を使用してインストールを実行することもできます。
本章の例では、以下を使用しています。
- サイト DC1 の hosts:clusternode1、サイト DC2 の clusternode2、およびサイト DC3 の remotehost3
- SID RH2
- adminUser rh2adm
4.3. 3 番目のサイトに SAP HANA システムレプリケーションをセットアップする リンクのコピーリンクがクリップボードにコピーされました!
既存のインストールでは、2 ノードクラスターのプライマリー SAP HANA インスタンスとセカンダリー SAP HANA インスタンスの間にすでに SAP HANA システムレプリケーションが設定されています。SAP HANA システムレプリケーションは、プライマリー SAP HANA データベースインスタンスが稼働していることが有効になっています。
本章では、3 番目の SAP HANA インスタンスを、ノード remotehost3 のノード DC3 で追加のセカンダリー HANA システムレプリケーションサイトとして登録する方法を説明します。この手順は、ノード clusternode2 での元のセカンダリー HANA インスタンス(DC2)の登録に似ています。詳細は、以降の章で説明します。さらに詳しい情報が必要な場合は、General Prerequisites for Configuring SAP HANA System Replication も参照してください。
4.3.1. プライマリーデータベースの確認 リンクのコピーリンクがクリップボードにコピーされました!
他のデータベースが実行中であり、システムのレプリケーションが適切に動作していることを確認する必要があります。以下を参照してください。
プライマリー HANA インスタンスは、以下で検出できます。
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "primary masters|^mode" mode: primary
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "primary masters|^mode"
mode: primary
4.3.2. データベースキーのコピー リンクのコピーリンクがクリップボードにコピーされました!
新しいセカンダリー HANA インスタンスを登録する前に、プライマリー HANA インスタンスのデータベースキーを新しい追加の HANA レプリケーションサイトにコピーする必要があります。この例では、3 番目のサイトのホスト名は remotehost3 です。
たとえば、プライマリーノード clusternode1 で以下を実行します。
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY
4.3.3. 追加の HANA インスタンスをセカンダリー HANA レプリケーションサイトとして登録 リンクのコピーリンクがクリップボードにコピーされました!
プライマリーデータベース を実行しているノードの名前を確認する必要があります。
登録を監視するには、プライマリーノードの別のターミナルで以下のコマンドを実行します。
clusternode1:rh2adm> watch python
/usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/python_support/systemReplicationStatus.py
clusternode1:rh2adm> watch python
/usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/python_support/systemReplicationStatus.py
これにより、進行状況とエラー (発生した場合) が表示されます。
3 番目のサイトの HANA インスタンスを追加のセカンダリー SAP HANA インスタンスとして登録するには、3 番目のサイトのホスト node3 で次のコマンドを実行します。
remotehost3:rh2adm> hdbnsutil -sr_register --name=DC3 --remoteHost=clusternode1 --remoteInstance=${TINSTANCE} --replicationMode=async --operationMode=logreplay --online
remotehost3:rh2adm> hdbnsutil -sr_register --name=DC3 --remoteHost=clusternode1 --remoteInstance=${TINSTANCE} --replicationMode=async --operationMode=logreplay --online
この例では、DC3 は 3 番目のサイトの名前、clusternode1 はプライマリーノードのホスト名です。
データベースインスタンスがすでに実行されている場合は、停止する必要はありません。オプション --online を使用すると、オンライン中にインスタンスが登録されます。インスタンスの必要な再起動 (停止と起動) は、hdbnsutil 自体によって開始されます。
オプション --online は、HANA インスタンスがオンラインでもオフラインでも機能します(このオプションは SAP HANA 2.0 SPS04 以降で利用可能です)。
データベースインスタンスがオフラインの場合は、3 番目のノードを登録した後にデータベースインスタンスを起動する必要があります。詳細は、SAP HANA システムレプリケーション を参照してください。
4.3.4. SAP HANA マルチターゲットシステムレプリケーションの自動登録サポートの追加 リンクのコピーリンクがクリップボードにコピーされました!
register_secondaries_on_takeover = true という SAP HANA システムレプリケーションオプションを使用しています。これにより、以前のプライマリーサイトと他のセカンダリーサイトの間でフェイルオーバーが発生した場合に、セカンダリー HANA インスタンスを新しいプライマリーサイトに自動的に再登録します。このオプションは、すべての潜在的なプライマリーサイトの global.ini ファイルに追加する必要があります。
すべての HANA インスタンスの global.ini に次のエントリーが含まれている必要があります。
[system_replication] register_secondaries_on_takeover = true
[system_replication]
register_secondaries_on_takeover = true
次の 2 つの章では、global.ini 設定について詳しく説明します。
パラメーターにもかかわらず、フェイルオーバーの開始時に 3 番目のノード上の追加のセカンダリー HANA インスタンスが 停止 している場合は、この HANA インスタンスを手動で再登録する必要があります。
4.3.5. Pacemaker ノードでの global.ini の設定 リンクのコピーリンクがクリップボードにコピーされました!
Pacemaker クラスターによって管理される SAP HANA インスタンスの global.ini に、オプション register_secondaries_on_takeover = true を追加する必要があります。ファイル global.ini は、常にそれぞれのノードで編集し、別のノードからファイルをコピーしないでください。
global.ini ファイルは、サイトの HANA インスタンスが処理を停止した場合にのみ編集してください。
rh2adm ユーザーとして global.ini を編集します。
clusternode1:rh2adm> vim /usr/sap/${SAPSYSTEMNAME}/SYS/global/hdb/custom/config/global.ini
clusternode1:rh2adm> vim /usr/sap/${SAPSYSTEMNAME}/SYS/global/hdb/custom/config/global.ini
以下に例を示します。
このオプションは、SAP HANA データベースインスタンスが起動するとすぐにアクティブになります。
4.3.6. 3 番目のサイトで global.ini を設定する リンクのコピーリンクがクリップボードにコピーされました!
<sid>adm ユーザーとして global.ini を編集します。
remotehost3:rh2adm> vim /usr/sap/${SAPSYSTEMNAME}/SYS/global/hdb/custom/config/global.ini
remotehost3:rh2adm> vim /usr/sap/${SAPSYSTEMNAME}/SYS/global/hdb/custom/config/global.ini
remotehost3 では、ha_dr_provider_SAPHanaSR セクションは使用されません。
remotehost3 の global.ini の例:
4.3.7. インストールの検証 リンクのコピーリンクがクリップボードにコピーされました!
インストール後、すべての HANA インスタンスが稼働しているか、および HANA システムレプリケーションがそれらのインスタンス間で動作していることを確認する必要があります。最も簡単な方法は、システムレプリケーション ステータスの確認 で説明されているように、systemReplicationStatus を確認 することです。
詳細は、データベースステータスの確認 も参照してください。
HANA システムレプリケーションが正しく機能するには、log_mode パラメーターが normal に設定されていることを確認してください。詳細は、SAP HANA データベースの log_mode の確認 を参照してください。
設定が想定どおりに機能していることを確認するには、以下の章の説明に従って テストケース を実行してください。
第5章 テストケース リンクのコピーリンクがクリップボードにコピーされました!
インストールの完了後、いくつかの基本テストを実行してインストールを確認し、SAP HANA マルチターゲットシステムレプリケーションがどのように動作するか、および障害からどのように回復するかを検証することを推奨します。実稼働を開始する前に、このようなテストケースを実行することを常に推奨します。可能であれば、実稼働を開始する前にテスト環境を準備して変更を検証することを推奨します。可能であれば、実稼働環境に変更を適用する前に、テスト環境を準備して変更を確認することもできます。
すべてのケースで、次の項目が説明されています。
- テストの内容
- テストの前提条件
- テストの手順
- テストのモニタリング
- テストの開始
- 期待される結果
- 初期状態に戻す方法
クラスターによって管理される HANA インスタンスで以前のプライマリー HANA レプリケーションサイトを新しいセカンダリー HANA レプリケーションサイトとして自動的に登録するには、SAPHana リソースでオプション AUTOMATED_REGISTER=true を使用できます。詳細は、AUTOMATED_REGISTER を参照してください。
例で使用される HA クラスターノードの名前と(括弧内)以下は、以下のとおりです。
- Clusternode1 (DC1)
- Clusternode2 (DC2)
- remotehost3 (DC3)
HANA インスタンスとクラスターの設定には、次のパラメーターが使用されます。
- SID=RH2
- INSTANCENUMBER
- CLUSTERNAME=cluster1
clusternode1-2、remotehost3 をテスト環境の /etc/hosts のエイリアスとして使用することもできます。
その後、例や前提条件の追加チェックなど、テストについてさらに詳しく説明します。最後に、さらなるテストに備えて環境をクリーンアップする方法の例も示します。
clusternode1-2 と remotehost3 の距離が長すぎる場合は、-replicationMode=syncmem の代わりに -replcationMode=async を使用する必要があります。適切なオプションを選択する前に、SAP HANA の管理者も確認してください。
5.1. テストの準備 リンクのコピーリンクがクリップボードにコピーされました!
テストを実行する前に、環境全体が正常で適切な状態である必要があります。
次のコマンドで、クラスターとデータベースを確認する必要があります。
-
pcs status --full -
python $DIR_EXECUTABLE/python_support/systemReplicationStatus.py -
df -h
pcs status --full の例は、pcs status を使用したクラスターのステータスの確認 にあります。"Migration Summary" に警告または以前の失敗がある場合は、テストを開始する前にクラスターをクリーンアップする必要があります。
pcs resource clear SAPHana_RH2_02-clone
[root@clusternode1]# pcs resource clear SAPHana_RH2_02-clone
クラスターのクリーンアップ で、クリーンアップを実行するその他の方法を説明しています。重要なのは、クラスターとすべてのリソースが起動していることです。
クラスターのほかに、データベースも稼働しており、同期している必要があります。データベースのステータスが適切であることを確認する最も簡単な方法は、システムのレプリケーションステータスを確認することです。レプリケーションステータス も参照してください。これはプライマリーデータベースで確認する必要があります。
プライマリーノードを検出するには、プライマリーデータベースの検出 をオンにするか、次のコマンドを使用します。
pcs status | grep -E "Promoted|Master" hdbnsutil -sr_stateConfiguration
[root@clusternode1]# pcs status | grep -E "Promoted|Master"
[root@clusternode1]# hdbnsutil -sr_stateConfiguration
次のコマンドを実行して、ファイルシステムに十分なスペースがあるかどうかを確認します。
df -h
[root@clusternode1]# df -h
続行する前に、システムチェック のガイドラインにも従ってください。環境がクリーンであれば、テストを実行する準備ができています。
5.2. 環境のモニタリング リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、テスト中の環境のモニタリングに焦点を当てます。このセクションでは、変更を確認するために必要なモニターのみを説明します。これらのモニターは専用のターミナルから実行することを推奨します。テスト中に変更を検出できるようにするには、テストを開始する前にモニタリングを開始することを推奨します。
便利なコマンド セクションで、さらに多くの例を紹介しています。
5.2.1. プライマリーノードの検出 リンクのコピーリンクがクリップボードにコピーされました!
プライマリーノードを検出してフェイルオーバーを監視するか、プライマリーノードで実行したときにレプリケーションステータスに関する情報のみを提供する特定のコマンドを実行する必要があります。
プライマリーノードを検出するには、<sid>adm ユーザーとして次のコマンドを実行します。
clusternode1:rh2adm> watch -n 5 'hdbnsutil -sr_stateConfiguration | egrep -e "primary masters|^mode"'
clusternode1:rh2adm> watch -n 5 'hdbnsutil -sr_stateConfiguration | egrep -e "primary masters|^mode"'
clusternode2 がプライマリーデータベースである場合の出力例:
mode: syncmem primary masters: clusternode2
mode: syncmem
primary masters: clusternode2
プライマリーデータベースを実行するノードの出力は次のとおりです。
mode: primary
mode: primary
5.2.2. レプリケーションステータスの確認 リンクのコピーリンクがクリップボードにコピーされました!
レプリケーションのステータスは、プライマリーデータベースノードとセカンダリーデータベースノード間の関係と、レプリケーションの現在のステータスを示します。
レプリケーションのステータスを確認するには、<sid>adm ユーザーとして次のコマンドを実行します。
clusternode1:rh2adm> hdbnsutil -sr_stateConfiguration
clusternode1:rh2adm> hdbnsutil -sr_stateConfiguration
システムのレプリケーションステータスの変更を永続的に監視する場合は、次のコマンドを実行してください。
clusternode1:rh2adm> watch -n 5 'python /usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'
clusternode1:rh2adm> watch -n 5 'python /usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'
この例では、現在の戻りコードも確認します。
戻りコード (ステータス) が 15 である限り、レプリケーションのステータスは正常です。他の戻りコードは次のとおりです。
- 10: NoHSR
- 11: Error
- 12: Unknown
- 13: Initializing
- 14: Syncing
- 15: Active
新しいセカンダリーを登録する場合は、プライマリーノード上の別のウィンドウでコマンドを実行し、レプリケーションの進行状況を確認できます。フェイルオーバーを監視する場合は、前のプライマリーデータベースサーバーと新しいプライマリーデータベースサーバーで並行してコマンドを実行できます。詳細は、SAP HANA システムレプリケーションのステータスの確認 を参照してください。
5.2.3. /var/log/messages のエントリーの確認 リンクのコピーリンクがクリップボードにコピーされました!
Pacemaker は、/var/log/messages ファイルに多くの情報を書き込みます。フェイルオーバー中に、大量のメッセージがこのメッセージファイルに書き込まれます。SAP HANA リソースエージェントに応じて重要なメッセージのみを追跡できるようにするには、Pacemaker SAP リソースの詳細なアクティビティーをフィルターすると便利です。単一のクラスターノードのメッセージファイルを確認するだけで十分です。
たとえば、次のエイリアスを使用できます。
tmsl='tail -1000f /var/log/messages | egrep -s "Setting master-rsc_SAPHana_$SAPSYSTEMNAME_HDB${TINSTANCE}|sr_register|WAITING4LPA|PROMOTED|DEMOTED|UNDEFINED|master_walk|SWAIT|WaitforStopped|FAILED|LPT"'
[root@clusternode1]# tmsl='tail -1000f /var/log/messages | egrep -s "Setting master-rsc_SAPHana_$SAPSYSTEMNAME_HDB${TINSTANCE}|sr_register|WAITING4LPA|PROMOTED|DEMOTED|UNDEFINED|master_walk|SWAIT|WaitforStopped|FAILED|LPT"'
別のウィンドウで tmsl を実行して、テストの進捗を監視します。フェイルオーバーと同期状態の監視 の例も参照してください。
5.2.4. クラスターの状態 リンクのコピーリンクがクリップボードにコピーされました!
クラスターのステータスを確認するにはいくつかの方法があります。
クラスターが実行中かどうかを確認します。
-
pcs cluster status
-
クラスターとすべてのリソースを確認します。
-
pcs status
-
クラスター、すべてのリソース、およびすべてのノード属性を確認します。
-
pcs status --full
-
リソースのみを確認します。
-
pcs resource
-
pcs status --full コマンドを使用すると、必要な情報がすべて得られます。変更を監視するには、このコマンドを watch と一緒に実行できます。
watch pcs status --full
[root@clusternode1]# watch pcs status --full
出力例とその他のオプションについては、クラスターのステータスの確認 を参照してください。
5.2.5. 残留物の検出 リンクのコピーリンクがクリップボードにコピーされました!
環境が次のテストを実行できる状態にあることを確認するには、以前のテストで残ったものを修正または削除する必要があります。
stonithは、クラスター内のノードをフェンスするために使用します。-
検出:
[root@clusternode1]# pcs stonith history -
修正:
[root@clusternode1]# pcs stonith cleanup
-
検出:
複数のプライマリーデータベース:
Detect:
clusternode1:rh2adm> hdbnsutil -sr_stateConfiguration | grep -i primary同じプライマリーを持つすべてのノードを識別する必要があります。
-
修正: %
--force_full_replicaオプションを使用して、正しくないプライマリーを登録し直します。
移動により発生した場所の制約:
検出:
[root@clusternode1]# pcs constraint location警告セクションを確認します。
-
修正:
[root@clusternode1]# pcs resource clear <clone-resource-which was moved>
セカンダリーレプリケーション関係:
-
検出:プライマリーデータベースで
clusternode1:rh2adm> python $DIR_EXECUTABLE/python_support/systemReplicationStatus.py を実行します。 - 修正: セカンダリーデータベースを登録解除して再登録します。
-
検出:プライマリーデータベースで
siteReplicationMode (すべての SAP HANA ノードで同じ出力)を確認します。
-
clusternode1:rh2adm> hdbnsutil -sr_state --sapcontrol=1 |grep site.*Mode
-
Pcs プロパティー:
-
検出:
[root@clusternode1]# pcs property config -
修正:
[root@clusternode1]# pcs property set <key=value>
-
検出:
maintenance-modeをクリアします。-
[root@clusternode1]# pcs property set maintenance-mode=false
-
log_mode:
Detect:
clusternode1:rh2adm> python systemReplicationStatus.py通常は
log_modeが必要であるという応答がレプリケーションのステータスで返されます。log_mode は、hdbsql を使用した Inifile の内容の確認で説明されている方法で検出できます。-
修正:
log_modeを normal に変更し、プライマリーデータベースを再起動します。
CIB エントリー:
検出: クラスター情報ベース内の SFAIL エントリー。
CIB エントリーを検索して削除するには、クラスターの整合性の確認 を参照してください。
クリーンアップ/クリア:
検出:
[root@clusternode1]# pcs status --full場合によっては、エラーや警告が表示されることがあります。リソースをクリーンアップ/クリアしても、すべてが正常であれば何も起こりません。次のテストを実行する前に、環境をクリーンアップできます。
修正の例:
[root@clusternode1]# pcs resource clear <name-of-the-clone-resource>[root@clusternode1]# pcs resource cleanup <name-of-the-clone-resource>
これは、既存の環境に問題があるかどうかをチェックする場合にも便利です。
詳細は、便利なコマンド を参照してください。
5.3. テスト 1: プライマリーノードをアクティブな 3 番目のサイトを使用してフェイルオーバーする リンクのコピーリンクがクリップボードにコピーされました!
| テストの内容 | 3 番目のサイトの自動再登録。 クリア後に同期状態が SOK に変わる。 |
| テストの前提条件 |
|
| テストの手順 |
|
| テストのモニタリング |
3 番目のサイトで、
セカンダリーノードで、root として |
| テストの開始 | クラスターコマンドを実行します。
|
| 期待される結果 | サイト 3 のモニターコマンドでは、プライマリーマスターが clusternode1 から clusternode2 に変わります。
リソースをクリアすると、同期状態が |
| 初期状態に戻す方法 | テストを 2 回実行します。 |
(*)
remotehost3:rh2adm> watch hdbnsutil -sr_state [root@clusternode1]# tail -1000f /var/log/messages |egrep -e ‘SOK|SWAIT|SFAIL’
remotehost3:rh2adm>
watch hdbnsutil -sr_state
[root@clusternode1]# tail -1000f /var/log/messages |egrep -e ‘SOK|SWAIT|SFAIL’
詳細な説明:
clusternode1 または clusternode2 で、クラスターの初期状態を root として確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力は、HANA がプライマリー SAP HANA サーバーである clusternode1 で昇格されていることを示しており、クローンリソースの名前が昇格可能な SAPHana_RH2_02-clone であることを示しています。
テスト中に別のウィンドウでこれを実行して、変更を確認できます。watch pcs status --full
[root@clusternode1]# watch pcs status --fullCopy to Clipboard Copied! Toggle word wrap Toggle overflow SAP HANA クローンリソースの名前を識別する別の方法は次のとおりです。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プライマリーサーバーの変更を確認するには、テストを開始する前に、別のターミナルウィンドウの remotehost3 でモニタリングを開始します。
remotehost3:rh2adm> watch 'hdbnsutil -sr_state | grep "primary masters"
remotehost3:rh2adm> watch 'hdbnsutil -sr_state | grep "primary masters"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力は以下のようになります。
Every 2.0s: hdbnsutil -sr_state | grep "primary masters" remotehost3: Mon Sep 4 08:47:21 2023 primary masters: clusternode1
Every 2.0s: hdbnsutil -sr_state | grep "primary masters" remotehost3: Mon Sep 4 08:47:21 2023 primary masters: clusternode1Copy to Clipboard Copied! Toggle word wrap Toggle overflow テスト中に、予想される出力は clusternode2 に変わります。
上記で検出されたクローンリソースを clusternode2 に移動して、テストを開始します。
pcs resource move SAPhana_RH2_02-clone clusternode2
[root@clusternode1]# pcs resource move SAPhana_RH2_02-clone clusternode2Copy to Clipboard Copied! Toggle word wrap Toggle overflow remotehost3 のモニターの出力は、以下に変わります。
Every 2.0s: hdbnsutil -sr_state | grep "primary masters" remotehost3: Mon Sep 4 08:50:31 2023 primary masters: clusternode2
Every 2.0s: hdbnsutil -sr_state | grep "primary masters" remotehost3: Mon Sep 4 08:50:31 2023 primary masters: clusternode2Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pacemaker は、クローンリソースを移動するための場所の制約を作成します。これは手動で削除する必要があります。制約は、以下を使用して確認できます。
pcs constraint location
[root@clusternode1]# pcs constraint locationCopy to Clipboard Copied! Toggle word wrap Toggle overflow この制約は削除する必要があります。
クローンリソースをクリアして、場所の制約を削除します。
pcs resource clear SAPhana_RH2_02-clone Removing constraint: cli-prefer-SAPHana_RH2_02-clone
[root@clusternode1]# pcs resource clear SAPhana_RH2_02-clone Removing constraint: cli-prefer-SAPHana_RH2_02-cloneCopy to Clipboard Copied! Toggle word wrap Toggle overflow リソースをクリーンアップします。
pcs resource cleanup SAPHana_RH2_02-clone Cleaned up SAPHana_RH2_02:0 on clusternode2 Cleaned up SAPHana_RH2_02:1 on clusternode1 Waiting for 1 reply from the controller ... got reply (done)
[root@clusternode1]# pcs resource cleanup SAPHana_RH2_02-clone Cleaned up SAPHana_RH2_02:0 on clusternode2 Cleaned up SAPHana_RH2_02:1 on clusternode1 Waiting for 1 reply from the controller ... got reply (done)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
テストの結果
- remotehost3 の "primary masters" モニターには、新しいプライマリーノードにすぐに切り替わったことがわかるはずです。
-
クラスターのステータスを確認すると、元のセカンダリーがプロモートされ、元のプライマリーが再登録されます。また、
Clone_StateがPromotedからUnknown、WAITINGFORLPA、DEMOTEDに変わります。 -
セカンダリーは、フェイルオーバー後に初めて
SAPHanaモニターが起動するときに、sync_stateをSFAILに変更します。既存の場所の制約のため、リソースをクリアする必要があります。しばらくするとセカンダリーのsync_stateが再びSOKに変わります。 - セカンダリーがプロモートされます。
初期状態を復元するには、次のテストを実行するだけです。テストが完了したら、クリーンアップ を実行してください。
5.4. テスト 2: プライマリーノードをパッシブな 3 番目のサイトを使用してフェイルオーバーする リンクのコピーリンクがクリップボードにコピーされました!
| テストの内容 | 停止した 3 番目のサイトの再登録はありません。 3 番目のサイトが停止している場合でも、フェイルオーバーが機能する。 |
| テストの前提条件 |
|
| テストの手順 |
|
| テストの開始 |
クラスターコマンド |
| 期待される結果 | DC3 には何も変化がありません。SAP HANA システムレプリケーションは古い関係にとどまります。 |
| 初期状態に戻す方法 | 新しいプライマリーに DC3 を再登録し、SAP HANA を起動します。 |
詳細な説明:
clusternode1 または clusternode2 で、クラスターの初期状態を root として確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例の出力は、HANA がプライマリー SAP HANA サーバーである clusternode1 で昇格され、クローンリソースの名前が
SAPHana_RH2_02-cloneであることを表しています。HANA より前に test 3 を実行すると、clusternode2 で昇格される可能性があります。remotehost3 でデータベースを停止します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow remotehost3 でプライマリーデータベースを確認します。
remotehost3:rh2adm> hdbnsutil -sr_stateConfiguration| grep -i "primary masters" primary masters: clusterclusternode2
remotehost3:rh2adm> hdbnsutil -sr_stateConfiguration| grep -i "primary masters" primary masters: clusterclusternode2Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターノードのクラスター内の現在のプライマリーを確認します。
pcs resource | grep Masters * Masters: [ clusternode2 ][root@clusterclusternode1]# pcs resource | grep Masters * Masters: [ clusternode2 ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow sr_stateを確認して、SAP HANA システムレプリケーションの関係を確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
SAP HANA システムレプリケーション関係には、DC2 および DC3 に複製されるプライマリー(DC1)が 1 つあります。ダウンしている remotehost3 でのレプリケーション関係は、以下を使用して表示できます。
offline である remotehost3 上のデータベースは、global.ini ファイルのエントリーをチェックします。
テストを開始:クラスター内でフェイルオーバーを開始し、
SAPHana-clone-resourceの例を移動します。pcs resource move SAPHana_RH2_02-clone clusternode2
[root@clusternode1]# pcs resource move SAPHana_RH2_02-clone clusternode2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記SAPHana が clusternode2 でプロモートされている場合は、クローンリソースを clusternode1 に移動する必要があります。この例では、SAPHana が clusternode1 で昇格されていることを想定しています。
何も出力されません。以前のテストと同様に場所の制約が作成されるため、次のように表示できます。
pcs constraint location Location Constraints: Resource: SAPHana_RH2_02-clone Enabled on: Node: clusternode1 (score:INFINITY) (role:Started)[root@clusternode1]# pcs constraint location Location Constraints: Resource: SAPHana_RH2_02-clone Enabled on: Node: clusternode1 (score:INFINITY) (role:Started)Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターが再び見える場合でも、制約が削除されない限り、この制約によって別のフェイルオーバーが回避されます。もう 1 つの方法は、リソースをクリアすることです。
リソースをクリアします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow リソースをクリーンアップします。
pcs resource cleanup SAPHana_RH2_02-clone Cleaned up SAPHana_RH2_02:0 on clusternode2 Cleaned up SAPHana_RH2_02:1 on clusternode1 Waiting for 1 reply from the controller ... got reply (done)
[root@clusternode1]# pcs resource cleanup SAPHana_RH2_02-clone Cleaned up SAPHana_RH2_02:0 on clusternode2 Cleaned up SAPHana_RH2_02:1 on clusternode1 Waiting for 1 reply from the controller ... got reply (done)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 現在の状態を確認します。同期する必要があるレプリケーションステータスを表示する方法は 3 つあります。remotehost3 のプライマリーから始めます。
remotehost3:rh2adm> hdbnsutil -sr_stateConfiguration| grep -i primary active primary site: 1 primary masters: clusternode1
remotehost3:rh2adm> hdbnsutil -sr_stateConfiguration| grep -i primary active primary site: 1 primary masters: clusternode1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力には、プライマリーを clusternode2 に移動するためにテストを開始する前にプライマリーであったサイト 1 または clusternode1 が表示されます。次に、新しいプライマリーでシステムレプリケーションのステータスを確認します。まず、新しいプライマリーを検出します。
pcs resource | grep Master * Masters: [ clusternode2 ][root@clusternode1]# pcs resource | grep Master * Masters: [ clusternode2 ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、remotehost3を再登録する必要がある不整合があります。再度テストを実行すると、プライマリーを元の clusternode1 に戻す可能性があります。この場合、システムのレプリケーションが機能しているかどうかを特定する 3 番目の方法があります。プライマリーノードで、clusternode2 が実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力に remotehost3 が表示されない場合は、remotehost3 を再登録する必要があります。登録する前に、登録の進行状況を監視するためにプライマリーノードで以下を実行してください。
clusternode2:rh2adm> watch python $DIR_EXECUTABLE/python_support/systemReplicationStatus.py
clusternode2:rh2adm> watch python $DIR_EXECUTABLE/python_support/systemReplicationStatus.pyCopy to Clipboard Copied! Toggle word wrap Toggle overflow これで、以下のコマンドを使用して remotehost3 を再登録できるようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow remotehost3 のデータベースがまだ開始されていない場合でも、システムレプリケーションステータスの出力に 3 番目のサイトが表示されます。
remotehost3 でデータベースを起動すると、登録を終了できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
上記で起動したモニターには、remotehost3 の同期がすぐに表示されます。
- 元に戻すには、テストを再度実行します。任意のテストでは、プライマリーをノードに切り替えることです。これは、remotehost3 の global.ini で設定され、データベースを開始します。データベースは稼働する場合もありますが、再登録されない限り、システムレプリケーションのステータスの出力には表示されません。
詳細は、SAP HANA システムレプリケーションステータスの確認 も参照してください。
5.5. テスト 3: プライマリーノードを 3 番目のサイトにフェイルオーバーする リンクのコピーリンクがクリップボードにコピーされました!
| テストの内容 | プライマリーを 3 番目のサイトにフェイルオーバーします。 セカンダリーが 3 番目のサイトに再登録される。 |
| テストの前提条件 |
|
| テストの手順 |
回復できるように、クラスターを
|
| テストの開始 |
SAP HANA commandon remotehost3: |
| テストのモニタリング |
3 番目のサイトで |
| 期待される結果 |
|
| 初期状態に戻す方法 |
詳細な説明:
データベースの確認 を使用してデータベースが実行されているかどうかを 確認 し、レプリケーションのステータスを確認します。
clusternode2:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters"
clusternode2:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
出力の例を以下に示します。
mode: syncmem primary masters: clusternode1
mode: syncmem
primary masters: clusternode1
この場合、プライマリーデータベースは clusternode1 です。clusternode1 でこのコマンドを実行すると、以下が得られます。
mode: primary
mode: primary
このプライマリーノードで、システムレプリケーションのステータスを表示することもできます。以下のようになります。
- これで適切な環境が完成し、別のウィンドウで 3 つのノードすべてでのシステムレプリケーションステータスの監視を開始できます。
3 台のモニターは、テストを開始する前に起動する必要があります。テストが実行されると、出力は変わります。したがって、テストが完了していない限り、そのまま実行します。
古いプライマリーノードで、clusternode1 はテスト中に別のウィンドウで実行されていました。
clusternode1:rh2adm> watch -n 5 'python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?`
clusternode1:rh2adm> watch -n 5 'python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?`
clusternode1 の出力は以下のようになります。
remotehost3 で、同じコマンドを実行します。
remotehost3:rh2adm> watch -n 5 'python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'
remotehost3:rh2adm> watch -n 5 'python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'
応答は以下のようになります。
this system is either not running or not primary system replication site
this system is either not running or not primary system replication site
テストがフェイルオーバーを開始した後、出力は変更されます。出力は、テストが開始される前のプライマリーノードの例と似ています。
2 番目のノードの起動時に、以下が行われます。
clusternode2:rh2adm> watch -n 10 'hdbnsutil -sr_state | grep masters'
clusternode2:rh2adm> watch -n 10 'hdbnsutil -sr_state | grep masters'
これにより、現在のマスター clusternode1 が表示され、フェイルオーバーの開始直後に切り替えられます。
-
すべてが正しく設定されていることを確認するには、
global.iniも確認してください。 -
DC1、DC2、DC3 の
global.iniを確認します。
3 つのすべてのノードで、global.ini に以下を含める必要があります。
[persistent] log_mode=normal [system_replication] register_secondaries_on_takeover=true
[persistent]
log_mode=normal
[system_replication]
register_secondaries_on_takeover=true
以下のように global.ini を編集できます。
clusternode1:rh2adm>vim /usr/sap/$SAPSYSTEMNAME/SYS/global/hdb/custom/config/global.ini
clusternode1:rh2adm>vim /usr/sap/$SAPSYSTEMNAME/SYS/global/hdb/custom/config/global.ini
[オプション] クラスターを
maintenance-modeにします。pcs property set maintenance-mode=true
[root@clusternode1]# pcs property set maintenance-mode=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow テスト中に、
maintenance-modeを設定せずにフェイルオーバーが機能することがわかります。最初のテストはなしで実行できます。リカバリーはする必要がありますが、紹介したいだけなので、使用と無しに動作します。プライマリーに関するオプションにはアクセスできません。テストを開始します。DC3 にフェイルオーバーします。remotehost3 では、次を実行してください。
remotehost3:rh2adm> hdbnsutil -sr_takeover done.
remotehost3:rh2adm> hdbnsutil -sr_takeover done.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
テストが開始されましたが、以前に開始されたモニターの出力を確認してください。
clusternode1 では、システムレプリケーションステータスで remotehost3 および clusternode2 (DC2)との関係が失われます。
クラスターはこの動作を認識しません。システムレプリケーションのステータスの戻りコードを確認すると、Returncode 11 はエラーを示し、何らかの問題があることを示します。アクセスがあれば、今すぐ maintenance-mode に入るとよいでしょう。
remotehost3 が新しいプライマリーになり、clusternode2 (DC2)が自動的に remotehost3 で新しいプライマリーとして登録されます。
remotehost3 のシステムレプリケーション状態の出力例。
戻りコード 15 では、すべて問題ありませんが、clusternode1 がありません。これは手動で再登録する必要があります。以前のプライマリー clusternode1 はリストされていないため、レプリケーションの関係は失われます。
-
maintenance-modeを設定します。
クラスターの 1 つのノードでクラスターに maintenance-mode を設定する前にまだ行っていない場合は、以下のコマンドを使用します。
pcs property set maintenance-mode=true
[root@clusternode1]# pcs property set maintenance-mode=true
maintenance-mode がアクティブであるかどうかを確認するには、以下のコマンドを実行します。
リソースは管理対象外で表示されます。これは、クラスターが maintenance-mode=true であることを示しています。仮想 IP アドレスは、clusternode1 で引き続き起動されます。別のノードでこの IP を使用する場合は、maintanence-mode=true を設定する前に vip_RH2_02_MASTER を無効にしてください。
pcs resource disable vip_RH2_02_MASTER
[root@clusternode1]# pcs resource disable vip_RH2_02_MASTER
clusternode1 を再登録すると、clusternode1 で sr_state を確認すると、DC2 にのみ関係が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ただし、DC2 を確認すると、プライマリーデータベースサーバーは DC3 になります。そのため、DC1 からの情報は正しくありません。
clusternode2:rh2adm> hdbnsutil -sr_state
clusternode2:rh2adm> hdbnsutil -sr_stateCopy to Clipboard Copied! Toggle word wrap Toggle overflow DC1 でシステムレプリケーションのステータスを確認すると、戻りコードは不明な 12 になります。したがって、DC1 を再登録する必要があります。
このコマンドを使用して、以前のプライマリー clusternode1 を remotehost3 の新しいセカンダリーとして登録できます。
clusternode1:rh2adm> hdbnsutil -sr_register --remoteHost=remotehost3 --remoteInstance=${TINSTANCE} --replicationMode=async --name=DC1 --remoteName=DC3 --operationMode=logreplay --online
clusternode1:rh2adm> hdbnsutil -sr_register --remoteHost=remotehost3 --remoteInstance=${TINSTANCE} --replicationMode=async --name=DC1 --remoteName=DC3 --operationMode=logreplay --online
登録が完了すると、3 つのサイトがすべてレプリケートされ、ステータス (戻りコード) が 15 に変わります。これが失敗した場合は、DC1 および DC3 でのレプリケーション関係を手動で削除する必要があります。セカンダリーの登録 に記載されている手順に従ってください。たとえば、以下を使用して、既存の関係を一覧表示します。
hdbnsutil -sr_state
hdbnsutil -sr_state
既存の関係を削除するには、次を使用できます。
clusternode1:rh2adm> hdbnsutil -sr_unregister --name=DC2
clusternode1:rh2adm> hdbnsutil -sr_unregister --name=DC2
通常、これは必須ではありません。
テスト 4 は、テスト 3 の後に実行することを想定したものです。回復手順は、テスト 4 を実行することです。
5.6. テスト 4: プライマリーノードを 1 番目のサイトにフェイルバックする リンクのコピーリンクがクリップボードにコピーされました!
| テストの内容 | プライマリーがクラスターノードに戻る。 フェイルバックしてクラスターを再度有効にする。 3 番目のサイトをセカンダリーとして再登録する。 |
| テストの前提条件 |
|
| テストの手順 | クラスターの予想されるプライマリーを確認します。 DC3 ノードから DC1 ノードにフェイルオーバーします。 以前のセカンダリーが新しいプライマリーに切り替わったかどうかを確認します。 remotehost3 を新しいセカンダリーとして再登録します。
クラスターを |
| テストのモニタリング | 新しいプライマリーの起動時に、次のコマンドを実行します。
|
| テストの開始 |
クラスターの予想されるプライマリーを確認します: VIP およびプロモートされた SAP HANA リソースを、新しい潜在的なプライマリーである同じノード上で実行する必要があります。
この潜在的なプライマリー実行: 以前のプライマリーを新しいセカンダリーとして再登録します。
|
| 期待される結果 | 新しいプライマリーが SAP HANA を起動します。 レプリケーションステータスで、3 つのサイトすべてがレプリケートされたことが示されます。 2 番目のクラスターサイトが、新しいプライマリーに自動的に再登録されます。 Disaster Recovery (DR)サイトは、データベースの追加レプリカになります。 |
| 初期状態に戻す方法 | テスト 3 を実行します。 |
詳細な説明:
クラスターが
maintenance-modeになっているか確認します。pcs property config maintenance-mode Cluster Properties: maintenance-mode: true
[root@clusternode1]# pcs property config maintenance-mode Cluster Properties: maintenance-mode: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow maintenance-modeが true でない場合は、次のように設定できます。pcs property set maintenance-mode=true
[root@clusternode1]# pcs property set maintenance-mode=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow システムレプリケーションのステータスを確認し、すべてのノードでプライマリーデータベースを検出します。まず、次を使用してプライマリーデータベースを検出します。
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters"
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
出力は、以下のようになります。
clusternode1 では:
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters" mode: syncmem primary masters: remotehost3
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters"
mode: syncmem
primary masters: remotehost3
clusternode2 の場合:
clusternode2:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters" mode: syncmem primary masters: remotehost3
clusternode2:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters"
mode: syncmem
primary masters: remotehost3
remotehost3 では、以下を行います。
remotehost3:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters" mode: primary
remotehost3:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters"
mode: primary
3 つのノードでは、プライマリーデータベースは remotehost3 です。このプライマリーデータベースでは、3 つすべてのノードでシステムレプリケーションのステータスが active であり、戻りコードが 15 である必要があります。
-
3 つの
sr_statesがすべて一貫してあるかどうかを確認します。
3 つのノードすべてで hdbnsutil -sr_state --sapcontrol=1 |grep site.*Mode を実行してください。
clusternode1:rh2adm>hdbnsutil -sr_state --sapcontrol=1 |grep site.*Mode
clusternode1:rh2adm>hdbnsutil -sr_state --sapcontrol=1 |grep site.*Mode
clusternode2:rh2adm>hsbnsutil -sr_state --sapcontrol=1 | grep site.*Mode
clusternode2:rh2adm>hsbnsutil -sr_state --sapcontrol=1 | grep site.*Mode
remotehost3:rh2adm>hsbnsutil -sr_state --sapcontrol=1 | grep site.*Mode
remotehost3:rh2adm>hsbnsutil -sr_state --sapcontrol=1 | grep site.*Mode
この出力はすべてのノードで同じである必要があります。
- 別のウィンドウでモニタリングを開始します。
clusternode1 が起動する場合は、以下のようになります。
clusternode1:rh2adm> watch "python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py; echo \$?"
clusternode1:rh2adm> watch "python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py; echo \$?"
remotehost3 の起動では、以下のようになります。
remotehost3:rh2adm> watch "python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py; echo \$?"
remotehost3:rh2adm> watch "python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py; echo \$?"
clusternode2 が起動する場合:
clusternode2:rh2adm> watch "hdbnsutil -sr_state --sapcontrol=1 |grep siteReplicationMode"
clusternode2:rh2adm> watch "hdbnsutil -sr_state --sapcontrol=1 |grep siteReplicationMode"
- テストを開始します。
clusternode1 へのフェイルオーバーは、clusternode1 で起動するには、以下を実行します。
clusternode1:rh2adm> hdbnsutil -sr_takeover done.
clusternode1:rh2adm> hdbnsutil -sr_takeover
done.
- モニターの出力を確認します。
clusternode1 のモニターは次のように変更されます。
重要点も戻りコード 15 です。clusternode2 のモニターは次のように変更されます。
DC3 はなくなっており、再登録する必要があります。remotehost3 では、systemReplicationStatus がエラーを報告し、リターンコードが 11 に変わります。
クラスターノードが再登録されるかどうかを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Site Mappings が表示され、clusternode2 (DC2)が再登録されました。
vip リソースを確認または有効にします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow vip リソース
vip_RH2_02_MASTERが停止します。再度起動するには、以下のコマンドを実行します。
pcs resource enable vip_RH2_02_MASTER Warning: 'vip_RH2_02_MASTER' is unmanaged
[root@clusternode1]# pcs resource enable vip_RH2_02_MASTER
Warning: 'vip_RH2_02_MASTER' is unmanaged
クラスターは maintenance-mode=false でない限りリソースを開始しないため、警告は右です。
-
クラスター
maintenance-modeを停止します。
maintenance-mode を停止する前に、変更を確認するために、別のウィンドウで 2 つのモニターを起動する必要があります。clusternode2 で、以下を実行します。
watch pcs status --full
[root@clusternode2]# watch pcs status --full
clusternode1 で、次を実行します。
clusternode1:rh2adm> watch "python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py; echo $?"
clusternode1:rh2adm> watch "python /usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py; echo $?"
以下を実行して、clusternode1 の maintenance-mode の設定を解除できるようになりました。
pcs property set maintenance-mode=false
[root@clusternode1]# pcs property set maintenance-mode=false
clusternode2 のモニターには、すべてが予想通りに実行されていることが表示されます。
手動との対話後、クラスターのクリーンアップ で説明されているように、クラスターをクリーンアップするのに適したアドバイスが常にあります。???
- remotehost3 を clusternode1 の新しいプライマリーに再登録します。
Remotehost3 を再登録する必要があります。進行状況を監視するには、clusternode1 で開始してください。
clusternode1:rh2adm> watch -n 5 'python
/usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'
clusternode1:rh2adm> watch -n 5 'python
/usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'
remotehost3で起動してください。
remotehost3:rh2adm> watch 'hdbnsutil -sr_state --sapcontrol=1 |grep siteReplicationMode'
remotehost3:rh2adm> watch 'hdbnsutil -sr_state --sapcontrol=1 |grep siteReplicationMode'
これで、以下のコマンドを使用して remotehost3 を再登録できるようになります。
remotehost3:rh2adm> hdbnsutil -sr_register --remoteHost=clusternode1 --remoteInstance=${TINSTANCE} --replicationMode=async --name=DC3 --remoteName=DC1 --operationMode=logreplay --online
remotehost3:rh2adm> hdbnsutil -sr_register --remoteHost=clusternode1 --remoteInstance=${TINSTANCE} --replicationMode=async --name=DC3 --remoteName=DC1 --operationMode=logreplay --online
clusternode1 のモニターは次のように変更されます。
また、remotehost3 のモニターは次のように変更されます。
これで 3 つのエントリーが再度あり、remotehost3 (DC3)が clusternode1 (DC1)からレプリケートされたセカンダリーサイトになりました。
- すべてのノードが clusternode1 のシステムレプリケーションステータスの一部であるかどうかを確認します。
3 つのノードすべてで hdbnsutil -sr_state --sapcontrol=1 |grep site.*Mode を実行してください。
clusternode1:rh2adm> hdbnsutil -sr_state --sapcontrol=1 |grep site.*ModesiteReplicationMode
clusternode1:rh2adm> hdbnsutil -sr_state --sapcontrol=1 |grep site.*ModesiteReplicationMode
clusternode2:rh2adm> hsbnsutil -sr_state --sapcontrol=1 | grep site.*Mode
clusternode2:rh2adm> hsbnsutil -sr_state --sapcontrol=1 | grep site.*Mode
remotehost3:rh2adm> hsbnsutil -sr_state --sapcontrol=1 | grep site.*Mode
remotehost3:rh2adm> hsbnsutil -sr_state --sapcontrol=1 | grep site.*Mode
すべてのノードで、同じ出力を取得する必要があります。
-
pcs status --fullおよびSOKを確認します。以下を実行します。
pcs status --full| grep sync_state
[root@clusternode1]# pcs status --full| grep sync_state
出力は PRIM または SOK のいずれかである必要があります。
* hana_rh2_sync_state : PRIM
* hana_rh2_sync_state : SOK
* hana_rh2_sync_state : PRIM
* hana_rh2_sync_state : SOK
最後に、クラスターのステータスは、sync_state PRIM および SOK を含むようになります。
すべてが再び正常に動作することを確認するには、クラスターのステータスの確認 および データベースの確認 を参照してください。
第6章 便利なコマンド リンクのコピーリンクがクリップボードにコピーされました!
以下の 3 つのセクションで、便利なコマンドを紹介します。ほとんどの場合、操作や設定の成功を確認するのに役立ちます。例を応答とともに記載しています。出力は、形式上の理由で調整されている場合があります。
-
このドキュメントにリストされているすべてのコマンドには、
<sid>admユーザーが実行するものである場合、先頭に%が付いています。 -
root userが実行するすべてのコマンドには、先頭に#が付いています。 -
コマンドを実行するには、接頭辞の
%または#を除きます。
6.1. SAP HANA コマンド リンクのコピーリンクがクリップボードにコピーされました!
SAP HANA コマンドは、<sid>adm ユーザーによって実行されます。以下に例を示します。
6.1.1. hdbclm を使用した SAP HANA のインストール リンクのコピーリンクがクリップボードにコピーされました!
3 番目のサイトのインストールは、2 番目のサイトのインストールと似ています。インストールは、root ユーザーとして hdblcm を使用して実行できます。以前に何もインストールされていないことを確認するには、hdbuninst を実行して、このノードに SAP HANA がまだインストールされていないかどうかを確認します。
HANA アンインストールの出力例:
cd /software/DATA_UNITS/HDB_SERVER_LINUX_X86_64 root@DC3/software/DATA_UNITS/HDB_SERVER_LINUX_X86_64# ./hdbuninst Option 0 will remove an already existing HANA Installation No SAP HANA Installation found is the expected answer
[root@remotehost3]# cd /software/DATA_UNITS/HDB_SERVER_LINUX_X86_64
root@DC3/software/DATA_UNITS/HDB_SERVER_LINUX_X86_64# ./hdbuninst
Option 0 will remove an already existing HANA Installation
No SAP HANA Installation found is the expected answer
DC3 での HANA インストールの出力例:
インストールが開始される前に、概要がリスト表示されます。
y を入力してインストールを開始します。
6.1.2. hdbsql を使用した Inifile の内容の確認 リンクのコピーリンクがクリップボードにコピーされました!
6.1.3. データベースの確認 リンクのコピーリンクがクリップボードにコピーされました!
データベースが実行されているかどうかを確認し、現在のプライマリーノードを検出します。
データベースインスタンスのリスト表示
出力が緑色の場合、インスタンスは実行中です。
データベースプロセスのリスト表示
通常、すべてのデータベースプロセスのステータスは GREEN です。
SAP HANA プロセスのリスト表示
SAP HANA ランドスケープ設定の表示
戻りコード:
- 0: Fatal
- 1: Error
- 2: Warning
- 3: Info
- 4: OK
プライマリーデータベースの検出
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "primary masters|^mode"
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "primary masters|^mode"
セカンダリーでの確認の例:
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "primary masters|^mode" mode: syncmem primary masters: clusternode1
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "primary masters|^mode"
mode: syncmem
primary masters: clusternode1
現在のプライマリーでの確認の例:
データベースのバージョンの表示
SQL クエリーを使用した例:
hdbsql RH2=> select * from m_database SYSTEM_ID,DATABASE_NAME,HOST,START_TIME,VERSION,USAGE "RH2","RH2","node1","2023-06-22 15:33:05.235000000","2.00.059.02.1647435895","CUSTOM" 1 row selected (overall time 29.107 msec; server time 927 usec)
hdbsql RH2=> select * from m_database
SYSTEM_ID,DATABASE_NAME,HOST,START_TIME,VERSION,USAGE
"RH2","RH2","node1","2023-06-22 15:33:05.235000000","2.00.059.02.1647435895","CUSTOM"
1 row selected (overall time 29.107 msec; server time 927 usec)
systemOverview.py を使用した例:
6.1.4. SAP HANA の起動と停止 リンクのコピーリンクがクリップボードにコピーされました!
オプション 1: HDB コマンド
clusternode1:rh2adm> HDB help
Usage: /usr/sap/RH2/HDB02/HDB { start|stop|reconf|restart|version|info|proc|admin|kill|kill-<sig>|term }
kill or kill-9 should never be used in a productive environment!
clusternode1:rh2adm> HDB help
Usage: /usr/sap/RH2/HDB02/HDB { start|stop|reconf|restart|version|info|proc|admin|kill|kill-<sig>|term }
kill or kill-9 should never be used in a productive environment!
データベースを起動します。
clusternode1:rh2adm> HDB start
clusternode1:rh2adm> HDB startCopy to Clipboard Copied! Toggle word wrap Toggle overflow データベースを停止します。
clusternode1:rh2adm> HDB stop
clusternode1:rh2adm> HDB stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow
オプション 2 (推奨): sapcontrol を使用
clusternode1:rh2adm> sapcontrol -nr ${TINSTANCE} -function StartSystem HDB
03.07.2023 14:08:30
StartSystem
OK
clusternode1:rh2adm> sapcontrol -nr ${TINSTANCE} -function StartSystem HDB
03.07.2023 14:08:30
StartSystem
OK
clusternode1:rh2adm> sapcontrol -nr ${TINSTANCE} -function StopSystem HDB
03.07.2023 14:09:33
StopSystem
OK
clusternode1:rh2adm> sapcontrol -nr ${TINSTANCE} -function StopSystem HDB
03.07.2023 14:09:33
StopSystem
OK
GetProcessList を使用して、HANA サービスの起動と停止を監視します。
clusternode1:rh2adm> sapcontrol -nr ${TINSTANCE} -function GetProcessList
clusternode1:rh2adm> sapcontrol -nr ${TINSTANCE} -function GetProcessList
6.1.5. SAP HANA システムレプリケーションのステータスの確認 リンクのコピーリンクがクリップボードにコピーされました!
SAP HANA システムレプリケーションのステータスを確認するには、さまざまな方法があります。
- `clusternode1:rh2adm> python systemReplicationStatus.py ` on the primary node
-
clusternode1:rh2adm> echo $? #(systemReplicationStatus の戻りコード) -
clusternode1:rh2adm> hdbnsutil -sr_state -
clusternode1:rh2adm> hdbnsutil -sr_stateConfiguration
モニターとして実行される systemReplicationStatus.py の出力例:
予想される戻りコードの結果は次のとおりです。
- 10: NoHSR
- 11: Error
- 12: Unknown
- 13: Initializing
- 14: Syncing
- 15: Active
ほとんどの場合、システムレプリケーションのチェックは戻りコード 15 を返します。別の表示オプションとして、-t (printLandscapeTree) を使用する方法があります。
現在のプライマリーでの出力の例:
clusternode1:rh2adm> python systemReplicationStatus.py -t
HANA System Replication landscape:
DC1 ( primary )
| --- DC3 ( syncmem )
| --- DC2 ( syncmem )
clusternode1:rh2adm> python systemReplicationStatus.py -t
HANA System Replication landscape:
DC1 ( primary )
| --- DC3 ( syncmem )
| --- DC2 ( syncmem )
hdbnsutil -sr_state の例:
プライマリーでの sr_stateConfiguation の例:
セカンダリーでの sr_stateConfiguration の例:
どのノードが現在のプライマリーであるかをセカンダリーデータベースで確認することもできます。フェイルオーバー中に 2 つのプライマリーデータベースが見つかった場合に、この情報は、どちらのプライマリーデータベースが間違っており、セカンダリーとして再登録する必要があるかを判断するために必要になります。
詳細は、Example: Checking the Status on the Primary and Secondary Systems を参照してください。
6.1.6. セカンダリーノードの登録 リンクのコピーリンクがクリップボードにコピーされました!
SAP HANA システムレプリケーション環境のセカンダリーデータベースを登録するための前提条件:
登録例:
登録すると、global.ini ファイルが自動的に更新されます。
更新前:
更新後:
6.1.7. sapcontrol GetProcessList リンクのコピーリンクがクリップボードにコピーされました!
アクティブな SAP HANA データベースのプロセスの確認
6.1.8. sapcontrol GetInstanceList リンクのコピーリンクがクリップボードにコピーされました!
これにより、SAP HANA データベースのインスタンスのステータスがリスト表示されます。ポートも表示されます。3 つの異なるステータス名があります。
- GREEN (実行中)
- GRAY (停止)
- YELLOW (ステータスが現在変化中)
アクティブなインスタンスの例:
停止したインスタンスの例:
6.1.9. hdbcons の例 リンクのコピーリンクがクリップボードにコピーされました!
HDB コンソールを使用してデータベースに関する情報を表示することもできます。
-
hdbcons -e hdbindexserver 'replication info' -
その他のオプションについては、
hdbcons -e hdbindexserver helpを参照
'replication info' の例:
help の例:
6.1.10. SAP HANA バックアップの作成 リンクのコピーリンクがクリップボードにコピーされました!
SAP HANA システムレプリケーションを使用する場合は、先にプライマリーシステムでバックアップを作成する必要があります。
ユーザー <sid>adm としてこれを実行する方法の例:
clusternode1:rh2adm> hdbsql -i ${TINSTANCE} -u system -d SYSTEMDB "BACKUP DATA USING FILE ('/hana/backup/')"
clusternode1:rh2adm> hdbsql -i ${TINSTANCE} -u system -d ${SAPSYSTEMNAME} "BACKUP DATA USING FILE ('/hana/backup/')"
clusternode1:rh2adm> hdbsql -i ${TINSTANCE} -u system -d SYSTEMDB "BACKUP DATA USING FILE ('/hana/backup/')"
clusternode1:rh2adm> hdbsql -i ${TINSTANCE} -u system -d ${SAPSYSTEMNAME} "BACKUP DATA USING FILE ('/hana/backup/')"
6.1.11. プライマリーノードでの SAP HANA システムレプリケーションの有効化 リンクのコピーリンクがクリップボードにコピーされました!
SAP HANA システムレプリケーションはプライマリーノードで有効にする必要があります。これを行うには、先にバックアップを実行する必要があります。
clusternode1:rh2adm> hdbnsutil -sr_enable --name=DC1 nameserver is active, proceeding ... successfully enabled system as system replication source site done.
clusternode1:rh2adm> hdbnsutil -sr_enable --name=DC1
nameserver is active, proceeding ...
successfully enabled system as system replication source site
done.
6.1.12. セカンダリーノードへのデータベースキーのコピー リンクのコピーリンクがクリップボードにコピーされました!
セカンダリーデータベースをセカンダリーとして登録するには、データベースキーをプライマリーデータベースからセカンダリーデータベースにコピーする必要があります。
以下に例を示します。
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY
6.1.13. SAP HANA システムレプリケーションのセカンダリーノードの登録 リンクのコピーリンクがクリップボードにコピーされました!
まず、データベースキーがセカンダリーノードにコピーされていることを確認してください。次に、登録コマンドを実行します。
clusternode1:rh2adm> hdbnsutil -sr_register --remoteHost=remotehost3 --remoteInstance=${TINSTANCE} --replicationMode=syncmem --name=DC1 --remoteName=DC3 --operationMode=logreplay --online
clusternode1:rh2adm> hdbnsutil -sr_register --remoteHost=remotehost3 --remoteInstance=${TINSTANCE} --replicationMode=syncmem --name=DC1 --remoteName=DC3 --operationMode=logreplay --online
パラメーターの説明:
-
remoteHost: ソース (プライマリー) データベースを実行しているアクティブノードのホスト名 -
remoteInstance: データベースのインスタンス番号 replicationMode: 次のオプションのいずれか-
sync: ハードディスク同期 -
async: 非同期レプリケーション -
syncmem: メモリー同期
-
-
name: このレプリケーションサイトのエイリアス -
remoteName: ソースデータベースのエイリアス名 operationMode: 次のオプションのいずれか-
delta_datashipping: データが定期的に送信されます。テイクオーバーに少し時間がかかります。 -
logreplay: ログがリモートサイトですぐに再実行されます。テイクオーバーが早くなります。 -
logreplay_readaccess: 2 番目のサイトへの追加の logreplay 読み取り専用アクセスが可能です。
-
6.1.14. SAP HANA データベースの log_mode の確認 リンクのコピーリンクがクリップボードにコピーされました!
log_mode の設定には 2 つのオプションがあります。
-
log_mode=overwrite -
log_mode=normal: これはデフォルト値であり、データベースインスタンスがプライマリーとして実行されている場合に必要です。SAP HANA マルチターゲットシステムレプリケーションを使用する場合は、log_mode=normalを使用する必要があります。log_modeを確認する最良の方法は、hdbsqlを使用することです。
間違った overwrite エントリーを含む例:
この場合、次の 2 つの global.ini ファイルがあります。
DEFAULT-
/usr/sap/${SAPSYSTEMNAME}/SYS/global/hdb/custom/config/global.ini
-
HOST-
/hana/shared/${SAPSYSTEMNAME}/HDB${TINSTANCE}/${HOSTNAME}/global.iniHOST値はDEFAULT値を上書きします。データベースを起動する前に両方のファイルを確認してから、hdbsqlを再度使用して正しい設定を確認することもできます。log_modeは、global.ini ファイルを編集することで変更できます。
-
以下に例を示します。
clusternode1:rh2adm> vim /hana/shared/${SAPSYSTEMNAME}/HDB${TINSTANCE}/${HOSTNAME}/global.ini
# global.ini last modified 2023-04-06 16:15:03.521715 by hdbnameserver
[persistence]
log_mode = overwrite
clusternode1:rh2adm> vim /hana/shared/${SAPSYSTEMNAME}/HDB${TINSTANCE}/${HOSTNAME}/global.ini
# global.ini last modified 2023-04-06 16:15:03.521715 by hdbnameserver
[persistence]
log_mode = overwrite
global.ini last modified 2023-04-06 16:15:03.521715 by hdbnameserver [persistence] log_mode = normal
# global.ini last modified 2023-04-06 16:15:03.521715 by hdbnameserver
[persistence]
log_mode = normal
global.ini ファイルを確認または更新した後、log_mode 値を確認します。
また、このセクションからわかるように、このパラメーターは [persistence] セクションで設定する必要があります。ログモードを overwrite から normal に変更する場合は、データベースを確実に回復できるように、完全なデータバックアップを作成することを推奨します。
6.1.15. プライマリーデータベースの検出 リンクのコピーリンクがクリップボードにコピーされました!
プライマリーノードを識別するには、たとえば次の方法があります。
-
pcs status | grep Promoted -
hdbnsutil -sr_stateConfiguration -
systemReplicationStatus.py
次の systemReplicationStatus.py スクリプトとフィルターの例は、すべてのノード上のプライマリーデータベースの場所を返します。
clusternode1:rh2adm>
/usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/Python/bin/python
/usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py --sapcontrol=1 | egrep -e
"3${TINSTANCE}01/HOST|PRIMARY_MASTERS"| head -1 | awk -F"=" '{ print $2 }'
clusternode1:rh2adm>
/usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/Python/bin/python
/usr/sap/$SAPSYSTEMNAME/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py --sapcontrol=1 | egrep -e
"3${TINSTANCE}01/HOST|PRIMARY_MASTERS"| head -1 | awk -F"=" '{ print $2 }'
出力:
clusternode2
clusternode2
オプション 2 - 次の例では、すべてのノードと同様の方法で systemReplicationStatus を示しています。
rh2adm>hdbnsutil -sr_state --sapcontrol=1 | grep site.*Mode
rh2adm>hdbnsutil -sr_state --sapcontrol=1 | grep site.*Mode
出力:
6.1.16. プライマリーのテイクオーバー リンクのコピーリンクがクリップボードにコピーされました!
プライマリーノードとセカンダリーノードの確認については、レプリケーションステータスの確認 セクションを参照してください。また、以下の点にも注意してください。
- クラスターを maintenance-mode にします。
- セカンダリーノードでテイクオーバーを開始します。
クラスターの maintenance-mode を有効にする例:
pcs property set maintenance-mode=true
[root@clusternode1]# pcs property set maintenance-mode=true
新しいプライマリーとなるセカンダリーで、<sidadm> ユーザーとして次のコマンドを実行します。
clusternode1:rh2adm> hdbnsutil -sr_takeover
clusternode1:rh2adm> hdbnsutil -sr_takeover
このセカンダリーがプライマリーになり、他のアクティブなセカンダリーデータベースが、新しいプライマリーに再登録されます。前のプライマリーは、セカンダリーとして手動で再登録する必要があります。
6.1.17. 以前のプライマリーをセカンダリーとして再登録する リンクのコピーリンクがクリップボードにコピーされました!
クラスターが停止しているか、maintenance-mode になっていることを確認してください。以下に例を示します。
clusternode2:rh2adm> hdbnsutil -sr_register --remoteHost=remotehost3 --remoteInstance=${TINSTANCE} --replicationMode=syncmem --name=DC2 --online --remoteName=DC3 --operationMode=logreplay --force_full_replica --online
clusternode2:rh2adm> hdbnsutil -sr_register --remoteHost=remotehost3 --remoteInstance=${TINSTANCE} --replicationMode=syncmem --name=DC2 --online --remoteName=DC3 --operationMode=logreplay --force_full_replica --online
この例では、完全なレプリケーションを使用しています。SAP HANA システム管理者は、完全なレプリケーションが必要になる場合を理解しておく必要があります。
6.1.18. フェイルオーバーからの回復 リンクのコピーリンクがクリップボードにコピーされました!
SAP HANA システムレプリケーションのステータスの確認 および プライマリーノードの検出 を参照してください。重要なのは、情報の整合性を確保することです。ノードが systemReplicationStatus.py の出力に含まれておらず、ノードのシステムレプリケーションの状態が異なる場合は、このノードを再登録する必要があるかどうかをデータベース管理者に確認してください。
これを解決する 1 つの方法は、このサイトを新しいセカンダリーとして 再登録 することです。
場合によっては、セカンダリーインスタンスがまだ起動していないことがあります。その後、もう一度再登録する前に、このサイトの登録を解除してください。セカンダリー DC1 の登録を解除する例:
clusternode1:rh2adm> hdbnsutil -sr_unregister --name=DC1
clusternode1:rh2adm> hdbnsutil -sr_unregister --name=DC1
DC1 の再登録例:
clusternode1:rh2adm> hdbnsutil -sr_register --name=DC1 --remoteHost=node2 --remoteInstance=02 --replicationMode=sync --operationMode=logreplay --online
clusternode1:rh2adm> hdbnsutil -sr_register --name=DC1 --remoteHost=node2 --remoteInstance=02 --replicationMode=sync --operationMode=logreplay --online
6.2. Pacemaker コマンド リンクのコピーリンクがクリップボードにコピーされました!
6.2.1. クラスターの起動と停止 リンクのコピーリンクがクリップボードにコピーされました!
すべてのノードでクラスターを起動するには、次のコマンドを実行します。
pcs cluster start -all
# pcs cluster start -all
再起動後、サービスが有効になっている場合にのみ、クラスターが自動的に起動します。このコマンドは、クラスターが起動したかどうか、およびデーモンの自動起動が有効になっているかどうかを確認するのに役立ちます。
pcs cluster status
# pcs cluster status
クラスターの自動起動は次の方法で有効にできます。
pcs cluster enable --all
# pcs cluster enable --all
その他のオプションは以下のとおりです。
- クラスターを停止する。
- ノードをスタンバイにします。
-
クラスターを
maintenance-modeにします。
詳細は、pcs cluster のヘルプを参照してください。
pcs cluster stop --all pcs cluster help
# pcs cluster stop --all
# pcs cluster help
6.2.2. クラスターを maintenance-mode にする リンクのコピーリンクがクリップボードにコピーされました!
変更を加えるときに Pacemaker クラスターによる干渉を避けるには、クラスターを maintenance-mode にすることで、クラスターを "フリーズ" できます。
pcs property set maintenance-mode=true
# pcs property set maintenance-mode=true
maintenance-mode を確認する簡単な方法は、リソースが unmanaged かどうかを確認することです。
maintenance-mode モードのクラスターは、リソースステータスの変更を更新しません。その間に、クラスターリソースを更新してリソース状態を検出します。
pcs resource refresh
# pcs resource refresh
これにより、何か問題がないかどうかが示され、maintenance-mode が終了するとすぐにクラスターによる修復アクションが実行されます。
次のコマンドを実行して maintenance-mode を解除します。
pcs property set maintenance-mode=false
# pcs property set maintenance-mode=false
これで、クラスターが引き続き動作します。設定に問題があった場合、クラスターはその問題にすぐに対処します。
6.2.3. クラスターのステータスの確認 リンクのコピーリンクがクリップボードにコピーされました!
以下に、クラスターのステータスを確認するいくつかの方法を示します。
クラスターが実行中かどうかを確認します。
pcs cluster status
# pcs cluster statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターとすべてのリソースを確認します。
pcs status
# pcs statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター、すべてのリソース、およびすべてのノード属性を確認します。
pcs status --full
# pcs status --fullCopy to Clipboard Copied! Toggle word wrap Toggle overflow リソースのみを確認します。
pcs resource status --full
# pcs resource status --fullCopy to Clipboard Copied! Toggle word wrap Toggle overflow Stonithの履歴を確認します。pcs stonith history
# pcs stonith historyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 場所の制約を確認します。
pcs constraint location
# pcs constraint locationCopy to Clipboard Copied! Toggle word wrap Toggle overflow
フェンシングを設定してテストする必要があります。可能な限り自動化されたソリューションを実現するには、クラスターを常にアクティブにする必要があります。そうすることで、再起動後にクラスターが自動的に起動できるようになります。実稼働環境では、再起動を無効にすると、クラッシュ後などに手動で介入できるようになります。デーモンのステータスも確認してください。
以下に例を示します。
6.2.4. リソースの状態の確認 リンクのコピーリンクがクリップボードにコピーされました!
pcs resource を使用して、すべてのリソースのステータスを確認します。これにより、リソースのリストと現在のステータスが出力されます。
以下に例を示します。
6.2.5. リソース設定の確認 リンクのコピーリンクがクリップボードにコピーされました!
次のコマンドで、現在のリソース設定が表示されます。
これには、インストールおよび設定されたリソースエージェントの設定に使用されるすべてのパラメーターがリスト表示されます。
6.2.6. SAPHana リソースオプションの AUTOMATED_REGISTER=true リンクのコピーリンクがクリップボードにコピーされました!
このオプションを SAPHana リソースで使用すると、Pacemaker はセカンダリーデータベースを自動的に再登録します。
最初のテストではこのオプションを使用することを推奨します。AUTOMATED_REGISTER=false を使用した場合、管理者はセカンダリーノードを手動で再登録する必要があります。
6.2.7. リソースの処理 リンクのコピーリンクがクリップボードにコピーされました!
リソース管理には複数のオプションがあります。詳細は、利用可能なヘルプを参照してください。
pcs resource help
# pcs resource help
使用されているリソースエージェントをリスト表示します。
pcs resource config | grep "type=" | awk -F"type=" '{ print $2 }' | sed -e "s/)//g"
# pcs resource config | grep "type=" | awk -F"type=" '{ print $2 }' | sed -e "s/)//g"
出力例:
IPaddr2 SAPHanaTopology SAPHana
IPaddr2
SAPHanaTopology
SAPHana
特定のリソースエージェントの説明と設定パラメーターを表示します。
pcs resource describe <resource agent>
# pcs resource describe <resource agent>
例 (出力なし):
pcs resource describe IPaddr2
# pcs resource describe IPaddr2
リソースエージェント IPaddr2 の例 (出力付き):
クラスターが停止すると、すべてのリソースも停止します。クラスターが maintenance-mode になると、すべてのリソースは実行されたままになりますが、監視または管理されなくなります。
6.2.8. maintenance mode のクラスタープロパティーの処理 リンクのコピーリンクがクリップボードにコピーされました!
定義されているすべてのプロパティーをリスト表示します。
データベースを再設定するには、設定が完了するまで変更を無視するようにクラスターに指示する必要があります。以下を使用してクラスターを maintenance-mode にできます。
pcs property set maintenance-mode=true
# pcs property set maintenance-mode=true
maintenance-mode を確認します。
すべてのリソースが "unmanaged" であることを確認します。
maintenance-mode の設定を解除すると、リソースは managed に戻ります。
pcs property set maintenance-mode=false
# pcs property set maintenance-mode=false
6.2.9. move を使用した SAPHana リソースのフェイルオーバー リンクのコピーリンクがクリップボードにコピーされました!
SAP HANA データベースをフェイルオーバーする簡単な例は、pcs resource move コマンドを使用することです。以下に示すように、クローンリソース名を使用してリソースを移動する必要があります。
pcs resource move <SAPHana-clone-resource>
# pcs resource move <SAPHana-clone-resource>
この例では、クローンリソースは SAPHana_RH2_02-clone です。
リソースを移動します。
制約が残っているかどうかを確認します。
pcs constraint location
# pcs constraint location
リソースをクリアすることで、フェイルオーバー中に作成された場所の制約を削除できます。以下に例を示します。
pcs resource clear SAPHana_RH2_02-clone
[root@clusternode1]# pcs resource clear SAPHana_RH2_02-clone
"Migration Summary" に警告やエントリーが残っているかどうかを確認します。
pcs status --full
# pcs status --full
stonith の履歴を確認します。
pcs stonith history
# pcs stonith history
必要に応じて、stonith の履歴をクリアします。
pcs stonith history cleanup
# pcs stonith history cleanup
Pacemaker バージョン 2.1.5 より前のバージョンを使用している場合は、Is there a way to manage constraints when running pcs resource move? を参照し、残っている制約を確認してください。
6.2.10. フェイルオーバーと同期状態の監視 リンクのコピーリンクがクリップボードにコピーされました!
すべての Pacemaker のアクティビティーは、クラスターノードの /var/log/messages ファイルに記録されます。他にも多くのメッセージがあるため、SAP リソースエージェントに関連するメッセージを確認するのが難しい場合があります。SAP リソースエージェントに関連するメッセージのみをフィルターするコマンドエイリアスを設定できます。
エイリアスの例 tmsl:
alias tmsl='tail -1000f /var/log/messages | egrep -s "Setting master-rsc_SAPHana_$SAPSYSTEMNAME_HDB${TINSTANCE}|sr_register|WAITING4LPA|PROMOTED|DEMOTED|UNDEFINED|master_walk|SWAIT|WaitforStopped|FAILED|LPT"'
# alias tmsl='tail -1000f /var/log/messages | egrep -s "Setting master-rsc_SAPHana_$SAPSYSTEMNAME_HDB${TINSTANCE}|sr_register|WAITING4LPA|PROMOTED|DEMOTED|UNDEFINED|master_walk|SWAIT|WaitforStopped|FAILED|LPT"'
tsml の出力例:
フィルターを使用すると、どのようなステータス変化が発生しているかを理解しやすくなります。詳細がない場合は、メッセージファイル全体を開くと、すべての情報を確認できます。
フェイルオーバー後、リソースをクリアできます。場所の制約が残っていないことも確認してください。
6.2.11. クラスターの整合性の確認 リンクのコピーリンクがクリップボードにコピーされました!
インストール中、設定が最終的に完了する前にリソースが起動することがあります。これにより、Cluster Information Base (CIB) のエントリーが発生し、誤った動作が発生する可能性があります。これは簡単に確認でき、設定の完了後に手動で修正することもできます。
SAPHana リソースを起動すると、欠落しているエントリーが再作成されます。間違ったエントリーには pcs コマンドでは対処できないため、手動で削除する必要があります。
CIB エントリーを確認します。
cibadmin --query
# cibadmin --query
クラスターメンバーが DC1 と DC2 であり、ノード間の同期状態が SOK と報告される場合、DC3 と SFAIL のエントリーはクラスター情報ベースに存在しないはずです。
対応するエントリーを確認する例:
cibadmin --query |grep '"DC3"' cibadmin --query |grep '"SFAIL"'
# cibadmin --query |grep '"DC3"'
# cibadmin --query |grep '"SFAIL"'
このコマンドは、クラスター内の任意のノードで root ユーザーとして実行できます。通常、コマンドの出力は空です。設定にまだエラーがある場合、出力は次のようになります。
<nvpair id="SAPHanaSR-hana_rh1_glob_sec" name="hana_rh1_glob_sec" value="DC3"/>
<nvpair id="SAPHanaSR-hana_rh1_glob_sec" name="hana_rh1_glob_sec" value="DC3"/>
これらのエントリーは、次のコマンドを使用して削除できます。
cibadmin --delete --xml-text '<...>'
# cibadmin --delete --xml-text '<...>'
上の例のエントリーを削除するには、次のように入力する必要があります。出力には二重引用符が含まれるため、テキストを一重引用符で囲む必要があることに注意してください。
cibadmin --delete --xml-text ' <nvpair id="SAPHanaSR-hana_rh1_glob_sec" name="hana_rh1_glob_sec" value="DC3"/>'
# cibadmin --delete --xml-text ' <nvpair id="SAPHanaSR-hana_rh1_glob_sec" name="hana_rh1_glob_sec" value="DC3"/>'
削除された CIB エントリーがないことを確認します。返される出力は空である必要があります。
cibadmin --query |grep 'DC3"'
# cibadmin --query |grep 'DC3"'
6.2.12. クラスターのクリーンアップ リンクのコピーリンクがクリップボードにコピーされました!
フェイルオーバーテスト中に、以前のテストの制約やその他の残留物が残ることがあります。次のテストを開始する前に、クラスターからこれらをクリアする必要があります。
クラスターのステータスで障害イベントがないか確認します。
pcs status --full
# pcs status --full
"Migration Summary" にクラスターの警告またはエントリーが表示された場合は、リソースをクリアしてクリーンアップする必要があります。
pcs resource clear SAPHana_RH2_02-clone pcs resource cleanup SAPHana_RH2_02-clone
# pcs resource clear SAPHana_RH2_02-clone
# pcs resource cleanup SAPHana_RH2_02-clone
出力:
Cleaned up SAPHana_RH2_02:0 on clusternode1 Cleaned up SAPHana_RH2_02:1 on clusternode2
Cleaned up SAPHana_RH2_02:0 on clusternode1
Cleaned up SAPHana_RH2_02:1 on clusternode2
以前のフェイルオーバーなどで使用された不要な場所の制約があるかどうかを確認します。
pcs constraint location
# pcs constraint location
既存の制約をさらに詳しく確認します。
pcs constraint --full
# pcs constraint --full
リソース移動後の場所の制約の例:
Node: hana08 (score:-INFINITY) (role:Started) (id:cli-ban-SAPHana_RH2_02-clone-on-hana08)
Node: hana08 (score:-INFINITY) (role:Started) (id:cli-ban-SAPHana_RH2_02-clone-on-hana08)
この場所の制約をクリアします。
pcs resource clear SAPHana_RH2_02-clone
# pcs resource clear SAPHana_RH2_02-clone
制約が制約リストから消えていることを確認します。まだ残っている場合は、制約 ID を使用して明示的に削除します。
pcs constraint delete cli-ban-SAPHana_RH2_02-clone-on-hana08
# pcs constraint delete cli-ban-SAPHana_RH2_02-clone-on-hana08
フェンシングを使用して複数のテストを実行する場合は、stonith の履歴をクリアすることもできます。
pcs stonith history cleanup
# pcs stonith history cleanup
pcs コマンドはすべて root ユーザーとして実行します。残留物の検出 も参照してください。
6.2.13. その他のクラスターコマンド リンクのコピーリンクがクリップボードにコピーされました!
さまざまなクラスターコマンドの例
6.3. RHEL および一般的なコマンド リンクのコピーリンクがクリップボードにコピーされました!
6.3.1. 現在のステータスの検出 リンクのコピーリンクがクリップボードにコピーされました!
環境の現在のステータスを知るには、いくつかの手順に従う必要があります。環境の監視 を参照してください。また、次のことを行うことを推奨します。
-
/var/log/messagesを確認し、ログの確認を容易にするために モニタリング用のエイリアス を使用します。 - 場合によっては、適切な操作を継続するために、クラスターを以前のアクティビティーからクリーンアップする必要があります。残留物を検出 し、必要に応じてクリアします。
6.3.2. yum info リンクのコピーリンクがクリップボードにコピーされました!
6.3.3. RPM バージョン表示 リンクのコピーリンクがクリップボードにコピーされました!
rpm -q resource-agents-sap-hana resource-agents-sap-hana-0.162.1-2.el9_2.noarch
# rpm -q resource-agents-sap-hana
resource-agents-sap-hana-0.162.1-2.el9_2.noarch
6.3.4. モニタリング用のエイリアス リンクのコピーリンクがクリップボードにコピーされました!
これをシェルプロファイルに追加できます。この例では、root のエイリアスは <sidadm> のエイリアスに依存しているため、これもすでに定義されている必要があります。
root (
~/.bashrcに追加):Copy to Clipboard Copied! Toggle word wrap Toggle overflow <sid>adm(~/.customer.shに追加):Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第7章 参考資料 リンクのコピーリンクがクリップボードにコピーされました!
7.1. Red Hat リンクのコピーリンクがクリップボードにコピーされました!
7.2. SAP リンクのコピーリンクがクリップボードにコピーされました!
- SAP HANA Administration Guide for SAP HANA Platform
- Disaster Recovery Scenarios for Multitarget System Replication
- SAP HANA System Replication Configuration Parameter
- Example: Checking the Status on the Primary and Secondary Systems
- General Prerequisites for Configuring SAP HANA System Replication
- Change Log Modes
- Failed to re-register former primary site as new secondary site due to missing log
- Checking the Status with landscapeHostConfiguration.py
- How to Setup SAP HANA Multi-Target System Replication
- SAP HANA マルチターゲットシステムレプリケーション