Share via

Consideraciones sobre los Cluster Shared Volumes (CSV)

  • Article

Hola

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.

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:

Cualquier idea para profundizar en cualquiera de estos temas es bienvenida.

Saludos

David Cervigón

Comments

  • Anonymous
    January 01, 2003
    Hola Lo primero se trata de discernir si queréis continuidad de negocio (multi-site cluster) o un centro de respaldo. Para montar un multi-site cluster activo/activo se suele requerir replica síncrona del almacenamiento para poder garantizar los failovers en caso necesario. Hay algunos fabricantes de almacenamiento que permiten hacerlo en asíncrono, pero en cualquier caso sueles estar ligado al fabricante. También existe la posibilidad de usar sistemas de archivos distribuidos (como Sanbolic) o sistemas de replicación síncrona por software tipo Doubletake Si lo que se busca es simplemente un site de DR, donde el failover es manual y seleccionable a nivel de VM, puedes recurrir a Hyper-V Replica. Es replica asíncrona a través de redes IP, con posibilidad de llevarte también puntos de recuperación anteriores. Existe software similar de terceros que te permite replicar asíncronamente volúmenes enteros de diferentes fabricantes de almacenamiento para llevarte a otro sito los VHDs. Multi-site clustering e Hyper-V Réplica no son mutuamente excluyentes. Allí donde se necesite continuidad de negocio se usará multisite clustering, con su replica síncrona del storage, y allí donde podamos relajar los requisitos y permitirnos mayores RTOs y RPOs, Hyper-V Réplica es una excelente solución Saludos

  • Anonymous
    January 01, 2003
    Hola Jose, Hyper-V pausa automaticamente todas las VMs de un store cuando el espacio libre baja por debajo del 3-5%. Es conveniente por tanto monitorizar este parámetro y seguir la recomendación de no usar discos de crecimiento dinámico en producción en la medida de lo posible Alejandro El modo de redireccion de IO se activa cuando uno o varios nodos dejan de poder ver el almacenamiento por alguna razón. Entondec mandan todo el IO a trabes de la red interna del cluster para que las lecturas/escrituras las realice otro nodo que si que tenga acceso al storage Saludos

  • Anonymous
    January 01, 2003
    Hola Cuando hablamos de clústeres de host de virtualización en activo/activo nos referimos a que todos los nodos del cluster contienen maquinas virtuales arrancadas y dando servicio. Lo que haya dentro de ellas es irrelevante, y obviamente los servicios instalados en esas VMs pueden tener sus porpias estrategias de alta disponibilidad (balanceo de carga en red, replicación de bases de datos por software, Guest clustering...). Para este tipo de cargas de trabajo el cluster a nivel de hosts de virtualización sería realmente irrelevante Los grandes fabricantes de almacenamiento tienen tecnologías de virtualización de la SAN que hacen que los volúmenes que se presentan a los hosts queden abstraídos de las técnicas de replicación que haya por debajo. De cara al que monta sistemas por encima, es muy cómodo, porque no te tienes que ocupar tu de pensar en como vas a replicar los datos. En estos casos el multi-site cluster se monta igual que uno local. Todas las máquinas ven los mismos discos como si no pasara nada. Es lo mejor, pero también es lo mas caro Un cluster de maquinas virtuales hace que si algo falla la VM se levante en el otro nodo. Pero a la VM le estas dando un botonazo virtual. Las aplicaciones no son nunca aware de que se están ejecutando en una VM clusterizada. Si nos queremos proteger contra este tipo de fallos a nivel virtual, la solución será montar clústeres virtuales, o técnicas tipo Always On o log shipping. A este nivel debemos de olvidarnos de que estamos trabajando a nivel virtual y tratar a esas VMs como si fueran servidores físicos Todos los fabricantes de virtualización, y por supuesto ISVs, ofecen soluciones de V2V que sirven para convertir VMs de un formato a otro (no diría yo que V2V sea una buena técnica de recuperación de desastres). Para migrar de VMware a Hyper-V tienes desde System Center Virtual Machine Manager al Microsoft Virtual machine Converter. Lo mismo sucede para las herramientas de conversión de físico a Virtual. SCVMM es la herramienta de Microsoft que lo permite, pero hay otras en el mercado Sobre VMWare SRM, la solución de Microsoft es Hyper-V réplica que es está incluida en Hyper-V de forma gratuita. La generación de planes de prueba, y recuperación puedes hacerla desde System Center Orchestrator, o ahora también desde Windows Azure con los servicios de Hyper-V Recovery Manager (www.windowsazure.com/.../recovery-manager ) Saludos

  • Anonymous
    February 22, 2011
    ¿Tengo una duda? Que por centaje de espacio debemos dejar libre en un store o CSV

  • Anonymous
    December 16, 2011
    Hola. Impresionantes tus artículos David. ¿Que es exactamente la redirección I/O de disco? Saludos

  • Anonymous
    July 02, 2013
    Hola David, si queremos crear un centro de respaldo y utilizar características multi-site cluster, cómo podría hacerse? ¿se necesita imperiosamente la replicación de cabina de discos? ¿existen soluciones que no nos "liguen" a un proveedor específico de cabinas? Un cordial saludo y enhorabuena por tu blog y presentaciones.

  • Anonymous
    July 03, 2013
    Hola David, -cuando te refieres a activo/activo,  ¿realmente es mantener grupos de nodos dispersos por distintas localizaciones trabajando simultáneamente sobre la misma aplicación, o realmente, sería el caso de activo para ciertas aplicaciones X y pasivo para ciertas aplicaciones Y en el Sitio A y viceversa (aplicacions X pasivas y aplicaciones Y activas en el Sitio B)? -he visto algo sobre PLEX de EMC que supuestamente te monta algo como una SAN Virtual, pero no se si te permite tener replicación síncrona "bidireccional" para repartir nodos de un mismo cluster en activo/activo, ¿sabes algo sobre este tema? -Otra duda importante que tengo es: hay ciertas aplicaciones como SGBD como Oracle, MSSQLServer,... que aunque registran en sus bitácoras toda la información para la recuperación, mantienen mucha información en memoria y no se como resuelven la replicación de cabinas su replicación síncrona y si de alguna forma son "-aware" de las aplicaciones que se ejecutan o realmente les da lo mismo. Si no fueran "-aware" de la información y aplicaciones que están replicando supongo que la alta disponibilidad del cluster entre dos centros distantes implicaría un proceso de recuperación de la base de datos ¿no?

  • Anonymous
    July 03, 2013
    Perdón una última cosa, además de soluciones V2V para recuperación de desastres, ¿conoces soluciones para entornos P2V?  he oido algo sobre platespin y el caso de double take, pero me gustaría saber como funcionarían soluciones más escalares y con menos problemas de gestión y administración.  Por otra parte, ¿existe algo parecido para Microsoft como es el caso de SRM de Vmware, o las posibilidades que aporta Microsoft son las que discutes en tu blog y las presentaciones tuyas que he revisado? Gracias por tu inestimable ayuda y por compartir tu conocimiento y experiencia con todos nosotros. Manuel.

  • Anonymous
    July 04, 2013
    Gracias David por la información, entonces sobre soluciones P2P (p.e. el caso de servidores con Oracle o MSSQL muy castigados y a los que el Administrador de BBDD no desea migrar a Virtual u otro tipo de aplicativos), ¿qué alternativas o soluciones tecnológicas tendría?. Por otra parte, como te comentaba según he leido plate spin proporciona soluciones P2V, ¿pero no consiguo dilucidar si son realmente automáticas en el failover? ¿conoces soluciones P2V que se compoten de forma automatizada? No se si mezclo conceptos pero tus aclaraciones seguro que me ayudan a ir situándome en este complicado mundo. Gracias, Manuel.

  • Anonymous
    July 04, 2013
    Otra cosa, me comentas el uso de windows azure .... ¿están las soluciones de recuperación de desastres que proporcionais a las organizaciones tendiendo a montar nubes privadas?

  • Anonymous
    June 26, 2015
    Muy buen articulo David.

    Mi pregunta es la siguiente, en que escenario es mejor utilizar Shared Volumen VS DFSR.

    Gracias