Il problema: quote regionali condivise e capacity planning complicatoChi gestisce ambienti Azure SQL Managed Instance (MI) su larga scala conosce bene un problema che, fino a pochi giorni fa, complicava ogni fase di dimensionamento: le quote regionali di subnet. Ogni Managed Instance deve risiedere in una subnet dedicata e delegata al servizio, e fino ad oggi il numero massimo di vCore utilizzabili in quella subnet era vincolato a una quota unica per regione e sottoscrizione, condivisa indistintamente tra tutte le generazioni hardware disponibili (Standard-series, Premium-series e Premium-series Memory Optimized).

In pratica, se un team aveva già saturato la quota regionale con istanze su hardware Standard-series, non poteva provisionare una nuova istanza Premium-series nella stessa regione senza prima aprire una richiesta di supporto per l’aumento della quota, anche se la subnet stessa aveva ancora #spazio IP disponibile. Un vincolo “trasversale” che poco aveva a che fare con la reale capacità di rete e molto con una limitazione amministrativa lato piattaforma, particolarmente dolorosa per chi gestisce deployment multi-tenant, ambienti di disaster recovery con failover group, o strategie di aggiornamento side-by-side che richiedono temporaneamente il doppio delle risorse.

Cosa cambia: quote per generazione hardware, non più una quota unicaMicrosoft ha annunciato il passaggio a un modello di limiti semplificati e granulari: la quota regionale condivisa viene sostituita da quote indipendenti per ciascuna famiglia hardware. In altre parole, i vCore disponibili per Standard-series, quelli per Premium-series e quelli per Premium-series Memory Optimized vengono ora contabilizzati separatamente, e i deployment sono governati dai normali limiti di rete virtuale di #Azure Resource Manager (ARM) piuttosto che da un vincolo specifico del servizio #SQL MI.

Il cambiamento si applica sia ai deployment single-zone sia a quelli zone-redundant, e riguarda tutte le subnet delegate a Microsoft.Sql/managedInstances. Per i clienti esistenti la transizione è trasparente: le quote regionali di vCore attualmente in uso vengono convertite automaticamente nel nuovo modello per-hardware, senza necessità di riconfigurare le istanze già in esercizio.

Perché è rilevante per chi fa capacity planningRichieste di quota più mirate: se serve solo più capacità Premium-series Memory Optimized, non è più necessario negoziare un aumento che finirebbe per “gonfiare” anche lo spazio per le altre famiglie hardware.

Pianificazione degli upgrade side-by-side più semplice: le operazioni che richiedono capacità aggiuntiva temporanea (ad esempio il passaggio da hardware Gen5 legacy a Standard-series) impattano ora solo la quota della famiglia hardware coinvolta.

Meno attrito nei deployment multi-team: in sottoscrizioni condivise tra più team o applicazioni, un consumo intensivo di una famiglia hardware non blocca più il provisioning su un’altra famiglia nella stessa regione.

Cosa resta invariato: il dimensionamento della subnetÈ importante non confondere questo cambiamento con un allentamento dei requisiti di rete: la subnet dedicata a Managed Instance deve continuare a rispettare i vincoli storici del servizio. Microsoft continua a raccomandare un blocco CIDR di almeno /27 (32 indirizzi) per garantire margine sufficiente a operazioni di manutenzione, failover e scaling, con /28 come limite minimo assoluto per ambienti realmente contenuti. Restano inoltre valide le regole che vietano di condividere la subnet con altre risorse non delegate e che richiedono una tabella di route e un gruppo di sicurezza di rete (NSG) dedicati e configurati secondo i requisiti del servizio.

Per chi deve verificare lo stato attuale delle quote, il percorso resta quello consueto tramite portale Azure, sotto Subscriptions > Usage + quotas filtrando per il provider Microsoft.Sql, oppure via Azure CLI:

az sql instance-pool list-usage --location "westeurope"

oppure, per verificare i limiti di risorsa applicabili a una specifica instance pool

az sql instance-pool show --name mypool --resource-group myRGLe richieste di aumento quota, quando necessarie, si effettuano ancora tramite una richiesta di supporto dedicata dal portale Azure, specificando ora la famiglia hardware interessata anziché una generica richiesta regionale.

Considerazioni pratiche per l’infrastrutturaPer chi sta pianificando una migrazione verso Managed Instance, o un ampliamento di un ambiente esistente, questo è un buon momento per rivedere la topologia di rete. Alcuni suggerimenti operativi:

Documentate quale famiglia hardware #usa ciascuna istanza nel vostro inventario CMDB o nei tag delle risorse: con quote separate, sapere “chi consuma cosa” diventa più rilevante per prevedere colli di bottiglia futuri.

Rivedete le pipeline di provisioning IaC (Bicep, #Terraform, ARM template): se avevate logica custom per gestire manualmente errori di quota condivisa, potete probabilmente semplificarla.

Pianificate in anticipo gli upgrade di generazione hardware: sapere che la quota Premium-series è indipendente da quella Standard-series consente di programmare finestre di migrazione senza il rischio che un’altra applicazione “consumi” involontariamente la capacità necessaria.

Verificate i failover group cross-region: assicuratevi che anche nella regione secondaria la quota per la famiglia hardware utilizzata sia sufficiente, dato che il DR richiede risorse equivalenti a quelle primarie.

ConclusioneSi tratta di una modifica infrastrutturale che non introduce nuove funzionalità visibili agli sviluppatori, ma che rimuove un attrito operativo reale per chi amministra ambienti Azure SQL Managed Instance su larga scala. Il passaggio da una quota condivisa a quote per hardware allinea meglio la governance delle risorse SQL a quella già in uso per il resto della rete virtuale, riduce le richieste di supporto necessarie per operazioni di routine e semplifica la pianificazione di capacity planning e upgrade. Per i team che gestiscono più applicazioni con esigenze hardware eterogenee nella stessa sottoscrizione, il beneficio pratico si vedrà già alla prossima richiesta di provisioning.

Fonte: Petri IT Knowledgebase – Azure SQL Managed Instance Removes a Capacity Planning Hurdle for Large Deployments

Chi gestisce ambienti SQL Server on-premises conosce bene il problema: la migrazione verso il cloud richiede quasi sempre di mettere insieme tool diversi per la valutazione, il trasferimento dei dati, il monitoraggio e infine il cutover. Ogni fase ha strumenti propri, competenze diverse e margini di errore che si sommano. Con l’annuncio della disponibilità generale (GA) della migrazione a SQL Server su macchine virtuali Azure tramite Azure Arc, Microsoft porta l’intero ciclo di vita della migrazione dentro un’unica esperienza guidata nel portale Azure, lo stesso modello già usato per le migrazioni verso Azure SQL Managed Instance.

Per chi amministra data center misti, con carichi legacy e SQL Server sparsi su fisico e virtuale, questa novità merita attenzione: non è solo un annuncio di marketing, ma un cambio concreto di flusso di lavoro operativo.

Cos’è cambiato con la GAFino a poco tempo fa, chi voleva spostare un’istanza SQL Server su una VM Azure doveva combinare Azure Migrate, Database Migration Service e strumenti di backup/restore manuali, gestendo ciascuno con logiche e dashboard separate. Con la funzionalità di migrazione integrata in Azure Arc, il processo si consolida in quattro fasi accessibili da un singolo pannello, il Database Migration, associato all’istanza SQL Server abilitata da Arc:

Assess source instance — valutazione di leggibilità e readiness dell’istanza sorgente

Select target — scelta o creazione della VM SQL Server di destinazione

Migrate data — trasferimento effettivo dei database

Monitor and cutover — monitoraggio della sincronizzazione e passaggio finale in produzione

La discovery delle istanze e la generazione dei report di readiness avvengono automaticamente ogni fine settimana, ma possono essere lanciate anche manualmente, senza configurazioni aggiuntive: la funzione è disponibile di default per tutte le istanze SQL Server abilitate da Arc a partire da SQL Server 2012 (11.x).

Copilot integrato nel flusso di migrazioneUna parte interessante della nuova esperienza è l’integrazione di Microsoft Copilot direttamente nel pannello di migrazione. Non si tratta di un chatbot generico: interroga la knowledge base Microsoft nel contesto specifico della vostra migrazione e risponde a richieste operative come:

Come vengono eseguite le valutazioni?
Aiutami a confrontare le opzioni di destinazione
Avvia la migrazione
Aiutami a scegliere il metodo di migrazione corretto
Monitora la migrazione in corso
Completa la migrazionePer un DBA che gestisce decine di istanze, questo significa poter chiedere direttamente nel pannello “quale VM SKU è consigliata per questo carico?” invece di andare a cercare tabelle di sizing nella documentazione.

Come funziona la migrazione via backup e restoreIl meccanismo sotto il cofano non è nuovo per chi ha familiarità con le migrazioni SQL Server classiche: si basa su backup e restore con log shipping continuo, pensato per supportare scenari di migrazione online con downtime minimo.

Viene eseguito un backup completo del database sorgente

Il backup viene caricato su un account di Azure Blob Storage intermedio

Il backup viene ripristinato sull’istanza SQL Server target sulla VM Azure

I backup dei log delle transazioni vengono caricati in continuo sullo stesso storage e applicati automaticamente al database target, mantenendolo sincronizzato

Al momento del cutover, Azure Arc applica l’ultimo backup caricato e porta online il database target

Un vincolo operativo da tenere a mente in fase di progettazione: l’account di Azure Blob Storage e la VM SQL Server target devono trovarsi nella stessa region Azure. È un dettaglio facile da trascurare se si pianifica la migrazione partendo dalla region “storica” dell’organizzazione invece che da quella scelta per il nuovo carico.

Prerequisiti praticiUna subscription Azure attiva

L’istanza SQL Server deve essere abilitata da Azure Arc con l’estensione più recente installata (l’estensione si aggiorna indipendentemente da SQL Server, quindi va controllata separatamente)

L’ambiente sorgente preparato secondo le linee guida ufficiali, incluso l’upload iniziale dei backup nello storage account

Per verificare rapidamente la versione dell’istanza sorgente prima di avviare l’assessment, un semplice controllo T-SQL è sempre un buon punto di partenza:

SELECT SERVERPROPERTY('ProductVersion') AS Versione,
SERVERPROPERTY('Edition') AS Edizione,
SERVERPROPERTY('EngineEdition') AS TipoMotore;Cosa considerare prima di partireIl pannello di monitoraggio e cutover mostra in tempo reale quali database sono migrati con successo, quali sono ancora in corso, il metodo di migrazione scelto, la durata della sincronizzazione e i log dettagliati. Quando lo stato passa a “Ready for cutover”, si può decidere il momento esatto del passaggio in produzione selezionando Cutover, con opzioni diverse in base al metodo di migrazione utilizzato.

Va detto che, come per ogni migrazione basata su backup/restore, restano da valutare a parte gli aspetti di sizing della VM di destinazione (storage, IOPS, memoria per il buffer pool), la licenza SQL Server (Hybrid Benefit se applicabile) e la strategia di alta disponibilità post-migrazione, che questo strumento non copre direttamente ma per cui l’assessment fornisce indicazioni.

ConclusionePortare discovery, assessment, migrazione e monitoraggio in un’unica dashboard riduce sensibilmente l’attrito operativo delle migrazioni SQL Server verso Azure, soprattutto per i team che gestiscono ambienti ibridi complessi con decine o centinaia di istanze. Non elimina la necessità di pianificazione — region, sizing e licensing restano decisioni da prendere a monte — ma consolida in un solo posto ciò che prima richiedeva più tool scollegati tra loro. Per chi ha già istanze abilitate da Azure Arc, vale la pena aggiornare l’estensione e lanciare un primo assessment anche solo per farsi un’idea della readiness del proprio parco macchine.

Fonte: Petri IT Knowledgebase e documentazione Microsoft Learn.