¿Cuántos nodos? Parte 1: Una introducción al dimensionamiento de un cluster de Couchbase Server 2.0

La primera parte de esta serie ofrece una visión general de las consideraciones que deben tenerse en cuenta al dimensionar un clúster de Couchbase Server 2.0 para producción. En segundo part profundiza en casos y escenarios de uso específicos. El sitio Tercero entra en algún consideraciones sobre el hardware y el 4ª analiza las métricas y la monitorización para dimensionar y decidir cuándo hacer crecer el clúster.

A la hora de desplegar un clúster de Couchbase, quizás la pregunta más común (e importante) que surge es: ¿Cuántos nodos necesito?

Aunque obviamente hay muchas variables que intervienen en esto, la idea básica es evaluar el rendimiento general y los requisitos de capacidad para tu carga de trabajo y conjunto de datos, y luego dividirlo en el hardware y los recursos que tienes disponibles. Para una discusión visual y de alto nivel sobre estos factores, así como las prácticas generales para ejecutar un clúster Couchbase en producción, vea una de mis recientes presentaciones en la Conferencia Couchbase: Couchbase Server 2.0 en producción 24×7

El tamaño de tu cluster de Couchbase va a ser crítico para su estabilidad y rendimiento. Tu aplicación quiere tantas lecturas como sea posible saliendo de la caché, y la capacidad IO para manejar sus escrituras. Tiene que haber suficiente capacidad en todas las áreas para soportar todo lo demás que el sistema está haciendo, manteniendo el nivel requerido de rendimiento.

A lo largo de esta discusión, me referiré a 5 factores determinantes que uno debe tener en cuenta a la hora de dimensionar un clúster Couchbase: RAM, disco (IO y espacio), CPU, ancho de banda de red y en general distribución de datos.

1. RAM: Con frecuencia una de las áreas más cruciales para dimensionar correctamente, la RAM es lo que permite a Couchbase ser tan rápido. Los documentos en caché permiten que las lecturas se sirvan con una latencia muy baja y un alto rendimiento, y la RAM disponible hace lo mismo con las escrituras.

Pronto dispondremos de una calculadora de tamaño actualizada, pero la cantidad de RAM necesaria será una suma de: tus conjuntos de datos activos y réplicas, los metadatos necesarios para el seguimiento de todos ellos (unos 64 bytes de sobrecarga para cada elemento, además de las longitudes de las claves), qué parte del conjunto total de datos debe almacenarse en caché en la RAM (tu "conjunto de trabajo") y cualquier sobrecarga necesaria para que el sistema operativo realice un buen trabajo de almacenamiento en caché de IO de disco.

Con Couchbase Server 2.0, hemos reducido la sobrecarga de metadatos por elemento. También hemos mejorado en gran medida el algoritmo de "expulsión" para utilizar un bit NRU (no utilizado recientemente) que está diseñado para hacer que la capa de almacenamiento en caché de objetos sea más inteligente sobre qué datos deben mantenerse en la RAM en función de la carga de trabajo de la aplicación.

Al aprovechar nuestra nueva función de vista/índice, también querrás reservar RAM para que el sistema operativo haga su mejor trabajo al almacenar en caché las peticiones de disco. Más información en parte 2.

2. Disco: Los requisitos de tu subsistema de disco se dividen en dos componentes: tamaño e IO.

• Tamaño: Couchbase Server 2.0 va a tener mayores requerimientos de tamaño de disco que 1.8. Esto no suele ser un problema, ya que el espacio en disco se considera "barato", pero es importante tenerlo en cuenta.

El cambio de un formato de disco de inserción/actualización a uno de sólo adición significa que cada escritura (inserción/actualización/eliminación) creará una nueva entrada en el/los archivo(s). Esto aporta inmensas ventajas en términos de fiabilidad, rendimiento, consistencia de ese rendimiento y tiempos de calentamiento/arranque muy mejorados. Sin embargo, también significa que el tamaño del disco crecería sin límites.

Con la versión 1.8, a veces se producía una pérdida de rendimiento debido a la fragmentación de los archivos en disco en cargas de trabajo con actualizaciones/borrados frecuentes. En la versión 2.0, no sólo no existe esa fragmentación, sino que se ha incorporado un proceso automático de compactación que garantiza que sólo se conservan las copias de datos relevantes y reduce el tamaño de los propios archivos en disco.

Dependiendo de la carga de trabajo, el tamaño de disco necesario puede oscilar entre 2 y 3 veces el tamaño total del conjunto de datos (datos activos y réplica combinados) debido al formato de disco de sólo anexión. Las cargas de trabajo más pesadas de actualización/eliminación aumentarán el tamaño de forma más drástica que las cargas de trabajo pesadas de inserción y lectura. En realidad, es probable que el tamaño aumente y disminuya significativamente a lo largo del tiempo a medida que se ejecuta el proceso de compactación automática. La cifra de 2-3 veces se debe más a esta necesidad de expansión que al hecho de que los datos ocupen más espacio en el disco.

También hay nuevos requisitos de espacio cuando se aprovecha la función de vista/indización de Couchbase Server 2.0. De nuevo, mucho más sobre esto en la parte 2.

• IO: Esto será una combinación de tu tasa de escritura sostenida, la necesidad de compactar los archivos de la base de datos y cualquier otra cosa que requiera acceso al disco. Couchbase Server almacenará automáticamente las escrituras en la base de datos en RAM y eventualmente las persistirá en el disco. Debido a esto, el software puede acomodar tasas de escritura mucho más altas que las que un disco es capaz de manejar. Sin embargo, sostener estas escrituras eventualmente requerirá suficiente IO para bajarlo todo al disco.

Puedes configurar fácilmente los umbrales y la programación del proceso de compactación para controlar cuándo se inicia (y cuándo no), pero ten en cuenta que la finalización con éxito de la compactación es fundamental para mantener el tamaño del disco bajo control.

Voy a discutir los detalles mucho más en la parte 2, pero al tomar ventaja de las nuevas características de Couchbase Server 2.0, tales como vistas / indexación y la replicación entre centros de datos (XDCR) IO de disco se convertirá en mucho más crítico para dimensionar correctamente.

Por último, querrás asegurarte de que tienes suficiente espacio en disco e IO para tomar copias de seguridad, así como cualquier otra cosa fuera de Couchbase que necesite espacio o acceder al disco. Siempre que sea posible, es nuestra mejor práctica recomendada utilizar las opciones de configuración disponibles para separar los archivos de datos, índices y los directorios de instalación/configuración en unidades/dispositivos separados para asegurar que el IO y el espacio se asignan de manera efectiva.

3. CPU: Aunque normalmente no es una gran preocupación con Couchbase Server 1.8, las nuevas características de Couchbase Server 2.0 requieren una mayor cantidad de CPU. Nuestra capa de caché basada en objetos todavía permite un rendimiento extremadamente alto de las solicitudes a bajas latencias, incluso cuando la CPU está sobrecargada, pero será importante asegurarse de que hay suficiente potencia de procesamiento para mantener el resto del sistema funcionando sin problemas. Generalmente recomendamos al menos 4 núcleos, con un núcleo extra por cubo que esté siendo replicado con XDCR y un núcleo extra por documento de diseño (relacionado con vistas).

4. Red: En la mayoría de las situaciones, este no es el factor determinante para dimensionar un cluster Couchbase. Sin embargo, siempre es importante entender lo que está pasando a nivel de red y asegurarse de que hay suficiente ancho de banda entre tu aplicación y los nodos de Couchbase, así como entre los propios nodos para servir el tráfico. Con XDCR, también es importante asegurar suficiente ancho de banda entre los clusters (a menudo repartidos geográficamente en una WAN).

La red es casi siempre el cuello de botella final que afecta a la latencia. Por ejemplo, cabe esperar que las lecturas/escrituras de documentos individuales en/desde la caché reciban en algún lugar tiempos de respuesta en el percentil 99 en torno a 1-2ms en Amazon AWS, 500-900us en una red gig-e estándar y sub-200us en una red 10G. Todo esto indica que el propio servidor Couchbase es capaz de proporcionar latencias extremadamente bajas, es la red la que suele añadir tiempo adicional. Tenga en cuenta que su kilometraje puede variar y utilizar estos puntos de referencia para fines de comparación general.

5. Distribución de datos: Independientemente de todo lo demás, siempre es importante asegurarse de que tus datos están seguros. Couchbase es por diseño un sistema distribuido y puede proporcionar una escala muy lineal y redundancia de datos sólo cuando se le permite hacerlo de manera efectiva.

En el extremo, un único nodo puede satisfacer todas las necesidades de RAM, disco, CPU y red. Sin embargo, esto crea un evidente punto único de fallo.

Añadir un segundo nodo permitirá la replicación, pero sigue sin ser el entorno más ideal. Por un lado, un fallo de cualquiera de los nodos creará un único punto de fallo. Por otro, la eventual necesidad de escalar se verá beneficiada por más nodos en el clúster, ya que cada uno tendrá que mover cada vez menos datos.

Es por estas razones que siempre recomendamos al menos 3 nodos en un clúster, independientemente de los otros factores de tamaño.

Siempre habrá un factor que dicte el mayor nivel de exigencia y, por tanto, "determine" el número de nodos necesarios. Por ejemplo, un conjunto de datos relativamente pequeño con una carga de trabajo de escritura muy elevada exigirá más nodos debido a los requisitos de rendimiento del disco más que al tamaño total del conjunto de datos. Por otro lado, una carga de trabajo de lectura intensa en un conjunto de datos relativamente grande exigirá más nodos debido a los requisitos de RAM.

Todos los factores anteriores se benefician y escalan linealmente al añadir más nodos. No sólo las lecturas y escrituras de la aplicación se reparten uniformemente entre los nodos, sino que cosas como la compactación, el reequilibrio, las actualizaciones de vista/índice y XDCR también se ven muy favorecidas por el hecho de tener más nodos. Cada nodo sólo tiene que operar en su conjunto de datos local, por lo que los procesos intensivos de disco y CPU pueden realizarse en paralelo.

Aunque las necesidades de cada uno y la disponibilidad de recursos varían, siempre se debe errar en el lado de más nodos, más pequeños en lugar de forzar Couchbase en una arquitectura de escalado de unos pocos nodos muy caros.

Por último, las directrices y las calculadoras no pueden hacer más que proporcionar cifras de dimensionamiento sobre el papel. Lo mejor es probar el comportamiento de la aplicación específica a distintos niveles de escala y supervisar constantemente el sistema para asegurarse de que arranca y mantiene el tamaño adecuado.

Parte 2 de esta serie profundiza mucho más en las consideraciones a tener en cuenta a la hora de desplegar (o actualizar a) un cluster de Couchbase Server 2.0.

Hasta la próxima...