Comments 44
На основе чего тиринг лицензируется, по числу терабайт? И почем лицензия?
Тиринг входит в Adaptive Optimization, лицензируется по дискам, позиция — HP 3PAR 7400 Adaptive Opt Drive LTU.
Какими средствами проводился анализ производительности на дисковую подсистему? Интересно было бы подробнее узнать
«Кстати очень порабовал RAID-5 по скорости работы (при этом он не тирится).» Пятый??? рэйд?
Эээ про скорость это наверное шутка такая? Да и надежность его при отказе одного диска, пока ребилд идет — нулевая.
Или это была ирония ?:)
Эээ про скорость это наверное шутка такая? Да и надежность его при отказе одного диска, пока ребилд идет — нулевая.
Или это была ирония ?:)
No pain — no gain! :) Без адреналину — жизнь не в радость!
На 3Par raid-5 считается на ASIC, и потому по скорости догоняет Raid1. Картинка из през HP-шных:
А на SAS 10K/15K ребилд быстро проходит, тем более что он проходит многие-ко-многим.
Это не 3х теребайтники в режиме многие-к-одному
А на SAS 10K/15K ребилд быстро проходит, тем более что он проходит многие-ко-многим.
Это не 3х теребайтники в режиме многие-к-одному
Да это все понятно, но все равно на больших объемах 5 Raid не самое лучший выбор.
Да и быстро, это все равно не 10 минут
Да и быстро, это все равно не 10 минут
Простите, а какой лучший выбор на больших объемах?
Если учесть что в реальной жизни на системах хранения размеры группы редко бывают 3 диска, а чаще всего дисков 20-30, то для таких задач оптимальный вариант — Raid-6.
Предпочтительно 50 и 60
Как мне нравятся такие советчики. Почему? Что за бред с 50-м рейдом. Ладно, допустим, вы являетесь фанатом NetAPP и будите доказывать с пеной у рта, что 5-й рейд небезопасен и его нельзя использовать в продуктиве. Не хочу влазить в холивар. Но 50-й то рейд в таком случае зачем? и нафига 60-й?
P.S. мне действительно интересно, кто это использует.
P.S. мне действительно интересно, кто это использует.
Интересно, что именно Вас в 50 и 60 не устраивает?
Если важна скорость и надежность. Или есть лучше варианты? Готов выслушать Ваше мнение?
Уж по защищенности он сильно выше чем 5 и ребилдится быстрее.
Если важна скорость и надежность. Или есть лучше варианты? Готов выслушать Ваше мнение?
Уж по защищенности он сильно выше чем 5 и ребилдится быстрее.
Вообще мне нравиться raid5 в его реализации на 3par. Диски бьются на гиговые чанклетсы, собираются в группы + данные мажуться по всей группе чанклетсов мелкими блоками. Таким образом ребилд так нелюбимой вам пятерки проходит в считаные минуты.
Мне не нравятся оговорки «если важна скорость и надежность». Вы когда-нибудь встречали кастомера, которого волновали бы только скорость и надежность? Если да — 10-ку ему в плечи и не нужно ни 5-ки ни 6-ки ни прочих извратов. Всегда есть вопрос, что же важнее. И пока все конторы в которых я проводил инсталяции выбирали небольшой прирост производительности в угоду не очевидному выигрышу в надежности.
Мне не нравятся оговорки «если важна скорость и надежность». Вы когда-нибудь встречали кастомера, которого волновали бы только скорость и надежность? Если да — 10-ку ему в плечи и не нужно ни 5-ки ни 6-ки ни прочих извратов. Всегда есть вопрос, что же важнее. И пока все конторы в которых я проводил инсталяции выбирали небольшой прирост производительности в угоду не очевидному выигрышу в надежности.
Если Вас пугает стоимость дискового пространства, то так и говорите.
И на счет 5 Raid, желаю Вам никогда не столкнуться с обвалом второго диска при ребилде массива так на терабайта 4. Доставшегося в наследство. А потом будете рассказывать про Raid 5 в продакшене :)
Отличный график, без малейшего намека на масштаб и и единицы измерения по осям )
По скорости оно «догоняет», как я вижу, в случае RAID-5 2+1, вы серьезно расчитываете такие группы использовать в жизни?
По скорости оно «догоняет», как я вижу, в случае RAID-5 2+1, вы серьезно расчитываете такие группы использовать в жизни?
А что пугает в 2+1? В случае 3Par, 2+1 это не дисковая группа, это разбиение на chunklets. И рейд с таким уровнем может быть собран на сотнях дисков в один клик.
То, что на два диска данных приходится один диск parity, то есть потеря на RAID-overhead — треть купленных дисков. Что, конечно, лучше, чем RAID-10, где этот оверхед — половина, но вряд ли порадует потенциальных желающих.
При этом, отмечу, потенциальная проблема RAID-5 c превращением на время реблида в RAID-0, с нулевой защитой от сбоев — остается. (как и 4 дисковых операции на одну операцию записи)
Пусть вероятнось снижается, но она остается. В энтерпрайзе за подход «авось пронесет» бьют канделябром. :)
PS. А что, официально HP где-то в Best Practices рекомендует использовать RAID-5? Покажете где?
При этом, отмечу, потенциальная проблема RAID-5 c превращением на время реблида в RAID-0, с нулевой защитой от сбоев — остается. (как и 4 дисковых операции на одну операцию записи)
Пусть вероятнось снижается, но она остается. В энтерпрайзе за подход «авось пронесет» бьют канделябром. :)
PS. А что, официально HP где-то в Best Practices рекомендует использовать RAID-5? Покажете где?
Ну так и рейд1 не гарантирует сохранности при выходе из строя двух дисков.
raid5 в данном случае это компромис соотношения утилизации/производительности/надежности
Best Practice — делать регулярные бекапы.
raid5 в данном случае это компромис соотношения утилизации/производительности/надежности
Best Practice — делать регулярные бекапы.
Ну, строго говоря, гарантирует, при отказе в разных половинах зеркала RAID-10 :)
Вообще-то RAID и бэкапы — это разные вещи, и предназначены для разного, поэтому заменой одно друому не является. Вот уж не ожидал, что придется такие элементарные вещи рассказывать сотруднику HP.
ЗЫ. То есть RAID-5 официально нигде в опубликованных руководствах HP не рекомендуется, я правильно вас понял?
Вообще-то RAID и бэкапы — это разные вещи, и предназначены для разного, поэтому заменой одно друому не является. Вот уж не ожидал, что придется такие элементарные вещи рассказывать сотруднику HP.
ЗЫ. То есть RAID-5 официально нигде в опубликованных руководствах HP не рекомендуется, я правильно вас понял?
Думаю не будете спорить, что при падении raid10, нет 100% гарантии сохранности данных.
Raid5 рекомендован в BestPractice. Первая попавшаяся ссылка.
Best practices for Oracle and HP 3PAR StoreServ Storage
Raid5 рекомендован в BestPractice. Первая попавшаяся ссылка.
Best practices for Oracle and HP 3PAR StoreServ Storage
На RAID-5 находятся архивные (не продакшн) базы, для отчетов по закрытым юрлицам или прошлым периодам. Но при этом периодичеки на них идет достаточно серьезная нагрузка.
Модель с 2 контроллерами и возможностью расширения при необходимости еще 2-мя.
Кстати, было бы интересно услышать начальника транспортного цеха, с разъяснением, каким образом и насколько просто можно провести вот это вот расширение с двух- на четырехконтроллерную 7400?
Если в кратце, то апгрейд проходит online.
Мне бы не вкратце, а подробно. Вот у меня есть стотыщпицот гигов данных на двухконтроллерной системе. Что я должен сделать, чтобы добавить еще два контроллера, чтобы производительность работы с этими гигами данных выросла вдвое?
В гипотетической ситуации, когда у вас скорость работы упирается в производительность двух контроллеров, а набор дисков при этом может дать еще столько же, добавление еще двух контроллеров повысит скорость в два раза.
Для этого необходимо будет половину дисков переподключить на новые device ports.
Если массив утилизирован на 100%, понадобится downtime: переключаем половину дисковых полок, массив сам их найдет и включит в работу.
Если массив утилизирован менее, чем на 50%, то без перерыва доступа к данным можно половину емкости вывести из группы, на горячую их переключить и ввести в группу.
Обычно апгрейды 2-node в 4-node сопряжены с апгрейдом емкости, и потому проходят Online.
Для этого необходимо будет половину дисков переподключить на новые device ports.
Если массив утилизирован на 100%, понадобится downtime: переключаем половину дисковых полок, массив сам их найдет и включит в работу.
Если массив утилизирован менее, чем на 50%, то без перерыва доступа к данным можно половину емкости вывести из группы, на горячую их переключить и ввести в группу.
Обычно апгрейды 2-node в 4-node сопряжены с апгрейдом емкости, и потому проходят Online.
Данные сами не рестрайпятся (что бы под этим не подразумевалось)?
Необходимо ли что-то дополнительно проделывать с данными, чтобы с ними начали работать два добавленных контроллера? Останется ли прежней структура доступа (допустим у мена все эти гиги разбросаны по двум сотням разных LUN, подключенным к двум сотням хостов), или нужно будет вручную перевешивать LUN-ы по новым контроллерам?
Необходимо ли что-то дополнительно проделывать с данными, чтобы с ними начали работать два добавленных контроллера? Останется ли прежней структура доступа (допустим у мена все эти гиги разбросаны по двум сотням разных LUN, подключенным к двум сотням хостов), или нужно будет вручную перевешивать LUN-ы по новым контроллерам?
Данные сами рестрайпятся — chunklets перераспределяются равномерно по всем дискам в CPG.
Чтобы новые контроллеры начали работать, нужно, чтобы данные оказались на дисках, подключеных к device ports этих контроллеров.
Т.е. или физически переключить эти диски, или в случае новых дисков — включить их в тот-же CPG и сделать рестрайп.
Все что твориться выше уровнем (Volume/LUN) апдейтится автоматом. У 3Par нет привязки LUN к контроллеру, все LUN равноправно доступны всем контроллерам. Если только принудительно это не ограничить.
Чтобы новые контроллеры начали работать, нужно, чтобы данные оказались на дисках, подключеных к device ports этих контроллеров.
Т.е. или физически переключить эти диски, или в случае новых дисков — включить их в тот-же CPG и сделать рестрайп.
Все что твориться выше уровнем (Volume/LUN) апдейтится автоматом. У 3Par нет привязки LUN к контроллеру, все LUN равноправно доступны всем контроллерам. Если только принудительно это не ограничить.
С tier'ингом у 3par всё довольно сложно. Минимальный срок реакции на изменение профиля нагрузки — пол-часа-час, при рекомендованном «раз в сутки».
Если профиль нагрузки хорошо предсказуемый, то 3par — душка и всеобщая любовь. Если нагрузка «гуляет», то можно запросто получить ситуацию «всё горячее на NL, а на FC оно будет завтра, когда горячим уже не будет».
В контексте 1С — какие-нибудь квартальные отчёты бухгалтерии, или генерального, решившего запустить «главный отчёт по всему и за всё время».
Если профиль нагрузки хорошо предсказуемый, то 3par — душка и всеобщая любовь. Если нагрузка «гуляет», то можно запросто получить ситуацию «всё горячее на NL, а на FC оно будет завтра, когда горячим уже не будет».
В контексте 1С — какие-нибудь квартальные отчёты бухгалтерии, или генерального, решившего запустить «главный отчёт по всему и за всё время».
На то он и tiering, а не кеш.
Мгновенная реакция может заставить массив только тем и заниматься, что гонять данные между дисками.
Tiering не панацея, а лишь инструмент. В случае с 3Par, иструмент более гибкий, т.к. позволяет тирить данные на одном и том-же наборе дисков, но между разными уровнями raid.
Мгновенная реакция может заставить массив только тем и заниматься, что гонять данные между дисками.
Tiering не панацея, а лишь инструмент. В случае с 3Par, иструмент более гибкий, т.к. позволяет тирить данные на одном и том-же наборе дисков, но между разными уровнями raid.
Меня скорее возмутило, что он не может это делать с записью.
Поскольку данные записываются, нет нужды читать их, то есть перекинуть горячий блок на более быстрый уровень можно было бы с нулевым оверхедом. Хотя у них там, по-моему то ли 4Мб, то ли 2Мб блок, так что проблемы, да.
По тому, что я видел, он выдаёт голую производительность шпинделей, то есть кеш там «ни о чём».
Поскольку данные записываются, нет нужды читать их, то есть перекинуть горячий блок на более быстрый уровень можно было бы с нулевым оверхедом. Хотя у них там, по-моему то ли 4Мб, то ли 2Мб блок, так что проблемы, да.
По тому, что я видел, он выдаёт голую производительность шпинделей, то есть кеш там «ни о чём».
У 3Par есть tier0, tier1, tier2. Запись идет на tier1 — primary tier.
С него уже согласно плотности IO пойдет перемещение.
Если у вас tier1 = ssd, tier2 = sas, то и запись будет идти всегда на ssd.
Предполагается, что нет смысла перемещать данные на более быстрый tier, до тех пор, пока не будет понятна его характеристика IO. может мы щас пишем полный дамп базы, который год никто трогать не будет. Его тоже на ssd писать? Лишняя работа по перемещению вниз.
С него уже согласно плотности IO пойдет перемещение.
Если у вас tier1 = ssd, tier2 = sas, то и запись будет идти всегда на ssd.
Предполагается, что нет смысла перемещать данные на более быстрый tier, до тех пор, пока не будет понятна его характеристика IO. может мы щас пишем полный дамп базы, который год никто трогать не будет. Его тоже на ssd писать? Лишняя работа по перемещению вниз.
Вседа? Даже если данные были выпихнуты в более низкие tier с помощью AO?
Новые данные всегда пишутся на оригинальный volume — тот, к которому была применена политика Adaptive Optimization. Cогласно best practice это должен быть tier 1. Но никто не запрещает оригинальным сделать ssd.
Перезапись(изменение) будет идти туда, где данные были размещены механизмом AO.
Перезапись(изменение) будет идти туда, где данные были размещены механизмом AO.
Тыг я про это и говорю. Начали обновляться данные в NL — терпи лаги, пока AO не наберётся силы духа кого-то куда-то перекинуть. Хотя казалось бы, раз уж пишут, почему бы не напрячься и не перенести?
То есть условно говоря, worst case scenario c трипаром выглядит как «ну посмотрите сколько шпиндели на NL выдадут — столько худшая оценка производительности».
Насчёт «ну, в жизни так не бывает», могу сказать, что бывает и ещё как, особенно, когда не одно приложение, а более-менее динамическая конфигурация.
Аналогично с чтением. Если уже прочитали — ну запишите на FC/SSD, кто мешает-то?
То есть условно говоря, worst case scenario c трипаром выглядит как «ну посмотрите сколько шпиндели на NL выдадут — столько худшая оценка производительности».
Насчёт «ну, в жизни так не бывает», могу сказать, что бывает и ещё как, особенно, когда не одно приложение, а более-менее динамическая конфигурация.
Аналогично с чтением. Если уже прочитали — ну запишите на FC/SSD, кто мешает-то?
Подскажите, а чем и как Вы меряли производительность СХД? Спасибо!
Производительность мерил iometer, но данные как написал в шапке не привожу, дабы не начинать полемику о результатах, параметрах измерения, «истинности» их и т.д. Сейчас настроили железяку «по фэншую», в принципе на выходных можно повторно снять результаты. Напишу в личку.
Комментарии по вопросам в конце топика:
1. А инженеры должны были установить MPIO? У вас должен быть подписанный SIR (System Installation Report), в нём указан менеджер проекта. Задайте ему (ей) вопрос, входит ли настройка MPIO на хостах в купленные работы по внедрению массива. Если да, то должны были сделать, если нет — нет.
2. Расписания курсов учебного центра HP лежит на сайте. hp.ru/education
3. Обычно по гарантийному письму можно получить услугу с отсрочкой платежа. По крайней мере, в «основном» HP это работает. Учебный центр может, правда, иметь другие правила — всё-таки у них свой бюджет и кост-центр.
Кстати, для миграции с EVA/P6000 на 3PAR есть сервис, который сильно облегчает процесс (требует «минимальный даунтайм»).
1. А инженеры должны были установить MPIO? У вас должен быть подписанный SIR (System Installation Report), в нём указан менеджер проекта. Задайте ему (ей) вопрос, входит ли настройка MPIO на хостах в купленные работы по внедрению массива. Если да, то должны были сделать, если нет — нет.
2. Расписания курсов учебного центра HP лежит на сайте. hp.ru/education
3. Обычно по гарантийному письму можно получить услугу с отсрочкой платежа. По крайней мере, в «основном» HP это работает. Учебный центр может, правда, иметь другие правила — всё-таки у них свой бюджет и кост-центр.
Кстати, для миграции с EVA/P6000 на 3PAR есть сервис, который сильно облегчает процесс (требует «минимальный даунтайм»).
1. По MPIO разобрались, обоюдная вина. Мы не могли устроить даунтайм серверу днем, HP не дало рекомендаций что нужно сделать. В контракт входил сервис инсталляции — HA114A1 UW HP Installation and Startup Service и UW HP Technical Installation Startup SVC.
2. Да, мы их там нашли. Просто не знали что вообще есть расширенный курс. А поиск информации на сайте HP — вообще процесс нетривиальный. Хуже — ИМХО только Intel.
3. Ну, у нас не получилось договориться. Чему я был немало удивлен.
2. Да, мы их там нашли. Просто не знали что вообще есть расширенный курс. А поиск информации на сайте HP — вообще процесс нетривиальный. Хуже — ИМХО только Intel.
3. Ну, у нас не получилось договориться. Чему я был немало удивлен.
Sign up to leave a comment.
Переход с HP EVA на 3PAR StoreServ 7400. Реальный опыт внедрения