Si el descubrimiento del nodo activo está habilitado (opción por defecto) para el entorno de PlateSpin, la migración de un clúster de Windows se logra mediante réplicas incrementales de los cambios del nodo activo transmitidas a un clúster de un nodo virtual. Si se inhabilita el descubrimiento del nodo activo, cada nodo de un clúster de Windows puede descubrirse y migrarse como un nodo independiente.
Antes de configurar los clústeres de Windows para su migración, asegúrese de que el entorno cumple los requisitos previos y de que entiende las condiciones para migrar las cargas de trabajo de clúster.
La cobertura de asistencia técnica para la migración del clúster está sujeta a las condiciones descritas en la Tabla 25-1. Tenga en cuenta estos requisitos cuando configure la migración de los clústeres en su entorno de PlateSpin.
Tabla 25-1 Requisitos de migración del clúster
|
Requisito |
Descripción |
|---|---|
|
Descubrir el nodo activo como un clúster de Windows |
El valor de configuración global de PlateSpin DiscoverActiveNodeAsWindowsCluster determina si los clústeres de Windows se migran como clústeres o como equipos independientes:
Consulte Sección 25.2, Configuración de descubrimiento del nodo activo de Windows. |
|
Valores de búsqueda del nombre del recurso |
El valor de configuración global de PlateSpin MicrosoftClusterIPAddressNames determina los nombres de recurso del clúster que se pueden descubrir en el entorno de PlateSpin. debe configurar los valores de búsqueda que permiten diferenciar el nombre del recurso de dirección IP del clúster compartido del nombre de otros recursos de dirección IP que pueda haber en el clúster. Consulte Sección 25.4, Adición de valores de búsqueda de nombres de recursos. |
|
Modo de clúster de Windows |
El valor de configuración global de PlateSpin WindowsClusterMode determina el método de transferencia de datos basada en bloques para las réplicas incrementales:
Consulte lo siguiente. |
|
Nombre de host o dirección IP del nodo activo |
Debe especificar el nombre de host o la dirección del nodo activo del clúster cuando realice una operación Add Workload (Añadir carga de trabajo). Debido a los cambios de seguridad efectuados por Microsoft, los clústeres de Windows ya no se pueden descubrir mediante el nombre del clúster virtual (es decir, con la dirección IP del clúster compartido). |
|
Nombre de host resoluble |
El servidor de PlateSpin también debe ser capaz de resolver el nombre de host de cada nodo del clúster según su dirección IP. NOTA:se requieren una búsqueda directa y una búsqueda inversa de DNS para resolver el nombre de host por su dirección IP. |
|
Recurso de quórum |
es preciso coubicar un recurso de quórum de clúster en el nodo junto al grupo de recursos del clúster (servicio) que se va a migrar. |
|
Similitud de los nodos de clúster |
En el modo de clúster de Windows por defecto, la sincronización sin controlador puede continuar desde cualquier nodo que se convierta en el nodo activo si los nodos son similares. Si no coinciden, las réplicas solo se pueden producir en el nodo activo descubierto originalmente. Consulte Similitud del nodo de clúster. |
|
PowerShell 2.0 |
Windows PowerShell 2.0 debe estar instalado en todos los nodos del clúster. |
La transferencia basada en bloques para los clústeres funciona de forma distinta que para los servidores independientes. La réplica inicial crea una copia completa o bien utiliza un método de sincronización sin controlador en el nodo activo del clúster. Las réplicas incrementales posteriores pueden utilizar un método sin controlador o uno basado en el controlador para la transferencia de datos basada en bloques.
NOTA:PlateSpin Migrate no admite la transferencia basada en archivos para los clústeres.
El valor de configuración global de PlateSpin WindowsClusterMode determina el método de transferencia de datos basada en bloques para las réplicas incrementales:
Por defecto: se usa la sincronización sin controlador con una réplica basada en MD5 en el nodo activo en ese momento.
SingleNodeBBT: se usa la sincronización basada en controlador con un controlador de BBT instalado en el nodo activo descubierto originalmente.
Ambos métodos admiten la réplica de nivel de bloques del almacenamiento local y el almacenamiento compartido en redes SAN Fibre Channel y SAN iSCSI.
En la Tabla 25-2 se describen y se comparan los dos métodos.
Tabla 25-2 Comparación de los métodos de transferencia de datos basada en bloques para la réplica incremental
|
Consideración |
BBT por defecto |
BBT de un solo nodo |
|---|---|---|
|
Método de transferencia de datos |
Se usa la sincronización sin controlador con una réplica basada en MD5 en el nodo activo en ese momento. |
Se usa un controlador BBT instalado en el nodo activo descubierto originalmente. |
|
Rendimiento |
Las réplicas incrementales serán potencialmente lentas. |
Mejora considerablemente el rendimiento de las réplicas incrementales. |
|
Clústeres de Windows admitidos |
Funciona con cualquier clúster compatible de Windows Server. |
Funciona con clústeres de Windows Server 2008 R2 y versiones posteriores. Otros clústeres de Windows compatibles utilizan el método de sincronización sin controlador para la réplica. |
|
Controladores |
|
|
|
Primera réplica incremental |
Se usa la sincronización sin controlador en el nodo activo. |
Si se ha completado una réplica completa después de instalar el controlador BBT, se utiliza una transferencia basada bloques basada en controlador en el nodo activo descubierto originalmente. De lo contrario, se usa una sincronización sin controlador en el nodo activo descubierto originalmente. |
|
Réplicas incrementales posteriores |
Se usa la sincronización sin controlador en el nodo activo. |
Se usa una transferencia basada en bloques basada en controlador en el nodo activo descubierto originalmente. Si un clúster cambia de nodo, el método de sincronización sin controlador se utiliza para la primera réplica incremental después de que el nodo activo original vuelva a ser el nodo activo. Consulte Impacto del failover del nodo de clúster en la réplica. |
En la Tabla 25-3 se describe el impacto de la operación de failover del nodo de clúster en la réplica y las acciones que debe realizar el administrador de Migrate.
Tabla 25-3 Impacto del failover del nodo de clúster en la réplica
|
Failover o failback del nodo de clúster |
BBT por defecto |
BBT de un solo nodo |
|---|---|---|
|
El failover del nodo de clúster se produce durante la primera réplica completa. |
La réplica falla. La primera réplica completa debe completarse correctamente sin un failover del nodo de clúster.
|
|
|
Se produce un failover del nodo de clúster durante una réplica completa posterior o una réplica incremental posterior. |
El comando de réplica se cancela y se muestra un mensaje que indica que es necesario volver a ejecutar la réplica. Si el perfil del nuevo nodo activo es similar al nodo activo erróneo, el contrato de migración continúa siendo válido.
Si el perfil del nuevo nodo activo es similar al del nodo activo erróneo, el contrato de migración solo continúa siendo válido en el nodo activo original.
|
El comando de réplica se cancela y se muestra un mensaje que indica que es necesario volver a ejecutar la réplica. El contrato de migración solo es válido en el nodo activo descubierto originalmente.
Esta primera réplica incremental después de un evento de failover/failback de clúster utiliza automáticamente la sincronización sin controlador. Las réplicas incrementales posteriores utilizarán el controlador basado en bloques, tal y como especifica la BBT de un solo nodo. |
|
El failover del nodo de clúster se produce entre réplicas. |
Si el perfil del nuevo nodo activo es similar al nodo activo erróneo, el contrato de migración continúa según lo planificado para la siguiente réplica incremental. En caso contrario, el comando de la próxima réplica incremental falla. Si se produce un error en una réplica incremental programada:
|
La réplica incremental falla si el nodo activo cambia entre las réplicas.
Esta primera réplica incremental después de un evento de failover/failback de clúster utiliza automáticamente la sincronización sin controlador. Las réplicas incrementales posteriores utilizarán el controlador basado en bloques, tal y como especifica la BBT de un solo nodo. |
En el modo de clúster de Windows por defecto, los nodos de clúster deben tener perfiles similares para evitar interrupciones en el proceso de réplica. Los perfiles de los nodos de clústeres se consideran similares si se cumplen todas las condiciones siguientes:
Los números de serie de los volúmenes locales de los nodos (volumen del sistema y volumen reservado para el sistema) deben ser iguales en cada nodo del clúster.
NOTA:use la utilidad Gestor de volúmenes personalizada para cambiar los números de serie del volumen local a fin de que coincidan en todos los nodos del clúster. Consulte Sincronización de números de serie en el almacenamiento local del nodo de clústeres.
Si los volúmenes locales de cada nodo del clúster tienen números de serie distintos, no será posible ejecutar una réplica después de que se produzca un failover del nodo de clústeres. Por ejemplo, durante un failover del nodo de clústeres, el nodo activo Nodo 1 falla y el software del clúster convierte al Nodo 2 en el nodo activo. Si las unidades locales de los dos nodos tienen números de serie distintos, el comando de la próxima réplica para la carga de trabajo falla.
Los nodos deben tener el mismo número de volúmenes.
Cada volumen debe ser exactamente del mismo tamaño en cada nodo.
Los nodos deben tener un número idéntico de conexiones de red.
Para configurar la migración de un clúster de Windows, siga el flujo de trabajo de migración de la carga de trabajo habitual. Asegúrese de que proporciona el nombre de host o la dirección IP del nodo activo del clúster.
PlateSpin Migrate admite el uso de discos compartidos RDM (asignación de dispositivo en bruto, FC SAN) en máquinas virtuales de destino para la migración semiautomatizada de un clúster de conmutación por error de Windows Server (WSFC) a VMware, donde cada nodo de máquina virtual de destino se encuentra en un host distinto en un clúster de VMware. Consulte Migración avanzada de clústeres de Windows a máquinas virtuales VMware con discos RDM.