Partilhar via

Documentação de orientação da linha de base de operações para o Azure Red Hat OpenShift

  • Artigo

O Azure Red Hat OpenShift fornece clusters OpenShift altamente dimensionáveis e totalmente geridos a pedido. Ao conceber corretamente a sua solução com gestão e monitorização em mente, pode trabalhar no sentido da excelência operacional e do sucesso do cliente.

Considerações de design

Considere os seguintes fatores:

  • Reveja a matriz de responsabilidade do Azure Red Hat OpenShift para compreender como as responsabilidades dos clusters são partilhadas entre a Microsoft, a Red Hat e os clientes.
  • Tenha em atenção os limites das máquinas virtuais do Azure e as regiões suportadas. Certifique-se de que existe capacidade disponível para implementar recursos.
  • Tenha em atenção formas de isolar cargas de trabalho logicamente num cluster e fisicamente em clusters separados.
  • Tenha em atenção formas de ajudar o Kubernetes a compreender o estado de funcionamento das suas cargas de trabalho.
  • Tenha em atenção vários tamanhos de máquinas virtuais e o efeito de utilizar um ou outro.
  • Tenha em atenção as formas de monitorizar e registar o Azure Red Hat OpenShift para obter informações sobre o estado de funcionamento dos seus recursos e prever potenciais problemas. Tanto o cluster como as aplicações em execução na parte superior podem gerar muitos eventos. Utilize alertas para ajudar a diferenciar entre entradas de registo para fins históricos e entradas que requerem ação imediata.
  • Tenha em atenção as atualizações e atualizações importantes do sistema. As atualizações de patches críticas são aplicadas aos clusters automaticamente pelos engenheiros de fiabilidade do site (SRE) do Azure Red Hat OpenShift. Os clientes que pretendam instalar atualizações de patches com antecedência são gratuitos para o fazer.
  • Tenha em atenção as limitações de recursos do cluster e cargas de trabalho individuais.
  • Tenha em atenção as diferenças entre o dimensionador automático horizontal de pods e o dimensionamento automático de clusters.
  • Reveja o ciclo de vida do suporte e compreenda a política de suporte de versões. O Azure Red Hat OpenShift suporta apenas as versões secundárias disponíveis atuais e anteriores da Plataforma de Contentores Red Hat OpenShift. Os pedidos de suporte requerem que o cluster esteja numa versão suportada.
  • Reveja os requisitos de configuração do cluster para manter a capacidade de suporte do cluster.
  • Reveja a rede entre espaços de nomes para proteger o tráfego dentro do cluster através da política de rede.

Recomendações de conceção

  • O Azure Red Hat OpenShift tem um ecossistema de operador avançado e deve ser utilizado para realizar e automatizar atividades operacionais com eficiência e precisão.
  • Adicione sondas de estado de funcionamento aos pods para monitorizar o estado de funcionamento da aplicação. Certifique-se de que os pods contêm livenessProbe e readinessProbe. Utilize sondas de Arranque para determinar o ponto em que a aplicação foi iniciada.
  • Utilize tamanhos de máquinas virtuais suficientemente grandes para conter várias instâncias de contentor para obter os benefícios de maior densidade, mas não tão grandes que o cluster não consiga processar a carga de trabalho de um nó com falhas.
  • Regular as funções de cluster através de plug-ins de admissão, que são normalmente utilizados para impor a política de segurança, limitações de recursos ou requisitos de configuração.
  • Utilize pedidos de pods e limites para gerir os recursos de computação num cluster. Os pedidos e limites do pod informam o agendador do Kubernetes, que atribui recursos de computação a um pod. Restringir o consumo de recursos num projeto através de intervalos de limite.
  • Otimize os valores dos pedidos de CPU e memória e maximize a eficiência dos recursos do cluster com o dimensionador automático de pods vertical.
  • A consola Web Do OpenShift contém todas as métricas ao nível do nó. Estabeleça um processo de monitorização com a integração incorporada do Prometheus ou do Container Insights.
    • O Prometheus vem pré-instalado e configurado para clusters do Azure Red Hat OpenShift 4.x.
    • O Container Insights pode ser ativado ao integrar o cluster no Kubernetes compatível com o Azure Arc.
    • O registo do OpenShift implementa os agregadores de registo, o armazenamento e os componentes de visualização.
  • Automatize o processo de entrega de aplicações através de práticas de DevOps e soluções CI/CD, como Pipelines/GitOps fornecidos pela OpenShift Container Platform.
  • Defina ClusterAutoScaler e MachineAutoScaler para dimensionar máquinas quando o cluster ficar sem recursos para suportar mais implementações.
  • Implemente verificações de estado de funcionamento do computador para reparar automaticamente máquinas danificadas num conjunto de máquinas.
  • Dimensione pods para satisfazer a procura com o dimensionador automático de pods horizontal.
  • Utilize um sistema de alertas para fornecer notificações quando precisar de ação direta: alertas de métricas do Container Insights ou IU de Alertas incorporada.

Continuidade de negócio e recuperação após desastre (BCDR)

A sua organização precisa de conceber capacidades adequadas ao nível da plataforma do Azure Red Hat OpenShift para satisfazer os seus requisitos específicos. Estes serviços de aplicação têm requisitos relacionados com o objetivo de tempo de recuperação (RTO) e o objetivo de ponto de recuperação (RPO). Existem várias considerações a abordar para a recuperação após desastre. O primeiro passo é definir um contrato de nível de serviço (SLA) para a sua infraestrutura e aplicação. Saiba mais sobre o SLA para o Azure Red Hat OpenShift. Veja a secção Detalhes do SLA para obter informações sobre os cálculos de tempo de atividade mensal.

Considerações de design para BCDR

Considere os seguintes fatores:

  • O cluster do Azure Red Hat OpenShift deve utilizar vários conjuntos de máquinas para fornecer o nível mínimo de disponibilidade para a sua aplicação.
  • Definir pedidos e limites de pods. Definir estes limites permite ao Kubernetes:
    • Atribua eficientemente recursos de CPU e memória aos pods.
    • Ter uma maior densidade de contentor num nó.
    • Aumentar a fiabilidade com custos reduzidos devido a uma melhor utilização do hardware.
  • Distribua nós por todas as zonas disponíveis para maior disponibilidade.
    • Escolha uma região que suporte Zonas de Disponibilidade.
    • Para um benefício zonal completo, todas as dependências de serviço também têm de suportar zonas. Se um serviço dependente não suportar zonas, é possível que uma falha na zona possa fazer com que esse serviço falhe. Reveja os tipos de disco utilizados ao distribuir a carga de trabalho entre zonas.
    • Para uma maior disponibilidade para além do que Zonas de Disponibilidade pode alcançar, execute vários clusters em diferentes regiões emparelhadas. Se um recurso do Azure suportar a redundância geográfica, indique a localização onde o serviço redundante terá a região secundária.
  • Crie consistentemente cópias de segurança para aplicações e dados.
    • Um serviço sem estado pode ser replicado de forma eficiente.
    • Se precisar de armazenar o estado no cluster, faça uma cópia de segurança dos dados frequentemente na região emparelhada.
  • Atualize e mantenha os clusters.
  • Para conectividade de rede se ocorrer uma ativação pós-falha:
    • Se precisar de distribuir o tráfego entre regiões, considere utilizar o Azure Front Door.
  • Para ativações pós-falha planeadas e não planeadas:
    • Ao configurar cada serviço do Azure, escolha as funcionalidades que suportam a recuperação após desastre. Por exemplo, se Azure Container Registry for escolhida, ative-a para georreplicação. Se uma região ficar inativa, ainda pode extrair imagens da região replicada.
  • Mantenha as capacidades do DevOps de engenharia para atingir os objetivos ao nível do serviço.

Recomendações de conceção para BCDR

Seguem-se as melhores práticas para a sua conceção:

  • Os clusters do Azure Red Hat OpenShift são aprovisionados com três nós de plano de controlo e três ou mais nós de trabalho. Certifique-se de que o cluster é criado numa região que suporte Zonas de Disponibilidade para que os nós sejam distribuídos pelas zonas.
  • Para elevada disponibilidade, implemente estes nós em diferentes Zonas de Disponibilidade. Uma vez que precisa de conjuntos de máquinas diferentes para cada Zona de Disponibilidade, crie pelo menos três conjuntos de máquinas.
  • Não execute cargas de trabalho adicionais nos nós do plano de controlo. Embora possam ser agendados nos nós do plano de controlo, causará problemas de estabilidade e utilização de recursos adicionais que podem afetar todo o cluster.
  • Crie conjuntos de máquinas de infraestrutura para conter componentes de infraestrutura. Aplique etiquetas específicas do Kubernetes a estas máquinas e, em seguida, atualize os componentes da infraestrutura para serem executados apenas nesses computadores.
  • Sempre que possível, remova o estado do serviço de dentro dos contentores. Em vez disso, utilize uma plataforma como serviço (PaaS) do Azure que suporte a replicação de várias regiões.
  • As implementações devem especificar os requisitos de recursos do pod. Em seguida, o agendador pode agendar adequadamente o pod. A fiabilidade desvaloriza significativamente quando os pods não são agendados.
  • Configure várias réplicas na implementação para lidar com interrupções, como falhas de hardware. Para eventos planeados, como atualizações e atualizações, um orçamento de interrupção pode garantir que o número necessário de réplicas de pods existe para processar a carga esperada da aplicação.
  • Utilize restrições de topologia de pods para agendar automaticamente pods em nós em todo o cluster.
  • As aplicações podem utilizar o armazenamento para os respetivos dados e devem garantir a disponibilidade entre regiões, se necessário:
  • Crie a cópia de segurança da aplicação e planeie o restauro:
  • Estimar limites de recursos de pods. Teste e estabeleça uma linha de base. Comece com valores iguais para pedidos e limites. Em seguida, ajuste gradualmente esses valores até estabelecer um limiar que possa causar instabilidade no cluster. Os limites dos pods podem ser especificados nos manifestos de implementação. O dimensionador automático de pods vertical otimiza os valores dos pedidos de CPU e memória e pode maximizar a eficiência dos recursos do cluster.
    • As funcionalidades incorporadas podem lidar com falhas e interrupções na arquitetura do serviço. Estas configurações ajudam a simplificar a automatização da estrutura e da implementação. Quando uma organização define um padrão para o SLA, RTO e RPO, pode utilizar serviços incorporados no Kubernetes e no Azure para atingir objetivos empresariais.
  • Considere estratégias azuis/verdes ou canárias para implementar novas versões da aplicação.
  • Defina orçamentos de interrupção de pods/prioridade do pod para limitar o número de réplicas de pods que o cluster tem permissão para remover para operações de manutenção, garantindo assim a disponibilidade.
  • Impor quotas de recursos em espaços de nomes de serviço. A quota de recursos num espaço de nomes irá garantir que os pedidos e limites do pod são definidos corretamente numa implementação.
    • Definir quotas de recursos ao nível do cluster pode causar problemas ao implementar serviços de parceiros que não têm pedidos e limites adequados.
  • Armazene as imagens de contentor no Azure Container Registry e replice georreplicar o registo para cada região.
  • Utilize várias regiões e localizações de peering para a conectividade do Azure ExpressRoute . Se ocorrer uma falha que afete uma região do Azure ou a localização do fornecedor de peering, uma arquitetura de rede híbrida redundante pode ajudar a garantir uma conectividade entre locais ininterrupta.
  • Interligar regiões com peering de rede virtual global. Se os clusters precisarem de falar entre si, a ligação de ambas as redes virtuais entre si pode ser obtida através do peering de rede virtual. Esta tecnologia interliga redes virtuais entre si para fornecer largura de banda elevada na rede principal da Microsoft, mesmo em diferentes regiões geográficas.
  • Utilize o protocolo anycast baseado em TCP dividido, o Azure Front Door, para ligar prontamente os seus utilizadores finais ao POP do Front Door mais próximo (ponto de presença). Mais funcionalidades do Azure Front Door incluem:
    • Terminação TLS
    • Domínio personalizado
    • Firewall de Aplicações Web
    • Reescrever URL
    • Afinidade de sessão

Passos seguintes

Saiba mais sobre considerações de design e recomendações para a automatização da plataforma e o DevOps nas suas zonas de destino do Azure.