Configurare il runtime di integrazione SSIS di Azure per la continuità aziendale e il ripristino di emergenza (BCDR)

SI APPLICA A: Azure Data Factory Azure Synapse Analytics

Suggerimento

Provare Data Factory in Microsoft Fabric, una soluzione di analisi completa per le aziende. Microsoft Fabric copre tutti gli elementi, dallo spostamento dei dati all'analisi scientifica dei dati, all'analisi in tempo reale, alla business intelligence e alla creazione di report. Scopri come avviare gratuitamente una nuova versione di valutazione .

database SQL di Azure/Istanza gestita e SQL Server Integration Services (SSIS) in Azure Data Factory (ADF) o nelle pipeline Synapse possono essere combinate come soluzione paaS (All-Platform as a Service) consigliata per la migrazione di SQL Server. È possibile distribuire i progetti SSIS nel database del catalogo SSIS (SSISDB) ospitato da database SQL di Azure/Istanza gestita ed eseguire i pacchetti SSIS in Azure SSIS Integration Runtime (IR) in ADF o Nelle pipeline di Synapse.

Per la continuità aziendale e il ripristino di emergenza (BCDR), è possibile configurare database SQL di Azure/Istanza gestita con un gruppo di replica geografica/failover, in cui SSISDB in un'area primaria di Azure con accesso in lettura/scrittura (ruolo primario) verrà replicato in modo continuo in un'area secondaria con accesso in sola lettura (ruolo secondario). Quando si verifica un'emergenza nell'area primaria, verrà attivato un failover, in cui i database SSISDB primari e secondari scambieranno i ruoli.

Per BCDR, è anche possibile configurare una coppia di runtime di integrazione SSIS di Azure dual standby che funziona in sincronizzazione con database SQL di Azure/Istanza gestita gruppo di failover. In questo modo è possibile avere una coppia di IR Azure-SSIS in esecuzione che in qualsiasi momento, solo uno può accedere al database SSISDB primario per recuperare ed eseguire pacchetti, nonché scrivere log di esecuzione dei pacchetti (ruolo primario), mentre l'altro può fare lo stesso solo per i pacchetti distribuiti altrove, ad esempio in File di Azure (ruolo secondario). Quando si verifica il failover di SSISDB, anche i ruoli IR di Azure-SSIS primario e secondario scambiano i ruoli e, se entrambi sono in esecuzione, si verifica un tempo di inattività quasi zero.

Questo articolo descrive come configurare Azure-SSIS IR con database SQL di Azure/Istanza gestita gruppo di failover per BCDR.

Configurare una coppia di runtime di integrazione Azure-SSIS dual standby con database SQL di Azure gruppo di failover

Per configurare una coppia di runtime di integrazione Azure-SSIS dual standby che funziona in sincronizzazione con database SQL di Azure gruppo di failover, completare la procedura seguente.

  1. Usando portale di Azure/interfaccia utente di Azure Data Factory, è possibile creare un nuovo runtime di integrazione Azure-SSIS con il server database SQL di Azure primario per ospitare SSISDB nell'area primaria. Se si dispone di un runtime di integrazione Azure-SSIS già collegato a SSIDB ospitato dal server primario database SQL di Azure ed è ancora in esecuzione, è necessario arrestarlo per prima cosa per riconfigurarlo. Si tratta del runtime di integrazione Azure-SSIS primario.

    Quando si seleziona per usare SSISDB nella pagina Impostazioni di distribuzione del riquadro Configurazione del runtime di integrazione, selezionare anche la casella di controllo Usa coppia di runtime di integrazione SSIS SSIS con dual standby con failover SSISDB. Per Dual standby pair name (Nome coppia standby doppio) immettere un nome per identificare la coppia di IR primari e secondari di Azure-SSIS. Al termine della creazione del runtime di integrazione Azure-SSIS primario, verrà avviato e collegato a un database SSISDB primario che verrà creato per conto dell'utente con accesso in lettura/scrittura. Se è stata appena riconfigurata, è necessario riavviarla.

  2. Usando portale di Azure, è possibile verificare se il database SSISDB primario è stato creato nella pagina Panoramica del server primario database SQL di Azure. Dopo la creazione, è possibile creare un gruppo di failover per i server di database SQL di Azure primario e secondario e aggiungerlo al database nella pagina Gruppi di failover. Dopo aver creato il gruppo di failover, è possibile verificare se il database SSISDB primario è stato replicato in un database secondario con accesso in sola lettura nella pagina Panoramica del server di database SQL di Azure secondario.

  3. Usando portale di Azure/interfaccia utente di Azure Data Factory, è possibile creare un altro runtime di integrazione Azure-SSIS con il server di database SQL di Azure secondario per ospitare SSISDB nell'area secondaria. Si tratta del runtime di integrazione Azure-SSIS secondario. Per il ripristino di emergenza completo, assicurarsi che tutte le risorse da cui dipende vengano create anche nell'area secondaria, ad esempio Archiviazione di Azure per l'archiviazione di script/file di installazione personalizzati, ADF per le esecuzioni di pacchetti di orchestrazione/pianificazione e così via.

    Quando si seleziona per usare SSISDB nella pagina Impostazioni di distribuzione del riquadro Configurazione del runtime di integrazione, selezionare anche la casella di controllo Usa coppia di runtime di integrazione SSIS SSIS con dual standby con failover SSISDB. Per Dual standby pair name (Nome coppia standby doppio) immettere lo stesso nome per identificare la coppia di IR di Azure-SSIS primari e secondari. Al termine della creazione del runtime di integrazione Azure-SSIS secondario, verrà avviato e collegato al database SSISDB secondario.

  4. Se si vuole avere un tempo di inattività quasi zero quando si verifica il failover di SSISDB, mantenere in esecuzione entrambe le operazioni di IRS SSIS di Azure. Solo il runtime di integrazione Azure-SSIS primario può accedere al database SSISDB primario per recuperare ed eseguire pacchetti, nonché scrivere i log di esecuzione dei pacchetti, mentre il runtime di integrazione Azure-SSIS secondario può eseguire le stesse operazioni solo per i pacchetti distribuiti altrove, ad esempio in File di Azure.

    Se si vuole ridurre al minimo i costi in esecuzione, è possibile arrestare il runtime di integrazione Azure-SSIS secondario dopo la creazione. Quando si verifica il failover di SSISDB, i ruoli di ripristino SSIS primario e secondario di Azure-SSIS verranno scambiati. Se il runtime di integrazione Azure-SSIS primario viene arrestato, è necessario riavviarlo. A seconda che venga inserito in una rete virtuale e il metodo di inserimento usato, l'operazione richiederà entro 5 minuti o circa 20 - 30 minuti per l'esecuzione.

  5. Se si usa Azure Data Factory per le esecuzioni di pacchetti di orchestrazione/pianificazione, assicurarsi che tutte le pipeline di Azure Data Factory pertinenti con le attività Esegui pacchetto SSIS e i trigger associati vengano copiati in ADF secondario con i trigger inizialmente disabilitati. Quando si verifica il failover di SSISDB, è necessario abilitarli.

  6. È possibile testare il gruppo di failover di database SQL di Azure e controllare nella pagina di monitoraggio di Azure-SSIS IR nel portale di Azure Data Factory se le richieste di integrazione Azure-SSIS primarie e secondarie hanno ruoli scambiati.

Configurare una coppia di runtime di integrazione Azure-SSIS dual standby con Istanza gestita di SQL di Azure gruppo di failover

Per configurare una coppia di runtime di integrazione Azure-SSIS dual standby che funziona in sincronizzazione con Istanza gestita di SQL di Azure gruppo di failover, completare i passaggi seguenti.

  1. Usando portale di Azure, è possibile creare un gruppo di failover per le Istanza gestita di SQL di Azure primarie e secondarie nella pagina Gruppi di failover del Istanza gestita di SQL di Azure primario.

  2. Usando portale di Azure/interfaccia utente di Azure Data Factory, è possibile creare un nuovo runtime di integrazione Azure-SSIS con il Istanza gestita di SQL di Azure primario per ospitare SSISDB nell'area primaria. Se si dispone di un runtime di integrazione Azure-SSIS già collegato a SSIDB ospitato dall'Istanza gestita di SQL di Azure primario ed è ancora in esecuzione, è necessario arrestarlo prima per riconfigurarlo. Si tratta del runtime di integrazione Azure-SSIS primario.

    Quando si seleziona per usare SSISDB nella pagina Impostazioni di distribuzione del riquadro Configurazione del runtime di integrazione, selezionare anche la casella di controllo Usa coppia di runtime di integrazione SSIS SSIS con dual standby con failover SSISDB. Per Dual standby pair name (Nome coppia standby doppio) immettere un nome per identificare la coppia di IR primari e secondari di Azure-SSIS. Al termine della creazione del runtime di integrazione Azure-SSIS primario, verrà avviato e collegato a un database SSISDB primario che verrà creato per conto dell'utente con accesso in lettura/scrittura. Se è stata appena riconfigurata, è necessario riavviarla. È anche possibile verificare se il database SSISDB primario è stato replicato in un database secondario con accesso in sola lettura nella pagina Panoramica del Istanza gestita di SQL di Azure secondario.

  3. Usando portale di Azure/interfaccia utente di Azure Data Factory, è possibile creare un altro runtime di integrazione Azure-SSIS con il Istanza gestita di SQL di Azure secondario per ospitare SSISDB nell'area secondaria. Si tratta del runtime di integrazione Azure-SSIS secondario. Per il ripristino di emergenza completo, assicurarsi che tutte le risorse da cui dipende vengano create anche nell'area secondaria, ad esempio Archiviazione di Azure per l'archiviazione di script/file di installazione personalizzati, ADF per le esecuzioni di pacchetti di orchestrazione/pianificazione e così via.

    Quando si seleziona per usare SSISDB nella pagina Impostazioni di distribuzione del riquadro Configurazione del runtime di integrazione, selezionare anche la casella di controllo Usa coppia di runtime di integrazione SSIS SSIS con dual standby con failover SSISDB. Per Dual standby pair name (Nome coppia standby doppio) immettere lo stesso nome per identificare la coppia di IR di Azure-SSIS primari e secondari. Al termine della creazione del runtime di integrazione Azure-SSIS secondario, verrà avviato e collegato al database SSISDB secondario.

  4. Istanza gestita di SQL di Azure possibile proteggere i dati sensibili nei database, ad esempio SSISDB, crittografandoli usando la chiave master del database (DMK). DMK stesso è a sua volta crittografato usando la chiave master del servizio (SMK) per impostazione predefinita. A partire da settembre 2021, SMK viene replicato dal Istanza gestita di SQL di Azure primario a quello secondario durante la creazione del gruppo di failover. Se il gruppo di failover è stato creato in precedenza, eliminare tutti i database utente, incluso SSISDB, dal Istanza gestita di SQL di Azure secondario e ricreare il gruppo di failover.

  5. Se si vuole avere un tempo di inattività quasi zero quando si verifica il failover di SSISDB, mantenere in esecuzione entrambe le operazioni di IRS SSIS di Azure. Solo il runtime di integrazione Azure-SSIS primario può accedere al database SSISDB primario per recuperare ed eseguire pacchetti, nonché scrivere i log di esecuzione dei pacchetti, mentre il runtime di integrazione Azure-SSIS secondario può eseguire le stesse operazioni solo per i pacchetti distribuiti altrove, ad esempio in File di Azure.

    Se si vuole ridurre al minimo i costi in esecuzione, è possibile arrestare il runtime di integrazione Azure-SSIS secondario dopo la creazione. Quando si verifica il failover di SSISDB, i ruoli di ripristino SSIS primario e secondario di Azure-SSIS verranno scambiati. Se il runtime di integrazione Azure-SSIS primario viene arrestato, è necessario riavviarlo. A seconda che venga inserito in una rete virtuale e il metodo di inserimento usato, l'operazione richiederà entro 5 minuti o circa 20 - 30 minuti per l'esecuzione.

  6. Se si usa Istanza gestita di SQL di Azure Agent per le esecuzioni di pacchetti di orchestrazione/pianificazione, assicurarsi che tutti i processi SSIS pertinenti con i relativi passaggi di processo e le pianificazioni associate vengano copiati nella Istanza gestita di SQL di Azure secondaria con le pianificazioni inizialmente disabilitate. Usando SSMS, completare la procedura seguente.

    1. Per ogni processo SSIS, fare clic con il pulsante destro del mouse e selezionare le voci di menu a discesa Script Job as, CREATE To e New Editor di query Window per generare il relativo script.

      Generate SSIS job script

    2. Per ogni script di processo SSIS generato, trovare il comando per eseguire sp_add_job la stored procedure e modificare/rimuovere l'assegnazione di valore all'argomento in base alle @owner_login_name esigenze.

    3. Per ogni script di processo SSIS aggiornato, eseguirlo nel Istanza gestita di SQL di Azure secondario per copiare il processo con i passaggi del processo e le pianificazioni associate.

    4. Usando lo script seguente, creare un nuovo processo T-SQL per abilitare/disabilitare le pianificazioni dei processi SSIS in base al ruolo SSISDB primario/secondario, rispettivamente, nei Istanza gestita di SQL di Azure primario e secondario ed eseguirlo regolarmente. Quando si verifica il failover di SSISDB, le pianificazioni dei processi SSIS disabilitate verranno abilitate e viceversa.

      IF (SELECT Top 1 role_desc FROM SSISDB.sys.dm_geo_replication_link_status WHERE partner_database = 'SSISDB') = 'PRIMARY'
         BEGIN
            IF (SELECT enabled FROM msdb.dbo.sysschedules WHERE schedule_id = <ScheduleID>) = 0
               EXEC msdb.dbo.sp_update_schedule @schedule_id = <ScheduleID >, @enabled = 1
         END
      ELSE
         BEGIN
            IF (SELECT enabled FROM msdb.dbo.sysschedules WHERE schedule_id = <ScheduleID>) = 1
               EXEC msdb.dbo.sp_update_schedule @schedule_id = <ScheduleID >, @enabled = 0
         END
      
  7. Se si usa Azure Data Factory per le esecuzioni di pacchetti di orchestrazione/pianificazione, assicurarsi che tutte le pipeline di Azure Data Factory pertinenti con le attività Esegui pacchetto SSIS e i trigger associati vengano copiati in ADF secondario con i trigger inizialmente disabilitati. Quando si verifica il failover di SSISDB, è necessario abilitarli.

  8. È possibile testare il gruppo di failover Istanza gestita di SQL di Azure e controllare nella pagina di monitoraggio di Azure-SSIS IR nel portale di Azure Data Factory se le richieste di integrazione Azure-SSIS primarie e secondarie hanno ruoli scambiati.

Collegare un nuovo runtime di integrazione Azure-SSIS a SSISDB esistente ospitato da database SQL di Azure/Istanza gestita

Se si verifica un'emergenza e influisce sul runtime di integrazione Azure-SSIS esistente ma non database SQL di Azure/Istanza gestita nella stessa area, è possibile sostituirlo con uno nuovo in un'altra area. Per collegare il database SSISDB esistente ospitato da database SQL di Azure/Istanza gestita a un nuovo runtime di integrazione Azure-SSIS, seguire questa procedura.

  1. Se il runtime di integrazione Azure-SSIS esistente è ancora in esecuzione, è necessario arrestarlo prima usando portale di Azure/interfaccia utente di Azure Data Factory o Azure PowerShell. Se l'emergenza influisce anche su ADF nella stessa area, è possibile ignorare questo passaggio.

  2. Usando SSMS, eseguire il comando seguente per SSISDB nel database SQL di Azure/Istanza gestita per aggiornare i metadati che consentiranno le connessioni dal nuovo runtime di integrazione ADF/Azure-SSIS.

    EXEC [catalog].[failover_integration_runtime] @data_factory_name = 'YourNewADF', @integration_runtime_name = 'YourNewAzureSSISIR'
    
  3. Usando portale di Azure/interfaccia utente di Azure Data Factory o Azure PowerShell, creare rispettivamente il nuovo runtime di integrazione ADF/Azure-SSIS denominato YourNewADF/YourNewAzureSSISIR in un'altra area. Se si usa portale di Azure/interfaccia utente di Azure Data Factory, è possibile ignorare l'errore di connessione di test nella pagina Impostazioni di distribuzione del riquadro Configurazione del runtime di integrazione.

È possibile prendere in considerazione queste altre opzioni di configurazione per azure-SSIS IR: