Terminamos diciendo en «Guest Clustering o la redundante HA» que al iniciar por primera vez nuestros nodos virtuales, el cluster no se iniciaría… lógico, aun nos quedan un par de cosas por construir.

1.- Desde el Administrador de Hyper-V, crea un conmutador virtual interno para cada anfitrión de hyper-v y por eso de ser rigurosos vamos a llamarlos igual, por ejemplo, Red Interna HB TestVM1 y en el otro anfitrión Red Interna HB TestVM2.

Aclaraciones: Éste conmutador interno solo se puede usar entre las máquinas virtuales que se ejecuten en el mismo anfitrión de hyper-v y entre las VM y el equipo físico. Un conmutador virtual interno no ofrece conectividad a una conexión de red física. Deberás habilitar el truncking entre los servidores físicos para que tengan comunicación por la vlan destinada al HB del guest cluster.

Su propósito va a ser dotar al guest cluster de un interfaz para la red de heart beat.

2.- A esta alturas ya puedes apagar tu cluster físico e iniciar el guest cluster. Cuando lo inicies, no olvides instalar los componentes de integración, después configura las redes del guest cluster, (el virtual swith dedicado a Gestión y el virtual swith interno dedicado a HB)

3.- Ves al administrador de discos, y pon en línea los discos de quorum, spool así como cualquier otro disco que contenga tu cluster y que ambos nodos virtuales deben poder ver y acceder.

4.- Abre el administrador de cluster. Dirigirte al apartado Discos y elimínalos. Tranquilo, la migración P2V fue tan exacta que se trajo hasta las viejas lun de los discos físicos que ya no tienes ni existen. Una vez que los elimines y si hemos hecho todo bien, podrás agregar nuevo almacenamiento al cluster, añade los discos virtuales y tus servicios de cluster deberán comenzar a funcionar.

Un par de pruebas; Balancea los recursos y servicios cluster entre los nodos virtuales… si funciona, vamos bien encaminados, finalmente apaga un nodo virtual y vuélvelo a iniciar, si arrancan sin errores, ya tienes un guest cluster con la redundante alta disponibilidad que un CSV te ofrece.

Si al reiniciar o apagar un nodo virtual del guest cluter no se inicia, revisa que los discos virtuales SCSI, estén compartidos y sean de tamaño fijo.

Hace poco quise migrar un servicio de impresión de alta disponibilidad de Windows 2008 R2 a Windows 2012 R2

El concepto, Cluster de Impresión, en alta disponibilidad, se anula en Windows 2012, porque el servicio de spool o cola de impresión deja de ser, ya no es un recurso cluster. Aun así, desde el punto de vista empresarial, continua existiendo la necesidad de disponer de un servicio HA para imprimir, máxime si una parte importante del core de tu negocio se basa en sacar facturas en formato papel impreso, por mucho que nos esforcemos por ser ecológicos.

Bueno, a grandes males, grandes soluciones. Desde la salida de Windows 2012 la impresión de HA, el Guest Clustering se convierte en la combinación de las tecnologías de cluster de conmutación por error de Microsoft y las tecnologías de Hyper-V para hacer de un servidor de impresión virtual de Windows Server 2012 un «HA».

Pero ATENCIÓN… puestos a rizar el rizo, encontré que mi viejo servicio de impresión Windows, usaba el servicio LPD, el cual permite que los equipos basados en UNIX u otros equipos que usen el servicio LPR, como gestor más inteligente de las colas de impresión, tipo PaperCut, puedan imprimir en las impresoras compartidas de Windows. Y ahora, ¿qué?

Tenemos dos opciones, o cambiamos el servicio LPD/LPR de la empresa, cosa poco probable o aplicamos de nuevo la misma máxima, a grandes males, grandes soluciones, de ahi el título de ésta entrada del blog, la redundante alta disponibilidad, Guest Clustering sobre un CSV de hyper-v.

Ésta fue mi fórmula;

P2V –> *.vhd –> *.vhdx –> CSV –> HDD (Fijo)

La explico.

Convierte tus nodos de cluster en nodos virtuales mediante P2V. Pero Ojo: P2V se descontinua en SCVMM 2012 R2. Para poder hacer un P2V con SCVMM necesitarás tener la versión 2012 y además tendrás que disponer y descubrir un servidor de hyper-v con el agente de 2012. Con eso, puedes comenzar con tu plan de migración de físico a virtual mediante P2V.

La migración habrá generado «n» discos virtuales vhd.

Si vas a migrar los nodos a un entorno de CSV con W2K12R2 es muy recomendable convertir los discos virtuales a vhdx Para ello desde Power Shell ejecuta los siguientes comandos:

PS C:\> Convert-VHD –Path c:\test\abbvhd.vhd –DestinationPath c:\test\abbvhdx.vhdx

Dependiendo del tamaño de los discos a convertir, ármate de paciencia y asegura el espacio en el disco físico para no quedarte sin él, ya que será aproximadamente un 5% mayor que el vhd.

Una vez convertido el disco lo movemos a nuestro recurso ClusterStorage del CSV y lo agregamos al cluster. Es muy posible que el resultado sea: una pequeña partición vhdx de arranque, una partición con el vhdx del sistema operativo y los discos compartidos del cluster incluido el de Quorum.

Antes de iniciar tu Cluster virtual necesitas lo siguiente:

1.- Configurar los discos que formarán tu Guest Clustering en el CSV de Hyper-V como discos SCSI

2.- Aunque se soportan discos de expansión dinámica es muy recomendable que los conviertas a discos de tamaño fijo.

3.- Comparte el disco vhdx para los recursos que formen el cluster (ej. disco de quorum y spool, además de cualquier otro que puedas tener), para ello:

3.1.- En la configuración de la máquina virtual, en Controlador SCSI, expande la unidad de disco que has creado.

3.2.- Haga clic en Características avanzadas

3.3.- En el panel de detalles, seleccione la casilla Habilitar uso compartido de discos duros virtuales

3.4.- Haga clic en Aplicar y, a continuación, haga clic en Aceptar. (Ni que decir tiene que la VM debe estar apagada cuando andes tocando el disco)

3.5.- Agrega el disco duro virtual a cada máquina virtual que vaya a usar el archivo .vhdx compartido. Al hacerlo, repite este procedimiento para habilitar el uso compartido de discos duros virtuales para cada máquina virtual que vaya a usar el disco.

Si prefieres hacer mediante consola de Power Shell, aquí tienes el comando para CSV:

Add-VMHardDiskDrive -VMName VM1 -Path C:\ClusterStorage\Volume1\Data1.vhdx -ShareVirtualDisk

El siguiente comando agrega un disco duro virtual compartido (Witness.vhdx) que está almacenado en un recurso compartido de archivos SMB (\\Server1\Share1) a una máquina virtual denominada VM2.

Add-VMHardDiskDrive -VMName VM2 -Path \\Server1\Share1\Witness.vhdx -ShareVirtualDisk

Ahora viene cuando tienes que apagar tu cluster físico, arrancar el Guest Clustering y descubrir que tu recién migrado y montado entorno virtual no funciona. Bueno, tranquilos, tiene su explicación que podréis leer en la siguiente entrada.

Hablamos de una característica que podemos usar para replicar máquinas virtuales (en adelante VM) como parte de una solución de continuidad del negocio. Réplica de Hyper-V proporciona una replicación asincrónica de las máquinas virtuales de Hyper-V entre dos anfitriones o servidores host y lo más importante, no requiere almacenamiento compartido ni ningún hardware de almacenamiento en particular.

Antes de replicar una máquina virtual, hay que habilitar un servidor que ejecute Hyper-V como, «servidor de réplicas», el propósito, un servidor disponible para recibir la VM replicada.

Si ya lo tenemos, lo siento pero nos toca modificar la configuración de replicación del servidor. Desde el Administrador de Hyper-V, abrimos el Configuración de Hyper-V y vamos a la página Configuración de Hyper-V, seleccionamos Configuración de replicación y marcamos la opción, Habilitar éste equipo como servidor de réplicas.

Una vez habilitado el servidor de réplicas, podremos configurar una VM para replicación. A partir de aquí publicaré el paso a paso para configurar la replica de las VM en Hyper-V.

Antes de nada, invitaros a la web de TechNet de Microsoft en http://technet.microsoft.com/es-es/library/hh831487.aspx donde encontrareis detallada y actualizada información sobre Data de Desduplicación.

Todos hemos experimentado como los datos de almacenamiento aumentan a velocidades increíbles, donde de nuevo incidimos en el coste de almacenamiento en disco, que aun habiendo disminuido, en tiempos de recortes, nunca es lo suficientemente rápido como para compensar el crecimiento en archivos de datos, lo que hace que la eficiencia de almacenamiento sea un requisito crítico.

Para sobrellevar este crecimiento en almacenamiento de datos ó archivos, consolidamos, centralizamos servidores y hablamos de nubes privadas y/o públicas donde nos servimos de la commodity de la virtualización, todo para escalar y optimizar que la capacidad sea un objetivo clave para una plataforma de consolidación. Windows Server 2012 y 2012R2 ofrece como ayuda aliada la deduplicación de datos.

Características Principales

Optimización de capacidad Para ello hace lo que precisamente indica su nombre, almacena más datos en menos espacio físico. La deduplicación de datos usa fragmentación y compresión de tamaño variable de subarchivos, que juntas ofrecen relaciones de optimización de 2:1 para servidores de archivos generales y de hasta 20:1 para datos de virtualización.

Escala y rendimiento. La deduplicación de datos es muy escalable, eficiente en materia de recursos y no intrusiva. Puede ejecutarse en varios volúmenes grandes de datos principales de manera simultánea sin afectar a otras cargas de trabajo en el servidor. Su bajo impacto en las cargas de trabajo del servidor se mantiene al limitar los recursos de CPU y memoria consumidos. Además, como vimos en el post «DATA DEDUPLICACIÓN en Windows Server 2012 R2 – Parte I de II» los usuarios con credenciales de administrador tienen la flexibilidad de establecer los tiempos en que debería ejecutarse la deduplicación de datos, especificar los recursos disponibles y establecer directivas de selección de archivos.

Confiabilidad e integridad de datos. Cuando se aplica la deduplicación de datos, es fundamental mantener la integridad de los datos. Para ello, Windows 2012 y 2012R2, aprovecha la suma de comprobación, la coherencia y la validación de identidad a fin de asegurar la integridad de los datos. Además, para todos los metadatos y los datos referenciados con más frecuencia, ésta deduplicación de datos mantiene la redundancia para garantizar que los datos puedan recuperarse en caso de corrupción de datos.

Mejora de ancho de banda en conjunto con BranchCache. Si además lo integramos con BranchCache, se aplican las mismas técnicas de optimización a los datos transferidos a través de la WAN. El resultado son tiempos de descarga de archivos más rápidos y consumo reducido de banda ancha.

Administración de optimización con herramientas familiares. 2012/2012R2 tiene la funcionalidad de optimización incorporada en el propio Administrador del servidor y por su puesto en PowerShell. Ya con la configuración predeterminada proporciona ahorros de inmediato y puedes optimizar las opciones para obtener mejores resultados.

En todo esto un apunte de Precaución o Advertencia
La deduplicación de datos es una característica que procesará de manera potencial todos los datos en un volumen seleccionado, de modo que debe realizarse una planeación cuidadosa para determinar si un servidor y los volúmenes conectados son candidatos adecuados para la deduplicación antes de habilitar la característica. Importante asegurarnos antes la disponiblidad de un backup-restore.

Por ejemplo, si con todo lo que hemos contado estas pensando en implementar Data Deduplicación en Exchange Server, porque tienes BD de gran tamaño, siento decirte que la deduplicación no esta soportada, puedes optar por ReFS, pensado para archivos grandes, pero tendrías que deshabilitar las características de integridad de las BD, aquí encontrarás más información al respecto: http://technet.microsoft.com/en-us/library/ee832792(v=exchg.150).aspx

Algo más acerca de la deduplicación de datos

La deduplicación de datos implica detectar y quitar la duplicación en los datos sin comprometer su fidelidad o integridad. El objetivo es almacenar más datos en menos espacio al segmentar archivos en pequeños fragmentos de tamaño variable (32–128 KB), identificar fragmentos duplicados y mantener una sola copia de cada fragmento. Las copias redundantes del fragmento se reemplazan por una referencia a una sola copia, los fragmentos se organizan en archivos contenedores y los contenedores se comprimen para lograr una mayor optimización del espacio.

Después de habilitar un volumen para deduplicación y de optimizar los datos, el volumen contiene lo que podemos resumir en cuatro items:

1.- Archivos no optimizados (es decir, archivos omitidos, por ejemplo: archivos de estado del sistema, archivos cifrados, archivos con atributos ampliados, archivos más pequeños que 64 KB y archivos de punto de reanálisis, archivos optimizados previamente que contienen punteros a los fragmentos respectivos en el almacén de fragmentos necesarios para construir el archivo)

2.- Archivos optimizados (almacenados como puntos de reanálisis)

3.- Almacén de fragmentos (los datos de archivos optimizados)

4.- Espacio libre adicional (porque los archivos optimizados y el almacén de fragmentos ocupan mucho menos espacio del que ocupaban antes de la optimización)

El resultado de todo esto es una transformación en disco de cada archivo. Después de la deduplicación, los archivos ya no se almacenan como secuencias de datos independientes, sino que se reemplazan por rutas internas que apuntan a bloques de datos almacenados en un almacén de fragmentos común. Dado que estos archivos comparten bloques, esos bloques solo se almacenan una vez, lo que reduce el espacio en disco necesario para almacenar ambos archivos. Durante el acceso a archivos, los bloques correctos se ensamblan de manera transparente para proporcionar los datos sin que la aplicación que llama ni el usuario tengan conocimiento del cambio en la transformación en disco realizada en el archivo. Esto nos permite a los administradores aplicar la deduplicación a archivos sin tener que preocuparnos por cualquier impacto o cambio en el comportamiento de las aplicaciones o el acceso de los usuarios a esos archivos.

Puedes usar deduplicación de datos en archivos replicados mediante el uso de DFSR (replicación DFS) porque solo se actualizan las partes de los archivos que cambiaron desde la última replicación.

Arquitectura
La característica de deduplicación de datos consiste en un controlador de filtro que supervisa las E/S locales y remotas, y un servicio de deduplicación que controla tres tipos de trabajos que están disponibles (recolección de elementos no utilizados, optimización y limpieza).

Es importante recordar que el ámbito de la deduplicación es compatible con clústeres, y que la característica de deduplicación está diseñada para ofrecer mejores resultados en datos principales con una optimización en segundo plano programada, controlada por politicas.

Inherente a la arquitectura de deduplicación es la resistencia frente a errores de hardware y bloqueos, con validación total de suma de comprobación en datos y metadatos, incluida la redundancia para metadatos y los fragmentos de datos más populares.

Hasta no hace mucho tiempo, hablar de virtualización era sinónimo de debates con los administradores de los sistemas de almacenamiento.

Mas allá de los costes y donde a nivel usuario no es difícil adquirir discos de varios TB ó inclusive discos de estado sólido, no ocurre así cuando a nivel empresarial nos vamos a discos de almacenamiento en cabina, máxime si son de fibra, donde los costes realmente se disparan y multiplican.

Para los que trabajamos en entornos de Cloud y de Virtualización, sobre todo con muchas máquinas virtuales iguales ó muy parecidas, nuestra luchas con los problemas de espacio por el almacenamiento se han terminado.

Hablemos de Data Deduplication

Si tienes varios cientos ó miles de VDI y máquinas virtuales, muchas de ellas con el mismo sistema operativo sólo que con diferente configuración y servicios, y muchas de ellas usadas como base para la creación de otras, dispones del escenario perfecto para implementar Data Deduplicación, archivos grandes, tipo vhdx que cambian poco o nada y con mucho contenido en común, es el escenario idóneo para lanzarte a montarlo.

Agrega el Rol de W2K12 o W2K12R2, Desduplicación de datos, que puedes encontrar los Servicios de archivos y almacenamiento / Servicios de iSCSI y archivo.

Una vez agregado el Rol, desde el administrador de Discos o Volúmenes de Windows, botón derecho sobre tu disco de cabina (ó no) de almacenamiento y configura la desduplicación de tu disco, en mi caso es el disco H:\

En éste punto hay una diferencia entre Windows 2012 y Windows 2012 R2.

La opción de marcar o desmarcar “Enable data deduplication”, solo está presente en Windows 2012.

En Windows 2012 R2, como veis en la imagen anterior, esa opción no está, por el contrario, podremos excluir aquellos ficheros que consideremos susceptibles de no ser desduplicados y por su puesto establecer la programación “Set Deduplication Schedule …” ó «Establecer programación de desduplicación…», al abrirlo podemos ver que por defecto está marcada la opción trabajará sobre archivos que tengan más de 5 días sin cambios. Si queremos ver el efecto ahora mismo, simplemente ponlo a 0 días, Aplicar.

Si crees que esperar la programación de la tarea a las 23:00 horas ó en segunda instancia a las 15:00 como he puesto a modo de ejemplo, implica mucho tiempo, puedes utilizar PowerShell para ejecutarlo manualmente en este mismo momento, abrimos la consola PowerShell y escribimos, donde H:\ será tu disco;

start-DedupJob H: –type optimization

Esperar un momento y a continuación podemos consultar el estado de des duplicación con dos comandos:

get-DedupJob

get-DedupStatus

Personalmente, no pude por más que frotarme los ojos al ver las trazas de log sobre un disco de 500 GB con 12 vhdx de 30 GB c/u, la primera al principio de aplicarlo, con 120,31 GB de espacio libre en disco y la segunda con 409,19 GB de espacio libre en disco a los pocos minutos, casi 300 GB de espacio ahorrado en disco.

FreeSpace    SavedSpace   OptimizedFiles     InPolicyFiles      Volume

———    ———-   ————–     ————-      ——

120.31 GB    0 B          0                  0                  H:

FreeSpace    SavedSpace   OptimizedFiles     InPolicyFiles      Volume

———    ———-   ————–     ————-      ——

409.19 GB    295.67 GB    12                 13                 H:

Si no lo has hecho ya, implementa éste rol del cual hablaré un poco más en una segunda entrada.

La Memoria, es uno de los aspectos más críticos que pueden existir en un entorno de virtualización, entender bien la arquitectura de memoria de Hyper-V, nos permitirá comprender mejor como aprovechar los recursos y obtener el mejor rendimiento posible, sin olvidar que junto con la CPU vs. Virtual Processor, la Red y el Almacenamiento, conforman un tanto por ciento muy grande de lo que es la virtualización.

Memoria Física del Host

Parece lógico pensar que la mayor cantidad de memoria es el parámetro más importante sobre la memoria, pero no olvidemos que la velocidad y la latencia de la memoria son siempre importantes en un host de virtualización, donde lo normal sería sacrificar si es necesario estos otros aspectos con el fin de obtener más cantidad de memoria al mismo precio, donde lo realmente importante es equilibrar la configuración del host para poder obtener el mejor coste por VM posible. Podemos obtener más memoria a menor precio con memoria más lenta y de igual forma podemos tener memoria más rápida al mismo precio reduciendo la cantidad de memoria.

¿Cómo se traslada esto al uso de la memoria en Hyper-V?,

Un ejemplo; Memoria DDR-3 a 1333 MHZ es capaz de mover 35 GB/ps, mientras que a 800 MHZ sería capaz de mover 25 GB/ps, sé que son cifras muy altas, y podemos encontrarnos con algunos otros buses en el sistema que serán cuello de botella más tarde y puede que finalmente estas cifras terminen rebajándose a 8GB/ps reales. Tengamos en cuenta en cualquier caso que en un servidor físico toda esa velocidad está al servicio de un único sistema, mientras que en un servidor de virtualización estará al servicio de hasta 384 VMs por servidor con Hyper-V.

La recomendación parece clara, evaluar cuidadosamente la elección de memoria, porque la elección que hagamos puede tener impacto en el rendimiento de la memoria, ya que por ejemplo algunos módulos de memoria pueden forzar al sistema a rebajar la velocidad del bus para todos los módulos y por tanto seria tirar el dinero mezclar memoria rápida con memoria lenta.

Si estás pensando en ampliar la memoria del servidor, ten en cuenta los bancos de memoria que quedan libres en el servidor, con la configuración de memoria que necesites para tu entorno de virtualización. Es muy posible que sea mejor negociar con tu proveedor la recompra de la memoria que tienes y adquirir la misma memoria con las prestaciones que necesitas.

Máximos de Memoria en Hyper-V

Hyper-V se presenta en dos sabores: 1.- Versión dedicada y gratuita “Hyper-V Server” que contiene todas las funcionalidades de Hyper-V pero ningún derecho de licencias. 2.- Como un rol del OS que activaremos sobre una instalación full o core. El principal benefio son las ventajas de licenciamiento, Hyper-V como rol en versión Datacenter licencia por socket todas las VMs que montes con los derechos de Windows Server incluidos. Y aunque una VM puede tener 64GB de memoria, el uso que haga de ellos dependerá del sistema operativo que corra en la VM.

En Windows Server 2008 R2 cada VM puede acceder hasta 4 procesadores virtuales, hasta 64 GB de memoria por VM y pueden estar activas por host hasta 384 máquinas virtuales. El Host, soporta 64 procesadores lógicos, 1 TB de memoria física y 512 VP por host. En CLuster CSV, 16 nodos y 1000 VM

En Windows Server 2012 cada VM puede acceder hasta 64 procesadores virtuales, hasta 1 TB de memoria por VM y pueden estar activas por host hasta 1024 máquinas virtuales. El Host, soporta 320 procesadores lógicos, 4 TB de memoria física y 2048 VP por host. En Cluster CSV, 64 nodos y 4000 VM

La reserva de memoria del host

El host y la partición padre requieren de memoria para funcionar y es muy importante asegurarnos que tienen la memoria que requieren. A parte de la propia memoria requerida por el sistema operativo de la partición padre, tenemos que tener en cuenta la memoria que consuma en pico de los agentes de antivirus, monitorización ó backup. Ya que menciono tema antivirus, asegúrate de añadir las excepciones necesarias para entornos de hyper-v y/o CSV. Hay que considerar como mejor solución que paginen las VM a que pagine el host, pese a que la paginación es un enemigo natural de la consolidación de VMs.

Ésta sería la fórmula a aplicar;

• Hyper-V requiere 300MB como hypervisor

• El sistema en la partición padre se llevará 512MB, (mejor 1024MB)

• Suma la memoria máxima de todos tus agentes instalados en el servidor, antivirus, monitorización, backup…

• Por cada VM suma 32 MB

• Por cada GB que tenga una VM por encima del primero suma otros 8MB

• Suma toda la memoria y será la cantidad a reservar para el host.

Con el resto de memoria que quede en el host será la memoria que podrás usar para las VMs, esto es así porque la memoria de las VM es de un tipo especial denominado “non-paged-pool memory” esto supone una garantía de rendimiento dado que nos garantiza que las VM siempre usaran RAM y no paginación en disco. El host puede paginar pero no por la RAM que usen las VMs.

La memoria de Paginación en las VMs

Partimos de la premisa que si un sistema operativo página es porque le falta memoria RAM y tendrá como resultado consumo en operaciones de entrada y salida (I/O) en disco Cuando virtualizamos muchas VMs en un mismo servidor y sistema de almacenamiento las I/O deben de ser de las cosas que más nos preocupen. Si una VM página en disco tendremos un impacto pequeño, pero si tenemos 1000 VDIs ó VMs y se ha dimensionado mal la memoria y un porcentaje grande de estas VMs página, el rendimiento general será bastante malo.

Un buen aliado puede ser la memoria dinámica pero no quita que tengamos cuidado a la hora de calcular la memoria real que necesitamos, si no calculamos bien puedes quedarte sin memoria y entonces veras cifras negativas de memoria disponible en las VMs y estarás sufriendo paginación. Para ello, monitoriza adecuadamente tus VM. Si el rendimiento de la paginación es crítico en tu entorno para una VM, puedes usar un VHDX fijo adicional para la paginación.

Los ficheros .bin

En cualquier momento puede ser necesario realizar operaciones que tienen repercusiones con respecto a la memoria de una VM, como por ejemplo pausar una VM o sacar una instantánea. Hyper-V es un sistema tremendamente protector que intenta a toda costa evitarte problemas especialmente los de estabilidad. Por esto Hyper-V reserva en el disco espacio para poder respaldar la memoria de la VM en disco y esto lo hace a través del fichero .BIN que en ocasiones ocupa tanto como la memoria asignada a la máquina virtual.

Entender la Memoria Dinámica

Cuando configuramos una máquina virtual hay dos formas de configurar su memoria, de forma estática o dinámica.

Configuración de memoria estática Cuando se configura una VM con memoria estática será necesario contar con toda esa memoria RAM libre en el host para poder arrancar la máquina virtual, si el host no tiene suficiente memoria RAM recibiremos un error que nos impedirá arrancar la VM en este host, pudiéndolo intentar en otro nodo del cluster si es que estamos en un cluster. De esta forma si configuramos todas las VM de un host con memoria estática la suma de la cantidad de memoria RAM de todas las VM más la memoria RAM no paginada usada por el HOST nunca podrá superar la RAM total del HOST.

Configuración de memoria dinámica

Normalmente los servidores o escritorios virtualizados no usan el 100% de la memoria asignada durante todo el tiempo, de hecho a ninguno nos gusta que ninguna de nuestras maquinas este al 90% de uso de memoria de forma constante. Hyper-V a través de la memoria dinámica nos permite aprovechar de forma inteligente la memoria no usada en las máquinas virtuales redistribuyendo esta memoria a las máquinas virtuales que la necesitan dentro del host.

Lo mejor de este sistema es que no afecta al rendimiento de forma perceptible, no entraña riesgos y no te requiere de ningún cambio de configuración en el sistema operativo de la VM para aprovechar todo su potencial. Podéis usar DM en servidores Windows Server 2008 R2 SP1 con Hyper-V o con la versión gratuita de Hyper-V; Hyper-V Server 2008 R2 SP1 y por supuesto en las versiones Windows 2012.

Las maquinas virtuales en las que activéis DM pueden ser Windows Server 2003, 2008, 2008 R2, 2012, 2012 R2, tanto en 32 como en 64-bit. Y en la parte cliente Windows 7 en versión Enterprise y Ultimate en 32 y 64-bit, Windows 8 y 8.1.

Cosas importantes sobre la DM Hyper-V nunca paginara para crear RAM de donde no hay por lo que nunca tendréis problemas de rendimiento.

Cuando configuramos una VM con memoria dinámica indicamos 3 parámetros iniciales:

La memoria de arranque será la cantidad de memoria que la VM reclamara al HOST para arrancar y una vez la VM arranque estará completamente bloqueada para su uso. Hay dos formas de tomar la decisión de cuanta memoria asignar como memoria de arranque:

1.- Usar la tabla de memoria mínima necesaria por sistema operativo de acuerdo a fabricante.

2.- Desde mi punto de vista es mejor tomar la decisión basándonos en los datos de la monitorización, si sabemos que un servidor emplea habitualmente 2 GB no tiene sentido configurarlo con una memoria mínima de 512 MB, será mejor configurar una memoria mínima cercana al uso real.

Creo que esto nos permite un mejor y más realista dimensionamiento de los sistemas a la vez que evita al host operaciones innecesarias.

El siguiente parámetro a configurar es la memoria máxima, si bien en algunos sitios se ha leído que lo mejor es configurar la memoria máxima al máximo permitido por Hyper-V (64GB) o bien al máximo permitido por el sistema operativo de la VM si es menos de 64GB, tenemos que configurar un valor que consideramos apropiado a la carga que existe dentro de la VM y al coste que queramos repercutir a ese servicio.

El siguiente parámetro es el buffer, podemos entender esta parámetro fácilmente viéndolo como el que especifica a Hyper-V que cantidad de memoria tiene que darle de una sola vez a la VM cada vez que es necesario. Si configuramos el buffer a un 10% y una VM que tiene ocupados 1GB requiere más RAM, Hyper-V tratara de darle 100MB si están disponibles bien como memoria libre en el host o bien como memoria que puede liberarse por falta de uso en otras VMs con DM.

Si ponemos el buffer a un valor muy bajo se le entregara memoria a la VM en bloques pequeños por lo que la VM no tendera a tener mucha memoria libre, sin embargo un buffer mayor dejara holgura en la VM lo que puede ser beneficioso para algunas cargas que usan caches en RAM. Hyper-V atiende una solicitud de memoria de forma activa e inmediata en cuanto una VM lo solicita.

¿Cómo añade y quita memoria Hyper-V?

Gracias los componentes de integración (IC) que sabéis que tenéis que instalar en todas las VM que ponéis en Hyper-V por eso cuando actualizáis vuestros Hyper-V 2012 a Hyper-V 2012 R2 tenéis que actualizar siempre los IC de todas las VM para que puedan usar DM y el resto de componentes de integración.

Dentro de los IC de la VM hay un elemento que se encarga de comunicar a Hyper-V la presión de memoria que hay dentro de la VM, a este componente le llamamos “Dynamic Memory VSC” donde VSC significa Virtual Service Consumer.

Hyper-V tiene otro componente análogo llamado “Dynamic Memory VSP” donde VSP significa Virtual Service Provider este componente se encarga de escuchar la información de los VSC sobre la presión de memoria dentro de las VMs.

Finalmente Hyper-V tiene otro componente denominado “Memory Balancer” este componente se encarga de seguir la presión de memoria de todas las VMs con la información que le pasa el VSC y si es necesario y se puede reclamar la memoria no usada y también asigna memoria a las maquinas que lo necesiten.

Al añadir memoria se usa una funcionalidad que aportan los IC para añadir memoria en caliente lo que dispara el sistema de Plug and play para detectar la nueva memoria dentro del sistema operativo de la VM. DM funciona en sistemas operativos que no soportan de serie la funcionalidad de añadir memoria en caliente, esto es gracias a los IC.

Quitar memoria es un poco más difícil de entender, principalmente porque DM en realidad si lo vemos desde el punto de vista del sistema operativo de la VM nunca quita la memoria aunque en realidad la memoria física ya no está disponible para la VM. La DM en Hyper-V a la hora de quitar memoria usa una técnica denominada “balloning” o balón de memoria.

Cuando Hyper-V decide quitarle memoria a una VM por que no la usa esta memoria libre se prepara dentro de la VM y entonces gracias a un driver introducido por los IC Hyper-V hincha el balón de memoria dentro de la VM usando memoria no paginada, este balón indica al sistema operativo que esa memoria está siendo usada por el driver de forma que el sistema operativo ya no la usa para nada mas e Hyper-V puede por detrás retirar esa memoria física y asignársela a otra VM. Si usáis la herramienta rammap de sysinternals veréis lo bien que se ve como el driver bloquea la memoria.

La reclamación de la memoria no se realiza inmediatamente en cuanto la VM no la necesita salvo que otras VMs estén reclamando esa memoria y no haya más memoria libre en el sistema. Con el fin de optimizar el proceso y evitar esperas, Hyper-V recolecta la memoria libre cada 5 minutos. Otro parámetro que se puede configurar es la prioridad o peso que tendrá esta VM respecto a otras a la hora de reclamar memoria.

Presión de memoria y banda de presión

Para entender cuando una VM pide memoria tenemos que entender el concepto de presión de memoria Expresamos la presión de memoria como un %, este porcentaje se calcula dividiendo el valor de “current commit charge” por el valor de la memoria física, el porcentaje restante hasta el total de la memoria RAM física que ve la VM es el valor que llamamos “free buffer”

Cuando la presión es superior al 100% la VM estará paginando mucho y el “free buffer” será negativo.

Hyper-V ve la presión de memoria de la VM dentro del contexto de lo que denominamos banda de presión, esta banda tiene unas marcas de agua que establecen la presión mínima y máxima dentro de la VM, los datos de presión mínima y máxima se establecen en base a la información histórica de presión de memoria dentro de la VM. Si la presión actual se mantiene entre el mínimo y el máximo la memoria ni se quitara ni pondrá. La memoria se quita cuando la presión de memoria está por debajo de la presión mínima y se pide memoria cuando se excede la presión máxima.

Para que la DM funcione adecuadamente es necesario que la máquina virtual tenga bien configurada la paginación, si el fichero de paginación no es suficientemente grande Hyper-V no podrá añadir más memoria a la VM. Un ejemplo: una VM tiene en este momento 2GB asignado, está usando 1950MB y un proceso pide 100MB, lo primero que es necesario es que el sistema operativo dentro de la VM le de esos 100MB y para eso tendrá que paginar los 50 que faltan, justo después Hyper-V detectará la condición y le añadirá memoria a la VM, pero si no hay espacio en el fichero de paginación no será posible todo esto.

Otra cosa a tener en cuenta es que el sistema operativo dentro de la VM si está configurado para establecer dinámicamente el tamaño del fichero de paginación lo hará en función de la cifra de RAM que configuramos como memoria de arranque, esto implica que si queremos que dentro de una VM se pueda ejecutar un volcado de memoria completo será necesario configurar el tamaño del fichero de paginación manualmente al tamaño máximo de memoria que pueda tener la VM.

Es frecuente preguntarnos si debemos usar o no la DM en nuestras VMs, la respuesta seria que si en la gran mayoría de los casos, solo evitaremos su uso en aquellas VMs que tengan cargas donde el fabricante explícitamente no soporte este tipo de tecnológicas o donde no tengan sentido por ser cargas como bases de datos que tienden a usar toda la RAM disponible como cache de datos.

Hay un último aspecto que comentar sobre la memoria dinámica y es que el fichero .BIN puede crecer al incrementarse la cantidad de memoria debido a una operación de adición de memoria. Si no hay espacio para que el .BIN crezca no se podrá añadir más memoria http://support.microsoft.com/kb/2504962

Monitorizar la memoria

Básicamente tenemos dos grupos de contadores, los contadores del balanceador de memoria que nos hablan de la memoria que el host tiene disponible y de las operaciones de añadir y quitar memoria y por otra parte los contadores relativos a cada VM que nos hablan de la memoria que se quita y se pone y de la presión de memoria que experimenta la VM.

Para terminar

Mientras que puede parecer que la memoria es un concepto muy sencillo, hay muchos detalles interesantes de entender para poder implementar si queremos exprimir hyper-v 2.0 y 3.0 en nuestros entornos.

El 18 de octubre de 2013, Microsoft libera junto con Windows 8.1, Windows 2012 R2, las novedades de Hyper-V 3.0, en la R2 de Windows 2012 prometen;

1.- Nueva Generación de Máquinas Virtuales: La arquitectura básica de la máquina virtual no ha cambiado en mucho tiempo. Los sistemas operativos fueron diseñados para operar en dispositivos físicos, por lo que las máquinas virtuales se encargan de emular el hardware. Hyper-V Server 2012 R2 admite el concepto de una nueva arquitectura basada en hardware moderno sin dispositivos emulados, todo virtual y sin dependencias.

2.- VM Direct Connect: Hasta ahora para poder conectarse a una máquina virtual era necesario tener una conexión de red activa, y la máquina virtual debía tener una dirección IP accesible por el sistema que intenta conectarse. Esta nueva característica permite una conexión de escritorio remoto directo a cualquier máquina virtual corriendo sobre lo que ahora se llama el VM Bus, lo que la hace independiente del adaptador de red.

3.- Replica extendida: Actualmente la réplica se limita a un único destino. En la R2 de 2012 es posible realizar una réplica en un servidor de réplicas, y este a su vez podrá ser emisor hacia otro servidor de réplicas.

4.- Frecuencia de las Réplicas: Hyper-V Server 2012 ya proporciona un intervalo de replicación fija de 5 minutos. Se han añadido dos nuevas opciones en la versión R2 de Hyper-V Server 2012, de replicación más frecuente (30 segundos) y no tan frecuentes (15 minutos).

5.- Live Migration más rápido: Dos nuevas opciones en 2012 R2 que ayudan a mejorar el rendimiento de las migraciones. El primero es la capacidad de habilitar la compresión en los datos para reducir el número total de bytes transmitidos, y la segunda opción se apoya en las ventajas que aporta SMB direct y las nuevas versiones de SMB.

6.- Exportación Online de VM: Permite clonar o exportar máquinas virtuales sin necesidad de detenerlas.

7.- Redimensionamiento Online de VHDX: Podemos expandir y reducir el tamaño de un disco duro con formato VHDX, sin necesidad de detener la máquina virtual a la que está asignado.

8.- Storage QoS: Incluye la posibilidad de limitar las máquinas virtuales para un determinado nivel de rendimiento de I/O, pudiendo limitar el número máximo de IOPS para una única máquina virtual.

9.- Memoria Dinámica VM Linux: Tiene la capacidad de ampliar de forma dinámica la cantidad de memoria disponible para una máquina virtual Linux en ejecución.

10.- Compatibilidad con Azure: En Windows Azure contaremos con la misma versión de hipervisor, lo que significa que nuestras máquinas virtuales serán totalmente compatibles con la Cloud Pública de Microsoft.

Más información;
http://technet.microsoft.com/en-us/library/dn282278.aspx

Con el fin de evitar los problemas conocidos durante las implementaciones de Hyper-V, os invito añadir en vuestras best practice, la aplicación de estos cambios imprescindibles en vuestros entornos de Hyper V, tanto para W2K8R2 como para W2K12;

Hyper-V: Update List for Windows Server 2012
http://social.technet.microsoft.com/wiki/contents/articles/15576.hyper-v-update-list-for-windows-server-2012.aspx

Hyper-V 2008 R2: Update List
http://social.technet.microsoft.com/wiki/contents/articles/1349.hyper-v-2008-r2-update-list.aspx

Cada cierto tiempo y solo en alguna ocasión, podemos encontrarnos con éste error (0x80070569) en dos escenarios distintos dentro de Hyper-V 2012;

1.- Al hacer Live Migration
2.- Al Crear una nueva máquina virtual

Error 0x80070569

En ambos casos, no se pudo iniciar el proceso de trabajo por falta de permisos y la operación de Live Migration o Nueva VM, falla con los siguientes mensajes;

Este problema se produce porque la identidad de la cuenta NT Virtual Machine\Virtual Machines, no tiene ó mejor dicho, ha perdido, el derecho de iniciar sesión como servicio en el host de Hyper-V.
El servicio de administración de máquinas virtuales (VMMS) sustituye a este permiso de usuario en cada actualización de la directiva de grupo para asegurarse de que está siempre presente. Sin embargo, la directiva de grupo de actualización no funciona correctamente en determinadas situaciones.

Actualmente Microsoft está investigando este problema para determinar cual es la causa del error y hasta entonces podemos usuar un fácil Workaround.

Opción 1

En primer lugar, podemos utilizar la salida del comando gpresult para identificar el objeto de directiva de grupo/s, que modifica la configuración de ACL

1.- Iniciamos sesión con un usuario con credenciales de admin. del dominio.
2.- Desde la consola de Directivas de Grupo buscamos la política que gestiona los derechos de usuario, editamos la política e incluimos NT Virtual Machine\Virtual Machines en las entradas para Iniciar sesión como servicio

3.- Cierre el editor de política e iniciar un gpupdate /force en el host de Hyper-V .  (Tendremos que esperar varios minutos para que la replicación de Active Directory que se produzca).

Opción 2

La más simple y por increíble que parezca funciona, sin necesidad de generar la GPO que se describe en la Opción 1, lanzamos desde el host de Hyper-V, el comando gpudate /force

ODX – Windows Offloaded Data Transfer

El gran salvador en la transferencia de datos, podríamos decir que es un concepto derivado de la API de VAAI de Vmware y que llega a Windows Server 2012 muy mejorado, su propósito es evitar que un intermediario, en este caso el servidor, haga funciones de buffering para los datos que se transfieren entre dos equipos externos.  Si configuramos bien ODX, conseguiremos aligerar mucho el movimiento de datos y aliviar la carga en los equipos tanto si hablamos de servidores físicos como virtuales.

ALOJAMIENTO ORIGEN -> SERVIDOR -> ALOJAMIENTO DESTINO

La implementación de ODX permite que el servidor en lugar de intermediar en el flujo de datos y tener que manejar un buffer de información sólo actúa para facilitar «las coordenadas de origen y destino» pero el flujo de datos real se realiza entre las dos fuentes implicadas siempre que soporten esta tecnología.

Para usar ODX, el entorno tanto de almacenamiento como de software deben cumplir una serie de requisitos de hardware y software, el siguiente enlace es bastante didáctico; http://technet.microsoft.com/es-es/library/jj200627.aspx

Centrémonos en el software, que es más nuestro, sistema operativo, W2K12 y W8, ojo con los antivirus y si además somos fanáticos de la seguridad, incompatible con el cifrado en unidades BitLocker y si además has querido probar el nuevo sistema de archivos resistente a errores ReFS, olvídate y de FAT mejor ni hablamos, por que no se admiten ninguno de los dos, tendrem0s que formatear a 64KB en NTFS, lo mejor para alojar máquinas virtuales con extensión vhd ó vhdx para hyper-v en W2K12.

Hyper-V en Windows Server 2012 trae una nueva funcionalidad denominada SHARED NOTHING LIVE MIGRATION, esto significa que las máquinas físicas no deben compartir nada más que una conexión de red en donde las máquinas virtuales a migrar, se mueven en vivo de un chasis a otro con todo con las aplicaciones y sesiones que están ejecutando al momento de la migración.

Antes de Windows Server 2012 para hacer una migración de VMs entre chasis se necesitaba tener un almacenamiento compartido entre los varios servidores físicos, ahora sólo se necesita tener una red entre las «n» máquinas físicas con Windows Server 2012 y las VMs se migran en vivo -por la red- al almacenamiento local, del volumen local 1 al volumen local 2. Importante tener en la cabina el firmware para ODX.

Si además nuestro almacenamiento cuenta con TRIM, que es la manera en que la cabina libera el espacio (en la cabina) cuando borras ficheros en el filesystem tendremos una solución global para la transferencia de datos.

Es decir, borras ficheros, y el OS le informa amablemente a la cabina, que ese espacio lo puede liberar (en la cabina) y seguir jugando cómodamente al thin provisioning reasignando el espacio disponible (en la cabina) de un volumen a otro de los que presenta por arriba a los diferentes hosts que consumen volúmenes de ella.

Se me ocurre advertir, que el proceso de borrado se puede quedar a medias. Para paliar el problema tenemos dos opciones, deshabilitar el TRIM en el OS, con lo que el proceso descrito arriba no se llevaría a cabo y nuestro flamante Windows 2012 se comportaría como un Windows Server anterior. El comando desde un Power Shell es:

fsutil behavior set disabledeletenotify 1 

Pero mejor que deshabilitar TRIM y ODX, en mi post anterior, Roll-up de Hyper-V sobre W2K12 explico los varios fix ó parches relacionados con todo esto del TRIM el ODX, los backups y los CSVs.

Fundamentalmente se consigue que Windows dialogue con la cabina para que la carga que debería hacer en front-end se encargue de hacerla automáticamente la cabina en back-end y así evitar el round-trip time de negociación entre Windows y la cabina.  De esta manera los puertos de front-end quedan libres para el resto de servidores lo que permite mantener buenos tiempos de respuesta siempre que los niveles de utilización de caché estén a niveles normales.

Slide útil de ODX en almacenamiento 3PAR de HP;