Procedure consigliate per Azure Batch

  • Articolo

Questo articolo illustra le procedure consigliate e i suggerimenti utili per l'uso efficace del servizio Azure Batch. Questi suggerimenti consentono di migliorare le prestazioni ed evitare problemi di progettazione nelle soluzioni Batch.

Suggerimento

Per indicazioni sulla sicurezza in Azure Batch, vedere Procedure consigliate per la sicurezza e la conformità di Batch.

Pool

I pool sono le risorse di calcolo per l'esecuzione di processi nel servizio Batch. Le sezioni seguenti includono raccomandazioni per l'uso di pool di Batch.

Configurazione e denominazione del pool

  • Modalità di allocazione pool: quando si crea un account Batch, è possibile scegliere tra due modalità di allocazione del pool: servizio Batch o sottoscrizione utente. Nella maggior parte dei casi si userà la modalità predefinita del servizio Batch, in cui i pool vengono allocati dietro le quinte nelle sottoscrizioni gestite da Batch. Nella modalità sottoscrizione utente alternativa, le macchine virtuali e le altre risorse di Batch vengono create direttamente nella sottoscrizione in fase di creazione di un pool. Gli account di sottoscrizione utente vengono usati principalmente per abilitare un piccolo ma importante subset di scenari. Per altre informazioni, vedere Configurazione per la modalità di sottoscrizione utente.

  • virtualMachineConfiguration oppure cloudServiceConfiguration: anche se attualmente è possibile creare pool usando una delle due configurazioni, è necessario configurare nuovi pool usando virtualMachineConfiguration e non cloudServiceConfiguration. Tutte le funzionalità correnti e nuove di Batch saranno supportate dai pool di configurazione delle macchine virtuali. I pool di configurazione del servizio cloud non supportano tutte le funzionalità e non sono pianificate nuove funzionalità. Non sarà possibile creare nuovi cloudServiceConfiguration pool o aggiungere nuovi nodi ai pool esistenti dopo il 29 febbraio 2024. Per altre informazioni, vedere Eseguire la migrazione della configurazione del pool di Batch da Servizi cloud a macchina virtuale.

  • classic o simplified modalità di comunicazione dei nodi: i pool possono essere configurati in una delle due modalità di comunicazione dei nodi, classica o semplificata. Nel modello di comunicazione dei nodi classico, il servizio Batch avvia la comunicazione con i nodi di calcolo e anche i nodi di calcolo richiedono la comunicazione con Archiviazione di Azure. Nel modello di comunicazione semplificata dei nodi, i nodi di calcolo avviano la comunicazione con il servizio Batch. A causa dell'ambito ridotto delle connessioni in ingresso/in uscita necessarie e non è necessario Archiviazione di Azure l'accesso in uscita per l'operazione di base, è consigliabile usare il modello di comunicazione semplificata dei nodi. Alcuni miglioramenti futuri al servizio Batch richiederanno anche il modello di comunicazione semplificata dei nodi. Il modello di comunicazione dei nodi classico verrà ritirato il 31 marzo 2026.

  • Considerazioni sul tempo di esecuzione di processi e attività: se sono presenti processi costituiti principalmente da attività a esecuzione breve e i conteggi totali delle attività previsti sono di piccole dimensioni, in modo che il tempo di esecuzione complessivo previsto del processo non sia lungo, non allocare un nuovo pool per ogni processo. Il tempo di allocazione dei nodi ridurrà il tempo di esecuzione del processo.

  • Più nodi di calcolo: i singoli nodi non sono sempre disponibili. Anche se non comuni, gli errori dell'hardware, gli aggiornamenti del sistema operativo e una serie di altri problemi possono portare offline i singoli nodi. Se il carico di lavoro di Batch richiede un avanzamento deterministico e garantito, è consigliabile allocare pool con più nodi.

  • Immagini con date di fine vita (EOL) in sospeso: è consigliabile evitare immagini con date di fine vita (EOL) di supporto batch in sospeso. Queste date possono essere individuate tramite l'API, PowerShell o l'interfaccia della ListSupportedImages riga di comando di Azure. È responsabilità dell'utente aggiornare periodicamente la visualizzazione delle date EOL pertinenti ai pool ed eseguire la migrazione dei carichi di lavoro prima che si verifichi la data EOL. Se si usa un'immagine personalizzata con un agente del nodo specificato, assicurarsi di seguire le date di fine del ciclo di vita di Batch per l'immagine con cui l'immagine personalizzata è derivata o allineata. Un'immagine senza una data specificata batchSupportEndOfLife indica che tale data non è stata ancora determinata dal servizio Batch. L'assenza di una data non indica che la rispettiva immagine sarà supportata per un periodo illimitato. Una data EOL può essere aggiunta o aggiornata in futuro in qualsiasi momento.

  • SKU di macchine virtuali con date di fine vita (EOL) in sospeso: come per le immagini delle macchine virtuali, gli SKU o le famiglie di macchine virtuali possono raggiungere anche la fine del ciclo di vita (EOL). Queste date possono essere individuate tramite l'API, PowerShell o l'interfaccia della ListSupportedVirtualMachineSkus riga di comando di Azure. Pianificare la migrazione del carico di lavoro a uno SKU di vm non EOL creando un nuovo pool con uno SKU di macchina virtuale supportato appropriato. L'assenza di una data associata batchSupportEndOfLife per uno SKU di macchina virtuale non indica che lo SKU di macchina virtuale specifico sarà supportato per un periodo illimitato. Una data EOL può essere aggiunta o aggiornata in futuro in qualsiasi momento.

  • Nomi di risorse univoci: le risorse batch (processi, pool e così via) spesso vengono e passano nel tempo. Ad esempio, è possibile creare un pool il lunedì, eliminarlo il martedì e quindi creare un altro pool simile il giovedì. A ogni nuova risorsa creata è necessario assegnare un nome univoco che non è mai stato usato prima. È possibile creare un'univocità usando un GUID (come nome completo della risorsa o come parte di esso) o incorporando la data e l'ora di creazione della risorsa nel nome della risorsa. Batch supporta DisplayName, che può assegnare a una risorsa un nome più leggibile anche se l'ID risorsa effettivo è qualcosa che non è descrittivo. L'uso di nomi univoci consente di distinguere più facilmente la risorsa specifica a cui fanno riferimento log e metriche. Rimuove anche l'ambiguità se è necessario presentare un caso di supporto per una risorsa.

  • Continuità durante la manutenzione e l'errore del pool: è consigliabile che i processi usino i pool in modo dinamico. Se i processi usano lo stesso pool per tutte le operazioni, è possibile che non vengano eseguiti se si verificano problemi in tale pool. Questo principio è particolarmente importante per i carichi di lavoro sensibili al tempo. Ad esempio, selezionare o creare un pool in modo dinamico quando si pianifica ogni processo oppure è possibile eseguire l'override del nome del pool in modo che sia possibile ignorare un pool non integro.

  • Continuità aziendale durante la manutenzione e l'errore del pool: esistono molti motivi per cui un pool potrebbe non aumentare le dimensioni desiderate, ad esempio errori interni o vincoli di capacità. Assicurarsi di poter retargetare i processi in un pool diverso ,possibilmente con dimensioni di vm diverse usando UpdateJob, se necessario. Evitare di basarsi su un ID pool statico con l'aspettativa che non verrà mai eliminata e non cambierà mai.

Sicurezza del pool

Limite di isolamento

Ai fini dell'isolamento, se lo scenario richiede l'isolamento di processi o attività l'uno dall'altro, farlo in pool separati. Un pool è il limite di isolamento della sicurezza in Batch e, per impostazione predefinita, due pool non sono visibili o in grado di comunicare tra loro. Evitare di usare account Batch separati come mezzo di isolamento della sicurezza, a meno che l'ambiente più ampio da cui opera l'account Batch richieda l'isolamento.

Aggiornamenti dell'agente del nodo Batch

Gli agenti del nodo Batch non vengono aggiornati automaticamente per i pool con nodi di calcolo diversi da zero. Per assicurarsi che i pool di Batch ricevano le correzioni di sicurezza e gli aggiornamenti più recenti per l'agente del nodo Batch, è necessario ridimensionare il pool in zero nodi di calcolo o ricreare il pool. È consigliabile monitorare le note sulla versione dell'agente del nodo Batch per comprendere le modifiche apportate alle nuove versioni dell'agente del nodo Batch. Controllare regolarmente la disponibilità di aggiornamenti quando sono stati rilasciati consente di pianificare gli aggiornamenti alla versione più recente dell'agente.

Prima di ricreare o ridimensionare il pool, è necessario scaricare i log degli agenti del nodo a scopo di debug se si verificano problemi con il pool di Batch o i nodi di calcolo. Questo processo è illustrato più avanti nella sezione Nodi .

Nota

Per indicazioni generali sulla sicurezza in Azure Batch, vedere Procedure consigliate per la sicurezza e la conformità di Batch.

Aggiornamenti del sistema operativo

È consigliabile aggiornare l'immagine della macchina virtuale selezionata per un pool di Batch con gli aggiornamenti della sicurezza forniti dall'autore più recente. Alcune immagini possono eseguire aggiornamenti automatici all'avvio (o poco dopo), che possono interferire con determinate azioni dirette dall'utente, ad esempio il recupero degli aggiornamenti del repository dei pacchetti (ad esempio apt update) o l'installazione di pacchetti durante azioni come StartTask.

Azure Batch non verifica o garantisce che le immagini consentite per l'uso con il servizio abbiano gli aggiornamenti della sicurezza più recenti. Aggiornamenti alle immagini si trovano sotto la visualizzazione dell'autore dell'immagine e non di Azure Batch. Per determinate immagini pubblicate in microsoft-azure-batch, non c'è alcuna garanzia che queste immagini vengano mantenute aggiornate con l'immagine derivata upstream.

Durata e fatturazione del pool

La durata del pool può variare a seconda del metodo di allocazione e delle opzioni applicate alla relativa configurazione. I pool possono avere una durata arbitraria e un numero variabile di nodi di calcolo in qualsiasi momento. È responsabilità dell'utente gestire i nodi di calcolo nel pool in modo esplicito o tramite funzionalità fornite dal servizio (scalabilità automatica o pool automatico).

  • Ricreazione piscina: evitare di eliminare e ricreare pool su base giornaliera. Creare invece un nuovo pool e quindi aggiornare i processi esistenti in modo che puntino al nuovo pool. Una volta spostate tutte le attività nel nuovo pool, eliminare quello precedente.

  • Efficienza e fatturazione del pool: Batch stesso non comporta costi aggiuntivi. Tuttavia, si comportano addebiti per le risorse di Azure usate, ad esempio calcolo, archiviazione, rete e qualsiasi altra risorsa che potrebbe essere necessaria per il carico di lavoro batch. Si riceve un addebito per ogni nodo di calcolo del pool, indipendentemente dallo stato in cui si trova. Per altre informazioni, vedere Analisi dei costi e budget per Azure Batch.

  • Dischi temporanei del sistema operativo: i pool di configurazione delle macchine virtuali possono usare dischi temporanei del sistema operativo, che creano il disco del sistema operativo nella cache della macchina virtuale o unità SSD temporanea, per evitare costi aggiuntivi associati ai dischi gestiti.

Errori di allocazione del pool

Gli errori di allocazione del pool possono verificarsi in qualsiasi momento durante la prima allocazione o con i successivi ridimensionamenti. Questi errori possono essere dovuti all'esaurimento temporaneo della capacità in un'area o a errori in altri servizi di Azure su cui Si basa Batch. La quota di core non è una garanzia, ma piuttosto un limite.

Tempo di inattività non pianificato

È possibile che i pool di Batch riscontrino eventi di tempi di inattività in Azure. Comprendere che possono verificarsi problemi ed è necessario sviluppare il flusso di lavoro in modo che sia resiliente alle riesezioni. Se i nodi hanno esito negativo, Batch tenta automaticamente di ripristinare questi nodi di calcolo per conto dell'utente. Questo ripristino può attivare la riprogrammazione di qualsiasi attività in esecuzione nel nodo ripristinato o in un nodo disponibile diverso. Per altre informazioni sulle attività interrotte, vedere Progettazione di nuovi tentativi.

Pool di immagini personalizzati

Quando si crea un pool in Azure Batch usando la configurazione della macchina virtuale, specificare l'immagine di macchina virtuale (VM) che fornisce la configurazione del sistema operativo per ogni nodo di calcolo nel pool. È possibile creare il pool con un'immagine di Azure Marketplace supportata oppure creare un'immagine personalizzata con un'immagine della raccolta di calcolo di Azure. Anche se è possibile usare un'immagine gestita per creare un pool di immagini personalizzato, è consigliabile creare immagini personalizzate usando la raccolta di calcolo di Azure, quando possibile. L'uso di Azure Compute Gallery consente di effettuare il provisioning di pool più velocemente, ridimensionare quantità maggiori di macchine virtuali e migliorare l'affidabilità durante il provisioning delle macchine virtuali.

Immagini di terze parti

I pool possono essere creati usando immagini di terze parti pubblicate in Azure Marketplace. Con gli account Batch in modalità sottoscrizione utente, è possibile che venga visualizzato l'errore "Allocazione non riuscita a causa del controllo di idoneità per l'acquisto del Marketplace" durante la creazione di un pool con determinate immagini di terze parti. Per risolvere l'errore, accettare le condizioni impostate dall'autore dell'immagine. A tale scopo, è possibile usare Azure PowerShell o l'interfaccia della riga di comando di Azure.

Dipendenza dall'area di Azure

Non è consigliabile basarsi su una singola area di Azure se si dispone di un carico di lavoro di produzione o sensibile al tempo. Anche se rari, esistono problemi che possono influire su un'intera area. Se ad esempio l'elaborazione deve essere avviata a un'ora specifica, è consigliabile aumentare il pool nell'area primaria con molto anticipo rispetto all'ora di inizio. Se l'aumento del pool non riesce in quell'area, è possibile eseguirne il fallback in una o più aree di backup.

I pool distribuiti tra più account in aree diverse forniscono un backup pronto e facilmente accessibile se si verificano problemi in un altro pool. Per altre informazioni, vedere Progettare l'applicazione per la disponibilità elevata.

Processi

Un processo è un contenitore progettato per includere centinaia, migliaia o anche milioni di attività. Seguire queste linee guida durante la creazione di processi.

Meno processi, più attività

L'uso di un processo per eseguire una singola attività è inefficiente. Ad esempio, è più efficiente usare un singolo processo contenente 1.000 attività anziché creare 100 processi contenenti 100 attività ognuna. Se sono stati usati 1.000 processi, ognuno con una singola attività che sarebbe l'approccio meno efficiente, più lento e più costoso da adottare.

Evitare di progettare una soluzione Batch che richiede migliaia di processi attivi contemporaneamente. Non esiste alcuna quota per le attività, quindi l'esecuzione di molte attività con il minor numero possibile di processi usa in modo efficiente le quote di pianificazione del processo e del processo.

Durata dei processi

Un processo di Batch ha una durata indefinita fino a quando non viene eliminato dal sistema. Il relativo stato indica se può accettare o meno la pianificazione di altre attività.

Un processo non passa automaticamente allo stato completato a meno che non venga terminato in modo esplicito. Questa azione può essere attivata automaticamente tramite la proprietà onAllTasksComplete o maxWallClockTime.

Esiste una quota predefinita di processo e pianificazione dei processi attiva. I processi e le pianificazioni dei processi nello stato completato non vengono conteggiati per questa quota.

Eliminare i processi quando non sono più necessari, anche se in stato completato. Anche se i processi completati non vengono conteggiati per la quota di processi attivi, è utile pulire periodicamente i processi completati. Ad esempio, l'elenco dei processi sarà più efficiente quando il numero totale di processi è un set più piccolo (anche se vengono applicati filtri appropriati alla richiesta).

Attività

Le attività sono singole unità di lavoro che costituiscono un processo. Le attività vengono inviate dall'utente e pianificate da Batch nei nodi di calcolo. Le sezioni seguenti forniscono suggerimenti per progettare le attività per gestire i problemi ed eseguire in modo efficiente.

Salvare i dati delle attività

I nodi di calcolo sono per loro natura temporanei. Le funzionalità batch, ad esempio il pool automatico e la scalabilità automatica, possono semplificare la scomparsa dei nodi. Quando i nodi lasciano un pool (a causa di un ridimensionamento o di un'eliminazione del pool), vengono eliminati anche tutti i file in tali nodi. A causa di questo comportamento, un'attività deve spostare l'output all'esterno del nodo in cui è in esecuzione e in un archivio durevole prima del completamento. Analogamente, se un'attività non riesce, è necessario spostare i log necessari per diagnosticare l'errore in un archivio permanente.

Batch ha integrato il supporto Archiviazione di Azure per caricare i dati tramite OutputFiles e con vari file system condivisi oppure è possibile eseguire il caricamento manualmente nelle attività.

Gestire la durata delle attività

Eliminare le attività quando non sono più necessarie o impostare un vincolo di attività retentionTime . Se retentionTime è impostato, Batch pulisce automaticamente lo spazio su disco usato dall'attività alla scadenza di retentionTime.

L'eliminazione di attività esegue due operazioni:

  • Assicura che non sia presente una compilazione di attività nel processo. Questa azione consente di evitare difficoltà a trovare l'attività a cui si è interessati perché sarà necessario filtrare le attività completate.
  • Pulisce i dati dell'attività corrispondenti nel nodo (purché retentionTime non sia già stato raggiunto). Questa azione consente di assicurarsi che i nodi non riempiono i dati delle attività ed eseguano spazio su disco.

Nota

Per le attività appena inviate a Batch, la chiamata API DeleteTask richiede fino a 10 minuti per rendere effettive le attività. Prima dell'applicazione, è possibile impedire la pianificazione di altre attività. Perché l'utilità di pianificazione batch tenta ancora di pianificare le attività appena eliminate. Se si vuole eliminare un'attività poco dopo l'invio, terminare l'attività invece (poiché la richiesta di attività di chiusura avrà effetto immediatamente). E quindi eliminare l'attività 10 minuti dopo.

Inviare un numero elevato di attività nella raccolta

Le attività possono essere inviate singolarmente o in raccolte. Inviare le attività in raccolte che ne contengono fino a 100 alla volta durante l'invio in blocco per ridurre il sovraccarico e i tempi della procedura.

Impostare il numero massimo di attività per nodo nel modo appropriato

Batch supporta la sovrasottoscrizione di attività nei nodi, ossia l'esecuzione di un numero di attività maggiore del numero di core di un nodo. È necessario assicurarsi che le attività siano ridimensionate correttamente per i nodi nel pool. È ad esempio possibile che si verifichi una riduzione delle prestazioni se si provano a pianificare otto attività, ognuna delle quali utilizza il 25% della CPU in un nodo (in un pool con taskSlotsPerNode = 8).

Progettare per la ripetizione di tentativi e di esecuzioni

Batch può provare automaticamente a ripetere le attività. Esistono due tipi di tentativi: controllati dall'utente e interni. I tentativi controllati dall'utente sono specificati dal valore di maxTaskRetryCount dell'attività. Quando un programma specificato nell'attività viene chiuso con un codice di uscita diverso da zero, l'attività viene ritentata fino al valore di maxTaskRetryCount.

In rari casi, un'attività può essere riprovata internamente a causa di errori del nodo di calcolo, ad esempio se non è possibile aggiornare lo stato interno o si verifica un problema nel nodo durante l'esecuzione dell'attività. L'attività verrà riprovata nello stesso nodo di calcolo, se possibile, fino a un limite interno prima che venga abbandonata e rinviata per la ripianificazione di Batch, possibilmente in un nodo di calcolo diverso.

Non esistono differenze di progettazione durante l'esecuzione delle attività in nodi dedicati o spot. Indica se un'attività viene annullata durante l'esecuzione in un nodo Spot o interrotta a causa di un errore in un nodo dedicato, entrambe le situazioni vengono attenuate progettando l'attività per resistere agli errori.

Creare attività permanenti

Le attività dovrebbero essere progettate per tollerare gli errori e supportare la ripetizione di tentativi. Questo principio è particolarmente importante per le attività a esecuzione prolungata. Assicurarsi che le attività generino lo stesso risultato singolo anche se vengono eseguite più volte. Un modo per ottenere questo risultato consiste nel rendere le attività di "ricerca obiettivo". Un altro modo consiste nel assicurarsi che le attività siano idempotenti (le attività avranno lo stesso risultato indipendentemente dal numero di esecuzioni).

Un esempio comune è un'attività per la copia di file in un nodo di calcolo. Sarebbe possibile ad esempio creare un'attività che copia tutti i file specificati ogni volta che viene eseguita, ma questo approccio, pur essendo semplice, non è efficiente e non prevede la tolleranza degli errori. Creare invece un'attività che assicuri che i file si trovino nel nodo di calcolo, ossia un'attività che non ricopi i file già presenti. In questo modo, l'attività riprenderà dal punto in cui è stata interrotta.

Evitare tempi di esecuzione brevi

Le attività eseguite solo per uno o due secondi non sono ideali. Provare a eseguire una quantità significativa di lavoro in un'attività singola (almeno 10 secondi, fino a ore o giorni). Se ogni attività è in esecuzione per almeno un minuto, il sovraccarico della pianificazione è minimo rispetto al tempo di calcolo complessivo.

Usare l'ambito del pool per attività brevi nei nodi Windows

Quando si pianifica un'attività nei nodi Batch, è possibile scegliere se eseguirla con ambito di attività o pool. Se l'attività verrà eseguita solo per un breve periodo di tempo, l'ambito dell'attività può risultare inefficiente a causa delle risorse necessarie per creare l'account utente automatico per tale attività. Per una maggiore efficienza, è consigliabile impostare queste attività sull'ambito del pool. Per altre informazioni, vedere Eseguire un'attività come utente automatico con ambito pool.

Nodi

Un nodo di calcolo è una macchina virtuale (VM) di Azure o del servizio cloud dedicata all'elaborazione di una parte del carico di lavoro dell'applicazione. Per l'uso dei nodi, seguire queste linee guida.

Avviare le attività: durata e idempotenza

Come per altre attività, l'attività di avvio del nodo deve essere idempotente. Le attività di avvio vengono rieseguite al riavvio del nodo di calcolo o al riavvio dell'agente Batch. Un'attività idempotente è semplicemente quella che produce un risultato coerente quando viene eseguita più volte.

Le attività di avvio non devono essere a esecuzione prolungata o associate alla durata del nodo di calcolo. Se è necessario avviare programmi di natura simile a servizi o servizi, creare un'attività di avvio che consenta l'avvio e la gestione di questi programmi da parte di strutture del sistema operativo, ad systemd esempio in Linux o Servizi Windows. L'attività di avvio deve comunque essere costruita come idempotente in modo che l'esecuzione successiva dell'attività di avvio venga gestita correttamente se questi programmi sono stati installati in precedenza come servizi.

Suggerimento

Quando Batch esegue nuovamente l'attività di avvio, tenterà di eliminare la directory dell'attività di avvio e crearla di nuovo. Se Batch non riesce a ricreare la directory dell'attività di avvio, il nodo di calcolo non avvierà l'attività di avvio.

Questi servizi non devono accettare blocchi di file in nessun file nelle directory gestite da Batch nel nodo, perché in caso contrario Batch non è in grado di eliminare tali directory a causa dei blocchi di file. Ad esempio, invece di configurare l'avvio del servizio direttamente dalla directory di lavoro dell'attività di avvio, copiare i file altrove in modo idempotente. Installare quindi il servizio da tale posizione usando le funzionalità del sistema operativo.

Nodi isolati

Considerare l'uso di dimensioni di VM isolate per i carichi di lavoro con requisiti normativi o di conformità. Le dimensioni isolate supportate nella modalità di configurazione della macchina virtuale includono Standard_E80ids_v4, Standard_M128msStandard_F72s_v2, Standard_G5, Standard_GS5, e Standard_E64i_v3. Per altre informazioni sulle dimensioni delle macchine virtuali isolate, vedere Isolamento macchina virtuale in Azure.

Evitare di creare giunzioni di directory in Windows

Le giunzioni di directory, talvolta denominate collegamenti reali di directory, sono difficili da gestire durante la pulizia di processi e attività. Usare i collegamenti simbolici (collegamenti temporanei) anziché i collegamenti reali.

Dischi temporanei e AZ_BATCH_NODE_ROOT_DIR

Batch si basa su dischi temporanei della macchina virtuale, per le dimensioni delle macchine virtuali compatibili con Batch, per archiviare i metadati correlati all'esecuzione delle attività insieme a tutti gli artefatti di ogni esecuzione di attività in questo disco temporaneo. Esempi di questi punti di montaggio temporanei del disco o directory sono: /mnt/batch, /mnt/resource/batche D:\batch\tasks. La sostituzione, il rimontaggio, la giunzione, il collegamento simbolico o il reindirizzamento di questi punti di montaggio e directory o qualsiasi directory padre non è supportata e può causare instabilità. Se è necessario più spazio su disco, prendere in considerazione l'uso di una dimensione o di una famiglia di macchine virtuali con spazio su disco temporaneo che soddisfi i requisiti o collegare i dischi dati. Per altre informazioni, vedere la sezione successiva sul collegamento e la preparazione dei dischi dati per i nodi di calcolo.

Collegamento e preparazione dei dischi dati

Ogni singolo nodo di calcolo ha la stessa specifica del disco dati collegata se specificata come parte dell'istanza del pool di Batch. Solo i nuovi dischi dati possono essere collegati ai pool di Batch. Questi dischi dati collegati ai nodi di calcolo non vengono partizionati, formattati o montati automaticamente. È responsabilità dell'utente eseguire queste operazioni come parte dell'attività di avvio. Queste attività iniziali devono essere create per essere idempotenti. È possibile eseguire nuovamente le attività di avvio nei nodi di calcolo. Se l'attività di avvio non è idempotente, è possibile che si verifichi una potenziale perdita di dati nei dischi dati.

Suggerimento

Quando si monta un disco dati in Linux, se si annida il punto di montaggio del disco nei punti di montaggio temporanei di Azure, /mnt ad esempio o /mnt/resource, è necessario prestare attenzione a non introdurre gare di dipendenza. Ad esempio, se questi montaggi vengono eseguiti automaticamente dal sistema operativo, può verificarsi una gara tra il disco temporaneo montato e i dischi dati montati sotto l'elemento padre. È necessario eseguire i passaggi per assicurarsi che le dipendenze appropriate vengano applicate dalle funzionalità disponibili, systemd ad esempio o rinviare il montaggio del disco dati all'attività di avvio come parte dello script di preparazione del disco dati idempotente.

Preparazione dei dischi dati nei pool di Batch Linux

I dischi dati di Azure in Linux vengono presentati come dispositivi in blocchi e assegnati un identificatore tipico sd[X] . Non è consigliabile basarsi sulle assegnazioni statiche sd[X] perché queste etichette vengono assegnate dinamicamente al momento dell'avvio e non è garantito che siano coerenti tra il primo e gli eventuali avvio successivi. È necessario identificare i dischi collegati tramite i mapping presentati in /dev/disk/azure/scsi1/. Ad esempio, se è stato specificato LUN 0 per il disco dati nell'API AddPool, il disco verrà manifesto come /dev/disk/azure/scsi1/lun0. Ad esempio, se si desidera elencare questa directory, è possibile visualizzare:

user@host:~$ ls -l /dev/disk/azure/scsi1/
total 0
lrwxrwxrwx 1 root root 12 Oct 31 15:16 lun0 -> ../../../sdc

Non è necessario convertire nuovamente il riferimento nel sd[X] mapping nello script di preparazione, ma fare riferimento direttamente al dispositivo. In questo esempio, questo dispositivo sarà /dev/disk/azure/scsi1/lun0. È possibile specificare questo ID direttamente a fdisk, mkfse qualsiasi altro strumento necessario per il flusso di lavoro. In alternativa, è possibile usare lsblk con blkid per eseguire il mapping dell'UUID per il disco.

Per altre informazioni sui dischi dati di Azure in Linux, inclusi metodi alternativi per individuare dischi dati e /etc/fstab opzioni, vedere questo articolo. Assicurarsi che non ci siano dipendenze o races come descritto nella nota Suggerimento prima di promuovere il metodo in uso in produzione.

Preparazione dei dischi dati nei pool di Windows Batch

I dischi dati di Azure collegati ai nodi di calcolo Di Batch Windows vengono presentati non partizionati e non formattati. È necessario enumerare i dischi con RAW le partizioni per l'azione come parte dell'attività di avvio. Queste informazioni possono essere recuperate usando il Get-Disk cmdlet di PowerShell. Ad esempio, è possibile vedere:

PS C:\Windows\system32> Get-Disk

Number Friendly Name Serial Number                    HealthStatus         OperationalStatus      Total Size Partition
                                                                                                             Style
------ ------------- -------------                    ------------         -----------------      ---------- ----------
0      Virtual HD                                     Healthy              Online                      30 GB MBR
1      Virtual HD                                     Healthy              Online                      32 GB MBR
2      Msft Virtu...                                  Healthy              Online                      64 GB RAW

Dove numero di disco 2 è il disco dati non inizializzato collegato a questo nodo di calcolo. Questi dischi possono quindi essere inizializzati, partizionati e formattati in base alle esigenze del flusso di lavoro.

Per altre informazioni sui dischi dati di Azure in Windows, inclusi gli script di PowerShell di esempio, vedere questo articolo. Verificare che tutti gli script di esempio vengano convalidati per idempotenza prima dell'innalzamento di livello nell'uso in produzione.

Raccogliere i log dell'agente Batch

Se si nota un problema che interessa il comportamento di un nodo o di attività in esecuzione al suo interno, raccogliere i log dell'agente di Batch prima di deallocare i nodi in questione. I log dell'agente di Batch possono essere raccolti usando l'API Carica log del servizio Batch. Questi log possono essere forniti come parte di un ticket di supporto a Microsoft e facilitano l'individuazione e la risoluzione dei problemi.

Gestire gli aggiornamenti del sistema operativo

Per gli account Batch in modalità sottoscrizione utente, gli aggiornamenti automatici del sistema operativo possono interrompere lo stato dell'attività, soprattutto se le attività sono a esecuzione prolungata. La compilazione di attività idempotenti può contribuire a ridurre gli errori causati da queste interruzioni. È anche consigliabile pianificare gli aggiornamenti delle immagini del sistema operativo per i tempi in cui le attività non sono previste per l'esecuzione.

Per i pool di Windows, enableAutomaticUpdates è impostato su per true impostazione predefinita. È consigliabile consentire gli aggiornamenti automatici, ma è possibile impostare questo valore su false se è necessario assicurarsi che un aggiornamento del sistema operativo non si verifichi in modo imprevisto.

Batch API

Errori di timeout

Gli errori di timeout non indicano necessariamente che il servizio non è riuscito a elaborare la richiesta. Quando si verifica un errore di timeout, è necessario ripetere l'operazione o recuperare lo stato della risorsa, in base alle esigenze della situazione, per verificare lo stato dell'esito positivo o negativo dell'operazione.

Connettività

Esaminare le indicazioni seguenti relative alla connettività nelle soluzioni Batch.

Gruppi di sicurezza di rete (NSG) e route definite dall'utente

Quando si esegue il provisioning dei pool di Batch in una rete virtuale, assicurarsi di seguire attentamente le linee guida relative all'uso di BatchNodeManagement.tag del servizio di area , porte, protocolli e direzione della regola. L'uso del tag di servizio è altamente consigliato; non usare gli indirizzi IP del servizio Batch sottostanti perché possono cambiare nel tempo. L'uso diretto degli indirizzi IP del servizio Batch può generare instabilità, interruzioni o disservizi per i pool di Batch.

Per le route definite dall'utente , è consigliabile usare BatchNodeManagement.tag del servizio di areaanziché indirizzi IP del servizio Batch in quanto possono cambiare nel tempo.

Rispettare il DNS

Assicurarsi che i sistemi rispettano il TTL (DNS Time-to-Live) per l'URL del servizio account Batch. Assicurarsi inoltre che i client del servizio Batch e altri meccanismi di connettività al servizio Batch non si basano sugli indirizzi IP.

Qualsiasi richiesta HTTP con codici di stato a livello 5xx insieme a un'intestazione "Connessione ion: close" nella risposta richiede la modifica del comportamento del client del servizio Batch. Il client del servizio Batch deve osservare la raccomandazione chiudendo la connessione esistente, risolvendo nuovamente il DNS per l'URL del servizio account Batch e tentando di seguire le richieste in una nuova connessione.

Ripetere automaticamente le richieste

Assicurarsi che per i client del servizio Batch siano implementati criteri appropriati di ripetizione dei tentativi per riprovare automaticamente le richieste, anche durante il normale funzionamento e non esclusivamente durante i periodi di manutenzione del servizio. Questi criteri di ripetizione dei tentativi devono estendersi in un intervallo di almeno 5 minuti. Le funzionalità di ripetizione automatica dei tentativi sono fornite da vari SDK di Batch, ad esempio la classe .NET RetryPolicyProvider.

Indirizzi IP pubblici statici

In genere, le macchine virtuali in un pool di Batch sono accessibili tramite indirizzi IP pubblici che possono cambiare nel corso della durata del pool. Questa natura dinamica può rendere difficile interagire con un database o un altro servizio esterno che limita l'accesso a determinati indirizzi IP. Per risolvere questo problema, è possibile creare un pool usando un set di indirizzi IP pubblici statici che si controllano. Per altre informazioni, vedere Creare un pool di Azure Batch con indirizzi IP pubblici specificati.

Test della connettività con la configurazione di Servizi cloud

Non è possibile usare il normale protocollo "ping"/ICMP con i servizi cloud, perché il protocollo ICMP non è consentito tramite il servizio di bilanciamento del carico di Azure. Per altre informazioni, vedere Connessione ivity and networking for Azure Servizi cloud(Servizi cloud).

Dipendenze sottostanti dei nodi di Batch

Quando si progettano le soluzioni Batch, tenere presenti le dipendenze e le restrizioni seguenti.

Risorse create dal sistema

Azure Batch crea e gestisce un set di utenti e gruppi nella macchina virtuale, che non deve essere modificato:

Windows:

  • Un utente denominato PoolNonAdmin
  • Un gruppo di utenti denominato WATaskCommon

Linux:

  • Un utente denominato _azbatch

Suggerimento

La denominazione di questi utenti o gruppi sono artefatti di implementazione e sono soggetti a modifiche in qualsiasi momento.

Pulizia dei file

Batch prova attivamente a pulire la directory di lavoro in cui vengono eseguite le attività, al termine del periodo di conservazione. La pulizia di tutti i file scritti al di fuori di questa directory è responsabilità dell'utente, per evitare di riempire spazio su disco.

La pulizia automatica per la directory di lavoro verrà bloccata se si esegue un servizio in Windows dalla directory di lavoro dell'attività di avvio, a causa della cartella ancora in uso. Questa azione porterà a prestazioni ridotte. Per risolvere questo problema, modificare la directory del servizio in una directory separata non gestita da Batch.

Passaggi successivi