Ejemplos de configuraciones de replicación

En esta página se describen algunos casos prácticos habituales de replicación de Bigtable y se presentan los ajustes que puede usar para admitir estos casos prácticos.

En esta página también se explica cómo decidir qué ajustes usar en otros casos prácticos.

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

Antes de añadir clústeres a una instancia, debes tener en cuenta las restricciones que se aplican al cambiar las políticas de recogida de elementos no utilizados en tablas replicadas.

En la mayoría de los casos, habilita el autoescalado en los clústeres de tu instancia. El autoescalado permite a Bigtable añadir y quitar nodos automáticamente de un clúster en función de la carga de trabajo.

Si eliges la asignación manual de nodos, aprovisiona suficientes nodos en todos los clústeres de una instancia para asegurarte de que cada clúster pueda gestionar la replicación, además de la carga que recibe de las aplicaciones. Si un clúster no tiene suficientes nodos, puede aumentar la latencia de replicación, el clúster puede experimentar problemas de rendimiento debido a la acumulación de memoria y es posible que se rechacen las escrituras en otros clústeres de la instancia.

En los ejemplos de este documento se describe cómo crear una instancia, pero también puedes añadir clústeres a una instancia que ya tengas.

Aísla las cargas de trabajo de analíticas por lotes de otras aplicaciones

Si usas un solo clúster para ejecutar una tarea de analíticas por lotes que realice numerosas lecturas grandes junto con una aplicación que realice una combinación de lecturas y escrituras, la tarea por lotes grande puede ralentizar el trabajo de los usuarios de la aplicación. Con la replicación, puedes usar perfiles de aplicación con enrutamiento de un solo clúster para enrutar trabajos de analíticas por lotes y 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 con dos clústeres.

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

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

    Si es necesario, puedes habilitar las transacciones de una sola fila en el perfil de la aplicación live-traffic. No es necesario habilitar las transacciones de una sola fila en el perfil de la aplicación batch-analytics, siempre que solo uses este perfil para lecturas.

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

  4. Mientras se ejecuta la carga de trabajo de tráfico en tiempo real, usa el perfil de aplicación 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 más grande, haz lo siguiente:

  1. Crea una instancia con tres clústeres.

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

  2. Crea los siguientes perfiles de aplicación:

    • live-traffic-app-a: enrutamiento de un solo clúster desde tu aplicación a cluster-a
    • live-traffic-app-b: enrutamiento de un solo clúster desde tu aplicación a cluster-b
    • batch-analytics: enrutamiento de un solo clúster del trabajo de analíticas por lotes a cluster-c

  3. Usa los perfiles de aplicaciones de tráfico real para ejecutar cargas de trabajo de tráfico real.

  4. Mientras se ejecutan las cargas de trabajo de tráfico real, usa el perfil de aplicación batch-analytics para ejecutar una carga de trabajo por lotes de solo lectura.

Crear alta disponibilidad

Si una instancia solo tiene un clúster, la durabilidad y la disponibilidad de tus datos se limitan a la zona en la que se encuentra ese clúster. La replicación puede mejorar tanto la durabilidad como la disponibilidad almacenando copias independientes de tus datos en varias zonas o regiones y conmutando automáticamente entre clústeres si es necesario.

Para configurar tu instancia en un caso práctico de alta disponibilidad, crea un perfil de aplicación que use el enrutamiento entre clústeres o actualiza el perfil de aplicación predeterminado para que use el enrutamiento entre clústeres. Esta configuración proporciona coherencia final. No podrás habilitar las transacciones de una sola fila porque pueden provocar conflictos de datos cuando usas el enrutamiento multiclúster.

Estas son algunas configuraciones para mejorar la disponibilidad:

  • 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 N+2 clústeres, cada uno en una región diferente. Por ejemplo, si el número mínimo de clústeres que necesitas para servir tus datos es 2, necesitas una instancia con cuatro clústeres para mantener la alta disponibilidad. Esta configuración proporciona tiempo de actividad incluso en el caso poco probable de que dos regiones no estén disponibles. Te recomendamos que distribuyas los clústeres en varios continentes.

    Ejemplo de configuración:

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

  • Dos clústeres en la misma región, pero en zonas diferentes. Esta opción proporciona alta disponibilidad en la disponibilidad de la región, la capacidad de conmutar por error sin generar costes de replicación entre regiones y sin aumentar la latencia en la conmutación por error. Tus datos de una instancia de Bigtable replicada están disponibles siempre que lo esté alguna de las zonas en las que se haya replicado.

    Para obtener más información sobre las consideraciones específicas de cada región, consulta el artículo sobre geografía y regiones.

    Ejemplo de configuración:

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

  • Dos clústeres en regiones diferentes. Esta configuración multirregional ofrece alta disponibilidad, al igual que la configuración multizona anterior, pero tus datos están disponibles aunque no puedas conectarte a una de las regiones.

    Se te cobrará por replicar escrituras entre regiones.

    Ejemplo de configuración:

    • cluster-a en la zona asia-northeast1-c de Tokio
    • cluster-b en la zona asia-east2-b de 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 aunque no puedas conectarte a una de las regiones y te proporciona capacidad adicional en la región A.

    Se te cobrará por replicar escrituras entre 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.

    Ejemplo de configuración:

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

Proporcionar copias de seguridad casi en tiempo real

En algunos casos, por ejemplo, si no puedes permitirte leer datos obsoletos, siempre tendrás que enrutar las solicitudes a un solo clúster. Sin embargo, puedes seguir usando la replicación gestionando las solicitudes con un clúster y manteniendo otro clúster como copia de seguridad casi en tiempo real. Si el clúster de servicio deja de estar disponible, puedes minimizar el tiempo de inactividad haciendo un failover manual al clúster de copia de seguridad.

Para configurar tu instancia en este caso práctico, crea un perfil de aplicación que use el enrutamiento de un solo clúster o actualiza el perfil de aplicación predeterminado para que use el enrutamiento de un solo clúster. El clúster que has especificado en el perfil de tu aplicación gestiona las solicitudes entrantes. El otro clúster actúa como copia de seguridad en caso de que necesites hacer un failover. Esta configuración se conoce como configuración activa-pasiva y proporciona coherencia sólida y coherencia inmediata (read-your-writes). Si es necesario, puede habilitar las transacciones de una sola fila en el perfil de la aplicación.

Para implementar esta configuración, sigue estos pasos:

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

  2. Usa la Google Cloud consola para monitorizar los clústeres de la instancia y confirma que solo un clúster gestiona las solicitudes entrantes.

    El otro clúster seguirá usando recursos de CPU para realizar la replicación y otras tareas de mantenimiento.

  3. Actualiza el perfil de la aplicación para que apunte al segundo clúster de tu instancia.

    Recibes una advertencia sobre la pérdida de la coherencia de lectura y escritura, lo que también significa que pierdes la coherencia fuerte.

    Si has habilitado las transacciones de una sola fila, también recibirás una advertencia sobre la posible pérdida de datos. Perderá datos si envía escrituras conflictivas mientras se produce la conmutación por error.

  4. Sigue monitorizando tu instancia. Deberías ver que el segundo clúster gestiona las solicitudes entrantes.

Mantener la alta disponibilidad y la resiliencia regional

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

En este caso práctico, puede 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 Google Cloud . También ofrece resiliencia regional, ya que, aunque una zona deje de estar disponible, el otro clúster de la región de esa zona seguirá disponible.

En función de las necesidades de tu empresa, puedes usar el enrutamiento de varios clústeres o el de un solo clúster en este caso práctico.

Para configurar tu instancia en este caso práctico, haz lo siguiente:

  1. Crea 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 zonas diferentes.

    Ejemplo de configuración:

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

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

En función de las necesidades de tu empresa, puedes usar el enrutamiento de varios clústeres o el de un solo clúster en este caso práctico. Si usas el enrutamiento a varios clústeres, Bigtable gestiona las conmutaciones por error automáticamente. Si usas el enrutamiento de un solo clúster, debes decidir cuándo conmutar por error a otro clúster.

Opción de enrutamiento de un solo clúster

Puedes usar el enrutamiento de un solo clúster en este caso práctico si no quieres que tu clúster de Bigtable conmute por error automáticamente si una zona o una región no están disponibles. Esta opción es una buena elección si quieres gestionar los costes y la latencia que pueden producirse si Bigtable empieza a enrutar tráfico hacia y desde una región lejana, o si prefieres tomar decisiones de conmutación por error en función de tu propio criterio o de tus reglas de negocio.

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 aplicación a cualquier clúster de la instancia de Bigtable. Por ejemplo, si tienes tres aplicaciones en Bombay y seis en Tokio, puedes configurar un perfil de aplicación para la aplicación de Bombay que se dirija a asia-south1-a y dos que se dirijan a asia-south1-c. En la aplicación de Tokio, configura tres perfiles de aplicación que dirijan a asia-northeast1-a y tres que dirijan a asia-northeast1-b.

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

Opción de enrutamiento entre clústeres

Si vas a implementar este caso práctico y quieres que Bigtable conmute automáticamente por error a una región si tu aplicación no puede acceder a la otra, usa el enrutamiento a varios clústeres.

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

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

Almacenar datos cerca de los usuarios

Si tienes usuarios en todo el mundo, puedes reducir la latencia ejecutando tu aplicación cerca de ellos 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 Google Cloud regiones, y tus datos se replican automáticamente en cada región.

En este caso práctico, usa perfiles de aplicación con enrutamiento de un solo clúster. El enrutamiento entre clústeres no es recomendable en 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 multiclúster cambia automáticamente la ruta del tráfico a una gran distancia, tu aplicación podría experimentar una latencia inaceptable e incurrir en costes de red adicionales inesperados.

Para configurar tu instancia en este caso práctico, haz lo siguiente:

  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 aplicaciones similares a los siguientes:

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

En esta configuración, tu aplicación usa el perfil de aplicación del 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 describe en esta página, responde a las siguientes preguntas para decidir cómo configurar tus perfiles de aplicación:

Siguientes pasos