Posts anteriores:
Hola
Sin ningún lugar a dudas, el almacenamiento es una de las piezas clave a la hora de hablar de virtualización. El hecho de virtualizar un servidor no implica que la carga de trabajo que corra en el vaya a tener un patrón de uso del almacenamiento diferente al que utilizaría en físico. Y lógicamente, cuanto mayor sea la densidad de máquinas virtuales, mayor será la superposición de dichos patrones del host de virtualización hacia el sistema de almacenamiento. Hable de este tipo de cosas en este post acerca de los Cluster Shared Volumes:
Para el caso que nos ocupa, si queremos probar las funcionalidades de HA y Live Migration necesitaremos contar con almacenamiento compartido al cual accederán los hosts por Fiber Channel y/o iSCSI
NOTA: El uso de sistemas NAS basados en CIFS/NFS, si bien funciona con Hyper-V, no está oficialmente soportado por ahora. Para más información al respecto, este es el post de referencia, de la mano de nuestro compañero José Barreto: Failover Clustering for Windows Server 2008 Hyper-V with File Server Storage
En el caso de nuestro laboratorio, todo funciona a través de iSCSI (mucho más barato que FC) contra dos sistemas de almacenamiento. Uno de ellos está basado en Windows Storage Server 2008, que incluye el Microsoft iSCSI Target, y el otro es una cabina SAN que amablemente nos presta NetApp. Tenemos montados laboratorios similares basados también en cabinas Dell Equalogic, y EVAs y MSAs de HP (tengo muchas ganas de probar también las Lefthand). También conozco casos de entornos basados en otros Targets iSCSI basados en software, como los de StarWind.
El esquema que hemos seguido es el siguiente:
La obsesión de tener todo almacenado en la SAN es sencilla de entender. Rinde estupendamente y si además tu cabina deduplica, los ahorros de espacio son sencillamente espectaculares. Por otro lado, recordemos que queremos la máxima granularidad y aislamiento entre las piezas. Si alguien se carga algún servidor físico, o lo cambias por otro de diferentes características, sus máquinas virtuales no están en los discos locales. Y si alguien borra inadvertidamente alguna de las máquinas virtuales mencionadas anteriormente, sus datos críticos siguen disponibles en espera de que aprovisionemos un nuevo servidor virtual o restauremos el backup, que será mucho más ligero al carecer de un gran volumen de datos.
La conexión de los servidores físicos con el almacenamiento es una de las primeras tareas que hay que abordar en el montaje de estos entornos, y la experiencia dice que suele ser uno de los principales escollos técnicos. He aquí algunas pistas y trucos que pueden hacer que el proceso sea más sencillo:
Todas estas operaciones pueden llevarse a cabo antes o después de haber agregado el role de Hyper-V. Se siga el orden que se siga, si que es interesante haber pensado, antes incluso de instalar los hosts, acerca de qué tipo de almacenamiento vamos a tener a nuestro disposición y cómo vamos a utilizarlo. Como hemos dicho al principio, es una de las piezas claves a tener en cuanta a la hora de planificar lo que vamos a poder hacer y lo que no.
Saludos
David Cervigón
Poco vamos a poder contar que no esté ya contemplado en la guía que se acaba de publicar aquí:
Vamos a ver qué uso de la red hace una infraestructura de virtualización basada en Hyper-V, cómo se pueden utilizar las tarjetas de red del host en diferentes escenarios y como estos requisitos se hacen más importantes para el caso de los clústeres en las que se vaya a utilizar Live Migration.
En resumen, estas son las cosas que hay que saber:
En hosts stand-alone podemos trabajar bastante bien con una o dos NICs físicas, si el uso de red de las máquinas virtuales no va a ser intensivo. Por ejemplo:
Sin embargo, para los hosts que vayan a ser miembros de un cluster vamos a tener diferente tipo de tráfico
En la guía que tenéis enlazada al principio del post tenéis los pormenores de las diferentes combinaciones. Es evidente que en producción vamos a necesitar que los hosts estén bien cargaditos de NICs, máxime si encima el almacenamiento es por iSCSI, pero lo cierto es que es factible configurar todo esto con una única NIC.
En estas figuras representamos varias opciones para probar en nuestro entorno de laboratorio, para el caso de que tengamos cuatro NICs y para el caso de tener solo dos. Somos conscientes de que hay más combinaciones posibles:
En el caso de nuestro laboratorio, los blades de los que disponemos solo tienen 2 NICs, y además el almacenamiento compartido es iSCSI como veremos en el siguiente post. No nos queda otro remedio que usar este último modelo, pero además utilizamos la tarjeta también para el tráfico dirigido al almacenamiento compartido.
Como todo esto es ciertamente un poco lioso, he aquí una lista de pistas y trucos que os pueden venir muy bien para acelerar el proceso de instalación y configuración de los hosts y minimizar los quebraderos de cabeza en fases posteriores:
Como decíamos más arriba, muchos de estos pasos son funcionalmente innecesarios y puede dar la impresión de que estamos complicando innecesariamente el proceso de configuración de la red. Sin embargo ayudan mucho a familiarizarnos con el funcionamiento del sistema, y facilitarán cambios de configuración que queramos hacer a posteriori. Y si en algún momento nos las tenemos que ver con sistemas con un gran número de NICs destinadas a diferentes tareas, esta metodología puede resultar de mucha utilidad.
En este post vamos a intentar dar respuesta a algunas preguntas que surgen de manera frecuente a la hora de considerar los requerimientos del Directorio Activo y el/los controladores de dominio necesarios para abordar este tipo de pruebas:
Antes de continuar, puede que este otro post algo antiguo resulte de interés, aunque esté un poco fuera de este ámbito:
Virtualizar controladores de dominio
Lo cierto es que no hay mucho más que contar que no esté ya recogido aquí:
Donde colocar el/los DCs, si vamos a montar un nuevo Directorio Activo dedicado al entorno de virtualización
Aquí van varias opciones, con sus pros y sus contras:
Como expliqué en el post anterior, la idea inicial cuando empezamos a montar nuestro entorno de demos fue mantener el aislamiento de las diferentes piezas y su portabilidad individual. Por suerte contábamos con más de dos servidores, con lo que la decisión fue montar un DC virtual sobre un pequeño servidor ajeno al chasis. El DC en ese servidor empezó a tener ciertos problemas de rendimiento (memoria y E/S de disco) y lo transportamos a uno de los blades, almacenando su VHD en la cabina. En alguna ocasión hemos tenido que recablear, cambiar la alimentación, etc. tanto en la cabina como en el chasis y nos hemos encontrado con que, por ejemplo, o te acordabas de las IPs de las cosas o no tenías ni DNS, ni Directorio Activo ni más ayuda que “ping –a”. Dormiremos mucho más tranquilos cuando usemos ese (u otro) pequeño servidor como DC adicional, además de como punto único de gestión del entorno (en algún sitio hay que enchufar un monitor un teclado y un ratón).
Utilizando un Directorio Activo existente
Para utilizar un directorio activo ya existente hay que tener en cuenta dos aspectos:
En resumen, podremos usar un Directorio Activo basado en Windows Server 2003, con un nivel funcional 2003 nativo, renunciando únicamente a la funcionalidad de “Personal Virtual Desktop”.
Otras recomendaciones relacionadas con el Directorio Activo
Hay varias cosas que siempre es bueno tener a mano en estas ocasiones:
Se acaba de liberar esta guía de configuración de red para Hyper-V en entornos de alta disponibilidad y Live Migration
Tiene dos tablas ciertamente útiles:
Volveré sobre este tema en breve.
Inicio una serie de posts dedicados al montaje de plataformas de virtualización basadas en Hyper-V y gestionadas con System Center que puede servir de base para el montaje de entornos de laboratorio, centros de demostraciones, pruebas de concepto y pilotos en los que probar en conjunto todas las tecnologías de virtualización que ofrece Microsoft. Posteriormente pueden complementarse con multitud de productos de otros fabricantes que aporten nuevas funcionalidades y ventajas sobre todo lo expuesto aquí.
Aunque la base de la que partimos es nuestro propio laboratorio y algunas experiencias de realizar este tipo de pilotos sobre el terreno, esperamos poder ofrecer diferentes alternativas para que todo lo expuesto sea lo más extrapolable posible otras situaciones y en particular, para montar las pruebas de concepto que planteamos en este post:
Los temas que abordaremos en las próximas entregas serán los siguientes:
El objetivo es montar algo similar a esto:
En esta serie de posts nos centraremos en el montaje y configuración de los hosts de virtualización y en System Center, ya que toda la parte de virtualización de escritorios ya la documentamos aquí:
La arquitectura que se muestra en el diagrama anterior no es desde luego la única que se puede utilizar, y viene dada por una serie de consideraciones generales que tuvimos en cuanta en base a la situación que teníamos cuando nos pusimos a montar el entorno, y que luego han podido ir variando en el tiempo. Muchos de los productos pueden instalarse sobre el misma máquina virtual, reduciendo por tanto el número de ellas a cambio de aumentar sus requerimientos de memoria y CPU. Pero uno de los requisitos que nos impusimos cuando empezamos a montar todo esto es que los diferentes componentes deben mantenerse entre si lo más aislados posible, y que pudieran ser extraídos, transportados y reimplantados en otro entorno hardware diferente de la manera más transparente posible. Lo primero es importante a la hora de probar nuevas versiones de productos y aislar fallos entre diferentes componentes. Lo segundo es más discutible, porque “transplantar” el entorno no es algo que se haga todos los días, lleva también su tiempo y supone también llevarse las claves de los diferentes productos a otro sitio. Nótese que en una arquitectura real destinada a producción, lo anterior puede ser o no de utilidad, pero hay otras muchas cosas que considerar.
Las principales piezas afectadas por el requerimiento anterior son el Directorio Activo y SQL. La “transportabilidad” sugiere un único DC virtual, pero esto se acaba convirtiendo en un gran único punto de fallo. Lo trataremos en detalle en el próximo post, pero mi preferencia personal es tener un DC físico y otro virtual. Por otro lado, muchos de los productos que montaremos requerirán de una o varias bases de datos para funcionar. Ahorraríamos espacio y capacidad de proceso montando un único servidor de SQL Standard o Enterprise para SCVMM, SCOM, SCDPM, APP-V, pero en este caso hemos preferido que cada máquina virtual albergue su producto con su instancia de SQL (Express, salvo para SCOM que requiere un Standard o un Enterprise).
El número de servidores y sus características, así como la existencia o no de almacenamiento compartido son dos factores decisivos a tener en cuenta. Sin almacenamiento compartido no podremos montar ni HA ni Live Migration. Y el número de servidores y sus características nos permitirán montar más o menos cosas, y ser más o menos flexibles a la hora de hacerlo.
En este caso ponemos cuatro servidores no porque sean necesarios, sino porque eso es lo que tenemos :-). En este post y en este otro nos apañábamos con portátiles. Contamos además con almacenamiento compartido, que nos permite servir almacenamiento tanto a hosts como directamente a las máquinas virtuales (en verde en el dibujo). Como mínimo es recomendable trabajar con dos servidores y acceso a almacenamiento compartido (FC y/o iSCSI)
Nosotros por nuestra parte hemos decidido utilizar los cuatro servidores con Hyper-V de esta manera:
También podríamos haber optado, sin afectar a la funcionalidad, por:
Recordaros por último un consejo universal. Hagas lo que hagas intenta hacerlo simple. Huye de complicaciones innecesarias (principio KISS: Keep It Short and Simple, Keep It Simple and Stupid, o Keep It Simple, Stupid)
Como ya habíamos hecho anteriormente, queremos compartir aquí cómo concebimos las diferentes pruebas de concepto sobre virtualización, actualizadas a las versiones actuales de los diferentes productos. Estas documentos pueden usarse también como base para pequeños pilotos, laboratorios y centros de demostraciones. En este sentido, vamos a empezar a documentar en breve diferentes consideraciones acerca de cómo montar paso a paso este tipo de escenarios, usando como base nuestro propio laboratorio y algunas experiencias del mundo real.
Esperamos que os resulten de utilidad.
Ya se puede descargar de TechNet y MSDN el recién anunciado MDOP 2010:
Los clientes con Software Assurance pueden descargarlo desde el site de Microsoft Volume Licensing Site (MVLS)
Una de las principales novedades es la versión 4.6 de Microsoft Application Virtualization, con el esperado soporte a sistemas x64 tanto a nivel de cliente como del secuenciador, y por tanto también de las aplicaciones que se pueden virtualizar.
El cliente para Remote Desktop Services está disponible de manera gratuita aquí. Este cliente puede utilizarse para instalarlo en Terminal Servers 2008 x64 o Remote Desktop Services 2008 R2 aunque el resto de componentes de App-V sean de la versión 4.5
Podéis leer más acerca de las novedades de App-V 4.6 y MED-V 1.0 SP1 RC en el blog del grupo de producto:
Aprovechando este lanzamiento, he creado igualmente una página estática con enlaces a recursos sobre APP-V, que podéis encontrar aquí:
La intentaré mantener lo más actualizada posible aquí:
La he agregado también al apartado de Colecciones abajo a la izquierda, junto con la de Hyper-V.
Como de costumbre, cualquier contribución es bienvenida.
Hace tiempo que quiero empezar a aglutinar la información que más suelo utilizar en el día a día en páginas estáticas del blog, con la idea de tener todo a mano en el mismo sitio. He empezado con una dedicada mi propia colección de recursos de Hyper-V
El que los comentarios de la página estén deshabilitados no implica que no se pueda contribuir. Si alguien encuentra algo que considere interesante, puede enviármelo por correo y lo incluiré en alguna de las páginas que vaya creando.
Intentaré enlazar dichas páginas en algún lugar del frame superior o izquierdo, si es que soy capaz. Por ahora están a la izquierda, debajo del Archivo, en la lista de Colecciones
Hace unas semanas HP publicó una herramienta para dimensionar soluciones de Hyper-V, orientada sobre todo a escenarios de consolidación. Está disponible aquí:
Y hay mucha más información relativa al uso de hardware de HP con Hyper-V aquí:
La herramienta tiene su propio motor de actualizaciones, y de vez en cuando pide descargárselas y aplicarlas. Lo cierto es que es extraordinariamente completa en los detalles y en el enganche con todo tipo de servidores y cabinas de almacenamiento de HP. Solo le veo una pega, y es que no tiene en cuenta las configuraciones en alta disponibilidad. Claro que en estos casos los factores que entran en juego dependen mucho del tipo de arquitectura que se vaya a implementar.
Cuando la lanzamos, nos encontramos con que podemos construir una nueva solución o cargar datos de una sesión anterior
Cuando construimos una nueva solución, podemos cargar los datos de los servidores a consolidar, bien manualmente, bien desde lo que hayamos obtenido trabajando con diferentes versiones de la herramienta Microsoft Assessment and Planning Toolkit (MAP). Como se puede observar es necesario conocer parámetros del hardware y grado de utilización de los mismos de los servidores a consolidar.
Luego introducimos los siempre importantes parámetros acerca de como y cuanto planeamos utilizar el almacenamiento:
Los recursos que planeamos dejar para uso del propio host y la partición padre. Por defecto recomiendan un 20%, pero al trabajar con porcentajes, a mayor cantidad de recursos, menor porcentaje podemos reservar:
A continuación elegimos el modelo de servidor sobre el que consolidaremos. Es el momento de pedirle un poco mas de memoria o más NICs (buen sitio para introducir lo que necesitamos de más para temas de HA):
Y por último nos “compramos” la cabina de almacenamiento. La verdad es que así da gusto:
Y tras un warning en el que nos avisa que ninguna herramienta debería sustituir nuestras cabezas pensantes, por fin tenemos lo que andábamos buscando:
Podemos salvarlo, pero si le damos a los detalles de la configuración o al BOM nos saca un un formato perfectamente imprimible y presentable no solo un resumen de todos los parámetros que se han contemplado sino la lista de part numbers (y sus precios según el país en el que te encuentres) que necesitamos para montar nuestra infraestructura.
Por cierto, que por lo que veo hay otros Sizers específicos para Exchange 2010 y Sharepoint :
Con la colaboración de nuestros colegas de Citrix, hemos estado probando estos días la integración de XenDesktop 4 con Hyper-V a través de Virtual Machine Manager.
Para ello hemos montado tres nuevas máquinas virtuales con Windows Server 2003 R2 para albergar:
y varios Windows 7 y Windows XP que conforman los pools y maquinas virtuales personales que controla el bróker.
Hay tres buenas guías que facilitan el proceso de instalación y configuración:
Máquinas virtuales y servidores de terminales se alimentan de la virtualización de aplicaciones de Microsoft Application Virtualization (App-V) que ya teníamos implementada en el escenario descrito en esta serie de posts:
Una de las preguntas más frecuentes al hablar de centralización de escritorios es a cuantos usuarios puede dar servicio de manera cncurrente un único servidor. Independientemente de si se va a utilizar Remote Desktop Services o VDI para servir ese escritorio, y teniendo en cuenta que la primera solución escala infinitamente mejor que la segunda, la respuesta es un rotundo depende. Cada tipo de usuario, en función de las aplicaciones que usa, datos que maneja, resoluciones de pantalla y profundidad de colores, dispositivos redirigidos, etc. tiene diferente impacto en los recursos que su sesión consume, tanto a nivel de CPU y memoria de servidor como I/O de almacenamiento y comunicaciones. Y todo esto hay que analizarlo en una situación lo más parecida posible a la real para cada caso particular.
Para poder dar una respuesta fiable a este tipo de preguntas, hace unas semanas se liberaron las Remote Desktop Load Simulation Tools para realizar pruebas de carga sobre servidores de Remote Desktop Services en fase de piloto, en función de las variables mencionadas anteriormente. Recientemente se ha publicado un documento que recoge la metodología de medición, y algunos resultados reales que pueden ser extrapolados a otros tipos de usuarios y servidores de diferentes características que los utilizados para estas pruebas (véanse los apéndices y las tablas de las páginas 17 en adelante).
Por otro lado, ya existía un whitepaper similar acerca de las mejoras de rendimiento introducidas en RDP 7.0
Estoy pensando crear páginas estáticas en el blog con enlaces a documentación, guías y herramientas en torno a las diferentes tecnologías de virtualización de Microsoft.
Por supuesto las principales fuentes del saber para este tipo de cosas son las Libraries y TechCenters de Microsoft TechNet, donde se publica nuevo contenido literalmente a diario. Ayer me entretuve un rato en desplegar todos los elementos que hay para Hyper-V (existen contenido equivalente para VMM, SCOM, DPM, App-V, Remote Desktop Services, etc.) y darle al copy-paste esto es lo que obtuve:
Library
Ayuda Online
Está disponible en Connect:
Entre las principales novedades relativas a Hyper-V que incluye, se encuentran:
Voy a actualizar la Beta que tenemos instalada e intentaré escribir algo al respecto.
Esta tarde hemos echado unas horas con nuestros colegas de NetApp para refinar la configuración de una unidad FAS2050 que juega cedida en nuestras oficinas, para nuestro deleite. Actualmente todos los servidores con Hyper-V del laboratorio, tanto nodos de cluster como stand-alone, almacenan sus máquinas virtuales por iSCSI en esta cabina con resultados más que satisfactorios, teniendo sobre todo en cuenta que los blades no tienen más que dos interfaces de red y que solamente tenemos un switch pequeñito a Gigabit, de esos que vienen en el chasis.
En particular queríamos probar el nuevo SnapManager for Hyper-V y configurar los hosts y Virtual Machine Manager con las versiones necesarias de SnapDrive y las Windows Host Utilities. La idea es aprovechar mejor la capacidad de la cabina de hacer snapshots cosnistentes a nivel de aplicación, simplificar la gestión del almacenamiento en las tareas del día a día y conseguir que los despliegues de las máquinas virtuales y sus movimientos entre hosts que no pertenezcan al mismo cluster se hagan mediante operaciones de la cabina (SAN Transfers) en lugar de por la red.
Todo ello está explicado en este par de excelentes guías que contienen la configuración paso a paso de la cabina, Hyper-V y Virtual Machine Manager, y además un montón de enlaces y bibliografía relacionados con estos temas. Hay parte de la información que obviamente se centra en explotar las funcionalidades específicas de las cabinas de NetApp, pero hay otras muchas consideraciones que se pueden extrapolar fácilmente a otros sistemas de almacenamiento.
Adicionalmente tenemos este par de documentos relacionados con la integración existente con System Center Operations Manager y System Centar Data Protection Manager:
Agradecimientos especiales a Jorge, Javier y Raúl por la colaboración prestada y por ayudarnos a seguir profundizando en estos temas.
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
MITOS:
¿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.
DUDAS FRECUENTES:
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.
PROBLEMAS FRECUENTES Y PROBLEMAS EVITABLES:
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:
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.