Назад | Перейти на главную страницу

LVM: перемещение физических томов

На виртуальном сервере (Debian GNU / Linux 8 amd64) у меня есть следующие диски и файловые системы:

# pvscan 
  PV /dev/vda1   VG vg0   lvm2 [100.00 GiB / 0    free]
  PV /dev/vdb1   VG vg0   lvm2 [46.56 GiB / 0    free]
  PV /dev/vda2   VG vg0   lvm2 [100.00 GiB / 0    free]
  PV /dev/vdc1   VG vg0   lvm2 [60.00 GiB / 60.00 GiB free]
  Total: 4 [306.55 GiB] / in use: 4 [306.55 GiB] / in no VG: 0 [0   ]

# lvdisplay 
  --- Logical volume ---
  LV Path                /dev/vg0/root
  LV Name                root
  VG Name                vg0
  LV UUID                qpeei3-v1nW-pYVR-lK7Y-4wwy-Y4Y4-c9yQEl
  LV Write Access        read/write
  LV Creation host, time nomos, 2015-03-17 16:34:05 +0100
  LV Status              available
  # open                 1
  LV Size                246.56 GiB
  Current LE             63119
  Segments               3
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/dm-0       243G  135G   98G  59% /
[... no other on-disk filesystems]

Корневая файловая система - ext4.

поскольку /dev/vda достаточно места для всех моих данных, я хочу удалить /dev/vdb и /dev/vdc. Последний используется в качестве временного пространства только для того, чтобы предоставить место для необходимых маневров. Данные о /dev/vdb1 следует переместить в /dev/vda* перед удалением /dev/vdb1. Однако корневая файловая система в настоящее время охватывает все три раздела. /dev/vda1, /dev/vda2 и /dev/vdb1.

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

Я запустил pvmove, чтобы переместить данные с диска:

# pvmove /dev/vdb1 
  Detected pvmove in progress for /dev/vdb1
  /dev/vdb1: Moved: 4.0%

и ждал, пока дойдет до 100%. Однако pvmove переместил данные в /dev/vdc1.

# pvs
  PV         VG   Fmt  Attr PSize   PFree 
  /dev/vda1  vg0  lvm2 a--  100.00g     0 
  /dev/vda2  vg0  lvm2 a--  100.00g     0 
  /dev/vdb1  vg0  lvm2 a--   46.56g 46.56g
  /dev/vdc1  vg0  lvm2 a--   60.00g 13.43g

И сейчас? Я, наверное, мог бы удалить /dev/vdb1, но я застрял со своими данными на /dev/vdc1. На самом деле мне нужно переместить выделенные inodes корневой файловой системы. /dev/vdb1 в свободное пространство файловой системы в /dev/vda*. Тогда я мечтаю, что могу двигаться /dev/vdb1 в сторону, потому что файловая система переехала в /dev/vda*. Я понимаю, что это не работает автоматически, но я не могу представить себе стратегию миграции, которая позволила бы мне сделать это даже вручную, без сжатия корневой файловой системы.

Не могли бы вы помочь, пожалуйста?

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

  1. Рассмотрим плюсы и минусы Btrfs, а также факт он еще не готов к производству (ну, по состоянию на 2015 год, но я не мог найти ничего более свежего по этой теме). Предположим, вы все равно этого хотите.
  2. Резервное копирование резервное копирование
  3. Преобразуйте файловую систему ext4 в Btrfs, потому что Btrfs поддерживает онлайн-миграцию с ext4
  4. Уменьшите новую корневую файловую систему, теперь Btrfs, потому что Btrfs поддерживает сжатие онлайн
  5. Уменьшите объем LVM contaner (vg0 / root)
  6. pvmove data off /dev/vdb1 (теперь vdc1, если учесть, что я уже переместил его в /dev/vdc1)
  7. удалять /dev/vdb1 (или /dev/vdc1)
  8. попрощайся с ext4 навсегда

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

Ваша проблема в том, чтобы resize2fs живую корневую файловую систему и уменьшите ее до 200 ГБ. Один из возможных подходов хорошо изложен в Unix.SE Как уменьшить корневую файловую систему вопрос. Оно использует pivot_root дважды и требует ручного перезапуска большинства процессов и служб ОС; это приводит к потере последних данных, поэтому вы не можете использовать их, если у вас есть действующая база данных; и это, мягко говоря, устрашающе. Но все же это альтернатива, которую люди пробовали с некоторым успехом.

Хорошо, вы извлекли свои данные из vdb1. Сейчас:

  • удалять /dev/vdb1 с помощью vgreduce vg0 /dev/vdb1
  • использовать pvmove удалить данные из/dev/vdc1
  • выпуск vgreduce vg0 /dev/vdc1 удалить его из группы томов

На данный момент ваши данные должны быть только на vda*

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