Erros de nó e pool de lotes do Azure

Algumas operações de criação e gerenciamento de pool do Azure Batch acontecem imediatamente. Detetar falhas para essas operações é simples, porque os erros geralmente retornam imediatamente da API, linha de comando ou interface do usuário. No entanto, algumas operações são assíncronas, executadas em segundo plano e levam vários minutos para serem concluídas. Este artigo descreve maneiras de detetar e evitar falhas que podem ocorrer nas operações em segundo plano para pools e nós.

Certifique-se de definir seus aplicativos para implementar uma verificação de erros abrangente, especialmente para operações assíncronas. A verificação abrangente de erros pode ajudá-lo a identificar e diagnosticar problemas prontamente.

Erros de pool

Os erros de pool podem estar relacionados a tempo limite ou falha de redimensionamento, falha de dimensionamento automático ou falha de exclusão de pool.

Redimensionar o tempo limite ou falha

Ao criar um novo pool ou redimensionar um pool existente, você especifica o número de destino dos nós. A operação de criação ou redimensionamento é concluída imediatamente, mas a alocação real de novos nós ou a remoção de nós existentes pode levar vários minutos. Você pode especificar o tempo limite de redimensionamento nas APIs Pool - Add ou Pool - Resize . Se o Lote não puder alocar o número de nós de destino durante o período de tempo limite de redimensionamento, o pool entrará em um estado estável e relatará erros de redimensionamento.

A propriedade resizeError lista os erros que ocorreram na avaliação mais recente.

As causas comuns para erros de redimensionamento incluem:

• Redimensione o tempo limite muito curto. Normalmente, o tempo limite padrão de 15 minutos é longo o suficiente para alocar ou remover nós do pool. Se você estiver alocando um grande número de nós, como mais de 1.000 nós de uma imagem do Azure Marketplace ou mais de 300 nós de uma imagem de máquina virtual (VM) personalizada, poderá definir o tempo limite de redimensionamento para 30 minutos.

• Quota de base insuficiente. Uma conta de lote é limitada no número de núcleos que pode alocar em todos os pools e para de alocar nós quando atinge essa cota. Você pode aumentar a cota principal para que o Batch possa alocar mais nós. Para obter mais informações, consulte Cotas e limites de serviço em lote.

• IPs de sub-rede insuficientes quando um pool está em uma rede virtual. Uma sub-rede de rede virtual deve ter endereços IP suficientes para alocar a cada nó de pool solicitado. Caso contrário, os nós não podem ser criados. Para obter mais informações, consulte Criar um pool de lotes do Azure em uma rede virtual.

• Recursos insuficientes quando um pool está em uma rede virtual. Ao criar um pool em uma rede virtual, você pode criar recursos como balanceadores de carga, IPs públicos e NSGs (grupos de segurança de rede) na mesma assinatura que a conta em lote. Verifique se as cotas de assinatura são suficientes para esses recursos.

• Grandes pools com imagens de VM personalizadas. Grandes pools que usam imagens de VM personalizadas podem levar mais tempo para alocar e tempos limite de redimensionamento podem ocorrer. Para obter recomendações sobre limites e configuração, consulte Criar um pool com a Galeria de Computação do Azure.

Falhas automáticas de dimensionamento

Você pode definir o Lote do Azure para dimensionar automaticamente o número de nós em um pool e definir os parâmetros para a fórmula de dimensionamento automático para o pool. Em seguida, o serviço Lote usa a fórmula para avaliar periodicamente o número de nós no pool e definir novos números de destino. Para obter mais informações, consulte Criar uma fórmula automática para dimensionar nós de computação em um pool de lotes.

Os seguintes problemas podem ocorrer quando você usa o dimensionamento automático:

• A avaliação automática do dimensionamento falha.
• A operação de redimensionamento resultante falha e atinge o tempo limite.
• Um problema com a fórmula de dimensionamento automático leva a valores de destino de nó incorretos. O redimensionamento pode funcionar ou atingir o tempo limite.

Para obter informações sobre a última avaliação automática de dimensionamento, use a propriedade autoScaleRun . Esta propriedade relata o tempo de avaliação, os valores e resultados, e quaisquer erros de desempenho.

O evento completo de redimensionamento do pool captura informações sobre todas as avaliações.

Falhas de exclusão de pool

Para excluir um pool que contém nós, o Batch primeiro exclui os nós, o que pode levar vários minutos para ser concluído. Em seguida, o lote exclui o próprio objeto do pool.

Batch define o poolState como durante deleting o processo de exclusão. O aplicativo de chamada pode detetar se a exclusão do pool está demorando muito usando as state propriedades e stateTransitionTime .

Se a exclusão do pool estiver demorando mais do que o esperado, o Batch tentará novamente periodicamente até que o pool seja excluído com êxito. Em alguns casos, o atraso deve-se a uma interrupção do serviço do Azure ou a outros problemas temporários. Outros fatores que impedem a exclusão bem-sucedida do pool podem exigir que você tome medidas para corrigir o problema. Esses fatores podem incluir os seguintes problemas:

• Os bloqueios de recursos podem ser colocados em recursos criados em lote ou em recursos de rede que o lote usa.

• Os recursos que você criou podem depender de um recurso criado em lote. Por exemplo, se você criar um pool em uma rede virtual, o Batch criará um NSG, um endereço IP público e um balanceador de carga. Se você estiver usando esses recursos fora do pool, não poderá excluí-lo.

• O Microsoft.Batch provedor de recursos pode não estar registrado na assinatura que contém seu pool.

• Para contas em lote do modo de assinatura de usuário, Microsoft Azure Batch talvez não tenha mais a função de Colaborador ou Proprietário da assinatura que contém seu pool. Para obter mais informações, consulte Permitir que o lote acesse a assinatura.

Erros de nó

Mesmo quando o Batch aloca com êxito nós em um pool, vários problemas podem fazer com que alguns nós não estejam íntegros e não consigam executar tarefas. Esses nós ainda incorrem em encargos, por isso é importante detetar problemas para evitar pagar por nós que você não pode usar. Saber sobre erros comuns de nó e conhecer o jobState atual é útil para a solução de problemas.

Iniciar falhas de tarefas

Você pode especificar um startTask opcional para um pool. Como em qualquer tarefa, a tarefa iniciar usa uma linha de comando e pode baixar arquivos de recursos do armazenamento. A tarefa de início é executada para cada nó quando o nó é iniciado. A waitForSuccess propriedade especifica se Batch aguarda até que a tarefa inicial seja concluída com êxito antes de agendar qualquer tarefa para um nó. Se você configurar o nó para aguardar a conclusão bem-sucedida da tarefa inicial, mas a tarefa inicial falhar, o nó não poderá ser usado, mas ainda incorrerá em cobranças.

Você pode detetar falhas de tarefa inicial usando as propriedades taskExecutionResult e taskFailureInformation da propriedade de nó startTaskInformation de nível superior.

Uma tarefa de inicialização com falha também faz com que Batch defina o computeNodeState como starttaskfailed, se waitForSuccess foi definido como true.

Como em qualquer tarefa, pode haver muitas causas para uma falha na tarefa inicial. Para solucionar problemas, verifique o stdout, stderr e quaisquer outros arquivos de log específicos da tarefa.

As tarefas de início devem ser reentrantes, porque a tarefa inicial pode ser executada várias vezes no mesmo nó, por exemplo, quando o nó é recriado ou reinicializado. Em casos raros, quando uma tarefa inicial é executada após um evento causar uma reinicialização do nó, um sistema operacional (SO) ou disco efêmero recria imagens enquanto o outro não. Como as tarefas de inicialização em lote e todas as tarefas em lote são executadas a partir do disco efêmero, essa situação geralmente não é um problema. No entanto, nos casos em que a tarefa de início instala um aplicativo no disco do sistema operacional e mantém outros dados no disco efêmero, pode haver problemas de sincronização. Proteja seu aplicativo de acordo se você usar ambos os discos.

Falha ao transferir o pacote de aplicações

Você pode especificar um ou mais pacotes de aplicativos para um pool. O Batch baixa os arquivos de pacote especificados para cada nó e descompacta os arquivos depois que o nó é iniciado, mas antes de agendar tarefas. É comum usar um comando start task com pacotes de aplicativos, por exemplo, para copiar arquivos para um local diferente ou para executar a instalação.

Se um pacote de aplicativo falhar ao baixar e descompactar, a propriedade computeNodeError relatará a falha e definirá o estado do nó como unusable.

Falha no download do contêiner

Você pode especificar uma ou mais referências de contêiner em um pool. O lote baixa os contêineres especificados para cada nó. Se o contêiner falhar ao baixar, a propriedade computeNodeError relatará a falha e definirá o estado do nó como unusable.

Atualizações do SO do nó

Para pools do Windows, enableAutomaticUpdates é definido como true por padrão. Embora seja recomendável permitir atualizações automáticas, as atualizações podem interromper o progresso das tarefas, especialmente se elas forem de longa execução. Você pode definir esse valor como false se precisar garantir que uma atualização do sistema operacional não aconteça inesperadamente.

Nó em estado inutilizável

Batch pode definir o computeNodeState como unusable por vários motivos. Não é possível agendar tarefas para um unusable nó, mas o nó ainda incorre em encargos.

Se Batch puder determinar a causa, a propriedade computeNodeError a relatará. Se um nó estiver em um unusable estado, mas não tiver computeNodeError, isso significa que o Batch não consegue se comunicar com a VM. Nesse caso, o Batch sempre tenta recuperar a VM. No entanto, o Batch não tenta recuperar automaticamente VMs que não conseguiram instalar pacotes de aplicativos ou contêineres, mesmo que seu estado seja unusable.

Outras razões para unusable nós podem incluir as seguintes causas:

• Uma imagem de VM personalizada é inválida. Por exemplo, a imagem não está devidamente preparada.
• Uma VM é movida devido a uma falha de infraestrutura ou uma atualização de baixo nível. O lote recupera o nó.
• Uma imagem de VM foi implantada em hardware que não oferece suporte a ela.
• As VMs estão em uma rede virtual do Azure e o tráfego foi bloqueado para portas de chave.
• As VMs estão em uma rede virtual, mas o tráfego de saída para o Armazenamento do Azure está bloqueado.
• As VMs estão em uma rede virtual com uma configuração de DNS personalizada e o servidor DNS não pode resolver o armazenamento do Azure.

Arquivos de log do agente do nó

O processo de agente em lote executado em cada nó do pool fornece arquivos de log que podem ajudar se você precisar entrar em contato com o suporte sobre um problema de nó do pool. Você pode carregar arquivos de log para um nó por meio do portal do Azure, do Batch Explorer ou da API Compute Node - Upload Batch Service Logs . Depois de carregar e salvar os arquivos de log, você pode excluir o nó ou o pool para economizar o custo de execução dos nós.

Disco de nó cheio

O lote usa a unidade temporária em uma VM de pool de nós para armazenar arquivos como os seguintes arquivos de trabalho, arquivos de tarefas e arquivos compartilhados:

• Arquivos do pacote do aplicativo
• Ficheiros de recursos de tarefas
• Arquivos específicos do aplicativo baixados para uma das pastas em lote
• Arquivos Stdout e stderr para cada execução de aplicativo de tarefa
• Arquivos de saída específicos do aplicativo

Arquivos como pacotes de aplicativos ou arquivos de recursos de tarefas iniciais gravam apenas uma vez quando o Batch cria o nó do pool. Mesmo que eles só escrevem uma vez, se esses arquivos são muito grandes, eles podem preencher a unidade temporária.

Outros arquivos, como stdout e stderr, são escritos para cada tarefa executada por um nó. Se um grande número de tarefas for executado no mesmo nó ou se os arquivos de tarefas forem muito grandes, eles poderão preencher a unidade temporária.

O nó também precisa de uma pequena quantidade de espaço no disco do sistema operacional para criar usuários depois que ele é iniciado.

O tamanho da unidade temporária depende do tamanho da VM. Uma consideração ao escolher um tamanho de VM é garantir que a unidade temporária tenha espaço suficiente para a carga de trabalho planejada.

Ao adicionar um pool no portal do Azure, você pode exibir a lista completa de tamanhos de VM, incluindo uma coluna Tamanho do disco de recurso. Os artigos que descrevem tamanhos de VM têm tabelas com uma coluna Armazenamento Temporário. Para obter mais informações, veja Tamanhos de máquinas virtuais otimizados para computação. Para obter um exemplo de tabela de tamanhos, consulte Fsv2-series.

Você pode especificar um tempo de retenção para arquivos gravados por cada tarefa. O tempo de retenção determina por quanto tempo manter os arquivos de tarefas antes de limpá-los automaticamente. Você pode reduzir o tempo de retenção para reduzir os requisitos de armazenamento.

Se o disco temporário ou do SO ficar sem espaço ou estiver perto de ficar sem espaço, o nó será movido para o unusable computeNoteState e o erro do nó informará que o disco está cheio.

Se você não tiver certeza do que está ocupando espaço no nó, tente conectar-se remotamente ao nó e investigar manualmente. Você também pode usar a API File - List From Compute Node para examinar arquivos, por exemplo, saídas de tarefas, em pastas gerenciadas em lote. Essa API lista apenas arquivos nos diretórios gerenciados em lote. Se suas tarefas criaram arquivos em outro lugar, essa API não os mostra.

Depois de se certificar de recuperar todos os dados necessários do nó ou carregá-los para um armazenamento durável, você pode excluir dados conforme necessário para liberar espaço.

Você pode excluir trabalhos concluídos antigos ou tarefas cujos dados de tarefas ainda estão nos nós. Procure na recentTasks coleção na taskInformation no nó ou use a API File - List From Compute Node . A exclusão de um trabalho exclui todas as tarefas do trabalho. A exclusão das tarefas no trabalho aciona a exclusão de dados nos diretórios de tarefas nos nós e libera espaço. Depois de liberar espaço suficiente, reinicie o nó. O nó deve sair do unusable estado e entrar novamente idle .

Para recuperar um nó inutilizável em pools VirtualMachineConfiguration , você pode remover o nó do pool usando a API Pool - Remove Nodes . Então você pode cultivar a piscina novamente para substituir o nó ruim por um novo.

Importante

Reimage não é suportado atualmente para pools VirtualMachineConfiguration .

Próximos passos

• Saiba mais sobre a verificação de erros de tarefas e tarefas.
• Saiba mais sobre as práticas recomendadas para trabalhar com o Azure Batch.