Saltar al contenido
MenteHackers

Red Hat reduce servidores para OpenShift en edge por altos costos de hardware

Red Hat presenta una configuración de dos servidores para OpenShift en edge que elimina la necesidad de un tercer nodo, reduciendo costos y complejidad.

Por

· 2 min de lectura

Red Hat reduce servidores para OpenShift en edge por altos costos de hardware

Red Hat ha desarrollado una solución para disminuir la cantidad de servidores necesarios en despliegues edge de alta disponibilidad con su plataforma OpenShift, respondiendo a las preocupaciones de sus clientes sobre los elevados costos de hardware.

Por qué importa: La innovación permite implementar OpenShift en entornos edge con menos nodos, reduciendo costos y simplificando la gestión en miles de sitios.

Lo esencial

  • Red Hat adapta tecnología de su High Availability Add-On para evitar el problema de split-brain en clusters de dos nodos.
  • El método tradicional usa un tercer dispositivo llamado arbiter, pero su costo y complejidad son ahora un problema.
  • La solución usa fencing con Pacemaker y Corosync para forzar el apagado del nodo fallido y mantener la consistencia.

Reducción de nodos en despliegues edge

La unidad de negocio de IBM, Red Hat, ha reconocido que el costo de alimentar, mantener y desplegar un tercer nodo en cientos o miles de sitios edge se ha vuelto prohibitivo, especialmente tras el aumento reciente en los precios del hardware. Por ello, han presentado una configuración que permite operar OpenShift con solo dos servidores, eliminando la necesidad de un mini-PC o dispositivo arbiter adicional.

El problema del split-brain y la solución fencing

En clusters de dos nodos, el split-brain ocurre cuando ambos servidores pierden comunicación y actúan simultáneamente como primarios, causando conflictos y pérdida de datos. Tradicionalmente, un arbiter con recursos mínimos mantenía el quorum para evitar esto. Ahora, Red Hat emplea fencing, una técnica que usa Pacemaker para forzar el apagado o reinicio del nodo desconectado, asegurando que solo un nodo esté activo y evitando inconsistencias.

Red Hat reduce servidores para OpenShift en edge por altos costos de hardware
Imagen de referencia: The Register.

Requisitos técnicos y limitaciones

Para implementar fencing, es necesario que los servidores cuenten con un controlador de gestión baseboard (BMC) compatible con la API Redfish, que permite controlar remotamente el hardware. Sin embargo, esta configuración presenta desafíos, como la posibilidad de inconsistencias si un nodo desconectado vuelve a encenderse automáticamente o la necesidad de intervención manual si ambos nodos fallan simultáneamente.

Impacto para organizaciones y despliegues edge

Esta innovación responde a la demanda creciente de soluciones edge escalables y económicas, donde el costo y la complejidad del hardware son barreras significativas. Al reducir el número de nodos y eliminar el arbiter, Red Hat facilita la adopción de OpenShift en entornos distribuidos, especialmente en sectores industriales y de telecomunicaciones que requieren alta disponibilidad con recursos limitados.

Preguntas frecuentes sobre OpenShift en edge con dos nodos

¿Qué es fencing y por qué es clave en esta solución?

Fencing es una técnica que permite a Pacemaker forzar el apagado o reinicio de un nodo desconectado para evitar que ambos nodos actúen como primarios, previniendo el split-brain.

¿Qué limitaciones tiene esta configuración de dos nodos?

Puede haber inconsistencias si un nodo vuelve a encenderse sin coordinación y requiere intervención manual si ambos nodos fallan simultáneamente.

Sobre el autor

AJOSE19

Comentarios

Deja tu comentario

Te puede interesar