Чем различаются ОС IBM мейнфрейм и ОС х86 / forpes.ru

Главная
Чем различаются ОС IBM мейнфрейм и ОС х86

Чем различаются ОС IBM мейнфрейм и ОС х86 +34

09.07.2025 15:27

zVlad909 109 7200 Источник

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

Многие популярные ОС выполняются на серверах (речь в статье пойдет исключительно про серверные ОС) х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 получаются такими, какими они получаются. Менять сложившееся по факту практически невозможно. Да и информации для целенаправленного изменения чего‑либо, как правило, нет. Можно только добавлять или убавлять сервера. Добавлять просто, а вот убавлять весьма проблематично.

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

Комментарии (109)

Tzimie
09.07.2025 15:41
#28550268
Ну WLM очень хорошо управляется ресурсами, но в х86 мире за те же деньги можно купить в 10-100 раз больше железа по мощности и просто не заморачиваться
1. SIISII
  09.07.2025 15:41
  #28550386
  Есть нюансы. Во-первых, выполнение некоего тяжёлого приложения на единой машине с 100500 процессоров и гигантским объёмом ОЗУ, в общем и целом, эффективнее, чем работа на 100500 хилых машинах со связью по локальной сети. Во-вторых, вопросы надёжности и восстановления после сбоев: с IBM тут тягаться тяжело, всё ж они на этой теме были зациклены ещё с 1960-х годов. Ну а в-третьих, в эксплуатации один мэйнфрейм может оказаться дешевле, чем куча обычных серверов.
  
  Но, понятно, все эти вопросы дискуссионные, и в разных ситуациях можно получить разные результаты.
  1. Alex-Freeman
    09.07.2025 15:41
    #28551012
    Ну такое, как выше сказали на эти же деньги можно купить во много раз больше железа, сделать FT для критических процессов и соединить чем ни будь типа 400G InfiniBand
  1. zVlad909 Автор
    09.07.2025 15:41
    #28551302
    Спасибо за комментарий. Но достоверности для надо сказать что не с 60-х годов ИБМ "зациклился" на надежности, а с началом и в процессе разработки MVS. Это 70-е годы. Желаемый уровень был достигнуть существенно позже. Это очень трудоемкая работа и много кода.
    
    SIISII
    09.07.2025 15:41
    #28551320
    Тут Вы ошибаетесь. И средства обработки аппаратных ошибок были с самого начала заложены в аппаратуру, и программная обработка и, по мере возможности, восстановление были предусмотрены ещё в MFT/MVT -- естественно, на тех моделях, которые позволяли это сделать. В частности, сбой (не полный отказ, а именно сбой) процессора или блока памяти при наличии MCH (он мог присутствовать для некоторых моделей Системы 360 и был обязателен для любых моделей Системы 370) во время выполнения прикладной задачи приводил к аварийному завершению этой задачи, а не системы в целом; всё остальное продолжало работать -- ну а сбойнувшая задача при определённых условиях могла быть перезапущена с контрольной точки. Макрокоманда STAE тоже была предусмотрена с самого начала. В MVS очень сильно расширяли расширили и дополнили уже имевшиеся механизмы и, в конце концов, довели их до ума, но сказать, что только в ней начали, будет некорректно.
    
    zVlad909 Автор
    09.07.2025 15:41
    #28551346
    Все верно Вы говорите. Полностью с Вами согласен. Сам начинал с OS/360 и именно как системный программист генерирующий системы. Все что Вы перечислили было и в OS/360 (ОС ЕС), но то что я дал в цитате из Википедии про требования к MVS начали внедрятся именно в MVS и это взяло немало лет.
    
    MVS в СССР очень не сильно был распространен. ВЦ ЖД с ним работало И больше я не знаю кто. Да, еще в НИЭВМ был студент которому дали разобраться с MVS и он достиг больших успехов в чтении дампов. Ну и конечно НИЦЭВТ.
    
    AndyCravec
    09.07.2025 15:41
    #28552850
    В МХТИ в 1989-1990 на ЕС 1066 стояла, я с ней работал как пользователь
1. zVlad909 Автор
  09.07.2025 15:41
  #28551224
  Спасибо за комментарий.
  
  Стандартный, ожидаемый ответ. Много раз слышал такой на мои выступления на эту тему в других местах. Могу согласиться что "..за те же деньги купить в 10-100 раз больше железа по мощности" (хотя вряд ли даже в 10, и точно не в 100), но посмею утверждать что загрузить эти мощности на 100% не получится. А в случае с МФ, zOS и WLM нормальным является потоянная загрузка на 100%.
  
  Кроме того имейте в виду что сравнение по мощности МФ с х86 далеко не тривиальное дело и это не сранение количеств CPU, тактовых частот и размера оперативной памяти (RAM).
  
  C интересом ознакомлюсь с Вашими источниками по этому вопросу.
  1. buldo
    09.07.2025 15:41
    #28555536
    Вот отсюда поподробнее. Чисто пальцем в небо для неспециалиста.
    Как можно сравнить мощности МФ и обычного сервера? Условно говоря, нам удалось подобрать конфигурации, когда у обычного x86 и МФ одинаковое число ядер(потоков, учитывая hyper-t) и оперативной памяти. Давайте рассмотрим производительность в таком случае.
    
    zVlad909 Автор
    09.07.2025 15:41
    #28555678
    Это очень нетривиальный вопрос. В недалеком прошлом (лет 10-15 назад) на эту тему было много материалов опубликовано, в основном не ИБМ-ского происхождения. Были плохие оценки, не в пользу МФ. Я анализировал эти тесты и показывал что в них было лукаво и как следствие необъективно.
    
    Были и ИБМ-вские исследования тоже примерно в тоже время (последнее время или я перестал этим интересоваться или в самом деле это заглохло). Так вот на семинарах, которые я регулярно посещал тогда в Торонто, говорилось что один CPU МФ эквивалетнен 26 х86. Каких именно х86 не говорилось. Но тем не менее это было официальное утверждение официаольных представителей от ИБМ. А они точно не будет допускать репутационные потери на вранье.
    
    Вот мой пример. Версия ERP приложения для МФ (DB2, CICS, Cobol) выполнялась у нас на одном небольшом МФ с 4 CPU (32 GB), на ограниченной скорости (speed) СPU. Причем не только Продакшн, но и все остальные DEV, QA, Training, Sandbox на этом же МФ. Версия этого же приложения с теми же пользователями и данными реализованная в Azure на Оракл и WildFly (Java) использует 36 серверов с количеством CPU на каждом от 4 до 16 и RAM не меньше 64 GB в каждом.
    
    Если "подобрать конфигурации, когда у обычного x86 и МФ одинаковое число ядер(потоков, учитывая hyper-t) и оперативной памяти. ", то это во-первых конечно будет очень разная цена, и во-вторых, таких конфигураций на обычных х86 можно будет разместить на МФ десятки.
1. Hemml
  09.07.2025 15:41
  #28555532
  Железо железу рознь. Насколько я слышал от людей, которые реально занимаются мэнфреймами, основная фишка там -- производительность I/O. Архитектура PC никогда не затачивалась на такое количество запросов в секунду, какое легко выдерживает мэнфрейм, отчего проваливаются многие попытки мигрировать с мэнфреймов на более дешевые решения.
  1. zVlad909 Автор
    09.07.2025 15:41
    #28555648
    Производительность I/O это действительно фишка. Все дело в том что ввод-вывод на Мф реально автономен и не использует ресурс CPU от слова совсем. Каналы ввода-вывода это по сути компьтеры в компьтере. И когда например говорится zOS выполняется на 4 CPU, то надо иметь в виду что на самом деле процессоров в нем больше и они добавляют производительность.
    
    Но есть и другие фишки. Например аппаратная реализация сжатия данных и кодирование, теперь еще и поддержка AI начиная с z16. На х86 тоже есть такие платы, но они опциональны и это деньги. В МФ это стандартно включено. И это еще не все.
    
    Но самая главная фишка это симбиоз МФ с ОС zOS.
  1. SIISII
    09.07.2025 15:41
    #28556080
    И производительность, и прямизна архитектуры в целом и архитектуры ввода-вывода в частности -- именно благодаря этому мэйнфреймы прекрасно виртуализируются, ну а по-настоящему качественных виртуализаций ПК не существует и вряд ли будет существовать (имеющиеся гипервизоры виртуализируют некоторое подмножество, достаточное для исполнения Винды/Линуха, но далеко не всегда способные работать с чем-то нестандартным; мэйнфреймы изначально виртуализировались абсолютно полностью, поэтому на виртуальной машине можно было творить ту же дичь с вводом-выводом, что и на реальном железе -- и всё работало).
    
    zVlad909 Автор
    09.07.2025 15:41
    #28558448
    На МФ, в виртуальной машине под, уже c VM/370, можно было загрузить ..... VM/370, более того в виртуальной машине под VM/370 на виртуальной машине можно снова загрузить VM/370.
    
    Идет это и с того как устроен ввод-вывод (каналы) и как разеделены режимы супервизора и прикладных программ. Четко разделены. Их всего два в отличии от х86 где их помнится пять. В первых версиях VMWare на тогдашних х86 просматривал выполняемый код на ВМ чтобы вылавить некоторые команды. В последующих х86 эта проблема решалась, но как мне помнится не до конца всеже. Что сейчас с этим я не в курсе. Может кто в курсе расскажет? Или укажет на источник.
1. ShaltaiBoltai
  09.07.2025 15:41
  #28557988
  Разумеется. Поэтому суперкомпьютеры строят на железе от Intel и AMD, а не от IBM. zEnterprise покупают те компании, у которых инфраструктура исторически сложилась из мейнфреймов с дремучих годов. Интересно, как часто компании выбирают построить свою инфраструктуру на продукции IBM с нуля? Подозреваю, весьма не часто.
  1. SIISII
    09.07.2025 15:41
    #28558024
    Во-первых, это, скорей, не суперкомпьютеры, а кластеры обычных компьютеров: физически там множество компьютеров, каждый под управлением своей собственной ОС и т.д. и т.п.
    
    А во-вторых, на железе от Интел их не строят никогда -- их строят на железе и Невидии, и именно её ГПУ выполняют всю "суперкомпьютерную" обработку, а кто скармливает им работу, абсолютно неважно.
    
    Но таки да, на мэйнфреймах суперкомпьютеры-числодробилки не строят -- они под другие задачи заточены.
    
    Hemml
    09.07.2025 15:41
    #28558762
    На GPU далеко не все алгоритмы ложатся, увы. Они только для очень специфичных задач.
    
    vadimr
    09.07.2025 15:41
    #28558942
    Ну в любом случае мейнфреймы от рождения не специализированы для численных расчётов, и потому имеют другое назначение, чем суперкомпьютеры.
  1. zVlad909 Автор
    09.07.2025 15:41
    #28558608
    Мне думается у ИБМ МФ еще будет ренесанс. Уж больно это, облака и клатеры на х86, напоминает мыльный пузырь. В нашей не маленькой, но и не большой компании сервера в Azure and on-prem исчисляются тысячами. От верхнего руководства идут сигналы про "че то дорого это ИТ, нельзя ли подешевле". Ищут и легко находят сервера без хозяина, почти простаивающие все время, сервера с пустыми дисками (кстати в Azure скорость I/O зависит от размера диска, хочешь хорошую скорость бери, надо не надо, больше диски). Было даже так что поступил запрос на новый сервер в то время как он уже существовал и работал в продакшн. Чувак преодолел все препоны и предупреждения и засунул это сервер (пустой пока) в домэйн , а тот что был из домэйна выпал и сервис пропал (это был WiFi). Все кто сидел на WiFi отвалились.
    
    Рано или поздно все это рухнеи как карточный домик и взгляды снова обратяться к ИБМ МФ.
    
    ShaltaiBoltai
    09.07.2025 15:41
    #28560500
    Да IBM и не загибается. Она даже не чувствует себя больной. Просто, в отличие от безапелляционно восхищенного тона статьи - мол, эти ваши x86 фигня, а вот мейнфреймы IBM - это настоящие серьезные компьютеры, мир так не считает. Большинство компаний, имея бюджеты на IT-инфраструктуру, позволяющие им затариться zEnterprise по самую макушку, всё равно этого не делают, а предпочитают решения на x86 или arm. Посмотрите, на каком железе гиганты индустрии строят свои датацентры. zEnterprise в таких новостях не упоминается ни разу. zEnterprise - это решение для тех, кто уже плотно сидит на предыдущих поколениях мейнфреймов от IBM. Остальные в сторону IBM смотрят редко. Если кто и строит свою IT-инфраструктуру с нуля на zEnterprise - это единичные случаи. Раз в 10 лет :)
    
    Но, повторю, IBM клиентов хватает, линейка zEnterprise развивается и загибаться не планирует. Просто она не на 100500 голов выше решений на x86, как поется в статье, она просто другая.
    
    Ну, и, разумеется, мне, обитателю условного кишлака из условного Афганистана нет большого смысла рассуждать о преимуществах и недостатках мейнфреймов IBM. Тем более, с канадцем. Мы с вами в разных мирах живем.

JBFW
09.07.2025 15:41
#28550362
Все дело в деньгах, как правильно заметил предыдущий оратор - вместо ОДНОЙ ОЧЕНЬ ДОРОГОЙ установки, для которой актуально ее максимально сбалансированное использование - в мире х86 принято набрать больше мелких серверов.

И даже не х86: как выяснилось, для некоторых задач можно использовать кучку arm-серверов, каждый из которых стоит копейки, решает одну свою задачу, и поэтому вопрос о его недозагруженности не имеет практического значения.
А в случае перегруженности - добавить еще один копеечный сервер.

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

То есть, тут принципиально разные пути эволюции, и чем дальше - тем больше они расходятся...
1. SIISII
  09.07.2025 15:41
  #28550428
  Ну, во-первых, мэйнфреймы отлично масштабируются. При нужде досыпать процессоров и памяти, как правило, проблемой не является.
  
  Во-вторых, ничто не мешает поставить два мэйнфрейма в физически разных местах, чтобы уберечь от всяких там бедствий (точно так же, как и обычные серверы придётся ставить в разных местах).
  1. JBFW
    09.07.2025 15:41
    #28550448
    А вот это опять деньги
    
    Разумеется для каких-то задач это подходит, а для каких-то других больше подходит "стая мелюзги"
    
    Поэтому и говорю что разные пути эволюции.
    
    zVlad909 Автор
    09.07.2025 15:41
    #28555316
    Конечно не везде приемлем МФ, но судя по содержимому Хабра "стаи мелюзги" используются в подавляющем применении в России. На Западе это не совсем так.
    
    Например на чем работают Госуслуги, СФР, Сбер и другие крупные банки, ЦБ, ФСБ, МО, и т.п. организации? Подозреваю что не на МФ. Возможно в некоторых из них и были МФ (ЕС ЭВМ), но запущенный в 90-е процесс вытеснения МФ (ЕСЭВМ) в 90-е годы и потеря компетенци в этой области вытеснила их и там.
    
    На Западе в одной и той же компании могут прекрасно сосуществовать и "стаи мелюзги", и ИБМ МФ. Особенно в банках это присутсвует. На МФ центральная БД и транзакции выполняются. На серверах фронтэнды.
    
    vadimr
    09.07.2025 15:41
    #28555338
    Некоторые из этих организаций в России использовали IBM z до недавнего времени, но санкции США в 2022 усложнили взаимодействие с IBM, а для мейнфрейма это очень важно по причине лицензионной политики.
    
    zVlad909 Автор
    09.07.2025 15:41
    #28555382
    И что они совсем покончили с z? Я давно живу и работаю в Канаде и совсем не имею представление об z в России. Но скоро освобождаюсь и собираюсь больше быть в России и хотелось бы к теми у кого z повстречаться, пообщаться помочь если надо.
    
    Кстати у меня были контакты в ИБМ Россия, меня даже туда хотели взять в 1998 году, но не было у меня английского тогда.
    
    Что касаемо лицензий то по-моему с этим не стоит заморачиваться. Это форс-мажер и надо просто продолжать использовать то что ИБМ бросил уйдя. Они еще вернутся. ПО МФ легко переносится на новое оборудование, легче гораздо чем ПО х86. Оборудование можно добывать через третьи страны, секонд нэнд. Это совсем не дорого. Есть возможности.
    
    vadimr
    09.07.2025 15:41
    #28555386
    Я не знаю, как они решают этот вопрос. Мейнфреймы – это большие деньги, которые любят тишину. Но современный мейнфрейм IBM технически невозможно эксплуатировать без возобновляемой лицензии на процессорное время, разве не так?
    
    zVlad909 Автор
    09.07.2025 15:41
    #28555600
    Нет не так. Мы (мои дебильные манагеры) уже два года и больше как порвали контракт с ИБМ саппорт. И ничего работает машинка. Правда они продолжают платить помесячную плату. Но в случае с Россией и этого не обязательно делать. У наших МФ нет никакой связи с ИБМ. Раньше была.
    
    SpiderEkb
    09.07.2025 15:41
    #28560492
    Примерно аналогично и для IBM i. Лицензии там бессрочные. Обновления (TR - Technology refresh) тоже можно каким-то образом доставать. Даже новое железо можно в принципе. Т.е. тут как всегда - вроде как и ушли, но... есть нюансы, как говорится.
    
    SIISII
    09.07.2025 15:41
    #28556100
    Возможно, это зависит от конкретной модели мэйнфрейма -- в последние могли и внедрить некую защиту от нелицензионного использования.
    
    zVlad909 Автор
    09.07.2025 15:41
    #28558410
    Некая защита (если это можно было бы называть защитой) заключается в том что (речь идет только о МФ для z/OS) при покупке МФ оговаривается конфигурация, которую хочет использовать покупатель. Это включает количество и типы CPU (их несколько), уровень производительности тех CPU на каких будет выполняться z/OS (последнее выражется т.н. capacity model в формате LNN, где L - буква от A до Z, NN - число, количество CPU для z/OS. Вариантов море), размер памяти для LPARs.
    
    Именно эта оговоренная при покупке конфигурация и будет встроена в предоставленном МФ. На самом деле в МФ будет такая конфигурация (их немного) какую делают на заводе.
    
    В процессе установки МФ на нем конфигурируется служба т.н. Call-home. Т.е. связь через инет в ИБМ Control and Support Center (Outbound Connectivity). Это нужно для того чтобы ИБМ получала все сигналы от МФ по поводу поломок и для другого ниже описанного. Call-home не обязателен, МФ работает и без этого. Но никто вам не позвонит и не скажется что у вас не так с МФ и вы не сможете делать описаное ниже и еще многое другое.
    
    В процессе использования пользователь может захотеть добавить "дровишек" к конфигурации. Это оформляется как Purchase Order, обсчитывается, выставляется счет, оплачивается. В итоге ИБМ создает некий record и сообщает пользователю order number. Системный программист пользователя заходит на Hardware Management Console, выбирает нужный МФ, переходит в Single Object Operation для этого МФ, выбирает "Perform model conversion" и далее в "Receive, and Active" for "Permanent Upgrade". HMC запрашивает order number, вводим, Ок, ждем несколько минут, Done, можем приступать к использованию новой конфигурации. Большей, или ......меньшей. Мы переходили на меньшую, это экономило деньги.
    
    Есть еще Temporary Upgrade это когда можно на до 10 дней увеличивать мощность МФ. Рекорды для таких апгрейдов закупаются заранее нужным количеством и могут использоваться например для ежегодных DR test или чего угодно еще. Эти рекорды могут активироваться системщиком когда угодно. Использованные рекорды из списка удаляются и так пока все не использованы. Их можно докупать по мере надобности. У нас такие рекорды использывались для DR test и изменяли capacity model с А01 (один CPU на наименьшей скорости) до z03 (три CPU на максимальной скорости).
    
    SpiderEkb
    09.07.2025 15:41
    #28560478
    Ну у нас именно так. Есть центральные сервера (не МФ, middleware - IBM i) и есть "куча мелюзги" - "внешние системы". Там и винда и RHEL и SLES и много чего.
    
    Центральные сервера - это АБС. Ядро всего банка. Все mission critical. Все остальное (что не так критично по времени недоступности, скорости отклика и т.п.) вынесено на внешние системы.
1. DenSigma
  09.07.2025 15:41
  #28552096
  Распределенные системы сложнее программируются. На обслуживании распределенных систем целая "индустрия" работает - DevOps.
  1. SIISII
    09.07.2025 15:41
    #28552522
    И куда больше времени тратится на согласование работы, выполняемой на физически разных машинах. Где-то это может быть несущественно, где-то -- очень важно.
    
    SpiderEkb
    09.07.2025 15:41
    #28560502
    Там основная проблема в скорости доступа. Елси та же БД сосотоит из нескольких десятков тысяч таблиц и индексов, то разносить ее по физически разным серверам становится сложно в плане резкой деградации скорости выполнения запросов (когда разные таблицы одного запроса на разных физических машинах оказываются).
1. zVlad909 Автор
  09.07.2025 15:41
  #28555360
  .....но и для того, чтобы когда один из серверов вышел из строя (потоп, пожар, физическое уничтожение) - оставшиеся подхватили бы работу.У одного большого мейнфрейма такой опции в принципе нет, если условно говоря он будет уничтожен - пострадают все, у кого на нем что-то работало.
  
  Ну это притянутый за уши аргумент. Во первых, и сервера на х86 и МФ располагаются в весьма защищенных дата центрах. Возможность потопа, пожара, физическое уничтожения в них сведено на нет, а если это и произойдет то выгорит все до тла. Это называется Disaster при против этого как в отношении ИТ на серверах х86, так и МФ компании разрабатывают и тестируют каждой год DR plan.
  
  У одного чего угодно нет возможности защиты от этого одного полного уничтожения. Минимум два конечно же, на разных локейшн. Или аренда DR сайта в другой организации. У нас одно время был DR site в ИБМ. Просто один наш МФ стоял в нашем, единственном ДЦ, а второй в ДЦ ИБМ.
  1. JBFW
    09.07.2025 15:41
    #28556372
    Возможность потопа, пожара, физическое уничтожения в них сведено на нет
    
    Хаха три раза, это только в крупных компаниях федерального значения, и только те случаи про которые мне было известно (а обычно об этом не особо распространяются).
    
    Про небольшие конторы уж и не говорю. Но у них на МФ денег просто нет, и не надо.
    
    SpiderEkb
    09.07.2025 15:41
    #28560496
    В небольших конторах и задач под МФ нет.
1. zVlad909 Автор
  09.07.2025 15:41
  #28558664
  Вот это:
  
  ...вместо ОДНОЙ ОЧЕНЬ ДОРОГОЙ установки, для которой актуально ее максимально сбалансированное использование - в мире х86 принято набрать больше мелких серверов.
  
  хочется продолжить так " ...миру х86 пофиг сбалансированность, т.е. эффективность, оптимальность, навалим столько ресурсов на сколько хватит денег и будем сидеть курить бамбук.
  
  Мой манагер, он же типа наш "архитектор" часто говорит так: примерно "берем Кубернетес, запускаем 50 подов в них 50 приложений." И хочется спросить " и что?".
  
  Помню обсуждали проблему перформанс одногт сервера с несколькими приложениями, Манагер спрашивает: "а какое приложение жрет ресурсы больше", серверисты наши разводят руками и говорят: "Мы не знаем". Для меня это звучит как детский лепет. В zOS я вижу все что происходит и как происходит, кто что и сколько ест, к чему это приводит и как это поправит. Это все потому что в z/OS есть WLM. Он все знает и по полиси созданной мной раздает. Плохо раздает, я меняю полиси и смотрю что стало. Это можно делать хоть на Продакнш хоть где столько раз сколько нужно чтобы добиться результата.
  1. SpiderEkb
    09.07.2025 15:41
    #28560530
    Манагер спрашивает: "а какое приложение жрет ресурсы больше", серверисты наши разводят руками и говорят: "Мы не знаем". Для меня это звучит как детский лепет.
    
    Вот именно. У нас сопровождение постоянно мониторит загрузку. И всегда видит кто сколько жрет.
    
    Запрос типа
    
    Сервис ... за последние 5 недель увеличил потребление ресурсов в 3 раза. На данный момент является вторым по величине сервисом.
    
    В качестве альтернативы рассматривается перенос сервиса на резервный сервер, что приведет к лагу до 10ти минут что недопустимо
    
    Означает необходимость доработки сервиса для оптимизации потребления ресурсов.

SIISII
09.07.2025 15:41
#28550376
Что, в какой-то момент длину имён наборов данных увеличили? В классической OS/360 она составляет максимум 44 символа, а не 144. Или это опечатка?

В "доисторической эре" не упомянут режим PCP -- однопрограммный. Самая первая версия OS/360 работала именно в этом режиме, поскольку IBM не успевала сделать всё, что хотела, причём для работы было достаточно 32 Кбайта памяти (примерно 14 занимало ядро системы, остальное уходило под программу пользователя или системную программу, не входящую в состав ядра). По мере развития системы требования к памяти росли; самые последние варианты PCP требовали 64 Кбайта. В конце концов, этот режим полностью выпилили, и самым младшим стал MFT, требующий к тому моменту 128 Кбайт (на момент своего появления ему было достаточно 64).

Не отмечена также изначально (или почти изначально) присутствовавшая возможность для прикладных программ создавать контрольные точки (checkpoint), чтобы в случае какого-то сбоя система могла возобновить выполнение программы с этой точки, а не с самого начала.
1. zVlad909 Автор
  09.07.2025 15:41
  #28551314
  Что, в какой-то момент длину имён наборов данных увеличили? В классической OS/360 она составляет максимум 44 символа, а не 144. Или это опечатка?
  
  Это опечатка. Спасибо что заметили. Попробую испрасить.
1. zVlad909 Автор
  09.07.2025 15:41
  #28551322
  Спасибо за критику. В одной статье охватить все ньюансы соверешенно невозможно. Такой подробности я не ставил своей целью. Статья и так получилась крупной для статьи.
  
  Да, checkpoint, а сколько еще разного было что отличало уже в 70-е годы прешественников нынешнего zOS от нынешних Юникс, Линукс, Виндовз, и еще больше собственно zOS.
1. zVlad909 Автор
  09.07.2025 15:41
  #28551354
  Исправил 144 на 44. Спасибо еще раз.

jobless
09.07.2025 15:41
#28550432
Спасибо. А планируете статью о z/VM? Особенно интересно во что превратилась CMS (ПДО у нас). Ведь это система со 100% паравиртуализацией. Приходилось ковыряться в макросах ввода вывода и обнаруживать вместо SIO,TIO,HIO обращения к супервизору (кажется термина гипервизор тогда не было) за услугой.

p.s. переписывал для себя stdlib Си-транслятора от НИЦЕВТ под ПДО

p.p.s. Master sheduler FOREVER!!!
1. SIISII
  09.07.2025 15:41
  #28550442
  У нас в СВМ гипервизор именовался монитором виртуальных машин (МВМ); супервизор же был, в первом приближении, ядром DOS/360 и OS/360, но не VM/370.
  
  ПДО -- да, однозадачная ОС, предназначенная для эксплуатации исключительно под СВМ, поэтому-то никаких команд ввода-вывода в ней нет.
  
  Пы.Сы. А Мастер Шедулер -- это уже про ОС/360, она же ОС ЕС :)
  1. jobless
    09.07.2025 15:41
    #28550472
    ПДО -- да, однозадачная ОС
    
    Однопользовательская, но многозадачная! У меня волею случая была фактически в качестве персоналки ЕС-1007 с терминалами ТС-7063. Поставили под проект который не взлетел и никому до неё дела не было.
    
    SIISII
    09.07.2025 15:41
    #28550516
    Ну да, хотел про однопользовательскую сказать :)
    
    zVlad909 Автор
    09.07.2025 15:41
    #28551368
    Вы не ошиблись. Строго говоря ПДО(CMS) была однопользоваетльской и однозадачной. Это можно легко проверить по документации, но я знаю это потому что в сотрудничестве с НИИЭВМ я с моими коллегами дорабатывал VM/SP Pass-Through для перекачки файлов из ПДО на ПК. Так вот в этом VM/SP Pass-Through был встроенный монитор многозадачночности. Многозадачность исходного ПДО достигалась запуском нескольких виртуальных машин и использованием протоколов связи ВМ через память.
1. Zhuravlev-A-E
  09.07.2025 15:41
  #28551128
  Приходилось ковыряться в макросах ввода вывода и обнаруживать вместо SIO,TIO,HIO обращения к супервизору (кажется термина гипервизор тогда не было) за услугой.
  
  видимо с помощью команды diag (на виртуальной машине это обращение к гипервизору, термин такой тогда уже был), в частности для ввода/вывода - diag 0020
  1. SIISII
    09.07.2025 15:41
    #28551286
    Угу. Вот только не diag, а просто ДИАГНОСТИКА -- у неё официально нет мнемоники. Впрочем, это уже придирки :)
  1. zVlad909 Автор
    09.07.2025 15:41
    #28551410
    Вы правы про гипервизор, согласно Вашей ссылке, но я не знал. В те года что я работал с СВМ ЕС этот термин в русскоговорящей среде не использовался и в документации на СВМ ЕС на русском языке, насколько я помню, не использовался.
1. zVlad909 Автор
  09.07.2025 15:41
  #28551404
  Классный вопрос. Очень неожиданный и приятный.
  
  СВМ ЕС, VM/SP это моя бурная молодость. 1985-1995 года (мои 30-40).С коллегами мы внедрили СВМ ЕС с БОС практически во все ВЦ Челябинской области (кроме ВЦ ЖД и еще может двух-трех) и еще пару-тройку ВЦ в Тюмени. Я провел до десяти курсов (40 часов) лекций по СВМ ЕС. Тесно сотрудничал с НИИЭВМ (Котов Михаил Петрович - начальник отдела, был R.I.P). Но, из Вики:
  
  Паравиртуализация (англ. Paravirtualization) — техника виртуализации, при которой гостевые операционные системы подготавливаются для исполнения в виртуализированной среде, для чего их ядро незначительно модифицируется.
  
  VM/370, VM/SP, и соответственно СВМ ЕС изначально были 100% виртуализацией реальной машины. Это значит что любая ОС МФ могла выполняться под VM/370 без каких либо проблем и доработок (исключения есть, но есть и решение для них в опциях конкретной виртуальной машины). Термина паравиртульность в те годы не было.
  
  Да ПДО/CMS была изначально разработано для виртуальной машины под управлением CP (Control Program) (термина Hypervisor тогда тоже не было еще).
  
  Ввод-Вывод в программах под ПДО осуществлялся макросами Ассемблера и операторами ввода-вывода языков высокого уровня заканчивающимися выполнением привелигированной команды DIAG (именно это Вы и должны были обнаруживать вместо SIO,...) - интерфейс к CP - используемый для выполнения ввода-вывода в CP (CP это не супервизор, супервизором тогда называли супервизор ввода-вывода для реальной МФ: DOS, OS/360, MVS, etc..) .
  
  Кроме этого в программах на Ассемблер под ПДО можно было подготавливать программу канала и выполнять ее с SIO, TIO, HIO, но это экзотический подход используемый для экзотических нужд, требующих отличного знания архитектуры ввода-вывода МФ и как СР будет реагировать на это. Я использовал этот поход для работы с терминалом 3270 эмулированным на ПК для копирования файлов.
1. zVlad909 Автор
  09.07.2025 15:41
  #28555344
  Я просмотрел CMS User Guide в zVM 7.3 (2025). Cудя по оглавлению практически все остлось как было в VM/SP. Добавилось пара-тройка новых названий (DFSMS/VM, CMS/DOS).
  
  И в самом деле зачем что-то добавлять в легкую системку персонального использования.
  1. jobless
    09.07.2025 15:41
    #28555824
    https://www.ibm.com/docs/en/zvm/7.4.0?topic=xl-cc-zvm-13
    
    Я и забыл, что IBM документация настолько доступна. Пока листал наткнулся на СИ и вспомнил свои приключения с Си под ПДО. Не помню как на ТС-7063, но на ЕС-7927 на клавиатуре фигурных скобок точно не было. А в знакогенераторе были и после перекодировки диграфов на экране показывались. :)
    
    SIISII
    09.07.2025 15:41
    #28556110
    Возможно, из-за того, что клавиатура ЕС-7927 рассчитана на ДКОИ, но собственно терминал внутри использует ASCII (точней, КОИ-что-то-там).
    
    Zhuravlev-A-E
    09.07.2025 15:41
    #28556270
    ЕМНИП, с малыми буквами была веселуха у разного EC-оборудования: вроде их можно было где-то на клавиатуре набирать, но отображались они на одних дисплеях правильно, на других - большими буквами, еще где-то точками, на некоторых АЦПУ пробелами ...
    
    SIISII
    09.07.2025 15:41
    #28556580
    На ЕС не встречал (хотя вполне могло быть), а вот на СМках это было обычное дело. IНЖАЛИД ДЕЖИЦЕ оттуда ж пошло :)
    
    zVlad909 Автор
    09.07.2025 15:41
    #28557786
    Не только доступна, но и очень высокого качества. По крайней мере для продуктов на МФ.
    
    Я сталкивался с ЕС-1007 только в одном месте - в филиале Института Теплотехники Челябинск-40. Даже наверное устанавливал СВМ ЕС (а что еще я мог там делать?). Но я не помню такого устройства ТС-7063. Почему ТС? Нырнул в Инет. Ну конечно же это ЕС-7970 комплекс. Такого зверя я знал. Прекрасная штука, почти персональный компьютер. Клавиатура мягкая, шрифт хороший. В лучшую сторону отличался по сравнению с ЕС-7927.
    
    SIISII
    09.07.2025 15:41
    #28558028
    У него сдвоенное обозначение, но почему, лично я не в курсе. Но вообще, такое бывало достаточно часто, но обычно с забугорными машинами (скажем, ЕС-1040 и ЕС-1055 имели у Роботрона свои собственные обозначения).
    
    jobless
    09.07.2025 15:41
    #28558270
    https://habr.com/ru/articles/383231/
    
    zVlad909 Автор
    09.07.2025 15:41
    #28558538
    Да я это тоже находил. Спасибо.
    
    jobless
    09.07.2025 15:41
    #28558276
    Не состоявшееся будущее https://vk.com/wall-45420541_6392
    Однажды был шокирован на выставке сочетанием шилдика ЕС-79XX и digger на цветном экране. )))

nv13
09.07.2025 15:41
#28550634
Однокурсник рассказывал, что когда все сотрудники расходились по домам и наступала ночь, их мейнфрейм начинал чем то там сам с собой заниматься, держа 30-40% нагрузки)
1. artptr86
  09.07.2025 15:41
  #28550738
  Банковский день закрывал?
  1. nv13
    09.07.2025 15:41
    #28551256
    Говорил, что какие то сервисные процедуры гонялись
1. zVlad909 Автор
  09.07.2025 15:41
  #28551606
  Был такой подход к использованию МФ когда днем пакетная обработка заданий не выполнялась в угоду диалоговой, дневной. Т.е. запустить пакетное задание было возможно, но т.н. инициаторы заданий запускались после рабочих часов. Задания эти хранились в очередях заданий и после окончания рабочего дня запускались инициаторы и шло выполнение этих пакетных заданий.
  
  К утру все они завершались и результаты их работы либо распечатывались либо помещались в очереди к тем кто их запускал для просмотра и дальнейшей обработки. Пакетные задания и инициаторы имели т.н. классы и часть пакетов, в определенных классах, могли и днем выполняться, а те что не к спеху отправлялись в тот класс(ы) что выполнялись ночью. Вот этими очередями заданий submitted днем и выполняемыми ночью и занимался их мэйнфрэйм.
  
  С появлением WLM (начало 21 века), и даже несколько раньше это стало не актуально и пакетные задания принимаются теперь для исполнения весь день и ночь, но в discretionary сервис классе. В правильном переводе на русский это надо понимать как "по усмотрению". Т.е. такие задания выполняются когда работы во все других сервис классах достигли своей цели и еще остались ресурсы, вот тогда ресурсы выдаются заданиям/работам в discretionary service class. Другими словами эти работы никому не мешают и используют только остатки (объетки если хотите).
  
  Опять же если какие-то задания должны выполняться в любое время суток с выше чем discretionary importance (важностью) они запускаются в очереди классов, обслуживаемых WLM в сервис классах с более высокими важностями, и возможно разными velocity (относительнуые скорости).

Kelbon
09.07.2025 15:41
#28551024
Вся статья состоит из того что там что-то безопаснее и так далее, а можно конкретики? Я напомню, что другие ОС тоже не собираются падать от чего угодно, у нас есть виртуальная память в процессоре, мы можем сами перезапустить программу (а не дать ОС бездумно перезапустить и сделать всё хуже)
1. SIISII
  09.07.2025 15:41
  #28551288
  А, например, при отказе процессора или блока памяти?
  1. prinv
    09.07.2025 15:41
    #28551700
    Hot-swap CPU и RAM это не уникальная фишка мэйнфреймов IBM.
    Навскидку, Sun/SPARC, DEC/Alpha умели это
    
    vadimr
    09.07.2025 15:41
    #28552078
    Вопрос не в hot swap, а в продолжении работы программы.
    
    bazanovv
    09.07.2025 15:41
    #28553096
    Уже лет 15, как существует технология виртуализации VMware Fault Tolerance, позволяющая для одной или нескольких виртуальных машин защититься от отказа процессора или сервера целиком, с немедленной активацией резервной копии ВМ и сохранением её состояния, включая все запущенные программы и их состояние. Да, есть ограничения - в первых версиях можно было только одно виртуальное ядро на ВМ, сейчас до 8 ядер. И стоит дорого. И, на практике, используется достаточно редко - обычные технологии кластеризации и проще, и надёжнее. Старое описание FT, текущие ограничения для vSphere 8.0.
    
    SIISII
    09.07.2025 15:41
    #28553130
    
    Для виртуальных машин. А что с самим гипервизором? Или с приложениями, работающими под управлением ОС на реальной, а не виртуальной машине?
    
    Способность восстановления после сбоев или отказов аппаратуры IBM развивала, начиная ещё с Системы 360, т.е. со второй половины 1960-х годов. Это довольно неплохо работало уже в поздних версиях классической OS/360 (а её развитие прекратилось на версии 21.8 году эдак в 1972-74; дальше шли уже системы с виртуальной памятью, быстро превратившиеся в MVS, из которой выросла нынешняя z/OS). Т.е. то, что на "обычных компах" появилось 15 лет назад, IBM имеет уже с полвека.
    
    bazanovv
    09.07.2025 15:41
    #28553186
    
    Гипервизор у нас уже умер вместе с отказавшим процессором, да и фиг с ним. На работу прикладной ВМ с настроенной FT это уже никак не влияет.
    
    Не уверен, но мне кажется, вы путаете разные технологии восстановления при сбоях и отказах железа - ECC для памяти и шин процессора и т.п. и в x86 уже работают достаточно давно. Речь же в этой ветке шла о полном сохранении состояния прикладной программы (не до контрольной точки, а текущего состояния) при полном отказе (а не сбое по шине) процессора. Вы уверены, что мэйнфрейм 1974 года обеспечивал такой функционал?
    
    Понятно, что в более дорогих мейнфреймах использовались топовые на этот момент технологии, этот тезис я и не пытаюсь оспорить. Наоборот, мой тезис в том, что сейчас в мире x86 и существующая технология полной защиты от аппаратных сбоев достаточно мало востребована - эти проблемы решаются на уровне архитектуры прикладного ПО, кластеризации, контейнеризации и т.п.
    
    SIISII
    09.07.2025 15:41
    #28553400
    Не уверен, но мне кажется, вы путаете разные технологии восстановления при сбоях и отказах железа - ECC для памяти и шин процессора и т.п. и в x86 уже работают достаточно давно
    
    Нет, речь именно о возможности восстановления работы после сбоя/отказа, а не чисто схемы коррекции ошибок -- таковые в мэйнфреймах были очень давно, но они -- лишь техническая база, так сказать. Скажем, наша ЕС-1035 микроархитектурно содрана с IBM 370/145 (если правильно помню; кстати, это единственный известный мне случай, когда наша машина микроархитектурно повторяет IBMовскую -- остальные, с которыми разбирался, хотя и имеют большее или меньшее сходство, но имеют и серьёзные микроархитектурные отличия) на уровне железа поддерживала контроль и коррекцию управляющей (микропрограммной) и основной (оперативной) памяти по коду Хэмминга, а также умела выполнять сбойнувшие микрокоманды повторно -- отказ фиксировался, если 8 повторений оказывались безуспешными. Но всё это, как понимаете, -- чисто железные (или микропрограммные, что для программы безразлично) вещи, и никакой специальной поддержки со стороны ОС им не нужно: они работают сами по себе.
    
    Вы уверены, что мэйнфрейм 1974 года обеспечивал такой функционал?
    
    Если мэйнфрейм двухпроцессорный (что для 1974 года было редкостью, но таки было -- первые ещё в 1960-х появились), то да, такая возможность была. Ну а будет ли рестарт с текущего состояния или с контрольной точки, зависит от того, удалось ли сохранить текущее состояние в корректном виде, а это уже зависит от вида отказа -- но это и сейчас так.
    
    Скажем, в ЕС-1033 (архитектурно это ещё Система 360 -- без MMU, а соответственно, без виртуальной памяти) блок диагностики работал абсолютно независимо от самого процессора, имел собственное микропрограммное управление и т.д. и т.п. Поэтому при отказе процессора он мог сам сохранить содержимое всех регистров в память -- естественно, при условии, что их содержимое не пострадало (контроль по нечётности), интерфейс с памятью работает и т.д.; другой процессор двухпроцессорного комплекса уведомлялся об отказе посредством прерывания, и ОС могла, проанализировав сохранённые данные, принять решение о дальнейших действиях.
    
    Но вообще, даже на однопроцессорных машинах определённые средства и возможности были. В частности, полноценный обработчик машинных ошибок (MCH, machine check handler), который был предусмотрен для любой машины Системы 370 и для некоторых старших моделей Системы 360, старался сохранить работоспособность того, что можно. Например, если неустранимый сбой возник при выполнении прикладной программы, её дальнейшее выполнение оказывалось невозможным, но работоспособность системы и других программ сохранялась. Кроме того, если для сбойнувшей программы был предусмотрен перезапуск, он мог производиться автоматически (либо с её начала, либо с последней контрольной точки). Если система была с виртуальной памятью (это уже не классическая MFT/MVT, а SVS или MVS -- но тоже первая половина 1970-х) и вышел из строя блок памяти, но его содержимое не менялось с момента последней загрузки, производилась загрузка нужной страницы в другой блок памяти, после чего работа возобновлялась -- ну и т.д. и т.п. Понятно, что всё это в дальнейшем совершенствовалось, и поздняя MVS ушла далеко вперёд от MFT, но, тем не менее, всё это начиналось с самого начала, а не сильно позже, и достаточно успешно работало уже в MFT/MVT, где железо позволяло.
    
    мой тезис в том, что сейчас в мире x86 и существующая технология полной защиты от аппаратных сбоев достаточно мало востребована - эти проблемы решаются на уровне архитектуры прикладного ПО, кластеризации, контейнеризации и т.п.
    
    Мне кажется, что все эти решения не обеспечивают полной защиты от проблем с железом. Как, например, восстановить работоспособность программы, если сдох процессор и содержимого регистров на момент отказа нет (они где-то в процессоре остались)? Никак тут не восстановишь с момента сбоя -- только с последней контрольной точки, если таковая имеется, ну или вообще только запуском с самого начала. Ну а на мэйнфреймах в тех случаях, когда это технически возможно (содержимое памяти корректно и были успешно сохранены регистры процессора), работа пострадавшей программы продолжается именно с точки сбоя, буквально с команды, при выполнении которой сдох процессор.
    
    Кроме того, защищаться путём соответствующей архитектуры прикладного ПО, естественно, можно -- но это резко усложняет это самое ПО и заставляет создавать необходимый функционал в каждой прикладной программе. В этом плане возможность разруливать ситуацию и обеспечивать восстановление на уровне аппаратуры и ОС для любого прикладного кода весьма ценна -- хотя, естественно, лучшие результаты достигаются в случае, когда и прикладное ПО спроектировано так, чтоб облегчать восстановление.
    
    bazanovv
    09.07.2025 15:41
    #28553560
    Мне кажется, что все эти решения не обеспечивают полной защиты от проблем с железом. Как, например, восстановить работоспособность программы, если сдох процессор и содержимого регистров на момент отказа нет (они где-то в процессоре остались)? Никак
    
    Так в том и суть vSphere Fault Tolerance, что она сохраняет работоспособность ВМ именно в таком случае - за счёт того, что ровно те же вычисления с такой же памятью и состоянием регистров выполняются на "теневой" копии ВМ на втором гипервизоре, а поведение процессора детерминировано. Там, где что-то не детерминировано или может рассинхронизироваться, нужные данные подтягиваются в теневую ВМ по сети (минимум 10 Гбит), при необходимости основная или теневая ВМ чуть притормаживается до синхронизации. При обнаружении отказа основной ВМ/гипервизора/etc теневая ВМ становится основной, ничего не заметив (реально там будет некоторая пауза и, как минимум, оповещение сетевого оборудования о смене интерфейса, на котором живёт этот MAC/ip, т.к. ввод-вывод на ВМ разблокируется, но это детали). Это действительно весьма крутая технология, защищающая от полного внезапного отказа железа или гипервизора - но она практически не востребована в реальной жизни.
    
    По остальным вопросам разногласий нет, спасибо!
    
    SIISII
    09.07.2025 15:41
    #28553910
    Про подобную реализацию не знал. Век живи -- век учись (и дураком помрёшь :) ).
    
    zVlad909 Автор
    09.07.2025 15:41
    #28554980
    .... при необходимости основная или теневая ВМ чуть притормаживается до синхронизации.
    
    Только не при необходимости, а постоянно притормаживается для синхронизации. Более того сама координация выполнения виртуальной машины на двух серверах берет ресурсы.
    
    Если сравнить с репликацей БД в синхронном режиме то притормаживание происходит только по фактам изменения данных, а здесь по видимому каждый шаг в праймери ВМ должен останавливать, дублироваться в стэндбай и лишь потом делаться следущий шаг. При этом еще на каждом шаге надо проверить кто из двух еще жив, упасть может любой из двух.
    
    Может я ошибаюсь в отношении VMWarе FT, но я хорошо знаю виртуальные машины и вряд ли сильно фантазирую.
    
    Тем не менее, то о чем говорит SIISII и то что говорите Вы это две разные проблемные области и соответственно два разных решения. Как я уже писал выше аналогом VMWare FT уместно считать Parallel Sysplex широко используемый в мире МФ, не имеющий существенных издержек синхронизации просто потому что каждая из до 32 zOS выполняет свою работу независимо, координуруя это с другими через Coupling Facility и когда падает то другие (один из них конечно) тут же продолжают работу падшего узла взяв данные из этого самого Coupling Facility.
    
    Это конечно не защита ВМ с гипервизором, но защита конкрентых работ с использованием таких сервисов как БД, сервер приложений и т.п.. Я не в курсе какие средства есть в современной zVM на этот счет, но чисто умозрительно думается что это внутренне дело ОС ВМ потивостоять неожиданным потерям своего существования, что в принципе может быть и в результате программной ошибки в ОС ВМ и в соответствий с принципом работы VMWare FT реплицироваться а теневую среду вызвав и в ней точно такое же падение. Т.е. остается только защита от аппаратных сбоев. С МФ с ней борятся избыточность аппаратуры и возможностью перехода с сбоящих элементов на запасные. В МФ всегда есть избыточные CPU не использымые для ОС, избыточная память (ЕСС всего лишь исправление одиной ошибки и сигнал о двой ошибке) по принципу на подобии дисковы RAID-5 в дисках называемая RAIM:
    
    RAIM (Redundant Array of Independent Memory) is a memory subsystem design used in IBM z/Architecture mainframes to enhance memory reliability and availability. It employs redundancy and advanced error correction techniques to protect against memory module failures, ensuring continuous operation even when modules fail. RAIM is more robust than traditional ECC memory and can correct multiple DRAM device failures and even entire memory channel failures.
    
    Есть и избыточные каналы ввода-вывода. Диски используемые МФ обычно RAID-5 (полагаю Вы в курсе этого).
    
    Мф очень сложно "убить", и практически всегда есть Дизастер Рековери процедура обычно таким образом что два МФ на разных локациях являются DR site друг для друга. Диски зеркалятся в обе стороны, накаких систем (standby) нет, в случае DR на другой машине подымаются погибшие системы с зеркала. Обычно это происходит автоматически. Да, есть down time, 10-15 минут в худшем случа, но это дизастер, т.е. физическое, полное уничтожение одного из дата центр.
    
    vadimr
    09.07.2025 15:41
    #28554990
    С синхронизацией ВМ ещё проблема в том, что не обязательно ведь в результате ошибки ВМ упадёт. Там может просто измениться какой-нибудь битик в памяти, и фиг это заметит гипервизор.
    
    bazanovv
    09.07.2025 15:41
    #28555048
    От изменения бита в памяти мы защищены ECC у памяти и шины, а вот логическую ошибку ПО или BSOD в ОС, FT, да, точно в таком же виде оттранслирует на теневую копию, это факт.
    
    vadimr
    09.07.2025 15:41
    #28555070
    
    ECC снижает вероятность ошибки, но не обнуляет её.
    
    Ошибка может произойти в процессоре. Помнится, я читал, что в среднем раз в год микропроцессор процессор даёт единичный сбой из-за действия космического излучения. Процессоры мейнфреймов имеют параллельно работающие функциональные блоки для устранения таких ошибок, x86 нет.
    
    Ошибка может произойти во вводе-выводе, даже с учётом контрольных сумм. Я думаю, каждый имеет опыт чтения мусора с диска. Даже с raid это принципиально возможно в ряде сценариев.
    
    bazanovv
    09.07.2025 15:41
    #28555036
    Да, понятно что FT будет стоить вычислительных ресурсов, именно поэтому исходно было ограничение максимум одно ядро процессора. Но не уверен, что настолько больших - код всё таки выполняется процессорами детерминированно, и при том же состоянии памяти и регистров в общем случае два одинаковых процессора дадут одинаковый результат даже без синхронизации. Тонкости начинаются, когда есть обмен с внешним миром и ввод-вывод, как именно это у VMware сделано не знаю, знаю только что теневая ВМ полностью изолирована от сети. Соответственно тратить много ресурсов на проверку её живости не нужно - при её потере мы теряем только резерв, это можно пережить. В том, что это похоже на Parallel Sysplex видимо соглашусь - я про мейнфреймы не знаю, но по описанию действительно похоже. А вот то, что ошибка приложения или синий экран смерти на основном экземпляре ВМ ровно в таком же виде оттранслируется на теневую, я совершенно уверен, это и логично, и в документации где-то написано. FT - это именно защита от аппаратных сбоев, и ничего больше. Поэтому кластера, контейнеры и т.п. и используются гораздо чаще - они и от сбоев железа, и от сбоев софта лучше защищают. Вся эта ветка началась с возможности обработки отказа CPU, что, конечно, явление фатальное - но, к счастью, довольно редкое :)
    
    zVlad909 Автор
    09.07.2025 15:41
    #28555268
    В том, что это похоже на Parallel Sysplex видимо соглашусь - я про мейнфреймы не знаю, но по описанию действительно похоже.
    
    К сожалению совсем не похоже. В Sysplex нет никаких теневых образов, все системы в Sysplex выполняют полезную работу, каждый свою и ничего не синхронизируется.
    
    Похожесть ограничивается только тем что когда одна из систем выходит из Sysplex (не обязательно из-за сбоя, а например для обслуживания) в целом оставки работы не происходит и никаие приложения не "падают".
    
    Вся эта ветка началась с возможности обработки отказа CPU, что, конечно, явление фатальное - но, к счастью, довольно редкое
    
    На МФ отказ CPU не является фатальным. Программа попавшая под сбой CPU выполняется другим CPU, отказавший CPU заменяется запасным. Программа повторяется с того месте где произошел сбой. Явление конечно редкое, но не невозможное.
    
    checkpoint
    09.07.2025 15:41
    #28555226
    Так в том и суть vSphere Fault Tolerance, что она сохраняет работоспособность ВМ именно в таком случае - за счёт того, что ровно те же вычисления с такой же памятью и состоянием регистров выполняются на "теневой" копии ВМ на втором гипервизоре, а поведение процессора детерминировано. Там, где что-то не детерминировано или может рассинхронизироваться, нужные данные подтягиваются в теневую ВМ по сети (минимум 10 Гбит), при необходимости основная или теневая ВМ чуть притормаживается до синхронизации.
    
    AFAIK, ничего там не исполняется на "теневом процессоре". Гипервизор делает регулярные снепшоты памяти. В случае аварии, сдохший СPU выводится из оборота, а подверженные воздействию сбоя виртуальные машины откатываются на ближайший снепшот. Аналогичный алгоритм с данными - регулярные снепшоты файловой системы (ZFS позволяет) синхронизированные по времени со снепшотами памяти. Но как вся эта кухня должна работать в составе более крупной системы и при это не рассинхронизироватья (ведь еще есть клиенты, которые могут и не знать о сбое), мне честно говоря не понятно. :)
    
    zVlad909 Автор
    09.07.2025 15:41
    #28553884
    VMware Fault Tolerance (FT) is a vSphere feature that provides continuous availability for virtual machines by creating a live, synchronized replica on a separate host.
    
    В случае МФ и zOS это называется Parallel Sysplex. Это когда до 32 экземпляров zOS работают как одно целое и в случае аварии любого экземпляра оставшиеся подхватывают и продолжная работу упавшего. 1990 год.
    
    SIISII
    09.07.2025 15:41
    #28553918
    Если аж 1990-й, то это ещё не z/OS -- до неё ещё 10 лет. Получается, уже на машинах ESA/390 сделали (а может, и на поздних ESA/370).
    
    zVlad909 Автор
    09.07.2025 15:41
    #28554530
    zOS, как Вам известно, это во первых 64-бит адресация и ребрандинг для новой мэйнфрэйм архитектуры начала 2000-х - z Architecture. Начиная с OS/390 изменение названия с MVS отражает лишь добавление Unix(USS) к MVS. MVS и все его возможности оставались и развивались наряду с USS. Документация по OS/390 и zOS всегда содержала и содержит раздел MVS и раздел USS, плюс все фасилитис в своих разднлах.
    
    Из википедии:
    
    In computing, a Parallel Sysplex is a cluster of IBM mainframes acting together as a single system image with z/OS. Used for disaster recovery, Parallel Sysplex combines data sharing and parallel computing to allow a cluster of up to 32 systems to share a workload for high performance and high availability.
    
    Sysplex
    
    In 1990, IBM mainframe computers introduced the concept of a Systems Complex, commonly called a Sysplex, with MVS/ESA SPV4.1. This allows authorized components in up to eight logical partitions (LPARs) to communicate and cooperate with each other using the XCF protocol.
    
    SIISII
    09.07.2025 15:41
    #28552548
    Как правильно отметили, вопрос именно в сохранении работоспособности программы, которая пострадала при отказе техники. Мэйнфрейм (аппаратура + программная поддержка в ОС) очень часто способен продолжить её выполнение -- когда прямо с точки сбоя, когда с некоторой контрольной точки, которая была чуть раньше.
1. zVlad909 Автор
  09.07.2025 15:41
  #28551482
  Спасибо за комментарий. Я ценю любые мнения.
  
  Мне не кажется что статья только о безопасности хотя это довольно важный аспект любой ОС и zOS в этом смысле имеет механизмы просто отсутствующие в других, "современных" (в ковычках потому что текущая версия zOS - 3.2 - анносирована три с небольшим месяца назад) системах.
  
  К моему сожалению Вы неправильно поняли про "перезапуск программы" в статье (кстати этот фрагмент есть отредактированный перевод из англоговорящего сегмента Википедии из статьи про MVS). Вот как это написано в оригиналеЖ
  
  Each recovery routine made the 'mainline' function reinvokable, captured error diagnostic data sufficient to debug the causing problem, and either 'retried' (reinvoke the mainline) or 'percolated' (escalated error processing to the next recovery routine in the hierarchy).
  
  На практике это проявляется следущим образом. Вы выполняете программу в DB2 (или в другой среде под zOS). Ваша программа завершается с ошибкой. Это не синтаксис SQL, это глубже. Это например закончилась память на диске. У вас будет диагностика от DB2, на уровне DB2, и будет диагностика от zOS, причем от zOS возможно на разных уровнях: DFSMS, супервизор ввода-вывода, или от секьюрити если это была ошибка доступа к ресурсу без права доступа с аккаунтом под которым выполняется программа. Конечно ни DB2, ни zOS при этом не рухнет.
  
  Иными словами это даже не столько процесс восстановления проблемного процесса с надеждой что повтор обойдет ошибку (далеко не все процессы могут восставливаться их повторением), но сбор диагностики для оперативного устранения исходной проблемы.
  
  Я достаточно много работал и с Линукс и с Виндовз, и сейчас работаю (у меня есть сервера Линукс и Виндовз где выполняются установленные мною программы (IBM InfoSphere Data Replication) и у меня есть админ доступ к ним) и я достаточно видел ситуаций когда что-то проходит неуспешно и трудно или невозможно или сложно докапаться до исходного события из-за которого эта неуспешность происходит. В zOS все гораздо прозрачнее, а значит нужно гораздо меньше усилий и знаний/опыта персонала для траблшутинга.
  
  Мне приходилось разбираться с проблемами приложений общего назначения и не только в zOS про которые у меня не было никакого представления что это и как оно устроено. Пользуясь описанными выше особенности zOS я довольно быстро доходил до решения проблемы и устранял ее. Это еще работает потому что в отличии от приложений в Линукс Виндовз где каждое значимое приложение создает свои службы всего что хватает куражу делать (пример Оракл) в zOS есть базовые службы (Facilties) которыми многие приложения предпочитают пользоваться не выдумывая свое, которое изначально будут хуже чем стандартные. Примеры: DFSMS (cм. выше в статье), RACF (Resource Access Control Facility), CAF (Cryptographic Facility), и т.д. Многое из этого в Линуксах и Виндовзах реализуется дополнительными пакетами и их легион, а в zOS есть свой стандартный и высококачественно реализованный набор. Что значительно упрощает работу в zOS. Наконец в zOS есть полноценный Unix и даже некоторые компоненты zOS (например TCP/IP и приложения TCP/IP) выполняются не в MVS, а в Unix System Services.

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

Т.е. паники в unixе или bug-checks (синие экраны) в винде вы не увидели.

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

Просто потому что одинаковый термин означает разные вещи. Процесс в MVT скорее похож на cgroup в Linux, или на job в windows.

zOS невероятно старая и дремучая. У меня есть теория, почему IBM гадит Hercules (это sw эмулятор железа, умеет запускать старые версии OS/370). Я считаю, что они таким образом прячут это безобразие от публики, пытаясь поддерживать репутацию чего-то большого и недосягаемого. А так, если иметь с ним опыт, и сравнить с любой современной системой - гуано.
1. SIISII
  09.07.2025 15:41
  #28551300
  z/OS просто не может быть "невероятно старой" -- для перехода на 64 разряда все собственно системные вещи пришлось переписать по, надеюсь, очевидным причинам. Это OS/360 невероятно старая -- но таки да, написанные под неё программы могут выполняться в z/OS без каких-либо изменений.
  
  И, кстати, в MVT процессов не было. Были задания, задачи, подзадачи, были разделы памяти -- но не процессы.
  
  А ещё кстати -- OS/370 в природе не существует. А Геркулес умеет запускать хоть древние системы, хоть современные.
  1. zVlad909 Автор
    09.07.2025 15:41
    #28555236
    Я бы сказал не переписать, а дописать.
    
    Как известно до 64-битности адрессное простояло из двух зон зона 24-бит адресации (below the line, 16 MB), зона 31-битной адресации (это не опечатка, именно 31 битная below the bar, 2GB). С 64-бит адресацией появилась область above the bar.
    
    В каждой из этих зон размещались области для личных данных и программ, области и программы системы. Программы могут быть оттранслированы с режимами AMODE16, AMODE31, and AMODE64. Другими словами далеко не все программы переписывались в одну 64-бит адресацию. И это понятно,потому что издержки на dynamic address translation (DAT) тем медленнее чем выше разрядность т.е. ниже производительность.
    
    SIISII
    09.07.2025 15:41
    #28556136
    Прикладные программы переписывать не требуется, там, насколько мне известно, 100% переносимость (и какой-нибудь прикладной код из 1965-го будет без изменений работать и сейчас), а вот ядро системы (супервизор, грубо говоря) -- необходимо, ведь именно оно обеспечивает возможность работы на 64 битах, оно должно поддерживать новые возможности управления адресными пространствами и т.д. и т.п.
    
    И, кстати, AMODE -- не 16, а 24, описка-с :)
    
    zVlad909 Автор
    09.07.2025 15:41
    #28558012
    Да. описка. 16 МБ, но 24 разряда адресация. Это в микропрцессорах было 8, 16, 32, 64.
    
    Как я понимаю (не писатель ядер z/OS) ядро системы тоже состоит из програм в каждой из трех зон: 24, 31, 64 (кстати знаете почему 31, а не 32? Думаю что знаете поэтому ответ "да" достаточен). Более того полагаю (можно уточнить) что большенство програм ядра как раз таки остаются в зоне below the line (16 МБ). По причине производительности. Давно это было когда все это разяснялось на курсах в ИБМ. Всего не упомнишь и конспекты уже давно выброшены.
1. zVlad909 Автор
  09.07.2025 15:41
  #28551440
  Синии экраны конечно видел. Поэтому и назвал то как обрабатываются такие ситуации в zOS одним из главных отличий. Паники в zOS не бывает.
  
  Просто потому что одинаковый термин означает разные вещи. Процесс в MVT скорее похож на cgroup в Linux, или на job в windows.
  
  MVT это не MVS. Может вы опечатались имея в видутаки MVS, но тем не менее просто процесс это далеко не все что различается в zOS для работы WLM и других конечно целей. Например, в DB2 есть "threads" и "enclaves" (последние есть также в WebSphere). WLM различает их и может назначать им квалифицированные сервис классы.
  
  Дело не терминалогии как таковой а в ее развитости и поддержке. В zOS поддерживается много больше признаков приложений и даже их внутренних компонет для целей менеджмента чем в любой другой известной системе.
  
  Текущая версия zOS 3.2 анносирована 8 апреля 2025 года. Это современнейшааяся система для бэкэнда со всеми возможностями, протоколами, языками и технологиями известными и значимыми.
  
  Геркулес (не мифический герой) без МФ это всего лишь иммитация связки zOS и МФ. Без собственно МФ это всего лишь эммуляция. Hercules приемлен лишь для начального обучения работе с zOS без возможности иметь доступ к настоящему МФ, что в наше время не представляет никаких трудностей. Достаточно выразить желание и назваться студентом и вы можете получить доступ к настоящему МФ. Конечно даже имея такой доступ и будучи студентом вы не осознаете всего что такое есть zOS на МФ. Для это надо поработать администратором, или как раньше говорили ситемным программистом zOS.

mikleh
09.07.2025 15:41
#28551442
z/OS и IBMовские мейнфреймы - великолепный пример того, что талантливый некромант может ехать на дохлой лошади очень долго и даже обгонять многих живых скакунов.

В то время как появление доступных микропроцессоров совершило революцию в мире электроники и позволило перейти к распределенным системам, которые по совокупности характеристик оказались лучше старых мейнфреймов, IBM приложила титанические усилия к тому, чтобы убедить мир, что их система надежна. Имел я опыт общения с z/OS. В далеком 2006, но мне кажется, там ничего принципиально не изменилось за последние 20 лет, как не менялось за предшествующие 30. Система надежная в своем роде, просто она надежно делает то, для чего ее создали. Но это точно не какие-то там ваши прикладные задачи.
1. SIISII
  09.07.2025 15:41
  #28551458
  Ну так и мэйнфреймы давным-давно уже микропроцессорные. Да и не сказать, что доступные микропроцессоры произвели какую-то революцию. Ну, вышел 8080 (первый более-менее полноценный микропроцессор), и что? Он лишь слегка подвинул мини-ЭВМ из их ниши, поскольку тягаться даже с самыми слабыми из них ему было, скажем так, проблематично. А к тому времени, как производительность микропроцессоров в достаточной степени увеличилась, мини-ЭВМ тоже превратились в микропроцессорные машины, а несколько позже то же самое сделали и мэйнфреймы.
1. zVlad909 Автор
  09.07.2025 15:41
  #28551498
  Спасибо за мнение. Я уважаю все мнения.
  
  Позвольте спросить чем Вы занимались в zOS в 2006 году? Не подумайте что это наезд, мне действительно хочется как люди имевшие контакт с этой тематикой приходят к такими выводам и заключениям как представили Вы.
  
  Тех кто серьезно работает с ИБМ МФ и zOS, а их везде по миру достаточно много для таких, я бы даже не постеснялся сказать глобальных, проектов, убеждать ни в чем не надо. Они все прекрасно знают, это не секрет. Они работают и никуда уходить не собираются. Да, много ушло. Вот где я сейчас работаю уходят. Уходят с 1995 года и наконец то похоже уйдут и дадут мне уйти наконец на пенсию (мне 70).
  
  Лучше старых мэйнфрэйм это каких? В апреле ИБМ выкатил z17. Вы легко найдете информацию на z17 в сети.
  
  Да, система zOS в связке с МФ супер надежна. И это дотигается не многократным дублированием, а гораздо более интелектуально и централизованно. Распределенные система это не понацея всего, у них есть очень много издержек и недостатков. С увеличением масштаба эти издержки и недостатки многократно увеличиваются и ... увы дорожают. Инфраструктуры на МФ из года в год дешевеют и мощнеют.

Alexandro_Live
09.07.2025 15:41
#28552432
Наверное, тот кто писал статью поддерживал z13 в сфр. Знаю таких адептов любителей старины. Меня больше всего поражает интерфейс и шрифт схожим с tr-dos (zx-spectrum). Ох настольная.
1. zVlad909 Автор
  09.07.2025 15:41
  #28555046
  Во-первых, z13 не такая уж и страна, у меня два МФ: zBC12 и z14. Оба под zOS 1.13 (текущая версия 3.2, а МФ - z17, этого года.
  
  Во-вторых не поддерживал, а поддерживаю и не в сфр, а в Ontario Power Generation (opg.com).
  
  Что касамо шрифтов во-первых для бэкэнд сервера шрифт (Вы повидимому видели терминал IBM-3270, или его аналог ЕС-7920) это последнее о чем надо замарачиваться, во-вторых в настоящее время и давно существует широкий набор клиентских приложений для работы с МФ в современном GUI.
  
  Я лично работаю с МФ с эмулятора 3270 на моем лаптопе. Это лучший интерфейс для администрирования, траблшутинга, мониторинга и т.п.. Программы я тоже пишу с 3270. На языке REXX главным образом.

saipr
09.07.2025 15:41
#28552458
Спасибо за интересную статью. Она мне напомнила собственные усилия по продвижению OC Unix вместо ОС ЕС (читай OS/360) в середине 80-х прошлого столетия:

При этом я прекрасно понимал, что всё это уже вчерашний день. Читая в академии отчеты IRIA, я знал и про СУБД, и про сети и про персональные компьютеры, операционную систему Unix и язык Си. Но здесь этого ничего не было, здесь была ОС ЕС, ПЛ/1, IBM и НИЦЭВТ.
1. zVlad909 Автор
  09.07.2025 15:41
  #28555090
  Я бегло просмотрел Вашу статью и буду читать ее внимательно и вдумчиво. Я люблю и знаю историю ИТ в СССР. По книге Малиновсого, по широкому сотрудничеству с НИИЭВМ (Минск), менее широкому с НИЦЭВТ (Наумов Вячеслав Владимирович) и ПО "Восход". Я был бы счастлив работать там где Вам повезло работать, но я родился в Челябинске и этим все сказано.
  
  Да в середине 80-х мы работали с системами вчерашнего дня. Но в теже 80-е, да и в 90-е, на Западе ИБМ мэйнфрэймы были топовым выбором. В смысле производительности, надежности развитости ПО.
  
  Операционная система Unix появилась на МФ в MVS в виде MVS/ESA OpenEdition (февраль 1993), включена в OS/390 в середине 90-х под названием Unix System Services и продолжает существовать в zOS. Вовсе не потому что чего-либо не хватало в MVS, а чисто из коммерчеких соображений (привлечь клиентов SAP R3), но и для того чтобы пополнять ПО МФ приложениями Unix написанными на том же С. Сейчас, опять же с 90-х, начале 2000-х программы на Java выполняются в zOS непосредственно, под CICS и WebSphere.
  
  Т.е. надо было просто подождать и все что хотелось появится от достижений ИБМ и их МФ.
1. zVlad909 Автор
  09.07.2025 15:41
  #28555462
  Читаю Вашу статью, интересно, дочитал до публикации Вашей книги. В начале 80-х (82-83) я занимался "...практическими аспектам связи программ, написанных на разных языках Ассемблере, и ПЛ/1". Это было довольно экзотическое занятие. Обычно программисты либо на Ассемблере писали либо на Фортран, либо ПЛ/1. Разобрался самостоятельно, по каким источникам честно говоря не помню, скорее всего по документации ОС ЕС или еще каким другим источникам. Давно это было. Работал я тогда в Челябинском военном училище штурманов.
  1. saipr
    09.07.2025 15:41
    #28556236
    дочитал до публикации Вашей книги
    
    Спасибо. Да, книга есть:

alecv
09.07.2025 15:41
#28552806
Странно, что автор настолько против микросервисов, что делает странное утверждение "один выделенный сервер для одной задачи". Так может быть еще и делает какой-нибудь мелко-средний бизнес в своем частном ЦОД и на стареньких серверах. А нормальный тяжелый продакшн давно на кластере кубер (или там vSphere/HA) и сервера загружаются равномерно. Более того, с учетом производительности процессоров/дисков и географической близости к клиентам.
1. hogstaberg
  09.07.2025 15:41
  #28554126
  И даже хуже - на последних ядрах усиленно пилится возможность свой кастомный шедулер на ebpf организовать
1. zVlad909 Автор
  09.07.2025 15:41
  #28554824
  Я в курсе микросервисов, но статья их вообще не касается. Да я мог написать "один выделенный сервер для одного сервиса", или по другому "один сервер под один сервис", имеяч в виду например БД на выделеном сервере, несколько экземпляров WebServer каждый на отдельно сервере с лоадбаленсером во главе. AD много экземпляров на отделеьны, выделеных сервер не важно on-prem или в облаке.
  
  В противоположность этому хорошая манера и правило сочедать в одном zOS много разных серверов все вместе. Это хорошая пища для пищеварения WLM и для более эффективного использования, да не дешевых, но ресурсов МФ, который постоянно дешевеют и в целом могут запросто оказаться дешевле ИТ инфраструктуры на тысячах серверах и особенно в облаках. Кстати в компании где я работаю это уже отмечается.

Yami-no-Ryuu
09.07.2025 15:41
#28554968
Провокационный и странный заголовок. А не x86? ARM64, RISC-V, там какие-то другие ОС или не считается? А Линукс считается? А с оркестратором контейнеров на NUMA железе?
1. zVlad909 Автор
  09.07.2025 15:41
  #28555276
  Я не стал перечислять все варианты процессоров (я всех их и не знаю, знаю только что они есть), на которых может выполняться Линукс, Вмндовз и другие подобные системы. Все они по сравнению с МФ одинаковы.
  
  А что действительно с ".. оркестратором контейнеров на NUMA железе "? Поясните, пожалуйста.

Чем различаются ОС IBM мейнфрейм и ОС х86 +34

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

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

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

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

Workload Manager (WLM)

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

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

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

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

Комментарии (109)

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор

zVlad909 Автор