Plongée en eaux profondes dans l'architecture du nouvel Exchange 2013
Upcoming SlideShare
Loading in...5
×
 

Plongée en eaux profondes dans l'architecture du nouvel Exchange 2013

on

  • 507 views

Attention, session en anglais. Animée par Scott Schnoll, Principal Technical Writer dans l'équipe Exchange à Microsoft corp. Découvrez la nouvelle architecture des serveurs Exchange 2013. Cette ...

Attention, session en anglais. Animée par Scott Schnoll, Principal Technical Writer dans l'équipe Exchange à Microsoft corp. Découvrez la nouvelle architecture des serveurs Exchange 2013. Cette nouvelle version apporte des nouveautés fondamentales et bénéficie de l'expérience de gestion du Cloud O365 par les équipes online. Des évolutions de l'architecture fondamentale d'Exchange découlent directement de ce retour d'expérience et ont été intégrées au produit. Venez découvrir celles-ci par l'expert mondial sur le sujet.

Statistics

Views

Total Views
507
Views on SlideShare
507
Embed Views
0

Actions

Likes
0
Downloads
40
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Plongée en eaux profondes dans l'architecture du nouvel Exchange 2013 Plongée en eaux profondes dans l'architecture du nouvel Exchange 2013 Presentation Transcript

  • Exchange Server 2013Architecture Deep DiveScott SchnollPrincipal Technical WriterMicrosoft CorporationServeurs / Entreprise / Réseaux / ITTwitter: SchnollBlog: http://aka.ms/Schnoll
  • • Exchange Server Evolution• Architecture Changes• Client Access Server Role• Mailbox Server RoleAgenda
  • EXCHANGE SERVER EVOLUTION
  • Exchange: Past, Present, and FutureC C C H H HL7 LB2010• Separate HA solution per role• Introduction of the DAG• Support for HybriddeploymentsCAS HTMBX MBX2007• Separate roles fordeployment &segmentation• Support cheaper storageEx ExSANEx Ex2000/2003• Role differentiationthrough manualconfiguration• Backups and hardwaresolutions for “reliability”
  • • 5 server roles• Tightly coupledin terms of– Versioning– Functionality– Geo-affinity– User partitioningPrevious Server Role ArchitectureInternal Network Phone system(PBX or VOIP)WebbrowserOutlook (remoteuser)Mobile phoneLine of business applicationOutlook (local user)Layer 7 LBExternalSMTPserversForefront OnlineProtection forExchangeE HUMC
  • • Exchange deployments can be complicated• Load balancing is difficult and can requireexpensive solutions• When dedicated server roles are deployed,hardware can go unutilized or under-utilized• Too many namespaces requiredChallenges with Existing Model
  • ARCHITECTURAL CHANGES
  • • Use Building Blocks to facilitatedeployments at all scales – from self-hosted, small organizations to Office 365– Server role evolution– Network layer improvements– Versioning and inter-op principlesExchange Server 2013 Architecture Theme
  • • Hardware efficiency• Deployment simplicity• Cross-version inter-op• Failure isolationExchange Server 2013 Architecture Benefits
  • • 2 Server Roles– Client Access– Mailbox• Loosely-coupled– Functionality– Versioning– Userpartitioning– Geo-affinityExchange 2013 Server Role ArchitectureInternal NetworkExternalSMTPserversPhone system(PBX or VOIP)WebbrowserOutlook(remote user)MobiledeviceLine of businessapplicationDAGLayer4LBCASArrayExchange OnlineProtectionOutlook(local user)Exchange2010/2007ECCCMMM
  • Exchange 2013 Tenet: Every Server is an IslandProtocols,Server AgentsBusiness LogicStorageEWSRPC CATransportAssistantsMRSMRSProxyEWSRPC CATransportAssistantsMRSMRSProxyServer1 (Vn) Server2 (Vn+1)XSO MailItemOther APIsCTSStoreESEContentindexFilesystemXSO MailItemOther APIsCTSStoreESEContentindexFilesystemSMTPMRS proxyprotocolEWS protocolCustom WSBannedE2010
  • Functional DifferencesAuthN, Proxy,Re-directProtocols, API,Biz-logicAssistants, Store, CIExchange 2010ArchitectureAuthN, Proxy,Re-directStore, CIProtocols, Assistants,API, Biz-logicExchange 2013ArchitectureClient AccessMailboxClient AccessHub Transport,Unified MessagingMailboxL4 LBL7 LB
  • CLIENT ACCESS SERVER ROLE
  • • Domain-joined machine in the internal Active Directory forest– Thin, stateless (protocol session) server• Comprised of three components:– Client access protocols (HTTP, IMAP, POP)– SMTP– UM Call Router• Exchange-aware proxy server– Understands requests from different protocols (OWA, EWS, etc.)– Supports proxy and redirection logic for client protocols– Capable of supporting legacy servers with redirect or proxy logic– Contains logic to route specific protocol requests to their destination end-pointClient Access Server Role
  • • A group of CAS organized in a load-balancedconfiguration• Designed to work with TCP affinity (aka, layer4 LB)– Does not require application-level session affinity (aka, layer7 LB)• Provides a unified namespace andauthentication– Similar to Exchange 2010 in terms of providing a unifiedendpoint for client connectivity and authenticationClient Access Array
  • • Exchange 2013 supports RPC/HTTP only– No RPC/TCP• Benefits– Simplifies the protocol stack– Provides an extremely reliable and stable connectivity model– RPC session is always on Mailbox server hosting active copy– Eliminates need for RPC CAS Array and RPC CAS Arraynamespace(s)– Eliminates end user interruptions like “The Exchangeadministrator has made a change that requires you to quitand restart Outlook” during mailbox moves or *oversOutlook Connectivity to Exchange 2013
  • Client Protocol Architecture in Exchange 2013Load BalancerMDBHTTP ProxyIISClientAccessRPC CAMailboxIISRPSOWA, EAS, EWS,ECP, OABPOP,IMAPSMTP UMPOPIMAPTransport UMSMTPPOP, IMAPHTTPMailQRpcProxySMTPSIPRedirectSIP + RTPPOP/IMAPOutlook Web App Outlook EAS EAC PowerShell
  • • No longer requires multiple namespacesfor site resilient solutions or site-specificscenarios• Easy to setup a single, worldwide clientaccess namespace• Can be used in coexistence with Exchange2010Namespace Simplification
  • Single Common Namespace ExampleSue(somewhere in NA)DNS ResolutionDAGVIP #1 VIP #2Sue(travelingin APAC)DNS Resolution via Geo-DNSRound-Robin between # of VIPsDAGVIP #3 VIP #4mail.contoso.comRound-Robin between # of VIPs
  • FRONT END TRANSPORT SERVICE
  • • Handles all inbound and outbound externalSMTP traffic for the organization, and acts asclient endpoint for SMTP traffic– Does not replace the Edge Transport Server role– Functions as a layer 7 proxy and has full access to protocolconversation– Does not queue mail locally, and is stateless– All outbound traffic can appear to come from CAS 2013– Listens on TCP25 and TCP587 (two receive connectors)Front End Transport Service
  • • Network protection – centralized, load-balanced egress/ingress point for theorganization• Mailbox locator – avoids unnecessary hopsby determining the best Exchange 2013Mailbox server to deliver the messageFront End Transport Service
  • Front End Transport Service ArchitectureFront End Transport serviceSMTP ReceiveProtocolAgentsSMTP to MBX 2013SMTP from MBX 2013External SMTP External SMTPHub SelectorSMTP Send
  • Inbound Mail Flow1. FET accepts initial SMTPconnection2. After DATA command isissued, FET determines thenext destination for therecipients in the message3. FET starts the SMTP proxysession to the appropriatedestinationOutbound Mail Flow1. MBX 2013 determines if mailrecipient is a remote destinationand selects a FET within localsite when FrontEndProxyEnabledparameter on Send Connector isset to $true2. MBX 2013 connects to FET andinitiates SMTP conversation3. FET proxies outboundconnection to appropriatedestinationInbound | Outbound Mail Flow
  • • FET uses delivery groups: DAG, mailbox, AD site• Bifurcation does not occur on FET– Only one DAG or Mailbox server is selected, regardless of thenumber of recipients in a message• Server selection within the delivery group is basedon recipient type– If message only has a single mailbox recipient, select MBX serverwithin delivery group based on proximity of AD site– If multiple mailbox recipients, select MBX server in closest deliverygroup, factoring in site proximity– If there are no mailbox recipients (DG, MEUs, etc.), select a randomMBX 2013, giving preference to local AD siteEntry Point Routing
  • • CAS– Simplifies the network layer– Removes need for RPC CAS Array and RPC CAS ArrayNamespaces– Provides deployment flexibility• FET– Provides centralized, load-balanced egress/ingress point forthe organization and for client/application SMTPsubmissions– Avoids unnecessary hops by determining the best place todeliver the messageBenefits of CAS and FET Architecture
  • MAILBOX SERVER ROLE
  • • Server that hosts components that process,render and store Exchange data• Includes components previously found inseparate roles• Connectivity to a mailbox is alwaysprovided by the protocol instance on theserver hosting the active database copyMailbox Server Role
  • • Collection of servers that forma unit of high availability• Boundary for replication and*over• DAG members can be indifferent sites• Can have a maximum of 16Mailbox serversDatabase Availability Group
  • • Managed Store• Larger Mailbox Support• Modern Public Folders• Search Foundation Integration• Mailbox Transport ChangesMailbox Server Changes
  • MANAGED STORE
  • • Unmanaged code• Nested, difficult to debug• Single process creates SPOFPrevious Information Store
  • • Store service process(Microsoft.Exchange.Store.Service.exe)– Manages worker process lifetime based on mount/dismount– Logs failure item when store worker process problems detected– Terminates store worker process in response to “dirty” dismountduring failover• Store worker process(Microsoft.Exchange.Store.Worker.exe)– One process per database, RPC endpoint instance is database GUID– Responsible for block-mode replication for passive databases– Fast transition to active when mounted– Transition from passive to active increases ESE cache size 5XManaged Store
  • LARGER MAILBOX SUPPORT
  • • Large Mailbox Size is 100 GB+– Aggregate Mailbox =Primary Mailbox + Archive Mailbox+ Recoverable Items• 1-2 years of mail (minimum)– Increase IW productivity– Eliminate or reduce PST files– Eliminate or reduce third-partyarchive solutions• OST size control with Outlook2013Larger Mailbox SupportTime Items Mailbox Size1 Day 150 11 MB1 Month 3300 242 MB1 Year 39000 2.8 GB2 Years 78000 5.6 GB4 Years 156000 11.2 GB
  • MODERN PUBLIC FOLDERS
  • • Based on the mailbox architecture• Single-master model– Hierarchy is stored in a PF mailbox (one writeable)– Content can be broken up and placed in multiplemailboxes– The hierarchy folder points to the target contentmailbox• Because it’s a mailbox…– High availability achieved through continuousreplication– No separate replication mechanism• Similar administrative features to current PFs– No end-user changesModern Public FoldersMBX2013CAS2013MBX2013MBX2013Public logonPrivatelogonPublic logonContentMailboxHierarchyMailbox
  • 1. User connects to their home PublicFolder mailbox first, which should belocated near their primary mailbox.2. Folder contents live in one specificmailbox for that folder. All contentoperations are redirected to themailbox for that folder3. Folder hierarchy changes areintercepted and written to writeablecopy of Public Folder hierarchy4. All Public Folder mailboxes listen forhierarchy changes and update similarto Outlook clients5. When a Public Folder mailbox getsfull, move some folders to a newmailboxModern Public Folders
  • SEARCH FOUNDATION INTEGRATION
  • • Formerly known as FAST Search• Significant improvements in query andindexing performance• Significant reduction in number of times anitem is indexed• Leveraged by SharePoint and Office 2013Search Foundation Integration
  • Search Foundation PrimerCoreCatalogCTSIncoming DocumentsFilterWordBreakContentXFormMARSWriterIncoming Queries“CTS Flow”IMSContentXFormQuery Parse“IMS Flow”
  • Exchange Search InfrastructureMailboxDB IdxPassiveTransportTransport CTSMailboxStoreDBIndex NodeIdxExSearchCTSRead ContentLogLog
  • MAILBOX TRANSPORT CHANGES
  • • Transport on Mailbox server is three services– Microsoft Exchange Transport - Stateful and handles SMTP mail flow for theorganization and performs content inspection– Microsoft Exchange Mailbox Transport Delivery - Receives mail from theTransport service and deliveries to the mailbox database– Microsoft Exchange Mailbox Transport Submission - Takes mail from themailbox databases and submits to the Transport service• Transport has the following responsibilities– Receives all inbound mail to the organization– Submits all outbound mail from the organization– Handles all internal message processing such as transport rules, contentfiltering, and antivirus– Performs mail flow routing– Queue messages– Supports SMTP extensibilityMailbox Transport Changes
  • • Two separate services to handle mail submissions(from the store) and mail delivery (from theTransport service)– Mailbox Assistant and Store Driver combined• Leverages SMTP (encrypted) for communicationwith the Transport component and TCP465 forinbound traffic• Leverages local RPC for delivery to store• Is stateless and does not have a persistent storagemechanismMailbox Transport Service
  • Transport Service ArchitectureTransport ServiceSMTP to Mailbox Transport Delivery serviceSMTP from FET or the MailboxTransport service on other serversSMTP to FET or Mailbox Transportservice on other serversSubmissionQueueDelivery QueuePickup/ReplayDirectoryCategorizerRoutingAgentsSMTP ReceiveProtocolAgentsSMTP SendSMTP from Mailbox Transport Submission service
  • Mailbox Transport Service ArchitectureMailbox Transport SubmissionMailbox Transport DeliveryMailbox Transport serviceSMTP SendSMTP ReceiveHub Selector (Router)Store Driver SubmitMailboxAssistantsMailboxSubmitAgentsMAPI MAPIMailbox DatabaseSMTP to Transport ServiceSMTP from Transport ServiceStore Driver DeliverMailboxDeliverAgents
  • • When receiving a message, the MailboxTransport component can either deliver themessage or not deliver the message• If non-delivery is chosen, then the MailboxTransport component must provide aresponse back to Transport– Retry delivery– Generate an NDR– Reroute the messageMessage Delivery
  • • Introduced in Office 365 to redundantly store all mail for aconfigured time span to protect against mailbox irrecoverablefailures• Now has a “shadow” equivalent and is no longer a Single Pointof Failure (SPOF)• Consolidates, improves and replaces Exchange 2010 TransportDumpster functionality• SafetyNet retains data for a set period of time, regardless ofwhether the message has been successfully replicated to alldatabase copies or delivered to final destination• Processes replay requests from “primary” or “shadow”SafetyNet for lossy mailbox failoversSafety Net
  • SUMMARY
  • • Exchange Server 2013 uses Building Blocksto facilitate deployments at all scales – fromself-hosted, small organizations to Office 365• Exchange Server 2013 provides you with anarchitecture that is Flexible, Scalable, andSimpler and helps customers reduce costsKey Takeaways
  • Scott SchnollPrincipal Technical Writerscott.schnoll@microsoft.comhttp://aka.ms/schnollschnollQuestions?
  • Formez-vous en ligneRetrouvez nos évènementsFaites-vous accompagnergratuitementEssayer gratuitement nossolutions ITRetrouver nos expertsMicrosoftPros de l’ITDéveloppeurswww.microsoftvirtualacademy.comhttp://aka.ms/generation-apphttp://aka.ms/evenements-developpeurshttp://aka.ms/itcamps-franceLes accélérateursWindows Azure, Windows Phone,Windows 8http://aka.ms/telechargementsLa Dev’Team sur MSDNhttp://aka.ms/devteamL’IT Team sur TechNethttp://aka.ms/itteam