Практикум: разворачиваем контейнеры в ОС Solaris

Насколько сложно их применение и для чего они могут быть полезны

Многие компании всё чаще обращают внимание на новые возможности операционных систем и прикладного ПО, связанные с виртуализацией и эффективным управлением ресурсами. Редакция it-times начинает серию прикладных материалов в формате "how-to", описывающих процессы применения новых востребованных функций. Разумеется, мы не приводим детальных инструкций и списков команд по проведению тех или иных операций. Материал призван стать отправной точкой для обсуждения способов применения новых продуктов и технологий.

В списке наиболее "горячих" нововведений последнего времени — контейнеры в ОС Solaris. У всех ИТ-специалистов, которые хотя бы краем уха слышали о Solaris, эта операционная система ассоциируется главным образом с файловой системой ZFS, бинарной совместимостью c Linux, динамической трассировкой DTrace и возможностью создавать контейнеры. Именно использованию контейнеров и зон посвящен данный материал. Мы попросили рассказать начальника отдела разработки ПО Sun Microsystems из Санкт Петербурга Сергея Пикалева о процессе настройки зон и о наиболее типичных сценариях их применения.

Настройка зон осуществляется очень просто – с этой задачей справится даже специалист не знакомый ранее с этой системой. Для того, чтоб начать работу с ними достаточно запустить команду zonecfg. Затем необходимо указать название зоны, конфигурирование которой хочет осуществить пользователь, например new_zone, даже если в данный момент не создано ни одной зоны. В этот момент система выдаст сообщение, с информацией о том, что данная зона отсутствует, однако, если пользователь хочет создать ее, то необходимо набрать команду create. После выполнения этой команды система пошагово будет сопровождать пользователя, и сообщать какие дальнейшие действия необходимо выполнить для последующей настройки. По окончании конфигурирования, при помощи команды verify можно проверить правильность выполненных настроек - система построена таким образом, что практически невозможно настроить зону так, что она будет не работоспособной.

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

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

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

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

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

С применением зон подобная проблема очень просто решается: администратор создает отдельную зону для базы данных и отдельную для веб сервера. В силу того, что зона «видит» сеть так же, как и глобальная зона, запросы к базе данных становятся не локальными, а сетевыми. Однако, поскольку зоны и глобальная зона функционируют на одной аппаратной платформе, в реальности обмен пакетами не доходит до уровня сетевой карты. Он осуществляется через кэш верхнего уровня в стеке TCP/IP и, следовательно, не снижает производительность системы. Специалистам предоставляются пароли к их зонам и полные права, которые относятся лишь к их зонам. Такой подход исключает возникновение непредвиденных ситуаций, связанных с нехваткой прав – они обладают всеми полномочиями в рамках своих контейнеров. Таким образом, специалисты могут выполнять свою работу в полном объеме, а системный администратор может не беспокоиться об остальных компонентах системы. Подобная схема применения контейнеров очень распространена.
Более подробную информацию о работе с зонами можно найти по этому адресу.

Вторая ситуация, в которой могут быть применены контейнеры, связанна с benchmark-тестированием, когда ведутся замеры времени. В таких случаях необходимо запускать несколько тестов на разных конфигурациях. Для объективного тестирования, нужны четко установленные и фиксированные значения всех параметров: частоты процессора, объема оперативной памяти, свободного места на диске. В силу того, что в системе может работать множество других программ, результаты тестирования не будут объективными.

Для объективной оценки, необходимо организовать отдельную изолированную рабочую станцию с заданными параметрами. На многопроцессорном оборудовании каждый запуск программы назначается на свободный в данным момент процессор, что уже заранее делает тесты, проводимые на таком оборудовании недостоверными. Каждый раз конфигурировать новую отдельную рабочую станцию занимает слишком много времени, возникает вопрос – можно ли использовать параллельные системы для того, чтобы проводить тестирование.

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

Для более подробного ознакомления с данной темой, рекомендуем посетить сайты:
http://www.sunhelp.ru
http://community.livejournal.com/ru_opensolaris
http://osug.org.ua
http://www.opennet.ru/mp/solaris

IT-Times 16 февраля 2009 http://it-times.com.ua/articles/projects/173/