TrueNas: когда Nas реально ТРУ

Задача:

Без больших трат, желательно используя то, что уже есть, получить адекватную скорость для хранилища бекапов (SQL, бекапы ESXi машин), сетевых дисков iSCSI и хорошую сетевую папку для ~50 пользователей с настройкой прав доступа на основе AD. В идеале, чтобы когда пользователь работает с поиском через проводник в сетевой папке, скорость не отличалась от поиска на локальном диске.

Что имеем:

Сервер с быстрыми в своё время процессорами, который сейчас оказался не у дел. Продавать его за гроши на барахолке смысла нет, а вот придумать ему разумное применение, почему бы и да!

Сейчас у кого-то начинает дёргаться глаз от этой солянки из серверного и откровенно домашнего железа. В разделе о файловой системе будет объяснение, почему такая конфигурация имеет право на жизнь. Ну и не забываем про задачу использовать то, что есть в наличии.

Что по деньгам:

Если собирать что-то подобное с нуля, то шасси сервера можно найти Б/У начиная от 14000 руб, процессоры с 6 ядрами около 600 рублей за штуку на Али (при этом в Б/У шасси уже часто стоят вполне нормальные CPU на 4-6 ядер). Память тоже на Али по цене около 1000 рублей за 8Gb. Мы много раз докупали память для серверов на Али и пока что брака не встречали. Но чтобы не терять время, всегда берём чуть больше планок, чем нам надо, чтобы в случае брака сразу иметь замену.

HDD мы покупали прям перед волной популярности Chia, когда цены на них ещё не превысили планку адекватности. Покупали диски SATA для QNAP хранилища (наши QNAP не умели в SAS). Но когда на первичную синхронизацию RAID5 массива из 4-х 3Tb дисков ушло больше суток, поняли, что надо искать альтернативу. Поэтому, что было куплено, то и решили использовать в TrueNas. Искать другие новые диски в мае 2021 года было бессмысленно.

В нашем случае докупили RAM и загрузочный SSD примерно на 3000 рублей, что соответствует ТЗ: потратить как можно меньше.

Да, итог в 70 килорублей это поболе, чем воткнуть внешний HDD за 2500р в Keenetic и включить галочку CIFS/SMB в Web интерфейсе. Но давайте посмотрим, что мы получаем.

Сначала минимум теории:

Итог применения ZFS №1: почему можно использовать SATA диски

В отличие от SATA, SAS поддерживает проверку контрольных сумм при записи данных, поэтому он является более предпочтительным для использования в корпоративном секторе, где сохранность данных намного важнее, чем дома (общий случай).

Так как ZFS поддерживает контрольные суммы на уровне файловой системы, то можно использовать более дешёвые SATA диски без глобальных проблем с надёжностью (конечно с оглядкой на более низкую скорость полудуплексного SATA и прочих упрощений этого интерфейса относительно SAS).
Коротко: SAS круче, но ZFS позволяет обходиться более дешёвыми SATA дисками.

Итог применения ZFS №2: нужно больше золота больше оперативки

Крайне желательно ECC. Минимумом по системным требованиям является 8Gb, но и на 4Gb стартует, на меньшем объёме не тестировал. Система всегда занимает всю свободную оперативку под кэш ZFS и чем её больше изначально, тем лучше (в пределах разумного).

Итог применения ZFS №3: нужно резервировать место на дисках

Из-за принципа работы, файловой системе всегда нужно свободное место на дисках для манёвра. Поэтому при создании пула резервируются минимум 20% свободного места. И это помимо того, что мы теряем объём одного диска из-за отказоустойчивости RAIDZ1! УЖАС! (на самом деле нет)

Как проводили тесты перед запуском:

Перед внедрением надо было провести тесты, чтобы изучить незнакомую технологию и знать, как она поведёт себя в бою. Особенно если учесть, что раньше мы с этим не работали. И хотя это не единая точка отказа всего бизнеса, и цена данных не такая, чтобы покупать многомилионные СХД, устраивать бета тестирование на пользователях не было желания.

Что мы проверили:

1. Выдёргивание дисков из сервера на горячую, во время передачи данных (во время тестирования использовали RAIDZ2, поэтому пул выдерживал выдёргивание двух дисков, по итогу остановились на RAIDZ1 для увеличения доступного места). Этим тестируем физическое умирание дисков (в TrueNas используется термин пул, а не массив, как в случае с RAID).

2. Подключение дисков назад в пул и их синхронизация.

3. Восстановление конфигурации из бекапа в случае умирания загрузочного SSD.

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

5. Введение и выведение из домена.

6. Обновление версии TrueNas. То есть мы специально поставили более старую версию, а потом обновили до актуальной, чтобы не было сюрпризов.

Что получили по итогам тестирования (по пунктам):

1. При выдёргивании дисков скорость не просела ни на 1 Mb/s, потому что и так упиралась в сетевой интерфейс (1Gbit/s).

2. Подключение дисков назад в пул в нашем случае невозможно без перезапуска сервера. Это особенность RAID контроллера, который не умеет работать с дисками иначе, кроме RAID конфигураций. Поэтому пришлось размечать диски как 6 RAID0 массивов с 1 диском в массиве. Сам TrueNas подключение на горячую поддерживает. После пересоздания RAID0 массива из выдернутого диска, он появляется в системе и начинается синхронизация пула, которая в нашем случае не повлияла на скорость проводившихся тестов (у сервера получился большой запас по мощности). Не так, как хотелось бы, но терпимо. Если умер диск, мы можем дотянуть до ночи и поменять ночью. Если умрёт сразу 2, забираем дополнительные бекапы критических данных с QNAP, которые делаются по rsync, об этом дальше.

3. Снесли систему с SSD, установили заново и подали файл конфигурации в нужное меню. Без сюрпризов.

4. Никаких проблем с разваливанием пула или чем-то подобным. Выдёргивали питание при загрузке/работе/завершении работы. Проблем не возникло.

5. Делается за пару минут. Проблема в том, что после перезагрузки TrueNas получается как бы в домене, а как бы и нет. Приходится выводить его и заводить заново. Починили в версии 12.0 U8 (последняя из 12 версии. Сейчас актуальная 13, но с пометкой “Community Release Only - Not Enterprise Supported.”)

6. Ни разу не получали проблем с этим ни при тестировании, ни при обновлении в бою.

Дополнительные функции TrueNas

Виртуальные машины

На TrueNas можно запускать полноценные виртуальные машины. По сути это FreeBSD с оболочкой, так что тут всё не сильно отличается от запуска виртуалок на любом другом linux. Сфера применения в нашем случае сомнительна, так как рядом есть сервера на ESXi. Но если это единственный сервер, или домашний сервер, то можно запустить внутри, например, veeam backup на windows, который будет в привычном интерфейсе забирать бекапы с компов в сети внутрь TrueNas.

Jail контейнеры

Jail в FreeBSD это механизм виртуализации, при котором используется ядро хостовой ОС (аналог OpenVZ). Есть свой репозиторий, в котором куча удобных настроенных Jail’ов (Plex, Transmission, Zabbix Server, OpenVPN Server, и т.д.). Лично мне приглянулся NextCloud. Если совсем упороться, можно поднять свой "Google Photo" с распознованием лиц на фотографии. Но нужна карточка с CUDA.
UPD: как заметил @unC0Rr, CUDA не работает в FreeBSD, так что без дополнительных прослоек распознавать лица не получится именно из jail плагина.

Rsync с TrueNas на QNAP

По расписанию особо важные данные синхронизируются с простеньким QNAP. Из коробки настройка rsync между двумя TrueNas не должна вызвать вопросов, но в нашем случае (rsync  TrueNas > QNAP) пришлось пользоваться велосипедом с подсовыванием в аргументах задания txt файла с паролем на учётку для синхронизации. Есть ещё способ с ключами, но нужна адекватная поддержка с принимающей стороны, а QNAP у нас самый простенький (D4 первой ревизии). Если что-то пошло не так, в почту прилетает уведомление.

Приятные бонусы, которые мы получили

Большое сжатие баз SQL

Так как ZFS всегда “пишет вперёд”, это позволяет на лету сжимать данные. Даже при использовании стандартных настроек (lz4 без дедупликации), мы получили замечательные результаты. Бекапы баз 1С (Microsoft SQL) сжимаются более чем в 3,5 раза! То есть те 20%, что резервируются для полноценной работы файловой системы тут же с лихвой отыгрываются при хранении баз данных. Понятно, что это не применимо к уже сжатым данным, например фото, видео, или бекапы Veeam, там выигрыш составляет 0-5%.

Скриншот пула

Примерный расчёт, сколько места мы получили бы при RAID5 в EXT4 и при RAIDZ1 в ZFS:

RAW space: 6*2,73Tb = 16,38Tb

RAID5: (6-1)*2,73Tb = 13,65Tb

RAIDZ1: (6-1)*2,73Tb - 20% = 10,92Tb

Сейчас у нас занято 6,07Tb с компрессией 2,01, или 12,2Tb без компрессии!
То есть в случае с RAID5 свободно осталось бы 1,45Tb, а в случае RAIDZ1 свободно 4,85Tb (Свободный объём на скриншоте указан без учёта -20%). А при нашем сценарии использования это почти 4,85*2!

Snapshot в ZFS

Создание snapshot происходит мгновенно. Потом мы можем увидеть эти снимки в разделе "предыдущие версии" прямо в проводнике windows, если речь о SMB, или создать новый том из снимка, если это том для iSCSI.

Предыдущие версии на основе снимков в проводнике

Плюсы и минусы

Начну с плюсов

• Это БЫСТРО! Если говорить о SMB, то скорость передачи всегда упирается в сетевой интерфейс, а переназначение прав на папки с тысячами файлов занимает секунды (а не десятки часов(!), привет QNAP'у D4). Поиск по папкам происходит достаточно быстро, чтобы пользователи не замечали разницы между локальной папкой и сетевой, проверено (но понятно, что на системном SSD на рабочих станциях ищет быстрее).

• Это достаточно быстро, чтобы держать тестовые базы 1С на 100+ Gb на iSCSI и не страдать. Да, это медленнее, чем SAS диски на 15000rpm, подключенные напрямую в основных серверах, но для тестов хватает.

Пример производительности при подключении тома по iSCSI

• Удобная настройка расписания создания и удаления периодических snapshot. Теперь мы храним множество снимков: от ежедневных вплоть до полугодовых (с разной длительностью хранения).

• 2 блока питания в сервере позволяет подключить его к разным ИБП и свести проблемы с выключением по питанию практически к нулю.

• Это полноценный сервер и мы имеем управление через iDRAC, что даёт ещё больше контроля удалённо.

• Пока что ни один диск не отвалился, но на будущее неожиданным плюсом стало то, что купить запасные диски домашнего сегмента из-за проблем с доставкой в 2022 году оказалось намного реальнее, чем серверные SAS (по крайней мере в наших краях).

Минусы

• Сеть 1Gbit/s. Но можно установить другую сетевую карту, или объединить несколько карточек из 4х для суммирования скорости.

• Для настройки иногда приходится лезть в командную строку, что может быть проблемой для людей не знакомых с linux (да ещё и часть команд отличается от debian-based linux типа Ubuntu).

• Это сервер и он ШУМНЫЙ! У нас он и так был установлен в серверной, но если отдельного помещения нет, то использовать 2U сервер в тихом офисе не лучшая идея.

• QNAP D4 потребляет около 30Вт в работе. Тут же мы имеем среднее потребление порядка 180-200Вт судя по панели сервера при типичной для наших задач нагрузке. Мощность процессоров явно избыточна для простого, пусть и быстрого NAS и можно брать процессоры попроще, или с пониженным потреблением, если нет цели гонять кучу плагинов в Jail или виртуалок.

Итог

Не стоит воспринимать этот кейс пример как единственно правильный. Тут много условностей, которые в другом случае стали бы критичными. Но для себя мы нашли такую конфигурацию, пожалуй, лучшей на данный момент. Если у вас есть интересные случаи применения TrueNas, или советы по улучшению описанной конфигурации, будет интересно почитать.

Не могу не рассказать о великолепном канале о TrueNas: LawrenceSystems. Очень много полезной и просто интересной информации о FreeNas/Truenas