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.
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
- 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.