¿Cuántos nodos? Parte 2: Dimensionamiento de un cluster de Couchbase Server 2.0

En el primera parte de esta serieEn el blog de Couchbase, di una visión general de los 5 factores que determinan el tamaño de tu clúster Couchbase: RAM, disco (IO y tamaño), CPU, red y distribución de datos. En esta segunda parte, quiero entrar más en detalle sobre casos de uso y escenarios específicos para ver cómo los distintos diseños de aplicaciones y cargas de trabajo afectan a estos diversos factores. El sitio tercera entrada de esta serie profundiza en las distintas opciones de hardware e infraestructura. Por último, el cuarta entrada examina las métricas que puede supervisar tanto dentro como fuera de Cocuhbase para comprender los requisitos de dimensionamiento.

Un cluster de Couchbase Server 1.8 era bastante sencillo de dimensionar, y puedes encontrar una discusión sobre esto aquí, junto con una calculadora. Con las recientes características añadidas a la versión 2.0, esto se vuelve un poco más complicado...

Veamos dos consideraciones sobre el diseño y los requisitos de las aplicaciones que influirán en el tamaño del clúster:

• ¿Su aplicación consiste principalmente (o incluso exclusivamente) en el acceso a documentos individuales? ¿O espera hacer uso de nuestra función de indexación y consulta? Aquí encontrará una buena descripción de cómo combinar el acceso a claves/documentos y las vistas.
• ¿Tiene previsto utilizar el nuevo Función de replicación entre centros de datos (XDCR)?

Acceso a documentos individuales y actualización desde 1.8

El caso de uso más sencillo de tratar es cuando una aplicación realmente sólo requiere el acceso a un documento individual (lo que suele denominarse un caso de uso "clave/valor"). Por ejemplo, los almacenes de sesiones y perfiles de usuario, las aplicaciones de segmentación publicitaria, muchos juegos sociales, etc.

El dimensionamiento de estos casos de uso es muy similar al de la versión 1.8, con algunas modificaciones. Como en todas las discusiones sobre dimensionamiento, se aplican los mismos 5 factores determinantes, siendo el dimensionamiento de RAM el que suele salir ganando aquí.

• RAM: Ver parte 1 para una discusión sobre las consideraciones para dimensionar adecuadamente la RAM. Para los que estéis familiarizados con 1.8, no ha cambiado mucho. Si no estás familiarizado, echa un vistazo a nuestras directrices y calculadora de tamaño.
• Disco: Ten en cuenta que actualizar de Couchbase Server 1.8 a 2.0 puede requerir considerablemente más espacio en disco. Desde una perspectiva IO, el formato de disco append-only leerá y escribirá datos más rápido y de forma más consistente que 1.8. Sin embargo, también existe la necesidad de compactación en línea de los archivos de disco y esto requerirá una cierta cantidad de IO de disco añadido. Este blog puede ayudarle a comprender mejor la compactación.
• CPU: Como se menciona en parte 1Con la compactación automática, la lectura y escritura de la aplicación dentro y fuera de la RAM puede ser manejada muy eficientemente con muy poca CPU. La adición de la compactación automática añade un poco más de actividad de la CPU debido a la IO del disco, pero normalmente no afectará al rendimiento de la aplicación. Mientras que las instalaciones típicas de la versión 1.x podrían "arreglárselas" con 2 núcleos, estamos aumentando esta recomendación a al menos 4, incluso para el caso de uso básico de "clave-documento".

Si se actualiza desde la versión 1.x, se recomienda encarecidamente ponerse en contacto con Soporte de Couchbase para que podamos ayudar a revisar el entorno, ofrecer recomendaciones y ayudar a que la actualización sea lo más fluida posible.

Replicación entre centros de datos (XDCR)

Muchas situaciones/entornos crean la necesidad de que los datos sean replicados a través de múltiples clusters de Couchbase. Necesitas XDCR para recuperación de desastres, geolocalización de datos o simplemente sincronización para pruebas. Será importante asegurarte de que tu clúster Couchbase tiene un tamaño efectivo. Estos requisitos de capacidad se suman a todo lo demás que se pide a los clústeres que realicen.

Para el propósito de esta discusión, echaré un vistazo por separado a los requisitos de los clústeres de "origen" y "destino" para XDCR. En producción, puede tener una topología uno-muchos, muchos-uno o muchos-muchos combinando múltiples flujos de replicación unidireccionales.

1. Fuente Cluster

• RAM: Esto es un poco variable, pero hemos visto que hay un poco de RAM extra necesaria sólo para manejar el proceso de replicación de datos a otro clúster. Variará un poco en función del número de cubos (y flujos de replicación), pero una buena estimación es dejar unos 2 GB de RAM libre por nodo por encima de lo necesario para mantener los datos. Esto lo necesita el proceso Erlang (beam.smp en Linux, erl.exe en Windows).
• Disco: La implementación actual de XDCR implica el envío de datos desde el subsistema de disco de un clúster de origen al de destino. Esto permite que no se mantengan colas en RAM, y que el reinicio de un proceso de replicación siga teniendo lugar sin reenviar todos los datos. Además, las escrituras múltiples de la aplicación local se desduplican automáticamente antes de replicarse, lo que ahorra un valioso ancho de banda de red. Lo que esto significa, sin embargo, es que el clúster de origen de cualquier XDCR tendrá mayores requisitos de IO en disco para leer los documentos una vez que hayan sido almacenados en disco.
• CPU: El cluster de origen de un XDCR también tendrá mayores requerimientos de CPU para procesar y enviar los datos a otro cluster. Por defecto, hay 32 flujos por nodo por replicación. Esto puede aumentarse, pero tenga en cuenta que un mayor número de flujos requerirá más CPU. Una mejor práctica general debería ser tener un núcleo extra por cada cubo XDCR que se replique.

2. Cluster de destino:

• RAM y tamaño del disco: Por lo general, no hace falta decirlo, pero si envías más datos a un clúster (por ejemplo, agregándolos de otros clústeres), necesitará más RAM y espacio en disco para contener esos datos. Si te limitas a replicar el mismo conjunto de datos, no debería haber más requisitos.
• IO de disco: Aunque no necesite más espacio para el mismo conjunto de datos (es decir, no necesita el conjunto de trabajo de la fuente en memoria), es probable que incurra en más escrituras desde el clúster o clústeres de origen a través de XDCR. Necesitará suficiente IO de disco para persistir estas escrituras en disco y también suficiente ancho de banda IO para compacto estos datos junto con la aplicación local escribe. ???
• En general, es importante dimensionar tanto el clúster de origen como el de destino y probar su rendimiento para la carga de trabajo. Sin embargo, se sabe que el rendimiento XDCR en el clúster de origen se beneficiará enormemente al tener más nodos, ya que los datos que necesitan ser enviados lo hacen en paralelo.

3. Red

Mientras que los requisitos de red entre clusters para Couchbase Server no requieren mucha consideración, la transferencia de datos a través de un enlace WAN probablemente requerirá un poco más de reflexión. Couchbase Server comprobará y reiniciará XDCR automáticamente cuando la red lo permita, pero la replicación sólo es efectiva si los datos pueden llegar al otro lado.

4. Replicación bidireccional y otras topologías

Este debate se ha centrado en los clústeres de origen y destino únicos que replican un único bucket. La replicación bidireccional convierte a cada clúster en origen y destino, con los requisitos de capacidad de ambos.

Cuando se combinan varios clusters y/o varios buckets, es importante asegurarse de que cada uno tiene capacidad suficiente. Por ejemplo, un uno-muchos creará más flujos de replicación en el único origen, y un muchos-uno generará una sobrecarga significativa (espacio en disco / IO / CPU) en el clúster de destino.
Vistas y consultas

Una de las nuevas características más solicitadas de Couchbase Server 2.0 es la adición de vistas para indexar/consultar tus datos. Como con cualquier nueva capacidad, viene con ciertos requisitos y consideraciones relativas al tamaño del clúster.

Actualmente, el sistema de vistas está basado en disco, lo que significa que aumentarán los requisitos de espacio en disco y de E/S, y que se necesitará más RAM fuera de la caché basada en objetos para mejorar el rendimiento y la latencia de las consultas a través de la caché de E/S integrada en el sistema operativo.

El impacto real dependerá significativamente tanto de la carga de trabajo de tu aplicación como de la cantidad y complejidad de tus documentos de diseño y definiciones de vistas. Es muy importante seguir estas prácticas recomendadas de escritura de vistas al diseñarlas para mitigar y reducir los requisitos de tamaño en la medida de lo posible. Las cargas de trabajo de escritura pesada pondrán más presión en la actualización real de los índices y las cargas de trabajo más orientadas a la lectura pondrán más carga en la consulta de esos índices.

1. Actualización del índice

Cuando se inserta o actualiza un documento, se produce una actualización del índice. Este desencadenamiento forma parte de nuestro proceso normal en segundo plano y/o procede de una solicitud de una aplicación. El tratamiento efectivo de estas actualizaciones tendrá las siguientes repercusiones:

• Tamaño del disco: Hay archivos extra creados tanto para cada documento de diseño, como para cada vista dentro de él. Estos archivos se rellenan con las claves y valores emitidos por las descripciones de las vistas (por eso es importante que sean lo más pequeños posible). Se trata de ficheros "append-only", por lo que crecerán con cada nueva inserción, actualización o borrado y se compactan de forma similar a los ficheros de datos.
• IO de disco: Posiblemente el mayor impacto que el uso de vistas tendrá en un sistema es en el IO de disco. La actualización del índice en sí requerirá potencialmente una cantidad significativa de IO ya que cada escritura de documento puede necesitar ser escrita en múltiples archivos de índice. Estas actualizaciones son manejadas por hilos y procesos separados para no afectar el funcionamiento normal de la base de datos, pero tener suficiente IO será crucial para mantener los índices actualizados. Además, la compactación normal y automática de los índices consumirá cierta cantidad de IO de disco y es necesaria para mantener el tamaño de los archivos de disco bajo control.
• CPU: Junto con el IO de disco, las actualizaciones de vistas incurrirán en una cantidad añadida de CPU. Por defecto hay 4 indexadores por bucket por nodo. Los sistemas con muchos núcleos se beneficiarán aumentando este número. La práctica general debería ser tener 1 núcleo adicional por documento de diseño (cada vista se procesa en serie dentro de un documento de diseño, pero se pueden procesar múltiples documentos de diseño en paralelo).
• Índices de réplica: Desactivados por defecto, pueden activarse para mejorar el rendimiento de las consultas tras el fallo de un nodo. Sin embargo, al menos duplicarán (dependiendo de cuántas réplicas estén configuradas) la cantidad de espacio en disco, IO de disco y carga de CPU requerida por el sistema. Junto con los indexadores primarios, hay 2 indexadores de réplica por bucket por nodo por defecto.

El proceso de actualización del índice se escala linealmente al añadir más nodos, ya que cada nodo sólo es responsable de procesar sus propios datos.

Es nuestra mejor práctica configurar la ruta de disco para los índices para que estén en una unidad / disco separado de los archivos de datos. Dado que cada conjunto de archivos es de sólo anexar, las escrituras son siempre secuenciales en un archivo. Sin embargo, combinar los archivos de datos e índices crea mucho más IO aleatorio en el disco compartido. Además, las cargas de trabajo de escritura pesada deben considerar seriamente el uso de SSD.
2. Consulta de vistas
Para que una aplicación obtenga el mejor rendimiento al consultar vistas, deben tenerse en cuenta los siguientes efectos sobre el tamaño:

• RAM: A pesar de que los archivos de índice se almacenan y acceden desde el disco, el formato de estos archivos de disco se presta muy bien a la caché de IO de disco normal del sistema operativo. Debido a esto, es importante dejar una cierta cantidad de RAM disponible para el sistema fuera de la cuota de Couchbase. El número real dependerá en gran medida del tamaño de tus índices, pero incluso una cantidad relativamente pequeña puede tener un gran impacto en la latencia y el rendimiento de las consultas.
• IO de disco: Aunque no se necesitará espacio adicional por el mero hecho de consultar las vistas, se requerirá una cierta cantidad de IO de disco adicional. Esto dependerá en gran medida de la frecuencia con la que se actualicen y consulten los índices, así como de la cantidad de RAM disponible para almacenarlos en caché.
• CPU: También aumentarán los requisitos de CPU al consultar las vistas debido a la gestión de las consultas individuales y la fusión de los resultados de los múltiples nodos.

Dada la implementación scather/gather de indexación y consulta, cada nodo necesita participar en cada petición de consulta. El rendimiento de las consultas puede mejorarse aumentando la caché disponible del sistema de archivos o el hardware físico.

3. Efecto de las opiniones sobre el reequilibrio

Al aprovechar la nueva característica Views de Couchbase Server 2.0, será importante conocer y prepararse para el impacto que esto tendrá en el reequilibrio del cluster.

En algún momento del proceso de reequilibrio, los datos que se mueven de un nodo a otro deben reflejarse en los índices de ese nodo para que las consultas sigan devolviendo los mismos resultados. Hemos diseñado el sistema para que realice esta actualización a lo largo de todo el proceso de reequilibrado, en lugar de intentar ponerlo todo al día al final. A medida que cada se mueve la partición de datos el índice se actualiza antes de transferir la propiedad de uno a otro. Este comportamiento es configurable. Puede desactivar el reequilibrio basado en índices si su aplicación puede manejar resultados inconsistentes y acelerar significativamente el tiempo de reequilibrio.

Si se deja activada esta opción, se producen los siguientes efectos:

• RAM: Dado que hay que realizar un procesamiento adicional, se utilizará más RAM para mantener las escrituras pendientes en la cola de escritura en disco de cada nodo de destino.
• Tamaño del disco: Habrá una cantidad significativamente mayor de espacio en disco utilizado durante el reequilibrio para garantizar tanto la seguridad como la coherencia de las vistas. Esto se limpia una vez que los datos ya no son necesarios, pero debido a la gran cantidad de escrituras, es posible que el proceso de compactación no sea capaz de mantener el ritmo hasta que se haya completado el reequilibrio.
• IO de disco: Dado que habrá una gran cantidad de datos siendo leídos, escritos e indexados al mismo tiempo, el IO de disco aumentará considerablemente durante el reequilibrio.

Junto con casi cualquier otra parte de Couchbase, el proceso de rebalanceo se beneficia al tener más nodos. Imagina añadir un solo nodo a un cluster. En un extremo, pasar de 1 a 2 nodos es siempre el peor escenario. Esto se debe a que hay que mover la mitad del conjunto de datos. En la mayoría de los casos, también se crea un conjunto de datos de réplica durante el reequilibrio. En este caso especial, sólo hay un nodo disponible para gestionar toda la lectura y recepción de datos. En cambio, pasar de 21 a 22 nodos es mucho menos intensivo. Sólo hay que mover 1/21 de los datos, probablemente no se están creando réplicas y la carga de lectura/recepción se reparte entre los 21 nodos.
Conclusión

Para cualquier sistema complejo (especialmente una base de datos), el dimensionamiento nunca es una tarea fácil. Las variables son numerosas y las consideraciones y decisiones deben basarse siempre en los requisitos individuales de la aplicación y la disponibilidad de recursos. Nos esforzaremos constantemente por hacer todo lo posible para proporcionar orientación, pero es muy importante probar y poner en escena un sistema con la carga de trabajo / requisitos de su aplicación, tanto antes como después de la implantación.

En siguiente y 3ª entrada de esta serie proporciona algunas recomendaciones/consideraciones específicas de despliegue y hardware para un cluster de producción de Couchbase Server.