Connettività dell'area di atterraggio dei dati a singola regione

In una configurazione a singola area, la zona di destinazione di gestione dei dati, le zone di destinazione dei dati e tutti i servizi associati vengono stabiliti all'interno della stessa area. Tutte le zone di atterraggio si trovano nella stessa sottoscrizione dell'hub di connettività. Questa sottoscrizione ospita risorse di rete condivise, che possono includere un'appliance virtuale di rete (ad esempio Firewall di Azure), un gateway ExpressRoute, un gateway VPN (Virtual Private Network), una rete virtuale hub o una rete WAN virtuale (hub vWAN).

Figura 1: Connettività a singola area.

In base alle funzionalità correnti dei servizi di rete di Azure, è consigliabile usare un'architettura di rete mesh. È necessario configurare il peering di rete virtuale tra:

• Hub di connettività e zona Gestione dati
• Hub di connettività e ogni zona di destinazione dei dati
• Zona Gestione dati e ogni zona di destinazione dei dati
• Ogni zona di destinazione dei dati

Questo articolo descrive i vantaggi e i svantaggi di ogni opzione di architettura di rete considerata per l'analisi su scala cloud.

La prima sezione di questo articolo è incentrata su un modello a singola area, in cui la zona Gestione dati e tutte le zone di destinazione dei dati sono ospitate nella stessa area.

Ogni modello di progettazione viene valutato usando i criteri seguenti:

• Costo
• Gestione dell'accesso degli utenti
• Gestione dei servizi
• Larghezza di banda
• Latenza

Ogni opzione di progettazione viene analizzata tenendo presente il seguente caso d'uso della zona di atterraggio di dati incrociati:

Architettura di rete mesh (scelta consigliata)

È consigliabile usare un'architettura mesh di rete quando si adotta l'analisi su scala cloud. Oltre alla progettazione di rete hub-spoke esistente configurata all'interno del tenant, è necessario eseguire due operazioni per implementare un'architettura mesh di rete:

• Aggiungere peering di rete virtuale tra tutte le Vnet della Zona di atterraggio dei dati.
• Aggiungi i peering di rete virtuale tra la Zona di Atterraggio Gestione Dati e tutte le Zone di Atterraggio Dati.

Nello scenario di esempio, i dati provenienti dall'account di archiviazione A transitano attraverso una connessione di peering di rete virtuale (2) connessa tramite le due reti virtuali delle Zone di Approdo dei Dati. Viene caricato ed elaborato dalla macchina virtuale B ((3) e (4) e quindi inviato tramite l'endpoint privato locale (5) da archiviare nell'account di archiviazione B.

In questo scenario, i dati non passano attraverso l'hub di connettività. Rimane all'interno della piattaforma dei dati costituita da una zona di gestione dei dati e una o più zone di atterraggio dei dati.

Figura 2: Architettura di rete mesh.

Gestione degli accessi utente nell'architettura di rete mesh

In una progettazione di rete mesh, i team delle applicazioni dati richiedono solo due elementi per creare nuovi servizi (inclusi gli endpoint privati):

• Accesso in scrittura al proprio gruppo di risorse dedicato nella zona di destinazione dei dati
• Aggiungere l'accesso alla subnet designata

In questa progettazione, i team dell'applicazione dati possono distribuire autonomamente endpoint privati. Purché dispongano dei diritti di accesso necessari per connettere gli endpoint privati a una subnet in un determinato spoke, i team non hanno bisogno di supporto durante la configurazione della connettività necessaria.

Riepilogo:

Gestione dei servizi nell'architettura di rete mesh

In una progettazione dell'architettura di rete mesh, nessuna appliance virtuale di rete funge da singolo punto di errore o limitazione. La mancanza di set di dati inviati tramite l'hub di connettività riduce il sovraccarico del team centrale della piattaforma Azure, purché non sia necessario aumentare il numero di istanze dell'appliance virtuale.

Ciò implica che il team centrale della piattaforma Azure non può più esaminare e registrare tutto il traffico inviato tra zone di destinazione dei dati. Tuttavia, l'analisi su scala cloud è una piattaforma coerente che si estende su più sottoscrizioni, che consente la scalabilità e supera le limitazioni a livello di piattaforma, in modo che non sia uno svantaggio.

Con tutte le risorse ospitate all'interno di una singola sottoscrizione, il team centrale della piattaforma Azure non controlla più tutti i dati nell'hub di connettività centrale. È comunque possibile acquisire i log di rete usando i log dei flussi del gruppo di sicurezza di rete. È possibile consolidare e archiviare altri log a livello di applicazione e di servizio usando impostazioni di diagnostica specifiche del servizio.

È possibile acquisire tutti questi log su larga scala usando Criteri di Azure definizioni per le impostazioni di diagnostica.

Questa progettazione consente anche di creare una soluzione DNS nativa di Azure basata su zone DNS privato. È possibile automatizzare il ciclo di vita dei record A DNS tramite definizioni di Criteri di Azure per i gruppi DNS privati.

Riepilogo:

Costo dell'architettura mesh di rete

In questa progettazione di rete si paga solo per:

• Endpoint privati (all'ora)
• Il traffico in ingresso e in uscita inviato attraverso gli endpoint privati per caricare il set di dati non elaborato (1) e archiviare il set di dati elaborato (6)

Il peering di rete virtuale non verrà addebitato (2), motivo per cui questa opzione ha un costo minimo.

Riepilogo:

Larghezza di banda e latenza in un'architettura di rete mesh

Questa progettazione non presenta limitazioni di larghezza di banda o latenza note perché nessuna appliance virtuale di rete limita la velocità effettiva per lo scambio di dati della zona di destinazione tra dati. L'unico fattore di limitazione della progettazione è il limite fisico dei nostri data center (velocità dei cavi in fibra ottica).

Riepilogo:

Riepilogo dell'architettura mesh di rete

Se si prevede di adottare analisi scalabile su cloud, è consigliabile usare il design della rete a maglia. Una rete mesh offre larghezza di banda massima e bassa latenza a un costo minimo, ma non compromette la gestione degli accessi utente o il livello DNS.

Se è necessario applicare altri criteri di rete all'interno della piattaforma dati, usare gruppi di sicurezza di rete anziché appliance virtuali di rete centrali.

Architettura hub-spoke tradizionale (scelta non consigliata)

La progettazione dell'architettura di rete hub-spoke è l'opzione più ovvia e una che molte aziende hanno adottato. In questo caso, la transitività di rete viene configurata nell'hub di connettività per accedere ai dati nell'account di archiviazione A dalla macchina virtuale B. I dati attraversano due peering di rete virtuale ((2) e (5)) e un'appliance virtuale di rete ospitata all'interno dell'hub di connettività ((3) e (4)). I dati vengono quindi caricati dalla macchina virtuale (6) e archiviati di nuovo nell'account di archiviazione B (8).

Figura 3: Architettura Hub e Spoke.

Gestione degli accessi utente nell'architettura hub e spoke tradizionale

In una progettazione hub-spoke tradizionale, i team dell'applicazione dati richiedono solo due elementi per creare nuovi servizi (inclusi gli endpoint privati):

• Accesso in scrittura al proprio gruppo di risorse nella zona di destinazione dei dati
• Aggiungere l'accesso alla subnet designata

In questa progettazione, i team dell'applicazione dati possono distribuire autonomamente endpoint privati. Purché dispongano dei diritti di accesso necessari per connettere gli endpoint privati a una subnet in un determinato spoke, i team non hanno bisogno di supporto durante la configurazione della connettività necessaria.

Riepilogo:

Gestione dei servizi nell'architettura Hub-and-Spoke tradizionale

Questa progettazione di rete è ben nota e coerente con la configurazione di rete esistente della maggior parte delle organizzazioni. In questo modo la progettazione è semplice da spiegare e implementare. È anche possibile usare una soluzione DNS nativa di Azure centralizzata con DNS privato zone per fornire la risoluzione FQDN all'interno del tenant di Azure. L'uso di DNS privato zone consente di automatizzare il ciclo di vita dei record DNS A tramite Criteri di Azure.

Un altro vantaggio di questa progettazione è che il traffico viene instradato attraverso un'appliance virtuale di rete centrale, quindi il traffico di rete inviato da uno spoke a un altro può essere registrato e controllato.

Uno svantaggio di questa progettazione è che il team centrale della piattaforma Azure deve gestire manualmente le tabelle di route. Ciò è necessario per garantire la transitività tra spoke, che consente la condivisione degli asset di dati tra più zone di destinazione dei dati. La gestione dei percorsi può diventare complessa e soggetta a errori nel tempo e deve essere considerata fin dall'inizio.

Un altro aspetto negativo di questa configurazione di rete è il modo in cui viene configurata l'appliance virtuale di rete centrale. L'appliance virtuale di rete funziona come singolo punto di errore e può causare gravi tempi di inattività all'interno della piattaforma dati in caso di errore. Inoltre, man mano che le dimensioni del set di dati aumentano all'interno di una piattaforma dati e il numero di casi d'uso della zona di destinazione tra dati aumenta, viene inviato più traffico attraverso l'appliance virtuale di rete centrale.

Nel corso del tempo, ciò può comportare gigabyte o persino terabyte di dati inviati tramite l'istanza centrale. Poiché la larghezza di banda delle appliance virtuali di rete esistenti è spesso limitata a uno o due gigabyte, l'appliance virtuale di rete centrale può costituire un collo di bottiglia che limita notevolmente il flusso di traffico tra le zone di approdo dati e limita la condivisione dei dati.

L'unico modo per evitare questo problema consiste nell'aumentare il numero di istanze dell'appliance virtuale di rete centrale in più istanze, con implicazioni importanti sui costi per questa progettazione.

Riepilogo:

Costo dell'architettura hub-spoke tradizionale

Per questa rete vengono addebitati costi orari per gli endpoint privati degli account di archiviazione. Vengono addebitati anche i costi per il traffico in ingresso e in uscita inviato attraverso gli endpoint privati per caricare un set di dati non elaborato (1) e archiviare il set di dati elaborato (8).

Il cliente viene addebitato per il traffico in ingresso e in uscita di un peering di rete virtuale (5). Come accennato in precedenza, il primo peering di rete virtuale non viene addebitato (2).

Se si usa questa progettazione di rete (3) e (4) si verifica un costo elevato per l'appliance virtuale di rete centrale. È necessario acquistare licenze aggiuntive e ridimensionare l'appliance virtuale di rete centrale in base alla richiesta o pagare l'addebito elaborato per gigabyte come è fatto con Firewall di Azure.

Riepilogo:

Larghezza di banda e latenza nell'architettura hub e spoke tradizionale

Questa progettazione di rete presenta gravi limitazioni della larghezza di banda. L'appliance virtuale di rete centrale diventa un collo di bottiglia critico man mano che aumenta la piattaforma, che limita i casi d'uso della zona di destinazione tra dati e la condivisione dei set di dati. È anche probabile che crei più copie dei set di dati nel tempo.

Questa progettazione influisce notevolmente anche sulla latenza, che diventa particolarmente critica negli scenari di analisi in tempo reale.

Riepilogo:

Riepilogo dell'architettura hub-spoke tradizionale

Questa progettazione della rete hub-spoke presenta alcuni vantaggi per la gestione degli accessi, ma a causa di limitazioni critiche della gestione dei servizi e della larghezza di banda e latenza, non è possibile consigliare questa progettazione di rete per i casi d'uso delle zone di destinazione tra dati.

Architettura di proiezione di endpoint privati (scelta non consigliata)

Un'altra opzione di progettazione è la proiezione di endpoint privati in ogni zona di destinazione. In questa progettazione viene creato un endpoint privato per l'account di archiviazione A in ogni zona di destinazione. Questo porta a un primo endpoint privato nella zona di destinazione dei dati A connessa alla rete virtuale nella zona di destinazione dei dati A, un secondo endpoint privato connesso alla rete virtuale nella zona di destinazione dei dati B e così via.

Lo stesso vale per l'account di archiviazione B e potenzialmente per altri servizi all'interno delle zone di destinazione dei dati. Se si definisce il numero di zone di destinazione dei dati come n, si finisce con n endpoint privati per almeno tutti gli account di archiviazione e potenzialmente anche altri servizi all'interno delle zone di destinazione dei dati. Ciò comporta un aumento esponenziale del numero di endpoint privati.

figura 4: Architettura di proiezione dell'endpoint privato.

Poiché tutti gli endpoint privati di un servizio specifico (ad esempio, l'account di archiviazione A) hanno lo stesso FQDN (ad esempio storageaccounta.privatelink.blob.core.windows.net), questa soluzione crea problemi nel livello DNS che non possono essere risolti usando le zone DNS privato. È invece necessaria una soluzione DNS personalizzata in grado di risolvere i nomi DNS in base all'indirizzo di origine/IP del richiedente. Ciò consente di connettere la macchina virtuale A agli endpoint privati connessi alla rete virtuale nella zona di destinazione dei dati A e di connettere la macchina virtuale B agli endpoint privati connessi alla rete virtuale nella zona di destinazione dati B. È possibile farlo con una configurazione basata su Windows Server, mentre è possibile automatizzare il ciclo di vita dei record A DNS tramite una combinazione di Log attività e Funzioni di Azure.

In questa configurazione è possibile caricare il set di dati non elaborato nell'account di archiviazione A nella macchina virtuale B accedendo al set di dati tramite l'endpoint privato locale (1). Dopo aver caricato ed elaborato il set di dati ((2) e (3),è possibile archiviarlo nell'account di archiviazione B accedendo direttamente all'endpoint privato locale (4). In questo scenario, i dati non devono attraversare alcun peering di rete virtuale.

Gestione degli accessi utente nell'architettura di proiezione di endpoint privati

Questo approccio di progettazione alla gestione degli accessi utente è simile a quello dell'architettura di rete con mesh. In questa progettazione, tuttavia, è possibile richiedere diritti di accesso per altre zone di destinazione dei dati, per creare endpoint privati non solo all'interno di una zona di destinazione dei dati designata e di una rete virtuale, ma anche in altre zone di destinazione dei dati e nelle rispettive reti virtuali.

Per questo motivo, i team dell'applicazione dati richiedono tre elementi, non due, per poter creare nuovi servizi:

• Accesso in scrittura a un gruppo di risorse in una zona di destinazione dei dati designata
• Aggiungere l'accesso alla subnet designata
• Accesso a un gruppo di risorse e a una subnet all'interno di tutte le altre zone di destinazione dei dati per creare i rispettivi endpoint privati locali

Questa progettazione di rete aumenta la complessità nel livello di gestione degli accessi perché i team dell'applicazione dati richiedono autorizzazioni in ogni singola zona di destinazione dei dati. La progettazione può anche confondere e causare un controllo degli accessi in base al ruolo incoerente nel tempo.

Se ai team dell'applicazione dati e alle aree di destinazione dei dati non sono assegnati diritti di accesso necessari, si verificheranno problemi descritti nell'architettura hub-spoke tradizionale (non consigliata).

Riepilogo:

Gestione dei servizi nell'architettura di proiezione di endpoint privati

Anche se di nuovo simile alla progettazione dell'architettura di rete mesh, questa progettazione di rete ha il vantaggio di nessuna appliance virtuale di rete che funge da singolo punto di errore o velocità effettiva di limitazione. Riduce anche il sovraccarico di gestione per il team centrale della piattaforma Azure non inviando set di dati tramite l'hub di connettività, perché non è necessario aumentare il numero di istanze dell'appliance virtuale. Ciò implica che il team centrale della piattaforma Azure non può più esaminare e registrare tutto il traffico inviato tra le zone di destinazione dei dati. Tuttavia, l'analisi su scala cloud è una piattaforma coerente che si estende su più sottoscrizioni, che consente la scalabilità e supera le limitazioni a livello di piattaforma, in modo che non sia uno svantaggio.

Con tutte le risorse ospitate all'interno di una singola sottoscrizione, il traffico non viene controllato nell'hub di connettività centrale. È comunque possibile acquisire i log di rete usando i log del flusso del gruppo di sicurezza di rete ed è possibile consolidare e archiviare altri log a livello di applicazione e di servizio usando impostazioni di diagnostica specifiche del servizio. È possibile acquisire tutti questi log su larga scala usando Criteri di Azure. D'altra parte, lo spazio degli indirizzi di rete richiesto dalla piattaforma dati aumenta a causa dell'aumento esponenziale degli endpoint privati necessari, che non è ottimale.

Le principali preoccupazioni relative a questa architettura di rete sono le problematiche DNS indicate in precedenza. Non è possibile usare una soluzione nativa di Azure sotto forma di zone DNS private, quindi questa architettura richiede una soluzione di terze parti in grado di risolvere FQDN in base all'indirizzo di origine/IP del richiedente. È anche necessario sviluppare e gestire strumenti e flussi di lavoro per automatizzare i record A DNS privati, che impongono un sovraccarico di gestione drasticamente maggiore rispetto alla soluzione proposta guidata da Policy di Azure .

È possibile creare un'infrastruttura DNS distribuita usando le zone di DNS privato, ma in questo modo vengono create isole DNS, che alla fine causano problemi quando si tenta di accedere ai servizi di collegamento privato ospitati in altre zone di destinazione all'interno del tenant. Pertanto, questa progettazione non è un'opzione valida.

Riepilogo:

Costo dell'architettura di proiezione degli endpoint privati

In questa progettazione di rete vengono addebitati solo gli endpoint privati (all'ora) e il traffico in ingresso e in uscita inviati tramite tali endpoint privati per caricare set di dati non elaborati (1) e archiviare set di dati elaborati (4). Tuttavia, è necessario prevedere costi aggiuntivi a causa dell'aumento esponenziale del numero di endpoint privati della piattaforma dati. Poiché vengono addebitati addebiti all'ora, l'importo dei costi aggiuntivi dipende dal numero di endpoint privati creati.

Riepilogo:

Larghezza di banda e latenza nell'architettura di proiezione di endpoint privati

Questa progettazione non presenta limitazioni di larghezza di banda e latenza note perché non dispone di appliance virtuali di rete che limitano la velocità effettiva per lo scambio di dati della zona di destinazione tra dati. L'unico fattore di limitazione della progettazione è il limite fisico dei nostri data center (velocità dei cavi in fibra ottica).

Riepilogo:

Riepilogo dell'architettura di proiezione di endpoint privati

La crescita esponenziale degli endpoint privati in questa architettura di rete può causare la perdita di traccia degli endpoint privati usati per lo scopo in cui si trovano. L'utente è limitato anche dai problemi di gestione degli accessi e dalle complessità del livello DNS. A causa di questi problemi, non è possibile consigliare questa progettazione di rete per i casi d'uso della zona di destinazione tra dati.

Endpoint privati nell'architettura dell'hub di connettività (scelta non consigliata)

Un'altra opzione di rete consiste nell'ospitare endpoint privati nell'hub di connettività e connetterli alla rete virtuale hub. In questa soluzione si ospita un singolo endpoint privato per ogni servizio nella rete virtuale aziendale. A causa dell'architettura di rete hub-spoke esistente nella maggior parte delle aziende e del fatto che l'hub di connettività ospita gli endpoint privati in questa soluzione, la transitività non è necessaria. Il peering di rete virtuale tra l'hub di connettività e le zone di destinazione dei dati consente l'accesso diretto.

I dati attraversano un singolo peering di rete virtuale tra l'hub di connettività e la zona di destinazione dei dati per caricare un set di dati archiviato nell'account di archiviazione A nella macchina virtuale B. Dopo il caricamento e l'elaborazione del set di dati ((3) e (4), attraversa lo stesso peering di rete virtuale una seconda volta (5) prima di essere archiviato nell'account di archiviazione B tramite l'endpoint privato connesso alla rete virtuale hub (6).

figura 5: Endpoint privati nell'architettura dell'hub di connettività.

Gestione degli accessi utente nell'architettura dell'hub di connettività

In questa progettazione di rete, i team delle zone di atterraggio dei dati e i team delle applicazioni dati hanno bisogno di due cose per poter connettere gli endpoint privati alla rete virtuale Hub:

• Autorizzazioni di scrittura per un gruppo di risorse nella sottoscrizione dell'hub di connettività
• Unire autorizzazioni alla rete virtuale hub

L'hub di connettività è designato per il team della piattaforma Azure dell'organizzazione ed è dedicato all'hosting dell'infrastruttura di rete necessaria e condivisa dell'organizzazione (inclusi firewall, gateway e strumenti di gestione della rete). Questa opzione di rete rende la progettazione incoerente perché non segue i principi di gestione degli accessi della zona di atterraggio Enterprise-Scale. Di conseguenza, la maggior parte dei team della piattaforma Azure non approva questa opzione di progettazione.

Riepilogo:

Gestione dei servizi nell'architettura dell'hub di connettività

Anche se simile alla progettazione dell'architettura di rete mesh, questa progettazione non ha appliance virtuali di rete che funge da singolo punto di errore o velocità effettiva di limitazione. Riduce anche il sovraccarico di gestione per il team centrale della piattaforma Azure non inviando set di dati tramite l'hub di connettività, perché non è necessario aumentare il numero di istanze dell'appliance virtuale. Ciò implica che il team centrale della piattaforma Azure non può più esaminare e registrare tutto il traffico inviato tra le zone di destinazione dei dati. Tuttavia, l'analisi su scala cloud è una piattaforma coerente che si estende su più sottoscrizioni, che consente la scalabilità e supera le limitazioni a livello di piattaforma, in modo che non sia uno svantaggio.

Con tutte le risorse ospitate all'interno di una singola sottoscrizione, il traffico non viene controllato nell'hub di connettività centrale. È comunque possibile acquisire i log di rete usando i log del flusso del gruppo di sicurezza di rete ed è possibile consolidare e archiviare altri log a livello di applicazione e di servizio usando impostazioni di diagnostica specifiche del servizio. È possibile acquisire tutti questi log su larga scala usando Criteri di Azure.

Questa progettazione consente anche di creare una soluzione DNS nativa di Azure basata su zone di DNS privato e di automatizzare il ciclo di vita dei record A DNS tramite Criteri di Azure.

Riepilogo:

Costo dell'architettura dell'hub di connettività

In questa progettazione di rete vengono addebitati solo gli endpoint privati (all'ora) e il traffico in ingresso e in uscita inviati tramite tali endpoint privati per caricare un set di dati non elaborato (1) e archiviare il set di dati elaborato (6).

Riepilogo:

Larghezza di banda e latenza nell'architettura dell'hub di connettività

Questa progettazione non presenta limitazioni di larghezza di banda e latenza note perché non dispone di appliance virtuali di rete che limitano la velocità effettiva per lo scambio di dati della zona di destinazione tra dati. L'unico fattore di limitazione della progettazione è il limite fisico dei nostri data center (velocità dei cavi in fibra ottica).

Riepilogo:

Endpoint privati nel riepilogo dell'architettura dell'hub di connettività

Anche se questa progettazione dell'architettura di rete presenta più vantaggi, le incoerenze di gestione degli accessi menzionate in precedenza lo rendono secondario. Pertanto, non è possibile consigliare questo approccio di progettazione.

Conclusione della connettività della zona di atterraggio dati a regione singola

Oltre a tutte le opzioni di architettura di rete esaminate e i relativi vantaggi e svantaggi, l'architettura di rete mesh è il vincitore chiaro. Offre enormi vantaggi per la velocità effettiva e per la gestione dei costi, motivo per cui è consigliabile usarla durante la distribuzione di analisi su scala cloud. Le reti virtuali spoke di peering non sono state in precedenza comuni e ciò ha causato problemi con la condivisione di set di dati tra domini e business unit.

È possibile visualizzare l'analisi su scala cloud come soluzione coerente che si estende su più sottoscrizioni. In una singola configurazione della sottoscrizione, il flusso del traffico di rete è uguale al flusso nell'architettura di rete mesh. All'interno di una singola configurazione della sottoscrizione, gli utenti raggiungeranno probabilmente i limiti e le quote a livello di sottoscrizione della piattaforma, che l'analisi su scala cloud mira a evitare.

Passaggi successivi

• Connettività della zona di atterraggio dei dati interregionale