Compartilhar via

Melhores práticas do Lote do Azure

  • Artigo

Este artigo aborda as práticas recomendadas e as dicas úteis para usar o serviço do Lote do Azure com eficiência. Essas dicas podem ajudar você a melhorar o desempenho e evitar armadilhas de design em suas soluções do Lote.

Dica

Para obter diretrizes sobre segurança no Lote do Azure, consulte Melhores práticas de segurança e conformidade do Lote.

Pools

Os 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 do Lote.

Configuração e nomenclatura de pool

  • Modo de alocação de pool: Ao criar uma conta do Lote, é possível escolher entre dois modos de alocação de pool: Serviço do Lote ou assinatura de usuário. Na maioria dos casos, você deve usar o modo de serviço de Lote padrão, no qual os pools são alocados em segundo plano em assinaturas gerenciadas no Lote. No modo de assinatura alternativo do usuário, as VMs do Lote e outros recursos são criados diretamente em sua assinatura, quando um pool é criado. As contas de assinatura de usuário são usadas principalmente para habilitar um subconjunto de cenários importante, mas pequeno. Para saber mais, confira a configuração para o modo de assinatura do usuário.

  • Modo de comunicação classic ou simplified: os pools também 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 do Lote 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 Microsoft Azure. No modo de comunicação de nó simplificado, os nós de computação iniciam a comunicação com o serviço do Lote. Devido ao escopo reduzido das conexões de entrada/saída necessárias e à não necessidade de acesso de saída do Armazenamento do Azure para a operação de linha de base, a recomendação é usar o modelo de comunicação de nó simplificado. Alguns aprimoramentos futuros no serviço do Lote também exigirão o modelo de comunicação de nó simplificado. O modelo de comunicação do nó clássico será desativado em 31 de março de 2026.

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

  • Múltiplos nós de computação: não há garantia de que os nós individuais estejam sempre disponíveis. Embora não sejam comuns, falhas de hardware, atualizações de sistema operacional e outros problemas podem fazer com que nós individuais fiquem offline. Se a carga de trabalho do Lote exigir um progresso determinístico e garantido, você deverá alocar pools com vários nós.

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

  • SKUs de VM com datas de EOL (fim de vida útil) iminentes: assim como em imagens de VM, SKUs de VM ou famílias também podem atingir o EOL de suporte do Lote. Essas datas podem ser descobertas por meio da ListSupportedVirtualMachineSkus API, do PowerShell ou da CLI do Azure. Planeje a migração da carga de trabalho para uma SKU de VM não EOL criando um novo pool com uma SKU de VM com suporte apropriado. A ausência de uma data de batchSupportEndOfLife associada para uma SKU de VM não indica que essa SKU específica terá suporte indefinidamente. Uma data de EOL pode ser adicionada ou atualizada no futuro a qualquer momento.

  • Nomes de recursos exclusivos: os recursos do Lote (trabalhos, pools etc.) geralmente entram e saem ao longo do tempo. Por exemplo, você pode criar um pool na segunda-feira, excluí-lo na terça-feira e criar outro semelhante na quinta-feira. Os novos recursos criados devem receber um nome exclusivo que você não usou antes. Você pode ter exclusividade usando um GUID (como o nome do recurso inteiro ou como parte dele) ou inserindo a data e a hora em que o recurso foi criado no nome do recurso. O Lote dá suporte ao DisplayName, que pode ser usado para atribuir a um recurso um nome fácil, mesmo que a ID de recurso real seja algo não tão amigável para as pessoas. Se você usar nomes exclusivos, isso facilita diferenciar um recurso específico que fez algo em logs e métricas. Ele também removerá a ambiguidade se você precisar arquivar um caso de suporte para um recurso.

  • Continuidade durante a manutenção e a falha do pool: É melhor fazer com que seus trabalhos usem pools dinamicamente. Se os seus trabalhos usarem o mesmo pool para tudo, haverá a chance de que os trabalhos não sejam executados se algo der errado com o pool. Esse princípio é especialmente importante para cargas de trabalho com detecção de hora. 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 dos negócios durante a manutenção e a falha do pool: há muitas razões pelas quais um pool pode não aumentar para o tamanho desejado, como erros internos ou restrições de capacidade. Verifique se você pode redirecionar os trabalhos em um pool diferente (possivelmente com um tamanho de VM diferente usando UpdateJob), se necessário. Evite contar com uma ID de pool estático com a expectativa de que ela nunca seja excluída e alterada.

Segurança do pool

Limite de isolamento

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

Atualizações do Agente de nó do lote

Os agentes de nó do lote não são atualizados automaticamente para os pools que têm nós de computação diferentes de zero. Para garantir que os pools do Lote recebam as últimas correções de segurança e atualizações para o agente de nó do Lote, você precisa redimensionar o pool para zero nó de computação ou recriar o pool. É recomendável monitorar as notas sobre a versão do Agente de Nó do Lote para entender as alterações nas novas versões do agente de nó do Lote. Verificar regularmente se há atualizações quando elas foram lançadas permite planejar atualizações para a versão mais recente do agente.

Antes de recriar ou redimensionar seu pool, você deverá baixar todos os logs do agente de nós para fins de depuração se estiver enfrentando problemas com o pool do Lote ou os nós de computação. O processo é discutido na seção Nós.

Observação

Para obter diretrizes gerais sobre a segurança no Lote do Azure, confira Melhores práticas de segurança e conformidade do Lote.

Atualizações do sistema operacional

É recomendável que a imagem da VM selecionada para um pool do Lote esteja atualizada com as atualizações de segurança mais recentes fornecidas pelo editor. Algumas imagens podem realizar atualizações automáticas de pacotes ao serem inicializadas (ou logo em seguida), o que pode interferir em certas ações dirigidas pelo usuário, como recuperar atualizações de repositórios de pacotes (por exemplo, apt update) ou instalar pacotes durante ações como um StartTask.

É recomendável habilitar a Atualização do sistema operacional automático para pools do Lote, o que permite que a infraestrutura subjacente do Azure coordene as atualizações no pool. Essa opção pode ser configurada para não interromper a execução da tarefa. A atualização automática do sistema operacional não é compatível com todos os sistemas operacionais suportados pelo Batch. Para obter mais informações, consulte a Matriz de Suporte de atualização do Sistema Operacional Automático dos Conjuntos de Dimensionamento de Máquinas Virtuais. Quanto aos sistemas operacionais do Windows, verifique se você não está habilitando a propriedade virtualMachineConfiguration.windowsConfiguration.enableAutomaticUpdates ao usar a atualização do Sistema operacional automático no pool do Lote.

O Lote do Azure 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 para imagens são de responsabilidade do editor da imagem e não do Lote do Azure. Para determinadas imagens publicadas em microsoft-azure-batch, não há garantia de que essas imagens sejam mantidas atualizadas com a imagem derivada upstream delas.

Tempo de vida e cobrança do pool

O tempo de vida do pool pode variar de acordo com o método de alocação e as 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 (dimensionamento automático ou pool automático).

  • Recriação do pool: evite excluir e recriar os pools diariamente. Em vez disso, crie um pool e atualize seus trabalhos existentes para apontar para o novo pool. Depois que todas as tarefas forem movidas para o novo pool, exclua o pool antigo.

  • Eficiência e cobrança do pool: o Lote em si não incorre em encargos adicionais. No entanto, você incorre em encargos de recursos do Azure usados, por exemplo, computação, armazenamento, rede e outros que possam ser exigidos pela carga de trabalho do Lote. Você será cobrado por cada nó de computação no pool, independentemente do estado em que ele está. Para mais informações, confira Análise de custo e orçamentos para o Lote do Azure.

  • Discos de SO efêmeros: os pools de configuração de máquina virtual podem usar discos de SO efêmeros, que criam o disco de SO no cache da VM ou em um SSD temporário para evitar custos adicionais associados a discos gerenciados.

Falhas de alocação de pool

As falhas de alocação de pool podem ocorrer a qualquer momento durante a primeira alocação ou redimensionamentos subsequentes. Essas falhas podem ocorrer devido ao esgotamento de capacidade temporária em uma região ou às falhas em outros serviços do Azure dos quais o Lote depende. Sua cota principal não é uma garantia, mas um limite.

Tempo de inatividade não planejado

É possível que os pools do Lote tenham eventos de tempo de inatividade no Azure. Entender que os problemas podem surgir e você deve desenvolver seu fluxo de trabalho para ser resiliente em reexecuções. Se nós falharem, o Lote tentará recuperar automaticamente esses nós de computação em seu nome. Essa recuperação pode disparar o reagendamento de qualquer tarefa em execução no nó restaurado ou em um nó diferente disponível. Confira Projetar para repetições para saber mais sobre as tarefas interrompidas.

Pools de imagem personalizada

Ao criar um pool no Lote 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. É possível criar o pool com uma imagem do Azure Marketplace compatível ou 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, é recomendável criar imagens personalizadas com o uso da Galeria de Computação do Azure sempre que possível. O uso da Galeria de Computação do Azure ajuda você 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 as contas do Lote no modo de assinatura do usuário, o erro "Falha na alocação devido à verificação da qualificação de compra do Marketplace" pode ser exibido ao criar um pool com determinadas imagens de terceiros. Para resolver esse erro, aceite os termos definidos pelo editor da imagem. Faça isso com usando oAzure PowerShell ou a CLI do Azure.

Pools de contêineres

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. Verifique se 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 pulls de imagem. Verifique se sua carga de trabalho não excede 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 artefato no ACR.

Dependência da região do Azure

É aconselhável não depender de uma única região do Azure caso tenha uma carga de trabalho de produção ou sensível ao tempo. Embora seja raro, há problemas que podem afetar toda a região. Por exemplo, se o processamento precisar ser iniciado em um momento específico, considere escalar verticalmente o pool em sua região primária bem antes da hora de início. Se a escala do pool falhar, você poderá fazer fallback para escalar verticalmente um pool em uma região (ou regiões) de backup.

Os pools em várias contas em regiões diferentes 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.

Trabalhos

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

Menos trabalhos, mais tarefas

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

Evite criar uma solução de Lote que exija milhares de trabalhos ativos simultaneamente. Não há nenhuma cota para tarefas; então, executar muitas tarefas com o mínimo de trabalhos possível usa com eficiência suas cotas de trabalho e de agendamento de trabalho.

Tempo de vida do trabalho

Um trabalho em Lotes tem um tempo de vida indefinido até que seja excluído do sistema. Seu estado designa se ele 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 disparada automaticamente por meio da propriedade onAllTasksComplete ou maxWallClockTime.

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

Exclua trabalhos quando eles não forem mais necessários, mesmo se estiverem em estado concluído. Embora os trabalhos concluídos não contem para a cota de trabalho ativa, é benéfico limpar periodicamente os trabalhos concluídos. Por exemplo, a listagem de trabalhos será mais eficiente quando o número total de trabalhos for menor (mesmo se os filtros adequados forem 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 Lote para nós de computação. As seções a seguir fornecem sugestões para projetar suas tarefas para lidar com problemas e ter um desempenho eficiente.

Salvar dados da tarefa

Os nós de computação são, por sua natureza, efêmeros. Há muitos recursos no Lote, como o pool automático e o dimensionamento automático, que facilitam o desaparecimento dos nós. Quando os nós deixam 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. Por causa desse comportamento, uma tarefa deve mover sua saída do nó em execução e para um repositório 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 em um repositório durável.

O Lote tem suporte integrado ao Armazenamento do Azure para carregar dados por meio de OutputFiles, e com vários de sistemas de arquivos compartilhados, ou você pode executar o upload por conta própria em suas tarefas.

Gerenciar 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 Lote limpará automaticamente o espaço em disco usado pela tarefa quando o retentionTime expirar.

A exclusão de tarefas realiza duas coisas:

  • Garante que você não terá um acúmulo de tarefas no trabalho. Essa ação ajudará a evitar a dificuldade de encontrar a tarefa em que você está interessado, pois você terá que filtrar as tarefas Concluídas.
  • Limpa os dados de tarefa correspondentes no nó (desde que o retentionTime ainda não tenha sido atingido). Essa ação ajuda a garantir que os nós não sejam preenchidos com os dados da tarefa e fique sem espaço em disco.

Observação

Para tarefas recém-enviadas ao Lote, a chamada à API DeleteTask leva até 10 minutos para entrar em vigor. Antes que ela entre em vigor, outras tarefas podem ser impedidas de serem agendadas. Isso ocorre porque o Agendador do Lote ainda tenta agendar as tarefas excluídas. Se você quiser excluir uma tarefa logo após ela ser enviada, encerre a tarefa em vez disso (já que a solicitação de tarefa de término entrará em vigor imediatamente). Em seguida, exclua a tarefa 10 minutos depois.

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

As tarefas podem ser enviadas em uma base individual ou em coleções. Envie tarefas em coleções de até 100 por vez ao realizar o envio em massa de tarefas para reduzir a sobrecarga e o tempo de envio.

Definir o máximo de tarefas por nó adequadamente

O Lote permite tarefas de substituição em nós (a execução de mais tarefas em vez de um nó tem núcleos). Depende de você garantir que suas tarefas tenham o tamanho certo para os nós no pool. Por exemplo, você pode ter uma experiência degradada se tentar agendar oito tarefas, cada uma consumindo 25% de uso da CPU em um nó (em um pool com taskSlotsPerNode = 8).

Design para novas tentativas e nova execução

As tarefas podem ser repetidas automaticamente pelo Lote. Há dois tipos de tentativas: controlado pelo usuário e interno. 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 da maxTaskRetryCount.

Embora seja raro, 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 adiá-la para ser reagendada pelo Lote, 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 com a criação da tarefa para resistir à falha.

Criar tarefas duráveis

As tarefas devem ser projetadas para resistir à falha e acomodar novas tentativas. Esse princípio é importante principalmente para tarefas de execução prolongada. Verifique se as tarefas geram o mesmo resultado, mesmo que elas sejam executadas mais de uma vez. Uma maneira de alcançar esse resultado é tornar suas tarefas "busca de meta". Outra maneira é garantir que suas tarefas sejam idempotentes (as tarefas terão o mesmo resultado, independentemente de quantas vezes são executadas).

Um exemplo comum é uma tarefa que copia arquivos para um nó de computação. Uma abordagem simples é uma tarefa que copia todos os arquivos especificados toda vez que ela é executada, o que é ineficiente e não é 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 copia arquivos que já estão presentes. Dessa forma, a tarefa é escolhida de onde parou se foi interrompida.

Evitar tempo de execução curto

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

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

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

Nós

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

Iniciar tarefas: vida útil e idempotência

Assim como acontece com outras tarefas, o nó tarefa iniciar deve ser idempotente. As tarefas iniciar são reexecutadas quando o nó de computação é reiniciado ou o agente do Lote é reiniciado. Uma tarefa idempotente produz um resultado consistente quando executada várias vezes.

As tarefas iniciar não devem ser de execução prolongada nem estar acopladas para toda a vida útil do nó de computação. Se precisar iniciar programas que são serviços ou de natureza semelhante a serviços, conceba uma tarefa iniciar que permita que esses programas sejam iniciados e gerenciados por instalações do sistema operacional, como systemd nos Serviços do Windows ou Linux. A tarefa iniciar continua precisando ser concebida como idempotente, de modo que a execução subsequente da tarefa iniciar seja tratada corretamente se esses programas tiverem sido instalados anteriormente como serviços.

Dica

Quando reexecutar sua tarefa iniciar, o Lote tentará excluir o diretório da tarefa de iniciar e criá-lo novamente. Se o Lote não conseguir recriar o diretório da tarefa iniciar, o nó de computação não conseguirá inicializar a tarefa iniciar.

Esses serviços não devem fazer bloqueios de arquivo em nenhum arquivo nos diretórios do nó gerenciados em Lote porque, caso contrário, o Lote não será capaz de excluir esses diretórios devido aos bloqueios de arquivo. Por exemplo, em vez de configurar a inicialização do serviço diretamente do diretório de trabalho da tarefa iniciar, copie os arquivos em outro lugar de forma idempotente. Em seguida, instale o serviço a partir desse local usando as instalações do sistema operacional.

Nós isolados

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

Evitar 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 da tarefa e do trabalho. Use symlinks (links soft) em vez de links físicos.

Discos temporários e AZ_BATCH_NODE_ROOT_DIR

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

Anexar e preparar os discos de dados

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

Dica

Ao montar um disco de dados no Linux, se estiver aninhando o ponto de montagem de 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, poderá haver uma corrida entre o disco temporário que está sendo montado e os discos de dados que estão sendo montados sob o pai. Etapas devem ser tomadas para garantir que as dependências apropriadas sejam impostas por instalações 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 do Lote do Linux

Os discos de dados do Azure no Linux são apresentados como dispositivos de bloco e atribuídos a um identificador típico sd[X]. Você não deve depender de atribuições estáticas sd[X], pois esses rótulos são atribuídos dinamicamente no momento da inicialização e não têm garantia de serem consistentes entre a primeira e as inicializações subsequentes. Você deve identificar seus discos anexados por meio dos mapeamentos apresentados em /dev/disk/azure/scsi1/. Por exemplo, se você especificou LUN 0 para o 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 é necessário traduzir a referência de volta para o mapeamento sd[X] em seu script de preparação; confira o dispositivo diretamente. Nesse exemplo, esse dispositivo seria /dev/disk/azure/scsi1/lun0. Você pode fornecer essa ID diretamente para fdisk, mkfs e qualquer outra ferramenta necessária para o fluxo de trabalho. Alternativamente, 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 localização de discos de dados e opções de /etc/fstab, confira esse artigo. Certifique-se de que não exista nenhuma dependência ou condições de corrida conforme descrito pela nota de Dica antes de promover seu método para ser usado na produção.

Preparando discos de dados em pools do Lote do Windows

Os discos de dados do Azure anexados aos nós de computação do Windows do Lote são apresentados sem partição e não formatados. Você precisará enumerar discos com partições RAW para que funcionem como parte da sua tarefa iniciar. Essas informações podem ser recuperadas usando o cmdlet do PowerShell Get-Disk. Por 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

Em que o disco 2 é o disco de dados não inicializado anexado a esse nó de computação. Esses discos podem ser inicializados, particionados e formatados conforme a necessidade do fluxo de trabalho.

Para obter mais informações sobre discos de dados do Azure no Windows, incluindo amostras de scripts do PowerShell, confira esse artigo. Certifique-se de que todas as amostras de scripts sejam validadas para idempotência antes de serem promovidas promoção para uso na produção.

Coletar logs de agente do Lote

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

API do 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ê deverá repetir a operação ou recuperar o estado do recurso, conforme apropriado para a situação, para verificar o status da operação: sucesso ou falha.

Conectividade

Reveja as diretrizes a seguir relacionadas à conectividade em suas soluções do Lote.

NSGs (grupos de segurança de rede) e UDRs (rotas definidas pelo usuário)

Ao provisionar pools do Lote em uma rede virtual, verifique se você está seguindo as diretrizes em relação ao uso da marca de serviço BatchNodeManagement.region, das portas, dos protocolos e da direção da regra. O uso da marca de serviço é altamente recomendado; não use endereços IP do serviço do Lote subjacentes, pois eles podem ser alterados ao longo do tempo. Usar endereços IP do serviço do Lote diretamente pode causar instabilidade ou interrupções nos pools do Lote.

Para Rotas Definidas pelo Usuário (UDRs), recomenda-se usar BatchNodeManagement.região marcas de serviço em vez de endereços IP de serviço de lote, pois eles podem ser alterados com o tempo.

Como honrar o DNS

Verifique se os seus sistemas estão respeitando a TTL (vida útil) do DNS para a URL do serviço da conta do Lote. Além disso, verifique se os clientes de serviço do Lote e outros mecanismos de conectividade para o serviço do Lote não dependem de endereços IP.

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

Repetir solicitações automaticamente

Verifique se os clientes do serviço do Lote têm 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 os períodos 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 do Lote, como a classe .NET RetryPolicyProvider.

Endereços IP públicos estáticos

Normalmente, as máquinas virtuais em um pool do lote são acessadas por meio de endereços IP públicos que podem ser alterados durante o 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 lidar com essa questão, você pode criar um pool usando um conjunto de endereços IP públicos estáticos controlados por você. Para obter mais informações, consulte Criar um pool do Lote do Azure com endereços IP públicos especificados.

Dependências subjacentes do nó do Lote

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

Recursos criados pelo sistema

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

Windows:

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

Linux:

  • Um usuário chamado _azbatch

Dica

As nomenclaturas desses usuários ou grupos são artefatos de implementação e estão sujeitas a alterações a qualquer momento.

Limpeza de arquivo

O Lote tenta ativamente limpar o diretório de trabalho no qual as tarefas são executadas, quando o tempo de retenção expira. Você é responsável por limpar todos os arquivos gravados fora desse diretório para evitar o preenchimento do 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 Iniciar tarefa, pois a pasta ainda está em uso. Essa 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 seja gerenciado pelo Lote.

Próximas etapas