Basel Exchange 2013 Architecture Overview René Lübke
Architecture Overview 40 René Lübke Size Matters 15 René Lübke Q&A 5 Alle Agenda
Architectural Overview - Generelle Übersicht - Client Access - Transport - Mailbox Server - Sizing
Generelle Übersicht - Umstände bei Exchange Server 2010 - Komplexe Deployments (7 Layer) - Viele Namespaces werden benötigt - Load Balancing kann zu Projekt/ Betriebskosten führen - Hoch Verfügbarkeit bei Public Folder nicht wirklich vorhanden
Generelle Übersicht - Ziele bei Exchange Server 2013 - Eine Lösung für kleine OnPrem Installationen bis zur O365 Plattform - Richtige Building Blocks - Fundament für zukünftige Versionierung und Versionsunteschiede - Weiterentwicklung der Server Rollen
Generelle Übersicht - Architektur Änderungen Exchange Server 2013-2 (3 mit Edge) anstatt 5 Rollen - Umstellung von 7 Layern auf 4 - Ausbau von «JBOD» Unterstützung - Reduzierung der IOPS Anforderungen
Generelle Übersicht
Architectural Overview - Generelle Übersicht - Client Access - Transport - Mailbox Server - Sizing
Client Access - Client Access Role/ Client Front End - CAS besteht aus 3 Kernkomponenten - Client Access (HTTPS/ POP/ IMAP) - Outlook Anyhwere ;-) - SMTP External Receive - UM Call Routing
Client Access - Kernfunktion des Client Front End Access - Authentisierung - Re-Direct - Proxy - Alle anderen Komponenten sind auf die Mailbox Rolle verschoben worden
Client Access
Client Access - Client Access Rolle - Ist ein Authentication End Point! - Basiert auf einheitlichen Namespace - Jede API hat Ihr Gegenstück auf der Backend (Mailbox) Rolle
Client Access
Client Access - Zugriffsmöglichkeiten - Nur RPC over HTTP(Outlook Anywhere) - RPC/TCP NUR bei Legacy Versionen - MAPI/ CDO wird (noch) Backend supported
Client Access - Koexistenz - Proxy und Weiterleitung (AUSSER RPC/TCP) - Proxy Funktion bei Exchange Server 2010 SP3 in gleicher Site - Weiterleitung bei Exchange Server 2007
Client Access
Architectural Overview - Generelle Übersicht - Client Access - Transport - Mailbox Server - Sizing
Transport - Elemente des «neuen» Transport Service - Edge Rolle (keine Änderungen) - Front-End Transport Service (FET) - Transport Service
Transport - Front-End Transport Service - KEINE SMTP Queues - End Punkt für den eingehenden SMTP Verkehr der Organisation - Ermittelt durch Mailbox GUID des Users die aktive Mailbox Datenbank
Front End Transport Service
Transport - Front-End Transport Service - Routing basiert auf Delivery Groups (DAG/ Mailbox/ AD-Site) - SMTP Verkehr wird nicht aufgeteilt (Bifurcation) Es existiert immer nur ein Endpunkt unabhängig von der Empfängeranzahl
Transport Service aka Hub Transport - 3 Transport Service Kernkomponenten - Transport Service - Mailbox Transport Delivery Service - Mailbox Transport Submission Service
Transport Service Architektur
Transport Service aka Hub Transport - Transport Service - Verarbeitet den SMTP Verkehr für die Organisation (Transport Rules/ Agents; Content Filtering; Anti-Virus) - Empfängt alle eingehenden Nachrichten durch den FET - Übermittelt alle ausgehenden Nachrichten (direkt oder über den FET)
Transport Service aka Hub Transport - Mailbox Transport Delivery Service - Empfängt die Mails vom Transport Service - Liefert Mails an die entsprechende Mailbox Database
Transport Service aka Hub Transport - Mailbox Transport Submission Service - Mailbox Database übergibt die Mail an Submission Service - Ermittelt den zuständigen Transport Service des Empfängers (Hub Selector) - Übermittelt die Mail and den Transport Service via SMTP
Transport Service - Transport Service - Hochverfügbarkeit - Shadow Redundancy (Speichert Mail im Transit bis Empfang quittiert wird) - Logische Grenze ist die DAG - Safety Net (Ausgelieferte Nachrichten bleiben per Default 2 Tage erhalten)
Architectural Overview - Generelle Übersicht - Client Access - Transport - Mailbox Server - Sizing
Jeder Mailbox Server ist eine Insel
Mailbox Server - Einige Änderungen - Jet-Engine wurde in C# neu geschrieben - Search Engine basiert auf Search Foundation (SQL Server ;-) ) - Public Folder Architektur
Mailbox Server - Einige Änderungen - Riesige Mailboxen (100GB+) - Jede MailbDB hat einen eigenen Store Prozess - Multiple Datenbank pro Volume - Reduzierung der IOPS Anforderungen
Mailbox Server - Einige Änderungen - Alle Komponenten in denen Daten verarbeitet, gerendert oder gespeichert werden sind auf dem Mailbox Server - Verbindung zum Mailbox Server nur über CAS möglich (Ausnahme MAPI CDO)
Architectural Overview - Generelle Übersicht - Client Access - Transport - Mailbox Server - Sizing
Size Matters - Auf die Grösse und Umfang kommt es an - Grösse und Anzahl der Mails pro Tag pro User im Durchschnitt http://blogs.technet.com/b/neiljohn/archive/2011/08/09/user-profile-analysis-forexchange-server-2010.aspx - Eckdaten (CPU) der Serverplattform http://www.spec.org/cgi-bin/osgresults?conf=rint2006 System # Cores # Chips # Cores Per Chip Base Copies Result Baseline ProLiant DL380p Gen8 (2.60 GHz, Intel Xeon E5-2670) 16 2 8 32 653 630
Size Matters - Grösse und Anzahl der Mails pro Tag/User - Ist die Grundlage für die Berechnung von - Log Space - IOPS Anforderungen - Prozessor Anforderungen - Memory Anforderungen
Referenzen der Product Gruppe
Referenzen der Produkt Gruppe
Size Matters - Sizing Beispiel - Hardware Plattform ~42K CHF Listenpreis - HP DL380p Gen8 E5-2670v2-2 Physische Cores/ 128 GB RAM - 12 x HP 4TB 6G SATA 7.2k im Server - MSA 2040-12 x HP 4TB 6G SATA 7.2k
Size Matters - Sizing Beispiel - Setup - 5840 User (50 Mails pro Tag / 75KB) - 10 GB Mailbox - Kein Raid für Datenbank Volumes - 4 Mailbox Datenbank pro Volume - 2 HD für OS / 2 HD für Autoseed / 20 HD für Mailbox Datenbank - Multi Role Server
Size Matters - User Mailbox 10 GB - 14 Tage Deleted Item Retention Time - Disk Space Bedarf ca. 10.054 GB - Maximum Database Size (vereinfachte Formel) - (3725 / 1.25) / 4 Disk pro Volume = 741 GB - 741 GB/ 10.054 GB = 73 User pro Datenbank
Size Matters - User Pro Volume - 73 User * 4 MailDB pro Volume = 292 User - User pro Server - 292 User pro Volume * 20 Volume = 5840 - HA Bereinigt ( 3 Server) = 1946 User
Size Matters - CPU - HP DL380p Gen8 E5-2670v2 2 Physische Cores - Liefert 43118 CPU Cycle System # Cores Result Baseline ProLiant DL380p Gen8 (2.60 GHz, Intel Xeon E5-2670) 16 653 630
Size Matters - CPU Anforderungen - 80 Mailboxdatenbank insgesamt (3 Server = 3 Kopien) - Failover = 1 Server down - Fiktiver Load sind 52 aktive/ 28 passive Mailbox DB s
Size Matters - CPU Anforderungen - Aktive DB x Anzahl User x CPU Requirement - 52 x 73 x 2.66 = 10097 CPU Cycles - Passive DB x Anzahl User x CPU Requirement - 28 x 73 x 0.69 = 1410 CPU Cycles - Insgesamt = 11507 CPU Cylces
Size Matters - CPU Berechnung der Auslastung - CPU Required / Server CPU Cycle - 11507 / 43118 = ~27% Auslastung im Failover Fall Das System könnte noch um eine MSA um 12 Disks/ 48 Datenbank erweitert werden Entweder zusätzliche 3504 User oder grössere Mailboxen für die User hinzugefügt werden
Basel THANK YOU!! Enjoy the Apero!