Guía sobre las suscripciones a la versión autogestionada de Red Hat OpenShift

Este documento le permitirá conocer el modelo de suscripción a las ofertas autogestionadas de Red Hat® OpenShift® y le brindará instrucciones paso a paso para calcular la cantidad aproximada de autorizaciones de acceso que se necesitan para su entorno de Red Hat OpenShift. Si lo solicita, podemos brindarle información más precisa para determinar las dimensiones.

Primero, definamos ciertos términos que debe comprender:

• Par de núcleos: es una de las bases de las suscripciones a la versión autogestionada de OpenShift y consiste en 2 núcleos físicos o 4 vCPU. En una máquina de servidor dedicado (bare metal), siempre hace referencia al núcleo físico, independientemente de que se utilice tecnología de hyperthreading o de multithreading simétrico. Cuando se utiliza la primera opción, los 2 núcleos físicos que se presentan como 4 vCPU cuentan como un único par de núcleos. En las implementaciones de proveedores principales, como AWS, Azure y GCP, siempre se considera 4 vCPU como un solo par de núcleos. Las suscripciones de par de núcleos se cuentan para el clúster, por lo que pueden incluir varias instancias de nube, máquinas virtuales y servidores físicos.
• Par de sockets de servidor dedicado (bare metal): es otra de las bases de las suscripciones a la versión autogestionada de OpenShift. Por cada servidor, se requiere al menos una suscripción de par de sockets de servidor dedicado (bare metal), la cual abarca como máximo 128 núcleos. Una sola suscripción de par de sockets de servidor dedicado (bare metal) no puede incluir más de un servidor, y los núcleos en una suscripción no pueden abarcar más de un servidor. Para incluir más núcleos y sockets, se pueden combinar varias suscripciones de este tipo.
• AI Accelerator: la cantidad de suscripciones a Red Hat AI Accelerator que se requieren depende de la cantidad de dispositivos de hardware complementarios que aceleren ciertas funciones informáticas fuera de las unidades centrales de procesamiento (CPU). Estos pueden ser, entre otros, unidades gráficas de procesamiento (GPU) separadas, unidades de procesamiento tensorial (TPU), unidades de procesamiento de datos (DPU), matrices de puertas programables en campo (FPGA), circuitos integrados de aplicaciones específicas (ASIC) y unidades de procesamiento de red (NPU) que se instalan como complementos. No incluye aceleradores totalmente integrados a la CPU principal (como GPU integradas, NPU ni otros tipos de aceleradores). Si bien estos elementos se pueden virtualizar y presentar a más de una instancia o máquina virtual, y pueden tener uno o varios núcleos similares a los de la CPU, la suscripción se basa en la cantidad de dispositivos físicos.
• SLA: las suscripciones a Red Hat exigen un acuerdo de nivel de servicio (SLA) de soporte. Puede elegir entre dos opciones: Standard 8x5 o Premium 24x7.
• Nodos informáticos: instancias (hosts de servidores dedicados [bare metal] o máquinas virtuales) de Red Hat Enterprise Linux® o Red Hat Enterprise Linux CoreOS en las que se ejecutan los pods de aplicaciones de los usuarios finales. Puede haber varios de ellos en los entornos de OpenShift, y requieren suscripciones a esta plataforma. Los nodos de plano de control y de infraestructura que respaldan los nodos informáticos no necesitan suscripciones, pero pueden conllevar gastos de infraestructura.
• Nodos de plano de control: instancias (hosts de servidores dedicados [bare metal] o máquinas virtuales) de Red Hat Enterprise Linux CoreOS que funcionan como capa de gestión u organización de Kubernetes para Red Hat OpenShift. Las autorizaciones para acceder a los nodos de plano de control están incluidas en las suscripciones a la versión autogestionada de OpenShift, por lo que no es necesario tenerlas en cuenta a la hora de determinar la cantidad de suscripciones que deben adquirirse. Consulte la sección "Nodos de infraestructura y de plano de control de Red Hat OpenShift" para obtener más detalles.
• Nodos de infraestructura: nodos que ejecutan pods que respaldan una infraestructura de clústeres de OpenShift y no instancias de aplicaciones. Por ejemplo, los nodos que ejecutan el equilibrador de carga basado en HAProxy que se utiliza para el tráfico de entrada. Las autorizaciones de acceso a los nodos de infraestructura están incluidas en las suscripciones a la versión autogestionada de OpenShift, por lo que no es necesario tenerlas en cuenta a la hora de determinar la cantidad de suscripciones que deben adquirirse, siempre y cuando no haya instancias de aplicaciones de usuarios en ejecución en ellas.
• Clúster: un clúster de Kubernetes de OpenShift que consiste en un plano de control, nodos de infraestructura opcionales y uno o más nodos informáticos.

Instancia de aplicación: una aplicación puede ser una instancia con un solo pod o puede estar implementada en instancias con varios pods que conforman un servicio de aplicación. Por ejemplo, un servicio de aplicación de alta disponibilidad puede tener dos o más pods. Las instancias de aplicaciones siempre deben ejecutarse en nodos informáticos incluidos en suscripciones a Red Hat OpenShift.

Red Hat OpenShift ofrece una plataforma uniforme de desarrollo y gestión de aplicaciones en un entorno de nube híbrida abierta, y respalda la infraestructura física y virtual en las instalaciones, y las implementaciones en la nube privada, la nube pública y el extremo de la red. Red Hat OpenShift se puede utilizar de dos maneras: con una versión autogestionada o con los servicios de nube totalmente gestionados.  En esta guía, nos ocuparemos de la versión autogestionada de OpenShift.

Con la versión autogestionada de OpenShift, puede instalar, operar y gestionar los entornos de Red Hat OpenShift con máxima capacidad de control, flexibilidad y personalización, lo cual le permite manejar su propio entorno desde la infraestructura. La plataforma autogestionada puede utilizarse en las instalaciones (mediante la nube privada, los entornos virtualizados y los servidores físicos) y en determinadas nubes públicas. Usted controla las actualizaciones, gestiona la infraestructura inferior y mantiene los acuerdos de nivel de servicio (SLA).

Red Hat y nuestros partners de nube pública operan y gestionan completamente los servicios de nube gestionados de OpenShift en las principales nubes públicas. Un equipo exclusivo de ingenieros de confiabilidad del sitio (SRE) gestiona y mantiene la infraestructura y los servicios principales de la plataforma, lo cual permite que sus equipos de DevSecOps se centren en desarrollar e implementar las nuevas aplicaciones y en modernizar las que ya existen.

Ofertas de servicios de nube de OpenShift y más información sobre ellas:

• Red Hat OpenShift Dedicated: servicio totalmente gestionado de Red Hat OpenShift en Amazon Web Services (AWS) y Google Cloud.
• Microsoft Azure Red Hat OpenShift: servicio de Red Hat OpenShift en Microsoft Azure gestionado totalmente de forma conjunta por Microsoft y Red Hat.
• Red Hat OpenShift Service on AWS: servicio de Red Hat OpenShift en Amazon Web Services totalmente gestionado de forma conjunta por AWS y Red Hat.
• Red Hat OpenShift on IBM Cloud: servicio de Red Hat OpenShift en IBM Cloud totalmente gestionado de forma conjunta por IBM y Red Hat.

Todas las versiones de Red Hat OpenShift ofrecen a los desarrolladores y los equipos de operaciones una experiencia del usuario uniforme en los diferentes entornos, lo cual le permite trasladar sus habilidades y aplicaciones a los entornos de nube en los que funcionan mejor.

La versión autogestionada de OpenShift (Red Hat OpenShift Platform Plus, Red Hat OpenShift Container Platform, Red Hat OpenShift Kubernetes Engine y Red Hat OpenShift Virtualization Engine) pueden utilizarse en cualquier sistema en el que Red Hat Enterprise Linux de 64 bits cuente con certificación y compatibilidad. Consulte la documentación para obtener más información sobre los métodos para implementar OpenShift y los tipos de infraestructura compatibles.

Versiones de sistemas de software autogestionados de OpenShift:

• Red Hat OpenShift Kubernetes Engine: motor de tiempo de ejecución de Kubernetes empresarial para la nube híbrida que ofrece las funciones principales de Red Hat OpenShift para implementar y ejecutar las aplicaciones. Puede instalarlo y gestionarlo en el centro de datos, la nube pública o el extremo de la red.
• Red Hat OpenShift Container Platform: plataforma de Kubernetes empresarial completa para la nube híbrida que permite diseñar, implementar y ejecutar aplicaciones. Puede instalarla y gestionarla en el centro de datos, la nube pública o el extremo de la red.
• Red Hat OpenShift Platform Plus:  plataforma para la nube híbrida que permite que las empresas diseñen, implementen, ejecuten y gestionen aplicaciones inteligentes según sea necesario en varios clústeres y entornos de nube. Las diversas capas de seguridad, capacidad de gestión y automatización proporcionan uniformidad en toda la cadena de suministro de software. Las suscripciones a OpenShift Platform Plus solo están disponibles para los clústeres basados en x86.
• Red Hat OpenShift Virtualization Engine: oferta de infraestructura de virtualización que se encuentra disponible únicamente para servidores dedicados (bare metal) y se basa en Red Hat OpenShift y el hipervisor open source de máquinas virtuales basadas en el kernel (KVM). Se diseñó con el objetivo de ofrecer a las empresas una solución empresarial confiable para implementar, gestionar y ajustar las máquinas virtuales. Este subconjunto de OpenShift está destinado únicamente a las cargas de trabajo de las máquinas virtuales y es compatible con los servicios de infraestructura en contenedores, es decir, no admite contenedores de aplicaciones orientadas al usuario final.

Tipos de suscripciones

Hay dos tipos de suscripciones para la versión autogestionada de OpenShift (par de núcleos y par de sockets de servidor dedicado [bare metal]), y hay dos niveles de soporte disponibles para cada una de ellas.

Los nodos informáticos de su entorno requieren suscripciones de nodos informáticos, las cuales pueden otorgarse con pares de núcleos o con pares de sockets de servidor dedicado (bare metal)

1. Par de núcleos (2 núcleos o 4 vCPU)
   • Esta opción está disponible para OpenShift Kubernetes Engine, OpenShift Container Platform y OpenShift Platform Plus. Las suscripción de par de núcleos no se aplica a OpenShift Virtualization Engine.
   • A la hora de autorizar núcleos de la CPU, cuente la cantidad total de núcleos físicos o vCPU en todos los nodos informáticos que se ejecutan en los clústeres de la plataforma que desea autorizar con las suscripciones de par de núcleos.
   • Se encuentra disponible con un SLA de soporte Standard 8x5 o Premium 24x7.
2. Par de sockets de servidor dedicado (bare metal) (1 o 2 sockets y un máximo de 128 núcleos en total)
   • Esta opción está disponible para todas las versiones autogestionadas de OpenShift y es la única alternativa para OpenShift Virtualization Engine.
   • La suscripción está disponible solo para nodos físicos de servidores dedicados (bare metal) x86 y ARM en los que OpenShift está instalado directamente en el hardware. No se admiten hipervisores de terceros.
   • Esta no es una suscripción de centro de datos virtual, como lo es Red Hat Enterprise Linux for Virtual Datacenters, en la cual, con una sola suscripción, se obtienen instalaciones ilimitadas de sistemas operativos de máquinas virtuales guest en cualquier host hipervisor.
   • Se encuentra disponible con un SLA de soporte Standard 8x5 o Premium 24x7.
   • Se puede agrupar para usar en servidores dedicados (bare metal) con más de 2 sockets o más de 128 núcleos, pero una sola suscripción no puede abarcar varios servidores de este tipo.

Además, necesita suscripciones a Red Hat AI Accelerator para los aceleradores de su entorno:

1. AI Accelerator (1 acelerador)
   • Esta suscripción es necesaria para las tarjetas de aceleradores (GPU, TPU, NPU, FPGA, DPU, etc.) que ofrecen aceleración informática en las cargas de trabajo de inteligencia artificial que son complementos separados y no forman parte del paquete de la CPU.
   • Se utiliza la misma suscripción para cada acelerador físico, independientemente de la versión de Red Hat OpenShift.
   • Si tanto Red Hat OpenShift como OpenShift AI están instaladas en el clúster, se puede usar una sola suscripción de este tipo.
   • La suscripción no es necesaria a menos que el acelerador se utilice para la informática. Por ejemplo, las DPU que se utilizan como SmartNIC para acelerar la red, incluso si tienen núcleos ARM disponibles que no usan, o las GPU que se emplean para procesar gráficos y no para agilizar la inteligencia artificial.
   • Se encuentra disponible con un SLA de soporte Standard 8x5 o Premium 24x7. El SLA debe coincidir con el de la suscripción de par de núcleos o par de sockets de servidor dedicado (bare metal).

Elección de suscripciones de par de núcleos

Conviene elegir suscripciones de par de núcleos cuando implementa la versión autogestionada de OpenShift en los proveedores principales de nube pública, en una nube privada de infraestructura como servicio (IaaS) o en un hipervisor como VMware vSphere, Red Hat OpenStack® Platform o Nutanix.

Con este tipo de suscripciones, no es necesario vincular suscripciones a los servidores físicos y los pods pueden implementarse en la nube híbrida en el momento y la ubicación que necesite.

También puede usar suscripciones de par de núcleos en dispositivos o servidores dedicados (bare metal), es decir, sin hipervisor. Tenga en cuenta que es posible que, para cierta densidad de pods informáticos, sean más rentables las suscripciones de par de sockets de servidores dedicados (bare metal).

Cuando usa OpenShift Virtualization Engine como plataforma de virtualización exclusiva, puede elegir habilitar los contenedores de OpenShift en máquinas virtuales usando suscripciones de par de núcleos, junto con las de par de sockets de servidor dedicado (bare metal) del hipervisor. Debe adquirir por separado las suscripciones de par de núcleos de la versión autogestionada de OpenShift y asignarlas a las máquinas virtuales del entorno, como lo haría con cualquier otra aplicación que compre y ejecute como máquina virtual. En este caso, es posible que, debido a la gran cantidad de núcleos, la opción más rentable sea adoptar el modelo de par de sockets de servidores dedicados (bare metal) para la versión autogestionada de OpenShift, lo que incluye contenedores ilimitados de la plataforma en estos servidores y la posibilidad de ejecutarlos en máquinas virtuales de OpenShift.

Las suscripciones de par de núcleos se pueden distribuir para abarcar todos los nodos informáticos de OpenShift en los clústeres de la plataforma. Por ejemplo, 100 suscripciones a Red Hat OpenShift Platform Plus de par de núcleos proporcionarán 200 núcleos (400 vCPU) que se pueden utilizar en cualquier cantidad de nodos informáticos y en todos los clústeres de OpenShift en ejecución en sus entornos de nube híbrida.

Elecciones de suscripciones de par de sockets de servidor dedicado (bare metal)

Las suscripciones de par de sockets de servidor dedicado (bare metal) solo pueden usarse para los nodos informáticos de OpenShift que se implementan en servidores físicos exclusivos, ya sea en el centro de datos, en una nube privada alojada de una oferta de servidor dedicado (bare metal) compatible o con uno de los proveedores principales en este tipo de oferta. Estas suscripciones son la única opción disponible para OpenShift Virtualization Engine, y se requieren para admitir la función OpenShift Virtualization en las otras versiones autogestionadas de OpenShift.

Cada suscripción de par de sockets de servidor dedicado (bare metal) admite hasta 128 núcleos físicos en el par de sockets. Se pueden combinar para abarcar pares de sockets con más de 128 núcleos en total y servidores físicos con más de 1 par de sockets.

Si quiere habilitar un servidor físico, agrupe una o varias suscripciones para cubrir la totalidad de sockets o de núcleos físicos que posee (lo que sea mayor). Por ejemplo, si un servidor tiene 2 sockets con 48 núcleos en cada CPU, lo que da un total de 96 núcleos, se necesita una sola suscripción, porque el servidor no tiene más de 2 sockets ni de 128 núcleos. Para un segundo servidor con 2 sockets y un total de 192 núcleos, necesitaría dos suscripciones, ya que una sola suscripción abarca como máximo 128 núcleos. Una única suscripción de par de sockets de servidor dedicado (bare metal) no puede dividirse y asignarse a varios hosts físicos para cubrir dos servidores con un solo socket cada uno ni núcleos en diferentes servidores.

Cada servidor dedicado (bare metal) físico que usa autorizaciones basadas en sockets solo se puede utilizar como nodo único de OpenShift debido a la naturaleza de la arquitectura de Kubernetes. Como cada nodo en Kubernetes puede pertenecer a un solo clúster, todos los contenedores en un servidor dedicado (bare metal) están en el mismo clúster. Esto es ideal para las cargas de trabajo que usan muchos recursos, como OpenShift Virtualization (en donde cada una de ellas ejecuta una máquina virtual completa), pero es posible que no sea adecuada para otras. Si bien OpenShift admite hasta 2500 contenedores en un único nodo, es posible que le convenga dividirlos y asignarlos a diferentes nodos o clústeres en determinadas situaciones por motivos relacionados con el rendimiento o la arquitectura. Para hacerlo, debe aplicar la virtualización en la creación de nodos informáticos independientes en el servidor dedicado (bare metal).

Un modelo típico a la hora de implementar contenedores consiste en diseñar la arquitectura usando muchos clústeres en los que se incluyan pocos contenedores. Este es uno de los modelos habituales en los entornos de los proveedores principales, y puede lograrse en el centro de datos si se usa un hipervisor para crear máquinas virtuales que se conviertan en los nodos informáticos en los que se implementan los contenedores. En el caso de proveedores como VMWare vSphere, Red Hat OpenStack Platform y Nutanix, debe usar suscripciones de par de núcleos para las versiones de OpenShift implementadas en las máquinas virtuales.

Los clústeres de OpenShift Kubernetes Engine, OpenShift Container Platform y OpenShift Platform Plus, que se implementan en servidores dedicados (bare metal) y suscripciones de par de sockets autorizadas, incluyen OpenShift Virtualization y suscripciones para los clústeres de OpenShift virtuales del mismo tipo de producto que se implementen en ellos. Esto significa, por ejemplo, que los clústeres de OpenShift virtuales que se implementen en uno de servidor dedicado (bare metal) de OpenShift Container Platform heredan las suscripciones a esta plataforma del clúster que las aloja.

Cabe destacar que la suscripción a OpenShift Virtualization Engine no incluye soporte para las instancias de aplicaciones en contenedores, a excepción de las cargas de trabajo de infraestructura descritas en la sección de OpenShift Virtualization Engine que aparece más abajo. Si desea ejecutar sus propias cargas de trabajo de aplicaciones en contenedores con OpenShift Virtualization Engine, debe autorizar la máquina virtual con suscripciones de par de núcleos para la versión autogestionada de OpenShift. Cuando la densidad es más alta, puede optar por adquirir una suscripción de par de sockets de servidor dedicado (bare metal) a las versiones autogestionadas de OpenShift Kubernetes Engine, OpenShift Container Platform u OpenShift Platform Plus para ejecutar aplicaciones basadas en contenedores directamente en el clúster de servidor dedicado (bare metal), como se describe en el párrafo anterior.

No se pueden usar diferentes tipos de productos de OpenShift en el mismo clúster; todos los nodos deben suscribirse con el mismo tipo de producto OpenShift Virtualization Engine, OpenShift Kubernetes Engine, OpenShift Container Platform u OpenShift Platform Plus. Sin embargo, las suscripciones de par de núcleos o de par de sockets pueden utilizarse en un único clúster. Por ejemplo, no puede tener un solo clúster de servidor dedicado (bare metal) con varios nodos de OpenShift Virtualization Engine para alojar máquinas virtuales y otros nodos suscritos con OpenShift Platform Plus para alojar aplicaciones en contenedores e instancias virtuales de OpenShift.

Contabilización de las suscripciones de AI Accelerator

Durante los últimos años, aparecieron en el mercado tecnologías de hardware específicas que agilizan el rendimiento de ciertas cargas de trabajo informáticas. A estos dispositivos se los denomina aceleradores de inteligencia artificial o, simplemente, aceleradores en el contenido de Red Hat. Hay varios tipos de dispositivos de hardware disponibles para los servidores modernos que se pueden clasificar como aceleradores, incluidos, entre otros, los ASIC, las GPU, las TPU, las NPU y las FPGA.

Por lo general, estos aceleradores son una tarjeta, una placa u otro dispositivo físico que ocupa una ranura de interconexión de elementos periféricos (PCI) en un servidor. En la mayoría de los casos, equivale a la cantidad de unidades que adquirió del proveedor del acelerador. Por ejemplo, si el proveedor afirma que el servidor tiene 8 GPU, esto suele significar que cuenta con 8 aceleradores físicos.

Cada suscripción a AI Accelerator abarca un dispositivo acelerador físico. Por ejemplo, si nos centramos solo en las suscripciones a AI Accelerator:

• Un nodo informático físico con 4 dispositivos GPU físicos requiere 4 suscripciones a AI Accelerator además de las suscripciones de par de núcleos o de par de sockets que cubren el nodo informático.
• Un único nodo informático virtual con un dispositivo GPU físico que se presenta a las máquinas virtuales como varias GPU requiere una suscripción a AI Accelerator, ya que se cuenta en función de los aceleradores físicos, no virtuales.

Solo se cuentan los aceleradores cuando se usan para ejecutar una carga de trabajo informática. Se considera que una carga es informática cuando su objetivo principal no es dibujar píxeles en la pantalla de los usuarios en tiempo real de manera activa y casi de inmediato ni trasladar datos en una red.

Esta distinción es importante porque las aplicaciones de transmisión de video y de efectos visuales pueden usar GPU y otros hardware aceleradores, pero, en esos casos, el objetivo fundamental es dibujar píxeles en una pantalla. En otras ocasiones, el fin principal es trasladar datos en una red, como sucede con las unidades de procesamiento de datos destinadas a las funciones de red, lo cual tampoco se considera una carga de trabajo informática.

Estos son algunos ejemplos de cargas de trabajo informáticas:

• las aplicaciones de software tradicionales, como Java, Python y Perl;
• los LLM u otro software que requieren un gran consumo de recursos informáticos;
• el perfeccionamiento y el entrenamiento de modelos de análisis de datos;
• la creación de modelos con fines científicos y las simulaciones físicas, como el plegamiento de proteínas y la dinámica de fluidos.

Nodos de infraestructura y de plano de control de Red Hat OpenShift

Cada suscripción a la versión autogestionada de OpenShift incluye autorizaciones de acceso para Red Hat OpenShift y otros elementos relacionados con esta plataforma. OpenShift Kubernetes Engine, OpenShift Container Platform y OpenShift Platform Plus incluyen autorizaciones de Red Hat Enterprise Linux para los nodos informáticos y de infraestructura. Red Hat OpenShift Virtualization Engine no admite los nodos de trabajo ni de infraestructura estándares de Red Hat Enterprise Linux, solo el sistema operativo Red Hat Enterprise Linux CoreOS que está incluido en la autorización de OpenShift.

Estas autorizaciones están contempladas para ejecutar la infraestructura y el plano de control de OpenShift requeridos, pero no debe contarlas a la hora de determinar la cantidad de suscripciones a Red Hat necesarias.

Las suscripciones a Red Hat OpenShift Platform Plus también incluyen la gestión de todos los nodos por parte de Red Hat Advanced Cluster Security for Kubernetes y Red Hat Advanced Cluster Management for Kubernetes.

Un instalador predeterminado implementa un plano de control altamente disponible de OpenShift, el cual está compuesto por 3 nodos de plano de control, además de por lo menos 2 nodos informáticos de esta plataforma para ejecutar las aplicaciones de los usuarios finales. De forma predeterminada, los elementos del plano de control de Kubernetes (p. ej., el servidor de la interfaz de programación de aplicaciones [API], el etcd y el programador) y los servicios de clústeres de respaldo (p. ej., la supervisión y el registro) se implementarán en los nodos del plano de control de OpenShift. Sin embargo, puede optar por trasladar algunos de estos servicios a los nodos de infraestructura exclusivos.

Para que se consideren nodos de infraestructura y puedan utilizar las autorizaciones de acceso incluidas, solo los elementos que respalden al clúster y que no formen parte de ninguna aplicación del usuario final pueden ejecutarse en esas instancias. Estos son algunos ejemplos:

• el registro de OpenShift;
• el enrutador de entrada de OpenShift (entrada local y global o de varios clústeres);
• OpenShift Observability;
• las instancias basadas en HAProxy que se utilizan para la entrada del clúster;
• 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;
• Planos de control alojados para Red Hat OpenShift.

Puede implementar y ejecutar en los nodos de infraestructura agentes y herramientas externos y personalizados para la supervisión, la recopilación y el envío de datos de registro, los controladores de hardware y la integración de la infraestructura (como los agentes de virtualización), sin que esto inhabilite el nodo para utilizar las licencias de la infraestructura. Sin embargo, esto se limita únicamente a los agentes y los elementos relacionados, lo cual incluye los pods del controlador para los operadores, pero no el conjunto de sistemas de software personalizados o de terceros. Estos son algunos ejemplos de software que no proviene de Red Hat, pero que puede considerarse como carga de trabajo de infraestructura:

• los agentes de supervisión de terceros y personalizados;
• los controladores (complementos) de la interfaz de red de contenedores (CNI) y de la interfaz de almacenamiento de contenedores (CSI);
• los aceleradores de habilitación de la virtualización o del hardware;
• los pods del controlador que se utilizan para las definiciones de recursos personalizados (CRD) o los operadores de Kubernetes (sistemas de software personalizados o de terceros).

No se pueden ejecutar otras instancias ni tipos de aplicaciones de usuario final en un nodo de infraestructura mediante las autorizaciones de acceso incluidas. Si desea ejecutar otras cargas de trabajo de infraestructura como instancias de aplicaciones en Red Hat OpenShift, debe hacerlo en nodos de aplicaciones regulares con suscripciones a Red Hat OpenShift válidas. Puede comprobar con Red Hat si una aplicación o servicio se considera una carga de trabajo de infraestructura. 

Autorizaciones de Red Hat Enterprise Linux

Las autorizaciones de Red Hat Enterprise Linux para los nodos informáticos y de infraestructura de OpenShift se incluyen con OpenShift Kubernetes Engine, OpenShift Container Platform y OpenShift Platform Plus. Esto también comprende los pods autorizados para las aplicaciones y las autorizaciones de sistemas operativos guest para las máquinas virtuales. Sin embargo, las suscripciones a Red Hat OpenShift no incluyen otras autorizaciones para nodos de Red Hat Enterprise Linux, salvo en el siguiente caso:

• un nodo de Red Hat Enterprise Linux que se usa exclusivamente para la implementación de una infraestructura preparada por el instalador (IPI) en un servidor dedicado (bare metal).

OpenShift Virtualization Engine no incluye Red Hat Enterprise Linux para los nodos informáticos ni de infraestructura ni para autorizaciones de sistemas operativos guest de máquinas virtuales. Para los guests de Red Hat Enterprise Linux en OpenShift Virtualization Engine, se requiere una suscripción a Red Hat Enterprise Linux for Virtual Datacenters o una que corresponda a cada máquina virtual.

No se incluyen autorizaciones de acceso de Red Hat Enterprise Linux para los nodos externos que alojan servicios de los cuales depende OpenShift, como los proxies de Internet, los equilibradores de carga o el registro espejo de la plataforma. La autorización no incluye Red Hat Satellite.

Registro de contenedores de arranque para replicar imágenes de contenedores de OpenShift

El registro espejo de OpenShift, que está incluido en la suscripción a Red Hat OpenShift, es una oferta con autorización de acceso de Quay cuyo único objetivo es facilitar el proceso de replicación del contenido necesario para el arranque de los clústeres desconectados de OpenShift. Se trata de una autorización con soporte limitado para una implementación mínima de Quay que creó un instalador específico, la cual le permite ejecutar un registro de Quay en un host de Red Hat Enterprise Linux con preparación previa y gestión por parte del cliente.

Nota: Puede usar Quay como registro espejo solamente para replicar el contenido requerido de la versión de OpenShift, el contenido de OperatorHub, las imágenes de muestra de operadores, la imagen de gráficos de Cincinnati y las imágenes relacionadas con las ofertas de Red Hat OpenStack Platform, incluidas Red Hat OpenStack Services on OpenShift y Red Hat OpenShift Data Foundation.

El registro espejo de OpenShift no está diseñado para el uso general ni el funcionamiento arbitrario. No obstante, se puede almacenar allí un conjunto limitado de imágenes personalizadas, que incluye el software complementario y necesario, como agentes e imágenes de contenedores para las cargas de trabajo de infraestructura calificadas. Estos son algunos ejemplos:

• los agentes de supervisión;
• los proveedores de la CNI y la CSI;
• los agentes de habilitación de la virtualización o del hardware;
• los operadores que admiten los servicios de proveedores de software independientes (VIS);
• los operadores personalizados como los controladores de la implementación.

Planos de control alojados

La infraestructura de OpenShift clásica requiere como mínimo 3 nodos de plano de control para cada clúster de OpenShift. También se pueden usar planos de control alojados, que se ejecutan en un clúster de plano de control central y actúan como plano de control lógico de los clústeres de OpenShift. Como en todos los casos, los nodos de infraestructura y de plano de control no cuentan para las suscripciones, pero deben considerarse para la arquitectura.

Los planos de control alojados pueden ejecutarse en cualquier clúster de servidor dedicado (bare metal) de OpenShift, pero los nodos informáticos de estos clústeres necesitan autorizaciones que correspondan a la infraestructura en la que se ejecutan. Por ejemplo, los clústeres virtuales que se ejecutan en OpenShift Virtualization Engine necesitan suscripciones de par de núcleos para los nodos informáticos, mientras que un clúster cuyo plano de control se encuentra alojado en un clúster de OpenShift Virtualization Engine y que utiliza nodos informáticos de servidor dedicado (bare metal) necesita suscripciones de par de sockets.

Excepción 1: Ejecución de instancias de aplicaciones en nodos de infraestructura o de plano de control

Los nodos de plano de control de OpenShift no se usan como nodos informáticos de forma predeterminada y, por lo tanto, no ejecutan instancias de aplicaciones. Para determinar si necesitará una suscripción completa a Red Hat OpenShift para estos nodos, es fundamental saber si ejecuta únicamente elementos de respaldo del clúster de la plataforma o aplicaciones de usuarios finales. Si elige usar un nodo de plano de control para alojar aplicaciones de usuarios finales, necesitará suscripciones para todos los núcleos. Consulte la sección sobre los nodos de infraestructura para identificar las cargas de trabajo calificadas que no requieren ninguna suscripción.

Excepción 2: Implementaciones de clústeres compactos

En las implementaciones de clústeres compactos como OpenShift de tres nodos, las cargas de trabajo de las aplicaciones del usuario final se ejecutan en los nodos de plano de control. Para las suscripciones a Red Hat OpenShift, debe contar los núcleos en los tres nodos, independientemente de su función.

Una instancia de un solo nodo de OpenShift implementa todos los servicios de OpenShift y las aplicaciones de usuario final en un único nodo físico o virtual, con optimizaciones que permiten reducir el espacio y aumentar la cantidad de recursos disponibles para las aplicaciones. Al igual que con los clústeres compactos de tres nodos mencionados anteriormente, no es necesario realizar adaptaciones especiales para este modelo de implementación, sino que todos los núcleos del nodo deben contar con la autorización de acceso correspondiente.

Recuperación ante desastres

Red Hat define tres tipos de entornos de recuperación ante desastres: caliente, templado y frío. Las suscripciones de pago a Red Hat OpenShift solo son necesarias para la recuperación ante desastres caliente.

• Los entornos calientes se caracterizan por funcionar correctamente en todos sus aspectos y por ejecutarse de forma simultánea con los sistemas de producción. Están preparados para recibir tráfico de inmediato y encargarse de la situación en caso de que haya problemas en el entorno principal. Cuando los volúmenes de datos se replican activamente en los distintos clústeres, ya sea de manera sincrónica o asincrónica, se considera que son sistemas calientes de recuperación ante desastres.
• Los sistemas de recuperación ante desastres templados están preparados para implementar y alojar cargas de trabajo en contenedores similares a las del sitio principal, pero no contienen cargas de trabajo de clientes de los clústeres de origen. No deben usarse en la replicación de volúmenes de datos en distintos clústeres, ya sea de manera sincrónica o asincrónica. La recuperación templada requiere que se restauren los datos de los clientes en el hardware del clúster que ya poseen desde el exterior del clúster.
• Los entornos fríos se caracterizan por contar con la infraestructura, pero no con la tecnología (el hardware, el software y los datos) necesaria para restaurar el servicio.

Se requiere suscripción para los clústeres en hibernación que no estén específicamente configurados ni diseñados en función de los entornos calientes o templados, como los clústeres que se ejecutan en servicios de nube y que se encuentran en dicho estado debido a una disminución en la demanda. También es necesario disponer de suscripciones cuando se retiran los clústeres del estado de hibernación para ejecutar cargas de trabajo. Sin embargo, si se retira temporalmente un clúster para pruebas o tareas de mantenimiento de rutina, no se necesitan suscripciones adicionales para ninguno de los elementos de las ofertas de software de OpenShift.

Tanto en los sistemas fríos como templados, se pueden transferir las suscripciones a Red Hat OpenShift del entorno principal al de recuperación ante desastres cuando ocurre un problema, para restaurar el servicio y cumplir con los términos de la suscripción a Red Hat.

Migración y actualizaciones transitorias

Red Hat OpenShift 4 ofrece actualizaciones integradas entre las versiones secundarias. No obstante, si actualiza el sistema desde Red Hat OpenShift 3 o debe realizar una actualización transitoria entre versiones secundarias de Red Hat OpenShift 4 debido a los períodos de mantenimiento u otros motivos, la suscripción a Red Hat OpenShift cubrirá tanto la infraestructura de origen como la de destino de la migración unidireccional hasta que esta se complete. Durante el proceso, las herramientas de gestión de la suscripción a Red Hat indicarán que el entorno no cumple con los requisitos en función de la cantidad de suscripciones a Red Hat OpenShift que se hayan adquirido. Red Hat ofrece esta posibilidad para las actualizaciones de las versiones principales, por lo que no será necesario adquirir otras suscripciones para volver a cumplir con los requisitos durante la migración. Por último, Red Hat OpenShift no solo ofrece herramientas de soporte para llevar a cabo estas migraciones, sino también los servicios de Red Hat Consulting en caso de que los solicite. Consulte la documentación sobre el kit de herramientas de migración para contenedores.

Autorizaciones para núcleos con hyperthreading

Para determinar si un nodo de OpenShift en particular usa un nodo físico o más, se debe identificar si el sistema tiene habilitada la ejecución de varios subprocesos por núcleo. Aprenda a definir si un sistema determinado admite hyperthreading.

Los nodos virtualizados de OpenShift que usan subprocesos de CPU lógicos, también conocidos como multithreading simultáneo para las CPU AMD EPYC o hyperthreading para las CPU Intel, calculan el uso de núcleos para las suscripciones a Red Hat OpenShift en función de la cantidad de núcleos o CPU que se asignan al nodo. Sin embargo, cada suscripción cubre 4 vCPU o núcleos cuando se usan los subprocesos de CPU lógicos. Las herramientas de gestión de las suscripciones a Red Hat asumen que los subprocesos de CPU lógicos se encuentran habilitados de manera predeterminada en todos los sistemas.

Las suscripciones de servidor dedicado (bare metal) solo cuentan los núcleos físicos; los subprocesos de CPU lógicos no se consideran al calcular la cantidad de suscripciones que se necesitan para este tipo de servidores.

Arquitecturas alternativas (ARM, IBM Z, IBM LinuxONE, IBM Power)

Nota: Si bien en este documento solo se hace referencia a IBM Z en adelante, toda la información referida a esta arquitectura también se aplica a IMB LinuxONE.

Red Hat OpenShift Container Platform también se puede ejecutar en ARM, IBM Z e IBM Power para los clientes que utilizan estas plataformas como estándar con el fin de diseñar e implementar microservicios y aplicaciones en la nube. Únicamente el modelo de suscripción basado en núcleos es compatible con las plataformas IBM Z e IBM Power.

Los clústeres de ARM se autorizan siguiendo las mismas reglas que x86.

En el caso de los clientes de IBM Z, Red Hat OpenShift no requiere que todo el nodo físico esté habilitado, sino solo los núcleos que utiliza la plataforma, lo que se conoce como “subcapacidad”. Los clientes que utilicen solo un subconjunto de núcleos disponibles (capacidad informática) en el entorno de IBM Z para OpenShift Container Platform, necesitarán suscripciones únicamente para el subconjunto que se utilice con los nodos informáticos. Esto se aplica indistintamente del método que se utilice para realizar particiones en la CPU: el pooling, el capping o las particiones lógicas (LPAR) separadas.

Para IBM Z, un procesador Integrated Facility for Linux (IFL) requiere una suscripción de par de núcleos a OpenShift. Cuando no se crean particiones, se pueden identificar hasta 3 IFL por clúster de OpenShift en los servicios de infraestructura o de plano de control que se ejecutan en el host. Para calificar, los IFL deben usarse activamente en estos servicios, y no requieren autorizaciones de OpenShift. En cambio, las implementaciones de clústeres compactos de tres nodos exigen que todos los IFL estén autorizados.

Por el momento, los elementos de Red Hat OpenShift Platform Plus más allá de OpenShift Container Platform no son compatibles con los sistemas IBM Z ni IBM Power, con las siguientes excepciones:

• Una suscripción independiente de Red Hat Quay que se ejecuta en arquitecturas x86 brinda un registro global para varias arquitecturas, lo cual incluye los clústeres de IBM Z e IBM Power. Red Hat Quay no se ejecutará por su propia cuenta en IBM Z o IBM Power.
• Red Hat Advanced Cluster Management for Kubernetes se puede instalar en entornos IBM Z o IBM Power para gestionar los nodos de Red Hat OpenShift que se ejecutan allí.
• Con Red Hat Advanced Cluster Security for Kubernetes, puede usar el operador de Red Hat Advanced Cluster Security para proteger los clústeres que se ejecutan en Red Hat OpenShift en IMB Z o IBM Power.
• Red Hat OpenShift Data Foundation admite su instalación en IBM Z e IBM Power.

Los elementos de la suscripción a Red Hat OpenShift Platform Plus tienen distintos niveles de compatibilidad con las arquitecturas alternativas (que no son x86). Consulte el artículo Red Hat OpenShift Container Platform 4.16 Multi Architecture Component Availability Matrix. Para obtener más información sobre la interoperabilidad entre los elementos de OpenShift Platform Plus y las arquitecturas que no son x86, consulte las matrices de compatibilidad de Red Hat OpenShift Container Platform, Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security, Red Hat Quay y  Red Hat OpenShift Data Foundation.

Red Hat OpenShift Kubernetes Engine y Red Hat OpenShift Virtualization Engine no son compatibles con IBM Z ni IBM Power.

Compatibilidad con los contenedores de Microsoft Windows Server

La versión autogestionada de OpenShift admite un subconjunto de infraestructuras de instalación y funciones de OpenShift usando contenedores de Microsoft Windows Server. Estos contenedores solo son compatibles con los nodos informáticos basados en Microsoft Windows Server. Los planos de control y de infraestructura del entorno de OpenShift deben ejecutarse en una arquitectura x86 con Red Hat Enterprise Linux o Red Hat Enterprise Linux CoreOS. Por este motivo, la compatibilidad con los contenedores de Windows Server se adquiere como una suscripción independiente que se cobra por núcleo.

Se puede usar la infraestructura de Red Hat OpenShift Container Platform y Red Hat OpenShift Platform Plus para implementar y gestionar los nodos informáticos de Windows Server. La compatibilidad con los contenedores de Microsoft Windows Server de las suscripciones a Red Hat OpenShift debe adquirirse como un complemento independiente.

Si bien no es posible utilizar Red Hat Advanced Cluster Management ni Red Hat Advanced Cluster Security para gestionar los nodos de Microsoft Windows, sí se puede utilizar Red Hat Quay, que se ejecuta en arquitecturas x86, para gestionar las imágenes de contenedores de las cargas de trabajo basadas en Microsoft Windows Server.

Cada caso es único: todas estas pautas son orientativas y no constituyen ninguna garantía

Red Hat OpenShift admite varias funciones que afectan la capacidad de ajuste, la programación de los pods, la inactividad y las cuotas o las limitaciones de los recursos. Los cálculos anteriores son orientativos, por lo que quizás pueda ajustar su entorno para reducir su tamaño total u optimizar el uso de los recursos. Los clientes de OpenShift Platform Plus también deben tener en cuenta las necesidades de las aplicaciones de software adicionales (Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security y Quay), incluidos los recursos informáticos y de almacenamiento, aunque posiblemente no requieran más suscripciones informáticas.

Si trabaja con un distribuidor externo, consulte sus términos y acuerdos específicos para los productos y servicios de Red Hat. 

Red Hat OpenShift Platform Plus incluye sistemas adicionales de software, además de OpenShift Container Platform, para que gestione y proteja su entorno de OpenShift en múltiples clústeres y nubes según sea necesario. Red Hat OpenShift Platform Plus se encuentra disponible en los modelos de suscripción de par de sockets de servidor dedicado [bare metal] y de par de núcleos, con las limitaciones que se mencionaron anteriormente.

Por lo general, el software adicional incluido en Red Hat OpenShift Platform Plus se limita a la gestión de los nodos habilitados con las suscripciones de esta oferta. Por ejemplo, la suscripción para Red Hat Advanced Cluster Management que se incluye con OpenShift Platform Plus solo puede utilizarse para gestionar los nodos y clústeres habilitados para dicha plataforma. Los clientes que deseen, además, gestionar otros nodos y clústeres, como los de Red Hat OpenShift Service on AWS, tendrán que adquirir suscripciones complementarias de Red Hat Advanced Cluster Management.

Estas suscripciones de software adicionales y las de OpenShift Platform Plus no se pueden separar. A modo de ejemplo: no puede adquirir 100 suscripciones a OpenShift Platform Plus, instalar 200 núcleos de suscripciones a Red Hat OpenShift Container Platform y utilizar por separado Red Hat Advanced Cluster Management para gestionar 200 núcleos de Azure Red Hat OpenShift con la misma suscripción. El software adicional solo se puede utilizar para gestionar los mismos 200 núcleos en los que está instalado el software principal de OpenShift Platform Plus.

Reglas específicas para cada producto en capas:

• Red Hat Advanced Cluster Management for Kubernetes: la suscripción a OpenShift Platform Plus le permite instalar todas las instancias centrales de Red Hat Advanced Cluster Management que necesite para gestionar su entorno e incluye la administración de todos los nodos y clústeres habilitados con OpenShift Platform Plus, como los nodos de infraestructura y de plano de control. Si desea gestionar nodos y clústeres sin las autorizaciones de acceso de OpenShift Platform Plus (por ejemplo, si también cuenta con clústeres habilitados para OpenShift Container Platform o Red Hat OpenShift Kubernetes Engine autogestionados, clústeres que se ejecutan en la nube totalmente gestionada de OpenShift o en entornos de Kubernetes de terceros compatibles con Red Hat Advanced Cluster Management), debe adquirir las suscripciones complementarias a Red Hat Advanced Cluster Management para cubrir esos entornos. Se pueden administrar de forma centralizada desde la consola de Red Hat Advanced Cluster Management instalada en OpenShift Platform Plus, o bien, desde una aplicación central independiente, si cumple con los requisitos. Obtenga más información sobre las suscripciones, los entornos compatibles y las prácticas recomendadas de Red Hat Advanced Cluster Management.
• Red Hat Advanced Cluster Security for Kubernetes: la suscripción a OpenShift Platform Plus le permite instalar todas las aplicaciones centrales de Red Hat Advanced Cluster Security que necesite para gestionar su entorno e incluye la administración de todos los nodos y clústeres habilitados con OpenShift Platform Plus, como los nodos de infraestructura y de plano de control. Si desea gestionar nodos y clústeres sin las autorizaciones de acceso de OpenShift Platform Plus (por ejemplo, si también cuenta con clústeres habilitados para OpenShift Container Platform u OpenShift Kubernetes Engine autogestionados, clústeres que se ejecutan en la nube totalmente gestionada de Red Hat OpenShift o en entornos de Kubernetes de terceros compatibles con Red Hat Advanced Cluster Security), debe adquirir las suscripciones complementarias a Red Hat Advanced Cluster Security para cubrir esos entornos. Red Hat recomienda gestionar cada entorno con una aplicación central de Red Hat Advanced Cluster Security independiente. Obtenga más información sobre los entornos compatibles con Red Hat Advanced Cluster Security.
• Red Hat Quay: la suscripción a OpenShift Platform Plus le permite instalar Red Hat Quay en cualquier clúster que cuente con las autorizaciones de acceso de OpenShift Platform Plus. Además, podrá instalar una cantidad ilimitada de implementaciones de Quay en los clústeres de dicha oferta. Este registro funciona en cualquier entorno de Kubernetes compatible que elija, lo cual incluye el de OpenShift Platform Plus, otros clústeres autogestionados de OpenShift, servicios gestionados de OpenShift y sistemas Kubernetes compatibles de terceros. Si desea instalar Quay en un entorno que no sea de OpenShift Platform Plus, deberá adquirir otra suscripción a Red Hat Quay, que también está disponible como software como servicio (SaaS) totalmente gestionado.
• Red Hat OpenShift Data Foundation: la suscripción a OpenShift Platform Plus le permite instalar Red Hat OpenShift Data Foundation Essentials en cualquier clúster que cuente con las autorizaciones de acceso de OpenShift Platform Plus. La autorización de acceso de Red Hat Data Foundation se limita a las funciones disponibles en Essentials y a una capacidad de almacenamiento de datos de 256 TB por clúster de OpenShift. Puede ampliar las funciones y la capacidad a través de suscripciones adicionales. Para obtener más información, consulte  OpenShift Data Foundation Subscription Guide (debe iniciar sesión en el portal de clientes) o póngase en contacto con un representante de ventas de Red Hat.

Desde hace tiempo que OpenShift Virtualization es una función incluida con todas las versiones autogestionadas de OpenShift, para que los clientes puedan integrar las cargas de trabajo de las máquinas virtuales a las aplicaciones desarrolladas en la nube y modernizar las máquinas virtuales en microservicios o contenedores.

Con los cambios más recientes en el mercado de la virtualización, aumentó la demanda de otras plataformas para realizar este proceso, en especial de aquellas que ofrecen un plan de modernización. Muchos de estos clientes no necesitan todas las funciones de OpenShift para llevar a cabo las primeras migraciones de las máquinas virtuales y, para tales casos prácticos, preferirían una versión autogestionada de OpenShift que sea más sencilla y menos costosa.

Red Hat OpenShift Virtualization Engine es una versión autogestionada de OpenShift diseñada específicamente para los clientes que buscan una plataforma de virtualización alternativa en la que puedan ejecutar las máquinas virtuales. Cuenta con autorización de las suscripciones de par de sockets de servidor dedicado (bare metal) en servidores físicos e instancias de servidores dedicados (bare metal) compatibles.

OpenShift Virtualization Engine incluye solo las características necesarias para implementar, gestionar y ejecutar máquinas virtuales, como las siguientes:

• Se incluyen máquinas virtuales ilimitadas en los hosts de las suscripciones.
• No se puede utilizar para ejecutar instancias de aplicaciones (como software comercial o aplicaciones de clientes) en contenedores, sino solo en máquinas virtuales.
• No se incluyen suscripciones para ejecutar versiones de Red Hat OpenShift en máquinas virtuales (es necesario adquirir suscripciones de par de núcleos por separado).
• No se incluyen las autorizaciones de guest de Red Hat Enterprise Linux para máquinas virtuales (es necesario adquirir suscripciones para cada máquina virtual o suscripciones de Red Hat Enterprise Linux for Virtual Datecenter por separado).

Ahora, Red Hat tiene dos productos complementarios para OpenShift Virtualization Engine.

• Red Hat Advanced Cluster Management for Virtualization respalda la virtualización, así como las operaciones y la gestión del ciclo de vida de los hipervisores, a un costo menor que la versión completa de Advanced Cluster Management (se requiere una suscripción por suscripción a OpenShift Virtualization Engine).
• Red Hat Ansible® Application Platform for Virtualization ofrece soporte para el nodo de hipervisor que se ejecuta en OpenShift Virtualization Engine destinado a la migración y las operaciones del día 1 (se requiere una suscripción por suscripción a OpenShift Virtualization Engine).

Si ya es cliente de Advanced Cluster Management y Ansible Application Platform, con la compra de las suscripciones complementarias mencionadas, puede usar sus instalaciones de estas aplicaciones centrales para respaldar el resto de su entorno y gestionar los hosts de OpenShift Virtualization Engine.

Si no tiene aplicaciones centrales de Advanced Cluster Management o Ansible Application Platform instaladas, la suscripción a estos complementos también incluye soporte para instalarlas como contenedores de infraestructura en sus hosts de OpenShift Virtualization Engine. Consulte la documentación de Advanced Cluster Management o Ansible Application Platform sobre la instalación de estas aplicaciones y las prácticas recomendadas con respecto a la arquitectura.

Si necesita automatizar las operaciones del día 2 de sus máquinas virtuales, se recomienda Ansible Automation Platform. Además de las suscripciones de nodo de hipervisores mencionadas, los clientes necesitarán una suscripción de nodo para cada instancia de máquina virtual.Para obtener más información, consulte la documentación de Ansible Automation Platform.

Mientras que la autorización para OpenShift Virtualization Engine restringe las instancias de aplicaciones de clientes únicamente a las máquinas virtuales, muchos de los requisitos de la infraestructura, como los controladores de almacenamiento, las aplicaciones de backup, los agentes de envío, Advanced Cluster Management y Ansible Automation Platform, se ejecutan como contenedores de infraestructura en Red Hat OpenShift. Esto significa que la autorización le permite ejecutar esas funciones de infraestructura en contenedores. Además, también incluye soluciones de almacenamiento definido por software que ofrecen almacenamiento para las máquinas virtuales. Los lineamientos para determinar los recursos que se incluyen en los contenedores de infraestructura son los mismos que definen las cargas de trabajo que se admiten en los nodos de infraestructura de otras versiones de Red Hat OpenShift. Consulte la información sobre los nodos de infraestructura en la sección "Elementos que no cuentan para las suscripciones". Compruebe con un representante de Red Hat si una aplicación o servicio se considera como carga de trabajo de infraestructura para OpenShift Virtualization Engine.

Utilice los siguientes ejemplos y preguntas para determinar la cantidad de suscripciones a la versión autogestionada de OpenShift (Red Hat OpenShift Platform Plus, Red Hat OpenShift Container Platform o Red Hat OpenShift Kubernetes Engine) o de suscripciones complementarias que necesita.

En resumen:

• Las aplicaciones se empaquetan en imágenes de contenedores o en máquinas virtuales.
• Los contenedores y las máquinas virtuales se implementan como pods.
• Los pods se ejecutan en nodos informáticos de OpenShift, cuya gestión está a cargo de los nodos de control de la plataforma.

Cálculo de la cantidad de autorizaciones de acceso necesarias

Las suscripciones a Red Hat OpenShift no limitan la cantidad de instancias de las aplicaciones. Puede ejecutar todas las que admitan la infraestructura y el hardware en el entorno de la plataforma. Los sistemas de hardware con mayor capacidad pueden ejecutar varias de ellas en una menor cantidad de hosts, mientras que es posible los que poseen menor capacidad necesiten más hosts para llevar a cabo esta tarea. El factor principal para determinar el tamaño de un entorno de Red Hat OpenShift es la cantidad de pods o instancias de aplicaciones que se ejecutarán en un momento dado.

Paso 1: Identifique la cantidad y el tipo de instancias de aplicaciones que necesita

Primero, céntrese en las aplicaciones y determine la cantidad de instancias de aplicaciones o pods que piensa implementar. A la hora de calcular el tamaño del entorno, tenga en cuenta que cada uno de los elementos de las aplicaciones que se implementan en Red Hat OpenShift, ya sea una base de datos, un servidor de frontend estático o una instancia de máquina virtual, es considerado una instancia de aplicación.

Esta cifra aproximada le servirá para estimar el tamaño de su entorno de Red Hat OpenShift. Para ajustar aún más esta estimación, puede utilizar algunas funciones, como la CPU, la asignación de más memoria de la que hay en el host físico, las cuotas y los límites.

Tabla 1: Preguntas sobre el tamaño de las aplicaciones y las instancias

Tenemos una aplicación que consiste en 200 instancias de contenedores, cada una de las cuales consume en promedio 1 vCPU y 4 GB de RAM. El uso máximo preferido es 80 %. Ejecutamos la aplicación en AWS y tenemos acceso a tipos de instancia M6i de EC2. Nuestra aplicación no requiere aceleradores de inteligencia artificial ni hardware específico. Elegimos Red Hat OpenShift Platform Plus como nuestra versión autogestionada y, por el momento, solo necesitamos calcular la cantidad de suscripciones que requerimos.

Paso 1: Identifique la cantidad y el tipo de instancias de aplicaciones que necesita

A partir de la información del ejemplo:

• Cantidad de instancias de aplicaciones = 200
• Uso máximo preferido del nodo = 80 %
• Requisito de vCPU de la aplicación promedio = 1 vCPU
• Espacio promedio de memoria en la aplicación = 4 GB

Paso 2: Determine la cantidad total de memoria y de núcleos que necesita

A partir de los resultados de los cálculos del paso 1:

• Uso máximo = 80 %
• Total de vCPU requeridas = 1 vCPU × 200 × 1 / 80 % = 250 vCPU
• Total de memoria requerida = 4 GB × 200 × 1 / 80 % = 1000 GB

Paso 3: Elija un nodo informático estándar

Según la información obtenida, no necesitamos un tipo de instancia con GPU o hardware especializado. Nuestra relación de vCPU:Memoria es 250 vCPU:1000 GB, o 1:4. Afortunadamente, hay varios tipos de instancia con esa proporción. Después de analizar los otros factores que requiere la aplicación, determinamos que el tipo de instancia más adecuado para nuestras necesidades es m6i.4xlarge. Cada instancia tiene 16 vCPU y 64 GB de memoria.

Paso 4: Calcule la cantidad total de suscripciones que se necesitan

En este caso, necesitamos suscripciones de par de núcleos, ya que la aplicación se ejecuta en la nube de uno de los proveedores principales, la cual utiliza vCPU. Por eso, usaremos la fórmula para la suscripción del par de núcleos que describimos en el paso 2.

Total de suscripciones de par de núcleos = Total de vCPU requeridas / 4, redondeado hacia arriba

250 vCPU / 4 = 62,5 (o 63, redondeado hacia arriba)

Paso 5: Calcule la cantidad total de suscripciones de AI Accelerator (si corresponde)

Esta sección no se aplica en este ejemplo porque no usamos aceleradores de inteligencia artificial.

Resultado

En este ejemplo, se necesitarían 63 suscripciones de par de núcleos a OpenShift Platform Plus.

Ahora, queremos ejecutar la misma aplicación en las instalaciones y en un servidor dedicado (bare metal), la cual implementamos en nodos informáticos de máquinas virtuales usando la función OpenShift Virtualization de Red Hat OpenShift. La aplicación consiste en 200 instancias de contenedores, cada una de las cuales consume 1 vCPU y 4 GB de RAM. El uso máximo preferido es 80 %. Nuestra aplicación no requiere aceleradores de inteligencia artificial ni hardware específico. Elegimos Red Hat OpenShift Platform Plus como nuestra versión autogestionada y, por el momento, solo necesitamos calcular la cantidad de suscripciones que requerimos. Tenemos cierta flexibilidad a la hora de elegir la configuración del servidor dedicado (bare metal), pero usaremos una estándar lista para usar.

Paso 1: Identifique la cantidad y el tipo de instancias de aplicaciones que necesita

A partir de la información del ejemplo:

• Cantidad de instancias de aplicaciones = 200
• Uso máximo preferido del nodo = 80 %
• Requisito de vCPU de la aplicación promedio = 1 vCPU
• Espacio promedio de memoria en la aplicación = 4 GB

Paso 2: Determine la cantidad total de memoria y de núcleos que necesita

A partir de los resultados de los cálculos del paso 1:

• Uso máximo = 80 %
• Total de vCPU requeridas = 1 vCPU × 200 × 1 / 80 % = 250 vCPU
• Total de memoria requerida = 4 GB × 200 × 1 / 80 % = 1000 GB

Paso 3: Elija un nodo informático estándar

Nuestro servidor dedicado (bare metal) estándar actual tiene 2 sockets y 32 núcleos y 64 vCPU por socket. Podemos elegir la RAM. Como nuestra relación de vCPU por RAM es 1:4, incorporaremos 256 GB de RAM en nuestros servidores. Por lo tanto, elegiremos un servidor dedicado (bare metal) con 2 sockets y 32 núcleos y 64 vCPU por socket (64 núcleos y 128 vCPU por servidor) y 256 GB de RAM.

Paso 4: Calcule la cantidad total de suscripciones que se necesitan

En un servidor dedicado (bare metal), podemos elegir entre suscripciones de par de núcleos y de par de sockets, así que calculemos ambas opciones:

Total de suscripciones de par de núcleos = Total de vCPU requeridas / 4, redondeado hacia arriba

250 vCPU / 4 = 62,5 (o 63, redondeado hacia arriba)

Total de suscripciones de par de sockets =

• Cantidad total de servidores necesarios = 250 vCPU / 128 vCPU por servidor, redondeado hacia arriba = 2 servidores
• Cantidad total de suscripciones necesarias por servidor = Cantidad total de núcleos por par de sockets / 128, redondeado hacia arriba = 64 / 128 = 0,5 redondeado hacia arriba= 1 suscripción
• 2 servidores × 1 suscripción/servidor = 2 suscripciones de par de sockets de servidor dedicado (bare metal)

En este caso, como pudimos elegir un servidor que nos diera la relación indicada de vCPU por memoria, no necesitamos calcular la cantidad de servidores que hacen falta para cumplir con los requisitos de memoria y tomar el que sea más alto. Si el servidor precisara otra cantidad de RAM, deberíamos tener en cuenta esa diferencia.

Paso 5: Calcule la cantidad total de suscripciones de AI Accelerator (si corresponde)

Esta sección no se aplica en este ejemplo porque no usamos aceleradores de inteligencia artificial.

Resultado

En este ejemplo, se necesitarían 63 suscripciones de par de núcleos de OpenShift Platform Plus o 2 suscripciones de par de sockets de servidor dedicado (bare metal). A esta altura, la decisión depende de lo que convenga en términos financieros o de arquitectura. 

Trasladamos nuestras máquinas virtuales de otro hipervisor a Red Hat. Se trata de un entorno combinado, pero identificamos las siguientes máquinas virtuales de diferentes tamaños:

• 1000 pequeñas= 1000 vCPU, 4000 GiB, además de 228 GiB de sobrecarga de memoria
• 300 medianas = 600 vCPU, 2400 GiB, además de 73 GiB de sobrecarga de memoria
• 200 grandes = 800 vCPU, 4800 GiB, además de 58 GiB de sobrecarga de memoria
• 200 extragrandes = 1600 vCPU, 9600 GiB, además de 64 GiB de sobrecarga de memoria

Paso 1: Identifique la cantidad y el tipo de instancias de aplicaciones que necesita

A partir de la información del ejemplo:

• Cantidad de instancias de aplicaciones = 1700
• Total de vCPU =  4000 vCPU
• Total de memoria = 20 800 GB + 423 GB de sobrecarga = 21 223 GB
• Requisito de vCPU de la aplicación promedio = 2,4 vCPU
• Espacio promedio de memoria en la aplicación = 12,5 GB

Paso 2: Determine la cantidad total de memoria y de núcleos que necesita

A partir de los resultados de los cálculos del paso 1:

• Total de memoria requerida = 20 800 GB + 423 GB de sobrecarga = 21 223 GB
• Total de vCPU requeridas =  4000 vCPU

El indicador que determina el uso máximo de máquinas virtuales difiere levemente del de los contenedores, pero no debería presentar dificultades a los administradores de virtualización.

En general, recomendamos que no se sobreasigne la memoria de las máquinas virtuales, por lo que los requisitos de memoria suelen ser el factor principal a la hora de establecer la cantidad de nodos informáticos.

En cambio, en el caso de los recursos informáticos, se espera que se sobreasigne la CPU, ya que la mayoría de las máquinas virtuales no los usan todos. La relación máxima de sobreasignación de la CPU para OpenShift Virtualization es de 10:1, por lo que una relación como 4:1 es una elección moderada. En este punto, se puede elegir si usar núcleos o subprocesos para igualar una vCPU (recordemos que, con la tecnología hyperthreading, cada núcleo puede representar dos subprocesos). Podemos optar por ser moderados y elegir una vCPU que equivalga a un núcleo sin hyperthreading. Ahora, estos son nuestros requisitos:

• Total de memoria requerida = 20 800 GB + 423 GB de sobrecarga = 21 223 GB
• Total de núcleos requeridos = 4000 vCPU × 1/4 × 1 núcleo/vCPU = 1000 núcleos

Paso 3: Elija un nodo informático estándar

La elección de un nodo informático de servidor dedicado (bare metal) para virtualización depende de muchos factores, como los dominios de redundancia y de fallas, el tamaño de los clústeres, etc. En las instalaciones, disponemos de distintas opciones, como el aumento de la RAM por servidor. Este puede ser nuestro punto de partida, ya que la memoria suele determinar los requisitos del servidor.

Tenemos 1700 máquinas virtuales y optamos por un servidor de 2 sockets con 32 núcleos en cada uno de ellos. Si usamos la cantidad de núcleos para establecer el número de servidores, necesitaremos:

• 1000 núcleos / 64 núcleos/servidor, redondeado hacia arriba = 16 servidores

Con 16 servidores, necesitaremos 21 223 GB / 16 servidores = 1326 GB por servidor. Con nuestro servidor, podemos elegir 1536 GB de RAM. Ahora, esta es nuestra configuración de servidor dedicado (bare metal):

• Servidor de 2 sockets con 32 núcleos/socket (64 núcleos en total) y 1536 GB de RAM

Por último, 16 servidores con esta configuración dan como resultado el siguiente total:

• 16 × 64 núcleos = 1024 núcleos
• 16 × 1536 GB = 24 576 GB de memoria

Esto es suficiente para ejecutar las cargas de trabajo de las máquinas virtuales, pero se necesitarán más servidores para garantizar la redundancia. No podemos arriesgarnos a perder ningún servidor y que se interrumpa el servicio o que se vea afectado su rendimiento de modo significativo. Nuestros administradores de virtualización nos recomiendan tener un 25 % de capacidad de reserva para asegurar la redundancia y la tolerancia a fallos. Para ello, necesitamos:

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

Repartiremos las máquinas virtuales en los 20 servidores para que, aunque perdamos entre 1 y 4 de ellos, podamos cumplir con los requisitos de las máquinas. (Sus requisitos de resistencia pueden ser diferentes de estos).

Paso 4: Calcule la cantidad total de suscripciones que se necesitan

Para un caso práctico de virtualización exclusiva usamos OpenShift Virtualization Engine, que solo se encuentra disponible en suscripciones de par de sockets de servidor dedicado (bare metal).

Total de suscripciones de par de sockets =

• Cantidad total de servidores necesarios = 20
• Cantidad total de suscripciones necesarias por servidor = 1, ya que el uso máximo de nuestros servidores es de 64 núcleos por par de sockets
• 20 servidores × 1 suscripción/servidor = 20 suscripciones de par de sockets de servidor dedicado (bare metal)

Paso 5: Calcule la cantidad total de suscripciones de AI Accelerator (si corresponde)

Esta sección no se aplica en este ejemplo porque no usamos aceleradores de inteligencia artificial.

Resultado

En este ejemplo, se necesitarían 20 suscripciones de par de sockets de servidor dedicado (bare metal) a OpenShift Virtualization Engine. 

Tabla 1: Diferencias generales en las funciones de las versiones de Red Hat OpenShift

Tabla 2: Diferencias detalladas entre las versiones de Red Hat OpenShift, incluidos los operadores que ofrecen las funciones

Nota 1: La licencia del operador OpenShift Elasticsearch Operator incluido en Red Hat OpenShift solo respalda las necesidades de búsqueda de la infraestructura interna del clúster de OpenShift y no puede usarse de manera independiente para las aplicaciones de los clientes.

Software típico de Red Hat que no se incluye en ninguna versión de Red Hat OpenShift

A menos que se indique lo contrario, las ofertas de software de Red Hat que aparecen a continuación suelen usarse junto con OpenShift y necesitan sus propias autorizaciones. Red Hat OpenShift Platform Plus incluye Red Hat Advanced Cluster Management, Red Hat Advanced Cluster Security, Red Hat Quay y Red Hat OpenShift Data Foundation Essentials. Otras suscripciones de la versión autogestionada de OpenShift no incluyen estos productos adicionales, pero se pueden adquirir por separado. Estos son otros sistemas de software de Red Hat que se usan con Red Hat OpenShift, pero no están incluidos en esta guía sobre las suscripciones:

• Red Hat Ansible Automation Platform;
• Red Hat Application Foundations;
• Red Hat Enterprise Linux AI;
• la cartera de productos de Red Hat Integration, incluidos 3scale, AMQ, Camel K, Fuse, etc.;
• Red Hat JBoss EAP;
• los paquetes de Red Hat Middleware;
• Red Hat OpenShift Developer Hub (compilación del proyecto Backstage de Red Hat);
• Red Hat OpenShift AI;
• Red Hat Satellite (para la gestión de Red Hat Enterprise Linux);
• IBM CloudPaks.

Si desea obtener más información sobre alguna de las ofertas mencionadas, consulte al partner o al distribuidor de Red Hat.