Virtualization is one of the best things you can do to enhance Exchange Server 2010 performance. It improves high availability, flexibility, quality of service and can help prevent unexpected
Even though most monitoring tasks are done to simply “keep an eye on things,” downtime can occur if they are not done on a daily basis. If it’s your responsibility to monitor Exchange Server 2010 and VMware vSphere, here’s a list of what you should check regularly.
#1 Server status
Most likely, Exchange virtual machines (VMs) are running across multiple virtual host servers. Because all your servers are extremely important, server status is critical. If you have already enabled VMware High Availability (HA), it will handle virtual host server outages and restart VMs as needed.
However, before VMware HA initiates server restarts and before you’ve heard any users complaining, you should monitor server status on a daily basis. This way, you'll know that everything is working properly. You'll also see that troubled virtual hosts are fixed as soon as possible.
To check physical server status on VMware vSphere, go into the vSphere Client and navigate to the highest level of hosts and cluster inventory. When there, click on the Hosts tab (Figure 1).
In the screenshot, you can see my virtualized servers' status, their uptime and CPU and memory utilization. In this case, the server status is Warning. I can see that the uptime looks good, but both server memory and CPU utilization are low.
If you have several host servers, you can sort these columns by clicking at the top of them. For example, you may want to sort your servers according to least amount of uptime.
#2 Review alarms and events
In vSphere, alerts are triggered based on either default alarms or custom alarms. The problem is that vSphere does not notify you if default alarms go off. You’ll only find out something is critically wrong with your vSphere infrastructure if you create alerts. I recommend that you review and configure alerts for important alarms so that you receive an email or SMS text when something goes wrong.
The Alarms tab in the vSphere Client contains alarms for hosts or VMs in the tree that includes Exchange VMs. For example, I set an alert on a virtual host server to notify me in the event of a fan failure.
An “event” refers to any action that occurs in your virtual infrastructure, and can be as simple as logging in. Reconfiguring a VM is also an event. Events can also occur automatically and without human intervention -- VMware HA restarting VMs when a host fails, for example.
Because there are so many different types of events, it can be difficult to predict when a failure might occur. I recommend that you review events on a daily basis. You can view all events across your infrastructure by navigating to the Events tab in the vSphere Client (Figure 3).
#3 Performance status
Because Exchange Server roles are spread across several VMs and performance can spike at various times during the day, you should monitor CPU, RAM, network and disk resource performance daily across all VMs.
The easiest way to do this is to put all Exchange-related VMs in a vSphere resource pool and then put that resource pool in a distributed resource scheduler (DRS)/HA cluster. From there, you can configure shares in that pool and individual VMs. It's also easier to monitor the performance of an entire resource pool than it is to monitor individual VMs.
I clicked on the vSphere Client’s Performance tab to check a VM's RAM utilization (Figure 4).
When monitoring CPU, RAM, network and disk utilization, you need to make sure you aren’t maxing out individual VM configurations. For example, be sure that vSphere isn’t forced to use memory reclamation techniques like host swapping; memory contention can diminish performance. You also don’t want to overallocate these resources by giving a VM four vCPUs when it only needs two, for example. This wastes valuable and limited virtual infrastructure resources.
Over time, you should be able to gauge what normal performance looks like. You'll get to the point where you can simply glance at a chart like the one shown in Figure 4, and identify a problem. Once you can identify a problematic condition, you can create custom alarms to automatically alert you when one occurs.
#4 Storage status
With hundreds or even thousands of users pushing maximum mailbox limits, it should come as no surprise that you also need to check storage utilization daily.
Exchange virtualization best practices recommend using thick-provisioned disks so that virtual disks on Exchange VMs don’t suffer from overprovisioning. Remember though, what you provisioned for the virtual disk can reach its maximum size, causing you to run out of storage space.
You should also check the status of your storage area network (SAN) and/or network attached storage (NAS) in which VM disk files are stored. Has the SAN or NAS suffered any outages? Are any alerts going off? Remember a poorly functioning SAN or NAS can cause your entire virtual infrastructure to go down.
You should also monitor storage I/O. Are an unusually high number of I/Os per second (IOPS) hitting the SAN? You can check this in the vSphere Client and view storage latency, queue depth as well as read and write IOPS for a single SAN logical unit number (Figure 5).
Virtualization monitoring and management tools to consider
There are several tools you can use to automate many of the monitoring tasks outlined in this tip. There also are several third-party management tools that will monitor your system and alert you to potential problems. The following are some virtualization management tools I recommend:
ABOUT THE AUTHOR
David Davis is the author of a VMware vSphere video training library from Train Signal. He has written hundreds of virtualization articles on the Web and is a vExpert, VCP, VCAP-DCA, and CCIE #9369 with more than 18 years of enterprise IT experience. His personal website is VMwareVideos.com.
This was first published in May 2011