Migrando uma instância com Mirror/Shadow de Caché/Ensemble para IRIS (Parte 03).

 

Olá comunidade! Nesta parte do artigo temos um cenário onde o nosso ambiente InterSystems Caché/Ensemble possui um ou mais servidores com Shadow e/ou Mirror.

Como comentado no início do artigo, componentes de um software possuem uma evolução natural e outros componentes são deprecados. E uma tecnologia muito utilizada pelos nossos clientes que está deprecada no InterSystems IRIS é o Shadow (esta informação está na página 18 do documento InterSystems IRIS Adoption Guide que volto a recomendar que você faça o download no WRC).

Como o Shadow é um componente deprecado, o cenário que vamos utilizar no artigo é um ambiente com dois servidores em Shadow.

Como primeiro passo, precisamos olhar para os pré-requisitos do nosso ambiente, já comentado na parte 01 do artigo.

Vamos utilizar como exemplo dois servidores Ensemble 2018.1.4 com Shadow rodando em um servidor Red Hat 8.0 e vamos executar a migração no mesmo hardware por estes atenderem os pré-requisitos (o ambiente teste que estou utilizando são duas EC2-t2.medium na AWS).

Não vou tratar neste artigo diferenças do Shadow X Mirror e os detalhes da configuração de ambos, vou deixar aqui alguns links importante sobre o assunto:

• Artigo da comunidade internacional: https://community.intersystems.com/post/cach%C3%A9-mirroring-101-brief-guide-and-faq
• Convertendo um Shadow para um servidor Mirror: https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GHA_mirror#GHA_mirror_set_bp_shadow
• Guia de alta disponibilidade do InterSystems IRS: https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GHA

Uma dica essencial para o processo:

Como, durante este processo de migração, vamos migrar primeiro o servidor secundário do FailOver e depois o primário, ou seja, durante o processo de migração o seu ambiente terá um servidor Caché como primário e um IRIS como secundário. Para que isso seja possível, lembre-se de olhar os pré-requisitos e a matriz de compatibilidade que se encontra no InterSystems IRIS Migration Guide (lembrando que é possível fazer o download via WRC) e ter certeza que os bancos que se encontram no Shadow/Mirror são bancos somente de Globais, pois não existe compatibilidade entre Caché/Ensemble e IRIS nos bancos de rotinas!

Abaixo um exemplo da lista de compatibilidades, existente na documentação oficial:

Então vamos colocar a mão na massa e com a dica mais importante para todo o processo:

Execute todo o processo de migração em ambiente de testes primeiro, valide sua aplicação e BACKUP, BACKUP e BACKUP...... e não esqueça de testar o RESTORE do ambiente!!

        Obs: Caso o seu ambiente já possua Mirror, ignorar a etapa 1 do processo abaixo, seguir os passos a partir da etapa 2.

1 - A primeira etapa da migração é migrar os nossos servidores Shadow para Mirror.

Observar os

Shadow Origem:

Shadow Destino:

1. 1.1 O processo de migração se inicia criando o ambiente de Mirror e adicionando o Shadow Origem com membro primário: Criando um Mirror.

Exemplo de configuração do Mirror:

1. 1.2  Agora como próximo passo adicione o Shadow destino como membro do Mirror (Backup failover Member)
2.  
3. Exemplo do servidor secundário como Backup FailOver:

       1.3 Adicione os bancos que estão configurados como “Shadowed databases” no servidor primário do Mirror. Adicionando um banco existente no Mirror.

Exemplo com o banco adicionado:

1.4 - Agora precisamos sincronizar o banco de dados no servidor membro, existem duas formas:

• Utilizando o backup e restore
• Utilizando o utilitário: ConvertShadowDatabases^MIRROR, de acordo com o procedimento em: Convertendo um servidor Shadow para Mirror.  Pronto, agora que finalizamos a migração de Shadow para Mirror, podemos migrar nosso ambiente para InterSystems IRIS.

 

2 - Todos os passos nesta etapa 2 são feitas no servidor secundário membro backup do Failover.

Na documentação oficial: How to migrate to InterSystems IRIS existe uma um capítulo tratando com detalhes esta etapa que vou passar dicas aqui, ela se chama: Mirrored Environment Migration Checklist. (Sempre lembrando que a documentação está disponível no WRC)

2.1 – O primeiro passo é parar o Failover automático no servidor de membro de backup, clicando em Set No Failover:

               

        O novo status do servidor ficará da seguinte maneira: Clear no Failover

 

1.            2.2  - Caso o ambiente seja Ensemble, lembre-se que é necessário desligar o Auto-Start da produção, este procedimento encontra-se na parte 02 deste artigo.

2.3 - Se o seu ambiente utiliza o mapeamento %ALL, você precisa deletar este mapeamento, caso contrário durante o processo de migração o processo vai falhar e o ambiente ficará em um estado que não é possível a recuperação.

1.           2.4 Agora vamos desligar o servidor secundário membro do ambiente Failover, e verificar o log para confirmar que não existe nenhum problema no ambiente.

 

2.5 - Como próximo passo é necessário parar e desativar o ISCAgent no servidor secundário membro do ambiente FailOver.

 

 

2.6 -Vamos rodar agora o script de instalação do InterSystems IRIS, atualizando o nosso ambiente corrente, lembrando que o instalador reconhecerá a instância de Caché/Ensemble, informando o nome da instância o instalador executará a atualização do ambiente.

 

2.7 - O alerta que é apresentando após a migração ocorre pois o ISCAgent está desativado. (Executado no passo 2.5).

Log:

 

 

O agente também foi atualizado durante o processo de instalação, como próximo passo precisamos reativar o ISCAgent.

 

1.           2.8 - Após o ISCAgent estar ativo, precisamos validar se o servidor membro do backup FailOver está ativo.

 

1.            2.9 - Como o servidor primário ficou ativo, precisamos ligar novamente o Mirror para que os bancos sincronizem, clique em Clear no Failover e verifique o monitor do Mirror e valide se todos os bancos sincronizaram:

 

3 - Agora esta etapa será realizada no servidor primário que está com Caché/Ensemble (neste momento o ambiente não pode ficar disponível para nenhum usuário).  Uma dica importante, como no primeiro momento o processo está sendo feito em ambiente de teste, este é um bom momento para medir o tempo de downtime do ambiente a fim de colocar no planejamento da sua migração oficial.

 

1.       3-1 - Caso o ambiente seja Ensemble, lembre-se que é necessário desligar o Auto-Start e parar a produção, este procedimento encontra-se na parte 02 deste artigo.
2.  
3.        3.2 - Se seu ambiente utiliza o mapeamento %ALL, você precisa deletar este mapeamento. Caso contrário, durante o processo de migração o processo vai falhar e o ambiente ficará em um estado que não é possível a recuperação.

1.         3.3 - Como próximo passo agora vamos desligar o servidor primário.

 

4 - Agora precisamos validar se o servidor secundário membro do Failover assumiu corretamente o posto, e se tornou primário:

 É possível verificar no Monitor do Mirror que tudo está certo! 😊

 

 4.1 – Se seu ambiente utiliza o mapeamento %ALL, agora chegou a hora de recriá-lo.

1.    4.2 - Vamos agora compilar as aplicações (Classes, Rotinas e CSP), este procedimento está descrito parte 02 do artigo.
2.  
3.    4.3 - Caso seu ambiente seja Ensemble chegou a hora de iniciar a produção.

1.     4.4  -Para prevenir problemas durante a atualização do servidor Caché (que se encontra parado), vamos parametrizar para não ocorrer o Failover automático no servidor IRIS, clicando em Set No Failover.

 

O status que precisamos é que mude para Clear no Failover:

Podemos reparar no Monitor do Mirror o status Down do servidor.

 

5 - Esta etapa será realizada no servidor Caché que está desligado. (Antigo servidor primário membro do FailOver).

5.1 - É necessário parar e desativar o ISCAgent no antigo servidor primário membro do ambiente FailOver.

1.  5.2 - Agora vamos rodar o script de instalação do InterSystems IRIS para atualizar o Caché/Ensemble. Lembrando que o instalador reconhecerá a instância do Caché/Ensemble atualmente instalada.  

 

1.     5.3 - Se seu ambiente utiliza o mapeamento %ALL, agora chegou a hora de recriá-lo.

 

1.      5.4 - Próxima passo é iniciar o ISCAgent.    
2.  
3.         
4.  
5.     5.5 - Agora precisamos verificar se o servidor se tornou um membro do Failover, como backup:

 

1. 5.6 - Caso o ambiente seja Ensemble, já é possível ligar o auto-start da Produção.
2.  
3. 5.7  - Podemos ligar o Failover automático novamente, para sincronismo do banco de dados, clicando em Clear No FailOver:

O status mudará para e a sincronização dos bancos deve iniciar:

 

6 – A migração dos dois servidores foi finalizada, porém, como o procedimento se inicia pelo servidor secundário, o atual servidor secundário (antigo primário) ainda precisa da sua atenção, se faz necessário compilar a aplicação neste servidor e torná-lo principal novamente. Este procedimento também deixará o ambiente indisponível para os usuários.

6.1 – Caso seja Ensemble, parar a produção no servidor primário atual.

6.2 – Desligar o servidor com segurança.

 

6.3 – Verificar se o servidor se tornou primário:

 

6.4 – Agora se faz necessário compilar as aplicações (Classes, Rotinas e CSP), este procedimento está descrito parte 02 do artigo.

 

6.5 – Agora vamos ligar o servidor secundário e verificar o sincronismo dos bancos de dados.

 

Nossa migração foi finalizada com sucesso!

A próxima parte do artigo, vamos tratar de uma migração de um ambiente com ECP, até lá e obrigado!