Comments 9
Такой подход нас очень выручил в еще одном интересном кейсе: в один момент на такой же четырехконтроллерной системе Dorado 5000 V6 одновременно сломались системные диски в обоих контроллерах.
А вот в таком кластерном сетапе и при такой аварии вторая контроллерная голова каким образом получает доступ к дискам в первой голове и подключенным к ней полкам ?
А с какими проблемами, связанными с отказом компонентов в СХД, сталкивались вы?
Как то помер мидплейн в одном из IBM V7000G2 ("никогда такого не было и вот опять" (c) инженер IBM)
Но когда кейсов уже стало несколько десятков, пришлось искать другое решение.
Как хорошо, что не позарились в свое время на дорады и остались на сторвайзах. Шестое чувство недаром подсказывало, что "не надо оно вам" ;)
А вот в таком кластерном сетапе и при такой аварии вторая контроллерная голова каким образом получает доступ к дискам в первой голове и подключенным к ней полкам ?
В случае выхода из строя системных дисков, контроллер переходит в статус Faulty, но не перестает работать и обслуживать сервисы. Связность обеспечивается межполочными RDMA кабелями.
А вот в таком кластерном сетапе и при такой аварии вторая контроллерная голова каким образом получает доступ к дискам в первой голове и подключенным к ней полкам ?
В кластере, собранном из двух СХД (scale-out), полный отказ одного контроллерного шасси логичным образом приводит к недоступности всех его дисков для "живой" полки. Только это происходит не в момент отказа системного диска, а когда контроллеры полки полностью недоступны. Такой сценарий - достаточно маловероятен даже при таком серьёзном сбое как авария системного диска.
Проблема была напрямую связана с версией микрокода 6.1.0, в которой на системные диски производилась чрезмерная запись. Это было устранено в одном из поздних хот-патчей (SPH30, но могу ошибаться). Мы ни разу не сталкивались с этой бедой ни на 6.0.1, ни на 6.1.2. Но если 6.1.0 эксплуатировалась достаточное время, то это практически был приговор. Количество хост-записей и износ по системе критериев смарткита для таких дисков были неутешительными.
Авария по диску, или сразу отказ контроллера (в виде полной потери управления и мониторинга) почти всегда происходил на master стороне. При этом, в течение достаточно длительного времени, СХД сохраняла полноценную работоспособность, без влияния не сервис, с сохранением всех путей. Встроенные средства EulerOS в ряде случаев даже перемонтировали отказавший диск, если его повреждения это позволяли и тогда возвращалось управление контроллером.
Таким образом, не смотря на критичность ситуации как таковой, СХД все равно оставалась рабочей, давая как минимум резерв времени на миграцию данных. При полном отказе контроллера с неисправным диском, мы заблаговременно отключали переход системы во write-protect.
История, безусловно, неприятная, но к счастью решаемая и не воспроизводимая на новых версиях микрокода
В кластере, собранном из двух СХД (scale-out), полный отказ одного контроллерного шасси логичным образом приводит к недоступности всех его дисков для "живой" полки. Только это происходит не в момент отказа системного диска, а когда контроллеры полки полностью недоступны. Такой сценарий - достаточно маловероятен даже при таком серьёзном сбое как авария системного диска.
Понятно. Спасибо. Т.е. получается эти кластерные конфигурации на двухконтроллерных головах это не про доступность при умирании одной головы, а про производительность. А у нетаппов также ?
получается эти кластерные конфигурации на двухконтроллерных головах это не про доступность при умирании одной головы, а про производительность
Верно, если общий пул собран на собственных дисках обеих полок. Впрочем, других вариантов использования такой конфигурации на мидрейнджах я и не видел.
А еще, я не видел расчётов из eDesigner, из которых для кластера из двух полок Dorado 5000, например, однозначно был бы виден некий реальный сценарий с заметным приростом производительности. Речь про реальный сервисный сценарий, а не абстрактный маркетинговый подход "берите-берите, ведь 4 контроллера лучше чем 2!".
Оценка состояния системных дисков, которую проводят смарткит и контроллер СХД, жёстко завязана на модель дисков. Иначе говоря, сторонние диски заводятся и работают, но контроль их состония смарткитом при хелс-чеке не ведётся, а контроллер (через disk_repair.sh) может даже не вывести информацию по статусу диска (и SMART соответственно). То есть, формально работоспособность контроллера восстанавливается, но вы теряете возможность контролировать статус диска собственными средствами контроллера. Кроме того, оценка System Disk Risk со стороны смарткита так же не будет проводиться.
Всё верно, в скрипты смарткита зашиты модели и смарт-параметры системных дисков, которые использует Huawei, но как уже написали ранее - достать их не представляется возможным, как и несколько дестяков контроллеров. Поэтому приходится внедрять периодический опрос контроллеров, через ранее упомянутый вами disk_repair и отслеживать параметры, указывающие на степень износа. Также, в ос контроллера остается встроенная проверка на скорость отклика диска, которая не привязана к модели.
Скажем так, задача их поиска сложная, но решаемая. Мы успешно заменили диски на оригинальные (иногда с небольшим пробегом) как в 5000 дорадах (форм-фактор 2280), так и в 3000 (2242). Вот эти последние - MD619HXCHDE3TC - искали прям долго, но в итоге удалось найти. Объем замены - тоже несколько десятков.
Что касается disk_repair, то (по крайней мере на двух СХД на версии 6.1.0) скрипт ничего не возвращал для "неродных" дисков. То есть, мониторить их нельзя было даже вручную. Возможно, что в более поздних версиях он стал менее разборчив.
Добрый день.
план подготовки системных дисков таким образом, чтобы на них уже присутствовало все необходимое ПО для работы (релиз SPC + хотпатч SPH)
Подскажите пожалуйста, в чем заключается этот план? Каким образом вы предзагружали ПО на диски?
Проактивное обслуживание для OceanStor Dorado: решаем проблему старения системных SSD