Almacenamiento del archivo DVR y caché SSD¶

Apéndice para instalaciones con un archivo grande: cómo el nodo lee el archivo DVR, cómo estimar la carga de los discos y elegir entre HDD y SSD, cómo colocar una caché SSD delante de una matriz de HDD con las herramientas del sistema operativo y cómo ajustar el sistema. La configuración de los propios almacenes y de la limpieza se describe en Almacenes DVR; su supervisión, en Monitor de DVR.

Todas las cifras de esta página son orientativas y ejemplos para hacer estimaciones, no una promesa de rendimiento: la carga real depende de la audiencia, del conjunto de canales y del hardware.

1. Cómo lee el nodo el archivo¶

El nodo escribe el archivo en ficheros normales en el directorio del almacén y lo lee con lectura de ficheros normal. Por eso cada lectura del archivo pasa por la caché de páginas de Linux: la lectura repetida de los mismos segmentos se sirve desde la memoria RAM, sin acceder al disco. La memoria RAM es el primer nivel de caché, y gratuito; el nodo no necesita ningún ajuste para ello.

Casi sin acceder al disco, desde la memoria se sirven:

la visualización con desplazamiento (timeshift) y desde el inicio del programa dentro de aproximadamente media hora o una hora desde la emisión en directo: estos segmentos se acaban de grabar y todavía están en la caché;
los programas y eventos populares que ven a la vez cientos de espectadores: el disco lee ese segmento una sola vez y el resto de los espectadores lo reciben desde la memoria;
el catch-up reciente de la franja de máxima audiencia de ayer, que se vuelve a ver.

La cola larga —distintos canales y días del archivo, cada uno visto por pocos— no cabe en la memoria y se lee de los discos. Linux conserva más tiempo las páginas leídas varias veces, mientras que las visualizaciones aisladas son desplazadas por el flujo de escritura en media hora o una hora. Por eso, con un archivo de decenas de terabytes y una audiencia amplia, la memoria quita de los discos, por regla general, de una cuarta parte a un tercio de las lecturas: acelera lo más caliente, pero no sustituye el rendimiento de los discos.

2. Estimación de la carga y elección de los discos¶

Escritura, volumen y lectura¶

Tres magnitudes se calculan así:

Flujo de escritura = número de canales que se graban × bitrate total de todas las variantes del canal. Por ejemplo, 150 canales de 8 Mbit/s (tres variantes de calidad) son 1200 Mbit/s, es decir, 150 MB/s de escritura continua.
Volumen del archivo = flujo de escritura × profundidad de almacenamiento. 150 MB/s son unos 13 TB al día, 7 días son unos 91 TB y 14 días, unos 182 TB de espacio útil, sin contar RAID.
Flujo de lectura = espectadores simultáneos del archivo × bitrate medio de visualización. El número de espectadores del archivo es la proporción máxima de espectadores simultáneos multiplicada por la proporción de quienes ven el archivo en lugar de la emisión en directo. Por ejemplo, 10 000 abonados, en la hora punta un 30 % frente a la pantalla y un 30 % de ellos en el archivo son 900 espectadores; a 4 Mbit/s de media son 3,6 Gbit/s, unos 450 MB/s de lectura.

Al flujo de lectura de los discos se suma el flujo de escritura: los discos atienden ambos a la vez. Parte de las lecturas las quita la memoria RAM (1. Cómo lee el nodo el archivo).

HDD y SSD¶

Cada espectador del archivo es un flujo de lectura secuencial independiente, y cientos de estos flujos juntos tienen para el disco el aspecto de un acceso aleatorio en bloques grandes.

Con muchos flujos simultáneos, un HDD (NL-SAS o SATA de 7200 rpm) rinde, por regla general, 60–100 MB/s por disco si la lectura anticipada es grande (4. Ajuste del sistema). El coste por terabyte del HDD es el más bajo.
Un SSD NVMe rinde gigabytes por segundo y el acceso aleatorio no le afecta. El terabyte cuesta varias veces más. La resistencia a la escritura se indica en DWPD: cuántas capacidades completas del disco al día se pueden escribir durante todo el periodo de garantía. Para el archivo se calcula así: volumen diario de escritura ÷ capacidad total de los discos. 13 TB al día en ocho discos de 15,36 TB son unos 0,1 DWPD, con margen incluso para discos de 1 DWPD.

Ejemplo para un archivo de 7 días (unos 91 TB): un RAID 6 de diez HDD de 20 TB ofrece 160 TB de espacio útil y del orden de 500–800 MB/s de lectura total. Esto basta para cientos de espectadores simultáneos del archivo junto con la escritura. Cuando hay más de mil espectadores del archivo, esa matriz trabaja al límite: hacen falta más discos, una caché SSD (3. Caché SSD con las herramientas del SO) o una matriz de SSD.

Elección de RAID y recomendaciones generales¶

RAID 6 es la opción principal para matrices grandes de HDD: la reconstrucción tras sustituir un disco de 20 TB es larga y RAID 6 sobrevive al fallo de un segundo disco durante ese tiempo. RAID 5 no se recomienda con discos de ese tamaño.
RAID 10 ofrece más rendimiento con carga mixta, pero solo la mitad de la capacidad.
Para matrices de SSD sirven RAID 5, RAID 6 o RAID 10: su tiempo de reconstrucción es mucho menor.
Un almacén por disco o matriz (Almacenes DVR).
Pautas de elección:
- hasta aproximadamente mil espectadores simultáneos del archivo: una matriz de HDD (RAID 6 o RAID 10) y 256–512 GB de memoria RAM para la caché de páginas;
- más espectadores o un archivo de 30–90 días con catch-up activo: HDD para la capacidad y una caché SSD para el último día, o bien el reparto de los canales entre varios nodos;
- una matriz solo de SSD: cuando el espacio en el rack, el consumo energético o una carga muy alta importan más que el coste por terabyte.

3. Caché SSD con las herramientas del SO¶

La caché SSD no estorba al nodo ni le exige nada: el nodo lee y escribe ficheros, y la caché se sitúa por debajo del sistema de ficheros (nivel de bloques) o dentro de él. Orden por intensidad del efecto: primero la memoria RAM (caché de páginas), luego el SSD para los datos calientes de uno o dos días siguientes (normalmente 2–8 TB de NVMe) y después el HDD para la capacidad.

Escritura directa y diferida¶

Escritura directa (writethrough) es el modo recomendado para el archivo. La escritura va directamente al HDD y el SSD conserva los bloques leídos con frecuencia. El fallo del SSD no pierde datos: la matriz sigue funcionando sin caché.
Escritura diferida (writeback) conserva en el SSD también la escritura reciente, lo que acelera el timeshift y el catch-up reciente. Pero los datos aún no transferidos al HDD se pierden junto con el SSD, por lo que en este modo la caché solo se coloca sobre un espejo de dos SSD (RAID 1) y consume la resistencia a la escritura del SSD.
dm-writecache almacena en caché solo la escritura y no acelera la lectura del archivo; no es adecuado para el archivo.

lvmcache: RHEL, AlmaLinux, Rocky Linux, Oracle Linux¶

lvmcache (dm-cache) es la opción principal para sistemas basados en RHEL, donde cuenta con soporte nativo. La caché es un volumen lógico en el SSD conectado al volumen del archivo dentro del mismo grupo de volúmenes. La política predeterminada (smq) traslada al SSD los bloques que se leen repetidamente, por lo que las visualizaciones aisladas no ensucian la caché. La caché se puede conectar y desconectar con el volumen en funcionamiento, sin detener la escritura.

En el ejemplo, el archivo está en el volumen vg_dvr/dvr (matriz de HDD) y el SSD es /dev/nvme0n1. Añada el SSD al grupo de volúmenes y cree en él el volumen de caché:

sudo pvcreate /dev/nvme0n1
sudo vgextend vg_dvr /dev/nvme0n1
sudo lvcreate -n dvr_cache -L 3T vg_dvr /dev/nvme0n1

Conecte la caché en modo de escritura directa:

sudo lvconvert --type cache --cachevol dvr_cache --cachemode writethrough vg_dvr/dvr

Compruebe el modo y las estadísticas de aciertos:

sudo lvs -o name,size,cache_mode,cache_policy,cache_read_hits,cache_read_misses vg_dvr

La relación entre cache_read_hits y la suma de aciertos y fallos es la proporción de lecturas que sirve el SSD. Para desconectar la caché: --splitcache conserva el volumen de caché para volver a conectarlo y --uncache lo elimina; los datos del archivo permanecen en el HDD en ambos casos. En versiones antiguas de LVM (por ejemplo, en RHEL 7) no existe --cachevol: allí el volumen de caché se convierte primero en un pool (lvconvert --type cache-pool) y se conecta con --cachepool.

sudo lvconvert --splitcache vg_dvr/dvr

bcache: Debian y Ubuntu¶

bcache forma parte del kernel de Linux y está extendido en Debian y Ubuntu; en RHEL no se suministra. Se crea sobre dispositivos vacíos: en una matriz existente con archivo no se puede activar sin trasladar los datos. El sistema de ficheros se crea ya sobre el dispositivo /dev/bcache0.

En el ejemplo, la matriz de HDD es /dev/md0 y el SSD es /dev/nvme0n1. Cree el dispositivo con caché (de forma predeterminada, en modo de escritura directa):

sudo apt install bcache-tools
sudo make-bcache -B /dev/md0 -C /dev/nvme0n1

El ajuste principal para el archivo es sequential_cutoff. De forma predeterminada, bcache deja pasar sin caché la lectura y escritura secuenciales de más de 4 MB, y cada espectador del archivo es precisamente un flujo secuencial, de modo que con el ajuste predeterminado la caché casi no almacena nada. Desactive el umbral:

echo 0 | sudo tee /sys/block/bcache0/bcache/sequential_cutoff

Este valor no se conserva tras el reinicio: establézcalo durante el arranque, por ejemplo con una regla de udev o un servicio de systemd. Compruebe el modo y la proporción de aciertos:

cat /sys/block/bcache0/bcache/cache_mode
cat /sys/block/bcache0/bcache/stats_day/cache_hit_ratio

ZFS: ARC y L2ARC¶

En ZFS (paquetes de OpenZFS), el papel de caché de páginas lo desempeña una caché propia en memoria, ARC, y el SSD se conecta al pool como segundo nivel de caché, L2ARC. L2ARC almacena en caché solo la lectura; el fallo del SSD no pierde datos. Conecte el SSD al pool dvr:

sudo zpool add dvr cache /dev/nvme0n1

De forma predeterminada, L2ARC no admite los datos leídos mediante lectura anticipada, es decir, los flujos secuenciales de los espectadores del archivo. Para el archivo hay que desactivarlo y, además, conservarlo para los siguientes arranques:

echo 0 | sudo tee /sys/module/zfs/parameters/l2arc_noprefetch
echo "options zfs l2arc_noprefetch=0" | sudo tee -a /etc/modprobe.d/zfs.conf

Algunos ajustes más para el archivo:

recordsize=1M para el conjunto de datos con el archivo: el archivo consta de ficheros grandes que se leen enteros;
atime=off: sin escribir la hora de acceso en cada lectura;
zfs_arc_max: límite de memoria para ARC; deje memoria también para el nodo;
l2arc_write_max: velocidad de llenado de L2ARC; el valor predeterminado es pequeño y, con un archivo grande, la caché se llena despacio.

Las estadísticas de ARC y L2ARC las muestra arc_summary y la carga de los dispositivos del pool, zpool iostat -v dvr 5.

4. Ajuste del sistema¶

Lectura anticipada. Para una matriz de HDD, establezca una lectura anticipada grande, por ejemplo 4 MB (8192 sectores de 512 bytes); se conserva hasta el reinicio, por lo que establézcala también en el arranque (con una regla de udev). Para un volumen LVM lo mismo lo establece lvchange --readahead.
```
sudo blockdev --setra 8192 /dev/md0
sudo blockdev --getra /dev/md0
```
Memoria para la caché. La caché de páginas ocupa toda la memoria libre, por lo que deje un margen al nodo: no ejecute en él otros procesos voraces y no permita que el sistema use el swap. La devolución de la memoria no utilizada por el nodo se describe en Memoria.
Sistema de ficheros. Sirven XFS (el predeterminado en sistemas basados en RHEL) y ext4. Monte el almacén con noatime para que la lectura del archivo no genere escrituras de la hora de acceso.
Supervisión. La carga de los discos la muestra iostat -x 5 (columnas de lectura y escritura en MB/s, tiempo de espera, carga del dispositivo), el tamaño de la caché de páginas, la línea buff/cache en la salida de free -h y los aciertos de la caché SSD, los comandos de las secciones anteriores. Las latencias de lectura y escritura del archivo por flujos las muestra la pantalla «Monitor de DVR» (Monitor de DVR), y ante lecturas y escrituras prolongadas se activa la alerta de código 50 (dvr-rw-time, Lista de alertas).