Нововведения в Solaris 10: на что обратить внимание админу?::Журнал СА 2.2007
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
20.12.2019г.
Просмотров: 5102
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 6343
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 7600
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 7924
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 6980
Комментарии: 0
Django 2 в примерах

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Нововведения в Solaris 10: на что обратить внимание админу?

Архив номеров / 2007 / Выпуск №2 (51) / Нововведения в 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.

Попробуем самостоятельно создать такую конфигурацию:

# zonecfg -z web

web: No such zone configured

Use 'create' to begin configuring a new zone.

zonecfg:web> create

zonecfg:web> set zonepath=/z/web

zonecfg:web> set autoboot=true

zonecfg:web> add net

zonecfg:web:net> set physical=pcn0

zonecfg:web:net> set address=10.0.0.101

zonecfg:web:net> end

zonecfg:web> exit

По шагам: мы создали зону, путь к её файлам указали как /z/web, включили автозагрузку зоны при старте сервера и назначили ей IP-адрес 10.0.0.101. Этот IP-адрес в дальнейшем автоматически появится как дополнительный логический интерфейс физического сетевого интерфейса pcn0, нам ничего настраивать не надо.

Посмотрим весь список настроек зоны:

# zonecfg -z web info

zonepath: /z/web

autoboot: true

pool:

inherit-pkg-dir:

        dir: /lib

inherit-pkg-dir:

        dir: /platform

inherit-pkg-dir:

        dir: /sbin

inherit-pkg-dir:

        dir: /usr

net:

        address: 10.0.0.101

        physical: pcn0

Кроме той информации, что мы ввели вручную, в экспорте настроек присутствуют блоки:

inherit-pkg-dir:

dir: /путь/к/каталогу

Так обозначается подключение каталогов /lib, /platform, /sbin, /usr глобальной зоны внутрь локальной – они будут подмонтированы при помощи loopback file system только для чтения. Благодаря этому большинство системных файлов не потребуется устанавливать еще раз, так что установка зоны не займёт много места.

При желании мы можем отказаться от этих каталогов, примонтировать другие или не монтировать вообще ничего. Тогда файловая структура локальной зоны будет полностью отличаться от глобальной. Кроме того, мы можем примонтировать какую-то файловую систему в режиме записи и обращаться к ней из других зон в режиме чтения. Это поможет организовать, например, обмен данными между зонами, но мы рискуем ухудшить безопасность системы. По умолчанию между зонами нет никаких связей, кроме возможности связаться по сети. Глобальная зона, как исключение, может обращаться ко всем файловым системам всех зон, что позволяет незаметно проводить аудит файлов локальных зон, выполнять резервное копирование, использовать системы обнаружения вторжения (IDS), и многое другое.

Посмотрим, в каком состоянии наша зона.

# zoneadm list -cv

ID NAME             STATUS         PATH

 0 global           running        /

 - web              configured     /z/web

Зона «сконфигурирована», но операционная система туда не установлена. Выполним установку:

# zoneadm -z web install

/z/web must not be group readable.

/z/web must not be group executable.

/z/web must not be world readable.

/z/web must not be world executable.

could not verify zonepath /z/web because of the above errors.

zoneadm: zone web failed to verify

Ошибка. По требованию Solaris, путь к корню зоны должен иметь атрибуты доступа 0700 и владельца root. Исправим ошибку и продолжим:

inherit-pkg-dir:

dir: /путь/к/каталогу

Preparing to install zone <web>.

Creating list of files to copy from the global zone.

Copying <2422> files to the zone.

Initializing zone product registry.

Determining zone package initialization order.

Preparing to initialize <974> packages on the zone.

Initializing package <185> of <974>: percent complete: 18%

...

Solaris начинает копировать файлы внутрь зоны. Он инсталлирует все пакеты, которые установлены в глобальной зоне, и настраивает конфигурационные файлы в каталоге /etc локальной зоны. Локальная зона никак не привязана к настройкам глобальной зоны, в том числе к сервису разрешения имен, поэтому она может иметь совершенно произвольную конфигурацию. Например, глобальная зона может пользоваться DNS и хранить пользователей в /etc/passwd, а локальная – обращаться только в LDAP или NIS+ за пользователями и именами компьютеров.

Тем временем копирование и установка пакетов закончились.

Initialized <974> packages on zone.

Zone <web> is initialized.

The file </z/web/root/var/sadm/system/logs/install_log> contains a log of the zone installation.

На самом деле копировались только вспомогательные файлы в каталоги /etc и /var. Дерево каталогов /usr, как мы знаем, подключено из глобальной зоны, и ничего туда копировать не надо. Так мы, во-первых, экономим место, а во-вторых, при установке обновлений к пакетам ОС мы обновляем все зоны сразу.

Посмотрим состояние зоны:

# zoneadm list -cv

ID NAME             STATUS         PATH

 0 global           running        /

 - web              installed      /z/web

Теперь зона в состоянии installed. Попробуем её запустить:

# zoneadm -z web boot

Если ошибок нет, то зона запустится. Посмотрим состояние:

# zoneadm list -cv

ID NAME             STATUS         PATH

 0 global           running        /

 1 web              running        /z/web

Запустилась? Попингуем:

# ping 10.0.0.101

10.0.0.101 is alive

Попробуем зайти на её консоль (для выхода из консоли нажмите тильду и точку (~.)):

# zlogin web

[Connected to zone 'web' pts/2]

Sun Microsystems Inc.   SunOS 5.10      Generic January 2005

Мы сейчас в зоне web. Посмотрим:

# zonename

web

# uname -a

SunOS web 5.10 Generic_118855-33 i86pc i386 i86pc

# psrinfo -v

Status of virtual processor 0 as of: 12/26/2006 22:39:19

  on-line since 12/26/2006 05:53:50.

  The i386 processor operates at 3000 MHz,

       and has an i387 compatible floating point processor.

Status of virtual processor 1 as of: 12/26/2006 22:39:19

  on-line since 12/26/2006 05:53:57.

  The i386 processor operates at 3000 MHz,

       and has an i387 compatible floating point processor.

Изучим список процессов зоны:

# ps -e -o user,pid,ppid,time,fname

 UID   PID  PPID   TIME CMD

root  4122  4122   0:00 zsched

root  4135  4122   0:26 svc.startd

root  4133  4122   0:01 init

root  4774  4122   0:00 sh

root  4137  4122   2:01 svc.configd

root  4779  4774   0:00 ps

daemon  4564  4122 0:00 kcfd

root  4565  4122   0:00 nscd

root  4691  4686   0:00 sysidnet

root  4582  4122   0:02 snmpd

root  4685  4122   0:00 cron

root  4720  4691   0:00 sysidnet

Интересно, что родительским у большинства процессов является процесс zsched c PID=4122, а PID процесса init вовсе не равен 1. Это значит, что зона действительно запущена, и мы находимся в её изолированной виртуальной среде. Ура, вот настоящее сисадминское удовольствие: родился новый сервер, пусть даже виртуальный. Посчитайте-ка, нам на это потребовалось меньше десяти команд, включая настройку зоны в zonecfg. А чем меньше команд, тем меньше вероятность ошибиться.

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

# df -n

/                  : zfs

/dev               : lofs

/lib               : lofs

/platform          : lofs

/sbin              : lofs

/usr               : lofs

/proc              : proc

...

Про удивительную новую файловую систему ZFS я расскажу в следующей статье, а пока обратите внимание на файловые системы, которые значатся как lofs. Это файловые системы глобальной зоны, доступные только для чтения.

# touch /usr/test

touch: /usr/test cannot create

# mount | grep /usr

/usr on /usr read only/setuid/nodevices/nosub/dev=840000

Как видим, достаточно безопасная конфигурация. Давайте попробуем запустить веб-сервер Apache внутри зоны. Я пропущу настройки сетевого интерфейса и DNS – здесь всё делается так же, как если бы это был свежеустановленный Solaris.

# svcs http

STATE        STIME    FMRI

disabled       22:38:28 svc:/network/http:apache2

SMF и частичные привилегии

Команда, которую мы сейчас выполнили, – еще одно новшество Solaris. Все службы, которые запускаются в системе и призваны работать постоянно, теперь управляются при помощи Service Management Facility (SMF). SMF позволяет указывать зависимости между службами, ускорять загрузку системы за счёт параллельного запуска независимых друг от друга служб, автоматически перезапускать службы в процессе работы сервера вместе с зависимостями и сильно упрощает управление службами с точки зрения администратора.

Например, мы хотим узнать, все ли службы нормально запустились после старта сервера. Смотрим:

# svcs -xv

svc:/application/print/server:default (LP print server)

 State: disabled since Tue Dec 26 16:55:08 2006

Reason: Disabled by an administrator.

   See: http://sun.com/msg/SMF-8000-05

   See: man -M /usr/share/man -s 1M lpsched

Impact: 2 dependent services are not running:

        svc:/application/print/rfc1179:default

        svc:/application/print/ipp-listener:default

Мы видим, что принт-сервер не запустился, и из-за этого не запустились подсистемы печати BSD и IPP.

Вернемся к Apache и разрешим ему работать. Сначала дадим ему какой-нибудь файл конфигурации, а потом включим службу. Название службы, кстати, можно указывать и целиком, как svc:/network/http:apache2, и частями.

# cp /etc/apache2/httpd.conf-example /etc/apache2/httpd.conf

# svcadm enable http

Нет необходимости перебирать ссылки в /etc/rc?.d, как это приходилось делать раньше – сервис просто запустился и работает. И будет впредь запускаться автоматически при загрузке зоны.

# pgrep -fl http

7797 /usr/apache2/bin/httpd -k start

7801 /usr/apache2/bin/httpd -k start

7799 /usr/apache2/bin/httpd -k start

7800 /usr/apache2/bin/httpd -k start

7795 /usr/apache2/bin/httpd -k start

7798 /usr/apache2/bin/httpd -k start

А теперь посмотрим сразу две интересные особенности 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 с ограниченными привилегиями. Посмотрим базовые права процесса:

# ppriv -S `pgrep -o http`

27400:  /usr/apache2/bin/httpd -k start

flags = <none>

        E: net_privaddr,proc_exec,proc_fork

        I: net_privaddr,proc_exec,proc_fork

        P: net_privaddr,proc_exec,proc_fork

        L: zone

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

Итого, мы не только изолировали приложение, мы ещё и защитили его дополнительно. Посмотрим теперь на производительность. Как узнать, насколько наша зона нагружает сервер? Команда prstat с новым ключом -Z покажет, кроме обычного списка процессов, табличку активности зон:

ZONEID    NPROC  SIZE   RSS MEMORY      TIME  CPU ZONE

     0       44  322M  178M    37%   0:10:32 0.5% global

     4       42  317M  154M    32%   0:08:34 0.5% web

     2       23  237M  157M    15%   0:28:34 0.0% jabber

     1       24  318M  156M    15%   0:23:12 0.0% mysql

     3       24   84M   53M   5.2%   0:05:43 0.0% dspam

Предположим, что у нас есть нестабильное приложение на отдельном сервере, которое иногда начинает загружать 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.

  1. BluePrints, Limiting Service Privileges in the Solaris 10 Operating System – http://www.sun.com/blueprints/0505/819-2680.pdf.
  2. BigAdmin, Solaris Containers: Consolidating Servers and Applications – http://www.sun.com/software/solaris/howtoguides/containersLowRes.jsp.
  3. BluePrints, Application And Database Server Consolidation On Sun Fire X4600 Server Solaris Containers – http://www.sun.com/blueprints/1006/820-0040.pdf.
  4. Sun.com, What’s new in Solaris 10 – http://www.sun.com/software/solaris/whats_new.jsp.

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru