Recomendações para projetar para redundância
Aplica-se a esta recomendação da 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í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 à sua computação, dados, rede e outras camadas de infraestrutura. Aplique essa redundância para dar à sua carga de trabalho uma base sólida e confiável para construir. 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 repositórios. |
| Particionamento | O processo de dividir fisicamente os dados em armazenamentos de dados separados. |
| Fragmento | Uma estratégia de particionamento de banco de dados horizontal 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 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 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 ao qual eles dão suporte 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 de 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 sobressalente para absorver falhas ou mau funcionamento que afetem um ou mais nós. Certifique-se de que a capacidade sobressalente possa 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 a 120%. Distribua 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 os custos, especialmente quando você usa o provisionamento excessivo. Ao usar 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 um alto grau de redundância. Por exemplo, os recursos que se espalham por zonas de disponibilidade ou regiões 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 projetos de redundância específicos do fluxo podem potencialmente introduzir complexidade no projeto geral.
Design de arquitetura redundante
Considere duas abordagens ao projetar uma arquitetura redundante: ativo-ativo ou ativo-passivo. Escolha sua abordagem dependendo da criticidade do fluxo do usuário e do fluxo do sistema que os componentes de infraestrutura suportam. Em termos de confiabilidade, um design ativo-ativo multirregional 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 multirregional 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 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 selos 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 nas regiões do Azure
Se você implantar um design ativo-ativo ou ativo-passivo, aproveite as zonas de disponibilidade nas 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, confira as 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 de infraestrutura como serviço (IaaS). Para um aplicativo em contêineres, determine a funcionalidade específica sobre a qual você precisa ter controle para determinar se deve usar o AKS (Serviço de Kubernetes do Azure) ou uma solução de PaaS (plataforma como serviço). Sua plataforma de nuvem gerencia totalmente um serviço de PaaS.
Use as 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 é integrado.
Use os Conjuntos de Dimensionamento de Máquinas Virtuais do Azure se precisar implantar VMs (máquinas virtuais). Com os Conjuntos de Dimensionamento de Máquinas Virtuais, você pode distribuir automaticamente sua computação uniformemente entre zonas de disponibilidade.
Mantenha sua camada de computação limpa de qualquer estado , pois os nós individuais que atendem às solicitações podem ser excluídos, defeituosos 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.
Provisione recursos críticos em excesso 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 design de redundância. Assim como no processo de tomada de decisão de redundância, suas metas de confiabilidade e decisões de compensação financeira determinam até que ponto você adiciona capacidade sobressalente com superprovisionamento. O superprovisionamento 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 uma única instância. Por exemplo, se você alterar uma VM de um SKU de camada inferior para um SKU de camada superior.
Implante serviços de IaaS manualmente ou por meio de automação em cada zona de disponibilidade ou região em que você pretende implementar sua solução. Alguns serviços de 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 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, 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 em 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 de aplicativos persistentes. 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 forem 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 fortemente 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 a consistência eventual.
Particionar dados 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 Comando e Consulta) para separar seus modelos de dados de leitura/gravação e somente leitura. Adicione mais instâncias redundantes de banco de dados somente leitura 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.
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 facilitam a criação e o dimensionamento do design de redundância.
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 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.
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 baixo desempenho 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 de VPN varia de acordo com o SKU. O suporte para redundância de zona só está disponível para alguns SKUs do balanceador de carga.
Certifique-se de que seu design para lidar com DNS seja criado com foco na resiliência e ofereça suporte à infraestrutura redundante.
Facilitação do Azure
A plataforma do Azure ajuda você a otimizar a resiliência de sua carga de trabalho e adicionar redundância:
Fornecendo redundância integrada com muitas soluções de PaaS e software como serviço (SaaS), algumas das quais são configuráveis.
Permitindo que você projete e implemente a redundância intrarregional usando zonas de disponibilidade e redundância entre regiões.
Oferecendo serviços de balanceamento de carga com reconhecimento de réplica, como Gateway de Aplicativo do Azure, Azure Front Door e 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 sua carga de trabalho.
Oferecendo recursos de restauração pontual para muitos serviços de dados PaaS.
Atenuando o esgotamento de portas por meio do Gateway NAT do Azure ou do Firewall do Azure.
Facilitação do Azure específica para 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 de zona privada do DNS do Azure.
Para cenários de resolução de nomes externos, use zonas públicas do 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 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. 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 da zona. O serviço se recupera e reequilibra automaticamente 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 nomes híbrida 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.
Exemplo
Para obter um exemplo de uma implantação com redundância de várias regiões, consulte Aplicativo Web com redundância de zona altamente disponível de linha de base.
O diagrama a seguir mostra outro exemplo:
Links relacionados
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 de zona
- 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 confiabilidade
Consulte o conjunto completo de recomendações.