Открыть список
Как стать автором
Обновить

Комментарии 17

Есть и некоторые особенности. Если писать на хранилище много информации в течение долгого времени, производительность падает.

Мне кажется логичнее предположить, что дело все же в процессе «garbage collection» и эффекте «Write Cliff» для SSD, чем в каком-то искусственном ограничении записи.

Про это ваши коллеги-конкуренты вот в этой статье более-менее подробно писали.
Если проблема в GC, то массив должен терять производительность при случайной записи маленькими блоками быстрее, чем при последовательной записи большими блоками в один поток. В СХД, которую я тестировал, по моим ощущениям это не так. Производительность падает после определенного объема записанной информации, вне зависимости от типа записи. Для того, чтобы наверняка ответить на этот вопрос, нужен доступ к документации, которую не показывают партнерам.
Искусственное ограничение может иметь смысл, так как flash, который использует вендор, поддерживает малое количество перезаписи.

Искусственное ограничение такого рода не имеет смысла. Если заказчик хочет записывать большое количество данных на массив, то ему ни что не помешает. Медленно или быстро, но данные будут записаны.

Найдете и почитаете описание эффекта Write Cliff для SSD решений, в том числе на англоязычных ресурсах. Основные симптомы как раз совпадают с описанными вами. Если на SSD или на all flash array идет большой поток записи и в итоге данными заполняется большой % дискового пространства, то GC (особенно когда в штатном режиме он запускается по расписанию) просто не успевает отчищать нужное количество блоков от «устаревших» данных. В результате GC продолжает работать в фоне, а вот операции записи сильно проседают. Писать то некуда, помеченные к перезаписи блоки есть, но они еще не очищены от старых данных. Это и называют эффектом Write Cliff.
Именно такой массив мы искали пару лет назад, у HP ничего похожего на тот момент не было и сейл нам упорно рассказывал, что оно нам не нужно. В итоге купили Хуавей, так как IBM было слишком дорого…
Тут согласен. В целом решение ну очень интересно выглядит. :)
И как он хуавей?
Поддержка временами не вполне адекватная, главным образом в том, что касается софта. Сама железка работает без проблем, за год износ флэша около 1%, замен компонентов не было, проседаний по скорости тоже. В целом, мы довольны.
Прошу прощения за оффтопик, но не сдержался :).
А отвертка на «главной» фото — это случайно не Westward? Уж больно похожа.
Если так, то не комильфо это — крутить такой отверткой HP 3Par :). Такие отвертки EMC2 поставляет в комплекте с DataDomain.
Это хорошая отвертка. Я пользуюсь ей уже пару лет, и она нормально работает с любыми массивами. К счастью, HP не предъявляет требований к модели отвертки.
Согласен, что хорошая :).
Не совсем понятно, где производились замеры: на бакенде или на хосте?
Судя по скринам — данные с сервера, на котором запускался тест.
«время отклика меньше секунды». Наверное, вы хотели сказать «милисекунды»? Потому что если это официальное «а у нас SSD на IO запрос отвечают быстрее секунды», то…
Да, конечно, миллисекунда; fixed.
И в случае с
300 000 IO с временем отклика меньше секунды
тоже опечатка?
«На борту бесплатная (у других вендоров эта опция часто идёт за дополнительные деньги) дедупликация» — NetApp уже лет 10 дает это for free :)
«Луны располагаются только на одной RAID-группе» — Так уже даже EMC не делает.
«В результате команда из 4 контроллеров в HP 3PAR работает значительно лучше, чем 4 малосвязанных контроллера в большинстве mid-range СХД.» — если использовать 4 контроллера, то будет 8 путей, что может вызвать проблему когерентности кэша. Нужно почитать, что на эту тему пишет сам вендор в connectivity guide (например EMC не рекомендует такой конфиг для VPLEX).
«Response time 0.1 ms» — это для SSD очень мало, даже для «True Flash» это очень мало, даже с половиной выключенных ячеек памяти на «True Flash» можно добиться около 0.25ms, а 0.1ms — это какой-то кэш.

P.S. и пора уже перестать воспринимать массив через призму IOPS'ов т.к. в большой инфраструктуре массив так же должен хорошо интегрироваться с этой инфраструктурой, т.к. IOPS'ы должны быть управляемыми.

P.P.S. реклама не удалась, КРОКу не зачет.

Аналог DDP и дедупликация поддерживаются на обычных нефлешевых/тиринговых версиях 3Par?

Если нет, то почему? Ведь это всё фичи контроллера, а тип дисков особой роли играть не должен — в крайнем случае может понадобиться кэш из нескольких SSD.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.