Exécuter Apache Cassandra sur des machines virtuelles Azure

Attention

Cet article fait référence à CentOS, une distribution Linux qui a atteint la fin de la prise en charge. Faites le point sur votre utilisation et organisez-vous en conséquence. Pour plus d’informations, consultez les conseils de fin de support 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 sont basées sur les résultats des tests de performances internes. Utilisez ces recommandations comme base de référence, puis testez-les sur 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’Groupes de machines virtuelles identiques Azure. Les recommandations suivantes ont été adoptées lors du développement de ce service.

Types de disques et tailles de machines virtuelles Azure

Pour les charges de travail Cassandra sur Azure, évaluez les tailles de machine virtuelle actuelles telles que Standard_D16s_v6 ou Standard_E16s_v6. Les charges de travail Cassandra bénéficient de plus de mémoire dans la machine virtuelle. Envisagez donc des tailles de machine virtuelle optimisées pour la mémoire, telles que les Standard_E16s_v6, ou des tailles optimisées pour le stockage local, telles que les Standard_L16s_v3.

Pour garantir la durabilité, les données et les journaux de validation sont généralement stockés sur un ensemble RAID de deux à quatre SSD Premium (P30) de 1 To.

Les nœuds Cassandra ne doivent pas être trop chargés en données. Nous vous recommandons d’avoir au maximum 1 à 2 To de données par machine virtuelle et suffisamment d’espace libre pour le compactage. Pour augmenter le débit combiné et les IOPS à l’aide de disques SSD Premium, nous vous recommandons de créer un volume en bande à partir de quelques disques de 1 Tio, au lieu d’utiliser un seul disque de 2 Tio ou de 4 Tio. Par exemple, sur une machine virtuelle Standard_E16s_v6, quatre disques P30 fournissent un total de 20 000 IOPS à les performances provisionnées de base, contre 7 500 IOPS pour un seul disque P50. Veillez à ce que l'ensemble de bandes respecte les limites de performances sans mise en cache de la machine virtuelle, soit 25 600 IOPS pour les disques SSD Premium et 848 Mo/s.

Évaluez Azure Ultra Disks pour les charges de travail Cassandra qui ont besoin d’une plus petite capacité de disque. Ils peuvent fournir des E/S par seconde/débit plus élevés et une latence plus faible sur les tailles de machine virtuelle comme Standard_E16s_v6 et Standard_D16s_v6.

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.

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.

La mise en réseau accélérée nécessite une distribution Linux prise en charge avec les derniers pilotes. 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. Pour les disques de données SSD Premium inférieurs à 4 Tio sur les tailles de machine virtuelle qui prennent en charge la mise en cache de l’hôte, évaluez la mise en cache ReadOnly . Les accès réussis au cache réduisent la latence de lecture, car les données sont lues directement depuis le cache de l'hôte plutôt que depuis le stockage principal.

Les charges de travail de lecture intensive et aléatoire comme Cassandra peuvent bénéficier d’une latence de lecture inférieure. Vérifiez les limites d’E/S par seconde et de débit mises en cache et non mises en cache de la taille de machine virtuelle sélectionnée.

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. Vérifiez la capacité de cache hôte disponible pour la taille de machine virtuelle sélectionnée.

Testez votre charge de travail avec et sans mise en cache ReadOnly avant de l’activer en production. Les disques Ultra et SSD Premium v2 ne prennent pas en charge la mise en cache de l’hôte. Pour ces types de disques, utilisez les limites de stockage non mises en cache de la machine virtuelle.

Lecture anticipée Linux

Dans la plupart des distributions Linux disponibles pour Azure dans la Place de marché Microsoft, le paramètre par défaut de lecture anticipée des périphériques de blocs est de 4 096 Ko. Les E/S de lecture de Cassandra sont généralement aléatoires et relativement petites. Par conséquent, un grand préchargement gâche 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).

Taille des segments de la baie de disques mdadm

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 les approches suivantes :

  • 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.

Système de fichiers des journaux de validation

Les opérations d'écriture 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 une meilleure durabilité, stockez les journaux de validation sur les DISQUES SSD Premium et non sur le stockage local, ce qui peut être perdu si la machine virtuelle est migrée vers un autre hôte.

En fonction de nos tests, Cassandra sur CentOS 7.x peut avoir des performances d’écriture inférieures lorsque les journaux de validation se trouvent sur le système de fichiers xfs et ext4. L'activation de la compression du journal de validation aligne les performances de xfs sur celles d'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.

Mesurer les performances des machines virtuelles de référence

Après avoir déployé les machines virtuelles pour l’anneau Cassandra, exécutez quelques tests synthétiques pour établir des performances réseau et disque de référence. 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.

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.

Facteur de réplication

La plupart des charges de travail Cassandra utilisent un facteur de réplication (RF) de 3 lorsqu’elles utilisent des disques Premium attachés et même 5 lorsqu’elles utilisent des 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 RF supérieur à 1 et un niveau de cohérence de LOCAL_QUORUM, il est normal que les performances de lecture et d’écriture soient inférieures à la même charge de travail exécutée avec RF 1.

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.

Pour cette raison, lors de l’exécution de tests de performances de lecture sur les mêmes données, la seconde et les lectures suivantes semblent alors être beaucoup plus rapides que la lecture d’origine, qui a besoin d’accéder aux données sur le disque de données distant ou à partir du cache 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, les données peuvent se trouver dans le cache hôte et les lectures suivantes sont plus rapides, même après avoir supprimé le cache de page du système d’exploitation et redémarré le service Cassandra.

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 dans l'apparition des données dans la deuxième région lorsque vous utilisez la cohérence d'écriture LOCAL_QUORUM, ou à une diminution drastique des performances des écritures lorsque vous utilisez EACH_QUORUM.

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). Toutefois, la réparation des nœuds pour les clusters volumineux reste un défi non résolu et s’applique à tous les environnements, qu’ils soient locaux ou dans le 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.

Configuration de transfert suggéré

Dans un anneau Cassandra multirégion, les charges de travail d'écriture avec un niveau de cohérence LOCAL_QUORUM peuvent entraîner une perte de 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.

Contributeurs

Microsoft conserve cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

Autre contributeur :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Pour plus d’informations sur les paramètres Cassandra généraux, et non spécifiques à Azure, consultez :

  • Dernière mise à jour :