Among EVO SDDC’s many capabilities are provisioning and lifecycle management. While working through the design of these features, we determined that a new abstraction would be useful in simplifying both the implementation and user workflows. This abstraction has come to be called a Workload Domain. A Workload Domain is a generic abstraction that can be applied to a number of different types of compute workloads. This allows the administrator to deploy capacity for specific workload types using a policy-driven approach on top of modular, standardized hardware.
A Workload Domain has a set of policies that are configurable by the user during the deployment process. The current implementation includes the following policies:
Capacity: The amount of compute and storage required for the workload. This property is provided by the requestor. In a vSphere environment, this translates to host count and usable VSAN storage. In a desktop environment this would be the number and type of desktops the user intends to deploy.
Availability: The level of availability required for the workload. This property is selected from a menu of options by the requestor. The options and implementation can vary by Workload Domain type. In a vSphere environment, this property affects how a cluster is provisioned and some aspects of the default VSAN storage profile. Additionally, it informs the host selection process as to how to choose hosts within a rack and between racks.
Performance: The level of performance required for the workload. This property is also selected from a menu of options and varies by Workload Domain type. Primarily this impacts VSAN storage policy configuration in a vSphere environment.
Networks: The networks to be used by the Workload Domain. For vSphere-based Workload Domains, this would be Management, VMotion, VXLAN, VSAN, and Data Center / Workload networks. These can be provided by the requestor or automatically assigned in some cases.
In addition, any management software components required to operate the Workload Domain will be included in the deployment. This typically includes applications such as vCenter, NSX Manager, or Horizon View components such as Connection Server or Composer. These are automatically deployed by EVO SDDC with no input required from the user, although the quantity and configuration are driven by the values of properties such as Availability.
The end result is a fully configured environment that meets the requested specifications. This request can be reduced to a few simple steps, with the intervening deployment complexity being handled by the EVO SDDC workflow engine.
To further reduce the work burden on users, vSphere Workload Domains are integrated with the authentication and monitoring infrastructure that is deployed during the initial EVO SDDC startup process. This means that the user can immediately make use of the environment once deployment is complete.
In this example diagram, there are two Workload Domains deployed. Domain 1 contains two vSphere clusters, while Domain 2 has a single cluster. Each domain can have completely different configurations for VSAN, DRS, and HA. These configurations are based on the Availability and Performance parameters provided during the provisioning workflow. Also note that each Workload Domain has a vCenter Server and NSX Manager, which allows for separation of workload types or different groups of Administrators.
Not only does this abstraction simplify deployment, it also provides an atomic unit for the lifecycle management process. Upgrades and patches can be deployed at the Workload Domain level without impacting the other workloads running in the EVO SDDC environment.
The generic nature of the Workload Domain abstraction will allow us to create new types such as Cloud Native, VMware Integrated Openstack and others. So expect to see more Workload Domain types available in the future.
For more information on EVO SDDC, please visit https://www.vmware.com/products/evosddc
