Comments 17
Есть и некоторые особенности. Если писать на хранилище много информации в течение долгого времени, производительность падает.
Мне кажется логичнее предположить, что дело все же в процессе «garbage collection» и эффекте «Write Cliff» для SSD, чем в каком-то искусственном ограничении записи.
Про это ваши коллеги-конкуренты вот в этой статье более-менее подробно писали.
Если проблема в GC, то массив должен терять производительность при случайной записи маленькими блоками быстрее, чем при последовательной записи большими блоками в один поток. В СХД, которую я тестировал, по моим ощущениям это не так. Производительность падает после определенного объема записанной информации, вне зависимости от типа записи. Для того, чтобы наверняка ответить на этот вопрос, нужен доступ к документации, которую не показывают партнерам.
Искусственное ограничение может иметь смысл, так как flash, который использует вендор, поддерживает малое количество перезаписи.
Искусственное ограничение может иметь смысл, так как flash, который использует вендор, поддерживает малое количество перезаписи.
Искусственное ограничение такого рода не имеет смысла. Если заказчик хочет записывать большое количество данных на массив, то ему ни что не помешает. Медленно или быстро, но данные будут записаны.
Найдете и почитаете описание эффекта Write Cliff для SSD решений, в том числе на англоязычных ресурсах. Основные симптомы как раз совпадают с описанными вами. Если на SSD или на all flash array идет большой поток записи и в итоге данными заполняется большой % дискового пространства, то GC (особенно когда в штатном режиме он запускается по расписанию) просто не успевает отчищать нужное количество блоков от «устаревших» данных. В результате GC продолжает работать в фоне, а вот операции записи сильно проседают. Писать то некуда, помеченные к перезаписи блоки есть, но они еще не очищены от старых данных. Это и называют эффектом Write Cliff.
Найдете и почитаете описание эффекта Write Cliff для SSD решений, в том числе на англоязычных ресурсах. Основные симптомы как раз совпадают с описанными вами. Если на SSD или на all flash array идет большой поток записи и в итоге данными заполняется большой % дискового пространства, то GC (особенно когда в штатном режиме он запускается по расписанию) просто не успевает отчищать нужное количество блоков от «устаревших» данных. В результате GC продолжает работать в фоне, а вот операции записи сильно проседают. Писать то некуда, помеченные к перезаписи блоки есть, но они еще не очищены от старых данных. Это и называют эффектом Write Cliff.
Именно такой массив мы искали пару лет назад, у HP ничего похожего на тот момент не было и сейл нам упорно рассказывал, что оно нам не нужно. В итоге купили Хуавей, так как IBM было слишком дорого…
Прошу прощения за оффтопик, но не сдержался :).
А отвертка на «главной» фото — это случайно не Westward? Уж больно похожа.
Если так, то не комильфо это — крутить такой отверткой HP 3Par :). Такие отвертки EMC2 поставляет в комплекте с DataDomain.
А отвертка на «главной» фото — это случайно не Westward? Уж больно похожа.
Если так, то не комильфо это — крутить такой отверткой HP 3Par :). Такие отвертки EMC2 поставляет в комплекте с DataDomain.
Не совсем понятно, где производились замеры: на бакенде или на хосте?
«время отклика меньше секунды». Наверное, вы хотели сказать «милисекунды»? Потому что если это официальное «а у нас SSD на 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. реклама не удалась, КРОКу не зачет.
«Луны располагаются только на одной 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.
Если нет, то почему? Ведь это всё фичи контроллера, а тип дисков особой роли играть не должен — в крайнем случае может понадобиться кэш из нескольких SSD.
Sign up to leave a comment.
Выгодная замена тиринговым массивам: обзор и тесты полностью флешевой железки HP 3PAR 7400