Confiabilidade no Lote do Azure
Este artigo descreve o suporte à confiabilidade no Lote do Azure e aborda a resiliência entre regiões com zonas de disponibilidade e links para informações sobre recuperação entre regiões e continuidade dos negócios.
Suporte à zona de disponibilidade
As zonas de disponibilidade do Azure são pelo menos três grupos de datacenters separados fisicamente em cada região do Azure. Os datacenters dentro de cada zona são equipados com energia, resfriamento e infraestrutura de rede independentes. Em caso de falha de uma zona local, as zonas de disponibilidade foram projetadas de modo que, se uma zona é afetada, os serviços regionais, a capacidade e a alta disponibilidade têm suporte nas 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 é obtida devido à redundância e ao isolamento lógico dos serviços do Azure. Para obter informações detalhadas sobre as zonas de disponibilidade no Azure, confira Regiões e zonas de disponibilidade.
Os serviços habilitados para zonas de disponibilidade do Azure foram projetados para fornecer o nível ideal de resiliência e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ter redundância de zona, com replicação automática entre zonas, ou podem ser zonais, com instâncias fixadas em uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre arquitetura zonal versus redundante de zona, consulte Recomendações para usar zonas e regiões de disponibilidade.
O Lote mantém a paridade com o Azure para dar suporte a zonas de disponibilidade.
Pré-requisitos
Para as contas do Lote no modo de assinatura do usuário, verifique se a assinatura na qual você está criando o pool não tem uma restrição de oferta de zona no SKU de VM solicitado. Para ver se sua assinatura não tem nenhuma restrição, chame a API de Lista de Skus dos Recursos e verifique o
ResourceSkuRestrictions. Se houver uma restrição de zona, você poderá enviar um tíquete de suporte para removê-la.Como a InfiniBand não dá suporte à comunicação entre zonas, você não poderá criar um pool com uma política de zonas se ela tiver a comunicação entre nós habilitada e usar uma SKU de VM que com suporte a InfiniBand.
O Lote mantém a paridade com o Azure para dar suporte a zonas de disponibilidade. Para usar a opção zonal, seu pool deve ser criado em uma região do Azure com suporte à zona de disponibilidade.
Para alocar o pool do Lote entre as zonas de disponibilidade, a região do Azure na qual o pool é criado deve dar suporte à SKU de VM solicitada em mais de uma zona. Para validar se a região dá suporte à SKU de VM solicitada em mais de uma zona, chame a API de Lista de Skus de Recursos e verifique o
locationInfocampo deresourceSku. 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 todos as SKUs de recursos disponíveis com o seguinte comando:az vm list-skus
Criar um pool do Lote do Azure em zonas de disponibilidade
Para obter exemplos de como criar um pool de Lote incluindo várias zonas de disponibilidade, confira Criar um pool de Lote do Azure incluindo várias zonas de disponibilidade.
Saiba mais sobre como criar contas do Lote com o portal do Azure, a CLI do Azure, o PowerShell ou a API de gerenciamento do Lote.
Experiência de zona inoperante
Durante uma interrupção de zona indisponível, 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 ou cria novos nós para compensar os nós que caíram devido à interrupção. Os usuários são obrigados a adicionar mais nós ao pool de nós e eles são alocados de outras zonas íntegras.
Tolerância a falhas
Para se preparar para uma possível falha da zona de disponibilidade, você deve superprovisionar a capacidade de serviço para garantir que a solução possa tolerar perda de 1/3 de capacidade e continuar funcionando sem desempenho degradado durante interrupções em toda a zona. Como a plataforma difunde as VMs em três zonas e você precisa considerar pelo menos a falha de uma zona, multiplique a contagem de instâncias de carga de trabalho de pico por um fator de zonas/(zonas-1) ou 3/2. Por exemplo, se a carga de trabalho de pico comum exigir quatro instâncias, você deverá provisionar seis instâncias: (2/3 * 6 instâncias) = 4 instâncias.
Migração da zona de disponibilidade
Você não pode migrar um pool de Lote existente para o suporte da zona de disponibilidade. Se quiser recriar um pool de Lote incluindo várias zonas de disponibilidade, confira Criar um pool de Lote do Azure incluindo várias zonas de disponibilidade.
Recuperação de desastre entre regiões e continuidade dos negócios
O Lote do Azure está disponível em todas as regiões do Azure. Mas quando uma conta do Lote é criada, ela deve ser associada a uma região específica. Todas as operações posteriores da conta do Lote só se aplicam a essa região. Por exemplo, pools e VMs (máquinas virtuais) associadas são criadas na mesma região que a conta do Lote.
Ao criar um aplicativo que usa o Lote, você deve considerar a possibilidade de o Lote não estar disponível em uma região. É possível encontrar uma rara situação em que há um problema com a região como um todo, todo o Lote de serviço na região ou sua conta específica do Lote.
Se o aplicativo ou solução que estiver usando o Lote sempre precisar estar disponível, ele deverá ser projetado para failover em outra região ou sempre ter a carga de trabalho dividida entre duas ou mais regiões. As duas abordagens exigem pelo menos duas contas do Lote, estando cada conta localizada em uma região diferente.
Você é responsável por configurar a recuperação de desastre entre regiões com o Lote do Azure. Se você executar várias contas do Lote em regiões específicas e aproveitar as zonas de disponibilidade, seu aplicativo poderá atender aos seus objetivos de recuperação de desastre quando uma de suas contas do Lote ficar indisponível.
Ao fornecer a capacidade de fazer failover para uma região alternativa, todos os componentes em uma solução precisam ser levados em conta. Ter uma segunda conta do Lote não é suficiente. Por exemplo, na maioria dos aplicativos do Lote, uma conta de armazenamento do Azure é necessária. A conta de armazenamento e a conta do Lote devem estar na mesma região para haver um desempenho aceitável.
Considere os seguintes pontos ao projetar uma solução que pode fazer failover:
Crie previamente todos os serviços necessários em cada região, como a conta do Lote e a conta de armazenamento. Geralmente, não há nenhuma cobrança por ter contas criadas, e as cobranças se acumulam somente quando a conta é usada ou quando os dados são armazenados.
Verifique antecipadamente se as cotas apropriadas estão definidas para todas as contas do Lote de assinatura de usuário para alocar o número necessário de núcleos usando a conta do Lote.
Use modelos de e/ou scripts para automatizar a implantação do aplicativo em uma região.
Mantenha dados de referência e binários de aplicativo atualizados em todas as regiões. Permanecer atualizado garantirá que a região possa ser colocada online rapidamente sem necessidade de esperar o upload e a 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 do Lote. Quando uma atualização do aplicativo é lançada, ela deve ser carregada em cada conta do Lote e referenciada pela configuração do pool (ou a versão mais recente deve se tornar a versão padrão).
No aplicativo que chama o Lote, o armazenamento e quaisquer outros serviços, facilite a troca de clientes ou a carga em regiões diferentes.
Considere a possibilidade de alternar com frequência 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 lote em si é independente de você usar várias contas ou uma única conta. Em configurações ativo-ativo, em que duas instâncias do Lote estão recebendo tráfego simultaneamente, a recuperação de desastre é mais rápida do que em uma configuração ativo-passivo. A configuração você escolher deve ser baseada em necessidades de negócios (regiões diferentes, requisitos de latência) e considerações técnicas.
Recuperação de desastre em região única
A forma como você implementa a recuperação de desastre no Lote é a mesma, esteja você trabalhando em uma 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 conta de armazenamento ou uma conta diferente em todas as regiões.
Teste de recuperação de desastres
Você deve executar seu próprio teste de recuperação de desastre de sua solução habilitada para Lote. Habilitar a alternância fácil entre a carga do cliente e do serviço em diferentes regiões é uma prática recomendada.
Testar seu plano de recuperação de desastre para o Lote pode ser tão simples quanto alternar contas do Lote. Por exemplo, você pode contar com uma única conta do Lote em uma região específica para um dia operacional. No dia seguinte, você pode mudar para uma segunda conta do Lote em uma região diferente. A recuperação de desastre é gerenciada principalmente no lado do cliente. Essa abordagem de várias contas para a recuperação de desastres cuida das expectativas de RTO e RPO em regiões individuais ou regiões múltiplas.
Capacidade e resiliência proativa de recuperação de desastre
A Microsoft e seus clientes operam sob o Modelo de Responsabilidade Compartilhada. A Microsoft é responsável pela resiliência de plataforma e infraestrutura. Você é responsável por lidar com a recuperação de desastre de qualquer serviço específico que implante e controle. Para garantir que a recuperação seja proativa:
Você sempre deve pré-reimplantar 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 esses recursos.
Pré-crie todos os serviços necessários em cada região, como suas contas do Lote e contas de armazenamento associadas. Não há nenhuma cobrança para criar novas contas. As cobranças se acumulam somente quando a conta é usada ou quando os dados são armazenados.
Verifique se as cotas apropriadas estão definidas em todas as assinaturas com antecedência para que você possa alocar o número necessário de núcleos usando a conta do Lote. Como com outros serviços do Azure, há limites em determinados recursos associados ao serviço de Lote. Muitos desses limites são cotas padrão aplicadas pelo Azure no nível da assinatura ou da conta. Lembre-se dessas cotas quando estiver projetando e dimensionando suas cargas de trabalho do Lote.
Observação
Se você planeja executar cargas de trabalho de produção em Lote, talvez seja necessário aumentar uma ou mais cotas para acima do padrão. Para aumentar uma cota, você pode solicitar um aumento de cota sem custo. Para obter mais informações, consulte Solicitar um aumento de cota.
Armazenamento
Você deve configurar o armazenamento em lote para garantir que os dados sejam copiados entre regiões. A responsabilidade do cliente é o padrão. A maioria das soluções do Lote usa o Armazenamento do Azure para armazenar arquivos de recurso e de saída. Por exemplo, as tarefas do Lote (incluindo as tarefas padrão, tarefas iniciais, tarefas de preparação do trabalho e tarefas de liberação do trabalho) especificam tipicamente os arquivos de recurso que residem nas contas de armazenamento. As contas de armazenamento também armazenam os dados processados e os dados de saída gerados. Considere a possibilidade de perda de dados entre as regiões de suas operações de serviço. Você também deve confirmar se os dados são recriáveis ou somente leitura.
O Lote é compatível com as seguintes opções de conta de Armazenamento do Azure:
- Contas de v2 (GPv2) de uso geral
- Contas v1 (GPv1) de uso geral
- Contas de armazenamento de Blobs (atualmente com suporte para pools de configuração de máquina virtual)
Para saber mais sobre as contas de armazenamento, confira Visão geral da conta de armazenamento do Azure.
Você pode associar uma conta de armazenamento à sua conta do Lote durante a criação da conta ou depois.
Se você estiver configurando uma conta de armazenamento separada para cada região em que seu serviço está disponível, use contas ZRS (armazenamento com redundância de zona). Use contas de GZRS (armazenamento com redundância de zona geográfica) se você estiver usando a mesma conta de armazenamento em várias regiões emparelhadas. Para geografias que contêm uma única região, você deve criar uma conta de ZRS (armazenamento com redundância de zona) porque o GZRS não está disponível.
O planejamento de capacidade é outra consideração importante com o armazenamento e deve ser abordado proativamente. Considere seus requisitos de desempenho e custo ao escolher uma conta de armazenamento. Por exemplo, as opções de conta de armazenamento de blob e GPv2 dão suporte a limites maiores de capacidade e escalabilidade em comparação com a GPv1. (Contate o Suporte do Azure para solicitar um aumento do limite de armazenamento.) Essas opções de conta podem melhorar o desempenho das soluções do Lote que contêm uma grande quantidade de tarefas paralelas lidas ou gravadas na conta de armazenamento.
Quando uma conta de armazenamento é vinculada a uma conta do Lote, pense nela como uma conta de armazenamento automático. Uma conta de armazenamento automático será necessária se você planejar usar a funcionalidade de pacotes de aplicativos, pois ela é usada para armazenar os arquivos .zip do pacote de aplicativos. Uma conta de armazenamento automático também pode ser usada para arquivos de recurso de tarefa; como a conta de armazenamento automático já está vinculada à conta do Lote, isso evita a necessidade de URLs de SAS (assinatura de acesso compartilhado) para acessar os arquivos de recurso.