Comments 38
Хотелось бы увидеть приблизительную цену на некоторые наиболее популярные модели.
Подскажите а контролееры работают Active-Active? Возможен ли интерфейс FC?
«Они использовали 24 штуки Toshiba PX04SV SAS 3.0 SSD. Такого количества SSD недостаточно, чтобы перегрузить контроллеры СХД»
business.toshiba-memory.com/en-us/product/storage-products/enterprise-ssd/px04svb-px04svqxxx.html
Sustained 4KiB Random Read 270,000 IOPS
Этот массив не может нагрузить эти диски. Узким местом является производительность контороллеров. 2 мс для All flash это очень много.
Стоимость нужно сравнивать Tb/$ при равной производительности, и в этом случае я не думаю что будет большая разница.
business.toshiba-memory.com/en-us/product/storage-products/enterprise-ssd/px04svb-px04svqxxx.html
Sustained 4KiB Random Read 270,000 IOPS
Этот массив не может нагрузить эти диски. Узким местом является производительность контороллеров. 2 мс для All flash это очень много.
Стоимость нужно сравнивать Tb/$ при равной производительности, и в этом случае я не думаю что будет большая разница.
Вы сравниваете поизводительность диска внутри сервера без прослойки в виде RAID и прочих уровней абстракции. При этом сервер имеет монопольный доступ к SSD. В СХД такой режим в принципе не возможен. Между ОС и диском есть немало элементов с ненулевыми задержками и ограниченными очередями. Плюс СХД предназначена для одновременной работы с многими хостами. И поэтому не в режиме работы «однин хост — один том» не удастся достичь пиковой производительности СХД.
Что касается latency в 2 мс, это просто мы условно ограничили показатель IOPS как некий «приемлимый». Если взглянуть на график, большая часть теста проходит с показателем не более 1 мс.
Что касается latency в 2 мс, это просто мы условно ограничили показатель IOPS как некий «приемлимый». Если взглянуть на график, большая часть теста проходит с показателем не более 1 мс.
Я не сравниваю, я указал что диски не являются узким местом для этой системы. Мы с вами написали одно и тоже, данная производительность ограничивается контроллерами, а не дисками. Вы расписали в каких местах тормозит контроллер. Latency в 2 мс для All Flash не является «приемлемым», если вы сравниваете с Enterprise. Если бы Вы указали в тексте значение IOPS для 1 мс, то выглядело бы значительно лучше, тем более разница не так уж и велика.
На вкус и цвет все фломастеры IOPS разные. Для меня вообще всегда странно выглядит тест с 100% чтения. Вы где в жизни такие сервисы видели? Которые только читают и ничего не пишут. Или читают только блоком одного размера. А если читать блоком 64KiB, то 270k IOPS резко превратятся в тыкву? Это уже не говоря про то что отдельный диск, с возможностью потерять все, и диск в RAID это совершенно разные диски, в том числе по производительности. И сравнивать их в лоб некорректно. Кстати а Тошиба указала при каком количестве потоков и с какой latency один диск выдает 270k IOPS? А сможете взять 5 таких дисков и на одном сервере показать нам 1 миллион IOPS с разумным временем отклика хотя бы в синтетике?
А почему графики с ватермарком сторайджревью? Это перевод статьи? Или вы просто у них графики взяли?
Мы указали в статье, что взяли их результаты тестов
В таком случае принято указывать ссылку на оригинал.
И если вы сами тесты не проводили, как вы сделали вывод, что
где графики нагрузки на контроллеры? порты?
И если вы сами тесты не проводили, как вы сделали вывод, что
Такого количества SSD недостаточно, чтобы перегрузить контроллеры СХД
где графики нагрузки на контроллеры? порты?
где графики нагрузки на контроллеры? порты?
Даже грубый подсчет для максимальных показателей 450K IOPS@4K даст нагрузку на порты менее 16Gbit/s, а для последовательного доступа 6000 MB/s ~48Gb/s. Что сильно меньше сумарной пропускной способности портов СХД в тесте (8x 16Gb/s).
По контроллерам, к сожалению, СХД не предоставляет отчета о нагрузке.
По контроллерам, к сожалению, СХД не предоставляет отчета о нагрузке.
тогда тем более не понятно, как сделан вывод
Такого количества SSD недостаточно, чтобы перегрузить контроллеры СХД
и на чём он основывается у вас. Или это вы так интерпретировали фразу в оригинале:
Overall, the XS5200 did quite well, taking full advantage of the Toshiba PX04 SAS3 SSDs we installed.
Вопрос в применимости данных решений, вот читаем в оригинале:
Of course, there's somewhat of a compromise; the feature set, interface and software integrations with popular packages like VMware leave a little to be desired as you look more upmarket at enterprise needs.
Ну и отсутствие компресси, дедупа и тд так же очень влияет, в том числе и на производительность. И да, при отсутствии дедупа/компресси придётся брать qsan раза в 3 большего объёма, чем его конкуренты Tier 1, и тут ещё вопрос — как оно в итоге по цене то выйдет.
И да, при отсутствии дедупа/компресси придётся брать qsan раза в 3 большего объёма, чем его конкуренты Tier 1, и тут ещё вопрос — как оно в итоге по цене то выйдет
Компрессия/дедуп будет скоро (~ 3-4 квартал) с обновлением прошивки. Что касается стоимости решения целиком, то по сравнению с конкурентами, где дедуп действительно эффективен и не приводит к катастрофическому падению производительности, Qsan оказывается в выигрыше.
Компрессия/дедуп будет скоро (~ 3-4 квартал) с обновлением прошивки.
Вот когда появится, когда будет видна эффективность и на сколько это будет влиять не производительность, тогда и обсудим. Написать софт — дело не простое, даже вон IBM в своём новом 9100 не справился софтовую компресси/дедуп сделать, воткнули асик, а уж про качество ПО азиатских компаний я промолчу.
Qsan оказывается в выигрыше
вы уж тогда спеки с ценами покажите, иначе это просто голословные заявления. Или с конкурентами по list-price сравниваете? :)
Насчет IBM вы не правы: дедупликация у IBM осуществляется «софтово» (если, конечно, считать софтовым вычисление sha на современных процессорах Intel). Компрессия в младшем midrange IBM (Storwize v5030) делается софтово. В старшем (Storwize v7000) — на «ускорителях» Intel QAT, в FlashSystem 9100 — либо на спроектированных IBM`ом NVMe накопителях аппаратно, либо снова аппаратно, но уже на встроенных в процессоры Intel QAT (для работы с обычныеми NVMe либо SAS дисками). Использование аппаратных ускорителей необходимо для обеспечения производительности при работе технологий data reduction, недостижимой конкурентными системами. Считаю, что IBM очень сильно угадали, сделав ставку на QAT в начале 2010х.
Так в чём именно я не прав? Что там не асик? Это не на столько принципиально каким конкретно аппартаным решением эти действия производить. Сторвайзы скоростью не выделяются, соответственно для FlashSystem 9100 была выбрана аппаратная реализация, т.к. IBM распихал процы уже везде где только можно это сделать и их ресурсы надо на что то тратить. Всё это сказывается опять-таки на стоимости.
Вы не правы в том, что, цитирую, «IBM в своём новом 9100 не справился софтовую компресси/дедуп сделать». Это как сказать, что Вальтер Рёрль не справился выиграть гонку пешком, поэтому сел на машину. Т.о. вы не правы два раза: 1. Дедупликация там таки софтовая 2. у IBM есть реализация софтовой компрессии, но конкрентно для названной вами системы была выбрана аппаратная реализация для того, чтобы быть быстрее конкурентных систем с софтовой реализацией.
Ну и по поводу того, что сторвайзы не выделяются скоростью — это ваши домыслы.
Ну и по поводу того, что сторвайзы не выделяются скоростью — это ваши домыслы.
это ваши домыслы
Ну как сказать — вон стоят и не блещут. какой сторвайз с софтовым дедупом и компрессией можно по производительности хотя бы со старшим фасом сравнить? Судя по нашим тестам — никакой.
1. Дедупликация там таки софтовая
Мы же уже выше обсудили, что в 9100 она аппаратная.
была выбрана аппаратная реализация
По тому что с текущей реализацией их софтовой компрессии/дедупа производительность крайне не высока в сравнении с конкурентами. О чём я и говорил в самом начале. Что на уроне ПО это нужно ещё грамотно уметь реализовать.
Мы же уже выше обсудили, что в 9100 она аппаратная.Перечитайте еще раз: дедупликация софтовая, компрессия — аппаратная.
вон стоят и не блещут. какой сторвайз с софтовым дедупом и компрессией можно по производительности хотя бы со старшим фасом сравнить?Вы создаете искуственные рамки. Сторвайза с соответствующим старшему FAS`у количеством ядер без аппаратной компрессии не существует. Соответственно, с младшим FAS`ом надо сравнивать младший сторвайз, со старшим — старший.
Сторвайза с соответствующим старшему FAS`у количеством ядер не существует.
со старшим — старший.
Так не существует с таким же кол-вом ядер или всё-таки надо со старшим сравнивать? Слишком сложная для меня фраза. Давайте так, сравнивали старший V7000 со средним FAS8200, сторвайз курил в сторонке.
Ещё был V5030 против 2650, но не помню сколько с него IOPS тогда сняли. Там было примерно одинаково, но 2650 — младший, а вот 5030 — нет.
Так не существует с таким же кол-вом ядер или всё-таки надо со старшим сравнивать? Слишком сложная для меня фраза.Поправил, не существует без плат аппаратной компрессии.
Ещё был V5030 против 2650, но не помню сколько с него IOPS тогда сняли. Там было примерно одинаково, но 2650 — младший, а вот 5030 — нет.Что и требовалось доказать: несмотря на маркетинговые разделения, FAS2650 является прямым конкурентом v5030: у них одинаковое количество ядер в контроллерах (6) и одинаковое количество кэш (32) и сопоставимая цена. Отсюда одинаковый результат. Аналога «младших» storwize (5010-5020) в линейке FAS не существует
сравнивали старший V7000 со средним FAS8200, сторвайз курил в сторонке.Тут надо уточнить, какие конфигурации сравнивали и какой был сторвайз: v7000 мог быть -124 (4 ядра на контроллер), -524 (8 ядер на контроллер), -624 (10 ядер на контроллер) при том, что сравниваете с 16и-ядерным FAS8200. Ну и по дискам-прошивкам нюансы конфигурации могли быть.
В общем приходите в storagediscussions, расскажете какой IBM крутой и классный
Спасибо, конечно, за приглашение. Про IBM предпочитаю рассказывать с пользой для дела. Могу вот статью запилить про 9100.вы уж тогда спеки с ценами покажите, иначе это просто голословные заявления. Или с конкурентами по list-price сравниваете? :)
Вы можете сравнить цены только либо через list price (что более или менее встречается в открытом доступе), либо придя к партнеру/дистрибьютеру с реальным проектом. По другому в IT мире никак.
Был опыт эксплуатации QSAN U600Q в конфигурации из трёх корзин, в сумме 60 дисков по 6Тб, итого примерно 300Тб хранилище под систему видеонаблюдения.
Изначально систему ставил и настраивал подрядчик, и собрал один LUN с расшаренной по samba папкой.
Полгода сервера видеонаблюдения писали в сетевую папку и все было хорошо, пока, внезапно, скорость записи не стала падать примерно до нуля. В такой момент даже переставал работать web-интерфейс. Техподдержка QSAN отвечала в духе вот вам новая прошивка.
На панелях хранилища горели предупреждения вида: хранилище заполнено на 90% сейчас будет performance degradation, который мы и получали. Софту системы видеонаблюдения на тот момент не удавалось в автоматическом режиме удалять старые записи. Наблюдая за всем этим безобразием возник вопрос. А здесь правда настроен RAID 0 из 60 дисков? На что подрядчик отвечал, нет там JBOD. Полистав документацию и интерфейс пришли к выводу, что JBOD-ом там называется способ подключения корзин, а собственно единственный LUN действительно лежит на нулевом рейде, да, из 60 дисков.
Все данные отправились в /dev/null и хранилище настроили на шесть LUN, которые отдавались по iSCSI. Все прекрасно заработало, за исключением того, что после перезагрузки сервера видеонаблюдения Windows не могла подключиться к iSCSI-диску. Покопавшись, выяснили, что винда после ребута пытается подключиться по адресам вида 169.254.x.x которые рапортует ей iSCSI-target со своих отключённых сетевых интерфейсов. Нашли в настройках хранилища лишние адреса для iSCSI, и выключили их. Только осталось непонятно, почему он их отдаёт, если там нет активного линка.
Чуть больше полгода все было тихо, пока снова хранилка не заполнилась на пресловутые 90% хотя в самой винде диски были заполнены на 85% После переписки с техподдержкой выяснилось: сам qsan использует внутри zfs, и чтобы все работало нормально, нужно чтобы всегда было свободно внутри более 10% и нужно было заранее разбивать LUN-ы с учетом этого резерва. А в доках про это нигде нет, видимо это рассказывают только на вендорских курсах. В нашей ситуации хранилище ничего не знает про свободные 15% на уровне вышележащей ФС, тк отдаёт целый LUN. Но можно в настройках хранилища включить zero deduplication, а в самой винде пройтись по диску sdelete.
На некоторых LUN удалось включить deduplication, а на других хранилище отвечало, у меня нет места, в итоге вставили дополнительный диск. Им оказался первый попавшийся десктопный 500gb.
Прогнали в винде диск через sdelete, и свободное место на хранилище стало совпадать с таким же внутри самих iscsi-дисков. Далее на вопрос, можно ли мигрировать данные с этого дополнительного диска на 500гб, начались расхождения. В web-интерфейсе есть некая кнопка free disk, теоретически сама zfs умеет освобождать диски, но техподдержка отвечала, что тогда данные с LUN-а пропадут.
Все это поработало ещё несколько месяцев, пока винда не начала находить ошибки на уровне ntfs.
Не помню, чем это уже все закончилось, но нашёлся следующий подрядчик, который со словами, вы все сделали неправильно, опять пересобрал хранилище отправив данные как всегда в null
Изначально систему ставил и настраивал подрядчик, и собрал один LUN с расшаренной по samba папкой.
Полгода сервера видеонаблюдения писали в сетевую папку и все было хорошо, пока, внезапно, скорость записи не стала падать примерно до нуля. В такой момент даже переставал работать web-интерфейс. Техподдержка QSAN отвечала в духе вот вам новая прошивка.
На панелях хранилища горели предупреждения вида: хранилище заполнено на 90% сейчас будет performance degradation, который мы и получали. Софту системы видеонаблюдения на тот момент не удавалось в автоматическом режиме удалять старые записи. Наблюдая за всем этим безобразием возник вопрос. А здесь правда настроен RAID 0 из 60 дисков? На что подрядчик отвечал, нет там JBOD. Полистав документацию и интерфейс пришли к выводу, что JBOD-ом там называется способ подключения корзин, а собственно единственный LUN действительно лежит на нулевом рейде, да, из 60 дисков.
Все данные отправились в /dev/null и хранилище настроили на шесть LUN, которые отдавались по iSCSI. Все прекрасно заработало, за исключением того, что после перезагрузки сервера видеонаблюдения Windows не могла подключиться к iSCSI-диску. Покопавшись, выяснили, что винда после ребута пытается подключиться по адресам вида 169.254.x.x которые рапортует ей iSCSI-target со своих отключённых сетевых интерфейсов. Нашли в настройках хранилища лишние адреса для iSCSI, и выключили их. Только осталось непонятно, почему он их отдаёт, если там нет активного линка.
Чуть больше полгода все было тихо, пока снова хранилка не заполнилась на пресловутые 90% хотя в самой винде диски были заполнены на 85% После переписки с техподдержкой выяснилось: сам qsan использует внутри zfs, и чтобы все работало нормально, нужно чтобы всегда было свободно внутри более 10% и нужно было заранее разбивать LUN-ы с учетом этого резерва. А в доках про это нигде нет, видимо это рассказывают только на вендорских курсах. В нашей ситуации хранилище ничего не знает про свободные 15% на уровне вышележащей ФС, тк отдаёт целый LUN. Но можно в настройках хранилища включить zero deduplication, а в самой винде пройтись по диску sdelete.
На некоторых LUN удалось включить deduplication, а на других хранилище отвечало, у меня нет места, в итоге вставили дополнительный диск. Им оказался первый попавшийся десктопный 500gb.
Прогнали в винде диск через sdelete, и свободное место на хранилище стало совпадать с таким же внутри самих iscsi-дисков. Далее на вопрос, можно ли мигрировать данные с этого дополнительного диска на 500гб, начались расхождения. В web-интерфейсе есть некая кнопка free disk, теоретически сама zfs умеет освобождать диски, но техподдержка отвечала, что тогда данные с LUN-а пропадут.
Все это поработало ещё несколько месяцев, пока винда не начала находить ошибки на уровне ntfs.
Не помню, чем это уже все закончилось, но нашёлся следующий подрядчик, который со словами, вы все сделали неправильно, опять пересобрал хранилище отправив данные как всегда в null
Для нормальной работы ZFS действительно требуется ~10% незанятого места на пуле. Увы, такова особенность работы этой файловой системы. Причем, удаленные данные внутри LUNов средствами файловой системы хостов на уровне ZFS не удаляются (=не высвобождаются), о чем вам, по вашим словам, и сообщила техподдержка (compression enabled, sdelete). Поэтому грамотным решением в вашем случае является резервирование 10% пространства на пуле как не размеченное. Надеемся, ваш нынешний подрядчик так и поступил.
Что же касается высвобождения диска из пула, то вы же сами указали, что использовали RAID0 без всякой защиты. Разумеется, извлечение диска из массива приведет к потере данных. Чудес, увы, не будет.
Что же касается высвобождения диска из пула, то вы же сами указали, что использовали RAID0 без всякой защиты. Разумеется, извлечение диска из массива приведет к потере данных. Чудес, увы, не будет.
И важное дополнение. В описываемых в статье системах ZFS не используется, поскольку это — блочные СХД. В то время как U600 — это NAS
RAID0 без всякой защиты. Разумеется, извлечение диска из массива приведет к потере данных
Предполагалось, если там zfs, то она может используемые блоки данных мигрировать на другие диски, и этот диск можно вытаскивать. Только не везде явно пишут об ограничениях:
However, this operation fails if no other valid replicas of the data exist. For example:
# zpool detach newpool c1t2d0
cannot detach c1t2d0: only applicable to mirror and replacing vdevs
Sign up to leave a comment.
СХД QSAN в качестве конкурента продукции брендам Tier 1