Consideraciones sobre los Cluster Shared Volumes (CSV)

La fiebre por los clústeres que me rodea últimamente me anima a escribir algo acerca de los Cluster Shared Volumes, en adelante los CSVs. Intentaré explicar de forma sencilla su origen, lo que son, como funcionan y algunas cuestiones a tener en cuenta a la hora de implementarlos. Anteriormente ya escribí por aquí algunas cosas relativas al apasionante mundo de los “clústeres de conmutación por error de Microsoft” que no está de más citar en de nuevo en esta ocasión.

• Sobre Clusters de Hyper-V y clusteres virtuales
• Clústeres Virtuales (guest clustering)
• Herramienta de cosecha propia para dimensionar Failover Clusters (Beta)

Origen

Como es bien sabido, la primera versión de Hyper-V que se incluyó en Windows Server 2008 carecía de la capacidad de realizar migraciones en caliente de maquinas virtuales entre hosts. En su lugar teníamos Quick Migration (y por supuesto HA), pero cada máquina virtual debía residir en su propia LUN del almacenamiento compartido para que pudiesen migrar de manera individual. Como es bien sabido, el Failover Cluster de Microsoft siempre ha seguido un modelo de “shared nothing”, donde el almacenamiento compartido, si bien esta presentado a todos los nodos del cluster, solo su propietario actual tiene acceso en lectura/escritura permaneciendo en estado reservado y offline para el resto de sus compañeros. El failover de un disco supone un proceso que conlleva entre unos pocos cientos de milisegundos y algunos segundos, por lo que cualquier intento de migración en caliente que suponga llevar a cabo estas tareas tiene pocas probabilidades de cumplir su misión. Esta debió de ser la principal razón, y esto es conjetura mía, de que se decidiese posponer la implementación de Live Migration hasta la siguiente versión de Windows Server, la actual Windows Server 2008 R2, donde se han incluido los ya famosos CSVs. Su misión está muy clara. Se necesita un sistema que, sin renunciar al sistema de archivos NTFS, permita que múltiples nodos de un cluster accedan de manera simultánea al contenido del almacenamiento compartido. De esta manera no es necesario incluir al disco en el proceso de failover o migración en caliente de una máquina virtual, por lo que esta se facilita, se agiliza y de paso flexibilizamos la gestión del almacenamiento rompiendo la barrera de una máquina virtual por LUN.

MITOS:

• Los clusteres de Hyper-V R2 solo pueden usar CSVs: Falso. Las máquinas virtuales pueden seguir almacenadas cada una en su propia LUN y seguir el mismo esquema de migración que en la primera versión de Hyper-V
• Live Migration requiere CSVs: Falso. Puedes tener Live Migration en máquinas virtuales que viven en su propia LUN. Sin embargo esto no está recomendado por la razón que mencionábamos arriba. La Migracion se detendrá el tiempo necesario para conmutar el disco de nodo.
• Live Migration sustituye a Quick Migration: Falso, tu eliges que método de migración te viene mejor en cada momento. Los dos tipos de migración están disponibles en los dos esquemas de uso del almacenamiento. LUNs tradicionales y CSVs

¿Que es un CSV?

Desde el punto de vista del almacenamiento, un CSV no es más que una LUN que está presentada a todos los nodos del cluster. Punto. Es decir, que desde el punto de vista del almacenamiento, un CSV es una LUN de las que se vienen usando en un Failover Cluster de Microsoft toda la vida. La única salvedad es que va a necesitar utilizar reservas persistentes SCSI-3. Este requisito no es una cuestión relativa a los CSVs sino a cualquier LUN que se vaya a utilizar en un cluster de Windows Server 2008 o Windows Server 2008 R2. Generalmente en las cabinas se suele indicar cual va a ser el Sistema Operativo del equipo al que le estamos presentando la LUN. Es frecuente encontrar, como sucede por ejemplo en las EVAs de HP, tanto Windows como Windows Server 2008 entre las opciones del menú de las propiedades del host. Es importante elegir la opción de Windows Server 2008 o consultar con el fabricante de la cabina qué opción garantiza el uso de SCSI-3. Una vez todos los nodos del cluster ven la LUN es conveniente ponerla online en alguno de ellos para crear el volumen y formatearlo con NTFS si es que es necesario. Posteriormente se agrega al cluster como siempre se ha hecho, y va a parar al apartado de almacenamiento disponible. Como se puede observar, insistimos, nada hasta ahora es diferente de como se ha venido gestionando el almacenamiento en Microsoft Failover Cluster hasta la fecha, con la salvedad de lo del SCSI-3 que, repetimos, afecta a todo cluster de Windows Server 2008 y Windows Server2008 R2. La moraleja de esto es que los encargados de gestionar el almacenamiento no tienen que hacer curso alguno de reciclaje para poder montar un cluster de Hyper-V R2, con su Live Migration y sus CSVs.

Los CSVs no están habilitados por defecto en el cluster. Simplemente hay que ir a las propiedades del cluster y activarlos. Después de un aviso que nos advierte de que, a fecha de hoy, solamente Hyper-V es capaz de utilizarlos tal y como vamos a comentar a continuación, veremos que se nos ha creado una carpetita “Cluster Shared Volumes”, donde tenemos la posibilidad de agregar cualquier disco que aparezca como almacenamiento disponible dentro del cluster. Vamos a ver lo que sucede durante ese proceso y como funcionan los CSVs a partir de ese momento.

¿Cómo funciona internamente?

Lo que antes era una LUN solamente visible en un nodo se “monta” en un espacio de nombres que es común en todos los nodos: C:\ClusterStorage\VolumenX, donde X es un simple ordinal que crece a medida que vamos creando CSVs. Las máquinas virtuales se crean debajo de estas estructuras de nombres, preferiblemente ordenaditas cada una en su propia carpeta. Lo que cuelgue de cada “VolumeX”, esta compartiendo la misma LUN del almacenamiento. Lógicamente es un requisito que todos los nodos tengan el sistema operativo instalado en C:\ para que todo esto funcione. De esta manera todos los nodos son capaces de leer y escribir en, por ejemplo C:\ClusterStorage\Volume1\VM1, tanto los VHDs como los ficheros de configuración de las máquinas virtuales. De ese modo el Hyper-V de cualquier nodo del cluster puede en cualquier momento comenzar a “mover” máquinas virtuales. De hecho, a Hyper-V todo este jaleo le resulta completamente trasparente. Simplemente necesita tener acceso a los ficheros que componen una máquina virtual para ponerse a trabajar con ella.

DUDAS FRECUENTES:

• ¿Funcionan los discos Pass-Through bajo el esquema de CSVs?. Pues obviamente no, no podemos presentar a una VM un CSV en Pass-Through. Además carece totalmente de sentido porque lo que buscamos con un disco de este tipo es que la VM tenga acceso exclusivo a una LUN, y por tanto no andamos buscando que esta se comparte en ningún caso.
• ¿Son recomendables los discos de crecimiento dinámico?. No. Primero por la clasica razón de que estos discos tienen peor rendimiento y, segundo, porque el crecimiento desmedido del tamaño de uno solo de los discos puede llegar a tirar (pausar) todas las VMs que comparten la LUN si esta se queda sin espacio.
• Puede ese CSV volver a comportarse como una LUN normal?. Definitivamente si. Una LUN que es un CSV podría, llegado el caso, presentarse a un host stand alone, asignarle (o no) una letra de unidad, y trabajar con los ficheros que componen las máquinas virtuales con toda normalidad, e incluso levantarlas en ese nodo.

Bien, ya tenemos un volumen montado en lectura/escritura por todos los nodos del cluster, y dicho volumen está formateado con NTFS. ¿Que sucede entonces con los logs de transacciones, índices, bloqueos y demás cuestiones relacionadas con el sistema de archivos?. ¿Como se evitan las famosas corrupciones que han estado evitando todo este tiempo atrás mediante el sistema de “shared nothing”?. Pues, paradójicamente, todo esto se resuelve no haciendo posible que todos los nodos escriban a la vez en el sistema de archivos. Para ellos, cada CSV tiene un nodo designado como “coordinador”, y el, y solo el, es el encargado de gestionar el espacio de nombres del volumen, y la creación de nuevos ficheros. Sin embargo, existe un filter driver en cada nodo que es capaz de distinguir el I/O producido por estos accesos y operaciones “del explorador de Windows”, para entendernos, del derivado de las lecturas/escrituras rápidas sobre un fichero (en este caso los VHDs) que requiere Hyper-V para trabajar de manera eficiente. El primero es redirigido al coordinador del CSV a través de la red configurada con menor métrica en el cluster (generalmente la interna, o de heartbeat), mientras que el segundo pasa directamente al almacenamiento compartido a través ya de los drivers específicos de las controladoras que nos conectan con el almacenamiento (HBAs o NICs). Es decir, Hyper-V escribe directamente al almacenamiento compartido para leer/escribir en los VHDs, y todo lo demás pasa a través de la red para que sea el coordinador del cluster quien lo escriba. Por supuesto, puede cambiarse el coordinador de un CSV mediante un proceso similar al de un failover tradicional, pero que no interrumpe el funcionamiento de las VMs que residen en esa LUN.

PROBLEMAS FRECUENTES Y PROBLEMAS EVITABLES:

• Tradicionalmente, la red interna del cluster se configuraba enlazando únicamente TCP/IP a la NIC. La comunicación de red mencionada entre el coordinador del CSV y el resto de los nodos utiliza SMB. Por tanto las NICs dedicadas a esta red deben tener enlazados tanto el cliente de redes Microsoft como el servicio de compartición de archivos. Si te has olvidado de hacerlo lo notarás enseguida, porque no podrás ver el contenido de C:\ClusterStorage desde ningún nodo, salvo desde el que sea su coordinador en ese momento.
• Tradicionalmente, la red interna del cluster solo tenía que aguantar el heartbeat, por lo que 10 Mbs bastaba y sobraba. Sin embargo ahora vemos que cobra especial importancia, por lo que esta red nunca debería ser inferior a Gigabit. Además, si el numero de NICs presente en el sistema lo permite, la red elegida para Live Migration no debería coincidir con la red que se utiliza para redirigir el tráfico de los CSVs.
• Una consecuencia de todo lo explicado es que si necesitamos copiar ficheros a un CSV, por ejemplo para aprovisionar una nueva VM, debemos de hacerlo desde el nodo que sea su coordinador en ese momento. Así obtendremos el mejor rendimiento y, sobre todo, evitaremos saturar la red interna con el tráfico extra producido por la copia. Claro que lo mejor es delegar este tipo de consideraciones a System Center Virtual Machine Manager.
• En el caso de utilizar antivirus en la partición padre, es más que recomendable agregar C:\ClusterStorage a los paths que no se inspeccionarán, además de las demás exclusiones habituales.

La redirección del I/O de disco por la red tiene otra aplicación interesante (ver Demo de Live Migration, Cluster Shared Volumes y Redirected I/O) y es la capacidad de que un nodo del cluster pueda seguir moviendo una máquina virtual aunque los caminos de ese nodo con el almacenamiento se hayan perdido. Dicho de otra manera, si cortamos los cables de fibra o Ethernet que conectan un nodo con el almacenamiento compartido, este enrutará el I/O por la red hacia el coordinador del CSV para que sea este quien lo escriba. No es una situación deseable por un tiempo prolongado, pero nos dará tiempo a poner ese nodo en modo mantenimiento y evacuar las máquinas virtuales por Live Migration a otros nodos que funcionen correctamente para reparar el problema.

¿Cuantos y cómo de grandes?. ¿Cuantas máquinas por CSV?

Llegados a este punto sabemos que un CSV no es mas que una LUN normal desde el punto de vista del almacenamiento, en la que tenemos varias máquinas virtuales funcionando simultáneamente, movidas por los diferentes nodos del cluster ya que todos ellos pueden acceder a ellas en lectura/escritura. También sabemos que para el resto de operaciones relativas al almacenamiento existe un coordinador que garantiza la salud del sistema de archivos NTFS, y que para ello los nodos se redirigen el I/O utilizando de manera activa el protocolo SMB a través de la red del cluster con menor métrica (la interna).

Las preguntas que surgen ahora son relativas al diseño y la arquitectura del almacenamiento del cluster. Por suerte o por desgracia, no hay una recomendación de aplicación universal salvo la que todos conocéis. Utilizar la arquitectura más simple que cumpla todos los requisitos que se le piden a la solución. Y los que generalmente asoman es este tipo de ecuaciones son:

• Rendimiento
• Tolerancia a fallos
• Replicación / multi-site clustering
• Backup, recuperación ante desastres.
• Disponibilidad y aprovechamiento del espacio
• Etc.

La virtualización no agregaría ningún tipo de consideración adicional al diseño del sistema de almacenamiento si no fuera por el hecho de que vamos a superponer diferentes cargas de trabajo, que pueden tener el mismo o distintos patrones de uso del mismo. Es la combinación del conocimiento de dichos patrones y del comportamiento del propio sistema de almacenamiento sobre el que vayamos a trabajar el que nos dará la combinación adecuada. En este sentido conviene a veces olvidarse de la propia virtualización y pensar en cómo lo haría uno para el caso de una máquina física. Si en cargas de trabajo tipo bases de datos se suelen separar discos de sistema de los de datos y logs, y además estos últimos de ponen sobre sistemas de discos con más ejes y más rápidos, o en escritorios, Web Servers, Terminal Servers (con matices) el I/O es menos importante, ¿por que en las correspondientes máquinas virtuales iba a ser diferente. Como LUNs normales que son, los CSVs pueden crearse sobre agregados de discos rápidos o lentos, o con diferentes niveles de redundancia. Las máquinas virtuales pueden tener sus diferentes discos repartidos en diferentes CSVs. Pondremos pocas VMs por CSV si éstas son muy demandantes de I/O, y podremos subir la densidad de máquinas virtuales si por el contrario sus tasas de I/O son bajas, o si pensamos que no hay razón para que los picos de demanda vayan a coincidir en el tiempo. Y todas estas cábalas lo mismo no valen para nada si al final ambas LUNs acaban creadas sobre el mismo grupo de discos físicos, o estos no tienen velocidad suficiente. Es por tanto un ejercicio muy recomendable conocer de antemano qué es lo que se va a consolidar y sentarse a planificar todo esto con las personas que conozcan bien el sistema de almacenamiento y como puede exprimírsele todo el jugo.

Otra cosa importante a tener en cuenta es que los CSVs no son la panacea universal. Existen buenas razones para que una máquina virtual resida en su propia LUN, y que ésta se utilice en el cluster del modo tradicional. Este es el caso por ejemplo de las configuraciones en Geo-Cluster o multi-site cluster en los que haya replicación de cabinas por medio. Esto es todo un mundo y cada fabricante tiene soluciones específicas. Otro caso claro son las situaciones en las que por rendimiento queremos utilizar discos pass-through.

Las copias de seguridad o la tolerancia a fallos que podemos esperar del propio sistema de almacenamiento o del sistema operativo a nivel por ejemplo de sistema de archivos es otra factor que puede marcarnos un límite a la hora de decidir el número de CSVs que vamos a utilizar el en máximo número de máquinas virtuales que pondremos en cada uno de ellos. Por ejemplo, se puede extender en caliente el tamaño de un CSV. Hay que hacerlo primero en la cabina y luego a nivel de volumen en el nodo que sea coordinador. Con un buen numero de VHDs corriendo ahí, ¿no da un poco de “yuyu”?. No hay problema, hacemos antes un backup. ¿Cómo de grande es el volumen de datos?. ¿Que mecanismo vamos a utilizar?. ¿Snapshots de la propia cabina o una herramientas software compatible con CSVs?. En este ultimo caso, lo normal es que se haga máquina virtual por máquina virtual utilizando el sistema de VSS de cada uno de los nodos en los que están corriendo. Pero, al margen de otra diferencias, en ambos casos tenemos que considerar que durante el tiempo que dure el proceso de “snapshoting” el CSV se pondrá seguramente en modo redirigido, por lo que consumiremos ancho de banda de red interna y afectaremos al rendimiento de todas las máquinas que residan en esa LUN.

Conclusión y documentación

Espero haber sido capaz de despejar las principales dudas del funcionamiento de esta novedad de Windows Server 2008 R2 de las que, a fecha de hoy, solo se beneficia Hyper-V R2. Desafortunadamente para este tipo de cosas es muy complicado ofrecer recetas de validez universal, y en algunos entornos todo esto dista bastante de ser trivial. La facilidad o dificultad, el acertar o no, dependerá fuertemente del nivel de conocimiento y control que se tenga de todos los componentes que hemos citado.

Aquí os dejo una colección de enlaces que seguro que lo explican todo mucho mejor que yo:

• Using Cluster Shared Volumes in a Failover Cluster in Windows Server 2008 R2
• Requirements for Using Cluster Shared Volumes in a Failover Cluster in Windows Server 2008 R2
• Designating a Preferred Network for Cluster Shared Volumes Communication
• Recommendations for Using Cluster Shared Volumes in a Failover Cluster in Windows Server 2008 R2
• Backing Up Cluster Shared Volumes in a Failover Cluster in Windows Server 2008 R2
• Cluster Shared Volumes Events and Errors

Fuente: http://blogs.technet.com/b/davidcervigon/archive/2010/02/01/consideraciones-sobre-los-cluster-shared-volumes-csv.aspx

Jorge Díaz.