Exchange 2013 architecture
Given
the development of different features over the past 10 years and the
growing influence of The Service, these factors coalesced into the
Exchange 2013 architecture. Briefly, the architecture used in Exchange
2013 can be distilled into four guiding principles:
Decouple version dependencies.
Communicate at the protocol layer of the network stack.
Concentrate functionality into the mailbox role.
Create building blocks for deployment.
Microsoft
wanted to break the close coupling between server roles that exists in
previous releases to enable different components to be upgraded in the
future without creating the need to upgrade everything. Sometimes, the
situation is referred to as a “tight versioning alignment,” meaning
that components had dependencies that prevented operation if all the
components were not upgraded together. Exchange 2013 therefore requires
servers to communicate at the protocol layer of the network stack,
using a well-defined set of protocols. Direct communication is not
permitted even if two components reside on the same physical server. If
the implementation works, it should mean that you can update mailbox
servers to the latest version of Exchange while continuing to use
Client Access Servers that run older software. Figure 1
shows how communication between Exchange 2013 Mailbox servers is
accomplished using three protocols. Unlike previous versions, when a
component such as the Store could communicate directly with the
transport service running on another service, all communications are
forced to flow up to the top of the stack and then over the most
appropriate protocol to a receiving component on another server. This
arrangement makes the roles loosely coupled because the only dependency
that exists is at the protocol layer.
Alongside an insistence on
using protocols to communicate, Microsoft radically simplified the CAS
role by moving all rendering and data access functionality to the
mailbox role. In many respects, the mailbox role is the core of
Exchange because the CAS now acts as a proxy for incoming client
connections.
The building blocks for deployment are the DAG for
Mailbox servers and the Client Access Array for CAS servers. Both can
be deployed independently, but you still need to ensure that a CAS is
deployed in every Active Directory site that hosts Mailbox servers.
Of
course, you do not have to deploy these building blocks if you don’t
want to or need to. A single multirole server can provide an excellent
email service to a small company. It doesn’t provide the kind of
resilience that additional servers can provide, but it will work.
