From the course: Planning and Configuring a Microsoft Messaging Platform

Plan transport architecture - Microsoft Exchange Server Tutorial

From the course: Planning and Configuring a Microsoft Messaging Platform

Start my 1-month free trial

Plan transport architecture

- [Instructor] Let's plan our Exchange 2019 architecture. Microsoft has what's called a preferred architecture and it's made up of several pieces. The first part is high availability. And that means that Exchange will continue to run even if one Exchange server is down. It's extremely important when it comes to Exchange servers, because at any time a hard drive or a RAID card can fail, and this can cause the server to go down and cause a loss of connectivity to the users. By having an additional server that's synchronized then we don't have to worry about a single node going down. Multiple copies of databases means a database availability group. This allows you to make multiple copies of an Exchange database on multiple Exchange servers. Whether in your same data center or spread out in multiple sites. We can easily let our Exchange server setup get out of control. So we need to considers how we can reduce complexity, and add high availability. We do this using multiple different technologies. The first in namespace design. For the namespace the choices are to either deploy a bound namespace. Or an unbound namespace. The unbound design is a new feature that will pick the data center closest to the user rather than sending them all to the same location regardless of location or speed. This load balances the Exchange environment, and make the user experience go much faster and this is exactly what Microsoft 365 uses with hosted exchange E-mail. To achieve this high availability and site resilience. We must have two or more data centers that are connected to each other with a high speed connection. Also, the data center should be connected via redundant network paths. Meaning that you're going to have to have multiple internet service providers. All servers and physical servers will use locally attached storage. Physical hardware is deployed rather than virtual hardware, and that's done for two reasons. Servers are scaled to use 80% of resources during the worst failure mode, and virtualization comes with a performance penalty as well as adding an additional layer of management. As with the namespace model each database availability group within the site operates in an unbound model, with active copies distributed equally across all servers in the DAG. It both distributes the load across many servers and ensures the DAG member's full stack of services are available. For storage what's recommended is a SAN or, storage area network. And these can be used by database availability groups to share a single storage device using multiple servers. And we can encrypt the communication between the SAN and the servers using CHAP encryption. We can connect using either iSCSI or a fiber connection to our SAN device. Fiber is faster and iSCSIs make great strides in speed as well. However the limitation for fiber has yet to be reached, and it's not affected by electromagnetic interference. RAID is a redundant array of inexpensive disks, and it comes in many different types. RAID 10 or 50 is optimal, but does use up more disk space. So less disk space would be available. Typically RAID five or six will get the job done with more storage, but less speed. Increasing availability in speed is very important to Exchange users when connecting to the Exchange server. The service itself has many features, and can easily overwhelm a network if not properly configured with the preferred architecture.

Contents