Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Un'attività in esecuzione in Azure Batch può produrre dati di output durante l'esecuzione. I dati di output delle attività devono spesso essere archiviati per il recupero da altre attività nel processo, dall'applicazione client che ha eseguito il processo o da entrambi. Le attività scrivono i dati di output nel file system di un nodo di calcolo di Batch, ma tutti i dati presenti nel nodo vanno persi quando ne viene ricreata l'immagine o quando il nodo lascia il pool. Le attività possono anche avere un periodo di conservazione dei file, dopo il quale i file creati dall'attività vengono eliminati. Per questi motivi, è importante rendere persistente l'output delle attività che sarà necessario in un secondo momento in un archivio dati, ad esempio Archiviazione di Azure.
Per le opzioni dell'account di archiviazione in Batch, vedere Account Batch e account di archiviazione di Azure.
L'API del servizio Batch supporta la persistenza dei dati di output in Archiviazione di Azure per le attività e le attività di gestione dei processi eseguite nei pool con Configurazione macchina virtuale. Quando si aggiunge un'attività, è possibile specificare un contenitore in Archiviazione di Azure come destinazione per l'output dell'attività. Il servizio Batch scrive quindi tutti i dati di output in tale contenitore al termine dell'attività.
Quando si usa l'API del servizio Batch per rendere persistente l'output dell'attività, non è necessario modificare l'applicazione in esecuzione dell'attività. Invece, con alcune modifiche alla tua applicazione client, puoi salvare l'output dell'attività dallo stesso blocco di codice che crea l'attività.
Importante
Il salvataggio permanente dei dati delle attività in Archiviazione di Azure con l'API del servizio Batch non funziona con i pool creati prima del 1° febbraio 2018.
Quando si usa l'API del servizio Batch per rendere persistente l'output dell'attività?
Azure Batch offre più modi per rendere persistente l'output delle attività. L'uso dell'API del servizio Batch è un approccio pratico più adatto a questi scenari:
- Si vuole scrivere codice per rendere persistente l'output del task dall'interno dell'applicazione client, senza modificare l'applicazione su cui è in esecuzione il task.
- Si vuole rendere persistente l'output dalle attività batch e dalle attività di gestione processi nei pool creati con la configurazione della macchina virtuale.
- Si vuole rendere persistente l'output in un contenitore di Archiviazione di Azure con un nome arbitrario.
- Si vuole rendere persistente l'output in un contenitore di Archiviazione di Azure denominato in base allo standard Batch File Conventions.
Se lo scenario è diverso da quelli elencati in precedenza, potrebbe essere necessario prendere in considerazione un approccio diverso. Ad esempio, l'API del servizio Batch non supporta attualmente lo streaming dell'output verso Azure Storage mentre l'attività è in esecuzione. Per trasmettere l'output, è consigliabile usare la libreria Batch File Conventions, disponibile per .NET. Per altri linguaggi, è necessario implementare la propria soluzione. Per altre informazioni su opzioni alternative, vedere Rendere persistente l'output dei processi e delle attività nell'archiviazione di Azure.
Creare un contenitore in Archiviazione di Azure
Per rendere persistente l'output delle attività in Archiviazione di Azure, è necessario creare un contenitore che funge da destinazione per i file di output. Creare il contenitore prima di eseguire l'attività, preferibilmente prima di inviare il job, utilizzando la libreria client di Azure Storage o l'SDK appropriato. Per altre informazioni sulle API di Archiviazione di Azure, vedere la documentazione di Archiviazione di Azure.
Ad esempio, se si scrive l'applicazione in C#, usare la libreria client di Archiviazione di Azure per .NET. L'esempio seguente mostra come creare un contenitore:
CloudBlobContainer container = storageAccount.CreateCloudBlobClient().GetContainerReference(containerName);
await container.CreateIfNotExists();
Specificare i file di output per i risultati delle attività
Per specificare i file di output per un'attività, creare una raccolta di oggetti OutputFile e assegnarli alla proprietà CloudTask.OutputFiles quando si crea l'attività. È possibile usare una firma di accesso condiviso o un'identità gestita per autenticare l'accesso al contenitore.
Uso di una firma di accesso condiviso
Dopo aver creato il contenitore, ottenere una firma di accesso condiviso con accesso in scrittura al contenitore. Un SAS fornisce accesso delegato al contenitore. L'SAS concede l'accesso con un set specificato di autorizzazioni e in un intervallo di tempo specificato. Il servizio Batch deve disporre di una firma di accesso condiviso con autorizzazioni di scrittura per scrivere l'output delle attività nel contenitore. Per ulteriori informazioni sulle firme di accesso condiviso (SAS), vedere l'uso delle firme di accesso condiviso nell'archiviazione di Azure.
Quando si ottiene una firma di accesso condiviso tramite le API di Archiviazione di Azure, l'API restituisce una stringa di token di firma di accesso condiviso. Questa stringa di token include tutti i parametri della firma di accesso condiviso, incluse le autorizzazioni e l'intervallo in cui la firma di accesso condiviso è valida. Per usare la firma di accesso condiviso per accedere a un contenitore in Archiviazione di Azure, è necessario aggiungere la stringa del token di firma di accesso condiviso all'URI della risorsa. L'URI della risorsa, insieme al token di firma di accesso condiviso aggiunto, fornisce l'accesso autenticato a Azure Storage.
L'esempio seguente illustra come ottenere una stringa di token SAS in sola scrittura per il contenitore, quindi aggiunge il token SAS all'URI del contenitore.
string containerSasToken = container.GetSharedAccessSignature(new SharedAccessBlobPolicy()
{
SharedAccessExpiryTime = DateTimeOffset.UtcNow.AddDays(1),
Permissions = SharedAccessBlobPermissions.Write
});
string containerSasUrl = container.Uri.AbsoluteUri + containerSasToken;
Nell'esempio di codice C# seguente viene creata un'attività che scrive numeri casuali in un file denominato output.txt. Nell'esempio viene creato un file di output per output.txt da scrivere nel contenitore. L'esempio crea anche file di output per tutti i file di log che corrispondono al modello std*.txt di file , ad esempiostdout.txt e stderr.txt. L'URL del contenitore richiede il SAS creato in precedenza per il contenitore. Il servizio di Batch usa la firma di accesso condiviso (SAS) per autenticare l'accesso al contenitore.
new CloudTask(taskId, "cmd /v:ON /c \"echo off && set && (FOR /L %i IN (1,1,100000) DO (ECHO !RANDOM!)) > output.txt\"")
{
OutputFiles = new List<OutputFile>
{
new OutputFile(
filePattern: @"..\std*.txt",
destination: new OutputFileDestination(
new OutputFileBlobContainerDestination(
containerUrl: containerSasUrl,
path: taskId)),
uploadOptions: new OutputFileUploadOptions(
uploadCondition: OutputFileUploadCondition.TaskCompletion)),
new OutputFile(
filePattern: @"output.txt",
destination:
new OutputFileDestination(new OutputFileBlobContainerDestination(
containerUrl: containerSasUrl,
path: taskId + @"\output.txt")),
uploadOptions: new OutputFileUploadOptions(
uploadCondition: OutputFileUploadCondition.TaskCompletion)),
}
Annotazioni
Se si usa questo esempio con Linux, assicurarsi di modificare le barre rovesciate in barre.
Uso dell'identità gestita
Anziché generare e passare una SAS con accesso in scrittura al contenitore a Batch, è possibile utilizzare un'identità gestita per autenticarsi con Azure Storage. L'identità deve essere assegnata al pool Batch e deve anche disporre dell'assegnazione di ruolo Storage Blob Data Contributor per il contenitore in cui scrivere. È quindi possibile indicare al servizio Batch di utilizzare l'identità gestita anziché un SAS per l'autenticazione dell'accesso al contenitore.
CloudBlobContainer container = storageAccount.CreateCloudBlobClient().GetContainerReference(containerName);
await container.CreateIfNotExists();
new CloudTask(taskId, "cmd /v:ON /c \"echo off && set && (FOR /L %i IN (1,1,100000) DO (ECHO !RANDOM!)) > output.txt\"")
{
OutputFiles = new List<OutputFile>
{
new OutputFile(
filePattern: @"..\std*.txt",
destination: new OutputFileDestination(
new OutputFileBlobContainerDestination(
containerUrl: container.Uri,
path: taskId,
identityReference: new ComputeNodeIdentityReference() { ResourceId = "/subscriptions/SUB/resourceGroups/RG/providers/Microsoft.ManagedIdentity/userAssignedIdentities/identity-name"} })),
uploadOptions: new OutputFileUploadOptions(
uploadCondition: OutputFileUploadCondition.TaskCompletion))
}
}
Specificare un modello di file per la corrispondenza
Quando si specifica un file di output, è possibile utilizzare la proprietà OutputFile.FilePattern per specificare un modello di file per la corrispondenza. Il modello di file può corrispondere a zero file, a un singolo file o a un set di file creati dall'attività.
La proprietà FilePattern supporta i caratteri jolly standard del file system, ad esempio * (per corrispondenze non ricorsive) e ** (per corrispondenze ricorsive). Ad esempio, l'esempio di codice precedente specifica il modello di file in modo che corrisponda std*.txt in modo non ricorsivo:
filePattern: @"..\std*.txt"
Per caricare un singolo file, specificare un modello di file senza caratteri jolly. Ad esempio, l'esempio di codice precedente specifica il modello di file che corrisponde output.txta :
filePattern: @"output.txt"
Specificare una condizione di caricamento
La proprietà OutputFileUploadOptions.UploadCondition consente il caricamento condizionale dei file di output. Uno scenario comune consiste nel caricare un set di file se l'attività ha esito positivo e un set diverso di file in caso di errore. Ad esempio, è possibile caricare file di log dettagliato solo quando l'attività ha esito negativo ed esce con un codice di uscita diverso da zero. Analogamente, è possibile caricare i file dei risultati solo se l'attività ha esito positivo, perché questi file potrebbero essere mancanti o incompleti se l'attività non riesce.
L'esempio di codice precedente imposta la proprietà UploadCondition su TaskCompletion. Questa impostazione specifica che il file deve essere caricato al termine delle attività, indipendentemente dal valore del codice di uscita.
uploadCondition: OutputFileUploadCondition.TaskCompletion
Per altre impostazioni, vedere l'enumerazione OutputFileUploadCondition .
Disambiguare i file con lo stesso nome
Le attività in un processo possono produrre file con lo stesso nome. Ad esempio, stdout.txt e stderr.txt vengono creati per ogni attività eseguita in un processo. Poiché ogni attività viene eseguita nel proprio contesto, questi file non sono in conflitto nel file system del nodo. Tuttavia, quando si caricano file da più attività in un contenitore condiviso, è necessario disambiguare i file con lo stesso nome.
OutputFileBlobContainerDestination.La proprietà Path specifica il BLOB di destinazione o la directory virtuale per i file di output. È possibile usare la proprietà Path per denominare il BLOB o la directory virtuale in modo che i file di output con lo stesso nome siano denominati in modo univoco in Archiviazione di Azure. L'uso dell'ID attività nel percorso è un buon modo per garantire nomi univoci e identificare facilmente i file.
Se la proprietà FilePattern è impostata su un'espressione wildcard, tutti i file che corrispondono al pattern vengono caricati nella directory virtuale specificata dalla proprietà Path. Ad esempio, se il contenitore è mycontainer, l'ID attività è mytaske il modello di file è ..\std*.txt, gli URI assoluti per i file di output in Archiviazione di Azure saranno simili a:
https://myaccount.blob.core.windows.net/mycontainer/mytask/stderr.txt
https://myaccount.blob.core.windows.net/mycontainer/mytask/stdout.txt
Se la proprietà FilePattern è impostata su a un singolo nome di file, ovvero non contiene caratteri jolly, il valore della proprietà Path specifica il nome completo del BLOB. Se si prevedono conflitti di nome per un singolo file da più attività, includere il nome della directory virtuale come parte del nome del file per evitare ambiguità. Ad esempio, impostare la proprietà Path per includere l'ID attività, il carattere delimitatore (in genere una barra) e il nome del file:
path: taskId + @"/output.txt"
Gli URI assoluti per i file di output per un set di attività saranno simili a:
https://myaccount.blob.core.windows.net/mycontainer/task1/output.txt
https://myaccount.blob.core.windows.net/mycontainer/task2/output.txt
Per altre informazioni sulle directory virtuali in Archiviazione di Azure, vedere Elencare i BLOB in un contenitore.
Molti file di output
Quando un'attività specifica numerosi file di output, è possibile che si verifichino limiti imposti dall'API di Azure Batch. È consigliabile mantenere le attività ridotte e mantenere basso il numero di file di output.
Se si verificano limiti, è consigliabile ridurre il numero di file di output usando modelli di file o usando contenitori di file come tar o zip per consolidare i file di output. In alternativa, usare il montaggio o altri approcci per rendere persistenti i dati di output (vedere Rendere persistente l'output dei processi e delle attività).
Diagnosticare gli errori di caricamento dei file
Se il caricamento dei file di output in Archiviazione Azure ha esito negativo, l'attività passa allo stato Completato e la proprietà TaskExecutionInformation.FailureInformation viene impostata. Esaminare la proprietà FailureInformation per determinare l'errore che si è verificato. Ad esempio, di seguito è riportato un errore che si verifica durante il caricamento di file se non è possibile trovare il contenitore:
Category: UserError
Code: FileUploadContainerNotFound
Message: One of the specified Azure container(s) was not found while attempting to upload an output file
In ogni caricamento di file, Batch scrive due file di log nel nodo fileuploadout.txt di calcolo e fileuploaderr.txt. È possibile esaminare questi file di log per ottenere ulteriori informazioni su un errore specifico. Nei casi in cui il caricamento del file non è mai stato tentato, ad esempio perché l'attività stessa non è stata eseguita, questi file di log non esistono.
Diagnosticare le prestazioni di caricamento dei file
Il fileuploadout.txt file registra lo stato di caricamento. È possibile esaminare questo file per altre informazioni sul tempo necessario per i caricamenti dei file. Tenere presente che esistono molti fattori che contribuiscono al caricamento delle prestazioni, tra cui le dimensioni del nodo, altre attività nel nodo al momento del caricamento, se il contenitore di destinazione si trova nella stessa area del pool di Batch, il numero di nodi che vengono caricati contemporaneamente nell'account di archiviazione e così via.
Usare l'API del servizio Batch con lo standard Batch File Conventions
Quando si rende persistente l'output dell'attività con l'API del servizio Batch, è possibile denominare il contenitore di destinazione e i BLOB come si desidera. È anche possibile scegliere di denominarli in base allo standard Batch File Conventions. Lo standard File Conventions determina i nomi del contenitore di destinazione e del BLOB in Archiviazione di Azure per un determinato file di output in base ai nomi del processo e dell'attività. Se si usa lo standard File Conventions per la denominazione dei file di output, i file di output sono disponibili per la visualizzazione nel portale di Azure.
Se si sviluppa in C#, è possibile usare i metodi incorporati nella libreria Batch File Conventions per .NET. Questa libreria crea automaticamente i contenitori correttamente denominati e i percorsi blob. Ad esempio, è possibile chiamare l'API per ottenere il nome corretto per il contenitore, in base al nome del processo:
string containerName = job.OutputStorageContainerName();
È possibile usare il metodo CloudJobExtensions.GetOutputStorageContainerUrl per restituire un URL di firma di accesso condiviso usato per scrivere nel contenitore. È quindi possibile passare questo SAS al costruttore OutputFileBlobContainerDestination.
Se si sviluppa in un linguaggio diverso da C#, sarà necessario implementare manualmente lo standard File Conventions.
Esempio di codice
Il progetto di esempio PersistOutputs è uno degli esempi di codice di Azure Batch in GitHub. Questa soluzione di Visual Studio illustra come usare la libreria client batch per .NET per rendere persistente l'output delle attività nell'archiviazione durevole. Per eseguire l'esempio, seguire questa procedura:
- Aprire il progetto in Visual Studio 2019.
- Aggiungere le credenziali degli account di Batch e Archiviazione a AccountSettings.settings nel progetto Microsoft.Azure.Batch.Samples.Common.
- Compilare (ma non eseguire) la soluzione. Se richiesto, ripristinare eventuali pacchetti NuGet.
- Usare il portale di Azure per caricare un pacchetto dell'applicazione per PersistOutputsTask. Includere
PersistOutputsTask.exee relativi assembly dipendenti nel pacchetto ZIP, impostare l'ID applicazione su "PersistOutputsTask" e la versione del pacchetto dell'applicazione su "1.0". - Avviare (eseguire) il progetto PersistOutputs .
- Quando viene richiesto di scegliere la tecnologia di persistenza da usare per l'esecuzione dell'esempio, immettere 2 per eseguire l'esempio usando l'API del servizio Batch per rendere persistente l'output dell'attività.
- Se lo si desidera, eseguire di nuovo l'esempio, immettendo 3 per rendere persistente l'output con l'API del servizio Batch e anche per assegnare un nome al contenitore di destinazione e al percorso BLOB in base allo standard File Conventions.
Passaggi successivi
- Per ulteriori informazioni sulla persistenza dell'output delle attività utilizzando la libreria File Conventions per .NET, vedere Persistenza dei dati dei processi e delle attività su Azure Storage con la libreria Batch File Conventions per .NET.
- Per informazioni su altri approcci per mantenere i dati di output in Azure Batch, vedere Persistenza dell'output di processi e attività in Azure Storage.