А если все таки разобраться? :) Если zpool будет больше 1PB, то как будет жить второй сервер?

Привет всем. #вопрос: Нормально ли использовать FreeNas с огромным объемом RAM, SSD под SLOG и включенной дедупликацией на одном сервере, и при этом делать бэкапы в другой FreeNas/чистый ZFS с ресурсами на несколько порядков скромнее? Собственно вопрос наверно в том, как будет работать при этом дедупликация и сжатие? Умрет ли второй сервер от требуемого RAM для дедупликации большого zpool или zfs как-то умеет "перекидывать" DDT между своими "братьями"? В целом, хотелось бы услышать, как правильно организовать подобную схему? Данных много, один сервер боевой (с большим кол-вом ресурсов), второй только для бэкапа и восстановления с него (не для пользовательской нагрузки). Спасибо!

У zfs send есть ключи для передачи данных "как есть на диске" в сжатом или дедуплицированном виде, по идее они не должны жрать ресурсы на сервере-приёмнике, потестите. Ddt в памяти нужен только для записи, т.е. На чтении много озу вам для него может не понадобиться

Отлично. А вот еще момент, принципиальный. Что лучше с FreeNas(FreeBSD) связываться или все таки на Debian(Linux) пробоваться с ZFS?

Что больше нравится, в общем то. если соберёте пул с features, совместимыми с обоими - сможете легко поменять.

Там практически на каждый чих ключик есть, шифрование вообще нативное классно сделали - можно передавать на сервер-приёмник без ключа на нём, а потом и целостность проверять без ключа, raw режим передачи. Осталось подождать пока перформанс шифрования поднимут, там патчики уже есть, на aes-gcm перейти хотели

стремно что периодически вываливаются issue с репликацией, то write holes, то с шифрованием корраптилось, даже недавно файлы при копировании становились нулевыми, но вроде все фиксится, только релизится потом долго)

@gmelikov кстати ты недавно упоминал, что тебе подход sanoid не нравится, можно узнать почему?

- Не удобно в конфиге задавать, мне больше нравится проперти у датасетов и не хватает возможности игнорить конкретные датасеты (т.е. Наоборот всё, кроме конкретного) - поставка не удобная, по сути ни два ни полтора - не атомарные рекурсивные снапшоты

как это невозможно

я делаю рекурсивные снапшоты и рекурсивную репликацию и там и там эксклюд возможен

каким снапшотам?)

а не атомарные имеется ввиду, что он делает не zfs snap -r ?

ну с одной стороны конфиг неудобно, а с другой там в нем удобные темплейты

я думал в зфс это тоже не атомарно будет, чисто для удобства опция

но если делать snap -r тогда эксклюдить тоже не получится

синкойд по идее вообще любые снапшоты умеет юзать

ну он сам досоздаёт свои

надо им предложить такую возможность запилить

можно без, я использую на сущестующих

мне у других не нравится отсутствие всяких _hourly _daily и остальных приписок

из плюсов только возможность по тцп гонять, но с хардварным шифрованиеп по ssh и тк больш 5 gbit просасывает(быстрее писать не смогло)

А у этих для заббикса даже есть https://github.com/psy0rz/zfs_autobackup#monitoring-with-zabbix-jobs

я для заббикса какраз свое накатал н основе _daily _hourly и кроме снапшотов отслеживалку старых ручных и прочих жизненных параметров и статистик зфса )

Там практически на каждый чих ключик есть, шифрование вообще нативное классно сделали - можно передавать на сервер-приёмник без ключа на нём, а потом и целостность проверять без ключа, raw режим передачи. Осталось подождать пока перформанс шифрования поднимут, там патчики уже есть, на aes-gcm перейти хотели

А можно поподробнее пожалуйста, при включённом шифровании в проц упирается

Что за патчи, нагуглить не удалось

кое-кто тестировал ZFS на большой базе (в конце поста). https://habr.com/ru/company/citymobil/blog/492172/

кое-кто тестировал ZFS на большой базе (в конце поста). https://habr.com/ru/company/citymobil/blog/492172/