Guia de subscrição do Red Hat OpenShift autogerenciado

Este documento ajuda você a entender o modelo de subscrição das ofertas do  Red Hat® OpenShift® autogerenciado, além de apresentar instruções detalhadas sobre como determinar a quantidade de direitos necessários em um ambiente do OpenShift. Informações mais precisas sobre os tamanhos estão disponíveis mediante solicitação.

Primeiro, vamos definir alguns termos que você precisa entender:

• Par de núcleos: uma das bases das subscrições do OpenShift autogerenciado. Ele representa dois núcleos físicos ou quatro vCPUs. Em máquinas bare metal, esse termo sempre se refere ao núcleo físico, mesmo que haja uma tecnologia de hyper-threading ou multithreading simétrico. Se o hyper-threading estiver ativado, dois núcleos físicos apresentados como quatro vCPUs ainda serão contabilizados como um único par de núcleos. Em implantações de hyperscalers como AWS, Azure e GCP, quatro vCPUs são sempre considerados como um único par de núcleos. As subscrições de par de núcleos são contabilizadas no nível do cluster. Por isso, elas podem abranger várias instâncias de computação em nuvem, máquinas virtuais (VMs) e servidores físicos.
• Par de soquetes bare metal: outra base das subscrições do OpenShift autogerenciado. É necessário ter pelo menos uma subscrição de par de soquetes bare metal por servidor, o que abrange o total de 128 núcleos. Uma subscrição desse tipo não pode cobrir mais de um servidor, e seus núcleos não podem se estender para mais de um servidor. É possível empilhar as subscrições de par de soquetes bare metal para cobrir quantidades maiores de núcleos e soquetes.
• Acelerador de IA: a quantidade exigida de subscrições do Red Hat AI Accelerator é baseada no número de dispositivos complementares de hardware que aceleram determinadas funções de computação fora das unidades centrais de processamento (CPUs). Isso inclui, entre outros, diferentes unidades de processamento gráfico (GPUs), unidades de processamento de tensor (TPUs), unidades de processamento de dados (DPUs), arranjos de portas programáveis em campo (FPGAs), circuitos integrados de aplicação especifica (ASICs) e unidades de processamento de rede (NPUs) instalados como complementos. Isso não inclui aceleradores integrados estreitamente à CPU principal, como GPUs, NPUs e outros tipos. Embora os aceleradores muitas vezes possam ser virtualizados e apresentados para mais de uma VM ou instância, além de ter um ou mais "núcleos" similares aos de CPU, a subscrição é baseada na quantidade de dispositivos físicos.
• SLA: é preciso escolher uma opção de contrato de nível de serviço (SLA) para as subscrições Red Hat. As duas opções disponíveis são suporte Standard em horário comercial e Premium em tempo integral.
• Nó de computação: instâncias (VMs ou hosts bare metal) do Red Hat Enterprise Linux® ou Red Hat Enterprise Linux CoreOS em que os pods de aplicação do usuário final são executados. Os ambientes do OpenShift podem ter vários nós de computação. Esse tipo de nós exige subscrições do OpenShift. Os nós de control plane e infraestrutura que oferecem suporte aos nós de computação não exigem subscrições, mas podem gerar custos.
• Nós de control plane: instâncias (VMs ou hosts bare metal) do Red Hat Enterprise Linux CoreOS que funcionam como a orquestração do Kubernetes ou a camada de gerenciamento do Red Hat OpenShift. Os direitos de nó de control plane estão incluídos nas subscrições do OpenShift autogerenciado e não precisam ser contabilizados para determinar a quantidade de subscrições a serem compradas. Veja mais detalhes na seção de nós de control plane e de infraestrutura do Red Hat OpenShift.
• Nós de infraestrutura: executam pods para oferecer suporte a uma infraestrutura de cluster do OpenShift, e não instâncias de aplicação. (Por exemplo, nós que executam o balanceador de carga baseado em HAProxy no tráfego de entrada). Os direitos de nó de infraestrutura estão incluídos nas subscrições do OpenShift autogerenciado e não precisam ser contabilizados para determinar a quantidade de subscrições a serem compradas, desde que esses nós não executem instâncias de aplicação do usuário.
• Cluster: um cluster Kubernetes do OpenShift que consiste em um control plane, nós de infraestrutura opcionais e um ou mais nós de computação.

Instância de aplicações: uma aplicação pode ser apenas uma instância de pod ou implantada em várias instâncias de pod que compõem um serviço de aplicação. Por exemplo, um serviço de aplicação altamente disponível pode ter dois ou mais pods. As instâncias de aplicação precisam ser executadas sempre em nós de computação com direitos usando as subscrições do Red Hat OpenShift.

O Red Hat OpenShift oferece uma plataforma consistente de gerenciamento e desenvolvimento de aplicações em ambientes de nuvem híbrida aberta. Além disso, ele dá suporte a infraestruturas físicas, virtuais e on-premises e a implantações de nuvem privada, nuvem pública e edge. Há duas maneiras de operar e usar o Red Hat OpenShift: OpenShift autogerenciado ou serviços em nuvem do OpenShift totalmente gerenciados. Este guia é voltado ao OpenShift autogerenciado.

Com o OpenShift autogerenciado, você pode instalar, operar e gerenciar ambientes do Red Hat OpenShift com o máximo de controle, flexibilidade e personalização. Assim, você opera seu próprio ambiente a partir da infraestrutura. O OpenShift autogerenciado tem suporte em ambientes on-premises (usando servidores físicos, virtualização e nuvem privada) e nuvens públicas compatíveis. Você controla os upgrades, gerencia a infraestrutura básica e mantém contratos de nível de serviço (SLAs).

Os serviços em nuvem  do OpenShift são totalmente gerenciados e operados pela Red Hat e nossos parceiros nas principais nuvens públicas. Uma equipe dedicada de engenharia de confiabilidade de sites (SRE) fica responsável pelo gerenciamento e manutenção da infraestrutura e serviços principais do Red Hat OpenShift. Assim, suas equipes de DevSecOps podem se concentrar em desenvolver e implantar novas aplicações e modernizar as existentes.

Ofertas de serviços em nuvem do OpenShift e onde encontrar mais informações:

• Red Hat OpenShift Dedicated: um serviço totalmente gerenciado do Red Hat OpenShift para Amazon Web Services (AWS) e Google Cloud.
• Microsoft Azure Red Hat OpenShift: um serviço totalmente gerenciado do Red Hat OpenShift para Microsoft Azure, gerenciado em conjunto pela Red Hat e Microsoft.
• Red Hat OpenShift Service on AWS: um serviço totalmente gerenciado do Red Hat OpenShift para Amazon Web Services, gerenciado em conjunto pela Red Hat e AWS.
• Red Hat OpenShift on IBM Cloud: um serviço totalmente gerenciado do Red Hat OpenShift para IBM Cloud, gerenciado em conjunto pela Red Hat e IBM.

Todas as edições do Red Hat OpenShift oferecem uma experiência de usuário consistente para desenvolvedores e equipes de operações em todos os ambientes. Assim, você pode transferir suas habilidades e aplicações para os ambientes de nuvem em que a execução das aplicações é melhor.

O OpenShift autogerenciado (Red Hat OpenShift Platform Plus, Red Hat OpenShift Container Platform, Red Hat OpenShift Kubernetes Engine e Red Hat OpenShift Virtualization Engine) pode ser usado em qualquer ambiente em que o Red Hat Enterprise Linux de 64 bits seja certificado e compatível. Consulte a documentação para conhecer mais sobre os métodos de implantação do OpenShift e os tipos de infraestruturas compatíveis.

Edições do software OpenShift autogerenciado:

• Red Hat OpenShift Kubernetes Engine: um mecanismo de runtime empresarial e de nuvem híbrida do Kubernetes que oferece a funcionalidade principal do Red Hat OpenShift. Assim, é possível implantar e executar aplicações que podem ser instaladas e gerenciadas em um data center, nuvem pública ou ambiente de edge.
• Red Hat OpenShift Container Platform:  uma plataforma empresarial, completa e de nuvem híbrida do Kubernetes para criar, implantar e executar aplicações que podem ser instaladas e gerenciadas em um data center, nuvem pública e ambiente de edge.
• Red Hat OpenShift Platform Plus: uma plataforma de nuvem híbrida para as empresas criarem, implantarem, executarem e gerenciarem aplicações inteligentes em escala em vários clusters e ambientes de nuvem. Há várias camadas de segurança, gerenciabilidade e automação que oferecem consistência em toda a cadeia de suprimentos de software. As subscrições do OpenShift Platform Plus estão disponíveis apenas para clusters x86.
• Red Hat OpenShift Virtualization Engine: uma oferta de infraestrutura de virtualização exclusiva para bare metal criada com base no Red Hat OpenShift e no hipervisor open source de máquina virtual baseada em Kernel (KVM). Ela foi desenvolvida para oferecer às empresas uma solução empresarial confiável para implantar, gerenciar e escalar VMs. Essa edição é um subconjunto das funcionalidades do OpenShift, voltada apenas para cargas de trabalho de máquina virtual. Além disso, somente os serviços de infraestrutura são compatíveis com os containers (ou seja, não há suporte para containers de aplicação do usuário final).

Tipos de subscrição

O OpenShift autogerenciado tem dois tipos de subscrição (par de núcleos e par de soquetes bare metal), com dois níveis de suporte para cada um.

Os nós de computação no seu ambiente exigem subscrições desse tipo. Esses direitos são concedidos por pares de núcleos ou de soquetes bare metal:

1. Par de núcleos (2 núcleos ou 4 vCPUs)
   • Essa opção de subscrição está disponível para o OpenShift Kubernetes Engine, OpenShift Container Platform e OpenShift Platform Plus. As subscrições de par de núcleos não são aplicáveis ao OpenShift Virtualization Engine.
   • Ao conceder direitos aos núcleos de CPU, contabilize o número agregado de núcleos físicos ou vCPUs em todos os nós de computação do OpenShift executados em todos os clusters do OpenShift que receberão direitos por meio de subscrições de par de núcleos.
   • Disponível com SLA que inclui suporte Standard em horário comercial ou Premium em tempo integral.
2. Par de soquetes bare metal (1 ou 2 soquetes com até 128 núcleos)
   • Essa opção de subscrição está disponível para todas as edições do OpenShift autogerenciado, sendo a única para o OpenShift Virtualization Engine.
   • Essa subscrição é exclusiva para nós físicos bare metal ARM e x86 em que o OpenShift esteja instalado diretamente no hardware. Hipervisores externos não são permitidos.
   • Isso claramente não é uma subscrição de "data center virtual" (como o Red Hat Enterprise Linux for Virtual Datacenters, em que uma única subscrição oferece instalações ilimitadas de sistema operacional guest de VM em qualquer host de hipervisor).
   • Disponível com SLA que inclui suporte Standard em horário comercial ou Premium em tempo integral.
   • É possível empilhar as subscrições para servidores bare metal com mais de dois soquetes ou mais de 128 núcleos. No entanto, uma única subscrição não pode abranger vários servidores bare metal.

Além disso, você precisará ter subscrições do Red Hat AI Accelerator para os aceleradores no seu ambiente:

1. Acelerador de IA (1 acelerador)
   • Essa subscrição é necessária para as placas aceleradoras (GPU, TPU, NPU, FPGA, DPU etc.) que agilizam a computação de cargas de trabalho de IA e que são complementos separados, sem fazer parte do pacote da CPU.
   • A mesma subscrição é usada para cada acelerador de IA físico, seja qual for a edição do Red Hat OpenShift.
   • Uma única subscrição de acelerador de IA será suficiente para o Red Hat OpenShift e o OpenShift AI se ambas as soluções estiverem instaladas no cluster.
   • Essa subscrição não será necessária desde que a funcionalidade de aceleração de computação não esteja sendo usada. Por exemplo, DPUs usadas como SmartNICs apenas na aceleração de rede mesmo quando elas têm núcleos ARM abordáveis não utilizados ou GPUs aplicadas à renderização de gráficos, e não à aceleração de IA.
   • Disponível com SLA que inclui suporte Standard em horário comercial ou Premium em tempo integral. Deve ser o mesmo SLA da subscrição de par de núcleos ou de soquetes bare metal usada.

Quando escolher subscrições de par de núcleos

As subscrições de par de núcleos são recomendadas para a implantação do OpenShift autogerenciado em hyperscalers de nuvem pública, em nuvens privadas de infraestrutura como serviço (IaaS) ou em hipervisores como VMware vSphere, Red Hat OpenStack® Platform e Nutanix.

Com essa opção, você não precisa vincular subscrições a servidores físicos e tem liberdade para implantar pods em toda a nuvem híbrida, quando e onde precisar.

Além disso, você pode usar subscrições de par de núcleos em dispositivos ou servidores bare metal (ou seja, sem um hipervisor). Vale notar que costuma haver densidade de pods de computação, e as subscrições de par de soquetes bare metal podem oferecer maior custo-benefício nesse quesito.

Ao usar o OpenShift Virtualization Engine como uma plataforma de virtualização dedicada, você pode conceder direitos aos containers do OpenShift em VMs que usam as subscrições de par de núcleos além das de par de soquetes bare metal do próprio hipervisor. É possível comprar separadamente subscrições de par de núcleos do OpenShift autogerenciado e atribuir às VMs desse ambiente, assim como qualquer outra aplicação que você adquire e executa como VM. Nessa instância, ocorre densidade de núcleos, e a troca para o modelo de par de soquetes bare metal do OpenShift pode oferecer maior custo-benefício nesse quesito, já que inclui containers ilimitados do OpenShift em servidores bare metal e suporte para executar esses containers em VMs do OpenShift.

É possível distribuir as subscrições de par de núcleos para cobrir todos os nós de computação do OpenShift em todos os clusters do OpenShift. Por exemplo, 100 subscrições de par de núcleos do Red Hat OpenShift Platform Plus concederão 200 núcleos (400 vCPUs) que podem ser usados em qualquer quantidade de nós de computação em todos os clusters do OpenShift em execução nos ambientes de nuvem híbrida.

Quando escolher as subscrições de par de soquetes bare metal

As subscrições de par de soquetes bare metal são a única opção para os nós de computação do OpenShift implantados em servidores físicos dedicados, seja no data center ou em nuvens privadas hospedadas ou hyperscalers em ofertas bare metal com suporte. Esse tipo de subscrição é exclusivo para o OpenShift Virtualization Engine e necessário para oferecer suporte à funcionalidade do OpenShift Virtualization em outras edições do OpenShift autogerenciado.

Cada subscrição de par de soquetes de bare metal concede o direito a até 128 núcleos físicos em dois soquetes. Essas subscrições podem ser colocadas empilhadas para cobrir os pares de soquete com mais de 128 núcleos no total e servidores físicos com mais de um par de soquetes.

Para conceder direitos a um servidor físico, empilhe uma ou mais subscrições para cobrir o número total de soquetes ou os núcleos físicos nele (o que for maior). Por exemplo, considere um servidor que tem dois soquetes com 48 núcleos em cada CPU, totalizando 96 núcleos. É necessária uma subscrição porque o servidor tem até dois soquetes e menos de 128 núcleos. Já outro servidor com dois soquetes e 192 núcleos no total exige duas subscrições. Elas são necessárias para cobrir os 192 núcleos, já que o máximo coberto por uma subscrição são 128. Não é possível dividir uma subscrição de par de soquetes bare metal por diferentes hosts físicos para cobrir dois servidores com um soquete cada ou abranger os núcleos em servidores distintos.

Cada servidor físico e bare metal que usa direitos baseados em soquetes pode ser utilizado somente como um nó do OpenShift por conta da arquitetura do Kubernetes. Como cada nó no Kubernetes pode pertencer apenas a um cluster, todos os containers em um servidor bare metal estarão no mesmo cluster. Isso é adequado para cargas de trabalho que consomem muitos recursos, como o OpenShift Virtualization (em que cada carga de trabalho executa uma VM completa), mas não é apropriado para outras. Embora o OpenShift ofereça suporte a até 2.500 containers em um nó, há casos em que pode ser necessário dividir os containers entre diferentes nós ou clusters por questões de desempenho ou arquitetura. Isso não é possível sem usar a virtualização para criar nós de computação separados no servidor bare metal.

Um típico modelo de implantação de containers é criar uma grande quantidade de clusters com volumes menores de containers em cada um deles. Esse modelo é comum em ambientes de hypercaler e pode ser implementado no data center. Para isso, é preciso usar um hipervisor para criar VMs que funcionam como os nós de computação em que os containers são implantados. No caso de hipervisores como VMware vSphere, Red Hat OpenStack Platform e Nutanix, você precisa usar as subscrições de par de núcleos para o OpenShift implantado nas VMs.

Quando implantados em bare metal e com direitos de par de soquetes, os clusters do OpenShift Kubernetes Engine, OpenShift Container Platform e OpenShift Platform Plus incluem o OpenShift Virtualization, além de subscrições para os clusters virtuais do OpenShift baseadas no mesmo tipo de solução implantada neles. Por exemplo, os clusters virtuais do OpenShift implantados em um cluster bare metal do OpenShift Container Platform herdam as subscrições do OpenShift Container Platform a partir do cluster host bare metal.

É importante notar que a subscrição do OpenShift Virtualization Engine não oferece suporte para instâncias de aplicações em container. A única exceção são as cargas de trabalho de infraestrutura conforme definidas na seção abaixo sobre o OpenShift Virtualization Engine. Se você quiser executar as próprias cargas de trabalho de aplicação em container com o OpenShift Virtualization Engine, será necessário conceder direitos às VMs usando as subscrições de par de núcleos do OpenShift autogerenciado. Por outro lado, em densidades maiores, você pode comprar uma subscrição de par de soquetes bare metal para o OpenShift Kubernetes Engine, OpenShift Container Platform ou OpenShift Platform Plus autogerenciados. Assim, é possível executar aplicações baseadas em container nativamente no cluster bare metal, ou os clusters virtuais podem herdar subscrições conforme descrito no parágrafo acima.

Não é possível combinar diferentes tipos de solução OpenShift no mesmo cluster. Além disso, as subscrições de todos os nós devem ter o mesmo tipo de solução OpenShift Virtualization Engine, OpenShift Kubernetes Engine, OpenShift Container Platform ou OpenShift Platform Plus. No entanto, você pode usar as subscrições de par de núcleos e de soquetes bare metal em um mesmo cluster. Por exemplo, você não pode ter um cluster bare metal com uma determinada quantidade de nós do OpenShift Virtualization Engine para hospedar VMs e outros nós do OpenShift Platform Plus para hospedar aplicações em container e instâncias virtuais do OpenShift.

Como contabilizar as subscrições de acelerador de IA

Nos últimos anos, tecnologias de hardware específicas surgiram no mercado para acelerar a execução de determinadas cargas de trabalho de computação. Esses tipos de dispositivos de hardware são chamados de aceleradores (ou de aceleradores de IA no conteúdo da Red Hat). Há vários tipos de dispositivos de hardware disponíveis para servidores modernos que podem ser classificados como aceleradores. Isso inclui, dentre outros, GPUs, TPUs, ASICs, NPUs e FPGAs.

Em geral, esses aceleradores são uma placa ou outro dispositivo físico que ocupam um slot de Peripheral Component interconnect (PCI) em um servidor. A quantidade desses componentes é quase sempre a que você comprou de um fornecedor de aceleradores. Por exemplo, em um servidor que diz "ter 8 GPUs", quase sempre isso significa que ele conta com oito unidades de aceleradores físicos.

Cada subscrição de acelerador de IA cobre 1 dispositivo de acelerador físico. Por exemplo, considerando apenas as subscrições de acelerador de IA:

• Um nó de computação físico com quatro dispositivos de GPU exige quatro subscrições de acelerador de IA, além das subscrições de CPU de par de núcleos ou de soquetes que cobrem o nó de computação.
• Um nó de computação virtual com um dispositivo de GPU físico apresentado às VMs como várias vGPUs exige uma assinatura de acelerador de IA, já que a contagem é baseada em aceleradores físicos, e não em aceleradores virtuais.

Os aceleradores são contabilizados apenas quando utilizados para executar uma carga de trabalho de computação. Uma carga de trabalho é considerada como de computação quando tem um objetivo principal que não seja de preencher pixels na tela de um usuário quase em tempo real nem de transferir dados por uma rede.

Essa diferenciação é importante porque aplicações de streaming e efeitos visuais (VFX) podem usar GPUs e outros hardwares aceleradores, mas com o objetivo principal de preencher pixels na tela. Em alguns casos, a funcionalidade principal é transferir dados por uma rede (como as unidades de processamento de dados dedicadas a funções de rede), o que também não é considerado como computação.

Os exemplos de carga de trabalho de computação incluem:

• Aplicações de software tradicionais, como Java, Python e Perl.
• LLMs ou outros softwares com uso intenso de computação.
• Treinamento e ajuste de modelos de ciência de dados.
• Modelagem científica e simulações físicas, como enovelamento de proteínas e hidrodinâmica.

Nós de control plane e de infraestrutura do Red Hat OpenShift

Toda subscrição do OpenShift autogerenciado inclui direitos do Red Hat OpenShift e outros componentes relacionados a essa solução. O OpenShift Kubernetes Engine, OpenShift Container Platform e OpenShift Platform Plus concedem direitos do Red Hat Enterprise Linux para nós de computação e infraestrutura. O Red Hat OpenShift Virtualization Engine não oferece suporte aos nós padrão de infraestrutura e trabalho do Red Hat Enterprise Linux, mas apenas ao sistema operacional Red Hat Enterprise Linux CoreOS, que está incluso nos direitos do OpenShift.

Esses direitos são concedidos para executar a infraestrutura e control plane exigidos do OpenShift, mas não precisam ser contabilizados para determinar a quantidade de subscrições Red Hat necessárias.

As subscrições do Red Hat OpenShift Platform Plus incluem o gerenciamento de todos os nós pelo Red Hat Advanced Cluster Security for Kubernetes e Red Hat Advanced Cluster Management for Kubernetes.

A instalação padrão implanta um control plane do OpenShift altamente disponível, composto por três nós de control plane, além de pelo menos dois nós de computação do OpenShift para executar aplicações do usuário final. Por padrão, os componentes do control plane do Kubernetes (por exemplo, servidor da interface de programação de aplicações [API], etcd e scheduler) e os serviços de cluster complementares (como monitoramento e registro) são implantados em nós de control plane do OpenShift. No entanto, você pode migrar alguns desses serviços de cluster complementares para "nós de infraestrutura" dedicados.

Para se qualificar como um nó de infraestrutura e usar os direitos inclusos, apenas os componentes que oferecem suporte ao cluster e que não fazem parte de uma aplicação do usuário final podem ser executados nessas instâncias. Por exemplo:

• Registro do OpenShift.
• Roteador de ingress do OpenShift (entrada local, global e multicluster)
• OpenShift Observability
• Instâncias baseadas em HAProxy usadas no ingress do cluster
• Red Hat Quay
• Red Hat OpenShift Data Foundation
• Red Hat Advanced Cluster Management for Kubernetes.
• Red Hat Advanced Cluster Security for Kubernetes.
• Red Hat OpenShift GitOps.
• Red Hat OpenShift Pipelines.
• Control planes hospedados do Red Hat OpenShift

Você pode implantar e executar agentes externos e personalizados, além de ferramentas de monitoramento, coleta e encaminhamento de dados de log, drivers de hardware, integração de infraestrutura (como agentes de virtualização), entre outros, sem que isso desqualifique o nó para o licenciamento da infraestrutura. No entanto, isso se limita apenas a agentes e componentes relacionados, como pods de controlador dos operadores, e não inclui o conjunto de soluções de software personalizado ou de terceiros. Exemplos de softwares que não são da Red Hat e se qualificam como carga de trabalho de infraestrutura:

• Agentes de monitoramento personalizados e externos
• Drivers e controladores (plug-ins) da interface de rede do container (CNI) e da interface de armazenamento em container (CSI)
• Aceleradores para capacitação de virtualização e hardware
• Pods de controlador usados em operadores (software personalizado ou externo) e definições de recursos personalizados (CRDs) do Kubernetes

Nenhum outro tipo ou instância de aplicações do usuário final pode ser executado em um nó de infraestrutura usando os direitos inclusos. Para executar outras cargas de trabalho de infraestrutura como instâncias de aplicação no Red Hat OpenShift, essas instâncias precisam ser executadas em nós de aplicação regulares com subscrições válidas do Red Hat OpenShift. Verifique com a Red Hat se uma aplicação ou um serviço se qualifica como carga de trabalho de infraestrutura. 

Direitos do Red Hat Enterprise Linux

Os direitos do Red Hat Enterprise Linux para nós de computação e infraestrutura do OpenShift estão inclusos no OpenShift Kubernetes Engine, OpenShift Container Platform e OpenShift Platform Plus. Isso também inclui direitos de pods para aplicações e de sistema operacional guest para VMs. No entanto, a subscrição do Red Hat OpenShift não inclui outros direitos para os nós do Red Hat Enterprise Linux, exceto pelo seguinte:

• Um nó do Red Hat Enterprise Linux usado especificamente para o provisionamento da Installer-Provisioned Infrastructure (IPI) bare metal.

O OpenShift Virtualization Engine  não inclui o Red Hat Enterprise Linux para nós de computação e infraestrutura nem para direitos de sistema operacional guest de VMs. Os guests do Red Hat Enterprise Linux no OpenShift Virtualization Engine exigem uma subscrição do Red Hat Enterprise Linux for Virtual Datacenters ou uma subscrição por VM.

Os direitos do Red Hat Enterprise Linux não estão inclusos para serviços de hospedagem de nós externos usados pelo OpenShift, como proxies de Internet, balanceadores de carga e mirror registry. O Red Hat Satellite não está incluído como parte dos direitos.

Realize boostrap no registro de containers para espelhar imagens de container do OpenShift

Incluso como parte da subscrição do Red Hat OpenShift, o mirror registry é um direito do Quay que tem como único objetivo facilitar o processo de espelhamento do conteúdo exigido para realizar bootstrap em clusters do OpenShift desconectados. Esse é um direito com suporte limitado referente a uma implantação mínima do Quay criada por um instalador específico. Com ele, você pode executar um registro do Quay em um host pré-provisionado e gerenciado pelo cliente do Red Hat Enterprise Linux.

Observação: você pode usar o Quay como um mirror registry com o objetivo exclusivo de espelhar o payload de release do OpenShift, o conteúdo do OperatorHub, além de imagens de exemplo do operador, imagens gráficas do Cincinnati e imagens relacionadas às ofertas do Red Hat OpenStack Platform, como Red Hat OpenStack Services on OpenShift e Red Hat OpenShift Data Foundation.

O mirror registry para OpenShift não deve ser usado como um registro geral que funciona em escala arbitrária. No entanto, é possível armazenar nele um conjunto limitado de imagens personalizadas que contém softwares auxiliares. Por exemplo, agentes e imagens de container para cargas de trabalho de infraestrutura qualificadas. Os exemplos incluem:

• Agentes de monitoramento
• Provedores de CNI e CSI
• Agentes para capacitação de virtualização e hardware
• Operadores que oferecem suporte a serviços de fornecedor de software independente (ISV)
• Operadores personalizados como controladores de implantação

Control planes hospedados

A infraestrutura clássica do OpenShift exige pelo menos três nós de control plane para cada cluster do OpenShift. Uma alternativa é usar control planes hospedados, que são executados em um cluster central e concedem o control plane lógico para os clusters do OpenShift. Como de praxe, os nós de control plane e infraestrutura não são contabilizados nas subscrições, mas devem ser considerados na arquitetura.

É possível executar control planes hospedados em qualquer cluster bare metal do OpenShift. No entanto, os nós de computação desses clusters vão precisar de direitos que estejam alinhados à infraestrutura em que eles são executados. Por exemplo, os clusters virtuais hospedados no OpenShift Virtualization Engine vão exigir subscrições de par de núcleos para os nós de computação. Já as subscrições de par de soquetes bare metal são aplicáveis aos clusters cujo control plane é hospedado por um cluster do OpenShift Virtualization Engine e usa nós de computação bare metal.

Exceção 1: execução de instâncias de aplicação em nós de control plane ou de infraestrutura

Por padrão, os nós de control plane do OpenShift não são usados como nós de computação. Por isso, eles não executam instâncias de aplicação. Um nó de control plane vai exigir uma subscrição completa do Red Hat OpenShift se ele executar apenas componentes complementares do cluster do OpenShift ou aplicações do usuário final. Se você quiser usar um nó de control plane para hospedar aplicações do usuário final, todos os núcleos vão exigir subscrições. Consulte a seção de nós de infraestrutura para identificar as cargas de trabalho qualificadas que não exigem subscrição.

Exceção 2: implantação de clusters compactos

Em implantações de cluster compacto, como o OpenShift de três nós, as cargas de trabalho de aplicações do usuário final são executadas nos nós de control plane. Você precisa contabilizar os núcleos nos três nós das subscrições do Red Hat OpenShift, seja qual for a função desempenhada por eles.

Uma instância do OpenShift de nó único implanta todos os serviços do OpenShift e aplicações de usuário final em um nó físico ou virtual, com otimizações para reduzir a área de ocupação e maximizar os recursos disponíveis para as aplicações. Assim como acontece com os clusters compactos de três nós acima, esse modelo de implantação não tem acomodações especiais: todos os núcleos no nó precisam de direitos.

Recuperação de desastres

A Red Hat define três tipos de ambientes de recuperação de desastres (DR): quente, morno e frio. Você só precisa de uma subscrição paga do Red Hat OpenShift para sistemas de DR quente.

• Os sistemas de DR quente são definidos como totalmente funcionais e executados de maneira simultânea aos sistemas de produção. Eles estão prontos para receber tráfego de imediato e para assumir o controle no caso de um desastre no ambiente principal. Quando os volumes de dados são replicados de maneira síncrona ou assíncrona entre os clusters, eles são considerados como sistemas de DR "quente".
• Os sistemas de DR morna são definidos como já preparados para implantar e hospedar cargas de trabalho em containers que representam uma cópia exata do que está no local principal, mas não incluem cargas de trabalho do cliente presentes nos clusters de origem. Os sistemas de DR morna não devem participar de replicações de volumes de dados síncronas e assíncronas entre os clusters. Eles exigem que os dados do cliente sejam restaurados no hardware do cluster existente, fora do cluster.
• Os sistemas de DR fria são definidos como tendo infraestrutura, mas não toda a tecnologia necessária (hardware, software e dados) para restaurar serviços.

As subscrições são exigidas para clusters em hibernação que não são configurados e criados expressamente para DR morna ou fria. Por exemplo, clusters executados em serviços em nuvem que estão hibernando temporariamente devido à demanda reduzida. As subscrições também são exigidas quando clusters de DR morna ou fria são retirados da hibernação para executar cargas de trabalho. Retirar temporariamente um cluster da hibernação para manutenção de rotina ou testes não requer uma subscrição adicional para nenhum dos componentes nas ofertas de software do OpenShift.

No caso de DRs mornas e frias, as subscrições do Red Hat OpenShift podem ser transferidas do ambiente principal para o ambiente de recuperação no caso de um desastre. Assim, é possível restaurar os serviços e manter a conformidade com os termos de subscrição da Red Hat.

Migrações e upgrades swing

O Red Hat OpenShift 4 oferece upgrades locais entre versões secundárias. No entanto, se você está fazendo o upgrade do Red Hat OpenShift 3 ou precisa realizar um upgrade swing entre versões secundárias do Red Hat OpenShift 4 devido a manutenção ou outros motivos, a subscrição do Red Hat OpenShift cobrirá tanto a infraestrutura original como a de destino em uma migração unidirecional até que esse processo seja concluído. Durante a migração, as ferramentas de gerenciamento de subscrição da Red Hat mostrarão que seu ambiente está fora de conformidade com base no número de subscrições do Red Hat OpenShift que você comprou. A Red Hat permite essa situação no caso de upgrades para versões principais e não exige que você compre mais subscrições para entrar novamente em conformidade durante a migração. Por fim, o Red Hat OpenShift oferece ferramentas para ajudar nessas migrações e serviços de consultoria se necessários. Consulte a documentação sobre o kit de ferramentas de migração para containers.

Direitos para núcleos com hyper-threading

Para determinar se um nó específico do OpenShift usa um ou mais núcleos físicos, é preciso saber se esse sistema tem ou não vários threads por núcleo habilitados. Descubra como determinar se um sistema específico oferece suporte ao hyper-threading.

No caso de nós virtualizados do OpenShift que usam threads lógicos de CPU (também conhecidos como multithreading simultâneo [SMT] em CPUs AMD EPYC e hyper-threading em CPUs Intel), a utilização de núcleos nas subscrições do Red Hat OpenShift é calculada com base na quantidade de núcleos/CPUs atribuídos ao nó. No entanto, cada subscrição cobre quatro vCPUs/núcleos quando threads lógicos de CPU são usados. As ferramentas de gerenciamento de subscrição da Red Hat parte do pressuposto de que os threads lógicos de CPU são ativados por padrão em todos os sistemas.

As subscrições bare metal contabilizam apenas os núcleos físicos, e os threads lógicos de CPU não são considerados no cálculo da quantidade de subscrições necessárias para bare metal.

Arquiteturas alternativas (ARM, IBM Z, IBM LinuxONE e IBM Power)

Observação: embora apenas o IBM Z seja mencionado neste documento daqui para frente, todas as informações relacionadas a ele também se aplicam ao IBM LinuxONE.

O Red Hat OpenShift Container Platform também pode ser executado no ARM, IBM Z e IBM Power se os clientes usarem essas plataformas como padrão para criar e implantar microsserviços e aplicações nativas em nuvem. Somente o modelo de subscrição baseada em núcleo é compatível com as plataformas  IBM Z e IBM Power.

Os clusters do ARM recebem direitos usando as mesmas regras que o x86.

Para clientes do IBM Z, o Red Hat OpenShift não exige que todo o nó físico tenha direitos, mas apenas os núcleos usados por ele. Os clientes do IBM Z conhecem isso como direito de "subcapacidade". Os clientes que usam apenas um subconjunto dos núcleos disponíveis (capacidade de computação) no ambiente do IBM Z para o OpenShift Container Platform precisam de subscrições apenas para o subconjunto utilizado nos nós de computação. Isso se aplica seja qual for o tipo de particionamento de CPU: pools de CPU, capping, partições lógicas separadas (LPARs) ou outros meios.

Para sistemas IBM Z, um Integrated Facility for Linux (IFL) exige uma subscrição de par de núcleos núcleo do OpenShift. Quando nenhum particionamento é usado, até três IFLs podem ser identificados por cluster do OpenShift para control plane ou serviços de infraestrutura executados no host. Eles devem ser ativamente usados no control plane e/ou serviços de infraestrutura para se qualificarem e não exigem direitos do OpenShift. As implantações de cluster compacto de três nós exigem que todos os IFLs tenham direitos.

Os componentes do Red Hat OpenShift Platform Plus além do OpenShift Container Platform não são compatíveis com os sistemas IBM Z e IBM Power no momento, com as seguintes exceções:

• Uma subscrição independente do Red Hat Quay executada em arquiteturas x86 oferece um registro global de várias arquiteturas, como clusters do IBM Z e IBM Power. O próprio Red Hat Quay não funciona no IBM Z ou IBM Power.
• É possível instalar o Red Hat Advanced Cluster Management for Kubernetes em ambientes do IBM Z ou IBM Power, além de gerenciar os nós do Red Hat OpenShift executados em ambientes do IBM Z ou IBM Power.
• Com o Red Hat Advanced Cluster Security for Kubernetes, você protege os clusters executados no Red Hat OpenShift em ambientes do IBM Z ou IBM Power usando o operador do Red Hat Advanced Cluster Security.
• O Red Hat OpenShift Data Foundation oferece suporte completo à instalação no IBM Z ou IBM Power.

Os componentes da subscrição do Red Hat OpenShift Platform Plus têm níveis diferentes de suporte em arquiteturas alternativas (que não são x86). Consulte o artigo Matriz de disponibilidade de componentes em várias arquiteturas do Red Hat OpenShift Container Platform 4.16. Para ver detalhes sobre a interoperabilidade entre os componentes do OpenShift Platform Plus e as arquiteturas que não são x86, consulte as matrizes de compatibilidade do Red Hat OpenShift Container Platform, Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security, Red Hat Quay e Red Hat OpenShift Data Foundation.

O Red Hat OpenShift Kubernetes Engine e o Red Hat OpenShift Virtualization Engine não são compatíveis com o IBM Z e IBM Power.

Suporte a containers do Microsoft Windows Server

O OpenShift autogerenciado é compatível com um subconjunto de infraestruturas de instalação e funcionalidades do OpenShift que usam os containers do Microsoft Windows Server. Os containers do Windows Server são compatíveis somente com nós de computação baseados no Microsoft Windows Server. O control plane e o plano de infraestrutura do ambiente do OpenShift devem ser executados em um sistema x86 que usa o Red Hat Enterprise Linux ou o Red Hat Enterprise Linux CoreOS. Por isso, o suporte a containers do Windows Server é vendido como uma subscrição independente, com preços por núcleo.

A infraestrutura do Red Hat OpenShift Platform Plus e do Red Hat OpenShift Container Platform pode ser usada para implantar e gerenciar nós de computação do Windows Server. O suporte a containers do Microsoft Windows Server para subscrições do Red Hat OpenShift deve ser comprado como um complemento separado.

O Red Hat Advanced Cluster Management e o Red Hat Advanced Cluster Security não são compatíveis com o gerenciamento de nós do Microsoft Windows. No entanto, o Red Hat Quay executado em arquiteturas x86 é capaz de gerenciar imagens de containers em cargas de trabalho baseadas no Microsoft Windows Server.

Cada situação é única: as informações aqui mostradas são diretrizes, e não garantias

O Red Hat OpenShift oferece suporte a muitas funcionalidades e funções que afetam a escalabilidade, programação de pods, ociosidade e cota/limitação de recursos. Os cálculos anteriores são apenas diretrizes que ajudam você a ajustar seu ambiente para aprimorar o uso de recursos ou reduzir o tamanho total do ambiente. Os clientes do OpenShift Platform Plus devem considerar as necessidades das outras aplicações de software (Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security e Quay), incluindo recursos de armazenamento e computação, mesmo que elas não exijam mais subscrições de computação.

Caso você trabalhe com um revendedor externo, consulte os termos e contratos específicos dos serviços e soluções Red Hat. 

O Red Hat OpenShift Platform Plus inclui mais softwares além do OpenShift Container Platform para ajudar você a gerenciar e proteger o ambiente do OpenShift em escala e em vários clusters e nuvens. O Red Hat OpenShift Platform Plus está disponível nos modelos de subscrição de par de núcleos e de soquetes bare metal, com as limitações já mencionadas.

Os software extras inclusos no Red Hat OpenShift Platform Plus são geralmente limitados ao gerenciamento de nós com subscrições do OpenShift Platform Plus. Por exemplo, a subscrição do Red Hat Advanced Cluster Management incluso no OpenShift Platform Plus pode ser usada apenas para gerenciar nós e clusters do OpenShift Platform Plus. Clientes que também quiserem gerenciar clusters e nós não autorizados do OpenShift Platform Plus, como o Red Hat OpenShift Service on AWS clusters precisarão comprar subscrições adicionais do Red Hat Advanced Cluster Management para incluir esses clusters.

As subscrições adicionais de software não podem ser vendidas separadamente da subscrição do OpenShift Platform Plus. Por exemplo, você não pode comprar 100 subscrições do OpenShift Platform Plus, instalar 200 núcleos das subscrições do Red Hat OpenShift Container Platform e, separadamente, usar o Red Hat Advanced Cluster Management para gerenciar 200 núcleos do Azure Red Hat OpenShift com a mesma subscrição. Os software adicionais só podem ser usados para gerenciar os mesmos 200 núcleos em que o núcleo do software OpenShift Platform Plus está instalado.

As regras específicas para cada solução em camadas são:

• Red Hat Advanced Cluster Management for Kubernetes: com uma subscrição do OpenShift Platform Plus, você pode instalar quantas instâncias centrais do Red Hat Advanced Cluster Management forem necessárias para gerenciar o ambiente. A subscrição inclui o gerenciamento de todos os nós e clusters cobertos pelo OpenShift Platform Plus, como os nós de control plane e infraestrutura. Se você quiser gerenciar nós e clusters sem os direitos do OpenShift Platform Plus, será necessário comprar mais subscrições do Red Hat Advanced Cluster Management para esses ambientes. Isso é aplicável quando você também tem clusters cobertos pelo Red Hat OpenShift Kubernetes Engine ou OpenShift Container Platform autogerenciado, clusters executados em uma nuvem do OpenShift totalmente gerenciado ou ambientes de terceiros do Kubernetes compatíveis com o Red Hat Advanced Cluster Management. Você pode escolher gerenciá-los de maneira central a partir do console do Red Hat Advanced Cluster Management instalado no OpenShift Platform Plus ou a partir de uma aplicação central independente que seja compatível com os requisitos. Leia mais sobre as subscrições do Red Hat Advanced Cluster Management, os ambientes compatíveis com ele e as práticas recomendadas da solução.
• Red Hat Advanced Cluster Security for Kubernetes: com uma subscrição do OpenShift Platform Plus, você pode instalar quantas aplicações centrais do Red Hat Advanced Cluster Security forem necessárias para gerenciar o ambiente. A subscrição inclui o gerenciamento de todos os nós e clusters cobertos pelo OpenShift Platform Plus, como os nós de control plane e infraestrutura. Se você quiser gerenciar nós e clusters sem os direitos do OpenShift Platform Plus, será necessário comprar mais subscrições do Red Hat Advanced Cluster Security para esses ambientes. Isso é aplicável quando você também tem clusters cobertos pelo OpenShift Kubernetes Engine ou OpenShift Container Platform autogerenciado, clusters executados em uma nuvem do Red Hat OpenShift totalmente gerenciado ou ambientes de terceiros do Kubernetes compatíveis com o Red Hat Advanced Cluster Security. A Red Hat recomenda gerenciar cada ambiente com uma aplicação central independente do Red Hat Advanced Cluster Security. Leia mais sobre os ambientes compatíveis com o Red Hat Advanced Cluster Security.
• Red Hat Quay: com a subscrição do OpenShift Platform Plus, você pode instalar o Red Hat Quay em qualquer cluster coberto pelo OpenShift Platform Plus. Não há limite de quantidade de implantações do Quay que você pode instalar nos clusters do OpenShift Platform Plus. Assim, o Quay pode atender a qualquer ambiente Kubernetes com suporte que você quiser, como o OpenShift Platform Plus, outros clusters do OpenShift autogerenciado, serviços do OpenShift gerenciado e Kubernetes de terceiros compatível. Caso queira instalar o Quay em um ambiente que não seja do OpenShift Platform Plus, você precisará comprar outra subscrição do Red Hat Quay. O Quay também está disponível como uma oferta de software como serviço (SaaS) totalmente gerenciada.
• Red Hat OpenShift Data Foundation: com a subscrição do OpenShift Platform Plus, você pode instalar o Red Hat OpenShift Data Foundation Essentials em qualquer cluster coberto pelo OpenShift Platform Plus. Os direitos ao Red Hat Data Foundation são limitados às funcionalidades disponíveis no Essentials e a 256 TB de armazenamento de dados por cluster do OpenShift. É possível ampliar a funcionalidade e a capacidade com subscrições extras. Consulte o Guia sobre a subscrição do OpenShift Data Foundation (exige login no Portal do Cliente) ou entre em contato com um representante de vendas da Red Hat para receber mais orientações.

Já faz tempo que o OpenShift Virtualization é uma funcionalidade oferecida em todas as edições do OpenShift autogerenciado. Por isso, os clientes podem incluir cargas de trabalho de VM em aplicações nativas em nuvem e modernizar as VMs com microsserviços e containers.

Mudanças recentes no mercado de virtualização aumentaram a demanda por outras plataformas do tipo, especialmente aquelas que oferecem um caminho até a modernização. Muitos dos clientes não precisam de todos os recursos do OpenShift nas suas primeiras migrações de VMs e preferem uma edição do OpenShift autogerenciado que seja mais simples e mais barata para esses casos de uso.

O Red Hat OpenShift Virtualization Engine é uma edição do OpenShift autogerenciado destinada especificamente aos clientes que querem adotar uma plataforma diferente de virtualização para executar VMs. O OpenShift Virtualization Engine é coberto pelas subscrições de par de soquetes bare metal em servidores físicos e instâncias bare metal de hyperscalers compatíveis.

O OpenShift Virtualization Engine oferece apenas as funcionalidades necessárias para implantar, gerenciar e executar máquinas virtuais, como:

• VMs ilimitadas em hosts com subscrição.
• Não pode ser usado para executar em containers instâncias de aplicação (como de cliente ou software comercial), mas sim apenas em VMs.
• Não inclui subscrições para executar edições do Red Hat OpenShift em VMs (é necessário comprar subscrições de par de núcleos).
• Os direitos de guest do Red Hat Enterprise Linux para VMs não estão inclusos (é necessário comprar separadamente subscrições por VM ou do Red Hat Enterprise Linux for Virtual Datecenter).

A Red Hat agora oferece dois complementos para o OpenShift Virtualization Engine.

• O Red Hat Advanced Cluster Management for Virtualization oferece suporte às operações e gerenciamento do ciclo de vida de hipervisores e virtualização a um custo reduzido, em comparação com a versão completa do Advanced Cluster Management (uma subscrição por cada do OpenShift Virtualization Engine).
• O Red Hat Ansible® Application Platform for Virtualization oferece suporte ao nó de hipervisor que executa o OpenShift Virtualization Engine para fins de migração e operações do Dia 1 (uma subscrição por cada do OpenShift Virtualization Engine).

No caso dos clientes do Advanced Cluster Management e Ansible Application Platform, é possível usar as instalações existentes dessas aplicações centrais para oferecer suporte ao restante do ambiente. Além disso, eles podem gerenciar os hosts do OpenShift Virtualization Engine com a compra das subscrições complementares mencionadas.

No caso dos clientes sem aplicações centrais do Advanced Cluster Management ou Ansible Application Platform instaladas, a subscrição dos complementos mencionados também oferece suporte à instalação de aplicações centrais como containers de infraestrutura nos hosts do OpenShift Virtualization Engine. Consulte a documentação do Advanced Cluster Management e do Ansible Application Platform para ver como instalar essas aplicações centrais e conferir práticas recomendadas de arquitetura.

No caso dos clientes que precisam de automação do Dia 2 nas VMs, a recomendação é o Ansible Automation Platform. Além das subscrições de nó de hipervisor mencionadas acima, os clientes vão precisar de uma subscrição de nó para cada instância de VM. Consulte a documentação do Ansible Automation Platform para ver mais detalhes.

Embora os direitos do OpenShift Virtualization Engine restrinjam as instâncias de aplicação do cliente a apenas VMs, muitos dos requisitos de infraestrutura são executados como containers no Red Hat OpenShift. Esses requisitos incluem drivers de armazenamento, aplicações de backup, agentes de encaminhamento, Advanced Cluster Management e Ansible Automation Platform. Por isso, seus direitos permitem a execução dessas funcionalidades de infraestrutura em containers. Além disso, as soluções de armazenamento definido por software implementadas em VMs, mas executadas em containers, também são incluídas nos direitos. As orientações sobre o que se qualifica para esses containers de infraestrutura são as mesmas em relação a quais cargas de trabalho são permitidas nos nós de infraestrutura de outras edições do Red Hat OpenShift. Consulte a seção "O que não contabilizar" para ver informações sobre os nós de infraestrutura. Verifique com seu Red Hatter se uma aplicação ou um serviço se qualifica como carga de trabalho de infraestrutura para o OpenShift Virtualization Engine.

Para determinar quantas subscrições do OpenShift autogerenciado (Red Hat OpenShift Platform Plus, Red Hat OpenShift Container Platform e Red Hat OpenShift Kubernetes Engine) ou complementares são necessárias, use as perguntas e exemplos a seguir.

Em resumo:

• As aplicações são empacotadas em imagens de container ou VMs.
• Os containers e VMs são implantados como pods.
• Os pods são executados em nós de computação do OpenShift, que são gerenciados pelos nós de control plane.

Como determinar seus requisitos de direitos

As subscrições do Red Hat OpenShift não limitam as instâncias de aplicação. Você pode executar o máximo de instâncias no ambiente do Red Hat OpenShift compatíveis com a infraestrutura e hardware subjacentes. Hardwares de maior capacidade podem executar muitas instâncias de aplicações em um pequeno número de hosts, enquanto os de menor capacidade exigem muitos hosts para executar várias instâncias. O fator principal para determinar o tamanho de um ambiente do Red Hat OpenShift é a quantidade de pods ou instâncias de aplicação que estarão em execução.

Etapa 1: identificar a quantidade e tipo de instâncias de aplicação necessários

Comece pelas aplicações. Determine quantas instâncias de aplicação (ou pods) você planeja implantar. Ao dimensionar o ambiente, todo componente de aplicação implantado no Red Hat OpenShift é considerado como uma instância de aplicação. Isso inclui banco de dados, servidor estático de front-end e instância de VM.

A seguir, você encontra um exemplo para ajudar a determinar o tamanho do seu ambiente do Red Hat OpenShift. Você pode aprimorar ainda mais essas estimativas usando CPU, mais memória, cotas, limites e outras funcionalidades.

Tabela 1: perguntas sobre dimensionamento de aplicações e instâncias

Temos uma aplicação que inclui 200 instâncias de container, em que cada uma delas consome em média 1 vCPU e 4 GB de RAM. A utilização máxima ideal para nós é 80%. Executamos a aplicação na AWS e temos acesso aos tipos de instância M6i do EC2. Nossa aplicação não exige hardware ou aceleradores de IA específicos. Escolhemos o Red Hat OpenShift Platform Plus como nossa edição autogerenciada e, no momento, precisamos apenas de uma estimativa da quantidade de subscrições necessárias para nós.

Etapa 1: identificar a quantidade e tipo de instâncias de aplicação necessários

Usando as informações do exemplo:

• Número de instâncias de aplicação = 200
• Utilização máxima desejada do nó = 80%
• Requisito médio de vCPU da aplicação = 1 vCPU
• Volume médio de memória da aplicação = 4 GB

Etapa 2: determinar o total de memória e de núcleos necessário

Considerando os valores da etapa 1 no nosso cálculo:

• Utilização máxima = 80%
• Total de vCPU exigido = 1 vCPU × 200 × 1 / 80% = 250 vCPUs
• Total de memória exigido  = 4 GB × 200 × 1 / 80% = 1.000 GB

Etapa 3: escolha um nó de computação padrão

Com base nas informações apresentadas, não precisamos de um tipo de instância com GPU ou hardware especializado. Nossa proporção entre vCPU e memória é de 250 vCPUs por 1.000 GB, ou seja, 1:4. Felizmente, há vários tipos de instância disponíveis com essa proporção. Após analisar outros fatores exigidos pela nossa aplicação, determinamos que o tipo de instância m6i.4xlarge é mais adequado para nossas necessidades. Cada instância tem 16 vCPUs e 64 GB de memória.

Etapa 4: calcular o total de subscrições necessárias

Nesse caso, sabemos que precisamos de subscrições de par de núcleos, já que executamos nossa computação em uma nuvem de hyperscaler que usa vCPU. Por isso, utilizamos a fórmula da subscrição de par de núcleos mostrada na etapa 2.

Total de subscrições de par de núcleos = total de vCPU exigido / 4, (resultado arredondado)

250 vCPUs / 4 = 62,5 ou, arredondando, 63

Etapa 5: calcule o total de subscrições de acelerador de IA (se aplicável)

Isso não é aplicável a este exemplo de dimensionamento, já que não vamos usar aceleradores de IA.

Resultado

Neste exemplo, seriam necessárias 63 subscrições de par de núcleos do OpenShift Platform Plus.

Agora, queremos executar a mesma aplicação on-premises e em bare metal, provisionada em nós de computação de VM que usam a funcionalidade inclusa OpenShift Virtualization do Red Hat OpenShift. Ela inclui 200 instâncias de container, em que cada uma consome 1 vCPU e 4 GB de RAM. A utilização máxima ideal para nós é 80%. Nossa aplicação não exige hardware ou aceleradores de IA específicos. Escolhemos o Red Hat OpenShift Platform Plus como nossa edição autogerenciada e, no momento, precisamos apenas de uma estimativa da quantidade de subscrições necessárias para nós. Temos certa flexibilidade na configuração bare metal escolhida, mas estamos usando as definições de servidor padrão disponíveis.

Etapa 1: identificar a quantidade e tipo de instâncias de aplicação necessários

Usando as informações do exemplo:

• Número de instâncias de aplicação = 200
• Utilização máxima desejada do nó = 80%
• Requisito médio de vCPU da aplicação = 1 vCPU
• Volume médio de memória da aplicação = 4 GB

Etapa 2: determinar o total de memória e de núcleos necessário

Considerando os valores da etapa 1 no nosso cálculo:

• Utilização máxima = 80%
• Total de vCPU exigido = 1 vCPU × 200 × 1 / 80% = 250 vCPUs
• Total de memória exigido  = 4 GB × 200 × 1 / 80% = 1.000 GB

Etapa 3: escolha um nó de computação padrão

Nosso servidor padrão bare metal atual inclui 2 soquetes com 32 núcleos/64 vCPUs por soquete. Temos uma RAM de preferência. Como a proporção de vCPU para RAM é de 1:4, vamos conceder aos servidores 256 GB de RAM. Portanto, nossa opção bare metal escolhida é um servidor de 2 soquetes com 32 núcleos/64 vCPUs por soquete (64 núcleos/128 vCPUs por servidor) e 256 GB de RAM.

Etapa 4: calcular o total de subscrições necessárias

Em um servidor bare metal, implementamos subscrições de par de núcleos e de soquetes bare metal. Vamos calcular ambos:

Total de subscrições de par de núcleos = total de vCPU exigido / 4, (resultado arredondado)

250 vCPUs / 4 = 62,5 ou, arredondando, 63

Total de subscrições de par de soquetes:

• Total de servidores necessários = 250 vCPUs / 128 vCPUs por servidor, arredondado = 2 servidores
• Total de subscrições necessárias por servidor = número de núcleos por par de soquetes / 128. Arredondado, o cálculo é 64 / 128 = 0,5, que equivale a 1 subscrição
• 2 servidores × 1 subscrição/servidor = 2 subscrições de par de soquetes bare metal

Nesse caso, como conseguimos selecionar um servidor para ter a proporção certa de vCPU para memória, não precisamos calcular o número de servidores necessários para atender aos requisitos de memória e pudemos escolher o maior dos dois servidores. Se o servidor escolhido tiver outra quantidade de RAM, será necessário considerar essa diferença.

Etapa 5: calcule o total de subscrições de acelerador de IA (se aplicável)

Isso não é aplicável a este exemplo de dimensionamento, já que não vamos usar aceleradores de IA.

Resultado

Neste exemplo, seriam necessárias 63 subscrições de par de núcleos do OpenShift Platform Plus ou 2 subscrições de par de soquetes bare metal . Cabe a você decidir a melhor opção com base nos seus requisitos financeiros e de arquitetura. 

Vamos migrar nossas máquinas virtuais de outro hipervisor para a Red Hat. O ambiente é misto, mas identificamos os seguintes valores de diferentes tamanhos de máquinas virtuais:

• 1.000 small = 1.000 vCPUs, 4.000 GiB. Há também 228 GiB de custos indiretos de memória
• 300 medium = 600 vCPUs, 2.400 GiB. Há também 73 GiB de custos indiretos de memória
• 200 large = 800 vCPUs, 4.800 GiB. Há também 58 GiB de custos indiretos de memória
• 200 xlarge = 1.600 vCPUs, 9.600 GiB. Há também 64 GiB de custos indiretos de memória

Etapa 1: identificar a quantidade e tipo de instâncias de aplicação necessários

Usando as informações do exemplo:

• Número de instâncias de aplicação = 1.700
• Total de vCPUs = 4.000 vCPUs
• Total de memória = 20.800 GB + custos indiretos de 423 GB = 21.223 GB
• Requisito médio de vCPU da aplicação = 2,4 vCPUs
• Volume médio de memória da aplicação = 12,5 GB

Etapa 2: determinar o total de memória e de núcleos necessário

Considerando os valores da etapa 1 no nosso cálculo:

• Total de memória exigido = 20.800 GB + custos indiretos de 423 GB = 21.223 GB
• Total de vCPUs exigido = 4.000 vCPUs

A métrica de utilização máxima das VMs é um pouco diferente em relação aos containers. No entanto, os administradores de virtualização já estão familiarizados com ela.

Em geral, como não recomendamos a superalocação de memória para as VMs, os requisitos de total de memória acabam sendo o fator principal para determinar a quantidade de nós de computação.

No caso dos recursos de computação, a superalocação de CPU é esperada, já que a maioria das VMs em média não usam todos os recursos de computação delas. Como a proporção máxima de superalocação de CPU para o OpenShift Virtualization é definida como 10:1, escolher uma opção como 4:1 é razoável. É aqui que também decidimos se vamos igualar uma vCPU usando núcleos ou threads (com suporte para hyper-threading, cada núcleo pode ser dois threads). Podemos fazer uma escolha razoável de 1 vCPU = 1 núcleo, sem incluir hyper-threading. Agora, nossos requisitos são:

• Total de memória exigido = 20.800 GB + custos indiretos de 423 GB = 21.223 GB
• Total de núcleos exigido = 4.000 vCPUs × 1/4 × 1 núcleo/vCPU = 1.000 núcleos

Etapa 3: escolha um nó de computação padrão

A escolha de um nó de computação bare metal para virtualização depende de vários fatores, como redundância e domínios de falha, tamanho de clusters etc. Há diferentes opções on-premises, como aumentar a RAM por servidor. Como a memória costuma determinar os requisitos de servidor, podemos começar por aqui.

Temos 1.700 VMs e queremos usar um servidor com dois soquetes e 32 núcleos por soquete. Usando a contagem de núcleos para corresponder ao número de servidores, vamos precisar de:

• 1.000 núcleos / 64 núcleos/servidor, arredondado = 16 servidores

Com 16 servidores, vamos precisar de 21.223 GB / 16 servidores = 1.326 GB de RAM por servidor. Com nosso servidor, podemos escolher 1.536 GB de RAM. Agora, nossa configuração bare metal é:

• Um servidor de 2 soquetes com 32 núcleos/soquetes (64 núcleos no total) e 1.536 GB de RAM

Por fim, 16 servidores com essa configuração produzem o total de:

• 16 x 64 núcleos = 1.024 núcleos
• 16 x 1.536 GB = 24.576 GB de memória

Isso é suficiente para executar as cargas de VM, mas exige servidores extras para possibilitar a redundância. No momento, não podemos nos dar ao luxo de perder nenhum servidor devido a uma interrupção ou impactos graves no desempenho. Os administradores de virtualização recomendam reservar 25% da capacidade para failover e redundância. Por isso, vamos precisar de:

• 16 servidores + (16 servidores × 25%) = 20 servidores no total

Vamos distribuir as VMs por todos os 20 servidores para conseguirmos atender aos requisitos delas mesmo se perdermos de 1 a 4 servidores. (Seus requisitos de resiliência podem ser diferentes.)

Etapa 4: calcular o total de subscrições necessárias

Nos casos de uso somente de virtualização, vamos usar o OpenShift Virtualization Engine, disponível apenas nas subscrições de par de soquetes bare metal.

Total de subscrições de par de soquetes :

• Total de servidores necessários = 20
• Total de subscrições necessárias por servidor= 1, já que nossos servidores atingem o máximo de 64 núcleos/par de soquetes
• 20 servidores × 1 subscrição/servidor = 20 subscrições de par de soquetes bare metal

Etapa 5: calcule o total de subscrições de acelerador de IA (se aplicável)

Isso não é aplicável a este exemplo de dimensionamento, já que não vamos usar aceleradores de IA.

Resultado

Neste exemplo, seriam necessárias 20 subscrições de par de soquetes bare metal do OpenShift Virtualization Engine . 

Tabela 1: diferenças gerais de funcionalidade por edição do Red Hat OpenShift

Tabela 2: diferenças detalhadas entre as edições do Red Hat OpenShift, incluindo os operadores que oferecem essas funcionalidades

Observação: o operador OpenShift Elasticsearch incluído no Red Hat OpenShift é licenciado apenas para oferecer suporte às necessidades de pesquisa da infraestrutura interna dos clusters do OpenShift. Ele não pode ser usado de maneira autônoma em aplicações do cliente.

Software comum da Red Hat não incluído nas edições do Red Hat OpenShift

A menos que especificado de outra forma, as ofertas de software da Red Hat a seguir, que costumam ser usadas com o OpenShift, precisam receber direitos separadamente. O Red Hat OpenShift Platform Plus inclui o Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security, Red Hat Quay e Red Hat OpenShift Data Foundation Essentials. Outras subscrições do OpenShift autogerenciado não incluem essas soluções extras, mas elas podem ser compradas separadamente. Estes são os outros softwares da Red Hat usados com o Red Hat OpenShift, mas não incluídos neste guia de subscrição:

• Red Hat Ansible Automation Platform
• Red Hat Application Foundations
• Red Hat Enterprise Linux AI
• Portfólio do Red Hat Integration, como 3scale, AMQ, Camel K, Fuse etc.
• Red Hat JBoss EAP
• Pacotes do Red Hat Middleware
• Red Hat OpenShift Developer Hub (build desenvolvido pela Red Hat do projeto Backstage)
• Red Hat OpenShift AI
• Red Hat Satellite (para o gerenciamento do Red Hat Enterprise Linux)
• IBM CloudPaks

Fale com seu parceiro ou revendedor Red Hat para descobrir mais detalhes sobre as ofertas acima.