Хранилище архива DVR и SSD-кеш¶

Приложение для инсталляций с большим архивом: как узел читает архив DVR, как оценить нагрузку на диски и выбрать между HDD и SSD, как поставить SSD-кеш перед массивом HDD средствами ОС и как настроить систему. Настройка самих хранилищ и очистки описана в Хранилища DVR, наблюдение за ними — в Монитор DVR.

Все числа на этой странице — ориентиры и примеры для оценки, а не обещание производительности: реальная нагрузка зависит от аудитории, набора каналов и оборудования.

1. Как узел читает архив¶

Узел записывает архив в обычные файлы в каталоге хранилища и читает их обычным чтением файлов. Поэтому каждое чтение архива проходит через кеш страниц Linux: повторное чтение тех же сегментов отдаётся из оперативной памяти, без обращения к диску. Оперативная память — первый и бесплатный уровень кеша; узлу для этого ничего настраивать не нужно.

Из памяти почти без обращений к диску отдаются:

просмотр со сдвигом (timeshift) и с начала передачи в пределах примерно получаса–часа от прямого эфира: эти сегменты только что записаны и ещё лежат в кеше;
популярные передачи и события, которые одновременно смотрят сотни зрителей: диск читает такой сегмент один раз, остальные зрители получают его из памяти;
свежий catch-up вчерашнего прайм-тайма, который смотрят повторно.

Длинный хвост (разные каналы и дни архива, каждый из которых смотрят немногие) в память не помещается и читается с дисков. Linux дольше держит страницы, прочитанные несколько раз, а разовые просмотры вытесняются потоком записи за полчаса–час. Поэтому при архиве в десятки терабайт и широкой аудитории память снимает с дисков, как правило, от четверти до трети чтений: она ускоряет самое горячее, но не заменяет производительность дисков.

2. Оценка нагрузки и выбор дисков¶

Запись, объём и чтение¶

Три величины считаются так:

Поток записи = число записываемых каналов × суммарный битрейт всех вариантов канала. Например, 150 каналов по 8 Мбит/с (три варианта качества) — 1200 Мбит/с, то есть 150 МБ/с непрерывной записи.
Объём архива = поток записи × глубина хранения. 150 МБ/с — это около 13 ТБ в сутки, 7 суток — около 91 ТБ, 14 суток — около 182 ТБ полезного места, без учёта RAID.
Поток чтения = одновременные зрители архива × средний битрейт просмотра. Число зрителей архива — это пиковая доля одновременных зрителей, умноженная на долю тех, кто смотрит архив, а не прямой эфир. Например, 10 000 абонентов, в пике 30 % у экранов и 30 % из них в архиве — 900 зрителей; при 4 Мбит/с в среднем это 3,6 Гбит/с, около 450 МБ/с чтения.

К потоку чтения с дисков прибавляется поток записи: диски обслуживают оба одновременно. Часть чтений снимает оперативная память (1. Как узел читает архив).

HDD и SSD¶

Каждый зритель архива — отдельный последовательный поток чтения, а сотни таких потоков вместе для диска выглядят как произвольный доступ крупными блоками.

HDD (NL-SAS или SATA 7200 об/мин) при многих одновременных потоках отдаёт, как правило, 60–100 МБ/с на диск, если упреждающее чтение крупное (4. Настройка системы). Стоимость терабайта у HDD самая низкая.
SSD NVMe отдаёт гигабайты в секунду, произвольный доступ ему не мешает. Терабайт стоит в несколько раз дороже. Ресурс записи указывают в DWPD — сколько полных объёмов диска в сутки можно записывать весь гарантийный срок. Для архива его считают так: суточный объём записи ÷ суммарная ёмкость дисков. 13 ТБ в сутки на восемь дисков по 15,36 ТБ — около 0,1 DWPD, с запасом даже для дисков на 1 DWPD.

Пример для архива 7 суток (около 91 ТБ): RAID 6 из десяти HDD по 20 ТБ даёт 160 ТБ полезного места и порядка 500–800 МБ/с суммарного чтения. Этого хватает на сотни одновременных зрителей архива вместе с записью. Когда зрителей архива больше тысячи, такой массив работает на пределе: нужны ещё диски, SSD-кеш (3. SSD-кеш средствами ОС) или массив из SSD.

Выбор RAID и общие рекомендации¶

RAID 6 — основной выбор для больших массивов HDD: восстановление после замены диска на 20 ТБ идёт долго, и RAID 6 переживает отказ второго диска за это время. RAID 5 на дисках такого размера не рекомендуется.
RAID 10 даёт больше производительности на смешанной нагрузке, но только половину ёмкости.
Для массивов SSD подходят RAID 5, RAID 6 или RAID 10: время восстановления у них намного короче.
На один диск или массив — одно хранилище (Хранилища DVR).
Ориентиры по выбору:
- до примерно тысячи одновременных зрителей архива — массив HDD (RAID 6 или RAID 10) и 256–512 ГБ оперативной памяти под кеш страниц;
- больше зрителей или архив на 30–90 суток с активным catch-up — HDD для ёмкости и SSD-кеш для последних суток, либо распределение каналов по нескольким узлам;
- массив только из SSD — когда место в стойке, энергопотребление или очень высокая нагрузка важнее стоимости терабайта.

3. SSD-кеш средствами ОС¶

Узлу SSD-кеш ничем не мешает и ничего не требует: узел читает и пишет файлы, а кеш стоит ниже файловой системы (блочный уровень) или внутри неё. Порядок по силе эффекта: сначала оперативная память (кеш страниц), затем SSD для горячих данных следующих одного-двух суток (обычно 2–8 ТБ NVMe), затем HDD для ёмкости.

Сквозная и отложенная запись¶

Сквозная запись (writethrough) — рекомендуемый режим для архива. Запись идёт сразу на HDD, SSD держит часто читаемые блоки. Отказ SSD не теряет данных: массив продолжает работать без кеша.
Отложенная запись (writeback) держит на SSD и свежую запись, что ускоряет timeshift и свежий catch-up. Но ещё не перенесённые на HDD данные пропадают вместе с SSD, поэтому кеш в этом режиме ставят только на зеркало из двух SSD (RAID 1), и он расходует ресурс записи SSD.
dm-writecache кеширует только запись и чтение архива не ускоряет; для архива он не подходит.

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

lvmcache (dm-cache) — основной вариант для систем на основе RHEL, где он поддерживается штатно. Кеш — это логический том на SSD, подключённый к тому архива в той же группе томов. Политика по умолчанию (smq) переносит на SSD блоки, которые читают повторно, поэтому разовые просмотры кеш не засоряют. Подключить и отключить кеш можно на работающем томе, без остановки записи.

В примере архив лежит на томе vg_dvr/dvr (массив HDD), SSD — /dev/nvme0n1. Добавить SSD в группу томов и создать на нём том кеша:

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

Подключить кеш в режиме сквозной записи:

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

Проверить режим и статистику попаданий:

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

Отношение cache_read_hits к сумме попаданий и промахов — доля чтений, которые отдаёт SSD. Отключить кеш: --splitcache оставляет том кеша для повторного подключения, --uncache удаляет его; данные архива остаются на HDD в обоих случаях. В старых версиях LVM (например, в RHEL 7) нет --cachevol: там том кеша сначала превращают в пул (lvconvert --type cache-pool) и подключают с --cachepool.

sudo lvconvert --splitcache vg_dvr/dvr

bcache: Debian и Ubuntu¶

bcache входит в ядро Linux и распространён на Debian и Ubuntu; в RHEL он не поставляется. Он создаётся на пустых устройствах: на существующем массиве с архивом его не включить без переноса данных. Файловая система создаётся уже на устройстве /dev/bcache0.

В примере массив HDD — /dev/md0, SSD — /dev/nvme0n1. Создать устройство с кешем (по умолчанию в режиме сквозной записи):

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

Главная настройка для архива — sequential_cutoff. По умолчанию bcache пропускает мимо кеша последовательное чтение и запись крупнее 4 МБ, а каждый зритель архива — как раз последовательный поток, так что с настройкой по умолчанию кеш почти ничего не хранит. Выключить порог:

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

Это значение не сохраняется после перезагрузки: задайте его при загрузке, например правилом udev или службой systemd. Проверить режим и долю попаданий:

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

ZFS: ARC и L2ARC¶

В ZFS (пакеты OpenZFS) роль кеша страниц играет собственный кеш в памяти — ARC, а SSD подключается к пулу как второй уровень кеша — L2ARC. L2ARC кеширует только чтение; отказ SSD данных не теряет. Подключить SSD к пулу dvr:

sudo zpool add dvr cache /dev/nvme0n1

По умолчанию L2ARC не принимает данные, прочитанные упреждающим чтением, то есть последовательные потоки зрителей архива. Для архива это нужно выключить и тоже сохранить для следующих загрузок:

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

Ещё несколько настроек для архива:

recordsize=1M для набора данных с архивом — архив состоит из крупных файлов, которые читаются целиком;
atime=off — без записи времени доступа при каждом чтении;
zfs_arc_max — предел памяти под ARC; оставьте памяти и узлу;
l2arc_write_max — скорость наполнения L2ARC; значение по умолчанию невелико, и при большом архиве кеш наполняется медленно.

Статистику ARC и L2ARC показывает arc_summary, нагрузку на устройства пула — zpool iostat -v dvr 5.

4. Настройка системы¶

Упреждающее чтение. Для массива HDD задайте крупное упреждающее чтение, например 4 МБ (8192 сектора по 512 байт); оно сохраняется до перезагрузки, поэтому задайте его и при загрузке (правилом udev). Для тома LVM то же задаёт lvchange --readahead.
```
sudo blockdev --setra 8192 /dev/md0
sudo blockdev --getra /dev/md0
```
Память под кеш. Кеш страниц занимает всю свободную память, поэтому оставьте узлу запас: не запускайте на нём других прожорливых процессов и не допускайте, чтобы система уходила в своп. Возврат неиспользуемой памяти узлом описан в Память.
Файловая система. Подходят XFS (по умолчанию в системах на основе RHEL) и ext4. Монтируйте хранилище с noatime, чтобы чтение архива не порождало записи времени доступа.
Наблюдение. Нагрузку на диски показывает iostat -x 5 (столбцы чтения и записи в МБ/с, время ожидания, загрузка устройства). Объём кеша страниц показывает строка buff/cache в выводе free -h, попадания SSD-кеша — команды из разделов выше. Задержки чтения и записи архива по потокам показывает экран «Монитор DVR» (Монитор DVR), а при долгих чтениях и записях поднимается алерт кода 50 (dvr-rw-time, Перечень алертов).