Comments 238
Ну 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 можно будет разместить на МФ десятки.
Вопрос №1 — производительность на каких задачах? И вопрос №2 —по каким критериям оценивать производительность (на одних и тех же задачах критерии могут быть разные, и по разным критериям разные системы выигрывают).
ИМХО сравнение «производительности» сродни известному упражнению с линейкой. Имеет смысл сравнивать стоимость решения одной и той же задачи в разных средах. Причём стоимость оборудования здесь дело шашнаццатое, а на первые позиции вылезут такие слабо формализуемые факторы как стоимость разработки/поддержки (скорость найма, кривая обучения, зарплаты) и стоимость поддержки (включая убытки от сбоев, где вообще сплошные вероятности).
Несколько сумбурно выражаетесь, уважаемый тезка. Так "производительность" или "стоимость" или "зарплата" или "поддержка" или "обучение". А "скорость найма" это что за зверь?
Задачи решаемые на МФ это в первую очередь информационные задачи с любым объемом данных. Это более менее детерминированые задачи, транзакционные, требующие высокой надежности, защищенности, доспупности. Копание в кучах информационного муссора с непредсказыемым результатом без какой либо ответственности за результат это не задачи для МФ, это для х86.
В наше время нет одного фактора (линейки), приложив который к той или иной платформе можно определить подходит это задаче или нет. Но беда в том что в нынешнем российском ИТ даже линейка не прикладывается к платформе ИБМ МФ. Их нет в Росси от слова совсем.
На Западе и на Востоке (Китай, Япония и уверен другие, да что там другие, наш "сосед" Украина к этому серьезнее относится чем мы:
Створення системного та прикладного програмного забезпечення для Mainframe, міграції застарілих систем на передові платформи та унікальні знання специфіки IBM Mainframe та інших комп’ютерних платформ.
Фахівці IBA Group мають великий досвід розробки, супроводу та технічної підтримки системних програмних засобів та прикладного програмного забезпечення на всіх платформах IBM (System z, System p, System i, and System x), а також на Sun SPARC.
Рішення на базі штучного інтелекту (Artificial Intelligence – AI), призначене для моніторингу та підтримки бізнес-додатків на z/OS.
Позор на мою седую голову. Дожил на старости лет.
Бизнес ставит перед ИТ задачи и предъявляет к решению ряд требований — функциональных и нефункциональных. Функциональные (какие виды документов и отчётов в системе, как из документов формируются проводки и т. д.) в данной теме нас не очень интересуют. А вот нефункциональные — да.
К нефункциональным требованиям относятся время разработки программы, затраты на поддержку, скорость выполнения транзакции, общее количество транзакций, время простоя системы и т. д., и т. п. Требования очень разнородные, сравнивать платформы по всем требования практически невозможно. Поэтому для сравнения все эти показатели приводят к одному — к деньгам.
Так вот, моя мысль заключается в том, что количество операций в секунду, выполняемых одним процессорным ядром, на итоговую оценку влияют достаточно слабо. Гораздо сильнее влияют другие факторы, не относящиеся напрямую к техническим особенностям платформы.
Думаю, что цена реализации нефункциональных требований на разных платформах может сильно отличаться...
Как говорится, и да и нет.
Как то Вы очень произвольно разделяется все на функционфально и нефункционфльное. Вообще есть другая классификация для ИТ: бизнес требования (это как раз про документы и их логику). И эксплуатационные требования к решению бизнес требований.
Ваше решение может быть прекрасно с точки зрения создателя, но совершенно не приемлемо с точки зрения бизнеса в его эксплуатации. По разным причинам не приемлемо, в том числе потому что железо на котором оно стоит не справляется с нагрузкой. Или решение стоит на сервере где стоит и другое и это другое монополизирует ресуры и не дает нормально функционировать первому.
Ни кому в голову не приходило расчитывать зарплату предприятия с 30 000 работников на персональном компьютере в 80-е, например, годы. А сечас, когда сервак на х86 имеет много высокопроизводительных процессоров, море памяти и дисков это запросто.
Так вот моя мысль тоже заключается в том "что количество операций в секунду, выполняемых одним процессорным ядром, на итоговую оценку влияют достаточно слабо. Гораздо сильнее влияют другие факторы, не относящиеся напрямую к техническим особенностям платформы.". Поэтому я и рассказывал про WLM, DFSMS и про то что МФ это не сервак, а, если хотите, минидатацентр, который может, на старщих моделях с полной комплектацией превратиться во вполне таки максидатацентр, а если их несколько то и вообще. Причем количество операционных единиц - имиджей ОС, виртуальных машин - будет по сравнению с решением на х86 в сотни, тысячи раз меньше, а надежность, защищенность, доступность на много выше.
Меньше операционных единиц это меньше затрат на персонал, лицензии, да и на электроэнергию, на площади тоже. Это 40 лет назад МФ стоял в машинных залах довольно на самом деле пустых. А сейчас это 19" стандартная стойка и в ней, даже при полной комплектации есть свободные U слоты в которые можно поставить switches, routers, etc....
Конечно дело в деньгах и здесь, по многочисленным исследованиям, МФ превосходить х86 уже давно. Более того, там где собственно МФ неэкономичен у ИБМ тоже давно есть решение zEnterprise, когда определенные нагрузки разгрузаются с МФ на х86 блэйды. Но есть более красивое решение проблемы экономики. Называется оно Specialty Engines (IFL, zIIP). Я про них еще не говорил, руки не доходили. но как вы поняли я с Вами послности согласен и утверждаю, да, дело в деньгах, в экономике. МФ это зачастую более экономичное решени с учетом всех факторов сопутствующих эксплуатации ИТ решений. И чем крупнее бизнес, его ИТ, тем больше эффект от экономии от использования МФ.
Еще во времена S/360 IBM стало развивать линейку middleware - S/36 и далее (до этого были S/32, S/34, после - S/38 и AS/400) - коммерческие сервера для малого и среднего бизнеса, тех, кому МФ избыточен. А когда дошло до AS/400, то выяснилось, что все это хорошо масштабируется и для крупного бизнеса. Это никак не конкурент МФ, а дополнение к нему.
Железо железу рознь. Насколько я слышал от людей, которые реально занимаются мэнфреймами, основная фишка там -- производительность 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... Правда, в те годы, наверное, китайцы ничего лучше не нашли (ну или иные причины были, не технического характера).
Ну а как выглядели... Крэй, например -- думаю, слыхали про такой. В первом приближении -- та же видюха, но без узлов, специфичных для графики (т.е. матричный процессор в более-менее чистом виде).
А что не просто много, а, пожалуй, основная масса алгоритмов толком не параллелится, я в курсе.
Вы путаете векторные процессоры и GPGPU (SIMD и SIMT). А насчёт алгоритмов – очень и очень многое великолепно параллелится, но просто не на GPGPU. Эти самые видеочипы – очень специфический продукт, подходит для довольно узкого круга задач (где у конкретно этих устройств высокий показатель FLOPS/Вт, и не требуются всякие глубокие конвейеры, AVX512 и прочие SVE). То, что сейчас их суют самосвалами в суперкомпьютеры, означает лишь только то, что приоритетным стал этот самый узкий круг задач, не более того.
удалено
Мне думается у ИБМ МФ еще будет ренесанс. Уж больно это, облака и клатеры на х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 рублей). И вовсе не по богатству сужу о собеседниках, а по их вдумчивости, спосности аргументировано спорить, отстаивать точку зрения и соглашать когда не правыми оказываются. Да не все знают о МФ. Это не секрет. Но плохо то что судят не зная, приписывают то чего нет и не слышат правду.
Уж куда мне, средневековому крестьянину из жопы мира понять белого человека.
О чем я и говорю: мы с вами в разных мирах живем.
Я совсем не это имел в виду. Я про эммиграцию говорил. Вы же не эммигрировали в другие страны надеюсь. Я бы тоже не эммигрировал, это был не мой выбор, или не по моей воле этот выбор был сделан.
Я рассказывал про DFSMS в Z/OS. Это фасилити помогающая прикладным програмам управляться в их большими данными. Под прикладными програмами я понимаю в том числе такую как DB2 for z/OS. В Линуксе как таковом ничего подобного нет.
Как мне представляется, x86 мир от этого не страдает. Вместо какой-то службы каталогов, помогающей найти хранилище данных (файл, датасет, не суть важно) по его коду SP.SMFDUMP.MVS0EA.D250 он использует файловые системы, позволяющие организовывать хранилища данных в иерархическую структуру и давать им имена длиной 255 символов Unicode. В общем, в x86 работу DFSMS делает файловая система.
Оракл в Линуксе управляет своей памятью на дисках сам, и все другим подобные приложения имеют свое решение для управления большими данными.
Файловая система в x86 мире обеспечивает физическое хранение данных, а уж чего с этими данными делать, решают сами программы. ОС в это дело не лезет. Зато она обеспечивает сохранность и быстродействие (всякие RAID, кеширование).
(я подчеркиваю это чтобы мне не говорили, мол, а игру не сможешь) пользуясь только возможностями z/OS. z/OS в его стандартной поставке имеет гораздо больше возможностей (facilities) чем тоже в виде Виндовз и Линукс.
Тут спорить не буду, вполне вероятно, что возможностей, в чем бы они ни заключались, z/OS предоставляет программам больше, чем ОС из мира x86. Но прогам из мира x86 возможностей этих ОС вполне хватает. Сеть? Пожалуйста. GUI? Пожалуйста. Графические навороты, чтобы игрушки делать? Пожалуйста. Я не слышал, чтобы кто-то из разработчиков плакал: "Вот какая пичалька! Я хочу сделать то-то и то-то, в z/OS я бы сделал это одной левой, а в Windows или Linux не могу! Ааааааа!!!"
активно используют эти z/OS-ские не изобретая каждый раз свои, например, системы секьюрити, управления опять же дисками и т.д. кластеризацией той же.
Так и проги в x86 мире не изобретают многие велосипеды заново, а пользуются теми, что им предоставляет ОС.
А что такого делают перечисленные процессоры что по Вашему процессору МФ не дано делать?
Вы меня не поняли. Или, вернее сказать, я тогда не понял вас. Этот абзац, если вы посмотрите, был ответом на ваш:
Но сервер на х86 остается сервером х86, Windows — Windows‑ом, а Unix — Unix‑ом.
Соответственно, он вопрошал, а в чем отличие z/OS от Windows или Linux в свете озвученного? Если то, что "х86 остается сервером х86, Windows — Windows‑ом, а Unix — Unix‑ом" - это ограничение мира x86, то, надо полагать, в z/OS такого ограничения нет. Значит, z/OS является одновременно многими сущностями, раз она противопоставляется тому, что в x86 мире проц архитектуры x86 "остается x86" и не может быть ничем иным, кроме как процом x86, Windows остается Windows, а Unix Unix. (Оставим за скобками такие детали, как WSL и Wine). Соответственно, я спрашивал: "А что, z/OS одновременно является многими типами возможных ОС, и архитектуру проца, на котором она работает, дает прогам тоже разную: хошь щас Power10, хошь на следующей инструкции x86?"
Да Вы и не один здесь россиянин из России.
Если подходить строго, то не один, верю. Какое-то количество нас тут есть. Но в общей массе, в процентном соотношении, нас тут мало. Тут подавляющее большинство либо из Москвапитера, либо из цивилизованного мира, как вы.
Я тоже россиянин, из Челябинска
Прошлое значения не имеет. Главное то, что сейчас, то, чего вы добились:
живу в Канаде
А то так-то про каждого тут можно сказать, что в прошлом он вообще разговаривать даже не умел и ходил под себя в памперс. Разве на этом основании можно говорить, что люди все равны по своим возможностям и своим достижениям?
Я не считаю себя, да и не являюсь, каким то богатым (у меня российская пенсия всего 15000 рублей).
Я полагаю, вы не станете всерьез сравнивать жителя Канады или любой другой современной цивилизованной страны с российским пенсионером, живущим в хрущевке на $100 в месяц?
Вы же не эммигрировали в другие страны надеюсь.
Абчом и спич. Вы же не считаете, что это сделать так просто, "стоит лишь только захотеть"? Это, на минуточку, дефолтное мнение обитателей рунета. "Чё ты такой бедный? Видимо, ты просто жопу от дивана оторвать не хочешь!" Мол, "оторви жопу" (c) и всё будет. Я в таких случаях задают вопрос: "Насколько высоко от дивана должен оторвать свою жопу 70 летний пенсионер из Костромы с пенсией $100 в месяц, чтобы получить возможность эмигрировать, скажем, в Канаду?" До сих пор внятного ответа на этот свой вопрос я так и не получил. Хотя спрашивал многих.
Насколько высоко от дивана должен оторвать свою жопу 70 летний пенсионер из Костромы с пенсией $100 в месяц, чтобы получить возможность эмигрировать, скажем, в Канаду?
Вот тут не надо передергивать. В 70 лет, понятно, делать уже что-то поздно.
Но. В 52(!!!) года я лично резко оторвал опу от дивана. Не до уровня "эмигрировать в Канаду", но поменял работу (хотя далось это тяжеловато). И резко поднял уровень своего благосостояния.
Знаю немало людей в своем окружении, кто сделал это в 30-35 лет. В т.ч. и тех, что уде имеет или ВНЖ или гражданство в европе.
Так что возможность таки есть. Но думать про это надо не в 70 лет, это совершенно точно.
Я не слышал, чтобы кто-то из разработчиков плакал: "Вот какая пичалька! Я хочу сделать то-то и то-то, в z/OS я бы сделал это одной левой, а в Windows или Linux не могу! Ааааааа!!!"
А много вы знаете разработчиков, кто серьезно бы МФ, а потом вернулся бы на Вин/Линукс? Для решения схожих задач...
Я с МФ не работал, работаю с middliware от IBM - IBM i (AS/400). И могу сказать, что в АСке возможностей для разработчика намного больше (и под вин и под линукс работал долго до АСки).
К примеру, достаточно активно используем системные очереди для организации разного рода конвейеров для распараллеливания обработки больших объемов данных. Ни в винде ни в линуксе ничего близко похожего нет.
Есть "очереди сообщений" куда я из программы могу откидывать какие-то трейсы и видеть что там происходит в реальном времени. Опять - в мире вин и линукс такого нет.
Также нет ведущихся системой для каждого задания joblog. Где видно все, что в этом задании происходило. Включая ошибки, исключения и т.п. - если программа упала, то там будет видно почему упала и где именно упала.
Нет системных журналов где журналируются все изменения объектов. На уровне системы. Автоматом. У нас на них работают т.н. "журнальные мониторы" которые отслеживают и анализируют изменения и выполняют необходимые действия.
И такого очень много. И, подозреваю, что на МФ тоже много подобных вещей.
И, подозреваю, что на МФ тоже много подобных вещей.
Гораздо больше чем можно даже подозревать. Я 25 лет плотно работаю с z/OS, делал апгрейды, переводил с одного МФ на другой, и не могу сказать что знаю все, наоборот говорю многого не знаю.
Например, DFSMS у нас даже организационно был в другой группе и там было два человека которые занимались только DFSMS и физической сторадж для МФ. Сейчас их нет и мне приходится по инцидентам работать с DFSMS и я восхищаюсь этим разделом z/OS (вот я и сказал это слово "восхищаюсь").
вот я и сказал это слово "восхищаюсь"
Ну вот мне АСка тоже очень нравится. И возможностями своими и тем, что она предоставляет разработчику и своей логической и идеологической целостностью и понятностью (сначала непривычно все, начиная от файловой системы которая там вообще не похожа на вин/линукс и концепцией "все есть объект", потом, когда чуть вникнешь в основы, дальше уже все просто и логично ложится одно на другое без зазоров).
И обратно в тот зоопарк вин/линукс я уже точно не хочу (и, надеюсь, не придется уже). Именно в плане разработки.
Но. В 52(!!!) года я лично резко оторвал опу от дивана. Не до уровня "эмигрировать в Канаду", но поменял работу (хотя далось это тяжеловато). И резко поднял уровень своего благосостояния.
Насколько я понимаю, в ваши 52 ваша опа имела хорошую репутацию. Поэтому ей не трудно было "резко поднять уровень своего благосостояния". Я спрашиваю для 70 летних, ибо не хочу их игнорировать. Сам я пишу выше, что нас по признакам дохода и возраста не считают за людей. Поэтому сам я такой подход не применяю. Но я с большим интересом послушаю инструкцию, как 52 летнему пенсионеру из ужгородской хрущевки перебраться в Ванкувер.
Знаю немало людей в своем окружении, кто сделал это в 30-35 лет.
Надо так понимать, что тех, кто этого не сделал, вы знаете гораздо меньше. Ну, у, скажем, Потанина в окружении тоже преобладают те, "кто смог", чем те, "кто не смог".
Так что возможность таки есть.
Для людей из окружения Потанина, несомненно. Для людей, кому родственники оставили пару квартир в центре Москвы, несомненно. Для многократных победителей ICPC, несомненно. А других в вашем мире, полагаю, нет, так что далее не спрашиваю.
Вместо какой-то службы каталогов, помогающей найти хранилище данных (файл, датасет, не суть важно) по его коду SP.SMFDUMP.MVS0EA.D250 он использует файловые системы, позволяющие организовывать хранилища данных в иерархическую структуру и давать им имена длиной 255 символов Unicode. В общем, в x86 работу DFSMS делает файловая система.
DFSMS это не файловая система. Каталоги в z/OS и длина имени (не кода) в 44 байта это еще до DFSMS было. Вот первый абзац из первого документа z/OS
Имена длиной до 255 символом это не есть великое достижение и врядли на самом деле используется. А когда используется то это что-нибудь составное из даты, времени и еще каких-нибудь атрибутов которые на самом деле могли бы быть реализованны иначе, но увы иначе не предусмотренно.
Наборы данных в z/OS это не наборы байтов. Есть конечно и такие. А есть и наборы данных с стандартной, поддерживаемой файловой системой (! не DFSMS), структурой. Например наборы данных Unix System Services (компонеты z/OS), в которых живет иерархическая файловая система Unix с именами файлов длиной до 255 символов Unicode.
Иначе говоря, то что вы считаете в х86 делает работу DFSMS на самом деле есть частный случай файловой системы z/OS, а точнее является фацловой системой Юникс в наборах данных z/OS.
А что же тогда DFSMS есть? В комментариях и даже в одной статье это не расскажеешь. Приведу лишь вступление к списку документов DFSMS (перевод сделан через Google транслятор):
DFSMS состоит из одного элемента z/OS (DFSMSdfp) и четырёх функций z/OS (DFSMSdss, DFSMShsm, DFSMSrmm и DFSMStvs).
DFSMSdfp предоставляет функции управления хранилищем, данными, программами и устройствами.
DFSMSdss — это инструмент управления данными и пространством DASD (дисков -zVlad909). DFSMShsm — это инструмент управления хранилищем DASD и повышения производительности для управления данными с низкой активностью и неактивными данными.
DFSMSrmm помогает управлять съёмными носителями (лентами, оптикой - zVlad909) как единой корпоративной библиотекой в системах z/OS, которые могут использовать как общий DASD, так и подключение по TCP/IP.
DFSMStvs (транзакционные службы VSAM) позволяет использовать пакетные задания и онлайн-транзакции CICS для одновременного обновления общих наборов данных VSAM.
А вот список документов в библиотеке DFSMS (это не брошюрки, не статьи это солидные объемные документы. Пробегитесь по названием и скажите что Вам кажется делает ч86 файловая система. Спасибо):
SC23-6846-50 z/OS DFSMS Access Method Services Commands
SC23-6847-50 z/OS DFSMS Advanced Copy Services
SC23-6848-50 z/OS DFSMS DFM Guide and Reference
SC23-6849-50 z/OS DFSMS Implementing System-Managed Storage
SC23-6850-50 z/OS DFSMS Installation Exits
SC23-6851-50 z/OS DFSMS Introduction
SC23-6852-50 z/OS DFSMS Macro Instructions for Data Sets
SC23-6853-50 z/OS DFSMS Managing Catalogs
SC23-6865-50 z/OS DFSMS OAM Application Programmer's Reference
SC23-6866-50 z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Object Support
SC23-6867-50 z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Tape Libraries
SC23-6854-50 z/OS DFSMS Software Support for IBM System Storage TS1140, TS1130, and TS1120 Tape Drives (3592)
SC23-6855-50 z/OS DFSMS Using Data Sets
SC23-6858-50 z/OS DFSMS Using Magnetic Tapes
SC23-6856-50 z/OS DFSMS Using the Interactive Storage Management Facility
SC23-6857-50 z/OS DFSMS Using the New Functions
SC23-6859-50 z/OS DFSMS Using the Volume Mount Analyzer
SC23-6861-50 z/OS DFSMSdfp Advanced Services
SC23-6862-50 z/OS DFSMSdfp Checkpoint/Restart
SC23-6863-50 z/OS DFSMSdfp Diagnosis
SC23-6860-50 z/OS DFSMSdfp Storage Administration
SC23-6864-50 z/OS DFSMSdfp Utilities
SC23-6868-50 z/OS DFSMSdss Storage Administration
GC14-7504-50 z/OS DFSMShsm Data Areas
GC52-1387-50 z/OS DFSMShsm Diagnosis
SC23-6869-50 z/OS DFSMShsm Implementation and Customization Guide
SC23-6870-50 z/OS DFSMShsm Managing Your Own Data
SC23-6871-50 z/OS DFSMShsm Storage Administration
SC23-6872-50 z/OS DFSMSrmm Application Programming Interface
SC23-6876-50 z/OS DFSMSrmm Diagnosis Guide
SC23-6874-50 z/OS DFSMSrmm Implementation and Customization Guide
SC23-6873-50 z/OS DFSMSrmm Managing and Using Removable Media
SC23-6875-50 z/OS DFSMSrmm Reporting
GC52-1388-50 z/OS DFSMStvs Administration Guide
SC23-6877-50 z/OS DFSMStvs Planning and Operating Guide
Имена длиной до 255 символом это не есть великое достижение и врядли на самом деле используется. А когда используется то это что-нибудь составное из даты, времени и еще каких-нибудь атрибутов которые на самом деле могли бы быть реализованны иначе, но увы иначе не предусмотренно.
В АСке имя объекта, а там все есть объект - и файл (хотя *FILE это просто один из типов объектов) и библиотека (аналог папки в винде) вообще ограничено 10-ю символами. Но у каждого объекта есть свойство TEXT - 50 символов произвольного текста куда можно писать все что угодно (и оно редактируемое).
Имена длиной до 255 символом это не есть великое достижение и врядли на самом деле используется.
Дело не в том, что надо обязательно использовать все 255 символов для имени, а в том, что такая возможность есть. А главное, есть возможность создавать папки, и потому путь к файлу может быть длиной в несколько тысяч символов. Вы тоже скажете, на практике такая длина пути встречается редко, но тем не менее, это позволяет обойтись без отдельного списка (и сервиса, этот список поддерживающего), сопоставляющего реальное имя файла SP.SMFDUMP.MVS0EA.D250 и более человеко-ориентированное название.
Вы мыслите в рамках вин/линукс. И заперты в этих рамках.
Дело не в том, что надо обязательно использовать все 255 символа для имени, а в том, что такая возможность есть. А главное, есть возможность создавать папки, и потому путь к файлу может быть длиной в несколько тысяч символов. Вы тоже скажете, на практике такая длина пути встречается редко, но тем не менее, это позволяет обойтись без отдельного списка (и сервиса, этот список поддерживающего), сопоставляющего реальное имя файла SP.SMFDUMP.MVS0EA.D250 и более человеко-ориентированное название.
Ок. Вы хороший собеседник, задаете вопросы, отвечая на которые мне сподручнее объяснить некоторые моменты, кторые иначе объяснять труднее. Иначе говоря, спасибо за вопрос.
Начну с того что мне не только хороршо известно устройство файловых систем в Unix, Linux, но я с ними много и плотно работал и сам мог бф рассзать про папки (folder) и пути (path).
Более того в языке JCL (Job Control Language) в операторе DD описывающих данные модно не только написать //<имя DD> DD DSN=SP.SMFDUMP.MVS0EA.D250, но и //<имя DD> DD PATH='/SP/SMFDUMP/MVS0EA/D250'. Программа выполняемая в этом задании с этим DD выполнится одинаково без изменения программы.
Это так шашечки. Вам наверное хорошо известно что каждая работа в Линукс/Юникс запускается из того или иного шелл. Запускается она из того или иного профиля с его home directory, в котором лешит файл .profile и в этом файле есть утверждения типа (оставим контейнеры и Docker пока в стороне):
PATH=/bin;/sbin;/usr/lpp/java/.....
$JAVA_HOME=/...
$WEB_SPHERE_HOME=/...
и т.д, и т.п.
Все эти Номе и Путь настраивают на определенную конфигурацию в системе где это выполняется. Причем в разных профилях эти номе и пути могут указывать в одни места, в других в другие (разные копии одной и той же версии чего то или разные версии этого). И вот вы решили навести порядок. Понимаете как это будет происходить? Конечно понимате.
В случае системного каталога в z/OS если, например, у нас есть супер важный файл (набор данных) с именем F1, используемый в куче мест как системными прогами так и пользовательскими, и он находится на томе ZOS111. F1 закаталогизирован и поэтому ссылаться на него можно просто по имени. (В системе на разных томах, кроме ZOS111, могут существовать другие F1, но чтобы использовать их надо указывать и имя тома ).
И вот мы решили переместить F1 c ZOS111 на ZOS222. Используем соответствующую утилиту DFSMS. Утилита проверит есть ли что в системе использующее F1 и если да то закончится неуспешно. Мы можем легко найти всех кто использует F1 и "попросить" их на время остановиться. Снова запускаем утилиту. Утилита залокает F1, чтобы никто не мог запросить к F1 доступ, скопирует на ZOS222, раскаталогизирует F1, удалит F1 с ZOS111, закаталогизирует F1 на ZOS222, разлокирует F1. Завершит выполнение.
Все кому надо F1 c этого момента будут брать его с ZOS222, не трогая своих настроек.
Мы примерно также можем изменить имя файла F1 на F2 и создать в каталоге алиас F1 к F2 и наши пользователи теперь обращаясь к F1 будут иметь дело с F2. В Юникс Линукс это тоже есть SYMBOL, LINK, но надо быть осторожным потому что один и тот же SYMBOL в разных директориях будут могут указывать на разные физические пути и файлы. Иными словами работая в Юникс, Линукс надо быть очень аккуратным, но всегда есть место ошибки которую с ходу можно и не заметить, но она может оказаться чревата очень плохими последствиями. В z/OS с каталогами эта проблема сведена до минимума.
SP.SMFDUMP.MVS0EA.D250713 это реальное имя и оно означает следущее:
SP это High Level Qualifier используемый системным администратором для обслуживания системы. Это HLQ защищен от использования, с ним можно создавать имена только авторизованными пользователями. При этом читать эти наборы в ощем случае могут все. А могут и нет.
SMFDUMP означает что это дамп System Monitoring Facility.
MVS0EA имя z/OS на которой этот дамп был создан 13 июля 2025 года, т.е есть вчера.
Больше про этом НД ничего сказать нельзя и не нужно. И так на самом деле имеет место быть для всех наборов данных.
Еще пример. НД с именем OMVS.V1R13.ROOT это НД USS (по традиции называем от Open MVS - предыдущее название USS) создан он z/OS версии 1 релиза 13 (почему это важно что одновременно в системе могут быть и НД других релизом, как правило в процессе перехода от одного к другому). И понять что этот НД содержит root "/" directory.
Или еще WAS700.JAVA.ZFS это directory WebSphere 7.0.0, а именно Java фолдер с фолдером bin. Тип файлой системы в этом НД - ZFS.
При наличии навыка можно называть НД так что не понадобится их имена расшифровывать дополнительно.
Вы хороший собеседник, задаете вопросы,
Спасибо, вы тоже.
Но предыдущий ваш коллега не выдержал масштаба моей неоторванной жопы и теперь минусы ставит. А ведь тоже всё хорошо начиналось...
Начну с того что мне не только хороршо известно устройство файловых систем в Unix, Linux, но я с ними много и плотно работал и сам мог бф рассзать про папки (folder) и пути (path).
Я в этом ни секунды не сомневаюсь и не сомневался.
Вообще, вся моя серия этих постов, помимо нарисовавшегося социального аспекта, прежде всего пытается донести такую мысль: мейнфреймы IBM хороши, спору нет, но тотального и неоспоримого преимущества над компами архитектуры x86 они не имеют. Ни в аппаратной, ни в софтверной части. А главное, они существенно дороже. Поэтому клиенты чаще выбирают IT-инфраструктуру на решениях Intel и AMD, а не выстраиваются в очередь за мейнфреймами IBM. За те же деньги они получают больше вычислительной мощности, и не проигрывают ни в надежности, ни, тем более, в быстродействии.
Вот "не проигрывают" - тут не факт.
Тут скорее другая логика - "мы сейчас купим подешевле, если что - потом докупим". А "потом" выясняется что надо вваливать еще и еще, но соскочить на что-то другое получится еще дороже. А результате выбор между "вложиться сразу и потом долго пользоваться" и "вкладываться постоянно и в результате заплатить больше, но потом". Плюс инертность мышления - x86 так или иначе знакома и понятна всем, а МФ это что-то такое страшное и непонятное.
Да и деньги считать тут далеко не все умеют. Основная часть крупняка сидит на господдержке, а там "сколько надо, столько и дадут из казны". Это тоже существенное отличие.
Ну и основное - далеко не всем нужны МФ. И даже Middleware решения нужны далеко не всем. Большей части действительно хватает обычных серверных решений.
Я бы еще добавил что ни в одном ВУЗе России нынче не дают Z System. Максимум бегло перечисляют вместе с DEC, VAX, PDP мол было и нет уже.
Соответсвенно просто некому и нечем даже подумать в сторону Z.
Компетенция в области IBM Z в России полностью утеряна. Это очень плохо. Она вобщем то деградировала задолго до СВО и ухода ИБМ из России.
Возможно где-то и стоят несколько экземпляров, но никакого развития там нет, просто крутят старые приложения и потихоньку переводят их на х86.
Полагаю с AS-400 та же история.
С АСкой работают как минимум Альфа Банк (+ Альфа-Страхование , +Альфа Банк Беларусь), Райффайзен, Росбанк и Ак-Барс Банк.
Плюс есть вендоры, которые умеют под нее писать - BTC, Cinemex, RMSLab (может еще кто-то).
Так что ту с компетенциями не так все плохо. Мы (Альфа) каждый год проводим IBM i DevConf - гостей хватает.
Кто умел под Z - точно Luxsoft, но они ушли вроде...
Я не минусов, ни плюсов не ставил здесь на Хабре, за исключением плюса "моему коллеги" за фразу, которую я с удовольствием воспроизведу здесь: "Профессионал не тот, кто умеет писать хороший код, а тот, кто не умеет писать плохой."
.....тотального и неоспоримого преимущества над компами архитектуры x86 они не имеют. Ни в аппаратной, ни в софтверной части.
Это завит от как смотреть на преимущества. Как говорил один мой друг, бывший "на вкус и цвет все фламастеры разные". Это шутка конечно.
Я наверно плохо умею доносить до других прописные истины. Каюсь. Пишу много, но видимо не то. Но и у Вас, уважаемый, с эти тоже проблемы. Надо бы хоть немного пробовать обосновывать свои утверждения.
Вот помню был у меня один оппонент на другом форуме. Сам он, как и Вы, с МФ и z/OS не работал, но хотя бы находил на интернете статьи с некоемыми исследованиями показывающими на экспериментах что, как Вы пишите "...тотального и неоспоримого преимущества над компами архитектуры x86 они не имеют. " И я мог ему объяснять что в этих исследованиях передергивание, а что и просто ложь.
Вы меня такой возможности лишили и думаете что просто сказав "...тотального и неоспоримого преимущества над компами архитектуры x86 они не имеют. " Вы успешно выполнили свою миссию: поставили на место странного пришельца из канады, пытавшегося обмануть аудиторию Хабр вражескими, подрывными действиями. Проще говоря пытавшегося "..запудрить нам, истинным знатокам ИТ, мозги и покачнуть нашу веру во всемогущество и вечную верность учений Intel и Microsoft."
А главное, они существенно дороже.
В том то и дело, не коллега, что при всем при том о чем я писал в этой статье решения на МФ существенно дешевле.
Нет, если вы говорите о 1С Бухгалтерия для СПА салона, пусть даже в Москве, или сервере ИП "Иванов и сыновья" для хранения их белой и серой книги учета движения склада в соседней с кабинетом директора комнате, то Вы правы дешевле х86 сервак, да что там сервак, лаптопа достаточно.
Но если Вы посмотрите на что-нибудь более крупное (не знаю на что у Вас есть возможность посмотреть я вижу ИТ большой энергитической компании провинции Онтарио) и возьмете в руки калькулятор и посчитаете сколько стоит ИТ в Azure и сравните с ИТ для этого же бизнеса на МФ, вот тогда нам будет о чем поговорить.
А пока рекомендую погуглить на тему TCO (Total Cost of Ownership) разных платформ, включая МФ. Я таких много видел. И уже давно все понял.
P.S. По крайней мере я вижу что с переходом с МФ на Azure в этой моей энергитической компании многократно выросла численность занятых в ее ИТ. При этом на пока еще живых двух МФ есть ровно и только одна единица на все что связано с МФ в текущей эксплуатации. И у меня нет DevOps, нет Кубернетес, нет кластеров, нет Dockers, нет "автоматизации". Я все успеваю делать своей головой и руками. При этом еще полностью закрываю тему репликации Продкшн и QA из Оракл в MS SQL их ERP класс приложения.
Это всё в принципе верно, но в России, как говорится, есть своя специфика. Та же самая упомянутая вами 1С, в версии 1С:Корпорация – это довольно серьёзный продукт, который, например, поддерживает конфиденциальный документооборот, защищённый по российским стандартам безопасности. А IBM МФ, по понятным причинам, построен на американских стандартах (т.е., условно говоря, мастер-ключи находятся в АНБ). Call Home в IBM тоже можно вспомнить тот же самый (он и у PC серверов IBM есть). И так как МФ представляет собой именно единую аппаратно-программную систему, то выковырять из её недр какие-то основополагающие вещи и заменить другими оказывается довольно непросто. Это не недостаток платформы МФ как таковой, а особенность локализации вендорских систем.
мастер-ключи находятся в АНБ
Можно поподробней про это. Я занимался encryption на МФ в z/OS. Давненько правда, ни про какие мастер ключи не знаю, не читал, не слышал. Спасибо.
P.S. Cаll номе не обязателен. Мы уже третий год живем без него, и раньше было. Точнее у нас больше не было чем было это. И что интересно, у нас серьезные проблемы происходили именно тогда когда Call Home не было. В начале 2000-х Call Home был на модем по номеру телефона, и был случай когда он сработал по ошибке памяти. Потом его сделали через интернет и надо долго уговаривать руководство чтобы дали IP и прокси сервер для выхода. Потом прокси поменяли и нам не сказали, а в это время был сбой. Узнал я про этот сбой случайно. Когда у нас начался ежегодный DR test и оказалось что оба Support Elements are down. Более того уже давно.
Ну я метафорически пишу. В России принято считать, что американские алгоритмы шифрования криптографически уязвимы, так как использованные в них случайные последовательности не случайны. Не моя тема и не готов предметно дискутировать, но важен вывод. Доверенными считаются только алгоритмы ГОСТ.
Про Call Home я знаю, что он не обязателен, он у нас выключен. Но кто поручится, что он сам не включится? Сервисную сеть, конечно, для этого надо шлюзовать в интернет, но тем не менее...
Ну я метафорически пишу.
ИТ это не эзотерика. В ИТ не должно быть использоваться метафоричность.
А какие еще алгоритмы могут нынче использоваться если не американские? Ну и причем здесь алгоритмы, если результат их работы определяется не самим алгоритмом, а некой валюнтаристически произведенной случайной последовательностью. Не нравится вам встроенный генератор случайных последовательностей, замените его своим. Взломайте этот генератор в конце концов.
А происхождение алгоритмов ГОСТ Вам известно? Я бы лично не доверял ни тем ни другим доведись мне быть ответственным за безопасность чего-нибудь серьезного.
Про Call Home я знаю, что он не обязателен, он у нас выключен. Но кто поручится, что он сам не включится? Сервисную сеть, конечно, для этого надо шлюзовать в интернет, но тем не менее...
Тем не менее в таких вопросах не аргумент. Если Вы выключили лампочку, то что вы не уверены в том что ее можете включить только вы, а не кто-нибудь другой?
Все физические связи МФ (и я полагаю IBM PC servers) проложены в ДЦ пользователя. Сетевики подьзователя точно знают как далеко простираются эти физические связи и что их ограничивает.
В случае МФ выход в Интернет идет с HMC (Hardware Management Console). HMC связывается с Support Element стоящий внутри МФ через локальную коробочку, называемую инженерами ИБМ Hub. Уберем этот HMC, уберем Hub, выключим оба SEs. Системы на МФ продолжат работать как ни в чем не бывало. Системы, для выхода в сеть пользователя не используют ни SEs ни HMC. Они используют OSA сard. И это еще не все. Но хватит.
Короче то что Вы пишите это параноя. И ссылка на ГОСТ это не оправдывает.
Ну вы там на своём Американском континенте несколько варитесь в собственном соку, а так вообще за пределами западных стран алгоритмы шифрования у всех свои. В России это ГОСТ Р 34.12-2015.
Я слышал, что китайцы вроде бы даже продавили IBM встроить свой национальный алгоритм в Z, но официальных подтверждений этому не видел.
ИТ это не эзотерика. В ИТ не должно быть использоваться метафоричность.
Ну уж извините, я сам как-нибудь решу, что у меня должно, а что не должно использоваться.
Не надо вставать в позу пророка, решившего донести до неверных свет единственной истины. Я сам, допустим, сертифицированный эксперт IBM по нескольким направлениям, но это не значит, что я считаю правильным всё, что делает IBM. И чем дальше, тем там всё запущеннее.
А происхождение алгоритмов ГОСТ Вам известно? Я бы лично не доверял ни тем ни другим доведись мне быть ответственным за безопасность чего-нибудь серьезного.
Если вам доведётся быть ответственным за безопасность чего-нибудь серьёзного, вам придётся использовать то, что предписывает лицензирующий орган. И никак иначе. В противном случае, как минимум, лицензии вам не видать, а как максимум, можно и присесть.
Не нравится вам встроенный генератор случайных последовательностей, замените его своим.
Частью алгоритма шифрования является определённая якобы случайная константа. В этом и фишка.
Короче то что Вы пишите это параноя.
Ну конечно, надо верить в добрую волю АНБ :)
Даже несчастный Telegram использует свою собственную криптографию, настолько уже нет веры дефолтным алгоритмам.
Но суть-то даже не в том, паранойя это или не паранойя, а в том, что это закон. Даже безобидные персональные данные (то есть ФИО и т.п.), строго говоря, запрещено в России шифровать американскими алгоритмами.
И я, кстати, ничего не утверждаю, но обострилось это всё после того, как приютили в России товарища Эдуарда Лоннивича Сноудена. Хотя может быть и случайное совпадение.
Ну вы там на своём Американском континенте ...
Пока Вы писали Ваш ответ я отредактивал свой. Советую ознакомится с новой, дополненной, редакцией.
Ну я, допустим, тоже отредактировал.
Я прочитал Вашу новую редакцию.
Если вам доведётся быть ответственным за безопасность чего-нибудь серьёзного, ....
У меня с 2006 на всех системах МФ есть уровень доступа RACF Special (введите в Гугл или поверьте что это самый высокий уровень доступа на МФ в z/OS). У меня есть и другая квалификация в области безопасности, не компьютерная.
В СССР я почти всегда после института имел "форму допуска" и посещал суперсекретные объекты.
Т.е. я знаю о чем я говорю, говоря.
В противном случае, как минимум, лицензии вам не видать, ...
О какой лицензии речь?
Даже несчастный Telegram использует свою собственную криптографию, настолько уже нет веры дефолтным алгоритмам.
Что Вы знаете про "свою собственную криптографию" Telegram?
Нет у них никакой собственной криптографии, у них все как на Западе. А то что его прижали готовирит как раз о том что АНБ не всесильно. И нет у них никаких мастер кийс. Их нет в природе.
У меня с 2006 на всех системах МФ есть уровень доступа RACF Special (введите в Гугл или поверьте что это самый высокий уровень доступа на МФ в z/OS). У меня есть и другая квалификация в области безопасности, не компьютерная.
Ну вот попробуйте зашифровать данные в своей фирме российским или китайским алгоритмом и посмотрите, что вам скажут. Хотя этого просто RACF не позволит.
В СССР я почти всегда после института имел "форму допуска" и посещал суперсекретные объекты.
Это было очень давно, тогда компьютерной безопасности вообще не было как явления. Хотя из этого опыта уже должно быть понятно, что необходимые меры по защите информации в целом определяются приказом, а не по личному разумению.
О какой лицензии речь?
Любая деятельность в области защиты информации в России лицензируется.
Цепочка тут такая. Допустим, у вас в России есть Z мейнфрейм. Слава богу. Но раз этот МФ не умеет сам по себе шифровать по ГОСТу, то он не является средством защиты информации с точки зрения российского права, и, соответственно, не может получить сертификат как СЗИ. А раз у него нет такого сертификата, то с его помощью запрещено шифровать конфиденциальные данные. Хотя можно было бы поставить на него дополнительное шифрующее по ГОСТу приложение, но это тогда сломает архитектуру z/OS.
Что Вы знаете про "свою собственную криптографию" Telegram?
Нет у них никакой собственной криптографии, у них все как на Западе.
Насколько мне известно, в Telegram используется свой собственный криптографический алгоритм, разработанный братом известного Дурова (этот брат, кстати, спокойно работает в России в институте математики им. Стеклова, и по внешнему виду гораздо больше смахивает на программиста, чем известный Дуров).
Насколько мне известно, в Telegram используется свой собственный криптографический алгоритм, разработанный братом известного Дурова (этот брат, кстати, спокойно работает в России в институте математики им. Стеклова, и по внешнему виду гораздо больше смахивает на программиста, чем известный Дуров).
И это всЁ? А Вы знаете сколько разных алгоритмов вообще существует и используется? А Вы думаете что вот так просто посмотрев на трафик можно определить какой из них был использован в данном конкретном случае, типа там в некоем заголовке написано: "использован алгоритм брата Дурова, который не похож на программиста, но почему то Telegram это его собственность." Так что ли?
Если вы дадите себе труд обратиться к поисковому серверу с запросом, то легко сможете найти и общее описание криптографического алгоритма Телеграма, и специальные статьи по криптографии, обсуждающие свойства этого алгоритма и его отличие от других.
А в том, почему один из братьев похож на программиста, а другой является собственником кода, я лично не вижу никакого противоречия. Было бы удивительно наоборот. Вроде только Гейтсу удалось совмещать, и то недолго.
Ну вы там на своём Американском континенте несколько варитесь в собственном соку, а так вообще за пределами западных стран алгоритмы шифрования у всех свои. В России это ГОСТ Р 34.12-2015.
Хорошо, пусть так. Объясните следущее. У меня есть смартфон. Он куплен и жил только на "Американском континенте". Он зарегистрирован в системе компании где я работаю. Т.е. всячески проверен.
Вопрос: Почему я успешно инсталлировал и использую приложение Госуслуги на этом смартфоне. Он у меня что знает про ГОСТ Р 34.12-2015?
Другой мой смартфон имеет две СИМки, российские. Я их использую для звонков по России, получения SMS от Госуслуг, Сбербанка через Wi-Fi Calling. на нем стоит приложение Authenticator Pro for two factor authorization с Госуслугами.
Как это все может сочетаться с тем что де в России все конфеденцифировано по ГОСТу? Что у нас на американском континенте тоже используют ГОСТ?
Добавлю. Будучи год назад в России я практически ничнго канадского достать не мог. Ни компанию, которую мог бы достать в сотне километров от места где был в России, но не из того российского места где я был. Только мой канадский банк давал мне доступ. А другой банк не давал.
Речь идет конечно не o с VPN. Боюсь сейчас я и к моему банку не смогу присоединяться из России. А вот наоборот пожалуйста. Получается мне сейчас удобнее жить в Канаде откуда у меня есть доступ к России. Чем в России откуда доступ к Канаде закрыт. А я хотел бы наоборот. Получается Канада это какашка. Так оно и есть на самом деле.
Это конечно здорово что Россия не ведет себя как гопники канадские. Но мы про другое сейчас.
Потому что приложение Госуслуги шифрует по ГОСТу своими собственными силами, и не пользуется для конфиденциальных данных вызовами крипто-API операционной системы смартфона. Точнее, там есть определённые уровни аутентификации – для каких-то функций можно обойтись без сильного шифрования, а для каких-то нельзя. Для вторых ещё устанавливается специальное криптоприложение Госключ.
Что касается доступа к канадскому банку. Насколько мне известно, в США действует государственный файрвол для фильтрации российских адресов при доступе к государственным американским серверам. Возможно, тут что-то подобное. Не очень понял, какое отношение политика фильтрации имеет к предыдущей теме.
В России есть подобная система ГОССОПКА для защиты государственных сайтов, но она действует более хитро, не просто банит адреса. Поэтому в принципе работать с большинством российских сайтов из-за рубежа можно, пока ваши действия не покажутся роботу злонамеренными.
Походу Вы не держали в руках компьютерные системы безопасности. Терминология Ваша явно хромает. Я могу ошибаться, но это то что я чуствую, метафорически.
Насколько мне известно, в США действует государственный файрвол для фильтрации....
Не очень понял, какое отношение политика фильтрации имеет к предыдущей теме.
Канада и США это две разные страны. Канада это не 51 штат США. Ау, гараж.
В файрволах нет такой опции "filter". Есть "permit" (разрешать) or "deny" (отказывать).
Отношение имеет то как относится Канада к Росси и как Россия к Канаде. Для Канады Россия лютый враг. Россия этого не замечает. И зря.
Канада и США это две разные страны. Канада это не 51 штат США. Ау, гараж.
Если Канада – это не 51 штат США, тогда непонятно, почему она не обладает атрибутами государственного суверенитета в сфере защиты информации – например, не применяет собственные алгоритмы, отдельные от США.
В файрволах нет такой опции "filter". Есть "permit" (разрешать) or "deny" (отказывать).
Эта функция по-русски называется "фильтрация трафика". Насколько мне известно, она и по-английски называется traffic filtering. Удивительно, что этот термин вызывает у вас вопросы, если вы профессионально занимаетесь безопасностью (в отличие от меня).
Отношение имеет то как относится Канада к Росси и как Россия к Канаде. Для Канады Россия лютый враг. Россия этого не замечает. И зря.
Я не думаю, что на бытовом уровне должна учитываться какая-то особенная специфика отношения Канады по сравнению с отношением США. Но, слава богу, это вообще не предмет моих размышлений.
Если Канада – это не 51 штат США, тогда непонятно, почему она не обладает атрибутами государственного суверенитета в сфере защиты информации – например, не применяет собственные алгоритмы, отдельные от США.
Потому что не в алгоритмах дело. Вы мне так и не объяснили почему мой канадский смарт может быть аутентифицирован на сайте Госуслуг.
Эта функция по-русски называется "фильтрация трафика". Насколько мне известно, она и по-английски называется traffic filtering. Удивительно, что этот термин вызывает у вас вопросы, если вы профессионально занимаетесь безопасностью (в отличие от меня).
Занимался, лет десять назад. Но помню кое что. Ну а раз Вы не занимаетесь, то зачем ввязываетесь в дискуссию об этом?
Anyway.
Функция фильтрации Traffic Filtration это всего лишь предварительная стадия в алгоритме файрвол. Ну да мы отфильтровали трафик. Причем трафик фильтруется гораздо больше чем типа Россия, не Россия. Что дальше? А дальше файрвол должен решить permit or deny ( To Be or Not to Be).
На вашей ссылке:
В конечном счёте межсетевые экраны выполняют над поступающим трафиком одну из двух операций: пропустить пакет далее (allow) или отбросить пакет (deny). Некоторые межсетевые экраны имеют ещё одну операцию — reject, при которой пакет отбрасывается, но отправителю сообщается о недоступности сервиса, доступ к которому он пытался получить. В противовес этому, при операции deny отправитель не информируется о недоступности сервиса, что является более безопасным
Потому что не в алгоритмах дело. Вы мне так и не объяснили почему мой канадский смарт может быть аутентифицирован на сайте Госуслуг.
Зачем бы я стал вам это объяснять, если вы об этом не спрашивали? Вы спросили, почему на вашем смартфоне работает приложение Госуслуг, я вам объяснил. Если же вас интересует, почему вы можете канадским смартфоном аутентифицироваться на сайте, то это происходит потому, что у вас при такой аутентификации отключена часть функций. Полный фунционал Госуслуг доступен только через браузер с поддержкой ГОСТ или через приложение.
Ну а раз Вы не занимаетесь, то зачем ввязываетесь в дискуссию об этом?
Потому что отвечаю на ваши вопросы, так как имею такую возможность.
Функция фильтрации Traffic Filtration это всего лишь предварительная стадия в алгоритме файрвол. Ну да мы отфильтровали трафик. Причем трафик фильтруется гораздо больше чем типа Россия, не Россия. Что дальше? А дальше файрвол должен решить permit or deny ( To Be or Not to Be).
Эти правила allow и deny являются частью фильтра, собственно из них и состоит фильтр. Как и в жизни. В машине у вас топливный фильтр бензин пропускает, а мусор не пропускает. Так и здесь.
Зачем бы я стал вам это объяснять, если вы об этом не спрашивали?
Спрашивал, промотайте вверх немного:
"Вопрос: Почему я успешно инсталлировал и использую приложение Госуслуги на этом смартфоне. Он у меня что знает про ГОСТ Р 34.12-2015? "
у вас при такой аутентификации отключена часть функций
Привидите названия функций, которые не доступны с моего смарта и я вам скажу отключены они или нет.
Потому что отвечаю на ваши вопросы, так как имею такую возможность.
Как оказывается не на все. Да и на те что отвечаете то не профессионально.
Судя по Вашему профилю Вы программист. Нет даже намека на системную работу и работу по информационной безопасности.
Я, например, никогда не сталкивался с Lisp. Я не будут отвечать на Ваши вопросы по Lisp, более того я вообще ничего Вам не смогу сказать про Lisp кроме того что это язык программирования. Про Scheme я даже не заню что это язык или какая то схема.
Вот по REXX я много что мог бы Вам рассказать и ответить на любой вопрос. И про Ассемблер тоже. Про PL/I (на какой платформе?). Я работал с PL/I и на МФ и на ПК. С Basic работал. По С проходил офлайн тест, но не работал вообще.
А Вы пытаетесь что-то рассказывать мне про IP filtering, с кеоторым я много работал и не только на МФ но и на Юникс (AIX).
Спрашивал, промотайте вверх немного
Раньше вы спрашивали про приложение Госуслуг, а во второй раз спросили про сайт Госуслуг. Это разные вещи с разной функциональностью и разным устройством защиты канала передачи данных, хотя они и выглядят похоже. Какая именно из них вас интересует? Определившись с этим, можно говорить про функции.
Что касается PL/I, то с ним я работал в СВМ и в OS/2. А Scheme – это диалект Lisp. Но формально принято считать другим языком.
Раньше вы спрашивали про приложение Госуслуг, а во второй раз спросили про сайт Госуслуг. Это разные вещи с разной функциональностью и разным устройством защиты канала передачи данных, хотя они и выглядят похоже. Какая именно из них вас интересует? Определившись с этим, можно говорить про функции.
Да что Вы говорите. А я и не знал что то что у меня на телефоне в Канаде и то что в Москве это разные вещи. Спасибо.
Хорошо. Спрошу про канал. Он что с чем соединяет?
Вы, как я полагаю, говорили про функции доступные пользователю в ГосУслугах. Вы сказали что у меня не все функции с моего телефона доступны потому и потому то. Я попросил Вас уточнить какие функции мне не доступны. Вы уходите в несознанку. Что ж это позиция и я ее уважаю. Продолжайте в том же духе.
Ё-моё. Нет с технической точки зрения такого понятия "Госуслуги". Есть приложение "Госуслуги" для смартфона, которое работает само по себе или вместе с приложением "Госключ", и есть сайт gosuslugi.ru, который работает через веб-браузер. И в первом случае канал соединяет сервер с портом в приложении, которое написано в России, а во-втором – с портом в браузере, который у вас, как я понял, написан в США. Функции в первом и во втором случае доступны разные.
Поскольку вы до сих пор не объяснили, через приложение вы работаете или через вебсайт (точнее, каждый раз пишете разное), то как я могу вам ответить о том, какие функции вам доступны? Телепаты в отпуске.
1.
Вопрос: Почему я успешно инсталлировал и использую приложение Госуслуги на этом смартфоне.
или же
2.
Вы мне так и не объяснили почему мой канадский смарт может быть аутентифицирован на сайте Госуслуг.
Нет с технической точки зрения такого понятия "Госуслуги". Есть приложение "Госуслуги" для смартфона, которое работает само по себе или вместе с приложением "Госключ", и есть сайт gosuslugi.ru, который работает через веб-браузер. И в первом случае канал соединяет сервер с портом в приложении, которое написано в России, а во-втором – с портом в браузере, который у вас, как я понял, написан в США. Функции в первом и во втором случае доступны разные.
Поскольку вы до сих пор не объяснили, через приложение вы работаете или через вебсайт (точнее, каждый раз пишете разное), то как я могу вам ответить о том, какие функции вам доступны?
Причем здесь где что написано? Андроид в моем смарте, и браузер в Андроиде, которым это приложение пользуется, не написаны в России. Я Вам больше скажу в моем приложении Госуслуг есть такая строчка gosuslugi.ru, или просто IP address Госуслуг-овского сервера.
Хорошо. Я работаю и так и так, и с приложения на смарте и через вэбброузер.
Кстати могу вас удивить и приложение и броузер (мои, оба) коннектятся с серверами в Москве.
Приложение не пользуется браузером! Оно коннектится напрямую к серверу госуслуг. Который находится на том же ip адресе gosuslugi.ru, но не на порте https.
Приложение реализует своими собственными силами шифрование по ГОСТ, а Андроид ему просто предоставляет голый tcp порт.
Дефолтный браузер Андроида (хром?) не умеет шифровать по ГОСТ, поэтому функции, которые доступны через такой браузер, ограничены. Например, зарегистрировать или расторгнуть брак не сможете :) Или зарегистрировать юрлицо. Полный список можно посмотреть по ключевым словам "госуслуги гост tls".
Можете установить Яндекс.браузер, он поддерживает ГОСТ в TLS. Но там вроде всё равно ещё нужен криптопровайдер, я особо не вникал.
Захожу в приложение Госуслуги на смарте, кликаю на "Услуги", выбираю "Семья", "Регистрация брака", читаю "С помощью услуги можно выбрать удобное время .... и отправить жениху или невесте предложение .." и есть кнопка "Начать".
Иду в раздел "Регистрация Паспорт", вижу "Регистрация некоммерческой организации".
Есть "Выписка из ЕГРН", "Запрет на действия с недвижимостью".
А еще что интересно при нажатии на услугу идет переход в браузер и появляется строка "Идет загрузка". О ужес приложение переходит в написанный в США браузер, который не умеет шифроваит по ГОСТ.
Оценка по теме Вам "двойка". Вы знаете только набор заклинаний, но не существо информационной безопасности и шифрования.
Наличие кнопки "Начать" не означает возможности завершить. Думаю, что проблема возникнет на этапе подписания подготовленного заявления.
Но если вам лень почитать документацию на предмет требований к защите информации, то я не буду с вами дальше спорить. Когда приедете в Россию, детально познакомитесь со всей нормативной базой на собственном опыте.
Но и у Вас, уважаемый, с эти тоже проблемы. Надо бы хоть немного пробовать обосновывать свои утверждения.
Вот помню был у меня один оппонент на другом форуме. Сам он, как и Вы, с МФ и z/OS не работал,
Так я и не скрываю свои проблемы. Я сразу написал, что я не видел и не увижу комп, дороже тысячи долларов. У меня нет причин выставлять себя чем-то большим, чем я есть.
Абчом и спич. Вы же не считаете, что это сделать так просто, "стоит лишь только захотеть"? Это, на минуточку, дефолтное мнение обитателей рунета. "Чё ты такой бедный? Видимо, ты просто жопу от дивана оторвать не хочешь!" Мол, "оторви жопу" (c) и всё будет. Я в таких случаях задают вопрос: "Насколько высоко от дивана должен оторвать свою жопу 70 летний пенсионер из Костромы с пенсией $100 в месяц, чтобы получить возможность эмигрировать, скажем, в Канаду?" До сих пор внятного ответа на этот свой вопрос я так и не получил. Хотя спрашивал многих.
Я "оторвал жопу от дивана" в самом конце 90-х. Мне было 43 тогда. Для эммиграции в Канаду по их бальной системе порогом высокого бал по возрасту было 44 (не больше длины имен наборов данных в MVS).
Денег для иммиграции у меня не было. Только продав квартиру я мог получить деньги требуемые для этого, но после августа 1998 года и этого стало недостаточно. Письмо с приглашением на получение виз в посольстве Канады, присланное в ноябре 1998 года, было положено на полку (хотел порвать, но подумалось может на старости лет буду показывать внукам). И только чудом к лету 1999 года мне удалось набрать сумму, но не для всех четырех нас, а только трех. Одного, старшего, пришлось оставить (вскоре удалось и его подтянуть).
Вот эти все рунетовские "жопу от дивана", и "70 летний пенсионер из Костромы", это все бла-бла-бла. Жизнь гораздо сложнее.
В рунете вообще очень любят чуть что аппелировать к мифическому "70-летнему пенсионеру из Костромы в пенсией 12тр". Вот сколько было родителей (и тетешек-дядюшек) - ни у кого "12тр" не было. Не сотни тысяч, но на жизнь хватало всем. И не скажу чтобы ежиков без соли кушали.
К слову сказать, жена уже оформила пенсию. чуть менее 60тр получилось. Всю жизнь занималась (ну и сейчас еще работает "вполсвиста") переводами (научная и техническая тематика, в т.ч. патенты - т.е. еще немного юридическое в области патентного права и интеллектуальной собственности), вопросами интеллектуальной собственности и иногда контролем качества (есть сертификат аудитора по качеству). Т.е. просто работала, не чиновничела и не начальничела особо.
Я "оторвал жопу от дивана" в самом конце 90-х. Мне было 43 тогда. Для эммиграции в Канаду по их бальной системе порогом высокого бал по возрасту было 44 (не больше длины имен наборов данных в MVS).
Этот разговор явно не для Хабра, но таки спрошу: У вас, полагаю, было приглашение от канадского работодателя?
Если вниматель читать ответы, то станет понятно что не было
Нет не было. Я ехал в Канаду как простой иммигрант. Работу нашел через 9 месяцев. Мог бы сразу найти, но мой английский был ужасен (в школе и институте я изучал немецкий). Он и сейчас ужасен, но мне это не мешает говорить по работе часами. Отношение конечно ко мне корренных предубедедительное. Карьеру мне сделать было не суждено. Работаю в поле.
Значит, вам повезло. Некоторые, к примеру, в лотерею Green Card выигрывают. Не будете же вы утверждать, что такая возможность есть у каждого? "Я вот выиграл. А что что, лox, раз не можешь?" Вам визу таки дали. И, как я понимаю, с возможностью работы в Канаде. А большинству россиян даже туристическую не дадут. Единственная страна, которая разрешает нищему россиянину ставить его варварскую ногу на свою территорию - это Турция. И только в качестве туриста на одну-две недели. Наверное, еще россиянину можно посещать дружественные Афганистан и Эритрею.
Сейчас - да. Но так было не всегда. Канада, Австралия, Новая Зеландия были вполне себе открыты. Не для пенсионеров, но даже лет в 40 вполне можно было уехать и прижиться там. Но нужно было желание. Ну и хоть что-то уметь кроме пива перед телевизором.
Скажу, что в начале нулевых тоже была вполне реальная возможность в Канаду. Но не было сильной мотивации.
Вы еще забыли Кубу, и таки Израиль. Я в Беларусии хотел бы жить. Но не сечас.
Мне визу таки дали, но исключительно потому что я был мэйнфрэймщик. Даже мой ужасный английский не был помехой.
Был бы у меня английский я бы еще пару лет раньше уехал в США по вызову работодателя. Несколько моих подчиненных уехали туда раньше меня. Но никто не уехал в Канаду. Только США. Виза H1B называется.
Но работу мне никто не гарантировал. И я знаю многих наших соотечественников кто приехал в Канаду, получив визу по другим направлениям, и не нашли работу по специальности. Но почти все так или иначе устроились.
Ну у меня знакомые в НЗ уехали, правда через пару лет в Австралию перебрались т.к. по их словам вся НЗ - глухая деревня и там дико скучно и никаких перспектив (жили в Крайсчерче), хотя в целом комфортно. Другой знакомый сразу в Австралию. Племянник сейчас в Германии (в их отделении Volvo работает, IT-шник, занимается робототехникой какой-то). Уже с ВНЖ, скоро можно будет на гражданство подавать.
Жена в свое время много работала в Канаде и США (иногда по полгода там проводила) - представитель СП одного нашего завода с канадской фирмой (в основном жила на PEI). В принципе, была возможность двинуть туда, но что-то не было сильно большого желания.
Файловая система в x86 мире обеспечивает физическое хранение данных, а уж чего с этими данными делать, решают сами программы. ОС в это дело не лезет. Зато она обеспечивает сохранность и быстродействие (всякие RAID, кеширование).
Физическое хранение данных обеспечивают физические устройства хранения (диски, ленты). Это одинаково для МФ и х86.
z/OS тоже в данные програм не лезет (было удивительно и не правильно наоборот), но например DB2 хранит свои данные в VSAM наборах данных, размещением и каталогизацией которых занимается DFSMS и делает это лучше, лучше не для DB2, которая и без DFSMS это может делать, а для DBA, сокращая их работу и уменьшая их ошибки.
(всякие RAID, кеширование) в случае МФ делается МФ дисковыми подсистемами (DS8K, EMC/Dell VMAX, PowerMAX). Это не правильно в наше время расходовать ресурсы сервера чтобы организовывать кэширование и избыточность. Это большой минус подхода х86 в работе со сторадж.
Я не слышал, чтобы кто-то из разработчиков плакал: "Вот какая пичалька! Я хочу сделать то-то и то-то, в z/OS я бы сделал это одной левой, а в Windows или Linux не могу! Ааааааа!!!"
Когда МФ (ЕС ЭВМ) в СССР стали сходить с арены многие МФ-щики (в том числе и я в период 1995-1999) пошли работать на х86. И именно так они "плакали". Но тогда еще не было z/OS вообще, а в СССР и MVS почти не было. Были виртуальные машины, CMS, и БОС для пакетной обработки.
Мне посчастливилось работать с OS/2 когда Windows 95 был посмешищем в определенных кругах. (Кстати, для Вас лично, я также тогда работал с VisualAge for SmallTalk (ООП) и DB2/2).
....Значит, z/OS является одновременно многими сущностями, раз она противопоставляется тому, что в x86 мире проц архитектуры x86 "остается x86" и не может быть ничем иным, кроме как процом x86, Windows остается Windows, а Unix Unix. (Оставим за скобками такие детали, как WSL и Wine). Соответственно, я спрашивал: "А что, z/OS одновременно является многими типами возможных ОС, и архитектуру проца, на котором она работает, дает прогам тоже разную: хошь щас Power10, хошь на следующей инструкции x86?"
Да, некоторые недопонимания имеют место быть. Мне показалось Вы говорили что процессор х86 (не ОС на х86, а сам процессор) или arm, или PowerPC обладают какими то возможностями каких у МФ процессора (не z/OS) нет.
Отвечаю на выделеное жирным. Да, z/OS является ОС MVS и OC Unix одновременно. А с z/OS Container Extensions также и Линуск (Dockers):
z/OS Container Extensions (zCX) — это новая функция z/OS 2.4, которая позволяет клиентам развертывать приложения Linux в виде контейнеров Docker на z/OS в рамках рабочей нагрузки z/OS. Это обеспечивает операционный контроль над средой Linux в z/OS, обеспечивает качество обслуживания z/OS при развертывании приложений и не требует выделения отдельных логических разделов (LPAR) или системных образов. IBM zCX расширяет и модернизирует экосистему программного обеспечения z/OS, позволяя запускать на z/OS приложения и рабочие нагрузки, разработанные для Linux на Z и упакованные в образ Docker.
Отвечаю на курсив. Да, МФ (не z/OS) позволяет выполнять инструкции других архитектур. Например в далекие 70-, 80-е в Минске на EC-1035 Котовым Михаилом Петровичем была реализована архитектура Минск-32. Делалось это на виртуальной машине СВМ ЕС конфигурация которой была объвлена как "Минск-32". Также в zVM можно конфигурировать ВМ c предыдущими zArchitecture архитектурами (370,XA, ESA etc...).
Эмулировать другие процессоры можно (используя уровень микропрограммирования МФ), но вряд ли это имеет смысл. zEnterprise позволяет разгружать ворклоад на реальные Windows, Unix, Linux находящиеся на привязаных к z/OS блэйдах. А сечас (лет десять еазад это "сейчас") непосредственно в z/OS и Линуск (Dockers).
Прошлое значения не имеет. Главное то, что сейчас, то, чего вы добились:
живу в Канаде
Я никогда не считал и не считаю это моим достижением. Вовсе нет. Перезд из одного места на глобусе в другое достижением быть не может.
А вот то что я смог найти достойное место в канаде и достичь это своими способностями и своим трудом, это да, это достижение которым я горжусь.
А еще я бы очень гордился бы если бы смог что-то сделать чтобы Россия не отставала от остального мира в области ИТ, а именно в области ИБМ мэйнфрэймы (Z). Это очень важно, потому что Z это преимущество плохо, если вообще, используемое в России.
Вовсе нет. Перезд из одного места на глобусе в другое достижением быть не может.
О чем я и говорю со своего первого поста. В вашем мире подобное действие "переезд из одного места на глобусе в другое " доступно каждому. Как у Марии Захаровой, у которой в окружении одни достойные люди, летающие на частных джетах. В моем мире такое действие доступно единицам. А в моем непосредственном окружении оно не доступно вообще ни одному человеку. Люди из вашего мира не интересуются тем, что происходит за его пределами. Вон у чела пенсия жены $600 в месяц. И сколько ему ни рассказывай, какой доход имеют подавляющее большинство российских пенсионеров, слушать не будет. Ибо интереса нет.
Вы сильно преувеличиваете мою избранность. Да у меня есть канадское гражданство и паспорт. Но у меня есть и российские паспорта (внутренний и загран). Последними я дорожу больше чем первый.
Но вот если пенсия российская за почти тридцать лет работы и службы в армии (2 года) составляет немного больше 18 000 рублей, то недавно зачисленная мне первая канадская государственная пенсия за 25 лет (я на нее не апплаился, но было письмо где сообщалось что раз тебе парень исполнилось 70 лет мы тебе насильно будет перечислять твою пенсию, а если хочешь отказаться напиши нам заявление об этот, подпищи и пошли в коверте по такому то адресу.
Так эта канадская пенсия составляет $CA1323.31 или по текущему курсу 56.99 рублей за $CA = 75,415.43 рублей. А еще у меня будет корпоративная пенсия в разы (3-4) большая чем госпенсия и еще одна госпенсия которую мне не дадут сейчас потому что слишком высокий доход для этой пенсии. Это пенсия за то что я прожил 26 лет в канаде. Первая часть, уже выплачиваемая насильно, это от взносов в Гос ПФ взятых с моей зарплаты за 25 лет.
Вот такие дела творятся в некоторых странах.
А начинал я в канаде с $CA8/час собирая газовые горелки и потом заправляя бензин канадцам на заправке Full Service. И было мне тогда 44-45 лет и был я уже капитан СА/РА в отставке.
Вы сильно преувеличиваете мою избранность.
Нет, я вовсе не это пытаюсь сказать. Я пытаюсь сказать, что вы слишком игнорируете реальность, в которой живет большинство россиян. Раз вам рабочую визу в Канаду дали, значит, ее любой россиянин может получить, только попроси. Нет, не любой. У молодых, до 30 лет, еще есть шансы воспользоваться Express Entry. У людей с лимоном баксов есть возможность купить ВНЖ или стать номадом. Но у большинства россиян нет лимона баксов, и не каждый россиянин молод. Среди нас, знаете ли, есть те, кому не только за 30, но и за 40. У таких в силу возраста нет шансов в программах эмиграции - стары уже, не нужны такие старперы. И денег у них нет, поэтому они себе купить ВНЖ не могут. А доходы в России (не в Москве и не у чинушей) такие, что сумму, равную, к примеру, годовому доходу среднестатистического жителя Канады, многие не заработают и за всю свою жизнь.
И что меня поражает цепляет во всём этом, то что жители первого мира делают вид, что всё, что я, к примеру, написал выше, это вранье. Нет такого. Вон пишут, что у россиян пенсия минимум $600, а уж если россиянин работает, то $3000 не вставая с дивана. Нет никаких пенсионеров из Костромы, тем более, 70-летних. Миф это. И, разумеется, россиянин может в любую точку мира переехать жить, ведь препятствий к этому никаких.
Да никто не спорит. Посыл в другом. Пенсия - это то, о чем нужно думать сильно заранее. Т.е. стараться не работать за з/п в конверте, пытаться искать более высокооплачиваемую работу и т.п.
Как думаете получается пенсия в $600? А просто - работа только в белую (т.е. с отчислениями в ПФР), часто две-три работы (одна постоянная, другая по договорам). В результате на пенсионном счету неплохое количество баллов накопилось.
Плюс была возможность выйти в 55 - не пошла. Доработала до 60-ти. А это 5 лет "переработки" и коэффициент почти 1.5 на который умножается стоимость баллов.
Ничего необычного, как видите, нет. Ничего такого недостижимого.
Я пытаюсь сказать, что вы слишком игнорируете реальность, в которой живет большинство россиян.
Один из таких россиян мой сын. Он уехал с нами когда ему было 14 лет. И вернулся в Россию в 2020 году.
Раз вам рабочую визу в Канаду дали,
Это была не рабочая виза, это была Landed Immigrant виза. Т.е. меня брали для безсрочного, безусловного проживания в канаде, хоть бомжом.
Есть провинциальные программы нынче по которым ты должен прожить, скажем. два года в Манитобе.
А доходы в России (не в Москве и не у чинушей) такие, что сумму, равную, к примеру, годовому доходу среднестатистического жителя Канады, многие не заработают и за всю свою жизнь.
Не надо особых иллюзий питать по поводу дохода среднестатистического жителя Канады. С учетом расходов канадских остается совсем не много. Плюс налоги. Они в Канаде ломовые по сравнению с Россией. И чем больше доход тем больше отдашь в налог. У меня примерно треть уходит в налоги и взносы. Да даже больше.
Многие мои друзья, коллеги оставшиеся в России живут сейчас гораздо богаче меня, хотя по меркам Канады я тоже очень не плохо зарабатываю. Есть конечно и другие примеры.
И, разумеется, россиянин может в любую точку мира переехать жить, ведь препятствий к этому никаких.
Конечно может. Станьте диссидентом, иноагентом и вперед, все двери открыты. Сколько уже таких россиян уехало. Шутка конечно.
Это была не рабочая виза, это была Landed Immigrant виза. Т.е. меня брали для безсрочного, безусловного проживания в канаде, хоть бомжом.
Так вот, для российских реалий вы - совершенно исключительный и уникальный человек. (Впрочем, у нас тут таких - каждый чиновник, но я, разумеется, вас с ними не сравниваю.) Потому, что обычному россиянину Landed Immigrant Visa не дают.
Вы опять делаете из меня какого-то монстра. А я обычный парень из провинции, из Челябинска. Отец быть старшиной стройба, мать секретарем-машинисткой и не секретаря обкома, и даже не райкома, и даже не директора завода.
Более того в Канаде нет механизмов выделения "исключительных и уникальных людей". Перед налоговой инспекцией Канады все равны.
Когда я приехал, 1-го сентября 1998, к канадскому посольству там бвло много людей, несколько десятков, но не больше сотни, а может и больше. И я там увидел одного парня, подошел, познакомился. В тот день этот парень сдал документы и получил формы на медицинскую комиссию, а я поехал домой, в Челябинск, потому что мои документы оказались не правильными.
Вот тот парень был гораздо более исключительным и уникальным чем я.
Здесь, в Канаде столько исключительных и уникальных из России что чтобы попасть на прием в консулат России надо записываться заранее и были времена когда записаться можно было только за пару-тройку месяцев и то если повезет. Сейчас попроще стало.
Вы опять делаете из меня какого-то монстра.
Про монстров я, вроде бы, не говорил.
А я обычный парень из провинции, из Челябинска.
И о том, что вы родились с золотой ложкой во рту, тоже.
и не секретаря обкома, и даже не райкома, и даже не директора завода.
Я упомянул чиновников, потому как без этой оговорки тот же ваш коллега мог бы возразить, что он знает сотни людей, у которых по два-три гражданства и с деньгами всё хорошо. Прямо, как у него. А я тут вру всё безбожно. Поэтому я сразу написал, что я знаю, что в России Москве есть люди и с тремя гражданствами и несколькими миллионами долларов на счету. Таки люди есть, и их наличие я не отрицаю. Вас же к ним я не приравниваю.
Когда я приехал, 1-го сентября 1998, к канадскому посольству там бвло много людей, несколько десятков, но не больше сотни, а может и больше.
Спасибо за рассказ. Я же, со своей стороны, пытаюсь донести до вас вот какую мысль. Не то, что вы сами какой-то сильно особенный (тем более, раз вы это сами опровергаете), а то, что обстоятельства вашей жизни сложились уникальным образом. Это то же самое, как если бы кто-то выиграл в лотерею. Не чудо, но и не сказать, что такое происходит с каждым вторым. Вы думаете, что в России, я не знаю, каждый третий может повторить ваш путь, или хотя бы, каждый десятый. А я вам говорю, что только каждый сотый, а, может, и того меньше. Только один из ста, плюс-минус, или обладает достаточными деньгами или достаточными достижениями, чтобы цивилизованная страна решила, что она не против его к себе пустить. Так что, не знаю, как для вас, но для меня соотношение "один из ста" - это далеко не показатель равных возможностей для большинства. А ровно наоборот.
О каких "равных возможностях" в говорите?
Те самые "70-летние пенсионеры" - это эпоха СССР. Когда возможность получить высшее образование измерялась не деньгами, а желанием, подкрепленным усилиями.
Я вот окончил обычную среднюю школу в Свердловске (тогда еще). Поступил в УПИ (уральский политех) на физтех (ядерные установки). И да, для этого пришлось учится, готовиться. И потом на физтехе не так просто было учится. Многое пришлось отодвинуть на второй план.
Потом распределение (академический институт РАН). Там понял что все это не мое и что мне нравится программировать. Сам освоил все это дело. А никаких курсов тогда не было, интернета не было (88-89-й годы). Приходил на работу к семи (чтобы успеть повозиться с компом до начала рабочего дня, уходил в восемь (еще повозиться после конца рабочего дня).
В 91-м ушел уже "в программисты". И да, тогда там не было таких безумных денег. Платили примерно как всем. Были периоды, когда работал практически за копейки на основной работе (потому что нравилось, потому что считал это своим делом - мы тогда один достаточно серьезный проект поднимали с нуля абсолютно, аналогов в стране не было), а деньги вечерами в других местах зарабатывал (в т.ч. тупо вбивая в таблички какие-то цифирьки коммерсам).
И вот скажите - где тут везение, или какие-то "особые возможности"? Никто никогда не помогал. Просто пахал всю жизнь как ишак.
У жены аналогично - по специальности "металловедение и физика металлов". Но выучила англиский сама, ушла в переводчики (тоже конец 80-х - начало 90-х). Попала переводчиком в проект TACIS (не по знакомству, прошла конкурс на общих основаниях, собеседование и все такое). Там попутно получила сертификат аудитора по системам контроля качества (сам аудитом не занималась, но много переводила на аудитах т.к. хорошо тематику знала плюс консультировала по подготовке к аудиту). Потом еще в тему интеллектуальной собственности влезла - много переводов по патентам плюс консультации по заявкам.
И тоже - никакого везения, только работа-работа-работа. Причем, далеко не всегда оплачиваемая. Часто "на будущее", "на репутацию"
А если плыть по течении и не дергаться - да. Потом останется только сетовать на "неравные возможности" - не дали, в рот не положили...
А я вам говорю, что только каждый сотый, а, может, и того меньше. Только один из ста, плюс-минус, или обладает достаточными деньгами или достаточными достижениями, чтобы цивилизованная страна решила, что она не против его к себе пустить.
А я считаю что даже одного из ста россиян не должно быть. Россия не Каледония как-нибудь, Россия великая ЦИВИЛИЗОВАННАЯ страна и любому россиянину должно быть хорошо в ней. И никуда россияне не должны ездить более чем на несколько месяцев.
А на Канады плевать, они сами должны строить свою страну, а не иммигрантами как это на самом деле происходит.
Я за чтобы не повторялись 90-е и за запрет выезда россиян на ПМЖ. Если сильно неймется можно и присесть. Так должно быть по-моему.
Ну я бы не стал так радикально. Не надо запретов. Надо так, чтобы не было нужды в запретах. Чтобы человеку и тут хорошо было.
Вот именно "чтобы человеку и тут хорошо было". как вы думаете много канадцев мечтают уехать куда-нибудь?
Ответ очевиден. У большенства канадцев даже паспортов нет. Есть места типа Виндзор, через речку Дэйтройд. Там на работу ездят по мосту.
Но в Канаде есть и много есть живущих весьма скромно. Есть районы в торонто где живут в вонючих аппартментах из которых нет пути наверх. И они не хотят никуда уезжать. Госудаство их кормит, лечит, учит детей.
В СССР был запрет на выезд, ну и что в этом было хорошего? Люди, которым не нравилось жить в стране, не могли уехать и разлагали государство изнутри, что закончилось его окончательным развалом.
Евреи уезжали в 70-е без особых проблем, а кому еще хотелось уехать? Назовите признаки таких людей? Мечтатели о красивой жизни на западе? Ну уехали они и тут им кувалдой по голове. А назад дороги нет. Почитайте Эдуарда Лимонова.
Вовсе не без проблем. Известному в России господину Кедми пришлось целый комитет ООН подключить, чтобы добиться своей эмиграции из СССР в Израиль (он об этом пишет в своих мемуарах).
Да какая разница, по каким причинам? Принудительный труд неэффективен. Нас ещё в школе ведь учили, что за рабами нужен надсмотрщик, они начинают ломать орудия труда, специально делать работу плохо и т.д., поэтому рабовладение вытесняется более прогрессивным феодализмом, и так далее.
Вовсе не без проблем. Известному в России господину Кедми пришлось целый комитет ООН подключить, чтобы добиться своей эмиграции из СССР в Израиль (он об этом пишет в своих мемуарах).
У меня был друг, работали в одной фирме, простой парень из Львова. Выехал из СССР в 70-е. И не один, у него было много друзей с аналогичной историей.
В 70-е евреи ухали самолетами. Не все правда доезжали до Израиля.
сумма конечно выглядит весьма красиво, но это для России, для Канады мне сложно судить. а что по здравоохранению для пенсионеров?
вообще давно меня мысль не отпускает, что ваше поколение "почти" последнее у кого будет пенсия от государства...
Для Канады моя пенсия суммарно гос и корпоративная тоже довольно красивая.
Здравоохранение в Канаде бесплатно. С 65 лет еще разные льготы даются, например, некоторые лекарства бесплатны. Я эту тему плохо знаю потому что у нас есть медицинские бенефиты от компании и они почти все покрывают и так. Причем эти бенефиты сохраняются и после выхода не пенсию.
Все дело в деньгах, как правильно заметил предыдущий оратор - вместо ОДНОЙ ОЧЕНЬ ДОРОГОЙ установки, для которой актуально ее максимально сбалансированное использование - в мире х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ти минут что недопустимо
Означает необходимость доработки сервиса для оптимизации потребления ресурсов.
Слуйно проходил рядом, отвечая на сообщение, и перечитал Ваш пост.
.....для того, чтобы когда один из серверов вышел из строя (потоп, пожар, физическое уничтожение) - оставшиеся подхватили бы работу.
В случае потопа, пожара, физического уничтожения дата центра с Вашими кластерами все сервера кластеров будут точно также униятожены как и "большой мейнфрейм". В этом случае нет никакой разницы между ними.
То на что Вы уповаете, защищаясь кластерной архитектурой, спасает только от гибели отдельных mother board в стойке. Это не может быть не потоп, ни пожар, при которых будет уничтожено все.
МФ - это стойка с внутренним резервированием всех элементов, многократным резервированием. Так что МФ на самом деле это кластер с точки зрения надежности от потери элементов.
У одного большого мейнфрейма такой опции в принципе нет, если условно говоря он будет уничтожен - пострадают все, у кого на нем что-то работало.
Тоже самое произойдет и в случае с кластером
Если бы это так и было то это было бы очень смешно. Никаких МФ нет без Disaster Recovery плана. Обязательно ставится задача для и рещатся на случай потери, нет не МФ, собственно МФ "сгореть" не может, а всего датацентра где находится МФ.
У нас, например, один МФ находится в специально созданом здании для датацентров многих компаний, и в нашем сегменте этого здания (очень защищенного от многоих факторов разрушения) сам МФ занимает 3-4 кв. метров. площади из 2-3 тысяч. И у этого МФ есть место, в 15-20 км удалении от этого здания, куда в случае разрушения всего этого здания, вместе со всем содержимым, работа этого МФ перекочевывает за 10-15 минут без потери данных кроме изменяемых транзакциями, выполняемыми на момент остановки МФ. Раз год, каждый год, этот сценарий симулируется и проверятся его работоспособность.
А тот МФ, куда первый "падает" в случае разрушения, выполняется своя работа, свои приложения и пользователи. И для этого МФ первый является DR сайтом. Т.е. два МФ являются DR сайтами друг друга. Каждый МФ имеет возможность выполнять всю работу обоих МФ. Но в нормальной обстановке каждый МФ загружен на все 100% своей мощности, за которую платит пользователь.
Эта наша конфигурация в некотором роде иммитация стандартной конфигурации называемой Geographically Dispersed Parallel Sysplex (GDPS) :
(Неудачно переведенные места в нижеследущем я вернул на английский)
Географически распределённая система Parallel Sysplex (GDPS®) объединяет технологию Parallel Sysplex® и технологию удалённого копирования для повышения доступности приложений и улучшения disaster recovery. Топология GDPS представляет собой кластер Parallel Sysplex (этого у нас нет - zVlad909), распределённый по двум площадкам, при этом все критически важные данные зеркалируются (это то что у нас есть - zVlad909) между площадками. GDPS управляет конфигурацией удалённого копирования и системами хранения, автоматизирует операционные задачи Parallel Sysplex и автоматизирует failure recovery из единой точки управления, тем самым повышая доступность приложений. GDPS поддерживает все менеджеры транзакций (например, Customer Information Control System [CICS] и систему управления информацией [IMS]) и менеджеры баз данных (например, DB2®, IMS и Virtual Storage Access Method [VSAM]).
Если нет нагрузки на два МФ или нет двух датацентров, то DR сайт можно рентовать у других пользователей МФ, например, у того же ИБМ. У нас так и было в начале 2000-х.
А вот одиночный сервер и даже кластер в отдельном датацентра в случае дизастера исчезнут бесследно и навсегда. Сделать такой же, как описан выше, DR план на серверах х86-64 тоже можно, но это будут уже совсем другие деньги и другие сопутствующие эффекты, а именно, ресурсы для DR не смогут быть использованы и будут просто простаивать, не бесплатно. Т.е. так как это сделано на МФ сделать на х86-64 просто не возможно. У нас есть DR для х86-64 серверов но это в лучшем случае (когда ресурсы не простаивают) использование QA серверов в другом дата центре и восстановление (многочасовое) с бэкап-а. В худшем это fail-over с горячим standby server doing nothing.
Что, в какой-то момент длину имён наборов данных увеличили? В классической 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 и командует фиоипинцем в Канаде. Нажми туда, пойди сюда-туда, открой, закрой, разомкни, замкни, и т.д и т.п..
Вот вам и Запад. Зря развалили СССР, хотя и в СССР тоже были клоуны, и я их знаю в том числе в нашей ИТ. Но эти, с кеми я сейчас, саморазваливаться точно не будут. Даже наоборот.
В чипе CPU есть цепи контроля и используются избыточные коды. Это электроника.
Вот про неё я и спрашиваю. Зачем вы потом ещё 10 абзацев про "конторы саппорта" пишете?
Чтоб просто иметь возможность определить одиночный (не многократный) сбой, все сигналы управления (те, что не шины данных) и логику управления необходимо каким-либо образом дублировать с постоянным сравнением. Если хочется ещё и игнорировать сбой -- троировать с мажорированием. Возможность определения одиночного сбоя не даёт гарантии что заодно и точно узнаем место и момент сбоя и сможем определить, на что он повлиял. Чтоб и это тоже было -- кол-во логики ещё увеличивается. И т.д.
В результате получаем что эти ваши moneyфреймы оказываются неэффективными по площади и по потреблению, т.к. кол-во логики на те же вычисления больше. Но видимо либо богатые конторы имеют возможность платить и х2 прайс за электричество, или на самом деле "жырность" мейнфреймов преувеличена и любой традиционный датацентр средней величины запросто обойдёт по потреблению и производительности любой мейнфрейм.
Не удебительно. На цифр, ни ссылок. Одни домыслы.
Лучше расскажите как борятся со собоями х86 Виндовз, и Линукс.
Не удебительно.
Я же сюда пришёл не мифотворчеством заниматься а выражать здоровый скептицизм. Тем более что апологетам ибм moneyфреймов, как оказывается, мне ответить нечего, кроме "не убедительно" :)
Это не есть здороый скептицизм:
Но видимо либо богатые конторы имеют возможность платить и х2 прайс за электричество, или на самом деле "жырность" мейнфреймов преувеличена и любой традиционный датацентр средней величины запросто обойдёт по потреблению и производительности любой мейнфрейм.
Это продукт дилетантизма. Уж извините что называю вещи их именами.
Повторю вопрос: Расскажите как борятся со собоями х86 Виндовз, и Линукс?
Зачастую достаточно обнаружить сбой, схем для чего требуется не очень много по объёму (реальное дублирование требуется для АЛУ, но их площадь на современных кристаллах незначительна -- это не машины 1960-х, где АЛУ могло по объёму аппаратуры занимать чуть ли не половину всего процессора). При обнаружении сбоя происходит прерывание от схем контроля (имелось ещё в Системе 360 -- собственно, все механизмы уже тогда были заложены, затем лишь шло их совершенствование), при котором в память записывается, в т.ч., содержимое всех программно доступных регистров процессора вместе с индикацией достоверности их содержимого. В многопроцессорной системе (а современные, понятное дело, все такие) сигнал сбоя одного процессора может передаваться другим процессорам, что при соответствующей программной поддержке позволяет "подхватить" задачу, выполнявшуюся на вышедшем из строя процессоре.
В общем, достаточно обеспечить высокую (желательно 100%) вероятность обнаружения сбоя и сохранность исходного содержимого регистров -- тогда продолжение работы на другом процессоре обеспечивается без проблем.
Плюс, ещё в OS/360 был механизм контрольных точек, позволяющий при нужде перезапустить приложение не с самого начала, а с какого-то промежуточного момента -- помогает, если продолжить выполнение прямо с точки сбоя невозможно (например, утрачено достоверное содержимое регистров).
Добавлю что не только регистров, а и что очень важно PSW (Program Status Word), в котором адрес прерваной программы и различная другая информация важная для выполнения и восстановления.
После сохранения PSW на момент прерывания (OLD PSW) происходит загрузка PSW с адресом программы управления данного прерывания (NEW PSW). Находятся эти OLD и NEW PSW (их столько сколько имеется прерываний) в PSA (Prefixed Save Area. У каждого процессора своя PSA). Таким образом управление передается программе обработки прерывания (в данном случае по машинному сбою). Программа эта сохраняет регистры общего назначения в области сохранения этой программы и начинает процесс вовстановления от сбоя или, в общем случае, обрабатывает прерывание.
Переключение PSW происходит аппаратно, все остальное программно.
Я написал про регистры вообще, а не конкретно про регистры общего назначения. Очевидно, что к числу регистров PSW тоже относится -- как относятся и регистры с плавающей запятой, и появившиеся в Системе 370 управляющие регистры, регистр префикса, регистры средств отсчёта времени, и т.д. и т.п.
Конечно, но главным в процессах прерывания является именно PSW именно они хранятся в PSA и аппаратно используются. Все остальные обслуживаются програмно. Каждая программа первым делом сохраняет регистры вызвавшей ее программы и создает область сохранения своих регистров. Регистров прикладных программ, сохраняемых всего 16 (R0-R15).
схем для чего требуется не очень много по объёму
Для обнаружения в передаваемых данных - действительно. Но вот сама управляющая логика по сути кроме как дублированием (или dual rail) никак не защищается.
При обнаружении сбоя происходит прерывание от схем контроля
Обнаружить сбой действительно можно именно так. Но вот у нас есть суперскалярный процессор, в нём могут одновременно выполняться сотни команд. Обнаружен сбой. Если нет информации, где именно -- то довольно нетривиально провернуть весь этот фарш назад для того, чтобы понять, например, сбой произошёл ДО того, как сделали снапшот памяти/процесса/его IO или после. Если сбой примерно совпал по времени с деланием этого снапшота, например.
Наверное можно например сбои управляющей логики разделять на сегменты -- типа вот тут логика коммита команд, а вон там логика шедулера, если сбойнуло там то мы можем ещё дождаться коммита всех операций, иначе засада и т.д. Но собственно тут и происходит радикальное усложение дизайна, когда поверх и так нетривиальной архитектуры суперскалярного ядра ещё натягивается система восстановления (частичного) после сбоя. Ну и в общем это то, что было бы интересно узнать из первых рук, а не только размахивания руками "у нас всё надёжно мамой клянусь, можно шокером в плату и всё продолжит работaть"
Управляющая логика тоже далеко не всегда требует дублирования. Скажем, на основе кода команды вырабатывается энное количество управляющих сигналов плюс 1-2 контрольных -- а дальше это где-то проверяется на чётность.
С обнаружением проблем в суперскалярном проце тоже особых проблем нет: чем занимается сдохший узел в каждый момент времени, известно. Есно, усложнение будет, но отнюдь не в 100500 раз (а по площади современных кристаллов -- так вообще мизер, ведь там бОльшая часть площади -- это разного рода кэши и буферы, которые контролируются элементарно).
А вот возьму как пример что-то сложнее, чем буфер но проще чем кеш: FIFO. Вот у нас данные, но они защищены чётностью например и мы их не трогаем. Вот сигналы наружу -- входы стробов чтения и записи, выходы сигналов 'full' и 'empty'. Если один из них сломается -- то в FIFO либо запишется чушь, либо прочитается чушь, либо не запишется что надо, либо не прочтётся что надо, либо (и т.д.). Нам их надо защитить, например дублированием (лучше когда сигнал и его инверсная копия). Ещё из блока управления FIFO торчат адреса в блок памяти, адрес чтения и записи. Их тоже хорошо бы защитить, минимум дублированием. Теперь есть собственно управляющая логика: она смотрит на те 4 сигнала выше и генерит адреса для блока памяти. Если эта логика сломается, будет опять см. выше что. Получается, нам ВЕСЬ блок управления памятью при FIFO надо продублировать. Далее ещё можно разобрать, как сделать чтобы в память не писали куда попало (вдруг провода от блока управления до памяти сломаются или в самой памяти дешифратор ряда) и чтоб не читало откуда попало. Тут тоже без некоторого увеличения логики и/или объёма памяти не обойтись.
И так можно рассказать почти обо всём. Откуда и моё утверждение про увеличение количества логики.
Ваши "управляющие сигналы" точно так же будут идти отдельными проводами на "проверку чётности" и другими -- собственно куда надо. И эти другие провода тоже могут сломаться, как и логика за ними. Получается, проверка чётности как у вас не обеспечивает полного контроля.
Если честно, я не знаю лучшего метода для рандомной логики, чем дублирование со сверкой -- если мы стремимся к 100% покрытию на детект одиночного сбоя.
Если честно, я не знаю лучшего метода для рандомной логики, чем дублирование со сверкой -- если мы стремимся к 100% покрытию на детект одиночного сбоя.
Не понятно к чему эти гипотетические раауждения о решениях про которых нет полной информации.
Вам SIISII несколько раз объяснил что контроль сбоев аппаратуры МФ имелся с самых первых моделей, уверен, что и на компьютерах до МФ это тоже уже имелось. Имелись также и средства востановления от сбоев.
Естественно не любой сбой можно пережить абсолютно безболезненно, но при наличии избыточности, а она в МФ есть во всех компонентах, восстановление может быть удачным в широких пределах.
Помню на ЕС 1033 в военном училище был недиагностируемый сбой вырающийся в том что команда конверсии из десятичного в шестнадцетиричное для числа 200 и только для него давала результат 0. Приводило это к тому что на резидентном томе переписывалась нулевая дорожка нулевого цилиндра.
Средства восстановления МФ в состоянии оценить масштабы сбоя и возможность его преодоления. Если не возможно восстановить выполнение пользовательской или системной задачи, то они завершаются аварийно с последущей обработкой возможности восстановления на уровне прикладной программы или системной. Есть такая служба в z/OS ARM:
ARM (Automatic Restart Manager) is a z/OS component that automatically restarts failed jobs or started tasks, enhancing system availability.
Крайним случаем является завершение работы ОС и выдачи кода состояния ожидания с запрещенными прерываниями.
С другой стороны что такое "рандомная логика" сегодня. Это твердотельная микросхема. Т.е. в ней нет движущихся частей, и нет паяных соединений. Есть только области с разными концентрациями примесей (транзисторы), проводники и возможно ёмкости. Эти микросхемы после изготовления тестируют и бракуют. Потом делают карты с многими микросхемами и они тестируются, причем делая с этими картами разные фокусы типа нагревания, охлаждения и нового тестирования. Собраный майнфрэйм тоже тестируютЮ нагревают, трясут имитируя землетрясение и снова тестируют. И лишь после этого отгружают.
Не понятно к чему эти гипотетические раауждения о решениях про которых нет полной информации.
Это не гипотетические, а вполне практические рассуждения. Вот прямо то чем я занимаюсь. Гипотетические, и уж точно без вообще какой-либо информации по существу -- у вас.
Вам SIISII несколько раз объяснил что контроль сбоев аппаратуры МФ имелся с самых первых моделей, уверен, что и на компьютерах до МФ это тоже уже имелось. Имелись также и средства востановления от сбоев.
Перефразируя: "talk is cheap. show me your schematics" :)
Если не возможно восстановить выполнение пользовательской или системной задачи, то они завершаются аварийно с последущей обработкой возможности восстановления на уровне прикладной программы или системной.
Уже лучше. Не "всё супер надёжно, никаких сбоев, если что другой процессор впряжётся и продолжит с того же места", а оказывается и упасть может.
Я же в свою очередь продолжаю настаивать, что тотальный контроль сбоев (даже одиночных) невозможнен без +- дублирования всей логики. А это площадь кристалла, потребление.
Кстати, о том как именно программно реализованы откаты (что и когда снапшотится и т.д.) тоже рассказа по существу не было. Вы как специалист по ibm mainframe'ам, уверен, можете об этом замечательно и очень интересно рассказать.
С другой стороны что такое "рандомная логика" сегодня. Это твердотельная микросхема.
В которой 100 миллиардов транзисторов например.
Потом делают карты с многими микросхемами
Вы сейчас точно не про ЕС-1033?
И лишь после этого отгружают.
А потом прилетает ТЗЧ, которой похрену на все тестирования, и флипает состояние одного триггера.
Это не гипотетические, а вполне практические рассуждения. Вот прямо то чем я занимаюсь. Гипотетические, и уж точно без вообще какой-либо информации по существу -- у вас.
Ну, скажем так, тема моего диплома в 1979 году была "Растровый цифровой запоминающий осциллограф". К защите диплома я начал двигаться с третьего курса и у меня несколько плат с микросхемами которые я сам разрботал, изготовил и отладил с обычным осциллографом и генератором. По моему диплому еще несколько дипломов (два-три) были написаны (кстати пояснительная записка к моему диплому у меня в Канаде). У меня было место на кафедрв для продолжения моей работы, и не известно кем бы я сейчас был если бы меня не загребли на СВО в Советсткую Армию.
Конечно же я не электронщик, но раз вы "Вот прямо то чем я занимаюсь.", то Вам сам бог велел найти на бескрайних просторан интернета описание как это сделано в ИБМ МФ и .... , а что собственно "И". Что вы хотите доказать, то? Похоже что вообще МФ быть не может. Уверяю Вас может, еще как может. МФ вот прямо то чем я занимаюсь. В смысле программного обеспечения (ОС, БД и т.д и т.п.)
Уже лучше. Не "всё супер надёжно, никаких сбоев, если что другой процессор впряжётся и продолжит с того же места", а оказывается и упасть может.
Никто не заявлял о супер надежности, SIISII пытались насколько это возможно в комментариях объяснить что да весьма надежно. Это Вы, не понятно зачем, сказали про "электрошокером в плату". МФ стоят на ДЦ под замком с допуском только авторизованного персонала. Но, например, можно на ходу вынимать многоие плату и ничего не случится. Конечно не все сразу. На МФ все зарезервированно в смысле привыходе чего-то одного всегда есть горячая замена. Есть, например (в моем МФ, маленьком, меньше не бывает) 4 сетевые карты (OSA card) с 8 портами на всех (по два). Вынимай на ходу любые две ничего не случится. ОС выдаст сообщение и не более того. Диски подключены через четыре карты ввода-вывода (FICON card. Оптоволокно), на каждой карте два порта, используется один. Можно вынуть на ходу три из четырех, ничего не случится. Четыре других карты отдельно на "ленты" для бэкапов. Из 16 портом I/O у нас задествованы только 8.
МФ, на сегдня, самое надежное оборудование для серверов. На х86 можно только кластеризацией добиться чего то похожего, да и то всегда найдется single point of failure из-за которого все может посыпаться как карточный домик. И у нас такое было недавно, несколько часов люди в нескольких огромных офисах сидели без связи, без WiFi. Это была человеческая ошибка, но все же. На х86 только дублированием сервисов на разных серверах пытаются достичь какой никакай надежности. А это оборудование, персонал и все остальное. Это в нетривиальных случаях огромные деньги. МФ стоит в сторонке нервно покуривая глядя на том что происходит с ИТ на х86.
Я продолжу после завтрака.
ТЗЧ — тяжёлая заряженная частица. Это то о чем Вы говорите выше?
Кстати, о том как именно программно реализованы откаты (что и когда снапшотится и т.д.) тоже рассказа по существу не было. Вы как специалист по ibm mainframe'ам, уверен, можете об этом замечательно и очень интересно рассказать.
Если Вы про машинные сбои, то это не откаты, а попытки восстановления. Об этом здесь и я и SIISII довольно много сказали. Я приводил перевод из ангоВикипедии. Лично мне это достаточно много сказало.
Программы машинных (центральных устройств, не перефирии) сбоев МФ это очень сложная тема, это создано совместно разработчиками МФ центральных устройств и разработчиками операционных систем на МФ.
Мне, на уровне ОС и системного ПО это не доступно и не надо. Мне достаточно знать как создать отчет т.н. программы EREP (The Environmental Record Editing and Printing Program, этой программе столько лет сколько лет МФ и ее развивают с каждым новым семейством МФ), которая обрабатывает данные из LOGREC где сохраняется вся информация о всех ошибках всех устройств из которых состоит МФ (CPU, RAM, I/O channels) и которые используются МФ (это внешние устройства, диски, терминалы, ленты, все что можно подключать к каналам ввода-вывода МФ). А также в LOGREC записываются все существенные сбои программ на МФ.
Я конечно могу о многом рассказать и рассказываю по мере возможности. Но термины "откаты" и "снапшопание" они такие размытые что и Вы сами не сможите корректно объяснить что Вы имеете в виду.
Еще раз советую Вам поискать на инете специальную информацию о вопросах, которыми Вы занимаетесь и которые относятся к МФ. Много Вы конечно не найдете, но точно больше чем от меня и тогда можно будет продолжить эту, реально увлекательную, беседу. Я до сих пор неровно дышу в отношении электроники, особенно цифровой.
В которой 100 миллиардов транзисторов например.
И что? Упор был на слово "твердотельная".
Вы сейчас точно не про ЕС-1033?
Нет. А почему Вы спросили?
А потом прилетает ТЗЧ, которой похрену на все тестирования, и флипает состояние одного триггера.
МФ не в фанерном корпусе собирается и не в деревянных сараях с соломенными крышами устранавливается. Одна ТЗЧ не флипнет триггер. Токи в микросхемах достаточно большие чтобы не искажаться одной ТЗЧ, надо серьезный поток их чтобы это произошло.
Давайте не будем наводить тень на плетень.
Мф очень сложно "убить"
Что, и даже шокером в плату не убить?
Так в том и суть 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