Despliege empresarial

A continuación, se muestra un despliegue empresarial del sistema que incluye nuevos elementos no implementados en el prototipo y otros modificados pero que da una idea de lo que podría ser el sistema si se continuara con el desarrollo en el mismo.

El sistema se despliega en un cluster de máquinas físicas que a su vez tienen máquinas virtuales, es importante que los sistemas que sean varios nodos no corran todos sobre la misma maquina física para así en caso de fallo de la maquina el sistema pueda seguir funcionando. Esto es debido a que está diseñado para ser tolerante a fallos la mayoría de elementos encargados del procesamiento y almacenamiento de información funcionan de manera distribuida por lo que si se cae un nodo otro ocupara su lugar. Por otro lado, esto permite añadir nuevos nodos para por un lado aumentar la tolerancia a fallos y por otro escalar el sistema para que pueda procesar y almacenar más datos.

Para describir este despliegue, se va a usar el de desarrollo como base, es decir, primero se comentarán las modificaciones del sistema y a continuación las agregaciones al mismo.

 Modificaciones

o IBM Streams, Kafka y HBASE: Estos elementos pueden funcionar de manera distribuida, por lo que en vez de ser un solo nodo corriendo el elemento con un Zookeeper embebido, se usaran varios nodos corriendo en máquinas físicas distintas y usando un Zookeeper externo, así se les añade tolerancia a fallos y escalabilidad.

o HDFS: De igual manera que los anteriores, HDFS también funcionaria de manera distribuida, aunque en este caso no requiere de un Zookeeper.

o IBM streams: en este caso lo ideal es añadir procesamiento de eventos complejos, que permitiría añadir funcionalidades como modificación de rutar, gestión de alarmas etc. Además, el canal de comunicaciones con Kafka se convertiría en bidireccional debido a que los resultados de dichos eventos se volverían a mandar a Kafka.

o REST server: puesto que HBASE envía las tablas enteras sin hacer ningún tipo de filtrado como haría una base de datos SQL, era el propio REST Server el encargado de hacerlas, puesto que el servidor no corre de manera distribuida cuando la cantidad de datos aumente aumentara la latencia de las peticiones Por ello se ha optado por delegar esa función en apache Phenix por lo que el servidor REST solo tendría ahora que solicitar la información en formato SQL.

o Edgent: En pos reducir los costes de despliegue, usando la filosofía Fog se ha sustituido el diseño de que cada contenedor y camión tuvieran su pequeño procesamiento por uno en el que todos los cubos y camiones tendrían lo más básico, un medio para capturar la información y transmitirla a una centralita (que puede tener otra de respaldo, en dicha centralita) se añadiría los

procesamientos pertinentes según la filosofía Fog (agregaciones, fechas horas, etc.) y se enviarían al cluster. Para la comunicación entre los contenedores y camiones y la centralita se usaría Lora para una arquitectura en estrella y Zigbee para cuando se requiera una arquitectura en malla.

o Kafka: Puesto que kafka incluye dentro Kafka streams, lo lógico sería intentar aprovechar dicha capacidad Fast Data para añadir agregaciones a los datos y eventos que corren por sus topics.

 Agregaciones

o Zookeeper: Puesto que gran cantidad de aplicaciones dependen de él, si fallara Zookeeper, el sistema se vería gravemente afectado, por ello se corre un cluster de nodos en modo Quorum para asegurar la tolerancia a fallos del sistema preferiblemente impar.

o MQTT: Uno de los problemas de Kafka es que está ideado para correr dentro de un cluster, por lo que tiene muchos problemas para trabajar con un firewall de por medio, por ello se ha usado un sistema publicador/subscriptor llamado MQTT que si se lleva mejor con los firewalls y serviría de pasarela entre el

exterior del cluster y Kafka. Puesto que MQTT no es distribuido para añadir tolerancia a fallos y escalabilidad necesitaremos usar un balanceador de carga, que se encargue por un lado de repartir los datos que le llegan entre los diferentes MQTT y detectar que están en funcionamiento. Para añadir tolerancia a fallos al balanceador se le añade uno de respaldo que entra en funcionamiento en caso de caída del primero.

o Apache Phoenix: Es el encargado de que cuando le llegue una petición SQL, tomar la información de HBASE y filtrarla y devolverla en forma SQL. Corre de manera distribuida usando Zookeeper, por lo que es escalable y tolerante a fallos.

o Spark/IBM BigInsights: Puesto que IBM streams está centrado en FastData no puede hacer procesamientos muy pesados debido a que añadiría latencia al sistema, para dichas tareas se proponen tecnologías de procesamiento en Batch como son Spark e IBM BigInsights para hacer análisis pesados sobre los datos del sistema.

Ilustración 89 Despliegue Empresarial

También es importante comentar que el uso de Kafka en el cluster permite que, si se quieren añadir nuevas herramientas de procesamiento o de tratamiento de eventos, simplemente las tenemos que conectar a kafka que nos ofrece un bus unificado por el que pasan todos los datos.

5 |

Manual

En este apartado se encuentra un breve manual para el manejo de la interfaz web.

5.1

Accediendo al interfaz por primera vezx

Cuando se inicia el sistema y se conecta uno por primera vez a la página, lo que se puede ver es esto:

1. A la de recha de la barra de navegación superior están los controles de vistas donde podemos cargar y guardar vistas para visionar en otras ocasiones. Esta barra es siempre visible, aunque se haga desplazamiento a la parte baja de la web.

2. Justo debajo de la barra de navegación, se encuentra el mapa, dicho mapa contiene los contenedores que se monitorizan. El color del icono de cada contenedor puedes ser verde, amarillo o rojo según su nivel de llenado. Si se deja el cursor quieto sobre el icono se puede ver el porcentaje de llenado exacto del mismo.

3. En este punto se irán añadiendo las nuevas vistas que se vayan creando. 4. Este panel sirve para agregar nuevas vistas.