アクティブ／スタンバイでサーバを自在に操る：ロードバランサの本質（3）

〜ロードバランサを冗長化して高信頼性ネットワークを構築する〜

[上谷一, 今野徹，F5ネットワークス]

ロードバランサの冗長化構成
仮想サーバアドレスと共有IPアドレスを移す

　連載第1回「パケットフローから負荷分散の基本を理解する〜NAT／コネクションテーブル／MAT〜」、第2回「ダウンサーバを回避して接続を維持する」では負荷分散時のパケットフローや、サーバヘルスチェックと接続維持など、ロードバランサの本質的動作を解説しました。

　最終回は、高信頼性ネットワークを構築する際に必要な知識である、ロードバランサの冗長化構成時の動きや冗長化されたスイッチやサーバ群との接続について、実際の構築事例を基に紹介します。

　また最後に、パフォーマンス測定についていくつかの留意点を記述します。今回の解説内容はロードバランサによって若干考え方や動作の違いがあります。本記事はF5社BIG-IPをベースに記述します。ただし、実際の差はそれほど大きなものではありません。

　ロードバランサ自身の障害対策のため、ロードバランサは通常図1のように2台の冗長化構成で設置されます。1台がアクティブ機でもう1台がスタンバイ機となり、負荷分散のトラフィックはアクティブ機側を通ることになります。アクティブ機は自分自身のIPアドレス（図1では10.10.1.2と

192.168.1.2）のほかに、負荷分散トラフィックのあて先である仮想サーバアドレス（10.10.1.100）と共有IPアドレス（10.10.1.1と192.168.1.1）を持っています。

図1　ロードバランサ冗長化構成

　一方のスタンバイ機は、2台をつなぐ専用ケーブルなどを利用して常にアクティブ機の動作を監視しており、障害を検知するとスタンバイ機が瞬時にアクティブ機に切り替わって、仮想サーバアドレスや共有IPアドレスを引き継ぎます（図2）。

図2　障害検知時

　通常、internal側に存在するサーバ群のデフォルトゲートウェイは社内ネットワーク（internal）側の共有IPアドレス（192.168.1.1）に設定され、またインターネット（external）側に存在するルータの経路表にはexternal側の共有IPアドレス（10.10.1.1）が登録されることになります。

アクティブ／スタンバイ切り替わりの動作
切り替わりを認識する2つの方法

　新しくアクティブ機になった元スタンバイ機上に仮想サーバや共有IPアドレスが移ったことを、ロードバランサ周辺のルータやサーバ、L2スイッチが認識する方法は大きく2つあります。1つ目はgratuitous ARPパケット（重複IPアドレス検出やARPキャッシュエントリ更新のために用いられるパケット）を利用する方法です（図3、図4）。

図3　アクティブ／スタンバイ切り替わり前

　切り替わりが発生する前のルータのARPテーブルが図3のようであったとします。切り替わり発生時に新アクティブ機はgratuitous ARPパケットをブロードキャストし、共有IPアドレスや仮想サーバアドレスについてのルータ のARPエントリを図4のように書き換えます。。internal側サーバ群の、共有IPアドレスについてのARPエントリも同様に書き換わります。

図4　アクティブ／スタンバイ切り替わり後

　環境によってはこのgratuitous ARPパケットによる切り替わりの動作が思うように動作しないことがあります。L2スイッチがgratuitous ARPパケットのブロードキャストを行わなかったり、実装によりルータやサーバがARPテーブルを更新しない場合などです。こういったときは共有MACアドレスによる方法を使用することがあります。

　仮想サーバや共有IPアドレスのMACアドレスとして、仮想的な共有のMACアドレスを用いる方法です。この方法ではルータやサーバのARPエントリが書き換わる必要はなく、L2スイッチ上のMACアドレスとポートのマッピングだけが変わる必要があります。

　どちらの方法を用いるにしても導入時に、切り替わりスピードなどについてのテストは必須となります。

ロードバランサの冗長化構成
ロードバランサに接続されたをL2スイッチで冗長化する

　最近のロードバランサは物理ポートを多数持っている機器が多いので、ルータやサーバ群を直接ロードバランサと接続するケースも増えてきました。ただ、ポート数が足りないなどの理由で間にスイッチを接続するケースも多数存在します。ロードバランサを2台構成で冗長化したのと同様に、スイッチの故障などに備えてスイッチも冗長化するのが一般的です（図5）。

図5　スイッチの冗長化構成

　スイッチ障害の検知の方法はロードバランサによって多少異なりますが、スイッチにつながっているロードバランサのポートを監視しトラフィックが一定期間観測されなかったら、ARPなどでトラフィックを流そうと試み、それでもトラフィックが観測されない場合障害と見なすといった方法が取られます。

　こういった方法ではスイッチ故障だけではなくケーブル外れといった障害にも対応することができます。障害を検知するとアクティブ／スタンバイが切り替わり、正常なスイッチを経由してトラフィックが流れるようになります。

ロードバランサの冗長化構成
L2スイッチは？ たすきがけ構成は？

　ロードバランサとサーバ群の接続は図6のようないくつかの形態を取ることができます。

図6　ロードバランサとサーバ群の接続

　L2スイッチを用いるか否か、あるいはサーバ群とロードバランサやスイッチをたすき掛け構成にするか否かで大きく分けることができます。L2スイッチはサーバの台数が多くロードバランサに収まり切らない場合などに使用されます。

　たすき掛け構成にしない場合（図6の（1）および（3））は、サーバ群を2つに分けてそれぞれ別々のスイッチやロードバランサに接続しますが、片方のスイッチやロードバランサに障害が起きた場合に使用できるサーバの台数が半分まで落ちてしまいます。

　たすき掛け構成の場合（図6の（2）および（4））は、片方のスイッチやロードバランサ障害時もすべてのサーバを使用することができますが、この構成に対応したサーバOSやNICは現在あまり一般的ではないようです。

• 実際の構成図例

　以上のようにロードバランサ、スイッチ、サーバが冗長化された実際の構成図例が図7になります。

図7　実際の構成図例

　図7の（2）はファイアウォール（FW）も冗長化（負荷分散）された構成図になります。ロードバランサ障害時にどのような動作をするか、あるいはスイッチ障害やケーブル外れが発生したらどうなるかなど、導入前に十分な動作試験を行います。

パフォーマンス測定は
現実に近いトラフィックで行うべし

　大きなトラフィック発生による負荷でサーバがダウンしたために慌ててロードバランサを導入するケースがありますが、サイトがダウンする前にロードバランサを導入しておくためにもパフォーマンス測定は重要な試験項目の1つです。実際にはJ2EEなどのアプリケーションやSSLの処理がボトルネックになることが多く、それらを検知するために実際のクライアントでのトランザクション遂行など、できる限り現実に近いトラフィックを流して負荷を掛けることが重要です。実際の環境でロードバランサのパフォーマンスが問題になることはあまりないのですが、いくつか留意点を記述します。

　まず、ベンダの公表しているパフォーマンス数値をうのみにしないことが重要です。ベンダは当然、他社と比較してそのベンダのパフォーマンスが一番いいという数値を出してきます。どういうパケットを発生させるかによって、パフォーマンス数値は大幅に変化するため、そのベンダが現実的なトラフィックを発生させてその数値を得たか否かを見極めることが重要になります。例えば、HTTPの場合は“TCPのオープン、HTTPである程度のサイズのfile取得、TCPのクローズ”という一連の流れが正常に行われていたか、あるいは使用したのは HTTP/1.0かHTTP/1.1かといったことを気にするようにします。

　また、ロードバランサの設定によってもパフォーマンス数値は大きく変化します。特に連載第1回で解説したようにL4スイッチかL7スイッチかによってロードバランサの動作は大きく変わるため、パフォーマンス数値も大きく変化します。実際に使用する設定で、できる限り現実に近いトラフィック発生によるパフォーマンス測定が重要です。

---

ご愛読いただきありがとうございました

以上、3回の連載で ロードバランサの本質的動作、サーバヘルスチェックとサーバ接続維持、ネットワークベースの負荷分散テクノロジ、ロードバランサのパフォーマンス測定や冗長構成の要点を説明しました。

ロードバランサの仕組みを解説しましたが、いかがでしたでしょうか？ 皆さんのネットワーク管理の1つの助けとなれば幸いです。

「ロードバランサの本質」バックナンバー

• アクティブ／スタンバイでサーバを自在に操る
• ダウンサーバを回避して接続を維持する
• パケットフローから負荷分散の基本を理解する