Etiqueta: junghanns

  • Sistemas redundantes y Failover, qué son y cómo funcionan.

    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…

    (más…)

  • Alternativa al ZapHFC y mISDN para tarjetas ISDN

    Actualmente, si alguien tiene una tarjeta de RDSI del tipo Billion, Ovislink, etc, habrá observado que dispone de un chip genérico llamado Cologne HFC que permite ser programado por el fabricante para manipular los datos (unos y ceros) de una manera concreta, en este caso, para capturar las tramas RDSI Básicas.

    Billion RDSICada fabricante, además de reprogramar este chipset a su gusto también desarrolla unos drivers o módulos que permitan comunicarse con esta tarjeta. Este es el caso de Junghanns y sus módulos qozap.

    El proyecto mISDN comenzó con el objeto de establecer un estándar de módulos que permitan la comunicación con la mayoría de las tarjetas basadas en este chipset, pero llegar a controlar la gran cantidad de módulos necesarios para permitir esta compatibilidad con tantas tarjetas, hace que mISDN llegue a ser para muchos una operación bastante tediosa e incluso para «no-expertos» es incluso practicable pese a ser, en mi opinión, uno de los mejores sistemas para cualquier tipo de tarjeta RDSI Básica.

    Digium automatizó la instalación de los drivers mISDN para su tarjeta B410P de manera que instalarla sea algo tan sencillo como:

    cd /usr/src/zaptel-x.y.z
    ./configure
    make
    make b410p
    make install
    make config

    Pero para aquellos que tienen otras tarjetas, estos pasos a veces no son suficientes y prueban con alternativas como ‘zaphfc‘ del paquete briStuff o incluso se atreven con CAPI.

    BristuffA diferencia del módulo qozap para las tarjetas Junghanns, el zaphfc, es un módulo de linux ya anticuado (deprecated) y no mantenido más por Junghanns, por lo que muchos se han movilizado para continuar el desarrollo de este módulo aprovechando las ventajas que ofrece que sea un módulo basado en software libre.

    Como alternativas podemos encontrar:

    vzaphfc: http://xorcom-rapid.berlios.de/vzaphfc/
    El parche de Florz: http://zaphfc.florz.dyndns.org/
    Capi-cm:

    Incluso Tzafir (de Xorcom), otra persona que no duerme nunca 🙂 se ha aventurado a continuar con el proyecto briStuff en su propia web: http://updates.xorcom.com/astribank/bristuff/

    Realmente estos proyectos son la prueba que el software libre mantiene el desarrollo y permite evolucionar más rápidamente que el software propietario.