ネットワーク負荷分散（NLB）

ネットワーク負荷分散（NLB）

   NLBはフロントエンドのWebサービス、およびVPNサーバやファイアウォールなどの「エッジサーバ」に関する可用性とスケーラビリティの問題に 対処する設計になっています。このサービスは、表4にあげるOSでのみ利用可能で、外部からのIPトラフィックの負荷をクラスタ全体に分散します。

   ネットワーク負荷分散を行うと、Webサービス／ストリーミングメディアサービス／ターミナルサービスなどのインターネットサービスの可用性とス ケーラビリティを向上させることができます。ネットワーク負荷分散は負荷分散のインフラストラクチャとして機能し、WMIをベースとして構築された管理ア プリケーションに制御情報を提供することでき、そして既存のWebサーバファームインフラストラクチャをシームレスに統合することができます。

図2：4ノードクラスタ構成の例

   NLBはハードウェアによるロードバランサーと違い、振り分けるというよりは効率的に処理できるノードが負担すると手をあげるというのがわかりやす い例えかもしれません。最初に処理を行う判断をしたサーバから他のサーバへの信号でどのサーバが処理を行うかを制御します。

   この制御については死活確認などいくつかのメカニズムがありますが、NLBについてはハートビートと呼ばれる通信を相互に行うことで制御し合っている構成となっています。

   ネットワーク負荷分散の設定は実は非常に簡単です。TCP/IPの設定を行うプロパティ画面で通常は何もチェックしない「ネットワーク負荷分散」にチェックを入れて、プロパティを構成するだけです。

   Webサーバを負荷分散している場合には、サーバクラスタ同様に図2の外部ネットワーク側に仮想アドレスを設定することで、Webブラウザに分散を 意識させずに特定のアドレスへアクセスさせて分散を実現できます。ここまではハードウェアによるバランサと何ら変わるところはありません。

   異なる点は仮想アドレスの設定をそれぞれのNICで行うこと、優先順位などの設定もすべて各ノードのNICに関連する情報として設定することです。設定はレジストリに書かれているという点を覚えておくといいかもしれません。

   Windows NT 4.0の頃のWLBSのなごりでコマンドラインのツールはWLBSコマンドがあります。よく使っていたのがWLBS DISPLAYです。しかし、Windows Server 2003でのネットワーク負荷分散マネージャの登場で自動化する際以外では利用しないで済んでしまうでしょう。

サーバクラスタとの併用

   非常に多く寄せられる質問がネットワーク負荷分散とサーバクラスタとの併用についてです。残念ながら同一ノードをMSCSとNLBの両方に参加させ ることをサポートしていません。双方ともハートビートや仮想アドレスなど非常に似た構造なので併用するのは難しいでしょうし、もし組んで動作してもあまり 事例のないクラスタ構成になってしまい、トラブルシュートが大変です。

クラスタを構築する際のノード数

   米マイクロソフトのWebサイト（www.microsoft.com）の運営について聞いていると、小規模のクラスタを多くする傾向にあるようで す。サーバが32台ある場合でも4台を8クラスタ組むというようなことですが、この場合にはもちろん全クラスタをラウンドロビン方式で振り分ける仕掛けが 必要になるので、1クラスタ内の台数やクラスタ数の組み方は対障害設計と負荷試験によって決定される要件によります。

ネットワーク負荷分散の分散メカニズム

   異なるクライアント同士が同じプロキシを通ると、同一IPアドレスでNLBクラスタに到達します。これにより、NLBクラスタはこれらの接続が単一マシンから発信された接続だと認識します。

   クラスタが「Affinity：単一モード」に構成されている場合、NLBは受信接続のソースIPアドレスのみを使用して負荷分散を実行します。ま た、これらすべての接続が同じIPアドレスから発信されているように認識されるため、すべてがクラスタ内の同じホストに送られることになります。

   しかし、クラスタが「Affinity：なし」モードに構成されていると、NLBはソースIPアドレスとソースポートの両方を使用して負荷分散を行い、負荷がすべてのホストに分散されます。

SSLを利用したネットワーク負荷分散

   SSLを利用したネットワーク負荷分散は、NLBが「Affinity：単一モード」で構成されているようにすることで対応できますが、負荷分散は「Affinity：なし」モードほど粒度が高くない点を理解の上で使用してください。

   さらに、すべてのセッションがクライアント側のプロキシを通って行われる場合、すべてのTCP接続が同じIPアドレスを持ち、それらはすべてクラスタの同じマシンで処理されて負荷分散は行いません。

   ぜひ下記URLを参考にして、サーバを購入するベンダーとよくご相談の上でスムーズにクラスタを構築してください。

コンポーネント負荷分散

   コンポーネント負荷分散は.NETの普及とともにEnterprise Services（.NETからのCOM+サービスの呼び出し）として利用できるため、引き続きご利用可能です。伝えておきたい点として、マイクロソフト の分散システム通信技術はWindows Communication Foundation（WCF／コードネーム：Indigo）を中心に集約されていく方向にあります。

   従って、今後はWCFの動向もウォッチいただいた上でコンポーネント負荷分散を使うかどうかを決定いただくことを推奨します。興味のある方はぜひ下記URLを参照してください。