Cloud Computing on Ulitzer

Microsoft has made some fairly substantial changes to the core architecture of Exchange 2010. Given that messaging can only be described as business critical today, it’s no surprise that many new aspects of Exchange 2010 and in particular its new architecture are designed to improve availability and management of its messaging systems.

Exchange 2010 includes many changes to its core architecture. In Exchange 2010, new features such as incremental deployment, mailbox database copies, and database availability groups work with other features such as shadow redundancy and transport dumpster to provide a new, unified platform for high availability and site resilience.^[1]

The core change in architecture will be felt not just by server and Exchange administrators, but by network and application delivery network administrators as well. With Exchange 2010 users no longer connect directly to Mailbox servers even when using Outlook in native MAPI mode; instead, all user access to e-mail, regardless of protocol, is achieved via Client Access Servers (CAS).

This specifically changes:

1. Outlook data connections go to RPC Client Access Service on CAS instead of connecting to Mailbox servers

2. Address Book Service on CAS replaces DSProxy interface and handles all Outlook Directory connections

3. Public folder connections connect directly to the Mailbox server, but through RPC Client Access Service running on backend

This may change network routing, host and domain naming, as well as the configuration of intermediaries as persistence is a requirement for Outlook, Outlook Anywhere, OWA, EAS, EWS, ECP, and Remote PowerShell. MAPI traffic over a VPN now flows along with HTTP, POP3, and other Exchange protocol traffic which may require adjustments to firewall and other security-related infrastructure configurations.

Also potentially a new requirement for network and systems’ administrators will be the need to provide load balancing for internal CAS connections given the increased load on this tier and the requirement to use CAS. This may require additional routing or changes to existing network routing architectures and will absolutely increase the load on the CAS tier as the highest volume of utilization certainly comes from internal connections. Considerations include capacity planning based on the roles of servers required for internal connections as it is likely there will be a requirement to increase the number of servers available in this tier. Microsoft offers guidance on sizing of servers based on role that will be valuable in this process. The impact of multi-role server deployments is not available at this time, although this is traditionally one of the architectural choices that has led to the use of load balancers as an integral component to a successful high-availability, well performing Exchange deployment.

This architectural change means that all traffic is available to be load balanced by an application delivery controller rather than the old model where only some traffic could be routed through the load balancer. This means all traffic can take advantage of additional functionality provided by application delivery controllers such as message security, application acceleration, and high availability configurations for increased reliability.

Example of a load balanced Exchange 2010 environment compared to a load balanced Exchange 2007 environment

Given that all client connections are now via CAS servers it is important to note that Microsoft is in the process of updating its high-availability and scalability design guide for Exchange and expects to publish it in the coming months. This paper will include more specific information on the role of hardware load-balancers for Exchange. Additionally, vendors should be updating any existing deployment guides specifically for Exchange 2010. F5 has already done so, and it is available here for your perusal [PDF].

This architectural change should have a positive impact on the cloud-based deployment of Exchange as the standardization on access via CAS servers means scalability can be more easily achieved via additional instances of CAS with granularity perhaps taking it even further by basing scaling needs on the role which the CAS server is playing in the overall architecture.

^[1] Microsoft TechNet library for Exchange Server: http://technet.microsoft.com/en-us/library/dd298026(EXCHG.140).aspx

Related blogs & articles:

• F5 Updates Microsoft Exchange 2010 Solution Portfolio
• WILS: Why Does Load Balancing Improve Application Performance?
• WILS: The Concise Guide to *-Load Balancing
• Load Balancing on the Inside
• WILS: Network Load Balancing versus Application Load Balancing
• Sessions and Cookies and Persistence, oh my!
• Persistent and Persistence, What's the Difference?
• Architects Need to Better Leverage Virtualization
• To Take Advantage of Cloud Computing You Must Unlearn, Luke.
• Vertical Scalability Cloud Computing Style