Предыстория, можно пропустить
Как то раз надо было быстро создать iSCSI диск для тестирования Fault Tolerance в ESXi. Быстрый гуглёж показал, что есть такая штука, как FreeNas, которая уже TrueNas. Установил по мануалу. Так и не смог понять, почему при создании пула съедался заметный процент объёма диска, но было не до этого. Тестирование провёл, виртуалки удалил. А через небольшой промежуток времени на работе стало не хватать скорости двух NAS от QNAP (один старый, другой изначально убогий). Вот тогда, глядя на недавно потушеный за ненадобностью Dell R710 с корзиной на 6 sata/sas 3.5” дисков и вспомнили, что есть же какой-то TrueNas, который почему-то хвалят.
По сути это рассказ о том, как от состояния “первый раз услышаю об этом” до внедрения прошло пару месяцев. Поэтому тут будут как технические детали, так и совсем очевидные моменты, с которыми мы столкнулись.
Задача:
Без больших трат, желательно используя то, что уже есть, получить адекватную скорость для хранилища бекапов (SQL, бекапы ESXi машин), сетевых дисков iSCSI и хорошую сетевую папку для ~50 пользователей с настройкой прав доступа на основе AD. В идеале, чтобы когда пользователь работает с поиском через проводник в сетевой папке, скорость не отличалась от поиска на локальном диске.
Что имеем:
Сервер с быстрыми в своё время процессорами, который сейчас оказался не у дел. Продавать его за гроши на барахолке смысла нет, а вот придумать ему разумное применение, почему бы и да!
Dell R710
CPU 2x Intel Xeon X5650. 6 core up to 3,06 GHz
RAM 48Gb DDR3 ECC
SSD 256Gb SATA3 загрузочный, вместо DVD привода
HDD 6x 3Tb Toshiba P300 SATA3
RAID controller PERC H700
Блоки питания 2 по 550W
Сейчас у кого-то начинает дёргаться глаз от этой солянки из серверного и откровенно домашнего железа. В разделе о файловой системе будет объяснение, почему такая конфигурация имеет право на жизнь. Ну и не забываем про задачу использовать то, что есть в наличии.
Что по деньгам:
Если собирать что-то подобное с нуля, то шасси сервера можно найти Б/У начиная от 14000 руб, процессоры с 6 ядрами около 600 рублей за штуку на Али (при этом в Б/У шасси уже часто стоят вполне нормальные CPU на 4-6 ядер). Память тоже на Али по цене около 1000 рублей за 8Gb. Мы много раз докупали память для серверов на Али и пока что брака не встречали. Но чтобы не терять время, всегда берём чуть больше планок, чем нам надо, чтобы в случае брака сразу иметь замену.
HDD мы покупали прям перед волной популярности Chia, когда цены на них ещё не превысили планку адекватности. Покупали диски SATA для QNAP хранилища (наши QNAP не умели в SAS). Но когда на первичную синхронизацию RAID5 массива из 4-х 3Tb дисков ушло больше суток, поняли, что надо искать альтернативу. Поэтому, что было куплено, то и решили использовать в TrueNas. Искать другие новые диски в мае 2021 года было бессмысленно.
Актуально на 4й квартал 2022:
Шасси: 14000 рублей
Процессоры: 0-1200 рублей
RAM: 48Gb DDR3 ECC 6000 рублей
Диски: 3Tb SATA 7200rpm 6*8000 рублей
SSD для загрузки: 1500 рублей
Итого 70700 рублей.
В нашем случае докупили RAM и загрузочный SSD примерно на 3000 рублей, что соответствует ТЗ: потратить как можно меньше.
Да, итог в 70 килорублей это поболе, чем воткнуть внешний HDD за 2500р в Keenetic и включить галочку CIFS/SMB в Web интерфейсе. Но давайте посмотрим, что мы получаем.
Сначала минимум теории:
ZFS
Она же “Zettabyte File System”. Это файловая система, которая работает по принципу Copy-On-Write. Тут повторять статью из Wiki нет смысла, поэтому вот она.
RAIDZ
Пул из дисков, отформатированных в ZFS. Цифра после Z означает степень отказоустойчивости. Мы разметили диски в RAIDZ1, поэтому при умирании одного дисков из 6, пул остаётся работоспособным.
Итог применения ZFS №1: почему можно использовать SATA диски
В отличие от SATA, SAS поддерживает проверку контрольных сумм при записи данных, поэтому он является более предпочтительным для использования в корпоративном секторе, где сохранность данных намного важнее, чем дома (общий случай).
Так как ZFS поддерживает контрольные суммы на уровне файловой системы, то можно использовать более дешёвые SATA диски без глобальных проблем с надёжностью (конечно с оглядкой на более низкую скорость полудуплексного SATA и прочих упрощений этого интерфейса относительно SAS).
Коротко: SAS круче, но ZFS позволяет обходиться более дешёвыми SATA дисками.
Итог применения ZFS №2: нужно больше золота больше оперативки
Крайне желательно ECC. Минимумом по системным требованиям является 8Gb, но и на 4Gb стартует, на меньшем объёме не тестировал. Система всегда занимает всю свободную оперативку под кэш ZFS и чем её больше изначально, тем лучше (в пределах разумного).
Итог применения ZFS №3: нужно резервировать место на дисках
Из-за принципа работы, файловой системе всегда нужно свободное место на дисках для манёвра. Поэтому при создании пула резервируются минимум 20% свободного места. И это помимо того, что мы теряем объём одного диска из-за отказоустойчивости RAIDZ1! УЖАС! (на самом деле нет)
Как проводили тесты перед запуском:
Перед внедрением надо было провести тесты, чтобы изучить незнакомую технологию и знать, как она поведёт себя в бою. Особенно если учесть, что раньше мы с этим не работали. И хотя это не единая точка отказа всего бизнеса, и цена данных не такая, чтобы покупать многомилионные СХД, устраивать бета тестирование на пользователях не было желания.
Что мы проверили:
Выдёргивание дисков из сервера на горячую, во время передачи данных (во время тестирования использовали RAIDZ2, поэтому пул выдерживал выдёргивание двух дисков, по итогу остановились на RAIDZ1 для увеличения доступного места). Этим тестируем физическое умирание дисков (в TrueNas используется термин пул, а не массив, как в случае с RAID).
Подключение дисков назад в пул и их синхронизация.
Восстановление конфигурации из бекапа в случае умирания загрузочного SSD.
Отключение сервера из сети питания на разных этапах работы и загрузки, чтобы проверить и знать на будущее, с чем мы можем столкнуться, если ИБП подведёт.
Введение и выведение из домена.
Обновление версии TrueNas. То есть мы специально поставили более старую версию, а потом обновили до актуальной, чтобы не было сюрпризов.
Что получили по итогам тестирования (по пунктам):
При выдёргивании дисков скорость не просела ни на 1 Mb/s, потому что и так упиралась в сетевой интерфейс (1Gbit/s).
Подключение дисков назад в пул в нашем случае невозможно без перезапуска сервера. Это особенность RAID контроллера, который не умеет работать с дисками иначе, кроме RAID конфигураций. Поэтому пришлось размечать диски как 6 RAID0 массивов с 1 диском в массиве. Сам TrueNas подключение на горячую поддерживает. После пересоздания RAID0 массива из выдернутого диска, он появляется в системе и начинается синхронизация пула, которая в нашем случае не повлияла на скорость проводившихся тестов (у сервера получился большой запас по мощности). Не так, как хотелось бы, но терпимо. Если умер диск, мы можем дотянуть до ночи и поменять ночью. Если умрёт сразу 2, забираем дополнительные бекапы критических данных с QNAP, которые делаются по rsync, об этом дальше.
Снесли систему с SSD, установили заново и подали файл конфигурации в нужное меню. Без сюрпризов.
Никаких проблем с разваливанием пула или чем-то подобным. Выдёргивали питание при загрузке/работе/завершении работы. Проблем не возникло.
Делается за пару минут. Проблема в том, что после перезагрузки TrueNas получается как бы в домене, а как бы и нет. Приходится выводить его и заводить заново. Починили в версии 12.0 U8 (последняя из 12 версии. Сейчас актуальная 13, но с пометкой “Community Release Only - Not Enterprise Supported.”)
Ни разу не получали проблем с этим ни при тестировании, ни при обновлении в бою.
Дополнительные функции 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
Комментарии (48)
Cayp
28.12.2022 10:24+2Если LZ4 может хорошо сжимать ваши бекапы MSSQL - значит сами бекапы выполняются без сжатия и достаточно рыхлые сами по себе.
Попробуйте включить сжатие прямо при выполнении бекапов в SQL и получите гораздо лучший результат (BACKUP DATABASE ... WITH COMPRESSION).
Это не создаёт никакой измеримой дополнительной нагрузки на современных процессорах в 2022 году.
aik
29.12.2022 08:24Попробуйте включить сжатие прямо при выполнении бекапов в SQL и получите гораздо лучший результат (BACKUP DATABASE… WITH COMPRESSION).
Зависит от версии MS SQL. Если сильно старая, то может и не быть сжатия.
У меня у самого, к примеру, до сих пор 2000 пашет на одном из серверов.
ildarz
28.12.2022 10:39Коротко: SAS круче, но ZFS позволяет обходиться более дешёвыми SATA дисками.
Этот вывод, как весь предшествующий абзац, с реальностью связан довольно слабо. Да, SAS "круче". Нет, далеко не только и не столько в связи с более продвинутыми алгоритмами коррекции ошибок. И нет, файловая система с выбором интерфейса дисков, вообще говоря, обычно не связана (т.е. с равным успехом можно использовать ZFS на SAS или не-ZFS на SATA).
Бекапы баз 1С (Microsoft SQL) сжимаются более чем в 3,5 раза!
Если вы не используете дедупликакцию, то их можно жать самим SQL (если у вас не совсем ископаемая версия) прямо при бэкапе. Помимо прочего, это позволяет сокращать окно бэкапа (иногда сильно) в ситуациях, когда скорость упирается в сеть.
начинается синхронизация пула, которая в нашем случае не повлияла на скорость проводившихся тестов
А на каких объемах дисков и заполнении пула вы это проверяли? Просто если что, такие вещи надо с близкими к боевыми объемами данных тестировать, потому что время регенерации и влияние на производительность именно от них зависит.
borovinskiy
28.12.2022 10:52Любой владелец денег, оплачивающий банкет, спросит чем же SAS "круче". За что конкретно он платит свои деньги?
С контрольными суммами понятно за что платишь: записалось именно то, что хотел записать. А ещё?ildarz
28.12.2022 12:59+1У SATA тоже есть контрольные суммы, причем работающие по тому же алгоритму, что и у SAS. Различия там лежат больше в области "что потом с этими ошибками делать", насколько мне известно. "Любому владельцу денег" обычно глубоко безразличен интерфейс дисков, он оперирует принципиально другими категориями. Даже на уровне сисадмина с точки зрения принятия практических решений в подавляющем большинстве случаев нужно смотреть на реальные измеримые характеристики устройств, а не на интерфейсы сами по себе. А относительно детальных различий SATA и SAS - если вас не устраивают общие слова вроде "SAS лучше масштабируется на большое количество устройств и высокие нагрузки, позволяет многопортовые подключения", и т.п. - тут уже надо читать спецификации протоколов или писать отдельную статью, коммент на хабре тут немного неподходящий формат.
borovinskiy
28.12.2022 14:34А в чем различие в поведении при обнаружении ошибок между SAS и SATA? Контрольные суммы на каком этапе сверяются? При передаче по интерфейсу?
borovinskiy
28.12.2022 14:58Пользователи ZFS знают, что иногда она начинает ругаться на данные при контроле своих контрольных сумм.
Это значит, что данные все-таки где-то побились. Биться могут на дисках, при передаче по шине от диска в ОЗУ и от ОЗУ к процессору, ну и биться могут в самом ОЗУ.
Поэтому да, вопрос интересен про контрольные суммы и разницу именно с точки зрения надежности.ildarz
28.12.2022 15:24+1SATA-3, там аж отдельный раздел про обработку ошибок:
Serial ATA Revision 3.1 (Gold) - December 8, 2010 (sata-io.org)
SAS 2 (6G), там для каждого уровня протокола про их обработку:
Serial Attached SCSI Manual (seagate.com)
Собственно контрольные суммы и там, и там считаются для передающихся по линку фреймов с данными, что стандартно для протоколов передачи данных в принципе. Лично с моей точки зрения разницы в надежности именно с точки зрения возможного незамеченного искажения данных (т.е. именно та ситуация, когда у ZFS контрольные суммы не сходятся) нет. Могу ошибаться, но тогда хотелось бы видеть конкретику от тех, кто считает, что она есть.
isden
28.12.2022 15:56Пользователи ZFS знают, что иногда она начинает ругаться на данные при контроле своих контрольных сумм.
А где искать эту ругань? Много лет использую ZOL на нескольких серверах — не видел такого. scrub делается раз в неделю — там всегда нули, в логах тоже все чисто.
Didimus
29.12.2022 18:22Сас можно на горячую втыкать, вроде
borovinskiy
29.12.2022 23:24+1SATA тоже можно.
Didimus
30.12.2022 12:18Недокументированная возможность.
borovinskiy
30.12.2022 13:00https://sata-io.org/system/files/specifications/SerialATA_Revision_3_1_Gold.pdf
Ctrl+F
hot plugЕсли говорить про десктопы, то горячее извлечение надо в UEFI включить.
Kotsusamu
28.12.2022 13:26Любой специалист спросит "а что такое "круче" и вообще Вы какие задачи планируете решать?".
borovinskiy
28.12.2022 14:53Эпитет "круче" я взял из топика. Согласен, что надо вести речь про задачи.
Lev3250 Автор
28.12.2022 14:59Согласен, "круче" надо было сразу брать в кавычки, а то такие споры начались... Наверное у меня просто пунктик на эту тему после того, как меня один товарищ убеждал, что дисков кроме SAS для более-менее серьёзного использования не существует
Didimus
29.12.2022 18:21Они на 15 тыс оборотов были, кажется
borovinskiy
29.12.2022 23:28+1Да, SAS HDD обычно на 10 и 15 тыс. оборотов, в то время как SATA на 7200 или 5400.
Хотя был WD VelociRaptor на 10 тыс. и с SATA-интерфейсом.
То есть скорость вращения не характеризует как таковая интерфейс, а в сегодняшних условиях покупать HDD на 15 тыс. оборотов "для скорости" дороже SSD той же емкости выглядит совсем уж странным.
Lev3250 Автор
28.12.2022 10:55файловая система с выбором интерфейса дисков, вообще говоря, обычно не связана
Файловая система не связана с интерфейсом диска. Тут посыл был в том, что ZFS может закрыть один из минусов SATA интерфейса. На канале LawrenceSystems этот момент оговаривается отдельно (конкретное видео не найду). Насколько это важно в реальных условиях? Личной статистики у меня нет.
можно жать самим SQL (если у вас не совсем ископаемая версия) прямо при бэкапе
Тут не могу ответить, почему сжатие при создании бекапа было выключено. Сделано было до меня и сделано было специально в своё время. Будет интересно проверить
Просто если что, такие вещи надо с близкими к боевыми объемами данных тестировать
Объёмы были в сотнях гигабайт (но запись/чтение в большинстве своём были линейными). Мы на тот момент и не знали, а какими будут боевые условия (задача из начала статьи сформировалась полностью только когда стало понятно, что способен потянуть TrueNas). Потому что из требований от QNAP на тот момент было "лишь бы не сдох". Процессор практически всегда был нагружен на 90-100%. Модель TS-412U или похожая. Так что то, что синхронизация не повлияла на скорость переливания папок туда-сюда уже было достаточно.
ildarz
28.12.2022 13:08Тут посыл был в том, что ZFS может закрыть один из минусов SATA интерфейса.
Обнаружение/коррекция ошибок, в т.ч. через CRC, в SATA тоже есть. Поэтому я просто не очень понимаю, о каких конкретно минусах тут идет речь. Если есть какие-то сценарии silent data corruption, возможные для SATA и невозможные для SAS - я бы почитал, конечно. Но просто на уровне "в SAS есть коррекция ошибок, в SATA нет" это звучит довольно странно.
Kotsusamu
28.12.2022 13:32"Тут посыл был в том, что ZFS может закрыть один из минусов SATA интерфейса " требуя при этом наличие ECC памяти. у SAS перед SATA немножко другие преимущества, чем вы озвучили (кстати на хабре по-этому поводу есть статья).
borovinskiy
29.12.2022 23:38+1ZFS отлично и без ECC работает. ЕСС - это не требование, а настоятельная рекомендация.
ECC лучше иметь на любом сервере, если, конечно, вам не все равно на скрытую порчу обрабатываемых данных.
Представьте, что у вас испортилась ячейка памяти и вы из нее читаете не то, что записали. Как это скажется на работе ПО на сервере? Скажется непредсказуемым образом. И тут не важно будет этим ПО ZFS, РСУБД или что-то еще.
unC0Rr
28.12.2022 10:54+2поднять свой «Google Photo» с распознованием лиц на фотографии. Но нужна карточка с CUDA.
CUDA не работает во FreeBSD.Lev3250 Автор
28.12.2022 11:16Да, в голове перемешались статьи про NextCloud в docker и в jail. Теоретически можно через виртуалки навелосипедить, но ИМХО это перебор будет :)
Добавил UPD в статью
13werwolf13
28.12.2022 11:48CUDA не работает в FreeBSD, так что без дополнительных прослоек распознавать лица не получится именно из jail плагина.
если под FreeBSD тут всё же понимать TrueNAS то пожалуй стоит уточнить что трунас сейчас есть как железобетонный на базе freebsd так и относительно недавно появившийся на базе debian где вроде бы всё то же самое но вместо jail используется докер а вместо бхива используется qemu, и там список "приложений" гораздо больше (да и с виртуализацией всё сильно лучше). однако я не тороплюсь на него переезжать хотя бы потому что там zfs работает через dkms, а dkms как известно плохой выбор.
Shrim
28.12.2022 13:53+3Не надо так.
У вас есть хороший RAID контроллер, а вы используете его как HBA.
Доукомплектуйте контроллер гигом кэша и аккумулятором. Из ваших весьма посредственных шести 3TB дисков лучше собрать RAID6, поверьте, у вас по факту RAID5 что на таких объёмах неприемлемо. Включите кэш контроллера на запись, отключите кэш дисков на запись. Создайте два логических диска — один на 5GB под систему, второй на весь оставшийся объём. Можно даже у первого логического диска выключить кэширование.
Устанавливаете debian только базовую систему (без окружения рабочего стола).
У вашего сервера четыре сетевых интерфейса, сколько сетевых интерфейсов у сервера виртуализации из статьи не понятно, подключите хотя бы два патч-кордами напрямую, не через коммутатор, если надо доукомплектуйте сервер виртуализации сетевой картой на два/четыре интерфейса. На интерфейсах пропишите адреса с маской 30.
Установите targetcli и опубликуйте ваш второй логический диск только для этих адресов.
В ESXi добавьте storage с включенным multipath политикой Round Robin, в свойствах storage вы увидите два пути к target или больше, сколько интерфейсов подключили. Multipath повысит скорость обмена и отказоустойчивость (от «случайного» выдёргивания одного патч-корда).
Всё. На этом storage делайте что хотите — храните резервные копии или запускайте виртуальные машины, хоть ту же TrueNAS с шарой на 50 пользователей AD.
По факту у вас получится дисковая полка с iSCSI.
Такая конфигурация производительней и безопасней, позволит крепче спать.borovinskiy
28.12.2022 14:50+1Рассмотрим два случая:
1. Сдыхает контроллер.
Всё, купи точно такой же с точно такой же прошивкой, иначе производитель не гарантирует, что твои данные не превратятся в кашу.
В случае с ZFS можно воткнуть любой контроллер и все будет работать.
2. Сдыхает диск
Если диск таки отвалился, необходимо обслуживание с заменой диска. В случае с контроллером надо будет поставить для этого утилиту производителя и если она установится, то тогда сможешь ею воспользоваться. При этом если веб-интерфейса нет, надо будет освоить ее терминальные команды на живом железе. А если с утилитой возникнут проблемы, то для настройки будешь грузиться с загрузочного диска производителя, остановив обслуживание.
С ZFS все это будет проще (именно при выходе из строя диска) и накосячить шансов меньше.
Плюс контроллера - несколько выше производительность, так как ZFS жрет процессор и снижает IOPS-ы.
Все остальное по созданию iSCSI-полки и с ZFS будет работать.Shrim
28.12.2022 15:00-11) Если так, то тогда собираем программный RAID6 через mdadm и не жалуемся на производительность, которая будет точно ниже чем у аппаратного контроллера с кэшем
2) В случае с контроллером надо будет просто заменить диск, только сегодня менял, синхронизация начинается автоматически. А с mdadm нужно будет лезть в консоль, «что может быть проблемой для людей не знакомых с linux»
Ну и не важно какой массив собрали, аппаратный или программный, мониторить его в любом случае надо — smartmontools, zabbix и «утилиты производителя» вам в помощь.borovinskiy
28.12.2022 22:35+1По производительности - кому надо производительность - купят NVMe SSD. Тут же речь за HDD и от них в почти уже 2023 чудес производительности не ждут и выжимать 30-50% сверху за счет кеша в 1Гб смысла нет. Так как если вам надо много IOPS - вам нужен не контроллер, а быстрый NVMe SSD.
Ну не, для кого-то может смысл и есть. Пусть сам решает. Но я бы скорее предпочел ZFS чем аппаратный контроллер при создании iSCSI-полки.
Shrim
29.12.2022 09:26+2По производительности — обсуждаем конкретную конфигурацию сервера, чудес производительности от него не ждём, но автор в задаче указал получить адекватную скорость, попробуем с ней разобраться.
У жестких дисков есть кэш память, например автор использует Toshiba P300 у которых 64MB кэша. По умолчанию кэш используется и на чтение и на запись.
При объединении дисков в массив, не важно какой — аппаратный, программный или ZFS пул RAIDZ, крайне рекомендуется отключать внутренний кэш диска на запись.
Это помогает сохранить консистентность массива при аварийной ситуации, но снижает скорость записи.
Каждый вид массива по своему старается сохранить консистентность и выжать максимум производительности.
У RAID-контроллеров для этого есть модуль кэш памяти и аккумулятор.
Программый RAID-массив для кэша использует оперативную память, размер выделяемой памяти указывается в stripe_cache_size.
Так же у программного массива есть write intent bitmap который позволяет после некорректной перезагрузки системы производить перепроверку не всего массива, а только тех областей, в которые на момент перезагрузки или отключения питания производилась запись.
Пул RAIDZ так же для кэша использует оперативную память, а для консистентности контрольные суммы.
Повторюсь — каждый вид массива чтобы повысить производительность использует кэш на запись.
Какое решение использовать вы выбираете сами, можете предпочесть использовать ZFS, это ваше право, вы несёте ответственность за эксплуатацию вашей инфраструктуры.Я просто дал рекомендацию основываясь на своём скромном опыте.Я работаю и с аппаратными и с программными массивами, с дисками разного уровня — от desktop sata до enterprise sas hdd/ssd.
Я сам уже почти десять лет использую сделанную из сервера дисковую полку подключенную по iSCSI к серверу виртуализации ESXi двумя 10Gb интерфейсами.
Мне случалось менять контроллер HP SmartArray на более новый, следующего поколения, естественно прошивка была другая. Контроллер нормально определил массив.
Я расширял аппаратный массив «на горячую». Менял диск на более емкий, дожидался синхронизации, менял следующий и т.д. После замены дисков просто расширил массив в HP ACU.
Я видел отказ второго диска при синхронизации RAID6.
Я видел аварийную остановку сервера из-за некорректируемой ошибки оперативной памяти.
Я видел внезапную «смерть» относительно нового APC Smart-UPS с достаточно свежими аккумуляторами.
Я ничего не имею против ZFS, аппаратных и программных массивов. Просто считаю что каждое решение должно использоваться там, где это уместно.
Мне кажется странным имея хороший аппаратный контроллер не использовать его возможности. Не надо боятся отказа аппаратного RAID-контроллера, отказать может всё что угодно, нужно просто быть к этому готовым.
Мне кажется сомнительным желание автора использовать один сервер для множества столь разных задач.
Я предложил решение, отличное от того к которому пришёл автор, и постарался указать его сильные стороны. Я не навязываю своё решение, не заставляю им пользоваться.
Я художник, я так вижу. Вы видите по другому. Сколько людей — столько мнений. И это хорошо. В споре рождается истина.
Cayp
29.12.2022 10:20+2"купи точно такой же с точно такой же прошивкой" - это утверждение ложно.
Диски собранные в рейд хранят на себе некоторую информацию о конфигрурации рейда специально для того чтобы их можно было собрать обратно. Это DELL рейд контроллер и он это действительно делает так (проверено).
Эти диски можно вынуть из этого сервера и эту конфигурацию сможет импортировать любой другой рейд контролер DELL.
Версия прошивки на это не влияет.
borovinskiy
29.12.2022 10:47+1Да, контроллеры хранят информацию прямо на дисках. Но можно все-таки ссылку на официальную документацию, что при выходе из строя контроллера замена контроллера c любой версией прошивки, как в большую, так и меньшую версии безопасно и поддерживается производителем?
Cayp
29.12.2022 12:33+1Например, для PERC H700 (что похоже на то что должно стоять в 11G сервере автора)
https://www.dell.com/support/home/en-us/product-support/product/poweredge-rc-h700/docs
User’s Guide -> Disk Migration
The PERC H700 and H800 cards support migration of virtual disks from
one controller to another without taking the target controller offline.
The controller can import RAID virtual disks in optimal, degraded,
or partially degraded states. You cannot import a virtual disk that is in
an offline state.
NOTE: The source controller must be offline prior to performing the disk migration.
NOTE: Disks cannot be migrated back to previous PERC RAID controllers.
NOTE: Importing secured virtual disks is supported as long as the appropriate key
(LKM) is supplied/configured.
When a controller detects a physical disk with an existing configuration,
it flags the physical disk as foreign, and generates an alert indicating that
a foreign disk was detected.Версия прошивки не упоминается.
Можно мигирировать на более новые или такие же поколения контроллеров.
borovinskiy
29.12.2022 16:18Ok, согласен, у HP ничего не написано про версии прошивок, значит в рамках одной модели контроллера это считается производителем безопасно, а иногда и безопасно на модель контроллера новее.
"NOTE: Disks cannot be migrated back to previous PERC RAID controllers." - Это значит, что после H700 диски нельзя пихать в H600. Так что все-таки не в любой контроллер HP можно всунуть диски, а только в совместимый.
Вот у Adaptec написано следующее: https://ask.adaptec.com/app/answers/detail/a_id/15128/~/how-to-change-an-existing-raid-array-using-maxview-storage-manager%3F
"To assure the safety of the data contained on your RAID array, please run a complete backup and verify prior to beginning the following procedure. When changing any configuration or adapter card there is always a danger of data loss."
То есть миграция возможна, "но это не точно" (с) мем.
Там же: "It is recommended to have the latest firmware/BIOS revision installed on the RAID controller before making changes to the RAID array".Про одинаковые прошивки, смею уверить, я не из головы придумал, а также на официальном сайте вычитал, но да, возможно информация устарела, по крайней мере в отношении некоторых производителей контроллеров.
Cayp
29.12.2022 18:58С не брендовыми контроллерами недокументированное и странное поведение гораздо более возможно чем с контроллерами крупных вендоров.
Разный подход к качеству. Adaptec решил перестраховаться и написал такое. Скорее всего потому что поддержка в рамках контроллера достаточно скудная. Dell решил совместимость в той или иной степени гарантировать и тестировать у себя, потому что поддержка оказывается целиком для серверных систем в том числе и при миграциях.
aik
29.12.2022 08:29У вас есть хороший RAID контроллер, а вы используете его как HBA.
И это плохо почему?
Сам я ZFS не особо люблю (может готовить не умею), но это решение всяко более гибкое, чем аппаратный RAID на стареньком сервере. А при наличии достаточно мощного железа — ещё и производительное.По факту у вас получится дисковая полка с iSCSI.
А задача была — получить NAS, а не дисковую полку.Shrim
29.12.2022 10:21+1Это не плохо. Есть свои плюсы и минусы. Например автор указал минус — невозможно заменить диск на горячую. Вы указали плюс — гибкость. Просто если уже есть хороший контроллер почему бы его не использовать по назначению? Выше уже указали пожалуй главный минус — что делать если сдохнет контроллер? Вдруг новый контроллер не увидит массив или превратит его в кашу. Или вообще контроллер этой фирмы купить не сможем. Но и автор не ушёл от этой проблемы, так как создал 6 RAID0. Тут уже или использовать все возможности аппаратного RAID-контроллера или заменить его на полноценный HBA.
Задачи получить NAS не было. Задач было несколько, автор их объединил в одно решение, я предложил их разделить на несколько решений.aik
29.12.2022 10:36если уже есть хороший контроллер почему бы его не использовать по назначению?
Потому что решение без контроллера более гибкое?автор не ушёл от этой проблемы, так как создал 6 RAID0
И это косяк. Лучше бы контроллер выкинул. Ну или постарался бы перешить в HBA.
Лично я вообще в нынешние времена не вижу особого смысла в них, для большинства софтверные решения будут гораздо удобнее.Задачи получить NAS не было.
«хранилища бекапов (SQL, бекапы ESXi машин), сетевых дисков iSCSI и хорошую сетевую папку» — по мне так вполне себе NAS, а не дисковая полка.
SpartacADM
28.12.2022 14:22-1непонятно: зачем накручивать морду (GUI) на простейшие вещи. ничего нового в TrueNAS я так и не увидел... и еще: как-то мало сочетается довольно подробное (может чуть наивное) описание и "иногда приходится лезть в командную строку, что может быть проблемой для людей не знакомых с linux"... хотя может цель авторов ОС как раз и есть дать начинающим удобный инструмент для работы, не для учебы
aik
29.12.2022 08:30В повседневной работе GUI удобнее. CLI должно оставаться для специфичных и скриптуемых задач. А задачи вида «расшарить папку» должны делаться мышкой.
ljety
28.12.2022 19:01+1RAID controller PERC H700
Эта версия контроллера не умеет использовать диски в non-raid режиме. В режиме "non-raid", TrueNAS видит каждый диск отдельно, что упрощает применения ZFS. Не требуется создавать RAID массив и диски можно менять и восстанавливать на горячию.
Lev3250 Автор
28.12.2022 19:03О чём я и написал
Это особенность RAID контроллера, который не умеет работать с дисками иначе, кроме RAID конфигураций. Поэтому пришлось размечать диски как 6 RAID0 массивов с 1 диском в массиве.
Kozobrod
29.12.2022 03:00+1Есть еще TrueNas Scale, который на дебиане и с докером в коробке. Позавчера как раз на него перешел после OpenMediaVault. Куча преднастроенных контейнеров доступна через репозиторий TrueCharts, плюс у ребят очень хорошая документация по конфигурированию, включая видео гайды с ютуба. Джентельменский набор traefic, nextcloud, vaultwarden ставится без проблем.
Главное помнить, что один диск будет только под систему, контейнеры на него не поставить, поэтому пришлось купить еще один ssd
aik
29.12.2022 08:31один диск будет только под систему, контейнеры на него не поставить
Я на флэшку ставил. В принципе, можно на этапе установки даже системное зеркало сделать из пары флэшек.
Fartzilla
Proxmox: на Debian-е, виртуалки и ZFS. В него openmediavault: на Debian-е, есть Docker.