La donnée et ses chemins I/O chez Nutanix

Ils se décomposent de la manière suivante :

1. Le « OpLog »
2. L’« Extent Store »
3. Le « Content Cache

1 – Le « Oplog »

Le « Oplog » est un Buffer persistant en écriture,  qui traite les requêtes en mode rafale, de manière à les fusionner et à les transférer en mode asynchrone dans le stockage persistant « Extent Store ». Tous les « OpLogs » du cluster participent au RF (réplication facteur x2, bientôt x3 avec la version 4 du Nutanix OS). Ils sont choisis dynamiquement en fonction de la charge des nœuds du cluster. Le « OpLog » d’un CVM est hébergé dans le disque local SSD du nœud du CVM en question, de manière à fournir des performances I/O en écriture optimales, notamment pour les charges I/O aléatoires. Pour les traitements séquentiels, le « OpLog » est n’est pas utilisé, les données en écriture sont stockées directement dans le stockage persistant « Extent Store ».

Lorsqu’une donnée en écriture (en vert) est écrite dans le « OpLog » du nœud1 (1a) Write I/O), elle est répliquée en mode synchrone (RF x2) dans le « OpLog » du noeud2 (1b) Replicate)  avant d’être acquittée (1c) Ack). On s’assure ainsi que la donnée (en vert) est bien stockée dans le « OpLog » du nœud2. Tant que la donnée (en vert) est en cours de traitement, donc sollicitée (donnée chaude) dans le « OpLog », les demandes en lecture sur cette donnée seront directement traitées à partir du « OpLog » pour être transférée dans le pool « Single-Touch » du « Content Cache ». Lorsqu’elle ne sera plus sollicitée (donnée froide), elle sera transférée en mode asynchrone (2) Coalesce and Async Drain) dans le stockage permanent « Extent Store ».

2 – L' « Extent Store »

C’est un espace de stockage persistant de NDFS qui couvre les disques locaux SSD et HDD du nœud. Il est extensible pour faciliter l’implémentation de nouveaux périphériques et traite les données qui proviennent (Drain) du « OpLog » ou les traitements séquentiels qui eux, ne transitent pas par le « OpLog ».

Nutanix ILM détermine de manière dynamique le meilleur palier des patterns I/O pour déplacer les données au meilleur endroit du stockage.

3 – Le « Content Cache »

Le « Content Cache » est un cache dynamique en lecture. Il couvre à la fois la mémoire du CVM et le disque SSD du nœud de ce CVM. Si une requête en lecture est demandée sur une donnée qui ne se trouve pas dans ce cache, cette dernière sera automatiquement placée dans le pool « Single-Touch » du « Content Cache » qui se trouve dans la mémoire du CVM, et qui est géré par l’algorithme « LRU » (Least Recently Used, algorithme de remplacement des lignes de cache). La prochaine requête en lecture va déplacer la donnée dans le pool « Multi-Touch » du « Content Cache » qui se trouve localisé à la fois dans la mémoire et dans la SSD (deux sous-segments). Dans le pool « Multi-Touch », il faut deux cycles LRU pour déplacer la donnée de la mémoire vers la SSD (la donnée n’est pas vraiment déplacée, on mesure son empreinte pour la mettre dans les métadonnées du cache, c’est la déduplication) et on affecte un nouveau compteur LRU. Toutes les autres requêtes en lecture sur la donnée dans le pool « Multi-Touch » feront en sorte de remonter la donnée au sommet du pool (donc de la SSD vers la mémoire) et un nouveau compteur LRU est affecté (ça permet d’optimiser les temps I/O sur la donnée, considérée comme « chaude »). La déduplication (mesure de l’empreinte de la donnée pour la gestion des métadonnées) se configure au niveau du « Container » via l’interface utilisateur. Par défaut, elle est activée.

Regarder la vidéo de Steven POITRAS pour mieux comprendre...