以前、Disaster Recovery 機能を用いたLifeKeeperの構築を行いました。
検証環境を一から作成し、LifeKeeperのインストールを初めて行ったのですが、
その際に生じた躓いたところを、自分への備忘もかねて今回まとめました。
概要
- AWS環境のRed Hat Enterprise Linux に LifeKeeperをインストール
- Disaster Recovery Add-onの初期設定及びリソース作成/拡張を実施
インストール時
まず初めにLifeKeeperをインストールの際のトラブルシューティングです。
事前に確認しておくべき項目を記載しておきます。
- ライセンスが有効であるか
初歩的なことですが、一番大事な確認かもしれません。
ライセンスが有効になっているか、期限が切れていないかまずは確認しましょう。 - SELinuxが無効化されているか
SELinux が enforcing モードの場合 、LifeKeeper は動作しないため無効となっているか確認しましょう。
確認コマンド：sestatus
上記事項の確認を終えましたら、インストールに移っていきます。
インストールの手順としては、isoファイルを対象のノードにセットして、セットアップを実行していきます。
私が初めて実施した際は、まずその段階でエラー発生しました。
# ./setup LifeKeeper for Linux Setup Validating files........................................................................OK Collecting system information.....................................done. Preparing configuration information............done. Performing package installation and updating configuration information for LifeKeeper for Linux. Install LifeKeeper and dependent packages done. Setup failed. Fix the problem and try again. ---error message--- - Status code: 999 for https:/--- Error: Failed to --- #
上記表示のように、エラーメッセージやエラーコードが表示されました。
セットアップコマンドが失敗した際は、エラー原因を確認し該当の箇所をある程度は切り分けられることができますので、
対処をして再度チャレンジしていきましょう。
インストールが完了しましたら、LifeKeeperが起動しているか確認してみましょう。
確認方法としては、/opt/LifeKeeper/bin/lktest を実行すると確認ができます。
# /opt/LifeKeeper/bin/lktest F S UID PID PPID C CLS PRI NI SZ STIME TIME CMD 4 S root 23199 23134 0 TS 39 -20 4579 05:29 00:00:00 lcm 4 S root 23201 23140 0 TS 39 -20 5526 05:29 00:00:00 ttymonlcm 4 S root 23205 23133 0 TS 29 -10 6674 05:29 00:00:00 lcd #
上記コマンドを実行して出力がされていれば、無事LifeKeeperは起動されております。
リソース作成時
続いて、LifeKeeperのインストール完了後、リソースと呼ばれる、LifeKeeperにて保護するアプリケーションやファイルシステムを設定する中でのトラブルシューティングとなります。
今回はDisaster Recovery Add-onにおけるDRBDリソース作成および拡張時におきたトラブルシュートの例を記載いたします。
リソース不足
デフォルト値の設定にてリソース作成を試みたところ容量不足でエラーが発生しました。
1.0MBで容量が不足とのことなのでこちらの対処として、AWS EBSで10 GiBのサイズを対象インスタンスへの割り当てを行い、こちらのエラーは解消となりました。
パーティション作成
続いて、DRBDリソース作成時に発生したエラーです。
このエラーは、パーティションの無いデバイスに対して操作を行うと生じるエラーとのことでした。
こちらは検証を行っていた段階では製品マニュアル等に記載が無い情報となりメーカーのサポート窓口と密にやり取りを行い解消できた事象となります。
対処として、マウント対象のデバイスに対してパーティションを作成し事象が解消となりました。
そのため、データレプリケーションリソース作成の際は、事前にデバイスの確認を行い、無いようであればディレクトリにパーティションの作成を行いましょう。
パーティションの作成方法としては以下となります。
fdiskを使用して新しいパーティションを作成または修正します。
●n を押して新しいパーティションを作成。
●p を選んでプライマリパーティションを設定。
●必要に応じて値を設定し、最後にパーティション変更を保存するために w を押します。
DRBDリソース再作成時の注意点
一度リソースの作成ができず、再度リソースの作成を試みようとしたとき、
DRBD の設定が残っている可能性があり、その場合リソース作成でエラーが発生いたします。
その際は以下のコマンドを実行をして余分な情報を削除する必要があります。
rm /etc/drbd.d/*res*
※該当ファイルの削除確認が表示されますので y で削除してください。
(何度もリソース作成をしていたので、何回も削除をして疲れた思い出があります。)
コミュニケーションパス作成時
リソース拡張前にコミュニケーションパスを作成する
リソース拡張という操作をするのですが、そもそもリソース拡張とは、なんぞやというところですが
リソース拡張とは1号機、2号機で作成したリソースを簡単に言うと紐づける動作となります。
その際の動作ですが、コミュニケーションパスで接続されているサーバーがないとそもそもLifeKeeper側で認識ができず、拡張ができないとのことです。
なので、先にコミュニケーションパスの作成をしましょうというお話です。
ちなみに、コミュニケーションパスの作成が完了し1号機、2号機が接続されている状態でリソース拡張先のサーバーでも該当のARL(今回の場合 DRBD ARK) やとLifeKeeperの設定をGUI上で行うLKWMC のインストールの準備が必要となります。こちらが行えていたら、リソース拡張操作で DRBD リソースの拡張が行えるようになります。
名前解決
コミュニケーションパスの作成時にも、もちろん(？)エラーが発生しました。
エラー原因は1号機、2号機間での名前解決が出来ていないからでした。
今回は、hostsファイルに対象のホスト名を明記し、解消しました。
192.168.xx.xx
10.142.xx.xx
対象ポートの許可
以下のTCPポートの許可設定が必要となります。
| サービス | ポート番号 |
|---|---|
| コミュニケーションパス (TCP) | 7365/tcp |
| GUI サーバーとの通信 | 81/tcp、82/tcp |
| GUI サーバーとクライアントとの RMI 通信 | 1024/tcp 以降の全ポート |
| LKWMCの通信GUIサーバー | 5110/tcp |
| LKWMCのREST APIサーバー | 5000/tcp |
Disaster Recovery Add-on機能の確認時
無事DRBDリソース作成及び拡張ができ、設定が完了したかと思い、機能の確認をしたのですが想定通りの動作がせず困ったことに、、、
そこで有識者に確認をしてみたところQuorum/Witness の設定をしてみたらどうかとの見解を頂きました。
上記3つの資料を参考にQuorum/Witnessの設定をしてみたのですが、/opt/LifeKeeper/bin/qwk_storage_initを実行でエラーが出てしまいました。
よくよく確認すると、AWS CLIの設定を修正(アクセスキー設定を統一)して再度実行したところ解消しました。
その後、東京リージョンのノードを落として、データレプリケーションが大阪ノードで行われるかの機能について確認したところ、
無事フェイルオーバーとデータレプリケーションを確認できました！復旧後の動作も問題なく確認できたため検証終了となりました。
＃cat /etc/default/LifeKeeper
NOBCASTPING=1
QUORUM_MODE=storage
WITNESS_MODE=storage
～以下省略～
# Do NOT edit LK_DISTRIBUTION values – this may cause LifeKeeper to malfunction
LK_DISTRIBUTION=redhat
LK_DISTRIBUTION_VERSION=9.4-0.4.el9
QWK_STORAGE_TYPE=aws_s3
QWK_STORAGE_OBJECT_ip_10_142_xx_xx_compute_internal=s3://drbd/～
QWK_STORAGE_OBJECT_ip_10_142_xx_xx_compute_internal=s3://drbd/～
QWK_STORAGE_OBJECT_ip_192_168_xx_xx_compute_internal=s3://drbd/～
まとめ
今回の検証作業では、一歩進んでは躓き、そこからまた一歩進んだかと思えば違う壁にぶつかりと一進一退の作業でした。
今回行ったトラブルシューティングの対応を今後に活かしていき、スムーズなLifeKeeperの構築を目指していきたいです。
本記事についてより詳しい内容を知りたい方がいらっしゃいましたら
以下画像をクリックし、HPよりお気軽にお問い合わせください。
