Es bien sabido que una tarea crucial de cualquier IT Manager es reducir al máximo el riesgo de sufrir caídas inesperadas de los sistemas de información imputables a factores que van desde errores humanos hasta aquellos inherentes a la tecnología. De éste último, podemos remarcar que Windows Server 2012 ha sido diseñado para proveer alta disponibilidad en cada capa: “Storage”, Server and File/Block Access”, “Network” and “Virtualization”.

Es materia de este artículo –en su primera parte- hablar de lo motivos por lo cual usted debería ya considerar migrar sus “clusters” a Windows Server 2012 y sacar provecho de las nuevas bondades que vienen ya incluidas en ésta nueva versión. Cabe mencionar que de lo que a continuación se lista y menciona brevemente, estaremos hablando con mucho más detalle en posteriores artículos como parte de una serie que tiene como fin darle a conocer lo nuevo en “Windows Server 2012 Failover Clustering”.

Escalabilidad. Windows Server 2008 R1 SP1 soporta 16 nodos en un cluster, 1000 VMs por cluster y 384 máquinas virtuales por nodo. En Windows Server 2012, el escalamiento vertical y horizontal prácticamente se cuadriplica a 64 nodos, 8,000 VMs por cluster y 1,024 máquinas virtuales por nodo.

Integración más estrecha con Hyper-V. Es tal la integración de Windows Server 2012 con Hyper-V que ahora Failover Clustering se considera como la pieza “Infrastructure as a Service (IaaS)” para la nube (pública y privada). Algunas funcionalidades de integración de listan a continuación:

  • Priorización de VMs en caso de “failover”. Las VMs pueden ser configuradas con cierta prioridad para controlar el orden en el que éstas hacen “failover” o inician.
  • Mejora en el criterio de colocación de VMs en caso de “failover”. Mover un número importante de cargas (VMs) de uno o más nodos en un cluster a otros nodos no es algo considerado simple. Estos movimientos pueden ser completamente intencionales o no intencionales debido a la falla de algún tipo en uno o más nodos. En Windows Server 2012, el criterio de dónde mover una VM depende de la disponibilidad de los recursos (memoria física + otras cargas) en cada nodo candidato antes de tomar la decisión final. Esto en combinación con la priorización de VMs hace que la transición de VMs entre nodos sea de la forma más óptima.
  • Movilidad de las VMs. Failover Cluster participa en varios escenarios de movilidad de VMs incluyendo Live Migration, Quick Migration, Storage Migration y Hyper-V Replica. Las dos primeras ya estaban presentes en Windows Server 2008 R2 con la mejora de que en Windows Server 2012 Live Migration ha sido modificada para permitir más de una operación simultanea entre dos nodos en el cluster. Windows Server 2012 introduce dos nuevas funcionalidades para escenarios de migración: Storage Migration y Hyper-V Replica. Storage Migration permite mover solo el storage de la VM a otra ubicación, lo cual puede ser hecho mientras la máquina virtual está activa representando esto cero “downtime”. Hyper-V Replica es una solución para Disaster Recovery, la cual permite la replicación de VMs de un sitio primario a otro secundario.
  • Monitoreo a nivel aplicación. Hyper-V y Failover Clustering proveen en conjunto una solución  para monitorear aplicaciones corriendo dentro de la VM, detectando así fallas en los servicios clave y llevando a cabo acciones correctivas tales como reiniciar la VM o reiniciando el servicio dentro de la máquina virtual.
  • Mejoras para “Guest Clustering”. Definamos a un Guest Cluster como aquel que reside dentro de las VMs. En ésta configuración tenemos a múltiples máquinas virtuales corriendo el servicio de cluster que en combinación crean un “Virtualized Failover Cluster”. En el pasado, los requerimientos de almacenamiento eran reunidos solo a través de iSCSI. En Windows Server 2012, éste requerimiento puede ser ahora también cubierto usando “Virtual Fibre Channel adapters” (hasta 4 por VM). Ésta funcionalidad es solamente soportada sobre HBAs especializadas que usan NPIV (“N_Port ID Virtualization”).

“Cluster-Aware Updating”. En el pasado, parchar clusters ha representado una tarea manual y compleja que por su naturaleza nos puede llevar a cometer errores no intencionados. Ahora, con Windows Server 2012, una nueva funcionalidad llamada “Cluster-Aware Updating (CAU)” fue agregada para ayudarnos en la automatización de éste proceso. El proceso CAU puede igual ser invocado de forma manual mediante el uso de una interfaz gráfica o a través de PowerShell. La segundo opción es hacer este rol altamente disponible de tal forma que se ejecute en base a un calendario. En posteriores “posts” estaremos hablando más en detalle de esta nueva funcionalidad.

Mejor interoperabilidad con AD. Las siguientes mejoras han sido incorporadas a la forma en la que los clusters coexisten con AD:

  • Por default la CNO es configurada para prevenir su borrado accidental
  • Recuperación en caso de borrado accidental de las VCOs. Una opción de “repair” puede ser usado para recrear los “computer objects” en AD.
  • Criterio más inteligente en la ubicación de “computer objects”. Es simple, el “Cluster Name Object” (CNO) es creado en la misma OU dónde se encuentran los nodos del cluster, y las “Virtual Computer Objects” (VCO) son creadas dónde la CNO está ubicada.
  • En Windows Server 2012, los nodos del cluster no son requeridos para comunicarse con controladores de dominio antes de que el servicio (clussvc) sea iniciado. Esto es principalmente importante cuando se tiene DCs virtualizados en los clusters que necesitaban comunicarse con ellos.
  • Refrescamiento del atributo lastLogonTimeStamp para las cuentas de computadora. El servicio de cluster ahora actualizará éste atributo de tal forma que las cuentas computadora relacionadas a los clusters no sean marcadas como “stale” por los administradores.
  • Soporte para Read-Only DCs (RODC). En Windows Server 2012, los clusters pueden ahora hacer uso de RODCs, permitiendo así poder implementar clusters de este tipo en una DMZ, por ejemplo.

Mejoras al “Cluster Validation Process”. En Windows Server 2012, el “cluster validation process” le han sido agregadas las siguientes capacidades:

  • La validación de storage es ahora más rápida, además de que es más granular de tal forma que las LUNs pueden ser probadas de forma individual.
  • Ahora las pruebas de “storage” aplican también para soluciones multisitio y excluyen LUNs para replica.
  • Pruebas específicas para Hyper-V han sido incluidas cuando los nodos tienen el rol instalado.
  • Verificación binaria de hotfixes a través de todos los nodos en caso de que existan discrepancias con respecto a los hotfixes instalados.
  • Pruebas orientadas a verificar los requerimientos para el soporte de Cluster Shared Volumes (CSV).

Mejoras al modelo de Quorum. El concepto de Quorum es fundamental en un cluster, tanto así que si en el cluster no existe consenso (mayoría de votos), entonces las aplicaciones altamente disponibles no son traídas online. En Windows Server 2012, el proceso de alcanzar tal consenso ha sido mejorado mediante los siguientes cambios:

  • “Node Vote Weight”. Usando esta característica un administrador puede controlar cuales nodos votan; lo cual puede ser útil en configuraciones multisitio donde se podrían configurar que sólo los nodes en el sitio primario voten.
  • “Dynamic Quorum”. Esta característica –que está habilitada predeterminadamente- permite a cluster mismo administrar el quorum. El cluster ajusta los requerimientos del quorum basándose en el número de nodos que participan activamente en el cluster. Si los nodos son apagados (shutdown), el número de votos requeridos para alcanzar el consenso cambia. Esto último permite al cluster sobrevivir incluso cuando más del 50% de los nodes no están activos en el cluster.

Nuevos roles para alta disponibilidad. Windows Server 2012 Failover Clustering incluye nuevos roles:

  • Scale-Out File Server. Éste Nuevo role aprovecha el Nuevo tipo de recurso “Distributed Network Name” y shares SMB almacenados en CSV.
  • Hyper-V Replica. Éste rol usa el nuevo tipo de recurso Hyper-V Replica Broker
  • Storage Spaces. Éste rol hace el “virtualized storage” (Storage Spaces) altamente disponible. “Storage Spaces” son recursos de disco que igual pueden ser usados en CSV.
  • iSCSI Target. Éste rol hace a los “iSCSI Software Targets” altamente disponibles.
  • Scheduled Tasks. Este role hace las tareas programadas puedan estar en alta disponibilidad.
  • “Cluster-Aware Updating”. Este rol puede ser configurado desde PowerShell o desde la consola de administración, pero una vez ya configurado únicamente es visible desde PoweShell.

Almacenamiento. Las siguientes mejoras al “storage” han sido integradas a Windows Server 2012 Failover Clustering:

  • Cluster Shared Volumes v2. De esto hablaremos más extensamente en un post posterior, pero como adelanto podemos decir que ahora con esto se pueden usar “shares” SMB para alojar datos de aplicaciones (Hyper-V y SQL Server), entre muchas otras características.
  • Mejoras al algoritmo de reservaciones persistentes que demanda menos recursos de los sistemas de almacenamiento.
  • Failover Clustering aprovecha la nueva versión de CHKDSK. Antes con Windows Server 2008 R2, cuando se detectaba una corrupción en el sistema de archivos chkdsk era iniciado en la siguiente vez el disco se traía en línea, lo cual podía tardar largo tiempo representando en una afectación en la disponibilidad de los servicios. En Windows Server 2012, cuando un corrupción es detectada, primera se determina esta es pasajera o de mayor seriedad, para lo que en el segundo caso se intenta corregir el problema mientras en disco esta activo, y si no se tiene éxito NTFS reporta un evento, el cual incluye la acción recomendada manteniendo el disco en línea.

“Networking”. En Windows Server 2012, la infraestructura de red del cluster es más tolerante a fallas y provee mejor rendimiento, tanto que ahora que el trafico CSV usa la infraestructura de red de NetFT. Otras mejoras incluyen:

  • Detección automática de iSCSI deshabilitando tales redes para las comunicaciones intracluster.
  • Regeneración de la dirección MAC de la interfaz NetFT en caso de conflicto.
  • Acceso a los “shares” SMB mediante nombres NETBIOS, Dirección IP and Alias DNS.

Seguridad. En ésta área la principal mejora radica en ahora los “Physical Disks” y los “Cluster Shared Volumes” pueden ser encriptados usando Bitlocker. La desencripción ocurre usando la cuenta CNO (Cluster Name Object) como identidad común.

“Failover Cluster Manager interface”. Windows Server 2012 también viene con varias mejoras a la consola de administración del cluster, los cuales incluyen, entre otras:

  • Múltiple selección de recursos para ejecutar acciones como “Bring Online”, “Live Migrate”, etc.
  • Aplicación de filtros en basado en un criterio. Por ejemplo, un filtro podría sólo mostrar los grupos en estado “Failed”.

Hasta ahora sólo hemos mencionado los cambios más relevantes en Windows Server 2012 Failover Clustering y en posteriores publicaciones daremos más detalles de estas nuevas funcionalidades incluyendo el cómo hacerlo (how-to). Por el momento, espero esta primera publicación sea de su utilidad para empezar a planear la migración de sus clusters a Windows Server 2012.

Saludos cordiales,

Octavio Pineda

Senior Premier Field Engineer