Esaminare un'istanza gestita di SQL

  • 9 minuti

Sebbene molte organizzazioni esecupino inizialmente la migrazione ad Azure usando le offerte IaaS, la piattaforma distribuita come servizio (PaaS) offre vantaggi aggiuntivi. Con PaaS, il servizio gestisce l'installazione e l'applicazione di patch a SQL Server, quindi non è più necessario eseguire queste attività. I controlli di coerenza, i backup, la sicurezza e gli strumenti per le prestazioni sono inclusi anche come parte del servizio gestito.

Istanza gestita di SQL di Azure è un'istanza di SQL Server completamente funzionale che è quasi 100% compatibile con l'ecosistema locale. Include funzionalità come SQL Agent, accesso a tempdb, query tra database e Common Language Runtime (CLR). Questo servizio usa la stessa infrastruttura del database SQL di Azure e offre tutti i vantaggi di PaaS, ad esempio backup automatici, applicazione automatica di patch e disponibilità elevata predefinita.

Funzionalità di Istanza gestita di SQL di Azure

Istanza gestita di SQL di Azure offre un percorso di migrazione semplice per le applicazioni esistenti abilitando i ripristini dai backup locali. A differenza del database SQL di Azure, progettato per strutture di database singoli, Istanza gestita di SQL offre un'istanza completa di SQL Server, che supporta fino a 100 database e concede l'accesso ai database di sistema. Include anche funzionalità non disponibili nel database SQL di Azure, ad esempio query tra database, Common Language Runtime (CLR) e l'uso di SQL Agent tramite il database di sistema msdb.

Quando si crea un'istanza gestita di SQL di Azure, è possibile scegliere tra due livelli di servizio: Business Critical e Utilizzo generico. Questi livelli sono allineati al modello vCore del database SQL di Azure, perché le istanze gestite di SQL vengono acquistate usando questo modello. Le differenze principali tra i due livelli sono che Business Critical include In-Memory OLTP e fornisce funzionalità secondarie leggibili, non disponibili nel livello Utilizzo generico. Entrambi i livelli offrono disponibilità elevata, con il livello Business Critical usando i gruppi di disponibilità Always On per una maggiore resilienza. Inoltre, entrambi i livelli consentono la configurazione indipendente delle risorse di archiviazione e di calcolo.

La funzionalità Collegamento offre funzionalità ibride replicando database da istanze di SQL Server a Istanza gestita di SQL di Azure. Usa gruppi di disponibilità distribuiti, parte della tecnologia del gruppo di disponibilità AlwaysOn, per replicare i dati. I record del log delle transazioni vengono replicati come parte di questi gruppi di disponibilità distribuiti.

I record del log delle transazioni nell'istanza primaria non possono essere troncati fino a quando non vengono replicati nell'istanza secondaria. I backup regolari del log delle transazioni consentono di ridurre il rischio di esaurimento dello spazio nell'istanza primaria.

La funzionalità Collegamento può essere usata anche come soluzione di ripristino di emergenza ibrido, consentendo di eseguire il failover dei database di SQL Server ospitati ovunque in un database in esecuzione in Istanza gestita di SQL. Inoltre, è possibile usare la funzionalità Collegamento per fornire un database secondario di sola lettura in Istanza gestita di SQL, scaricamento delle operazioni di sola lettura intensive.

Per altre informazioni su come configurare la funzionalità di collegamento per Istanza gestita di SQL di Azure, vedere Preparare l'ambiente per la funzionalità di collegamento - Istanza gestita di SQL di Azure.

Pool di istanze

I pool di istanze offrono un modo conveniente per eseguire la migrazione di istanze di SQL Server più piccole nel cloud. Anziché consolidare i database più piccoli in un'istanza gestita di dimensioni maggiori, che richiede una governance aggiuntiva e una pianificazione della sicurezza, i pool di istanze consentono di effettuare il pre-provisioning delle risorse in base alle esigenze e ai requisiti totali della migrazione.

La funzionalità del pool di istanze offre un tempo di distribuzione rapido fino a 10 minuti, rendendo ideale per gli scenari in cui la durata della distribuzione è fondamentale. Inoltre, tutte le istanze di un pool condividono la stessa macchina virtuale e l'allocazione IP totale è indipendente dal numero di istanze distribuite.

Per informazioni su come distribuire un pool di istanze per Istanza gestita di SQL, vedere Distribuire Istanza gestita di SQL di Azure in un pool di istanze .

Disponibilità elevata e ripristino di emergenza

Istanza gestita di SQL di Azure, come servizio PaaS, offre intrinsecamente disponibilità elevata. Un'istanza gestita SQL autonoma offre un Accordo sul Livello di Servizio (SLA) del 99,99%, garantendo un massimo di 52,60 minuti di interruzione all'anno. L'architettura rispecchia quella del database SQL di Azure: il livello Utilizzo generico usa la replica di archiviazione per la disponibilità, mentre il livello Business Critical usa più repliche per migliorare la resilienza.

Azure SQL Istanza Gestita offre gruppi di failover automatici per il ripristino d'emergenza, proteggendo l'intera istanza gestita e tutti i database associati. Questa funzionalità replica in modo asincrono i dati dall'istanza gestita di SQL di Azure primaria a un'istanza secondaria, ma attualmente è limitata all'area di Azure abbinata dell'istanza primaria, con una sola replica consentita.

Analogamente al database SQL di Azure, i gruppi di failover automatico forniscono endpoint listener di lettura/scrittura e di sola lettura, semplificando la gestione delle stringhe di connessione. In caso di failover, le stringhe di connessione dell'applicazione vengono indirizzate automaticamente all'istanza appropriata. Tuttavia, questi endpoint seguono un formato leggermente diverso: <fog-name>.zone_id.database.windows.net per Istanza gestita di SQL, rispetto a <fog-name>.zone_id.database.windows.net, mentre il database SQL di Azure utilizza il formato <fog-name>.secondary.database.windows.net.

Sia le istanze gestite primarie che secondarie devono trovarsi nella stessa zona DNS. In questo modo si garantisce che lo stesso certificato multidominio possa essere usato per l'autenticazione della connessione client tra le istanze nel gruppo di failover. È possibile specificare un "Partner zona DNS" tramite il portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure.

Backup

I backup automatici sono configurati per impostazione predefinita per Istanza gestita di SQL di Azure. Una differenza fondamentale tra Istanza gestita di SQL di Azure e il database SQL di Azure è che con Istanza gestita di SQL è possibile creare manualmente un backup di sola copia di un database. Questi backup devono essere archiviati in un URL, perché l'accesso all'archiviazione locale non è consentito. È anche possibile configurare la conservazione a lungo termine (LTR) per conservare i backup automatici per un massimo di 10 anni nell'archiviazione BLOB di Azure con ridondanza geografica.

I backup del database seguono la stessa pianificazione del database SQL di Azure e queste pianificazioni non possono essere modificate.

  • Completo: una volta alla settimana
  • Differenziale: ogni 12 ore
  • Log delle transazioni: ogni 5-10 minuti in base all'utilizzo del log delle transazioni

Il ripristino di un database in un'istanza gestita di SQL di Azure è simile al processo con il database SQL di Azure. È possibile usare il portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure. Per eseguire il ripristino da un'istanza a un'altra, entrambe le istanze devono trovarsi nella stessa sottoscrizione di Azure e nella stessa area. Inoltre, non è possibile ripristinare l'intera istanza gestita, ma solo i singoli database all'interno dell'istanza gestita di SQL.

Come nel database SQL di Azure, non è possibile eseguire il ripristino su un database esistente. È necessario eliminare o rinominare il database esistente prima di ripristinarlo dal backup. Poiché SQL Managed Instance è un'istanza di SQL Server completamente funzionale, è possibile eseguire un comando RESTORE, cosa che non è possibile con Azure SQL Database. Tuttavia, come servizio PaaS, esistono alcune limitazioni:

  • È necessario eseguire il ripristino da un endpoint URL, perché le unità locali non sono accessibili.
  • È possibile utilizzare le opzioni seguenti oltre a specificare il database:
    • FILELISTONLY
    • HEADERONLY
    • LABELONLY
    • VERIFYONLY
  • I file di backup che contengono più file di log non possono essere ripristinati
  • I file di backup che contengono più set di backup non possono essere ripristinati
  • Non è possibile ripristinare i backup che contengono in-Memory/FILESTREAM

Per impostazione predefinita, i database in un'istanza gestita vengono crittografati usando Transparent Data Encryption (TDE) con una chiave gestita da Microsoft. Per eseguire un backup di sola copia avviato dall'utente, è necessario disabilitare TDE per il database specifico. Se un database è crittografato, è possibile ripristinarlo, ma è necessario accedere al certificato o alla chiave asimmetrica usata per la crittografia. Senza questi, non è possibile ripristinare il database in un'istanza gestita di SQL.

Per informazioni sulle nuove funzionalità per Istanza gestita di SQL di Azure, vedere Novità di Istanza gestita di SQL di Azure.