Getting started with Data Services Manager v2.1

The latest version of Data Services Manager (DSM) is now available. DSM version 2.1 delivers a new set of capabilities and functionality, including simplified deployment, MySQL Clustering, LDAP access to databases, Certificate Management, and log shipping enhancements. In this post, I will go through the deployment process of DSM version 2.1 as there are some significant differences when compared the 2.0.x user experience. Our aim is to make the whole process of deployment in 2.1 a lot easier. In future posts, I will look at the other enhancements in more detail, but for now I just want to focus on the “getting started” step.

Installation – Larger Appliance Capacity

The first thing you may notice as you go through the deployment is that the DSM appliance has grown in size. The reason for this is that we are now hosting the database images inside of the DSM appliance, rather than asking customers to store them in an external S3 compatible bucket (previous known as the provider repo). This makes the initial “getting started” experience much smoother and removes the need for an external provider repo S3 compatible bucket at setup time. There is still a requirement for S3 compatible buckets for both backups and logs, but these can be configured later on, post deployment. Here is a screenshot of the new appliance size taken from my lab. This is the 2.1 GA version 2.1.0.4891.

Installation – vCenter Thumbprint now required

In previous deployments, the vCenter thumbprint was optional during the deployment of the DSM appliance. In DSM 2.1, the vCenter thumbprint (SHA-256) is now required. We are making a conscious decision to make DSM 2.1 as secure as possible for our customers, thus the need to provide this thumbprint to establish trust and secure communication between DSM and vCenter Server.

The thumbprint must use the colon “:” separator. Fortunately this is quite easy to retrieve from a shell session to vCenter Server. Check out KB article 312777 for instructions of how to get the SHA-256 thumbprint from your vCenter server (the KB refers to it as a fingerprint, but it is the same thing). Once the setup is complete, you should be able to observe the same DSM install tasks as before. When the “Install Solution” task completes, refresh the vSphere client browser, and new Data Services Manager related items should appear in the Inventory > vCenter > Configure view.

A VI Admin can also monitor databases in the vSphere Client via the Inventory > vCenter > Monitor view.

New UI Features – Trusted Root Certificates

Those of you who are familiar with DSM 2.0.x will notice some new UI features in DSM 2.1, once the DSM Client Plugin is installed. The first of these is the Trusted Root Certificates. This feature ensures that DSM can securely communicate with various external services. After installation, vCenter trust will have been established, and the vCenter Certificate Authority (CA) will now be visible in the Trust Root Certificates. If you wish to use LDAPS for user access, securely ship logs to Aria Operations for Logs, or securely use external S3 buckets from an Object Store (that has a certificate signed by a CA), then the appropriate CA from each of those services will need to be added to the set of Trusted Root Certificates on DSM. The screenshot below show the CA from my vCenter which has already been added. Additional Trusted Root Certificates from my LDAPS server, Log Insight server and S3 object storage are also present. These can be added either from the vSphere Client below, or via the DSM UI.

New UI Features – Upload DSM Update Bundle

Once again, in an effort to make things simpler for the DSM admin, we have added a new UI feature to add updates and patches to DSM. For those of you who deployed DSM using the air-gap process, you will remember that you were tasked with adding update bundles directly to the provider repo bucket. This was not very user-friendly, and was a little error prone. To avoid this situation going forward, we have added a new UI-based mechanism to add updates to DSM. You can find it under the Version and Upgrades view. As new patches and updates get released for v2.1 and later, this will make it much easier to apply them to your system.

Infrastructure Policy – DRS & HA now required

The next noticeable change is during the creation of the infrastructure policies. In this release, we are requiring that both DRS and HA are enabled on the compute resources selected for the infrastructure policy. This was not a requirement in previous versions of DSM, but as we aim to position this solution with our enterprise customers, we now are requesting that these features are enabled. As you might imagine, both these features provide high availability and resource distribution for DSM provisioned databases and data services. You will not be able to create an infrastructure policy unless the compute objects have these core vSphere features enabled. In fact, DRS will need to be Fully Automated in DSM 2.1 environments. This new requirement is also highlighted in the UI.

Configuration – New Bucket Requirements

While we have reduced the need to have a Provider Repo bucket in v2.1, there is still a requirement on S3 compatible buckets for provider logs, provider backup and database backup. One major difference in 2.1 relates to PostgreSQL backups. The backup task is done by a component called pgbackrest. Previously in v2.0.x, pgbackrest accepted an IP address backup location (S3 compatible bucket). Now if you wish to use a backup location endpoint with an IP address, the certificate used by the endpoint must include the IP address as a DNS entry in the Subject Alternative Name (SAN) section of the certificate. If upgrading from a previous version of DSM, there is no need to delete the existing bucket. Simply update the certificate on the object store with the new SAN entry, then edit the buckets in the DSM UI and accept the new updated certificate.

Another new enhancement that you will observe on S3 buckets is a new “Force Path Style” option for provider backup, provider logs and database backup buckets. You might ask what this is. There are two addressing options for S3 buckets; virtual addressing and path style. By default, virtual addressing will be used if the bucket is DNS compatible and has an FQDN address. If you wish to use an IP address, you must force the access to path style. If you do not select the checkbox, then the following admission webhook is displayed:

Hover the mouse over the information signpost for the Force Path Style and additional information is displayed. If you wish to continue with IP addressing, as might be the case if you are using an on-premises object storage solution for a DSM proof-of-concept, then check the box and accept the certificate from the Object Store to continue.

Database Templates – no Data Services visible

At this point, once the appliance is deployed and DSM has been configured, you are ready to enable the data services. However, you may notice that there are no data services visible in the Version and Upgrade > Data Services view.

This is resolved by simply doing a check for upgrade which will discover the database images. Navigate back to Version & Upgrade, and under the DSM System view, click on the “Check for Upgrade” button. This should then allow DSM to discover the Data services and populate the view above.

Data Services Preview

Once the Data Services are visible, they need to be enabled. One final new feature to bring to your attention is the fact that when a Data Service is enabled, it can be enabled in “Preview” mode. This Preview mode means that the Data Service in question will not have DSM’s automated lifecycle management functionality associated with it. Instead, administrators will have to manually patch this services should a new update become available.

Once the data services has been enabled, it can now be used to create data services such as PostgreSQL databases or MySQL databases.

Summary

You can now begin to leverage some of the great features of Data Services Manager, such as automated backups, automated patching and updates, database cloning, database scaling, and LDAPS access to databases. As well as this, DSM has integrations with the Aria stack, including Aria Automation, Aria Operations and Aria Operations for Logs. DSM version 2.1 also integrates with the Cloud Consumption Interface (CCI), with a new Supervisor Service now available for DSM to allow for the provisioning of databases through Aria Automation and CCI. Finally this release includes vCloud Director integration through the new VMware Cloud Director extension for Data Solutions 1.5 (commonly referred to as DSE). This should be of special interest to our Cloud Service Providers (CSPs). Thanks for reading this far, and watch this space for further posts relating to the new features in DSM version 2.1.