Замена диска в raid 1
Допустим, у сервера 2 диска: /dev/sda и /dev/sdb . Эти диски собраны в софтверный RAID1 с помощью утилиты mdadm --assemble .
Один из дисков вышел из строя, например, это /dev/sdb . Повержденный диск нужно заменить.
Перед заменой диска желательно убрать диск из массива.
Введение
Когда первый раз сталкиваешься с рукожопством сотрудников техподдержки дата центра, впадаешь в ступор и думаешь, ну как так то? Сейчас я спокойно отношусь к таким ситуациям и действую исходя из самых худших ожиданий. На днях я столкнулся с ситуацией, когда мне заменили не тот диск в сервере с RAID1. Вместо сбойного диска вынули рабочий и заменили чистым. К счастью все закончилось хорошо, но обо всем по порядку.
Не скажу, что у меня прям большой опыт аренды серверов, но он есть. Я регулярно обслуживаю 10-15 серверов, расположенных в разных дата центрах, как российских, так и европейских. Первый негативный опыт я получил именно в Европе и был очень сильно удивлен и озадачен. Я, как и многие, был под влиянием либеральной пропаганды на тему того, что у нас все плохо, а вот Европа образец надежности, стабильности и сервиса. Как же я ошибался. Сейчас отдам предпочтение нашим дата центрам. По моему мнению и опыту, у нас тех поддержка и сервис в целом лучше, чем там, без привязки к стоимости. В Европе дешевле схожие услуги, так как там масштабы сервисов в разы больше.
Приведу несколько примеров косяков саппорта, с которыми сталкивался.
Было много всяких инцидентов помельче, нет смысла описывать. Хотя нет, один все же опишу. Устанавливал свой сервер в ЦОД. Решил пойти в маш зал и проконтролировать монтаж. Если есть такая возможность, крайне рекомендую ей воспользоваться. Местный рукожоп неправильно прикрепил салазки и сервер во время монтажа стал падать. Я его поймал, тем спас его и сервера других клиентов. В итоге помог с монтажом. Сам бы он просто не справился. Я не представляю, что было, если бы я не пошел в машзал. К чести руководства, я написал претензию, где подробно описал данный случай и попросил бесплатно месячную аренду. Мне ее предоставили. Советую всем так поступать. Зачастую, руководство может быть не в курсе того, что происходит в реальности. Надо давать обратную связь.
Уровень моего доверия к тех поддержке дата центров и хостингов вы примерно представляете :) Ну и вот случилось очередное ЧП. Подробнее остановлюсь на этой ситуации, так как она случилась вчера, свежи воспоминания.
Установить загрузчик
После добавления диска в массив нужно установить на него загрузчик.
Если сервер загружен в нормальном режиме или в infiltrate-root , то это делается одной командой:
Если сервер загружен в Recovery или Rescue (т.е. с live cd), то для установки загрузчика:
Смонтируйте корневую файловую систему в /mnt :
Смонтируйте /dev , /proc и /sys :
Выполните chroot в примонтированную систему:
Установите grub на sdb :
Затем попробуйте загрузиться в нормальный режим.
You are in emergency mode
У меня много примеров того, как я восстанавливал загрузку сломавшихся linux дистрибутивов.
В данной ситуации с mdadm я был уверен, что все получится, так как сам массив с системой жив, данные доступны. Надо только разобраться, почему система не загружается. Напомню, что ошибка загрузки была следующая.
Дальше нужно ввести пароль root и вы окажетесь в системной консоли. Первым делом я проверил состояние массива mdadm.
Состояние массива md0, на котором располагается раздел /boot - inactive. Вот, собственно, и причина того, почему сервер не загружается. Судя по всему, когда был подключен сбойный диск, mdadm отключил массив, чтобы предотвратить повреждение данных. Не понятно, почему именно на разделе /boot, но по факту было именно это. Из-за того, что массив остановлен, загрузиться с него не получалось. Я остановил массив и запустил снова.
После этого массив вышел из режима inactive и стал доступен для дальнейшей работы с ним. Я перезагрузил сервер и убедился, что он нормально загружается. Сервер фактически был в рабочем состоянии, просто с развалившимся массивом mdadm, без одного диска.
Если вам это не поможет, предлагаю еще несколько советов, что можно предпринять, чтобы починить загрузку. Первым делом проверьте файл /etc/fstab и посмотрите, какие разделы и как там монтируются. Вот мой пример этого файла.
Вам нужно убедиться, что указанные lvm разделы /dev/mapper/vg0-root и /dev/mapper/vg0-swap_1 действительно существуют. Для этого используйте команду:
Подробно об этой команде, о работе с lvm и вообще с дисками я рассказываю в отдельной статье - настройка диска в debian. Если с lvm разделами все нормально, проверьте /boot. У меня он монтируется по uuid. Посмотреть список uuid всех разделов можно командой.
Как вы видите, у меня uuid раздела для загрузки полностью совпадает с тем, что указано в fstab. Если по какой-то причине uuid изменился (разобрали и собрали новый массив), отредактируйте fstab.
Все дальнейшие действия я делал уже по ssh. Скопировал таблицу разделов с рабочего диска sda на чистый sdb.
Проверил таблицы разделов и убедился, что они идентичные.
Скопировал раздел BIOS boot partition с рабочего диска на новый.
Потом добавил разделы диска sdb2 и sdb3 в рейд массив.
Дождался окончания ребилда и убедился, что он прошел. Проверил состояние массива.
В завершении устанавливаем загрузчик на оба диска.
После этого я перезагрузился и убедился, что все работает нормально. По хорошему, теперь надо было бы поменять загрузочный диск с первого на второй и убедиться, что со второго тоже нормально грузится. Я не стал этого делать, и так простой и так был велик. Главное, чтобы массив был на месте, а починить загрузку, если что, дело техники.
Вот и все по замене диска в массиве mdadm. После доступа к консоли сервера, мне потребовалось минут 10, чтобы вернуть сервер в рабочее состояние.
Добавить диск в массив
Если на /dev/sdb созданы разделы, то можно добавить диск в массив:
После добавления диска в массив должна начаться синхронизация. Скорость зависит от размера и типа диска (ssd/hdd):
Замена диска в рейде mdadm
Речь пойдет о дешевых дедиках от selectel. Я их много где использую и в целом готов рекомендовать. Это обычные десктопные системники за скромные деньги. Свое мнение об этих серверах, а так же сравнение с полноценными серверами сделаю в конце, в отдельном разделе.
На сервере была установлена система Debian из стандартного шаблона Selectel. Вот особенности дисковой подсистемы этих серверов и шаблона.
- 2 ssd диска, объединенные в mdadm
- /boot раздел на /dev/md0 размером 1G
- корень / на /dev/md1 и поверх lvm на весь массив
В целом, хорошая и надежная разбивка, чему будет подтверждение дальше. На сервере был установлен proxmox, настроен мониторинг mdadm. Мониторинг дисков не сделал. В какой-то момент получил уведомление в zabbix, что mdadm развалился. Сервер при этом продолжал работать. Ситуация штатная. Пошел в консоль сервера, чтобы все проверить. Посмотрел состояние рейда.
Убедился, что один диск выпал из массива. В системном логе увидел следующее.
Попробовал посмотреть информацию о выпавшем диске.
Информации не было, утилита показывала ошибку обращения к диску. Получилось посмотреть модель и серийный номер только работающего диска.
Я не стал разбираться, что там к чему с диском. Если вижу проблемы, сразу меняю. Предупредил заказчика, что с диском проблемы, нужно планировать замену. Так как железо десктопное, "сервер" надо выключать. Согласовали время после 22 часов. Я в это время уже сплю, поэтому написал тикет в тех поддержку, где указал время и серийный номер диска, который нужно было оставить. Я сделал на этом акцент, объяснил, что сбойный диск не отвечает, поэтому его серийник посмотреть не могу. Расписал все очень подробно, чтобы не оставить почвы для недопонимания или двойного толкования. Я в этом уже спец, но все равно не помогло.
Я спокойно согласился на эту операцию, потому что часто делаются бэкапы и они гарантированно рабочие. Настроен мониторинг бэкапов и делается регулярное полуручное восстановление из них. Договоренность была такая, что хостер после замены дожидается появления окна логина, а заказчик проверяет, что сайт работает. Все так и получилось - сервер загрузился, виртуалки поднялись, сайт заработал. На том завершили работы.
Утром я встал и увидел, что весь системный лог в ошибках диска, рабочего диска в системе нет, а есть один глючный и один новый. Сразу же запустил на всякий случай ребилд массива и он вроде как даже прошел без ошибок. Перезагрузка временно оживила сбойный диск. В принципе, на этом можно было бы остановиться, заменить таки сбойный диск и успокоиться. Но смысл в том, что этот сбойный диск почти сутки не был в работе и данные на нем старые. Это не устраивало. Потом пришлось бы как-то склеивать эти данные с данными из бэкапов. В случае с базой данных это не тривиальная процедура. Созвонился с заказчиком и решили откатываться на рабочий диск, который вытащили накануне ночью.
Я создал тикет и попросил вернуть рабочий диск на место. К счастью, он сохранился. К нему добавить еще один полностью чистый. Хостер оперативно все сделал и извинился. В завершении прислал скриншот экрана сервера.
И самоустранился. Дальше решать проблему загрузки он предложил загрузившись в режиме rescue. Этот режим доступен через панель управления сервером в админке, даже если сервер не имеет ipmi консоли. Как я понял, по сети загружается какой-то live cd для восстановления. Я в нем загрузился, убедился, что данные на месте, но понять причину ошибки не смог. Может быть и смог бы, если бы дольше покопался, но это очень неудобно делать, не видя реальной консоли сервера. Я попросил подключить к серверу kvm over ip, чтобы я мог подключиться к консоли. Тех поддержка без лишних вопросов оперативно это сделала.
К слову, мне известны случаи, когда техподдержка selectel потом сама чинила загрузку и возвращала mdadm в рабочее состояние. Видел такие переписки в тикетах у своих клиентов до того, как они обращались ко мне. Но я не стал настаивать на таком решении проблемы, так как боялся, что будет хуже. К тому же это было утро воскресенья и специалистов, способных это сделать, могло просто не быть. Плюс, я не думаю, что они обладали бы большими компетенциями, чем я. Я бы за их зарплату не пошел работать в ЦОД.
После того, как я подключился к консоли сервера, восстановление загрузки было делом техники.
Копировать разметку для MBR
Для копирования разметки MBR:
Здесь первым пишется диск, с которого копируется разметка, а вторым — на который копируется.
Если разделы не видны в системе, то можно перечитать таблицу разделов командой:
В чем отличия программного и аппаратного рейда
Сейчас расскажу, чем принципиально отличается программный рейд контроллер (mdadm) от аппаратного, для тех, кто этого до конца не понимает. Если бы у меня вышел из строя диск на аппаратном рейд контроллере, установленном в полноценный сервер, проблема по замене сбойного диска в RAID решалась бы в следующей последовательности:
- Рейд контроллер оповещает о том, что с диском проблемы и выводит его из работы. В случае с софтовым рейдом система может зависнуть в случае проблем с диском, прежде чем пометит его как проблемный и перестанет к нему обращаться.
- Я оставляю тикет в тех поддержку, где прошу заменить сбойный диск. Информацию о нем я посмотрю в панели управления рейд контроллером.
- Сотрудник тех поддержки видит сбойный диск, так как индикация на нем, скорее всего, будет мигать красной лампочкой. Это не гарантия того, что рукожоп все сделает правильно, но тем не менее, шансов, что он ошибется, меньше. Я сталкивался с ситуацией, когда и в этом случае диск меняли не тот.
- При появлении нового диска raid контроллер автоматически начинает ребил массива.
Если же у вас в сервере уже установлен запасной диск на случай выхода из строя диска в составе raid массива, то все еще проще:
- При выходе из строя диска, контроллер помечает его как сбойный, вводит в работу запасной диск и начинает ребилд.
- Вы получаете оповещение о том, что вышел из строя диск и оставляете тикет в тех поддержку на замену запасного диска.
И это все. В обоих случаях у вас вообще нет простоя. Вот принципиальная разница между mdadm и железным raid контроллером. Стоимость полноценного сервера с контроллером и постоянным ipmi доступом к консоли в среднем в 3 раза выше, чем у сервера на десткопном железе с софтовым рейдом при схожей производительности. Это все при условии, что вам достаточно одного процессора и 64G памяти. Это потолок для десктопных конфигураций. Дальше считайте сами, что вам выгоднее. Если возможен простой в несколько часов на замену диска или других комплектующих, то смело можно использовать десктопное железо. Mdadm обеспечивает сопоставимую гарантию сохранности данных в сравнении с железным контроллером. Вопрос лишь в простое и производительности. Ну и своевременные бэкапы добавляют уверенности в том, что вы переживете неполадки с железом.
При использовании железного рейда на hdd дисках, есть возможно получить очень значительный прирост скорости за счет кэша контроллера. Для ssd дисков я особо не замечал разницы. Но это все на глазок, никаких замеров и сравнений я не делал. Нужно еще понимать, что десктопное железо в целом менее надежное. К примеру, в том же селектеле на дешевых серверах я ловил перегрев или очень высокую температуру дисков. Прыгала в районе 55-65 градусов. Все, что ниже 60-ти, тех поддержка футболила, говоря, что это допустимая температура, судя по документации к дискам. Это так и есть, но мы же понимаем, что диск, постоянно работающий на 59 градусах с бОльшей долей вероятности выйдет из строя.
Вот еще пример разницы в железе. Если у вас в нормальном сервере выйдет из строя планка памяти, сервер просто пометит ее как сбойную и выведет из работы. Информацию об этом вы увидите в консоли управления - ilo, idrac и т.д. В десктопном железе у вас просто будет постоянно виснуть сервер и вам придется долго выяснять, в чем же проблема, так как доступа к железу у вас нет, чтобы проще было запланировать тестирование сервера. А если вы закажете это у тех поддержки, то есть ненулевая вероятность, что станет хуже - сервер уронят, перепутают провода подключения дисков и т.д. В общем, это всегда риск. Проще сразу съезжать с такой железки на другую.
3 Удаление неисправного жёсткого диска
Для удаления /dev/sdb, пометим /dev/sdb1 и /dev/sdb2 как неисправные и удалим их из соответствующих массивов RAID (/dev/md0 и /dev/md1).
Для начала отметим /dev/sdb1 как неисправный:
Выходные данные в
должны выглядеть следующим образом:
Затем удалим /dev/sdb1 из /dev/md0:
Выходные данные должны быть следующими:
должно быть следующим:
Теперь проделаем тоже самое с /dev/sdb2 (который является частью /dev/md1):
Затем выключим систему:
и заменим старый жёсткий диск /dev/sdb на новый (по крайней мере объём нового жесткого диска должен совпадать со старым –если размер на несколько МБ меньше, то перестроить массивы будет невозможно).
4-Добавление нового жёсткого диска
После замены жёсткого диска /dev/sdb, включим систему.
Первым делом необходимо создать точно такое же разбиение на разделы, что и в /dev/sda. Выполним это командой sgdisk из пакета gdisk. Если у Вас не установлен gdisk, установите его, выполнив для Debian и Ubuntu следующее:
Для rpm-дистрибутивов Linux, таких как CentOS:
Следующий шаг необязательный, но рекомендуемый. Для проверки того, что у нас есть резервная копия схемы раздела, воспользуемся sgdisk для записи схем раздела обоих дисков в файл. В нашем случае файл сохраним в /root folder.
В случае неудачи можно восстановить таблицу разделов с помощью опции --load-backup в sgdisk .
Теперь скопируем схему раздела из /dev/sda в /dev/sdb:
Затем необходимо рандомизировать GUID на новом жёстком диске, чтобы убедится, что он уникален.
для проверки, что оба жёстких диска имеют одинаковое разбиение на разделы.
Далее добавим /dev/sdb1 в /dev/md0 и /dev/sdb2 в /dev/md1:
Теперь оба массива (/dev/md0 и /dev/md1) будут синхронизированы.
Результат можно увидеть по команде:
Во время синхронизации выходные данные должны выглядеть следующим образом:
А по окончании синхронизации выходные данные должны выглядеть следующим образом:
Довелось понастраивать сервер DELL T610 с рейд контроллером PERC H700 на борту. Все как обычно, кроме одного нюанса. Решил проверить, как оперативно выполнить замену сбойного диска. На сервер была установлена стандартная утилита mеgacli для управления всеми контроллерами с драйвером MegaRAID, к коим относится и упомянутый выше. Такая тривиальная задача оказалась не совсем тривиальной и пришлось поковыряться с документацией.
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти вступительный теcт.
У меня был сервер на Debian 8 с 3 рейдами, raid1, raid1, raid10. Я вытаскивал диск из raid10 и заменял его новым.
Обращаю внимание, это важно. Я вставлял обратно не тот же самый диск, как часто делают, а другой. Это принципиально разные события. Если вынуть диск, а потом его же поставить на место, то ребилд пойдет автоматом и делать ничего дополнительно не надо. Если же вы другой физический диск ставите, то нужно будет проделать все то, что я сейчас опишу.
Сначала проверим состояние наших массивов:
Чувствуете хардкор? Еще нет? Тогда поехали дальше. Обращаю внимание, что последний массив помечен как Degraded, из него вынут диск. Это raid10. К сожалению, я так и не понял, как через megacli посмотреть тип массива. Где тут указано, что в массиве raid10, я не понял. Теперь посмотрим на список дисков:
Нас интересует последний диск. В Firmware state указано Unconfigured(good). Это я уже воткнул новый пустой диск, вместо старого. Если с диском будут какие-то проблемы, то его состояние будет Failed. Дальше вам важно запомнить следующие значения этого диска:
- Enclosure Device ID: 32
- Slot Number: 7
- DiskGroup: 2
Первые два - ID и номер слота жесткого диска. Они нам нужны в дальнейших командах для обозначения диска. Последнее, судя по всему, принадлежность к номеру DiskGroup в описании массива. Я не уверен в этом на 100%, но в моем случае эти данные для всех дисков и массивов показывали полное совпадение. Скорее всего это так. Проверьте по этой цифре, точно ли сбойный диск принадлежит к тому массиву, о котором вы думаете.
Я немного забежал вперед и поторопился с заменой диска. Я вытащил диск, загрузил сервер, убедился, что он работает без диска и что массив понимает, что он находится в состоянии Degraded. После этого мне нужно было бы выполнить следующие команды.
Отключить сбойный диск:
Пометить его как отключенный:
Я это не сделал, а просто выключил сервер и установил новый диск. После включения убедился, что новый диск присутствует в списке дисков и его статус Unconfigured(good). После этого я указываю контроллеру, что диск заменен:
Над этой командой я долго ломал голову. Расскажу по порядку, что тут к чему.
Array3. Откуда взялась цифра 3? Вот описание:
"The number N of the Array parameter is from the "Span Reference:" line you get using MegaCli -CfgDsply -aALL, minus the 0x0 part."
Выполняем команду просмотра конфигурации:
Получается такая простыня, которую очень трудно читать и анализировать. Грепаю вывод, чтобы разобраться, что тут вообще выходит:
Вижу, что у меня 4 конфигурации, хотя массива только 3. Рассуждаю логически. Так как последний массив это RAID10, то наверно он отображается как 2 RAID1. Проверил внимательно вывод конфигурации, убедился, что так оно и есть. Первые 2 рейда обозначены как DISK GROUP: 0 и 1, а raid10 как SPANNED DISK GROUP: 0, в котором соответственно SPAN: 0 и 1. Один из SPAN имеет статус Degraded и параметр Span Reference: 0x03. Судя по документации, мне надо взять это число 0x03 и отбросить 0x0. Получается цифра 3 и параметр Array3 в команде.
Дальше следует параметр row. Я очень старался понять что это такое :) Описание:
"The number N of the row parameter is the Physical Disk in that span or array starting with zero (it can be but is not always the physical disk’s slot!)".
Только сейчас, когда пишу статью, легко понимаю, откуда берется эта цифра. А когда тестировал сильно тупил и никак не мог сообразить. Сильно мешает очень объемный вывод команд. Я устал глазами бегать по простыням. В общем, это номер диска в сбойном SPAN. В моем случае это второй диск в SPAN, то есть цифра 1, так как отсчет идет с нуля. Таким образом получился параметр row1. Еще раз напоминаю команду замены сбойного диска:
Пока мы только указали, что заменили диск. Теперь нам надо запустить его ребил:
Статус ребилда смотрим командой:
После окончания ребилда снова смотрим вывод информации по массивам и дискам. Массив должен стать Optimal, а диск Online, Spun Up. На этом забываем про megacli как страшный сон и вспоминаем про приятный и удобный mdadm.
Я всегда тестирую выход из строя жесткого диска и его замену. Делаю на всех массивах, железных и софтовых. На железных, чтобы вот таких сюрпризов не было, а была рабочая инструкция. А в софтовых, в основном, чтобы убедиться, что загрузчик стоит на всех нужных дисках и система поднимется в случае чего. По надежности и замене дисков у меня к mdadm вопросов нет. Там все понятно и просто.
Хочу рассказать поучительную историю, которая случилась со мной на днях. На одном из серверов в ЦОД вышел из строя диск в составе рейда mdadm. Ситуация типовая, с которой регулярно сталкиваюсь. Оставил заявку в техподдержку на замену диска с указанием диска, который надо поменять. В цоде заменили рабочий диск и оставили сбойный. Дальше история, как я решал возникшую проблему.
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти вступительный теcт.
2 Как узнать, что жёстких диск неисправен?
Если жёсткий диск неисправен, в журнале регистрации событий появится большое количество ошибок, например в /var/log/messages или /var/log/syslog.
Можно также выполнить:
и вместо строки [UU] получится [U_], что означает, что массив RAID1 неполон.
Цели статьи
- Рассказать поучительную историю о том, какие могут быть проблемы при аренде серверов в ЦОД.
- Показать на примере, как надо действовать при выходе из строя диска в рейде mdadm.
- Простыми словами объяснить, в чем разница между программным и аппаратным рейдом.
Определить таблицу разделов (GPT или MBR) и перенести ее на новый диск
После замены поврежденного диска нужно добавить новый диск в массив. Для этого надо определить тип таблицы разделов: GPT или MBR. Для этого используется gdisk .
Где /dev/sda — исправный диск, находящийся в RAID.
Для MBR в выводе будет примерно следующее:
Для GPT примерно следующее:
Перед добавлением диска в массив на нем нужно создать разделы в точности такие же, как и на sda . В зависимости от разметки диска это делается по-разному.
Заключение
Надеюсь, моя статья была интересной. Для тех, кто никогда не работал с ЦОДами будет полезно узнать, чего можно от них ожидать. Я скучаю по временам, когда все сервера, которые я администрировал, были в серверной, куда никому не было доступа и куда я мог в любой момент попасть и проверить их. Сейчас все стало не так. И твои сервера уже не твои. Их может сломать, уронить, что-то перепутать сотрудник тех поддержки дата центра.
Сейчас большой тренд на переход в облака. Я смотрю на эти облака и не понимаю, как с ними можно нормально взаимодействовать. Заявленная производительность не гарантированная, нагрузка плавает в течении суток. Упасть может в любой момент и ты не будешь понимать вообще в чем проблема. Твои виртуалки могут быть по ошибке удалены и кроме извинений и компенсации в 3 копейки ты ничего не получить. Каждое обращение в ТП как лотерея. Думаешь, что сломают в этот раз. Если сервера железные, то когда пишу тикет на доступ к железу, я морально и технически всегда готов к тому, что этот сервер сейчас отключится и я больше не смогу к нему подключиться.
В целом, опыт работы с облаками у меня негативный. Несколько раз пробовал для сайтов и все время съезжал. Нет гарантированного времени отклика. А это сейчас фактор ранжирования. Для очень быстрого сайта остается только один вариант - свое железо, а дальше уже кому какое по карману. Зависит от надежности и допустимого времени простоя.
Я про облака заговорил, потому что тенденции к тому, что от железных серверов надо отказываться и все переносить в облака. С одной стороны удобно должно быть. Как минимум, не будет указанных выше в статье проблем. А с другой стороны добавляется куча других проблем. Я пока сижу на железяках разного качества и стоимости. А у вас как?
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.
Проверьте себя на вступительном тесте и смотрите подробнее программу ссылке.
Заменить диск, если он сбойный
Диск в массиве можно условно сделать сбойным с помощью ключа --fail (-f) :
Сбойный диск можно удалить с помощью ключа --remove (-r) :
Добавить новый диск в массив можно с помощью ключей --add (-a) и --re-add :
Собственно хотелось бы понять последовательность действий.
Как правило когда RAID создается, то все диски форматируются.
Если у меня из 2 дисков 1 вышел из строя, что нужно делать по шагам?
Мои предположения:
1) Разбить рэйд
2) заменить битый диск на новый
3) собрать рэйд
На 3 шаге,я предполагаю, система отформатирует оба диска и я останусь ни с чем.
И попутно - как можно оба диска заменить в RAID-1 вместе с переносом всех данных?
У RAID есть forced rebuild, с которым регулярно косячит масса людей, уничтожая данные при замене диска, и "правильный" rebuild, который выполняется с учётом замены только одного диска.
Форматированием, как я понимаю, вы называете именно forced rebuild, либо инициализацию.
В зависимости от того, как вы создавали массив, у вас должны быть средства управления им. Наверняка где-то там вы и увидели информацию о том, что один из дисков необходимо заменить. Изучите соответствующую справку/документацию на предмет того, как правильно заменять диски без потери данных.
Однако, с учётом того, сколько случаев потери данных при замене диска в RAID мы видим, я бы всё равно рекомендовал сделать копию хотя бы важных данных перед заменой (а лучше всех). Наличие копии данных также позволит вам просто создать новый RAID1 с нуля и потом скопировать на него файлы.
1)Отключаете неисправный.
2)Подключаете исправный.
3)Даете команду контроллера на rebuild.
1)Убрать старые диски.
2)Поставить новые диски.
3)Дать команду контроллеру на построение RAID.
4)Восстановить все данные из бэкапа.
А есть способ переноса данных плавно?
Ну типа поменяли 1 диск, синхронизировали, поменяли 2 диск, синхронизировали?
sbh, Можно и так.
Это собственно вариант замены одного диска - замена одного диска, без остановки работы.
После того как замените и убедитесь что все отлично - меняем другой диск.
АртемЪ, помоему если заменить диск - контроллер скажет что новый не является членом рэйда. чтобы его добавить нужно создать рйэд, а в момент создания оба диска форматируются.
sbh, Вы отключаете один диск- рэйд работает в режиме degrade - потеря избыточности.
Добавляете диск и делаете ребилд массива - рэйд снова в работе.
Вообще RAID1 делают для единственной цели - обеспечить непрерывную работу, даже в случае отказа диска.
Поэтому любой контроллер способен справится с ситуацией отказа или удаления одного из дисков, и корректно перестроить массив при добавлении нового диска.
Какие именно команды нужно давать контроллеру - тут зависит от контроллера, надо читать доки.
В данной статье рассмотрим, как удалить неисправный жёсткий диск из массива Linux RAID1 (программное обеспечение RAID) и добавить новый жёсткий диск в массив RAID1 без потери данных. Для копирования схемы раздела диска будем использовать gdisk. Данная программа также работает на большинстве жёстких дисков с GPT (GUID Partition Table).
1 Предварительные замечания
Рассмотрим в качестве примера 2 жёстких диска, /dev/sda и /dev/sdb, с разделами /dev/sda1, /dev/sda2, /dev/sdb1 и /dev/sdb2.
/dev/sdb неисправен и нам потребуется заменить его.
Удалить диск из массива
Проверьте, как размечен диск в массиве:
В данном случае массив собран так, что md0 состоит из sda2 и sdb2 , md1 — из sda3 и sdb3 .
На этом сервере md0 — это /boot , а md1 — своп и корень.
Удалите sdb из всех устройств:
Если разделы из массива не удаляются, то mdadm не считает диск неисправным и использует его, поэтому при удалении будет выведена ошибка, что устройство используется.
В этом случае перед удалением пометьте диск как сбойный:
Снова выполните команды по удалению разделов из массива.
После удаления сбойного диска из массива запросите замену диска, создав тикет с указанием s/n сбойного диска. Наличие downtime зависит от конфигурации сервера.
Копировать разметку для GPT
Для копирования разметки GPT:
Обратите внимание! Здесь первым пишется диск, на который копируется разметка, а вторым — с которого копируется (то есть с sda на sdb ). Если перепутать их местами, то разметка на изначально исправном диске будет уничтожена.
Второй способ копирования разметки:
После копирования присвойте диску новый случайный UUID:
Читайте также: