Pull to refresh

Comments 38

Это не работает, забудьте. Держа на массиве с блоками (sic!) 4Kb сотню клиентских ВМ .vhd собранных с 3-4 шаблонов мы ожидали, что будет как в книжке про NetApp, коэффициент 8-10. Этого не вышло, dedup ratio был около 2-3. Т.е. включение базовой компрессии приводит к схожему результату – 40%. Для достижения коэффициентов 8-10 вероятно надо использовать офлайновую дедупликацию с ползучим по размеру блоком. Это как в storage pools новой Windows 2012 или ONTAP.

Хммм. А у вас партиции получившихся из шаблонов VM точно выровненные? Вроде как 2012 выравнивает правильно по умолчанию, а для 2008 и R2 надо предпринимать действия.
В вашем случае сильно похоже на сбитое выравнивание, поэтому дедупликация не может найти идентичные блоки (все те, что должна найти).

Кстати у NetApp тоже дедупикация с фиксированным блоком, чистый оффлайн с переменным блоком делался, но так и не вышел в свет, в связи с закрытием компанией направления VTL.

Машину собрали годную, 36 дисков по 300Gb SAS 15K, нашли 300Gb SDD Intel 710 серии (круче некуда на тот момент) и так далее.

Интересно, какова была рельная выгода по деньгам с брэндовым аналогом аналогичной мощности? Ну, без учета дальнейших чудес, просто затраты «на старте».

Стоит ZFS пулу заполниться, как он радикально деградирует по производительности.

Падение производительности при заполнении это неизбежное зло у любых «файловых систем», даже у тех стораджей, которые традиционно принято считать «чисто блочными», но, конечно, не у всех это падение в десять раз.
И чем больше фич сверчено поверх этой «файловой системы», тем заметнее падение.
Интересно, какова была рельная выгода по деньгам с брэндовым аналогом аналогичной мощности? Ну, без учета дальнейших чудес, просто затраты «на старте».

Хм. А чем брэндовый сервер помог бы автору топика в его проблемах с Nexenta? Аж ничем.
Я не про брэндовый сервер, а про брэндовый сторадж с соответствующей функциональностью «из коробки».
Впрочем, я уже посмотрелответ в более ранних постах, там называлась сумма в примерно 12 тысяч долларов.
А, простите, не так понял. Если я правильно понял этот сервер обошелся в 300К руб, сомнительно чтобы можно было найти даже БУ бренд на ебее за такие деньги, и это еще без учета доставки…
Да, цена-то хорошая, только работает… вот так… через раз ;)
Ну почему так себе… про переполнение таблицы дедупликации и деградацию ZFS должно быть сказано в документацию на Nexenta — если это не так — то да, минус им — но вообще ничего военного.
Апгрейд системы требует перезагрузки? Пффф… Скажите спасибо что не бекапа всех данных — это вполне обычное требование для СХД.
В сухом остатке — только проблемы связности iSCSI в Nexenta и Windows — при том что линуксовая версия работает нормально.
Все это конечно хорошо, в качестве сферических рассуждений в вакууме, но на практике обычно вопрос ставится «чтобы к утру работало, не то попадос на бапки списываем с виновного, того, кто это чуда нас уговорил купить»

Про отсутствие проблем с Linux отчасти радует, конечно, но у меня сложилось ощущение, что HOSTKEY это преимущественно Windows-хостинговая компания.
Так было с прошлом году, сейчас примерно 50/50 винда и линукс. С вводом в работу солусВМ мы закрыли эту тему на 100%. А новый control center наконец позволит нам пускать внешнего клиента в коньрольную панель с выделенными ресурсами.
Ну почему сферических в вакууме? в статье описан реальный опыт, а документацию надо читать хоть на нексенту, хоть на нетапп, хоть на емс, хоть на что… А по поводу «попадос на бабки» — так не вопрос, похожий по характеристикам NetApp та ебее, правда с FC — 40K, пусть ISCSI будет 30К — «nobody was fired for bying IBM», бабки на стол и нет вопросов. :)
Хотеть дешевле — есть дешвле, но сам топчешься по своим граблям. Стоит ли оно того? Для небольших компаний — однозначно стоит имхо. крупным же легче купить готовое за пару-тройку лимонов… Peace :)
Мне не нравится что в нексенте напрочь отсутствует защита от неверной настройки и аварийные отбойники. Это большой минус, можно заложить себе мину и потом не иметь возможности это исправить. Бакап-то мы держим, но не силами нексенты, а силами DPS и solusVM
Работает ровно, но в определенных режимах и под наблюдением. Аналогичная ISCSI полка с ssd и 36 дисками обошлась нам бы минимум в 30-40к баксов.
Только б/у Netapp если с ебэя взять за 10к баксов схожей емкости, но есть вероятность что он не случайно на ебее оказался…
Там с нетаппом есть существенная засада. Дело в том, что лицензии там non-transferrable, то есть вы теоретически получаете при покупке used — только голое железо. Которое можно, например, использовать для починки и расширения своего законно купленного. Но официально used-систему нельзя продать с «софтом».
Да, существуют способы это обойти так или иначе, но «буква закона» такова, к сожалению. лицензии продаются на конкретное имя (компании) и на конкретный номер purchase order.

А так — оказались они там на ебэе потому, что народ их активно юзает и активно апгрейдит, это очень популярный в америках сторадж.
Мы с Германии таскаем, но там копирастам надавали по рогам за такие ограничения как я понимаю. Так что если апгрейда не будет, то и не страшно. А запчасти там же можно брать
Это в Америке. В Европе легально купить б/у с софтом.
Купить-то можно и в Америке, но мнение NetApp по поводу того, кому были проданы лицензии это не меняет. :)
НургалиевЕвропейский суд разрешил, NetApp просто не может продавать в Европе non-transferrable лицензии AFAIK…
Ну если Нургалиев… Впрочм, я знаю, что все эти решения суда обычно написаны юридическим языком и обложены десятками сложно понимаемых условий, так что я бы не был столь однозначен и не радовался по одному факту того, что кто-то чего-то «разрешил». Реальность как всегда бывает сложнее схем.
По поводу выравнивания — я не видел там таких вариантов, мы храним ВМ в виде тонких .vhd, а линуксовые сидят в LVM по тому на машину. Подскажите где смотреть?
Ну я не спец по Нексенте, но уверен, что их партнеры в курсе проблемы.
Идея там в том, что смещение начала партиции должно укладываться в число, кратное размеру блока.
Допустим размер физического блока у дисков 4KB (ну или 512b, «по старому»), размер блока у ZFS тоже, допустим, 4KB.
А вот стандартное смещение первой партиции относительно физического начала диска у старых Windows 32762, что не делится нацело на 4096, таким образом получается, что блок 4KB у NTFS лежит началом в одном блоке ZFS, конец — во втором, и так далее. Из-за этого смещения, особенно если оно не совпадает у разных VM, получается так, что блоки ZFS, несущие один и те же файлы, из за вот этого вот смещения положенных поверх них блоков NTFS, не совпадают содержимым, когда дедупликация в них считает их хэши.
Заодно правильное выравнивание помогает наковырять процентов 10 производительности в ряде workloads, и уменьшить занятость памяти контроллера, не радикально, но бывает полезно.

Впрочем, я вот сейчас посмотрел на свежеустановленную 2008R2 SP1, она поставилась со смещением 105 906 176, что на 4096 нацело делится. Так что моежт я зря вам поклеп возвожу. Также правильно теперь ставится автоматом Server 2012.

Не спец в винде, но в 2008R2 SP1 уже вроде как с выравниванием все ок.
А, значит это результат интегрированного SP1 в моем дистрибутиве.
UFO just landed and posted this here
Да, про деградацию скорости работы zfs только ленивый не пишет в интернетах.

Скажите, у вас под кеш zfs один ssd или несколько?
Почему подключали через адаптек, а не напрямую в мать?
Какое стоит значение ashift?
Проводился ли эксперимент с физическим вытаскиванием в процессе работы дисков из стораджа? Если да, то что происходит в этом случае?
Расскажите какой тюнинг операционки производился?
Спасибо!
Кэш один, несколько дисков подключены через адаптек так как Нексента не видела встроенного sas контроллера на матери, пришлось поставьть hba имени адаптека. К матери ничего не подключил — все должно быть хотсвопным, а на матери таких портов нет.
Эксперименты мы проводили на холодную, и вытаскивали и полки подключали.
Тюнинга специального не делали, только один раз увеличили руками размер таблицы дд.
У нас Нексента от локального вендора, тоже на кучу проблем напаролись. Главная — низкая скорость «на выходе» через iSCSI.
А вы подробнее напишите, что за Нексента, куда таргеты цепляете, для чего используете
Смотрел нексенту. Был глубоко поражён тем, насколько плохо солярис отрабатывает дисковые ошибки уровня шины. (mpt2sas у них ещё хуже того, что в ванильном линуксе).
Ламера. Все это описано в документации и на форумах. Читать надо внимательно и продумывать сайзинг перед внедрением. С таким подходом с любым решением проблемы будут.
Нука, подробнее — где про отличную совместимость видны и нексенты написано на форумах? Сами что эксплуатируете? Напишите конфиг и тип задачи.
Совместимость comstar таргета и инициатора в новых серверных виндах это только один пункт из ваших «шокирующих деталей». Причем пока кроме как у вас нигде больше я не встречал. Нормально работает даже с MPIO.

Про дедупликацию в user guide написано в каждом разделе: «Use this parameter with caution, because it utilizes RAM resources intensively.» Насколько intensively написано в интернетах чуть ли не на каждом углу. Например, в блоге у Гонзалеса:
constantin.glez.de/blog/2010/03/opensolaris-zfs-deduplication-everything-you-need-know
constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupe
Поэтому не составляет никакого труда просчитать размер ARC и/или L2ARC для дедуплицированного тома.

Деградация производительности CoW файловых систем при полной заполненности это нормально by design. Поэтому в том же NetApp мануале и во всех admin guides по ZFS написано о необходимости оставлять 30% свободного места. Прочтите хотя бы официальный админ гайд по ZFS от сана/оракла или серию статей на сайте нексенты.

Про апгрейд с ребутом вообще непонятно, вы ожидали чего-то иного при обновлении software-defined стораджа?

У нексенты масса нерешенных проблем, что-то вроде iSCSI hangs on heavy IO load, удаление дедуплицируемого тома и прочие. Часть из них пофиксили в 3.1.4, часть в 4й ветке. Но вы не описали ни один их них. Все эти «шокирующие детали» результат плохого знания мат.части и недостаточно глубокого анализа выбранного продукта.

P.S. Да и intel 710 не самый прям распрекрасный вариант. Это лучший из дешевого.
Сам использую nexenta как быстрый и дешевый сторадж для некритичных и тестовых данных на шасси HP DL180G6 с 25 SAS 300GB 10k rpm и 64GB RAM на кластере из 5 хостов ESXi. В продакшене связка из 2х Dell EqualLogic PS4110XV с синхронной репликацией.
вот это годная статья, рекомендую.
Имею опыт. Более нескольких лет. Хочу добавить.

1. Не используйте дедупликацию в продакшене. Вообще. Фича из разряда «никогда не пользоваться». Каждый раз, когда она была включена, это заканчивалось пересозданием пула. Ибо все работает несколько месяцев, потом полная деградация производительности. Даже на пуле с давно выключенной дедупликацией. На машинах с 128-192-384Гб + l2arc 400-800Гб SSD.
2. Не используйте Нексенту с 16-32Гб в продакшене. Только для бэкапов. Все правильно пишут насчет zfs likes RAM. Ввиду cow (что по моему мнению не совсем корректное название, copy-on-write — это как раз про стандартные блочные устройства со снапшотом, где данные именно копируются при изменении _части_ блока, что приводит к деградации производительности, здесь просто запись в новое место) запись происходит всегда последовательно, что, в свою очередь приводит к фрагментации. И нужен большой кеш на чтение. Очень большой.
3. Так за много лет и не определился — выключать ли prefetch. С одной стороны, трата памяти и лишние iops, с другой — попадания все же есть. Интуитивно — много памяти, маленькая нагрузка — оставлять. Большая нагрузка — выключать, ибо пользы мало. По ощущениям и статистикам — радикального изменения не наблюдается.
4. Касаемо виртуализации. Не знаю насчет HyperV, не пользую, для esxi — не используйте один большой lun. Все-таки iscsi reservations, будь они не ладны, сильно дегрейдят. Было древнее правило (точно не помню) 5-10-20. 5 высоконагруженных машин на лун и т.д. Уже все гораздо лучше, но общий принцип остался. То есть 200-400 вм на одном луне совсем не есть хорошо, как оказалось. Да и не проблемы это нексенты, это проблемы vmfs.
5. Касаемо сжатия. Есть два фактора: увеличивает производительность на чтение (меньше нужно читать), увеличивает фрагментацию (блок переменного размера). Эти два фактора взаимоподавляют друг друга. Фиг его знает, но всегда держу включенным. По ощущениям (zpool iostat) проявляется только при недостатке места. В виде увеличения iops на чтение и снижении производительности (в мб/с). Включать, естественно, zip9 не надо, нужно самый простой.
6. Естественно, все говорят в интернетах про raid-10, не наблюдаю такого, есть две идентичные системы по 40+ дисков, в одной raid-z1, в другой raid-10. raid-z1 иногда даже лучше по производительности, нагрузка одинаковая. Наверное, нужно подробнее разбираться почему. Было просетаплено исключительно из-за места. Ожидался дегрейд производительности. А нет его.
7. Про VAAI. Ранее (версии 3.0) совокупно с iSCSI приводили к падению. Так и не понял, пофиксили или нет, в высоконагруженном кластере выключено, в так себе — включено. И работает. Непонятно, хотелось бы отзывов.

Тут еще есть, просто всего не упомню. Общее впечатление: лучшее, что есть. Рвет по производительности (в разы) коммерческие системы, но есть проблемы, куда без них. К сожалению, они (грабли) не описаны. Например, про сервера HP: www.nexentastor.org/boards/2/topics/8941
Да и много чего.

Опыт основан на серверах HP с 16+ дисков (иногда 100) и 128Г+ памяти (иногда 384Г), esxi + iscsi (иногда nfs), Есть опыт использования HA cluster (пока не продакшн, но ведет себя достойно. можно спокойно нажать ресет, ничего не падало пока).

Буду рад пообщаться насчет нексенты, дома не использую, поэтому врядли смогу ответить на вопросы вроде «хватит ли 16Гб для дедцпликации». Скорее всего нет.
А какой обьем данных у вас дедуплицировался при проблемах?
Как быстро переключается HA кластер на резервную ноду? Меняли ли таймауты в гипервизоре?
Какая конфигурация нод? Какой плагин используете (simple или полноценный)?
Используете 3.1.3.5 или уже обновились на 3.1.4?
P41X использовать для нексенты имхо совсем не стоит. Лучше уж купить нормальный LSI HBA, а 41X продать страждущим.
Как кстати raid-z1 в продакшене? Не страшно за пул? Как собирали vdev'ы по сколько физ. устройств? В любых raid производительность vdev на запись будет равна производительности 1 (одного) диска, поэтому интересно посмотреть как сильно вы делили ваши 40 устройств на vdev'ы.
> Если места на пуле не станет, это будет катастрофа – придется аварийно расширять пул

Для ZFS расширение существующего пула никогда не было аварийной ситуацией. Это её свойство «расширяться», делается просто и безопасно без отмонтирования ФС в пуле.

> дисковый пул Нексенты в идеале должен состоять из одинаковых дисков, собранных в одинаковые raid-группы. Вы не сможете в дальнейшем расширять эти группы или менять в них тип raid.

Это да, в идеале. Но ZFS пул позволяет собирать отдельные VDEV в различные группы RAID или использовать единичные устройства подходящей ёмкости, которые впоследствии можно дополнить до mirror VDEV. Для добавления в пул VDEV с отличной от нормальной схемы построения групп накопителей, используемых в пуле, есть опция командной строки, разрешающую данную ситуацию.
Sign up to leave a comment.