Testování jsem prováděl na MS Windows Server 2008 R2 a switchi Cisco Catalyst 2960G. Zajímavý článek o této problematice je Catalyst Switches for Microsoft Network Load Balancing Configuration Example. NLB je volitelná Feature na serveru 2008, pro správu se používá Network Load Balancing Manager (z libovolného stroje s dostupným spojením). Při testech jsem pouštěl NLB Manager z členů clusteru a několikrát jsem se setkal s tím, že z jednoho serveru nebyli vidět všichni členové, ale z druhého ano.

NLB zařizuje distribuci požadavku klienta na skupinu serverů. Odpověď pak přichází od člena clusteru, který požadavek zpracoval. Hlavní roli zde hraje virtuální IP adresa, která se označuje jako cluster IP address. To je adresa, kterou pak používáme pro volání aplikace na clusteru. K této IP adrese se automaticky generuje MAC adresa, její tvar záleží na modu clusteru. Členové clusteru by měli (nejsem si jistý, zda je to vždy povinná podmínka) být ve stejném subnetu.

Při konfiguraci NLB se automaticky upraví nastavení adaptéru, který má zvolenou IP adresu (podle ní se přidává do clusteru). A k jeho standardní IP adrese se přidá jako druhá cluster IP. Takže všichni členové clusteru získají stejnou IP adresu (jako druhou). Požadavek klienta pak na L3 (3. vrstva dle OSI modelu) dorazí zároveň na všechny servery a ty si již podle určitých pravidel určí, který z nich bude dotaz zpracovávat. Rozdělení se provádí podle spočítaného hashe (může být založen na zdrojové IP adrese) a podle počtu serverů v clusteru mají rozsah hashe rozdělen mezi sebou.

Členové clusteru musí mít navíc přehled o tom, kolik dalších aktivních členů se v clusteru nachází. Aby si správně rozdělili příchozí komunikaci a zpracovali ji. Proto všichni pravidelně odesílají NLB heartbeat (součástí je cluster virtual IP a host IP).

NLB je clusterovací technologie MS a je součástí Windows Server 2000, 2003, 2008. Může pracovat v jednom ze tří módů unicast, multicast a IGMP multicast. Důležité je, že NLB může používat na komunikaci mezi členy clusteru stejný síťový adaptér, který je clusterovaný.

Hodit se může informace, že konfigurace NLB (včetně IP a MAC adres) se ukládá do registrů do klíče HKLM\SYSTEM\CurrentControlSet\Services\WLBS. To je asi z historických důvodů, protože WLBS je zkratka MS Windows NT Load Balancing Service, což byl předchůdce NLB.

Pro testy popsané dále bylo použito následující zapojení. Server 1 a Server 2 jsou použity pro vytvoření NLB clusteru, PC1 slouží k posílání dotazů a PC2 je pouze pro monitoring toho, že se některá komunikace šíří i mimo porty kam je směrována.

NLB Unicast mode

Defaultní mód pro NLB, údajně je s ním nejméně problémů. NLB přidá na adaptér všech členů clusteru druhou IP adresu (cluster IP) a zároveň změní MAC adresy těchto adaptérů. Nová MAC adresa je z rozsahu "běžných NLB MAC adres" a je společná pro všechny členy clusteru i pro virtuální IP (v mém testu šlo o MAC 02:bf:c0:a8:02:0a). Díky tomu by měla komunikace na L2 dorazit zároveň všem členům clusteru. Jenže, na jednom switchi nemohou mít dva porty přiřazenu stejnou MAC adresu, takže v praxi toto řešení nefunguje (na switchi by se pořád měnil záznam, který port má tuto MAC a vždy by fungoval pouze jeden = MAC address flapping).

NLB to řeší tak, že defaultně provádí maskování MAC adres v Ethernet hlavičce odchozích rámců. To jsou ty adresy, které se switch učí a ukládá do CAM tabulky. NLB vytvoří falešné rozdílné MAC adresy (02:01:c0:a8:02:0a, 02:02:c0:a8:02:0a), které vychází z cluster MAC adresy, ale v druhém oktetu má pořadové číslo člena clusteru. Komunikace pak probíhá tak, že v hlavičkách se používají tyto falešné MAC adresy, ale na ARP dotazy odpovídají servery tou virtuální MAC adresou. V ARP reply pak máme jinou MAC adresu v hlavičce a jinou MAC adresu v datech jako zdrojovou, což mohou některá zařízení vyhodnotit jako podvržení.

Obecně to ale funguje, switch používá MAC adresy z hlaviček rámců, klienti používají údaje z ARP. Klienti tedy odesílají data na virtuální MAC adresu. Tu switch nezná (nepřišel z ní žádný rámec), takže rámec posílá na všechny porty v dané VLANě mimo příchozího, to je stejné jako broadcast.

Zajímavé ještě je, když se přes ARP ptá některý člen clusteru na MAC adresu jiného člena, tak používá opět jinou MAC adresu a podobnou dostane v odpovědi (03:bf:c0:a8:02:1e, 03:bf:c0:a8:02:1f). To je pro přímou komunikaci mezi členy clusteru. Další zajímavostí je, že když provedeme testování pomocí ICMP echo/reply (ping), tak na každý request dostaneme odpověď od všech členů (na této vrstvě se ještě nerozděluje zpracování požadavků).

Pokud použijeme NLB v unicast modu, tak se nám MS NLB heartbeat šíří pomocí broadcastu (cílová MAC adresa je FF:FF:FF:FF:FF:FF) a odesílá se každou sekundu.

Vylepšení pomocí konfigurace switche

Výše popsané řešení je sice funkční, ale to, že nám komunikace probíhá vlastně broadcastem, určitě není dobré a pro mnohé je naprosto neakceptovatelné. Naštěstí existuje řešení, jak toto chování změnit. Když máme Cisco switch, tak můžeme záznam do CAM tabulky provést staticky a dokonce je možné jednu MAC adresu přiřadit více portům. Tím zajistíme, že komunikace odesílaná na cluster (virtuální MAC), dorazí pouze na zadané porty.

SWITCH(config)#mac address-table static 02bf.c0a8.020a vlan 112 interface Gi0/3 Gi0/17
SWITCH#show mac address-table | inc Gi0/3
112    0201.c0a8.020a    DYNAMIC     Gi0/3
112    02bf.c0a8.020a    STATIC      Gi0/3 Gi0/17

Aby nedocházelo k maskování MAC adresy v unicast modu

Nyní již vypadá maskování MAC adres jako zbytečné, takže bychom mohli přepnout defaultní chování do režimu, kdy se i na L2 používá clusterová MAC. Toto přepnutí se provádí v registrech na všech členech clusteru, musíme změnit hodnotu MaskSourceMAC na 0 (0 je vypnuto, 1 zapnuto) v cestě HKLM\SYSTEM\CurrentControlSet\Services\WLBS\Parameters\Interface\Adapter-GUID. Následně je třeba provést restart serveru.

Bohužel, to že zadáme MAC adresu staticky na více portů, nám nevyřeší problém s MAC flappingem. Switch se pořád učí MAC adresy na portech (i když tu stejnou má staticky zadanou) a přestože komunikace funguje, tak se vytěžuje switch.

NLB IGMP Multicast mode

Multicast mode nám MS nabízí ve dvou typech, jako nestandardní multicast, který používá pro cluster IP Microsoftí NLB multicast MAC adresu. Tomu se zde věnovat nebudeme. Nebo standardní IGMP multicast, který používá standardní multicast MAC adresy (začínají 01:00:5e) a také IGMP Report Message (zprávy o zařazování do multicast skupin).

Při multicast módu zůstává fyzickým adaptérům originální MAC adresa, na adaptér se přiřadí virtuální IP adresa a na ARP dotazy na cluster IP odpovídají servery multicastovou MAC adresou (01:00:5e:7f:02:0a). Když klient odesílá na tuto MAC adresu požadavek, tak switch odesílá rámec na všechny porty mimo příchozího v této VLANě (standardní chování multicastu v rámci subnetu, takže opět jako broadcast). V případě funkčního IGMP Snoopingu, zkoumá switch IGMP Report Message a pak posílá data pouze na porty, které jsou přihlášeny k multicast skupině.

POZOR! V tomto případě se může objevit problém, pokud potřebujeme, aby s cluster IP adresou komunikovali i klienti, kteří jsou v jiné VLANě. Cisco zařízení nepovolí ARP odpovědi, kde je unicast IP a multicast MAC. Takže cluster IP není dostupná pro klienty z jiných VLAN. Řešením jsou statické záznamy do ARP tabulky routeru.

SWITCH(config)#arp 172.16.63.241 0300.5e11.1111 

Pokud použijeme NLB v IGMP multicast modu, tak se nám MS NLB heartbeat šíří pomocí multicastu na multicast MAC adresu clusteru (01:00:5e:7f:02:0a) a odesílá se každou sekundu. Členové clusteru používají v odpovědi svoji MAC adresu. Zajímavé je, že při zachytávání komunikace na členu clusteru se v rámcích odesílaných na cluster IP a MAC zobrazuje místo multicast MAC adresy MAC adresa daného člena clusteru. Také se v zachycené komunikace vůbec nezobrazují NLB heartbeaty.

Vylepšení pomocí konfigurace switche

Rozchození IGMP Snoopingu není vůbec tak jednoduché, jak se může zdát (nestačí jej zapnout na aktivních prvcích, což je u Cisca default). Takže i při použití multicastu se nám většinou šíří komunikace jako broadcast. Naštěstí zde funguje stejná věc jako u unicastu. Můžeme na switchi zadat statické záznamy do CAM tabulky (toto nastavení přebije i IGMP Snooping).

SWITCH(config)#mac address-table static 0100.5e7f.020a vlan 112 interface G0/3 G0/17

Cisco hovoří ještě o tom, že u Catalystů 6000 a 6500 je třeba doplnit příkaz o klíčové slovo disable-snooping.

SWITCH(config)#mac address-table static 0100.5e7f.020a vlan 112 interface G0/3 G0/17 disable-snooping

Toto řešení je asi to nejlepší, protože se na porty mimo cluster a klienta nedostává žádná komunikace, která tam nepatří (ani NLB heartbeat).

Tabulky MAC adres v různých režimech

Myslím, že velkou vypovídací hodnotu má tabulka MAC adres, které vidí různá zařízení při nastavení různého módu NLB. V první tabulce jsou zobrazeny výchozí hodnoty.

Druhá tabulka ukazuje, jaké MAC adresy používají jednotlivá zařízení pro IP adresy jiného zařízení. Nejprve máme vlastní MAC adresy na adáptérech členů clusteru. Potom jakou MAC adresu vrací pro cluster IP.

Následně jaké MAC adresy vidí členové clusteru mezi sebou. Potom jaké MAC adresy vrací členové clusteru klientům.

A poslední jsou MAC adresy na portech switche.