Herramienta de cosecha propia para dimensionar Failover Clusters (Beta)

Hola

He recibido en los últimos meses muchas consultas acerca de como dimensionar una solución de alta disponibilidad basada en el Failover Cluster de Windows Server 2008, generalmente relacionadas también con el mundo de la virtualización.

En este libro de Excel he intentado plasmar sin demasiadas pretensiones gran parte de las variables que se tienen que tener en cuenta para empezar. Me gustaría compartirla con vosotros para que comprobarais que no he metido la pata y me hicieseis sugerencias acerca de cómo mejorarla. El enlace está al final del post, como un adjunto.

Antes de nada, un par de aclaraciones previas. En primer lugar, este tipo de clúster esta pensado para ofrecer alta disponibilidad por tolerancia a fallos. Y dado que de lo que se trata es que si algún servidor falla o debe dejar de dar servicio por tareas de mantenimiento su pérdida pase lo más desapercibida posible, todo el sistema debe estar sobredimensionado para que los restantes miembros del clúster puedan asumir sin problemas su carga de trabajo. Esto hace que la solución sea cara, dado que la mayor parte del tiempo tendremos recursos que no estaremos utilizando para nada. La segunda es que éste es precisamente uno de los principales talones de Aquiles de todo esto. Tener recursos sin utilizar es algo que suele gustar poco a quienes han pagado dinero por ellos, y la tentación de dar trabajo a la infraestructura “ociosa” es muy tentadora. Pero si lo hacemos y algo sucede, harán una película sobre nosotros por no tener suficientes botes salvavidas para todos los pasajeros del barco.

Dicho esto, vamos a ver como se usa el juguete:

• Número de nodos: Entre 2 y 16
• Modelo de Quorum: Mayoría de nodos (para un número superior o igual a 3), mayoría de Nodos y Disco y mayoría de nodos y File Share. Sin entrar en demasiados detalles, en Windows Server 2008 el Failover Cluster usa un sistema mayorías, donde todos los elementos activos del clúster tienen un voto. Podemos perder elementos siempre y cuando el numero de elementos “vivos” supere al de elementos “caídos”. Si se pierde la mayoría, adiós al clúster. Además de los nodos, puede usarse como “witness) un disco compartido o un File Share. Cada uno de ellos tiene sus ventajas y sus inconvenientes, pero en la hoja solamente ponemos si usamos o no un witness, es decir, si usaremos solo mayoría de nodos o si nos apoyaremos en un elemento adicional.
• Máximo número de nodos en fallo: Esto indica el máximo numero de nodos que pueden caer antes de que se destruya el clúster por completo, y depende obviamente del numero de nodos y de si usamos o no un witness adicional, que suponemos siempre vivo, o que al menos no fallará simultáneamente con los nodos
• Número de nodos en fallo: Aquí entra en juego un apuesta personal, en función de lo optimistas o pesimistas que seamos. ¿A cuantos nodos caídos de manera simultánea me puedo llegar a enfrentar en la peor de las situaciones?. Fijaros que este puede ser de hecho el valor que hay que decidir en primer lugar, para a partir de ahí decidir cuantos nodos ha de tener mi sistema, y en ese caso tendremos que igualarlo al valor anterior.
• Reserva por host: esto representa el porcentaje de recursos que queremos reservar para que el propio host funcione correctamente y sea gestionable (agentes, backup, etc.)
• Número de nodos pasivos: Hay gente que considera buena idea tener nodos pasivos, listos para asumir la carga de trabajo en caso de que algo suceda. Nuevamente esta decisión depende de nuestro grado de optimismo y prudencia. Desde lo mas conservador (nº nodos activos = nº nodos pasivos) a lo mas atrevido (todos activos) todo es posible, siempre y cuando no violemos la máxima de no sobrecargar al sistema con mas trabajo del que puede asumir en caso de que suceda el fallo contra el que nos estamos intentando proteger.

Las cuentas que hace la hoja combinan todos esos parámetros de forma que nos indica cuanto podemos cargar cada nodo, tanto para configuraciones Activo/Activo (se ignora el número de nodos pasivos) como Activo/Pasivo (para el número número de nodos pasivos especificados). En el caso de que el numero de nodos que fallen sea mayor que el numero de nodos pasivos existentes, se sobreentiende que el resto de nodos activos han de asumir carga de trabajo.

Un par de ejemplos:

Dos nodos, con un witness adicional (necesario en este caso). Solo puede fallar un nodo, y si estamos montando un clúster es porque asumimos que puede fallar. Reservamos un 10% de los recursos de cada host para su propio uso.

El nada sorprendente resultado es que en una configuración Activo/Activo cada uno de los nodos deberá cargarse de servicios clusterizados hasta alcanzar un 45% de uso de recursos, y en una configuración Activo/Pasivo el nodo activo puede cargarse hasta el 90%. En ambos casos, si un nodo cae, el otro se queda con el 90% de carga, que es justo lo que queremos.

Vamos ahora a un caso menos trivial. 9 nodos, 8 activos y 1 pasivo, y pensamos que, todo lo mas, se nos pueden llegar a caer 3 nodos simultánemaente. En 9 nodos 5 son mayoría, luego podemos perder 4. Si ponemos un witness adicional nos salen 10 votos, pero en este caso una mayoría son 6 a 4, es decir, que solo podemos perder 4 nodos. Por tanto aquí usar o no un disco de quorum o un file share como witness es irrelevante:

En este caso, no deberíamos sobrecargar cada host activo con más de un 67% de carga de trabajo. Si prescindimos del nodo pasivo la cifra se reduce a 60%.

En la segunda hoja del libro hay una tabla rápida en la que la única variable es el número de nodos pasivos que puede ayudar a centrar un poco el tiro (o directamente nos acaba de confundir por completo):

La parte más discutible de todo esto es precisamente que significan esos porcentajes de carga de trabajo. En el fondo eso lo decide cada uno con mayor o menor acierto (el “performance tunning” es más un arte que una ciencia), pero digamos que representa una media ponderada de RAM, CPU, IO de disco e IO de red. Simplificando mucho las cosas, he incluido los dos primeros para hacernos una idea de lo que esto supone en términos de RAM en Gb y CPU en número de cores. Multiplicando por ese porcentaje nos saldrían los topes de memoria y el número de cores totalmente saturados (al 100% de CPU) que pueden llegarse a consumir por cada nodo y en total para todo el sistema clúster. La diferencia de estos valores con respecto al total de recursos disponibles es el precio que pagamos por la alta disponibilidad.

Hablando ahora de virtualización, ¿cuantas máquinas virtuales me caben si…?. Pues depende. Considerando (incorrectamente) una VM como un mero conjunto de RAM y CPU podemos echar unas cuentas rápidas. Apiñar VMs para intentar demostrar que en una solución equivalente metes más VMs que tu competidor es una práctica muy peligrosa. La cosa debe transcurrir al revés. ¿Que rendimiento deben dar mis máquinas virtuales?. ¿Cómo estaban/están dimensionadas en físico?. ¿Que usos medios de RAM y CPU utilizan?. En función de eso decidimos cuanta RAM y cuantos procesadores virtuales necesitaremos para cada VM, y luego ya podemos dividir.

Supongamos una estructura de VMs homogénea (VDI, servidores estandarizados, etc.). Tenemos la RAM en Gb de cada VM, el número de procesadores que queremos asignarles. Tenemos que decidir un ratio de procesadores virtuales por core físico. Lo normal es que un equipo no esté todo el rato al 100% de CPU. Si está al 25-30% podemos usar razonablemente un ratio 1:4. El numero máximo de VMs que podemos meter en la infraestructura será la que antes sature la memoria o los procesadores.

Veamos un caso. 16 nodos, 2 pasivos, 2 en fallo, con nodos de 32 Gb de RAM y dos procesadores quad-core, a los que les reservamos un 5%: VMs de 512 MB y un solo procesador:

Usamos por tanto 14 nodos y nos caben, redondeando a la baja, 30 VMs por host, y 420 en total. Fijaros que aquí mandan las CPUs. Subir el ratio a posteriori es trampa. Pero si metemos hosts de 4 procesadores quad-core la cosa sube a 60 VMs por host y 840 VMs en total, y en ese caso quien impone la limitación es la memoria.

Cuidado con estas cuentas. ¿Soportarán el almacenamiento y la red estas cantidades?. ¿Y nuestros debilitados corazones?.

Saludos

David Cervigón

P.D: Enhorabuena por llegar hasta aquí. Insisto. Repasadme las cuentas y comunicadme cualquier error o sugerencia que encontréis.

Clusters.zip

Comments

• Anonymous
  January 01, 2003
  Pues a Brad Pit le atravesaban el tendon con la flecha en la peli... :-) Gracias

• Anonymous
  May 29, 2009
  The comment has been removed

• Anonymous
  May 29, 2009
  Si es que ya no vamos a poder fiarnos ni de las pelis "históricas"...

• Anonymous
  May 30, 2009
  Cuidadín con los clusters que almacenan el quorum en un fileserver, hasta ahora al tener almacenado este es una cabina con comunicación de fibra o iscsi, no nos ha importado la velocidad de la comunicación de los nodos con el quorum, ahora la comunicación es más lenta y afecta desde los cables utp hasta el i/o del juego de discos del almacenamiento, pasando por el switch, por supuesto gigabit y si hay más de 500milisegundos mal vamos. ¡Saludos!.

• Anonymous
  February 10, 2015
  The comment has been removed

• Anonymous
  February 10, 2015
  tengo X usuarios concurrentes que ocupan 10 segundos por peticion
  tengo un trafico medio por peticion de YY kbs
  
  cuanta memoria tengo que tener, cpus, etc para atender al 90%