Traducido del inglés al español - www.onlinedoctranslator.

com

FIGURA 4-25 Centro de recursos de Microsoft Azure

Resumen del capítulo

Los contenedores se basan en imágenes. Creas un contenedor ejecutando una imagen y creas
una imagen guardando el contenido de un contenedor.
Windows Server 2016 incluye la función Contenedores, que proporciona el entorno de
soporte para la plataforma Docker.
Las opciones de instalación de Server Core y Nano Server admiten la creación de
contenedores de Windows Server e Hyper-V. En Nano Server, puede ejecutar el cliente
Docker.exe en un sistema remoto.
Docker es una solución de contenedor de código abierto que consta de dos archivos:
Dockerd.exe, que es el motor que se ejecuta como servicio en Windows, y Docker.exe, que es el
cliente de línea de comandos que controla el motor Dockerd.
Con un archivo de texto llamado daemon.json, puede configurar las opciones de inicio para el
motor Dockerd.

El cliente de Docker es una forma de controlar el motor de Docker, pero no es la única. También
puede usar el módulo Docker para Windows PowerShell para realizar las mismas tareas.

Para descargar imágenes desde Docker Hub, use el comando Docker Pull.
Las etiquetas son indicadores de versión que los desarrolladores pueden usar para rastrear las compilaciones o versiones de

una imagen de contenedor. Para asignar valores de etiqueta, use el comando Etiqueta de Docker.

Para desinstalar una imagen de contenedor, use el comando Docker RMI.

Para crear un contenedor de Windows Server, use el comando Docker Run, especificando el nombre
de una imagen de contenedor.

El procedimiento para crear un contenedor Hyper-V con Docker difiere de un

contenedor de Windows Server solo en la inclusión del parámetro --isolation.
El cliente Docker.exe le permite controlar contenedores iniciando, deteniendo, guardando,

401
 y eliminándolos.
El módulo Docker para Windows PowerShell proporciona una alternativa al cliente
Docker.exe que puede realizar la mayoría, si no todas, las mismas funciones.
De forma predeterminada, Docker utiliza la traducción de direcciones de red para proporcionar a los contenedores
acceso a la red. Sin embargo, puede anular los contenedores predeterminados y configurarlos para que formen
parte de su red más grande.

Docker le permite crear volúmenes de datos que existen en el host del contenedor y agregarlos a un
contenedor. Los volúmenes de datos permanecen en su lugar, incluso si retira el contenedor.

Al usar parámetros en la línea de comando Docker Run, puede limitar la cantidad de

memoria y recursos de CPU que un contenedor puede usar.
Un dockerfile es un script que contiene instrucciones para crear una nueva imagen de
contenedor. Utiliza el comando Docker Build para ejecutar el script y crear la imagen.
Docker Hub es un repositorio gratuito, basado en la nube, en el que puede cargar su
Microsoft Azure le permite crear máquinas virtuales que puede usar como hosts de contenedor.

Experimento mental
En este experimento mental, demuestre sus habilidades y conocimiento de los temas cubiertos en este
capítulo. Puede encontrar la respuesta a este experimento mental en la siguiente sección.

Ralph quiere crear una máquina virtual llamada Core1 que funcione como un host contenedor
para los contenedores de Windows Server y Hyper-V. Para crear el host contenedor, planea realizar
las siguientes tareas:
Crea una máquina virtual.
Configure la máquina virtual con 4 GB de memoria, dos procesadores virtuales y la suplantación
de direcciones MAC habilitada.

Instale Windows Server 2016 en la máquina virtual.

Instale la función Contenedores.
Instale el rol de Hyper-V.
Instale el módulo dockermsftprovider.
Instale el paquete de Docker.
Extraiga la imagen de Server Core de DockerHub. Cree
contenedores con el comando Docker Run.
¿Qué paso ha olvidado Ralph que le impide crear los contenedores que necesita? ¿Qué
tarea debe realizar para completar su plan y cuándo debe completarlo?

Respuesta del experimento mental

402
Esta sección contiene la solución al experimento mental.
Ralph se olvidó de exponer las extensiones de virtualización del procesador de la computadora
física a la VM, para que pueda ejecutar el rol de Hyper-V. Para hacer esto, debe ejecutar el siguiente
comando en una sesión de PowerShell después de crear la máquina virtual y antes de iniciarla:

Haga clic aquí para ver la imagen del código

set-vmprocessor -vmname server1 -exposevirtualizationextensions $ true

403
Capítulo 5. Implementar la alta disponibilidad

Mantener las aplicaciones en funcionamiento en todo momento es una prioridad importante para muchos
administradores de sistemas, y Windows Server 2016 incluye características que le permiten crear soluciones de servidor
redundantes que pueden anticipar casi cualquier tipo de desastre. Los clústeres de conmutación por error le permiten
crear servidores que comparten datos, lo que garantiza que una aplicación se ejecute a pesar de múltiples fallas. Los
clústeres de equilibrio de carga de red le permiten proporcionar una aplicación con tolerancia a fallas y escalabilidad.

Habilidades en este capítulo:

Implemente opciones de alta disponibilidad y recuperación ante desastres en Hyper-VImplementar la agrupación en

clústeres de conmutación por error Implementar espacios de almacenamiento Direct Administrar la agrupación en clústeres

de conmutación por error

Administrar el movimiento de VM en nodos agrupados

Implementar el balanceo de carga de red (NLB)

Habilidad 5.1: Implementar opciones de alta disponibilidad y recuperación ante desastres en

Hyper-V
Hyper-V permite a los administradores consolidar varios servidores físicos en un solo servidor
Hyper-V. Una de las ventajas de virtualizar servidores de esta manera es que puede mover
fácilmente máquinas virtuales (VM) de un host Hyper-V a otro. Ya sea por razones de tolerancia a
fallas o por equilibrio de carga, Hyper-V proporciona varias tecnologías para replicar y migrar
máquinas virtuales.

Esta sección cubre cómo:

Implementar la réplica de Hyper-V

Implementar la migración en vivo

Implementar la migración en vivo de Shared Nothing

Configurar el protocolo de autenticación CredSSP o Kerberos para la migración en vivo Implementar

la migración de almacenamiento

Implementar la réplica de Hyper-V

La réplica de Hyper-V es una característica del rol de Hyper-V que le permite crear una réplica de las
máquinas virtuales en un servidor Hyper-V a otro servidor, localmente o en un sitio remoto. los

404
la replicación es asincrónica y el proceso de conmutación por error a la réplica no es automático. Sin
embargo, Hyper-V Replica es fácil de configurar y no requiere funciones de red avanzadas, como
almacenamiento compartido o un clúster de conmutación por error. Es una forma sencilla de crear una
réplica de un servidor Hyper-V que puede iniciar siempre que el servidor principal no esté disponible.

La réplica de Hyper-V se basa en puntos de control, por lo que una vez que se completa la replicación
inicial, solo se controlan y replican los cambios realizados en el servidor principal. Esto minimiza la cantidad
de datos transmitidos a través de la red y permite que el servidor de réplica cargue la máquina virtual para
acceder a sus puntos de control.

Hyper-V Replica tiene muchas opciones. No requiere un clúster de conmutación por error, pero
funciona en uno. No requiere certificados para transmisiones encriptadas, pero puede usarlos. Esto
permite a los administradores crear una configuración tan simple o tan compleja como necesiten.

Planificación del entorno de replicación

En su forma más simple, una implementación de réplica de Hyper-V usa dos servidores en la siguiente
configuración:

Hyper-V instalado en ambos servidores Los servidores

están ubicados detrás del mismo firewall Los servidores no

forman parte de un clúster

Los servidores están unidos al mismo dominio de Servicios de dominio de Active Directory (AD DS) o
dominios con relaciones de confianza mutua

Los servidores utilizan comunicaciones no cifradas y autenticadas por Kerberos

Cualquier excepción a estas políticas requiere procedimientos de configuración adicionales, como los
siguientes:

Si los servidores están ubicados en sitios diferentes, debe configurar los firewalls
intermedios para permitir que pase el tráfico de replicación.

Si el tráfico de replicación se va a cifrar, debe obtener un certificado de seguridad de una

autoridad de certificación adecuada (o utilizar un certificado autofirmado).
Si los servidores forman parte de un clúster de conmutación por error, debe configurar el rol de Agente de
réplica de Hyper-V y anotar el nombre del punto de acceso del cliente.

Si desea utilizar un tercer servidor para crear una réplica adicional, debe configurar la
réplica de Hyper-V para utilizar la réplica ampliada.

Configuración de los servidores Hyper-V

Para configurar la replicación en una dirección, debe configurar Hyper-V Replica en el servidor de destino, también
llamado servidor de réplica. Sin embargo, para usar Hyper-V Replica como solución de conmutación por error, la
práctica recomendada es configurar ambos servidores como servidores de réplica. De esta manera, después de un
incidente de conmutación por error en el que activa un servidor de réplica, puede replicar cualquier cambio
realizado en el ínterin en el servidor original una vez que vuelva a estar en línea.

405
 Para configurar un servidor Hyper-V como un servidor de réplica con Hyper-V Manager, utilice el
siguiente procedimiento:

1. Abra el Administrador de Hyper-V, seleccione el servidor y, en el panel Acciones, haga clic en Configuración de
Hyper-V para mostrar el cuadro de diálogo Configuración de Hyper-V.

2. En la página Configuración de replicación, seleccione la casilla de verificación Habilitar este equipo

como servidor de réplica, como se muestra en Figura 5-1.

406
FIGURA 5-1 La página Configuración de replicación del cuadro de diálogo Configuración de Hyper-V

3. En el cuadro Autenticación y puertos, seleccione una de las siguientes opciones:

Utilice Kerberos (HTTP) El tráfico de réplica no se cifrará y los servidores deben unirse
al mismo dominio (o dominios de confianza).
Usar autenticación basada en certificados (HTTPS) Haga clic en Seleccionar certificado para
especificar el certificado que se utilizará para el cifrado de tráfico de réplicas.

4. En el cuadro Autorización y almacenamiento, seleccione una de las siguientes opciones:

Permitir la replicación desde cualquier servidor autenticado Habilita la replicación desde cualquier
servidor y guarda las réplicas en la ubicación que especifique.

407
 Replicación permitida desde los servidores especificados Haga clic en Agregar para abrir el cuadro de
diálogo Agregar entrada de autorización, que se muestra en Figura 5-2, en el que especifica un nombre de
servidor, una ubicación para las réplicas de ese servidor y un grupo de confianza al que pertenece.

FIGURA 5-2 El cuadro de diálogo Agregar entrada de autorización

5. Haga clic en Aceptar.

También puede configurar las opciones de configuración de la réplica de un servidor mediante el cmdlet Set-
VmReplicationServer para Windows PowerShell. Este cmdlet se incluye en el módulo de Hyper-V, por lo que debe
tener instaladas las herramientas de administración de Hyper-V para usarlo. El comando para una configuración
simple de réplica de Hyper-V aparece de la siguiente manera:

Haga clic aquí para ver la imagen del código

set-vmreplicationserver -replicationenabled $ true -

allowedauthenticationtype kerberos
- replicationallowedfromanyserver $ true -defaultstoragelocation d: \ replicas

También debe configurar el Firewall de Windows en un servidor de réplica para permitir el tráfico entrante

408
desde el servidor primario. Para hacer esto, abra la consola Firewall de Windows con seguridad
avanzada y, en la página Reglas de entrada, que se muestra enFigura 5-3, habilite una de las
siguientes reglas, según sus selecciones en la página Configuración de replicación:
Si seleccionó la opción Usar Kerberos (HTTP), habilite la regla de escucha HTTP de réplica
de Hyper-V (TCP-In).
Si seleccionó la opción Usar autenticación basada en certificados (HTTPS), habilite la regla de
escucha de HTTPS de réplica de Hyper-V (TCP-In).

FIGURA 5-3 El Firewall de Windows con la consola de seguridad avanzada

Para configurar la regla de firewall con PowerShell, use el cmdlet Enable-NetFirewallRule,

como en los siguientes ejemplos:
Haga clic aquí para ver la imagen del código

enable-netfirewallrule -displayname "escucha http de réplica de hyper-v (tcp-

in)"

enable-netfirewallrule -displayname "escucha https de réplica de hyper-v (tcp-

in)"

Como se mencionó anteriormente, este proceso de configuración solo es necesario en el servidor de réplica,
pero es posible que desee considerar configurar el servidor primario de la misma manera, en

409
anticipación de una recuperación de una situación de conmutación por error.

Configurando las máquinas virtuales

Una vez que el servidor de réplica está configurado, puede proceder a configurar las máquinas virtuales en el
servidor principal que desea replicar. Para hacer esto, utilice el siguiente procedimiento.

1. En Hyper-V Manager, haga clic con el botón derecho en una máquina virtual y, en el menú contextual,
seleccione Habilitar replicación para iniciar el Asistente para habilitar replicación.

2. En la página Especificar servidor réplica, escriba el nombre del servidor réplica que ha configurado o
haga clic en Examinar para abrir un cuadro de diálogo Seleccionar equipo.

3. En la página Especificar parámetros de conexión, en el cuadro Tipo de autenticación, especifique si

desea utilizar Kerberos o autenticación basada en certificados, utilizando la misma configuración que
eligió en el servidor de réplica. También puede especificar si desea comprimir los datos de
replicación.

4. En la página Choose Replication VHDs, desactive las casillas de verificación de cualquier

VHD en la máquina virtual que no desee replicar.
5. En la página Configurar frecuencia de replicación, especifique la frecuencia con la que el servidor
principal debe enviar cambios al servidor de réplica: cada 30 segundos, 5 minutos o 15 minutos.

6. En la página Configurar puntos de recuperación adicionales, seleccione una de las siguientes

opciones:

Mantenga solo el último punto de recuperación Esta opción crea una réplica que contiene solo el
estado de la máquina virtual principal en el momento del último evento de replicación.

Cree puntos de recuperación adicionales por hora Esta opción le permite replicar hasta 24
horas de puntos de recuperación y hasta 12 horas de instantáneas del Servicio de instantáneas de
volumen.

7. En la página Choose Initial Replication Method, que se muestra en Figura 5-4, especifique si desea
realizar la replicación inicial enviándola a través de la red, transportándola manualmente en un
medio externo o creando usted mismo una máquina virtual en el servidor de réplica. Estas opciones
le permiten evitar la replicación de una máquina virtual completa a través de enlaces de red de área
amplia (WAN) relativamente lentos o costosos.

410
 FIGURA 5-4 La página Elegir método de replicación inicial de Habilitar replicación
Mago
8. En el cuadro Programar replicación inicial, especifique cuándo debe comenzar el proceso de replicación,
inmediatamente o en el momento que usted especifique.
pr9. Haga clic en Finalizar.

Una vez que comienza el proceso de replicación, aparece un menú contextual de replicación cuando hace clic con el botón derecho

en la máquina virtual, lo que le permite iniciar una conmutación por error planificada, pausar o eliminar la replicación.

proceso, y mostrar un cuadro de diálogo Replication Heath, como se muestra en Figura 5-5.

411
 FIGURA 5-5 El cuadro de diálogo Estado de la replicación

Implementar la migración en vivo

Una de las principales ventajas de la virtualización de servidores, si no la principal, es la capacidad de

consolidar varios servidores físicos en un servidor Hyper-V que ejecuta varias máquinas virtuales.
Debido a que todas las máquinas virtuales se ejecutan en la misma plataforma de hardware virtualizado,
es fácil moverlas a diferentes hosts de Hyper-V, con fines de equilibrio de carga o tolerancia a fallas.
Migración en vivo es una función de Hyper-V que hace posible mover una máquina virtual de un host de
Hyper-V a otro mientras está en ejecución, sin casi ninguna interrupción del servicio.

Live Migration no es una alternativa a Hyper-V Replica; no mueve los archivos de datos de la
máquina virtual. Live Migration está diseñado para entornos en los que virtual

412
las máquinas ya tienen acceso al almacenamiento de datos compartidos; lo que se migra es el estado del sistema y el
contenido de la memoria en vivo. Si, por ejemplo, tiene un clúster de conmutación por error de Hyper-V que ejecuta un
servidor web, con todos los nodos del clúster accediendo a la misma matriz de almacenamiento que contiene los
archivos del sitio web, Live Migration puede mover una máquina virtual de un host de Hyper-V a otro sin interrumpir las
transacciones del cliente en curso.

Originalmente concebido para su uso en clústeres de conmutación por error con subsistemas físicos de
almacenamiento compartido, Live Migration en Windows Server 2016 ahora puede funcionar con sistemas no
agrupados, sistemas en diferentes dominios o ningún dominio en absoluto, y sistemas que utilizan casi cualquier tipo
de almacenamiento compartido, físico o virtual.

Una migración en vivo típica de una máquina virtual se lleva a cabo de la siguiente manera:

1. El servidor de origen establece una conexión con el servidor de destino, que crea una máquina
virtual vacía y confirma que tiene los recursos para recrear la máquina virtual de origen, como
memoria suficiente y acceso al almacenamiento compartido que contiene los archivos de la
máquina virtual.

2. El destino asigna memoria y otros recursos a la nueva VM, esencialmente

recreando la configuración de hardware virtual de la VM de origen.
3. El servidor de origen comienza a transmitir las páginas de memoria de la VM a la VM de destino. La máquina virtual de
origen todavía está funcionando en este punto, dando servicio a los clientes de la manera habitual. Sin embargo, a
medida que avanza la transferencia de memoria, Hyper-V en el servidor de origen comienza a marcar las páginas de su
memoria que hayan cambiado desde que comenzó la transferencia.

4. Una vez que se completa la transferencia de memoria inicial, el proceso comienza de nuevo, y el servidor de
origen transfiere las páginas de memoria que han cambiado desde que comenzó la transferencia inicial.
Este proceso se repite a lo largo de varias iteraciones, hasta que los servidores alcanzan un punto crítico en
el que sus estados de memoria son idénticos.

5. En este punto, el procesamiento y la E / S se suspenden en la VM de origen y el control de los

recursos de almacenamiento se transfiere a la VM de destino.

6. La máquina virtual de destino ahora tiene un "conjunto de trabajo" actualizado de contenido de memoria, estado de la CPU

y recursos de almacenamiento, y puede asumir la funcionalidad de la máquina virtual.

7. Con la VM de destino en funcionamiento, Hyper-V notifica al conmutador de red del

cambio, lo que hace que registre las direcciones MAC de la VM de destino y las asocie con
su dirección IP, de modo que el tráfico de red se desvíe a la nueva máquina virtual.

A pesar de toda esta actividad, una migración en vivo generalmente se completa en menos tiempo que
el intervalo de tiempo de vida de TCP de la VM. Por tanto, el cambio es invisible, tanto para los clientes
como para el software que se ejecuta en la máquina virtual. Hay muchos factores que pueden afectar la
velocidad de una migración en vivo, incluida la cantidad de memoria que se transferirá, el ancho de banda
disponible en la red y la carga de trabajo en los servidores de origen y destino. Sin embargo, cualquier
retraso perceptible que se produzca suele deberse al tiempo necesario para que la red propague el cambio
de destino.

413
Migración en vivo en un clúster

Cuando usa la función de clústeres de conmutación por error en Windows Server 2016 para crear un clúster
de Hyper-V, usa la consola del Administrador de clústeres de conmutación por error para iniciar el Asistente
para nueva máquina virtual. El asistente en sí es el mismo al que puede acceder a través de Hyper-V Manager,
pero después de que se crea la VM, Failover Cluster Manager inicia el Asistente de alta disponibilidad, que
configura la VM para admitir la migración en vivo. En el equivalente de PowerShell, use los cmdlets estándar
para crear la máquina virtual y luego ejecute el cmdlet Add-ClusterVirtualMachineRole para que la máquina
virtual tenga una alta disponibilidad.

Migración en vivo sin un clúster

Es posible, en Windows Server 2016, realizar migraciones en vivo entre servidores Hyper-V que no
están agrupados, aunque deben ser miembros del mismo dominio (o dominios de confianza). Sin
embargo, antes de poder hacer esto, debe configurar los ajustes de migración en vivo, tanto en el
servidor de origen como en el de destino.
Para hacer esto usando el Administrador de Hyper-V, abra el cuadro de diálogo Configuración de Hyper-V, seleccione la
página de Migración en vivo y seleccione la casilla de verificación Habilitar migraciones en vivo entrantes y salientes, como se
muestra en Figura 5-6.

414
 FIGURA 5-6 La página de migraciones en vivo en el cuadro de diálogo Configuración de Hyper-V

Luego, configure los siguientes ajustes en esa página y en la página Migraciones en vivo / Funciones
avanzadas:

Migraciones simultáneas en vivo Le permite especificar cuántas migraciones en vivo puede realizar
el servidor al mismo tiempo, según el ancho de banda y los niveles de tráfico de su red y la carga de
trabajo en el servidor. La configuración predeterminada es 2.

Migraciones en vivo entrantes Si el servidor está conectado a más de una red, esta
configuración le permite especificar qué red debe usar el servidor para el tráfico de
migración en vivo y el orden en el que se deben usar varias redes. Siempre que sea posible,
la mejor práctica es separar el tráfico de migración en vivo del área local estándar

415
 tráfico de red (LAN).
Protocolo de autenticación Le permite especificar si usar CredSSP o Kerberos
para la autenticación entre los servidores. Kerberos requiere una configuración
adicional de delegación restringida en Active Directory.
Opciones de desempeño Le permite especificar si desea utilizar los protocolos TCP / IP o Server
Message Block (SMB) para las transferencias de datos de migración en vivo. Si tiene una red dedicada al
tráfico de almacenamiento o una red que utiliza puentes de centros de datos para separar el tráfico de
almacenamiento y LAN, SMB probablemente sea una mejor opción. En una conexión LAN estándar,
utilice TCP / IP.

Para configurar estos ajustes mediante PowerShell, utilice comandos como los siguientes:

Haga clic aquí para ver la imagen del código

enable-vmmmigration

set-vmmigrationnetwork 192.168.4.0

set-vmhost -virtualmachinemigrationauthenticatiuontype kerberos

set-vmhost -virtualmachinemigrationperformanceoption
smbtransport

Una vez que los servidores están configurados, usted inicia una migración en vivo usando el Asistente de
movimiento, al que accede seleccionando una máquina virtual en Hyper-V Manager, eligiendo Mover en el panel
Acciones. En la página Choose Move Type del asistente, que se muestra enFigura 5-7, la opción Mover la máquina
virtual le permite realizar una migración en vivo.

416
 FIGURA 5-7 La página Elegir tipo de movimiento en el Asistente de movimiento

Cuando selecciona Mover la máquina virtual, la página Elegir opciones de movimiento, que se muestra en
Figura 5-8, proporciona las siguientes opciones:

Mueva los datos de la máquina virtual a una sola ubicación Hace que el asistente mueva la
máquina virtual y su almacenamiento a la ubicación predeterminada en el servidor de destino.

Mueva los datos de la máquina virtual seleccionando dónde mover los elementosHace que
el asistente mueva la máquina virtual y su almacenamiento a una ubicación que especifique en
el servidor de destino.

Mover solo la máquina virtual Hace que el asistente mueva la máquina virtual al servidor
de destino sin su almacenamiento. Esta opción proporcionó el equivalente no agrupado de
una migración en vivo.

417
 FIGURA 5-8 La página Elegir opciones de movimiento en el Asistente de movimiento

Para realizar una migración en vivo con PowerShell, use el cmdlet Move-VM, como en el
siguiente ejemplo:
Haga clic aquí para ver la imagen del código

Move-vm -vm server1 -destinationhost hyper2

Implementar la migración en vivo sin compartir

Live Migration fue originalmente una herramienta con requisitos muy restrictivos. Sus servidores debían
formar parte de un clúster y las máquinas virtuales debían tener acceso al almacenamiento compartido.
Windows Server 2016 hace posible migrar máquinas virtuales entre hosts Hyper-V sin ninguno de esos
requisitos, utilizando una función conocida como Shared Nothing Live Migration.

Shared Nothing Live Migration es esencialmente una combinación de una migración en vivo y una migración
de almacenamiento. En la superficie, el procedimiento es esencialmente el mismo que el descrito para una
migración en vivo, excepto que el servidor de origen copia el almacenamiento de la VM en el destino, además de
su memoria y el estado del sistema. Obviamente, el proceso de migración

418
toma mucho más tiempo que la migración en vivo estándar, dependiendo de la cantidad de almacenamiento
involucrado y el ancho de banda de red disponible, pero al igual que con una migración en vivo, la máquina virtual
de origen continúa activa hasta que se completa la transferencia de datos.

Una migración en vivo sin compartir tiene los siguientes requisitos previos:

Las máquinas virtuales de origen y destino deben ser miembros del mismo dominio de AD DS (o
dominios de confianza).

Los servidores de origen y de dominio deben utilizar la misma familia de procesadores (Intel o
AMD).

Los servidores de origen y destino deben estar conectados mediante una red Ethernet que funcione a
un mínimo de 1 gigabit por segundo (Gbps).

Los servidores de origen y destino deben tener conmutadores virtuales idénticos que usen el mismo
nombre. Si no lo hacen, el proceso de migración se interrumpirá para solicitar al operador que
seleccione un conmutador en el servidor de destino.

Al igual que con una migración en vivo no agrupada, debe habilitar la migración en vivo en el cuadro de diálogo
Configuración de Hyper-V, y las diversas configuraciones en las páginas de Migraciones en vivo y Funciones
avanzadas también se aplican aquí. El procedimiento para realizar una migración en vivo de nada compartido es el
mismo también, usando el Asistente para mover, excepto que selecciona la opción Mover los datos de la máquina
virtual a una sola ubicación en la página Elegir opciones de movimiento.

Configurar el protocolo de autenticación CredSSP o Kerberos para la migración en vivo

Cuando habilita la migración en vivo en un servidor Hyper-V, puede elegir entre dos
protocolos de autenticación:
Proveedor de soporte de seguridad de credenciales (CredSSP) CredSSP es un protocolo de
autenticación que permite a un cliente delegar las credenciales de un usuario para la autenticación en un
servidor remoto. En Hyper-V, CredSSP es el protocolo de autenticación predeterminado para Live
Migration. El protocolo no requiere una configuración especial, pero sí requiere que un usuario inicie
sesión en el servidor de origen antes de realizar una migración en vivo.

Kerberos El protocolo de autenticación predeterminado para Active Directory, Kerberos, no

requiere que inicie sesión, como lo hace CredSSP, pero debe configurarlo para usar la
delegación restringida antes de poder realizar migraciones en vivo.
La delegación restringida es un elemento del protocolo Kerberos que permite que un servidor actúe en
nombre de un usuario, pero solo para servicios específicos. Para configurar la delegación restringida, debe
iniciar sesión como administrador de dominio y utilizar el siguiente procedimiento.

1. Abra la consola Usuarios y equipos de Active Directory.

2. Vaya al contenedor Computadoras y localice el objeto de computadora para el servidor de
origen de Live Migration.

3. Abra la hoja Propiedades para el objeto de computadora del servidor de origen y seleccione la
pestaña Delegación, como se muestra en Figura 5-9.

419
 FIGURA 5-9 La pestaña Delegación de la hoja de Propiedades de un objeto de computadora

4. Seleccione la opción Confiar en este equipo para la delegación a los servicios especificados
únicamente y deje seleccionada la opción Usar solo Kerberos.

5. Haga clic en Agregar y, en el cuadro de diálogo Agregar servicios, haga clic en Usuarios o equipos.

6. En el cuadro de diálogo Seleccionar usuarios o equipos, escriba el nombre del servidor de destino y haga
clic en Aceptar.

420
 7. En el cuadro Servicios disponibles, seleccione uno o ambos de los siguientes servicios, según sea necesario, y
haga clic en Aceptar.

cifs Permite al usuario de la computadora mover el almacenamiento de la máquina virtual, con o sin
la propia máquina virtual.

Servicio de migración de sistema virtual de Microsoft Permite que la computadora mueva

máquinas virtuales.

8. Haga clic en Aceptar para cerrar la hoja de Propiedades.

9. Repita el procedimiento para el equipo de destino de Live Migration, especificando el

nombre del equipo de origen en el cuadro de diálogo Seleccionar usuarios o equipos.

Implementar la migración de almacenamiento

Live Migration está diseñado para mover una máquina virtual de un servidor host de Hyper-V a otro, sin tocar los
archivos, que se supone que son accesibles en el almacenamiento compartido. La migración de almacenamiento
(a veces denominada, de manera algo inexacta, migración de almacenamiento en vivo) es exactamente lo
contrario; mueve los archivos de la máquina virtual a otra ubicación, mientras que la máquina virtual permanece
en su lugar.

Puede utilizar Storage Migration para mover los archivos de una máquina virtual, incluidos archivos de
configuración, puntos de control y archivos de paginación inteligente, a cualquier ubicación a la que el usuario tenga
permiso de acceso, incluido otro disco o directorio en la misma computadora o en una computadora diferente. Al igual
que con Live Migration, las migraciones de almacenamiento pueden ocurrir mientras la máquina virtual está en
ejecución o mientras está detenida.

En comparación con una migración en vivo, la migración de almacenamiento utiliza un proceso relativamente simple:

1. Cuando inicia una migración de almacenamiento, el servidor de destino crea nuevos archivos de disco
duro virtual de tamaños y tipos correspondientes a los del servidor de origen.

2. La máquina virtual en el servidor de origen continúa funcionando con sus archivos locales, pero Hyper-V
también comienza a reflejar las escrituras de disco en el servidor de destino.

3. Mientras continúa reflejando escrituras, Hyper-V en el servidor de origen inicia una copia
de un solo paso de los discos de origen en el destino. Se omiten los bloques que ya se han
escrito en el destino mediante el proceso de duplicación.
4. Cuando se completa la copia de una sola pasada y continúan las escrituras duplicadas, Hyper-V
actualiza la configuración de la máquina virtual y comienza a trabajar desde los archivos en el
servidor de destino.

5. Una vez que la máquina virtual se ejecuta correctamente desde los archivos migrados, Hyper-V elimina los
archivos de origen.

Si la máquina virtual de origen está apagada, no es necesario ningún procedimiento especial. Hyper-V
simplemente copia los archivos del origen al destino, reconfigura la máquina virtual para usar los
archivos de destino y luego borra los archivos de origen.

Apenas existen requisitos especiales para realizar una migración de almacenamiento, excepto

421
que no puede migrar máquinas virtuales que utilizan discos de transferencia para su almacenamiento. Los archivos deben
almacenarse en archivos de disco duro virtual (ya sea VHD o VHDX).

Para realizar una migración de almacenamiento, use el mismo Asistente de movimiento que para las
migraciones en vivo no agrupadas y las migraciones en vivo sin contenido compartido. En la página Choose
Move Type del asistente, seleccione la opción Move The Virtual Machine's Storage. Aparece la página Choose
Options For Moving Storage, como se muestra enFigura 5-10, con las siguientes opciones:

Mueva todos los datos de la máquina virtual a una única ubicación Le permite especificar un
destino para todos los archivos de la máquina virtual de origen.

Mueva todos los datos de la máquina virtual a diferentes ubicaciones Agrega varias
pantallas al asistente, en las que puede seleccionar los tipos de archivo para migrar y
especificar un destino para cada tipo.
Mueva solo los discos duros virtuales de la máquina virtual Le permite seleccionar
qué archivos VHD / VHDX migrar y especificar un destino para cada uno.

422
 FIGURA 5-10 La página Elegir opciones para mover almacenamiento en el Asistente para mover

Habilidad 5.2: Implementar la agrupación en clústeres de conmutación por error

A clúster de conmutación es un grupo de dos o más computadoras, físicas o virtuales, y que ejecutan la misma
aplicación, que funciona como una sola entidad para brindar un servicio de alta disponibilidad, escalable y
tolerante a fallas a los clientes en la red. Las aplicaciones agrupadas generalmente brindan servicios esenciales
para el usuario, como aplicaciones de servidor de correo electrónico y bases de datos, o servicios de
infraestructura, como Hyper-V y servidores de archivos. Con varias computadoras llamadasnodos: Al ejecutar la
misma aplicación, los servicios están siempre disponibles, incluso cuando falla un nodo. Cuando aumenta la
demanda del servicio, los administradores pueden agregar fácilmente más nodos al clúster, aumentando su
capacidad general.

En Windows Server 2016, la función de agrupación en clústeres de conmutación por error proporciona las
herramientas necesarias para crear un clúster de hasta 64 equipos, que admiten hasta 8.000 máquinas virtuales,
con un máximo de 1.024 máquinas virtuales por nodo. La función incluye una herramienta de administración
gráfica, la consola Failover Cluster Manager, además de un módulo de Windows PowerShell con una colección
completa de cmdlets.

Aunque es posible crear un clúster simple de dos nodos en un entorno de laboratorio, incluso en

423
un solo servidor Hyper-V, los clústeres de conmutación por error generalmente tienen requisitos
sofisticados de hardware y software, especialmente cuando brindan servicios vitales a muchos clientes
en un entorno de producción. Los requisitos de hardware y software incluyen lo siguiente:

Servidores Las computadoras que funcionan como nodos de clúster están diseñadas para ser
intercambiables, por lo que deben ser lo más idénticas posible en sus configuraciones de hardware.
La situación ideal es aquella en la que cada nodo del clúster tiene el mismo número y tipo de
procesadores y la misma cantidad de memoria. Los adaptadores de red en todas las computadoras
deben configurarse de manera idéntica. Para el soporte de Microsoft, todos los componentes de
hardware y software en los nodos del clúster deben cumplir con los requisitos del logotipo Certificado
para Windows Server 2016.

Sistema operativo Todos los servidores de un clúster deben ejecutar la misma versión y
edición del sistema operativo, con las mismas actualizaciones aplicadas.
Almacenamiento Los clústeres de conmutación por error suelen utilizar una implementación de almacenamiento
compartido, como una red de área de almacenamiento (SAN) o un almacenamiento conectado a la red (NAS), para que
todos los nodos puedan acceder a los mismos archivos de datos. En un momento, esto requería una infraestructura de
hardware de almacenamiento dedicada y elaborada, incluso si los nodos del clúster fueran virtuales, pero tecnologías
como iSCSI ahora han hecho posible la creación de subsistemas de almacenamiento compartido utilizando
componentes listos para usar e infraestructuras de disco virtual. .

Redes Los clústeres de conmutación por error intercambian su propio tráfico de control
entre los nodos y, en una implementación grande, se recomienda que haya una red separada
dedicada al tráfico del clúster. Además, la infraestructura de almacenamiento compartido
normalmente también debería tener su propia red dedicada. Por lo tanto, una
implementación de clúster de conmutación por error puede tener tres o más interfaces de
red por nodo, que admiten estos diversos tipos de tráfico, así como los conmutadores,
cableado y otros componentes adicionales necesarios para admitir las redes adicionales. Para
aplicaciones de misión crítica, también puede ser necesario combinar las implementaciones
de red con adaptadores, conmutadores y cableado redundantes, para evitar puntos únicos de
falla. Para implementaciones más pequeñas, como en un entorno de laboratorio, también es
posible utilizar tecnologías de calidad de servicio, como Datacenter Bridging,

Aplicaciones Además de los requisitos de hardware para el clúster en sí, también debe
considerar los requisitos para la aplicación que se ejecutará en los nodos del clúster. Por
ejemplo, los nodos de un clúster de Hyper-V deben cumplir con los requisitos de hardware
de virtualización especificados para el rol de Hyper-V.
Debido a que la configuración de hardware es una parte integral de la creación de un clúster, el Administrador
de clústeres de conmutación por error incluye un Asistente para validar clústeres que realiza una serie de pruebas
en los servidores que seleccione para determinar si son elegibles para ser miembros de un clúster. También puede
usar el cmdlet Test-Cluster PowerShell para iniciar estas pruebas. El proceso de validación genera un informe
detallado, como el que se muestra enFigura 5-11.

424
 FIGURA 5-11 Un informe de validación del clúster de conmutación por error

Una vez que la configuración de hardware del clúster se haya validado correctamente, puede
proceder a crear el clúster mediante el Asistente para crear clústeres o el cmdlet New-Cluster. Para
hacer esto, especifique el nombre de los servidores que desea agregar como nodos en el clúster.
También especifica un nombre para el clúster, que es cómo se direccionará en la red, como se muestra
en el siguiente ejemplo:

Haga clic aquí para ver la imagen del código

nuevo-clúster -nombre clúster1 -nodo servidor1, servidor2

El clúster es una entidad separada, con su propio nombre y dirección IP. Si hay un servidor
DHCP disponible en la red, el clúster obtendrá una dirección IP desde allí. De lo contrario, debe
asignar al clúster una dirección estática, como en el siguiente ejemplo:
Haga clic aquí para ver la imagen del código

nuevo-clúster -nombre clúster1 -nodo servidor1, servidor2 -staticaddress 10.0.0.3

El clúster también tiene su propio objeto de computadora en Active Directory, llamado objeto de nombre de
clúster (CNO). Una vez que la aplicación se esté ejecutando en los nodos del clúster, los clientes abordarán

425
sus solicitudes al clúster en sí, no a un servidor individual.

Esta sección cubre cómo:

Implementar clústeres de grupo de trabajo, de un solo dominio y de varios dominios

Configurar el quórum

Configurar redes de clúster

Restaurar la configuración de un solo nodo o clúster

Configurar el almacenamiento del clúster

Implementar la actualización compatible con clústeres

Implementar la actualización gradual del sistema operativo del clúster

Configurar y optimizar los volúmenes compartidos en clúster (CSV)

Configurar los clústeres sin nombres de red

Implementar el servidor de archivos de escalabilidad horizontal (SoFS)

Determinar diferentes escenarios para el uso de SoFS frente al servidor de archivos en clúster Determinar

escenarios de uso para implementar la agrupación en clústeres de invitados

Implementar una solución de espacios de almacenamiento en clúster utilizando gabinetes de almacenamiento SAS

compartidos

Implementar la réplica de almacenamiento

Implementar el testigo en la nube Implementar

la resiliencia de la máquina virtual

Implementar VHDX compartido como solución de almacenamiento para clústeres invitados

Implementar clústeres de grupos de trabajo, de un solo dominio y de varios dominios

Antes de Windows Server 2016, todos los servidores de un clúster de conmutación por error debían unirse al
mismo dominio de AD DS. Esto ahora se llamaclúster de dominio único. Como se mencionó anteriormente, el
Asistente para crear clústeres y el cmdlet New-Cluster crean un objeto de AD DS que representa el clúster de
forma predeterminada.

Sin embargo, a partir de Windows Server 2016, es posible crear un clúster utilizando servidores unidos a
diferentes dominios, lo que se denomina clúster multidominio, o servidores que no están unidos a ningún
dominio, lo que se denomina clúster de grupo de trabajo.

La agrupación en clústeres de conmutación por error utiliza Active Directory para una variedad de servicios, entre los
cuales se encuentra la ubicación del clúster en sí. Sin la compatibilidad con Active Directory, es necesario que el clúster
utilice DNS para registrar un punto de acceso administrativo, también conocido como nombre de red del clúster.

También existen problemas de Active Directory con algunas aplicaciones que impiden que se
ejecuten en un clúster de varios dominios o grupos de trabajo. Microsoft SQL Server funciona bien

426
sin Active Directory porque tiene su propio mecanismo de autenticación. Sin embargo, un clúster de
servidores de archivos sin autenticación de Active Directory requeriría la creación de cuentas de usuario
en cada nodo del clúster.
Antes de poder crear un clúster de grupo de trabajo o multidominio, debe completar las
siguientes tareas.

Crea una cuenta local

En un clúster de dominio único, una cuenta de usuario de dominio puede proporcionar acceso a todos
los nodos. Sin Active Directory, el acceso a los nodos para las comunicaciones del clúster es un problema.
Por lo tanto, debe crear una cuenta de usuario local en cada nodo, con el mismo nombre de usuario y la
misma contraseña. Luego, debe agregar el usuario al grupo de administradores local.

Puede utilizar la cuenta de administrador incorporada para este propósito, que ya es

miembro del grupo de administradores, si le asigna la misma contraseña en cada nodo. Sin
embargo, si no usa la cuenta de administrador, debe establecer una clave de registro llamada
LocalAccountTokenFilterPolicy en cada nodo, usando el siguiente comando en una sesión de
PowerShell con privilegios administrativos:
Haga clic aquí para ver la imagen del código

ruta-nueva-propiedad-ite
hklm: \ software \ microsoft \ windows \ currentversion \ policies \ system
- nombre localaccounttokenfilterpolicy -value 1

Agregar sufijos DNS

Sin Active Directory, un clúster debe usar DNS para ubicar los nodos del clúster y el clúster en sí.
Por lo tanto, debe especificar un sufijo DNS primario al asignar un nombre a cada nodo, como se
muestra enFigura 5-12.

427
 FIGURA 5-12 Asignar un sufijo DNS principal

No hay una forma directa de configurar el sufijo DNS primario usando PowerShell, pero puede
hacerlo usando la Política de grupo, navegando a la Computadora
Configuración \ Políticas \ Plantillas administrativas \ Red \ Cliente DNS y habilitando la política
Sufijo DNS primario, como se muestra en Figura 5-13.

428
 FIGURA 5-13 El cuadro de diálogo de la política de sufijo DNS primario

Para un clúster de varios dominios, también debe configurar la Configuración avanzada de TCP / IP en
cada nodo con los sufijos DNS para todos los dominios representados en el clúster, como se muestra en
Figura 5-14.

429
 FIGURA 5-14 Especificar sufijos DNS adicionales

También puede hacer esto mediante el cmdlet de PowerShell Set-DnsClientGlobalSettings, como se

muestra en el siguiente ejemplo:

Haga clic aquí para ver la imagen del código

set-dnsclientglobalsettings -suffixsearchlist @ ("adatum.com", "corp.adatum.com",

"paris.
adatum.com "," rome.adatum.com ")

Crear un grupo de trabajo o un clúster multidominio

Con esta configuración en su lugar, puede proceder a crear el clúster. Cuando usa PowerShell,
usa el cmdlet New-Cluster, tal como lo haría para un solo clúster de dominio, pero

430
debe incluir el parámetro AdministrativeAccessPoint con el valor de DNS, como se muestra en el
siguiente ejemplo:

Haga clic aquí para ver la imagen del código

nuevo-clúster –nombre clúster1 -nodo servidor1, servidor2, servidor3 - punto

de acceso administrativo dns

El parámetro AdministrativeAccessPoint hace que el cmdlet use un nombre DNS para el clúster y
evita que cree un objeto de equipo en Active Directory. También puede usar el Administrador de
clústeres de conmutación por error para crear el clúster, si el equipo que usa no está unido a un
dominio de AD DS.

Configurar quórum
La función de quórum en la agrupación en clústeres de conmutación por error es evitar que un clúster se divida
en dos y que ambas mitades continúen ejecutándose. A esto se le llamacerebro dividido situación. Si, por ejemplo,
una falla en la red hace que un clúster de seis nodos se divida en dos clústeres de tres nodos, ambos podrían
seguir funcionando si no fuera por el quórum. Si el clúster estuviera ejecutando una aplicación de base de datos,
eso significaría que hay dos copias separadas de la base de datos a las que diferentes conjuntos de clientes
acceden y actualizan al mismo tiempo. Esto podría ser desastroso para la integridad de la información en la base
de datos.

El quórum proporciona un voto a cada nodo del clúster y, en muchos casos, hay un disco testigo que
agrega otro voto para romper posibles vínculos. Todos los nodos monitorean los votos continuos de los
otros nodos y del testigo. Si un nodo detecta que el recuento de votos cae por debajo del 50 por ciento
+1, se elimina del grupo. En el caso del clúster de seis nodos dividido por la mitad mencionado
anteriormente, todos los nodos verían el recuento de votos caer de 6 a 3. Debido a que 3 es menos del
50 por ciento +1, todos los nodos se eliminarían solos, cerrando ambas mitades. del clúster.

Si hubiera un disco testigo en algún lugar de este clúster, entonces la mitad que puede
contactar con el disco testigo tendría un recuento de votos de 4, que es 50 por ciento +1 del clúster
original. Por tanto, la mitad con el disco testigo seguiría funcionando, mientras que los nodos de la
otra mitad, con un recuento de 3 votos, se retirarían.

Testigos de quórum
Cuando crea un clúster de conmutación por error, el Asistente para crear clústeres o el cmdlet New-Cluster
crea una configuración de quórum que, en la mayoría de los casos, es adecuada para el clúster, según la
cantidad de nodos y los recursos de almacenamiento disponibles. De forma predeterminada, cada nodo
obtiene un voto y, si hay un número par de nodos, el asistente o cmdlet intenta crear un testigo para que
funcione como un desempate. Como los nodos, el testigo obtiene un voto.

A testigo es un recurso que, por su existencia, vota por el funcionamiento continuado del clúster. La agrupación en
clústeres de conmutación por error en Windows Server 2016 admite tres tipos de testigos, como se indica a
continuación:

431
 Testigo de disco Un disco dedicado en el almacenamiento compartido del clúster que contiene una copia
de la base de datos del clúster. Esta es la opción típica para un clúster ubicado en un solo sitio.

Testigo de archivos compartidos Un recurso compartido de archivos SMB en un servidor Windows con un
archivo Witness.log que contiene información sobre el clúster. Esta es la opción típica para clústeres divididos
entre varios sitios con almacenamiento replicado.

Testigo de la nube Un blob almacenado en la nube mediante los servicios estándar de Microsoft Azure.
Esta es una nueva opción en Windows Server 2016, diseñada para clústeres extendidos divididos entre
múltiples centros de datos en sitios remotos, que desean mantener un testigo que sea independiente de
todos los centros de datos.

Gestión de quórum dinámica

La configuración de quórum predeterminada en Windows Server 2016 también incluye gestión dinámica de quórum,
que es una función diseñada para mantener un clúster en ejecución en situaciones en las queIAntes de que se detuviera
en versiones anteriores de la función de agrupación en clústeres de conmutación por error.

Cuando un nodo abandona el clúster, la administración dinámica de quórum elimina automáticamente

su voto, de modo que la funcionalidad del clúster se basa en el quórum de los votos restantes. Por ejemplo,
en un clúster de cinco nodos sin administración de quórum dinámica, si fallan tres nodos, el voto del
quórum cae a dos de cada cinco y los dos nodos restantes se eliminan, cerrando el clúster. En el mismo
clúster con administración de quórum dinámica, el voto de cada nodo que falla se elimina automáticamente
del recuento, lo que da como resultado un voto de quórum de dos de cada dos, por lo que el clúster
continúa funcionando. Por lo tanto, esta característica puede permitir que un clúster funcione, incluso
cuando todos los nodos menos uno hayan fallado.

Modificación de la configuración del quórum

Por lo general, la configuración de quórum creada por el Asistente para la creación de clústeres o el cmdlet New-
Cluster es adecuada para el clúster y no requiere ningún ajuste. Sin embargo, puede modificar la configuración del
quórum ejecutando el Asistente para configurar el quórum del clúster en el Administrador de clústeres de
conmutación por error o mediante el cmdlet Set-ClusterQuorum en Windows PowerShell. Con estas herramientas,
puede agregar o cambiar un testigo y especificar qué nodos deben tener votos en el quórum.

Para ejecutar el Asistente para configurar quórum de clúster, seleccione el clúster en el Administrador de clústeres de
conmutación por error y, en el panel Acciones, seleccione Más acciones | Configure las opciones del quórum del clúster.
En la página Seleccionar opción de configuración de quórum, que se muestra enFigura 5-15, tiene las siguientes
opciones.

432
FIGURA 5-15 La página Seleccionar opción de configuración de quórum en Configurar clúster
Asistente de quórum

Usar la configuración de quórum predeterminada Permite al asistente configurar una

configuración de quórum adecuada para el clúster sin entrada manual.

Seleccione el testigo del quórum Le permite agregar un testigo, si no existe ninguno,

eliminar un testigo existente y especificar el tipo y la ubicación del testigo que el quórum debe
usar, como se muestra en Figura 5-16.

433
FIGURA 5-16 La página Seleccionar testigo de quórum en el asistente Configurar quórum de clúster

Configuración de quórum avanzada Le permite especificar qué nodos deben tener votos en el
quórum, como se muestra en Figura 5-17. También configura la misma configuración de testigo que
la opción Seleccionar el testigo del quórum.

434
 FIGURA 5-17 La página Seleccionar configuración de votación en Configurar quórum de clúster
Mago
Para configurar la configuración del quórum con Windows PowerShell, use comandos
como el siguiente.
Para configurar el quórum para usar una mayoría de nodos, sin testigos:

Haga clic aquí para ver la imagen del código

set-clusterquorum -cluster cluster1 -nodemajority

Para configurar el quórum con votos de cada nodo y un testigo de disco:

Haga clic aquí para ver la imagen del código

set-clusterquorum -cluster cluster1 -nodeanddiskmajority "disco de clúster

1"

Para configurar un nodo de clúster para que no tenga un voto de quórum:

Haga clic aquí para ver la imagen del código

(get-clusternode clusternode1) .nodeweight = 0

435
 Nota Ejecución de cmdlets de agrupación en clústeres

Muchos de los cmdlets de PowerShell en el módulo FailoverClusters no funcionan

correctamente desde una ubicación remota. Siempre que sea posible, debe intentar
ejecutar los cmdlets en un nodo de clúster.

Configurar un testigo
En la mayoría de los casos, la agrupación en clústeres de conmutación por error crea un testigo cuando el
clúster tiene un número par de nodos. Solo puede haber un testigo en un grupo, y se recomienda que no
cree un testigo en una situación en la que resultaría en un número par de votos en el quórum.

Cuando todos los nodos de un clúster tienen acceso al mismo almacenamiento compartido, la configuración
recomendada es un testigo de disco. La página Configurar testigo de almacenamiento en el Asistente para
configurar quórum de clúster, que se muestra enFigura 5-18, le permite seleccionar el disco que debe funcionar
como testigo. El disco testigo solo debe contener una pequeña cantidad de datos, por lo que debe crear un
disco NTFS de 512 MB de tamaño mínimo para este propósito.

436
 FIGURA 5-18 La página Configurar testigo de almacenamiento en Configurar quórum de clúster
Mago
Las opciones para crear un testigo de uso compartido de archivos o un testigo en la nube son similares, lo que le
permite especificar la ubicación del testigo y, en el caso de un testigo en la nube, el nombre y la clave de su cuenta de
almacenamiento de Azure.

Modificar la votación del quórum

En la mayoría de los casos, todos los nodos del clúster deberían tener un voto. Es posible configurar un
clúster sin nodos de votación y solo con el voto de un testigo, y esto puede parecer al principio una opción
viable. Si hay un nodo disponible que tiene acceso al almacenamiento, el clúster puede ejecutarse. Sin
embargo, en esta configuración, el testigo se convierte en un único punto de falla. Si el testigo se vuelve
inaccesible, el clúster se cae, incluso si todos los nodos y el resto del almacenamiento funcionan.

Sin embargo, existen situaciones en las que es posible que desee revocar los votos de nodos específicos
del clúster. Por ejemplo, puede tener nodos de clúster en un sitio remoto que estén allí estrictamente como
respaldo, para la conmutación por error manual en caso de un desastre. Puede revocar sus votos para que
no formen parte de los cálculos de quórum.

437
 Nota Nodos sin derecho a voto

El hecho de que un nodo tenga un voto de quórum no influye en su funcionalidad en el clúster.

Los nodos que no participan en el quórum siguen estando completamente activos en el clúster.

Configurar redes de clúster

Las conexiones de red son fundamentales para mantener la alta disponibilidad de un clúster de
conmutación por error. Separar el tráfico en diferentes redes y proporcionar conexiones redundantes en
todos los puntos de la ruta de la red ayuda a garantizar la funcionalidad continua del clúster.

Según la función que desempeñe el clúster, es posible que desee crear redes independientes
para cada uno de los siguientes tipos de tráfico:
Comunicaciones con el cliente El acceso del cliente a la aplicación que se ejecuta en el clúster es la
máxima prioridad. Esta suele ser la red compartida predeterminada que se utiliza para otras
comunicaciones cliente / servidor, pero siempre que sea posible, los otros tipos de tráfico enumerados
aquí deben mantenerse fuera de esta red.

Comunicaciones de clúster Los latidos y otras comunicaciones entre los nodos del
clúster son esenciales para la funcionalidad continua del clúster.
iSCSI iSCSI y otras comunicaciones de red de área de almacenamiento deben estar separadas de
todos los demás tipos de tráfico de red.

Migración en vivo En un clúster de Hyper-V, Live Migration es fundamental para que las máquinas
virtuales sigan funcionando, y el rendimiento de la red es fundamental para que Live Migration funcione de
manera eficiente.

Seleccionar hardware de red

Para el hardware de red, el objetivo debe ser proporcionar la mayor redundancia posible y evitar
puntos únicos de falla. Algunas de las recomendaciones de aprovisionamiento de hardware son las
siguientes:
Utilice adaptadores de red independientes, en lugar de adaptadores con múltiples interfaces, para evitar
que la tarjeta adaptadora sea un único punto de falla.

Utilice adaptadores de red de diferentes marcas cuando sea posible, para evitar que los problemas con los controladores

afecten a varios adaptadores.

Utilice conmutadores físicos separados, en lugar de configurar VLAN en un único

conmutador grande, para evitar que el conmutador sea un único punto de falla.
Cree conexiones de red redundantes siempre que sea posible, especialmente para la red de
comunicación del cliente.
Para redes sin conexiones redundantes, como las de comunicación de clúster y migración en vivo,
utilice NIC Teaming para proporcionar capacidad de conmutación por error en caso de una

438
 mal funcionamiento del adaptador de red.

Modificar los valores predeterminados de la red

Cuando crea un clúster, el sistema evalúa cada una de las redes conectadas y les asigna
roles de tráfico, según los siguientes criterios:
Cualquier red que transporte tráfico iSCSI está deshabilitada para cualquier comunicación de clúster.

Las redes sin una dirección de puerta de enlace predeterminada se configuran solo para
comunicaciones de clúster.

Las redes con una dirección de puerta de enlace predeterminada están configuradas para la comunicación del
clúster y del cliente.

Los estados actuales de las redes detectadas se muestran en la página Redes de Failover
Cluster Manager, como se muestra en Figura 5-19o ejecutando el cmdlet Get-ClusterNetwork
en PowerShell.

FIGURA 5-19 La página Redes de Failover Cluster Manager

Es posible modificar la configuración de red predeterminada creada con el clúster, utilizando

Failover Cluster Manager o el cmdlet Get-ClusterNetwork PowerShell. Para configurar la red en
Failover Cluster Manager, utilice el siguiente procedimiento.
1. Abra el Administrador de clústeres de conmutación por error y vaya a la página Redes.

2. Seleccione una red y, en el panel Acciones, haga clic en Propiedades.

3. En la hoja Propiedades que se muestra en Figura 5-20, elija entre las siguientes opciones:
Permitir la comunicación de clúster en esta red Permite que la red se utilice solo para la
comunicación del clúster.
Permitir que los clientes se conecten a través de esta red Permite que la red se utilice para la
comunicación con el cliente, así como para la comunicación del clúster.

No permita la comunicación de clúster en esta red Evita que la red se utilice

para cualquier comunicación de clúster.

439
 FIGURA 5-20 La hoja de propiedades de una red

4. Haga clic en Aceptar.

440
 Para configurar estas opciones en Windows PowerShell, use el cmdlet Get-
ClusterNetwork, como en el siguiente ejemplo:
Haga clic aquí para ver la imagen del código

(get-clusternetwork "network1"). role = 1

Los valores de la propiedad Rol son los siguientes:

0 Deshabilitado para la comunicación del clúster 1 Habilitado

solo para la comunicación del clúster 3 Habilitado para la

comunicación del cliente y del clúster

Nota Cmdlets de clúster de conmutación por error

En muchos casos, los cmdlets del módulo FailoverClusters PowerShell son menos intuitivos
que los de otros módulos. Incluso los usuarios experimentados de PowerShell pueden
encontrar más conveniente utilizar Failover Cluster Manager en muchas tareas de
configuración de clústeres.

Restaurar la configuración de un solo nodo o clúster

Los clústeres de conmutación por error pueden proporcionar tolerancia a errores, pero no lo eximen de la necesidad de realizar una copia de

seguridad de sus servidores. Independientemente de la solución de almacenamiento compartido que utilice para un clúster de conmutación

por error, debe tener una estrategia de respaldo implementada, incluso si incluye espejos o redundancia de datos basada en paridad. Sin

embargo, el otro problema relacionado con las copias de seguridad es la configuración del clúster en sí.

Copia de seguridad de Windows Server tiene una capacidad limitada para realizar copias de seguridad de volúmenes compartidos de clúster

(CSV) como parte de la copia de seguridad del servidor, pero puede hacer una copia de seguridad de la base de datos del clúster, como se muestra

en Figura 5-21.

441
 FIGURA 5-21 La lista de elementos recuperables para un trabajo de copia de seguridad de Windows Server

La base de datos del clúster se almacena en cada nodo de un clúster, así como en un testigo de disco, si
existe. El servicio de clúster que se ejecuta en cada nodo es responsable de asegurarse de que la versión más
reciente de la base de datos del clúster se replique en cada nodo. Cuando realiza una restauración desde una
copia de seguridad en un nodo de clúster, debe considerar si desea realizar una restauración autorizada de la
base de datos del clúster.

Una de las situaciones de desastre más probables para un entorno de clúster de conmutación por error es la pérdida
de un solo nodo. Si un nodo falla y el resto del clúster se está ejecutando, probablemente pueda realizar una
restauración completa de ese nodo desde una copia de seguridad. La versión de la base de datos del clúster en la copia
de seguridad estará desactualizada y el Servicio de Cluster Server la sobrescribirá con la última versión tan pronto como
el nodo aparezca como parte del clúster. Esto se denomina copia de seguridad no autorizada.

La otra situación es cuando desea realizar una restauración autorizada del clúster.

442
base de datos, es decir, desea que el clúster use la versión de la base de datos de la copia de seguridad, no la
que está usando actualmente. Para hacer esto con Copia de seguridad de Windows Server, debe realizar la
restauración desde el símbolo del sistema utilizando el programa Wbadmin.exe. No puede usar la GUI para
esto.

Cuando ejecuta el siguiente comando Wbadmin, muestra las copias de seguridad que están
disponibles para restauración. El resultado se muestra enFigura 5-22.

wbadmin obtener versiones

FIGURA 5-22 Resultados del comando Wbadmin get versions

Con el identificador de versión especificado en la lista, ahora puede mostrar el contenido recuperable
en la copia de seguridad, incluida la base de datos del clúster, con un comando como el siguiente. El
resultado se muestra enFigura 5-23.

Haga clic aquí para ver la imagen del código

wbadmin obtener elementos -versión: 14/11/2016: 05: 09

FIGURA 5-23 Resultados del comando get items de Wbadmin

Para realizar la restauración autorizada, use un comando como el siguiente.

443
Haga clic aquí para ver la imagen del código

wbadmin start recovery -itemtype: app -items: cluster - versión: 01/01 /

2008-00: 00

Los resultados, mostrados en Figura 5-24, indique que la base de datos se ha restaurado
correctamente y proporcione instrucciones para reiniciar el clúster.

FIGURA 5-24 Resultados del comando Wbadmin start recovery

Puede iniciar el servicio de clúster en los otros nodos de forma remota, resaltándolos en el Administrador de
clústeres de conmutación por error y seleccionando Más acciones | Inicie Cluster Service en el panel Acciones.

Configurar el almacenamiento en clúster

Para que un clúster de conmutación por error aloje una aplicación de alta disponibilidad, todos los nodos del clúster deben
tener acceso a los datos de la aplicación. Por lo tanto, el clúster debe tener alguna forma de almacenamiento compartido. El
almacenamiento compartido es un requisito de la función de clústeres de conmutación por error en Windows Server 2016.
Antes de que pueda agregar almacenamiento al clúster, debe asegurarse de que todos los servidores que se convertirán en los
nodos del clúster tengan acceso al almacenamiento que contendrá los datos de la aplicación.

Windows Server 2016 admite varias tecnologías de almacenamiento compartido, incluidas las
siguientes:

Canal de fibra Uno de los primeros protocolos de red de área de almacenamiento (SAN), Fibre Channel,
es una red de fibra óptica dedicada que, en el momento de su introducción, funcionaba en

444
 altas velocidades, pero que requerían equipo especializado y experiencia, los cuales eran
extremadamente costosos. Ahora existe una variante de canal de fibra que se ejecuta a través de
Ethernet estándar (canal de fibra sobre Ethernet o FCoE), que es más asequible, pero sigue siendo
la esotérica gama alta de las tecnologías SAN.
SCSI conectado en serie (SAS) Small Computer System Interface (SCSI) es un protocolo de conexión
de almacenamiento basado en bus que, en su forma paralela, fue en un momento el estándar de la
industria para el almacenamiento local de alto rendimiento. La variante SAS utiliza comunicaciones en
serie para aumentar la longitud máxima del bus, mientras utiliza cables y conectores más pequeños
que los dispositivos paralelos originales.

Internet SCSI (iSCSI) Otra variante del protocolo SCSI que transmite el mismo lenguaje de comandos
SCSI a través de una red IP estándar. Al igual que con SAS, iSCSI designa los dispositivos de
almacenamiento como objetivos y los servidores y otros dispositivos que acceden al almacenamiento
como iniciadores. Un servidor que ejecuta Windows Server 2016 puede funcionar como un destino e
iniciador iSCSI, lo que hace posible implementar una SAN iSCSI completamente en software.

Cada una de estas tecnologías es menos costosa que las anteriores, y las SAN iSCSI ahora se pueden realizar
por poco más que el costo de una matriz de discos poco sofisticada. Si bien algunos dispositivos de
almacenamiento de alta gama incluyen diferentes niveles de inteligencia, tolerancia a fallas y alta disponibilidad,
también existen matrices de almacenamiento conocidas como JBOD (Just a Bunch of Disks), que son dispositivos
de bajo costo que son poco más que unidades de disco duro estándar. en un armario con una fuente de
alimentación común.

Sugerencia para el examen

Con Hyper-V e iSCSI, es posible implementar un clúster de conmutación por error en un

solo servidor físico, con fines educativos, de evaluación y de prueba. Es probable que el
nivel de rendimiento del clúster sea extremadamente limitado, pero una disposición
como esta le permitirá explorar la función de clústeres de conmutación por error de
Windows Server 2016.

Una vez que cree el clúster, todos los discos que califiquen deberían aparecer en el Administrador de clústeres de conmutación

por error cuando seleccione Agregar discos en la página Almacenamiento \ Discos, como se muestra en Figura 5-25. Una vez que

agrega un disco, se designa como Almacenamiento disponible.

445
 FIGURA 5-25 El cuadro de diálogo Agregar discos a un clúster en el Administrador de clústeres de conmutación por error

Alternativamente, puede usar el almacenamiento en los discos para crear un grupo de almacenamiento en clúster. El
proceso es como el de crear un grupo utilizando espacios de almacenamiento en un solo servidor de Windows, excepto
que el almacenamiento es compartido por todos los nodos del clúster.

Un grupo de almacenamiento en clúster requiere un mínimo de tres discos de al menos 4 GB de capacidad cada
uno, que deben estar conectados a todos los nodos del clúster mediante SAS o iSCSI. Para crear un grupo de
almacenamiento en clúster, utilice el siguiente procedimiento.

1. En el Administrador de clústeres de conmutación por error, vaya a la página Almacenamiento \ Grupos y haga clic en Nuevo

grupo de almacenamiento en el panel Acciones para iniciar el Asistente para nuevo grupo de almacenamiento.

2. En la página Especificar un nombre de grupo de almacenamiento y subsistema, escriba un nombre para el

grupo y seleccione el grupo primordial que contiene los discos que desea utilizar.

3. En la página Seleccionar discos físicos para el grupo de almacenamiento, seleccione los discos que desea
agregar al grupo y especifique si cada uno debe ser Automático, Repuesto en caliente o Manual, como se
muestra en Figura 5-26.

446
 FIGURA 5-26 La página Seleccionar discos físicos para el grupo de almacenamiento en el Nuevo almacenamiento

Asistente de piscina

4. Haga clic en Crear.

Implementar actualizaciones basadas en clústeres

Uno de los requisitos previos importantes para la agrupación en clústeres de conmutación por error en Windows Server 2016 es
que todos los nodos de clúster potenciales ejecuten la misma versión del sistema operativo, con todas las mismas
actualizaciones aplicadas. El Asistente para validar clústeres emite advertencias cuando determina que los servidores que está
comprobando no están actualizados de forma idéntica. Entonces, ¿qué debe hacer para mantener sus nodos actualizados una
vez que el clúster esté operativo?Actualización compatible con clústeres (CAU) es una herramienta suministrada con la
agrupación en clústeres de conmutación por error que puede actualizar los nodos del clúster de forma sistemática con un
tiempo de inactividad mínimo.

CAU aplica actualizaciones a un clúster de forma rotatoria, denominada ejecución de actualización, mediante el
siguiente procedimiento:

1. Selecciona un nodo para actualizar.

2. Mueve los roles existentes del nodo seleccionado a otros nodos del clúster, utilizando Live
Migration u otras técnicas que minimizan las interrupciones del servicio del cliente.
3. Coloca el nodo seleccionado en modo de mantenimiento de nodo.

4. Instala las actualizaciones necesarias en el nodo seleccionado y lo reinicia, si es necesario.

447
 5. Saca el nodo seleccionado del modo de mantenimiento.

6. Pasa al siguiente nodo del clúster y repite el procedimiento.

De esta forma, cada nodo, a su vez, se pone fuera de servicio temporalmente y se actualiza, hasta que se hayan
aplicado las mismas actualizaciones a todo el clúster.

CAU requiere una computadora para funcionar como el Coordinador de Actualización, dirigiendo las
actividades de actualización para el clúster. La cuestión de qué computadora realiza esta función es la distinción
principal entre los dos modos de funcionamiento de la CAU:

Modo de actualización automática En este modo, uno de los nodos del clúster tiene instalada la función
de clúster de CAU, lo que le permite funcionar como Coordinador de actualizaciones. El nodo Coordinador
de actualizaciones realiza Ejecuciones de actualización de acuerdo con un programa configurado por un
administrador, activando actualizaciones en cada uno de los otros nodos a su vez. Cuando todos los demás
nodos se han actualizado, el rol de CAU en el Coordinador de actualizaciones conmuta a otro nodo, lo que
le permite asumir el rol de Coordinador de actualizaciones. El coordinador original puede actualizarse él
mismo. En este modo, todo el proceso de actualización se realiza automáticamente.

Modo de actualización remota En este modo, una computadora fuera del clúster está configurada para
funcionar como Coordinador de actualizaciones. Desde esta computadora, un administrador puede activar
manualmente una ejecución de actualización en el clúster. La computadora del Coordinador de actualizaciones
no se actualiza por sí misma y el proceso no se puede automatizar.

Para utilizar CAU en modo de actualización automática, cada nodo del clúster debe tener instaladas las herramientas
de clústeres de conmutación por error. Las herramientas se instalan de forma predeterminada cuando agrega la función
de agrupación en clústeres de conmutación por error mediante el Administrador del servidor. Sin embargo, si instala la
función mediante PowerShell, debe agregar el parámetro IncludeManagementTools al comando Install-WindowsFeature.

Para el modo de actualización remota, el Coordinador de actualizaciones debe tener instaladas las herramientas de agrupación en

clústeres de conmutación por error, pero la función de agrupación en clústeres de conmutación por error no es necesaria. Las

herramientas en sí se encuentran en Herramientas de administración de servidor remoto en el Asistente para agregar funciones y

características. Se conocen como agrupación en clústeres RSAT en Windows PowerShell.

Las herramientas de CAU incluyen una consola de actualización compatible con clústeres, como se muestra en
Figura 5-27y un módulo ClusterAwareUpdating para Windows PowerShell, que contiene cmdlets para administrar
el servicio.

448
 FIGURA 5-27 La consola de actualización compatible con clústeres

Existen otros requisitos previos para usar CAU, la mayoría de los cuales ya se cumplen en un clúster de
conmutación por error de Windows Server 2016 correctamente instalado. Al hacer clic en Analizar preparación
de actualización de clúster en la lista Acciones de clúster de la consola o ejecutar el cmdlet Test-CauSetup en
PowerShell en un nodo de clúster, se realiza una serie de pruebas que evalúan la preparación de todo el
clúster, como se muestra enFigura 5-28.

449
 FIGURA 5-28 Clúster Actualización de resultados de preparación

Para usar el modo de autoactualización, una vez que el clúster cumpla con todos los requisitos previos, instale
el rol agrupado de CAU haciendo clic en Configurar opciones de autoactualización del clúster en la consola. Esto
inicia el Asistente para configurar opciones de actualización automática, que agrega la función en clúster y crea
una programación para las actualizaciones automáticas, como se muestra enFigura 5-29. También puede
configurar opciones de actualización avanzadas, como el número máximo de reintentos permitidos por nodo y el
orden en el que se deben actualizar los nodos. También puede hacer estas cosas con el cmdlet Add-CauClusterRole
en PowerShell, como en el siguiente ejemplo:

Haga clic aquí para ver la imagen del código

add-cauclusterrole -clustername "cluster1" -daysofweek sunday - weeksinterval 3

- maxretriespernode -nodeorder nodo2, nodo1, nodo3

450
 FIGURA 5-29 La página Especificar actualización automática de Configurar opciones de actualización automática

Mago
Una vez establecida la programación, puede esperar a que se ejecute o realizar una ejecución de actualización
inmediatamente, como se muestra en Figura 5-30, haciendo clic en Aplicar actualizaciones a este clúster o ejecutando el
cmdlet Invoke-CauRun.

451
 FIGURA 5-30 La consola de actualización compatible con clústeres con una ejecución de actualización en curso

Implementar la actualización progresiva del sistema operativo del clúster

Antes de Windows Server 2016, la actualización del sistema operativo en un clúster de conmutación por
error requería que desconectara todo el clúster, instalara el nuevo sistema operativo en todos los nodos
y, básicamente, reconstruyera el clúster desde cero. Windows Server 2016 ahora admite una técnica
llamadaActualización progresiva del sistema operativo del clúster que hace posible actualizar un clúster
de servidor de archivos de escalabilidad horizontal o Hyper-V de Windows Server 2012 R2 a Windows
Server 2016 sin tener que desactivar el clúster.

La actualización progresiva del sistema operativo del clúster no es una herramienta ni un asistente; no existe un
proceso automatizado para actualizar el clúster. Es más bien una técnica en la que se baja cada nodo del clúster, se
realiza una actualización limpia del sistema operativo y se vuelve a agregar al clúster. La característica que hace
que esto sea posible es un nuevo modo operativo para la agrupación en clústeres de conmutación por error
llamadomodo de sistema operativo mixto. A diferencia de los clústeres en versiones anteriores de Windows, es
posible que un clúster funcione, temporalmente, con nodos que ejecutan diferentes versiones del sistema
operativo, específicamente Windows Server 2012 R2 y Windows Server 2016.

El proceso para actualizar cada nodo de Windows Server 2012 R2 en el clúster es el

siguiente:

452
 1. Pausa el nodo.
2. Drene el nodo de su carga de trabajo migrándolo a otros nodos.
3. Desalojar el nodo del clúster.
4. Vuelva a formatear la unidad del sistema y realice una instalación limpia de Windows Server
2016.

5. Configure las conexiones de red y almacenamiento.

6. Instale la función de agrupación en clústeres de conmutación por error.

7. Vuelva a agregar el nodo recién instalado al clúster.

8. Vuelva a implementar la carga de trabajo del clúster.

Cuando un nodo de Windows Server 2016 recién instalado se vuelve a agregar al clúster, se ejecuta en un
modo de compatibilidad que le permite cooperar con los nodos restantes de Windows Server 2012 R2. El
clúster continúa funcionando en el nivel funcional de Windows Server 2012 R2 hasta que se hayan
actualizado todos los modos. Las nuevas características de agrupación en clústeres de conmutación por
error en Windows Server 2016 no están disponibles. Todo durante este período, que puede tardar días o
semanas, si es necesario, todo el proceso es reversible. Puede reinstalar Windows Server 2012 R2 en sus
nodos y devolver el clúster a su estado original, si es necesario.

Nota Completando las actualizaciones

Microsoft recomienda que todos los nodos de un clúster se actualicen en un mes. El modo de
sistema operativo mixto no pretende ser una solución permanente para un clúster de
conmutación por error.

Cuando se hayan completado las actualizaciones en todos los nodos, finalice el proceso
ejecutando el cmdlet Update-ClusterFunctionalLevel. Este es el "punto sin retorno", cuando el
nivel funcional se eleva permanentemente a Windows Server 2016. En este punto, las nuevas
funciones están disponibles y no hay vuelta atrás a la versión anterior.

Configurar y optimizar volúmenes compartidos en clúster (CSV)

Cuando considera el requisito previo de almacenamiento compartido para la agrupación en clústeres de conmutación
por error, está hablando de compartir a nivel de hardware. Todos los nodos del clúster pueden ver los discos
compartidos, pero usarlos es otro problema. Puede agregar discos a un clúster en el Administrador de clústeres de
conmutación por error o mediante el cmdlet Add-ClusterDisk, y aparecen como Almacenamiento disponible, como
Cluster Disk 4 y Cluster Disk 5, que se muestran enFigura 5-31.

453
 FIGURA 5-31 Almacenamiento disponible en el administrador de clústeres de conmutación por error

Estos dos discos tienen un nodo (SVR-11) listado como su propietario designado. Si va a ese nodo y abre el
complemento Administración de discos, esos discos aparecen con letras de unidad y nombres de volumen,
en buen estado y listos para usar, como se muestra enFigura 5-32.

FIGURA 5-32 El complemento Administración de discos con dos discos iSCSI montados

Si va a otro nodo y abre el mismo complemento, esos mismos dos discos no tienen letras de unidad y tienen un
estado de Reservado, como se muestra en Figura 5-3. Si intenta ponerlos en línea, no podrá. Si se supone que esto
es almacenamiento compartido, ¿por qué no se puede acceder a estos discos en ambos nodos?

454
 FIGURA 5-33 El complemento Administración de discos con dos discos iSCSI reservados

El problema no es iSCSI o cualquier protocolo de almacenamiento compartido que utilice en su SAN;

es el sistema de archivos. NTFS no está diseñado para que más de una instancia de sistema operativo
pueda acceder a él y utilizarlo a la vez. Esas dos unidades están montadas en el nodo propietario y se
pueden utilizar allí. Para usarlos en un nodo diferente, debe desmontarlos del nodo actual y volver a
montarlos en el nuevo. Esto es posible; pero lleva tiempo.
En la versión original de Hyper-V en Windows Server 2008, este retraso en el desmontaje y montaje era
el mayor obstáculo para el uso eficiente de las máquinas virtuales en un clúster. Además, dado que solo un
nodo puede acceder a un disco a la vez, si desea migrar una máquina virtual a otro servidor, debe migrar
todas las demás máquinas virtuales utilizando ese mismo disco también.

La solución a este problema son los volúmenes compartidos en clúster (CSV). Los volúmenes compartidos en
clúster crean lo que es esencialmente un pseudo sistema de archivos (llamado CSVFS) que se superpone al sistema
de archivos NTFS. El problema con varios nodos que acceden a una unidad NTFS simultáneamente es el acceso a
los metadatos que controlan la estructura del disco y los archivos almacenados en él. Cuando dos sistemas
intentan modificar esos metadatos al mismo tiempo, se producen daños y se pierden los datos. CSVFS es
esencialmente un filtro que permite que varios nodos realicen operaciones de E / S de datos en el disco, pero
restringe el acceso a los metadatos al propietario designado (también conocido como coordinador).

Puede ver esto observando los archivos CSV en el complemento Administración de discos, como lo hizo
anteriormente con los discos de almacenamiento disponibles. En su nodo propietario, que se muestra enFigura 5-34, el
disco iscsi3 aparece usando el sistema de archivos CSVFS, y el menú contextual muestra los controles habituales para
formatear, reducir y eliminar el volumen.

455
 FIGURA 5-34 El complemento Administración de discos, con acceso de propietario a un disco CSVFS

En otro nodo, no el propietario, que se muestra en Figura 5-35, el mismo disco iscsi3 parece
igualmente accesible, con el mismo sistema de archivos CSVFS, pero el menú contextual está
completamente atenuado. Esto se debe a que esos comandos para formatear, reducir y eliminar el
volumen son competencia de los metadatos, y solo el propietario tiene acceso a ellos.

456
 FIGURA 5-35 El complemento Administración de discos, con acceso de no propietario a un disco CSVFS

Agregar discos a CSV

La agrupación en clústeres de conmutación por error en Windows Server 2016 incluye compatibilidad con CSV de forma predeterminada.

Cuando agrega un disco a un clúster, aparece en el Administrador de clústeres de conmutación por error como Almacenamiento disponible.

A continuación, puede seleccionar un disco de almacenamiento disponible y, en el panel Acciones, hacer clic en Agregar a volúmenes

compartidos de clúster.

Para agregar almacenamiento disponible a un CSV con PowerShell, use el cmdlet Add-
ClusterSharedVolume, como en el siguiente ejemplo:

Haga clic aquí para ver la imagen del código

add-clustersharedvolume -name "disco de clúster 5"

Una vez que hace esto, el CSV se monta en la carpeta C: \ ClusterStorage en todos los nodos del clúster.
También puede ver en el complemento Administración de discos que el disco ahora está disponible en todos los
nodos del clúster. También puede seleccionar el CSV en el Administrador de clústeres de conmutación por error y
hacer clic en Mover |, Mejor nodo posible. Observe cómo la propiedad del CSV cambia de manos en cuestión de
segundos. Esto es lo que hace posible que las migraciones en vivo de Hyper-V se realicen con tanta rapidez. Antes
de los CSV, el desmontaje y el montaje de los discos NTFS era el cuello de botella del proceso.

Optimización de CSV

457
Los CSV incluyen una caché diseñada para mejorar el rendimiento de las operaciones de E / S de lectura intensiva.
La caché usa una cantidad de memoria del sistema que usted especifica como caché de escritura directa, lo que
puede beneficiar a los clústeres que ejecutan las funciones Hyper-V y Scale-Out File Server.

En la agrupación en clústeres de conmutación por error de Windows Server 2016, la caché existe de forma predeterminada,
pero el tamaño de caché predeterminado es 0, lo que la desactiva de manera efectiva. El tamaño máximo de la caché es el 80%
de la memoria del sistema. Para habilitar la caché CSV, debe especificar una cantidad de memoria para ella, en megabytes,
usando el siguiente comando de PowerShell:

Haga clic aquí para ver la imagen del código

(obtener-clúster) .blockcachesize = 512

Comprobación rápida

¿Cuál de los siguientes componentes de almacenamiento evita que dos nodos de clúster
accedan a un disco compartido simultáneamente?

1. iSCSI
2. NTFS
3. CSVFS
4. SAS
Respuesta de verificación rápida

NTFS no está diseñado para el acceso de dos instancias del sistema operativo al mismo
tiempo. Si dos sistemas modifican los metadatos NTFS, las tablas del sistema de archivos
pueden dañarse y perderse datos.

Configurar clústeres sin nombres de red

Los clústeres de conmutación por error dependen de los servicios de dominio de Active Directory para los servicios de
autenticación y nombres. De forma predeterminada, la creación de un clúster hace que AD DS cree un objeto de
computadora, llamado objeto de nombre de clúster (CNO), para representar el clúster en sí. Este es el clústerpunto de
acceso administrativo. Algunas aplicaciones agrupadas también crean objetos AD DS que representan puntos de acceso
de clientes, denominados objetos de computadora virtual (VCO).

Sin embargo, es posible crear un clúster que no utilice estos objetos de AD DS, aunque los
nodos del clúster estén unidos a un dominio. Esto se llamaClúster independiente de Active
Directory. Debido a que no hay objetos creados en Active Directory, no es necesario que la
persona que crea el clúster tenga los permisos necesarios para crear objetos o tener los objetos
del equipo preconfigurados en AD DS.
En un clúster separado de Active Directory, el nombre del clúster y los nombres utilizados para los
puntos de acceso del cliente se registran en el DNS en lugar de en Active Directory. Sin embargo, los
nodos aún deben unirse a un dominio de AD DS y el clúster aún usa Kerberos para

458
autenticar las comunicaciones del clúster entre los nodos. La autenticación para el nombre del clúster utiliza
NTLM.
Debido a estos cambios, algunas aplicaciones no funcionarán correctamente cuando las implemente en un
clúster separado de Active Directory. Hyper-V, por ejemplo, se basa en la autenticación Kerberosnorte
icación para la migración en vivo, por lo que no es un candidato adecuado para este tipo de clúster.
Tampoco puede usar el cifrado de unidad BitLocker o la Actualización compatible con clústeres en el modo de
actualización automática. Sin embargo, Microsoft SQL Server tiene su propio mecanismo de autenticación
interno, que le permite funcionar correctamente en un clúster separado de Active Directory.

Para crear un clúster separado de Active Directory, debe usar el cmdlet New-Cluster
PowerShell e incluir el parámetro AdministrativeAccessPoint, especificando un valor de DNS en
lugar del valor predeterminado de ActiveDirectoryAndDns, como en el siguiente ejemplo:

Haga clic aquí para ver la imagen del código

ew-cluster cluster1 –node node1, node2 –staticaddress 10.0.0.1

- Sin almacenamiento -
dns punto de acceso administrativo

Esta configuración de parámetro hace que el cmdlet cree el nombre de red del clúster y los nombres de
red en todos los roles en clúster que instale más adelante, en DNS en lugar de en Active Directory.

Nota Clústeres sin nombre

También es posible crear un clúster sin ningún punto de acceso administrativo, especificando
un valor de None para el parámetro AdministrativeAccessPoint en el comando New-Cluster.
Sin embargo, si hace esto, no podrá utilizar el Administrador de clústeres de conmutación por
error para administrar el clúster y la funcionalidad de algunos roles de clúster podría verse
afectada.

Implementar el servidor de archivos de escalabilidad horizontal (SoFS)

Servidor de archivos escalable es un rol agrupado que está diseñado para proporcionar almacenamiento de alta
disponibilidad para aplicaciones, como Hyper-V y SQL Server. A diferencia de un servidor de archivos diseñado para uso
general, un SoFS crea recursos compartidos que son accesibles en todos los nodos del clúster al mismo tiempo. Esto se
conoce como un sistema activo / activo (o activo dual), a diferencia de un sistema activo / pasivo, en el que un nodo
proporciona recursos compartidos accesibles y los otros permanecen inactivos hasta que se produce una conmutación
por error.

Un SoFS garantiza la disponibilidad continua de datos para las aplicaciones que requieren esa continuidad.
Cuando un nodo deja de funcionar, debido a una falla de hardware, un ciclo de mantenimiento o cualquier otra
razón, los datos permanecen disponibles a través de los recursos compartidos en los otros nodos. Incluso si un
nodo pierde el acceso a la SAN, CSV puede redirigir el tráfico de E / S a través de la red a otro nodo.

459
 Nota Métricas de la red del clúster

Un clúster asigna valores métricos a las redes disponibles, en función de sus velocidades y
otras características, como se muestra en el comando Get-ClusterNetwork en Figura 5-36. CSV
utiliza la red con el valor de métrica más bajo para su tráfico de redireccionamiento. En
algunas situaciones, puede ser necesario ajustar las métricas para garantizar que el tráfico de
redireccionamiento CSV para un SoFS utilice una red específica. Para modificar las métricas de
la red manualmente, use un comando como el siguiente:

Haga clic aquí para ver la imagen del código

(get-clusternetwork -name "red de clúster 3"). metric = 30000

FIGURA 5-36 Resultados del comando Get-ClusterNetwork

SoFS también aumenta la eficiencia del clúster al utilizar el ancho de banda combinado de todos los nodos
para la E / S del sistema de archivos. Para aumentar el ancho de banda disponible, los administradores pueden
agregar más nodos al clúster. Finalmente, SoFS reequilibra automáticamente las conexiones, para asegurar que
cada cliente sea dirigido al nodo con el mejor acceso a los datos solicitados.

Los requisitos previos para crear un servidor de archivos escalable son esencialmente los mismos que los de la
agrupación en clústeres de conmutación por error. La configuración de hardware de los nodos del clúster debe ser lo
más idéntica posible, y todos los nodos deben tener acceso al almacenamiento compartido mediante iSCSI, SAS, Fibre
Channel o una tecnología similar. Como SoFS es una función en clúster, debe instalar la función de agrupación en
clústeres de conmutación por error en todos sus nodos y crear el clúster antes de poder instalar SoFS. También debe
asignar su almacenamiento disponible como volúmenes compartidos en clúster, ya que son necesarios para un servidor
de archivos escalable.

Una vez que el clúster esté en su lugar y operativo, instale SoFS mediante el siguiente
procedimiento.
1. Abra el Administrador de clústeres de conmutación por error y seleccione la página Roles.

2. Haga clic en Configurar rol para iniciar el Asistente de alta disponibilidad.

3. En la página Tipo de servidor de archivos, seleccione el servidor de archivos de escalabilidad horizontal para datos de aplicación

460
opción, como se muestra en Figura 5-37.

461
 FIGURA 5-37 La página Tipo de servidor de archivos en el Asistente de alta disponibilidad

4. En la página Client Access Point, especifique un nombre que los clientes usarán para acceder
al rol. El asistente creará un objeto de equipo con AD DS con este nombre.
5. Haga clic en Finalizar. El servidor de archivos escalable aparece en la página Roles.

Nota Usando PowerShell

Para instalar la función de servidor de archivos escalable con Windows PowerShell,
ejecute el cmdlet Add-ClusterScaleOutFileServer sin parámetros.

Con la función de servidor de archivos de escalabilidad horizontal instalada, puede continuar con la creación de un recurso compartido de

archivos mediante el siguiente procedimiento.

1. En el Administrador de clústeres de conmutación por error, en la página Roles, seleccione el rol de servidor de archivos escalable que

acaba de crear y, en el panel Acciones, seleccione Agregar recurso compartido de archivos para iniciar el Asistente para recurso

compartido nuevo.

2. En la página Seleccionar el perfil para este recurso compartido, seleccione Compartir SMB - Aplicaciones

3. Tenga en cuenta que, a pesar de la similitud de este asistente con el Asistente para recursos compartidos nuevos en el Administrador del

servidor, debe usar el Administrador de clústeres de conmutación por error o el cmdlet New-SmbShare para

462
 crear recursos compartidos de archivos SoFS.

4. En la página Seleccionar el servidor y la ruta para este recurso compartido, seleccione la función de servidor de
archivos escalable que creó, como se muestra en Figura 5-38.

463
 FIGURA 5-38 La página Seleccionar el servidor y la ruta para este recurso compartido del nuevo recurso compartido

Mago
5. En el cuadro Compartir ubicación, seleccione un volumen compartido de clúster.

6. En la página Especificar nombre del recurso compartido, escriba un nombre y, opcionalmente, una descripción del recurso

compartido.

7. En la página Configure Share Settings, asegúrese de que la casilla de verificación Habilitar disponibilidad
continua esté seleccionada y que la casilla de verificación Habilitar enumeración basada en acceso esté
desactivada.

8. En la página Especificar permisos para controlar el acceso, haga clic en Personalizar permisos y
asegúrese de que los objetos de equipo de AD DS para el clúster y los nodos que usan el recurso
compartido SoFS tengan el permiso de Control total.

9. Haga clic en Crear.

Para crear un recurso compartido de SoFS con PowerShell, use el cmdlet New-SmbShare para crear el recurso
compartido, como en el siguiente ejemplo. El cmdlet Set-SmbPathAcl configura los permisos del sistema de archivos de
la carpeta para que coincidan con los del recurso compartido.

Haga clic aquí para ver la imagen del código

464
 new-smbshare -name share1 -path c: \ clusterstorsge \ volume1 - fullaccess
adatum \ cluster1,
adatum \ nodo1, adatum \ nodo2
- set-smbpathacl continuamente disponible –sharename share1

Determinar diferentes escenarios para el uso de SoFS frente al servidor de archivos en clúster

La página Tipo de servidor de archivos del Asistente de alta disponibilidad permite elegir entre la función de
clúster de servidor de archivos estándar, diseñada para uso general, y la función de servidor de archivos
escalable, que está diseñada para ser utilizada por aplicaciones en clúster. En algunos casos, puede que no
quede claro cuál es la mejor opción para una carga de trabajo en particular.

Los recursos compartidos de SoFS se encuentran en volúmenes compartidos de clúster y la naturaleza subyacente de los
CSV determina en gran medida qué roles y aplicaciones se adaptan mejor a un servidor de archivos escalable. SoFS hace que
sus recursos compartidos estén disponibles en todos los nodos del clúster, lo que significa que cualquier nodo puede procesar
solicitudes de lectura y escritura de disco. Sin embargo, el sistema de archivos CSVFS subyacente aún requiere que el
coordinador del disco (es decir, el nodo propietario del disco) realice todas las actividades relacionadas con los metadatos.
Esto significa que todas las solicitudes para abrir, cerrar, crear y cambiar el nombre de archivos en un recurso compartido
SoFS, sin importar qué nodo los reciba, deben redirigirse al nodo coordinador.

Esto hace que sea más fácil comprender por qué la función SoFS se recomienda específicamente para su uso
en clústeres de Hyper-V y SQL Server. Ambas aplicaciones abren de forma rutinaria archivos grandes (VHD y
bases de datos) y los dejan abiertos durante largos períodos de tiempo. Las solicitudes de metadatos son poco
frecuentes en este tipo de aplicación, por lo que se minimiza la carga sobre el nodo coordinador del disco.

Sin embargo, para muchas otras aplicaciones, incluidas las actividades generales del servidor de archivos que
realizan los usuarios y administradores habituales, la carga del nodo coordinador del disco puede convertirse en un
cuello de botella. Esto se debe a que hay muchas más solicitudes que requieren acceso a los metadatos del sistema de
archivos, incluidas las actividades comunes del administrador del servidor de archivos, como la modificación de
permisos NTFS y otros atributos del sistema de archivos.

La disponibilidad continua de recursos compartidos de SoFS también puede afectar el rendimiento general de un servidor
de archivos. Para garantizar la integridad de los datos, las solicitudes de escritura se envían directamente al disco, en lugar de
almacenarse en caché en el nodo. De esta forma, si un nodo falla, hay menos posibilidades de que se pierdan datos debido a
una falla en la caché.

Como resultado, debe considerar la naturaleza de la carga de trabajo de su clúster antes de decidir qué opción
seleccionar en la página Tipo de servidor de archivos. Cuanto mayor sea la proporción de solicitudes de administración
de archivos que genera la aplicación, es menos probable que sea un candidato adecuado para un servidor de archivos
escalable.

Determine los escenarios de uso para implementar la agrupación en clústeres de invitados

Un clúster de conmutación por error invitado es un clúster que consta únicamente de máquinas virtuales que se ejecutan en un único

servidor host de Hyper-V. Puede crear dos o más máquinas virtuales idénticas, instale la conmutación por error

465
La función de agrupación en clústeres en todos ellos y crea un clúster a partir de ellos, como si fueran
computadoras físicas. De hecho, es menos probable que tenga problemas de validación de clúster con un
clúster invitado, porque la configuración de hardware (virtual) de cada nodo es idéntica. Para el
almacenamiento compartido que necesita un clúster invitado, puede utilizar cualquiera de las tecnologías de
red de área de almacenamiento estándar, incluido Fibre Channel, SAS o iSCSI, como discos de paso.

La creación de un clúster de invitados es una excelente manera de aprender sobre la agrupación en clústeres de
conmutación por error y una herramienta útil para evaluar aplicaciones en clúster, sin tener que invertir en una gran
cantidad de hardware. Con fines educativos y de prueba, puede crear un clúster invitado con una SAN virtualizada
utilizando la capacidad de destino iSCSI en Windows Server 2016 para montar un disco duro virtual, al que sus
máquinas virtuales pueden acceder mediante el iniciador iSCSI. Los niveles de rendimiento probablemente no serán
adecuados para aplicaciones de producción, pero el clúster funcionará.

Además, con las capacidades de virtualización anidadas integradas en Windows Server 2016, incluso
puede crear un clúster invitado instalando Hyper-V en una sola máquina virtual y agrupando máquinas
virtuales anidadas.

Los clústeres de invitados también tienen funciones prácticas, que incluyen las siguientes:

Monitoreo de nodo Los clústeres pueden monitorear recursos, como el subsistema de

almacenamiento, la conectividad de red y la propia aplicación en clúster, y tomar medidas
automáticamente cuando ocurre un problema, migrando o conmutando el rol a otro nodo.

Migración de aplicaciones Al implementar una aplicación como un rol en un clúster invitado, puede
mantener la disponibilidad migrando la aplicación a diferentes nodos en el clúster. Por ejemplo, en
lugar de implementar una aplicación en un solo servidor de red, puede configurar el servidor como un
host Hyper-V y crear un clúster que ejecute la aplicación. De esa forma, si una máquina virtual falla o
requiere mantenimiento, la aplicación puede conmutar por error a otro nodo.

Disponibilidad del anfitrión Puede crear un clúster invitado a partir de máquinas virtuales
ubicadas en diferentes hosts de Hyper-V. Si un host experimenta una falla, los nodos que se
ejecutan en otros hosts detectarán la ausencia de sus VM y pondrán en línea las aplicaciones
agrupadas que se estaban ejecutando allí.

Migración de VM Si tiene varios hosts Hyper-V disponibles, puede migrar máquinas virtuales
entre hosts según sea necesario, para realizar tareas de mantenimiento que requieren que
desconecte un host temporalmente.

Clustering anidado Es posible crear un "clúster invitado dentro de un clúster", uniendo dos o más
servidores físicos en un clúster de Hyper-V y luego agrupando máquinas virtuales en clúster de
invitado que se ejecutan en los nodos de host de Hyper-V. Esto permitirá que el sistema reaccione
automáticamente ante la falla de un host Hyper-V, al migrar sus máquinas virtuales a los otros hosts; o
la falla de una máquina virtual, al migrar sus aplicaciones agrupadas.

Implemente una solución de espacios de almacenamiento en clúster utilizando gabinetes de almacenamiento SAS

compartidos

466
Espacios de almacenamiento es la herramienta de Windows Server 2016 que le permite agregar el almacenamiento de datos
proporcionado por varios discos físicos a un grupo de almacenamiento. Luego, puede usar el almacenamiento en el grupo para
crear discos virtuales de cualquier tamaño, independientemente de los límites entre los discos físicos. Al combinar los espacios
de almacenamiento con la agrupación en clústeres de conmutación por error, puede crear una solución de alta disponibilidad y
resistencia a las fallas del disco duro y del servidor. Esta solución se conoce comúnmente como espacios de almacenamiento en
clúster.

Una solución de espacios de almacenamiento en clúster comienza con uno o más arreglos de discos
SCSI conectados en serie (SAS), gabinetes simples de solo un grupo de discos (JBOD) que no brindan
funciones adicionales, como el arreglo redundante de discos independientes (RAID ). En una
implementación de Espacios de almacenamiento, el software proporciona tolerancia a fallas de datos; no
desea duplicar esas funciones en el hardware. Si las matrices de discos incluyen esas funciones, debe
deshabilitarlas para poder utilizar los discos con espacios de almacenamiento.

Storage Spaces proporciona resistencia de datos en forma de duplicación de datos, en la que se escriben dos
o tres copias de todos los archivos en diferentes discos; o paridad, una técnica a nivel de bits que brinda la
capacidad de recuperarse de una falla en el disco reconstruyendo los datos perdidos usando bits de paridad.

El segundo elemento de la solución es el clúster de conmutación por error, generalmente un grupo de dos a cuatro
servidores que están conectados a los receptáculos de discos mediante hardware redundante. Para crear una solución
verdaderamente confiable para la productividad empresarial, debe haber redundancia de hardware en todos los niveles,
incluidos varios adaptadores de bus de host en cada servidor, fuentes de alimentación redundantes en los receptáculos
de disco e incluso receptáculos de disco redundantes.

Con el hardware en su lugar, el resto de la solución consiste en un grupo de almacenamiento que proporciona
almacenamiento de datos redundante, el clúster de conmutación por error que proporciona servidores redundantes,
volúmenes compartidos de clúster, que proporcionan un espacio de nombres unificado en todo el clúster y recursos
compartidos de archivos de alta disponibilidad, que es cómo los usuarios acceden a los datos. La solución completa se
muestra enFigura 5-39.

467
 FIGURA 5-39 Diagrama de la instalación de un volumen compartido de clúster

Una vez que los componentes de hardware estén en su lugar y haya instalado Windows Server 2016 en todos
los servidores, debe confirmar que el almacenamiento sea accesible desde todos los servidores. Luego, puede
proceder a crear una solución de Espacios de almacenamiento en clúster de dos maneras:

Grupo de almacenamiento primero Si tiene un grupo de almacenamiento existente o si está creando

un clúster desde cero, puede crear el grupo de almacenamiento mediante el Administrador del
servidor o el cmdlet New-StoragePool antes de crear el clúster. Una vez que haya creado el clúster, el
grupo de almacenamiento estará disponible para él.

Clúster de conmutación por error primero Si tiene un clúster existente, puede crear el grupo de
almacenamiento en Failover Cluster Manager.

Para crear espacios de almacenamiento en clúster en un clúster existente con Failover Cluster Manager, utilice
el siguiente procedimiento.

1. En el Administrador de clústeres de conmutación por error, seleccione Almacenamiento | Pools, para mostrar la página Pools.

2. Haga clic en Agregar grupo de almacenamiento para iniciar el Asistente para grupo de almacenamiento nuevo.

468
 3. En la página Especificar un nombre de grupo de almacenamiento y subsistema, especifique un nombre
para el grupo y seleccione el grupo primordial que contiene los discos que desea agregar.

4. En la página Seleccionar discos físicos para el grupo de almacenamiento, seleccione las casillas de verificación de
los discos que desea agregar al grupo. Para crear un grupo de almacenamiento en clúster, debe seleccionar un
mínimo de tres discos; para la duplicación de tres vías, debe seleccionar un mínimo de cinco discos.

5. Haga clic en Crear.

6. En la página Ver resultados, seleccione la casilla de verificación Crear un disco virtual cuando este
asistente se cierre y haga clic en Cerrar. Aparece el Asistente para nuevo disco virtual.

7. En la página Seleccionar el grupo de almacenamiento, seleccione el grupo que acaba de crear.

8. En la página Especificar el nombre del disco virtual, escriba un nombre para el disco.

9. En la página Select the Storage Layout, seleccione Simple, Mirror o Parity. Si selecciona
Duplicar y hay cinco discos en el grupo, aparece la página Configure The Resiliency
Settings, que le solicita que elija Two-Way Mirror o Three-Way Mirror.
10. En la página Especificar el tamaño del disco virtual, escriba un tamaño en MB, GB o TB, o seleccione
la casilla de verificación Tamaño máximo.

11. Haga clic en Crear.

12. En la página Ver resultados, seleccione la casilla de verificación Crear un volumen cuando este asistente se
cierre y haga clic en Cerrar. Aparece el Asistente para nuevo volumen.

13. En la página Seleccionar el servidor y el disco, seleccione su clúster y el disco virtual que acaba de
crear.

14. En la página Especificar el tamaño del volumen, escriba un tamaño de volumen.

15. En la página Asignar a una letra o carpeta de unidad, seleccione una letra de unidad o una
carpeta donde desee montar el volumen.

dieciséis. En la página Seleccionar configuración del sistema de archivos, seleccione el sistema de archivos NTFS o ReFS,

especifique un Tamaño de unidad de asignación y escriba una etiqueta de volumen.

17. Haga clic en Crear. Luego haga clic en Cerrar.

El almacenamiento resistente ahora está disponible para el clúster. Puede crear archivos CSV a partir de él para crear

recursos compartidos de alta disponibilidad utilizando un solo espacio de nombres unificado.

Implementar la réplica de almacenamiento

Storage Replica es una característica de Windows Server 2016 que le permite replicar volúmenes, de forma
sincrónica o asincrónica, con fines de preparación y recuperación ante desastres. Puede realizar
replicaciones entre dispositivos de almacenamiento ubicados en la misma computadora, en el mismo
centro de datos o en ciudades distantes.

Con Storage Replica, puede crear un clúster extendido, que es un clúster que se divide entre
dos o más sitios, sin almacenamiento compartido que conecte los sitios. Por ejemplo tu

469
puede tener un clúster de cuatro nodos con un conjunto de datos, pero dos de los nodos están en la
sucursal de Nueva York y dos en la sede de San Francisco. La idea es que los nodos del sitio de Nueva York
funcionen como respaldo de conmutación por error, en caso de que la oficina de San Francisco sufra un
desastre.

Cada sitio tiene almacenamiento compartido para sus dos nodos, pero no tienen acceso al almacenamiento en
los sitios opuestos. A esto se le llama almacenamiento asimétrico. Sin embargo, para que los dos sitios funcionen
como un verdadero clúster de conmutación por error, deben tener los mismos datos. Storage Replica puede
replicar los datos entre los dos sitios, ya sea de forma sincrónica o asincrónica.

¿Necesita más revisión? Usando Storage Replica

Para obtener más información sobre la implementación de Storage Replica en un
entorno de clúster, consulte Capitulo 2.

Implementar testigo en la nube

Un testigo de nube es un nuevo tipo de testigo de quórum para un clúster de conmutación por error. En lugar de almacenar el testigo

en un disco o en un archivo compartido, se almacena en la nube, en una cuenta de almacenamiento de Windows Azure. La función de

un testigo en la nube es mantener un clúster en funcionamiento, incluso cuando la mitad de sus nodos están inactivos o en un estado

de cerebro dividido.

Cuando un clúster se divide uniformemente entre dos sitios, las versiones anteriores de la agrupación en
clústeres de conmutación por error le obligan a almacenar el testigo en un sitio o en el otro, declarando
efectivamente uno como sitio principal y otro como secundario. La única otra opción es crear un tercer sitio en
otra ubicación, con un servidor solo para almacenar el testigo, lo cual es una propuesta costosa.

La razón de esto es permitir que cualquiera de las dos mitades del clúster continúe ejecutándose si la otra
mitad sufre un corte de energía u otro desastre. Si el testigo se almacena en uno de los sitios, como se muestra
enFigura 5-40, entonces ese sitio tiene la mayoría de los votos de quórum.

470
 FIGURA 5-40 Diagrama de un clúster dividido con un testigo de disco

Si el sitio de la minoría dejó de funcionar, el clúster del sitio de la mayoría continúa ejecutándose, porque tiene
quórum. Sin embargo, si el sitio de la mayoría deja de funcionar, el sitio de la minoría debe detenerse también, porque
no tenía quórum. Ahora, en la agrupación en clústeres de conmutación por error de Windows Server 2016, si el testigo
está almacenado en la nube, como se muestra enFigura 5-41. Si el clúster superviviente puede conectarse a Internet,
para obtener el voto de los testigos, cualquiera de las mitades del clúster puede continuar ejecutándose si la otra falla.
Microsoft recomienda el uso de un testigo en la nube para cualquier clúster de conmutación por error en el que todos
los nodos tengan acceso a Internet.

471
 FIGURA 5-41 Diagrama de un clúster dividido con un testigo de nube

Un testigo en la nube se almacena en la nube mediante una cuenta de almacenamiento de Microsoft Azure,
que es una forma económica de almacenar pequeñas cantidades de datos en la nube, sin tener que mantener un
servidor virtual únicamente para ese propósito. El testigo se almacena como un objeto binario grande (llamado
blob).

Para crear un testigo en la nube, primero debe crear una cuenta de almacenamiento en Microsoft Azure y
luego configurar el testigo en la nube para que el clúster use esa cuenta. Para crear la cuenta de
almacenamiento, utilice el siguiente procedimiento.

1. En Azure Portal, seleccione Nuevo | Almacenamiento | Cuenta de almacenamiento, como se muestra enFigura 5-42.

472
 FIGURA 5-42 Creación de una cuenta de almacenamiento en el portal de Azure

2. En el campo Nombre, escriba un nombre para la cuenta.

3. En la lista desplegable Tipo de cuenta, seleccione Blob Storage.

4. En la lista desplegable Replicación, seleccione Almacenamiento con redundancia local (LRS).

5. Haga clic en Crear.

6. Cuando se crea la cuenta de almacenamiento, selecciónela en el panel de Azure y haga clic en el icono de
claves.

7. Tenga en cuenta la siguiente información que aparece en la página, que necesitará para
configurar el testigo:
Nombre de la cuenta de almacenamiento

Llave

Punto de conexión del servicio Blob

Con esta información en la mano, puede proceder a configurar su clúster con un testigo en la
nube, utilizando el siguiente procedimiento.

1. En Failover Cluster Manager, en la página principal de su clúster, seleccione Más acciones | Configure las
opciones del quórum del clúster para iniciar el Asistente para configurar el quórum del clúster.

2. En el panel Seleccionar opción de configuración de quórum, seleccione la opción Seleccionar el

testigo de quórum.

3. En la página Seleccionar testigo de quórum, seleccione Configurar un testigo de nube.

4. En la página Configurar Cloud Witness, que se muestra en Figura 5-43, escribe la información

473
que recopiló del portal de Azure.

474
 FIGURA 5-43 La página Configure Cloud Witness de Configure Cluster Quorum
Mago
5. Haga clic en Finalizar.

Para configurar un testigo en la nube con PowerShell, use un comando como el siguiente:
Haga clic aquí para ver la imagen del código

set-clusterquorum -cloudwitness -accountname clusterstorage1 - clave de acceso

oyhmhpi1x9q5htonrcxhcnpz0xzw2zgf49lgdwmexn5lr7xcdrenuxtlxujdpfwc

Implementar la resistencia de la máquina virtual

Toda la idea detrás de la agrupación en clústeres es proporcionar servicios que puedan seguir funcionando a
pesar de eventos catastróficos. Sin embargo, en el clima actual, las fallas transitorias localizadas ocurren con más
frecuencia que las grandes catástrofes. Por este motivo, la versión de clústeres de conmutación por error de
Windows Server 2016 incluye mejoras que aumentan la resistencia de las máquinas virtuales individuales de varias
formas.

Los nodos de clúster se comunican constantemente; al menos, se supone que deben comunicarse
constantemente. Sin embargo, es común que una sola máquina virtual pierda contacto con el clúster
temporalmente. Hay muchas causas posibles para esto: por ejemplo, el Cluster

475
El servicio en una máquina virtual puede cerrarse debido a un problema de memoria o software; la comunicación de la red
puede verse interrumpida debido a un controlador o un problema de direccionamiento IP; o el cable de red podría estar
dañado o simplemente desenchufado.

Para ayudar a los administradores a abordar problemas como estos, Windows Server 2016 ha
introducido nuevos estados de VM, que aparecen en Failover Cluster Manager como el estado de un rol o
nodo. Estos estados incluyen lo siguiente:

No supervisado Indica que el servicio de clúster no supervisa la máquina virtual que

posee un rol.
Aislado Indica que el nodo no se encuentra actualmente en un miembro activo del clúster, pero
todavía está en posesión de un rol. Durante una falla transitoria, una máquina virtual se coloca
primero en el estado aislado y luego pasa al estado no supervisado cuando se quita del clúster activo.

Cuarentena Indica un nodo que ha sido drenado de sus funciones y eliminado del clúster durante un
período de tiempo específico después de haber abandonado y vuelto a ingresar al clúster tres veces
en la hora anterior.

También puede configurar la forma en que el clúster usa estos estados, usando la siguiente
configuración en Windows PowerShell:

Nivel de resiliencia Un valor de 1 habilita el uso del estado aislado solo si el nodo proporciona
una razón conocida para desconectarse del clúster. De lo contrario, el nodo falla inmediatamente.
Un valor de 2 (que es el predeterminado) permite el uso gratuito del estado Aislado y permite que
el nodo se recupere.

Haga clic aquí para ver la imagen del código

(get-cluster) .resiliencylevel = 2

ResiliencyDefaultPeriod Especifica cuánto tiempo se permite que los nodos de todo el

clúster permanezcan en estado aislado (en segundos). El valor predeterminado es 240.

Haga clic aquí para ver la imagen del código

(get-cluster) .resiliencydefaultperiod = 240

Período de resiliencia Especifica cuánto tiempo se permite que los nodos de un grupo en particular
permanezcan en el estado Aislado (en segundos). Un valor de -1 hace que el grupo vuelva a la
configuración de ResiliencyDefaultPeriod. El valor predeterminado es 240.

Haga clic aquí para ver la imagen del código

(get-clustergroup "group1"). resiliencyperiod = 240

QuarantineThreshold Especifica el número de fallas que puede experimentar un nodo en un

período de una hora antes de ser puesto en cuarentena. El valor predeterminado es 3.

Haga clic aquí para ver la imagen del código

476
 (get-cluster) .quarantinethreshold = 3

CuarentenaDuración Especifica el tiempo (en segundos) que un nodo permanece en

cuarentena. El valor predeterminado es 7200.

Haga clic aquí para ver la imagen del código

(get-cluster) .quarantineduration = 7200

Implementar VHDX compartido como solución de almacenamiento para clústeres invitados

La creación de un clúster de invitados en un clúster de conmutación por error existente puede complicar el problema del

almacenamiento compartido. Sin embargo, es posible utilizar el almacenamiento compartido proporcionado por un clúster físico para

crear un archivo VHDX compartido para el clúster invitado.

En este escenario, tiene dos o más servidores Hyper-V físicos, que funcionan como nodos en un clúster de conmutación por
error. Estos servidores físicos están conectados a hardware de almacenamiento compartido mediante iSCSI, SAS o Fibre
Channel, como se muestra enFigura 5-44. El almacenamiento compartido se configura como volúmenes compartidos de clúster
o recursos compartidos de SMB 3.0.

FIGURA 5-44 Diagrama de un clúster físico con almacenamiento compartido

Para crear el clúster de invitados, cada uno de los servidores Hyper-V aloja una máquina virtual. Para crear el
almacenamiento compartido que necesita el clúster invitado, puede crear un archivo VHDX compartido en los CSV
del clúster físico, como se muestra enFigura 5-45.

477
 FIGURA 5-45 Diagrama de un clúster invitado con un archivo VHDX compartido

Windows Server 2016 admite dos tipos de archivos de disco duro virtual compartidos, de la siguiente manera:

VHDX Introducidos en Windows Server 2012 R2, los archivos VHDX creados en una infraestructura de
almacenamiento compartido se pueden compartir entre máquinas virtuales en un clúster invitado. Los archivos
VHDX compartidos todavía son compatibles con Windows Server 2016, para proporcionar compatibilidad con
versiones anteriores para los clústeres existentes, pero Microsoft recomienda crear conjuntos VHD para archivos
nuevos.

Conjunto de VHD Introducido en Windows Server 2016, un conjunto de VHD consta de un archivo VHDS de 260 KB,
que contiene metadatos, y un archivo AVHDX, que contiene los datos reales. Los conjuntos VHD brindan capacidades
de cambio de tamaño en línea y soporte para copias de seguridad basadas en host de las que carecen los archivos
VHDX.

Nota Conversión de formatos VHD

Puede convertir un archivo VHDX al nuevo formato VHD Set mediante el cmdlet
Convert-VHD en Windows PowerShell. El cmdlet funciona creando un nuevo archivo
con el formato apropiado y copiando los datos en él desde el

478
 archivo original. El formato del destino se especifica mediante la extensión del nombre de
archivo, que para un conjunto de VHD es VHDS. Un comando típico aparece de la siguiente
manera:

Haga clic aquí para ver la imagen del código

convert-vhd -path disk.vhdx -destinationpath disk.vhds

Para crear un nuevo archivo compartido de VHDX o VHD Set para un clúster invitado, abra el cuadro de diálogo
Configuración en el Administrador de clústeres de conmutación por error, seleccione el controlador SCSI, seleccione
Unidad compartida y haga clic en Agregar. A continuación, puede iniciar y ejecutar el Asistente para nuevo disco duro
virtual, tal como lo haría en un servidor Hyper-V no agrupado. La única diferencia es una página Elegir formato de disco,
que se muestra enFigura 5-46, en el que especifica si desea crear un archivo VHDX o VHD Set.

479
 FIGURA 5-46 La página Elegir formato de disco del Asistente para agregar disco duro virtual

Habilidad 5.3: Implementar espacios de almacenamiento directo

Espacios de almacenamiento directo (S2D) es la siguiente etapa en la evolución de la tecnología de

almacenamiento definida por software que apareció por primera vez en servidores como Espacios de
almacenamiento en Windows Server 2012. Espacios de almacenamiento permite crear grupos que contienen el
espacio de varias unidades de disco físico y luego crear discos virtuales del almacenamiento agrupado,
independientemente de los límites del disco físico. Storage Spaces Direct proporciona el mismo tipo de servicios
en un entorno en clúster, lo que hace posible crear grupos de almacenamiento compartido utilizando las unidades
SAS, SATA o NVMe locales estándar dentro de los nodos del clúster. Por primera vez, no es necesario comprar
costosas matrices de almacenamiento externo para implementar un clúster de conmutación por error.

Esta sección cubre cómo:

Determinar los requisitos del escenario para implementar Storage Spaces Direct
Habilitar Storage Spaces directamente con Windows PowerShell
Implementar un escenario de Espacios de almacenamiento directo desagregado en un clúster

480
 Implementar un escenario de Storage Spaces Direct hiperconvergente en un clúster

Determinar los requisitos del escenario para implementar Storage Spaces Direct
Storage Spaces Direct proporciona muchos de los mismos beneficios que Storage Spaces, como la
redundancia de datos y el almacenamiento por niveles, y lo hace en software, utilizando unidades de disco
estándar y componentes de red comunes. Sin embargo, esto no quiere decir que S2D no tenga requisitos
especiales. Las siguientes secciones explican algunos de los factores que debe considerar antes de
implementar un clúster S2D.

Nota Disponibilidad directa de espacios de almacenamiento

Storage Spaces Direct se incluye solo en la edición Datacenter de Windows Server 2016, no
en la edición Standard. Sin embargo, puede usar S2D en un servidor de centro de datos
utilizando cualquiera de las opciones de instalación, incluidos Server Core y Nano Server, así
como la experiencia de escritorio completa.

Servidores

Un clúster de Espacios de almacenamiento directo puede constar de hasta 16 nodos, con hasta 400
unidades. A pesar de la capacidad de S2D para funcionar con componentes estándar, los servidores del
clúster deben poder admitir una gran cantidad de unidades y múltiples interfaces de red.

Unidades de disco

La configuración de unidad recomendada para un nodo en un clúster S2D es un mínimo de seis unidades, con
al menos dos unidades de estado sólido (SSD) y al menos cuatro unidades de disco duro (HDD). Cualquiera
que sea el factor de forma de la carcasa de la unidad, interna o externa, no debe haber ningún RAID u otra
inteligencia que no se pueda desactivar. S2D proporciona tolerancia a fallos y alto rendimiento; El hardware
de la competencia solo tendrá un efecto negativo en la funcionalidad general del clúster.

Para que S2D los detecte y los use, los discos deben inicializarse (generalmente usando GPT),
pero no deben estar particionados. Los discos con particiones o volúmenes no se considerarán
elegibles para su uso por Storage Spaces Direct.

Redes
La clave de Storage Spaces Direct es la bus de almacenamiento de software, un conducto de red lógica
que conecta las unidades de datos locales en todos los nodos del clúster. Este bus teóricamente cae entre
los servidores y las unidades de disco dentro de ellos, como se muestra enFigura 5-47.

481
 FIGURA 5-47 El bus de almacenamiento de software

Debido a que S2D crea un grupo a partir del almacenamiento interno en diferentes computadoras, todo el tráfico de
almacenamiento se transporta a través de redes Ethernet estándar usando SMB3 y RDMA. No existe un tejido de red de
almacenamiento tradicional, como SAS o Fibre Channel, lo que elimina las limitaciones de distancia y la necesidad de
diferentes tipos de cableado. Sin embargo, la gestión del tráfico es, por tanto, una parte fundamental de cualquier
implementación de clúster S2D de producción.

La realización física del bus de almacenamiento de software lógico debe transferir datos como si los
discos de los distintos nodos del clúster fueran una sola entidad. Además, las redes deben transportar los
datos redundantes generados por los arreglos de paridad y duplicación en discos virtuales creados a partir
del grupo. Por lo tanto, el rendimiento eficiente de S2D requiere comunicaciones Ethernet intranodo que
proporcionen tanto ancho de banda alto como baja latencia.

En la capa física, Microsoft recomienda el uso de al menos dos adaptadores Ethernet de 10 Gbps por
nodo, preferiblemente adaptadores que usen RDMA, para que puedan descargar parte de la carga del
procesador de los servidores.
S2D utiliza Server Message Block versión 3 (SMB3) para las comunicaciones entre los nodos del
clúster, empleando las funciones avanzadas del protocolo, como SMB Direct y SMB Multichannel,
siempre que sea posible.

482
Habilitar espacios de almacenamiento directamente con Windows PowerShell

La mayor parte del proceso de implementación de un clúster que usa Storage Spaces Direct es casi el mismo
que el de cualquier otro clúster. Instala Windows Server 2016 en los nodos del clúster, los actualiza de manera
idéntica, agrega la característica de clústeres de conmutación por error y el nodo Hyper-V, y crea el clúster.

Aquí encontrará una desviación importante del procedimiento estándar. Si bien puede crear
el clúster mediante el asistente gráfico Crear clúster en Failover Cluster Manager, debe evitar
que el sistema busque y agregue almacenamiento automáticamente. Por lo tanto, debe crear
el clúster en Windows PowerShell con un comando como el siguiente:
Haga clic aquí para ver la imagen del código

nuevo-clúster -nombre clúster1 -nodo servidor1,

servidor2, servidor3, servidor4 -nostorage

El parámetro NoStorage es importante aquí, y la falta de almacenamiento generará un error

durante la creación del clúster. El almacenamiento se agregará cuando habilite Stoage Spaces Direct.
Para hacer esto, ejecute el cmdlet Enable-ClusterStorageSpacesDirect sin ningún parámetro, de la
siguiente manera:

enable-clusterstoragespacesdirect

Este cmdlet realiza varias tareas que son cruciales para la implementación de S2D, incluidas las
siguientes:
Localiza discos El sistema escanea todos los nodos del clúster en busca de discos locales sin particiones.

Crea cachés El sistema clasifica los discos en cada nodo por sus respectivos tipos de bus y medios y
establece enlaces entre ellos para crear asociaciones en cada servidor que utilizan los discos más
rápidos para el almacenamiento en caché de lectura y escritura.

Crea una piscina El sistema agrega todos los discos disponibles en todos los nodos en un solo grupo de
almacenamiento de todo el clúster.

Una vez que se crea el grupo de almacenamiento, puede proceder a crear discos virtuales en él (tal como lo hace en
Espacios de almacenamiento en el Administrador del servidor en un servidor independiente). En Failover Cluster
Manager, seleccione el grupo de almacenamiento, como se muestra enFigura 5-48e inicie el Asistente para nuevo disco
virtual (Storage Spaces Direct). En el asistente, especifica un tamaño y crea un disco utilizando la configuración
predeterminada de resistencia de espejo bidireccional.

483
 FIGURA 5-48 El cuadro de diálogo Seleccionar el grupo de almacenamiento

Sin embargo, los discos virtuales S2D pueden admitir tipos de resiliencia simple, duplicada y de paridad,
así como niveles de almacenamiento personalizados. Para obtener más flexibilidad en la creación de discos
virtuales, puede usar el cmdlet New-Volume en Windows PowerShell. Este cmdlet puede realizar, en un solo
paso, tareas que en un momento requirieron varias operaciones independientes, incluida la creación,
partición y formateo del disco virtual, convertirlo al sistema de archivos CSVFS y agregarlo al clúster.

Por ejemplo, para crear un disco virtual que use resistencia de paridad y dos niveles, con los nombres
descriptivos predeterminados de Rendimiento para SSD y Capacidad para HDDS, puede usar un comando
como el siguiente:

Haga clic aquí para ver la imagen del código

new-volume -storagepool "s2d *" -friendlyname vdisk1 -filesystem csvfs_refs

- rendimiento de nombre de paridad: niveles de almacenamiento nombres amistosos

configuración de resiliencia, capacidad
- niveles de almacenamiento de 10 gb, 100 gb

Una vez que haya creado los discos virtuales, puede agregarlos a los volúmenes compartidos del clúster para
que sean accesibles en todos los nodos.

Implementar un escenario de Espacios de almacenamiento directo desagregado en un clúster

La aplicación designada para Storage Spaces Direct, según se define en los dos escenarios de implementación de
Microsoft, es compatible con un clúster de Hyper-V. En el primer escenario, denominado implementación
desagregada o convergente, hay dos grupos distintos. El primero es un clúster de servidor de archivos escalable
que usa Storage Spaces Direct para proporcionar el almacenamiento para el segundo, un clúster de Hyper-V que
aloja máquinas virtuales, como se muestra enFigura 5-49.

484
485
 FIGURA 5-49 Una implementación de Storage Spaces Direct desagregada

En este escenario, la función del clúster S2D es proporcionar el almacenamiento que el clúster Hyper-
V necesita para sus máquinas virtuales. Como tal, S2D es esencialmente un reemplazo de una SAN.
Debido a que requiere dos clústeres separados, este modelo requiere más servidores y, por lo tanto, es
más costoso de implementar. Sin embargo, la ventaja de este tipo de implementación es que el clúster
S2D y el clúster Hyper-V pueden escalar de forma independiente.
Storage Spaces Direct crea un entorno altamente escalable en el que puede agregar unidades a los
nodos o agregar nodos al clúster. De cualquier manera, S2D asimilará cualquier nuevo almacenamiento
detectado en el grupo. En una implementación desagregada, puede agregar almacenamiento al clúster de
S2D sin afectar al clúster de Hyper-V. De la misma manera, puede agregar nodos al clúster de Hyper-V sin
afectar la infraestructura de almacenamiento.

Para implementar el escenario desagregado, proceda como se describió anteriormente para crear un clúster,
habilitar S2D, crear discos virtuales y agregarlos a CSV. Luego, agrega la función de servidor de archivos de
escalabilidad horizontal para completar la configuración del clúster de almacenamiento. El segundo clúster es un
clúster Hyper-V estándar que utiliza los recursos compartidos proporcionados por el clúster SoFS para almacenar sus
máquinas virtuales.

Implementar un escenario de Storage Spaces Direct hiperconvergente en un clúster

El segundo escenario de Storage Spaces Direct se denomina hiperconvergente porque combina Storage
Services Direct con Hyper-V en un solo clúster, como se muestra en Figura 5-50. Hay menos hardware
involucrado en esta solución y ciertamente genera menos tráfico de red; también es mucho menos
costoso y requiere menos mantenimiento. No es necesario configurar los permisos del servidor de
archivos ni supervisar dos clústeres.

486
 FIGURA 5-50 Una implementación de Storage Spaces Direct hiperconvergente

Sugerencia para el examen

Con Windows Server 2016, es posible crear un clúster S2D hiperconvergente en un

solo servidor Hyper-V, con fines educativos y de prueba. Después de instalar
Failover Clustering e Hyper-V, puede crear dos o más máquinas virtuales con
varios archivos VHDX en cada una, agruparlas y habilitar Storage

487
 pasos Directos. Luego, después de exponer las extensiones de virtualización del servidor
host, puede instalar Hyper-V en las VM, crear VM anidadas y agruparlas. Eso
ser no será rápido, y la tormenta de solicitudes de disco manejadas por el servidor host
Los discos físicos serían caóticos si pudieras verlos, pero funciona.

El inconveniente de este escenario es que no puede escalar los servicios SoFS e Hyper-V de forma
independiente. Si desea agregar un servidor para proporcionar más almacenamiento al grupo, también
debe agregar un nodo al clúster de Hyper-V.
La implementación de un clúster de Espacios de almacenamiento directo hiperconvergente no es muy diferente
de la de un clúster Hyper-V estándar, excepto que debe habilitar S2D después de crear el clúster. Uno de los
aspectos positivos de S2D es que aprovecha las habilidades que los administradores probablemente ya conocen. Si
ha trabajado con clústeres de conmutación por error de Windows
Por lo tanto, no debería haber muchas cosas nuevas para usted en una implementación de S2D. De hecho, en
comparación con la configuración de una SAN, Storage Spaces Direct es mucho más fácil.

¿Necesita más revisión?

Para obtener un procedimiento detallado que describe una implementación de clúster de

Storage Spaces Direct hiperconvergente, consulte https://technet.microsoft.com/en-us/
windows-serverdocs/storage/storage-spaces/hyper-converged-solution-using-storagespaces-
direct.

Comprobación rápida

¿Cuál de las siguientes soluciones de almacenamiento compartido permite que los clústeres utilicen los
discos locales dentro de una computadora?

1. Canal de fibra
2. Volúmenes compartidos en clúster

3. SCSI conectado en serie

4. Espacios de almacenamiento directo

Respuesta de verificación rápida

Storage Spaces Direct (n. ° 4) puede crear un grupo que consta del almacenamiento en disco
local en todos los nodos del clúster combinados y compartidos con todo el clúster.

Habilidad 5.4: Gestionar la agrupación en clústeres de conmutación por error

Una vez que haya instalado y configurado un clúster de conmutación por error, debe realizar tareas de
mantenimiento y administración en curso, utilizando herramientas como Failover Cluster Manager y
cmdlets de Windows PowerShell en el módulo FailoverClusters.

488
 Esta sección cubre cómo:
Configure los ajustes específicos de la función, incluidos los recursos compartidos disponibles continuamente. Configure

la supervisión de la máquina virtual.

Configurar la configuración de preferencias y la conmutación por error Implementar

clústeres de conmutación por error extensibles y con reconocimiento del sitio

Habilitar y configurar la equidad de nodos

Configure los ajustes específicos de la función, incluidos los recursos compartidos disponibles continuamente

Cada rol de clúster que instala en el Administrador de clústeres de conmutación por error o mediante un cmdlet de
PowerShell tiene su propia configuración que es específica para la función del rol. En la página Roles del Administrador
de clústeres de conmutación por error, cuando selecciona uno de sus roles, aparece una sección en el panel Acciones,
como se muestra enFigura 5-51. Algunas de las acciones del panel son específicas de la función y algunas son acciones
genéricas que aparecen en cada panel de funciones.

489
490
 FIGURA 5-51 La lista de acciones para el rollo de clúster de la máquina virtual

Configuración del rol de la máquina virtual

En este ejemplo, para el rol de Máquina virtual, hay acciones como las de Hyper-V Manager, que le
permiten iniciar, detener y conectarse a la VM, así como abrir su cuadro de diálogo Configuración. El
menú Mover le permite realizar migraciones en vivo, migraciones rápidas y migrar el almacenamiento
de la máquina virtual, utilizando la interfaz que se muestra enFigura 5-52.

491
 FIGURA 5-52 El cuadro de diálogo Mover almacenamiento de máquina virtual

Configuración para compartir continuamente disponible

Cuando instala la función de clúster del servidor de archivos, tiene la opción de crear un servidor de archivos de
uso general o un servidor de archivos escalable diseñado para proporcionar almacenamiento a aplicaciones,
como Hyper-V y SQL Server. Ambos roles le permiten crear recursos compartidos que están continuamente
disponibles mediante el uso del protocolo SMB 3.0.

La versión 3.0 del protocolo SMB incluye mejoras que son particularmente útiles en un
entorno en clúster, incluidas las siguientes:
Conmutación por error transparente SMB Permite que una sesión de cliente se transfiera de un nodo del clúster a
otro sin interrupción. Esto se implementa de forma predeterminada en todos los recursos compartidos del servidor
de archivos del clúster de conmutación por error. Tanto el cliente como el servidor deben admitir SMB 3.0 (Windows
Server 2012 o Windows 8).

Escalado horizontal de SMB Permite que los clientes puedan acceder a los recursos compartidos desde todos los nodos del

clúster simultáneamente. Esto aumenta efectivamente el ancho de banda disponible del recurso compartido al ancho de

banda combinado de los nodos. Los recursos compartidos escalables solo son accesibles para los clientes que ejecutan las

versiones 2 y 3 de SMB.

SMB multicanal Permite que los servidores de archivos combinen el ancho de banda de varios
adaptadores de interfaz de red para lograr una mejor tolerancia a fallas y en todo momento. SMB

492
 puede detectar automáticamente la existencia de múltiples adaptadores y configurarse para
hacer uso de ellos.

SMB directo Utiliza Remote Direct Memory Access (RDMA) para realizar transferencias
directas de datos de memoria a memoria entre sistemas remotos, lo que minimiza la
utilización del procesador del sistema. Tanto el cliente como el servidor deben utilizar SMB 3.0.

Cifrado SMB Proporciona cifrado AES de extremo a extremo entre servidores y clientes que
utilizan SMB 3.0.
Cuando crea o modifica un recurso compartido de servidor de archivos en el Administrador de clústeres de conmutación por error, el

Asistente para recurso compartido nuevo presenta una página Configurar opciones de recurso compartido, como se muestra en Figura

5-53. La casilla de verificación Habilitar disponibilidad continua, seleccionada de forma predeterminada, activa la función de conmutación

por error transparente SMB y la casilla de verificación Cifrar acceso a datos habilita el cifrado SMB.

493
 FIGURA 5-53 La página Configurar opciones de recursos compartidos del Asistente para recursos compartidos nuevos

Configurar el monitoreo de VM
Una de las ventajas de ejecutar Hyper-V en un clúster es que el clúster es capaz de monitorear servicios
específicos en las máquinas virtuales, informar cuando ocurre un problema y tomar medidas que usted
puede configurar. De esta manera, puede seleccionar el servicio asociado con una aplicación crítica en la
VM y configurar la VM para reiniciarla o conmutar por error a otro nodo cuando ocurre un problema.

Para usar la supervisión de VM en la agrupación en clústeres de conmutación por error, la máquina virtual debe cumplir con

los siguientes requisitos previos:

La máquina virtual debe estar en el mismo dominio que el host de Hyper-V.

El Firewall de Windows en la VM debe tener habilitadas las reglas de entrada en el grupo de

Monitoreo de la máquina virtual.

El administrador del clúster de Hyper-V debe ser miembro del grupo de administradores locales en la
máquina virtual.

Para configurar la supervisión de una máquina virtual específica, utilice el siguiente procedimiento.

494
1. Abra el Administrador de clústeres de conmutación por error y haga clic en Roles para mostrar la página Roles.

2. Seleccione el rol de la máquina virtual que desea monitorear y, en el panel Acciones, seleccione
Más acciones, Configurar monitoreo.

3. En el cuadro de diálogo Seleccionar servicios aparece, como se muestra en Figura 5-54, seleccione la
casilla de verificación del servicio que desea supervisar y haga clic en Aceptar.

495
 FIGURA 5-54 El cuadro de diálogo Seleccionar servicios

También puede configurar la supervisión mediante el cmdlet Add-ClusterVMMonitoredItem en una

ventana de Windows PowerShell, como en el siguiente ejemplo:

Haga clic aquí para ver la imagen del código

add-clustervmmonitoreditem –virtualmachine clustervm3 -service

496
 spooler
Cuando un servicio que ha seleccionado experimenta problemas, primero los maneja el Administrador de
control de servicios en la VM, que usa las propiedades del servicio individual para controlar sus acciones,
como se muestra en Figura 5-55. Puede modificar estas propiedades para especificar qué acciones debe
realizar el Administrador de control de servicios y con qué frecuencia.

497
 FIGURA 5-55 Hoja de propiedades de un servicio

Si los esfuerzos del Administrador de control de servicios fallan y el servicio sigue funcionando mal, el clúster toma
el control y realiza sus propias acciones de recuperación, de la siguiente manera:

El clúster crea una entrada en el registro del sistema del host con el Id. De evento 1250.

498
 El clúster cambia el estado de la máquina virtual a Aplicación en VM crítica.
El clúster reinicia la máquina virtual en el mismo nodo. Si el servicio continúa
fallando, el clúster transfiere el rol a otro nodo.
Puede modificar estas actividades de reinicio predeterminadas abriendo la hoja Propiedades de WMI del clúster de
máquinas virtuales, como se muestra en Figura 5-56. Se encuentra en la página principal del clúster, en el cuadro
Recursos principales del clúster.

499
 FIGURA 5-56 La hoja de propiedades de WMI del clúster de máquinas virtuales

Configurar la configuración de preferencias y la conmutación por error

500