Exchange 2010: Hochverfügbarkeit – CAS-Array mit Windows NLB

Einleitung

Die DAG (Database Availablity Group) macht es den Administratoren einfach Hochverfügbarkeit für die Postfachserver sicherzustellen. Eine DAG mit mehreren Datenbanken über mehrere Server zu spannen ist recht simpel. Aber wie sieht es mit den anderen Rollen des Exchange Servers aus? Wenn es zwar hochverfügbare Postfachserver gibt, aber durch einen Defekt der einzige CAS-Server im Unternehmen ausfällt, können Clients keine Verbindung mehr mit den Postfachservern herstellen. Das kommt schon fast einem Totalausfall des Systems nahe. In dieser Testumgebung werfe ich das Augenmerk gezielt auf die CAS-Rolle, DC und Postfachrolle sind mangels Hardware Ressourcen auf dem Test System nicht ausfallsicher ausgelegt.

Für die Testumgebung habe ich folgende Systeme installiert:

1 Windows Server 2008 R2 als DC und Exchange Postfachserver (ExSRV01)

2 Windows Server 2008 R2 als CAS und Hub Transport Server (ExSRV02 und ExSRV03)

Der Zeichnung kann man die Netzwerkkonfiguration der einzelnen Systeme entnehmen.

Die IP-Konfiguration der Server lautet wie folgt:

ExSRV01:

IPv4: 192.168.1.240/24

IPv6: 1999::1/64

ExSRV02:

IPv4: 192.168.1.241/24

IPv6: 1999::2/64

ExSRV03:

IPv4: 192.168.1.242/24

IPv6: 1999::3/64

Als Cluster IP-Adressen werden die IPv4-Adresse 192.168.1.243/24 und die IPv6-Adresse 1999::4/64 verwendet.

Hinweis:
Bei Windows Server 2003 war es noch Standard 2 Netzwerkkarten für NLB Cluster zu verwenden. Dies ist seit Windows Server 2008 nicht mehr zwingend notwendig. Der „Netzwerklastenausgleich-Manager“ nörgelt zwar beim Start etwas rum. Die Funktion ist jedoch nicht beeinträchtigt. Der Einfachheit halber verwende ich in diesem Beispiel nur eine Netzwerkkarte um es übersichtlicher zu halten. In Produktiv Umgebungen sollten dennoch 2 Netzwerkkarten verwendet werden. Die Konfiguration ist in weiten Teilen gleich.

Installation und Konfiguration NLB:

Zunächst installieren wir das Windows Feature „Netzwerklastenausgleich“ auf ExSRV01 und ExSRV02. Das können wir ganz einfach über den Servermanager durchführen:

Servermanager -> Windows Features -> Feature hinzufügen -> Netzwerklastenausgleich

Ein Klick auf „Weiter“ installiert das gewünschte Feature. Nach der Installation befindet sich der „Netzwerklastenausgleich-Manager“ unter Start -> Verwaltung.

.Als nächstes konfigurieren wir einen neuen Cluster, dazu klicken wir auf die Menüeintrag „Cluster“ und dann auf „Neu“. Es öffnet sich der Dialog zum Erstellen eines neuen Clusters.

Wir verbinden uns zunächst mit dem Server „ExSRV02“, dann klicken wir auf „Weiter“. Im nächsten Dialog müssen wir nichts ändern und bestätigen die IP-Konfiguration mit „Weiter“.

Dann geben wir die IP-Adresse an, unter der der Cluster in Zukunft zu erreichen ist, wir fügen also als IPv4-Adresse die 192.168.1.243/24 und als IP-v6-Adresse die 1999::4 hinzu und klicken auf „Weiter“

Als nächstes geben wir den zukünftigen DNS-Namen für den Cluster an, in meinem Beispiel ist das „casarray.frankysweb.local“. Diesen neuen Host muss auch auf unserem DC und DNS Server „ExSrv01“ als Host mit seiner entsprechenden Cluster IP-Adresse bekannt gemacht werden.

Hinweis:    Als Clusterführungsmodus habe ich „Multicast“ gewählt. Weitere Informationen zu den Clusterführungsmodi gibt’s hier:

Im nächsten Dialog werden die benötigten Ports konfiguriert. Ich habe folgende Regeln erstellt:

Port 80 HTTP (wird eigentlich nicht benötigt, ist aber für Testzwecke ganz nützlich)

Port 443 HTTPS (HTTP over SSL, wird für OWA benötigt)

Port 110 POP (wird nur benötigt wenn auch das POP-Protokoll genutzt wird)

Port 143 IMAP (wird nur benötigt wenn IMAP genutzt wird)

Port 135 RPC-Endpointmapper (für MAPI Clients, also Outlook)

Port 1024 – 65535 (dynamisch für Outlook RPC bzw. MAPI Verbindung)

Mit dem Klick auf „Fertigstellen“ wird der neue Cluster angelegt. Wenn dies geschehen ist, fügen wir den zweiten CAS-Server „ExSRV03“ dem Cluster hinzu. Dazu markieren wir den Eintrag für den Cluster und klicken auf „Cluster“ und dann auf „Host hinzufügen“. Wir geben „ExSRV03“ als Host an und klicken auf „Verbinden“, danach auf „Weiter“

Es folgen weitere Dialoge in denen keine Einstellungen geändert werden müssen

Nach einer Weile sollte auch der neue Host dem Cluster hinzugefügt worden sein.

Die Konfiguration vom NLB Cluster ist nun abgeschlossen. Um Probleme zu vermeiden schalten wir noch IP-Forwarding auf beiden CAS-Servern ein. Das können wir über die Eingabeaufforderung erledigen.

netsh int ipv4 set int „Intern“ forwarding=enabled
(Wobei „Intern“ für den Namen der Netzwerkverbindung steht)

Fertig!

Konfiguration Exchange

Abschließend muss noch ein neues CAS-Array über die Exchange Management Shell angelegt werden.

New-ClientAccessArray -Name „CAS Array“ -site „Default-First-Site-Name“ -FQDN „casarray.frankysweb.local“

Der Parameter „Site“ steht für den Active Directory Standort des CAS-Arrays. „FQDN“ ist der Name unseres NLB Clusters.

Als nächstes weisen wir der Postfachdatenbank das neue CAS-Array zu:

Get-MailboxDatabase | Set-MailboxDatabase -RPCClientAccessServer „casarray.frankysweb.local“

Ob das auch funktioniert hat können wir mit folgendem Befehl überprüfen:

Get-MailboxDatabase | select Name,RPCClientAccessServer | ft

Wenn in der Spalte „RPCClientAccessServer“ der Name unseres NLB-Clusters steht ist alles gut gelaufen.

Nachtrag: Möchte man die CAS-Rolle ausfallsicher auslegen, ist der einzig von Microsoft supportete Weg die NLB Lösung. Da Windows NLB aber recht beschränkt in den Möglichkeiten ist, sollte man in Erwägung ziehen einen Hardware Loadbalancer in Produktivumgebungen einzusetzen. Ich habe mir vorgenommen, auch einen Fail-Over Cluster mit der CAS-Rolle zu testen, aber wie vorhin erwähnt wird diese Variante nicht von Microsoft unterstützt.

In den nächsten Tagen werde ich einen Client mit Outlook 2010 zu dem Cluster verbinden und ein paar Ausfalltests durchführen. Die Ergebnisse werden dann hier veröffentlicht.