Загрузка систем SOLARIS

С помощью механизма управления службами SMF (Service Management Facility) компания Sun модернизировала процесс загрузки для систем Solaris 10 и OpenSolaris. Механизм SMF обеспечивает комплексный и принципиально новый подход к управлению службами в системах UNIX. Его уникальность состоит в надстройке нового логического уровня над службами, который управляет зависимостями между ними и автоматически обрабатывает ошибки в данных конфигурации и программные сбои.

Механизм SMF в значительной степени изменяет процедуру загрузки системы. Традиционная схема работы демона init и его rc-сценариев уходит в прошлое. Разработчики Sun заявляют, что современные приложения и их взаимозависимости стали слишком сложными для стандартной схемы управления ими. И они отчасти правы. С другой стороны, стандартная архитектура гораздо проще, и мы даже диву даемся, как Linux и другим популярным операционным системам удавалось работать при старой организации.

Прежде чем рассматривать процесс загрузки системы, опишем в общих чертах механизм SMF.

Механизм управления службами в системе Solaris

Sun определяет службу как "средство предоставления приложениям некоторого списка возможностей и других служб, локальных и удаленных". С нашей точки зрения, служба — это аналог демона: веб-сервер, системный регистратор syslogd или даже init. Любая служба в системе может быть представлена несколькими экземплярами. Например, вы могли бы запустить на выполнение несколько почтовых серверов с различными конфигурационными данными и IP-адресами. Кроме того, службу можно определить как коллекцию других служб. Это свойство позволяет SMF взять на себя роль традиционных уровней выполнения демона init.

Каждый экземпляр службы уникальным образом определяется FMRI-идентифи-катором (/ault management resource identifier — идентификатор управляемого ресурса в системе управления сбоями). Например, следующие эквивалентные FMRI-иденти-фикаторы ссылаются на службу ssh.

svc:/network/ssh:default

network/ssh:default

Служба ssh принадлежит категории network, и данный конкретный FMRI-иден-тиФикатор описывает стандартный экземпляр. В SMF определено несколько категорий, например application, device, network и system. Специальная категория mj-lestone инкапсулирует концепцию уровней выполнения. Экземпляр службы в каждый момент времени может находиться в одном из возможных семи состояний. Узнать состояние службы можно с помощью команды svcs. Чтобы получить полный список служб, определенных в системе, используйте команду svcs -а. Если опустить флаг -а, вы увидите только те службы, которые выполняются в данный момент. Команду svcs можно использовать и для отдельно взятой службы. Например, следующая команда проверяет состояние службы ssh.

solaris$  svcs -1 svc:/network/ssh:default

fmri         svc:/network/ssh:default

name      SSH server

enabled  true

state       online.

next_state             none

state_time             Mon Jul 13 15:56:19 2009

logfile     /var/svc/log/network-ssh:default.log

restarter svc:/system/svc/restarter:default

contract_id 65

dependency         require_all/none svc:/system/filesystem/local   (online)

dependency         optional_all/none svc:/system/filesystem/autofs   (online)

dependency         require_all/none svc:/network/loopback  (online)

dependency         require_all/none svc: /network/physical   (online)

dependency         require_all/none svc:/system/cryptosvc  (online)

dependency         require_all/none svc:/system/utmp   (online)

dependency         require_all/restart file://localhost/etc/ssh/sshd_config  (online)

В этой командной строке используется полный FMRI-идентификатор (в отличие от сокращенного), но поскольку существует только один экземпляр этой службы, можно было бы ограничиться более лаконичной командой svcs   -1  ssh.

Состояние службы может принимать одно из следующих значений:

  • online — запуск разрешен, экземпляр службы успешно работает;
  • disabled — запуск запрещен; экземпляр службы не запущен;
  • degraded — запуск разрешен, но работа происходит с ограниченной функциональностью;
  • legacyrun — служба работает; некоторые унаследованные (от предыдущих версий системы) службы не подлежат управлению через SMF, однако их работу можно наблюдать стандартными для SMF средствами; это состояние возможно только для унаследованных служб;
  • uninitialized — в этом состоянии находятся все службы до того, как их конфигурация будет считана из репозитория;
  • maintenance — экземпляр службы аварийно завершился и не может быть запущен заново без вмешательства администратора;
  • offline — запуск разрешен, но экземпляр службы еще не запущен или нет возможности его запустить из-за ожидания "неудовлетворенной зависимости" или по другой причине.

В дополнение к текущему состоянию службы, команда svcs -1 позволяет узнать местоположение журнала регистрации службы, ее зависимости и другие важные данные.

С помощью зависимостей описываются взаимосвязи (различной сложности) между службами. Это средство, по сути, заменяет систему пронумерованных сценариев запуска, используемую традиционным демоном init, в котором сценарий с префиксом S20 должен выполняться раньше сценария с префиксом S90. Из приведенного выше примера видно, что служба SSH использует элементы локальных файловых систем, сетевые интерфейсы, службы cryptosvc и utmp, а также файл sshd_conf ig. Средство автоматического монтирования файловых систем autof s отмечено как имеющее необязательную зависимость. Это означает, что служба SSH будет выполняться в случае, если автомонтировщик не работает (по намерению администратора) или если он нормально работает.

Команда svcadm изменяет состояние службы. Чтобы запретить запуск сервера SSH (не пытайтесь делать это удаленно!), используйте такую команду. solaris$    sudo svcadm disable ssh

В этом примере используется сокращенный FMRI-идентификатор для сервера SSH, так как он уникальный. Такой запрет является устойчивым изменением; для временного же запрещения запуска службы SSH используйте команду svcsadm -t.

В системе SMF службы конфигурируются на основе XML-файлов, именуемых манифестами и профилями. Манифест содержит полное описание всех свойств службы (зависимостей и инструкций для ее запуска и останова). Файлы манифестов хранятся в каталоге /var/svc/manifest. Каждый экземпляр службы имеет собственный файл манифеста.

Строки exec__method в файле манифеста обычно указывают на сценарии, которые запускают или останавливают службы, т.е. во многом подобно тому, как используются сценарии в системе init. d. Например, процесс запуска для демона SSH определяется в файле /var/svc/manifest/ssh.xml следующим образом.

<exec_method

type='method'

name='start'

exec='/lib/svc/method/sshd start'

timeout_seconds='60'/>

Сценарий /lib/svc/method/sshd, на который здесь содержится ссылка, является sh-сценарием, запускающим службу sshd. Все это подозрительно напоминает сценарий, который когда-то хранился в каталоге /etc/rc.d, — чем больше мы изменяем жизнь, тем больше она остается прежней.

Файл профиля службы определяет, разрешено ли запускать данный экземпляр или запрещено. Профили хранятся в каталоге /var/svc/profile.

Постоянные данные о конфигурации для служб в действительности хранятся в виде файла SQLite-базы данных /etc/svc/repository.db. Таким образом, вам необязательно непосредственно модифицировать содержимое XML-файлов. Вместо этого вы можете управлять манифестами и профилями с помощью команды svccf д. Для управления службами, находящимися под контролем демона inetd, используйте команду ^netadm. Для получения дополнительной информации о командах svccfg, inetadm и svc. configd обратитесь к соответствующим man страницам.

Одной из самых интересных особенностей механизма SMF является использование так называемых "пускателей" (restarters), которые составляют часть разрекламированной в Solaris технологии "прогнозируемого самовосстановления". В результате анализа тщательно определенной системы зависимостей механизм SMF может предположительно определить причину сбоя службы и при необходимости перезапустить ее. Причиной отказа службы может служить ошибка в программном обеспечении, сбой в работе оборудования, проблема с зависимым элементом или даже ошибка администратора. означенный в SMF процесс "пускателей", тесно связанный с ядром, автоматически выполняет действия, необходимые для восстановления.

Комментарии (0)

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