Anmerkung: Diese Infos ergaben sich aus einem Gespräch und sind daher als ungefilterte Mitschrift zu verstehen.
Das Exchange 2013 Environment besteht aus der „All-in-One“ Mailbox Server Rolle und der CAS Rolle, der aber wenig mit der 2010 CAS Rolle gemein hat. Die CAS Rolle im Sinne von 2010 liegt auch auf dem Mailbox Server, welche nun alle Rollen innehält.
Grund hierfür sind die momentanen Faktoren aus der IT Industrie: CPU Leistung ist günstig und kein ausschlaggebender Faktor und man möchte eine einfache, einheitliche und vor allem skalierbare Lösung. Obendrein wird die Fehlereingrenzung einfacher und die Nutzung heutiger Hardware effektiver. V.a. bei Virtualisierung. [1]
Ein EDGE Transport Server gibt es momentan nicht, falls benötigt/angedacht lässt sich ein 2010er Edge Transport integrieren, wie hier beschrieben.
Die CAS Rolle übernimmt keine Client verwaltenden Rollenfunktionen außer Authentifizierung, Proxying Dienst und eine begrenzte Redirection Funktionalität. Die CAS Funktionalität eignet sich wunderbar in Failover Situationen um den Outlook Clients im Cached Mode nach wie vor eine Verbindung zu Exchange zu suggerieren, während der Zeit die das Failover auf die andere Site läuft. Die „Session Affinity“ sitzt somit nicht mehr beim Load-Balancer sondern wird vom CAS geliefert. Details können hier nachgelesen werden, dort wird das Verhalten des neuen CAS genau erläutert. Layer-7 Loadbalancer sind somit nicht mehr erforderlich, empfohlen werden Layer-4 Loadbalancer.
Interessante Informationen zu den benötigten Umgebungsvariablen finden sich hier.
Ein Vergleich einer früheren Exchange 2010 Organisation zur aktuellen 2013er Umgebung:
2010 Architektur:
2010 wurde ab ca. 2005 entwickelt, dabei war Multicore/Processing noch nicht so verfügbar wie heute, somit wurden die Rollen sehr geteilt. Es gab damals viele Gründe für „Loosely connected“ Server. Größte Herausforderung stellt bei 2010 das Load-Balancing dar. Layer7 LB wurde benötigt. Viele Namespaces werden benötigt.
2013 bietet mit seiner All-in-one Rolle die Möglichkeit im Baukastenprinzip einfach zu skalieren, von klein bis groß. Update Szenarien wurden stark vereinfacht da verschiedene Update Versionen zusammen funktionieren. Jeder Server ist für sich geschlossen und spricht nur noch via EWS, MRS, SMTP usw. miteinander, die Cross-Kommunikation zwischen den Komponenten wurde unterbunden.
Dank der neuen CAS Rolle wird nur noch Layer4 LB benötigt.
Eine DAG kann aus 16 Mailbox Server bestehen, die DAG Members können in verschiedenen Rechenzentren stehen, welche mit einer Breitbandanbindung vernetzt sind.
Im Bezug auf das Hardware Sizing gibt es momentan noch keinen Calculator oder ähnliches. Jedoch lässt sich bei dem Wissen, dass alle Rollen auf ein und derselben Maschine laufen der aktuelle Calculator für Exchange 2010 gut anwenden:
Vorteile bei der Performance bietet die Teilung der Store.exe in Service und Worker Prozesse, jede DB hat ihren eigenen Worker Prozess. Das spart Leistung bei der Replizierung der passiven Datenbanken und erhöht die Geschwindigkeit beim Umschalten auf passiv zu aktiv. Die IOPS wurden weiter reduziert.
Empfohlen werden bei mehreren Mailbox Servern eine gleichmäßige Auslastung an Datenbanken Pro Server. Eine Datenbank sollte im Idealfall 1,67 TB Nutzdaten tragen und 2TB groß sein. Mehrere passive Datenbanken über mehrere Server verteilt erlauben die schnellere Wiederherstellung eines Servers, da das Seeding nun parallel von mehreren Servern erfolgt. Jeder Server transferiert Datenbank-Daten mit ca. 20MB/s auf einen weiteren Server bei Wiederherstellung. Skalierung ist also entscheidend bei möglichen Serverausfällen bzw. Datenbankausfällen und Wiederherstellungen.
In diesem Fall fällt der Zugriff auf die DB1 auf MBX15-1 aus, sei es dass die Datenbank nicht reagiert oder der OWA Dienst hängt, was durch den Server via Probes und Responders automatisch festgestellt wird. Der Fehler wird erkannt und der Dienst wird automatisch neugestartet. Der Dienst läuft wieder, aber kurz danach stoppt der Dienst evtl. schon wieder. Der Dienst konnte nicht mehr automatisch neu gestartet werden. Der Managed Availability Service bemerkt das und schaltet die DB1 auf MBX15-1 ab und schaltet DB1 auf MBX15-2 ist aktiv. Die Clients werden an den neuen Server umgeleitet.
Im Technet findet sich ein Screencast mit den wichtigsten Architekturänderungen:
In einem weiteren Video wird auch noch auf die Neuigkeite eingegangen. Ich finde beide Videos sind sehenswert.
http://technet.microsoft.com/en-us/video/whats-new-in-exchange-2013.aspx
Hi Frank,
guter Artikel, über den 2013 Exchange