Editar

Partilhar via

Implantar aplicativos Web usando o Azure Red Hat OpenShift com redundância de zona

Azure Red Hat OpenShift
Azure Cosmos DB
Azure Front Door

Este artigo fornece uma visão geral abrangente de uma carga de trabalho de aplicativo Web no Red Hat OpenShift do Azure em uma configuração com redundância de zona. Os serviços com redundância de zona replicam seus serviços e dados em zonas de disponibilidade para protegê-los de pontos únicos de falha e fornecer alta disponibilidade.

Antes de criar um ambiente de produção com o Azure Red Hat OpenShift, leia Azure Red Hat OpenShift landing zone accelerator.

Arquitetura

Diagrama que mostra a arquitetura de um aplicativo Web com alta disponibilidade.

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de Trabalho

  • Um usuário envia uma solicitação para o Azure.
  • O Azure Front Door recebe a solicitação e a encaminha para um aplicativo Web hospedado no Azure Red Hat OpenShift.
  • O aplicativo Web executa a solicitação usando o Azure Key Vault, o Azure Cosmos DB e o Azure Container Registry.
  • O aplicativo Web envia uma resposta de volta para o usuário.

Componentes

  • O Microsoft Entra ID ou Azure AD B2C autentica usuários. Nessa arquitetura, o Microsoft Entra ID fornece acesso seguro e granular a recursos externos.
  • O Azure Front Door é a interface pública para todas as solicitações da Internet. Ele atua como um proxy reverso HTTP global e cache para serviços back-end. O Azure Front Door melhora a segurança e o desempenho dessa arquitetura, como a adição de proteção contra ataques distribuídos de negação de serviço (DDoS) de camada 4.
  • O Azure Red Hat OpenShift é o orquestrador de contêineres baseado em Kubernetes que hospeda os aplicativos e serviços de API e fornece uma interface para serviços back-end. O Azure Red Hat OpenShift serve como a principal plataforma de computação nessa arquitetura.
  • O Registro de Contêiner suporta imagens de contêiner compatíveis com Docker e Open Container Initiative (OCI). O Registro de Contêiner suporta redundância de zona, o que o torna altamente disponível e resiliente a falhas de zona. Ele também suporta replicação geográfica, que replica o serviço em várias regiões. Nessa arquitetura, o Registro de Contêiner fornece ao cluster ARO acesso privado a imagens de contêiner gerenciadas localmente que fazem parte da carga de trabalho.
  • O Azure Red Hat OpenShift usa a integração de rede virtual para se conectar a serviços back-end por meio de uma rede virtual privada. A integração de rede virtual fornece uma rede segura com o Azure Red Hat OpenShift e outros serviços do Azure nesta arquitetura.
  • O Azure Cosmos DB fornece bancos de dados de documentos NoSQL para serviços front-end. O Azure Cosmos DB é usado pela carga de trabalho nessa arquitetura para armazenar dados do usuário.
  • Os pontos de extremidade privados habilitam conexões com serviços PaaS do Azure a partir de redes virtuais privadas e permitem que você desabilite os pontos de extremidade públicos nesses serviços. Nessa arquitetura, os pontos de extremidade privados com integração de rede virtual mantêm o tráfego de rede do Red Hat OpenShift do Azure privado enquanto se comunicam com serviços PaaS.
  • O DNS Privado do Azure configura e atualiza os registos DNS que os serviços de ponto de extremidade privados exigem. Nessa arquitetura, o DNS Privado do Azure é usado para resolução de nomes em redes privadas.
  • O Cofre da Chave armazena com segurança segredos e certificados que são acessados pelos serviços do Azure. Nessa arquitetura, o Azure Key Vault armazena segredos com segurança para os aplicativos executados no Azure Red Hat OpenShift.
  • O Azure Monitor e o Application Insights coletam logs de serviço e métricas de desempenho de aplicativos para observabilidade. Nessa arquitetura, o Azure Monitor é a sincronização de log para logs de plataforma e de carga de trabalho. O Application Insights é especificamente para logs e métricas originados no código da carga de trabalho.

Alternativas

  • O DNS gerenciado pelo Azure é recomendado, mas você pode usar seu próprio provedor de DNS.
  • Você deve usar o Gateway de Aplicativo do Azure em vez da Porta da Frente do Azure se a maioria dos usuários estiver localizada perto da região do Azure que hospeda sua carga de trabalho e se você não precisar de cache de conteúdo. Use a Proteção contra DDoS do Azure para proteger os serviços do Gateway de Aplicativo voltados para a Internet.
  • Implante uma instância premium de Gerenciamento de API do Azure com redundância de zona como uma alternativa para hospedar APIs front-end, APIs back-end ou ambas. Para obter mais informações sobre redundância de zona de Gerenciamento de API, consulte Migrar o Gerenciamento de API do Azure para suporte à zona de disponibilidade.
  • Você pode usar o OpenShift Container Platform (OCP) ou o Origin Community Distribution of Kubernetes (OKD) em Máquinas Virtuais do Azure em vez do Azure Red Hat OpenShift. OCP ou OKD são alternativas de infraestrutura como serviço (IaaS) para um serviço totalmente gerenciado por plataforma, como o Azure Red Hat OpenShift. Você deve usar os Conjuntos de Escala de Máquina Virtual do Azure para redundância de zona. Para obter mais informações, consulte Azure Red Hat OpenShift.

Detalhes do cenário

Essa arquitetura descreve como compor serviços com redundância de zona em uma solução que fornece alta disponibilidade e é resiliente a falhas zonais.

As zonas de disponibilidade são locais físicos separados em cada região do Azure. As zonas de disponibilidade distribuem uma solução por várias zonas independentes em uma região, o que permite que um aplicativo continue funcionando quando uma zona falhar. Essa arquitetura se baseia na infraestrutura de zonas de disponibilidade encontrada em muitas regiões. Para obter uma lista de regiões que dão suporte a zonas de disponibilidade do Azure, consulte Regiões do Azure com zonas de disponibilidade.

Quando as plataformas de hospedagem estão em escala, muitas vezes é difícil mantê-las altamente disponíveis. Historicamente, a alta disponibilidade exige implantações complexas e caras em várias regiões, com consistência de dados e compensações de alto desempenho. As zonas de disponibilidade resolvem muitos desses problemas. A maioria dos serviços principais do Azure e muitos serviços especializados do Azure fornecem suporte para zonas de disponibilidade. Todos os serviços do Azure nessa arquitetura são redundantes de zona, o que simplifica a implantação e o gerenciamento. Para obter mais informações, consulte Serviços do Azure que dão suporte a zonas de disponibilidade.

Para manter os SLAs (contratos de nível de serviço), o Azure Red Hat OpenShift com redundância de zona gerencia e atenua falhas, incluindo falhas de zona. A redundância de zona fornece um tempo de recuperação de zero para falha de zona. Se uma única zona em uma região não estiver disponível, você não perderá nenhum dado e sua carga de trabalho continuará a ser executada. A redundância de zona é configurada no momento da implantação e gerenciada por serviços, portanto, você não precisa gerenciar a fixação de zona ou implantações zonais.

Nessa arquitetura, um cluster do Azure Red Hat OpenShift é implantado em três zonas de disponibilidade em regiões do Azure que oferecem suporte a elas. Um cluster consiste em três nós de plano de controle e três ou mais nós de trabalho. Para melhorar a redundância, os nós estão espalhados pelas zonas.

O Azure Front Door, o Microsoft Entra ID e o Azure DNS são serviços disponíveis globalmente que são resilientes a interrupções em toda a zona e região. Todos os outros serviços nesta arquitetura são redundantes de zona.

Potenciais casos de utilização

O Azure Red Hat OpenShift é um serviço de orquestração de contêineres que usa o Kubernetes. É adequado para muitos casos de uso, tais como:

  • Banca
  • Negociação de ações
  • Comércio eletrónico
  • Comunicação social
  • Aplicações Web
  • Aplicações móveis
  • Aplicações de processamento em lote
  • Transmissão em fluxo de multimédia
  • Cargas de trabalho de Machine Learning

Recomendações

As recomendações a seguir se aplicam à maioria dos cenários.

Azure Front Door

  • Use certificados gerenciados pelo Azure em todos os aplicativos front-end para evitar problemas de configuração incorreta e expiração de certificados.
  • Habilite o cache em rotas para melhorar a disponibilidade. O cache da Porta da Frente do Azure distribui seu conteúdo dinâmico, bem como conteúdo estático, para os nós de borda do ponto de presença (POP) do Azure. O cache reduz a carga nos servidores de origem e melhora o desempenho.
  • Implante o Azure Front Door Premium e configure uma política de firewall de aplicativo Web (WAF) com um conjunto de regras gerenciado pela Microsoft. Aplique a política a todos os domínios personalizados. Use o modo de prevenção para mitigar ataques da Web que possam causar uma falha no serviço de origem.

Azure Red Hat OpenShift

  • Certifique-se de que a região do Azure onde o Azure Red Hat OpenShift está implantado ofereça suporte a zonas de disponibilidade. Para obter mais informações, consulte Regiões do Azure com suporte à zona de disponibilidade.
  • Um cluster do Azure Red Hat OpenShift depende de alguns serviços. Certifique-se de que esses serviços suportam e estão configurados para redundância de zona. Para obter mais informações, consulte Serviços do Azure com suporte à zona de disponibilidade.
  • Remova o estado dos contêineres e use o armazenamento do Azure ou os serviços de banco de dados.
  • Configure várias réplicas em implantações com configuração de orçamento de interrupção apropriada para fornecer continuamente serviço de aplicativo apesar de interrupções, como falhas de hardware em zonas.
  • Acesso seguro ao Azure Red Hat OpenShift. Para garantir que as solicitações não possam ignorar o WAF da Porta da Frente do Azure, permita apenas o tráfego da Porta da Frente do Azure. Para obter mais informações sobre como restringir o acesso a uma instância específica do Azure Front Door, consulte Acesso seguro ao Azure Red Hat OpenShift com o Azure Front Door.

Container Registry

Para obter mais informações, consulte Habilitar redundância de zona no Registro de contêiner para resiliência e alta disponibilidade e Usar o registro de contêiner com o Azure Red Hat OpenShift.

Azure Cosmos DB

Key Vault

O Cofre da Chave é redundante em qualquer região onde as zonas de disponibilidade estejam disponíveis. Nessa arquitetura, o Cofre da Chave é implantado com um ponto de extremidade privado habilitado e um ponto de extremidade público desabilitado. Para obter mais informações sobre pontos de extremidade privados para o Cofre de Chaves, consulte Integrar o Cofre de Chaves com o Private Link.

Zonas DNS privadas do Azure

Para simplificar o gerenciamento de DNS, integre pontos de extremidade privados com zonas DNS privadas do Azure. Para obter mais informações, consulte Configuração de DNS do ponto de extremidade privado do Azure.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Azure Well-Architected Framework.

Fiabilidade

A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte Visão geral do pilar de confiabilidade.

Essa arquitetura garante confiabilidade, fornecendo disponibilidade, resiliência e recursos de serviço global confiáveis.

Disponibilidade

Quando a infraestrutura da zona de disponibilidade é implementada corretamente, essa arquitetura oferece excelente disponibilidade para menor custo e menor sobrecarga operacional do que outras soluções. Essa arquitetura reduz o risco de uma falha de zona em uma região do Azure porque os serviços redundantes de zona suportam a falha enquanto ainda operam dentro do SLA definido.

Falhas regionais são improváveis, mas possíveis. Em uma falha regional, os serviços ficam indisponíveis em todas as zonas de disponibilidade dentro de uma região. Combine essa arquitetura redundante de zona com uma arquitetura de várias regiões para reduzir o risco de falha de região. Planeje sua arquitetura de várias regiões para reduzir o tempo de recuperação se uma região inteira estiver indisponível.

Os projetos de várias regiões são mais complexos e, muitas vezes, mais caros do que os projetos de várias zonas em uma única região, mas os projetos de várias regiões oferecem uma oportunidade para otimizar ainda mais a disponibilidade e a confiabilidade geral.

Nota

Execute uma avaliação de risco para determinar se sua solução requer uma arquitetura de várias regiões.

Resiliência

Os projetos de várias zonas baseados em zonas de disponibilidade oferecem disponibilidade e resiliência que atendem ou excedem os requisitos de negócios da maioria das organizações. Mas se você quiser replicar dados para uma região secundária para recuperação de desastres, suas opções dependem dos serviços do Azure que você usa.

Por exemplo, o Armazenamento do Azure dá suporte à replicação de objetos para blobs de bloco. Os serviços de dados do Azure, como o Azure Cosmos DB, oferecem replicação de dados para outras regiões do Azure que têm backup contínuo. Você pode usar esses recursos para restaurar sua solução se ocorrer um desastre. Para obter mais informações, consulte Backup contínuo com restauração point-in-time no Azure Cosmos DB.

Serviços Globais

Falhas em serviços globais, como o Azure Front Door e o Microsoft Entra ID, são raras, mas o efeito de uma falha pode ser alto. Para melhorar a recuperação em caso de falha, prepare e ensaie runbooks.

Por exemplo, você pode reduzir o tempo de inatividade da Porta da Frente do Azure usando um runbook para implantar o Gateway de Aplicativo do Azure e alterar os registros DNS para redirecionar o tráfego até que a Porta da Frente do Azure seja restaurada.

Para obter mais informações, consulte Criando resiliência na infraestrutura de gerenciamento de identidade e acesso.

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.

  • Considere a implantação de um cluster privado.
  • Utilize pontos de extremidade privados em serviços do Azure que não são acedidos a partir da Internet pública.
  • Por padrão, toda a comunicação de serviço a serviço no Azure é criptografada TLS (Transport Layer Security). Configure o Azure Front Door para aceitar apenas tráfego HTTPS e defina a versão mínima do TLS.
  • As identidades gerenciadas autenticam a comunicação serviço-a-serviço do Azure onde ela está disponível. Para obter mais informações, consulte O que são identidades gerenciadas para recursos do Azure?
  • Para gerenciar e proteger segredos, certificados e cadeias de conexão em seu cluster, conecte o cluster do Azure Red Hat OpenShift ao Kubernetes habilitado para Azure Arc. Use a extensão Key Vault Secrets Provider para buscar segredos.
  • Configure o Microsoft Defender for Containers para fornecer segurança para clusters, contêineres e aplicativos. O Defender for Containers é suportado por meio do Kubernetes habilitado para Azure Arc. Analise suas imagens em busca de vulnerabilidades com o Microsoft Defender ou outra solução de verificação de imagens.
  • Configure a integração do Microsoft Entra para usar a ID do Microsoft Entra para autenticar usuários (por exemplo, SRE, SecOps ou desenvolvedores de aplicativos) em seu cluster do Azure Red Hat OpenShift.

Otimização de custos

A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.

As arquiteturas com redundância de zona são menos dispendiosas do que as alternativas de várias regiões porque os serviços são implantados em uma única região. Mas há várias implicações em termos de custos a ter em conta:

  • Alguns serviços exigem que um número mínimo de instâncias ou réplicas sejam implantadas para obter redundância de zona.
  • O armazenamento com redundância de zona (ZRS) e o armazenamento com redundância local (LRS) têm preços diferentes. Para obter mais informações, consulte Preços de armazenamento.
  • Os pontos de extremidade privados estão disponíveis principalmente em SKUs de serviço premium do Azure. Os terminais privados incorrem em encargos por hora e por largura de banda. Para obter mais informações, consulte Preços de links privados.

Otimize os custos reservando recursos com antecedência. Muitos serviços nessa arquitetura são elegíveis para preços de capacidade reservada. Para obter mais informações, consulte Reservas.

Utilize a calculadora de preços do Azure para prever os custos.

Excelência operacional

A excelência operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Visão geral do pilar de excelência operacional.

Todos os serviços do Azure que são plataforma como serviço (PaaS) são integrados com o Azure Monitor. Siga as práticas recomendadas do Azure Monitor (confiabilidade, segurança, otimização de custos, excelência operacional e eficiência de desempenho) para:

  • Crie um modelo de integridade para quantificar a integridade do aplicativo no contexto dos requisitos de negócios.
  • Configure a quantidade adequada de coleta de dados de log.
  • Crie painéis do Azure para unificar dados em uma única exibição para equipes de operações.
  • Crie uma estratégia de alerta bem-sucedida.
  • Integre o Application Insights em aplicativos para acompanhar as métricas de desempenho do aplicativo.
  • Para fornecer notificações quando uma ação direta for necessária, use um sistema de alertas, como alertas de métricas do Container insights ou a interface do usuário de alertas do Azure Red Hat OpenShift.
  • Considere vários métodos para monitorar e registrar o Azure Red Hat OpenShift para obter informações sobre a integridade de seus recursos e prever possíveis problemas.
  • Analise a matriz de responsabilidade do Azure Red Hat OpenShift para entender como a Microsoft, a Red Hat e os clientes compartilham responsabilidades por clusters.
  • Automatize implantações de serviços com o Bicep, uma linguagem de modelo para implantar infraestrutura como código (IaC). Como os serviços do Azure nessa arquitetura têm pontos de extremidade privados, você não pode usar agentes hospedados pela Microsoft do Azure Pipelines ou corredores hospedados no GitHub. Em vez disso, use soluções como agentes auto-hospedados do Azure Pipelines ou corredores hospedados no GitHub.
  • Valide continuamente a carga de trabalho para testar o desempenho e a resiliência de toda a solução usando serviços, como o Azure Load Testing e o Azure Chaos Studio.

Eficiência de desempenho

Eficiência de desempenho é a capacidade da sua carga de trabalho para dimensionar para satisfazer as exigências que os utilizadores lhe colocam de forma eficiente. Para obter mais informações, consulte Visão geral do pilar de eficiência de desempenho.

  • Armazene ativos em cache no Azure Front Door para distribuir cargas de trabalho para pontos de presença.
  • Revise os limites de assinatura e as cotas para garantir que os serviços sejam dimensionados de acordo com a demanda.
  • Monitore o desempenho do aplicativo usando o Application Insights.
  • Cargas de trabalho de teste de desempenho para medir qualquer latência causada por conexões entre zonas.
  • Escolha tamanhos de máquina virtual apropriados para suas cargas de trabalho. Escolha um tamanho que seja grande o suficiente para obter os benefícios do aumento da densidade, mas não tão grande que seu cluster não possa lidar com a carga de trabalho de um nó com falha.
  • Use solicitações e limites de pod para gerenciar os recursos de computação dentro de um cluster. Solicitações e limites de pod informam o agendador do Kubernetes, que atribui recursos de computação a um pod. Restrinja o consumo de recursos em um projeto usando intervalos de limite.
  • Defina solicitações e limites de recursos de pod nos manifestos de implantação do aplicativo e imponha esses limites com a Política do Azure.
  • Otimize os valores de solicitação de CPU e memória e maximize a eficiência dos recursos do cluster usando o Vertical Pod Autoscaler.
  • Dimensione pods para atender à demanda usando o Horizontal Pod Autoscaler.
  • Defina ClusterAutoScaler e MachineAutoScaler para dimensionar máquinas quando o cluster ficar sem recursos para dar suporte a mais implantações.

Implementar este cenário

Para implantar essa arquitetura, consulte o acelerador de zona de aterrissagem do Azure Red Hat OpenShift e o repositório GitHub associado.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

Outros contribuidores:

  • Ayobami Ayodeji - Brasil | FastTrack para engenheiro do cliente do Azure
  • Daniel Larsen - Brasil | FastTrack para engenheiro do cliente do Azure

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos