Warning: Undefined array key "url" in /home/nesuke2/milestone-of-se.nesuke.com/public_html/wp-content/plugins/code-snippets/php/snippet-ops.php(582) : eval()'d code on line 2
Windows NLBとは
Windows NLB とは、Windows Network Load Balancing の略で、同じサービス (Web 等) を起動した 2 台以上の Windows サーバでクラスタを組み、周りからは 1 台のように見せかけ、その複数台でサービスの処理を負荷分散する、Windows独自のロードバランサ機能です。
日本語では『Windows ネットワーク負荷分散』とも呼びます。
ロードバランサの機能を、追加ハードウェア無し、追加ライセンス無しで実現できます。
各サーバは実 IP の他に、HSRP や VRRP のように各サーバ共通の VIP (仮想 IP)を持ち、クライアントはその VIP を宛先とします。
NLB には『ユニキャストモード』と『マルチキャストモード』の 2 種類の動作モードがあります。
ユニキャストモードの動作とメリット・デメリット
ユニキャストモードでは、サーバが収容されている L3 機器から VIP 宛の L2 通信を L2 ユニキャストで送信します。
VIP の MAC アドレスは以下になります。
例えば VIP が 10.1.1.99 であれば、MACアドレスは以下になります。
しかし NLB クラスタ内の全サーバが単純にこのアドレスを素直に ARP を返してもうまく動作しません。なぜならサーバを収容するスイッチには MAC アドレステーブルがあり、サーバが ARP を出したタイミングでその MAC宛の通信はそのサーバになりますが、次のタイミングではどのサーバになるか分からなくなるからです。
負荷分散するのだからいいじゃんと思うかもしれませんが、少なくとも TCP では同じサーバと通信しないと TCP コネクションすら確立できませんし、https の TLS セッション中、http のクッキーセッション中は同一サーバで処理される必要があります。なので、同じ送信元 IP からの通信は同じサーバと通信できなくてはなりません。
そこでどうするかというと、非効率ではありますが、クライアントからの通信を毎回スイッチでフラッディングをさせるようにARPを返すのです。
具体的には、ARP の中身は正しく [VIP=10.1.1.99] に対して [MAC=02-bf-0a-01-01-63] を返す内容にしますが、その Ethernet ヘッダの送信元 MAC は、[ダミーMAC=02-[xx]-0a-01-01-63] を使います。
これにより、L3 機器は ARP を正しく解釈し、正規の MAC アドレス宛に通信しますし、スイッチは MAC=02-bf-0a-ff-63-01 を学習しないため、毎回フラッディングされますので、NLB クラスタ内の全サーバが全てのパケットを受信します。
このように、ユニキャストモードでは通信が非効率になるのがデメリットですが、スイッチ側では特に設定が不要というのがメリットになります。
返信を担当するサーバのマッピング
クラスタ内の全サーバがパケットを受け取ったとしても、返信するのは 1 台のサーバのみです。デフォルト設定では、クライアント IP (つまり送信元 IP) に従って担当が予めマッピングが決まっています。(つまり、このクライアント IP からの通信は、サーバ A が担当、等)
このマッピングは基本そのままですが、クラスタ内のサーバが増えたり減ったりした場合に適宜見直されます。
なお、誰の担当でもないクライアント IP からの通信が来た場合は "デフォルトホスト" と呼ばれるサーバが返信することになっています。
マルチキャストモードの動作とメリット・デメリット
マルチキャストモードではもう少しスマートで、サーバが収容されている L3 機器から VIP 宛の L2 通信を L2 マルチキャストで送信します。
つまり、IP はユニキャスト IP アドレス、Ethernet はマルチキャスト MAC アドレスになります。
VIP の MAC アドレスは以下になります。
例えば VIP が 10.1.1.99 であれば、MAC は以下になります。
L2 マルチキャストにより、全サーバが受信できます。また、ユニキャストモードと同じく、返信するのはクライアント IP 毎に担当がマッピングで予め決まっています。
ただし、注意点として、L3 機器は VIP の MAC アドレスを ARP で解決しようとしますか、返ってくるのは L2 マルチキャストアドレスです。通常はあり得ないことなので、機器によってはこの IP/MAC を ARP テーブルに学習しません。
その場合は L3 機器に Static で ARP エントリを書く必要があるのであります。例えば cisco では以下のように設定します。
(config)# arp 10.1.1.99 03-bf-0a-01-01-63
しかしここまでではユニキャストモードと大差ありません。マルチキャストモードでは、L3 機器及び配下の L2 スイッチの、各サーバへ繋がる全ポートに対し、MAC テーブルのエントリを Static で追加することで、スマートな通信が可能になります。
例えば cisco では以下のように設定します。
(config)# mac-address-table static 03-bf-0a-01-01-63 interface gigabitEthernet 0/1 vlan 10
機器によっては複数ポートに同じ MAC アドレスを Static 設定することができませんので、事前確認が必要です。NG の場合はユニキャストモードで動作させることを検討します。
ARP テーブルと MAC テーブルがごっちゃになっている人は、以下をご参照下さい。
ユニキャストモードとマルチキャストモードのメリット・デメリットのまとめ
ユニキャストモード
- メリット:スイッチ設定が不要
- デメリット:通信が非効率(毎回フラッディング)、
マルチキャストモード
- メリット:通信が効率的
- デメリット:スイッチの ARP テーブルや MAC アドレステーブルに Static エントリ設定が必要、スイッチの仕様によってはこのモードは利用不可
アフィニティ(負荷分散アルゴリズム)
先ほど『デフォルト設定では』クラスタ内の全サーバが VIP 宛の通信を受け取った場合、『送信元 IP によって』返信を担当するサーバがマッピングされる、と説明しました。
どのサーバが担当するかを決める基準は、『アフィニティ (親和性)』というパラメータによって決まります。
アフィニティでは以下の 3 つの設定が可能です。
None (アフィニティなし)
クライアントの送信元 IP と送信元ポートの情報を使って担当サーバを決めます。なので TCP コネクション毎に担当サーバが変わるため、極めて均等に負荷分散できます。
ただし、この設定を使うときは、サーバがステートレスなものである必要があります。クッキーを使わない http 等が該当します。
Single (単一親和性)
クライアントの送信元 IP アドレスの情報のみを使って担当サーバを決めます。なので、クライアント 1 台につき、担当サーバは必ず 1 つになりますのでセッション維持が可能です。
なのでステートフルなサーバの場合はこの設定が望ましいです。クラスタ作成時のウィザードでは、デフォルトでこのパラメータが指定されています。
Class C (クラスC親和性)
クラス C の IP アドレス (192.0.0.1~223.255.255.254) に対してのみ有効で、IP アドレスの上位 24 bit の情報のみを使って担当サーバを決めます。
つまり、クラス C の同一セグメント内のクライアントは必ず担当が同じになります。
ハートビートによる相互監視とフェイルオーバー
NLB ではクラスタ内のサーバは互いにハートビードパケットを送信して相互監視を行っており、このハートビートが途絶えた場合はそのサーバが障害で Down したと見なし、フェイルオーバーします。
つまり、担当サーバのマッピング変更を行い、残ったサーバでできるだけ均等になるようにします。
コメント