¿Qué es la sobreasignación de recursos de VM en un host SCADA?
La virtualización ahorra dinero en parte porque la mayoría de las máquinas virtuales no usan todos sus recursos asignados todo el tiempo, así que un host puede prometer más CPU y memoria a sus VM de la que físicamente posee y salirse con la suya. Esa práctica se llama sobreasignación, y para cargas de oficina ordinarias es eficiente e inofensiva. Para una VM SCADA en tiempo real, sin embargo, la sobreasignación puede estrangular en silencio a la única máquina que nunca debe llegar tarde, causando escaneos de sondeo perdidos que parecen problemas de red pero en realidad son el hipervisor racionando ciclos. Esta guía explica qué son la sobreasignación de CPU y memoria, los riesgos de ballooning y de CPU-ready que dañan las cargas de control, y por qué las VM del SCADA y del historiador necesitan reservas y recursos fijados.
Sobreasignación de recursos de VM en una línea: La sobreasignación de recursos de VM, también llamada sobresuscripción, es cuando un host de virtualización asigna más CPU o memoria a sus máquinas virtuales de la que tiene físicamente, apostando a que no todas demandarán su porción completa a la vez. Es eficiente para cargas en ráfagas, pero puede estrangular de ciclos a una VM SCADA en tiempo real cuando el host se ocupa, por lo que las VM de control necesitan reservas garantizadas en lugar de apoyarse en que el host reparta con justicia.
Cómo la sobreasignación ahorra dinero y dónde falla la apuesta
La sobreasignación existe porque la mayoría de las máquinas virtuales están ociosas la mayor parte del tiempo. Un host con, digamos, dieciséis núcleos físicos de CPU podría repartir el equivalente a cuarenta núcleos virtuales entre sus VM, bajo la suposición razonable de que rara vez estarán todas ocupadas simultáneamente. La misma lógica aplica a la memoria: el host puede prometer más RAM a sus VM de la que tiene físicamente, respaldando el faltante con técnicas ingeniosas de recuperación, porque en cualquier momento dado mucha de la memoria asignada queda sin usar. Cuando la apuesta se sostiene, el sitio obtiene mucha más consolidación del mismo hardware, y eso es dinero real ahorrado.
La apuesta es estadística, y funciona porque las cargas en ráfaga y no correlacionadas rara vez alcanzan su pico juntas. Un servidor de archivos de oficina, una cola de impresión, y una base de datos de reportes están cada uno ocupados en momentos distintos, así que sobreasignarlos es seguro. El problema es que la sobreasignación asume que cualquier VM dada puede tolerar esperar un momento por su turno cuando la contención sí se dispara, porque para la mayoría del software unos milisegundos extra de latencia son invisibles. Esa suposición es justo la que una carga de control en tiempo real viola.
Un servidor SCADA corre sobre un reloj. Debe sondear sus dispositivos de campo, procesar las respuestas, evaluar alarmas, y actualizar el historiador dentro de un ciclo de escaneo que se repite a una cadencia fija. Si el hipervisor hace esperar a la VM SCADA por CPU porque prometió de más ciclos a otras VM que todas se ocuparon a la vez, el escaneo corre tarde. Para un operador eso parece un dispositivo volviéndose no responsivo o un fallo de comunicación, pero la causa real es que la VM de control perdió una carrera por núcleos físicos que en realidad nunca tuvo garantizados. La sobreasignación que es invisible para una VM de oficina se vuelve un escaneo perdido para una VM de control.
Ballooning, CPU-ready y los riesgos que causan escaneos perdidos
Dos mecanismos específicos explican la mayoría de los problemas de sobreasignación en SCADA. El primero es el ballooning de memoria, la técnica que un host usa para recuperar RAM que prometió de más. Un pequeño controlador dentro de cada VM puede inflarse por demanda, presionando al sistema operativo huésped a devolver memoria al host para que pueda entregarse a una VM que la necesita más. Bajo presión de memoria el host infla el globo en la VM SCADA, el huésped empieza a paginar a disco para arreglárselas, y una máquina que debería estar sirviendo un escaneo está en cambio intercambiando memoria - una ralentización fácil de diagnosticar mal porque la VM aún reporta abundante RAM asignada.
El segundo es el tiempo de CPU-ready, el intervalo que una CPU virtual pasa lista para correr pero esperando porque ningún núcleo físico está libre. En un host sin contención, el tiempo ready es despreciable. En un host sobreasignado bajo carga, las CPU virtuales de una VM hacen fila por núcleos físicos escasos, y esa fila se muestra como tiempo ready. Para la mayoría de las VM un poco de tiempo ready es inofensivo, pero para una VM SCADA cada milisegundo de tiempo ready es un milisegundo que el escaneo se demora, y si el tiempo ready trepa, los escaneos empiezan a incumplir sus plazos. Monitorear el CPU-ready es muchas veces como los equipos de OT versados en virtualización atrapan una VM de control siendo estrangulada en silencio.
Hay una trampa más sutil con las VM anchas. Si la VM SCADA se configura con muchas CPU virtuales, el hipervisor puede necesitar alinear esa cantidad de núcleos físicos libres en el mismo instante antes de que la VM pueda correr, y en un host ocupado y sobreasignado esos núcleos rara vez se liberan juntos, así que una VM ancha puede esperar más que una angosta. Darle a una VM de control más CPU virtuales de las que necesita puede por tanto empeorar su latencia, no mejorarla - uno de los riesgos contraintuitivos que hacen del ajuste de sobreasignación para cargas en tiempo real algo distinto de ajustar servidores ordinarios.
Reservas, participaciones y fijación para VM SCADA en tiempo real
La cura no es prohibir la sobreasignación de plano, sino eximir las cargas que no pueden tolerarla. Los hipervisores proveen reservas, una garantía de que una VM siempre obtendrá al menos una cantidad definida de CPU y memoria que el host aparta y nunca sobreasigna. Reservar los recursos de las VM del SCADA y del historiador las saca del conjunto estadístico: sin importar qué tan ocupadas se pongan las demás VM, las VM de control tienen un piso de recurso físico que es suyo. Ese piso es lo que mantiene los escaneos a tiempo mientras el resto del host permanece eficientemente sobreasignado.
Dos controles relacionados ayudan. Las participaciones fijan la prioridad relativa que una VM recibe cuando el host tiene que arbitrar la contención, así que subir las participaciones de la VM SCADA hace que el planificador la favorezca sobre vecinos de menor prioridad durante un aprieto. La afinidad o fijación de CPU ata las CPU virtuales de una VM a núcleos físicos específicos, así que la carga de control no se rebota de un lado a otro ni tiene que competir por el núcleo que resulte estar libre. Las reservas garantizan la cantidad; las participaciones y la fijación moldean cómo y dónde se sirve la VM. Juntas convierten un host compartido en uno donde las VM de control se comportan como si tuvieran hardware dedicado.
Para el SCADA en la nube, toda esta clase de preocupación de ajuste se quita del plato del cliente para la capa primaria de monitoreo. Cuando una plataforma como Merobix corre la carga del SCADA y del historiador en un entorno de nube administrado, las garantías de recursos, el margen de capacidad y el aislamiento de rendimiento son responsabilidad del proveedor, ingenierizados para que la ingesta y los tableros se mantengan ágiles bajo carga. Los hosts en sitio aún necesitan reserva y fijación cuidadosas para cualquier VM de control local, pero el monitoreo de cara al campo que los operadores vigilan no depende de que alguien se acuerde de reservar CPU para la VM SCADA en una caja compartida de vuelta en el sitio.
Preguntas frecuentes
¿Sobreasignar un host de virtualización SCADA es alguna vez seguro?
Sobreasignar el host está bien para las VM que no son de tiempo real que corren en él, pero las VM del SCADA y del historiador deben protegerse de ello con reservas para que siempre obtengan CPU y memoria física garantizadas. En otras palabras, aún puede sobreasignar las cargas de estilo oficina para ahorrar dinero, siempre que las VM de control se aparten con un piso garantizado. Sobreasignar las VM de control mismas arriesga escaneos perdidos cuando el host se ocupa.
¿Qué causa que un servidor SCADA virtualizado pierda escaneos?
Dos culpables comunes de sobreasignación son el ballooning de memoria, donde el host recupera RAM de la VM SCADA y la fuerza a paginar a disco, y el tiempo de CPU-ready alto, donde las CPU virtuales de la VM esperan por núcleos físicos ocupados. Ambos demoran el ciclo de escaneo y pueden parecer un fallo de comunicación. Fijar reservas de recursos y monitorear el tiempo de CPU-ready por lo general resuelve y diagnostica el problema.
¿Qué es el ballooning de memoria?
El ballooning de memoria es cómo un hipervisor recupera memoria que prometió de más. Un controlador dentro de cada VM huésped puede inflarse para presionar a ese huésped a liberar memoria de vuelta al host, que luego la redistribuye a las VM que la necesitan más. Funciona en silencio para VM ociosas, pero inflar el globo en una VM SCADA ocupada fuerza a su huésped a paginar a disco, ralentizando la carga de control aunque la VM aún muestre abundante memoria asignada.
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.