Finally, there is a Service Group bound to each Virtual Server. Content Switch directs user’s request to the appropriate LB Virtual Server based on the URL. The general diagram is presented in Figure 2.Īs you can see, user connects to the Content Switch first. Finally, we need a catchall default entity for cases when URL does not match anything. In addition, we are not implementing MAPI at this point. Also, our testing indicates that Outlook Anywhere (RPC) and EWS need to be grouped together in order to avoid transient Outlook errors. Now, let us see how this general architecture can be translated into NetScaler configuration.įirst thing that comes to mind is that some web apps can be grouped together to avoid excessive complexity. The basic idea is that Layer 7 proxy allows us to have independent logical entry point for each Exchange web app which in turn allows us to independently switch them on and off based on their individual health rather than overall health of the server. Path: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parametersīack to top General Architecture of the SSL Content Switchīelow is the load-balancing architecture as seen by the Microsoft: By default, this parameter in the registry does not exist so we need to add it: The only thing to do is to configure TCP/IP idle timeout. In Exchange 2013, there are no CAS arrays anymore, so no need to create one. However, we are only interested in the parts connected to load balancing. Exchange 2013 load balancing does not require any connection persistence.īack to top Preparing Exchange CAS ServersĬonfiguring Exchange CAS server correctly is a vast task.That allows us to adhere to the Microsoft-recommended health-per-protocol principle. As described in the article above, we created custom monitors for all the Exchange web apps and bound them to their respective back-end entities (service groups).All the idle timeouts on the NetScaler must be at least 1.5 times longer than on Exchange server.We are using single namespace layer 7 proxy with no session affinity. Accumulating our experience of working with both NetScaler and Exchange, we decided on the following: Microsoft has a good but rather theoretical article ( Load Balancing in Exchange 2013) on the Exchange 2013 CAS load balancing. In our design, we followed both Microsoft and Citrix recommendations. That is why most of this article is about load balancing HTTPS traffic. While the other types of traffic (SIP, SMTP, IMAP4 and so on) are also important, they are not nearly as big in terms of volume and not nearly as complex. When we talk about load balancing Exchange CAS, it is mostly about load-balancing HTTPS traffic.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |