LINUX.ORG.RU
решено ФорумAdmin

Вопрос по совтовому рейду(mdadm)

 


0

1

Доброго времени суток !
Интересно Ваше мнение. Как лучше делать raid 1 на уже существующей системе с учетом того, что там 6 разделов. RAID-массив на каждый раздел или один RAID-массив для всех разделов ?

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1           1        1024   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2   *           1          13       97280   83  Linux
Partition 2 does not end on cylinder boundary.
/dev/sda3              13      120855   970662912   83  Linux
/dev/sda4          120855      121602     5998593    5  Extended
/dev/sda5          120855      121353     3998720   82  Linux swap / Solaris
/dev/sda6          121353      121602     1998848   83  Linux

Number  Start   End     Size    Type      File system     Flags
 1      1049kB  2097kB  1049kB  primary
 2      2097kB  102MB   99.6MB  primary   ext2            boot
 3      102MB   994GB   994GB   primary   ext4
 4      994GB   1000GB  6143MB  extended
 5      994GB   998GB   4095MB  logical   linux-swap(v1)
 6      998GB   1000GB  2047MB  logical   ext4


И под вопрос. Стоит ли напрягаться, если sfdisk при копировании таблицы разделов выдает варнинг?
root@host01:~# sfdisk -d /dev/sda | sfdisk /dev/sdb
Checking that no-one is using this disk right now ...
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
OK

Disk /dev/sdb: 121601 cylinders, 255 heads, 63 sectors/track
Old situation:
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sdb1          0       -       0          0    0  Empty
/dev/sdb2          0       -       0          0    0  Empty
/dev/sdb3          0       -       0          0    0  Empty
/dev/sdb4          0       -       0          0    0  Empty
New situation:
Units = sectors of 512 bytes, counting from 0

   Device Boot    Start       End   #sectors  Id  System
/dev/sdb1          2048      4095       2048  83  Linux
/dev/sdb2   *      4096    198655     194560  83  Linux
/dev/sdb3        198656 1941524479 1941325824  83  Linux
/dev/sdb4     1941526526 1953523711   11997186   5  Extended
/dev/sdb5     1941526528 1949523967    7997440  82  Linux swap / Solaris
/dev/sdb6     1949526016 1953523711    3997696  83  Linux
Warning: partition 1 does not end at a cylinder boundary

sfdisk: I don't like these partitions - nothing changed.
(If you really want this, use the --force option.)



Последнее исправление: UserV (всего исправлений: 5)

За счет второго диска мигрируй на LVM пока не поздно. Средствами lvm и mirror сделаешь.

anonymous
()

Я бы сделал на новом диске один раздел под RAID и поверх него lvm. После этого можно отформатировать и примонтировать новые разделы, перенести туда систему командой:

rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/lost+found"} /* /mnt/newroot

Потом нужно будет пересобрать initrd и установить загрузчик на новый диск.

После успешной загрузки с нового диска, можно скопировать с него таблицу разделов на старый и добавить старый диск в массив.

Если нет времени и желания страдать с загрузкой с mdraid+lvm, можно сделать два раздела для двух массивов. На первом держать /boot, на втором — lvm.

Deleted
()
Ответ на: комментарий от anonymous

Каких только извращений не придумают лишь бы не использовать dump/restore

Да, особенно когда диски разного размера.

vlb ★★★
()

Спасибо всем за комментарии !

UserV
() автор топика
Ответ на: комментарий от vlb

Да, особенно когда диски разного размера.

И в каком месте dump/restore зависят от размеров диска?

anonymous
()
Ответ на: комментарий от anonymous

За счет второго диска мигрируй на LVM пока не поздно. Средствами lvm и mirror сделаешь.

Это самый худший совет, какой можно дать. LVM — мертворождённые поделия для локалхоста. Говорю как человек, ответственный за бэкапы довольно сложной системы, использующей LVM. Во всех новых установках от LVM отказались в пользу ZFS.

По делу: без краткой информации о том, для чего используются разделы на вопрос ответить будет сложно. В общем случае, надёжность RAID определяется надёжностью входящих в его состав дисков. Однако, если у тебя на одном разделе лежит какая-то важная БД, то его, возможно, имеет смысл вынести в отдельный RAID, для гранулярного управления возможной синхронизацией RAID и уменьшения времени простоя. Так же настоятельно советую посмотреть на ZFS в целом и ZVOL частности. RAID1 для свапа, очевидно, бессмысленен. Лучше всего рассмотреть возможность отказаться от свапа вообще, но если это невозможно, RAID0 для свапа показывал неплохие результаты по очевидным причинам.

anonymous
()

Стоит ли напрягаться, если sfdisk при копировании таблицы разделов выдает варнинг?

Нет, не стоит. Выравнивание по границе цилиндров в для современных дисков не имеет никакого смысла, в отличие от выравнивания по границе блока. Если у тебя SSD, это применимо в особенности и, для оптимальной производительности, рекомендуется выравнивать размеры разделов по границе «erase block». Самый универсальный способ это просто выравнивать по границе 1MiB и не загоняться по мелочам.

anonymous
()
Ответ на: комментарий от anonymous

просто выравнивать по границе 1MiB и не загоняться по мелочам

Если бы всё было так просто.

Метаданные mdraid версии 1.1 и 1.2 занимают 1 килобайт в начале раздела (если в массиве не больше 384 дисков). Если у тебя крутой диск с блоком 4k, то способ с границей 1MiB не поможет.

Я тестировал выравнивание на дисках. Оно того стоит. Например если нормально выровнять raid6 из 12 дисков, можно получить в 4 раза больше иопсов при в 2 раза меньшей задержке на тесте с параллельными рандомными записью и чтением. Но для этого нужно выровнять всё: таблицу разделов, mdraid, lvm, ФС, правильно рассчитать страйпы, чанки и т.п. Ошибка на любом из этих этапов сводит на нет все усилия. Если не загоняться по мелочам, то проще вообще забить, т.к. оно того не стоит.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.