Configurare un gruppo di failover per l'istanza gestita di SQL di Azure
Si applica a: 
Istanza gestita di SQL di Azure SQL
Questo articolo illustra come configurare un gruppo di failover per Istanza gestita di SQL di Azure usando il portale di Azure e Azure PowerShell.
Per uno script PowerShell end-to-end che crei entrambe le istanze all'interno di un gruppo di failover, consultare Aggiungere un'istanza a un gruppo di failover con PowerShell.
Prerequisiti
Per configurare un gruppo di failover, è necessario disporre delle opportune autorizzazioni e di un'istanza gestita di SQL che si intende usare come primaria. Per iniziare, vedere Crea istanza.
Assicurarsi di esaminare le limitazioni prima di creare l'istanza secondaria e il gruppo di failover.
Requisiti di configurazione
Per configurare un gruppo di failover tra un'istanza gestita SQL primaria e una secondaria, considerare i seguenti requisiti:
- L'istanza gestita secondaria deve essere vuota, ovvero non contenere database utente.
- Le due istanze devono avere lo stesso livello di servizio e le stesse dimensioni di archiviazione. Sebbene non sia obbligatorio, è fortemente consigliato che entrambe le istanze abbiano le stesse dimensioni di calcolo, per garantire che l'istanza secondaria possa elaborare in modo sostenibile le modifiche replicate dall'istanza primaria, anche durante i periodi di attività di picco.
- L’intervallo di indirizzi IP per la rete virtuale dell'istanza primaria non deve sovrapporsi all'intervallo di indirizzi della rete virtuale per l'istanza gestita secondaria o a qualsiasi altra rete virtuale con peering con la rete virtuale primaria o secondaria.
- Entrambe le istanze devono trovarsi nella stessa zona DNS. Quando si crea l'istanza gestita secondaria, è necessario specificare l'ID della zona DNS dell'istanza primaria. In caso contrario, l'ID della zona viene generato come stringa casuale quando viene creata la prima istanza in ogni rete virtuale e lo stesso ID viene assegnato a tutte le altre istanze nella stessa subnet. Dopo l'assegnazione, la zona DNS non può essere modificata.
- Le regole dei gruppi di sicurezza di rete (NSG) per le subnet di entrambe le istanze devono avere connessioni TCP in ingresso e in uscita aperte per la porta 5022 e l'intervallo di porte 11000-11999 per facilitare la comunicazione tra le due istanze.
- Le istanze gestite dovrebbero essere implementate in aree associate per motivi di prestazioni. Le istanze gestite che risiedono in aree geografiche abbinate beneficiano di una velocità di replica geografica significativamente più elevata rispetto alle aree non abbinate.
- Entrambe le istanze devono usare gli stessi criteri di aggiornamento.
Creare l'istanza secondaria
Quando si crea l'istanza secondaria, è necessario utilizzare una rete virtuale con uno spazio di indirizzi IP che non si sovrapponga all'intervallo di spazi di indirizzi IP dell'istanza primaria. Inoltre, quando si configura la nuova istanza secondaria, è necessario specificare l'ID dell zona dell'istanza primaria.
È possibile configurare la rete virtuale secondaria e creare l'istanza secondaria usando il portale di Azure e PowerShell.
Creare una rete virtuale
Per creare una rete virtuale per l'istanza secondaria nel portale di Azure, procedere come segue:
Controllare lo spazio indirizzi per l'istanza primaria. Accedere alla risorsa di rete virtuale per l'istanza primaria nel portale di Azure e in Impostazioni selezionare Spazio indirizzi. Controllare l'intervallo in Intervallo di indirizzi:
Creare una nuova rete virtuale che si prevede di usare per l'istanza secondaria passando alla pagina Crea rete virtuale.
Nella scheda Informazioni di base della pagina Crea rete virtuale:
- Selezionare il gruppo di risorse che si intende usare per l'istanza secondaria. Crearne uno nuovo se non esiste ancora.
- Specificare un nome per la rete virtuale, ad esempio
vnet-sql-mi-secondary. - Selezionare un'area abbinata all'area in cui si trova l'istanza primaria.
Nella scheda Indirizzi IP della pagina Crea rete virtuale:
- Usare Elimina spazio indirizzi per eliminare lo spazio indirizzi IPv4 esistente.
- Dopo l'eliminazione dello spazio indirizzi, selezionare Aggiungi spazio indirizzi IPv4 per aggiungere un nuovo spazio e quindi specificare uno spazio indirizzi IP diverso dallo spazio indirizzi usato dalla rete virtuale dell'istanza primaria. Ad esempio, se l'istanza primaria corrente usa uno spazio indirizzi 10.0.0.16, immettere
10.1.0.0/16per lo spazio indirizzi della rete virtuale che si intende usare per l'istanza secondaria. - Usare + Aggiungi una subnet per aggiungere una subnet predefinita con valori predefiniti.
- Usare + Aggiungi una subnet per aggiungere una subnet vuota denominata
ManagedInstanceche verrà dedicata all'istanza secondaria, usando un intervallo di indirizzi diverso dalla subnet predefinita. Ad esempio, se l'istanza primaria usa un intervallo di indirizzi compreso tra 10.0.0.0 e 10.0.255.255, specificare un intervallo di subnet di10.1.1.0 - 10.1.1.255per la subnet dell'istanza secondaria.
Selezionare Rivedi e crea per verificare le impostazioni e quindi selezionare Crea per creare la nuova rete virtuale.
Creare un'istanza secondaria
Una volta che la rete virtuale è pronta, seguire questa procedura per creare l'istanza secondaria nel portale di Azure:
Accedere a Crea istanza gestita di SQL di Azure nel portale di Azure.
Nella scheda Dati generali della pagina Crea Istanza gestita di SQL di Azure:
- Scegliere un'area per l'istanza secondaria abbinata all'istanza primaria.
- Scegliere un livello di servizio corrispondente al livello di servizio dell'istanza primaria.
Nella scheda Rete della pagina Crea Istanza gestita di SQL di Azure usare l'elenco a discesa in Rete virtuale/subnet per selezionare la rete virtuale e la subnet create in precedenza:
Nella scheda Impostazioni aggiuntive della pagina Crea Istanza gestita di SQL di Azure selezionare Sì per Usa come istanza secondaria di failover e quindi scegliere l'istanza primaria appropriata dall'elenco a discesa.
Configurare il resto dell'istanza in base alle esigenze aziendali e quindi crearla usando Rivedi e crea.
Stabilire la connettività tra le istanze
Per un flusso ininterrotto del traffico di replica geografica, è necessario stabilire la connettività tra le subnet della rete virtuale che ospitano le istanze primaria e secondaria. Esistono diversi modi per connettere istanze gestite in aree di Azure diverse, tra cui:
- Peering di rete virtuale globale
- Azure ExpressRoute
- Gateway VPN
Il peering di reti virtuali globale è il metodo consigliato più solido e performante per stabilire la connettività tra due istanze in un gruppo di failover. Il peering di reti virtuali globale consente di avere una connessione privata a bassa latenza e con larghezza di banda elevata tra le reti virtuali con peering usando l'infrastruttura backbone di Microsoft. Nella comunicazione tra le reti virtuali con peering non sono necessari gateway, la rete Internet pubblica o una crittografia aggiuntiva.
Importante
I modi alternativi di connessione delle istanze che coinvolgono dispositivi di rete aggiuntivi potrebbero complicare la risoluzione dei problemi di connettività o velocità di replica, eventualmente richiedendo un coinvolgimento attivo degli amministratori di rete e prolungando in modo significativo i tempi di risoluzione.
Se si utilizza un meccanismo per stabilire la connettività tra le istanze diverso dal peering di reti virtuali globale consigliato, assicurarsi di quanto segue:
- I dispositivi di rete, come firewall o appliance virtuali di rete, non bloccano il traffico sulle connessioni in ingresso e in uscita per la porta 5022 (TCP) e l'intervallo di porte 11000-11999.
- Il routing è configurato correttamente e il routing asimmetrico viene evitato.
- Se si distribuiscono gruppi di failover in una topologia di rete hub-and-spoke tra aree diverse, per evitare problemi di connettività e velocità di replica, il traffico di replica deve transitare direttamente tra le due subnet dell'istanza gestita anziché essere indirizzato attraverso le reti hub.
Questo articolo illustra come configurare il peering di reti virtuali globale tra le reti delle due istanze usando il portale di Azure e PowerShell.
Nel portale di Azure passare alla risorsa Rete virtuale per l'istanza gestita primaria.
Selezionare Peering in Impostazioni per aprire la pagina Peering e quindi usare + Aggiungi dalla barra dei comandi per aprire la pagina Aggiungi peering.
Nella pagina Aggiungi peering, immettere o selezionare i valori per le impostazioni seguenti:
Impostazioni Descrizione Riepilogo della rete virtuale remota Nome del collegamento di peering il nome per il peering deve essere univoco all'interno della rete virtuale. Questo articolo usa Fog-peering.Modello di distribuzione della rete virtuale Seleziona Gestione risorse. Conosco l'ID della risorsa È possibile lasciare deselezionata questa casella, a meno che non si conosca l'ID della risorsa. Abbonamento Selezionare la sottoscrizione dall'elenco a discesa. Rete virtuale Selezionare la rete virtuale per l'istanza secondaria dall'elenco a discesa. Impostazioni del peering di reti virtuali remoto Consentire alla "rete virtuale secondaria" di accedere alla "rete virtuale primaria" Selezionare la casella per consentire la comunicazione tra le due reti. L'abilitazione della comunicazione tra reti virtuali consente alle risorse connesse a una o all'altra delle reti virtuali di comunicare tra loro con la stessa larghezza di banda e latenza che userebbero se fossero connesse alla stessa rete virtuale. Tutte le comunicazioni tra le risorse nelle due reti virtuali avvengono tramite la rete privata di Azure. Consentire alla "rete virtuale secondaria" di ricevere traffico inoltrato dalla "rete virtuale primaria" Ai fini della presente guida, è possibile selezionare o deselezionare questa casella. Per altre informazioni, vedere Creare un peering. Consentire al gateway o al server di route nella "rete virtuale secondaria" di inoltrare il traffico alla "rete virtuale primaria" Ai fini della presente guida, è possibile selezionare o deselezionare questa casella. Per altre informazioni, vedere Creare un peering. Abilitare la "rete virtuale secondaria" per usare il gateway remoto o il server di route della "rete virtuale primaria" Lasciare questa casella deselezionata. Per altre informazioni sulle altre opzioni disponibili, vedere Creare un peering. Riepilogo della rete virtuale locale Nome del collegamento di peering Nome dello stesso peering utilizzato per la rete virtuale remota. Questo articolo usa Fog-peering.Consentire alla "rete virtuale primaria" di accedere alla "rete virtuale secondaria" Selezionare la casella per consentire la comunicazione tra le due reti. L'abilitazione della comunicazione tra reti virtuali consente alle risorse connesse a una o all'altra delle reti virtuali di comunicare tra loro con la stessa larghezza di banda e latenza che userebbero se fossero connesse alla stessa rete virtuale. Tutte le comunicazioni tra le risorse nelle due reti virtuali avvengono tramite la rete privata di Azure. Consentire alla "rete virtuale primaria" di ricevere traffico inoltrato da "rete virtuale secondaria" Ai fini della presente guida, è possibile selezionare o deselezionare questa casella. Per altre informazioni, vedere Creare un peering. Consentire al gateway o al server di route nella "rete virtuale primaria" di inoltrare il traffico alla "rete virtuale secondaria" Ai fini della presente guida, è possibile selezionare o deselezionare questa casella. Per altre informazioni, vedere Creare un peering. Abilitare la "rete virtuale primaria" per usare il gateway remoto o il server di route della "rete virtuale secondaria" Lasciare questa casella deselezionata. Per altre informazioni sulle altre opzioni disponibili, vedere Creare un peering. Usare Aggiungi per configurare il peering con la rete virtuale selezionata e tornare automaticamente alla pagina Peering, che mostra che le due reti sono connesse:
Configurare porte e regole del gruppo di sicurezza di rete
Indipendentemente dal meccanismo di connettività scelto tra le due istanze, le reti devono soddisfare i requisiti seguenti per il flusso del traffico di replica geografica:
- La tabella di route e i gruppi di sicurezza di rete assegnati alle subnet delle istanze gestite non vengono condivisi tra le due reti virtuali con peering.
- Le regole del gruppo di sicurezza di rete (NSG) in entrambe le subnet che ospitano ogni istanza consentono il traffico in ingresso e in uscita verso l'altra istanza sulla porta 5022 e l'intervallo di porte 11000-11999.
È possibile configurare la comunicazione delle porte e le regole dei gruppi di sicurezza di rete usando il portale di Azure e PowerShell.
Per aprire le porte del gruppo di sicurezza di rete nel portale di Azure, seguire questa procedura:
Passare alla risorsa gruppo di sicurezza di rete per l'istanza primaria.
In Impostazioni selezionare Regole di sicurezza in ingresso. Controllare se sono già presenti regole che consentono il traffico per la porta 5022 e l'intervallo 11000-11999. In caso affermativo, e se l'origine soddisfa le esigenze aziendali, ignorare questo passaggio. Se le regole non esistono o se si vuole usare un'origine diversa, ad esempio l'indirizzo IP più sicuro, eliminare la regola esistente e quindi selezionare + Aggiungi dalla barra dei comandi per aprire il riquadro Aggiungi regola di sicurezza in ingresso:
Nel riquadro Aggiungi regola di sicurezza in ingresso, immettere o selezionare i valori per le seguenti impostazioni:
Impostazione Valore consigliato Descrizione Origine Indirizz IP o tag del servizio Filtro per l'origine della comunicazione. L'indirizzo IP è il più sicuro e consigliato per gli ambienti di produzione. Il tag di servizio è appropriato per gli ambienti non di produzione. Tag del servizio di origine Se è stato selezionato Tag del servizio come origine, specificare VirtualNetworkcome tag di origine.I tag predefiniti sono identificatori predefiniti che rappresentano una categoria di indirizzi IP. Il tag VirtualNetwork indica tutti gli spazi di indirizzi di rete virtuale e locale. Indirizzi IP di origine Se sono stati selezionati indirizzi IP come origine, specificare l'indirizzo IP dell'istanza secondaria. Specificare un intervallo di indirizzi usando la notazione CIDR (ad esempio 192.168.99.0/24 o 2001:1234::/64) o un indirizzo IP (ad esempio 192.168.99.0 o 2001:1234::). È anche possibile fornire un elenco delimitato da virgole di indirizzi IP o intervalli di indirizzi usando IPv4 o IPv6. Intervalli porte di origine 5022 Specifica su quali porte il traffico sarà consentito da questa regola. Servizioo Personalizzazione Il servizio specifica il protocollo di destinazione e l'intervallo di porte per questa regola. Intervalli porte di destinazione 5022 Specifica su quali porte il traffico sarà consentito da questa regola. Questa porta deve corrispondere all'intervallo di porte di origine. Azione Consenti Consentire la comunicazione sulla porta specificata. Protocollo TCP Determina il protocollo per la comunicazione tra porte. Priorità 1200 Le regole vengono elaborate in ordine di priorità; minore è il numero, maggiore è la priorità. Nome allow_geodr_inbound Il nome della regola. Descrizione Facoltativo È possibile scegliere di specificare una descrizione o lasciare vuoto questo campo. Selezionare Aggiungi per salvare le impostazioni e aggiungere la nuova regola.
Ripetere questi passaggi per aggiungere un'altra regola di sicurezza in ingresso per l'intervallo di porte
11000-11999con un nome, ad esempio allow_redirect_inbound e una priorità leggermente superiore alla regola 5022, ad esempio1100.In Impostazioni selezionare Regole di sicurezza in uscita. Controllare se sono già presenti regole che consentono il traffico per la porta 5022 e l'intervallo 11000-11999. In caso affermativo, e se l'origine soddisfa le esigenze aziendali, ignorare questo passaggio. Se le regole non esistono o se si vuole usare un'origine diversa, ad esempio l'indirizzo IP più sicuro, eliminare la regola esistente e quindi selezionare + Aggiungi dalla barra dei comandi per aprire il riquadro Aggiungi regola di sicurezza in uscita.
Nel riquadro Aggiungi regola di sicurezza in uscita usare la stessa configurazione per la porta 5022 e l'intervallo
11000-11999usato per le porte in ingresso.Passare al gruppo di sicurezza di rete per l'istanza secondaria e ripetere questi passaggi in modo che entrambi i gruppi di sicurezza di rete abbiano le regole seguenti:
- Consentire il traffico in ingresso sulla porta 5022
- Consentire il traffico in ingresso sull'intervallo di porte
11000-11999 - Consentire il traffico in uscita sulla porta 5022
- Consentire il traffico in uscita sull'intervallo di porte
11000-11999
Creare il gruppo di failover
Creare il gruppo di failover per le istanze gestite usando il portale di Azure o PowerShell.
Creare il gruppo di failover per i Istanza gestita di SQL usando il portale di Azure.
Selezionare Azure SQL nel menu a sinistra nel portale di Azure. Se Azure SQL non è presente nell'elenco, selezionare Tutti i servizi e digitare Azure SQL nella casella di ricerca. (Facoltativo) Selezionare la stella accanto ad Azure SQL per aggiungerlo ai Preferiti e come elemento del riquadro di spostamento sinistro.
Selezionare l'istanza gestita primaria da aggiungere al gruppo di failover.
In Gestione dei dati, selezionare Gruppi di failover e quindi usare Aggiungi gruppo per aprire la pagina Gruppo di failover dell'istanza:
Nella pagina Gruppo di failover dell'istanza:
- L'istanza gestita primaria è preselezionata.
- In Nome gruppo di failover immettere un nome per il gruppo di failover.
- In Istanza gestita secondaria selezionare l'istanza gestita che si vuole usare come secondaria nel gruppo di failover.
- Scegliere un criterio di failover di lettura/scrittura dall'elenco a discesa. Si consiglia l'opzione manuale per avere il controllo sul failover.
- Lasciare Abilita diritti di failover su Disattivato, a meno che non si intenda usare questa replica solo per il ripristino di emergenza.
- Usare Crea per salvare le impostazioni e creare il gruppo di failover.
Al termine della distribuzione del gruppo di failover, si torna alla pagina Gruppi di failover. La pagina viene aggiornata per visualizzare il nuovo gruppo di failover al termine della distribuzione.
Failover di test
Testare il failover del gruppo di failover usando il portale di Azure o PowerShell.
Nota
Se le istanze si trovano in sottoscrizioni o gruppi di risorse diversi, avviare il failover dall'istanza secondaria.
Testare il failover del gruppo di failover con il portale di Azure.
Passare all'istanza gestita primaria o secondaria all'interno del portale di Azure.
In Gestione dei dati, selezionare Gruppi di failover.
Nel riquadro Gruppi di failover annotare quale istanza è l'istanza primaria e quale istanza è l'istanza secondaria.
Nel riquadro Gruppi di failover selezionare Failover dalla barra dei comandi. Selezionare Sì sull'avviso relativo alla disconnessione delle sessioni TDS e prendere nota delle implicazioni per le licenze.
Nel riquadro Gruppi di failover, una volta completato il failover, le istanze si scambiano i ruoli in modo che l'istanza secondaria precedente diventi la nuova istanza primaria e l'istanza primaria precedente diventi la nuova istanza secondaria.
Importante
Se i ruoli non sono stati scambiati, verificare la connettività tra le istanze e le relative regole NSG e del firewall. Procedere con il passaggio successivo solo dopo il cambio di ruolo.
(Facoltativo) Nel riquadro Gruppi di failover usare Failover per invertire i ruoli in modo che l'istanza primaria originale torni a essere primaria.
Modificare gruppo di failover esistente
È possibile modificare un gruppo di failover esistente, ad esempio per modificare i criteri di failover, usando il portale di Azure, PowerShell, l'interfaccia della riga di comando di Azure e le API REST.
Per modificare un gruppo di failover esistente tramite il portale di Azure, eseguire questi passaggi:
Passare a Istanza gestita di SQL nel portale di Azure.
In Gestione dati selezionare Gruppi di failover per aprire il riquadro Gruppi di failover.
Nel riquadro Gruppi di failover selezionare Modifica configurazioni dalla barra dei comandi per aprire il riquadro Modifica gruppo di failover:
Individuare l'endpoint del listener
Dopo aver configurato il gruppo di failover, aggiornare la stringa di connessione dell'applicazione per puntare all'endpoint del listener di lettura/scrittura in modo che l'applicazione continui a connettersi all'istanza primaria dopo il failover. Usando l'endpoint del listener, non è necessario aggiornare manualmente la stringa di connessione ogni volta che il gruppo di failover esegue il failover perché il traffico viene sempre indirizzato all'istanza primaria corrente. È anche possibile indirizzare il carico di lavoro di sola lettura all'endpoint del listener di sola lettura.
Importante
La connessione a un'istanza di un gruppo di failover utilizzando la stringa di connessione specifica dell'istanza è supportata, ma è fortemente sconsigliata. Usare invece gli endpoint del listener.
Per ricercare l'endpoint del listener nel portale di Azure, passare all'istanza gestita di SQL e in Gestione dati selezionare Gruppi di failover.
Scorrere verso il basso per trovare gli endpoint del listener:
- L'endpoint del listener di lettura/scrittura, sotto forma di
fog-name.dns-zone.database.windows.net, instrada il traffico all'istanza primaria. - L'endpoint del listener di sola lettura, sotto forma di
fog-name.secondary.dns-zone.database.windows.net, instrada il traffico all'istanza secondaria.
Creare un gruppo di failover tra le istanze in sottoscrizioni diverse
È possibile creare un gruppo di failover tra istanze gestite di SQL in due sottoscrizioni diverse, purché le sottoscrizioni siano associate allo stesso tenant di Microsoft Entra.
- Quando si usa l'API di PowerShell, è possibile farlo specificando il parametro
PartnerSubscriptionIdper l’Istanza gestita di SQL secondaria. - Quando si usa l'API REST, ogni ID istanza incluso nel parametro
properties.managedInstancePairspuò avere il proprio ID sottoscrizione. - Il portale di Azure non supporta la creazione di gruppi di failover tra sottoscrizioni diverse.
Importante
Il portale di Azure non supporta la creazione di gruppi di failover in sottoscrizioni diverse. Per i gruppi di failover esistenti in sottoscrizioni e/o gruppi di risorse diversi, il failover non può essere avviato manualmente tramite il portale di Azure dall'istanza gestita di SQL primaria. È quindi necessario avviarlo dall'istanza geografica secondaria.
Evitare la perdita di dati critici
A causa della latenza elevata delle reti Wide Area Network, per la replica geografica viene usato un meccanismo di replica asincrona. La replica asincrona può comportare la perdita di dati nel caso in cui il database primario abbia esito negativo. Per proteggere questi aggiornamenti critici dalla perdita di dati, uno sviluppatore di applicazioni può richiamare la stored procedure sp_wait_for_database_copy_sync subito dopo il commit della transazione. La chiamata sp_wait_for_database_copy_sync blocca il thread chiamante fino a quando l'ultima transazione sottoposta a commit non viene trasmessa e sottoposta a protezione avanzata nel log delle transazioni del database secondario. Tuttavia, non attende che le transazioni trasmesse vengano riprodotta (eseguite nuovamente) nel database secondario. sp_wait_for_database_copy_sync è limitato a un collegamento di replica geografica specifico. La procedura può essere chiamata da qualsiasi utente che abbia diritti di connessione al database primario.
Nota
sp_wait_for_database_copy_sync impedisce la perdita di dati dopo il failover geografico per transazioni specifiche, ma non garantisce la sincronizzazione completa per l'accesso in lettura. Il ritardo causato da una chiamata di procedura sp_wait_for_database_copy_sync può essere significativo e dipende dalle dimensioni del log delle transazioni non ancora trasmesso al database primario al momento della chiamata.
Modificare l'area secondaria
Si supponga che l'istanza A sia l'istanza primaria, l'istanza B sia l'istanza secondaria esistente e l'istanza C sia la nuova istanza secondaria nella terza area. Per eseguire la transizione, seguire questa procedura:
- Creare l'istanza C con le stesse dimensioni di A e nella stessa zona DNS.
- Eliminare il gruppo di failover tra le istanze A e B. A questo punto, i tentativi di accesso iniziano a non riuscire perché gli alias SQL per i listener del gruppo di failover sono stati eliminati e il gateway non riconoscerà il nome del gruppo di failover. I database secondari vengono disconnessi da quelli primari e diventano database di lettura/scrittura.
- Creare un gruppo di failover con lo stesso nome tra l'istanza A e C. Seguire le istruzioni riportate nella guida alla configurazione del gruppo di failover. Si tratta di un'operazione di dimensioni dei dati e viene completata quando tutti i database dell'istanza A vengono inizializzati e sincronizzati.
- Eliminare l'istanza B se non è necessario per evitare addebiti non necessari.
Nota
Dopo il passaggio 2 e fino al passaggio 3 i database nell'istanza A rimarranno non protetti da un errore irreversibile dell'istanza A.
Cambiare l'area primaria
Si supponga che l'istanza A sia l'istanza primaria, l'istanza B sia l'istanza secondaria esistente e l'istanza C sia la nuova istanza primaria nella terza area. Per eseguire la transizione, seguire questa procedura:
- Creare l'istanza C con le stesse dimensioni di B e nella stessa zona DNS.
- Avviare un failover manuale dall'istanza B per renderla la nuova istanza primaria. L'istanza A diventa automaticamente la nuova istanza secondaria.
- Eliminare il gruppo di failover tra le istanze A e B. A questo punto, i tentativi di accesso che usano gli endpoint del gruppo di failover iniziano a non riuscire. I database secondari in A vengono disconnessi dalle primarie e diventano database di lettura/scrittura.
- Creare un gruppo di failover con lo stesso nome tra l'istanza B e C. Si tratta di un'operazione di dimensionamento dei dati e viene completata quando tutti i database dell'istanza B vengono inizializzati e sincronizzati con l'istanza C. A questo punto, i tentativi di accesso cessano di fallire.
- Eseguire manualmente il failover per passare l'istanza C al ruolo primario. L'istanza B diventa automaticamente la nuova istanza secondaria.
- Eliminare l'istanza A se non è necessario per evitare addebiti non necessari.
Attenzione
Dopo il passaggio 3 e fino al completamento del passaggio 4, i database nell'istanza A rimarranno non protetti da un errore irreversibile dell'istanza A.
Importante
Quando il gruppo di failover viene eliminato, vengono eliminati anche i record DNS per gli endpoint del listener. A questo punto, esiste una probabilità diversa da zero che qualcun altro crei un gruppo di failover con lo stesso nome. Poiché i nomi dei gruppi di failover devono essere univoci a livello globale, ciò impedirà di usare di nuovo lo stesso nome. Per ridurre al minimo questo rischio, non usare nomi di gruppo di failover generici.
Modificare i criteri di aggiornamento
Le istanze in un gruppo di failover devono avere criteri di aggiornamento corrispondenti. Per abilitare i criteri di aggiornamento sempre aggiornati nelle istanze che fanno parte di un gruppo di failover, abilitare prima di tutto i criteri di aggiornamento sempre aggiornati nell'istanza secondaria, attendere che la modifica venga applicata e quindi aggiornare i criteri per l'istanza primaria.
Anche se la modifica dei criteri di aggiornamento sull'istanza primaria nel gruppo di failover determina il failover dell'istanza su un altro nodo locale (in modo analogo alle operazioni di gestione sulle istanze che non fanno parte di un gruppo di failover), non provoca il failover del gruppo di failover, mantenendo l'istanza primaria nel ruolo primario.
Attenzione
Una volta modificati i criteri di aggiornamento in sempre aggiornati, non è più possibile modificarli in criteri di aggiornamento di SQL Server 2022.
Abilitare scenari dipendenti da oggetti dai database di sistema
I database di sistema non vengono replicati nell'istanza secondaria in un gruppo di failover. Per abilitare scenari che dipendono dagli oggetti dei database di sistema, assicurarsi di creare gli stessi oggetti nell'istanza secondaria e di mantenerli sincronizzati con l'istanza primaria.
Ad esempio, se si prevede di usare gli stessi account di accesso nell'istanza secondaria, assicurarsi di crearli con lo stesso SID.
-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;
Per altre informazioni, vedere Replica di account di accesso e processi dell'agente.
Sincronizzare le proprietà dell'istanza e le istanze dei criteri di conservazione
Le istanze in un gruppo di failover rimangono risorse di Azure separate e non verranno replicate automaticamente modifiche alla configurazione dell'istanza primaria nell'istanza secondaria. Assicurarsi di eseguire tutte le modifiche rilevanti sia nell'istanza primaria che secondaria. Ad esempio, se si modificano i criteri di ridondanza dell'archivio di backup o di conservazione dei backup a lungo termine nell'istanza primaria, assicurarsi di modificarlo anche nell'istanza secondaria.
Ridimensionamento delle istanze
È possibile aumentare o ridurre le prestazioni dell'istanza primaria e secondaria passando a dimensioni di calcolo diverse all'interno dello stesso livello di servizio o di un livello di servizio diverso. Quando si aumenta all’interno dello stesso livello di servizio, prima aumentare quelle del database secondario geografico e quindi quelle del database primario. Quando si effettua un ridimensionamento nello stesso livello di servizio, invertire l'ordine: ridurre prima le prestazioni del database primario e quindi ridurre le prestazioni di quello secondario. Seguire la stessa sequenza quando si ridimensiona un'istanza in un livello di servizio diverso.
Questa sequenza è consigliata per evitare problemi dall’elemento geografico secondario, con SKU di una versione precedente, raggiungendo un overload e richiedendo un nuovo processo di seeding durante la procedura di aggiornamento o downgrade.
Autorizzazioni
Le autorizzazioni per un gruppo di failover vengono gestite tramite il controllo degli accessi in base al ruolo di Azure (Azure RBAC).
Il ruolo collaboratore di Istanza gestita di SQL, con ambito per i gruppi di risorse dell'istanza gestita primaria e secondaria, è sufficiente per eseguire tutte le operazioni di gestione sui gruppi di failover.
La tabella seguente offre una visualizzazione granulare delle autorizzazioni minime necessarie e dei rispettivi livelli di ambito minimi necessari per le operazioni di gestione sui gruppi di failover:
| Operazione di gestione | Autorizzazione | Scope |
|---|---|---|
| Creare/Aggiornare il gruppo di failover | Microsoft.Sql/locations/instanceFailoverGroups/write |
Gruppi di risorse dell'istanza gestita primaria e secondaria |
| Creare/Aggiornare il gruppo di failover | Microsoft.Sql/managedInstances/write |
Istanza gestita primaria e secondaria |
| Eseguire il failover del gruppo di failover | Microsoft.Sql/locations/instanceFailoverGroups/failover/action |
Gruppi di risorse dell'istanza gestita primaria e secondaria |
| Forzare il failover del gruppo di failover | Microsoft.Sql/locations/instanceFailoverGroups/forceFailoverAllowDataLoss/action |
Gruppi di risorse dell'istanza gestita primaria e secondaria |
| Eliminare un gruppo di failover | Microsoft.Sql/locations/instanceFailoverGroups/delete |
Gruppi di risorse dell'istanza gestita primaria e secondaria |
Limiti
Quando si crea un nuovo gruppo failover, tenere conto delle seguenti limitazioni:
- Non è possibile creare gruppi di failover tra due istanze nella stessa area di Azure.
- Un'istanza può partecipare a un solo gruppo di failover alla volta.
- Non è possibile creare un gruppo di failover tra due istanze appartenenti a tenant di Azure diversi.
- La creazione di un gruppo di failover tra due istanze in gruppi di risorse o sottoscrizioni diversi è supportata solo con Azure PowerShell o con l'API REST e non nel portale di Azure o con l'interfaccia della riga di comando di Azure. Una volta creato, il gruppo di failover è visibile nel portale di Azure e tutte le operazioni sono supportate nel portale di Azure o tramite l'interfaccia della riga di comando di Azure. Il failover deve essere avviato dall'istanza secondaria.
- Se il seeding iniziale di tutti i database non viene completato entro 7 giorni, la creazione del gruppo di failover fallisce e tutti i database replicati vengono eliminati dall'istanza secondaria.
- La creazione di un gruppo di failover con un'istanza configurata con un collegamento a un'istanza gestita non è attualmente supportata.
- Non è possibile creare gruppi di failover tra istanze se presenti in un pool di istanze.
- I database migrati all’istanza gestita di SQL di Azure usando il servizio di riproduzione log (LRS) non possono essere aggiunti a un gruppo di failover fino a quando non viene eseguito il passaggio di cutover.
Quando si usano i gruppi di failover, tenere conto delle seguenti limitazioni:
- I gruppi di failover non possono essere rinominati. Sarà necessario eliminare il gruppo e ricrearlo con un nome diverso.
- Un gruppo di failover contiene esattamente due istanze gestite. L'aggiunta di istanze aggiuntive al gruppo di failover non è supportata.
- I backup completi vengono eseguiti automaticamente:
- prima del seeding iniziale e possono ritardare notevolmente l'inizio del processo di seeding iniziale.
- dopo il failover e possono ritardare o impedire un failover successivo.
- La ridenominazione del database non è supportata per i database inclusi in un gruppo di failover. Per poter rinominare un database sarà necessario eliminare temporaneamente il gruppo di failover.
- I database di sistema non vengono replicati nell'istanza secondaria in un gruppo di failover. Di conseguenza, gli scenari che dipendono da oggetti dei database di sistema, ad esempio gli accessi al server e i processi degli agenti, richiedono la creazione manuale degli oggetti nelle istanze secondarie che devono essere sincronizzati manualmente quando vengono apportate eventuali modifiche nell'istanza primaria. L'unica eccezione è la chiave master del servizio per un'istanza gestita di SQL replicata automaticamente nell’istanza secondaria durante la creazione di un gruppo di failover. Tutte le modifiche successive della chiave master del servizio nell'istanza primaria, tuttavia, non verranno replicate nell'istanza secondaria. Per altre informazioni, vedere Come abilitare scenari dipendenti da oggetti dai database di sistema.
- Per le istanze all'interno di un gruppo di failover, la modifica del livello di servizio verso o dal livello Utilizzo generico di nuova generazione non è supportata. È necessario eliminare il gruppo di failover prima di modificare una delle repliche e poi ricreare il gruppo di failover dopo l'applicazione della modifica.
- Le istanze gestite di SQL in un gruppo di failover devono avere gli stessi criteri di aggiornamento, anche se è possibile modificare i criteri di aggiornamento per le istanze all'interno di un gruppo di failover.
Gestione programmatica di gruppi di failover
I gruppi di failover possono anche essere gestiti a livello di codice usando Azure PowerShell, l'interfaccia della riga di comando di Azure e l'API REST. Le tabelle seguenti descrivono il set di comandi disponibili. I gruppi di failover includono un set di API di Azure Resource Manager per la gestione, compresa l'API REST del database SQL di Azure e i cmdlet di Azure PowerShell. Queste API richiedono l'uso di gruppi di risorse e supportano la sicurezza basata sui ruoli (Azure RBAC). Per ulteriori informazioni su come implementare i ruoli di accesso, vedere Controllo degli accessi in base al ruolo di Azure (Azure RBAC).
| Cmdlet | Descrizione |
|---|---|
| New-AzSqlDatabaseInstanceFailoverGroup | Questo comando crea un gruppo di failover e lo registra nell’istanza primaria e secondaria |
| Set-AzSqlDatabaseInstanceFailoverGroup | Modifica la configurazione di un gruppo di failover |
| Get-AzSqlDatabaseInstanceFailoverGroup | Recupera la configurazione di un gruppo di failover |
| Switch-AzSqlDatabaseInstanceFailoverGroup | Attiva il failover del gruppo di failover per l’istanza secondaria |
| Remove-AzSqlDatabaseInstanceFailoverGroup | Rimuove un gruppo di failover |