こんにちは。
サイオステクノロジー國政です。プリセールスを担当しております
前回はLifeKeeperの機能であるQSPを利用してスクリプトを書かずに簡単にsquidをHAクラスター化してみました。
おさらいも含めて構成上の主なポイントを記載します。
構成上のポイント
< Phase1 >
・シングル構成でsquidサーバーを準備し、クライアントからの動作確認をする
< Phase2 >
・LifeKeeperを導入、2台目のサーバーにも同様にsquidを導入、設定
ただし、squidの設定ファイルは各サーバー上で保持
・LifeKeeperの機能であるQSPにてスクリプトを書かずに短時間でHAクラスター構成を
行った
・仮想IPとQSPを連携させ、クラインとからのアクセスを仮想IPで受ける事で、可用性を
担保した
・ホストの切り替えに伴う共有データ領域はない。ログなども各サーバーで保持している
しかし、解析に必要なデータなどは2台のサーバーで共有、保存、利用をしたい
⇒ここが今回のPhase3のテーマとなります。
設定のおおまかな流れ
1.DataKeeperの設定
2.サーバーの時刻同期の再確認(chronydかntpの利用)
3.レプケーション領域へのログの配備
4.qsp-aである程度稼働させたのち、qsp-bへ手動フェイルオーバーを発生
ログなど正しく追従しているか確認
5.再度切り替えを実施し、同じくログが正しく追従しているか確認
では、さっそく進めていきましょう。
＜Phase 3＞
LifeKeeper管理画面上の 
マークをクリックし、リソース作成ウィザードを利用します。
Data Replicationを選択します。
Switchback Typeは intelligentで設定します。
qsp-aサーバーから
Replicate New Filesystemで新規作成を行います。
DataKeeperで利用するディスクを選択します。今回は/dev/sdb(5.0GB)を利用します。
選択したディスクは共有されていませんと言った警告が表示されますが、Continueで進めます。
DataKeeperで利用するミラー領域のマウントポイントを入力します。
(/mnt./mirrorとしています)
作成するファイルシステムの種類を選択します。(ext3で作成しています)
DataKeeper管理用のタグを指定します。(通常はこのままでOKです)
ファイルシステムリソースのタグ名を指定します。(通常はこのままでOKです)
Bitmapファイルの生成位置を指定します。(通常はこのままでOKです)
同期モードもしくは非同期モードの選択画面になります。今回は同期モードで
作成する為、非同期モードを有効にするかどうかの問いは「no」とします。
qsp-a側での設定がすべて済みましたので作成前の確認が表示されています。
内容を確認して[create]を押下する事でData Replication Resourceがqsp-a側で作成されます。
次にqsp-b側への拡張(設定反映)ウィザードが表示されます。
ここは、Accept Defaultsで進めます。
Accept Defaultsで進めた場合も、ターゲットディスクの指定は必要で、
当該箇所で選択を促されるので、(/dev/sdb 5.0GB)を選択します。
レプリケーションに利用するネットワークを選択します。
(2本目の172セグメントをレプリケーション用に指定します)
これまでの入力にてDataKeeperで利用する設定が済みました。
最後に[Finish]を押下します。
Doneを押下します。
既にある仮想IPリソース、QSPリソースとの連携を取る為にリソースに依存関係を作成します。(QSP-squidタグにて Create Dependency…)をクリックします。
QSPの下に来るものをデータレプリケーションリソースとするための設定を行います。
設定内容に間違いがなければ、Create Dependencyを押下します。
暫くすると、設定した依存関係が作成されます。
同様の作業にて、IPリソース、qsp-squid、DataKeeperの関係になるよう設定します。
(以下のような依存関係を持つように設定します)
以上でDataKeeperの設定は完了です。
続いで時刻同期の設定確認を行います。
※この部分は導入するOSやインストールタイプによって違ってきます。
一例としてntpをyumでインストール、設定していますが、環境によって調整してください。
これは両方のサーバーで設定を行い、時刻同期が実施されている事を確認しておいてください。
qsp-a側での確認(ntpq -pコマンドでも実行状況を確認)、自動起動の設定も行っておきます。
qsp-b側での確認(ntpq –pコマンドでも実行状況を確認) 自動起動の設定も行っておきます。
さて、ここまできたら、次の考察点です。
squid自体いろいろなログやキャッシュなどを保持する事が可能です。
LifeKeeperで利用する上で考慮すべき点は、「サーバーが切り替わった場合でも継続して利用するデータがあるか、ある場合はDataKeeperの領域に置く」事となります。
アクセス解析に必要なaccess.logやcache.logなども共有する必要があれば、DataKeeperのミラー領域へ配置すればよいと思います。
今回はサーバー切り替わり前後で必要なログとしては、解析に利用する事が多いaccess.logを両方のサーバーでたとえサーバー切り替わりが発生したとしても継続して利用できるように設定をしていきたいと思います。
設計思想:squidのログは通常の/var/log/squid以下の他にDataKeeperのミラー領域へも出力する各サーバーのローカルと、ミラーリング領域の2つ出力します。
では、DataKeeperミラー領域へログを出す設定を行います。(qsp-a/qsp-b両方同じ作業です)
ログフォーマットを指定する事も可能ですので、少し見やすくするために形式を指定する事と、ログの書き出し先を2箇所に設定して設定ファイルを保存します。
初めのaccess.logだけミラー領域へ作成し、squidでアクセス可能なように属性を変更しておきます。
一旦squidのプログラムを再スタートさせておきます。
ログをリアルタイム更新させながら、クライアントからのアクセスで表示が更新されるか確認します。
きちんと更新され、ログの量も増えていきます。(正常動作)
続いてqsp-b側での設定動作確認を行う為、DataKeeperのアクティブなミラー領域をqsp-b側へ切り替えます。
qsp-b側のIPリソースの上で[In Service]を実行します。
qsp-b側が稼働系として動作し、DataKeeperのアクティブもqsp-bがSource、qsp-aがTargetと変わっています。
切り替え直後のDataKeeperミラー領域の状態を見てみると、少し更新されている様子、
ではtailコマンドで確認しながらクライアントからアクセスしてみましょう。
クライアントからのアクセスに追従してログの増加が確認できました。
では、サーバーを切り替えて今アクセスしたログが保存されているか確認します。
今度はqsp-aのIPリソースの上でIn Serviceを実施し、稼働系をqsp-aに切り替えます。
量が少ないのでcatコマンドで開きましたが、量が多い場合は別の方法で確認してください。
切り替え前のsios.jpへのアクセスの記録など必要な情報は記載されています。
次に、DataKeeperのミラー領域に配置したログのローテーションも考えておきます。
これも一例としてご参照下さい。
squidのログローテーションに必要な設定ファイルを開きます。
既存設定は変更ぜずにミラー領域に配置したaccess.logを対象としています。
ログローテーションの設定につきましては、OS付属のマニュアルや各種情報をご参照下さい。
ログローテーションのテストを実行してみます。
今は必要がない旨のメッセージが出力されます。
一度強制的にログのローテーションを実行してみます。
設定通りに動作している事を確認。
これらの処理はミラー領域にアクセスできる必要があるので、qsp-b側へ再度切り替えます。
qsp-bでもクライアントPCからのアクセスログを少し貯めてから、ローテーションの
テスト実行、強制実行を行い新たにローテーションされたログが生成される事を確認します。
以上、Phase1/Phae2/Phase3の各段階においての解説を行ってきました。
squidの冗長化はいろいろ難しい部分もあるかと思いますが、LifeKeeperを使えば、「標準搭載機能のQSPで」「スクリプトを書かずに」「簡単に」設定頂ける事がわかると思います。
QSPがない時は、汎用フレームワークであるGeneric ARKを利用し、各種スクリプトを準備せざるを得なかった場合と比較してHA構成の敷居はQSPにより大きく下がると思います。
LifeKeeper for Linuxのversion9.1以降であれば、既存のLifeKeeperシステムにQSPでこのような機能を足す事もできますので利用用途を広げる意味でのご検討も有益ではないかと思います。
