Горячая замена жестких дисков raid
Горячая замена диска Adaptec 6405 официально поддерживается RAID-контроллером и осуществляется достаточно просто. При этом вам все же лучше будет полностью протестировать этот процесс пока сервер ещё не введен в работу, а также задокументировать эти шаги . Если какой-либо диск (или несколько дисков) все же выйдут из строя на массиве с полезной нагрузкой, вам будет не до выяснения нюансов работы контроллера, нужно будет выполнять замену диска и лучше, чтобы вы были полностью уверены в этом процессе. Для тех, кто поленился сделать для себя подробный гайд step by step главным образом и предназначается эта статья (ну а также разумеется для меня самого и моих коллег).
Подробнее о контроллерах Adaptec серии 6xxx читайте в головной статье — RAID-контроллер Adaptec 6405.
Если вам интересны raid-технологии и задачи администрирования raid-контроллеров, рекомендую обратиться к рубрике RAID на моем блоге.
Горячая замена диска Adaptec 6405
Для начала нужно определить в какой корзине находится диск, который нам нужно заменить. Есть несколько способов это сделать:
1) При должной настройке диск скорее всего сидит в корзине с тем порядковым номером, в какой и должен (судя по информации из ASM. Учтите, что номера корзин начинаются с 0);
2) На всякий случай можно подстраховаться и точно определить корзину. Для этого в утилите Adaptec Storage Manager нажимаем правой кнопкой на нужном диске — Blink physical disk.
На этом моменте корзина диска должна ритмично замигать красным светодиодом.
3) Ничего не делать и просто через ASM перевести диск в состояние Failed. В этом случае контроллер начнет издавать мерзкий писк и будет непрерывно светиться красный светодиод на корзине с проблемным диском.
Отлично, допустим диск определен (или вы пропустили этот шаг), двигаемся дальше. Теперь нужно подготовить диск к изъятию. Можно конечно его просто выдернуть, но не думаю, что это хорошее решение, тем более когда все можно сделать правильно. К тому же так рекомендуют сделать и в официальной документации 1 .
When removing a drive to simulate a failure or pro-actively replace a questionable drive, it is recommended to use the Storage Manager «set drive state to failed» or CLI / ARCCONF «force fail» option prior to removing the drive. When the drive is marked as failed, it is safe to remove and replace the drive.
Нажимаем правой кнопкой на нужном диске — Set drive state to failed:
Сразу выскочит предупреждение, что массив будет переведен в деградированное состояние:
Подтверждаем. В реальной среде вышедший из строя диск скорее всего и так будет в состоянии Failed, а массив в деградированном виде. У меня же эксперимент на тестовой среде и я перевожу диск в нужное состояние вручную. Вот как изменятся показания ПО:
Напоминаю, что массив при этом у меня формально остался в рабочем состоянии, ведь я использую RAID1 и он обеспечивает работоспособность при выходе из строя до половины дисков.
На этом этапе можно смело идти и заменять диск на новый (объем диска вплоть до байта должен быть больше или равен объему других дисков в действующем массиве). Контроллер при этом будет издавать писк (как я и говорил выше), а корзина с проблемным диском сигнализировать о проблеме непрерывно горящим красным светодиодом .
После замены показания ASM будут выглядеть следующим образом:
Новый диск готов к использованию и нужно его инициализировать. Нажимаем правой кнопкой на диске — Initialize:
Получаем предупреждение и соглашаемся с ним:
Далее нужно дать понять контроллеру, что он может использовать новый диск вместо недавно «вышедшего из строя» и замененного диска. Для этого нужно сделать новый диск диском горячей замены (правой кнопкой на новом диске — Create dedicated hot-spare drive for):
Никаких дополнительных диалоговых окон выскочить не должно, а диск сразу станет частью массива:
и автоматически запустится процесс ребилда:
Во время процесса работа сервера может не прекращаться (для наглядности скриншоты ASM я снимал как раз с того же сервера, на котором проводил тестирование). Только учтите один момент: ребилд — достаточно ресурсоемкий процесс и если в вашем массиве небольшое количество низкопроизводительных дисков (а сейчас это фактически любые диски, кроме SSD), то лучше провести технические обслуживание, предварительно сняв полезную нагрузку с сервера. Это особенно касается массивов RAID5 (и им подобных), которые в продакшене вообще использовать не рекомендуется (почему, читайте подробнее в моей статье — Типы RAID-массивов).
Решил написать эту статью после знакомства с публикацией «HP, Dell и IBM: компоненты, отвечающие за надёжность сервера», поскольку имею другое мнение насчёт некоторых моментов. Эта статья не претендует на инновационные подходы, а просто описывает полученный опыт и, надеюсь, предотвратит банальные ошибки.
Итак, начнём с того, что попробуем выяснить, зачем бесперебойность и беспрерывность серверам? Собственно, серверам бесперебойность не обязательна, но она нужна сервисам, которые предоставляют эти сервера. Наилучшая беспрерывность обеспечивается только распределёнными системами, которые могут функционировать независимо друг от друга с автоматическим переключением между ними (для скорости) и разнесённые географически (катастрофоустойчивость). Но это выдвигает особые (не всегда реализуемые) требования к программному обеспечению. Недостатками таких решений являются повышеная стоимость, проблемы с репликацией данных, передача состояния для бесшовного переключения на резервную систему. Дополнительными плюсами является то, что при правильной реализации системы, возможно повышение быстродействия — клиенты делятся между двумя или более локациями, а при сбое перераспределяются.
Но есть задачи, настолько критичные и специфические, что требуют особой бесперебойности серверов, для них делают особые сервера, например менфреймы, с возможностью горячей замены всех компонентов, включая процессоры, память и даже материнские платы. Но такие решения стоят гораздо дороже обычных серверов и те кто их покупает — понимаю зачем это надо.
Вернёмся к серверам начального и среднего уровней. Существенно повышает беспрерывность работы серверов возможность горячей замены компонентов.
Горячая замена дисков
Горячую замену дисков можно производить практически со всеми вариантами интерфейсов. Конечно, есть и некоторые ограничения.
IDE устройства редко переносят отключение/подключение второго устройства на шлейф — велик риск пропадания работающего устройства из системы. Главная проблема интерфейса IDE в правильной обработке операционной системой этого события. Так как интерфейс IDE не предусматривает горячей замены, в большинстве случаев необходимо вручную запустить сканирование устройств для определения нового оборудования. Важный момент — интерфейс подключается/отключается к обесточенному диску (подключение: сначала интерфейс, потом питание, отключение: сначала питание, потом интерфейс).
ОТКАЗ ОТ ОБЯЗАТЕЛЬСТВ: выполняя отключение/подключение устройств IDE Вы делаете это на свой страх и риск — никто не гарантирует сохранение работоспособности оборудования, и стабильность работы ОС.
Интерфейсы FC, SAS, SATA (AHCI) — поддерживают горячую замену дисков в полном объеме, проблемы могут быть в операционной системе. Если дисковый контроллер SATA находится в режиме совместимости IDE — то, возможно, понадобится вручную запустить сканирование шины. В режиме AHCI в большинстве случаев диск определится автоматически. Рекомендую использовать AHCI, если ваша ОС это позволяет, т.к. этот режим также повышает производительнось диска; TRIM поддерживается только в этом режиме работы контроллера.
При отключении дисков для продления срока их службы рекомендую предварительно отключать их программным методом и извлекать после остановки шпинделя, т.е. через примерно 30 секунд после выключения для дисков 7200RPM. Если диск невозможно отключить программно и он установлен в hot-swap корзинке, рекомендую вытащить диск на минимальное расстояние, при котором диск будет отключен, подождать остановки шпинделя и извлечь окончательно. В большинстве систем — это расстояние полностью отведённой ручки корзинки. Конечно, эти действия не несут практического смысла, если диск вышел из строя, но, возможно, он просто «завис» и вам не поменяют его по гарантии и придется использовать в некритичном оборудовании.
Так же важно понимать, что диск находится в составе RAID или как отдельное блочное устройство. При использовании отдельного диска необходимо предварительно его отмонтировать для избежания сбоев в работе ОС и программного обеспечения. Даже если диск не используется в текущий момент, после извлечения примонтированого диска зачастую наблюдаются лаги всей ОС. Конечно же, диск, на котором установлена ОС, извлечь без «зависания» не получится.
Большинство серверов позволяет подсветить индикатором диск по команде с сервера, по возможности пользуйтесь этой функцией, для минимизации ошибочных извлечений дисков. Например на серверах SuperMicro номер корзинки указан на самой корзинке, и может не совпадать с номером слота на бэкплейне. Такая-же проблема есть у многих производителей.
Так же перед отключением желательно получить информацию о диске (модель, объем, серийный номер) для сопоставления сразу после извлечения диска. Во многих случаях при ошибочном извлечении другого диска это позволит устранить ошибку сразу, а иногда даже предотвратить сбой в работе или потерю данных.
В случае использования RAID-массивов, рекомендую отключать диски программно (помечать как сбойные), перед извлечением это устранит снижение производительности дисковой системы сразу после отключения диска.
Проблем с SSD дисками при частом горячем подключении/извлечении не заметил, хотя использовал несколько именно в таком режиме.
На этом первая часть заканчивается, в следующей частях про RAID массивы, память для серверов, системы удалённого управления и про важность мониторинга.
Собственно хотелось бы понять последовательность действий.
Как правило когда RAID создается, то все диски форматируются.
Если у меня из 2 дисков 1 вышел из строя, что нужно делать по шагам?
Мои предположения:
1) Разбить рэйд
2) заменить битый диск на новый
3) собрать рэйд
На 3 шаге,я предполагаю, система отформатирует оба диска и я останусь ни с чем.
И попутно - как можно оба диска заменить в RAID-1 вместе с переносом всех данных?
- Вопрос задан более трёх лет назад
- 14932 просмотра
У RAID есть forced rebuild, с которым регулярно косячит масса людей, уничтожая данные при замене диска, и "правильный" rebuild, который выполняется с учётом замены только одного диска.
Форматированием, как я понимаю, вы называете именно forced rebuild, либо инициализацию.
В зависимости от того, как вы создавали массив, у вас должны быть средства управления им. Наверняка где-то там вы и увидели информацию о том, что один из дисков необходимо заменить. Изучите соответствующую справку/документацию на предмет того, как правильно заменять диски без потери данных.
Однако, с учётом того, сколько случаев потери данных при замене диска в RAID мы видим, я бы всё равно рекомендовал сделать копию хотя бы важных данных перед заменой (а лучше всех). Наличие копии данных также позволит вам просто создать новый RAID1 с нуля и потом скопировать на него файлы.
1)Отключаете неисправный.
2)Подключаете исправный.
3)Даете команду контроллера на rebuild.
1)Убрать старые диски.
2)Поставить новые диски.
3)Дать команду контроллеру на построение RAID.
4)Восстановить все данные из бэкапа.
А есть способ переноса данных плавно?
Ну типа поменяли 1 диск, синхронизировали, поменяли 2 диск, синхронизировали?
sbh, Можно и так.
Это собственно вариант замены одного диска - замена одного диска, без остановки работы.
После того как замените и убедитесь что все отлично - меняем другой диск.
АртемЪ, помоему если заменить диск - контроллер скажет что новый не является членом рэйда. чтобы его добавить нужно создать рйэд, а в момент создания оба диска форматируются.
sbh, Вы отключаете один диск- рэйд работает в режиме degrade - потеря избыточности.
Добавляете диск и делаете ребилд массива - рэйд снова в работе.
Вообще RAID1 делают для единственной цели - обеспечить непрерывную работу, даже в случае отказа диска.
Поэтому любой контроллер способен справится с ситуацией отказа или удаления одного из дисков, и корректно перестроить массив при добавлении нового диска.
Какие именно команды нужно давать контроллеру - тут зависит от контроллера, надо читать доки.
Добрый день. Использую Raspberry Pi 4 в качестве NAS устройства. Год опыта использования показывают хорошие результаты, более чем доволен. Но вот задался вопросом. В случае какого-то сбоя, проблемы с одним из жестких дисков или его замены, как правильно его будет отключить и подключить новый? Не просто же вытягивать?
Современные контроллеры умеют в горячую замену. Главное питание подключай последним и отключай первым.
Современные контроллеры умеют в горячую замену.
Имеется ввиду контроллеры на HDD? У меня Western Digital Red Plus.
Главное питание подключай последним и отключай первым.
Понял. А программно никакого сбоя не будет ?
лучше не надо у меня так пару штук на полочке лежат , контроллер навернулся в дисках .
На FreeBSD через camcontrol можно отключить питание.
SATA рассчитан на горячую замену. RAID, в нормальных условиях, от отказа HDD не умирает. Ну а дальше как пойдёт, лучший вариант конечно - это когда HDD не на шлейфах, а в жёсткой корзинке, тогда и за очерёдностью отсоединения контактов следить не надо. Ну и у mdadm есть команды вывода устройства из массива, можно заранее сделать.
В режиме AHCI(а режим IDE compatibility сейчас используют только в очень специфических случаях) горячая замена на SATA предусмотрена. Порядок отключения тут уже упомянули. Диск автоматически добавляется в массив при наличии метаданных, которых на новом чистом диске естественно не будет. В mdadm есть ключ для замены сбойного диска на новый(--re-add)
Под горячую замену выделяется диск (или несколько). Эти диски участвуют в массиве в роле hot-spare, то есть они используются только для замены вышедшего из строя диска, а в остальное время простаивают.
Сколько дисков, размер дисков и массива соотвественно?
4 диска по 2 терабайта, то есть нужно докупать SAS-экспандеры для подключения дисков для hot-spare?
не делай kvm на lvm, делай kwm на qcow2 или raw
Или жить без hot-spare дисков. В таком случае надо просто отслеживать состояние RAID и держать наготове запасные диски.
Вообще говоря, зависит от задачи. Если во время аварии допускается некоторое понижение производительности на время замены и синхронизации диска - то необходимости именно в hot-spare на мой взгляд нет.
Насчёт LVM vs QCOW/RAW вопрос спорный. В случае с LVM минимум накладных расходов на дисковые операции, в случае с файловым хранилищем - ещё и ФС в которой они лежат.
Подскажите как бипер вырубить, я сымитировал отключение одного из дисков рэйд, потом поставил диску статус гуд и делаю замену проценты потекли всё норм, но находиться с этим серваком просто невозможно.
Если кто сталкнется то вот команда для отключения звука при замене диска
./MegaCli64 -AdpSetProp AlarmSilence -aN
Ждать ребилд пару часов и слушать этот ужасный писк было невыносимо
И как воспользоваться функцией горячей замены если один из дисков выйдет из строя без отключения системы, MegaCLI как я понял позволяет делать только горячий резерв.
Из горячего резерва диск подхватится сам. Потом надо извлечь отказавший, вставить исправный, добавить его в горячий резерв через megacli
Насчёт LVM vs QCOW/RAW вопрос спорный. В случае с LVM минимум накладных расходов на дисковые операции, в случае с файловым хранилищем - ещё и ФС в которой они лежат.
вообще-то это не vs. то есть qcow2 и raw это формат имиджа а LVM и файлы это метод хранения имиджа.
Поддерживаю предыдущего оратора. 3 года использую qcow2 на LVM, брат жив.
KVM на LVM томах. - правильный подход, это позволяет убрать прокладку в виде ФС и делать снапшоты.
Выкинуть megacli с его идиотским мозгодробительным синтаксисом и установить понятный и логичный storcli.
Горячая замена блоков питания
В моей практике, сгоревших БП (блоков питания) было немного, но наличие в сервере hot-swap БП, подключённых по схеме N+N во многих случаях существенно увеличивает бесперебойность работы сервера. Если в сервере больше двух БП, то зачастую реализована схема N+1, что не позволяет питать сервер от двух независимых источников или линий питания. Электропитание с подачей в стойку двух независимых линий повышает бесперебойность в самых различных ситуациях, например при обслуживании или аварии систем энергообеспечения в датацентре. Был случай, в сервере вышел из строя БП и создал короткое замыкание, что привело к срабатыванию защиты PDU и его отключению, соседние сервера с БП по схеме 1+1, подключённые также к другому PDU продолжили работу. Резервирование БП позволяет изменять подключение сервера к сети энергообеспечения, не прерывая его работу, например, оптимизировать укладку кабелей (конечно, правильно укладывать кабеля надо при установке сервера, но мы живём в не идеальном мире).
Вопреки заблуждению сертификация 80 Plus указывает на энергоеффективность блока питания, и не обязывает производителя к обеспечению какого либо уровня надёжности.
Также резервирование БП предотвращает большинство проблем связанных с кабелями питания. Плохой контакт некачественных кабелей, случайное их выдергивание персоналом при работах. Если у вас сервер с одним блоком питания, использование для него качественного и неизношенного кабеля, который плотно устанавливается в гнездо, и при нагрузке не издаёт посторонних звуков (потрескивание) более важно — невозможна замена без остановки сервера. В случае сервера с резервированными БП, плохой контакт кабеля может привести к выходу блока питания из строя.
Читайте также: