Pull to refresh

Очередная миграция PROXMOX в softRAID1, но теперь уже 3.2 и на GPT-разделах, установка FreeNAS 9.2 на виртуальную машину и проброс в него физического диска

Reading time 7 min
Views 28K
Здравствуйте!

В очередной раз мне понадобился сервер Proxmox. Железо следующее: AMD FX-4300, 4Gb, два диска 500Gb для самого proxmox и еще два для хранилища. Задачи слоял следующие: одна из машин FreeNAS, в нее хотелось пробросить несколько дисков (желательно физических), что бы на них разместить хранилище, и еще несколько ВМ не относящихся к статье.

У меня есть фишечка всегда пытаться ставить самые последнии версии, а не проверенные старые. Так произошло и в этот раз.
Скачал Proxmox VE 3.2 и FreeNAS 9.2. А вот что из этого получилось под катом.

Установив в очередной раз Proxmox (последнюю на данный момент версию 3.2) решил перевести его на SoftRAID1. Но обнаружил, что в отличии от 3.0, он (proxmox) преобразовал диск в GPT. Соответственно рекомендации в статье на которую я ориентировался не совсем актуальны. К тому же во всех статьях о переводе Proxmox в SoftRAID речь идет только о двух разделах (boot и LVM). В моем же случае разделов на диске было 3. Первый GRUB, а затем уже стандартные boot и LVM.

Это не должно нас остановить.

Перевод proxmox на softRAID на GPT разделах


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

# nano /etc/apt/sources.list.d/pve-enterprise.list
и закомментируйте единственную строку.

Если вы все же хотите добавить бесплатный репозитарий, то выполните команду:
echo "deb http://download.proxmox.com/debian wheezy pve pve-no-subscription" >> /etc/apt/sources.list.d/proxmox.list
Спасибо heathen за его комментарий.

Теперь ставим необходимые пакеты:

# aptitude update && aptitude install mdadm initramfs-tools screen
последний нужен если вы проделываете это удаленно. Перенос LVM в RAID длится долго и желательно это делать через screen.

Проверяем что создание массивов теперь доступно:

# modprobe raid1
Далее мы копируем разделы с sda на sdb. Вот тут то и начинаются отличия в MBR и GPT. Для GPT это делается так:
# sgdisk -R /dev/sdb /dev/sda
The operation has completed successfully.
Присвоим новому жесткому диску случайный UUID.
# sgdisk -G /dev/sdb
The operation has completed successfully.
# sgdisk --randomize-guids --move-second-header /dev/sdb
The operation has completed successfully.


Проверим что разделы созданы так как мы хотели:

диск sda диск sdb
# parted -s /dev/sda print
Model: ATA WDC WD5000AAKS-0 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  2097kB  1049kB               primary  bios_grub
 2      2097kB  537MB   535MB   ext3         primary  boot
 3      537MB   500GB   500GB                primary  lvm
# parted -s /dev/sdb print
Model: ATA ST3500320NS (scsi)
Disk /dev/sdb: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  2097kB  1049kB               primary  bios_grub
 2      2097kB  537MB   535MB                primary  boot
 3      537MB   500GB   500GB                primary  lvm


Меняем флаги разделов sdb2 и sdb3 на raid:

# parted -s /dev/sdb set 2 "raid" on
# parted -s /dev/sdb set 3 "raid" on
# parted -s /dev/sdb print
Model: ATA ST3500320NS (scsi)
Disk /dev/sdb: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  2097kB  1049kB               primary  bios_grub
 2      2097kB  537MB   535MB                primary  raid
 3      537MB   500GB   500GB                primary  raid
Все получилось правильно.

Идем дальше и на всякий случай очищаем суперблоки:

# mdadm --zero-superblock /dev/sdb2
mdadm: Unrecognised md component device - /dev/sdb2
# mdadm --zero-superblock /dev/sdb3
mdadm: Unrecognised md component device - /dev/sdb3
Вывод «mdadm: Unrecognised md component device — /dev/sdb3» означает, что диск не участвовал в RAID.
Собственно, пора создавать массивы:
# mdadm --create /dev/md1 --level=1 --raid-disks=2 missing /dev/sdb2
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
# mdadm --create /dev/md2 --level=1 --raid-disks=2 missing /dev/sdb3
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.


На вопрос «Продолжить создание массива?» отвечаем утвердительно.

Посмотрим, что у нас получилось:

# cat /proc/mdstat
Personalities : [raid1]
md2 : active raid1 sdb3[1]
      487731008 blocks super 1.2 [2/1] [_U]

md1 : active raid1 sdb2[1]
      521920 blocks super 1.2 [2/1] [_U]


В выводе видно состояние массивов — [_U]. Это обозначает, что в массиве есть лишь один диск. Так и должно быть, ведь второй (первый) мы в массив еще не включили. (missing).

Добавляем информацию о массивах в конфигурационный файл:

# cp /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf_orig
# mdadm --examine --scan >> /etc/mdadm/mdadm.conf


Скопируем раздел boot на соответствующий массив. (Добавил здесь команды отмонтирования раздела. Спасибо за информацию пользователю skazkin. Его опыт показал, что в некоторых случаях без этих действий может раздел boot оказаться пустым после перезагрузки):

# mkfs.ext3 /dev/md1
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
130560 inodes, 521920 blocks
26096 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67633152
64 block groups
8192 blocks per group, 8192 fragments per group
2040 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409

Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

# mkdir /mnt/md1
# mount /dev/md1 /mnt/md1
# cp -ax /boot/* /mnt/md1
# umount /mnt/md1
# rmdir /mnt/md1
Далее нам нужно закоментировать в /etc/fstab строку описывающую монтирование boot-раздела с UUID и пропишем монтирование соответствующего массива:

# nano /etc/fstab


# <file system> <mount point> <type> <options> <dump> <pass>
/dev/pve/root / ext3 errors=remount-ro 0 1
/dev/pve/data /var/lib/vz ext3 defaults 0 1
# UUID=d097457f-cac5-4c7f-9caa-5939785c6f36 /boot ext3 defaults 0 1
/dev/pve/swap none swap sw 0 0
proc /proc proc defaults 0 0
/dev/md1 /boot ext3 defaults 0 1


Должно получиться примерно так.
Перезагружаемся:

# reboot


Настраиваем GRUB (делаем это абсолютно так же как и в оригинальной статье):
# echo 'GRUB_DISABLE_LINUX_UUID=true' >> /etc/default/grub
# echo 'GRUB_PRELOAD_MODULES="raid dmraid"' >> /etc/default/grub
# echo 'GRUB_TERMINAL=console' >> /etc/default/grub
# echo raid1 >> /etc/modules
# echo raid1 >> /etc/initramfs-tools/modules


Переустанавливаем GRUB:

# grub-install /dev/sda --recheck
Installation finished. No error reported.
# grub-install /dev/sdb --recheck
Installation finished. No error reported.
# update-grub
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.32-27-pve
Found initrd image: /boot/initrd.img-2.6.32-27-pve
Found memtest86+ image: /memtest86+.bin
Found memtest86+ multiboot image: /memtest86+_multiboot.bin
done
# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-2.6.32-27-pve


Теперь добавим раздел boot с первого (sda) диска в массив. Сначала пометим его флагом «raid»:

# parted -s /dev/sda set 2 "raid" on


А затем и добавим:
# mdadm --add /dev/md1 /dev/sda2
mdadm: added /dev/sda2


Если посмотреть теперь состояние массивов:

# cat /proc/mdstat
Personalities : [raid1]
md2 : active (auto-read-only) raid1 sdb3[1]
      487731008 blocks super 1.2 [2/1] [_U]

md1 : active raid1 sda2[2] sdb2[1]
      521920 blocks super 1.2 [2/2] [UU]

unused devices: <none>


то мы увидим, что md1 стал «двухдисковым» — [UU]

Теперь нужно перенести основной раздел — LVM. Тут нет никаких отличий от «оригинала», за исключением другой нумерации разделов и:

# screen bash
# pvcreate /dev/md2
  Writing physical volume data to disk "/dev/md2"
  Physical volume "/dev/md2" successfully created
# vgextend pve /dev/md2
  Volume group "pve" successfully extended
# pvmove /dev/sda3 /dev/md2
  /dev/sda3: Moved: 2.0%
 ...
  /dev/sda3: Moved: 100.0%
# vgreduce pve /dev/sda3
  Removed "/dev/sda3" from volume group "pve"
# pvremove /dev/sda3

Здесь, так же по рекомендации skazkin добавил команду pvremove. Без нее (опять таки не всегда) может появиться другая проблема:
система не поймет что произошло с дисками и не загрузится дальше initramfs-консоли


Добавляем раздел sda3 в массив:

# parted -s /dev/sda set 3 "raid" on
# mdadm --add /dev/md2 /dev/sda3
mdadm: added /dev/sda3
# cat /proc/mdstat
Personalities : [raid1]
md2 : active raid1 sda3[2] sdb3[1]
      487731008 blocks super 1.2 [2/1] [_U]
      [>....................]  recovery =  0.3% (1923072/487731008) finish=155.4min speed=52070K/sec

md1 : active raid1 sda2[2] sdb2[1]
      521920 blocks super 1.2 [2/2] [UU]

unused devices: <none>


и видим, что он добавляется.

Так как я действую по оригинальной статье, то я пошел наливать кофе.

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

Для тех, кто как и я не понял почему на этом все, объясняю. Т.к. LVM том мы фактически перенесли с одного блочного устройства на другое, то и прописывать его не требуется (как это было с boot). Я на какое-то время застопорился на этом месте.

FreeNAS 9.2 на процессорах AMD


Следующим моим шагом была установка FreeNAS версии 9.2 на proxmox. Долго мучался. Пока не попробовал поставить из того же образа (FreeNAS 9.2) на другом proxmox-сервере. Он немного отличается от описываемого в статье: во-первых он на Core i7, во-вторых proxmox 3.1. И там это естественно встало на счет раз. Т.е. проблема либо в AMD (нет такого точно не может быть), либо в том, что в proxmox 3.2 поломали поддержку FreeBSD9 (бррр). Долго копал. Потом начал экспериментировать сам. В итоге все таки AMD. Что уж у них там за проблема, но как только я выставил в свойствах ВМ тип процессора Core 2 Duo FreeNAS 9.2 установился без проблем.

Проброс физического диска в KVM (proxmox)


Долго искал ответ на это вопрос на просторах Сети, но находил лишь обрывки. Может кто-то и по ним может сразу понять, что и как, но не я.
В общем делается это так (с консоли):

# nano /etc/pve/nodes/proxmox/qemu-server/100.conf


и добавляете в конце строку:

virtio0: /dev/sdc


где sdc — это ваше устройство. Далее можно через запятую указать прочие параметры (их можно посмотреть в wiki proxmox'а).

Вот и все. Правда не знаю насколько такое подключение поднимает (или опускает) скорость дисковых операций. Тесты у меня еще впереди.
Tags:
Hubs:
+6
Comments 28
Comments Comments 28

Articles