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Гб для дедцпликации». Скорее всего нет.
В целом интересно. Несколько поверхностно и скучно, автор (странно, ведь вроде разработчик reactos) плавает в некоторых фундаментальных вещах.
Но! Подобной систематизированной информации (хотя бы достойной попытки) никогда не видел в открытом доступе.
Ну и позавидовал его выдержке, когда за камерой некий студент со знаниями «ваш финдовз — кака, а линукс — зашибись», при этом явно не зная ни того, ни другого, нес какую-то ахинею с попаданием ~3% в реальность.
Для того, чтобы на L2 самым быстрым способом начать передавать фрейм дальше, нужно прослушать преамбулу и получить dst-mac.
Для того же на L3 нужно получить dst-ip в заголовке (пусть даже время на поиск маршрута == 0, что не так).
Быстрее принципиально никак.
Вы говорите про доли микросекунд. Это согласуется с вышенаписанным? (сам не считал)
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Гб для дедцпликации». Скорее всего нет.
Но! Подобной систематизированной информации (хотя бы достойной попытки) никогда не видел в открытом доступе.
Ну и позавидовал его выдержке, когда за камерой некий студент со знаниями «ваш финдовз — кака, а линукс — зашибись», при этом явно не зная ни того, ни другого, нес какую-то ахинею с попаданием ~3% в реальность.
Для того же на L3 нужно получить dst-ip в заголовке (пусть даже время на поиск маршрута == 0, что не так).
Быстрее принципиально никак.
Вы говорите про доли микросекунд. Это согласуется с вышенаписанным? (сам не считал)
«не увидЕте снова». Поправьте пожалуйста.
tar xf 2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO.bz2