This article can also be found in the Premium Editorial Download "Virtual Data Center: Understanding I/O bottlenecks throughout your physical architecture."
Download it now to read this article plus other related content.
For IT departments in recent years, deploying and managing email systems have become core missions fraught with challenges. Messaging began as a set of disparate noncritical systems and grew into integrated mission-critical systems with high transaction rates and data retention requirements. But unlike other production systems, they lack the software pieces that make delivery easy or manageable. In addition, messaging systems touch many other IT systems, so they must be somewhat accessible to users outside the enterprise, and they are user interaction intensive.
In hopes of curing some of the ills of managing messaging systems, some IT managers now virtualize them. Is this a risky venture that will pose more problems than solutions, or can server virtualization actually reduce deployment risks, overall costs and the management burden? Can portable virtual machines be used to more easily scale growing email systems? Can they simplify disaster recovery? And can they help consolidate satellite servers? In this exploration of messaging virtualization, we address these questions while also delving into the challenges of vendor support, system requirements and I/O issues.
But first, IT organizations have to separate the hype from reality. Virtualization vendors and some messaging vendors contend that virtualization is a cure-all. That’s not necessarily so, of course, so dig deeper and find some real world deployment stories and documentation.
Both evaluations make a strong argument for virtualized messaging, but not because virtualized messaging systems outperform physical messaging systems. Rather, it’s because several virtual servers can perform an equivalent job performed by their physical counterparts on a single physical server. These reports and my discussions with IT managers suggest that disaster recovery and high availability can be easier and cheaper to achieve with virtual servers than they are with dedicated physical servers.
Knowing your requirements: Server, Memory and Storage
Messaging systems have their own unique requirements—Exchange 2000 and 2003 have a front-end/back-end architecture, while Exchange 2007 has a role-based architecture. Both architectures enable you to separate the different components of the messaging application onto dedicated servers to optimize performance, security and availability.
An organization that has limited budget or limited rack space for physical servers could utilize virtual machines to provide dedicated resources for each messaging server role instead. The degree to which you plan your deployment and understand your messaging system’s requirements may make the difference between success and failure. For a baseline, see the table “Email Systems and Their Requirements”, which lists various email servers and their role-based requirements. When you virtualize your messaging environment, you need to consider and plan for several other factors. Some factors, such as virtual machine time keeping, are common in most scenarios. Others will be specific to your own server, application and network setup.
Knowing your requirements:
Compliance: The Sarbanes-Oxley Act (SOX) has brought additional burdens and requirements for messaging systems in a virtual environment. Under SOX, all messaging-related systems must have accurate time stamps on messages and all message-related events must be accurate.
VMware counsels that best practices for deploying Microsoft Exchange in a VMware environment are the following: “Since much of operating system time keeping depends upon a count of CPU cycles, and because virtual machines which do not require CPU cycles do not get them, time in a virtual machine needs to be synchronized explicitly.” The best way to maintain proper time on all virtual machines is to turn on VMware Tools’ time synchronization within each virtual machine, then implement the Network Time Protocol (NTP) daemon from within the service console on every VMware ESX Server host and point to an external stratum 1 NTP source or a corporate time source that synchronizes to an external stratum 1 NTP source. This enables virtual machines to keep time based on the underlying ESX Server host and the ESX Server host to keep proper time using an authoritative external source.
I don’t recommend using Windows Time service to synchronize time in a virtual machine. The service is based on the behavior of a physical machine and is not aware of the unusual clock behavior of a virtual machine; as result, it doesn’t always synchronize accurately.
Messaging applications have server programs, databases and log files. Better performance can be achieved by distributing data to multiple disks. By placing the server programs, databases and log files onto three different virtual disks residing on three separate physical disks, you get better performance. But the process of optimizing the disk I/O for the virtualized storage system can be even more complex than physical storage configurations. When configuring your virtualization solution for storage, a certain amount of overhead needs to be factored in. If overhead isn’t planned for, your messaging servers may suffer from subpar performance.
Because of the complexity involved in planning storage for virtualized messaging systems, some organizations have prolonged or abandoned virtualizing their email systems because the virtualization solution has already been deployed and the I/O requirement for the messaging systems were not initially considered.
Many storage area network vendors encourage customers to first determine the I/O requirements of virtual machines and then determine the optimal number of physical spindles (i.e., disk drives) needed to support a virtualization technology. And when you keep in mind that messaging applications have the same I/O requirements even when virtualized, it’s easier to determine that number.
Whether you use ESX Server or another virtualization technology, having enough I/O in the disk storage that you plan to virtualize is the most important element for which to plan.
VMotion and Disaster Recovery
VMware’s ESX Server includes support for VMotion, which enables a virtual machine to be moved from one ESX host to another without requiring a user to shut down a virtual machine or disconnect remotely connected machines from their sessions.
For mission-critical applications like a messaging system, the impact of VMotion is significant. It enables you to perform live migrations with zero downtime, to perform hardware maintenance without scheduling downtime or disrupting mission-critical business applications, and to move virtual machines away from failing or under performing servers. As resources become exhausted on one ESX host, using VMotion and Distributed Resource Scheduler, or DRS, virtual machines are migrated to different physical ESX hosts without interrupting the email flow or client access to email. Even large virtual machines with as many as 2,000 users can be transferred in less than seven minutes. If you use VMotion, you may want to keep virtual machines small and just have more of them rather than having one large VM for your messaging system, which can reduce the transfer time on a per VM-instance basis.
With virtualized messaging servers, the disaster recovery implications are substantial as well. Deploying a disaster recovery solution for a messaging environment can be complex and expensive. High-availability solutions like Microsoft Cluster Service and network load balancing can eliminate single points of failure that may lead to data loss and disaster, but these technologies require an investment in additional hardware. By virtualizing the hardware used for high availability and disaster recovery of a messaging system, you can reduce downtime and speed data recovery even further.
Moreover, vendor testing shows that Microsoft Exchange Server 2007 performs well in a VMware Infrastructure environment. Dell engineers tested Microsoft Exchange Server 2007 with VMware Infrastructure’s VMotion (or live migration feature) and Vmware High Availability and had dramatic results. For example, a 2000 server recovered from a failed VM instance of Exchange server in 22 minutes.
When it comes to messaging infrastructure, virtualization is an ever-growing infrastructure
reality that offers design options. While virtualizing messaging systems brings some pain and
liability— planning, management and research are musts—you also gain the benefits of virtual
systems: easier disaster recovery and the ability to provide ancillary messaging services without
complex server infrastructure.
But you can’t go down this road without understanding the requirements of your messaging system, support concerns, SOX requirements and other considerations. Research whether your messaging vendor supports the virtualization technology that you have implemented. Finally, administer your virtualized messaging servers as if they were physical servers. Don’t take shortcuts on resource allocation, or the messaging application will suffer. Know the limits of the virtualization solution, and find the common ground between the messaging vendor’s and the virtualization vendors’ best practices for the best results.
About the Author
Richard Luckett is the president of Systms of NY Inc. With more than 15 years of experience as an IT professional, Luckett is a Microsoft Certified Systems Engineer and specializes in security and messaging. He is also a Microsoft Certified Trainer with more than nine years of Exchange Server instructional experience. Luckett co-authored Administering Exchange 2000 Server and Microsoft Exchange Server 2007: The Complete Reference by McGraw-Hill. He is the course director of seven best-selling Exchange courses for Global Knowledge Inc. and a contributor to SearchExchange.com on spam and security
This was first published in May 2008