Ejemplos de configuración para la replicación

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

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 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.

Sin importar el caso de uso, siempre aprovisiona suficientes nodos en todos los clústeres de una instancia para asegurarte de que cada clúster pueda manejar la replicación, además de la carga que recibe de las aplicaciones. Si un clúster no tiene suficientes nodos, el retraso 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 se podrían rechazar.

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 la app, uno de nombre live-traffic y otro de nombre 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.

  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.

    Con 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 cantidad mayor de nodos en cluster-c para asistir la carga de trabajo más grande.

  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.

  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.

Crea una alta disponibilidad (HA)

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 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.

Para obtener más información sobre cómo Bigtable ayuda a lograr una alta disponibilidad, consulta Crea una presencia de datos global con Bigtable .

Las configuraciones para mejorar la disponibilidad incluyen lo siguiente:

  • Clústeres en 3 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 de ellos en un región diferente. Por ejemplo, si la cantidad mínima de clústeres que necesitas para entregar tus datos es 2, necesitas una instancia de 4 clústeres a fin de mantener la alta disponibilidad. Esta configuración proporciona tiempo de actividad, incluso en el caso poco frecuente de que 2 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

    Para esta configuración, aprovisiona suficientes nodos a fin de mantener un objetivo de uso de CPU del 23% para una instancia de 3 clústeres y 3 regiones, y del 35% para una instancia de 4 clústeres y 4 regiones. Esto garantiza que, incluso si 2 regiones no están disponibles, el clúster o los clústeres restantes puedan entregar todo el tráfico.

  • 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

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

  • 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

    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, 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 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 app con el enrutamiento de varios clústeres para ejecutar una carga de trabajo de prueba.

  2. Usa la consola de Google Cloud para supervisar los clústeres de la instancia y confirmar que los clústeres controlen 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, 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 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 app que use el enrutamiento de un solo clúster o actualiza el perfil de 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.

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 app con el 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 1 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.

    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 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 2 clústeres en la región A, y 2 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. Crea una instancia de Bigtable con 4 clústeres: 2 en la región A y 2 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.

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.

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.

Cuando configuras inicialmente tu instancia, no excedas 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 la consola de Google Cloud para supervisar los clústeres de la instancia y confirmar que los 4 clústeres manejen 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.

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.

    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 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?