Под знаком интеграла

Публикуемый цикл о серверных платформах был бы не полон без рассказа о системе OS/390.

Ровно год назад в статье "Затерянный мир" (апрельский номер LAN за 1997 год) мы обратились к теме мэйнфреймов и обнаружили, что мир этот на самом деле не такой уж затерянный, как кажется поначалу. Более того, время показало, что (благоприятные) прогнозы представителей IBM относительно развития рынка этих систем (и, в частности, появление новых заказчиков) как во всем мире, так и в России сбываются, а кроме того, намечаются другие позитивные для мэйнфреймов тенденции. Способствовали этому и технологические сдвиги в производстве самих машин, благодаря которым удалось удержать цены и производительность на конкурентоспособном уровне, и "смена имиджа" мэйнфреймов, которые называются так теперь больше по привычке, поскольку системы нового поколения IBM подчеркнуто именует серверами. Такое, как сейчас модно говорить, изменение парадигмы, произошло далеко не в последнюю очередь благодаря эволюции операционной системы, получившей после нескольких переименований название OS/390. Рассказу об этой платформе и будет посвящена наша статья.

AB AVO

Из всех современных операционных систем OS/390 имеет, пожалуй, самую богатую историю. С одной стороны, наличие "тяжелого наследия прошлого" принято сегодня заносить в пассив, с другой - накопленные традиции в разработке дают несомненные преимущества (в чем мы уже убедились во время работы над предыдущим материалом цикла). Одно из преимуществ состоит в том, что все важные механизмы ОС (как правило, не зависящие от того, какая концепция вычислений на данный момент является популярной) проходят серьезную проверку временем и постепенно набирают все большую мощь, впитывая все последние технологические достижения. В этой статье мы постараемся дать читателям представление об основных аспектах архитектуры OS/390.

Прежде всего обратим внимание на то, что OS/390 - система не 64-разрядная и останется таковой в обозримом будущем. На фоне сегодняшнего стремления отрасли в светлое 64-разрядное будущее подобное заявление со стороны IBM может на первый взгляд показаться парадоксальным, но только на первый взгляд. Свою позицию относительно разрядности OS/390 компания обосновывает следующими соображениями. Основная цель перехода на 64-разрядную архитектуру - получение возможности адресации к более чем 2 Гбайт оперативной памяти. Это, разумеется, не самоцель, а вызвано практической необходимостью кэширования в памяти выборок из больших баз данных. Возможность держать в оперативной памяти те данные, обращение к которым происходит чаще всего, значительно ускоряет работу серверов баз данных, а эту возможность OS/390 обеспечивает уже сегодня. Серверы S/390 позволяют установить до 16 Гбайт оперативной памяти. Практика показывает, что большее количество в одной системе заказчикам и не требуется. Каждое приложение в OS/390 получает в свое распоряжение до 2 Гбайт памяти (как под код, так и под данные), но при этом через механизм Data-in-Memory, являющийся, грубо говоря, аналогом расширенной (expanded) памяти DOS, оно имеет возможность использовать остальную память. В случае с базами данных внешне это выглядит так (или почти так), как будто кэшируемые данные копируются на промежуточный RAM-диск (кстати, подобные устройства для систем S/390 с поддержкой режима работы существуют и как отдельные модули). Всего архитектура OS/390 позволяет адресовать при использовании данного механизма до 16 Тбайт памяти, что требует всего лишь 44 разрядов, (на самом деле 42), поскольку в OS/390 эта память блочно-адресуемая, т. е. данные "выдаются" процессу блоками по четыре байта. Такой подход обеспечивает меньшую степень загрузки процессора при операциях по управлению памятью, - всего 1-3% - в случае очень больших баз данных, согласно исследованиям для СУБД DB2. Разумеется, 64-разрядные системы способны адресовать на 6 порядков больше памяти, но, опять-таки, самые крупные коммерческие СУБД сегодня занимают не более

4-5 Тбайт. Заметим также, что указанные выше ограничения на объем физической памяти касаются только одного отдельно взятого сервера. Машины, объединенные в Parallel Sysplex (с этой технологией мы познакомимся позже), могут иметь единое пространство физической памяти емкостью до 256 Гбайт. Еще один несомненный плюс такого подхода в том, что все приложения остаются 32-разрядными, и даже старые программы получают возможность воспользоваться преимуществом Data-in-Memory без доработок или перекомпиляции. И, в завершение этой темы, отметим, что преимущества перехода к 64 разрядам (IBM, кстати, развивает в данном направлении все остальные свои системы) нами ни в коем случае не оспариваются, мы только обращаем внимание на то, что отсутствие 64-х разрядности не является недостатком OS/390, просто эта система в ней пока не нуждается.

Говоря о разрядности, мы упомянули об управлении процессами и памятью. OS/390 - преемница целого семейства многозадачных ОС IBM и, как и все многозадачные системы "со стажем", обладает развитыми средствами обеспечения надежного выполнения нескольких параллельных процессов. Используемый в OS/390 подход образно можно назвать двухуровневой системой виртуальных машин. Пользователю под его задачи выделяется отдельная виртуальная машина (те, кто в свое время работал на ЕС в системе VM/SP, должны хорошо представлять себе, о чем идет речь), что исключает какое-либо несанкционированное вмешательство его процессов в работу приложений других пользователей, а также доступ к ресурсам низкого уровня. Машину, как она есть, может видеть только суперпользователь (администратор), переключение же между режимами осуществляется на аппаратном уровне. Пользовательские задачи имеют тем не менее возможность доступа к таким ресурсам (как правило, это специфические функции подсистемы ввода-вывода), но обращаются к ним не напрямую, а через специальные системные вызовы. Если полномочия, которыми пользователя наделил администратор, разрешают доступ к конкретному низкоуровневому сервису, то вызов обрабатывается, в противном случае приложение останавливается.

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

Степень "виртуализируемости", если позволительно вводить такой термин, в машинах S/390 достигает того, что один сервер можно поделить на логические разделы (Logical Partitions, LPAR), каждый из которых будет функционировать как автономная машина. Реализующий эту возможность механизм PR/SM позволяет делить физические ресурсы сервера - память, диски, процессорное время, а если процессоров несколько, то и сами процессоры - в требуемых пропорциях между логическими серверами. Данный механизм сертифицирован, так что каждый из логических серверов можно официально считать автономной машиной (между прочим, "делить" можно и сетевые адаптеры). Это обстоятельство имеет важное значение, когда соображения безопасности предполагают наличие машин, специально выделенных под определенные задачи. Очевидно, что покупка и эксплуатация двух серверов обойдется дороже, чем использование одного сервера адекватной мощности. Другое преимущество такого решения проявляется при переходе со старых систем на новые. Заказчик приобретает одну машину равной (или большей) мощности, чем несколько старых, но при этом пользователи не заметят даже, что их старой техники нет, поскольку, с их точки зрения, они будут продолжать работать со своей прежней машиной. Сам процесс переноса ПО и данных при таком подходе тоже заметно упрощается.

Не только один сервер может вести себя как пятнадцать (максимальное число LPAR), но и несколько машин могут функционировать как одна. Кластерная архитектура S/390 Parallel Sysplex позволяет достичь степени доступности ресурсов системы в пять девяток, т. е. 99,999%, что составляет 5 минут простоя в год, и даже не простоя, а отсутствия отклика системы, когда она, что называется, "тормозит". OS/390, разумеется, не только пользуется избыточностью системы, но и позволяет оптимально распределить объединенные ресурсы между различными приложениями. Часть задач можно поделить между входящими в кластер машинами (IBM, кстати, в отношении серверов S/390 термин "кластер" не употребляет, а предпочитает "сисплекс"), разнести приложение по нескольким машинам, а также совместить оба подхода (см. Рисунок 1).

(1x1)

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

В OS/390 реализованы механизмы параллельных вычислений (частично это касается не только кластера, но и многопроцессорных систем), показанные на Рисунке 2. Первый вид распараллеливания применяется в задачах типа ночных аналитических расчетов в крупных банках. Если администратор видит, что какие-то пакеты заданий могут выполняться независимо (т. е. не используют результаты работы друг друга), то он может задать схему их параллельного/последовательного выполнения, сокращая тем самым общее время расчетов (жестко ограниченное периодом от конца одного банковского дня до начала следующего). Второй вид распараллеливания применяется чаще всего при обработке сложных запросов к очень большим базам данных. Запрос разбивается на элементарные подзапросы, и входящие в кластер серверы все вместе его "перемалывают". Таким образом, время, требуемое на выполнение запроса, сокращается от часа и более до нескольких минут. Этот механизм в принципе должен поддерживаться также и на уровне самих СУБД (DB2 его поддерживает). Наконец, предусмотрено элементарное перераспределение транзакций на лету, когда диспетчер перенаправляет текущий запрос наименее загруженному из всех серверу. Этот механизм применяется при интенсивном потоке транзакций.

(1x1)

...ФИЛЬТРУЕШЬ?

Уже несколько раз мы касались темы защиты данных, теперь наконец настало время рассмотреть, как эти вопросы решаются в OS/390. На все системные объекты от данных до пользователей заводится "дело", или, в общепринятой терминологии, "профиль" (profile), который хранится в специальной базе данных RACF. "Дело" пользователя содержит его системное имя, реальное имя, группу пользователей, к которой он принадлежит, его пароль, историю смены паролей, правила смены паролей и другую информацию. Наборам данных ставится в соответствие имя, имя ресурса, определяющий права доступа объект, правила доступа. Определяющим права доступа объектом может быть как пользователь, так и процесс. Вообще говоря, любой ресурс от терминала до программы тоже регистрируется в базе с некоторым именем, классом ресурса, определяющим права доступа объектом, и правилами доступа. Под группой понимается совокупность пользователей, которым требуется доступ к одним и тем же ресурсам и которые имеют общие атрибуты. Каждый пользователь обязательно входит в какую-нибудь группу.

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

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

RACF является ядром реализованной в OS/390 концепции политики защиты данных в масштабе предприятия, интегрируется в различное окружение и поддерживает многие стандарты. Например, если на платформе OS/390 реализован сервер Web (см. статью Р. Ниебаума "Мэйнфрейм в Web" в мартовском номере LAN за этот год), то RACF без проблем взаимодействует с протоколом SSL. Сертификат SSL будет обработан, отождествлен с записями в базе данных, после чего сервер безопасности даст или не даст разрешение на передачу данных по пользовательскому запросу.

RACF интегрируется и со службой каталогов DCE (). DCE позволяет объединять ресурсы на различных платформах в так называемые ячейки и организовывать взаимодействие между ними; обеспечивает единый вход в систему и централизованный контроль за правами доступа. DCE объединяет частично черты NDS и частично - Pathworks (см. статью А. Авдуевского "8760 часов" в мартовском номере LAN за этот год). Вдаваться в подробности работы DCE мы не будем, отметим только, что сервер безопасности DCE ведет свою собственную базу данных (реестр), синхронизируемую (на логическом уровне, разумеется) с базой данных RACF. При необходимости получения зарегистрированным в реестре DCE пользователем каких-либо ресурсов OS/390 (и наоборот) вопрос о правах доступа решается в процессе диалога между серверами безопасности. Наконец, RACF в этом году будет поддерживаться платформой управления Tivoli TME 10. В системах S/390 есть еще один уровень защиты - встроенный криптопроцессор, позволяющий шифровать передаваемые и хранимые данные, но в России эта функция, увы, недоступна по известным причинам, и системы поставляются с заблокированным механизмом.

Завершая разговор о защите данных, мы кратко коснемся резервного копирования. К сожалению, этому вопросу у нас все еще уделяется недостаточно внимания (вот и мы вспомнили о нем только под конец), а, как показывает практика, именно резервное копирование оказывается "палочкой-выручалочкой" во многих форс-мажорных ситуациях. IBM предлагает ПО ADSTAR Distributed Storage Manager (ADSM) (оно не является уникальным для OS/390 и поддерживается всеми ОС IBM, а также Windows NT, HP-UX и Solaris), позволяя использовать системы S/390 в качестве центрального сервера резервного копирования. ADSM в полной мере реализует концепцию иерархического хранения данных (HSM), имеет специальную поддержку для SAP/R3, Oracle, Sybase, DB2/2, DB2/6000 и Lotus Notes и обладает развитыми средствами администрирования. Поскольку подразделение устройств хранения данных IBM предлагает для систем S/390 широкий спектр мощных устройств резервного копирования, централизованно архивировать можно данные сразу всей системы уровня предприятия (агенты ADSM могут быть установлены практически на любых коммерческих серверных и настольных платформах).

ВСЕ В ОДНОМ ФЛАКОНЕ

После того как отдел корпоративных систем IBM с гордостью объявил три года назад, что OS/390 - это "и UNIX тоже", у широкой аудитории возник резонный вопрос, точнее, два вопроса: "Как это?" и "А зачем?". На первый вопрос ответить легко - достаточно давно сервисы UNIX были реализованы в MVS посредством программной эмуляции (а какое-то время IBM предлагала даже AIX для мэйнфреймов). Работало это расширение ОС довольно медленно, и IBM его не особенно рекламировала. Три года назад удалось оптимизировать взаимодействие программного интерфейса UNIX с ядром системы, так что потери производительности удалось свести к минимуму, и, после того как оболочка прошла сертификацию UNIX-95, IBM с полным правом может заявлять, что теперь OS/390 - это две ОС в одной.

Ответ на второй вопрос сформулировать в одной фразе трудно. Прежде всего отметим, что, хотя "встроенный" UNIX по понятным причинам весьма похож на AIX, его стоит рассматривать как самостоятельную операционную систему. В частности, двоичный код, откомпилированный под AIX, в OS/390 выполняться не будет, равно как нет и средств его кросс-компиляции. Т. е. для того, чтобы воспользоваться встроенной оболочкой UNIX, приложения надо либо разрабатывать "с нуля" (инструментарий есть), либо переносить с другой платформы. Перевести сразу все программы с UNIX-машин на мэйнфрейм не получится, но эта цель и не преследовалась.

IBM удалось убить сразу двух зайцев. Во-первых, OS/390 получила интерфейс интеграции в сети TCP/IP. По большому счету, чтобы использовать OS/390 как, например, файловый сервер, не надо специально настраивать клиентские рабочие места - стандартных средств вроде ftp или NFS, поддерживаемых сегодня любой "уважающей себя" ОС, вполне достаточно для доступа к требуемым ресурсам. Благодаря полноценной поддержке TCP/IP OS/390 теперь легко вписывается в концепцию сетей Intranet и, как мы уже говорили, может быть использована в качестве платформы для корпоративного сервера Web. Во-вторых, внезапное появление целого сонма разнообразнейших коммерческих приложений для OS/390 обусловлено именно тем, что компании-разработчики получили возможность без особых сложностей переносить свои приложения на OS/390. Да и перенести собственные разработки заказчику будет не так уж сложно.

Использование UNIX-оболочки OS/390 имеет, правда, и оборотную сторону - снижение класса безопасности системы. Конечно, все системные вызовы встроенного UNIX проходят несколько уровней защиты (в том числе и RACF), но все равно класс безопасности не превышает уровня С2. Хотя, в ряде случаев, благодаря PR/SM и это ограничение можно обойти. Кстати, для брандмауэра (для OS/390 есть и такое ПО) отдельной машины, очевидно, не потребуется, поскольку его можно выделить в отдельный LPAR.

Концепция "одного флакона" имеет в OS/390 и дальнейшее развитие. Компания Bristol Technologies предлагает средства эмуляции Windows NT для OS/390. Собственно, подобный продукт продавался компанией достаточно давно, правда, для UNIX, и, как только сервисы UNIX в OS/390 стали работать эффективно, она адаптировала свой продукт для этой платформы. Понятно, что область практического применения такого решения ограничена, однако есть хороший пример использования эмуляции NT в OS/390. Американский банк в процессе своего роста обзавелся примерно тысячей серве-

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

В рамках темы "два в одном" уместно упомянуть и системы P/390 и R/390. Напомним, что эти системы представляют собой PC- и RISC-сервер соответственно с установленной в них системной платой S/390.

С системой ввода-вывода взаимодействует процессор S/390 с помощью второго процессора (под управлением OS/2 или AIX). Область применения этих недорогих (по сравнению с любой машиной S/390) систем - замена старых машин (P/390 легко заменяет ЕС, и даже не одну) и использование в качестве выделенных машин для разработки. Несмотря на то что эти машины могут показаться "карманными мэйнфреймами" (каковыми они, впрочем, и являются), на них работает полноценная версия OS/390 без каких-либо ограничений, кроме тех, которые налагают ресурсы машины. Взаимодействие обеих операционных систем (на уровне обращения к приложениям и ресурсам) осуществляется программно, например через IP. Задействовать OS/2 (в случае P/390), кроме как в качестве интерфейса для OS/390, обычно не рекомендуется, однако использовать AIX-ресурсы R/390 вполне возможно. Кстати, прогнозы относительно роста спроса на P/390 в России также сбылись - уже продано порядка 30 систем, и интерес к ним не ослабевает.

ЗАКЛЮЧЕНИЕ

Мы не задавались целью рассказать об OS/390 абсолютно все, или даже половину всего, иначе нам пришлось бы выпускать этот номер журнала под названием "OS/390 Magazine", а замена своей торговой марки (хотя бы и на столь известную) не входит в наши планы. Однако хочется верить, что нам удалось дать общее представление о платформе OS/390 и ее месте в мире клиент-серверных технологий. Нам кажется, что в безграничном море практических задач и потребностей корпоративных пользователей эта платформа занимает свою, особую нишу, к тому же при всем богатстве своих традиций большие системы регулярно предстают перед нами в новом качестве, и отечественный рынок (на которым представлены и клоны S/390) стабильно развивается. А это значит, что мы еще не раз вернемся к данной тематике, к тому же отклики читателей показывают, что она вызывает заметный интерес у нашей аудитории.