zfs raidz2 vs ZFS stripe + mirror (raid 10) на 8ми дисках (CCTV)

Зачем ты плодишь однотипные треды? Тебе уже в предыдущем треде уже сказали про производительность RAIDZ. И stripe в этой конструкции влиять если и будет, то точно не в лучшую сторону.

Дополню мысль предыдущего оратора: ты будешь писать с нескольких камер в один пул? Значит у тебя несколько процессов будут конкурировать на запись, плюс будет фрагментация, которая сильно заметна на несжимаемых (а видео жмётся крайне плохо и очень дорого по ресурсам) данных на медленных (в сравнении с SSD) HDD. То есть ты проигрываешь в скорости как на чтение, так и на запись.

Я бы сделал пачку RAID-10 (mirror+stripe) из цельных дисков (без деления на разделы) и эти отдельные пулы использовал на меньшее количество камер (а монтировать можно в какие-нибудь /media/cam/00-04, /media/cam/05-09 и так далее. В плане распределения места, если у тебя все камеры работают круглосуточно (без датчика движения), то место будет расходоваться плюс-минус одинаково (зависит от освещённости помещений).

Зачем ты плодишь однотипные треды?

Это совершенно разные треды. В первом я интересовался raid 6 vs raid 60. Тут, про raid 10 vs raid6. Везде, везде в Интернете пишут, что для cctv must have raid6(+0). И редко где пишут про raid10. По-этому, решил создать отдельный тред.

Дополню мысль предыдущего оратора: ты будешь писать с нескольких камер в один пул?

Более 100 штук!

Значит у тебя несколько процессов будут конкурировать на запись, плюс будет фрагментация, которая сильно заметна на несжимаемых (а видео жмётся крайне плохо и очень дорого по ресурсам) данных на медленных (в сравнении с SSD) HDD. То есть ты проигрываешь в скорости как на чтение, так и на запись.

Имеется ввиду всё не в пользу raid6? Лучше 10ый?

Я бы сделал пачку RAID-10 (mirror+stripe) из цельных дисков (без деления на разделы) и эти отдельные пулы использовал на меньшее количество камер (а монтировать можно в какие-нибудь /media/cam/00-04, /media/cam/05-09 и так далее. В плане распределения места, если у тебя все камеры работают круглосуточно (без датчика движения), то место будет расходоваться плюс-минус одинаково (зависит от освещённости помещений).

Именно так и хочу в душе сделать. Мой видео софт позволит даже программным образом делать raid10, т.е. мне будет достаточно пачки raid1. Но, блин, везде в Интернет, пишут, что raid6 для cctv… А я никогда такое не делал. Проще 1+0 или 1. Вот и сомневаюсь. По-этому спрашиваю. :)

Официально, один диск может записывать до 64 камер. Но, в эту цифру я не верю. Если я сделаю отдельные зеркала, или 1+0, полагаю, на таком кол-ве дисков, у меня всё колом не встанет при пересборке массва. А вот на raid6, всей этой истории в момент пересборки массива, кажется, придет писец. Вот такие мысли…

Именно так и хочу в душе сделать.

Не надо в дýше ничего делать

Имеется ввиду всё не в пользу raid6? Лучше 10ый?

По скорости RAIDZ медленнее mirror. Вне зависимости от наличия или отсутствия stripe в конструкции.

ввиду

Внутривенно? (%

Именно так и хочу в душе сделать.

В душе замкнёт, там влажность высокая.

Более 100 штук!

Не многовато более ста камер для одного душа?

raid6 для cctv

Потому что для видеонаблюдения место важнее скорости. Скорость можно нивелировать огромными кэшами, но оперативка нынче дороже диска.

Проще 1+0 или 1.

У тебя куча камер, потому лучше меньшие пулы делать для распределения нагрузки на диски. То есть много маленьких mirror, чем большие mirror+stripe.

Официально, один диск может записывать до 64 камер. Но, в эту цифру я не верю.

Может. За счёт кэшей. В синтетике. И точно не в RAIDZ. ☺

Спасибо огромное! Всё чётко и понятно.

Подскажи, пож-та: зависит ли zfs speed up resilver от volblocksize расположенного на нем zvol? Сейчас делаю пересборку массива, диск подох. Так вот, в массиве zvol с volblocksize 8k. Скорость пересборки 10 мегабайт в секунду, нагрузки внешшней никакой нет. Всё отключил. zpool iostat показывает 500 iops на запись… Предполагаю, что такая низкая скорость пересборки и такой большой iops, вызвано тем, что очень маленький размер блока в zvol. Прав или нет? :)

зависит ли zfs speed up resilver от volblocksize расположенного на нем zvol?

Отчасти. volblocksize, считай, это logical block size. Чем он выше — тем больше чанки при чтении, со сжатием можно добиться неплохих результатов. А с записью от задачи зависит. Обычно рекомендую начинать с (2^ashift)*2 (ashift==12 → volblocksize=8K) и плясать в большую сторону.

Но я не могу понять зачем тебе для CCTV нужно бить в zvol, это же лишняя абстракция. А если ты туда ещё и журналируемую ФС накатил… Или оно в виртуалке? Тогда дешевле (по ресурсам) прокинуть туда диски как есть, и уже там развернуть ZFS.

Скорость пересборки 10 мегабайт в секунду, нагрузки внешшней никакой нет.

Начни отсюда.

Спасибо огромное за ответ по существу.

Но я не могу понять зачем тебе для CCTV нужно бить в zvol, это же лишняя абстракция. А если ты туда ещё и журналируемую ФС накатил… Или оно в виртуалке? Тогда дешевле (по ресурсам) прокинуть туда диски как есть, и уже там развернуть ZFS.

Да, у меня очень старая CCTV, железо на котром оно работало уже давно вышло из эксплуатации. И пришлось унести её в виртуальную машину. Там Linux+Java+mysql и ядро весьма старое (система назыввается netavis). По-этому, для большей гибкости я сделал zfs и выделил zvol, а внутри уже при помощи патчей сделал ext4, там настолько всё старое, что максимум было ext3 и xfs изначально. xfs сыпалось пару раз в полную кашу. Решил сделать ext4. Работает нормально. Скоро буду менять систему. Но, сейчас в текущей навернулся диск… И из-за крайне медленной репликации, я не могу его заменить. Даже без нагрузки, синхронизация займет десять суток. Что не приемлемо в моём случае, настолько останавливать систему видеонаблюдения. С работающей системой, ничего не выходит, диски перегружены. Java внутри VM падает, так-как ввод вывод крайне печальный. Считаю, что всему виной тут моя невнимательность, допущеная пять лет назад. Я сделал blocksize 8k. Мне видится, что для Linux нужно оставить 8k, для mysql сделать 16к (+ SSD, как это и сейчас есть zlog), для данных: 128k - там java в каком-то своём формате пишет архивы по паре гигабайт в одном куске. Вот мне видится, что если бы я так изначально сделал, у меня синхронизация была бы много быстрей, и нагрузка на диски намного ниже. - Как считаете? Сейчас у меня zfs 0.7.2, по-этому, полагаю синхронизация такая медленная. Спасибо за ссылку.

Вот для новой CCTV, я думаю, что лучше: TrueNAS или аппаратный СХД? Новая система, не поддерживает большие разделы для архивов. Боольше 18 ТБ в одном разделе, уже будут тормоза. По-этому, я думаю, может быть поставить TrueNAS, дальше сделать zvol и порезать как надо. - Вот думаю, стоит так делать или нет…

Решил сделать ext4.

Зачем тебе журналируемая файловая система для системы наблюдения?

Для самой ОС это оправдано, да, но именно для файлохранилки чем проще файловая система внутри zvol, тем меньше проблем.

+ SSD, как это и сейчас есть zlog

В твоей ситуации полезнее будет L2ARC (cache). Ящитаю.

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

Проблема комплексная. Для начала я бы прикрутил L2ARC на SSD, что снизит нагрузку на медленные HDD, прикрутил сжатие в зависимости от типа данных (для баз данных и медии, которую пишет CCTV, можно обойтись lz4 или даже lzo, потому что выигрыш будет ≈1M на ≈1G, то есть 1:1000, в лучшем случае — 1:800), саму ОС хоть в gzip (gzip-3, больше не надо). Всё это, разумеется, на стороне гипервизора (хостовой ZFS).

И каждый шаг желательно тестировать, ибо перетюнить иногда хуже чем недотюнить.

Сейчас у меня zfs 0.7.2

Помнится, в 0.7.x было немало проблем, потому имеет смысл обновиться хотя бы на 0.8.x, а лучше на актуальную 2.x (не знаю какая сейчас актуальна+стабильна, во FreeBSD 13.2-RELEASE поставляется zfs-2.1.9, git hash 92e0d9d18, со своими патчами поверх ZoL).

TrueNAS или аппаратный СХД?

TrueNAS выглядит надёжнее в долгосрочной перспективе. Как в плане возможности обновления, так и в плане переноса storage на другой TrueNAS/FreeBSD или Linux с ZFS (посредством send/recv) с минимальным даунтаймом.

сделать zvol и порезать как надо

Я бы скормил диски под CCTV целиком. Ну или, если vtnet(4) прокачает столько камер, можно даже NFS.

я бы прикрутил L2ARC на SSD

Зачем ему L2ARC, если он будет постоянно писать видео? Ну и сжатие соответственно тут вредно.

Зачем ему L2ARC, если он будет постоянно писать видео?

У него там Java с MySQL (читай тред), которые делят I/O с CCTV.

Ну и сжатие соответственно тут вредно.

С lz4/lzo оверхед в пределах погрешности… как и экономия места. ☺

Привет!

Итог:

Под ОС и СУБД сделал: 16k блок (знаю, что под ОС надо бы 8k, но, пока решил так) под видео сделал 128k. На старых данных посыпались диски, пока массив жив (убрал в архив), создал новый. Прицепил log (но, он и раньше был - но, сейчас, fsync данные явней стали видны в нем). - Итог: la упал с 20 до 1. Программа показывает нагрузку на диск: 2%, вместо 100% как было до этого. iops с 250 на диск упал до 20ти. Итого: нагрузка на систему уменьшилась в десять раз. Система чилит с кучей камер (на этой машине их 50, но там не все fullhd). Всё живет на raid1 (раньше было на raid10)! Да, пока нет фрагментации и т.п., будет потом, конечно хуже, но… Видео клиент перестал лагать. Пока всё летает. И это при том, что у меня ОЗУ там просто нету). Ещё потюнил настройки самой виртуалки. - Сделал отдельный тред на io для видео, и поменял контроллер с LSI на virtio single

знаю, что под ОС надо бы 8k

В ZFS@ZFS можно и 8K, в остальных случаях можно даже 4K.

Итог: la упал с 20 до 1. Программа показывает нагрузку на диск: 2%, вместо 100% как было до этого. iops с 250 на диск упал до 20ти. Итого: нагрузка на систему уменьшилась в десять раз.

Правильно, потому что у тебя теперь чанки читаются один раз по 128K, а не шестнадцать раз по 8K. Тебе же не надо объяснять про очередь ядра? ☺

поменял контроллер с LSI на virtio single

Я вообще не доверяю хардварным RAID…

Правильно, потому что у тебя теперь чанки читаются один раз по 128K, а не шестнадцать раз по 8K. Тебе же не надо объяснять про очередь ядра?

Привет! Блин, даже до этого не додумался, что ещё ведь и очередь ядра… Спасибо, прямо супер комменты! Итоговым результатом очень доволен, буду собирать новую полку, под новый софт для видео.

Я вообще не доверяю хардварным RAID…

Не, не… - Речь идет о виртуализованном дисковом контроллере в proxmox. Как я так прокосячил, даже не знаю. В общем, все сделал согласно лучшим практикам настройки виртуальной машины. Результат до сих пор, эпично хорош! Более чем в десять раз ниже нагрузка.

результатом очень доволен

:3

// Приглашаю присоединиться к нашему небольшому сообществу. ☺

TrueNAS выглядит надёжнее в долгосрочной перспективе.

UPD: Пощупал свежую TrueNAS, ну его нахер, оно упоролось!

Лучше взять ClonOS/MyBee (последнее — проприетарщина, имей в виду; ну а первое до сих пор далеко от продушкн-реяди, но уже, говорят, юзабельно).

Привет! Понял! Спасибо! Пока я хочу попробовать свой любимый proxmox - мне нужно, посмотреть есть ли на ZoL возможность делать hotspare шаренный. - На FreeBSD, есть, но, в TrueNAS не реализовано. Плюс, я хочу на уровне proxmox сделать и zil для всех томов из разделов SSD небольших. Опять-же, TrueNAS, мимо. Я сделаю: raid1, 5 шт. - А на эти raid1, данные, уже программны образом буду раскладывать видео - это trassir умеет. Ну и подниму postgresql для trassir. Пока такой план.