Generic リソースとサンプルスクリプトを使って PostgreSQLをクラスター化してみた【Windows】

    system-structure1

    LifeKeeper for Windowsの機能の一つである Generic リソースを用いて、LifeKeeperでリカバリーキットとして提供されていないアプリケーションを保護することができます。

    Generic リソースを作成するためには、保護対象のアプリケーションを制御するためのスクリプトを作成する必要があります。
    LifeKeeper for Windows にはWindowsサービスで制御されるアプリケーションをLifeKeeper で制御するためのGeneric リソースのサンプルスクリプトが同梱されており、本サンプルスクリプトを用いることでWindowsサービスにより制御されるアプリケーションをLifeKeeperへ登録することができます。

    本稿では、WindowsアプリケーションをLifeKeeper for WindowsでHAクラスター化する例として、PostgreSQLサービスに上述のサンプルスクリプトを用いてHAクラスター化する方法を紹介します。

    システム構成 

    クラウド基盤:AWS (シングルAZ構成)
    OS:Windows Server 2012 R2 Standard Edition
    LifeKeeper:version 8.4 (非共有ディスク構成のためDataKeeper を使用)
    PostgreSQL:PostgreSQL-9.5.6-1a-win64
    ※LifeKeeper/DataKeeperのインストール、および PostgreSQL のインストールは、各種マニュアルをご参照ください。

    システム構成図 

    system-structure1 system-structure2

    Webサーバホスト名:WEB
    DBサーバホスト名:POSTGRES1、POSTGRES2
    コミュニケーションパス:192.168.2.90/192.168.2.91
    DataKeeper ボリューム:Dドライブ
    レプリケーション用ネットワーク:192.168.2.90/192.168.2.91
    PostgreSQLアプリケーションは両方のホストへインストールし、PostgreSQLのDBデータはDataKeeperボリュームのDドライブへ配置します。

    今回の構築における制限事項 

    今回の構築では、GenericリソースとしてLifeKeeperへ登録したPostgreSQLサービスの冗長化のみに焦点を当てて、リソースの手動切り替えや障害発生時の自動フェイルオーバを検証しています。そのため、本来HA構成されたDBサーバが持つ代表IPアドレスの保護については今回の構築では考慮しておらず、IPアドレスを保護するIPリソースは作成していません。

    以下の前提で環境構築を行っています。

    ● AWS EC2構成
    ・ シングルAZ (Availability Zone A) 内の同一サブネット上にWebサーバ1台とDBサーバ2台を配置する構成を想定しています。
    ・ EC2のセキュリティグループのインバウンド設定として、subnet 192.168.2.0/24 の範囲に限定して1/tcp~65535/tcpを開放するカスタムTCPルールを追加しています。
    ・ WebサーバのみにElastic IPを割当て、AWSの外部からWebサーバへアクセスすることを想定します。

    ● サーバ環境
    ・ Webサーバのアプリケーション構築は行わず、WebサーバからみてPostgreSQLリソースが切り替わることのみを確認します。これを満たすため、Webサーバ上でLifeKeeper GUIを表示し、PostgreSQLリソースの切り替えを確認します。
    ・ DBサーバ上にLifeKeeper、DataKeeperとPostgreSQLをインストールします。
    ・ LifeKeeperのコミュニケーションパスは1本のみ作成しています。本コミュニケーションパスで、LifeKeeperノード間のハートビートとDataKeeperボリュームのレプリケーションを共用します。

    構築の流れ 

    LifeKeeperおよびDataKeeperの設定は完了しているものとし、Postgres1がActive、Postgres2がStandbyとなっている事を前提とします。

    step1

     

    1. POSTGRES1サーバでPostgreSQLをインストールします。
    データベース領域は、DataKeeperボリュームのD:ドライブ配下を指定します。

    step2

    2. Windowsサービス画面を開き、インストールしたPostgreSQLのサービスの「スタートアップの種類」設定を手動に変更します。

    step3

    3. 同様にPOSTGRES2サーバでPostgreSQLをインストールします。
     データベース領域については、1. で設定したフォルダパスと同じ場所を指定します。
     また、Windowsサービス画面で2.と同様にPostgreSQLサービスの「スタートアップの種類」設定を手動に変更します。

    4. WEBサーバ上のLifeKeeper GUIで、Genericリソースの作成を行います。
     リソース階層の作成 メニュー を起動し、以下を選択します。
     プライマリサーバ : [ POSTGRES1 ]
     バックアップサーバ : [ POSTGRES2 ]
     保護するアプリケーション : [ Generic Application ]

    5. 汎用アプリケーションリソースの作成画面で、以下のスクリプトのフォルダパスを指定します。
     Restoreスクリプト:C:\LK\Admin\kit\app\templates\example_service\restore.pl
     Removeスクリプト:C:\LK\Admin\kit\app\templates\example_service\remove.pl
     クイックチェックスクリプト [オプション] :
     C:\LK\Admin\kit\app\templates\example_service\quickcheck.pl
     ディープチェックスクリプト [オプション] : (指定せず空白のままとしてください)
     ローカルリカバリー [オプション]:
     C:\LK\Admin\kit\app\templates\example_service\recover.pl

    6. アプリケーション情報 [オプション] で、インストールしたPostgreSQLのサービス名を指定します。本項目に設定したサービスがLifeKeeperのGenericリソースで保護される動作となります。
    アプリケーション情報[オプション] : [ postgresql-x64-9.5 ]

    step4

    7. Genericリソースの設定として各々以下を指定し、PostgreSQL リソースを作成します。
     ローカル・リカバリーを有効にする:[ はい ]
     リソースタグ名:[ PostgreSQL ] (任意の名前で指定可能)
     バックアップの優先順位:[ 10 ]

    以上の操作で、PostgreSQLリソースの作成が完了します。

    step5

    8. 次に、作成したPostgreSQLリソースとDataKeeperのVol.Dリソースが連動して動作するように依存関係を作成します。

    step6

    以上で、LifeKeeperにおけるPostgreSQLリソースの作成は完了です。

    手動でのリソース切替 

    POSTGRES2上のPostgreSQLリソースを起動することで、手動切替を行えます。

    step7

    step8

    ローカルリカバリの動作確認 

    LifeKeeper for WindowsのGeneric の仕組みを用いて、PostgreSQLサービスがダウンした際に自動的にサービスを再起動させることができます。

    サービス管理画面で、稼働系LifeKeeperノード上で起動しているPostgreSQLサービスを手動で停止します。

    step9

    手動で停止した後に数分ほど時間を置き、サービス画面をリフレッシュするとPostgreSQLサービスが自動的に起動状態に遷移しています。

    step10

    障害テスト 

    上述のローカルリカバリではローカルリカバリスクリプトが実行されることでサービスが再起動しましたが、ローカルリカバリでもサービスが起動できなかった場合の動作を確認します。

    PostgreSQLリソースのローカルリカバリスクリプトが配置されている以下のフォルダへアクセスし、スクリプトファイル名を任意の名前へ変更します

    ローカルリカバリスクリプト配置場所:
    C:\LK\Subsys\gen\resources\app\actions\!recover\PostgreSQL

    ファイル名変更後:
    C:\LK\Subsys\gen\resources\app\actions\!recover\PostgreSQL.org

    step11

    スクリプトファイル名を変更することにより、ローカルリカバリ実行時に呼出されるスクリプトが存在せず、ローカルリカバリに失敗する動作となります。

    次に、ローカルリカバリ動作で操作したように、稼働系LifeKeeperノード上で起動しているPostgreSQLサービスを手動で停止します。

    step12

    手動で停止した後に数分ほど時間を置くと、ローカルリカバリスクリプトが存在しないことからLifeKeeperはローカルリカバリの処理に失敗し、対向側LifeKeeperへの切り替わりが発生します。

    step13

     

    以上にて、Generic リソースとサンプルスクリプトを用いたPostgreSQLのクラスター化作業は完了です。

    また、サンプルスクリプトを用いたGeneric リソースによるWindowsサービス保護の概要につきましては、以下のLifeKeeperナレッジでも記事を公開していますので、併せてご参照ください。

     [Windows]任意のWindowsサービスを冗長化可能なGeneric ARKサンプルスクリプト

     [ドキュメント][Windows] 汎用アプリケーションリソース開発の手引

    [ 免責事項 ]
    ・ 本資料に記載された情報は予告なしに変更、削除される場合があります。
    ・ 本資料に記載された情報は、全て慎重に作成され、記載されていますが、本資料をもってその妥当性や正確性についていかなる種類の保証もするものではありません。
    ・ 本資料に含まれた誤りに起因して、本資料の利用者に生じた障害については、サイオステクノロジー株式会社は一切の責任を負うものではありません。
    ・ 第三者による本資料の記載事項の変更、削除、ホームページおよび本資料等に対する不正なアクセス、その他第三者の行為により本資料の利用者に生じた一切の損害について、サイオステクノロジー株式会社は一切の責任を負うものではありません。

    本記事について気になる点やご質問等ありましたら、以下よりお気軽にお問い合わせください。

    SNSでもご購読できます。