Exchange Server 2019: what is Preferred Architecture (PA)

Exchange Server Preferred Architecture (PA) is like a validated design with best practices of Exchange server deployment. It is highly recommended that you follow preferred architecture, however, due to some design challenges, it may not be possible to follow it. Exchange server can be deployed in these situation in a non-preferred architecture but do check supported designs prior to deployment.

The Preferred Architecture design key areas are as follows:

  • Namespace design
  • Site resilient datacenter pair design
  • Server design
  • Database availability group design

Namespace design:

The recommended namespace design is “unbounded model,” where a single namespace is used per client protocol. Well, what does it mean? Let us understand with an example of VirtualMaestro as an Exchange Organization with two sites..

VirtualMaestro users will connect to Autodiscover services by using the name https://autodiscover.virtualmaestro.in and outlook on the web by using the name https://webmail.virtualmaestro.in across both sites. Traffic will be distributed equally across the datacenter’s through solutions such as round robin DNS, geo-DNS, or any other similar solutions.

Image: Microsoft

Site resilient datacenter pair design

Extending the messaging infrastructure to multiple Active Directory sites to provide operational continuity for the messaging system in the event of a failure affecting one of the sites is identified as Site resiliency. Site resiliency can be achieved with recommended solution like database availability groups (DAG). Below are some guidelines for the same.

  • Ensure that DAG member servers are evenly distributed between two or more datacenter’s.
  • Datacenter’s should be well-connected which means they have a low RTT latency.
  • Ensure redundant network paths are available via different ISPs.
  • Each datacenter should be in its own Active Directory site.

Server Design

It is recommended to use physical servers that use locally attached storage such as JBOD for Exchange server deployment. Virtual machines are also supported for Exchange servers provided that best practices are implemented. Generally virtualisation platform like Hyper-V or VMware vSphere adds up the layers of complexity of management and also additional processing overhead which can affect performance slightly.

Resource recommended configuration:

  • 2U, dual socket servers with up to 48 physical processor cores (as per requirement)
  • Up to 256 GB of memory (as per requirement)
  • A battery-backed write cache controller
  • 12 or more drive bays inside server chassis
  • The ability to mix HDD and SSD within the same chassis.

Instead of setting up large configuration server (Known as scale-up model), try to use more number servers with slightly less resources per server (known as scale-out model) than that of large configuration servers. Scale out model enables you to have more number of failure points and better distribution of workloads.

Storage

Single RAID1 disk pair should be used for the operating system, Exchange binaries, protocol or client logs, and the transport database. The remaining storage that holds Exchange data should be formatted with ReFS and should be configured in two storage classes:

  • Traditional storage class
  • Storage state storage class

Traditional storage class

  • The JBOD storage contains mailbox database files and transaction log files.
  • Large capacity SAS disks where up to four database copies are deployed per-disk with a single active database copy per disk.
  • At least one disk is reserved as a hot spare for the auto-reseed process that quickly restores database redundancy after a disk failure.

Storage state storage class

  • This storage contains Exchange MetaCache Database (MCDB) files.
  • It is recommended to have extra 5-10% of additional storage is a solid-state storage con top of your requirement. For example, if a server is configured with 10TB of mailbox database files on traditional storage, then an additional 1 TB of solid-state storage is recommended to be deployed as additional storage for the same server.
  • It is also recommended that solid-state disks and traditional disks are deployed in a 1:3 ratio whenever possible.

Database availability group (DAG) design

Image: Microsoft
  • Exchange organisation can deploy one or more DAGs which can stretch across two datacenters.
  • This ensures distribution of the load across multiple servers during a failure scenario.
  • Both datacenter’s should be identical, which means there are same number of DAG members in each datacenter.
  • Witness server is used for quorum maintenance.
  • In case you have three datacenter available, it is recommended to deploy the DAG’s witness server in that third datacenter.
  • If not then the witness server can be placed in Azure.
  • Data resiliency is achieved by deploying multiple database copies that are distributed across the site resilient datacenter pair.

For more detailed information, do refer Microsoft Docs.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.