MAESTRÍA EN TELECOMUNICACIONES
UNIDAD II: TEORÍA DE LAS TELECOMUNICACIONES
LEONEL SOLÍS HERNÁNDEZ
Sistemas Redundantes.
Vamos a imaginar que queremos crear un sistema disponible el 99,99…% del
tiempo, porque es un servicio vital para la empresa, porque cualquier pérdida o
corte, puede provocar pérdidas económicas o de cualquier otro tipo.
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.
Sea como fuere, suele ser necesario al menos dos sistemas y los
resultados son muy interesantes. No es un servicio digamos “intuitivo”. 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.
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”…
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.
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 850para 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.
