Azure Batch pool e erros de nós

Algumas operações de criação e gestão de pools do Azure Batch são realizadas imediatamente. Detetar falhas nestas operações é simples, pois os erros normalmente regressam imediatamente da API, linha de comandos ou interface de utilizador. No entanto, algumas operações são assíncronas, executam-se em segundo plano e demoram vários minutos a ser concluídas. Este artigo descreve formas de detetar e evitar falhas que podem ocorrer nas operações em segundo plano para pools e nós.

Certifique-se de configurar as suas aplicações para implementar verificação de erros abrangente, especialmente para operações assíncronas. Uma verificação abrangente de erros pode ajudá-lo a identificar e diagnosticar rapidamente problemas.

Erros de pool

Erros de pool podem estar relacionados a tempo de espera ou falha de redimensionamento, falha de escalonamento automático, ou falha na eliminação do pool. Com a inclusão de mensagens de erro mais detalhadas, o diagnóstico e a resolução destes problemas tornaram-se mais simples.

Detalhes do Erro do Fornecedor de Relé

Os erros do fornecedor de relay são diretamente transmitidos pelos fornecedores de recursos Azure subjacentes, como o Azure Virtual Machine Scale Set (VMSS), e oferecem uma compreensão mais profunda sobre o motivo pelo qual uma operação de pool falhou. Estes erros ocorrem tipicamente quando a criação, redimensionamento ou eliminação de um pool é afetado por um problema de serviço de camada inferior.

Estrutura do Erro do Fornecedor de Relé

Estes erros são fornecidos num formato JSON estruturado contendo os seguintes componentes-chave:

• Código de Erro: O tipo de erro encontrado (ex.: AllocationFailed, BadRequest, etc.).
• Mensagem de Erro: Breve descrição do erro
• Provider Error Json: Uma mensagem de erro detalhada gerada pelo serviço Azure subjacente (por exemplo, VMSS).
• Erro do Fornecedor Truncado: Um Booleano que indica se a mensagem de erro do fornecedor foi truncada devido a limites de tamanho.

Exemplos de Erros no Fornecedor de Relé

Exemplo 1

Código de Erro:AllocationFailed
Mensagem de Erro: O número desejado de nós dedicados não pôde ser alocado
Erro de Fornecedor JSON:

{
  "error": {
    "code": "BadRequest",
    "message": "The selected VM size 'STANDARD_A1_V2' cannot boot Hypervisor Generation '2'. If this was a Create operation, please ensure that the Hypervisor Generation of the Image matches the Hypervisor Generation of the selected VM Size. If this was an Update operation, please choose a Hypervisor Generation '2' VM Size."
  }
}

Erro de Fornecedor JSON Truncado: Falso

Este erro indica uma incompatibilidade entre o tamanho da VM e a geração do Hypervisor. A mensagem de erro sugere selecionar um tamanho de VM compatível para resolver o problema.

Exemplo 2

Código de Erro:AllocationFailed
Mensagem de Erro: Ocorreu um erro interno ao redimensionar o pool
Erro de Fornecedor JSON:

{
  "error": {
    "code": "ScopeLocked",
    "message": "The scope '/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Compute/VirtualMachineScaleSets/<guid>-azurebatch-VMSS-D' cannot perform write operation because the following scope(s) are locked: '/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Compute/VirtualMachineScaleSets/<guid>-azurebatch-VMSS-D'. Please remove the lock and try again."
  }
}

Erro de Fornecedor JSON Truncado: Falso

Este erro indica que a operação de redimensionamento do pool falhou porque um alcance estava bloqueado, impedindo a operação de escrita; remover o bloqueio pode resolver o problema.

Os erros do fornecedor de relay oferecem uma visão mais profunda sobre falhas na operação do pool, facilitando o diagnóstico e a resolução de problemas diretamente a partir dos serviços Azure.

Redimensionar o timeout ou falhar

Quando cria um novo pool ou redimensiona um pool existente, especifica o número alvo de nós. A operação de criação ou redimensionamento é concluída imediatamente, mas a alocação efetiva de novos nós ou a remoção de nós existentes pode demorar vários minutos. Pode especificar o timeout de redimensionamento nas APIs de Criar Pool ou Redimensionar Pool . Se o Batch não conseguir alocar o número alvo de nós durante o período de tempo de redimensionamento, o pool entra em estado estacionário e relata erros de redimensionamento.

As causas comuns para erros de redimensionamento incluem:

• Redimensionar o timeout é demasiado curto. Normalmente, o timeout padrão de 15 minutos é suficientemente longo para alocar ou remover nós do pool. Se estiver a alocar 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 personalizada de máquina virtual (VM), pode definir o tempo de redimensionamento para 30 minutos.

• Quota de núcleo insuficiente. Uma conta Batch é limitada no número de núcleos que pode alocar em todos os pools e pára de alocar nós assim que atinge essa quota. Podes aumentar a quota de core para que o Batch possa alocar mais nós. Para obter mais informações, consulte Cotas e limites do serviço Batch.

• Número insuficiente de IPs na sub-rede quando um pool está numa rede virtual. Uma sub-rede virtual de rede 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 mais informações, consulte Criar um pool Batch Azure numa rede virtual.

• Recursos insuficientes quando um pool está numa rede virtual. Ao criar um pool numa rede virtual, pode criar recursos como balanceadores de carga, IPs públicos e grupos de segurança de rede (NSGs) na mesma subscrição da conta Batch. Certifique-se de que as quotas de subscrição são suficientes para estes recursos.

• Grandes pools com imagens de VM personalizadas. Grandes pools que utilizam imagens personalizadas de VM podem demorar mais tempo a alocar, e podem ocorrer tempos limite de redimensionamento. Para recomendações sobre limites e configuração, consulte Criar um pool com a Azure Compute Gallery.

Falhas automáticas de escalabilidade

Podes definir o Azure Batch para escalar automaticamente o número de nós num pool, e defines os parâmetros para a fórmula automática de escalonamento do pool. O serviço Batch utiliza então a fórmula para avaliar periodicamente o número de nós no pool e definir novos números-alvo. Para mais informações, consulte Criar uma fórmula automática para escalar nós de computação num pool Batch.

Os seguintes problemas podem ocorrer ao usar escalabilidade automática:

• A avaliação automática de escalabilidade falha.
• A operação de redimensionamento resultante falha e expira o tempo.
• Um problema com a fórmula de escalonamento automático leva a valores de destino dos nós incorretos. O redimensionamento pode funcionar ou ser interrompido por tempo esgotado.

Para obter informações sobre a última avaliação automática de escala, utilize a propriedade Avaliar Pool Auto Scale . Esta propriedade reporta o tempo de avaliação, os valores e o resultado, e quaisquer erros de desempenho.

O evento completo de redimensionamento do grupo recolhe informações sobre todas as avaliações.

Falhas de eliminação de pools

Para eliminar um pool que contém nós, o Batch apaga primeiro os nós, o que pode demorar vários minutos a completar. O batch apaga o próprio objeto do pool.

Batch define o poolState para deleting durante o processo de eliminação. A aplicação que chama pode detetar se a eliminação do pool está a demorar demasiado tempo usando as state e stateTransitionTime propriedades.

Se a eliminação do pool demorar mais do que o esperado, o Batch tenta periodicamente até que o pool seja eliminado com sucesso. Em alguns casos, o atraso deve-se a uma interrupção do serviço Azure ou outros problemas temporários. Outros fatores que impedem a eliminação bem-sucedida do pool podem exigir que tome medidas para corrigir o problema. Estes fatores podem incluir as seguintes questões:

• Os bloqueios de recursos podem ser colocados em recursos criados pelo Batch, ou em recursos de rede que o Batch utiliza.

• Os recursos que criaste podem depender de um recurso criado por lote. Por exemplo, se criar um pool numa rede virtual, o Batch cria um NSG, um endereço IP público e um balanceador de carga. Se estiveres a usar estes recursos fora do pool, não podes apagar o pool.

• O Microsoft.Batch fornecedor de recursos pode não estar registado na subscrição que contém o seu pool.

• Para contas Batch em modo de subscrição de utilizador, Microsoft Azure Batch pode já não ter o papel de Contribuidor ou Proprietário na subscrição que contém o seu pool. Para mais informações, consulte Permitir que o Batch aceda à subscrição.

Erros de nó

Mesmo quando o Batch aloca com sucesso nós num pool, vários problemas podem fazer com que alguns nós fiquem pouco saudáveis e incapazes de executar tarefas. Estes nós continuam a acarretar encargos, por isso é importante identificar problemas de forma a evitar pagar por nós que não pode usar. Conhecer erros comuns de nós e o estado atual do trabalho é útil para a resolução de problemas.

Falhas iniciais de tarefas

Podes especificar uma tarefa inicial opcional para um pool. Como em qualquer tarefa, a tarefa inicial utiliza uma linha de comandos e pode descarregar ficheiros de recursos a partir do armazenamento. A tarefa de início é executada para cada nó quando este começa. A propriedade waitForSuccess especifica se o Batch espera até que a tarefa de início seja concluída com sucesso antes de agendar qualquer tarefa para um nó. Se configurar o nó para esperar que a tarefa de início seja concluída com sucesso, mas a tarefa de início falhar, o nó não é utilizável mas ainda assim sofre cargas.

Pode detetar falhas ao iniciar tarefas usando as propriedades taskExecutionResult e taskFailureInformation do nó de nível superior startTaskInformation.

Uma tarefa de início falhada também faz com que o Batch defina o computeNodeState para starttaskfailed, se waitForSuccess for definido para true.

Como em qualquer tarefa, podem existir muitas causas para a falha de uma tarefa inicial. Para resolver problemas, verifique o stdout, stderr e quaisquer outros ficheiros de log específicos da tarefa.

As tarefas de início devem ser reentrantes, porque a tarefa de início pode ser executada várias vezes no mesmo nó, por exemplo, quando o nó é reimaginado ou reiniciado. Em casos raros, quando uma tarefa de início é executada após um evento causar o reinício do nó, um dos sistemas operativos (SO) ou um dos discos efémeros é reconfigurado, enquanto o outro não. Como as tarefas de arranque em lote e todas as tarefas em lote correm a partir do disco efémero, esta situação normalmente não é um problema. No entanto, nos casos em que a tarefa inicial instala uma aplicação no disco do sistema operativo e mantém outros dados no disco efémero, podem surgir problemas de sincronização. Proteja a sua aplicação em conformidade se usar ambos os discos.

Falha no download do pacote de aplicação

Pode especificar um ou mais pacotes de aplicação para um pool. O batch descarrega os ficheiros de pacote especificados para cada nó e descomprime os ficheiros depois do início do nó, mas antes de agendar tarefas. É comum usar um comando start task com pacotes de aplicação, por exemplo, para copiar ficheiros para outro local ou para executar setup.

Se um pacote de aplicação falhar em descarregar e descomprimir, a propriedade computeNodeError reporta a falha e define o estado do nó para unusable.

Falha no download do contentor

Pode especificar uma ou mais referências de contentores num pool. O batch descarrega os contentores especificados para cada nó. Se o contentor falhar ao descarregar, a propriedade computeNodeError reporta a falha e define o estado do nó para unusable.

Atualizações do sistema operativo Node

Para pools Windows, enableAutomaticUpdates está definido como true por defeito. Embora seja recomendado permitir atualizações automáticas, as atualizações podem interromper o progresso das tarefas, especialmente se estas forem de longa duração. Podes definir este valor para false caso precises, para garantir que uma atualização do sistema operativo não acontece inesperadamente.

Nó em estado inutilizável

O batch pode definir o computeNodeState para unusable por várias razões. Não podes agendar tarefas para um unusable nó, mas o nó continua a sofrer cargas.

Se o Batch conseguir determinar a causa, a propriedade computeNodeError reporta-a. Se um nó estiver num unusable estado, mas não tiver computeNodeError, isso significa que o Batch não é capaz de comunicar com a VM. Neste caso, o Batch tenta sempre recuperar a VM. No entanto, o Batch não tenta automaticamente recuperar VMs que falharam em instalar pacotes de aplicações ou containers, mesmo que o seu estado seja unusable.

Outras razões para unusable os 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 na infraestrutura ou a uma atualização de baixo nível. O processo em lote recupera o nó.
• Uma imagem de VM foi implementada em hardware que não a suporta.
• As VMs estão numa rede virtual Azure e o tráfego foi bloqueado para portas-chave.
• As VMs estão numa rede virtual, mas o tráfego de saída para o Azure Storage está bloqueado.
• As VMs estão numa rede virtual com uma configuração DNS personalizada, e o servidor DNS não consegue resolver o armazenamento Azure.

Ficheiros de registo do nó agente

O processo Batch Agent que executa em cada nó de pool fornece ficheiros de registo que podem ajudar caso precise de contactar o suporte sobre um problema com um nó de pool. Pode carregar ficheiros de registo para um nó através do portal Azure, Batch Explorer ou da API Compute Node - Upload Batch Service Logs . Depois de carregares e guardares os ficheiros de registo, podes eliminar o nó ou pool para poupar os custos de operação dos nós.

Disco de nó cheio

O batch utiliza o disco temporário numa VM de pool de nós para armazenar ficheiros como os seguintes ficheiros de trabalho, ficheiros de tarefas e ficheiros partilhados:

• Ficheiros de pacotes de aplicação
• Ficheiros de recursos da tarefa
• Ficheiros específicos da aplicação descarregados para uma das pastas Batch
• Stdout e stderr ficheiros para a execução de cada aplicação da tarefa
• Ficheiros de saída específicos de aplicação

Ficheiros como pacotes de aplicação ou ficheiros de recurso de início de tarefa, escrevem-se apenas uma vez, quando o Batch cria o nó do pool. Mesmo que só escrevam uma vez, se estes ficheiros forem demasiado grandes podem preencher o disco temporário.

Outros ficheiros, como stdout e stderr, são escritos para cada tarefa que um nó executa. Se um grande número de tarefas for executado no mesmo nó, ou se os ficheiros forem demasiado grandes, podem preencher o disco temporário.

O nó também precisa de uma pequena quantidade de espaço no disco do sistema operativo para criar utilizadores após o arranque.

O tamanho do disco temporário depende do tamanho da VM. Uma consideração ao escolher o tamanho de uma VM é garantir que o disco temporário tem espaço suficiente para a carga de trabalho planeada.

Quando adicionas um pool no portal Azure, podes mostrar a lista completa dos tamanhos das VMs, incluindo uma coluna de tamanho do disco de Recursos . Os artigos que descrevem tamanhos de VMs têm tabelas com uma coluna de Armazenamento Temporário . Para mais informações, consulte Tamanhos de máquinas virtuais otimizados para computação. Para uma tabela de tamanhos de exemplo, veja Fsv2-series.

Pode especificar um tempo de retenção para ficheiros escritos por cada tarefa. O tempo de retenção determina quanto tempo guardar os ficheiros da tarefa antes de os limpar automaticamente. Pode reduzir o tempo de retenção para reduzir os requisitos de armazenamento.

Se o disco temporário ou do sistema operativo ficar sem espaço, ou estiver perto de ficar sem espaço, o nó passa para o unusablecomputeNoteState, e o erro do nó indica que o disco está cheio.

Se você não tiver certeza do que está a ocupar espaço no nó, tente ligar-se remotamente ao nó e investigar manualmente. Também pode usar a API File - List From Compute Node para examinar ficheiros, por exemplo saídas de tarefas, em pastas geridas por lote. Esta API lista apenas ficheiros nos diretórios geridos por lote. Se as tuas tarefas criaram ficheiros noutro local, esta API não os mostra.

Depois de garantir que recupera todos os dados necessários do nó ou os carrega para um armazenamento durável, pode apagar os dados conforme necessário para libertar espaço.

Pode eliminar trabalhos antigos já concluídos ou tarefas cujos dados ainda estejam presentes nos nós. Procure na recentTasks coleção em taskInformation do nó, ou utilize a API Ficheiro - Lista do Nó de Computação. Eliminar um trabalho elimina todas as tarefas do trabalho. Eliminar as tarefas no trabalho desencadeia a eliminação dos dados nos diretórios de tarefas dos nós e liberta espaço. Quando libertar espaço suficiente, reinicie o nó. O nó deve sair do estado unusable e entrar novamente no idle.

Para recuperar um nó inutilizável nos pools VirtualMachineConfiguration , pode remover o nó do pool usando a API Pool - Remove Nodes . Depois podes aumentar o pool novamente para substituir o nó defeituoso por um novo.

Próximos passos

• Aprenda sobre verificação de erros de trabalhos e tarefas.
• Aprenda sobre as melhores práticas para trabalhar com Azure Batch.