Intégration de stockage flash sur le cluster

Les événements des dix derniers jours et le début de résolution aujourd'hui l'ont montré de manière assez franche. On posait la question d'acheter maintenant ou pas du flash pour le cluster (on en aura de toute façon besoin plus tard pour le stockage des BDD). Au final, je suis convaincu que même si l'emploi n'est pas nominal dès aujourd'hui, cela reste essentiel pour soutenir les solutions qu'on emploie, en stockage particulièrement, puisqu'on n'en maîtrise pas finement le comportement IO et qu'il faudra de temps en temps absorber la charge le temps d'optimiser.

Bref : il nous faut du flash, il en faut au moins sur chaque noeud qui héberge aujourd'hui du garage et sur chaque noeud qui hébergera demain des BDD. La question c'est combien et comment ? Je propose de poser ce qui est requis d'abord, en intégrant un schema qui offre de la souplesse.

Volumétries et répartition

On a besoin de deux types de stockage sur les noeuds : du rapide (plutôt basse latence en random que bon débit, même si ça ne fait pas de mal), et du standard (sur lequel on fait peu de random et on peut patienter quelques ms par accès). Résumé autrment : du SSD/NVMe et du rotatif. L'orientation est à placer sur du rapide les conteneurs, possiblement l'OS s'il n'est pas distinct, et les "métadonnées" (les tables de différentes bases, qu'il s'agisse de relationnel, des meta garage, etc.) ; et sur du standard les données objet, les blobs non structurés.

J'ai fait un bilan des volumétries actuelles et de ce qu'on peut raisonnablement projeter par noeud à 3-5 ans (hautement spéculatif, j'ai fait une grosse loi de Moore à 3 ans, soit peu ou prou x3). Pour le stockage distribué ou répliqué, je prends l'hypothèse de 1 standby sur postgres et 3 réplicas sur garage. Tout est projeté sur un cluster à 5 noeuds (on est à 3, 4 prévu, on aura probablement un 5è dans l'intervalle).

Le stockage objet mesuré est la somme des usages actuels qu'on imagine basculer brutalement sur du stockage objet (images 15Go, mastodon 500Go, matrix 600Go, owncloud 100Go, video 250Go, pixelfed 3Go, artifacts 125Go), c'est à dire 1.6To

Usage	Volumétrie actuelle	Volumétrie projetée	Brut par noeud, rapide	Brut par noeud, standard
Objets	1.6To	5To	100Go	3To
Bases relationnelles	650Go	2To	800Go	10Go (wal attendant archive)
Dépôts Git	10Go	30Go	1Go	30Go (aucune idée de comment on répliquera)
Mails	100Go	300Go	1Go	300Go (idem)
OS	20Go	60Go	60Go
Hepto	80Go	240Go	240Go
Total		6To	1To	3.5To

Cela prèche pour disposer au minimum d'un flash de 1To et un rotatif de 4To par noeud qu'on gérerait maintenant dans le cluster. Tout le monde ne sera pas à ce niveau-là immédiatement mais ce n'est pas un problème. Je propose qu'on fixe comme orientation court-moyen terme : mini 4To de stockage dont 500Go de flash, visant 1To de flash par noeud. Le plus simple pour l'implémenter reste de faire 1To SSD + 4To HDD. Lorsqu'on a plus sans effort on peut. Lorsque le packaging oblige à faire un seul support, on peut faire 4To SSD.

Intégration dans hepto

Un des enjeux reste que le stockage doit être accessible à hepto de manière gérable dans le temps. Jusqu'ici on montait le HDD (seule support dispo) dans /hdd dans hepto.

Avec le recul c'est assez mal informé. Le déplacement des metadata garage vers SSD en témoigne. kubernetes supporte assez mal les points de montage non homogènes dans un cluster, surtout quand on fait du hostPath dans un DaemonSet. En vérité c'est classique de beaucoup de technos donc il faut uniformiser ça. Pour monter les metadata garage, pour le moment on a surchargé le /hdd/garage/meta, puisque tout était monté dans /hdd initialement.

Il me semble qu'il faut distinguer le besoin de l'implémentation pour avoir un petit peu de souplesse. Ma proposition à ce stade :

• on stocke tout dans /mnt dans hepto, /mnt/data pour les données non structurées/indexées, et /mnt/meta pour les metadonnées indexées qui ont besoin de stockage rapide ;
• on laisse soin à l'hôte d'exposer des points de montage corrects et unifiés (avec LVM ou autre) et de les monter dans hepto
• en cas de HDD + SSD par exemple, on monte le HDD dans /mnt/data et le SSD dans /mnt/meta
• en cas de gros HDD mais pas encore de SSD, ou de gros SSD qui couvre tout, on le monde dans /mnt