※この記事は翻訳されたものです。本記事の原文はこちら
この記事では、SIOS Lifekeeper for LinuxのGeneric Load-Balancer Application Recovery Kit (ARK) と、Google Cloud上での具体的な設定方法について説明します。ARKは、LifeKeeper製品がプラットフォームやアプリケーションを認識できるようにするプラグインです。
この記事では、2ノードのNFSクラスターとそれが提供するNFSエクスポートを使用して、最終的にロードバランサー経由でアクセスする方法を紹介します。
SIOSは、GCP上で動作しているLifeKeeperクラスターにおいて、クライアントのリダイレクトを容易にするために、このARKを作成しました。
GCPはGratuitous ARP（GARP：ルーター自体のIPアドレスに対するブロードキャストリクエスト）をサポートしていないため、クライアントは従来のクラスターの仮想IPアドレスに直接接続できません。よってクライアントはロードバランサーに接続する必要があり、ロードバランサーはトラフィックをアクティブなクラスターノードにリダイレクトします。
GCPは、レイヤー4 TCP、レイヤー4 UDPまたはレイヤー7 HTTP/HTTPで動作する個別のロードバランサーソリューションを実装しています。ロードバランサーは、プライベートまたはパブリックのフロントエンドIP、どのノードがアクティブかを判断できるヘルスチェックプローブ、一連のバックエンドIPアドレス（クラスターの各ノード用）と受信/送信ネットワークトラフィックルールを持つように構成できます。
従来、ヘルスチェックプローブはアプリケーションのアクティブポートを監視し、そのアプリケーションがどのノードでアクティブかを判断していました。 Generic Load-balancer ARKは、アクティブノードがユーザー定義のポートでリッスンするように設定されています。このポートは、GCPロードバランサーでヘルスチェックプローブとして構成されます。これにより、アクティブなクラスターノードがTCPヘルスチェックプローブに応答できるようになり、クライアントの自動リダイレクトが可能になります。
GCP でのインストールと構成は簡単
GCPポータル内で、負荷分散を選択します。
この例では、TCP負荷分散を選択します。
ロードバランサーを作成し、これをデプロイするリソースグループと名前を選択します。IMAでロードバランサーを使用しているクラスタータイプと一致する名前を使用すると良いでしょう。たとえば、IMA-NFS-LBは両方のIMA-NFSノードの前に配置されます。
インターネットに接続するのか、VPCの内部なのかを決定します。この例では、VPC内でのみ使用するために、NFSサーバーの前に内部専用ロードバランサーを構成しています。
名前、リージョンなどを決定したら、バックエンド構成を割り当てるように求められます。これには、フロントエンドにするHAノードを含むインスタンスグループが必要です。
インスタンスグループを割り当てたら、ヘルスチェックを定義します。これは、Lifekeeper Generic Load-balancerの設定で使用するポートと同じポートです。この例では、54321を使用しています。
Lifekeeperで使用するため、ここでもポート番号に注意してください。
この例では、Health基準のデフォルト値をそのまま使用しています。
ロードバランサーのバックエンド構成情報とヘルスチェックを入力したら、フロントエンド構成を定義する必要があります。これは、ロードバランサー用に作成するサブネット、リージョン、IPで構成されています。
IPを設定します。これは保護しているLifekeeperのIPと同じにします。
設定が完了したら、内容を確認するか、 [作成] をクリックします。
[作成] を選択すると、GCPがロードバランサーのデプロイを開始します。これには数分かかることがあり、完了すると、SIOS Protection Suiteの設定に移行します。
Configuration with SIOS Protection Suite SIOS Protection Suiteでの設定
このブログでは、SPS-Lを使用して保護されるように3つのNFSエクスポートを設定しました。3つのエクスポートは、GCPロードバランサのフロントエンドIPと同じIPを使用するよう設定されています。
Datakeeperを使用して、エクスポートに保存されているデータを複製しています。
まず、スクリプトを取得します。wgetを使用するのが一番簡単ですが、パッケージ全体をダウンロードし、winscpなどのツールを使用してrpmを直接ノードにアップロードすることもできます。Lifekeeperクラスター内のすべてのノードにHotfixをインストールする必要があります。
Recovery Kit全体は、以下で入手できます。
http://ftp.us.sios.com/pickup/LifeKeeper_Linux_Core_en_9.5.1/patches/Gen-LB-PL-7172-9.5.1
パーツは、wgetを使用して以下から取得できます。
wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm
wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm.md5sum
wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/Gen-LB-readme.txt
ダウンロードしたら、FTPサイトに記録されている値とMD5の合計を照合します。
以下でRPMをインストールします。
rpm -ivh steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm
以下を実行して、インストールが成功したことを確認します。
rpm -qa | grep steeleye-lkHOTFIX-Gen-LB-PL-7172
何らかの理由で RPM を削除する必要がある場合は、次のコマンドを実行して削除できます。
rpm -e steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64
以下は、すでに設定した3つのNFSエクスポートが表示されているGUIです。
SIOS Protection Suite内では、SIOSが提供するHotfixスクリプトを使用してロードバランサーを定義する必要があります。
まず、新しいリソース階層を作成し、ドロップダウンからGeneric Applicationを選択します。
/opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ にある restore.pl スクリプトを定義します。
/opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ にある remove.pl スクリプトを定義します。
/opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/ にある quickCheck スクリプトを定義します。
ローカルリカバリースクリプトはありませんので、この入力は必ずクリアしてください。
アプリケーション情報を求められたら、ヘルスチェックのポート番号で設定したのと同じ番号を入力します。例：54321
サービスが作成されたら、In Serviceにすることを選択します
リソース タグは、SPS-L GUIに表示される名前です。識別しやすい名前を使用すると良いでしょう。
すべてが正しく設定されていれば、「END successful restore」と表示されます。次に、これをもう一方のノードに拡張して、リソースをどちらのノードでもホストできるようにします。
これは、両方のノードへの拡張後、完了したロードバランサーの設定を示しています。
このクラスターでの最後のステップは、3つのNFSエクスポートの子依存関係を作成することです。これは、DatakeeperミラーとIPを持つすべてのNFSエクスポートがロードバランサーに依存することを意味します。アクティブなノードで深刻な問題が発生した場合、これらのリソースはすべて、機能している他のノードにフェイルオーバーされます。
上の画像は、Lifekeeper GUIでの完成した階層構造です。下の画像は、ロードバランサーリソースの子として、NFSエクスポート、IP、ファイルシステム、DataKeeperレプリケートボリュームを示す、拡張版のGUIのビューです。
これは、GCPでLifeKeeperを使用して、シンプルなNFSクラスターを保護する方法の一例です。同じコンセプトは、保護が必要なビジネスクリティカルなアプリケーションにも適用できます。SIOSが提供するGeneric ARK for Load Balancer probe replyを利用して、GCPロードバランサー（インターネットまたは内部）が、現在どのノードがアプリケーションをホストしているかを判断できるようにするだけでOKです。
