Neste documento, descrevemos as práticas recomendadas para uma migração homogênea do Db2 para o Compute Engine. Ele é destinado a administradores de bancos de dados, administradores de sistemas e softwares, bancos de dados e engenheiros operacionais que estejam migrando ambientes Db2 para o Google Cloud. As migrações do Db2 para outros tipos de bancos de dados estão fora do escopo deste documento.
Terminologia
- IBM Db2
- Um sistema de gerenciamento de banco de dados relacional (RDBMS) de nível empresarial, com recursos de replicação e failover.
- Recuperação de desastres de alta disponibilidade (HADR, na sigla em inglês)
- Um recurso do Db2 que usa atividades registradas em banco de dados para replicar dados do banco de dados primário para o modo de espera. Esse recurso ativa um failover manual do banco de dados primário para o banco de dados de espera.
- Primário
- A máquina que hospeda o Db2 e aceita solicitações de leitura e gravações. Ela é a origem da replicação para as máquinas de espera
- Modo de espera principal
- Uma máquina de espera que só pode aceitar solicitações de leitura. Ela aceita qualquer um dos modos de sincronização que o Db2 permite e é designada como uma instância de failback para fins de HADR. O IBM Db2 permite apenas uma máquina desse tipo em um cluster.
- Modo de espera auxiliar
- Uma máquina de espera que só pode aceitar solicitações de leitura. Ela aceita apenas o modo de sincronização SUPERASYNC e reside em um data center diferente da máquina primária, no caso de failover manual se o data center principal falhar.
- Tivoli System Automation for Multiplatforms (TSA/MP)
- O software de gerenciamento de clusters que facilita o failover automático de recursos do banco de dados primário para o modo de espera principal. Esse software inclui recursos de rede, armazenamento e processamento que são definidos como parte do cluster. O Db2 edição empresarial inclui direito ao TSAMP para HADR.
- Redirecionamento automático do cliente (ACR, na sigla em inglês)
- Um recurso do Db2 que redireciona os aplicativos clientes de um servidor com falha para um servidor alternativo, de modo que os aplicativos possam continuar funcionando com o mínimo de interrupções.
- Captura de dados de alterações (CDC, na sigla em inglês)
- Um conjunto de técnicas ou ferramentas para detectar alterações em um banco de dados, como sincronização de dados com outro banco de dados ou criação de uma trilha de auditoria.
Arquitetura
Em geral, um cluster do Db2 é composto de pelo menos um nó primário e nós de espera principais com HADR entre eles. Nas versões mais recentes do Db2, também é possível adicionar nós de espera auxiliares que atendem a finalidades de recuperação de desastres.
No diagrama a seguir, retratamos um ambiente de origem.
Nesse ambiente, o nó primário e o nó de espera principal estão em um mesmo data center, e os nós de espera auxiliares estão em data centers diferentes.
Uma meta de migração é recriar esse ambiente no Google Cloud, conforme mostrado no diagrama a seguir.
A tabela a seguir compara aspectos de cada tipo de migração.
| Migrate to Virtual Machines | Replicação Q | Replicação SQL | HADR | |
|---|---|---|---|---|
| Origens | VMware, VMs da Amazon Web Services (AWS) | Qualquer ambiente do Db2, com base em licenciamento | Qualquer ambiente do Db2 | Qualquer ambiente do Db2 |
| O que é replicado? | Replicação de discos no nível de bloco | Tabelas no banco de dados | Tabelas no banco de dados | Banco de dados inteiro |
| Cutover (substituição) | Requer alguns minutos para uma VM ser iniciada no Google Cloud | Apontar apps e DNS para as instâncias do Compute Engine | Apontar apps e DNS para as instâncias de nuvem | Apontar apps e DNS para as instâncias de nuvem |
| Replicação de alteração de DDL | Sim (gravações em disco sendo replicadas) | Sim | Sim | Sim |
| Replicação síncrona de dados | N/A | Não | Sim | Sim |
| Replicação assíncrona de dados | N/A | Sim | Sim | Sim |
| Replicação pontual de dados | Não | Sim | Sim | Não |
A tabela anterior é um guia para ajudar você a atender aos requisitos de disponibilidade do sistema e nível de esforço de recurso para configurar o sistema de destino, configurar a replicação, manter e testar a replicação ao longo do tempo. A tabela mostra que o Migrate to VMs é a abordagem mais fácil de implementar, mas a menos flexível em termos de disponibilidade do sistema. Como alternativa, o HADR, a replicação Q e a replicação SQL têm um impacto menor na disponibilidade do sistema em troca de um nível mais alto de esforço para configurar e manter a replicação em um modelo paralelo.
Tipos de migração
Há duas maneiras de migrar o Db2 para o Compute Engine:
- migrações que envolvem a modificação de uma configuração ou topologia atual de cluster
- migrações que replicam dados em clusters completamente novos
A modificação de um cluster não exige a inicialização de um cluster completamente novo na nuvem e, portanto, pode ser mais rápido. A outra alternativa de migração exige a implantação de um novo cluster no Google Cloud, mas isso tem um impacto menor no cluster atual, já que a replicação está fora da faixa. Esse método também é útil quando se quer replicar apenas uma parte do banco de dados ou realizar transformações nos dados antes que cheguem ao destino.
Nas seções a seguir, mostramos o que considerar antes de mover as instâncias do Db2 para o Google Cloud. Alguns recursos usados com frequência podem não funcionar como no Google Cloud ou podem ser necessárias algumas alterações de configuração.
Endereços IP flutuantes (virtuais)
Em um cluster do Db2 altamente disponível, o TSA/MP pode atribuir um endereço IP virtual ao nó primário. Esse endereço também é conhecido como endereço IP flutuante e significa que o tráfego é sempre encaminhado para o nó primário, e não o de espera.
O Compute Engine usa uma pilha de rede virtualizada em uma nuvem privada virtual (VPC, na sigla em inglês). Portanto, mecanismos de implementação comuns podem não funcionar. Por exemplo, a rede VPC processa solicitações ARP (Address Resolution Protocol) com base na topologia de roteamento configurada e ignora frames ARP desnecessários. Além disso, é impossível modificar diretamente a tabela de roteamento de rede VPC com protocolos de roteamento padrão, como o protocolo OSPF (Open Shortest Path First Protocol) ou BGP (Border Gateway Protocol). Portanto, é preciso implementar uma alternativa aos endereços IP flutuantes ou usar ACR.
Se você estiver migrando alguns ou todos os nós de um cluster do Db2, desative os endereços IP flutuantes do seu cluster antes de migrar qualquer nó.
ACR
Se o ambiente do Db2 usa ACR, talvez seja necessário alterar o catálogo dos clientes caso os nomes DNS sejam alterados ou os clientes se conectem usando endereços IP.
Desempate
O TSA/MP exige que a maioria dos nós do cluster esteja on-line para iniciar as ações de automação. Se o cluster consiste em um número par de nós, há chances de que a metade exata dos nós do cluster esteja on-line, e há chances de um cenário de dupla personalidade. Nesse caso, o TSA/MP usa um desempatador para decidir o estado do quórum (o grupo majoritário), que determina se as ações de automação podem ser iniciadas.
Considere os seguintes desempatadores que o ambiente do Db2 pode usar:
- Desempatador de armazenamento ou disco. O Ibm Db2 usa reservas de disco para desempatar. Como as reservas não estão disponíveis no Google Cloud, é necessário escolher um tipo diferente de desempatador.
- Desempatador de rede. Usa um endereço IP externo (ao cluster) para resolver uma situação de empate. Em uma implantação híbrida, seu desempatador de rede pode não precisar migrar para o Google Cloud inicialmente, desde que seja possível alcançá-lo por meio dos nós do cluster. No entanto, após a execução do cluster no Google Cloud, uma prática recomendada é criar o desempatador em uma zona diferente ou usar o servidor de metadados do Google Cloud como desempatador.
- Desempatador do NFS. O desempatador do NFS resolve situações de empate baseadas nos arquivos de reserva armazenados em um servidor NFS v4. Como no caso do desempatador de rede, o desempatador do NFS e o servidor NFS v4 também podem permanecer nos locais originais em uma implantação híbrida. Depois, uma prática recomendada é implantar seu próprio servidor NFS ou usar parceiros, como o Elastifile, como destinos de desempatador do NFS no Google Cloud.
Como migrar usando o Migrate to VMs
Se as duas condições a seguir forem verdadeiras para seu ambiente, "Migrate to VMs" será a opção recomendada:
Você tem um ambiente VMware vCenter ou máquinas virtuais no Amazon Elastic Compute Cloud (Amazon EC2).
Você tem uma conexão particular do Google Cloud com seu ambiente, como o Cloud VPN ou o Cloud Interconnect.
A opção Migrate to VMs é para migrar máquinas virtuais de ambientes locais e na nuvem para o Google Cloud. Ele permite que você migre uma máquina virtual para o Google Cloud em alguns minutos, enquanto os dados são copiados em segundo plano, mas as máquinas virtuais estão completamente operacionais. É necessária uma conexão particular entre o ambiente de origem e o projeto do Google Cloud, como o Cloud VPN, Cloud Interconnect, ou Partner Interconnect.
Com o Migrate to VMs, é necessário reavaliar a configuração do banco de dados nas VMs da nuvem. Algumas configurações podem não ser otimizadas para o Google Cloud, como variáveis do registro, pools de buffer, configuração do gerenciador de bancos de dados ou configuração de banco de dados.
É possível usar o utilitário AUTOCONFIGURE para iniciar com uma linha de base.
A metodologia operacional do Migrate to VMs é detalhada no Ciclo de vida da migração da VM.
Nas seções a seguir, descrevemos como aplicar essa metodologia a um ambiente do Db2.
Clones de teste
Só há clones de teste disponíveis em ambientes do vCenter.
O Migrate to VMs pode tirar um snapshot da sua VM e criar uma instância do Compute pronta para uso no Google Cloud com base nesse snapshot. É possível recriar o ambiente do Db2 no Google Cloud, testar mudanças na configuração, testar e comparar a implantação sem quaisquer consequências para o ambiente de origem.
O diagrama a seguir mostra o ambiente do DB2 no Google Cloud com o ambiente lado a lado no Google Cloud após uma clonagem de teste do Migrate to VMs.
Depois de realizar um comparativo e testar os clones de teste no Google Cloud, é possível excluí-los.
Execução em nuvem
Ao ativar a execução em nuvem, o Migrate to VMs encerra o cluster de origem e inicia as VMs no Google Cloud, enquanto busca apenas dados conforme necessário e não faz streaming do armazenamento inteiro para o Google Cloud. A execução em nuvem é compatível com o write-back e é ativada por padrão. Com o Migrate to VMs, é possível testar seu ambiente antes de fazer o streaming efetivo do armazenamento. Também é possível migrar a VM de volta ao seu ambiente de origem usando o recurso Retornar. Nas migrações entre nuvens, não é possível replicar write-backs para a origem.
No diagrama a seguir, mostramos a fase de execução em nuvem, se você definir todos os nós para execução em nuvem. Você tem a opção de migrar gradualmente os nós do cluster, em vez do cluster inteiro de uma só vez.
Migração
A fase de migração é semelhante à de execução na nuvem, mas o Migrate to VMs também realiza o stream de atividades de armazenamento no Google Cloud. Durante a fase de execução na nuvem, o Migrate to VMs só traz dados sob demanda para economizar na largura de banda porque você não indicou que está pronto para mover a VM completamente.
Remover
Durante essa fase, o Migrate to VMs sincroniza os dados do cache e do armazenamento de objetos com os discos de dados nativos no Google Cloud e, em seguida, anexa os discos à VM. Nesta fase, é necessário encerrar a VM no Google Cloud. No caso do Db2, recomendamos desanexar um nó do cluster por vez.
Como usar a replicação
No caso do Db2, a replicação é o processo de capturar alterações do registro de transações usando um programa denominado "capture" e, em seguida, aplicando-as a um cluster diferente usando o programa "apply". O modo como o programa "capture" captura as alterações e o tipo de canal de comunicação usado para transmitir as alterações ao programa "apply" são diferentes entre os tipos de replicação.
No diagrama a seguir, mostramos o fluxo lógico de informações na replicação do Db2.
O app "capture" captura as alterações do banco de dados e as envia para o app "apply". O app "apply" grava essas alterações no banco de dados de destino. Há algumas transformações que os apps podem fazer nos próprios dados. Não é obrigatória a execução dos aplicativos "capture" e "apply" no próprio servidor de banco de dados.
Replicação SQL
Uma replicação SQL captura alterações em tabelas e visualizações de origem e usa tabelas de preparo para armazenar dados de transações confirmados. As alterações são lidas das tabelas de preparo e replicadas nas tabelas de destino correspondentes. No momento da elaboração deste documento, quando você instalava o Db2, a replicação SQL ficava disponível.
Um processo de migração que aproveita a replicação SQL tem uma estrutura como esta:
- Implantar o Db2 no Google Cloud.
- Configurar a replicação SQL.
- Iniciar a replicação SQL.
- Verificar se as implantações estão sincronizadas.
- Direcionar seus aplicativos para a instância do Google Cloud. Parar a replicação.
O diagrama a seguir é um exemplo de replicação SQL.
Seu ambiente de produção funciona normalmente, enquanto replica os comandos SQL para o novo cluster criado no Google Cloud. No diagrama anterior, o processo de replicação é executado na instância principal, mas há diferentes métodos de implantá-la que estão fora do escopo deste documento.
Replicação Q
A replicação Q é uma maneira mais recente e mais eficiente do que a replicação SQL de replicar dados de uma instância do Db2 para outra. Esse método usa o IBM MQ para entregar entradas de alterações de dados, o que significa que é preciso implantar uma instância do IBM MQ no ambiente de origem e no ambiente de destino. Esse método de replicação é mais rápido que a replicação SQL porque ocorre na memória. A replicação SQL é mais lenta, mas a replicação Q geralmente é mais difícil de configurar, porque é necessário configurar o IBM MQ. Dependendo da sua licença do Db2, poderá ser necessário adquirir uma licença para a replicação Q.
Ao iniciar a replicação do Db2 Q, escolha um dos dois métodos a seguir:
Carregamento automático. Os processos de replicação Q executam o carregamento inicial, o que significa restaurar o banco de dados de destino com base em um backup da origem.
Carregamento manual. Você executa o carregamento inicial e, em seguida, inicia a replicação a partir do ponto no registro.
Um processo de migração tem a seguinte estrutura:
- Implantar o IBM MQ no Google Cloud e no seu ambiente de origem.
- Implantar o Db2 no Google Cloud.
- Configurar a replicação Q.
- Iniciar a replicação Q (com carregamento manual ou automático).
- Verificar se as duas implantações estão sincronizadas.
- Direcionar seus aplicativos para a instância do Google Cloud. Parar a replicação.
No diagrama a seguir, mostramos uma possível solução da replicação Q.
O ambiente de origem usa a replicação IBM Q para enviar as alterações do banco de dados ao IBM MQ e ao ambiente de destino, estendendo um cluster do Db2 ao Compute Engine
Nessa abordagem, você migra gradualmente seu cluster atual do Db2 para o Compute Engine e conta com o HADR para a transferência de dados entre os nós.
Use essa abordagem se as seguintes condições forem verdadeiras:
- Você não quer implantar um cluster totalmente novo no Compute Engine.
- Não é possível aproveitar o Migrate to VMs.
- Não é possível usar uma das opções de replicação.
- Você não usa ou não é possível usar um produto de parceiro (licenciamento, custos ou conformidade, entre outros motivos).
Se sua versão do Db2 não aceita modo de espera auxiliar
Faça o seguinte:
- Implante uma instância do Db2 no Compute Engine.
- Faça um backup da instância primária.
- Restaure a instância do Db2 no Compute Engine com base no backup.
- Remova a instância de espera da configuração de HADR.
- Anexe a instância do Db2 do Compute Engine como instância de espera (é possível escolher o modo de sincronização, mas, devido à possibilidade de uma latência mais alta,
ASYNCouNEARASYNCpodem ser preferíveis). - Execute failover na instância do Db2 do Compute Engine e torne-a instância primária de HADR.
- Crie outra instância do Db2 do Compute Engine, restaure-a do backup e configure-a como instância de espera de HADR.
A primeira etapa no diagrama a seguir mostra a instância recém-criada do Db2 no Google Cloud configurada como a espera principal do Db2 primário de origem.
No diagrama anterior, a instância do Google Cloud torna-se a primária de HADR. Em seguida, você remove a instância de espera principal de origem e anexa outra instância do Db2 ao Compute Engine como a instância de espera principal.
Se sua versão do Db2 aceita modo de espera auxiliar
Uma opção é seguir as mesmas etapas de quando a versão do Db2 não aceita o modo de espera auxiliar e, no final, migrar também as instâncias de espera auxiliar.
Outra opção é aproveitar as réplicas auxiliares para uma migração mais tolerante a falhas para o Google Cloud, porque você não tem a espera primária ou principal no ambiente de origem e na outra no Google Cloud. A lista a seguir descreve as etapas dessa segunda opção:
- Implantar instâncias do Db2 no Compute Engine (primária, principal, auxiliar, se necessário) nos locais correspondentes.
- Remover os nós de espera auxiliares do cluster de origem.
- Configurar os nós que se tornarão o primário e o principal dos nós de espera auxiliar do cluster de origem.
- Executar uma transferência de uma das instâncias do Compute Engine. Essa instância se torna a instância primária. Configure uma das outras instâncias do Compute Engine como espera principal da instância primária.
A primeira etapa descrita no diagrama a seguir mostra duas das instâncias recém-criadas do Db2 no Compute Engine.
As instâncias são configuradas como esperas auxiliares da instância primária do Db2 de origem, em vez de instâncias auxiliares no ambiente de origem. Em seguida, após invocar a transferência para uma das instâncias do Compute Engine, essa instância se tornará a primária de HADR, e outra instância será configurada como espera principal. Na última etapa, duas outras instâncias são configuradas como esperas auxiliares.
Produtos de parceiros
O Google tem vários parceiros que têm produtos para ajudar nessa migração. A maioria desses produtos usa CDC para replicar dados entre o Db2 de origem e o destino. Esses produtos não pertencem ao Google Cloud, e é necessário verificar o licenciamento e os preços de cada produto ou serviço. Normalmente, esse serviço replica dados de um cluster atual para um cluster diferente criado no Google Cloud, e a abordagem geral é semelhante aos cenários de replicação descritos neste documento.
Exemplos de produtos de parceiros:
A seguir
- Guia de planejamento do IBM Db2 para SAP
- Central de migração de banco de dados do Google Cloud.
- Confira arquiteturas de referência, diagramas e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.