Consideración sobre la migración de grupos principales

En la Versión 6 y posteriores se incluye el gestor de alta disponibilidad y las funciones del grupo principal. En este tema se describen las consideraciones sobre configuración y topología de los grupos principales que pueden suponer un impacto en la migración desde una versión del producto que no contiene esta función como, por ejemplo, la Versión 5.1.

Antes de leer de este artículo, debe comprender los conceptos de grupo principal básico contenidos en los temas siguientes:
  • High Availability Manager
  • Cuándo se debe utilizar el gestor de alta disponibilidad
  • Grupos principales
  • Transportes de grupo principal
  • Coordinador de grupos principales
  • Consideración sobre la administración de grupos principales
  • Consideraciones sobre el escalado de grupos principales

Debido a que es posible que sea necesario realizar las actividades de planificación y migración especiales para su entorno, antes de migrar desde una versión del producto que no tiene un gestor de alta disponibilidad a uno que tiene un gestor de alta disponibilidad, debe saber las respuestas a las preguntas siguientes:

Actividades de migración relacionadas con el grupo principal por omisión

Las actividades relacionadas con el grupo principal por omisión que se realizan automáticamente durante el proceso de migración son relativamente simples y directas. Cuando realiza la migración desde un entorno de la Versión 5.x a un entorno de la Versión 7.0.x, se efectúan las acciones siguientes en el orden indicado:
  1. El gestor de despliegue se migra a la Versión 7.0.x.
  2. Durante el proceso de migración, se crean un perfil del gestor de despliegue de la Versión 7.0.x y un grupo principal denominado DefaultCoreGroup.
  3. El nuevo proceso del gestor de despliegue se añade a DefaultCoreGroup.
  4. Los nodos de la versión 5.x se migran de uno en uno a la versión 7.0. A medida que se migra cada uno de los nodos, el agente del nodo y los servidores de aplicaciones del nodo que se está migrando se añaden a DefaultCoreGroup.

Cuando finaliza la migración, todos los procesos de la célula de la Versión 5.x son miembros del grupo DefaultCoreGroup de la Versión 7.0.x. Dado que DefaultCoreGroup se configura con los valores predeterminados para todos los valores, el proceso de migración no configura los servidores del coordinador preferido y no realiza una partición del coordinador entre varios servidores. El proceso de migración tampoco crea nuevas políticas de alta disponibilidad ni proporciona ninguna alteración temporal de la configuración de las propiedades personalizadas.

Planificación de la topología del grupo principal

Para la mayor parte de las topologías de la Versión 5.x, una migración por omisión proporciona una topología del grupo principal de la Versión 7.0.x adecuada y con la que se puede trabajar. En algunos casos, es posible que deba realizar algunos cambios ligeros en la topología como, por ejemplo, el transporte que no es el transporte por omisión, o que deba configurar el grupo principal para la duplicación. Si la célula de la Versión 5.x es lo suficientemente grande como para necesitar varios grupos principales en la topología de la Versión 7.0.x, entonces debe realizar más tareas de planificación antes de iniciar el proceso de migración para impedir que falten aplicaciones cuando realiza cambios en la configuración de los grupos principales.

Migrar una célula de gran tamaño de la Versión 5.x a la Versión 7.0.x, en la que se necesitan varios grupos principales, puede resultar una tarea compleja. Cuando la topología de la Versión 7.0.x requiere varios grupos principales, tiene varios modos de proceder sobre cómo y cuándo ha de particionar la célula en varios grupos principales. El método que elija debe estar basado en factores como, por ejemplo, el número de procesos de la célula y los requisitos para la disponibilidad continua de las aplicaciones. Por ejemplo, aunque la recomendación habitual es mantener los grupos principales en aproximadamente 50 miembros, el límite práctico es ligeramente superior a los 50. Para las topologías con un número reducido de aplicaciones instaladas en las máquinas del extremo superior (CPU de gran tamaño con mucha memoria), es posible que tenga grupos principales de hasta 200 miembros. Si hay 150 procesos en la célula y la disponibilidad de las aplicaciones no es un problema, una opción puede ser simplemente migrar toda la célula a la Versión 7.0.x y luego crear grupos principales adicionales. Si la disponibilidad de las aplicaciones es un problema, debe crear grupos principales adicionales durante el proceso de migración, de modo que no tenga que detener y reiniciar los miembros del grupo principales una vez completado el proceso de migración.

Tamaño del grupo principal
La consideración de planificación más importante es el tamaño del grupo principal. De forma predeterminada, normalmente hay un grupo principal por célula. Debido a que los grupos principales no se escalan en tamaños grandes, si la célula de la Versión 5.x es grande, es posible que desee crear grupos principales adicionales para la topología de la Versión 7.0.x. Es posible que tenga que configurar puentes de grupo principal si estos diferentes grupos principales se han de comunicar entre sí.
Transporte del grupo principal
Se modifica la configuración del transporte del grupo principal, todos los miembros del grupo principal se deben reiniciar para que los cambios entren en vigor. Por lo tanto, es necesario planificar para minimizar el efecto de modificar el transporte. Si se modifica el transporte para DefaultCoreGroup, el mejor momento para cambiarlo es inmediatamente después de migrar el gestor de despliegue, ya que en ese momento sólo será necesario reiniciar el gestor de despliegue. Si se crean otros grupos principales, entonces el transporte se debe configurar correctamente a medida que se crean los nuevos grupos principales.
Alteraciones temporales de la configuración de las propiedades personalizadas
Se pueden modificar los parámetros de configuración de los grupos principales mediante las alteraciones temporales de las propiedades personalizadas. Las alteraciones temporales de las propiedades personalizadas están documentadas en los artículos del centro de información de esta sección.

Cuando se añade, elimina o modifica una alteración temporal de las propiedades personalizadas, todos los miembros del grupo principal deben reiniciarse para poder recoger el cambio. Por lo tanto, es necesario planificar para minimizar el efecto de modificar las propiedades personalizadas. Si se deben modificar las propiedades personalizadas para DefaultCoreGroup, el mejor tiempo para modificarlas es inmediatamente después de la migración del gestor de despliegue. Si se crean otros grupos principales, entonces se deben modificar las propiedades personalizadas a medida que se crean nuevos grupos principales.

Coordinador de grupos principales
La configuración de los servidores del coordinador preferido es un método recomendado. Dado que el gestor de alta disponibilidad puede volver a leer y aplicar de forma dinámica los cambios en la configuración del coordinador del grupo principal, no es necesario reiniciar todos los miembros del grupo principal para recoger este cambio.

Ejemplo: migración de una célula de gran tamaño

El ejemplo siguiente ilustra algunos de los procesos de pensamiento que debe recorrer a medida que planifica y ejecuta la migración de una célula de la Versión 5.x de gran tamaño a la Versión 7.0.x, en el que son necesarios varios grupos principales. Para fines de este ejemplo, presuponga que la célula de la Versión 5.x tiene las características de topología siguiente:

  • La célula contiene ocho nodos, cuyos nombres son Node1, Node2, Node3, ..., Node8, sin incluir el nodo del gestor de despliegue.
  • La célula contiene diez clústeres, cuyos nombres son Cluster1, Cluster2, Cluster3, ..., Cluster10.
  • Cada uno de los clústeres Cluster1 al Cluster9 contiene 32 servidores de aplicaciones. Los miembros del clúster para estos clústeres se distribuyen de forma simétrica, cuatro servidores de aplicaciones por nodo, entre todos los nodos
  • El Cluster10 contiene 28 servidores de aplicaciones. El Cluster10 no tiene ningún servidor de aplicaciones en Node1. Los servidores de aplicaciones para Cluster10 se distribuyen simétricamente, cuatro servidores de aplicaciones por nodo, entre los nodos Node2 al Node8.
  • Hay un total de 316 servidores de aplicaciones, 8 agentes de nodos y un gestor de despliegue en la célula.
  • Cada clúster tiene una aplicaciones desplegada en el mismo que utiliza los EJB. Y estas aplicaciones se pueden comunicar entre sí. Por lo tanto, la información del direccionamiento WLM (Work Load Management) debe estar disponible en todos los lugares de la célula.
  • Las aplicaciones deben estar disponibles de forma continuada durante la migración.
  • La migración se lleva a cabo durante un período de días o semanas.

Las primeras cosas que se han de tener en cuenta para planificar la topología del grupo principal de la Versión 7.0.x es que esta célula contiene 325 procesos y la disponibilidad continuada de las aplicaciones es un requisito. Estos factores nos impiden migrar simplemente toda la célula y luego volver a configurar los grupos principales. Debe distribuir los procesos contenidos en la célula entre los diferentes grupos principales como parte del proceso de migración.

Cuando determine cómo desea distribuir los procesos de la célula de la Versión 5.x entre el grupo principal nuevo, asegúrese de que cada grupo principal se adhiera a las siguientes reglas del grupo principal:

  • Cada grupo principal debe contener al menos un proceso administrativo. Debido a que la célula de este ejemplo tiene nueve procesos administrativos, ocho agentes de nodo y un gestor de despliegue, el número máximo de grupos principales posibles en este topología es de nueve.
  • Todos los miembros de un clúster deben ser miembros del mismo grupo principal.
  • El número de procesos contenidos en cada grupo principal no debe superar el tamaño recomendado de aproximadamente 50 miembros.
Siguiendo las reglas de este ejemplo:
  • Al menos uno de los grupos principales debe contener dos clústeres porque sólo puede dividir la célula en un máximo de nueve grupos principales y hay diez clústeres en la célula de la Versión 5.x.
  • Cualquiera de los grupos principales que contenga varios clústeres, tendrá más de 50 miembros debido a que cada clúster contiene entre 28 ó 32 servidores de aplicaciones.

Aunque el número de miembros en al menos uno de los grupos principales superará el limite recomendado, el número de miembros está dentro del límite práctico y no debe suponer un problema.

Dado que las aplicaciones de este ejemplo requieren la información de direccionamiento WLM para cada clúster contenido en la célula, se deben configurar los puentes de los grupos principales de modo que permitan la comunicación entre todos los grupos principales. Consulte los temas sobre el puente de grupo principal si no está familiarizado con el modo de configurar un puente de grupo principal. Una topología correcta de puente de grupo principal para este ejemplo incluye:

  • Un punto de acceso de grupo principal para cada grupo principal. Cada punto de acceso contiene el conjunto de procesos que proporciona las interfaces puente para el grupo principal. Las interfaces puente son procesos que en la práctica se comunican con los procesos de otros grupos principales.
  • Dos interfaces puente para cada punto de acceso para eliminar el puente de grupo principal como un solo punto de anomalía. Estas dos interfaces puente también se colocarán en nodos diferentes para garantizar adicionalmente la disponibilidad continua.

    Cuando seleccione los procesos que servirán como interfaces puente, recuerde que las interfaces puente necesitan memoria adicional y ciclos de CPU. Normalmente los agentes de nodo son buenos procesos para utilizarlos como interfaces puente ya que durante las operaciones normales, un agente de nodo tiene una carga de trabajo inferior que un servidor de aplicaciones o el gestor de despliegue.

    No obstante, en este ejemplo sólo hay ocho agentes de nodo disponibles que sirvan como interfaces puente. Debido a que la topología desea dos interfaces puente por punto de acceso, si únicamente utiliza agentes de nodo como interfaces puente, queda limitado a cuatro puntos de acceso y, por consiguiente, a cuatro grupos principales. Por lo tanto, antes de comenzar el proceso de migración, es posible que desee crear ocho servidores autónomos que actúen específicamente como interfaces puente y que no alojen aplicaciones. De este modo, cada punto de acceso puede contener un agente de nodo y un servidor de interfaz de puente autónomo. Esta configuración le proporciona un total de ocho puntos de acceso y ocho grupos principales.

  • Un grupo individual de puntos de acceso de grupos principales que puede contener todo el punto de acceso. Un grupo individual de puntos de acceso de grupos principales garantiza que todos los procesos de las interfaces puente se comuniquen directamente. Estas interfaces puente constituyen una red totalmente conectada.

    Una topología alternativa es utilizar varios grupos de puntos de acceso, lo que da como resultado una topología en cadena. En una topología en cadena la comunicación se dirige de una interfaz puente a otra a través de las interfaces puente intermedias de la cadena.

Ahora que ha determinado la configuración de las interfaces de puente del grupo principal, está listo para decidir cómo ha de distribuir los diez clústeres, ocho agentes de nodo, ocho servidores de interfaces de puente autónomas y el gestor de despliegue entre los ocho grupos principales. Es recomendable distribuir los procesos del modo más equitativo posible entre los ocho grupos principales. La topología siguiente es un buen ejemplo de cómo se distribuye equitativamente el proceso contenido en la célula de la Versión 5.x:

  • El primer grupo principal, DefaultCoreGroup, contiene el gestor de despliegue, el agente del nodo de Node1, el servidor de puente de Node2 y Cluster1.
  • El grupo principal 2 contiene el agente de nodo de Node2, el servidor de puente de Node3 y Cluster2
  • El grupo principal 3 contiene el agente de nodo de Node3, el servidor de puente de Node4 y Cluster3

No es necesario modificar el transporte por omisión de este ejemplo.

Dado que este ejemplo no indica que necesitará más de un coordinador por grupo principal, puede dejar el valor del coordinador en el valor predeterminado de 1. No obstante, es posible que desee que el servidor autónomo de la interfaz de puente, contenido en cada grupo principal, sea el servidor de coordinador preferido para dicho grupo principal. Esta designación mantiene inicialmente la carga de trabajo necesaria de un coordinador fuera de los servidores de aplicaciones agrupados en clúster que están ejecutando las aplicaciones.

El plan de migración

Si, después de revisar el ejemplo anterior y completar el proceso de planificación inicial para la célula que está migrando, determina que el flujo de migración por omisión no es el correcto para la topología de la Versión 7.0.x de destino, ha llegado el momento de desarrollar un plan o un mapa de guía para el proceso de migración real. Este plan debe incluir todos los pasos adicionales relacionados con el grupo principal necesarios para migrar de la versión 5.x a la versión 7.0. y respuestas a las preguntas siguientes:

¿Cuándo creará los nuevos grupos principales?
El mejor momento de crear los nuevos grupos principales es inmediatamente después de que se complete la migración del gestor de despliegue. A medida que se crean los nuevos grupos principales, debe configurar las propiedades personalizadas mencionadas anteriormente. Puede utilizar la consola administrativa o el mandato wsadmin createCoreGroup para crear los nuevos grupos principales. No obstante, debe utilizar la consola administrativa para configurar las propiedades personalizadas.
¿Qué acciones necesita realizar a medida que se migran los nodos?
A medida que se migran los nodos, debe:
  • Crear el nuevo servidor de aplicaciones autónomo que va a ser una de las interfaces de puente del grupo principal.
  • Ajustar el tamaño del almacenamiento intermedio de transporte en todos los procesos del nodo. Un script es la mejor opción para realizar esta acción.
  • Ajuste el tamaño del almacenamiento intermedio en el agente de nodo y el servidor autónomo y active GC en modalidad verbosa para estos procesos.
Todos estos cambios se deben completar antes de reiniciar el nodo migrado. Puede utilizar la consola administrativa para llevarlos a cabo y luego realizar una sincronización manual de la configuración de los nodos antes de reiniciar el agente de nodo y los servidores de aplicaciones.
¿Cuándo y cómo se mueven los procesos a los nuevos grupos principales?
De forma predeterminada, el proceso de migración coloca todos los procesos en el grupo principal denominado DefaultCoreGroup. En algún momento, el número de miembros contenidos en este grupo principal superará los límites de tamaño y debe volver a distribuir los procesos a otros grupos principales. Es importante comprender que los procesos se deben detener para poder moverlos. Si se necesita una disponibilidad continuada de las aplicaciones, debe planificar detenidamente el orden en que moverá los procesos a los diferentes grupos principales.

Puede utilizar la consola administrativa o el mandato wsadmin moveServerToCoreGroup para mover el gestor de despliegue, los agentes de nodo y el servidor de aplicaciones autónomo.

Mover los servidores de aplicaciones agrupados en clúster resulta más complicado. En circunstancias normales, puede utilizar la consola administrativa o el mandato wsadmin moveServerToCoreGroup para mover los clústeres. No obstante, durante el proceso de migración, debido a que el clúster que se ha de mover puede tener miembros de la Versión 7.0.x o de la Versión 5.x, los mandato normales fallan debido a que el miembro del clúster de la Versión 5.x todavía no es un miembro de ningún grupo principal. Para mover un clúster mixto a un nuevo grupo principal, debe utilizar el mandato wsadmin moveClusterToCoreGroup con el parámetro checkConfig opcional.

Por ejemplo, suponga que Cluster0 tiene los miembros de clúster A, B, C y D. El miembro A esta en un nodo que se ha migrado a la Versión 7.0.x y es miembro de DefaultCoreGroup, mientras B, C y D continúan en los nodos de la Versión 5.x. Para mover Cluster0 al grupo principal CG1 utilice el mandato siguiente"
$AdminTask moveClusterToCoreGroup {-source CoreGroup1 –target CG1
     –clusterName Cluster0 –checkConfig false}

Cuando se migra un servidor de aplicaciones agrupado en clúster, los programas de utilidad de migración determinan si otros miembros del clúster ya se han migrado y coloca el miembro que se está migrando en el mismo grupo principal que los otros miembros del mismo clúster que ya se han migrado.

En el ejemplo anterior, el miembro A se ha movido al grupo principal CG1. Cuando se migran los nodos que contienen B, C y D , la migración colocará estos miembros de clúster en CG1, en lugar de en DefaultCoreGroup. Por lo tanto, es necesario ejecutar el mandato moveClusterToCoreGroup únicamente una vez para cada clúster.

¿Cuándo necesita configurar los puentes de grupo principal?
En el momento que mueve los procesos a varios grupos principales, debe tener configurados y en ejecución los puentes de grupo de principal. Esto significa que es posible que los procesos que desea utilizar como interfaces puente en la topología de destino de la Versión 7.0.x no estén disponibles cuando se necesitan inicialmente debido a que no se han migrado desde los nodos de la Versión 5.x. Por lo tanto, para garantizar la disponibilidad continuada de las aplicaciones, debe configurar algunos servidores de aplicaciones agrupados en clúster para que sirvan como interfaces puente temporales mientras continúa la migración. Después de que se hayan migrado todos los procesos a la Versión 7.0.x, puede ajustar la configuración del puente de grupo principal de modo que coincida con la topología deseada de la Versión 7.0.x.

Otras consideraciones de planificación

Si la configuración de la Versión 7.0 requiere varios puentes de grupo principal, utilice la propiedad personalizada de grupo principal IBM_CS_WIRE_FORMAT_VERSION para implementar las mejoras de escalado.

Asimismo, si todos los grupos principales están enlazados entre sí mediante puentes y la información compartida se direcciona entre los mismos, la cantidad de datos compartidos entre los miembros del grupo principal probablemente sea mucho mayor de lo normal. Por lo tanto, debe utilizar los siguientes valores para aumentar los valores de memoria del grupo principal de modo que permitan una transferencia de los datos más eficaz:

  • Establezca IBM_CS_DATASTACK_MEG en 100
  • Establezca el tamaño del almacenamiento intermedio de transporte en todos los procesos a 100.

También debe considerar el ajuste de factores como, por ejemplo, los tamaños del almacenamiento dinámico de la JVM para cualquier agente de nodo o servidor de aplicaciones que se esté utilizando como una interfaz puente y cualquier servidor autónomo que se esté utilizando como coordinador. Un punto de inicio recomendado es aumentar el tamaño del almacenamiento dinámico en 512 megabytes. Asimismo, puede activar la supervisión de GC en modalidad verbosa para estos procesos, de modo que pueda ajustar con precisión estos tamaños de almacenamiento dinámico con el tiempo.

Flujos de migración posibles

Hay varios flujos de migración que puede implementar para que la migración se realice correctamente. Los siguientes flujos presuponen un punto de inicio común en el que se ha completado la migración del gestor de despliegue y se han creado los grupos principales pero no se han realizado acciones adicionales.

Flujo de migración 1
En este flujo, se siguen estrictamente las reglas. Este flujo no es satisfactorio por diferentes motivos. A medida que se migra cada nodo, no es necesario mover los clústeres. Esto requiere detener todos los miembros del clúster. Esto puede implicar que las aplicaciones no estén disponibles. Asimismo, es necesario volver a configurar los puentes en cada paso.
  • Migrar Node1. DefaultCoreGroup contiene el gestor de despliegue y todos los procesos de Node1. Dado que DefaultCoreGroup contiene menos de 50 miembros, no es necesario realizar ninguna acción adicional.
  • Migrar Node2. Ahora DefaultCoreGroup contiene más del número de procesos recomendados. Equilibre los procesos de más de 2 grupos principales moviendo la mitad de los clústeres y el agente de nodo para Node2 en CoreGroup2. Dado que ahora se están utilizando varios grupos principales, se ha de configurar el puente del grupo principal. Cree los servidores de la interfaz puente en los nodos Node1 y Node2. Configure el puente de grupo principal de modo que sirva de puente de los dos grupos principales.
  • Migrar Node3. Equilibre los procesos entre los 3 grupos principales moviendo uno de los clústeres de DefaultCoreGroup y CoreGroup2 a CoreGroup3. Mueva el agente de nodo para Node3 a CoreGroup3. Cree el servidor de la interfaz puente en Node3. Vuelva a configurar el puente de grupo principal de modo que sirva de puente entre los tres grupos principales.
  • Continúe migrando los nodos hasta que se complete la migración. A medida que se migra cada nodo, es posible que sea necesario volver a equilibrar y configurar el puente de grupo principal.
Flujo de migración 2
En este flujo, se rompen temporalmente las reglas. Este flujo presenta mejores resultados ya que los servidores de aplicaciones no se han de detener para moverlos a un grupo principal diferente. Mientras la migración está en proceso, algunos grupos principales no contendrán un proceso administrativo durante algún período de tiempo. Esta es una violación técnica de las reglas, pero resulta aceptable siempre que la configuración del grupo principal no se modifique mientras la migración esté en proceso.
  • Migrar Node1. Node1 contiene miembros de todos los clústeres excepto de Cluster10
  • Mueva todos los clústeres posibles al grupo principal identificado en la topología de destino final. El gestor de despliegue, el agente de nodo para Node1 y Cluster1, ya están en DefaultCoreGroup, por lo tanto, no se requiere ninguna acción adicional de los mismos. Mueva Cluster2 a CoreGroup2, Cluster3 a CoreGroup3 y así sucesivamente. Cree el servidor de puente para Node1 y colóquelo en CoreGroup2.
  • Configure el puente de grupo principal de modo que sirva de puente para los ocho grupos principales. Para simplificar las cosas, configuraremos temporalmente una interfaz puente individual para cada punto de acceso. Esto introducirá un solo punto de anomalía mientras la migración está en proceso. Dado que la mayor parte de las interfaces puente de la topología final continúan en la Versión 5.x, será necesario utilizar servidores de aplicaciones como interfaces puente temporales en 6 de los 8 grupos principales. Esto puede requerir que se aumente el tamaño del almacenamiento dinámico de los servidores de aplicaciones.
  • Migrar Node2. La migración moverá automáticamente los servidores de aplicaciones agrupados en clúster para Node2 a los grupos principales correctos. Ya que cluster10 no tenía servidores de aplicaciones en Node1, mueva manualmente Cluster10 a CoreGroup8. Mueva el agente de nodo para Node2 a CoreGroup2. Cree el servidor de puente en Node2. Opcionalmente, vuelva a configurar el puente de grupo principal de modo que algunos servidores de la interfaz puente temporal estén en Node2 como ayuda para distribuir la carga entre ambos nodos.
  • Continúe migrando los nodos utilizando el mismo patrón hasta que todos los nodos se hayan migrado.
  • Cuando se hayan migrado todos los nodos, configure los servidores del coordinador preferido. Vuelva a configurar las interfaces puente de modo que coincidan con la topología de destino final (con los dos servidores de interfaz puente en cada punto de acceso). Detenga y reinicie los servidores que se han utilizado como interfaces puente temporales. Reinicie los nuevos servidores de la interfaz puente.
Flujo de migración 3
Este flujo es una variación del Flujo 2. Como se ha indicado, este flujo es una variación del Flujo 2, pero su ventaja es que la carga del puente inicial se distribuye entre los tres nodos, en lugar de en 1. La desventaja es que la redistribución inicial de los clústeres en grupos principales se lleva a cabo después de migrar Node3. Esto significa que para moverlos es necesario que se detengan los servidores que se ejecutan en los nodos Node1 y Node2. Esto puede afectar la disponibilidad de las aplicaciones.
  • Migrar Node1. Cuando se completa este paso, DefaultCoreGroup contendrán 38 procesos, lo que está dentro de sus límites.
  • Migrar Node2. Cuando se completa este paso, DefaultCoreGroup contendrá 79 procesos. Aunque esto es mayor del tamaño recomendado, está dentro del límite práctico.
  • Migrar Node3. Mueva todos los clústeres al grupo principal identificado en la topología final. Mueva Cluster2 a CoreGroup2, Cluster3 a CoreGroup3 y así sucesivamente. Mueva los tres agentes de nodo a los grupos principales correctos. Cree y mueva los tres servidores de la interfaz puente a los grupos principales adecuados.
  • Seleccione los servidores de aplicaciones agrupados en clúster para que actúen como puentes temporales para los grupos principales que todavía no contienen interfaces puente designadas. Temporalmente ajuste los tamaños del almacenamiento dinámico de estos servidores. Configure el puente de grupo principal de modo que sirva de puente para los ocho grupos principales.
  • Continúe migrando los nodos hasta que todos los nodos se hayan migrado.
  • Cuando se hayan migrado todos los nodos, configure los coordinadores preferidos. Vuelva a configurar las interfaces puente de modo que coincidan con la topología de destino final. Detenga y reinicie los procesos según sea necesario.

Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_ha_cgmigration
File name: crun_ha_cgmigration.html