Linux rad: How to configure RAID in Linux

настраиваем lvm, raid на linux / Хабр

Небольшое отступление: данная л\р является синтетической.

Некоторые задания которые здесь описаны можно сделать гораздо проще, но поскольку задача л/р — познакомиться с функционалом raid, lvm то некоторые операции искусственно усложнены.

Требования к инструментам для выполнения л\р:

• Средства виртуализации, например Virtualbox
• Установочный образ linux, например Debian9
• Наличие интернета для скачивания нескольких пакетов
• Подключение по ssh к установленной VM (опционально)

ВНИМАНИЕ

Данная лабораторная работа связана с такой тонкой материей как сохранность данных — это такая область, которая позволяет из-за мельчайшей ошибки — одной лишней буквы или цифры потерять все ваши данные.

Поскольку вы выполняете лабораторную работу вам ничего не грозит, разве что придется начать делать ее заново.

В реальной жизни все гораздо серьезнее, поэтому следует очень внимательно вводить имена дисков, понимая что именно вы выполняете текущей командой и с какими дисками работаете.

Второй важный момент — именование дисков и разделов: в зависимости от ситуации номера дисков могут отличаться от тех значений, что представлены в командах в лабораторной работе.

Так, например, если удалить диск sda из массива, а затем добавить новый диск, то новый диск будет отображаться в системе с именем sda. Если же выполнить перезагрузку перед добавлением нового диска, то новый диск будет иметь имя sdb, а старый станет именоваться sda

Лабораторная работа должна выполняться под суперпользователем (root) поскольку большая часть команд требует повышенных привилегий и не имеет смысла постоянно повышать привилегии через sudo.

Материалы для изучения

• RAID
• LVM
• Именование дисков в ОС Linux
• Что такое раздел
• Что такое таблица разделов и где она хранится
• Что такое grub

Используемые утилиты

1. Просмотр информации о дисках:
   • lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT
   • fdisk -l

2. Просмотр информации и работа с LVM
   • pvs
   • pvextend
   • pvcreate
   • pvresize
   • vgs
   • vgreduce
   • lvs
   • lvextend

3. Просмотр информации и работа с RAID:
4. Точки монтирования:
   • mount
   • umount
   • cat /etc/fstab
   • cat /etc/mtab

5. Переразметка диска:
6. Копирование разделов:
   • dd if=/dev/xxx of=/dev/yyy

7. Работа с таблицей разделов:
8. Работа с загрузчиком:
   • grub-install /dev/XXX
   • update-grub

9. misc

Лабораторная работа состоит из 3-х частей:

• Настройка работоспособной системы с использованием lvm, raid.
• Эмуляция отказа одного из дисков.
• Замена дисков на лету, с добавлением новых дисков и переносом разделов.

Задание 1 (Установка ОС и настройка LVM, RAID)

1. Создайте новую виртуальную машину, выдав ей следующие характеристики:

   • 1 gb ram
   • 1 cpu
   • 2 hdd (назвать их ssd1, ssd2 и назначить равный размер, поставить галочки hot swap и ssd)
   • SATA контроллер настроен на 4 порта:

2. Начать установку Linux и дойдя до выбора жестких дисков сделать следующее:

   • Partitioning method: manual, после чего вы должны увидеть такую картину:

   • Настройка отдельного раздела под /boot: Выберите первый диск и создайте на нем новую таблицу разделов:
     • Partition size: 512M
     • Mount point: /boot

   • Повторите настройку для второго диска, но поскольку одновременно монтировать 2 раза /boot нельзя, то выберите mount point: none в итоге получив следующее (картинка с косяком, переделывать лень):

   • Настройка RAID:
   • Выберите свободное место на первом диске и настройте в качестве типа раздела physical volume for RAID
   • Выберите «Done setting up the partition»
   • Повторите точно такую же настройку для второго диска, в результате получив следующее:

   • Выберите пункт «Configure software RAID»
     • Create MD device
     • Software RAID device type: Выберите зеркальный массив
     • Active devices for the RAID XXXX array: Выбрать оба диска
     • Spare devices: Оставить 0 по умолчанию
     • Active devices for the RAID XX array: выбрать разделы, которые вы создавали под raid
     • Finish

   • В итоге вы должны получить такую картину:

   • Настройка LVM: Выберите Configure the Logical Volume Manager
   • Keep current partition layout and configure LVM: Yes
   • Create volume group
   • Volume group name: system
   • Devices for the new volume group: Выберите ваш созданный RAID
   • Create logical volume
     • logical volume name: root
     • logical volume size: 2\5 от размера вашего диска

   • Create logical volume
     • logical volume name: var
     • logical volume size: 2\5 от размера вашего диска

   • Create logical volume
     • logical volume name: log
     • logical volume size: 1\5 от размера вашего диска

   • Выбрав Display configuration details вы должны получить следующую картину:

   • Завершив настройку LVM вы должны увидеть следующее:

   • Разметка разделов: по-очереди выберите каждый созданный в LVM том и разметьте их, например, для root так:
     • Use as: ext4
     • mount point: /

   • Результат разметки корневого раздела должен получиться таким:

   • Повторите операцию разметки для var и log выбрав соответствующие точки монтирования (/var и /var/log вручную ввести), получив следующий результат:

   • Выберите Finish Partitioning
   • Вам зададут несколько вопросов, про то что у вас остался несмонтированный раздел и не настроен swap. Следует ответить отрицательно на оба вопроса.
   • Финальный результат должен получиться вот таким:

3. Закончить установку ОС, поставив grub на первое устройство (sda) и загрузить систему.

4. Выполните копирование содержимого раздела /boot с диска sda (ssd1) на диск sdb (ssd2)

   dd if=/dev/sda1 of=/dev/sdb1

5. Выполнить установку grub на второе устройство:

   • Посмотреть диски в системе:

     fdisk -l
     lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT

   • Перечислите все диски которые вам выдала предыдущая команда и опишите что это за диск.

   • Найдите диск на который не была выполнена установка grub и выполните эту установку:

     grub-install /dev/sdb

   • Просмотрите информацию о текущем raid командой cat /proc/mdstat и запишите что вы увидели.
   • Посмотрите выводы команд: pvs, vgs, lvs, mount и запишите что именно вы увидели.

Опишите своими словами что вы сделали и какой результат получили в итоге проделанного задания.

После выполнения этого задания рекомендуется сохранить резервную копию папки с виртуальной машиной или сделать vagrant box.

Результат: Виртуальная машина с дисками ssd1, ssd2.

Задание 2 (Эмуляция отказа одного из дисков)

1. Если вы поставили галочку hot swap, то вам доступно удаление дисков на лету:
   • Выполните удаление диска ssd1 в свойствах машины.
   • Найдите директорию, где хранятся файлы вашей виртуальной машины и удалите ssd1.vmdk.

2. Убедитесь что ваша виртуальная машина по-прежнему работает
3. Выполните перезагрузку виртуальной машины и убедитесь что она по-прежнему работает
4. Проверьте статус RAID-массива: cat /proc/mdstat
5. Добавьте в интерфейсе VM новый диск такого же размера и назовите его ssd3.
6. Выполните операции:
   • Посмотрите что новый диск приехал в систему командой fdisk -l
   • Скопируйте таблицу разделов со старого диска на новый: sfdisk -d /dev/XXXX | sfdisk /dev/YYY
   • Посмотрите результат командой fdisk -l
   • Добавьте в рейд массив новый диск: mdadm --manage /dev/md0 --add /dev/YYY
   • Посмотрите результат: cat /proc/mdstat. Вы должны увидеть что началась синхронизация

7. Теперь нужно вручную выполните синхронизацию разделов, не входящих в RAID. Для этого воспользуемся утилитой dd, скопировав с «живого» диска на новенький, который вы недавно поставили:

   dd if=/dev/XXX of=/dev/YYY

8. После завершения синхронизации установите grub на новый диск.
9. Выполните перезагрузку ВМ, для того чтобы убедиться что все работает.

Опишите своими словами что вы сделали и какой результат получили в итоге проделанного задания.

Результат: удалён диск ssd1, сохранен диск ssd2, добавлен диск ssd3.

Задание 3 (Добавление новых дисков и перенос раздела)

Это самое сложное и объемное задание из всех представленных. Очень внимательно проверяйте что вы делаете и с какими дисками и разделами. Рекомендуется снять копию перед его выполнением. Это задание независимо от задания №2, его можно выполнять после задания №1 с поправкой на имена дисков.

Вторая часть задания этой лабораторной должна привести в точно такое же состояние которое было после выполнения первой части.

Для того чтобы вам было проще работать могу рекомендовать не удалять физически диски с хостовой машины, а только лишь отсоединять их в свойствах машины. С точки зрения ОС в ВМ это будет выглядеть абсолютно одинаково, но вы сможете в случае чего подключить диск обратно и продолжить выполнение работы откатившись на пару пунктов назад, в случае если у вас возникли проблемы. Например вы могли выполнить неверно или забыть скопировать на новый диск раздел /boot. Я могу лишь посоветовать несколько раз перепроверять с какими дисками и разделами вы работаете, а еще лучше выписать на листочек соответствие дисков, разделов и «физическому» номеру диска. Красивое и понятное дерево рисует команда lsblk, пользуйтесь ей как можно чаще для анализа того что вы сделали и что нужно сделать.

К истории…

Представьте себе что ваш сервер работал долгое время на 2-х ssd дисках, как вдруг…

1. Проэмулируйте отказ диска ssd2, удалив из свойств ВМ диск и перезагрузившись.

2. Посмотрите текущее состояние дисков и RAID:

   cat /proc/mdstat
   fdisk -l
   lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT

3. Вам повезло — начальство разрешило закупить несколько новых дисков:

   2 SATA большого объема для давно назревшей задачи вынесения раздела с логами на отдельный диск. 2 SSD на замену погибшему, а также на замену пока еще функционирующему.

   Следует учитывать, что корзина сервера поддерживает установку только 4х дисков. одновременно, поэтому добавить все диски сразу нельзя.

   Объем HDD выбрать в 2 раза больше чем SSD.
   
   Объем SSD выбрать в 1,25 раза больше бывших SSD.

4. Добавьте один новый ssd диск, назвав его ssd4, а после добавления проверьте что произошло:

   fdisk -l
   lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT

5. В первую очередь следует озаботиться сохранностью данных старого диска. На этот раз мы будем переносить данные с помощью LVM:

   • В первую очередь необходимо скопировать файловую таблицу со старого диска на новый:

     sfdisk -d /dev/XXX | sfdisk /dev/YYY

     Подставьте вместо x,y правильные диски и разберите что делает данная команда.

   • Выполните команду lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT и сравните ее вывод с прошлым вызовом. Что поменялось?

   • С помощью команды dd скопируйте данные /boot на новый диск:

     dd if=/dev/XXX of=/dev/YYY

   • Если /boot остался смонтирован на старом диске, его следует перемонтировать на живой диск:

     mount | grep boot # смотрим куда смонтирован диск
     lsblk # смотрим какие диски есть в системе и смотрим есть ли диск, полученный из предыдущего пункта
     umount /boot # отмонтируем /boot
     mount -a # выполним монтирование всех точек согласно /etc/fstab. 
     # Поскольку там указана точка монтирования /dev/sda, то будет выполнено корректное перемонтирование на живой диск

   • Установите загрузчик на новый ssd диск:

     grub-install /dev/YYY

     Зачем мы выполняем эту операцию?

   • Создайте новый рейд-массив с включением туда только одного нового ssd диска:

     mdadm --create --verbose /dev/md63 --level=1 --raid-devices=1 /dev/YYY

     Команда приведенная выше не отработает без указания специального ключа.Прочитайте справку и добавьте этот ключ к команде.

   • С помощью команды cat /proc/mdstat проверьте результат вашей операции. Что поменялось?
   • Выполните команду lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT и сравните ее вывод с прошлым вызовом. Что поменялось?

6. Следующим этапом необходимо настроить LVM

   • Выполните команду pvs для просмотра информации о текущих физических томах.

   • Создайте новый физический том включив в него ранее созданный RAID массив:

     pvcreate /dev/md63

   • Выполните команду lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT и сравните ее вывод с прошлым вызовом. Что поменялось?
   • Снова выполните команду pvs. Что поменялось?

   • Увеличим размер Volume Group system с помощью такой команды:

     vgextend system /dev/md63

   • Выполните команды и запишите что вы увидели и что поменялось.

     vgdisplay system -v
     pvs
     vgs
     lvs -a -o+devices

     На каком физическом диске сейчас находятся LV var, log, root?

   • Выполните перемещение данных со старого диска на новый, подставив правильные имена устройств.

     pvmove -i 10 -n /dev/system/root /dev/md0 /dev/md63 

     Повторите операцию для всех logical volume.

   • Выполните команды и запишите что вы увидели и что поменялось.

     vgdisplay system -v
     pvs
     vgs
     lvs -a -o+devices
     lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT

   • Изменим наш VG, удалив из него диск старого raid. Подставьте правильное имя raid.

     vgreduce system /dev/md0

   • Выполните команды и запишите что вы увидели и что поменялось.

     lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT
     pvs
     vgs

   • Для красоты картины перемонтируйте /boot на второй ssd диск (ssd4) и выполните lsblk. В итоге на диске ssd3 не должно быть ничего смонтировано. Внимательно проверьте что раздел /boot не пустой! ls /boot должен показать несколько файлов и папок. Изучите что хранится в этом разделе и запишите какой файл\каталог за что отвечает.

7. Удалите ssd3 диск и добавьте ssd5, hdd1, hdd2 согласно вышеописанным ТЗ, в итоге получив:

   • ssd4 — первый новый ssd
   • ssd5 — второй новый ssd
   • hdd1 — первый новый hdd
   • hdd2 — второй новый hdd

8. Проверьте что произошло после добавления дисков:

   fdisk -l
   lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT

9. Восстановим работу основного raid массива:

   • Выполните копирование таблицы разделов, подставив правильные диски:

     sfdisk -d /dev/XXX | sfdisk /dev/YYY

   • Обратите внимание, что когда мы скопировали таблицу разделов со старого диска лказалось что новый размер не использует весь объем жесткого диска. Поэтому в скором времени нам потребуется изменить размер этого раздела и расширить raid. Убедитесь в этом сами, введя команду:

     lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT

10. Скопируйте загрузочный раздел /boot с диска ssd4 на ssd5:

    dd if=/dev/XXX of=/dev/YYY

11. Установите grub на новый диск (ssd5).

12. Изменим размер второго раздела диска ssd5.

13. Перечитаем таблицу разделов и проверим результат:

    partx -u /dev/XXX
    lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT

    • Добавим новый диск к текущему raid массиву (не забудьте подставить правильные диски):

      mdadm --manage /dev/md63 --add /dev/sda2

    • Расширим количество дисков в нашем массиве до 2-х штук:

      mdadm --grow /dev/md63 --raid-devices=2

    • Посмотрите результат: у нас размечено 2 массива, но оба раздела входящие в этот массив имеют разные размеры:

      lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT

14. Увеличим размер раздела на диске ssd4

15. Перечитаем таблицу разделов и проверим результат.

    partx -u /dev/XXX
    lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT

    Обратите внимание, теперь sda2, sdc2 разделы имеют размер > чем размер raid-устройства.

16. На этом этапе размер raid можно теперь расширить:

    mdadm --grow /dev/md63 --size=max
    lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT # check result

    Просмотрите lsblk и запишите что изменилось.

17. Однако, хоть мы и изменили размер raid, сами размеры vg root,var,log не изменились

    • Посмотрите чему равен размер PV:

      pvs

    • Расширим размер нашего PV:

      pvresize /dev/md63

    • Посмотрите чему равен размер PV:

      pvs

18. Добавим вновь появившееся место VG var, root:

    lvs # посмотрим сколько сейчас размечено
    lvextend -l +50%FREE /dev/system/root
    lvextend -l +100%FREE /dev/system/var
    lvs # проверьте что получилось

    На этом этапе вы завершили миграцию основного массива на новые диски. работа с ssd1,ssd2 закончена.

19. Наша следующая задача — переместить /var/log на новые диски, для этого создадим новый массив и lvm на hdd дисках.

    • Посмотрим какие имена имеют новые hdd диски:

      fdisk -l

    • Создадим raid массив:

      mdadm --create /dev/md127 --level=1 --raid-devices=2 /dev/sdc /dev/sdd

    • Создадим новый PV на рейде из больших дисков:

      pvcreate data /dev/md127

    • Создадим в этом PV группу с названием data:

      vgcreate data /dev/md127

    • Создадим логический том размером всего свободного пространства и назовем его val_log:

      lvcreate -l 100%FREE -n var_log data # lvs # посмотрим результат

    • Отформатируем созданные раздел в ext4:

      mkfs.ext4 /dev/mapper/data-var_log

    • Посмотрим результат:

      lsblk

20. Перенесем данные логов со старого раздела на новый

    • Примонтируем временно новое хранилище логов:

      mount /dev/mapper/data-var_log /mnt

    • Выполним синхронизацию разделов:

      apt install rsync
      rsync -avzr /var/log/ /mnt/

    • Выясним какие процессы работают сейчас с /var/log:

      apt install lsof
      lsof | grep '/var/log'

    • Останавливаем эти процессы:

      systemctl stop rsyslog.service syslog.socket

    • Выполним финальную синхронизацию разделов (тех данных что могли измениться с момента последней синхронизации):

      rsync -avzr /var/log/ /mnt/

    • Поменяем местами разделы:

      umount /mnt
      umount /var/log
      mount /dev/mapper/data-var_log /var/log

    • Проверяем что получилось:

      lsblk

21. Правим /etc/fstab

    fstab — файл, в котором записываются правила, по которым при загрузке будут смонтированы разделы. Наша задача — найти ту строку, в которой монтируется /var/log и поправить устройство system-log на data-var_log.

22. Самое важно на этом этапе — не забыть изменить таблицу раделов (ext4, например). Поскольку как бы мы не изменяли всякие raid, lvm — пока ФС на разделе не будет уведомлена о том что теперь размер раздела изменился, мы не сможем использовать новое пространство. Используйте команду resize2fs для изменения ФС.

23. Финальный аккорд

    • Выполним перезагрузку. Если вы все сделали правильно — вы снова попадете в вашу ОС (это нужно для того чтобы убедиться что все работает. Никакого смысла кроме самопроверки этот шаг не несет)

    • Выполните проверки, что все что мы хотели сделать действительно было сделано:

      pvs
      lvs
      vgs
      lsblk
      cat /proc/mdstat

24. [ОПЦИОНАЛЬНО] Выполните действия

    • Перезагрузитесь нажимая F12, чтобы указать при загрузке разные диски, для того чтобы убедиться что вы можете загрузиться с любого из ssd дисков, так чтобы мы не боялись отказа одного из них.

    • Теперь у вас есть ненужный LV log в VG system. Распределите это пространство между root или var, но вместо использования конструкции 100%FREE укажите размер руками с помощью ключа -L:

      -L 500M  

    • Исправьте проблему с тем что /boot находится на двух разделах без синхронизации, по-правильному так делать не нужно, здесь это добавлено для примера. Не забудьте предварительно куда-то скопировать содержимое /boot.
    • Создайте новый рейд и включите в него sda1, sda2.
    • Включите эти разделы в существующий raid и восстановите /boot в основном raid, но уже не монтируя его.

Программный RAID под Linux

Введение

Это руководство посвящено установке, настройке и администрированию mdadm программного RAID в системах Linux.
Предпосылками

• Установленная ОС Linux
• Выделенный сервер с несколькими дисками
• Корневой доступ

Шаг 1 — Подготовка

Сначала вы должны подумать о том, какую систему RAID вы хотите запустить. Это зависит от цели и количества дисков, установленных на самом сервере.

Примечание. RAID не следует рассматривать как резервную копию данных, поскольку он не обеспечивает защиту от потери данных. Это только увеличивает доступность данных.

Шаг 1.1 — Выбор уровня RAID

Выбор правильного уровня RAID не прост и зависит от нескольких факторов:

• Сколько дисков у сервера?
• Каковы твои цели?
  • Больше места для хранения / меньше доступности
  • Более высокая доступность / Меньше места для хранения

Вот список наиболее часто используемых уровней RAID:
RAID0 :
Если существует группа из двух или более разделов, разделы логически объединяются в один раздел. Здесь доступность уменьшается. Если один из дисков неисправен автоматически, все данные будут потеряны .

• профессионал
  • Объединяет доступное пространство для хранения.
  • Увеличивает производительность диска.
• против
  • В случае сбоя диска данные всех дисков будут потеряны.

RAID1 :
Если существует группа из двух или более разделов, данные зеркально отображаются в каждом разделе.

• профессионал
  • Увеличивает надежность / доступность данных.
  • Увеличивает скорость чтения данных.
• против
  • Доступное пространство для хранения уменьшено вдвое.

RAID5 :
Группа из трех или более разделов, в которой данные отражаются в двух из трех разделов. Так называемые «четности» хранятся на третьем разделе, с помощью которого можно восстанавливать данные на неисправных дисках в RAID.
Узнайте больше о RAID5

• профессионал
  • Повышенная надежность / доступность данных.
  • Оптимальное использование хранилища
  • Увеличивает скорость чтения данных.
• против
  • Меньшая производительность при доступе к записи

Список дополнительных уровней RAID, которые используются реже:

• Линейный: объединить несколько разделов
• Multipath: нет RAID, но сопоставление файла двум разным путям в одном разделе (зеркалирование).
• Faulty: эмулирует неисправную систему RAID для тестовых случаев
• Уровень 4: как и уровень 0, но с дополнительным устройством для битов четности (повышенная надежность).
• Уровень 6: как и уровень 5, но с двумя независимыми битами четности на сегмент (повышенная надежность).

Шаг 1.2 — Список дисков в системе

Для краткого и понятного списка всех доступных блочных устройств lsblkможно использовать команду . Вот пример вывода:

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 232.9G 0 disk 
├─sda1 8:1 0 10G 0 part /
├─sda2 8:2 0 208.1G 0 part /home/han/data
<font color=#38B0DE>-=─sda3=- Proudly Presents 
sr0 11:0 1 1024M 0 Rome

Для списка с более подробной информацией, fdisk -lмогут быть использованы. Вот пример вывода:

Disk /dev/sda: 80.0 GByte, 80026361856 Byte
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinder of 16065 × 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x92669266

   Device boot.     Start End Blocks Id System
/dev/sda1 * 1 1305 10482381 83 Linux
/dev/sda2 1306 3977 21462840 83 Linux
/dev/sda3 4508 9729 41945715 83 Linux
/dev/sda4 3978 4507 4257225 82 Linux Swap / Solaris

Примечание . Для программного RAID-массива необязательно добавлять весь диск в RAID-массив. Отдельных разделов достаточно.

Шаг 2 — Создание программного RAID

Шаг 2.1 — Подготовка дисков

Сначала диски должны быть отформатированы соответственно.
Создайте новую пустую таблицу разделов на диске:

• Для больших 2 ТБ накопителей или ПК с UEFI:

  sudo parted /dev/sda mklabel gpt 

• Для дисков меньше 2 ТБ и BIOS:

  sudo parted /dev/sda mklabel msdos

Создайте раздел на диске:

sudo parted -a optimal -- /dev/sda mkpart primary 2048s -8192s 

Если вы хотите использовать весь диск, просто введите «0% 100%» вместо «2048 с-8192 с».

Подсказка : 8192 сектора в конце диска намеренно оставлены неиспользованными для подготовки к сбоям. Это позволяет вам использовать диски с несколькими секторами в качестве замены из-за свободного места.

Отметьте вновь созданный раздел как раздел RAID:

sudo parted /dev/sda set 1 raid on

Шаг 2.2 — Создание программного RAID

Под Linux mdadmэто основной инструмент. Это интерфейс к функциям RAID ядра.
Для создания RAID 1 достаточно следующей команды:

sudo mdadm --create /dev/md0 --auto md --level=1 --raid-devices=2 /dev/sda1 /dev/sdb2

Для создания RAID 5 достаточно следующей команды:

sudo mdadm --create /dev/md0 --auto md --level=5 --raid-devices=4 /dev/sda1 /dev/sdb2 /dev/sdc3 /dev/sdd4 

Параметры в деталях:

• --create /dev/md0— Создает новую конечную точку с именем md0. Если конечные точки с таким именем уже существуют, выберите другое свободное имя (md1, md2 и т. Д.).
• --auto md — Создает «классическую» конечную точку без предварительного разбиения.
• --level= — Тип уровня RAID.
• --raid-devices — Количество отдельных устройств, из которых должен состоять RAID.
• /dev/sde1 /dev/sde2 ...— Отдельные устройства для объединения. Порядок идентификаторов или, в идеале, идентификаторов соответствующих физических устройств, должен быть записан, если RAID необходимо собрать вручную в чрезвычайной ситуации.

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

Personalities : [raid0] [raid1]
mdX : active raid1 sda1[1] sdb1[0]
      8384448 blocks super 1.2 [2/2] [UU]
      [==============>.......] check = 74.7% (6267520/8384448) finish=0.1min speed=202178K/sec

Отформатируйте вновь созданный RAID:
Интеграция RAID:

sudo mount /dev/mdX /mnt/md0

Автоматическая интеграция RAID:
Здесь соответствующая строка должна быть введена в файл /etc/fstab:

/dev/mdX /mnt/md0 xt4 defaults 0 2

(Необязательно) Диски Hotspare : Диски / разделы Hotspare — это те, которые обычно не используются. Они используются, если один из активных дисков / разделов системы RAID имеет ошибку или неисправен. Если в программном рейде не определен диск горячего резервирования, восстановление поврежденного RAID-массива необходимо запустить вручную. Если имеется горячий резерв, восстановление будет начато автоматически. Горячий резервный диск можно добавить с помощью следующей команды.

mdadm --add /dev/md/X /dev/sdX1

Шаг 3 — Удаление программного RAID

Чтобы удалить программный RAID, необходимо выполнить следующие шаги:

1. Остановите RAID:

   sudo umount /dev/md0
   sudo mdadm --stop /dev/md0

2. Удалить записи автоматического монтирования (например /etc/fstab)
3. Удалить записи RAID в mdadm.conf.
4. Удалить суперблок используемых разделов:

   sudo mdadm --zero-superblock /dev/sda1 /dev/sdb1 

5. Отключить флаг RAID:

   sudo parted /dev/sda set 1 raid off

Шаг 4 — Управление программным RAID

Шаг 4.1 — Получить статус RAID

Краткий список всех RAID-массивов в системе можно получить с помощью вывода файла /proc/mdstat.

Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid1 sdb1[1] sda1[0]
      8380416 blocks super 1.2 [2/2] [UU]
      
md2 : active raid1 sdb3[1] sda3[0]
      536739840 blocks super 1.2 [2/2] [UU]
      bitmap: 3/4 pages [12KB], 65536KB chunk

md1 : active raid1 sdb2[1] sda2[0]
      1047552 blocks super 1.2 [2/2] [UU]
      
unused devices: <none>

Более точный вывод делается с помощью команды:

sudo mdadm --detail /dev/md/2

Вот пример вывода:

/dev/md/2:
           Version : 1.2
     Creation Time : Fri Feb 22 17:19:37 2019
        Raid Level : raid1
        Array Size : 536739840 (511.88 GiB 549.62 GB)
     Used Dev Size : 536739840 (511.88 GiB 549.62 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Sun May 26 13:49:02 2019
             State : clean 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : rescue:2
              UUID : c76e5446:f3c41fbc:0b62ca86:803a7e88
            Events : 2170

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       1       8       19        1      active sync   /dev/sdb3

Шаг 4.2 — Заменить неисправный диск

Для этого сначала необходимо удалить неисправный диск из RAID:

sudo mdadm --manage /dev/md/0 -r /dev/sda1

Если диск горячего резервирования недоступен, новый диск должен быть разбит на разделы. Важно, чтобы новый диск имел те же разделы, что и неисправный диск!
Для разбиения нового диска достаточно скопировать таблицу разделов с существующего диска.
Для разделенных на MBR дисков:

sfdisk --dump /dev/sda > sda_parttable_mbr.bak # Backs up partition table
sfdisk -d /dev/sda | sfdisk /dev/sdb # Copy partition table from sda to sdb

Для GPT-дисков:

sgdisk --backup=sda_parttable_gpt.bak /dev/sda # Create a backup of the partition table
sgdisk --load-backup=sda_parttable_gpt.bak /dev/sdb # Copy the created backup of the partition table to sdb

Если новый диск правильно разделен, его можно снова добавить в систему RAID:

sudo mdadm --manage /dev/md/0 -a /dev/sda1

Чтобы начать процесс восстановления, новому добавленному диску должен быть присвоен статус faulty:

sudo mdadm --manage --set-faulty /dev/md/0 /dev/sda1

Ход можно снова отслеживать с помощью команды watch cat /proc/mdstat.
Как только восстановление RAID завершено, раздел должен быть удален из RAID и добавлен снова, чтобы удалить состояние «неисправен». Это делается с помощью команд:

sudo mdadm --manage /dev/md/0 -r /dev/sda1 # To be removed
sudo mdadm --manage /dev/md/0 -a /dev/sda1 # To be added again

* * Примечание . Если система находится на самом RAID-массиве, необходимо установить загрузчик на соответствующий диск. Это делается с помощью следующей команды:

update grub && grub-install /dev/sda

Шаг 4.3 — Расширить RAID

Только RAID с уровнями 1, 5 и 6 могут быть расширены.
Новый раздел должен быть сначала добавлен в качестве горячего резерва:

sudo mdadm /dev/md0 --add /dev/sda1 

Теперь RAID можно расширить с помощью нового диска:

sudo mdadm --grow --raid-devices=5 /dev/md0 --backup-file=/root/md0.bak 

Примечание : в указанном файле --backup-fileсохраняются критические области (обычно несколько МБ). Если во время расширения происходит сбой системы, расширение можно продолжить позже, используя следующую команду:

sudo mdadm /dev/md0 --continue --backup-file=/tmp/md0.bak

Файл резервной копии не должен быть расположен на RAID, чтобы быть расширенным! Использование backup-fileне обязательно, но настоятельно рекомендуется.

Файловая система должна быть расширена, чтобы можно было использовать только что созданное пространство хранения. Расширение происходит с помощью следующих команд:

sudo umount /dev/md0 /mnt    # Unmount the file system
sudo fsck.ext4 -f /dev/md0   # Force the check, even if it has recently been checked
sudo resize2fs /dev/md0      # Extend file system to maximum size
sudo mount /dev/md0 /mnt     # Mount the file system again 

Шаг 4.4 — RAID-мониторы

Для мониторинга RAID эта запись может быть сохранена как crontab ( sudo crontab -e):

0 0 * * * /usr/share/mdadm/checkarray --cron --all --quiet >/dev/null 2>&1 # Runs every day at 00:00 AM

Вывод

В этой статье мы рассказали, как выбрать подходящий уровень RAID для вашего проекта, а затем настроить его в системах Linux, используя mdadm. Кроме того, будут обсуждаться административные задачи, такие как расширение RAID или замена неисправных жестких дисков.

Ускоряем софтрейд и RAID6 в домашнем сервере / Хабр

Чем можно заниматься в 0 часов 0 минут в Москве? Сидеть за праздничным столом и праздновать? Как бы не так. В этот праздничный миг я хочу поделиться с вами моими сегодняшними изысканиями по тюнингу производительности софтрейда в домашнем сервере. Можно пропустить теорию и сразу читать последний абзац где основная соль.

Почему RAID-6?

Как известно, RAID-5 выдерживает смерть одного веника, и после этой самой смерти – до момента когда закончится восстановление рейда с новым винчестером ваши данные под угрозой – восстановление обычно занимало до 70 часов для больших массивов и еще один веник может легко умереть в это время.
RAID-6 выдерживает смерть 2-х любых веников. Из минусов – общепризнанное мнение что тормозит, особенно запись, даже по сравнению с RAID-5. Что-ж, проверим.

Почему софтрейд?

Железный рейд нужен только в одном случае – если у него есть батарейка и набортный кеш. Тогда контроллер сразу отвечает ОС что запись на диск завершена на физическом уровне и всякие ACID базы работают очень быстро и безопасно.
В остальных случаях никаких бонусов по сравнению с софт-рейдом нет, одни минусы:
1) Сгорело железо? Новый сервер? Будьте добры купить тот же контроллер, ну или молитесь о совместимости. Софтрейд из тех-же дисков собирается где угодно.
2) Цена 🙂 Собственно, из-за этого нормальных рейдов с батарейкой я в руках так ниразу и не держал 🙂

Ну а те «рейд-контроллеры» которые стоят на обычных материнских платах – вообще никогда не стоит использовать. Они просто дают грузить ОС с рейда за счет набортного биоса (который выполняется центральным процессором, своего процессора нет), на этом их польза заканчивается, и остаются только минусы.

О паре мифов софтрейда

1) Он жрет много драгоценного процессора
Если мы одним глазком глянем в исходники драйвера RAID в ядре Linux, то увидем, что там давно все оптимизированно под SSE2. А с SSE2 процессор может считать XOR от 16 байт за 1 такт на 1 ядре современного процессора и все упирается в скорость обмена с памятью. Можете прикинуть сколько % загрузки одного ядра сгенерирует поток в 1Гб/сек 🙂 А ядер то много 🙂 На практике, с моим Opteron 165 (1.8Ghz 2 ядра) скорость никогда не упиралась в CPU.
2) Он разваливается и потом хрен соберешь.
Если что-то и отваливается – то из-за железа (например обычные винты любят иногда делать всякие фоновые задачи). Добавление вывалившегося веника – простая операция, которая кроме того может проводится автоматически. Впрочем, в среднем это надо делать раз в год.
mdadm /dev/md0 -a /dev/sde1
3) У софтрейда хреновый мониторинг
С мониторингом все отлично и настраиваемо. Достаточно например просто мыло указать в конфиге mdadm и он пришлет вам письмо если что-то случиться с вашим массивом. Очень удобно )

Вот например что приходит если один веник отвалился:

This is an automatically generated mail message from mdadm running on XXXXX

A DegradedArray event had been detected on md device /dev/md0.

Faithfully yours, etc.

P.S. The /proc/mdstat file currently contains the following:

Personalities: [raid6] [raid5] [raid4]

md0: active raid6 sda1[1] sdc1[4] sdd1[3] sde1[2]

2929683456 blocks super 1.2 level 6, 1024k chunk, algorithm 2 [5/4] [_UUUU]

unused devices: none

Рекоменую протестировать перед использованием:
mdadm —monitor -1 -m [email protected] /dev/md0 -t
4) У софтрейда очень низкая скорость перестройки массива
В дефолтной конфигурации – да. А если вы дочитаете до конца статьи – узнаете как сделать так, чтобы все перестраивалось со скоростью самого медленного веника 🙂

О роли bitmap

Linux-овый софтрейд поддерживает замечательную фичу: bitmap. Там отмечаются измененные блоки на диске, и если у вас почему-то отвалился один диск из массива, а потом вы его обратно добавили – полная перестройка массива не нужна. Чертовски полезно. Хранить можно на самом рейде – internal, а можно в отдельном файле – но тут есть ограничения (на тип ФС например). Я сделал internal bitmap. И зря. Internal bitmap тормозит безбожно т.к. постоянно дергается головка веников при записи.

Посмотрим на скорость:

Скорость можно тестировать например так:

time sh -c «dd if=/dev/zero of=ddfile bs=1M count=5000»

time sh -c «dd if=ddfile of=/dev/null bs=1M count=5000»

Результаты для моего RAID-6 из 5xWD 1Тб получились следующие: чтение 268МБ/сек, запись 37МБ/сек. Все разводят руками и говорят: ну а чего же вы хотели? RAID-6 тормозит при записи, ведь ему надо прочитать то что было записано раньше, чтобы посчитать обновленные контрольные суммы для всех дисков. А еще и этот bitmap…
Скорость перестройки массива – около 25МБ/сек – полная перестройка массива до 15 часов. Вот он, ваш ночной кошмар.

Решаются проблемы просто:

1. У драйвера рейда в Linux есть такой полезный параметр: stripe_cache_size
   
   значение по умолчанию которого равно 256. Слишком низкое значение – резко снижает скорость записи (как оказалось). Оптимальное значение для многих – 8192. Это — кол-во блоков памяти на 1 диск. 1 блок это обычно 4kb (зависит от платформы), для 5-и дискового массива кеш займет 8192*4кб*5 = 160МБ.
   
   echo 8192 > /sys/block/md0/md/stripe_cache_size

   Действовать начинает моментально. Теперь в большинстве случаев драйверу не приходится читать диск перед записью (особенно при линейной записи), и производительность резко вырастает. После перезагрузки пропадает, чтобы не пропало — добавляем в какой-нибуть /etc/rc.local например.

   Скорость перестройки массива теперь – 66МБ/сек (это сразу по всем дискам, около 5 часов на весь массив), скорость чтения осталась той-же, а вот скорость записи – выросла до 130МБ/сек (с 37).

2. Переносим bitmap на отдельный диск (в моём случае — системный). Если системный веник сдохнет — ничего страшного, массив восстановится и без bitmap-а.
   
   Головка больше не дергается при записи лишний раз, и скорость записи вырастает до 165МБ/сек.
   
   mdadm -G /dev/md0 -b /var/md0_intent

Итак, за 10 секунд мы подняли скорость записи с удручающих 37 МБ/сек до вполне приличных 165 МБ/сек (более чем в 4 раза!!). Теперь через Samba по сети файлы и пишутся и читаются 95-100 МБ/сек, и планировавшийся из-за низкой скорости рейда апгрейд сервера придется отложить на неопределенное время – производительности дохленького Opteron 165 теперь с лихвой хватает для всех поставленных задач 🙂
С новым годом 🙂

PS. Внимание! Под рутом ходить только на трезвую голову!
PS. В непростой схватке, первый пост на хабре в 2011 году опубликовал все-таки я
PS. infi

опыт восстановления массива 16Тб / Хабр

Несколько дней назад вышел из строя один из жестких дисков на бюджетном массиве из 16х1ТБ дисков. Уровень массива: RAID 6. Ситуация осложнилась тем, что (как оказалось) ранее также встал кулер на видеокарте этого же сервера, что не было заранее подмечено, и после замены HDD, в результате изменения режима охлаждения корпуса — это стало проявляться в виде зависаний во время синхронизации, что само по себе очень неприятно. Вылилось это в то, что массив перестал автособираться, и были помечены как сбойные еще несколько дисков, и пришлось уже разбираться с ним по-серьёзному, курить вики, мануалы и форумы (форумы — самое полезное, поскольку описывают опыт конкретных людей в конкретных ситуациях).

Структура моего массива:

16х1Тб HDD

разделы:

md0 — /root 8х1 Гб, RAID 6

md1 — /data: 16х999Гб, RAID 6

Сначала все эксперименты по сборке ставились на md0, т. е. на рутовой партиции, которая сама по себе большой ценностью не обладает, разве что тот факт что это настроенная система.

Итак я загрузился с 1-го диска Дебиан в режиме «Resque mode»

Попытка автосборки массива через

mdadm --assemble --scan

привела к выводу ошибки «недостаточно дисков для сборки массива».

Продолжаем по науке:

1. Необходимо сохранить информацию описания для массивов, которые содержат иформацию, какой конкретно диск является каким номером в массиве. На случай если придется собирать «опасными методами»:

mdadm --examine /dev/sd[abcdefghijklmnop]1 > /mnt/raid_layout1
mdadm --examine /dev/sd[abcdefghijklmnop]2 > /mnt/raid_layout2

Данные файлы содержат что-то похожее на приведенное ниже для всех HDD, у которых на партиции sdX1 есть суперблок (в моем случае только 8 из 16 для md0 имеют суперблок на sdX1)

Ниже пример вывода одного из разделов:

/dev/sdp1:
        Version : 0.90.00
     Raid Level : raid6
  Used Dev Size : 975360 (952.66 MiB 998.77 MB)
   Raid Devices : 8
  Total Devices : 8

      Number   Major   Minor   RaidDevice State
this     4       8      177        4      active sync   /dev/sdl1

   0     0       8       97        0      active sync   /dev/sdg1
   1     1       8      113        1      active sync   /dev/sdh2
   2     2       8      129        2      active sync   /dev/sdi1
   3     3       8      145        3      active sync   /dev/sdj1
   4     4       8      177        4      active sync   /dev/sdl1
   5     5       8      193        5      active sync   /dev/sdm1
   6     6       8      209        6      active sync   /dev/sdn1
   7     7       8      225        7      active sync   /dev/sdo1

Кратко о том, что это означает:

sdf2 — текущая анализируемая партиция

Version 0.90.00 — Версия суперблока

Также вы увидите кучу полезной информации — размер массива, UUID, Level, Размер массива, Кол-во устройств и т. д.

Но самое важное для нас сейчас — это таблица внизу списка, первая строчка в ней, указывает, каким по счету HDD в массиве является наш экзаменуемый:

this     4       8      177        4      active sync   /dev/sdl1

Также обратите пристальное внимание на версию суперблока! В моем случае это 0.90.00.

Тут мы видим его номер в массиве, т. е. 4 — такие же номера вы найдете в выводе для всех других устройств из списка. Обратите внимание, что буковка диска в строчке статуса другая — sdl1 — это означает, что диск был проинициализирован на другом SATA порту, затем перемещен. Это некритичная информация, но может быть полезной.

Критичным является название устройства и его номер в массиве (они поменяются при переносе устройств с порта на порт).

Сохраняем созданный файл raid_layout (например на флешке), чтобы не потерялся, и приступаем к следующему шагу:

2. Пытаемся собрать массив

Собрать массив можно 2мя способами: автоматический и ручной.

Автоматический:

mdadm --assemble --scan -v

Если автоматически он собрался, считайте вам повезло, надо просто проверить все ли HDD в массиве, и если нет, добавить недостающие, и дальше можно не читать. Но, в моем случае, автоматическая сборка не проходит с ошибкой, что недостаточно работающих устройств:

mdadm: /dev/md2 assembled from 4 drives - not enough to start the array.

и массив был создан на 4 из 8 дисков. Работать конечно не будет, поскольку Raid6 позволяет отсутствовать только 2-м дискам.

Проверяем статус массива

cat /proc/mdstat

md2 : inactive sdn1[3](S) sdk1[7](S) sdj1[6](S) sdp1[4](S)
      3907264 blocks

Тут есть тонкость — если в списке HDD встречается не проинициализированный или помеченный как сбойный, то сборка немедленно прекращается, поэтому полезен флаг «-v» — чтобы увидеть на каком из HDD сборка встала.

Ручная сборка:

mdadm --assemble /dev/sd[abcdefgh]1 -v

Тоже самое, но мы указали конкретно, какие HDD использовать для сборки.

Скорее всего массив не соберется также, как и в случае с автоматической сборкой. Но, собирая вручную, вы начинаете лучше понимать саму суть происходящего.

Массив также не соберется, если в метаданных раздела, диск помечен как «faulty».

Тут я перескакивая на то, как я запустил массив с данными, поскольку /root массив я потерял, почему и как — рассказано ниже. Собрать массив игнорируя статус «faulty» — можно добавив флаг «-f» (force) — в моем случае это решило проблему сборки основного раздела с данными т. е. раздел был успешно пересобран следующей командой:

mdadm --assemble /dev/md3 /dev/sd[abcdefghijklmnop]2 -f

наверняка, простой способ собрать его был бы следующим:

mdadm —assemble —scan -f -v

Но, поскольку я добрался до флага «-f» через тернии, это сейчас понятно.
Т. е. разделы, помеченные как сбойные, или устаревшие были добавлены в массив, а не проигнорированы. С большой вероятностью, сбойным или устаревшим раздел может быть помечен при плохо, или не плотно сидящем SATA кабеле, что является не редкостью.

Тем не менее, у меня получился массив в режиме degraded, на 14 дисков из 16.

Теперь, чтобы восстановить нормальную работоспособность массива и не бояться за него, нужно добавить в него 2 недостающих диска:

mdadm --add /dev/md3 /dev/sdX2

где Х буковка раздела нового HDD

Ниже я приведу сложности с которыми я столкнулся, дабы уберечь других, от наступания на мои грабли:

Я использовал рекомендации WIKI — Linux RAID Recovery ( raid.wiki.kernel.org/index.php/RAID_Recovery ) по работе с массивом с Linux RAID WIKI — Советую быть с ними осторожными, поскольку страничка очень кратко описывает процесс, и благодаря этим рекомендациям, я разрушил /root (md0) моего массива.

До данной строчки в самом низу статьи WIKI, все очень полезно:

mdadm --create --assume-clean --level=6 --raid-devices=10 /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 missing missing /dev/sdl1 /dev/sdk1 /dev/sdj1

Данная строчка демонстрирует как пересоздать массив, зная какие устройства в каком порядке в него входят. Тут очень важно учесть версию своего суперблока, поскольку новые mdadm создают суперблок 1.2 и он располагается в начале раздела, 0.90 же располагается в конце. Поэтому нужно добавить флаг «—metadata=0.90».
После того, как я собрал массив используя «—create», файловая система оказалась разрушенной, и ни основной суперблок ext4, ни резервные не нашлись. Сначала я обнаружил, что новый суперблок не 0.90 а 1.2, что могло являться причиной уничтожения раздела, но, похоже, не являлось, поскольку изменение версии RAID суперблока на 0.90 и поиск backup суперблока ext4 — был неудачен.
Поскольку /root партиция — это не самая важная часть, тут я решил поэкспериментировать — массив был переформатирован и после этого остановлен:
mdadm —stop /dev/md2
и тотчас создан ещё раз через «—create»: результат — файловая система разрушена опять, хотя этого случиться не должно было, я уверен, что не перепутал порядок устройств и первый раз, и тем более 2-й.
Возможно кто-то успешно восстанавливал разделы, через «—create», буду рад добавить в данную статью, что конкретно мною было сделано неправильно, и почему разрушалась FS. Возможно, она была собрана еще и с другими параметрами размера блока (chunk size).

Очевидно что какими либо рекомендациями из данной статьи следует пользоваться на свой страх и риск, никто не гарантирует что в Вашем случае все сработает именно так как в моём.

Установка Linux на software raid

Будем исходить из того, что у нас есть рабочий компьютер без аппаратного raid-контроллера, два харда одинакового размера, дистрибутив Linux на флешке, в моем случае Xubuntu и острое желание установить систему на software raid1 — что все же лучше, чем single disk, понятно почему

Загружаемся с флешки в live-mode. Получаем полноценный рабочий стол. Запускаем терминал и устанавливаем mdadm — тулза, которая и будет управлять нашим рейд-массивом

apt install mdadm

Теперь на каждом из дисков /dev/sda, /dev/sdb при помощи fdisk нужно создать единственный раздел fd максимального размера. Тип раздела Linux raid autodetect. Для этого выполняем

fdisk /dev/sda

n <return>
p <return>
1 <return>
2048 <return>
<return>
t <return>
fd <return>
w <return>

Аналогично для /dev/sdb. Синхронизируем диски

mdadm --create /dev/md0 --bitmap=internal --level=1 -n 2 /dev/sd[ab]1

Для наблюдения за процессом синхронизации

cat /proc/mdstat

Таким образом мы создали новый дисковый массив /dev/md0, на который и будем устанавливать систему. Необязательно ждать окончания синхронизации. Продолжаем

Так как стандартный инсталятор *ubuntu не умеет работать с разделами /dev/md0, то еще раз воспользуемся услугами fdisk и создадим разделы вручную. Количество разделов и их размеры зависят от Ваших предпочтений

fdisk /dev/md0

• /dev/md0p1 / корневой раздел
• /dev/md0p2 swap, принято давать в два раза больше чем память, но я не думаю, что это точная формула
• /dev/md0p3 /home домашный раздел для пользователей

Создали, записали, вышли из fdisk. Запускаем инсталятор из той же консоли

ubiquity -b

В том месте (выбор Something else), где нужно выбрать диски/разделы, выбираем

• /dev/md0p1, точку монтирования /, ставим галочку format
• /dev/md0p2, swap раздел
• /dev/md0p3, точку монтирования /home, ставим галочку format

Продолжаем установку. По завершении еще не перегружаемся, поскольку нужно установить еще загрузчик. В консоли

mount /dev/md0p1 /mnt
mount -o bind /dev /mnt/dev
mount -o bind /dev/pts /mnt/dev/pts
mount -o bind /sys /mnt/sys
mount -o bind /proc /mnt/proc
cat /etc/resolv.conf >> /mnt/etc/resolv.conf
chroot /mnt
apt-get install mdadm
vi /etc/grub.d/10_linux # изменить значение quick_boot на 0
grub-install /dev/sda
grub-install /dev/sdb
update-grub
exit

Перегрузка и мои поздравления

Александр Черных

системный администратор

4.6k

Программный raid на Linux с mdadm

Mdadm – утилита Linux, позволяющая создавать и управлять софтварными Raid-массивами дисков (md – multiple devices). Что такое raid и для чего он нужен я писал давным давно.

Сейчас мы замутим программный рейд на Linux-машине. Делать будем “зеркало” (raid1).

План:

1. Создаём рейд-массив;
2. Делаем автомонтирование;
3. Проверяем отказоустойчивость;

Сперва добавим к нашей виртуальной машине два дополнительных диска. Перейдём в настройки, откроем раздел “Носители”, добавим новый диск в раздел “Контроллер: SATA”. Объем небольшой, по 2 гигабайта хватит.

Добавление нового “физического” диска

Получилось как-то так:

Два новых диска

Запускаем виртуальную машину.

В системе появились два новых устройства /dev/sdb и /dev/sdc

Разделов на них нет. Создадим разделы на обоих, выделив всё свободное место и сменив тип файловой системы на fd – Linux raid autodetect:

Fdisk

Создаем раздел

Выбираем тип ФС

Подобные операции мы проделали и с /dev/sdb и с /dev/sdc. Итак, у нас есть /dev/sdb1 и /dev/sdc1 разделы.

Создадим программное зеркало:

# mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1

Указали создать новое устройство /dev/md0, из двух устройств sdb1 и sdc1 в уровень 1 (raid1).

Создаём программный рейд

Готово! Создали рейд. Теперь нам нужно сделать автосоздание рейда при запуске, автомонтирование каталога и проверить отказоустойчивость.

Допишем в файл /etc/fstab запись, чтобы устройство монтировалось в каталог /raid. Не забудем эту папочку создать командой

# mkdir /raid

Делаем запись в fstab

Ну попутно ещё создадим файловую систему на устройстве:

# mkfs.ext3 /dev/md0

Создаём файловую систему

Автосоздание рейда при запуске описывается в конфигурационном файле /etc/mdadm/mdadm.conf, содержимое которого выглядит так:

Строка “DEVICE partitions“, а затем вывод команды # mdadm --detail --scan

# mdadm --detail --scan >> /etc/mdadm/mdadm.conf

Создаём файл автоконфигурирования

итак, файл выглядит вот так:

Содержимое файла автоконфигурирования

Готово! Перезагружаемся!

# reboot

Сейчас мы заполним данными диск. Я просто скопировал файлы из каталога /etc/ в каталог /raid/, в который у нас примонтировано наше устройство /dev/md0

# cp /etc/* /raid/

Содержимое каталога

Готово. Сейчас мы будем имитировать нештатную ситуацию – выход из строя одного из дисков:

Пометим диск как сбойный (кстати, удалить раздел из рейда без пометки его как сбойного может не получиться):

# mdadm /dev/md0 -f /dev/sdc1

Метим раздел как сбойный

Теперь raid работает на одном диске, в чём легко убедиться:

# mdadm -D /dev/md0

Детальная информация о массиве

Появилась строка faulty spare /dev/sdc1… А статус массива degraded. Вот, в общем-то и имитация сбоя. На практике это произойдёт автоматически, не надо будет помечать диск как фейловый (ключ -f).

Удалим раздел /dev/sdc1 из массива и занулим его:

# mdadm /dev/md0 -r /dev/sdc1
# dd if=/dev/zero of=/dev/sdc

Удаляем раздел из массива и зануляем его

Теперь у нас имеется “битое зеркало”, которое дышит благодаря одному лишь диску /dev/sdb1, в чём нетрудно убедиться. Данные на месте.

Далее, по нашей симуляции, мы установим “чистый диск”, коим у нас будет являться /dev/sdc (он и правда чист, мы его занулили).

Теперь нужно воссоздать разметку диска. Можно это делать вручную fdisk-ом. А можно воспользоваться sfdisk, если диски одного размера.

# sfdisk -d /dev/sdb | sfdisk /dev/sdc

Копируем разметку с раздела

Таким образом мы скопируем разметку, то есть разделы, начало, конец и количество блоков. И тип файловой системы. Всё, что нам нужно.

Когда процедура будет завершена, добавим в наш рейд /dev/sdc1 и дождёмся окончания синхронизации:

# mdadm /dev/md0 -a /dev/sdc1
А посмотреть состояние синхронизации можно в файле /proc/mdstat

# cat /proc/mdstat

Статистика синхронизации

Как видим, происходит восстановление…

Если выполнить команду

# mdadm -D /dev/md0

то увидим, что и тут идёт ребилдинг (синхронизация)

Информация о синхронизации

Когда синхронизация завершена – оба диска работает нормально! Данные на месте!

Диски синхронизированны

Вот так мы и рассмотрели работу зеркала. Аналогично можно создать и raid5, на трёх дисках, к примеру. Там избыточность будет меньше.

миграция с Windows raid0 на Linux mdadm raid5 / Хабр

Отчет о том как мы мигрировали с Windows raid0 на Linux raid5, какие подводные камни встретили и как их преодолевали.

Предистория. Отдел дизайна обслуживается файловым сервером под управлением Windows 2003. Изначально он проектировался для обмена данными, но со временем его стали использовать для долговременного хранения файлов, несмотря на то что у него программный raid0. Наступило время очередного обновления оборудования. После закупки «неожиданно» выяснилось что на новой материнской плате Windows 2003 не стартует, производитель драйвера не выпускает и рекомендует использовать более новую версию Windows, что неприемлемо по лицензионным соображениям.

В итоге было принято два решения:

• Перенести сервер в виртуальную машину под KVM
• Использовать для хранения данных raid5

Вопросов по виртуализации нет — делалось не раз. Основная проблема это нулевой рейд, организованный средствами Windows. Было потрачено время на попытку примонтировать windows-raid0 в linux — не удалось, несмотря на описания в интернете того что это возможно.

Вторая проблема: на Windows сервере винчестеров для raid0 два, по 2TB каждый, весь массив заполнен данными и скопировать их некуда. Новых винчестеров купили тоже два но уже по 3TB. Руководство отдела изначально хотело их присоединить к имеющемуся нулевому рейду и получить виртуальный диск для хранения данных в 10TB.

Путем объяснения удалось убедить в неправильности такого подхода, но убедить докупить третий винчестер на 3TB не удалось, поэтому решили действовать в последовательности:

1) Собрать raid5 с одним отсутствующим винчестером

mdtest# mdadm --create /dev/md4 -l 5 -n 3 /dev/sda1 /dev/sdb1 missing

2) Передать raid5 в Windows и его средствами скопировать данные

3) По завершению копирования из оставшихся дисков собрать raid0 и передать его в качестве третьего блочного устройства в raid5

mdtest# mdadm --create /dev/md3 -l 0 -n 2 /dev/sdc1 /dev/sdd1
mdtest# mdadm --add /dev/md4 /dev/md3

Оттестировали данный вариант в виртуальной машине с меньшим объемом данных — все получается замечательно, по завершению теста имеем raid5, проводим несколько жестких перезагрузок, отключаем-включаем виртуальные винчестеры — рейд живет как и положено — самовосстанавливается и потерь данных нет.

Очень смущает то что, после того как скопированы данные, имеется деградированный массив и он восстанавливается за счёт двух винчестеров с которых они были скопированы, в случае сбоя на этом этапе — полная потеря всей информации. Значит нужно данные где-то предварительно забэкапить. Но все осложняется тем что из свободных винчестеров есть только два по 1TB. Обстановка накаляется, утром данные на сервере должны быть как минимум в доступе на чтение.

Ревизия других серверов показала что у нас есть сервер с 2TB свободного места, это спасает ситуацию, мы можем сохранить образ одного из двух 2TB винчестеров и на этапе восстановление raid5 использовать его в страйпе с винчестером на 1TB, в случае сбоя все данные в сохранности. Итоговая схема:

/dev/md3 - raid0: 1TB + 2TB
/dev/md4 - raid5: 2x3TB + /dev/md3

Приступаем к действиям над реальными данными

Собираем raid5 без одного винчестера, запускаем Windows 2003 под Linux в KVM, начинаем копирование и видим что скорость записи очень низкая 3-6МB/s, при этом запись из-под Linux на тот же деградированный raid5 (утроенного объема данных от оперативной памяти) прошло на средней скорости в 80MB/s, но из-за того что исходные данные можно скопировать только из под Windows это никак не помогает. Да мы знаем что скорость записи на деградированный raid5 снижается, но откуда такая разница между Linux и Windows.

Для теста попробовали из-под Windows копировать данные на одиночный диск — 100MB/s. Может реализация mdadm такова что Windows плохо себя чувствует в операциях на запись в raid? Маловероятно — у нас несколько Windows работают поверх raid1 собранных в mdadm. Эксперимента ради собрали raid1, скорость копирования из под Windows в тех же пределах что и на одиночный диск — примерно 100MB/s.

Наши ошибки в том что мы поверили статье где из контекста утверждалось: «изначально собранный в mdadm raid5 из двух винчестеров и одного отсутствующего является по реализации нулевым рейдом», а также то что тестирование мы проводили только под Linux, начни мы копирование во время тестов из-под Windows проблема была известна раньше.

Тестовая среда должна полностью повторять продуктивную.

Возвращаемся к тестам

Принимается решение собрать из двух 3TB винчестеров raid0, скопировать данные, а затем пересобрать этот массив в raid5.

1) Создаем raid0

mdtest# mdadm --create /dev/md4 -l 0 -n 2 /dev/sda1 /dev/sdb1

2) Копируем данные, на этот раз из-под Windows, скорость записи 60-100MB/s

3) Преобразуем raid0 в raid1

mdtest# mdadm /dev/md4 --grow --level=5
mdadm: level of /dev/md4 changed to raid5

Данная операция производится мгновенно mdadm -D /dev/md4 рапортует о том что у нас raid5

mdtest# mdadm -D /dev/md4
/dev/md4:
     Raid Level : raid5
   Raid Devices : 3
  Total Devices : 2
          State : clean, degraded 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0
    Number   Major   Minor   RaidDevice State
       0     252        0        0      active sync   /dev/dm-0
       1     252        1        1      active sync   /dev/dm-1
       2       0        0        2      removed

4) Добавляем третье блочное устройство

mstest# mdadm --add /dev/md4 /dev/md3
mdadm: added /dev/md3

Смотрим статус:

mdtest# mdadm -D /dev/md4
/dev/md4:
     Raid Level : raid5
   Raid Devices : 3
  Total Devices : 3
          State : clean, degraded, recovering
 Active Devices : 2
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 1
 Rebuild Status : 2% complete
    Number   Major   Minor   RaidDevice State
       0     252        0        0      active sync   /dev/dm-0
       1     252        1        1      active sync   /dev/dm-1
       3     252        2        2      spare rebuilding   /dev/dm-2

Тесты завершены успешно.

Фактическая миграция

1. Собрали mdadm-raid0 [md4] из двух 3TB винчестеров.
2. В Windows скопировали на mdadm-raid0 данные с windows-raid0.
3. Сохранили образ второго винчестера из windows-raid0 на соседнем сервере (2TB).
4. Преобразовали mdadm-raid0 в mdadm-raid5.
5. Собрали mdadm-raid0 [md3] из диска 1TB и второго диска из windows-raid0.
6. Добавили в mdadm-raid5 третьим блочным устройством mdadm-raid0 [md3].

Примечания

Во время пересборки raid5, для ускорения проводилась оптимизация, stripe_cache_size был увеличен на максимум до 32768: echo 32768 > /sys/block/md4/md/stripe_cache_size. Write Intent Bitmap был отключен: mdadm --grow --bitmap=none /dev/md4.

Если windows-raid0 заполнен до предела, то на нем сильная фрагментация данных, проводить дефрагментацию на 4TB долго, мы вышли из положения копируя в несколько потоков программой Microsoft Richcopy

Очень толковое руководства по командам mdadm «Программный RAID в Linux».

Linux Raid Wiki

Введение

Этот сайт представляет собой управляемый сообществом список ядер Linux-raid для программного RAID-массива Linux, реализованного в ядрах последней версии 4 и более ранних.
Он должен заменить многие из неподдерживаемых и устаревших документов из , таких как Software RAID HOWTO и Linux RAID FAQ .

По возможности, информация должна быть помечена минимальной версией ядра / программного обеспечения, необходимой для использования этой функции.Некоторая информация на этих страницах, к сожалению, довольно старая, но мы находимся в процессе обновления информации (не всегда ли …)

Список рассылки

Проблемы

Linux RAID обсуждаются в списке рассылки linux-raid, который можно найти по адресу http://vger.kernel.org/vger-lists.html#linux-raid

Это соответствует соглашениям kernel.org. Вы должны использовать «ответить всем», если явно не запрошено. Посторонний материал следует обрезать. Ответы должны быть в строке или внизу. (Пожалуйста, прочтите .sig плаката, так как это может означать: «Я прочитал список — пожалуйста, не отправляйте мне копию».)

И, пожалуйста, используйте почтовый клиент, который корректно выполняет потоки!

Требуется помощь

Этот сайт был создан Дэвидом Гривзом и Ником Йейтсом. Но жизнь шла своим чередом, и после попыток предоставить актуальную информацию информация снова устарела. Келд Симонсен обновил много информации и сделал хорошие оценки для Google.

По состоянию на сентябрь 2016 года Wol обновляет его до mdadm 3.3 и ядер 4.x (mdadm 4.0 был выпущен в январе 2017 года). Пожалуйста, свяжитесь с Волом, Келдом или Ником, если хотите помочь.Пожалуйста, прочтите правила редактирования.

По состоянию на июнь 2018 года основной сайт обновлен. Однако в доступной информации много пробелов, любая помощь, которую вы можете оказать редактору (ам), будет с благодарностью принята — предложения статей, примеры реализации рейдов, которые в настоящее время не рассматриваются, оборудование для практики на, чтобы не повредить живые системы и т. д.

Обзор

[TODO: обсудить наслоение вещей поверх raid, то есть разбиение массива, LVM или файловой системы btrfs]

Перезапись 2016 года не распространяется на LVM (на данный момент), поэтому для LVM вы найдете все старые вещи в разделе археологии.Кроме того, все данные о производительности относятся к урожаю 2011 года, так что они также были отнесены к разделу археологии.

Когда дела пойдут, Wrogn

Не паникуйте, мистер Мейнверинг!

RAID очень хорошо защищает ваши данные. Фактически, ПОЧТИ ВСЕ данные, которые были потеряны, как сообщается в список рассылки рейда, связаны с ошибкой пользователя при попытке восстановить отказавший массив.

В частности, НИКОГДА НИКОГДА не используйте «mdadm —create» на уже существующем массиве, если вы не руководствуетесь экспертом.Это единственный наиболее эффективный способ превратить простое упражнение по восстановлению в серьезную судебно-медицинскую проблему — он может быть не так эффективен, как «dd if = / dev / random of = / dev / sda», но он довольно близок …

Иногда самое простое оказывается лучшим. Если массив не запускается после сбоя или перезагрузки, и вы не можете заставить его собрать, всегда попробуйте «mdadm / dev / mdN —stop», а затем попробуйте собрать его снова. Проблемы при загрузке часто оставляют вас с частично собранным массивом, который затем отказывается что-либо делать.«Стоп», за которым следует «сборка», никогда не причинит вреда и вполне может решить проблему. Однако будьте очень осторожны с «—force», так как это может вызвать повторную синхронизацию, которая может уничтожить содержимое диска и сделать восстановление трудным или невозможным.

Также убедитесь, что вы используете последнюю версию mdadm (см. Руководство по mdadm).

В дополнение к чтению этого, вероятно, стоит посетить раздел археологии программного обеспечения и прочитать «Восстановление RAID» и «Восстановление сбойного программного RAID».Просто имейте в виду, что это старые страницы, и все могло измениться. И что все, что актуально в 2016 году, нужно было скопировать на указанные выше страницы.

Интересующие территории

Аппаратный RAID

Правильные аппаратные RAID-системы представлены Linux как блочные устройства, и в этой вики они не рассматриваются (пока).

BIOS / встроенное ПО RAID, также известное как поддельные рейдовые карты:

• предлагают несколько преимуществ в производительности (например, разгрузку ЦП, шины и ОЗУ), но часто может быть намного медленнее, чем рейд SW (ссылка?)
• Если «рейд» карта или материнская плата умирают, вам часто приходится искать точную замену, а это может быть сложно для старых карт
• если диски перемещаются на другие машины, данные не могут быть легко прочитаны
• обычно нет мониторинга или отчетов по массиву — если возникает проблема, она может не появиться, если машина не перезагружена * и * кто-то действительно наблюдает за экраном загрузки BIOS (или пока не произойдет несколько ошибок и ваши данные не будут потеряны )
• вы поручаете свои данные неподдающемуся исправлению программному обеспечению, записанному в BIOS, который, вероятно, не был протестирован, не имеет механизма поддержки и почти не имеет сообщества.
• , увидев, сколько ошибок ядро ​​исправляет в различных BIOS, было бы оптимистично думать, что BIOS RAID не содержит ошибок.

Учитывая, что цель RAID обычно заключается в снижении риска, справедливо будет сказать, что использование fakeraid — ужасная идея, и лучше сосредоточить энергию либо на реальном рейде HW, либо на рейде внутри ядра SW …. останавливая тебя 🙂

Программирование ядра

Этот раздел предназначен для множества вещей.С уходом Нила Брауна с поста сопровождающего (начало 2016 г.) процесс разработки не кажется таким «надежным». Неудивительно, что новым сопровождающим необходимо получить опыт, накопленный Нейлом в работе с подсистемой. Таким образом, в этом разделе будет размещена документация о том, как работают внутренние компоненты подсистемы рейдов.

RIP Шаохуа Ли. Шаохуа Ли (LWN) Шаохуа сменил Нила, но, к сожалению, умер на Рождество 2018 года. Йенс Аксбоу стал временным сопровождающим.

Но документация без спецификации бесполезна.Существовала философия (известная как Microsoft, особенно в их спецификации Office Open XML), согласно которой «код — это документация» или «код — это спецификация». Это отлично подходит для программистов — одна из его особенностей заключается в том, что он устраняет все ошибки одним махом! Если код является спецификацией, то система должна вести себя, как указано, . Таким образом, в этом разделе также будет размещена документация о том, как должны работать внутренние компоненты подсистемы рейдов.

Тогда, конечно, мы хотим, чтобы с системой помогало как можно больше людей.Таким образом, этот раздел также будет содержать список проектов, которые люди могут сделать, и несколько советов, которые помогут им в том, с чего начать. Они не обязательно должны работать над самим ядром или mdadm, уже есть утилиты (lsdrv Фила, сценарий тайм-аута Брэда), и есть еще много других, которые будут оценены по достоинству.

Программирование проектов

Археология

В этот раздел были перемещены все старые страницы. Некоторые из них могли быть отредактированы перед перемещением, но информация здесь в основном устарела, например, lilo, raidtools и т. Д.Это может быть интересно людям, использующим старые системы, но не должно быть в основном разделе, где это может сбить с толку.

Археология RAID

Внешние ссылки

См. Раздел «Блокировка спама» для получения информации об ограничениях на спам на этом сайте.

.

Получить подробную информацию о конфигурации RAID [linux]

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

.