Recomendações para projetar para redundância

  • Artigo

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

RE:05 Adicione redundância em diferentes níveis, especialmente para fluxos críticos. Aplique redundância às camadas de computação, dados, rede e outras camadas de infraestrutura de acordo com as metas de confiabilidade identificadas.

Guias relacionados:Design | multirregional altamente disponívelUsando zonas e regiões de disponibilidade

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 à 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 se basear. 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

Termo Definição
Redundância A implementação de várias instâncias idênticas de um componente de carga de trabalho.
Persistência poliglota O conceito de usar tecnologias de armazenamento diferentes pelo mesmo aplicativo ou solução para aproveitar os melhores recursos de cada componente.
Consistência de dados A medida de como em sincronia ou fora de sincronia um determinado conjunto de dados está em vários repositórios.
Particionamento 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 dá suporte a várias instâncias de armazenamento com um esquema comum. Os dados não são replicados em todas as instâncias.

Principais estratégias de design

No contexto de 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 necessárias para a redundância de cada fluxo.

Por exemplo, você pode ter vários nós de servidor Web em execução ao mesmo tempo. A criticalidade do fluxo que eles dão suporte pode exigir que todas elas tenham réplicas prontas para aceitar o tráfego se houver um problema que afete todo o pool, por exemplo, uma interrupção regional. Como alternativa, como problemas de 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é que você resolve 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 maneira 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 sobressalente 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ê distribuir o tráfego entre dois nós para desempenho e ambos forem executados com 60% de utilização e um nó falhar, o nó restante correrá o risco de ficar sobrecarregado porque não pode operar em 120%. Espalhe 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 examinar regularmente sua arquitetura para garantir que você esteja gerenciando os custos, especialmente quando você usa o excesso de provisionamento. Quando você usa o superprovisionamento como uma estratégia de resiliência, equilibre-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 em um alto grau de redundância. Por exemplo, os recursos que se espalham entre zonas ou regiões 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. Os designs de redundância específicos do fluxo podem potencialmente introduzir complexidade no design geral.

Design de arquitetura redundante

Considere duas abordagens ao criar uma arquitetura redundante: ativo-ativo ou ativo-passivo. Escolha sua abordagem dependendo da criticalidade do fluxo do usuário e do fluxo do sistema ao qual os componentes de infraestrutura dão suporte. Em termos de confiabilidade, um design ativo-ativo de várias regiões ajuda você a alcançar o nível mais alto de confiabilidade possível, mas é significativamente mais caro do que um design ativo-passivo. Decidir as regiões geográficas apropriadas se torna a próxima opção crítica. Você também pode usar essas abordagens de design para uma única região usando zonas de disponibilidade. Para obter mais informações, consulte Recomendações para design de várias regiões altamente disponível.

Selos de implantação e unidades de escala

Se você implantar em um modelo ativo-ativo ou ativo-passivo, siga o padrão de design selos de implantação para garantir que você implante sua carga de trabalho de maneira repetível e escalonável. Os selos de implantação são os agrupamentos de recursos necessários para entregar sua carga de trabalho a um determinado subconjunto de seus clientes. Por exemplo, o subconjunto pode ser um subconjunto regional ou um subconjunto com todos os mesmos requisitos de privacidade de dados que sua carga de trabalho. Pense em cada selo como uma unidade de escala que você pode duplicar para dimensionar sua carga de trabalho horizontalmente ou para executar implantações azul-verde. Projete sua carga de trabalho com selos de implantação para otimizar sua implementação ativa-ativa ou ativa-passiva para resiliência e carga de gerenciamento. O planejamento de expansão de várias regiões também é importante para superar possíveis restrições de capacidade de recursos temporários em uma região.

Zonas de disponibilidade em regiões do Azure

Se você implantar um design ativo-ativo ou ativo-passivo, aproveite as zonas de disponibilidade dentro das regiões ativas para otimizar totalmente sua resiliência. Muitas regiões do Azure fornecem várias zonas de disponibilidade, que são grupos separados de data centers em uma região. Dependendo do serviço do Azure, você pode aproveitar as zonas de disponibilidade implantando elementos da carga de trabalho com redundância entre zonas ou fixando elementos em zonas específicas. Para obter mais informações, consulte Recomendações para usar zonas e regiões de disponibilidade.

Diretrizes de camada de infraestrutura

Recursos de computação

  • Escolha o serviço de computação apropriado para sua carga de trabalho. Dependendo do tipo de carga de trabalho que você projeta, pode haver várias opções disponíveis. Pesquise os serviços disponíveis e entenda quais tipos de cargas de trabalho funcionam melhor em um determinado serviço de computação. Por exemplo, as cargas de trabalho sap normalmente são mais adequadas para serviços de computação iaaS (infraestrutura como serviço). Para um aplicativo em contêineres, determine a funcionalidade específica sobre a qual você precisa ter controle para determinar se deve usar Serviço de Kubernetes do Azure (AKS) ou uma solução de PaaS (plataforma como serviço). Sua plataforma de nuvem gerencia totalmente um serviço de PaaS.

  • Use opções de computação de PaaS se seus requisitos permitirem. O Azure gerencia totalmente os serviços de PaaS, o que reduz a carga de gerenciamento e um grau documentado de redundância é interno.

  • Use o Azure Conjuntos de Dimensionamento de Máquinas Virtuais se precisar implantar VMs (máquinas virtuais). Com Conjuntos de Dimensionamento de Máquinas Virtuais, você pode distribuir automaticamente sua computação uniformemente entre zonas de disponibilidade.

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

  • Use serviços com redundância de zona sempre que possível para fornecer maior resiliência sem aumentar sua carga operacional.

  • Superprovisione recursos críticos para atenuar falhas de instâncias redundantes, mesmo antes do início das operações de dimensionamento automático, para que o sistema continue operando após uma falha de componente. Calcule o efeito aceitável de uma falha ao incorporar o superprovisionamento em seu design de redundância. Assim como acontece com seu processo de tomada de decisão de redundância, suas metas de confiabilidade e decisões de compensação financeira determinam a extensão em que você adiciona capacidade de reposição com o excesso de provisionamento. O excesso de provisionamento refere-se especificamente à expansão, o que significa adicionar instâncias extras de um determinado tipo de recurso de computação, em vez de aumentar os recursos de computação de qualquer instância única. Por exemplo, se você alterar uma VM de um SKU de camada inferior para um SKU de camada superior.

  • Implante os serviços de IaaS manualmente ou por meio da automação em cada zona de disponibilidade ou região na qual você pretende implementar sua solução. Alguns serviços de PaaS têm recursos internos que são replicados automaticamente entre zonas e regiões de disponibilidade.

Recursos de dados

  • Determine se a replicação de dados síncrona ou assíncrona é necessária para a funcionalidade da carga de trabalho. Para ajudá-lo a fazer essa determinação, consulte Recomendações para usar zonas e regiões de disponibilidade.

  • Considere a taxa de crescimento de seus dados. Para planejamento de capacidade, planeje o crescimento de dados, a retenção de dados e o arquivamento para garantir que seus requisitos de confiabilidade sejam atendidos à medida que a quantidade de dados em sua solução aumentar.  

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

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

  • 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 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. Eles também incluem logs de aplicativo, 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 frágeis. 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.

  • Particione dados para disponibilidade. O particionamento de banco de dados melhora a escalabilidade e também pode melhorar a disponibilidade. Se um fragmento ficar inativo, 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 (Separação de Responsabilidade de Comando e Consulta) 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.  

  • Entenda os recursos internos de replicação e redundância dos serviços de plataforma com estado que você usa. Para obter recursos de redundância específicos de serviços de dados com estado, consulte Links relacionados.

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 aplicativos escolhida. Se um aplicativo iniciar várias conexões TCP ou UDP de saída, ele poderá esgotar todas as portas disponíveis e causar baixo desempenho do aplicativo.

  • Escolha SKUs e configure serviços de rede que podem atender aos seus 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 alguns SKUs do balanceador de carga.

  • Verifique se o design para lidar com o DNS foi criado com foco na resiliência e dá suporte à infraestrutura redundante.

Facilitação do Azure

A plataforma do Azure ajuda você a otimizar a resiliência da carga de trabalho e adicionar redundância:

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 Resiliência de zona privada do 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 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 Resolvedor Privado de 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 recupera automaticamente e reequilibra para aproveitar a zona íntegra. Para obter mais informações, consulte Resiliência no Resolvedor Privado de DNS do Azure.

  • Para eliminar um ponto único 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 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 o failover de DNS usando resolvedores privados.

Exemplo

Para obter um exemplo de uma implantação redundante de várias regiões, consulte Aplicativo Web com redundância de zona altamente disponível na 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, confira os seguintes recursos:

Lista de verificação de confiabilidade

Consulte o conjunto completo de recomendações.

Lista de verificação de confiabilidade