TN319AS - Funcionamiento de los componentes de System Platform sin licencia activa

TN319AS - Funcionamiento de los componentes de System Platform sin licencia activa

TN319WAS- Funcionamiento de los componentes de System Platform sin licencia activa

Este documento detalla como es el funcionamiento del Application Server sin licencias en las primeras horas en las que se pierde una licencia, o se desactiva por el motivo que sea. Se pretende indicar como funciona el software tras perder licencia, como afecta a las comunicaciones e historización, entre otros. 
Notes
El sistema está configurado para leer e historizar datos mediante el protocolo MBTCP (Modbus TCP/IP) de una simulación de una planta, estos datos se obtienen de un programa que simula un PLC que comunica mediante MODBUS.
InfoLa versión del software en las pruebas es la 2023P03, por lo que la interfaz o algún mensaje podría no ser exactamente igual en otras versiones.  La versión de Enterprise License Manager es la 3.7.002. 
Partiremos de un servidor licenciado con una licencia demo, por lo que desactivaremos esa licencia mientras se comunica e historizan datos del simulador, y veremos como reacciona el sistema en consecuencia, qué logs indican que tenemos o no licencias activas y como podemos determinar si tenemos comunicaciones e historizamos sin problema. 

En primer lugar, vamos a plantear el funcionamiento del sistema. Tenemos un simulador que comunica mediante el driver OI.MBTCP de AVEVA mediante objetos de la aplicación, estos datos se procesan por el software de AVEVA y posteriormente se pueden leer desde el OCMC (Operations Control Management Console) o desde otras herramientas que nos permitan conectar como cliente (QuickClient de KepServerEX, Object Viewer de AVEVA...)



En segundo lugar, procederemos con las pruebas de desactivación de la licencia, el objetivo que tenemos ahora es ver como reacciona el sistema.
Procedemos con la desactivación de la licencia, la desactivamos mediante el Enterprise License Manager y analizamos los logs del servidor y las comunicaciones, para revisar como ha reaccionado el sistema. 


Y confirmamos que no hay licencia actualmente:


Llegados a este punto, podemos plantear que las comunicaciones se han interrumpido, o que los drivers no lo permitan, pero nada más lejos de la realidad, los drivers seguirán funcionando durante un período de 24 horas, ya que el sistema se queda en modo de Grace Period, o período de gracia. Durante este período de 24 horas las comunicaciones  no se detendrán, podremos utilizar los distintos software de AVEVA e incluso la historización y las alarmas se generarán sin ningún problema. 

En el logger debemos habilitar una serie de "Flags" para poder analizar el comportamiento de la licencia, así como sus datos. Este menú para modificar los mensajes que aparecen en los logs se puede abrir desde la ventana de "Action" y posteriormente seleccionar la opción de "Log Flags". Debemos habilitar los flags para el componente GDILicensing.

                  

Una vez hemos eliminado la licencia (o esta ha llegado a la fecha de expiración) nos aparecerán una serie de mensajes en el logger que nos indicarán que efectivamente estamos dentro del período de gracia de la licencia. 
Info
Para ver los logs que mencionamos, antes debemos habilitar los flags, como se indica en los pasos anteriores.  



Este es el "Trigger" o accionador que lanza el período de gracia de las 24 h para los productos de AVEVA, pero como podemos comprobar nos permite comunicar, historizar y gestionar el IDE. 
Desde el momento en el que entremos en el período de gracias de 24 horas, aparecerán mensajes en los logs correspondientes a una cuenta atrás de este período, cuando este finaliza, el driver, ahora sí, dejará de funcionar.

El funcionamiento del sistema se puede monitorizar desde los logs del OCMC (SMC), cada 5 minutos el sistema hace una petición de la licencia, y el sistema la procesa haciendo sus comprobaciones para asegurar que el sistema está licenciado, de manera que los logs que nos indican que una licencia no ha sido adquirida en el servidor son los siguientes: 
Process ID
Thread ID
Log Flag 
Component 
Message
3500
3640
Trace
GDILicensingExe
Expiration set with grace (YYYY\MM\DD HH:MM:SS) - 2025\05\20 03:26:46
3500
3640
Warning
GDILicensingExe
License 24 hour grace period for expiration started.
3500
3640
Trace
GDILicensingExe
License state cached expiration, Prev=LICENSED, Curr=NOT_LICENSED, Actual=LICENSED
3500
3640
Trace
GDILicensingExe
License state exposed to clients for expiration "LICENSED", (YYYY\MM\DD HH:MM:SS) - 2025\05\20 03:26:46

  Estos logs nos indican que empieza el Grace Period de 24 horas que nos da el software para funcionar con normalidad, es decir, no nos corta inmediatamente las comunicaciones y permite un tiempo para intervenir. La fecha y hora que aparecen indican cuando se dejará de obtener este Grace Period, es decir, que nos quedaremos sin licencia ni grace period y el software dejará de funcionar con su comportamiento habitual. 

Y de igual manera se puede monitorizar los logs para saber que se ha activado una licencia correctamente, los logs que indican que una licencia ha sido adquirida con éxito son: 
Process IDThread IDLog Flag Component Message
3500
3640TraceGDILicensingExeGet expiration from license success (YYYY\MM\DD HH:MM:SS) - 2025\05\31 23:59:59
35003640WarningGDILicensingExeLicense 24 hour grace period for expiration canceled.
35003640TraceGDILicensingExeLicense state cached expiration, Prev=NOT_LICENSED, Curr=LICENSED, Actual=LICENSED, (YYYY\MM\DD HH:MM:SS) - 2025\05\31 23:59:59
35003640TraceGDILicensingExeLicense state exposed to clients for expiration "LICENSED", (YYYY\MM\DD HH:MM:SS) - 2025\05\31 23:59:59

   Estos logs nos indican que finaliza el Grace Period de 24 horas que nos da el software para funcionar con normalidad, de manera que en este punto tenemos una licencia activa y su fecha de caducidad aparece en los logs como se puede ver en la tabla anterior. 

1) Pruebas de comunicación sin licencia activa (en grace period de 24 horas)

Al trabajar sin licencia, podemos seguir comun
icándonos con los datos procedentes del PLC (en nuestro caso un simulador de Modbus TCP/IP). Podemos ver que el dispositivo sigue conectado sin licencia activa. Para asegurar el correcto funcionamiento debemos evitar reiniciar el servidor durante este período de gracia, además de evitar modificar los servicios encargados o que tengan relación con las licencias, para más información revisad la documentación de la guía de usuario del Enterprise License Manager.



También nos permite crear nuevas instancias de drivers y tópicos, para posteriormente ser utilizados pese a no tener licencia en ese momento, es decir, el sistema actua como si hubiera una licencia activa para los Communication Drivers durante estas 24 horas de gracia. 

2) Pruebas de historización de los datos sin licencia activa (en grace period de 24 horas)

En cuánto a los datos que se hayan habilitado para historización en base de datos, utilizando Historian, se seguirán tomando y guardando en la base de datos de SQL mientras no se reinicien los servicios o el servidor, de manera muy similar al caso de los drivers de comunicación visto en el párrafo anterior. 
En este punto tenemos un comportamiento distinto que en las comunicaciones, ya que no podremos utilizar los clientes de visualización de los datos de la forma habitual.
Primero nos centraremos en la historización de los datos, una vez desactivada la licencia del servidor, el sistema continúa historizando los datos mientras estemos dentro del período de gracia de 24 horas que nos proporciona el software. 
Por ejemplo tenemos datos más allá de las 09:55 (aproximadamente) de la mañana, momento en el cual hemos desactivado la licencia:

Lo que confirma que los datos se almacenan sin problema y permitiendo la posterior consulta y visualización de estos. 

La diferencia en cuanto a las comunicaciones es que en el caso de los clientes de trends, o de datos históricos, aparecerá un mensaje de que no hay licencia activa, e iniciará una cuenta atrás:


Y cuando esta cuenta atrás llega a 0, debemos resetear al cliente (en mi caso es el Trend de AVEVA) para reconectar. 

NOTA: la herramienta Query no nos permite consultar estos datos sin necesidad de licencia activa, funciona igual que el "Trend":


Tras finalizar este período podemos cerrar y abrir la aplicación para poder volver a trabajar sin licencia activa. 



3) Pruebas con el IDE de Application server sin licencia activa (en grace period de 24 horas)

El IDE no permite acceso sin licencia activa. 


Si accedemos con licencia activa en ese momento, obviamente no tenemos ese problema: 

Lo curioso ocurre cuando tenemos abierto el IDE, pero desactivamos la licencia, podremos operar de manera completamente normal con la mayoría de los componentes del IDE, incluso desplegar y hacer check-ins, por ejemplo. 
Hacemos la prueba, vamos a desactivar la licencia mientras está abierto el IDE: 

Lo primero que podemos ver es que no nos cierra el software, ni nos indica ningún mensaje de error. 


Nos permite:
- Abrir objetos, modificarlos, añadir I/O 
- Realizar el check-in y check-out de los objetos
- Se pueden desplegar objetos, incluso aquellos en los que se ha modificado los I/O
- Permite la modificación de plantillas y posterior derivación a las instancias de esta
- Permite utilizar WindowViewer 

¿Qué ocurre al finalizar las 24 horas de periodo de gracia?

Finalizado el periodo de gracia de 24 horas después de quedarnos sin licencia activa en el servidor, podremos ver que las comunicaciones no se establecen, además de que no historizamos y no podremos acceder al IDE. 
                              

Con los drivers ocurre algo curioso, podemos reiniciarlos para obtener otras dos horas de "prueba" del driver, es decir, podremos utilizarlo siempre que lo reiniciemos cada dos horas, esto puede ser muy útil en casos donde el cliente está en desarrollo o quiere probar algunas soluciones sin necesidad de contar con una licencia activa en ese servidor. 
El símbolo del driver de color verde con un triángulo representa este periodo de tiempo de prueba de dos horas que comentaba en los anteriores párrafos. El funcionamiento de los trend client será el mismo, es decir, pedirá la licencia cada 20 minutos aproximadamente y nos impedirá ver los datos históricos, como con los drivers podemos cerrar y abrir el software para permitirnos trabajar, pese a que no tengamos licencias activas en ese momento. 

            



ANEXO I. RESERVA DE LICENCIAS 

Concepto de reserva de licencias

Cuando tenemos varias licencias, podemos utilizar la función de reserva que nos ofrece el Enterprise License Manager, si lo hacemos garantizaremos que se asigna una licencia a un dispositivo o usuario específico, o a varios de ellos. Si tiene varias licencias iguales, para el mismo producto alojado en el mismo servidor de licencias, las reservas no son necesarias. Sin embargo, si una o más licencias tienen una funcionalidad única, entonces se necesitan reservas para asegurar que los dispositivos (servidores) adquieran únicamente esas licencias.
  
  1. Reserva de dispositivo
          Reservar una licencia de producto específica para un dispositivo garantiza que un usuario que acceda a ese dispositivo pueda utilizar esa licencia reservada siempre que el             usuario esté autorizado por el producto licenciado.

  1. Reserva de usuario
        Reservar una licencia para un usuario específico garantiza que el usuario podrá utilizar la licencia reservada siempre que el usuario está autorizado por el producto con             licencia.

Checkout licenses

Podemos hacer un check-out de las licencias que deseemos, lo que hacemos con el Checkout es asignar permanentemente esas licencias para un nodo, tras esto las licencias no requieren el License Server. 
La utilidad de Checkout te permite realizar la extracción (check out) y/o devolución (check in) de determinadas licencias, estas licencias quedarán permanentemente asignadas a ese nodo para su uso, pero no podrán ser utilizadas en otros nodos hasta realizar el Check-in.
Info
Solo un usuario que sea administrador o miembro del departamento de seguridad de LicMgr puede acceder a la utilidad Checkout.

Drop devices

Nos permite eliminar un dispositivo para liberar todas las licencias adquiridas y reservadas asociadas a él. Esto quiere decir que eliminará tanto la reserva de esa licencia como su activación en el dispositivo que seleccionemos. 


Notes
Nota: En un escenario de par redundante, la operación de colocación del dispositivo es exitosa sólo si los servidores están en estado "conectados".

Checkout de licencias en entornos donde acceden RDC (Remote Desktop Connection) son mediante el RDS

En el caso de usuarios que accedan al servidor mediante escritorio remoto, la reserva de licencias y su checkout puede provocar que esas licencias queden bloqueadas por el sistema. Para evitar este comportamiento se recomienda reservar únicamente licencias para usuarios que no sean RDC, de manera que no permítamos que estas licencias puedan llegar a estar "bloqueadas". Si este comportamiento ocurre, en la vista de Usage Details aparecerán las licencias disponibles, que realmente han quedado bloqueadas, por lo que nos dará fallo de adquisición de licencia en el nodo en el que intentemos acceder a alguna funcionalidad del software. 

Para resolver este problema, simplemente debemos hacer un checkin de las licencias reservadas, además de un drop de ese dispositivo. En ese punto las licencias vuelven a estar disponibles para su adquisición en otros servidores que lo requieran. 
Info
Se recomienda NO utilizar el Checkout en sesiones RDC o de clientes de supervisión (con o sin Historian) y utilizarlo para los Communication Drivers, es decir, las licencias encargadas de las comunicaciones, ya que siempre deben estar activas y si hay cualquier fallo queremos que queden asignadas permanentemente a ese servidor y vuelvan a comunicar cuánto antes. 
Warning
Reiniciar el servidor, o modificar según qué servicios puede afectar al funcionamiento planteado en el documento, por lo que no se recomienda hacerlo bajo ningún concepto, es probable que se pierda el periodo de gracia de 24 horas mencionado, y que el servidor o servidores se queden sin la posibilidad de utilizar los productos de AVEVA, las comunicaciones y la historización se verán afectados...
AlertNota Importante: Esta Nota Técnica se entrega “as is”, es decir, como complemento a la documentación del producto, pero no incluido dentro del ámbito del Soporte Técnico. Por tanto, cualquier mal funcionamiento derivado del contenido de esta nota técnica no es responsabilidad de Becolve Digital.