So we’ve already covered some of the basic elements of scoping vCA compute in part 1. Let’s delve into Dedicated Private Cloud (DPC) to show how the compute differs from the services built on Virtual Private Cloud (VPC, DR2C and OnDemand).
DPC compute basics
Unlike the multi-tenanted Virtual Private Cloud service, Dedicated Private Cloud (DPC) assigns physically dedicated host’s to each tenant (as the name might suggest). This has numerous benefits for compute, specifically;
- Physical isolation for the purpose of security and licensing compliance
- The ability to split resources across multiple VDCs
- The ability to control oversubscription at a VDC/VM level
Note: There are other benefits for network, which I will cover in a another post.
From a consumer perspective the services are almost identical, however there are a few additional parameters which can be configured from both the vCA and vCD web portals within the DPC service.
A great place to start is understanding what we have access to when working with DPC. The physical specification of the hosts is identical to VPC (2x 8 core, x86 Intel processors @2.6GHz and 256GB RAM in AU South at the time of writing). This gives us access to a core subscription of 35Ghz CPU and 240GB RAM (the remaining resources are reserved for the hypervisor).
From a compute standpoint our workloads have access to a single host’s resources, but in reality we actually have two host’s (1x Active / 1x HA) within our DPC environment. High Availability has been a critical component of vSphere for many years now and by no means is it excluded from vCA.
DPC scales in this manner until we reach 7 hosts (1x core & 6x add-ons) where a second HA host is added into our DPC environment. As a rule every 7 hosts in your allocation adds a HA host, capped at 28 which maxes out the underlying cluster of 32 hosts (28x Active + 4x HA).
So why is this important? Probably the most obvious reason (other than curiosity) is licensing compliance. For the more restrictive software vendors (*cough*Oracle) it is critical to know how many hosts are in our environment as a whole.
Correction: Since I wrote this post the model has changed to horizontally scale HA hosts from 16 hosts onwards (ie. one HA host until you reach 14x active hosts where a second is added).
DPC compute consumption
As DPC compute is dedicated to a single (master) tenant, all compute resources are 100% guaranteed. It is completely up to the account administrator(s) how resources are split over a single or multiple VDC’s within the organisation.
The ability to create multiple VDC’s is a powerful tool as it gives us the choice to run heavily oversubscribed (think test/dev) or with room to stretch (think mission critical) within the same subscription. It’s also useful as a subtenancy construct for service providers (to be covered in a later post).
Once we dive into the configuration for an individual VM we can set shares, reservations and limits as a mechanism to balance workloads according to priority when our VDC is in contention. By default the reservation is set to ‘0’ (as pictured below) for both CPU and memory (unlike VPC which automatically reserves 100% of the memory allocation for powered on VM’s).
Sticking with the default configuration (NORMAL, 0, Unlimited) will allow us to run heavily oversubscribed within our VDC with all workloads having equal access to resources. We get far greater control over the individual performance of each VM once we start pulling levers (read: configuring shares, reservations and limits). We’re not going to cover the specifics of resource management in this post, but I recommend reading this blog from @ as a start.
… is not as straight forward as VPC where we can use memory as a measure for sizing the environment (assuming memory is the most common resource for contention). If you are familiar with scoping and building a vSphere environment from scratch then this shouldn’t be too much of a chore.
When you are moving VM’s from an existing vSphere environment to vCA there are a number of tools that can be used to predictively analyse virtual resource utilisation like vRealize Operations Manager or VMware Infrastructure Planner. If not concerned with peak utilisation we can also use a point-in-time capture tool like RVTools. The key is to understand CPU and memory utilisation across a known resource quantity. As long as we know what is currently being consumed, we know how to size the compute for DPC.
For example, if we take a typical vSphere environment with 3 hosts (100GHz CPU / 384GB RAM) with a 15% and 50% utilisation respectively then we can conclude we need 15GHz CPU and 192GB RAM which is within the thresholds of a core subscription (35GHz / 240GB). However if memory utilisation is high, let’s say 75% (288GB) then we need a minimum of a core subscription plus a single compute add-on (70GHz / 480GB).
Before anyone gets fired up, I realise that the above is a drastic oversimplification for anything but the simplest migrations. It’s only intended to show that we don’t need to go to ridiculous lengths to get an indicative scope.
Note: We can use the same methodology for VPC, however we need would need to right-size the workloads before being migrated as vRAM is 100% reserved for powered on VMs.