VMware Data Services Manager 9.1.1 aggiorna il modo in cui PostgreSQL, MySQL e Microsoft SQL Server vengono gestiti all’interno di VMware Cloud Foundation. La novità non è semplicemente l’aggiunta di nuove versioni dei motori: il rilascio punta a ridurre il lavoro manuale su aggiornamenti, backup, continuità operativa, identità e isolamento tra tenant.
Per un’azienda che mantiene database nel proprio private cloud, il punto da valutare è concreto: DSM 9.1.1 può rendere più ripetibili alcune attività critiche, ma non elimina la necessità di progettare correttamente capacità, recovery, segregazione delle reti e responsabilità operative. Vediamo cosa cambia e quali verifiche conviene fare prima dell’adozione.
Che cos’è VMware Data Services Manager 9.1.1
VMware Data Services Manager, spesso abbreviato in DSM, è il servizio con cui VMware Cloud Foundation gestisce database relazionali come servizio. Consente ai team applicativi di richiedere istanze database attraverso procedure standardizzate, mentre infrastruttura e sicurezza mantengono il controllo su immagini, policy, reti, aggiornamenti e protezione dei dati.
La versione 9.1.1, annunciata il 15 settembre 2026 e indicata come disponibile, estende il modello introdotto con DSM 9.1. Broadcom sottolinea che PostgreSQL, MySQL e SQL Server sono tutti gestibili come servizi di produzione su VMware Cloud Foundation. Il rilascio si concentra soprattutto sul “day 2”: mantenere i database aggiornati, disponibili e protetti mentre il numero di istanze cresce.
Questo orientamento distingue DSM da una semplice appliance per installare database. L’obiettivo è costruire una piattaforma operativa comune, utile quando più applicazioni e più gruppi devono condividere la stessa infrastruttura senza moltiplicare procedure e console.
Le novità principali per PostgreSQL, MySQL e SQL Server
PostgreSQL 18 e lifecycle più uniforme
DSM 9.1.1 aggiunge il supporto a PostgreSQL 18. Per chi usa PostgreSQL nel private cloud, la disponibilità di una versione recente dentro il catalogo gestito riduce il rischio di creare installazioni fuori standard solo per soddisfare un requisito applicativo. Il beneficio, però, dipende dalla qualità del processo di validazione: estensioni, driver, procedure di replica e strumenti di monitoraggio devono essere testati prima di promuovere una nuova versione nel catalogo aziendale.
Aggiornamenti automatizzati per MySQL
Per MySQL arrivano aggiornamenti automatici sia major sia minor. È una funzione importante perché riduce attività manuali ripetitive, ma non trasforma un major upgrade in un’operazione priva di rischio. Cambiamenti del motore, compatibilità SQL, charset, plugin e comportamento dell’optimizer possono incidere sulle applicazioni. In produzione conviene quindi mantenere ambienti di pre-produzione rappresentativi, finestre di manutenzione definite e criteri di rollback verificati.
SQL Server 2025 e cumulative update
La release introduce il supporto a Microsoft SQL Server 2025 e ai relativi cumulative update. DSM 9.1.1 aggiunge inoltre automazione per gli account Active Directory usati da SQL Server, cifratura nativa dei backup e possibilità di abilitare la Transparent Data Encryption importando certificati e intervenendo tramite T-SQL quando necessario.
Per le imprese con infrastruttura Microsoft, l’integrazione dell’identità riduce il rischio di account creati e gestiti in modo incoerente. Restano comunque essenziali la separazione dei ruoli, la rotazione delle credenziali e la protezione del materiale crittografico: un backup cifrato è utile solo se chiavi e certificati hanno un ciclo di vita documentato e recuperabile.
Backup on demand e aggiornamenti: cosa cambia davvero
DSM 9.1.1 introduce backup on demand pilotabili via API. Questo consente di collegare la protezione del database a pipeline applicative, procedure di change management o automazioni prima di un aggiornamento. Per esempio, una pipeline può richiedere un backup verificato prima di distribuire una nuova versione dell’applicazione o applicare una modifica allo schema.
Automatizzare la richiesta non equivale però a validare il ripristino. La checklist minima dovrebbe includere:
- obiettivi RPO e RTO approvati dal proprietario del servizio;
- test periodici di restore in un ambiente isolato;
- verifica di consistenza applicativa, non soltanto dell’avvio del motore;
- monitoraggio degli esiti e allarmi sui backup falliti;
- separazione tra credenziali amministrative, backup e accesso applicativo;
- retention coerente con obblighi contrattuali e normativi.
Lo stesso principio vale per gli upgrade. L’orchestrazione diminuisce la possibilità di errore umano e rende il processo ripetibile, ma l’azienda deve stabilire chi autorizza l’operazione, quali test devono risultare superati e quanto a lungo conservare il punto di ritorno.
Alta disponibilità tra cluster e osservabilità centralizzata
Tra le novità più rilevanti c’è la Supervisor cross-cluster high availability. In pratica, i servizi database possono essere progettati per resistere al guasto di un singolo cluster host. Per infrastrutture che ospitano applicazioni critiche, questo amplia il dominio di resilienza rispetto a una configurazione concentrata in un unico cluster.
La funzione non va confusa con una strategia completa di disaster recovery. L’alta disponibilità tra cluster protegge da determinate classi di guasto, mentre un incidente di sito, un errore logico, un attacco o la cancellazione di dati richiedono backup indipendenti, replica adeguata e procedure di ripristino. È lo stesso principio che vale nella protezione degli ambienti virtualizzati, già discusso nell’articolo su backup delle VM OpenShift con Veeam.
DSM 9.1.1 introduce inoltre l’integrazione con un target globale per le metriche. L’obiettivo è correlare salute dei database e condizioni dell’infrastruttura in una vista comune. In caso di rallentamenti, gli operatori possono distinguere più rapidamente tra saturazione del database, problemi di storage, pressione su CPU e memoria o anomalie del cluster.
DSM diventa un servizio nativo di VMware Cloud Foundation
Con la nuova versione, Data Services Manager viene gestito come servizio nativo di VMware Cloud Foundation. Deployment, configurazione, aggiornamenti, rollback e recovery entrano quindi nel modello operativo di VCF, invece di dipendere da un componente separato.
La release supporta anche VMware vSphere Kubernetes Service 3.7 e scenari Kubernetes multi-cluster. L’astrazione è utile perché consente ai team database di usare una piattaforma moderna senza dover amministrare direttamente ogni dettaglio di Kubernetes. Per il reparto IT significa però definire bene il confine tra responsabilità del team VCF, amministratori dei database, sicurezza e proprietari applicativi.
Le aziende che stanno valutando alternative alla virtualizzazione tradizionale possono confrontare questo approccio con le opzioni descritte nell’analisi su Lenovo ThinkAgile VX850 V4. DSM non sostituisce la scelta dell’infrastruttura: aggiunge un livello di servizio sopra VCF, con vantaggi maggiori quando esiste già una standardizzazione della piattaforma.
Sicurezza multi-tenant, rete e identità
DSM 9.1.1 rafforza l’isolamento di rete tra tenant. È un aspetto essenziale quando più business unit, clienti interni o ambienti applicativi condividono la stessa piattaforma. La separazione riduce il rischio che un servizio possa raggiungere dati o endpoint appartenenti a un altro tenant.
La sicurezza effettiva dipende comunque dalla configurazione complessiva. Prima del go-live è opportuno verificare:
- segmentazione tra management, traffico database, backup e monitoraggio;
- regole east-west e flussi realmente necessari;
- integrazione con Active Directory e gruppi amministrativi;
- gestione di certificati e chiavi per TDE e backup cifrati;
- logging centralizzato delle operazioni privilegiate;
- scansione delle configurazioni e revisione periodica degli accessi.
Per comprendere come rete fisica e private cloud possano essere governati con un piano comune, è utile anche l’approfondimento su Cisco Nexus One e l’unificazione della rete nel private cloud.
Quando VMware Data Services Manager 9.1.1 ha senso
DSM 9.1.1 è particolarmente interessante per organizzazioni che hanno già adottato VMware Cloud Foundation e devono offrire database standardizzati a più team. Il valore cresce quando il numero di istanze rende costose le procedure manuali, quando servono controlli coerenti tra reparti o quando la localizzazione dei dati rende preferibile il private cloud.
È meno immediato il beneficio per chi gestisce pochi database stabili, non dispone di competenze VCF o ha già standardizzato completamente su servizi database pubblici. In questi casi bisogna confrontare licenze, infrastruttura, personale, supporto e costi di esercizio con le alternative. Per workload molto esigenti resta inoltre fondamentale dimensionare correttamente memoria, storage e rete: il tema è approfondito nell’articolo sulle VM Google Cloud M4N per database ad alte prestazioni.
Checklist per valutare l’adozione
- Censire i motori: versioni, estensioni, dipendenze, driver e criticità delle applicazioni.
- Definire i livelli di servizio: RPO, RTO, finestre di manutenzione e responsabilità.
- Verificare la compatibilità: VCF, VKS, hardware, storage, rete e sistemi operativi guest.
- Progettare i tenant: confini organizzativi, segmentazione, quote e modello di autorizzazione.
- Provare upgrade e rollback: prima su copie realistiche, includendo test applicativi.
- Testare il restore: non limitarsi all’esito positivo del job di backup.
- Integrare le metriche: definire dashboard, soglie, escalation e ownership degli alert.
- Proteggere chiavi e certificati: documentare custodia, rotazione e recupero.
- Misurare il costo: confrontare TCO della piattaforma con gestione tradizionale e DBaaS pubblico.
Domande frequenti su VMware Data Services Manager 9.1.1
DSM 9.1.1 è già disponibile?
Sì. Nell’annuncio ufficiale del 15 settembre 2026 Broadcom indica VMware Data Services Manager 9.1.1 come disponibile.
Quali database gestisce?
La piattaforma copre PostgreSQL, MySQL e Microsoft SQL Server. La versione 9.1.1 aggiunge, tra l’altro, PostgreSQL 18 e SQL Server 2025.
Gli aggiornamenti automatici eliminano il downtime?
No. L’automazione riduce le attività manuali e può limitare il rischio operativo, ma compatibilità, finestra di manutenzione e continuità devono essere valutate per ogni servizio.
L’alta disponibilità tra cluster sostituisce il disaster recovery?
No. Protegge da specifici guasti del cluster, mentre disaster recovery e cyber recovery richiedono copie indipendenti, procedure di ripristino e test periodici.
È una soluzione adatta alle PMI?
Può esserlo se l’impresa utilizza già VCF, gestisce più database critici o deve mantenere i dati on-premises. Per ambienti piccoli va verificato che il beneficio operativo compensi complessità e costi della piattaforma.
Conclusioni
VMware Data Services Manager 9.1.1 rende più maturo il modello Database-as-a-Service dentro VMware Cloud Foundation. Supporto alle nuove versioni, backup via API, aggiornamenti automatizzati, alta disponibilità tra cluster, osservabilità centralizzata e controlli multi-tenant affrontano problemi reali del day 2.
La scelta non dovrebbe però partire dall’elenco delle funzioni. Conviene partire dai servizi applicativi, dai livelli di continuità richiesti e dalle competenze disponibili. Un progetto pilota con un database non critico, metriche definite e un restore completo è il modo più concreto per capire se l’automazione promessa si traduce in meno rischio e meno lavoro operativo.
Fonti ufficiali
- VMware Cloud Foundation Blog: Announcing VMware Data Services Manager 9.1.1, 15 settembre 2026.
- VMware Cloud Foundation Blog: disponibilità generale di VCF 9.1.1, 3 settembre 2026.