Recomendações para conceber redundância

  • Artigo

Aplica-se a esta recomendação de 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 aos escalões de computação, dados, rede e outras infraestruturas de acordo com os destinos de fiabilidade identificados.

Guias relacionados:Design multi-regional | de elevada disponibilidadeCom zonas de disponibilidade e regiões

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. Cumpra os requisitos dos seus destinos de fiabilidade definidos ao aplicar os níveis adequados de redundância à computação, aos dados, à rede e a outras camadas de infraestrutura. Aplique esta redundância para dar à carga de trabalho uma base forte e fiável para se basear. Quando cria a carga de trabalho sem redundância da infraestrutura, existe um alto risco de tempo de inatividade prolongado devido a potenciais 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 utilizar diferentes tecnologias de armazenamento pela mesma aplicação ou solução para tirar partido das melhores capacidades de cada componente.
Consistência de dados A medida de como, em sincronização ou dessincronizada, um determinado conjunto de dados está em vários arquivos.
Criação de partições O processo de divisão física de dados em arquivos de dados separados.
Partição horizontal Uma estratégia de criação de partições de base de dados horizontal que suporta 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 da fiabilidade, utilize a redundância para conter problemas que afetam um único recurso e certifique-se de que esses problemas não afetam a fiabilidade de todo o sistema. Utilize as informações que identificou sobre os fluxos críticos e os destinos de fiabilidade para tomar decisões informadas necessárias para a redundância de cada fluxo.

Por exemplo, pode ter vários nós de servidor Web em execução ao mesmo tempo. A importância do fluxo que suportam pode exigir que todas tenham réplicas prontas para aceitar o tráfego se existir um problema que afete todo o conjunto, por exemplo, uma indisponibilidade regional. Em alternativa, uma vez que os problemas em grande escala são raros e é dispendioso implementar um conjunto inteiro de réplicas, pode implementar um número limitado de réplicas para que o fluxo funcione num estado degradado até resolver o problema.

Quando conceber a redundância no contexto da eficiência de desempenho, distribua a carga por vários nós redundantes para garantir que cada nó tem um desempenho ideal. No contexto da fiabilidade, crie uma capacidade sobressalente para absorver falhas ou avarias que afetam um ou mais nós. Certifique-se de que a capacidade sobressalente pode 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 espalhar tráfego por dois nós para desempenho e ambos forem executados com 60% de utilização e um nó falhar, o nó restante corre o risco de ficar sobrecarregado porque não pode funcionar a 120%. Espalhe a carga com outro nó para garantir que os destinos de desempenho e fiabilidade são mantidos.

Vantagens:

  • Mais redundância de cargas de trabalho equivale a mais custos. Considere cuidadosamente adicionar redundância e reveja regularmente a sua arquitetura para garantir que está a gerir os custos, especialmente quando utiliza o sobreaprovisionamento. Quando utiliza o sobreaprovisionamento como uma estratégia de resiliência, equilibre-a com uma estratégia de dimensionamento bem definida para minimizar as ineficiências de custos.
  • Pode haver desvantagens de desempenho quando cria um elevado grau de redundância. Por exemplo, os recursos distribuídos por zonas ou regiões de disponibilidade podem afetar o desempenho porque tem de enviar tráfego através de ligações de latência elevada entre recursos redundantes, como servidores Web ou instâncias de base de dados.
  • Diferentes fluxos na mesma carga de trabalho podem ter requisitos de fiabilidade diferentes. Os designs de redundância específicos do fluxo podem potencialmente introduzir complexidade na conceção geral.

Design de arquitetura redundante

Considere duas abordagens quando conceber uma arquitetura redundante: ativo-ativo ou ativo-passivo. Escolha a sua abordagem consoante a importância do fluxo de utilizador e do fluxo de sistema que os componentes da infraestrutura suportam. Em termos de fiabilidade, um design ativo-ativo de várias regiões ajuda-o a alcançar o nível mais elevado de fiabilidade possível, mas é significativamente mais caro do que um design ativo-passivo. Decidir as regiões geográficas adequadas torna-se a próxima escolha crítica. Também pode utilizar estas abordagens de estrutura para uma única região através de zonas de disponibilidade. Para obter mais informações, veja Recomendações para a conceção de várias regiões de elevada disponibilidade.

Selos de implementação e unidades de dimensionamento

Quer implemente num modelo ativo-ativo ou ativo-passivo, siga o padrão de estrutura dos Selos de Implementação para garantir que implementa a carga de trabalho de forma repetível e dimensionável. Os selos de implementação são os agrupamentos de recursos necessários para entregar a carga de trabalho a um determinado subconjunto dos seus clientes. Por exemplo, o subconjunto pode ser um subconjunto regional ou um subconjunto com todos os mesmos requisitos de privacidade de dados que a carga de trabalho. Pense em cada selo como uma unidade de escala que pode duplicar para dimensionar a carga de trabalho horizontalmente ou para efetuar implementações verde-azulada. Crie a carga de trabalho com selos de implementação para otimizar a sua implementação ativa-ativa ou ativa-passiva para resiliência e carga de gestão. O planeamento do aumento horizontal de várias regiões também é importante para ultrapassar potenciais restrições temporárias de capacidade de recursos numa região.

Zonas de disponibilidade nas regiões do Azure

Quer implemente um design ativo-ativo ou ativo-passivo, tire partido das zonas de disponibilidade nas regiões ativas para otimizar totalmente a sua resiliência. Muitas regiões do Azure fornecem várias zonas de disponibilidade, que são grupos separados de datacenters numa região. Consoante o serviço do Azure, pode tirar partido das zonas de disponibilidade ao implementar elementos da carga de trabalho redundantemente entre zonas ou afixar elementos a zonas específicas. Para obter mais informações, veja Recomendações para utilizar zonas de disponibilidade e regiões.

Documentação de orientação sobre a camada de infraestrutura

Recursos de computação

  • Escolha o serviço de computação adequado para a carga de trabalho. Dependendo do tipo de carga de trabalho que conceber, poderão existir várias opções disponíveis. Pesque os serviços disponíveis e compreenda que tipos de cargas de trabalho funcionam melhor num determinado serviço de computação. Por exemplo, as cargas de trabalho SAP são normalmente mais adequadas para serviços de computação de infraestrutura como serviço (IaaS). Para uma aplicação em contentores, determine a funcionalidade específica sobre a qual precisa de ter controlo para determinar se deve utilizar Azure Kubernetes Service (AKS) ou uma solução de plataforma como serviço (PaaS). A plataforma cloud gere totalmente um serviço PaaS.

  • Utilize as opções de computação PaaS se os seus requisitos o permitirem. O Azure gere totalmente os serviços PaaS, o que reduz os encargos de gestão e é incorporado um grau documentado de redundância.

  • Utilize o Azure Conjuntos de Dimensionamento de Máquinas Virtuais se precisar de implementar máquinas virtuais (VMs). Com Conjuntos de Dimensionamento de Máquinas Virtuais, pode distribuir automaticamente a computação uniformemente pelas zonas de disponibilidade.

  • Mantenha a camada de computação limpa de qualquer estado porque os nós individuais que servem pedidos podem ser eliminados, falhados ou substituídos em qualquer altura.

  • Utilize serviços com redundância entre zonas sempre que possível para proporcionar maior resiliência sem aumentar a carga operacional.

  • Recursos críticos de sobreaprovisionamento para mitigar falhas de instâncias redundantes, mesmo antes do início das operações de dimensionamento automático, pelo que o sistema continua a funcionar após uma falha do componente. Calcule o efeito aceitável de uma falha ao incorporar o sobreaprovisionamento na estrutura de redundância. Tal como acontece com o seu processo de tomada de decisão de redundância, os seus objetivos de fiabilidade e decisões de contrapartida financeira determinam a extensão em que adiciona capacidade sobressalente com o sobreaprovisionamento. O sobreaprovisionamento refere-se especificamente ao aumento horizontal, o que significa adicionar instâncias adicionais de um determinado tipo de recurso de computação, em vez de aumentar as capacidades de computação de qualquer instância individual. Por exemplo, se alterar uma VM de um SKU de escalão inferior para um SKU de camada superior.

  • Implemente os serviços IaaS manualmente ou através da automatização em cada zona ou região de disponibilidade na qual pretende implementar a sua solução. Alguns serviços PaaS têm capacidades incorporadas que são replicadas automaticamente em 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 o ajudar a fazer esta determinação, veja Recomendações para utilizar zonas de disponibilidade e regiões.

  • Considere a taxa de crescimento dos seus dados. Para planeamento de capacidade, planeie o crescimento de dados, a retenção de dados e o arquivo para garantir que os seus requisitos de fiabilidade são cumpridos à medida que a quantidade de dados na sua solução aumenta.  

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

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

  • Automatizar a ativação pós-falha após uma falha da instância da base de dados. Pode configurar a ativação pós-falha automatizada em vários serviços de dados PaaS do Azure. A ativação pós-falha automatizada não é necessária para arquivos de dados que suportem escritas em várias regiões, como o Azure Cosmos DB. Para obter mais informações, veja Recomendações para conceber uma estratégia de recuperação após desastre.

  • Utilize o melhor arquivo de dados para os seus dados. Abrace a persistência poliglota ou soluções que utilizam uma combinação de tecnologias de arquivo de dados. Os dados incluem mais do que apenas dados de aplicações persistentes. Também incluem as caches, as mensagens, os eventos e os registos da aplicação.

  • Considere os requisitos de consistência de dados e utilize a consistência eventual quando os requisitos o permitirem. Quando os dados são distribuídos, utilize a coordenação adequada para impor garantias de consistência fortes. A coordenação pode reduzir o débito e tornar os seus sistemas fortemente acoplados, o que pode torná-los mais frágeis. Por exemplo, se uma operação atualizar duas bases de dados, em vez de colocá-la num único âmbito de transação, é melhor que o sistema consiga acomodar a consistência eventual.

  • Dados de partição para disponibilidade. A criação de partições de bases de dados melhora a escalabilidade e também pode melhorar a disponibilidade. Se uma partição horizontal se desativar, as outras partições horizontais continuam acessíveis. Uma falha numa partição horizontal apenas interrompe um subconjunto do total de transações.

  • Se a fragmentação não for uma opção, pode utilizar o padrão de Segregação de Responsabilidade de Comandos e Consultas (CQRS) para separar os modelos de dados só de leitura e leitura. Adicione instâncias de base de dados só de leitura mais redundantes para proporcionar mais resiliência.  

  • Compreenda as capacidades de replicação e redundância incorporadas dos serviços de plataforma com estado que utiliza. Para obter capacidades de redundância específicas de serviços de dados com estado, veja Ligações relacionadas.

Rede

  • Decida sobre uma topologia de rede fiável e dimensionável. Utilize um modelo hub-and-spoke ou um modelo de WAN Virtual do Azure para o ajudar a organizar a sua infraestrutura de cloud em padrões lógicos que facilitam a compilação e dimensionamento da estrutura de redundância.

  • Selecione o serviço de rede adequado para equilibrar e redirecionar pedidos dentro ou entre regiões. Utilize serviços de balanceamento de carga globais ou com redundância entre zonas sempre que possível para cumprir os seus objetivos de fiabilidade.

  • Certifique-se de que atribuiu espaço de endereços IP suficiente nas suas redes virtuais e sub-redes para ter em conta a utilização planeada, incluindo requisitos de escalamento horizontal.

  • Certifique-se de que a aplicação pode ser dimensionada dentro dos limites de porta da plataforma de alojamento de aplicações escolhida. Se uma aplicação iniciar várias ligações TCP ou UDP de saída, pode esgotar todas as portas disponíveis e causar um fraco desempenho da aplicação.

  • Selecione SKUs e configure serviços de rede que possam cumprir os seus requisitos de largura de banda e disponibilidade. O débito de um gateway de VPN varia consoante o SKU. O suporte para redundância entre zonas só está disponível para alguns SKUs do balanceador de carga.

  • Certifique-se de que a sua conceção para processar O DNS é criada com foco na resiliência e suporta infraestruturas redundantes.

Facilitação do Azure

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

Facilitação do Azure específica do DNS

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

  • Para cenários de resolução de nomes externos, utilize zonas públicas DNS do Azure, que têm redundância de zona incorporada 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 falhas regionais porque os dados de zona estão disponíveis globalmente.

  • Para cenários de resolução de nomes híbridos entre ambientes no local e na cloud, utilize a Resolução Privada do DNS do Azure. Este serviço suporta redundância entre zonas se a carga de trabalho estiver localizada numa região que suporte zonas de disponibilidade. Uma indisponibilidade em toda a zona não requer qualquer ação durante a recuperação da zona. O serviço recupera automaticamente e reequilibrar-se automaticamente para tirar partido da zona em bom estado de funcionamento. Para obter mais informações, veja Resiliência na Resolução Privada do DNS do Azure.

  • Para eliminar um único ponto de falha e alcançar uma resolução de nomes híbridos mais resiliente entre regiões, implemente duas ou mais resoluções privadas do DNS do Azure em diferentes regiões. A ativação pós-falha DNS, num cenário de reencaminhamento condicional, é obtida ao atribuir uma resolução como o servidor DNS principal. Atribua a outra resolução numa região diferente como um servidor DNS secundário. Para obter mais informações, veja Configurar a ativação pós-falha DNS com resoluções privadas.

Exemplo

Para obter um exemplo de uma implementação com redundância entre várias regiões, veja Linha de base de uma aplicação Web com redundância entre zonas de elevada disponibilidade.

O diagrama seguinte mostra outro exemplo:

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

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

Lista de verificação de fiabilidade

Veja o conjunto completo de recomendações.

Lista de verificação de fiabilidade