latest updates from easySERVICE™
I’m running quite a complex test environment, which includes multiple domains, multiple sites and all Exchange server roles in all the variations you can think of. Currently I can run up to 12 VMs on my Windows Server 2008 R2 with a low-budget Intel quad-core processor, 16 GB of memory, one Samsung SSD 830 drive (256 GB) and another hard disk drive. To keep it up and running, I spent quite some time investigating how to optimize performance and meet requirements. Here’s what I have learned about running a virtual test environment:
• Run the Microsoft Exchange Server Jetstress 2013 tool to verify performance.
You can follow any design guides or best practices when planning for the performance requirements of your Exchange servers. The single tool I found most useful for verifying that my plan will work as expected is the Jetstress 2013 tool. This tool allows you to verify that memory, CPU and disk subsystems actually can handle the load that you are planning. In my experience the main bottleneck is usually the disk subsystem; with Jetstress, you can identify it upfront, before you place too many mailboxes in the databases.
• Regularly check your VM resources and adjust them if needed.
Depending on your environment, I recommend that you regularly check your VMs running Exchange server to adjust their resource allocations. CPU and memory utilization change over time; thus if resources are scarce, your VMs will get slower the longer they run.
• Solid State Drives (SSDs) will speed up your test environment by as much as 1000%.
The first time I built my test environment, I used normal hard disk drives with spindles. The result was OK but the more VMs I ran simultaneously, the slower they ran. So I decided to move to SSDs and I was pleasantly surprised about the change. The OS boots in a matter of seconds, not minutes, and my six VMs start in minutes. Working in the VMs also became much faster than before. The opening time needed for OWA or the Exchange Management Shell is similar to, if not quicker than the high-end servers I’ve installed for various customers. Of course, for this you need to install your Server OS on the SSD as well as the virtual disks for your VMs.
Still, SSDs are not as safe as physical hard disks, so I follow these rules to make sure I do not lose my Exchange data if the SSD crashes:
• Use them only in test environments, not in your production environment.
• Don’t purchase the cheapest SSD. Remember, SSDs can cause data failures very quickly when you run them 24×7. In my personal environment, I have used the Samsung SSD 830 for more than 18 months now, and I am very pleased as no errors have been found on the disk yet. Also, don’t forget to check your SSDs regularly to prevent the total loss of your data in the event of a failure.
• For additional security, I created a database copy of my Exchange databases on a VHD that is located on a physical hard disk drive. Even if I lose the databases on the SSD, I still have a copy available on the physical disk.
• Don’t run the SSD at its limit. Make sure that you always have approximately 15-25% of free disk space on your SSD, because filling it with data will have a negative impact on performance.
• Use the Windows Task Manager to optimize memory usage for your test environment.
The Windows Task Manager is a crucial tool for planning CPU utilization and memory availability. On the host machine, it is important to reserve sufficient resources so the OS does not start to page out too much memory. Always reserve 1 GB of memory for your Windows Server 2008 R2 in addition to what you allocate to your VMs.
Windows Server 2012 requires more memory—I normally start with 2 GB and figure out what is really required, depending on the roles and features installed. Within the VMs, it is critical to consider the amount of Available and Free memory (shown in the Physical Memory panel under the Performance tab of Windows Task Manager).
Make sure that the amount of Free physical memory is not permanently zero and the Available physical memory can satisfy peak performance requirements. In my experience, you can go well below Microsoft’s memory requirements—but remember you should do this only on your test system, not on production systems. The figure below shows a multi-role Exchange server—you can see that you can free up some additional memory if required.
Source: Veeam. Siegfried Jagott.
Siegfried has planned, designed and implemented some of the world’s largest Windows and Exchange Server infrastructures for international customers. He received an MBA from Open University in England and has been a Microsoft Certified Systems Engineer (MCSE) since 1997.