(i) Dependency
To be able to use VCF 9.0 and VCF Automation data services, customers must use Data Services Manager version 9.0. It is not possible to integrate VCF 9.0 and VCF Automation with earlier versions of DSM. Also be aware that DSM 9.0 is an Add-On Service to VCF. It cannot be used in production by customers who do not have VCF subscription. Please take note that the DSM appliance installation is not part of VCFA configuration. The step of deploying the DSM appliance will need to be done before DSM is integrated with VCFA.
(ii) Infrastructure Policy Updates
DSM 9.0 introduces an additional way to define vSphere resources for databases and data services. Along with the traditional DSM-Managed infrastructure policies that we have had in previous versions of DSM, there is now a new way to define an infrastructure policy. Infrastructure policies in DSM 9.0 may now backed by a vSphere Namespace, which is a set of resources defined through the Supervisor. The major difference with this approach is that rather than defining everything around resources (CPU, Memory, Storage, Network) as we do in a DSM-Managed infrastructure policy, it is the vSphere Namespace which dictates which resources are available to a database provisioned with the vSphere Namespace based policy.
Another significant difference relates to what happens “under the covers” when a database is provisioned using a vSphere Namespace based infrastructure policy. With a vSphere Namespace infrastructure policy, the database is created using a vSphere Kubernetes Service (VKS) Kubernetes Cluster. This is different to the DSM provisioned Kubernetes cluster which is what we observe with the DSM-Managed infrastructure policies.
This should become clearer once we have setup the DSM / VCFA integration, and a tenant wishes to create a database.
Overview of DSM/VCFA Integration Steps
We can divide the DSM/VCFA integration steps as follows:
- As VI Admin, deploy DSM, create DSM permissions for DSM Admin via DSM UI, create infra policy
- As Provider Admin, connect VCFA to DSM
- As Provider Admin, create Data Services Policy, assign to ORG(s)
- As VI Admin, install Supervisor Service – Data Services Manager Consumption Operator
- As Tenant User, deploy Database / Data Service
Step 1: Configure DSM
Nothing much has changed here for VI Admins who have setup previous versions of DSM. As before, they install the DSM plugin on vCenter, which includes the deployment of the appliance. Once this step is completed, the vSphere Client is extended to include DSM specific actions. This includes the creation of infrastructure policies to provide guard-rails around resources consumed by data services. This initial setup should also involves the creation of a DSM Admin user which will be used later on to connect DSM to VCFA.
Step 2: Connect VCFA to DSM
As the Provider Administrator in VCFA, my first step is to connect VCF Automation to Data Services Manager. We’re going to assume that all of the other VCFA building blocks are in place, as these are beyond the scope of this post. To connect VCFA to DSM, navigate to the VCF Services section and select Data Services, as shown below. Click on the service configuration option. Add the URL of your DSM appliance, the DSM Admin Username and Admin Password. You will also need to provide the Certificate Authority from the DSM appliance. Once all of these settings are added, click Configure. Check your VCFA Provider tasks to ensure that there are no errors.
You can now return to the vSphere Client, and under vCenter > Configure > Data Service Manager > Permissions > VCF Automation, you should see details about your VCF Automation configuration, and a status of Ready. Next, we can proceed with the creation of a Data service Policy in VCFA.
Step 3: Create a Data Service Policy
Switching back to VCFA, once there is at least one Infrastructure Policy available for selection, the Provider Admin can proceed with the creation of a Data Service Policy. An Organization gets permissions to deploy data services to infrastructure in VCFA via a new construct called Data Service Policies. This construct is introduced to enable DSM to work in multi-tenant environments. Organizations within VCFA must first be granted access to data services and vSphere resources via Data Service Policies before any tenants within that organization has the ability to provision a data service. Below is an overview of the sorts of information that is added to a DSP. It include a policy name, type of service (Postgres or MySQL), which organization the policy is assigned to, which versions of an engine should be made available, which infrastructure policies to include and which backup locations are available. This gives us true multi-tenancy control over data services by allocating different data services and different resources to different tenant organizations.
Step 4: Install the DSM Consumption Operator on Supervisor
With the VCFA and DSM integration configured and our DSPs created from step 3, we require the services of the VI Admin one more time. In order to make the Data Service available to tenants, the DSM Consumption Operator must be installed as a Supervisor Service. This will make it behave like other services in so far as it becomes visible to the tenants to consume, similar to VKS (Kubernetes Service), VM Service and Volume Service. Navigate to the vSphere Client > Supervisor Management > Services > Add New Service. Then click on Register New Service.
The steps to install the Data Service Manager Consumption Operator can be found here. Some configuration is required in so far as the Consumption Operator configuration will need details about your DSM Appliance, similar to what was added to VCFA. The public Consumption Operator package and values manifests for DSM 9.0 are available here. Once the Consumption Operator components are up and running, the Database service becomes visible to tenant namespaces in VCF Automation.
Step 5: As a tenant / org user, deploy a database
A tenant of an organization can now begin provisioning databases, and providing details about topology, database name and admin details. The assumption is that this user is part of the organization who has been assigned the ability to provision DSM data services through the Data Service Policy (DSP) created in step 3. The tenant can only choose options available in the DSP.
The tenant provides some basic information includes Database Version, Instance Name and Topology. Database Name, Admin Username and Admin Password are auto-generated but are customisable should a tenant wish to do so. The database configuration is also captured in YAML for repeated use / GitOps type functionality. As the configuration progresses, an infrastructure policy must be chosen. There could be many infrastructure policies available for selection. VCFA does a “Logical AND” across all Data Service Policies to derive the available infrastructure policies, thus “Tenants can only choose Infra Policies that all applicable Data Service Policies allow”. If customer wish to have a “Logical OR” choice of infrastructure policies, then the infrastructure policies need to be included in a single DSP. Backup location and maintenance window settings are also available for selection, as well as advanced database parameters and host based access settings (i.e., pg_hba.conf). If successful, the database configuration is shown to the tenant in the ORG Portal. From here, the tenant can copy the connection string and connect to the database. They can also optionally retrieve the YAML manifest for the database if they so wish, and use this for future operations.
Summary
That completes the introduction to VCF Automation and Data Services Manager 9.0 integration. Hopefully this serves to highlight the fact that Data Services Manager is the DBaaS for VMware Cloud Foundation (VCF), offering multi-tenanted data services to your end-users on-premises, on vSphere. Additional details on the integrations can be found in the official documentation which is available here. I appreciate you reading this far. Please reach out if you have any questions or queries.