PowerScale, Isilon OneFS : Tests des performances HBase sur Isilon (en anglais)

Introduction

Nous avons effectué une série de tests d’analyse comparative des performances sur un cluster Isilon X410 à l’aide de la suite d’analyses comparatives YCSB et de CDH 5.10.

L’environnement de laboratoire POC CAE a été configuré avec 5 nœuds Isilon x410 exécutant OneFS 8.0.0.4 et versions supérieures 8.0.1.1 NFS de streaming en mode bloc volumineux nous devrions nous attendre à 5 écritures ~700 Mo/s (3,5 Go/s) et 5 lectures ~1 Go/s (5 Go/s) pour nos maximums agrégés théoriques dans l’un de ces tests.

Les (9) nœuds de calcul sont des serveurs Dell PowerEdge FC630 exécutant CentOS 7.3.1611 chacun configuré avec 2 processeurs 18C/36T-Intel Xeon® E5-2697 v4 à 2,30 GHz avec 512 Go de RAM. Le stockage local est 2xSSD dans RAID 1 formaté en tant que XFS pour le système d’exploitation et les fichiers d’espace de travail/projection de liquide.

Trois serveurs edge supplémentaires ont également été utilisés pour générer la charge YCSB.

Le réseau back-end entre les nœuds de calcul et Isilon est de 10 Gbit/s avec trames Jumbo définies (MTU = 9162) pour les cartes réseau et les ports du commutateur.

Tests initiaux

La première série de tests visait à déterminer les paramètres pertinents du côté HBASE qui affectaient la sortie globale. Nous avons utilisé l’outil YCSB pour générer la charge pour HBASE. Ce test initial a été exécuté à l’aide d’un seul client (serveur Edge) à l’aide de la phase de charge de YCSB et de 40 millions de lignes. Ce tableau a été supprimé avant chaque exécution.
 

charge ycsb hbase10 -P workloads/workloada1 -p table='ycsb_40Mtable_nr' -p columnfamily=family -threads 256 -p recordcount=400000000

hbase.regionserver.maxlogs  : nombre maximal de fichiers WAL (Write-Ahead Log). Cette valeur multipliée par HDFS Block Size (dfs.blocksize) est la taille du WAL qui doit être rejouée lorsqu’un serveur se bloque. Cette valeur est inversement proportionnelle à la fréquence des vidages sur le disque.

hbase.wal.regiongrouping.numgroups  : lorsque vous utilisez plusieurs WAL HDFS comme WALProvider, définit le nombre de logs d’écriture anticipée que chaque RegionServer doit exécuter. Résultat : ce nombre de pipelines HDFS. Les écritures pour une région donnée ne sont transmises qu’à un seul pipeline, ce qui répartit la charge totale de RegionServer.

La philosophie ici était de paralléliser autant d’écritures que possible, ce qui permet d’augmenter le nombre de licences WAL, puis le nombre de threads (pipeline) par WAL. Les deux graphiques précédents montrent que pour un nombre donné pour « maxlogs » 128 ou 256, nous ne voyons aucun changement réel indiquant que nous n’enclenchons pas vraiment ce nombre du côté client. Oby varie le nombre de « pipelines » par fichier, bien que la tendance indique le paramètre sensible à la parallélisation. La question suivante est alors de savoir où Isilon « s’insérait » avec les E/S de disque, le réseau, le processeur ou OneFS, et nous pouvons examiner le rapport de statistiques Isilon.


 
Les graphiques du réseau et du processeur nous indiquent que le cluster Isilon est sous-utilisé et qu’il a de la place pour plus de travail. Le processeur serait > de 80 % et la bande passante réseau serait supérieure à 3 Go/s.



Ces tracés présentent les statistiques du protocole HDFS et la façon dont elles sont traduites par OneFS. Les opérations HDFS sont des multiples de dfs.blocksize, soit 256 Mo ici. Ce qui est intéressant ici, c’est que le graphique « Heat » présente les opérations de fichier OneFS et vous pouvez voir la corrélation entre les écritures et les verrous. Dans ce cas, HBase effectue des ajouts au WAL afin que OneFS verrouille le fichier WAL pour chaque écriture ajoutée. C’est ce que nous attendons des écritures stables sur un système de fichiers en cluster. Ils semblent contribuer au facteur limitatif de cet ensemble de tests.

Mises à jour HBase

Ce test suivant consistait à faire d’autres expériences pour trouver ce qui se passe à grande échelle. J’ai donc créé un tableau à un milliard de lignes, qui a pris une bonne heure pour générer, puis j’ai exécuté une exécution YCSB qui a mis à jour 10 millions de lignes à l’aide des paramètres « workloada » (50/50 en lecture/écriture). Cette opération a été exécutée sur un seul client et je recherchais également le débit le plus maximal que je puisse générer. Je l’ai donc exécuté en tant que fonction du nombre de threads YCSB. Autre remarque : nous avons effectué quelques réglages d’Isilon et sommes passés à OneFS 8.0.1.1, qui a des ajustements de performances pour le service de nœud de données. Vous pouvez voir la hausse des performances par rapport à l’ensemble d’exécutions précédent. Pour ces exécutions, nous définissons hbase.regionserver.maxlogs = 256 et hbase.wal.regiongrouping.numgroups = 20

Si vous examinez ces éléments, la première chose qui semble être la chute à un nombre élevé de threads est évidente. J’ai voulu savoir s’il s’agissait d’un problème Isilon ou d’un problème côté client. Nous voyons d’autres tests à ce sujet dans les paragraphes à venir. Mais je peux dire que le fait de générer plus de 200 000 opérations avec une latence de mise à jour de < 3 ms est impressionnant. Chacune de ces exécutions de mise à jour était rapide et je pourrais les exécuter l’une après l’autre. Le graphique ci-dessous montre l’équilibre pair entre les nœuds Isilon pour ces exécutions.



Encore une fois, vous pouvez voir à partir du graphique thermique que les opérations de fichier sont des écritures et des verrous correspondant à la nature d’ajout des processus WAL.

Mise à l’échelle du serveur régional

Le test suivant consistait à déterminer la façon dont les nœuds Isilon (cinq d’entre eux) seraient comparés à un nombre différent de serveurs régionaux. Le même script de mise à jour exécuté lors du test précédent a été exécuté ici. Un tableau à un milliard de lignes et 10 millions de lignes mis à jour à l’aide de « workloada » avec un seul client et threads YCSB à 51, nous avons également conservé le même paramètre sur les maxlogs et les pipelines (256 et 20 respectivement).

 
Les résultats sont informatifs, mais pas surprenants. La nature scale-out de HBase associée à la nature scale-out d’Isilon et more==better. Il s’agit d’un test que je recommanderais aux clients d’exécuter dans leurs environnements dans le cadre de leur propre exercice de dimensionnement. Il peut s’agir d’un point de réduction des retours, mais ici, nous avons neuf serveurs lourds qui poussent cinq nœuds Isilon et il semble qu’il y ait de la place pour plus.

Plus de clients

La dernière série de tests provient de cet endroit sombre profond qui vous donne envie de briser le système que vous testez. Après tout, il s’agit d’une méthode scientifique parfaitement valide pour tester jusqu’à ce que les choses se cassent et appellent en sachant quelle est la limite supérieure des paramètres testés. Dans cette série de tests, j’ai eu deux serveurs supplémentaires que je pourrais utiliser pour exécuter le client à partir de. En outre, j’ai exécuté deux clients YCSB sur chacun d’eux, ce qui me permet d’évoluer jusqu’à six clients chacun pour 512 threads, soit 4 096 threads au total. J’ai créé deux tableaux différents, un avec 4 milliards de lignes divisées en 600 régions et une avec 400 lignes en 90 régions.  

 



 

Comme vous pouvez le voir, la taille du tableau compte peu dans ce test. En examinant à nouveau les graphiques Thermiques Isilon, vous pouvez constater qu’il existe quelques différences en pourcentage dans le nombre d’opérations de fichiers principalement à la volée, avec les différences d’un tableau à quatre milliards de lignes à 400 millions de lignes.

Conclusion

HBase est un bon candidat pour l’exécution sur Isilon, principalement en raison des architectures scale-out vers scale-out. HBase effectue une grande partie de sa propre mise en cache et fractionne le tableau sur un grand nombre de régions où HBase peut évoluer avec vos données. En d’autres termes, il fait un bon travail pour répondre à ses propres besoins, et le système de fichiers est là pour la persistance. Nous n’avons pas pu repousser les tests de charge au point de rompre les choses, mais si vous envisagez quatre milliards de lignes dans votre conception HBase et que vous prévoyez 800 000 opérations avec moins de 3 ms de latence, cette architecture la prend en charge. Si vous remarquez que je n’en ai pas mentionné beaucoup plus sur la myriade d’autres ajustements côté client que vous pourriez appliquer à HBase lui-même, je m’attends à ce que tous ces ajustements restent valides, et au-delà du périmètre de ce test.