Guía de Arquitectura y Tamaño de Ignition Server
Esta guía está destinada a proporcionar algunos consejos que le ayudarán a determinar la arquitectura correcta según sus requisitos
Tabla de contenidos
1. Introducción | 5. Arquitectura escalable |
Introducción
Ignition es un conjunto de herramientas de desarrollo, con licencias ilimitadas y diferentes módulos, que le brinda las herramientas para crear soluciones. Un proyecto de Ignition puede ser tan pequeño como un recopilador de datos para unas pocas etiquetas o tan grande como una solución empresarial con cientos de dispositivos, cientos de miles de etiquetas y cientos de clientes de visualización. Es extremadamente importante encontrar la arquitectura y los tamaños de servidores adecuados para su proyecto de Ignition, de modo que el proyecto funcione según lo previsto y tenga espacio para crecer en el futuro.
Esta guía está destinada a proporcionar algunos consejos que le ayudarán a determinar la arquitectura correcta según sus requisitos. Es importante tener en cuenta que cualquier arquitectura que se le ocurra debe ser probada y verificada por completo. A lo largo de ese proceso, puede observar las características de rendimiento del servidor para realizar los ajustes necesarios en la arquitectura. No hay garantía de rendimiento, ya que se basa en sus elecciones de diseño.
El rendimiento y el tamaño de Ignition se basan en varios factores diferentes:
• Número de conexiones de dispositivos
• Tipos de PLC (Controlador)
• Número de etiquetas
• Frecuencia de sondeo de etiquetas (1 segundo, 5 segundos, 1 minuto, etc.)
• Número de cambios de valor de etiqueta por segundo (% de cambio)
• Número de clientes de visualización simultáneos
• Rendimiento de la base de datos SQL (Historiador, diario de alarmas, etc.)
• Implementación (Máquina física, VM, etc.)
• Latencia de conexión
• Y más...
Las funciones que utiliza en Ignition también juegan un papel importante en el rendimiento. Las funciones, como las siguientes, requieren tiempo de procesamiento y memoria:
• Comunicación del dispositivo
• OPC-UA (cliente y servidor)
• Etiquetas (OPC, expresión, consulta SQL, etc.)
• Historiador (almacenamiento y recuperación)
• Alarmante (estado, diario, canalizaciones de notificación)
• Grupos de transacciones (especialmente grandes cantidades)
• Informes PDF programados
• Gráficos de funciones secuenciales
• Scripting
○ Scripts de cambio de etiqueta
○ Scripts que se ejecutan en el servidor (temporizador, controladores de mensajes, etc.)
• Clientes de visualización
○ Número de suscripciones a etiquetas en una pantalla
○ Consultas de sondeo (historial de etiquetas, alarmas, consultas personalizadas, etc.)
○ Número de solicitudes de puerta de enlace
• Red de puerta de enlace (servicios remotos, EAM)
• Funcionalidad MES
• MQTT o inyección en la nube
• Y más...
Ignition tiene muchos subprocesos múltiples y puede manejar configuraciones con todas las características anteriores en límites razonables. Algunas de las funciones anteriores, como la comunicación del dispositivo y las etiquetas, tienen un rendimiento predecible. Otras características, como los clientes de visualización, tienen un rendimiento menos predecible, ya que se basan en cómo el usuario interactúa con el sistema y cómo está configurado el proyecto. Por ejemplo, podemos permitir que un usuario extraiga un año de datos históricos sobre una tendencia y lo sondee a una velocidad de un segundo. Podemos pasar horas o días sin que nadie use esa pantalla, pero luego podríamos tener una situación en la que 10 personas la estén usando al mismo tiempo, lo que provocará un aumento de la carga en el servidor. En la mayoría de los casos, un solo servidor es suficiente para manejar todo. Sin embargo, cuando los proyectos crecen o cuando superamos los límites de Ignition, necesitamos utilizar varios servidores. Afortunadamente, Ignition es modular y tiene la capacidad de escalarse separando diferentes módulos y funciones en servidores dedicados. Al final del día, esos servidores separados funcionan como una unidad de encendido y son completamente transparentes para el usuario, gracias a la red de puerta de enlace de Ignition y estándares como OPC-UA, SQL, MQTT y más.
El propósito de esta guía es guiarlo a través de proyectos de diferentes tamaños para comprender sus requisitos de hardware y arquitectura. Dado que Ignition tiene muchas características diferentes, esta guía se centrará en la cantidad de dispositivos, etiquetas y clientes.
Base de datos SQL
La base de datos SQL (MySQL, Microsoft SQL Server, etc.) en todos estos escenarios a continuación debe estar en su propio servidor dedicado. Si desea ponerlo en el mismo servidor que Ignition, necesitará más capacidad de procesamiento y memoria. A continuación, se muestran algunos consejos básicos sobre el tamaño de la base de datos:
- Historian Pequeño
2 núcleos (2 GHz +), 2 GB de memoria, SSD
0-100 cambios de valor por segundo
Requiere aproximadamente 300 GB de espacio en disco / año si el 100% de los valores cambian cada segundo sostenido (aproximadamente 6 GB con un 2% de cambio, más pequeño con velocidades más lentas)
2 núcleos (2 GHz +), 4 GB de memoria, SSD
100 - 500 cambios de valor por segundo
Requiere aproximadamente 3 TB de espacio en disco / año si el 100% de los valores cambian cada segundo sostenido (aproximadamente 60 GB con un 2% de cambio, más pequeño con velocidades más lentas)
- Historian Mediano
500 - 2500 cambios de valor por segundo
Requiere aproximadamente 7 TB de espacio en disco / año si el 100% de los valores cambian cada segundo sostenido (aproximadamente 150 GB con un 2% de cambio, más pequeño con velocidades más lentas)
4 núcleos (4 GHz +), 16 GB de memoria, SSD
2500 - 5000 cambios de valor por segundo
Requiere aproximadamente 15 TB de espacio en disco / año si el 100% de los valores cambian cada segundo sostenido (aproximadamente 300 GB con un 2% de cambio, más pequeño con velocidades más lentas)
- Historian Grande
8 núcleos (4 GHz +), 16 GB de memoria, SSD
5,000 - 10,000 cambios de valor por segundo
Requiere aproximadamente 30 TB / año si el 100% de los valores cambian cada segundo sostenido (aproximadamente 60 GB con un cambio del 2%, más pequeño con velocidades más lentas)
Nota: Algunas bases de datos en un servidor correctamente ajustado pueden alcanzar un máximo de 10,000 cambios de valor por segundo. Por ejemplo, MySQL maximizará el rendimiento del servidor a 10,000 cambios de valor por segundo, por lo que es aconsejable mantenerse dentro de 5,000. Microsoft SQL Server puede manejar hasta 20.000-30.000 cambios de valor por segundo con la última versión. Sin embargo, el rendimiento y la velocidad de las consultas dependen de la configuración del hardware y la base de datos. La velocidad de recuperación de datos en Ignition también puede verse afectada con un mayor rendimiento de almacenamiento. Puede lograr un mayor rendimiento instalando otra instancia de Ignition en el mismo servidor que la base de datos y utilizando la función de historial de etiquetas remotas de Ignition a través de la red de puerta de enlace. Esto evitará el envío de una gran cantidad de datos sin procesar (inserciones SQL) a través de la red y, en cambio, enviará datos comprimidos a través de la red, lo que finalmente dará como resultado las mismas inserciones pero ejecutadas localmente.
Memoria Ignition
La cantidad de memoria que Ignition ha asignado en el archivo de configuración ignition.conf de Ignition se puede ajustar. Debe establecer la cantidad adecuada de memoria para cada uno de los escenarios siguientes. Por lo general, puede dejar 1-2 GB de memoria para el sistema operativo (SO) y usar el resto para Ignition. Consulte nuestra documentación para obtener más detalles sobre cómo configurar la memoria de Ignition.
Arquitectura estándar (Servidor único)
La arquitectura más común de Ignition consiste en un único servidor Ignition en las instalaciones conectado a una base de datos SQL, PLC y clientes. En este caso, todas las funciones se configuran en el mismo servidor de Ignition. Las licencias de Ignition son ilimitadas. Sin embargo, Ignition está limitado por el tamaño del hardware. Con hardware más grande, Ignition puede manejar más conexiones de dispositivos, etiquetas y clientes.
- Proyecto de Ignition Pequeño
Perfecto para Edge Panel, Edge IIoT, HMI, SCADA pequeño, recopilación de datos, alarmante.
BRAZO, 1 GB de memoria, SSD
1-2 dispositivos
500 etiquetas
2 clientes concurrentes
2 núcleos (2 GHz +), 2 GB de memoria, SSD
1-10 dispositivos
2500 etiquetas
5 clientes concurrentes
2 núcleos (3 GHz +), 4 GB de memoria, SSD
1-10 dispositivos
5000 etiquetas
10 clientes concurrentes
- Proyecto de Ignition Mediano
Sistemas SCADA completos medianos o sistemas MES.
4 núcleos (3 GHz +), 4 GB de memoria, SSD
1-25 dispositivos
10,000 etiquetas
20 clientes concurrentes
4 núcleos (4 GHz +), 8 GB de memoria, SSD
1-50 dispositivos
25.000 etiquetas (40% de cambios en el historial de etiquetas como máximo)
25 clientes concurrentes
4 núcleos (4 GHz +), 16 GB de memoria, SSD
1-100 dispositivos
50.000 etiquetas (20% de cambios en el historial de etiquetas como máximo)
50 clientes concurrentes
- Proyecto de Ignition Grande
Grandes sistemas SCADA completos o sistemas MES.
8 núcleos (4 GHz +), 8 GB de memoria, SSD
1-100 dispositivos
75.000 etiquetas (10% de cambios en el historial de etiquetas como máximo)
50 clientes concurrentes
8 núcleos (4 GHz +), 16 GB de memoria, SSD
1-100 dispositivos
100,000 etiquetas (10% de cambios en el historial de etiquetas como máximo)
75 clientes concurrentes
16 núcleos (4 GHz +), 32 GB de memoria, SSD
1-100 dispositivos
150.000 etiquetas (6% de cambios en el historial de etiquetas como máximo)
100 clientes concurrentes
Los resultados pueden variar según las opciones de diseño. Los ejemplos se basan en el uso típico. Las tasas de sondeo más rápidas, los cambios de valor aumentados y la utilización de otras funciones de Ignition, como scripts, grupos de transacciones, SFC y más, pueden afectar significativamente el rendimiento general.
Arquitectura escalable
En sistemas más grandes, a menudo es más fácil tener varias instalaciones de Ignition para ayudar a dividir la carga entre las tareas de frontend y las tareas de backend. Esto es perfecto para sistemas grandes individuales que no están divididos en diferentes sitios. En los casos en que los sistemas se dividen en diferentes sitios, la arquitectura Hub and Spoke suele ser la mejor opción.
En la arquitectura de escalabilidad horizontal, tiene al menos una puerta de enlace que maneja las comunicaciones de back-end. La puerta de enlace backend se ocupa de todas las comunicaciones de dispositivos y PLC. La puerta de enlace de frontend maneja todos los clientes, sirviendo los datos extraídos de la puerta de enlace de backend. Esto es posible a través de la red de puerta de enlace, que conecta las puertas de enlace entre sí y permite que las etiquetas se compartan a través de proveedores de etiquetas remotas.
- Red de puerta de enlace
La red de puerta de enlace le permite conectar varias puertas de enlace juntas en una red de área amplia y abre muchas funciones distribuidas entre las puertas de enlace.
La red de puerta de enlace ofrece las siguientes características:
• Un canal de datos HTTP dedicado que puede manejar múltiples flujos de datos de mensajes.
• La capacidad de configurar un nodo para que actúe como proxy de otro nodo.
• Configuraciones de seguridad que restringen las conexiones entrantes basadas en una lista blanca o en la aprobación manual de la conexión. Las conexiones entrantes también se pueden desactivar por completo.
• Un modo SSL disponible. Cuando está habilitado, las conexiones deben enviar certificados SSL para probar su identidad. No se aceptará una conexión hasta que se apruebe su certificado SSL.
• Opcionalmente, los certificados de cliente se pueden configurar para que sean necesarios, así como los certificados de servidor.
Características de la red de puerta de enlace
La red de puerta de enlace abre ciertos servicios para su uso que facilitan la administración de múltiples puertas de enlace y la comunicación efectiva con cada una de las puertas de enlace. También tiene una seguridad especial que puede restringir que ciertos servicios sucedan en ciertas zonas de la red de puerta de enlace.
Administración de empresas
El módulo de administración empresarial (EAM) utiliza la red de puerta de enlace para la transferencia de mensajes y archivos y puede supervisar la disponibilidad de las conexiones de red. El EAM informa cada vez que se pierden las comunicaciones a través de eventos de alarma y etiquetas del sistema.
Servicios distribuidos
Los servicios distribuidos incluyeron lo siguiente:
• Proveedores de etiquetas remotas en tiempo real: Brindan la capacidad de leer / escribir etiquetas desde un servidor Ignition remoto. Perfecto para servidores frontend que necesitan ver las etiquetas en el backend. Esto incluye leer y escribir en etiquetas, ver alarmas e incluso consultar datos históricos.
• Proveedores de etiquetas históricas remotas: Brinda la capacidad de enviar datos históricos a otro servidor Ignition para su almacenamiento en una base de datos SQL. También proporciona la capacidad de consultar datos históricos de forma remota cuando no hay una conexión a la base de datos SQL disponible.
• Alarma remota: Brinda la capacidad de enviar notificaciones de alarma a otro servidor de Ignition. Perfecto cuando el correo electrónico, la voz o los SMS solo están disponibles en un servidor de Ignition central.
• Diario de alarmas remoto: Proporciona la capacidad de enviar el historial de alarmas a otro servidor de Ignition para su almacenamiento en una base de datos SQL.
• Registros de auditoría remotos: Proporciona la capacidad de enviar registros de auditoría a otro servidor de Ignition para su almacenamiento en una base de datos SQL.
Zonas de seguridad y seguridad del servicio
Las zonas de seguridad se pueden configurar para bloquear o evitar el acceso a determinadas partes de las puertas de enlace dentro de la red de puertas de enlace. Puede configurar la seguridad del nivel de servicio en cada sistema para definir lo que se permite desde los servidores de Ignition remotos.
- Una E/S / Una Interfaz
Con esta arquitectura, tiene un servidor Ignition que se comunica con los PLC y realiza tareas de back-end, como sondear valores en vivo, historiador y alarmas. El servidor backend es responsable de registrar datos en la base de datos SQL. El servidor frontend maneja todos los clientes de visualización (Visión y Perspectiva) y también debe comunicarse con la base de datos SQL para consultar datos históricos.
Con esta arquitectura, puede manejar más conexiones de dispositivos, etiquetas y clientes ya que tiene dos servidores. Puede expandirse fácilmente a múltiples servidores de E / S y servidores frontend a medida que aumenta el tamaño del proyecto, lo que permite una fácil escalabilidad.
- Un Servidor OPC-UA / Una E/S / Una Interfaz
Con esta arquitectura, se introdujo un servidor OPC-UA dedicado que maneja toda la comunicación del PLC. Básicamente, está separando OPC-UA de un solo servidor. Esta arquitectura permite manejar un conjunto más grande de dispositivos. El servidor de E / S simplemente maneja los cambios del valor de la etiqueta. Puede manejar fácilmente un conjunto más grande de etiquetas, en lo que respecta al historial y las alarmas, con servidores OPC-UA adicionales para diferentes conjuntos de PLC.
- Dos E/S / Una Interfaz
Con esta arquitectura, tiene dos servidores Ignition que se comunican con diferentes conjuntos de PLC, lo que permite la comunicación con un conjunto más grande de dispositivos y etiquetas. Por ejemplo, es posible manejar aproximadamente 250.000 etiquetas de 200 dispositivos. Puede agregar fácilmente servidores de E / S adicionales según sea necesario.
Prácticas recomendadas para proveedores de etiquetas
Con la arquitectura de escalamiento horizontal, es importante proporcionar nombres adecuados a sus proveedores de etiquetas y los nombres deben ser consistentes en todas las E / S y la interfaz. Debe evitar usar el proveedor predeterminado que viene en una instalación estándar. Es común crear un nuevo proveedor de etiquetas en tiempo real en el servidor de E / S con un nombre que describa ese servidor de E / S y se distinga de otros servidores de E / S. En el servidor frontend, debe crear un proveedor de etiquetas remotas con el mismo nombre que el servidor de E / S para que los dos sean coherentes.
Rutas de etiquetasSe recomienda utilizar rutas de etiquetas totalmente calificadas en sus proyectos, especialmente con plantillas y pantallas de visualización. Una ruta totalmente calificada permite a Ignition saber exactamente dónde está la etiqueta, incluido el nombre del proveedor de la etiqueta.
Por ejemplo, una ruta de etiqueta no totalmente calificada tiene el siguiente aspecto:
Ruta / a / mi / etiqueta
Con esa ruta, no sabe de qué proveedor de etiquetas proviene. Un proyecto de Ignition utilizará el proveedor de etiquetas predeterminado del proyecto, que es solo un proveedor.
Una ruta de etiqueta completamente calificada tiene el siguiente aspecto:
[NombreProveedorEtiquetas] Ruta / a / mi / etiqueta
Observe que la ruta incluye el proveedor de etiquetas. Puede proporcionar fácilmente un parámetro en una plantilla de visualización que puede cambiar el proveedor de la etiqueta y la ruta de la etiqueta, lo que nos permite apuntar a cualquier etiqueta de cualquier proveedor.
- Escalado horizontal completo con equilibrador de carga
Lo mejor de la arquitectura Scale-Out es que es fácil escalar Ignition a medida que crece su sistema. En la imagen de arriba, se agregaron más puertas de enlace frontend para ayudar a manejar un aumento de clientes y un equilibrador de carga para distribuir automáticamente los clientes entre ellos. Al utilizar un equilibrador de carga, es importante activar las sesiones "pegajosas" para garantizar que la conexión se mantenga constante durante al menos una hora. El servidor frontend tiene que ser completamente sin estado. Obtiene sus datos de los servidores de E / S y de la base de datos SQL. Al utilizar esta arquitectura con una cantidad adecuada de servidores frontend, puede manejar miles de clientes simultáneos junto con una gran cantidad de dispositivos y etiquetas.
Ejemplos de equilibradores de carga:
• Equilibrador de carga F5
• HAProxy
• AWS / Azure LB
Los cambios de valor son clave
Cuando se trata de etiquetas, los cambios de valor son la métrica más importante a tener en cuenta. Esto se define como un cambio en el valor que es mayor que la banda muerta configurada. Las bandas muertas pueden ser absolutas o basadas en porcentajes. Por ejemplo, tiene un valor analógico con una banda muerta de 0,1. Un cambio de 7.89 a 7.88 no se consideraría un cambio. Sin embargo, un cambio de 7,89 a 7,9 se consideraría un cambio. Por lo general, cualquier cambio con valores discretos se considera un cambio, ya que se trata de un estado. Las bandas muertas se pueden configurar por etiqueta.
La razón por la que los cambios de valor son clave se debe al hecho de que tenemos que procesar el cambio de valor, para las alarmas, el historiador y más. Ese procesamiento requiere memoria y tiempo de cálculo. Cuantas más etiquetas cambiemos por segundo, más procesamiento. Un servidor de Ignition en el extremo superior puede manejar aproximadamente 50,000 cambios de valor por segundo procesando a través del sistema de etiquetas, alarmante, historiador y clientes. Sin embargo, como se mencionó anteriormente, algunas bases de datos SQL tienen un límite de 10,000 cambios de valor por segundo en una instancia dedicada. Entonces, su trabajo es tratar de reducir el número de cambios de valor por segundo. Ignition puede manejar más dispositivos, etiquetas y clientes mediante la optimización y la reducción de cambios de valor.
Veamos algunos escenarios diferentes que ayudan a comprender lo que puede manejar un servidor. Cada escenario representa una serie de etiquetas que maximizan el rendimiento en un servidor.
• 10,000 etiquetas a una velocidad de 1 segundo con 100% de cambio = 10,000 valores / seg.
• 50.000 etiquetas a una velocidad de 5 segundos con un cambio del 100% = 10.000 valores / seg.
• 100.000 etiquetas a una velocidad de 1 segundo con un 10% de cambio = 10.000 valores / seg.
• 500.000 etiquetas a una velocidad de 5 segundos con un 10% de cambio = 10.000 valores / seg.
• 500 dispositivos con 100 etiquetas cada uno = 50.000 etiquetas a una velocidad de 5 segundos con un cambio del 100% = 10.000 valores / seg.
Como puede ver, se pueden manejar más etiquetas optimizando las tasas de encuesta y las bandas muertas. Es posible tener un gran número de conexiones y etiquetas de dispositivos mediante la optimización.
Optimizaciones
Realmente puede optimizar su sistema prestando mucha atención a la cantidad de cambios de valor que ocurren cada segundo. Cuanto más sintonice el sistema, más podrá manejar y mejor rendimiento obtendrá. A continuación, se incluyen algunas cosas a considerar:
- Tasas de sondeo
Los grupos de etiquetas (o clases de escaneo) dictan la frecuencia con la que Ignition sondea los datos de los PLC. Asegúrese de utilizar las tasas de votación adecuadas. No todo tiene que ser a una velocidad de 1 segundo. Algunos valores se pueden sondear más lentamente que otros, ya que no cambian con mucha frecuencia. Intente determinar todas las posibles tasas de sondeo que necesita. Por ejemplo, es posible que necesite un conjunto de etiquetas a una velocidad de 1 segundo para alarmas o historial, mientras que el resto de las etiquetas se pueden sondear en intervalos de 5 segundos o minutos.
- Bandas muertas
Las bandas muertas registran menos puntos de datos, especialmente cuando los cambios de valor son demasiado pequeños para ser significativos. Son especialmente útiles en un proceso que inspecciona con una frecuencia alta, pero que está más interesado en capturar cambios de valor que exceden una magnitud o porcentaje definido. Las bandas muertas pueden ser absolutas o basadas en porcentajes. Absoluto se basa en un cambio absoluto en el valor, mientras que las bandas muertas porcentuales significan que el valor tiene que cambiar en un porcentaje particular. También hay dos modos de banda muerta: digital y analógico. La banda muerta digital se almacena cuando un nuevo valor es +/- el valor de la banda muerta lejos del valor almacenado previamente. Los valores del modo analógico se evalúan con un algoritmo de "ventana deslizante" modificado que intenta registrar la menor cantidad de puntos necesarios para dibujar el gráfico correctamente.
Hay bandas muertas en las etiquetas tanto para tiempo real como histórico. Las bandas muertas en tiempo real significan que Ignition no procesará el nuevo valor en absoluto a menos que cambie de acuerdo con la configuración. Las bandas muertas históricas se aplican después y dictan cuándo se registrará un valor en el historiador. Eso permite ver datos más granulares en pantallas en tiempo real pero registrar menos puntos.
Sin bandas muertas adecuadas, los sistemas registrarán "ruido" en las señales analógicas. Nunca tiene sentido tener más sensibilidad para el registro que la precisión nominal de un sensor.
Cuanto mejor ajuste sus bandas muertas, menos cambios de valor tendrá en el sistema. Puede evitar la fluctuación de los valores analógicos y el costoso almacenamiento del historial.
- Grupos de etiquetas alquilados y controlados
Los grupos de etiquetas le dicen a Ignition con qué frecuencia leer (sondear) el PLC. Los grupos de etiquetas dictan la ejecución de etiquetas, lo cual es especialmente importante para sistemas grandes y de alto rendimiento. Se recomienda que organice los grupos de etiquetas mediante estrategias de sondeo. Para cualquier etiqueta dada, es común usar un grupo de etiquetas rápido para el estado y control, y un grupo de etiquetas más lento para el historial.
Los grupos de etiquetas controlados son una excelente opción para el historial donde se requiere condicionalmente un registro más rápido. Los grupos de etiquetas no establecen su tasa histórica de registro, pero influyen en la frecuencia con la que Ignition verá el cambio de datos.
Los grupos de etiquetas alquilados son una excelente opción cuando solo desea sondear etiquetas cuando es necesario en una pantalla. Hay muchos valores en los PLC que no se usan para el historial o alarmas, solo para verlos en una pantalla. No necesitamos sondear esos valores todo el tiempo.
Es importante tener en cuenta que los grupos de etiquetas alquilados y controlados tienen un impacto cuando se utilizan los controladores y el servidor OPC-UA de Ignition, ya que las suscripciones cambian con bastante frecuencia. Un cambio en la suscripción requiere que el controlador de dispositivo de Ignition se vuelva a optimizar por conexión de dispositivo, que vuelve a leer cada etiqueta configurada en esa conexión en el momento en que cualquier etiqueta alquilada o impulsada cambia entre las velocidades rápida y lenta. Debido a esto, al usar el servidor OPC-UA de Ignition y los controladores con grupos de etiquetas arrendados o controlados, se recomienda crear dos conexiones de dispositivo al PLC si está permitido. Una conexión para los grupos de etiquetas directas y una conexión para los grupos de etiquetas arrendados y controlados. De esa manera, los cambios de suscripción de grupos de etiquetas alquilados e impulsados no tienen un efecto en los grupos de etiquetas directas y evitan costosas reoptimizaciones y superposiciones obsoletas.
- Evento conducido
Es extremadamente importante ejecutar solo la lógica en el cambio, especialmente con expresiones y consultas SQL. Esto evitará cálculos adicionales cuando los valores no hayan cambiado. Ignition 8.0+ introdujo nuevos modos de ejecución en las etiquetas, de los cuales se destaca "Event-Driven". El control por eventos solo activa la expresión o la consulta SQL cuando cambia una dependencia (es decir, un evento de valor de etiqueta o un evento de alarma) en lugar de ejecutarse a una velocidad específica todo el tiempo. Imagine tener una etiqueta de expresión en un UDT que realiza una instrucción de cambio en un valor entero para proporcionar un estado legible por humanos. El estado no cambia muy a menudo. Supongamos que tiene 2000 instancias de UDT que dan como resultado 2000 expresiones. La función impulsada por eventos solo activará la expresión cuando el estado cambie, lo cual es muy poco frecuente. Alternativamente, las tasas fijas podrían disparar 2000 expresiones por segundo, lo que podría ser una gran cantidad de cálculos innecesarios.
Se recomienda utilizar expresiones controladas por eventos, etiquetas derivadas y etiquetas de consulta SQL. También se recomienda configurar el modo de historial de una etiqueta en "Al cambiar".
- Scripts
Puede escribir scripts en varios lugares dentro de Ignition. Es muy importante comprender dónde y cuándo se ejecutan esos scripts. Evite las expresiones runScript a menos que sea absolutamente necesario. Evite muchos scripts de temporizador en el Gateway o en el cliente. Evite muchos scripts de cambio de etiqueta. En última instancia, intente reducir la cantidad de scripts que tiene tanto en el servidor como en los clientes. Puede ver la página de estado de Gateway de Ignition para obtener más información sobre la ejecución de scripts y motores de ejecución. Las expresiones se ejecutan mucho más rápido que los scripts, por lo tanto, utilice expresiones en lugar de scripts siempre que sea posible. Utilice secuencias de comandos donde tenga sentido, ya que las secuencias de comandos son muy poderosas y útiles, pero tenga en cuenta la potencia de procesamiento que requieren las secuencias de comandos que escribe.
- Evite las consultas de sondeo y utilice el almacenamiento en caché
Es realmente fácil configurar consultas de sondeo al historiador, diario de alarmas, registros de auditoría o consultas SQL personalizadas en un cliente. Se recomienda evitar las consultas de sondeo, ya que colocan una carga adicional en el servidor Ignition, especialmente cuando hay muchos clientes abiertos. Por ejemplo, si tiene dos consultas de sondeo ejecutándose cada segundo en un cliente y 25 clientes abiertos, tendrá 50 consultas ejecutándose cada segundo. Intente reducir el número de consultas de sondeo o desactívelas por completo. Puede colocar fácilmente un botón de actualización en la interfaz de usuario (UI) que puede ejecutar la consulta a pedido. Tanto Vision como Perspective tienen una función fácil de usar para actualizar cualquier encuadernación.
Las consultas con nombre pueden optar por almacenar en caché los resultados en la puerta de enlace. Esto significa que si entra otra solicitud a la misma consulta con nombre, la puerta de enlace puede devolver el resultado almacenado en caché en lugar de que la base de datos vuelva a ejecutar la consulta. Esto usará más memoria en la puerta de enlace (para mantener los resultados) pero podría resultar en que se ejecuten menos consultas en la base de datos. Cuando sea necesario realizar un sondeo o si tiene muchos clientes abiertos, utilice consultas con nombre con almacenamiento en caché para proporcionar un mejor rendimiento.
- Detección de datos obsoletos de Tag Historian
Esta función de encendido, si está habilitada, rastrea las ejecuciones de grupos de etiquetas para determinar la diferencia entre los valores que no cambian y los valores que son planos debido a que el sistema no está funcionando. Esencialmente, rastrea cuando el sistema no está funcionando, comúnmente debido a problemas de desviación del reloj, y registra la hora en que el sistema no estaba funcionando. Esta función está activada de forma predeterminada. Aunque esto puede ser útil en ocasiones, muchos sistemas con esta función habilitada terminan con muchas filas en la tabla sqlth_sce en la base de datos, lo que provoca inadvertidamente problemas de rendimiento al consultar datos históricos. Los problemas de rendimiento se deben a que Ignition realiza más consultas SQL con un mayor número de filas en la tabla.
A menos que sea absolutamente necesario, recomendamos desactivar esta función y simplemente dejar que el sistema realice un seguimiento de los valores a medida que cambian. Si hay desviaciones del reloj o problemas del sistema, estos también deben tratarse y tratarse como problemas separados para resolver. Para desactivar la función, primero, desactive la configuración de detección de datos obsoletos para sus proveedores de historial en la página de configuración de Ignition Gateway en Etiquetas → Historial. Edite su proveedor y en Configuración avanzada deshabilite "Habilitar detección de datos obsoletos". A continuación, establezca el modo de historial en todas sus etiquetas históricas en "Al cambiar". Por último, verifique su base de datos SQL para ver si tiene una gran cantidad de filas en la tabla sqlth_sce con la siguiente consulta:
SELECT COUNT(*) FROM sqlth_sce
Si tiene cientos de filas o más, considere la posibilidad de consolidar las filas en una fila por clase de escaneo y tasa. Puede utilizar esta consulta para encontrar el número mínimo ideal de filas:
SELECT scid, MIN(start_time) start_time, MAX(end_time) end_time, rate FROM sqlth_sce GROUP BY scid, rate
- Tasa de encuesta de etiquetas de clientes de Vision
Los clientes de Vision y el diseñador de Ignition deben comunicarse con Ignition Gateway para obtener valores de etiqueta. Por supuesto, solo necesita obtener los datos que le interesa ver en la pantalla. En ese caso, los clientes de Vision y el diseñador crean una suscripción en las etiquetas que necesitan. Sin embargo, la puerta de enlace no puede notificar al cliente / diseñador cuando cambia una etiqueta, por lo que el cliente / diseñador debe sondear la puerta de enlace. La tasa de encuesta del cliente (en milisegundos) es la tasa a la que un cliente de Vision o un diseñador de Ignition sondea el Gateway en busca de actualizaciones de sus etiquetas suscritas. De forma predeterminada, la configuración está establecida en 250 ms. Eso significa que cada cliente y diseñador de Vision sondeará el Gateway cada 250 ms para ver si alguna de las etiquetas a las que están suscritos ha cambiado. Si nada ha cambiado, obtenemos un resultado vacío. La tasa es bastante rápida, pero no suele ser un problema. Sin embargo, si tiene una gran cantidad de clientes de Vision, puede causar una carga adicional en el servidor. Puede reducir fácilmente esta carga cambiando la configuración a 1 segundo. Por lo tanto, si tiene 100 clientes abiertos, recibirá 400 solicitudes por segundo para cambios de etiquetas de forma predeterminada. Si cambia la configuración a 1 segundo, obtendrá solo 100 por segundo. La configuración para esto está en el diseñador en Proyecto → Propiedades en el Proyecto → pestaña General.
- Optimizaciones de la red de puerta de enlace
La red de puerta de enlace es increíble, pero puede ser fácil enviar muchos datos sin querer. Es importante saber qué y cuántos datos pasan por la red. Ignition proporciona una página de diagnóstico en la sección de estado del Gateway para ver el tráfico entrante y saliente del servicio Gateway Network. Se recomienda optimizar la comunicación para garantizar el estado de la red de puerta de enlace.
Suscripción de alarma de proveedor de etiquetas remotas
El proveedor de etiquetas remotas tiene la capacidad de consultar alarmas a través de la red de puerta de enlace para su uso en el componente de estado de alarma. Puede desactivar las alarmas o establecer el modo en el que desea recuperar las alarmas. Se recomienda utilizar el modo "Suscrito" para una comunicación óptima. En 'suscrito', el estado se suscribirá y las actualizaciones se enviarán de forma asincrónica. Suscrito proporciona un mejor rendimiento pero utiliza más memoria. Esto es especialmente importante con muchas conexiones de red de puerta de enlace y un gran número de alarmas.
Modo de historial de proveedor de etiquetas remoto
El proveedor de etiquetas remotas tiene la capacidad de consultar el historial a través de la red de puerta de enlace. Se recomienda conectar una puerta de enlace frontend a la base de datos SQL directamente y utilizar rutas de etiquetas históricas para consultar los datos. Sin embargo, si está utilizando rutas de etiquetas en tiempo real para consultar el historial, se recomienda configurar el proveedor de etiquetas remotas para que utilice el modo "Base de datos" para acceder al historial. De esa manera, puede evitar tener que solicitar datos históricos al servidor de E / S. Por el contrario, puede cortocircuitar y consultar la base de datos directamente, lo que requiere una conexión directa a la base de datos SQL. Si una conexión a la base de datos SQL no está disponible, intente reducir la cantidad de consultas de historial y evite consultas costosas con grandes rangos de tiempo y datos.
Ejecución de Ignition en máquinas virtuales
- Resumen
Uno de los principales entornos de implementación de Ignition en la actualidad son las máquinas virtuales (VM). Un gran porcentaje de clientes empresariales utilizan Ignition en máquinas virtuales en lugar de servidores físicos nativos. Aunque las máquinas virtuales por diseño son más lentas que las que se ejecutan sin sistema operativo, siempre que se aplique correctamente la configuración correcta de la máquina virtual, Ignition debería funcionar bien en estos entornos.
- Software
Ignition se ejecutará en cualquier hipervisor que emule correctamente el hardware y un sistema operativo. Cuando Ignition se ejecuta en una máquina virtual, se usa más comúnmente en VMWare, principalmente debido a la ubicuidad de VMWare. Inductive Automation no recomienda VMWare por encima de otros hipervisores y, siempre que la asignación de recursos sea adecuada, no ha visto problemas específicos de hipervisor en ningún software de virtualización reciente.
- Asignación de recursos
La asignación de CPU y memoria debe ser determinada por los ingenieros que crean los proyectos de Ignition. Los sistemas pequeños pueden tener 4 CPU virtuales con 8 GB de RAM. Los sistemas muy grandes pueden tener 32 CPU virtuales o más con 64 GB de RAM.
Cuando Ignition ejecuta sistemas pequeños con solo un puñado de clientes y etiquetas, la asignación normal de recursos suele ser aceptable. Cuando se ejecutan aplicaciones críticas o se ejecuta cualquier tipo de carga significativa, se requieren recursos dedicados para que el sistema siga funcionando.
- Recursos dedicados
Cuando especifique por primera vez las necesidades de un Ignition Gateway, siempre mencione la necesidad de CPU virtuales y memoria dedicadas. Si un Ignition Gateway comienza con un tamaño pequeño, es posible que no sea necesario inicialmente, pero a medida que crezca, se requerirán recursos dedicados para evitar problemas. Si los recursos dedicados no se configuran inicialmente, es posible que más adelante se produzca un rechazo significativo por parte de los departamentos de TI que no estaban anticipando esta necesidad.
- Configuración específica de VMWare
En VMWare, esto se configura más comúnmente estableciendo Sensibilidad de latencia en Alta.
Después de configurar esto, verifique que la asignación de vCPU esté 100% dedicada a Ignition VM. Si no es así, significa que todo el VM Host está sobre aprovisionado y esto deberá solucionarse.
- Preguntas comunes
P: Mi uso de CPU no es demasiado alto. ¿Todavía necesito recursos dedicados?
R: Sí, es probable. A menos que esté ejecutando un sistema que no hace mucho, su Ignition Gateway probablemente esté manejando una gran cantidad de procesamiento de ráfagas. Esto significa que el tráfico llega a través de la red, los subprocesos se despiertan de forma asincrónica o que están sucediendo otras cosas en las que Ignition quiere utilizar instantáneamente los ciclos de la CPU. Sin recursos dedicados, esto puede tardar hasta 50-500 uS. Si ocurren 1000 operaciones como esta por segundo, lo cual no es irrazonable en un sistema de encendido muy cargado, la demora de activación podría ser de hasta un 5% -50% de una CPU virtual.
P: ¿Cómo sé si necesito recursos dedicados?
R: La automatización inductiva normalmente recomienda comenzar con recursos dedicados. Teniendo en cuenta lo importante que es Ignition para la mayoría de las empresas, el valor que aporta y la inversión en la compra, no tiene sentido tratar de reducir los recursos.
Si ya ha comenzado con los recursos compartidos, hay una señal principal de que los recursos dedicados se están volviendo necesarios.
Deriva del reloj. Esta es una métrica de Ignition en las páginas de estado y es una medida de cuándo el sistema operativo ejecuta una tarea programada. Ignition programa una tarea para que se ejecute en 1 s. En la mayoría de las circunstancias, esa tarea se ejecutará exactamente en 1000 ms. Si no es así, hay un problema con el sistema operativo obteniendo los ciclos de CPU que necesita para ejecutar esa tarea. Es un problema de asignación de CPU, un sistema muy cargado, otro software que afecta al sistema operativo o el hipervisor no proporciona recursos o suficientes recursos con la suficiente rapidez. Los recursos dedicados casi siempre eliminan el Clock Drift. Tenga en cuenta que tener muy pocas CPU virtuales asignadas también puede contribuir a Clock Drift.
Los retrasos en las tareas comunes, el procesamiento lento, los problemas del historial si la base de datos y los dispositivos no están sobrecargados, y otros comportamientos lentos pueden ser signos de que también se necesitan recursos dedicados.
P: Ya tengo recursos dedicados y he asignado una gran cantidad de vCPU, pero mi sistema Ignition todavía está sobrecargado. ¿Qué debo hacer?
R: En algún momento, un solo servidor Ignition alcanzará su límite, independientemente de las asignaciones de CPU y memoria. La arquitectura escalable de Inductive Automation es la recomendación general para ir más allá de los límites de un solo sistema.
Referencias
VMWare 5.5 Latency Sensitivity
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/latency-sensitive-perf-vsphere55-white-paper.pdf
VMWare 6.7 Latency Sensitivity
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/vsphere-esxi-vcenter-server-67-performance-best-practices.pdf
Publicado en español el 20 de Setiembre del 2021.
Originalmente publicado el 06 de Mayo del 2021.
Fuente original:
https://inductiveautomation.com/resources/article/ignition-server-sizing-and-architecture-guide