Ejemplos de parámetros de configuración de replicación
En esta página, se describen algunos casos de uso comunes de Bigtable replicación y presenta la configuración que puedes usar para admitir estos usos diferentes.
- Aísla las cargas de trabajo de estadísticas por lotes de otras aplicaciones
- Crea alta disponibilidad (HA)
- Proporciona copias de seguridad casi en tiempo real
- Mantén la disponibilidad alta y la resiliencia regional
- Almacena los datos cerca de tus usuarios
Esta página también explica cómo decidir qué configuración utilizar para otros usos casos.
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 tu en los clústeres de la instancia. El ajuste de escala automático le permite agregar y quitar nodos automáticamente en un clúster según la carga de trabajo.
Si eliges la asignación manual de nodos, aprovisiona suficientes nodos todos los clústeres de una instancia para garantizar que cada uno pueda controlar por lotes, 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 experimenta problemas de rendimiento debido a la acumulación de memoria y escribe en otros de la instancia podrían rechazarse.
Los ejemplos en este documento describen la creación de 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:
Crear una instancia con dos clústeres
Crea dos perfiles de app, uno llamado
live-traffic
y otra llamadabatch-analytics
.Si los ID de tu clúster son
cluster-a
ycluster-b
, el perfil de aplicaciónlive-traffic
debe enrutar las solicitudes acluster-a
y el perfil de appbatch-analytics
debe enrutarlas acluster-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 appbatch-analytics
, si solo usarás este perfil de app para las lecturas.Usa el perfil de la app
live-traffic
para ejecutar una carga de trabajo de tráfico en vivo.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:
Crea una instancia con tres clústeres.
Con estos pasos, se supone que tus clústeres usan los ID
cluster-a
,cluster-b
ycluster-c
.Crea los siguientes perfiles de apps:
live-traffic-app-a
: Enrutamiento de un solo clúster de tu aplicación acluster-a
live-traffic-app-b
: Enrutamiento de un solo clúster de tu aplicación acluster-b
batch-analytics
: Enrutamiento de un solo clúster del trabajo de estadísticas por lotes acluster-c
Utiliza los perfiles de la app live-traffic para ejecutar cargas de trabajo con tráfico en vivo.
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 está ubicado ese 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 (recomendado configuración). La configuración recomendada para la alta disponibilidad es una instancia tiene N + 2 clústeres que se encuentran en una región diferente. Por ejemplo, si el la cantidad mínima de clústeres que necesitan para entregar datos es 2, necesitas una instancia con cuatro clústeres para mantener la alta disponibilidad. Esta configuración y 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.
Configuración de ejemplo:
cluster-a
en la zonaus-central1-a
en Iowacluster-b
en la zonaeurope-west1-d
en Bélgicacluster-c
en la zonaasia-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 zonaaustralia-southeast1-a
en Sídneycluster-b
en la zonaaustralia-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 zonaasia-northeast1-c
en Tokiocluster-b
en la zonaasia-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. 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 tiene un clúster en la región B. Si escribes a la región B, se cobran dos veces porque tienes dos clústeres en la región A.
Configuración de ejemplo:
cluster-a
en la zonaeurope-west1-b
en Bélgicacluster-b
en la zonaeurope-west1-d
en Bélgicacluster-c
en la zonaeurope-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 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.
Si quieres configurar tu instancia para este caso de uso, crea un perfil de app que use enrutamiento de un solo clúster o actualiza el perfil predeterminado perfil de app para usar el enrutamiento de un solo clúster. 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:
Usa un perfil de app con enrutamiento de un solo clúster para ejecutar una carga de trabajo.
Usa la consola de Google Cloud para supervisar los clústeres de la instancia y confirmar que solo uno controle los clústeres entrantes solicitudes.
El otro seguirá usando los recursos del CPU para ejecutar la replicación y otras tareas de mantenimiento.
Actualiza el perfil de la aplicación a fin de que se oriente al segundo clúster de la instancia.
Recibes una advertencia sobre la pérdida de la función de lectura-tus-escrituras coherencia, lo que también significa que perderás y mantener la coherencia.
Si habilitaste las transacciones de una sola fila, también recibirás una advertencia. sobre las posibilidades de pérdida de datos. Pierdes datos si envías escrituras con conflicto mientras se ejecuta la conmutación por error.
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 de uso, 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:
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 zonaasia-south1-a
en Bombaycluster-b
en la zonaasia-south1-c
en Bombaycluster-c
en la zonaasia-northeast1-a
en Tokiocluster-d
en la zonaasia-northeast1-b
en Tokio
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:
Crea una instancia con clústeres en tres regiones geográficas distintas, como Estados Unidos, Europa y Asia.
Coloca un servidor de aplicaciones cerca de cada región.
Crea perfiles de apps similares a los siguientes:
clickstream-us
: Enrutamiento de un solo clúster al clúster en los Estados Unidosclickstream-eu
: Enrutamiento de un solo clúster al clúster en Europaclickstream-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:
¿Necesitas realizar transacciones de fila única, como operaciones de lectura, modificación y escritura (incluidos incrementos y anexos) y operaciones de verificación y modificación (también conocidas como escrituras o mutaciones condicionales)?
Si es así, tus perfiles de app deben usar el enrutamiento de un solo clúster para evitar la pérdida de datos y debes controlar las conmutaciones por error de forma manual.
¿Quieres que Bigtable controle automáticamente las conmutaciones por error?
Si es así, tus perfiles de aplicación deben usar el enrutamiento de varios clústeres. Si un clúster no puede procesar una solicitud entrante, Bigtable realiza la conmutación por error automáticamente en los otros clústeres. Obtén más información sobre las conmutaciones por error automáticas.
Para prevenir la pérdida de datos, no puedes habilitar las transacciones de una sola fila cuando usas el enrutamiento de varios clústeres. Más información.
¿Quieres mantener una copia de seguridad o un clúster de repuesto en caso de que el principal no esté disponible?
Si es así, usa el enrutamiento de un solo clúster en tus perfiles de aplicación y, si es necesario, realiza la conmutación de forma manual al clúster de copia de seguridad.
Esta configuración también permite usar las transacciones de una sola fila si es necesario.
¿Quieres dividir los tipos de tráfico entre los clústeres?
Si es así, usa el enrutamiento de un solo clúster en tus perfiles de aplicación y dirige cada tipo de tráfico a su propio clúster. Realiza la conmutación por error de forma manual entre los clústeres si es necesario.
Puedes habilitar las transacciones de una sola fila en tu perfil de la aplicación si es necesario.
¿Qué sigue?
- Obtén más información sobre los perfiles de app.
- Crea un perfil de la app o actualiza uno existente.
- Descubre cómo funcionan las conmutaciones por error.