В z/OS применяются не имеющая аналогов файловая система, поддержка функций Unix, непревзойденные возможности управления рабочей нагрузкой и масса других особенностей, сделавших ее кладезем интересных идей. На мэйнфреймах IBM zSeries может работать много различных ОС, в том числе z/Linux, z/TPF, z/VM и даже Open Solaris, однако z/OS среди них остается флагманом.
Аппаратная платформа
В отличие от серверов старшего класса, работающих под управлением различных вариантов Unix, z/OS может работать только на мэйнфреймах IBM («копировщики» теперь практически отсутствуют на рынке) или на компьютерах с программным обеспечением, эмулирующем zSeries, например на х86-совместимых компьютерах, оснащенных FLEX-ES, или Hercules [1]. Особенностью нашей страны является использование унаследованных приложений, разработанных еще для ЕС ЭВМ. В учебных курсах ряда известных отечественных вузов рассматриваются некоторые аппаратные возможности этих компьютеров и программные средства ОС – предшественников z/OS.
Cамый дешевый способ для работы с z/OS – эмуляция zSeries, в том числе на ПК, при этом возможно и подсоединение внешних устройств мэйнфреймов к специальным канальным адаптерам PCI. В рамках S/390 (предшественник zSeries) выпускался недорогой одно- или двухпроцессорный мэйнфрейм MP3000, имеющий в конфигурации внутренний диск, каналы, сервисный процессор (System Assist Processor, SAP) и др. Ну и, наконец, можно применять большие мэйнфреймы IBM – cерверы zSeries z9 и z10. Последние могут иметь до 64 процессоров, оперативную память емкостью до 1,5 Тбайт, поддерживают большое число каналов ESCON/FICON и др.
Центральная часть z10 – Central Processor Complex (СРС) содержит процессорные устройства (PU), оперативную память и каналы. Имеется много типов PU: традиционные центральные процессоры (СРU), IFL (Integrated Facility for Linux, разновидность центральных процессоров, в которой заблокированы некоторые команды, на них z/OS работать не может), zAAP (z10 Application Assist Processor, спецпроцессор для работы с базами данных, с приложениями ERP и CRM и т.п.), а также ICF (Integrated Coupling Facility, предназначен для работы с кластерами Sysplex) и SAP.
В z10 имеется четыре типа каналов: ESCON/FICON, Express4, OSA Express3, HiperSockets. CPC может быть сконфигурирован с несколькими разделами (в разных разделах могут работать разные ОС), каждый из которых может содержать несколько процессорных устройств и каналов (рис. 1).
В S/370 и ЕС ЭВМ применялись параллельные каналы, которые имели адрес вида CKU, где C, K, U – шестнадцатеричные цифры, задающие соответственно номер канала, номер устройства управления (контроллера, к которому подсоединялись внешние устройства – до восьми устройств управления на канал) и номер внешнего устройства (до восьми внешних устройств на устройство управления). В сменивших параллельные каналы волоконнооптических каналах ESCON/FICON реализовано подсоединение одного устройства управления, или, чаще, порта коммутатора, что позволяет разделять устройства управления и внешние устройства между разными компьютерами [3, 4].
Эти каналы идентифицируются шестнадцатеричными числами СHPID (Channel Path Identifier). Программное обеспечение z/OS «видит» адрес («номер») внешнего устройства, содержащий до четырех шестнадцатеричных цифр, включающий CHPID, номер порта коммутатора, адреса устройства управления и внешнего устройства. Номер внешнего устройства помещается в оперативную память в Hardware Save Area при включении питания – на основе данных из конфигурационного файла IOCDS, доступного из SAP. Как и в операционной системе ЕС ЭВМ, каждое внешнее устройство в z/OS имеет свой управляющий блок UCB [5].
Традиционно в мэйнфреймах IBM применялись жеские диски с «архитектурой» CKD (Counter-Key-Data – «cчетчик-ключ-данные»), в отличие от современных дисков с поблочной организацией записи/чтения [3]. Последние диски СКD-типа, IBM 3390 (с устройством управления IBM 3990, которое подключалось к четырем каналам), имели длину дорожки 56 664 байт (точнее, 3390 имело расширенную архитектуру ECKD, предназначенную для работы с ESCON/FICON и предполагавшую чтение/запись дорожек целиком). Сегодня эти диски эмулируются в системах хранения (например, IBM Enterprise Storage Server 2105 или DS8000), основанных на обычных жестких дисках с интерфейсом SCSI (SAS).
Другие типы каналов zSeries используются для более специализированных целей, например OSA Express – для соединения с локальной сетью, HiperSockets – для высокоскоростных (на скорости оперативной памяти) TCP/IP-коммуникаций между разделами z10.
Структура
ОС z/OS быстро развивается – последняя версия V1.10 появилась осенью 2008 года. Уже одни отличия V1.10 от предыдущей заслуживают отдельного рассказа; отметим лишь поддержку страниц памяти емкостью 1 Мбайт и cредства HiperDispatch для улучшения диспетчеризации при большом числе процессоров. Работавшие с ранними версиями операционной системы MVS или даже ЕС ЭВМ обнаружат в z/OS огромные пласты известных вещей: язык управления заданиями JCL, среду для интерактивной работы TSO, знакомые утилиты с префиксами IEB и IEH, утилиты ICKDSF и IDCAMS, программу дампа/восстановления дисков ADRDSSU и массу всего другого. Обратная совместимость является одним из основополагающих принципов z/OS.
z/OS является 64-разрядной ОС с виртуальной памятью, позволяющей адресовать 16 экзабайт (~18 x 1018 байт). В z/OS используется и преобразование виртуальных адресов в реальные (физические) адреса оперативной памяти, и свопинг.
Как и в предшествовавших z/OS операционных системах, ее работа управляется с применением большого числа управляющих блоков одного из четырех типов: относящихся к системе в целом, к отдельному ресурсу (например, внешнее устройство), к заданию (Job) или задаче (Task). Так, TCB – это блок управления задачей; блок SRB (Service Request Block) представляет запрос на сервис системы, а блок ASCB управляет адресным пространством (Address Space, AS).
AS – это непрерывный диапазон адресов, который z/OS присваивает пользовательской программе. Внутри AS пользователь может иметь много задач (и много TCB), что обеспечивает мультипрограммирование. AS является аналогом процесса в Unix, а ASID – аналогом PID; TCB управляет аналогом нити в Unix.
z/OS использует много AS: минимум по одному для каждого задания и каждого пользователя TSO, включая заходивших по telnet/ftp. Пользователи так называемых «подсистем» (СICS, IMS) работают в соответствующем им AS [5].
Уникальной особенностью z/OS является эффективная «равноправная» поддержка как пакетной обработки с большим объемом исходных данных и результатов (например, ежемесячных или ежеквартальных отчетов разных типов), так и оперативной обработки транзакций (например, транзакции банкоматов). Они прекрасно сочетаются даже в условиях резких изменений рабочей нагрузки, обеспечивая как необходимое время реакции для интерактивных работ, так и высокую пропускную способность для пакетных работ. Это достигается во многом благодаря средствам балансировки нагрузки Workload Manager, дополняющим известные еще по MVS средства System Resource Manager [6].
Интерактивная обработка и Unix
Интерактивная обработка в z/OS осуществляется в среде TSO/E, хорошо известной пользователям MVS. В TSO можно работать традиционным образом – применяя систему меню и панелей ISPF (Interactive System Productivity Facility) и командные языки CLIST и REXX. Для работы в TSO необходимы дисплеи IBM3270 (в СССР их аналогом были ЕС7920); их можно просто эмулировать на ПК. Но для ISPF можно установить и различные графические пользовательские интерфейсы, и тогда работать с мышью [5].
TSO и ISPF работают c традиционными для MVS наборами данных – с файловой системой, ориентированной на записи. Но из среды TSO можно попасть не только в ISPF, но и в Unix, введя команду OMVS для работы с оболочкой или команду ISHELL – чтобы получить панельный ISPF-интерфейс к командам Unix. При этом пользователь может работать с Unix-интерфейсами. Для терминального доступа тогда могут использоваться обычные средства telnet. Естественно, Unix работает с собственными файловыми системами: HFS и zFS [5], базирующимися на традиционном для Unix, Windows и других современных операционных систем простом потоке байтов. Файловые системы Unix расположены на обычных жестких дисках z/OS, соответствующие файлы можно, как обычно, описать средствами JCL, но для работы с Unix-файлами применяется специальный метод доступа, а для копирования этих файлов в набор данных z/OS или обратно имеются специальные утилиты. Приятно также, что в Unix можно использовать простой и удобный редактор текстов из ISPF.
Физическая и виртуальная память
Динамическое преобразование адресов (Dynamic Address Translation, DAT) реализовано аппаратно-программными средствами и использует таблицы областей, таблицы сегментов, таблицы страниц и аппаратуру буферов TLB. Страницу в физической оперативной памяти в IBM называют «рамкой» (frame), а виртуальную в файле на жестком диске – «слотом». Размер стандартной страницы – 4 Кбайт. При отсутствии страницы в памяти происходит ее пересылка из слота в свободную рамку (так называемая «подкачка»). Если свободной рамки нет, одна из страниц памяти будет вытеснена в слот (page-out), и освободившаяся рамка будет использована для копирования в нее из слота нужной страницы (page-in). Кроме того, z/OS старается превентивно поддерживать достаточное количество свободных рамок, при необходимости вытесняя давно не использовавшиеся рамки (page stealing). В памяти хранится только часть страниц AS – рабочее множество страниц.
При свопинге происходит вытеснение из памяти на жесткий диск страниц всего AS. Решение о свопинге принимает System Resource Manager по рекомендации Workload Manager.
Формат 64-разрядного виртуального адреса (VA) включает четыре поля (индекса) – области (RX), сегмента (SX), страницы (PX) и байта (BX, внутри страницы). Сегменты со стандартным размером 1 Мбайт имеют последовательные адреса, начинающиеся на границе мегабайта.
Области имеют размер 2-8 Гбайт и адрес начала, кратный 2 Гбайт. Если левая наиболее значимая часть RX есть RTX (рис. 2), то используются 42-разрядные адреса (до 4 Гбайт); если это RSX – применяются 53-разрядные адреса (до 8 Пбайт); если это RFX – то адреса 64-разрядные [2, 5]. Один и тот же VA может встречаться несколько раз – в различных AS.
В [5] указано на четыре вида защиты памяти в z/OS. Первый из них связан с изоляцией каждого пользователя в собственном AS. Второй основан на ключах защиты памяти и применялся еще в S/360 [2, 4].
Каждая рамка имеет семиразрядный ключ защиты оперативной памяти; аналогичный ключ имеет выполняющаяся программа. Изменить содержимое рамки она может, только если ее ключ совпадает с ключом рамки (или равен 0 – привилегированный режим). Можно взвести в ключе рамки бит защиты от выборки – тогда для чтения страницы также потребуется совпадение ключей.
Ключ задается в битах 8-11 слова состояния программы PSW, которое в z/OS является 128-разрядным. Ключи 0-7 использует базовая управляющая программа z/OS (BCP) и подсистемы, а также программное обеспечение промежуточного слоя; с ключом 0 работают некоторые части BCP. Ключ 8 применяется для большинства пользовательских программ, работающих в виртуальной памяти; изоляция при этом осуществляется за счет AS. Для приложений, требующих работы в реальной памяти, применяются ключи 9-15.
Организация AS
Общая организация памяти в AS представлена на рис. 3. В ней отражена история развития мэйнфреймов. Так, The Lin – граница 16 Мбайт – выделяет 24-разрядные S/370, The Bar – граница 2 Гбайт – выделяет 31-разрядные адреса архитектуры IBM/370 XA; в z/OS могут работать программы с 24-, 31- и 64-разрядной адресацией.
Каждое AS имеет размер до 16 экзабайт. Изоляция AS друг от друга осуществляется благодаря «частным областям» (private area); к «общим областям» (common area) имеют доступ все AS. Для кодов и данных пользователя доступна только часть адресов AS; часть диапазона адресов занимают системные коды и данные. В каждом AS есть собственные таблицы DAT – таблицы областей, сегментов и страниц. Некоторые программы (например, распределяющие блоки управления наборами данных) работают с реальными адресами памяти и используют память ниже «линии 16 Мбайт». Эти программы получают создаваемый редактором связей атрибут RMODE(24). Таких программ много; обычно это – унаследованные программы, работавшие в операционных системах до MVS/XA.
Нижние 8 Кбайт области AS занимает Prefixed Save Area (PSA), используемая для обработки прерываний и ошибок. Далее располагается System Region – системная область, размером четыре страницы, используемая каждым AS для RCT (Region Control Task). RCT является главной задачей в AS, она нужна для процедур свопинга самого AS. Все другие задачи в AS являются подзадачами RCT. Выше лежит пользовательская область (User Region), которая может использоваться любой программой. Далее – системная область LSQA (Local System Queue Area), SQA (Sheduler Work Area) и подпулы 228/230. Подпулы – области динамически выделяемой макрокомандами GETMAIN памяти, обладающей общими для всех ее адресов атрибутами, например, допускается подкачка, свопинг и т.д. Подпулы с номерами 228/230 имеют специфические атрибуты и предназначаются для системных функций, требующих памяти внутри AS.
Выше находится общая область Common System Area (CSA), в которой располагаются данные, доступные для всех AS. Еще выше – область для программ системного уровня, которые часто выполняются во многих AS и к которым поэтому обеспечивается доступ из всех AS. Это Pageable Link Pack Area (PLPA) и ее «модификации» FLPA (Fixed LPA) /MLPA (Modified LPA), известные еще в MVS. Над этой областью расположена область системных очередей SQA, данные которой фиксированы в памяти и имеют ключ защиты 0. Наконец, замыкает область 16 Мбайт ядро (Nucleus), также работающее с нулевым ключом; эта память доступна только на чтение. Ядро в z/OS является монолитным.
Выше 16 Мбайт, но ниже 2 Гбайт расположены «зеркальные расширения» соответствующих общих областей, лежащих «под линией», и зеркальные расширения лежащих ниже личных областей (рис. 3). Область выше 2 Гбайт используется 64-разрядными программами и называется старшей виртуальной памятью (High Virtual Storage).
Взаимодействие AS
Для каждого AS система создает блоки ASCB в SQA. У z/OS имеется много собственных системных AS. Главный планировщик, отвечающий за управление консолями оператора, имеет ASID=1. Главный планировщик запускает подсистему ввода заданий (JES2 или JES3), которая работает в своем AS (JES может быть запущена и из пакета автоматизации работы оператора). Затем стартуют другие подсистемы, работающие в своих AS, например DB2, CICS и IMS. TSO-сессии пользователя работают в собственных AS. JES запускает пакетные задания и создает для каждого из них свое адресное пространство.
Имеется два способа коммуникаций между AS – асинхронный (планирование SRB-запроса) и синхронный (применение сервисов cross-memory и регистров доступа). SRB применяется для инициации процесса в другом AS или в том же AS. Сервис cross-memory использует прямой доступ в AS другого пользователя и аналогичен разделяемой памяти в Unix. Но для реализации этого в z/OS требуется авторизация программы в списке APF, что обеспечивает более высокую безопасность, чем Unix [5].
Другие задачи управления
За управление выполнением работ в системе отвечает супервизор (часть ядра). Он осуществляет обработку прерываний, создание диспетчеризуемых единиц работы (через блоки TCB или SRB) и диспетчеризацию работ и поддерживает мультипрограммирование в z/OS.
Типы прерываний и основные механизмы их обработки в zSeries очень близки к тому, как это происходило еще в S/370 [2, 4, 5].
Диспетчеризация задаваемых SRB или TCB работ зависит от того, допускается ли вытеснение прерванной единицы работы. Если да, то система определяет, какую следующую единицу работы с максимальным приоритетом надо выполнять, и передает ей управление. Если нет – прерывание будет обработано, но затем эта работа снова получит управление. Часто SRB-работы являются «невытесняемыми», а для TCB вытеснение возможно.
z/OS связывает данные задачи с внешними устройствами и управляет распределением файлов, их удалением, созданием резервных копий/восстановлением из них и т.д. При этом используются «ручные» (то есть ли явно задаваемые пользователем) или автоматические процессы [5]. Остановимся только на «файловой системе» z/OS.
Работа с наборами данных
«Набор данных» – термин, используемый в z/OS для файлов. В отличие от других файловых систем, набор данных в z/OS – не простой набор байт, он предполагает наличие внутри записей, то есть набор данных имеет определенную внутреннюю структуру. Эта внутренняя структура называется «организацией набора данных». Он может быть последовательным, библиотечным, с прямой организацией и т.д.
Чаще всего наборы данных хранятся на магнитных лентах или жестких дисках. Для последних IBM использует термин DASD (Direct Access Storage Device; ранее в этот класс попадали также магнитные барабаны).
Набор данных может быть каталогизирован, тогда для него нет нужды указывать, где (на каком внешнем устройстве) он расположен, достаточно указать его имя. В z/OS имеется главный каталог (Master Catalog), который используется для доступа к другим каталогам или наборам данных. Для доступа к наборам данных, расположенным на DASD, используется оглавление тома (Volume Table Of Contents, VTOC). Если набор не каталогизирован, для обращения к нему необходимо указать имя набора данных, серийный номер тома – лента или диск и тип этого устройства (например, 3390). Для данного DASD имя набора должно быть уникальным.
Метка тома пишется на нулевую дорожку нулевого цилиндра жесткого диска при инициализации DASD c помощью утилиты ICKDSF. При ее вызове часто одновременно проверяется качество поверхности жесткого диска (и форматирование, при котором ICKDSF также создает на томе VTOC). Дисковое пространство для наборов данных выделяется путем использования JCL, или через вызов утилиты IDCAMS, или с применением средств управления (автоматизации распределения файлов) DFSMS.
Для записи и чтения наборов данных применяется определенный тип программных компонентов z/OS, называемый «методом доступа». Метод доступа определяется главным образом организацией наборов данных. Так, для последовательных наборов данных могут использоваться последовательные методы доступа BSAM и QSAM (соответственно базовый метод и метод доступа с очередями). Но иногда можно применять другой метод доступа, скажем, прямой метод доступа BDAM для последовательного набора данных или последовательный метод доступа – для наборов данных с прямым доступом.
Особо важны наборы данных, для которых применяется метод доступа VSAM (Virtual Sequential Access Method). Такие наборы могут содержать ключи (для поиска внутри набора данных) и последовательно расположенные данные. Это эффективно для часто используемых наборов данных со случайным (то есть в непредсказуемом порядке) обращением. VSAM используется, в частности, при доступе в страничные наборы данных.
Для библиотечных наборов данных (Partitioned Data Set, PDS) примеяется базовый метод BPAM. PDS создает еще один уровень над последовательными наборами данных, коллекцию последовательных разделов библиотеки. Имена разделов, вместе с некоторыми атрибутами, имеются в оглавлении библиотеки в алфавитном порядке. Элементы оглавления содержат также указатель на положение соответствующих разделов PDS. Большинство системных наборов данных относятся к типу PDS. Разделами в PDS могут являться исходные тексты, загрузочные модули или параметры z/OS.
Любой набор данных на диске в z/OS начинается с границы дорожки, что для жестких дисков 3390 приводит к потерям дискового пространства, если есть много маленьких наборов данных («остатки» дорожек пропадают). В PDS этого ограничения нет, разделы не должны располагаться с начала дорожек. При добавлении или изменении раздела PDS теряет часть свободного пространства внутри себя, поэтому над PDS приходится периодически проводить специальную процедуру сжатия для освобождения свободного места. Другим недостатком PDS является ограниченный размер оглавления (задается при создании PDS). Для борьбы с этими недостатками была введена организация наборов данных PDSE (PDS Extended). PDSE может автоматически расширяться до 522 236 разделов длиной до 15 728 639 записей. PDSE имеет отличный от PDS внутренний формат. В PDSE для организации быстрого поиска разделов применяются специальные индексы, а пространство при удалении раздела освобождается автоматически. PDSE могут быть разделяемыми. Разделы – исполняемые модули в PDSE – используют не формат загрузочных модулей PDS, а являются так называемыми «программными объектами» [5].
***
Завершающим краткое общее представление об организации и функционировании z/OS перечислением важных общих характеристик z/OS: изоляция AS и коммуникации их через общую область; поддержание целостности данных; работа с одновременно выполняемыми пакетными заданиями; поддержание множественности одновременно работающих коммуникационных подсистем; многоуровневая система программного восстановления при сбоях; автоматическая балансировка ресурсов z/OS; поддержка больших конфигураций ввода/вывода с тысячами жестких дисков, многими ленточными библиотеками и т.д.; наличие специального интерфейса оператора системы; возможность управления z/OS с нескольких терминалов оператора или через API для автоматизации работы оператора.
Дополнительно к операционной системе IBM предлагает самые разнообразные программные средства; их имеются сотни – даже если не считать продукты независимых производителей. Вот лишь некоторые примеры: средства обеспечения информационной безопасности (в том числе IBM RACF); компиляторы (в составе z/OS имеется Си и язык Ассемблер, а Кобол и PL/1 поставляется отдельно); реляционные (DB2) и иерархические СУБД; системы обработки транзакций (в том числе IBM CICS, IMS, WebSphere Application Server); средства сортировки; большое количество утилит (например, утилита просмотра результатов выполнения пакетных заданий IBM SDSF).
Имеется также широкий спектр программного обеспечения промежуточного слоя – Web-серверы, СУБД, средства работы с XML, менеджеры транзакций, виртуальные машины Java и др. Часто инструментарий промежуточного слоя предоставляет API например, для DB2 он выражается в виде языка SQL, а для WebSphere таким межплатформным API является WebSphere MQ [5]. n
Литература
-
Михаил Кузьминский. Мэйнфрейм на ПК // Открытые системы. – 2006. – № 1.
-
Михаил Кузьминский. Z-архитектура // Открытые системы. – 2001. – № 10.
-
Михаил Кузьминский. Эволюция подсистемы ввода-вывода мэйнфреймов IBM // Открытые системы. – 1999. – № 1.
-
Принципы работы системы IBM/370. [Пер. с англ. под ред. Л.Д. Райкова]. – М.: Мир. 1975.
-
Introduction to the new mainframe: z/OS basics. July 2006, IBM, SG24-6366-00.
-
System Programmer's guide to: Workload Manager. March 2008, IBM, SG24-6472-03.
Рис.1. Конфигурация сервера zSeries