А Вы знаете ответ на его (нашего "архитектора") сомнения?
Я с самого начала как в ИТ началось деление на узкие специализации (тестеры, бизнес аналитики, архитекторы, администраторы, секьюрити) понял что это цирк. Нет, конечно, в серьезных фирмах разработчиках ОС такое деление имеет смысл, но в фирмах-пользователях только два направления имеют смысл - системное (или инфраструктура, которое включает в себя собственно системщиков т.е. архитекторов, администраторов, и секьюритиб как поднаправления), и прикладное, в которое входят и тестеры и бизнес-аналитики.
Наш "архитектор" начальник моего начальника и него самомго есть еще как минимум один начальник, считающий себя тоже "архитектором". Но кроме "архитектора" надо мной есть еще не мало "архитекторов" в нашем ИТ.
Ну а теперь Вы мне ответьте на вопрос "как у вас сажают брюкву с кожурою или без", т.е. как Вы решаете вопрос соотношения количества кластеров Ку с реальной структурой Вашего ИТ? Спросите Вашего "архитектора", который точно архитектор, а не плотник или каменщик. .
Предложенные автором решения не всегда оптимальны, и мы добавили в материал комментарии нашего эксперта @Philipp451 там, где можно что-то улучшить или применить альтернативный подход.
Интересно было бы посмотреть оригинал перевода, а больше от какой компании эта статья написана исходною
Не всегда оптимальны это скорее почти никогда не оптимальны. Коренная причина этому именно то что считается самым сильным моментом - кластеризация. Или иначе распределенность.
В условиях рапределенности практически всегда рано или поздно какие-то ноды окажутся бутылочным горлышком при том что други будут простаивать. У нас это регулярно происходит в конфигурации load balancer.
Только в случаях таких рабочих нагрузок какие имеются в Google это более менее оптимально. Но много ли таких чья ИТ похожа на Гугловскую? Очень не много, почти по пальцам можно пересчитать.
И есть огромное количество чьи ИТ совсем не похожи на Google.
Примечание: Главный редфлаг. Фраза «архитектура OpenClaw спроектирована вокруг модели с одним шлюзом» является ключевой для всей статьи — и одновременно главным редфлагом. Если система не проектировалась как мультиинстансная, попытки запустить ее в таком режиме — это архитектурно плохой паттерн. Все, что дальше предлагается — RWX-тома, shared NFS, Redis-локи — это костыли поверх фундамента, который не рассчитан на такую нагрузку.
Хорошее примечание. А что понимается под "проектировалась как мультиинстансная"? Какое явление природы показывает что надо проектировать как мультиинстансное или нет (а если нет, то как?)?.
Вообще то уже давно, в "современном" ИТ такой подход как централизованная архитектура отвергнут за не имением таких серверов и ОС которые были бы в состоянии "потянуть" в одиночку целое приложение со всеми его компонентами. Есть только ИБМ мэйнфрэйм и zOS способные это делать. Но ИБМ мэйнфрэйм в России существует в исчезающих количествах и в перспективе вообще может исчезнуть.
Например у нас где я работаю я слышал от одного из архитекторов что он не знает надо ли делать множество Кубернетес кластеров или достаточного одного. Очень поразительное, но показательное, откровение. Действительно, наверное, только Google понимает зачем и как использовать Кубернетес.
Я был два дня на курсах Микрософт по их AKS и понял что и они не имеют понимания как именно и почему нужно использовать те или иные объекты Ку. Лектор тупо рассказывала про эти объекты и не давала никаких рекомендаций. Кроме того что если нам понадобятся дополнительные ресурсы, то хорошо бы заранее про это сообщить в Azure.
Based on the provided search results, Nexign OSS and IBM InfoSphere Data Replication (IIDR) serve different primary purposes within the enterprise software ecosystem.
Nexign OSS is a comprehensive Operations Support System (OSS) designed specifically for telecommunications service providers, focusing on network management, service fulfillment, and assurance.
IBM InfoSphere Data Replication (IIDR) is a high-performance, log-based change data capture (CDC) solution used for real-time data replication, synchronization, and ETL feeding across diverse databases.
IIDR это про базы данных и в том числе ETL. Как @XManschремонтирует данный из постгри мне не понятно. Из приведенной цитаты видно что Nexign OSS не про базы данных вовсе.
чисто для себя сделал, оттестировал (за полгода, в одно рыло) и применял для личных целей патч для файловой системы CMS, который позволял выделенную одной VM область диска (она там называлась "минидиск") подключать по чтению/записи к другой VM
Вы возможно не совсем корректно описываете Ваше решение. Не знаю. Звучит странно.
Вообще то была и есть команда СР LINK для этого.
Минидиски можно было подключать к любому набору ВМ по чтению-записи. Другое дело что если так использовать диски CMS то они скоро убъются
. А вот диски ОС ЕС можно было использовать по чтению-записи несколькими машинами, при условии что переисывание содержимого сохраненного одним пользователем другим это Ок.
Я эту проблему решил однажды много лет назад примерно за час/полтора сделав сервисную машину с дотупом к минидиску общего пользования по записи, а для пользователей изменяющих файлы на этом диске по чтению, и написал простенькие REXX на сервисную машину и для пользователей, который у пользователя счтитывал файл в редактор (XEDIT) и после редактирования записывал файл на личный минидиск пользователя с последующей пересылкой файла на сервисную ВМ используя PUNCH and и READ. Таким образом запись файлов на диск серверной машины испоьзуя строго последовательное выполнение не приводили с убиванию этого диска.
До IUCV была аналогичная службв VMCF: VMCF was the predecessor to IUCV, but continued to be used and supported within VM/SP.
Про IUCV ИИ пишет что IUCV Introduced in 1980 with VM/SP Release 1 to enable message-based interaction.
Попытки были разной степени успешности: к примеру TSO на ОС ЕС 6 работала на этой конкретной 1045 днём минут по пятнадцать
Из почти ста ВЦ, которые я успел посетить за 8 лет работы в СоюзЭВМкомплексе (По "Конус") только на одном ВЦ - ЖД использовали TSO. На остальных это был либо Примус либо что-то из доброго десятка аналогов написаных в СССР.
я вот как-то в свое время не поинтересовался про ДЕМОС для VM (клон Unix - ее системщики притаскивали на посмотреть, но не взяли: советские ЕС 7927 рисовали большие и маленькие буквы одинаково, потому что места в ПЗУ знакогенератора под маленькие буквы не было, оно было занято русскими буквами), и теперь я даже не скажу, можно ли было из нее сделать хранимую систему.
ИИ говорит:
ДЕМОС (Диалоговая Единая Мобильная Операционная Система) — советская UNIX-подобная ОС, созданная в начале 1980-х на базе BSD. Разработана программистами Института атомной энергии им. Курчатова для отечественных ЭВМ (СМ ЭВМ). Использовалась как основа для ранних сетей, включая «Компания «Демос «Релком».
Ключевые факты о ДЕМОС:
Назначение: Первая отечественная операционная система для ЭВМ серии СМ (СМ-4, СМ-1420, позже Электроника-85/82).
Но тот же ИИ говорит:
МОС ЕС (Мобильная Операционная Система) — советская операционная система типа UNIX, разработанная в 1980-х годах в НИЦЭВТ (Научно-исследовательский центр электронной вычислительной техники) под руководством В.В. Митрофанова. Она предназначалась для персональных компьютеров и машин ЕС ЭВМ, обеспечивая совместимость с Unix.
Вот этот МОС и мог бы работать на ВМ под VM/SP без проблем, в том числе и как хранимая система занружаться. Сам я с этими системами в те давние годы не сталкивался и никакого интереса к ним не испытывал.
советские ЕС 7927 рисовали большие и маленькие буквы одинаково, потому что места в ПЗУ знакогенератора под маленькие буквы не было, оно было занято русскими буквами)
Вам уже три года назад здесь на Хабре на эту глупость отвечали другие::
Единственное, что доставало - это отсутствие заглавной буквы Ё. На матричный принтер печаталось без проблем. Обмен с ПК тоже проходил нормально, через плату, изображавшую из себя тот же EC-7927.
Да и сколько уж там так места не хватало под какой-то десяток другой символов. Все было нормально, сортировать только данные по алфавиту используя SORT в SQL было невозможно без поддержки дополнительным кодом. Но и это было.
Что касаемо создания хр.системы CMS то Вы сами написали что:
я этим не занимался - мне бы системщики все равно хранимую систему сделать не позволили, и вообще привилегии админские у меня там были незаконные (я же писал - хакерствовал), просто была договоренность с тамошним реальным специалистом
Я наоборот всегда и везде работал с доступом системщика и сохранял системы иножество раз (как Вы наверное уже поняли это была моя работа, причем на многои, разных ВЦ.
16МБ нужны были чтобы сформировать память для участков хранимой системы CMS, которая размещалась от линии 16 МБ вниз. Для этого и загружалась система не с хранимого образа, а с минидиск 190 - резидент CMS. Команда IPL выглядела примерно так:
IPL 190 CLEAR PARM SAVESYS CMS
При такой загрузке система (CMS) понимала что раз ее загружают с диска то надо сформировать весь образ системы в памяти (в 16 МБ) и в правидьный момент выдать команду СР SAVESYS. После этого, чтобы загрузиться с хр.системы нужно было уменьшить размер памяти ВМ (у простых пользователей она всегда была ограничена) до значения которое оставляла верхнюю память выше памяти ВМ вне доступности для програм ВМ. Есть там еще ньюансы, но за давностью лет я их все не помню и копаться в этом большого смысла не вижу.
Вы говорите что "Видимо поэтому ни VMWare, ни MS созданием хранимых систем не заморачивались. " и что "А так аппаратура иметь разделяемые сегменты памяти вополне позволяет.". В случае МФ и VM с хр.системами не только и не столько разделение участков памяти (а может и вовсе не это, потому что в "Принципах работы современного МФ" (не знаю какого уровня, но точно не 370, может 390 и выше), есть механизмы общения программ в разных адресных пространствах через общие сегменты в которые программы могут писать и читаь данные для общения) сколько возможность использования кода в сегментах к которым никакая ВМ не имеет доступа по записи (как я писал выше даже память находящаяся за пределами памяти ВМ). Насколько я помню это достигалось (в VM/SP, как это сейчас в zVM я не знаю) тем что в таблице страниц ВМ часть указателей на память сегментов хр.систем и разделяемых сегментов модифицировались так что они указывали на одну и ту же копию сегментов хр. системы (вне адресных пространств ВМ использующих эту систему) и защищенных от записи. Таким образом когда выполнялись программы ядра и расширения ядра это все происходило вне памяти ВМ, а данные этих РЕЕНТАРАБЕЛЬНЫХ программ размещались в тех сегментах ВМ которые были доступны для записи.
z/VM keeps track of the NSSs that are currently loaded for virtual machines and the shared storage they contain. Virtual machines that are sharing storage also share the page tables used for those segments.
Я пишу по памяти про дела 30 летней давности. Могу ошибаться, но не сильно и не принципиально.
Один хрен. Их уровень - переклеивание шильдиков, максимум - мелкие доработки.
Нет надо задирать нос. Ты по сравнению с ребятами из НИИЭВМ пигмей.
....был именно IBM VM/SP (т.е. следующая версия), оригинальный, только вот патч под конкретную машину для него сделали (
Последния версия СВМ ЕС была адаптацией VM/SP 6. Поставка состояла из легальной оригинальной VM/SP 6 от ИБМ и пакета изменений/дополнений сделаных в НИИЭВМ. Работать с оригинальной было невозможно. Это была древесина. С пакетом НИИЭВМ с этим можно было работать.
Я всегда считал тех кто щеголял использованием "оригинальных" систем от ИБМ пижонами и садомазахистами. Представляю как рыдали ваши обычные пользователи. Как те ежики что кололись, плакали но ели кактус.
Не любая. Для сохранения системы нужна точка, в которой система находится в покое. Вот вам цитата про условия, в которых можно вызывать команду SAVESYS ( ....
Например какая не могла? Их немного было на мейнфреймах. Назови.
Для сохранении CMS нужно было увеличить память ВМ до 16 МБ, и загрузить ее с диска с правильной строкой в параметре PARM команды IPL. Она в этом случае сама себя сохраняла.
Смутно помню (30 лет не подходил к VM) что делал я хранимую систему DOS (или ОС ЕС) и нужно было лишь команду ATTN чтобы после загрузки с хранимой ее разбудить. Не уверен.
БОС (от НИЦЭВТ, который тоже по твоему шильдики перекливал. Слышал про БОС?) тоже имел хранимую систему, подготовленную в НИЦЭВТ. Что еще можно было тогда хотеть, иметь чтобы выполнять на ВМ?
А реентерабельность, скорее всего, и не требуется: не помню, чтобы CMS ей страдала,
Память хранимых систем и сегментов была защищена от изменений в ВМ. Как можно в таком случае выполнять нереентерабельную программу? Вот тебе AI в помощь:
In z/VM and z/OS environments, Named Saved Systems (NSS) and Shared Segments are used to load reentrant modules (executable code that does not modify itself) into shared memory to maximize efficiency. This allows multiple virtual machines or users to share a single copy of the code in memory, reducing system memory usage.
IBM VM/370, работавшей на советском клоне IBM System/370 (нашлись какие-то умельцы в Союзе, которые ее адаптировали).
Это были не "умельцы", а организованные в научноисследовательских инстутах Минрадиопрома группы профессоналов. В частности над СВМ ЕС (VM/370) работал отдел НИИЭВМ (Минск) численностью порядка 60 человек. Я многоих из них знал, а меня знали все в отделе. Это потому что я, как они сами меня называли, был их работодателем. Ваня Шаклеин придумал так меня называть. В командировки на НИИЭВМ я ездил, в 80-е, раз шесть в год. Последний раз был там в 2015, а с директором НИИЭВМсервис разговаривал на прошлой неделе.
"Умельцем", кстати, и я в некотором роде был. Находил баги и рассказывал про них разработчикам.
Ага, называлась такая штука «хранимая система», и я лично не знаю, реализовывал ли кто-нибудь ещё эту концепцию, полагаю, что вряд ли: она требует контроля и над кодом гипервизора и над кодом ОС, таким контролем обладает ещё только MS, а MS AFAIK этого так и не сделала.
Ничем таким MS не обладает потому что MS зажат возможностями х86.
Любая мыслемая ОС на МФ может использовать VM-ские хранимые системы и разделяемые сегменты памяти. Для этого не нужен контроль над кодом этих ОС. Нужен лишь механизм самой такой ОС чтобы она имела фрагменты ядра и библиотек обеспечивающих механизм реентерабельности, или по русски многовходимость. Это когда программы не модифицирую сами себя и не имею динамических областей данных в самих себе.
Гипервизор VM изначально готов к таким ОС. Это все укладывается в "Принципы работы МФ" и следует из них.
Пользователи мейнфреймов платят за процессорное время.
Да-да, вы купили СВОЙ мейнфрейм, купили продукт (или подписку на продукт), а потом ещё в конце месяца, вместе с выплатами зарплат сотрудникам, уплаты коммунальных платежей отстёгиваете IBM денежку за процессорное время ... которое тратили продукты, за которые вы уже заплатили.
Возможно, именно поэтому высокоуровневые языки трудно приживаются в этом мире.
Более того, т.к. никто не хочет платить за процессорное время, появились разновидности «конфигурации» процессора (а точнее их аналога ядер), типо zAAP (для Java) или zIIP (для баз данных) – за которые пользователи уже не платят (или платят по более дешёвым тарифам). Причём вы ваше обычное «ядро» CP, например, можете поменять в zAAP если у вас много Java приложений, тем самым можно сэкономить пару тысяч долларов.
Уверен что сами Вы в процессе связаном с отчетностью по процессорному времени не участвовали никогда и пересказываете информацию из третьих или четвертых уст.
Я, в течении многоих лет, каждый месяц подготавливал информацию об использовании МФ и отправлял эти отчеты в ИБМ.
На самом деле это работает в точности до наоборот.
Во-первых, продукты ИБМ для МФ делятся на две группы. One time fixed price, когда продукт покупается по фиксированной цене и навсегда. Вторая группа (классика МФ) это когда оплата взимается помесячно и зависит от capacity model МФ на котором этот продукт используется. Т.е. чем меньше производительность МФ тем меньше цена. Capacity model может изменятся и соответстветственно будет изменяться цена. С каждым новым поколением МФ разценки уменьшаются. Во вторую группу входят такие продукты как z/OS, CICS, DB2 for z/OS, Cobol. В первую группу входит например WebSphere for z/OS.
Во-вторых, в общем случае периодические платежи зависят только от capacity model и они не меняются от использования процессорного время (на саом деле процессорное время это только часть того показателя который измеряется и используется в отчетах).
Есть и другие обстоятельства влияющие на ценообразование за классические продукты. Но принцип таков что цена, определяемая моделью МФ это потолок цены. В ряде случаев, для которых и подаются отчеты отчеты использования в ИБМ для инвойсов, это дает возможность пользователю платить меньше. Как правило МФ недогружены (из-за неумения их правильно использовать) и это весьма реально чтобы иметь экономию.
Это маркетинговый ход чтобы не снижания высоких цен для "классики МФ" - z/OS, CICS? DB2 for z/OS, WeShpere и т.д. - занять нишу в "современных ИТ" для сбыта мейнфреймовских компонент.
В этих МФ для Линукс все тоже самое что и в "МФ для классике", но "классика - z/OS" на этих МФ работать не будет, не "захочет".
Судя по содержанию статьи под "модернизацией мейнфреймов" понимается перевод Кобол програм на Java и последующий уход с мейнфреймов.
На самом деле имеет смысл модернизировать использование старых (по времени создания), но работающих приложений на том же Кобол без переписывания и ухода с МФ.
Что касается модного нынче термина "автоматизация" на МФ имеет несколько иной смысл чем тот который в этот термин вкладывается и существует десятилетия. Называется этот продукт System Automation и его функциональность покрывает все мыслемые потребности в автоматизации. Но для этого лучше всего сочетать System Automation c z/OS and WLM.
Короче говоря, у давно написаных и до сих пор работоспособных приложений на МФ, не важно на Кобол или каком-либо другом языке (их много, включая Java, C/C++), есть прекрасные перспективы модернизации без нудного, трудоемкого, дорогого и небезопасного переписывания и перехода на х86-64 платформу (к этому как я понял и клонят авторы статьи, скрываясь за "модернизация мейнфрейм) и оставаясь написаными на Кобол и выполняемыми на мейнфреймах.
Самая "маленькая" серия в 2012 году (бог мой как быстро время бежит) была не zEC12, а zBC12. Bussines Class. На такой машине сконфигурированной с 4 CPU и 32GB (zBC12 capacity model O04) ram компания где я работаю - Ontario Power Generation (opg.com) выполняла одно из самых важных своих приложений. В 2022 году это приложение перевели на сервера в облако Azure. На больше чем 30 серверов х86-64. Два года уже занимаются апгрейдом этого приложнения (на МФ это делалось на раз-два-три) и для этого разворачивают 50 серверов и будут "перескакивать" на них в апреле. Как перскочат будем посмотреть.
Системы на zBC12-O04 я остановил осенью прошлого года, а в этом году эту машину и другой МФ - z14 - вывезли. В среду на следущей неделе ИБМ будет уламывать OPG взять IBM LinuxONE. Будет их презентация. Что интересно Erwin - докладчик из IBM не называет LinuxONE мэйнфрэймом. И я его в этом поддерживаю. Хотя на самом деле конечно же LinuxONE это самый что нина есть МФ. Но с другой стороны с только Linux на нем, или на виртуалках под zVM, он фактически превращается в прайвет клауд. Хороший такой и мощный, но клауд типа Azure.
Расширенная поддержка виртуализации: можно сделать мультиплатформенный дата-центр c тысячами виртуальных машин Linux на одном мейнфрейме.
Линукс на МФ появился в самом начале рулевых. Я лично знаком с ибм-овцем предложившим эту идею. Его звать Jim Elliot (https://jlelliotton.blogspot.com/)
Виртуальные машины на МФ ведут свою историю с конца 60-х. В 80-е, начале 90-х я перевел почти все ВЦ Челябинской области на работу в виртуальных машинах на ЕС ЭВМ. Только ВЦ ЮУрЖД не перешди из-за их ориентации на MVS. Правильный кстати был выбор. Строго говоря MVS (z/OS) это самая правильная ОС для сервера. Никаких виртуализаций не надо потому что MVS это и есть виртуализация в лучшем ее понимании и исполнении. На современной z/OS можно выполнять юниксовские приложения, а также контейнеризованные юникс и линукс приложения. Что еще? Да есть zVM, да можно гонять тысячи виртуалок с Линукс. Но управлять этими виртуалками так как если это все гонять под z/OS z/VM не может, а z/OS может.
Никакой такой "расширенной" виртуализации на МФ не появилось с zEC12. Всегда можно было на виртуальной машине загружать любую ОС МФ без какго-либо "расширения".
В связи с нынешней модой впервые компании IBM вставила слова Elastic Cloud прямо в название мейнфрейма.
EC в названии zEC12 означает Enterprise Class. В названии zBC12 это Bussines Class.
ИБМ мэйнфрэймы всегда были эквивалентами нынешних облаков. В 70-е, 80-е и дальше на Западе существовали дата центры общего пользования построенные на МФ. Это изменилось когда начался down sizing - переход на мини под Uniх. А еще раньше когда цены на МФ стали снижаться (а цены на МФ всю их долгую историю стабильно снижаются) и это стало доступным небольшим компаниям. Еще надо понимать что МФ это в каждом поколении широчайший выбор моделей по производительности и соответственно цене. Практически для любых потребностей можно подобрать правильную модель и не париться. Вот и началось расползания по своим дата центрам. И вдруг, ура, вспомнили про совместное использование в публичных дата центрах назвав их облаками. .
Короче автор написал ствтью - прекрасный пример манипулирования фактами и домыслами. А в общем целом это очередная демонстрация незнания и непонимания ИБМ мэйнфрэймов, выдаваемые за истину не доказаную даже фактурным материалом статьи.
Итак, почему же серверы — это не мейнфреймы? Казалось бы, и те, и другие — это мощные компьютеры, выполняющие серверные роли.
Да ладно. По-Вашему можно ставить на одну дощечку старшую модель z17 c 200 корами CPU и тысячами каналов ввода-вывода и какой-либо х86-64 сервер?
МФ это полноценный дата центр. В одном МФ можно уместить ИТ довольно большого бизнеса. А для этого же на х86-64 нужны тысячи серверов. Я знаю о чем говорю.
В золотой век мейнфреймов (1960–1970-е) альтернатив им почти не было. Большие организации ставили «электронно-вычислительные машины» в специальных залах. Если нужна была машина поменьше — в то время существовал класс мини-компьютеров (например, DEC PDP) для средних задач.
В "золотой век" МФ, в США и вообще на Западе были такие бизнесы как Data Center с ИБМ МФ, которыми могли пользоваться и пользовались организации любых размеров. В пакетном режиме выполнялись их работы и оплата расчитывалась по фактическому использованию ресурсов. Была доступна и диалоговая работа, тоже с расчетом по факту.
Были бизнесы специализирующиеся на задачах широкого назначения. Например, бухгалтерских. Эти бизнесы аутсорсали, например, бухгалтерию любых бизнесов от малых до великих и тоже использовали МФ.
Не задач средних или больших. Есть средние и большие вычислительные потребности. На МФ можно выполнять смесь задач разных потребностей от микроскопических до гигантских. Миникомпьютеры в этом смысле имели ограничения. А современные облака уже становятся дорогим удовольствием.
Кроме того, исторически мейнфреймы работали под своими специализированными ОС (OS/360, z/OS и др.)
Ни OS/360 ни z/OS специализируемыми не являлись и не являются. Это, в некотором роде, самые что ни на есть универсальные ОС поддерживающие широчайший круг языков, протоколов и областей применения (БД, сервера приложений, Web сервера, клиент-сервер, и тд. в том числе все приложения TCP/IP
Когда появилась OS/360 никаких других ОС, используемых сегодня, еще и не было в помине, а те что были давно ушли в небытие.
"и др." включает zVM и Linux, разные его оттенки. Добавьте два варианта выполнения контэйнеризованных приложений, для Unix и Linix. Кстати Unix на МФ есть с середины 90-х, это одна из двух высокоинтегрированных операционных сред z/OS. Вторая - MVS. .
Эти машины были спроектированы для максимальной производительности, надёжности и пропускной способности ввода-вывода. В мейнфреймах исторически уделялось меньше внимания рекордной скорости процессора, зато огромное значение отводилось отказоустойчивости и параллельной обработке потоков данных. Также среди особенностей называются:
избыточность всех важных компонентов (без единой точки отказа);
мощные подсистемы ввода-вывода, умеющие разгружать центральный процессор и обеспечивать обратную совместимость с ПО прошлых поколений;
широкое использование виртуализации для максимальной загрузки системы.
Максимальная производительность вовсе не была целью. Целью была совместимость всех моделей поколения от самых младших до самых старших, а также между поколениями так что программы написанные для S/360 выполняются на System Z.
"параллельной обработке потоков данных" я бы для ясности и точности перефразировал это как "параллельная работа CPU и ввода-вывода. В это особенность МФ, а не в абстрактной "параллельной обработке потоков данных". Cколько там потоков паралельно (или последовательно) выполняется не так уж и важно, важно чтобы быстродействующие центральные устройства не занимались рутинным вводом-выводом с более медленными внешними устройствами. В х86 с этим до сих пор проблема.
Подсистемы ввода-вывода и совместимость это раздельные процессы. ПО в любом поколении изолировано от особенностей ввода-вывода.
Для максимальных загрузок системы (наверное мэйнфрэйм, не системы) используется не виртуализация (IBM VM), а MVS и его последователь z/OS. Только z/OS может обеспечить максимальную загрузку без деградаций. Это Вам говорит человек много проработавший с VM и еще больше с z/OS.
Да есть, но надо присматриваться чтобы найти. Я пытался, но не получилось с первого раза. Спасибо за наводку.
А Вы знаете ответ на его (нашего "архитектора") сомнения?
Я с самого начала как в ИТ началось деление на узкие специализации (тестеры, бизнес аналитики, архитекторы, администраторы, секьюрити) понял что это цирк. Нет, конечно, в серьезных фирмах разработчиках ОС такое деление имеет смысл, но в фирмах-пользователях только два направления имеют смысл - системное (или инфраструктура, которое включает в себя собственно системщиков т.е. архитекторов, администраторов, и секьюритиб как поднаправления), и прикладное, в которое входят и тестеры и бизнес-аналитики.
Наш "архитектор" начальник моего начальника и него самомго есть еще как минимум один начальник, считающий себя тоже "архитектором". Но кроме "архитектора" надо мной есть еще не мало "архитекторов" в нашем ИТ.
Ну а теперь Вы мне ответьте на вопрос "как у вас сажают брюкву с кожурою или без", т.е. как Вы решаете вопрос соотношения количества кластеров Ку с реальной структурой Вашего ИТ? Спросите Вашего "архитектора", который точно архитектор, а не плотник или каменщик. .
Интересно было бы посмотреть оригинал перевода, а больше от какой компании эта статья написана исходною
Не всегда оптимальны это скорее почти никогда не оптимальны. Коренная причина этому именно то что считается самым сильным моментом - кластеризация. Или иначе распределенность.
В условиях рапределенности практически всегда рано или поздно какие-то ноды окажутся бутылочным горлышком при том что други будут простаивать. У нас это регулярно происходит в конфигурации load balancer.
Только в случаях таких рабочих нагрузок какие имеются в Google это более менее оптимально. Но много ли таких чья ИТ похожа на Гугловскую? Очень не много, почти по пальцам можно пересчитать.
И есть огромное количество чьи ИТ совсем не похожи на Google.
Хорошее примечание. А что понимается под "проектировалась как мультиинстансная"? Какое явление природы показывает что надо проектировать как мультиинстансное или нет (а если нет, то как?)?.
Вообще то уже давно, в "современном" ИТ такой подход как централизованная архитектура отвергнут за не имением таких серверов и ОС которые были бы в состоянии "потянуть" в одиночку целое приложение со всеми его компонентами. Есть только ИБМ мэйнфрэйм и zOS способные это делать. Но ИБМ мэйнфрэйм в России существует в исчезающих количествах и в перспективе вообще может исчезнуть.
Например у нас где я работаю я слышал от одного из архитекторов что он не знает надо ли делать множество Кубернетес кластеров или достаточного одного. Очень поразительное, но показательное, откровение. Действительно, наверное, только Google понимает зачем и как использовать Кубернетес.
Я был два дня на курсах Микрософт по их AKS и понял что и они не имеют понимания как именно и почему нужно использовать те или иные объекты Ку. Лектор тупо рассказывала про эти объекты и не давала никаких рекомендаций. Кроме того что если нам понадобятся дополнительные ресурсы, то хорошо бы заранее про это сообщить в Azure.
IBM IDR и Nexign OSS две разные функциональности:
IIDR это про базы данных и в том числе ETL. Как @XMansch ремонтирует данный из постгри мне не понятно. Из приведенной цитаты видно что Nexign OSS не про базы данных вовсе.
Наши английскую блоху подковать завсегда смогут.
Вы возможно не совсем корректно описываете Ваше решение. Не знаю. Звучит странно.
Вообще то была и есть команда СР LINK для этого.
Минидиски можно было подключать к любому набору ВМ по чтению-записи. Другое дело что если так использовать диски CMS то они скоро убъются
. А вот диски ОС ЕС можно было использовать по чтению-записи несколькими машинами, при условии что переисывание содержимого сохраненного одним пользователем другим это Ок.
Я эту проблему решил однажды много лет назад примерно за час/полтора сделав сервисную машину с дотупом к минидиску общего пользования по записи, а для пользователей изменяющих файлы на этом диске по чтению, и написал простенькие REXX на сервисную машину и для пользователей, который у пользователя счтитывал файл в редактор (XEDIT) и после редактирования записывал файл на личный минидиск пользователя с последующей пересылкой файла на сервисную ВМ используя PUNCH and и READ. Таким образом запись файлов на диск серверной машины испоьзуя строго последовательное выполнение не приводили с убиванию этого диска.
До IUCV была аналогичная службв VMCF: VMCF was the predecessor to IUCV, but continued to be used and supported within VM/SP.
Про IUCV ИИ пишет что IUCV Introduced in 1980 with VM/SP Release 1 to enable message-based interaction.
Из почти ста ВЦ, которые я успел посетить за 8 лет работы в СоюзЭВМкомплексе (По "Конус") только на одном ВЦ - ЖД использовали TSO. На остальных это был либо Примус либо что-то из доброго десятка аналогов написаных в СССР.
ИИ говорит:
ДЕМОС (Диалоговая Единая Мобильная Операционная Система) — советская UNIX-подобная ОС, созданная в начале 1980-х на базе BSD. Разработана программистами Института атомной энергии им. Курчатова для отечественных ЭВМ (СМ ЭВМ). Использовалась как основа для ранних сетей, включая «Компания «Демос «Релком».
Ключевые факты о ДЕМОС:
Назначение: Первая отечественная операционная система для ЭВМ серии СМ (СМ-4, СМ-1420, позже Электроника-85/82).
Но тот же ИИ говорит:
МОС ЕС (Мобильная Операционная Система) — советская операционная система типа UNIX, разработанная в 1980-х годах в НИЦЭВТ (Научно-исследовательский центр электронной вычислительной техники) под руководством В.В. Митрофанова. Она предназначалась для персональных компьютеров и машин ЕС ЭВМ, обеспечивая совместимость с Unix.
Вот этот МОС и мог бы работать на ВМ под VM/SP без проблем, в том числе и как хранимая система занружаться. Сам я с этими системами в те давние годы не сталкивался и никакого интереса к ним не испытывал.
Вам уже три года назад здесь на Хабре на эту глупость отвечали другие::
У Вас какие-то странные были EC-7927. Во всех, которые я встречал, знакогенератор был полный. Как тут https://wp.wiki-wiki.ru/wp/index.php/ДКОИ-8
Единственное, что доставало - это отсутствие заглавной буквы Ё. На матричный принтер печаталось без проблем. Обмен с ПК тоже проходил нормально, через плату, изображавшую из себя тот же EC-7927.
Да и сколько уж там так места не хватало под какой-то десяток другой символов. Все было нормально, сортировать только данные по алфавиту используя SORT в SQL было невозможно без поддержки дополнительным кодом. Но и это было.
Что касаемо создания хр.системы CMS то Вы сами написали что:
я этим не занимался - мне бы системщики все равно хранимую систему сделать не позволили, и вообще привилегии админские у меня там были незаконные (я же писал - хакерствовал), просто была договоренность с тамошним реальным специалистом
Я наоборот всегда и везде работал с доступом системщика и сохранял системы иножество раз (как Вы наверное уже поняли это была моя работа, причем на многои, разных ВЦ.
16МБ нужны были чтобы сформировать память для участков хранимой системы CMS, которая размещалась от линии 16 МБ вниз. Для этого и загружалась система не с хранимого образа, а с минидиск 190 - резидент CMS. Команда IPL выглядела примерно так:
IPL 190 CLEAR PARM SAVESYS CMS
При такой загрузке система (CMS) понимала что раз ее загружают с диска то надо сформировать весь образ системы в памяти (в 16 МБ) и в правидьный момент выдать команду СР SAVESYS. После этого, чтобы загрузиться с хр.системы нужно было уменьшить размер памяти ВМ (у простых пользователей она всегда была ограничена) до значения которое оставляла верхнюю память выше памяти ВМ вне доступности для програм ВМ. Есть там еще ньюансы, но за давностью лет я их все не помню и копаться в этом большого смысла не вижу.
Вы говорите что "Видимо поэтому ни VMWare, ни MS созданием хранимых систем не заморачивались. " и что "А так аппаратура иметь разделяемые сегменты памяти вополне позволяет.". В случае МФ и VM с хр.системами не только и не столько разделение участков памяти (а может и вовсе не это, потому что в "Принципах работы современного МФ" (не знаю какого уровня, но точно не 370, может 390 и выше), есть механизмы общения программ в разных адресных пространствах через общие сегменты в которые программы могут писать и читаь данные для общения) сколько возможность использования кода в сегментах к которым никакая ВМ не имеет доступа по записи (как я писал выше даже память находящаяся за пределами памяти ВМ). Насколько я помню это достигалось (в VM/SP, как это сейчас в zVM я не знаю) тем что в таблице страниц ВМ часть указателей на память сегментов хр.систем и разделяемых сегментов модифицировались так что они указывали на одну и ту же копию сегментов хр. системы (вне адресных пространств ВМ использующих эту систему) и защищенных от записи. Таким образом когда выполнялись программы ядра и расширения ядра это все происходило вне памяти ВМ, а данные этих РЕЕНТАРАБЕЛЬНЫХ программ размещались в тех сегментах ВМ которые были доступны для записи.
Я пишу по памяти про дела 30 летней давности. Могу ошибаться, но не сильно и не принципиально.
Нет надо задирать нос. Ты по сравнению с ребятами из НИИЭВМ пигмей.
Последния версия СВМ ЕС была адаптацией VM/SP 6. Поставка состояла из легальной оригинальной VM/SP 6 от ИБМ и пакета изменений/дополнений сделаных в НИИЭВМ. Работать с оригинальной было невозможно. Это была древесина. С пакетом НИИЭВМ с этим можно было работать.
Я всегда считал тех кто щеголял использованием "оригинальных" систем от ИБМ пижонами и садомазахистами. Представляю как рыдали ваши обычные пользователи. Как те ежики что кололись, плакали но ели кактус.
Например какая не могла? Их немного было на мейнфреймах. Назови.
Для сохранении CMS нужно было увеличить память ВМ до 16 МБ, и загрузить ее с диска с правильной строкой в параметре PARM команды IPL. Она в этом случае сама себя сохраняла.
Смутно помню (30 лет не подходил к VM) что делал я хранимую систему DOS (или ОС ЕС) и нужно было лишь команду ATTN чтобы после загрузки с хранимой ее разбудить. Не уверен.
БОС (от НИЦЭВТ, который тоже по твоему шильдики перекливал. Слышал про БОС?) тоже имел хранимую систему, подготовленную в НИЦЭВТ. Что еще можно было тогда хотеть, иметь чтобы выполнять на ВМ?
Память хранимых систем и сегментов была защищена от изменений в ВМ. Как можно в таком случае выполнять нереентерабельную программу? Вот тебе AI в помощь:
Это были не "умельцы", а организованные в научноисследовательских инстутах Минрадиопрома группы профессоналов. В частности над СВМ ЕС (VM/370) работал отдел НИИЭВМ (Минск) численностью порядка 60 человек. Я многоих из них знал, а меня знали все в отделе. Это потому что я, как они сами меня называли, был их работодателем. Ваня Шаклеин придумал так меня называть. В командировки на НИИЭВМ я ездил, в 80-е, раз шесть в год. Последний раз был там в 2015, а с директором НИИЭВМсервис разговаривал на прошлой неделе.
"Умельцем", кстати, и я в некотором роде был. Находил баги и рассказывал про них разработчикам.
Ничем таким MS не обладает потому что MS зажат возможностями х86.
Любая мыслемая ОС на МФ может использовать VM-ские хранимые системы и разделяемые сегменты памяти. Для этого не нужен контроль над кодом этих ОС. Нужен лишь механизм самой такой ОС чтобы она имела фрагменты ядра и библиотек обеспечивающих механизм реентерабельности, или по русски многовходимость. Это когда программы не модифицирую сами себя и не имею динамических областей данных в самих себе.
Гипервизор VM изначально готов к таким ОС. Это все укладывается в "Принципы работы МФ" и следует из них.
Уверен что сами Вы в процессе связаном с отчетностью по процессорному времени не участвовали никогда и пересказываете информацию из третьих или четвертых уст.
Я, в течении многоих лет, каждый месяц подготавливал информацию об использовании МФ и отправлял эти отчеты в ИБМ.
На самом деле это работает в точности до наоборот.
Во-первых, продукты ИБМ для МФ делятся на две группы. One time fixed price, когда продукт покупается по фиксированной цене и навсегда. Вторая группа (классика МФ) это когда оплата взимается помесячно и зависит от capacity model МФ на котором этот продукт используется. Т.е. чем меньше производительность МФ тем меньше цена. Capacity model может изменятся и соответстветственно будет изменяться цена. С каждым новым поколением МФ разценки уменьшаются. Во вторую группу входят такие продукты как z/OS, CICS, DB2 for z/OS, Cobol. В первую группу входит например WebSphere for z/OS.
Во-вторых, в общем случае периодические платежи зависят только от capacity model и они не меняются от использования процессорного время (на саом деле процессорное время это только часть того показателя который измеряется и используется в отчетах).
Есть и другие обстоятельства влияющие на ценообразование за классические продукты. Но принцип таков что цена, определяемая моделью МФ это потолок цены. В ряде случаев, для которых и подаются отчеты отчеты использования в ИБМ для инвойсов, это дает возможность пользователю платить меньше. Как правило МФ недогружены (из-за неумения их правильно использовать) и это весьма реально чтобы иметь экономию.
Это маркетинговый ход чтобы не снижания высоких цен для "классики МФ" - z/OS, CICS? DB2 for z/OS, WeShpere и т.д. - занять нишу в "современных ИТ" для сбыта мейнфреймовских компонент.
В этих МФ для Линукс все тоже самое что и в "МФ для классике", но "классика - z/OS" на этих МФ работать не будет, не "захочет".
Судя по содержанию статьи под "модернизацией мейнфреймов" понимается перевод Кобол програм на Java и последующий уход с мейнфреймов.
На самом деле имеет смысл модернизировать использование старых (по времени создания), но работающих приложений на том же Кобол без переписывания и ухода с МФ.
Что касается модного нынче термина "автоматизация" на МФ имеет несколько иной смысл чем тот который в этот термин вкладывается и существует десятилетия. Называется этот продукт System Automation и его функциональность покрывает все мыслемые потребности в автоматизации. Но для этого лучше всего сочетать System Automation c z/OS and WLM.
Короче говоря, у давно написаных и до сих пор работоспособных приложений на МФ, не важно на Кобол или каком-либо другом языке (их много, включая Java, C/C++), есть прекрасные перспективы модернизации без нудного, трудоемкого, дорогого и небезопасного переписывания и перехода на х86-64 платформу (к этому как я понял и клонят авторы статьи, скрываясь за "модернизация мейнфрейм) и оставаясь написаными на Кобол и выполняемыми на мейнфреймах.
Обращайтесь ко мне если хотите узнать как.
Это все совсем другая песня. Современный ИБМ МФ не имеет аналогов.
Самая "маленькая" серия в 2012 году (бог мой как быстро время бежит) была не zEC12, а zBC12. Bussines Class. На такой машине сконфигурированной с 4 CPU и 32GB (zBC12 capacity model O04) ram компания где я работаю - Ontario Power Generation (opg.com) выполняла одно из самых важных своих приложений. В 2022 году это приложение перевели на сервера в облако Azure. На больше чем 30 серверов х86-64. Два года уже занимаются апгрейдом этого приложнения (на МФ это делалось на раз-два-три) и для этого разворачивают 50 серверов и будут "перескакивать" на них в апреле. Как перскочат будем посмотреть.
Системы на zBC12-O04 я остановил осенью прошлого года, а в этом году эту машину и другой МФ - z14 - вывезли. В среду на следущей неделе ИБМ будет уламывать OPG взять IBM LinuxONE. Будет их презентация. Что интересно Erwin - докладчик из IBM не называет LinuxONE мэйнфрэймом. И я его в этом поддерживаю. Хотя на самом деле конечно же LinuxONE это самый что нина есть МФ. Но с другой стороны с только Linux на нем, или на виртуалках под zVM, он фактически превращается в прайвет клауд. Хороший такой и мощный, но клауд типа Azure.
Линукс на МФ появился в самом начале рулевых. Я лично знаком с ибм-овцем предложившим эту идею. Его звать Jim Elliot (https://jlelliotton.blogspot.com/)
Виртуальные машины на МФ ведут свою историю с конца 60-х. В 80-е, начале 90-х я перевел почти все ВЦ Челябинской области на работу в виртуальных машинах на ЕС ЭВМ. Только ВЦ ЮУрЖД не перешди из-за их ориентации на MVS. Правильный кстати был выбор. Строго говоря MVS (z/OS) это самая правильная ОС для сервера. Никаких виртуализаций не надо потому что MVS это и есть виртуализация в лучшем ее понимании и исполнении. На современной z/OS можно выполнять юниксовские приложения, а также контейнеризованные юникс и линукс приложения. Что еще? Да есть zVM, да можно гонять тысячи виртуалок с Линукс. Но управлять этими виртуалками так как если это все гонять под z/OS z/VM не может, а z/OS может.
Никакой такой "расширенной" виртуализации на МФ не появилось с zEC12. Всегда можно было на виртуальной машине загружать любую ОС МФ без какго-либо "расширения".
EC в названии zEC12 означает Enterprise Class. В названии zBC12 это Bussines Class.
ИБМ мэйнфрэймы всегда были эквивалентами нынешних облаков. В 70-е, 80-е и дальше на Западе существовали дата центры общего пользования построенные на МФ. Это изменилось когда начался down sizing - переход на мини под Uniх. А еще раньше когда цены на МФ стали снижаться (а цены на МФ всю их долгую историю стабильно снижаются) и это стало доступным небольшим компаниям. Еще надо понимать что МФ это в каждом поколении широчайший выбор моделей по производительности и соответственно цене. Практически для любых потребностей можно подобрать правильную модель и не париться. Вот и началось расползания по своим дата центрам. И вдруг, ура, вспомнили про совместное использование в публичных дата центрах назвав их облаками. .
Короче автор написал ствтью - прекрасный пример манипулирования фактами и домыслами. А в общем целом это очередная демонстрация незнания и непонимания ИБМ мэйнфрэймов, выдаваемые за истину не доказаную даже фактурным материалом статьи.
Да ладно. По-Вашему можно ставить на одну дощечку старшую модель z17 c 200 корами CPU и тысячами каналов ввода-вывода и какой-либо х86-64 сервер?
МФ это полноценный дата центр. В одном МФ можно уместить ИТ довольно большого бизнеса. А для этого же на х86-64 нужны тысячи серверов. Я знаю о чем говорю.
Отдельный МФ это сотни-тысячи серверов.
В "золотой век" МФ, в США и вообще на Западе были такие бизнесы как Data Center с ИБМ МФ, которыми могли пользоваться и пользовались организации любых размеров. В пакетном режиме выполнялись их работы и оплата расчитывалась по фактическому использованию ресурсов. Была доступна и диалоговая работа, тоже с расчетом по факту.
Были бизнесы специализирующиеся на задачах широкого назначения. Например, бухгалтерских. Эти бизнесы аутсорсали, например, бухгалтерию любых бизнесов от малых до великих и тоже использовали МФ.
Не задач средних или больших. Есть средние и большие вычислительные потребности. На МФ можно выполнять смесь задач разных потребностей от микроскопических до гигантских. Миникомпьютеры в этом смысле имели ограничения. А современные облака уже становятся дорогим удовольствием.
Ни OS/360 ни z/OS специализируемыми не являлись и не являются. Это, в некотором роде, самые что ни на есть универсальные ОС поддерживающие широчайший круг языков, протоколов и областей применения (БД, сервера приложений, Web сервера, клиент-сервер, и тд. в том числе все приложения TCP/IP
Когда появилась OS/360 никаких других ОС, используемых сегодня, еще и не было в помине, а те что были давно ушли в небытие.
"и др." включает zVM и Linux, разные его оттенки. Добавьте два варианта выполнения контэйнеризованных приложений, для Unix и Linix. Кстати Unix на МФ есть с середины 90-х, это одна из двух высокоинтегрированных операционных сред z/OS. Вторая - MVS. .
А также Security - непревзойденная на х86.
Максимальная производительность вовсе не была целью. Целью была совместимость всех моделей поколения от самых младших до самых старших, а также между поколениями так что программы написанные для S/360 выполняются на System Z.
"параллельной обработке потоков данных" я бы для ясности и точности перефразировал это как "параллельная работа CPU и ввода-вывода. В это особенность МФ, а не в абстрактной "параллельной обработке потоков данных". Cколько там потоков паралельно (или последовательно) выполняется не так уж и важно, важно чтобы быстродействующие центральные устройства не занимались рутинным вводом-выводом с более медленными внешними устройствами. В х86 с этим до сих пор проблема.
Подсистемы ввода-вывода и совместимость это раздельные процессы. ПО в любом поколении изолировано от особенностей ввода-вывода.
Для максимальных загрузок системы (наверное мэйнфрэйм, не системы) используется не виртуализация (IBM VM), а MVS и его последователь z/OS. Только z/OS может обеспечить максимальную загрузку без деградаций. Это Вам говорит человек много проработавший с VM и еще больше с z/OS.