--- title: Stockage de l’archive DVR et cache SSD url: https://doc2.pstreamer.tv/fr/manual/extras/dvr_storage.html lang: fr product: Perfect Streamer version: 2.0.2.423 --- # Stockage de l’archive DVR et cache SSD Annexe pour les installations disposant d’une grande archive : comment le nœud lit l’archive DVR, comment estimer la charge sur les disques et choisir entre HDD et SSD, comment placer un cache SSD devant une grappe de HDD avec les moyens de l’OS et comment configurer le système. La configuration des stockages eux-mêmes et du nettoyage est décrite dans [Stockages DVR](../streamer/ott_dvr.md#streamer-dvr-storage), leur supervision dans [Moniteur DVR](../webui/monitor.md#webui-dvr-monitor). Tous les chiffres de cette page sont des repères et des exemples pour une estimation, et non une promesse de performances : la charge réelle dépend de l’audience, de l’ensemble des chaînes et du matériel. ## 1. Comment le nœud lit l’archive Le nœud écrit l’archive dans des fichiers ordinaires, dans le répertoire du stockage, et les lit par une lecture de fichier ordinaire. Chaque lecture de l’archive passe donc par le cache de pages de Linux : la relecture des mêmes segments est servie depuis la mémoire vive, sans accès au disque. La mémoire vive est le premier niveau de cache, et il est gratuit ; le nœud n’a rien à configurer pour cela. Sont servis depuis la mémoire, presque sans accès au disque : - le visionnage en décalage (timeshift) et depuis le début de l’émission, dans une fenêtre d’environ une demi-heure à une heure par rapport au direct : ces segments viennent d’être écrits et se trouvent encore dans le cache ; - les émissions et événements populaires que des centaines de spectateurs regardent en même temps : le disque lit un tel segment une seule fois, les autres spectateurs le reçoivent depuis la mémoire ; - le catch-up récent de la veille en prime time, que l’on regarde de nouveau. La longue traîne — les différentes chaînes et jours de l’archive, que peu de spectateurs regardent chacun — ne tient pas en mémoire et est lue depuis les disques. Linux garde plus longtemps les pages lues plusieurs fois, tandis que les visionnages isolés sont évincés par le flux d’écriture en une demi-heure à une heure. Ainsi, pour une archive de plusieurs dizaines de téraoctets et une large audience, la mémoire décharge les disques, en règle générale, d’un quart à un tiers des lectures : elle accélère le plus sollicité, mais ne remplace pas les performances des disques. ## 2. Estimation de la charge et choix des disques ### Écriture, volume et lecture Trois grandeurs se calculent ainsi : - **Débit d’écriture** = nombre de chaînes enregistrées × débit total de toutes les variantes de la chaîne. Par exemple, 150 chaînes à 8 Mbit/s (trois variantes de qualité) font 1200 Mbit/s, soit 150 Mo/s d’écriture continue. - **Volume de l’archive** = débit d’écriture × durée de conservation. 150 Mo/s représentent environ 13 To par jour, 7 jours environ 91 To, 14 jours environ 182 To d’espace utile, hors RAID. - **Débit de lecture** = spectateurs simultanés de l’archive × débit moyen de visionnage. Le nombre de spectateurs de l’archive est la part de spectateurs simultanés au pic, multipliée par la part de ceux qui regardent l’archive plutôt que le direct. Par exemple, 10 000 abonnés, 30 % devant l’écran au pic et 30 % d’entre eux dans l’archive font 900 spectateurs ; à 4 Mbit/s en moyenne, cela donne 3,6 Gbit/s, soit environ 450 Mo/s de lecture. Le débit d’écriture s’ajoute au débit de lecture depuis les disques : les disques assurent les deux en même temps. Une partie des lectures est absorbée par la mémoire vive (1. Comment le nœud lit l’archive). ### HDD et SSD Chaque spectateur de l’archive est un flux de lecture séquentiel distinct, et des centaines de tels flux ressemblent, pour le disque, à un accès aléatoire par gros blocs. - Un **HDD** (NL-SAS ou SATA 7200 tr/min) délivre, en règle générale, 60 à 100 Mo/s par disque avec de nombreux flux simultanés, si la lecture anticipée est grande (4. Configuration du système). Le coût du téraoctet est le plus bas avec les HDD. - Un **SSD NVMe** délivre des gigaoctets par seconde, et l’accès aléatoire ne le gêne pas. Le téraoctet coûte plusieurs fois plus cher. L’endurance en écriture est indiquée en DWPD : combien de fois la capacité totale du disque peut être écrite par jour pendant toute la durée de garantie. Pour une archive, on la calcule ainsi : volume d’écriture quotidien ÷ capacité totale des disques. 13 To par jour sur huit disques de 15,36 To font environ 0,1 DWPD, avec de la marge même pour des disques de 1 DWPD. Exemple pour une archive de 7 jours (environ 91 To) : un RAID 6 de dix HDD de 20 To offre 160 To d’espace utile et de l’ordre de 500 à 800 Mo/s de lecture cumulée. Cela suffit pour des centaines de spectateurs simultanés de l’archive, écriture comprise. Lorsque les spectateurs de l’archive dépassent le millier, une telle grappe travaille à sa limite : il faut davantage de disques, un cache SSD (3. Cache SSD avec les moyens de l’OS) ou une grappe de SSD. ### Choix du RAID et recommandations générales - Le **RAID 6** est le choix principal pour les grandes grappes de HDD : la reconstruction après le remplacement d’un disque de 20 To est longue, et le RAID 6 survit à la panne d’un deuxième disque pendant ce temps. Le RAID 5 n’est pas recommandé sur des disques de cette taille. - Le **RAID 10** offre plus de performances sur une charge mixte, mais seulement la moitié de la capacité. - Pour les grappes de SSD, le RAID 5, le RAID 6 ou le RAID 10 conviennent : leur temps de reconstruction est bien plus court. - Un stockage par disque ou par grappe ([Stockages DVR](../streamer/ott_dvr.md#streamer-dvr-storage)). - Repères pour le choix : - jusqu’à environ mille spectateurs simultanés de l’archive : une grappe de HDD (RAID 6 ou RAID 10) et 256 à 512 Go de mémoire vive pour le cache de pages ; - davantage de spectateurs, ou une archive de 30 à 90 jours avec un catch-up actif : des HDD pour la capacité et un cache SSD pour les derniers jours, ou bien la répartition des chaînes entre plusieurs nœuds ; - une grappe uniquement de SSD : lorsque la place en baie, la consommation électrique ou une charge très élevée comptent plus que le coût du téraoctet. ## 3. Cache SSD avec les moyens de l’OS Le cache SSD ne gêne pas le nœud et ne lui demande rien : le nœud lit et écrit des fichiers, et le cache se trouve sous le système de fichiers (niveau bloc) ou à l’intérieur. Ordre par force d’effet : d’abord la mémoire vive (cache de pages), ensuite un SSD pour les données chaudes du ou des deux jours suivants (généralement 2 à 8 To de NVMe), puis les HDD pour la capacité. ### Écriture directe et écriture différée - **L’écriture directe (writethrough)** est le mode recommandé pour l’archive. L’écriture va immédiatement sur le HDD, et le SSD conserve les blocs fréquemment lus. La panne du SSD ne fait perdre aucune donnée : la grappe continue de fonctionner sans cache. - **L’écriture différée (writeback)** conserve sur le SSD aussi les écritures récentes, ce qui accélère le timeshift et le catch-up récent. Mais les données pas encore transférées sur le HDD disparaissent avec le SSD ; c’est pourquoi, dans ce mode, le cache n’est placé que sur un miroir de deux SSD (RAID 1), et il consomme l’endurance en écriture du SSD. - **dm-writecache** ne met en cache que l’écriture et n’accélère pas la lecture de l’archive ; il ne convient pas pour l’archive. ### lvmcache : RHEL, AlmaLinux, Rocky Linux, Oracle Linux lvmcache (dm-cache) est la variante principale pour les systèmes de la famille RHEL, où il est pris en charge en standard. Le cache est un volume logique sur SSD, rattaché au volume de l’archive dans le même groupe de volumes. La politique par défaut (smq) transfère sur le SSD les blocs lus à plusieurs reprises, de sorte que les visionnages isolés n’encombrent pas le cache. Le cache peut être rattaché et détaché sur un volume en fonctionnement, sans arrêter l’écriture. Dans l’exemple, l’archive se trouve sur le volume `vg_dvr/dvr` (grappe de HDD) et le SSD est `/dev/nvme0n1`. Ajouter le SSD au groupe de volumes et y créer le volume de cache : ```sh sudo pvcreate /dev/nvme0n1 sudo vgextend vg_dvr /dev/nvme0n1 sudo lvcreate -n dvr_cache -L 3T vg_dvr /dev/nvme0n1 ``` Rattacher le cache en mode écriture directe : ```sh sudo lvconvert --type cache --cachevol dvr_cache --cachemode writethrough vg_dvr/dvr ``` Vérifier le mode et les statistiques de succès : ```sh sudo lvs -o name,size,cache_mode,cache_policy,cache_read_hits,cache_read_misses vg_dvr ``` Le rapport entre `cache_read_hits` et la somme des succès et des échecs est la part des lectures servies par le SSD. Pour détacher le cache : `--splitcache` conserve le volume de cache pour un nouveau rattachement, `--uncache` le supprime ; les données de l’archive restent sur les HDD dans les deux cas. Les anciennes versions de LVM (par exemple dans RHEL 7) n’ont pas `--cachevol` : il faut d’abord y transformer le volume de cache en pool (`lvconvert --type cache-pool`) et le rattacher avec `--cachepool`. ```sh sudo lvconvert --splitcache vg_dvr/dvr ``` ### bcache : Debian et Ubuntu bcache fait partie du noyau Linux et est répandu sur Debian et Ubuntu ; il n’est pas fourni dans RHEL. Il se crée sur des périphériques vides : sur une grappe existante contenant l’archive, on ne peut pas l’activer sans déplacer les données. Le système de fichiers est créé directement sur le périphérique `/dev/bcache0`. Dans l’exemple, la grappe de HDD est `/dev/md0` et le SSD `/dev/nvme0n1`. Créer le périphérique avec cache (par défaut en mode écriture directe) : ```sh sudo apt install bcache-tools sudo make-bcache -B /dev/md0 -C /dev/nvme0n1 ``` Le réglage principal pour l’archive est `sequential_cutoff`. Par défaut, bcache contourne le cache pour la lecture et l’écriture séquentielles de plus de 4 Mo, or chaque spectateur de l’archive est précisément un flux séquentiel, de sorte qu’avec le réglage par défaut le cache ne conserve presque rien. Désactiver le seuil : ```sh echo 0 | sudo tee /sys/block/bcache0/bcache/sequential_cutoff ``` Cette valeur n’est pas conservée après un redémarrage : définissez-la au démarrage, par exemple avec une règle udev ou un service systemd. Vérifier le mode et le taux de succès : ```sh cat /sys/block/bcache0/bcache/cache_mode cat /sys/block/bcache0/bcache/stats_day/cache_hit_ratio ``` ### ZFS : ARC et L2ARC Dans ZFS (paquets OpenZFS), le rôle du cache de pages est tenu par un cache propre en mémoire, l’ARC, et le SSD se rattache au pool comme second niveau de cache, le L2ARC. Le L2ARC ne met en cache que la lecture ; la panne du SSD ne fait perdre aucune donnée. Rattacher le SSD au pool `dvr` : ```sh sudo zpool add dvr cache /dev/nvme0n1 ``` Par défaut, le L2ARC n’accepte pas les données lues par lecture anticipée, c’est-à-dire les flux séquentiels des spectateurs de l’archive. Pour une archive, il faut le désactiver et le conserver aussi pour les démarrages suivants : ```sh echo 0 | sudo tee /sys/module/zfs/parameters/l2arc_noprefetch echo "options zfs l2arc_noprefetch=0" | sudo tee -a /etc/modprobe.d/zfs.conf ``` Quelques réglages de plus pour l’archive : - `recordsize=1M` pour le jeu de données de l’archive : l’archive se compose de gros fichiers lus en entier ; - `atime=off` : sans écriture de l’heure d’accès à chaque lecture ; - `zfs_arc_max` : limite de mémoire pour l’ARC ; laissez de la mémoire au nœud aussi ; - `l2arc_write_max` : vitesse de remplissage du L2ARC ; la valeur par défaut est modeste, et avec une grande archive le cache se remplit lentement. Les statistiques de l’ARC et du L2ARC sont affichées par `arc_summary`, la charge sur les périphériques du pool par `zpool iostat -v dvr 5`. ## 4. Configuration du système - **Lecture anticipée.** Pour une grappe de HDD, définissez une grande lecture anticipée, par exemple 4 Mo (8192 secteurs de 512 octets) ; elle est conservée jusqu’au redémarrage, définissez-la donc aussi au démarrage (par une règle udev). Pour un volume LVM, la même chose est faite par `lvchange --readahead`. ```sh sudo blockdev --setra 8192 /dev/md0 sudo blockdev --getra /dev/md0 ``` - **Mémoire pour le cache.** Le cache de pages occupe toute la mémoire libre, laissez donc une réserve au nœud : n’y lancez pas d’autres processus gourmands et ne laissez pas le système basculer dans le swap. La restitution de la mémoire inutilisée par le nœud est décrite dans [Mémoire](tuning.md#extras-tuning-memory). - **Système de fichiers.** XFS (par défaut dans les systèmes de la famille RHEL) et ext4 conviennent. Montez le stockage avec `noatime`, afin que la lecture de l’archive ne génère pas d’écritures de l’heure d’accès. - **Supervision.** La charge sur les disques est affichée par `iostat -x 5` (colonnes de lecture et d’écriture en Mo/s, temps d’attente, charge du périphérique), le volume du cache de pages par la ligne `buff/cache` dans la sortie de `free -h`, les succès du cache SSD par les commandes des sections ci-dessus. Les latences de lecture et d’écriture de l’archive par flux sont affichées par l’écran « Moniteur DVR » ([Moniteur DVR](../webui/monitor.md#webui-dvr-monitor)), et en cas de lectures et d’écritures longues, une alerte de code 50 (`dvr-rw-time`, [Liste des alertes](alert_codes.md#extras-alert-codes)) se déclenche.