4.1 CONCLUSIONES
• En base a los resultados obtenidos, se puede concluir que es posible implementar de manera satisfactoria un clúster computacional de alta disponibilidad entre dos centrales IP virtualizadas usando la versión de Issabel liberada en enero del 2020, permitiendo la continuidad del servicio de comunicaciones, tanto para el funcionamiento normal la central IP (IVR, llamadas salientes, entrantes, CDR), como para el funcionamiento de un call center (campañas salientes, monitoreo de campaña). Constituyéndose en una solución para empresas cuya actividad económica depende en gran medida del funcionamiento de su central IP, como empresas de cobranzas, empresas que brindan soporte técnico, call centers enfocados al agendamiento de citas médicas o a la venta de distintos productos y servicios.
• En el caso de un evento programado o no programado, que impida el funcionamiento de la central principal, los usuarios pueden recuperar el servicio de comunicaciones, tanto para las funciones normales de la central IP, como para las funciones del módulo de call center, sin la necesidad de que un especialista intervenga en el proceso, en el peor de los casos, que es la pérdida del servicio en medio de una campaña saliente, solo tienen que cerrar y volver a abrir el softphone, ingresar a la consola de agente, e intentar registrarse nuevamente.
• En el caso de un evento programado o no programado, que impida el funcionamiento de la central principal, los usuarios pueden recuperar el servicio de comunicaciones, tanto para las funciones normales de la central IP, como para el las funciones del módulo de call center, en un lapso de tiempo menor a un minuto. Si la falla se da cuando no hay llamadas salientes, la recuperación del servicio de comunicaciones llegaría a ser transparente para el usuario.
• Se constató el funcionamiento de DRBD, el cual se encuentra trabajando siempre en los dos nodos bajo la modalidad maestro-esclavo, en donde solo el nodo que funciona como maestro monta el dispositivo de bloque replicado (drbd0) y tiene permisos de escritura y lectura sobre él. Aparte de que la información está en constante sincronización entre los dos nodos, este comportamiento es muy importante cuando se detiene la central primaria por medio de un evento planificado, es decir, usando un comando para apagarla, ya que se evidenció que
92
existe un intercambio de mensajes previo al traspaso de recursos para prevenir al nodo secundario que el primario está en proceso de apagado, lo que permite que los servicios se inicialicen más rápido que en el caso de un evento no planificado. • Se comprobó el funcionamiento de Corosync y de Pacemaker por medio de los
mensajes de los logs del sistema del nodo que pasaba a ser primario, en los que se pudo observar las distintas notificaciones que se realizan cuando existe un cambio en la estructura del clúster, e incluso se pudo observar las notificaciones del protocolo TOTEM para rediseñar el clúster en caso de que uno de los nodos falle en un evento programado o no. En cuanto al comportamiento de Pacemaker, se pudo constatar el proceso de control y traspaso de cada uno de los recursos configurados en el clúster, en donde se pudo observar que los recursos se inicializan en la central que pasa a ser primaria de acuerdo al orden establecido en las configuraciones.
• Se constató el correcto funcionamiento del servicio de telefonía IP y del módulo de call center de la plataforma de comunicaciones unificadas denominada Issabel, probó ser eficiente, de fácil configuración e interpretación, ya que permite implementar desde un servicio de telefonía IP básico, hasta un servicio que requiera funcionalidades más avanzadas. Uno de los factores para que esto suceda, es su interfaz web intuitiva, en la que se puede encontrar las opciones de configuración, pero aparte, se puede obtener estadísticas del uso de los recursos del servidor, del estado de las llamadas, aparte del CDR. En cuanto al módulo de call center, como se puede observar en el apartado de la implementación, su configuración no es difícil y también se pueden obtener estadísticas sobre el comportamiento de los agentes y sobre el comportamiento de las distintas campañas de llamadas salientes que se configuren.
• Se comprobó dos de los más importantes beneficios de la hiperconvergencia en TI, demostró ser una gran herramienta para poner en producción varios servidores virtuales, aparte de esto, se la usó para crear el escenario de prueba, logrando tener un control detallado sobre cada servidor virtual y evitando la necesidad de adquirir nuevos dispositivos físicos, pero logrando el mismo comportamiento como si se lo hubiera hecho.
93
4.2 RECOMENDACIONES
• Si existen fallas en el comportamiento del clúster, remitirse a los mensajes de los logs del sistema para averiguar la causa del error y poderlo solucionar, en este trabajo se tuvo que realizar eso para solucionar dos problemas puntuales, el primero fue la incompatibilidad del Kernel que viene por defecto en Issabel, con el que necesita DRBD y el segundo problema tuvo que ver con un error en la base de datos que usa Asterisk, el cual no permitía que se realicen llamadas a nivel local, ni a exteriores, para lo cual también fue de gran ayuda la interpretación de los mensajes del CLI de Asterisk.
• Si al probar el servicio de DRBD, los dos nodos se quedan como secundarios, se debe forzar al nodo principal a que sea el primario, esto se lo puede hacer por medio de los comandos que se usó en la parte de configuración de este trabajo. En caso de que la parte de comandos no funcione, se recomienda apagar el nodo que se desea que sea secundario, y ahí usar los comandos para forzar al nodo principal a que sea primario.
• Si al momento de ingresar a la consola web de Issabel, se presenta el error “FATAL: Unable to render with empty menú!”, se debe borrar los datos de navegación del navegador, sobre todo las cookies.
• Para un escenario de producción se recomienda crear usuarios en la central con permisos para acceder únicamente a la consola de agente, así, cuando un agente se registre en la interfaz web de Issabel, solo tendrán acceso a la consola de agente, más no, a todas las configuraciones a las que accede el administrador. • En caso de que se necesite obtener ayuda por algún inconveniente con Issabel, se
puede encontrar información en el foro de Issabel, en la cuenta de GitHub de Issabel y en su fanpage de Facebook. Como es muy similar a Elastix, también se puede encontrar ayuda en los foros y en la bibliografía sobre Elastix, y al estar basado en Asterisk, también se puede usar los foros, la wiki y la bibliografía sobre Asterisk. • Cuando se realice pruebas, tomar en cuenta si los relojes de cada sistema se
encuentran sincronizados, en este caso, se tuvo que considerar que el reloj de VMware estaba adelantado con 4 segundos, respecto al reloj de Issabel. Para solucionar este inconveniente, se podría sincronizar los relojes con un servidor NTP (Network Time Protocol).
94
• Como mejora al presente trabajo se puede implementar el modelo del clúster de alta disponibilidad incluyendo una campaña de llamadas entrantes y la posibilidad de grabación de llamadas, usando una central IP de respaldo que se encuentre implementada en la nube, ya que es la tendencia en cuanto a infraestructura tecnológica, debido los altos niveles de disponibilidad que ofrecen las plataformas como las de Amazon, Google o Vultr. También, se puede ampliar el alcance de este trabajo, al configurar un clúster en el cual, si una aplicación específica deja de funcionar o se corrompe, inmediatamente se inicie el servicio en el otro servidor. • El clúster implementado en el presente trabajo, al estar basado en software libre,
abre las puertas a que se puedan realizar nuevas mejoras y desarrollos, tanto en los elementos del clúster propiamente dicho, como en las funcionalidades de la central IP. Se pueden desarrollar ambientes de alta disponibilidad híbridos, es decir usando infraestructura física y virtual, netamente virtuales o netamente físicos. Se pueden realizar desarrollos que interactúen con Issabel, como plataformas de tarifación, plataformas personalizadas para la consola de los agentes, plataformas personalizadas para la administración del call center, plataformas para poder realizar encuestas después de una llamada, plataformas de CRM (Customer Relationship Management, gestión de relaciones con clientes) que se integren con el módulo de call center, entre otras. Para esto, el lenguaje fundamental de programación es PHP.
95