Замена дисков в raid 5 на диски большего объема
Обновлено: 07.07.2024
Допустим, у сервера 2 диска: /dev/sda и /dev/sdb . Эти диски собраны в софтверный RAID1 с помощью утилиты mdadm --assemble .
Один из дисков вышел из строя, например, это /dev/sdb . Повержденный диск нужно заменить.
Примечание: перед заменой диска желательно убрать диск из массива.
Удаление диска из массива
Проверьте, как размечен диск в массиве:
В данном случае массив собран так, что md0 состоит из sda2 и sdb2 , md1 — из sda3 и sdb3 .
На этом сервере md0 — это /boot , а md1 — своп и корень.
Удалите sdb из всех устройств:
Если разделы из массива не удаляются, то mdadm не считает диск неисправным и использует его, поэтому при удалении будет выведена ошибка, что устройство используется.
В этом случае перед удалением пометьте диск как сбойный:
Снова выполните команды по удалению разделов из массива.
После удаления сбойного диска из массива запросите замену диска, создав тикет с указанием s/n сбойного диска. Наличие downtime зависит от конфигурации сервера.
Определение таблицы разделов (GPT или MBR) и ее перенос на новый диск
После замены поврежденного диска нужно добавить новый диск в массив. Для этого надо определить тип таблицы разделов: GPT или MBR. Для этого используется gdisk .
Где /dev/sda — исправный диск, находящийся в RAID.
Для MBR в выводе будет примерно следующее:
Для GPT примерно следующее:
Перед добавлением диска в массив на нем нужно создать разделы в точности такие же, как и на sda . В зависимости от разметки диска это делается по-разному.
Копирование разметки для GPT
Для копирования разметки GPT:
Обратите внимание! Здесь первым пишется диск, на который копируется разметка, а вторым — с которого копируется (то есть с sda на sdb ). Если перепутать их местами, то разметка на изначально исправном диске будет уничтожена.
Второй способ копирования разметки:
После копирования присвойте диску новый случайный UUID:
Копирование разметки для MBR
Для копирования разметки MBR:
Обратите внимание! Здесь первым пишется диск, с которого копируется разметка, а вторым — на который копируется.
Если разделы не видны в системе, то можно перечитать таблицу разделов командой:
Добавление диска в массив
Если на /dev/sdb созданы разделы, то можно добавить диск в массив:
После добавления диска в массив должна начаться синхронизация. Скорость зависит от размера и типа диска (ssd/hdd):
Установка загрузчика
После добавления диска в массив нужно установить на него загрузчик.
Если сервер загружен в нормальном режиме или в infiltrate-root , то это делается одной командой:
Если сервер загружен в Recovery или Rescue-режиме (т.е. с live cd), то для установки загрузчика:
Смонтируйте корневую файловую систему в /mnt :
Смонтируйте /dev , /proc и /sys :
Выполните chroot в примонтированную систему:
Установите grub на sdb :
Затем попробуйте загрузиться в нормальный режим.
Как заменить диск, если он сбойный
Диск в массиве можно условно сделать сбойным с помощью ключа --fail (-f) :
Сбойный диск можно удалить с помощью ключа --remove (-r) :
Добавить новый диск в массив можно с помощью ключей --add (-a) и --re-add :
В наличии файловый сервер. Ubuntu 14.04. Из 3 HDD 1Gb собран RAID5.
Задача: заменить 3 HDD 1Gb на 3 HDD 2Gb
Как я это представляю: отключаю от рейда 1 диск, на его место ставлю новый диск, жду когда рейд сделает ребилд с новым диском. И так со всеми остальными дисками.
рейд поймет, что новый диск большего размера, чем был до этого?
Мы не телепаты. RAID чем сформирован? Общий ответ на вопросы: Вероятно нет.
Райд верняк софтовый.
Лучше сделать бекап и заного на новые винты райд сделать.
Как правило, да. Смотри документацию RAID-контроллера.
Рейд софтовый, собран при установки системы.
Всего подключено 4 винта к SATAII (сиреневые порты) 1 винт c OS и 3 винта с рейдом.
Есть такая идея: Не менять винты на большие, а добавить еще через внешний контролер.
Ставлю этот контроллер, к нему подключаю новые винты, винты добавляю к рейду.
Ставлю этот контроллер, к нему подключаю новые винты, винты добавляю к рейду.
Интерфейс PCI 32-Bit 33MHz
Поддержка стандартов SATA-1
и я вижу там целых 4 порта sata
Если ты очень хочешь, чтобы просела скорость работы со всем массивом, то добавляй конечно через него. Предполагаю, что падение скорости ты заметишь уже при подключении к нему второго винта из 4х возможных (пиковая пропускная способность для 32bit pci 33mhz не более 133МБ/c)
NightOperator ★★★ ( 10.01.17 11:52:18 )Последнее исправление: NightOperator 10.01.17 11:57:27 (всего исправлений: 3)
А если другой контролер, по быстрее, поставить? Смысл есть?
рейд поймет, что новый диск большего размера, чем был до этого?
Если простой сервера в 1-2 дня не критичен, предлагаю: приготовить livecd, подключить новые диски к упомянутому контроллеру (жаль что такое старье, лучше было бы что-нибудь на PCIe), собрать там md-raid нужной конфигурации, скопировать разделы со старых дисков. Убрать старые диски (аккуратно пометив, в каком порту какой стоял), переткнуть новые диски в мать, убрать контроллер и добиться загрузки с новых дисков.
А если другой контролер, по быстрее, поставить
У тебя на матплате стоит P965+ICH8, почитай спеки на неё, на pci rev 2.x и pci-express 1.0 и подумай ;)
NightOperator ★★★ ( 10.01.17 12:04:01 )Последнее исправление: NightOperator 10.01.17 12:10:06 (всего исправлений: 4)
Странно, но никто не написал про бэкапы. ТС они же у вас есть? Воткнуть новые харды, развернуть из бэкапа. По времени простоя скорее всего больше получиться но и гемороя меньше. За теже 1-2 дня уложиться должны.
заодно, бекапы проверить
ТС пишет, что ОС на отдельном винте, наверное и загрузчик там. Или именно из-за этого пункта планируется простой 2 дня?
2ТС. mdadm понимает, но сам ничего не делает. Руками по одному удаляете старый диск из массива, добавляете новый, если добавлете не диск, а раздел диска, то сначала делаете его на весь диск. После того как все диски станут 2Гб, даёте команду:
Иногда возникает ситуация, когда места на сервере начинает не хватать. Хорошо, когда есть дополнительные слоты под диски и можно просто добавить несколько винчестеров и расширить существующий рейд либо создать еще один. Но в случае если свободных слотов нет, ситуация становится проблемной, поскольку нужно копировать данные, ставить новые диски с большим объемом, создавать новый рейд и восстанавливать данные из бекапа.
Довольно часто, у компаний нету столько свободного места для проведения всех этих манипуляций, не говоря уже о том, что нету столько времени, чтобы полностью останавливать работу и проделывать все эти операции. К счастью у HP есть способ как это сделать не останавливая работу предприятия на длительное время и без промежуточного хранилища данных.
Как это сделать?
Увеличивать объем логических дисков будем на примере сервера HP DL360e G8, контроллера HP Smart Array P420, операционной системы Windows Server 2012 R2, встроенного приложения Smart Storage Administrator (далее SSA) и двумя жесткими дисками объемом 300GB подключенными в RAID1. Будем производить замену на 2 диска объемом 600GB чтобы удвоить рабочее пространство в рейде.
Изначально размер нашего системного диска составляет 300GB.
Выключаем сервер. Меняем один жесткий диск с 300GB на 600GB и включаем сервер. Во время загрузки контроллера нажимаем “F1” чтобы начался процесс ребилдинга РЕЙДа. Ребилдинг - это копирование резервной информации с рабочего диска на новый диск. Операция сильно нагружает рабочий диск, поэтому лучше запланировать этот процесс на нерабочее время. При сильной необходимости, работать можно, но лучше перестраховаться.
Ждем когда восстановится первый диск. Это можно увидеть по индикации дисков в сервере, в ILO и приложении SSA.
Индикация на диске
На винчестере который мы поставили, по центру круга индикации должен за мигать значок жесткого диска зеленым цветом. Когда он перестанет мигать, и начнет светится зеленым цветом, ребилдинг закончится.
В ILO этот процесс можно увидеть в пункте “System information” раздел “Storage”
С помощью SSA можно увидеть в процентах сколько осталось до конца восстановления
Когда логический диск восстановится статус поменяется на “OK”
Теперь опять отключаем сервер и меняем уже второй диск на 600GB. Так же как и с первым диском ожидаем его восстановление.
После ребилдинга, заходим в SSA, выбираем рейд который хотим расширить и нажимаем “Extend Logical Drive”
Выбираем “Maximum Size”
Логический диск трансформирован. Выходим из SSA, запускаем операционную систему и переходим в “Disk management”
Нажимаем правой клавишей мыши на локальный диск С: и выбираем “Extend Volume”
>>
Когда происходит выход из строя (полный или частичный) одного из дисков группы типа RAID-5, то RAID-группа переходит в состояние degraded, но наши данные остаются доступными, так как недостающая часть их может быть восстановлена за счет избыточной информации того самого «дополнительного объема, размером в один диск». Правда обычно быстродействие дисковой группы резко падает, так как при чтении и записи выполняются дополнительные операции вычислений избыточности и восстановления целостности данных. Если мы вставим вместо вышедшего из строя новый диск, то умный RAID-контроллер начнет процедуру rebuild, «перестроения», для чего начнет считывать со всех дисков оставшиеся данные, и, на основании избыточной информации, заполнит новый, ранее пустой диск недостающей, пропавшей вместе со сдохшим диском частью.
Если вы еще не сталкивались с процессом ребилда RAID-5, вы, возможно, будете неприятно поражены тем, насколько длительным этот процесс может быть. Длительность эта зависит от многих факторов, и, кроме количества дисков в RAID-группе, и их заполненностью, что очевидно, в значительной степени зависит от мощности процессора RAID-контроллера и производительности диска на чтение/запись. А также от рабочей нагрузки на дисковый массив во время проведения ребилда, и от приоритета процесса ребилда по сравнению с приоритетом рабочей нагрузки.
Если вам не посчастливилось потерять диск в разгар рабочего дня или рабочей недели, то процесс ребилда, и так небыстрый, может удлинниться в десятки раз.
А с выходом все более и более емких дисков, уровни быстродействия которых, как мы помним, почти не растут, в сравнении с емкостью, время ребилда растет угрожающими темпами, ведь, как уже писалось выше, скорость считывания с дисков, от которой напрямую зависит скорость прохождения ребилда, растет гораздо медленнее, чем емкость дисков и объем, который нужно считать.
Так, в интернете легко можно найти истории, когда сравнительно небольшой 4-6 дисковый RAID-5 из 500GB дисков восстанавливал данные на новый диск в течении суток, и более.
С использованием же терабайтных и двухтерабайтных дисков приведенные цифры можно смело умножать в 2-4 раза!
И вот тут начинаются страсти.
Дело в том, и это надо себе трезво уяснить, что на время ребилда RAID-5 вы остаетесь не просто с RAID лишенным отказоустойчивости. Вы получаете на все время ребилда RAID-0
RAID-5 в состоянии "degraded" эквивалентна отсутствию RAID вообще.
Поэтому лучшей стратегий будет забрать оттуда остатки информации, т.е. сделать бэкап.
Это будет медленно, но это ещё возможно.
Ребилд массива повысит вероятность выхода из строя оставшихся дисков и тогда вы не сможете сделать бэкап даже медленно.
Продолжим цитирование
>>
Так, например, для 6-дискового RAID-5 с дисками 1TB величина отказа по причине BER оценивается в 4-5%, а для 4TB дисков она же будет достигать уже 16-20%.
Эта холодная цифра означает, что с 16-20-процентной вероятностью вы получите отказ диска во время ребилда (и, следовательно, потеряете все данные на RAID). Ведь для ребилда, как правило, RAID-контроллеру придется прочитать все диски, входящие в RAID-группу, для 6 дисков по 1TB объем прочитанного RAID-контроллером потока данных с дисков достигает 6TB, для 4TB он уже станет равным 24TB.
24TB это, при BER 10^15, четверть от 110TB.
Но даже и это еще не все.
Как показывает практика, примерно 70-80% данных, хранимых на дисках, это так называемые cold data. Это файлы, доступ к которым сравнительно редок. С увеличением емкости дисков их объем в абсолютном исчислении также растет. Огромный объем данных лежит, зачастую, нетронутый никем, даже антивирусом (зачем ему проверять гигабайтные рипы и mp3?), месяцами, а возможно и годами.
Ошибка данных, пришедшаяся на массив cold data обнаружится только лишь в процессе полного чтения содержимого диска, на процесс ребилда.
>>
Итак, ребилд массива с вероятностью 20% приведёт к ошибке и развалу всего RAID.
Из-за чтения дурацких "cold data" вы с вероятностью 20% потеряете ценнейшие "hot data".
3. Повышенная нагрузка на диски в период восстановления потенциально еще повышает вероятность сбоя. (14) При попытке сделать бэкап произойдет ровно то же самое.
Чем раньше будет выявлена ошибка или нестабильность в данных, тем лучше. Конечно, лучше при бэкапе, чем при ребилде.
С другой стороны, если бэкап грамотный, он холодные данные не будет читать, только изменившиеся.
Поэтому для особо важных данных еще отдельно scrubbing делают.
А вообще, BER - это чисто маркетологический параметр. Делают одинаковые диски, в них заливают немного разные прошивки - и вуаля: у одного диска BER 10e14, а у другого - 10e16. В реальности вероятность ошибки гораздо ниже, при этом совсем не факт что она вообще будет обнаружена. НЯП, изначально эта цифра рассчитывалась как вероятность ошибке при "безошибочном" чтении. Т.е. вероятность того, что ошибка будет пропущена, и считанные данные будут неверными. Т.е. это вероятность искажения данных, а не read error.
Вероятность отказа дисков при ребилде вычисляется исходя из MTBF. Т.е., например, если 6-дисковый массив ребилдится сутки - наработка составит 6*24 часа, что, например, при 1,2 млн. часов MTBF дает вероятность 0,012%. Если бы это было не так - в датацентрах требовалась бы куча админов для жонглирования дисками.
Читайте также: