Windows NLBの仕組み 〜ユニキャストモード/マルチキャストモードの動作、アフィニティ(負荷分散アルゴリズム)、セッション維持、ポートルール

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アドレスは以下になります。

02-bf-[VIPアドレスの4byte]

例えば VIP が 10.1.1.99 であれば、MACアドレスは以下になります。

02-bf-0a-01-01-63

しかし 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アドレスは以下になります。

03-bf-[VIPアドレスの4byte]

例えば VIP が 10.1.1.99 であれば、MACは以下になります。

03-bf-0a-01-01-63

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アドレスの上位24bitの情報のみを使って担当サーバを決めます。つまり、クラスCの同一セグメント内のクライアントは必ず担当が同じになります。

ハートビートによる相互監視とフェイルオーバー

NLBではクラスタ内のサーバは互いにハートビードパケットを送信して相互監視を行っており、このハートビートが途絶えた場合はそのサーバが障害でDownしたと見なし、フェイルオーバーします。つまり、担当サーバのマッピング変更を行い、残ったサーバでできるだけ均等になるようにします。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする