Creare un pool di Azure Batch in una rete virtuale
Quando si crea un pool di Azure Batch, è possibile effettuare il provisioning del pool in una subnet di un Rete virtuale di Azure specificato. Questo articolo illustra come configurare un pool di Batch in un Rete virtuale.
Perché usare un Rete virtuale?
I nodi di calcolo in un pool possono comunicare tra loro, ad esempio per eseguire attività a istanze multiple, senza richiedere un Rete virtuale separato. Tuttavia, per impostazione predefinita, i nodi in un pool non possono comunicare con una macchina virtuale (VM) esterna al pool, ad esempio licenze o file server.
Per consentire ai nodi di calcolo di comunicare in modo sicuro con altre macchine virtuali o con una rete locale, è possibile effettuare il provisioning del pool in una subnet di un Rete virtuale.
Prerequisiti
Autenticazione. Per usare un'Rete virtuale di Azure, l'API client batch deve usare l'autenticazione Microsoft Entra. Per altre informazioni, vedere Autenticare le soluzioni del servizio Batch con Active Directory.
Un Rete virtuale di Azure. Per preparare una Rete virtuale con una o più subnet in anticipo, è possibile usare il portale di Azure, Azure PowerShell, l'interfaccia della riga di comando di Microsoft Azure o altri metodi.
Per creare un Rete virtuale basato su Azure Resource Manager, vedere Creare una rete virtuale. È consigliabile usare un Rete virtuale basato su Resource Manager per le nuove distribuzioni ed è supportato solo nei pool che usano la configurazione della macchina virtuale.
Per creare un Rete virtuale classico, vedere Creare una rete virtuale (classica) con più subnet. Un Rete virtuale classico è supportato solo nei pool che usano Servizi cloud Configurazione.
Importante
Evitare di usare la rete virtuale del pool di Azure Batch 172.17.0.0/16. È l'impostazione predefinita per la rete bridge Docker e può essere in conflitto con altre reti che si desidera connettere alla rete virtuale. La creazione di una rete virtuale per il pool di Azure Batch richiede un'attenta pianificazione dell'infrastruttura di rete.
Requisiti generali della rete virtuale
Il Rete virtuale deve trovarsi nella stessa sottoscrizione e nella stessa area dell'account Batch usato per creare il pool.
La subnet specificata per il pool deve avere un numero sufficiente di indirizzi IP non assegnati per contenere il numero di macchine virtuali di destinazione per il pool, sufficiente per contenere le
targetDedicatedNodesproprietà etargetLowPriorityNodesdel pool. Se la subnet non dispone di sufficienti indirizzi IP non assegnati, il pool alloca parzialmente i nodi di calcolo e si verifica un errore di ridimensionamento.Se non si usa la comunicazione semplificata dei nodi di calcolo, è necessario risolvere gli endpoint Archiviazione di Azure usando qualsiasi server DNS personalizzato che gestisce la rete virtuale. In particolare, gli URL con formato
<account>.table.core.windows.net,<account>.queue.core.windows.nete<account>.blob.core.windows.netdevono essere risolvibili.È possibile creare più pool nella stessa rete virtuale o nella stessa subnet , purché disponga di spazio indirizzi sufficiente. Un singolo pool non può esistere in più reti virtuali o subnet.
Altri requisiti di rete virtuale variano a seconda che il pool di Batch si trova in VirtualMachineConfiguration o CloudServiceConfiguration. VirtualMachineConfiguration per i pool di Batch è consigliabile, perché CloudServiceConfiguration i pool sono deprecati.
Importante
I pool di batch possono essere configurati in una delle due modalità di comunicazione dei nodi. La modalità di comunicazione dei nodi classica è la posizione in cui il servizio Batch avvia la comunicazione con i nodi di calcolo. La modalità di comunicazione semplificata dei nodi è la posizione in cui i nodi di calcolo avviano la comunicazione con il servizio Batch.
- Qualsiasi rete virtuale o rete virtuale con peering che verrà usata per i pool di Batch non deve avere intervalli di indirizzi IP sovrapposti con la rete definita dal software o il routing nei nodi di calcolo. Un'origine comune per i conflitti deriva dall'uso di un runtime del contenitore, ad esempio Docker. Docker creerà un bridge di rete predefinito con un intervallo di subnet definito di
172.17.0.0/16. Tutti i servizi in esecuzione all'interno di una rete virtuale in tale spazio di indirizzi IP predefinito sono in conflitto con i servizi nel nodo di calcolo, ad esempio l'accesso remoto tramite SSH.
Pool nella configurazione della macchina virtuale
Requisiti:
- Rete virtuale supportate: solo reti virtuali basate su Azure Resource Manager.
- ID subnet: quando si specifica la subnet usando le API Batch, usare l'identificatore della risorsa della subnet. L'identificatore della subnet è nel formato:
/subscriptions/{subscription}/resourceGroups/{group}/providers/Microsoft.Network/virtualNetworks/{network}/subnets/{subnet}
- Autorizzazioni: controllare se i criteri di sicurezza o i blocchi nella sottoscrizione o nel gruppo di risorse dell'Rete virtuale limitano le autorizzazioni di un utente per gestire il Rete virtuale.
- Risorse di rete: Batch crea automaticamente più risorse di rete nel gruppo di risorse contenente il Rete virtuale.
Importante
Per ogni 100 nodi dedicati o con priorità bassa, Batch crea un gruppo di sicurezza di rete (NSG), un indirizzo IP pubblico e un servizio di bilanciamento del carico. Queste risorse sono limitate in base alle quote delle risorse della sottoscrizione. Per pool di grandi dimensioni potrebbe essere necessario richiedere un aumento della quota per una o più di queste risorse.
Gruppi di sicurezza di rete per i pool di configurazione della macchina virtuale: Impostazione predefinita di Batch
Batch crea un gruppo di sicurezza di rete (NSG) a livello di interfaccia di rete di ogni distribuzione del set di scalabilità di macchine virtuali all'interno di un pool di Batch. Per i pool che non hanno indirizzi IP pubblici nella simplified comunicazione dei nodi di calcolo, i gruppi di sicurezza di rete non vengono creati.
Per fornire la comunicazione necessaria tra i nodi di calcolo e il servizio Batch, questi gruppi di sicurezza di rete sono configurati in modo che:
- Traffico TCP in ingresso sulle porte 29876 e 29877 dagli indirizzi IP del servizio Batch che corrispondono a BatchNodeManagement.tag del servizio di area . Questa regola viene creata solo in modalità di comunicazione del
classicpool. - Traffico TCP in ingresso sulla porta 22 (nodi Linux) o sulla porta 3389 (nodi Windows) per consentire rispettivamente l'accesso remoto per SSH o RDP sulle porte predefinite. Per determinati tipi di attività a istanze multiple in Linux, ad esempio MPI, potrebbe essere necessario consentire il traffico SSH per gli indirizzi IP nella subnet contenente nodi di calcolo batch. Alcuni runtime MPI possono richiedere l'avvio tramite SSH, che in genere viene instradato nello spazio indirizzi IP privato. Questo traffico potrebbe essere bloccato per ogni regola del gruppo di sicurezza di rete a livello di subnet.
- In uscita qualsiasi traffico sulla porta 443 agli indirizzi IP del servizio Batch che corrispondono a BatchNodeManagement.tag del servizio di area .
- Traffico in uscita su qualsiasi porta verso la rete virtuale. Questa regola potrebbe essere modificata in base alle regole del gruppo di sicurezza di rete a livello di subnet.
- Traffico in uscita su qualsiasi porta verso Internet. Questa regola potrebbe essere modificata in base alle regole del gruppo di sicurezza di rete a livello di subnet.
Importante
Prestare attenzione se si modificano o aggiungono regole in ingresso o in uscita nei gruppi di sicurezza di rete configurati per Batch. Se la comunicazione con i nodi di calcolo nella subnet specificata viene negata da un gruppo di sicurezza di rete, il servizio Batch imposta lo stato dei nodi di calcolo su Non utilizzabile. Inoltre, non è necessario applicare blocchi di risorse a qualsiasi risorsa creata da Batch, perché ciò può impedire la pulizia delle risorse a seguito di azioni avviate dall'utente, ad esempio l'eliminazione di un pool.
Gruppi di sicurezza di rete per i pool di configurazione della macchina virtuale: specifica delle regole a livello di subnet
Se si dispone di un gruppo di sicurezza di rete associato alla subnet per i nodi di calcolo Batch, è necessario configurare questo gruppo di sicurezza di rete con almeno le regole di sicurezza in ingresso e in uscita visualizzate nelle tabelle seguenti.
Avviso
Gli indirizzi IP del servizio Batch possono cambiare nel tempo. Pertanto, è consigliabile usare BatchNodeManagement.tag del servizio di area per le regole del gruppo di sicurezza di rete indicate nelle tabelle seguenti. Evitare di popolare le regole del gruppo di sicurezza di rete con indirizzi IP specifici del servizio Batch.
Regole di sicurezza in ingresso
Configurare il traffico in ingresso sulla porta 3389 (Windows) o 22 (Linux) solo se è necessario consentire l'accesso remoto ai nodi di calcolo provenienti da origini esterne rispettivamente nelle porte RDP o SSH predefinite. Potrebbe essere necessario consentire il traffico SSH in Linux se è necessario il supporto per le attività a istanze multiple con determinati runtime MPI (Message Passing Interface) nella subnet contenente i nodi di calcolo Batch perché il traffico potrebbe essere bloccato per ogni regola del gruppo di sicurezza di rete a livello di subnet. Il traffico MPI è in genere sullo spazio indirizzi IP privato, ma può variare tra i runtime MPI e la configurazione di runtime. Consentire il traffico su queste porte non è strettamente necessario affinché i nodi di calcolo del pool siano utilizzabili. È anche possibile disabilitare l'accesso remoto predefinito su queste porte tramite la configurazione degli endpoint del pool.
Regole di sicurezza in uscita
In uscita a BatchNodeManagement. Se si usano attività di Gestione processi o se le attività devono comunicare con il servizio Batch, è necessario specificare il tag del servizio region service in classic modalità di comunicazione del pool. Per l'uscita in BatchNodeManagement. area in simplified modalità di comunicazione del pool, il servizio Batch attualmente usa solo il protocollo TCP, ma UDP potrebbe essere necessario per la compatibilità futura. Per i pool senza indirizzi IP pubblici che usano simplified la modalità di comunicazione e con un endpoint privato di gestione dei nodi, non è necessario un gruppo di sicurezza di rete.
Per altre informazioni sulle regole di sicurezza in uscita per BatchNodeManagement.tag del servizio di area , vedere Usare la comunicazione semplificata dei nodi di calcolo.
Pool nella configurazione Servizi cloud
Avviso
Servizi cloud pool di configurazione sono deprecati. Usare invece pool di configurazione macchina virtuale.
Requisiti:
Rete virtuale supportate: solo Rete virtuale classiche.
ID subnet: quando si specifica la subnet usando le API Batch, usare l'identificatore della risorsa della subnet. L'identificatore della subnet è nel formato:
/subscriptions/{subscription}/resourceGroups/{group}/providers/Microsoft.ClassicNetwork/virtualNetworks/{network}/subnets/{subnet}Autorizzazioni: l'entità
Microsoft Azure Batchservizio deve avere ilClassic Virtual Machine Contributorruolo di Azure per il Rete virtuale specificato.
Gruppi di sicurezza di rete per pool di configurazione di Servizi cloud
La subnet deve consentire la comunicazione in ingresso dal servizio Batch per poter pianificare le attività nei nodi di calcolo e deve consentire la comunicazione in uscita per comunicare con Archiviazione di Azure o altre risorse.
Non è necessario specificare un gruppo di sicurezza di rete, perché Batch configura la comunicazione in ingresso solo dagli indirizzi IP batch ai nodi del pool. Tuttavia, se alla subnet specificata sono associati gruppi di sicurezza di rete (NSG) e/o un firewall, configurare le regole di sicurezza in ingresso e in uscita, come illustrato nelle tabelle seguenti. Se la comunicazione con i nodi di calcolo nella subnet specificata viene negata da un gruppo di sicurezza di rete, il servizio Batch imposta lo stato dei nodi di calcolo su Non utilizzabile.
Configurare il traffico in ingresso sulla porta 3389 per Windows se è necessario per consentire l'accesso RDP ai nodi del pool. Questa regola non è necessaria affinché i nodi del pool siano utilizzabili.
Regole di sicurezza in ingresso
| Indirizzi IP di origine | Porte di origine | Destinazione | Porte di destinazione | Protocollo | Azione |
|---|---|---|---|---|---|
| Qualsiasi Anche se questa regola richiede in modo efficace tutti, il servizio Batch applica una regola ACL a livello di ogni nodo che filtra tutti gli indirizzi IP non del servizio Batch. |
* | Any | 10100, 20100, 30100 | TCP | Consenti |
| Facoltativo, per consentire l'accesso RDP ai nodi di calcolo. | * | Any | 3389 | TCP | Consenti |
Regole di sicurezza in uscita
| Origine | Porte di origine | Destinazione | Porte di destinazione | Protocollo | Azione |
|---|---|---|---|---|---|
| Qualsiasi | * | Qualsiasi | 443 | Qualsiasi | Consenti |
Creare un pool con un Rete virtuale nel portale di Azure
Dopo aver creato il Rete virtuale e aver assegnato una subnet, è possibile creare un pool di Batch con tale Rete virtuale. Seguire questa procedura per creare un pool dal portale di Azure:
Cercare e selezionare Account Batch nella barra di ricerca nella parte superiore del portale di Azure. Selezionare l'account Batch. Questo account deve trovarsi nella stessa sottoscrizione e nella stessa area del gruppo di risorse contenente il Rete virtuale che si intende usare.
Selezionare Pool nel riquadro di spostamento sinistro.
Nella finestra Pool selezionare Aggiungi.
Nella pagina Aggiungi pool selezionare le opzioni e immettere le informazioni per il pool. Per altre informazioni sulla creazione di pool per l'account Batch, vedere Creare un pool di nodi di calcolo. Dimensioni dei nodi, Nodi dedicati di destinazione e Nodi spot/priorità bassa e tutte le impostazioni facoltative desiderate.
In Rete virtuale selezionare la rete virtuale e la subnet che si desidera usare.
Selezionare OK per creare il pool.
Importante
Se si tenta di eliminare una subnet usata da un pool, verrà visualizzato un messaggio di errore. Prima di eliminare tale subnet, è necessario eliminare tutti i pool che usano una subnet.
Route definite dall'utente per il tunneling forzato
Potrebbero essere previsti requisiti nell'organizzazione per reindirizzare (forzare) il traffico associato a Internet dalla subnet alla posizione locale per l'ispezione e la registrazione. Inoltre, potrebbe essere stato abilitato il tunneling forzato per le subnet nel Rete virtuale.
Per assicurarsi che i nodi del pool funzionino in un Rete virtuale con tunneling forzato abilitato, è necessario aggiungere le route definite dall'utente seguenti per tale subnet.
Per i pool classici della modalità di comunicazione:
Il servizio Batch deve comunicare con i nodi per la pianificazione delle attività. Per abilitare questa comunicazione, aggiungere una route definita dall'utente corrispondente a BatchNodeManagement.tag del servizio di areanell'area in cui è presente l'account Batch. Impostare il tipo hop successivo su Internet.
Assicurarsi che la rete locale non blocchi il traffico TCP in uscita per Archiviazione di Azure sulla porta di destinazione 443 (in particolare gli URL del formato
*.table.core.windows.net,*.queue.core.windows.nete*.blob.core.windows.net).
Per i pool di modalità di comunicazione semplificata senza usare l'endpoint privato di gestione dei nodi:
- Assicurarsi che la rete locale non blocchi il traffico TCP/UDP in uscita verso Azure BatchNodeManagement.tag del servizio di area sulla porta di destinazione 443. Attualmente viene usato solo il protocollo TCP, ma UDP potrebbe essere necessario per la compatibilità futura.
Per tutti i pool:
- Se si usano i montaggi di file virtuali, esaminare i requisiti di rete e assicurarsi che non venga bloccato alcun traffico necessario.
Avviso
Gli indirizzi IP del servizio Batch possono cambiare nel tempo. Per evitare interruzioni dovute alle modifiche all'indirizzo IP del servizio Batch, non specificare direttamente gli indirizzi IP. Usare invece BatchNodeManagement.tag del servizio di area.