Estrategias para la migración de IBM Db2 a Compute Engine

En este documento, se describen las prácticas recomendadas para una migración homogénea de Db2 a Compute Engine. Está dirigido a administradores de bases de datos, administradores de sistemas y, también, ingenieros de software, bases de datos y operaciones que migren entornos de Db2 a Google Cloud. Las migraciones de Db2 a otros tipos de bases de datos no se incluyen en este documento.

Terminología

IBM Db2
Un sistema de administración de bases de datos relacionales (RDBMS) de nivel empresarial, con funciones de replicación y conmutación por error.
Recuperación ante desastres de alta disponibilidad (HADR)
Una función para Db2 que usa actividades registradas en la base de datos a fin de replicar datos de la base de datos primaria a la que está en espera. Mediante esta función, se habilita una conmutación por error manual de la base de datos primaria a la que está en espera.
Primaria
La máquina que aloja Db2, la cual acepta operaciones de escritura y solicitudes de lectura. Es la fuente de la replicación en las máquinas en espera.
En espera principal
Una máquina en espera que solo puede aceptar solicitudes de lectura. Esta máquina admite cualquiera de los modos de sincronización que Db2 permite y se designa como una instancia de recuperación para propósitos de HADR. IBM Db2 solo permite una máquina de este tipo en un clúster.
En espera auxiliar
Una máquina en espera que solo puede aceptar solicitudes de lectura. Solo admite el modo de sincronización SUPERASYNC y reside en un centro de datos diferente al de la máquina primaria en caso de que se produzca una conmutación por error manual si falla el centro de datos principal.
Tivoli System Automation for Multiplatforms (TSA/MP)
Software de administración de clústeres que facilita la conmutación por error automática de recursos desde la base de datos primaria a la en espera primaria. En este software, se incluyen recursos de red, almacenamiento y procesamiento que se definen como parte del clúster. Db2 Enterprise Edition incluye autorización de TSAMP para HADR.
Redireccionamiento automático de clientes (ACR)
Una función de Db2 que redirecciona las apps cliente de un servidor con errores a un servidor alternativo para que las apps puedan seguir funcionando con una interrupción mínima.
Captura de datos modificados (CDC)
Un conjunto de técnicas o herramientas para detectar cambios en una base de datos, como la sincronización de datos con otra base de datos o la creación de un registro de auditoría.

Arquitectura

Por lo general, un clúster de Db2 consta de nodos primarios y en espera principales con HADR entre ellos. En las versiones más recientes de Db2, también puedes agregar nodos en espera auxiliares que sean útiles para fines de DR.

En el siguiente diagrama, se muestra un entorno de origen.

Arquitectura del entorno de origen típico en dos centros de datos.

En este entorno, la base de datos primaria y la en espera principal están en un centro de datos, mientras que las en espera auxiliares se encuentran en centros de datos diferentes.

Un objetivo de migración es volver a crear este entorno en Google Cloud, como se muestra en el siguiente diagrama.

Arquitectura del entorno de origen que se volvió a crear en Google Cloud.

En la siguiente tabla, se comparan aspectos de cada tipo de migración.

Migrate to Virtual Machines Replicación de Q Replicación de SQL HADR
Origen VMware, VM de Amazon Web Services (AWS) Cualquier entorno de Db2, basado en licencias Cualquier entorno de Db2 Cualquier entorno de Db2
Qué se replica Replicación de discos a nivel de bloque Tablas en la base de datos Tablas en la base de datos Base de datos completa
Migración de sistemas La implementación de una VM tarda algunos minutos en Google Cloud Dirige aplicaciones y DNS a las instancias de Compute Engine Dirige aplicaciones y DNS a las instancias de Cloud Dirige aplicaciones y DNS a las instancias de Cloud
Replicación de cambios de DDL Sí (las escrituras de disco se están replicando) Sí Sí Sí
Replicación de datos síncrona N/A No Sí Sí
Replicación de datos asíncrona N/A Sí Sí Sí
Replicación de datos de un momento determinado No Sí Sí No

La tabla anterior sirve de guía para ayudarte a hacer coincidir los requisitos de disponibilidad del sistema y el nivel de esfuerzo de los recursos a fin de configurar el sistema de destino, la replicación, y el mantenimiento y la prueba de la replicación en el tiempo. En la tabla, se muestra que Migrate to VMs es el enfoque más fácil de implementar, pero el menos flexible en términos de disponibilidad del sistema. Como alternativa, HADR, la replicación de Q y la replicación de SQL tienen un impacto menor en la disponibilidad del sistema a cambio de un mayor nivel de esfuerzo para configurar y mantener la replicación en un modelo paralelo.

Tipos de migración

Hay dos maneras de migrar Db2 a Compute Engine:

  • Migraciones que implican modificar una configuración o una topología de clúster existente
  • Migraciones que replican datos en clústeres completamente nuevos

La modificación de un clúster existente no requiere que se inicie un clúster completamente nuevo en la nube y, por lo tanto, puede ser más rápida. La otra forma de migrar requiere que implementes un clúster nuevo en Google Cloud, pero esto tiene un impacto menor en el clúster existente porque la replicación está fuera de banda. Este método también es útil si deseas replicar solo una parte de la base de datos o realizar transformaciones en los datos antes de que lleguen al destino.

En las siguientes secciones, se analiza qué debes considerar antes de mover tus instancias de Db2 a Google Cloud. Es posible que algunas funciones que suelen usarse no funcionen igual que en Google Cloud o que necesiten algunos cambios de configuración.

Direcciones IP flotantes (virtuales)

En un clúster de Db2 con alta disponibilidad, TSA/MP puede asignar una dirección IP virtual al nodo principal. Esta dirección también se denomina dirección IP flotante y significa que el tráfico siempre se enruta al nodo principal y no al nodo en espera.

Compute Engine usa una pila de red virtualizada en una red de nube privada virtual (VPC), por lo que los mecanismos de implementación típicos podrían no funcionar. Por ejemplo, la red de VPC controla las solicitudes del Protocolo de resolución de direcciones (ARP) en función de la topología de enrutamiento configurada e ignora los marcos de ARP injustificados. Además, es imposible modificar directamente la tabla de enrutamiento de la red de VPC con protocolos de enrutamiento estándares, como Abrir la ruta de acceso más corta primero (OSPF) o el Protocolo de puerta de enlace fronteriza (BGP). Por lo tanto, debes implementar una alternativa a las direcciones IP flotantes o usar ACR.

Si mueves algunos o todos los nodos de un clúster de Db2, asegúrate de inhabilitar las direcciones IP flotantes para tu clúster antes de moverlos.

ACR

Si el entorno de Db2 usa ACR, es posible que debas cambiar el catálogo en tus clientes si los nombres de DNS cambian o si los clientes se conectan mediante direcciones IP.

Tiebreakers

TSA/MP requiere que la mayoría de los nodos del clúster estén en línea para iniciar acciones de automatización. Si el clúster consiste en una cantidad par de nodos, existe la posibilidad de que la mitad exacta de los nodos del clúster esté en línea y de que haya una situación de cerebro dividido. En este caso, TSA/MP usa un tiebreaker para decidir el estado del quórum (el grupo mayoritario), que determina si se pueden iniciar acciones de automatización o no.

Considera los siguientes tiebreakers que podría usar el entorno de Db2:

  • Tiebreaker de disco o almacenamiento. IBM Db2 usa reservas de disco para definir empates. Debido a que las reservas no están disponibles en Google Cloud, debes elegir otro tipo de tiebreaker.
  • Tiebreaker de red. Usa una dirección IP externa (en el clúster) a fin de resolver situaciones de empate. En una implementación híbrida, es posible que, en un principio, el tiebreaker de red no tenga que moverse a Google Cloud, siempre y cuando se pueda acceder a este desde los nodos del clúster. Sin embargo, una vez que el clúster se ejecuta en Google Cloud, se recomienda crear el tiebreaker en una zona diferente o usar el servidor de metadatos de Google Cloud como tiebreaker.
  • Tiebreaker de NFS. El tiebreaker de NFS resuelve situaciones de empate basadas en archivos de reserva que se almacenan en un servidor NFS v4. Al igual que el tiebreaker de red, el tiebreaker de NFS y el servidor NFS v4 también pueden permanecer en su ubicación original en una implementación híbrida. Más adelante, se recomienda que implementes tu propio servidor NFS o uses socios como Elastifile como objetivos del tiebreaker de NFS en Google Cloud.

Migra con Migrate to VMs

Si tu entorno cumple con las dos condiciones siguientes, Migrate to VMs es la opción recomendada para ti:

  • Tienes un entorno de VMware vCenter o máquinas virtuales en Amazon Elastic Compute Cloud (Amazon EC2).

  • Tienes una conexión privada de Google Cloud a tu entorno, como Cloud VPN o Cloud Interconnect.

Migrate to VMs es para migrar máquinas virtuales de entornos locales y en la nube a Google Cloud. Te permite migrar una máquina virtual a Google Cloud en pocos minutos, mientras que los datos se copian en segundo plano, pero las máquinas virtuales son completamente operativas. Debes tener una conexión privada entre tu entorno de origen y el proyecto de Google Cloud, como Cloud VPN, Cloud Interconnect o la interconexión de socio.

Con Migrate to VMs, debes volver a evaluar la configuración de la base de datos en las VMs de la nube. Es posible que algunas opciones de configuración no estén optimizadas para Google Cloud, como las variables de registro, los grupos de búferes, la configuración del administrador de bases de datos o la configuración de bases de datos. Puedes usar la utilidad AUTOCONFIGURE para comenzar con un modelo de referencia.

La metodología operativa de Migrate to VMs se detalla en Ciclo de vida de la migración de VMs.

En las siguientes secciones, se describe cómo aplicar esta metodología para un entorno de Db2.

Clonaciones de prueba

Las clonaciones de prueba solo están disponibles en entornos de vCenter.

Migrate to VMs puede tomar una instantánea de tu VM y crear una instancia de procesamiento lista para usar en Google Cloud a partir de esa instantánea. Puedes volver a crear tu entorno de Db2 en Google Cloud, probar los cambios de configuración, realizar pruebas y comparar la implementación sin consecuencias en el entorno de origen.

En el siguiente diagrama, se muestra tu entorno de DB2 en Google Cloud con el entorno en paralelo de Google Cloud después de una clonación de prueba de Migrate to VMs.

Arquitectura del entorno en paralelo después de una clonación de prueba

Después de comparar y probar las clonaciones de prueba en Google Cloud, puedes borrarlas.

Ejecución en la nube

Cuando se activa la ejecución en la nube, Migrate to VMs cierra el clúster de origen e inicia las VMs en Google Cloud, mientras que solo recupera datos según sea necesario y no transmite todo el almacenamiento a Google Cloud. La ejecución en la nube admite la reescritura y está habilitada de forma predeterminada. Migrate to VMs te ayuda a probar tu entorno antes de transmitir el almacenamiento de forma activa. También puedes migrar la VM al entorno de origen mediante la función de migración al origen. En las migraciones de nube a nube, no es posible replicar las operaciones de escritura en la fuente.

En el siguiente diagrama, se muestra la fase de ejecución en la nube si configuras todos los nodos para que se ejecuten en la nube. Puedes decidir mover de forma gradual los nodos del clúster en lugar del clúster completo de una sola vez.

Arquitectura de la fase de ejecución en la nube con todos los nodos configurados para ejecutarse en la nube.

Migración

La fase de migración es similar a la fase de ejecución en la nube, pero Migrate to VMs también transmite activamente el almacenamiento a Google Cloud. Durante la fase de ejecución en la nube, Migrate to VMs solo agrega datos bajo demanda a fin de ahorrar en el ancho de banda, dado que no indicaste que ya estabas listo para mover la VM por completo.

Desconectar

Durante esta fase, Migrate to VMs sincroniza los datos desde su caché y su depósito de objetos hacia los discos de datos nativos en Google Cloud y, luego, conecta los discos a la VM. En esta fase, se requiere que cierres la VM en Google Cloud. Para Db2, te recomendamos desconectar un nodo del clúster a la vez.

Usa la replicación

Para Db2, la replicación es el proceso de capturar cambios del registro de transacciones mediante un programa llamado programa de captura y, luego, aplicarlos a un clúster diferente con el programa de aplicación. La forma en que el programa de captura adquiere los cambios y el tipo de canal de comunicación que se usa para transmitirlos al programa de aplicación difiere entre los tipos de replicación.

En el siguiente diagrama, se muestra el flujo lógico de información en la replicación de Db2.

Arquitectura del flujo de información en la replicación de Db2.

La app de captura obtiene los cambios de la base de datos y los envía a la app de aplicación. La app de aplicación escribe esos cambios en la base de datos de destino. Existen algunas transformaciones que las apps pueden realizar en los datos. Las apps de captura y aplicación no necesitan ejecutarse en el servidor de la base de datos.

Replicación de SQL

Una replicación de SQL captura los cambios en las tablas de origen y las vistas, y usa tablas de etapa de pruebas para almacenar datos transaccionales confirmados. Luego, los cambios se leen desde las tablas de etapa de pruebas y se replican en las tablas de destino correspondientes. En el momento en el que se redacta este documento, cuando instalas Db2, la replicación de SQL está disponible.

Un proceso de migración que aprovecha la replicación de SQL se vería de la siguiente manera:

  1. Implementa Db2 en Google Cloud.
  2. Configura la replicación de SQL.
  3. Inicia la replicación de SQL.
  4. Verifica que las implementaciones estén sincronizadas.
  5. Apunta tus aplicaciones a la instancia de Google Cloud. Detén la replicación.

El siguiente diagrama es un ejemplo de replicación de SQL.

Replicación de SQL del entorno de origen en Google Cloud.

Tu entorno de producción funciona como siempre, mientras replicas los comandos de SQL en el clúster nuevo que creas en Google Cloud. En el diagrama anterior, el proceso de replicación se ejecuta en la instancia primaria, pero existen diferentes formas de implementarlo que no se incluyen en este documento.

Replicación de Q

La replicación de Q es una forma más nueva y eficiente que la replicación de SQL para replicar datos de una instancia de Db2 a otra. En este método, se usa IBM MQ para entregar entradas de cambios de datos, lo que significa que debes implementar una instancia de IBM MQ en el entorno de origen y en el entorno de destino. Este método de replicación es más rápido que la replicación de SQL porque está en la memoria. La replicación de SQL es más lenta, pero la replicación de Q suele ser más difícil de configurar porque necesitas configurar IBM MQ. Según tu licencia de Db2, es posible que debas adquirir una licencia para la replicación de Q.

Cuando inicias la replicación de Q de Db2, puedes elegir entre los siguientes dos métodos:

  • Carga automática. Los procesos de replicación de Q realizan la carga inicial, lo que implica restablecer la base de datos de destino desde una copia de seguridad de la fuente.

  • Carga manual. Debes realizar la carga inicial y, luego, iniciar la replicación desde el punto del registro.

Un proceso de migración se ve de la siguiente manera:

  1. Implementa IBM MQ en Google Cloud y en tu entorno de origen.
  2. Implementa Db2 en Google Cloud.
  3. Configura la replicación de Q.
  4. Inicia la replicación de Q (ya sea con carga manual o carga automática).
  5. Verifica que las dos implementaciones estén sincronizadas.
  6. Apunta tus aplicaciones a la instancia de Google Cloud. Detén la replicación.

En el siguiente diagrama, se muestra una posible solución de replicación de Q.

Arquitectura de la replicación de Q del entorno de origen en Google Cloud.

El entorno de origen usa la replicación de Q de IBM para enviar los cambios de la base de datos a IBM MQ y al entorno de destino, lo que extiende un clúster de Db2 a Compute Engine.

En este enfoque, debes mover tu clúster de Db2 existente a Compute Engine y depender de HADR para la transferencia de datos entre nodos.

Usa este enfoque si cumples con las siguientes condiciones:

  • No quieres implementar un clúster completamente nuevo en Compute Engine.
  • No puedes aprovechar Migrate to VMs.
  • No puedes usar una de las opciones de replicación.
  • No puedes usar un producto de un socio (licencias, costos o cumplimiento, entre otros motivos).

Qué hacer si tu versión de Db2 no es compatible con la instancia en espera auxiliar

Puedes realizar lo siguiente:

  1. Implementa una instancia de Db2 en Compute Engine.
  2. Realiza una copia de seguridad de tu instancia primaria.
  3. Restablece la instancia de Db2 en Compute Engine desde la copia de seguridad.
  4. Quita la instancia en espera de la configuración de HADR.
  5. Adjunta la instancia de Db2 de Compute Engine como instancia en espera (puedes elegir tu modo de sincronización, pero debido a una posible latencia mayor, ASYNC o NEARASYNC pueden ser de preferencia).
  6. Conmuta por error a la instancia de Db2 de Compute Engine y haz que sea la primaria de HADR.
  7. Crea otra instancia de Db2 de Compute Engine, restablécela desde una copia de seguridad y configúrala como HADR en espera.

En el primer paso del siguiente diagrama, se muestra la instancia de Db2 que recién se creó en Google Cloud configurada como la en espera principal de la primaria de Db2 de origen.

Arquitectura de la instancia de Db2 en Google Cloud configurada como instancia en espera principal.

En el diagrama anterior, la instancia de Google Cloud se convierte en la primaria de HADR. Luego, debes quitar la en espera principal de origen y adjuntar otra instancia de Db2 en Compute Engine como instancia en espera principal.

Qué hacer si tu versión de Db2 es compatible con la instancia en espera auxiliar

Una opción es seguir los mismos pasos que cuando la versión de Db2 no admite la instancia en espera auxiliar y, al final, mover también las instancias en espera auxiliares.

Otra opción es aprovechar las réplicas auxiliares para una migración más tolerante a errores a Google Cloud, ya que no tienes la instancia primaria o la en espera principal en tu entorno de origen y la otra en Google Cloud. En la siguiente lista, se describen los pasos de esta segunda opción:

  1. Implementa instancias de Db2 en Compute Engine (primaria, principal y auxiliar si es necesario) en sus ubicaciones.
  2. Quita los nodos en espera auxiliares del clúster de origen.
  3. Configura los nodos que se convertirán en el primario y el principal de las instancias en espera auxiliares del clúster de origen.
  4. Realiza la apropiación de una de las instancias de Compute Engine. Esta instancia se convierte en la instancia primaria. Configura una de las otras instancias de Compute Engine como una en espera principal de la instancia primaria.

En el primer paso que se indica en el siguiente diagrama, se muestran dos de las instancias de Db2 que se crearon recién en Compute Engine.

Arquitectura de instancias auxiliares de Db2 en Google Cloud.

Las instancias se configuran como en espera auxiliares de la instancia primaria de Db2 de origen en lugar de las instancias auxiliares en el entorno de origen. Luego, después de invocar la apropiación de una de las instancias de Compute Engine, esa instancia se convierte en la primaria de HADR, y otra se configura como en espera principal. En el último paso, hay otras dos instancias que se configuran como en espera auxiliares.

Productos de socios

Google cuenta con varios socios que tienen productos para ayudar con esta migración. La mayoría de estos productos aprovechan los CDC para replicar datos entre Db2 de origen y de destino. Estos productos no son productos de Google Cloud, y debes verificar las licencias y los precios de cada producto o servicio. Por lo general, este servicio replica los datos de un clúster existente en otro que creas en Google Cloud, y el enfoque general es similar a las situaciones de replicación descritas en este documento.

Los siguientes son algunos productos asociados:

¿Qué sigue?