Другие журналы

научное издание МГТУ им. Н.Э. Баумана

НАУКА и ОБРАЗОВАНИЕ

Издатель ФГБОУ ВПО "МГТУ им. Н.Э. Баумана". Эл № ФС 77 - 48211.  ISSN 1994-0408

Сравнение средств установки и поддержки программного обеспечения операционных систем z/OS и Linux

# 07, июль 2011
Файл статьи: О©╫О©╫О©...©╫_P.pdf (549.01Кб)
авторы: Смирнова Е. В., Большаков И. К., Костырко А. С.

УДК 004.451

МГТУ им. Н.Э. Баумана

galiam@bmstu.ru

navik2000@yandex.ru

akost@rusarm.ru

В настоящей статье выполнено сравнение операционных систем z/OS и Linux больших машин (мейнфреймов) по критерию гибкости и управляемости средств установки и поддержки программного обеспечения. Поскольку каждая инсталляция операционной системы рассчитана на выполнение конкретных прикладных задач, важным является комплект установленного программного обеспечения и, соответственно, процедуры его обслуживания. Для управления установкой и обслуживанием прикладных программ, а также компонентов самой операционной системы (далее ОС) используются специальные средства операционной системы. Данная статья будет интересна студентам, изучающим операционные системы больших машин, а также специалистам, интересующимся особенностями различных ОС.

Мейнфрейм – это вычислительная система, изначально ориентированная на бесперебойную работу под исключительно большими смешанными рабочими нагрузками при высоком коэффициенте использования системы. Мейнфреймы могут функционировать под управлением операционных систем различных семейств, каждая их которых располагает собственной средой для выполнения приложений и работы пользователей, а также имеет специфические особенности и области применения. Современные представители этих семейств: ОС z/VM, представляющая из себя гипервизор виртуальных машин, ОС z/OS (ранее OS/390, MVS), которая является наиболее функциональной ОС для мейнфреймов производства компании IBM и ОС Linux для мейнфреймов, появившаяся в январе 2000 года. Последние две ОС являются предметом исследования в этой статье.

Операционная система Linux

Операционная система Linux была создана в 1991 году и является измененной и усовершенствованной свободной реализацией ОС UNIX. ОС Linux соответствует стандарту POSIX, точнее, набору стандартов, описывающих интерфейс между UNIX-системой и прикладными программами, и поэтому совместима с большинством унаследованных от UNIX приложений. Отличие Linux от остальных реализаций UNIX заключается в том, что Linux является бесплатной ОС с открытым исходным кодом и разрабатывается множеством энтузиастов и организаций. Собственно название Linux относится только к ядру ОС, комплектуемому библиотеками и системными программами. Совокупность ядра и так называемого пользовательского окружения, состоящего из базовых программ, позволяющих пользователю взаимодействовать с ядром, называют дистрибутивом Linux. Различные дистрибутивы Linux предназначены для разных целей и поддерживают широкий набор платформ. В 2000 году был официально представлен первый дистрибутив Linux для работы на мейнфреймах, который может работать непосредственно на оборудовании мейнфрейма, или как виртуальная система, управляемая гипервизором z/VM. Два самых популярных корпоративных дистрибутива поставляются компаниями SuSE и Red Hat. Возможности этих дистрибутивов обычно используются для работы веб- и почтовых серверов, межсетевых экранов и серверов приложений.

Семейства дистрибутивов Linux используют различные системы управления пакетами, называемые также менеджерами пакетов, позволяющие управлять процессом установки, удаления и настройки программного обеспечения (далее ПО). Пакеты представляют собой сжатые архивы, содержащие в себе сам дистрибутив ПО и служебные данные, необходимые для работы менеджера пакетов. Менеджеры пакетов умеют разрешать межпакетные зависимости, то есть автоматически определять набор пакетов, необходимый для установки, что позволяет администраторам ОС быть уверенными в правильной последовательности установки приложений, содержащихся в пакетах, а также зависимых от них библиотек и вспомогательных файлов. Широко распространены два менеджера пакетов: в дистрибутивах семейств Red Hat, Fedora, SUSE и большинстве других используется менеджер пакетов RPM (Red Hat Packet Manager — диспетчер пакетов Red Hat), а в дистрибутивах Debian и Ubuntu используется менеджер пакетов DEB. Поскольку широко используемые на мейнфреймах дистрибутивы SuSE и Red Hat используют RPM, именно его будем рассматривать в контексте сравнения  со средствами ОС z/OS.

Менеджер пакетов RPM и соответствующий ему формат пакетов RPM используются в дистрибутивах Linux, поддерживающих стандарт LSB (Linux Standart Base). Основой менеджера пакетов RPM является база данных, содержащая в себе сведения обо всех пакетах, установленных в системе. Каждый пакет стандарта RPM имеет название, состоящее из следующих частей: название программы, версия программы, номер релиза, архитектура. Менеджеры пакетов работают в виде двухуровневых средств управления конфигурацией, как показано на рис. 1. На нижнем уровне находятся средства, инсталлирующие, деинсталлирующие и запрашивающие пакеты, в данном случае - подсистема RPM. На верхнем уровне находятся подсистемы, умеющие производить поиск пакетов в сети Internet, анализировать зависимости между пакетами и модернизировать все пакеты в системе, в нашем случае такой системой является YUM .

Рисунок 1 - Схема работы уровней менеджера пакетов

В системе RPM используются два типа пакетов - бинарные и пакеты с исходным кодом. Бинарные пакеты содержат собранное ПО для определенной платформы, которое может быть непосредственно установлено и использовано, а пакеты с исходным кодом содержат текст кода этого ПО с документацией о том, каким именно образом ПО должно собираться для конкретной платформы перед установкой с помощью RPM. Пакеты RPM поставляются в виде сжатых архивов, которые содержат установочные файлы, а также инструкции для RPM по установке этих файлов, включая права доступа, которые должны быть применены к каждому файлу в процессе установки. Эти инструкции также могут содержать скрипты, настраивающие ОС, которые запускаются перед или после установки (удаления) пакета. Для облегчения установки и управления все пакеты должны иметь ясные имена. Части имен отделяются дефисами или точками. Пакеты RPM поставляются в формате "один пакет - один RPM-файл". Все пакеты имеют формат, состоящий из четырех секций, как показано на рисунке 2:

Рисунок 2 - Формат пакета RPM

Начальный идентификатор пакета позволяет ОС Linux распознать RPM-файл, как пакет. Подпись пакета является результатом крипто-функции над начальным идентификатором и архивом пакета и позволяет проверить целостность и подлинность пакета. Заголовок пакета имеет поля, содержащие данные о версии пакета, его описание и информацию об авторских правах. Архив пакета RPM содержит архивированное дерево файлов и каталогов устанавливаемого ПО, которые копируются в необходимые места файловой системы при установке.

В заголовке пакета находятся поля, в которых может храниться информация о зависимостях пакета. Зависимости могут быть следующих четырех видов:

·         Требование (requirement) – устанавливаемый пакет требует установки других пакетов.

·         Предложение (provides) – от устанавливаемого пакета могут зависеть другие пакеты.

·         Конфликт (conflict) – устанавливаемый пакет не может быть установлен в системе одновременно с некоторыми пакетами

·         Замещенная версия (obsolete) – устанавливаемый пакет замещает другой пакет, который начинает считаться устаревшим.

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

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

Менеджер пакетов RPM использует базу данных установленных пакетов с информацией о функционале, зависимостях и о времени установки. Это облегчает управление пакетами, так как дает возможность запросить информацию обо всех установленных пакетах, определить, какому приложению принадлежит файл, или откатить неудачное обновление, а также проверить целостность и подлинность пакетов. Например, устанавливаемый пакет RPM 1 требует установки пакета RPM 2, который, в свою очередь, зависит от пакета RPM 3. Взаимодействие базы данных с пакетами показано на рисунке 3.

Рисунок 3 - Пример взаимодействия базы данных и пакетов RPM

Операционная система z/OS

Операционная система z/OS предназначена для обеспечения наиболее полного использования возможностей мейнфрейма и работы приложений, унаследованных от предыдущих поколений мейнфреймов.

Разработка ПО в среде z/OS имеет свои особенности, которые определили направление развития инструментов управления конфигурацией, и состоят они в следующем:

·         Большое количество компонентов.

·         Большая гибкость в формировании пакетов ПО, что означает потребность системы (инсталляции) X в модуле A, но не модуле B, или наоборот. Такая гибкость всегда была важна для создания на мейнфрейме собственного нестандартного окружения.

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

·         Существование различных разработчиков и поставщиков программного обеспечения.

·         Длительный срок поддержки версий ПО.

В ОС z/OS для установки программных продуктов и отслеживания их модификаций используется средство SMP/E (System Modification Program/Extended – расширенная программа модификации системы).

Операционная система z/OS состоит из множества элементов, выполняющих различные функции, каждая функция выполняется одним или несколькими загрузочными модулями. Загрузочный модуль в z/OS представляет собой элементарный модуль исполняемого машинного кода. Загрузочные модули создаются посредством компоновки одного или нескольких объектных модулей, как показано на рис. 4. Объектные модули, полученные от разработчиков, могут компоноваться совместно с модулями, написанными и собранными программистами данной инсталляции z/OS, таким образом, возможно внесение собственных изменений в программные продукты.

Рисунок 4 - Компоновка загрузочных модулей с помощью средства SMP/E

Помимо объектных модулей и исходного кода, большинство продуктов содержат макросы, справочные данные, списки команд и прочие компоненты библиотек z/OS. В отличие от ОС Linux, в которой процесс обновления ПО сводится, собственно говоря, к удалению предыдущей версии с сохранением пользовательских конфигураций и к установке новой версии, в ОС z/OS средство SMP/E использует специальные пакеты обновления SYSMOD. Пакет SYSMOD представляет собой пакет элементов и управляющей информации, который должен быть установлен с помощью SMP/E. Пакет обновления  SYSMOD состоит из двух частей:

·         Управляющие операторы модификации, сообщающие средству SMP/E, какие элементы обновляются или заменяются, информацию о зависимостях устанавливаемого SYSMOD, а также прочую информацию об установке.

·         Объектные модули, макросы и прочие элементы, содержащиеся в SYSMOD.

Пакеты SYSMOD бывают четырех типов, в зависимости от их предназначения:

·         FUNCTION – этот тип используется для добавления нового элемента в систему или обновления уже существующего. В некотором смысле аналогичен пакетам RPM.

·         PTF – пакет этого типа предоставляется компанией IBM для профилактики и исправления обнаруженных проблем.

·         APAR – пакет этого типа предназначен для временного исправления проблемы и предоставляется первому клиенту, с ней столкнувшемуся, до того как IBM не проанализирует проблему и не выпустит устраняющий ее на всех инсталляциях PTF.

·          USERMOD – такой пакет создается системным программистом ОС и предназначен для установки самостоятельных модификаций ПО.

Необходимым условием для установки пакетов APAR, PTF и USERMOD является наличие установленного FUNCTION SYSMOD того ПО, для которого устанавливаются исправления или дополнения. Также возможны следующие условия:

·         PTF SYSMOD может зависеть от других PTF

·         APAR может зависеть от PTF SYSMOD и других APAR SYSMOD

·         USERMOD SYSMOD может зависеть от PTF, APAR и других USERMOD SYSMOD.

Для отслеживания и управления предварительными условиями подсистема SMP/E использует идентификаторы модификации. Существует три вида идентификаторов модификации, связанных с каждым элементом.

·         Идентификаторы функциональных изменений идентифицируют FUNCTION SYSMOD, внедряющий элемент в систему.

·         Идентификаторы изменений замены идентифицируют последний SYSMOD для замены элемента.

·         Идентификаторы изменений обновления идентифицируют SYSMOD, представляющий обновление элемента со времени его последней замены.

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

Зависимости между SYSMOD в SMP/E бывают следующих видов:

·         Необходимые требования (Prerequisites). Минимально необходимый для безопасной установки набора модификаций уровень поддержки ПО. Представлен именами SYSMOD (как правило, PTF), которые должны иметься в системе.

·         Сопутствующие требования (Corequisites). Вторичные по отношению к уровню поддержки модификации, зависящие от установленного ПО. Представлены в виде: «если в системе имеется PTF abc, должно иметься и PTF xyz».

·         IF-требования (IF requisite). Операторы контроля модификаций MCS позволяющие задать требования к наличию прочих модификаций, которые необходимо установить для данной SYSMOD при установке конкретной функции.

Все установленное ПО хранится в специальных библиотеках, представляющих из себя комплект наборов данных. В среде SMP/E имеется два типа библиотек: дистрибутивные библиотеки и целевые библиотеки. В дистрибутивных библиотеках хранятся резервные копии элементов рабочей системы, а в целевых библиотеках хранится исполняемый код. Набор данных CSI (consolidated software inventory – консолидированная база данных программного обеспечения) хранит информацию, необходимую для отслеживания дистрибутивных и целевых библиотек. Группы дистрибутивных библиотек называются дистрибутивной зоной, а группы целевых библиотек, соответственно, целевой зоной.

Установка пакетов SYSMOD с помощью SMP/E происходит в три этапа. Сначала, при помощи операции RECEIVE выделяется место для хранения и пакеты SYSMOD загружаются из веб-источника или магнитной ленты. Затем проверяется синтаксис управляющих операторов MCS (Modification control statements – операторы контроля модификаций) и производится доступ к данным HOLDDATA. HOLDDATA это операторы MCS, поставляемые вместе с SYSMOD и указывающие, какой SYSMOD и по каким причинам нельзя устанавливать. Причины могут быть следующие:

·         PTF содержит ошибку (ERROR HOLD)

·         Перед установкой SYSMOD системе необходимо выполнить некоторые действия (SYSTEM HOLD)

·         Пользователь должен выполнить некоторые действия перед установкой (USER HOLD)

После выполнения необходимых действий производится установка SYSMOD в библиотеках, как показано на рис. 5.

Рисунок  5 - Установка SYSMOD в временные библиотеки с помощью операции RECEIVE

На этом этапе мы получаем сохраненные во временных хранилищах объектный код пакета и проверенные на наличие ошибок управляющие записи. Если провести аналогию с ОС Linux, результаты выполнения операции RECEIVE можно сравнить с проверенными на целостность и сохраненными на жестком диске пакетами, полученными из источника с помощью нижнего уровня менеджера пакетов RPM.

На втором этапе производится выбор и установка полученных ранее SYSMOD, хранящихся во временных библиотеках. Во время выполнения операции APPLY подсистема SMP/E проверяет, установлены ли в систему необходимые пакеты, описанные в записях MCS, или проверяет правильность последовательности их установки. После этого производится копирование программных модулей в целевую библиотеку для проверки работоспособности ПО и модификация базы данных CSI. Данный этап показан на рис. 6.

Рисунок 6 - Установка SYSMOD в целевые библиотеки с помощью операции APPLY

Для обеспечения возможности восстановления SYSMOD в специальном наборе данных SMPSCDS создаются BACKUP записи. Они используются для восстановления исходного состояния с помощью функции RESTORE. При использовании этой функции вся информация в целевой зоне, относящаяся к восстанавливаемым SYSMOD удаляется и заменяется информацией из дистрибутивной зоны. В глобальной зоне записи SYSMOD и MCS, относящиеся к восстанавливаемому SYSMOD также удаляются.

После установки и тестирования SYSMOD в целевой библиотеке изменения принимаются с помощью операции ACCEPT. Она устанавливает выбранные SYSMOD в соответствующих дистрибутивных библитеках, выполняя их замену или перекомпоновку, а затем обновляет базу данных CSI. Затем выполняется удаление временных данных, которые были созданы на предыдущих этапах. Данный этап показан на рис. 7.

Рисунок 7 - Установка SYSMOD в дистрибутивные библиотеки с помощью операции ACCEPT

Если каждый пакет RPM хранит в себе список пакетов, которые требуется автоматически установить в системе при его установке, позволяя программисту лишь указывать требования к версиям требуемых пакетов, то система SMP/E предоставляет командный язык, позволяющий гибко управлять зависимостями. Предположим, что имеются два компонента системы z/OS, состоящие из двух и трех загрузочных модулей соответственно. Системный программист или компания IBM присылают администратору мейнфрейма пакет PFT SYSMOD, который должен обновить первый модуль из второго компонента и обновить третий в случае, если в системе установлен первый компонент. Механизм, позволяющий  запрограммировать данное действие, называется IF-требованием (IF requisite), его работа продемонстрирована на рис. 8.

Рисунок 8 - Пример использования IF-требования при установке PTF SYSMOD

Вывод

Результаты сравнения двух ОС, выполненные в статье, систематизированы и сведены в таблицу сравнения средств установки и поддержки программного обеспечения операционных систем z/OS и Linux. Как видим, в сравнении с менеджером пакетов RPM, средство SMP/E требует большего внимания со стороны системного программиста, однако, обеспечивает высокую гибкость, управляемость и более широкие возможности, что соотносится с философией мэйнфреймов IBM.

Таблица сравнения средств установки и поддержки программного обеспечения операционных систем z/OS и Linux

Критерий для сравнения

Linux

zOS

Средство установки ПО

Менеджер пакетов PRM

Средство управления конфигурацией SMP/E

Типы пакетов

Пакет RPM

Пакет SYSMOD четырех типов

1)      FUNCTION

2)      PTF

3)      APAR

4)       USERMOD

Технология проверки пакетов на целостность

С помощью подсистемы нижнего уровня RPM

В процессе выполнения команды RECEIVE

Установка пакетов в специальную область для тестирования

Менеджер пакетов RPM не имеет такой возможности

После выполнения операции APPLY

База данных

База данных RPM хранит информацию о всех пакетах в системе

База данных CSI, хранит указатель на элемент в дистрибутивных и целевых библиотеках, а также другие данные

Возможность восстановления конфигурации

Менеджер пакетов RPM не имеет такой возможности

Возможность восстановления исходного состояния с помощью операции RESTORE

Внимание со стороны системного программиста

Меньше

Больше

Обеспечивает высокую гибкость, управляемость и более широкие возможности

Меньше

Больше

Концепция управления программным обеспечением

Минимальный управляемый компонент

Пакет

Загрузочный  модуль

Технология разрешения зависимостей

Автоматически

Вручную

Наличие системы гибкого управления версиями

Нет

Присутствует мощная система управления модификациями, работающая со сложными зависимостями. Возможно обновление ПО без его удаления и повторной инсталляции

 

Благодарность

Авторы выражают благодарность руководству МГТУ им. Н.Э. Баумана и Министерства образования и науки РФ. Статья выполнена в рамках поисковой научно-исследовательской работы по Государственному контракту ╧16.740.11.0407 от 26 ноября 2010 г.

Литература

1.      IBM SMP/E for z/OS User’s Guide / IBM Redbooks SA22-7773-14. Poughkeepsie, NY: IBM press, 2009. 244 с.

2.      Eric Foster-Johnson. Red Hat RPM Guide. CC-BY-SA: Red Hat, Inc, 2010. 504 с.

3.      М. Эбберс, У. О’Брайен, Б. Огден. Введение в современные мэйнфреймы: основы z/OS. М.: IBM, 2007. 621 c.

4.      Э. Немет, Г. Снайдер, Т. Хейн. Руководство администратора Linux. М.: Вильямс, 2007.  1072 с.

5.      Материалы веб-сайта Академического центра компетенции IBM в области больших ЭВМ. http://mainframe.bmstu.ru  (дата обращения:5.05.2011).


Тематические рубрики:
Поделиться:
 
ПОИСК
 
elibrary crossref ulrichsweb neicon rusycon
 
ЮБИЛЕИ
ФОТОРЕПОРТАЖИ
 
СОБЫТИЯ
 
НОВОСТНАЯ ЛЕНТА



Авторы
Пресс-релизы
Библиотека
Конференции
Выставки
О проекте
Rambler's Top100
Телефон: +7 (915) 336-07-65 (строго: среда; пятница c 11-00 до 17-00)
  RSS
© 2003-2024 «Наука и образование»
Перепечатка материалов журнала без согласования с редакцией запрещена
 Тел.: +7 (915) 336-07-65 (строго: среда; пятница c 11-00 до 17-00)