Netin HUB¶
¿Qué es?¶
NetinHub se puede definir de dos formas:
- El addon para conectar e integrar NetinDS con el resto del mundo, facilitando el intercambio de información e incorporando nuevas funcionalidades al sistema de diagnóstico y monitorización.
- Un servicio que gestiona, analiza y enruta los datos de monitorización de NetinDS para integrarlos en diferentes sistemas, infraestructuras OT, plataformas IoT, sistemas ad hoc, etc. mediante distintos servicios cloud como AWS, Azure o Mindsphere entre otros.
¿Como funciona?¶
NetinHub es un servicio que gestiona, analiza y enruta los datos de monitorización del servidor para integrarlos en diferentes sistemas, infraestructuras OT, plataformas IoT, sistemas ad hoc, etc. mediante distintos servicios cloud como AWS, Azure o Mindsphere entre otros, facilitando el intercambio de información e incorporando nuevas funcionalidades al sistema de diagnóstico y monitorización, actuando como Gateway.
NetinHub recibe la información mediante el Bróker de Kafka, que se encarga de redirigir la información hacia el FireHose correspondiente en función de al cloud al que se quiera enviar la información.
Un ejemplo: En la plantilla de un equipo se indica en la opción broadcast que todos los datos que se recojan de ese equipo han de ser llevados a AWS. Cuando esos datos se han procesado por el agente (en Zavod), han sido enviados al servidor mediante el FireHose Uplink y enviados a NetinHub desde el servidor por el FireHose Broadcast, al llegar a NetinHub, este envía los datos recibidos al servidor, cluster, etc del cliente.
Además, en este caso, contamos con Apache Nifi para poder controlar de forma visual el flujo de información hacia otros sistemas (AWS, Azure, etc) de una forma completamente visual y mucho más intuitiva y que está directamente conectado con el Broker de Kafka.
Para terminar con el NetinHub, comentar que, a diferencia del bróker AMQ, el bróker de Kafka no dispone de una interfaz visual propia, por lo que actualmente este bróker se conecta con CMAK para poder interactuar con el bróker de Kafka y poder controlar así la información que maneja de una manera más sencilla.
Brokers de comunicación que se utlizan en NetinHub:¶
Kafka¶
Es un bróker encargado de establecer las conexiones con todos los sistemas externos, de gestionar los buffers y la bifurcación y replicación de la información.
Permite retener los mensajes en el buffer mediante un periodo de tiempo determinado por si hubiera problemas de conexión con los servidores de almacenamiento y procesamiento de la información.
Estos mensajes podrían estar almacenados en los buffers durante una semana, por ejemplo y tras pasar esa semana, si no se ha podido establecer nuevamente la conexión con el servidor, estos mensajes serían eliminados.
Además de permitir gestionar los buffers por tiempo, también permite gestionar los buffers por tamaño, de manera que, tras alcanzar un determinado tamaño, estos mensajes serían eliminados si no se ha conseguido establecer conexión con el servidor.
En lo referente a la bifurcación y replicación de la información, hay que mencionar que hay grupos de consumo que permiten gestionar de una manera rápida y eficiente donde queremos almacenar y procesar la información.
De esta manera, basta con cambiar al grupo de consumo deseado (AWS, Azure, etc.) para duplicar la información en el nuevo destinatario sin que desaparezca del destinatario original. Ideal para realizar pruebas o para tener replicación.
FireHoseApi¶
Es la interfaz encargada de sacar la información hacia medios externos mediante el uso de diversos conectores para conectar sistemas (origen y destino).
Esta API está basada en el concepto de SINK y SOURCE para conectar un orígen con un destino. SINK es la clase encargada de enviar la información mientras que SOURCE es la clase encargada de recibir la información por la tubería.
Para SINK existen dos métodos de sincronización (JET y TAP). JET se utiliza para recibir la información de forma continua y TAP para enviar paquete a paquete. Para SOURCE existen tres métodos de sincronización (FLOW, SEQUENCE Y WINDOW).
FLOW se utiliza para recibir la información de forma continua hasta enviar un PAUSE para parar el envío de información. SEQUENCE se utiliza para recibir la información paquete a paquete y WINDOW se utiliza para recibir los paquetes hasta llenar el tamaño de ventana. Una vez se llena la ventana, hay que esperar a que el destinatario lo procese y vacíe la ventana para seguir recibiendo información.
Además, FireHoseAPI implementa la técnica de backpressure basada en Node.JS, que se explica más adelante. Explicación de Backpressure.
FireHoseAPI también dispone de una interfaz en la que poder desarrollar diferentes estrategias que permita aplicar tantas reglas como se quiera, como un procedimiento específico para transformar o interpretar datos, por ejemplo.
La gran ventaja de esta API es que cualquier implementador de la herramienta (externo, que haya realizado los cursos de formación, o interno) puede implementar una nueva salida en un corto periodo de tiempo y en la que le llegará un TimeStamp, un ID de dispositivo y la información correspondiente. Esto permite que ante una alta demanda de algún servicio externo concreto se pueda desarrollar e implementar el conector de una manera mucho más efectiva.
¿Qué conectores hay actualmente?¶
Actualmente NetinHUB dispone de una serie de conectores que permiten la conexión con los servidores cloud (AWS y Mindsphere) e incluso con bases de datos SQL mediante canal frío y canal caliente, utilizando replicación y routing de datos, pero... ¿Qué es un canal frio o un canal caliente?
Canal frío (subida en frío)¶
¿Qué es?¶
El Canal frío o la subida en frío se utiliza para subir cualquier cantidad de datos a los que se va a acceder con poca frecuencia para poder analizarlos posteriormente bajo demanda y a un coste mucho menor. Estos datos se envían al servicio cloud en un periodo de tiempo más amplio o al llegar a una cierta capacidad. Este canal es el utilizado por defecto.
¿Dónde se almacenan los datos?¶
Los datos subidos mediante esta canal se almacenan en un almacenamiento denominado "Almacenamiento en frío". Este tipo de almacenamientos permiten almacenar cualquier cantidad de datos históricos o datos a los que se accede con poca frecuencia analizarlos bajo demanda, a un costo menor que en otros niveles de almacenamiento.
El almacenamiento en frío es apropiado si necesita realizar investigaciones periódicas o análisis forenses sobre datos antiguos. Algunos ejemplos prácticos de datos apropiados para el almacenamiento en frío son los registros a los que se accede con poca frecuencia, como los datos que se deben conservar para cumplir con los requisitos de conformidad o los registros que tienen valor histórico.
Canal caliente (subida en caliente)¶
¿Qué es?¶
El Canal caliente o la subida en caliente se utiliza para subir cualquier cantidad de datos a los que se va a acceder con mucha frecuencia para poder almacenarlos, analizarlos y procesarlos bajo mucha demanda y a un coste mucho mayor. Estos datos se envían en intervalos de tiempo breves, por ejemplo, cada minuto, al servicio cloud configurado para su procesamiento antes de volcarlos al bucket de almacenamiento
¿Dónde se almacenan los datos?¶
Los datos subidos mediante esta canal se almacenan en un almacenamiento denominado "Almacenamiento en caliente". Este tipo de almacenamientos permiten almacenar cualquier cantidad de datos a los que se accede con mucha frecuencia para poder almacenarlos, analizarlos y procesarlos bajo mucha demanda y a un coste mucho mayor que el almacenamiento en frío.
El almacenamiento en caliente es apropiado si necesita acceder a los datos de forma continuada como realizar consultas a bases de datos, sistemas gestores de correos electrónicos, el uso de la intranet de una empresa, reproducciones en Streaming (Netflix), etc.
¿Se esperan más conectores?¶
Conforme se ha mencionado con anterioridad, es muy sencillo gracias a la API fireHoseAPI y al broker de NetinHUB, implementar nuevos conectores, por lo que, si en algún momento surge una alta demanda de conexión con algún producto concreto, no se dudará en desarrollarlo. En breve estará disponible el conector para Azure, por ejemplo.
Terminología¶
NiFi¶
Apache NiFi es un proyecto de software de Apache Software Foundation diseñado para automatizar el flujo de datos entre sistemas de software. Aprovechando el concepto de Extraer, transformar, cargar, se basa en el software " NiagaraFiles " desarrollado previamente por la Agencia de Seguridad Nacional de EE. UU. (NSA), que también es la fuente de una parte de su nombre actual: NiFi. Fue de código abierto como parte del programa de transferencia de tecnología de la NSA en 2014.
El diseño del NiFi se basa en el modelo de programación basado en el flujo y ofrece funciones que incluyen de manera destacada la capacidad de operar dentro de clústeres, seguridad mediante cifrado TLS extensibilidad (los usuarios pueden escribir su propio software para ampliar sus capacidades) y funciones de usabilidad mejoradas como un portal que se puede utilizar para ver y modificar el comportamiento visualmente.
Replicación¶
Gracias a la API y al broker de NetinHUB, al tener diferentes salidas de datos desde NetinHUB (routing de datos), se permite la implementación de grupos de consumo para poder tener replicación de datos en diferentes sistemas.
Routing de datos¶
El Routing de datos hacia NetinHUB permite la configuración pormenorizada, mediante los templates (plantillas) de dispositivo de Netin, de los valores que se envían a la nube (NetinHUB), definiendo cuáles exactamente se suben y los servicios de destino (Azure, AWS, etc.) configurados en NetinHUB.
Por ejemplo, para un mismo dispositivo se puede definir que determinados datapointSets se envíen al cloud de Azure, otros al cloud de AWS, y otros no se envíen a la nube.
Sistema de Backpressure¶
Es una técnica basada en Node.JS, que utiliza un buffer interno (conjunto de todos los buffers del sistema) para almacenar los mensajes y no perderlos en caso de caída de la red, del servidor, etc. Y para evitar la saturación de red y del servidor ante el envío de mucha información, controlando en todo momento la cantidad de datos que se maneja.
Ahora bien, cuando este buffer se llena, para y deja de leer, en lugar de eliminar la información e informa al resto de equipos de que no puede recibir más información.
Ahora bien, como excepción, existe la opción de que esos mensajes vengan marcados con un tiempo de vida (TTL). En ese caso, cuando el TTL del mensaje haya vencido, es eliminado del buffer, lo que da paso a que lleguen nuevos mensajes.
Continuando con la norma general, cuando el buffer principal se vacía, empieza a vaciar el resto de los buffers para poder empezar a recibir más información.