Pool de SSD SATA ou miroirs de disques durs pour des millions de petits fichiers

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

SATA SSD Pool vs HDD Mirrors for Millions of Small Files - Zima Store Online

Un pool de SSD SATA constitue généralement le meilleur niveau de travail pour des millions de petits fichiers, car les parcours de répertoires, les recherches de miniatures, l’extraction de paquets et les lectures liées aux bases de données sont très sensibles à la latence. Un miroir de disques durs reste le meilleur choix en matière de rapport capacité-prix lorsque la collection est principalement froide, que la capacité domine le budget et que les utilisateurs peuvent tolérer une indexation plus lente.

Il ne s’agit pas d’une simple décision « les SSD sont plus rapides ». Une comparaison pertinente conserve constants le nombre de fichiers, la taille du jeu de données, le système de fichiers, le réseau, la mémoire vive et la politique de sauvegarde. Elle cherche ensuite à déterminer si la charge de travail passe davantage de temps à attendre des opérations dispersées sur les métadonnées ou à déplacer de gros blocs séquentiels.

Filtrez la comparaison à travers la charge de travail réelle

Comptez les fichiers, déterminez leur taille médiane, le nombre d’utilisateurs actifs et les opérations qui semblent lentes. Un million de documents archivés ouverts occasionnellement se comporte différemment d’un million de miniatures analysées, renommées, dédoublonnées et synchronisées chaque jour.

Les opérations sur de petits fichiers amplifient la latence, car une seule action de l’utilisateur peut déclencher de nombreuses recherches dans le système de fichiers et de courtes lectures. Une discussion de la communauté sur le déplacement des miniatures et des bases de données vers un SSD illustre le cas pratique : les métadonnées fréquemment utilisées peuvent tirer parti d’un SSD même lorsque les fichiers multimédias originaux restent sur des disques durs.

Si la limite actuelle est une liaison 1GbE lors de copies séquentielles volumineuses, l’un ou l’autre pool peut saturer le réseau. Dans ce cas, n’achetez pas de SSD pour leur débit théorique ; mesurez plutôt les tâches de listage de répertoires, de recherche, d’analyse et de restauration qui représentent le problème des petits fichiers.

Comparez les critères de décision, pas les débits de pointe

Critère de décision	Pool de SSD SATA	Miroir de disques durs
Latence des métadonnées aléatoires	Faible et régulière ; performant pour les recherches parallèles	Limité par les temps de recherche lorsque la simultanéité augmente
Capacité par euro	Coût plus élevé à l’échelle de plusieurs téraoctets	Généralement meilleur choix pour la capacité brute
Bruit et vibrations	Aucun bruit de recherche mécanique	Recherches audibles et vibrations pendant les analyses
Endurance en écriture	Nécessite d’examiner la charge de travail et l’endurance des disques	Aucune endurance liée à la mémoire flash, mais l’usure mécanique demeure
Récupération après panne	Reconstructions rapides, mais les modèles similaires et les micrologiciels restent importants	Exposition plus longue pendant la reconstruction à mesure que la capacité des disques augmente

L’avantage des SSD est surtout visible dans le temps de réponse p95 lors d’opérations simultanées sur les métadonnées, et pas uniquement dans le nombre moyen de mégaoctets par seconde. Le miroir de disques durs l’emporte lorsque la plupart des octets restent inactifs et que l’achat d’une capacité SSD équivalente rognerait le budget de sauvegarde.

Aucun miroir ne constitue une sauvegarde. Une suppression, un événement de chiffrement, une erreur d’application ou une erreur du système de fichiers peut affecter les deux membres ; conservez une récupération versionnée en dehors du pool.

Quand une conception à niveaux séparés surpasse les deux extrêmes

Une troisième option est souvent gagnante : placez les index, les miniatures, les caches de paquets, les projets actifs et les bases de données sur des SSD en miroir, tout en stockant les fichiers originaux froids ou les archives immuables sur des miroirs de disques durs. La taille de l’ensemble de travail sensible à la latence reste ainsi suffisamment réduite pour être abordable.

La séparation doit être explicite. Les applications doivent savoir quelles données peuvent être régénérées, lesquelles doivent être sauvegardées et ce qui se passe lorsque le niveau de disques durs est indisponible ; sinon, un « cache » devient discrètement l’unique copie de données précieuses.

Pour les applications accessibles sur le réseau, l’article de ZimaSpace sur les partages réseau fiables pour Immich montre pourquoi l’emplacement de la base de données, la stabilité du montage et l’emplacement des fichiers multimédias doivent être considérés comme des décisions distinctes.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

Choisissez selon le seuil qui change l’expérience utilisateur

Choisissez le pool de SSD SATA lorsque les analyses répétées, la navigation dans les dossiers, les opérations de gestion de versions, les frises chronologiques de photos ou l’indexation des sauvegardes restent lentes après avoir écarté les limites de la mémoire vive et du réseau. Utilisez des disques offrant une endurance adaptée et conservez suffisamment d’espace libre pour le ramasse-miettes et les instantanés.

Choisissez des miroirs de disques durs lorsque le jeu de données est principalement volumineux ou froid, que l’augmentation de la capacité constitue la principale contrainte et que les tâches sur les métadonnées peuvent être exécutées en dehors des heures d’activité. Ajouter de la mémoire vive peut améliorer la mise en cache, mais cela ne supprime ni les temps de recherche lorsque le cache est froid ni le premier parcours complet.

Choisissez une architecture à niveaux séparés lorsqu’un ensemble de données actives mesuré est beaucoup plus petit que l’archive. Interrompez la comparaison et corrigez d’abord le réseau, la base de données de l’application ou la conception de la sauvegarde si ce sont ces composants, et non le support de stockage, qui déterminent le résultat.

FAQ

Un million de fichiers constitue-t-il un seuil universel justifiant des SSD ? Non. La profondeur des répertoires, la taille des fichiers, le taux de succès du cache, le nombre de tâches simultanées et le schéma d’accès comptent davantage qu’un seuil rond fondé sur le nombre de fichiers.

Un cache SSD peut-il rendre un miroir de disques durs équivalent ? Seulement lorsque le cache capture régulièrement les lectures et écritures fréquemment utilisées. Une analyse complète de données froides atteint toujours les disques durs, et la mise en cache en écriture différée ajoute des exigences en matière de récupération.