Nota de Aplicación May 2010 Rev 03

Transcripción

1 Nota de Aplicación May 2010 Rev 03

2 INDEX 1.- ARQUITECTURA GENERAL DE REDUNDANCIA CÓMO FUNCIONA EL DEVICE BACKUP? CONCEPTO DE MAESTRO Y ESCLAVO Funcionamiento del equipo MAESTRO Funcionamiento del equipo ESCLAVO EL CANAL DE SUPERVISIÓN DEL DEVICE BACKUP SEÑALIZACIÓN EXTERNA DEL DEVICE BACKUP Señalización externa para la conmutación de audio Señalización de alarmas asociadas al Device Backup PARÁMETROS DE CONFIGURACIÓN DEL DEVICE BACKUP Parámetros de configuración del equipo MAESTRO Configuración del equipo maestro: Backup Monitoring Control Timeout Configuración del equipo MAESTRO: Direcciones IP de los equipos supervisados y parámetros asociados Parámetros de configuración del equipo ESCLAVO Configuración del equipo ESCLAVO: Direcciones IP de los equipos supervisados y parámetros asociados EJEMPLOS DE CONFIGURACIONES DEL DEVICE BACKUP DEVICE BACKUP EN COMUNICACIONES UNICAST MODO SINGLE DEVICE BACKUP EN COMUNICACIONES UNICAST MODO DOBLE DEVICE BACKUP EN COMUNICACIONES MULTIUNICAST DEVICE BACKUP EN COMUNICACIONES MULTICAST...19 Page 2

3 Para qué sirve el Device Backup? La opción Device Backup de la familia de codecs de audio ProntoNet permite diseñar arquitecturas redundantes donde uno o más equipos supervisan y respaldan a otros tantos equipos de la misma familia en caso de que estos fallen. El concepto de redundancia va asociado al de fallo del equipo supervisado y no de ningún otro factor externo al mismo como podría ser una caída de la línea de comunicaciones o un fallo en la fuente de audio. Este sistema se ha diseñado para trabajar con los modelos estacionarios (standalone) de la familia ProntoNet que normalmente trabajan de forma autónoma y no atendida. Los modelos que soportan la opción de Device Backup son los siguientes: ProntoNet ProntoNet LC Las tarjetas Doris de los modelos Nereus y Nereus One. 1.- ARQUITECTURA GENERAL DE REDUNDANCIA La arquitectura de redundancia puede ser N+K, es decir, pueden coexistir más de un equipo supervisado (N) y más de un equipo supervisor (K). Cada equipo supervisor puede dar respaldo a los mismos equipos, a parte de ellos o a otros distintos, es decir, la configuración es totalmente flexible como se aprecia en la siguiente figura: Page 3

4 Un equipo supervisor no puede respaldar más de cuatro equipos. Page 4

5 2.- CÓMO FUNCIONA EL DEVICE BACKUP? La filosofía de funcionamiento del Device Backup es muy sencilla y permite su puesta en marcha sin grandes esfuerzos. Para se ello se ha diseñado un algoritmo de redundancia capaz de comunicarse con los equipos respaldados una vez que sus direcciones IP son conocidas sin mayores complicaciones de configuración para el usuario. Tan solo será necesario tomar una precaución a la hora de definir la arquitectura de redundancia y es la de separar los equipos respaldados en: Equipos llamantes: originan la comunicación. Equipos llamados: reciben la comunicación. Equipos MAESTROS: Monitorizan y reemplazan a las unidades llamantes. Equipos ESCLAVOS: Reciben las conexiones en el caso de que fallen los equipos llamados. El resto de parámetros se intercambiarán de forma automática por el canal de control establecido por el equipo backup de manera que gestione de forma totalmente automática y transparente al usuario la gestión de los fallos detectados en los equipos respaldados CONCEPTO DE MAESTRO Y ESCLAVO Lo primero que hay que definir es si el equipo que trabaje como Device backup va a hacerlo como Maestro o como Esclavo. Este concepto es clave para que el algoritmo de redundancia funcione correctamente y está directamente relacionado con lo que mencionamos antes sobre si los equipos monitorizados son llamantes o llamados, es decir si desde ellos se estableció o no la comunicación: Page 5

6 El equipo configurado como MAESTRO supervisa solamente equipos llamantes y el equipo configurado como ESCLAVO supervisa sólo equipos llamados. Imagen del menú de configuración del Device Backup Es decir, cuando definamos una arquitectura de redundancia basada en el Device backup deberemos separar los equipos llamantes de los equipos llamados para que todo funcione correctamente. Un equipo supervisor no puede respaldar equipos llamantes y llamados al mismo tiempo Funcionamiento del equipo MAESTRO El equipo MAESTRO se denomina así porque adopta una actitud activa en el algoritmo de redundancia ya que cuando detecta un fallo en uno de los equipos que respalda trata de restablecer la situación inicial siguiendo un protocolo en función de la naturaleza del fallo. Básicamente el algoritmo trata de establecer la comunicación con el equipo remoto cuando el equipo respaldado no es capaz de comunicarse. Page 6

7 Funcionamiento del equipo ESCLAVO Al contrario que el equipo MAESTRO, el ESCLAVO se limita a aceptar una comunicación remota identificando la IP del llamante para determinar a qué equipo está respaldando en ese momento. Por tanto, no es parte activa en la toma de decisiones del algoritmo de redundancia y ello significa que el equipo MAESTRO también interviene cuando se produce un fallo en el extremo de los equipos llamados. Como se observa en el diagrama inferior, el equipo MAESTRO será quien de órdenes al equipo respaldado A para que reintente la conexión con el equipo ESCLAVO remoto. Este modo de funcionamiento es una de las claves para la robustez del algoritmo de redundancia ya que así evita posibles conflictos que podrían originarse si interviniesen simultáneamente dos equipos frente a un mismo fallo. Page 7

8 2.2.- EL CANAL DE SUPERVISIÓN DEL DEVICE BACKUP Cuando un equipo se configura como Device Backup activando dicha funcionalidad desde su página web se anula cualquier otro tipo de funcionamiento y pasa a trabajar sólo como supervisor de aquellos equipos que el usuario define en el menú de configuración de la opción Device backup. Desde ese instante se activa el canal de supervisión, el cual funciona a través de su puerto LAN de Control. A través de este puerto el equipo supervisor se comunica con los equipos respaldados para monitorizar su estado y adoptar los parámetros de configuración de los mismos de manera que se garantice la continuidad del servicio cuando sea necesario sustituirlos. Es de destacar que los equipos respaldados no requieren ningún tipo de configuración para que dicha monitorización tenga lugar. Sólo los equipos maestros y esclavos (no los equipos supervisados) necesitan ser configurados para que funcione el algoritmo de device backup. Es posible poner en marcha equipos supervisores en cualquier momento y sin necesidad de interferir en el funcionamiento normal de los equipos respaldados. Page 8

9 La puesta en marcha se realiza en el equipo supervisor (MAESTRO O ESCLAVO) una vez que se han configurado los parámetros de configuración y las direcciones IP de los equipos a los que se dará respaldo. Para que un equipo pueda trabajar como supervisor en el modo Device Backup deberá tener habilitada su correspondiente licencia: SEÑALIZACIÓN EXTERNA DEL DEVICE BACKUP Hay dos aspectos en la señalización: uno se refiere a la conmutación del audio y el otro a las alarmas asociadas al Device backup Señalización externa para la conmutación de audio El menú de configuración del Device backup permite configurar sus GPO s para señalizar a un dispositivo externo que está respaldando a otro equipo para que tenga lugar la conmutación de audio: Para cada equipo respaldado habrá un GPO dedicado. Page 9

10 Señalización de alarmas asociadas al Device Backup Existe un alarma específica asociada al DeviceBackup llamada Device Backup Active. Los posibles valores que tendrá son: Primary Unit 1: Connecting to remote units Primary Unit 2: Connecting to remote units Primary Unit 3: Connecting to remote units Primary Unit 4: Connecting to remote units Primary Unit 5: Connecting to remote units Supervisor: Replacing Primary Unit x Cuando la alarma salte en un equipo MAESTRO, puede hacerlo con 2 mensajes posibles: Primary Unit x cuando se cae la llamada de un equipo monitorizado. Permanecerá activa hasta que se consiga conectar con algún remoto o no se consiga conectar con ninguno en cuyo caso el supervisor sustituirá al equipo. Supervisor cuando el supervisor sustituya a algún equipo supervisado. En este caso, la alarma permanecerá activa todo el rato (hasta que se cuelgue manualmente). Cuando sea un equipo ESCLAVO, la alarma sólo saltará con valor Supervisor cuando el supervisor sustituya algún a algún equipo supervisado. La alarma permanecerá activa hasta que se cuelgue la llamada PARÁMETROS DE CONFIGURACIÓN DEL DEVICE BACKUP Una vez que tenemos definida la arquitectura de redundancia, es decir, que se hayan definido qué equipos son MAESTROS y cuáles son ESCLAVOS, es necesario configurar los parámetros de funcionamiento del Device Backup. Como ya dijimos anteriormente, son simples y rápidos de introducir. Page 10

11 Parámetros de configuración del equipo MAESTRO Este capítulo describe los parámetros de configuración que hay que utilizar en el equipo MAESTRO Configuración del equipo maestro: Backup Monitoring Control Timeout Primero de todo es necesario definir el time out que utiliza el algoritmo de redundancia para decidir que un equipo está fallando. Este temporizador se lanza cada vez que el equipo supervisor detecta un problema en el equipo monitorizado a través del canal de control del Device Backup. Si el canal de control se cae por motivos ajenos a los equipos se dará lugar a una situación anómala en la cual el equipo supervisor podría intervenir sin motivo. El algoritmo de gestión del Device Backup ha contemplado esta posibilidad y tratará de detectarla de forma que no se interfiera en el funcionamiento de los equipos innecesariamente Configuración del equipo MAESTRO: Direcciones IP de los equipos supervisados y parámetros asociados Equipos Primarios: Son los equipos que el equipo MAESTRO va a respaldar. Máximo 4. Equipos Remotos: Son los equipos remotos a los que están conectados los primarios. Como se ve en el dibujo inferior también Page 11

12 se incluyen los equipos Esclavos que respaldan a los remotos a los cuales se llamará cuando el intento de conexión a los primeros falle. Menú de Configuración: Dirección IP del equipo Primario Direcciones IP del equipo llamado y de los equipos esclavos asociados. Tantas como líneas conectadas. En este campo se indica la línea utilizada por el equipo Primario para comunicarse con el remoto. Page 12

13 Si el equipo Primario trabaja en modo doble o MultiUnicast habrá una dirección IP destino por cada línea de comunicación. Es por ello, que en el menú de configuración de las direcciones IP remotas hay que definir dicha línea. Insistimos en que dicha línea corresponde al equipo Primario y no tiene nada que ver con el parámetro target codec, es decir, la línea por la que se conecta el equipo remoto. Este último parámetro es reconocido automáticamente por el equipo Backup maestro y no es necesario configurarlo Parámetros de configuración del equipo ESCLAVO Este capítulo describe los parámetros de configuración que hay que utilizar en el equipo ESCLAVO. Page 13

14 Configuración del equipo ESCLAVO: Direcciones IP de los equipos supervisados y parámetros asociados Equipos Primarios: Son los equipos que el equipo Esclavo va a respaldar. Máximo 4. Equipos Remotos: De nuevo son los equipos remotos a los que están conectados los primarios pero en este caso tienen una utilidad distinta ya que sirven para que el esclavo reconozca a qué equipo está respaldando cuando reciba una llamada. Menú de Configuración: Dirección IP del equipo Primario. Direcciones IP del equipo llamante y línea del equipo Primario por la que entrará la comunicación. Page 14

15 Las direcciones IP de las unidades remotas deben ser las de los equipos llamantes, es decir sus direcciones IP privadas y no la de los routers que les den acceso a la red WAN. En caso de que la llamada se establezca desde un equipo MAESTRO, éste indicará al equipo remoto ESCLAVO a qué equipo está sustituyendo por lo que no es necesario programar sus direcciones IP en el ESCLAVO. Si el equipo Primario de un backup Esclavo trabaja en modo doble habrá que configurar las direcciones IP de los equipos remotos llamantes indicando la línea del Primario por la que entra la comunicación. Page 15

16 3.- EJEMPLOS DE CONFIGURACIONES DEL DEVICE BACKUP Este capítulo trata de aclarar algunas dudas que surgen debido a la distinta naturaleza de las comunicaciones IP y a que un mismo equipo puede trabajar con varias líneas de comunicaciones simultáneamente. Por ello presentamos ejemplos de comunicaciones Unicast en modo single y Double, MultiUnicast y Multicast DEVICE BACKUP EN COMUNICACIONES UNICAST MODO SINGLE Se trata del caso más simple posible en el que tenemos: Page 16

17 3.2.- DEVICE BACKUP EN COMUNICACIONES UNICAST MODO DOBLE C IP ADDRESS A L1 L2 A IP ADDRESS IP L1 C Bkup Slave C BKUP CTRL BKUP CTRL B A,B Bkup Master L1 L2 D D Bkup Slave BKUP CTRL A IP ADDRESS B IP ADDRESS D IP ADDRESS Main C L1 Backup 1 C Bakup Slave L1 Main D L2 Backup 1 D Bakup Slave L2 Main D Backup 1 D Bakup Slave L1 L1 A IP ADDRESS B IP ADDRESS Page 17

18 3.3.- DEVICE BACKUP EN COMUNICACIONES MULTIUNICAST C IP ADDRESS L1 B B Bkup Slave A IP ADDRESS BKUP CTRL A A,B Bkup Master A IP ADDRESS Main B L1 Backup 1 B Bakup Slave L1 Main C L2 Backup 1 C Bakup Slave L2 Main D Backup 1 D Bakup Slave L3 L3 L3 L1 L2 L1 IP D D Bkup Slave D IP ADDRESS L1 C C Bkup Slave BKUP CTRL BKUP CTRL C IP ADDRESS A IP ADDRESS A IP ADDRESS Page 18

19 3.4.- DEVICE BACKUP EN COMUNICACIONES MULTICAST En las comunicaciones Multicast no existe el concepto de equipo llamante o llamado ya que todos deben conectarse a la dirección del grupo Multicast que corresponda. Por ello se configurarán todos los equipos como MAESTRO y la dirección IP no será la de ningún equipo sino la del grupo multicast al que estén conectados. Page 19