Linee guida per la pianificazione della rete per Azure NetApp Files

La pianificazione dell'architettura di rete è un elemento fondamentale della progettazione di qualsiasi infrastruttura di applicazioni. Questo articolo consente di progettare un'architettura di rete efficace per i carichi di lavoro, in modo da sfruttare al meglio le avanzate funzionalità di Azure NetApp Files.

I volumi di Azure NetApp Files sono progettati per essere contenuti in una subnet per scopi specifici denominata subnet delegata, appartenente alla rete virtuale di Azure. È quindi possibile accedere ai volumi direttamente da Azure tramite peering reti virtuali o da un gateway Rete virtuale (ExpressRoute o Gateway VPN). La subnet è dedicata ad Azure NetApp Files e non è disponibile connettività a Internet.

Funzionalità di rete configurabili

Nelle aree supportate è possibile creare nuovi volumi o modificare volumi esistenti per usare le funzionalità di rete Standard o Basic . Nelle aree in cui le funzionalità di rete Standard non sono supportate, per impostazione predefinita il volume usa le funzionalità di rete Basic. Per altre informazioni, vedere Configurare le funzionalità di rete.

  • Standard
    La selezione di questa impostazione abilita limiti IP più elevati e funzionalità di rete virtuale standard, ad esempio gruppi di sicurezza di rete e route definite dall'utente su subnet delegate e modelli di connettività aggiuntivi, come indicato in questo articolo.

  • Base
    Se si seleziona questa impostazione, vengono attivati modelli di connettività selettivi e scalabilità IP limitata, come indicato nella sezione Considerazioni . Tutti i vincoli si applicano in questa impostazione.

Aree geografiche supportate

Le funzionalità di rete Standard di Azure NetApp Files sono supportate per le aree seguenti:

  • Australia centrale
  • Australia centrale 2
  • Australia orientale
  • Australia sud-orientale
  • Brasile meridionale
  • Brasile meridionale
  • Canada centrale
  • Canada orientale
  • India centrale
  • Stati Uniti centrali
  • Asia orientale
  • Stati Uniti orientali
  • Stati Uniti orientali 2
  • Francia centrale
  • Germania settentrionale
  • Germania centro-occidentale
  • Giappone orientale
  • Giappone occidentale
  • Corea centrale
  • Corea meridionale
  • Stati Uniti centro-settentrionali
  • Europa settentrionale
  • Norvegia orientale
  • Norvegia occidentale
  • Qatar centrale
  • Sudafrica settentrionale
  • Stati Uniti centro-meridionali
  • India meridionale
  • Asia sud-orientale
  • Svezia centrale
  • Svizzera settentrionale
  • Svizzera occidentale
  • Emirati Arabi Uniti centrali
  • Emirati Arabi Uniti settentrionali
  • Regno Unito meridionale
  • Regno Unito occidentale
  • US Gov Arizona
  • US Gov Texas
  • US Gov Virginia
  • Europa occidentale
  • Stati Uniti occidentali
  • West US 2
  • Stati Uniti occidentali 3

L'opzione per modificare le funzionalità di rete per i volumi esistenti è supportata per le aree seguenti:

  • Australia centrale
  • Australia centrale 2
  • Australia orientale
  • Australia sud-orientale
  • Brasile meridionale
  • Brasile meridionale
  • Canada centrale
  • Canada orientale
  • India centrale
  • Stati Uniti centrali
  • Asia orientale
  • Stati Uniti orientali*
  • Stati Uniti orientali 2
  • Francia centrale
  • Germania settentrionale
  • Germania centro-occidentale
  • Giappone orientale
  • Giappone occidentale
  • Corea centrale
  • Corea meridionale
  • Stati Uniti centro-settentrionali
  • Europa settentrionale
  • Norvegia orientale
  • Norvegia occidentale
  • Qatar centrale
  • Sudafrica settentrionale
  • Stati Uniti centro-meridionali*
  • India meridionale
  • Asia sud-orientale
  • Svezia centrale
  • Svizzera settentrionale
  • Svizzera occidentale
  • Emirati Arabi Uniti centrali
  • Emirati Arabi Uniti settentrionali
  • Regno Unito meridionale
  • Regno Unito occidentale
  • US Gov Arizona
  • US Gov Texas
  • US Gov Virginia
  • Europa occidentale
  • Stati Uniti occidentali
  • Stati Uniti occidentali 2*
  • Stati Uniti occidentali 3

* Non tutti i volumi in questa area sono disponibili per la conversione. Tutti i volumi saranno disponibili per la conversione in futuro.

Considerazioni

È necessario prendere in considerazione alcuni aspetti quando si pianifica la rete Azure per NetApp Files.

Vincoli

La tabella seguente descrive cosa è supportato per ogni configurazione delle funzionalità di rete:

Funzionalità Funzionalità di rete standard Funzionalità di rete di base
Numero di indirizzi IP in una rete virtuale (incluse le reti virtuali con peering immediato) che accedono ai volumi in un'istanza di Azure NetApp Files che ospita la rete virtuale Stessi limiti standard delle macchine virtuali 1000
Subnet delegate di Azure NetApp Files per rete virtuale 1 1
Gruppi di sicurezza di rete (NSG) nelle subnet delegate di Azure NetApp Files No
Route definite dall'utente (UDR) nelle subnet delegate di Azure NetApp Files No
Connessione ivity to Endpoint privati Sì* No
Connessione ivity to Endpoint servizio No
Criteri di Azure (ad esempio, criteri di denominazione personalizzati) nell'interfaccia di Azure NetApp Files No No
Servizi di bilanciamento del carico per il traffico di Azure NetApp Files No No
Doppia rete virtuale stack (IPv4 e IPv6) No
(Supportato solo IPv4)
No
(Supportato solo IPv4)
Traffico indirizzato tramite appliance virtuale di rete dalla rete virtuale con peering No

* L'applicazione di gruppi di sicurezza di rete di Azure nella subnet di collegamento privato ad Azure Key Vault non è supportata per le chiavi gestite dal cliente di Azure NetApp Files. I gruppi di sicurezza di rete non influiscono sulla connettività a collegamento privato a meno che i criteri di rete degli endpoint privati non siano abilitati nella subnet. È consigliabile mantenere disabilitata questa opzione.

Topologie di rete supportate

La tabella seguente descrive le topologie di rete supportate da ogni configurazione delle funzionalità di rete di Azure NetApp Files.

Topologie Funzionalità di rete standard Funzionalità di rete di base
Connettività a un volume in una rete virtuale locale
Connettività a un volume in una rete virtuale con peering (stessa area)
Connettività a un volume in una rete virtuale con peering (in aree diverse o con peering globale) Sì* No
Connettività a un volume sul gateway ExpressRoute
ExpressRoute (ER) FastPath No
Connettività da locale a un volume in una rete virtuale spoke tramite gateway ExpressRoute e peering di rete virtuale con transito tramite gateway
Connettività da locale a un volume in una rete virtuale spoke tramite gateway VPN
Connettività da locale a un volume in una rete virtuale spoke tramite gateway VPN e peering di rete virtuale con transito tramite gateway
Connessione ivity su gateway VPN attivi/passivi
Connessione ivity su gateway VPN attivi/attivi No
Connessione ivity rispetto ai gateway con ridondanza della zona attiva/attiva No
Connessione ivity sui gateway con ridondanza della zona attiva/passiva
Connessione ivity over rete WAN virtuale (VWAN) No

* Questa opzione comporta un addebito sul traffico in ingresso e in uscita che usa una connessione di peering di rete virtuale. Per altre informazioni, vedere Prezzi di Rete virtuale. Per altre informazioni generali, vedere Peering reti virtuali.

Rete virtuale per volumi di Azure NetApp Files

In questa sezione vengono illustrati i concetti che possono semplificare la pianificazione di una rete virtuale.

Reti virtuali di Azure

Prima di effettuare il provisioning di un volume di Azure NetApp Files, è necessario creare una rete virtuale di Azure o usarne una già esistente nella stessa sottoscrizione. La rete virtuale definisce il limite di rete del volume. Per altre informazioni sulla creazione di reti virtuali, vedere la documentazione sulle reti virtuali di Azure.

Subnet

Le subnet segmentano la rete virtuale in spazi di indirizzi separati usabili dalle risorse di Azure contenute. I volumi di Azure NetApp Files sono contenuti in una subnet per scopi specifici denominata subnet delegata.

La delega della subnet offre al servizio Azure NetApp Files autorizzazioni esplicite per creare le risorse specifiche del servizio nella subnet. Usa inoltre un identificatore univoco per la distribuzione del servizio. In questo caso, viene creata un'interfaccia di rete per abilitare la connettività ad Azure NetApp Files.

Se si usa una nuova rete virtuale, è possibile creare una subnet e delegarla ad Azure NetApp Files seguendo le istruzioni riportate in Delegare una subnet ad Azure NetApp Files. È anche possibile delegare una subnet vuota esistente non delegata ad altri servizi.

Se la rete virtuale è con peering con un'altra rete virtuale, non è possibile espandere lo spazio indirizzi della rete virtuale. È questo il motivo per cui la nuova subnet delegata deve essere creata nello spazio di indirizzi della rete virtuale. Se è necessario estendere lo spazio di indirizzi, prima di eseguire questa operazione è necessario eliminare il peering della rete virtuale.

Importante

Verificare che le dimensioni dello spazio indirizzi della rete virtuale di Azure NetApp Files siano maggiori della subnet delegata.

Ad esempio, se la subnet delegata è /24, lo spazio di indirizzi della rete virtuale contenente la subnet deve essere /23 o superiore. La non conformità con questa linea guida può causare problemi imprevisti in alcuni modelli di traffico: il traffico che attraversa una topologia hub-spoke che raggiunge Azure NetApp Files tramite un'appliance virtuale di rete non funziona correttamente. Inoltre, questa configurazione può causare errori durante la creazione di volumi SMB e CIFS se tentano di raggiungere DNS tramite la topologia di rete hub-spoke.

È anche consigliabile che le dimensioni della subnet delegata siano almeno /25 per i carichi di lavoro SAP e /26 per altri scenari di carico di lavoro.

Route definite dall'utente e gruppi di sicurezza di rete

Se la subnet ha una combinazione di volumi con le funzionalità di rete Standard e Basic, le route definite dall'utente e i gruppi di sicurezza di rete (NSG) applicati alle subnet delegate verranno applicate solo ai volumi con le funzionalità di rete Standard.

Nota

L'associazione dei gruppi di sicurezza di rete a livello di interfaccia di rete non è supportata per le interfacce di rete di Azure NetApp Files.

La configurazione di route definite dall'utente nelle subnet della macchina virtuale di origine con il prefisso dell'indirizzo della subnet delegata e l'hop successivo perché L'appliance virtuale di rete non è supportata per i volumi con le funzionalità di rete di base. Un'impostazione di questo tipo genererà problemi di connettività.

Nota

Per accedere a un volume di Azure NetApp Files da una rete locale tramite un gateway di rete virtuale (ExpressRoute o VPN) e un firewall, configurare la tabella di route assegnata al gateway di rete virtuale per includere l'indirizzo /32 IPv4 del volume di Azure NetApp Files elencato e puntare al firewall come hop successivo. L'uso di uno spazio indirizzi aggregato che include l'indirizzo IP del volume di Azure NetApp Files non inoltra il traffico di Azure NetApp Files al firewall.

Nota

Se si vuole configurare una route UDR nella rete virtuale della macchina virtuale, per controllare il routing dei pacchetti destinati a un volume Standard di Azure NetApp Files con peering a livello di area, il prefisso UDR deve essere più specifico o uguale alle dimensioni della subnet delegata del volume di Azure NetApp Files. Se il prefisso UDR è di dimensioni maggiori rispetto alle dimensioni della subnet delegata, non sarà efficace.

Ambienti nativi di Azure

Il diagramma seguente illustra un ambiente nativo di Azure:

Diagram depicting Azure native environment setup.

Rete virtuale locale

Uno scenario di base consiste nel creare o connettersi a un volume di Azure NetApp Files da una macchina virtuale nella stessa rete virtuale. Per la rete virtuale 2 nel diagramma, il volume 1 viene creato in una subnet delegata e può essere montato nella macchina virtuale 1 nella subnet predefinita.

Peering reti virtuali

Se si hanno altre reti virtuali nella stessa area in cui è necessario accedere alle risorse dell'altro, le reti virtuali possono essere connesse usando il peering reti virtuali per abilitare la connettività sicura tramite l'infrastruttura di Azure.

Si considerino la rete virtuale 2 e la rete virtuale 3 del diagramma precedente. Se la macchina virtuale 1 deve connettersi alla macchina virtuale 2 o al volume 2 oppure se la macchina virtuale 2 deve connettersi alla macchina virtuale 1 o al volume 1, è necessario abilitare il peering di reti virtuali tra la rete virtuale 2 e la rete virtuale 3.

Si consideri anche uno scenario in cui la rete virtuale 1 è con peering con la rete virtuale 2 e la rete virtuale 2 è con peering con la rete virtuale 3 nella stessa area. Le risorse della rete virtuale 1 possono connettersi alle risorse nella rete virtuale 2, ma non possono connettersi alle risorse nella rete virtuale 3, a meno che la rete virtuale 1 e la rete virtuale 3 non siano sottoposte a peering.

Nel diagramma precedente, anche se la macchina virtuale 3 può connettersi al volume 1, la macchina virtuale 4 non può connettersi al volume 2. Il motivo è che le reti virtuali spoke non sono sottoposte a peering e il routing di transito non è supportato tramite peering reti virtuali.

Peering reti virtuali globali o tra aree

Il diagramma seguente illustra un ambiente nativo di Azure con peering reti virtuali tra aree.

Diagram depicting Azure native environment setup with cross-region VNet peering.

Con le funzionalità di rete Standard, le macchine virtuali possono connettersi ai volumi in un'altra area tramite peering reti virtuali globali o tra aree. Il diagramma precedente aggiunge una seconda area alla configurazione nella sezione peering reti virtuali locali. Per la rete virtuale 4 in questo diagramma, un volume di Azure NetApp Files viene creato in una subnet delegata e può essere montato in VM5 nella subnet dell'applicazione.

Nel diagramma vm2 nell'area 1 può connettersi al volume 3 nell'area 2. La macchina virtuale5 nell'area 2 può connettersi al volume 2 nell'area 1 tramite il peering reti virtuali tra l'area 1 e l'area 2.

Ambienti ibridi

Il diagramma seguente illustra un ambiente ibrido:

Diagram depicting hybrid networking environment.

In uno scenario ibrido, le applicazioni dei data center locali devono accedere alle risorse in Azure. Questo è il caso se si vuole estendere il data center ad Azure o si vogliono usare i servizi nativi di Azure o per il ripristino di emergenza. Per informazioni su come connettere più risorse locali a risorse di Azure tramite una rete VPN da sito a sito o un circuito ExpressRoute, vedere le opzioni di pianificazione di Gateway VPN.

In una topologia di rete hub-spoke, l'hub è una rete virtuale in Azure che svolge la funzione di punto centrale di connettività alla rete locale. Gli spoke sono reti virtuali di cui viene eseguito il peering con l'hub e possono essere usati per isolare i carichi di lavoro.

A seconda della configurazione, è possibile connettere le risorse locali alle risorse disponibili nell'hub o negli spoke.

Nella topologia sopra illustrata, la rete locale è connessa a una rete virtuale hub in Azure e, nella stessa area, sono presenti due reti virtuali spoke di cui è stato eseguito il peering con la rete virtuale hub. In questo scenario, le opzioni di connettività supportate per i volumi di Azure NetApp Files sono le seguenti:

  • Le risorse locali "macchina virtuale 1" e "macchina virtuale 2" possono connettersi al volume 1 dell'hub tramite una VPN da sito a sito o un circuito ExpressRoute.
  • Le risorse locali VM 1 e VM 2 possono connettersi al volume 2 o al volume 3 tramite una VPN da sito a sito e un peering reti virtuali a livello di area.
  • La macchina virtuale 3 nella rete virtuale hub può connettersi al volume 2 nella rete virtuale spoke 1 e al volume 3 nella rete virtuale spoke 2.
  • La macchina virtuale 4 della rete virtuale spoke 1 e la macchina virtuale 5 della rete virtuale spoke 2 possono connettersi al volume 1 nella rete virtuale hub.
  • La macchina virtuale 4 nella rete virtuale spoke 1 non può connettersi al volume 3 nella rete virtuale spoke 2. Inoltre, la macchina virtuale 5 in spoke VNet2 non può connettersi al volume 2 nella rete virtuale spoke 1. Questo è il caso perché le reti virtuali spoke non sono con peering e il routing di transito non è supportato tramite peering reti virtuali.
  • Nell'architettura precedente, se è presente anche un gateway nella rete virtuale spoke, la connettività al volume ANF dalla connessione locale tramite il gateway nell'hub andrà persa. Per impostazione predefinita, infatti, viene assegnata la preferenza al gateway della rete virtuale spoke e, quindi, solo i computer che si connettono tramite quel gateway possono connettersi al volume di Azure NetApp Files.

Passaggi successivi