¿Qué es un host de virtualización SCADA?
Las salas de control modernas rara vez corren ya una aplicación por caja física. En cambio, un solo servidor poderoso, el host de virtualización, corre el servidor SCADA, el historiador, el controlador de dominio, y la estación de ingeniería lado a lado como máquinas virtuales separadas. Esa consolidación ahorra espacio de rack, energía, y costo, pero también concentra todo el sistema de control en una pieza de hardware, lo que cambia cómo tiene que pensar en la redundancia. Esta guía explica qué es el host de virtualización, cómo se dimensiona para cargar una pila de VM de SCADA, por qué el host mismo se vuelve un punto único de falla crítico, y cómo los sitios agrupan hosts en cluster para que ninguna caja pueda tumbar la sala de control.
Host de virtualización SCADA en una línea: Un host de virtualización SCADA es el servidor físico que corre el hipervisor y hospeda varias máquinas virtuales de SCADA, típicamente el servidor SCADA, el historiador, el controlador de dominio, y la estación de ingeniería, en una caja. Como esa sola máquina ahora carga toda la pila de la sala de control, el host mismo se vuelve un punto único de falla crítico, por lo que los sitios de producción agrupan dos o más hosts en cluster para que las VM sobrevivan la pérdida de cualquiera.
Una caja corriendo toda la pila de la sala de control
El host de virtualización es el hardware físico, sockets de CPU, memoria, almacenamiento, y adaptadores de red, sobre el cual corre un hipervisor. El hipervisor es la capa de software que talla los recursos del host en máquinas virtuales aisladas; el host es el metal debajo de él. Donde una sala de control tradicional pudo haber tenido cuatro o cinco servidores físicos separados, cada uno corriendo un rol, un solo host bien aprovisionado puede correr todos esos roles como VM, cada una con su propio sistema operativo y cada una creyendo que tiene su propia máquina.
Consolidar así trae ventajas reales más allá de ahorrar espacio. Cada función SCADA queda aislada en su propia máquina virtual, así que un problema en el historiador no tumba al servidor SCADA, y cada VM puede tomarse una instantánea, respaldarse como imagen, y moverse entre hosts como una unidad autocontenida. Aprovisionar una nueva estación de ingeniería se vuelve cuestión de clonar una VM en lugar de conseguir y construir una nueva caja física. Parchar y probar se vuelve más seguro porque una instantánea permite revertir una actualización mala en minutos.
El compromiso es la concentración. Cinco roles que solían fallar de forma independiente en cinco máquinas ahora comparten un conjunto de fuentes de poder, una tarjeta madre, un conjunto de controladores de almacenamiento, y un entorno operativo de host. Un solo host es enormemente capaz, pero es también una sola canasta que contiene todos los huevos de la sala de control. Esa realidad es lo que impulsa las dos preguntas centrales de diseño para un host de virtualización: cuánto hardware necesita para cargar la carga con comodidad, y cómo asegurar que la pérdida del host no equivalga a la pérdida del sistema SCADA.
Dimensionar el host para la consolidación
Dimensionar un host de virtualización significa totalizar las demandas de cada VM que cargará y luego dejar margen generoso. Suma los núcleos de procesador que cada VM necesita, la memoria que cada una requiere, la capacidad de almacenamiento y el rendimiento de disco para el historiador y las bases de datos, y el rendimiento de red para el sondeo y el tráfico de operadores. A esa suma agrega margen para la sobrecarga propia del hipervisor, para parchar sin apagar las VM, y para los momentos pico en que varias VM están ocupadas a la vez en lugar del promedio tranquilo.
Las VM de SCADA no son todas iguales, lo que complica el cálculo. El historiador es hambriento de almacenamiento y de E/S conforme escribe un flujo constante de mediciones, mientras que el servidor SCADA es más sensible a la disponibilidad sostenida de procesador porque debe completar sus escaneos de sondeo a tiempo. El controlador de dominio y la estación de ingeniería son más ligeros pero aun así necesitan estar presentes. El buen dimensionamiento respeta estas diferencias en lugar de tratar cada VM como una rebanada igual, y evita deliberadamente correr el host tan cerca del lleno que una VM de SCADA en tiempo real empiece a perder escaneos cuando los vecinos se ocupan.
El error de dimensionamiento más común es empacar el host demasiado apretado para exprimir la máxima consolidación, y luego descubrir que la VM de SCADA tartamudea bajo contención. Las cargas de control tienen expectativas de tiempo real que los servidores de oficina ordinarios no tienen, así que la tentación de sobresuscribir un host tiene que resistirse donde las VM de SCADA e historiador están involucradas. Dimensionar con margen, y reservar recursos garantizados para las VM críticas en tiempo, es lo que evita que la consolidación degrade en silencio el desempeño del sistema de control. Un host dimensionado solo para el promedio fallará justo cuando el proceso se ponga interesante.
El host como punto único de falla y su agrupamiento en cluster
Como un solo host ahora carga toda la pila de la sala de control, su falla es un evento de toda la sala de control, no la pérdida de un rol. Una fuente de poder fallida, una tarjeta madre muerta, o un entorno operativo de host corrupto tumba el servidor SCADA, el historiador, el controlador de dominio, y la estación de ingeniería juntos. Este es el riesgo definitorio de la consolidación, y es por lo que un host de virtualización solitario corriendo SCADA de producción es un diseño que renuncia a la independencia misma que los servidores físicos separados solían proveer.
La respuesta estándar es un cluster de hosts: dos o más hosts unidos con almacenamiento compartido o replicado, para que las VM no estén atadas a ninguna máquina. Si un host falla, el cluster reinicia sus VM en los hosts sobrevivientes automáticamente, y la sala de control está de vuelta en minutos en lugar de esperar una reparación de hardware. Para el mantenimiento planeado, las VM pueden moverse en vivo de un host a otro para que la caja física pueda parcharse o servirse sin tiempo de inactividad. El cluster convierte al host de un punto único de falla en un miembro reemplazable de un pool resiliente.
Un par en cluster también necesita cuidado con el problema de desempate: dos hosts deben ponerse de acuerdo sobre quién es dueño de cuáles VM para que no intenten ambos correr el mismo servidor SCADA a la vez, por lo que los clusters usan un testigo o mecanismo de quórum para arbitrar. Para sitios remotos o no atendidos, el SCADA de nube cambia lo que está en juego ante una falla de host, cuando una plataforma como Merobix contiene el monitoreo primario y la historia en una nube administrada, una interrupción de host en sitio ya no deja ciegos a los operadores, porque los datos de campo siguen transmitiéndose a un tablero de navegador mientras el cluster local se recupera. El host todavía importa para cualquier carga en sitio, pero deja de ser lo único que se interpone entre los operadores y el proceso.
Preguntas frecuentes
¿Cuál es la diferencia entre un host de virtualización y un hipervisor?
El hipervisor es el software que divide los recursos de una máquina en máquinas virtuales aisladas; el host de virtualización es el hardware del servidor físico sobre el que corre el hipervisor. En conversación casual la gente usa los términos de forma suelta, pero estrictamente el host es el metal, CPU, memoria, almacenamiento, y red, y el hipervisor es la capa encima que permite a esa caja correr varias VM de SCADA a la vez.
¿Puedo correr un sistema SCADA entero en un solo host de virtualización?
Técnicamente sí, y muchos sitios pequeños lo hacen, pero un solo host hace que toda la sala de control dependa de una pieza de hardware. Una falla de fuente de poder, tarjeta madre, o almacenamiento tumba el servidor SCADA, el historiador, y cada otra VM juntos. Los sitios de producción que no pueden tolerar ese riesgo agrupan dos o más hosts en cluster para que las VM sobrevivan la pérdida de cualquier máquina, que es el diseño más seguro para cualquier cosa crítica.
¿Cuántas VM puede correr un host de SCADA?
Depende por completo de la capacidad de procesador, memoria, y almacenamiento del host frente a la demanda combinada de las VM, así que no hay número fijo. El enfoque correcto es dimensionar por carga: totalice la CPU, RAM, y E/S que cada VM necesita, agregue margen para el hipervisor y para la carga pico, y reserve recursos garantizados para las VM de SCADA e historiador en tiempo real. Empacar demasiadas en un host arriesga hambrear a las VM de control críticas en tiempo.
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.