 |
|
|
|
Нововведения в Solaris 10: на что обратить внимание админу?
Нововведения в Solaris 10: на что обратить внимание админу? Современная версия ОС Solaris 10 содержит в себе большое количество нововведений и уникальных технологий, что даже бывалые администраторы не успевают уследить за всеми появившимися возможностями. Полный список нововведений вы можете посмотреть по ссылке [4], а я попытаюсь наглядно показать основные преимущества Solaris нового поколения. Зоны Классическое IT-правило «один сервис – один сервер» практически никогда не удается реализовать из-за нехватки средств и ресурсов. «Железо» слишком дорогое, поддержка множества серверов тоже недешевая, да и чересчур много систем приходится администрировать сразу – невозможно уследить ни за обновлениями, ни за пользователями. Стоимость IT-инфраструктуры с каждым новым сервером возрастает в геометрической прогрессии. Чтобы всё-таки приблизиться к идеалу и упростить работу администраторов, в Solaris была реализована концепция контейнеров (containers), иначе называемых зонами (zones). Зона похожа на Jail во FreeBSD, но имеет больше степеней свободы. Приложения, помещенные в различные зоны, полностью изолированы друг от друга и практически независимы от аппаратного обеспечения. У каждой зоны может быть свой набор установленных программ, свои сетевые адреса, свои объекты файловой системы, свой список пользователей, и в том числе свой суперпользователь – root. Ядро системы – единственное, что есть неизменно общего у всех установленных зон. Таким образом, каждая зона работает как независимая операционная система, что дает нам возможность просто и безопасно создавать виртуальные серверы, помещая приложения в соответствующие зоны. Есть много способов практического применения зон. Можно использовать зоны для изоляции приложений, риск атаки которых достаточно велик – в таком случае взломщик будет ограничен пределами зоны и не сможет нанести большого вреда. Или, к примеру, если вы поддерживаете серьезный веб-сервер, над различными сайтами которого трудятся разные группы дизайнеров, вы можете каждой группе предоставить свою среду, свои приложения и даже дать им полный контроль над локальным веб-сервером или самой зоной. Если же с вашим сервером работают программисты, то можно сгенерировать зону, максимально подобную production-окружению, и дать им возможность как следует протестировать свои приложения. Некоторые веб-администраторы в зону помещают honeypot-ловушки и контролируют их активность снаружи – зона изнутри не может узнать, кто и как за ней наблюдает. Хорошее решениее – разнести основные службы сервера по различным зонам. Можно будет перезагружать зоны сервера по отдельности, не мешая остальным приложениям, и обеспечить их раздельное резервное копирование – в таком случае вы сможете быстро восстановить зону на ближайшем доступном сервере, если основной выйдет из строя. Кроме того, упрощаются миграция и обновление приложений в зонах. Кластерный комплекс Sun Cluster, доступный бесплатно на sun.com, позволяет организовать и зоны высокой доступности – резервная зона поднимется мгновенно (загрузка зоны занимает секунды), если произойдёт сбой основной зоны. Впрочем, благодаря простоте настройки такую отказоустойчивость можно реализовать и самостоятельно с помощью скриптов. Давайте лучше поближе взглянем на сами зоны. Рассмотрим простую схему: операционная система плюс одна зона. Считается, что сама операционная система тоже находится в зоне, и эта зона называется глобальной (global zone). Все остальные зоны назовем локальными, хотя в английской терминологии они называются «неглобальные» (non-global). Пусть наша глобальная зона имеет адрес 10.0.0.1. Внутри у неё находится локальная зона «web» с веб-сервером внутри и адресом 10.0.0.101. Попробуем самостоятельно создать такую конфигурацию:
По шагам: мы создали зону, путь к её файлам указали как /z/web, включили автозагрузку зоны при старте сервера и назначили ей IP-адрес 10.0.0.101. Этот IP-адрес в дальнейшем автоматически появится как дополнительный логический интерфейс физического сетевого интерфейса pcn0, нам ничего настраивать не надо. Посмотрим весь список настроек зоны:
Кроме той информации, что мы ввели вручную, в экспорте настроек присутствуют блоки: inherit-pkg-dir: dir: /путь/к/каталогу Так обозначается подключение каталогов /lib, /platform, /sbin, /usr глобальной зоны внутрь локальной – они будут подмонтированы при помощи loopback file system только для чтения. Благодаря этому большинство системных файлов не потребуется устанавливать еще раз, так что установка зоны не займёт много места. При желании мы можем отказаться от этих каталогов, примонтировать другие или не монтировать вообще ничего. Тогда файловая структура локальной зоны будет полностью отличаться от глобальной. Кроме того, мы можем примонтировать какую-то файловую систему в режиме записи и обращаться к ней из других зон в режиме чтения. Это поможет организовать, например, обмен данными между зонами, но мы рискуем ухудшить безопасность системы. По умолчанию между зонами нет никаких связей, кроме возможности связаться по сети. Глобальная зона, как исключение, может обращаться ко всем файловым системам всех зон, что позволяет незаметно проводить аудит файлов локальных зон, выполнять резервное копирование, использовать системы обнаружения вторжения (IDS), и многое другое. Посмотрим, в каком состоянии наша зона.
Зона «сконфигурирована», но операционная система туда не установлена. Выполним установку:
Ошибка. По требованию Solaris, путь к корню зоны должен иметь атрибуты доступа 0700 и владельца root. Исправим ошибку и продолжим:
Solaris начинает копировать файлы внутрь зоны. Он инсталлирует все пакеты, которые установлены в глобальной зоне, и настраивает конфигурационные файлы в каталоге /etc локальной зоны. Локальная зона никак не привязана к настройкам глобальной зоны, в том числе к сервису разрешения имен, поэтому она может иметь совершенно произвольную конфигурацию. Например, глобальная зона может пользоваться DNS и хранить пользователей в /etc/passwd, а локальная – обращаться только в LDAP или NIS+ за пользователями и именами компьютеров. Тем временем копирование и установка пакетов закончились.
На самом деле копировались только вспомогательные файлы в каталоги /etc и /var. Дерево каталогов /usr, как мы знаем, подключено из глобальной зоны, и ничего туда копировать не надо. Так мы, во-первых, экономим место, а во-вторых, при установке обновлений к пакетам ОС мы обновляем все зоны сразу. Посмотрим состояние зоны:
Теперь зона в состоянии installed. Попробуем её запустить: # zoneadm -z web boot Если ошибок нет, то зона запустится. Посмотрим состояние:
Запустилась? Попингуем:
Попробуем зайти на её консоль (для выхода из консоли нажмите тильду и точку (~.)):
Мы сейчас в зоне web. Посмотрим:
Изучим список процессов зоны:
Интересно, что родительским у большинства процессов является процесс zsched c PID=4122, а PID процесса init вовсе не равен 1. Это значит, что зона действительно запущена, и мы находимся в её изолированной виртуальной среде. Ура, вот настоящее сисадминское удовольствие: родился новый сервер, пусть даже виртуальный. Посчитайте-ка, нам на это потребовалось меньше десяти команд, включая настройку зоны в zonecfg. А чем меньше команд, тем меньше вероятность ошибиться. Посмотрим, какие файловые системы у нас подключены:
Про удивительную новую файловую систему ZFS я расскажу в следующей статье, а пока обратите внимание на файловые системы, которые значатся как lofs. Это файловые системы глобальной зоны, доступные только для чтения.
Как видим, достаточно безопасная конфигурация. Давайте попробуем запустить веб-сервер Apache внутри зоны. Я пропущу настройки сетевого интерфейса и DNS – здесь всё делается так же, как если бы это был свежеустановленный Solaris.
SMF и частичные привилегии Команда, которую мы сейчас выполнили, – еще одно новшество Solaris. Все службы, которые запускаются в системе и призваны работать постоянно, теперь управляются при помощи Service Management Facility (SMF). SMF позволяет указывать зависимости между службами, ускорять загрузку системы за счёт параллельного запуска независимых друг от друга служб, автоматически перезапускать службы в процессе работы сервера вместе с зависимостями и сильно упрощает управление службами с точки зрения администратора. Например, мы хотим узнать, все ли службы нормально запустились после старта сервера. Смотрим:
Мы видим, что принт-сервер не запустился, и из-за этого не запустились подсистемы печати BSD и IPP. Вернемся к Apache и разрешим ему работать. Сначала дадим ему какой-нибудь файл конфигурации, а потом включим службу. Название службы, кстати, можно указывать и целиком, как svc:/network/http:apache2, и частями. # cp /etc/apache2/httpd.conf-example /etc/apache2/httpd.conf # svcadm enable http Нет необходимости перебирать ссылки в /etc/rc?.d, как это приходилось делать раньше – сервис просто запустился и работает. И будет впредь запускаться автоматически при загрузке зоны.
А теперь посмотрим сразу две интересные особенности SMF и нового Solaris. Как известно, Apache стартует обычно с правами root, открывает порт 80 и потом свои дочерние процессы запускает с правами непривилегированного пользователя (webservd в Solaris). Опираясь на принцип «defence in depth», мы можем дополнительно защитить систему, изначально запуская Apache с правами webservd. Возникает вопрос: как же он откроет привилегированный порт 80? Фокус в том, что в новом Solaris права root – не цельное понятие. По традиции, если в UNIX нужно выполнить привилегированную команду, ядро проверяет, равняется ли uid пользователя нулю. То есть имеет ли он права root. В Solaris эта идея изменилась, когда потребовалось более глубоко реализовать систему ролей и профилей. Привилегии root разбиты на несколько десятков базовых прав, которые можно предоставлять раздельно. То есть мы можем дать пользователю или процессу право открывать привилегированный порт, не давая ему при этом все права root. Или, скажем, мы можем дать право управлять службами. Права root растащили по частям – в релизе Solaris 10 6/06 таких базовых привилегий было 48, в ноябрьском 11/06 их уже больше шестидесяти. Удобство состоит в том, что мы можем указать нужные привилегии в описании службы в SMF. Если перед включением веб-сервера Apache настроить его SMF-манифест так, чтобы там было указано базовое право net_privaddr, Apache сможет самостоятельно открыть 80-й порт, не имея других суперпользовательских привилегий. Как это сделать, подробно описано в BluePrints, [1]. Вот, например, уже настроенный Apache с ограниченными привилегиями. Посмотрим базовые права процесса:
Буква E отображает список действующих (effective) базовых прав процесса. Кроме права net_privaddr, нужного для открытия порта, у сервера есть права запускать другие процессы и потоки. Такие права, кстати, целесообразно отбирать у процессов, которые рискуют быть взломанными, чтобы злоумышленник не смог ничего лишнего запустить. Итого, мы не только изолировали приложение, мы ещё и защитили его дополнительно. Посмотрим теперь на производительность. Как узнать, насколько наша зона нагружает сервер? Команда prstat с новым ключом -Z покажет, кроме обычного списка процессов, табличку активности зон:
Предположим, что у нас есть нестабильное приложение на отдельном сервере, которое иногда начинает загружать CPU на все 100%. Неужели мы просто перенесем это приложение в зону и дадим ему время от времени валить наш сервер своей неконтролируемой активностью? А вот и нет. Кроме обычного распределения ресурсов по проектам, которое всегда было в Solaris, теперь есть дополнительные средства ограничения и резервации ресурсов специально для зон. Например, можно выделить зоне только несколько процессоров системы. Если, скажем, у вас сервер T2000 с 32-разрядными ядрами и вы хотите запустить шесть активных приложений в шести зонах, то целесообразно выделить им по 4 ядра на зону и оставить 8 ядер основной системе. Как можно эффективно распределять ресурсы, посмотрите на BigAdmin, [2], или в BluePrints, [3]. Если у вас не так много свободы в манипулировании ресурсами, то при консолидации серверов и переносе приложений в зоны важно заранее представлять себе планируемую нагрузку и не помещать на один сервер два приложения, требовательные к одному и тому же ресурсу. Желательно брать такие пары, в которых, например, одно приложение активно использует CPU и не использует ввод-вывод, а второе – наоборот. Тогда выигрыш в производительности и стоимости будет существенно больше. IP Multipathing Хорошо, скажете вы, вот мои сервисы теперь собраны в зоны, защищены, наделены нужными ресурсами. И что же, теперь у меня образовалась единая точка отказа – сетевое подключение? Действительно, это важная проблема. К счастью, в современных серверах редко бывает всего один сетевой интерфейс. Если у вас их несколько, вы можете воспользоваться еще одной особенностью Solaris – IP Multipathing (IPMP). IPMP появился еще в 8-й версии, к 10-й его возможности сильно возросли, но тем не менее я не видел, чтобы его активно использовали. Если у нас есть несколько сетевых интерфейсов, подключенных к одной сети, мы можем объединить их в группу и указать, что каждый является резервным для остальных. Таким образом, если Solaris определяет отказ одного из сетевых соединений, он переносит все адреса с интерфейса, на котором определен отказ, на другой интерфейс группы. При этом установленные сетевые подключения от клиентов сервера тоже переносятся, то есть Solaris пытается их сохранить. Как это работает? Через определенные промежутки времени каждый интерфейс рассылает мультикастовые запросы, проверяя, работает ли сетевое подключение. Подразумевается, что в одной с сервером сети есть еще кто-нибудь, кто на эти запросы ответит. Если на одном из интерфейсов ответов нет уже 10 секунд (значение по умолчанию для IPMP), сервер создает логические интерфейсы с адресами отказавшего интерфейса на работающем интерфейсе. Если отключившийся интерфейс оживает, сервер через 10 секунд переносит адреса обратно. При планировании включения новых зон принимайте во внимание нагрузку на сетевые интерфейсы и распределяйте трафик между ними. Кроме того, поскольку в современном Solaris TCP/IP-стек был полностью переписан, теперь низкоуровневая обработка сетевой нагрузки – прерываний от сетевой карты в том числе – распределяется между всеми процессорами, а не отдается нулевому процессору, как это сделано в большинстве ОС. Если ваш сервер обрабатывает огромное количество пакетов в секунду, имеет смысл изменить это поведение. Например, можно убрать обработку прерываний с первых пяти процессоров: # psradm -i 0 1 2 3 4 Теперь эти процессоры заняты только исполнением приложений. Заключение Мы вкратце посмотрели на зоны, привилегии процессов и управление службами. За кадром остались файловая система ZFS, DTrace, средства автоматического поиска ошибок и самовосстановления ОС, BrandZ – технология запуска приложений Linux в зонах, и многое другое [4]. Если вы еще не пробовали установить Solaris 10, то обязательно попробуйте. Solaris, как и большинство продуктов Sun, теперь можно скачать бесплатно с sun.com и использовать даже для коммерческих целей. А на opensolaris.ru вы всегда найдете поддержку со стороны российского общества пользователей Solaris.
|
Алексей КоробкинКомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
