Ejecución de Apache Cassandra en máquinas virtuales de Azure

Precaución

En este artículo se hace referencia a CentOS, una distribución de Linux que alcanzó el final del soporte técnico. Tenga en cuenta su uso y planifique en consecuencia. Para obtener más información, consulte la guía de fin de soporte técnico de CentOS.

En este artículo se describen las consideraciones de rendimiento para ejecutar Apache Cassandra en máquinas virtuales de Azure.

Estas recomendaciones se basan en los resultados de las pruebas de rendimiento internas. Use estas recomendaciones como línea base y, a continuación, pruebe con su propia carga de trabajo.

Azure Instancia administrada para Apache Cassandra

Si busca un servicio más automatizado para ejecutar Apache Cassandra en máquinas virtuales de Azure, considere la posibilidad de usar Azure Instancia administrada for Apache Cassandra. Este servicio automatiza la implementación, la administración (actualización de parches y salud de los nodos) y el escalado de nodos dentro de un clúster de Apache Cassandra. También proporciona la funcionalidad para clústeres híbridos, por lo que los centros de datos de Apache Cassandra implementados en Azure pueden unirse a un anillo existente de Cassandra de terceros u hospedado en el entorno local. El servicio se implementa mediante Azure Virtual Machine Scale Sets. Las siguientes recomendaciones se adoptaron durante el desarrollo de este servicio.

Tipos de disco y tamaños de máquina virtual de Azure

En el caso de las cargas de trabajo de Cassandra en Azure, evalúe los tamaños de máquina virtual actuales, como Standard_D16s_v6 o Standard_E16s_v6. Las cargas de trabajo de Cassandra se benefician de tener más memoria en la máquina virtual, por lo que considere los tamaños de máquina virtual optimizados para memoria , como Standard_E16s_v6 o tamaños optimizados para almacenamiento local , como Standard_L16s_v3.

Para la durabilidad, los datos y los registros de confirmación se almacenan normalmente en un conjunto de franjas de dos a cuatro SSD Premium de 1 TB (P30).

Los nodos de Cassandra no deben tener demasiados datos. Se recomienda tener como máximo de 1 a 2 TB de datos por máquina virtual y suficiente espacio libre para la compactación. Para aumentar el rendimiento combinado e IOPS mediante SSD Premium, se recomienda crear un conjunto distribuido a partir de unos pocos discos de 1 TiB, en lugar de usar un único disco de 2 TiB o 4 TiB. Por ejemplo, en una máquina virtual Standard_E16s_v6, cuatro discos P30 proporcionan 20 000 IOPS combinadas en el rendimiento aprovisionado de línea base, frente a 7500 IOPS para un único disco P50. Mantenga el conjunto de franjas dentro de los límites sin caché de la máquina virtual de 25 600 IOPS SSD Premium y 848 MBps.

Evalúe Azure Ultra Disks para las cargas de trabajo de Cassandra que necesiten menor capacidad de disco. Pueden proporcionar una mayor IOPS/rendimiento y una menor latencia en tamaños de máquina virtual, como Standard_E16s_v6 y Standard_D16s_v6.

En el caso de cargas de trabajo de Cassandra que no necesiten almacenamiento duradero, es decir, cuando los datos se puedan reconstruir fácilmente desde otro medio de almacenamiento, tenga en cuenta la posibilidad de usar las máquinas virtuales Standard_L16s_v3 o Standard_L16s_v2. Estos tamaños de máquinas virtuales (VMs) tienen discos de NVM temporales de gran tamaño y rápidos.

Redes aceleradas

Los nodos de Cassandra hacen un uso intensivo de la red para enviar y recibir datos de la máquina virtual cliente y para comunicarse entre los nodos para la replicación. Para obtener un rendimiento óptimo, las máquinas virtuales de Cassandra se benefician de la red de baja latencia y alto rendimiento.

Se recomienda habilitar redes aceleradas en la NIC del nodo de Cassandra y en las máquinas virtuales que ejecutan aplicaciones cliente que tienen acceso a Cassandra.

Las redes aceleradas requieren una distribución de Linux compatible con los controladores más recientes. Para obtener más información, consulte Creación de una máquina virtual Linux con redes aceleradas.

Almacenamiento en caché del disco de datos de la máquina virtual de Azure

Las cargas de trabajo de lectura de Cassandra funcionan mejor cuando la latencia de disco de acceso aleatorio es baja. En el caso de los discos de datos SSD Premium menores de 4 TiB en tamaños de máquina virtual que admiten el almacenamiento en caché del host, evalúe el almacenamiento en caché de ReadOnly . Los aciertos en caché reducen la latencia de lectura porque los datos se leen de la memoria caché en el host en lugar de ir al almacenamiento back-end.

Las cargas de trabajo de lectura aleatoria y intensiva, como Cassandra, pueden beneficiarse de una menor latencia de lectura. Compruebe los límites de IOPS y de rendimiento almacenados en caché y sin almacenar en caché del tamaño de máquina virtual seleccionado.

El almacenamiento en caché de solo lectura es especialmente útil para las series temporales de Cassandra y otras cargas de trabajo donde el conjunto de datos en uso encaja en la caché del servidor y los datos no se sobrescriben constantemente. Compruebe la capacidad de caché de host disponible para el tamaño de máquina virtual seleccionado.

Pruebe la carga de trabajo con y sin el almacenamiento en caché de ReadOnly antes de habilitarla en producción. Los discos Ultra y SSD Premium v2 no admiten el almacenamiento en caché del host. Para estos tipos de disco, use los límites de almacenamiento sin caché de la máquina virtual.

Lectura anticipada de Linux

En la mayoría de las distribuciones de Linux disponibles para Azure en Microsoft Marketplace, la configuración predeterminada de lectura anticipada del dispositivo de bloque es de 4096 KB. Los I/OS de lectura de Cassandra son por lo general aleatorios y relativamente pequeños. Por lo tanto, tener un gran volumen de lectura anticipada, se desperdicia rendimiento por leer partes de archivos que no son necesarios.

Para minimizar la búsqueda anticipada innecesaria, establezca la configuración de lectura anticipada del dispositivo de bloqueo de Linux en 8 kB. Consulte Configuración de producción recomendada en la documentación de DataStax.

Configure la lectura anticipada de 8 kB para todos los dispositivos de bloque del conjunto seccionado y en el propio dispositivo de matriz (por ejemplo, /dev/md0).

Tamaño de fragmento de mdadm de la matriz de discos

Al ejecutar Cassandra en Azure, es habitual crear un conjunto seccionado mdadm (es decir, RAID 0) de varios discos de datos para aumentar el rendimiento general del disco y que las IOPS estén más cerca de los límites de la máquina virtual. Un tamaño de franja de disco óptimo es una configuración específica de la aplicación. Por ejemplo, para las cargas de trabajo OLTP de SQL Server, la recomendación es 64 kB. En el caso de las cargas de trabajo de almacenamiento de datos, la recomendación es 256 kB.

En nuestras pruebas no encontramos ninguna diferencia significativa entre los tamaños de fragmento de 64 kB, 128 kB y 256 kB para las cargas de trabajo de lectura de Cassandra. Parece haber una ventaja pequeña, ligeramente perceptible, en el tamaño de fragmento de 128 kB. Por lo tanto, se recomiendan los siguientes enfoques:

  • Si ya usa un tamaño de fragmento de 64 o 256 KB, no tiene sentido volver a crear la matriz de discos para usar el tamaño de 128 KB.

  • En el caso de una nueva configuración, tiene sentidos usar 128 kB desde el principio.

Sistema de archivos del registro de confirmación

Las escrituras de Cassandra funcionan mejor cuando los registros de confirmación se encuentran en discos con un alto rendimiento y una baja latencia. En la configuración predeterminada, Cassandra 3.x vacía los datos de la memoria en el archivo de registro de confirmación cada ~10 segundos y no toca el disco en cada escritura. En esta configuración, el rendimiento de escritura es casi idéntico si el registro de confirmación está en discos conectados premium frente a discos locales o efímeros.

Los registros de confirmación deben ser duraderos, de modo que un nodo reiniciado pueda reconstruir los datos que aún no estén en los archivos de datos de los registros de confirmación vaciados. Para mejorar la durabilidad, almacene los registros de confirmación en ssd Premium y no en el almacenamiento local, lo que se puede perder si la máquina virtual se migra a otro host.

En función de nuestras pruebas, Cassandra en CentOS 7.x puede tener un rendimiento de escritura menor cuando los registros de confirmación están en el sistema de archivos xfs frente a ext4. Al activar la compresión del registro de confirmación, el rendimiento de XFS es igual que el de Ext4. Según nuestras pruebas, XFS comprimido funciona igual de bien que Ext4 comprimido y sin comprimir.

Medición del rendimiento de la máquina virtual de línea base

Después de implementar las máquinas virtuales para el anillo de Cassandra, ejecute algunas pruebas sintéticas para establecer el rendimiento de disco y red de línea base. Use estas pruebas para confirmar que el rendimiento va acorde con las expectativas, según el tamaño de máquina virtual.

Más adelante, cuando ejecute la carga de trabajo real, conocer la línea de base de rendimiento facilitará la investigación de posibles cuellos de botella. Por ejemplo, saber cuál es el rendimiento de línea de base de la salida de red en la máquina virtual puede ayudar a descartar que la red sea un cuello de botella.

Tamaño del documento

El rendimiento de lectura y escritura de Cassandra depende del tamaño del documento. Puede esperar ver mayor latencia y operaciones inferiores por segundo al leer o escribir con documentos de mayor tamaño.

Factor de replicación

La mayoría de las cargas de trabajo de Cassandra usan un factor de replicación (RF) de 3 cuando usan discos Premium conectados e incluso 5 cuando usan discos locales temporales o efímeros. El número de nodos del anillo de Cassandra debe ser un múltiplo del factor de replicación. Por ejemplo, RF 3 implica un anillo de 3, 6, 9 o 12 nodos, mientras que RF 5 tendría 5, 10, 15 o 20 nodos. Cuando se usa RF mayor que 1 y un nivel de coherencia de LOCAL_QUORUM, es normal que el rendimiento de lectura y escritura sea inferior a la misma carga de trabajo que se ejecuta con RF 1.

Almacenamiento en caché de páginas de Linux

Cuando el código Java de Cassandra lee archivos de datos, utiliza operaciones de E/S de archivos normales y se beneficia del almacenamiento en caché de páginas de Linux. Una vez que partes del archivo se leen una vez, el contenido de lectura se almacena en la memoria caché de la página del sistema operativo. El acceso de lectura subsiguiente a los mismos datos es mucho más rápido.

Por este motivo, al ejecutar pruebas de rendimiento de lectura con los mismos datos, las segundas y posteriores lecturas parecen ser mucho más rápidas que la lectura original, que era necesario para acceder a los datos en el disco de datos remoto o desde la memoria caché del host cuando ReadOnly está habilitado. Para obtener medidas de rendimiento similares en las ejecuciones posteriores, borre la memoria caché de la página de Linux y reinicie el servicio Cassandra para borrar su memoria interna. Cuando el almacenamiento en caché de ReadOnly está habilitado, los datos pueden estar en la caché del host y las lecturas posteriores son más rápidas incluso después de borrar la caché de páginas del sistema operativo y reiniciar el servicio Cassandra.

Replicación de varios centros de datos

Cassandra admite de forma nativa el concepto de varios centros de datos, lo que facilita la configuración de un anillo de Cassandra en varias regiones de Azure o a través de zonas de disponibilidad dentro de una región.

En el caso de una implementación de varias regiones, use Azure Global VNet-peering para conectar las redes virtuales en diferentes regiones. Cuando las máquinas virtuales se implementan en la misma región, pero en zonas de disponibilidad independientes, las máquinas virtuales pueden estar en la misma red virtual.

Es importante medir la latencia de ida y vuelta de la línea base entre las regiones. La latencia de red entre regiones puede ser de 10-100 veces superior a la latencia dentro de una región. Se espera que haya un intervalo entre los datos en la segunda región cuando usa la coherencia de escritura LOCAL_QUORUM, o que se reduzca significativamente el rendimiento de las escrituras cuando usa EACH_QUORUM.

Al ejecutar Apache Cassandra a gran escala y, en concreto, en un entorno con varios controladores de dominio, la reparación de nodos se convierte en un desafío. Herramientas como Reaper pueden ayudar a coordinar las reparaciones a gran escala (por ejemplo, en todos los nodos de un centro de datos, en un centro de datos cada vez, para limitar la carga en todo el clúster). Sin embargo, la reparación de nodos para clústeres de gran tamaño sigue siendo un desafío no resuelto y se aplica en todos los entornos, ya sea local o en la nube.

Cuando se agregan nodos a una región secundaria, el rendimiento no se escala linealmente, ya que algunos recursos de ancho de banda y de CPU/disco se dedican a recibir y enviar el tráfico de replicación entre regiones.

Configuración de la entrega sugerida

En un anillo de Cassandra de varias regiones, las cargas de trabajo de escritura con el nivel de coherencia LOCAL_QUORUM es posible que se pierdan datos en la región secundaria. De forma predeterminada, la entrega sugerida de Cassandra se limita a un rendimiento máximo relativamente bajo y una duración de la sugerencia de tres horas. En el caso de cargas de trabajo con una gran cantidad de operaciones de escritura, se recomienda aumentar la limitación de entrega de sugerencias y el tiempo en el que aparecen para garantizar que las sugerencias no se quitan antes de que se repliquen.

Colaboradores

Microsoft mantiene este artículo. Los siguientes colaboradores escribieron este artículo.

Autor principal:

Otro colaborador:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

Para más información sobre la configuración general de Cassandra, no específica de Azure, consulte:

  • Se actualizó por última vez el