Zones

Сегодня наконец-то успешно завершил первый эксперимент с Solaris 8 Migration Assistant (S8MA) - новым продуктом от Sun, который позволяет запускать зоны с Solaris 8. Решение является полностью поддерживаемым (за поддержку, конечно же, придётся заплатить), но доступен для бесплатного скачивания и тестирования в течение 90 дней, чем я и воспользовался.

Для начала - немного о полезности данного продукта. Во многих компаниях к апгрейдам Solaris относятся довольно консервативно. Большинство основных систем работает под Solaris 8, если не что-нибудь ещё старше. Часто это обусловлено зависимостями от программного обеспечения сторонних разработчиков, которое было в своё время куплено и налажено под Solaris 8, и теперь не может быть достаточно легко портировано в Solaris 10. Получается, что такие системы обречены на медленное, но очень дорогое устаревание. Дорогое - потому что с каждым годом поддержка серверов, способных работать под управлением Solaris 8, становится всё дороже.

Вот как раз для таких случаев и было придумано решение с зонами Solaris 8. Всё очень просто: создаёшь flar-слепок существующей Solaris 8-системы, создаёт зону Solaris 8, импортирует туда flar-образ, и получаешь виртуальную копию твоей Solaris 8, вместе со всеми процессами, программами и скриптами. Для особых случаев даже предусмотрена возможность указания старого hostid для свежесозданной зоны - чтобы ни одна из программ, запущенных внутри зоны, даже не догадалась о своём виртуальном положении.

Возможно, я расскажу об этой технологии более подробно в другой раз. А пока - простейший набор действий и команд для проверки того, как же всё это работает:

1. Найти и подготовить какую-нибудь sparc-систему с Solaris 10u4. Важно, чтобы это был самый распоследний апдейт Solaris 10. Подготовка заключается в установке патча с обновлением ядра. В моём случае оказалось достаточно патча 127111-01.

2. Скачать Solaris 8 Migration Assitant (текущая версия - 1.0) вот по этой ссылке: Solaris 8 Migration Assistant. 3 пакета, полученных в архиве, устанавливаются простейшим образом с помощью стандарнтого pkgadd.

Пакеты - следующие:


3. Создать flar-слепок с вашего Solaris 8 бокса.

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



4. Создать костяк нашей новой зоны с Solaris 8.

Делается это так:


Естественно, IP адрес и имя сетевого интерфейса в вашем случае могут быть другими. Теперь наша зона, в общем-то, уже готова, и находится в состоянии configured (но пока ещё не installed).

5. Установить зону Solaris 8 по мотивам нашего flar-архива



В моём случае зона Solaris 8 застряла на элементе sys-unconfig, и поэтому пришлось ей помочь расконфигурироваться, подключившись к виртуальной консоли зоны.

Делается это с помощью команды:

Сегодня я расскажу о моделях корневых файловых систем для не-глобальных зон Solaris.

Как вы уже, наверное, знаете, таких моделей в Solaris 10 две: sparse root и whole root. Как можно догадаться по названиям, первая модель означает, что корневая файловая система в зоне будет только частично состоять из по-настоящему скопированных файлов, и, следовательно, такой вариант создания зоны потребует где-то 100 мб дискового пространства в минимальном варианте, что существенно меньше, чем потребовалось бы для обычной установки Solaris 10, которая практически и происходит в случае с whole root. Я об этом немного уже рассказывал.

По умолчанию файлы четырёх разделов корневой файловой системы являются доступными каждой зоне в соответствии с моделью sparse root: /lib, /platform, /sbin и /usr.

Принято также считать, что если при создании зоны был использован хотя бы один ресурс типа inherit-pkg-dir, то такая зона называется sparse root зоной.

В описании каждой не-глобальной зоны можно увидеть, как именно организован доступ к этим разделам глобальной зоны:

zonecfg -z zone1 export



Запомните: ресурсы данного типа можно создавать для зоны только когда она находится в режиме configured, т.е. окружение для зоны создано, но собственно инсталляция пакетов ОС Solaris в зону ещё не производилась. Соответственно, если вы решите изменить ресурсы данного типа для вашей уже существующей зоны, придётся сначала сделать ей uninstall (например, zonecfg -z zone1 uninstall).

Модель sparse root зон делает следующее: при установке того или иного пакета в не-глобальную зону, заново копируются только самые необходимые файлы, а именно - те пакеты, в которых параметр SUNW_PKGTYPE имеет значение root. Все остальные пакеты устанавливаться в не-глобальную зону не будут, а позже она получит доступ к остальным файлам нашей глобальной зоны посредством файловых систем loopback, дающих доступ только для чтения. Можете себе представить, сколько места экономится!

Если вы ничего не знаете про lofs, то почитайте man lofs, всё наверняка прояснится ;)

В качестве примера, выполните следующие команды:



Теперь, если вы зайдёте в каталог /var/tmp/hey, и попробуете там что-нибудь создать или удалить, то у вас ничего не получится, ибо файловая система /var/tmp/hey даёт доступ к файлам /usr только для чнения.

Итак, если в не-глобальной зоне нет ни одного ресурса inherit-pkg-dir, то такая зона считается whole root, так как файлы всех пакетов устанавливаются в неё полностью. Места такая модель требует гораздо больше, но зато у вас появляется гибкость - внутри не-глобальной зоны вы легко можете удалять какие угодно пакеты, чего нельзя было бы сделать, установи вы эту зону с помощью ресурсов inherit-pkg-dir.

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

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

Итак, запускаем zonecfg с командой export чтобы просмотреть конфигурацию (export это параметр командной строки в данном примере, но если вам больше нравится, можно ввести zonecfg -z zone1 и потом ввести export после приглашения):

zonecfg -z zone1 export



Как видно из названия команды export, мы получаем полный список команд zonecfg, чтобы создать аналогичную зону. Отсюда и название - мы экспортируем конфигурацию. Подробнее об этом я расскажу как-нибудь в другой раз.

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

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

В зонах Solaris 10 могут быть ресурсы следующих типов:

net - сетевой интерфейс. Как вы помните, при добавлении такого ресурса к зоне, следует указать имя реального физического устройства на вашей системе, и сетевой интерфейс создаваемой зоны будет виртуальным интерфейсом на указанном сетевом адаптере.

device - дополнительное устройство. С помощью маски имён устройств (например, /dev/pts*) можно разрешить не-глобальной зоне доступ к любым устройствам, существующим в вашей системе.

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

inherit-pkg-dir - наследуемый не-глобальной зоной раздел корневой файловой системы глобальной зоны. Указав имя каталога, вы тем самым указываете на то, что файлы из данного каталога глобальной зоны не должны копироваться в создаваемую зону, а будут заимствованы у неё. Фактически, они будут доступны только для чтения с помощью loopback-файловой системы (спасибо, Dan!)

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

rctl - контроль ресурсов. Пока доступны только два свойства этого типа - zone.cpu-shares и zone.max-lwps, но в будущем их будет больше. Эта параметры позволяют ограничивать процессорное время, отдаваемое на выполнение процессов создаваемой зоны, или максимальное количество lwp-процессов, которые в этой зоне смогут быть созданы.

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

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



Создать не-глобальную зону очень просто. Отведите для неё необходимое пространство на диске, и запускайте команду zonecfg. В качестве параметра нужно указать имя создаваемой или конфигурируемой зоны:

zonecfg -z zone3

Если указанной зоны не существует, то об этом будет выдано соответствующее сообщение. После этого вы попадаете в командный интерфейс, где следует последовательно ввести следующие команды (построчно).



Этот пример создаст нам простейшую зону. Как видно, параметров указывать нужно не так уж много:

zonepath - содержит полный путь к каталогу, где будут размещаться файлы нашей зоны
autoboot - флаг, устанавливающий, следует ли при перезагрузке основной системы (с глобальной зоной) автоматически загружать указанную зону

Далее мы присваиваем нашей зоне один сетевой интерфейс и указываем для него IP-адрес. Указывается имя реального сетевого интерфейса, существующего в нашей глобальной зоне. Для создаваемой зоны будет создан виртуальный интерфейс на основе указанного реального интерфейса.

После этого следует проверить (verify), всё ли верно - проверяется, что все необходимые минимальные свойства получили какие-то значения, и можно завершать работу с командой.

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



Пока что она находится в сконфигурированном состоянии, но до тех пор, пока мы не установим на неё ОС, она не получит своего идентификатора (поле ID), и тем более не сможет быть загружена.

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

configured - система сконфигурирована, но элементы окружения, создаваемые при первой загрузке зоны, ещё не существуют.

incomplete - во время операций инсталляции и деинсталляции, команда zoneadm устанавливает статус зоны именно в это значение. По завершении операций с зоной, её статус меняется.

installed - конфигурация завершена, и даже пакеты ОС были уже установлены в корневой каталог зоны. По сути, это уже готовая к использованию зона, которую осталось лишь загрузить. Виртуальное пространство для этой зоны пока ещё не отведено.

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

running - процессы в зоне выполняются. Можно подключиться к зоне и начать работу. Полностью функциональная среда.

shutting down и down - это кратковременные состояния зоны, которые отображаются, пока процессы зоны завершают работу после выполнения команды halt. После этого, зона переходит в состояние installed, если это нормальное завершение сеанса работы с зоной.

Итак, продолжаем конфигурацию нашей зоны. Теперь, нам нужно её установить. Делается это с помощью команды:

zoneadm -z zone3 install

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

zoneadm -z zone3 boot

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

Как бы там ни было, нужно подключиться к виртуальной консоли нашей зоны, и ответить на все задаваемые стандартным Configuration Assistant'ом вопросы. В числе оных будет и вопрос про пароль для root'а. После всего этого, система в нашей зоне перегрузится ещё раз, и вы сможете войти с консоли под root'ом. Если хочется разрешить подключение через обычный rsh, то следует закомментировать строчку CONSOLE=/dev/console в /etc/default/login.

К консоли нашей зоны можно подключиться следующей командой, в которой ключик -C как раз и означает, что мы желаем подключиться именно к консоли.
zlogin -C zone3

Отключиться от консоли можно будет позднее при вводе стандартной комбинации: "~." (тильда и точка)

Ещё один такой момент. Так как не-глобальные зоны будут совместно с глобальной зоной использовать один и тот же физический интерфейс, это уже ваша забота - позаботиться о том, чтобы ваша система (глобальная зона) могла видеть сеть, чей IP вы установили в не-глобальной зоне.

Скажем, фрагмент ifconfig -a на моём лаптопе выглядит таким образом:



Как видно, адреса, принадлежащие зонам, довольно легко определимы по параметру zone. А мне пришлось создать виртуальный интерфейс с адресом из той же подсети, чтобы я из глобальной зоны мог подсоединиться к моим не-глобальным зонам.

Ещё один момент, последний в этой заметке: пакеты программного обеспечения, устанавливаемые в зонах. Особо любопытные из вас, конечно же, уже посмотрели на лог-файл, и увидели, что в зоне установлено довольно много всего - практически, полноценная ОС. При этом, каталог с зоной занимает при установке по умолчанию около 70мб... Такое несоответствие объясняется одной из ключевых особенностей виртуализации зон: они умеют совместно использовать пакеты глобальной зоны. Т.е. можно для каждой зоны указать, что некоторые файлы, которые должны будут быть установлены на неё из стандартных пакетов установки Solaris 10, фактически копировать и устанавливать необязательно - их можно позаимствовать с уже установленных этих же файлов, существующих в глобальной зоне. Естественно, в нее-глобальных зонах, заимствующих файлы из пакетов глобальной зоны, все эти файлы будут доступны только для чтения. Таким образом и достигается значительная экономия места в зонах. По умолчанию, таким образом зоны наследуют все файлы, устанавливаемые из пакетов в каталоги /lib, /platform, /usr и /sbin. Хочу ещё раз подчеркнуть - наследуются только файлы из стандартных пакетов. Т.е. если вы в указанные выше каталоги добавите вручную какие-то ещё файлы, они, естественно, не унаследуются.

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