本記事の検証内容は2021年2月時点の情報です。検証ではQuorum方式(Quorum/Witness Server Kitのstorage)でAzure共有ディスク構成を採っていますが、2022年9月リリースのLifeKeeper for Linux v9.6.2からSCSIリザーブ方式のAzure共有ディスク構成を採れます。LifeKeeper for LinuxでAzure共有ディスク構成を採る場合は、SCSI3 Recovery Kitを使用したSCSIリザーブ方式の共有ディスク構成の利用をご検討ください。
こんにちは、高正と申します。
しばらくLifeKeeper/DataKeeperというプロダクトから遠ざかっていましたが、再びこれらのプロダクトに関わっていくことになりました。みなさま今後ともどうぞよろしくお願いします。
さて、今回は、Azure 共有ディスク（=Azure Shared Disks）とLifeKeeper for Linuxの組みあわせで検証してみましたので、その内容をご紹介します。
はじめに
先日、WSFCとAzure 共有ディスクによるHAクラスター構成をやってみたをご紹介しましたが、続編としてLifeKeeper for LinuxでAzure 共有ディスクによるHAクラスター構成をやってみたと題して、ブログを書きました。LifeKeeperで共有ディスクを利用するときは、SCSIリザーブ方式とQuorum/Witness Server方式があります。SCSIリザーブ方式は、SCSIリザーブのコマンドを利用して、クラスターノード間の共有ディスクの排他制御を実現する方式です。一方、Quorum/Witness Server方式はSCSIリザーブのコマンドは使わずに、クラスターノード間の排他制御を実現する方式です。
今回は、Azure 共有ディスクによる共有ストレージ構成を組めることを期待してQuorum/Witness Server方式で検証しました。これまではLifeKeeper for LinuxはAzure上でHAクラスタのレプリケーション構成しか組めませんでしたが、Azure共有ディスクでHAクラスタの共有ディスク構成が組めれば、構成のバリエーションが増えますね。
なお、Azure Shared DiskについてはWSFCとAzure 共有ディスクによるHAクラスター構成をやってみたで解説していますので、本ブログではAzure 共有ディスクの解説と設定方法は省略させていただきます。
今回の検証のポイントは以下の2つです。
Azure 共有ディスクを使えば、Azure上でLifeKeeper for Linuxの共有ディスク構成が組める
Azure共有ディスクはQuorum/Witness Server Kitのstorageモードでスプリットブレイン対策をする
ブログを読んでいただいている方に、これらのポイントが伝われば、今回のブログの目的は達成したようなものです。今回の検証の具体的なシステム構成に興味がある人は残りのパートを読んでいただけると幸いです。それでは実際のHAクラスター構成を説明します。
HAクラスター構成のセットアップ
それでは本題に入りましょう。まず、Quorum/Witness Server方式を利用するにあたって、LifeKeeperのストレージサポートポリシーに書かれている要件をおさらいしましょう。
以下は該当箇所の引用です。
- OSやハードウェア、プラットフォームでサポート済みのストレージである
- LifeKeeper のSCSI Reservation 機能をオフにする
- LifeKeeper のQuorum/Witnessによるフェンシング機能を採用する
新しいストレージサポートポリシー（Any Storage）について
引用した箇所の1行目は、SCSIリザーブ方式ではなくても、ハードウェアベンダーやクラウドベンダーがサポートしているストレージであれば、サポートするという意味合いです。今回はマイクロソフトのAzureで提供しているAzure 共有ディスクだからサポート条件は満たしていると判断できます。
システム構成
Virtual machine
・Operating system: Linux (centos 8.2.2004)
・LifeKeeper: LifeKeeper for Linux 9.5.1
LifeKeeperで設定するもの
・コミュニケーションパス2本
・DataKeeperリソース
・Storage Quorum/Witness(Azure Shared Diskを利用)
アクティブ、スタンバイの2台を用意し、それぞれのノードからAzure 共有ディスクを参照するシンプルなシステム構成です。オンプレの共有ディスクと同等にAzure 共有ディスクが使えることを確認するためのシンプルな構成です。実際に本番環境で利用するときは、HAクラスターで制御する仮想IPやアプリケーションを準備しますが、今回はAzure共有ディスクがオンプレの共有ディスクと同等にHAクラスターとして動作するかを評価するのが目的としていたため、今回は仮想IPやアプリケーションの準備はしません。その点をご了承ください。
Quorum設定
基本的にはQuorum に関する設定は、オンラインマニュアルに書かれているリザベーションの無効化と製品ユーザーポータルに書かれている設定を行うだけです。製品ユーザーポータルではblock, file, aws_s3の3種類がありますが、今回はblockの箇所を読み進めて設定を行いました。
ちなみに私は、ホスト名をmtakasho-ika、mtakasho-takoと‐(ハイフン)を含む形式だったため、qwk_storage_initコマンド実行時にエラーが発生し、少しだけつまづきました。もし、私と同じようにホスト名にハイフンを含む場合は、製品ユーザーポータルに書かれている回避策を適用してください。
動作確認
HAクラスターの動作確認は、Storage Quorum/Witness がシナリオ通りに動作するかという観点で評価しました。オンラインマニュアルにStorage Quorum/Witness利用時のシナリオ毎の動作が書かれています。シナリオは1から3まであります。3つのシナリオすべて期待する結果になりました。私が動作確認のために、実際に行ったことをシナリオ毎にご説明します。
シナリオ１
ノード A とノード B の間のコミュニケーションパス通信に障害が発生（ノード A とノード B とも共有ストレージにアクセス可能）
コミュニケーションパスの通信障害を起こすために、コミュニケーションパスに設定しているネットワークインターフェースを以下のipコマンドで停止させました。すると、オンラインマニュアルのシナリオの説明に書かれている通り、フェイルオーバは発生しませんでした。
ip link set eth1 downシナリオ２
ノード A に障害が発生してノード A が停止
稼働系で下記のコマンドで意図的にカーネルパニックを発生させました。すると、オンラインマニュアルのシナリオの説明に書かれてる通り、フェイルオーバが発生しました。
echo c > /proc/sysrq-triggerシナリオ3
ノード A のネットワークに障害が発生（ノード A は稼働しているが、他のノードや共有ストレージにアクセス不能）
行ったことは、以下の2つです。
稼働系の仮想マシンのコミュニケーションパスに設定しているネットワークインターフェースを停止させること
AzureポータルからQuorum用に利用しているLUNの共有ディスクを稼働系からデタッチ
AzureポータルでLUNをデタッチするには、対象のLUNの行の画面右側の青色のバツボタンをクリックして、ポータル上部のある保存ボタンをクリックするだけです。LUNをデタッチして、しばらくすると、フェイルオーバが発生しました。
まとめ
オンプレの共有ディスクの代わりにAzure 共有ディスクを使いましたが、LifeKeeperは共有ストレージ構成を組むために、Quorum/Witness Serverの設定を行っただけで、特別な設定は行っておりません。これまではLifeKeeper for Linux on Azureではレプリケーション構成しかHAクラスターを組めませんでしたが、Azure 共有ディスクの登場によって、共有ディスクのHAクラスターが組めるようになりました。LifeKeeperでAzure 共有ディスクを使って、共有ディスク構成を取る場合は、Quorum/Witness Server方式をご利用ください。
最後に、本ブログで取り上げた内容は、十分な検証を行っておりますが、実際にお客様にてAzure 共有ディスクの構成を検討の際は、評価版等をご利用のうえ、期待する動作となるか十分な検証を行うようにしてください。
参考情報
https://docs.us.sios.com/spslinux/9.7.0/ja/topic/how-to-setup-azure-shared-storage
関連記事
