Cisco Unified Communications Manager 8.5 "Diseño de un Red de Telefonía IP Parte 3 Diseño de un Clúster Clustering sobre la WAN – Failover Remoto"

Cisco Unified Communications Manager 8.5

Diseño de un Red de Telefonía IP Parte 3

Diseño de un Clúster

Clustering sobre la WAN – Failover Remoto

El diseño del clúster comprende el Publisher y un subscriber ubicado en el sitio A y un subscriber instalado en el Sitio B. El esquema de redundancia será 1:1 active/backup con balanceo de carga.

Para proveer disaster recovery y una distribución de recursos más equilibrada a diferentes áreas geográficas los siguientes puntos relacionados a la redundancia del clúster deben ser considerados:

·         La solución no provee un backup de Publisher, en el evento de una falla en el Publisher no pueden realizarse modificaciones en la configuración.

·         El plan es que haya TFTP servers en cada Sitio y aplicar features específicos que permiten un upgrade de firmware de los teléfonos no traumático en caso de upgrade completo.

Clustering sobre la WAN – Failover Remoto

Para cumplir con el requerimiento de proveer procesamiento de llamadas aún si uno de los sitios falla, se configurará un modelo de deployment “Clustering sobre la WAN” con redundancia de procesamiento 1:1 y balance de carga separada entre los servers localizados a través de la WAN.

Failover remoto permite instalar los servers de procesamiento de llamadas separados en la WAN entre Sitio A y Sitio B.

En cada sitio que dependa de estos sitios centrales a través de conexiones LAN, se instalarán Gateways con SRST para mantener los llamados internos en caso de pérdida de conectividad con el clúster.

Algunas características claves serán mantenidas:

·         Único punto de administración para todos los sitios

·         Transparencia de features

·         Shared lines

·         Dial plan unificado

Consideraciones en la WAN

Clustering en la WAN requiere que se cumplan algunas características de diseño, planificación e implementación.

La comunicación Intra-Cluster (ICCS= Intra-Cluster Communication Signaling) entre los servers consiste de muchos tipos de tráfico. Esos tipos de tráfico ICCS se clasifica como tráfico priority o Best Effort. En el primer caso se marca con DSCP 24 o PHB CS3. El tráfico Best Effort se marca con DSCP 0 o PHB BE. Esta marca la realizan los servidores de UC.

Las siguientes condiciones deben ser cumplidas cuando se realiza clustering sobre la WAN:

·         El delay máximo one-way entre dos CallManagers para todo el tráfico priority ICCS no tendría que exceder 20 ms o 40 ms de round-trip (RTT). El delay de otro tráfico ICCS tiene que mantenerse razonable para permitir el acceso a la base de datos y directorios. El delay de propagación entre dos sitios agrega 6 micro-seg por Km, sin considerar ningún otro tipo de delay.

·         El jitter es la variación del delay en el que el paquete puede incurrir a través de la red debido a procesamiento, colas, buffers, congestión o variaciones de delay en el camino. Para el tráfico ICCS priority debe ser minimizado utilizando QoS.

·         La red no debe tener errores o pérdida de paquetes para el tráfico ICCS priority debido a que la pérdida o los errores tendría efecto negativo sobre el procesamiento de llamada dentro del clúster.

·         Ancho de banda: Es necesario suministrar el ancho de banda necesario entre los servers para el volumen de llamadas esperado, tipo y número de dispositivos. Este ancho de banda es adicional a cualquier otro BW para otras aplicaciones que compartan la red incluyendo voice y video. El BW debe tener QoS habilitado para proveer prioritización y scheduling para las diferentes clases de tráfico.

Guías de diseño:

·         Cada 10000 busy hour call attemps (BHCA) entre sitios que tienen clúster sobre la WAN requiere 900 kbps de BW para Intra-Cluster Communications Signaling (ICCS). Este es el mínimo BW requerido y el BW es asignado en múltiplos de 900 kbps.

·         El mínimo recomendado entre sitios que están en clustering sobre la WAN es 1.544 Mbps. Esta cantidad permite un mínimo de 900 kbps para ICCS y 644 kbps para LDAP y otro tráfico inter-server.

·         Entre cualquier dos servers del clúster se permite un Round Trip máximo (RTT) de 40 ms. Este tiempo es igual a 20 ms de delay máximo de one-way, o una distancia de transmisión de aproximadamente 3000 km en condiciones ideales.

La siguiente tabla muestra los puertos utilizados por el tráfico ICCS y las marcas:

Call Manager TCP/UDP Ports

Tráfico	Descripción	TCP/UDP ports	Marking
ICCP	ICCS CTiM CES	TCP 8000 – 2 TCP 8003 TCP 2552 - 1	CS3 CS3 CS3
IBM INFORMIX	Replicación de base de datos entre servers	TCP 1526	Best Effort 0
LDAP	DC Directory replication between all servers	TCP 389, 8404	Best Effort 0
RIS	RIS Data Collector	TCP 2555 – 6	Best Effort 0
SCCP	IP Phone signaling.	TCP 2000 - 2	CS3
H323	H225 RAS GK RAS GK CCM	1720 1719 1718	CS3 CS3 CS3

Cisco ha comenzado a cambiar las marcas de los protocolos de control de voice desde DSCP 26 (PHB AF31) a DSCP 24 (PHB CS3). Sin embargo muchos productos aún marcan con DSCP 26 (PHB AF31), por lo tanto, se recomienda que las reservas de bandwidth consideren ambas marcas. El CallManager 8 usa el nuevo sistema de marcas.

Redundancia de Subscribers

La tecnología de clustering provee redundancia de Call Manager. La redundancia de Call Manager es la habilidad de proveer un server hot standby para el procesamiento de llamadas para todos los endpoints capaces de mover su conexión desde el primario automáticamente en caso de disrupción del servicio.

Se pueden definir hasta tres Subscribers por grupo de CallManagers. El backup tiene que tener la capacidad de soportar los teléfonos registrados de manera primaria a ellos y eventualmente los que se registren cuando deban actuar como backup

En este diseño se utilizará load balancing entre Servers. De esa manera no habrá ningún Servers que sólo actúe en caso de backup sino que todos serán activos de un grupo y backup de otro.

Este modelo permite compartir la carga de procesamiento con lo que se consigue una respuesta más rápida. Al mismo tiempo permite una transición más rápida en caso de falla de alguno de los servers debido a que todos los dispositivos (teléfonos, CTI Ports, Gateways, etc) están distribuidos en todos los subscribers.

Utilizando grupos de redundancias y device pools se puede hacer que los dispositivos se registren en uno de los subscribers mientras que el otro, del otro lado de la WAN actúa como backup y viceversa. Esta distribución debe ser realizada con cuidado de manera que cuando un server responde a sus dispositivos registrados, y a su vez actúa como backup de los dispositivos del otro server en un momento de falla, no se exceda la cantidad máxima de dispositivos que el server puede soportar.

En el caso que ambos servers lleguen a quedar no disponibles se realiza un switch a SRST en los gateways.

TFTP

Como se mencionó anteriormente las funciones principales del TFTP Server son suministrar archivos para los servicios, archivos de configuración para dispositivos como teléfonos o Gateways, los archivos para los upgrades y archivos de seguridad.

Cada vez que un endpoint pide un archivo hay una nueva sesión de transferencia TFTP. En un modelo de procesamiento centralizado el tiempo en completar esa transferencia afecta el tiempo en que un endpoint está listo para operar. Si bien no es el único factor que afecta el tiempo que se toma un endpoint para quedar listo para operar, es un componente importante. El tiempo que toma cada transferencia de archivo vía TFTP es función del tamaño del archivo, el porcentaje de paquetes TFTP que deben ser retransmitidos y la latencia y el round-trip de la red.

Debido a que la latencia y la pérdida de paquetes afecta el tiempo de transferencia de TFTP, es ventajoso tener un TFTP server local. Este server TFTP local podría ser un subscriber local en un modelo de clustering sobre la WAN.

Una alternativa es TFTP Load Server en un router local. Los dispositivos se configuran con una dirección de un server local, que le permite al endpoint bajar archivos pequeños de configuración del TFTP central y obtener los archivos más grandes de firmware de un server local. Este método requiere que el administrador cargue los archivos de firmware en los TFTP servers en cada sitio.

Otro método de upgrade de firmware sin utilizar la WAN excesivamente es utilizar Peer File Sharing (PFS). Con este feature sólo un teléfono de cada modelo baja el nuevo firmware del TFTP central.

Una vez que un teléfono baja el firmware distribuye el archivo a todos los otros teléfonos.

Este método evita la carga manual y la configuración necesaria en los “Load servers”.

El feature PFS trabaja de manera que los teléfonos se ordenan en una jerarquía al momento de hacer el upgrade. Intercambian mensajes entre ellos y seleccionando el root que será quien realice el download desde el TFTP. El teléfono envía el archivo de firmware al segundo teléfono en la cadena mediante TCP, éste lo envía al tercero y así hasta llegar al último teléfono.

La jerarquía se forma por subnet y por firmware de teléfono.

En nuestro caso, se utilizará el modelo de un server TFTP en cada lado de la WAN y el feature PFS. La siguiente figura muestra un esquema del funcionamiento.

Media Resources

Los Media Resources, conferencias, annunciator, transcoders, media termination point (MTP) y MoH pueden ser provistos de un par de maneras dependiendo del tamaño del clúster y de la topología de la solución.

La siguiente es una breve descripción de los servicios:

·         Music on Hold (MoH): Provee MoH unicast o Multicast a los dispositivos que se ponen on hold, se transfieren o son agregados a una conferencia. Debido a que la red de nuestro sitio está integrada a través de la red MPLS que no soporta multicas, en los sitios remotos será entregado por los gateways locales y los archivos de audio se localizarán en la flash de los dispositivos.

·         Annunciator: Provee anuncios en lugar de tonos para indicar números marcados incorrectamente. Este servicio se brinda desde los CUCM servers.

·         Conference bridges: Puede ser basado en software o en hardware, en este caso será suministrado por hardware.

Todos los sitios proveerán recursos de locales por hardware para las conferencias. Las mejores prácticas indican reservar recursos de conferencias para al menos el 5% de la base de recursos.

Los recursos de DSP serán tomados de los Gateways Locales.

·         Media termination point (MTP): provee features para clientes H323, trunks H323 y trunks SIP.

Cisco AS recomienda que el diseño para recursos de media este distribuido equitativamente y tener redundancia a través del clúster. Esto se realiza a través de Media Resource Group List (MRGL) y Media Resource Group (MRG). El ancho de banda de la WAN debe ser tenido en cuenta en el diseño de los recursos de media a través de la WAN.

Music on Hold

MoH provee la música a los usuarios cuando su llamada en puesta on hold, transferida, puesta en park o agregado en una conferencia. Para proveer la mayor calidad de MoH, el archivo de audio utilizará el códec G.711.

La propuesta para este clúster es proveer MoH multicast desde los servers del Sitio 1 y del Sitio 2 solamente, esto significa que serán utilizados sólo por los teléfonos de esos lugares. La distribución de MoH al resto de los sitios y en particular a través de la WAN que no soporta Multicast estará basado en la flash de los servers locales como lo indica la siguiente figura:

Se alcanzará configurando los subscribers con un audio que tiene la misma IP Multicast y número de port que el que se configura en los gateways. Debido a que el stream de audio MoH está viniendo de la flash de los gateways, no es necesario que atraviesen la WAN.

Para lograr esto es necesario que la infraestructura soporte Multicast.

Para tener streams de MoH en multicast desde la flash del Gateway, hay que considerar que se recomienda que el límite del archivo de audio sea de 10 MB que contiene aproximadamente 10 min de audio.

CTI Manager

El CTI Manager se necesita para las aplicaciones que usan TAPI o JTAPI como el IPCC. Las aplicaciones CTI se comunican con un CTI Manager primario y si ocurre una falla utilizarán un backup.

El CTI Manager tendría que ser activado sólo en Subscribers. Se recomienda realizar load-balance a través de varios CTI Managers.

Saludos