Rh Cloud Monitor

APP para la monitorizacion de redes de comunicaciones de todo ambito FTTH /Gpon etc.

posibilidades de configuración
entornos distintos y sencillo: una máquina, un repositorio, un usuario.
Las coordenadas en las que se puede enriquecer la arquitectura son:
● Multi-server. Cuando por número de CPEs gestionados, tecnologías
provisionadas/monitorizadas, usuarios del sistema, etc. una única máquina se queda
pequeña.
● Multi-realm. Cuando la topología de la red a provisionar/monitorizar así lo aconseje.
● Multi-vendor. Migraciones para cambiar el fabricante de equipamiento de red.
● Multi-rol: distintos perfiles de usuario precisan de herramientas distintas.
● Multi-kiwi. Diferentes departamentos de atención al cliente necesitan visibilidad de
sólo una parte de los usuarios.
Multi-server / Multi-realm
Las combinaciones son tantas como las que permita shinken. Y no son pocas.
http://shinken.readthedocs.io/en/latest/09_architecture/
Multi-vendor – GPON
Analicemos, por ejemplo, el caso de querer migrar una red GPON con OLTs de fabricante H
al Z:
● 32 PON con aproximadamente 30 ONUs por PON… cerca 1.000 clientes.
● Algún modelo de ONU (H-SlowWiFi) ha de remplazarse por otro (Z-FastWiFi).
Pongamos que hay 250.
● Servicio VoIP
● Servicio IPTV.
Paso1 – Monitorización oltH
Krill Monitorizando oltHuawei nos anuncia qué modelos de ONU están presentes en cada
PON, con lo que podremos cuántas ONUs se han de sustituir en cada paso.
Paso2 – Provisión en oltZ
Definición de Servicios en oltZ, tests de velocidad, pruebas VoIP, IPTV, etc.
Paso3 – Test de migración
Saco una fibra del primer PON de la oltH y lo pincho en la oltH. Si algo falla, lo dejo todo
como estaba. Si todo funciona, cambio las 3? H-SlowWiFi por los nuevos Z-FastWiFi.
Sencillo.
Paso3. Migración.
Una vez que está todo testeado, lo único que restar es planificar el remplazo de los
H-SlowWiFi por los nuevos, PON a PON. Al ritmo que demande la red.
Multi-rol
Bajo una misma instancia Krill se pueden definir tantos perfiles de usuario como sean
necesarios. Por ejemplo:
● Usuarios del NOC ven alarmas, informes y gráficas sólo de máquinas centrales
(OLTs, CMTSs, switches, routers, enlaces, estaciones base, etc.)
● Usuarios del Call Center sólo ven datos de CPE.
● El encargado de la parte WiMAX no recibe alarmas de la parte GPON, pues queda
fuera de su competencia.
Multi-Kiwi
Krill puede cargar clientes y CPEs de varias APIs Kiwi, cada uno definido para definir los
servicios contratados por una serie de poblaciones. Cada una tendría un espacio de
nombres distintos para sus CPEs.
Por otro lado se pueden definir usuarios que sólo tengan acceso a uno de estos espacios de
nombres.
El resultado: distintos equipos de atención a cliente acceden a los clientes de sus
poblaciones. Los usuarios del NOC siguen teniendo acceso a todas las máquinas centrales.