Simplified Installation
The most noticeable change in Data Services Manager version 2.1 is the installation experience. The number of deployment steps have been considerably reduced by including the database templates in the DSM appliance itself. This means that there is now no need to pull down the database images manually, nor is there a need to upload the images manually to an S3 compatible object storage bucket. With these database templates included in the DSM appliance, we don’t even need the Provider Repo bucket which was a requirement in previous versions of DSM. Now when the DSM 2.1 client plugin and appliance are deployed, the data services can be immediately enabled and databases can be deployed in a very short time indeed.
Improved visibility for the VI Admin
DSM 2.x always considers the role of the VI Admin. As well as being able to guard-rail resources consumed by databases and data services through the use of Infrastructure Polices, DSM is designed to give VI Admins insight into how their vSphere resources are consumed. The vSphere Client has been extended in DSM v2.1 to give more details about the DSM provisioned databases consuming those resources, as well as raising alerts should something go wrong. The screenshot below is showing the overall status of the database:
Additional details, such as which database role is running on which VM, as well as detail resource metrics, are also now displayed in the vSphere Client. This level of detail enables VI Admins and Data Admins to have meaningful conversations around database resource consumption and troubleshooting.
MySQL Clustering
I am also delighted to say that our engineering team have pulled out all the stops, and delivered an enterprise-ready clustering solution for MySQL. This was a pain-staking effort, but very worthwhile as we now have what we believe to be a very robust solution for MySQL clustering. The standalone, single node MySQL database is still supported but in Data Services Manager version 2.1, a three node database can also be provisioned with a primary and two replicas. PostgreSQL continue to be available with both standalone and clustering topologies.
Certificate Management
Today, security is top of mind for our customers. In Data Services Manager version 2.1, we have spent a considerable amount of time and resources implementing secure communication both between internal DSM components, and between DSM and external systems. Through a new Trusted Root Certificates mechanism, administrators can secure communication to external systems such as vCenter, S3 Object Store, LDAP server, and even Aria Operations for Logs (formerly Log Insight). This is achieved by adding the Certificate Authority (CA) from these systems to DSM’s Trusted Root Certificates, as shown below:
Now when S3 buckets are added to DSM for backups, when logs are shipped to Aria Operations for Logs, or LDAPS is configured for user access, the communication between DSM and these other systems is secure. It goes without saying that it is also possible to secure communication between clients and the DSM provisioned databases. Each of the databases provisioned by DSM has a secret, which contains both the password to the database and a Certificate Authority (CA). With the appropriate permissions, the DSM gateway API can be used to retrieve the CA, which in turn can be used to establish secure SSL/TLS connectivity to the database.
% kubectl get secrets --kubeconfig kubeconfig-gateway.yaml NAME CREATED AT mysql-mysql01 2024-07-22T16:00:49Z pg-pg01 2024-07-22T09:46:21Z
One final note on certificates. It is also possible for administrators to add their own custom externally signed Certificate Authority to the DSM. This can be done for both the DSM (Provider) appliance VM as well as the databases. This is also done through DSM gateway API and is detailed in the official v2.1 documentation (link at bottom of post).
LDAPS Support for Database Access
In previous release, DSM support secure LDAP access for the DSM admins and users. In Data Services Manager version 2.1, LDAPS support has been extended to the databases. Both OpenLDAP and Active Directory are supported. LDAPS is configured via Directory Services in the DSM Settings page. When databases are created with Directory Services enabled, it is now possible to enable secure LDAP access to the database at provisioning time.
It is also possible to enable LDAPS on a database after the database has been provisioned.
Now you can have full control over which users are allowed access to which databases. A few simple SQL commands on the database determines who can login to the database, and what permission these users have. This is something that many of our customers have been requesting, so it is great to now deliver on this for them.
Improved Aria Operations for Logs integration
While we had log shipping support in previous versions of DSM, Data Services Manager version 2.1 adds some major improvements here. In particular, I wanted to highlight the fact that we now have support for the Aria Operations for Logs cfAPI protocol, meaning that log filtering and dashboard building becomes much easier with this version of DSM. All components of DSM now have their own tag as well. Here is a sample dashboard that I built very quickly where two different DSM systems were shipping their logs to the same Aria Operations for Logs system.
Integration with Cloud Consumption Interface (CCI)
The Cloud Consumption Interface allows administrators to manage multiple vSphere Iaas Control Planes (formerly vSphere with Tanzu) Supervisors via Aria Automation, typically to provision TKG clusters and/or Pod VM. It can also be used to provisioned what are known as Supervisor Services. Data Services Manager version 2.1 now also integrates as a Supervisor Service and allow users of Aria Automation/CCI to provision and manage PostgreSQL databases. The request is made via Aria Automation/CCI to the Supervisor Cluster DSM Service, and from there the request is sent to DSM via the Consumption Operator which is installed as a Supervisor Service. I have a series of blog posts on this topic starting here if you are interested in learning more about it.
Integration with vCloud Director
This is something that should appeal to our Cloud Service Providers. Data Services Manager version 2.1 now integrates seamlessly with VMware Cloud Director extension for Data Solutions 1.5 (commonly referred to as DSE). This allows vCloud Director users to provision DSM-based databases effortlessly through a a simple tenant-facing self-service UI. Check out the DSE 1.5 Release Notes for more information about this integration.
Summary
I hope that this blog post conveys the new features and functionality of Data Services Manager version 2.1. This is not a complete list of all the improvements and enhancements, but covers most of the major items. If you want to learn more about the v2.1 release, check out these links to the Release Notes and Product Documentation. Over the coming days and weeks, I will delve into some of these topics in greater details. Check back regularly for more updates and detailed descriptions of DSM v2.1 features snd functionality. Thanks for reading this far.