Actualización gradual del sistema operativo del clúster
La actualización gradual del sistema operativo (SO) del clúster permite a un administrador actualizar el sistema operativo de los nodos del clúster sin detener la función Hyper-V ni las cargas de trabajo del Servidor de archivos de escalabilidad horizontal. Con esta característica, se pueden evitar las penalizaciones de tiempo de inactividad en los acuerdos de nivel de servicio (SLA).
La actualización gradual del sistema operativo del clúster proporciona las siguientes ventajas:
Los clústeres de conmutación por error que ejecutan máquinas virtuales de Hyper-V y cargas de trabajo de servidor de archivos de escalabilidad horizontal (SOFS) se pueden actualizar desde una versión de Windows Server, a partir de Windows Server 2012 R2, a una versión más reciente de Windows Server. Por ejemplo, puede actualizar Windows Server 2016 (que se ejecuta en todos los nodos de clúster del clúster) a Windows Server 2019 (que se ejecuta en todos los nodos del clúster) sin tiempo de inactividad.
No requiere ningún hardware adicional. En clústeres pequeños, puede agregar nodos de clúster adicionales temporalmente para mejorar la disponibilidad del clúster durante el proceso de actualización gradual del sistema operativo del clúster.
No es necesario detener ni reiniciar el clúster.
No se requiere un nuevo clúster. El clúster existente se actualiza. Además, se usan objetos de clúster existentes almacenados en Active Directory.
El proceso de actualización es reversible hasta el último paso, cuando todos los nodos del clúster ejecutan la versión más reciente de Windows Server y se ejecuta el
Update-ClusterFunctionalLevel
cmdlet de PowerShell.El clúster puede admitir operaciones de revisión y mantenimiento mientras se ejecuta en el modo de sistema operativo mixto.
Admite la automatización a través de PowerShell y WMI.
La propiedad públicaClusterFunctionalLevel del clúster indica el estado del clúster en Windows Server 2016 y nodos de clúster posteriores. Esta propiedad se puede consultar mediante el cmdlet de PowerShell desde un nodo de clúster que pertenece a un clúster de conmutación por error:
Get-Cluster | Select ClusterFunctionalLevel
En la tabla siguiente se muestran los valores y cada nivel funcional correspondiente:
Valor Nivel funcional 8 Windows Server 2012 R2 9 Windows Server 2016 10 Windows Server 2019
En esta guía se describen las distintas fases del proceso de actualización gradual del sistema operativo del clúster, los pasos de instalación, las limitaciones de características y las preguntas más frecuentes (FAQs) y se aplica a los siguientes escenarios de actualización gradual del sistema operativo de clúster en Windows Server:
- Clústeres de Hyper-V
- Clústeres de servidor de archivos de escalabilidad horizontal
No se admiten los siguientes escenarios:
- Actualización gradual del sistema operativo del clúster de clústeres invitados mediante el disco duro virtual (archivo .vhdx) como almacenamiento compartido.
La actualización gradual del sistema operativo del clúster es totalmente compatible con System Center Virtual Machine Manager (SCVMM). Si usa SCVMM, consulte Realizar una actualización gradual de un clúster de hosts de Hyper-V para Windows Server 2016 en VMM para obtener instrucciones sobre cómo actualizar los clústeres y automatizar los pasos que se describen en este documento.
Requisitos
Complete los siguientes requisitos antes de comenzar el proceso de actualización gradual del sistema operativo del clúster:
- Comience con un clúster de conmutación por error que ejecute Windows Server 2012 R2 o posterior. Puede actualizar a la siguiente versión, por ejemplo, desde Windows Server 2016 a Windows Server 2019.
- Compruebe que los nodos de Hyper-V tienen CPU que admiten la tabla de direcciones de segundo nivel (SLAT) mediante uno de los métodos siguientes; - Revise ¿Es compatible con SLAT? Sugerencia 01 del SDK de WP8 que describe dos métodos para comprobar si una CPU admite SLAT -Descargue la herramienta Coreinfo v3.31 para determinar si una CPU es compatible con SLAT.
Estados de transición del clúster durante la actualización gradual del sistema operativo del clúster
En esta sección se describen los distintos estados de transición del clúster de Windows Server que se está actualizando a la siguiente versión de Windows Server mediante la actualización gradual del sistema operativo de clúster.
Para mantener las cargas de trabajo del clúster en ejecución durante el proceso de actualización gradual del sistema operativo del clúster, cambie una carga de trabajo de clúster desde un nodo que ejecuta una versión anterior de Windows Server a un nodo que ejecuta una versión más reciente de Windows Server funciona mediante un modo de compatibilidad. Este modo de compatibilidad hace que los nodos que ejecutan la versión más reciente de Windows Server aparezcan como si estuvieran ejecutando la misma versión anterior de Windows Server. Por ejemplo, al actualizar un clúster de Windows Server 2016 a Windows Server 2019, los nodos de Windows Server 2019 funcionan en un modo de compatibilidad Windows Server 2016 como medida temporal. Un nuevo modo de clúster conceptual, denominado modo de sistema operativo mixto, permite que los nodos de diferentes versiones existan en el mismo clúster (consulte la figura 1).
Figura 1: Transiciones de estado del sistema operativo del clúster
Un clúster de Windows Server entra en modo de sistema operativo mixto cuando se agrega un nodo que ejecuta una versión más reciente de Windows Server al clúster. El proceso es totalmente reversible en este momento: los nodos de Windows Server más recientes se pueden quitar del clúster y los nodos que ejecutan la versión existente de Windows Server se pueden agregar al clúster en este modo. El proceso no es reversible una vez que se ejecuta el Update-ClusterFunctionalLevel
cmdlet de PowerShell en el clúster. Para que este cmdlet se realice correctamente, todos los nodos deben ejecutar la versión más reciente de Windows Server y todos los nodos deben estar en línea.
Estados de transición de un clúster de cuatro nodos mientras se realiza la actualización gradual del sistema operativo
En esta sección se muestran y describen las cuatro fases diferentes de un clúster con almacenamiento compartido cuyos nodos se actualizan de Windows Server 2012 R2 a Windows Server 2016. El proceso es el mismo para las versiones posteriores de Windows Server.
"Fase 1" es el estado inicial: comenzamos con un clúster de Windows Server 2012 R2.
Figura 2: Estado inicial: clúster de conmutación por error de Windows Server 2012 R2 (fase 1)
En "Fase 2", se han pausado, purgado, expulsado, vuelto a formatear e instalado dos nodos con Windows Server 2016.
Figura 3: Estado intermedio: modo de sistema operativo mixto: clúster de conmutación por error de Windows Server 2012 R2 y Windows Server 2016 (fase 2)
En "Fase 3", todos los nodos del clúster se han actualizado a Windows Server 2016 y el clúster está listo para actualizarse con Update-ClusterFunctionalLevel
el cmdlet de PowerShell.
Nota
En esta fase, el proceso se puede invertir completamente y los nodos R2 de Windows Server 2012 se pueden agregar a este clúster.
Figura 4: Estado intermedio: Todos los nodos actualizados a Windows Server 2016, listos para Update-ClusterFunctionalLevel (fase 3)
Una vez ejecutado el Update-ClusterFunctionalLevel
cmdlet, el clúster escribe "Fase 4", donde se pueden usar las nuevas características del clúster de Windows Server 2016.
Figura 5: Estado final: clúster de conmutación por error de Windows Server 2016 (fase 4)
Proceso de actualización gradual de SO del clúster
En esta sección se describe el flujo de trabajo para realizar la actualización gradual del sistema operativo del clúster.
Figura 6: Flujo de trabajo de proceso de actualización gradual del sistema operativo del clúster
La actualización gradual del sistema operativo del clúster incluye los pasos siguientes para actualizar de Windows Server 2012 R2 a Windows Server 2016, pero el proceso es el mismo para versiones posteriores de Window Server.
Prepare el clúster para la actualización del sistema operativo de la siguiente manera:
La actualización gradual del sistema operativo del clúster requiere quitar un nodo a la vez del clúster. Compruebe si tiene suficiente capacidad en el clúster para mantener acuerdos de nivel de servicio de alta disponibilidad cuando se quita uno de los nodos del clúster para una actualización del sistema operativo. Es decir, ¿necesita la capacidad de conmutar por error las cargas de trabajo a otro nodo cuando se quita un nodo del clúster durante el proceso de actualización gradual del sistema operativo del clúster? ¿El clúster tiene la capacidad de ejecutar las cargas de trabajo necesarias cuando se quita un nodo del clúster para la actualización gradual del sistema operativo del clúster?
Para las cargas de trabajo de Hyper-V, compruebe que todos los hosts de Hyper-V de Windows Server tienen compatibilidad con la CPU para la tabla de direcciones de segundo nivel (SLAT). Solo las máquinas compatibles con SLAT pueden usar el rol de Hyper-V en Windows Server 2016 y versiones más recientes.
Compruebe que se han completado las copias de seguridad de carga de trabajo y considere la posibilidad de realizar copias de seguridad del clúster. Detenga las operaciones de copia de seguridad al agregar nodos al clúster.
Compruebe que todos los nodos del clúster están en línea /en ejecución/en ejecución mediante el cmdlet (consulte la
Get-ClusterNode
figura 7).Figura 7: Determinación del estado del nodo mediante Get-ClusterNode cmdlet
Si está ejecutando actualizaciones de software en clústeres (CAU), compruebe estas se están ejecutando actualmente mediante la interfaz de usuario de actualizaciones de software en clústeres o el cmdlet
Get-CauRun
(consulte la figura 8). Detenga la CAU mediante el cmdletDisable-CauClusterRole
(consulte la figura 9) para evitar que cualquier nodo se ponga en pausa y purga mediante la CAU durante el proceso de actualización gradual del sistema operativo del clúster.Figura 8: Uso del
Get-CauRun
cmdlet para determinar si las actualizaciones de software en clústeres se está ejecutando en el clústerDisable-CauClusterRole Ilustración 9: Deshabilitación del rol de Novedades compatible con clústeres mediante el
Disable-CauClusterRole
cmdlet
Para cada nodo en el clúster, complete lo siguiente:
Con la interfaz de usuario del Administrador de clústeres, use la opciónPausar | Purgar para purgar el nodo (consulte la figura 10) o usar el cmdlet (consulte la
Suspend-ClusterNode
figura 11).Figura 10: Purgar roles de un nodo mediante el Administrador de clústeres de conmutación por error
Figura 11: Purgar roles de un nodo mediante el
Suspend-ClusterNode
cmdletCon la interfaz de usuario del Administrador de clústeres, expulse el nodo en pausa del clúster o use el
Remove-ClusterNode
cmdlet.Figura 12: Quitar un nodo del clúster mediante el
Remove-ClusterNode
cmdletVuelva a formatear la unidad del sistema y realice una "instalación limpia del sistema operativo" de Windows Server 2016 en el nodo mediante la opción Personalizado: Instalar solo Windows (avanzado) (consulte la figura 13) en setup.exe. Evite seleccionar la opción Actualizar: Instalar Windows y mantener archivos, configuraciones y aplicaciones, ya que la actualización gradual del sistema operativo del clúster no fomenta la actualización local.
Figura 13: Opciones de instalación disponibles para Windows Server 2016
Agregue el nodo al dominio de Active Directory adecuado.
Agregue los usuarios adecuados al grupo Administradores.
Con la interfaz de usuario de Administrador del servidor o Install-WindowsFeature cmdlet de PowerShell, instale los roles de servidor que necesite, como Hyper-V.
Install-WindowsFeature -Name Hyper-V
Con la interfaz de usuario de Administrador del servidor o Install-WindowsFeature cmdlet de PowerShell, instale la función Clústeres de conmutación por error.
Install-WindowsFeature -Name Failover-Clustering
Instale las funciones adicionales necesarias para las cargas de trabajo del clúster.
Compruebe la configuración de conectividad de red y almacenamiento mediante la interfaz de usuario del Administrador de clústeres de conmutación por error.
Si se usa Firewall de Windows, compruebe que la configuración del firewall es correcta para el clúster. Por ejemplo, los clústeres habilitados para la actualización de software con clústeres (CAU) pueden requerir la configuración del firewall.
Para las cargas de trabajo de Hyper-V, use la interfaz de usuario de Administrador de Hyper-V para iniciar el cuadro de diálogo Administrador de conmutadores virtuales (consulte la figura 14).
Compruebe que el nombre de los conmutadores virtuales usados son idénticos para todos los nodos host de Hyper-V del clúster.
Figura 14: Administrador de conmutadores virtuales
En un nodo de Windows Server 2016 (no use un nodo R2 de Windows Server 2012), use el Administrador de clústeres de conmutación por error (consulte la figura 15) para conectarse al clúster.
Figura 15: Agregar un nodo al clúster mediante el Administrador de clústeres de conmutación por error
Use la interfaz de usuario del Administrador de clústeres de conmutación por error o el
Add-ClusterNode
cmdlet (consulte la figura 16) para agregar el nodo al clúster.Figura 16: Agregar un nodo al clúster mediante el
Add-ClusterNode
cmdletNota
Cuando el primer nodo Windows Server 2016 se une al clúster, el clúster entra en modo "Sistema operativo mixto" y los recursos principales del clúster se mueven al nodo Windows Server 2016. Un clúster de modo "Sistema operativo mixto" es un clúster totalmente funcional donde los nodos nuevos se ejecutan en un modo de compatibilidad con los nodos antiguos. El modo "Sistema operativo mixto" es un modo transitorio para el clúster. No está pensado para ser permanente y se espera que los clientes actualicen todos los nodos de su clúster en cuatro semanas.
Después de agregar correctamente el nodo Windows Server 2016 al clúster, puede mover (opcionalmente) parte de la carga de trabajo del clúster al nodo recién agregado para volver a equilibrar la carga de trabajo en el clúster de la siguiente manera:
Figure 17: Traslado de una carga de trabajo de clúster (rol de máquina virtual de clúster) mediante el
Move-ClusterVirtualMachineRole
cmdletUse la migración en vivo desde el Administrador de clústeres de conmutación por error para máquinas virtuales o el cmdlet
Move-ClusterVirtualMachineRole
(consulte la figura 17) para realizar una migración en vivo de las máquinas virtuales.Move-ClusterVirtualMachineRole -Name VM1 -Node robhind-host3
Use Move from the Failover Cluster Manager (Mover desde el Administrador de clústeres de conmutación por error) o el
Move-ClusterGroup
cmdlet para otras cargas de trabajo de clúster.
Cuando se haya actualizado cada nodo a Windows Server 2016 y vuelva a agregarlo al clúster, o cuando se haya expulsado cualquier nodo R2 restante de Windows Server 2012, haga lo siguiente:
Importante
- Después de actualizar el nivel funcional del clúster, no puede volver al nivel funcional de Windows Server 2012 R2 y no se pueden agregar nodos R2 de Windows Server 2012 al clúster.
- Hasta que se ejecute el
Update-ClusterFunctionalLevel
cmdlet, el proceso es totalmente reversible y se pueden agregar nodos R2 de Windows Server 2012 a este clúster y se pueden quitar nodos de Windows Server 2016. - Algunas operaciones de clúster, como la purga de nodos, pueden provocar que un nodo se aísle durante un breve período de tiempo. Este comportamiento puede producirse cuando no se ha ejecutado la operación
Update-ClusterFunctionalLevel
. - Una vez ejecutado el
Update-ClusterFunctionalLevel
cmdlet, habrá nuevas características disponibles.
Con la interfaz de usuario del Administrador de clústeres de conmutación por error o el
Get-ClusterGroup
cmdlet, compruebe que todos los roles de clúster se ejecutan en el clúster según lo previsto. En el ejemplo siguiente, no se usa el almacenamiento disponible, sino que se usa CSV, por lo tanto, el almacenamiento disponible muestra un estado Sin conexión (consulte la figura 18).Figura 18: Comprobación de que todos los grupos de clústeres (roles de clúster) se ejecutan mediante el
Get-ClusterGroup
cmdletCompruebe que todos los nodos del clúster están en línea y en ejecución mediante el
Get-ClusterNode
cmdlet.Ejecute el
Update-ClusterFunctionalLevel
cmdlet : no se debe devolver ningún error (consulte la figura 19).Figure 19: Actualización del nivel funcional de un clúster mediante PowerShell
Una vez ejecutado el
Update-ClusterFunctionalLevel
cmdlet, habrá nuevas características disponibles.
Reanude las actualizaciones y copias de seguridad normales del clúster:
Si anteriormente estaba ejecutando CAU, reinícielo mediante la interfaz de usuario de CAU o use el
Enable-CauClusterRole
cmdlet (consulte la figura 20).Figura 20: Habilitación del rol de actualizaciones de software con clústeres mediante el
Enable-CauClusterRole
cmdletReanude las operaciones de copia de seguridad.
Habilite y use las características de Windows Server 2016 en las máquinas virtuales de Hyper-V.
Después de actualizar el clúster al nivel funcional de Windows Server 2016, muchas cargas de trabajo como las máquinas virtuales de Hyper-V tendrán nuevas funcionalidades. Para obtener una lista de las nuevas funcionalidades de Hyper-V, consulte Migrar y actualizar máquinas virtuales
En cada nodo host de Hyper-V del clúster, use el
Get-VMHostSupportedVersion
cmdlet para ver las versiones de configuración de máquina virtual de Hyper-V compatibles con el host.Figura 21: Visualización de las versiones de configuración de máquina virtual de Hyper-V compatibles con el host
En cada nodo host de Hyper-V del clúster, las versiones de configuración de máquinas virtuales de Hyper-V se pueden actualizar mediante la programación de una breve ventana de mantenimiento con los usuarios, la copia de seguridad, la desactivación de máquinas virtuales y la ejecución del
Update-VMVersion
cmdlet (consulte la figura 22). Esto actualizará la versión de la máquina virtual y habilitará las nuevas características de Hyper-V, lo que eliminará la necesidad de futuras actualizaciones del componente de integración de Hyper-V (IC). Este cmdlet se puede ejecutar desde el nodo de Hyper-V que hospeda la máquina virtual o el-ComputerName
parámetro se puede usar para actualizar la versión de la máquina virtual de forma remota. En este ejemplo, aquí se actualiza la versión de configuración de VM1 de 5.0 a 7.0 para aprovechar muchas nuevas características de Hyper-V asociadas a esta versión de configuración de máquina virtual, como puntos de control de producción (copias de seguridad coherentes con la aplicación) y el archivo de configuración de máquina virtual binaria.Figura 22: Actualización de una versión de máquina virtual mediante el cmdlet de PowerShell Update-VMVersion
Los grupos de almacenamiento se pueden actualizar mediante el cmdlet Update-StoragePool de PowerShell: se trata de una operación en línea.
Aunque estamos dirigidos a escenarios de nube privada, específicamente los clústeres de Hyper-V y servidor de archivos de escalabilidad horizontal, que se pueden actualizar sin tiempo de inactividad, el proceso de actualización gradual del sistema operativo del clúster se puede usar para cualquier rol de clúster.
Restricciones y limitaciones
- Esta característica solo funciona para las versiones de Windows Server a partir de Windows Server 2012 R2. Esta característica no puede actualizar versiones anteriores de Windows Server como Windows Server 2008, Windows Server 2008 R2 o Windows Server 2012.
- Cada nodo de Windows Server 2016 solo debe volver a formatear o realizar una nueva instalación. No se recomiendan los tipos de instalación local oactualización.
- Se debe usar un nodo que ejecute la versión más reciente de Windows Server para agregar los nuevos nodos al clúster.
- Al administrar un clúster de modo de sistema operativo mixto, realice siempre las tareas de administración desde un nodo de nivel superior que ejecuta Windows Server 2016. Los nodos de Windows Server de nivel inferior no pueden usar herramientas de administración ni de interfaz de usuario en versiones más recientes de Windows Server.
- Animamos a los clientes a pasar por el proceso de actualización del clúster rápidamente porque algunas características del clúster no están optimizadas para el modo de sistema operativo mixto.
- Evite crear o cambiar el tamaño del almacenamiento en nodos de Windows Server más recientes mientras el clúster se ejecuta en modo de sistema operativo mixto debido a posibles incompatibilidades en la conmutación por error desde un nodo de Windows Server más reciente a nodos de Windows Server de nivel descendente.
Preguntas más frecuentes
¿Cuánto tiempo se puede ejecutar el clúster de conmutación por error en modo de sistema operativo mixto? Animamos a los clientes a completar la actualización en un plazo de cuatro semanas. Hemos actualizado correctamente los clústeres de Hyper-V y servidor de archivos de escalabilidad horizontal sin tiempo de inactividad en menos de cuatro horas en total.
¿Volveréis a migrar esta característica a Windows Server 2012, Windows Server 2008 R2 o Windows Server 2008? No tenemos planes para migrar esta característica a versiones anteriores. La actualización gradual del sistema operativo del clúster es nuestra visión para actualizar clústeres de Windows Server.
¿Los nodos que ejecutan la versión anterior de Windows Server deben tener instaladas todas las actualizaciones de software antes de iniciar el proceso de actualización gradual del sistema operativo del clúster? Sí, antes de iniciar el proceso de actualización gradual del sistema operativo del clúster, compruebe que todos los nodos del clúster se actualizan con las actualizaciones de software más recientes.
¿Puedo ejecutar el Update-ClusterFunctionalLevel
cmdlet mientras los nodos están desactivados o en pausa?
No. Todos los nodos de clúster deben estar activados y estar en pertenencia activa para que el Update-ClusterFunctionalLevel
cmdlet funcione.
¿Funciona la actualización gradual del sistema operativo del clúster para cualquier carga de trabajo de clúster? ¿Funciona para SQL Server? Sí, la actualización gradual del sistema operativo del clúster funciona para cualquier carga de trabajo del clúster. Sin embargo, solo es un tiempo de inactividad cero para los clústeres de Hyper-V y servidor de archivos de escalabilidad horizontal. La mayoría del resto de cargas de trabajo incurren en un tiempo de inactividad (normalmente un par de minutos) cuando se conmutan por error y la conmutación por error es necesaria al menos una vez durante el proceso de actualización gradual del sistema operativo del clúster.
¿Puedo automatizar este proceso mediante PowerShell? Sí, hemos diseñado la actualización gradual del sistema operativo del clúster para automatizarse mediante PowerShell.
En el caso de un clúster grande que tenga capacidad de conmutación por error adicional, ¿puedo actualizar varios nodos simultáneamente? Sí. Cuando se quita un nodo del clúster para actualizar el sistema operativo, el clúster tendrá un nodo menor para la conmutación por error, por lo que tendrá una capacidad de conmutación por error reducida. En el caso de clústeres de gran tamaño con suficiente carga de trabajo y capacidad de conmutación por error, se pueden actualizar varios nodos simultáneamente. Puede agregar temporalmente nodos de clúster al clúster para proporcionar una carga de trabajo mejorada y capacidad de conmutación por error durante el proceso de actualización gradual del sistema operativo del clúster.
¿Qué ocurre si detecto un problema en el clúster después Update-ClusterFunctionalLevel
de que se haya ejecutado correctamente?
Si ha realizado una copia de seguridad de la base de datos del clúster con una copia de seguridad de estado del sistema antes de ejecutar Update-ClusterFunctionalLevel
, debe poder realizar una restauración autoritativa en un nodo que ejecute la versión anterior de Windows Server y restaurar la base de datos y la configuración del clúster original.
¿Puedo usar la actualización local para cada nodo en lugar de usar la instalación de clean-OS (limpiar sistema operativo) al volver a formatear la unidad del sistema? No se recomienda el uso de la actualización local de Windows Server, pero sabemos que funciona en algunos casos en los que se usan controladores predeterminados. Lea detenidamente todos los mensajes de advertencia que se muestran durante la actualización local de un nodo de clúster.
Si uso la replicación de Hyper-V para una máquina virtual de Hyper-V en mi clúster de Hyper-V, ¿la replicación permanecerá intacta durante y después del proceso de actualización gradual del sistema operativo del clúster? Sí, la réplica de Hyper-V permanece intacta durante y después del proceso de actualización gradual del sistema operativo del clúster.
¿Puedo usar System Center Virtual Machine Manager (SCVMM) para automatizar el proceso de actualización gradual del sistema operativo del clúster? Sí, puede automatizar el proceso de actualización gradual del sistema operativo del clúster mediante VMM en System Center.