Всем доброго времени суток. Ищу помощи специалистов по тюнингу ФС и умению сделать "все хорошо". Из группы Storage Discussions подсказали написать сюда.
Дано сервер - Ubuntu 20.04 LTS, ppc64le 80 x 3.49GHz, 512GB RAM
Диски
2 x 16TB 3.5" HDD SATA WD
1 x 1.6TB AIC SSD NVMe PCIe x8 Samsung
2 x 128GB M.2 SSD NVMe PCI4 x4 Samsung
+ (маленький диск под OS но он не в счет, его не трогаем)
Надо
Собрать дисковую подсистему для 20 контейнеров (это максимум), рабочий объем данных что нужен в горячем пуле не превышает 1TB, скорости All-Flash не ожидаются, по IOPS требования очень низкие. Возможно доустановить несколько NVMe дисков при необходимости. А также полностью затюнить все критические параметры.
Пока в текущем тестовом стенде сделано так, zfs последняя версия из репо. RAID1 из 2 HDD средствами zfs, 1.6TB под L2ARC, 1 диск на 128GB по ZIL SLOG, 1 диск на 128GB под метаданные (special device). Очевидно что нужен глубокий тюнинг всего этого дела.
Если сдохнут ssd которые по 1шт, а сними и все данные (речь про special) ничего страшного?
riv
sweetiefox
Если сдохнут ssd которые по 1шт, а сними и все данные (речь про special) ничего страшного?
Там на карту где стоит M.2 можно добавить еще один диск, будет mirror. Таким образом спокойно можно добавить еще 2 диска. По uptime там супер критичного ничего нету, на сервер загружаются данные которые обрабатывают и после стираются, но в любом случае доставить еще один диск не проблема.
Vladislav
Ава мое уважение
riv
Там на карту где стоит M.2 можно добавить еще один диск, будет mirror. Таким образом спокойно можно добавить еще 2 диска. По uptime там супер критичного ничего нету, на сервер загружаются данные которые обрабатывают и после стираются, но в любом случае доставить еще один диск не проблема.
Это необходимо сделать. Slog допускается не дублировать, но это крайне не желательно. Тоже лучше mirror. А вот кэшь vdev дублировать однозначно не требуется с точки зрения отказоустойчивости. Но подумайте о том как просядет производительность при отказе ssd под кэшь и отключении кэша. С точки зрения продолжения работы имеет смысл подключить несколько ssd под кэш но не в mirror а как самостоятельные vdev
riv
В основном по iostat операции будут 80-90% read / 10-20% write, типовой рабочий датасет примерно 1TB. Просадки из-за промахов кэша не критичны, ситуаций с волнообразным обновлением данных по rand крайне редки, обычно контейнеры по чуть чуть подсасывают нужные данные в свой рабочий датасет +/-, но даже если будет просадка по IOPS - то она не фатальна, ибо SLA на это нету - клиента это не важно.
В остальном, не имею идей как кардинально поднять производительность. Далее только добавление hdd vdev для расширеня места и не большого поднятия iops на запись или замена hdd vdev на ssd )
Тюнить надо размер озу под arc иначе можете столкнутся с нехваткой свободной озу при старте контейнеров. По умолчанию zfs возьмет половину установленной озу, которую потом отдаёт не очень охотно.
sweetiefox
В остальном, не имею идей как кардинально поднять производительность. Далее только добавление hdd vdev для расширеня места и не большого поднятия iops на запись или замена hdd vdev на ssd )
Тюнить надо размер озу под arc иначе можете столкнутся с нехваткой свободной озу при старте контейнеров. По умолчанию zfs возьмет половину установленной озу, которую потом отдаёт не очень охотно.
Как сделать так чтобы zfs не пыталась писать жирные файлы сразу на HDD, а кэшировала их для начала? Чтобы например их скидывали на 128GB SSD, а потом уже дальше на HDD.
Vladislav
Всем доброго времени суток. Ищу помощи специалистов по тюнингу ФС и умению сделать "все хорошо". Из группы Storage Discussions подсказали написать сюда.
Дано сервер - Ubuntu 20.04 LTS, ppc64le 80 x 3.49GHz, 512GB RAM
Диски
2 x 16TB 3.5" HDD SATA WD
1 x 1.6TB AIC SSD NVMe PCIe x8 Samsung
2 x 128GB M.2 SSD NVMe PCI4 x4 Samsung
+ (маленький диск под OS но он не в счет, его не трогаем)
Надо
Собрать дисковую подсистему для 20 контейнеров (это максимум), рабочий объем данных что нужен в горячем пуле не превышает 1TB, скорости All-Flash не ожидаются, по IOPS требования очень низкие. Возможно доустановить несколько NVMe дисков при необходимости. А также полностью затюнить все критические параметры.
Пока в текущем тестовом стенде сделано так, zfs последняя версия из репо. RAID1 из 2 HDD средствами zfs, 1.6TB под L2ARC, 1 диск на 128GB по ZIL SLOG, 1 диск на 128GB под метаданные (special device). Очевидно что нужен глубокий тюнинг всего этого дела.
Мету и мелкие файлы до blocksize на special vdev, который разместить либо на 128гб либо создав раздел на 1.6тб, ибо AIC почти бессмертны
l2arc (тык и тык) скорее бесполезен чем полезен, но рекомендую проверить на тестовой нагрузке попадает ли в него объем на 1тб
sweetiefox
Мету и мелкие файлы до blocksize на special vdev, который разместить либо на 128гб либо создав раздел на 1.6тб, ибо AIC почти бессмертны
l2arc (тык и тык) скорее бесполезен чем полезен, но рекомендую проверить на тестовой нагрузке попадает ли в него объем на 1тб
А эту статью уже видела :) Меня больше волнует вопрос что ZFS на запись под дефолту все что больше N размера сразу пишет на основной backing device. И как итог ужасная скорость :( А L2ARC это RO cache.
Vladislav
Поэтому small block size выносить на special vdev
Алексей
sweetiefox
Ну мета то понятно что будет, а что на счет основных данных. Ведь вопрос в том что данных то на 16ТБ (реальная емкость 14ТБ), а кэша только на 128ГБ. Или под special vdevs отдать 1.6TB AIC?
riv
Как сделать так чтобы zfs не пыталась писать жирные файлы сразу на HDD, а кэшировала их для начала? Чтобы например их скидывали на 128GB SSD, а потом уже дальше на HDD.
Никак, zfs не синхронные операции будет скидывать на основные диски.
Гипотетически, настройка файловой системы sync=olways может привести к такому поведению, но я уверен, что всё только замедлится.
Нужно понимать, что zfs все не синхронные операции пишет через writeback-буфер и срасывает на диски дольшими порциями, так что данные пишутся на пределе пропускной способности накопителей. Но в отличие от классических файловых систем, этому потоку не мешают синхронные вызовы, котомые сразу же сбрасываются на slog и отложенно переносятся на основные диски.
riv
Для ультра мелких блоков (1-4кб) лучше special vdev
Возможно тогда special должен быть побольше. По умолчанию zfs не настроен на запись мелких блоков на special, но даже перенос метаданных хорошо разгружает основные vdev.
sweetiefox
Никак, zfs не синхронные операции будет скидывать на основные диски.
Гипотетически, настройка файловой системы sync=olways может привести к такому поведению, но я уверен, что всё только замедлится.
Нужно понимать, что zfs все не синхронные операции пишет через writeback-буфер и срасывает на диски дольшими порциями, так что данные пишутся на пределе пропускной способности накопителей. Но в отличие от классических файловых систем, этому потоку не мешают синхронные вызовы, котомые сразу же сбрасываются на slog и отложенно переносятся на основные диски.
А можно ли сделать устройство типа bcache с опцией writeback cache и уже поверх него поставить zfs? таким образом чтобы bcache решал вопрос с заполнением буфера на запись в HDD, а уже zfs поверх решала остальные вопросы?
Vladislav
Возможно тогда special должен быть побольше. По умолчанию zfs не настроен на запись мелких блоков на special, но даже перенос метаданных хорошо разгружает основные vdev.
Я поэтому и рекомендую 1.6тб под это счастье
Vladislav
riv
Ну мета то понятно что будет, а что на счет основных данных. Ведь вопрос в том что данных то на 16ТБ (реальная емкость 14ТБ), а кэша только на 128ГБ. Или под special vdevs отдать 1.6TB AIC?
Нужно учесть, что пул ше должен заполняться более чем на 80%, так что данных там поместится не 16ТБ
Vladislav
Не стоит мешать zfs с другими системами
Золотое правило ZFS, если ты ставишь что-то активное, что-то, что может обрабатывать данные добавляя задержку в записи между диском и ZFS - ты говоришь, что ты умнее разрабов, и лучше знаешь как держать данные в сохранности
sweetiefox
Нужно учесть, что пул ше должен заполняться более чем на 80%, так что данных там поместится не 16ТБ
Ну да там эффективная емкость на 14ТБ само собой. Следовательно от этой величины ставим 80%.
riv
А можно ли сделать устройство типа bcache с опцией writeback cache и уже поверх него поставить zfs? таким образом чтобы bcache решал вопрос с заполнением буфера на запись в HDD, а уже zfs поверх решала остальные вопросы?
Прежде чем решать в ьаком духе проблемы с производительностью, надо вообще посмотреть какого рода они будут возникать.
Например меня удивляет заявление про 90% чтения, тогда как на практике, вирт машины обычно пишут 3/4, а читают 1/4
sweetiefox
Прежде чем решать в ьаком духе проблемы с производительностью, надо вообще посмотреть какого рода они будут возникать.
Например меня удивляет заявление про 90% чтения, тогда как на практике, вирт машины обычно пишут 3/4, а читают 1/4
Это не совсем виртуальные машины, а LXC/LXD контейнеры. Что-то более чем docker/k8s, но меньше чем обычные виртуальные машины.
Vladislav
А можно ли сделать устройство типа bcache с опцией writeback cache и уже поверх него поставить zfs? таким образом чтобы bcache решал вопрос с заполнением буфера на запись в HDD, а уже zfs поверх решала остальные вопросы?
Либо ждите пока bcachefs добавит скраб в реализацию
Либо смотрите в сторону LVM/mdadm с полным выносом журнала на nvme
sweetiefox
Либо ждите пока bcachefs добавит скраб в реализацию
Либо смотрите в сторону LVM/mdadm с полным выносом журнала на nvme
Ну мне кажется что LVM будет явно по медленнее в плане кэширования. Также у LXC есть интеграция из коробки с btrfs/zfs - чтобы не надо было тома ручками нарезать. А все это делалось уже автоматически.
riv
Это не совсем виртуальные машины, а LXC/LXD контейнеры. Что-то более чем docker/k8s, но меньше чем обычные виртуальные машины.
Linux довольно много всего пишет на диски даде в простое, больше чем windows-машины. Думаю и контейнеры тоже так себя поведут.
Кстати, контейнеры, вероятно будут у вас на fs dataset а не в виде zvol dataset
Vladislav
Это не совсем виртуальные машины, а LXC/LXD контейнеры. Что-то более чем docker/k8s, но меньше чем обычные виртуальные машины.
Рекомендую запустить систему на чистых HDD, запустить blktrace и снять дамп, а потом тестировать через btreplay проверять результаты
sweetiefox
Linux довольно много всего пишет на диски даде в простое, больше чем windows-машины. Думаю и контейнеры тоже так себя поведут.
Кстати, контейнеры, вероятно будут у вас на fs dataset а не в виде zvol dataset
Нет, при создании контейнера в основном zpool создается отдельный dataset который квотируется и потом сразу передается в контейнер, т.е. там поверх dataset нету никакой своей ФС сверху. Поэтому накладных расходов нету.
riv
Ну мне кажется что LVM будет явно по медленнее в плане кэширования. Также у LXC есть интеграция из коробки с btrfs/zfs - чтобы не надо было тома ручками нарезать. А все это делалось уже автоматически.
Lvm по синтетическим тестам, возможно и быстрее будет, но при большом кол-ве вирт машин, zfs позволяет их запустить больше чем lvm до момента начала неприемлимых тормозов.
Vladislav
Всем доброго времени суток. Ищу помощи специалистов по тюнингу ФС и умению сделать "все хорошо". Из группы Storage Discussions подсказали написать сюда.
Дано сервер - Ubuntu 20.04 LTS, ppc64le 80 x 3.49GHz, 512GB RAM
Диски
2 x 16TB 3.5" HDD SATA WD
1 x 1.6TB AIC SSD NVMe PCIe x8 Samsung
2 x 128GB M.2 SSD NVMe PCI4 x4 Samsung
+ (маленький диск под OS но он не в счет, его не трогаем)
Надо
Собрать дисковую подсистему для 20 контейнеров (это максимум), рабочий объем данных что нужен в горячем пуле не превышает 1TB, скорости All-Flash не ожидаются, по IOPS требования очень низкие. Возможно доустановить несколько NVMe дисков при необходимости. А также полностью затюнить все критические параметры.
Пока в текущем тестовом стенде сделано так, zfs последняя версия из репо. RAID1 из 2 HDD средствами zfs, 1.6TB под L2ARC, 1 диск на 128GB по ZIL SLOG, 1 диск на 128GB под метаданные (special device). Очевидно что нужен глубокий тюнинг всего этого дела.
Я вчитался в последний абзац
Так однозначно делать нельзя. Special device обязательно минимум зеркало, zil желательно тоже, потому что там находятся данные последних 1-10 транзакций
riv
Нет, при создании контейнера в основном zpool создается отдельный dataset который квотируется и потом сразу передается в контейнер, т.е. там поверх dataset нету никакой своей ФС сверху. Поэтому накладных расходов нету.
Да, я это и имел в виду. В zfs датасетом называют либо zfs fs либо zfs zvol - т.е. блочное устройство, но они исполтзуются как правило виртуалками.
А гипервизор какой предполагается?
Vladislav
riv
Я вчитался в последний абзац
Так однозначно делать нельзя. Special device обязательно минимум зеркало, zil желательно тоже, потому что там находятся данные последних 1-10 транзакций
Special содержат метаданные, при их гибели, данные не восстановить! А вот slog, да, не так фатально, но крайне не рекомендуется его без резерва оставлять.
sweetiefox
Да, я это и имел в виду. В zfs датасетом называют либо zfs fs либо zfs zvol - т.е. блочное устройство, но они исполтзуются как правило виртуалками.
А гипервизор какой предполагается?
LXC/LXD - это не виртуализация, а контейнеризация через cgroups+namespaces. "машины" получаются zfs fs внутри себя.
riv
Но slog/zil это 32-64гб
Возможно хватит даже 8-16Гб. Вообще не видел чтобы slog выл занят более чем на пару сотен Мб
riv
LXC/LXD - это не виртуализация, а контейнеризация через cgroups+namespaces. "машины" получаются zfs fs внутри себя.
Вы попробуйте дать нагрузку на ваш конфиг, посмотрите во что упрется. Не просто так в zfs нет механизма выноса записи на ssd, кроме синхронных вызовов.
Потому что zfs сбрасывает данные на диск раз в 5 сек, т.е. данные накопливаются 5 сек потом пишутся большой группой почти целиком последовательно.
В ram не синхронные вызовы попадают мнгновенно, по этому нет смысла их писать на ssd, а синхронные и так пишутся на slog.
Гипотетически, если бы механизм отложенной записи существовал, он был бы бесполезен, т.к. при длительной нагрузке, на ssd рано или поздно кончится место, а диски и и так пишут последовательно с максимально возможной скоростью.
Вместо bcach может быть имеет смысл проверить как будет работать с настройками по умолчанию и потом попробовать увеличить задержку сброса данных на диски и размер озу выделенный для zfs.
По сути вместе с slog мы получаем интеллектуальный writeback который подлерживает консистентность за счет разлеления потоков синхронной и не синхронной записи.
sweetiefox
Возможно хватит даже 8-16Гб. Вообще не видел чтобы slog выл занят более чем на пару сотен Мб
Можно ли сделать так - чтобы больше транзакций попадало в SLOG? например увеличив количество операций перед записью на основное устройство? или на SLOG попадают только метаданные, но не сами транзакции?
riv
Можно ли сделать так - чтобы больше транзакций попадало в SLOG? например увеличив количество операций перед записью на основное устройство? или на SLOG попадают только метаданные, но не сами транзакции?
Я же написал настройка zfs subfs всех или части контейнеров sync=olways заставит zfs все вызовы считать синхронными и соответсвенно писать серез slog, но скорее всего это все замедлит. Вы недоочениваете архитектурные решения лежащие в основе zfs. Ещё не столкнувшиюсь с пробоеммами вы пытаетесь их решить, а проблемы, возможно будут в другом.
riv
Можно ли сделать так - чтобы больше транзакций попадало в SLOG? например увеличив количество операций перед записью на основное устройство? или на SLOG попадают только метаданные, но не сами транзакции?
Ну грубо говоря я имею в виду коману:
zfs set sync=olways zpool\conteiners
riv
Но я думаю, что лучше будет оставить по умолчанию, т.е sync=auto
riv
Вы можете менчть эту настроку прямо находу и сравнивать эффект
George
Можно ли сделать так - чтобы больше транзакций попадало в SLOG? например увеличив количество операций перед записью на основное устройство? или на SLOG попадают только метаданные, но не сами транзакции?
у zfs нет tiered storage и асинхронного перекладывания данных в рамках одного пула. В общем то всё.
НО - обычно оно и не нужно, sync write по объёму небольшой и можно улучшить латенси записи с помощью slog (который - просто журнал перед записью асинхронно на обычные vdevs). async write итак будет преобразовано в псевдопоследовательную запись, комфортную hdd. Итог - ожидаемый перформанс всё время.
Стоит бенчить. Хотите перформанс ожидаемый - юзайте соответствующие диски.
George
меня как-то спрашивали про аналог windows storagespaces tiered storage. На определённых малых масштабах оно может выглядеть хорошо, но там любая запись итого будет умножена раза в 2-3 (пока данные с одного тира на другой "ночью" переедут и тд). Главное не уткнуться в момент когда 1й тир закончился финита ля комедия :)
Vladislav
Главное помните, что очень удобно бенчить реальными тестами через blktrace
George
нутаникс тоже хвалится своих гиперконвергентным стораджем и тирами, только я как то общался с товарищем из их саппорта - первая частая проблема саппорта нутаникса - когда кончился tier 1 сторадж (ну или локальный сторадж ноды, гиперконвергентность - она такая) :D
riv
меня как-то спрашивали про аналог windows storagespaces tiered storage. На определённых малых масштабах оно может выглядеть хорошо, но там любая запись итого будет умножена раза в 2-3 (пока данные с одного тира на другой "ночью" переедут и тд). Главное не уткнуться в момент когда 1й тир закончился финита ля комедия :)
Я об этом и пытался выше сказать. Механизмы zfs разгружают основные vdev от случайных чтений (cache vdev, special vdev) и случайной записи (slog, special vdev), оставшаяся нагрузка позволяет дискам работать с большой пропускной способностью. Дальше вместо добавления ssd tier для записи, часто выгоднее увеличить cache, увеличить special и перенести туда мелкие блоки, поставить более шустрый slog и т.д)
Обратите внимание, многое можно менять в настройках на ходу, но вот мелкие блоки на special если они запишутся на основной vdev уже сами не перенесутся. Т.е. это надо включать заранее, а заранее вы зне знаете сколько их будет (128GB мне кажется маловато) или же после включения эти данные записывать заново, разлеление происходит во время записи. Тоже самое касается метаданных при подключении special не сразу после создания пула. С другой стороны, тогда мелкие блоки будут охотно кэшироваться в cache vdev.
В общем zfs не просто так устроенна именно так как устроена.
Ivan
нутаникс тоже хвалится своих гиперконвергентным стораджем и тирами, только я как то общался с товарищем из их саппорта - первая частая проблема саппорта нутаникса - когда кончился tier 1 сторадж (ну или локальный сторадж ноды, гиперконвергентность - она такая) :D
я думал гиперконвергентность это когда сторадж и вм на одном серевере крутятся.
George
я думал гиперконвергентность это когда сторадж и вм на одном серевере крутятся.
ну это пока один сервер всё понятно. А дальше то сторадж размазывается, 100% данные вмки могут не помещаться на один сервер и тд
riv
ну это пока один сервер всё понятно. А дальше то сторадж размазывается, 100% данные вмки могут не помещаться на один сервер и тд
Я использую исключительно локальный zfs, т.к. по моей оценке, при использовании чего-то типа ceph всё станет намного медленее и дороже.
George
так что гиперконвергентность на масштабах - это либо жёсткое ограничение какой объём стораджа у вмки может быть локальным, либо локализация только горячих данных (и тут резко у стораджа появляются различные требования по умению размазывать данные, tiers и тд)
George
видел в mailing lists у openzfs ребят которые на локальных дисках в AWS юзают ZFS со сжатием чтобы ДАННЫЕ ПОМЕЩАЛИСЬ
George
ибо локальные диски по размеру ограничены
riv
видел в mailing lists у openzfs ребят которые на локальных дисках в AWS юзают ZFS со сжатием чтобы ДАННЫЕ ПОМЕЩАЛИСЬ
Сжатие, кстати довольно не плохо жмёт у zfs особенно zstd
Vladislav
я думал гиперконвергентность это когда сторадж и вм на одном серевере крутятся.
У нутаникса есть отдельный сторадж из их нод, который может работать как классическая схд
Nikita
меня как-то спрашивали про аналог windows storagespaces tiered storage. На определённых малых масштабах оно может выглядеть хорошо, но там любая запись итого будет умножена раза в 2-3 (пока данные с одного тира на другой "ночью" переедут и тд). Главное не уткнуться в момент когда 1й тир закончился финита ля комедия :)
и не вспоминайте... весь последний год я сплю и вижу, когда со storagespaces перееду на iscsi zfs.
sweetiefox
А можете подсказать на счет special devices и поведение при заполнении пула, т.е. что будет когда special device будет заполнен, а на основном vdev полно места? то весь дисковый пул встанет?
riv
А можете подсказать на счет special devices и поведение при заполнении пула, т.е. что будет когда special device будет заполнен, а на основном vdev полно места? то весь дисковый пул встанет?
колом не встанет, запись новых блоков метаданных будет производится на основные vdev. Это, разумеется в недалёкой перспективе, начнёт все сильнее и сильнее снижать производительность пула, т.к. все больше и больше метаданных будет записано на основные vdev и будет создавать на них дополнительную нагрузку в виде случайного ввода-вывода.
riv
А можете подсказать на счет special devices и поведение при заполнении пула, т.е. что будет когда special device будет заполнен, а на основном vdev полно места? то весь дисковый пул встанет?
Кстати, можно увеличивать размер блочных устройств в оставе vdev прямо на ходу. Я это использую так: когда не могу определиться с размером special vdev, я выделяю необходимый минимум через lvm и поверх lvm создаю zfs, по мере заполнения special увеличиваю размер через lvm потом прошу zfs учесть изменение размера, места на special прибавляется.
riv
Но считается что zfs лучше работает поверх голых блочных устройств без всяких lvm
sweetiefox
а можно ли как-то сказать zfs сколько в special отдавать под metadata, а сколько под мелкие блоки?
sweetiefox
т.е. задать ратио?
sweetiefox
или можно ли разделить - сделать 1 специальное устройство для метаданных, и 1 специальное устройство для мелких блоков?
sweetiefox
и еще - может ли увеличение таймаута записи sync с 5 секунд например 10 секунд - помочь в плане производительности? Или даже до 15 секунд. При условии что есть достаточного размера ZIL SLOG в очень большим и жирным размером - вроде Intel P1600X или P4801X?
Georg🎞️🎥
Василий
а можно ли как-то сказать zfs сколько в special отдавать под metadata, а сколько под мелкие блоки?
Можно указать какие блоки считать мелкими.
Василий
или можно ли разделить - сделать 1 специальное устройство для метаданных, и 1 специальное устройство для мелких блоков?
Можно по факту в special добавить еще одно зеркало, и тем самым увеличить его объем, получим 10 raid. Более того в такой конфигурации скорость работы special увеличится.
Georg🎞️🎥
Можно по факту в special добавить еще одно зеркало, и тем самым увеличить его объем, получим 10 raid. Более того в такой конфигурации скорость работы special увеличится.
А его в raidz3 какой нить можно собрать , интересно ?
Василий
Нет
Василий
Только зеркала
Василий
Но можно, зеркалить в глубь и ширь... например никто вам не запрещает сделать тройное зеркало ну или паласатое...
Vladislav
или можно ли разделить - сделать 1 специальное устройство для метаданных, и 1 специальное устройство для мелких блоков?
Буквально вопрос был выше уже такой...