Индекс
НазадОглавлениеВперед

Глава 11. Вычислительная система AS/400

11.1. Архитектура

Семейство вычислительных систем AS/400 [11, 23] является результатом длительного эволюционного развития вычислительных систем IBM среднего класса. Основные архитектурные концепции, заложенные в этой системе, сформировались еще в IBM System/38 (1978 г.). Архитектура AS/400 представлена на рисунке 11.1.


Рисунок 11.1 Архитектура AS/400

В архитектуре AS/400 сочетаются концепции иерархической архитектуры, архитектуры на базе микроядра, виртуальной машины и объектно-ориентированного подхода. Иерархическая структура программного обеспечения системы хорошо видна на рисунке. Самый нижний слой программного обеспечения выделен в, так называемый, Системный Лицензионный Внутренний Код (SLIC - System Licensed Internal Code) и составляет микроядро. Программное обеспечение слоя микроядра фирма не включает в ОС, считая его входящим в состав оборудования. Исторически сложилось так, что в самой первой системе, применяющей этот подход - IBM System/36, этот слой действительно был изолирован аппаратно (выполнялся на другом процессоре), далее в IBM System/38 и в ранних моделях AS/400, строившихся на базе 48-разрядного CISC-процессора, этот слой был реализован как программно, так и микропрограммно. При переходе AS/400 на 64-разрядный RISC-процессор PowerPC (1995 г.) этот слой стал чисто программным.

Интерфейс микроядра - в AS/400 он называется MI (machine interface - машинный интерфейс) - обеспечивает функционально полную систему команд, в символьном виде представляемую высокоуровневым языком ассемблера. Таким образом, MI предоставляет лежащему выше программному обеспечению интерфейс некоторой виртуальной машины. И приложения, и сама ОС OS/400 разрабатываются на уровне MI (или выше), не имея доступа к интерфейсам, лежащим ниже MI, в том числе, и к командам реального процессора. Переносимость программного обеспечения - приложений и ОС - обеспечивается на уровне MI-кодов. MI-код не является непосредственно исполняемым, он должен быть переведен в команды реального процессора. Однако, процесс трансляции расположен ниже уровня MI, он совершенно прозрачен для приложений и для ОС. Среди команд MI имеются как команды, близкие к обычным машинным командам, оперирующие байтами, словами, числами и т.п., так и команды, оперирующие с интегрированными структурами данных - объектами, обрабатываемыми микроядром. Впрочем, "обычные" команды MI также можно назвать объектно-ориентированными: команды содержат не собственно данные, а ссылки на объекты, содержащие наряду с самими данными и описания их типа, размера и т. п. Так, например, системы команд реальных процессоров обычно содержат несколько команд сложения - разных для разных размеров и форм представления чисел; в MI имеется единственная команда сложения ADDN, которая в зависимости от типов операндов транслируется в ту или иную команду (или последовательность команд) реального процессора.

SLIC обеспечивает аппаратную независимость верхних уровней программного обеспечения - приложений и OS/400. При упомянутом переходе на платформу PowerPC переделке подвергся только SLIC, операционная система и все приложения (более 20 тысяч приложений) не изменялись, но, как будет показано ниже, были автоматически оптимизированы для новой, 64-разрядной платформы.

AS/400 отличается значительной степенью системной интеграции и высоким уровнем системных интерфейсов. Ряд системных функций в AS/400 выполняются SLIC (лежат ниже уровня MI), ряд - OS/400, выполнение же большинства функций распределено между ОС и микроядром. Примеры такого распределения показаны на рисунке 11.2. Так, многие функции, традиционно выполняемые ОС, здесь реализованы на уровне SLIC (защита, ввод-вывод, управление памятью); многие функции, традиционно обеспечиваемые утилитами и отдельными приложениями, интегрированы в OS/400 (база данных, пользовательский интерфейс).


Рисунок 11.2 Распределение функций между OS/400 и SLIC

11.2. Объекты

Еще одной ключевой концепцией AS/400 является ее объектно-ориентированная структура. Выше мы упомянули об объектах MI в AS/400, для оперирования которыми имеются специальные команды MI В системе имеется предопределенный набор типов объектов - системные объекты, часть из которых является объектами MI, часть - объектами OS/400. Некоторые OS/400-объекты отображаются в MI-объекты "один к одному" (хотя иногда под другими названиями), другие OS-объекты совершенно не связаны с объектами MI, некоторые OS/400-объекты представляют собой интеграцию MI-объектов. Примеры OS/400-объектов: программа, документ, таблица, файл, команда, профиль пользователя, библиотека (объект, содержащий другие объекты), папка (объект, содержащий другие объекты и папки). Примеры MI-объектов: программа (то же, что и в ОС), модуль, пространство данных, индекс, очередь, профиль пользователя (то же, что и в ОС), контекст (библиотека в ОС). Следует отметить, что объекты нижнего уровня - объекты MI - доступны как для приложений, так и для OS/400 только через специальные команды MI и не могут обрабатываться каким-либо иным образом, минуя эти команды. Аналогично объекты OS/400 доступны для приложений только через системные вызовы.

Общие свойства системных объектов перечисляются ниже.

  1. Объект, как правило, имеет имя. Объект может не иметь имени, если он не используется никем, кроме ОС.
  2. Объект должен быть явным образом создан командой MI CREATE. Команда ссылается на созданный пользователем шаблон (template) объекта, который содержит атрибуты и значения объекта.
  3. Объект может быть постоянным или временным - этот атрибут объекта определяется при его создании. Постоянные объекты сохраняются в системе до их явного уничтожения (командой MI DELETE). Временные сохраняются не дольше, чем до перезагрузки системы. При явном уничтожении объекта занимаемое ими адресное пространство очищается, но не освобождается, сохраняется также заголовок объекта, в котором, однако, делается пометка "уничтоженный". Это позволяет корректно обрабатывать ошибочные обращения к уже удаленным объектам. Освобождение пространства и уничтожение заголовка происходит при перезагрузке системы.
  4. Адресация к объектам производится через системные указатели. Управление правами доступа к объекту выполняется ниже уровня MI (подробно рассматривается далее).
  5. Временные объекты могут помещаться в "группы доступа". "Группа доступа" - системный объект, который позволяет связывать объекты различного типа и осуществлять к ним совместный доступ.
  6. Атрибуты объекта могут быть "материализованы", то есть, скопированы в доступную область.

Объектам выделяется пространство, в котором располагаются данные и указатели. Внутреннее представление объекта занимает один или несколько сегментов памяти и включает в себя:

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

Следует отдельно упомянуть системный объект, называемый "машинным индексом", внутреннюю структуру которого составляет двоичное дерево. Такие объекты составляют основу всех системных таблиц и каталогов микроядра и ОС, а также входят в состав объектов встроенной реляционной базы данных (DB2 for AS/400). Именно это обстоятельство позволяет нам утверждать, что система управления базой данных в AS/400 глубоко интегрирована в систему: она использует те же средства, что и ОС и даже микроядро.

Системный указатель, адресующий объект, может быть "разрешенным" (resolved) или "неразрешенным" (unresolved). Неразрешенный системный указатель содержит символьную идентификацию объекта. Разрешенный системный указатель представляет собой 16-байтную структуру данных, в состав которой входит прямой адрес объекта в пространстве одноуровневой памяти. Оперировать с объектами можно только, используя разрешенный системный указатель. Для доступа к объекту системный указатель должен быть разрешен, что обеспечивается командой MI RESOLVE, схема действия которой показана на рисунке 11.3. Эта инструкция преобразует символьный указатель в разрешенную форму. Выполнение разрешения включает в себя:


Рисунок 11.3 Разрешение системного указателя

11.3. Управление памятью

Одноуровневая модель памяти AS/400 описана в разделе 3.8 части I. Все управление памятью расположено ниже уровня MI и обеспечивается не ОС, а "виртуальным оборудованием" - микроядром SLIC. Механизмы одноуровневой модели памяти, таким образом, реализуются на аппаратном и самом низком программном уровне и являются прозрачными не только для процессов пользователей, но и для ОС. Интерфейс же управления памятью (или то, что ему здесь соответствует) используется одинаковым образом и процессами пользователей, и OS/400. Виртуальная память выделяется сегментами (в старых моделях размер сегмента составлял 64 Кбайт, в новых - 16 Мбайт). Любой объект занимает целое число сегментов. Запрос на выделение памяти приводит к созданию нового объекта "область данных". Для совместимости с другими ОС в последних версиях системы добавлена возможность выделения для процесса отдельного частного адресного пространства размером до 1 Тбайт. Всего возможно создавать до миллиона терабайтных адресных пространств.

Некоторые аппаратные средства процессора PowerPC поддерживают защиту памяти в одноуровневой модели. Во-первых, дескриптор страницы, как и во многих других процессорах, содержит бит защиты от записи и бит пользователь/система. Эти биты защищают страницы, занятые системными объектами. Еще один механизм аппаратной защиты включен в процессор Power PC специально для AS/400. В системе различаются несколько типов указателей, из которых для нас представляют интерес прежде всего "системные указатели" и "указатели памяти". Последние являются указателями в привычном для нас смысле, они могут модифицироваться, например, операциями адресной арифметики, но только в пределах установленного диапазона для объекта "область памяти". Системные указатели представляют адреса объектов. Их создание и работа с ними возможны только специальными командами MI. Процесс не должен модифицировать системные указатели, но если системные указатели расположены в области данных, то они не застрахованы от модификации их процессом. Механизм ярлыков контролирует модификацию системных указателей. Ярлыком (tag) является дополнительный бит, связанный с каждым машинным словом и индицирующий модификацию этого слова. В качестве ярлыка используется один из битов корректирующего кода для каждого 64-разрядного слова. Доработки, внесенные в процессор Power PC для адаптации его к AS/400, в значительной степени состояли во включении в систему команд процессора команд, работающих с tag-битом. Эти команды, однако, недоступны на уровне MI, следовательно, tag-бит для уровня OS/400 и приложений не существует. При корректных (через инструкции MI) операциях с системным указателем в составе соответствующих инструкций MI выполняются команды, устанавливающие tag-биты указателя в 1, любые другие команды модификации данных сбрасывают tag-биты в 0. При использовании данных в качестве системных указателей проверяются ярлыки двух 64-битных слов, составляющих системный указатель, если хотя бы один из них сброшен, генерируется прерывание-ловушка. Таким образом, описанный механизм не защищает системные указатель от изменений, но предотвращает неправильное использование системных указателей. При вытеснении страницы на внешнюю память ярлыки всех слов страницы группируются в отдельную структуру, которая записывается в заголовок сектора на дисковой памяти.

11.4. Программы и процессы

Подготовка программ в системе AS/400 также имеет некоторые интересные особенности, представленные на рисунке 11.4. в несколько упрощенном виде.


Рисунок 11.4 Подготовка программ в системе AS/400

Компилятор языка высокого уровня (C, PL/1 и т.д.) выполняет трансляцию исходного текста в промежуточный W-код, общий для всех блочных языков. Над промежуточным кодом выполняется системно-независимая оптимизация, а затем программа транслируется в MI-представление, называемое программным шаблоном. Программный шаблон является частью объекта "программа" (это объект как MI, так и OS/400). При запуске программы на выполнение происходит обращение к SLIC. SLIC проверяет наличие в программном объекте кодовой части и, если таковая отсутствует, выполняет трансляцию шаблона в систему команд конкретного процессора. Транслятор во внутримашинное представление, выполняющий также и машинно-зависимую оптимизацию, входит, таким образом, в состав SLIC. Программные коды сохраняются в составе программного объекта, и при последующих запусках на той же вычислительной системе трансляция не выполняется. Поскольку объект "программа" инкапсулирован, составные части объекта (шаблон и коды) доступны только через определенные для объекта операции. Для объекта "программа" не существуют операции "читать" и "писать", что исключает возможность модификации программного кода, например, вирусом. При переносе программного объекта в другую вычислительную систему переносимой частью является программный шаблон. При первом запуске на новой системе SLIC определяет, что программные коды не соответствуют новой платформе и перетранслирует шаблон. Поскольку при такой трансляции выполняется аппаратно-зависимая оптимизация, внутреннее представление получается максимально эффективным именно для той модели процессора, на которой оно будет выполняться. Такое свойство системы позволило ее разработчикам при резкой смене архитектуры процессора не только сохранить все имеющиеся на текущий момент приложения, но и обеспечить без дополнительных затрат их полноценный перевод на 64-разрядную архитектуру. В целях экономии пространства программный шаблон может быть удален из состава программного объекта, но это ограничит переносимость программы на другие платформы.

Схема подготовки программ для AS/400, показанная на рисунке 11.4, как мы отметили, неполная. На самом деле выходе транслятора-оптимизатора трансляции получается объект "модуль". Этот объект затем обрабатывается компоновщиком, также входящим в состав SLIC, и результатом является кодовая часть объекта-программы. В системе различаются "программы", имеющие единственную входную точку, и "системные программы", наборы процедур, используемые как библиотеки статической или динамической компоновки. В языке MI имеется два вида команд вызова: "вызов процедуры" и "вызов программы". Первый используется для обращения к модулям, включенным компоновщиком в состав программного объекта и статически привязанным к программе. Второй - устанавливает связь с другими модулями динамически, при выполнении вызова. Проблемы размещения здесь не возникает, поскольку динамически подключаемые модули, как и все прочие объекты, уже размещены в одноуровневом адресном пространстве. Проблема прав доступа решается на общесистемном уровне защиты объектов.

Единицей работы в системе является процесс или задача. В системе различаются четыре состояния задач: "подвешенность" (задача начинается или завершается), готовность, исполнение, ожидание. Блок контекста задачи представляется весьма масштабной структурой данной, которая обрабатывается исключительно микроядром. С каждой задачей связан Блок диспетчеризации задачи. Блоки диспетчеризации всех задач, готовых к выполнению, объединены в очередь диспетчеризации задач и упорядочены в ней по приоритетам. Первый Блок диспетчеризации (или первые n блоков в n-процессорной конфигурации) относится к активной (исполняемой) задаче. Приоритеты задач перевычисляются динамически по оригинальному алгоритму "планировщика с оценкой задержки", который позволяет оптимизировать загрузку в многопроцессорных конфигурациях. Допускается, однако, и выполнение задач вне порядка их приоритетов. Наиболее важной составляющей процесса является, так называемая, группа активизации, которая, прежде всего, предоставляет процессу ресурсы памяти - статическую память, стек, кучу. По умолчанию процесс имеет две группы активизации - системную и пользовательскую. Понятием более высокого уровня является задание. Задание - единица работы с точки зрения пользователя, выполняемая одним или несколькими процессами. Задания выполняются в подсистемах, каждая их которых представляет собой предопределенную среду, предназначенную для выполнения в ней однотипных заданий (например, пакетных, интерактивных и т.д.). Подсистеме выделяется некоторый набор ресурсов, таким образом, подсистемы изолированы друг от друга.

Интересно рассмотреть, как в AS/400 поддерживается работа с нитями. Теоретически можно было бы обеспечить выполнение нитей в составе процесса, выделяя каждой нити свою группу активизации. Однако такая структура нитей повлекла бы за собой необходимость слишком серьезных изменений в микроядре. Для обеспечения совместимости со стандартами разработчики прибегли к паллиативе. Нить представляется в виде отдельной задачи, которая разделяет с другими задачами-нитями одну и ту же группу активизации. Для обеспечения требования быстрого создания нитей в системе при загрузке создается пул "пустых" задач с уже выделенными для них блоками контекста и некоторыми наиболее общими ресурсами. При необходимости запуска задачи-нити из этого пула выбирается пустая задача и формируются ее индивидуальные ресурсы. Такое решение нельзя не признать остроумным, однако, сами разработчики признают его недостаточно эффективным и рассматривают только как временную меру до - реализации поддержки нитей в микроядре.

11.5. Постоянные объекты и ввод-вывод

Взаимодействие между процессами в AS/400 обеспечивается через очереди сообщений, передачу которых обеспечивает SLIC. Очереди поддерживаются "классическими" семафорами.

Как мы отметили выше, одноуровневая модель памяти замещает понятие "файл" понятием "постоянный объект". (Собственно "файлами" в AS/400 называются файлы встроенной СУБД.) Базовая логическая структура хранения объектов в AS/400 - двухуровневая: объекты размещаются в библиотеках. Для идентификации объекта следует указать имя библиотеки, имя объекта и тип объекта (объекты разного типа могут иметь одинаковые имена). Единственная системная библиотека - QSYS - может включать в себя другие библиотеки. Для обеспечения функций продукта Office Vision в AS/400 был включен тип объекта "папка" - контейнерный объект с неограниченным уровнем вложенности. Этот объект послужил также основой продукта PC Support/400, обеспечивающего хранение в AS/400 файлов ПЭВМ, работающих под управлением MS DOS или OS/2. В дальнейшем для обеспечения полного набора клиент/серверных возможностей с широким разнообразием типов клиентов был создан новый продукт - Client Access/400 и Интегрированная файловая система IFS (Integrated file system). IFS позволяет представить структуру хранения всех объектов в AS/400 в виде иерархической файловой системы клиента (MS DOS, OS/2, Windows, Unix, Nowell, NFS и т.д.). При этом подкаталоги верхнего уровня соответствуют различным файловым системам клиентов. В основе IFS лежит базовая двухуровневая система хранения, которая является подмножеством любой иерархической файловой системы, верхние уровни над ней строятся при помощи объектов-папок.

Неотъемлемой частью архитектуры AS/400 являются процессоры ввода-вывода. Взаимодействие приложения с процессором ввода-вывода происходит через механизм обмена сообщениями, поддерживаемый SLIC. Данные могут передаваться как в составе сообщения, так и выбираться процессором ввода-вывода непосредственно из оперативной памяти. Сообщение-запрос ввода-вывода проходит через ряд последовательных ступеней обработки в OS/400 и SLIC, на каждой ступени к обработке привлекаются соответствующие объекты операционной системы и микроядра, описывающие логические и физические устройства. В одной из возможных конфигураций AS/400 в качестве процессора ввода-вывода применяется процессор Intel/Pentium, работающий под управлением OS/2 Warp или Windows NT. Вычислительная система, таким образом, может выполнять функции сетевого файлового сервера, не загружая этой работой свой системный (центральный) процессор.

Отметим, что диски не входят в эту систему управления устройствами. В соответствии с концепцией одноуровневой памяти, управление дисками относится к управлению памятью и полностью обеспечивается в SLIC.

11.6. Система безопасности

Одной из наиболее интересных особенностей AS/400 является ее система безопасности, реализованная в микроядре SLIC. Как мы показали, команда RESOLVE осуществляет контроль доступа к объекту, причем контроль этот выполняется в микроядре, ниже уровня MI. Разрешенный системный указатель является константой - он не может быть изменен в программе. Системные указатели, которые находятся в области данных какого-либо объекта, могут быть изменены (по ошибке или при попытке "взлома" системы), но теги защищают систему от использования модифицированных системных указателей. Концепция безопасности AS/400 в настоящее время включает в себя 5 возможных уровней защиты. Уровень выбирается при конфигурировании системы. Краткие характеристики уровней приводятся ниже.

Уровень 10. Отсутствие защиты.

Уровень 20. Защита входа в систему паролем. Дополнительным средством этого уровня является возможность регистрации "пользователя с ограниченными возможностями", для которого определяется допустимое подмножество команд.

Уровень 30. Защита ресурсов. К предыдущему уровню добавляется контроль прав доступа пользователей к объектам - системным и пользовательским.

Уровень 40. Защита ОС. К предыдущему уровню добавляется защита от нестандартного доступа к объектам. Этот уровень был введен для того, чтобы пресечь создание независимыми разработчиками приложений, использующих внутреннюю структуру объектов: такие приложения оказывались непереносимыми на следующие версии AS/400. Для обеспечения этого уровня были определены два состояния системы: системное и пользовательское, и некоторая часть команд MI стала привилегированной. В MI было введено огромное число новых команд для корректного доступа к объектам.

Уровень 50. Защита по C2. К предыдущему уровню добавляется контроль событий, связанных с безопасностью.

Дальнейшее рассмотрение мы ведем на уровнях 40 и 50.

AS/400 в основном использует защиту, ориентированную на списки возможностей. Ниже описывается информация по защите, содержащаяся в профиле пользователя.

  1. Имя пользователя и пароль для входа в систему.
  2. Класс пользователя. Различаются такие классы:
    • Офицер безопасности - имеет полный набор прав доступа ко всем объектам;
    • Системный администратор - устанавливает права доступа для Пользователей рабочих станций;
    • Системный программист, разработчик приложений - имеет права доступа к инструментальным средствам разработки приложений;
    • Системный оператор - имеет доступ к средствам обслуживания системы, системным очередям, утилитам и т.д.;
    • Пользователь рабочей станции, пользователь, работающий в среде определенного приложения - имеет ограниченный доступ к библиотекам используемого им программного продукта.
  3. Объекты, к которым пользователь имеет доступ. В профиле имеются два списка таких объектов: тех, для которых пользователь является владельцем, и тех, для которых у пользователя определены частные права. Создатель объекта становится его владельцем, но может передать право владения другому пользователю. Владелец может устанавливать для других пользователей частные права на объект.
  4. Права доступа - определяются для каждого объекта в вышеуказанных списках. Различаются следующие права доступа:
    • операционное - получать описание объекта и пользоваться другими правами;
    • управления - определять защиту для объекта, перемещать и переименовывать объект;
    • существования - удалять объект, выполнять его сохранение и восстановление, передавать право владения;
    • управления правами - устанавливать частные права для других пользователей;
    • группа прав данных - читать, добавлять, удалять, изменять записи в объекте (каждое из этих действий составляет отдельное право);
    • имеются также коды для стандартных комбинаций прав, а также "право" EXCLUDE - отмена всех прав, в том числе, и прав, определяемых групповыми профилями, и публичных прав (см. ниже).
    Для каждого объекта все возможные права доступа кодируются в одном элементе списка.
  5. Специальные права - определяют подмножество возможностей пользователя, применимых ко всем объектам в системе, например: полный доступ ко всем объектам, доступ ко всем пользовательским профилям, управление любыми заданиями в системе и т.д.

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

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

В числе атрибутов объекта "программа" имеется один, позволяющий закрепить за программой "адаптированные" права - права ее создателя, эти права, сохраняются только на время выполнения программы.

Алгоритм авторизации (поиска прав доступа), выполняемый при разрешении системных, указателей состоит из следующих шагов.

  1. Поиск индивидуальных прав, выполняемый в такой последовательности:
    • специальные права в пользовательском профиле;
    • права и частные права в пользовательском профиле;
    • права по списку доступа (если объект входит в такой список).
  2. Поиск групповых прав в такой последовательности:
    • специальные права в групповом профиле;
    • частные права в групповом профиле;
    • групповые права по списку прав доступа.
  3. Поиск публичных прав:
    • публичные права в коде доступа объекта;
    • публичные права по списку доступа.

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

11.7. Новые свойства и перспективы

Начиная с версии OS/400 V4R4 в AS/400, была введена архитектура логических разделов (LPAR), которая обеспечивает представление одной вычислительной системы как нескольких систем - каждая с собственным процессором/процессорами, памятью, устройствами ввода-вывода и со своей ОС. Разделы функционируют независимо друг от друга и логически отделены от других разделов. Коммуникации между разделами осуществляются через операции ввода-вывода (виртуальный Ethernet). Архитектура программного обеспечения AS/400 с LPAR показана на рисунке 11.5.


Рисунок 11.5 AS/400 с логическими разделами

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

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

В системное программное обеспечение AS/400 введен еще один слой - PLIC (Partitioning Licensed Internal Code). Некоторые функции управления разделами реализованы в самом PLIC, для выполнения других PLIC работает совместно с частью SLIC одного из разделов, называемого первичным. Таким образом, гипервизор состоит из PLIC и части SLIC первичного раздела.

Первичный раздел обязательно должен быть в системе, и только один раздел может быть первичным, остальные разделы - вторичные. AS/400 продается как система только с первичным разделом. Этот раздел является владельцем всех ресурсов вычислительной системы. Далее покупатель может из первичного раздела создавать вторичные разделы, распределять и перереспределять ресурсы между ними, устанавливать в них ОС. Некоторые ресурсы (например, сервисный процессор) могут принадлежать только первичному разделу. Из первичного раздела также происходит взаимодействие оператора со всей системой в части управления разделами.

Каждому разделу выделяется собственное подмножество физических ресурсов - процессор или процессоры, память, средства ввода-вывода и т.д. В первой реализации LPAR в V4R4 каждому разделу требовался один физический процессор (или более). В V5R1 допускается логическое разделение (квантование процессоров). Объем ресурсов процессора и памяти, выделенный разделу, может быть изменен только при перезагрузке раздела. Ресурсы же, базирующиеся на процессорах ввода-вывода, могут перераспределяться между разделами динамически.

Обычно ОС использует области, расположенные по некоторым фиксированным адресам физической памяти, для хранения каких-то системных управляющих структур, обработки прерываний и т.п. Поскольку в LPAR физическая память распределена между разделами, это становится невозможным для ОС раздела. Поэтому все программное обеспечение раздела, включая SLIC, является перемещаемым. Первичную обработку прерываний выполняет PLIC, но его функции здесь сводятся к нахождению вектора прерываний соответствующего SLIC и передаче управления на него.

Структура системного программного обеспечения AS/400 такова, что над SLIC может располагаться не обязательно OS/400, а и какая-то другая ОС. Такая возможность была использована еще в самых первых версиях системы: AS/400 обеспечивает работу также ОС своих предшественниц - System/36 и System/38. Однако реализация над SLIC "совсем другой" ОС осуществилась только в V5R1 в 2001 г. И такой ОС стала ОС Linux. Первая версия - это 32-битный Linux для PowerPC на базe ядра 2.4, но уже в 2002 г. будет реализована и 64-битная версия. Linux инсталлируется во вторичном логическом разделе AS/400 и требует всего 0,1 процессора и 64 Мбайт памяти на раздел, поэтому на одной вычислительной системе можно иметь десятки инсталляций Linux. В первичном разделе, однако, должна работать OS/400. OS/400 обеспечивает для Linux-разделов виртуальные устройства ввода-вывода, доступ к системным службам OS/400 и взаимодействие с приложениями, выполняющимися в OS/400.

Некоторое время вычислительные системы среднего класса были "нелюбимым детищем" фирмы IBM и не слишком усердно продвигались на рынке. Однако, с 1995 года ситуация кардинально меняется. AS/400 попадает в число стратегических продуктов фирмы, объемы ее продаж резко возрастают. Все программные продукты IBM оперативно портируются на эту вычислительную систему, а в ряде случаев она становится первой платформой, на которой эти продукты внедряются. AS/400 сейчас, безусловно, находится на подъеме, как в отношении своих позиций на рынке, так и в отношении развития системы. Среди постоянно развивающихся свойств AS/400 следует прежде всего отметить ее движение к Открытым Системам. AS/400 поддерживает до 90% спецификаций Single Unix Specification, и в нее включены все API Unix для бизнес-вычислений, в том числе: файловый ввод-вывод, средства взаимодействия между процессами, функции управление процессами, сигналы, нити. интерпретатор shell и т.д.

Еще одно направление развития интероперабельности системы - обеспечение интеграции служб OS/400 со службами ОС Windows 2000, которая может выполняться на одном из процессоров ввода-вывода AS/400.

В настоящее время AS/400 или iServer представляет собой семейство вычислительных систем с широкими возможностями масштабирования (старшие модели семейства отличаются по производительности от младших более чем в 300 раз), работающих под управлением OS/400 v.4.5 или v.5.1. Дальнейшее развитие и эскалацию на рынке этой системы можно прогнозировать на длительный срок.

Контрольные вопросы

  1. Какие архитектурные концепции реализованы в программном обеспечении AS/400?
  2. Программы, разработанные в конце 70-х годов для System/36 и System/38, выполняются на современных моделях AS/400, полностью используя их возможности. Какие архитектурные особенности AS/400 обеспечили такую переносимость?
  3. Сопоставьте объектно-ориентированную архитектуру AS/400 с объектно-ориентированной архитектурой Windows NT/2000. Какая система более полно воплощает объектный подход?
  4. Что дает основание утверждать, что реляционная СУБД DB2 встроена в AS/400?
  5. В чем принципиальное отличие концепции памяти AS/400 от всех других рассмотренных нами систем?
  6. Как AS/400 поддерживает работу с нитями? Сопоставьте нити AS/400 с нитями Open Unix и с нитями BSD Unix.
  7. Какие из описанных в главе 6 части I методов управления устройствами применяются в AS/400?
  8. Что представляет собой программа в AS/400? Почему программы AS/400 неуязвимы для компьютерных вирусов?
  9. Какие уровни защиты могут быть установлены для AS/400? Какими средствами обеспечивается аудит доступа на уровне 50?
  10. Какими средствами защиты памяти поддерживается система безопасности AS/400?
  11. Опишите сценарий процесса авторизации для AS/400.
  12. Сопоставьте структуры хранения информации о правах в AS/400 и в Windows NT/2000. Что между ними общего, в чем различия?
  13. Какие изменения в архитектуре системного программного обеспечения AS/400 повлекло за собой введение логических разделов?

НазадОглавлениеВперед
Индекс