Комментарии 138
Ну WLM очень хорошо управляется ресурсами, но в х86 мире за те же деньги можно купить в 10-100 раз больше железа по мощности и просто не заморачиваться
Есть нюансы. Во-первых, выполнение некоего тяжёлого приложения на единой машине с 100500 процессоров и гигантским объёмом ОЗУ, в общем и целом, эффективнее, чем работа на 100500 хилых машинах со связью по локальной сети. Во-вторых, вопросы надёжности и восстановления после сбоев: с IBM тут тягаться тяжело, всё ж они на этой теме были зациклены ещё с 1960-х годов. Ну а в-третьих, в эксплуатации один мэйнфрейм может оказаться дешевле, чем куча обычных серверов.
Но, понятно, все эти вопросы дискуссионные, и в разных ситуациях можно получить разные результаты.
Ну такое, как выше сказали на эти же деньги можно купить во много раз больше железа, сделать FT для критических процессов и соединить чем ни будь типа 400G InfiniBand
Спасибо за комментарий. Но достоверности для надо сказать что не с 60-х годов ИБМ "зациклился" на надежности, а с началом и в процессе разработки MVS. Это 70-е годы. Желаемый уровень был достигнуть существенно позже. Это очень трудоемкая работа и много кода.
Тут Вы ошибаетесь. И средства обработки аппаратных ошибок были с самого начала заложены в аппаратуру, и программная обработка и, по мере возможности, восстановление были предусмотрены ещё в MFT/MVT -- естественно, на тех моделях, которые позволяли это сделать. В частности, сбой (не полный отказ, а именно сбой) процессора или блока памяти при наличии MCH (он мог присутствовать для некоторых моделей Системы 360 и был обязателен для любых моделей Системы 370) во время выполнения прикладной задачи приводил к аварийному завершению этой задачи, а не системы в целом; всё остальное продолжало работать -- ну а сбойнувшая задача при определённых условиях могла быть перезапущена с контрольной точки. Макрокоманда STAE тоже была предусмотрена с самого начала. В MVS очень сильно расширяли расширили и дополнили уже имевшиеся механизмы и, в конце концов, довели их до ума, но сказать, что только в ней начали, будет некорректно.
Все верно Вы говорите. Полностью с Вами согласен. Сам начинал с OS/360 и именно как системный программист генерирующий системы. Все что Вы перечислили было и в OS/360 (ОС ЕС), но то что я дал в цитате из Википедии про требования к MVS начали внедрятся именно в MVS и это взяло немало лет.
MVS в СССР очень не сильно был распространен. ВЦ ЖД с ним работало И больше я не знаю кто. Да, еще в НИЭВМ был студент которому дали разобраться с MVS и он достиг больших успехов в чтении дампов. Ну и конечно НИЦЭВТ.
Спасибо за комментарий.
Стандартный, ожидаемый ответ. Много раз слышал такой на мои выступления на эту тему в других местах. Могу согласиться что "..за те же деньги купить в 10-100 раз больше железа по мощности" (хотя вряд ли даже в 10, и точно не в 100), но посмею утверждать что загрузить эти мощности на 100% не получится. А в случае с МФ, zOS и WLM нормальным является потоянная загрузка на 100%.
Кроме того имейте в виду что сравнение по мощности МФ с х86 далеко не тривиальное дело и это не сранение количеств CPU, тактовых частот и размера оперативной памяти (RAM).
C интересом ознакомлюсь с Вашими источниками по этому вопросу.
Вот отсюда поподробнее. Чисто пальцем в небо для неспециалиста.
Как можно сравнить мощности МФ и обычного сервера? Условно говоря, нам удалось подобрать конфигурации, когда у обычного x86 и МФ одинаковое число ядер(потоков, учитывая hyper-t) и оперативной памяти. Давайте рассмотрим производительность в таком случае.
Это очень нетривиальный вопрос. В недалеком прошлом (лет 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 можно будет разместить на МФ десятки.
Железо железу рознь. Насколько я слышал от людей, которые реально занимаются мэнфреймами, основная фишка там -- производительность I/O. Архитектура PC никогда не затачивалась на такое количество запросов в секунду, какое легко выдерживает мэнфрейм, отчего проваливаются многие попытки мигрировать с мэнфреймов на более дешевые решения.
Производительность I/O это действительно фишка. Все дело в том что ввод-вывод на Мф реально автономен и не использует ресурс CPU от слова совсем. Каналы ввода-вывода это по сути компьтеры в компьтере. И когда например говорится zOS выполняется на 4 CPU, то надо иметь в виду что на самом деле процессоров в нем больше и они добавляют производительность.
Но есть и другие фишки. Например аппаратная реализация сжатия данных и кодирование, теперь еще и поддержка AI начиная с z16. На х86 тоже есть такие платы, но они опциональны и это деньги. В МФ это стандартно включено. И это еще не все.
Но самая главная фишка это симбиоз МФ с ОС zOS.
Верно ли я понял из текста, что ещё и встроенное "версионирование" — тоже часть системы работы с файлами?
Группы поколений данных? Да, но, как по мне, оно не шибко удобно, хотя вполне себе работает. Но учитывая, что OS/360, похоже, была вообще первой "настоящей большой ОС" в истории (а современная MVS тянет совместимость с ней), трудно было всё сделать и правильно, и удобно :)
Группы поколений данных используются широко и не только в угоду совметимости с древними подходами. Интересно что Вы понимате под "сделать и правильно и удобно".
Пример использования группы поколений данных (один из многих). Я должен представлять в ИБМ отчет об использовании МФ ежемесячно. Для этого надо выполнять два задания. Одно ежедневно и одно ежемесячно. Ежедневное собирает данные за прошедший день и сохраняет их в файле. Ежемесячное берет всю совокупность ежедневных файлов за месяц и делает месячный отчет.
Это автоматизировано мной так что 2 числа каждого месяца мне приходит e-mail (из МФ) с приатаченым .csv файлом, который я аплодаю на соответствующий ИБМ портал.
Модифицировать вышеназванные задание мне не надо. Чистить предыдущие, ненужные уже ежедневные файлы мне тоже не нужно и их не бывает больше чем 33. Также и месячных, которых не бывает больше 15.
Сделано это все на группах поколений. Предложите более правильный и удобный подход с такими же свойствами и не на группах генераций о которых мы говорим. Спасибо.
Верно ли я понял из текста, что ещё и встроенное "версионирование" — тоже часть системы работы с файлами?
Если Вы относительно групп поколений (Generation Group) как выше предположил SIISII, то как бы да, но это не всех файлов касается, а только тех что объявлены входящими в группу. Т.е. не все файлы под этот механизм подпадает, но и более того поколения (generation) это не версии (version). Я понимаю о чем Вы говорите и ответ будет нет, встроенного версионирования нет.
В каждом поколении файлы всегда разные и откат на них, как это предполагает версионирование, не имеет никакого смысла.
Тем не менее на МФ есть продукты и весьма развитые с механизмами версионирования. Мы ставили его на наш МФ для разработчиков. IBM Rational и не только для МФ.
IBM Rational is a suite of software development tools. Key products within the Rational family include Rational Application Developer, Rational Software Architect, Rational DOORS Next Generation, and Rational Functional Tester
И производительность, и прямизна архитектуры в целом и архитектуры ввода-вывода в частности -- именно благодаря этому мэйнфреймы прекрасно виртуализируются, ну а по-настоящему качественных виртуализаций ПК не существует и вряд ли будет существовать (имеющиеся гипервизоры виртуализируют некоторое подмножество, достаточное для исполнения Винды/Линуха, но далеко не всегда способные работать с чем-то нестандартным; мэйнфреймы изначально виртуализировались абсолютно полностью, поэтому на виртуальной машине можно было творить ту же дичь с вводом-выводом, что и на реальном железе -- и всё работало).
На МФ, в виртуальной машине под, уже c VM/370, можно было загрузить ..... VM/370, более того в виртуальной машине под VM/370 на виртуальной машине можно снова загрузить VM/370.
Идет это и с того как устроен ввод-вывод (каналы) и как разеделены режимы супервизора и прикладных программ. Четко разделены. Их всего два в отличии от х86 где их помнится пять. В первых версиях VMWare на тогдашних х86 просматривал выполняемый код на ВМ чтобы вылавить некоторые команды. В последующих х86 эта проблема решалась, но как мне помнится не до конца всеже. Что сейчас с этим я не в курсе. Может кто в курсе расскажет? Или укажет на источник.
Разумеется. Поэтому суперкомпьютеры строят на железе от Intel и AMD, а не от IBM. zEnterprise покупают те компании, у которых инфраструктура исторически сложилась из мейнфреймов с дремучих годов. Интересно, как часто компании выбирают построить свою инфраструктуру на продукции IBM с нуля? Подозреваю, весьма не часто.
Во-первых, это, скорей, не суперкомпьютеры, а кластеры обычных компьютеров: физически там множество компьютеров, каждый под управлением своей собственной ОС и т.д. и т.п.
А во-вторых, на железе от Интел их не строят никогда -- их строят на железе и Невидии, и именно её ГПУ выполняют всю "суперкомпьютерную" обработку, а кто скармливает им работу, абсолютно неважно.
Но таки да, на мэйнфреймах суперкомпьютеры-числодробилки не строят -- они под другие задачи заточены.
На GPU далеко не все алгоритмы ложатся, увы. Они только для очень специфичных задач.
на железе от Интел их не строят никогда
Ну зачем же вводить в заблуждение? Как по-Вашему, выглядели суперкомпьютеры, когда видеокарты были нужны только для обработки видеоинформации? И да, до сих пор очень и очень много алгоритмов плохо портируются на GPGPU.
Да, про это не знал. Хотя использовать для этого интелы (точней, интеловскую архитектуру) -- такое себе, из-за её крайней ублюдочности, что влечёт огромный расход энергии на единицу работы. Думается, под такую задачу лучше подошёл бы почти любой (псевдо)РИСК -- ARM, MIPS, RISC-V... Правда, в те годы, наверное, китайцы ничего лучше не нашли (ну или иные причины были, не технического характера).
Ну а как выглядели... Крэй, например -- думаю, слыхали про такой. В первом приближении -- та же видюха, но без узлов, специфичных для графики (т.е. матричный процессор в более-менее чистом виде).
А что не просто много, а, пожалуй, основная масса алгоритмов толком не параллелится, я в курсе.
Мне думается у ИБМ МФ еще будет ренесанс. Уж больно это, облака и клатеры на х86, напоминает мыльный пузырь. В нашей не маленькой, но и не большой компании сервера в Azure and on-prem исчисляются тысячами. От верхнего руководства идут сигналы про "че то дорого это ИТ, нельзя ли подешевле". Ищут и легко находят сервера без хозяина, почти простаивающие все время, сервера с пустыми дисками (кстати в Azure скорость I/O зависит от размера диска, хочешь хорошую скорость бери, надо не надо, больше диски). Было даже так что поступил запрос на новый сервер в то время как он уже существовал и работал в продакшн. Чувак преодолел все препоны и предупреждения и засунул это сервер (пустой пока) в домэйн , а тот что был из домэйна выпал и сервис пропал (это был WiFi). Все кто сидел на WiFi отвалились.
Рано или поздно все это рухнеи как карточный домик и взгляды снова обратяться к ИБМ МФ.
Да IBM и не загибается. Она даже не чувствует себя больной. Просто, в отличие от безапелляционно восхищенного тона статьи - мол, эти ваши x86 фигня, а вот мейнфреймы IBM - это настоящие серьезные компьютеры, мир так не считает. Большинство компаний, имея бюджеты на IT-инфраструктуру, позволяющие им затариться zEnterprise по самую макушку, всё равно этого не делают, а предпочитают решения на x86 или arm. Посмотрите, на каком железе гиганты индустрии строят свои датацентры. zEnterprise в таких новостях не упоминается ни разу. zEnterprise - это решение для тех, кто уже плотно сидит на предыдущих поколениях мейнфреймов от IBM. Остальные в сторону IBM смотрят редко. Если кто и строит свою IT-инфраструктуру с нуля на zEnterprise - это единичные случаи. Раз в 10 лет :)
Но, повторю, IBM клиентов хватает, линейка zEnterprise развивается и загибаться не планирует. Просто она не на 100500 голов выше решений на x86, как поется в статье, она просто другая.
Ну, и, разумеется, мне, обитателю условного кишлака из условного Афганистана нет большого смысла рассуждать о преимуществах и недостатках мейнфреймов IBM. Тем более, с канадцем. Мы с вами в разных мирах живем.
Спасибо за комментарий. Я уважаю все мнения. Но где у меня в статье такое есть (восхищение, фигня):
Просто, в отличие от безапелляционно восхищенного тона статьи - мол, эти ваши x86 фигня, ......
Я сам по себе давно не интересуюсь информацией о том как идут дела у ИБМ с их МФ Z. Когда интересовался лет 10 назад то видел десятки примеров захода на ИБМ Z, уходов и возвращений. Последние годе я лишь отмечаю появление новых семейств ИБМ Z и новых версий z/OS и понимаю что все Ок. А раз все Ок после стольких лет (начиная с 1995 в котором одним болтуном журналистом, которого читали, было предсказано отключение последнего МФ) ИБМ Z остается актуален значит в нем действительно есть что-то особенное. Вот про это особенное я и пишу без всяких "фигня" и "восхищение".
Но, повторю, IBM клиентов хватает, линейка zEnterprise развивается и загибаться не планирует. Просто она не на 100500 голов выше решений на x86, как поется в статье, она просто другая.
Вы постоянно называете МФ zEnterprise. Позволю себе пояснить другим читателям кто не в курсе что zEnterprise это гетерогенная архитектура соединяющая Z c блэйд-серверами на х86 (ранее также RISC) под управлением Виндовз и Линукс, и под общим управлением z/OS на Z.
Для тех задач и приложений, в которых одновременно позиционируется и Z и инфраструктуры на х86, начиная с некоторого размера (лаптопам в киосках на рынке с 1C или Excel Z не конкурент), а имеено бизнес приложения для реальных бизнесов (а не поисковых систем, помогающих искать непонятно что не понятно где и находящих всегда бесконечное множество чего угодно, нужного и совсем не нужно, а также социальных сетей и месенджеров, список можно продолжить в этом направлении), банки, страховые копании, пенсионные фонды, госучереждения, медицина в рамках стран и вообще все что касается реальных людей и их реальными ситуациями по деньгам, здоровью, рождению, жизнью, наследованию и смертью, список тоже можно продолжать в этом направлении, да Z не просто другой а особый подход и речь идет не про фронтэнды, а бэкэнды, централизованные базы и детерминированные (а не стахостические) бизнес транзакции и логику. На фронэндах, в презентэйшн лэйере конечно же х86 не Z.
Ну, и, разумеется, мне, обитателю условного кишлака из условного Афганистана нет большого смысла рассуждать о преимуществах и недостатках мейнфреймов IBM. Тем более, с канадцем. Мы с вами в разных мирах живем.
Мы живем в одном мире. Не надо приумалять себя что пнуть другого было удобно. Да, к несчастью я оказался в канаде и провел здесь 26 лет. Потому что к концу 90-х такие как я оказались совершенно не у дел и чтобы не мешать другим покинули Россию 90-х, освободили и передали наши квартиры, рабочие места, места в детских садах и школах наших детей, оказались от социальной поддержки, простились с могилами предков и уехали туда где вроде бы, говорят, наши знания и опыт затребованы. Но рабочих мест не гарантируют. Плюс язык. И мы очертя голову, перекрестившись, прыгнули в омут неизвестности. Выплыли, отряхнулись испили чашу иммигрантов до дна и в итоге прижились. Вот и вся разница между кишлаком у себя на родине и жизнью почти как в плену у победителей. Особенно это тяжело сейчас, во времена СВО. Вам это не понять. Но всему есть конец. Мой сын уже в России с 2020 года. Я скоро выхожу на пенсию и собираюсь возвращаться. Появление меня здесь на Хабр-е с эти и связано. А вовсе не с тем чтобы восхвалять z/OS, которым я естественно восхищен, зная неплохо и работав и с Виндовз не только как пользователь, и с Линукс как инсталятор и администратор на МФ, а также как инсталятор и администратор WebSphere на Linux, и тоже с IBM InfoSphere Data Replication, которую не на МФ инсталирую и администрирую в реальном времени. Установленные мною элементы IIDR работают на Линукс и на Виндовз серверах, и у меня уроень admin на этих серверах. Я на on-call 24х7х365 потому что в продакшн. Вопросы?
Из своего опыта работы с Видовсами, Линуксами, OS/2 в том числе, я могу утверждать, что ничего подобного ни в одной другой системе, включая мейнфреймовские, я не видел.
Не дотягивают, убогие.
Нет, конечно, можно прицепить огромное хранилище к одному Линуксу и свалить туда все файлы в кучу по разным папкам. Можно и два, и три и т. д. хранилища подключить. Но уже ближе к десятку это превратится в большой головняк.
То есть, если я подключу хранилище из 100500 дисков общей вместимостью до-его-ард байт к x86 системе, то я получу головняк. А если тот же до-его-ард я подключу к машине с z/OS, то головняка не будет. Хотя и там до-его-ард, и там. Но, видимо, при подключении к z/OS каждый байт приобретает кошерность. А у всех суперкомпьютеров на x86 (а других-то и нет) вечная мигрень из-за отсутствия кошерности.
Как‑то с этим борются в облаках. Но сервер на х86 остается сервером х86, Windows — Windows‑ом, а Unix — Unix‑ом.
А z/OS не остается z/OS? Она является всем сразу? Запускаешь в ней прогу, то есть, я хотел сказать, задачу, и задача может одновременно использовать системные вызовы unix, API Windows и всё это делать как x86, как arm и, разумеется, как PowerPC, жонглируя вызовами, как пьяный фокусник.
В тоже время инфраструктуры на х86 не имеют иного способа строить инфраструктуры для крупных приложений, кроме как распределяя нагрузки и кластеризуя ресурсы многих серверов. При этом практически полностью теряется возможность оптимизации использования ресурсов и управления их использованием. Другими словами, инфраструктуры на х86 получаются такими, какими они получаются.
Ущербными, надо полагать.
Но если вы говорите, что
Но где у меня в статье такое есть (восхищение, фигня)...
Вот про это особенное я и пишу без всяких "фигня" и "восхищение".
то на нет и суда нет.
Но это я так, просто размышляю в слух. Сам-то я никогда не видел и не увижу ни одного компа, дороже тыщи баксов. В моем кишлаке высшим достижением инженерной мысли является ишак.
Вы постоянно называете МФ zEnterprise.
Был неточен, поправляюсь. Я имею в виду современные поколения мейнфреймов IBM, начиная от z900 и заканчивая z17. Я просто по памяти выбрал для них такое общее название.
Мы живем в одном мире.
Это с некоторыми москвичами вы живете в одном мире. Это с посетителями Хабра вы живете в одном мире, которые тоже все из Штатов, Канады, и прочих мест цивилизованного мира. А я здесь один случайно затесавшийся житель России. Иногда что-то пописываю, как видите. Являю собой, так сказать, глас средневековья в вашем междусобойчике богатых и успешных.
Потому что к концу 90-х такие как я оказались совершенно не у дел и чтобы не мешать другим покинули Россию 90-х,
Поймите меня правильно, я не пытаюсь вас пнуть. Вы всё правильно сделали. Вы поставили себе цель, много работали, и добились желаемого. Вас можно только похвалить. Но я уже не одно десятилетие в рунете пописываю, и понял одно: богатые и успешные демонстративно не замечают остальных. Тех, кто не смог добиться всего того, что добились они. А так как я являюсь представителем последних, я стараюсь не упускать возможности напоминать богатым и успешным, что мы тоже существуем. Не все мы еще вымерли. Разумеется, это ничего не изменит, ну и ладно. Мне пару строчек написать никогда не влом.
Вам это не понять.
Уж куда мне, средневековому крестьянину из жопы мира понять белого человека.
О чем я и говорю: мы с вами в разных мирах живем.
То есть, если я подключу хранилище из 100500 дисков общей вместимостью до-его-ард байт к x86 системе, то я получу головняк. А если тот же до-его-ард я подключу к машине с z/OS, то головняка не будет. Хотя и там до-его-ард, и там.
Я рассказывал про DFSMS в Z/OS. Это фасилити помогающая прикладным програмам управляться в их большими данными. Под прикладными програмами я понимаю в том числе такую как DB2 for z/OS. В Линуксе как таковом ничего подобного нет. Оракл в Линуксе управляет своей памятью на дисках сам, и все другим подобные приложения имеют свое решение для управления большими данными.
А z/OS не остается z/OS? Она является всем сразу? Запускаешь в ней прогу, то есть, я хотел сказать, задачу, и задача может одновременно использовать системные вызовы unix, .....
Да, и системные вызовы Unix тоже. Но это если ваша програма пришла из Unix. А вообще можно написать любое приложения бэкэнда (я подчеркиваю это чтобы мне не говорили, мол, а игру не сможешь) пользуясь только возможностями z/OS. z/OS в его стандартной поставке имеет гораздо больше возможностей (facilities) чем тоже в виде Виндовз и Линукс. И все приложения расширения возмоностей (DB2, CICS, WebSphere....) активно используют эти z/OS-ские не изобретая каждый раз свои, например, системы секьюрити, управления опять же дисками и т.д. кластеризацией той же.
... это делать как x86, как arm и, разумеется, как PowerPC, ....
А что такого делают перечисленные процессоры что по Вашему процессору МФ не дано делать? Я полагаю то что Вы скажете в ответ процессор МФ делал задолго до появления х86, arm и, о горе, PowerPC.
Был неточен, поправляюсь. Я имею в виду современные поколения мейнфреймов IBM, начиная от z900 и заканчивая z17. Я просто по памяти выбрал для них такое общее название.
Да нет можно и zEnterprise говорить. Это вполне современное название. Просто говоря о МФ не правильно будет включать блэйдсервера на х86 входящих в zEnterprise. Можно просто говорить Z. Кратко и понятно. И не перепутаешь с "i".
Это с некоторыми москвичами вы живете в одном мире. Это с посетителями Хабра вы живете в одном мире, которые тоже все из Штатов, Канады, и прочих мест цивилизованного мира. А я здесь один случайно затесавшийся житель России. Иногда что-то пописываю, как видите. Являю собой, так сказать, глас средневековья в вашем междусобойчике богатых и успешных.
Я пришел на Хабр именно чтобы общаться с специалистами ИТ в России. До этого я много общался на форуме Привет, где да в основном были США и Канада. Не надо самоуничижаться, Россия великая страна и будет еще править миром. Да Вы и не один здесь россиянин из России. Я тоже россиянин, из Челябинска, живу в Канаде, но это временно.
Но я уже не одно десятилетие в рунете пописываю, и понял одно: богатые и успешные демонстративно не замечают остальных. Тех, кто не смог добиться всего того, что добились они. А так как я являюсь представителем последних, я стараюсь не упускать возможности напоминать богатым и успешным, что мы тоже существуем.
Я не считаю себя, да и не являюсь, каким то богатым (у меня российская пенсия всего 15000 рублей). И вовсе не по богатству сужу о собеседниках, а по их вдумчивости, спосности аргументировано спорить, отстаивать точку зрения и соглашать когда не правыми оказываются. Да не все знают о МФ. Это не секрет. Но плохо то что судят не зная, приписывают то чего нет и не слышат правду.
Уж куда мне, средневековому крестьянину из жопы мира понять белого человека.
О чем я и говорю: мы с вами в разных мирах живем.
Я совсем не это имел в виду. Я про эммиграцию говорил. Вы же не эммигрировали в другие страны надеюсь. Я бы тоже не эммигрировал, это был не мой выбор, или не по моей воле этот выбор был сделан.
Все дело в деньгах, как правильно заметил предыдущий оратор - вместо ОДНОЙ ОЧЕНЬ ДОРОГОЙ установки, для которой актуально ее максимально сбалансированное использование - в мире х86 принято набрать больше мелких серверов.
И даже не х86: как выяснилось, для некоторых задач можно использовать кучку arm-серверов, каждый из которых стоит копейки, решает одну свою задачу, и поэтому вопрос о его недозагруженности не имеет практического значения.
А в случае перегруженности - добавить еще один копеечный сервер.
Второй момент - физическое резервирование: кластер нужен не только для того, чтобы выполнять задачи быстрее чем отдельный сервер, но и для того, чтобы когда один из серверов вышел из строя (потоп, пожар, физическое уничтожение) - оставшиеся подхватили бы работу.
У одного большого мейнфрейма такой опции в принципе нет, если условно говоря он будет уничтожен - пострадают все, у кого на нем что-то работало.
То есть, тут принципиально разные пути эволюции, и чем дальше - тем больше они расходятся...
Ну, во-первых, мэйнфреймы отлично масштабируются. При нужде досыпать процессоров и памяти, как правило, проблемой не является.
Во-вторых, ничто не мешает поставить два мэйнфрейма в физически разных местах, чтобы уберечь от всяких там бедствий (точно так же, как и обычные серверы придётся ставить в разных местах).
А вот это опять деньги
Разумеется для каких-то задач это подходит, а для каких-то других больше подходит "стая мелюзги"
Поэтому и говорю что разные пути эволюции.
Конечно не везде приемлем МФ, но судя по содержимому Хабра "стаи мелюзги" используются в подавляющем применении в России. На Западе это не совсем так.
Например на чем работают Госуслуги, СФР, Сбер и другие крупные банки, ЦБ, ФСБ, МО, и т.п. организации? Подозреваю что не на МФ. Возможно в некоторых из них и были МФ (ЕС ЭВМ), но запущенный в 90-е процесс вытеснения МФ (ЕСЭВМ) в 90-е годы и потеря компетенци в этой области вытеснила их и там.
На Западе в одной и той же компании могут прекрасно сосуществовать и "стаи мелюзги", и ИБМ МФ. Особенно в банках это присутсвует. На МФ центральная БД и транзакции выполняются. На серверах фронтэнды.
Некоторые из этих организаций в России использовали IBM z до недавнего времени, но санкции США в 2022 усложнили взаимодействие с IBM, а для мейнфрейма это очень важно по причине лицензионной политики.
И что они совсем покончили с z? Я давно живу и работаю в Канаде и совсем не имею представление об z в России. Но скоро освобождаюсь и собираюсь больше быть в России и хотелось бы к теми у кого z повстречаться, пообщаться помочь если надо.
Кстати у меня были контакты в ИБМ Россия, меня даже туда хотели взять в 1998 году, но не было у меня английского тогда.
Что касаемо лицензий то по-моему с этим не стоит заморачиваться. Это форс-мажер и надо просто продолжать использовать то что ИБМ бросил уйдя. Они еще вернутся. ПО МФ легко переносится на новое оборудование, легче гораздо чем ПО х86. Оборудование можно добывать через третьи страны, секонд нэнд. Это совсем не дорого. Есть возможности.
Я не знаю, как они решают этот вопрос. Мейнфреймы – это большие деньги, которые любят тишину. Но современный мейнфрейм IBM технически невозможно эксплуатировать без возобновляемой лицензии на процессорное время, разве не так?
Нет не так. Мы (мои дебильные манагеры) уже два года и больше как порвали контракт с ИБМ саппорт. И ничего работает машинка. Правда они продолжают платить помесячную плату. Но в случае с Россией и этого не обязательно делать. У наших МФ нет никакой связи с ИБМ. Раньше была.
Возможно, это зависит от конкретной модели мэйнфрейма -- в последние могли и внедрить некую защиту от нелицензионного использования.
Некая защита (если это можно было бы называть защитой) заключается в том что (речь идет только о МФ для 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 на максимальной скорости).
За 3 года РЖД с IBM слезло, грязно ругаясь и целые системы
Видимо РЖД потеряло и не воспроизвела настоящих мэйнфрэймщиков.
Я там были очень крутые ребята, они первыми прочухали выдающуюся значимость MVS еще тогда когда все остальные, включая меня самого, "тащились" от СВМ ЕС (VM/370, VM/SP) и БОС (Базовая Оперционная Система - огрузок от MVS - НИЦЭВТ). Мы бы тоже в итоге пришли к MVS, но СССР рухнул и все разбежались. Остались те кого на Западе еще не очень то и надо было. Возможно и РЖД-ские ребята на Запад свали в 90-е.
Ну что ж тем хуже для РЖД. Теперь они будут терпеть, но грязно ругаться на то на что залезли после ИБМ.
В РЖД и IBM i были...
А как бы Вы ответили на вопрос, в чём крутость MVS именно по сравнению с VM? Для меня акцент IBM на OS/MVS никогда не выглядел технически обоснованным. Но я не имею опыта работы с MVS.
Это очень крутой вопрос. Он про переворачивание моей жизни с ... на... .Обычно говорят про ноги и голову, но я не знаю что назвать ногами, а что головой в этом случае.
Вы, если читаете меня более менее полностью, могли заметить намеки на объяснение этому. Я даже собираюсь написать статью про это.
Попробую тезисно ответить.
В где-то в 1985 году возле Павелецского вокзала (а может и где-то в другом месте, но возле этого вокзала был офис ПО "Конус", в Челябинском отделении которого я только год назад начал работать), в каком то задрипанном московском ВЦ нам демонстрировали CBM ЕС. И было показано SPOOL PU TO <имя ВМ> , и потом PUNCH <имя файла>, и потом READ на той ВМ куда указывала команда SPOOL. Мне тогда было 30 лет, я закончил с красным дипломом институт в 1979 году (диплом назывался "Растровый цифровой запоминающий осцилограф". Он у меня здесь в Канаде. Там была память 8 микросхем по 256 бит и микросхема регистра последовательного приближения), отслужил два года офицером в РВСН, проработал два-три года в Челябинском военном училище штурманов, сначала на кафедре где занимался научной работой по математике (наблюдение и управление в условиях неопределенности. Мы занимались алгоритмами постановки помех), потом на ВЦ училища сразу начальником бюро программирования, и наконец попал в Челябинский Региональный Центр по обслуживанию ЕС ЭВМ, и я уже проинсталлировал несколько ОС ЕС в организациях Челябинска, в том числе возможно уже инсталировал ОС ЕС в Челябинском отделении ЦБ СССР.
И вот меня торкнула последовательность команд SP PU TO, PU, READ. По возвращению из Москвы я занялся этим всерьез, и уже через пару лет я имел много установок СВМ ЕС в Челябинске, проводил курсы по СВМ, ездил раз по шесть в год в Минск в НИИЭВМ, где создавали СВМ (из IBM VM, конечно. Никто там это не отрицал), знал весь отдел (в лучшие времена там было до 60 сотрудников), общался с начальником отдела (Котов Михаил Петрович R.I.P) со всеми начальниками сектором (ПДО и т.д. ), как правило попадал на их "корпоративы" на Новый Год.
И вот на пике успеха с СВМ (VM) в одном из разговоров с Котовым М.П. он мне говорит: "А вот знаешь, Владимир, ИБМ сделали систему MVS из их OS/360 и в ней тоже есть виртуализация и многое другое чего в нашей СВМ (их VM) нет и быть не может, например, RACF". Я конечно удивился. Я не знал что такое RACF. Котов был очень вдумчивый человек. Его все в НИИЭВМ уважали как мощного специалиста. Он сделал эмуляцию команд Минск-32 на виртуальной машине. И вообще был знаковым, харизматичным.
У меня же на тот момент была можно сказать "родовая травма" от работы с ОС ЕС, сиречь OS/360 (MFT, MVT, SVS, TKS - это уже в ГДР сделано было).
Потом на одном из многих семинаров, проводившихся тогда по всему СССР появился молодой парень (кстати вспомнилось что это было в Уфе), который "топил" за MVS. Парень был из ВЦ ЖД, с Комсомольской площади. Мы с ним, после докладов за шашлыками, немного попикеровались. Я топил за виртуальные машины, он за, как здесь говорят "мертвую лошадь", или выкидыша, как мне тогда казалось, OS/360 в известной мне хорошо OC ЕС. Это было еще в благостные 80-е, их конец примерно.
Позже, в начале 90-х, я противостоял тенденциям за Unix. С этим я боролся осознано поскольку понять что это за зверь было не сложно (понять что такое MVS было гораздо сложнее, но там действовали эмоции в основном, такие же как у современной молодежи, топящей за Искусственный Интеллект и не меньше. Кстати об ИИ. Я еще в институте, это 70-е, читал книжки про искусственный интелект).
В 90-е меня пронесло по OS/2, DB2/2, VisualAge for SmallTalk (это я очень плотно изучил самостоятельно по ИБМ документации, и в последствии, в Канаде, почти попал на работу на SmallTalk), Lotus Notes. Windows 95 шел факультативно потому что многие тогда сидели на нем, а я писал в VisualAge на OS/2 и переносил результат в Windows 95.
И вот я в Канаде. Учу язык, ищу работу, клепаю газовые горелки для строительства (кстати в итоге сам полностью собирал их и отгружал эти газовые горелки за $8/час, а начальником у меня был тогда хохол из Одессы, который мне ни доллара не добавил с начиная мною "учеником" до эксперта), заправляю машины канадцев на заправке Full Service. И наконец получаю offer letter на позицию DBA DB2 for OS/390. Т.е. MVS !. Кстати этот офер я получил после двух интервью на 700 University Avenue, Toronto (посмотрите на Google Maps, это через дорогу от парламента Онтарио, Queens Park, там я провел много лет), на которые я опоздал первый раз часа на полтора, второй где-то на час. Но меня в итоге взяли. Моими интервьюерами были венгр и чех. (Peter Beriny, and Ivan Moravec).
На интервью я кстати ни разу не говорил что знаю и работал с MVS. Да было несколько эпизодов когда меня приглашали на ВЦ ЖД Челябинска когда они внедряли MVS, но мне тогда показалось что MVS это хорошо знакомый мне ОС ЕС, от которого я "сбежал" на СВМ и БОС.
Так или иначе я вышел на работу в Канаде сразу после католической Пасхи в 2000 году. В двух шагах от офиса была православная церковь (Holy Trinity Russian Orthodox Church) Святой Троицы (настоятель Владимир, я тоже Владимир, но атеист, православный!), где мы в последствии не раз ходили крестным ходом на Пасху). Это походу знак какой то, однако. Я только сейчас это понял.
Ну да ладно. Много знаков в жизни каждого может быть. Начал я как говорил выше DBA DB2 for OS/390. Вскоре мы перешли с OS/390 на z/OS. Я освоился, включил свои способности. Стал крутым DBA DB2.
В 2006 в компании произошла большая реорганизация. Уволили кучу людей, контрактников кто занимался z/OS, а постоянных работников связанных с z/OS разбросали. Вызвали меня к начальству и говорят: "Влад, мы хотим чтобы ты бросил это дело DBA и стал системным программистом (кто знает что это такое меня поймет) z/OS. Согласен?". Я вспомнил кем я был в СССР/Россия и согласился. Мне передали пароль к юзерайди с правами RACF Special (это типа рут в Юникс или administrator Windows (на самом деле совсем другое, но чтобы понятно было, приблизительно)). И сказали бери любые курсы в ИБМ и если что ИБМ тебе поможет, у нас с ИБМ контракт на полное обслуживание по МФ.
К ИБМ за помощью я не обращался, но курсов в ИБМ прошел много. Даже по Unix System Services и по Linux. И по всем другим аспектам z/OS кроме DFSMS. Этим тогда занимались другие люди.
И я понял тогда (и это есть ответ на вопрос, на который я так долго отвечаю) что VM, моя любовь, основа моего успеха в 80-е, начале 90-х) это детский лепет. Нет не так. VM это VM, а MVS это СИСТЕМА. Настоящая система. Если все кому не лень пишут Linux подобные системы, то MVS подобную систему уже никому не удастся написать. Как не удастся создать систему Энергия/Буран, СССР и воскресить Ленина.
Вот так.
Дык у VM и MVS (как и у исходной OS/360) банально совершенно разное назначение: VM -- это гипервизор, её обязанность -- запускать под собой гостевые операционные системы, а не с прикладными программами работать. Идущая вместе с ней ПДО (забыл, как её по-буржуйски звать) полноценной системой не является, она нужна, по большому счёту, для обслуживания самой СВМ (хотя понятно, что её можно использовать а-ля МС ДОС -- в качестве ОС для "персонального компьютера" в виде виртуальной машины на мэйнфрейме).
В общем, они не исключают, а дополняют друг друга, причём практически не пересекаясь в области применения.
Все верно. НО!
ПДО в оригинале называетс Conversational Monitor System (CMS, originally Cambridge Monitor System).
В VM есть еще одна ОС ВМ: GCS. Ее роль привнести в VM "сладкие" возможности MVS (мини MVS):
The Group Control System (GCS) is:
A component of z/VM. It consists of a named, shared segment in storage that you can IPL and run in a virtual machine.
A virtual machine supervisor. It bands many virtual machines together in a group and supervises their operations. See Figure 2.
An interface between applications. Some of the applications are:
Virtual Telecommunications Access Method (VTAM®®)
Remote Spooling Communications Subsystem (RSCS)
NetView®®
z/VM®'s Control Program (CP), Figure 1.
На сегодня роль zVM исключительно для Линукса.
Объясняю "НО". Компьютеры предназначены для выполнения пользовательских програм, а не для развлечения програмистов. Нынче правда все с точностью наоборот происходит. Но это только в мире х86. На МФ все направлено на эффективную производительную работу.
Роль VM на МФ на самом деле исполняет PR/SM. Для производительной работы создана была исключительная по возможностям и пригодная для любой производительной работы MVS. Чтобы иметь возможность выполнять Юникс програмы был добавлен USS. TCP/IP stack был добавлен. Даже контейнеры (о них я ниже добавлю) добавлены в zOS. Хотите выполняйте ваши контейнеры в zOS.
Выполнять zOS на виртуальной машине можно, но это верх идиотизма.
Что еще надо для бэкэнда? В принципе ничего. Но капитализм это.. нет не конкуренция.. это анархия. Каждый может делать что ему в голову взбредет и продавать это кому угодно.
До появления микросхем создать мощный компьютер могла только мощная организация. Да и сейчас сделать мощный компьтер в гараже не получится. Но можно делать мощь из кучи чего-нибудь маломощного. Не буду уходит в туман. Потом когда-нибудь.
Другой очень гнусной манерой в ИТ этого века стало то что крупные производители ПО изобретают "колесо", "велосипед", "ракету", т.д. называют это новыми именами, точнее даже кличками (докер, контейнер, кубернетес, Монго, Хадуп...), и объявляют это изобретением. Патентуют возможно даже. По факту это может быть и как правило оказавыется нечто давно известное, называемое иначе. Но это позволяет создать нишу на рынке и получить экстра моней.
Примером этому могут служить докеры, контейнеры и кубернетес. Эти ни о чем не говоряшие названия по сути делают то что делает вышеупомянутый GCS. Идея таже.
Ну у нас именно так. Есть центральные сервера (не МФ, middleware - IBM i) и есть "куча мелюзги" - "внешние системы". Там и винда и RHEL и SLES и много чего.
Центральные сервера - это АБС. Ядро всего банка. Все mission critical. Все остальное (что не так критично по времени недоступности, скорости отклика и т.п.) вынесено на внешние системы.
Распределенные системы сложнее программируются. На обслуживании распределенных систем целая "индустрия" работает - DevOps.
И куда больше времени тратится на согласование работы, выполняемой на физически разных машинах. Где-то это может быть несущественно, где-то -- очень важно.
Там основная проблема в скорости доступа. Елси та же БД сосотоит из нескольких десятков тысяч таблиц и индексов, то разносить ее по физически разным серверам становится сложно в плане резкой деградации скорости выполнения запросов (когда разные таблицы одного запроса на разных физических машинах оказываются).
Или разные части одной и той же таблицы. Архитектура "Shared Nothing". Собственно единственная для кластеров на х86. Исключение Оракл RAC ("Oracle RAC (Real Application Clusters) is a database clustering solution that enables multiple servers to operate as a single, unified system, providing high availability, scalability, and fault tolerance.").
.....но и для того, чтобы когда один из серверов вышел из строя (потоп, пожар, физическое уничтожение) - оставшиеся подхватили бы работу.У одного большого мейнфрейма такой опции в принципе нет, если условно говоря он будет уничтожен - пострадают все, у кого на нем что-то работало.
Ну это притянутый за уши аргумент. Во первых, и сервера на х86 и МФ располагаются в весьма защищенных дата центрах. Возможность потопа, пожара, физическое уничтожения в них сведено на нет, а если это и произойдет то выгорит все до тла. Это называется Disaster при против этого как в отношении ИТ на серверах х86, так и МФ компании разрабатывают и тестируют каждой год DR plan.
У одного чего угодно нет возможности защиты от этого одного полного уничтожения. Минимум два конечно же, на разных локейшн. Или аренда DR сайта в другой организации. У нас одно время был DR site в ИБМ. Просто один наш МФ стоял в нашем, единственном ДЦ, а второй в ДЦ ИБМ.
Возможность потопа, пожара, физическое уничтожения в них сведено на нет
Хаха три раза, это только в крупных компаниях федерального значения, и только те случаи про которые мне было известно (а обычно об этом не особо распространяются).
Про небольшие конторы уж и не говорю. Но у них на МФ денег просто нет, и не надо.
Вот это:
...вместо ОДНОЙ ОЧЕНЬ ДОРОГОЙ установки, для которой актуально ее максимально сбалансированное использование - в мире х86 принято набрать больше мелких серверов.
хочется продолжить так " ...миру х86 пофиг сбалансированность, т.е. эффективность, оптимальность, навалим столько ресурсов на сколько хватит денег и будем сидеть курить бамбук.
Мой манагер, он же типа наш "архитектор" часто говорит так: примерно "берем Кубернетес, запускаем 50 подов в них 50 приложений." И хочется спросить " и что?".
Помню обсуждали проблему перформанс одногт сервера с несколькими приложениями, Манагер спрашивает: "а какое приложение жрет ресурсы больше", серверисты наши разводят руками и говорят: "Мы не знаем". Для меня это звучит как детский лепет. В zOS я вижу все что происходит и как происходит, кто что и сколько ест, к чему это приводит и как это поправит. Это все потому что в z/OS есть WLM. Он все знает и по полиси созданной мной раздает. Плохо раздает, я меняю полиси и смотрю что стало. Это можно делать хоть на Продакнш хоть где столько раз сколько нужно чтобы добиться результата.
Манагер спрашивает: "а какое приложение жрет ресурсы больше", серверисты наши разводят руками и говорят: "Мы не знаем". Для меня это звучит как детский лепет.
Вот именно. У нас сопровождение постоянно мониторит загрузку. И всегда видит кто сколько жрет.
Запрос типа
Сервис ... за последние 5 недель увеличил потребление ресурсов в 3 раза. На данный момент является вторым по величине сервисом.
В качестве альтернативы рассматривается перенос сервиса на резервный сервер, что приведет к лагу до 10ти минут что недопустимо
Означает необходимость доработки сервиса для оптимизации потребления ресурсов.
Что, в какой-то момент длину имён наборов данных увеличили? В классической OS/360 она составляет максимум 44 символа, а не 144. Или это опечатка?
В "доисторической эре" не упомянут режим PCP -- однопрограммный. Самая первая версия OS/360 работала именно в этом режиме, поскольку IBM не успевала сделать всё, что хотела, причём для работы было достаточно 32 Кбайта памяти (примерно 14 занимало ядро системы, остальное уходило под программу пользователя или системную программу, не входящую в состав ядра). По мере развития системы требования к памяти росли; самые последние варианты PCP требовали 64 Кбайта. В конце концов, этот режим полностью выпилили, и самым младшим стал MFT, требующий к тому моменту 128 Кбайт (на момент своего появления ему было достаточно 64).
Не отмечена также изначально (или почти изначально) присутствовавшая возможность для прикладных программ создавать контрольные точки (checkpoint), чтобы в случае какого-то сбоя система могла возобновить выполнение программы с этой точки, а не с самого начала.
Что, в какой-то момент длину имён наборов данных увеличили? В классической OS/360 она составляет максимум 44 символа, а не 144. Или это опечатка?
Это опечатка. Спасибо что заметили. Попробую испрасить.
Спасибо за критику. В одной статье охватить все ньюансы соверешенно невозможно. Такой подробности я не ставил своей целью. Статья и так получилась крупной для статьи.
Да, checkpoint, а сколько еще разного было что отличало уже в 70-е годы прешественников нынешнего zOS от нынешних Юникс, Линукс, Виндовз, и еще больше собственно zOS.
Исправил 144 на 44. Спасибо еще раз.
Спасибо. А планируете статью о z/VM? Особенно интересно во что превратилась CMS (ПДО у нас). Ведь это система со 100% паравиртуализацией. Приходилось ковыряться в макросах ввода вывода и обнаруживать вместо SIO,TIO,HIO обращения к супервизору (кажется термина гипервизор тогда не было) за услугой.
p.s. переписывал для себя stdlib Си-транслятора от НИЦЕВТ под ПДО
p.p.s. Master sheduler FOREVER!!!
У нас в СВМ гипервизор именовался монитором виртуальных машин (МВМ); супервизор же был, в первом приближении, ядром DOS/360 и OS/360, но не VM/370.
ПДО -- да, однозадачная ОС, предназначенная для эксплуатации исключительно под СВМ, поэтому-то никаких команд ввода-вывода в ней нет.
Пы.Сы. А Мастер Шедулер -- это уже про ОС/360, она же ОС ЕС :)
ПДО -- да, однозадачная ОС
Однопользовательская, но многозадачная! У меня волею случая была фактически в качестве персоналки ЕС-1007 с терминалами ТС-7063. Поставили под проект который не взлетел и никому до неё дела не было.
Ну да, хотел про однопользовательскую сказать :)
Вы не ошиблись. Строго говоря ПДО(CMS) была однопользоваетльской и однозадачной. Это можно легко проверить по документации, но я знаю это потому что в сотрудничестве с НИИЭВМ я с моими коллегами дорабатывал VM/SP Pass-Through для перекачки файлов из ПДО на ПК. Так вот в этом VM/SP Pass-Through был встроенный монитор многозадачночности. Многозадачность исходного ПДО достигалась запуском нескольких виртуальных машин и использованием протоколов связи ВМ через память.
Приходилось ковыряться в макросах ввода вывода и обнаруживать вместо SIO,TIO,HIO обращения к супервизору (кажется термина гипервизор тогда не было) за услугой.
видимо с помощью команды diag (на виртуальной машине это обращение к гипервизору, термин такой тогда уже был), в частности для ввода/вывода - diag 0020
Угу. Вот только не diag, а просто ДИАГНОСТИКА -- у неё официально нет мнемоники. Впрочем, это уже придирки :)
Вы правы про гипервизор, согласно Вашей ссылке, но я не знал. В те года что я работал с СВМ ЕС этот термин в русскоговорящей среде не использовался и в документации на СВМ ЕС на русском языке, насколько я помню, не использовался.
Классный вопрос. Очень неожиданный и приятный.
СВМ ЕС, 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 эмулированным на ПК для копирования файлов.
Я просмотрел CMS User Guide в zVM 7.3 (2025). Cудя по оглавлению практически все остлось как было в VM/SP. Добавилось пара-тройка новых названий (DFSMS/VM, CMS/DOS).
И в самом деле зачем что-то добавлять в легкую системку персонального использования.
https://www.ibm.com/docs/en/zvm/7.4.0?topic=xl-cc-zvm-13
Я и забыл, что IBM документация настолько доступна. Пока листал наткнулся на СИ и вспомнил свои приключения с Си под ПДО. Не помню как на ТС-7063, но на ЕС-7927 на клавиатуре фигурных скобок точно не было. А в знакогенераторе были и после перекодировки диграфов на экране показывались. :)
Возможно, из-за того, что клавиатура ЕС-7927 рассчитана на ДКОИ, но собственно терминал внутри использует ASCII (точней, КОИ-что-то-там).
Не только доступна, но и очень высокого качества. По крайней мере для продуктов на МФ.
Я сталкивался с ЕС-1007 только в одном месте - в филиале Института Теплотехники Челябинск-40. Даже наверное устанавливал СВМ ЕС (а что еще я мог там делать?). Но я не помню такого устройства ТС-7063. Почему ТС? Нырнул в Инет. Ну конечно же это ЕС-7970 комплекс. Такого зверя я знал. Прекрасная штука, почти персональный компьютер. Клавиатура мягкая, шрифт хороший. В лучшую сторону отличался по сравнению с ЕС-7927.
У него сдвоенное обозначение, но почему, лично я не в курсе. Но вообще, такое бывало достаточно часто, но обычно с забугорными машинами (скажем, ЕС-1040 и ЕС-1055 имели у Роботрона свои собственные обозначения).
Однажды был шокирован на выставке сочетанием шилдика ЕС-79XX и digger на цветном экране. )))
Однокурсник рассказывал, что когда все сотрудники расходились по домам и наступала ночь, их мейнфрейм начинал чем то там сам с собой заниматься, держа 30-40% нагрузки)
Банковский день закрывал?
Был такой подход к использованию МФ когда днем пакетная обработка заданий не выполнялась в угоду диалоговой, дневной. Т.е. запустить пакетное задание было возможно, но т.н. инициаторы заданий запускались после рабочих часов. Задания эти хранились в очередях заданий и после окончания рабочего дня запускались инициаторы и шло выполнение этих пакетных заданий.
К утру все они завершались и результаты их работы либо распечатывались либо помещались в очереди к тем кто их запускал для просмотра и дальнейшей обработки. Пакетные задания и инициаторы имели т.н. классы и часть пакетов, в определенных классах, могли и днем выполняться, а те что не к спеху отправлялись в тот класс(ы) что выполнялись ночью. Вот этими очередями заданий submitted днем и выполняемыми ночью и занимался их мэйнфрэйм.
С появлением WLM (начало 21 века), и даже несколько раньше это стало не актуально и пакетные задания принимаются теперь для исполнения весь день и ночь, но в discretionary сервис классе. В правильном переводе на русский это надо понимать как "по усмотрению". Т.е. такие задания выполняются когда работы во все других сервис классах достигли своей цели и еще остались ресурсы, вот тогда ресурсы выдаются заданиям/работам в discretionary service class. Другими словами эти работы никому не мешают и используют только остатки (объетки если хотите).
Опять же если какие-то задания должны выполняться в любое время суток с выше чем discretionary importance (важностью) они запускаются в очереди классов, обслуживаемых WLM в сервис классах с более высокими важностями, и возможно разными velocity (относительнуые скорости).
Вся статья состоит из того что там что-то безопаснее и так далее, а можно конкретики? Я напомню, что другие ОС тоже не собираются падать от чего угодно, у нас есть виртуальная память в процессоре, мы можем сами перезапустить программу (а не дать ОС бездумно перезапустить и сделать всё хуже)
А, например, при отказе процессора или блока памяти?
Hot-swap CPU и RAM это не уникальная фишка мэйнфреймов IBM.
Навскидку, Sun/SPARC, DEC/Alpha умели это
Вопрос не в hot swap, а в продолжении работы программы.
Уже лет 15, как существует технология виртуализации VMware Fault Tolerance, позволяющая для одной или нескольких виртуальных машин защититься от отказа процессора или сервера целиком, с немедленной активацией резервной копии ВМ и сохранением её состояния, включая все запущенные программы и их состояние. Да, есть ограничения - в первых версиях можно было только одно виртуальное ядро на ВМ, сейчас до 8 ядер. И стоит дорого. И, на практике, используется достаточно редко - обычные технологии кластеризации и проще, и надёжнее. Старое описание FT, текущие ограничения для vSphere 8.0.
Для виртуальных машин. А что с самим гипервизором? Или с приложениями, работающими под управлением ОС на реальной, а не виртуальной машине?
Способность восстановления после сбоев или отказов аппаратуры IBM развивала, начиная ещё с Системы 360, т.е. со второй половины 1960-х годов. Это довольно неплохо работало уже в поздних версиях классической OS/360 (а её развитие прекратилось на версии 21.8 году эдак в 1972-74; дальше шли уже системы с виртуальной памятью, быстро превратившиеся в MVS, из которой выросла нынешняя z/OS). Т.е. то, что на "обычных компах" появилось 15 лет назад, IBM имеет уже с полвека.
Гипервизор у нас уже умер вместе с отказавшим процессором, да и фиг с ним. На работу прикладной ВМ с настроенной FT это уже никак не влияет.
Не уверен, но мне кажется, вы путаете разные технологии восстановления при сбоях и отказах железа - ECC для памяти и шин процессора и т.п. и в x86 уже работают достаточно давно. Речь же в этой ветке шла о полном сохранении состояния прикладной программы (не до контрольной точки, а текущего состояния) при полном отказе (а не сбое по шине) процессора. Вы уверены, что мэйнфрейм 1974 года обеспечивал такой функционал?
Понятно, что в более дорогих мейнфреймах использовались топовые на этот момент технологии, этот тезис я и не пытаюсь оспорить. Наоборот, мой тезис в том, что сейчас в мире x86 и существующая технология полной защиты от аппаратных сбоев достаточно мало востребована - эти проблемы решаются на уровне архитектуры прикладного ПО, кластеризации, контейнеризации и т.п.
Не уверен, но мне кажется, вы путаете разные технологии восстановления при сбоях и отказах железа - 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 и существующая технология полной защиты от аппаратных сбоев достаточно мало востребована - эти проблемы решаются на уровне архитектуры прикладного ПО, кластеризации, контейнеризации и т.п.
Мне кажется, что все эти решения не обеспечивают полной защиты от проблем с железом. Как, например, восстановить работоспособность программы, если сдох процессор и содержимого регистров на момент отказа нет (они где-то в процессоре остались)? Никак тут не восстановишь с момента сбоя -- только с последней контрольной точки, если таковая имеется, ну или вообще только запуском с самого начала. Ну а на мэйнфреймах в тех случаях, когда это технически возможно (содержимое памяти корректно и были успешно сохранены регистры процессора), работа пострадавшей программы продолжается именно с точки сбоя, буквально с команды, при выполнении которой сдох процессор.
Кроме того, защищаться путём соответствующей архитектуры прикладного ПО, естественно, можно -- но это резко усложняет это самое ПО и заставляет создавать необходимый функционал в каждой прикладной программе. В этом плане возможность разруливать ситуацию и обеспечивать восстановление на уровне аппаратуры и ОС для любого прикладного кода весьма ценна -- хотя, естественно, лучшие результаты достигаются в случае, когда и прикладное ПО спроектировано так, чтоб облегчать восстановление.
Мне кажется, что все эти решения не обеспечивают полной защиты от проблем с железом. Как, например, восстановить работоспособность программы, если сдох процессор и содержимого регистров на момент отказа нет (они где-то в процессоре остались)? Никак
Так в том и суть vSphere Fault Tolerance, что она сохраняет работоспособность ВМ именно в таком случае - за счёт того, что ровно те же вычисления с такой же памятью и состоянием регистров выполняются на "теневой" копии ВМ на втором гипервизоре, а поведение процессора детерминировано. Там, где что-то не детерминировано или может рассинхронизироваться, нужные данные подтягиваются в теневую ВМ по сети (минимум 10 Гбит), при необходимости основная или теневая ВМ чуть притормаживается до синхронизации. При обнаружении отказа основной ВМ/гипервизора/etc теневая ВМ становится основной, ничего не заметив (реально там будет некоторая пауза и, как минимум, оповещение сетевого оборудования о смене интерфейса, на котором живёт этот MAC/ip, т.к. ввод-вывод на ВМ разблокируется, но это детали). Это действительно весьма крутая технология, защищающая от полного внезапного отказа железа или гипервизора - но она практически не востребована в реальной жизни.
По остальным вопросам разногласий нет, спасибо!
Про подобную реализацию не знал. Век живи -- век учись (и дураком помрёшь :) ).
.... при необходимости основная или теневая ВМ чуть притормаживается до синхронизации.
Только не при необходимости, а постоянно притормаживается для синхронизации. Более того сама координация выполнения виртуальной машины на двух серверах берет ресурсы.
Если сравнить с репликацей БД в синхронном режиме то притормаживание происходит только по фактам изменения данных, а здесь по видимому каждый шаг в праймери ВМ должен останавливать, дублироваться в стэндбай и лишь потом делаться следущий шаг. При этом еще на каждом шаге надо проверить кто из двух еще жив, упасть может любой из двух.
Может я ошибаюсь в отношении 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 минут в худшем случа, но это дизастер, т.е. физическое, полное уничтожение одного из дата центр.
С синхронизацией ВМ ещё проблема в том, что не обязательно ведь в результате ошибки ВМ упадёт. Там может просто измениться какой-нибудь битик в памяти, и фиг это заметит гипервизор.
От изменения бита в памяти мы защищены ECC у памяти и шины, а вот логическую ошибку ПО или BSOD в ОС, FT, да, точно в таком же виде оттранслирует на теневую копию, это факт.
ECC снижает вероятность ошибки, но не обнуляет её.
Ошибка может произойти в процессоре. Помнится, я читал, что в среднем раз в год микропроцессор процессор даёт единичный сбой из-за действия космического излучения. Процессоры мейнфреймов имеют параллельно работающие функциональные блоки для устранения таких ошибок, x86 нет.
Ошибка может произойти во вводе-выводе, даже с учётом контрольных сумм. Я думаю, каждый имеет опыт чтения мусора с диска. Даже с raid это принципиально возможно в ряде сценариев.
Да, понятно что FT будет стоить вычислительных ресурсов, именно поэтому исходно было ограничение максимум одно ядро процессора. Но не уверен, что настолько больших - код всё таки выполняется процессорами детерминированно, и при том же состоянии памяти и регистров в общем случае два одинаковых процессора дадут одинаковый результат даже без синхронизации. Тонкости начинаются, когда есть обмен с внешним миром и ввод-вывод, как именно это у VMware сделано не знаю, знаю только что теневая ВМ полностью изолирована от сети. Соответственно тратить много ресурсов на проверку её живости не нужно - при её потере мы теряем только резерв, это можно пережить. В том, что это похоже на Parallel Sysplex видимо соглашусь - я про мейнфреймы не знаю, но по описанию действительно похоже. А вот то, что ошибка приложения или синий экран смерти на основном экземпляре ВМ ровно в таком же виде оттранслируется на теневую, я совершенно уверен, это и логично, и в документации где-то написано. FT - это именно защита от аппаратных сбоев, и ничего больше. Поэтому кластера, контейнеры и т.п. и используются гораздо чаще - они и от сбоев железа, и от сбоев софта лучше защищают. Вся эта ветка началась с возможности обработки отказа CPU, что, конечно, явление фатальное - но, к счастью, довольно редкое :)
В том, что это похоже на Parallel Sysplex видимо соглашусь - я про мейнфреймы не знаю, но по описанию действительно похоже.
К сожалению совсем не похоже. В Sysplex нет никаких теневых образов, все системы в Sysplex выполняют полезную работу, каждый свою и ничего не синхронизируется.
Похожесть ограничивается только тем что когда одна из систем выходит из Sysplex (не обязательно из-за сбоя, а например для обслуживания) в целом оставки работы не происходит и никаие приложения не "падают".
Вся эта ветка началась с возможности обработки отказа CPU, что, конечно, явление фатальное - но, к счастью, довольно редкое
На МФ отказ CPU не является фатальным. Программа попавшая под сбой CPU выполняется другим CPU, отказавший CPU заменяется запасным. Программа повторяется с того месте где произошел сбой. Явление конечно редкое, но не невозможное.
МФ отказ CPU не является фатальным.
Как определить что CPU отказал/сбойнул?
Если определили, как понять, с какого момента?
В чипе CPU есть цепи контроля и используются избыточные коды. Это электроника. Есть прерывание, которое останавливает вычисление запоминает адрес прерванной команды в памяти для этого предназначенной, управление передается програме восстановления машинной ошибки. Програма востановления выполняет действия о которых вы спрашиваете. Это теория которую я изучал в начале 80-х. Сейчас в принципе тоже самое только круче.
В МФ всегда имеются запасные CPU. Их активируют в замен отказавшего. Как уже описывалось выше, МФ имеет связь с ИБМ (кстати это может быть не только ИБМ на самом деле) и в случае любого сбоя ИБМ или другая компания взявшая на себя обязаности ИБМ (почему бы эти обязаности не взять кому нибудь в России?) получает сигнал с информацией что ж там случилось. В ИБМ автоматически генерируется work order и заказ на склад для запчастей, также делается звонок ответственному клиента чтобы запланировать приезд инженера для замены сбойного оборудования на МФ,
Вот так это работает и к этому надо стремиться. Я это наблюдал пару-тройку раз за 25 лет работы в Канаде и был в восторге. Но, к сожалению, недавно, в конце апреля этого года, я наблюдал и другую картину. Три года назад наши манагеры решили съэкономить и отказались от ИБМ саппорт. Перешли в какую то левую которая заявляла себя способной заменить ИБМ. Со мной это не согласовывалось. У ангосаксов такая манера несогласовывать со специалистом если они нашли дешевый вариант и экономят деньги.
И вот спустя три года сначала один Support Element вышел из строя, потом второй, сигналы принимать было некому, а потом и одна система, и надо же Продакшн, не Девелопмент тоже выполнявшаяся на этом же МФ, тоже выходит из строя!!! И тут я выясняю что и оба Support Elements тоже down и я не могу просто перезагрузить Продакшн. Объявили DR для Продакшн. Вообщем тухлая история. Отказ от ИБМ оказался таки фатальным с самом конце использования МФ в этой нашей компании. Конечно все в итоге восстановили и сейчас та Продакшн жужжит где жужжала. Но начались проблемы с Dell VMAX 40K на другом МФ, который как раз DR для этой Продакшн и не только. От Dell support тоже отказались три года назад, и за это время redundancy упала ниже плинтуса и VMAX got vaulted, ушел в несознанку, спился, улетел на Марс (как говорилось в одном советском филме).
Короче МФ-му МФ-мовое, а человеку человеково. Тут палюсом еще ментальность наглосаксов. Я за пару часов нашел где купить запчасти для VMAX и инструкцию как их заменить. Сам, говорю могу это сделать хоть и не электрик (но у меня красный диплом Челябинского Политехнического Института по специальности Автоматика и Телемеханика и квалификация инженер-электрик, да и электриком я рабол до ЧПИ, 4-го разряда). Они ничего не говорят! Ни да, ни против, Причем "они" это парочка русскоговорящих "манагеров" с молоду здесь, в Канаде, и в мозгами переделами под канаду. Ну и конечно у этих "русскобезмозглых" начальство. У одного выходец из Вьетнама, у другого то ли Португалия то ли... хрен знает откуда. Все струпор. Но в пятницу фирма, которую они наняли три года назад, выкатила таки quotes на $15591 после недели раздумий, типа, "сколько ж с них взять?". Это за пять "батареек", которые на интернеты я находил стоят меньше $1000 (у них в инвойсе $1500), хорошо $7500 за пять. И чтобы их поменять (батарейки!!!) еще $7500. Вот вам и ВВП Канады больще чем России. Кстати эта фирма что саппортает наш, канадский, VMAX вовсе и не канадская, а США. Спецы ее сидят в NewJersey. Я с ними говорил когда они чинили Support Elements. Они работают так: посылают клиенту какого-нибудь филипинца в Канаде, который умеет держать отверку в руках и камеру смартфона двигать, на экран этой камеры смотрит парень сидящий в NewJersey и командует фиоипинцем в Канаде. Нажми туда, пойди сюда-туда, открой, закрой, разомкни, замкни, и т.д и т.п..
Вот вам и Запад. Зря развалили СССР, хотя и в СССР тоже были клоуны, и я их знаю в том числе в нашей ИТ. Но эти, с кеми я сейчас, саморазваливаться точно не будут. Даже наоборот.
Мф очень сложно "убить"
Что, и даже шокером в плату не убить?
Так в том и суть vSphere Fault Tolerance, что она сохраняет работоспособность ВМ именно в таком случае - за счёт того, что ровно те же вычисления с такой же памятью и состоянием регистров выполняются на "теневой" копии ВМ на втором гипервизоре, а поведение процессора детерминировано. Там, где что-то не детерминировано или может рассинхронизироваться, нужные данные подтягиваются в теневую ВМ по сети (минимум 10 Гбит), при необходимости основная или теневая ВМ чуть притормаживается до синхронизации.
AFAIK, ничего там не исполняется на "теневом процессоре". Гипервизор делает регулярные снепшоты памяти. В случае аварии, сдохший СPU выводится из оборота, а подверженные воздействию сбоя виртуальные машины откатываются на ближайший снепшот. Аналогичный алгоритм с данными - регулярные снепшоты файловой системы (ZFS позволяет) синхронизированные по времени со снепшотами памяти. Но как вся эта кухня должна работать в составе более крупной системы и при это не рассинхронизироватья (ведь еще есть клиенты, которые могут и не знать о сбое), мне честно говоря не понятно. :)
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 год.
Если аж 1990-й, то это ещё не z/OS -- до неё ещё 10 лет. Получается, уже на машинах ESA/390 сделали (а может, и на поздних ESA/370).
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.
Как правильно отметили, вопрос именно в сохранении работоспособности программы, которая пострадала при отказе техники. Мэйнфрейм (аппаратура + программная поддержка в ОС) очень часто способен продолжить её выполнение -- когда прямо с точки сбоя, когда с некоторой контрольной точки, которая была чуть раньше.
Спасибо за комментарий. Я ценю любые мнения.
Мне не кажется что статья только о безопасности хотя это довольно важный аспект любой ОС и 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.
Вот, кстати, да. Что очень нравится в IBM i - это то, что в каждом задании есть JOBLOG. Который, по окончании задания падает в спул (вывод на печать, хотя физическим принтером никто не пользуется - "спульники" можно и так посмотреть). И в нем есть все. Все ошибки, все сообщения. Очень подробно. Что случилось и где.
В RPG есть дополнительные средства. Например, команда dump - в обработчике необработанных исключений делаем дамп и в спул падает полный дамп в данной точке - полная диагностика (в какой строке, какая ошибка, состояние всех переменных и т.п.)
Если исключение перехвачено и обрабатывается самостоятельно - есть PSDS - Program Status Data Structure. Там тоже немало информации что и где случилось.
Т.е. диагностика отказов тут намного лучше реализована чем в других средах.
Вышеописанное различие я считаю ключевым в сравнении систем. Из своего опыта работы с Видовсами, Линуксами, OS/2 в том числе, я могу утверждать, что ничего подобного ни в одной другой системе, включая мейнфреймовские, я не видел.
Т.е. паники в unixе или bug-checks (синие экраны) в винде вы не увидели.
В Unix-вариантах существенно ограничен набор квалификаторов процессов и целей. Характер целей тоже совсем иной. Это в случае Unix будет в основном количество CPU, памяти, предоставляемыми тем или иным процессам.
Просто потому что одинаковый термин означает разные вещи. Процесс в MVT скорее похож на cgroup в Linux, или на job в windows.
zOS невероятно старая и дремучая. У меня есть теория, почему IBM гадит Hercules (это sw эмулятор железа, умеет запускать старые версии OS/370). Я считаю, что они таким образом прячут это безобразие от публики, пытаясь поддерживать репутацию чего-то большого и недосягаемого. А так, если иметь с ним опыт, и сравнить с любой современной системой - гуано.
z/OS просто не может быть "невероятно старой" -- для перехода на 64 разряда все собственно системные вещи пришлось переписать по, надеюсь, очевидным причинам. Это OS/360 невероятно старая -- но таки да, написанные под неё программы могут выполняться в z/OS без каких-либо изменений.
И, кстати, в MVT процессов не было. Были задания, задачи, подзадачи, были разделы памяти -- но не процессы.
А ещё кстати -- OS/370 в природе не существует. А Геркулес умеет запускать хоть древние системы, хоть современные.
Я бы сказал не переписать, а дописать.
Как известно до 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) тем медленнее чем выше разрядность т.е. ниже производительность.
Прикладные программы переписывать не требуется, там, насколько мне известно, 100% переносимость (и какой-нибудь прикладной код из 1965-го будет без изменений работать и сейчас), а вот ядро системы (супервизор, грубо говоря) -- необходимо, ведь именно оно обеспечивает возможность работы на 64 битах, оно должно поддерживать новые возможности управления адресными пространствами и т.д. и т.п.
И, кстати, AMODE -- не 16, а 24, описка-с :)
Да. описка. 16 МБ, но 24 разряда адресация. Это в микропрцессорах было 8, 16, 32, 64.
Как я понимаю (не писатель ядер z/OS) ядро системы тоже состоит из програм в каждой из трех зон: 24, 31, 64 (кстати знаете почему 31, а не 32? Думаю что знаете поэтому ответ "да" достаточен). Более того полагаю (можно уточнить) что большенство програм ядра как раз таки остаются в зоне below the line (16 МБ). По причине производительности. Давно это было когда все это разяснялось на курсах в ИБМ. Всего не упомнишь и конспекты уже давно выброшены.
Синии экраны конечно видел. Поэтому и назвал то как обрабатываются такие ситуации в 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.
z/OS и IBMовские мейнфреймы - великолепный пример того, что талантливый некромант может ехать на дохлой лошади очень долго и даже обгонять многих живых скакунов.
В то время как появление доступных микропроцессоров совершило революцию в мире электроники и позволило перейти к распределенным системам, которые по совокупности характеристик оказались лучше старых мейнфреймов, IBM приложила титанические усилия к тому, чтобы убедить мир, что их система надежна. Имел я опыт общения с z/OS. В далеком 2006, но мне кажется, там ничего принципиально не изменилось за последние 20 лет, как не менялось за предшествующие 30. Система надежная в своем роде, просто она надежно делает то, для чего ее создали. Но это точно не какие-то там ваши прикладные задачи.
Ну так и мэйнфреймы давным-давно уже микропроцессорные. Да и не сказать, что доступные микропроцессоры произвели какую-то революцию. Ну, вышел 8080 (первый более-менее полноценный микропроцессор), и что? Он лишь слегка подвинул мини-ЭВМ из их ниши, поскольку тягаться даже с самыми слабыми из них ему было, скажем так, проблематично. А к тому времени, как производительность микропроцессоров в достаточной степени увеличилась, мини-ЭВМ тоже превратились в микропроцессорные машины, а несколько позже то же самое сделали и мэйнфреймы.
Спасибо за мнение. Я уважаю все мнения.
Позвольте спросить чем Вы занимались в zOS в 2006 году? Не подумайте что это наезд, мне действительно хочется как люди имевшие контакт с этой тематикой приходят к такими выводам и заключениям как представили Вы.
Тех кто серьезно работает с ИБМ МФ и zOS, а их везде по миру достаточно много для таких, я бы даже не постеснялся сказать глобальных, проектов, убеждать ни в чем не надо. Они все прекрасно знают, это не секрет. Они работают и никуда уходить не собираются. Да, много ушло. Вот где я сейчас работаю уходят. Уходят с 1995 года и наконец то похоже уйдут и дадут мне уйти наконец на пенсию (мне 70).
Лучше старых мэйнфрэйм это каких? В апреле ИБМ выкатил z17. Вы легко найдете информацию на z17 в сети.
Да, система zOS в связке с МФ супер надежна. И это дотигается не многократным дублированием, а гораздо более интелектуально и централизованно. Распределенные система это не понацея всего, у них есть очень много издержек и недостатков. С увеличением масштаба эти издержки и недостатки многократно увеличиваются и ... увы дорожают. Инфраструктуры на МФ из года в год дешевеют и мощнеют.
Наверное, тот кто писал статью поддерживал z13 в сфр. Знаю таких адептов любителей старины. Меня больше всего поражает интерфейс и шрифт схожим с tr-dos (zx-spectrum). Ох настольная.
Во-первых, z13 не такая уж и страна, у меня два МФ: zBC12 и z14. Оба под zOS 1.13 (текущая версия 3.2, а МФ - z17, этого года.
Во-вторых не поддерживал, а поддерживаю и не в сфр, а в Ontario Power Generation (opg.com).
Что касамо шрифтов во-первых для бэкэнд сервера шрифт (Вы повидимому видели терминал IBM-3270, или его аналог ЕС-7920) это последнее о чем надо замарачиваться, во-вторых в настоящее время и давно существует широкий набор клиентских приложений для работы с МФ в современном GUI.
Я лично работаю с МФ с эмулятора 3270 на моем лаптопе. Это лучший интерфейс для администрирования, траблшутинга, мониторинга и т.п.. Программы я тоже пишу с 3270. На языке REXX главным образом.
Да, аппаратные терминалы ушли в прошлое. Для IBM i на смену аппаратным 5250 пришли эмуляторы. В т.ч. и гуевые.
Сама IBM дает бесплатный пакет IBM i Access Client Solutions.
Там кроме самого эмулятора 5250 еще очень много всякого полезного - работа со спульниками, работа с IFS ("интегрированная файловая система" - INIX-like подраздел ФС), работа с бд, включая интерактивный SQL который еще и планы запросов рисовать умеет с диагностикой и рекомендациями оптимизатора - очень полезный инструмент для разработчика) и средства администрирования...
Спасибо за интересную статью. Она мне напомнила собственные усилия по продвижению OC Unix вместо ОС ЕС (читай OS/360) в середине 80-х прошлого столетия:
При этом я прекрасно понимал, что всё это уже вчерашний день. Читая в академии отчеты IRIA, я знал и про СУБД, и про сети и про персональные компьютеры, операционную систему Unix и язык Си. Но здесь этого ничего не было, здесь была ОС ЕС, ПЛ/1, IBM и НИЦЭВТ.
Я бегло просмотрел Вашу статью и буду читать ее внимательно и вдумчиво. Я люблю и знаю историю ИТ в СССР. По книге Малиновсого, по широкому сотрудничеству с НИИЭВМ (Минск), менее широкому с НИЦЭВТ (Наумов Вячеслав Владимирович) и ПО "Восход". Я был бы счастлив работать там где Вам повезло работать, но я родился в Челябинске и этим все сказано.
Да в середине 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.
Т.е. надо было просто подождать и все что хотелось появится от достижений ИБМ и их МФ.
Читаю Вашу статью, интересно, дочитал до публикации Вашей книги. В начале 80-х (82-83) я занимался "...практическими аспектам связи программ, написанных на разных языках Ассемблере, и ПЛ/1". Это было довольно экзотическое занятие. Обычно программисты либо на Ассемблере писали либо на Фортран, либо ПЛ/1. Разобрался самостоятельно, по каким источникам честно говоря не помню, скорее всего по документации ОС ЕС или еще каким другим источникам. Давно это было. Работал я тогда в Челябинском военном училище штурманов.
Странно, что автор настолько против микросервисов, что делает странное утверждение "один выделенный сервер для одной задачи". Так может быть еще и делает какой-нибудь мелко-средний бизнес в своем частном ЦОД и на стареньких серверах. А нормальный тяжелый продакшн давно на кластере кубер (или там vSphere/HA) и сервера загружаются равномерно. Более того, с учетом производительности процессоров/дисков и географической близости к клиентам.
И даже хуже - на последних ядрах усиленно пилится возможность свой кастомный шедулер на ebpf организовать
Я в курсе микросервисов, но статья их вообще не касается. Да я мог написать "один выделенный сервер для одного сервиса", или по другому "один сервер под один сервис", имеяч в виду например БД на выделеном сервере, несколько экземпляров WebServer каждый на отдельно сервере с лоадбаленсером во главе. AD много экземпляров на отделеьны, выделеных сервер не важно on-prem или в облаке.
В противоположность этому хорошая манера и правило сочедать в одном zOS много разных серверов все вместе. Это хорошая пища для пищеварения WLM и для более эффективного использования, да не дешевых, но ресурсов МФ, который постоянно дешевеют и в целом могут запросто оказаться дешевле ИТ инфраструктуры на тысячах серверах и особенно в облаках. Кстати в компании где я работаю это уже отмечается.
Провокационный и странный заголовок. А не x86? ARM64, RISC-V, там какие-то другие ОС или не считается? А Линукс считается? А с оркестратором контейнеров на NUMA железе?
Не знаю зачем мне эта информация, но прочитал с интересом, спасибо.
Какие средства для автоматизации есть? Допустим ситуация - сгорел ЦОД со всем железом, надо в кратчайшие сроки восстановить инфраструктуру. Мы в другом ЦОДе ставим и подключаем железо, далее по PXE ставится ОС, ну а дальше через FluxCD, Ansible, Terraform и др. и прочее автоматически накатывается вся конфигурация. От человека кроме подключения железа требуется только нажать кнопку и вся инфраструктура восстанавливается. В статье было приведено большое количество различных конфигураций, есть возможность хранить её, например, в git-е, чтобы была версионность, история изменений, и не надо было звать того одного единственного человека, обладающего сакральными знаниями (вспоминаем про эффект автобуса)?
И второй вопрос про TCO (Total Cost Ownership), которая включает стоимость железа, но и стоимость найма сотрудника и прочее. Нет смысла покупать железо, которое во-первых сложно купить (способы купить железо IBM на территории РФ), во-вторых, найти специалистов, которые имеют опыт работы (на hh искать?) и в-третьих, не будет ли ситуация через 10-15 лет ещё хуже?
У нас, с начала нулевых вот такая "автоматизацмия была создана на случай" Disaster.
Начать правда необходимо с того что в самом МФ нет дисков С: с операционными системами и никогда не было. Системы сидят на внешних дисках. Отсюда следствие что если нам удалось сохранить диски то мы можем загрузить наши системы со всем установленным в них ПО где угодно на другом МФ.
Сохраняем мы диски зеркалированием в другой ЦОД. В Другом ЦОД-е у нас стоит другой МФ и его диски зеркалируются в первый для того же.
В случае "сгорел ЦОД со всем железом" я из моего котеджа на острове в озере Симко (Snake Island) захожу в HMC второго ЦОД-а, активирую LPAR (активирую, не создаю) для погибшей на первом ЦОД-е системы и загружаю ее. 10-15 мину. С теми же IP адресами. Сетевики переносят субнет в котором был сгоревший ЦОД на другой. Все пользователи перконекчиваются и продолжают работу. Это все. Никаких FluxCD, Ansible, Terraform и др. и никаких накатов не требуется.
Кстати системы с которыми мы работам изначально были построенны в 80-е годы и до сих пор целиком ни разу не переуставливались. Производились лишь последовательные апгрейды чере множество версий и релизов то текущих. Я сейчас вижу файлы созданные в каком-нибудь 1987 году.
И второй вопрос про TCO (Total Cost Ownership), которая включает стоимость железа, но и стоимость найма сотрудника и прочее. Нет смысла покупать железо, которое во-первых сложно купить (способы купить железо IBM на территории РФ), во-вторых, найти специалистов, которые имеют опыт работы (на hh искать?) и в-третьих, не будет ли ситуация через 10-15 лет ещё хуже?
Что касаемо TCO. Эту тему на Западе, в Америках бурно обсуждали лет 10-15 назад во времена наиболее активных боев за рынки. Сейчас это как то затихло. Наверное еще будет когда окажется что облачные техноглогий по факту дорогие.
Не раз на семинарах ИБМ слушал доклады на эту тему (кстати именно ИБМ эту тему и поднял тогда, когда из каждого утюга говорилось МФ стоит миллионы долларов на эти дентги можно купить миллион серверов х86). Вот тогда ИБМ и рассказал что покупка железа это еще далеко не все. И приводил нормальные исследования на нормальных т.е. реальных ситуациях, на 5 лет и показывал что ИБМ МФ может зачастую быть дешевле чем скажем Оракл на его (Sun) железе. Показывал кстати с Оракл же, но на МФ.
По поводу покупки на территори России ничего сказать не могу, но думаю все возможно. Ведь даже в годы холодной войны в СССР были ИБМ МФ. Это задача для ФСБ. Они все могут.
Специалисты появятся там где они будут нужны. Дайте мне предвыпускную группу любого университета Росси по любой технической, лучше электронной специализацией, и я за год преготовлю 10-15-20 специалистов на ИБМ МФ. Вы думаете когда появились первые компьютеры в СССР уже были специаоисты по ним? Первыми программистами были сами разработчики первых компьютеров.
Ситуация 10-15 лет вперед никто не знает какой будет. Но мне, кто прожил с наглосаксами, 26 лет кажется что если хоть как решится вопрос с Украиной все вернется на до СВО рельсы. И появится ИБМ. Но если сидеть сложа руки то через 10-15 лет вообще ничего не именится. Мне кажется готовиться к возврату ИБМ надо уже сейчас чтобы хотя бы знать что есть и может быть полезно для нас от ИБМ. На сегодня , как я понимаю, в Росии полностю потеряны компетенции в области ИБМ МФ в то время другие страны их эффективно используют там где они эффективны. А мы (я говорю "мы" потому что я россиянин, и даже российский пенсионер) даже не знаем где это можно/нужно использовать. Вот в чем проблема.
Чем различаются ОС IBM мейнфрейм и ОС х86