Considerazioni sulla topologia di rete e sulla connettività per l'acceleratore di zona di destinazione di Integration Services
Questo articolo fornisce considerazioni sulla progettazione e consigli per la topologia di rete e la connettività che è possibile applicare quando si usa l'acceleratore di zona di destinazione di Azure Integration Services (AIS). La rete è fondamentale per quasi tutto in una zona di destinazione.
Le considerazioni sulla topologia di rete e sulla connettività per questa architettura dipendono dai requisiti dei carichi di lavoro ospitati e dai requisiti di sicurezza e conformità dell'organizzazione.
Considerazioni relative alla progettazione
Usare una topologia di rete basata su rete WAN virtuale se l'organizzazione:
Prevede di distribuire le risorse in diverse aree di Azure e richiede connettività globale tra reti virtuali in queste aree di Azure e più posizioni locali.
Deve integrare una rete di succursali su larga scala direttamente in Azure, tramite una distribuzione WAN (SD-WAN) software-defined o richiede più di 30 siti di succursale per la terminazione IPsec nativa.
È necessario il routing transitivo tra la rete privata virtuale ed ExpressRoute, ad esempio rami remoti connessi tramite VPN da sito a sito o utenti remoti connessi tramite VPN da punto a sito richiedono la connettività a un controller di dominio connesso a ExpressRoute tramite Azure.
Le organizzazioni usano la rete WAN virtuale per soddisfare i requisiti di interconnettività su larga scala. Microsoft gestisce questo servizio, che consente di ridurre la complessità complessiva della rete e di modernizzare la rete dell'organizzazione.
Usare una topologia di rete di Azure tradizionale basata su un'architettura hub-spoke se l'organizzazione:
Prevede di distribuire le risorse solo in aree di Azure selezionate.
Non è necessaria una rete globale e interconnessa.
Include poche posizioni remote o di succursali per area e richiede meno di 30 tunnel di sicurezza IP (IPsec).
Richiede il controllo completo della configurazione o richiede una configurazione personalizzata manuale della rete di Azure.
Topologia di rete di riferimento
Il diagramma dell'architettura seguente illustra l'architettura di riferimento per una distribuzione aziendale di AIS:
Pianificare l'indirizzamento IP
Le distribuzioni aziendali di AIS devono includere l'uso di endpoint privati e Rete virtuale. Quando si pianifica l'indirizzamento IP, è necessario tenere conto delle considerazioni di progettazione seguenti:
Alcuni servizi di intelligenza artificiale richiedono subnet dedicate
È possibile designare una determinata subnet t0 un determinato servizio per creare istanze di tale servizio all'interno della subnet. Ad esempio, è possibile designare una subnet ai piani di servizio app in modo da poter aggiungere altre app nel tempo.
Azure Gateway VPN può connettere siti locali sovrapposti con spazi di indirizzi IP sovrapposti tramite la funzionalità NAT (Network Address Translation).
DNS personalizzato
La maggior parte dei servizi AIS consente ai clienti di usare i propri nomi DNS per gli endpoint pubblici, usando i propri server DNS o tramite l'offerta DNS di Azure. La configurazione di queste operazioni viene eseguita in base a una risorsa in base alla risorsa, ma le risorse supportate sono elencate di seguito:
Gestione API supporta domini personalizzati.
App per le funzioni e App per la logica supportano domini personalizzati, se ospitati da un piano di servizio app o da ambiente del servizio app.
Archiviazione account supportano domini personalizzati per gli endpoint di archiviazione BLOB.
Data Factory, bus di servizio e Griglia di eventi non supportano domini personalizzati.
DNS privato
Azure DNS privato offre un servizio DNS affidabile e sicuro per la rete virtuale. DNS privato di Azure gestisce e risolve i nomi di dominio nella rete virtuale senza la necessità di configurare una soluzione DNS personalizzata.
Per risolvere i record di una zona DNS privata dalla rete virtuale, è necessario collegare la rete virtuale alla zona. Le reti virtuali collegate hanno accesso completo a e possono risolvere tutti i record DNS pubblicati nella zona privata.
Considerazioni relative alla progettazione
È importante configurare correttamente le impostazioni DNS per risolvere l'indirizzo IP dell'endpoint privato nel nome di dominio completo (FQDN) delle risorse.
È possibile che i servizi di Microsoft Azure esistenti abbiano già una configurazione DNS per un endpoint pubblico. È necessario eseguire l'override di questa configurazione per connettersi usando l'endpoint privato.
Crittografia e autenticazione del certificato
Se la progettazione della rete richiede la crittografia del traffico in transito e/o l'autenticazione basata su certificati, potrebbe essere necessario considerare dove e come viene eseguita questa crittografia/autenticazione. Ad esempio, è necessario identificare il servizio che esegue la terminazione TLS.
Considerazioni relative alla progettazione
La progettazione richiede che il traffico tra i servizi di Azure venga crittografato? La crittografia può essere terminata in una frontdoor di Azure e quindi non crittografata durante l'attraversamento del backbone di Azure o all'interno della rete virtuale?
È necessario terminare la crittografia in più posizioni?
È necessario gestire l'autenticazione in più posizioni o eseguirla una sola volta per una richiesta esterna?
Suggerimenti per la progettazione
Se si usa una progettazione hub-spoke aziendale, è consigliabile usare Frontdoor di Azure come punto di ingresso per le richieste basate su Internet.
È consigliabile usare app Azure lication Gateway come punto di terminazione per qualsiasi richiesta esterna basata su TLS o Gestione API per l'autenticazione del certificato e/o la terminazione SSL.
Connessione ivity alle risorse locali
Molti scenari di integrazione aziendale richiedono la connessione dei sistemi locali ad Azure. È importante considerare i modelli consigliati per fornire questa connettività.
Considerazioni relative alla progettazione
Azure ExpressRoute offre connettività privata dedicata alle risorse IaaS (Infrastructure as a Service) e PaaS (Platform as a Service) dedicate da posizioni locali.
Azure Gateway VPN fornisce connettività condivisa da sito a sito (S2S) tramite la rete Internet pubblica a risorse di rete virtuale IaaS (Infrastructure as a Service) di Azure da posizioni locali.
Azure ExpressRoute e Azure Gateway VPN hanno funzionalità, costi e prestazioni diversi.
È possibile usare il gateway dati locale (OPDG) o le Connessione ibride di Azure in cui ExpressRoute o Gateway VPN non è pratico. I Connessione OPDG/Ibridi sono entrambi servizi di inoltro esempi, che usano bus di servizio per stabilire connessioni in uscita dalla rete locale per ricevere richieste da Azure, senza dover aprire porte nel firewall o nella rete esterna.
OPDG è limitato nel numero di richieste al minuto supportate (limite di limitazione), ha limiti di dimensioni dei dati specifici e funziona solo con risorse di Azure limitate (App per la logica, Power BI, Power Apps, Power Automate, Analysis Services).
Le connessioni ibride funzionano con servizio app (app per le funzioni o App Web) e hanno limiti di limitazione e dimensionamento specifici.
Le Connessione ibride di Inoltro di Azure sono una parte fondamentale di bus di servizio che consente l'inoltro all'esterno di servizio app o OPDG.
Suggerimenti per la progettazione
Usare Azure ExpressRoute come canale di connettività principale per la connessione di una rete locale ad Azure.
Assicurarsi di usare lo SKU corretto per ExpressRoute e/o Gateway VPN in base ai requisiti di larghezza di banda e prestazioni.
Usare Azure Gateway VPN per connettere rami o posizioni remote ad Azure.
Usare OPDG e/o Connessione ibridi in cui Non è possibile usare ExpressRoute o Gateway VPN, in cui i limiti di velocità effettiva non saranno un problema e dove si usa una risorsa di Azure di supporto (ad esempio App per la logica, App per le funzioni).
Connessione ivity to AIS PaaS services
I servizi PaaS di Azure AIS sono in genere accessibili tramite endpoint pubblici. La piattaforma Azure offre funzionalità per proteggere questi endpoint o persino renderli completamente privati.
La protezione di questi endpoint può essere ottenuta usando endpoint privati.
Per bloccare tutto il traffico Internet verso una risorsa di destinazione, usare un endpoint privato.
Se si vuole proteggere una sotto-risorsa specifica per le risorse della rete virtuale, usare un endpoint privato.
Se si vuole proteggere un account di archiviazione specifico per le risorse della rete virtuale, è possibile usare un endpoint privato.
collegamento privato di Azure consente di accedere ai servizi AIS di Azure (ad esempio, bus di servizio e Gestione API) e ai servizi di proprietà del cliente/partner ospitati in Azure tramite un endpoint privato nella rete virtuale.
Quando si usa collegamento privato, il traffico tra la rete virtuale e il servizio attraversa la rete backbone Microsoft, quindi l'esposizione del servizio a Internet pubblico non è più necessaria. È possibile creare un servizio Collegamento privato personale nella rete virtuale e distribuirlo ai clienti. Collegamento privato di Azure offre un'esperienza coerente di configurazione e utilizzo per i servizi PaaS di Azure, i servizi di proprietà dei clienti e quelli condivisi dei partner.
Considerazioni relative alla progettazione
L'inserimento di reti virtuali fornisce distribuzioni private dedicate per i servizi supportati. Il traffico del piano di gestione continua a fluire attraverso indirizzi IP pubblici.
collegamento privato di Azure fornisce accesso dedicato usando indirizzi IP privati per le istanze PaaS di Azure o i servizi personalizzati dietro il livello Azure Load Balancer Standard.
I clienti aziendali spesso hanno preoccupazioni sugli endpoint pubblici per i servizi PaaS che devono essere mitigati in modo appropriato.
Suggerimenti per la progettazione
Usare l'inserimento della rete virtuale per i servizi di Azure supportati per renderli disponibili all'interno della rete virtuale.
I servizi PaaS di Azure inseriti in una rete virtuale eseguono comunque operazioni del piano di gestione usando indirizzi IP pubblici specifici del servizio. Connessione ivity deve essere garantita affinché il servizio funzioni correttamente.
Accedere ai servizi PaaS di Azure dall'ambiente locale tramite ExpressRoute con peering privato. Usare l'inserimento di reti virtuali per i servizi di Azure dedicati o collegamento privato di Azure per i servizi condivisi di Azure disponibili.
Per accedere ai servizi PaaS di Azure dall'ambiente locale quando non è disponibile l'inserimento o la collegamento privato della rete virtuale, usare ExpressRoute con il peering Microsoft, che consente di evitare di attraversare la rete Internet pubblica.
L'accesso ai servizi PaaS di Azure da locale tramite ExpressRoute con peering Microsoft non impedisce l'accesso agli endpoint pubblici del servizio PaaS. È necessario configurare e limitare separatamente in base alle esigenze.
Non abilitare gli endpoint servizio di rete virtuale per impostazione predefinita in tutte le subnet.
Disabilitare l'accesso pubblico ai servizi PaaS aiS.
Progettazione di rete per Gestione API
Considerazioni relative alla progettazione
Decidere se le API sono accessibili esternamente, internamente o ibrido di entrambi.
Decidere se si vuole usare il gateway Gestione API interno come endpoint principale o se si vuole usare un servizio Web Application Firewall (WAF) come gateway di app Azure lication o Frontdoor di Azure.
Decidere se devono essere distribuiti più gateway e la modalità di bilanciamento del carico, ad esempio usando gateway applicazione davanti al gateway Gestione API.
Decidere se è necessaria la connettività agli ambienti locali o multicloud.
Suggerimenti per la progettazione
Distribuire l'istanza di Gestione API in una rete virtuale per consentire l'accesso ai servizi back-end nella rete.
Usare gateway applicazione per l'accesso esterno a Gestione API quando l'istanza di Gestione API viene distribuita in una rete virtuale in modalità interna.
Usare un endpoint privato per l'istanza di Gestione API per consentire ai client nella rete privata di accedere in modo sicuro all'istanza tramite collegamento privato di Azure.
Progettazione di rete per gli account Archiviazione
Archiviazione di Azure viene usato come soluzione di archiviazione per App per la logica di Azure e Funzioni di Azure.
Suggerimenti per la progettazione
Per ottenere prestazioni ottimali, l'app per la logica o l'app per le funzioni deve usare un account di archiviazione nella stessa area, riducendo la latenza.
Usare gli endpoint privati per gli account Archiviazione di Azure per consentire ai client in una rete virtuale (VNet) di accedere in modo sicuro ai dati tramite un collegamento privato.
È necessario creare endpoint privati diversi per ogni tabella, coda e servizio di archiviazione BLOB.
Progettazione di rete per ambiente del servizio app
Un ambiente del servizio app (A edizione Standard) è un ambiente dedicato isolato per l'esecuzione di app Web, app per le funzioni e App per la logica (Standard). Viene distribuito nella rete virtuale e contiene una serie di piani servizio app, ognuno dei quali viene usato per ospitare i servizi dell'app.
Considerazioni relative alla progettazione
Un edizione Standard viene distribuito in una singola subnet all'interno della rete virtuale. Un oggetto A edizione Standard può essere distribuito usando un indirizzo IP virtuale (VIP) che consente alle connessioni esterne di usare un indirizzo IP visibile pubblicamente, che può essere aggiunto a un record DNS pubblico.
Le applicazioni all'interno di un edizione Standard avranno accesso a tutte le altre risorse all'interno del Rete virtuale, a seconda delle regole di accesso alla rete. L'accesso alle risorse in altre reti virtuali può essere ottenuto usando Rete virtuale peering.
Le applicazioni all'interno di un edizione Standard non devono essere configurate per appartenere a una rete virtuale, ma vengono automaticamente all'interno della rete virtuale in virtù della distribuzione in A edizione Standard. Ciò significa che invece di dover configurare l'accesso di rete per ogni risorsa, è possibile configurarlo una sola volta a livello A edizione Standard.
Suggerimenti per la progettazione
- Usare A edizione Standard v3, se possibile, in quanto offre la massima flessibilità di rete, riducendo al contempo la configurazione necessaria per le singole risorse all'interno di A edizione Standard. A edizione Standard v3 supporta anche la ridondanza della zona.
Progettazione di rete per piani di servizio app
servizio app in un ambiente multi-tenant possono essere distribuiti con un endpoint privato o pubblico. Quando viene distribuito con un endpoint privato, viene rimossa l'esposizione pubblica del servizio app. Se è necessario che l'endpoint privato del servizio app sia raggiungibile anche tramite Internet, prendere in considerazione l'uso del gateway app per esporre il servizio app.
Pianificare attentamente le subnet per l'integrazione della rete virtuale in uscita considerando il numero di indirizzi IP necessari. L'integrazione della rete virtuale richiede una subnet dedicata. Quando si pianificano le dimensioni della subnet, tenere presente che Azure riserva 5 indirizzi IP in ogni subnet. Inoltre, un indirizzo viene usato dalla subnet di integrazione per ogni istanza del piano. Quando si ridimensiona l'app a quattro istanze, vengono usati quattro indirizzi. Quando si aumentano o si abbassano le dimensioni, lo spazio degli indirizzi richiesto viene raddoppiato per un breve periodo di tempo. Ciò influisce sulle istanze supportate reali e disponibili nella subnet.
Quando è necessario connettersi da un servizio app a servizi locali, privati o con restrizioni IP, tenere presente che:
Quando si esegue nell'ambiente multi-tenant, la chiamata servizio app può provenire da un'ampia gamma di indirizzi IP e l'integrazione della rete virtuale potrebbe essere necessaria per soddisfare i requisiti di rete.
I servizi come Gestione API (GESTIONE API) possono essere usati per eseguire chiamate proxy tra limiti di rete e possono fornire un INDIRIZZO IP statico, se necessario.
Suggerimenti per la progettazione
- Poiché le dimensioni delle subnet non possono essere modificate dopo l'assegnazione, usare una subnet sufficientemente grande per supportare qualsiasi scalabilità che l'app possa raggiungere. Per evitare problemi con la capacità della subnet, è consigliabile usare un suffisso /26 (64 indirizzi) per l'integrazione della rete virtuale.
Progettazione di rete per Azure Data Factory
Considerazioni relative alla progettazione
Per connettere Data Factory a un'origine dati che si trova nella rete locale o ad esempio in un servizio di Azure configurato per bloccare l'accesso da tutti i servizi di Azure, a meno che non siano consentiti in modo specifico, è necessario prendere in considerazione l'integrazione di Data Factory con una rete virtuale che fornisce l'accesso di rete all'origine dati di destinazione.
Data Factory usa ambienti separati denominati runtime di integrazione. Il runtime predefinito di Data Factory, il runtime di integrazione di Azure, non è associato a una rete virtuale e, di conseguenza, non può essere usato per connettersi alle origini dati protette con i firewall più restrittivi. Considerare quale di questi runtime soddisfa meglio i requisiti.
L'avvio delle reti virtuali gestite richiede tempo, mentre i normali runtime di Azure sono disponibili quasi immediatamente. Questo è un aspetto da tenere presente quando si pianificano le pipeline e si esegue il debug.
L'avvio dei runtime SSIS con un runtime integrato nella rete virtuale richiederà fino a 30 minuti.
I runtime di integrazione self-hosted possono eseguire solo l'attività di copia, che copia i dati da un'origine a un'altra così come sono. Se si vogliono eseguire trasformazioni ai dati, non è possibile eseguire queste operazioni usando i flussi di dati di Data Factory.
Gli endpoint privati gestiti sono endpoint privati creati nella Rete virtuale gestita di Azure Data Factory che stabilisce un collegamento privato alle risorse di Azure (in genere origini dati per Azure Data Factory). Azure Data Factory gestisce questi endpoint privati per conto dell'utente.
Gli endpoint privati sono disponibili solo per i runtime di integrazione self-hosted per connettersi a Data Factory.
Progettazione di rete per App per la logica (Standard) - App integrate della rete virtuale
Considerazioni relative alla progettazione
Il traffico in ingresso verso le app per la logica passerà attraverso endpoint privati. Fare riferimento alle considerazioni relative al traffico in ingresso attraverso la documentazione degli endpoint privati durante la pianificazione della progettazione della rete di App per la logica.
Il traffico in uscita dalle app per la logica passa attraverso la rete virtuale. Fare riferimento alle considerazioni relative al traffico in uscita tramite la documentazione sull'integrazione della rete virtuale durante la pianificazione della progettazione della rete di App per la logica.
Progettazione di rete per bus di servizio
Considerazioni relative alla progettazione
Si usano DNS privato zone o il proprio server DNS (con inoltro DNS) per risolvere una risorsa di collegamento privato?
I filtri IP e le reti virtuali sono supportati solo nel livello SKU Premium per bus di servizio. Se il livello Premium non è pratico, esaminare l'uso dei token di firma di accesso condiviso come metodo principale per bloccare l'accesso allo spazio dei nomi.
Suggerimenti per la progettazione
L'accesso alla rete pubblica deve essere disabilitato usando il filtro IP, che si applica a tutti i protocolli supportati, ad esempio AMQP e HTTPS.
Il traffico verso questo spazio dei nomi deve essere limitato solo sugli endpoint privati, limitando l'accesso alla rete pubblica (tramite filtro IP).
Posizionare l'endpoint privato nella propria subnet dedicata riservata per bus di servizio.
Aggiungere un record DNS usando la zona DNS privata per l'endpoint privato. Abilitare i servizi attendibili all'interno di Azure per accedere direttamente allo spazio dei nomi (ignorando così il firewall) per evitare problemi con la progettazione dell'integrazione.
Progettazione di rete per le app per le funzioni
Considerazioni relative alla progettazione
- Si usano DNS privato zone o il proprio server DNS (con inoltro DNS) per risolvere una risorsa di collegamento privato?
Suggerimenti per la progettazione
L'accesso alla rete pubblica deve essere disabilitato.
Il traffico verso questo spazio dei nomi deve essere limitato solo sugli endpoint privati.
Posizionare l'endpoint privato nella propria subnet dedicata riservata per Funzioni.
Aggiungere un record DNS usando la zona DNS privata per l'endpoint privato.
Progettazione di rete per Azure Key Vault
Suggerimenti per la progettazione
L'accesso alla rete pubblica deve essere disabilitato.
Creare un endpoint privato per limitare l'accesso solo tramite la rete virtuale.
Posizionare l'endpoint privato nella propria subnet dedicata riservata per Key Vault.
Aggiungere un record DNS usando la zona DNS privata per l'endpoint privato.
Progettazione di rete per Griglia di eventi
Considerazioni relative alla progettazione
- Si usano DNS privato zone o il proprio server DNS (con inoltro DNS) per risolvere una risorsa di collegamento privato?
Suggerimenti per la progettazione
L'accesso alla rete pubblica deve essere disabilitato tramite il filtro IP.
Il traffico verso gli argomenti e il dominio devono essere limitati solo agli endpoint privati.
Posizionare l'endpoint privato nella propria subnet dedicata riservata per Griglia di eventi.
Aggiungere un record DNS usando la zona DNS privata per l'endpoint privato.
Progettazione di rete per Hub eventi
Considerazioni relative alla progettazione
- La limitazione dell'accesso alla rete non funziona con il livello SKU Basic in Hub eventi
Suggerimenti per la progettazione
L'accesso alla rete pubblica deve essere disabilitato tramite il filtro IP.
L'accesso alla rete pubblica deve essere disabilitato usando gli endpoint di servizio: creare un endpoint di servizio Rete virtuale nella rete virtuale e associarlo allo spazio dei nomi di Hub eventi usando una regola di rete virtuale
Abilitare l'opzione Servizi attendibili per consentire alle risorse di Azure di accedere allo spazio dei nomi.
Passaggio successivo
Esaminare le aree di progettazione critiche per prendere in considerazione e consigli completi per l'architettura.