Fiabilidade no Azure Batch

Este artigo descreve o suporte à confiabilidade no Azure Batch. Ele aborda como melhorar a resiliência intrarregional usando zonas de disponibilidade, pools de lotes e nós de computação para minimizar o tempo de inatividade e a perda de dados. Ele também tem links para informações sobre recuperação entre regiões e continuidade de negócios.

Suporte à zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem fazer failover para uma das zonas restantes.

O Batch mantém a paridade com o Azure nas zonas de disponibilidade de suporte.

Pré-requisitos

• Para contas Batch no modo de subscrição de utilizador, assegure-se de que a subscrição na qual está a criar o seu pool não tenha uma restrição de ofertas de zona na SKU de VM solicitada. Para ver se a sua assinatura não tem restrições, chame a API Resource Skus List e verifique o ResourceSkuRestrictions. Se existir uma restrição de zona, você pode enviar um tíquete de suporte para remover a restrição de zona.

• Como a InfiniBand não suporta comunicação entre zonas, não poderá criar um pool com uma política zonal se esta tiver a comunicação inter-nó ativada e usar uma SKU de VM que suporte InfiniBand.

• O Batch mantém a paridade com o Azure nas zonas de disponibilidade de suporte. Para usar a opção zonal, seu pool deve ser criado em uma região do Azure com suporte à zona de disponibilidade.

• Para alocar seu pool de lotes entre zonas de disponibilidade, a região do Azure na qual o pool foi criado deve dar suporte à SKU de VM solicitada em mais de uma zona. Para validar se a região suporta a SKU de VM solicitada em mais de uma zona, chame a API Lista de Recursos Skus e verifique o campo locationInfo de resourceSku. Verifique se há suporte para mais de uma zona para a SKU de VM solicitada. Você também pode usar a CLI do Azure para listar todas as SKUs de recursos disponíveis com o seguinte comando:

  
      az vm list-skus
  
  

Criar um pool de Batch do Azure através de zonas de disponibilidade

Para obter exemplos sobre como criar um pool de lotes em zonas de disponibilidade, consulte Criar um pool de lotes do Azure em zonas de disponibilidade.

Saiba mais sobre como criar contas em lote com o portal do Azure, a CLI do Azure, o PowerShell ou a API de gerenciamento de lote.

Experiência de zoneamento

Durante uma interrupção de serviço na zona, os nós dentro dessa zona ficam indisponíveis. Todos os nós dentro desse mesmo pool de nós de outras zonas não são afetados e continuam disponíveis.

A conta do Azure Batch não realoca nem cria novos nós para compensar os nós que ficaram inativos devido à interrupção. Os utilizadores são obrigados a adicionar mais nós ao pool de nós, que são alocados de outras zonas saudáveis.

Tolerância a falhas

Para se preparar para uma possível falha na zona de disponibilidade, você deve provisionar excessivamente a capacidade de serviço para garantir que a solução possa tolerar 1/3 de perda de capacidade e continuar a funcionar sem desempenho degradado durante interrupções em toda a zona. Como a plataforma distribui VMs por três zonas e você precisa levar em conta pelo menos a falha de uma zona, multiplique a contagem de instâncias de pico de carga de trabalho por um fator de zonas/(zonas-1) ou 3/2. Por exemplo, se sua carga de trabalho de pico típica requer quatro instâncias, você deve provisionar seis instâncias: (2/3 * 6 instâncias) = 4 instâncias.

Migração da zona de disponibilidade

Não é possível migrar um pool Batch existente para o suporte à zona de disponibilidade. Se desejar recriar o seu Batch Pool nas zonas de disponibilidade, consulte Criar um Batch Pool do Azure nas zonas de disponibilidade.

Recuperação de desastres entre regiões e continuidade de negócios

O Azure Batch está disponível em todas as regiões do Azure. No entanto, quando uma conta de lote é criada, ela deve ser associada a uma região específica. Todas as operações subsequentes para essa conta de lote só se aplicam a essa região. Por exemplo, pools e máquinas virtuais (VMs) associadas são criados na mesma região que a conta de lote.

Ao projetar um aplicativo que usa Batch, você deve considerar a possibilidade de que Batch pode não estar disponível em uma região. É possível encontrar uma situação rara em que há um problema com a região como um todo, todo o serviço Batch na região ou sua conta Batch específica.

Se o aplicativo ou solução usando Batch deve estar sempre disponível, ele deve ser projetado para failover para outra região ou sempre ter a carga de trabalho dividida entre duas ou mais regiões. Ambas as abordagens exigem pelo menos duas contas em lote, com cada conta localizada em uma região diferente.

Você é responsável por configurar a recuperação de desastres entre regiões com o Azure Batch. Se você executar várias contas de lote em regiões específicas e aproveitar as zonas de disponibilidade, seu aplicativo poderá atender aos seus objetivos de recuperação de desastres quando uma de suas contas de lote ficar indisponível.

Ao fornecer a capacidade de failover para uma região alternativa, todos os componentes de uma solução devem ser considerados; não basta simplesmente ter uma segunda conta Batch. Por exemplo, na maioria dos aplicativos em lote, uma conta de armazenamento do Azure é necessária. A conta de armazenamento e a conta de lote devem estar na mesma região para um desempenho aceitável.

Considere os seguintes pontos ao projetar uma solução que pode fazer failover:

• Pré-crie todos os serviços necessários em cada região, como a conta de lote e a conta de armazenamento. Muitas vezes, não há cobrança por ter contas criadas, e as cobranças se acumulam apenas quando a conta é usada ou quando os dados são armazenados.

• Certifique-se antecipadamente de que as cotas apropriadas estão definidas para todas as contas de Batch de subscrição de usuário, para alocar o número necessário de núcleos através da conta de Batch.

• Use modelos e/ou scripts para automatizar a implantação do aplicativo em uma região.

• Mantenha os binários de aplicativos e os dados de referência atualizados em todas as regiões. Manter-se atualizado garantirá que a região possa ser colocada on-line rapidamente sem ter que esperar pelo upload e implantação de arquivos. Por exemplo, considere o caso em que uma aplicação personalizada para instalar em nós de pool é armazenada e referenciada usando pacotes de aplicações Batch. Quando uma atualização do aplicativo é lançada, ela deve ser carregada em cada conta do Batch e referenciada pela configuração do pool (ou tornar a versão mais recente a versão padrão).

• No aplicativo que chama Batch, o armazenamento e quaisquer outros serviços, facilitam a alternância entre clientes ou a carga para regiões diferentes.

• Considere mudar frequentemente para uma região alternativa como parte da operação normal. Por exemplo, com duas implantações em regiões separadas, mude para a região alternativa todos os meses.

A duração do tempo para se recuperar de um desastre depende da configuração escolhida. O Batch em si é indiferente quanto a usar várias contas ou uma única conta. Em configurações ativo-ativo, onde duas instâncias Batch estão a receber tráfego simultaneamente, a recuperação de desastres é mais rápida do que numa configuração ativo-passivo. A configuração escolhida deve ser baseada nas necessidades de negócios (diferentes regiões, requisitos de latência) e considerações técnicas.

Recuperação de desastres em uma única região

A forma como implementa a recuperação de desastres no Batch é a mesma, quer esteja a trabalhar numa geografia de região única ou de várias regiões. As únicas diferenças são qual SKU você usa para armazenamento e se você pretende usar a mesma ou diferente conta de armazenamento em todas as regiões.

Testes de recuperação de desastres

Você deve executar o seu próprio teste de recuperação em caso de desastres para a sua solução com suporte de processamento em lote. É considerada uma prática recomendada permitir a comutação fácil entre o cliente e a carga de serviço em diferentes regiões.

Testar seu plano de recuperação de desastres para o Batch pode ser tão simples quanto alternar contas do Batch. Por exemplo, pode utilizar uma única conta de lote numa região específica por um dia de operação. Então, no dia seguinte, poderás mudar para uma segunda conta Batch em uma região diferente. A recuperação de desastres é gerenciada principalmente no lado do cliente. Essa abordagem de várias contas para recuperação de desastres atende às expectativas de RTO e RPO em geografias de uma ou várias regiões.

Capacidade e resiliência proativa de recuperação de desastres

A Microsoft e seus clientes operam sob o modelo de Responsabilidade Compartilhada. A Microsoft é responsável pela resiliência da plataforma e da infraestrutura. Você é responsável por abordar a recuperação de desastres para qualquer serviço específico que implante e controle. Para garantir que a recuperação seja proativa:

• Você deve sempre pré-distribuir secundários. A pré-implantação de secundários é necessária porque não há garantia de capacidade no momento do impacto para aqueles que não pré-alocaram tais recursos.

• Pré-crie todos os serviços necessários em cada região, como suas contas de lote e contas de armazenamento associadas. A criação de novas contas é gratuita; As cobranças só se acumulam quando a conta é usada ou quando os dados são armazenados.

• Certifique-se de que as cotas apropriadas sejam definidas em todas as assinaturas com antecedência, para que você possa alocar o número necessário de núcleos usando a conta Batch. Tal como acontece com outros serviços do Azure, existem limites para determinados recursos associados ao serviço em lote. Muitos desses limites são cotas padrão aplicadas pelo Azure no nível da assinatura ou da conta. Tenha essas cotas em mente ao projetar e dimensionar suas cargas de trabalho em lote.

Nota

Se você planeja executar cargas de trabalho de produção em lote, talvez seja necessário aumentar uma ou mais cotas acima do padrão. Para aumentar a quota, pode solicitar um aumento de quota gratuitamente. Para obter mais informações, consulte Solicitar um aumento de cota.

Armazenamento

Você deve configurar o armazenamento do Batch para garantir que o backup dos dados seja feito entre diferentes regiões; a responsabilidade pelo cliente é a padrão. A maioria das soluções em lote usa o Armazenamento do Azure para armazenar arquivos de recursos e arquivos de saída. Por exemplo, as suas tarefas do Batch (incluindo tarefas standard, tarefas de início, tarefas de preparação de trabalhos e tarefas de lançamento de trabalhos), normalmente, especificam os ficheiros de recursos que residem numa contas de armazenamento. As contas de armazenamento também armazenam dados que são processados e quaisquer dados de saída que são gerados. Compreender a possível perda de dados entre as regiões de suas operações de serviço é uma consideração importante. Você também deve confirmar se os dados são regraváveis ou somente leitura.

O Batch suporta os seguintes tipos de contas de Armazenamento do Azure:

• Contas de Uso geral v2 (GPv2)
• Contas para fins gerais v1 (GPv1)
• Contas de armazenamento Blob (atualmente suportadas para pools na configuração de Máquina Virtual)

Para obter mais informações sobre as contas de armazenamento, veja Azure Storage account overview (Descrição geral da conta de armazenamento do Azure).

Você pode associar uma conta de armazenamento à sua conta de lote ao criar a conta ou fazer esta etapa mais tarde.

Se você estiver configurando uma conta de armazenamento separada para cada região em que seu serviço está disponível, deverá usar contas de armazenamento com redundância de zona (ZRS). Use contas de armazenamento com redundância geográfica (GZRS) se estiver usando a mesma conta de armazenamento em várias regiões emparelhadas. Para regiões geográficas que contêm uma única região, você deve criar uma conta de armazenamento com redundância de zona (ZRS) porque o GZRS não está disponível.

O planejamento de capacidade é outra consideração importante com o armazenamento e deve ser abordado de forma proativa. Considere os requisitos de desempenho e custo ao escolher uma conta de armazenamento. Por exemplo, as opções de conta de armazenamento GPv2 e BLOBs suportam limites de escalabilidade e capacidade mais elevados em comparação com a GPv1. (Entre em contato com o Suporte do Azure para solicitar um aumento em um limite de armazenamento.) Essas opções de conta podem melhorar o desempenho de soluções em lote que contêm um grande número de tarefas paralelas que leem ou gravam na conta de armazenamento.

Quando uma conta de armazenamento estiver vinculada a uma conta de lote, pense nela como a conta de armazenamento automático. É necessária uma conta de autostorage se tenciona usar a capacidade de pacotes de aplicativos, pois é utilizada para armazenar os arquivos .zip do pacote de aplicativos. Uma conta de armazenamento automático também pode ser usada para ficheiros de recursos de tarefas; como a conta de armazenamento automático já está vinculada à conta em lote, isso evita a necessidade de URLs de assinatura de acesso compartilhado (SAS) para acessar os ficheiros de recursos.

Próximos passos

• Fiabilidade no Azure