TIEMPO DE RECUPERACIÓN DEL SERVICIO DE COMUNICACIONES

Esta prueba se la hace para dos escenarios, el primero consiste en apagar de manera manual la central IP que está actuando como primaria (simulando un escenario de mantenimiento) y en el otro escenario, se apaga de manera forzosa la central IP que está funcionando como primaria (simulando una falla no programada).

82

Para realizar la prueba dentro del primer escenario se enciende la central secundaria para apagar de manera manual (por medio de comandos) la central principal y establecer el tiempo de recuperación de los servicios usando los logs de sistema de ambos servidores (accediendo a /var/log/messages), así:

El momento que se ejecuta el comando para apagar la central principal (shutdown -h now), se inicia un proceso en el cual se van cerrando todos los servicios y se notifica a la central secundaria que el nodo principal dejará de funcionar, dando un tiempo para que la central secundaria se prepare a inicializar los servicios de manera local. En la Figura 3.7 se muestra el proceso de cambio de recursos desde que se apaga la central principal hasta que se carga el último recurso en el nodo secundario. Se nota que el momento en que se ejecutó el comando de apagado en el nodo principal fue a las 12:15:59, a las 12:16:07 se genera una notificación en el nodo secundario por parte del servicio DRBD (que siempre se encuentra funcionando en ambos nodos bajo la modalidad maestro-esclavo), en donde se avisa que el nodo que era primario, pasa a ser secundario, a las 12:16:08 el nodo secundario toma el control del recurso ip_virtual, a las 12:16:13 toma el control de datos_DRBD, a las 12:16:15 inicializa el recurso SistArch_DRBD, a las 12:16:23 inicializa el recurso MySQL, a las 12:16:27 inicializa el recurso Asterisk y a las 12:16:29 inicializa el recurso Apache.

Figura 3.7. Cronología del proceso de recuperación del servicio de comunicaciones en el primer escenario.

83

Para realizar la prueba dentro del segundo escenario se enciende el nodo principal, una vez hecho esto, se apaga el nodo secundario (que está actuando como primario) desde la consola de VMware, al igual que se realizó en el primer escenario, el tiempo de recuperación de los servicios de comunicación se constata por medio de los logs del nodo que pasa a ser primario. Para saber el tiempo en el que se apagó el nodo principal se usa el registro de eventos del servidor virtual de VMware, cabe destacar que el tiempo de VMware se encuentra adelantado con 4 segundos al de Issabel, así que por lo que se muestra en la Figura 3.8, el servidor secundario se apaga a las 18:25:34 (tiempo de Issabel) y en ese mismo instante le llega una notificación del protocolo TOTEM en el servidor principal de que se debe cambiar la configuración del clúster, a las 18:25:37 el servidor primario toma el control del recurso ip_virtual, a las 18:25:41 toma el control del recurso datos_DRBD, a las 18:25:49 inicializa SistArch_DRBD, a las 18:25:59 inicializa MySQL, a las 18:26:04 inicializa Asterisk y a las 18:26:07 inicializa Apache.

Figura 3.8. Cronología del proceso de recuperación del servicio de comunicaciones en el segundo escenario.

3.1.5 COMPORTAMIENTO DEL CLÚSTER EN UNA CAMPAÑA SALIENTE

Para esta prueba se inicializa la campaña de llamadas salientes desde la central primaria del clúster con los agentes 1001 y 1002, usando las extensiones 101 y 102, respectivamente. Se carga una base de 30 contactos, que es la que se muestra en la Figura 2.39, con la idea de que se tenga tiempo para responder las llamadas. Se contestó las dos primeras llamadas, en la Figura 3.9 se puede observar las consolas de los agentes 1001 (atendiendo la llamada que se hizo a 4002) y 1002 (atendiendo la llamada que se hizo a

84

4001), para este instante, en las estadísticas de la campaña se tienen 2 llamadas conectadas y 6 fallidas (son números que no existen en la central de pruebas), como se observa en la Figura 3.10, en ese momento se procedió a apagar la central principal desde VMware (apagado forzoso). A continuación, se describe el comportamiento del clúster cuando existe una falla en una campaña de llamadas salientes:

Figura 3.9. Agentes 1001 y 1002 en medio de una llamada.

Figura 3.10. Estadísticas de la campaña cuando en medio de las dos primeras llamadas. Las comunicaciones se cortaron, las extensiones 101 y 102 dejaron de recibir audio, pero en la consola de los agentes seguía avanzando el tiempo de llamada, dando la impresión de que la llamada continuaba, un momento después aparece el mensaje de pérdida de

85

conexión con el servidor, como se muestra en la Figura 3.11. Si se recarga la página web, se podrá observar un mensaje de que la página no se encuentra disponible, si no, se presentará la página de inicio de sesión de Issabel, dependiendo si transcurrieron o no los 33 segundos que aproximadamente se demora el clúster en reestablecer los servicios de la central IP.

Figura 3.11. Error de pérdida de conexión con el servidor.

Una vez que se ha podido acceder nuevamente a la interfaz web, en la opción de campaña saliente se puede observar que la campaña sigue activa y en la opción de monitoreo de campaña se indica que se terminaron las dos llamadas, por lo que también se indica que se conectaron dos llamadas, hay seis llamadas fallidas y quedan veintidós por realizar, como se muestra en la Figura 3.12.

Otro aspecto a destacar de la Figura 3.12, es que no aparecen los agentes de la campaña, de hecho, si se desea volver al registrarse como agente desde la consola de agentes, en algunos casos no se podrá, porque sale el error de que es un número de agente inválido, como se muestra en la Figura 3.13. Para solucionar este problema se debe cerrar y volver a abrir el softphone, una vez hecho esto, se vuelve a intentar el registro del agente. En este punto ya habrán aparecido los agentes en la pantalla de monitoreo, si no se permitió el registro, se debe intentar otra vez. Una vez que se permite el registro del agente, la central empieza a asignar nuevamente las llamadas a los agentes conectados, en el monitoreo de campaña se puede observar este proceso, como se muestra en la Figura 3.14.

86

Figura 3.12. Estadísticas de la campaña saliente después de la recuperación de los servicios de comunicaciones en el nodo secundario.

Figura 3.13. Error de registro de agente.

Figura 3.14. Asignación de llamadas a agentes registrados nuevamente después del fallo en la central principal.

87

3.2 RESULTADOS DE LAS PRUEBAS DE FUNCIONAMIENTO