Load balancing Exchange 2010 voor Outlook clients, een voorbeeld uit de praktijk. (deel 1)

Onlangs heb ik bij een kleine onderneming een Exchange 2010 omgeving ontworpen en gebouwd. In dit artikel wil ik wat meer vertellen over het ontwerpen van deze omgeving en dan met name met betrekking tot hoge beschikbaarheid. Het is niet mijn bedoeling om alle details of verschillende opties te benoemen, meer om een globaal idee te geven van hoe zo’n omgeving in de praktijk tot stand komt. In het tweede deel van dit artikel zal ik wat dieper ingaan op de configuratie van load balancing. Ik ga er vanuit dat de lezer (basis-)kennis heeft van Exchange 2010, Outlook 2007 en de verschillende verkeerstypen zoals MAPI en SMTP.

De situatie

Voor deze onderneming is e-mail een belangrijk medium, zowel de toegang tot de mailbox als het kunnen ontvangen en verzenden van e-mail moet zo goed mogelijk beschikbaar zijn. De meeste andere delen van de ICT omgeving zijn dubbel uitgevoerd, zoals bijvoorbeeld de internetverbindingen, storage, virtualisatie en de oplossing voor mailfiltering welke in de DMZ staat. De 150 gebruikers werken allemaal met Outlook 2007 op een SBC omgeving en kunnen gemiddelde gebruikers genoemd worden. Voor toegang van buitenaf maken gebruikers verbinding met de SBC omgeving, er wordt geen gebruik gemaakt van Outlook Web App, Outlook Anywhere of Exchange ActiveSync.

Servers en rollen

Voor Exchange 2010 hebben we minimaal drie van de vijf beschikbare Exchange rollen nodig: Client Access, Hub Transport en de Mailbox rol. De andere rollen zijn optioneel en voor deze klant niet van toepassing.

Exchange rol	Benodigd?
Mailbox
Client Access
Hub Transport
Edge Transport
Unified Messaging

De meest eenvoudige opstelling is om deze te combineren op één server. Er is in deze situatie geen voordeel te behalen door ze te verdelen over meerdere servers. In tegendeel, dat zou de oplossing duurder, lastiger te beheren en onnodig complex maken.

Om Exchange 2010 hoog beschikbaar te maken is het uitgangspunt dat je meerdere servers in zet en elke rol minimaal twee keer installeert. In ons geval is een tweede server met de drie Exchange serverrollen voldoende. We hebben nu twee servers die mail kunnen routeren (Hub Transport), client connecties aannemen (Client Access) en mailboxen en Pubic Folders kunnen bevatten (Mailbox).

Load balancing

We hebben nu dus twee servers die klaar staan voor Outlook clients, die bovendien SMTP mail kunnen aannemen van de anti-spam toepassing in de DMZ. Maar aan welke van de twee Exchange servers moet de mail nu afgeleverd worden? Met welke server laten we Outlook verbinden? En wat als die server uit is gevallen, of als we daar onderhoud aan willen plegen? Het antwoord op die vragen is Load Balancing.

Door middel van load balancing kunnen we deze ‘load’, namelijk SMTP en Outlook connecties, naar één virtueel IP-adres sturen. De load balancer zorgt vervolgens dat het verkeer doorgestuurd wordt naar één van de echte servers. Welke load balancers?

Voor het load balancen van de Hub Transport en Client Access rol hebben we verschillende mogelijkheden. Bij het vergelijken van de opties moeten we naar een aantal aspecten kijken, onder andere:

• Capaciteit
• Persistence of stickyness
• Health monitoring
• Prijs

Onder persistence wordt verstaan dat een load balancer het verkeer van bepaalde sessies steeds naar één van de achterliggende servers moet sturen. Stel je voor dat een gebruiker op OWA is ingelogd, nu wil hij een mail bekijken en de load balancer verbindt zijn sessie met een andere Client Access server. Het resultaat is dat de gebruiker opnieuw moet inloggen omdat hij nog niet aangemeld was bij deze Client Access server. Sommige load balancers kunnen dit alleen op basis van het client IP-adres, anderen kunnen dit op meer geavanceerde manieren doen.

Bij health monitoring gaat het er om dat de load balancer de gezondheid van de echte servers in de gaten houdt. Wanneer poort 443 bijvoorbeeld wel reageert maar vervolgens een HTTP 500 error geeft in plaats van het OWA inlogscherm, dan zou hij deze server uit de pool moeten halen.

Optie 1: Windows Network Load Balancing

Een veel gebruikte load balancer is Windows Network Load Balancing (WNLB). WNLB is standaard aanwezig in Windows Server en functioneert als een soort netwerkfilter. De werking is gebaseerd op MAC adressen en het voor de gek houden van switches, het resultaat is dat netwerkpakketjes bij verschillende servers uitkomen en dat WNLB bepaalt welke node de sessie afhandelt. Het voordeel van WNLB is dat het standaard aanwezig is in Windows Server, je hebt er dus al voor betaald.

Maar er zijn ook een paar belangrijke beperkingen. WNLB controleert niet of een server wel gezond functioneert, als de IIS service bijvoorbeeld gestopt zou zijn dan zal WNLB nog steeds OWA clients naar deze node sturen. Verder moeten er aanpassingen worden gedaan aan netwerkapparatuur om ongewenste bijverschijnselen te voorkomen. En ten slotte is het maar beperkt mogelijk om persistence te configureren, WNLB zal in principe alle clientconnecties van een heel Class C subnet met één node verbinden. Om bovenstaande redenen adviseert Microsoft niet langer om WNLB te gebruiken voor Exchange.

En voor ons project is er nog een andere belemmering: WNLB is niet compatible met Windows Failover Clustering (WFC). En laat WFC nou gebruikt worden door de Database Availability Group. WNLB kan dus niet gebruikt worden op een DAG member. Voor deze organisatie betekent dit dat we twee extra servers in moeten zetten om de mailbox rol op aparte servers te zetten indien we voor WNLB hadden gekozen.

Optie 2: Hardware load balancer

Hardware load balancers worden verkocht in de vorm van een fysiek netwerk apparaat, een zogenaamde appliance. Deze apparaten beschikken doorgaans over geavanceerde mogelijkheden om persistence te configureren, bijvoorbeeld op basis van HTTP cookies, en ondersteunen features als SSL offloading. Verder kunnen ze load balancen op verschillende lagen in het OSI model. En er zijn verschillende mogelijkheden om de gezondheid van de echte servers te controleren, bijvoorbeeld door regelmatig een url op te vragen en het antwoord te inspecteren op een bepaalde string. Zo weet de load balancer niet alleen of een server in de lucht is, maar ook of deze naar behoren functioneert.

Keuze

Voor WNLB zijn dus twee extra servers nodig, worden truukjes uitgehaald op het netwerk en het is niet application aware. Voor deze klant was de keuze al snel gemaakt, een hardware load balancer past beter bij de eisen die deze professionele organisatie stelt aan componenten van de ICT infrastructuur. De keuze is gevallen op de Barracuda Load Balancer Model 340, een betaalbare load balancer die bovendien zelf ook hoog beschikbaar kan worden gemaakt door twee exemplaren in een cluster te plaatsen. En dat laatste is precies waar we voor gekozen hebben.

Volgend deel…

In dit artikel zijn we tot een aantal ontwerpkeuzes gekomen, in het volgende deel zal ik verder in gaan om de configuratie van Exchange 2010. Binnenkort meer…