En este artículo, compuesto de 2 partes, cubriré un tema recurrente en instalaciones de Office Communication Server 2007 (R1 o R2), el cual se trata de ¿cómo dar algún nivel de tolerancia a fallos y alta disponibilidad a OCS?

Veamos:  Oficialmente, OCS 2007 soporta Tolerancia a Fallos y Alta Disponibilidad al trabajar con la versión Enterprise del producto, para lo cual se debe implementar por lo menos 2 servidores OCS Enterprise que actúan como Front-End (Conexión de usuarios), por lo menos un servidor SQL en el cual se mantendrán las bases de datos de OCS y un dispositivo balanceador de carga de red (HLB, Hardware Load Balancer).  Para los detalles específicos ver OCS 2007 R2 Enterprise Edition 

En la siguiente figura podemos ver el esquema de un entorno de alta disponilibidad de OCS 2007 R2, soportado oficialmente por Microsoft

Sin embargo, muchas empresas deciden no implementar la arquitectura oficial, debido al costo del Hardware Load Balancer e implementan la versión Enterprise de OCS sin el balanceador.  Es importante destacar que es absolutamente necesario el Balanceador de carga de red si se quiere tener los dos servidores OCS Enterprise ejecutando simultáneamente (que es el objetivo de la implementación de Alta Disponibilidad)

Entonces, ya que la arquitectura de OCS Enterprise sin Balanceador, no ofrece Alta Disponibilidad, nos enfrentamos al problema de que una eventual falla en el servidor OCS, significará la interrupción de los servicios ofrecidos por éste: Mensajería Instantánea, conferencias, Voz sobre IP.

Alta Disponibilidad versus Media Disponibilidad

Si bien el término Media Disponilibidad no existe oficialmente, lo usaré en este artículo como un punto intermedio entre una iterrupción total de servicios con un tiempo largo (sobre 4 horas) en la restauración de estos y un interrupción total de servicios pero restaurados en un tiempo corto (de 15 minutos a una hora)

En el caso de OCS usaremos una metodología no oficial, para ofrecer la capacidad de contar con servicios de OCS en un tiempo corto frente a la falla del servidor OCS  Frontend.

Entonces, trabajaremos con el concepto de WARM Copy, que es un servidor preparado para asumir las funciones del servidor principal pero que no ofrece servicios constantes a la red.

Debemos definir ciertos puntos propios de la arquitectura de OCS.

- Servidor FrontEnd: Servidor que ejecuta los servicios de Mensajería Instantánea, Conferencias, Señalización de Voip, entre otros

- Servidor Backend: Servidor SQL Server que mantiene los datos de configuración de los usuarios, como listas de contactos, además de configuración propia de OCS

- POOL: punto de conexión virtual a un conjunto de servidores FrontEnd de OCS:  Los usuarios se conectan al POOL en lugar de conectarse a los servidores Frontend en particular.

El servidor Frontend tiene su propio nombre e IP, independiente del nombre e IP del Pool.  Sin embargo cada Servidor Frontend debe configurar en su tarjeta de red la ip propia y la del pool.  Este es el punto que requiere el balanceador de carga e impide que dos equipos OCS estén funcionando simultáneamente sin el balanceador, ya que se produce un choque de IP’s en la red.

Implementación de la estructura de Media Disponibilidad

En la siguiente imagen vemos la arquitectura para la implementación de OCS en modo “WARM COPY” (Recuerden, este no es un término oficial)

Los pasos generales de instalación son los siguientes, considerando que ya existe un servidor OCS Enterprise como FrontEnd, un Servidor SQL como Backend, un nombre de POOL y una IP asignada al pool :

1.- Apagar  primer servidor  OCS Frontend

2.- En otro equipo, instalar sistema operativo y requisitos de OCS

3.- Configurar ip particular de este nuevo servidor (debe ser distinta a la ip del primer servidor OCS)

4.- Configurar IP del pool (el servidor quedará con 2 IP’s temporalmente)

5.- Instalar OCS Enterprise asociado al pool que ya existe.

6.- Configurar certificados digitales

7.- Iniciar clientes Communicator.

8.- Probar comunicación.

Es importante recordar que los clientes OCS, es decir Office Communicator, se conectan al nombre del pool y no al nombre del servidor en particular, lo cual facilita esta configuración.

Una vez que las pruebas se han realizado y se ha comprobado que todo funciona bien, se puede apagar este segundo servidor de OCS y volver a iniciar el primero, que actúa como nuestro servidor OCS principal.

Dimensionamiento del OCS Warm Copy

De acuerdo a la cantidad de usuarios que se manejen en la  red de OCS, es posible que el OCS Warm Copy opere como una máquina física similar a la principal o también puede ser un Servidor Virtual

Y que hacemos frente a una falla??

Ok, llegamos al punto importante, nuestra red opera con el servidor OCS Frontend “principal”, que tiene buen Hardware, buena memoria, Raid, tremenda CPU.  Super, pero lo atacó un virus por ejemplo o debemos realizar una mantención y no queremos (… o no podemos) dejar de prestar servicio a nuestros usuarios. 

Bien, falló el servidor y… sólo debemos iniciar nuestra OCS WARM COPY y una vez que suba, los usuarios volverán a tener comunicaciones.  Es posible que no tengan las mismas prestaciones, sobre todo en conferencias, pero vamos a estar arriba dignamente.

A futuro:  en un próximo artículo vamos a detallar la implementación del Warm Copy y mostrar que ocurre con los clientes Communicator, además de implementar un esquema de media disponibilidad que no requiere intervención manual para iniciar el Warm Copym usando máquinas virtuales.

Saludos

Oscar Soto Casali