QSP(Quick Service Protection)を使ったSquidのHAクラスター化(後編:Phase3)

    こんにちは。
    サイオステクノロジー國政です。プリセールスを担当しております

    前回はLifeKeeperの機能であるQSPを利用してスクリプトを書かずに簡単にsquidをHAクラスター化してみました。
    おさらいも含めて構成上の主なポイントを記載します。

    構成上のポイント

    < Phase1 >
    ・シングル構成でsquidサーバーを準備し、クライアントからの動作確認をする

    < Phase2 >
    ・LifeKeeperを導入、2台目のサーバーにも同様にsquidを導入、設定
     ただし、squidの設定ファイルは各サーバー上で保持
    ・LifeKeeperの機能であるQSPにてスクリプトを書かずに短時間でHAクラスター構成を
     行った
    ・仮想IPとQSPを連携させ、クラインとからのアクセスを仮想IPで受ける事で、可用性を
     担保した
    ・ホストの切り替えに伴う共有データ領域はない。ログなども各サーバーで保持している

    しかし、解析に必要なデータなどは2台のサーバーで共有、保存、利用をしたい
    ⇒ここが今回のPhase3のテーマとなります。

    Phase3 構成図

    Phase3 構成図

     設定のおおまかな流れ

    1.DataKeeperの設定
    2.サーバーの時刻同期の再確認(chronydかntpの利用)
    3.レプケーション領域へのログの配備
    4.qsp-aである程度稼働させたのち、qsp-bへ手動フェイルオーバーを発生
      ログなど正しく追従しているか確認
    5.再度切り替えを実施し、同じくログが正しく追従しているか確認

    では、さっそく進めていきましょう。

    <Phase 3>

    LifeKeeper管理画面上の image2マークをクリックし、リソース作成ウィザードを利用します。
    Data Replicationを選択します。

    image3

    Switchback Typeは intelligentで設定します。

    image4

    qsp-aサーバーから

    image5

    Replicate New Filesystemで新規作成を行います。

    image6

    DataKeeperで利用するディスクを選択します。今回は/dev/sdb(5.0GB)を利用します。

    image7

    選択したディスクは共有されていませんと言った警告が表示されますが、Continueで進めます。

    image8

    DataKeeperで利用するミラー領域のマウントポイントを入力します。
    (/mnt./mirrorとしています)

    image9

    作成するファイルシステムの種類を選択します。(ext3で作成しています)

    image10

    DataKeeper管理用のタグを指定します。(通常はこのままでOKです)

    image11

    ファイルシステムリソースのタグ名を指定します。(通常はこのままでOKです)

    image12

    Bitmapファイルの生成位置を指定します。(通常はこのままでOKです)

    image13

    同期モードもしくは非同期モードの選択画面になります。今回は同期モードで
    作成する為、非同期モードを有効にするかどうかの問いは「no」とします。

    image14

    qsp-a側での設定がすべて済みましたので作成前の確認が表示されています。
    内容を確認して[create]を押下する事でData Replication Resourceがqsp-a側で作成されます。

    image15

    次にqsp-b側への拡張(設定反映)ウィザードが表示されます。
    ここは、Accept Defaultsで進めます。

    image16

    Accept Defaultsで進めた場合も、ターゲットディスクの指定は必要で、
    当該箇所で選択を促されるので、(/dev/sdb 5.0GB)を選択します。

    image17

    レプリケーションに利用するネットワークを選択します。
    (2本目の172セグメントをレプリケーション用に指定します)

    image18

    これまでの入力にてDataKeeperで利用する設定が済みました。
    最後に[Finish]を押下します。

    image19

    Doneを押下します。

    image20

    既にある仮想IPリソース、QSPリソースとの連携を取る為にリソースに依存関係を作成します。(QSP-squidタグにて Create Dependency…)をクリックします。

    image21

    QSPの下に来るものをデータレプリケーションリソースとするための設定を行います。

    image22

    設定内容に間違いがなければ、Create Dependencyを押下します。

    image23

    暫くすると、設定した依存関係が作成されます。

    image24

    同様の作業にて、IPリソース、qsp-squid、DataKeeperの関係になるよう設定します。
    (以下のような依存関係を持つように設定します)

    image25

    以上でDataKeeperの設定は完了です。

    続いで時刻同期の設定確認を行います。
    ※この部分は導入するOSやインストールタイプによって違ってきます。
    一例としてntpをyumでインストール、設定していますが、環境によって調整してください。
    これは両方のサーバーで設定を行い、時刻同期が実施されている事を確認しておいてください。

    image26

    qsp-a側での確認(ntpq -pコマンドでも実行状況を確認)、自動起動の設定も行っておきます。

    image27

    qsp-b側での確認(ntpq –pコマンドでも実行状況を確認) 自動起動の設定も行っておきます。

    image28

     

    さて、ここまできたら、次の考察点です。
    squid自体いろいろなログやキャッシュなどを保持する事が可能です。
    LifeKeeperで利用する上で考慮すべき点は、「サーバーが切り替わった場合でも継続して利用するデータがあるか、ある場合はDataKeeperの領域に置く」事となります。
    アクセス解析に必要なaccess.logやcache.logなども共有する必要があれば、DataKeeperのミラー領域へ配置すればよいと思います。

    今回はサーバー切り替わり前後で必要なログとしては、解析に利用する事が多いaccess.logを両方のサーバーでたとえサーバー切り替わりが発生したとしても継続して利用できるように設定をしていきたいと思います。

    設計思想:squidのログは通常の/var/log/squid以下の他にDataKeeperのミラー領域へも出力する各サーバーのローカルと、ミラーリング領域の2つ出力します。

     

    では、DataKeeperミラー領域へログを出す設定を行います。(qsp-a/qsp-b両方同じ作業です)

    image29

    ログフォーマットを指定する事も可能ですので、少し見やすくするために形式を指定する事と、ログの書き出し先を2箇所に設定して設定ファイルを保存します。

    image30

    初めのaccess.logだけミラー領域へ作成し、squidでアクセス可能なように属性を変更しておきます。

    image31

    一旦squidのプログラムを再スタートさせておきます。

    image32

    ログをリアルタイム更新させながら、クライアントからのアクセスで表示が更新されるか確認します。

    image33

    きちんと更新され、ログの量も増えていきます。(正常動作)

    image34

    続いてqsp-b側での設定動作確認を行う為、DataKeeperのアクティブなミラー領域をqsp-b側へ切り替えます。
    qsp-b側のIPリソースの上で[In Service]を実行します。

    image35

    qsp-b側が稼働系として動作し、DataKeeperのアクティブもqsp-bがSource、qsp-aがTargetと変わっています。

    image36

    切り替え直後のDataKeeperミラー領域の状態を見てみると、少し更新されている様子、
    ではtailコマンドで確認しながらクライアントからアクセスしてみましょう。

    image37

    クライアントからのアクセスに追従してログの増加が確認できました。
    では、サーバーを切り替えて今アクセスしたログが保存されているか確認します。

    image38

    今度はqsp-aのIPリソースの上でIn Serviceを実施し、稼働系をqsp-aに切り替えます。

    image39

    image40

    量が少ないのでcatコマンドで開きましたが、量が多い場合は別の方法で確認してください。
    切り替え前のsios.jpへのアクセスの記録など必要な情報は記載されています。

    image41

    次に、DataKeeperのミラー領域に配置したログのローテーションも考えておきます。
    これも一例としてご参照下さい。

    squidのログローテーションに必要な設定ファイルを開きます。

    image42

    既存設定は変更ぜずにミラー領域に配置したaccess.logを対象としています。
    ログローテーションの設定につきましては、OS付属のマニュアルや各種情報をご参照下さい。

    image43

    ログローテーションのテストを実行してみます。

    image44

    今は必要がない旨のメッセージが出力されます。

    image45

    一度強制的にログのローテーションを実行してみます。

    image46

    設定通りに動作している事を確認。

    image47

    これらの処理はミラー領域にアクセスできる必要があるので、qsp-b側へ再度切り替えます。

    image48

    qsp-bでもクライアントPCからのアクセスログを少し貯めてから、ローテーションの
    テスト実行、強制実行を行い新たにローテーションされたログが生成される事を確認します。

    image49

    以上、Phase1/Phae2/Phase3の各段階においての解説を行ってきました。
    squidの冗長化はいろいろ難しい部分もあるかと思いますが、LifeKeeperを使えば、「標準搭載機能のQSPで」「スクリプトを書かずに」「簡単に」設定頂ける事がわかると思います。

    QSPがない時は、汎用フレームワークであるGeneric ARKを利用し、各種スクリプトを準備せざるを得なかった場合と比較してHA構成の敷居はQSPにより大きく下がると思います。

    LifeKeeper for Linuxのversion9.1以降であれば、既存のLifeKeeperシステムにQSPでこのような機能を足す事もできますので利用用途を広げる意味でのご検討も有益ではないかと思います。

    SNSでもご購読できます。