Pěknou botu jsem dnes vyrobil. Takovou, že si ji raději zapíšu, aby se mi to nepovedlo znovu. Network Load Balancing služba běžící na několika web serverech (a je už jedno, zdali Windows Server 2003 či 2008) dokáže spořádat pěknou porci požadavků od uživatelů. Přesto se však stává, že je občas některý ze serverů velmi zatížen – typicky při “návštěvě” nějakého ne příliš citlivého indexovacího robota. Pokud je afinita NLB pravidla nastavena na Network či Single, směřuje provoz od žádající IP adresy vždy na jeden webový server. Tento server pak může být přetížen. Zkrátka a dobře jsme si řekli, že by bylo dobré nastavit afinitu na None, takže by se load-balancovaly všechny jednotlivé požadavky, tj. i ty, které by pocházely od uživatele se stejnou IP adresou.
Výše uvedené není problém nastavit. Pokud s tím počítá aplikace (je připravena např. pro využití dedikovaného .NET session serveru), je to skvělé. Po přepnutí afinity na None se ukázaly dvě věci:
1) to, že programátoři tvrdí, že aplikace je připravena pro běh na webové farmě, nemusí být pravda
2) vše se strašně zpomalilo
Bod 1 jako ne-programátor těžko vyřeším, mohu maximálně zkontrolovat definici session serveru ve web.configu aplikace, případně nastavit speciální NLB pravidla v NLB manageru pro IP adresy, na nichž běží weby, jež nekamarádí s load-balancingem. Bod 2 mne však zarazil – co je špatně? No – obsluha.
Je tady jeden zádrhel. V našem konkrétním případě jsem zapomněl na to, že SSL protokoly nejsou terminovány na předřazeném SSL koncentrátoru, ale jsou ukončovány přímo na webových serverech. Odpověď jsem pak našel na
http://edge.technet.com/Media/Network-Load-Balancing-NLB-in-Windows-Server-2008/.
There are a few other things you can do with affinity:
- Single affinity: connections initiated by a given ip address are handled by the same server in the cluster until cluster membership changes. This is useful for those applications that maintain sessions across multiple connections (e.g. E-commerce applications). Note that SSL connections will need single affinity to avoid re-negotiation at every attempt.
- No affinity: connections are load-balanced based on originating address and port. This is more efficient, as connections from the same client can be routed to several hosts.
- VPN and IPSec affinity: vpn and ipsec sessions will be preserved even if cluster membership changes.
- Class C affinity: useful when internet clients access the cluster through proxies that expose the same class-C addresses. Load balancing is based on the class-C subnet portion of the incoming address.