Ключевые слова:disk, partition, fs, linux, (найти похожие документы)
From: Владимир Холманов <fmfm AT symmetron.msk.ru>
Date: Mon, 28 Feb 2004 14:31:37 +0000 (UTC)
Subject: Разбиение дисков и инсталляция Linux на LVM
Оригинал: http://www.linuxrsp.ru/artic/ch1.html
Разбиение дисков и инсталляция Linux на LVM.
Владимир Холманов (fmfm AT symmetron.msk.ru)
В этой серии из трёх статей рассматриваются некоторые варианты
разбиения диска на разделы для инсталляции Linux и новые возможности
при использовании LVM. LVM (Logical Volume Manager) сравнительно
недавно появившаяся технология, которую часто связывают с "большими
серверными инсталляциями". Цель этой публикации будет достигнута, если
у читателя сложится мнение, что LVM уместен уже при наличии двух hard
дисков.
1. Linux на двух дисковых разделах.
Самый простой вариант подготовки диска для инсталляции Linux - его
разбиение на два раздела: swap и корневой раздел. При этом под swap
отводится место сообразно наличию оперативной памяти, а под корень
"сколько не жалко". Преимущество такого разбиения - минимум
административных действий, поскольку отпадает необходимость делать
прогноз наполняемости файловой системы. При таком разбиении достаточно
учесть следующее.
Для корневого раздела командой fdisk выбрать тип 83 (обычный тип для
Linux) и максимально возможный размер. Рекомендуемая файловая система
- одна из доступных журналируемых, например ext3, reiserfs или xfs. В
случае использования reiserfs обязательна опция монтирования notail в
соответствующей записи файла /etc/fstab.
Для swap раздела выбрать тип 82 (Linux swap), а с размером
определиться из следующих соображений.
- жёсткий лимит снизу. Ядра, начиная с 2.4.10, не могут монтировать
swap, если размер дискового раздела меньше 128 Mb.
- жёсткий лимит сверху. Размер swap не может превышать половины
адресного пространства оперативной памяти. Для i86 при размере
страницы памяти 4 Kb (значение по умолчанию) размер адресного
пространства 4 Gb, а максимальный размер swap, соответственно 2 Gb.
- разумный лимит сверху. По эффективности использования рекомендуется
иметь не более чем swap = 2*RAM. С точки зрения эффективности swap
если и нужен, но в размере близком к лимиту снизу. Разумное исключение
- интенсивное использование tmpfs (/dev/shm).
- ядро умеет балансировать нагрузку для swap между ide каналами (всеми
scsi дисками). На многодисковых машинах хорошо иметь swap разделы на
каждом master ide (каждом scsi) диске и сделать запись в /etc/fstab о
равенстве их приоритетов, например:
/dev/hda5 swap swap defaults,pri=1 0 0
/dev/hdc5 swap swap defaults,pri=1 0 0
Заметьте, лимит снизу становится равным 128 + 128 = 256 Mb.
2. Linux на трех дисковых разделах.
Вместе с первым опытом использования Linux приходит понимание
неудобства инсталляции на два раздела. Следующих шаг в "познании" -
вынос за корневую файловую систему раздела /boot. Раздел /boot самая
критическая часть для загрузки операционной системы и уже по этой
причине достойна отдельной жилплощади. О разделах под swap и root было
сказано выше. Можно только добавить, что, когда /boot выносится на
отдельный раздел и для корневой файловой системы используется
reiserfs, ограничение по notail снимается.
Для /boot раздела следует установить с помощью fdisk обычный тип 83 и
учесть следующее:
- размер определяется расчётом: примерно 3 Mb на ядро при наличии
достаточно большого запаса для столь важного раздела. Как правило,
достаточно 20 - 30 Mb.
- рекомендуемая файловая система - ext2 (журналируемые файловые
системы для карликовых разделов неуместны). Но, если вы оригинал и
общие рекомендации не для вас - используя reiserfs, не забывайте о
notail.
- если пользуетесь загрузчиком GRUB, в целях повышения надежности при
обычной работе следует иметь /boot размонтированным (в случае
использования LILO это не критично, но кому повредит хорошая
привычка). Монтировать раздел следует только при инсталляции нового
ядра или новой схемы загрузки и возвращаться в исходное состояние
после выполнения работ. Запись в /etc/fstab может быть примерно
следующей:
/dev/hda1 /boot ext2 noauto 1 2
- ещё одной хорошей привычкой на многодисковых инсталляциях может
стать резервирование в начале каждого диска небольшого раздела. Даже
если вы в данное время пользуетесь единственным /boot, жертва в 20 -
30 Mb для современных дисков незначительна.
Схему разбиения на три раздела можно признать удачной для однодисковой
рабочей станции. Снимается головная боль по прогнозу наполняемости
разделов, а получить заметный выигрыш от использования современных
технологий на одном диске проблематично. Кроме того, такая схема легко
трансформируется в более приемлемую при добавлении в систему
дополнительных дисков (использование xfs на корневом разделе усложнит
трансформацию).
3. Linux на многодисковой машине.
Появление на машине уже второго диска меняет представление об
оптимальном разбиении. Большой раздел с корневой файловой системой
нужно делить. Кроме того, второй диск (если это scsi или ide-master на
втором канале) наводит на мысль об извлечении выгод от использования
"продвинутых" технологий. Становится возможным для каждой "берлоги"
файлового дерева подобрать индивидуальный оптимизированный рабочий
микроклимат. В первую очередь осознаётся потребность "выноса за
скобки" с корневой файловой системы всего, что не критично для
процесса загрузки. При ближайшем рассмотрении кандидатами становятся
файловые системы /home, /var (эти в первую очередь) и /usr, /opt.
Для корневой файловой системы реально необходимое дисковое
пространство, при условии выноса всего возможного, 120 - 180 Mb, а с
учётом запаса - 250 - 350 Mb. Файловая система журналируемая
(присмотритесь к стабильной ext3 и её data=ordered по умолчанию).
Запись в /etc/fstab может выглядеть примерно так:
/dev/hda6 / ext3 defaults 0 1
Файловые системы /usr и /opt проблем обычно не приносят. Требуемый им
размер дискового пространства относительно стабилен и зависит от
инсталлированного software. С большой долей уверенности можно сказать,
что 2,5 Gb на две файловые системы должно хватить (это для рабочей
станции с GUI, у сервера, не обременённого графикой, запросы
скромнее).
Что касается /home и /var, здесь всё сложнее. Прогноз резервирования
дискового пространства не всегда сбывается. Это основная проблема при
инсталляции Linux на множестве дисковых разделов (на данном шаге мы
рассматриваем необходимость иметь 6 или 7 разделов). Проходит немного
времени после распределения лимитов и фактического разбиения дисков
под прогноз и выясняется, что одни файловые системы близки к
заполнению, другие явно недоиспользуют дисковое пространство. Не всё
так плохо. Если при разбиении диска был допущен просчёт, существует
минимум четыре способа решения проблемы. Назовём их условно так:
"радикальный" (не говорите, что его вам рекомендовали), "сопливый",
"жесткий" и "гибкий". Давайте коротко о перечисленных способах.
К "радикальному" методу я отнёс бы следующее. Резервируется на внешний
носитель вся нужная информация. Делается разбиение под новые
"обстоятельства". Инсталлируется операционная система.
Восстанавливаются зарезервированные данные. Вот так.
"Сопливый" метод следует понимать так. Отдельные подкаталоги
переполненной файловой системы переносятся на незаполненную, а на их
месте создаются гибкие ссылки на вновь созданные. До некоторой степени
это помогает.
Под "жёстким" методом подразумевается применение утилит типа parted.
Parted позволяет производить перепланировку разделов с гарантией
сохранности данных. Жёстким этот метод назван лишь потому, что имеет
некоторые ограничения по типам файловых систем (специфика xfs не
позволит им воспользоваться), двигает "стенки" только между смежными
разделами и бессилен, если разделы находятся на разных дисках. Освойте
этот метод, он пригодится при переходе от схемы "три раздела на одном
диске" к схемам разбиения для нескольких дисков.
"Гибкий" метод предполагает, что возможность возникновения и решения
проблем с дисковыми ресурсами была заложена ещё при инсталляции
системы. При таком подходе вынесенные из корня разделы создаются на
логических томах. Конечно, не всё так просто. Метод подразумевает
освоение новых команд, если точнее, освоение большого числа новых
утилит (как следствие большой гибкости технологии). Затраты времени на
освоение могут окупиться тем, что перепланировка разделов из проблемы
превратится в ещё один системный сервис. Схема разбиения двух дисков с
выносом на логику всего возможного из корневого каталога с точки
зрения "физики" представляет собой linux на четырех симметричных
разделах. Выбирая между linear и striped логикой можно достаточно
полно реализовать преимущества многодисковой инсталляции. В интернете
доступен LVM-HOWTO tldp.org/HOWTO/LVM-HOWTO.html>
В следующей статье будет описание "что было, что стало".
1. Сравнение схем разбиения дисков "три на одном" и "с логикой на двух".
Посмотрим, как выглядит разбиение дисков при инсталляции Linux на три
раздела на одном диске. Схема может выглядеть примерно так.
hda1 hda5 hda6
---- ---- ----
| | |
| | |
| | |
| | |
| | |
boot swap1 root
| | |
| | |
ext2 swap ext3
А теперь схема для инсталляции Linux на два диска с логическими
томами.
И несколько примечаний.
Вместо того чтобы делить дисковое пространство под вынесенные из корня
файловой системы, на дисках hda и hdc создается по одному разделу "на
всё остальное" из расчета, сколько не жалко. Командой fdisk оба
раздела помечены как тип 8e.
Имена "LIN", "tomhome", "tomusr", "tomopt", "tomvar" условны, вы
можете присваивать имена логическим уровням значимые для вашей
инсталляции (в конкретном случае в файле /etc/fstab имена разделов
следует записывать как /dev/LIN/tomhome или /dev/LIN/tomusr ...).
Не существует технических ограничений для перемещения на логику
корневой файловой системы. Но делать этого не стоит, в этом случае
процессы загрузки и восстановления в случае сбоя критически
усложняются. На диске hdc есть симметричный к корневому раздел
(помечен как none). Моё мнение: место "чистому" корневому каталогу на
soft-raid-зеркале с файловой системой ext3. Но это за рамками статьи.
В этом примере подбор типов файловых систем скорее демонстрирует то,
что LVM прозрачен для их драйверов, т.е. драйверы файловых систем не
знают, с чем они фактически взаимодействуют. Подумайте, стоит ли
заводить "файловый зоопарк" или определиться с одним типом
журналируемой fs для нагруженных приложениями файловых систем.
2. Терминология LVM.
VG (volume group) - центральное звено LVM. Группу томов можно понимать
как банк дисковых ресурсов. Вкладчиками такого банка является физика,
а заёмщиками логика. Все команды для этого уровня именуются vgxxxxx.
PV (physical volume). Под физическим томом следует понимать обычное
блочное устройство - целый диск, раздел на диске и т.п. Все команды
для этого уровня именуются pvxxxxx.
LV (logical volume). На логических томах фактически размещаются
файловые системы. Все команды для этого уровня именуются lvxxxxx.
PE (physical extent). Каждый физический том "нарезан" на части (по
умолчанию 4 Mb). Это минимальный размер дискового ресурса, с которым
может оперировать VG (вы можете динамически менять размеры логических
томов на величину, строго кратную PE).
LE (logical extent). Как и для физики, но взгляд с противоположной
стороны (их взаимосвязь называется mapping).
3. Режимы mapping.
Имеется возможность выбрать одну из двух стратегий mapping:
1. Linear (линейный) mapping напрямую соединяет диапазон LE с областью
последовательных PE.
2. Striped mapping имеет дело не только со связыванием LE и PE, но и с
чередующимися между физическими разделами chunks. Считается, что такая
стратегия позволяет увеличить производительность logical volume.
Разумеется, чередующиеся chunks должны находится на разных scsi или
разных ide-master дисках. При этом администрирование логики
усложняется, гибкость инсталляции во многом теряется, а отказ любого
диска создаст проблему всему логическому тому. Планируя переход от
схемы 3 раздела на одном диске на четыре симметричных на двух со
striped логикой, запаситесь tmp диском или выполните backup на внешние
носители.
Raid tools поддерживают как массивы с избыточностью (жёсткие
конструкции повышенной надежности, например, raid1 и raid4/5), так и
массивы без избыточности. Об LVM можно сказать, что технологии
псевдо-raid выделены в отдельный класс и для них созданы утилиты, по
максимуму использующие повышенную гибкость таких конструкций. И ещё.
Складывается впечатление, что не следует смешивать linear и striped в
одной VG (реализация LVM позволяет иметь на одной машине несколько
VG). Если решите использовать обе стратегии, создайте для них
изолированные группы.
4. Snapshots.
Замечательное средство, обеспеченное LVM - snapshots. Это позволяет
администратору создавать новое дополнительное блочное устройство, при
этом логический том просматривается в двух ракурсах - "замороженном"
на определенный момент времени и текущем. При этом алгоритм
функционирования расположенной на томе файловой системы становится
похожим на тот, что используется в файловых системах, "заточенных" под
микросхемы флэш-памяти (примером может служить JFFS2 для linux).
Размер snapshots следует рассчитывать исходя из скорости обновлений и
времени "заморозки". Такой режим может эффективно использоваться для
резервного копирования логического тома в непротиворечивом состоянии
без закрытия приложений, модернизирующих хранящиеся на нем данные. По
окончанию резервного копирования администратор удаляет snapshots.
Требование - кратковременно закрыть приложения в момент создания
snapshots (а затем открыть доступ к тому) и повторное кратковременное
закрытие доступа в момент удаления snapshots. В итоге, общее время
простоя сервера ничтожно мало по сравнению со временем резервного
копирования.
5. Чем придётся пожертвовать?
Вопрос важный. Выигрывая в одном, неизбежно проигрываешь в другом. Как
удобство использования влияет на общую производительность?
Тестирование (сравнивались физика и linear логика) показало следующее.
Перенос файловых систем с физики на логику на скорости операций I/O не
отразился. Другое дело, такой перенос для всех типов тестируемых
файловых систем (ext3, reiserfs, xfs) повысил нагрузку на процессор
примерно на 10% - 15%. Тесты не претендовали на академичность и могут
дать иной результат на другом железе, но некоторое представление о
предмете дают. Общий вывод такой: подбор файловых систем более
критичен для производительности, чем переход с физики на логику.
Интересно было бы видеть результаты тестов для striped логики.
6. Логические тома и файловые системы.
Как уже говорилось, LVM прозрачен для драйверов файловых систем. С
другой стороны, а все ли файловые системы в одинаковой мере способны
извлекать выгоду от расположения на логике? Интересно знать ответы на
следующие вопросы. Способна ли файловая система расширяться -
усекаться? До какой степени от первоначального размера можно расширить
- усечь файловую систему, не волнуясь за последствия? Позволяет ли
файловая система менять свой размер без размонтирования и остановки
работающих приложений? Попытка дать ответы на эти вопросы для файловых
систем ext2/3, reiserfs, xfs будет предпринята в следующей статье.
1. Общий взгляд на процедуру resizefs.
В общем виде пошаговая инструкция расширения файловой системы на
логическом томе выглядит так.
* увеличиваем размер логического тома на необходимую величину.
* расширяем файловую систему до заполнения всего тома.
Пошаговая инструкция по усечению файловой системы имеет обратную
последовательность.
* усекаем файловую систему до нужного размера.
* усекаем логический том под новый размер файловой системы.
Подобная инструкция предполагает точный расчёт, на практике
предпочтение следует отдать трех шаговому решению.
* усекаем файловую систему "с запасом".
* усекаем логический том до нужного размера.
* расширяем файловую систему до заполнения всего тома.
Асимметрия по уровню сложности подводит к мысли, что, создавая
логические тома лучше "недосолить", чем "пересолить". Расширить том и
находящуюся на нём файловую систему труда не составит (не все файловые
системы поддерживают усечение, а где эта функция есть, сохранность
находящихся в файловой системе данных подвергается более высокому
риску). Уровень VG позволяет иметь "золотой запас" дисковых ресурсов и
следует приучить себя его иметь. Это может потребоваться не только для
resize файловых систем, но и при появлении bad блоков, для создания
snapshots и внеплановых разделов, для смены версий и типов файловых
систем. Если ёмкость дисков позволяет, имейте запас превышающий размер
самой большой файловой системы.
2. Расширение и усечение логического тома.
Увеличить существующий логический том (при наличии резерва у VG) можно
либо указав его новый размер, или указав на какую величину необходимо
расшириться. Команды будут следующими:
# lvextend -L3G /dev/LIN/tomusr
или
# lvextend -L+1G /dev/LIN/tomusr
В первом случае новый размер тома станет 3 Gb, во втором увеличится на
1 Gb (если первоначальный размер 2 Gb обе команды эквивалентны).
Первая команда может как расширить, так и усечь существующий том, во
втором случае для усечения достаточно поменять lvextend на:
# lvreduce -L-1G /dev/LIN/tomusr.
3. Файловая система ext2/3 и LVM.
В первозданном виде файловая система ext2 требует размонтирования
перед операциями resize. Однако имеется patch (ext2online), снимающий
это ограничение. Узнайте у поставщика вашего дистрибутива,
поддерживает ли это ваше ядро. Увеличить размер non-patch ext2 под
новый размер логического тома можно следующей последовательностью
команд:
# umount /dev/LIN/tomusr
# lvextend -L+1G /dev/LIN/tomusr
# resize2fs /dev/LIN/tomusr
# mount /dev/LIN/tomusr /usr
Для усечения ext2 командой resize2fs следует отказаться от умолчания
(по умолчанию файловая система заполняет весь имеющийся объём) и
передать в виде параметра новый размер в файловых блоках:
# umount /usr
# resize2fs /dev/LIN/tomusr 54000
# lvreduce -L-1G /dev/LIN/tomusr
# resize2fs /dev/LIN/tomusr
# mount /usr
Обратите внимание, промежуточный размер файловой системы должен быть
заведомо меньшим, чем новый размер логического тома, но достаточным
для сохранения имеющихся данных.
Ещё одно замечание для классики. При создании ext2 определяется
статический набор inodes, по умолчанию оптимизированный под размер
файловой системы. При увеличении файловой системы может наблюдаться
дефицит inodes, а при усечении их избыток. Критически относитесь к
тому, в каких пределах можно расширять и усекать файловую классику.
4. Файловая система reiserfs и LVM.
Файловая система reiserfs может расширяться как в смонтированном, так
и в размонтированном состоянии. Выбирайте как вам удобнее. Для
увеличения размера:
# lvextend -L+3G /dev/LIN/tomhome
# resize_reiserfs -f /dev/LIN/tomhome
или
# umount /dev/LIN/tomhome
# lvextend -L+3G /dev/LIN/tomhome
# resize_reiserfs -f /dev/LIN/tomhome
# mount -treiserfs /dev/LIN/tomhome /home
Операция по уменьшению размера логического тома и файловой системы
технически более сложная и может выполняться только на
размонтированной fs.
# umount /home
# resize_reiserfs -s-4G /dev/LIN/tomhome
# lvreduce -L-3G /dev/LIN/tomhome
# resize_reiserfs -f /dev/LIN/tomhome
# mount -treiserfs /dev/LIN/tomhome /home
Замечание по промежуточному размеру файловой системы остаются в силе
(обратите внимание, reiserfs понимает размер не в блоках). Файловые
inodes создаются динамически по необходимости. Вы можете создать
файловую систему размером 1 Gb и в дальнейшем растянуть её хоть на 100
Gb, при этом, не нарушив баланса между управляющими структурами и
блоками данных.
5. Файловая система xfs и LVM.
Файловая система xfs в настоящее время не может усекаться (для
серверов это не критично, для АРМ может представлять проблему).
Увеличение размера происходит в смонтированном состоянии. Обратите
внимание, в качестве аргумента следует передавать строго точку
монтирования, но не имя устройства.
# lvextend -L+3G /dev/LIN/tomvar
# xfs_growfs /var
У команды xfs_growfs имеется множество опций. Ознакомьтесь с ними
внимательно и разберитесь в особенностях этой сложной и
высокопроизводительной файловой системы перед началом работы.
6. С чего лучше начать.
Обычно знакомство со всем новым начинается с того, как это новое
создать и удалить. В случае с LVM классическое знакомство может
запутать. Прежде чем приступить к чтению man pages и howto, уясните,
какое значение в логике имеет "включить" и "выключить".
Создав все объекты для логики (последовательно, PV, VG, LV) и
перезагрузив машину, можно испытать чувство дискомфорта, обнаружив,
что всё недавно созданное вдруг стало недоступным. Одна из интересных
и пугающих особенностей LVM в том, что логику перед началом работы
необходимо активизировать. Файловые системы на логических томах могут
находиться в трёх состояниях.
* файловая система смонтирована на активном логическом томе.
* файловая система размонтирована на активном логическом томе.
* файловая система размонтирована на неактивном логическом томе.
Те или иные административные работы с логикой могут требовать одного
из трёх перечисленных статусов.
Процесс перевода логики из неактивного состояния в активный и обратно
несимметричен (обычно выполняется автоматически при загрузке и
остановке). Для активизации группы логических томов требуется две
команды, обратный процесс выполняется одной. Активизации VG
достигается последовательностью:
# vgscan
# vgchange -a y LIN
Первая команда самая загадочная. Она сканирует дескрипторы дисков и
дисковых разделов, загружает драйверы для логики (в файловой системе
/proc появляется подкаталог lvm), переписывает несколько текстовых и
индексных файлов в подкаталоге /etc и возвращает код возврата "1" в
случае успеха. В автоматических сценариях код возврата "1" обычно
является условием для запуска второй команды. Аргумент "y" (иначе Yes)
во второй команде - указание активизировать VG по имени "LIN" ("n",
иначе "No", снимет флаг активности с группы при условии, что все
находящиеся на логических томах файловые системы размонтированы).
7. Эффект "хорошего соседа".
Для чего каждый раз перечитывать дисковые дескрипторы? Не будет ли
достаточным создавать все необходимые структуры данных при создании
логики и в дальнейшем ими пользоваться? Ведь пересоздание всех
структур каждый раз с нуля сильно усложняет реализацию логики и работу
с ней. Хорошо, допустим, на диске только одна операционная система и
только в ней производится разбиение диска. Тогда такое поведение
действительно нелогично. А если операционных систем несколько? А если
имеются схемы загрузки на разные корневые файловые системы? А если
диски переносились с одной машины на другую? Ни при каких
обстоятельствах Linux не создаст проблем для своих соседей. И одно
очень большое предупреждение. Опасайтесь использовать логику из
операционных систем сомнительного качества.
8. Заключение.
Администратор имеет возможность выбирать не только между типами
файловых систем с разными соотношениями надежности и скорости, но и
использовать технологии, дополнительно влияющие на производительность
и надежность. Зачем такое разнообразие? Неужели не существует одной,
наилучшей рекомендации? Рекомендация есть - разбиение файловой системы
linux на разделы. Заметьте, файлы в linux размещаются в дереве не по
принципу принадлежности к тому или иному packages, а по
функциональному назначению. Для каждой ветви файловой системы из
имеющихся технологий можно подобрать наиболее приемлемую по комбинации
свойств. Заканчиваю цитатой от - Крис Торек - "У UNIX есть свои
недостатки, но файловая система к ним не относится".
