Partilhar via


Estratégias de arquitetura para projetar redundância

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

RE:05 Adicione redundância em diferentes níveis, especialmente para fluxos críticos, para ajudar a atingir suas metas de confiabilidade. Considere componentes de infraestrutura redundantes, como computação e rede, e várias instâncias de sua solução.

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 suas metas de confiabilidade definidas aplicando os níveis adequados de redundância à computação, aos dados, à rede e a outras camadas de infraestrutura. Aplique essa redundância para dar à sua carga de trabalho uma base sólida e confiável na qual se basear. Quando você cria sua carga de trabalho sem redundância de infraestrutura, há um alto risco de tempo de inatividade prolongado devido a possíveis falhas.

Definições

Term Definition
Redundancy A implementação de várias instâncias idênticas de um componente de carga de trabalho.
Região Um local de datacenter do Azure.
Persistência poliglota O conceito de usar diferentes tecnologias de armazenamento pelo mesmo aplicativo ou solução para aproveitar os melhores recursos de cada componente.
Consistência de dados A medida de como um determinado conjunto de dados está sincronizado ou fora de sincronia em vários armazenamentos.
Partitioning O processo de divisão física de dados em armazenamentos de dados separados.
Fragmento Uma estratégia de particionamento horizontal de banco de dados que oferece suporte a várias instâncias de armazenamento com um esquema comum. Os dados não são replicados em todas as instâncias.

No contexto da confiabilidade, use a 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 metas de confiabilidade para tomar decisões informadas que são 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 suportam for crítico, todos os nós podem precisar de réplicas que possam aceitar tráfego imediatamente se um problema afetar todo o pool, como uma interrupção completa do datacenter. Como alternativa, como problemas em grande 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é resolver o problema.

Ao projetar para redundância no contexto da eficiência de desempenho, distribua a carga entre vários nós redundantes para garantir que cada nó tenha um desempenho ideal. No contexto da confiabilidade, crie capacidade ociosa para absorver falhas ou avarias que afetem um ou mais nós. Certifique-se de que a capacidade ociosa possa absorver falhas durante todo o tempo necessário para recuperar os nós afetados. Com esta distinção em mente, ambas as estratégias têm de funcionar em conjunto. Se você distribuir o tráfego entre dois nós para desempenho e ambos forem executados a 60% de utilização e um nó falhar, o nó restante correrá o risco de ficar sobrecarregado porque não pode operar a 120%. Divida a carga com outro nó para garantir que suas metas de desempenho e confiabilidade sejam mantidas.

Compensações:

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

  • Pode haver compensações de desempenho quando você cria um alto grau de redundância. Por exemplo, recursos espalhados por zonas ou locais de disponibilidade 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. Projetos de redundância específicos de fluxo podem potencialmente introduzir complexidade no projeto 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 de grande escala, como um desastre geográfico, que coloca todas as instâncias offline. Um ambiente de recuperação de desastres (DR) geodistante ajuda a mitigar esse risco, mas aumenta os custos.

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

Aproveite as soluções de software como serviço (SaaS) e plataforma como serviço (PaaS) sem servidor 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 redundância de forma transparente, o que elimina 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 redundância automaticamente em relação às abordagens baseadas em infraestrutura que exigem configuração manual de redundância.

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

Serviços globais com redundância integrada: Serviços como Microsoft Entra ID, Azure DNS 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 exigir 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 Azure Cosmos DB, Azure Databricks e 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 em várias instâncias, zonas e regiões, ao mesmo tempo em que apresentam um modelo simplificado de faturamento e gerenciamento. Você especifica 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.

Crie redundância em sua carga de trabalho com várias instâncias de componentes

Implante várias instâncias de seus componentes e serviços de infraestrutura para obter a resiliência de que sua carga de trabalho precisa. Essa estratégia fundamental de redundância garante que, se uma instância falhar, outras instâncias possam continuar a lidar com a carga de trabalho. Você pode obter várias instâncias por meio de diferentes abordagens. 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 a várias instâncias diretamente, como definir Conjuntos de Escala de Máquina Virtual 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 forneçam 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 satisfazem suas metas 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 incorporado. Esses serviços permitem que você especifique o número de instâncias necessárias e pode lidar com a distribuição e o gerenciamento dessas instâncias para você.

  • Mantenha sua camada de computação limpa de qualquer estado , pois nós individuais que atendem solicitações podem ser excluídos, com defeito 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 entre regiões geográficas para fornecer resiliência a interrupções regionais e falhas catastróficas.

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

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

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

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

  • 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 de aplicativos persistentes. Ele também inclui logs de aplicativos, eventos, mensagens e caches.

  • Considere os requisitos de consistência de dados e use consistência eventual quando os requisitos permitirem. Quando os dados são distribuídos, use a coordenação apropriada para impor fortes garantias de consistência. 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 atualiza dois bancos de dados, em vez de colocá-la em um único escopo de transação, é melhor se o sistema puder acomodar uma eventual consistência.

  • Particione dados para disponibilidade. O particionamento de banco de dados melhora a escalabilidade e também pode melhorar a disponibilidade. Se um fragmento descer, os outros fragmentos ainda são alcançáveis. Uma falha em um fragmento apenas interrompe um subconjunto do total de transações.

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

Recursos de rede:

  • Decida sobre uma topologia de rede confiável e escalá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 tornam seu design de redundância mais fácil de criar e dimensionar.

  • Selecione o serviço de rede apropriado para equilibrar e redirecionar solicitações dentro ou entre regiões. Use serviços de balanceamento de carga com redundância global ou de região sempre que possível para atingir suas metas de confiabilidade.

  • Certifique-se de ter alocado espaço de endereço IP suficiente em suas redes virtuais e sub-redes para levar em conta o uso planejado, incluindo os requisitos de expansão.

  • Certifique-se de que o aplicativo possa ser dimensionado dentro dos limites de porta da plataforma de hospedagem de aplicativos escolhida. Se um aplicativo iniciar várias conexões TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol) de saída, ele poderá esgotar todas as portas disponíveis e causar um desempenho insatisfatório do aplicativo.

  • Escolha SKUs e configure serviços de rede que possam atender aos seus requisitos de largura de banda e disponibilidade. A taxa de transferência de um gateway 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.

  • Certifique-se de que seu projeto para lidar com o Sistema de Nomes de Domínio (DNS) seja construído com foco na resiliência e ofereça suporte à infraestrutura redundante.

Use 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 sua carga de trabalho ou grupos lógicos de recursos. Siga o padrão de design Selos de Implantação para criar unidades repetíveis e independentes que incluem todos os recursos necessários para entregar sua carga de trabalho a um subconjunto específico de usuários ou requisitos.

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

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

Alcance zero tempo de inatividade por meio de 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 lidando ativamente com o tráfego. Essa configuração garante 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á automaticamente redirecionado 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 que uma implantação encontre problemas. As configurações ativo-ativo são ideais para cargas de trabalho de missão crítica que exigem disponibilidade ininterrupta, mas têm custos de infraestrutura e complexidade mais altos. São necessárias estratégias operacionais avançadas para gerenciar vários ambientes dinâmicos, garantir a consistência dos dados e coordenar as atualizações em todas as instâncias.

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

  • Ativo-ativo na capacidade: Carimbos 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 eles atendem e escalável para lidar com cargas de outros locais se ocorrer uma interrupção regional.

    • Ligação em rede: Use latência ou roteamento global ponderado para distribuir 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 em várias regiões. Para bancos de dados relacionais, use réplicas legíveis com cadeias de conexão somente leitura.

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

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

  • Sobreprovisionado ativo-ativo: Carimbos de implantação espelhados em dois ou mais locais, cada um superprovisionado para lidar com cargas de trabalho de produção para o local ou locais que eles atendem e para lidar com cargas de outros locais se ocorrer uma interrupção regional.

    • Ligação em rede: Use latência ou roteamento global ponderado para distribuir 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 em várias regiões. Para bancos de dados relacionais, use réplicas legíveis com cadeias de conexão somente leitura.

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

    • Desvantagem deste design: Custos operacionais mais altos do que um design escalável.

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

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

Use um design de arquitetura ativo-passivo como uma abordagem de DR econômica

As configurações de implantação ativo-passivo fornecem uma maneira econômica de garantir a DR executando uma instância primária que lida com 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 e, ao mesmo tempo, fornece recursos confiáveis de failover.

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 cair, o sistema secundário rapidamente assume e restaura as operações com o mínimo de interrupção. Essa abordagem equilibra confiabilidade e custo, o que a torna ideal para cargas de trabalho que podem tolerar breves tempos de recuperação sem a complexidade ou a despesa de implantações ativas.

Considere as seguintes opções de configuração para implantações ativo-passivo.

  • 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 é executado sem carga. Este local é conhecido como um local de reserva quente . Após o failover, os recursos de computação e dados são dimensionados para lidar com a carga do local principal.

    • Ligação em rede: Use o roteamento global prioritário .

    • 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 PaaS, como o Azure Cosmos DB e o Banco de Dados SQL do Azure.

    • Vantagem deste design: Menor tempo de recuperação entre os projetos ativo-passivo.

    • Desvantagem deste design: Maior custo operacional entre os projetos ativo-passivo.

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

    • Ligação em rede: Use o roteamento global prioritário .

    • 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 PaaS, como o Azure Cosmos DB e o Banco de Dados SQL.

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

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

Distribuir cargas de trabalho pela infraestrutura independente próxima

A implantação de cargas de trabalho em datacenters ou setores de datacenters independentes 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 na latência. Ele fornece a resiliência da infraestrutura distribuída, mantendo a capacidade de resposta de uma implantação em um único local. No Azure, as zonas de disponibilidade fornecem essa funcionalidade. As zonas de disponibilidade são datacenters ou setores de datacenter fisicamente independentes 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 de usuário ininterrupta. Os servidores de jogos distribuídos por 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, esta estratégia comporta alguns riscos, uma vez que os eventos regionais de grande escala ainda podem afetar todos os locais em simultâneo.

Fortaleça a tolerância a falhas com implantações geodistantes

A implantação em datacenters geograficamente distribuídos oferece a proteção mais forte contra desastres de grande escala, distribuindo cargas de trabalho por 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 estão espalhadas pelo mundo. Ao usar essa abordagem de design, escolha regiões próximas aos usuários, mas geograficamente distantes, como Oeste dos EUA e Leste dos EUA.

Por exemplo, uma plataforma financeira global pode manter um 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 oferece suporte à conformidade regulatória em todas as jurisdições, mas introduz maior latência, requisitos complexos de consistência de dados e maior sobrecarga operacional. Você deve pesar esses fatores cuidadosamente em relação aos benefícios da redundância global.

Gestão do Azure

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

Facilitação do Azure específica do DNS

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

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

  • Os serviços DNS do Azure públicos e privados são serviços globais que são 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 de DNS do Azure. Este serviço suporta redundância de zona se a sua carga de trabalho estiver localizada numa região que suporte zonas de disponibilidade. Uma interrupção em toda a zona não requer nenhuma ação durante a recuperação da zona. O serviço auto-cura e reequilibra-se automaticamente para tirar partido da zona saudável. Para obter mais informações, consulte Resiliência no Resolvedor Privado de DNS do Azure.

  • Para eliminar um único ponto de falha e obter uma resolução de nomes híbridos mais resiliente entre regiões, implante dois ou mais resolvedores privados de DNS do Azure em regiões diferentes. 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 failover de DNS usando resolvedores privados.

Aplicar proteção contra exclusão para preservar a redundância

A redundância só ajuda se os componentes que a fornecem permanecerem no lugar. A exclusão acidental de um armazenamento de dados, zona DNS ou camada de roteamento de tráfego colapsa a resiliência e força ações de recuperação total. Reduza o raio de explosão de erro humano aplicando bloqueios CanNotDelete do recurso do Azure.

Compensação: A aplicação de bloqueios retarda as ações legítimas de recuperação e pode criar atrito operacional. Os bloqueios bloqueiam a exclusão de recursos, não alterações ou dados dentro do recurso. Considere os bloqueios como uma camada fina de segurança que complementa, nunca substitui, os backups, a replicação e a governança de acesso.

Example

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

O diagrama a seguir mostra outro exemplo.

Diagrama que mostra a arquitetura da implementação de referência.

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

Lista de verificação de fiabilidade

Consulte o conjunto completo de recomendações.