Назад |
Перейти на главную страницу
VMware, LVM и Linux: расширение тома… временно и без простоев
Наши уровни хранения следующие в стандартной настройке:
- Вне ОС:
- LUN в сети SAN
- Том VMware VMFS на LUN
- виртуальные диски (VMDK) на VMFS
- Внутри ОС (Linux):
- VMDK соответствует LVM PV (физическому тому) непосредственно на устройстве (без разделов)
- 1 PV = 1 VG = 1 LV, который, наконец, содержит:
- файловая система (ext3)
Обратите внимание, что мы не говорим здесь о корневом диске.
Теперь к вопросу.
Иногда есть пользователи, которым нужно больше места на томе временно. Это означает: они хотят вернуть пространство после того, как закончили. / Я хочу забрать его после того, как они будут готовы.
Некоторые соображения:
- Это не так просто, как создать символическую ссылку на второй том, который мы можем создать временно, чтобы потом снова удалить. Это потому, что иногда заранее неизвестно, где именно требуется место. Кроме того, в этом случае он может быть не на 100% прозрачным, потому что для этого, возможно, придется перемещать данные. Так что я не считаю это приемлемым ответом.
- Я не буду расширять физический том (потому что это потребует увеличения размера VMDK, и вы не сможете легко снова его уменьшить).
- То же самое и с файловой системой.
- Таким образом, единственное решение, похоже, использует уровень LVM, для которого не проблема расширять и сокращать по желанию.
- Но: файловую систему поверх нее можно легко расширить, но не сжать.
Итак, какова была бы возможность делать это на лету и без простоев, таким образом, полностью прозрачно?
Это как раз тот случай, когда нужно лучше спланировать ... И, возможно, улучшить процесс развертывания и подготовки.
LVM поверх VMware немного избыточен, особенно с учетом того, что вы можете добавлять / удалять диски VMDK с тонкой подготовкой на лету. Вы исключили это, но это правильный подход.
Если потребности в хранилище действительно динамические, дополнительный риск изменения устройства LVM и расширения / сжатия файловых систем не стоит того. Возможно, эту проблему можно было решить путем лучшего разбиения.