Que tiene de nuevo Hyper-V en Windows Server 2012 R2?

Bueno, despues de haber visto videos y presentaciones del TechEd del pasado mes en Madrid, os dejo estos links sobre “Qué tiene de nuevo Hyper-V (What’s New in…), Failover Cluster y Powershell 4.0.

Os dejo este video de Channel9 y la  PPT de rigor.

Espero que os gusten.

Saludos robeznos.

Afinar la configuración de nuestro Cluster Hyper-V Windows 2012. Preferred Owners o Nodos preferidos a traves de Powershell.

Como continuación al Post del viernes pasado (este), sobre la afinación en la configuración de nuestro Cluster Hyper-V Windows 2012, dejamos pendiente la configuración a través de Powershell.

Allá vamos. Lo dividiremos en varias partes, debido a su amplitud,, Preferred Owners, Proceso de Failover, Mejoras en el Orden de arranque de las VM y Reglas de Afinidad y Antiafinidad.

.

PREFERRED OWNERS

Partimos desde el punto de que ya tenemos instalado nuestro Cluster de Windows Server 2012 con el Rol de Hyper-V, por lo tanto, al instalar la RSAT, nos cargaría el módulo de PowerShell para FailoverCluster:

HVCluster000011.- Ordenamos los elementos del Cluster.-

Get-ClusterGroup

2.- Ordenamos los elementos del Cluster dependiendo del propietario.-

Get-ClusterGroup | Get-ClusterOwnerNode

TunningHyper-V000100005

Donde vemos los Host preferidos para las VMA y VMB, así como los recursos del Cluster Group y Available Storage .

3.- Asignamos un propietario preferido, el Host A, a una VM por ejemplo a la VMA:

Get-ClusterGroup VMA | Set-ClusterOwnerNode HOST_A

y comprobamos que el recuros VMA tiene su Owner en el Host A:

TunningHyper-V000100006

Si queremos volver a quitar los Preferred Owners de la máquina virtual VMA, sin ningún problema:

Get-ClusterGroup VMA | Set-ClusterOwnerNode “”

 

Bibliografia

Altaro.

Hyper-V Performance – Parte IV – Red.

Me quedé sin espacio en la base de datos de mi WordPress en Azure, así que continuamos en “MasRobeznoQueNunca” hasta que solucione este pequeño problema.

Hoy continuamos con la monitorización de la red.

Después de haber visto la monitorización mas complicada como es la de Almacenamiento o la de memoria, la monitorización de rede la vamos a basar en dos simples contadores, uno para la tarjeta del host y otro para la tarjeta de las Máquinas Virtuales (VM):

a) Tarjeta de red del Host.- El siguiente contador indica el total de Bytes por segundo tanto de tráfico de entrada como de salida en una tarjeta de red física (NIC).

Network InterfaceBytes Total/Sec

Con la siguiente horquilla de valores recomendados:

0001

No tenemos que olvidar detalles tan importantes como la velocidad de nuestra tarjeta de red, como por ejemplo:

  • NIC de 10 GB puede enviar cerca de 1250 millones de bytes/sec
  • NIC de 1 GB puede enviar cerca de 125 millones de bytes/sec
  • NIC de 100 MB puede enviar cerca de 12,5 millones de bytes/sec

y la velocidad de los Switches o Routers a los que está conectado, ya que aunque tengamos la posibilidad de configurar las tarjetas de red a 10 GB si los Switches son de 1GB ……

.

b) Tarjeta de red de la VM.- En el caso de que queramos estudiar el tráfico de las tarjetas de red virtuales (vNIC), utilizaremos el siguiente contador que representa el número total de byts que atraviesan dicho adaptador virtual.

Hyper-V Virtual Network AdapterBytes Total/Sec

Utilizaremos la misma horquilla descrita en el punto anterior.

Buena semana a todos.

Afinar la configuración de nuestro Cluster Hyper-V Windows 2012. Proceso de Failover.

Hoy vamos a configurar dos puntos relacionadas con el proceso de Failover de Máquinas Virtuales (VMs).

 

Partimos desde una infraestructura de un Cluster de Windows Server 2012 con el Rol de Hyper-V de dos nodos, Nodo A y Nodo C. Que contienen dos VMs, VMA y VMB:

TunningHyper-V000100001.

 TunningHyper-V000100004

Preferred Owners.- Imaginaos que de entre todos los Hosts Hyper-V incluidos en el cluster podemos seleccionar nodos como favoritos para la ubicación de una VM, o sea, que podemos priorizar la ubicación de nuestras VMs dependiendo del Host que queremos que sea propietario:

Puede darse la situación que nos interese que una VM solo pueda estar en el nodo A y B y  no en el C, por que este último nodo tiene menos recursos, etc., En nuestro caso tenemos solo dos Hosts, así que lo normal sería configurar ambos como preferidos. Incluso, entre los nodos preferidos, podemos crear un orden, basta con ordenarlos utilizando los botones de Up & Down.

.

TunningHyper-V000100002b

Configuración del proceso de “Failover”.- Podemos especificar el número de veces que el servicio de Cluster intentará reiniciar o realizará un proceso de Failover de las VM, en nuestro caso, en un periodo de tiempo determinado. Configuraremos:

.

  • Máximo número de fallo en un periodo de tiempo.
  • Periodo de tiempo en horas.

 

También configuraremos la marcha a tras del proceso de Failover, conocido como Failback, con las siguientes opciones:

 

  • Denegar el proceso de vuelta a tras.
  • Permitir el proceso de Failback.-
    • Inmediatamente
    • En un periodo de tiempo determinado que elegiremos.

 

Mejorar el criterio de arranque de las VMs en caso de Failover.-

TunningHyper-V000100002

En este último punto vamos a configurar la prioridad que vamos a darle a cada VM en el caso de un proceso de Failover.

 

Como podemos ver tenemos cuatro opciones de ponderación:

 

  • Alta,
  • Media,
  • Baja
  • No auto inicio.

 

Poco puedo aportar sobre cada una de las opciones, bastantes claras.

 

Esto mismo se puede configurar desde las opciones de cada VM, exactamente en “Cambiar la prioridad del arranque”, con las mismas opciones:

TunningHyper-V000100003

Recordar que todos estos puntos se pueden configurar a través de Powershell y también podemos crear reglas de Afinidad y reglas de Anti-Afinidad para las VMs, pero eso lo vemos la semana que viene en otro Post.

Buen fin de semana a todos.

Afinar la configuración de nuestro Cluster Hyper-V Windows 2012. Introduccion.

Llegados a este punto, despues de ver en Post anteriores la instalación y la configuración de una manera sencilla de nuestro Cluster de Windows Server 2012 con el rol de Hyper-V, vamos a proceder a afinar o mejorar, utilizando el término ingles, Tunnear, nuestro cluster.

Estos son los puntos que inicialmente vamos a tratar:

  • Proceso de Failover.-
    • Preferred Owners.
    • Proceso de Failover.-
    • Priorización de VMs en caso de “failover”.
  • Opciones de movilidad.-
    • Quick Migration.-
    • Live Migration.-
    • Storage Migration.-
    • Hyper-V Replica.-
  • Mejoras al modelo de Quorum.-
    • Node vote Weight.- Control sobre qué nodos votan y cuales no votan. Optimo para configuraciones Multisite.
    • Dynamic Quorum.- Permite al propio Cluster administrar el Quorum.

Nos vemos.

 

Hyper-V Performance – Parte III – Almacenamiento.

 

Continuamos con esta serie de Post sobre como medir el rendimiento de nuestros Hyper-V, despues de la CPU y la memoria RAM, hoy nos toca el almacenamiento.

 

El almacenamiento suele ser uno de los puntos donde se originan mas cuellos de botella en nuestra infraestructura. Detectar dichos problemas suele ser uno de los dolores de cabeza mas frecuentes del informático. En Hyper-v no va a dejar de ocurrir lo mismo. Lo vamos a dividir en tres partes:

 

a) Logical Disk.- Tenemos estos tres contadores de rendimiento recomendados de Disco lógico, como podreis intuir se trata de monitorizar si tenemos latencia en lectura, escritura y en transferencia por segundo, en valores medios:

\LogicalDisk\Avg Disk sec/Read0001

\LogicalDisk\Avg Disk sec/Write

\LogicalDisk(*)\Disk Transfers/sec (IOPS desde el punto de vista de Windows).

Utilizaremos el siguiente baremo recomendado por Microsoft para saber si nuestros discos están en estado saludable o tenemos latencia:

 

b) Physical Disk.- Tenemos los mismos contadores de rendimiento recomendados que en punto de Disco lógico, lectura, escritura y transferencia por segundo en valores medios. Además utilizaremos la misma horquilla para saber si tenemos latencia o no.

 

\Physical Disk\Avg Disk sec/Read

\Physical Disk\Avg Disk sec/Write

 \LogicalDisk(*)\Disk Transfers/sec

 

En el caso que estemos utilizando Cluster Shared Volumes (CSV) conectados como discos Passthrough, tendremos que monitorizarlos no solo para saber si tenemos latencia, también para ver el grado de fragmentación de dicho disco.

 

\Physical Disk(*)\Disk Transfers/sec (* CSV monitoring)

 

También tendremos que tener especial cuidado si hemos montado nuestra infraestructura de virtualización aprovechando las bondades de Server Message Block (SMB), ya en versión 3, con los siguientes contadores:

 

\SMB Clients Share\Avg Disk sec/Read

\SMB Clients Share\Avg Disk sec/Write

 

Es dificil poner un baremo en estos contadores ya que siempre dependerá de la infraestructura de red que tengamos.

 

c) Hyper-V Storage.- Estos contadores representan el número total de bytes que han sido leidos o escritos por segundo en el dispositivo virtual. Es complicado poner un baremo ya que en todo momento depende del tipo de almacenamiento físico que estemos utilizando:

 

\Hyper-V Virtual Storage Device\Read bytes/Sec

\Hyper-V Virtual Storage Device\Write bytes/Sec

 

Cada fichero VHD o VHDX tendrá su propia instancia de contador de rendimiento y lo utilizaremos para determinar qué disco tiene mas o menos utilización (IOPS).

Como podreis comprobar hay innumerables post en blogs sobre el rendimiento y el almacenamiento, hay mucha información, en general, sobre el rendimiento. Os enumero unos poquitos:

Hyper-V Performance – Parte II – Consumo de Memoria.

Continuo con esta serie de Post sobre como medir el rendimiento de nuestros Hyper-V, despues de la CPU hoy llega la memoria RAM.

 

Obviamente lo dividimos en la parte del Host de virtualización, ya sea Windows Server 2012 con el rol de Hyper-V o sea Hyper-V server 2012, y la parte de las máquinas virtuales (VMs).

 

Host.- Los principales contadores para monizar la memoria del Host son los siguientes:

 

  • \Memory\Available MBytes.- Microsoft nos recomienda monitorizar la memoria disponible de cada Host de virtualización a través de esta orquilla de valores:

0001

  • \Memory\Pages /Sec.- Con este contador monitorizaremos las páginas que se están leyendo o escribiendo en disco por segundo, para tratar de detectar errores de paginación, o sea, que tengamos un caso que el sistema operativo no dispone de mas memoria disponible y está utilizando el disco duro para volcar el resto de  memoria que necesita, con su correspondiente impacto negativo en el rendimiento.   Microsoft nos recomienda esta orquilla de valores a la hora de medir este contador:

0002

Como ejemplo, un alto número de paginas por segundo unido a una baja memoria disponible nos está indicando una falta de memoria en el servidor, obviamente.

 

Recordamos los principios básicos de la relación existente entre la memoria y la paginación a disco “a mas memoria RAM asignada a un equipo menos paginará en disco“, sin olvidarnos de que “no siempre disponemos de toda la memoria RAM que queremos y/o necesitamos”.

 

Virtual Machines.- En este caso se nos presentan dos opciones de configuración en la gestión de la memoria:

 

  • Sin memoria Dinámica configurada.- Al no tener configurada esta característica, utilizaríamos los mismos contadores que para un Host de virtualización. Volvemos al punto anterior.

 

 

  • Con memoria Dinámica configurada.- Tenemos los siguientes contadores de rendmiento:
  • \Hyper-V Dinamic Memory Balancer\Available Memory.- Este contador representa la cantidad de memoria que queda disponible en el “nodo balancer” (gestor del balanceo de memoria entre las VM cuando están configuradas con memoria dinámica), y que puede ser asignada a las VMs.

Aqui prestaremos atención a que el valor de dicho contador no esté próximo a 0, que nos indicará que el sistema está cerca del consumo del 100% de la memoria, con los consiguientes problemas de rendimiento en las mismas.

  • \Hyper-V Dinamic Memory Balancer\Physical Memory.- Este contador representa la cantidad de memoria en la VM. Es muy util para entender el consumo histórico de una VM.

Tendremos que tener cuidado de que el valor que nos da este contador no esté cerca de la memoria máxima asignada, ya que nos indicaría que este servidor está consumiendo toda su memoria RAM y, probablemente, esté paginando a disco y necesite mas.

  • \Hyper-V Dinamic Memory Balancer\Average.- Este último contador representa la presión media sobre el “nodo balancer”. Esta es la orquilla de valores recomendados:

0003

 

Por defecto en Windows Server 2012 con el rol de Hyper-V, automáticamente se fija una memoria para el Host. Para sistemas operativos anteriores, como Windows Server 2008 R2, necesitamos habilitar y configurar una entrada en el registro:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization

  • Nombre:MemoryReserve
  • Tipo: DWORD
  • Valor: Memoria a reservar en MB.

 

Dos cosas para terminar. Recordar que estos datos no son extrapolables al 100% a todos y cada uno de nuestros entornos, como ya dije en el Post anterior, son recomendaciones. Y, segundo, recordar, también, en el caso de configurar memoria dinámica a las VMs, qué parámetros tenemos que tener en cuenta:

 

Buena semana a todos,

Actualizar la licencia de Windows Server.

La pasada semana Samuel Lopez Trenado en su Blog “El Baul del ITPRO” comentaba el procedimiento de actualizar la edición de Windows Server.

Hace poco he instalado un Cluster de Windows Server 2012 con el rol de Hyper-v y debido a una serie de malas gestiones con las licencias, compra de licencias OEM en un idioma distinto al que luego se instala, los tenía con la licencia de evaluación a la espera de su caducidad:

VersionDISM0001b

Gracias a su artículo he podido incluir la licencia a ambos nodos del Cluster y ….. ya los tengo activados:

VersionDISM0002

Y este es el resultado final:

kkkkk

Para empezar fuerte la semana.

 

Hyper-V Performance – Parte I – Consumo de CPU.

Aprovechando que hace poco estube en un Workshop en Microsoft sobre el rendimiento de nuestros servidores con el rol de Hyper-V, adelanto esta serie de Posts sobre “cómo medir dicho rendimiento así cómo detectar posibles cuellos de botella en nuestro entorno de virtualización”.

Para empezar, me gustaría recordar este Post sobre “10 errores típicos en una revisión de salud de un entorno de Virtualización“, que considero indispensable releer cada vez que me meto en un proyecto de virtualización, independientemente del tipo de Hypervisor que se vaya a utilizar.

 

0001

i) Host Processor.- Normalmente en cualquier servidor, si queremos verificar el consumo de nuestro procesador lo que haremos será cargar los siguientes contadores de rendimiento:

 

  • \Processor(*)\% Processor Time
  • Task Manager (ver imagen =>)
  • \System\Processor Queue Lenght

 

Pues en nuestro caso, para saber qué consumo tiene la partición padre, que no hay que olvidar que es una máquina virtual (VM) en si misma, ya sea Hyper-V Server 2012 o Windows Server 2012 con el rol de Hyper-V, serán los mismos.

 

Veamos en que rangos de consumo de tiempo de procesador nos movemos:

0003

En el caso de que hayamos visto o intuyamos que pueda haber un problema de rendimiento en la CPU, o sea, nos hayemos en la zona de Caution o Critical, utilizaremos el contador de la Longitud de la cola del procesador, como referente inicial disponemos de la siguiente horquilla de valores que nos puede ayudar:

0002

Siempre hay que tener en cuenta que si ocurre en un momento puntual, no pasa nada. Otra cosa es que estos valores se alcancen durante un tiempo continuado. En cuanto a la horquilla de valores, éstos son orientativos, hay que saber extrapolarlos a las situaciones reales, a la carga del servidor, a los roles que tengamos instalados en el mismo, etc., no cogerlos como una regla de tres o lo que dice el KB de Microsoft va a Misa.

 

ii) Logical processor.- Para medir el total del consumo de procesador por parte del Host y todas las VM, utilizaremos los siguientes contadores de rendimiento:

  • \Hyper-v Hypervisor Logical Processor(*)\% Total Runtime
  • \Hyper-v Hypervisor Logical Processor(*)\Context Switches /Sec

% Total Runtime, con su consiguiente horquilla de valores indicativos (si os fijais son los mismos que en el punto anterior):

0003

Para el caso de los Content Switches, ocurren cuando el kernel cambia el procesador asignado de un subproceso a otro, verificaremos cuántos se producen por procesador y por segundo, con la consiguiente horquilla de valores indicativos:

0004

Cuando detectamos que estamos en zona Critical, suele venir motivado por:

  • Adaptadores del tipo Legacy Network.
  • Mal diseño de aplicaciones.
  • Drivers mal instalados.

 

ii)  Virtual processor.- Determinar el consumo de procesador de cada VM:

  • \Hyper-v Hypervisor Virtual Processor(*)\% Guest Runtime

Con la misma o muy parecida horquilla de valores indicativos que en el punto anterior:

0005

Como consejo final, si detectamos que \Hyper-V Hypervisor Virtual Processor (_Total)\% Total Run Time (Virtual Procesor Total Run Time – VPTR) está muy alto y \Hyper-V Hypervisor Logical Processor (_Total)\% Total Run Time (Logical Procesor Total Run Time – LPTR) es bajo, consideremos en asignar procesadores adicionales a esa VM.

El próximo día la memoria RAM.

Cluster Hyper-V – Configuración del tipo de Quorum.

Ya estamos terminando de configurar nuestro Failover Cluster para Hyper-V. Hoy nos toca la configuración del tipo de Quorum. Este punto sería uno de los primeros a tratar pero por diversos motivos, hoy es un buen dia para hablar de él.

Al generar el Failover cluster nodo a nodo, inicialmente se genera una configuración de disco Quorum: Node Majority o mayoría de nodos, automáticamente, ya que sólo tenemos un único nodo. Una vez añadimos un segundo nodo a nuestro Cluster, nos surge el dilema de dónde poner un tercer nodo o, mejor dicho, dónde poner un tercer voto a nuestro Cluster, ¿en una carpeta compartida?, ¿en un disco?

Accedemos a la configuración del cluster Quorum desde la consola:

Quorum00001

Nos lanza un asistente de configuración que nos da tres distintas posiblidades iniciales:

Quorum00003opcion1

  1. Típica (recomendada).
  2. Agregar o cambiar el testigo del quorum
  3. Configuración Avanzada.

Si seleccionamos la opción 1, nos hace la siguiente recomendación:

Quorum00004opcion1

Pero hoy tenemos un mal dia y no hacemos caso a nadie, así que probamos con la última opción, la 3, Configuración Avanzada, y continuamos con el asistente, nos pide qué nodos vamos a asignar y cuales no, si es que hay alguno:

Quorum00006opcion3_2_bis

Llegamos al seiguiente paso, donde vamos a configurar el tipo de testigo, apareciendo,  nuevamente,  tres opciones:

  1. Configuración de un disco como testigo (recomendada).
  2. Configuración de un directorio compartido como testigo.
  3. No configurar un testigo.

Quorum00008opcion3

En nuestro caso, añadiremos un disco FC de Quorum de 512 MB formateado en NTFS o ReFS al Cluster para que haga de testigo. No hace falta asignarle una unidad de red:

Quorum00009opcion3opcion3

Nos informan de la configuración seleccionada:

Quorum00010opcion3opcion3

Y nos muestra una ventana final del tipo sumario, con nuestro consiguiente reporte en formato html:

Quorum00011opcion3

Y final. Desde la consola de nuestro Failover Cluster queda de la siguiente manera:

Quorum00012opcion3

La situación final de nuestros discos será la siguiente:

Quorum00013

Nos vemos.