CAS und NLB

Der Exchange 2007 CAS-Server ist ja geradezu prädestiniert, über ein NLB-Cluster (Network Load Balancing) hochverfügbar und skalierbar bereit gestellt zu werden. Mehrere Server haben die gleiche IP-Adresse und teilen sich brüderlich die Arbeit und springen auch für einander sein.

Bei dieser Seite handelt es sich nicht um eine "How-To" Seite, sondern um eine Diskussionsgrundlage und Denkanstöße. Ob diese Konfiguration für Sie zutreffend ist, müssen Sie selbst entscheiden. für die meisten Firmen ist es nicht erforderlich, vor allem wenn die Outlook Systeme Mitglied der Domäne sind

Allerdings durfte diese Funktion nur für POP3, IMAP4, ClientSMTP (587/TCP) und HTTP (80 +443) aktiviert werden. Die Nutzung von SMTP als NLB-Team wird erst seit Exchange 2007 SP1 offiziell unterstützt. Wer also Clients hatte, die per SMTP Mails eingeliefert haben, konnte nur mit DNS--RoundRobin oder einer IP-Adresse arbeiten, die im Fehlerfall auf den anderen Server übertragen wurde (z.B.: MiniSFT) oder die Client haben nicht den Standardport 25/TCP sondern 587/TCP genutzt.

Für die hohe Verfügbarkeit aus dem Internet sollte man sich den ISA2006-Server mal genauer anschauen. NLB funktioniert mit dem ISA-Server nur dann gut, wenn bei der Veröffentlichung der ISA-Server nicht die eigenen IP-Adresse zur Anfrage verwendet, da ansonsten das NLB-Team aufgrund der Affinität immer nur einen Knoten nutzt. ISA2006 hingegen kann mehrere identische Webseiten intern unter einem Namen nach Extern veröffentlichen. Natürlich können Sie mehrere ISA2006-Server nebeneinander wieder als Team betreiben.

Insofern gilt die Regel:

  • CAS Server intern Hochverfügbar -> NLB
  • CAS Server von extern hochverfügbar -> Reverse Proxy Server Load Balancing (z.B. ISA2006)

Fußangeln und Feinheiten

Was aber so einfach aussieht, kann ganz schön tückisch sein, da es nicht damit getan ist, einfach zwei oder mehr CAS-Server mit dem NLB-Assistent zu einem Team zu formen. Es gibt hier gleich mehrere Fakturen zu betrachten:

  • NLB-Fallen
    Auf die Tücken von NLB mit Switchen, Routern und diversen Netzwerkkonfigurationen will ich gar nicht mal genauer eingehen. Diese sind auf Network Load Balancing schon ausreichend beschrieben
  • Zertifikate
    Ein Punkt der sehr schnell auffällt sind die Zertifikate, die auf dem Server zu installieren sind. Alle NLB-Teammitglieder sollten das gleiche Zertifikat haben, damit sie auch mit dem gleichen Namen (z.B. owa.msxfaq.de) erreichbar sind. Allerdings enthält so ein Zertifikat natürlich nicht die einzelnen Hostnamen als SAN-Zertifikat. Einige Dienste greifen aber eben auf den Host direkt per SSL zu. Das zwingt uns ja schon zu einer zweiten Webseite mit eigener IP-Adresse, um ein zweites Zertifikat zu installieren oder mit Hostheadern und Wildcard Zertifikate oder SAN-Zertifikate zu arbeiten.
  • URLs
    Sicher sind ihnen die Parameter "ExternalURL" und "InternalURL" schon geläufig. Ansonsten sollten Sie CASProxy 2007 vorab lesen.
  • OAB und RPC/Internet
    Diese beiden Dienste können nur "genau einmal" pro CAS-Server konfiguriert werden und binden sich in die Default Webseite. Das ist für mich der primäre Grund, Warum ich die Default Webseite für NLB konfiguriere und keine eigene Webseite. Sicher kann man diese URLs auch auf eine andere Webseite umbiegen, aber aus meiner Erfahrung weiß ist, dass einige Dienste besser nicht verschoben werden.
  • SMTP Zugriffe und Connectoren
    NLB für SMTP ist nicht erlaubt, wenn Connectoren im Spiel sind. Ich vermute hier Abhängigkeiten mit den Zertifikaten, die bei SMTP zwischen den Exchange Server zur Verschlüsselung eingesetzt werden. Auf der sicheren Seite sind Sie also, wenn Sie NLB mit SMTP-Empfang z.B. nur für den Clientport 587/TCP einsetzen oder wenn sie die Verbindungen des Clients über eigene IP-Adressen und Netzwerkkarten führen, die nicht per WINS, DNS oder NetBIOS zu den primären Karten der Server gehören und damit von Exchange Connectoren selbst nicht genutzt werden.
  • Webseiten
    Und dann gibt es noch die IIS Probleme, dass man nicht eine Webseite auf eine IP-Adresse mit dem Port 443 binden kann und eine andere Webseite auf "any:443" konfiguriert. Je nach Startreihenfolge wird eine Webseite dann nicht starten. Bindungen an 443 mit mehreren Webseiten sollten immer explizit sein.

Das sind eine ganze Menge Vorbedingungen, die bei der Planung einer NLB-Farm berücksichtig werden müssen.

So könnte es aussehen

Daher möchte ich hier einen Vorschlag einer Konfiguration vorstellen, der mit einem "Single LAN" arbeitet und dennoch Verbindungen von den Clients zum CAS-Server von den Verbindungen zum Mailbox Server im Backend trennt. Durch die beiden Netzwerkkarten pro Server können die Adapter im Team ohne Microsoft Client betrieben werden (Sicherheit) und die Kommunikation mit anderen Servern läuft über die dedizierten Karten und bringt die Switches nicht ins Schwitzen. Weitere Details zur NLB-Konfiguration finden Sie auf Network Load Balancing.

CAS und NLB

Im Hinblick auf Exchange finden wir auf beiden CAS-Servern erst einmal die "Default Webseite", welche auf allen IP-Adressen lauscht und mit einem Selbstzertifikat, Ausgestellt auf den kurzen (NetBIOS) und langen (FQDN) Servernamen auch SSL anbietet. Da müssen wir was tun, um zwei und mehr Server mit einem gemeinsamen Namen im Netzwerk bereit zu stellen.

Sicher könnte man ein großes SSL-Zertifikat erstellen, welches die Namen aller CAS-Server in beiden Schreibweisen und die zusätzlichen Namen des NLB-Clusters enthält. Aber wenn Sie z.B.: offizielle Zertifikate benutzen, dann kann das sehr schnell teuer werden. Daher kann man die Umgebung auch mit mehreren Zertifikaten aufbauen. Dazu muss man aber wissen, dass auf eine Kombination aus IP-Adresse und Port immer nur genau ein Zertifikat gebunden werden kann. Und dies natürlich auch mit dem Namen im DNS übereinstimmen muss. Da aber auch einige Systeme direkten Zugriff auf den CAS-Servernamen und nicht nur das NLB-Team durchführen, sollte man dies berücksichtigen.

Die Servernamen sind natürlich auf die dedizierten Adressen der Server registriert, während der Name für das NLB-Team auf eine eigene NLB-IP-Adresse verweist.

Konfiguration

Viele Einstellungen kann man per grafischer Oberfläche machen, aber einige Parameter können auch mit Exchange 2007 SP1 nur per PowerShell konfiguriert werden. Auf jedem CAS-Server sind folgende Einstellungen erforderlich.

  • Verzeichnis C:\inetpub\<casservername>root anlegen
    Hier landet später das Basisverzeichnis des Webserver.
  • Anpassen der Default IIS-Seite (IP und Zertifikat)
    Diese Webseite sollte sich nur noch auf die NLB-IP-Adresse gebunden werden und das Zertifikat verwenden, welches von der Firewall (ISA Publishing) oder den Clients (intern oder per NAT oder VPN von extern erreichbar) akzeptiert wird. Dies ist meist ein SAN-Zertifikat, welches sowohl auf den Namen "autodiscover.firma.de" ausgestellt ist (Siehe auch Autodiscover), weil dieser Name intern genutzt wird.
  • Anlegen der Host-Webseite
    Da viele Dienste aber auch den "Hostnamen" direkt ansprechen, und sie den internen Namen aller CAS-Server natürlich nicht im offiziellen SAN-Zertifikat mit bezahlen wollen, muss man eine Webseite bereit stellen, die eben auf https://cassservername reagiert. Nutzen Sie folgende Parameter

Name = CAS
IP = <IP-Adresses des CAS-Servers>
Basisverzeichnis C:\inetpub\<CAS-Servername>root
Zertifikat = Selbstzertifikat oder ausgestellt aus Servername und Servername.domain.tld

  • Einrichten von Exchange
    Auch diese neue Webseite muss natürlich die entsprechenden CAS-Verzeichnisse von Exchange erreichbar machen. Das geht am einfachsten per PowerShell. Die ExternalURL bleibt absichtlich leer (Siehe auch CASProxy 2007)
New-OWAVirtualDirectory `
        -WebSiteName "CAS1" `
        -OwaVersion:Exchange2007 `
        -InternalURL:https://CAS1.msxfaq.de/owa
        -ExternalURL: $null 
New-OWAVirtualDirectory `
        -WebSiteName "CAS1" `
        -OwaVersion:Exchange2003or2000 `
        -VirtualDirectoryType Mailboxes `
        -Name "exchange"
New-OWAVirtualDirectory `
        -WebSiteName "CAS1"  `
        -OwaVersion:Exchange2003or2000 `
        -VirtualDirectoryType PublicFolders `
        -Name "public"
New-OWAVirtualDirectory  `
        -WebSiteName "CAS1" `
        -OwaVersion:Exchange2003or2000 `
        -VirtualDirectoryType Exchweb `
        -Name "exchweb"
New-OabVirtualDirectory `
         -WebSiteName "OWAExtern"
New-ActiveSyncVirtualDirectory `
        -WebSiteName "CAS1" `
        -InternalURL "https://CAS1.msxfaq.de/Microsoft-Server-ActiveSync"
        -ExternalURL: $null
New-AutoDiscoverVirtualDirectory `
        -Websitename "CAS1" `
        -WindowsAuthentication $true `
        -DigestAuthentication $true `
        -InternalURL "https://CAS1.msxfaq.de/autodiscover/autodiscover.aspx"
        -ExternalURL: $null
New-WebServicesVirtualDirectory `
        -WebsiteName "CAS1" `
        -InternalURL "https://CAS1.msxfaq.de/EWS/Exchange.asmx"
        -ExternalURL: $null
New-UMVirtualDirectory `
        -WebsiteName "CAS1" `
        -InternalURL "https://CAS1.msxfaq.de/UnifiedMessaging/Service.asmx" `
        -ExternalURL $null
  • Anpassen der Default Webseite
    Zuletzt müssen wir natürlich noch sicherstellen, dass die NLB-Webseite mit dem richtigen Namen im Internet und Intranet veröffentlich wird. Ich gehe hier mal von einem "Split-DNS" aus, bei dem interner und externe Namensraum gleich sind
set-OWAVirtualDirectory `
        -identity "owa (Default Web Site)"
        -ExternalURL "http://webmail.msxfaq.de/owa" `
        -InternalURL "http://webmail.msxfaq.de/owa"
set-ActiveSyncVirtualDirectory `
        -identity "Microsoft-Server-ActiveSync (Default Web Site)" '
        -ExternalURL "http://webmail.msxfaq.de/Microsoft-Server-ActiveSync" `
        -InternalURL "http://webmail.msxfaq.de/Microsoft-Server-ActiveSync"
set-AutoDiscoverVirtualDirectory `
        -Websitename "Autodiscover (Default Web Site)" `
        -WindowsAuthentication $true `
        -DigestAuthentication $true `
        -ExternalURL "https://autodiscover.msxfaq.de/autodiscover/autodiscover.aspx" `
        -InternalURL "https://autodiscover.msxfaq.de/autodiscover/autodiscover.aspx"
set-WebServicesVirtualDirectory `
        -WebsiteName "EWS (Default Web Site)" `
        -ExternalURL "https://webmail.msxfaq.de/EWS/Exchange.asmx" `
        -InternalURL "https://webmail.msxfaq.de/EWS/Exchange.asmx"
Set-UMVirtualdirectory 
        -Identity "MAIL05ADD\UnifiedMessaging (Default Web Site)"`
        -InternalURL "https://autodiscover.msxfaq.de/UnifiedMessaging/Service.asmx" `
        -ExternalURL "https://autodiscover.msxfaq.de/UnifiedMessaging/Service.asmx"
Set-ClientAccessServer `
        -Identity "CAS-01" `
        -AutodiscoverServiceInternalURI "https://autodisover.msxfaq.de/autodiscover/autodiscover.xml" `
        -AutodiscoverServiceSiteScope "Paderborn"

Diese Einstellungen sind für die anderen CAS-Server im Team entsprechend durchzuführen. Mit diesen Einstellungen haben wir nun erreicht, dass die vormals "Default Web Site" nun unter der NLB-IP-Adresse per SSL erreichbar ist. Weiterhin gibt es auf jeden CAS-Server eine dedizierte Webseite, die unter dem Namen des Servers erreichbar ist und das SSL-Zertifikat für diesen Server nutzt.

NLB und MOMT

Mit Exchange 2010 übernimmt die CAS-Rolle auch den RPC-Verkehr von Outlook (MOMT - MAPI on the Middle Tier). Wer also mehrere CAS-Server hat, kann diese auch "zusammenschalten". Dazu muss aber ein CAS-Array konfiguriert werden, da ansonsten der Client weiterhin den physikalischen Namen des Postfachservers verwendet.

Beachten Sie dazu auch die Seite CASArray

New-ClientAccessArray 
  -Name CAS 
  -Fqdn cas.domain.tld
  -Site Paderborn

Get-MailboxDatabase `
   | Set-MailboxDatabase -RpcClientAccessServer cas.domain.tld

Diese Eintragungen sind pro Site angestimmt vorzunehmen. Denken Sie daran, dass Sie den hier verwendeten Namen "cas.domain.tld" natürlich auch im DNS eintragen müssen, das er auf die NLB-Adresse verweist und das Zertifikat sollte für alle Fälle auch passen.

Achtung
Laut Microsoft muss sichergestellt, dass die "Affinität" gewahrt bleibt, d.h. dass ein Client bei einer Verbindung auch immer zum gleichen RPC-Knoten kommt und kein "Load Balancing" oder gar DNS-RoundRobin stattfindet.

Weitere Links