Exécuter Apache Cassandra sur des machines virtuelles Azure
Attention
Cet article fait référence à CentOS, une distribution Linux proche de l’état de fin de service (EOL). Faites le point sur votre utilisation et organisez-vous en conséquence. Pour plus d’informations, consultez les conseils d’aide relatifs à la fin de vie de CentOS.
Cet article décrit les considérations relatives aux performances pour l’exécution d’Apache Cassandra sur les machines virtuelles Azure.
Ces recommandations reposent sur les résultats des tests de performances disponibles sur GitHub. Vous devez les utiliser comme base de référence avant de procéder à un test avec votre propre charge de travail.
Azure Managed Instance pour Apache Cassandra
Si vous recherchez un service plus automatisé pour l’exécution d’Apache Cassandra sur les machines virtuelles Azure, envisagez d’utiliser Azure Managed Instance pour Apache Cassandra. Ce service automatise le déploiement, la gestion (mise à jour corrective et intégrité du nœud) et la mise à l’échelle des nœuds au sein d’un cluster Apache Cassandra. Il offre également la possibilité d’utiliser des clusters hybrides, de sorte que les centres de données Apache Cassandra déployés dans Azure peuvent rejoindre un anneau Cassandra hébergé sur site ou tiers. Le service est déployé à l’aide d’Azure Virtual Machine Scale Sets. Les recommandations suivantes ont été adoptées lors du développement de ce service.
Types de disques et tailles de machines virtuelles Azure
Les charges de travail Cassandra sur Azure utilisent généralement des machines virtuelles Standard_DS14_v2, Standard_DS13_v2, Standard_D16s_v5 ou Standard_E16s_v5. Les charges de travail Cassandra bénéficient d’une plus grande quantité de mémoire dans la VM. Il faut donc envisager des tailles de machine virtuelle optimisées pour la mémoire, telles que Standard_DS14_v2 ou Standard_E16s_v5, ou des tailles optimisées pour le stockage local, telles que Standard_L16s_v3.
Pour des raisons de durabilité, les données et les journaux de validation sont généralement stockés sur un agrégat par bandes de deux à quatre disques managés premium de 1 To (P30).
Les nœuds Cassandra ne doivent pas être trop chargés en données. Nous vous recommandons de ne pas dépasser 1 à 2 To de données par machine virtuelle et de prévoir suffisamment d’espace libre pour le compactage. Pour obtenir le débit combiné et le nombre d’IOPS les plus élevés possibles à l’aide de disques managés premium, nous vous recommandons de créer un agrégat par bandes à partir de plusieurs disques de 1 To plutôt que d’utiliser un seul disque de 2 ou 4 To. Par exemple, sur une machine virtuelle DS14_v2, quatre disques de 1 To présentent un nombre maximum d’IOPS de 4 × 5000 = 20 K, contre 7,5 K pour un seul disque de 4 To.
Évaluez Azure Ultra Disks pour les charges de travail Cassandra qui ont besoin d’une plus petite capacité de disque. Ils peuvent fournir des IOPS/throughput plus élevés et une latence plus faible sur des tailles de VM comme Standard_E16s_v5 et Standard_D16s_v5.
Pour les charges de travail Cassandra qui n’ont pas besoin d’un stockage durable, c’est-à-dire pour lesquelles les données peuvent être facilement reconstruites à partir d’un autre support de stockage, envisagez d’utiliser des machines virtuelles Standard_L16s_v3 ou Standard_L16s_v2. Ces tailles de machines virtuelles disposent de disques locaux temporaires NVM Express (NVMe) volumineux et rapides.
Pour plus d’informations, consultez Comparer les performances des disques Azure locaux/éphémères et des disques attachés/persistants (GitHub).
Mise en réseau accélérée
Les nœuds Cassandra font un usage intensif du réseau pour envoyer et recevoir les données de la machine virtuelle cliente et pour communiquer entre les nœuds à des fins de réplication. Pour des performances optimales, les machines virtuelles Cassandra ont besoin d’un réseau à haut débit et à faible latence.
Nous recommandons d’activer la mise en réseau accélérée sur la carte réseau du nœud Cassandra et sur les machines virtuelles exécutant des applications clientes qui accèdent à Cassandra.
Les performances réseau accélérées nécessitent une distribution Linux moderne avec les pilotes les plus récents, tels que Cent OS 7.5+ ou Ubuntu 16.x/18.x. Pour plus d’informations, consultez Créer une machine virtuelle Linux avec mise en réseau accélérée.
Mise en cache des disques de données des machines virtuelles Azure
Les charges de travail de lecture Cassandra sont plus performantes lorsque la latence des disques à accès aléatoire est faible. Nous vous recommandons d’utiliser des disques managés Azure sur lesquels la mise en cache ReadOnly est activée. La mise en cache ReadOnly offre une latence moyenne plus faible, car les données sont lues à partir du cache de l’hôte et non à partir du stockage principal.
Les charges de travail à lecture aléatoire nécessitant un grand nombre de lectures telles que Cassandra ont besoin d’une latence de lecture plus faible, même si le mode avec mise en cache présente des limites de débit inférieures à celles du mode sans mise en cache. (Par exemple, les machines virtuelles DS14_v2 ont un débit maximum de 512 Mo/s avec la mise en cache, contre 768 Mo/s sans la mise en cache).
La mise en cache ReadOnly est particulièrement utile pour les séries chronologiques Cassandra et autres charges de travail où le jeu de données de travail tient dans le cache de l’hôte et où les données ne sont pas constamment remplacées. Par exemple, DS14_v2 fournit une taille de cache de 512 Go, capable de stocker 50 % des données d’un nœud Cassandra avec une densité de données de 1 à 2 To.
L’activation de la mise en cache ReadOnly n’entraîne pas de baisse significative des performances en cas d’échec de la mise en cache ; le mode avec mise en cache est donc recommandé pour toutes les charges de travail, sauf pour celles qui nécessitent un grand nombre d’écritures.
Pour plus d’informations, consultez Comparer les configurations de mise en cache des disques de données des machines virtuelles Azure (GitHub).
Lecture anticipée Linux
Dans la plupart des distributions Linux de la Place de marché Azure, le paramètre par défaut de lecture anticipée des périphériques de traitement par blocs est de 4096 Ko. Les E/S de lecture de Cassandra sont généralement aléatoires et relativement petites. Par conséquent, l’utilisation d’une grande capacité de lecture anticipée puise inutilement dans le débit en lisant des parties de fichiers qui ne sont pas nécessaires.
Pour réduire les lectures anticipées inutiles, définissez le paramètre correspondant du périphérique de traitement par blocs Linux sur 8 Ko. (Consultez Paramètres de production recommandés dans la documentation DataStax).
Configurez une lecture anticipée de 8 Ko pour tous les périphériques de traitement par blocs de l’agrégat par bandes et sur le périphérique de groupe proprement dit (par exemple, /dev/md0).
Pour plus d’informations, consultez Comparer l’impact des paramètres de lecture anticipée des disques (GitHub).
Taille de bloc mdadm de la baie de disques
Lors de l’exécution de Cassandra sur Azure, un agrégat par bandes mdadm (RAID 0) de plusieurs disques de données est souvent créé pour augmenter le débit global des disques et le nombre d’IOPS afin de se rapprocher des limites de la machine virtuelle. La taille optimale de la bande de disque est un paramètre spécifique à l’application. Par exemple, pour les charges de travail OLTP SQL Server, la recommandation est de 64 Ko. Pour les charges de travail d’entreposage de données, la recommandation est de 256 Ko.
Nos tests n’ont révélé aucune différence significative entre les tailles de bloc de 64 K, 128 K et 256 K pour les charges de travail de lecture Cassandra. La taille de bloc de 128 K semble présenter un léger avantage, à peine perceptible. Par conséquent, nous vous recommandons ce qui suit :
Si vous utilisez déjà une taille de bloc de 64 K ou 256 K, il n’est pas nécessaire de reconstruire la baie de disques pour utiliser une taille de 128 K.
Pour une nouvelle configuration, il est judicieux d’utiliser 128 K dès le début.
Pour plus d’informations, consultez Mesurer l’impact des tailles de bloc mdadm sur les performances de Cassandra (GitHub).
Système de fichiers des journaux de validation
Les écritures Cassandra présentent de meilleures performances lorsque les journaux de validation se trouvent sur des disques à haut débit et à faible latence. Dans la configuration par défaut, Cassandra 3.x vide les données de la mémoire pour les transférer vers le fichier journal de validation toutes les 10 secondes environ et ne touche pas le disque à chaque écriture. Dans cette configuration, les performances d’écriture sont quasiment identiques lorsque le journal de validation se trouve sur des disques attachés premium ou sur des disques locaux/éphémères.
Les journaux de validation doivent être durables, afin qu’un nœud redémarré puisse reconstruire toutes les données qui ne figurent pas encore dans les fichiers de données à partir des journaux de validation vidés. Pour améliorer la durabilité, stockez les journaux de validation sur des disques managés premium et non sur le stockage local, qui peut être perdu en cas de migration de la machine virtuelle vers un autre hôte.
D’après nos tests, Cassandra sur CentOS 7.x peut présenter des performances d’écriture inférieures lorsque les journaux de validation se trouvent sur le système de fichiers xfs que lorsqu’ils se trouvent sur le système de fichiers ext4. L’activation de la compression des journaux de validation permet d’aligner les performances du système de fichiers xfs sur celles du système de fichiers ext4. Dans le cadre de nos tests, les systèmes de fichiers xfs compressés fonctionnent aussi bien que les systèmes de fichiers ext4 compressés et non compressés.
Pour plus d’informations, consultez Observations relatives aux systèmes de fichiers ext4 et xfs et aux journaux de validation compressés (GitHub).
Établir les performances de référence des machines virtuelles
Après avoir déployé les machines virtuelles pour l’anneau Cassandra, effectuez quelques tests synthétiques pour établir les performances de référence du réseau et des disques. Utilisez ces tests pour vérifier que les performances sont conformes aux attentes, en fonction de la taille des machines virtuelles.
Plus tard, lorsque vous exécuterez la charge de travail réelle, le fait de connaître les performances de référence facilite l’examen des goulots d’étranglement potentiels. Par exemple, le fait de connaître les performances de référence de la sortie réseau sur la machine virtuelle peut permettre d’éliminer le réseau comme cause du goulot d’étranglement.
Pour plus d’informations sur l’exécution des tests de performances, consultez Valider les performances de référence des machines virtuelles Azure (GitHub).
Taille du document
Les performances de lecture et d’écriture de Cassandra dépendent de la taille du document. Attendez-vous à une latence plus élevée et à une diminution du nombre d’opérations par seconde lors de la lecture ou de l’écriture de documents volumineux.
Pour plus d’informations, consultez Comparer les performances relatives de différentes tailles de documents Cassandra (GitHub).
Facteur de réplication
La plupart des charges de travail Cassandra utilisent un facteur de réplication de 3 lors de l’utilisation de disques premium attachés, et même de 5 lors de l’utilisation de disques locaux temporaires/éphémères. Le nombre de nœuds de l’anneau Cassandra doit être un multiple du facteur de réplication. Par exemple, un facteur de réplication de 3 implique un anneau de 3, 6, 9 ou 12 nœuds, contre 5, 10, 15 ou 20 nœuds pour un facteur de réplication de 5. Lorsque vous utilisez un facteur de réplication supérieur à 1 et un niveau de cohérence LOCAL_QUORUM, il est normal que les performances de lecture et d’écriture soient inférieures à celles de la même charge de travail exécutée avec un facteur de réplication de 1.
Pour plus d’informations, consultez Comparer les performances relatives de divers facteurs de réplication (GitHub).
Mise en cache de pages Linux
Quand le code Java de Cassandra lit des fichiers de données, il utilise les entrées/sorties normales des fichiers et bénéficie de la mise en cache de pages Linux. Après la première lecture de certaines parties du fichier, le contenu lu est stocké dans le cache de pages du système d’exploitation. L’accès en lecture ultérieur aux mêmes données est beaucoup plus rapide.
Ainsi, lors de l’exécution de tests de performances de lecture sur les mêmes données, la deuxième lecture et les suivantes semblent beaucoup plus rapides que la première qui doit accéder aux données sur le disque de données distant ou à partir du cache de l’hôte lorsque ReadOnly est activé. Pour obtenir des mesures de performances similaires lors des exécutions suivantes, videz le cache de pages Linux et redémarrez le service Cassandra pour effacer sa mémoire interne. Lorsque la mise en cache ReadOnly est activée, si les données se trouvent dans le cache de l’hôte, les lectures suivantes seront plus rapides même après avoir vidé le cache de pages du système d’exploitation et redémarré le service Cassandra.
Pour plus d’informations, consultez Observations relatives à l’utilisation par Cassandra de la mise en cache de pages Linux (GitHub).
Réplication multi-centres de données
Cassandra prend nativement en charge le concept de centres de données multiples, ce qui facilite la configuration d’un anneau Cassandra couvrant différentes régions Azure ou différentes zones de disponibilité au sein d’une même région.
Pour un déploiement multirégion, utilisez le peering Azure Global VNet afin de connecter les réseaux virtuels des différentes régions. Lorsque des machines virtuelles sont déployées dans la même région mais dans des zones de disponibilité distinctes, les machines virtuelles peuvent se trouver dans le même réseau virtuel.
Il est important de mesurer la latence aller-retour de référence entre les régions. La latence réseau entre les régions peut être 10 à 100 fois supérieure à la latence au sein d’une région. Attendez-vous à un décalage entre les données apparaissant dans la deuxième région lorsque la cohérence d’écriture LOCAL_QUORUM est utilisée, ou à une diminution significative des performances d’écriture lorsque EACH_QUORUM est utilisé.
Quand vous exécutez Apache Cassandra à grande échelle, en particulier dans un environnement englobant plusieurs contrôleurs de domaine, la réparation de nœuds devient difficile. Des outils tels que Reaper peuvent aider à coordonner les réparations à grande échelle (par exemple, sur tous les nœuds d’un centre de données, un centre de données à la fois, afin de limiter la charge sur l’ensemble du cluster). Cependant, les problèmes posés par la réparation de nœuds dans de grands clusters ne sont pas encore entièrement résolus, et cette réparation s’applique à tous les environnements, qu’ils soient locaux ou cloud.
Quand des nœuds sont ajoutés à une région secondaire, les performances ne sont pas mises à l’échelle de manière linéaire, car une partie de la bande passante et des ressources processeur/disque est consacrée à la réception et à l’envoi du trafic de réplication entre les régions.
Pour plus d’informations, consultez Mesurer l’impact de la réplication interrégionale dans des environnements à plusieurs contrôleurs de domaine (GitHub).
Configuration de transfert suggéré
Dans un anneau Cassandra multirégion, les charges de travail d’écriture du niveau de cohérence LOCAL_QUORUM peuvent perdre des données dans la région secondaire. Par défaut, le transfert suggéré par Cassandra est limité à un débit maximum relativement faible et à une durée de vie suggérée de trois heures. Pour les charges de travail nécessitant un grand nombre d’écritures, nous recommandons d’augmenter la limite de transfert suggéré et la fenêtre de suggestion pour veiller à ce que les indicateurs ne soient pas supprimés avant leur réplication.
Pour plus d’informations, consultez Observations relatives au transfert suggéré dans la réplication entre plusieurs régions (GitHub).
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- Arsen Vladimirskiy | Principal Customer Engineer
Autre contributeur :
- Theo van Kraay | Gestionnaire de programme senior
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
Pour plus d’informations sur ces résultats de performances, consultez Expériences de performances sur des machines virtuelles Cassandra sur Azure.
Pour plus d’informations sur les paramètres généraux de Cassandra, non spécifiques à Azure, consultez :