I have been using Aria Operations and True Visibility Management Packs quite a bit recently. This is mostly to get visibility into databases that are being provisioned by VMware Data Services Manager (DSM). I just learnt that we released a bunch of new Management Packs (v9.1) only last week, including updated Management Packs for both PostgreSQL and MySQL. In this post, I will deploy a new PostgreSQL database via Data Services Manager (DSM) 2.0, add the necessary database configuration options and extensions, and then add the database to Aria Operations True Visibility for PostgreSQL databases for monitoring. You might ask…
This video will show the power of the Gateway API in Data Services Manager (DSM) 2.0. The Gateway API is a Kubernetes API for the creation, modification, query and deletion of DSM objects. There are two personas related to the Gateway API, the infrastructure admin and the DSM admin/user. The video shows how to retrieve the Kubernetes configuration file (kubeconfig) for each of the personas. It also shows how to use the gateway API to create infrastructure components such as an IP Pool, a VM Class and an Infrastructure Policy. The gateway API is a great tool for those administrators…
I have created a new video showing how to create an PostgreSQL database in Data Services Manager (DSM) version 2.0. The objective is to show how simple it is to not only deploy a database, but also how the provisioning steps allows different vSphere infrastructure resources to be selected during the provisioning stage. This is achieved through Infrastructure Policies which we learnt about in the previous video. The demo also touches on features such as automated backups, automated lifecycle management and advanced settings, all of which may be configured at database deployment time.
In previous posts, a number of benefits of Data Services Manager (DSM) were highlighted. Features such as automated backups, ease of scaling, as well as comprehensive monitoring and alerting were highlighted. Another feature which is a big differentiator in DSM is lifecycle management. In this post, I am going to show the steps in upgrading the DSM appliance/provider, essentially the DSM control plane, when a new update is available. Of course, there is also a plan for lifecycle management on the databases and data services, but that will be a topic for another post. In this post, I will take…
I have created a new video showing how to create an Infrastructure Policy in Data Services Manager (DSM) version 2.0. Infrastructure Policies enable VI Admins to control which vSphere resources are being consumed by data services and databases provisioned by DSM. The video will also cover how to build an IP Pool and a VM Class, as well as choosing Compute Resources, Portgroups and Storage Policies to create a complete Infrastructure Policy.
A common question I get asked when giving talks on Data Service Manager (DSM) version 2.0 is “what happens to the databases and data services when the DSM appliance / provider has an outage?” The simple answer is that nothing happens to your data services or databases – they will continue to run as before. Of course, without the DSM appliance, you do not have access to the UI to manage and monitor the databases, nor do you have access to the gateway API. Therefore it won’t be possible to provision new data services. So the next obvious question is…
One of the guiding goals for Data Services Manager (DSM) 2.0 is to provide a very rich Kubernetes compliant API server for end-users and developers. We refer to this as the Gateway API. In this post, I will demonstrate the Gateway API server’s capabilities and show how it can be used to query the state of the objects that are provisioned through DSM, and also how to modify and manipulate these objects. The kubectl command line interface is used. We will use this tool to query and modify some of the infrastructure components, as well as query the existing data…