次のページネットワーク負荷分散(NLB)NLBはフロントエンドのWebサービス、およびVPNサーバやファイアウォールなどの「エッジサーバ」に関する可用性とスケーラビリティの問題に対処する設計になっています。このサービスは、表4にあげるOSでのみ利用可能で、外部からのIPトラフィックの負荷をクラスタ全体に分散します。サーバOSのEditionと最大数ネットワーク負荷分散を行うと、Webサービス/ストリーミングメディアサービス/ターミナルサービスなどのインターネットサービスの可用性とスケーラビリティを向上させることができます。ネットワーク負荷分散は負荷分散のインフラストラクチャとして機能し、WMIをベースとして構築された管理アプリケーションに制御情報を提供することでき、そして既存のWebサーバファームインフラストラクチャをシームレスに統合することができます。図2:4ノードクラスタ構成の例NLBはハードウェアによるロードバランサーと違い、振り分けるというよりは効率的に処理できるノードが負担すると手をあげるというのがわかりやすい例えかもしれません。最初に処理を行う判断をしたサーバから他のサーバへの信号でどのサーバが処理を行うかを制御します。この制御については死活確認などいくつかのメカニズムがありますが、NLBについてはハートビートと呼ばれる通信を相互に行うことで制御し合っている構成となっています。ネットワーク負荷分散の設定は実は非常に簡単です。TCP/IPの設定を行うプロパティ画面で通常は何もチェックしない「ネットワーク負荷分散」にチェックを入れて、プロパティを構成するだけです。Webサーバを負荷分散している場合には、サーバクラスタ同様に図2の外部ネットワーク側に仮想アドレスを設定することで、Webブラウザに分散を意識させずに特定のアドレスへアクセスさせて分散を実現できます。ここまではハードウェアによるバランサと何ら変わるところはありません。異なる点は仮想アドレスの設定をそれぞれのNICで行うこと、優先順位などの設定もすべて各ノードのNICに関連する情報として設定することです。設定はレジストリに書かれているという点を覚えておくといいかもしれません。4.0の頃のWLBSのなごりでコマンドラインのツールはWLBSコマンドがあります。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を参考にして、サーバを購入するベンダーとよくご相談の上でスムーズにクラスタを構築してください。Services(.NETからのCOM+サービスの呼び出し)として利用できるため、引き続きご利用可能です。Foundation(WCF/コードネーム:Indigo)を中心に集約されていく方向にあります。従って、今後はWCFの動向もウォッチいただいた上でコンポーネント負荷分散を使うかどうかを決定いただくことを推奨します。興味のある方はぜひ下記URLを参照してください。洋AS/400プログラマーからスタートし、OS/2・Windows環境でのデータ連携やワークフローシステムの構築、パッケージ開発を経験。マイクロソフトに入社してからアプリ系のコンサルタント、その後主に金融顧客向けの製品サポート顧客担当(TAM)を経て、2005年1月からエバンジェリストとして活動中。