Consideraciones para la instalacin de un failover cluster distribuido en Windows Server 2008

Contenido
1 2 Introduccin ............................................................................................................ 3 Clsteres mono-sitio y multi-sitio (distribuido) ......................................................... 4

2.1 Clsteres mono-sitio (no distribuidos) ................................................................................ 4 2.2 Clsteres multi-sitio (distribuidos) ..................................................................................... 4

El qurum en el failover clster de Windows Server 2008 ......................................... 5

3.1 Mayora Vs disco qurum .................................................................................................. 5 3.2 Tipos de qurum en Windows Server 2008......................................................................... 6
3.2.1 Qurum de mayora de nodos .................................................................................................................. 7 3.2.2 Qurum de mayora de nodos y testigo ................................................................................................... 8 3.2.3 Clster sin mayora de nodos: disco qurum ......................................................................................... 10

3.3 Recomendaciones de tipo de qurum para clsteres distribuidos ..................................... 10

3.3.1 Uso de la mayora de nodo y carpeta compartida testigo en clsteres distribuidos ............................. 12

Almacenamiento en los clsteres distribuidos ........................................................ 14

4.1 Replicacin...................................................................................................................... 14
4.1.1 Niveles de replicacin ............................................................................................................................. 15 4.1.2 Tipos de replicacin ................................................................................................................................ 15 4.1.3 Recomendaciones sobre replicacin ...................................................................................................... 17

Redes en clsteres distribuidos .............................................................................. 17

5.1 Configuracin de Heartbeat y DNS ................................................................................... 18 5.2 Hyper-V y el direccionamiento de mquinas virtuales....................................................... 19

Introduccin

El presente documento tiene por finalidad exponer la arquitectura, requerimientos y alternativas para la creacin de clsteres distribuidos, as como exponer unas recomendaciones finales.

Clsteres mono-sitio y multi-sitio (distribuido)

Podemos establecer dos tipos de clster en funcin a su arquitectura:

Clsteres mono-sitio (no distribuidos). Clsteres multi-sitio (distribuidos).

2.1 Clsteres mono-sitio (no distribuidos)

Este tipo de clsteres se caracterizan por estar compuestos de n-nodos que acceden a uno o ms almacenamientos compartidos (SANs). Todos los nodos del clster acceden a los mismos almacenamientos compartidos, permitiendo esto que la informacin obtenida/generada por las aplicaciones y/o servicios del clster sea la misma para todos los nodos. Vemos en el grfico un clster mono-sitio compuesto por 2 nodos que acceden a una cabina.

2.2 Clsteres multi-sitio (distribuidos)

Este tipo de clsteres se caracteriza por estar compuesto de nodos ubicados en ms de una localizacin o sitio. En cada uno de los sitios hay uno o ms almacenamientos compartidos, accediendo todos los nodos del sitio a los mismos almacenamientos compartidos, pero no accediendo a los almacenamientos compartidos de los otros sitios . Para que la informacin sea la misma en todos los sitios, los almacenamientos replican entre ellos. En el grfico vemos un clster multi-sitio compuesto de 4 nodos distribuidos en dos sitios (dos nodos por sitio) conectando los nodos de cada sitio a la cabina de su

sitio, replicando las cabinas entre ellas, y un tercer sitio con una carpeta compartida testigo (veremos qu significa esto ms adelante).

3 El qurum en el failover clster de Windows Server 2008

Windows Server 2008 presenta un nuevo modelo de qurum en su implantacin de failover clster diferente al de las versiones anteriores, basado en mayora en lugar de en un disco de qurum. Veremos el concepto de mayora frente al de disco de qurum y cada uno de los tipos qurum que se pueden establecer.

3.1 Mayora Vs disco qurum

El disco de qurum tradicional almacenaba la informacin del cluster y era accedido por todos los nodos del cluster, lo que tiene la ventaja de que el cluster puede seguir funcionando con un nico nodo, independientemente del nmero de nodos que lo componen (ventaja relativa, pues para que esto sea de verdad operacional, es necesario que todos los nodos del cluster sean capaces de albergar todos los servicios y aplicaciones de cada uno de los nodos, lo que implica multiplicar la potencia de los servidores por el nmero de nodos, disparndose el coste, o asumir que no todos los servicios y

aplicaciones se balancearn en el caso de quedar un solo nodo en funcionamiento). La principal desventaja de este modelo de cluster es que en caso de perderse el disco de qurum se pierde el cluster, aunque funcionen sin problemas todos los nodos que lo conforman. Frente a este enfoque del disco de qurum se desarroll un qurum que residiera no en un disco compartido, si no que existiera una copia completa en cada uno de los nodos y fuese replicada entre ellos, para as evitar el punto de ruptura que supone el disco de qurum tradicional. Este enfoque requiere tener en cuenta el efecto isla. Este efecto consiste en que un clster, al producirse un problema de red u otra clase, podra quedar dividido en dos o ms grupos (islas) de nodos capaces de comunicarse entre s . En esta situacin, como mximo debe haber uno de los grupos de nodos que quede como clster , que sea el encargado de dar los servicios y aplicaciones, y los otros deberan quedar como en fallo, pues si no los datos que se generasen en los servicios y aplicaciones no seran los mismos para todos los nodos del cluster, si no que habra un conjunto de datos diferente para cada uno de los grupos de nodos, lo cual es un comportamiento errneo en un clster Qu grupo de nodos es el que debe considerarse como clster y qu grupos los que no? Para poder efectuar esa decisin, se desarroll el criterio de mayora, por el cual para que un grupo de nodos est operativo se establece un sistema de votacin en el que cada uno de los nodos tiene un voto. Para que no se produzca el indeseado efecto isla, aquel grupo de nodos que rena la mayora de votos ser el grupo que provea los servicios y aplicaciones del clster y los grupos que no la renan no proveern dichos servicios.

3.2 Tipos de qurum en Windows Server 2008

Existen cuatro tipos de qurum en los clsteres de tolerancia a fallos de Windows Server 2008:

Mayora de nodo. Mayora de nodo con testigo. o Disco testigo. o Carpeta compartida testigo. Sin mayora de nodo, slo disco de qurum.

3.2.1 Qurum de mayora de nodos

Para que el clster se considere que est operativo se establece un sistema de votacin en el que cada uno de los nodos tiene un voto; para que el clster siga en funcionamiento, es necesario que la mitad ms uno de los votos sean emitidos (es decir, que la mitad ms uno de los nodos estn operativos). La mitad se calcula redondeando hacia abajo, de forma que hay una sensible diferencia entre que el nmero de nodos sea impar o par. En la siguiente tabla se ve el nmero de nodos, cuantos votos implican y cuantos nodos pueden estar cados y sin que el cluster deje de funcionar:
Nmero de nodos Nmero de votos Nodos que pueden caer 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7

Si observamos la anterior tabla, este mecanismo beneficia los clsteres de nodos impares, pues permiten tener cados tantos nodos como el clster conformado por el nmero par inmediatamente superior a l (3 nodos permiten la cada de uno, 4 nodos permiten la cada de uno); adems, en el caso de un clster de dos nodos, no se puede caer ninguno de ellos. Por ello est especialmente indicado para clsteres de nodos impares y para clsteres distribuidos. Este tipo de clsteres no se recomiendan para clsteres de 2 nodos o clsteres con un nmero par de nodos.

3.2.2 Qurum de mayora de nodos y testigo

Para solventar el anterior comportamiento en clsteres conformados por un nmero par de nodos, se puede configurar un testigo, que es un disco o una carpeta compartida, que tiene un voto, de manera que permita obtener un nmero impar de votos a los clsteres con nodos pares, y as optimizar el nmero de nodos que pueden estar cados. Veamos la tabla de nmero de nodos, votos y nodos que pueden caer:
Nmero de nodos Nmero de votos Nodos que pueden caer 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8

De esta manera un clster de nodos pares permite tantos nodos cados como el cluster de nodos impares inmediatamente superior (6 nodos permiten 3 cados, 7 nodos permiten 3 cados); adems de esto, es factible que un clster de dos nodos pueda seguir funcionando con uno cado. Hay dos tipos de testigos:

Disco testigo Carpeta compartida testigo

3.2.2.1

Disco testigo

El disco testigo consiste en un almacenamiento externo a los nodos (una LUN en cabina presentada a todos los nodos, ya que Windows Server 2008 no permite el uso de SCSI compartido), al que acceden todos los nodos, en el que se guarda una copia del qurum. Se puede confundir el disco testigo con el tradicional disco de qurum, pero hay una importantsima diferencia: si cae el disco de qurum, cae el cluster; si cae el disco testigo no cae el cluster si hay la mitad ms uno de nodos en funcionamiento. Por todo ello, este tipo clster est indicado para clsteres formados por 2 nodos o por un nmero par de nodos. No est indicado para los clsteres de un solo nodo o los distribuidos , al requerir el acceso a una misma LUN por parte de todos los nodos, cosa que no es posible, al encontrarse los nodos del clster distribuidos en diferentes sitios y accediendo a diferentes almacenamientos.

3.2.2.2

Carpeta compartida testigo

El concepto es el mismo que el del disco de testigo (la carpeta compartida testigo tiene un voto), con la salvedad de que la carpeta compartida testigo no almacena una copia del qurum, si no que almacena qu nodos son los que tienen la copia ms actualizada del qurum. Esto provoca que slo emita su voto a favor si ve presente al menos a uno de los nodos con la ltima versin del qurum. El ejemplo ms tpico de este problema es el siguiente: 1. Tenemos un clster de dos nodos (A y B), cada uno ejecutndose y sincronizados. 2. Se apaga el nodo B. 3. Realizamos cambios al clster en el nodo A. Estos cambios estn tan solo en la copia del qurum del nodo A, al estar el B apagado y, por tanto, no haber replicado. 4. Se apaga el nodo A. 5. Se enciende el nodo B. Como el nodo B no tiene una copia del qurum actualizada, y la carpeta compartida testigo ve que la copia actualizada est en el nodo A y no en el nodo B, la carpeta compartida testigo evita que el nodo B forme el clster. No funcionar el clster hasta que vuelva a funcionar el nodo A. Este tipo de clster est indicado para todos los tipos de clsteres (pares o impares), excepto los de un solo nodo. En aquellos casos en los que se puede utilizar el disco testigo, es preferible ste, siendo la ventaja de la carpeta compartida testigo la de abaratar la solucin en clsteres no distribuidos, al ahorrarse espacio en cabina, pues la

carpeta compartida puede estar en cualquier equipo que se desee e incluso ese equipo contener las carpetas compartidas testigos de varios clsteres. Tambin est indicado en clsteres distribuidos (de hecho es la mejor opcin en el caso de clsteres distribuidos), y siendo ubicada en otra localizacin distinta a la de los nodos. No est indicado en clsteres de un solo nodo.

3.2.3 Clster sin mayora de nodos: disco qurum

Es el tipo de clster tradicional. Como vimos anteriormente, la configuracin del clster es almacenada en el disco de qurum, lo que permite que se puedan caer n 1 nodos del clster y seguir ste funcionando. Lo malo es que no permite la cada del disco de qurum, siendo un punto de rotura nico. En la siguiente tabla vemos la tolerancia del este tipo de qurum, segn los nodos, los nodos que pueden estar cados y los fallos de disco de qurum permitidos (ninguno):
Nmero de nodos Nodos que pueden caer Fallos tolerados del disco de qurum
1 2 ... 16 ... n 0 1 ... 15 ... n-1 0 0 ... 0 ... 0

3.3 Recomendaciones de tipo de qurum para clsteres distribuidos

La tabla siguiente proporciona las recomendaciones de Microsoft, para el tipo de qurum en clsteres distribuidos:
Recomendado No Recomendado Mayora de nodos Mayora de nodos y carpeta compartida testigo Sin mayora: Disk Only X X (la mejor) X

Muchas de las ventajas de los clsteres distribuidos derivan en gran parte del hecho de que trabajan de una forma algo diferente a los clsteres no distribuidos (mono-sitio). La

separacin en la distancia de los nodos de un clster afectar las opciones del modelo de qurum elegido y a la configuracin de almacenamiento, red y datos en el clster . Para algunos usos de negocio, incluso un acontecimiento tan poco probable como fuegos, inundaciones, terremotos, etc., pueden plantear una cantidad intolerable de riesgo a las operaciones de negocio. Para las cargas de trabajo verdaderamente esenciales, la distancia puede proporcionar el nico remedio contra una catstrofe. El servidor 2008 de Windows permite crear clsteres distribuidos en distancias ilimitadas, haciendo la solucin ms resistente a los desastres locales, regionales o an nacionales . Con el servidor 2008 de Windows, se puede desplegar un clster distribuido para automatizar el balanceo de servicios y aplicaciones en las siguientes situaciones:

Comunicaciones cadas entre sitios. Un sitio est cado y no est disponible para ejecutar aplicaciones o servicios.

Un clster distribuido de Windows Server 2008 tiene los siguientes atributos:

Las aplicaciones estn configuradas para balancear de la misma forma que en un clster local. El servicio de clster dispone de una monitorizacin del estado de salud y deteccin de fallos de aplicaciones, nodos y enlaces de comunicacin. El clster dispone de mltiples cabinas de almacenamiento, con al menos una cabina en cada sitio. Esto asegura que en caso de fallo de algn sitio, el resto de sitios tengan una copia local de los datos, que puede ser utilizada para continuar proporcionando los servicios y aplicaciones, garantizando as la alta disponibilidad. Los nodos del clster estn conectados con el almacenamiento de forma que en el caso de faltar un sitio o un enlace de comunicacin, puedan acceder a los datos de ese sitio gracias a la replicacin de las cabinas . Es decir, en el caso de un clster de dos sitios, los nodos del sitio A estn conectados al almacenamiento del sitio A y los nodos del sitio B estn conectados al almacenamiento del sitio B. Esto permite que los nodos del sitio A puedan acceder a los datos sin tener acceso al almacenamiento del almacenamiento del sitio B, y viceversa. Las cabinas de almacenamiento o el software basado en host proporcionan una forma de replicar la informacin entre los sitios, de manera que cada uno tenga una copia de datos. No existe un almacenamiento compartido al que accedan todos los nodos, lo que obliga e esta replicacin entre cabinas.

3.3.1 Uso de la mayora de nodo y carpeta compartida testigo en clsteres distribuidos

En este modo de qurum, todos los nodos y una carpeta compartida testigo tienen un voto para determinar la mayora. Esto ayuda a eliminar el punto de ruptura del viejo modelo que supona el disco de qurum. Esto hace que la mayora de nodo y carpeta compartida testigo est especialmente indicado para los clsteres distribuidos : un solo servidor de archivos puede servir como testigo a mltiples clsteres (usando cada uno su propia carpeta compartida testigo).

Supongamos que tenemos dos sitios fsicos, sitio A y sitio B, cada uno con dos nodos. Tenemos adems una carpeta compartida testigo en un tercer sitio fsico. En total se disponen de cinco votos, cuatro correspondientes a los nodos y el quinto a la carpeta compartida testigo. Veamos posibilidades:

Desastre en el sitio A: Si, por ejemplo cae el enlace de comunicaciones en el sitio A, o se produce un desastre como un incendio o terremoto, por ejemplo, perdemos los votos del sitio A, y quedando nicamente los votos del sitio B y el voto de la carpeta compartida testigo; esto hace un total de tres votos disponibles, como el clster es de cuatro nodos, su mitad ms uno es dos y por tanto el clster seguir suministrando sus servicios y aplicaciones.

Desastre en el sitio B: Si, por ejemplo cae el enlace de comunicaciones en el sitio B, o se produce un desastre como un incendio o terremoto, por ejemplo, perdemos los votos del sitio B, y quedando nicamente los votos del sitio A y el voto de la carpeta compartida testigo; esto hace un total de tres votos disponibles, como el clster es de cuatro nodos, su mitad ms uno es dos y por tanto el clster seguir suministrando sus servicios y aplicaciones. Desastre en el sitio de la carpeta compartida testigo: en este caso, se pierde un nico voto, con lo que quedan cuatro y, por tanto, el clster seguir suministrando sus servicios y aplicaciones.

Si la carpeta compartida testigo est ubicada en uno de los sitios de los nodos, el comportamiento no ser el correcto, pues si hay una cada de la comunicacin entre los dos sitios, si suponemos que la carpeta compartida testigo est ubicada en el sitio A, este sitio ser considerado como el sitio que provee los servicios y aplicaciones del clster; si el sitio que est incomunicado es, precisamente el A, el clster no estar suministrando los servicios y aplicaciones, pues est incomunicado y es el nico capaz de contactar con la carpeta compartida testigo, as que se considera como vlido para suministrar los servicios y aplicaciones; mientras tanto, el nodo del sitio B no ser capaz de suministrar estos servicios y aplicaciones, al no poder contactar ni con el otro nodo no con la carpeta compartida testigo, y sin embargo es el nodo que debe de proveer los servicios y carpetas; ser, por tanto, necesario intervenir en el sitio B para eliminar el control de no mayora. Como podemos ver, el uso del modo de qurum de carpeta compartida testigo permite la continuidad del clster, en el caso de la cada completa de uno de los sitios .

3.3.1.1

Uso de la mayora de nodo en un clster distribuido

Si el uso de una carpeta compartida testigo no es posible, se puede an as utilizar el modelo de qurum por mayora de nodo. Supongamos que tenemos un clster distribuido de cinco nodos, tres de los cuales estn ubicados en el sitio A y dos en el sitio B. Si hay una cada de la comunicacin entre los dos sitios, en el sitio A todos los nodos del sitio se pueden ver entre s, suman tres votos y por tanto consideran que ellos son el clster vlido. Los nodos en el sitio B pueden comunicarse entre s, pero, al sumar dos votos, no consiguen la mayora, y dejan de prestar servicio. Si el sitio que ha perdido los enlaces fuese el A, sera necesario intervenir en el sitio B para eliminar el control de no mayora. Esta configuracin es menos tolerante que la de mayora de nodo y carpeta compartida testigo en un tercer sitio, ya que la cada del sitio primario causa la cada completa del clster . Para solventar este problema,

en un clster con mayora de nodo, sera necesario un tercer sitio en el que situar al menos un nodo, de manera que para obtener la mayora, fueran necesarios los votos de los nodos de al menos dos sitios; en el ejemplo anterior podramos situar 2 nodos en el sitio A, otros dos en el B y un tercer nodo en el sitio C; no obstante, esto requiere el tener una tercera cabina replicando, lo que incrementa la complejidad y los costes, siendo por tanto mucho mejor el uso de una carpeta compartida testigo.

Almacenamiento en los clsteres distribuidos

Para que un clster distribuido pueda ser implantado, es necesario cumplir los siguientes requerimientos con el almacenamiento:

Los nodos de cada sitio deben tener al menos un almacenamiento compartido (SAN). Los almacenamientos compartidos deben replicar con los almacenamientos compartidos de los otros sitios, para que la informacin utilizada/generada por los servicios y aplicaciones del clster sea coherente en todos los sitios. El software de cabina debe permitir que se detecte el failover del clster, de manera que cuando este se produzca, las LUNs implicadas de las cabinas pasen, de manera automtica, de lectura/escritura a solo lectura, en la cabina a la que estn conectados los nodos del sitio que ha cado, y de slo lectura a escritura en la cabina del sitio que asume el servicio.

4.1 Replicacin
Veremos a continuacin la replicacin de datos en funcin de:

Niveles de replicacin. Tipos de replicacin.

4.1.1 Niveles de replicacin

La replicacin de los datos entre sitios puede estar hecha a tres niveles:

Nivel de hardware (nivel de bloque): la replicacin es realizada por las controladoras de cabina o por el software de espejo. Nivel de sistema operativo (replicacin de los cambios en el sistema de archivo): el software de servidor realiza la replicacin. Nivel de aplicacin: la propia aplicacin es la encargada de realizar la replicacin. Un ejemplo de ello es la replicacin continua de Exchange, es decir, Microsoft Exchange Server 2007 Continuous Cluster Replication (CCR).

El mtodo a elegir para la replicacin depende de los requerimientos de negocio y de aplicacin.

4.1.2 Tipos de replicacin

Existen dos tipos de replicacin:

Replicacin sncrona Replicacin asncrona

4.1.2.1

Replicacin sncrona

En este tipo de replicacin, los cambios que se realizan en un sitio no se dan por concluidos hasta que no se han replicado en los otros sitios. Garantiza que no haya prdida de datos en caso de cada de un sitio. Si en el sitio A se escribe un bloque de datos, esta operacin de entrada / salida no se da por concluida hasta que no se haya escrito ese mismo bloque en el sitio B. Es el mejor tipo de replicacin en clsteres distribuidos cuando se tienen lneas de comunicacin con un gran ancho de banda y una baja latencia. En la prctica, esto limita este tipo de replicacin a clsteres distribuidos en los cuales la distancia entre sitios es corta. La replicacin sncrona protege de la prdida de datos en caso de failover en clsteres distribuidos, pero tiene en su contra la potencial latencia, provocada por las operaciones de escritura y ACK. Debido a esta latencia potencial, la rplica sncrona puede penalizar en exceso el rendimiento de las aplicaciones de cara al usuario . De ah lo que decamos

sobre la distancia entre sitios y el ancho de banda de los enlaces: si el ancho de banda no es suficiente, o la distancia es excesiva (lo que provoca latencia en las comunicaciones) o la aplicacin no permite la latencia inherente a este tipo de replicacin, la replicacin sncrona no es una opcin aceptable.

4.1.2.2

Replicacin asncrona

En este tipo de replicacin, los cambios que se realizan en un sitio se dan por finalizados de forma local, y posteriormente se replican a los otros sitios en segundo plano . Si en el sitio A se escribe un cambio, este se da por finalizado en cuanto se ha realizado la operacin de lectura / escritura en el almacenamiento del sitio y el software de replicacin se encarga de modificar el almacenamiento de del sitio B, para que refleje ese cambio, en segundo plano. La replicacin asncrona es la mejor opcin para obtener el mximo rendimiento de las aplicaciones y servicios del clster, pues no hay que aadir la latencia correspondiente a la espera del ACK de las cabinas remotas y la latencia correspondiente a la distancia entre sitios y/o ancho de banda limitado. En clsteres distribuidos con grandes distancias entre los sitios, o con aplicaciones que requieren una respuesta muy rpida, es la nica opcin viable. El punto dbil de la replicacin asncrona es que hay que asumir que en el caso de producirse un failover, habr prdida de datos, pues todo proceso de rplica que se est efectuando es ese momento no ser completado, con lo que se vern perdidos los datos implicados. Este problema de prdida de datos de la replicacin asncrona hace que se tenga que tomar en cuenta tambin cmo implementa el fabricante esta replicacin. Unos fabricantes la hacen respetando el orden de las operaciones y otros no . Esta es una diferencia crucial, pues si la rplica respeta el orden, el estado de los discos de la cabina del sitio B estar obsoleto, pero ser un estado existente en el pasado en los discos de la cabina A y la solucin es coherente ante roturas (crash consistent) . De manera inversa, si la replicacin no respeta el orden de las operaciones, el estado de los discos del sitio B ser, probablemente, un estado en el que nunca estuvieron los discos de la cabina A . Muchas aplicaciones son capaces de recuperarse de roturas coherentes, mientras que muy pocas son capaces de hacerlo en el caso de operaciones de entrada y salida desordenadas. Por ello, un clster distribuido nunca debera utilizar rplicas asncronas que no respeten el orden de operaciones de entrada y salida .

4.1.3 Recomendaciones sobre replicacin

Teniendo en cuenta todo lo que hemos visto en referencia a la replicacin entre cabinas, podemos establecer las siguientes recomendaciones:

Seleccin del nivel de replicacin (bloque, sistema de archivos o aplicacin) : se debe consultar a los fabricantes del hardware y software para decidir cul es el nivel de replicacin que ms nos conviene segn los servicios y/o aplicaciones que deseamos que ejecute el clster. Configurar la replicacin para evitar la corrupcin de datos: en el caso de que la replicacin entre cabinas sea asncrona, sta debe respetar el orden de las operaciones de entrada y salida, pues poqusimas aplicaciones son capaces de recuperarse si los datos de replicacin estn corrompidos. No debe usarse Distributed File System Replication (DFR-S): no se debe usar DFRS como mtodo para la replicacin entre sitios pues DFR-S slo replica los ficheros una vez cerrados. DFR-S funciona muy bien con ficheros como documentos, presentaciones y hojas de clculo, pero no con ficheros que deben permanecer abiertos, como bases de datos o mquinas virtuales. Seleccionar entre replicacin sncrona o asncrona: como vimos, aunque es ms segura, por evitarse la prdida de datos, la replicacin sncrona, si no se dispone del suficiente ancho de banda y/o baja latencia en la comunicacin entre sitios y las necesidades de rendimiento de los servicios o aplicaciones que ejecuta el clster no permiten este tipo de replicacin cuando no es rpida, nos veremos obligados a configurar la replicacin como asncrona. Si este es el caso, se debe tener en cuenta el segundo punto de estas recomendaciones.

Redes en clsteres distribuidos

Un mejora de la tecnologa de clster en Windows Server 2008 es la posibilidad de que los nodos que componen un clster pueden estar en diferentes subredes . Al contrario de lo que suceda en las versiones anteriores (Windows 2000 Server y Windows Server 2003) los nodos de los clsteres de Windows Server 2008 pueden comunicarse entre s a travs de enrutadores de red, lo que permite no estar obligado a que los nodos distribuidos geogrficamente estn en la misma VLAN, reduciendo la complejidad y los costes debidos a la configuracin necesaria para los clsteres distribuidos . Nota En el caso de SQL Server 2005 y SQL Server 2008 es requerido el uso de VLAN.

No obstante, mantener las VLANs puede ser conveniente, para mejorar el tiempo de respuesta de los clientes. Los clientes no pueden ver una carga de trabajo en la que se hizo failover ms rpido de lo que tarden los servidores DNS en replicarse y lo que tarden los clientes en buscar la informacin DNS actualizada al nuevo servidor con la carga de trabajo. Esto es as debido a que, a pesar de que los servicios y aplicaciones mantienen los mismos nombres de red en caso de failover, las IPs de estos servicios y aplicaciones cambian. Los servidores DNS deben actualizar los registros correspondientes a los servicios y aplicaciones que han hecho failover a las nuevas IPs. Adems de esto, los clientes tienen en cach las IPs antiguas, y deben expirar para que los clientes vuelvan a consultar al servidor DNS, obtengan como respuestas las nuevas IPs y as puedan ser localizados dichos servicios y aplicaciones. En los siguientes puntos se harn recomendaciones para clsteres distribuidos cuya configuracin de red est hecha en mltiples subredes.

5.1 Configuracin de Heartbeat y DNS

Cuando el clster no est en su propia VLAN, para optimizar la velocidad de failover, de la rplica de DNS y de las bsquedas DNS, se deben ajustar las configuraciones de Heartbeat y DNS, debido al tiempo de rplica de los servidores DNS y expiracin de consultas cacheadas en clientes, que vimos anteriormente. Para minimizar el tiempo de cada en un clster distribuido deberemos:

Revisar qu opciones tenemos para usar VLANs o mltiples subredes . Si usamos VLANs, evitamos los problemas derivados de la replicacin de DNS y la expiracin de registros DNS cacheados en el cliente, pues las IPs de servicios y aplicaciones no cambiarn. No obstante, el uso de mltiples subredes puede ser mucho ms simple que el de VLANs a la hora de configurarlas y administrarlas. Si decidimos utilizar mltiples subredes, deberemos elegir entre dos estrategias para acelerar la resolucin de nombres, cambiar la propiedad TTL de servidores y clientes o crear registros por cada una de las IPs: o Time To Live (TTL): esta propiedad limita el tiempo que es usado un registro DNS antes de ser descartado, esto es, el lmite de persistencia en cach de un registro DNS. De manera predeterminada es de 20 minutos (1200 segundos), este lmite deberamos configurarlo en funcin de las recomendaciones del servicio o aplicacin; por ejemplo, para Exchange

Server 2007 el TTL recomendado es de 5 minutos (How to Configure the DNS TTL Value for a Clustered Mailbox Server Network Name Resource). o Registro simple o mltiple de IPs: podemos elegir entre tener en DNS nicamente las IPs que estn en funcionamiento o tener todas las posibles IPs que tengan los servicios y aplicaciones que son ejecutadas por el clster. Esta opcin es muy til en el caso de clientes capaces de manejar mltiples IPs asociadas a un mismo nombre de red. Si decidimos utilizar mltiples subredes, es conveniente que ajustemos la configuracin de Heartbeat. Esta configuracin, de forma predeterminada, es de un latido cada segundo y si un nodo pierde 5 latidos, otro nodo iniciar el failover. El rango para la frecuencia de latidos es entre 250 y 2000 milisegundos, en redes comunes y entre 250 y 4000 milisegundos entre diferentes subredes. El rango de latidos perdidos est entre 3 y 10. Es interesante establecer valores diferentes para las redes comunes y las no comunes, debido a que la fiabilidad y velocidad de los enlaces entre subredes ser, probablemente, menor que en el caso de las redes comunes, y por tanto ser conveniente hacer ms tolerante el control entre subredes, espaciando los latidos y admitiendo ms fallos. Para ver cmo se configura consultar Configure Heartbeat and DNS Settings in a Multi-Site Failover Cluster.

5.2 Hyper-V y el direccionamiento de mquinas virtuales

Si tenemos un clster distribuido en el que se ejecutan mquinas virtuales de Hyper-v y el clster est configurado en mltiples subredes, deberemos tener en cuenta el direccionamiento de las mquinas virtuales que ejecuta el clster. Esto es as ya que, lo mismo que pasa con otros servicios en clster distribuido, en el caso de un failover ser necesario que los clientes busquen a las mquinas virtuales con otra IP distinta a la que tenan antes del failover, ya que stas han cambiado a otra subred. Esto implica que es necesario que cada mquina que se vea implicada en un failover cambie de propiedades de red (IP, mscara, puerta de enlace, DNS, etc.). Si las propiedades de las mquinas son establecidas dinmicamente por medio de DHCP, este cambio puede ser automatizado, en caso contrario deber realizarse de manera manual. Por lo tanto sera muy interesante configurar las mquinas virtuales con una IP dinmica, reservar en cada uno de los DHCPs de los sitios la IP correspondiente a ese sitio para cada mquina y configurar el DNS, ya sea siguiendo la estrategia de modificar el TTL de los servidores DNS y los clientes o la estrategia de crear mltiples entradas en DNS para las diferentes IPs de de las mquinas.