Замена 2 дисков (raid 1) на большую пару под контроллером 3ware в linux

У меня 3ware 9650se с 2x 2 ТБ дисками в топологии raid-1.

Я недавно заменил диски на 2 больших (3 ТБ), один за другим. Вся миграция прошла гладко. Проблема, с которой я столкнулся сейчас, заключается в том, что я не знаю, что еще мне нужно сделать, чтобы система знала об увеличении размера этого диска.

Некоторая информация:

root@samothraki:~# tw_cli /c0 show all

/c0 Model = 9650SE-4LPML
/c0 Firmware Version = FE9X 4.10.00.024
/c0 Driver Version = 2.26.02.014
/c0 Bios Version = BE9X 4.08.00.004
/c0 Boot Loader Version = BL9X 3.08.00.001

....

Unit  UnitType  Status         %RCmpl  %V/I/M  Stripe  Size(GB)  Cache  AVrfy
------------------------------------------------------------------------------
u0    RAID-1    OK             -       -       -       139.688   Ri     ON     
u1    RAID-1    OK             -       -       -       **1862.63**   Ri     ON     

VPort Status         Unit Size      Type  Phy Encl-Slot    Model
------------------------------------------------------------------------------
p0    OK             u0   139.73 GB SATA  0   -            WDC WD1500HLFS-01G6 
p1    OK             u0   139.73 GB SATA  1   -            WDC WD1500HLFS-01G6 
p2    OK             u1   **2.73 TB**   SATA  2   -            WDC WD30EFRX-68EUZN0
p3    OK             u1   **2.73 TB**   SATA  3   -            WDC WD30EFRX-68EUZN0

Обратите внимание, что диски p2 & p3 правильно определены как 3TB, но массив raid1 u1 все еще видит массив 2TB.

После следования руководству по кодовому набору LSI 3ware 9650se 10.2 (примечание: руководство пользователя по кодовому набору 9.5.3 содержит точно такую ​​же процедуру).

Я тройной sync мои данные и umount рейдовый массив u1, Затем я удаляю массив raid из командной строки, используя команду:

tw_cli /c0/u1 remove

и, наконец, я повторно сканирую контроллер, чтобы снова найти массив:

tw_cli /c0 rescan

к сожалению новый u1 Массив все еще идентифицировал диск 2TB.

Что может быть не так?

Некоторая дополнительная информация. u1 массив соответствует dev/sdb/ что, в свою очередь, соответствует физическому объему большего диска LVM. Теперь, когда я заменил оба диска, кажется, что таблица разделов пуста. И все же диск LVM работает нормально. Это нормально?!

root@samothraki:~# fdisk -l /dev/sdb 

Disk /dev/sdb: 2000.0 GB, 1999988850688 bytes
255 heads, 63 sectors/track, 243151 cylinders, total 3906228224 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

root@samothraki:~# 

5 ответов

Решение

Хорошо , этот ответ добавляет к grs's ответ. поэтому кредиты идут туда на 70% ответа.

Заметки:

  • если этот ответ вас устраивает, ПОЛУЧИТЕ резервную копию СЕЙЧАС.
  • если у вас есть ИБП, подключите его к ПК, о котором идет речь, СЕЙЧАС.
  • Следующая процедура была выполнена в linux, на дисковых массивах DATA. Может потребоваться некоторые модификации для работы с OS/ загрузочными массивами.
  • Следующая процедура требует нескольких перезапусков, о которых я не сообщаю, поскольку мне удалось завершить процедуру в течение нескольких недель, когда я пытался и терпел неудачу в ряде случаев. Хорошая вещь, хотя, когда компьютер был включен, у меня больше не было простоев и я не терял данные (т.е. мне не нужно было полагаться на свои резервные копии).

Подведение итогов ситуации:

  • не может перейти с raid1 на raid1 в системе 3ware 9650se.
  • не может разбить диски и ожидать, что /c0/uX автоматически обновит размер своего массива.
  • Вы должны удалить модуль и воссоздать его, чтобы он обнаружил диски большего размера.

Таким образом, ключ заключается в том, чтобы удалять один диск за раз и каждый раз заново создавать новый массив. В общем и целом:

  1. разделить массив raid1. Это сгенерирует 2 массива со старым размером дисков (2 ТБ в моем случае).

    tw_cli /c0/u1 migrate type=single
    

    драгоценный /dev/sdX который указывал на raid1 /u1, должен еще существовать (и работать!). и вы также получите новый блок /u2 который основан на 2-м диске зеркала.

  2. удалить диск зеркала, которое больше не используется (он принадлежит новому устройству /u2 в моем случае и должен был приобрести новый /dev/sdX дескриптор файла после перезапуска).

    tw_cli /c0/u2 del
    
  3. создать новый single блок с неиспользованным диском. ПРИМЕЧАНИЕ: я сделал этот шаг из BIOS, поэтому я не уверен, что именно так это и должно быть, как я утверждаю ниже. В BIOS я сделал "создать модуль", а не "мигрировать". Кто-то, пожалуйста, подтвердите это.

    tw_cli /c0/u2 migrate type=single disk=3
    

    новый /u2 блок должен "увидеть" все 3ТБ.

  4. иди вперед и перенеси данные с диска 2 ТБ на диск 3 ТБ.

  5. как только данные поступят на новый модуль, обновите все ссылки на новый / dev / sdX.

  6. оставшийся диск объемом 2 ТБ (должен быть!) теперь не используется, поэтому удалите его.

    tw_cli /c0/u1 del
    
  7. создать новый single блок с неиспользованным диском.

    tw_cli /c0/u1 migrate type=single disk=2
    

    новый /u1 Теперь у устройства должно быть 3TB места.

  8. наконец, сделайте глубокий вдох и объедините 2 отдельных диска в новый расширенный raid1

    tw_cli /c0/u2 migrate type=raid1 disk=2
    

    /u1 теперь должен исчезнуть и единица /u2 должен начать восстановление.

  9. Наслаждайся жизнью. Мол, серьезно.

Вам нужно будет обновить u1 размер до увеличения файловой системы изнутри ОС. Последний не будет "видеть" новый размер, пока контроллер 3ware не уведомит об этом.

Расширение емкости устройства в 3ware называется миграцией. Я уверен, что это работает для RAID5 и 6, не пробовал это с RAID1. Вот пример команды миграции для запуска:

# tw_cli /c0/u1 migrate type=raid1 disk=p2-p3

Когда это завершится fdisk -l /dev/sdb должен дать 3TB и vgdisplay <VG name> перечислит некоторое пустое место. Оттуда вы увеличиваете размер VG, затем соответствующий LV и, наконец, файловую систему в LV.

Изменить: я думаю, что вам не повезло - см. Стр. 129 в руководстве пользователя.
Вы можете перенести ваш RAID1 в другой тип массива.

Вот альтернативный вариант (он несет некоторый риск, поэтому убедитесь, что резервные копии хорошие):

  1. tw_cli /c0/u1 migrate type=single - это разобьёт твой u1 объединить в два отдельных диска;
  2. tw_cli /c0/u1 migrate type=raid1 disk=2-3 - это должно перенести ваш отдельный блок обратно на RAID1 с правильным размером

Конечно, есть альтернативные подходы к этому, тот, который я перечислил выше, на случай, если вы хотите, чтобы ваши данные постоянно находились в сети.

Возможно, ваше ядро ​​не получало обновления от контроллера.

Попробуйте обновить информацию о дисках, набрав:

partprobe /dev/sdb

Это заставит ядро ​​перечитать таблицы разделов и свойства дисков.

Также попробуйте:

hdparm -z /dev/sdb

и / или:

sfdisk -R /dev/sdb

причина partprobe не всегда работает...

Суть этого поста - обратиться в службу поддержки LSI, чтобы получить сценарий миграции.

Я почти уверен, что у меня один и тот же контроллер в конфигурации с 2 и 4 портами, и когда я захотел обновить с 1 Gig Raid 1 до 2 Gig, я заменил один из дисков на 2 Gig, а затем заменил другой диск после восстановления.

На данный момент у меня все еще был 1 Гиг рейд 1, но я сидел на 2 Гиг дисках. Затем я отправил некоторую спецификацию измерения диска в LSI в качестве запроса на поддержку, и они, в свою очередь, прислали мне (очень технический) скрипт, который при выполнении выполнял миграцию для меня.

Я никогда не был удовлетворен, почему эта миграция не может быть осуществлена ​​без поддержки LSI, но в итоге все прошло хорошо.

Это всего лишь некоторые заметки, добавляющие nass's ответ. Если исходить из памяти, то это может быть не совсем правильно, и на этих шагах была сделана некоторая перезагрузка.

  • Шаги 1-2:

  • Шаг 3: Добавление нового single блок из кли: tw_cli /c0 add type=single disk=3

  • Шаг 4: я использовал dd if=/dev/sdX of=/dev/sdY bs=64K клонировать диск. Чтобы определить, какие устройства были правильными, перед Шагом 3 я попытался смонтировать некоторые устройства (например, sudo mount -t ntfs /dev/sda1 /mnt/a) и исследовать содержимое, чтобы увидеть, какое устройство было источником /c0/u1, (Возможно, есть лучший способ определить это.)

    Также до шага 3 я ls /dev/sd*отметил, какое устройство имело существующее sdY1 но нет sdY, а затем после шага 3 снова проверил, для чего sdY был создан. Я также использовал sudo hdparm -I /dev/sdY на каждом устройстве до / после шага 3, чтобы подтвердить, что все выглядело правильно. ПРИМЕЧАНИЕ. Перезагрузка может изменить какое устройство, поэтому не делайте этого между проверкой и dd"Инж.

  • Шаги 5-6:

  • Шаги 7-8: Создание нового отдельного устройства из неиспользуемого диска и последующая миграция не работали для меня (Invalid disk ошибка или что-то в этом роде). Вместо этого следует пропустить шаг 7 и перейти прямо к шагу 8.

  • Шаг 9: Сделаем. Спасибо за помощь!

Некоторые другие заметки из моего опыта с этим:

  • Я использовал Knoppix Live CD, чтобы сделать большую часть этого. Чтобы установить на него tw-cli:
    sudo nano /etc/apt/sources.list
    добавлять deb http://hwraid.le-vert.net/ubuntu precise main на вершине.
    sudo apt-get update
    sudo apt-get install tw-cli 3dm2

  • Я делал это на загрузочном диске установки Windows, переходя от дисков 2 ТБ к дискам 4 ТБ. Перед запуском я забыл проверить, был ли диск MBR или GPT. Оказывается, это была MBR, что означает, что я не могу получить доступ к большей части дополнительного пространства на диске без преобразования в GPT.

Другие вопросы по тегам