08.10.2007

Области применения виртуализации. Часть 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

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

02.10.2007

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). Но об этом в другой раз.