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 seu ambiente do OpenShift. Informações mais precisas sobre dimensionamento 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. É definido como dois núcleos físicos ou quatro unidades virtuais de processamento central (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 múltiplas instâncias de computação em nuvem, máquinas virtuais (VMs) e servidores físicos.
• Nó bare metal: outra base das subscrições do OpenShift autogerenciado. É necessário ter uma subscrição de nó bare metal por servidor físico. Uma subscrição desse tipo não pode abranger mais de um servidor, e seus núcleos não podem se estender para mais de um servidor.
• Acelerador de IA: a quantidade necessária de subscrições do Red Hat AI Accelerator é baseada no número de dispositivos complementares de hardware que aceleram determinadas funções de recursos computacionais fora das unidades centrais de processamento (CPUs). Isso inclui, entre outros, unidades de processamento gráfico (GPUs) discretas, 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 da Red Hat. As duas opções disponíveis são suporte Standard em horário comercial e Premium em tempo integral.
• Nó de recursos computacionais: 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 recursos computacionais. Esse tipo de nós exige subscrições do OpenShift. Os nós do plano de controle e infraestrutura que oferecem suporte aos nós de recursos computacionais não exigem subscrições, mas podem gerar custos.
• Nós de plano de controle: 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 do nó de plano de controle 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 plano de controle 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 ingress. Os direitos do 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 plano de controle, nós de infraestrutura opcionais e um ou mais nós de recursos computacionais.
• Instância de aplicação: uma aplicação pode ser uma única instância de pod ou estar implantada em múltiplas 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, é compatível com infraestruturas físicas, virtuais e on-premise e com 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. O foco deste guia é o 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 é compatível com ambientes on-premise (usando servidores físicos, virtualização e nuvem privada) e determinadas nuvens públicas. 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 na Amazon Web Services (AWS) e no 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 ter mais informações 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 desenvolver, 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 empresarial de nuvem híbrida para desenvolver, implantar, executar e gerenciar aplicações inteligentes em grande escala e em múltiplos clusters e ambientes de nuvem. Há múltiplas camadas de segurança, capacidade de gerenciamento 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 hypervisor 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, segmentada para cargas de trabalho exclusivas de máquinas virtuais. 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 nó bare metal), com dois níveis de suporte para cada um.

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

1. Par de núcleos (dois núcleos ou quatro 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 recursos computacionais 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 suporte Standard em horário comercial e Premium em tempo integral.

2. Nó bare metal (um nó físico) 

• Um nó físico representa um servidor, independentemente do número de soquetes de CPU no servidor ou de núcleos nas CPUs.
• 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 está instalado diretamente no hardware. Hypervisors de terceiros não são permitidos.
• Isso explicitamente 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 hypervisor).
• Disponível com suporte Standard em horário comercial e Premium em tempo integral.

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

1.  Acelerador de IA (um acelerador)

• Essa subscrição é necessária para as placas aceleradoras (GPU, TPU, NPU, FPGA, DPU etc.) de recursos computacionais de cargas de trabalho de IA que são complementos discretos, 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 caso a capacidade de aceleração de recursos computacionais não esteja sendo usada. Por exemplo, DPUs usadas como SmartNICs apenas para aceleração de rede, mesmo quando elas têm núcleos ARM acessíveis não utilizados ou GPUs aplicadas à renderização de gráficos, e não à aceleração de IA.
• Disponível com suporte Standard em horário comercial e Premium em tempo integral. Deve ter o mesmo SLA da subscrição de par de núcleos ou nó bare metal compatível.

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 hypervisor). Observe que, dependendo da densidade dos pods de recursos computacionais, as subscrições de nó bare metal podem oferecer maior custo-benefício.

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 subscrições de nó bare metal do próprio hypervisor. É possível comprar separadamente subscrições de par de núcleos do OpenShift autogerenciado e atribuí-las às VMs desse ambiente, assim como qualquer outra aplicação que você compra e executa como VM. Nessa instância, ocorre densidade de núcleos, e a troca para o modelo de nó bare metal do OpenShift autogerenciado pode oferecer maior custo-benefício, já que inclui containers ilimitados do OpenShift em servidores bare metal e suporte para executá-los em VMs do OpenShift.

É possível distribuir as subscrições de par de núcleos para cobrir todos os nós de recursos computacionais 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 recursos computacionais em todos os clusters do OpenShift em execução nos seus ambientes de nuvem híbrida.

Quando escolher as subscrições de nó bare metal

As subscrições de nó bare metal são a única opção para os nós de recursos computacionais do OpenShift implantados em servidores físicos dedicados, seja no data center ou em nuvens privadas hospedadas ou hyperscalers em ofertas bare metal compatíveis. 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 nó bare metal concede direitos a um único nó físico, independentemente do número total de soquetes ou núcleos de CPU.

Por conta da arquitetura do Kubernetes, cada servidor bare metal físico que usa direitos por nó pode ser utilizado somente como um nó do OpenShift. 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 hypervisors 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 nó, 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 bare metal de hospedagem.

É importante notar que a subscrição do OpenShift Virtualization Engine não oferece suporte para instâncias de aplicação em container. A única exceção são as cargas de trabalho de infraestrutura, conforme definido na seção abaixo sobre o OpenShift Virtualization Engine. Se você quiser executar suas 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 nó 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 subscrições de par de núcleos e nó 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 nó que cobrem o nó de recursos computacionais.
• Um nó de recursos computacionais virtuais com um dispositivo de GPU físico apresentado às VMs como múltiplas 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 recursos computacionais 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
• Hosted control planes do Red Hat OpenShift
• Ansible Automation Platform, quando usado apenas para gerenciamento de clusters

Você pode implantar e executar agentes de terceiros e personalizados, além de ferramentas para monitoramento, coleta e encaminhamento de dados de log, drivers de hardware e integração de infraestrutura (como agentes de virtualização) nos nós de infraestrutura sem desqualificar o nó para licenciamento da infraestrutura. Todavia, isso se limita somente a agentes e componentes relacionados, incluindo pods de controlador para operadores, mas sem 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 terceiros ou personalizados de monitoramento.
• 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 de terceiros) 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 infraestrutura provisionada pelo instalador (IPI) bare metal.

O OpenShift Virtualization Engine não inclui o Red Hat Enterprise Linux para nós de recursos computacionais e de infraestrutura nem para direitos de sistema operacional guest para 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 mirror registry com o objetivo exclusivo de espelhar o payload de versão 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 tem a intenção de ser um registro de uso 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

Hosted control planes

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 hosted control planes em qualquer cluster bare metal do OpenShift. No entanto, os nós de recursos computacionais desses clusters vão precisar de direitos que estejam alinhados à infraestrutura em que são executados. Por exemplo, os clusters virtuais hospedados no OpenShift Virtualization Engine exigem subscrições de par de núcleos para os nós de recursos computacionais. Já as subscrições de nó bare metal são aplicáveis aos clusters cujo plano de controle é hospedado por um cluster do OpenShift Virtualization Engine e usa nós de recursos computacionais bare metal.

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

Por padrão, os nós de plano de controle do OpenShift não são usados como nós de recursos computacionais. 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 plano de controle. 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.

• Por definição, os sistemas de DR quente são totalmente funcionais e executados simultaneamente com os 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 o armazenamento definido por software hospedado no OpenShift replica os volumes de dados 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 clusters de DR morna não devem participar da replicação ativa de volumes de dados entre clusters, seja de forma síncrona ou assíncrona, quando o site secundário (DR) estiver montando esses dados em cargas de trabalho de container ativas no cluster. Os dispositivos de armazenamento externo que executam a replicação de volumes ainda são considerados DR morna. Para o armazenamento definido por software hospedado no OpenShift, eles exigem que os dados do cliente sejam restaurados no hardware do cluster existente, oriundos de fora do cluster.
• Os sistemas de DR fria têm a infraestrutura pronta, mas a tecnologia completa (hardware, software e dados) necessária para restaurar o serviço não está em vigor. 

São necessárias subscrições 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 necessárias quando clusters de DR morna ou fria são retirados da hibernação para executar cargas de trabalho. Tirar um cluster da hibernação temporariamente para manutenção ou testes de rotina não exige uma subscrição adicional para nenhum dos componentes das ofertas de software do Red Hat 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 migration toolkit for containers.

Direitos de 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 múltiplas linhas por núcleo habilitado. Descubra como determinar se um sistema específico é compatível com hyper-threading. 

No caso de nós virtualizados do OpenShift que usam linhas lógicas 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 linhas lógicas de CPU são usadas. 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 as linhas lógicas de CPU não são consideradas 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 poderá ser executado no Arm, IBM Z e IBM Power se os clientes usarem essas plataformas como padrão para desenvolver 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. As subscrições de bare metal baseado em soquete do Red Hat OpenShift não podem ser usadas com as plataformas IBM Z e IBM Power. 

Os clusters do Arm recebem direitos com as mesmas regras do x86.

Para clientes do IBM Z, o Red Hat OpenShift não exige que todo o nó físico tenha direitos, apenas os núcleos usados pelo OpenShift. 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 a todos os tipos de particionamento de CPU: pools de CPU, capping, partições lógicas separadas (LPARs) ou outros meios. 

Para o IBM Z, um Integrated Facility for Linux (IFL) exige uma subscrição de núcleo do OpenShift. O IBM Z é a única arquitetura em que a base das subscrições é um único núcleo. Essa arquitetura não aplica o conceito de vCPU. Quando nenhum particionamento é usado, até três IFLs podem ser identificados por cluster do OpenShift para o plano de controle ou serviços de infraestrutura executados no host. Eles devem ser usados ativamente para o plano de controle e/ou serviços de infraestrutura para se qualificar e não exigem direitos do OpenShift. Em implantações compactas de clusters de três nós, todos os IFLs precisam ter direitos. 

O IBM Power usa o modelo de subscrição de par de núcleos. Essa arquitetura não aplica o conceito de vCPU.

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.19" no Red Hat Customer Portal (requer acesso por login). 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 apenas com nós de recursos computacionais 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 subscrição autônoma com preço por núcleo.

A infraestrutura do Red Hat OpenShift Platform Plus, Red Hat OpenShift Container Platform e Red Hat OpenShift Kubernetes Engine pode ser usada para implantar e gerenciar nós de recursos computacionais do Windows Server. O suporte a containers do Microsoft Windows Server em 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 computacionais e de armazenamento, mesmo que elas não exijam mais subscrições de recursos computacionais.

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

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

O software extra incluso no Red Hat OpenShift Platform Plus geralmente limita-se 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 seu ambiente. A subscrição inclui o gerenciamento de todos os nós e clusters cobertos pelo OpenShift Platform Plus, como os nós de plano de controle e infraestrutura. Se você quiser gerenciar nós e clusters sem os direitos do OpenShift Platform Plus, será necessário comprar subscrições adicionais 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 separada que seja compatível com seus requisitos. Mais informações 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 seu ambiente. A subscrição inclui o gerenciamento de todos os nós e clusters cobertos pelo OpenShift Platform Plus, como os nós de plano de controle e infraestrutura. Se você quiser gerenciar nós e clusters sem os direitos do OpenShift Platform Plus, será necessário comprar subscrições adicionais 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 separada do Red Hat Advanced Cluster Security. Mais informações 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. Dessa forma, o Quay pode atender a qualquer ambiente Kubernetes compatível que você quiser, incluindo o ambiente do OpenShift Platform Plus, outros clusters autogerenciados do OpenShift e serviços gerenciados do OpenShift e Kubernetes de terceiros que sejam compatíveis. Caso queira instalar o Quay em um ambiente fora 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. Veja o Guia de subscrição do OpenShift Data Foundation (requer login no Customer Portal) ou faça uma consulta com um representante de vendas da Red Hat para receber mais orientação.
• Argo CD Agent: com a subscrição do OpenShift Platform Plus, você pode instalar o componente Argo CD Agent do Red Hat OpenShift GitOps em qualquer cluster coberto pelo OpenShift Platform Plus. O Argo CD Agent pode ser executado no Red Hat OpenShift ou em ambientes Kubernetes compatíveis. O Red Hat OpenShift GitOps está incluso no OpenShift Container Platform.

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 de modernização. O foco exclusivo dos clientes é a virtualização, com a opção de adotar recursos modernos de desenvolvimento de aplicações e conteinerização no próprio ritmo.

O Red Hat OpenShift Virtualization Engine é uma edição do OpenShift autogerenciado destinada especificamente a clientes que querem adotar uma plataforma de virtualização diferente para executar VMs. O OpenShift Virtualization Engine é coberto pelas subscrições de nó bare metal em servidores físicos e instâncias bare metal de hyperscalers compatíveis. Quando os usuários estão prontos para fazer o upgrade para o portfólio mais amplo, basta alterar os direitos da subscrição, sem a necessidade de reimplantar os clusters existentes.

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 separadas).
• Os direitos de guest do Red Hat Enterprise Linux para VMs não estão inclusos (é necessário comprar separadamente subscrições separadas por VM ou do Red Hat Enterprise Linux for Virtual Datecenters).

O Red Hat Advanced Cluster Management e o Red Hat Ansible® Automation Platform são compatíveis com o OpenShift Virtualization Engine. Para casos de uso somente de virtualização, as subscrições adicionais de ambas as soluções estão disponíveis a um custo reduzido em comparação com a versão completa. 

Os clientes do Red Hat Advanced Cluster Management e Ansible Automation Platform podem usar suas 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 adicionais mencionadas. 

No caso dos clientes sem aplicações centrais do Red Hat Advanced Cluster Management ou Ansible Automation Platform instaladas, as subscrições adicionais mencionadas também oferecem suporte à instalação de aplicações centrais como containers de infraestrutura nos hosts do OpenShift Virtualization Engine. Consulte a documentação do Red Hat Advanced Cluster Management e do Ansible Automation Platform para aprender a 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 hypervisor 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, Red Hat 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 recursos computacionais do OpenShift, que são gerenciados pelos nós de plano de controle.

Como determinar seus requisitos de direitos 

As subscrições do Red Hat OpenShift não limitam as instâncias de aplicação. No ambiente do Red Hat OpenShift, você pode executar o máximo de instâncias que a infraestrutura e hardware subjacentes aceitarem. 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: identifique a quantidade e o 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 bancos de dados, servidores estáticos de front-end e instâncias de VM.

Pode ser um número aproximado 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

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

Depois de determinar os requisitos de uma instância de aplicação e a quantidade de instâncias, é fácil identificar o total de recursos necessários, incluindo recursos computacionais e memória. 

Nesta etapa, vamos determinar a utilização máxima que os nós de recursos computacionais devem alcançar. Isso possibilita que haja uma variação normal na aplicação antes de a escala automática ser necessária e acomoda a despesa operacional de gerenciamento do OpenShift. Para ver mais detalhes, consulte a documentação, mas normalmente se trata de um núcleo ou uma vCPU e 1 GB de memória de acesso de leitura (RAM) por nó de computação. No caso de utilização intensa (maior do que 80%), você precisará considerar explicitamente os requisitos de despesa operacional do OpenShift nos cálculos de recursos de memória e núcleo.

Nos casos de uso de virtualização, será necessário considerar a alocação extra de CPU e memória, as preocupações com redundância e alta disponibilidade e a arquitetura geral do ambiente. Você entenderá melhor isso ao dimensionar o exemplo 3.

Tabela 2: perguntas sobre utilização máxima preferencial dos nós do OpenShift

Utilização máxima = porcentagem escolhida pelos arquitetos

Total de núcleos (ou vCPUs) exigidos = núcleos de 1 aplicação × quantidade de instâncias de aplicação × 1 / porcentagem de utilização

Total de memória exigida = memória de 1 aplicação × quantidade de instâncias de aplicação × 1 / porcentagem de utilização

Etapa 3: escolha um nó de recursos computacionais padrão (VM, instância de nuvem ou servidor bare metal)

Agora, você tem o total de núcleos e memória a ser acomodado. A próxima etapa é escolher um nó de computação padrão para implantar os nós de trabalho das suas aplicações. 

Em uma infraestrutura de virtualização, o ambiente pode permitir que você escolha a configuração das VM que vão servir o nós de computação. Caso contrário, você talvez tenha que escolher um dos vários tipos de VM padrão baseados na sua necessidade. 

Em uma nuvem de hyperscaler, você geralmente precisa escolher uma instância de computação em nuvem com computação, memória e acesso diferentes para os equipamentos opcionais como aceleradores de IA. 

No caso de implantações em bare metal, seja on-premises ou em uma instância bare metal de hyperscaler, pode haver uma configuração de servidor padrão, ou às vezes você pode precisar especificar a configuração. 

Sempre que possível, escolha nós de computação que estejam mais alinhados à proporção ou requisitos de núcleo ou memória. Por exemplo, imagine que o requisito total para seus containers é de 400 vCPUs e 1.600 GB de RAM. Para ter as melhores proporções de consolidação regular, basta escolher nós de recursos computacionais que tenham proporção aproximada de 1:4 para vCPU e memória. 

Tabela 3: perguntas sobre dimensionamento de VM e hardware

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

Por fim, determine o número de subscrições do Red Hat OpenShift necessárias com base nos dados que você coletou nas etapas 1 a 3. No caso de instâncias de nuvem de hyperscaler ou VMs, use o modelo de subscrição de par de soquetes. No caso de servidores bare metal, calcule a quantidade de subscrições considerando os dois modelos: compare as diferenças de custo e flexibilidade entre eles e escolha a melhor opção para suas necessidades. 

Para o modelo de subscrição de par de núcleos

• Número de subscrições de par de núcleos do OpenShift autogerenciado¹ 

= total de núcleos / 2 (arredondado) ou

= total de vCPUs / 4 (arredondado)

Para o modelo de subscrição de nó bare metal

• Primeiro, calcule o número de subscrições de par de núcleos necessárias para sua aplicação, já que esse modelo pode ser usado em uma instalação bare metal.
• Em seguida, determine o número de subscrições bare metal: cada servidor físico exige uma subscrição por nó.
• A seguir, compare as diferenças de custo e flexibilidade entre os dois modelos.
  • Finanças:
    • Um modelo de subscrição provavelmente será menos caro do que o outro no seu ambiente dimensionado.
    • No planejamento a longo prazo, considere um ponto de equilíbrio de capacidade que, ao ser ultrapassado, definirá que um modelo é melhor do que o outro em termos financeiros.
  • Arquitetura:
    • É possível usar subscrições de par de núcleos em qualquer lugar do seu ambiente (VMs, instâncias de nuvem e servidores bare metal). Já subscrições de nó bare metal são exclusivas para servidores bare metal.
    • As subscrições de par de núcleos em servidores bare metal precisam executar containers em bare metal e estar em um mesmo cluster.
    • É possível instalar o OpenShift Virtualization Engine nos servidores bare metal, além de subscrições de par de núcleos do OpenShift para os containers (OpenShift sobre OpenShift). Isso é mais adequado para ambientes mistos de VM com uma quantidade relativamente pequena de OpenShift por servidor.
    • Se você precisa de mais densidade de cargas de trabalho do Red Hat OpenShift em um servidor bare metal, a subscrição de nó bare metal oferece containers ilimitados do OpenShift diretamente em bare metal ou por meio da funcionalidade OpenShift Virtualization (dentro das VMs em execução no servidor).

Etapa 5: calcule o total de subscrições do AI Accelerator (se aplicável)

Adicione todas as subscrições de acelerador de IA acima. Você precisa de uma subscrição de acelerador de IA por acelerador físico on-premises ou em um servidor bare metal. Em um ambiente de nuvem de hyperscaler, os tipos de instância que viabilizam a computação acelerada vão mostrar uma lista da quantidade de GPUs físicas ou aceleradores que eles incluem. Não se esqueça de que o SLA da subscrição de acelerador de IA precisa ser igual ao da subscrição do Red Hat OpenShift.

Observação: 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 computacionais e de armazenamento, mesmo que não exijam mais subscrições de recursos computacionais.

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

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: identifique a quantidade e o 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 regular de vCPU da aplicação = 1 vCPU
• Volume regular de memória da aplicação = 4 GB

Etapa 2: determine 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 recursos computacionais padrão

Com base nas informações apresentadas, não precisamos de um tipo de instância com GPU ou hardware especializado. A proporção de vCPU:memória é de 250 vCPUs por 1.000 GB, ou 1:4. Felizmente, há diversos tipos de instância 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: calcule o total de subscrições necessárias

Nesse caso, sabemos que precisamos de subscrições de par de núcleos, já que executamos os recursos computacionais 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 do AI Accelerator (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-premise e em bare metal, provisionada em nós de recursos computacionais de VM que usam a funcionalidade OpenShift Virtualization inclusa no 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 prontas para uso.

Etapa 1: identifique a quantidade e o 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 regular de vCPU da aplicação = 1 vCPU
• Volume regular de memória da aplicação = 4 GB

Etapa 2: determine 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 recursos computacionais padrão

Nosso servidor bare metal padrão atual inclui dois 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 dois soquetes com 32 núcleos/64 vCPUs por soquete (64 núcleos/128 vCPUs por servidor) e 256 GB de RAM.

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

Em um servidor bare metal, implementamos subscrições de par de núcleos e de nó 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 nó = número total de servidores físicos

• Total de servidores necessários = 250 vCPUs / 128 vCPUs por servidor (arredondado = 2 servidores)
• 2 servidores × 1 subscrição/servidor = 2 subscrições de nó 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 núcleos de CPU ou RAM, será necessário considerar essa diferença.

Etapa 5: calcule o total de subscrições do AI Accelerator (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 duas subscrições de nó bare metal. Cabe a você decidir a melhor opção com base na sua arquitetura e recursos financeiros. 

Vamos migrar nossas máquinas virtuais de outro hypervisor para a Red Hat. O ambiente é misto, mas identificamos os seguintes números de máquinas virtuais com diferentes tamanhos:

• 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 memória como despesa operacional

Etapa 1: identifique a quantidade e o 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 + despesa operacional de 423 GB = 21.223 GB
• Requisito regular de vCPU da aplicação = 2,4 vCPUs
• Volume regular de memória da aplicação = 12,5 GB

Etapa 2: determine 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 + despesa operacional 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á devem estar 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 + despesa operacional 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 recursos computacionais padrão

A escolha de um nó de recursos computacionais bare metal para virtualização depende de vários fatores, como redundância e domínios de falha, tamanho dos 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: calcule 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 nó bare metal.

Total de subscrições de nó = 

• Total de servidores necessários = 20
• 20 servidores × 1 subscrição/servidor = 20 subscrições de nó 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 nó bare metal do OpenShift Virtualization Engine.

Tabela 1: diferenças gerais nas funcionalidades 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 1: o OpenShift Elasticsearch Operator 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 Advanced Developer Suite
• 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 Data Foundation Advanced
• 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.