LVSを使ったブローカーの構築：｢keepalived.conf｣についての説明

今回構築から検証までの間で説明を省略していた
｢keepalived.conf｣について私が理解している範疇で説明します。

※誤り等あればご指摘いただけると助かります。。。

まず、説明の対象となる｢keepalived.conf｣を以下に掲載いたします。

なお、｢keepalived.conf｣の設定内容はスケジューリング方式や監視方式により変わる為、
ここでは、今回利用した設定を中心に説明を行います。

vrrp_instance句

VRRPとは｢Virtual Router Redundancy Protocol｣の略で、
ルータの多重化（ホットスタンバイ）を実現するプロトコルの事で、
｢vrrp_instance｣句ではその仮想ルータの設定について記載を行っています。

■state

仮想ルータの起動時の状態を指定します。
｢BACKUP｣または｢MASTER｣を指定できます。
なお、起動済みのMASTERルータが存在しない場合は、
いずれかのBACKUPルータがMASTERに昇格します。

■interface

仮想ルータで利用するインターフェースを指定します。

■ grap_master_delay

自身がMASTERルータに昇格した場合に送信するARPの遅延させる時間を設定します。

■ virtual_router_id

仮想ルータを識別する為のIDを設定します。
同一ルータを構成するBACKUPルータ等は同一のIDを指定する必要があります。

■priority

同一仮想ルータID内での優先度を指定します。
なお、｢PREEEMPT｣動作時は｢state｣の設定内容に関係なく
本値でMASTERルータが設定されます。

■nopreempt

｢NOPREEMPT｣動作に切り替えます。
｢NOPREEMPT｣動作中は優先度の高い仮想ルータが認識されても既に
同一仮想ルータID内に既にMASTERルータが存在する場合は
その後｢state｣に｢MASTER｣設定がされているルータを起動しても変更されません。

■ advert_int

仮想ルータを複数構成（冗長化）としている場合、その確認の間隔を指定します。

■ ｢authentication｣ブロック

仮想ルータを複数構成（冗長化）としている場合にインスタンス間で確認が行われますが、
その際の認証に関する設定を行うことができます。
同一仮想ルータIDは同一の設定となっている必要があります。
本ブロックでは｢auth_type｣と｢auth_pass｣を設定します。

□ auth_type

認証の手段を指定します。
｢PASS｣または｢AH｣が設定できます。
｢PASS｣を指定した場合は｢auth_pass｣に認証用の文字列を設定します。
｢AH｣を指定した場合は IPSecの認証ヘッダ(Authentication Header)を利用します。

□ auth_pass

｢auth_type｣に応じた認証用文字列を設定します。

■ ｢virtual_ipaddress｣ブロック

仮想ルータに設定するIPアドレス等の情報を設定します。

｢virtual_server｣句

仮想サーバに関する設定を行います。
なお、冒頭は｢virtual_server （仮想ルータIPアドレス） dev （使用インターフェース）｣
というフォーマットで記述します。

■ delay_loop

対象仮想サーバの監視間隔を設定します。

■ lvs_sched

実サーバへの転送時のアルゴリズム（スケジューリング方式）を設定します。
選択可能な方式としては以下のものがあります。

□rr：Round-Robin

実サーバに対し順番に振り分けを行います。

□wrr：Weighted Round-Robin

実サーバに設定された重みを考慮し振り分けを行います。
なお、重みが同一の場合は順番に振り分けを行うこととなります。

□lc：Least-Connection

確立したコネクション数がもっとも少ない実サーバに振り分けを行います。

□wlc：Weighted Least-Connection

重みを考慮した上で確立したコネクション数がもっとも少ない実サーバに振り分けを行います。

□lblc：Locality-Based Least-Connection

基本的に同一の接続元からの要求は同一サーバへ振り分けを行います。
但し、振り分け先の実サーバの負荷が高い場合は、別な実サーバへ転送されます。

□lblcr：Locality-Based Least-Connection with Replication

基本的には｢lblc：Locality-Based Least-Connection｣と同様。
異なる点は振り分け先実サーバをレプリケーションすることが可能。

□dh：Destination Hashing

送信先IPアドレスによるハッシュを使ったスケジューリングを行います。

□sh：Source Hashing

送信元IPアドレスによるハッシュを使ったスケジューリングを行います。

□sed：Shortest Expected Delay

最短遅延予測によるスケジューリングを行います。
※意訳すると、もっとも応答が速いと予測されるサーバに優先的に振分けを行う

□nq：Never Queue

空いている実サーバがあればそこに振り分けます。
空いているサーバがない場合は、｢sed｣と同様の動作を行います。

■ lvs_method

ルーティング方式を｢DR｣｢NAT｣または｢TUN｣から選択します。

DR：Virtual Server via Direct Routing
→　アクセスはLVSを経由するがレスポンスは実サーバからクライアントへ直接返される方式。
NAT：Virtual Server via Network Address Translation
→　アクセスもレスポンスもLVS経由で行われる方式。
TUN：Virtual Server via IP Tunneling
→　DRの拡張版。LVSから実サーバへのパケットがカプセル化される。

■ protocol

対象のプロトコルを指定します。

■ real_server

サービスを実際に提供する実サーバの設定を行います。
書式としては｢real_server [IPアドレス] [ポート番号] { 監視設定} ｣となります。

なお｢監視設定｣については
｢TCP_CHECK｣｢HTTP_GET｣｢SSL_GET｣｢MISC_CHECK｣等が設定できます。

□TCP_CHECK

｢connect_port｣にて指定したTCPポートを利用し監視する。

□SMTP_CHECK

実際にSMTPサーバに接続を行い監視を行う。

□HTTP_GET / SSL_GET

｢url｣で指定された｢path｣にアクセスを行い、
その応答結果と｢status_code｣や｢digest｣を比較し合致するかどうかで監視を行う。

□MISC_CHECK

｢misc_path｣で指定したプログラムを実行し、その結果を利用して監視を行う。
基本的に応答コードが｢0｣であれば正常で、応答コ＾ドが｢0｣以外、
または、｢misc_timeout｣で指定された時間内に応答がない場合は異常とみなします。

今回使用した設定項目をざっと説明してみました。
具体的な使い方でご質問等あればリクエストいただければ
私がわかる範疇で説明いたします。

なお、｢keepalived.conf｣の設定内容を含む、
LVSに関する情報としては、以下の書籍も参考にしております。

ご興味のある方は購入してみてください。

以上で、MySQL Clusterとkeepalivedを組合わせた環境の構築について説明を終えます。
皆様の参考になればと思います。

お疲れ様でした。

Technorati Tags: MySQL, Cluster, keepalived