Vamos a imaginar que queremos crear un sistema disponible el 99,99…% del tiempo, bien porque es un servicio vital para la empresa, bien porque cualquier pérdida o corte, puede provocar pérdidas económicas o de cualquier otro tipo. ¿Qué hacemos entonces?

Para eso se suele configurar lo que se denomina un “sistema redundante”, es decir dos o más sistemas configurados de forma que uno de ellos sea el que está en funcionamiento, y en el caso en que deje de funcionar por cualquier motivo, se active otro de los sistemas que hasta ese momento estaba “en espera” o “inactivo” tan rápidamente como sea posible. Mediante este sistema, incluso en el peor de los casos (la rotura de un disco duro, un desbordamiento de memoria que mate un proceso vital, o incluso que alguien le pegue una patada al cable) puede seguir funcionando gracias al siguiente equipo hasta entonces “dormido”.

Linux ya cuenta con muchas herramientas de este tipo, y seguramente cualquier usuario que trabaje con Asterisk o con cualquier otro servicio importante ya conocerá algunas herramientas como Heartbeat, Corosync, PeaceMaker, etc… son las más utilizadas. No obstante, hay quien prefiere utilizar virtualización para dotar al sistema de una “seguridad”, por lo menos a nivel lógico (poco se puede hacer si el servidor que hospeda las máquinas virtuales se quema por una subida de tensión), pero aún así siempre se puede poner un servidor de máquinas virtualizadas en modo redundante (la cosa se empieza a complicar… pero es muy, muy seguro).

 

Sea como fuere, suele ser necesario al menos dos sistemas y los resultados son muy interesantes. No es un servicio digamos “intuitivo”, pero siguiendo cualquier tutorial que se puede encontrar en Internet, es bien sencillo hacer tu primera prueba. Con el tiempo, configurar un sistema redundante es algo que se hace ya casi de forma automática.

En sistemas de comunicaciones basados en Asterisk es muy interesante esta técnica de redundancia, ya que (por ejemplo) un callcenter basado en un único sistema, en caso de que la tarjeta de red deje de funcionar, tendríamos a varias personas completamente paradas y todo el tiempo en que se encuentran paradas, son pérdidas de todo tipo: económica, productivas, tiempo, etc… por lo que un callcenter que dependa de una única máquina es realmente un riesgo muy, muy grande.

No obstante, si aún así contamos con dos máquinas configuradas en modo redundante (por si a alguna le da por dejar de funcionar), nos encontramos con un problema extra: las líneas de comunicaciones.

Si utilizamos proveedores IP, o gateways, igual el problema no es tan grande pero viene por otro lado (pérdidas de la conexión a internet, dependencia del tráfico del proveedor, latencia, necesidad de más ancho de banda,…), pero si utilizamos líneas de primarios, analógicas o RDSI básicas, la complejidad es diferente… ¿cómo conectamos las líneas a ambas máquinas de forma que, en caso de una parada del sistema principal, se conecte automáticamente al siguiente sistema? Vamos a ver qué soluciones encontramos…

Alta Disponibilidad de Redfone

La empresa RedFone dio con una solución perfecta: En lugar de utilizar una tarjeta en cada servidor y cambiar las líneas de una tarjeta a otra cuando el servidor deje de funcionar, vamos a “sacar” la tarjeta del servidor y a través de la red ethernet, vamos a enviar la información de las líneas al sistema que más nos interese. Esta solución es realmente ideal: fácil, económico y muy eficaz. El único inconveniente es que este sistema únicamente sirve para líneas de primarios, y no para líneas RDSI Básicas o analógicas.

Página del producto: http://www.red-fone.com/products-new/67.html

Failover de Junghanns

Junghanns dió con otra solución, no tan buena como RedFone pero que cubre las necesidades de “cambiar las líneas de un servidor a otro cuando el principal deja de funcionar”, para ello empezaron a comercializar lo que se conoce como un “Failover” un dispositivo que, conectado al sistema principal, conecta las líneas de comunicaciones a los puertos de las tarjetas. Si el sistema principal deja de funcionar, el “Failover” deja de recibir la información necesaria y automáticamente conecta las líneas al servidor secundario. Este sistema sí soporta RDSI Básicas además de RDSI de Primarios, pero es menos económico que un Redfone al requerir, además del “Failover”, que cada servidor tenga una tarjeta de comunicaciones instalada y configurada. Otro inconveniente es que la “señal” que el servidor principal debe enviar al Failover para indicar a dónde tiene que conectar las líneas, se envía mediante un conector “serie”, algo que hoy día pocos servidores tienen pese a que existen adaptadores USB/RS232. Quizá por la seguridad que ofrece un puerto serie, es en la opinión de muchos expertos, una gran baza frente a otros failovers que funcionan mediante USB, o paquetes IP que pueden perderse, o que tienen otros puntos de fallo como un bloqueo eventual del switch, … por lo que este dispositivo es bastante robusto y quizá, demasiado “artesanal”… 🙂

Página del producto: http://www.junghanns.net/en/ISDNguard_produkt.html

Failover de Beronet

Beronet tomó la idea de Junghanns y creó otro “Failover”, de igual funcionamiento pero además soportaba líneas analógicas, configurador web para indicar el modo de funcionamiento, y en lugar de enviar la señal por el puerto serie, utiliza un puerto de red RJ45, su dirección IP, máscara de red, etc… La pega… ¿qué ocurre si cae el switch al que está conectado el failover? Podemos conectar el failover a una tarjeta dedicada en el servidor principal… La posibilidad de tener un Failover “mixto” (unos puertos con líneas analógicas, otros puertos con líneas RDSI Básicas y otros de primarios) además de utilizar un puerto de red en lugar de un puerto serie lo ha hecho el ideal y uno de los mejor valorados hasta el momento.

Página del producto: http://www.beronet.com/product/failover-switch/

Failover de Digium

Hace unos días Digium ha hecho público el lanzamiento de dos dispositivos nuevos, dos sistemas de “Failover” similares a los de Junghanns y Beronet, llamados Series R 800 para líneas analógicas y Series R 850 para líneas RDSI Básicas y Primarios E1/T1. El funcionamiento es prácticamente igual que el de Junghanns y Beronet pero con unas ligeras diferencias:

  • Soportan hasta 8 líneas (analógicas/RDSI Básicas/RDSI Primarias) en lugar de las 4 que soportan los failovers de Junghanns y Beronet.
  • La señal Watchdog que informa de que el servidor principal está funcionando correctamente, viaja por USB (en lugar de por puerto serie o de red)
  • El mismo puerto USB que envía la señal Watchdog, se encarga de alimentar el Failover (no es necesario un cable externo de alimentación).
No obstante, sigue siendo necesario disponer de las tarjetas de comunicaciones, algo que nos ahorraríamos con un Redfone, pero si queremos hacer redundancia de líneas analógicas, RDSI Básicas, además de Primarios… es necesario estudiar más posibilidades.

Para más información: http://www.digium.com/en/products/failover/r800/#overview

17 Comentarios

  • Como dices las soluciones que no incorporan tarjetas son más caras, pero sólo en caso de que empieces y necesites comprar todos los equipos.
    Si ya tienes las tarjetas es más barato comprar una de las soluciones tipo Junghanns.

    El failover de Digium parece interesante por lo que ofrece y el precio.
    Aunque la mayoría está enfocado a Asterisk imagino que podrán funcionar con cualquier sistema. El watchdog verá los circuitos caídos y enrutará el tráfico por los backup.
    ¿Es así? ¿Crees que por ejemplo el de Digium sirve para cualquier sistema?

    Gracias por la info, como siempre 😉

    • Aún no lo he probado, no se muy bien qué tipo de “señal” hay que enviar y cómo enviarla. Equipos como el de Junghanns y el de Beronet disponen de un módulo propio en Asterisk, de forma que si la aplicación Asterisk “cae”, el failover “salta” al servidor secundario.

      No obstante también incorpora aplicaciones “demonio” que pueden ser utilizados sin Asterisk.

  • También se pueden usar gateways de lineas Analógicas/RDSI a SIP configurados contra la IP “enmascarada” del mecanismo de redundancia (heartbeat o lo que sea).

    Cuando el servidor principal cae, se traspasa esa IP al secundario, y a partir del entonces el gateway manda los paquetes al servidor secundario y no se entera del cambio. No necesitas ninguna señal adicional.

    • Utilizar un Gateway es otra forma de hacer redundancia de líneas, el problema puede venir cuando el gateway se rompe por algún motivo (el transformador, un firmware en mal estado, etc…) ¿qué pasa con las líneas que están conectadas al gateway? ¿cómo las cambias a otro posible gateway?

      • Sí, está claro que para eso no hay solución. Pero eso también pasa con el Redfone (también se puede romper).

        Yo creo que dejando de lado el hecho de que el concepto de equipo es diferente, la solución con un Redfone o con un gateway SIP es igual en cuanto a funcionalidad y “riesgo”. Eso sí, el Redfone es más barato que los gateway, pero por otro lado el cambiar un gateway sip es más fácil que un redfone, ya que el gateway sip le puedes tener preconfigurado e incluso instalado y con cambiar los cables basta (hasta el cliente lo podría hacer), pero si cambias un redfone por otro nuevo tienes que tocar la configuración en el servidor (aquí hablo de memoria, pero por lo menos la nueva MAC, ¿no?). Si el dinero no es un problema para el cliente, yo me iría al gateway por comodidad, si no, la solución de redfone está genial (ahora hasta lo puedes virtualizar y crear gateways sip virtuales).

        Los otros equipos de failover no los conozco, y no sé que probabilidad de fallo tienen o qué pasa cuando fallan, así que no hablo para no meter la pata… 😉

      • Para mi única opción valida es la de los gateways, tipo los de dialogic (los que conozco mejor).
        Permiten hacer repartición de carga, detección automatica de caída de los asterisks (o servicio SIP para ser exacto), poder quitar en caliente un asterisk del pool activo (cosa que no se puede hacer con los redfones o otros: pierde todas las llamadas activas de este momento).

        Además si falla, por ejemplo la alimentación del gateway, existe un bypass de los primarios hacia bocas de bypass. (Eso por lo menos con los de 4 primarios). El inconveniente es que puede usar 2 lineas en lugar de los 4 disponibles…

        Fallo de actualización de firmware? Quien hace una actualización en un aparato de esto en producción si te va bien?

        Otro problemas de los redfones es con son caja “negra” : no puedes configurar perfectamente los primarios, sobre todo si va mezclando los proveedores en el mismo redfone. Cuantos problemas con los famosos “HDLC Bad FCS (8) on Primary D-channel of span X”.

  • Pero que sentido o cual es la ventaja que tiene este failover de digium u otro en comparacion con redfone, si igual necesito comprar placas?

    Supongamos que yo ya tengo un sistema en produccion con 4 E1 (una placa Digium de 4E1) y quiero agregar un sistema de cluster, deberia comprar:

    A) Un RedFone de 4 y la placa que ya tengo me queda en el armario. $2400
    B) Comprar una placa Digium de 4 y comprar un SR850. $3400

    Es decir, economicamente sirve mucho mas red-fone, no? que ventaja me trae las placas y el SR850…. tanto el redfone, como las placas, como el SR850 se pueden romper, todo se puede romper

  • Todo puede fallar… la idea es siempre minimizar el riesgo…

    Los Redfone tienen muchas ventajas, la más llamativa para el usuario suele ser la ventaja económica, que ocupan menos espacio que un failover (esto puede parecer una tontería pero es importante) que hay la mitad de posibilidades que se rompa un Redfone a que se rompa una tarjeta de uno de los equipos (hay dos equipos, 2 tarjetas vs 1 redfone = mitad de posibilidades) y que, una vez que sabes cómo funciona un foneBridge2, es muy, muy cómodo.

    Yo expongo las posibilidades, uno ya tiene que pensar qué ventajas le supone una solución u otra. ¿y si tu cliente mañana quiere instalar una RDSI Básica? ¿o 5 líneas analógicas? ¿o trabajar con 16 primarios en un mismo servidor?

    Todo tiene sus ventajas y sus inconvenientes… yo expongo ambas y luego cada uno debe pensar qué es más ventajoso. 🙂

  • Estimados: No olviden la redundancia de Xorcom! Twinstar es muy bueno! Failover automático vía USB, en caso de que falle el server.
    Saludos!
    Mariano.

    • Cierto, ni lo conocía… Xorcom no es muy conocido en España y no se muy bien porqué… pero es otra opción a estudiar.

      • Hola Elio,
        Estuve mirando su web y me parece muy interesante y enriquecedor.
        En España Xorcom ha hecho su ingreso durante 2011. Se puede obtener por intermedio de Jesatel Comunicaciones de Madrid (www.jesatel.com).
        Le dejo un comparativo que ha hecho Xorcom con las versiones R: http://blog.xorcom.com/?p=538
        Gracias y saludos!
        Ariel

  • Xorcom es ya un equipo completo, vaya no requiere que tengas un asterisk, este ya es un servicio como tal. Y la verdad compite bastante con un asterisk a medio nivel.

    Por cierto saludos Mariano, nos conocimos en Mexico en un dCAP

  • Mejor cuando tienes una troncal SIP con tu proveedor y la conectas al SW así podes hacer tu propio sistema redndante con 2 servidores fisicos, por ejemplo monitorear las interfaces y enviar mensajes entre ambos servidores con scapy(http://www.secdev.org/projects/scapy/), detrás una lógica para saber cuando esta vivo el uno o el otro, incluso cuando falla la troncal SIP…..y muchas otras más cosas que te podrás imaginar..SALUDES!

    • En muchos países, una caída momentánea de Internet es algo bastante frecuente por desgracia…

  • No he visto ningun comentario acerca de el modo TX-TRI STATE, con las tarjetas sangoma. (http://wiki.sangoma.com/wanpipe-txtristate). La han tenido en cuenta como alternativa para redundancia o fail over?. La replicación de las bases de datos haciendolo desde MySQL con el modo maestro-esclavo y heartbeat 3 tomando control de los servicios necesarios es uno de los mejores escenarios que existen; de todas maneras DRBD ha avanzado mucho desde su famosa version 8.3 que usabamos en la mayoria de los tutoriales disponibles. En el caso de los primarios, el modo TRISTATE es solo un parametro configurable en el archivo wanpipex.conf, pero el punto es que hay que tener dos tarjetas (una en cada servidor del cluster) y un splitter entre la interfaz del PRI y las dos tarjetas. La solución es mas costosa que un solo redfone, pero realmente elimina el riesgo de depender de un solo gateway. Solo es un punto de vista. Los redfone son una solucion interesantisima. De hecho en una de mis instalaciones con estos equipos en el año 2009, junto con Mark Warren y su equipo,la gente de Palosanto Solutions (en ese tiempo trabajaba bastante con Elastix…) y la mía, descubrimos el siguiente bug, documentado en el portal de soporte de redfone, y nos tomó varios días poder declarar oficialmente en produccion el sistema entero por esto:

    http://support.red-fone.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=34&nav=0

    Salu2.

    • No, el sistema txtristate de Sangoma es similar al de un failover salvo que se elimina la necesidad de un dispositivo que balancee los primarios de un servidor al otro, aunque a cambio hay que activar la configuración para obtener la señal del primario.

      Al principio de los productos, es normal encontrarse con bugs que no han sido detectados en el proceso de fabricación, sobre todo si este es “externo” al propio desarrollo de la gente de Redfone (bastante ya tienen con desarrollar los módulos y el hardware para que todo vaya como la seda, como para preocuparse de errores que pueden producirse por descargar el dahdi sin haber descargado el fonulator y sin haber “cortado” el flujo de datos del foneBridge2 a la tarjeta de red). Hoy día esto está sobradamente resuelto y montar un sistema redundante con Redfone es (para los que ya conocemos el producto mínimamente) bastante rápido y sencillo.

      • Ok..lo que quise expresarte es que ese bug especifico se descubrió en esa implementación. Ya no existe esa restriccion. Y en mi opinión, el uso de el hardware sangoma con esa funcionalidad activada, es una alternativa para los que necesiten tener un sistema de Alta disponibilidad utilizando tarjetas pci, en el caso de querer minimizar la posibilidad de falla del gateway de primarios.

        Salu2,

Archivos

© 2014 Sinologic, inc. All rights reserved.

Menú

Redes sociales