The fact is that these days the ratio of cloud/hybrid vs. on-premise Exchange Server deployments is roughly 80% vs. 20% – changed days from say 3 years ago when we were still deploying mostly on-premise. However i have seen some movement towards Exchange 2016, released October 2015 which in reality is just Service Pack 2 for Exchange 2013. Of course MS rebrand it for marketing every three years, but for the techies out there there is little additional functionality – a few additional cloud hooks as expected from a product being run at scale in O365 – and a simplification of the existing “Preferred Architecture” to the Mailbox only role. For those companies out there running Exchange 2010 – still most of the current install base – they know it’s time to upgrade as Ex2010 has been in extended support since January 2015, a year ago already.
Back in the bad old days of Exchange 2010 RTM (I remember it well as i had been on my first Microsoft TAP Program for Exchange 2010), Microsoft unveiled this thing called a DAG (Database Availability Group) in an effort to ease the pain of Exchange Admins who had been through years of torture supporting Exchange 2007’s various flavors of High Availability (CCR, SCC, LCR aaaagggghh!). The DAG simplified things immensely and moved the concept of HA from server clustering and it’s associated O/S dependencies to the database level, where multiple distributed copies of DBs provided the availability for your mailbox data.
The problem here, was that in order to support your DAG and CASArray, Microsoft insisted you use Hardware Load Balancers (yes i was getting to the original point of this post eventually). I’ll leave aside the discussion about why the Exchange Team no longer recommend Windows NLB for Client Access Server Load Balancing– but assuming you like to be supported on your SEV A call to Premier Support then you deployed physical HLBs. Dependent on what knowledge the Sales guy had, you may or may not have been advised about this very relevant topic when budgeting the cost of your Exchange migration incorporating High Availability. If you were not advised on this need to deploy HLB to be supported, then you got a shock when I started asking difficult questions during the initial Discovery Phase of the migration project (remember Good Discovery = Awesome Project!), for example “where are your F5s or NetScalers?”
At time of writing the deployment cost of 2x F5/NetScaler/CiscoACE etc can end up at $30K+ very quickly – probably more than double the cost of your original Statement of Work for the Exchange upgrade.
This is where KEMP stepped in and killed it with a suite of products which changed the HLB game for the big boys. Visit their pricing page and you’ll see why. By using the handy Load Balancer Sizing Tool you can quickly figure current load based on concurrent SSL traffic and how much you then need to spend. Throw in the Edge Security Pack (ESP) and you get what the old Microsoft Threat Management Gateway (TMG) gave you (reverse proxy and a bunch of other stuff) – free of charge!
I was reminded of all this last week with a local government customer, currently running Exchange 2010 but unfortunately not running HA. I was doing a three day Microsoft Exchange Deployment Planning Session with them, effectively a few days knowledge transfer on the new Exchange 2016 offering.
They wanted to migrate to Exchange 2016 asap but presumed HA would be out of scope due to not being able to leverage any existing HLB for Exchange HA. A quick trip to KEMP’s website helped them confirm that a purchase of 2x VLM-200 would more than satisfy their requirements. One of the things i like about KEMP is their responsiveness – for either Technical Support or PreSales – i was able to have a live demo WebEx setup the same day with an engineer out of the USA who took us through the different technical variables and value to be attained from the purchase – not only for Exchange workloads. My customer was impressed and immediately confident about moving forward with the rest of the migration project.
And best of all? They leverage the value and engineering time invested in High Availability by the Exchange Product Team, instead of relying on P2V and other dubious VMware methods for hypervisor level HA. To quote Paul Cunningham MVP “…You might get some push back from customers or managers who have been sold on the idea of VMware HA for everything, or who take the line from VMware as implied support for the configuration. But in the real world I prefer to go with what is supported over what is possible….”
You know you need High Availability when you don’t have access to your data anymore. Don’t wait to be burned, getting there might not cost as much as you think.