Операционные системы "тонких" клиентов

В 1997 г. для BeOS была разработана новая файловая система - BFS. В ней была введена иерархическая структура файловой системы и логическая структура в значительной степени интегрировалась с физической структурой хранения. Однако наряду с иерархической логической структурой BFS поддерживает и индексирование по именам и другим атрибутам файлов и, таким образом, в полном объеме сохраняется возможность альтернативной "реляционной" навигации по файловой системе.

Единицей распределения дискового пространства является блок, размер блока выбирается из ряда: 512 байт, 1 Кбайт, 2 Кбайт, 4 Кбайт, 8 Кбайт. Файл состоит из одного или нескольких экстентов, каждый экстент - целое число последовательных блоков. План размещения файла представляет собой массив описателей экстентов. Каталоги структурированы в виде B+-деревьев. Дескрипторы файлов и элементы каталогов разделены, но несмотря на это, BFS не поддерживает "жесткие" связи (алиасы), а только "мягкие" связи (косвенные файлы). В дескрипторе файла хранятся основные его атрибуты, расширенные же атрибуты хранятся вместе с данными файла.

С введением BFS была введена и концепция виртуальной файловой системы, обеспечивающая для BeOS возможность работы с файловыми системами различных форматов (CDFS и HFS от MacOS). Ядром BeOS формируется корневой каталог виртуальной файловой системы, в котором не могут находится файлы, а только подкаталоги и "мягкие" связи. Другие физические файловые системы монтируются как подкаталоги корневого каталога. Ряд подкаталогов и связей монтируются в корневой каталог автоматически, при загрузке системы. Также автоматически монтируются и еще две виртуальные файловые системы: /dev - виртуальная файловая система устройств и /pipe - виртуальная файловая система программных каналов.

Некоторые другие интересные свойства BFS также определяются спецификой этой файловой системы:

64-разрядный размер файла - важное обстоятельство, если учесть то, что многие файлы в BFS содержат мультимедийную информацию;

использование многопоточности в работе самих модулей BFS - в соответствии с общей концепцией всей BeOS;

журналирование - свойство, которое может показаться роскошью для настольной ОС, но в BFS оно совершенно необходимо для сохранения целостности при сбоях базы данных файлов.

Интересен способ, который использует BeOS для определения типа файла, а следовательно, и приложения, по умолчанию связываемого с визуализацией и обработкой этого файла. В атрибутах файла обеспечивается идентификация типа в соответствии со спецификациями MIME (Multipurpose Internet Mail Extensions). Наряду со стандартными типами MIME, BeOS применяет также и собственные типы, не предусмотренные в MIME, но определяемые также в формате спецификации MIME. При отсутствии у файла MIME-специфицированных атрибутов для определения типа используется расширение файла, и BeOS ведет собственную "базу типов файлов", которые определяют связанные с типом-расширением приложения. BeOS также представляет пользователю возможность назначать собственные интерпретации типа для каждого файла или группы файлов.

Глава 10. Операционная система QNX

10.1 Архитектура

Операционная система QNX [32] производится компанией QNX Software Systems Ltd. с 1980 г. В настоящее время существует версия 6.1 системы. Для нас ОС QNX представляет особый интерес по двум причинам: во-первых, это ОС реального времени, во-вторых, это ОС, построенная на концепции микроядра "в чистейшем виде". Как следствие этого, QNX - легко масштабируемая система

Архитектура ОС QNX показана на рисунке 10.1.

Микроядро QNX имеет минимальный размер (всего 8 Кбайт), и в нем сосредоточены все операции, выполняемые в режиме ядра. Ядро не имеет процессов, его модули всегда выполняются в контексте процесса, их вызвавшего. Модули, сосредоточенные в микроядре, выполняют следующие основные функции:

планирование и переключение процессов и управление реальной памятью (планировщик);

первичную обработку прерываний и перенаправление их адресатам (редиректор прерываний);

обеспечение связей между процессами (средства взаимодействия);

сетевые взаимодействия (сетевой интерфейс).

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

менеджер процессов (Proc);

менеджер файловой системы (Fsys);

менеджер устройств (Dev);

сетевой менеджер (Net).

Микроядро QNX выполняет всего 57 системных вызовов, однако процессы-менеджеры ОС обеспечивают выполнение большого числа других системных вызовов, что позволило ОС QNX получить сертификат POSIX. Таким образом, ОС QNX может считаться Unix-подобной системой, хотя ее внутренняя структура далека от традиционной структуры ОС Unix.

10.2 Управление процессами

Порождение и планирование процессов обеспечивается менеджером процессов совместно с планировщиком в микроядре. Менеджер процессов выполняет порождение новых процессов, загрузку и завершение процессов. Для создания процессов имеются системные вызовы fork() и exec(), традиционные для Unix, а также spawn() - создание процесса-потомка с выполнением в нем новой программы.

QNX различает процессы, находящиеся в следующих состояниях:

готовые ( среди них - и активный процесс);

ожидающие (6 подвидов - в зависимости от причин ожидания)

мертвые (уже завершившиеся, но не передавшие информации о своем завершении).

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

FCFS;

RR;

динамическое изменение приоритета.

В последнем случае изменение приоритета производится по таким правилам:

если активный процесс полностью исчерпал квант времени и есть еще процессы с таким же приоритетом, приоритет активного процесса уменьшается на 1;

если процесс пробыл в очереди готовых процессов, не получая обслуживания на процессоре, 1 сек, его приоритет увеличивается на 1.

Всего в системе имеется 32 градации приоритетов.

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

Внешнее событие вызывает прерывание. Для обеспечения высокой реактивности прерывание должно обрабатываться немедленно. Но обработка прерывания может быть отложена по следующим причинам:

выполняется обработка прерывания с более высоким приоритетом;

выполняется нереентерабельный код микроядра (при этом обработка прерывания запрещается).

Если первый вид задержек является объективным и оправданным, то второй является нежелательным. В QNX модули микроядра тщательно оптимизированы с целью минимизации размера участков нереентерабельного кода. В результате модули микроядра также являются прерываемыми почти в любом месте. Участки кода с запрещенными прерываниями составляют в среднем всего 9 команд на входе в модуль микроядра и 14 команд - на выходе из модуля.

10.3 Средства взаимодействия

ОС QNX обеспечивает (на уровне микроядра) три средства взаимодействия процессов: сигналы, сообщения и поручения (proxy).

Механизм сигналов соответствует тому, который мы рассмотрели в разделе 9.2 части I. QNX работает с большим количеством типов сигналов, среди которых:

стандартные сигналы, определяемые POSIX;

сигналы, управляющие работой процессов;

специальные сигналы QNX;

сигналы, поддерживающие старые версии Unix.

Процесс может определять способы обработки некоторых (но не всех) сигналов.

Сообщения являются основным способом взаимодействия между процессами в QNX. В отличие от того смысла, который мы вкладывали в этот термин в разделе 9.7 части I, в QNX сообщения являются синхронными, то есть процесс, пославший сообщение, требует обязательного ответа на него.

Обмен сообщениями обеспечиваются вызовами микроядра:

Send() - посылка сообщения:

Recive() - прием сообщения;

Reply() - посылка ответа.

На рисунке 10.2 показан сценарий взаимодействия процессов при посылке сообщения

Рисунок 10.2 Сценарий взаимодействия процессов при посылке сообщения

В соответствии с протоколом передачи сообщений различаются следующие подвиды блокировки процесса:

SEND-блокированный процесс - послал сообщение и ожидает подтверждения его приема.

REPLY-блокированный процесс - получил подтверждение приема и ожидает получения ответа.

RECIVE-блокированный процесс - запросил прием сообщения и ожидает его поступления. На рисунке 10.2 состояние RECIVE-блокировки не показано, в него мог бы попасть Процесс B, если бы выполнил системный вызов Recive() прежде, чем Процесс A выполнил Send().

Модель сообщений QNX более всего напоминает взаимодействие процессов по принципу рандеву (см. раздел 8.11 части I), описываемую как:

A!x; ?y

Для взаимодействия процессов необходима "встреча" готовности одного процесса (Процесса A) передать сообщение и готовности другого процесса (Процесса B) принять сообщение. При этом для процессов, участвующих в рандеву, нет необходимости знать о готовности процесса-корреспондента. Процесс, первым пришедший в точку рандеву, просто блокируется (SEND- или RECIVE-блокировкой) до готовности процесса-партнера.

Передача ответа подтверждения не требует, и выполнение вызова Reply() не приводит к блокировке процесса, выполнившего этот вызов.

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

Несколько процессов могут послать сообщения одновременно одному адресату. В этом случае сообщения могут обрабатываться (получаться адресатом) либо в порядке их поступления, либо в соответствии с приоритетами отправителей.

Еще один вызов микроядра -Crecive() - позволяет процессу проверить наличие сообщений для него и, таким образом, избежать RECIVE-блокировки.

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

Третий вид взаимодействия - поручения - обеспечивает асинхронное взаимодействие процессов. Фактически поручения идентичны очередям сообщений, описанным нами в разделе 9.7 части I.

10.4 Файловая система

Администратор файловой системы ОС QNX позволяет стандартным образом организовать хранение и доступ к данным файловых подсистем (томов). С точки зрения логической файловой системы, хранение файлов в QNX подобно тому, какое обеспечивает ОС Unix: общее дерево каталогов с возможностью монтирования новых томов как ветвей этого общего дерева. Обеспечиваются также "жесткие" и "мягкие" связи.

На физическом уровне диск QNX структурирован так, как показано на рисунке 10.3.

Рисунок 10.3 Структура диска QNX

Загрузчик представляет собой блок начальной загрузки. Он не осуществляет загрузку собственно ОС, а выполняет выбор загрузочного файла ОС.

Корневой блок имеет структуру каталога и содержит информацию о следующих специальных файлах:

файл с именем / - корневой каталог;

файл с именем /.inodes - файл файловых индексов;

файл с именем /.boot - загрузочный файл ОС;

файл с именем /.altboot - альтернативный загрузочный файл ОС.

Загрузчик загружает операционную систему из файла /.boot, но имеется возможность загрузки и из альтернативного файла.

Битовая карта содержит информацию о свободных блоках на диске. Свободному блоку соответствует бит со значением 0, занятому - 1.

Размещение файла на диске QNX показано на рисунке 10.4.

Рисунок 10.4 Размещение файла на диске QNX

Единицей распределения дискового пространства является блок (512 байт). Пространство файлу выделяется экстентами - непрерывными последовательностями, состоящими из целого числа блоков. В элементе каталога, соответствующем файлу, содержится номер начального блока и размер для первого экстента файла. Если файлу выделено более одного экстента, то в элементе каталога содержится номер блока расширения, через который адресуются следующие экстенты файла. Если одного блока расширения недостаточно, последний элемент первого блока расширения адресует второй блок расширения и т.д.

Интересным образом обеспечиваются в QNX жесткие связи (алиасы). Показанная на рисунке 10.4 структура относится к файлу, не имеющему жестких связей. Если же для файла создается жесткая связь, то информация о размещении файла переносится в файловый индекс, находящийся в файле /.inodes. Элемент каталога в этом случае содержит номер файлового индекса, и два разных элемента каталога могут ссылаться на один и тот же файловый индекс, а следовательно, на один и тот же физический файл. Таким образом, файловый индекс для файла создается только тогда, когда нужно разделить информацию о хранении файла в логической и в физической файловых системах.

Файловый индекс создается также и для файла с длинным именем. В обычном элементе каталога предусмотрено место для 16-символьного имени файла. Если длина имени файла превышает 16 символов, для файла создается файловый индекс и информация о размещении файла переносится в файловый индекс. При этом в элементе каталога освобождается место еще для 32 символов имени, таким образом, длина имени файла может достигать 48 символов.

10.5 Управление устройствами

Интерфейс между процессами и устройствами обеспечивается менеджером устройств. Устройства включены в общее пространство имен файловой системы как специальные файлы, находящиеся в подкаталоге \.dev. Для процесса устройство представляется как двунаправленный поток байтов. Менеджер устройств управляет прохождением этого потока между процессом и устройством и отчасти осуществляет обработку данных в потоке. С каждым устройством связан блок управления termios, в котором задаются параметры обработки данных, такие как:

алгоритм передачи данных (скорость, контроль четности и т.д.);

отображение символов, вводимых с клавиатуры, на экране;

трансляция вводимых символов;

программное и аппаратное управление потоком данных;

и т.д., и т.п.

Данные, которыми обмениваются менеджер устройств и драйвер, проходят через набор очередей, с каждым устройством связаны по три очереди:

входная очередь;

выходная очередь;

так называемая, каноническая очередь - очередь ввода данных с редактированием.

Общий размер всех трех очередей не превышает 64 Кбайт. Очереди обслуживаются по дисциплине FIFO, независимо от приоритетов процессов, которым принадлежат данные в очередях. Для обеспечения высокой эффективности ввода-вывода сам менеджер устройств выполняется как процесс с высоким приоритетом. Это не сказывается на быстродействии других процессов, так как управление вводом-выводом никогда не занимает процессор надолго. Драйверы также выполняются как отдельные процессы, их приоритеты зависят от особенностей обслуживаемых ими устройств.

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

Запрос данных при пустой входной очереди приводит к блокировке процесса. Также блокируется процесс и тогда, когда пытается вывести данные при переполненной выходной очереди.

10.6 Сетевые взаимодействия

С самого начала QNX создавалась как сетевая ОС и это выражается прежде всего в том, что средства взаимодействия локальных и удаленных процессов в QNX одни и те же - сообщения. Процесс не видит разницы во взаимодействии с локальным или удаленным корреспондентом. Такое свойство обеспечивается при помощи "виртуальных каналов", показанных на рисунке 10.5.



Рисунок 10.5 Посылка сообщения через виртуальный канал

Виртуальный канал создается процессом-отправителем сообщения При этом на узле отправителя и на узле получателя создаются виртуальные процессы, каждый из которых представляет на локальном узле идентификатор процесса - удаленного корреспондента. Реальный процесс имеет реальный идентификатор (PID), виртуальный процесс - виртуальный идентификатор (VID). VID обеспечивает соединение, которое содержит следующую информацию:

локальный PID;

удаленный PID;

удаленный NID (идентификатор узла сети);

удаленный VID.

Процессы QNX имеют символьные имена, причем эти имена могут быть глобальными, доступными во всей сети. Приложение может по имени получить PID процесса - удаленного корреспондента. При этом система автоматически создает виртуальный канал и для приложения этот канал отождествляется с PID корреспондента.

Администратор сети обеспечивает создание виртуальных каналов, буферизацию данных в канале и контроль целостности виртуальных каналов.

10.7 Графическая система Photon

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

В отличие от других графических систем, которые обеспечивают функции графического интерфейса в монолитной (Windows) или клиент/серверной (X Window) модели, Photon строится на базе компактного графического микроядра и распределения графической функциональности между взаимодействующими процессами. Архитектура графической системы показана на рисунке 10.6, и она очень похожа на архитектуру QNX в целом.

Рисунок 10.6 Архитектура графической системы Photon

Микроядро Photon, которое является процессом QNX, выполняет необходимый минимум графических функций. Микроядро Photon занимает всего 55 Кбайт памяти. Прочие части графической системы - также процессы, которые для выполнения базовых функций обращаются к микроядру Photon, используя средства взаимодействия, обеспечиваемые микроядром QNX. Менеджеры графической системы являются опционными, включение новых менеджеров расширяет функции системы. До некоторой степени ключевым компонентом, определяющим переход от интерфейса встроенной системы к WIMP-интерфейсу, является менеджер окон, который обеспечивает изменение размера, минимизацию, перемещение и т.д. для окон.

Работа системы Photon строится на концепции "трехмерного пространства событий", которая иллюстрируется на рисунке 10.7.

Рисунок 10.7. Движение через пространство событий

Событиями в системе являются как события, инициируемые пользователем (мышью, клавиатурой), так и события, инициируемые процессами. Пространство, через которое движутся события, представляется как набор параллельно размещенных прямоугольных областей. Метафорой, давшей название системе, является движение частицы света (фотона) через ряд стеклянных пластин. На одном конце этого ряда находится корневая область, создаваемая системой, на другом конце - та область, которая представляется пользователю. Процесс, который выполняет какие-либо функции, связанные с интерфейсом, помещает свою область в этот ряд. Каждая область имеет две маски для проходящих через нее событий: маску чувствительности и маску непрозрачности. Установка бита чувствительности для определенного события определяет передачу события для обработки процессу, связанному с областью. Установка для события бита непрозрачности определяет прекращение движения события через пространство. Графические драйверы являются процессами, которые помещают свои области на переднем (ближнем к пользователю) краю ряда. Это обеспечивает также возможность распределенной обработки в сети: приложение с графическим интерфейсом может работать в одном узле сети, а результат его работы отображаться на другом узле. Физический драйвер целевого узел просто помещает свою область на переднем краю пространства событий. Подобным образом обеспечивается и отображение результатов работы приложений QNX в других графических системах: вместо драйвера в пространство событий вставляется область переходника в систему Windows или X Window.

Глава 12. Операционные системы мейнфреймов

12.1 История и архитектура мейнфреймов

Обычно на русский язык термин "мейнфрейм" переводится как "большая ЭВМ универсального назначения". Однако нам представляется, что в настоящее время такое определение уже не является точным. Современные мейнфреймы не универсальны. Они специализированы как компьютеры для обработки больших и сверхбольших объемов данных или как суперсерверы. Название одного из поколений мейнфреймов IBM ESA (Enterprise System Architecture - архитектура систем масштаба предприятия) достаточно точно отражает такую специализацию

Мейнфреймы фирмы IBM [7] имеют почти 40-летнюю историю развития, причем, развитие это протекало эволюционно, во всяком случае, с точки зрения пользователей. При любых изменениях в аппаратной архитектуре каждое следующее поколение мейнфреймов обеспечивало выполнение программного обеспечения, разработанного для предшествующих поколений, почти в полном объеме.

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

Семейство мейнфреймов IBM System/360, появившееся в начале 60-х годов, стало значительной вехой в истории вычислительной техники. Во-первых, это были первые ЭВМ, которые начали выпускаться серийно, а не по индивидуальным проектам, во-вторых, они стали первым семейством ЭВМ, то есть набором моделей с разной производительностью и разной стоимостью, но с переносимостью программного обеспечения с одной модели на другую. Семейство IBM System/360 строилось на базе CISC-процессоров с богатым набором команд и несколькими режимами адресации. Эти процессоры, однако, не поддерживали динамическую трансляцию адресов, поэтому программное обеспечение работало с реальной памятью, привязка адресов осуществлялась при загрузке. (Точнее - во время выполнения, в момент загрузки "базовых" регистров, но загруженная в реальную память программа уже не могла быть перемещена.) Размер адресной шины составлял 24 бит, что позволяло адресовать 16 Мбайт памяти - реальной и виртуальной. Чрезвычайно сильным свойством IBM System/360 явилась архитектура каналов ввода-вывода [8] (см. главу 6 части I). Достоинства мейнфреймов IBM System/360 определили ведущее положение этого семейства на рынке вычислительной техники в течение всех 60-х и начала 70-х годов, и первое время конкуренты IBM, вынуждены были делать собственные компьютеры программно совместимыми с IBM System/360.

Следующим поколением мейнфреймов стало семейство IBM System/370. Принципиальным отличием его от предыдущего поколения явилось введение динамической трансляции адресов. Применялась сегментно-страничная модель трансляции, во всех ОС этого поколения каждому процессу выделялся один сегмент адресного пространства (АП), то есть, процесс обладал собственной виртуальной памятью размером в 16 Мбайт. Однако в этом поколении проявилось некоторая "успокоенность" фирмы IBM. Фирма упустила из виду одно из конкурирующих направлений развития вычислительной техники, а именно - мини-ЭВМ, так называемые, Unix-машины, ведущим производителем которых в то время была фирма Digital Equipment. Нововведений семейства IBM System/370 оказалось недостаточно, чтобы сохранить почти монопольное положение на рынке, и именно тогда возникла первая "легенда о смерти мейнфреймов".

Отличие семейства IBM System/370/XA (eXtended Architecture - расширенная архитектура) от предыдущего поколения было достаточно революционным: адресная шина расширилась до 31 бита, что позволило адресовать виртуальную память до 2 Гбайт (при этом сохранилась совместимость и со старыми 24-разрядными моделями). Другим принципиально важным нововведением расширенной архитектуры явилось введение в подсистему ввода-вывода возможности динамического определения пути к устройствам ввода-вывода и поддержка SMP-архитектуры.

Следующим поколением стало семейство IBM ESA/370. В этом семействе появилась возможность адресовать до 16 2-Гбайтных виртуальных АП. Важнейшим из других возможностей, по-видимому, явилось свойство PR/SM (Partition Resources/System Management), обеспечивающее возможность разбиения (на микропрограммном уровне) ресурсов вычислительной системы на независимые логические разделы. Семейства 370/XA и ESA/370 определили новую специализацию мейнфреймов, однако еще не вывели фирму IBM в абсолютные лидеры.

Дальнейшее развитие мейнфреймов происходило во многом благодаря конкуренции IBM с японскими фирмами (Hitachi, Fujitsu), выпускающими собственные мейнфреймы, программно совместимые с IBM. Новое семейство - IBM ESA/390 интегрировало в себе большое количество нововведений, которые в итоге определили "второе рождение" мейнфреймов. Среди этих нововведений - увеличение регистрового массива, новые средства защиты памяти, новые средства работы с числами с плавающей точкой, оптоволоконные ESCON-каналы, встроенные криптографические процессоры и аппаратная поддержка сжатия данных и, конечно, sysplex - средство комплексирования вычислительных систем. В этом семействе произошел также переход мейнфреймов на CMOS-технологию, что привело к тому, что по размерам и по энергопотреблению они стали сравнимы даже с ПЭВМ.

Семейство ESA/390 прочно восстановило позиции мейнфреймов в мире информационных технологий, но дальнейшее развитие требований к обработке данных повлекло за собой и появление нового семейства мейнфреймов - z/900 [40]. Главная особенность новой архитектуры - расширение адресной шины до 64 разрядов. Для понимания функционирования программного обеспечения и ОС мейнфреймов мы приведем некоторые минимальные сведения об аппаратной части z-архитектуры. На рисунке 12.1 показана логическая структура современного мейнфрейма, так называемого z-сервера.

Рисунок 12.1 Логическая структура z-сервера

Основные вычислительные свойства реализуются на симметричной многопроцессорной (до 16 z-процессоров) конфигурации. Однако реально процессоров может быть и больше, так как конфигурация может включать в себя, помимо основных z-процессоров, специализированные сервисные процессоры, криптографические процессоры, процессоры ввода-вывода и т.д. Z-процессор, как и все предыдущие поколения центральных процессоров мейнфреймов, является CISC-процессором. Свойства CISC используются в этой архитектуре в полной мере. Обязательной составной частью z-архитектуры является Лицензионный Внутренний Код (LIC), реализованный на уровне микропрограмм процессора. Интенсивное использование микропрограммирования позволяет включить в систему команд процессора очень мощные команды, обеспечивающие значительную поддержку работы операционных систем и даже конкретных приложений. Одно из различий в моделях z-процессоров состоит в том, реализованы те или иные команды в них аппаратно (в более производительных моделях) или микропрограммно.

Основной аппаратной структурой, в которой фиксируется состояние процессора, является 16-байтное Слово Состояния Программы (PSW - Program State Word). В нем отражается адрес выполняемой команды, состояние задача/супервизор, режим адресации и т.п. Дополнительная информация о состоянии содержится еще в 16 8-байтных управляющих регистрах. В системе имеется 16 8-байтных регистров общего назначения (пара смежных таких регистров может использоваться для представления 16-байтного значения) и 16 16-байтных регистров плавающей точки.

Система имеет основную (оперативную) и расширенную память. Команды и обрабатываемые данные находятся в оперативной памяти. Расширенная память является необязательным компонентом системы. Она используется как дополнительный буфер между оперативной и внешней памятью. Данные могут перемещаться между основной и расширенной памятью постранично - командами PAGE IN и PAGE OUT.

В z-процессоре адрес имеет размер 64 бита, что позволяет работать с адресным пространством (АП) размером 16 эксабайт, однако процессор поддерживает и "старые" режимы адресации - с 31-битным и 24-битным адресом (режим определяется состоянием соответствующих разрядов PSW).

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

Абсолютный адрес - адрес в реальной памяти, фактический адрес ячейки памяти.

Реальный адрес, как правило, совпадает с абсолютным, кроме реальных адресов, меньших 8 Кбайт. Реальный адрес, меньший 8 Кбайт, преобразуется в абсолютный путем префиксации - добавления к нему значения, записанного в префиксном регистре. Область реальной памяти до 8 Кбайт используется для специальных целей системой прерываний и ввода-вывода, префиксация обеспечивает для каждого процессора в многопроцессорной системе собственную область младших адресов памяти.

Виртуальные адреса различаются четырех типов: первичные, вторичные, домашние и определяемые регистрами доступа. Для виртуальных адресов разного типа по-разному выполняется динамическая трансляция адреса. Режим динамической трансляции задается определенными битами PSW и управляющих регистров. В зависимости от режима, в процессе динамической трансляции адресов используются от двух до пяти управляющих таблиц переадресации (3 таблицы областей, таблица сегментов, таблица страниц). В системе имеется также 16 AR-регистров (регистры доступа). Регистр AR0 содержит указатель на таблицы переадресации для первичного АП. Регистры AR1-AR15 позволяют приложению адресовать еще 15 дополнительных АП.

Защита памяти в мейнфреймах z-архитектуры включает в себя традиционную для многих компьютерных систем изоляцию АП виртуальной памяти, бит защиты от выборки, бит обращения и бит изменения в дескрипторах страниц, а также предусматривает механизм, основанный на применении ключей защиты памяти. Такой ключ приписывается каждой 4-килобайтной странице. В дескрипторе каждого страничного кадра имеется 4-битный ключ доступа, обеспечивающий авторизацию программ при обращении к памяти. Каждая программа имеет свой 4-битный ключ доступа, который при выполнении программы заносится в определенные разряды PSW. При каждом обращении к памяти ключ защиты, который выбирается из PSW, сравнивается с ключом страницы, к которой происходит обращение. Запись разрешается, только при совпадении ключей. Системные (привилегированные) программы выполняются с нулевым ключом защиты, что дает им доступ к любой странице памяти.

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

Параллельные канальные пути, служащие для поддержки интерфейса ввода-вывода System/360 и System/370; такой путь представляет собой электрические проводные соединения между канальной подсистемой и одним или несколькими контроллерами. До 8 контроллеров и до 256 устройств могут использовать совместно один параллельный путь.

Последовательные канальные пути ESCON и FICON состоят из двух фибероптических кабелей, динамических переключателей и контроллеров. Динамическое переключение может быть выполнено между двумя любыми последовательными канальными путями в этой же или в другой канальной подсистеме. К каждому контроллеру последовательного интерфейса может быть подключено до 256 внешних устройств.

Внешний таймер (ETR - external time reference) обеспечивает синхронизацию часов мейнфреймов, объединенных в тесно связанный комплекс (Parallel Sysplex).

Аппаратные средства z-архитектуры поддерживают программное обеспечение всех предыдущих архитектур мейнфреймов IBM, аналогично и ОС мейнфреймов развиваются эволюционным путем [21]. Эта эволюция происходит по трем параллельным линиям, история которых представлена на рисунке 12.2.

12.2 Операционная система VSE/ESA

Линия ОС, представляемая сегодня VSE/ESA v.2.6 [21, 24, 38], ориентирована на применение на младших, наименее мощных моделях мейнфреймов. Поэтому ей свойственны более простые решения, запаздывающее внедрение новых свойств аппаратной платформы (в частности, она пока не использует новых возможностей z-архитектуры), отсутствие развитых средств управления производительностью. Хотя имеется много примеров успешного построения промышленных информационных систем на базе VSE, ее основное назначение - поддерживать "унаследованное" программное обеспечение, разработанное для предшествовавших версий аппаратуры и ОС. Программисту, воспитанному на ПЭВМ, это может показаться странным, но в сфере промышленной обработки данных достаточно широко применяется программное обеспечение, разработанное 20 и более лет назад. За столь длительный срок эти программы доказали свою полезность и надежность, и у пользователей нет оснований от них отказываться.

Среда выполнения, которую VSE обеспечивает для приложений, показана на рисунке 12.3. Эта среда обеспечивается отчасти обязательными компонентами в составе ОС, отчасти - опционными компонентами ОС, отчасти - промежуточным программным обеспечением. Ниже вкратце рассматриваются компоненты, создающие эту среду.

Рисунок 12.3 Среда выполнения приложения в VSE/ESA

Базовые управляющие средства обеспечиваются обязательным компонентом ОС, который носит название VSE/AF (Advanced Functions). В состав этого компонента входят: ядро ОС - супервизор, обеспечивающее управление памятью, управление задачами (в терминологии IBM задача означает процесс), базовые функции управления заданиями и базовые функции управления файлами, некоторые системные утилиты и т.д.

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

Аббревиатура VSE расшифровывается как Virtual Storage Extension - расширение виртуальной памяти. Это название сложилось исторически, но сейчас его нельзя считать вполне точным. Первая ОС этой линии - DOS - работала только с реальной памятью. Реальная память разбивалась на разделы фиксированного размера, и в каждом разделе выполнялась одна задача. В DOS/VSE за счет динамической трансляции адреса System/370 создавалось виртуальное АП размером 16 Мбайт, которое затем разбивалось на разделы фиксированного размера - и для такой модели название VSE является вполне справедливым. Однако, уже в VSE/SP и далее - в VSE/ESA появилась возможность создавать для каждого раздела независимое АП размером 16 Мбайт (а позже - 2 Гбайт). Структура памяти для современных версий VSE представлена на рисунке 12.4.

Рисунок 12.4 Структура памяти VSE/ESA

Нижняя часть виртуальной памяти - общая для всех разделов, в ней размещается ядро ОС - супервизор. Выше располагается совместно используемая область виртуальной памяти, которая содержит программы и данные, доступные для всех разделов. Другая совместно используемая область находится в верхней части 2-Гбайтного АП. Разделение совместно используемой области на две части связано с переходом от 24-разрядного адреса к 31-разрядному. Унаследованные программы с 24-разрядной адресацией видят только часть АП до 16 Мбайт, в которой есть все, что им нужно. Программы же, созданные с учетом 31-разрядной адресации, видят все 2 Гбайт АП, в том числе, и расширение разделяемой области.

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

При старте системы автоматически создается 12 статических разделов. В системе есть также возможность создавать и динамические разделы (до 200 разделов) - такие разделы создаются автоматически при запуске задачи в области динамических разделов и уничтожаются при ее завершении. Кроме того, 31-разрядным приложениям ОС может предоставлять (через регистры AR) 2-Гбайтные "пространства данных", которые могут использоваться для хранения данных. В этих пространствах также могут создаваться виртуальные диски.

В части статических разделов, как правило, уже при старте системы запускаются системные задачи. Так, в разделе 0, который называется BG, обычно запускается задача связи с оператором - BG; в разделе 1 - задача POWER и т.д. Разделы этих задач, выполняющих обязательное общесистемное обслуживание, обычно (но не обязательно) размещаются в общей части АП, как показано на рисунке 12.4.

Управление задачами

Единицей работы в ОС является задание (job). Задание состоит в последовательном выполнении нескольких шагов-задач (task) - программ (в частном случае задание может состоять из единственного шага). Задание характеризуется классом (буква) и приоритетом (число). Для каждого раздела оператором задаются классы заданий, выполняемых в разделе, и приоритет класса в разделе. Задания одного класса выбираются на выполнение в соответствии с числовым приоритетом, а при равенстве приоритетов - в порядке поступления. Классы и приоритеты заданий определяют порядок, в котором задания выбираются на выполнение, но не дисциплину распределения процессорного времени.

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

При работе VSE/ESA на многопроцессорной конфигурации только один процессор в каждый момент времени может выполнять код в режиме супервизора (привилегированном режиме).

Задания в VSE/ESA бывают двух видов - пакетные и интерактивные. Базовые средства VSE/AF обеспечивают обработку пакетных заданий. Пакетное задание представляет собой набор операторов языка управления задания JCL на перфокартах (виртуальных). Основными операторами языка JCL являются:

// JOB - оператор заголовка задания;

// OPTION - оператор установки параметров/режимов выполнения задания;

// EXEC - шаг задания, вызов на выполнение программы;

// ASSIGN - назначение физического устройства логическому файлу программы для шага задания;

// DLBL - назначение физического дискового файла логическому файлу программы для шага задания;

// EXEC PROC - выполнение процедуры в шаге задания; процедура представляет собой хранимый в библиотеке набор операторов JCL; процедура может иметь параметры и содержать некоторую логику (ветвление в зависимости от значений параметров и результатов выполнения отдельных шагов).

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

Обязательным компонентом VSE является VSE/POWER - подсистема управления входными и выходными и выходными очередями. POWER обычно запускается в разделе F1 и располагается в реальной памяти. POWER выполняет следующее:

читает задания из различных источников и записывает их во входную очередь, располагающуюся на диске (очередь RDR);

выбирает задания из очереди RDR (в соответствии с их параметрами) в соответствующие разделы и инициирует их выполнение;

записывает выходные данные приложений в очереди LST (печать) и PUN (вывод на перфокарты);

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

для сетевой среды POWER создает также очередь XMT для передачи данных между узлами сети.

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

Описанные выше классы и приоритеты заданий относятся к входной очереди, RDR. Данные, выводимые в выходные очереди, также имеют классы и приоритеты, задаваемые независимо от входных. VSE/POWER имеет собственный управляющий язык JECL (Job Entry Control Language), основное назначение операторов которого - определение классов и приоритетов данных в очередях.

Файловая система

Сочетание структуры файлов на внешней памяти и способов обработки файлов в программе составляет метод доступа. В VSE/ESA применяются две группы методов доступа: базисные методы - BAM, "унаследованные" от старых версий и виртуальный последовательный метод - VSAM (применяемый также и в z/OS как единственная для этой ОС структура файловой системы). Обычно при инсталляции VSE создаются два дисковых тома. На этих томах устанавливаются системные файлы и библиотеки, но также остается место и для пользовательских файлов. Первичное управление дисковым пространством выполняется средствами BAM. На каждом диске выделяется пространство - область VSAM. С точки зрения BAM, вся эта область представляется как один файл, но внутри этого файла средства VSAM обеспечивают собственное управление дисковым пространством и создание VSAM-файлов.

В начале каждого диска находится метка тома (VOL1), содержащая имя тома и указатель на размещение оглавления тома. Оглавление тома - структура VTOC - содержит информацию о размещении на томе BAM-файлов. Средства BAM фактически перекладывают управление дисковым пространством на программиста: при создании файла программист должен явным образом указать физический адрес файла на диске и его размер. Это выполняется средствами языка управления заданиями: после оператора // DLBL, относящегося к создаваемому файлу должен следовать один или несколько операторов // EXTENT, задающих адреса и размеры участков файла. BAM-файл располагается в одном или нескольких (до 16) непрерывных участках дискового пространства. Дисковое пространство выделяется сразу при создании файла и не может быть перераспределено в дальнейшем. Элемент VTOC для каждого файла содержит его имя и до 16 пар "адрес-размер" для каждого участка. - Утилита VTOC помогает программисту вести карту распределения дискового пространства.

Основные файлы BAM, создаваемые на диске DOSRES при инсталляции системы:

системная библиотека IJSYSRS.SYSLIB, необходимая для начальной загрузки системы;

область страничного обмена;

область очередей POWER;

области файлов ICCF, CICS и других системных программ;

каталог VSAM;

область VSAM.

Часть системных библиотек и файлов инсталлируется в области VSAM.

Информация обо всех VSAM-файлах на диске сохраняется в каталоге VSAM. Каталог VSAM должен быть на каждом томе, содержащем область VSAM.

Для файлов VSAM дисковое пространство выделяется динамически, и файл может занимать несмежные участки дискового пространства. Пространство выделяется блоками фиксированного размера (размер выбирается), план размещения файла представляет собой B+-дерево. Кроме того, "листья" дерева связаны в линейный список, что позволяет осуществлять быстрый последовательный доступ к данным файла. VSAM поддерживает физические стуктуры файлов четырех типов:

ESDS (entry-sequenced data set) - неупорядоченные записи фиксированной или переменной длины;

KSDS (key-sequenced data set) - записи фиксированной или переменной длины, упорядоченные по ключам;

RRDS (relative-record data set) - записи фиксированной длины, упорядоченные по номерам;

VRDS (variable-length relative-record data set) - записи фиксированной или переменной длины, упорядоченные по номерам.

Физическая структура файлов ESDS очевидна. Для файлов RRDS память выделяется сразу для всех записей файла, и относительная позиция записи вычисляется. В RRDS-файле могут быть "пустые места" - для записей, еще не занесенных в файл. Для файлов KSDS и VRDS строится индекс (B+-дерево с линейным списком листьев) ключей или номеров соответственно. Для этих файлов возможно создавать также любое количество альтернативных индексов - по любым другим ключам, альтернативный индекс ссылается на основной индекс. Хотя физическая структура файлов в VSE - записеориентированная, системный API предоставляет как записе-, так и байториентированный интерфейс.

Логическое структурирование хранения информации и в BAM, и в VSAM основывается на концепции библиотек. Библиотека является контейнерным объектом, содержащим одну или несколько подбиблиотек. Подбиблиотеки содержат разделы (файлы). Память выделяется для библиотеки, библиотеки BAM не могут увеличиваться в размерах сверх выделенного им пространства. Память для подбиблиотек выделяется динамически в пределах пространства библиотеки. Обычно подбиблиотеки объединяют в себе данные одного определенного типа - исходные, объектные или загрузочные модули. Системная утилита LIBR обеспечивает операции по обслуживанию библиотек.

ICCF

Наряду с пакетными заданиями, в VSE есть возможность и интерактивной работы. Она обеспечивается компонентом VSE/ICCF (Interactive Computing Control Facility). ICCF не является строго обязательным компонентом ОС, но применяется практически при всех ее инсталляциях. ICCF выполняется в отдельном статическом разделе и обеспечивает пользователю терминала следующие возможности:

ввод, просмотр и редактирование программ, заданий и данных;

запуск с терминала заданий - интерактивных или пакетных в POWER;

ведение библиотек ICCF (см. ниже);

доступ к файлам VSE;

доступ к очередям;

интерактивное выполнение системных утилит;

организацию и выполнение потока заданий в интерактивном разделе.

Для взаимодействия с пользователем ICCF использует несколько типов полноэкранных панелей:

панели выбора (меню);

панели ввода данных;

списковые панели;

панели подсказок;

панель текстового редактора.

ICCF обеспечивает собственные библиотеки и подбиблиотеки, предназначенные прежде всего для хранения текстов программ и заданий. Файлы в библиотеках ICCF состоят из записей размером 88 байт, из которых первые 80 используются для данных, а в 8 байтах находятся два указателя, связывающие записи файла в двунаправленный список. Для библиотек ICCF определяются права доступа. С точки зрения доступа имеется три типа библиотек:

COMMON - библиотеки, содержащие некоторую общую информацию (общие процедуры, макросы и т.п.), к таким библиотекам имеют доступ все пользователи, но только для чтения, только системный администратор имеет доступ к этим библиотекам для записи;

PUBLIC - библиотеки, доступные всем пользователям для чтения и для записи;

PRIVATE - библиотеки, доступные только для одного пользователя.

Права доступа назначаются системным администратором.

Другие компоненты

Для обеспечения одновременной работы многих пользователей и ряда других своих функций ICCF использует компонент VSE/CICS (Customer Information Control System), который обязательно должен устанавливаться вместе с ICCF.

Функциональность CICS значительно шире, чем только поддержка интерактивного интерфейса VSE. CICS является мощным сервером транзакций, который доступен на всех аппаратных и операционных платформах IBM и применяется для обеспечения совместного доступа к данным множества разноплатформенных компонентов информационной системы. VSE/CICS представляет собой набор программных единиц и системных таблиц, которые выполняются в отдельном статическом разделе и обеспечивают:

безопасность - авторизацию доступа пользователей к данным;

управление терминалами;

управление задачами - с мультипрограммным управлением транзакциями в разделе CICS;

управление программами, включая поддержку множественных языковых сред и параллельное выполнение транзакций в одной программе;

сериализацию доступа к данным параллельно выполняющихся транзакций;

ведение журнала и восстановление целостности данных после сбоев.

Во всех промышленных применениях VSE CICS является практически обязательным компонентом, и прикладные программы для таких применений создаются с использованием платформенно-независимого API CICS для доступа к данным.

VSE/BTAM (Basic Telecommunication Access Method) является базовым телекоммуникационным методом доступа, обеспечивающим управление локальными и удаленными устройствами с использованием протоколов BSC или Asynch. BTAM не требует отдельной инсталляции и входит в состав VSE/AF.

VSE/VTAM - (Virtual Telecommunication Access Method) является дополнительным методом телекоммуникации, управляющим взаимодействиями между устройствами в сети SNA. Он поддерживает локальные и удаленные рабочие станции в одно- или многомашинной сети. Если VSE/ESA установлена в узле сети, VTAM позволяет:

пользователям и приложениям получать доступ к приложениям, установленным в другой системе;

обмениваться данными с другими системами;

другим системам получать доступ к VSE.

VTAM устанавливается как опционный компонент VSE/ESA и выполняется как задача в отдельном статическом разделе.

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

z/OS (раньше - OS/390, еще раньше - MVS) является стратегической для IBM ОС мейнфреймов [21, 24, 41]. Именно в этой ОС в первую очередь осваиваются новые свойства аппаратной платформы, именно в этой ОС в первую очередь становятся доступными новые версии стратегических продуктов промежуточного программного обеспечения, именно эта ОС рассчитана на применение в самых мощных и производительных вычислительных комплексах и sysplex'ах (тесно связанных многомашинных комплексах, которые "выглядят" с точки зрения управления и распределения нагрузки как одна вычислительная система). Последняя на сегодняшний день версия этой ОС - z/OS V1R3.