Ejemplos de parámetros de configuración de replicación

En esta página, se describen algunos casos de uso comunes para la replicación de Bigtable y se presenta la configuración que puedes usar para admitir estos casos.

En esta página, también se explica cómo decidir qué configuración usar en otros casos de uso.

Antes de leer esta página, debes familiarizarte con la descripción general de la replicación de Bigtable.

Antes de agregar clústeres a una instancia, debes tener en cuenta las restricciones que se aplican cuando cambias las políticas de recolección de elementos no utilizados en tablas replicadas.

En la mayoría de los casos, habilita el ajuste de escala automático para los clústeres de tu instancia. El ajuste de escala automático permite que Bigtable agregue y quite nodos de un clúster automáticamente según la carga de trabajo.

Si eliges la asignación manual de nodos, aprovisiona suficientes nodos en cada clúster de una instancia para garantizar que cada clúster pueda controlar la replicación además de la carga que recibe de las aplicaciones. Si un clúster no tiene suficientes nodos, la demora de replicación puede aumentar, el clúster puede experimentar problemas de rendimiento debido a la acumulación de memoria y las operaciones de escritura en otros clústeres de la instancia pueden rechazarse.

Los ejemplos de este documento describen cómo crear una instancia, pero también puedes agregar clústeres a una instancia existente.

Aísla las cargas de trabajo de estadísticas por lotes de otras aplicaciones

Cuando usas un solo clúster para ejecutar un trabajo de estadísticas por lotes que realiza varias lecturas grandes, además de una aplicación que lleva a cabo una mezcla de lecturas y escrituras, ese gran trabajo por lotes puede ralentizar los procesos para los usuarios de la aplicación. Con la replicación, puedes usar los perfiles de aplicaciones con enrutamiento de un solo clúster para enrutar los trabajos de estadísticas por lotes y el tráfico de aplicaciones a diferentes clústeres, de modo que los trabajos por lotes no afecten a los usuarios de tus aplicaciones.

Para aislar dos cargas de trabajo, sigue estos pasos:

  1. Crear una instancia con dos clústeres

  2. Crea dos perfiles de app, uno llamado live-traffic y otro llamado batch-analytics.

    Si los ID de tu clúster son cluster-a y cluster-b, el perfil de aplicación live-traffic debe enrutar las solicitudes a cluster-a y el perfil de app batch-analytics debe enrutarlas a cluster-b. Esta configuración proporciona coherencia de lectura y escritura para aplicaciones que usan el mismo perfil de app, pero no para aplicaciones que usan perfiles de app diferentes.

    De ser necesario, puedes habilitar las transacciones de fila única en el perfil de app live-traffic. No es necesario habilitar las transacciones de fila única en el perfil de app batch-analytics, si solo usarás este perfil de app para las lecturas.

  3. Usa el perfil de la app live-traffic para ejecutar una carga de trabajo de tráfico en vivo.

  4. Mientras esta se encuentre en ejecución, usa el perfil de la app batch-analytics para ejecutar una carga de trabajo por lotes de solo lectura.

Para aislar dos cargas de trabajo más pequeñas de una carga de trabajo más grande, sigue estos pasos:

  1. Crea una instancia con tres clústeres.

    Con estos pasos, se supone que tus clústeres usan los ID cluster-a, cluster-b y cluster-c.

  2. Crea los siguientes perfiles de apps:

    • live-traffic-app-a: Enrutamiento de un solo clúster de tu aplicación a cluster-a
    • live-traffic-app-b: Enrutamiento de un solo clúster de tu aplicación a cluster-b
    • batch-analytics: Enrutamiento de un solo clúster del trabajo de estadísticas por lotes a cluster-c

  3. Utiliza los perfiles de la app live-traffic para ejecutar cargas de trabajo con tráfico en vivo.

  4. Mientras se ejecutan las cargas con trabajo de tráfico en vivo, usa el perfil de app batch-analytics para ejecutar una carga de trabajo por lotes de solo lectura.

Crea una alta disponibilidad (HA)

Si una instancia tiene un solo clúster, la durabilidad y disponibilidad de tus datos se limitan a la zona en la que se encuentra el clúster. La replicación puede mejorar la durabilidad y la disponibilidad, ya que almacena copias independientes de todos tus datos en varias zonas o regiones, y realiza la conmutación por error automáticamente entre los clústeres si es necesario.

A fin de configurar tu instancia para un caso de uso de alta disponibilidad (HA), crea un perfil de aplicación nuevo que use el enrutamiento de varios clústeres o actualiza el perfil de la aplicación predeterminado para que lo use. Esta configuración proporciona coherencia eventual. No podrás habilitar las transacciones de fila única porque pueden causar conflictos de datos cuando usas el enrutamiento de varios clústeres.

Las configuraciones para mejorar la disponibilidad incluyen lo siguiente:

  • Clústeres en tres o más regiones diferentes (configuración recomendada). La configuración recomendada para la alta disponibilidad es una instancia que tiene clústeres N + 2, cada uno en una región diferente. Por ejemplo, si la cantidad mínima de clústeres que necesitas para entregar tus datos es 2, entonces necesitas una instancia con cuatro clústeres para mantener la alta disponibilidad. Esta configuración proporciona tiempo de actividad incluso en el caso poco frecuente de que dos regiones no estén disponibles. Te recomendamos que distribuyas los clústeres en varios continentes.

    Configuración de ejemplo:

    • cluster-a en la zona us-central1-a en Iowa
    • cluster-b en la zona europe-west1-d en Bélgica
    • cluster-c en la zona asia-east1-b en Taiwán

  • Dos clústeres en la misma región, pero en diferentes zonas. Esta opción proporciona una alta disponibilidad dentro de la disponibilidad de la región, la posibilidad de realizar una conmutación por error sin generar costos de replicación entre regiones y sin una mayor latencia en la conmutación por error. Tus datos en una instancia replicada de Bigtable están disponibles, siempre y cuando también lo esté cualquiera de las zonas a las que se replica.

    Configuración de ejemplo:

    • cluster-a en la zona australia-southeast1-a en Sídney
    • cluster-b en la zona australia-southeast1-b en Sídney

  • Dos clústeres en diferentes regiones. Esta configuración multirregional proporciona una disponibilidad alta, como la configuración multizona anterior, pero tus datos están disponibles incluso si no puedes conectarte a una de las regiones.

    Se te cobrará por replicar escrituras entre las regiones.

    Configuración de ejemplo:

    • cluster-a en la zona asia-northeast1-c en Tokio
    • cluster-b en la zona asia-east2-b en Hong Kong

  • Dos clústeres en la región A y un tercer clúster en la región B. Esta opción hace que tus datos estén disponibles incluso si no puedes conectarte a una de las regiones y proporciona capacidad adicional en la región A.

    Se te cobrará por replicar escrituras entre las regiones. Si escribes en la región A, se te cobrará una vez porque solo tienes un clúster en la región B. Si escribes en la región B, se te cobrará dos veces porque tienes dos clústeres en la región A.

    Configuración de ejemplo:

    • cluster-a en la zona europe-west1-b en Bélgica
    • cluster-b en la zona europe-west1-d en Bélgica
    • cluster-c en la zona europe-north1-c en Finlandia

Proporciona copias de seguridad casi en tiempo real

Por ejemplo, en algunos casos, si no te puedes permitir leer datos inactivos, siempre deberás enrutar las solicitudes a un solo clúster. Sin embargo, aún puedes usar la replicación mediante el control de las solicitudes con un clúster y el uso del otro como una copia de seguridad casi en tiempo real. Si el primer clúster deja de estar disponible, puedes reducir el tiempo de inactividad con una conmutación por error manual al clúster de respaldo.

Si deseas configurar tu instancia para este caso de uso, crea un perfil de app que use el enrutamiento de un solo clúster o actualiza el perfil de la app predeterminado para que lo use. El clúster que especificaste en el perfil de tu aplicación controla las solicitudes entrantes. El otro actuará como respaldo en caso de que necesites realizar una conmutación por error. A menudo, este acuerdo se conoce como configuración activa-pasiva y proporciona coherencia sólida y coherencia en la lectura de tus escrituras. De ser necesario, puedes habilitar las transacciones de fila única en el perfil de app.

Para implementar esta configuración, sigue estos pasos:

  1. Usa un perfil de app con enrutamiento de un solo clúster para ejecutar una carga de trabajo.

  2. Usa la consola de Google Cloud para supervisar los clústeres de la instancia y confirmar que solo un clúster controle las solicitudes entrantes.

    El otro seguirá usando los recursos del CPU para ejecutar la replicación y otras tareas de mantenimiento.

  3. Actualiza el perfil de la aplicación a fin de que se oriente al segundo clúster de la instancia.

    Recibes una advertencia si pierdes la coherencia en la lectura de tus escrituras, lo que también significa que pierdes la coherencia sólida.

    Si habilitaste las transacciones de una sola fila, también recibirás una advertencia sobre la posible pérdida de datos. Pierdes datos si envías escrituras con conflicto mientras se produce la conmutación por error.

  4. Sigue supervisando tu instancia. Deberías ver que el segundo clúster está controlando las solicitudes entrantes.

Mantiene la disponibilidad alta y la resiliencia regional

Supongamos que tienes concentraciones de clientes en dos regiones distintas dentro de un continente. Deseas entregar cada concentración de clientes con clústeres de Bigtable lo más cerca posible de los clientes. Deseas que tus datos tengan alta disponibilidad dentro de cada región y es posible que desees una opción de conmutación por error si uno o más de tus clústeres no están disponibles.

Para este caso práctico, puedes crear una instancia con dos clústeres en la región A y dos clústeres en la región B. Esta configuración proporciona alta disponibilidad, incluso si no puedes conectarte a una región de Google Cloud. También proporciona resiliencia regional porque incluso si una zona deja de estar disponible, el otro clúster en la región de esa zona sigue estando disponible.

Puedes decidir utilizar el enrutamiento de varios clústeres o el enrutamiento de un solo clúster para este caso práctico, según tus necesidades empresariales.

Con el fin de configurar tu instancia para este caso práctico, sigue estos pasos:

  1. Crear una instancia de Bigtable con cuatro clústeres: dos en la región A y dos en la región B. Los clústeres de la misma región deben estar en diferentes zonas.

    Configuración de ejemplo:

    • cluster-a en la zona asia-south1-a en Bombay
    • cluster-b en la zona asia-south1-c en Bombay
    • cluster-c en la zona asia-northeast1-a en Tokio
    • cluster-d en la zona asia-northeast1-b en Tokio

  2. Coloca un servidor de aplicaciones cerca de cada región.

Puedes decidir utilizar el enrutamiento de varios clústeres o el enrutamiento de un solo clúster para este caso práctico, según tus necesidades empresariales. Si usas el enrutamiento de varios clústeres, Bigtable maneja las conmutaciones por error automáticamente. Si usas el enrutamiento de un solo clúster, utiliza tu propio criterio para decidir cuándo conmutar por error a un clúster diferente.

Opción de enrutamiento de un solo clúster

Puedes usar el enrutamiento de un solo clúster para este caso de uso si no deseas que tu clúster de Bigtable realice una conmutación por error automáticamente si una zona o región deja de estar disponible. Esta es una buena opción si deseas administrar los costos y la latencia que pueden ocurrir si Bigtable comienza a enrutar el tráfico desde y hacia una región distante, o si prefieres tomar decisiones de conmutación por error basadas en tu propio criterio o tus reglas empresariales.

Para implementar esta configuración, crea al menos un perfil de aplicación que use el enrutamiento de un solo clúster para cada aplicación que envíe solicitudes a la instancia. Puedes enrutar los perfiles de la aplicación a cualquier clúster en la instancia de Bigtable. Por ejemplo, si tienes tres aplicaciones que se ejecutan en Bombay y seis en Tokio, puedes configurar un perfil de app para que la aplicación de Bombay se enrute a asia-south1-a y dos que se enruten a asia-south1-c. Para la aplicación de Tokio, configura tres perfiles de aplicación que se enruten a asia-northeast1-a y tres que se enruten a asia-northeast1-b.

Con esta configuración, si uno o más clústeres no están disponibles, puedes realizar una conmutación por error manual o puedes dejar que tus datos no estén disponibles temporalmente en esa zona hasta que vuelva a estar disponible.

Opción de enrutamiento de varios clústeres

Si estás implementando este caso de uso y deseas que Bigtable realice una conmutación por error automáticamente a una región si tu aplicación no puede llegar a la otra región, usa el enrutamiento de varios clústeres.

Para implementar esta configuración, crea un nuevo perfil de la aplicación que utiliza enrutamiento de varios clústeres para cada aplicación o actualiza el perfil de aplicación predeterminado para usar el enrutamiento de varios clústeres.

Esta configuración proporciona coherencia eventual. Si una región deja de estar disponible, las solicitudes de Bigtable se envían automáticamente a la otra región. Cuando esto sucede, se te cobrará por el tráfico de red a la otra región y tu aplicación puede experimentar una latencia más alta debido a la mayor distancia.

Almacena los datos cerca de tus usuarios

Si tienes usuarios en todo el mundo, puedes reducir la latencia ejecutando tu aplicación cerca de tus usuarios y colocando tus datos lo más cerca posible de tu aplicación. Con Bigtable, puedes crear una instancia que tenga clústeres en varias regiones de Google Cloud, y tus datos se replican automáticamente en cada región.

Para este caso práctico, usa los perfiles de app con enrutamiento de un solo clúster. El enrutamiento de varios clústeres no es recomendable para este caso práctico debido a la distancia entre los clústeres. Si un clúster deja de estar disponible y su perfil de aplicación de varios clústeres desvía automáticamente el tráfico a una gran distancia, tu aplicación puede experimentar una latencia inaceptable, además de incurrir en costos de red inesperados y adicionales.

Con el fin de configurar tu instancia para este caso práctico, sigue estos pasos:

  1. Crea una instancia con clústeres en tres regiones geográficas distintas, como Estados Unidos, Europa y Asia.

  2. Coloca un servidor de aplicaciones cerca de cada región.

  3. Crea perfiles de apps similares a los siguientes:

    • clickstream-us: Enrutamiento de un solo clúster al clúster en los Estados Unidos
    • clickstream-eu: Enrutamiento de un solo clúster al clúster en Europa
    • clickstream-asia: Enrutamiento de un solo clúster al clúster en Asia

En esta configuración, tu aplicación usa el perfil de la app para el clúster más cercano. Las escrituras en cualquier clúster se replican automáticamente en los otros dos clústeres.

Otros casos prácticos

Si tienes un caso práctico que no se describa en esta página, usa las siguientes preguntas que te ayudarán a decidir cómo configurar los perfiles de tu aplicación:

¿Qué sigue?