Комментарии 14
Вопрос: Этот массив работает только с SSD?
Если да, то SSD по-прежнему управляются SCSI протоколом?
Ну а как — для полностью флеш-массива 400к IOPS — как-то не серьезно…
Если да, то SSD по-прежнему управляются SCSI протоколом?
Ну а как — для полностью флеш-массива 400к IOPS — как-то не серьезно…
Если да, то SSD по-прежнему управляются SCSI протоколом?
По сетевым протоколам (FC, iSCSI, FCoE итд) всё равно ходит SCSI, так что какая разница?
Ну а как — для полностью флеш-массива 400к IOPS — как-то не серьезно…
Тут скорее упирается уже в Latency SAN протоколов. Если бы тестировали на FC 16G (там latency пониже немного) или вообще Infiniband, то там было бы получше.
Эээ… Немного не согласен по обеим пунктам.
1. Не обязательно кидать SCSI. Зачем? Если так делать — идет многократное преобразование (упаковка в SCSI и распоковка обратно). Я понимаю, что это делается быстро, но… делается же.
Пример другой ситуации — тот же Violin, где все флешки висят на PCI-E, или те-же FMD от Хитачи.
2. Латенси тут в принципе не плохое, я по IOPS-ы говорю. Собсно на том-же HUS-VM можно добиться до 3КК IOPS на дисках FMD. Похожие результаты и у НетАп, и у ЕМС.
В общем: на мой взгляд — незачет.
1. Не обязательно кидать SCSI. Зачем? Если так делать — идет многократное преобразование (упаковка в SCSI и распоковка обратно). Я понимаю, что это делается быстро, но… делается же.
Пример другой ситуации — тот же Violin, где все флешки висят на PCI-E, или те-же FMD от Хитачи.
2. Латенси тут в принципе не плохое, я по IOPS-ы говорю. Собсно на том-же HUS-VM можно добиться до 3КК IOPS на дисках FMD. Похожие результаты и у НетАп, и у ЕМС.
В общем: на мой взгляд — незачет.
1. Что значит — не обязательно? А какой же протокол используется внутри Fibre Channel? Всё тот же SCSI. Так что без него никак.
2. Латенси и иопсы это связанные параметры, по-моему это очевидно. Один вытекает из другого и наоборот.
2. Латенси и иопсы это связанные параметры, по-моему это очевидно. Один вытекает из другого и наоборот.
Погодите…
1. В FC конечно же ходит SCSI, с этим ни кто не спорит. Зачем SCSI кидать с дисков? Вы же не диски напрямую к серверу цепляете? Там же есть еще RAID, какая-то логика, кэш. При каждой операции специальные процессоры (в лучшем случае), или ЦП делают разворачивание/заворачивание в SCSI. Вот эти операции для флешового массива на мой взгляд являются точно лишними. Это пережиток обычных дисков, которые сами работают по SCSI. Для флешов достаточно просто посадить на PCI-E, что уже сделано на указанных мной массивах от Violin или EMC
2. Связаны то они конечно связаны… Но… У HUS-VM от Хитачи с обычными дисками латенси как Вы понимаете — дай Боже… тоже по 20 мс… Но IOPS может выдать под пол миллиона… Как Вы наверное понимаете, операции бывают и последовательные. И блоками. За одну операцию можно выдать не один пакет.
Хотя тут конечно, что считать IOPS. Это тоже у разных вендоров понятие разное. Кто-то мерит чтение с диска, кто-то пакет, а кто-то — одну запрос/возврат.
1. В FC конечно же ходит SCSI, с этим ни кто не спорит. Зачем SCSI кидать с дисков? Вы же не диски напрямую к серверу цепляете? Там же есть еще RAID, какая-то логика, кэш. При каждой операции специальные процессоры (в лучшем случае), или ЦП делают разворачивание/заворачивание в SCSI. Вот эти операции для флешового массива на мой взгляд являются точно лишними. Это пережиток обычных дисков, которые сами работают по SCSI. Для флешов достаточно просто посадить на PCI-E, что уже сделано на указанных мной массивах от Violin или EMC
2. Связаны то они конечно связаны… Но… У HUS-VM от Хитачи с обычными дисками латенси как Вы понимаете — дай Боже… тоже по 20 мс… Но IOPS может выдать под пол миллиона… Как Вы наверное понимаете, операции бывают и последовательные. И блоками. За одну операцию можно выдать не один пакет.
Хотя тут конечно, что считать IOPS. Это тоже у разных вендоров понятие разное. Кто-то мерит чтение с диска, кто-то пакет, а кто-то — одну запрос/возврат.
1. Как оно будет внутри — это, я согласен, дело уже производителя. Чем проще — тем лучше. Но снаружи всё раво скази :)
2. Чудес не бывает. Один SAS 15k диск выдает под 200 случайных IOPS и чтобы получить 500к на таких дисках — нужно их 2500 штук.
Я, конечно, очень уважаю Хитачи, но не думаю что они кудесники.
IOPS это вполне понятная величина — количество случайных операций записи или чтения блоком определённого размера в секунду. Мерять последовательные IOPS смысла никакого нет, в этом случае меряется пропускная способность (throughput).
Что такое «пакет» я не очень понял.
2. Чудес не бывает. Один SAS 15k диск выдает под 200 случайных IOPS и чтобы получить 500к на таких дисках — нужно их 2500 штук.
Я, конечно, очень уважаю Хитачи, но не думаю что они кудесники.
IOPS это вполне понятная величина — количество случайных операций записи или чтения блоком определённого размера в секунду. Мерять последовательные IOPS смысла никакого нет, в этом случае меряется пропускная способность (throughput).
Что такое «пакет» я не очень понял.
Я понимаю, куда вы клоните. Будущее — за NVMe, где действительно удалось сбросить SCSI с парохода современности. Вот только полноценных реализаций SAN на базе NVMe пока что не предвидится. Были какие-то концепты с парой инициаторов и стандартизацией внешних интерфейсов год назад. Как оно сейчас живет, не помню.
Вопрос: Этот массив работает только с SSD?
Если да, то SSD по-прежнему управляются SCSI протоколом?
вероятно, впечатление об использовании SSD и SAS шины на бэкенде устройства у Вас вызвала только внешняя схожесть модулей с стандартными SFF дисками и салазками. На самом деле это не так: в ядре СХД две неблокируемые отказоустойчивые шины собственной разработки (без PCIe соединений и SAS контроллеров) обеспечивающие, по заявлению производителя, бОльшую внутреннюю пропускную способность. Флеш-модули так же свои, не SSD. Архитектура сильно отличается от традиционных СХД.
Ну а как — для полностью флеш-массива 400к IOPS — как-то не серьезно…
по сравнению с маркетинговыми цифрами — да. На практике 400к — очень круто. Надо учитывать, что это средний показатель за время теста (3 минуты), что СХД в не самой полной конфигурации (8 модулей из 12 возможных), что флеши были заполнены данными. Во время тестирования мы наблюдали скачки за 550к iops, но кому они интересны? Целью тестирования было не извлечение максимальных цифр, а составление картины производительности в реальных условиях, которую можно применять при решении конкретных задач.
А почему такая большая latency? 20мс — это ж обычные (не сильно быстрые) шпиндели. На SSD такие задержки — обычно признак «перебора» по глубине очереди. Хотя в контексте СХД — шут его знает, но я реально не хотел бы видеть современные системы в таких условиях. Я уже начал наблюдать тренд среди программистов «забивать» на вопросы производительности произвольного доступа («devstack syndrome» — если на ноутбуке программиста (где SSD) это работает быстро, значит всюду так же должно работать"). После 100µs на локальном диске, 20000µs на продакшен-системе…
Да, 20 мс — это много. Но там же есть еще меньшие латенси < 1 мс. Хотя это похоже на искусственные тесты, где все попадает в кеш.
Надеюсь хоть при испытании выключили кэш на файловой системе сервера? А то кто его знает… :)
Надеюсь хоть при испытании выключили кэш на файловой системе сервера? А то кто его знает… :)
Даже на десктопных SSD можно увидеть минимальные (т.е. на синтетических тестах с QD=1) значения задержки близкие к 60µs (попадает в RAM-кэш) SSD, на чтение 200-300µs вполне достижимы. Тут, конечно, добавляется прослойка в виде FC.
Не помешало бы определить, на что способна система в плане минимальных задержек, и сколько мы можем увидеть IOPS'ов при приемлемом значении задержки.
Не помешало бы определить, на что способна система в плане минимальных задержек, и сколько мы можем увидеть IOPS'ов при приемлемом значении задержки.
А маленький частный самолётик стоит дешевле или дороже сего чуда?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестирование флеш СХД. IBM FlashSystem 840