Ejemplos de la configuración de la replicación

En esta página, se describen algunos casos prácticos comunes para habilitar la replicación de Cloud Bigtable y, luego, se presenta la configuración que puedes usar con el fin de admitir estos casos.

En esta página también se explica cómo decidir qué configuración usar si tu caso práctico no aparece aquí.

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

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. Crea una instancia nueva con 2 clústeres o agrega un segundo clúster a una instancia existente.

    Sigue las recomendaciones de uso de CPU estándar para esta configuración.

  2. Crea 2 perfiles de aplicación, uno llamado live-traffic y otro llamado batch-analytics.

    Si los ID de tus clústeres son cluster-a y cluster-b, el perfil de la aplicación live-traffic debería enrutar las solicitudes a cluster-a, y el perfil de la aplicación batch-analytics debería hacerlo a cluster-b. Esta configuración proporciona coherencia en la lectura de tus escrituras para todas las aplicaciones que usan estos perfiles de aplicación.

    Puedes habilitar las transacciones de una sola fila en el perfil de la aplicación live-traffic si es necesario. No se requiere habilitar las transacciones de una sola fila en el perfil de la aplicación batch-analytics, suponiendo que este es el único que usarás para las lecturas.

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

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

  5. Supervisa el uso de CPU de los clústeres de la instancia y, si es necesario, agrégales nodos.

  6. Supervisa la latencia del lado del cliente con la herramienta que prefieras. Si usas el cliente de HBase para Java, puedes supervisar la latencia con sus métricas del lado del cliente.

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 nueva con 3 clústeres o agrega clústeres a una instancia existente hasta que tenga 3 clústeres.

    Sigue las recomendaciones de uso de CPU estándar para esta configuración.

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

    Usa la misma cantidad de nodos en cluster-a y cluster-b si muestran la misma aplicación. Usa una mayor cantidad de nodos en cluster-c para admitir la carga de trabajo más grande.

  2. Crea los siguientes perfiles de aplicaciones:

    • 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 aplicación live-traffic para ejecutar cargas de trabajo de live-traffic.

  4. Mientras se ejecutan las cargas de trabajo de live-traffic, usa el perfil de la aplicación batch-analytics para ejecutar una carga de trabajo de solo lectura por lotes.

  5. Supervisa el uso de CPU de los clústeres de la instancia y, si es necesario, agrégales nodos.

  6. Supervisa la latencia del lado del cliente con la herramienta que prefieras. Si usas el cliente de HBase para Java, puedes supervisar la latencia con sus métricas del lado del cliente.

Mejora la disponibilidad

Si una instancia tiene 1 solo clúster, la durabilidad y la disponibilidad de tus datos estará limitada según la zona en la que se encuentre 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, si es necesario, realiza la conmutación por error automáticamente entre los clústeres.

A fin de configurar tu instancia para este caso práctico, 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 una sola fila porque pueden causar conflictos de datos cuando utilizas el enrutamiento de varios clústeres.

Las configuraciones para mejorar la disponibilidad incluyen lo siguiente:

  • Dos clústeres en la misma región, pero en diferentes zonas. Esta opción proporciona una disponibilidad alta y la posibilidad de realizar una conmutación por error sin generar costos de replicación entre las regiones. Tus datos en una instancia replicada de Cloud 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

    Sigue las recomendaciones de uso de CPU estándar para esta configuración.

  • Dos clústeres en diferentes regiones. Esta configuración de varias regiones proporciona una disponibilidad alta, como la configuración de varias zonas descrita anteriormente, 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

    Sigue las recomendaciones de uso de CPU estándar para esta configuración.

  • 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. Además, 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 1 clúster en la región B. Si escribes en la región B, se te cobrará dos veces porque tienes 2 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

    Comienza con un objetivo del 35% de uso de CPU en la región con 2 clústeres y el 70% en la otra región. Supervisa los clústeres de la instancia y ajusta la cantidad de nodos según sea necesario con el fin de que cada clúster tenga recursos suficientes para manejar una conmutación por error.

Puedes simular la conmutación por error en este caso práctico para probar tu aplicación:

  1. Usa el perfil de la aplicación con el enrutamiento de varios clústeres para ejecutar una carga de trabajo de prueba.

  2. Utiliza Google Cloud Platform Console para supervisar los clústeres de la instancia y confirmar que los clústeres están manejando las solicitudes entrantes.

  3. Borra uno de los clústeres para simular una interrupción.

    Con este cambio, también se borrará la copia de tus datos que se almacena en ese clúster.

  4. Sigue supervisando la latencia y las tasas de errores. Si los clústeres restantes tienen recursos de CPU suficientes, deberían poder mantener su rendimiento con las solicitudes entrantes.

  5. Agrega un clúster a la instancia y sigue supervisándola. Los datos deberían comenzar a replicarse a este clúster nuevo.

Proporcionar 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, igual puedes usar la replicación; para ello, solo debes controlar las solicitudes con un clúster y mantener el otro como una copia de seguridad casi en tiempo real. Si este clúster deja de estar disponible, puedes reducir el tiempo de inactividad con una conmutación por error manual al clúster de respaldo.

A fin de configurar tu instancia para este caso práctico, crea un perfil de aplicación que use el enrutamiento de un solo clúster o actualiza el perfil de la aplicación predeterminado para que lo use. El clúster que especificaste en el perfil de tu aplicación controlará 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 una sola fila en el perfil de la aplicación.

Sigue las recomendaciones de uso de CPU estándar para esta configuración.

Para implementar esta configuración, sigue estos pasos:

  1. Usa el perfil de la aplicación con el enrutamiento de un solo clúster para ejecutar una carga de trabajo.

  2. Usa Google Cloud Platform Console para supervisar los clústeres de la instancia y confirmar que solo 1 clúster está manejando 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.

    Recibirás una advertencia, la cual indicará que perderás la coherencia en la lectura de tus escrituras, lo que implica que también perderás 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. Perderás los datos si envías escrituras con conflicto mientras se ejecuta 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 a cada concentración de clientes clústeres de Cloud Bigtable que estén 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, puede crear una instancia con 2 clústeres en la región A y 2 en la región B. Esta configuración proporciona una alta disponibilidad incluso si no puedes conectarte a una región de GCP. 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. Crea una instancia de Cloud Bigtable con 4 clústeres: 2 en la región A y 2 en la región B. Los clústeres en la misma región deben estar en zonas diferentes.

    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-a 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 utilizas el enrutamiento de varios clústeres, Cloud 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 varios clústeres

Si estás implementando este caso práctico y deseas que Cloud Bigtable se traslade 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.

A fin de implementar esta configuración, crea un nuevo perfil de aplicación que use enrutamiento de varios clústeres 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 Cloud Bigtable se envían automáticamente a la otra región. Cuando esto sucede, se te cobra 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.

Puedes usar solo un perfil de aplicación con enrutamiento de varios clústeres por instancia, y no puedes usar una combinación de perfiles de enrutamiento de varios clústeres y de un solo clúster. Una instancia debe usar una o la otra.

Cuando configuras inicialmente tu instancia, debes tratar de no exceder el 35% de uso de CPU para cada clúster. Este objetivo garantiza que cada clúster pueda manejar el tráfico que normalmente maneja el otro en su región si se produce una conmutación por error. Es posible que debas ajustar este objetivo según tus patrones de tráfico y uso.

Puedes simular la conmutación por error en este caso práctico para probar tu aplicación:

  1. Ejecuta una carga de trabajo de prueba.

  2. Usa GCP Console para supervisar los clústeres de la instancia y confirmar que los 4 clústeres están manejando las solicitudes entrantes.

  3. Borra uno de los clústeres en la región A para simular un problema de conexión a una zona.

    Con este cambio, también se borrará la copia de tus datos que se almacena en ese clúster.

  4. Sigue supervisando la latencia y las tasas de errores de los clústeres restantes.

    Si los clústeres tienen recursos de CPU suficientes, deberían poder mantener su rendimiento con las solicitudes entrantes.

  5. Agrega un clúster a la instancia en la región A y continúa supervisando la instancia.

    Los datos deberían comenzar a replicarse a este clúster nuevo.

  6. Borra ambos clústeres en la región A para simular un problema de conexión a una región.

    Con este cambio, se borran las copias de tus datos que estaban en esos clústeres.

  7. Sigue supervisando la latencia y las tasas de errores de los clústeres restantes.

    Si los clústeres tienen los recursos de CPU suficientes, deberían poder mantener su rendimiento con las solicitudes entrantes. Si los clústeres no tienen suficientes recursos, es posible que debas ajustar la cantidad de nodos.

Opción de enrutamiento de un solo clúster

Puedes usar el enrutamiento de un solo clúster para este caso práctico si no deseas que tu clúster de Cloud 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 Cloud Bigtable comienza a enrutar el tráfico hacia y desde una región distante, o si prefieres tomar decisiones de conmutación por error basadas en tu propio criterio o reglas empresariales.

Para implementar esta configuración, crea 4 perfiles de aplicaciones que utilicen enrutamiento de un solo clúster. Cada perfil de aplicación se enruta a un clúster diferente en la instancia de Cloud Bigtable.

Sigue las recomendaciones de uso de CPU estándar para esta configuración.

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.

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 Cloud Bigtable, puedes crear una instancia que tenga clústeres en varias regiones de GCP, y tus datos se replican automáticamente en cada región.

Para este caso práctico, usa los perfiles de aplicaciones 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.

    Sigue las recomendaciones de uso de CPU estándar para esta configuración.

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

  3. Crea perfiles de aplicaciones 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 utiliza el perfil de la aplicación 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?

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Documentación de Cloud Bigtable