Novell уволила разработчиков AppArmor

Зачем нужна AppArmor?

AppArmor – это реализация мандатного контроля доступа для Linux-систем. Не будем вдаваться глубоко в технические детали. Скажем лишь, что мандатный контроль доступа позволяет достичь уровня безопасности, принципиально невозможного для традиционного (дискреционного) контроля доступа, используемого в подавляющем большинстве современных операционных систем.

В частности, системы мандатного контроля доступа используют правительственные и военные организации для строгого разграничения доступа к секретной информации.

История и нынешнее состояние AppArmor

Технологическая основа AppArmor была создана небольшой компанией Immunix, специализировавшейся на разработке решений для обеспечения безопасности Linux-систем.

В 2005 году Immunix была куплена Novell, после чего продукт был переименован в Novell AppArmor, а ключевые разработчики продолжили работу над ним уже как сотрудники Novell. Этот факт позволил Novell включить AppArmor в свой дистрибутив SuSe Linux и обеспечить его поддержку.

Смогла ли бы Novell обеспечить поддержку AppArmor, не имея его разработчиков в штате? Вряд ли. Мандатный контроль доступа – не только очень мощная технология, но и достаточно сложная. AppArmor всегда позиционировался как простая в использовании система мандатного контроля доступа. Но относительно простая она лишь для пользователя, в разработке и поддержке она ничуть не проще любой другой.

На сегодняшний день AppArmor стал достаточно популярен. В частности, Canonical включила его в новую версию дистрибутива Ubuntu, а Mandriva – в Mandriva Linux 2008. Казалось бы, решение пользуется популярностью, и логично развивать и продвигать его дальше.

Но тут Novell увольняет пятерых ключевых разработчиков, включая лидера проекта (подробнее - http://www.news.com/8301-13580_3-9796140-39.html).

Войдет ли AppArmor в следующие версии SuSe?

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

Возможно ли это? Включать обновленный AppArmor в дистрибутив – конечно да. А вот обеспечить адекватную поддержку комплексной технологии, не имея ее разработчиков в штате, крайне сложно.

Главный вопрос. Почему Novell так поступила? В чем смысл происходящего?

Не претендуя на абсолютную точность, рискнем все же сделать достаточно очевидные выводы. Похоже, Novell не заинтересована в AppArmor и избавилась от этого направления разработки как от непрофильного актива.

Дело в том, что на сегодняшний день существует две системы мандатного контроля доступа – SELinux и AppArmor. Первая из них рассчитана на предельную строгость. Вторая – на простоту настройки. Но простота настройки – явно не первоочередная задача, когда речь идет о системе мандатного контроля доступа. Поэтому подавляющее большинство серьезных внедрений основано на SELinux. AppArmor же используется, как правило, для тестирования и изучения поведения приложений.

Видимо, Novell решила, что в такой ситуации вкладывать силы в развитие проекта не имеет смысла, и предпочла сконцентрироваться на других направлениях.

Какое будущее ждет AppArmor?

Уволенные разработчики заявляют о том, что не собираются бросать проект. На сегодняшний день они создали компанию Mercenary Linux (http://www.mercenarylinux.com/), которая будет разрабатывать AppArmor и оказывать консультации по его использованию. Так как именно эти люди создали AppArmor и координировали его разработку все последние годы, их позиция абсолютно логична и понятна. Если они сейчас перестанут поддерживать проект, велик риск того, что пока вокруг него будет формироваться новая команда, он отстанет в своем развитии от аналогов и будет забыт.

Кроме того, разработчики заявили, что если какая-либо компания заинтересована в развитии AppArmor и хочет приобрести Mercenary Linux, то они всегда готовы обсудить честные предложения.

Сетевые файловый системы

Введение

Идея сетевых файловых систем далеко не нова. Далеко не нова - это значит, что первые реализации файловых систем, внешних по отношению к физическим ЭВМ, появилась в начале 80х - это файловые системы для VAX-VMS кластеров. Эту идею развивали многие компании, в результате чего мы по сути имеем несколько фундаментальных концептов разделяемых файловых систем, не говоря уже о количестве конкретных реализаций данных концептов. Фундаментальные концепты включают сетевые файловые системы (NFS), параллельные файловые системы (Lustre) и симметричные блочно-разделяемые файловые системы (GFS и иже с ними).

Сетевые файловые системы (NFS)

Сетевая файловая система (NFS) - достаточно простое, дешевое и привычное в мире Unix решение для организации разделяемых данных. Спецификации (как и многие реализации) NFS имеют прямое отношение к SUN Microsystems. Всего существует 4 различных спецификации протокола NFS, хотя первая его версия так и не вышла в свет, оставшись навсегда во внутренних тестовых лабораториях SUN. Поэтому наш обзор мы начнем с NFSv2. Напомним, что это концепт удаленной файловой системы, предоставляющей доступ на файловом уровне.

NFSv2

Спецификация NFSv2, выпущенная в далеком 1989 году, полагалась исключительно на UDP в качестве транспортного протокола. Это позволяло создать достаточно простой сервер, который не имел внутреннего состояния (Stateless), что, соответственно, не давало никаких гарантий транзакционности файловых операций (например потому, что файловые операции могли выполняться сервером в порядке дохождения пакетов, который, вообще говоря, может отличаться от порядка операций, задуманного клиентом). Файловые блокировки также были реализованы вне основного протокола, что существенно ограничивало производительность. В частности, многие реализации просто начинали poll'ить заблокированный файл, создавая паразитный трафик и ненужную нагрузку на сервер. Добавим сюда абсолютное отсутствие аутентификации клиента на сервере (мы же не полагаемся на IP-адрес, как на данные аутентификации, правда?) и предположение об однородном пространстве соответствий пользователей и их идентификаторов, что принято было обеспечивать с помощью, мягко говоря, не самого безопасного протокола - NIS, и мы поймем, насколько эта версия NFS слаба и незащищена.

Итого, из плюсов системы можно отметить только:

1. Простоту реализации и развертывания
2. Абсолютную индифферентность "сервера-без-состояния" к происходящему в сети. Например, клиент запросто мог перезагрузиться и продолжить запись в файл как ни в чем ни бывало.

Зато из недостатков:

1. Фактическое отсутствие контроля доступа и шифрования информации.
2. Необходимость использования в "доверенной сети".
3. Необходимость централизации пользовательской информации.
4. Отсутствие транзакционности.
5. Отсутствие поддержки блокировок.
6. Поддержка исключительно синхронных операций записи.
   

NFSv3

Спецификация NFSv3 вышла в чуть менее далеком 95м, хотя, наверное, это знаменательное событие было несколько оттенено запуском Windows 95 =). В новой (по тем временам) спецификации было 4 фундаментальных преимущества перед версией v2. Вот они:

1. Возможность использовать TCP в качестве транспортного протокола.
2. Возможность использовать 64-битные размеры и смещения в файлах, что позволяло использовать большие файлы (более 4Гб).
3. Поддержка асинхронного ввода-вывода.
   
4. Реализация файловых блокировок в протоколе.
   

Остальные фундаментальные недостатки, вроде абсолютного отсутствия аутентификации и необходимости использовать централизованный сервис предоставления пользовательской информации, никуда не делись.

NFSv4 aka текущая версия

Данная спецификация была разработана в 2000 году и пересмотрена в 2003. В то время спецификация уже вышла из-под контроля SUN (как в свое время сделали немало других спецификаций, например, спецификации Java). Из принципиальных улучшений стоит отметить:

1. Поддержку аутентификации хостов и пользователей (например, средствами Kerberos).
2. Поддержку шифрования информации.
   
3. Поддержку "продвинутых" методов клиентского кэширования.

В спецификации есть дополнительно много мелких улучшений (со списком можно ознакомиться в RFC3530).

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

Параллельные файловые системы (Lustre)

Авторы утверждают, что название этой файловой системы произошло от смешения слов Linux и cluster, хотя лично нам аналогия с люстрой кажется несколько более очевидной. Это файловая система обладает максимальной производительностью, масштабируемостью и является наиболее успешным примером файловой системы, которая, например, используется в MPP-системах, таких как вычислительные кластера. Это байт-ориентированная файловая система. Принцип устройства файловой системы достаточно комплексен, так что рекомендую читать более одного раза =). Базовых компонент три:

1. Сервер метаданных (возможно с активным/пассивным резервированием). Данный сервис отвечает за метаданные, такие как структура директорий, атрибуты и имена файлов, а также указывает на положение "объектов", составляющих файл, на экземплярах следующей компоненты.
2. Сервер хранения. Это сервер, к которому может быть подключено несколько "целей хранения", или, если по простому, блочных устройств. В настоящее время на этих блочных устройствах используется несколько видоизмененная файловая система ext3 для хранения объектов. Типичная конфигурация сервера хранения предусматривает наличие от 2-х до 8-ми "целей", каждая объемом до 8 Тб. Общий объем файловой системы равен сумме объемов целей, ее составляющих.
3. Клиент. Без особых комментариев. Клиент находит необходимый ему файл (а точнее, объекты его составляющие), пользуясь сервером метаданных. Затем блокирует определенный диапазон смещений внутри файла и обращается к серверам хранения, которые непосредственно модифицируют данные на своих "дисках".

При подобной инфраструктуре выдерживается также следующее правило: если файл влезает в один "объект", то этот объект хранится на одном сервере, в противном случае производится stripping файла между несколькими серверами, что, во-первых, позволяет избежать ограничений объема единичных устройств, и, во-вторых, разнести нагрузку.

Подобный концепт обеспечивает наилучшую масштабируемость и производительность, за что Lustre снискала немалую популярность в научном мире (Lustre используется в 30 из top 50 суперкомпьютеров). Однако для бизнеса это решение не очень подходит, потому что требует солидного количества аппаратуры для работы, а значит - излишне громоздко для типичных бизнес-задач, вроде кластера СУБД. Для подобных задач остроумные люди придумали симметричные разделяемые (кластерные) файловые системы с доступом к устройству хранения на блочном уровне.

Симметричные ФС с разделяемым диском (GFS, GFS2...)

Подобные файловые системы характеризуются отсутствием функционального разделения узлов с одной стороны, и достаточно высокой производительностью - с другой. Принцип действия данных систем следующий:

• Могут использоваться любые протоколы доступа к разделяемому блочному устройству, будь то стандартные (FC, iSCSI) или софтверные линуксоспецифичные (GNBD). Естественно, каждый из методов обладает своими преимуществами и недостатками.
• Должны использоваться кластерные службы, в частности, cman (задача - обеспечение функционирования распределенного менеджера блокировок), fence (задача - "отсечение" некорректно работающих узлов от данных и восстановление).
• Для управления хранилищем данных обычно используется CLVM, кластерный вариант управления логическими томами от Red Hat. Принцип действия, за исключением блокировок, тот же самый, что был описан в предыдущих постах для LVM.
• Используется журналирование метаданных и данных, что обеспечивает, соответственно, целостность файловой системы/даных.
  

Общий алгоритм работы выглядит следующим образом:

• Каждый узел занимает свой индивидуальный журнал.
• Информация о блокировках распределена между узлами. В нормальном положении все узлы в курсе всех блокировок.
• Узлы открывают файлы и работают с данными. При этом клиенты осуществляют прямой параллельный доступ к ФС, работая с данными на блочном уровне.
• ФС поддерживает изменение размеров (только в большую сторону) без отключения.
  

В случае отказа одного из услов происходит горячее восстановление по следующему алгоритму:

1. Узел "убивается" (fence). Обычно это осуществляется физическим отключением питания, используя какие-либо сетевые устройства (APC, HP iLO,...).
2. Один из узлов в кластере завершает свои операции и освобождает свой журнал, забирая себе журнал сбойного узла.
3. Операции по журналу сбойного узла откатываются/завершаются и система продолжает функционировать как ни в чем ни бывало.

При всем при этом производительность решения с параллельной симметричной блочной ФС выше, чем у NFS, не требуя при этом того колчества доп. аппаратуры, которое используется в Lustre. GFS давно стала привычной технологией для решения бизнес-задач, вроде организации кластеров СУБД, благодаря некоторым расширениям POSIX, которые предоставляет GFS, как-то:

• Direct I/O - синхронный режим записи на диск для определенных файлов.
• Freeze/Unfreeze - возможность приостановить работу с FS (корректно "подвесив" системные вызовы на прочих узлав) с одного узла (например, для нужд обслуживания).
• CDPN (Context Depending Path Names - контекстно-зависимые пути к файлам), позволяющий хранить данные, специфичные для узла, на общей файловой системе.

К сожалению, первая версия GFS не была лишена недостатков. К числу их можно отнести:

1. Хранение журналов "рядом" с файловой системой, а не на ней. Это приводило к ситуации, в которой нельзя было увеличить количество журналов, не уменьшив объем файловой системы (что, напомним, делать онлайн нельзя), либо не увеличив размер логического тома.
2. Отсутствие поддержки хранения информации SELinux (контекстов файлов).
3. Падение производительности при работе с большим количеством мелких файлов.

Эти недостатки были исправлены в этом году с выпуском версии GFS2.

Резюме.

В Linux наблюдается огромное разнообразие (многие считают его избытком) поддерживаемых файловых систем, локальных и сетевых. Причем в отношении сетевых ФС в полной мере справедливо правило UNIX: каждый инструмент решает свою четко очерченную задачу. В этом плане сетевые файловые системы (NFS) удобно использовать для небольшого количества клиентов и интенсивного ввода/вывода, GFS - для интенсивных задач ввода/вывода в масштабах типичного бизнес-кластера, а Lustre - для MPP-систем.

Области применения виртуализации. Часть 1.

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

Общепринятая точка зрения на виртуализацию – она ведет к некоторым потерям производительности, впрочем, вполне терпимым. Но при этом дает значительные преимущества при обслуживании систем и позволяет строить более гибкую инфраструктуру.

На самом деле в некоторых ситуациях виртуализация позволяет увеличить производительность приложений. Не торопитесь кричать «Бред!», дочитайте сначала до конца.

Подход к увеличению производительности

В течении уже многих лет инженеры Red Hat и Intel совместно работают над оптимизацией работы Red Hat Enterprise Linux на оборудовании Intel. В последнее время они работали над поддержкой новейших платформ Intel Caneland на базе четырехядерных процессоров Tigerton. В результате эти системы будут полностью поддерживаться в Red Hat Enterprise Linux 5.1, выходящем в октябре 2007г. Предварительные тесты показывают просто фантастическую производительность.

Кроме того, в Red Hat Enterprise Linux 5.1 войдут паравиртуализованные драйвера для полностью виртуализованных гостевых систем. Эти драйвера позволяют полностью виртуализованным гостевым системам практически достичь производительности паравиртуализованных. На сегодняшний день готовы драйвера для Red Hat Enterprise Linux 3 и решается вопрос о драйверах для операционных систем других производителей.

Таким образом, возможно развернуть весь стек приложений, основанный на Red Hat Enterprise Linux 3, в гостевой системе на новейшей платформе Caneland и таким образом добиться значительного прироста производительности.

Зачем здесь вообще виртуализация? Дело в том, что старые системы не поддерживают новое оборудование. А для переноса полного стека приложений на Red Hat Enterprise Linux 5 время и ресурсы есть не всегда.

Тесты производительности

Разумеется, мало сформулировать подход, надо еще и доказать его состоятельность. По запросу Red Hat и Intel независимая лаборатория Principled Technologies провела тесты производительности изложенного выше подхода.

Полный отчет о тестах SPECjbb2005, SPECcpu2006 и Linpack Вы можете найти на http://www.principledtechnologies.com/clients/reports/Red%20Hat/RHEL51_VirtReps.htm

Если же в двух словах, то, например, тест SPECjbb2005 показал следующее:

• Система на процессорах Xeon и Red Hat Enterprise Linux 3 показала результат 210,000 операций в секунду (4 двухядерных процессора, гипертрединг, в итоге 16 исполняемых нитей).

• Система на основе Caneland и Red Hat Enterprise Linux 5 показала результат 380,000 операций в секунду (4 четырехядерных процессора, также 16 нитей).

• Гостевая система Red Hat Enterprise Linux 3 на хост-системе на основе Caneland и Red Hat Enterprise Linux 5 показала результат 340,000 операций в секунду.

Таким образом, использование виртуализованного Red Hat Enterprise Linux 3 на Caneland-системе позволило получить прирост производительности более 50%.

Комментарии

Очевидно, что прирост производительность обусловлен не виртуализацией как таковой, а использованием более современного оборудования. Собственно, это очевидно – закон Мура никто не отменял. Но принципиально новым является то, что использование виртуализации позволяет быстро и беспроблемно получить отдачу от закона Мура – не требуется перенос приложений на новую систему.

Отдельно стоит отметить, что при решении подобных задач решения на основе Xen оказываются гораздо эффективнее, чем на основе VMware. Дело в том, что VMware не поддерживает для одной гостевой системы более 4 исполняемых нитей. То есть VMware может использовать не более четверти мощности Caneland-систем. Xen же позволяет использовать мощность нового оборудования на 100%.

Где это будет востребовано

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

Яркий пример – САПР. В этой области отладка программ и введение в промышленную эксплуатацию вычислительного комплекса может занимать до нескольких лет. Поэтому возможности быстро перенести приложения на новую систему нет. При этом вопросы производительности в задачах САПР стоят очень остро.

Крайне похоже обстоит дело с корпоративными системами на базе Oracle или SAP – их внедрение процесс длительный и дорогостоящий, поэтому любая миграция оказывается крайне болезненной.

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

Microsoft проиграла иск в Евросоюзе

О чем вообще речь?

Microsoft проиграла иск в европейском суде первой инстанции. Суть иска заключалась в том, что Microsoft злоупотребляла своим доминирующим положением на рынке ПО с целью не допустить появления конкурентов.

Публикации об этом иске в прессе часто сводятся к тому, что Microsoft включала в Windows свой медиаплеер, тем самым принуждая пользователей покупать его вместе с операционной системой и создавая неравные условия для разработчиков всех остальных плееров.

На самом деле история про медиаплеер – далеко не самая важная часть иска. А наложенные на Microsoft штрафы в несколько сот миллионов долларов – не самая важная часть судебного решения. Просто история про плеер и штрафы проще и понятнее для большинства авторов статей, поэтому о них и пишут.

Но на самом деле основной вопрос разбирательства – информация о интерфейсах сетевого взаимодействия Windows-систем и о протоколах CIFS. Эта информация критична для нормального взаимодействия Linux и Windows-систем. А актуальность этой проблемы очевидна всякому, кто пробовал, например, интегрировать Linux-системы с Active Directory. На сегодняшний день это достаточно трудоемкая задача, требующая немалого объема знаний.

Казалось бы – откуда вообще возникает проблема? А дело именно в том, что Microsoft не раскрывает протоколов взаимодействия. Более того, она регулярно их меняет. И до тех пор пока команда проекта Samba (цель которого – как раз организация взаимодействия Linux и Windows-миров) вынуждена получать информацию о протоколах взаимодействия методами reverse engineering и постоянно отслеживать их изменения, проблема окончательно решена не будет.

Учитывая то, что Samba используется в серверах рабочих групп Sun, Novell, IBM, Apple, в подавляющем большинстве NAS дешевле $5000, становится ясен истинный масштаб вопроса – и он гораздо серьезнее, чем интеграция медиаплеера в операционную систему. По сути, вопрос предоставления или не предоставления информации о протоколах взаимодействия – это вопрос того, сможет ли хоть одна компания работать с любыми сетевыми решениями, не заплатив предварительно Misrosoft.

Что решил суд?

По решению суда Microsoft обязана предоставить требуемую информацию. По законом Евросоюза интерфейсы в отличии от конкретной их реализации не защищаются копирайтами.

Это победа?

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

Что самое интересное, по сути против корпорации боролись всего несколько человек – команда проекта Samba, которую юридически в суде представляли FSF Europe и итальянский юрист Carlo Piana. И они победили.

И никаких проблем больше не предвидится?

А вот этого никто не обещал. Мало выиграть дело в суде, теперь надо реально получить от Microsoft информацию.

Основная проблема в том, что несколько лет назад, после решения еврокомиссии 2004 года, Microsoft пыталась предоставить требуемую документацию. И не смогла – участники программы MCPP (программа лицензирования протоколов) заявили, что в рамках программы они не получить никакой новой информации по сравнению с тем, что знали до вступления в программу. Получается, что у Microsoft просто нет полноценной документации собственной реализации протоколов взаимодействия даже для избранных партнеров.

Ощущение такое, что Microsoft может собрать требуемую информацию только путем reverse engineering`а собственного кода.

Что в итоге?

Борьба не закончена, но пройден крайне важный этап. Если Microsoft хочет остаться на рынке Евросоюза, ей придется пойти на компромисс и все же предоставить требуемую информацию. И это крайне важный прецедент. Впервые компанию-монополиста (будем называть вещи своими именами) обязали предоставить информацию, необходимую для появления честной конкуренции.

Даже если исполнения решения суда затянется, важен уже сам его факт. Кроме того, если Microsoft потребуется неадекватно большое время на предоставления документации по реализации собственных протоколов, это будет сильным аргументом против OpenXML во время окончательного голосования по нему. В самом деле, стоит ли стандартизировать форматы компании, которая не может предоставить документацию на собственную их реализацию?

Дополнительная информация

Пресс-релиз Samba и FSFE:

http://mail.fsfeurope.org/pipermail/press-release/2007q3/000186.html

Интервью с людьми, внесшими основной вклад в победу:

http://www.groklaw.net/article.php?story=20070919214307459

(Крайне рекомендуется к прочтению! Очень хорошо написано и рассказано об очень многих деталях того, как реально выглядел весь процесс изнутри.)

LVM. Управление Логическими Томами

Введение

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

1. Размер создаваемой единицы хранения данных ограничен размером физического диска. (или RAID-массива, что немногим лучше)


2. Ограничены возможности управления хранилищем.
   


3. Отсутствует возможность он-лайн увеличения хранилища.
   


4. Отсутствуют встроенные возможности обеспечения избыточности (здесь мы имеем ввиду средства разбиения, а не Linux software RAID).
   


5. Отсутствует гибкость проведения он-лайн архивирования системы с динамично меняющимися данными.
   


6. Сложности с динамическим именованием устройств, хотя они и несколько обходятся с помощью UDEV и монтирования по меткам.
   

Все эти (а на самом деле не только эти) проблемы решены в системе, получившей название LVM (Logical Volume Management), которая уже давно является частью "Ванильного" ядра Linux. Эта система делает управление данными под Linux "просто сказкой". Если вы еще не знакомы с ней - самое время. Как обычно, все примеры приведены для системы RHEL5, но, скорее всего, с минимальными изменениями будут работать в других дистрибутивах.

Условные обозначения

1. Физический том (Physical Volume, или PV) - специальным образом отформатированное блочное устройство. Может быть как диском целиком, так и партицией, MD-устройством и т.д.
   


2. Логическая группа (Volume Group, или VG) - по сути "пул ресурсов". Имеет логическое и физическое представление. С физической точки зрения является объединением физических томов, с логической точки зрения является "емкостью", из которой "разливаются" логические тома.
   


3. Логический том (Logical Volume, или LV) - собственно логическая "партиция", расположенная на логической группе.
   

Основы практической работы

Работает все это следующим образом. Физические партиции форматируются в физические тома, например вот так:

 # pvcreate /dev/sda

После команды pvcreate могут вообще говоря следовать несколько блочных устройств. В этом случае все они будут отформатированы как PV. Затем следует объединить физические тома в логические группы. Для начала мы сделаем группу, состоящую только из одного PV:

 # vgcreate -s 32M vg0 /dev/sda

По сути, единственный актуальный параметр - это так называемый Physical Extent Size. Он определяет "квант" места, то есть единицу, до которой округляются все размеры логических томов. По сути Extent - это "клеточка", в которую "разлинована" ваша логическая группа.
После того, как мы сделали логическую группу, время создать логические тома:

 # lvcreate -L10G -n lvol vg

Последняя команда создает логический том в группе vg0. Она имеет множество опций, самые важные, впрочем, это -L РАЗМЕР -n ИМЯ. Возможно также задать политику расположения (аллокации) логических экстентов на физических, сделать LV "зеркалируемым" или "черезполосным" (Stripped - аналог RAID0).
Теперь самое время отформатировать логический том нашей любимой файловой системой EXT3:

 # mkfs.ext3 /dev/vg0/lvol

Обычно в Red Hat Enterprise Linux симлинки на логические тома доступны по пути /dev/[лог. группа]/[лог. том].
Допустим, что позднее мы добавляем в систему еще одно блочное устройство /dev/sdb. Причем хотим не просто добавить, а использовать его как "расширение" уже имеющегося хранилища, желательно в рамках той же файловой системы и без остановки приложений. Делается это следующим образом: форматируем новое устройство как физизческий том:

 # pvcreate /dev/sdb

Расширяем имеющуюся логическую группу, вводя в нее новорожденный физический том:

 # vgextend vg0 /dev/sdb

Расширяем логический том, добавляя, например, еще 10Gb места:

 # lvextend -L +10G /dev/vg0/lvol

После чего осталось лишь расширить файловую систему на устройстве. К счастью для нас файловая система Ext3 (как впрочем и GFS) поддерживает online resize в большую сторону.

 # resize2fs /dev/vg0/lvol.

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

Принципы устройства и прочие возможности

Теперь вернемся к теории и рассмотрим, как же это работает, и какие выгоды теоретически достижимы. Принцип устройства логических томов очень похож на принципы устройства виртуальной памяти в современных ОС. Дисковое пространство "нарезается" на экстенты. Далее логическим экстентам ставятся в соответствие физические, в соответствие с политикой аллокации. То есть весь концепт логического управления томами идейно - не более чем игра с соответствиями логических и физических единиц.

Допустим, каждому выделяемому логическому экстенту ставятся в соответствие 2 физических, убеждаясь при этом, что они расположены на разных физических томах. Получается естественный метод "зеркалирования", то есть функциональность RAID1. Это все просто и интересно, но не самое оригинальное и не это самое прекрасное в LVM.

Прекрасно то, что можно, не прерывая доступа к данным, "передвинуть" занятые физические экстенты на другие физические тома, тем самым освободив физический драйв от данных. Как вам перспектива замены жестких дисков под системным разделом в процессе работы системы (убедитесь, что ваши HDD поддерживают HotPlug =))) )?

Прекрасно то, что LVM "собирается" каждый раз по UUID-идентификаторам, которые расположены на самих разделах. LVM не зависит от порядка обнаружения SCSI-устройств, моделей именования устройств и прочих мелочей.

Наконец, LVM поддерживает технологию Snapshots. Эта технология крайне напоминает технологию COW (Copy-on-Write, копирования при записи), используемую в linux при создании новых процессов. При создании Snapshot'а логического тома все логические "клеточки" созданного тома-снапшота ссылаются на те же самые физические "клеточки" блочных устройств, что и «клеточки» исходного тома. Это означает, что одни и те же данные доступны по двум логическим именам. Это же, кстати, делает процесс создания снапшота любого размера практически мгновенным. При изменении одной из "копий" данных логические ячейки разносятся. Это позволяет двум логическим томам использовать совместно неизменяемую часть данных, поддерживая независимо только различающуюся часть.

Такой подход значительно экономит ресурсы диска, но это не главное. Главное – что со снапшота очень удобно производить резервное копирование файловых систем, содержащих динамично изменяющиеся данные (например, данные СУБД). Алгоритм прост:

1. Создаем снапшот, "замораживая" состояние логического тома для резервного копирования. При этом мы не блокируем исходный LV, приложения могут продолжать работать и изменять данные на нем.
   
2. Спокойно делаем резервную копию со снапшота.
   
3. Уничтожаем снапшот и продолжаем работу как ни в чем ни бывало.
   

Заключение

Тут и сказочке конец. Можно еще добавить, что Red Hat предоставляет довольно удобный графический инструмент для управления LVM (system-config-lvm), который позволяет делать все описанное несколько быстрее. А самое интересное - большинство возможностей LVM уже давно доступно и в кластерном варианте (CLVM - Cluster Logical Voume Management). Но об этом в другой раз.