Affidabilità in Azure Data Factory

Questo articolo descrive il supporto per l'affidabilità in Azure Data Factory. Copre la resilienza all'interno dell'area tramite zone di disponibilità e distribuzioni in più aree.

L'affidabilità è una responsabilità condivisa tra l'utente e Microsoft. È possibile usare questa guida per scoprire quali opzioni di affidabilità soddisfano gli obiettivi aziendali e gli obiettivi di tempo di attività specifici.

È possibile usare Data Factory per creare pipeline di dati flessibili e potenti per l'integrazione dei dati serverless e la trasformazione dei dati. Di conseguenza, quando si definisce il piano di continuità aziendale per l'affidabilità, è necessario prendere in considerazione i requisiti di affidabilità e le indicazioni per:

• Pipeline di Data Factory.

• Runtime di integrazione (IR) che si connettono agli archivi dati ed eseguono attività definite nella pipeline.

• Archivi di dati che si connettono alla fabbrica di dati. Per garantire che gli archivi dati soddisfino i requisiti di continuità aziendale, consultare la documentazione e le indicazioni sull'affidabilità dei prodotti.

Panoramica dell'architettura di affidabilità

Data Factory è costituito da più componenti dell'infrastruttura. Ogni componente supporta l'affidabilità dell'infrastruttura in vari modi.

I componenti di Data Factory includono:

• Il servizio Di base di Data Factory, che gestisce i trigger della pipeline e supervisiona il coordinamento delle attività della pipeline. Il servizio principale gestisce anche i metadati per ogni componente nella data factory. Microsoft gestisce il servizio principale.

• Runtime di integrazione (IR) che eseguono attività specifiche della pipeline. Esistono tipi diversi di IR.

  • IR gestiti da Microsoft, che includono il runtime di integrazione di Azure e il runtime di integrazione Azure-SQL Server Integration Services (Azure-SSIS). Microsoft gestisce i componenti che costituiscono questi runtime. In alcuni scenari si configurano le impostazioni che influiscono sulla resilienza degli IR.

  • Runtime di integrazione self-hosted (SHIR). Microsoft fornisce software che è possibile eseguire nella propria infrastruttura di calcolo per eseguire alcune parti delle pipeline di Data Factory. Si è responsabili della distribuzione e della gestione delle risorse di calcolo e della resilienza di tali risorse di calcolo.

Errori temporanei

Gli errori temporanei sono errori brevi e intermittenti nei componenti. Si verificano spesso in un ambiente distribuito come il cloud e fanno parte delle normali operazioni. Si correggono dopo un breve periodo di tempo. È importante che le applicazioni gestisca gli errori temporanei, in genere ritentando le richieste interessate.

Tutte le applicazioni ospitate nel cloud devono seguire le linee guida per la gestione degli errori temporanei di Azure durante la comunicazione con qualsiasi API, database e altri componenti ospitati nel cloud. Per altre informazioni, vedere Raccomandazioni per la gestione di errori temporanei.

Quando si usa Data Factory, è importante prepararsi per gli errori temporanei, soprattutto quando si progettano pipeline e attività.

Idempotenza

Le attività della pipeline devono essere idempotenti, il che significa che possono essere rieseguite più volte senza causare effetti negativi. Se si verifica un errore temporaneo, ad esempio un errore di rete o un'interruzione della zona di disponibilità, Data Factory potrebbe eseguire nuovamente le attività della pipeline. Questa riesecuzione può creare record duplicati.

Per evitare l'inserimento di record duplicati a causa di un errore temporaneo, implementare le procedure consigliate seguenti:

• Usare identificatori univoci per ogni record prima di scrivere nel database. Questo approccio consente di trovare ed eliminare record duplicati.

• Usare una strategia upsert per i connettori che supportano upsert. Prima che si verifichi l'inserimento di record duplicati, usare questo approccio per verificare se esiste già un record. Se esiste, aggiornarlo. Se non esiste, inseriscilo. Ad esempio, i comandi SQL come MERGE o ON DUPLICATE KEY UPDATE usano questo approccio upsert.

• Usare strategie di azione di copia. Per altre informazioni, vedere Verifica della coerenza dei dati nell'attività di copia.

Criteri di ripetizione dei tentativi

È possibile usare i criteri di ripetizione dei tentativi per configurare parti della pipeline per riprovare in caso di problemi, ad esempio errori temporanei nelle risorse connesse. In Data Factory è possibile configurare i criteri di ripetizione dei tentativi nei tipi di oggetto pipeline seguenti:

• Trigger di finestra a cascata
• Attività di esecuzione

Per altre informazioni su come modificare o disabilitare i criteri di ripetizione per i trigger e le attività della Data Factory, vedere Esecuzioni e trigger della pipeline.

Supporto della zona di disponibilità

Le zone di disponibilità sono gruppi di data center separati fisicamente all'interno di ogni area di Azure. In caso di guasto in una zona, i servizi possono passare a una delle zone restanti.

Per altre informazioni sulle zone di disponibilità in Azure, vedere Che cosa sono le zone di disponibilità?

Data Factory supporta la ridondanza della zona, che offre resilienza agli errori nelle zone di disponibilità. Questa sezione descrive in che modo ogni parte del servizio Data Factory supporta la ridondanza della zona.

Regioni supportate

Le risorse di Data Factory a ridondanza di zona possono essere distribuite in qualsiasi area che supporta le zone di disponibilità.

Considerazioni

Servizio principale: Microsoft gestisce i componenti nel servizio Core Data Factory e li distribuisce tra le zone di disponibilità.

Runtime di integrazione (IR): Il supporto alla ridondanza regionale dipende dal tipo di runtime di integrazione che utilizzi.

• Un runtime di integrazione di Azure supporta la ridondanza zonale, e Microsoft gestisce questa funzionalità.

• Un Azure-SSIS IR richiede di distribuire almeno due nodi. Questi nodi vengono allocati automaticamente in zone di disponibilità diverse.

• Un shir assegna la responsabilità di implementare l'infrastruttura di calcolo per ospitare l'ambiente di esecuzione. È possibile distribuire più nodi, ad esempio singole macchine virtuali e configurarli per la disponibilità elevata. È quindi possibile distribuire tali nodi tra più zone di disponibilità. Per altre informazioni, vedere Disponibilità elevata e scalabilità.

Costo

Servizio principale: Non si applica alcun costo aggiuntivo per la ridondanza della zona.

IRs: Il costo della ridondanza della zona varia a seconda del tipo di IR che si utilizza.

• Un Azure IR include la ridondanza zonale senza costi aggiuntivi.

• Un Azure-SSIS IR richiede la distribuzione di almeno due nodi per ottenere la ridondanza di zona. Per altre informazioni sulla fatturazione di ogni nodo, vedere “Esempio di tariffazione: Eseguire pacchetti SSIS in un runtime di integrazione Azure-SSIS”.

• Un shir richiede la distribuzione e la gestione dell'infrastruttura di calcolo. Per ottenere la resilienza della zona, è necessario distribuire le risorse di calcolo tra più zone. A seconda del numero di nodi distribuiti e del modo in cui vengono configurati, è possibile che vengano addebitati costi aggiuntivi dai servizi di calcolo sottostanti e da altri servizi di supporto. Non è previsto alcun costo aggiuntivo per l'esecuzione della funzione SHIR in più nodi.

Configurare il supporto delle zone di disponibilità

Servizio principale: Nessuna configurazione necessaria. Il servizio core di Data Factory supporta automaticamente la ridondanza della zona.

Irs:

• Un runtime di integrazione di Azure: Nessuna configurazione necessaria. Il runtime di integrazione Azure IR abilita automaticamente la ridondanza delle zone.

• Un runtime di integrazione Azure-SSIS: Nessuna configurazione necessaria. Un runtime di integrazione Azure-SSIS abilita automaticamente la ridondanza zonale quando viene implementato con due o più istanze.

• Un shir richiede di configurare la propria resilienza, che include la distribuzione dei nodi tra più zone di disponibilità.

Pianificazione e gestione della capacità

Servizio principale: Il servizio core di Data Factory viene ridimensionato automaticamente in base alla richiesta e non è necessario pianificare o gestire la capacità.

Irs:

• Un IR di Azure viene ridimensionato automaticamente in base alla domanda e non è necessario pianificare o gestire la capacità.

• Un runtime di integrazione Azure-SSIS richiede di configurare in modo specifico il numero di nodi usati. Per prepararsi a un guasto della zona di disponibilità, prendere in considerazione un provisioning eccessivo della capacità del runtime di integrazione. Il provisioning eccessivo consente alla soluzione di tollerare un certo grado di perdita di capacità e continuare a funzionare senza prestazioni ridotte. Per ulteriori informazioni, vedere Gestire la capacità tramite sovraprovisionamento.

• A SHIR richiede di configurare la tua capacità e la scalabilità. Considerare il sovradimensionamento quando si distribuisce uno SHIR.

Operazioni normali

Routing del traffico tra zone: Durante le normali operazioni, Data Factory distribuisce automaticamente attività della pipeline, trigger e altri compiti tra istanze operative in ogni zona di disponibilità.

Esperienza di riduzione della zona

Rilevamento e risposta: La piattaforma Data Factory è responsabile del rilevamento di un errore in una zona di disponibilità e della risposta. Non è necessario eseguire alcuna operazione per avviare un failover di zona nelle pipeline o in altri componenti.

Richieste attive: Qualsiasi pipeline e trigger in corso continuano a essere eseguiti, e non subisci alcuna interruzione immediata da un errore di zona. Tuttavia, le attività in corso durante un errore di zona potrebbero fallire e essere riavviate. È importante progettare le attività come idempotenti, il che le aiuta a recuperare da guasti della zona e altri errori. Per altre informazioni, vedere Errori temporanei.

Ritornare alla situazione precedente

Quando la zona di disponibilità si riprende, Data Factory esegue automaticamente il failback verso la zona originale. Non è necessario eseguire alcuna operazione per avviare un failback di zona nelle pipeline o in altri componenti.

Tuttavia, se si usa un SHIR, potrebbe essere necessario riavviare le risorse di calcolo se sono state fermate.

Verifica dei guasti di zona

Per il servizio principale e per Azure e Azure-SSIS IR, Data Factory gestisce il routing del traffico, il failover e il failback per le risorse con ridondanza di zona. Poiché questa funzionalità è completamente gestita, non è necessario avviare o convalidare i processi di errore della zona di disponibilità.

Per SHIR, è possibile usare Azure Chaos Studio per simulare un errore della zona di disponibilità in una macchina virtuale di Azure.

Supporto multi-regionale

Le risorse di Data Factory vengono distribuite in una singola area di Azure. Se la regione diventa non disponibile, anche la fabbrica di dati non sarà disponibile. Esistono tuttavia approcci che è possibile usare per garantire la resilienza alle interruzioni dell'area. Questi approcci dipendono dal fatto che la data factory si trova in un'area abbinata o non abbinata e in base ai requisiti e alla configurazione specifici.

Failover gestito da Microsoft in un'area abbinata

Data Factory supporta il failover gestito da Microsoft per fabbriche di dati in regioni abbinate, ad eccezione del Sud del Brasile e del Sud-est asiatico. Nel caso improbabile di un errore di area prolungato, Microsoft potrebbe avviare un failover a livello di area dell'istanza di Data Factory.

A causa dei requisiti di residenza dei dati in Brasile meridionale e Asia sud-orientale, i dati di Data Factory vengono archiviati solo nell'area locale usando l'archiviazione con ridondanza della zona di Archiviazione di Azure. Per l'Asia sud-orientale, tutti i dati vengono archiviati a Singapore. Per il Brasile meridionale, tutti i dati vengono archiviati in Brasile.

Per le data factory in regioni non abbinate o in Brasile Sud o Asia sud-orientale, Microsoft non esegue il failover a livello regionale per voi.

Failover di IR

Per prepararsi a un failover, potrebbero esserci alcune considerazioni aggiuntive, a seconda del runtime di integrazione (IR) utilizzato.

• È possibile configurare il runtime di integrazione di Azure per determinare automaticamente l'area utilizzata. Se la regione è impostata per la risoluzione automatica e si verifica un'interruzione nella regione primaria, Azure IR esegue automaticamente il failover nella regione associata. Questo failover è soggetto a limitazioni. Per configurare l'area del runtime di integrazione di Azure per l'implementazione o l'invio dell'attività nell'installazione del runtime di integrazione, impostare l'area per la risoluzione automatica.

• Azure-SSIS IR failover del runtime di integrazione viene gestito separatamente da un failover della data factory gestito da Microsoft. Per altre informazioni, vedere Approcci alternativi per più aree.

• Un SHIR si esegue nell'infrastruttura per cui si è responsabili, quindi un failover gestito da Microsoft non si applica agli SHIR. Per altre informazioni, vedere Approcci alternativi per più aree.

Riconfigurazione post-failover

Al termine di un failover gestito da Microsoft, è possibile accedere alla pipeline di Data Factory nell'area abbinata. Tuttavia, al termine del failover, potrebbe essere necessario eseguire alcune riconfigurazioni per IR o altri componenti. Questo processo include il ristabilimento della configurazione di rete.

Approcci alternativi per più aree

Se è necessario che le pipeline siano resilienti alle interruzioni a livello di area ed è necessario controllare il processo di failover, prendere in considerazione l'uso di una pipeline basata sui metadati.

• Configurare il controllo del codice sorgente per Data Factory per tenere traccia e controllare le modifiche apportate ai metadati. È possibile usare questo approccio per accedere ai file JSON dei metadati per pipeline, set di dati, servizi collegati e trigger. Data Factory supporta diversi tipi di repository Git, ad esempio Azure DevOps e GitHub. Per altre informazioni, vedere Controllo del codice sorgente in Data Factory.

• Usare un sistema di integrazione continua e recapito continuo (CI/CD), ad esempio Azure DevOps, per gestire i metadati e le distribuzioni della pipeline. È possibile usare CI/CD per ripristinare rapidamente le operazioni su un'istanza in un'altra area. Se un'area non è disponibile, è possibile effettuare il provisioning di una nuova data factory manualmente o tramite l'automazione. Dopo aver creato la nuova data factory, è possibile ripristinare le pipeline, i set di dati e i servizi collegati JSON dal repository Git esistente. Per altre informazioni, vedere Continuità aziendale e ripristino di emergenza (BCDR) per data factory e pipeline di Azure Synapse Analytics.

A seconda dell'IR che usi, potrebbero esserci altre considerazioni.

• Un Azure-SSIS IR utilizza un database archiviato in Azure SQL Database o in Azure SQL Managed Instance. È possibile configurare la replica geografica o un gruppo di failover per questo database. Il database Azure-SSIS si trova in un'area primaria di Azure con accesso in lettura/scrittura. Il database viene replicato continuamente in un'area secondaria con accesso di sola lettura. Se l'area primaria non è disponibile, viene attivato un failover che causa lo scambio dei ruoli tra i database primari e secondari.

  È anche possibile configurare una coppia di runtime di integrazione dual standby di Azure SSIS che funziona in sincronia con un database SQL di Azure o un gruppo di failover di Istanza gestita di SQL Azure.

  Per ulteriori informazioni, vedere Configurare un Azure-SSIS IR per BCDR.

• A SHIR funziona sull'infrastruttura che gestisci. Se lo shir viene distribuito in una macchina virtuale di Azure, è possibile usare Azure Site Recovery per attivare il failover delle macchine virtuali in un'altra area.

Backup e ripristino

Data Factory supporta CI/CD tramite l'integrazione del controllo del codice sorgente, in modo da poter eseguire il backup dei metadati di un'istanza di Data Factory. Le pipeline CI/CD distribuiscono questi metadati senza problemi in un nuovo ambiente. Per altre informazioni, vedere CI/CD in Data Factory.

Contratto di servizio

Il contratto di servizio per Azure Data Factory descrive la disponibilità prevista del servizio. Questo accordo descrive inoltre le condizioni per soddisfare le aspettative. Per comprendere queste condizioni, assicurarsi di esaminare i contratti di servizio per i servizi online.

Contenuti correlati

• Affidabilità in Azure