En driftrelease snarare än en funktionslista
VMware Data Services Manager 9.1.1 är tillgänglig sedan den 15 september 2026. Releasen för samman databaslivscykel, hög tillgänglighet, identitet och kryptering när PostgreSQL, MySQL och Microsoft SQL Server körs som tjänster på VMware Cloud Foundation.
Den praktiska förändringen är att flera moment som normalt hamnar mellan plattforms-, databas- och säkerhetsteam flyttas in i samma styrmodell. Det gäller bland annat versionsuppgraderingar, behovsstyrda säkerhetskopior, Active Directory-konton och isolering mellan tenants.
Broadcom beskriver 9.1.1 som mer än en korrigeringsrelease. LabOps IT:s bedömning är att den framför allt bör behandlas som en driftrelease: värdet uppstår först när de nya kontrollerna kopplas till organisationens egna ändringsfönster, återställningsmål och ansvarsfördelning.
Tre databasmotorer får utökad livscykelhantering
Den officiella lanseringen anger stöd för PostgreSQL 18, automatiserade större och mindre versionsuppgraderingar för MySQL samt SQL Server 2025 med stöd för kumulativa uppdateringar. API-styrda säkerhetskopior på begäran kompletterar det löpande underhållet. Broadcoms lansering av DSM 9.1.1 beskriver funktionerna.
Detta innebär inte att en uppgradering blir riskfri. Applikationskompatibilitet, tillägg, databasscheman, drivrutiner och beroenden behöver fortfarande provas mot målversionen. Automatiseringen minskar antalet manuella steg men ersätter inte ett godkännande från den som äger applikationen.
Införande bör därför börja med en versionsmatris. Lista databasversion, operativsystem, klientdrivrutin, tillägg och beroende applikation för varje tjänst. Lägg till tydliga kriterier för att fortsätta, pausa eller återställa när DSM genomför en uppgradering.
PostgreSQL 18-stödet är relevant för nya miljöer och planerad modernisering, men är inte i sig ett skäl att flytta alla instanser omedelbart. För MySQL blir den viktigaste kontrollen hur större versionssteg påverkar applikationer och repliker. För SQL Server bör kumulativa uppdateringar samordnas med Windows-underhåll och verksamhetens ordinarie patchprocess.
DSM blir en del av VCF:s egen livscykel
I 9.1.1 levereras Data Services Manager som en inbyggd VCF-tjänst. Broadcom anger att driftsättning, konfiguration, uppgraderingar, återställning och rollback hanteras inom VCF-modellen. Releasen stöder även VMware vSphere Kubernetes Service 3.7 och Kubernetes över flera kluster.
För plattformsteamet kan detta minska antalet separata konsoler och specialbyggda integrationsflöden. Samtidigt skapas ett tätare beroende mellan databasplattformens livscykel och den underliggande VCF-miljön. Förändringar måste därför provas som en sammanhängande kedja, inte som isolerade produktuppdateringar.
Dokumentera vilka komponenter som uppgraderas av VCF, vilka databasartefakter som förvaltas av DSM och vilka delar som fortfarande ägs av DBA- eller applikationsteamet. En enkel RACI-matris kan förhindra att en automatiserad åtgärd blir utan tydlig beställare eller mottagare.
Den tidigare DSM 9.1-releasen gjorde SQL Server till en produktionsklar databasmotor vid sidan av PostgreSQL och MySQL. Den gav bland annat policybaserad provisionering, Windows-autentisering och stöd för Always On-konfigurationer. Översikten över DSM 9.1 ger bakgrunden. Uppgifterna om tids- och kostnadsbesparing där är leverantörspåståenden och bör inte användas som egna kalkylvärden utan lokala mätningar.
Hög tillgänglighet flyttas över klustergränsen
DSM 9.1.1 introducerar enligt lanseringen Supervisor cross-cluster high availability. Avsikten är att en databastjänst inte ska falla med ett enskilt värdkluster. Samtidigt kan en global metrics target samla signaler om databas- och värdhälsa för en gemensam vy.
Detta är relevant för incidenthantering, eftersom ett prestandaproblem ofta kräver korrelation mellan frågelast, databasresurser och underliggande infrastruktur. En gemensam mätpunkt kan korta felsökningen, men bara om larm, ägarskap och tidsstämplar är konsekventa.
Cross-cluster HA måste också provas med verkliga fel. Stäng av en kontrollerad resurs, mät det faktiska avbrottet och verifiera att klienterna återansluter. Kontrollera därefter att övervakningen visar både orsaken och följdeffekten. Ett grönt kontrollplan är inte samma sak som att applikationen åter levererar tjänst.
Testet bör omfatta beroenden som DNS, lastbalansering, certifikat, identitet och lagring. Om någon av dessa endast finns i ett kluster kan databasens flyttbarhet ge en falsk bild av hela tjänstens motståndskraft. Dokumentera dessutom hur kapacitet reserveras så att det mottagande klustret klarar belastningen under ett fel.
Tenant-isolering och Active Directory kräver ny kontroll
Säkerhetsdelen innehåller tre tydliga nyheter: nätverksisolering mellan tenants, automatisk hantering av Active Directory-konton för SQL Server samt inbyggd kryptering av SQL Server-säkerhetskopior. Via API kan backupkryptering aktiveras för samtliga databaser i ett SQL Server-kluster.
Broadcom anger också att certifikat kan importeras via API för att manuellt aktivera Transparent Data Encryption, TDE, på enskilda databaser med T-SQL. Det är viktigt att skilja detta från säkerhetskopiekrypteringen: de skyddar olika delar av datalivscykeln och använder inte nödvändigtvis samma nyckelprocess.
Tenant-isolering bör verifieras som en uttrycklig nekandepolicy. Testa trafik både mellan tenants och mot gemensamma tjänster som katalog, DNS, loggning och backup. Dokumentera tillåtna flöden så att ett framtida undantag inte öppnar en bredare väg än avsett.
För automatiserade AD-konton behöver organisationen bestämma namngivning, ägarskap, rotation, avveckling och granskning. Automatisering minskar handpåläggningen, men ett konto utan tydlig livscykel blir fortfarande en säkerhetsrisk. Koppla därför DSM:s skapande och borttagning till befintlig identitetsstyrning.
Krypterad backup är inte samma sak som verifierad återställning
Inbyggd SQL Server-backupkryptering är en viktig kontroll för data i vila och för kopior som lämnar den primära miljön. Men kryptering kan samtidigt göra återställningen beroende av certifikat och nycklar som inte finns i själva backupfilen.
Skapa därför ett återställningstest där både data och nödvändigt nyckelmaterial hämtas från den dokumenterade katastrofvägen. Testet ska genomföras till en isolerad målmiljö och bekräfta att databasen går att öppna, att applikationsidentiteten fungerar och att återställningstiden ryms inom verksamhetens mål.
Den tekniska genomgången av SQL Server i DSM 9.1 visar hur plattformen skiljer på instans, användardatabaser och den underliggande infrastrukturen. Den beskriver också SQL Server Agent, övervakning samt integration med bekanta verktyg som SSMS, PowerShell och SQLCMD. Broadcoms SQL Server-genomgång är användbar bakgrund till vilka arbetsflöden som nu byggs ut.
Backup-API:t bör integreras med organisationens katalog över återställningspunkter och retention. Ett lyckat API-anrop är inte tillräckligt bevis för återställningsbarhet. Följ upp med periodiska prov, kontroll av lagringsmål och larm när en förväntad kopia saknas.
Rekommenderad införandeordning
Börja med inventering och beroenden, inte med massuppgradering. Välj en icke-kritisk tjänst från varje relevant databasmotor och dokumentera nulägets manuella arbete, felrisk och återställningstid.
Genomför sedan fyra separata prov: versionsuppgradering med rollback, behovsstyrd backup med isolerad återställning, klusterfel med klientåteranslutning och tenant-test där förbjuden trafik verkligen blockeras. För SQL Server tillkommer kontroll av AD-kontots fulla livscykel och förvaring av krypteringsmaterial.
Efter piloten kan plattformsteamet jämföra utfall i stället för marknadsförda besparingar. Mät arbetstid, avbrott, återställningstid, antal manuella undantag och hur snabbt ett larm kan kopplas till rätt lager. Dessa mått avgör om automatiseringen faktiskt förenklar driften.
Inför inte samtidigt nya databasversioner, ny HA-topologi och ny identitetsmodell i en kritisk tjänst. Även om DSM samlar funktionerna bör förändringarna sekvenseras så att varje fel kan isoleras och återställas.
LabOps IT:s bedömning
DSM 9.1.1 är betydelsefull för organisationer som redan använder eller seriöst utvärderar VCF som plattform för privata databastjänster. Releasevärdet ligger mindre i ännu en självbetjäningsportal och mer i att underhåll, resiliens och säkerhetskontroller förs närmare plattformens ordinarie livscykel.
Den starkaste förbättringen är kombinationen av klusteröverskridande HA, versionsautomation och tydligare SQL Server-kontroller. Den största risken är att organisationen tolkar automatisering som att ansvar och verifiering försvinner. Tvärtom blir beroendekedjan bredare och behöver testas hela vägen från VCF till applikation.
Vår rekommendation är planerad prioritet: inventera nu, bygg en avgränsad pilot och acceptera först därefter funktionerna i produktion. Säkerhetskopiekryptering och tenant-isolering är värda tidig verifiering, men bör inte beskrivas som färdiga skydd förrän återställning och nekad trafik har bevisats.