¿Cuántos nodos? Parte 3: Consideraciones sobre el hardware

Las dos primeras partes de esta serie cubrían una visión general de la 5 factores para dimensionar un clúster de Couchbase Servery un análisis más profundo de los distintos casos de uso y características, así como de los efectos que tienen en el dimensionamiento. En la cuarta parte se analizará métricas para la supervisión un clúster de Couchbase Server para determinar el tamaño adecuado y cuándo hacerlo crecer.

Ahora me gustaría proporcionar algunas orientaciones sobre las recomendaciones de hardware. Aunque sería fácil para nosotros en Couchbase exigir requisitos muy estrictos para el hardware, no sería en absoluto apropiado dada la gran diferencia en casos de uso y entornos de aplicación/infraestructura en los que nuestros clientes quieren utilizar el software. Tomemos por ejemplo la diferencia entre un cliente que ejecuta en su propio hardware físico en su propio centro de datos donde tienen acceso a sistemas de 512 GB de RAM, tarjetas FusionIO y redes 10Gig-E frente a un cliente que ejecuta dentro de AWS de Amazon. Los clientes de Couchbase abarcan estos dos extremos y casi todas las configuraciones intermedias... puedes ver lo difícil que es para nosotros ofrecer recomendaciones específicas.

Al más alto nivel, Couchbase está diseñado y probado para funcionar en "hardware básico". Como se puede deducir de lo anterior, "commodity" significa cosas diferentes para diferentes personas. Siempre pregunto a los clientes con qué tipo de perfil de hardware cuentan o quieren o planean contar. A continuación, dimensionamos el clúster teniendo en cuenta las ventajas de la escalabilidad horizontal y el número de nodos necesarios para soportar el conjunto de datos y la carga de trabajo... en lugar de decir que definitivamente necesitará 6 HP DL 380 con 64 GB de RAM, 24 núcleos de CPU y 2 TB de SSD. Nuestra recomendación de hardware estará en la intersección de su conjunto de datos y los requisitos de carga de trabajo, los recursos disponibles para usted y el costo. Nuestra documentación también cubre esto brevemente: Recursos necesarios

Vale, basta de renuncias, entremos en detalles. En las partes anteriores de esta serie, enumeré los 5 factores para dimensionar Couchbase:

1. RAM
2. Disco
3. CPU
4. Red
5. Distribución de datos

Voy a empezar por lo más fácil (por abajo) e iré subiendo.

1. Distribución de datos

Lo más fácil :-) Cualquier despliegue de producción de Couchbase debería tener no menos de 3 nodos. El motivo es la seguridad de autofailover, la facilidad de actualización y la escalabilidad.

2. Red

La 2ª más fácil :-S. En general, es probable que tengas muy pocas opciones en cuanto al tipo de red que tienes disponible. Hoy en día, cualquier cosa de 1Gig-E o superior será suficiente para Couchbase. Si tu aplicación es particularmente sensible a la latencia o requiere un rendimiento extremadamente alto, te beneficiarás de una conectividad de extremo a extremo de 10Gig-E.

Pon el menor número de "saltos" entre tus nodos Couchbase y los clientes en términos de cortafuegos y routers. Si necesitas tenerlos en medio, ten en cuenta que tu latencia se verá afectada.

Al configurar XDCRLa variabilidad de la red es mayor, pero también es menos importante debido a cómo hemos diseñado esa función.

3. CPU

Couchbase tiene más que ver con los núcleos de la CPU que con la velocidad de cada uno (2,4 GHz frente a 2,6 GHz frente a 3,0 GHz frente a Intel frente a AMD no supondrá ninguna diferencia). Couchbase es multi-hilo en muchos sentidos y hará uso de muchos núcleos... pero tampoco es un requisito tener 32 o 64 o más núcleos (la mayoría estaría de acuerdo en que esos no son exactamente "commodity"). Empieza con 4 núcleos para una carga de trabajo básica, y luego añade núcleos adicionales según sea necesario para vistas y XDCR. Véase la partes anteriores de esta serie para más detalles.

4. Disco

Este va a ser un gran tema, como debe ser. Couchbase es una base de datos, pero diferente a cualquier otra. Donde Oracle/MySQL/Postgres dependen mucho del rendimiento del disco, Couchbase separa el rendimiento principal de la aplicación del IO del disco, lo que significa que los requisitos son mucho menores. Más bajos, pero no inexistentes.

• Utiliza el mejor almacenamiento "local" que tengas disponible.  Nuestra mejor práctica y arquitectura gira en torno a un sistema distribuido. No recomendamos el uso de un sistema de almacenamiento centralizado como SAN o NAS. Mientras que estos pueden ser capaces de estar a la altura de las necesidades de rendimiento, presentan un único cuello de botella / punto de fallo (incluso si HA) que limita la naturaleza distribuida de Couchbase. Los beneficios de tener un almacenamiento compartido pueden compensar esto, pero es algo a tener en cuenta.
• EBS < Unidad virtual < 7200 < 10K < SSD < FusionIO: Más adelante hablaré de las consideraciones de hardware para la nube y las máquinas virtuales, pero es lógico que los discos más rápidos sean más rápidos. Normalmente vemos alrededor de 1000 o menos escrituras por segundo por nodo para EBS, alrededor de 1500 para unidades de 10K y más de 6000 para SSD. He visto tasas de escritura de más de 30.000 por segundo por nodo... ya me entiendes: todo depende. Si tu carga de trabajo va a ser tal que dependes en gran medida del rendimiento del disco, ya sea para lecturas pesadas (desde el disco), escrituras sostenidas, actualización de índices y/o XDCR, entonces querrás pensar más en tu capa de disco. Me doy cuenta de que "pesado" es un término muy vago, pero no hay otra manera de decirlo y sólo puedo recomendar que aproveches la experiencia de nuestros equipos de ingeniería y de campo aquí en Couchbase para obtener detalles específicos acerca de tu aplicación.
• RAID no es un requisito, pero si tienes una configuración de despliegue estándar, generalmente RAID 0 o 10 es mejor que 1 o 5. Querrás usar RAID para un mejor rendimiento y latencia, no para una mejor redundancia ya que Couchbase ya tendrá réplicas a través del cluster. En casos donde tengas los discos y el espacio disponible y estés almacenando grandes cantidades de datos (>100GB) por nodo, RAID 5 puede valer la pena para evitar tener que hacer failover y rebalancear cuando un disco falla.
• Si dependes de las vistas, es una buena idea tener dos discos separados y dividir los datos y las vistas entre ellos para obtener el mejor rendimiento y eficiencia. Más información sobre las vistas en partes anteriores de esta serie.
• El espacio en disco suele ser barato, consigue tanto como puedas permitirte. Consulte mi entradas anteriores para saber cómo hay que tener en cuenta nuestro formato de archivo append-only y la compactación.

5. RAM

Esto también es bastante fácil... generalmente consigue tanta RAM como puedas en todo el cluster (basado en tus necesidades de cálculo de tamaño). El punto óptimo para Couchbase es normalmente alrededor de 8GB-128GB por nodo. Aunque ciertamente hay excepciones; menos de 8 no deja mucho espacio disponible para headroom o caché de disco y más de 128 empieza a poner una gran cantidad de datos bajo la responsabilidad de la disponibilidad de un solo nodo y los recursos disponibles.

Algunas otras consideraciones:

• Aunque pueda parecer intuitivo intentar usar toda la memoria disponible, en realidad es una buena práctica dejar algo de RAM disponible fuera de la cuota de Couchbase. La mayoría de los sistemas operativos modernos quieren algunos gigabytes (Windows normalmente un poco más que Linux), y puede haber otros procesos ejecutándose en estos nodos como agentes de monitorización. También hay necesidades de caché IO tanto para las vistas como para el funcionamiento general del sistema. Normalmente recomendamos asignar alrededor de 60-80% de la RAM del sistema a la cuota de Couchbase, dejando el resto para necesidades de memoria fuera de Couchbase.
• Es mejor con 6x32GB nodos en lugar de 3x64GB
• No habrá una diferencia notable entre los distintos tipos de RAM o velocidades.
• Linux (garantiza el mayor y más eficiente uso de la RAM):
  • Tener configurados entre 5 y 10 GB de espacio de intercambio. Aunque ciertamente no esperamos usarlo, también queremos un poco de red de seguridad de la Linux OOM killer
  • Desactive las THP (páginas transparentes enormes, a veces conocidas como páginas hyge anónimas). Aunque pueden ser beneficiosas en algunos casos, hemos visto problemas en nuestros clientes con ellas activadas (consulta tu sistema operativo y versión concretos para obtener instrucciones sobre cómo desactivar THP).
  • Poner la intercambiabilidad a 0
  • Pruebas recientes sugieren que desactivar Zone Reclaim en sistemas NUMA puede ser beneficioso (http://engineering.linkedin.com/performance/optimizing-linux-memory-management-low-latency-high-throughput-databases).

"Colocación"

Muchas veces nos preguntan si es correcto ejecutar Couchbase en los mismos servidores que la aplicación. Aunque no hay ninguna limitación técnica para hacerlo, no sería nuestra mejor recomendación por varias razones:

• Los cálculos de tamaño se complican si se tienen en cuenta los requisitos de otras tecnologías.
• La mayoría de las otras aplicaciones en realidad tienen diferentes requisitos de hardware / tamaño que Couchbase y por lo tanto la capacidad de asignar recursos donde importan es un beneficio de dividirlos.
• El escalado se vuelve más complejo. Imagina una granja de aplicaciones de 3 nodos con 3 nodos de Couchbase corriendo en los mismos servidores. Ahora quieres escalar la aplicación pero no necesitas escalar Couchbase con ella. ¿Tienes 5 servidores de aplicaciones, de los cuales sólo 3 tienen Couchbase corriendo?
• La administración es más difícil. El mismo entorno que el anterior... ahora necesitas reiniciar tu nivel de aplicación, pero no quieres que Couchbase se caiga con él.

¿Movilidad virtual o no?

No es ningún secreto que el hardware físico le dará el mejor rendimiento y el uso más eficiente de los recursos. Sin embargo, una gran parte de los clientes de Couchbase están utilizando VMs y es un despliegue que probamos y apoyamos. Algunas cosas a tener en cuenta:

• Trata a Couchbase con respeto... no sobrecargues la máquina anfitriona con otras aplicaciones. Sobrecomprometer CPU y RAM especialmente puede llevar a resultados muy inesperados (y difíciles de diagnosticar). Algo de esto puede ser controlado con ajustes reales en el host vm (como para RAM) y algo de esto es sólo una buena práctica (como no asignar más CPUs virtuales que núcleos físicos).
• La red va a ser un poco más lenta con las máquinas virtuales... quizás no se note, pero hay un efecto.
• Los mismos requisitos numéricos se aplican a la CPU y la RAM
• El almacenamiento local es mejor que volver a una SAN compartida por las mismas razones anteriores para un entorno distribuido.
• Nuestro consejo general de más nodos en lugar de menos es aún más fuerte con las máquinas virtuales
• Asegúrate de no tener más de un nodo Couchbase por máquina física
• Puedes sacrificar algo de lo anterior para entornos que no sean de producción, pero ten en cuenta que puedes encontrarte con problemas de rendimiento o estabilidad. Si planeas tener los mismos conjuntos de datos de producción y las mismas cargas de trabajo en pruebas, UAT y/o staging, también vas a tener los mismos requisitos de recursos en esos entornos.
• No parece haber diferencia entre la elección de tecnologías de virtualización

En las nubes...

En este contexto, una "nube" es un entorno de despliegue en el que el hardware está realmente desacoplado del software para cada componente y, en mi opinión, es diferente de la mera ejecución en máquinas virtuales. Alrededor de 50% de nuestros clientes están desplegados en Amazon. Un puñado más está en algún otro proveedor de nube como GAE/Rackspace/Softlayer/Savvis/etc y un puñado está ejecutando su propia nube privada. Siguiendo con el tema del principio, no estoy en posición de decirte en qué infraestructura debes desplegar Couchbase... tú me lo dirás.

Muchas/todas las mismas consideraciones se aplican a las nubes como lo hacen a las máquinas virtuales y tenemos alguna documentación más específica sobre consideraciones sobre la nube.

• RAM: Normalmente se dispone de menos RAM por nodo
• Disco: Una sola unidad EBS es (potencialmente inconsistente) lenta. Recomendamos un LVM/striped-RAID de 4-6 unidades por nodo para obtener el mejor rendimiento y unidades EBS IOPS optimizadas/provisionadas. EC2 también proporciona instancias basadas en SSD que, aunque muy costosas en este momento, serían la mejor opción para el rendimiento. Tenga en cuenta que también tiene la posibilidad de "elegir" los tipos de disco para su directorio de instalación, directorio de archivos de datos y directorio de vista/índice.
• Distribución de datos: De nuevo, planifica el uso de más nodos en lugar de menos.
• Zonas de disponibilidad: Aunque todavía no hacemos nada especial para desplegar Couchbase a través de racks o zonas (está en camino), sigue siendo una buena idea dividir tu cluster a través de zonas. De esta manera, el fallo de una zona no hará que todo tu conjunto de datos no esté disponible. Usar XDCR entre zonas puede ser una buena consideración para proporcionar una resistencia añadida.

"Ampliar" frente a "Reducir".

La elasticidad de Couchbase a través del reequilibrio permite no sólo el mantenimiento y la actualización sin problemas del software, sino también del hardware. Añadiendo nuevos nodos de mayor capacidad e intercambiándolos con los nodos más antiguos de menor capacidad, puedes conseguir escalabilidad vertical... todo ello sin pérdida de rendimiento o disponibilidad de datos para una aplicación en ejecución.

Saber cuándo aumentar la capacidad de sus nodos va a depender de su propio caso de uso, de la disponibilidad de recursos y de las variables de coste subyacentes. En un extremo, no recomendaríamos 1, 2 o 3 nodos de hardware muy potente... ni tampoco 1000 nodos muy pequeños. Algunas reglas generales son:

1. Escala fuera con el menor tamaño de nodo posible hasta unos 15-20 nodos, y luego considere escalado arriba para reducir el número de nodos
2. Cuando aumente la escala, no elija hardware que reduzca el número de nodos por debajo de 6... enjuague y repita #1 arriba.
3. Si tu carga de trabajo está ligada a la memoria, ten cuidado al reducir el número de nodos con respecto al rendimiento de disco que tienes... cuanta más RAM tenga cada nodo, más IO de disco necesitará cada nodo tanto para la carga de trabajo en estado estacionario, como para la compactación y especialmente para el reequilibrio, etc.
4. Si su carga de trabajo está vinculada al disco, es mejor tener más nodos para distribuir la carga de trabajo en lugar de aumentar gradualmente el rendimiento del disco de cada nodo.

Un buen ejemplo de ello es un cliente reciente cuyo tamaño requería 32 nodos de discos giratorios debido a una gran carga de trabajo de escritura. Gracias a las unidades SSD, pudieron reducir el número de nodos a 9, lo que encajaba perfectamente en los modelos #1 y #2 anteriores y compensaba fácilmente el coste de las unidades SSD.

En resumen

Para empezar, tus requisitos mínimos de hardware deberían ser más o menos los siguientes:

• 3 nodos
• 4 GB O MÁS DE RAM
• 4 núcleos de CPU (+1 por cubo, +1 por documento de diseño, +1 por flujo XDCR, +1 por trabajador lector/escritor más allá del valor predeterminado de 3)
• El mejor almacenamiento "local" de que disponga
• La red de menor latencia y mayor rendimiento de que disponga

Al fin y al cabo, tu arquitectura global estará mucho mejor servida teniendo más nodos de menor capacidad/potencia que teniendo menos nodos de mucha mayor potencia (y coste).

Y recuerde, en caso de duda, el equipo de campo de Couchbase está a su disposición para evaluar su entorno y proporcionar orientación sobre sus necesidades específicas. Queremos asegurarnos de que tengas la mejor experiencia posible con el producto.

En el siguiente y cuarta entrada de esta serie, hablaré de las distintas métricas y prácticas de monitorización para entender el dimensionamiento adecuado de un cluster de Couchbase Server.