Guía sobre las suscripciones de los entornos autogestionados de Red Hat OpenShift

En este documento, conocerás el modelo de suscripción a las ofertas autogestionadas de Red Hat® OpenShift® y obtendrás instrucciones paso a paso para calcular la cantidad aproximada de autorizaciones de acceso que necesitas para tu entorno de Red Hat OpenShift. Si lo solicitas, podemos brindarte información más precisa para determinar las dimensiones.

Primero, definamos ciertos términos que debes comprender.

• Par de núcleos: Es una de las bases de las suscripciones a la versión autogestionada de OpenShift. Se define como dos núcleos físicos o cuatro unidades centrales de procesamiento virtuales (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.
• Nodo de servidor dedicado (bare metal): Es otra de las bases de las suscripciones a la versión autogestionada de OpenShift. Se requiere una suscripción de nodo de servidor dedicado (bare metal) por cada servidor físico. Una sola suscripción de nodo 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.
• 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. Puedes elegir entre dos opciones: Standard 8x5 o Premium 24x7.
• Nodos informáticos: Son 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: Se trata de 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. Consulta la sección "Nodos de infraestructura y de plano de control de Red Hat OpenShift" para obtener más detalles.
• Nodos de infraestructura: Son 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: Es 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 la 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, la nube privada, la nube pública y las implementaciones en el extremo de la red. La plataforma 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, puedes instalar, operar y gestionar los entornos de Red Hat OpenShift con una mayor capacidad de control, flexibilidad y personalización, lo cual te permite manejar tu 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. Tú controlas las actualizaciones, gestionas la infraestructura inferior y mantienes 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 tus 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 de Red Hat OpenShift totalmente gestionado en Amazon Web Services (AWS) y Google Cloud.
• Microsoft Azure Red Hat OpenShift: Servicio de Red Hat OpenShift en Microsoft Azure totalmente gestionado 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 te permite trasladar tus 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. Consulta 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. Puedes 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. Puedes 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 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 nodo 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 nodos 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, cuenta 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 deseas autorizar con las suscripciones de par de núcleos.
• Se encuentra disponible con un SLA de soporte Standard 8x5 o Premium 24x7.

2. Nodo de servidor dedicado (bare metal) (1 nodo físico) 

• Un nodo físico es un servidor, independientemente de la cantidad de sockets de CPU en el servidor o de núcleos en las CPU.
• 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.

Además, necesitas suscripciones a Red Hat AI Accelerator para los aceleradores de tu entorno.

1.  AI Accelerator (un 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 de nodo 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 puedes usar suscripciones de par de núcleos en dispositivos o servidores dedicados (bare metal), es decir, sin hipervisor. Ten en cuenta que es posible que, para cierta densidad de pods informáticos, sean más rentables las suscripciones de nodo de servidores dedicados (bare metal).

Cuando utilizas OpenShift Virtualization Engine como plataforma de virtualización exclusiva, puedes elegir habilitar los contenedores de OpenShift en máquinas virtuales usando suscripciones de par de núcleos, junto con las de nodo de servidor dedicado (bare metal) del hipervisor. Debes 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 compres y ejecutes 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 nodo 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 nodo de servidor dedicado (bare metal)

Las suscripciones de nodo 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 hyperscalers 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 nodo de servidor dedicado (bare metal) autoriza un solo nodo físico, independientemente de la cantidad total de sockets o núcleos de CPU.

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, debes 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 cuentan con suscripciones de nodos 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 deseas ejecutar tus propias cargas de trabajo de aplicaciones en contenedores con OpenShift Virtualization Engine, debes 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, puedes optar por adquirir una suscripción de nodo 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) o en clústeres virtuales que hereden las suscripciones, 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 nodo pueden utilizarse en un único clúster. Por ejemplo, no puedes 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 cuatro dispositivos GPU físicos requiere cuatro suscripciones a AI Accelerator además de las suscripciones de par de núcleos o de nodo 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.
• Ansible Automation Platform, cuando se usa solo para la gestión de clústeres.

Puedes 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 te 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: Puedes 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 mirror registry 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 nodo.

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. Consulta 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 sistemas de recuperación ante desastres calientes son aquellos que funcionan de manera simultánea con los sistemas de producción. Están preparados para recibir tráfico de inmediato y tomar el control en caso de que se produzca un desastre en el entorno principal. Cuando los volúmenes de datos se replican activamente en los distintos clústeres mediante almacenamiento definido por software alojado en OpenShift, 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. Los clústeres de recuperación ante desastres templados no deben participar en la replicación activa de volúmenes de datos en los distintos clústeres , ya sea de forma sincrónica o asincrónica, cuando el sitio secundario (DR) monta dichos datos en cargas de trabajo de contenedores que se están ejecutando en el clúster. Los dispositivos de almacenamiento externo que llevan a cabo la replicación de volúmenes siguen considerándose una recuperación ante desastres templada. En el caso del almacenamiento definido por software alojado en OpenShift, 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 Red Hat OpenShift. 

Tanto en el caso de la recuperación ante desastres templada como en la fría, las suscripciones a Red Hat OpenShift se pueden transferir del entorno principal al de recuperación cuando se produce el desastre, para restaurar el servicio y mantener el cumplimiento de los términos de la suscripción de 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 permite esto para las actualizaciones de versiones principales y no requerirá la compra de suscripciones adicionales para volver a cumplir con las normas 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 solicites. Consulta 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. Aprende 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. Las suscripciones de servidor dedicado (bare metal) basadas en sockets de Red Hat OpenShift no se pueden utilizar 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 para OpenShift Container Plarform utilizan solo un subconjunto de los núcleos disponibles (capacidad informática) en su entorno IBM Z deben adquirir únicamente las suscripciones necesarias para el subconjunto que se emplea para 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 núcleo a OpenShift (IBM Z es la única arquitectura en la que la base para las suscripciones es un solo núcleo). Esta arquitectura no incluye el concepto de vCPU. 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. 

Para IBM Power, se utiliza el modelo de suscripción de par de núcleos. Esta arquitectura no incluye el concepto de vCPU.

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). Consulta el artículo "Red Hat OpenShift Container Platform 4.19 Multi Architecture Component Availability Matrix" en el Portal de clientes Red Hat (se requiere acceso mediante inicio de sesión). Para obtener más información sobre la interoperabilidad entre los elementos de OpenShift Platform Plus y las arquitecturas que no son x86, consulta 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 infraestructura 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, Red Hat OpenShift Platform Plus y Red Hat OpenShift Kubernetes Engine 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 trabajas con un distribuidor externo, consulta 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 gestiones y protejas tu entorno de Red Hat OpenShift en múltiples clústeres y nubes según sea necesario. OpenShift Platform Plus se encuentra disponible en los modelos de suscripción de nodo 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 te permite instalar todas las instancias centrales de Red Hat Advanced Cluster Management que necesites para gestionar tu 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 deseas gestionar nodos y clústeres sin las autorizaciones de acceso de OpenShift Platform Plus (por ejemplo, si también cuentas 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), debes 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 cumples con los requisitos. Obtén 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 te permite instalar todas las aplicaciones centrales de Red Hat Advanced Cluster Security que necesites para gestionar tu 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 deseas gestionar nodos y clústeres sin las autorizaciones de acceso de OpenShift Platform Plus (por ejemplo, si también cuentas 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), debes 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. Obtén más información sobre los entornos compatibles con Red Hat Advanced Cluster Security.
• Red Hat Quay: La suscripción a OpenShift Platform Plus te permite instalar Red Hat Quay en cualquier clúster que cuente con las autorizaciones de acceso de OpenShift Platform Plus. Además, podrás 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 deseas instalar Quay en un entorno que no sea de OpenShift Platform Plus, deberás 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 te 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. Puedes ampliar las funciones y la capacidad a través de suscripciones adicionales. Para obtener más información, consulta la guía OpenShift Data Foundation Subscription Guide (debes iniciar sesión en el Portal de clientes) o ponte en contacto con un representante de ventas de Red Hat.
• Argo CD Agent: La suscripción a OpenShift Platform Plus te permite instalar el elemento Argo CD Agent de Red Hat OpenShift GitOps en cualquier clúster que cuente con una suscripción a OpenShift Platform Plus. Argo CD Agent puede ejecutarse en entornos de Red Hat OpenShift o de Kubernetes compatibles. Red Hat OpenShift Gitops se incluye con OpenShift Container Platform.

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. Estos clientes se centran exclusivamente en la virtualización y tienen la opción de adoptar las funciones modernas de desarrollo de aplicaciones y organización en contenedores a su propio ritmo.

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 nodo de servidor dedicado (bare metal) en servidores físicos e instancias de servidores dedicados (bare metal) compatibles. Cuando los usuarios estén preparados para acceder a una cartera de productos más amplia, podrán actualizar las prestaciones incluidas en su suscripción sin necesidad de volver a implementar los clústeres actuales.

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 Datecenters por separado).

Red Hat Advanced Cluster Management y Red Hat Ansible® Automation Platform son compatibles con OpenShift Virtualization Engine. En comparación con las versiones completas, las suscripciones complementarias para ambos productos están diseñadas específicamente para casos de uso exclusivos de virtualización y son menos costosas. 

Si ya eres cliente de Red Hat Advanced Cluster Management y Ansible Automation Platform, puedes comprar las suscripciones complementarias mencionadas y utilizar tus instalaciones de estas aplicaciones centrales para gestionar el resto de tu entorno y los hosts de OpenShift Virtualization Engine. 

Si no tienes aplicaciones centrales de Red Hat Advanced Cluster Management o Ansible Automation Platform instaladas, la suscripción a estos complementos también incluye soporte para instalarlas como contenedores de infraestructura en tus hosts de OpenShift Virtualization Engine. Consulta la documentación de Red Hat Advanced Cluster Management o Ansible Automation 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, consulta 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, Red Hat Advanced Cluster Management y Ansible Automation Platform, se ejecutan como contenedores de infraestructura en Red Hat OpenShift. Esto significa que la autorización te 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. Puedes 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: Identifica la cantidad y el tipo de instancias de aplicaciones que necesitas

Primero, céntrate 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, ten 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 te servirá para estimar el tamaño de tu entorno de Red Hat OpenShift. Para ajustar aún más esta estimación, puedes 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

Paso 2: Determina la cantidad total de memoria y de núcleos que necesitas

Una vez que se determinaron los requisitos para una instancia de aplicación y la cantidad de estas, es muy sencillo definir la cantidad de recursos informáticos y de memoria que se necesita. 

A esta altura, debes establecer el uso máximo que harán de ellos los nodos informáticos. También deben tenerse en cuenta los recursos que requiere la gestión de OpenShift (consulta la documentación para obtener más detalles; como referencia, suele destinarse un núcleo o una vCPU y un GB de RAM por nodo informático) y permitirse las variaciones normales que pueda haber en la aplicación sin necesidad de que se ajuste automáticamente. Si supone un uso exigente (superior al 80 %), es posible que debas incluir explícitamente los requisitos de la sobrecarga en el cálculo de recursos de memoria y de núcleos.

En los casos prácticos de virtualización, debe tenerse en cuenta la sobreasignación de memoria y CPU, los aspectos relacionados con la alta disponibilidad y la redundancia y la arquitectura general del entorno. En el ejemplo 3, veremos la forma de determinar el tamaño de un entorno.

Tabla 2: Preguntas sobre el uso máximo preferido de los nodos de OpenShift

Uso máximo = % que eligió el arquitecto

Cantidad total de núcleos (o vCPU) requeridos = núcleos para una aplicación × cantidad de instancias de aplicación × 1 / porcentaje de uso

Cantidad total de memoria requerida = memoria para una aplicación × cantidad de instancias de aplicación × 1 / porcentaje de uso

Paso 3: Elige un nodo informático estándar (máquina virtual, instancia de nube o servidor dedicado [bare metal])

Ahora que ya sabes la cantidad total de núcleos y de memoria que quieres asignar, debe elegir un nodo informático estándar para implementar los nodos de trabajo de sus aplicaciones. 

En una infraestructura de virtualización, es posible que su entorno le permita elegir la configuración de las máquinas virtuales que actuarán como nodo informático o que deba seleccionar una entre varias opciones estándares. 

En la nube de un proveedor principal, por lo general, deberá elegir un tipo de instancia de nube con diferentes recursos informáticos, memoria y acceso a equipos opcionales como los aceleradores de inteligencia artificial. 

Si realiza la implementación en un servidor dedicado (bare metal), ya sea en las instalaciones o en una instancia de un proveedor principal, es posible que el servidor tenga una configuración de servidor estándar y que, en ocasiones, usted pueda establecer su propia configuración. 

Siempre que sea posible, elija los nodos informáticos que mejor se adapten a la relación entre los recursos o a los requisitos de núcleos y de memoria. Por ejemplo, si el requisito total de los contenedores es 400 vCPU y 1600 GB de RAM, las mejores relaciones promedio de consolidación se obtienen cuando se eligen nodos informáticos con una relación 1:4 de vCPU por memoria. 

Tabla 3: Preguntas sobre la determinación del tamaño de la máquina virtual y el hardware

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

Determina la cantidad de suscripciones a Red Hat OpenShift que necesitarás según los datos de los pasos anteriores. Para las suscripciones en máquinas virtuales o instancias de nube de proveedor principal, debe usar el modelo de suscripción de par de núcleos. En el caso de los servidores dedicados (bare metal), debes calcular la suscripción utilizando ambos modelos, comparar las diferencias en términos de costos y flexibilidad y elegir la opción que mejor se adapte a tus necesidades. 

Para el modelo de suscripción de par de núcleos

• Cantidad de suscripciones de par de núcleos de la versión autogestionada de OpenShift¹ 

= total de núcleos / 2, redondeado hacia arriba o

= total de vCPU / 4, redondeado hacia arriba

Para el modelo de suscripción de nodo de servidor dedicado (bare metal)

• Primero, calcula la cantidad de suscripciones de par de núcleos que necesita tu aplicación, ya que puedes usar ese modelo en una instalación de servidor dedicado (bare metal).
• En segundo lugar, determina la cantidad de suscripciones de servidor dedicado (bare metal): cada servidor físico requerirá una suscripción de nodo de servidor dedicado (bare metal) (necesitarás una suscripción por nodo).
• Tercero, compara los dos modelos en términos de costos y flexibilidad.
  • Desde el punto de vista de las finanzas:
    • Probablemente, un modelo de suscripción resultará menos costoso que el otro para su entorno en el tamaño definido.
    • Planifique a futuro y considere que es posible que más adelante se alcance un punto de equilibrio en el que el otro modelo resulte más rentable.
  • Desde el punto de la arquitectura:
    • Las suscripciones de par de núcleos pueden usarse en cualquier ubicación del entorno (máquinas virtuales, instancias de nube y servidores dedicados [bare metal]), mientras que las suscripciones de nodo de servidores dedicados (bare metal) solo se pueden utilizar en este tipo de servidores.
    • Las suscripciones de par de núcleos en servidores dedicados (bare metal) deben ejecutar contenedores en estos servidores y estar en el mismo clúster.
    • Puedes elegir instalar OpenShift Virtualization Engine en los servidores dedicados (bare metal) y agregar suscripciones a OpenShift de par de núcleos para los contenedores (OpenShift en OpenShift). Esta opción es ideal para los entornos con varias máquinas virtuales que tienen pocas cargas de trabajo de OpenShift por servidor.
    • Cuando se necesita una alta densidad de cargas de trabajo de Red Hat OpenShift en un servidor dedicado (bare metal), la suscripción de nodo te ofrece contenedores ilimitados de la plataforma, ya sea directamente en el servidor dedicado (bare metal) o con la función OpenShift Virtualization, en las máquinas virtuales que se ejecutan en el servidor.

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

Agrega todas las suscripciones a AI Accelerator indicadas anteriormente. Necesita una por cada acelerador físico que haya en las instalaciones o en un servidor dedicado (bare metal). En un entorno de nube de proveedor principal, los tipos de instancia para los recursos informáticos acelerados definirán la cantidad de GPU o aceleradores físicos que se incluyen en esas instancias. Recuerda que el SLA de la suscripción a AI Accelerator debe coincidir con la correspondiente suscripción de Red Hat OpenShift.

Nota: 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 puedas ajustar tu 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), lo cual incluye los recursos informáticos y de almacenamiento, aunque posiblemente no requieran suscripciones informáticas adicionales.

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

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: Identifica la cantidad y el tipo de instancias de aplicaciones que necesitas

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: Determina la cantidad total de memoria y de núcleos que necesitas

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: Elige 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 vCPU:memoria es de 250 vCPU:1000 GB o 1:4. Afortunadamente, hay muchos tipos de instancias 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: Calcula 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: Calcula 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: Identifica la cantidad y el tipo de instancias de aplicaciones que necesitas

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: Determina la cantidad total de memoria y de núcleos que necesitas

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: Elige 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: Calcula 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 nodo, 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 nodos = cantidad total de servidores físicos

• Cantidad total de servidores necesarios = 250 vCPU / 128 vCPU por servidor, redondeado hacia arriba = 2 servidores
• 2 servidores × 1 suscripción/servidor = 2 suscripciones de nodo 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 núcleos CPU o RAM, deberíamos tener en cuenta esa diferencia.

Paso 5: Calcula 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 nodo 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: Identifica la cantidad y el tipo de instancias de aplicaciones que necesitas

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: Determina la cantidad total de memoria y de núcleos que necesitas

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: Elige 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: Calcula 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 nodo de servidor dedicado (bare metal).

Total de suscripciones de nodo = 

• Cantidad total de servidores necesarios = 20
• 20 servidores × 1 suscripción/servidor = 20 suscripciones de nodo de servidor dedicado (bare metal)

Paso 5: Calcula 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 nodo 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: 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 (que suelen usarse junto con Red Hat OpenShift) 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 Advanced Developer Suite;
• 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;
• OpenShift Data Foundation Advanced;
• 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 deseas obtener más información sobre alguna de las ofertas mencionadas, consulta al partner o al distribuidor de Red Hat.