Если знаешь что на хабре есть люди с Ростова, то просто создавай аналогичный топик, вроде «Встречаемся в воскресенье в „Багдаде“ на Буденновском». Самая простая организация ;)
Мы ради интереса отснифали, как работает родной «Perfomance Tools»: он цепляется к массиву по телнету и с помощью комманд CLI снимает необходимую информацию :) Это можно назвать адекватным production-решением?
А когда в массивах p6300/p2000 появится возможность мониторить параметры загрузки, например IOPS, по SNMP? Мы, являясь далеко не последним заказчиком HP, обратились в саппорт с этим вопросом, где были посланы на 3 известных буквы. Фичреквест наш пошел туда же.
Корпоративные стандарты требуют мониторинга всех параметров дисковых накопителей, а у ваших массивов такого функционала нет. Я уже даже не знаю, стоит ли HP'шные storage закладывать в бюджет на 2013й год ;)
Спасибо за подробный рассказ.
Учитывая то, что у меня в продуктиве крутится подобная схема на mdadm (правда, без flashcache. К своему стыду, первый раз об этой технологии услышал) стало как-то не по себе. Хотя очень надеюсь что используемое у меня решение мультипачинга на основе multibus не даст полного отказа в обслуживании в случае залипания одного хранилища.
Надеюсь, если баг в реализации raid10 подтвердится, разработчикам улетит баг-репорт?
а почему не multibus + выбор по service-time? На тестах он у меня давал лучшую производительность.
Плюс, в теории, в подобной ситуации при мультибасе будет лишь деградация сервиса, а не полный отказ в обслуживании. Хотя, конечно, врядли кто-то это тестировал.
Интересно потом будет почитать описание причин и методов исправления.
Мы натыкались на похожие грабли после замены одного HDD внутри рейда mdadm в условиях сильной нагрузки на I/O
Смотря где сбой. Мы, к сожалению, подробностей не знаем.
Если накрылась сто раз переписанная управляющая ИС — то да.
А если сбой в системах хранения данных, в FC-сети, в ядре гипервизора либо каких-нибудь других атомарных компонентах то оперативная поддержка вендора может быть очень кстати.
Временем реакции. При коммерческом решении с купленной техподдержкой время реакции строго регламентировано, и в течении N часов вендор должен дать ответ (если, конечно, не сэкономили и не купили классическую «next business day»)
Корпоративные стандарты требуют мониторинга всех параметров дисковых накопителей, а у ваших массивов такого функционала нет. Я уже даже не знаю, стоит ли HP'шные storage закладывать в бюджет на 2013й год ;)
А 7го мая в ЦПКиО пьянко. Нельзя мне уже столько пить :(
Для простоты можно взять число в 500 серверов.
Решение легко внедряется на RHEL/CentOS 5/6
Учитывая то, что у меня в продуктиве крутится подобная схема на mdadm (правда, без flashcache. К своему стыду, первый раз об этой технологии услышал) стало как-то не по себе. Хотя очень надеюсь что используемое у меня решение мультипачинга на основе multibus не даст полного отказа в обслуживании в случае залипания одного хранилища.
Надеюсь, если баг в реализации raid10 подтвердится, разработчикам улетит баг-репорт?
Плюс, в теории, в подобной ситуации при мультибасе будет лишь деградация сервиса, а не полный отказ в обслуживании. Хотя, конечно, врядли кто-то это тестировал.
Мы натыкались на похожие грабли после замены одного HDD внутри рейда mdadm в условиях сильной нагрузки на I/O
Если накрылась сто раз переписанная управляющая ИС — то да.
А если сбой в системах хранения данных, в FC-сети, в ядре гипервизора либо каких-нибудь других атомарных компонентах то оперативная поддержка вендора может быть очень кстати.