Apologies for the weird spacing, apparently Google changed something so Windows Live Writer can't post to Blogger currently. Posted this via a very weird work-around.
This week I was made aware of some VMware articles and whitepapers about running Microsoft Exchange on VMware VSAN. VMware VSAN is a 'virtual SAN' solution that employs local server storage and presents this to the hypervisor as a pool of shared storage, similar to the approach of Nutanix.
What surprised me, besides the mud slinging between VMware and their partner Nutanix, is the Exchange environment VMware built to execute their performance testing with.
I won't go into the details of the VSAN storage technology in this blog post, nor cover all aspects of the Exchange architecture design process. Today I want to focus on the high-level Exchange architecture used in the whitepapers.
The Exchange 2010 on VSAN whitepaper
First let's take a look at the 2014 whitepaper Microsoft® Exchange Server Performance on VMware Virtual SAN™.
Wait what? Exchange 2010 was used to perform the tests while Exchange 2013 was released almost two years earlier. Exchange 2010 was installed on Windows Server 2008 R2 while Server 2012 was available. Using older software to demonstrate your platforms capabilities may be done for very good reasons, however they were not explained in the whitepaper.
Microsoft introduced server roles in Exchange 2007 and soon discovered the new roles confused the crap out of their customers. So in the Exchange 2010 time-frame the Exchange team started to emphasize why combining the Mailbox, Client Access and Hub Transport roles on a single server was the preferred way to deploy Exchange. Most important reason: less complexity. And with that of course comes a decrease in costs, better reliability and more good things.
There have been situations where multi-role was not the most efficient option. Back when Exchange 2010 was released the most dominant hypervisor vendor was not able to assign more than 4 vCPU to a VM and when they were, they charged extra for that capability. As far as I know none of these limitations apply today so it's unclear why VMware did not deploy Exchange as recommended.
The Exchange 2013 on VSAN 6.0 whitepaper
The updated version of this whitepaper can be found here: Virtualizing Microsoft Applications on VMware Virtual SAN, Reference Architecture. In this whitepaper VMware explains how to deploy a HA Exchange 2013 environment while using the VSAN solution as the storage back-end.
Now starting with Exchange 2013 the Exchange team went a step further and consolidated their recommendations in the Preferred Architecture. This architecture was presented on industry conferences as MEC, TechEd and recently Ignite. In fact, the first article Microsoft released about Exchange 2016 contains a section called Preferred Architecture where the team explains the Exchange 2013 PA remains valid, with some minor updates.
Now let's compared the PA with the architecture VMware describes in this whitepaper.
First of all VMware did not deploy multi-role servers, they deployed 8 Exchange 2013 server where 4 could've done the trick. More servers equals an increase in complexity and costs.
The placement of the "DAG File Cluster" is a bit confusing too, especially because the Exchange Mailbox servers and the FSW are connected by a blue line. I wonder if the author understands the role of the FSW for the cluster.
Database and log files are isolated, this isn't required. And 80 GB is not sufficient for the OS (32 GB), page file (32 GB + 10 MB) and Exchange (30 GB).
Not just VMware, Citrix too
Recently I commented on some Exchange whitepapers by Citrix and today I looked at two whitepapers by VMware. Both vendors demonstrate they have limited understanding of Microsoft Exchange and the best practices Microsoft wrote.
Let me be honest. IT has been never more challenging as today. Customer's environments are growing in size and complexity. Trends like virtualization (server, network, storage, application, etcetera), BYOD, consumerization of IT, cloud computing and increasing demands from the business can drive an IT person crazy. This is why it has never been so important for vendors to reduce complexity, make sure recommendations are in line with other vendors and that customers receive all the help they need to implement the solutions in the best way possible.
As an Exchange consultant I often sat with customers discussing Microsoft best practices for Exchange and the storage or virtualization guy showing up with an outdated or slightly inaccurate document instructing the exact opposite. Customers expect the vendors to help them clarify stuff, not to cause even more confusion.
So Citrix, VMware and other vendors too, time to step up your game. Make sure you read and understand every article on the official Exchange Team Blog. Update your whitepapers during their lifetime when progressive insight or updated best practices require it. Ask Microsoft for feedback or involve Subject Matter Experts to review your document and provide some feedback from their perspective. I'm sure that with a little extra effort the quality of the whitepapers can improve a lot.
Dynamic Memory is een nieuwe feature van Hyper-V, nieuw sinds Service Pack 1 voor Windows Server 2008 R2. Dynamic Memory zorgt er voor dat je een virtuele machine een kleinere hoeveelheid startgeheugen kunt geven, waarna Hyper-V er voor zorgt dat een VM die het nodig heeft wat meer geheugen toegewezen krijgt. Door het beheer verder aan Hyper-V over te laten kan het geheugen efficiënter verdeeld worden waardoor je meer VM’s op de server kunt draaien.