Managing and supporting various vSphere environments over the years has given me a binocular view of what vSphere monitoring checks are best for keeping ESXi hosts healthy and VMs at peak performance.
And, now that most IT departments have realized that cramming as many VMs as possible onto a host is not a good or best practice, it’s easier to justify health and performance over virtual machine density relative to the return on investment.
Think of your vSphere as a STACK
From the bottom up, you have (physical stack):
- network switches, VLANs, interfaces, and connections
- storage units, LUNs, and spindles
- server hardware, memory, CPUs, hard drives
- ESXi
- vCenter & client
- databases
- monitoring tools
Then there are virtual resources such as (virtual stack):
- vSwitches
- datastore
- clusters
- virtual hardware
- resource pools
- vCloud Director
And finally on top of that are (platform stack):
- VMs
- OS
- Middleware
- vApps and Apps.
Most health and performance problems normally originate at the physical stack (in networking, storage, or server hardware) and affect the virtual stack.
For example:
Poor network performance on all the VMs sharing a vSwitch that is connected via a NIC to an oversubscribed network switch.
or
Poor performance on all the VMs that share the same oversubscribed storage LUN.
or
Poor performance on all the VMs that share the same oversubscribed pizza box server hardware.
7 vSphere Monitoring Recommendations
- Monitoring networking to ensure there are no switches or ports that are oversubscribed due to too many VMs sharing a single port or VLAN. This used to be a common health problem before 10G came along.
- Monitoring storage for available spare capacity in datastores and ensuring you are not queuing during peak business hours. Queuing is when there is not enough IO being processed by your storage unit and reads and writes are backing up (or queuing). This used to be a big health problem when disk drive capacity grew but spindle counts shrunk. THIS HAS BEEN IMPROVED with SSD and cache, but it is still important to ensure queuing is not happening during peak hours when top performance is critical.
- Monitoring for server hardware alerts and failures is another important daily health check. This can include firmware and drivers for blades, chassis, controllers, NICs, and various other hardware devices.
- Monitoring resource thresholds that are set to ensure more hardware resources are added before your warning thresholds are breached. Allowing an ESXi host to be oversubscribed puts all the VMs at risk of poor performance since it only takes one highly used VM (bully) to cause performance issues across all the VMs sharing the same host. I’ve found that at least N+1 Esxi host per cluster allows for DRS and HA to safely protect your vSphere.
- Monitoring for orphan and zombie VMs that waste valuable physical and virtual hardware resources. As well as snapshots and over-provisioning of memory and storage resources during VM deployments. Note: Reducing assigned resources after the VM deployment is almost impossible in most cases regardless of what capacity tools you have in place.
- Monitoring ESXi patches and VMTool upgrades to ensure important security and system updates are applied regularly.
- Monitoring that your VM OS deployment templates are up to date to ensure best practices are consistent after ESXi updates and upgrades are rolled out. Or that new OS patches and revisions are rolled up into new templates.
There are health check scripts that you can find online but these 7 monitoring recommendations will help ensure your vSphere is healthy and VMs are at top performance.
Conclusion
Never fall into the trap of letting density overrule performance, especially if the environment you are supporting is running business-critical applications that will impact your company’s customers.
This only covers vSphere monitoring checks that relate to the infrastructure stack (IaaS).
What is not covered are the checks and monitoring for the VM OS and application stacks (PaaS and SaaS).
Those checks are generally assigned to another team or group (DevOps Engineer or System Engineers).
Other recommended reading: vSphere 5 Monitoring and Performance Guide
