Exchange 2013 Server Architecture: Part 1. Jeff Mealiffe Senior Program Manager Exchange Product Group

Transcription

1 Exchange 2013 Server Architecture: Part 1 Jeff Mealiffe Senior Program Manager Exchange Product Group

2 Agenda Part 1 Overview of the new Architecture The Client Access server role Part 2 The Mailbox server role Transport Architecture Service Availability Improvements

3 E2007/E2010 Server Role Role Architecture Architecture 5 major roles Tightly coupled Functionality Geo affinity Versioning User partitioning Forefront Online Protection for Exchange External SMTP servers Mobile phone Web browser Outlook (remote user) Edge Transport Routing and AV/AS Enterprise Network Layer 7 LB Outlook (local user) Hub Transport Routing & policy Mailbox Storage of mailbox items Client Access Client connectivity Web services Line of business application Phone system (PBX or VOIP) Unified Messaging Voice mail and voice access AD

4 What s wrong with the existing model? Exchange deployments are overly complicated Doing Exchange load balancing right is hard and often requires expensive solutions Requiring session affinity at the load balancer significantly impacts scalability Many hardware load balancing solutions are expensive and thus, are a luxury many of our customers can t afford or don t have the expertise to deploy Customers deploy based on dedicated server roles This means that in many cases, hardware is deployed that is unutilized (e.g., DIMM slots and disk slots, etc.) or under-utilized Too many namespaces are required (especially in site resilient designs)

5 Exchange: The evolution 2000/ Role differentiation through manual configuration Hardware solutions for reliability ($$$$) Separate roles for ease of deployment and mgmt. segmentation Support cheaper storage Separate HA solutions for each role Introduced the DAG Rich management experience using RBAC Leaves resources on the ground in each role Simplify for scale, balanced utilization, isolation Integrate HA for all roles Simplify network architecture LB Ex Ex CAS HT L7 LB Ex SAN Ex MBX MBX

6 The new server role architecture

7 Exchange 2013 architecture theme Use Building Blocks to facilitate deployments at all scales from self-hosted small organizations to Office 365 Server role evolution Network layer improvements Versioning and inter-op principles Benefits Hardware efficiency Deployment simplicity Low friction cross-version inter-op Failure isolation

8 Layer 4LB Exchange 2013 server role architecture 2 Building Blocks Client Access Array Evolution of E2010 CAS Array SMTP Front-End Forefront Online Protection for Exchange Edge Transport Routing and AV/AS Enterprise Network CAS Array CAS DAG MBX AD Database Availability Group Evolution of E2010 DAG Includes core server protocols Loosely coupled Functionality Versioning User partitioning Geo affinity External SMTP servers Mobile phone Web browser Outlook (remote user) Outlook (local user) CAS CAS CAS CAS Line of business application MBX MBX MBX MBX Phone system (PBX or VOIP)

9 Every server is an island EWS protocol MRS proxy protocol SMTP Protocols, Server Agents EWS MRS MRSProxy Transport RPC CA Assistants Custom WS Transport MRS MRSProxy Assistants RPC CA EWS Business Logic XSO CTS Mail Item Other API Banned E2010 XSO CTS Mail Item Other API Storage Store ESE Content index File system Store ESE Content index File system Server1 (V n ) Server2 (V n+1 )

10 Functional layering E2010 Architecture E2013 Architecture Hardware LB L7LB Load Balancer AuthN, Proxy, Re-direct CAS2013 CAS, HT, UM AuthN, Proxy, Re-direct Protocols, API, Biz-logic MBX Assistants, Store, CI Protocols, API, Biz-logic Store, CI MBX2013

11 The key to enlightenment User For a given mailbox s connectivity, the protocol being used is always served by the server that hosts the active database copy Layer 4LB Each CAS determines the right end point for the traffic, and so all sessions, regardless of where they started, end up in the same place This means that the rendering for clients like OWA occurs on the Mailbox server, Transport transcoding is occurring on the Mailbox server etc. CAS DAG1 MBX-A MBX-B

12 The client access server role

13 What is the CAS2013 role? CAS2013 is comprised of three components: Client protocols (HTTP, IMAP, POP) SMTP UM Call Router Thin, stateless (protocol session) servers organized in a load balanced configuration Session affinity NOT required at the load balancer Provides a unified namespace and authentication for clients Where the logic lives to route a specific protocol request to the correct destination end point Capable of supporting legacy servers with redirect or proxy logic Is a domain-joined machine in the corporate forest

14 CAS2013 client protocol architecture OWA Outlook EAS EAC PowerShell IMAP SMTP Telephony SIP + RTP Load Balancer Redirect CAS2013 IIS HTTP Proxy POP IMAP SMTP UM HTTP POP IMAP SMTP IIS POP IMAP Transport UM MBX2013 RPS RpcProxy RPC CA OWA, EAS, EWS, ECP, OAB MDB MailQ

15 Outlook Connectivity RPC/HTTP and the death of RPC/TCP What are the benefits? Does not require a RPC CAS array namespace for the DAG No longer have to worry about The Exchange administrator has made a change that requires you to quit and restart Outlook during mailbox moves or *over events Extremely reliable and stable connectivity model the RPC session is always on the MBX2013 server hosting the active database copy What changes? RPC end point for Outlook client is now a GUID (and SMTP suffix) Support for internal and external Outlook Anywhere namespaces

16 Third-Party MAPI Products Third-party MAPI products will need to use RPC/HTTP to connect to CAS2013 Exchange 2013 will be the last release that supports a MAPI/CDO download Third-parties must move to EWS in the future The MAPI/CDO download will be updated to include support for RPC/HTTP connectivity Will require third-party application configuration; either by programmatically editing a dynamic MAPI profile or setting registry keys Legacy environments can continue to use RPC/TCP

17 CAS2013 client protocol connectivity flow HTTP Load Balancer HTTP Load Balancer CAS IIS HTTP Proxy HTTP Site Boundary CAS IIS HTTP Proxy HTTP Site Boundary CAS HTTP IIS HTTP Proxy MBX MBX MBX Protocol Head Protocol Head Protocol Head DB DB DB Local Proxy Request OWA Cross-Site Redirect Request Cross-Site Proxy Request

18 Trade-offs Who s it for? Exchange load balancing options Generalist IT admin + Simple, fast, no affinity LB + Single, unified namespace + Minimal networking skillset - Per Server Availability Those with increased network flexibility Functionality Simplicity + Simple, fast, no affinity LB + Per protocol availability - One namespace per protocol Those who want to maximize server availability + Per protocol availability + Single, unified namespace - SSL LB - Requires increase networking skillset

19 A single common namespace example Geographical DNS solution Sue (somewhere in NA) DNS Resolution Round-Robin between # of VIPs mail.contoso.com DNS Resolution via Geo-DNS Round-Robin between # of VIPs Sue (traveling in APAC) VIP #1 VIP #2 VIP #3 VIP #4 DAG DAG

20 Summary: CAS2013 Client Protocol Benefits Simplifies the network layer No longer requires session affinity at the load balancer Just get the traffic to CAS2013 and let it handle the affinity CAS2013 can be farther away from MBX2013 and still offer good client performance (because it is a 1:1 proxy) Removes the need for RPC Client Access arrays Deployment flexibility CAS2013 provides more deployment flexibility; for example, consolidate to fewer sites Can deploy a single world-wide namespace Simplifies upgrade and inter-op Designed to proxy to multiple Mailbox server versions, up and down level DAGs can be replaced with E2013 at any desired pace

21 Coming up in part 2 Mailbox server role Transport architecture Service availability improvements

22 Questions?

23 2012 Microsoft Corporation. All rights reserved. Microsoft, Office 365, and other product and service names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.