The qualification program described here is not a Microsoft certification or logo program. Microsoft makes no warranties or representations with regard to the third-party solutions included in the program, including without limitation the supportability of such third-party solutions.
Support for the specific implementation of third-party products within an Exchange solution is provided by the third-party vendor under the terms agreed between you and the vendor. You are solely responsible for selecting, evaluating, and determining whether any third-party offering listed on this site is appropriate for your use. Hardware or software load balancer vendors interested in participating in interoperability testing of their solutions with Exchange Server should contact exlb microsoft.
Listed below are hardware load balancers that have been tested by the vendor and reviewed by Microsoft to meet Exchange Server requirements. It's recommended that you visit the vendor's website for the latest information about product specifications, capacity, country support and documentation including release notes and known issues.
Contact the vendor for more information about these products. Listed below are software load balancers that have been tested by the vendor and reviewed by Microsoft to meet Exchange Server requirements.
It's recommended that you visit the vendor's web site for the latest information about product specifications, capacity, country support and documentation including release notes and known issues. Contact the vendor for more information on these products.
Exchange Server SP3. Understanding load balancing in Exchange However, this comes with trade-offs. Knowing only a single IP address, the load balancer can monitor only a single service. The risk with a Layer 4 solution is that if a service fails but the server is still available, clients can connect to the failed service. This means that a resilient Layer 4 implementation requires multiple IP addresses configured with separate HTTP namespaces per service, for example, owa.
Layer 7 load balancers work at the Application layer and can inspect the traffic content and direct it accordingly. Layer 7 load balancers forego the raw performance benefits of Layer 4 load balancing for the simplicity of a single namespace, for example, mail.
Exchange introduced significant flexibility for your namespace and load-balancing architecture. With many options for deploying load balancing in your Exchange organization, from simple DNS to sophisticated third-party Layer 4 and Layer 7 solution, we recommend that you review them all in light of your organization's needs.
The following scenarios come with benefits and limitations, and understanding each is key to implementing the solution that best fits your Exchange organization:. In this Layer 4 scenario, a single namespace, mail. The load balancer doesn't maintain session affinity. Because this is a layer 4 solution, the load balancer is configured to check the health of only a single virtual directory as it can't distinguish Outlook on the web requests from RPC requests.
From the perspective of the load balancer in this example, health is per-server and not per-protocol for the designated namespace. Administrators will have to choose which virtual directory they want to target for the health probe; we recommend that you choose a heavily used virtual directory.
For example, if the majority of your users use Outlook on the web, then choose the Outlook on the web virtual directory in the health probe. As long as the Outlook on the web health probe response is healthy, the load balancer keeps the destination Mailbox server in the load-balancing pool. However, if the Outlook on the web health probe fails for any reason, then the load balancer removes the destination Mailbox server from the load-balancing pool for all requests associated with that namespace.
This means that if the health probe fails, all client requests for that namespace is directed to another server, regardless of protocol. In this Layer 7 scenario, a single namespace, mail. We recommend this configuration for Exchange and Exchange The load balancer is configured to check the health of the destination Mailbox servers in the load-balancing pool, and a health probe is configured on each virtual directory. For example, as long as the Outlook on the web health probe response is healthy, the load balancer will keep the destination Mailbox server in the Outlook on the web load-balancing pool.
However, if the Outlook on the web health probe fails for any reason, then the load balancer removes the target Mailbox server from the load-balancing pool for Outlook on the web requests.
In this example, health is per-protocol, which means that if the health probe fails, only the affected client protocol is directed to another server. The load balancer is also configured to check the health of the target Mailbox servers in the load-balancing pool. The health probe is configured on each virtual directory. However, enabling session affinity decreases capacity and utilization. This is because the more involved affinity options, cookie-based load balancing, or Secure Sockets Layer SSL session-ID, require more processing and resources.
We recommend that you check with your vendor on how session affinity affects your load-balancing scalability. As in the previous scenario, as long as the Outlook on the web health probe response is healthy, the load balancer keeps the destination Mailbox server in the Outlook on the web load-balancing pool. Here, health is per-protocol, which means that if the health probe fails, only the affected client protocol is directed to another server. This last scenario with multiple namespaces and no session affinity offers per-protocol health checks and Layer 4 power.
A unique namespace is deployed for each HTTP protocol client. For example, you would configure the HTTP protocol clients as mail. This scenario provides per-protocol health checking while not requiring complex load-balancing logic. Some Exchange protocols require affinity and others do not.
For more details please refer to this Microsoft Technet article. For additional information on the various affinity options, please refer to this Microsoft Technet article:. Microsoft recommends that any port within the range to should be used, and that the same ports should be used on all Client Access Servers within the same AD site.
For a full Exchange Server port list, please refer to this Microsoft Technet article. There are multiple ways to deploy Exchange, but in this example two servers are used.
0コメント