Confiabilidade no Lote do Azure

Lote do Azure executa trabalhos em lotes paralelos e de computação de alto desempenho (HPC) em larga escala no Azure. O Batch cria e gerencia pools de nós de computação, instala os aplicativos que você deseja executar e agenda trabalhos a serem executados nos nós.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar suporte à resiliência e recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar Lote do Azure resiliente a falhas transitórias, falhas de nó de computação, falhas de zona de disponibilidade, falhas em toda a região e manutenção do serviço. Ele também descreve as recomendações de implantação de produção, a arquitetura de confiabilidade do Batch, o backup e a restauração e as principais informações sobre o SLA (contrato de nível de serviço) do Lote do Azure.

Recomendações de implantação de produção

Para cargas de trabalho de produção, siga as práticas recomendadas para Lote do Azure, incluindo estas recomendações de confiabilidade:

Visão geral da arquitetura de confiabilidade

Esta seção descreve alguns dos aspectos importantes de como o serviço funciona que são mais relevantes do ponto de vista da confiabilidade. A seção apresenta a arquitetura lógica, que inclui alguns dos recursos e recursos que você implanta e usa. Também discute a arquitetura física, que fornece detalhes sobre como o serviço funciona nos bastidores.

Arquitetura lógica

Lote do Azure usa vários tipos de recursos para executar cargas de trabalho em lotes. A configuração desses recursos determina como sua carga de trabalho responde a falhas.

Todos os recursos e processamento do Batch são associados a uma conta do Batch. Uma solução Batch usa os seguintes componentes lógicos:

• Conta do Batch: Um recurso regional com o qual pools, trabalhos, tarefas e outros recursos do Batch estão associados. Você cria a conta e seleciona sua região, modo de alocação de pool e configurações de autenticação.

• Pool: Uma coleção de nós de computação nos quais as tarefas são executadas. A configuração de um pool define sua imagem e tamanho da VM, contagem de nós de destino, comportamento de dimensionamento, rede e posicionamento de zona. Você configura cada pool para fornecer a capacidade, o posicionamento e o ambiente operacional necessários para sua carga de trabalho. A contagem de nós de destino é a capacidade solicitada, mas o número de nós alocados pode ser menor devido a limites de cota, restrições de capacidade ou falhas de alocação.

• Jobs e tarefas: Um job gerencia uma coleção de tarefas e é associado a um pool. Uma tarefa executa um aplicativo ou script em um nó de computação. Você define jobs, tarefas, restrições, dependências, comportamento de repetição e o pool no qual cada job é executado.

• Conta de armazenamento associada: Uma conta do Armazenamento do Azure que você vincula opcionalmente a uma conta do Azure Batch. A maioria das soluções do Batch usa uma conta de armazenamento associada para arquivos de aplicativo, arquivos de recurso de tarefa, dados de entrada e dados de saída.

  Depois de vincular uma conta de armazenamento a uma conta do Batch, o Batch se referirá a ela como a conta de autostorage. Uma conta de autostorage é necessária para pacotes de aplicativos e também pode armazenar arquivos de recurso de tarefa.

  A confiabilidade de uma solução Batch depende de seus recursos de armazenamento. Você é responsável por selecionar uma configuração de redundância de armazenamento que atenda aos requisitos de recuperação ao criar a conta de armazenamento. Mova a saída da tarefa e outros dados duráveis de nós de computação para o armazenamento. Para obter informações sobre Armazenamento do Azure opções de confiabilidade, consulte Confiabilidade no Armazenamento de Blobs do Azure.

Para obter mais informações, consulte fluxo de trabalho e recursos do serviço Batch e contas do Batch e contas do Armazenamento do Azure.

Arquitetura física

Lote do Azure tem um plano de controle regional que processa operações de gerenciamento em contas do Batch e outros recursos do Batch, como pools, jobs e tarefas. Ele é separado dos nós de computação que executam tarefas.

Lote do Azure pools usam Máquinas Virtuais do Azure e Conjuntos de Dimensionamento de Máquinas Virtuais. Um nó de computação é uma VM que processa parte de uma carga de trabalho do Batch. Cada nó pertence a um pool e executa tarefas que o serviço Batch atribui a ele. O agente de nó do Batch é executado em cada nó e fornece a interface de comando e controle entre o nó e o serviço Batch. Os nós de computação e o armazenamento local são efêmeros. Quando um nó sai de um pool, as alterações no sistema operacional e nos arquivos são perdidas.

O modo de alocação do pool da conta do Batch determina onde o Batch cria os recursos relacionados à computação e à VM:

• Modo de alocação do pool de serviços em lote: O Batch aloca os recursos em assinaturas do Azure gerenciadas pelo serviço Batch.
• Modo de alocação do pool de assinatura do usuário: O Batch cria os recursos diretamente na assinatura que contém a conta do Batch.

As responsabilidades pela arquitetura física são divididas da seguinte maneira:

• Microsoft: Microsoft opera o plano de controle regional do Batch e a infraestrutura de serviço. Batch provisiona nós de computação de acordo com a configuração do pool e a capacidade disponível, agenda tarefas, monitora a integridade do nó e tenta recuperar nós após falhas de infraestrutura. O Batch pode recolocar tarefas interrompidas na fila para execução em outro nó disponível.

• Você: Selecione a imagem e o tamanho da VM, os tipos de nó, a contagem de nós de destino, a configuração de dimensionamento, a rede e o posicionamento da zona de disponibilidade.

  Você também é responsável por manter capacidade suficiente para tolerar falhas de nó, monitorar nós e estados de tarefa, manter o sistema operacional convidado e o agente de nó atualizados, projetar tarefas para tolerar a reexecução e mover dados duráveis para fora dos nós de computação.

A recuperação de nó de lote não garante que uma carga de trabalho continue sem interrupção. Para obter mais informações, consulte Resiliência a falhas de nós de computação.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes nos componentes. Elas ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. Falhas transitórias se corrigem após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente repetindo solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas do Azure quando eles se comunicam com qualquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para resolver falhas transitórias.

Em uma solução do Batch, falhas transitórias podem afetar os aplicativos e scripts executados como tarefas e quaisquer aplicativos que chamem APIs do Batch para gerenciar recursos do Batch. Batch fornece mecanismos de nova tentativa no nível da tarefa. Você é responsável por configurar restrições de tarefa, tornar as tarefas idempotentes (seguras para serem executadas mais de uma vez) e configurar o comportamento de repetição para chamadas para o serviço Batch e outras dependências.

Tentativas de tarefa e limites de tempo

Configure maxTaskRetryCount para controlar quantas vezes o Batch tenta novamente uma tarefa depois que seu processo é encerrado com um código de saída diferente de zero:

• O valor padrão, 0, significa que o Batch não tenta novamente a tarefa após um código de saída diferente de zero.
• Um inteiro positivo define um número máximo de novas tentativas após a tentativa inicial.
• Um valor de -1 permite novas tentativas ilimitadas. Esse valor não é recomendado porque uma falha persistente pode fazer com que a tarefa seja executada indefinidamente.

Crie cada tarefa para ser idempotente para que as novas tentativas não causem corrupção de dados ou saída duplicada. Para tarefas de execução prolongada, use checkpointing para que uma nova tentativa possa continuar com o progresso salvo. Para obter mais informações, consulte Design para novas tentativas e reexecução.

Defina a restrição de tempo limite maxWallClockTime em uma tarefa ou job para encerrar o trabalho que não progride dentro de um período aceitável. Um limite de tempo também limita o efeito de falhas repetidas. Selecione contagens de repetição e limites de tempo que se alinham aos objetivos de recuperação da carga de trabalho.

Falhas transitórias em dependências de tarefa

Aplicativos e scripts executados como tarefas em lote geralmente chamam outros componentes, como Armazenamento do Azure, bancos de dados ou APIs. O Lote não gerencia as solicitações individuais que o código da tarefa envia para essas dependências. Implemente o tratamento de falhas transitórias no código da tarefa ou use recursos de repetição fornecidos pelo SDK da dependência. Siga as diretrizes de cada dependência para identificar erros passíveis de nova tentativa, selecionar as configurações de backoff e tempo limite apropriadas e respeitar as instruções de nova tentativa, como o cabeçalho Retry-After. Execute novamente somente as operações que são seguras de repetir.

Se uma falha de dependência fizer com que o processo da tarefa saia com um código de saída diferente de zero, o Batch poderá repetir toda a tarefa de acordo com maxTaskRetryCount. No entanto, o Batch não tenta novamente uma solicitação de dependência individual em uma tarefa em execução.

Novas tentativas de solicitação da API em lote

Seus aplicativos em execução fora do serviço podem chamar APIs do Batch para criar e gerenciar pools, trabalhos, tarefas, nós de computação e outros recursos do Batch. Configure esses clientes com políticas de repetição que abrangem pelo menos cinco minutos para lidar com falhas transitórias de rede ou do serviço Batch.

Use o suporte de repetição do SDK integrado quando estiver disponível. Por exemplo, a biblioteca de cliente Azure.Compute.Batch para .NET expõe o comportamento de repetição por meio de Azure.Core opções de repetição.

Se você interagir diretamente com as APIs do serviço Batch do seu código, aguarde vários segundos antes de tentar novamente, use backoff exponencial com randomização (jitter) para evitar solicitações de nova tentativa sincronizadas e respeite o cabeçalho Retry-After retornado com respostas de limitação de taxa, como 429 Too Many Requests e 503 Service Unavailable.

Um tempo limite de solicitação não significa necessariamente que o Batch falhou ao processar a solicitação. Após um tempo limite, repita a operação quando for seguro fazer isso ou recupere o estado do recurso para determinar se a operação original foi bem-sucedida. Para obter mais informações, consulte Tratamento e detecção de erros em Lote do Azure.

Resiliência a falhas de nó de computação

Um nó de computação pode ficar indisponível devido a uma falha de infraestrutura, problema de sistema operacional ou problema de configuração. Batch tenta recuperar nós afetados por falhas de infraestrutura, mas não consegue se recuperar automaticamente de todas as falhas relacionadas à configuração. Por exemplo, se um pacote de aplicativo ou contêiner falhar na instalação, você deverá corrigir o problema subjacente e talvez precise remover e substituir o nó afetado.

Se uma falha de nó interromper uma tarefa, o Batch poderá repetir a tarefa no mesmo nó, se possível, até um limite interno. Se a tarefa não puder continuar nesse nó, o Batch poderá reenfileirá-la para execução em outro nó disponível. Essas tentativas de recuperação controladas pelo serviço são independentes de maxTaskRetryCount e podem ocorrer mesmo quando seu valor é 0.

processo de recuperação de nó gerenciado por Microsoft

Microsoft gerencia a recuperação de nó controlada pelo serviço e o reenfileiramento de tarefas. Se o serviço Batch parar de receber heartbeats de um nó por tempo suficiente para disparar a recuperação, o Batch poderá executar as seguintes ações:

1. Isole o nó: O Batch trata o nó como não íntegro, define seu estado como unusable e interrompe o agendamento de novas tarefas nele.
2. Identificar tarefas afetadas: O Batch identifica as tarefas que estavam em execução no nó como candidatas para reagendamento.
3. Reenfileirar tarefas qualificadas: Se uma tarefa afetada ainda estiver persistida no estado running, o Batch poderá redefini-la para active, para que o agendador possa atribuí-la a outro nó. O Lote não redefine ou executa novamente uma tarefa já persistida no estado completed.
4. Recupere o nó: Batch tenta restaurar o nó para um estado íntegro ou substituir a VM subjacente.

A recuperação não é instantânea. Uma tarefa pode permanecer no estado running enquanto o Batch detecta a falha do nó e tenta reagendar a tarefa. Se nenhum outro nó de computação estiver disponível, a tarefa poderá permanecer nesse estado até que o Batch possa reagendá-la. Para obter mais informações, consulte limitações conhecidas para tarefas em Batch.

Se o nó original retomar sinais de atividade saudáveis antes do início da substituição, o Batch poderá devolvê-lo a um estado estável. Se a substituição já tiver sido iniciada, o Batch poderá remover a VM original e provisionar uma substituição.

Suas responsabilidades

A recuperação orientada por serviço não garante a execução ininterrupta da tarefa nem capacidade restante suficiente. Você é responsável pelas seguintes ações:

• Manter capacidade suficiente: Se a carga de trabalho precisar continuar enquanto um nó estiver indisponível, provisione nós suficientes para que os nós restantes executem tarefas reagendadas. Sem outro nó utilizável, as tarefas interrompidas devem aguardar.

• Monitorar a capacidade utilizável: Acompanhe as contagens de nós agregados e os estados para que você possa detectar quando um pool não tiver mais nós utilizáveis suficientes para sua carga de trabalho. Estados como unusable, startTaskFailed, unknowne preempted indicam capacidade reduzida. Para obter mais informações, consulte Monitorar soluções do Batch por meio da contagem de tarefas e nós por estado.

• Investigar nós de problema: Se as tarefas falharem repetidamente, forem requeadas ou permanecerem no estado running depois que o nó atribuído se tornar inutilizável ou sair do pool, use metadados de tarefa para determinar se os problemas estão associados a um nó específico.

  Antes de remover um nó com problema, carregue os logs do agente de nó do Batch e preserve os logs de tarefas relevantes porque a remoção do nó exclui seus arquivos locais. Os logs do agente do nó podem ajudar o Suporte da Microsoft a diagnosticar problemas do serviço Batch ou do nó, enquanto os logs de tarefas, como stdout e stderr, podem ajudá-lo a identificar problemas de configuração e aplicativo. Para obter mais informações, consulte arquivos de log do agente do Node.

• Proteger o progresso e os dados da tarefa: Projetar tarefas para tolerar interrupção e reexecução. Mova pontos de verificação, saída e outros dados duráveis de nós de computação porque seu armazenamento local é efêmero.

Para obter mais informações, consulte erros de pool e de nó no Lote do Azure e tratamento e detecção de erros no Lote do Azure.

Resiliência a falhas de zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em uma região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

Batch oferece suporte a zonas de disponibilidade de duas maneiras principais:

• Plano de controle: O plano de controle do Batch é resiliente a zonas em muitas regiões. Nessas regiões, as operações de gerenciamento em contas do Batch e em outros recursos do Batch podem continuar durante uma falha de zona. Microsoft não publica quais regiões fornecem essa resiliência do plano de controle.

• Pools: Você pode configurar um pool do Batch para usar o posicionamento da zona de disponibilidade. Se uma zona ficar indisponível, os nós de computação em zonas íntegras permanecerão disponíveis para agendamento de tarefas.

  Para posicionamento de nó de computação, esse modelo de suporte é semelhante à redundância de zona em outros serviços Azure porque um único pool pode conter nós de computação em várias zonas de disponibilidade. No entanto, o Batch distribui nós entre zonas na medida do possível. Ele tenta usar todas as zonas na região, mas não garante o posicionamento em todas as zonas ou em uma distribuição uniforme. Você não pode selecionar zonas específicas ou controlar o número de nós colocados em cada zona.

O diagrama a seguir mostra um exemplo de conta do Batch. A conta tem um único pool com seus nós distribuídos em três zonas de disponibilidade:

Você é responsável por tornar outros recursos dependentes, como contas de armazenamento, resilientes à zona. Examine os guias de confiabilidade de cada serviço. Para obter mais informações, consulte os guias de confiabilidade para serviços de Azure.

Requirements

• Suporte à região: Crie o pool em uma região de Azure que dê suporte a zonas de disponibilidade.

• Disponibilidade de SKU de VM: A SKU de VM selecionada deve estar disponível em mais de uma zona na região. Use a API de Lista de SKUs de Recursos para verificar o campo locationInfo da SKU da VM.

• Acesso à assinatura: Para um modo de alocação de pool de assinatura de usuário, a assinatura não deve ter uma restrição de oferta de zona para a SKU de VM selecionada. Verifique ResourceSkuRestrictions na resposta da API de Lista de SKUs de Recursos. Se houver uma restrição, envie uma solicitação de suporte para solicitar sua remoção.

• Comunicação entre nós: Um pool não pode usar uma política de posicionamento de zona de disponibilidade quando a comunicação entre nós está habilitada com uma SKU de VM habilitada para InfiniBand.

Distribuição de instâncias entre zonas

Quando você habilita o posicionamento da zona de disponibilidade, o Batch tenta alocar nós de computação em todas as zonas de disponibilidade na região selecionada. Essa alocação é executada na medida do possível. Batch controla a distribuição, e o número de nós em cada zona pode não ser igual.

Cost

O Batch não adiciona um encargo para habilitar o posicionamento da zona de disponibilidade. Você é cobrado pela computação, armazenamento, rede e outros recursos de Azure usados pela carga de trabalho. Se você provisionar nós extras para tolerar a perda de uma zona, esses nós estarão sujeitos às cobranças normais. Para obter mais informações, consulte preços do Lote do Azure.

Configurar o suporte à zona de disponibilidade

• Crie um novo pool com o posicionamento da zona de disponibilidade: Para criar um pool com o posicionamento da zona de disponibilidade habilitado, consulte Criar um pool do Batch entre zonas de disponibilidade.

• Alterar o posicionamento da zona de disponibilidade em um pool existente: Você deve selecionar o posicionamento da zona de disponibilidade ao criar o pool. Você não pode alterar um pool existente para usar zonas de disponibilidade.

  Você pode criar um pool de substituição e atualizar cada uma de suas tarefas para usá-lo seguindo as etapas abaixo:

  1. Desabilite o job: Use a operação Disable Job e selecione como o Batch lida com tarefas em execução ao enviar a solicitação:

     • Aguarde: O lote para de iniciar novas tarefas e permite que as tarefas em execução sejam concluídas no pool existente. O trabalho permanece no estado disabling em execução até que as tarefas em execução sejam concluídas.
     • Reenfileirar: O lote interrompe a execução de tarefas e as retorna para a fila. As tarefas podem ser executadas novamente depois que você habilitar o job.
     • Encerrar: O Lote interrompe a execução de tarefas e as marca como concluídas com informações de falha que indicam que elas foram encerradas. As tarefas não são executadas novamente depois que você habilita o job.

     As tarefas que já estão no estado active em fila, o que significa que estão na fila, mas não em execução, permanecem na fila com todas as opções.

     Aguarde até que o trabalho chegue ao disabled estado antes de continuar. Nesse ponto, nenhuma tarefa está em execução e o Batch não agenda novas tarefas.

  2. Edite o pool do trabalho: Use a operação Atualizar Trabalho para definir o poolInfo.poolId do trabalho para o pool de substituição. O Lote só permite que essa propriedade seja alterada enquanto o trabalho estiver no disabled estado. Verifique se o pool de substituição existe e tem capacidade utilizável antes de habilitar a tarefa. Se o pool não existir, o Batch aceitará a atualização, mas ele não poderá agendar tarefas até que você crie o pool.

  3. Habilite o job: Use a operação Habilitar Job. A tarefa transita pelo estado enabling para o estado active. Em seguida, o Batch agenda tarefas enfileiradas, incluindo tarefas retornadas à fila pela opção Requeue, no pool de substituição. As tarefas que terminaram enquanto o Batch aplicava a opção Aguardar e as tarefas concluídas pela opção Encerrar não são executadas novamente.

Planejamento e gerenciamento de capacidade

O processo normal de recuperação de nó do Batch tenta substituir nós que se tornam inutilizáveis durante uma falha de zona e restaura o pool para sua contagem de nós de destino configurada. Ele não aumenta esse alvo. Para manter capacidade suficiente para que a carga de trabalho continue quando uma zona não estiver disponível, considere o superprovisionamento da capacidade do pool usando o dimensionamento automático ou manualmente:

• Se você usar o dimensionamento automático: Faça referência à $UsableNodeCount variável definida pelo serviço na fórmula de dimensionamento automático do pool para detectar quando a capacidade utilizável está abaixo da linha de base necessária para sua carga de trabalho. $UsableNodeCounté uma variável de dimensionamento automático do Lote para o pool cuja fórmula está sendo avaliada, não uma métrica de Azure Monitor. Azure Monitor publica métricas de contagem de nós do Batch no escopo da conta do Batch, e essas métricas não têm uma dimensão poolId.

• Se você gerenciar a capacidade manualmente: Use a operação List Pool Node Counts para recuperar contagens de nós dedicados e spot em cada estado para cada pool. A operação não retorna um único valor de contagem de nós utilizáveis. Avaliar estados compatíveis com tarefas, como idle e running, em relação a estados indisponíveis ou problemáticos, como unusable, unknown, offline e startTaskFailed. As contagens retornadas podem não estar atualizadas; portanto, enumere os nós de computação do pool quando você precisar de uma contagem exata.

O Batch distribui nós entre zonas com base no melhor esforço, portanto, a distribuição real pode não ser igual. Não suponha que os nós sejam distribuídos igualmente entre zonas quando você planeja a capacidade. Valide se sua carga de trabalho pode atender aos objetivos de recuperação com capacidade reduzida do pool.

Comportamento quando todas as zonas estão saudáveis

Esta seção descreve o que esperar quando um pool do Batch usa o posicionamento da zona de disponibilidade e todas as zonas estão operacionais.

• Operação entre zonas: Batch agenda tarefas em nós de computação disponíveis em todo o pool, independentemente da zona que contém cada nó.

• Replicação de dados entre zonas: Os nós de computação em lote são efêmeros e o Batch não replica arquivos de tarefa entre zonas. Você é responsável por mover dados de entrada, saída, pontos de verificação e diagnóstico que devem sobreviver à perda de nó para o armazenamento durável. Configure a redundância da conta de armazenamento para atender aos seus requisitos de disponibilidade.

Comportamento durante uma falha de zona

Esta seção descreve o que esperar quando um pool do Batch usa o posicionamento da zona de disponibilidade e uma zona de disponibilidade não está disponível.

• Detecção e resposta: Microsoft monitora o serviço Batch e a integridade do nó de computação. Durante uma falha de zona, o Batch detecta a perda de pulsação sustentada de nós afetados e inicia seu processo normal de recuperação de nó. Nodes em zonas íntegras permanecem disponíveis, e o Batch pode continuar a agendar tarefas neles.

  O Batch tenta restaurar o pool para sua contagem de nós de destino configurada por meio de seu processo de recuperação normal, mas não aumenta essa contagem de destino. Você será responsável por solicitar capacidade adicional se o recurso de destino não fornecer capacidade suficiente para a carga de trabalho.

• Notificação: A Microsoft não notifica você automaticamente quando uma zona está inoperante. No entanto, você pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas Service Health para notificar você sobre problemas.

• Tarefas ativas: As tarefas em execução em nós afetados são interrompidas. O Batch pode reagendar tarefas em nós disponíveis como parte de seu comportamento de recuperação interna. Projete tarefas para tolerar novas tentativas e reexecução, conforme descrito em Resiliência para falhas transitórias e resiliência para falhas de nó de computação.

• Perda de dados esperada: Os arquivos nos nós de computação afetados não estão disponíveis durante a interrupção e serão perdidos se os nós forem reimageados ou removidos do pool. O Batch não replica esses arquivos entre zonas. Os dados persistidos no armazenamento durável permanecem disponíveis de acordo com a configuração de redundância desse recurso de armazenamento.

• Tempo de inatividade esperado: As tarefas nos nós saudáveis continuam. Tarefas interrompidas experimentam tempo de inatividade até que o Batch possa reagendá-las para nós utilizáveis. Se nenhum nó utilizável estiver disponível, uma tarefa poderá permanecer no estado running até que o Batch possa reagendá-la. O tempo de recuperação depende da capacidade do pool disponível e da carga de trabalho na fila.

  As operações de gerenciamento em contas do Batch e em outros recursos do Batch continuarão se a conta estiver em uma região em que o plano de controle seja resiliente à zona. Em outras regiões, as operações de gerenciamento podem ficar indisponíveis até que a zona afetada se recupere.

• Redistribuição: Após a perda sustentada de heartbeat, o Batch marca os nós afetados como unusable e os envia para substituição por meio de seu processo normal de recuperação de nó. O Batch tenta restaurar o pool para sua contagem de nós de destino configurada, mas a capacidade de substituição depende da cota e da disponibilidade da VM nas zonas íntegras.

  Os jobs permanecem associados ao pool durante esse processo. O Batch continua a agendar tarefas de jobs ativos em nós utilizáveis em zonas saudáveis. Se os nós de substituição forem alocados e se tornarem utilizáveis, o Batch também poderá agendar tarefas nesses nós.

  Esse processo de recuperação não aumenta a contagem de nós de destino configurado. Se sua carga de trabalho exigir capacidade além dessa meta, aumente-a manualmente ou configure a fórmula de dimensionamento automático do pool para fazer isso.

Recuperação de zona

O Batch gerencia o processo de recuperação quando uma zona se recupera após uma falha. Batch segue o mesmo processo definido em Resiliência a falhas de nós de computação.

O Batch não garante que os nós sejam rebalanceados uniformemente entre zonas de disponibilidade após a recuperação. O posicionamento da zona permanece em regime de melhor esforço.

Testar falhas em zonas

Você não pode simular uma interrupção real da zona de disponibilidade Azure para teste. Em vez disso, use um pool de não produção para interromper tarefas representativas e tirar nós de computação suficientes do serviço para aproximar a perda de capacidade esperada. Considere usar as seguintes operações de nó com suporte:

• Reinicie os nós selecionados.
• Desabilite o agendamento de tarefas em nós selecionados.
• Remova os nós selecionados do pool.

Quando uma operação permite que você escolha como lidar com tarefas em execução, selecione a opção Requeue para que o Batch possa agendar as tarefas interrompidas nos nós restantes.

Durante o teste, verifique se o Batch reagenda tarefas interrompidas e se a reexecução não produz uma saída duplicada ou inconsistente. Confirme se os pontos de verificação e a saída permanecem disponíveis no armazenamento durável, o monitoramento detecta perda de nó e capacidade reduzida, e a carga de trabalho pode terminar com a capacidade restante.

Essas operações validam a interrupção da tarefa e o reagendamento, a idempotência, o ponto de verificação e o tratamento de saída durável. No entanto, eles não reproduzem todos os efeitos de uma falha que afeta toda a zona.

Resiliência a falhas em toda a região

Uma conta do Batch e seus pools têm como escopo uma região do Azure. Se a região apresentar uma falha, seus trabalhos e pools do Batch poderão ser afetados.

Batch não replica contas, configuração de pool, trabalhos, tarefas, pacotes de aplicativos ou dados de tarefa para outra região e não fornece failover integrado entre regiões. Você é responsável por implantar e operar uma solução Batch multirregional quando sua carga de trabalho deve tolerar uma falha em toda a região.

Soluções multirregionais personalizadas para resiliência

Para criar uma solução de várias regiões, implante pelo menos uma conta do Batch em cada região que o design de recuperação usa. As contas em lote operam de forma independente entre regiões. Você é responsável por selecionar as regiões, implantar e operar os recursos em cada região e coordenar a configuração, a replicação, o failover e o failback.

Você pode criar uma abordagem ativa-ativa que envia trabalho em várias regiões durante a operação normal ou uma abordagem ativa-passiva que mantém a implantação secundária pronta para failover. Os designs ativo-ativos podem reduzir o tempo de recuperação porque ambas as implantações processam cargas de trabalho durante operações normais, enquanto os designs ativo-passivos podem reduzir os custos de computação de estado estável.

A lista a seguir fornece exemplos de suas responsabilidades ao projetar a solução:

• Implantação: Pré-criar as contas do Batch, pools ou definições de implantação de pool, contas de armazenamento, recursos de rede e outras dependências em cada região. Verifique se cada região selecionada dá suporte aos recursos do Batch, tamanhos de VM e serviços dependentes que sua carga de trabalho exige. Mantenha cada conta do Batch e os recursos de armazenamento usados por suas tarefas na mesma região, quando possível, para evitar latência desnecessária. Defina contas do Batch, pools e recursos de suporte usando infraestrutura como código para que a configuração possa ser reproduzida consistentemente entre regiões.

• Cotas e capacidade: Verifique as cotas aplicáveis da conta do Batch, da assinatura e da família de VM em todas as regiões de recuperação e solicite aumentos antes de uma interrupção, quando necessário. Uma cota é um limite, e não uma garantia de capacidade. A disponibilidade da VM varia de acordo com a região, a família de VMs e o momento. Para obter mais informações, consulte a conta do Batch e as cotas de núcleo.

• Replicação de dados: Mantenha pacotes de aplicativos, imagens de contêiner, dados de entrada e dados de referência disponíveis em todas as regiões de recuperação. O Batch não replica esses itens para você.

• Replicação de armazenamento: Configure a redundância de armazenamento e a replicação de dados entre regiões com base no objetivo do ponto de recuperação. Verifique se os dados replicados estão acessíveis a partir de cada região de recuperação. Para obter opções de confiabilidade de armazenamento, consulte Confiabilidade em Armazenamento de Blobs do Azure.

• Direcionamento de região: Se seus aplicativos funcionarem com sua conta do Batch, projete-os para que possam selecionar outra conta do Batch e seus recursos de armazenamento associados sem a necessidade de uma implantação de código.

• Failover: Batch não move automaticamente sua carga de trabalho para outra região. Você é responsável por detectar uma interrupção, determinar como a interrupção afeta sua carga de trabalho, interromper envios para a conta do Batch afetada, direcionar novos trabalhos para uma conta do Batch em uma região saudável e decidir se deseja reenviar trabalhos interrompidos. A saída de um trabalho ou de uma tarefa que você não replicou fora da região afetada pode estar indisponível ou perdida. O tempo de recuperação depende do modelo de implantação, da capacidade disponível, da replicação de dados e da automação.

• Recuperação de região: Depois que a disponibilidade do serviço for restaurada na região afetada, valide a conta do Batch, os pools, as dependências de armazenamento e o estado do trabalho antes de direcionar o trabalho para essa região. Reconcilie tarefas duplicadas ou parcialmente concluídas antes da reenviação. O Batch não coordena esse processo nem concilia o estado entre contas regionais.

• Teste: Teste regularmente o processo de recuperação regional completo em um ambiente de não produção. Simule uma implantação regional tornando-se indisponível, direcione as submissões para outra conta regional do Batch, valide o acesso a pacotes de aplicativos e dados de entrada, execute trabalhos representativos, colete a saída e pratique o retorno da implantação recuperada ao serviço. Meça os resultados em relação ao objetivo de tempo de recuperação e ao objetivo do ponto de recuperação.

Backup e restauração

Lote do Azure não é um repositório durável para dados de entrada e saída da carga de trabalho. Microsoft mantém o serviço Batch, mas você é responsável por preservar a configuração e os dados necessários para recriar sua carga de trabalho:

• Configuração do Batch: Defina contas do Batch, pools, trabalhos e recursos de suporte usando infraestrutura como código, como Bicep, e definições de trabalho controladas por versão. Esses artefatos fornecem uma maneira repetível de recriar a configuração na mesma região ou em outra região. Teste regularmente se as definições podem implantar um pool e executar um trabalho representativo.

• Metadados do lote: O Lote retém registros de jobs e tarefas até que você exclua o job ou a tarefa associados, mas esses registros não são um backup. Se você precisar manter esse histórico, preserve os registros necessários fora do Batch.

• Dados sobre nós de computação: Nós de computação são efêmeros e seus sistemas de arquivos não são backup nem armazenamento durável. Os dados em um nó são perdidos quando o nó é reimageado ou sai de um pool. O Batch também pode excluir arquivos de tarefa depois que o período de retenção expirar. Persista os logs de saída e diagnóstico necessários em armazenamento durável antes que uma tarefa seja concluída. Para tarefas de execução prolongada, persista pontos de verificação durante a execução. Para obter mais informações, consulte Persistir a saída do trabalho e da tarefa e Monitorar o Lote do Azure.

• Dados em contas de autostorage: Uma conta de autostorage associada pode conter pacotes de aplicativos e arquivos de recurso de tarefa. Além de configurar a redundância que atenda aos seus objetivos de recuperação, considere se você precisa proteger esses dados contra exclusão acidental ou corrupção. Para obter mais informações, consulte Backup e recuperação no Armazenamento de Blobs do Azure.

Teste de restauração e recuperação

Para recuperar, implante a configuração do Batch e dos recursos de suporte, restaure ou reconecte os dados de entrada e os artefatos de aplicativo necessários e reenvie o trabalho que não foi concluído. Teste periodicamente a reconstrução de recursos e a restauração de dados em um ambiente de recuperação isolado ou de não produção. Utilize definições controladas por versão e dados armazenados em backup, execute um trabalho representativo, verifique a saída resultante e o acesso às dependências e meça o tempo de recuperação e o ponto de recuperação alcançados em relação aos seus objetivos. Verifique se as tarefas são idempotentes para que a reenviação de trabalho incerto não corrompa dados ou crie uma saída duplicada.

Resiliência à manutenção do serviço

Microsoft executa a manutenção da plataforma e coordena atualizações de infraestrutura para Lote do Azure e outros serviços. Você é responsável por configurar o comportamento de atualização do pool e projetar tarefas para tolerar a interrupção.

• Manutenção do host: Azure usa técnicas de manutenção, como migração ao vivo, quando possível. Se a manutenção exigir que um nó de computação seja reiniciado ou movido, as tarefas em execução poderão ser interrompidas e o Batch poderá reagendá-las. Torne as tarefas idempotentes e persista pontos de verificação e saída para o armazenamento durável.

• Sistema operacional convidado: Você é responsável por manter o sistema operacional convidado e o agente de nó do Batch atualizados. O comportamento de atualização do sistema operacional depende da configuração de imagem e atualização. Com a configuração apropriada, as atualizações automáticas de imagem do sistema operacional para pools do Batch podem atualizar nós de pool sem interromper a execução de tarefas. As atualizações automáticas de imagem do sistema operacional não dão suporte a todas as imagens do sistema operacional do Batch.

• Atualizações do agente do nó: As atualizações automáticas de imagem do sistema operacional não atualizam automaticamente o agente de nó do Batch. Os agentes de nó do lote não são atualizados automaticamente enquanto houver nós de computação no pool. Para receber um agente de nó mais recente, redimensione o pool para zero nós e dimensione-o novamente ou substitua o pool. Antes de remover nós, preserve qualquer saída de tarefa e logs de diagnóstico necessários. Para obter mais informações, consulte atualizações do agente de nó do Batch.

Siga as recomendações de implantação de produção e as diretrizes de falha do nó de computação para ajudar sua carga de trabalho a continuar ou se recuperar quando a manutenção interrompe tarefas ou torna os nós de computação indisponíveis.

Contrato de nível de serviço

O SLA (contrato de nível de serviço) para serviços de Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

O SLA de disponibilidade do Lote do Azure se aplica às operações executadas na API do Lote do Azure. Para obter informações detalhadas sobre os tipos de operações incluídas, examine a redação SLA. O tamanho do pool, a distribuição de zonas e os serviços dependentes afetam a disponibilidade de ponta a ponta da carga de trabalho, mas não alteram os termos do SLA do Batch.

Conteúdo relacionado

• Documentação do Lote do Azure
• Práticas recomendadas para Lote do Azure
• Confiabilidade no Azure