Physical efforts in virtualization and mobility
Now true to form this isn’t a how to on “Load Balancing Exchange 2010 with NetScaler”; there are plenty of blogs on that, some of the best ones I’ve come across are below:
For the process end to end, these are very good:
Two from Dave Stork:
For handling rewrite which basically means appending ‘/owa’ to the end of a blank URL:
and another detailing content switching:
Actually the best one I have found, particularity for content switching is this one, which has a smart single expression covering OWA, RPC and OAB. It also has a summary of some useful tips at the end:
I do a fair amount of NetScaler work normally due to XenApp or XenDesktop and a requirement to include remote access within the solution. On the odd occasion I am called upon to do pure load balancing assignments however. Most of them are pretty straightforward including Exchange if you have a lot of IP addresses at your disposal. When you don’t you will need to get your head around content switching. One of the above blogs will help you there.
SSL Offload – Quick how to
Now to the point, Content Switching to one side, most blogs and guides you will come across will blindly advise the same course of action to achieve load balancing of Exchange. In summary:
Collectively these steps enable SSL offload on the NetScaler; that is the CPU intensive decryption process is moved away from the Exchange servers onto the NetScaler appliances. This is a particularly good thing if you have physical MPX NetScalers as they have dedicated SSL offload cards built into them, ultimately the Exchange servers will have improved efficiency. For a VPX it’s probably marginally better than having your Exchange servers carrying out this task but it will increase CPU utilisation on the associated hypervisor host(s).
So although I’m quite comfortable with NetScalers, Exchange is not my thing, so I’m not really happy about blindly making these changes to a production Exchange servers which have thousands of internal users on-board. After-all in many cases you may only have a maybe fifty or a few hundred concurrent external users to cater for, but with thousands of internal users using these CAS servers, there could be adverse affects.
The needs of the many outweigh the needs of the few
Consider the following:
Going against the grain
I decided I didn’t like the smell of the above scenario so I thought what’s wrong with using an SSL only Service Group assigned to my SSL vServer? To me it sounded like SSL bridge was the ticket, this will just proxy the connection through carrying out no decryption. There are two issues with this:
So the only remaining course of action is to use standard SSL service groups and vServers with no SSL offload, and do you know what? It works. OWA, ActiveSync, RPC over HTTP etc, all work just fine; there is no need to to make any changes to your Exchange servers that you may not fully understand (like me) at all. Sure you have no SSL offload but consider how many users you will be presenting this solution to, and the capability of your CAS servers.
What actually occurs in the scenario is: