Metodo standard di inserimento della rete virtuale

SI APPLICA A: Azure Data Factory Azure Synapse Analytics

Suggerimento

Provare Data Factory in Microsoft Fabric, una soluzione di analisi all-in-one per le aziende. Microsoft Fabric copre tutto, dallo spostamento dati al data science, all'analisi in tempo reale, alla business intelligence e alla creazione di report. Vedere le informazioni su come iniziare una nuova prova gratuita!

Quando si usa SQL Server Integration Services (SSIS) in Azure Data Factory (ADF) o nelle pipeline Synapse, sonoq disponibili due metodi per aggiungere Azure-SSIS Integration Runtime a una rete virtuale: standard ed express. Se si usa il metodo standard, è necessario configurare la rete virtuale per soddisfare questi requisiti:

• Assicurarsi che Microsoft.Batch sia un provider di risorse registrato nella sottoscrizione di Azure con la rete virtuale per l'aggiunta del runtime di integrazione Azure-SSIS. Per istruzioni dettagliate, vedere la sezione Registrare Azure Batch come provider di risorse .

• Assicurarsi che all'utente che crea Azure-SSIS IR siano concesse le autorizzazioni necessarie per il controllo degli accessi in base al ruolo per l'aggiunta alla rete virtuale o alla subnet. Per altre informazioni, vedere la sezione Selezionare le autorizzazioni di rete virtuale di seguito.

• Selezionare una subnet appropriata nella rete virtuale per aggiungere il runtime di integrazione Azure-SSIS. Per altre informazioni, vedere la sezione Selezionare una subnet di seguito.

A seconda dello scenario specifico, è possibile configurare facoltativamente quanto segue:

• Se si vogliono usare indirizzi IP pubblici statici (BYOIP) per il traffico in uscita del runtime di integrazione Azure-SSIS, vedere la sezione Configurare indirizzi IP pubblici statici di seguito.

• Se si vuole usare il proprio server DNS (Domain Name System) nella rete virtuale, vedere la sezione Configurare un server DNS personalizzato di seguito.

• Se si vuole usare un gruppo di sicurezza di rete (NSG) per limitare il traffico in ingresso/in uscita nella subnet, vedere la sezione Configurare un gruppo di sicurezza di rete di seguito.

• Se si vogliono usare route definite dall'utente per controllare/controllare il traffico in uscita, vedere la sezione Configurare le route definite dall'utente di seguito.

• Assicurarsi che il gruppo di risorse della rete virtuale (o il gruppo di risorse degli indirizzi IP pubblici se si usa un proprio indirizzo IP pubblico) possa creare ed eliminare determinate risorse di rete di Azure. Per altre informazioni, vedere Configurare il gruppo di risorse pertinente.

• Se si personalizza azure-SSIS IR come descritto nell'articolo Configurazione personalizzata per Azure-SSIS IR , il processo interno per gestire i nodi utilizzerà indirizzi IP privati da un intervallo predefinito compreso tra 172.16.0.0 e 172.31.255.255. Di conseguenza, assicurarsi che gli intervalli di indirizzi IP privati delle reti virtuali e locali non siano in conflitto con questo intervallo.

Questo diagramma mostra le connessioni necessarie per il runtime di integrazione Azure-SSIS:

Selezionare le autorizzazioni di rete virtuale

Per abilitare l'inserimento di reti virtuali standard, all'utente che crea Azure-SSIS IR deve essere concessa le autorizzazioni di controllo degli accessi in base al ruolo necessarie per l'aggiunta alla rete virtuale o alla subnet.

• Se si aggiunge il runtime di integrazione Azure-SSIS a una rete virtuale di Azure Resource Manager, sono disponibili due opzioni:

  • Usare il ruolo predefinito Collaboratore di rete. Questo ruolo include l'autorizzazione Microsoft.Network/* che ha un ambito molto più ampio del necessario.

  • Creare un ruolo personalizzato che includa solo l'autorizzazione Microsoft.Network/virtualNetworks/*/join/action necessaria. Se si vuole anche usare indirizzi IP pubblici statici per Azure-SSIS IR durante l'aggiunta a una rete virtuale di Azure Resource Manager, includere anche l'autorizzazione Microsoft.Network/publicIPAddresses/*/join/action nel ruolo.

  • Per istruzioni dettagliate, vedere la sezione Concedere le autorizzazioni di rete virtuale.

• Se si aggiunge il runtime di integrazione Azure-SSIS a una rete virtuale classica, è consigliabile usare il ruolo Collaboratore macchina virtuale classica predefinito. In caso contrario, è necessario creare un ruolo personalizzato che includa l'autorizzazione per l'aggiunta alla rete virtuale. È anche necessario assegnare MicrosoftAzureBatch a tale ruolo predefinito/personalizzato.

Selezionare una subnet

Per abilitare l'inserimento di reti virtuali standard, è necessario selezionare una subnet appropriata per l'aggiunta del runtime di integrazione Azure-SSIS:

• Non selezionare GatewaySubnet, perché è dedicato per i gateway di rete virtuale.

• Assicurarsi che la subnet selezionata abbia indirizzi IP disponibili per almeno due volte il numero del nodo azure-SSIS IR. Questi sono necessari per evitare interruzioni durante l'implementazione di patch/aggiornamenti per il runtime di integrazione Azure-SSIS. Azure riserva anche alcuni indirizzi IP che non possono essere usati in ogni subnet. Il primo e l'ultimo indirizzo IP sono riservati per la conformità del protocollo, mentre altri tre indirizzi sono riservati per i servizi di Azure. Per altre informazioni, vedere la sezione Restrizioni relative agli indirizzi IP della subnet.

• Non usare una subnet occupata esclusivamente da altri servizi di Azure, ad esempio Istanza gestita di SQL di Azure, servizio app e così via.

Configurare indirizzi IP pubblici statici

Se si vogliono usare indirizzi IP pubblici statici personalizzati per il traffico in uscita di Azure-SSIS IR durante l'aggiunta a una rete virtuale, in modo da consentirli nei firewall, assicurarsi che soddisfino i requisiti seguenti:

• Devono essere forniti esattamente due non usati che non sono già associati ad altre risorse di Azure. Il componente aggiuntivo verrà usato quando si aggiorna periodicamente il runtime di integrazione Azure-SSIS. Si noti che non è possibile condividere un indirizzo IP pubblico tra le richieste di integrazione di Azure-SSIS attive.

• Devono essere entrambi statici di tipo standard. Per altri dettagli, vedere la sezione SKU dell'indirizzo IP pubblico.

• Devono avere entrambi un nome DNS. Se non è stato specificato un nome DNS durante la creazione, è possibile farlo su portale di Azure.

  

• E la rete virtuale devono trovarsi nella stessa sottoscrizione e nella stessa area.

Configurare un server DNS personalizzato

Se si vuole usare il proprio server DNS nella rete virtuale per risolvere i nomi host privati, assicurarsi che possa risolvere anche i nomi host globali di Azure( ad esempio, il Archiviazione BLOB di Azure denominato <your storage account>.blob.core.windows.).

È consigliabile configurare il proprio server DNS per inoltrare richieste DNS non risolte all'indirizzo IP dei resolver ricorsivi di Azure (168.63.129.16).

Per altre informazioni, vedere la sezione Risoluzione dei nomi del server DNS.

Nota

Usare un nome di dominio completo (FQDN) per il nome host privato, ad esempio usare <your_private_server>.contoso.com anziché <your_private_server>. In alternativa, è possibile usare una configurazione personalizzata standard nel runtime di integrazione Azure-SSIS per aggiungere automaticamente il proprio suffisso DNS (ad esempio contoso.com) a qualsiasi nome di dominio di etichetta singola non qualificato e trasformarlo in un nome di dominio completo prima di usarlo nelle query DNS, vedere la sezione Standard custom setup samples (Esempi di installazione personalizzata standard).

Configurare un gruppo di sicurezza di rete

Se si vuole usare un gruppo di sicurezza di rete nella subnet aggiunta dal runtime di integrazione Azure-SSIS, consentire il traffico in ingresso e in uscita seguente:

Direction	Protocollo di trasporto	Origine	Porte di origine	Destinazione	Porte di destinazione	Commenti
In entrata	TCP	BatchNodeManagement	*	VirtualNetwork	29876, 29877 (se si aggiunge il runtime di integrazione SSIS a una rete virtuale di Azure Resource Manager) 10100, 20100, 30100 (se si aggiunge il runtime di integrazione SSIS a una rete virtuale classica)	Il servizio Data Factory usa queste porte per comunicare con i nodi azure-SSIS IR nella rete virtuale. Indipendentemente dal fatto che si crei un gruppo di sicurezza di rete nella subnet, Data Factory configura sempre un gruppo di sicurezza di rete nella scheda di interfaccia di rete collegata alle macchine virtuali che ospitano il runtime di integrazione Azure-SSIS. Solo il traffico in ingresso dagli indirizzi IP di Data Factory sulle porte specificate è consentito dal gruppo di sicurezza di rete a livello di scheda di interfaccia di rete. Anche se si aprono queste porte al traffico Internet a livello di subnet, il traffico proveniente da indirizzi IP che non sono indirizzi IP di Data Factory è ancora bloccato a livello di scheda di interfaccia di rete.
In entrata	TCP	CorpNetSaw	*	VirtualNetwork	3389	(Facoltativo) Richiesto solo quando un tecnico del supporto Microsoft chiede di aprire la porta 3389 per la risoluzione dei problemi avanzata e può essere chiuso subito dopo la risoluzione dei problemi. Il tag del servizio CorpNetSaw consente solo ai computer workstation di accesso sicuro (SAW) nella rete aziendale Microsoft di accedere al runtime di integrazione Azure-SSIS tramite RDP (Remote Desktop Protocol). Questo tag di servizio non può essere selezionato da portale di Azure ed è disponibile solo tramite Azure PowerShell/interfaccia della riga di comando. Nel gruppo di sicurezza di rete a livello di scheda di interfaccia di rete la porta 3389 è aperta per impostazione predefinita, ma è possibile controllarla con un gruppo di sicurezza di rete a livello di subnet, mentre il traffico in uscita su di esso non è consentito per impostazione predefinita nei nodi del runtime di integrazione Azure-SSIS usando la regola di Windows Firewall.

Direction	Protocollo di trasporto	Origine	Porte di origine	Destinazione	Porte di destinazione	Commenti
In uscita	TCP	VirtualNetwork	*	AzureCloud	443	Obbligatorio per l'accesso al runtime di integrazione SSIS di Azure, ad esempio Archiviazione di Azure e Hub eventi di Azure.
In uscita	TCP	VirtualNetwork	*	Internet	80	(Facoltativo) Il runtime di integrazione Azure-SSIS usa questa porta per scaricare un elenco di revoche di certificati (CRL) da Internet. Se si blocca questo traffico, è possibile che si verifichi una riduzione delle prestazioni quando si avvia azure-SSIS IR e si perde la capacità di controllare i CRL quando si usano i certificati, che non è consigliabile dal punto di sicurezza. Per limitare le destinazioni a determinati nomi di dominio completi, vedere la sezione Configurare le route definite dall'utente di seguito
In uscita	TCP	VirtualNetwork	*	Sql/VirtualNetwork	1433, 11000-11999	(Facoltativo) Obbligatorio solo se si usa database SQL di Azure server/Istanza gestita per ospitare il catalogo SSIS (SSISDB). Se l'database SQL di Azure server/Istanza gestita è configurato con un endpoint pubblico o un endpoint servizio di rete virtuale, usare il tag del servizio Sql come destinazione. Se il server/Istanza gestita database SQL di Azure è configurato con un endpoint privato, usare il tag del servizio VirtualNetwork come destinazione. Se i criteri di connessione del server sono impostati su Proxy invece di Reindirizzamento, è necessaria solo la porta 1433 .
In uscita	TCP	VirtualNetwork	*	Archiviazione/Rete virtuale	443	(Facoltativo) Obbligatorio solo se si usa Archiviazione di Azure contenitore BLOB per archiviare lo script o i file di installazione personalizzati standard. Se il Archiviazione di Azure è configurato con un endpoint pubblico o un endpoint servizio di rete virtuale, usare il tag del servizio di archiviazione come destinazione. Se il Archiviazione di Azure è configurato con un endpoint privato, usare il tag del servizio VirtualNetwork come destinazione.
In uscita	TCP	VirtualNetwork	*	Archiviazione/Rete virtuale	445	(Facoltativo) Obbligatorio solo se è necessario accedere alle File di Azure. Se il Archiviazione di Azure è configurato con un endpoint pubblico o un endpoint servizio di rete virtuale, usare il tag del servizio di archiviazione come destinazione. Se il Archiviazione di Azure è configurato con un endpoint privato, usare il tag del servizio VirtualNetwork come destinazione.

Configurare le route definite dall'utente

Se si vuole controllare o controllare il traffico in uscita dal runtime di integrazione Azure-SSIS, è possibile usare route definite dall'utente (UDR) per reindirizzarlo a un'appliance firewall locale tramite il tunneling forzato di Azure ExpressRoute che annuncia una route BGP (Border Gateway Protocol) 0.0.0.0/0 alla rete virtuale, a un'appliance virtuale di rete (NVA) configurata come firewall o per Firewall di Azure servizio.

Per renderlo funzionante, è necessario assicurarsi quanto segue:

• Il traffico tra il servizio di gestione di Azure Batch e il runtime di integrazione Azure-SSIS non deve essere instradato a un'appliance/servizio firewall.

• L'appliance/servizio firewall deve consentire il traffico in uscita richiesto da Azure-SSIS IR.

Se il traffico tra il servizio di gestione di Azure Batch e il runtime di integrazione Azure-SSIS viene instradato a un'appliance/servizio firewall, verrà interrotto a causa del routing asimmetrico. Le route definite dall'utente devono essere definite per questo traffico, in modo che possano passare attraverso le stesse route in cui è arrivato. È possibile configurare le route definite dall'utente per instradare il traffico tra il servizio di gestione di Azure Batch e il runtime di integrazione Azure-SSIS con il tipo di hop successivo come Internet.

Ad esempio, se il runtime di integrazione Azure-SSIS si trova nel Regno Unito meridionale e si vuole esaminare il traffico in uscita usando Firewall di Azure, è prima possibile ottenere gli intervalli IP per il tag del servizio BatchNodeManagement.UKSouth dal collegamento di download dell'intervallo IP tag del servizio o dall'API di individuazione tag del servizio. È quindi possibile configurare le route definite dall'utente seguenti per le route dell'intervallo IP pertinenti con il tipo di hop successivo come Internet e la route 0.0.0.0/0 con il tipo di hop successivo come appliance virtuale.

Nota

Questo approccio comporta un costo aggiuntivo per la manutenzione, poiché è necessario controllare regolarmente gli intervalli IP pertinenti e aggiungere route definite dall'utente per i nuovi per evitare l'interruzione del runtime di integrazione Azure-SSIS. È consigliabile controllarli ogni mese, perché quando viene visualizzato un nuovo intervallo IP per il tag di servizio pertinente, l'applicazione richiederà un altro mese.

È possibile eseguire lo script di PowerShell seguente per aggiungere route definite dall'utente per il servizio di gestione di Azure Batch:

$Location = "[location of your Azure-SSIS IR]"
$RouteTableResourceGroupName = "[name of Azure resource group that contains your route table]"
$RouteTableResourceName = "[resource name of your route table]"
$RouteTable = Get-AzRouteTable -ResourceGroupName $RouteTableResourceGroupName -Name $RouteTableResourceName
$ServiceTags = Get-AzNetworkServiceTag -Location $Location
$BatchServiceTagName = "BatchNodeManagement." + $Location
$UdrRulePrefixForBatch = $BatchServiceTagName
if ($ServiceTags -ne $null)
{
    $BatchIPRanges = $ServiceTags.Values | Where-Object { $_.Name -ieq $BatchServiceTagName }
    if ($BatchIPRanges -ne $null)
    {
        Write-Host "Start adding UDRs to your route table..."
        for ($i = 0; $i -lt $BatchIPRanges.Properties.AddressPrefixes.Count; $i++)
        {
            $UdrRuleName = "$($UdrRulePrefixForBatch)_$($i)"
            Add-AzRouteConfig -Name $UdrRuleName `
                -AddressPrefix $BatchIPRanges.Properties.AddressPrefixes[$i] `
                -NextHopType "Internet" `
                -RouteTable $RouteTable `
                | Out-Null
            Write-Host "Add $UdrRuleName to your route table..."
        }
        Set-AzRouteTable -RouteTable $RouteTable
    }
}
else
{
    Write-Host "Failed to fetch Azure service tag, please confirm that your location is valid."
}

Seguendo le indicazioni riportate nella sezione Configurare un gruppo di sicurezza di rete precedente, è necessario implementare regole simili nell'appliance/servizio firewall per consentire il traffico in uscita dal runtime di integrazione Azure-SSIS:

• Se si usa Firewall di Azure:

  • È necessario aprire la porta 443 per il traffico TCP in uscita con il tag del servizio AzureCloud come destinazione.

  • Se si usa database SQL di Azure server/Istanza gestita per ospitare SSISDB, è necessario aprire le porte 1433, 11000-11999 per il traffico TCP in uscita con tag del servizio Sql/VirtualNetwork come destinazione.

  • Se si usa Archiviazione di Azure contenitore BLOB per archiviare lo script o i file di installazione personalizzati standard, è necessario aprire la porta 443 per il traffico TCP in uscita con il tag del servizio Storage/VirtualNetwork come destinazione.

  • Se è necessario accedere File di Azure, è necessario aprire la porta 445 per il traffico TCP in uscita con il tag del servizio Storage/VirtualNetwork come destinazione.

• Se si usa un'altra appliance/servizio firewall:

  • È necessario aprire la porta 443 per il traffico TCP in uscita con 0.0.0.0/0 o i seguenti FQDN specifici dell'ambiente di Azure come destinazione.

    Ambiente di Azure	FQDN
    Pubblico di Azure	Azure Data Factory (gestione) *.frontend.clouddatahub.net Archiviazione di Azure (gestione) *.blob.core.windows.net *.table.core.windows.net Registro Azure Container (installazione personalizzata) *.azurecr.io Hub eventi (registrazione) *.servicebus.windows.net Servizio registrazione Microsoft (uso interno) gcs.prod.monitoring.core.windows.net prod.warmpath.msftcloudes.com azurewatsonanalysis-prod.core.windows.net
    Azure Government	Azure Data Factory (gestione) *.frontend.datamovement.azure.us Archiviazione di Azure (gestione) *.blob.core.usgovcloudapi.net *.table.core.usgovcloudapi.net Registro Azure Container (installazione personalizzata) *.azurecr.us Hub eventi (registrazione) *.servicebus.usgovcloudapi.net Servizio registrazione Microsoft (uso interno) fairfax.warmpath.usgovcloudapi.net azurewatsonanalysis.usgovcloudapp.net
    Microsoft Azure gestito da 21Vianet	Azure Data Factory (gestione) *.frontend.datamovement.azure.cn Archiviazione di Azure (gestione) *.blob.core.chinacloudapi.cn *.table.core.chinacloudapi.cn Registro Azure Container (installazione personalizzata) *.azurecr.cn Hub eventi (registrazione) *.servicebus.chinacloudapi.cn Servizio registrazione Microsoft (uso interno) mooncake.warmpath.chinacloudapi.cn azurewatsonanalysis.chinacloudapp.cn

  • Se si usa database SQL di Azure server/Istanza gestita per ospitare SSISDB, è necessario aprire le porte 1433, 11000-11999 per il traffico TCP in uscita con 0.0.0.0/0 o il server database SQL di Azure/Istanza gestita FQDN come destinazione.

  • Se si usa Archiviazione di Azure contenitore BLOB per archiviare lo script/i file di installazione personalizzati standard, è necessario aprire la porta 443 per il traffico TCP in uscita con 0.0.0.0/0 o il nome di dominio completo Archiviazione BLOB di Azure come destinazione.

  • Se è necessario accedere a File di Azure, è necessario aprire la porta 445 per il traffico TCP in uscita con 0.0.0.0/0 o il nome di dominio completo File di Azure come destinazione.

• Se si configura un endpoint servizio di rete virtuale per Archiviazione di Azure/Registro Contenitori/Hub eventi/SQL abilitando rispettivamente le risorse Microsoft.Storage/Microsoft.ContainerRegistry/Microsoft.EventHub/Microsoft.Sql, nella subnet, tutto il traffico tra il runtime di integrazione Azure-SSIS e questi servizi nelle stesse aree associate verranno instradati alla rete backbone di Azure anziché alla rete backbone di Azure appliance/servizio firewall.

• È consigliabile aprire la porta 80 per il traffico TCP in uscita con i siti di download dell'elenco di revoche di certificati (CRL) seguenti come destinazione:

  • crl.microsoft.com:80
  • mscrl.microsoft.com:80
  • crl3.digicert.com:80
  • crl4.digicert.com:80
  • ocsp.digicert.com:80
  • cacerts.digicert.com:80

  Se si usano certificati con CRL diversi, è necessario aggiungere anche i siti di download come destinazione. Per altre informazioni, vedere l'articolo Elenco di revoche di certificati .

  Se si blocca questo traffico, è possibile che si verifichi una riduzione delle prestazioni quando si avvia azure-SSIS IR e si perde la capacità di controllare i CRL quando si usano i certificati, che non è consigliabile dal punto di sicurezza.

Se non è necessario controllare o controllare il traffico in uscita dal runtime di integrazione Azure-SSIS, è possibile usare le route definite dall'utente per forzare tutto il traffico con il tipo di hop successivo come Internet:

• Quando si usa Azure ExpressRoute, è possibile configurare una route definita dall'utente per la route 0.0.0.0/0 nella subnet con il tipo di hop successivo come Internet.

• Quando si usa un'appliance virtuale di rete, è possibile modificare la route definita dall'utente esistente per la route 0.0.0.0/0 nella subnet per cambiare il tipo di hop successivo da Appliance virtuale a Internet.

Nota

La configurazione delle route definite dall'utente con il tipo di hop successivo perché Internet non significa che tutto il traffico passerà su Internet. Se l'indirizzo di destinazione appartiene a uno dei servizi di Azure, Azure instrada tutto il traffico a tale indirizzo tramite la rete backbone di Azure anziché Internet.

Configurare il gruppo di risorse pertinente

Per abilitare l'inserimento di reti virtuali standard, il runtime di integrazione Azure-SSIS deve creare determinate risorse di rete nello stesso gruppo di risorse della rete virtuale. Tali risorse includono:

• Un servizio di bilanciamento del carico di Azure, con il nome Guid-azurebatch-cloudserviceloadbalancer>.<
• Un indirizzo IP pubblico di Azure, con il nome Guid-azurebatch-cloudservicepublicip>.<
• Un gruppo di sicurezza di rete con il nome Guid-azurebatch-cloudservicenetworksecuritygroup>.<

Nota

È ora possibile usare indirizzi IP pubblici statici personalizzati per Azure-SSIS IR. In questo scenario si creerà il servizio di bilanciamento del carico di Azure e il gruppo di sicurezza di rete nello stesso gruppo di risorse degli indirizzi IP pubblici statici anziché nella rete virtuale.

Queste risorse verranno create all'avvio del runtime di integrazione Azure-SSIS. e verranno eliminate all'arresto di Azure-SSIS IR. Se si mettono gli indirizzi IP pubblici statici per Azure-SSIS IR, non verranno eliminati quando il runtime di integrazione Azure-SSIS si arresta. Per evitare di bloccare l'arresto di Azure-SSIS IR, non riutilizzare queste risorse per altri scopi.

Assicurarsi di non avere alcun blocco delle risorse nel gruppo di risorse o nella sottoscrizione a cui appartengono la rete virtuale/gli indirizzi IP pubblici statici. Se si configura un blocco di sola lettura/eliminazione, l'avvio e l'arresto di Azure-SSIS IR avranno esito negativo o si bloccheranno.

Assicurarsi di non avere alcuna assegnazione Criteri di Azure che impedisca la creazione delle risorse seguenti nel gruppo di risorse o nella sottoscrizione a cui appartengono la rete virtuale/gli indirizzi IP pubblici statici:

• Microsoft.Network/LoadBalancers
• Microsoft.Network/NetworkSecurityGroups
• Microsoft.Network/PublicIPAddresses

Assicurarsi che la quota di risorse per la sottoscrizione sia sufficiente per queste risorse. In particolare, per ogni runtime di integrazione Azure-SSIS creato in una rete virtuale, è necessario riservare due volte il numero di queste risorse, poiché le risorse aggiuntive verranno usate quando si aggiorna periodicamente il runtime di integrazione Azure-SSIS.

Domande frequenti

• Come è possibile proteggere l'indirizzo IP pubblico esposto nel runtime di integrazione Azure-SSIS per la connessione in ingresso? È possibile rimuovere l'indirizzo IP pubblico?

  Al momento, un indirizzo IP pubblico verrà creato automaticamente quando il runtime di integrazione Azure-SSIS viene aggiunto a una rete virtuale. È disponibile un gruppo di sicurezza di rete a livello di scheda di interfaccia di rete per consentire solo al servizio di gestione di Azure Batch di connettersi in ingresso al runtime di integrazione Azure-SSIS. È anche possibile specificare un gruppo di sicurezza di rete a livello di subnet per la protezione in ingresso.

  Se non si vuole esporre alcun indirizzo IP pubblico, è consigliabile configurare un runtime di integrazione self-hosted come proxy per il runtime di integrazione Azure-SSIS invece di aggiungere il runtime di integrazione Azure-SSIS a una rete virtuale.

• È possibile aggiungere l'indirizzo IP pubblico del runtime di integrazione Azure-SSIS all'elenco di indirizzi consentiti del firewall per le origini dati?

  È ora possibile usare indirizzi IP pubblici statici personalizzati per Azure-SSIS IR. In questo caso, è possibile aggiungere gli indirizzi IP all'elenco di indirizzi consentiti del firewall per le origini dati. In alternativa, è anche possibile prendere in considerazione altre opzioni seguenti per proteggere l'accesso ai dati dal runtime di integrazione Azure-SSIS a seconda dello scenario:

  • Se l'origine dati è locale, dopo aver connesso una rete virtuale alla rete locale e aver aggiunto il runtime di integrazione Azure-SSIS alla subnet della rete virtuale, è possibile aggiungere l'intervallo di indirizzi IP privati di tale subnet all'elenco di indirizzi consentiti del firewall per l'origine dati.

  • Se l'origine dati è un servizio di Azure che supporta gli endpoint servizio di rete virtuale, è possibile configurare un endpoint servizio di rete virtuale nella subnet della rete virtuale e aggiungere il runtime di integrazione Azure-SSIS a tale subnet. È quindi possibile aggiungere una regola di rete virtuale con tale subnet al firewall per l'origine dati.

  • Se l'origine dati è un servizio cloud non di Azure, è possibile usare una route definita dall'utente per instradare il traffico in uscita dal runtime di integrazione Azure-SSIS all'indirizzo IP pubblico statico tramite un'appliance virtuale di rete/Firewall di Azure. È quindi possibile aggiungere l'indirizzo IP pubblico statico dell'appliance virtuale di rete/Firewall di Azure all'elenco di indirizzi consentiti del firewall per l'origine dati.

  • Se nessuna delle opzioni precedenti soddisfa le proprie esigenze, valutare la possibilità di configurare un runtime di integrazione self-hosted come proxy per il runtime di integrazione Azure-SSIS. È quindi possibile aggiungere l'indirizzo IP pubblico statico del computer che ospita il runtime di integrazione self-hosted all'elenco di indirizzi consentiti del firewall per l'origine dati.

• Perché è necessario fornire due indirizzi pubblici statici se si vuole usare il proprio runtime di integrazione Azure-SSIS?

  Azure-SSIS IR viene aggiornato automaticamente a intervalli regolari. I nuovi nodi vengono creati durante l'aggiornamento e quelli precedenti verranno eliminati. Tuttavia, per evitare tempi di inattività, i nodi precedenti non verranno eliminati fino a quando i nuovi non saranno pronti. Di conseguenza, il primo indirizzo IP pubblico statico usato dai nodi precedenti non può essere rilasciato immediatamente ed è necessario il secondo indirizzo IP pubblico statico per creare i nuovi nodi.

• Sono stati portati i propri indirizzi IP pubblici statici per Azure-SSIS IR, ma perché non è ancora possibile accedere alle origini dati?

  Verificare che i due indirizzi IP pubblici statici siano entrambi aggiunti all'elenco di indirizzi consentiti del firewall per le origini dati. Ogni volta che il runtime di integrazione Azure-SSIS viene aggiornato, il relativo indirizzo IP pubblico statico viene spostato tra questi due elementi. Se si aggiunge solo uno di essi all'elenco consenti, l'accesso ai dati per il runtime di integrazione Azure-SSIS verrà interrotto dopo l'aggiornamento.

  Se l'origine dati è un servizio di Azure, verificare se è stata configurata con gli endpoint servizio di rete virtuale. In tal caso, il traffico da Azure-SSIS IR all'origine dati passerà all'uso degli indirizzi IP privati gestiti dai servizi di Azure e l'aggiunta di indirizzi IP pubblici statici all'elenco di indirizzi consentiti del firewall per l'origine dati non avrà effetto.

Contenuto correlato

• Aggiungere Azure-SSIS IR a una rete virtuale tramite l'interfaccia utente di Azure Data Factory
• Aggiungere Azure-SSIS IR a una rete virtuale tramite Azure PowerShell

Per altre informazioni su Azure-SSIS IR, vedere gli articoli seguenti:

• Azure-SSIS IR. Questo articolo fornisce informazioni concettuali generali sugli IR, incluso Azure-SSIS IR.
• Esercitazione: Distribuire pacchetti SSIS in Azure. Questa esercitazione fornisce istruzioni dettagliate per creare il runtime di integrazione Azure-SSIS. Usa database SQL di Azure server per ospitare SSISDB.
• Creare un runtime di integrazione SSIS di Azure. Questo articolo si espande sull'esercitazione. Vengono fornite istruzioni sull'uso di database SQL di Azure server configurato con un endpoint servizio di rete virtuale/una regola del firewall IP/un endpoint privato o un Istanza gestita di SQL di Azure che unisce una rete virtuale all'host SSISDB. Illustra come aggiungere il runtime di integrazione Azure-SSIS a una rete virtuale.
• Monitorare un runtime di integrazione SSIS di Azure. Questo articolo illustra come recuperare e comprendere le informazioni su Azure-SSIS IR.
• Gestire un runtime di integrazione SSIS di Azure. In questo articolo viene illustrato come arrestare, avviare o rimuovere Azure-SSIS IR. Viene anche illustrato come aumentare il numero di istanze per Azure-SSIS IR tramite l'aggiunta di nodi.