Estratégias de arquitetura para projetar para redundância

Aplica-se a esta recomendação de lista de verificação de confiabilidade do Azure Well-Architected Framework:

Este guia descreve as recomendações para adicionar redundância em fluxos críticos em diferentes camadas de carga de trabalho, o que otimiza a resiliência. Atenda aos requisitos de seus destinos de confiabilidade definidos aplicando os níveis adequados de redundância à sua computação, dados, rede e outras camadas de infraestrutura. Aplique essa redundância para dar à sua carga de trabalho uma base forte e confiável para criar. Quando você cria sua carga de trabalho sem redundância de infraestrutura, há um alto risco de tempo de inatividade estendido devido a possíveis falhas.

Definições

No contexto de confiabilidade, use redundância para conter problemas que afetam um único recurso e garantir que esses problemas não afetem a confiabilidade de todo o sistema. Use as informações que você identificou sobre seus fluxos críticos e destinos de confiabilidade para tomar decisões informadas necessárias para a redundância de cada fluxo.

Por exemplo, você pode ter vários nós de servidor Web que são executados ao mesmo tempo. Se o fluxo que eles dão suporte for crítico, todos os nós poderão precisar de réplicas que possam aceitar o tráfego imediatamente se um problema afetar todo o pool, como uma interrupção completa do datacenter. Como alternativa, como problemas em larga escala são raros e é caro implantar um conjunto inteiro de réplicas, você pode implantar um número limitado de réplicas para que o fluxo opere em um estado degradado até que você resolva o problema.

Ao projetar para redundância no contexto de eficiência de desempenho, distribua a carga entre vários nós redundantes para garantir que cada nó seja executado de forma ideal. No contexto de confiabilidade, crie uma capacidade sobressalente para absorver falhas ou defeitos que afetam um ou mais nós. Verifique se a capacidade de reposição pode absorver falhas durante todo o tempo necessário para recuperar os nós afetados. Com essa distinção em mente, ambas as estratégias precisam trabalhar juntas. Se você espalhar o tráfego entre dois nós para desempenho e ambos forem executados em 60% utilização e um nó falhar, o nó restante corre o risco de ficar sobrecarregado porque ele não pode operar em 120%. Espalhe a carga com outro nó para garantir que seus destinos de desempenho e confiabilidade sejam mantidos.

Compensações:

• Mais redundância de carga de trabalho equivale a mais custos. Considere cuidadosamente a adição de redundância e examine regularmente sua arquitetura para garantir que você esteja gerenciando custos, especialmente quando você usa o excesso de provisionamento. Ao usar o excesso de provisionamento como uma estratégia de resiliência, balancee-o com uma estratégia de dimensionamento bem definida para minimizar as ineficiências de custo.

• Pode haver compensações de desempenho quando você cria um alto grau de redundância. Por exemplo, os recursos que se espalham entre zonas de disponibilidade ou locais podem afetar o desempenho porque você precisa enviar tráfego por conexões de alta latência entre recursos redundantes, como servidores Web ou instâncias de banco de dados.

• Fluxos diferentes dentro da mesma carga de trabalho podem ter requisitos de confiabilidade diferentes. Os designs de redundância específicos do fluxo podem potencialmente introduzir complexidade no design geral.

• Um design de redundância de baixa latência significa que você aceita o risco de perder esses componentes no caso de um evento em grande escala, como um desastre geográfico, que coloca todas as instâncias offline. Um ambiente de recuperação de desastre (DR) geo distante ajuda a atenuar esse risco, mas aumenta os custos.

Preferir serviços totalmente gerenciados e sem servidor para reduzir a carga operacional

Aproveite as soluções de SaaS (software como serviço) sem servidor e paaS (plataforma como serviço) para adicionar redundância facilmente à sua carga de trabalho sem a necessidade de gerenciar operações de replicação ou failover de dados. Esses serviços implementam a redundância de forma transparente, o que remove a carga operacional de projetar e manter seus próprios mecanismos de redundância. Ao avaliar as opções de serviço, priorize os serviços gerenciados que lidam com a redundância automaticamente em relação a abordagens baseadas em infraestrutura que exigem configuração de redundância manual.

Os serviços gerenciados do Azure fornecem redundância por meio de modelos diferentes. Cada modelo fornece diferentes níveis de abstração e simplicidade operacional.

Serviços globais com redundância interna: Serviços como Microsoft Entra ID, DNS do Azure e Azure Key Vault operam como serviços globais com redundância automática em várias regiões. Esses serviços fornecem resiliência inerente sem a necessidade de qualquer configuração de redundância de você. Eles lidam automaticamente com cenários de failover e recuperação de forma transparente.

Modelos de capacidade abstraídos: Ofertas como o Azure Cosmos DB, o Azure Databricks e os pontos de extremidade gerenciados do Azure OpenAI abstraem a complexidade da infraestrutura subjacente por trás de unidades de capacidade, DTUs ou outras métricas lógicas. Esses serviços distribuem automaticamente sua carga de trabalho entre várias instâncias, zonas e regiões, apresentando um modelo simplificado de cobrança e gerenciamento. Especifique os requisitos de capacidade em vez de gerenciar instâncias redundantes individuais.

Ao arquitetar sua solução, avalie se existe uma opção de serviço gerenciado para cada componente antes de implementar a redundância baseada em infraestrutura. Os serviços gerenciados reduzem sua sobrecarga operacional e geralmente fornecem implementações de redundância mais robustas do que soluções personalizadas, embora possam envolver compensações no controle e custos potencialmente mais altos para cada unidade de capacidade.

Criar redundância em sua carga de trabalho com várias instâncias de componente

Implante várias instâncias de seus componentes e serviços de infraestrutura para alcançar a resiliência de que sua carga de trabalho precisa. Essa estratégia de redundância fundamental garante que, se uma instância falhar, outras instâncias poderão continuar a lidar com a carga de trabalho. Você pode obter várias instâncias por meio de abordagens diferentes. Alguns cenários exigem que você configure manualmente a redundância implantando vários recursos individualmente, como vários circuitos do Azure ExpressRoute ou configurando o Gerenciador de Tráfego do Azure em várias regiões. Outros serviços são projetados para dar suporte diretamente a várias instâncias, como definir conjuntos de dimensionamento de máquinas virtuais do Azure para cinco instâncias ou configurar o Serviço de Aplicativo do Azure para executar 10 instâncias. Quando possível, prefira serviços que fornecem suporte interno para várias instâncias e recursos de dimensionamento automático, pois simplificam o gerenciamento de redundância e podem responder às necessidades de confiabilidade e desempenho.

Ao implantar componentes de infraestrutura redundantes, determine quantas instâncias de cada componente atendem aos seus destinos de confiabilidade. Considere se você precisa de várias instâncias de todos os componentes ou apenas componentes críticos específicos e determine a distribuição geográfica dessas instâncias para atender aos seus requisitos de resiliência. Ao implantar uma infraestrutura redundante, considere as recomendações a seguir.

Recursos de computação:

• Prefira serviços que tenham suporte para redundância interna. Esses serviços permitem especificar o número de instâncias necessárias e podem lidar com a distribuição e o gerenciamento dessas instâncias para você.

• Mantenha sua camada de computação limpa de qualquer estado porque nós individuais que atendem solicitações podem ser excluídos, com falha ou substituídos a qualquer momento.

• Projete e teste sua estratégia de dimensionamento para corresponder à sua abordagem de redundância.

Recursos de dados:

• Replique dados em regiões geográficas para fornecer resiliência a interrupções regionais e falhas catastróficas.

• Entenda os recursos internos de replicação e redundância dos serviços de plataforma com estado que você usa.

• Determine se a replicação de dados síncrona ou assíncrona é necessária para a funcionalidade da carga de trabalho. Para obter mais informações, confira as Recomendações para usar zonas e regiões de disponibilidade.

• Distribua dados geograficamente, conforme suportado pelo serviço, para minimizar o efeito de falhas geograficamente localizadas.

• Automatize o failover após uma falha na instância do banco de dados. Você pode configurar o failover automatizado em vários serviços de dados de PaaS do Azure. O failover automatizado não é necessário para armazenamentos de dados que dão suporte a gravações de várias regiões, como o Azure Cosmos DB. Para obter mais informações, consulte Recomendações para criar uma estratégia de recuperação de desastre.

• Use o melhor armazenamento de dados para seus dados. Adote a persistência poliglota ou soluções que usam uma combinação de tecnologias de armazenamento de dados. Os dados incluem mais do que apenas dados persistentes do aplicativo. Ele também inclui logs de aplicativos, eventos, mensagens e caches.

• Considere os requisitos de consistência de dados e use a consistência eventual quando os requisitos permitirem. Quando os dados são distribuídos, use a coordenação apropriada para impor garantias de consistência fortes. A coordenação pode reduzir sua taxa de transferência e tornar seus sistemas firmemente acoplados, o que pode torná-los mais fracos. Por exemplo, se uma operação atualizar dois bancos de dados, em vez de colocá-lo em um único escopo de transação, será melhor se o sistema puder acomodar a consistência eventual.

• Dados de partição para disponibilidade. O particionamento de banco de dados melhora a escalabilidade e também pode melhorar a disponibilidade. Se um fragmento cair, os outros fragmentos ainda poderão ser acessados. Uma falha em um fragmento interrompe apenas um subconjunto do total de transações.

• Se a fragmentação não for uma opção, você poderá usar o padrão CQRS (Segregação de Responsabilidade de Consulta de Comando) para separar seus modelos de dados somente leitura e leitura. Adicione instâncias de banco de dados somente leitura mais redundantes para fornecer mais resiliência.

Recursos de rede:

• Decida sobre uma topologia de rede confiável e escalonável. Use um modelo hub-and-spoke ou um modelo de WAN Virtual do Azure para ajudá-lo a organizar sua infraestrutura de nuvem em padrões lógicos que facilitam a compilação e a escala do design de redundância.

• Selecione o serviço de rede apropriado para balancear e redirecionar solicitações dentro ou entre regiões. Use serviços de balanceamento de carga globais ou com redundância de zona quando possível para atender às suas metas de confiabilidade.

• Verifique se você alocou espaço de endereço IP suficiente em suas redes virtuais e sub-redes para considerar o uso planejado, incluindo requisitos de expansão.

• Verifique se o aplicativo pode ser dimensionado dentro dos limites de porta da plataforma de hospedagem de aplicativo escolhida. Se um aplicativo iniciar várias conexões TCP (Protocolo de Controle de Transmissão de Saída) ou UDP (User Datagram Protocol), ele poderá esgotar todas as portas disponíveis e causar um desempenho ruim do aplicativo.

• Escolha SKUs e configure serviços de rede que possam atender aos requisitos de largura de banda e disponibilidade. A taxa de transferência de um gateway de VPN varia de acordo com sua SKU. O suporte para redundância de zona só está disponível para algumas SKUs do balanceador de carga.

• Verifique se seu design para lidar com o DNS (Sistema de Nomes de Domínio) foi criado com foco na resiliência e dá suporte à infraestrutura redundante.

Usar o padrão selos de implantação para simplificar sua abordagem de redundância

Além da redundância para componentes e serviços de infraestrutura individuais, estenda sua estratégia de redundância para o nível de carga de trabalho implantando várias instâncias de toda a carga de trabalho ou grupos lógicos de recursos. Siga o padrão de design de Selos de Implantação para criar unidades repetíveis e autocontidas que incluem todos os recursos necessários para entregar sua carga de trabalho a um subconjunto específico de usuários ou requisitos.

Os selos de implantação representam uma mudança do nível do componente para a redundância no nível da carga de trabalho. Cada carimbo serve como uma unidade completa de escala que contém todos os recursos necessários — computação, armazenamento, rede e dependências — que podem operar de forma independente. Essa abordagem fornece os principais benefícios, incluindo domínios de falha isolados que contêm raio de explosão, dimensionamento horizontal por meio de implantação de selo adicional em vez de dimensionamento de componente individual, segmentação flexível por geografia ou requisitos e operações simplificadas por meio de unidades repetiíveis idênticas.

Se você implantar selos em um modelo ativo-ativo (em que todos os selos atendem ativamente ao tráfego simultaneamente) ou modelo ativo-passivo (em que um carimbo serve o tráfego enquanto outros permanecem em espera), projete cada selo para ser uma implantação completa e autossus suficiente que possa lidar com sua carga de trabalho designada de forma independente.

Obter tempo de inatividade zero por meio da redundância ativa-ativa

As implantações ativas-ativas maximizam a disponibilidade do serviço executando várias instâncias de uma carga de trabalho simultaneamente, cada uma manipulando ativamente o tráfego. Essa configuração garante o failover imediato, elimina o tempo de inatividade e otimiza o uso de recursos mantendo todas as instâncias produtivas. Se uma instância falhar, o tráfego será redirecionado automaticamente para instâncias íntegras sem interromper o serviço.

Por exemplo, uma plataforma de comércio eletrônico durante a alta temporada pode manter operações perfeitas mesmo se uma implantação encontrar problemas. As configurações ativas-ativas são ideais para cargas de trabalho críticas que exigem disponibilidade ininterrupta, mas têm custos de infraestrutura e complexidade mais altos. Estratégias operacionais avançadas são necessárias para gerenciar vários ambientes dinâmicos, garantir a consistência dos dados e coordenar atualizações em todas as instâncias.

As seções a seguir descrevem as opções de configuração para implantações ativas-ativas.

• Ativo-ativo na capacidade: Selos de implantação espelhados em dois ou mais locais, cada um configurado para lidar com cargas de trabalho de produção para o local ou locais que servem e escalonáveis para lidar com cargas de outros locais se ocorrer uma interrupção regional.

  • Rede: Use latência ou roteamento global ponderado para espalhar o tráfego entre os locais.

  • Replicação e consistência de dados: Use um armazenamento de dados distribuído globalmente, como o Azure Cosmos DB , para recursos de leitura e gravação de várias regiões. Para bancos de dados relacionais, use réplicas legíveis com cadeias de conexão somente leitura.

  • Vantagem desse design: Custos operacionais mais baixos do que um design superprovisionado.

  • Desvantagem desse design: Possível degradação da experiência do usuário ao escalar verticalmente para atender às demandas de uma carga completa se outro local sofrer uma interrupção.

• Superprovisionado ativo-ativo: Selos de implantação espelhados em dois ou mais locais, cada um sobreprovisionado para lidar com cargas de trabalho de produção para o local ou locais que servem e para lidar com cargas de outros locais se ocorrer uma interrupção regional.

  • Rede: Use latência ou roteamento global ponderado para espalhar o tráfego entre os locais.

  • Replicação e consistência de dados: Use um armazenamento de dados distribuído globalmente, como o Azure Cosmos DB , para recursos de leitura e gravação de várias regiões. Para bancos de dados relacionais, use réplicas legíveis com cadeias de conexão somente leitura.

  • Vantagem desse design: O design mais resiliente possível.

  • Desvantagem desse design: Custos operacionais mais altos do que um design escalonável.

• Vantagens comuns de ambos os designs: Alta resiliência e baixo risco de interrupção total da carga de trabalho.

• Desvantagens comuns de ambos os designs: Custos operacionais mais altos e carga de gerenciamento devido a vários fatores, incluindo a necessidade de gerenciar a sincronização de dados e estado do aplicativo.

Usar um design de arquitetura ativo-passivo para fornecer resiliência de RECUPERAÇÃO

As configurações de implantação ativo-passivo fornecem uma maneira econômica de garantir a recuperação de desastre executando uma instância primária que manipula todo o tráfego, mantendo as instâncias secundárias ociosas, mas prontas. Essas instâncias em espera são ativadas somente quando a instância primária falha ou passa por manutenção. Essa abordagem minimiza o uso de recursos ao fornecer recursos de failover confiáveis.

Por exemplo, uma plataforma de negociação financeira pode usar essa configuração para manter a continuidade do serviço. O sistema primário gerencia todas as transações, enquanto o sistema secundário permanece sincronizado em segundo plano. Se o sistema primário falhar, o sistema secundário assumirá rapidamente e restaurará as operações com interrupção mínima. Essa abordagem equilibra a confiabilidade e o custo, o que o torna ideal para cargas de trabalho que podem tolerar breves tempos de recuperação sem a complexidade ou a despesa de implantações ativas-ativas.

Considere as seguintes opções de configuração para implantações ativas-passivas.

• Sobressalente quente: Um local primário e um ou mais locais secundários. O local secundário é implantado com o mínimo possível de computação e dimensionamento de dados e execuções sem carga. Esse local é conhecido como um local de reposição quente . Após o failover, os recursos de computação e dados são dimensionados para lidar com a carga do local primário.

  • Rede: Use o roteamento global de prioridade .

  • Replicação e consistência de dados: Replique seu banco de dados para sua localização passiva e use os recursos de failover automático de soluções de PaaS, como o Azure Cosmos DB e o Banco de Dados SQL do Azure.

  • Vantagem desse design: Tempo de recuperação mais curto entre os designs ativo-passivos.

  • Desvantagem desse design: Maior custo operacional entre os designs ativo-passivos.

• Sobressalente frio: Um local primário e um ou mais locais secundários. O local secundário é dimensionado para lidar com a carga completa, mas todos os recursos de computação são interrompidos. Esse local é conhecido como um local de reposição frio . Você precisa iniciar os recursos antes do failover.

  • Rede: Use o roteamento global de prioridade .

  • Replicação e consistência de dados: Replique seu banco de dados para seu local passivo e use os recursos de failover automático de soluções de PaaS, como o Azure Cosmos DB e o Banco de Dados SQL.

  • Vantagem desse design: Custos operacionais mais baixos do que o design de sobressalente quente.

  • Desvantagem desse design: Tempo de recuperação mais longo do que o design de reposição quente.

Distribuir cargas de trabalho em uma infraestrutura independente próxima

Implantar cargas de trabalho em datacenters independentes ou setores de datacenter próximos fornece redundância sem comprometer o desempenho. Usando instalações geograficamente próximas, mas fisicamente separadas, essa configuração garante o isolamento de falhas com impacto mínimo de latência. Ele fornece a resiliência da infraestrutura distribuída, mantendo a capacidade de resposta de uma implantação de site único. No Azure, as zonas de disponibilidade fornecem essa funcionalidade. As zonas de disponibilidade são datacenters fisicamente independentes ou setores de datacenter projetados para permitir que você implante facilmente cargas de trabalho tolerantes a falhas e de baixa latência.

Para aplicativos sensíveis à latência, como jogos em tempo real, essa abordagem permite failover contínuo e experiência ininterrupta do usuário. Os servidores de jogos distribuídos entre datacenters locais podem redirecionar instantaneamente o tráfego durante interrupções, com balanceamento de carga transparente e replicação de dados quase em tempo real preservando a continuidade do jogo. No entanto, essa estratégia oferece algum risco porque eventos regionais em larga escala ainda podem afetar todos os sites simultaneamente.

Fortalecer a tolerância a falhas com implantações geo distantes

A implantação entre datacenters distribuídos geograficamente fornece a proteção mais forte contra desastres em larga escala, espalhando cargas de trabalho entre regiões a centenas ou milhares de quilômetros de distância. Essa abordagem garante a continuidade dos negócios durante eventos como desastres naturais, falhas de infraestrutura ou interrupções geopolíticas que podem afetar áreas metropolitanas inteiras. No Azure, você pode implantar cargas de trabalho em regiões, que são distribuídas por todo o mundo. Ao usar essa abordagem de design, escolha regiões próximas aos seus usuários, mas que estejam geograficamente distantes, como Oeste dos EUA e Leste dos EUA.

Por exemplo, uma plataforma financeira global pode manter o serviço ininterrupto roteando o tráfego para regiões não afetadas se uma área sofrer uma grande interrupção. Essa abordagem maximiza a resiliência e dá suporte à conformidade regulatória entre jurisdições, mas introduz maior latência, requisitos complexos de consistência de dados e aumento da sobrecarga operacional. Você deve pesar esses fatores cuidadosamente em relação aos benefícios da redundância global.

Facilitação do Azure

A plataforma do Azure ajuda você a otimizar a resiliência da carga de trabalho e adicionar redundância executando as seguintes ações:

• Ajuda você a selecionar as melhores regiões do Azure para sua arquitetura de várias regiões com o guia Selecionar Regiões do Azure.

• Fornece redundância interna com muitas soluções de PaaS e SaaS, algumas das quais são configuráveis.

• Fornece serviços gerenciados globais, como a ID do Microsoft Entra, o DNS do Azure e o Key Vault que implementam a redundância de forma transparente sem a necessidade de configuração.

• Permite que você projete e implemente a redundância intra-região usando zonas de disponibilidade e redundância entre regiões.

• Fornece soluções de computação com redundância de zona, como Conjuntos de Dimensionamento de Máquinas Virtuais, que podem espalhar automaticamente sua computação uniformemente entre zonas de disponibilidade ao implantar VMs (máquinas virtuais).

• Fornece serviços de balanceamento de carga com reconhecimento de réplica, como o Gateway de Aplicativo do Azure, o Azure Front Door e o Azure Load Balancer.

• Fornece soluções de replicação geográfica facilmente implementadas, como replicação geográfica ativa para o Banco de Dados SQL. Implemente a distribuição global e a replicação transparente usando o Azure Cosmos DB. O Azure Cosmos DB fornece duas opções para lidar com gravações conflitantes. Escolha a melhor opção para sua carga de trabalho.

• Fornece recursos de PITR (restauração pontual) para muitos serviços de dados paaS.

• Reduz o esgotamento da porta por meio do Gateway nat do Azure ou do Firewall do Azure.

Facilitação do Azure específica do DNS

• Para cenários internos de resolução de nomes, use zonas privadas DNS do Azure, que têm redundância de zona interna e redundância geográfica. Para obter mais informações, consulte a resiliência da zona privada DNS do Azure.

• Para cenários de resolução de nomes externos, use zonas públicas DNS do Azure, que têm redundância de zona interna e redundância geográfica.

• Os serviços DNS públicos e privados do Azure são serviços globais resilientes a interrupções regionais porque os dados de zona estão disponíveis globalmente.

• Para cenários de resolução de nomes híbridos entre ambientes locais e de nuvem, use o Resolvedor Privado DNS do Azure. Esse serviço dá suporte à redundância de zona se sua carga de trabalho estiver localizada em uma região que dê suporte a zonas de disponibilidade. Uma interrupção em toda a zona não requer nenhuma ação durante a recuperação de zona. O serviço se auto-cura automaticamente e reequilibra para aproveitar a zona íntegra. Para obter mais informações, consulte Resiliência no Resolvedor Privado DNS do Azure.

• Para eliminar um único ponto de falha e obter uma resolução de nome híbrido mais resiliente entre regiões, implante dois ou mais resolvedores privados de DNS do Azure em diferentes regiões. O failover de DNS, em um cenário de encaminhamento condicional, é obtido atribuindo um resolvedor como seu servidor DNS primário. Atribua o outro resolvedor em uma região diferente como um servidor DNS secundário. Para obter mais informações, consulte Configurar o failover de DNS usando resolvedores privados.

Example

Para obter um exemplo de uma implantação redundante de várias regiões, consulte o aplicativo Web com redundância de zona altamente disponível na linha de base.

O diagrama a seguir mostra outro exemplo.

Links relacionados

Para saber mais sobre redundância, confira os seguintes recursos:

• Guia de regiões do Azure
• Redundância de Armazenamento do Azure
• Armazenamento com redundância de zona
• Replicação geográfica ativa do Banco de Dados SQL
• Configurar a replicação entre duas instâncias gerenciadas

Lista de verificação de confiabilidade

Consulte o conjunto completo de recomendações.