Recomendações para projetar para 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. 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ível Usando 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 à 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
| 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 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. |
| Criação de partições | O processo de divisão física de dados em armazenamentos de dados separados. |
| Shard | 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. |
Principais estratégias de design
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 em execução ao mesmo tempo. A criticidade do fluxo que eles suportam pode exigir que todos eles tenham réplicas prontas para aceitar tráfego se houver um problema que afete todo o pool, por exemplo, uma interrupção regional. 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é que você resolva 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 com 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 que se espalham por 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. Projetos de redundância específicos de fluxo podem potencialmente introduzir complexidade no projeto geral.
Projeto de arquitetura redundante
Considere duas abordagens ao projetar uma arquitetura redundante: ativo-ativo ou ativo-passivo. Escolha sua abordagem dependendo da criticidade do fluxo de usuários e do fluxo do sistema suportados pelos componentes da infraestrutura. Em termos de confiabilidade, um design ativo-ativo de várias regiões ajuda você a alcançar o mais alto nível de confiabilidade possível, mas é significativamente mais caro do que um design ativo-passivo. Decidir as regiões geográficas apropriadas torna-se a próxima escolha 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 multirregião altamente disponível.
Selos de implantação e unidades de escala
Quer você implante em um modelo ativo-ativo ou ativo-passivo, siga o padrão de design Carimbos de Implantação para garantir que você implante sua carga de trabalho de forma repetível e escalável. Os carimbos 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 os mesmos requisitos de privacidade de dados que sua carga de trabalho. Pense em cada carimbo 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 carimbos de implantação para otimizar sua implementação ativa-ativa ou ativa-passiva para resiliência e carga de gerenciamento. O planejamento da expansão de várias regiões também é importante para superar possíveis restrições temporárias de capacidade de recursos em uma região.
Zonas de disponibilidade dentro das regiões do Azure
Quer você implante 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 dentro de uma região. Dependendo do serviço do Azure, você pode aproveitar as zonas de disponibilidade implantando elementos de sua carga de trabalho de forma redundante 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.
Implementar redundância de zona para 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 geralmente são mais adequadas para serviços de computação IaaS (infraestrutura como serviço). Para um aplicativo em contêiner, determine a funcionalidade específica sobre a qual você precisa ter controle para determinar se deve usar o Serviço Kubernetes do Azure (AKS) ou uma solução de plataforma como serviço (PaaS). Sua plataforma de nuvem gerencia totalmente um serviço PaaS.
Use as opções de computação PaaS se seus requisitos permitirem. O Azure gerencia totalmente os serviços de PaaS, o que reduz sua carga de gerenciamento, e um grau documentado de redundância é incorporado.
Use os Conjuntos de Escala de Máquina Virtual do Azure se precisar implantar máquinas virtuais (VMs). Com os Conjuntos de Dimensionamento de Máquina Virtual, você pode distribuir automaticamente sua computação uniformemente pelas zonas de disponibilidade.
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.
Use serviços redundantes de zona sempre que possível para fornecer maior resiliência sem aumentar sua carga operacional.
Superprovisionar recursos críticos para mitigar falhas de instâncias redundantes, mesmo antes do início das operações de dimensionamento automático, para que o sistema continue a operar após uma falha de componente. Calcule o efeito aceitável de uma falha ao incorporar o provisionamento excessivo em seu projeto de redundância. Tal como acontece com o seu processo de tomada de decisões de redundância, as suas metas de fiabilidade e as decisões de compensação financeira determinam até que ponto adiciona capacidade ociosa com sobreaprovisionamento. O provisionamento excessivo 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 uma SKU de camada inferior para uma SKU de camada superior.
Implante serviços IaaS manualmente ou por meio de automação em cada zona de disponibilidade ou região na qual você pretende implementar sua solução. Alguns serviços PaaS têm recursos internos que são replicados automaticamente entre zonas de disponibilidade e regiões.
Implementar redundância de zona para recursos de dados
Determine se a replicação de dados síncrona ou assíncrona é necessária para a funcionalidade da sua 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 dos seus dados. Para o planejamento de capacidade, planeje o crescimento e 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 aumenta.
Distribua dados geograficamente, conforme suportado pelo seu serviço, para minimizar o efeito de falhas geograficamente localizadas.
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 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 recuperação de desastres.
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. Também incluem as caches, as mensagens, os eventos e os registos da aplicação.
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 seu rendimento e tornar seus sistemas firmemente acoplados, o que pode torná-los mais frágeis. 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 and Query Responsibility Segregation) para separar os 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.
Compreenda os recursos internos de replicação e redundância dos serviços de plataforma com monitoração de estado que você usa. Para obter recursos específicos de redundância de serviços de dados com monitoração de estado, consulte Links relacionados.
Implementar redundância de zona para 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 ou UDP de saída, 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 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 design para lidar com DNS seja construído com foco na resiliência e ofereça suporte à infraestrutura redundante.
Facilitação do Azure
A plataforma Azure ajuda-o a otimizar a resiliência da sua carga de trabalho e a adicionar redundância:
Fornecendo redundância integrada com muitas soluções PaaS e software como serviço (SaaS), algumas das quais são configuráveis.
Permitindo que você projete e implemente redundância intrarregião usando zonas de disponibilidade e redundância entre regiões.
Oferecendo serviços de balanceamento de carga com reconhecimento de réplica, como o Azure Application Gateway, o Azure Front Door e o Azure Load Balancer.
Oferecendo soluções de replicação geográfica facilmente implementadas, como replicação geográfica ativa para o Banco de Dados SQL do Azure. Implemente a distribuição global e a replicação transparente usando o Azure Cosmos DB. O Azure Cosmos DB oferece duas opções para lidar com gravações conflitantes. Escolha a melhor opção para a sua carga de trabalho.
Oferecendo recursos de restauração point-in-time para muitos serviços de dados PaaS.
Atenuando 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 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.
Exemplo
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:
Ligações relacionadas
Para saber mais sobre redundância, consulte os seguintes recursos:
- Guia de regiões do Azure
- Redundância do Armazenamento do Azure
- Armazenamento com redundância entre zonas
- Replicação geográfica ativa do Banco de Dados SQL do Azure
- Configurar a replicação entre duas instâncias gerenciadas
Lista de verificação de fiabilidade
Consulte o conjunto completo de recomendações.