Comments 143
А есть такие, кто их никогда не видел. Можно ли написать текст одновременно интересный для двух этих категорий читателей? Не знаю, но подозреваю что это был бы непростой вызов для автора.
Прошу прощения, но статья получилась ни о чем. Все-таки читатели на Хабре в большинстве своём 80-, Альцгеймером не страдают, и им (нам) можно вполне успешно объяснить несколько более сложные концепции. Где-то когда-то я что-то слышал про то, что в мейнфреймах намного эффективнее распараллеливается ввод-вывод, благодаря чему на нём by design могут работать намного больше пользователей (процессов?) не влияя друг на друга в плане производительности, чем на x86, и только в последние годы, с вводом облачных вычислений в мейнстрим, x86 смогли обеспечить схожий уровень параллелизма, который мейнфреймы обеспечивают уже очень давно. Что-то где-то слышал про нативную поддержку десятичной арифметики, что очень востребованно финансовыми приложениями, которые из-за этого сильно теряют в производительности при портировании на x86…
Но это все на уровне "кажется, я где-то об этом слышал", и я совершенно не уверен, что все на самом деле так. Но это примеры того, что было бы интересно узнать от человека, работающего с мейнфреймами, читателям Хабра.
Это правда, потому что ввод-вывод выполняется отдельными процессорами, выполняющими свои команды (специфичные для устройства), включая например поиск записи по ключу на диске (автономно от CPU).
>нативную поддержку десятичной арифметики
Тоже правда.
Только это все было правдой уже 20 лет назад. Или даже 30. Потому что то что я вам сейчас отвечаю — это мой опыт, датированный примерно серединой 1990-х.
Ничего нового тут нет. Для свежей статьи 2021 года это банально.
Извините, а разве 20-30 лет назад уже был Хабр, и где-то можно увидеть те статьи?
Статьи тут кстати были, я могу припомнить чуть больше двух :)
Это какое-то лукавство — говорить о надежности, когда она обеспечивается физически одной железкой, пусть и внутри у неё все хотсвап, вплоть до памяти и процессора.
Сейчас надёжность — это только распределённые системы, но это не про мейнфреймы.
miga, извините, промахнулась, не на ту стрелочку тыкнула.
Ничто не мешает иметь несколько мейнфреймов в нескольких в географически распределенных дата-центрах и распределять нагрузку между ними. Тут принципиальной разницы с другими платформами нет.
Кроме того, на основе операционной системы z/OS можно построить кластер (aka SYSPLEX) с узлами active-active на расстоянии (если память не подводит) до 100 км. И иметь возможность, например, единой копии СУБД, которую можно обновлять с любого из узлов.
вобщем не взлетело.
Да, блокировки (не все подряд) хранятся в CF (Coupling Facility), измененные страницы таблиц — тоже в CF. Да, это может стать узким местом.
Работа по оптимизации сигнализации и снижению нагрузки на CF идет постоянно и на всех уровнях: внутренний код CF, z/OS, прикладное ПО под z/OS (DB2, MQ, CICS, и т.д.).
Ну и дальше идет уже архитектура приложений, которые все это используют, архитектура таблиц, оптимизация конкретных запросов.
Т.е. сделать этому кластеру «плохо» — можно. Но и пространство для маневра тоже есть.
А так, помимо масштабирования производительности, кластер (DB2 Data Sharing group) позволяет прозрачно для приложения «потерять» один из узлов, обновить СУБД без останова всего кластера, работать с разным «уровнем» обновлений на разных узлах и т.п.
рынок уже все расставил по местам и рулят БД кластеры не из МФ
Я похоже живу и работаю в совсем другой реальности где и IBM System z и продукты для этой платформы вполне себе живы и востребованы.
Для тех кому интересно, оставлю здесь ссылку на документацию, в ней описано как происходит процесс изменения данных в случае DB2 в режиме Data Sharing:How an update happens.
Более подробно можно поискать ключевые слова «Lock Avoidance», «commit log sequence number (CLSN)» и блог «Robert Catterall».
Половина искусства администрирования DB2 состоит в настройке системы блокировок. Сколько их там, 28 типов?
В отдельных случаях можно «покрутить» гранулярность блокировки для таблицы (одна запись, страница, партиция, таблица) и предел после которого происходит эскалация блокировки. Но это не так часто нужно делать.
Чаще, смотрится топ-10 запросов, которые или долго выполняются, или кушают неприличное количество ресурсов и далее принимаются меры или со стороны СУБД ( индексы, определенные виды статистики и т.п.) или со стороны прикладного ПО (замена SQL-запроса на более «адекватный»).
Дополнительно можно «отстреливать» запросы которые превышают лимиты по потреблению, но не для всякой бизнес-логики это применимо.
К примеру, в чем на практике (и в конкретных устройствах) воплощается идея из статьи «Мейнфреймы изначально разрабатываются чтобы переживать различные природные катастрофы» (звучит как пустая фраза из рекламного проспекта). Чем подходы реализации надежности отличаются от резервирования блоков питания, процессов и т.п. у «стандартных» x86 серверов? Кто эти компании, которые до сих пор покупают мейнфреймы и для каких задач их используют (например, в Вильнюсе)?
Конечно, было бы интересно сравнить производительность каким-нибудь архитектурно независимым тестом типа Dhrystone. Однако, если оплачивается процессорное время уже купленного устройства (вот пишу и даже не верится что так еще бывает...) это, наверное, невозможно. Как кстати определяют процессорное время, есть какой-то «одометр» с защитой от «скрутки»? По результатам месяца выписывают премию за экономию процессорного времени? ;-)
Я конечно не знаю, как это принято у серьёзных взрослых дяденек, но оплата процессорного времени своего компьютера выглядит дикостью. Под любой взимаемой оплатой должна лежать какая-то экономическая основа: обоснованные реальные (или хотя бы потенциальные, типа обеспечения гарантии) затраты вендора. Иначе все это выглядит, как плата за воздух, а политика IBM выглядит как: как бы нам ещё ободрать клиента.
Интересно, как это всё оформлено юридически? Если клиент не станет платить за время? Отберут мейнфрейм? :)) Он клиент просто лишится поддержки? Понятно, что поддержка жизненно нужна, поэтому наверное получается, что процессорное время — это просто способ тарификации техподдержки?
Давайте представим. У вас есть предприятие, которому раз в квартал надо три дня считать отчётность. Пиковая нагрузка (условно) в 10 раз выше обычной. В этом случае вы заказываете машину у IBM с кучей процессоров, но 90 % из них активируете в пиковые периоды, оплачивая использованное время.
С точки зрения бизнеса — это выгоднее.
Не уверен, но рискну предположить, что речь про "техподдержку". Это когда специально обученные инженеры вендора регулярно меняют расходники типа вентиляторов, блоков питания и жестких дисков, ну и в т.ч. накатывают обновления софта. Не потому, что винты погорели или "нашу древнюю ось взломали", а просто потому что положено по срокам. И эти плановые сроки замены вполне могут зависеть от нагрузки на компоненты.
Все придумано до вас.
Очень длительное время мейнфреймы не покупались, а брались в аренду у производителя.
Но и в случае "приобретения" вы "покупали" не только железо, но и некоторую поддержку, которая зависела от использования продукта (это как ТО автомобиля).
Поэтому нужно не гадать на кофейной гуще, а смотреть условия "продажи". С большой вероятностью она в такой терминологии существует только в ваших фантазиях.
P.S а насчёт ободрать… Посмотрите в сторону Амазон и их AWS. Аналогии ну очень уж прямые. Только у IBM это все на 30-50-80 лет раньше появилось.
Из статьи так и не понял, что же такое мэйнфрэйм.
Вопрос продажнику IBM:
Почему сегодня клиент, который выбирает новое решение с нуля, должен сделать выбор в пользу мейнфрейма IBM, а не использовать сервер или кластер другой более популярной архитектуры?
Отметьте преимущества по категориям: производительность, надежность, доступность ПО, доступность профильного персонала, масштабируемость, техподдержка вендора, цена.
Я не виже ни одного явного плюса. Максимум есть паритет в паре категорий с другими решениями, а в основном жирные минусы.
Я не продажник IBM, но представьте, что вы — банк, у вас миллиард клиентских счетов, 10 миллиардов платёжек в сутки и терабайт транзакций в час. Вам нужно на чём-то крутить базу данных типа оракла.
Я не уверен, что несколько стоек, набитых х86_64 барахлом, будет дешевле мейнфрейма сопоставимой мощности.
Миллиард счетов может и да, трудно представить, а вот миллиард измененных записей в сутки в одной таблице у меня в проекте имеется (и таблиц там сильно больше одной). И да, там не x86, а скажем Sun от Oracle.
И если уж у них получилось, то и банков тем более получится.
Так у меня и есть банк. Про миллиард счетов — не слышал, а миллиард транзакций (или 10 терабайт в сутки по одной таблице, скажем) — это запросто.
>банков тем более получится
Обычно вопрос стоит слегка иначе — а нафига? Даже если получится — то далеко не даром, как вы догадываетесь.
Ну т.е. как выше высказались: «Я не уверен, что несколько стоек, набитых х86_64 барахлом» — ну и я тоже не уверен. В реальности надо считать и думать.
Я вас и поправил. Потом вы сами поправились. О чем спор? :-).
Насчет «x86_64 барахла» тоже посмеялся. На этом «барахле» сегодня работает Амадеус, свалив с кошерных мэйнфреймов на «барахло». И судя по фоткам, в Вилларибо по этому поводу праздник :-). А в Виллабаждо все еще мучаются с мэйнфремами?
Тогда мы идем к вам :-).
Вот немного разношерстной статистики.
Авиабилеты
до 3 миллиардов 120 тысяч билетов по всему миру в 2014
Вот новость по банкам за 2018й год
Сбербанк вошел в число мировых лидеров по обслуживанию карт
За год он обработал 9 млрд карточных платежей – половину совершенных в России
Из банков впереди Сбербанка лишь два американских гиганта – JPMorgan Chase (21,8 млрд) и Bank of America.
И это все только лишь часть банковских операций.
На этом фоне 3млрд билетов не смотрятся вообще.
Ой, что то я с трудом представляю такой банк
Пффф, каждый вклад/кредит/карточка это отдельный счёт. Причём даже после закрытия счет ещё долго не удаляется, потому что через 10 лет могут прийти какие-нибудь наследники и затребовать выписку.
Ну и, потом, не все так грустно сегодня с миграцией. Тяжело было первопроходцам в этом деле. А сейчас уже наработаны практики и компетенции, так что многие компании (начиная с AWS) предлагают помощь в этом вопросе.
А так, есть статистика, что вообще большинство проектов в авйти выходят за рамки плана по бюджету и срокам.
Надо было к вам, и вы бы им объяснили, что мигрируют с мэйнфреймов только неудачники и колхозники. А профессионалы выбирают имб форева :-).
В РФ, я знаю, как минимум, одну компанию, которая будет вынуждена уйти с МФ на «калькулятор», как мы шутим — «в облака», главное, чтобы не буквально. Они осуществляют миграцию только по политическим причинам!!! Они имеет квалиф.спецов по МФ; компания понимает все сложность и неадекватность процесса перехода; она осознают техническую неэффективность миграции, которая будет компенсирована дополнительным количеством калькуляторов; они знают о потребном временном лаге и в какие деньги это выльется. Политическое решение принято, а техническое решение, пока, окончательно не готово, несмотря на весь тех.бэкграунд и финвозможности этой компании. Вот это подход! Люди уже четыре года подступаются к этому вопросу, потому что право на ошибку — нет, соответственно цена не фиксируется. Вот так люди должны мигрировать с МФ! Когда они понимают, что они теряют и что может быть смогут приобрести. И, без обид, слава Богу, что Вас нет в этой команде.
Ну и, конечно, процесс миграции с МФ идет повсеместно, а не только в РФ. Так это объективный процесс, а не «политика».
Как специалист, отдавший «зеленым экранам», как мы шутим, пол жизни, в том числе непосредственно в ibm, я этот процесс поддерживаю и считаю прогрессивным. Будущее за открытыми технологиями и стандартами, потому что они дают гибкость и возможность выбора, что хорошо для бизнеса и рынка.
Да, жалко немного людей, которые 30 лет делали одно и то же и настолько закостенели в своих привычках, что переход на что-то другое для них сложен а нередко и невозможен. Но, с другой стороны, я видел и нежелание учиться и смотреть что происходит вокруг у многих. Слишком удобно было думать, что вот это, полученное когда-то знание будет кормить всегда и можно не развиваться в профессии. Так что и не особо жалко. Пора, друзья, или начать учиться новому или идти на пенсию.
Вы лучше себя пожалейте, я думаю, что Вы имеете «зуб» на IBM (Вас несправедливо уволили, или вовремя не повысили ЗП и т.п.), из-за этого перенести свою обиду на технологию — несколько мелко. Да у МФ есть недостатки — их немного и мы о них знаем. Говорить о том что это закостенелая технология — глупость, настоящий реальный техспец так не скажет (хотя, может быть Вы 30 лет в MVT/SVS смотрели...). Реальные проекты сейчас лежат на стыке МФ — РС графика, и если нет требований по импортозамещению — то это очень жизнестойкая спарка.
Сколько нового о себе родном порой узнаешь от незнакомых людей на хабре.
Ну и да, какой я спец, по сравнению с вами :-).
Ладно, я вижу с кем имею дело. Переход на личности, неимоверный ЧСВ и ноль технических деталей. Удачи в пугании «молодежи» неимоверной крутизной изделий от ibm. Только вряд ли преуспеете. Больше шансов с непрофессионалами: чиновниками, менеджерами… А в открытой технической дискуссии вы просто бессильны и смешны. Когда вам приводят линки на конкретные кейсы успешных миграций самых сложных систем, ответить вам нечем, кроме каких-то мифических историй с минимумом деталей. Так что складывается полное понимание, что дело там было в некомпетентности конкретных исполнителей, а не в мифической незаменимости мэйнфреймов.
Даже жалко вас, немного.
Вообщем, на пенсию, пора вам на пенсию ;-).
Я не один год работал в z/TPF, в системе заказов авиабилетов. И до сих пор имею много знакомых в отрасли. В том числе и в курсе конкретно этого проекта в Амадеусе. Не верьте красивым картинкам — им надо демонстрировать успешность, иначе инвесторы не поймут. Но вот изнутри информация "немного" иная приходит. Результат более чем разочаровывающий.
Кроме них, знаком и лично сталкивался ещё примерно с пятью переходами с МФ на "пластик". И ни одного успешного. Если даже удалось мигрировать с точки зрения технологий, то финансово примерно через 5-6 лет операционные расходы оказываются значительно выше тех, к которым пришли бы, оставшись на МФ. А если добавить расходы на кадры — то и ещё выше. При этом именно технологически справились с задачей только в двух местах. В остальных — параллельно держат МФ, поскольку полностью слезть не смогли. Но релизы — столь же радужные, как и у Амдокса!
Добавлю — "конкретные исполнители" и технологии, на которые переходили, всюду были разные.
Если вся проектная документация, а то и вообще понимание что программа делает, утеряны (или даже никогда не существовали), то превышение затрат на миграцию по сравнению с затратами на разработку — норма, ведь с обратной разработкой всегда так. А если это выясняется внезапно уже после начала миграции — то и превышение бюджета понятно. И да, документацию восстанавливать нужно в любом случае, так что даже в случае неудачной миграции деньги не впустую пропали.
Если же ничего утеряно не было — то я просто не представляю чем вообще можно 10 лет заниматься.
На самом деле, везде где остались эти мастодонты от них перманентно хотят избавиться. Но миграция — дело непростое и не дешевое. А причины по которым хотят избавиться не только технические. Жесткий вендор лок, когда твой бизнес целиком зависит от одного поставщика и его жадности и недальновидности — это плохо и рискованно для бизнеса.
А, да, еще меня всегда веселит эта реклама «вы можете запускать на нем линукс!».
Встречный вопрос: а нафига мне для этого мэйнфрейм? В шкафу ценой от 500К вечнозеленых сразу плюс еще немало ежегодно за аренду (да-да, этот шкаф вам не принадлежит!), древний линух крутится медленнее, чем на сервере x86 за 5K. Плюс еще куча головняка с пакетами (архитектура весьма специфическая).
Или это: вы можете сделать партишины (LPAR их называют в IBM)! Офигеть! Так зачем мне делить мэйфрейм, единственное достоинство архитектуры которого в возможности поддержать большое количество памяти, дисков и юзеров в одной системе, на мелкие партишины? Так я лучше куплю пять отдельных серверов — это будет дешевле на порядок, проще на порядок и тот же выхлоп.
Я уж молчу про импортозамещение.
Вообщем, оставьте вы эту платформу в покое. Она, несомненно, была великой. Но вешать на нее какие-то модные штучки и пытаться продавать сегодня — это даже как-то унизительно. Как на великий ретро автомобиль пытаться приладить какой нибудь гугл ауто и заставлять конкурировать на широком рынке.
Пора этой платформе уже упокоиться где-то в музее. А для энтузиастов есть геркулес. Работает на нем все — вплоть до последних версий zOS. Причем, часто шустрее, чем на оригинальном железе.
http://www.hercules-390.eu/
Эмулятор
Да, z/OS там запускается, но многих полезных расширений там просто нет, не реализовано.
Нет поддержки аппаратного сжатия (z/EDC), шифрования (CryptoExpress), полноценной работы сетевого адаптера в режиме QDIO, я уже не говорю про невозможность сделать кластерный режим aka SYSPLEX.
Производительность геркулеса очень и очень невысокая, в сравнении с реальным современным «железом» (поколение z14 или z15).
Насчет производительности… Большинство сайтов старше 10 лет. Им это новое железо нафик не нужно и покупают его вынуждено, потому, что заставляет IBM (прекращая саппорт для старого железа в новых версиях системы), а не потому что реально нужно.
Очень хорошо что Геркулес есть, но он применим далеко не всегда. И в первую очередь из за весьма скромной производительности.
С поддержкой старого «железа» все не так уж и грустно.
Например самая «свежая» на сегодняшний день IBM z/OS версии 2.4, вышедшая в сентябре 2019 года, официально поддерживает поколение z12 (EC12/BC12), которое было выпущено в августе 2012 года.
Я знаю как минимум один сайт в России, который периодически покупает новое «железо», потому как всю доступную мощность «старых» уже скушали за счет роста нагрузки и за счет разворачивания там же новых приложений.
или просто перелезали с одного вендора (ИБМ) на другого (Оракл гггг)
По нему было несколько докладов, гуглите.
Или вот еще: www.youtube.com/watch?v=HbzhClY-Brs
Мы сейчас как раз в процессе — переписываем решение, которое начало создаваться 60(!) лет назад и до сих пор работает. Про прямое портирование речи нет, по сути пишем с нуля на современных платформах новое приложение, которое позволит полностью отказаться от мейнфрейма через 2 с небольшим года. Для заказчика сейчас это один из важнейших приоритетов, потому что каждый день работы мейнфрейма для него несет весьма существенные расходы — достаточно большие, чтобы вложить в переписывание ресурсы в виде 5-7 скрам команд на три с половиной года.
Плюс, конечно, желание избавиться от "чёрных ящиков", когда специалист регулярно запускает какой-то макрос для выгрузки определённых данных, но никто не знает, как он работает, и разбираться в этом тоже некому...
По большому счету — бек-офисная система, учет клиентов/поставщиков/продуктов/заказов и все в таком роде. Бизнес-область — разного рода публикации, научные статьи, подписки на периодические издания, доступ к базам данных и т.п. То есть про какие-то запредельные нагрузки речи нет, все вполне умеренно. Сейчас мигрируем в AWS, в соответствии с общей политикой развития компании.
Так и не нужно «рассказывать про мейнфреймы» вообще, огромный объем информации вас задавит.
Рассказывайте про отдельные аспекты, вроде «Как тут живут без файлов и каталогов» или «Как решается вот эта задача».
z/OS manages data by means of data sets. The term data set refers to a file that contains one or more records. The record is the basic unit of information used by a program running on z/OS.
и вы увидите, что датасет это и есть файл, просто под другим названием. Ну исторически, в отличие скажем от UNIX, где файлы состоят из байтов, файлы на мейнфреймах IBM состоят из записей, фиксированной или переменной длины. Соответственно, API несколько другой, ориентированный на записи, а не на массивы/потоки байтов. Но это уже мелочи.
Мне это попалось 2002 году на одной пищевой фабрике: мейнфрейм IBM AS/400, DB2, BPCS — Черный ящик жил в московском офисе, а питерский завод сидел в термнальчиках удаленно.
Но AS/400 это midrange :)
Архитектурно AS/400 (или i по современному) — это такой же мэнфрейм, улучшенный и пересмотренный. Разница чисто в мощности. Но старшие модели i будут помощнее младших моделей z.
Вообщем, я думаю, что это разница — чисто коммерческий ход ibm, а по сути i — это мэйнрейм такой же как и z. И с теми же проблемами. Плюс еще закрытый и строго секретный TIMI, так что рассчитывать на создание в ближайшее время эмулятора, наподобие геркулеса, не приходится :-(.
Я работал и на тех и на других, и как по мне, они так же похожи-не похожи как например WinXP и Win10. Для пользователя одной платформы другая не будет шоком.
Интереснее было бы услышать по сути, какие критерии определяют мэйнфрейм архитектуру и почем i — не мэйнфрейм.
И, главное, объектно-ориентированная архитектура OS запрещена для мэйнфрема? Это критерий?
Ну да. Power например. Но совершенно не такое, как у z. Насколько я знаю, там никогда не было например каналов ввода/вывода, которые являются одной из важнейших особенностей архитектуры S/360 и ее наследников.
Ну и ОС тоже — покажете например z/VM для AS/400?
Более того, для развлечения, в рочестере запускали i/os на PS3 :-).
Каналы, в смысле, специализированные процессоры ввода-вывода, конечно, были в AS/400 с самого начала. Как они реализуются в железе сегодня сказать точно не могу.
Нет, то что железо разное — это понятно. Но ведь определение мэйнфрем вроде как не не привязано к конкретному типу процессора.
Я в курсе, что попытка IBM перевести Z на power не увеньчалась успехом что породило ликование в некоторых кругах ;-).
Но, хочу напомнить, что и AS/400 изначально имела свой собственный CPU, а миграция на Power потребовала внесения дополнений в ISA, так что ранние модели имели свою специальную версию Power CPU. Потом эти расширения были включены в следующие версии ISA.
Вот смотрите. Вики дает следующие критерии мэйнфреймов:
- Redundant internal engineering resulting in high reliability and security
- Extensive input-output («I/O») facilities with the ability to offload to separate engines
- Strict backward compatibility with older software
- High hardware and computational utilization rates through virtualization to support massive throughput.
- Hot-swapping of hardware, such as processors and memory.
И каждый из них выполняется для i не хуже чем для z.
Скажу больше, вот что-что, а уж VM точно не является эксклюзивной фичей Z — сейчас кто угодно может в виртуализацию и таки да VM в VM тоже некоторые умеют, тот же Win.
Я думаю что и z и i — это мэйнфрейм архитектура.
Вам бы статью написать :) мне как перфоманс специалисту было бы интересно почитать что-то настоящее живое с реальными кейсами, без маркетинговой чепухи :)
VM в VM тоже некоторые умеют, тот же Win
Чисто ради интереса: интересно, а загружать уже частично инициализованные хранимые системы (типа как по команде IPL CMS) сейчас кто-нибудь умеет, не знаете?
PS Справедливости ради, в Hyper-V (официальное название технологии виртуализации от MS) «VM в VM» появилась позже других, где-то в 2016. А мне как админу эта возможность (поэкспериментировать с кластерами Hyper-V, например) сильно раньше была желанна, потому лично я, например, начал использовать для этого VMWare Workstation.
Кто-нибудь хочет стартап?
старые thinkpad по 100 $ за штуку вполне сгодятся в качестве терминалов.
или вы хотите на них еще и ютуб в браузере смотреть?
Опять же, повторюсь, я не про то, что это можно сделать, купив кучу мусора на Avito. Я про то, что хочется законченное решение. Чтоб включил — и оно работало.
Вот тебе терминал за 11к рублей: https://www.irbis.su/category/portable/notebooks/product/478
А своём "кластере" делаешь точку входа для SSH, настраиваешь https://lp.jetbrains.com/projector/ для программирования и дальше по своему усмотрению заруливаешь в SSH всё, что можно и немного того, что нельзя. Ни кто не будет покупать сейчас "готовый мейнфрейм нового поколения", а тем кому надо "что-то похожее" собирают это на БУ блейд серверах.
Это сложно — в комплекте с дешевым процессором обычно идут дешевый экран, скрипучий корпус, маленькая батарейка и так далее.
Может хромбуки будут норм, не знаю.
В теории можно, на практике — вряд ли :) Хороший корпус с экраном даже с минимального уровня начинкой окажется дороже, чем средний-дешевый ноут целиком, а денег от замены начинки в среднем ноуте на минимально приемлемую все равно не хватит на корпус и экран заметно лучше.
Так и получается, что старые топовые или пред-топовые ноуты лучше всего подходят под ваше описание, как ни странно. Начинка устаревшая и откровенно слабая для современных задач, но в терминале это и не нужно, а все остальное — корпус, экран, клавиатура — на требуемом уровне.
А зачем терминалу процессор, которого хватает на ютьюб? Разве декодированием видео на ютьюбе не должен заниматься сервер, отдавая на клиенты видеопоток, который они (после декодирования, конечно, канал-то не резиновый) отображают?
Дело в архитектуре OS.
Что касается терминалов (клиентов), то есть уже открытые эмуляторы и 5250 и 3270.
Я сильно сомневаюсь, что где-то на современных сайтах еще активно используют оригинальные терминалы подключаемые через коаксиал — все работают на телнет эмуляторах.
Лчно для вас посоветую — одну очень мощную машину, несколько физических видеокарт, несколько мониторов hdmi/dvi и usb подключения через хаб (до 5 метров проблем нет, дальше лотерея) для клавиатур и мышек.
Никаких проблем в linux (каждое рабочее место — своя видеокарта), все работает прекрасно быстро и невероятно выгодно.
Для десктопных windows это решается с помощью ibik aster (немного платно), когда то прекрасно работали даже игры (каждое рабочее место свой логин windows, установка в свои каталоги), возможно будут проблемы с разными античитами, а уж обычный офисные задачи — на ура.
Статья какая-то поверхностная, но немного полезной информации про особенности этих систем всё же есть. Жду продолжения с большим числом деталей.
В чём мотивация делать на них новые проекты, когда и специалисты и железо, и софт больших денег? Для легаси всё понятно, но не построена же работа компании вокруг чего-то написанного 30 лет назад и с тех пор не менявшегося? Или такое тоже бывает?
Статья действительно сильно поверхностная, но и рассказывать про фреймы можно до ужаса долго. Но и с утверждением о том, что мейнфрейм догоняет современные технологии вообще не соглашусь — все как раз наоборот. К примеру технологии виртуализации сначала появились на нем, а потом уже "перетекли" на другие платформы (та же z/VM). Еще в начале нулевых под z/VM делал подобие докера — (когда технологий контейнеров еще даже в планах не было). Еще тогда можно было под z/VM загрузить и стартовать ядро Linux в разделяемый сегмент памяти, "заморозить" его и грузить еще +100500 линуксов с этого сегмента разделяемой памяти.
А фреймы по сути нужны там где ну очень сильные требования к ввод-выводу — тут их архитектура рулит ( у фреймов канальная архитектура, в отличии от условно шинной в x86).
В текущем поколении (z/14) bandwidth одного чипа с с центральными процессорами составляет 2.4TB/s — память 1.6ТB/s. Уровней кэша в фреймах 4 штуки. L1-128КB, L2-4MB, L3-128MB, L4-672MB. А отказоустойчивость достигается как в космических аппаратах — дублированием всего и всея. Например в каждом ядре каждая инструкция параллельно выполняется на 2-х блоках и результаты сравниваются — если есть различие процессор помечается сбойным и инструкция уезжает работать на "запасной" процессор (на одной подложке их несколько — и один как минимум всегда в резерве ).
у МФ жутко дорогая память, потому реальные МФ, которые еще не выкинули вынуждены ютиться в мизерном объеме памяти, отсюда и повышенный требования на i/o. все равно МФ не в состоянии соревноваться с каким-нибудь хадуп кластером который способен все данные в оперативку забрать гарантируя на 2 порядка меньшее i/o по много меньшей цене.
фишка МФ в оптимальном распределением задач в стесненных ресурсах, но это не кому не нужно по такой цене. добавить терабайт памяти в тысячи и тысячи раз дешевле, чем радоваться тому как МФ хорошо работает забив ресурсы на все 100%
центральная часть МФ — db2/zOS, который не развивается, а лишь с опозданием адаптирует фишки из LUW редакции.
Как человек видевший DB2 LUW изнутри, я бы сказал что все несколько иначе :-) DB2 LUW — это наследие от DB2 z/OS — там большая часть кодовой базы от фрейма. тот же протокол DRDA для соединения с DB2 работает в кодировке EBCDIC (которая pure mainframe )
Про HADOOP спорить не буду — все это вкусовщина, но скажу что in memory DB — как то не очень верится что хорошо работают с базами данных с размерами в петабайты (а довелось видеть и такие)
Насчет «большой кодовой базы» в DB2 LUW от Z… А на каком языке эта кодовая база была?
Чистый С. было очень заметно как имена функций были ограничены 8-ю символами в верхнем регистре и соответствовали именам в LOAD модулях от фреймовых библиотек
Понятно, что мэйнфреймы для них — это главный рынок, оттуда и EBCDIC и все остальное в коде. Но есть разница все же между «портировать с» и «разрабатывать для».
А до того, DB2 была на MVS на ассемблере и PL/X. Поправьте, если ошибаюсь.
В начале это вообще был не DB2 — а SQL/DS — который работал на VSE и VM. потом уже появилась DB2 for MVS. А еще раньше был System R. Потом написали DB2 под полуось — в принципе ее можно считать за прародительницу DB2 LUW. В какой то момент было 4 кодовых базы DB2. А потом был проект StarBurst — это оптимизирующий компилятор SQL (по сути половина базы данных) — его впилили во все платформы и как мне помнится он был написан на С.
An earlier version of the code that would become DB2 LUW (Linux, Unix, Windows) was part of an Extended Edition component of OS/2 called Database Manager.
IBM extended the functionality of Database Manager a number of times, including the addition of distributed database functionality by means of Distributed Relational Database Architecture (DRDA) that allowed shared access to a database in a remote location on a LAN. (Note that DRDA is based on objects and protocols defined by Distributed Data Management Architecture (DDM).)
Eventually, IBM took the decision to completely rewrite the software. The new version of Database Manager was called DB2/2 and DB2/6000 respectively. Other versions of DB2, with different code bases, followed the same '/' naming convention and became DB2/400 (for the AS/400), DB2/VSE (for the DOS/VSE environment) and DB2/VM (for the VM operating system).
Если не ограничиваться Россией, то количество разных use-cases гораздо больше.
Да, DB2 for z/OS вполне популярна у тех, кто эксплуатирует IBM z, но не является единственной «фишкой» платформы.
К сожалению, одну из современных «фишек», аппаратно-ускоренное сквозное шифрование данных, в России эксплуатировать в прямом виде нельзя. «Отечественное» шифрование прикрутить можно, но для этого кто-то имеющий нужные сертификации внутри России должен разработать, изготовить и сертифицировать карту расширения, выполняющую шифрование/дешифрование по стандартам России.
Возвращаясь к DB2, DB2 for z/OS и DB2 for LUW — это две разных линейки продуктов с совместимым синтаксисом SQL. И копирование фич там точно перекрестное а не одностороннее.
DB2 for z/OS вполне активно развивается. Насколько мне известно, IBM добавляет те или иные фичи по пожеланиям крупных клиентов, т.е. продукт меняется и развивается по желаниям клиентов, которые платят за лицензии и за тех.поддержку. Что, по моему, вполне логично.
Насчет применимости других СУБД — спорить не буду, ибо нет нигде «золотой пули». Разные базы данных имеют разные требования от бизнеса и для их воплощения могут подходить разные СУБД, в том числе и IBM DB2 for z/OS.
Говоря про 100% нагрузку. Да, мейнфреймовое «железо» и «софт» отлично умеют долговременно выдерживать 100% нагрузку на процессор, ввод/вывод и прочие ресурсы. При этом встроенный в z/OS планировщик с настраиваемой пользователем политикой (которая может быть весьма сложной) позволяет системе не «затыкаться» и обслуживать нагрузку согласно приоритетам в этой политике. Но, это не говорит о том, что такой ситуации нужно «радоваться».
Китайцы заставили IBM выпускать процессоры с китайским шифрованием.
Думаю, это больше рекламная кампания. Сейчас все современные CPU поддерживают аппаратное шифрование. А то, что в z для этого нужен отдельный контроллер — это особенность конкретной архитектуры, а не то, что именно так это лучшим способом реализуется. Они вон по той же причине носятся со своими каналами, которые там вынужденно остались, тогда как все другие давно перешли на DMA.
На самом деле, чтобы говорить о «ниочем» надо предметно смотреть по результатам. Взять старшую модель i и посравнивать на тестах с младшей z.
То же «железное сквозное шифрование» реализуется в серверах Power с помощью On-chip accelerators. А через OpenCAPI можно подключать вообще что угодно.
К примеру технологии виртуализации сначала появились на нем, а потом уже «перетекли» на другие платформы (та же z/VM).
Да, примерно так. Только вот z/VM была не первой в роду. Ее родоначальником была система, которая сейчас известна CP/CMS и работала она на IBM System/360 Model 67 еще в далекой древности — полсотни лет назад. Ну, а лично я приобщился к виртуализации (и немало там похакерствовал) сильно позднее, в середине 80-х, под IBM VM/370, работавшей на советском клоне IBM System/370 (нашлись какие-то умельцы в Союзе, которые ее адаптировали). Так что бум виртуализации в середине 00-х был для меня приветом из далекой молодости.
Еще тогда можно было под z/VM загрузить и стартовать ядро Linux в разделяемый сегмент памяти, «заморозить» его и грузить еще +100500 линуксов с этого сегмента разделяемой памяти.Ага, называлась такая штука «хранимая система», и я лично не знаю, реализовывал ли кто-нибудь ещё эту концепцию, полагаю, что вряд ли: она требует контроля и над кодом гипервизора и над кодом ОС, таким контролем обладает ещё только MS, а MS AFAIK этого так и не сделала.
Попробуйте объяснить, что такое «майнить биткоин» людям за 70, вот примерно так же я чувствую себя, когда пытаюсь объяснить что такое Мейнфрейм чуть больше чем всем.
Попробуйте объяснить людям 80+, что такое интернет и как им заказать еду на дом с предоплатой по карте, опустив объяснения про мышь, клавиатуру, браузер, сайт и т.д.
Похоже автор страдает эйджизмом.
О, я писала JCLки всего лет 5 назад. Ностальгия прямо, субмитишь их, потом в спуле лог смотришь… Для автоматизации запилила библиотечку на питоне: robotframework-mainframelibrary, регрессию гонять. Можно сказать, был небольшой местный взлет эффективности работы тестировщиков. А потом все стали на aws мигрировать(((
Интересно было бы узнать из первых рук, куда уходят с мейнфреймов (предположу, что тут всё достаточно банально: всякие СУБД вроде Oracle и ERP системы вроде SAP? хотя, может и на что-то более новое, вроде облаков?) и, особенно, кто и зачем может сейчас переходить на мейнфреймы?
С новыми клиентами тоже есть пара предположений:
- Пользователи различных клонов S/360 и далее, возможно, использовавшие до недавнего времени Hercules
- Пользователи младших линеек IBM (та же System i), «доросшие» до мейнфреймов
- Ещё одна потенциальная категория новых пользователей — миграции с аналогичных решений конкурентов, вроде OpenVMS, у которой ещё недавно всё было совсем плохо, вплоть до перспективы полного прекращения поддержки, после чего права на неё передали VSI и даже началось портирование на x86.
Ещё вопрос, какие технологии с точки зрения IBM и пользователей подобных систем считаются основными конкурентами мейнфреймов?
И, может, кто-нибудь в курсе, как там сейчас поживает вышеупомянутая OpenVMS?
Как мейнфреймы не вымерли