Partilhar via

Melhores práticas do Azure Batch

  • Artigo

Este artigo discute as práticas recomendadas e dicas úteis para usar o serviço de Lote do Azure de forma eficaz. Essas dicas podem ajudá-lo a melhorar o desempenho e evitar armadilhas de design em suas soluções em lote.

Gorjeta

Para obter orientação sobre segurança no Lote do Azure, consulte Práticas recomendadas de conformidade e segurança em lote.

Conjuntos

Pools são os recursos de computação para executar trabalhos no serviço de lote. As seções a seguir fornecem recomendações para trabalhar com pools de lotes.

Configuração e nomenclatura do pool

  • Modo de alocação de pool: ao criar uma conta de lote, você pode escolher entre dois modos de alocação de pool: serviço de lote ou assinatura de usuário. Para a maioria dos casos, você deve usar o modo de serviço em lote padrão, no qual os pools são alocados nos bastidores em assinaturas gerenciadas por lote. No modo de subscrição de utilizador alternativo, as VMs do Batch e outros recursos são criados diretamente na sua subscrição quando é criado um conjunto. As contas de assinatura de usuário são usadas principalmente para habilitar um subconjunto pequeno, mas importante, de cenários. Para obter mais informações, consulte Configuração para o modo de assinatura do usuário.

  • classic ou simplified modo de comunicação de nó: os pools podem ser configurados em um dos dois modos de comunicação de nó, clássico ou simplificado. No modelo de comunicação de nó clássico, o serviço Batch inicia a comunicação com os nós de computação e os nós de computação também exigem comunicação com o Armazenamento do Azure. No modelo de comunicação de nó simplificado, os nós de computação iniciam a comunicação com o serviço em lote. Devido ao escopo reduzido de conexões de entrada/saída necessárias, e não exigindo acesso de saída do Armazenamento do Azure para operação de linha de base, a recomendação é usar o modelo de comunicação de nó simplificado. Algumas melhorias futuras para o serviço Batch também exigirão o modelo simplificado de comunicação de nó. O modelo clássico de comunicação de nó será desativado em 31 de março de 2026.

  • Considerações sobre o tempo de execução do trabalho e da tarefa: se você tiver trabalhos compostos principalmente de tarefas de curta duração e as contagens totais de tarefas esperadas forem pequenas, de modo que o tempo de execução esperado geral do trabalho não seja longo, não aloque um novo pool para cada trabalho. O tempo de alocação dos nós diminuirá o tempo de execução do trabalho.

  • Vários nós de computação: não é garantido que nós individuais estejam sempre disponíveis. Embora incomuns, falhas de hardware, atualizações do sistema operacional e uma série de outros problemas podem fazer com que nós individuais fiquem offline. Se a carga de trabalho do Batch exigir um progresso determinístico e garantido, você deverá alocar pools com vários nós.

  • Imagens com datas de fim de vida (EOL) iminentes: é altamente recomendável evitar imagens com datas de fim de vida útil (EOL) de suporte em lote iminentes. Essas datas podem ser descobertas por meio da API, PowerShellListSupportedImages ou CLI do Azure. É sua responsabilidade atualizar periodicamente sua exibição das datas EOL pertinentes aos seus pools e migrar suas cargas de trabalho antes que a data EOL ocorra. Se você estiver usando uma imagem personalizada com um agente de nó especificado, certifique-se de seguir as datas de fim de vida útil do suporte em lote para a imagem para a qual sua imagem personalizada é derivada ou alinhada. Uma imagem sem uma data especificada batchSupportEndOfLife indica que essa data ainda não foi determinada pelo serviço Batch. A ausência de uma data não indica que a respetiva imagem será suportada indefinidamente. Uma data EOL pode ser adicionada ou atualizada no futuro a qualquer momento.

  • SKUs de VM com datas de fim de vida (EOL) iminentes: Assim como acontece com as imagens de VM, as SKUs ou famílias de VM também podem atingir o fim da vida útil do suporte em lote (EOL). Essas datas podem ser descobertas por meio da API, PowerShellListSupportedVirtualMachineSkus ou CLI do Azure. Planeje a migração de sua carga de trabalho para uma SKU VM NÃO EOL criando um novo pool com uma SKU de VM suportada apropriada. A ausência de uma data associada batchSupportEndOfLife para uma SKU de VM não indica que determinada SKU de VM será suportada indefinidamente. Uma data EOL pode ser adicionada ou atualizada no futuro a qualquer momento.

  • Nomes de recursos exclusivos: os recursos em lote (trabalhos, pools, etc.) geralmente vêm e vão ao longo do tempo. Por exemplo, você pode criar um pool na segunda-feira, excluí-lo na terça-feira e, em seguida, criar outro pool semelhante na quinta-feira. Cada novo recurso criado deve receber um nome exclusivo que você não tenha usado antes. Você pode criar exclusividade usando um GUID (como o nome do recurso inteiro ou como parte dele) ou incorporando a data e a hora em que o recurso foi criado no nome do recurso. O Batch suporta DisplayName, que pode dar a um recurso um nome mais legível, mesmo que o ID real do recurso seja algo que não seja amigável para humanos. O uso de nomes exclusivos facilita a diferenciação de qual recurso específico fez algo em logs e métricas. Ele também remove a ambiguidade se você tiver que arquivar um caso de suporte para um recurso.

  • Continuidade durante a manutenção e falha da piscina: é melhor fazer com que seus trabalhos usem as piscinas dinamicamente. Se seus trabalhos usam o mesmo pool para tudo, há uma chance de que os trabalhos não sejam executados se algo der errado com o pool. Este princípio é especialmente importante para cargas de trabalho sensíveis ao tempo. Por exemplo, selecione ou crie um pool dinamicamente ao agendar cada trabalho ou tenha uma maneira de substituir o nome do pool para que você possa ignorar um pool não íntegro.

  • Continuidade de negócios durante a manutenção e falha do pool: há muitos motivos pelos quais um pool pode não crescer para o tamanho desejado, como erros internos ou restrições de capacidade. Certifique-se de que você pode redirecionar trabalhos em um pool diferente (possivelmente com um tamanho de VM diferente usando UpdateJob), se necessário. Evite confiar em um ID de pool estático com a expectativa de que ele nunca será excluído e nunca será alterado.

Segurança da piscina

Limite de isolamento

Para fins de isolamento, se o seu cenário exigir o isolamento de trabalhos ou tarefas uns dos outros, faça-o colocando-os em pools separados. Um pool é o limite de isolamento de segurança no Batch e, por padrão, dois pools não são visíveis ou capazes de se comunicar entre si. Evite usar contas de lote separadas como um meio de isolamento de segurança, a menos que o ambiente maior a partir do qual a conta de lote opera exija isolamento.

Atualizações do Batch Node Agent

Os agentes de nó em lote não são atualizados automaticamente para pools com nós de computação diferentes de zero. Para garantir que seus pools de lotes recebam as correções de segurança e atualizações mais recentes para o agente do nó de lote, você precisa redimensionar o pool para zero nós de computação ou recriar o pool. É recomendável monitorar as notas de versão do Batch Node Agent para entender as alterações nas novas versões do Batch Node Agent. Verificar regularmente se há atualizações quando elas foram lançadas permite que você planeje atualizações para a versão mais recente do agente.

Antes de recriar ou redimensionar seu pool, você deve baixar todos os logs do agente de nó para fins de depuração se estiver enfrentando problemas com seu pool de lotes ou nós de computação. Esse processo é discutido mais detalhadamente na seção Nodes .

Nota

Para obter orientações gerais sobre segurança no Azure Batch, consulte Práticas recomendadas de conformidade e segurança em lote.

Atualizações ao sistema operativo

É recomendável que a imagem da VM selecionada para um pool de lotes esteja atualizada com as atualizações de segurança fornecidas pelo editor mais recente. Algumas imagens podem executar atualizações automáticas de pacotes na inicialização (ou logo depois), o que pode interferir com certas ações direcionadas ao usuário, como recuperar atualizações do repositório de pacotes (por exemplo, apt update) ou instalar pacotes durante ações como um StartTask.

É recomendável habilitar a atualização automática do sistema operacional para pools de lotes, o que permite que a infraestrutura subjacente do Azure coordene atualizações em todo o pool. Esta opção pode ser configurada para não causar interrupções na execução da tarefa. A atualização automática do SO não suporta todos os sistemas operativos suportados pelo Batch. Para obter mais informações, consulte a Matriz de suporte de atualização automática do SO de conjuntos de escala de máquina virtual. Para sistemas operacionais Windows, verifique se você não está habilitando a propriedade virtualMachineConfiguration.windowsConfiguration.enableAutomaticUpdates ao usar a atualização automática do sistema operacional no pool de lotes.

O Azure Batch não verifica nem garante que as imagens permitidas para uso com o serviço tenham as atualizações de segurança mais recentes. As atualizações de imagens estão sob a alçada do editor da imagem, e não do Azure Batch. Para determinadas imagens publicadas em microsoft-azure-batch, não há garantia de que essas imagens sejam mantidas atualizadas com a imagem derivada a montante.

Tempo de vida e faturamento do pool

O tempo de vida do pool pode variar dependendo do método de alocação e das opções aplicadas à configuração do pool. Os pools podem ter um tempo de vida arbitrário e um número variável de nós de computação a qualquer momento. É sua responsabilidade gerenciar os nós de computação no pool explicitamente ou por meio de recursos fornecidos pelo serviço (autoscale ou autopool).

  • Recreação de piscinas: evite excluir e recriar piscinas diariamente. Em vez disso, crie um novo pool e, em seguida, atualize seus trabalhos existentes para apontar para o novo pool. Depois que todas as tarefas tiverem sido movidas para o novo pool, exclua o pool antigo.

  • Eficiência e faturamento do pool: O lote em si não incorre em encargos extras. No entanto, você incorre em cobranças pelos recursos do Azure utilizados, como computação, armazenamento, rede e quaisquer outros recursos que possam ser necessários para sua carga de trabalho em lote. Você é cobrado por cada nó de computação no pool, independentemente do estado em que ele se encontra. Para obter mais informações, consulte Análise de custos e orçamentos para o Azure Batch.

  • Discos efêmeros do sistema operacional: os pools de configuração de máquina virtual podem usar discos efêmeros do sistema operacional, que criam o disco do sistema operacional no cache da VM ou SSD temporário, para evitar custos extras associados aos discos gerenciados.

Falhas na alocação do pool

Falhas de alocação de pool podem acontecer a qualquer momento durante a primeira alocação ou redimensionamentos subsequentes. Essas falhas podem ser devido ao esgotamento temporário da capacidade em uma região ou falhas em outros serviços do Azure nos quais o Batch depende. Sua cota principal não é uma garantia, mas sim um limite.

Período de indisponibilidade não planeado

É possível que os pools de lotes experimentem eventos de tempo de inatividade no Azure. Entender que problemas podem surgir e você deve desenvolver seu fluxo de trabalho para ser resiliente a reexecuções. Se os nós falharem, o Batch tentará recuperar automaticamente esses nós de computação em seu nome. Essa recuperação pode acionar o reagendamento de qualquer tarefa em execução no nó que é restaurado ou em um nó diferente disponível. Para saber mais sobre tarefas interrompidas, consulte Projetando para tentativas.

Pools de imagens personalizadas

Ao criar um pool de lotes do Azure usando a Configuração de Máquina Virtual, você especifica uma imagem de VM que fornece o sistema operacional para cada nó de computação no pool. Você pode criar o pool com uma imagem do Azure Marketplace com suporte ou pode criar uma imagem personalizada com uma imagem da Galeria de Computação do Azure. Embora você também possa usar uma imagem gerenciada para criar um pool de imagens personalizado, recomendamos criar imagens personalizadas usando a Galeria de Computação do Azure sempre que possível. Usar a Galeria de Computação do Azure ajuda a provisionar pools mais rapidamente, dimensionar quantidades maiores de VMs e melhora a confiabilidade ao provisionar VMs.

Imagens de terceiros

Os pools podem ser criados usando imagens de terceiros publicadas no Azure Marketplace. Com contas em lote do modo de assinatura de usuário, você pode ver o erro "Falha na alocação devido à verificação de elegibilidade de compra do marketplace" ao criar um pool com determinadas imagens de terceiros. Para resolver esse erro, aceite os termos definidos pelo editor da imagem. Você pode fazer isso usando o Azure PowerShell ou a CLI do Azure.

Piscinas de contentores

Quando você cria um pool de lotes com uma rede virtual, pode haver efeitos colaterais de interação entre a rede virtual especificada e a ponte padrão do Docker. O Docker, por padrão, criará uma ponte de rede com uma especificação de sub-rede de 172.17.0.0/16. Certifique-se de que não há intervalos de IP conflitantes entre a ponte de rede do Docker e sua rede virtual.

O Docker Hub limita o número de imagens extraídas. Certifique-se de que sua carga de trabalho não exceda os limites de taxa publicados para imagens baseadas no Docker Hub. É recomendável usar o Registro de Contêiner do Azure diretamente ou aproveitar o cache de artefatos no ACR.

Dependência da região do Azure

Você não deve confiar em uma única região do Azure se tiver uma carga de trabalho de produção ou sensível ao tempo. Embora raros, existem problemas que podem afetar uma região inteira. Por exemplo, se o processamento precisar começar em um horário específico, considere ampliar o pool na região principal bem antes da hora de início. Se essa escala de pool falhar, você poderá voltar a dimensionar um pool em uma região (ou regiões) de backup.

Pools em várias contas em diferentes regiões fornecem um backup pronto e facilmente acessível se algo der errado com outro pool. Para obter mais informações, consulte Projetar seu aplicativo para alta disponibilidade.

Tarefas

Um trabalho é um contêiner projetado para conter centenas, milhares ou até milhões de tarefas. Siga estas orientações ao criar postos de trabalho.

Menos trabalhos, mais tarefas

Usar um trabalho para executar uma única tarefa é ineficiente. Por exemplo, é mais eficiente usar um único trabalho contendo 1.000 tarefas em vez de criar 100 trabalhos que contêm 10 tarefas cada. Se você usasse 1.000 trabalhos, cada um com uma única tarefa que seria a abordagem menos eficiente, mais lenta e mais cara a ser executada.

Evite projetar uma solução em lote que exija milhares de trabalhos ativos simultaneamente. Não há cota para tarefas, portanto, executar muitas tarefas no menor número possível de tarefas usa eficientemente suas cotas de trabalho e agendamento de tarefas.

Vida útil do trabalho

Um trabalho em lote tem um tempo de vida indefinido até ser excluído do sistema. Seu estado designa se pode aceitar mais tarefas para agendamento ou não.

Um trabalho não é movido automaticamente para o estado concluído, a menos que seja explicitamente encerrado. Essa ação pode ser acionada automaticamente por meio da propriedade onAllTasksComplete ou maxWallClockTime.

Há uma cota padrão de trabalho ativo e agendamento de trabalho. Trabalhos e cronogramas de trabalho no estado concluído não contam para essa cota.

Exclua trabalhos quando eles não forem mais necessários, mesmo que estejam concluídos. Embora os trabalhos concluídos não contem para a cota de trabalho ativa, é benéfico limpar periodicamente os trabalhos concluídos. Por exemplo, listar trabalhos será mais eficiente quando o número total de trabalhos for um conjunto menor (mesmo que filtros adequados sejam aplicados à solicitação).

Tarefas

As tarefas são unidades individuais de trabalho que compõem um trabalho. As tarefas são enviadas pelo usuário e agendadas pelo Batch para nós de computação. As seções a seguir fornecem sugestões para projetar suas tarefas para lidar com problemas e executar com eficiência.

Salvar dados da tarefa

Os nós de computação são, por natureza, efêmeros. Recursos em lote, como autopool e dimensionamento automático, podem facilitar o desaparecimento de nós. Quando os nós saem de um pool (devido a um redimensionamento ou a uma exclusão de pool), todos os arquivos nesses nós também são excluídos. Devido a esse comportamento, uma tarefa deve mover sua saída do nó em que está sendo executada e para um armazenamento durável antes de ser concluída. Da mesma forma, se uma tarefa falhar, ela deverá mover os logs necessários para diagnosticar a falha para um armazenamento durável.

O Batch tem suporte integrado ao Armazenamento do Azure para carregar dados por meio de OutputFiles e com vários sistemas de arquivos compartilhados, ou você mesmo pode executar o carregamento em suas tarefas.

Gerenciar o tempo de vida da tarefa

Exclua tarefas quando elas não forem mais necessárias ou defina uma restrição de tarefa retentionTime . Se um retentionTime estiver definido, o Batch limpará automaticamente o espaço em disco usado pela tarefa quando a retentionTime expirar.

A exclusão de tarefas realiza duas coisas:

  • Garante que você não tenha um acúmulo de tarefas no trabalho. Esta ação ajudará a evitar dificuldades em encontrar a tarefa em que está interessado, uma vez que terá de filtrar as tarefas Concluídas.
  • Limpa os dados da tarefa correspondente no nó (desde retentionTime que ainda não tenha sido atingido). Essa ação ajuda a garantir que seus nós não se encham com dados de tarefas e fiquem sem espaço em disco.

Nota

Para tarefas enviadas para o Batch, a chamada da API DeleteTask leva até 10 minutos para entrar em vigor. Antes de entrar em vigor, outras tarefas podem ser impedidas de serem agendadas. Isso porque o Batch Scheduler ainda tenta agendar as tarefas que acabaram de ser excluídas. Se você quiser excluir uma tarefa logo após o envio, encerre a tarefa em vez disso (já que a solicitação de encerrar tarefa entrará em vigor imediatamente). E, em seguida, exclua a tarefa 10 minutos depois.

Enviar um grande número de tarefas na coleção

As tarefas podem ser enviadas individualmente ou em coleções. Envie tarefas em coleções de até 100 de cada vez ao fazer o envio em massa de tarefas para reduzir a sobrecarga e o tempo de envio.

Definir tarefas máximas por nó adequadamente

O Batch suporta a sobresubscrição de tarefas em nós (executar mais tarefas do que um nó tem núcleos). Cabe a você garantir que suas tarefas tenham o tamanho certo para os nós em seu pool. Por exemplo, você pode ter uma experiência degradada se tentar agendar oito tarefas que consomem 25% de uso da CPU em um nó (em um pool com taskSlotsPerNode = 8).

Design para novas tentativas e reexecução

As tarefas podem ser repetidas automaticamente pelo Batch. Existem dois tipos de tentativas: controladas pelo usuário e internas. As novas tentativas controladas pelo usuário são especificadas pelo maxTaskRetryCount da tarefa. Quando um programa especificado na tarefa é encerrado com um código de saída diferente de zero, a tarefa é repetida até o valor do maxTaskRetryCount.

Embora rara, uma tarefa pode ser repetida internamente devido a falhas no nó de computação, como não ser capaz de atualizar o estado interno ou uma falha no nó enquanto a tarefa está em execução. A tarefa será repetida no mesmo nó de computação, se possível, até um limite interno antes de desistir da tarefa e adiar a tarefa a ser reagendada pelo Batch, potencialmente em um nó de computação diferente.

Não há diferenças de design ao executar suas tarefas em nós dedicados ou spot. Se uma tarefa é antecipada durante a execução em um nó Spot ou interrompida devido a uma falha em um nó dedicado, ambas as situações são atenuadas projetando a tarefa para resistir a falhas.

Crie tarefas duráveis

As tarefas devem ser concebidas de modo a resistir a falhas e a permitir novas tentativas. Este princípio é especialmente importante para tarefas de longa duração. Certifique-se de que suas tarefas gerem o mesmo resultado único, mesmo que sejam executadas mais de uma vez. Uma maneira de alcançar esse resultado é tornar suas tarefas "em busca de metas". Outra maneira é certificar-se de que suas tarefas são idempotentes (as tarefas terão o mesmo resultado, não importa quantas vezes sejam executadas).

Um exemplo comum é uma tarefa para copiar arquivos para um nó de computação. Uma abordagem simples é uma tarefa que copia todos os arquivos especificados sempre que é executada, o que é ineficiente e não foi criado para resistir a falhas. Em vez disso, crie uma tarefa para garantir que os arquivos estejam no nó de computação; Uma tarefa que não recopia arquivos que já estão presentes. Desta forma, a tarefa continua de onde parou se foi interrompida.

Evite o curto tempo de execução

Tarefas que só são executadas por um a dois segundos não são ideais. Tente fazer uma quantidade significativa de trabalho em uma tarefa individual (mínimo de 10 segundos, indo até horas ou dias). Se cada tarefa estiver sendo executada por um minuto (ou mais), a sobrecarga de agendamento como uma fração do tempo de computação geral será pequena.

Usar o escopo do pool para tarefas curtas em nós do Windows

Ao agendar uma tarefa em nós de lote, você pode escolher se deseja executá-la com o escopo da tarefa ou o escopo do pool. Se a tarefa for executada apenas por um curto período de tempo, o escopo da tarefa poderá ser ineficiente devido aos recursos necessários para criar a conta de usuário automático para essa tarefa. Para maior eficiência, considere definir essas tarefas para agrupar o escopo. Para obter mais informações, consulte Executar uma tarefa como um usuário automático com escopo de pool.

Nós

Um nó de computação é uma máquina virtual (VM) do Azure ou uma VM de serviço de nuvem dedicada ao processamento de uma parte da carga de trabalho do seu aplicativo. Siga estas diretrizes ao trabalhar com nós.

Iniciar tarefas: tempo de vida e idempotência

Tal como acontece com outras tarefas, a tarefa de início do nó deve ser idempotente. As tarefas de inicialização são executadas novamente quando o nó de computação é reiniciado ou quando o agente de lote é reiniciado. Uma tarefa idempotente é simplesmente aquela que produz um resultado consistente quando executada várias vezes.

As tarefas iniciais não devem ser de longa execução ou estar acopladas ao tempo de vida do nó de computação. Se você precisar iniciar programas que são serviços ou serviços semelhantes por natureza, construa uma tarefa de início que permita que esses programas sejam iniciados e gerenciados por recursos do sistema operacional, como systemd Linux ou Serviços do Windows. A tarefa inicial ainda deve ser construída como idempotente, de modo que a execução subsequente da tarefa inicial seja tratada corretamente se esses programas foram instalados anteriormente como serviços.

Gorjeta

Quando o Batch executar novamente sua tarefa inicial, ele tentará excluir o diretório da tarefa inicial e criá-lo novamente. Se Batch não conseguir recriar o diretório de tarefas iniciar, o nó de computação falhará ao iniciar a tarefa de início.

Esses serviços não devem aceitar bloqueios de arquivos em nenhum arquivo em diretórios gerenciados em lote no nó, porque, caso contrário, o Batch não poderá excluir esses diretórios devido aos bloqueios de arquivos. Por exemplo, em vez de configurar o lançamento do serviço diretamente do diretório de trabalho da tarefa inicial, copie os arquivos em outro lugar de forma idempotente. Em seguida, instale o serviço a partir desse local usando os recursos do sistema operacional.

Nós isolados

Considere o uso de tamanhos de VM isolados para cargas de trabalho com requisitos normativos ou de conformidade. Os tamanhos isolados suportados no modo de configuração da máquina virtual incluem Standard_E80ids_v4, Standard_M128ms, Standard_F72s_v2, Standard_G5, Standard_GS5e Standard_E64i_v3. Para obter mais informações sobre tamanhos de VM isolados, consulte Isolamento de máquina virtual no Azure.

Evite criar junções de diretório no Windows

As junções de diretório, às vezes chamadas de links físicos de diretório, são difíceis de lidar durante a limpeza de tarefas e tarefas. Use links simbólicos (soft-links) em vez de hard-links.

Discos temporários e AZ_BATCH_NODE_ROOT_DIR

O Batch depende de discos temporários de VM, para tamanhos de VM compatíveis com Batch, para armazenar metadados relacionados à execução de tarefas, juntamente com quaisquer artefatos de cada execução de tarefa nesse disco temporário. Exemplos desses pontos ou diretórios temporários de montagem em disco são: /mnt/batch, /mnt/resource/batche D:\batch\tasks. A substituição, remontagem, junção, ligação simbólica ou de outra forma o redirecionamento desses pontos de montagem e diretórios ou qualquer um dos diretórios pai não é suportada e pode levar à instabilidade. Se você precisar de mais espaço em disco, considere usar um tamanho ou família de VM que tenha espaço em disco temporário que atenda aos seus requisitos ou anexar discos de dados. Para obter mais informações, consulte a próxima seção sobre como anexar e preparar discos de dados para nós de computação.

Expor e preparar os discos de dados

Cada nó de computação individual tem exatamente a mesma especificação de disco de dados anexada, se especificada como parte da instância do pool de lotes. Somente novos discos de dados podem ser anexados a pools de lotes. Esses discos de dados conectados a nós de computação não são automaticamente particionados, formatados ou montados. É sua responsabilidade executar essas operações como parte de sua tarefa inicial. Essas tarefas iniciais devem ser criadas para serem idempotentes. É possível reexecutar as tarefas iniciais em nós de computação. Se a tarefa inicial não for idempotente, pode ocorrer perda potencial de dados nos discos de dados.

Gorjeta

Ao montar um disco de dados no Linux, se aninhar o ponto de montagem do disco sob os pontos de montagem temporários do Azure, como /mnt ou /mnt/resource, deve-se tomar cuidado para que nenhuma corrida de dependência seja introduzida. Por exemplo, se essas montagens forem executadas automaticamente pelo sistema operacional, pode haver uma corrida entre o disco temporário que está sendo montado e o(s) seu(s) disco(s) de dados sendo montado(s) sob o pai. Devem ser tomadas medidas para garantir que as dependências apropriadas sejam impostas pelos recursos disponíveis, como systemd ou adiar a montagem do disco de dados para a tarefa inicial como parte do script de preparação do disco de dados idempotente.

Preparando discos de dados em pools de lotes do Linux

Os discos de dados do Azure no Linux são apresentados como dispositivos de bloco e recebem um identificador típico sd[X] . Você não deve confiar em atribuições estáticas sd[X] , pois esses rótulos são atribuídos dinamicamente no momento da inicialização e não é garantido que sejam consistentes entre a primeira e as subsequentes. Você deve identificar seus discos anexados através dos mapeamentos apresentados em /dev/disk/azure/scsi1/. Por exemplo, se você especificou o LUN 0 para seu disco de dados na API AddPool, esse disco se manifestaria como /dev/disk/azure/scsi1/lun0. Por exemplo, se você listasse esse diretório, poderia ver:

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

Não há necessidade de traduzir a referência de volta para o sd[X] mapeamento em seu script de preparação, em vez disso, consulte o dispositivo diretamente. Neste exemplo, este dispositivo seria /dev/disk/azure/scsi1/lun0. Você pode fornecer essa ID diretamente para fdiska , mkfse qualquer outra ferramenta necessária para seu fluxo de trabalho. Como alternativa, você pode usar lsblk com blkid para mapear o UUID para o disco.

Para obter mais informações sobre discos de dados do Azure no Linux, incluindo métodos alternativos de localizar discos de dados e /etc/fstab opções, consulte este artigo. Certifique-se de que não há dependências ou raças conforme descrito na nota de dica antes de promover seu método para uso em produção.

Preparando discos de dados em pools de lotes do Windows

Os discos de dados do Azure anexados aos nós de computação do Windows em lote são apresentados não particionados e não formatados. Você precisa enumerar discos com RAW partições para ação como parte de sua tarefa inicial. Essas informações podem ser recuperadas usando o Get-Disk cmdlet do PowerShell. Como exemplo, você pode ver:

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

Onde o disco número 2 é o disco de dados não inicializado conectado a este nó de computação. Esses discos podem ser inicializados, particionados e formatados conforme necessário para seu fluxo de trabalho.

Para obter mais informações sobre discos de dados do Azure no Windows, incluindo scripts PowerShell de exemplo, consulte este artigo. Certifique-se de que todos os scripts de exemplo sejam validados para idempotência antes da promoção para uso em produção.

Coletar logs do agente em lote

Se você notar um problema envolvendo o comportamento de um nó ou tarefas em execução em um nó, colete os logs do agente em lote antes de deslocalizar os nós em questão. Os logs do agente de lote podem ser coletados usando a API de logs do serviço Upload Batch. Esses logs podem ser fornecidos como parte de um tíquete de suporte para a Microsoft e ajudarão na solução e resolução de problemas.

API de lote

Falhas de tempo limite

As falhas de tempo limite não indicam necessariamente que o serviço falhou ao processar a solicitação. Quando ocorrer uma falha de tempo limite, você deve tentar novamente a operação ou recuperar o estado do recurso, conforme apropriado para a situação, para verificar o status se a operação foi bem-sucedida ou falhou.

Conectividade

Analise as diretrizes a seguir relacionadas à conectividade em suas soluções em lote.

Grupos de Segurança de Rede (NSGs) e Rotas Definidas pelo Usuário (UDRs)

Ao provisionar pools de lotes em uma rede virtual, certifique-se de seguir de perto as diretrizes relativas ao uso do BatchNodeManagement.etiqueta de serviço de região , portas, protocolos e direção da regra. O uso da etiqueta de serviço é altamente recomendado; não use endereços IP subjacentes do serviço de lote, pois eles podem mudar ao longo do tempo. O uso direto de endereços IP do serviço de lote pode causar instabilidade, interrupções ou interrupções nos pools de lotes.

Para UDRs (Rotas Definidas pelo Usuário), é recomendável usar BatchNodeManagement.tags de serviço de região em vez de endereços IP de serviço em lote, pois elas podem mudar ao longo do tempo.

Honrando o DNS

Certifique-se de que seus sistemas respeitem o tempo de vida útil (TTL) do DNS para a URL do serviço da conta em lote. Além disso, certifique-se de que seus clientes de serviço de lote e outros mecanismos de conectividade com o serviço de lote não dependam de endereços IP.

Qualquer solicitação HTTP com códigos de status de nível 5xx, juntamente com um cabeçalho "Conexão: fechar" na resposta, requer o ajuste do comportamento do cliente de serviço em lote. Seu cliente de serviço de lote deve observar a recomendação fechando a conexão existente, resolvendo novamente o DNS para a URL do serviço de conta em lote e tentando seguir as solicitações em uma nova conexão.

Repetir solicitações automaticamente

Certifique-se de que seus clientes de serviço em lote tenham políticas de repetição apropriadas em vigor para repetir automaticamente suas solicitações, mesmo durante a operação normal e não exclusivamente durante qualquer período de tempo de manutenção do serviço. Essas políticas de repetição devem abranger um intervalo de pelo menos 5 minutos. Os recursos de repetição automática são fornecidos com vários SDKs de lote, como a classe .NET RetryPolicyProvider.

Endereços IP públicos estáticos

Normalmente, as máquinas virtuais em um pool de lotes são acessadas por meio de endereços IP públicos que podem ser alterados ao longo do tempo de vida do pool. Essa natureza dinâmica pode dificultar a interação com um banco de dados ou outro serviço externo que limita o acesso a determinados endereços IP. Para resolver essa preocupação, você pode criar um pool usando um conjunto de endereços IP públicos estáticos que você controla. Para obter mais informações, consulte Criar um pool de lotes do Azure com endereços IP públicos especificados.

Dependências subjacentes do nó de lote

Considere as seguintes dependências e restrições ao projetar suas soluções em lote.

Recursos criados pelo sistema

O Lote do Azure cria e gerencia um conjunto de usuários e grupos na VM, que não deve ser alterado:

Windows:

  • Um usuário chamado PoolNonAdmin
  • Um grupo de usuários chamado WATaskCommon

Linux:

  • Um usuário chamado _azbatch

Gorjeta

A nomeação desses usuários ou grupos são artefatos de implementação e estão sujeitos a alterações a qualquer momento.

Limpeza de ficheiros

O Batch tenta ativamente limpar o diretório de trabalho no qual as tarefas são executadas, assim que o tempo de retenção expirar. Quaisquer arquivos escritos fora deste diretório são de sua responsabilidade para limpar para evitar o preenchimento de espaço em disco.

A limpeza automatizada para o diretório de trabalho será bloqueada se você executar um serviço no Windows a partir do diretório de trabalho da tarefa inicial, devido à pasta ainda estar em uso. Esta ação levará a um desempenho degradado. Para corrigir esse problema, altere o diretório desse serviço para um diretório separado que não é gerenciado pelo lote.

Próximos passos