There will be four virtual data centers per vCenter Server that relate to the various networking zones. The virtual data center construct is an administrative boundary, but it is not necessary to create multiple instances whereby there isn't a requirement to completely segregate the various vCenter constructs from a privileges perspective. Four virtual data centers are used solely for the purpose of placing the vSphere Distributed Switches (VDS). ESXi hosts and networks would need to be recreated in a new single virtual data center. This activity should only be undertaken with extensive research and planning.
The following are the configuration recommendations for virtual resources:
- VM density per host: The operation team ensures that they run all required VMs on different clusters and that the RAM will not be overcommitted. It can also decide to use up to 90% available RAM capacity of each host. They use the concept of resource units while scaling their VMs, and each RU is the equivalent of 1 vCPU and 4 GB RAM.
- Consolidation ratio recommendation: They have a general rule regarding that the vCPU to pCPU ratio should be less than 3:1. This is this ratio that normally assists the RU limits on the ESXi host. The ratio should be guided by a combination of the specific applications of each VM, the CPU configuration and utilization of the VMs, and the performance metrics of the ESXi hosts on which the VMs are residing. Consolidation ratios and vCPU:pCPU ratios can be influenced by the following parameters:
- Workload awareness: Not all workloads are equal; a 4vCPU VM will not have identical performance characteristics to another equally configured 4vCPU VM.
- Virtual machine configuration: Due to the constraints to the RU model, there may be unnecessary additional overhead that impacts the overall consolidation ratio. It is generally a best practice that VMs should only be configured with the resources they require so as to reduce the negative impacts of symmetric multiprocessing of VMs that have more than one vCPU. As the RU model is a fixed model, VMs with increased RAM demands must have more vCPUs configured, even if these are not needed.
- ESXi performance metrics: Having a fixed CPU consolidation ratio is not generally recommended. Instead, taking into account the preceding detailed considerations with two important ESXi host metrics will permit a greater understanding of the potential consolidation ratios.
- CPU ready%: The percentage of time the VM was ready to run but no physical CPUs were available to schedule the request. A value higher than 10 should generally be avoided.
- Dashboards and supermetrics: vROPs can be utilized to create powerful and informative dashboards. Use cases always need to be identified as the following:
- Capacity planning dashboard: RU calculations are done through a combination of getting numbers from individual clusters and using these with a spreadsheet to determine capacity. Creating a dashboard and using metric/supermetrics to determine what full looks like to a customer will reduce the manual tasks that are required. This could also be used in conjunction with alerts to provide proactive warnings in regards to the cluster capacity.
- RU model dashboard: A dashboard containing metrics that are affected by the RU model; under-utilization of CPU or memory, and ESXi host metrics affected by symmetric multi-processing (SMP). We can identify use cases for dashboards and create them as required.
vROPs has a powerful alerting engine, which can be based of dynamic or static symptom thresholds. There are many out-of-the-box alerts from both VMware and third-party partners that have created solution adapters for vROPS. It will be always a task to resolve the initial number of alerts that are spawned by vROPS as this is an opportunity to identify and fix the issues that are identified, as well as to tune the existing alerts and symptoms and/or create new symptoms and alerts that fit the environment better. Custom groups and profiles can be used to create a granular approach to monitoring. The metrics for a production SQL cluster may be vastly different from a non-production file server. Using custom groups and profiles allows the alerts to be fine-tuned for the specific environment. This can identify how alerting from the vSphere environment should be achieved, and can determine whether vROPS can meet these requirements and, if so, configure them as required.