Fiabilidade no Azure Batch

Este artigo descreve o suporte à confiabilidade no Azure Batch e aborda a resiliência intrarregional com zonas de disponibilidade e links para informações sobre recuperação entre regiões e continuidade de negócios.

Suporte à zona de disponibilidade

As zonas de disponibilidade do Azure são pelo menos três grupos fisicamente separados de datacenters em cada região do Azure. Os datacenters dentro de cada zona são equipados com infraestrutura independente de energia, resfriamento e rede. No caso de uma falha de zona local, as zonas de disponibilidade são projetadas de modo que, se uma zona for afetada, os serviços regionais, a capacidade e a alta disponibilidade sejam suportados pelas duas zonas restantes.

As falhas podem variar de falhas de software e hardware a eventos como terremotos, inundações e incêndios. A tolerância a falhas é alcançada com redundância e isolamento lógico dos serviços do Azure. Para obter informações mais detalhadas sobre zonas de disponibilidade no Azure, consulte Regiões e zonas de disponibilidade.

Os serviços habilitados para zonas de disponibilidade do Azure são projetados para fornecer o nível certo de confiabilidade e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ser redundantes de zona, com replicação automática entre zonas, ou zonais, com instâncias fixadas a uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre arquitetura zonal versus arquitetura com redundância de zona, consulte Recomendações para usar zonas e regiões de disponibilidade.

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

Pré-requisitos

• Para contas em lote do modo de assinatura de usuário, verifique se a assinatura na qual você está criando seu pool não tem uma restrição de oferta de zona na SKU de VM solicitada. Para ver se sua assinatura não tem restrições, ligue para 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 oferece suporte à comunicação entre zonas, você não poderá criar um pool com uma política zonal se ela tiver a comunicação entre nós habilitada e usar uma SKU de VM que ofereça suporte a 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 de Lista de Skus de Recursos e verifique o locationInfo campo 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 Lotes do Azure entre 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 zona descendente, 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 Lote do Azure não realoca nem cria novos nós para compensar os nós que ficaram inativos devido à interrupção. Os usuários são obrigados a adicionar mais nós ao pool de nós, que são alocados de outras zonas íntegras.

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 de lotes existente para o suporte à zona de disponibilidade. Se desejar recriar seu pool de lotes entre zonas de disponibilidade, consulte Criar um pool de lotes do Azure em 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 Lote de assinatura de usuário, para alocar o número necessário de núcleos usando a conta de lote.

• 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 um aplicativo personalizado para instalar em nós de pool é armazenado e referenciado usando pacotes de aplicativos em lote. 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 próprio lote é agnóstico em relação a se você está usando várias contas ou uma única conta. Em configurações ativo-ativo, onde duas instâncias em lote estão recebendo tráfego simultaneamente, a recuperação de desastres é mais rápida do que para uma 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 seu próprio teste de recuperação de desastres de sua solução habilitada para 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, você pode contar com uma única conta de lote em uma região específica por um dia operacional. Então, no dia seguinte, você pode mudar para uma segunda conta de lote 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é-implantar 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 uma 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 em lote para garantir que o backup dos dados seja feito entre regiões; a responsabilidade do cliente é o 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 para Fins gerais v2 (GPv2)
• Contas para Fins gerais v1 (GPv1)
• Contas de armazenamento de blobs (atualmente suportadas para conjuntos na configuração da 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. Uma conta de armazenamento automático é necessária se você planeja usar o recurso de pacotes de aplicativos, pois ele é usado para armazenar o pacote de aplicativos .zip arquivos. Uma conta de armazenamento automático também pode ser usada para arquivos de recursos de tarefas, uma vez que 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 arquivos de recursos.

Próximos passos

• Fiabilidade no Azure