Комментарии 9
Важно понимать, что используемые в настоящий момент интерфейсы SAS и SATA
Причём статистика показывает, что SAS не сильно-то надёжней SATA
Говоря прямо, SAN и NAS стоят кучу денег, и на них уходит до трети всех затрат на «железо» в дата-центрах компаний. Да, производители таких продуктов заработали себе отличную репутацию, поэтому их продукцию используют для хранения самых критически важных данных, но давайте будем честны — в этих забитых дисками коробках размером с рефрижератор нет никакой магии.
Вообще ноль магии — для рукастых есть OpenIndiana, для обычных — Nexenta
Этому дорогущему безумию можно положить конец, но для этого необходим нестандартный и креативный подход представителей крупного бизнеса
Не, не нужен — есть уже готовые к продакшену системы, нет денег — собери сам, мало денег — иди к нексенте.
ZFS божественна, все рейды — фуфло.
Последний раз, когда я смотрел на luminos, она вела себя крайне неприлично при любых пертурбациях в районе SAS-шины. mpt2sas для соляриса ещё хуже, чем в линуксе.
Простите за неожиданный камбэк.
Читал про это, но у меня была возможность выбрать железо, с которым mpt2sas работает прилично. Уже более двух лет LSI 9207-8i просто работает, хотя по началу пришлось поуговаривать, да.
mpt2sas для соляриса ещё хуже, чем в линуксе.
Читал про это, но у меня была возможность выбрать железо, с которым mpt2sas работает прилично. Уже более двух лет LSI 9207-8i просто работает, хотя по началу пришлось поуговаривать, да.
Какая у вас средняя утилизация дисков? По моим наблюдениям проблемы начинаются за 60-70%.
В пятницу чистил снапшоты за два года, было как раз около 70-80% — нечего страшного не происходило.
Но у меня нагрузка почти никакая — файлопомойка по SMB для 20 человек, виртуалки по NFS и iSCSI, которые нагружают диски только при старте.
Но, вообще, выше 90% лучше не доводить, так пишут в манускриптах.
А какие именно проблемы вылазят?
У меня основная проблема — при недоступности Primary Domain Controller самба-сервер может начать тупить и перезапустить его уже будет нельзя, только ребут, хорошо, хоть, что ребут давно уже сделан перегрузкой ядра без ухода в биос — пара минут и всё обратно оживает само.
Но у меня нагрузка почти никакая — файлопомойка по SMB для 20 человек, виртуалки по NFS и iSCSI, которые нагружают диски только при старте.
zpool iostat tank
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
tank 1.73T 1.89T 80 386 745K 3.65M
Но, вообще, выше 90% лучше не доводить, так пишут в манускриптах.
А какие именно проблемы вылазят?
У меня основная проблема — при недоступности Primary Domain Controller самба-сервер может начать тупить и перезапустить его уже будет нельзя, только ребут, хорошо, хоть, что ребут давно уже сделан перегрузкой ядра без ухода в биос — пара минут и всё обратно оживает само.
Там проблемы много ниже уровнем. Краткая суть: encolsure обеспечивает в один момент времени обслуживание одного диска. Для этого диск и контроллер согласовано организуют процесс переключения. Если диск умирает или ему очень плохо, плюс высокая загруженность, то channel в enclosure не закрывается, блокируя IO по всем соседям. После этого идут ошибки IO (по таймауту) на соседях. Через некоторое время контроллер перезагружает enclosure (SCSI bus reset, resetting bla-bla-bla и т.д.), но если запросов много, то часть из них затыкается на слишком долгое время
Таймауты по IO возвращаются в ОС, файловую систему, приложения, клиентов приложений и т.д.
Таймауты по IO возвращаются в ОС, файловую систему, приложения, клиентов приложений и т.д.
ZFS имеет ряд собственных нюансов и далеко не идеальна. Если использовать ее не разобравшись в этих нюансах, то и данные потерять не долго. Не говоря уже про всякие тонкости и оптимизации для достижения хорошей производительности и т.д. Достаточно вчитаться вот в этот документ от разработчиков FreeNAS.
Как пример:
For maximum performance and reliability, you should never try to use ZFS with less than 8GB of RAM and a 64-bit system under any circumstances, regardless of the size of your pool. We typically see at least 1-2 people every week that break this rule and they lose their pools suddenly. There is no recovery if you damage your pool and ignoring this warning.
It is not recommended that VDevs contain more than 11 disks under any circumstances.
FreeNAS’ ZFS stripes data in chunks up to 128 kilobyte. If you will be using compression (default is enabled/lz4) with FreeNAS 9.2.1+ then the following slide does not apply. Compression adds a layer of complexity because each block of data will be compressed to some arbitrary smaller size, so planning for ideal block allocation is impossible.
For home users in particular, your bottleneck is certainly going to be your Gb NIC and not your pool unless you are using woefully inadequate hardware for FreeNAS.
А сама статья оставляет впечатление, что автор не в курсе, что большие вендоры тоже давно смотрят на сегмент Scale-out систем хранения и на программно определяемые СХД. И на рынке давно уже разносолье готовых решений (из коробки) на эту тему и за ваши деньги. Не все компании могут позволить себе держать штат высококвалифицированных программистов и админов, что бы пилить собственное решение под себя. По этому наравне с классическими решениями хранения, те же самые компании продвигают и продают так называемые «легко масштабируемые» Scale-out и software defined storage. A SMB 3.0 от мелкомягких не единственный протокол в мире IT, годный для получения доступа к хранимым данным ;).
Как пример:
For maximum performance and reliability, you should never try to use ZFS with less than 8GB of RAM and a 64-bit system under any circumstances, regardless of the size of your pool. We typically see at least 1-2 people every week that break this rule and they lose their pools suddenly. There is no recovery if you damage your pool and ignoring this warning.
It is not recommended that VDevs contain more than 11 disks under any circumstances.
FreeNAS’ ZFS stripes data in chunks up to 128 kilobyte. If you will be using compression (default is enabled/lz4) with FreeNAS 9.2.1+ then the following slide does not apply. Compression adds a layer of complexity because each block of data will be compressed to some arbitrary smaller size, so planning for ideal block allocation is impossible.
For home users in particular, your bottleneck is certainly going to be your Gb NIC and not your pool unless you are using woefully inadequate hardware for FreeNAS.
А сама статья оставляет впечатление, что автор не в курсе, что большие вендоры тоже давно смотрят на сегмент Scale-out систем хранения и на программно определяемые СХД. И на рынке давно уже разносолье готовых решений (из коробки) на эту тему и за ваши деньги. Не все компании могут позволить себе держать штат высококвалифицированных программистов и админов, что бы пилить собственное решение под себя. По этому наравне с классическими решениями хранения, те же самые компании продвигают и продают так называемые «легко масштабируемые» Scale-out и software defined storage. A SMB 3.0 от мелкомягких не единственный протокол в мире IT, годный для получения доступа к хранимым данным ;).
ZFS имеет ряд собственных нюансов и далеко не идеальна. Если использовать ее не разобравшись в этих нюансах, то и данные потерять не долго. Не говоря уже про всякие тонкости и оптимизации для достижения хорошей производительности и т.д. Достаточно вчитаться вот в этот документ от разработчиков FreeNAS.
К сожалению нет такой универсальной ФС, чтобы и быстрая на любых размерах файлов и дедупликация и памяти не ела и без фрагментации и неубиваемая.
Так вот ZFS ест очень много оперативки, особенно после включения дедупликации, не особенно шустрая в сравнении с ext2 или fat — это, конечно минусы.
К плюсам, за все 5 лет использования, я могу отнести абсолютную неубиваемость — там где generic raid сказал бы — вашим данным хана, ZFS выдала мне всё до байтика за минусом пары снапшотов, попавших в бэдблоки на, как оказалось, заведомо испорченных WD RE в зеркале. Коротко ещё раз — оба диска в зеркале были куплены с бэд-блоками (нехороший поставщик), вся информация с них восстановлена штатными средствами ZFS на рабочем сервере не уходя в оффлайн. При чём ZFS на этих бэд-блоках работала где-то год, тормозила при скрабе, но основные функции выполняла на 100%
Покажите мне рейд, который из такой ситуации все данные выдаст без колдовства и уж тем более не уходя в оффлайн.
По поводу «повышения производительности». Цитата с solarisinternals: «Tuning is often evil and should rarely be done.»
Проще говоря — настройки из коробки подойдут для большинства задач. Можно тюнить ZFS зная, что делаешь и для чего, но если не знаешь — не трогай — сделаешь только хуже. Но это относилось к родной соляре, которую настраивали сановые инженеры. Фрю и линукс, приходится настраивать самим. Основная проблема, которую нельзя исправить после установки — размер сектора создаваемого пула должен соответствовать физическому размеру сектора диска, что положительно сказывается на перформансе. Но сейчас уже все сборки zpool по-умолчанию выставляют ashift = 12.
We typically see at least 1-2 people every week that break this rule and they lose their pools suddenly
Реализация во FreeNAS, видимо, прекрасна — я не знаю, что надо делать с ZFS, чтобы потерять данные, с рейдами я наелся по уши — они не выдержали бы и десятой части того, что спокойно переносит ZFS.
There is no recovery if you damage your pool and ignoring this warning.
Инженеры сана сделали файловую систему, которой не нужен рекавери. Есть скраб, есть резильвер, на соляре этого достаточно.
It is not recommended that VDevs contain more than 11 disks under any circumstances.
Это прекрасно! Это многое говорит о FreeNAS, нежели о ZFS.
FreeNAS’ ZFS stripes data in chunks up to 128 kilobyte. If you will be using compression (default is enabled/lz4) with FreeNAS 9.2.1+ then the following slide does not apply. Compression adds a layer of complexity because each block of data will be compressed to some arbitrary smaller size, so planning for ideal block allocation is impossible.
Почему же на соляре никаких проблем со сжатием не существует, а существует только больше свободного места и незаметная глазу нагрузка на процессор?
For home users in particular, your bottleneck is certainly going to be your Gb NIC and not your pool unless you are using woefully inadequate hardware for FreeNAS.
Про неадекватное железо — полностью поддерживаю. На встроенном в дешёвую материнку SATA-контроллере, используя обычную DRAM без ECC можно поставить фринас и кричать, что зфс ваш говно. Так боле-менее понятно.
A SMB 3.0 от мелкомягких не единственный протокол в мире IT, годный для получения доступа к хранимым данным
SMB это больше фронт-енд протокол, ZFS раскрывается при использовании в бэк-енде — атомарные снапшоты с возможностью немедленной обработки скриптами — к примеру инкрементальное копирование в сетку на резервный бэкап-сервер, причём эти снапшоты не дают никакого оверхеда и не вносят побочных эффектов, как в LVM или бтрфс; нативная поддержка NFSv4 ACL, совместимая с MS NTFS ACL; сжатие выбранных томов разными алгоритмами; дедупликация (осторожно — нужно много оперативки); кэш на чтение L2ARC; кэш на запись ZIL; поддержка iSCSI и т.п. А самое главное — поразительная живучесть, чтобы сломать ZFS надо гвоздь в винчестер забить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Анархия и хранение данных: есть ли будущее у SAN