VMware Data Services Manager v1.3.2 – Agent Deployment
After a successful deployment and configuration of the Provider appliance in my most recent post of VMware Data Service Manager, it is now time to turn our attention to the Agent appliance. This component is responsible for initiating operations on a particular vSphere cluster. An Agent can only be part of a single vSphere cluster. However, multiple agents, which are provisioned across many vSphere clusters, can all be managed from a single Provider UI.
Just like the Provider appliance, the Agent is also delivered as a .OVA which is available for download from both VMware Tanzu Network and VMware Customer Connect. The product name is Data Management for VMware Tanzu and the current version is 1.3.2. Let’s look at the Agent deployment in this post.
DSM Agent Deployment
Unlike the Provider, the Agent deploys with only a single network interconnect. This network is attached to the control plane network, which is the network used by the RabbitMQ message broker. The Agent must be able to communicate to the Provider over this network. Another consideration is that the Agent needs to be able to communicate to, and resolve the vCenter server and ESXi hostname. Therefore it not only needs a route to the management / corporate network, but it also needs to be able to reach the corporate DNS server. This requirement was highlighted in the initial Provider deployment DSM post.
Here is an example of my Agent configuration, with the IP addresses obfuscated.
Again, it will take a few minutes for the Agent to come online. As per the deployment of the Provider appliance, I recommend opening a VM console to the Agent appliance and monitoring the messages until the ‘Started Appliance initialization script’ appears.
At this point, it should now be possible to open a browser to the IP Address of the Agent appliance, and begin the on-boarding process. Since the only network interface on the Agent appliance is on the control plane network, you will need to be able to reach this address with the browser. To login, use the Agent root user and the root password which was provided as part of the appliance deployment.
There is an assumption made that the vCenter server, ESXi hosts, vCenter Datacenter object, vSphere Cluster and VM Folder already exist on the vSphere infrastructure. Another assumption is that two vSphere SSO users also exist, one of which has a read-only role. The official documentation provides extensive documentation on how to create these vSphere SSO users, so I will not repeat those steps in this post.
Step 1 – Provider Authentication
The first step is to connect to the provider. Note that this is the Provider management interface that you are authenticating to, not the control plane interface. The username and password should be the credentials belonging to the Provider Administrator. In this setup, my Provider Admin is chogan@rainpole.com.
You will then most likely see a popup that requests that you accept the Provider thumbprint. Once you have done this, and the authentication is successful, you will be asked to select a Provider Organization. In my example, this is called ‘Rainpole’. The other item to select on this form is the operation. In this case, the idea is to create a new environment. However, there is also an option to recover an environment at this point should the agent need to be redeployed at some point in the future.
Note that in the Onboarding Type part of the form, the only organizations that are visible are Provider organizations. Tenant organizations are not displayed.
Step 2 – vCenter Configuration
The next step in the Agent Onboarding is to add the vCenter server configuration. You can choose between on-premises vSphere or VMware Cloud (VMC). In my example, the deployment is on-premises. The Data Services Manager official documentation recommends creating new SSO users and creating new roles with a specific list of permissions rather than using existing SSO users such as administrator@vsphere.local. In this example, I created a new user called dms-user@vsphere.local and assigned the appropriate roles, privileges and permissions. Note that the documentation talks extensively about assigning privileges to this SSO user. Some of the privileges mentioned in the documentation are not visible in vCenter, i.e. System.Anonymous, System.Read and System.View. However, any new role created in vCenter have these three System privileges automatically added. So you do not need to worry about these privileges for the user.
After clicking on connect, you will be asked to accept the vCenter thumbprint. At this point, you are prompted to add a read only user. Again, the official docs talk about how to create this user, but this is a user with a standard read-only role. for the purposes of this setup, my read-only user is called dms-read-only-user@vsphere.local.
Click connect once again to proceed to the environment step of the setup.
Step 3 – Environment
At this point, we are now defining the vSphere environment where the databases will be provisioned. This includes stating which datacenter to choose from the list of datacenters managed by vCenter. In that datacenter, we must also choose which vSphere cluster we wish to provisioned databases to, and also choose the VM Folder where the database VMs will reside. All of these must already exist – they cannot be created from the Agent Onboarding UI. All the objects in vCenter must also have permissions granted for the SSO users configured previously – the configuration will complain if there are issues with the permissions.
Once the above details have been populated, you can proceed to selecting a datastore on which to provision the database VMs, which (application) network should be used for the databases, and finally selecting the control plane network. This is because the database VMs will be multi-homed, with one network interface on the application network and the other network interface on the control plane network.
Step 4 – Database Template Storage
The next step selects an S3 Object Store bucket for the agent’s database template. We saw that once we setup the Provider, it saves a local copy of each database template. These templates are downloaded from the Tanzu Network to the Provider Repo S3 bucket. An Agent then copies a database template from the Provider Repo to the agent’s Template Storage S3 bucket. This occurs the first time that a template is used by the Agent to provision a database in its Onboarded Cluster. It is the agent’s database template S3 bucket that we are configuring here.
Step 5 – Save Configuration
That now completes the configuration. The final step is to save it.
After clicking on Save, you will be logged out of the UI. Log back in again and note the reference to RabbitMQ Shovels and link to provider UI for DB Operations. A RabbitMQ Shovel is a core plugin that moves messages from a source to a destination.
Note: At this point you should save the ENV ID as you will need this if you ever need to perform an environment recovery.
Verify Environment in Provider UI
If everything appears to be working, we can connect to the DSM Provider UI and verify that the environment is recognized. After connecting to the Provider UI, check the Environments view in the Provider UI. As shown below, you should be able to see a new onboarded environment. The Agent onboarding appears to have completed successfully in this example.
That completes part 2 of the VMware Data Services Manager setup. In the next upcoming blog post, we will take a look at the final configurations steps, such as adding users and creating namespaces, and finally deploy our first database.
One Reply to “VMware Data Services Manager v1.3.2 – Agent Deployment”
Comments are closed.