Kritische Namespace-Konfigurationen in Exchange Server 2013

Eine der wichtigsten Überlegungen bei der Installation von Exchange Server 2013 ist die Namespace-Konfiguration. Der Namespace ist eines der Dinge, die Sie beim ersten Mal richtig machen müssen, da es schwierig oder unmöglich sein kann, ihn später zu ändern.

Die Menge an Arbeit, die Sie investieren müssen Namespace Die Planung für Exchange 2013 basiert auf zwei Faktoren. Erstens erfordert die Namespace-Planung weniger Arbeit, wenn Sie eine saubere Bereitstellung durchführen, anstatt von Exchange Server 2007 zu migrieren. Zweitens erfordern einfache, kleine Exchange-Bereitstellungen weniger Arbeit als solche, die sich über mehrere Standorte erstrecken oder erfordern Lastverteilung.

In einer umfangreichen Exchange Server-Bereitstellung, die sich über mehrere Rechenzentren erstreckt und den Lastenausgleich verwendet, müssen sechs Hauptnamespaces geplant werden. Abhängig von der Konfiguration Ihrer Umgebung kann es andere geben:

  • Der IP-Namespace des primären Rechenzentrums
  • Der IP-Namespace des sekundären Rechenzentrums
  • Der Outlook Web App (OWA) -Failback-Namespace des primären Rechenzentrums
  • Der OWA-Failback-Namespace des sekundären Rechenzentrums
  • Der Legacy-Namespace unter der Annahme, dass die Umgebung von Exchange 2007 migriert wurde
  • Der Autodiscover-Namespace

In dieser Diskussion werde ich mich auf die IP-Namespaces in den primären und sekundären Rechenzentren konzentrieren. Diese Namespaces sind im Allgemeinen an den geografischen Standort gebunden. Angenommen, Sie haben zwei Rechenzentren in Nordamerika – eines in Miami und eines in Seattle. In dieser Situation können Sie Namen wie verwenden Miami.contoso.com oder Seattle.contoso.com.

Dieser Ansatz scheint zunächst unkompliziert zu sein; Die Dinge werden jedoch komplizierter, wenn Sie bedenken, dass einer der Vorteile der Verwendung mehrerer Rechenzentren darin besteht, sie platzieren zu können Datenbankverfügbarkeitsgruppe Mitglieder an beiden Standorten. Daher kann sich das Postfach eines Benutzers an jedem Ort befinden, je nachdem, welche Datenbankkopie zu einem bestimmten Zeitpunkt aktiv ist.

Sie müssen Ihren Benutzern die Arbeit erleichtern. Sie möchten einem Benutzer in Miami nicht sagen, dass er zu Miami.contoso.com gehen soll. Wenn dies nicht funktioniert, versuchen Sie es mit Seattle.contoso.com. Zum Glück müssen Sie nicht. Bei richtiger Planung ist es möglich, eine einzige Namespace-Konfiguration für den gesamten Postfachzugriff zu verwenden und Exchange Server die Details aussortieren zu lassen.

Denken Sie daran: Alles hängt von einer zuverlässigen Hochgeschwindigkeitsverbindung zwischen den beiden Rechenzentren ab. Die Dinge funktionieren anders, wenn niedrigLatenz Konnektivität ist nicht verfügbar.

Nehmen wir vor diesem Hintergrund an, dass sowohl das Rechenzentrum in Miami als auch das Rechenzentrum in Seattle Client Access Server-Arrays enthalten, die den Lastausgleich für die jeweiligen Rechenzentren übernehmen – und das jeweils Array besteht aus drei CASes. Wir könnten eine Öffentlichkeit schaffen Domain Name System (DNS) -Namensraumkonfiguration für Miami.contoso.com und Seattle.contoso.com, aber es ist einfacher, einen einzelnen generischen Namespace zu erstellen.

In dieser Situation könnten wir so etwas verwenden mail.contoso.com. Es spielt keine Rolle, dass dieser Internet-Namespace keinem unserer Rechenzentren entspricht. Der DNS-Eintrag kann die virtuellen IP-Adressen unserer CAS-Arrays enthalten. Dies bedeutet, dass eingehende Anforderungen zwischen den beiden Rechenzentren in a verteilt werden Round-Robin Mode.

Es gibt zwei Dinge, die Sie über Exchange 2013 CAS wissen müssen. Erstens führt CAS keine Datenwiedergabe mehr durch – ein CAS übernimmt nur die Authentifizierung und Proxy oder Umleitungslogik. Es wird nicht versucht, irgendeine Art von Datentransformation durchzuführen. Zweitens findet der Lastausgleich jetzt auf Schicht 4 statt auf Schicht 7 statt, sodass für den Lastausgleich keine Sitzungsaffinität mehr erforderlich ist.

Lassen Sie uns unter Berücksichtigung dieser beiden Punkte zu unserem Beispiel zurückkehren. Da DNS Anfragen gleichmäßig an die beiden Rechenzentren verteilt, kann die Anfrage eines Miami-Benutzers möglicherweise an Seattle gesendet werden. Wenn das Rechenzentrum in Seattle die Anforderung empfängt, weist der Load Balancer die Anforderung einem der CASes im CAS-Array zu. Dieser CAS authentifiziert die Anforderung und bestimmt dann, in welcher Postfachdatenbank sich das Postfach des Benutzers befindet.

Zu diesem Zeitpunkt muss der CAS entscheiden, ob die Anforderung an den Postfachserver weitergeleitet oder die Anforderung an ein anderes CAS-Array umgeleitet werden soll. Die Umleitung erfolgt nur, wenn sich die Anforderung auf bezieht Telefonie oder unter besonderen Umständen im Zusammenhang mit OWA-Anforderungen für Postfächer an anderen Active Directory-Standorten. In den meisten Fällen fragt der CAS den Active Manager ab, um festzustellen, wo sich die aktive Datenbankkopie befindet, und leitet die Anforderung dann an diesen Postfachserver weiter.

Über den Autor:
Brien Posey ist ein achtmaliger Microsoft MVP für seine Arbeit mit Windows Server-, IIS-, Exchange Server- und Dateisystemspeichertechnologien. Brien war CIO einer landesweiten Kette von Krankenhäusern und Gesundheitseinrichtungen und war einst für den IT-Betrieb in Fort Knox verantwortlich. Er war auch als Netzwerkadministrator für einige der größten Versicherungsunternehmen des Landes tätig.

Similar Posts

Leave a Reply