Este tipo de clústeres se caracterizan por estar compuestos de n-nodos que
acceden a uno o más almacenamientos compartidos (SANs). Todos los nodos
del clúster acceden a los mismos almacenamientos compartidos, permitiendo
esto que la información obtenida/generada por las aplicaciones y/o servicios
del clúster sea la misma para todos los nodos. Vemos en el gráfico un clúster
mono-sitio compuesto por 2 nodos que acceden a una cabina.
Este tipo de clústeres se caracteriza por estar compuesto de nodos ubicados
en más de una localización o sitio. En cada uno de los sitios hay uno o
más 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 información sea la misma
en todos los sitios, los almacenamientos replican entre ellos. En el gráfico
vemos un clúster 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 más adelante).
Windows Server 2008 presenta un nuevo modelo de quórum
en su implantación de failover clúster diferente al de las versiones anteriores,
basado en mayoría en lugar de en un disco de quórum. Veremos el concepto
de mayoría frente al de disco de quórum y cada uno de los tipos quórum que
se pueden establecer.
El disco de quórum tradicional almacenaba la información
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 número 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 número de nodos, disparándose el coste, o asumir
que no todos los servicios y aplicaciones se balancearán 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 quórum se pierde el cluster,
aunque funcionen sin problemas todos los nodos que lo conforman.
Frente a este enfoque del disco de quórum se desarrolló
un quórum 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 quórum tradicional.
Este enfoque requiere tener en cuenta el efecto isla.
Este efecto consiste en que un clúster, al producirse un problema de
red u otra clase, podría quedar dividido en dos o más grupos (islas) de
nodos capaces de comunicarse entre sí. En esta situación, como máximo
debe haber uno de los grupos de nodos que quede como clúster, que sea
el encargado de dar los servicios y aplicaciones, y los otros deberían
quedar como en fallo, pues si no los datos que se generasen en los servicios
y aplicaciones no serían los mismos para todos los nodos del cluster, si
no que habría un conjunto de datos diferente para cada uno de los grupos
de nodos, lo cual es un comportamiento erróneo en un clúster ¿Qué grupo
de nodos es el que debe considerarse como clúster y qué grupos los que no?
Para poder efectuar esa decisión, se desarrolló el criterio de mayoría, por
el cual para que un grupo de nodos esté operativo se establece un sistema
de votación 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 reúna la
mayoría de votos será el grupo que provea los servicios y aplicaciones del
clúster y los grupos que no la reúnan no proveerán dichos servicios.
Existen cuatro tipos de quórum en los clústeres de tolerancia a fallos de Windows Server 2008:
Para que el clúster se considere que esté operativo se
establece un sistema de votación en el que cada uno de los nodos tiene un
voto; para que el clúster siga en funcionamiento, es necesario que la mitad
más uno de los votos sean emitidos (es decir, que la mitad más uno de
los nodos estén operativos). La mitad se calcula redondeando hacia abajo,
de forma que hay una sensible diferencia entre que el número de nodos sea
impar o par. En la siguiente tabla se ve el número de nodos, cuantos votos
implican y cuantos nodos pueden estar caídos y sin que el cluster deje de
funcionar:
| Número de nodos |
Número de votos |
Nodos que pueden caer |
| 1 |
1 |
0 |
| 2 |
2 |
0 |
| 3 |
3 |
1 |
| 4 |
4 |
1 |
| 5 |
5 |
2 |
| 6 |
6 |
2 |
| 7 |
7 |
3 |
| 8 |
8 |
3 |
| 9 |
9 |
4 |
| 10 |
10 |
4 |
| 11 |
11 |
5 |
| 12 |
12 |
5 |
| 13 |
13 |
6 |
| 14 |
14 |
6 |
| 15 |
15 |
7 |
| 16 |
16 |
7 |
Si observamos la anterior tabla, este mecanismo beneficia
los clústeres de nodos impares, pues permiten tener caídos tantos nodos como
el clúster conformado por el número par inmediatamente superior a él (3 nodos
permiten la caída de uno, 4 nodos permiten la caída de uno); además, en el
caso de un clúster de dos nodos, no se puede caer ninguno de ellos. Por ello
está especialmente indicado para clústeres de nodos impares y para clústeres
distribuidos. Este tipo de clústeres no se recomiendan para clústeres
de 2 nodos o clústeres con un número par de nodos.
Para solventar el anterior comportamiento en clústeres
conformados por un número 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 número impar de votos a los clústeres con nodos pares,
y así optimizar el número de nodos que pueden estar caídos. Veamos la tabla
de número de nodos, votos y nodos que pueden caer:
| Número de nodos |
Número de votos |
Nodos que pueden caer |
| 1 |
2 |
0 |
| 2 |
3 |
1 |
| 3 |
4 |
1 |
| 4 |
5 |
2 |
| 5 |
6 |
2 |
| 6 |
7 |
3 |
| 7 |
8 |
3 |
| 8 |
9 |
4 |
| 9 |
10 |
4 |
| 10 |
11 |
5 |
| 11 |
12 |
5 |
| 12 |
13 |
6 |
| 13 |
14 |
6 |
| 14 |
15 |
7 |
| 15 |
16 |
7 |
| 16 |
17 |
8 |
De esta manera un clúster de nodos pares permite tantos
nodos caídos como el cluster de nodos impares inmediatamente superior
(6 nodos permiten 3 caídos, 7 nodos permiten 3 caídos); además de esto, es
factible que un clúster de dos nodos pueda seguir funcionando con uno caído.
Hay dos tipos de testigos:
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 quórum. Se puede confundir
el disco testigo con el tradicional disco de quórum, pero hay una importantísima
diferencia: si cae el disco de quórum, cae el cluster; si cae el disco testigo
no cae el cluster si hay la mitad más uno de nodos en funcionamiento. Por
todo ello, este tipo clúster está indicado para clústeres formados por
2 nodos o por un número par de nodos. No está indicado para los clústeres
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 clúster distribuidos en diferentes sitios y accediendo a diferentes
almacenamientos.
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 quórum, si no que almacena
qué nodos son los que tienen la copia más actualizada del quórum. Esto
provoca que sólo emita su voto a favor si ve presente al menos a uno de los
nodos con la última versión del quórum. El ejemplo más típico de este problema
es el siguiente:
- Tenemos un clúster de dos nodos (A y B), cada uno ejecutándose y sincronizados.
- Se apaga el nodo B.
- Realizamos cambios al clúster en el nodo A. Estos cambios están tan solo
en la copia del quórum del nodo A, al estar el B apagado y, por tanto, no
haber replicado.
- Se apaga el nodo A.
- Se enciende el nodo B. Como el nodo B no tiene una copia del quórum 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 clúster. No funcionará el clúster hasta que vuelva a funcionar el nodo
A.
Este tipo de clúster está indicado para todos los tipos de clústeres (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 solución en clústeres 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 clústeres.
También está indicado en clústeres distribuidos (de hecho es la mejor
opción en el caso de clústeres distribuidos), y siendo ubicada en otra localización
distinta a la de los nodos.
No está indicado en clústeres de un solo nodo.
Es el tipo de clúster “tradicional”. Como vimos anteriormente, la configuración
del clúster es almacenada en el disco de quórum, lo que permite que se
puedan caer n – 1 nodos del clúster y seguir éste funcionando. Lo malo es
que no permite la caída del disco de quórum, siendo un punto de rotura
único. En la siguiente tabla vemos la tolerancia del este tipo de quórum,
según los nodos, los nodos que pueden estar caídos y los fallos de disco de
quórum permitidos (ninguno):
| Número
de nodos |
Nodos
que pueden caer |
Fallos
tolerados del disco de quórum |
| 1 |
0 |
0 |
| 2 |
1 |
0 |
| ... |
... |
... |
| 16 |
15 |
0 |
| ... |
... |
... |
| n |
n-1 |
0 |
La tabla siguiente proporciona las recomendaciones de Microsoft, para el
tipo de quórum en clústeres distribuidos:
|
Recomendado |
No
Recomendado |
| Mayoría
de nodos |
X |
|
| Mayoría
de nodos y carpeta
compartida testigo |
X
(la mejor) |
|
| Sin
mayoría: Disk Only |
|
X |
Muchas de las ventajas de los clústeres distribuidos derivan en gran parte
del hecho de que trabajan de una forma algo diferente a los clústeres no distribuidos
(mono-sitio). La separación en la distancia de los nodos de un clúster
afectará las opciones del modelo de quórum elegido y a la configuración de
almacenamiento, red y datos en el clúster. 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 catástrofe. El servidor 2008
de Windows permite crear clústeres distribuidos en distancias ilimitadas,
haciendo la solución más resistente a los desastres locales, regionales o
aún nacionales.
Con el servidor 2008 de Windows, se puede desplegar un clúster distribuido
para automatizar el balanceo de servicios y aplicaciones en las siguientes
situaciones:
Un clúster distribuido de Windows Server 2008 tiene los siguientes atributos:
-
Las aplicaciones están configuradas
para balancear de la misma forma que en un clúster local. El servicio
de clúster dispone de una monitorización del estado de salud y detección
de fallos de aplicaciones, nodos y enlaces de comunicación.
-
El clúster dispone de múltiples cabinas
de almacenamiento, con al menos una cabina en cada sitio. Esto asegura
que en caso de fallo de algún 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 clúster están conectados
con el almacenamiento de forma que en el caso de faltar un sitio o un enlace
de comunicación, puedan acceder a los datos de ese sitio gracias a la replicación
de las cabinas. Es decir, en el caso de un clúster de dos sitios, los
nodos del sitio A están conectados al almacenamiento del sitio A y los nodos
del sitio B están 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 información
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 replicación entre cabinas.
En este modo de quórum, todos los nodos y una carpeta compartida testigo
tienen un voto para determinar la mayoría. Esto ayuda a eliminar el punto
de ruptura del viejo modelo que suponía el disco de quórum. Esto hace que
la mayoría de nodo y carpeta compartida testigo está especialmente indicado
para los clústeres distribuidos: un solo servidor de archivos puede servir
como testigo a múltiples clústeres (usando cada uno su propia carpeta compartida
testigo).
Supongamos que tenemos dos sitios físicos, sitio A y sitio B, cada uno con
dos nodos. Tenemos además una carpeta compartida testigo en un tercer sitio
físico. 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 clúster es
de cuatro nodos, su mitad más uno es dos y por tanto el clúster 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 clúster es de cuatro nodos, su mitad más uno es dos y por tanto
el clúster 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 clúster 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 caída
de la comunicación 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 clúster; si el sitio que está
incomunicado es, precisamente el A, el clúster 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 válido 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 mayoría (el procedimiento
lo encontramos en la sección “Troubleshooting: how to force a cluster to start
without quorum” de la guía paso a paso “Failover
Cluster Step-by-Step Guide: Configuring the Quorum in a Failover Cluster”)
Como podemos ver, el uso del modo de quórum de carpeta compartida testigo
permite la continuidad del clúster, en el caso de la caída completa de uno
de los sitios.
Si el uso de una carpeta compartida testigo no es posible, se puede aún
así utilizar el modelo de quórum por mayoría de nodo.
Supongamos que tenemos un clúster distribuido de cinco nodos, tres de los
cuales están ubicados en el sitio A y dos en el sitio B. Si hay una caída
de la comunicación 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 clúster válido. Los nodos en el sitio B pueden comunicarse entre
sí, pero, al sumar dos votos, no consiguen la mayoría, y dejan de prestar
servicio. Si el sitio que ha perdido los enlaces fuese el A, sería necesario
intervenir en el sitio B para eliminar el control de no mayoría (el procedimiento
lo encontramos en la sección “Troubleshooting: how to force a cluster to start
without quorum” de la guía paso a paso “Failover
Cluster Step-by-Step Guide: Configuring the Quorum in a Failover Cluster”).
Esta configuración es menos tolerante que la de mayoría de nodo y carpeta
compartida testigo en un tercer sitio, ya que la caída del sitio primario
causa la caída completa del clúster. Para solventar este problema, en
un clúster con mayoría de nodo, sería necesario un tercer sitio en el que
situar al menos un nodo, de manera que para obtener la mayoría, fueran necesarios
los votos de los nodos de al menos dos sitios; en el ejemplo anterior
podríamos 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.
Para que un clúster 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 información utilizada/generada por los servicios y aplicaciones
del clúster sea coherente en todos los sitios.
-
El software de cabina debe permitir
que se detecte el failover del clúster, de manera que cuando este se produzca,
las LUNs implicadas de las cabinas pasen, de manera automática, de lectura/escritura
a solo lectura, en la cabina a la que están conectados los nodos del sitio
que ha caído, y de sólo lectura a escritura en la cabina del sitio que asume
el servicio.
Veremos a continuación la replicación de datos en función de:
-
Niveles de replicación.
-
Tipos de replicación.
La replicación de los datos entre sitios puede estar hecha a tres
niveles:
-
Nivel de hardware (nivel de bloque):
la replicación es realizada por las controladoras de cabina o por el software
de espejo.
-
Nivel de sistema operativo (replicación
de los cambios en el sistema de archivo): el software de servidor realiza
la replicación.
-
Nivel de aplicación: la propia
aplicación es la encargada de realizar la replicación. Un ejemplo de ello
es la replicación continua de Exchange, es decir, Microsoft®
Exchange Server 2007 Continuous Cluster Replication (CCR).
El método a elegir para la replicación depende de los requerimientos de
negocio y de aplicación.
Existen dos tipos de replicación:
-
Replicación síncrona
-
Replicación asíncrona
En este tipo de replicación, 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 pérdida de datos en caso de caída de un sitio.
Si en el sitio A se escribe un bloque de datos, esta operación 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 replicación en clústeres distribuidos cuando se tienen
líneas de comunicación con un gran ancho de banda y una baja latencia.
En la práctica, esto limita este tipo de replicación a clústeres distribuidos
en los cuales la distancia entre sitios es corta.
La replicación síncrona protege de la pérdida de datos en caso de failover
en clústeres distribuidos, pero tiene en su contra la potencial latencia,
provocada por las operaciones de escritura y ACK. Debido a esta latencia potencial,
la réplica síncrona puede penalizar en exceso el rendimiento de las aplicaciones
de cara al usuario. De ahí lo que decíamos 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 aplicación no permite la latencia inherente a este tipo de replicación,
la replicación síncrona no es una opción aceptable.
En este tipo de replicación, 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 operación de lectura / escritura en el almacenamiento del
sitio y el software de replicación se encarga de modificar el almacenamiento
de del sitio B, para que refleje ese cambio, en segundo plano.
La replicación asíncrona es la mejor opción para obtener el máximo rendimiento
de las aplicaciones y servicios del clúster, pues no hay que añadir 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
clústeres distribuidos con grandes distancias entre los sitios, o con aplicaciones
que requieren una respuesta muy rápida, es la única opción viable.
El punto débil de la replicación asíncrona es que hay que asumir que en
el caso de producirse un failover, habrá pérdida de datos, pues todo proceso
de réplica que se esté efectuando es ese momento no será completado, con lo
que se verán perdidos los datos implicados.
Este problema de pérdida de datos de la replicación asíncrona hace que se
tenga que tomar en cuenta también cómo implementa el fabricante esta replicación.
Unos fabricantes la hacen respetando el orden de las operaciones y otros no.
Esta es una diferencia crucial, pues si la réplica 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 solución
es coherente ante roturas (crash consistent). De manera inversa, si
la replicación 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
clúster distribuido nunca debería utilizar réplicas asíncronas que no respeten
el orden de operaciones de entrada y salida.
Teniendo en cuenta todo lo que hemos visto en referencia a la replicación
entre cabinas, podemos establecer las siguientes recomendaciones:
-
Selección del nivel de replicación
(bloque, sistema de archivos o aplicación): se debe consultar a los
fabricantes del hardware y software para decidir cuál es el nivel de replicación
que más nos conviene según los servicios y/o aplicaciones que deseamos que
ejecute el clúster.
-
Configurar la replicación para evitar
la corrupción de datos: en el caso de que la replicación entre cabinas
sea asíncrona, ésta debe respetar el orden de las operaciones de entrada
y salida, pues poquísimas aplicaciones son capaces de recuperarse si los
datos de replicación están corrompidos.
-
No debe usarse Distributed File System Replication (DFR-S): no se
debe usar DFR-S como método para la replicación entre sitios pues DFR-S
sólo replica los ficheros una vez cerrados. DFR-S funciona muy bien con
ficheros como documentos, presentaciones y hojas de cálculo, pero no con
ficheros que deben permanecer abiertos, como bases de datos o máquinas virtuales.
-
Seleccionar entre replicación síncrona
o asíncrona: como vimos, aunque es más segura, por evitarse la pérdida
de datos, la replicación síncrona, si no se dispone del suficiente ancho
de banda y/o baja latencia en la comunicación entre sitios y las necesidades
de rendimiento de los servicios o aplicaciones que ejecuta el clúster no
permiten este tipo de replicación cuando no es rápida, nos veremos obligados
a configurar la replicación como asíncrona. Si este es el caso, se debe
tener en cuenta el segundo punto de estas recomendaciones.
Un mejora de la tecnología de clúster en Windows Server 2008 es la posibilidad
de que los nodos que componen un clúster pueden estar en diferentes subredes.
Al contrario de lo que sucedía en las versiones anteriores (Windows 2000 Server
y Windows Server 2003) los nodos de los clústeres de Windows Server
2008 pueden comunicarse entre sí a través de enrutadores de red, lo
que permite no estar obligado a que los nodos distribuidos geográficamente
estén en la misma VLAN, reduciendo la complejidad y los costes debidos
a la configuración necesaria para los clústeres 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 más rápido de lo que tarden los servidores
DNS en replicarse y lo que tarden los clientes en buscar la información 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. Además 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 harán recomendaciones para clústeres distribuidos
cuya configuración de red esté hecha en múltiples subredes.
Cuando el clúster no está en su propia VLAN, para optimizar la velocidad
de failover, de la réplica de DNS y de las búsquedas DNS, se deben ajustar
las configuraciones de Heartbeat y DNS, debido al tiempo de réplica de
los servidores DNS y expiración de consultas cacheadas en clientes, que vimos
anteriormente.
Para minimizar el tiempo de caída en un clúster distribuido deberemos:
-
Revisar qué opciones tenemos para
usar VLANs o múltiples subredes. Si usamos VLANs, evitamos los problemas
derivados de la replicación de DNS y la expiración de registros DNS cacheados
en el cliente, pues las IPs de servicios y aplicaciones no cambiarán. No
obstante, el uso de múltiples subredes puede ser mucho más simple que el
de VLANs a la hora de configurarlas y administrarlas.
-
Si decidimos utilizar múltiples
subredes, deberemos elegir entre dos estrategias para acelerar la resolución
de nombres, cambiar la propiedad TTL de servidores y clientes o
crear registros por cada una de las IPs:
-
Si decidimos utilizar múltiples subredes,
es conveniente que ajustemos la configuración de Heartbeat. Esta configuración,
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 más tolerante el
control entre subredes, espaciando los latidos y admitiendo más fallos.
Para ver cómo se configura consultar Configure Heartbeat and DNS Settings in a Multi-Site Failover Cluster.
Si tenemos un clúster distribuido en el que se ejecutan máquinas virtuales
de Hyper-v y el clúster está configurado en múltiples subredes, deberemos
tener en cuenta el direccionamiento de las máquinas virtuales que ejecuta
el clúster. Esto es así ya que, lo mismo que pasa con otros servicios en clúster
distribuido, en el caso de un failover será necesario que los clientes busquen
a las máquinas virtuales con otra IP distinta a la que tenían antes del failover,
ya que éstas han cambiado a otra subred. Esto implica que es necesario
que cada máquina que se vea implicada en un failover cambie de propiedades
de red (IP, máscara, puerta de enlace, DNS, etc.). Si las propiedades
de las máquinas son establecidas dinámicamente por medio de
DHCP, este cambio puede ser automatizado, en caso contrario
deberá realizarse de manera manual.
Por lo tanto sería muy interesante configurar las máquinas virtuales con
una IP dinámica, reservar en cada uno de los DHCPs de los sitios la IP correspondiente
a ese sitio para cada máquina 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 múltiples entradas en DNS para las diferentes IPs de las máquinas.
