Generar el fichero cluster.log en Windows Server 2012.

El habilitar el fichero cluster.log en nuestros servicios de cluster nos proporciona un registro detallado de su actividad permitiéndonos utilizarlo en la resolución de problemas, principalmente.

Este registro puede ser generado incluso cuando la creación de nuestro Cluster falla.

¿Como creamos este registro? mediante un cmdlet de Powershell: Get-ClusterLog

Notas a tener en cuenta:

El nivel de detalle predeterminado para nuestro registro del cluster.log es 3.  Este nivel tiene que ser suficiente para la mayoría de los niveles de depuración, pero, en caso contrario, podemos elevarlo.

(Get-Cluster).clusterLogLevel=5

Este nivel de detalle produce un considerable aumento de la información a depurar y, sobre todo, del tamaño del fichero, por lo que conviene, una vez encontrado y solucionado el problema, devolverlo al nivel por defecto.

Para terminar, los logs pueden ser registrados en la hora local, usariamos el siguiente cmdlet:

Get-ClusterLog -UseLocalTime

Se me olvidaba comentar la ruta por defecto donde se genera el fichero cluster.log:

ClusterLog00002

Buen fin de semana a todos.

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.

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.

 

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.

Cluster Hyper-V – Configuración del Almacenamiento.

Continuamos con la configuración de nuestro Failover Cluster para Hyper-V. Hoy configuración del Almacenamiento.

Una vez asignados los discos por parte del grupo que gestiona el almacenamiento, que en pequeñas empresas seremos nosotros mismos y en empresas grandes existirá un departamento solo para las cabinas de discos, lo visualizaremos la consola de gestión de discos de cualquiera de los nodos del Cluster.

Como podemos ver, son dos discos de 500 Gb de una cabina HITACHI, y se ven perfectamente en el gestor de discos del Server Manager de cada uno de los dos nodos del Failover Cluster, asi que los añadimos al Cluster:

FailOverCluster000006

Los ponemos On line y los formateamos convenientemente:

FailOverCluster000007

Posteriormente, desde la consola de Failover Cluster procederemos a añadirlos a nuestro Failover Cluster:

FailOverCluster000007b

El siguiente paso será añadir dichos discos en formato Cluster Shared Volumes (CSV), formato especial de disco de Microsoft para Hyper-V exclusivamente:

FailOverCluster000009

Apareciéndonos el cambio de asignación de discos:

FailOverCluster000008

Asimismo, podemos apreciar la creación de este tipo de discos CSV en nuestra unidad C:

FailOverCluster000010

Pues ya tenemos nuestro almacenamiento compartido en formato CSV. Ya nos queda muy poquito.

Cluster Hyper-V – Configuración proceso Live Migration.

En este caso, la configuración es muy sencilla. Sólo tenemos que configurar qué redes van a ser utilizadas para la migración de Máquinas Virtuales (VM) entre los diferentes nodos del Cluster. Posteriormente si tendremos que configurar qué VM podrán realizarlo pero hoy toca solo configuración del Cluster Failover.

Vamos pues a configurarlo. Desde nuestra consola, dentro de las redes definidas en el post anterior (ver aqui):

FailOverCluster000003

Seleccionaremos configurar “Live Migration” y definiremos las redes que este proceso va a utilizar:

FailOverCluster000004

En nuestro caso tenemos tres redes. Utilizaremos como red primaria la definida para el HeartBeat y el proceso de Live Migration, y como red secundaria la propia red de producción y acceso a las VM (esto es menos recomendable y no entraría en unas Buenas Prácticas).

Hasta el próximo Post.

Cluster Hyper-V – Configuración de redes.

Seguimos con la configuración de nuestro Failover Cluster de Hyper-V. Hoy la configuración de nuestras redes.

 

Tenemos que definir las siguientes redes virtuales entre todas las redes físicas que tengamos en nuestro Failover Cluster:

  • Red de acceso de los Clientes a las Máquinas Virtuales (VM) del Failover Cluster.
  • Red para Live Migratión o migración de VM en vivo.
  • Red para el Heartbeat del Failover Cluster.
  • Red para el Almacenamiento.- En el caso de utilizar iSCSI.

 

En nuestro caso, el resultado final es el siguiente:

  • Red de acceso de los Clientes a las Máquinas Virtuales (VM) del Failover Cluster. Esta red la hemos denominado VM:

FailOverCluster000001

  • Red para Live Migratión o migración de VM en vivo y Red para el Heartbeat del Failover Cluster.- Por falta de medios y, sobre todo, de tarjetas de red las hemos unificado.

FailOverCluster000002

Este dibujo cambiará cuando tengamos mas tarjetas de red disponibles.

FailOverCluster000003

Hasta la próxima.