Instancias, clústeres y nodos

Para usar Bigtable, debes crear instancias que contengan clústeres a los que puedan conectarse tus aplicaciones. Cada clúster contiene nodos, las unidades de procesamiento que administran los datos y ejecutan las tareas de mantenimiento.

En esta página, encontrarás información sobre las instancias, los clústeres y los nodos de Bigtable.

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

Instancias

Una instancia de Bigtable es un contenedor de tus datos. Las instancias tienen uno o más clústeres, ubicados en diferentes zonas. Cada clúster tiene al menos 1 nodo.

Las tablas pertenecen a las instancias, no a los clústeres o nodos. Si tienes una instancia con más de un clúster, estás usando la replicación. Esto significa que no puedes asignar una tabla a un clúster individual ni crear políticas de recolección de elementos no utilizados únicas para cada clúster de una instancia. Tampoco puedes hacer que cada clúster almacene un conjunto de datos distinto en la misma tabla.

Las instancias tienen algunas propiedades importantes que es necesario conocer, como las siguientes:

  • El tipo de almacenamiento (SSD o HDD)
  • Los perfiles de aplicaciones, destinados a las instancias que usan la replicación

Estas propiedades se describen con más detalle en las siguientes secciones.

Tipos de almacenamiento

Cuando creas una instancia, debes elegir si sus clústeres almacenarán datos en unidades de estado sólido (SSD) o unidades de disco duro (HDD). A menudo, SSD es la elección más eficiente y rentable, pero no siempre.

La elección entre SSD y HDD es permanente, y todos los clústeres de tu instancia deberán usar el mismo tipo de almacenamiento, por lo que debes elegir el tipo de almacenamiento adecuado para tu caso práctico. Si deseas obtener más información para tomar una decisión, consulta Elige entre el almacenamiento SSD y HDD.

Perfiles de aplicación

Después de crear una instancia, Bigtable la usa para almacenar perfiles de aplicaciones o perfiles de apps. En las instancias que usan la replicación, los perfiles de apps controlan cómo se conectan las aplicaciones a los clústeres de la instancia.

Si tu instancia no usa la replicación, puedes usar los perfiles de apps para asignar identificadores distintos a cada una de las aplicaciones o a cada función dentro de una aplicación. Luego, puedes ver gráficos de cada perfil de app en la consola de Google Cloud.

Si quieres obtener más información sobre los perfiles de apps, consulta Perfiles de aplicaciones. Para obtener información sobre cómo configurar los perfiles de apps de una instancia, consulta Configura perfiles de apps.

Clústeres

Un clúster representa el servicio de Bigtable en una ubicación específica. Cada clúster pertenece a una instancia de Bigtable, que puede tener hasta 8 regiones. Cuando la aplicación envía solicitudes a una instancia de Bigtable, uno de los clústeres de la instancia controla esas solicitudes.

Cada clúster se encuentra en una sola zona. Una instancia puede tener clústeres en hasta 8 regiones en las que Bigtable esté disponible. Cada zona de una región puede contener solo un clúster. Por ejemplo, si una instancia tiene un clúster en us-east1-b, puedes agregar un clúster en una zona diferente en la misma región, como us-east1-c, o una zona en una región distinta, como europe-west2-a.

La cantidad de clústeres que puedes crear en una instancia depende de la cantidad de zonas disponibles en las regiones que elijas. Por ejemplo, si creas clústeres en 8 regiones que tienen 3 zonas cada una, la cantidad máxima de clústeres que puede tener la instancia es de 24. Para obtener una lista de las zonas y regiones en las que Bigtable está disponible, consulta Ubicaciones de Bigtable.

Las instancias de Bigtable que tienen solo 1 clúster no usan la replicación. Si agregas un segundo clúster a una instancia, Bigtable comienza a replicar los datos de forma automática; para hacerlo, mantiene copias independientes de los datos en cada una de las zonas de los clústeres y sincroniza las actualizaciones entre las copias. Puedes elegir a qué clúster se conectan las aplicaciones, lo que permite aislar los diferentes tipos de tráfico entre sí. También puedes permitir que Bigtable balancee el tráfico entre los clústeres. Si un clúster deja de estar disponible, puedes realizar la conmutación por error de uno a otro. Si quieres obtener más información sobre cómo funciona la replicación, consulta la descripción general de la replicación.

En la mayoría de los casos, debes habilitar el ajuste de escala automático para un clúster, de modo que Bigtable agregue y quite nodos según sea necesario para controlar las cargas de trabajo del clúster.

Cuando creas un clúster, puedes habilitar el escalamiento de 2 nodos, una configuración que configura el clúster para que siempre escale en incrementos de dos nodos. Para obtener más información, consulta Factor de escalamiento de nodos.

Nodos

Cada clúster de una instancia tiene 1 o más nodos, que son recursos de procesamiento que Bigtable usa para administrar los datos.

En segundo plano, Bigtable divide todos los datos de una tabla en tablets independientes. Estos se almacenan en el disco, separadas de los nodos, pero en la misma zona. Cada tablet se asocia con un solo nodo.

Los nodos son responsables de lo siguiente:

  • Mantener un seguimiento de los tablets específicos en el disco
  • Manejar las lecturas y escrituras entrantes para sus tablets
  • Realizar tareas de mantenimiento en sus tablets, como compactaciones periódicas.

Un clúster debe tener suficientes nodos para admitir su carga de trabajo actual y la cantidad de datos que almacena. De lo contrario, es posible que el clúster no pueda administrar las solicitudes entrantes, y la latencia aumente. Supervisa el uso de CPU y disco de los clústeres y agrega nodos a una instancia cuando las métricas excedan las recomendaciones que se indican en Planifica tu capacidad.

Si quieres obtener más información sobre cómo Bigtable almacena y administra los datos, consulta Arquitectura de Bigtable.

Nodos para clústeres replicados

Cuando tu instancia tiene más de un clúster, la conmutación por error se convierte en una consideración cuando configuras la cantidad máxima de nodos para el ajuste de escala automático o asignas los nodos de forma manual.

  • Si usas el enrutamiento de varios clústeres en cualquiera de tus perfiles de app, puede ocurrir una conmutación por error automática en caso de que uno o más clústeres no estén disponibles.

  • Cuando realizas una conmutación por error manual de un clúster a otro, o cuando se produce una conmutación por error automática, lo ideal es que el clúster receptor tenga suficiente capacidad para admitir la carga. Puedes asignar siempre suficientes nodos para admitir la conmutación por error, lo que puede ser costoso, o puedes confiar en el ajuste de escala automático para agregar nodos cuando se produzca la conmutación por error del tráfico, pero ten en cuenta que podría haber un breve impacto en el rendimiento mientras el clúster se escala.

  • Si todos tus perfiles de aplicación usan el enrutamiento de un solo clúster, cada clúster puede tener una cantidad de nodos diferente. Cambia el tamaño de cada uno en función de su carga de trabajo.

    Dado que Bigtable almacena una copia independiente de tus datos en cada clúster, estos siempre deben tener nodos suficientes para admitir el uso del disco y replicar las escrituras entre ellos.

    De todas formas, puedes realizar la conmutación por error manual de un clúster a otro si es necesario. Sin embargo, si un clúster tiene muchos más nodos que otro y debes realizar una conmutación por error al que tiene menos, es posible que debas agregar nodos primero. Nada garantiza que habrá nodos disponibles cuando necesites realizar la conmutación por error. La única manera de reservarlos por adelantado es agregarlos al clúster.

¿Qué sigue?