Комментарии 57
Proxmox: на Debian-е, виртуалки и ZFS. В него openmediavault: на Debian-е, есть Docker.
За pve +++
Работаю с ним еще с версии 3.х. С каждым релизом все лучше и лучше.
Недавно завезли ядро 6.1 с MG-LRU https://forum.proxmox.com/threads/opt-in-linux-6-1-kernel-for-proxmox-ve-7-x-available.119483/
Заинтересовавшимся - Proxmox, ceph, zfs, pfsense и все-все-все https://forum.netgate.com/topic/163435/proxmox-ceph-zfs-pfsense-и-все-все-все-часть-2/
Зы. Напоминаю про proxmox backup server для ОЧ. быстрых инкрементных бэкапов на pve.
Зы2. Взял на wasabi s3-хранилище 1тб за 6$\в мес, подключил к pve\pbs и храню там бэкапы.
Если LZ4 может хорошо сжимать ваши бекапы MSSQL - значит сами бекапы выполняются без сжатия и достаточно рыхлые сами по себе.
Попробуйте включить сжатие прямо при выполнении бекапов в SQL и получите гораздо лучший результат (BACKUP DATABASE ... WITH COMPRESSION).
Это не создаёт никакой измеримой дополнительной нагрузки на современных процессорах в 2022 году.
Попробуйте включить сжатие прямо при выполнении бекапов в SQL и получите гораздо лучший результат (BACKUP DATABASE… WITH COMPRESSION).
Зависит от версии MS SQL. Если сильно старая, то может и не быть сжатия.
У меня у самого, к примеру, до сих пор 2000 пашет на одном из серверов.
а там может быть express sql , в котором компрессии нет
Коротко: SAS круче, но ZFS позволяет обходиться более дешёвыми SATA дисками.
Этот вывод, как весь предшествующий абзац, с реальностью связан довольно слабо. Да, SAS "круче". Нет, далеко не только и не столько в связи с более продвинутыми алгоритмами коррекции ошибок. И нет, файловая система с выбором интерфейса дисков, вообще говоря, обычно не связана (т.е. с равным успехом можно использовать ZFS на SAS или не-ZFS на SATA).
Бекапы баз 1С (Microsoft SQL) сжимаются более чем в 3,5 раза!
Если вы не используете дедупликакцию, то их можно жать самим SQL (если у вас не совсем ископаемая версия) прямо при бэкапе. Помимо прочего, это позволяет сокращать окно бэкапа (иногда сильно) в ситуациях, когда скорость упирается в сеть.
начинается синхронизация пула, которая в нашем случае не повлияла на скорость проводившихся тестов
А на каких объемах дисков и заполнении пула вы это проверяли? Просто если что, такие вещи надо с близкими к боевыми объемами данных тестировать, потому что время регенерации и влияние на производительность именно от них зависит.
Любой владелец денег, оплачивающий банкет, спросит чем же SAS "круче". За что конкретно он платит свои деньги?
С контрольными суммами понятно за что платишь: записалось именно то, что хотел записать. А ещё?
У SATA тоже есть контрольные суммы, причем работающие по тому же алгоритму, что и у SAS. Различия там лежат больше в области "что потом с этими ошибками делать", насколько мне известно. "Любому владельцу денег" обычно глубоко безразличен интерфейс дисков, он оперирует принципиально другими категориями. Даже на уровне сисадмина с точки зрения принятия практических решений в подавляющем большинстве случаев нужно смотреть на реальные измеримые характеристики устройств, а не на интерфейсы сами по себе. А относительно детальных различий SATA и SAS - если вас не устраивают общие слова вроде "SAS лучше масштабируется на большое количество устройств и высокие нагрузки, позволяет многопортовые подключения", и т.п. - тут уже надо читать спецификации протоколов или писать отдельную статью, коммент на хабре тут немного неподходящий формат.
А в чем различие в поведении при обнаружении ошибок между SAS и SATA? Контрольные суммы на каком этапе сверяются? При передаче по интерфейсу?
Пользователи ZFS знают, что иногда она начинает ругаться на данные при контроле своих контрольных сумм.
Это значит, что данные все-таки где-то побились. Биться могут на дисках, при передаче по шине от диска в ОЗУ и от ОЗУ к процессору, ну и биться могут в самом ОЗУ.
Поэтому да, вопрос интересен про контрольные суммы и разницу именно с точки зрения надежности.
SATA-3, там аж отдельный раздел про обработку ошибок:
Serial ATA Revision 3.1 (Gold) - December 8, 2010 (sata-io.org)
SAS 2 (6G), там для каждого уровня протокола про их обработку:
Serial Attached SCSI Manual (seagate.com)
Собственно контрольные суммы и там, и там считаются для передающихся по линку фреймов с данными, что стандартно для протоколов передачи данных в принципе. Лично с моей точки зрения разницы в надежности именно с точки зрения возможного незамеченного искажения данных (т.е. именно та ситуация, когда у ZFS контрольные суммы не сходятся) нет. Могу ошибаться, но тогда хотелось бы видеть конкретику от тех, кто считает, что она есть.
я думаю, что имелся в виду t10 dif, в теории вещь хорошая.
только (a) поддержка накопителями не так уж и часто встречается (а там, где встречается, цены несколько отличаются от привычных), (b) поддержка со стороны файловых систем и прочего фактически отсутствует (во всяком в опенсорсе).
Немного поискал тут, нашел краткую статью интересную SAS vs SATA | What Is the Difference & Which Is Better? | ESF (enterprisestorageforum.com) . Если верить приведенным там цифрам, то да, автор таки прав и для SATA риски выше, даже без учета t10 dif.
мельком глянул, есть ощущение, что автор передёргивает.
статистики датацентров говорят, что никакой корреляции между классом устройства (заявленным BER) и частотой выхода из строя нет, это чисто маркетинговый параметр.
думаю, что примерно то же и для silent data corruption в кабеле, никакой статистики я не встречал, думаю, что нарисованная там таблица полностью умозрительна.
более того, все случаи silent data corruption, с которыми я встречался/о которых я слышал, были не вероятностого характера ("вот эта исправная система работает, но ловит в среднем две ошибки в год"), а связанными с неисправностью железа ("вчера ошибок не было, сегодня пачка, заменили кабель/hdd/etc — прошло").
P. S. опять же, в той статье ставится знак равенства между SATA и NL SAS. но фактически между этими двумя вариантами и идёт выбор, другие варианты SAS если и доступны для ёмких накопителей, то по в разы более высокой цене.
Пользователи ZFS знают, что иногда она начинает ругаться на данные при контроле своих контрольных сумм.
А где искать эту ругань? Много лет использую ZOL на нескольких серверах — не видел такого. scrub делается раз в неделю — там всегда нули, в логах тоже все чисто.
Сас можно на горячую втыкать, вроде
SATA тоже можно.
Недокументированная возможность.
https://sata-io.org/system/files/specifications/SerialATA_Revision_3_1_Gold.pdf
Ctrl+F
hot plug
Если говорить про десктопы, то горячее извлечение надо в UEFI включить.
Любой специалист спросит "а что такое "круче" и вообще Вы какие задачи планируете решать?".
Они на 15 тыс оборотов были, кажется
Да, SAS HDD обычно на 10 и 15 тыс. оборотов, в то время как SATA на 7200 или 5400.
Хотя был WD VelociRaptor на 10 тыс. и с SATA-интерфейсом.
То есть скорость вращения не характеризует как таковая интерфейс, а в сегодняшних условиях покупать HDD на 15 тыс. оборотов "для скорости" дороже SSD той же емкости выглядит совсем уж странным.
файловая система с выбором интерфейса дисков, вообще говоря, обычно не связана
Файловая система не связана с интерфейсом диска. Тут посыл был в том, что ZFS может закрыть один из минусов SATA интерфейса. На канале LawrenceSystems этот момент оговаривается отдельно (конкретное видео не найду). Насколько это важно в реальных условиях? Личной статистики у меня нет.
можно жать самим SQL (если у вас не совсем ископаемая версия) прямо при бэкапе
Тут не могу ответить, почему сжатие при создании бекапа было выключено. Сделано было до меня и сделано было специально в своё время. Будет интересно проверить
Просто если что, такие вещи надо с близкими к боевыми объемами данных тестировать
Объёмы были в сотнях гигабайт (но запись/чтение в большинстве своём были линейными). Мы на тот момент и не знали, а какими будут боевые условия (задача из начала статьи сформировалась полностью только когда стало понятно, что способен потянуть TrueNas). Потому что из требований от QNAP на тот момент было "лишь бы не сдох". Процессор практически всегда был нагружен на 90-100%. Модель TS-412U или похожая. Так что то, что синхронизация не повлияла на скорость переливания папок туда-сюда уже было достаточно.
Тут посыл был в том, что ZFS может закрыть один из минусов SATA интерфейса.
Обнаружение/коррекция ошибок, в т.ч. через CRC, в SATA тоже есть. Поэтому я просто не очень понимаю, о каких конкретно минусах тут идет речь. Если есть какие-то сценарии silent data corruption, возможные для SATA и невозможные для SAS - я бы почитал, конечно. Но просто на уровне "в SAS есть коррекция ошибок, в SATA нет" это звучит довольно странно.
"Тут посыл был в том, что ZFS может закрыть один из минусов SATA интерфейса " требуя при этом наличие ECC памяти. у SAS перед SATA немножко другие преимущества, чем вы озвучили (кстати на хабре по-этому поводу есть статья).
ZFS отлично и без ECC работает. ЕСС - это не требование, а настоятельная рекомендация.
ECC лучше иметь на любом сервере, если, конечно, вам не все равно на скрытую порчу обрабатываемых данных.
Представьте, что у вас испортилась ячейка памяти и вы из нее читаете не то, что записали. Как это скажется на работе ПО на сервере? Скажется непредсказуемым образом. И тут не важно будет этим ПО ZFS, РСУБД или что-то еще.
поднять свой «Google Photo» с распознованием лиц на фотографии. Но нужна карточка с CUDA.CUDA не работает во FreeBSD.
Да, в голове перемешались статьи про NextCloud в docker и в jail. Теоретически можно через виртуалки навелосипедить, но ИМХО это перебор будет :)
Добавил UPD в статью
CUDA не работает в FreeBSD, так что без дополнительных прослоек распознавать лица не получится именно из jail плагина.
если под FreeBSD тут всё же понимать TrueNAS то пожалуй стоит уточнить что трунас сейчас есть как железобетонный на базе freebsd так и относительно недавно появившийся на базе debian где вроде бы всё то же самое но вместо jail используется докер а вместо бхива используется qemu, и там список "приложений" гораздо больше (да и с виртуализацией всё сильно лучше). однако я не тороплюсь на него переезжать хотя бы потому что там zfs работает через dkms, а dkms как известно плохой выбор.
У вас есть хороший RAID контроллер, а вы используете его как HBA.
Доукомплектуйте контроллер гигом кэша и аккумулятором. Из ваших весьма посредственных шести 3TB дисков лучше собрать RAID6, поверьте, у вас по факту RAID5 что на таких объёмах неприемлемо. Включите кэш контроллера на запись, отключите кэш дисков на запись. Создайте два логических диска — один на 5GB под систему, второй на весь оставшийся объём. Можно даже у первого логического диска выключить кэширование.
Устанавливаете debian только базовую систему (без окружения рабочего стола).
У вашего сервера четыре сетевых интерфейса, сколько сетевых интерфейсов у сервера виртуализации из статьи не понятно, подключите хотя бы два патч-кордами напрямую, не через коммутатор, если надо доукомплектуйте сервер виртуализации сетевой картой на два/четыре интерфейса. На интерфейсах пропишите адреса с маской 30.
Установите targetcli и опубликуйте ваш второй логический диск только для этих адресов.
В ESXi добавьте storage с включенным multipath политикой Round Robin, в свойствах storage вы увидите два пути к target или больше, сколько интерфейсов подключили. Multipath повысит скорость обмена и отказоустойчивость (от «случайного» выдёргивания одного патч-корда).
Всё. На этом storage делайте что хотите — храните резервные копии или запускайте виртуальные машины, хоть ту же TrueNAS с шарой на 50 пользователей AD.
По факту у вас получится дисковая полка с iSCSI.
Такая конфигурация производительней и безопасней, позволит крепче спать.
Рассмотрим два случая:
1. Сдыхает контроллер.
Всё, купи точно такой же с точно такой же прошивкой, иначе производитель не гарантирует, что твои данные не превратятся в кашу.
В случае с ZFS можно воткнуть любой контроллер и все будет работать.
2. Сдыхает диск
Если диск таки отвалился, необходимо обслуживание с заменой диска. В случае с контроллером надо будет поставить для этого утилиту производителя и если она установится, то тогда сможешь ею воспользоваться. При этом если веб-интерфейса нет, надо будет освоить ее терминальные команды на живом железе. А если с утилитой возникнут проблемы, то для настройки будешь грузиться с загрузочного диска производителя, остановив обслуживание.
С ZFS все это будет проще (именно при выходе из строя диска) и накосячить шансов меньше.
Плюс контроллера - несколько выше производительность, так как ZFS жрет процессор и снижает IOPS-ы.
Все остальное по созданию iSCSI-полки и с ZFS будет работать.
2) В случае с контроллером надо будет просто заменить диск, только сегодня менял, синхронизация начинается автоматически. А с mdadm нужно будет лезть в консоль, «что может быть проблемой для людей не знакомых с linux»
Ну и не важно какой массив собрали, аппаратный или программный, мониторить его в любом случае надо — smartmontools, zabbix и «утилиты производителя» вам в помощь.
По производительности - кому надо производительность - купят NVMe SSD. Тут же речь за HDD и от них в почти уже 2023 чудес производительности не ждут и выжимать 30-50% сверху за счет кеша в 1Гб смысла нет. Так как если вам надо много IOPS - вам нужен не контроллер, а быстрый NVMe SSD.
Ну не, для кого-то может смысл и есть. Пусть сам решает. Но я бы скорее предпочел ZFS чем аппаратный контроллер при создании iSCSI-полки.
У жестких дисков есть кэш память, например автор использует Toshiba P300 у которых 64MB кэша. По умолчанию кэш используется и на чтение и на запись.
При объединении дисков в массив, не важно какой — аппаратный, программный или ZFS пул RAIDZ, крайне рекомендуется отключать внутренний кэш диска на запись.
Это помогает сохранить консистентность массива при аварийной ситуации, но снижает скорость записи.
Каждый вид массива по своему старается сохранить консистентность и выжать максимум производительности.
У RAID-контроллеров для этого есть модуль кэш памяти и аккумулятор.
Программый RAID-массив для кэша использует оперативную память, размер выделяемой памяти указывается в stripe_cache_size.
Так же у программного массива есть write intent bitmap который позволяет после некорректной перезагрузки системы производить перепроверку не всего массива, а только тех областей, в которые на момент перезагрузки или отключения питания производилась запись.
Пул RAIDZ так же для кэша использует оперативную память, а для консистентности контрольные суммы.
Повторюсь — каждый вид массива чтобы повысить производительность использует кэш на запись.
Какое решение использовать вы выбираете сами, можете предпочесть использовать ZFS, это ваше право, вы несёте ответственность за эксплуатацию вашей инфраструктуры.
Я сам уже почти десять лет использую сделанную из сервера дисковую полку подключенную по iSCSI к серверу виртуализации ESXi двумя 10Gb интерфейсами.
Мне случалось менять контроллер HP SmartArray на более новый, следующего поколения, естественно прошивка была другая. Контроллер нормально определил массив.
Я расширял аппаратный массив «на горячую». Менял диск на более емкий, дожидался синхронизации, менял следующий и т.д. После замены дисков просто расширил массив в HP ACU.
Я видел отказ второго диска при синхронизации RAID6.
Я видел аварийную остановку сервера из-за некорректируемой ошибки оперативной памяти.
Я видел внезапную «смерть» относительно нового APC Smart-UPS с достаточно свежими аккумуляторами.
Я ничего не имею против ZFS, аппаратных и программных массивов. Просто считаю что каждое решение должно использоваться там, где это уместно.
Мне кажется странным имея хороший аппаратный контроллер не использовать его возможности. Не надо боятся отказа аппаратного RAID-контроллера, отказать может всё что угодно, нужно просто быть к этому готовым.
Мне кажется сомнительным желание автора использовать один сервер для множества столь разных задач.
Я предложил решение, отличное от того к которому пришёл автор, и постарался указать его сильные стороны. Я не навязываю своё решение, не заставляю им пользоваться.
Я художник, я так вижу. Вы видите по другому. Сколько людей — столько мнений. И это хорошо. В споре рождается истина.
"купи точно такой же с точно такой же прошивкой" - это утверждение ложно.
Диски собранные в рейд хранят на себе некоторую информацию о конфигрурации рейда специально для того чтобы их можно было собрать обратно. Это DELL рейд контроллер и он это действительно делает так (проверено).
Эти диски можно вынуть из этого сервера и эту конфигурацию сможет импортировать любой другой рейд контролер DELL.
Версия прошивки на это не влияет.
Да, контроллеры хранят информацию прямо на дисках. Но можно все-таки ссылку на официальную документацию, что при выходе из строя контроллера замена контроллера c любой версией прошивки, как в большую, так и меньшую версии безопасно и поддерживается производителем?
Например, для 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.
Версия прошивки не упоминается.
Можно мигирировать на более новые или такие же поколения контроллеров.
Ok, согласен, у 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".
Про одинаковые прошивки, смею уверить, я не из головы придумал, а также на официальном сайте вычитал, но да, возможно информация устарела, по крайней мере в отношении некоторых производителей контроллеров.
С не брендовыми контроллерами недокументированное и странное поведение гораздо более возможно чем с контроллерами крупных вендоров.
Разный подход к качеству. Adaptec решил перестраховаться и написал такое. Скорее всего потому что поддержка в рамках контроллера достаточно скудная. Dell решил совместимость в той или иной степени гарантировать и тестировать у себя, потому что поддержка оказывается целиком для серверных систем в том числе и при миграциях.
У вас есть хороший RAID контроллер, а вы используете его как HBA.
И это плохо почему?
Сам я ZFS не особо люблю (может готовить не умею), но это решение всяко более гибкое, чем аппаратный RAID на стареньком сервере. А при наличии достаточно мощного железа — ещё и производительное.
По факту у вас получится дисковая полка с iSCSI.
А задача была — получить NAS, а не дисковую полку.
Задачи получить NAS не было. Задач было несколько, автор их объединил в одно решение, я предложил их разделить на несколько решений.
если уже есть хороший контроллер почему бы его не использовать по назначению?
Потому что решение без контроллера более гибкое?
автор не ушёл от этой проблемы, так как создал 6 RAID0
И это косяк. Лучше бы контроллер выкинул. Ну или постарался бы перешить в HBA.
Лично я вообще в нынешние времена не вижу особого смысла в них, для большинства софтверные решения будут гораздо удобнее.
Задачи получить NAS не было.
«хранилища бекапов (SQL, бекапы ESXi машин), сетевых дисков iSCSI и хорошую сетевую папку» — по мне так вполне себе NAS, а не дисковая полка.
непонятно: зачем накручивать морду (GUI) на простейшие вещи. ничего нового в TrueNAS я так и не увидел... и еще: как-то мало сочетается довольно подробное (может чуть наивное) описание и "иногда приходится лезть в командную строку, что может быть проблемой для людей не знакомых с linux"... хотя может цель авторов ОС как раз и есть дать начинающим удобный инструмент для работы, не для учебы
RAID controller PERC H700
Эта версия контроллера не умеет использовать диски в non-raid режиме. В режиме "non-raid", TrueNAS видит каждый диск отдельно, что упрощает применения ZFS. Не требуется создавать RAID массив и диски можно менять и восстанавливать на горячию.
Есть еще TrueNas Scale, который на дебиане и с докером в коробке. Позавчера как раз на него перешел после OpenMediaVault. Куча преднастроенных контейнеров доступна через репозиторий TrueCharts, плюс у ребят очень хорошая документация по конфигурированию, включая видео гайды с ютуба. Джентельменский набор traefic, nextcloud, vaultwarden ставится без проблем.
Главное помнить, что один диск будет только под систему, контейнеры на него не поставить, поэтому пришлось купить еще один ssd
> Сеть 1Gbit/s. Но можно установить другую сетевую карту, или объединить несколько карточек из 4х для суммирования скорости.
В помощь https://www.youtube.com/watch?v=txwLT9ZCZ8k (на пальцах - чел просто перепрошил дешевую MCX354A-QCBT прошивкой от более дорогой MCX354A-FCBT и получил 40гбит\с по ether вместо 10гбит\с)
Карта + кабель есть на али.
На freenas scale (там debian) карта с видео выше точно заводится.
Upd. Есть еще вариант https://habr.com/ru/post/529732/
переходник тут https://aliexpress.ru/wholesale?SearchText=FlexibleLOM
карта тут https://aliexpress.ru/wholesale?SearchText=764285-B21
и даже тут https://www.avito.ru/all/tovary_dlya_kompyutera?q=764286-B21
40/56 Гбит\с для дома должно хватить каждому
TrueNas: когда Nas реально ТРУ