NLB voor zowel de Client Access Server als de Hub Transport

  • Article

NLB binnen Windows 2003 is een veelgebruikte manier om services redudant te maken en/of te load balancen. Het is standaard beschikbaar in elke versie van Windows 2003 server; dit in tegenstelling to Cluster Services welke in de standard en web editions van Windows 2003 server niet beschikbaar is.

In Exchange 2007 kan je een aantal diensten aanbieden via NLB. Owa, web services, imap4 en pop3 kan je prima achter een NLB cluster zetten. De hub/edge transport role, mailbox server role en Unified messaging role kan je niet gebruiken i.c.m. NLB, of toch wel? Via een klein trucje kan je toch een hub transport server achter NLB zetten als je de Receive Connectoren voor communicatie met andere hub transports maar niet via NLB aanbiedt. Dit omdat de hub transports onderling mutual TLS authentication gebruiken, en NLB problemen veroorzaakt met het uitwisselen en valideren van de certificaten. Ook heeft de hub transport role zelf geen notie van een cluster en zal daardoor een set exchange servers nooit als een cluster benaderen. NLB is in de meeste gevallen ook helemaal niet nodig omdat Hub transports in dezelfde site (wat btw ook een vereiste is voor een NLB cluster. Een NLB cluster over subnets heen bestaat (nog) niet) zelf al load balancen en fault tolerant zijn. Echter wanneer je andere systemen hebt die verbinding maken via SMTP met een hub transport server (bv: fax of sms diensten), kan het handig zijn om een stukje load balancing en fault tolerance in de infrastructuur aan te brengen. 

Dit artikel zal een beschrijving geven hoe je dit voor elkaar krijgt:
More...

Voordat we met het configureren beginnen is het handig even kort stil te staan bij hoe NLB ongeveer werkt. NLB werkt door middel van een filterdriver die geladen wordt, waarmee het netwerk connecties getoetst kunnen worden aan de rules die opgesteld kunnen worden wanneer je NLB configureert. Deze rules bepalen of UDP of TCP verkeer voor een bepaalde port wel of niet tot NLB 'enabled' verkeer behoort. NLB werkt in Unicast of Multicast mode, wat wil zeggen dat de netwerkkaarten die gebruikt worden OF 1 (unicast) MAC address krijgt of meerdere (multicast) MAC addressen kan gebruiken. Wanneer NLB in unicast wordt opgezet, wordt het MAC address van de netwerk kaart vervangen door een MAC address dat iedere node in het cluster zal gebruiken. In multicast wordt het gezamenlijke MAC address toegevoegd aan de netwerkkaarten. Doordat meerdere hosts gebruik maken van hetzelfde MAC address kan deze netwerk kaart niet meer gebruiken voor interhost communicatie (dit omdat source en dest MAC hetzelfde zijn. Zelfs in Multicast mode kan het zijn dat je tegen dit probleem aanloopt). Het is daarom ten sterkste aan te raden een extra netwerk kaart te gebruiken voor NLB.
Wanneer je nu het NLB cluster aanmaakt dan configureer je een clusterIP en een clusterDNS (de laatste moet je wel zelf nog toevoegen in DNS). Verder kan je aangeven welke hosts in het cluster zijn opgenomen, welk verkeer je wilt filteren, of je het wilt load balancen of je alleen fault tolerant wilt zijn en of je server affinity wilt gebruiken. Dit laatste laat connecties (binnen een bepaald tijdframe) van ip addressen of complete subnets altijd door dezelfde host afhandelen. Dit is bijvoorbeeld handig voor als je met applicaties werkt via een SSL tunnel. Zonder affinity zou het aantal SSL sessies explosief stijgen. Wanneer je port 80 achter NLB hebt zitten en je gebruikt je browser om https://nlb.domein.com te benaderen, zullen de netwerk packets gerouteerd worden tot aan de laatste router of multi-layer switch. Hierna zullen de frames op de Datalink laag (LEVEL 2 in het OSI model) op basis van het MAC address afgeleverd worden bij de uiteindelijke host. Echter het MAC address wordt gebruikt op alle hosts. Een switch kan hier niet mee omgaan. Achter elke switch port moet een uniek MAC address zitten. Een switch bouwt zijn ARP table op door de frames te bekijken van de verbonden hosts en via ARP requests, en neemt de source MAC addressen op in de table. Als de switch een frame krijgt en het destination MAC address niet kan vinden in zijn table, zal hij het frame over alle poorten broadcasten. NLB maakt hier sneaky gebruik van. Op alle uitgaande frames van de NLB NIC wordt het MAC address aangepast. Alle NLB cluster MACs zijn hetzelfde opgebouwd, waarbij de tweede 8 bits (in HEX) altijd BF is. Echter voor de uitgaande frames wordt deze tweede set 8 bits aangepast aan de priority dat een node in het cluster heeft (01, 02, 03, 04 etc etc). Dit maakt dat de ARP tabel alleen de aangepaste MAC addressen bevat. Als er dus een frame komt dat bestemt is voor het cluster, dan zal hij deze broadcasten over alle porten.. Via het gezamenlijk algoritme dat de NLB nodes onderhouden, antwoordt de node die op dat moment 'aan de beurt is'. Door dit principe staat NLB erom bekend switches te kunnen flooden. Hier zijn tweaks voor.

Zo, dat is NLB in een nutshell :)

Volg de volgende stappen om NLB te activeren voor je Exchange services:

  1. Installeer een tweede netwerk kaart in je systemen.

  2. Zorg dat de primaire netwerk kaart als eerste in de binding order komt en verwijder de 'File and printer sharing' en 'Client for MS networks' bindings van de tweede netwerk kaart.

  3. Start NLBMGR op vanuit een command shell.

  4. Maak een cluster aan in UNICAST mode (in VMWARE moet je multicast gebruiken, anders werkt het niet) en voeg, wanneer je een host toevoegt, de tweede netwerkkaart toe.

  5. Maak vervolgens rules aan voor TCP porten 80, 443, 110, 143 en 25. Port 80 en 25 hebben geen host affinity nodig. Port 110, 143 en 443 stel je in met single affinity. (wanneer je pop3 of imap unsecure gaat aanbieden, kan je 110 en 143 ook zonder affinity instellen). Zet de rule in 'Multiple Hosts' mode, wat ervoor zorgt dat alle hosts meedoen in het cluster.
    NLB port settings

  6. Maak nu een nieuwe receive connector aan op elke NLB node en laat deze alleen luisteren op het cluster ip adres. Zorg ervoor dat de default connectors luisteren op het primaire ip adres. Pas ook de FQDN response aan van alle receive connectors in het cluster. Om een nieuwe connector te maken:
    Voorbeeld: New-ReceiveConnector -Server:'Node1' -Name:'NLB Connector' -Type:'Costum' -Bindings:'192.168.1.100:25' -fqdn:'Cluster.fqdn.domein.com' -RemoteIpRanges:192.168.1.10 - PermissionGroups:'AnonymousUsers' -AuthMechanism:'None'

    Dit maakt op Node1 een connector aan met de naam 'NLB Connector' die luistert op clusteripadres 192.168.1.100 port 25, en antwoordt met cluster.fqdn.domein.com in de SMTP banner (220 cluster.fqdn.domein.com Microsoft ESMTP MAIL service ready at (datum)). Het accepteert anonymous verbindingen van 192.168.1.10. Om ook nog echt te kunnen relayen moet je echter nog het ms-Exch-SMTP-Accept-Any-Recipient recht toekennen aan 'ANONYMOUS LOGON' wat het security principle is voor anonieme verbindingen. Dit recht stelt je in staat om email te verzenden aan iedere ontvanger en niet alleen aan accepted domains.
    Voorbeeld: Get-ReceiveConnector 'Node1\NLB Connector' | add-adpermission -User 'NT AUTHORITY\ANONYMOUS LOGON' -ExtendedRights ms-Exch-SMTP-Accept-Any-Recipient

    VERGEET AUB NIET DE BINDING VAN DE ANDERE RECEIVE CONNECTORS TE VERANDEREN NAAR HET PRIMAIRE IP ADDRESS

Probeer nu OWA te benaderen op https://cluster.fqdn.domein.com/owa en de nieuwe SMTP connector via telnet clusterip 25. Als het goed is moet nu alles werken (door de banner te veranderen op de verschillende receive connectoren kan je zien dat het werkt).

Ik zeg... aan de slag!! ;)