Share via

Lote do Azure - Detalhes de pool e nó

  • Artigo

Cuidado

Este artigo faz referência ao CentOS, uma distribuição do Linux que está se aproximando do status de EOL (fim da vida útil). Considere seu uso e planejamento adequadamente. Para obter mais informações, veja a orientação CentOS End Of Life.

Algumas operações de criação e gerenciamento de pool do Lote do Azure ocorrem imediatamente. A detecção de falhas para essas operações é simples, pois os erros geralmente retornam imediatamente da API, da linha de comando ou da 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 detectar e evitar falhas que podem ocorrer nas operações em segundo plano que para pools e nós.

Verifique se definiu seus aplicativos para implementar a verificação de erro abrangente, especialmente para operações assíncronas. Uma boa verificação de erros pode ajudá-lo a identificar e diagnosticar imediatamente os problemas.

Erros do pool

Erros de pool podem estar relacionados ao tempo limite de redimensionamento ou falha, falha de dimensionamento automático ou falha de exclusão de pool.

Redimensionar tempo limite ou falha

Quando você cria um novo pool ou redimensiona um existente, o número de destino de nós é especificado. 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 – Adicionar ou Pool – Redimensionar. Se o Lote não puder alocar o número de nós de destino durante o período de tempo limite do redimensionamento, o pool entrará em um estado estável e reportará erros de redimensionamento.

A propriedade ResizeError lista os erros que ocorreram da avaliação mais recente.

As causas comuns dos erros de redimensionamento incluem:

  • Redimensionar o tempo limite muito curto. Normalmente, o tempo limite padrão de 15 minutos é longo o suficiente para alocar ou remover nós de 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 VM (máquina virtual) personalizada, poderá definir o tempo limite de redimensionamento como 30 minutos.

  • Cota de núcleo insuficiente. Uma conta do Lote é limitada ao número de núcleos que pode alocar em todos os pools. Ela para de alocar nós quando atinge essa cota. Você pode aumentar a cota de núcleos para que esse lote possa alocar mais nós. Para saber mais, confira Limites e cotas do serviço de Lote.

  • IPs de sub-rede insuficientes quando um pool está em uma rede virtual. Uma sub-rede de rede virtual deve ter suficiente endereços IP para alocar 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 Lote do Azure em uma rede virtual.

  • Recursos insuficientes quando um pool está em uma rede virtual. Quando você cria um pool em uma rede virtual, é possível criar recursos como grupos de segurança de rede, IPs públicos e grupo de segurança de rede na mesma assinatura que a conta do lote. Verifique se as cotas de assinatura para esses recursos são suficientes.

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

Falhas de dimensionamento automático

Você pode configurar o Lote do Azure para dimensionar automaticamente o número de nós em um pool e também pode definir os parâmetros da fórmula de dimensionamento automático para o pool. O serviço de lote usa a fórmula para avaliar o número de nós no pool periodicamente e definir novos números de destino. Para mais informações, confirar Criar uma fórmula de dimensionamento automático de nós de computação em um pool do Lote.

Os seguintes problemas podem ocorrer ao usar o dimensionamento automático:

  • A fórmula de dimensionamento automático falhar.
  • A operação de redimensionamento resultante pode falhar e atingir o tempo limite.
  • Um problema com a fórmula de dimensionamento automático pode resultar em valores de destino de nó incorretos. O redimensionamento pode funcionar ou atingir o tempo limite.

Para obter as informações sobre a última avaliação do dimensionamento automático, use a propriedade autoScaleRun. Essa propriedade informa o tempo de avaliação, os valores, o resultado e quaisquer erros de desempenho.

Informações sobre todas as avaliações são capturadas automaticamente por um evento completo de redimensionamento de pool.

Falhas na exclusão de pool

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

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

Se a exclusãi di pool estiver demorando mais do que o esperado, o Lote tenta novamente periodicamente até que o pool seja excluído com êxito. Em alguns casos, o atraso é devido 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 Lote 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á excluir o pool.

  • O provedor de recursos Microsoft.Batch pode ter o registro cancelado da assinatura que contém o pool.

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

Erros dos nós

Mesmo quando o Lote aloca com êxito os nós em um pool, diversos problemas podem fazer com que os nós sejam não íntegros e não consigam executar tarefas. Esses nós ainda incorrem em encargos, portanto, é importante detectar problemas para evitar o pagamento de nós que você não pode usar. Sabre sobre os erros de nós comuns e saber o estado do trabalho atual é útil ao solucionar problemas.

Falhas ao iniciar tarefa

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

Falhas na tarefa inicial podem ser detectadas usando as propriedades taskExecutionResult e taskFailureInformation da propriedade de nó startTaskInformation de nível superior.

Uma falha ao iniciar a tarefa também faz com que o lote defina o nó computeNodeState em starttaskfailed se waitForSuccess estiver definido como true.

Assim como acontece com qualquer tarefa, pode haver muitas causas para uma falha na tarefa inicial. Para solucionar problemas, stdout, stderr e quaisquer arquivos de log de tarefas específicas adicionais devem ser verificados.

As tarefas iniciais devem ser de reinserção, porque a tarefa inicial pode ser executada várias vezes no mesmo nó; por exemplo quando o nó é reinicializado ou tem a imagem refeita. Em casos raros, quando uma tarefa de início é executada após um evento causar uma reinicialização de nó, um sistema operacional (SO) ou disco efêmero refazerá a imagem enquanto o outro não. Como as tarefas de início do Lote e todas as tarefas do Lote são executadas no disco efêmero, essa situação geralmente não é um problema. No entanto, nos casos em que a tarefa inicial 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 adequadamente se você usa os dois discos.

Falha no download do pacote de aplicativos

Você pode especificar um ou mais pacotes de aplicativos de um pool. O Lote baixa os arquivos de pacote especificados para cada nó e descompacta os arquivos depois que o nó inicia mas antes que as tarefas sejam agendadas. É comum usar uma linha de comando de tarefa inicial, com os pacotes de aplicativos, para copiar arquivos para um local diferente ou executar a configuração, por exemplo.

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

Falha ao baixar 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 não for baixado, 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, elas podem interromper o andamento da tarefa, especialmente se as tarefas forem de execução prolongada. 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

O Lote pode definir o computeNodeState pode ser definido como unusable por muitos motivos. Você não pode agendar tarefas para um nó unusable, mas o nó ainda incorre em encargos.

Se o lote poder determinar a causa, a propriedade do nó computeNodeError irá reportá-lo. Se um nó estiver em um estado unusable, mas não tiver computeNodeError, isso significa que o Lote não poderá se comunicar com a VM. Nesse caso, o Lote sempre tenta recuperar a VM. No entanto, o Lote não tentará recuperar automaticamente as VMs que falharem ao instalar contêineres ou pacotes de aplicativos mesmo se o estado for unusable.

Outros motivos para nós unusable podem incluir as seguintes causas:

  • A imagem de VM personalizada é inválida. Por exemplo, a imagem não está preparada corretamente.
  • Uma VM é movida devido a uma falha de infraestrutura ou de uma atualização de nível baixo. O lote recupera o nó.
  • Uma imagem de VM foi implantada em hardware que não dá suporte a ela. Por exemplo, uma imagem do CentOS HPC em uma VM Standard_D1_v2.
  • As VMs estão em uma rede virtual do Azure e o tráfego para as principais portas foi bloqueado.
  • 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 consegue resolver o armazenamento do Azure.

Arquivos de log do agente de nó

O processo do agente do Lote que é executado em cada nó do pool fornece arquivos de log que podem ser úteis se você precisar contatar o suporte sobre um problema de nó do pool. Você pode carregar arquivos de log para um nó por meio do portal do Azure, Explorer do Lote ou da API Nó de Computação – Carregar Logs de Serviço do Lote. Depois de carregar e salvar os arquivos de log, você pode excluir o nó ou o pool para economizar o custo da execução dos nós.

Disco do nó cheio

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

  • Arquivos do pacote de aplicativos
  • Arquivos de recursos de tarefas
  • Arquivos específicos do aplicativo baixados em uma das pastas do Lote
  • Arquivos stdout e stderr para cada execução de aplicativo de tarefas
  • Arquivos de saída específicos do aplicativo

Arquivos como pacotes de aplicativos ou arquivos de recurso de tarefa de início são gravados apenas uma vez quando o Lote cria o nó do pool. Mesmo que eles sejam gravados apenas uma vez, se esses arquivos forem muito grandes, poderão preencher a unidade temporária.

Outros arquivos, como stdout e stderr, são gravados para cada tarefa que um nó executa. Se um grande número de tarefas for executado no mesmo nó ou 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 após o início.

O tamanho da unidade temporária depende do tamanho da VM. Ao escolher um tamanho de VM, considere 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 Compute optimized virtual machine sizes (Tamanhos de máquinas virtuais com computação otimizada). Para obter uma tabela de tamanho de exemplo, consulte Fsv2-series.

Você pode especificar um tempo de retenção para arquivos gravados por cada tarefa. O tempo de retenção determina quanto tempo manter os arquivos de tarefa 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 sistema operacional ficar sem espaço ou estiver perto de ficar sem espaço, o nó passará para unusablecomputeNoteState e o erro do nó indicará que o disco está cheio.

Se você não tiver certeza do que está ocupando espaço no nó, tente se conectar ao nó remotamente e investigue manualmente. Você também pode usar a API Arquivo – Listar do Nó de Computação para examinar arquivos, por exemplo, saídas de tarefa, em pastas gerenciadas do Lote. Esta API lista apenas arquivos nos diretórios gerenciados em Lote. Se suas tarefas criarem arquivos em outro lugar, essa API não os mostrará.

Depois de recuperar os dados necessários do nó ou carregá-los em um repositório durável, você poderá excluir os dados conforme necessário para liberar espaço.

Você pode excluir tarefas ou trabalhos cujos dados de tarefa ainda estejam nos nós. Examine a coleção recentTasks na tarefaInformation no nó ou use a API Arquivo – Listar do Nó de Computação. Excluir um trabalho exclui todas as tarefas no trabalho. Excluir as tarefas no trabalho dispara a exclusão de dados nos diretórios de tarefa nos nós e libera espaço. Depois de liberar espaço suficiente, reinicie o nó. O nó deve sair do estado unusable e entrar em idle novamente.

Para recuperar um nó inutilizável em pools VirtualMachineConfiguration, você pode remover um nó do pool usando a API Pool - Remover Nós. Em seguida, você pode aumentar novamente o pool para substituir o nó inadequado por um novo. Para pools CloudServiceConfiguration, você pode refazer a imagem do nó usando a API Nó de Computação – Refazer imagem para limpar todo o disco. A ação de refazer imagem não tem suporte no momento para pools de VirtualMachineConfiguration.

Próximas etapas