Что будет если/когда умрут SSD диски под l2ark и ZIL?

[BadSimon]

Собственно сабж.

Либо по очереди, т.е. какие последствия после выхода из строя ссд с л2арк или выхода из строя ссд для зил будут для DB 1C, OS, etc?

Хранилка используется в качестве хоста с хардами для ВМ. Созданы пул raidZ1 по 5 дисков. На ВМках крутится в основоном винда 2012-2019 с файловой 1Ской.

П.С. Скорости, "вроде бы", хватает, но её всегда мало!)) Отсюда и вопрос, если начать разгонять пул такими плюшками, то какие последствия меня ждут?

 

[mav@]

В значительной степени зависит как именно они будут помирать. Если помрут тихо и в один день, то потеря L2ARC не грозит вообще ничем кроме ожидаемого снижения производительности. Потеря SLOG на живой системе приведет к тому, что журнал просто станет писаться на основные диски, так-же со снижанием производительности. Потеря SLOG во время когда пул экспортирован может привести к потере трафика за несколько секунд, пул просто откатится на последнюю транзакцию. Хуже будет если диски вместо смерти начнут тупить и т.п. В таком случае вся система может стать нестабильной.

Но я бы хотел отметить, что понятия DB, ВМ и RAIDZ не смешиваются. Оные нагрузки лучше работают при меньших размерах блоков и больших IOPS, в то время как RAIDZ не эффективен для мелких блоков и не блещет IOPS, предпочитая высокую последовательную скорость.

 

[BadSimon]

Благодарю за ответ! Но, возможно я не полно описал.

Но я бы хотел отметить, что понятия DB, ВМ и RAIDZ не смешиваются.

Хочу уточнить, базы данных 1C будут находиться внутри ВМ, а вот диск ВМ будет на фринасе. Не? Лучче железный рейд? В перспективе, создать сервер бадынных, опять же на виртуалке, mssql под 1С.

Оные нагрузки лучше работают при меньших размерах блоков и больших IOPS, в то время как RAIDZ не эффективен для мелких блоков и не блещет IOPS, предпочитая высокую последовательную скорость.

Так для БД и нужна последовательная запись. Подкинуть ссд для слога, поболее оперативки и очень интересно должно получиться. Ошибаюсь?

P.S. Еще вопрос, не по теме, если использовать не hdd, а ssd, то нужен ли тогда ссд под l2arc и slog? Если да, то на сколько они увеличат скорость?

 

[mav@]

Лучче железный рейд? В перспективе, создать сервер бадынных, опять же на виртуалке, mssql под 1С.

Про железный RAID я не говорил. Я имел в виду MIRROR вместо RAIDZ. У него кратно лучше IOPS.

Так для БД и нужна последовательная запись. Подкинуть ссд для слога, поболее оперативки и очень интересно должно получиться. Ошибаюсь?

Для БД последовательная заниси? Это что-то новое или редкое. Чаще таки случайная и короткая. SLOG полезен для быстрого выполнения коммита транзакций в БД.

P.S. Еще вопрос, не по теме, если использовать не hdd, а ssd, то нужен ли тогда ссд под l2arc и slog? Если да, то на сколько они увеличат скорость?

Смотря какие будут SSD. L2ARC скорее всего нет, а SLOG -- возможно, но он должен быть крайне быстрым, например NVDIMM.

 

[BadSimon]

Про железный RAID я не говорил. Я имел в виду MIRROR вместо RAIDZ. У него кратно лучше IOPS.

А если противопоставить фринас на моём текущем железе(hp dl380g7/2*5620/32mem+hp d2700) и, к примеру, дешевый рейд hp p812/1g battery. Что будет предпочтительнее под мои задачи? Понятно, что ни каких фишек zfs там не будет, но всё таки, если рассматривать ситуацию со стороны быстродействия?
Повторюсь, ВМ это word/excel + 1С, при чем изначально 1Ска будет файловой, т.е. в каждой ВМ будет минимум по одной базе, а то и не по одной. А mssql только в перспективе. На старте будет около 5-7 виртуальных машин(расчетная мощность 50+ ВМ), соответствено минимум 5-7 БД. Каждая машина расчитывается на 5-20 пользователей. Когда будет больше - будем внедрять mssql, т.к. наш 1Сник сказал что даже предпочтительнее использовать файловую 1Ску для малого кол-ва пользователей в одной базе.

Для БД последовательная заниси? Это что-то новое или редкое. Чаще таки случайная и короткая. SLOG полезен для быстрого выполнения коммита транзакций в БД.

Я еще "плаваю" в этой теме. Видимо, не внимательно читал. Спасибо за уточнение.
Отсюда сразу вопрос, какие размеры блоков указывать? Первый раз указывается размер при создании zpool, по дефолту там стоит 128к, и второй раз указывается при создании zvol, тут дефолт почему-то плавает. Для ВМ с файловыми БД какие устанавливать размеры?

Смотря какие будут SSD. L2ARC скорее всего нет, а SLOG -- возможно, но он должен быть крайне быстрым, например NVDIMM.

Спасибо за ответы. Как я понял, можно обходится и без ссд, просто хорошо увеличив оперативку - 128+!

П.С. Просто очень понравился Ваш продукт и хочется использовать именно его под мои задачи, не смотря на скепсис моих коллег по поводу "сторонних поделок", их мнение - создать самому всё нуля! Под бэкапы есть старенький "железный" нас, а вот под ВМ пока ни чего нет. Отсюда куча вопросов. Еще раз, благодарю за вашу помощь!

 

[alex821982]

Про железный RAID я не говорил. Я имел в виду MIRROR вместо RAIDZ. У него кратно лучше IOPS.

А можно про это поподробнее где то цифры и тесты увидеть?
Недавно проводил тесты, не знаю может быть они конечно не корректны, но к примеру такая прога как ATTODiskBenchmark
в виртуальной машине на RaidZ из 4 SATA SSD выдает намного больше IOPS чем на RAID1 из двух NVME SSD
как так получается?

 

[mav@]

Сравнивать IOPS для SSD -- занятие не самое благодарное, даже если тест поставлен корректно. Но просто если логическт подумать: в случае MIRROR каждый диск способен читать независимо, а писать в паре с другим, в то время как в случае RAIDZ читать и писать должны все диски одновременно. Соответственно RAIDZ быстрее на линейной записи и крупных блоках, а MIRROR во всех остальных.

 

[BadSimon]

А на мои вопросы я могу получить ответы?

 

[mav@]

Это публичный форум, а не платная поддержка. Тут никто никому ничего не должен. А подобные вопросы уже все многократно отвечены в мануале и как минимум английских ветках форума.

Что касается сравнения с железным RAID, то вопрос где он будет стоять. Если локально в сервере с VMware или чем-то, то там конечно будет преимущество локального доступа, но доступ будет только локальный и миграция ВМ между хостами ВМ будет только с миграцией данных. Если же строить отдельный NAS, то там железный RAID не нужен и даром, софт как минимум функциональнее.

Что касается размера блоков, то тут зависит от характера использования. Большие блоки хороши для линейного и выровненного доступа, чего в случае ВМ ждать не приходится. Мелкие блоки лучше работают на произвольном доступе, но если опустить сильно низко, то последовательный доступ уж слишком сильно страдает. Для ВМ мы на данный момент рекомендуем MIRROR и блок 16КБ.

 

[BadSimon]

Это публичный форум, а не платная поддержка. Тут никто никому ничего не должен. А подобные вопросы уже все многократно отвечены в мануале и как минимум английских ветках форума.

Благодарю за ответы!
С английским туго, понимаю что это не оправдание, но всёж! А инфы действительно полно, да вот только, зачастую, могут 2 источника противоречить друг-другу... Поэтому и задаю вопросы, так сказать, первоисточнику.

Что касается сравнения с железным RAID, то вопрос где он будет стоять. Если локально в сервере с VMware или чем-то, то там конечно будет преимущество локального доступа, но доступ будет только локальный и миграция ВМ между хостами ВМ будет только с миграцией данных. Если же строить отдельный NAS, то там железный RAID не нужен и даром, софт как минимум функциональнее.

Вы меня не совсем верно поняли. Я спрашивал не про сравнение freenas'a на железном рейде против freenas'a на хба адаптерах, а о сравнении NAS'a, построеного на хардварном рейде с lin/win таргетом iscsi/fc, без zfs, без freenas'a и NAS, с установленным freenas, конечно, с hba адаптером и прямым доступом к полке/дискам, софтовым рейдом и всеми плюшками ZFS.

Для ВМ мы на данный момент рекомендуем MIRROR и блок 16КБ.

Я бы хотел уточнить момент, recordsize zpool оставить неизменным 128к? Или тоже сократить? Если да, то до какого размера? Использоваться планирую сасы хдд 10к 300-900.

Еще хотел уточнить. Вы не рекомендуете использовать коммандную строку, оно и понятно почему. Так вот вопрос по поводу удаления кэшей. Как через вебку(11.2) отключить/удалить диски-кэши? К примеру, подошел примерный срок эксплуатации SSD slog'a, соотвественно, надо старый удалить, а новый добавить. Как добавить - понятно. Удалить - нет, не разваливая/отключая пул.

 

[mav@]

Вы меня не совсем верно поняли. Я спрашивал не про сравнение freenas'a на железном рейде против freenas'a на хба адаптерах, а о сравнении NAS'a, построеного на хардварном рейде с lin/win таргетом iscsi/fc, без zfs, без freenas'a и NAS, с установленным freenas, конечно, с hba адаптером и прямым доступом к полке/дискам, софтовым рейдом и всеми плюшками ZFS.

Если бы мы не считали что можем сделать лучше конкурентов, мы бы этим не занимались. Как я сказал, железный RAID с непосредственным подключением может иметь большую производительность чем NAS, он ведь прямо в систему вставляется. Но если речь уже о вариантах NAS, то зачем ограничивать себя заведомо меньшими возможностями железного RAID, когда софт/ZFS может много больше и достаточно быстро? Безусловно, функциональность ZFS дается не бесплатно, но начиная с какого-то уровня задач без нее уже не обойтись.

Я бы хотел уточнить момент, recordsize zpool оставить неизменным 128к? Или тоже сократить? Если да, то до какого размера? Использоваться планирую сасы хдд 10к 300-900.

recordsize устанаваливется не для zpool, а для каждого dataset отдально. Для ZVOL его полным аналогом является volblocksize. Уж не знаю кому в Sun пришла идея ввести два разных термина для одного и того-же. Причина почему recordsize по умолчанию истанавливается в 128К лишь в том, что dataset в отличие от ZVOL обычно используются для линейных операций и они обычно выровнены. Тем кто используют ВМ или БД не через iSCSI/FC а через SMB/NFS так-же рекомендуется уменьшать recordsize до тех-же 16КБ или размера блока ВМ/БД.

Еще хотел уточнить. Вы не рекомендуете использовать коммандную строку, оно и понятно почему. Так вот вопрос по поводу удаления кэшей. Как через вебку(11.2) отключить/удалить диски-кэши? К примеру, подошел примерный срок эксплуатации SSD slog'a, соотвественно, надо старый удалить, а новый добавить. Как добавить - понятно. Удалить - нет, не разваливая/отключая пул.

Я не проверял на 11.2, но думаю такая возможность должна быть если войти в статус пула и там выбрать соответствующий диск. Нет причины почему не должно быть. Ищите. В новом интерфейсе 11.3 точно есть. Ну или в крайнем случае это можно сделать и из коммандной строки -- код FreeNAS старается по минимуму кешировать информацию о пуле.

 

[BadSimon]

Благодарю Вас за исчерпывающие ответы!

Можно поинтересоваться, когда выйдет 11.3 стабильная версия?

 

[mav@]

Релиз -- где-то после Нового Года. BETA1 для покататься вышла неделю назад.

 

[BadSimon]

Видел, спс! Оценил допил дизайна UI. Сморится еще приятнее! Ставил ради "посмотреть", кататься не пробовал.
Ждём стабильную версию!