Compression et déduplication se cochent sur chaque conteneur, et la tentation est de tout activer. La documentation Nutanix et ses ingénieurs disent autre chose : la compression inline presque toujours, la déduplication presque jamais.
Où ça se règle
Les deux se règlent par conteneur de stockage. Selon Josh Odgers en 2016, elles se modifient à tout moment sans déplacer les VM ; à la désactivation, Curator décompresse ou réhydrate les données en tâche de fond. La compression inline est active par défaut sur tout nouveau conteneur. Les taux se lisent dans Prism, Storage > Dashboard.
Compression inline : le défaut, et la bonne réponse
L’inline compresse à l’écriture dans l’Extent Store les flux séquentiels et les E/S de plus de 64 Ko. Les écritures aléatoires entrent non compressées dans l’OpLog, y sont regroupées, puis compressées en mémoire avant d’être écrites dans l’Extent Store. D’où la recommandation de la Nutanix Bible : « Almost always use inline compression (compression delay = 0) », car elle n’affecte pas les performances en écriture aléatoire.
Les bénéfices annexes cités par la Bible :
- plus de données tiennent dans le tier SSD ;
- pour les écritures volumineuses ou séquentielles compressées en ligne, la réplication liée au facteur de réplication (RF) expédie des données compressées, donc moins d’octets sur le réseau ;
- l’erasure coding s’y ajoute et cumule les gains.
Côté mécanique : LZ4 pour les données courantes, LZ4HC pour les données froides, sans accès depuis 3 jours (1 jour pour les snapshots, immuables). En lecture, la décompression se fait en mémoire.
Compression post-process : un délai qui ne sert plus
En post-process, les données s’écrivent non compressées ; une fois le délai configuré écoulé, Curator les compresse sur tout le cluster, tâches réparties sur tous les nœuds et régulées par Chronos. La Bible tranche : puisque l’inline traite déjà en différé les E/S aléatoires ou petites, c’est elle qu’il faut utiliser.
La doctrine a changé. En 2014, sur le forum Nutanix, un employé déconseillait l’inline pour les bases de données et proposait au mieux la post-process avec un long délai. En 2022, un autre employé écrit que l’inline « works very well for almost any workloads ». Un conseil de forum se date avant de s’appliquer (voir aussi la latence disque dans une VM base de données).
Déduplication : un outil de niche
L’Elastic Dedupe Engine prend l’empreinte des données à l’ingestion, par blocs de 16 Ko dans une extent de 1 Mo, pour les E/S de 64 Ko ou plus, et la range dans les métadonnées ; Curator supprime ensuite les doublons. Les données lues montent dans l’Unified Cache, qui sert ensuite toute requête de même empreinte. Depuis AOS 6.6, les snapshots ne recopient plus les métadonnées de déduplication.
Les cas d’usage de la Bible : full clones VDI, bureaux persistants, P2V/V2V, Hyper-V ODX. Le point commun : des données qui ne viennent pas des clones AOS, déjà économes en espace. Astuce de la Bible : dédupliquer les images de base pour profiter de l’Unified Cache.
Quand l’éviter :
- Bases de données et fortes E/S. Un Staff SRE Nutanix, en 2022 : « Never use deduplication for SQL, Oracle or any other databases as well as any high I/O performance applications ». Chaque donnée dédupliquée ajoute une empreinte aux métadonnées.
- Par défaut. Sur le blog communautaire Nutanix, Josh Odgers dit en 2020 recommander en général de la laisser désactivée : compression, erasure coding, clones par métadonnées et suppression des zéros suffisent. Selon lui, de gros taux de déduplication affichés viennent souvent d’un reporting trompeur.
Ce qu’il faut retenir
- Laissez la compression inline (délai 0) sur tous les conteneurs : l’aléatoire est compressé en différé, sans pénalité.
- La compression post-process n’a plus de cas d’usage selon la Bible.
- La déduplication vise les données qui ne viennent pas de clones AOS : full clones VDI, bureaux persistants, P2V/V2V.
- Pas de déduplication pour les bases de données ni les applications à fortes E/S.
- Datez chaque conseil lu sur un forum : les recommandations de 2014 contredisent celles d’aujourd’hui.
In English
Inline compression can almost always stay enabled, post-process compression has little reason left to exist, and deduplication only pays off in a few specific cases. Mechanisms and selection rules: inline compression only compresses sequential writes or writes larger than 64 KB, deduplication fingerprints data in 16 KB blocks, and a Nutanix engineer rules it out for databases and I/O-heavy applications.
Sources & vérification
Relevé sur : Documentation publique Nutanix (Nutanix Bible, Nutanix Community) et blogs d'ingénieurs, relevé 2026-10
- Nutanix Bible, AOS Data Efficiency nutanixbible.com
- Nutanix Community, Use Cases of Compression, Deduplication and Erasure coding (2022) next.nutanix.com
- Nutanix Community, Storage Components (2020) next.nutanix.com
- Nutanix Community, When do you use Compression? (2014) next.nutanix.com
- Nutanix Community blog, Deduplication & Compression Comparison, Nutanix ADSF vs VMware vSAN, Part 2 (2020) next.nutanix.com
- joshodgers.com, Nutanix Implementation of Data Avoidance & Reduction Technologies (2016) joshodgers.com