Это статья в формате вольного пересказа более чем сорокалетнего периода работы с разными ОС, главным образом с ОС мейнфрейм, и размышлениями об их сходстве и различиях (в большей степени о различиях, конечно).

Многие популярные ОС выполняются на серверах (речь в статье пойдет исключительно про серверные ОС) х86 (Intel, AMD). Это Линукс разных мастей и названий, и Windows. В силу уклона российского образования в сторону инфраструктур на основе х86 у многих айтишников есть твердое убеждение, что то, как написаны известные ОС, это единственный вариант, как ОС и могут быть написаны. Попытки писать свою, российскую, ОС сводятся к написанию очередного Линукса.

Но есть и другие, современные ОС, выполняющиеся не на х86 платформе. Это одна из ОС IBM мейнфрейм (МФ), называемая z/OS. IBM МФ — тоже весьма современная техническая платформа. В апреле этого года IBM анонсировали новое поколение z17, т. е. семнадцатое поколение, начавшее свою историю в далеком 1964 году.

Есть и другие ОС на МФ кроме z/OS. Например z/VM — виртуальные машины — ведет свою историю из далекого 1967 года. Да‑да, виртуальные машины появились не в начале 2000-х. У z/VM была нелегкая судьба. Был момент в 70-е, когда решался вопрос: а не убить ли ее, чтобы не распылять силы разработчиков IBM, сконцентрированные на создании флагманской ОС IBM — MVS, (о которой, собственно, и будет главным образом говориться в этой статье). К разработчикам MVS был послан чиновник. Он спрашивает одного:

— Ты что делаешь?

— Отлаживаю то‑то и то‑то в MVS.

— А что ты используешь для этого?

— Виртуальную машину VM/370.

И так оказалось, что разработчики MVS отлаживали свои коды на виртуальных машинах VM/370. И чиновник сказал, что если VM хороша для разработчиков MVS, то она хороша и для IBM. Таким образом, VM не была убита и развивается до сих пор, используясь главным образом для Линукс виртуальных машин на МФ (LinuxONE). На этом с VM мы прощаемся в рамках этой статьи, добавив лишь то, что VM на МФ изначально предоставлял полную — нет, неправильно — ПОЛНУЮ виртуализацию реальной машины, в данном случае МФ.

Как я уже намекнул, говорить я буду про MVS. Причем здесь z/OS заявлена в начале статьи. Дело в том, что z/OS на самом деле состоит из двух ОС: MVS и Unix System Services (USS). Да‑да, два в одном. Причем обе системы полностью интегрированы друг с другом таким образом, что в любой программе можно обращаться и использовать фукциональность обеих систем одновременно.

Но все началось даже не с MVS, а как было принято тогда, с DOS, потом появилась OS/360 с несколькими режимами работы на выбор: OS/360 MFT (мультипрограммирование с фиксированным количеством задач), OS/360 MVT (мультипрограммирование с переменным числом задач), OS/360 VS1 (MFT в виртуальной памяти до 16 МБ) и OS/360 VS2 (MVT в виртуальной памяти до 16 МБ). Машины тогда еще даже близко не имели физической памяти в 16 МБ. Вся эта история уложилась в шесть лет, с 1966 до 1972 года. К этому времени IBM накопили богатый опыт в области их МФ и в операционных системах как таковых. Началась разработка MVS, первый релиз которой состоялся в 1974 году.

MVS расшифровывается как Multiple Virtual Storage. Множество виртуальных адресных пространств. Исторически то, что нынче называется Memory (внутренняя память компьютера), в терминологии IBM называется Storage. А то что нынче называется Storage (Disks), называлось и называется DASD (читается как дасди) — Direct Access Storage Device.

Я бы раскрыл MVS как Multiple Virtual Systems. В самом деле, каждое адресное пространство в MVS (кроме адресных пространств данных, есть такие и еще другие) содержит свою копию ОС, т. е. самого MVS. И таким образом программы как бы выполняются на виртуальной машине с собственной ОС, но это всегда MVS. Причем это ОС, сконфигурированная для конкретной программы. Ничего это никому не напоминает? Контейнеры, докеры, кубернетесы. А?

Главное отличие

Перед разработкой MVS были поставлены грандиозные требования, с которых мы и начнем разбираться, чем же различаются современные ОС и, если хотите легаси, система МФ — MVS. Вот что пишется об этом в англоговорящей Википедии — перевожу (очень глубокий по смыслу текст — не поленитесь дочитать его, даже если не все будет понятно с первого раза):

MVS сделала большой шаг вперед в отказоустойчивости, построенной на более ранней возможности STAE, которую IBM назвала восстановлением программного обеспечения. IBM решила сделать это после многих лет практического реального опыта с MVT в деловом мире. Системные сбои теперь оказывали серьезное влияние на бизнес-клиентов, и IBM решила сделать большой скачок в проектировании, предположив, что, несмотря на лучшие методы разработки и тестирования программного обеспечения, «проблемы БУДУТ возникать». Это глубокое предположение сыграло решающую роль в добавлении большого процента кода отказоустойчивости в систему и, вероятно, способствовало успеху системы в устойчивости к программным и аппаратным сбоям. Трудно получить статистическую информацию, чтобы доказать ценность этих конструктивных особенностей (как можно измерить «предотвращенные» или «исправленные» проблемы?), но IBM во многих измерениях улучшила эти функции восстановления отказоустойчивого программного обеспечения и быстрого решения проблем с течением времени. Эта конструкция определила иерархию программ обработки ошибок в системном (ядро/'привилегированный') режиме, называемых Функциональными Процедурами Восстановления, и в пользовательском ('задача' или 'проблемная программа') режиме, называемых «ESTAE» (Extended Specified Task Abnormal Exit routines / Расширенные процедуры аварийного выхода из заданной задачи), которые вызываются в случае, если система обнаруживает ошибку (ошибка аппаратного процессора или хранилища, или программная ошибка). Каждая процедура восстановления делала проблемную функцию повторно вызываемой, собирала диагностические данные об ошибках, достаточные для отладки вызывающей проблемы функции, и либо повторно вызывала эту фукцию, либо обработка ошибок эскалировалась на следующий уровень процедур восстановления в иерархии.

Таким образом, при каждой ошибке система собирала диагностические данные и пыталась выполнить исправление и поддерживать систему в рабочем состоянии. Худшим из возможных решений было отключение пользовательского адресного пространства в случае неисправленных ошибок. Хотя это была начальная точка проектирования, только в последней версии MVS (z/OS) программа восстановления не только гарантировала собственную процедуру восстановления, но и каждая процедура восстановления теперь имеет собственную процедуру восстановления. Эта процедура восстановления была встроена в базовую программу управления MVS, а средства программирования доступны и используются разработчиками прикладных программ и сторонними разработчиками.

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

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

В дополнении к вышеприведенному от себя добавлю, что если система не в состоянии продолжать успешное функционирование, то она переводит саму себя в режим ожидания с запрещенными прерываниями (т. н. wait status). При этом аппаратным путем предоставляется код ожидания — wait state code (большенство из них на самом деле вовсе ничего не ожидают, а по факту сообщают о причине остановки/аварии). Кодов не просто много, а очень много. Многие из этих кодов имеют уточняющие подкоды. К слову, за 25+ лет работы мне не довелось увидеть ни одного wait state code, кроме двух‑трех во время начальной загрузки системы, и они были связаны с неправильным указанием загрузочных параметров или с проблемой на загрузочном диске.

Кроме аварийных кодов ожидания есть системные коды завершения (System Completion Codes), с которыми могут завершаться прикладные программы и компоненты системы. В отличие от кодов ожидания, коды завершения не сопровождаются остановкой работы самой системы. Эти коды (их много) тоже предоставляют диагностику причины, почему система аварийно завершает прикладную программу или свою системную компоненту.

Вышеописанное различие я считаю ключевым в сравнении систем. Из своего опыта работы с Видовсами, Линуксами, OS/2 в том числе, я могу утверждать, что ничего подобного ни в одной другой системе, включая мейнфреймовские, я не видел.

Второстепенные отличия

Но перейдем к более простым и менее эффектным (может, где‑то и спорным) различиям. Замечание 1: далее многие из вас прочитают про вещи со вроде бы знакомыми названиями, но в совершенно неизвестных вам интерпретациях. Это потому, что я буду описывать классические мейнфреймовские решения. Но надо иметь в виду, что и все более привычные для открытых систем вещи на МФ тоже возможны. Например, МФ может работать с SCSI-устройствами. О них я, если все хорошо пойдет, напишу позже, в других статьях.

Начнем с...

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

Все привыкли, что файлы образуют иерархию папок (folder) и вложений в них (files), описанные в стандарте POSIX. Так оно и есть в той части z/OS, что называется Unix System Services (USS). Совсем иначе обстоят дела в MVS. Аналогом файлов являются наборы данных (data sets). Довольно отдаленным аналогом, потому что, в отличие от файлов, наборы данных имеют различную организацию. Самая простая — это последовательная организация данных в наборе данных. Аналог обычного файла.

Есть организация, называемая библиотечной. В этой организации есть оглавление и разделы, каждый из которых представляет собой последовательный набор. Обращение к разделам осуществляется в формате <имя‑библиотеки>(имя‑раздела).

Далее есть так называемая Generation Group (группа поколений данных), которая под одним названием представляет группу поколений одного и того же набора данных. Доступ к текущему (последнему) поколению осуществляется в формате <имя‑группы>(0), к предыдущему поколению <имя‑группы>(-1) и т. д., новое поколение <имя‑группы>(+1).

Есть организации наборов данных, ушедшие в прошлое, но все они (как и все остальное начиная с OS/360) до сих пор поддерживаются в текущих версиях z/OS. т. н. индексно‑последовательные и прямая организация наборов данных.

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

Ну и последней организацией, о которой необходимо сказать, будет иерархическая организация для файловых систем Unix System Services. В двух форматах: HFS, and ZFS.

Системные и пользовательские каталоги

Каталоги в MVS содержат информацию о размещении наборов данных MVS и алиасы для путей (PATH) в иерархиях USS. Исторически и до настоящего времени диски и ленты в MVS существуют в форме т. н. томов (dasd volume). Изначально это были физически отдельные устроства (Device), объединенные в группы через т. н. управляющие устройства (Control Unit CU), которые в свою очередь подключались к каналам ввода‑вывода собственно МФ. К одному CU подключаются многие устройства, например диски. Многие — значит до 256. Все устройства, используемые МФ, по сути, всегда были и есть внешние устройства.

Вернемся к томам (volume). Каждый том имеет уникальную метку (volser — volume serial number), состоящий из числа до шести символов. Каждый том имеет таблицу содержимого тома (VTOC — Volume Table Of Content). В этой таблице находятся данные о наборах данных и их размещении на томе. Наборы данных именуются уникальными для тома составными именами длиной до 44 символов, составленными из до восьмисимвольных квалификаторов. Например SP.SMFDUMP.MVS0EA.D250 704, или проще DSN1, DSN2, и т. д.

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

Каталог — это набор данных, используемый как базы данных о наборах данных и их местонахождении на томах системы. Имена наборов данных, хранимых в каталогах, уникальны и являются индексом для поиска остальных данных (метка тома в простейшем случае) для точной связи с набором данных, где бы он ни находился в системе и дополнительной информации о VSAM наборах данных.

В каждой инсталяции MVS есть один главный каталог (Master Catalog) и сколько угодно пользовательских каталогов (User Catalog). Главный каталог содержит информацию о системных наборах данных и алиасах, связанных с пользовательскими каталогами. Например, мы может создать алиас USER1 в главном каталоге и привязать к нему пользовательский каталог в наборе данных каталога с именем SYS1.USER1.CATALOG. Это будет означать, что данные о наборах данных с именами USER1.* будут сохраняться в и браться из SYS1.USER1.CATALOG. В главном каталоге будет только записан алиас USER1 и имя пользовательского каталога.

В ранние времена существования МФ и ранних версиях ОС было принято размещать наборы данных практически вручную с указанием метки тома и, соответственно, адресовать их двумя именами. Замечу, что на разных томах могли (и могут) существовать наборы данных с одинаковыми именами. Но в каталогах могли быть закаталогизированы только уникальные имена наборов данных.

Data Facility Storage Management Subsystem (DFSMS)

Уже в конце 70-х начале 80-х IBM разрабатывали вспомогательные компонеты MVS, автоматизирующие начальное размещение наборов данных и их миграцию на внешних носителях без каталогов того уровня автоматизации этих процессов, какой в современной Data Facility Storage Management Subsystem (DFSMS) достичь было бы невозможно. Вот поэтому в z/OS присутствуют каталоги. В общем случае пользователи z/OS, включая администраторов и ДБА, придумывают только имена наборов данных, а в большинстве случаев часть имен, следующую за т. н. квалификатором высшего уровня (HLQ). Все остальное происходит автоматически на основании политики используемых DFSMS и созданных администратором DFSMS. Эти политики включают такие понятия, как Storage Class, Management Class, Data Class, Storage Group, Extended Attributes, etc...

DFSMS была анонсирована в 1988 году. До этого, с 1981, эта тема развивалась под названием Data Facility Product (DFP), который объединил несколько продуктов, разрабатываемых с конца 70-х — начала 80-х. DFSMS остается неотъемлемой частью z/OS, автоматизируя и поддерживая все задачи, требуемые для работы с хранилищем на высочайшем уровне.

В открытых системах есть масса вариантов работы с хранилищем и масса файловых систем. Хорошо это или не очень — трудно сказать. Но что‑то говорит мне, что это обилие не гарантирует комплексности и качества этих решений. Я работал в разных Линуксах (SuSe, Red Hat). Программы для работы с хранилищем в них явно не предусматривают случай для очень больших объемов и главное — большого количества приложений в рамках одной системы. И в самом деле: зачем им это, если основным подходом является дробление на много простых установок, имеющих дело с небольшими кусочками чего-то большого. Нет, конечно, можно прицепить огромное хранилище к одному Линуксу и свалить туда все файлы в кучу по разным папкам. Можно и два, и три и т. д. хранилища подключить. Но уже ближе к десятку это превратится в большой головняк.

Однако продолжим.

Workload Manager (WLM)

WLM-функция известна практически в каждой ОС. Когда лет 20 назад я начал заниматься этой темой в zOS, то поинтересовался, как с этим обстоят дела в Юниксах, Линуксах, Виндовсах. Да, есть такие названия в этих системах. Но это совсем не то, что в zOS.

Как правило, WLM в «открытых» системах (Виндовс к ним не относится) обеспечивают аллокацию заданного/желаемого количества CPU тем или иным программам в системе. Это слишком примитивно. Ниже вы узнаете, чем оперирует WLM в zOS.

Основы управления нагрузками

Чтобы сервер мог выполнять свою роль и отвечать ожиданиям пользователей, он должен уметь распределять ресурсы: CPU(s), memory, input‑output — определенным образом, отвечающим ожиданиям тех, в чьих интересах выполняются сервисы на серверах. Обычно это закрепляется в официальных соглашениях. Например, время выполнения транзакции не должно превышать одной секунды.

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

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

Достигается это на разных платформах по-разному. В этом смысле просматривается две группы подходов: применяемые на мейнфрейм (главным образом в zOS) и на платформах х86, RISC, Power в ОС Windows, Unix, Linux.

В последних как правило используется подход «один сервер‑один сервис» т. е. на физический или виртуальный сервер ставится либо СУБД, либо сервер приложений (Web), либо сервер печати, либо proxy, DNS, AD и так далее по списку. Более того, в тяжелых случаях и для надежности один и тот же сервис располагают на нескольких независимых серверах. В результате сервис обладает всеми ресурсами сервера и обеспечивает показатели, ограниченные только возможностями сервера(‑ов).

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

Чем-то в этом плане помогает виртуализация, но с ней связаны другие проблемы. Как‑то с этим борются в облаках. Но сервер на х86 остается сервером х86, Windows — Windows‑ом, а Unix — Unix‑ом.

Посмотрим, как с этим обстоят дела на мейнфрейме, и в частности в zOS.

Принципы работы WLM for zOS

WLM for zOS является подсистемой, осуществляющей автоматические настройки приоритетов выполняемых процессов с целью обеспечения ожиданий пользователей в интересующих их терминах, критериях и количественных показателях. Ожидания пользователя выражаются через политики, являющиеся источником целеполагания для действий WLM. Исполнительным механизмом для WLM являются приоритеты, используемые диспетчером для обслуживания очередей готовых к выполнению процессов.

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

Результаты измерений разных показателей нормализуются отношением достигнутого значения параметра к заданому. Называется это отношение «индекс производительности» (ПИ). Значение ПИ = 1 означает, что цель управления в точности достигнута. ПИ < 1 означает, что цель достигнута с превышением, а ПИ > 1 означает недостаточность фактического достижения цели. Перелет или недолет в терминах артиллерии.

Для достижения целей в следущем цикле управления WLM ищет «доноров» — процессы с ПИ < 1 и понижет их приоритетность, повышая при этом приоритеты «акцепторов» — процессов с ПИ > 1. Таким образом происходит перераспределение ресурсов сервера для достижения лучшего процесса выполнения формализованных интересов пользователя.

Наличие WLM в zOS позволяет выполнять множества самых разнообразных нагрузок (БД, сервера приложений, пакетная обработка, и т. д.) без негативного влияния одних на другие при этом добиваясь более полноценного использования всех ресурсов вычислительной установки.

Основные понятия WLM for zOS

Пройдемся по основным понятиям и объектам WLM for zOS.

Политики (Policy). Хранилище всех объектов, задаваемых пользователем и используемых WLM в своей работе. Можно это называть конфигурация. В одной и той же системе может существовать несколько разных политик. В каждый момент активна одна из них, и их можно менять на ходу без перезагрузки системы. Например, по времени суток или дням недели.

Класс сервиса (Service class). Основной элемент политики, в котором пользователь прописывает свои «хотелки». Единица связанных целеполаганий и критериев пользователя, достижение которых будет требоваться от WLM. Для описания этих целеполаганий и критериев используются следующие понятия:

• Важность цели (Goal Importance). Важность процесса, которому назначен класс сервиса. Задается один из шести уровней числами от 1 до 5. Высший уровень — уровень 1. Он используется для системных процессов, но может присваиваться и прикладным тоже.

• Тип цели (Goal). Один из вариантов цели: «среднее время выполнения (Average response time)», «время выполнения с процентом (Response time with percentile)», «темп выполнения(Execution velocity)», «по усмотрению(Discretionary)». «По усмотрению» означает, что ресурсы предоставляются только при условии, что все другие типы цели будут удовлетворены (ПИ = 1 или ПИ < 1).

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

• Квалификатор процесса (Qualifier Sets). Своего рода тип признака/атрибута и его значение, на основании которых WLM будет назначать класс сервиса процессу. Важный параметр, который определяет гранулярности различений процессов в системе. Признаки/атрибуты/квалификаторы процессов разные для разных типов процессов в zOS. Это, например, пакетные задания, процессы DB2, веб-процессы, Unix-процессы. Всего их 12 в zOS v1r13 (текущий уровень v3r2). В каждой группе признаков свой набор. Например, для DB2 этот набор состоит из 15 признаков; самый простой для понимания — имя пользователя (User ID). Также имеются признаки, связанные с учетом (accounting), типами присоединения к DB2, сетевые параметры присоединений и т. п. В итоге имеются десятки, если не сотня разных признаков для разного вида процессов, используемых WLM‑ом для связи процессов с классами сервиса.

Из однотипных квалификаторов можно строить группы квалификаторов (Classification Groups), например группа идентификаторов пользователей или имен транзакций и т. п.

• Правила связи по классификаторам (Classification Rules). Это раздел политики, где описываются связи между квалификаторами и их значениями и/или группы квалификаторов с классами сервисов (goals).

Работает WLM постоянно. Остановить его нельзя. Охватывает он все процессы без изъятия. zOS из коробки поставляется с вариантом политик по умолчанию, но, как правило, ее надо доводить до нужд конкретной установки.

В Unix-подобных (HP UX, AIX) системах тоже имеются подсистемы, называемые Work Load Manager. Их инструментарий и глубина проникновения несравненно уже по сравнению с WLM for zOS. Даже в AIX продукте от того же IBM WLM попроще и поограниченнее будет. Это определяется отличиями в архитектуре платформ собственно железа и ОС.

В Unix-вариантах существенно ограничен набор квалификаторов процессов и целей. Характер целей тоже совсем иной. Это в случае Unix будет в основном количество CPU, памяти, предоставляемыми тем или иным процессам.

Из разговоров с администраторами Unix я извлек то, что популярностью WLM у них не пользуется, многие даже не знают о существовании WLM в их системах.

На zOS, как было сказано выше, WLM — неотъемлемая часть системы. И что особенно важно — это то, что работа WLM сопровождается сбором огромного объема информации о процессах и о том, как WLM удается достигать целей, заданных пользователем в политике. Это прекрасный, эффективный источник понимания того, что ж такое выполняется в конкретной системе и как следует изменять политики, чтобы лучше достигать целей при меньших затратах на сам процесс управления.

Распределенная обработка против централизованной

Операционные системы стали эффективным средством использования вычислительных мощностей (компьютеров) тогда, когда они стали многопользовательскими и многозадачными и многопроцессорными. Все современные ОС заявлены как много‑, много‑.

Но что мы имеем на практике. Мы имеем в более-менее крупных инфраструктурах под каждую нагрузку кластеры серверов, т. е. мало того, что один сервис (БД, Application, etc..) устанавливается на отдельный сервер и ни с чем не разделяет этот сервер, так и этот сервер разносится на несколько серверов в кластере. В наши дни считается нормой строить ИТ-инфраструктуры обязательно на кластерах.

К чему приводит такой подход? К недоиспользованию ресурсов. Даже когда мы ставим БД на один сервер, бизнес-приложение на другой, Active Directory и DNS на третий и четвертый, мы увидим разные уровни использования всех четырех, и нет никакой возможности поместить все четыре сервиса (а их обычно гораздо больше) на один сервер. Нет возможности, потому что нет механизма интеллектуально разделять ресурсы одного сервера между четырьмя сервисами так, чтобы никто никогда не придавливал бы. Нет таких средств в ОС для х86.

IBM МФ изначально и по наши дни исповедовал подход максимальной загрузки отдельной инсталляции ОС путем взятия на себя смеси различных нагрузок, пакетной обработки и диалоговых программ, баз данных и серверов приложений, сетевых сервисов (FTP/NFS server, etc..), секьюрити и так далее. Работая со смесями нагрузок, разработчики IBM МФ пришли к тому, что выше описано как WLM. Гибкий инструмент настройки работы ОС с множественными нагрузками, так что ни одна не монополизирует использования ресурса и в тоже время все нагрузки достигают своих целей с заданным количеством и качеством.

Ошибочно будет считать, что IBM МФ — это некий неделимый монстр, в котором выполняется одна ОС и все «программы» крутятся в ней. Как было сказано выше, уже в конце 60-х — начале 70-х на МФ появились виртуальные машины, а в 1988 виртуализация была встроена в firmware МФ, так что виртуальные машины стали доступны на уровне железа. Называется это PR/SM (читается как призм) (Processor Resource/System Manager). PR/SM позволяет создавать логические партиции в терминах ресурсов всего МФ. Все ресурсы могут использоваться совместно всеми партициями кроме памяти (memory), которая нарезается из физической памяти кусками произвольного размера сумарно не больше чем размер физической памяти. Таким образом, память в партициях не виртуализирована. Но в системах, выполняемых в партициях, конечно, память виртуализируется. Процессоры МФ могут использоваться совместно, т. е. разделяться системами в партициях, но могут и быть закреплены за ними и использоваться монопольно. В случае разделения каждая партиция получает свой вес, и PR/SM разделяет время доступа к процессорам на основе веса партиций.

Кроме разделения физических ресурсов МФ между системами IBM МФ предоставляет возможность объединять несколько МФ в группу (кластер, если хотите), так что несколько ОС (и это могут быть только zOS) будут работать как единое целое. Называется эта технология Sysplex (от Systems Complex) и/или Parallel Sysplex. До 32 образов zOS, выполняемых на разных физических МФ или в партициях одного МФ, или и то и другое вместе. В отличие от кластеров на х86, в Sysplex используются специализированные устройства и протоколы, позволяющие наращивать мощности линейно.

Многие приложения zOS могут использовать Sysplex, например БД DB2 имеет Data Sharing режим, когда несколько экземпляров DB2 в разных нодах разделяют одну и ту же БД. WLM, описанный выше, расширяет поле своей деятельности на все системы в Sysplex, используя одну и ту же политику и кроме управления ресурсами одной системы может перераспределять ресурсы между партициями с целью лучшего достижения целей сервис-классов в разных партициях.

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

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

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