[Exchange 2007] Hub Transport server redundancy

[Question Mark]

Ik ben bezig met het maken van een design voor een nieuwe Exchange 2007 mailomgeving.

De Mailboxserver rol zal verzorgd gaan worden door een Single Copy Cluster, waarvan de clusternodes verspreid staan over twee datacenters. Beide datacenters zijn opgenomen in dezelfde AD-site. In beide datacenters zullen tevens servers neergezet gaan worden die beiden de Hub-Transport en de Client-Access rol gaan verzorgen.

Voor internet connectivity zal ervoor gekozen worden om dit door beide Hub-Transport servers te laten verzorgen. Er worden dus geen Edge-Transport servers ingezet.

Redundancy wordt in bovenstaand verhaal verkregen door een combinatie van clustering en DNS Round Robin. Eea conform de design guidelines van MS. Op de High Availability pagina van MS kom je bijvoorbeeld over het redundant maken van de verschillende rollen onderstaand tegen:

Client Access You can use Network Load Balancing or a third-party hardware-based network load-balancing device for Client Access server high availability.

Hub Transport You can deploy multiple Hub Transport servers for internal transport high availability. Resiliency has been designed into the Hub Transport, as well as the Mail Submission Service on Mailbox servers, for deployment of multiple Hub Transport servers.

Edge Transport You can deploy multiple Edge Transport servers and use round robin DNS to load balance activity across those servers.

Mijn vraag is echter hoe inkomende (internet)-mail redundant te krijgen is. Via de MX-records wordt de mail bezorgd op onze firewall, die deze mail door moet sturen naar één van de Hub-Transport servers. Op de firewall kan echter maar één (intern) ip-adress ingevuld worden, dus de mail wordt altijd maar bij slechts één server bezorgd. Als deze server dus uitvalt komt er geen externe mail meer binnen.

De meest voor de hand liggende oplossing zouhet inzetten van NLB voor de Hub-Transport servers zijn. De firewall kan dan zo geconfigureerd worden dat deze de mail doorstuurd naar het virtuele ip-adress van het NLB-cluster. Het probleem is dat ik op veel forums tegen kom dat dit niet supported zou zijn (aangezien Hub-Transport servers out-of-the-box al redundant zijn). Ik kan hier echter op Technet geen bevestiging van vinden, aangezien praktisch alle redundante MS scenario's uitgaan van het inzetten van Edge-Transport servers.

De enige manier die ik momenteel zie is het aanschaffen van twee extra servers en daar de Edge-Transport rol op plaatsen. Ik vind het echter zonde van de extra investering. De overige functionaliteit die een Edge-Transport biedt zal niet gebruikt gaan worden...

Iemand enig idee?

[alt-92]

Question Mark schreef op woensdag 27 juni 2007 @ 11:48:
Mijn vraag is echter hoe inkomende (internet)-mail redundant te krijgen is. Via de MX-records wordt de mail bezorgd op onze firewall, die deze mail door moet sturen naar één van de Hub-Transport servers. Op de firewall kan echter maar één ip-adress ingevuld worden, dus de mail wordt altijd maar bij slechts één server bezorgd. Als deze server dus uitvalt komt er geen externe mail meer binnen.

Ik denk dat het bold gedeelte je echte bottleneck is in dit verhaal, toch?
Geen beschikking over een routed subnet waar je eventueel een 2e IP kan 'lenen'?

[Grolsch]

als je 2 mx records met verschillende prioriteiten hebt, en je hebt 2 publiek toegankelijke SMTP servers, dan is je probleem toch ook getackled ?
MX10 = smtp1.bedrijf.nl
MX20 = smtp2.bedrijf.nl

valt smtp1.bedrijf.nl weg, dan gaat alles automatisch door naar mx20

[Powermage]

Grolsch schreef op woensdag 27 juni 2007 @ 13:13:
als je 2 mx records met verschillende prioriteiten hebt, en je hebt 2 publiek toegankelijke SMTP servers, dan is je probleem toch ook getackled ?
MX10 = smtp1.bedrijf.nl
MX20 = smtp2.bedrijf.nl

valt smtp1.bedrijf.nl weg, dan gaat alles automatisch door naar mx20

er van uitgaande dat de gebruikte firewall niet een of andere doos is die de mail echt ontvangt, scant op whatever en deze dan door gooit. maar wanneer die puur en alleen firewall speelt, idd een 2e MX record op een 2e publiek IP

[Erhnam]

Ik dacht dat een Cluster Continuous Replication alleen geen shared storage had en dus ideaal te gebruiken is over verschillende datacenters. Wat is het verschil met een Single Copy Cluster dan?

[Question Mark]

Erhnam schreef op woensdag 27 juni 2007 @ 13:57:
Ik dacht dat een Cluster Continuous Replication alleen geen shared storage had en dus ideaal te gebruiken is over verschillende datacenters. Wat is het verschil met een Single Copy Cluster dan?

Een single copy Exchange cluster maakt gebruikt van Shared Storage om zijn databases en logfiles op te slaan. Een CCR cluster heeft databases en logfiles lokaal staan en maakt gebruikt van logfile shipping om de databases op de passieve node "up-to-date" te houden. Een klein nadeel hiervan is dat de logfiles pas bijgewerkt worden op de passieve node als deze afgesloten zijn op de actieve node. In het ergste geval ben je na een failover dus 1 MB aan maildata kwijt.

In mijn geval heeft elke clusternode een eigen SAN, op de SAN's draait een mechanisme om de data realtime te syncen tussen beide rekencentra. Behalve Exchange komt er nog eea aan geclusterde applicaties (fileshares, printerspool, Citrix license server, etc) op het cluster te draaien, die geen build-in mechanisme hebben om data te syncen. Voor deze applicaties ben ik dus shared storage nodig.

Was het een dedicated Exchange cluster geweest, dan was de keuze inderdaad op een CCR cluster gevallen.

@all: dank voor de antwoorden voorzover. Ik zal morgen eens met de netwerkploeg om de tafel om eea door te nemen.

alt-92 schreef op woensdag 27 juni 2007 @ 12:37:
[...]Ik denk dat het bold gedeelte je echte bottleneck is in dit verhaal, toch?

Ligt eraan, met Exchange 2003 Clustering was je SMTP server virtueel waarmee dit probleem niet speelt. Met Exchange 2007 heeft MS besloten om enkel de mailbox server role clusteraware te maken. De overige services moet je redundant maken door middel van het plaatsen van meerdere servers. Een geclusterde Exchange 2007 omgeving bestaat dus uit minimaal vier servers, ipv twee voor Exchange 2003 (en 6 als je ook Edge-Transport in gaat zetten). Da's probleem één.

Probleem twee is dat de Hub-Transport rol niet opgenomen mag worden in een NLB-cluster. kan iemand dit bevestigen?

MS heeft dus enkele design beslissingen genomen die het redundant maken van Exchange niet makkelijker maken Het hebben van deze firewall had in combinatie met Exchange 2003 geen problemen opgeleverd.

alt-92 schreef op woensdag 27 juni 2007 @ 12:37:
[...]IGeen beschikking over een routed subnet waar je eventueel een 2e IP kan 'lenen'?

Wat bedoel je precies met dit gedeelte?

[alt-92]

Ik lees het verhaal denk ik een beetje verkeerd zie ik nu, het gaat om het interne IP waar de FW z'n connectie naartoe legt.

Ik zat namelijk te denken aan een 2e IP aan de outside voor je 2e MX die zelf ook naar een tweede interne server kan forwarden.
is de één dan niet bereikbaar dan heb je ook een failover.

[ Voor 40% gewijzigd door alt-92 op 27-06-2007 14:37 ]

[Erhnam]

Question Mark schreef op woensdag 27 juni 2007 @ 14:32:
[...]
In mijn geval heeft elke clusternode een eigen SAN, op de SAN's draait een mechanisme om de data realtime te syncen tussen beide rekencentra. Behalve Exchange komt er nog eea aan geclusterde applicaties (fileshares, printerspool, Citrix license server, etc) op het cluster te draaien, die geen build-in mechanisme hebben om data te syncen. Voor deze applicaties ben ik dus shared storage nodig.

Klinkt interessant! Mag ik vragen op welke manier je de data tussen de twee dca's realtime synct?

[Verwijderd]

Hub transport rol kan inderdaad niet in een NLB opgenomen worden:
http://forums.microsoft.c...?PostID=1397069&SiteID=17

Zie het antwoord van Scott Schnoll op die pagina.

[Question Mark]

Erhnam schreef op woensdag 27 juni 2007 @ 14:37:
[...]Klinkt interessant! Mag ik vragen op welke manier je de data tussen de twee dca's realtime synct?

Dat is een optie in de SAN's die we gebruiken (IBM FastT). Met deze optie is het mogelijk om dus realtime volumes te syncen over je SAN's in verschillende rekencentra. Ook zijn de datapaden redundant uitgevoerd. Elke clusternode is verbonden met beide SAN's en speciale software (multi-path drivers) regelt vanaf welke SAN de clusternode zijn disken toegewezen krijgt.

Standaard is dit het SAN in zijn eigen rekencentrum. Mocht echter een SAN uitvallen, en draait de clusternode nog, dan "krijgt" de clusternode de disken van het andere SAN en hoeft er geen failover plaats te vinden van de clusterapplicaties. Valt één compleet rekencentrum uit, dan vind een failover plaats en draait de overgebleven node alle clusterapplicaties vanaf het SAN in 'zijn' rekencentrum.

In alle gevallen blijf je dus operationeel. Bijna elke fatsoenlijke storageleverancier kan een dergelijke opzet leveren (HP, Netapp, IBM, etc). Als je op Technet gaat zoeken op "geografic dispersed cluster", dan verwijst MS je ook al snel door naar 3-party solutions om dit te realiseren.

Mocht je ooit een CCR cluster op willen zetten, houd er dan ook rekening mee dat je niet beveiligd bent tegen het uitvallen van een compleet rekencentrum. Een MNS cluster gaat pas "draaien" als (N/2)+1 clusternodes operationeel zijn, waarbij de file-share-witness als node meegerekend wordt. Valt nu net het rekencentrum uit, waar je file-share-witness staat, dan vallen er twee nodes uit (clusternode + file-share-witness). Met als resultaat dat er dan slechts één clusternode actief is en da's te weinig om je cluster overeind te houden. Oftewel: alles gaat down....

[/offtopic]

Verwijderd schreef op woensdag 27 juni 2007 @ 21:04:
Hub transport rol kan inderdaad niet in een NLB opgenomen worden:
http://forums.microsoft.c...?PostID=1397069&SiteID=17

Zie het antwoord van Scott Schnoll op die pagina.

Daar was ik al bang voor. De enige twee opties die overblijven zijn dan het alsnog inzetten van Edge-Transport servers, of het inzetten van een tweede MX-record en een tweede NAT op de firewall (die dan naar de andere Hub-Transport server verwijst).

Kostentechnisch zal die laatste optie veel voordeliger zijn, lijkt me dus dat dat de richting is die we in moeten gaan.