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

image1
Pocket

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

前回は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でもご購読できます。