Комментарии 21
Используйте sanoid/syncoid.
Swaks используется для тестирования отправок писем, а не для продакшена!
Хочется отправлять в jabber, то тогда sendxmpp.
У телеги своя извращенная логика, рекомендую не связівать мониторинг с ней.
Есть ещё snapzend, но sanoid пока нравится больше.
P.S. По поводу UTC — допёр.
В /lib/systemd/system/sanoid*.service нужно убрать Environment=TZ=UTC
Стоило бы упомянуть, что для SLOG (который в статье указан как ZIL), обычный рандомный ssd, даже pcie, подходит слабо. Если не брать в расчёт специализированные устройства типа Radian Memory RMS-200, то лучше всего подходят диски Intel Optane.
Стоило бы упомянуть, что для SLOG (который в статье указан как ZIL), обычный рандомный ssd, даже pcie, подходит слабо
почему это? именно на записи что обычный nvme, что optane показывают ≈20мкс (мы же говорим не о дестопных nvme, правильно? на тех из-за отсутствия ионисторов синхронная запись может быть медленной)
https://docs.google.com/spreadsheets/d/1E9-eXjzsKboiCCX-0u0r5fAjjufLKayaut_FOPxYZjc/edit?hl=en#gid=0
Вообще как я понял Optane бывают сильно разные и однозначного представления о том, что лучше брать для SLOG — нет. Скиньте статью, если есть чем поделиться о том, что лучше брать для SLOG.
В подкате сразу вам ложечка дёгтя. Да ZFS работает медленее. Существенно. Но использовать её как обычную фс нельзя. Она должна работать в массиве дисков, где увеличение количества дисков только приветствуется, диски желательно должны быть SAS, контроллер должен работать в режиме HBA (а не raid0 в качестве одиночных дисков), должна быть ОЗУ ECC и её должно быть много, обязательно должен быть один SSD (лучше PCI-E) в качестве кэша на чтение второго уровня (небольшой, гигов от 64) и один SSD для ZIL можно совсем небольшой, но желательно MLC.
какой-то набор мифов ИМХО.
- отличия по производительности от других ФС бывают как в ту, так и в другую сторону, в целом я бы не назвал zfs особо медленной ФС;
- про массивы дисков: raidz/raidz2 как раз "не любит" многопоточную нагрузку на "широкие" vdev (особенно на небольших файлах) — чтение/запись файла нагружает все диски, то есть происходит мультипликация количества операций ввода-вывода (в случае с классическим RAID 5/6 с достаточно большим chunk size небольшой файл обычно будет помещаться на одном, максимум двух дисках);
- от SAS-дисков я вообще никакого прироста не ощутил (брал NL только потому, что разница в цене смешная и пугали худшей совместимостью SATA дисков с active backplane);
- память ECC должна быть на любом сервере;
- L2ARC — весьма спорная штука, вот первый результат из гугла: В качестве практического метода, каждый гигабайт L2ARC требует 25МБ ARC;
- ZIL нужен только лишь для некоторых нагрузок (синхронная запись).
Итого из отрицательных сторон я бы назвал:
- (linux-специфичное) своё управление памятью, не слишком хорошо интегрированное со стандартным линуксовым, из-за этого, во-многом, и "нужно много памяти";
- особенность работы raidz с мелкими файлами, о которой писал выше.
P.S. и раз вас интересует производительность — гуглите special VDEV (BTW, ZIL тоже автоматически оказывается там же).
Вообще мне больше нравятся производные от зеркал и страйпов конфигурации, но вот сейчас придётся собирать массив из 6-ти 600-х SAS. Другого ничего не будет и 1,8T будет недостаточно, придётся собирать RAID 5 из 3-х пар страйпов. Да, плохо, денег нет, но вы держитесь. Буду набивать опыт, куда без этого, классно это делать за чужие бабки, но мы не ищем лёгких путей.
По части пункта 6… И...? Не стоит его ставить?
special VDEV — отличная наводка, спасибо. Русскоязычной информации по поводу того, как это использовать — не нашёл. Нужно время чтобы перевести и понять что пишут иностранцы. Что с ним делать то, если вкратце? Выкинуть L2ARC и использовать его?
до него стояли SATA диски, показавшие себя неплохо mdadm, но ZFS с ними просто коловая. Почему?
тут нельзя сказать заочно, нужно разбираться в конкретном случае. дело может быть в контроллере, винтах, настройках софта…
а может быть вы просто заменили диски 5400rpm на 10000rpm, а разницу приписываете SAS.
сходу вспоминается, что в SATA меньшая глубина очереди, ну и передача полудуплексная. ничего иэ этого кардинально на производительность не влияет (в SAS, конечно, есть свои "плюшки", не связанные с производительностью, но это предмет для отдельного разговора).
Русскоязычной информации по поводу того, как это использовать — не нашёл. Нужно время чтобы перевести и понять что пишут иностранцы.
на хабре было же уже. и что там понимать?
в zfs есть разные виды блоков, если упростить: данные (содержимое файлов) и метаданные (всё остальное). обычно основное место на диске занимают данные, метаданных же не так много в байтах, однако для доступа к данным зачастую нужно прочитать несколько блоков метаданных.
получаем мультпликацию операций ввода-вывода: чтобы прочитать мегабайт из файла (что современный винт может делать на скорости выше 100Мб/с, плюс 10мс на поиск места, то есть за 10+10мс), нам зачастую нужно прочитать несколько блоков метаданных (а это несколько сиков, на каждый опять же 10мс).
конечно, есть волшебный ARC, а к нему L2ARC впридачу, но:
- память стоит дорого (а L2ARC тоже потребляет память, про это я уже писал);
- это работает только на чтение;
- после перезагрузки содержимое ARC и L2ARC теряется.
поэтому светлые головы предложили хранить метаданные в том же пуле, но в отдельном VDEV (раньше такое уже проделали с ZIL). мы можем выделить под метаданные относительно небольшой SSD, а данные разместить на недорогом HDD. в результате большая часть случайного доступа у нас уходит на SSD, производительность во многих сценариях существенно растёт, а обходится это не так дорого.
а может быть вы просто заменили диски 5400rpm на 10000rpm, а разницу приписываете SAS.и там и там 7200. Контроллер… ну на mdadm тот же контроллер и был. Можете погуглить «zfs io wait».
Ситуация была в чём… были 2 sata десктопных диска, они были организованы в zfs зеркало без L2ARC и ZIL. При запуске деятельности ВМ на этом массиве фризились и ВМ и гипервизор даже в консоли. Как результат — фризы и огромный io wait.
Переконфигурил в mdadm + lvm — ВМ работают до сих пор без проблем на том первом сервере. Потом был организован второй, где я курил гугл месяц (чистый месяц, вообще больше конечно раза в 3) и выяснял и про HBA и про очереди, тестил на разных очередях и конфигурациях, но всё равно я не добился ничего адекватного даже с ARC, L2ARC и ZIL на простых SSD.
Заработало это нормально когда пришли 3,5 SAS NL 6TB 72 за 14 рублей каждый.
По части Spec vdev. То есть если у меня два PCI-E m2 SSD по 128G, они разбиты по 16 для ZIL в зеркале и 112 в страйпе для L2ARC, то имеет смысл убрать L2ARC, переделать раздел со 112 из страйпа в зеркало и разместить там special vdev? Или лучше оставить L2ARC а в качестве spec dev поставить ещё диск.
То есть если у меня два PCI-E m2 SSD по 128G, они разбиты по 16 для ZIL в зеркале и 112 в страйпе для L2ARC, то имеет смысл убрать L2ARC, переделать раздел со 112 из страйпа в зеркало и разместить там special vdev?
ну как минимум стоит попробовать. с помощью zdb -bb посмотрите сколько у вас метаданных, чтобы было понятно какого размера требуется special vdev.
Вот ещё неплохой красавчик, если кому надо, но уже он как-то неприлично дорого стоит. (Стоил 1200 где-то)
хотя бы 7200, хотя бы HL
Комьюнити очень интересуется вопросом — что такое HL?
Подскажите как Вы организовали шифрование ВМ? Как и с помощью чего?
Удалённые инкрементные резервные копии ZFS. Проще некуда