Recomendações para a conceção de várias regiões de elevada disponibilidade
Aplica-se a esta recomendação da lista de verificação de fiabilidade do Azure Well-Architected Framework:
| RE:05 | Adicione redundância a diferentes níveis, especialmente para fluxos críticos. Aplique redundância às camadas de computação, dados, rede e outras infraestruturas de acordo com os destinos de fiabilidade identificados. |
|---|
Guias relacionados:Redundância | Utilizando zonas e regiões de disponibilidade
Este guia descreve as recomendações para conceber um ambiente de cloud de várias regiões de elevada disponibilidade. A elevada disponibilidade é um princípio fundamental da conceção de fiabilidade. Uma arquitetura de elevada disponibilidade pode ajudá-lo a evitar o máximo de tempo de inatividade possível e a recuperar de forma eficiente se ocorrer um período de indisponibilidade.
Ativo-ativo e ativo-passivo são tipos de arquitetura gerais que podem ser aplicados de formas diferentes, consoante a plataforma em que implementa o seu ambiente. Este guia centra-se na conceção de um ambiente de cloud de várias regiões. No Azure, também pode criar uma arquitetura ativa-ativa ou ativa-passiva numa única região através de zonas de disponibilidade. Para obter orientações detalhadas sobre a conceção de uma arquitetura de elevada disponibilidade através de zonas de disponibilidade, veja o Guia do Azure Well-Architected Framework.
Principais estratégias de conceção
Ativo-ativo e ativo-passivo são as duas abordagens fundamentais para conceber um ambiente de cloud de elevada disponibilidade. Os ambientes ativos-ativos foram concebidos para processar cargas de produção em todas as regiões em que implementa a carga de trabalho. Os ambientes ativos-passivos foram concebidos para processar cargas de produção apenas na região primária, mas efetuam a ativação pós-falha para a região secundária (passiva) quando necessário. Selecionar as melhores regiões do Azure para a sua carga de trabalho é uma parte fundamental da conceção de um ambiente de várias regiões de elevada disponibilidade. Para obter orientações sobre como selecionar regiões do Azure, veja o guia Selecionar Regiões do Azure.
Esta secção descreve as opções de estrutura que deve considerar quando avalia cada padrão e refina a sua arquitetura para satisfazer os seus requisitos empresariais.
Veja Deployment Stamps pattern (Padrão de Selos de Implementação ) para obter orientações sobre como arquitetar a carga de trabalho de forma repetível e dimensionável. Este padrão de conceção pode ajudá-lo a otimizar o design de elevada disponibilidade para uma gestão eficiente.
As secções seguintes descrevem as opções de estrutura dos dois padrões.
Ativa-ativa
Ativo-ativo na capacidade: carimbos de implementação espelhados em duas ou mais regiões do Azure, cada uma configurada para processar cargas de trabalho de produção para a região ou regiões que servem e dimensionáveis para processar cargas de outras regiões em caso de indisponibilidade regional.
Rede: utilize a latência ou o encaminhamento global ponderado para distribuir o tráfego entre regiões.
Replicação e consistência de dados: utilize um arquivo de dados distribuído globalmente, como o Azure Cosmos DB , para capacidades de leitura e escrita de várias regiões. Para bases de dados relacionais, utilize réplicas legíveis com cadeias de ligação só de leitura.
Vantagem deste design: custos operacionais mais baixos do que um design sobreaprovisionado.
Desvantagem deste design: possível degradação da experiência do utilizador ao aumentar verticalmente para satisfazer as exigências de uma carga completa se outra região sofrer uma indisponibilidade.
Ativo-ativo sobreaprovisionado: carimbos de implementação espelhados em duas ou mais regiões do Azure, cada uma sobreaprovisionada para processar cargas de trabalho de produção para a região ou regiões que servem e para processar cargas de outras regiões em caso de indisponibilidade regional.
Rede: utilize a latência ou o encaminhamento global ponderado para distribuir o tráfego entre regiões.
Replicação e consistência de dados: utilize um arquivo de dados distribuído globalmente, como o Azure Cosmos DB , para capacidades de leitura e escrita de várias regiões. Para bases de dados relacionais, utilize réplicas legíveis com cadeias de ligação só de leitura.
Vantagem deste design: o design mais resiliente possível.
Desvantagem deste design: custos operacionais mais elevados do que um design dimensionável.
Vantagens comuns de ambos os designs: elevada resiliência e baixo risco de indisponibilidade total da carga de trabalho.
Desvantagens comuns de ambos os designs: custos operacionais e encargos de gestão mais elevados devido a vários fatores, incluindo a necessidade de gerir a sincronização do estado e dos dados da aplicação.
Ativa-passiva
Sobressalente quente: uma região primária e uma ou mais regiões secundárias. A região secundária é implementada com o tamanho mínimo possível de computação e dados e é executada sem carga. Esta região é conhecida como uma região de reserva quente . Após a ativação pós-falha, os recursos de computação e dados são dimensionados para processar a carga da região primária.
Rede: utilize o encaminhamento global prioritário .
Replicação e consistência de dados: replique a base de dados para a sua região passiva e utilize as capacidades de ativação pós-falha automática de soluções paaS (plataforma como serviço), como o Azure Cosmos DB e a Base de Dados SQL do Azure.
Vantagem deste design: o tempo de recuperação mais curto entre os designs ativo-passivo.
Desvantagem deste design: custo operacional mais elevado entre os designs ativo-passivo.
Sobressalente a frio: uma região primária e uma ou mais regiões secundárias. A região secundária é dimensionada para processar a carga total, mas todos os recursos de computação são parados. Esta região é conhecida como uma região sobressalente fria . Tem de iniciar os recursos antes da ativação pós-falha.
Rede: utilize o encaminhamento global prioritário .
Replicação e consistência de dados: replique a base de dados para a região passiva e utilize as capacidades de ativação pós-falha automática de soluções PaaS, como o Azure Cosmos DB e a Base de Dados SQL do Azure.
Vantagem deste design: custos operacionais mais baixos do que o design de reserva quente.
Desvantagem deste design: tempo de recuperação mais longo do que o design de reserva quente.
Reimplementar após desastre: uma região primária e uma ou mais regiões secundárias. Apenas a rede necessária é implementada na região secundária. Os operadores têm de executar scripts de aprovisionamento na região secundária para efetuar a ativação pós-falha das cargas de trabalho. Este design é conhecido como reimplementar em desastres.
Rede: utilize o encaminhamento global prioritário .
Replicação e consistência de dados: implemente novas instâncias de base de dados e reidrate os dados a partir de cópias de segurança.
Vantagem deste design: os custos operacionais mais baixos.
Desvantagem deste design: tempo de recuperação mais longo.
Vantagens comuns das estruturas ativas-passivas: custos operacionais mais baixos e menos encargos diários de gestão do que os designs ativos-ativos. Não é necessário sincronizar o estado da aplicação.
Desvantagens comuns dos designs ativo-passivo: processo de recuperação mais longo e complexo. Maior probabilidade de precisar de intervenção manual para uma ativação pós-falha bem-sucedida.
Nota
Independentemente da sua estrutura de elevada disponibilidade, lembre-se de configurar a redundância para os serviços de suporte, como a infraestrutura do Azure DevOps, as jump boxes, a monitorização e qualquer outro serviço crítico necessário para administrar a carga de trabalho.
Facilitação do Azure
O Azure Front Door combina a funcionalidade de encaminhamento global do Gestor de Tráfego do Azure com um sistema de entrega de conteúdos e uma firewall de aplicações Web para o ajudar a gerir a carga de trabalho de elevada disponibilidade.
O Azure Cosmos DB é uma plataforma de base de dados NoSQL distribuída globalmente que pode ajudá-lo a executar um ambiente ativo-ativo e minimizar a possibilidade de tempo de inatividade quando ocorre uma indisponibilidade regional.
Ligações relacionadas
Lista de verificação de fiabilidade
Veja o conjunto completo de recomendações.
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários