Une configuration Jellyfin à double stockage avec les métadonnées sur SSD et les données sur HDD

Une configuration Jellyfin efficace à deux niveaux de stockage place l’état sensible à la latence de l’application et les métadonnées actives sur SSD, tout en conservant les gros fichiers multimédias sur un stockage HDD offrant un bon rapport capacité-coût.

Cela ne signifie pas que tous les fichiers Jellyfin nécessitent le périphérique le plus rapide. Les bases de données, les index d’illustrations, les miniatures et les caches génèrent de nombreuses petites recherches ; les films et la musique font principalement l’objet de grandes lectures séquentielles ; l’espace temporaire de transcodage est provisoire et peut générer de nombreuses écritures. Attribuez à chaque rôle un niveau de stockage dont la latence, la capacité, l’endurance, la sauvegarde et la récupération correspondent au flux de travail, puis testez la configuration complète pendant l’analyse et la lecture.

Attribuez des rôles différents au SSD et au HDD

Utilisez le SSD pour le système d’exploitation ou les données des applications conteneurisées, la base de données Jellyfin, la configuration, les métadonnées actives, les index et le cache. Conservez les films, les épisodes, la musique et les vidéos personnelles volumineux sur le pool de HDD. Considérez le stockage de transcodage comme un choix distinct : il peut utiliser le SSD si l’espace et l’endurance le permettent, ou un autre espace temporaire rapide si les transcodages simultanés génèrent beaucoup d’écritures.

Un guide pratique des charges de travail sur SSD en homelab établit la même distinction entre les rôles : les bases de données et les applications actives profitent de la mémoire flash à faible latence, tandis que les niveaux de stockage de grande capacité n’ont pas besoin de performances de classe NVMe simplement parce qu’un stockage plus rapide existe.

Ne répartissez pas les données en vous fiant uniquement au nom du dossier. Certaines « métadonnées » font autorité ou ont été organisées manuellement et méritent d’être sauvegardées, tandis que le cache des images peut être régénéré. La configuration devient récupérable lorsque vous savez quels contenus du SSD doivent être restaurés après une panne et lesquels peuvent être recréés à partir des fichiers multimédias.

Placez les données d’application à accès aléatoire sur le SSD

La navigation dans Jellyfin, les recherches, les mises à jour de l’état des utilisateurs, la recherche des illustrations, les transactions de la base de données et de nombreuses opérations sur la bibliothèque sont sensibles à la latence, contrairement à la lecture séquentielle d’un film. Déplacer cet ensemble de données de travail de l’application du HDD vers le SSD élimine le coût des déplacements mécaniques des têtes de lecture et réduit les interférences entre les petites opérations d’E/S sur les métadonnées et les grandes lectures de fichiers multimédias.

Un guide récent sur les performances de Jellyfin identifie le stockage lent des métadonnées comme une cause directe de la lenteur de navigation dans la bibliothèque, car les données de l’application nécessitent de nombreuses petites lectures. L’analyse de ZimaSpace sur les performances de Jellyfin sur SSD par rapport au HDD établit la même répartition des rôles : la latence des données de l’application profite du SSD, tandis que les fichiers multimédias volumineux peuvent rester sur HDD.

Dimensionnez le SSD en fonction de la croissance réelle des données de l’application, en prévoyant une marge, et non en fonction de la capacité des médias. Gardez de l’espace libre pour la croissance de la base de données, les métadonnées, les séquences d’images intermédiaires ou les illustrations si cette fonction est activée, les sauvegardes créées localement avant leur exportation, ainsi que la charge de travail temporaire la plus importante que vous prévoyez d’y placer. Un petit SSD saturé est pire qu’un SSD plus grand conservant une marge d’espace libre suffisante.

Conservez les médias volumineux sur disque dur, sauf si une autre exigence change la donne

Le disque dur reste un choix judicieux pour les médias, car la lecture d’un film consiste généralement en une lecture séquentielle soutenue dont le débit binaire est très inférieur au débit d’un disque moderne en bon état. Le coût par unité de capacité, les baies de disques, la redondance et les sauvegardes pèsent souvent bien plus dans la décision que la vitesse d’interface d’un SSD pour le fichier média lui-même.

Un utilisateur récent de Jellyfin sur NAS décrit une configuration avec des conteneurs sur SSD et des médias sur disque dur qui permet de parcourir rapidement le contenu depuis le SSD, mais entraîne un délai de 15 à 20 secondes lorsque les disques durs en veille doivent se réveiller pour la lecture. Cela illustre le véritable compromis : non pas le débit soutenu, mais la latence de la première lecture et le comportement de la gestion de l’énergie.

Si le démarrage immédiat compte davantage que les économies liées à la mise en veille, laissez les disques des médias actifs pendant les heures habituelles de visionnage ou ajustez leur politique de gestion de l’énergie. Si le silence et la faible consommation sont prioritaires, acceptez le délai de réveil lors de la première lecture. Déplacer tous les médias sur SSD pour éviter une seule pause de démarrage est généralement un choix lié au coût de la capacité, et non une exigence de Jellyfin.

Featured

NAS cloud personnel et domestique ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Protégez le SSD, petit mais essentiel pour la restauration

Le SSD peut contenir bien moins de données que le pool de disques durs, tout en abritant les éléments qui font que le serveur ressemble toujours à la même instance Jellyfin. Une panne du SSD contenant les données de l’application peut effacer les utilisateurs, l’historique de lecture, la configuration, les listes de lecture et les métadonnées sélectionnées, même si tous les films restent intacts. Sauvegardez fréquemment ce petit ensemble de données à restaurer, en le plaçant hors du domaine de défaillance du SSD.

Une architecture à deux niveaux fonctionne mieux lorsque les données d’application stockées sur SSD disposent de leur propre procédure de restauration testée. Un processus de test de restauration met l’accent sur la validation de l’application sur une cible isolée, plutôt que de considérer les fichiers copiés comme une preuve. Conservez les données spécifiques au serveur dans des sauvegardes SSD versionnées, puis gardez certains fichiers annexes des médias uniquement s’ils facilitent la migration ou la reconstruction.

Ne mettez pas le SSD en miroir dans le seul but d’éviter les sauvegardes. La redondance peut réduire les temps d’arrêt après une panne de périphérique, mais elle ne permet pas de récupérer les données après une mise à niveau ratée, une suppression accidentelle, une corruption de base de données ou la perte de l’hôte. Conservez des points de restauration versionnés et testez une restauration sur une instance Jellyfin isolée.

Évitez que les tâches à E/S mixtes compromettent la séparation du stockage

Cette configuration est surtout utile lorsque les E/S liées à l’état de l’application restent sur le SSD et que les gros transferts de médias restent sur le HDD. Les sauvegardes, téléchargements, décompressions, analyses de médias ou écritures de transcodage peuvent compromettre cette séparation s’ils ciblent tous le même périphérique au même moment. Déterminez où chaque tâche récurrente écrit ses données et, si nécessaire, planifiez les tâches lourdes en dehors des heures de visionnage les plus chargées.

Un homelab à deux niveaux de stockage doit être testé avec le même type de charge d’E/S aléatoires mixtes qui rend visibles les files d’attente du stockage. Les chiffres exacts des tests de performance ne s’appliquent pas à Jellyfin, mais le mécanisme, lui, est le même : les petites opérations simultanées sur la base de données réagissent à la latence très différemment d’une longue lecture séquentielle de médias.

Mesurez le chargement du tableau de bord, les recherches, le démarrage de la lecture, la durée des analyses, la mise en file d’attente des HDD et la latence du SSD lors d’un chevauchement normal. Si la navigation reste rapide, mais que la lecture n’attend que le réveil des disques en veille, la configuration fonctionne comme prévu. Si les deux niveaux ralentissent pendant une sauvegarde ou une importation, corrigez le goulot d’étranglement commun du contrôleur, du réseau ou de la planification avant d’acheter une mémoire flash plus rapide.

Étendez le niveau qui atteint réellement sa limite

Augmentez la capacité SSD lorsque l’état de l’application Jellyfin, les métadonnées ou l’espace de travail temporaire approchent du seuil d’espace libre, ou lorsqu’une autre base de données hébergée sur la même machine a besoin du même niveau à faible latence. Augmentez la capacité HDD lorsque la conservation des médias atteint la limite du pool. Ne mettez le réseau à niveau que lorsque le chemin média séparé devient le goulot d’étranglement mesuré.

Un récent guide sur les niveaux de stockage pour les serveurs multimédias fait la même distinction entre les charges de travail : la capacité SSD doit accueillir les données du serveur sensibles à la latence, tandis que la capacité HDD sert aux grandes médiathèques. Augmentez la capacité du niveau dont la limite mesurée de capacité ou de latence est effectivement atteinte.

Arrêtez-vous lorsque le SSD peut contenir l’ensemble de travail de l’application active tout en gardant une marge pour la récupération, que le pool de disques durs répond à la demande habituelle de médias, que les sauvegardes couvrent correctement les deux rôles et que le chevauchement normal le plus exigeant respecte les objectifs de latence. La configuration à deux niveaux de stockage est réussie lorsque chaque niveau a une fonction claire, et non lorsque chaque connecteur disponible est occupé par un disque.