Considerações sobre Migração do Grupo Principal
A funcionalidade de gerenciador de alta disponibilidade e grupo principal é oferecida na Versão 6 e superior. Este tópico discute as considerações de topologia e configuração de grupo principal que poderão impactar sua migração se você estiver migrando de uma versão do produto que não contém essa funcionalidade, como a Versão 5.1.
- Gerenciador de Alta Disponibilidade
- Ao Utilizar um Gerenciador de Alta Disponibilidade
- Grupos principais
- Transportes do Grupo Principal
- Coordenador do Grupo Principal
- Considerações sobre Administração do Grupo Principal
- Considerações sobre Escalonamento do Grupo Principal
Como atividades especiais de planejamento e migração podem ser necessárias em seu ambiente, antes de migrar de uma versão do produto que não tenha um gerenciador de alta disponibilidade para um que o tenha, você deverá conhecer as respostas às seguintes perguntas:
- Qual é a configuração e a topologia apropriadas de grupo principal para uma célula depois que ela for totalmente migrada para a Versão 7.0?
- Em um ambiente misto, a célula da Versão 5.x é configurada para utilizar a replicação de memória para memória? Se for, como o ambiente de replicação é migrado? Como a replicação é afetada durante o processo de migração?
- Qual provedor JMS, se houver, é utilizado na célula da Versão 5.x?
- Qual, se houver, provedor JMS é utilizado na célula da Versão 7.0?
- Se o provedor de sistemas de mensagens IBM® padrão da Versão 7.0 será utilizado na célula da Versão 7.0, o provedor de sistemas de mensagens deverá ser configurado para se tornar altamente disponível?
- A recuperação do log de transações deverá ser configurada na célula da Versão 7.0?
Atividades de Migração Relacionadas ao Grupo Principal Padrão
- O gerenciador de implementação é migrado para a Versão 7.0.
- Durante o processo de migração, um perfil do gerenciador de implementação da Versão 7.0 e um grupo principal denominado DefaultCoreGroup são criados.
- O novo processo do gerenciador de implementação é incluído no DefaultCoreGroup.
- Os nós da Versão 5.x são migrados um por um para a Versão 7.0. Conforme cada nó é migrado, o agente do nó e os servidores de aplicativos no nó da migração são incluídos no DefaultCoreGroup.
Quando a migração for concluída, todos os processos na célula da Versão 5.x serão membros do DefaultCoreGroup da Versão 7.0. Como o DefaultCoreGroup é configurado com os valores padrão para todas as configurações, o processo de migração não configura servidores do coordenador preferidos e não particiona o coordenador em vários servidores. O processo de migração também não cria novas políticas de alta disponibilidade e não fornece nenhuma substituição de configuração de propriedade customizada.
Planejando a Topologia do Grupo Principal
Na maioria das topologias da Versão 5.x, uma migração padrão gera uma topologia de grupo principal da Versão 7.0 apropriada e funcional. Em alguns casos, pode ser necessário fazer alterações menores na topologia, como configurar um transporte não-padrão ou configurar o grupo principal para replicação. Se a célula da Versão 5.x for grande o suficiente para exigir vários grupos principais na topologia da Versão 7.0, um maior planejamento deverá ser feito antes de iniciar o processo de migração, a fim de impedir que ocorram interrupções de aplicativos ao fazer alterações na configuração do grupo principal.
A migração de uma célula grande da Versão 5.x para a Versão 7.0, na qual vários grupos principais são exigidos, pode ser uma tarefa complexa. Quando a topologia da Versão 7.0 requer vários grupos principais, você tem várias opções de como e quando particionar a célula em vários grupos principais. A abordagem tomada deve ser baseada em fatores como o número de processos na célula e os requisitos para disponibilidade contínua de aplicativos. Por exemplo, enquanto a recomendação normal é manter os grupos principais em torno de 50 membros, o limite prático é um pouco maior que 50. Para topologias com um número pequeno de aplicativos instalados em máquinas de high end (CPUs grandes com muita memória), você pode conseguir ter grupos principais de até 200 membros. Se houver 150 processos na célula e a disponibilidade do aplicativo não for problema, uma opção poderá ser simplesmente migrar a célula inteira para a Versão 7.0 e, em seguida, criar grupos principais adicionais. Se a disponibilidade de aplicativos for um problema, será necessário criar os grupos principais adicionais durante o processo de migração para que você não tenha que parar e reiniciar membros do grupo principal depois que o processo de migração for concluído.
- Tamanho do Grupo Principal
- A consideração mais importante sobre planejamento é o tamanho do grupo principal. Por padrão, há normalmente um grupo principal por célula. Como os grupos principais não são dimensionados para tamanhos grandes, se a célula da Versão 5.x for grande, convém criar grupos principais adicionais para a topologia da Versão 7.0. Talvez seja necessário também configurar pontes de grupos principais se esses vários grupos principais precisarem se comunicar uns com os outros.
- Transporte do Grupo Principal
- Se for feita uma alteração na configuração de transporte do grupo principal, todos os membros do grupo principal deverão ser reiniciados antes que a alteração entre em vigor. Portanto, o planejamento é requerido para minimizar o efeito da alteração do transporte. Se o transporte para o DefaultCoreGroup for alterado, a melhor hora para alterá-lo será imediatamente depois de migrar o Deployment Manager, desde que nesse momento apenas o Deployment Manager precise ser reiniciado. Se outros grupos principais forem criados, o transporte deverá ser configurado de forma adequada conforme os novos grupos principais forem criados.
- Substituições na Configuração de Propriedade Customizada
- Vários parâmetros de configuração do grupo principal podem ser alterados através
de substituições da Propriedade Customizada. As substituições disponíveis da propriedade customizada são documentadas em outros artigos do Centro de Informações nesta seção.
Sempre que uma substituição da Propriedade Customizada for incluída, removida ou alterada, todos os membros do grupo principal deverão ser reiniciados para que a alteração seja efetivada. Portanto, o planejamento é requerido para minimizar o efeito da alteração das Propriedades Customizadas. Se as Propriedades Personalizadas tiverem que ser alteradas porque o DefaultCoreGroup é alterado, a melhor hora para alterá-las será imediatamente depois de migrar o Deployment Manager. Se outros grupos principais forem criados, as Propriedades Personalizadas deverão ser alteradas conforme os novos grupos principais forem criados.
- Coordenador do Grupo Principal
- A configuração de servidores preferidos do coordenador é uma boa prática. Como o HA Manager pode reler e aplicar dinamicamente alterações na configuração do coordenador do grupo principal, um reinício de todos os membros do grupo principal para efetivar essa alteração não é requerido
Exemplo: Uma Migração de Célula Grande
O exemplo a seguir ilustra alguns processos cogitados pelos quais você deverá passar conforme planeja e executa a migração de uma célula grande da Versão 5.x para a Versão 7.0, onde vários grupos principais são necessários. Para propósito deste exemplo, suponha que sua célula da Versão 5.x tenha as seguintes características de topologia:
- A célula contém oito nós, que são denominados Node1, Node2, Node3, ..., Node8, não incluindo o nó do gerenciador de implementação.
- A célula contém dez clusters, que são denominados Cluster1, Cluster2, Cluster3, ..., Cluster10.
- Os clusters do Cluster1 ao Cluster9 contêm, cada um, 32 servidores de aplicativos. Os membros de cluster para esses clusters são distribuídos simetricamente, quatro servidores de aplicativos por nó, em todos os nós
- O Cluster10 contém 28 servidores de aplicativos. O Cluster10 não tem nenhum servidor de aplicativos no Node1. Os servidores de aplicativos para o Cluster10 são distribuídos simetricamente, quatro servidores de aplicativos por nó, nos nós do Node2 ao Node8.
- Há um total de 316 servidores de aplicativos, 8 agentes do nó e um gerenciador de implementação na célula.
- Cada cluster tem um aplicativo implementado para ele que utiliza EJBs. e esses aplicativos podem se comunicar uns com os outros. Portanto, as informações de roteamento do WLM (Work Load Management) devem estar disponíveis em todo lugar na célula.
- Os aplicativos devem estar continuamente disponíveis durante a migração.
- A migração é executada sobre um período de dias ou semanas.
O primeiro item a ser considerado no planejamento da topologia de grupos principais da Versão 7.0 é que essa célula contém 325 processos, e que a disponibilidade contínua de aplicativos é um requisito. Esses fatores nos impedem de simplesmente migrar a célula inteira e, em seguida, reconfigurar os grupos principais. É necessário distribuir os processos contidos na célula entre vários grupos principais como parte do processo de migração.
Ao determinar como você deseja distribuir os processos da célula V5.x entre o novo grupo principal, certifique-se de que cada grupo principal aceite as seguintes regras do grupo principal:
- Cada grupo principal deve conter pelo menos um processo administrativo. Como a célula neste exemplo tem nove processos administrativos, 8 agentes do nó e o gerenciador de implementação, o número máximo de grupos principais possíveis nessa topologia é nove.
- Todos os membros de um cluster devem ser membros do mesmo grupo principal.
- O número de processos contidos em cada grupo principal não deve exceder o tamanho recomendado de aproximadamente 50 membros.
- Pelo menos um dos grupos principais deve conter dois clusters, pois é possível dividir a célula em apenas um máximo de nove grupos principais e há dez clusters na célula V5.x.
- Algum dos grupos principais que contêm vários clusters terá mais que 50 membros, pois cada cluster contém 28 ou 32 servidores de aplicativos.
Enquanto o número de membros em pelo menos um grupo principal irá exceder o limite recomendado, o número de membros está bem dentro do limite prático e não deverá criar um problema.
Como os aplicativos neste exemplo requerem as informações de roteamento do WLM para cada cluster contido na célula, as pontes do grupo principal devem ser configuradas para permitir a comunicação entre todos os grupos principais. (Consulte os tópicos de ponte do grupo principal se não estiver familiarizado com como configurar uma ponte do grupo principal.) Uma topologia de ponte do grupo principal apropriada para este exemplo inclui:
- Um ponto de acesso do grupo principal para cada grupo principal. Cada ponto de acesso contém o conjunto de processos que fornecem as interfaces de ponte para o grupo principal. As interfaces de ponte são os processos que realmente se comunicam com processos em outros grupos principais.
- Duas interfaces de ponte para cada ponto de acesso para eliminar a ponte do
grupo principal como um único ponto de falha. Essas duas interfaces de ponte também serão
colocadas em diferentes nós para garantir melhor a disponibilidade contínua.
Quando selecionar processos para servir como interfaces de ponte, lembre-se de que as interfaces de ponte precisam de memória extra e ciclos de CPU. Normalmente, os agentes do nó são bons processos para utilizar como interfaces de ponte porque durante operações normais um agente do nó tem uma carga de trabalho menor que um servidor de aplicativos ou o gerenciador de implementação.
Porém, neste exemplo há apenas oito agentes do nó disponíveis para servir como interfaces de ponte. Como a topologia deseja duas interfaces de ponte por ponto de acesso, se utilizar apenas agentes do nó como interfaces de ponte, você estará limitado a quatro pontos de acesso e, subsequentemente, quatro grupos principais. Portanto, antes de iniciar o processo de migração, você poderá desejar criar oito servidores independentes, para agirem especificamente como interfaces de ponte, e não aplicativos de host. Então, cada ponto de acesso pode conter um agente do nó e um servidor de interface de ponte independente. Esta configuração dá um total de oito pontos de acesso e oito grupos principais.
- Um único grupo de pontos de acesso do grupo principal que contém todos os pontos
de acesso. Um único grupo de pontos de acesso do grupo principal garante que todos os processos da interface de ponte possam se comunicar diretamente. Essas interfaces de ponte formam uma malha totalmente conectada.
Uma topologia alternativa é utilizar vários grupos de pontos de acesso, o que resulta em uma topologia de cadeia. Em uma topologia de cadeia, a comunicação é redirecionada de uma interface de ponte para outra através de interfaces de ponte intermediárias ao longo da cadeia.
Agora que você determinou a configuração das interfaces de ponte do grupo principal, estará pronto para decidir como distribuir os dez clusters, oito agentes do nó, oito servidores de interface de ponte independentes e o gerenciador de implementação entre os oito grupos principais. Você deseja distribuir os processos da maneira mais uniforme possível através dos oito grupos principais. A topologia a seguir é um bom exemplo de como distribuir uniformemente o processo contido na célula da V5.x:
- O primeiro grupo principal, DefaultCoreGroup, contém o gerenciador de implementação, o agente do nó de Node1, o servidor de ponte de Node 2 e Cluster1.
- O Grupo Principal 2 contém o agente do nó de Node2, o servidor de ponte de Node3 e Cluster2
- O Grupo Principal 3 contém o agente do nó de Node3, o servidor de ponte de Node4 e Cluster3
O transporte padrão neste exemplo não precisa ser alterado.
Como este exemplo não indica que você precisará de mais de um coordenador por grupo principal, você poderá deixar a configuração do coordenador no valor padrão de 1. No entanto, você poderá desejar tornar o servidor de interface de ponte independente, que está contido em cada grupo principal, o servidor do coordenador preferencial para o grupo principal. Essa designação inicialmente mantém a carga de trabalho necessária de um coordenador fora dos servidores de aplicativos em cluster que estão executando aplicativos.
Seu Plano de Migração
Se, após a revisão do exemplo anterior e a conclusão do processo de planejamento inicial para a célula que você está migrando, for determinado que o fluxo de migração padrão não é apropriado à topologia da Versão 7.0 de destino, é hora de elaborar um plano ou um roteiro para o processo de migração real. Esse plano deve incluir todas as etapas adicionais necessárias relacionadas ao grupo principal para migração da Versão 5.x para a Versão 7.0 e as respostas às seguintes perguntas:
- Quando você irá criar os novos grupos principais?
- A melhor hora para criar os novos grupos principais é imediatamente depois da migração do gerenciador de implementação ser concluída. Conforme os novos grupos principais são criados, você deve configurar as propriedades customizadas mencionadas anteriormente. É possível utilizar o console administrativo ou o comando wsadmin do createCoreGroup para criar os novos grupos principais. Porém, é necessário utilizar o console administrativo para configurar as propriedades customizadas.
- Quais ações devem ser executadas conforme os nós são migrados?
- Conforme cada nó é migrado, você deve:
- Crie o novo servidor de aplicativos independente que deve ser uma das interfaces de ponte do grupo principal.
- Ajustar o tamanho do buffer de transporte em todos os processos no nó. Um script é a melhor opção para executar esta ação.
- Ajuste o tamanho do heap no agente do nó e no servidor independente e ative o GC detalhado para esses processos.
- Quando e como os processos são movidos para novos grupos principais?
- Por padrão, o processo de migração coloca todos os processos no grupo principal
denominado DefaultCoreGroup. Em um determinado momento, o número de membros contidos
neste grupo principal irá exceder os limites de tamanho e será necessário redistribuir os
processos para outros grupos principais. É importante entender que os processos devem ser
parados antes de serem movidos. Se a disponibilidade de aplicativos contínua for requerida,
será necessário planejar cuidadosamente a ordem em que os processos serão movidos
para diferentes grupos principais.
É possível usar o console administrativo ou o comando moveServerToCoreGroup wsadmin para mover o gerenciador de implementação, os agentes do nó e o servidor de aplicativos independente.
Mover servidores de aplicativos armazenados em cluster é mais complicado. Em circunstâncias normais, você pode utilizar o console administrativo ou o comando wsadmin do moveServerToCoreGroup para mover clusters. Entretanto, durante o processo de migração, como o cluster a ser movido poderá ter membros da Versão 7.0 e da Versão 5.x, os comandos normais falharão porque um membro de cluster da Versão 5.x ainda não é membro de nenhum grupo principal. Para mover um cluster misto para um novo grupo principal, é necessário utilizar o comando wsadmin do moveClusterToCoreGroup com o parâmetro checkConfig opcional.
Por exemplo, suponha que Cluster0 tenha os membros de cluster A, B, C e D. O membro A está em um nó que foi migrado para a Versão 7.0 e é membro do DefaultCoreGroup, enquanto B, C e D ainda estão nos nós da Versão 5.x. Para mover o Cluster0 para o grupo principal CG1, utilize o comando a seguir”$AdminTask moveClusterToCoreGroup {-source CoreGroup1 –target CG1 –clusterName Cluster0 –checkConfig false}
Quando um servidor de aplicativos armazenado em cluster é migrado, os utilitários de migração determinam se outros membros de cluster já foram migrados e automaticamente colocam o membro que está migrando no mesmo grupo principal que outros membros do mesmo cluster que já foi migrado.
No exemplo anterior, o membro A foi movido para o grupo principal CG1. Quando os nós contendo B, C e D forem migrados, a migração colocará esses membros de cluster em CG1 em vez de no DefaultCoreGroup. Portanto, é necessário executar o comando moveClusterToCoreGroup apenas uma vez para cada cluster.
- Quando é necessário configurar suas pontes do grupo principal?
- No momento em que você mover os processos para vários grupos principais, será necessário ter pontes do grupo principal configuradas e em execução. Isso significa que os processos que você deseja utilizar como interfaces ponte na topologia de destino da Versão 7.0 poderão não estar disponíveis quando forem inicialmente necessários, visto que não foram migrados dos nós da Versão 5.x. Portanto, para garantir a disponibilidade contínua dos aplicativos, é necessário configurar alguns servidores de aplicativos armazenados em cluster para que sejam interfaces de ponte temporárias enquanto a migração continua. Depois que todos os processos tiverem sido migrados para a Versão 7.0, você poderá ajustar a configuração de ponte de grupo principal para corresponder à topologia da Versão 7.0 desejada.
Outras Considerações sobre Planejamento
Se a configuração da Versão 7.0 de destino exigir várias pontes de grupo principal, utilize a propriedade customizada de grupo principal IBM_CS_WIRE_FORMAT_VERSION para implementar aperfeiçoamentos em escala.
Além disso, se todos os seus grupos principais forem unidos em ponte e rotearem informações compartilhadas uns com os outros, a quantidade de dados compartilhados entre os membros do grupo principal provavelmente será muito maior que o normal. Portanto, é necessário utilizar as seguintes configurações para aumentar as configurações de memória do grupo principal para permitir uma transferência de dados mais eficiente:
- Configure IBM_CS_DATASTACK_MEG para 100
- Configure o tamanho do buffer de transporte em todos os processos para 100.
Você também deve considerar ajustar tais fatores como tamanhos do heap da JVM para qualquer agente do nó ou servidor de aplicativos que está sendo usado como uma interface de ponte e qualquer servidor independente que está sendo usado como coordenador. Um ponto de partida recomendado é aumentar o tamanho de heap em 512 megabytes. Você pode também ativar o monitoramento de GC detalhado para esses processos para que possa ajustar esses tamanhos de heap além do tempo.
Fluxos de Migração Possíveis
Há vários fluxos de migração que podem ser implementados para uma migração bem-sucedida. Os fluxos a seguir assumem um ponto de partida comum em que a migração do gerenciador de implementação foi concluída e os grupos principais foram criados, mas nenhuma ação adicional foi tomada.
- Fluxo de Migração 1
- Neste fluxo, as regras são rigorosamente seguidas. Este fluxo é insatisfatório
por vários motivos. Conforme cada nó é migrado, os clusters precisarão ser
movidos. Isso requer parar todos os membros de cluster. Isso pode fazer com que os aplicativos não estejam disponíveis. Além disso, as pontes precisam ser reconfiguradas em cada
etapa.
- Migrar Node1. O DefaultCoreGroup contém o gerenciador de implementação e todos os processos de Node1. Como o DefaultCoreGroup contém menos que 50 membros, nenhuma ação adicional é necessária.
- Migrar Node2. O DefaultCoreGroup, agora, contém mais que o número recomendado de processos. Equilibre os processos sobre 2 grupos principais movendo metade dos clusters e o agente do nó para o Node2 no CoreGroup2. Como há, agora, vários grupos principais sendo utilizados, é necessário configurar a ponte do grupo principal. Crie servidores de interface de ponte nos nós Node1 e Node2. Configure a ponte do grupo principal para unir em ponte os dois grupos principais.
- Migrar Node3. Equilibre os processos em 3 grupos principais movendo alguns dos clusters do DefaultCoreGroup e do CoreGroup2 para o CoreGroup3. Mova o agente do nó para o Node3 para CoreGroup3. Crie o servidor de interface de ponte no Node3. Reconfigure a ponte do grupo principal para unir em ponte todos os três grupos principais.
- Continue migrando os nós até que a migração seja concluída. Conforme cada nó é migrado, um certo rebalanceamento e uma certa reconfiguração da ponte do grupo principal podem ser necessários.
- Fluxo de Migração 2
- Neste fluxo, as regras são temporariamente flexíveis. Este fluxo produz resultados melhores, uma vez que a execução de servidores de aplicativos não precisa ser parada para movê-los para um grupo principal diferente. Enquanto a migração estiver em andamento, alguns grupos principais não conterão um processo administrativo por um período de tempo. Essa é uma violação técnica das regras, mas é aceitável desde que a configuração do grupo
principal não seja alterada enquanto a migração estiver em andamento.
- Migrar Node1. Node1 contém membros de todos os clusters exceto Cluster10
- Mova todos os clusters possíveis para o grupo principal identificado na topologia de destino final. O gerenciador de implementação, o agente do nó para Node1 e Cluster1 já estão no DefaultCoreGroup, portanto, nenhuma ação adicional é requerida para eles. Mova o Cluster2 para o CoreGroup2, o Cluster3 para o CoreGroup3 e assim por diante. Crie o servidor de ponte para Node1 e coloque-o no CoreGroup2.
- Configure a ponte do grupo principal para unir em ponte todos os 8 grupos principais. Por motivo de simplicidade, nós configuraremos temporariamente uma única interface de ponte para cada ponto de acesso. (Isso introduzirá um único ponto de falha enquanto a migração está em andamento). Como a maioria das interfaces de ponte da topologia final ainda estão na Versão 5.x, é necessário utilizar servidores de aplicativos como interfaces de ponte temporárias em 6 dos 8 grupos principais. Isso pode exigir um aumento temporário no tamanho de heap dos servidores de aplicativos selecionados.
- Migrar Node2. A migração automaticamente moverá os servidores de aplicativos armazenados em cluster para Node2 para os grupos principais apropriados. Como o Cluster10 não tinha nenhum servidor de aplicativos no Node1, mova manualmente o Cluster10 para o CoreGroup8. Mova o agente do nó para Node2 para o CoreGroup2. Crie o servidor de ponte no Node2. Opcionalmente, reconfigure a ponte do grupo principal para que alguns dos servidores da interface de ponte temporária estejam no Node2 para ajudar a distribuir a carga em ambos os nós.
- Continue migrando os nós utilizando o mesmo padrão até que todos os nós tenham sido migrados.
- Quando todos os nós tiverem sido migrados, configure os servidores preferidos do coordenador. Reconfigure as interfaces de ponte para que correspondam à topologia de destino final (com dois servidores da interface de ponte em cada ponto de acesso). Pare e reinicie os servidores que estão servindo como interfaces de ponte temporária. Reinicie os novos servidores da interface de ponte.
- Fluxo de Migração 3
- Este fluxo é uma variação do Fluxo 2. Conforme observado, este fluxo é uma variação
do Fluxo 2. O benefício é que a carga da ponte inicial é distribuída nos três nós
em vez de em 1. A desvantagem é que a redistribuição inicial de clusters para os
grupos principais ocorre depois que Node3 tiver migrado. Isso exige que os
servidores em execução nos nós Node1 e Node2 sejam parados para que a
movimentação ocorra. Isso pode afetar a disponibilidade do aplicativo.
- Migrar Node1. Quando essa etapa for concluída, o DefaultCoreGroup conterá 38 processos, o que está dentro dos limites.
- Migrar Node2. Quando essa etapa for concluída, o DefaultCoreGroup conterá 79 processos. Ao mesmo tempo em que isso é maior que o tamanho recomendado, está bem dentro do limite prático.
- Migrar Node3. Mova todos os clusters para o grupo principal identificado na topologia final. Mova o Cluster2 para o CoreGroup2, o Cluster3 para o CoreGroup3 e assim por diante. Mova os três agentes do nó para os grupos principais apropriados. Crie e mova os três servidores da interface de ponte para os grupos principais apropriados.
- Selecione servidores de aplicativos armazenados em cluster para agirem como pontes temporárias para os grupos principais que ainda não contêm interfaces de ponte designadas. Ajuste temporariamente os tamanhos de heap nesses servidores. Configure a ponte do grupo principal para unir em ponte todos os 8 grupos principais.
- Continue migrando os nós até que todos os nós tenham sido migrados.
- Quando todos os nós tiverem sido migrados, configure os coordenadores preferidos. Reconfigure as interfaces de ponte para que correspondam à topologia de destino final. Pare e reinicie os processos conforme requerido.