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

увеличить размер диска - использовать LVM или нет?

Сотрудник спросил меня, почему мы должны использовать LVM. Я сказал, что с моими ограниченными знаниями LVM, потому что это позволяет легко изменять размер / управлять томами!

Его идея такова:

Мы используем ESX, и у нас есть возможность увеличить размер диска. Вместо использования LVM он предложил такой сценарий:

  1. увеличить / dev / sdb на 100 ГБ в клиенте vsphere
  2. обратно в Linux повторно сканировать / dev / sdb: echo 1> / sys / block / sdb / device / rescan
  3. изменить размер ФС онлайн: resize2fs / dev / sdb

Готово.

Вроде нормально. Хотя я не уверен. Что плохого в этом сценарии по сравнению с использованием LVM? Какой лучший вариант для расширения диска?

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

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

Я лично избегаю использования LVM. Может быть, это старый подход, а может, меня избаловали RAID-контроллеры HP SmartArray, но я обнаружил, что могу прогнозировать и планировать потребности в использовании диска в зависимости от требований приложения и среды. В большинстве систем есть один или два «раздела роста», в зависимости от приложения. Это может быть /home для многопользовательской системы. /opt для сервера приложений. /var для системы с большим количеством журналов или /var/lib/pgsql для сервера базы данных ... Раздел, который необходимо увеличить, должен быть последним разделом в таблице или на собственном аппаратном томе.

Также см: Опасности и предостережения LVM

Есть цель для нескольких разделов на основе Стандарт иерархии файловой системы. В приведенном ниже примере /var и /appdata имеют наибольшую активность. /appdata при необходимости настроен на рост. /var имеет достаточно места для циклической регистрации. /usr и /boot не меняйте часто. / может немного увеличиться, но если это станет проблемой, смонтируйте другую файловую систему в этой иерархии. Это довольно последовательно во всех дистрибутивах ОС.

Filesystem            Size  Used Avail Use% Mounted on
/dev/cciss/c0d0p2     9.7G  3.4G  5.9G  37% /
/dev/cciss/c0d0p7     996M   34M  911M   4% /tmp
/dev/cciss/c0d0p6     3.0G 1023M  1.8G  37% /var
/dev/cciss/c0d0p3     5.9G  2.0G  3.6G  37% /usr
/dev/cciss/c0d0p1      99M   23M   71M  25% /boot
/dev/cciss/c0d0p8      79G  6.5G   73G   9% /appdata
tmpfs                 2.4G     0  2.4G   0% /dev/shm

Другой случай для LVM, даже на виртуальном хосте: он позволяет расширить файловую систему на несколько дисков или наборов дисков.

Предположим, вы запускаете ESX без SAN, и в хранилище данных не хватает места для конкретной виртуальной машины, которой требуется больше места; если вы добавляете больше физических дисков, они обычно создают новые хранилища данных, в которые вы можете добавлять виртуальные диски; эти виртуальные диски можно добавить в качестве новых физических томов в вашу группу томов LVM.