CAPTULO 6

ESQUEMAS DE SISTEMAS VOIP CON ALTA DISPONIBILIDAD Y ALTO RENDIMIENTO

1

Introduccin

El objetivo de este captulo es mostrar la posibilidad de integracin del servicio de VoIP Asterisk con los servicios de alta disponibilidad y alto rendimiento vistos anteriormente. Existen diversas opciones a la hora de integrar alta disponibilidad y/o alto rendimiento en un sistema VoIP, cada una presentando sus ventajas e inconvenientes, de forma que permita adaptar las caractersticas del sistema a los requisitos que se deseen cumplir y manteniendo los costes de implantacin. Para ver el alcance de las distintas combinaciones que se pueden llevar a cabo, se va a detallar en un ejemplo una arquitectura VoIP bsica para ir complementndola e integrndola con los servicios de alta disponibilidad y alto rendimiento ya vistos en los puntos anteriores, analizando y estudiando las ventajas e inconvenientes de cada uno de ellos desde el punto de vista de la disponibilidad del servicio, del rendimiento as como del coste de implantacin que dicha configuracin supondra a una empresa.

Esquema bsico

Supongamos como escenario bsico una Universidad. Para simplificar, supongamos que la red de cada uno de los edificios de la Universidad se conecta a un switch central, el cual conecta directamente cada uno de ellos con la troncal que ofrece acceso a Internet a toda la Universidad. En la figura 6-1. Arquitectura bsica de un escenario VoIP se muestra esta arquitectura.

Figura 6-1. Arquitectura bsica de un escenario VoIP

El sistema se compone de una centralita Asterisk sobre la cual se registran todos los telfonos de la Universidad. Asterisk tiene varios proveedores: un proveedor de VoIP para sacar el trfico internacional y otro PSTN o Public Switched Telephone Network por lo que tambin se podrn realizar llamadas a travs de la red telefnica tradicional. Adems, la Universidad permite que usuarios externos se puedan conectar a Asterisk a travs de Internet, de manera que los usuarios del sistema puedan realizar llamadas desde cualquier lugar del mundo tal y como si estuvieran dentro de la Universidad. A primera vista, el sistema cuenta con dos puntos de fallo. El punto de fallo ms importante es Asterisk, ya que en caso de fallo toda la Universidad se queda sin el servicio, no pudiendo realizarse ningn tipo de llamada: ni llamadas internas en la propia Universidad ni llamadas realizadas por los usuarios externos, etc. El otro punto de fallo es la troncal de Internet de la propia Universidad. Si esta no se encuentra disponible durante un tiempo los usuarios externos no podrn hacer uso del sistema telefnico, ya que este se encuentra en el interior de la Universidad y no existe un camino alternativo a la troncal para acceder al sistema. Del mismo modo y en sentido inverso, no se podrn realizar llamadas a travs de un proveedor VoIP por lo solo se podrn realizar llamadas a travs de la PSTN, con el considerable incremento de costes que esto supone. Sin embargo, y afortunadamente, las llamadas internas entre clientes internos de la propia Universidad s podran realizarse ya que internamente el servicio no se vera afectado por el fallo de la troncal. Conocido el escenario inicial, se presentan a continuacin diversos esquemas en los cuales se van eliminando los puntos de fallo, analizndose adems, para cada uno de ellos, las ventajas e inconvenientes que presentan.

Esquema 1

El primer esquema consiste en una arquitectura VoIP de alta disponibilidad. El servicio de telefona es ofrecido por Asterisk y la alta disponibilidad se consigue mediante Heartbeat. La arquitectura, por tanto, se compone de un cluster de alta disponibilidad formado por dos nodos Asterisk con Heartbeat. En la siguiente figura 6-2. Arquitectura de un escenario VoIP con alta disponibilidad se muestra la arquitectura.

Figura 6-2. Arquitectura de un escenario VoIP con alta disponibilidad

En la configuracin de Asterisk se definen cules son los posibles destinos de cada terminal, los parmetros de autenticacin de cada terminal, buzones de voz, etc. Esta configuracin ha de mantenerse igual en los dos nodos Asterisk en todo momento. Por tanto, para hacer que el sistema sea ms fcil de mantener es necesario hacer uso de una aplicacin como DRBD para mantener los datos replicados en tiempo real como si de un sistema RAID se tratase, por lo que nicamente bastara realizar los cambios en el servidor Asterisk activo. En este primer esquema se elimina la vulnerabilidad de disponer de un nico servidor Asterisk ofreciendo el servicio. Para ello se hace uso de un cluster de alta disponibilidad mediante Heartbeat compuesto por dos nodos, donde cada nodo es situado en edificios distintos con el objetivo de minimizar la posibilidad de fallo simultneo de ambos debido al corte del suministro elctrico. De esta manera, adems de solucionar el problema de fallo hardware/software de uno de los dos nodos, en caso de fallo del suministro elctrico o incendio en uno de los edificios el servicio de telefona ser ofrecido por el Asterisk del otro edificio. Una alternativa sobre este mismo esquema es la de utilizar la replicacin MySQL en lugar de DRBD. Configurando Asterisk en modo Real-Time en cada uno de los nodos, donde cada nodo respectivamente har uso de su propia base de datos y mediante la replicacin

MySQL ambas bases de datos sern replicas por lo que la informacin ser redundante en ambos nodos en todo momento. Para que, independientemente del servidor Asterisk que se encuentre ofreciendo el servicio se pueda hacer uso de la PSTN, se complementa el sistema con un balanceador de primarios, como los comercializados por la empresa Redfone Communications. ste se integra con Heartbeat de tal manera que las llamadas tanto enviadas como recibidas a travs de la PSTN, son enviadas al Asterisk activo en ese momento. El punto de fallo presente en la troncal de Internet an existe en la solucin propuesta por este esquema, ya que ante el fallo de la troncal (por ejemplo el fallo del router) los usuarios externos no dispondrn del servicio telefnico de la Universidad.

Esquema 2

El segundo esquema consiste en una arquitectura VoIP de alta disponibilidad con balanceado. La arquitectura por tanto se compone de un clster de alta disponibilidad formado por dos nodos Asterisk con Heartbeat en la Universidad, un clster de alta disponibilidad de dos nodos Asterisk con Heartbeat en otra ubicacin remota y un servidor KAMAILIO situado en un lugar de muy alta disponibilidad como los mantenidos por el consorcio RedIris o cualquier DataCenter importante. En la figura 6-3. Arquitectura de un escenario VoIP con alta disponibilidad y balanceo se muestra la arquitectura.

Figura 6-3. Arquitectura de un escenario VoIP con alta disponibilidad y balanceo

En este esquema tambin es eliminado el punto de fallo hardware/software de disponer de un nico servidor Asterisk ofreciendo el servicio, por lo que, es muy poco probable que los usuarios internos de la propia Universidad, no se puedan comunicar entre s. En esta nueva arquitectura, nicamente los usuarios externos se registrarn y autenticarn en el servidor KAMAILIO. El motivo es que las comunicaciones telefnicas VoIP con origen los usuarios externos, es decir desde Internet, no se establecern directamente con

Asterisk (como en el caso de los usuarios internos) sino que lo harn nicamente con KAMAILIO. De esta manera KAMAILIO reenviar la comunicacin preferentemente al Asterisk de la propia Universidad, y si ste por cualquier motivo, no se encuentra disponible, reenviar la comunicacin al Asterisk remoto. El punto de fallo presente en la troncal de Internet de la Universidad es superado en la solucin propuesta por este esquema, ya que ante el fallo de la troncal o del router, los usuarios externos dispondrn del servicio telefnico remoto. Es obvio que un usuario externo no podr comunicarse con la Universidad mediante VoIP si la troncal no est operativa, aunque al menos s que lo podr hacer con otro usuario externo. Sin embargo, en este esquema se pone a disposicin del usuario externo el servicio telefnico tradicional por lo que la comunicacin con la Universidad si ser posible a travs de esta va.

Esquema 3

El tercer esquema consiste en una arquitectura VoIP de alta disponibilidad y alto rendimiento. Esta nueva arquitectura es necesaria cuando el volumen de llamadas es muy alto como para ser soportado por un nico y saturado nodo Asterisk. La arquitectura se compone de un clster de alta disponibilidad y alto rendimiento formado por dos nodos Asterisk + Heartbeat y dos nodos KAMAILIO + Heartbeat en la Universidad, un clster de alta disponibilidad de dos nodos Asterisk + Heartbeat en la ubicacin remota y un servidor KAMAILIO situado en un lugar de muy alta disponibilidad como los mantenidos por la empresa RedIris. En la figura 6-4. Arquitectura de un escenario VoIP con alta disponibilidad y alto rendimiento se muestra la arquitectura.

Figura 6-4. Arquitectura de un escenario VoIP con alta disponibilidad y alto rendimiento

Este tercer esquema aade al segundo esquema alto rendimiento en el interior de la propia Universidad. Es necesario por tanto modificar la configuracin de Heartbeat utilizada hasta el momento. Anteriormente, la configuracin del cluster de alta disponibilidad para el servicio Asterisk era un configuracin Activo/Pasivo, es decir, en un mismo instante

nicamente hay un nodo activo. Ahora con la nueva configuracin de Heartbeat se va a establecer un cluster de alta disponibilidad Activo/Activo, es decir, ambos nodos Asterisk y en el mismo instante, sern activos, lo que permite tratar con el doble de volumen de llamadas simultneas respecto a los esquemas anteriores. En esta nueva arquitectura, los usuarios internos se registrarn y autenticarn en el servidor KAMAILIO interno de la Universidad, mediante una IP Virtual asociada al servidor KAMAILIO activo, ya que la configuracin del cluster de alta disponibilidad va a ser Activo/Pasivo. De esta manera el KAMAILIO interno de la Universidad balancear la carga entre los dos Asterisk disponibles haciendo uso por ejemplo de algoritmos tales como Round Robin, etc.. Para el cluster de alta disponibilidad con KAMAILIO se utiliza replicacin MySQL en lugar de DRBD, ya que toda la informacin referente a KAMAILIO es almacenada en una base de datos. No se ha considerado aadir tambin alto rendimiento en el clster de alta disponibilidad remoto, ya que el volumen de llamadas que puede ser generado por los usuarios externos temporalmente durante el fallo de la troncal se ha considerado que es perfectamente soportado por una nica mquina Asterisk en funcionamiento.

Conclusiones

Se pone en evidencia que si se desea tener un servicio de VoIP fiable, es necesario hacer uso de una solucin de alta disponibilidad. Por lo tanto para aquellas empresas, instituciones, etc, que no consideren el servicio telefnico algo crtico optara por la implementacin mostrada en el primer esquema, ya que por el simple coste de aadir un equipo ms a la arquitectura las ventajas que se consiguen son ms que evidentes. Sin embargo, si en un entorno se realizan un gran nmero de llamadas, es necesario adoptar, adems de alta disponibilidad, soluciones de alto rendimiento. Para cumplir estos requisitos podemos optar bien por el segundo o bien por el tercer esquema. Tal y como se ha presentado, el tercer esquema, ste presenta un inconveniente. Si uno de los Asterisk del queda inoperativo, el rendimiento del sistema VoIP es el mismo que el que podemos conseguir con el segundo esquema propuesto. Sin embargo, el segundo esquema no resulta ser tan escalable como el tercero aunque el volumen de llamadas que se puede conseguir con la segunda opcin es ya de por s muy elevado. Por lo tanto, para aquellos entornos donde el volumen de llamadas es elevado pero no se espera que estas puedan aumentar de manera notable en un corto periodo de tiempo optara por la segunda solucin propuesta. Por ltimo, si se requiere adems de escalabilidad, el tercer esquema es el ms adecuado ya que el rendimiento del sistema VoIP aumenta considerablemente a medida que se van incluyendo nuevos nodos Asterisk en el cluster de alta disponibilidad.