L’Integration Runtime (IR) è l’infrastruttura di calcolo che Azure Data Factory (e le pipeline di Azure Synapse Analytics) usa per eseguire concretamente il lavoro: movimento dati, dispatch delle activity di trasformazione ed esecuzione dei pacchetti SSIS. Capire quale IR scegliere e dove gira davvero il data movement è una delle competenze più testate del dominio ingestion del DP-203.
I tre tipi di Integration Runtime
Azure IR
L’Azure IR è completamente gestito, serverless e con autoscaling. Si occupa di:
- Copy activity tra data store raggiungibili dal cloud pubblico.
- Dispatch delle activity di trasformazione esterne (Databricks, HDInsight, stored procedure).
- Esecuzione dei Mapping Data Flow, che girano su cluster Apache Spark provisionati on-demand.
La sua region può essere in auto-resolve (Data Factory sceglie una region vicina al sink) oppure fissata esplicitamente per motivi di data residency e compliance. In configurazione Managed VNet, l’Azure IR raggiunge sorgenti private tramite managed private endpoint, senza gestire tu la rete.
Self-hosted IR (SHIR)
Il Self-hosted IR è un agente che installi su una macchina on-premises o su una VM in una VNet. È obbligatorio quando la sorgente o la destinazione è:
- on-premises (SQL Server locale, file share, Oracle);
- dentro una VNet o una rete privata non raggiungibile dal cloud pubblico;
- dietro un firewall o accessibile solo via private endpoint su rete non gestita.
Punto chiave d’esame: con il SHIR il data movement gira fisicamente sul nodo self-hosted, usando la sua CPU, RAM e connettività. Il SHIR richiede solo traffico HTTPS in uscita sulla porta 443 verso Azure: non serve aprire porte inbound. Un singolo SHIR può inoltre essere condiviso tra più Data Factory.
Azure-SSIS IR
L’Azure-SSIS IR è un cluster gestito di VM Azure dedicato all’esecuzione di pacchetti SSIS esistenti: è lo strumento di lift & shift per portare in cloud carichi SSIS on-premises senza riscriverli. Configuri node size e node count in base al carico, e puoi farlo joinare a una VNet per raggiungere sorgenti on-premises o private durante l’esecuzione dei pacchetti.
Come scegliere
| Scenario | IR corretto |
|---|---|
| Copy cloud-to-cloud, Data Flow | Azure IR |
| Sorgente on-premises / dietro firewall / VNet privata | Self-hosted IR |
| Migrazione di pacchetti SSIS esistenti | Azure-SSIS IR |
| Data residency stringente | Azure IR con region fissata |
High availability e requisiti di rete
Il SHIR è il punto in cui si concentrano le domande su affidabilità:
- Supporta fino a 4 nodi in configurazione scale-out + high availability. Il primo nodo è il primary e coordina la sincronizzazione delle credenziali.
- Con un solo nodo hai un single point of failure: per HA servono almeno 2 nodi.
- Tutti i nodi devono poter comunicare tra loro ed essere sulla stessa versione; le credenziali dei linked service sono cifrate localmente e sincronizzate tra i nodi.
- Per l’esecuzione concorrente si dimensiona in base ai concurrent jobs supportati dai nodi.
Trappole tipiche d’esame
- Scenario: devi copiare da un SQL Server on-premises verso Azure Data Lake. Risposta giusta: serve un Self-hosted IR; il data movement gira sul nodo SHIR, non sull’Azure IR, anche se la destinazione è cloud.
- Scenario: un Mapping Data Flow deve trasformare dati che risiedono on-premises. Risposta giusta: i Data Flow girano solo su Azure IR (Spark) e non possono usare direttamente un linked service basato su SHIR: prima stagi i dati in Azure con una Copy activity via SHIR, poi applichi il Data Flow.
- Scenario: devi garantire continuità del data movement on-premises. Risposta giusta: installa almeno 2 nodi SHIR (fino a 4) per high availability e scale-out; un nodo singolo non è HA.
- Scenario: il security team chiede di non aprire porte in ingresso. Risposta giusta: il SHIR usa solo HTTPS/443 in uscita; nessuna porta inbound va aperta.
- Scenario: hai pacchetti SSIS legacy da eseguire in Azure senza riscriverli, ma con accesso a dati on-premises. Risposta giusta: usa un Azure-SSIS IR joinato a una VNet, non un Self-hosted IR generico.