¿Qué es un servidor de terminales para SCADA?
En lugar de instalar un cliente SCADA completo en cada estación de trabajo, algunas organizaciones corren todos esos clientes en una sola máquina potente y dejan que los usuarios se conecten a su propia sesión en ella. Esa máquina es el servidor de terminales, y el patrón - un host central que corre los escritorios o aplicaciones completos de muchos usuarios - es una manera de larga data de centralizar el software cliente del SCADA. Esta guía explica el modelo de servidor de terminales, o host de sesión de escritorio remoto: cómo un cliente SCADA completo corre en el host central mientras los usuarios reciben apps o escritorios publicados, por qué esto centraliza el parcheo y el licenciamiento, y dónde muerden sus compromisos, desde la densidad de sesiones hasta ser un punto único de falla.
Servidor de terminales para SCADA en una línea: Un servidor de terminales para SCADA es un host central de sesiones - a menudo un host de sesión de escritorio remoto o un host Citrix - que corre software cliente SCADA completo y da a múltiples usuarios su propia sesión en él, entregada como escritorio publicado o aplicación publicada. En lugar de instalar y mantener el cliente SCADA en cada estación de trabajo, el cliente vive una sola vez en el host de sesiones, lo que centraliza el parcheo y la gestión de licencias pero concentra la carga y el riesgo en ese host.
El patrón de host de sesiones
Un servidor de terminales voltea de cabeza el modelo usual de instalación del cliente. Normalmente cada estación de trabajo tiene el cliente SCADA instalado localmente y se conecta al servidor SCADA; con un servidor de terminales, el cliente SCADA se instala una sola vez en el host de sesiones, y cada usuario obtiene su propia sesión independiente en ese host en la que corre el cliente. El dispositivo del propio usuario se vuelve poco más que una ventana hacia su sesión, enviando entrada de teclado y ratón y recibiendo la pantalla, mientras que la ejecución real del cliente ocurre de forma central. Muchos usuarios comparten el único host, cada uno aislado en su propia sesión, todos corriendo el mismo software cliente instalado.
Lo que el usuario recibe puede ser un escritorio publicado completo - todo el entorno de sesión presentado como si fuera su propia máquina - o una aplicación publicada, donde solo se entrega la ventana del cliente SCADA y el escritorio circundante permanece oculto. Publicar solo la aplicación suele ser más limpio para los operadores, ya que presenta el cliente SCADA solo sin exponer el sistema operativo subyacente, mientras que un escritorio completo conviene a usuarios que necesitan más que la sola aplicación. En cualquier caso la entrega depende de un protocolo de sesión remota que lleva la pantalla y la entrada entre el dispositivo del usuario y su sesión en el host.
Este es el back-end clásico para despliegues de cliente ligero, donde dispositivos de usuario deliberadamente mínimos dependen de un host central para hacer el trabajo real. El host de sesiones provee el cómputo, la memoria y el software instalado para cada usuario a la vez, y por eso debe dimensionarse para el agregado de todas las sesiones concurrentes en lugar de para un solo cliente. Entender que el host carga el peso combinado de todos los conectados es la clave para entender tanto su atractivo como sus límites.
Por qué centraliza el parcheo y el licenciamiento
El argumento más fuerte a favor de un servidor de terminales es que colapsa muchas instalaciones de cliente en una. Parchar el cliente SCADA, actualizar su configuración o aplicar una corrección del sistema operativo ocurre una sola vez en el host de sesiones e inmediatamente beneficia a cada usuario, en lugar de repetirse en docenas de estaciones de trabajo dispersas que cada una hay que visitar, actualizar y verificar. Para un equipo responsable de mantener los clientes al día y consistentes, mantener un host cuidadosamente administrado es mucho menos trabajo y mucho menos propenso a errores que perseguir el mismo cambio por una flota de máquinas individuales.
El licenciamiento puede ser más simple de la misma manera, porque el software cliente se instala en un solo lugar y la cantidad de sesiones concurrentes en el host está naturalmente acotada y es visible. Administrar los derechos contra un solo host con una capacidad de sesiones conocida es más contenido que rastrear instalaciones repartidas por muchos extremos, y el punto central facilita ver y controlar cuántos clientes están corriendo en realidad. Esta pulcritud es un beneficio operativo real incluso antes de considerar el esfuerzo de mantenimiento reducido.
La consistencia es la ventaja más silenciosa que se sigue de la centralización. Como cada usuario corre el mismo cliente instalado en el mismo host, todos ven la misma versión comportándose de la misma manera, sin la deriva que se cuela cuando las máquinas individuales se quedan atrás en actualizaciones o acumulan peculiaridades locales. Esa uniformidad reduce las sorpresas que vienen de un cliente comportándose distinto en la estación de un operador que en la de otro, y hace más simple el soporte porque hay en efecto un solo entorno sobre el cual razonar en lugar de muchos.
Compromisos: densidad, punto único de falla y doble conteo de licencias
El primer compromiso es la densidad de sesiones y la carga que impone al host. Como el cliente de cada usuario corre en la única máquina, el host debe tener suficiente CPU, memoria y capacidad para cargar todas las sesiones concurrentes a la vez, y a medida que más usuarios se conectan, cada uno compite por los recursos compartidos. Empuje la densidad demasiado alto y la sesión de todos se ralentiza junta, así que el host tiene que dimensionarse con generosidad para el pico ocupado, y hay un techo de cuántas sesiones puede servir cómodamente un solo host antes de que el desempeño se degrade para todas.
El segundo compromiso es que el host de sesiones se vuelve un punto único de falla concentrado. Cuando el cliente SCADA de cada usuario corre en una máquina, perder esa máquina saca a todos de sesión de golpe - no un operador inconveniente, sino toda la población que depende del host cortada de sus pantallas simultáneamente. Esta concentración es la imagen espejo del beneficio de centralización: el mismo punto único que facilita el parcheo y el licenciamiento también hace inusualmente costoso un corte de ese punto, lo que empuja a los despliegues serios hacia la redundancia entre múltiples hosts, agregando de vuelta algo de la complejidad que un solo host pretendía evitar.
El tercer compromiso es un matiz de licenciamiento más sutil: el doble conteo. Correr clientes SCADA en un servidor de terminales puede requerir licencias para la propia infraestructura de host de sesiones - la tecnología de acceso remoto que entrega las sesiones - además de las licencias del cliente SCADA para los usuarios, así que el mismo acceso puede contarse en dos esquemas de licenciamiento a la vez. Aquí es donde un servidor de terminales contrasta con un cliente ligero HTML5 que no necesita capa de host de sesiones, y es por lo que la aparente simplicidad de centralizar clientes tiene que sopesarse contra el licenciamiento extra que el enfoque de host de sesiones puede introducir. El servidor de terminales es un patrón maduro y capaz, pero estos tres compromisos - densidad, concentración de falla y licenciamiento en capas - definen dónde encaja y dónde un cliente nativo de navegador puede servir mejor.
Preguntas frecuentes
¿En qué se distingue un servidor de terminales de una puerta de enlace de escritorio remoto?
Un servidor de terminales, o host de sesiones, es donde ocurre el trabajo: corre el cliente SCADA completo y aloja la sesión de cada usuario. Una puerta de enlace de escritorio remoto es el borde de acceso que corredura de forma segura una conexión a ese host desde afuera, manejando el punto de entrada en lugar de correr la aplicación. La puerta de enlace le permite alcanzar el host de sesiones con seguridad, pero es el host de sesiones mismo el que en realidad corre los clientes SCADA para todos los conectados.
¿Por qué correr SCADA en un servidor de terminales a veces necesita doble licenciamiento?
Porque dos capas de licenciamiento separadas pueden aplicar a la vez. Puede necesitar licencias para el software cliente SCADA que cada usuario corre, y por separado para la infraestructura de sesión remota - la tecnología de servidor de terminales o aplicación publicada - que entrega esas sesiones. El mismo acceso de usuario se cuenta entonces en dos esquemas. Esto contrasta con un cliente ligero HTML5 nativo de navegador, que no necesita capa de host de sesiones, y es un costo que sopesar contra los beneficios de centralización del enfoque de host de sesiones.
¿Cuál es el riesgo principal de usar un solo servidor de terminales para SCADA?
Concentra el cliente de cada usuario en una sola máquina, haciendo de ese host un punto único de falla. Si se cae, todos los que dependen de él pierden sus pantallas SCADA a la vez, no solo un operador. También tiene un techo de densidad de sesiones, ya que todas las sesiones concurrentes comparten la CPU y la memoria del host. Los despliegues serios abordan el riesgo de falla corriendo múltiples hosts redundantes, lo que restaura la resiliencia a costa de algo de la simplicidad que un solo host ofrecía.
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.