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 ha llegado a su final de ciclo vida (EOL). Tenga en cuenta su uso y planifique en consecuencia. Para más información, consulte la Guía de fin de ciclo de vida 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, que puede encontrar en GitHub. Debe usar estas recomendaciones como base de referencia y, a continuación, realizar pruebas con su propia carga de trabajo.
Azure Managed Instance 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 Managed Instance for Apache Cassandra. Este servicio automatiza la implementación, la administración (aplicación de revisiones y estado del nodo) 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
Las cargas de trabajo de Cassandra en Azure usan normalmente las máquinas virtuales Standard_DS14_v2, Standard_DS13_v2, Standard_D16s_v5 o Standard_E16s_v5. Las cargas de trabajo de Cassandra presentan la ventaja de que tienen más memoria en la máquina virtual, por lo que tenga en cuenta los tamaños de máquina virtual optimizados para memoria, como Standard_DS14_v2 o Standard_E16s_v5, o los tamaños optimizados para almacenamiento como Standard_L16s_v3.
En cuanto a la durabilidad, los registros de datos y de confirmación se almacenan normalmente en un conjunto seccionado de dos a cuatro discos administrados premium de 1 TB (P30).
Los nodos de Cassandra no deben tener demasiados datos. Se recomienda tener como máximo 1 a 2 TB de datos por VM y suficiente espacio libre para la compactación. Para lograr la mejor combinación posible de rendimiento e IOPS con discos administrados premium, se recomienda crear un conjunto seccionado a partir de unos pocos discos de 1 TB, en lugar de usar un solo disco de 2 o 4 TB. Por ejemplo, en una VM DS14_v2, cuatro discos de 1 TB tienen una IOPS máxima de 4 × 5000 = 20 000, frente a los 7500 de un solo disco de 4 TB.
Evalúe Azure Ultra Disks para las cargas de trabajo de Cassandra que necesiten menor capacidad de disco. Pueden proporcionar más IOPS y rendimiento, y una menor latencia en los tamaños de máquina virtual como Standard_E16s_v5 y Standard_D16s_v5.
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áquina virtual tienen discos de NVM Express (NVMe) temporales de gran tamaño y rápidos.
Para obtener más información, consulte Comparación del rendimiento de los discos locales o efímeros frente a los discos adjuntos o persistentes de Azure (GitHub).
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 necesitan una distribución moderna de Linux con los controladores más recientes, como centOS 7.5 + o Ubuntu 16.x/18.x. 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. Se recomienda usar Azure Managed Disks con el almacenamiento en caché ReadOnly habilitado. El almacenamiento en caché ReadOnly (solo lectura) proporciona una latencia más baja, ya que los datos se leen de la memoria caché del host en lugar de ir al almacenamiento de back-end.
Las cargas de trabajo de lectura aleatoria de lectura intensivas como Cassandra, se benefician de una menor latencia de lectura, aunque el modo de almacenamiento en caché tiene menos límites de rendimiento que el modo sin almacenamiento en caché. (Por ejemplo, las máquinas virtuales DS14_v2 tienen un rendimiento máximo en caché de 512 MBps frente a las de no almacenamiento en caché, que es de 768 MBps).
El almacenamiento en caché ReadOnly es especialmente útil para la serie temporal de Cassandra y otras cargas de trabajo en las que el conjunto de datos operativo encaja en la memoria caché del host y no se sobrescriben datos constantemente. Por ejemplo, DS14_v2 proporciona un tamaño de caché de 512 GB, que podría almacenar hasta el 50 % de los datos de un nodo de Cassandra con una densidad de datos de 1-2 TB.
No hay ninguna penalización significativa en el rendimiento por los errores de caché cuando se habilita el almacenamiento en caché ReadOnly, por lo que se recomienda el modo de almacenamiento en caché para todas las cargas de trabajo, excepto para las más intensivas en cuanto a operaciones de escritura.
Para obtener más información, consulte Comparación de las configuraciones de almacenamiento en caché de los discos de datos de máquinas virtuales de Azure (GitHub).
Lectura anticipada de Linux
En la mayoría de las distribuciones de Linux de Azure Marketplace, la configuración de lectura anticipada de dispositivos bloqueados predeterminada es de 4096 kB. Las E/S de lectura de Cassandra suelen ser aleatorias y relativamente pequeñas. Por lo tanto, con un gran volumen de lectura anticipada, se desperdicia rendimiento por leer partes de archivos que no se necesitan.
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).
Para obtener más información, consulte Comparación del impacto de la configuración de lectura anticipada de disco (GitHub).
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 recomienda lo siguiente:
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.
Para obtener más información, consulte Medición del impacto de los tamaños de los fragmentos de mdadm en el rendimiento de Cassandra (GitHub).
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 obtener una mayor durabilidad, almacene los registros de confirmación en discos administrados premium y no en el almacenamiento local, ya 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, es posible que tenga menor rendimiento de escritura cuando los registros de confirmación se encuentran 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.
Para obtener más información, consulte Observaciones sobre los sistemas de archivos Ext4 y XFS y los registros de confirmación comprimidos (GitHub).
Medición del rendimiento de la máquina virtual de línea de base
Después de implementar las máquinas virtuales para el anillo de Cassandra, ejecute algunas pruebas sintéticas para establecer la red de línea de base y el rendimiento del disco. 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.
Para obtener más información sobre la ejecución de pruebas de rendimiento, vea Validación del rendimiento de máquinas virtuales de Azure de línea de base (GitHub).
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.
Para obtener más información, consulte Comparación del rendimiento relativo de varios tamaños de documento de Cassandra (GitHub).
Factor de replicación
La mayoría de las cargas de trabajo de Cassandra usan un factor de replicación (RF) de 3 al usar discos premium conectados e incluso 5 cuando se 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 menor que la misma carga de trabajo que se ejecuta con RF 1.
Para obtener más información, consulte Comparación del rendimiento relativo de varios factores de replicación (GitHub).
Almacenamiento en caché de páginas de Linux
Cuando el código Java de Cassandra lee archivos de datos, usa la E/S de archivos normal y las ventajas 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 esta razón, al ejecutar las pruebas de rendimiento de lectura con respecto a los mismos datos, las lecturas segundas y posteriores parecerá que son mucho más rápidas que la lectura original, que necesitaba acceder a los datos del disco de datos remoto o en la caché del host cuando se habilita ReadOnly. 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 se habilita el almacenamiento en caché ReadOnly, los datos pueden estar en la memoria caché del host y las lecturas posteriores serán más rápidas incluso después de borrar la memoria caché de la página del sistema operativo y reiniciar el servicio Cassandra.
Para obtener más información, consulte Observaciones sobre el uso de Cassandra del almacenamiento en caché de páginas de Linux (GitHub).
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 el emparejamiento de red virtual global de Azure para conectar las redes virtuales en las distintas 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 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 se usa la coherencia de escritura LOCAL_QUORUM, o que se reduzca significativamente el rendimiento de las escrituras cuando se 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). Por desgracia, la reparación de nodos de clústeres grandes es un escollo que todavía no se ha resuelto del todo y que se da en todos los entornos, ya sean locales 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.
Para obtener más información, consulte Medición del impacto de la replicación entre regiones de varios centros de datos (GitHub).
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 pueden perder 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.
Para obtener más información, consulte Observaciones sobre la entrega sugerida en la replicación entre regiones (GitHub).
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- Arsen Vladimirskiy | Ingeniero de clientes principal
Otro colaborador:
- Theo van Kraay | Gerente sénior de programas
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
Para obtener más información sobre estos resultados de rendimiento, consulte Cassandra en los experimentos de rendimiento de máquinas virtuales de Azure.
Para obtener información sobre la configuración general de Cassandra, no es específica de Azure, consulte los siguientes artículos: