InConcert HA Manual de usuario

Alta Disponibilidad Pgina 1

ndice
1. 2. 3. INTRODUCCIN...................................................................................................................... 3 DESCRIPCIN DE LA ARQUITECTURA DE LA SOLUCIN ............................................................ 4 CLUSTER SERVIDORES WINDOWS ........................................................................................... 7 3.1 Service Group SQLServer .................................................................................................. 9 3.2 Service Group MWServer ............................................................................................... 13 4. 5. 6. 7. REPLICACIN DE DATOS ....................................................................................................... 15 MEDICIONES Y ALARMAS EN LIVE MONITOR ......................................................................... 18 CLUSTER SERVIDOR PBX ....................................................................................................... 20 OPERACIN DE LA PLATAFORMA .......................................................................................... 24

Alta Disponibilidad Pgina 2

1. Introduccin
En este documento se explicarn los conceptos necesarios para la operacin de la plataforma inConcert HA (Alta Disponibilidad), esquema que provee al sistema de tolerancia a fallos, llevando al mnimo posible los tiempos de inactividad no planificados (downtime). Las posibles causas del downtime no planificados incluyen las fallas de potencia, de hardware, fallas de red, fallas a nivel de sistema operativo y fallas de aplicativos. Ante cualquiera de estas causas un sistema High Availability es capaz de continuar brindando servicios mediante la utilizacin de servidores de contingencia que toman el control suplantando al equipo daado. Como primer paso se har una descripcin de la arquitectura utilizada, explicando cmo reacciona el sistema frente a las diferentes fallas. Luego se presentarn las herramientas de manejo de la plataforma, as como tambin las diferentes estructuras a travs de las cuales se realiza el monitoreo y control de la misma. Se explicarn tambin los pasos para seguir para realizar correctamente maniobras de mantenimiento o respuestas ante fallos. En caso de necesitarse informacin ms detallada sobre el manejo de la plataforma HA se puede consultar la documentacin de Veritas SFW, as como tambin el manual de inConcert Live Monitor, disponibles en los siguientes enlaces: http://www.symantec.com/business/support/documentation.jsp?language=english&view=man uals&pid=56805 http://kbase.inconcerthelpdesk.com/index.php/Live_Monitor

Alta Disponibilidad Pgina 3

2. Descripcin de la arquitectura de la solucin

La plataforma de inConcert consta de tres servidores independientes que interactan entre s, cumpliendo cada uno de ellos a cabo una funcin especfica: Server BD: Es el servidor de Base de Datos. Funciona con el sistema operativo Windows Server 2003 y utiliza el motor de base de datos Microsoft SQL Server 2005. Las bases de datos de inConcert se almacenan en un volumen dedicado, alojado en los discos duros locales de este Server, los cuales se configuran en arquitectura de RAID, para brindar redundancia en los datos. Server MW: Es el servidor de aplicaciones. Funciona con el sistema operativo Windows Server 2003 y es donde residen los distintos servicios de InConcert a los cuales se conectan los clientes. Server PBX: Es el servidor de comunicaciones. Funciona con el sistema operativo CentOS y es quien provee las interfaces y el enrutamiento para todas las comunicaciones, ya sean de telefona TDM, analgica, VoIP, Fax, Voicemail, etc. Estos tres servidores funcionan en conjunto para proveer los servicios a los clientes. La solucin de Alta Disponibilidad contempla duplicar la arquitectura de modo de proveer redundancia y tolerancia a fallos, reduciendo al mnimo posible los tiempos de inactividad. Para ello se utilizan dos nodos, cada uno de los cuales tendr su Server BD, MW y PBX, como se observa en la Imagen 1. Cada uno de los servidores BD almacenar la informacin en volmenes definidos en sus discos duros locales, entre los cuales se realizar constantemente una replicacin de datos, manteniendo dichos volmenes perfectamente sincronizados en todo momento. En situacin normal, el nodo A (que consta de los servers MW A, BD A y PBX A) se mantendr activo, brindando servicios a los clientes, los servidores del nodo B se mantendrn en modalidad pasiva y la plataforma inConcert HA monitorear constantemente el correcto funcionamiento del sistema en todos sus niveles. Los datos generados se almacenarn en el volumen A, y sern instantneamente replicados hacia el volumen B, mantenindose siempre la sincronizacin entre ellos.

Alta Disponibilidad Pgina 4

En caso de detectarse una falla critica, en cualquiera de los servers/servicios del nodo A, se llevar a cabo el proceso denominado Failover, en el cual los servidores del nodo B (que consta de los Server BD B, MW B y PBX B) pasarn a cumplir el rol activo de manera de sustituir al/los servers que fallaron. Dado que existe una replicacin constante de datos entre los servers BD, en el caso de producirse un Failover, la plataforma continuar trabajando en la situacin previa a la falla y de manera transparente para los clientes, utilizando para ello la informacin contenida en el volumen B. Una vez solucionado el inconveniente que desencaden el Failover, se procede a devolver el control al nodo A (proceso denominado Failback) y la plataforma quedar nuevamente en la situacin inicial.

SERVIDOR DE DOMINIO

NODO A REPLICACIN

NODO B

VOL A
HEARTBEAT

VOL B

BD A

MW A
FAILOVER ACTIVO

MW B

BD B

PASIVO

NODO A ACTIVO
DIRECCIONES IP PBLICAS

PBX A
NODO B

FAILOVER

PASIVO

CLIENTES

PBX B

Imagen 1 Topologa de la plataforma

Alta Disponibilidad Pgina 5

Los distintos servidores del Cluster se encuentran comunicados entre s, y actualizando constantemente la informacin sobre el estado de cada uno. Para ello se utilizan seales de heartbeat, las cuales se distribuyen utilizando el protocolo de comunicacin LLT (directamente sobre Ethernet), y a travs de (al menos) dos interfaces de red por cada servidor, de manera de proveer redundancia ante posibles fallas de comunicacin entre los nodos. El sistema inConcert HA es capaz de responder ante distintos tipos de fallas o eventos definidos y tomar acciones segn el caso que se presente, para esto es posible configurar diferentes tipos de mediciones y monitoreos en varios niveles de la plataforma (hardware, conectividad, telefona, base de datos, servicios, etc). En caso de detectarse una falla que se considere crtica para el sistema (por ejemplo un servicio cae y arroja un error al intentar iniciarlo nuevamente), se procede a realizar el proceso denominado failover, en el cual se le traspasa el control de los servicios hacia los servidores de contingencia, haciendo previamente el intercambio de las direcciones IP pblicas. De esta manera el cambio resulta transparente para los clientes que acceden a la plataforma, a menos del downtime que ocurre durante el desarrollo del failover. Debido al requerimiento de mantener un orden determinado en el inicio de los servicios y bases de datos de inConcert, para el caso de los servidores BD y MW es necesario realizar el failover de manera conjunta, es decir que de producirse una falla en cualquiera de ellos, el pasaje del control hacia el nodo B se debe hacer en ambos, independientemente de si la falla afecta uno o ambos servidores. Esto ltimo no sucede para el caso de fallas en el servidor PBX, el cual puede provocar un failover local, sin la necesidad de modificar el nodo activo en ningn otro server. Es condicin necesaria para la implementacin de esta solucin que todos los servidores Windwos que integren el Cluster se encuentren registrados dentro de un mismo dominio, debido al manejo que realiza Veritas de los permisos de acceso para una comunicacin segura.

Alta Disponibilidad Pgina 6

3. Cluster servidores Windows

El manejo y configuracin de los recursos de bajo nivel del Cluster (acceso al Storage, volmenes, placas de red, motor de base de datos), as como tambin el proceso de failover se realiza y monitorea a travs del software Veritas Cluster Server. Se puede utilizar remotamente la consola de manejo (Java Console) para efectuar tareas de soporte, utilizando como direccin de acceso cualquieras de las IP privadas de los servidores pertenecientes al Cluster. A continuacin se mostrarn algunas capturas de pantalla de la aplicacin, en donde explicarn los comandos de uso bsico. El caso corresponde a una plataforma con la configuracin de un Cluster para inConcert HA.

Imagen 2 Sumario del Cluster

En la pantalla inicial de la consola se muestra un sumario de los nodos presentes y el status de cada uno de ellos, aqu particularmente se aprecia que los server BD (INCC-APP-A) y MW (INCC-DBA) del nodo A se encuentran activos y sin alarmas presentes (Online). El panel navegador de la parte izquierda muestra todos los Clusters a los que pertenece el servidor al cual estamos conectados. En el caso de inConcert HA, hay un nico Cluster definido llamado InConcertCluster, dentro de l se pueden ver los tres Service Groups definidos (MWServer, SQLServer y

Alta Disponibilidad Pgina 7

Replication, uno por cada tipo de servidor), y los Resources que hay dentro de cada uno agrupados por categora(GenericService, IP, NIC, etc). Estos ltimos son los que realizan el monitoreo de cada elemento particular del servidor. Luego se har una descripcin ms detallada de cada uno de ellos.

Imagen 3 Conectividad del Cluster

La imagen 3 muestra el status de las conexiones entre los servidores pertenecientes al Cluster, se puede ver que los dos puertos utilizados para el heartbeat en cada uno de ellos presentan enlaces correctamente levantados. Como ya se mencion anteriormente, cada uno de los tipos de servidor presentes (MW y BD), se encuentran representados con su respectivo Service Group, en el se definen las caractersticas propias de cada grupo y se configuran los distintos elementos (Resources) a monitorear. Se har a continuacin un explicacin de los dos casos utilizados para inConcert HA en una arquitectura de redundancia MW + BD. El manejo de la replicacin de datos utiliza un Service Group independiente y ser explicado posteriormente.

Alta Disponibilidad Pgina 8

3.1 Service Group SQLServer

Si se ingresa en el navegador al Service Group de SQLServer se visualizar un sumario de los distintos elementos que lo constituyen y el estado de cada uno, como se observa en la imagen 4.

Imagen 4 Sumario del Service Group SQLServer

En la pestaa de Resources se pueden ver las relaciones entre los elementos y el orden jerrquico que estas respetan, as como tambin el estado de cada elemento. Esto ltimo se visualiza en el color del icono, un elemento en estado OFFLINE tiene color gris, mientras que uno ONLINE es azul, un elemento en estado FAULTED (luego de una falla), figura con una cruz roja encima del icono. Un elemento que se encuentra en estado ONLINNG muestra una flecha apuntando hacia arriba, mientras que uno OFFLINING la tiene hacia abajo. Se puede visualizar el estado de cada uno de los servidores pertenecientes al Service Group haciendo click en su correspondiente botn ubicado en la parte inferior de la pantalla, en caso de seleccionarse SQLServer se mostrar el estado del miembro que se encuentre ONLINE u ONLINING.

Alta Disponibilidad Pgina 9

Imagen 5 Diagrama de Resources del Service Group SQLServer

Se puede modificar el estado de cada Resource desde la consola, as como tambin el del Service Group completo, esto es, pasar a ONLINE u OFFLINE cualquier elemento. Hay que tener en cuenta que se debe respetar la jerarqua de los elementos, o sea, para levantar un elemento cualquiera, deben encontrarse activos todos los elementos que estn por debajo de l, en el mismo servidor. De igual manera si se quiere detener un resource deben encontrarse OFFLINE todos los que estn por encima de l. A nivel de Service Group la regla que debe respetarse es que solo puede existir un miembro del grupo en estado activo, esto implica que en los servers que se encuentran en stand by, todos los resources deben estar en estado OFFLINE. Para efectuar una accin sobre un elemento o Service Group se debe presionar click derecho sobre l, y seleccionar el servidor donde se desea realizar la accin. En la imagen 6 se muestra el caso de intentar pasar a OFFLINE el Resource SQLServer-ClusterService en el server INCC-DBA.

Alta Disponibilidad Pgina 10

Imagen 6 Accin Offline sobre un Resource del servidor INCC-DBA

Otra cuestin que se debe tener presente es que un elemento debe ser estar probado antes de poder activarse en primera instancia, para chequear que su configuracin sea consistente, para eso existe la accin Probe. Los elementos no probados o que presentan problemas de configuracin muestran un signo ? encima del icono. Para el caso de los Service Groups se dispone tambin de la accin SWITCH, la cual realiza un OFFLINE completo del server que se encuentra activo y traspasa el mismo estado al servidor que se haya seleccionado como destino.

Alta Disponibilidad Pgina 11

A continuacin se presenta la lista de los Resources presentes en este Service Group y la funcin que cumple cada uno de ellos. NIC

Este elemento monitorea el estado de la placa de red donde se montan las IP de servicio (tanto la privada como la pblica). En caso de producirse una prdida del enlace o una cada del hardware de red, este es el Resource que mostrar la falla. IP

Monta la IP pblica (flotante) a utilizarse en cada tipo de server (MW y BD) hacia el exterior del Cluster y monitorea posibles conflictos. Lanman

Gestiona la autenticacin de permisos de usuario con el servidor de dominio, a travs de los cuales los servidores interactan entre s de manera segura. RVGPrimary

Habilita la replicacin de datos, manejada por el Service Group Replication, colocando el nodo en el que se levanta el Resource como primario y el offline como secundario. MountV

Realiza el attach al servidor de los volmenes utilizados para las bases de datos, los cuales a su vez se incluyen dentro del DiskGroup previamente importado. SQLServer

Es el encargado de iniciar, detener y monitorear el servicio SQL Server 2005. SQLAgService

Es el encargado de iniciar, detener y monitorear el servicio SQL Agent. ClusterService

Este Resource es la interfaz a travs de la cual interactan Veritas e inConcert, al levantarse provoca que todos los servicios de inConcert ubicados en el nodo seleccionado se inicien en el orden correcto para su funcionamiento, de la misma manera cuando se detiene este Resource se provoca la baja ordenada de los mismos. Cuando inConcert decide realizar un failover detiene este servicio, lo cual posteriormente provoca un pasaje a FAULT en el Resource y esto termina desencadenando el Failover ordenado de la plataforma.

Alta Disponibilidad Pgina 12

3.2 Service Group MWServer

El uso del Service Group MWServer es completamente anlogo al caso anterior (SQLServer), pero dado que estamos ante un servidor que nicamente aloja servicios, su funcionamiento desde Veritas es ms sencillo. Se puede apreciar que carece de elementos referidos a SQL y manejo de unidades y volmenes, en cambio nicamente realiza controles y monitoreo a nivel de placa de red (NIC), intercambio de la direccin IP pblica (IP) y manejo de los servicios de inConcert a travs del Resource ClusterService. A continuacin se muestra el sumario correspondiente a este Service Group, as como tambin su diagrama de Resources. El manejo de los elementos es completamente anlogo a lo explicado anteriormente

Imagen 7 Sumario del Service Group MWServer

Alta Disponibilidad Pgina 13

Imagen 8 Diagrama de Resources del Service Group MWServer

En el caso de realizarse una accin SWITCH para este grupo, sta no solo impactar en el Service Group en cuestin, sino que forzar a un switcheo ordenado entre los servidores BD (SQLServer), dado que inConcert HA incluye una serie de scripts que reaccionan como trigger ante estos casos, de manera de mantener constantemente la consistencia entre los nodos A y B del Cluster. Esta es entonces la manera de realizar un failover manual, el orden de los eventos es: Se detiene MW-A y luego BD-A, a continuacin se inicia BD-B y luego MW-B. Los mismos scripts mencionados anteriormente son los que garantizan el correcto orden de detencin e inicio durante un failover automatico (falla crtica) y se encuentran alojados en la carpeta C:\Program Files\Veritas\cluster server\bin\Triggers de cada servidor.

Alta Disponibilidad Pgina 14

4. Replicacin de datos
Para implementar la replicacin de datos se utiliza el software Veritas Volume Replicator, el cual forma parte de Veritas Storage Foundation. Las bases de datos a replicar se encuentran almacenadas en volmenes independientes al sistema operativo y dedicado a dicho propsito. Cada vez que ocurre una transaccin en ellas, esta informacin es instantneamente almacenada en un log de replicacin y seguidamente enviada al volumen secundario mediante una interfaz de red independiente, de manera de optimizar el ancho de banda y no afectar el servicio. Para gestionar los recursos de la replicacin, as como tambin el manejo de los discos duros y volmenes de los servidores BD, se debe utilizar la aplicacin Veritas Enterprise Administrator, iniciando sesin con la direccin IP del servidor BD A. Una vez dentro de la consola se debe seleccionar la opcin vea://Replication Network/ disponible en el combo Select Host, como muestra la imagen 9.

Imagen 9 Veritas Enterprise Administrator, pantalla inicial

Alta Disponibilidad Pgina 15

Una vez dentro (imagen 10), se podrn monitorear y configurar los diferentes recursos de la replicacin, como por ejemplo el ancho de banda mximo, la modalidad de replicacin (sincrnica o asncrona), la proteccin contra overflow, consultar los datos histricos de uso de la red, etc. En una situacin normal el status debe encontrarse como Active y el Replicator Log debe mantenerse cerca del 0%, pudiendo el mismo crecer espordicamente y luego volver a descender. Haciendo click derecho sobre el host secundario (el que tiene un icono verde) se puede detener y pausar la replicacin, por ejemplo para realizar tareas de mantenimiento de la red. Si s detiene la replicacin, ser necesario realizar una nueva sincronizacin de volmenes para reanudar el proceso (la cual puede durar varias horas). En el caso de pausar, no ser necesario re sincronizar, en tanto no se produzca un overflow del replicator log (se alcance el 100%).

Imagen 10 Veritas Enterprise Administrator, configuracin de la replicacin

La forma de integrar la replicacin de datos con el cluster y el proceso de failover es a travs de un nuevo Service Group de Veritas Cluster Server llamado Replication, el cual tendr 3 elementos con las siguientes funciones:

Alta Disponibilidad Pgina 16

NIC

Este elemento monitorea el estado de la placa de red donde se monta la IP de replicacin (configurada directamente a travs de Windows). En caso de producirse una prdida del enlace o una cada del hardware de red, este el Resource que mostrar la falla. VMDg

Importa y deporta en cada nodo el DiskGroup, donde se almacenan los volmenes a replicar VvrRvg

Inicia, detiene y monitorea el Replication Volume Group, donde se configuran todos los volmenes primarios y secundarios en los que se realizar replicacin. Estos 3 elementos (y por ende el Service Group completo) se encuentran permanentemente levantados en ambos nodos del cluster, sin importar cul de ellos se encuentra activo, dado que es aqu que se gestiona la replicacin de datos que ocurre permanentemente en ambos nodos. Cuando se da el caso de una falla en el nodo A y se desencadena un failover, la replicacin de datos se detiene y el volumen secundario toma el control de los servicios, utilizando la informacin obtenida proveniente del primario hasta el instante en que se produjo la falla.

Imagen 11 Service Group de replicacin

Alta Disponibilidad Pgina 17

5. Mediciones y alarmas en Live Monitor

Live Monitor es una poderos herramienta desarrollada por inConcert, que permite realizar todo tipo de mediciones y monitoreos, tanto sobre magnitudes fsicas como indicadores de negocios, resultantes del procesamiento de la informacin. Tambin permite realizar grficos histricos, definir alarmas preventivas y establecer procedimientos para el manejo de las distintas situaciones, en que las mediciones cumplan ciertas condiciones. Es capaz de realizar consultas a cualquier base de datos va ODBC y mediciones sobre cualquier dispositivo de la red que maneje el protocolo SNMP (servidores, switches, impresoras, routers, etc). Tambin permite la ejecucin local o remota de scrpits que obtengan datos y realicen procesamiento posterior. En la Imagen 12 se observa el grfico de una medicin de consumo de CPU realizada con Live Monitor.

Imagen 12 Grfico realizado en Live Monitor

Para implementar la solucin de inConcert HA, se utiliza Live Monitor como herramienta de monitoreo del status de los servicios y servidores de la plataforma, as como tambin para definir los distintos procedimientos de contingencia, como desencadenar un failover. Los elementos a medir para determinar el correcto funcionamiento se definen en la forma de Atributos Monitoreables, tal cual se observa en la Imagen 13, cada uno de ellos realizar el seguimiento de un punto de determinado de la plataforma. Un ejemplo de ello sera el status del servicio inConcert Web Handler.

Alta Disponibilidad Pgina 18

Imagen 13 Consola de configuracin de Live Monitor

Dentro de cada atributo montoreable se pueden definir alarmas que se dispararn en caso de que las mediciones cumplan una serie de condiciones determinadas, por ejemplo si un host deja de devolver el PING durante 5 mediciones consecutivas, cada una de ellas realizada con una separacin de 10 segundos. En el caso de detectarse una alarma se procede a ejecutar las acciones asociadas a ella, para el caso de inConcert HA estas involucrarn los siguientes pasos: 1. Se enva de un correo a soporte notificando la falla. 2. Se intenta de inicializar el elemento que fall. 3. En caso de no resultar exitoso el paso 2, se provoca el failover de la plataforma, en el caso de los servidores Windows, deteniendo el servicio inConcert Cluster Service, en el caso del server PBX mediante la ejecucin de scripts remotos. Las notificaciones de las alarmas disparadas, junto con la informacin de fecha y hora del evento se encuentran listadas en la seccin Pending Events de la consola de configuracin de Live Monitor.

Alta Disponibilidad Pgina 19

6. Cluster servidor PBX

El manejo de la contingencia para los servidores de comunicaciones se realiza a travs de la herramienta de inConcert Live Monitor. Para su implementacin se configuran alarmas que monitorean el correcto funcionamiento del server, la imagen 14 muestra el atributo monitoreable utilizado para la solucin (medicin del Up Time de Asterisk).

Imagen 14 Definicin de un atributo monitoreable

Dentro del atributo monitoreable se definen alarmas que se dispararn ante ciertos eventos en las mediciones, relacionados con fallas en el server, y acciones a tomar para cada caso, las imgenes 1 5 y 16 muestran ejemplos de alarmas y acciones utilizadas para le cluster de PBX.

Alta Disponibilidad Pgina 20

Imagen 15 Definicin de una alarma para el server PBX

Imagen 16 Definicin de la accin para el failover de PBX

Alta Disponibilidad Pgina 21

En caso de detectarse un punto de falla se disparar la alarma y por ende se ejecutar la accin configurada y asociada a ella, la misma desencadenar el proceso de failover, implementado a travs de scripts remotos (ubicados en cada server en la carpeta /etc/cluster/), los cuales realizan el intercambio de direcciones IP y el posterior inicio de la plataforma de comunicaciones. El orden de ejecucin de los eventos es el siguiente: 1. Se dispara la condicin que activa la alarma asociada a status de Asterisk. 2. La alarma se pasa a estado Sleep. 3. Se ejecuta el script remoto /etc/cluster/failoverNodoA.sh, ubicado en el servidor activo, realizando los siguientes pasos: a. Detiene los servicios de inConcert, en caso de que aun se encuentren levantados. b. Se realiza el intercambio de todas las direcciones IP del servidor por las privadas asociadas al mismo. c. Se configuran todas las rutas asociadas a las direcciones IPs privadas del servidor. d. Se inicia nuevamente el proceso RemoteExecutionServer, encargado de recibir las invocaciones remotas de Live Monitor y ejecutar los scripts. 4. En caso de no poder ejecutarse el paso 3 se asume que el servidor se encuentra inaccesible o apagado y se procede con el paso siguiente. 5. Se ejecuta el script remoto /etc/cluster/failoverNodoB.sh, ubicado en el servidor pasivo, realizando los siguientes pasos: a. Se realiza el intercambio de todas las direcciones IP del servidor por las pblicas del cluster, anteriormente asociadas al nodo A. b. Se configuran todas las rutas asociadas a las direcciones IPs privadas del servidor. c. Se inician los servicios de inConcert, comenzando a brindar servicio nuevamente. d. Se inicia nuevamente el proceso RemoteExecutionServer, encargado de recibir las invocaciones remotas de Live Monitor y ejecutar los scripts. 6. Finalmente la plataforma se encuentra lista para continuar brindando servicios.

Alta Disponibilidad Pgina 22

Este proceso completo no debera tomar ms de unos pocos segundos en ejecutarse. Luego de solucionada la falla, si se quisiera realizar el procedimiento de failback para devolver la plataforma a su situacin original se debern ejecutar los scripts correspondientes (ubicados tambin en /etc/cluster/), pero en el sentido inverso al que ocurre en el failover, los pasos seran los siguientes:

1. Detener la alarma asociada a Asterisk en Live Monitor, de manera de asegurarse que no se dispare la misma durante el proceso de failback manual, ingresando al atributo monitoreable inConcertAsteriskStatus y desmarcando la opcin Enabled. 2. Ingresar al servidor activo (nodo B), el cual tiene las direcciones pblicas asignadas. 3. Ejecutar el script /etc/cluster/ failbackNodoB.sh, el cual realiza los siguientes pasos: a. Detiene los servicios de inConcert, en caso de que aun se encuentren levantados. b. Se realiza el intercambio de todas las direcciones IP del servidor por las privadas asociadas al mismo. c. Se configuran todas las rutas asociadas a las direcciones IPs privadas del servidor. d. Se inicia nuevamente el proceso RemoteExecutionServer, encargado de recibir las invocaciones remotas de Live Monitor y ejecutar los scripts. 4. Ingresar al servidor pasivo (nodo A), el cual tiene las direcciones privadas asignadas. 5. Ejecutar el script /etc/cluster/failbackNodoA.sh, el cual realiza los siguientes pasos: a. Se realiza el intercambio de todas las direcciones IP del servidor por las pblicas del cluster, anteriormente asociadas al nodo B. b. Se configuran todas las rutas asociadas a las direcciones IPs pblicas del servidor. c. Se inician los servicios de inConcert, comenzando a brindar servicio nuevamente. d. Se inicia nuevamente el proceso RemoteExecutionServer, encargado de recibir las invocaciones remotas de Live Monitor y ejecutar los scripts. 6. Asegurarse de que asterisk se encuentre iniciado y con las conexiones establecidas mediante los comandos inconcert start, y luego inconcert show clients y inconcert show middleware. 7. Iniciar nuevamente el atributo monitoreable de Live Monitor desactivado en el paso 1.

Alta Disponibilidad Pgina 23

7. Operacin de la plataforma
En un funcionamiento normal de la plataforma, el nodo A se encuentra activo, y cada uno de sus servidores tiene asignada la IP pblica correspondiente. Ante una falla el sistema es capaz de reaccionar automticamente, utilizando para esto los mecanismos anteriormente explicados, realizando diferentes acciones correctivas dependiendo del caso. Si la situacin es lo suficientemente crtica se efecta el failover, activando el nodo pasivo y enviando el activo a estado de Stand By (los elementos que hayan presentado fallas quedarn en estado FAULTED y las acciones quedarn registradas en el log) En caso de necesitarse realizar un failover manual, este se puede hacer a travs de la accin SWITCH sobre el Service Group MWServer, tal como se explic anteriormente, esto desencadenar el proceso completo y de forma ordenada. Previamente se debe asegurar que no existan clientes utilizando la plataforma, ya que de otra forma ver interrumpida abruptamente la operacin, provocando seguramente errores en los procesos. Luego de producirse una falla en alguno de los servidores Windows y por ende un failover, llegar el momento en que la misma se encontrar corregida y se querr devolver el sistema a su estado original. Para ello se debe ingresar a la consola de Veritas Cluster Server y limpiar (CLEAR FAULT) todos los elementos que se encuentren con estado FAULTED (aquellos en los que se produjo la falla), as como tambin asegurarse de que se encuentren probados todos los resources del nodo A y posteriormente ejecutar la accin SWITCH en el Service Group MWServer hacia el correspondiente server del nodo A, esto desencadenar el proceso de Failback. Dentro de las propiedades de cada Service Group se encuentra definido el orden de prioridad de los servidores pertenecientes a l. El conjunto de servidores BD y MW que tiene asignada la prioridad 0 son quieren conforman el Nodo A, y dado que la opcin AutoStart se encuentra habilitada, cuando se inicien cada uno de estos equipos, se proceder a levantar ordenadamente los Resources de su Service Group asociado (a menos que ya se encuentren levantados en otro servidor del mismo grupo). El orden correcto para levantar la plataforma desde cero es el usual: En primer lugar se debe encender el servidor BD-A y esperar a que se inicie correctamente todo (monitorear desde la consola de Veritas), luego se deber iniciar el servidor MW-A hasta que todo quede completamente levantado. Con ambos servidores activos se puede iniciar la telefona para comenzar a utilizar los servicios. Una vez que el nodo A se encuentre funcionando correctamente se podr encender y reinciar los servidores del nodo B sin que esto ocasione problemas, ya que todos sus elementos permanecern en estado OFFLINE. Para que el sistema quede completamente funcional y en condicin de responder ante fallas deben dejarse iniciados los 4 servidores del Cluster y se debe comprobar el correcto status de la conectividad, en el panel System Conectivity de la consola. Se debe chequear tambin que todos los elementos del nodo pasivo se encuentren correctamente probados.

Alta Disponibilidad Pgina 24