Administración de bases de datos de múltiples nubes: Arquitecturas, casos de uso y prácticas recomendadas

Last reviewed 2022-10-28 UTC

En este documento, se describen las arquitecturas de implementación, los casos de uso y las prácticas recomendadas para la administración de bases de datos en múltiples nubes. Está dirigido a ingenieros y arquitectos que diseñan y, también, implementan aplicaciones con estado dentro de múltiples nubes, y entre ellas.

Las arquitecturas de aplicaciones de múltiples nubes que acceden a bases de datos dependen del caso de uso. Ninguna arquitectura de aplicaciones con estado única puede admitir todos los casos de uso de múltiples nubes. Por ejemplo, la mejor solución de base de datos para un caso de uso de aumentos de actividad en la nube es diferente a la mejor solución de base de datos para una aplicación que se ejecuta en varios entornos de nube de forma simultánea.

Para las nubes públicas como Google Cloud, existen varias tecnologías de bases de datos que se ajustan a casos de uso específicos de múltiples nubes. Para implementar una aplicación en varias regiones dentro de una sola nube pública, una opción es usar una base de datos multirregional, administrada por el proveedor y de nube pública, como Spanner. A fin de implementar una aplicación para que sea portátil en nubes públicas, una base de datos independiente de la plataforma podría ser una mejor opción, como PostgreSQL.

En este documento, se presenta una definición de una aplicación de base de datos con estado seguida de un análisis de casos de uso de bases de datos en múltiples nubes. Luego, se presenta una clasificación de sistema de base de datos detallada para las arquitecturas de implementación de múltiples nubes basadas en los casos de uso.

En el documento, también se presenta un árbol de decisión para seleccionar bases de datos que describe los puntos de decisión clave a fin de seleccionar una tecnología de base de datos adecuada. Concluye con un análisis sobre las prácticas recomendadas para la administración de bases de datos en múltiples nubes.

Términos y definiciones clave

En esta sección, se proporciona terminología y se define la aplicación de base de datos con estado genérica que se usa en este documento.

Terminología

  • Nube pública. Una nube pública proporciona una infraestructura de multiusuario (por lo general, global) y servicios que los clientes pueden usar para ejecutar sus cargas de trabajo de producción. Google Cloud es una nube pública que proporciona muchos servicios administrados, incluidos GKE, GKE Enterprise y bases de datos administradas.
  • Nube híbrida. Una nube híbrida es una combinación de una nube pública con uno o más centros de datos locales. Los clientes de la nube híbrida pueden combinar sus servicios locales con servicios adicionales que proporciona una nube pública.
  • Múltiples nubes. Una estrategia de múltiples nubes es una combinación de varias nubes públicas y centros de datos locales. Una nube híbrida es un subconjunto de las múltiples nubes.
  • Ubicación de la implementación. Una ubicación de infraestructura es una ubicación física que puede implementar y ejecutar cargas de trabajo, incluidas aplicaciones y bases de datos. Por ejemplo, en Google Cloud, las ubicaciones de implementación son zonas y regiones. En un nivel abstracto, una región o zona de la nube pública y un centro de datos local son ubicaciones de implementación.

Aplicaciones de bases de datos con estado

Para definir casos de uso de múltiples nubes, se usa una arquitectura de aplicaciones de bases de datos con estado genéricas en este documento, como se muestra en el siguiente diagrama.

Arquitectura de aplicaciones con estado genéricas

En el diagrama, se muestran los siguientes componentes:

  • Base de datos. Una base de datos puede ser de instancia única, de varias instancias o distribuida, implementada en nodos de procesamiento o disponible como un servicio administrado en la nube.
  • Servicios de aplicaciones. Estos servicios se combinan como una aplicación que implementa la lógica empresarial. Los servicios de aplicaciones pueden ser cualquiera de los siguientes:
    • Microservicios en Kubernetes.
    • Procesos generales que se ejecutan en una o más máquinas virtuales.
    • Una aplicación monolítica en una máquina virtual grande.
    • Código sin servidores en Cloud Functions o Cloud Run. Algunos servicios de aplicaciones pueden acceder a la base de datos. Es posible implementar cada servicio de aplicaciones varias veces. Cada implementación de un servicio de aplicaciones es una instancia de ese servicio.
  • Clientes de aplicaciones. Los clientes de aplicaciones acceden a la funcionalidad que proporcionan los servicios de aplicaciones. Los clientes de aplicaciones pueden ser una de las siguientes opciones:
    • Clientes implementados, en los que el código se ejecuta en una máquina, laptop o teléfono celular.
    • Clientes no implementados, en los que el código del cliente se ejecuta en un navegador. Las instancias de clientes de aplicaciones siempre acceden a una o más instancias de servicios de aplicaciones.

En el contexto del análisis de una base de datos en múltiples nubes, la abstracción de la arquitectura de una aplicación con estado consta de una base de datos, servicios de aplicaciones y clientes de aplicaciones. En la implementación de una aplicación, los factores como el uso de sistemas operativos o los lenguajes de programación que se usan pueden variar. Sin embargo, estos detalles no afectan la administración de bases de datos de múltiples nubes.

Colas y archivos como servicios de almacenamiento de datos

Hay muchos recursos de persistencia disponibles para los servicios de aplicaciones a fin de conservar datos. Estos recursos incluyen bases de datos, colas y archivos. Cada recurso de persistencia proporciona modelos de datos de almacenamiento y patrones de acceso que se especializan en estos modelos. Si bien las aplicaciones usan colas, sistemas de mensajería y sistemas de archivos, en la siguiente sección, el enfoque principal es la base de datos.

Aunque las mismas consideraciones para factores como la ubicación de la implementación, el uso compartido del estado y la replicación síncrona y asíncrona para bases de datos de múltiples nubes se aplican a colas y archivos, este análisis está fuera del alcance de este documento.

Redes

En la arquitectura de una aplicación con estado genérica (que se vuelve a mostrar en el siguiente diagrama), cada flecha entre los componentes representa una relación de comunicación a través de una conexión de red, por ejemplo, un cliente de aplicaciones que accede a un servicio de aplicaciones.

Arquitectura de aplicaciones con estado genéricas

Una conexión puede estar dentro de una zona, o bien entre zonas, regiones o nubes. Pueden existir conexiones entre cualquier combinación de ubicaciones de implementación. En entornos de múltiples nubes, las herramientas de redes en diferentes nubes son una consideración importante y hay varias opciones que puedes usar. Para obtener más información sobre las herramientas de redes en diferentes nubes, consultaConéctate a Google Cloud: información sobre tus opciones de herramientas de redes.

En los casos de uso de este documento, se asume lo siguiente:

  • Que existe una conexión de red segura entre las nubes.
  • Que las bases de datos y sus componentes pueden comunicarse entre sí.

Desde una perspectiva no funcional, el tamaño de la red, lo que significa la capacidad de procesamiento y la latencia, puede afectar la latencia y la capacidad de procesamiento de la base de datos. Desde una perspectiva funcional, por lo general, las herramientas de redes no tienen ningún efecto.

Casos de uso de bases de datos en múltiples nubes

En esta sección, se presenta una selección de los casos de uso más comunes para la administración de bases de datos de múltiples nubes. Para estos casos de uso, se asume que hay conectividad de red segura entre las nubes y los nodos de la base de datos.

Migración de aplicaciones

En el contexto de la administración de bases de datos de múltiples nubes, la migración de aplicaciones se refiere a la migración de una aplicación, todos los servicios de la aplicación y la base de datos de la nube actual a una nube de destino. Hay muchas razones por las que una empresa puede decidir migrar una aplicación, por ejemplo, a fin de evitar una situación competitiva con el proveedor de servicios en la nube, para modernizar la tecnología o para reducir el costo total de propiedad (TCO).

En la migración de aplicaciones, el objetivo es detener la producción en la nube actual y continuarla en la nube de destino después de que se complete la migración. Los servicios de aplicaciones deben ejecutarse en la nube de destino. Para implementar los servicios, se puede usar un enfoque lift-and-shift. En este enfoque, se implementa el mismo código en la nube de destino. Para volver a implementar el servicio, se pueden usar las tecnologías modernas de la nube disponibles en la nube de destino.

Desde la perspectiva de la base de datos, ten en cuenta las siguientes opciones alternativas para la migración de aplicaciones:

  • Migración lift-and-shift de bases de datos: Si el mismo motor de base de datos está disponible en la nube de destino, es posible realizar una migración lift-and-shift de la base de datos para crear una implementación idéntica en la nube de destino.
  • Migración lift-and-shift de bases de datos a equivalentes administrados: una base de datos autoadministrada se puede migrar a una versión administrada del mismo motor de base de datos si la nube de destino lo proporciona.
  • Modernización de bases de datos: Diferentes nubes ofrecen diferentes tecnologías de bases de datos. Las bases de datos administradas por un proveedor de servicios en la nube pueden tener ventajas, como los Acuerdos de Nivel de Servicio (ANS) más estrictos, la escalabilidad y la recuperación ante desastres automática.

Sin importar la estrategia de implementación, la migración de una base de datos es un proceso que tarda tiempo debido a la necesidad de transferir datos de la nube actual a la nube de destino. Si bien es posible seguir un enfoque de importación y exportación que incurra en tiempo de inactividad, es preferible la migración con tiempo de inactividad mínimo o cero. Este enfoque minimiza el tiempo de inactividad de la aplicación y tiene el menor impacto en una empresa y sus clientes.

Recuperación ante desastres

La recuperación ante desastres se refiere a la capacidad de una aplicación de continuar proporcionando servicios a los clientes de aplicaciones durante una interrupción regional. A fin de garantizar la recuperación ante desastres, una aplicación debe implementarse en al menos dos regiones y estar lista para ejecutarse en cualquier momento. En producción, la aplicación se ejecuta en la región principal. Sin embargo, si se produce una interrupción, una región secundaria se convierte en la región principal. Los siguientes son modelos diferentes de preparación para la recuperación ante desastres:

  • En espera activa. La aplicación se implementa en dos o más regiones (primaria y secundaria) y funciona por completo en cada región. Si la región principal falla, la aplicación en la región secundaria puede aceptar el tráfico de los clientes de inmediato.
  • En espera pasiva. La aplicación se ejecuta en la región principal; sin embargo, está lista para iniciarse en una región secundaria (pero no en ejecución). Si la región principal falla, la aplicación se inicia en la región secundaria. Una interrupción de la aplicación se produce hasta que la aplicación pueda ejecutarse y proporcionar todos sus servicios a los clientes de la aplicación.
  • Sin espera. En este modelo, el código de la aplicación está listo para su implementación, pero aún no se implementa en la región secundaria (y, por lo tanto, no usa ningún recurso implementado). Si una región principal tiene una interrupción, la primera implementación de la aplicación debe hacerse en la región secundaria. Esta implementación coloca la aplicación en el mismo estado que una espera pasiva, lo que significa que debe iniciarse. En este enfoque, la interrupción de la aplicación es más larga en comparación con el caso de espera pasiva, ya que la implementación de la aplicación primero debe ocurrir, lo que incluye la creación de recursos en la nube.

Desde la perspectiva de la base de datos, los modelos de preparación que se analizaron en la lista anterior corresponden a los siguientes enfoques de bases de datos:

  • Base de datos sincronizada de forma transaccional. Esta base de datos corresponde al modelo en espera activa. Cada transacción en la región principal se confirma en la coordinación síncrona en una región secundaria. Cuando la región secundaria se convierte en la región principal durante una interrupción, la base de datos es coherente y está disponible de inmediato. En este modelo, el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO) son cero.
  • Base de datos replicada de forma asíncrona. Esta base de datos también corresponde al modelo en espera activa. Debido a que la replicación de la base de datos de la región principal a la secundaria es asíncrona, existe la posibilidad de que, si la región principal falla, algunas transacciones puedan replicarse en la región secundaria. Si bien la base de datos de la región secundaria está lista para la carga de producción, es posible que no tenga los datos más actuales. Por esta razón, la aplicación puede generar una pérdida de transacciones que no se pueden recuperar. Debido a este riesgo, este enfoque tiene un RTO de cero, pero el RPO es mayor que cero.
  • Base de datos inactiva. Esta base de datos corresponde al modelo en espera pasiva. La base de datos se crea sin datos. Cuando la región principal falla, los datos deben cargarse en la base de datos inactiva. Para habilitar esta acción, se debe realizar una copia de seguridad normal en la región principal y transferirse a la región secundaria. La copia de seguridad puede ser completa o incremental, según lo que admita el motor de la base de datos. En cualquier caso, la base de datos vuelve a la última copia de seguridad y, desde la perspectiva de la aplicación, se pueden perder muchas transacciones en comparación con la región principal. Si bien este enfoque puede ser rentable, el valor se ve mitigado por el riesgo de que todas las transacciones desde la última copia de seguridad disponible se pierdan debido a que el estado de la base de datos no está actualizado.
  • Sin base de datos. Este modelo es equivalente al caso sin espera. La región secundaria no tiene instalada una base de datos y, si la región principal falla, se debe crear una base de datos. Después de que se crea la base de datos, como en el caso de la base de datos inactiva, esta debe cargarse con datos antes de que esté disponible para la aplicación.

Los enfoques de recuperación ante desastres que se analizan en este documento también se aplican si se usa una nube principal y una secundaria en lugar de una región principal y una secundaria. La principal diferencia es que, debido a la heterogeneidad de la red entre las nubes, la latencia entre las nubes puede aumentar en comparación con la distancia de la red entre las regiones dentro de una nube.

La probabilidad de que falle una nube completa es menor que la probabilidad de que falle una región. Sin embargo, de todos modos podría ser útil que las empresas tengan una aplicación implementada en dos nubes. Mediante este enfoque, puedes proteger a una empresa contra fallas o ayudarla cumplir con las normativas comerciales o del sector.

Otro enfoque de recuperación ante desastres es tener una región principal y una secundaria, y una nube principal y una secundaria. Este enfoque permite que las empresas elijan el mejor proceso de recuperación ante desastres para abordar una situación de falla. Para permitir que se ejecute una aplicación, se puede usar una región secundaria o una nube secundaria, según la gravedad de la interrupción.

Cloud bursting

Aumentos de actividad en la nube hace referencia a una configuración que permite el escalamiento vertical del tráfico del cliente de aplicaciones en diferentes ubicaciones de implementación. Una aplicación aumenta la actividad cuando la demanda de capacidad aumenta y una ubicación en espera proporciona capacidad adicional. Una ubicación principal admite el tráfico normal, mientras que una ubicación en espera puede proporcionar capacidad adicional en caso de que el tráfico del cliente de la aplicación aumente más allá de lo que la ubicación principal puede admitir. La ubicación principal y la ubicación en espera tienen instancias de servicio de aplicación implementadas.

El patrón de aumentos de actividad en la nube se implementa en nubes en las que una nube es la principal y otra es la nube en espera. Se usa en un contexto de nube híbrida para aumentar una cantidad limitada de recursos de procesamiento en centros de datos locales con recursos elásticos de computación en la nube en una nube pública.

Para la compatibilidad con las bases de datos, están disponibles las siguientes opciones:

  • Implementación en la ubicación principal. En esta implementación, la base de datos solo se implementa en la ubicación principal y no en la ubicación en espera. Cuando una aplicación aumenta la actividad, la aplicación en la ubicación en espera accede a la base de datos en la ubicación principal.
  • Implementación en ubicación principal y en espera. Esta implementación admite la ubicación principal y la que está en espera. Una instancia de base de datos se implementa en ambas ubicaciones y las instancias de servicios de aplicaciones de esa ubicación acceden a ella, en especial, en el caso de aumentos de actividad. Al igual que en la recuperación ante desastres dentro de las nubes y entre ellas, las dos bases de datos pueden sincronizarse de forma transaccional o de forma asíncrona. En la sincronización asíncrona, puede haber un retraso. Si las actualizaciones se realizan en la ubicación en espera, estas actualizaciones deben propagarse a la ubicación principal. Si es posible realizar actualizaciones simultáneas en ambas ubicaciones, se debe implementar la resolución de conflictos.

El patrón de aumentos de actividad en la nube es un caso de uso común en las nubes híbridas para aumentar la capacidad en los centros de datos locales. También es un enfoque que se puede usar en nubes públicas cuando los datos deben permanecer dentro de un país. En los casos en los que una nube pública tiene solo una región en un país, es posible generar un aumento de actividad en una región de una nube pública diferente en el mismo país. Este enfoque garantiza que los datos permanezcan dentro del país y, al mismo tiempo, se abordan las restricciones de recursos en la región de las regiones de nube pública.

El mejor uso de los servicios en la nube

Algunas aplicaciones requieren productos y servicios en la nube especializados que no están disponibles en una sola nube. Por ejemplo, una aplicación puede realizar un procesamiento de lógica empresarial de datos comerciales en una nube y estadísticas de los datos comerciales en otra nube. En este caso de uso, las partes de procesamiento de lógica empresarial y las partes de estadísticas de la aplicación se implementan en nubes diferentes.

Desde la perspectiva de la administración de datos, los casos de uso son los siguientes:

  • Datos particionados. Cada parte de la aplicación tiene su propia base de datos (partición independiente) y ninguna de las bases de datos está conectada directamente entre sí. La aplicación que administra los datos escribe dos veces cualquier dato que deba estar disponible en ambas bases de datos (particiones).
  • Base de datos replicada de forma asíncrona. Si los datos de una nube deben estar disponibles en la otra, puede que una relación de replicación asíncrona sea apropiada. Por ejemplo, si una aplicación de estadísticas requiere el mismo conjunto de datos o un subconjunto de este para una aplicación empresarial, este último se puede replicar entre las nubes.
  • Base de datos sincronizada de forma transaccional. Estos tipos de bases de datos te permiten hacer que los datos estén disponibles para ambas partes de la aplicación. Cada actualización de cada una de las aplicaciones tiene coherencia transaccional y está disponible para ambas bases de datos (particiones) de inmediato. Las bases de datos sincronizadas transaccionales actúan de manera eficaz como una sola base de datos distribuida.

Servicios distribuidos

Un servicio distribuido se implementa y ejecuta en dos o más ubicaciones de implementación. Es posible implementar todas las instancias de servicio en todas las ubicaciones de implementación. Como alternativa, es posible implementar algunos servicios en todas las ubicaciones y otros solo en una de las ubicaciones, en función de factores como la disponibilidad de hardware o la carga limitada esperada.

Los datos de una base de datos sincronizada de forma transaccional son coherentes en todas las ubicaciones. Por lo tanto, esa base de datos es la mejor opción para implementar instancias de servicio en todas las ubicaciones de implementación.

Cuando usas una base de datos replicada asíncrona, existe el riesgo de que el mismo elemento de datos se modifique en dos ubicaciones de implementación de forma simultánea. Para determinar cuál de los dos cambios conflictivos es el estado coherente final, se debe implementar una estrategia de resolución de conflictos. Aunque es posible implementar una resolución de conflictos, no siempre es fácil y, a veces, se requiere intervención manual para que los datos vuelvan a un estado coherente.

Reubicación y conmutación por error del servicio distribuido

Si una región de nube completa falla, se inicia la recuperación ante desastres. Si falla un solo servicio en una aplicación de base de datos con estado (no la región ni aplicación la completa), el servicio se debe recuperar y reiniciar.

Un enfoque inicial para la recuperación ante desastres es reiniciar el servicio con errores en su ubicación de implementación original (un enfoque de reinicio en su ubicación). Tecnologías como Kubernetes reinician un servicio de forma automática en función de su configuración.

Sin embargo, si este enfoque de reinicio en su ubicación no tiene éxito, una alternativa es reiniciar el servicio en una ubicación secundaria. El servicio conmuta por error de su ubicación principal a una ubicación secundaria. Si la aplicación se implementa como un conjunto de servicios distribuidos, la conmutación por error de un solo servicio se puede realizar de forma dinámica.

Desde la perspectiva de la base de datos, el reinicio del servicio en la ubicación de implementación original no requiere una implementación de base de datos específica. Cuando un servicio se traslada a una ubicación de implementación alternativa y el servicio accede a la base de datos, se aplican los mismos modelos de preparación que se analizaron en Servicios distribuidos anteriormente en este documento.

Si un servicio se reubicará de forma temporal y si una empresa acepta latencias más altas durante la reubicación, el servicio podría acceder a la base de datos en las ubicaciones de implementación. Aunque el servicio se reubica, este sigue accediendo a la base de datos de la misma manera que lo haría desde su ubicación de implementación original.

Implementación que depende del contexto

En general, una implementación de aplicación única para entregar servicios a todos los clientes de aplicaciones incluye todos sus servicios y bases de datos de aplicaciones. Sin embargo, hay casos de uso excepcionales. Una implementación de aplicación única puede entregar servicios a solo un subconjunto de clientes (según criterios específicos), lo que significa que se necesita más de una implementación de aplicación. Cada implementación entrega servicios a un subconjunto de clientes diferente y todas las implementaciones juntas entregan servicios a todos los clientes.

Estos son algunos ejemplos de casos de uso para una implementación que depende del contexto:

  • Cuando se implementa una aplicación multiusuario para la que se implementa una aplicación para todos los usuarios pequeños, otra aplicación se implementa por cada 10 usuarios medianos y se implementa una aplicación para cada usuario premium.
  • Cuando se necesita separar clientes, por ejemplo, clientes empresariales y gubernamentales.
  • Cuando se necesita separar los entornos de desarrollo, etapa de pruebas y producción.

Desde la perspectiva de la base de datos, es posible implementar una base de datos por cada implementación de aplicación en una estrategia de implementación de uno a uno. Como se muestra en el siguiente diagrama, esta estrategia es un enfoque sencillo en el que se crean datos particionados porque cada implementación tiene su propio conjunto de datos.

Cada implementación de aplicación incluye una base de datos independiente.

En el diagrama anterior, se muestra lo siguiente:

  • Una configuración con tres implementaciones de una aplicación.
  • Cada conjunto de datos tiene su base de datos respectiva.
  • No se comparten datos entre las implementaciones.

En muchas situaciones, la implementación de uno a uno es la estrategia más adecuada. Sin embargo, existen alternativas.

En el caso de los usuarios múltiples, los usuarios pueden reubicarse. Un usuario pequeño puede convertirse en un usuario mediano y tener que trasladarse a una aplicación diferente. En este caso, las implementaciones de bases de datos independientes requieren la migración de bases de datos. Si se implementa una base de datos distribuida y todas las implementaciones la usan al mismo tiempo, todos los datos de usuario residen en un sistema de base de datos único. Por este motivo, mover un usuario entre bases de datos no requiere la migración de la base de datos. En el siguiente diagrama, se muestra un ejemplo de este tipo de base de datos:

Todas las implementaciones de la aplicación comparten una base de datos distribuida.

En el diagrama anterior, se muestra lo siguiente:

  • Tres implementaciones de una aplicación.
  • Todas las implementaciones comparten una única base de datos distribuida.
  • Las aplicaciones pueden acceder a todos los datos de cada implementación.
  • No se implementó la partición de datos.

Si una empresa suele reubicar usuarios como parte de las operaciones de ciclo de vida, la replicación de bases de datos puede ser una alternativa útil. En este enfoque, los datos de usuarios se replican entre las bases de datos antes de la migración de usuarios. En este caso, las bases de datos independientes se usan para diferentes implementaciones de aplicación y solo se configuran para la replicación justo antes y durante la migración de usuarios. En el siguiente diagrama, se muestra una replicación temporal entre dos implementaciones de aplicaciones durante una migración de usuarios.

Replicación temporal de la base de datos entre dos implementaciones de aplicación.

En el diagrama anterior, se muestran tres implementaciones de una aplicación con tres bases de datos independientes que contienen los datos asociados con cada implementación. Se puede configurar una migración de base de datos temporal para migrar datos de una base de datos a otra.

Portabilidad de aplicaciones

La portabilidad de aplicaciones garantiza que una aplicación se pueda implementar en diferentes ubicaciones de implementación, en especial en nubes diferentes. Esta portabilidad garantiza que una aplicación se pueda migrar en cualquier momento, sin necesidad de realizar una reingeniería específica de la migración o un desarrollo de aplicación adicional para preparar la migración de una aplicación.

Para garantizar la portabilidad de aplicaciones, puedes usar uno de los siguientes enfoques, que se describen más adelante en esta sección:

  • Portabilidad basada en el sistema
  • Compatibilidad de API
  • Portabilidad basada en la funcionalidad

La portabilidad basada en el sistema usa los mismos componentes técnicos que se usan en todas las implementaciones posibles. Para garantizar la portabilidad basada en el sistema, cada tecnología debe estar disponible en todas las ubicaciones de implementación posibles. Por ejemplo, si una base de datos como PostgreSQL es candidata, su disponibilidad en todas las posibles ubicaciones de implementación debe verificarse para el período esperado. Lo mismo sucede con todas las demás tecnologías, por ejemplo, lenguajes de programación y tecnologías de infraestructura. Como se muestra en el siguiente diagrama, este enfoque establece un conjunto de funciones comunes en todas las ubicaciones de implementación según la tecnología.

Portabilidad mediante la implementación de la misma tecnología.

En el diagrama anterior, se muestra una implementación de aplicación portátil en la que la aplicación espera exactamente el mismo sistema de base de datos en cada ubicación en la que se implementa. Debido a que se usa el mismo sistema de base de datos en cada ubicación, la aplicación es portátil. La aplicación puede esperar que se use exactamente el mismo sistema de base de datos en toda la implementación. Por lo tanto, se puede suponer la misma interfaz y comportamiento de sistema de base de datos.

En el contexto de las bases de datos, en el sistema de compatibilidad con la API, el cliente usa una biblioteca de acceso a base de datos específica (por ejemplo, una biblioteca cliente de MySQL) para garantizar que se pueda conectar a cualquier implementación de cumplimiento que pueda estar disponible en un entorno de nube. En el siguiente diagrama, se ilustra la compatibilidad con la API.

Portabilidad mediante la implementación de una tecnología diferente que admita la misma API

En el diagrama anterior, se muestra la portabilidad de la aplicación en función de la API de database system, en lugar del sistema de base de datos. Aunque los sistemas de bases de datos pueden ser diferentes en cada una de las ubicaciones, la API es la misma y expone la misma funcionalidad. La aplicación es portátil porque puede adoptar la misma API en cada ubicación, incluso si el sistema de base de datos subyacente es una tecnología de base de datos diferente.

En la portabilidad basada en la funcionalidad, se pueden usar en diferentes nubes diferentes tecnologías que proporcionen la misma funcionalidad. Por ejemplo, es posible restringir el uso de bases de datos al modelo relacional. Debido a que cualquier sistema de base de datos relacional puede admitir la aplicación, se pueden usar diferentes sistemas de bases de datos en diferentes versiones y en diferentes nubes sin afectar la portabilidad de la aplicación. Una desventaja de la portabilidad basada en la funcionalidad es que solo puede usar las partes del modelo de base de datos que admiten todos los sistemas de bases de datos relacionales. En lugar de un sistema de base de datos compatible con todas las nubes, se debe usar un modelo de base de datos. En el siguiente diagrama, se muestra una arquitectura de ejemplo para la portabilidad basada en la funcionalidad.

Portabilidad mediante la implementación de una tecnología y una API diferentes, pero el mismo modelo de base de datos

Como se muestra en el diagrama anterior, la API de database system y el sistema de base de datos pueden ser diferentes en cada ubicación. Para garantizar la portabilidad, la aplicación solo debe usar las partes de cada sistema de base de datos y cada API que estén disponibles en cada ubicación. Debido a que solo un subconjunto de cada sistema de base de datos suele estar disponible en cada ubicación, la aplicación debe restringir su uso a ese subconjunto.

A fin de garantizar la portabilidad para todas las opciones de esta sección, la arquitectura completa debe implementarse de forma continua en todas las ubicaciones de destino. Todos los casos de pruebas de unidades y sistemas deben ejecutarse en estas implementaciones. Estos son requisitos esenciales para que los cambios en las infraestructuras y tecnologías se detecten con anticipación y se aborden.

Prevención de dependencia de proveedores

La prevención de dependencia de un solo proveedor ayuda a mitigar el riesgo de depender de una tecnología y un proveedor específicos. Es superficialmente similar a la portabilidad de aplicaciones. La prevención de dependencia de un solo proveedor se aplica a todas las tecnologías que se usan, no solo a los servicios en la nube. Por ejemplo, si MySQL se usa como un sistema de base de datos y se instala en máquinas virtuales en nubes, no hay una dependencia desde la perspectiva de la nube, pero sí hay dependencia de MySQL. Una aplicación que es portátil en las nubes igualmente puede depender de tecnologías proporcionadas por proveedores diferentes a los de la nube.

Para evitar la dependencia de proveedores, se deben reemplazar todas las tecnologías. Por esta razón, es necesaria una abstracción completa y estructurada de toda la funcionalidad de la aplicación a fin de que cada servicio de la aplicación se pueda volver a implementar en una base de tecnología diferente sin afectar la forma en que se implementa la aplicación. Desde la perspectiva de la base de datos, esta abstracción se puede realizar mediante la separación del uso de un modelo de base de datos de un sistema de administración de bases de datos en particular.

Sistema de administración de bases de datos de producción existente

Si bien muchas aplicaciones de múltiples nubes se desarrollan con sistemas de bases de datos como parte de su diseño, muchas empresas desarrollan aplicaciones de múltiples nubes como parte de su esfuerzo de modernización de aplicaciones. Estas aplicaciones se desarrollan con el supuesto de que la aplicación recién diseñada e implementada accede a las bases de datos existentes.

Existen muchos motivos para no incorporar las bases de datos existentes en un esfuerzo de modernización. Es posible que haya funciones específicas en uso que no están disponibles en otros sistemas de bases de datos. Una empresa puede tener bases de datos con procesos de administración complejos y bien establecidos, lo que hace que cambiarse a un sistema diferente sea poco práctico o poco rentable. O bien, una empresa puede optar por modernizar una aplicación en la primera fase y modernizar la base de datos en la segunda fase.

Cuando una empresa usa un sistema de base de datos existente, el diseñador de la aplicación de múltiples nubes debe decidir si será la única base de datos usada o si se debe agregar un sistema de base de datos diferente para las diferentes ubicaciones de implementación. Por ejemplo, si se usa una base de datos de forma local y la aplicación también debe ejecutarse en Google Cloud, se debe considerar si los servicios de la aplicación implementados en Google Cloud acceden a la base de datos local. O, de forma alternativa, si se debe implementar una segunda base de datos tanto en Google Cloud como en los servicios de la aplicación que se ejecutan de manera local.

Si se implementa una segunda base de datos en Google Cloud, el caso de uso puede ser el mismo que los que se analizan en Aumentos de actividad en la nube o Servicios distribuidos. En cualquier caso, se aplica el mismo análisis de base de datos que en estas secciones. Sin embargo, se limita a la funcionalidad entre ubicaciones que la base de datos local existente puede admitir, por ejemplo, la sincronización y la replicación.

Patrones de implementación

Los casos de uso que se analizan en este documento plantean una pregunta común desde una perspectiva de base de datos: si las bases de datos están en más de una ubicación de implementación, ¿cuál es su relación?

Los principales tipos de relaciones (patrones de implementación), que se analizan en la siguiente sección, son los siguientes:

  • Particionado sin dependencia entre bases de datos
  • Replicación unidireccional asíncrona
  • Replicación bidireccional con resolución de conflictos
  • Sistema activo-activo distribuido y completamente sincronizado

Es posible asignar cada caso de uso de este documento a uno o más de los cuatro patrones de implementación.

En la siguiente discusión, se asume que los clientes acceden a los servicios de aplicaciones directamente. Según el caso de uso, es posible que se necesite un balanceador de cargas para dirigir de forma dinámica el acceso del cliente a las aplicaciones, como se muestra en el siguiente diagrama.

Acceso del cliente a través del balanceo de cargas.

En el diagrama anterior, un balanceador de cargas en la nube dirige las llamadas del cliente a una de las ubicaciones disponibles. El balanceador de cargas garantiza que se apliquen las políticas de balanceo de cargas y que los clientes se dirijan a la ubicación correcta de la aplicación y su base de datos.

Particionado sin dependencia entre bases de datos

Este patrón de implementación es el más simple de todos los que se analizan en este documento: cada ubicación o nube tiene una base de datos y las bases de datos contienen conjuntos de datos particionados que no dependen uno del otro. Un elemento de datos se almacena en una sola base de datos. Cada partición de datos se encuentra en su propia base de datos. Un ejemplo de este patrón es una aplicación multiusuario en la que un conjunto de datos está en una base de datos o en la otra. En el diagrama siguiente, se muestran dos aplicaciones completamente particionadas.

Implementación de base de datos completamente particionada

Como se muestra en el diagrama anterior, una aplicación se implementa en dos ubicaciones, cada una responsable de una partición de todo el conjunto de datos. Cada elemento de datos reside en solo una de las ubicaciones, lo que garantiza un conjunto de datos particionado sin ninguna replicación entre las dos.

Un patrón de implementación alternativo para bases de datos particionadas ocurre cuando el conjunto de datos está particionado por completo, pero aún se almacena dentro de la misma base de datos. Solo hay una base de datos que contiene todos los conjuntos de datos. Aunque los conjuntos de datos se almacenan en la misma base de datos, los conjuntos están separados por completo (particionados), y realizar un cambio en uno no genera cambios en otro. En el siguiente diagrama, se muestran dos aplicaciones que comparten una sola base de datos.

Instancia de base de datos única que admite varias ubicaciones.

En el diagrama anterior, se muestra lo siguiente:

  • Dos implementaciones de aplicaciones que comparten una base de datos común que se encuentra en la primera ubicación.
  • Cada aplicación puede acceder a todos los datos de la implementación porque el conjunto de datos no está particionado.

Replicación unidireccional asíncrona

Este patrón de implementación tiene una base de datos principal que se replica en una o más bases de datos secundarias. La base de datos secundaria se puede usar para el acceso de lectura. Un ejemplo de este patrón ocurre cuando la mejor base de datos para un caso de uso en particular se usa como la base de datos principal y la base de datos secundaria se utiliza para estadísticas. En el siguiente diagrama, se muestran dos aplicaciones que acceden a bases de datos replicadas de forma unidireccional.

Replicación unidireccional asíncrona.

Como se muestra en el diagrama anterior, una de las dos bases de datos es una réplica de la otra. La flecha en el diagrama indica la dirección de replicación: los datos del sistema de base de datos en la ubicación 1 se replican en el sistema de base de datos en la ubicación 2.

Replicación bidireccional con resolución de conflictos

Con este patrón de implementación, hay dos bases de datos principales que se replican de forma asíncrona entre sí. Si los mismos datos se escriben al mismo tiempo en cada base de datos (por ejemplo, la misma clave primaria), se puede causar un conflicto de escritura. Debido a este riesgo, debe existir una resolución de conflicto para determinar cuál es el estado más reciente durante la replicación. Este patrón se puede usar en situaciones en las que las probabilidades de que haya un conflicto de escritura sean bajas. En el siguiente diagrama, se muestran dos aplicaciones que acceden a bases de datos replicadas de forma bidireccional.

Replicación bidireccional con resolución de conflictos.

Como se muestra en el diagrama anterior, cada base de datos se replica en la otra base de datos. Las dos replicaciones son independientes entre sí, como se indica en el diagrama mediante dos flechas azules distintas. Debido a que las dos replicaciones son independientes, puede surgir un conflicto si, por casualidad, cada aplicación cambia el mismo elemento de datos y este se replica de forma simultánea. En este caso, se debe aplicar la resolución de conflictos.

Sistema activo-activo distribuido y completamente sincronizado

Este patrón de implementación tiene una sola base de datos que tiene una configuración activa-activa (también conocida como principal-principal y primaria-primaria). En una configuración activa-activa, una actualización de datos en cualquier base de datos principal es transaccionalmente coherente y replicada de forma síncrona. Un caso de uso de ejemplo para este patrón es el procesamiento distribuido. En el siguiente diagrama, se muestran dos aplicaciones que acceden a una base de datos principal-principal completamente sincronizada.

Base de datos principal-principal distribuida y completamente sincronizada

Como se muestra en el diagrama anterior, esta disposición garantiza que cada aplicación siempre acceda al último estado coherente, sin una demora o riesgo de conflicto. Un cambio en una base de datos está disponible de inmediato en la otra base de datos. Cualquier cambio se refleja en ambas bases de datos cuando se produce un cambio de confirmación de transacción.

Categorización de los sistemas de bases de datos

No todos los sistemas de administración de bases de datos se pueden usar de la misma manera para los patrones de implementación que se analizan en este documento. Según el caso de uso, puede que solo sea posible implementar un patrón de implementación o una combinación de patrones de implementación con solo un subconjunto de sistemas de bases de datos.

En la siguiente sección, los diferentes sistemas de bases de datos se categorizan y asignan a los cuatro patrones de implementación.

Es posible categorizar las bases de datos según diferentes dimensiones, como el modelo de datos, la arquitectura interna, el modelo de implementación y los tipos de transacción. En la siguiente sección, para la administración de bases de datos en múltiples nubes, se usan dos dimensiones:

  • Arquitectura de implementación. La arquitectura de cómo se implementa un sistema de administración de bases de datos en recursos de nubes (por ejemplo, instancias de Compute Engine o administradas en la nube).
  • Modelo de distribución. El modelo de distribución que un sistema de base de datos admite (por ejemplo, de instancia única o completamente distribuida).

Estas dos dimensiones son las más relevantes en el contexto de casos de uso de múltiples nubes y pueden admitir los cuatro patrones de implementación derivados de los casos de uso de bases de datos de múltiples nubes. Una categorización popular se basa en los modelos de datos que admite un sistema de administración de bases de datos. Algunos sistemas solo admiten un modelo (por ejemplo, un modelo en grafo). Otros sistemas admiten varios modelos de datos al mismo tiempo (por ejemplo, modelos relacionales y de documentos). Sin embargo, en el contexto de la administración de bases de datos en múltiples nubes, esta categorización no es relevante porque las aplicaciones de múltiples nubes pueden usar cualquier modelo de datos para su implementación de múltiples nubes.

Sistema de base de datos por arquitectura de implementación

La administración de bases de datos en múltiples nubes incluye las siguientes cuatro clases principales de arquitectura de implementación para sistemas de administración de bases de datos:

  • Bases de datos integradas en la nube. Las bases de datos integradas en la nube están diseñadas, compiladas y optimizadas para funcionar con la tecnología de nube. Por ejemplo, algunos sistemas de bases de datos usan Kubernetes como su plataforma de implementación y utilizan la funcionalidad de Kubernetes. CockroachDB y YugaByte son ejemplos de este tipo de base de datos. Pueden implementarse en cualquier nube compatible con Kubernetes.
  • Bases de datos administradas por el proveedor de servicios en la nube. Las bases de datos administradas por el proveedor de servicios en la nube se compilan con tecnología específica del proveedor de servicios en la nube y son un servicio de base de datos que administra un proveedor de servicios en la nube específico. Spanner y Bigtable son ejemplos de este tipo de base de datos. Las bases de datos administradas por el proveedor de servicios en la nube solo están disponibles en la nube del proveedor y no se pueden instalar ni ejecutar en otro lugar.
  • Bases de datos anteriores a la nube. Las bases de datos anteriores a la nube existían antes del desarrollo de la tecnología de nube (a veces durante mucho tiempo) y, por lo general, se ejecutan en hardware físico y máquinas virtuales (VM). PostgreSQL y MySQL son ejemplos de este tipo de base de datos. Estos sistemas pueden ejecutarse en cualquier nube que admita las máquinas virtuales o el hardware físico necesarios.
  • Bases de datos administradas por socios en la nube. Algunas nubes públicas tienen socios de bases de datos que instalan y administran las bases de datos de clientes en la nube pública. Por este motivo, los clientes no tienen que administrar estas bases de datos por su cuenta. MongoDB Atlas y MariaDB son ejemplos de este tipo de base de datos.

Hay algunas variantes de estas categorías principales. Por ejemplo, un proveedor de bases de datos que implementa una base de datos compilada para la nube también puede proporcionar una instalación en tecnología diseñada para la nube y una oferta administrada a los clientes en la nube que proporciona el proveedor. Este enfoque es equivalente a que el proveedor proporcione una nube pública que admite solo su base de datos como servicio único.

Las bases de datos anteriores a la nube también pueden alojarse en contenedores y se pueden implementar en un clúster de Kubernetes. Sin embargo, estas bases de datos no usan funciones específicas de Kubernetes, como escalamiento, varios servicios o implementación de varios pods.

Los proveedores de bases de datos pueden asociarse con más de un proveedor de servicios en la nube pública al mismo tiempo, y ofrecer su base de datos como una base de datos administrada por socios en la nube en más de una nube pública.

Sistema de base de datos por modelo de distribución

Los diferentes sistemas de administración de bases de datos se implementan según los modelos de distribución en la arquitectura de una base de datos. Los modelos para las bases de datos son los siguientes:

  • Instancia única Una instancia de base de datos única se ejecuta en una VM o un contenedor y actúa como un sistema centralizado. Este sistema administra todo el acceso a la base de datos. Debido a que la instancia única no se puede conectar a ninguna otra instancia, el sistema de base de datos no admite la replicación.
  • Varias instancias activas-pasivas. En esta arquitectura común, varias instancias de bases de datos están vinculadas. La vinculación más común es una relación activa-pasiva en la que una instancia es la instancia de base de datos activa que admite las instancias y operaciones de lectura y escritura. Uno o más sistemas pasivos son de solo lectura y reciben todos los cambios en bases de datos de la principal de forma síncrona o asíncrona. Los sistemas pasivos pueden proporcionar acceso de lectura. El modelo activo-pasivo también se conoce como primario-secundario o principal-secundario.
  • Varias instancias activas-activas. En esta arquitectura poco común, cada instancia es una instancia activa. En este caso, cada instancia puede ejecutar transacciones de lectura y escritura, y proporcionar coherencia de datos. Por esta razón, para evitar incoherencias de datos, todas las instancias siempre están sincronizadas.
  • Varias instancias activas-activas con resolución de conflictos. Este también es un sistema relativamente poco común. Cada instancia está disponible para acceso de escritura y lectura; sin embargo, las bases de datos se sincronizan de forma asíncrona. Se permiten actualizaciones simultáneas del mismo elemento de datos, lo que genera un estado incoherente. Una política de resolución de conflictos debe decidir cuál de los estados es el último estado coherente.
  • Fragmentación de varias instancias. La fragmentación se basa en la administración de particiones (desconectadas) de datos. Una instancia de base de datos separada administra cada partición. Esta distribución es escalable, ya que se pueden agregar más fragmentos de forma dinámica a lo largo del tiempo. Sin embargo, es posible que las consultas de fragmentos cruzados no puedan realizarse porque esta funcionalidad no es compatible con todos los sistemas.

Todos los modelos de distribución que se analizan en esta sección pueden admitir la fragmentación y pueden ser un sistema fragmentado. Sin embargo, no todos los sistemas están diseñados para proporcionar una opción de fragmentación. La fragmentación es un concepto de escalabilidad y, por lo general, no es relevante para la selección de bases de datos de arquitectura en entornos de múltiples nubes.

Los modelos de distribución son diferentes para las bases de datos administradas en la nube y por socios. Debido a que estas bases de datos están vinculadas a la arquitectura de un proveedor de servicios en la nube, estos sistemas implementan arquitecturas en función de las siguientes ubicaciones de implementación:

  • Sistema zonal. Un sistema de base de datos administrado por zonas está vinculado a una zona. Cuando la zona está disponible, el sistema de la base de datos también está disponible. Sin embargo, si la zona deja de estar disponible, no se puede acceder a la base de datos.
  • Sistema regional. Una base de datos administrada por regiones está vinculada a una región y se puede acceder a ella cuando es posible acceder al menos a una zona. Cualquier combinación de zonas puede volverse inaccesible.
  • Sistema interregional. Un sistema interregional está vinculado a dos o más regiones y funciona de manera correcta cuando al menos una está disponible.

Un sistema interregional también puede ser compatible con un sistema entre nubes si la base de datos se puede instalar en todas las nubes que una empresa quiera usar.

Hay otras alternativas posibles a las arquitecturas de bases de datos administradas que se analizan en esta sección. Un sistema regional puede compartir un disco entre dos zonas. Si alguna de las dos zonas se vuelve inaccesible, el sistema de base de datos puede continuar en la zona restante. Sin embargo, si una interrupción afecta a ambas zonas, el sistema de base de datos no estará disponible, aunque otras zonas estén completamente en línea.

Mapea sistemas de bases de datos a patrones de implementación

En la siguiente tabla, se describe cómo se relacionan los patrones de implementación y las arquitecturas de implementación que se analizan en este documento. Los campos indicann las condiciones que se necesitan para que una combinación sea posible, según el patrón y la arquitectura de implementación.

Arquitectura de implementación Patrón de implementación
Particionado sin dependencia entre bases de datos Replicación unidireccional asíncrona Replicación bidireccional con resolución de conflictos Sistema activo-activo distribuido y completamente sincronizado
Bases de datos integradas en la nube Es posible para todas las nubes que proporcionen tecnología de nube integrada que usen los sistemas de bases de datos.

Si la misma base de datos no está disponible, se pueden usar diferentes sistemas de bases de datos.		 Base de datos en la nube que proporciona replicación. Base de datos en la nube que proporciona replicación bidireccional. Base de datos en la nube que proporciona sincronización principal-principal.
Bases de datos administradas por el proveedor de servicios en la nube Los sistemas de bases de datos pueden ser diferentes en nubes diferentes. La réplica no tiene que ser la base de datos administrada por el proveedor de servicios en la nube (consulta La función de la tecnología de migración de bases de datos en los patrones de implementación). Solo dentro de una nube, no entre nubes, si la base de datos proporciona replicación bidireccional. Solo dentro de una nube, no entre nubes, si la base de datos proporciona sincronización principal-principal.
Bases de datos anteriores a la nube Los sistemas de bases de datos pueden ser los mismos o diferentes en diferentes nubes. La replicación es posible entre varias nubes. El sistema de base de datos proporciona replicación bidireccional y resolución de conflictos. El sistema de base de datos proporciona sincronización principal-principal.
Bases de datos administradas por socios en la nube Los sistemas de bases de datos pueden ser diferentes en nubes diferentes.

Si el socio proporciona un sistema de base de datos administrado en todas las nubes requeridas, se puede usar la misma base de datos.		 La réplica no tiene que ser la base de datos administrada por el proveedor de servicios en la nube.

Si el socio proporciona un sistema de base de datos administrado en todas las nubes requeridas, se puede usar la misma base de datos. 		El sistema de base de datos proporciona replicación bidireccional y resolución de conflictos. El sistema de base de datos proporciona sincronización principal-principal.

Si un sistema de base de datos no proporciona replicación integrada, podría ser posible usar la tecnología de replicación de la base de datos. Para obtener más información, consulta La función de la tecnología de migración de bases de datos en los patrones de implementación.

En la siguiente tabla, se relacionan los patrones de implementación con los modelos de distribución. Los campos indican las condiciones con las que es posible realizar la combinación, según un patrón de implementación y un modelo de distribución.

Modelo de distribución Patrón de implementación
Particionado sin dependencia entre bases de datos Replicación unidireccional asíncrona Replicación bidireccional con resolución de conflictos Sistema activo-activo distribuido y completamente sincronizado
Instancia única Es posible con el mismo sistema de base de datos o uno diferente en las nubes involucradas. No aplicable No aplicable No aplicable


Varias instancias activas-pasivas		 Es posible con el mismo sistema de base de datos o uno diferente en las nubes involucradas. La replicación es posible entre nubes. La replicación es posible entre nubes. No aplicable


Varias instancias activas-activas		 Es posible con el mismo sistema de base de datos o uno diferente en las nubes involucradas. No aplicable No aplicable La sincronización es posible entre nubes.


Varias instancias activas-activas con resolución de conflictos		 Es posible con el mismo sistema de base de datos o uno diferente en las nubes involucradas. No aplicable No aplicable Aplicable si la replicación bidireccional es posible entre nubes.

Algunas implementaciones de modelos de distribución que agregan abstracción adicional basada en la tecnología de base de datos subyacente no incluyen un modelo de distribución integrado, como Postgres-BDR, un sistema activo-activo. Esos sistemas se incluyen en la tabla anterior, en la categoría correspondiente. Desde una perspectiva de múltiples nubes, es irrelevante la forma en que se implementa un modelo de distribución.

Migración y replicación de bases de datos

Según el caso de uso, es posible que una empresa necesite migrar una base de datos de una ubicación de implementación a otra. Como alternativa, para el procesamiento posterior, es posible que se deban replicar los datos para una base de datos en otra ubicación. En la siguiente sección, se analiza con más detalle la migración y la replicación de base de datos.

Migración de bases de datos

La migración de la base de datos se usa cuando se traslada una base de datos de una ubicación de implementación a otra. Por ejemplo, una base de datos que se ejecuta en un centro de datos local se migra para ejecutarse en la nube. Una vez que se completa la migración, la base de datos se cierra en el centro de datos local.

Los enfoques principales para la migración de bases de datos son los siguientes:

  • Lift-and-shift. La VM y los discos que ejecutan las instancias de base de datos se copian en el entorno de destino como están. Después de copiarlos, se inician y la migración se completa.
  • Importación y exportación, y copia de seguridad y restablecimiento. Ambos enfoques usan la funcionalidad del sistema de base de datos para externalizar una base de datos y volver a crearla en la ubicación de destino. Por lo general, la importación y exportación se basa en un formato ASCII, mientras que la copia de seguridad y restablecimiento se basa en un formato binario.
  • Migración con tiempo de inactividad cero En este enfoque, la base de datos se migra mientras los sistemas de la aplicación acceden al sistema de origen. Después de una carga inicial, los cambios se transmiten de la base de datos de origen a la de destino mediante tecnologías de captura de datos modificados (CDC). La aplicación genera tiempo de inactividad desde que se detiene en el sistema de la base de datos de origen hasta que se reinicia en el sistema de la base de datos de destino después de que se completa la migración.

La migración de bases de datos se vuelve relevante en los casos de uso de múltiples nubes cuando una base de datos se traslada de una nube a otra o de un tipo de motor de base de datos a otro.

La migración de bases de datos es un proceso multifacético. Para obtener más información, consulta Migración de bases de datos: Conceptos y principios (parte 1) y Migración de bases de datos: Conceptos y principios (parte 2).

Las tecnologías de bases de datos integradas se pueden usar para realizar migraciones de bases de datos, por ejemplo, operaciones de importación y exportación, operaciones de copias de seguridad y restablecimiento, o protocolos de replicación integrados. Cuando el sistema de origen y el de destino son diferentes sistemas de bases de datos, las tecnologías de migración son la mejor opción para la migración de bases de datos. Striim y Debezium son ejemplos de tecnologías de migración de bases de datos.

Replicación de bases de datos

La replicación de bases de datos es similar a la migración de bases de datos. Sin embargo, durante la replicación de la base de datos, el sistema de base de datos de origen permanece en su lugar mientras cada cambio se transmite a la base de datos de destino.

La replicación de la base de datos es un proceso continuo que envía cambios de la base de datos de origen a la de destino. Cuando este proceso es asíncrono, los cambios llegan a la base de datos de destino después de un retraso breve. Si el proceso es síncrono, los cambios en el sistema de origen se realizan en el sistema de destino al mismo tiempo y en las mismas transacciones.

Además de replicar una base de datos de origen en una de destino, una práctica común es replicar datos de una base de datos de origen en un sistema de estadísticas de destino.

Al igual que con la migración de bases de datos, si los protocolos de replicación están integrados, se puede usar la tecnología de base de datos integrada para replicar bases de datos. Si no hay protocolos de replicación integrados, es posible usar tecnologías de replicación como Striim o Debezium.

La función de la tecnología de migración de bases de datos en los patrones de implementación

La tecnología de base de datos integrada para habilitar la replicación no suele estar disponible cuando se usan diferentes sistemas de bases de datos en los patrones de implementación, por ejemplo, la replicación asíncrona (heterogénea). En su lugar, la tecnología de migración de bases de datos se puede implementar para habilitar este tipo de replicación. Algunos de estos sistemas de migración también implementan la replicación bidireccional.

Si la tecnología de migración o replicación de bases de datos está disponible para los sistemas de bases de datos usados en combinaciones marcadas como “No aplicable” en la Tabla 1 o en la Tabla 2 de Mapea sistemas de bases de datos a patrones de implementación, podría ser posible usarla para la replicación de bases de datos. En el siguiente diagrama, se muestra un enfoque para la replicación de bases de datos mediante una tecnología de migración.

Replicación mediante tecnología de replicación y de migración de bases de datos

En el diagrama anterior, la base de datos en la ubicación 1 se replica en la base de datos de la ubicación 2. En lugar de una replicación directa del sistema de base de datos, se implementa un servidor de migración para implementar la replicación. Este enfoque se usa para los sistemas de bases de datos que no tienen incorporada la función de replicación de la base de datos en su implementación y que deben depender de un sistema independiente del sistema de base de datos para implementar la replicación.

Selección de bases de datos de múltiples nubes

Los casos de uso de bases de datos de múltiples nubes en combinación con la categorización del sistema de base de datos te ayudan a decidir qué bases de datos son mejores para un caso de uso determinado. Por ejemplo, para implementar el caso de uso de Portabilidad de aplicaciones, hay dos opciones. La primera opción es asegurarse de que el mismo motor de base de datos esté disponible en todas las nubes. Este enfoque garantiza la portabilidad del sistema. La segunda opción es garantizar que el mismo modelo de datos y la misma interfaz de consulta estén disponibles para todas las nubes. Aunque los sistemas de bases de datos pueden ser diferentes, la portabilidad se proporciona en una interfaz funcional.

En los árboles de decisión de las siguientes secciones, se muestran los criterios de toma de decisiones para los casos de uso de bases de datos de múltiples nubes en este documento. Los árboles de decisión sugieren la mejor base de datos para cada caso de uso.

Prácticas recomendadas para un sistema de base de datos existente

Si un sistema de base de datos está en producción, se debe decidir si conservarlo o reemplazarlo. En el siguiente diagrama, se muestran las preguntas que debes hacer en el proceso de decisión:

Árbol de decisión para un sistema de base de datos existente.

Las preguntas y respuestas del árbol de decisión son las siguientes:

Decisión sobre la administración de bases de datos de múltiples nubes

El siguiente árbol de decisión es para un caso de uso con un requisito de base de datos de varias ubicaciones (incluida una implementación de base de datos en múltiples nubes). Usa el patrón de implementación como base para los criterios de toma de decisiones.

Árbol de decisión para la administración de bases de datos de múltiples nubes.

Las preguntas y respuestas del árbol de decisión son las siguientes:

  • ¿Los datos se particionan en bases de datos diferentes sin ninguna dependencia entre bases de datos?
    • Si es así, se pueden seleccionar los mismos sistemas de bases de datos o unos diferentes para cada ubicación.
    • De lo contrario, continúa con la siguiente pregunta.
  • ¿Se requiere la replicación unidireccional asíncrona?
    • Si es así, evalúa si un sistema de replicación de bases de datos es aceptable.
      • Si es así, selecciona los mismos sistemas de bases de datos o diferentes que sean compatibles con el sistema de replicación.
      • Si no es así, selecciona un sistema de base de datos que pueda implementar un modelo de distribución activo-pasivo.
      • De lo contrario, continúa con la siguiente pregunta.
  • Selecciona un sistema de base de datos con instancias sincronizadas.
    • ¿Es aceptable la resolución de conflictos?
      • Si es así, selecciona un sistema de base de datos de replicación bidireccional o un sistema de base de datos activo.
      • Si no es así, selecciona un sistema activo.

Si se implementa más de un caso de uso de múltiples nubes, una empresa debe decidir si desea usar un sistema de base de datos que admita todos los casos de uso o varios sistemas de bases de datos.

Si una empresa quiere usar un sistema de base de datos para admitir todos los casos de uso, el sistema con la mejor sincronización es la mejor opción. Por ejemplo, si se requiere replicación unidireccional, además de las instancias sincronizadas, la mejor opción son las instancias sincronizadas.

La jerarquía de calidad de la sincronización es (de ninguna a la mejor): particionada, replicación unidireccional, replicación bidireccional y replicación completamente sincronizada.

Prácticas recomendadas de implementación

En esta sección, se destacan las prácticas recomendadas que debes seguir cuando elijas una base de datos para la migración o el desarrollo de aplicaciones en múltiples nubes.

Sistema de administración de bases de datos existente

Se recomienda conservar una base de datos y no realizar cambios en el sistema de base de datos, a menos que sea necesario en un caso de uso específico. Para una empresa con un sistema de administración de bases de datos establecido y que tiene procesos de desarrollo, de mantenimiento y operativos eficaces, es mejor evitar realizar cambios.

Es posible que un caso de uso de aumentos de actividad en la nube que no requiera un sistema de base de datos en la nube no necesite un cambio de base de datos. Otro caso de uso es la replicación asíncrona en una ubicación de implementación diferente dentro de la misma nube o en otra nube. Para estos casos de uso, un buen enfoque es implementar una comparativa y verificar que la comunicación entre ubicaciones y que la comunicación y latencia entre ubicaciones cumplan con los requisitos de la aplicación cuando se accede a la base de datos.

Sistema de base de datos como servicio de Kubernetes

Si una empresa piensa en ejecutar un sistema de base de datos en Kubernetes como un servicio basado en StatefulSets, se deben tener en cuenta los siguientes factores:

  • Si la base de datos proporciona el modelo de base de datos que requiere la aplicación.
  • Factores no funcionales que determinan cómo se implementa el funcionamiento en un sistema de base de datos como un servicio de Kubernetes; por ejemplo, cómo se realiza el escalamiento (escalamiento vertical), cómo se administran las copias de seguridad y los restablecimientos, y cómo el sistema pone la supervisión a disposición de los usuarios. Para ayudarlas a comprender los requisitos de un sistema de base de datos basado en Kubernetes, las empresas deben usar sus experiencias con bases de datos como punto de comparación.
  • Alta disponibilidad y recuperación ante desastres. Para proporcionar alta disponibilidad, el sistema debe seguir funcionando cuando falla una zona dentro de una región. La base de datos debe poder conmutar por error de forma rápida de una zona a otra. En el mejor de los casos, la base de datos tiene una instancia que se ejecuta en cada zona y que está sincronizada por completo para tener un RTO y un RPO de cero.
  • Recuperación ante desastres para abordar la falla de una región (o nube). En una situación ideal, la base de datos continúa funcionando en una segunda región con un RPO y un RTO de cero. En una situación menos ideal, es posible que la base de datos en la región secundaria no se actualice por completo con todas las transacciones de la base de datos principal.

Para determinar cómo ejecutar una base de datos dentro de Kubernetes, se recomienda realizar una evaluación completa de la base de datos, en especial cuando el sistema necesita ser comparable con un sistema en producción fuera de Kubernetes.

Sistema de base de datos independiente de Kubernetes

No siempre es necesario que una aplicación que se implementa como servicios en Kubernetes tenga la base de datos en ejecución en Kubernetes al mismo tiempo. Hay muchas razones por las que un sistema de base de datos debe ejecutarse fuera de Kubernetes; por ejemplo, procesos establecidos, conocimiento del producto dentro de una empresa o falta de disponibilidad. Tanto los proveedores de servicios en la nube como las bases de datos administradas por socios en la nube se ajustan a esta categoría.

Es posible y factible ejecutar una base de datos en una instancia de Compute Engine. Cuando seleccionas un sistema de base de datos, se recomienda realizar una evaluación completa de la base de datos a fin de asegurarte de que se cumplan todos los requisitos para una aplicación.

Desde la perspectiva del diseño de la aplicación, la agrupación de conexiones es una consideración de diseño importante. Un servicio de aplicación que accede a una base de datos puede usar un grupo de conexiones de manera interna. El uso de un grupo de conexiones es bueno para la latencia reducida y la eficiencia. Las solicitudes se toman del grupo sin necesidad de que se inicien y no hay que esperar a que se creen conexiones. Si la aplicación se escala verticalmente mediante la adición de instancias de servicios de aplicaciones, cada instancia crea un grupo de conexiones. Si se siguen las prácticas recomendadas, cada grupo crea por adelantado un conjunto mínimo de conexiones. Cada vez que se crea otra instancia de servicios de aplicaciones para escalar la aplicación, se agregan conexiones a la base de datos. Desde la perspectiva del diseño, debido a que las bases de datos no pueden admitir conexiones ilimitadas, la adición de conexiones debe administrarse para evitar la sobrecarga.

Comparación entre el mejor sistema de base de datos y la portabilidad del sistema de base de datos

Cuando se seleccionan sistemas de bases de datos, es común que las empresas seleccionen el mejor sistema de bases de datos para abordar los requisitos de una aplicación. En un entorno de múltiples nubes, se puede seleccionar la mejor base de datos de cada nube y se pueden conectar entre sí según el caso de uso. Si estos sistemas son diferentes, cualquier replicación (unidireccional o bidireccional) requiere un esfuerzo significativo. Este enfoque puede justificarse si el beneficio de usar el mejor sistema supera el esfuerzo necesario para implementarlo.

Sin embargo, se recomienda considerar y evaluar de forma simultánea un enfoque para un sistema de base de datos que esté disponible en todas las nubes requeridas. Si bien esta base de datos podría no ser la mejor opción, puede ser mucho más fácil implementar, operar y mantener ese sistema.

Una evaluación simultánea del sistema de base de datos demuestra las ventajas y desventajas de ambos sistemas de bases de datos, lo que proporciona una base sólida para la selección.

Comparación entre una replicación de sistema de base de datos integrada y una externa

Para los casos de uso que requieren un sistema de base de datos en todas las ubicaciones de implementación (zonas, regiones o nubes), la replicación es una función importante. La replicación puede ser replicación asíncrona, bidireccional o activa-activa completamente sincronizada. Los sistemas de bases de datos no admiten todas estas formas de replicación.

En los sistemas que no admiten la replicación como parte de la replicación de la implementación del sistema, los sistemas como Striim se pueden usar para complementar la arquitectura (como se explica en Migración de bases de datos).

Una práctica recomendada es evaluar los sistemas alternativos de administración de bases de datos para determinar las ventajas y desventajas de un sistema que tenga replicación integrada o un sistema que requiera tecnología de replicación.

En este caso, también hay una tercera clase de tecnología que cumple una función. Esta clase proporciona complementos a los sistemas de bases de datos existentes para proporcionar replicación. Un ejemplo es el clúster de MariaDB Galera. Se recomienda evaluar estos sistemas si el proceso de evaluación lo permite.

¿Qué sigue?