Condividi tramite

Confrontare l'archiviazione con ridondanza locale con il collegamento a Istanza gestita

  • Articolo

Si applica a:Istanza gestita di SQL di Azure

Questo articolo confronta il Log Replay Service (LRS) con il collegamento all'Istanza Gestita durante la migrazione a Istanza Gestita SQL di Azure.

Informazioni generali

Log Replay Service (LRS) è stato usato per le migrazioni verso Azure SQL Managed Instance dal lancio del servizio a novembre 2018. Sotto il cofano, l'implementazione del log shipping supporta il Servizio di Migrazione del database di Azure e l'estensione di migrazione SQL di Azure per Azure Data Studio.

Nel mese di marzo 2022, il collegamento Istanza gestita (collegamento MI) è stato introdotto come opzione di migrazione più efficiente, con una promessa del miglior tempo di inattività minimo possibile per la migrazione. Il collegamento Istanza Gestita utilizza la tecnologia del gruppo di disponibilità Always On distribuito per replicare i dati quasi in tempo reale da SQL Server ad Azure SQL Istanza Gestita. Con il collegamento è anche possibile eseguire il fallback online da Istanza gestita di SQL a SQL Server 2022 o versione successiva come polizza assicurativa per la migrazione.

L'archiviazione con ridondanza locale e il collegamento MI si integrano tra loro nelle funzionalità, con ogni tecnologia che soddisfa esigenze aziendali diverse. Esaminare le funzionalità di ogni strumento per determinare quale sia l'opzione migliore da usare per la migrazione in base alle circostanze specifiche.

La differenza fondamentale tra LRS e il link MI deriva dalla tecnologia di base. Poiché LRS si basa sul log shipping, i backup differenziali e del log delle transazioni vengono continuamente eseguiti da SQL Server, caricati nell'Azure Blob Storage e ripristinati su SQL Managed Instance. Il processo non è in tempo reale, perché richiede tempo per eseguire il backup dei file, caricarli e ripristinarli. Le prestazioni di LRS dipendono dalle dimensioni dei segmenti di backup.

Al contrario, il collegamento MI usa la tecnologia del gruppo di disponibilità AlwaysOn per inviare i record del log delle transazioni quasi in tempo reale da SQL Server a Istanza gestita di SQL, rendendola una soluzione di migrazione notevolmente più efficiente. Tuttavia, per configurare il collegamento MI, è necessario impostare una VPN tra SQL Server e SQL Managed Instance e aprire le porte appropriate nel firewall, mentre l'archiviazione con ridondanza locale funziona fin da subito utilizzando un endpoint pubblico. LRS può essere usato per tutte le edizioni di SQL Server 2008 e versioni successive, mentre il collegamento MI può essere usato solo per le edizioni Standard, Enterprise e Developer di SQL Server 2016 e versioni successive.

Un vantaggio principale del collegamento MI è la possibilità di eseguire una migrazione inversa su SQL Server 2022 e versioni successive, cosa non possibile con LRS (archiviazione ridondante locale). Un altro vantaggio principale della migrazione con il collegamento MI è che il database nell'istanza gestita di SQL può essere usato per i carichi di lavoro di sola lettura mentre la migrazione è in corso. Questa funzionalità non è disponibile con l'archiviazione con ridondanza locale (LRS), perché il database è in fase di ripristino fino al completamento della migrazione. Analogamente, quando si esegue una migrazione inversa a SQL Server 2022 e versioni successive, il database è accessibile per i carichi di lavoro di sola lettura in SQL Server mentre la migrazione è in corso.

La tabella seguente confronta l'archiviazione con ridondanza locale (LRS) e il collegamento MI in modo più dettagliato.

Funzionalità Collegamento a Istanza gestita (collegamento MI) Servizio di riproduzione dei log (LRS) Note
Tecnologia sottostante Gruppi di disponibilità distribuiti Trasferimento dei log Il collegamento MI utilizza un gruppo di disponibilità distribuito per la replica, una tecnologia più recente e avanzata rispetto al log shipping usato dall'archiviazione con ridondanza locale (LRS).
Prestazioni della replica Quasi in tempo reale. Ripristina ogni pochi minuti. La replica dei dati tramite il collegamento MI è notevolmente più performante rispetto all'applicazione dei backup del log delle transazioni con LRS.
Database di origine con supporto minimo SQL Server 2016 e versioni successive SQL Server 2008 e versioni successive LRS può supportare versioni di SQL Server molto più vecchie rispetto al link MI.
Secondario di sola lettura Supportato/a. Non supportato. Mentre la replica è in corso, i database di Istanza gestita di SQL replicati tramite il collegamento possono essere usati per carichi di lavoro di sola lettura, che consentono di testare la migrazione prima del cut over o di usare i database prima della migrazione ad Azure. Analogamente, quando si esegue una migrazione inversa a SQL Server 2022 e versioni successive, il database è accessibile per i carichi di lavoro di sola lettura in SQL Server mentre la migrazione è in corso. Questa funzionalità non è disponibile con LRS (archiviazione con ridondanza locale).
Replicazione dei database crittografati TDE Sì, richiede l'importazione di chiavi di sicurezza in Istanza gestita di SQL. Sì, richiede l'importazione di chiavi di sicurezza in Istanza gestita di SQL. Il requisito e la procedura per eseguire la migrazione del certificato di crittografia corrispondente da SQL Server a Istanza gestita di SQL prima di avviare la migrazione è lo stesso per entrambe le opzioni di migrazione.
Tipo di connettività di rete - Endpoint privato
- VPN configurata con porte in ingresso e in uscita		 Endpoint pubblico Sebbene MI link offra livelli di sicurezza aggiuntivi e offra VPN come opzione, la configurazione della rete è più difficile rispetto a LRS.

Per impostazione predefinita, LRS offre un'esperienza semplificata in modo da poterlo utilizzare immediatamente senza necessità di configurazioni di rete o VPN. LRS usa un endpoint pubblico per impostazione predefinita, che è meno sicuro rispetto alla VPN utilizzata con il collegamento MI, e potrebbe non soddisfare alcuni dei requisiti di sicurezza più impegnativi poiché utilizza un account di archiviazione Blob di Azure esposto pubblicamente come intermediario per salvare i dati prima del ripristino su Istanza Gestita di SQL (SQL Managed Instance). Sebbene sia possibile usare un endpoint privato con archiviazione con ridondanza locale (LRS) per rendere più sicura la trasmissione dei dati, ciò aumenta la complessità della configurazione iniziale.
Crittografia dei dati nella trasmissione - Dati crittografati con AES e
- SSL viene usato per la crittografia della trasmissione dei dati.		 SSL viene usato per la crittografia della trasmissione dei dati. Il collegamento MI usa un livello di crittografia AES dati aggiuntivo. SSL viene usato per la trasmissione di dati per gli strumenti di migrazione.
Autenticazione per la replica Certificati firmati da un'autorità attendibile (CA) Identità gestite o token di firma di accesso condiviso Il collegamento MI richiede un'autorità di certificazione (CA) per firmare un certificato per l'autenticazione. Per LRS, l'uso di identità gestite è più sicuro rispetto all'uso di token SAS autogenerati.
Impatto sugli aggiornamenti o sul failover del sistema No, ad eccezione di un'interruzione minima per un breve failover. - Per le istanze per utilizzo generico, la migrazione viene sospesa e ripresa automaticamente dopo le interruzioni.
- Per le istanze business critical, il processo di migrazione viene annullato per le interruzioni e deve essere riavviato manualmente.		 Il collegamento MI è resiliente e la migrazione non viene influenzata dai failover di Istanza gestita SQL.

Viceversa, le migrazioni LRS vengono ritardate dai riavvii o dai failover delle istanze gestite di SQL nel livello di servizio Servizio Generico, e la migrazione viene riavviata per le istanze nel livello di servizio Business Critical.
Durata replicazione Tempo di replica illimitato usando il collegamento (mesi e persino anni alla volta). Il lavoro LRS può essere eseguito per un massimo di 30 giorni. Un collegamento MI può essere eseguito per un periodo illimitato di tempo.

LRS è limitato a un massimo di 30 giorni di spedizione continua dei log, dopo di che la migrazione viene arrestata automaticamente ed è necessario riavviarla dall'inizio.
Tipo di migrazione Vera migrazione online con un failover breve (misurato in secondi). - Migrazione online con tempi di inattività previsti durante il passaggio per il tempo necessario a ripristinare l'ultimo file di backup.
- Il tempo richiesto per il passaggio delle istanze nel livello di servizio Business Critical è significativamente maggiore.		 Il collegamento MI è l'unica soluzione che offre una soluzione per ridurre al minimo il tempo di inattività (<1 minuto) per tutti i livelli di servizio di SQL Istanza Gestita.

Con LRS, l'ultimo file di backup è ancora in corso di ripristino durante il passaggio. In base alle dimensioni di tale file e al tempo necessario per completare il ripristino, potrebbe esserci un'attesa significativa prima che il database diventi disponibile su Istanza Gestita di SQL.

Quando si utilizza LRS (archiviazione con ridondanza locale) per eseguire la migrazione al livello di servizio Business Critical, il tempo di inattività della migrazione può essere notevolmente più lungo, poiché l'intero database deve essere replicato nei nodi secondari dal nodo primario prima che il database sia disponibile per i carichi di lavoro sul nodo primario. A seconda delle dimensioni complessive del database, la replica negli altri nodi e pertanto il tempo di inattività può richiedere ore.

Di conseguenza, i database possono diventare disponibili notevolmente più lentamente con LRS (archiviazione con ridondanza locale) rispetto al collegamento MI, che può essere quasi istantaneo.
Manutenzione richiesta sul sorgente Sì, backup regolari del log delle transazioni. No. Il collegamento MI richiede backup regolari del log delle transazioni dell'istanza di SQL Server di origine durante la migrazione per troncare il log delle transazioni e impedire l'esaurimento dello spazio su disco.

Al contrario, non è necessaria alcuna manutenzione per LRS.
Resilienza Riprende automaticamente la replica dei collegamenti se SQL Server viene riavviato. - La migrazione si blocca se è presente una catena di backup interrotta o un file di backup specificato in modo non corretto.
- Non supporta i file di backup da più database nella stessa cartella (la migrazione ha esito negativo).		 Il collegamento MI è più resiliente rispetto a LRS perché la replica riprende automaticamente non appena vengono risolti i problemi, come ad esempio interruzioni inaspettate, aggiornamenti, perdita di connettività di rete e molti altri. Inoltre, il collegamento MI è resiliente ai failover di SQL Managed Instance o agli aggiornamenti del servizio.

Alcune condizioni causano un blocco dell'LRS. La migrazione con ridondanza locale viene riavviata automaticamente se la migrazione al livello di servizio per utilizzo generico viene interrotta, ma deve essere riavviata se viene interrotta una migrazione al livello di servizio Business Critical.
Migrazione inversa da istanza gestita di SQL a SQL Server La migrazione offline e online a SQL Server 2022 e versioni successive è supportata. Non supportato. Il collegamento MI è l'unica soluzione che offre la migrazione inversa online e offline a SQL Server 2022 e versioni successive. La migrazione inversa non è disponibile per le versioni precedenti di SQL Server.

Cosa scegliere?

La scelta tra LRS e il link MI dipende dalle circostanze e dalle esigenze aziendali. La differenza notevole tra le soluzioni di migrazione è le prestazioni. LRS ha una configurazione iniziale più semplice, che consente di migrare rapidamente. Sebbene la configurazione iniziale del collegamento MI sia più complessa, offre maggiore resilienza, sicurezza e flessibilità.

Inoltre, il tempo di cutover è notevolmente più breve con il collegamento MI, che è un vantaggio significativo per molti clienti. Di fatto, il potenziale tempo di inattività notevole durante la migrazione al livello di servizio Business Critical con LRS è il motivo per cui il collegamento MI viene definito l'unica migrazione "veramente online" al livello di servizio Business Critical.

Infine, se è necessario che il database sia accessibile per i carichi di lavoro di sola lettura nella destinazione di migrazione mentre è in corso la migrazione o se è necessario eseguire di nuovo una migrazione inversa a SQL Server 2022 e versioni successive, il collegamento MI è l'unica opzione che supporta questi scenari.

Contenuti correlati