Quand je fais un audit ou que je reprends un environnement Nutanix existant, il y a une situation que je rencontre beaucoup plus souvent que ce que je devrais autour des optimisations de stockage.
Pas parce que Nutanix ne fonctionne pas.
Mais parce que les options ont été activées sans réellement comprendre ce que fait déjà le stockage nativement.
Très souvent, le raisonnement est simple : « on a la licence, donc autant tout activer ». Déduplication, compression inline, parfois post-process, erasure coding, et on empile les options en espérant que la réduction de capacité suive. Dans la réalité, on obtient surtout une configuration difficile à expliquer, exploiter, des gains modestes, et parfois des comportements inattendus.
Le premier point qui revient presque systématiquement, c’est la déduplication.
La déduplication est souvent activée par réflexe, notamment sur des containers qui hébergent des serveurs applicatifs, des bases de données, et parfois même des environnements VDI en linked clone. Dans beaucoup de cas, ce choix ne repose pas sur un besoin réel, mais sur une méconnaissance du fonctionnement natif du stockage AOS, en particulier pour les snapshots et les clones.
Sur Nutanix, les snapshots et les clones ne reposent pas sur un mécanisme de déduplication post-process classique. AOS utilise un modèle de redirect-on-write basé sur les métadonnées. Un vDisk est composé de vBlocks, eux-mêmes référencés dans une block map. Lorsqu’un snapshot ou un clone est créé, le vDisk de base est marqué immutable et un nouveau vDisk est créé en lecture/écriture. Les deux partagent exactement la même block map au départ.
Il n’y a aucune copie de données, aucune écriture, aucun calcul de fingerprint. Tout se fait au niveau des métadonnées. Chaque vDisk possède sa propre block map, ce qui évite les traversées de chaînes de snapshots et les pénalités de lecture que l’on connaît sur d’autres architectures. C’est aussi ce qui permet de créer des snapshots en continu ou des clones en cascade sans impact mesurable sur les performances.
Quand un clone écrit de nouvelles données, ces écritures sont simplement ajoutées à sa propre block map. Les blocs existants restent partagés. Autrement dit, la mutualisation est déjà maximale par design.
Dans ce contexte, activer la déduplication sur des environnements de clones, de linked clones ou de VAAI clones n’apporte rien. Le gain est déjà là, sans traitement post-process, sans scan de blocs, sans consommation supplémentaire de métadonnées. On ajoute simplement une couche de complexité inutile.
La déduplication garde évidemment tout son intérêt dans d’autres scénarios : P2V, full clones, postes persistants, ou ensembles de données réellement redondantes dans le temps. Mais sur les snapshots et les clones, AOS n’a tout simplement pas besoin de ce mécanisme.
La compression est un autre sujet récurrent, mais à la différence de la déduplication, la compression inline est généralement un bon choix. Ce n’est pas un hasard si Nutanix l’active par défaut sur les nouveaux containers : elle correspond au plus large éventail de workloads rencontrés en entreprise.
Ce choix par défaut est pertinent dans la majorité des cas. La compression inline permet de réduire la quantité de données écrites et lues, ce qui diminue la pression sur le stockage et le réseau. Sur des environnements limités par l’I/O plutôt que par le CPU, ce gain peut compenser, voire dépasser, le coût de compression et améliorer les performances perçues. Pour la majorité des workloads généralistes, c’est un choix évident.
Les limites apparaissent uniquement sur des cas très spécifiques, comme certaines applications transactionnelles ou bases de données particulièrement sensibles à la latence CPU. Ces situations existent, mais elles restent minoritaires.
Dans ces cas-là, la compression post-process est souvent plus adaptée. Elle est encore trop peu utilisée alors qu’elle fonctionne très bien pour des données peu modifiées dans le temps (file servers, profils utilisateurs, vDisks majoritairement en lecture) grâce à un délai configurable qui évite tout impact sur les écritures.
En pratique, la compression inline est un excellent point de départ et restera le bon choix dans la plupart des environnements. Le problème n’est pas ce choix par défaut, mais le fait de ne plus jamais le remettre en question quand le workload sort du cadre général.
L’erasure coding est sans doute l’option la plus mal comprise. Les gains de capacité sont bien réels, mais son cadre d’utilisation est clairement défini. Nutanix le recommande principalement pour les workloads de type Files et Object Storage, ainsi que dans des environnements configurés en RF3 lorsque la réduction de l’empreinte de stockage devient un objectif réel et justifié.
En fonctionnement nominal, l’erasure coding n’a pas d’impact sur les performances de lecture ou d’écriture. En revanche, il n’est pas adapté aux workloads fortement orientés écriture ou réécriture, et il introduit une complexité supplémentaire, notamment lors des phases de reconstruction après une défaillance. Malgré cela, je l’ai vu activé “pour tester”, ou simplement parce que “ça fait gagner de la place”, sans besoin clairement identifié.
Je l’ai même rencontré sur des clusters disposant de larges marges de capacité. C’est un point essentiel à garder en tête : les optimisations de stockage ne sont jamais gratuites. Si la capacité n’est pas un problème, convertir du CPU, de la RAM et de la complexité opérationnelle en quelques gigaoctets économisés n’apporte pas de valeur.
À force d’empiler ce type de choix, on arrive souvent à une autre dérive : la multiplication des containers. Un container par combinaison de paramètres (compression, RF, chiffrement) jusqu’à obtenir une plateforme fragmentée, difficile à maintenir, et dont les règles ne sont comprises que par ceux qui l’ont initialement conçue.
Aujourd’hui, ce modèle n’est plus nécessaire.
Avec les versions récentes de Prism Central, la logique a clairement évolué vers une gestion par stratégie, et non plus par containers. Les Storage Policies permettent de définir le Replication Factor, le type de compression, le chiffrement ou encore la QoS, et de les appliquer via des catégories directement aux VMs ou aux Volume Groups.
On réduit drastiquement le nombre de containers, on rend les règles explicites, visibles, et surtout cohérentes. On arrête d’adapter l’infrastructure aux workloads, et on adapte les workloads à des stratégie claires.
Après plusieurs projets de redesign ou de remise à plat, mon constat est assez simple. Le problème n’est jamais le manque de fonctionnalités. Le problème, c’est l’idée qu’une option activée est forcément une bonne option.
Les optimisations de stockage doivent être choisies, ciblées et comprises. .Aujourd’hui, une approche basée sur moins de containers et des Storage Policies bien définies est, dans la majorité des cas que j’ai rencontrés, la solution la plus propre, la plus lisible et la plus efficace.
