Cache de lecture SSD ou disque direct pour les lectures NAS multi-utilisateurs : quand la réutilisation partagée change-t-elle le vainqueur ?

Le cache de lecture SSD prend davantage de valeur dans un NAS multi-utilisateur lorsque différents clients demandent régulièrement les mêmes blocs fréquemment utilisés, après que ces blocs ne tiennent plus dans la RAM. L’accès direct au disque reste la meilleure référence lorsque les utilisateurs lisent principalement des données différentes, que la charge est séquentielle ou que le pool de disques durs répond déjà plus vite que le réseau client ne peut les exploiter.

La nouvelle variable de décision est la réutilisation partagée. Dix utilisateurs ne rendent pas automatiquement le cache utile : dix personnes lisant dix archives sans lien peuvent créer très peu d’ensemble de travail réutilisable, tandis que trois monteurs ouvrant régulièrement les mêmes ressources de projet peuvent transformer une seule copie en cache en de nombreuses lectures disque évitées. Mesurez le chevauchement, pas le nombre d’utilisateurs.

La réutilisation partagée doit survivre au cache RAM avant que le SSD soit pris en compte

Les lectures répétées passent normalement par la RAM avant d’atteindre un cache SSD. Sur ZFS, l’ARC est le cache de lecture principal et le L2ARC constitue le niveau secondaire sur SSD/NVMe. Un deuxième utilisateur ouvrant le même fichier peut sembler bénéficier d’une vitesse « SSD », alors que les données ne quittent jamais la mémoire. Un test multi-utilisateur à chaud doit donc déterminer quelle couche a servi la requête.

Klara Systems explique que le L2ARC stocke les blocs qui seraient autrement expulsés de l’ARC et qu’il est particulièrement utile lorsque l’ensemble de travail actif est plus grand que la RAM, mais suffisamment petit pour tenir dans la RAM et le L2ARC réunis. Son analyse de 2026 sur l’adéquation de l’ensemble de travail au L2ARC fournit le premier filtre pertinent : le cache SSD n’a d’importance qu’après que les défauts de cache mémoire ont généré de véritables lectures du stockage.

Si l’ARC ou le cache de pages du système d’exploitation fournit déjà un taux élevé de succès pour les données partagées, l’ajout d’un cache SSD peut simplement déplacer les copies vers un niveau plus lent tout en consommant de la mémoire pour les métadonnées du cache. Dans ce cas, l’accès direct au disque n’est même pas le véritable concurrent : la RAM a déjà gagné.

Plusieurs utilisateurs ne sont utiles que lorsque leurs ensembles fréquemment utilisés se chevauchent

L’accès multi-utilisateur modifie l’économie du cache lorsque les requêtes convergent vers des données communes : dossiers de projet partagés, paquets logiciels, modèles de machines virtuelles, miniatures, index, médias de référence ou répertoires d’équipe fréquemment consultés. Une seule copie sur SSD peut satisfaire les défauts de cache répétés de plusieurs clients, réduisant les recherches mécaniques et les files d’attente sur les disques durs pendant les périodes chargées.

Les recommandations plus générales de Klara en matière d’optimisation des performances décrivent l’ARC comme un équilibre entre récence et fréquence, et indiquent que les blocs réutilisés fréquemment se comportent différemment de ceux parcourus une seule fois. Le comportement du cache sensible à la fréquence est ici le mécanisme essentiel : la réutilisation partagée augmente la probabilité qu’un bloc promu par un utilisateur reste utile à un autre.

Le nombre d’utilisateurs sans chevauchement peut produire l’effet inverse. Si chaque membre du foyer ou chaque poste de travail lit un jeu de données distinct, l’ensemble de travail combiné augmente plus vite et peut provoquer une rotation excessive dans la RAM comme dans le cache SSD. Davantage d’utilisateurs réduit alors le taux de succès au lieu de l’améliorer. La question est « quelle quantité de données fréquemment utilisées est commune ? », et non « combien de clients sont connectés ? »

L’accès direct au disque gagne lorsque le débit séquentiel ou le réseau fixe la limite

La lecture de gros médias, la vérification de sauvegardes et l’analyse d’archives parcourues une seule fois sont souvent séquentielles et peuvent ne toucher chaque bloc qu’une seule fois. Un pool sain de plusieurs disques durs peut diffuser efficacement ce trafic, tandis que le cache bénéficie de très peu de réutilisation future. Si le réseau 2,5 GbE ou 1 GbE est déjà saturé, servir la même lecture depuis un SSD peut ne pas réduire le temps d’achèvement perçu par le client.

L’article sur l’optimisation du L2ARC indique également que le trafic de prélecture séquentielle n’est pas toujours promu vers le L2ARC et que le cache de lecture est inefficace pour les charges à dominante d’écriture ou les jeux de données beaucoup plus grands que la hiérarchie de cache. C’est pourquoi un test de cache ne doit pas se limiter à une deuxième copie d’un petit dossier avant de généraliser le résultat au streaming de plusieurs téraoctets.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

La rotation du cache peut donner l’impression que le niveau SSD travaille sans accélérer les utilisateurs

Un cache de lecture SSD doit être alimenté, indexé et géré. Si l’ensemble de travail combiné change continuellement, les blocs utiles peuvent être évincés avant qu’un autre utilisateur ne les réutilise. Le périphérique de cache peut afficher une activité élevée tandis que le pool de disques durs traite encore de nombreux défauts, raison pour laquelle l’utilisation du SSD ne constitue pas à elle seule une preuve de bénéfice.

Un fil de discussion de la communauté TrueNAS datant de 2025 décrit une charge NAS et Proxmox mixte dans laquelle les taux de succès de l’ARC étaient généralement élevés, mais chutaient fortement lors d’événements tels que le redémarrage de nombreuses machines virtuelles, tandis que le L2ARC absorbait une part significative des défauts. Ce cas de cache pour charge mixte constitue un exemple réel de fonctionnement, et non un taux de succès universel à viser.

Le cache perd de sa valeur lorsqu’il tourne continuellement, consomme de la RAM rare pour ses métadonnées ou coûte presque aussi cher que le placement du jeu de données connu comme fréquemment utilisé sur un volume SSD dédié. Un cache est un placement adaptatif ; un niveau SSD dédié est un placement explicite. Utilisez ce dernier lorsque la latence prévisible compte davantage que la promotion automatique.

Testez des ensembles de travail partagés, pas un seul client répétant l’accès à un seul dossier

Créez trois jeux de données : un ensemble fréquemment utilisé commun à tous les clients, un ensemble privé par client et un ensemble d’archives séquentielles. Exécutez le même programme d’accès d’abord sans cache SSD, puis avec. Enregistrez les succès du cache ARC et du cache de pages, les succès du cache SSD, les IOPS et la latence des disques durs, l’utilisation du réseau et le temps de réponse client au 95e percentile. Le cache doit réduire le travail du stockage pour l’ensemble commun, et pas seulement produire une deuxième exécution plus rapide.

Ne videz pas destructivement les caches de production simplement pour créer un test. Utilisez un jeu de données de test plus grand que la RAM disponible, des redémarrages contrôlés lorsque cela est approprié ou des exécutions suffisamment longues pour faire passer l’ensemble commun dans la hiérarchie normale. Comparez le comportement stable après la montée en température au comportement à froid, car un cache qui met plus de temps à se remplir que la durée de la charge a peu de valeur pratique.

L’article existant de ZimaSpace sur la décision générale concernant le cache pour les lectures répétées établit la limite de l’ensemble de travail pour un seul utilisateur. Ce test ajoute une question distincte : les différents utilisateurs réutilisent-ils effectivement les blocs mis en cache par les autres assez souvent pour modifier le résultat ?

Envisagez trois résultats au lieu de forcer le choix entre cache et absence de cache

Choisissez un cache de lecture SSD lorsque l’ensemble de travail partagé dépasse la RAM, se répète entre les utilisateurs, tient suffisamment bien dans le niveau de cache pour produire des succès stables et que la latence des disques durs diminue lorsque le cache est actif. Conservez l’accès direct au disque lorsque les lectures sont principalement séquentielles ou privées, que le pool respecte déjà les objectifs de latence ou que le réseau reste la limite visible.

Choisissez un jeu de données ou un volume SSD dédié lorsque les fichiers fréquemment utilisés doivent être rapides immédiatement, sont fréquemment écrits ou sont trop importants pour dépendre des règles de promotion et d’éviction. Cette troisième option est particulièrement pertinente pour les disques de machines virtuelles actives, les bases de données, l’état des conteneurs ou les fichiers de projet dont la limite de données fréquemment utilisées est connue.

Le gagnant ne devrait changer que lorsqu’une condition mesurée change : réutilisation partagée, défauts de cache mémoire, latence du stockage, stabilité du taux de succès du cache ou marge réseau. Si aucun de ces éléments ne change, un cache SSD n’est qu’un périphérique supplémentaire à gérer. Le multi-utilisateur ne crée une opportunité de cache que lorsqu’il crée des lectures partagées répétables.