Cómo puede Red Hat OpenShift ofrecer soporte para su entorno de multinube híbrida

Sabemos que las empresas han migrado o están migrando sus cargas de trabajo a la nube. Sin embargo, es raro que una empresa quiera migrar todas sus aplicaciones a la nube y más raro aun que elija un único proveedor de nube para alojar esas aplicaciones. La estrategia más común es una mezcla de servicios locales y proveedores de nube, lo que se denomina una nube híbrida. Hoy en día, la mayoría de las organizaciones ya está en algún lugar de este complejo proceso de cambio.

En esta publicación del blog explicaré cómo están cambiando las cargas de trabajo, lo que eso significa para los negocios y cómo puede Red Hat OpenShift ayudar a organizaciones con multinubes híbridas.

Primero, algunas definiciones

Una estrategia multinube abarca servicios en la nube de más de un proveedor de nube. A medida que la adopción de la nube crece, las líneas de negocios suelen encontrar nuevas formas de consumir capacidades de la nube para suplir sus demandas específicas de conformidad, seguridad, escalabilidad o costos. Esto, junto a la reticencia de los clientes a confiar en un único proveedor, ha llevado a la mayoría de las organizaciones a adoptar un enfoque multinube.

Nube híbrida se refiere a un entorno de computación que combina nubes públicas y privadas en una misma organización. Algunos negocios usan una solución de nube híbrida para aumentar la seguridad, mientras que otros la usan para igualar el rendimiento requerido para una aplicación particular. Permite que aplicaciones y datos se muevan entre estos entornos.

Una multinube híbrida combina estas estrategias, ofreciendo soluciones de nube pública y privada de más de un proveedor.

Un informe reciente de Flexera indica que el 84 % de las empresas tiene una estrategia multinube, al tiempo que los que planean una estrategia de nube híbrida crecieron a un 58 %.

Nuestras cargas de trabajo están cambiando

No solo tenemos numerosas opciones sobre dónde podemos implementar nuestras aplicaciones, ahora tenemos múltiples opciones sobre cómo podemos implementarlas.

Tradicionalmente teníamos sistemas independientes que ejecutaban un único sistema operativo, usando todo el hardware que dicho sistema poseía y que por lo general proporcionaban una única aplicación. La virtualización de Hypervisor nos trajo después la habilidad de “compartir” recursos de hardware como procesamiento, memoria e I/O. Esto significó que pudiéramos empacar más máquinas virtuales en un único servidor; sin embargo, cada una tendía aún a tener su propio sistema operativo y aplicación. La contenedorización introdujo el concepto de virtualización de sistema operativo. Esto nos permitió implementar y ejecutar aplicaciones en un ambiente “acicalado”, consumiendo muchos menos recursos que las máquinas virtuales, en función de que los contenedores solo necesitan contener los componentes de tiempo de ejecución requeridos para esa aplicación.

Figura 1: Comparando máquinas virtuales y contenedores

¿Qué significa eso para el cliente de una empresa?

Los clientes de las empresas buscan formas de transformar algunas de sus aplicaciones tradicionales en aplicaciones nativas de la nube, pero al mismo tiempo se dan cuenta de que necesitan mantener algunas cargas de trabajo en máquinas virtuales, sean locales o en la nube. Esto introduce la necesidad de implementar y gestionar cargas de trabajo, tanto contenedorizadas como virtualizadas en el entorno de multinube híbrida más adecuado.

No solo eso, ¿qué sucede con la gestión de esos contenedores después de la implementación? ¿Cómo aseguramos que iniciaron correctamente? ¿Cómo los monitoreamos para asegurar que tienen el desempeño esperado? ¿Cómo damos acceso a esas aplicaciones? ¿Cómo actualizamos esas aplicaciones? Esto se hace más complejo en ambientes en los que ejecutamos cientos o miles de contenedores individuales.

Es ahí donde Red Hat OpenShift puede ayudar.

Cómo puede ayudar Red Hat OpenShift

Red Hat OpenShift Container Platform es una plataforma como servicio para empresas construida en Kubernetes. Su propósito primario es proveer a los usuarios una plataforma para construir y escalar aplicaciones de microservicios contenedorizadas en una nube híbrida; podríamos escribir numerosas publicaciones en el blog sobre todas las características disponibles en OpenShift. Puede instalarse localmente, en una nube pública o entregarse por medio de un servicio gestionado.

La arquitectura de OpenShift Container Platform se basa alrededor de nodos master host y de trabajo.

Los master hosts contienen los componentes del panel de control como el servidor API, la tienda de clústeres (etcd), gestor de controlador, HAProxy y demás, y deberían implementarse en una configuración altamente disponible para evitar puntos únicos de fallos. Con OpenShift Container Platform v3.11, los Master hosts son servidores RHEL/Atomic ejecutados en IBM POWER Systems o x86.

Los nodos de trabajo son gestionados por los master hosts y son responsables de ejecutar los contenedores de aplicaciones. Estas cargas de trabajo de aplicaciones son programadas por los master hosts en los nodos de trabajo Con OCP v3.11, los nodos de trabajo son RHEL/Atomic/Linux sobre servidores IBM Z ejecutándose sobre IBM Power Systems, x86 o IBM Z. En este momento usted no puede mezclar arquitectura de nodos dentro del mismo clúster OCP.

¿Qué ofrece OpenShift Container Platform?

OpenShift provee un número de métodos de implementación como DeploymentConfig, StatefulSets y DaemonSets. Estos nos permiten definir cómo debería implementarse nuestra aplicación contenedorizada, incluyendo características clave como número de pods, número de replicaciones, qué imágenes usar para esos pods, opciones de escalado, opciones de actualización, controles de salud, supervisión, IP de servicio e información de ruteo, puerto para escuchar y así por delante. Luego podemos agregar esa plantilla de aplicación al catálogo y permitir que los usuarios del portal de autoservicio la implementen dentro del espacio de su propio proyecto.

Ahora tenemos un estado declarativo que describe cómo queremos que se vea esa aplicación y OpenShift la supervisará para garantizar que coincida con el estado definido. Si se desvía de dicho estado deseado, OpenShift realiza acciones para resolver los problemas.

Veamos un ejemplo donde se definió que una aplicación requiere dos pods en su plantilla de configuración y por alguna razón uno de esos pods se canceló. El master OpenShift notaría esta desviación y actuaría (en este caso, crear un nuevo pod), como se muestra en el cuadro siguiente:

Figura 2: OpenShift recreando el pod cancelado.

IBM Cloud Pak for Multicloud Management y Cloud Automation Manager

Red Hat OpenShift no solo puede entregar aplicaciones contenedorizadas, nos da la capacidad de gestionar un entorno multiclúster e impulsar entornos de TI más tradicionales como las máquinas virtuales locales o en nubes públicas. IBM Cloud Pak for Multicloud Management nos permite gestionar múltiples clústeres Kubernetes, tanto locales como en la nube, dándonos una única vista de todos los clústeres y permitiéndonos realizar tareas de gestión multiclúster.

Figura 3: Visión general de IBM Multicloud Manager

Desde Multicloud Management de Cloud Pak podemos implementar IBM Cloud Automation Manager (CAM) dentro de nuestro clúster OpenShift. Cloud Automation Manager nos da la capacidad de proveer aplicaciones basadas en máquinas virtuales entre múltiples nubes híbridas, al permitirnos registrar proveedores de nube adicionales, como los entornos IBM PowerVC locales (basadas en OpenStack) y VMware vSphere, o proveedores de nube pública como IBM Cloud, Amazon EC2, Microsoft Azure, Google Cloud y otros.

Una vez que hemos agregado nuestros proveedores de nube, podemos configurar plantillas basadas en terraform que definen cómo debería verse un VM dentro del entorno objetivo. Estas plantillas pueden publicarse como ofertas de servicio que aparezcan en el catálogo OCP como se muestra en el siguiente gráfico:

Figura 4: Catálogo OpenShift, incluyendo opciones de máquina virtual

Conclusión

Combinando OpenShift, IBM Automation Manager e IBM Power VC, es posible ofrecer un catálogo autoaprovisionado de aplicaciones similar al mostrado en la figura 4, proporcionando a los usuarios la habilidad de solicitar múltiples aplicaciones que se extienden por un entorno de multinube híbrida.

Si busca soporte para una solución de multinube híbrida en IBM Power Systems, contáctese con IBM hoy mismo.

Para obtener más información sobre el proceso de cambio hacia la multinube híbrida e IBM Power Systems, lea “IBM Power Systems: El proceso de cambio hacia la multinube híbrida”.