LifeKeeper for LinuxでAzure Shared DisksによるHAクラスター構成を組んでみた

    こんにちは、高正と申します。

    しばらくLifeKeeper/DataKeeperというプロダクトから遠ざかっていましたが、再びこれらのプロダクトに関わっていくことになりました。みなさま今後ともどうぞよろしくお願いします。

    さて、今回は、Azure Share DisksLifeKeeper for Linuxの組みあわせで検証してみましたので、その内容をご紹介します。

    はじめに

    先日、WSFCとAzure Shared DisksによるHAクラスター構成をやってみたをご紹介しましたが、続編としてLifeKeeper for LinuxでAzure Shared DisksによるHAクラスター構成をやってみたと題して、ブログを書きました。LifeKeeperで共有ディスクを利用するときは、SCSIリザーブ方式とQuorum/Witness Server方式があります。SCSIリザーブ方式は、SCSIリザーブのコマンドを利用して、クラスターノード間の共有ディスクの排他制御を実現する方式です。一方、Quorum/Witness Server方式はSCSIリザーブのコマンドは使わずに、クラスターノード間の排他制御を実現する方式です。

    今回は、Azure Shared Disksによる共有ディスク構成を組めることを期待してQuorum/Witness Server方式で検証しました。これまではLifeKeeper for LinuxはAzure上でHAクラスタのレプリケーション構成しか組めませんでしたが、Azure Shared DisksでHAクラスタの共有ディスク構成が組めれば、構成のバリエーションが増えますね。

    なお、Azure Shared DiskについてはWSFCとAzure Shared DisksによるHAクラスター構成をやってみたで解説していますので、本ブログではAzure Shared Disksの解説と設定方法は省略させていただきます。

    今回の検証のポイントは以下の2つです。

    • Azure Shared Disksを使えば、Azure上でLifeKeeper for Linuxの共有ディスク構成が組める

    • Azure Shared DisksはQuorum/Witness Server Kitのstorageモードでスプリットブレイン対策をする

    ブログを読んでいただいている方に、これらのポイントが伝われば、今回のブログの目的は達成したようなものです。今回の検証の具体的なシステム構成に興味がある人は残りのパートを読んでいただけると幸いです。それでは実際のHAクラスター構成を説明します。

    HAクラスター構成のセットアップ

    それでは本題に入りましょう。まず、Quorum/Witness Server方式を利用するにあたって、LifeKeeperのストレージサポートポリシーに書かれている要件をおさらいしましょう。
    以下は該当箇所の引用です。

    • OSやハードウェア、プラットフォームでサポート済みのストレージである
    • LifeKeeper のSCSI Reservation 機能をオフにする
    • LifeKeeper のQuorum/Witnessによるフェンシング機能を採用する

    新しいストレージサポートポリシー(Any Storage)について

    引用した箇所の1行目は、SCSIリザーブ方式ではなくても、ハードウェアベンダーやクラウドベンダーがサポートしているストレージであれば、サポートするという意味合いです。今回はマイクロソフトのAzureで提供しているAzure Shared Disksだからサポート条件は満たしていると判断できます。

    システム構成

    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 Shared Disksを参照するシンプルなシステム構成です。オンプレの共有ディスクと同等にAzure Shared Disksが使えることを確認するためのシンプルな構成です。実際に本番環境で利用するときは、HAクラスターで制御する仮想IPやアプリケーションを準備しますが、今回はAzure Shared Disksがオンプレの共有ディスクと同等に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つのシナリオすべて期待する結果になりました。私が動作確認のために、実際に行ったことをシナリオ毎にご説明します。

    シナリオ1
    ノード A とノード B の間のコミュニケーションパス通信に障害が発生(ノード A とノード B とも共有ストレージにアクセス可能)

    コミュニケーションパスの通信障害を起こすために、コミュニケーションパスに設定しているネットワークインターフェースを以下のipコマンドで停止させました。すると、オンラインマニュアルのシナリオの説明に書かれている通り、フェイルオーバは発生しませんでした。

    ip link set eth1 down

    シナリオ2
    ノード A に障害が発生してノード A が停止

    稼働系で下記のコマンドで意図的にカーネルパニックを発生させました。すると、オンラインマニュアルのシナリオの説明に書かれてる通り、フェイルオーバが発生しました。

    echo c > /proc/sysrq-trigger

    シナリオ3
    ノード A のネットワークに障害が発生(ノード A は稼働しているが、他のノードや共有ストレージにアクセス不能)

    行ったことは、以下の2つです。

    • 稼働系の仮想マシンのコミュニケーションパスに設定しているネットワークインターフェースを停止させること

    • AzureポータルからQuorum用に利用しているLUNのShared Disksを稼働系からデタッチ

    AzureポータルでLUNをデタッチするには、対象のLUNの行の画面右側の青色のバツボタンをクリックして、ポータル上部のある保存ボタンをクリックするだけです。LUNをデタッチして、しばらくすると、フェイルオーバが発生しました。

    まとめ

    オンプレの共有ディスクの代わりにAzure Shared Disksを使いましたが、LifeKeeperは共有ストレージ構成を組むために、Quorum/Witness Serverの設定を行っただけで、特別な設定は行っておりません。これまではLifeKeeper for Linux on Azureではレプリケーション構成しかHAクラスターを組めませんでしたが、Azure Shared Disksの登場によって、共有ディスクのHAクラスターが組めるようになりました。LifeKeeperでAzure Shared Disksを使って、共有ディスク構成を取る場合は、Quorum/Witness Server方式をご利用ください。

    最後に、本ブログで取り上げた内容は、十分な検証を行っておりますが、実際にお客様にてAzure Shared Disksの構成を検討の際は、評価版等をご利用のうえ、期待する動作となるか十分な検証を行うようにしてください。

    関連記事

    SNSでもご購読できます。