Análisis de los criterios de decisión para la selección de herramientas y el modelo de migración
Ahora que hemos explorado las opciones de metodologías de migración y opciones de herramientas, podemos explorar los criterios de decisión que debemos tener en cuenta para ejecutar nuestras migraciones al servidor flexible de Azure Database for PostgreSQL. Los tres criterios principales que nos ayudan a tomar nuestras opciones son Tiempo de inactividad, Ubicación de la base de datos de origen y Personalización.
Tiempo de inactividad
El tiempo de inactividad es una faceta clave de las actividades de migración y la duración aceptable para las partes interesadas nos ayuda a decidir si tenemos que realizar una actividad de migración sin conexión o en línea.
Normalmente, las actividades de migración se planean con antelación para asegurarse de que se completan los controles de cambio adecuados y la gobernanza asociada para la actividad. Este planeamiento permite que un diálogo con las partes interesadas clave comprenda cuánto tiempo puede estar sin conexión el sistema. En esta situación, es aconsejable saber cuánto tiempo tomarán las diferentes opciones para poder establecer duraciones mínimas y máximas estimadas de tiempo de inactividad.
Establecer el tiempo de inactividad mínimo necesario para realizar una transición de la aplicación es clave. En última instancia, este tiempo es la duración del período en que tiene que desconectar el sistema incluso para una actividad de migración en línea (o con un tiempo de inactividad mínimo). La complejidad de la aplicación va a dictar esta escala temporal. Para una aplicación relativamente sencilla, este proceso podría ser un caso de detener un servicio, actualizar un archivo de configuración y volver a activarlo. En entornos más complejos, este proceso puede tardar mucho más si hay varios servidores y capas de aplicación en juego.
Comprender la duración necesaria para las actividades de migración en línea o sin conexión es el siguiente elemento importante relacionado con el tiempo de inactividad. Si se trata de una migración sin conexión, el tiempo necesario para extraer, transferir y cargar los datos del origen al destino seguido de la validación y la comprobación es el tiempo de inactividad. Este tiempo de inactividad se intercala entre el tiempo necesario para desactivar la aplicación o la carga de trabajo y el tiempo necesario para volver a activar la aplicación o la carga de trabajo.
Si se trata de migraciones en línea (tiempo de inactividad mínimo), el tiempo de inactividad es la duración necesaria para sincronizar los cambios finales del origen al destino una vez desactivada la aplicación. Agregue a ese tiempo de inactividad, las actividades de validación y comprobación antes de volver a configurar y habilitar la aplicación o carga de trabajo.
Una vez que tengamos esta información, podemos examinar los elementos técnicos de la migración para ayudar a establecer cuáles son nuestras opciones viables.
Ubicación de la base de datos de origen
La ubicación de origen de las bases de datos que se van a migrar desempeña una parte debido a las restricciones que probablemente estén en vigor para cualquier configuración determinada.
Orígenes locales o externos a Azure
En el caso de una base de datos situada localmente o fuera de Azure, el principal obstáculo suele ser la conectividad de red entre el origen y el destino. Los tres puntos que se deben tener en cuenta aquí son ancho de banda, latencia y volumen de datos. Una vez que comprendamos estos puntos, podemos tomar una decisión informada sobre qué tipo de migración es viable.
Si tenemos un gran volumen de datos para migrar y una cantidad proporcionalmente pequeña de ancho de banda, es probable que un simple volcado y restauración no sea viable. Mientras que si tenemos un gran volumen de datos y una gran cantidad de ancho de banda, entonces es menos preocupante.
Del mismo modo, si se trata de una migración en línea en la que se va a realizar la sincronización de datos, la latencia es uno de los factores clave. Si la latencia es alta, podría haber efectos adversos en el rendimiento del sistema porque el proceso de sincronización tarda demasiado tiempo en completarse.
Un factor importante que también se debe tener en cuenta al migrar desde otros proveedores de nube es si cobran por salida de datos. Si es así, poder minimizar la superficie física de los datos que se transfieren podría ser una consideración. En situaciones como esta, la tecnología de compresión puede ser importante para volcados de memoria o flujos de datos usados para la sincronización.
Otros servicios basados en Azure
Habrá situaciones en las que desea migrar de otros servicios basados en Azure al servidor flexible de Azure Database for PostgreSQL. Estas bases de datos de origen podrían estar en máquinas virtuales, contenedores de Azure o, posiblemente, en un servidor único de Azure Database for PostgreSQL. Si es así, hay un conjunto diferente de consideraciones para explorar, pero al mismo tiempo, varias oportunidades para beneficiarse de las optimizaciones dentro de los servicios de Azure para estos escenarios.
Personalización
El área final de consideración es la cantidad de personalización necesaria o deseada. Esta consideración puede tomar la forma de necesitar modificar la estructura de la base de datos de origen para admitir la replicación de datos, como alternativa, podría significar lo fácil que es automatizar a través del scripting.
Un buen ejemplo sería automatizar la migración sin conexión de una base de datos a través de pg_dump y pg_restore pero, al mismo tiempo, incluir la compresión y descompresión de los archivos de volcado de memoria.
Toma de decisiones
Ahora que pasamos por el proceso para recopilar toda esta información, podemos trabajar con las partes interesadas para determinar la mejor opción para un escenario determinado. Al tomar la decisión sobre qué metodología y tecnología se establece para usar, es importante no solo trabajar con las partes interesadas de la empresa, sino también con las partes interesadas técnicas. Esta colaboración ayuda a evitar una situación en la que la empresa impulsa una migración de tiempo de inactividad mínima, que el equipo técnico no está en condiciones de ofrecer debido a restricciones de personal, recursos o tecnología.
Lo clave aquí es administrar las expectativas y tener un diálogo abierto y honesto. También es importante asegurarse de que la empresa toma posesión de las tareas de validación que se encuentran fuera de la misión de los equipos técnicos que entregan la migración de la base de datos. Esta validación puede implicar comprobaciones de coherencia y validación de datos y pruebas de experiencia del usuario.