Docker for zOS. Что это и зачем?

[zVlad]

ИБМ так любит акронимы. Это ужас какой-то.
Эти биг эндианцы как будто назло термины придумывают.

Это Вы о чем? ИБМ дал миру ИТ все базовые нове термины и принципы работы. Это кокуренты ИБМ начали придумывать новые термины чтобы отвадить молодеж от ИБМ.
В данном случае ИБМ дал название своему продукту созданому на основе стандарта. Могли бы легко обойтись и без стандарта. Как Вы надеюсь поняли на мф давено уже используется HiperSockets.
SMC-R был создан главным образом, если не сказать только, для zCX (Dockers on zOS). Проблема RDMA была решена на zOS десятилетия назад с помощью Coupling Facility (CF) и Parallel Sysplex.
CF - это код и память в одной, или нескольких, партициях на мф в которую разные zOS и не только на том же мф и даже не только в одном дата центре могут записывать данные и читать их. Например там могут раместиться DB2 Buffer Pools called Global Buffer Pools, т.е данные которые будут доступны разным DB2 в разных zOS, на разных мф, в разных дата центрах.

вот, море акронимов.
кстати, а почему hipersockets а не hypersockets?

Не знаю. Меня это тоже всегда конфузит. Словарь говорит есть и то и другое с одинаковыми значениями.

Есть еще HiperDispatch - режим диспетчирования задач когда учитывается на каком CPU выполнялась задача когда была прервана. Дисперчер посторается вохобновуть задачу с того же CPU чтобы не пропали данные в кэшах CPU, или хотя бы на CPU с того же PU (cash PU). HiperDispatch может "заморозить" использование доступных для партиции CPU если согласно веса партиции достаточно меньшее количество CPU. Например у нас 4 CPU и все 4 доступны двум партициям с весами 80 и 20. Если парция с весом 80 использует все 100% то вторая партиция будет использовать один CPU - 3 CPU будут "заморожены". Примерно так.

[zVlad]

А что такого специального в эмуляции z/OS?
Геркулесу много лет, главная проблема дистрибутив z/OS достать, а дальше развлекайся сколько душенька пожелает.
https://en.wikipedia.org/wiki/Hercules_%28emulator%29

Дистрибутив zOS то достать можно (у меня, например, купить. Продам недорого), вот только не будет он работать на эмуляторе Геркулес и ни на какoм другом подобном.
В коде zOS есть проверка на чем его запускают и эту упроверку сэмулировать не "возможно". А если и возможно то это будет нарушение авторского права. Не на zOS, хотя и на него то же, а на микрокод, который используется для проверки.
IBM убрал код проверки из своих старых версий MVS. Их можно скачать кому угодно и ставить на какие угодно эмуляторы. Возможно и старые версии zOS открыты. Но те которые еще используются на продаваемых и поддерживаемых версиях МФ конeчно не открыты. Это денеги. И у Hercules Inc. нет таких денег чтобы оплатить иск. Он будет огромен. Клиенты IBM тоже не захотят ссориться с IBM. IBM support для МФ outstanding во всех смыслах. Крупные клиенты знают что никакой Hercules ни на каком железе не потянет то что потянет MF. Или железо то будет стоить дороже МФ. Мелкие клиенты либо уже давно разбежались либо сидят со своими мелкими потребностями на эмуляторах и старых версиях.
Есть одна прлесть от эмулятора MF интерсная в том числе IBM. С помощью эмулятора и старых версий интересующийся может хорошо ознакоминться с OS MF и может даже пойти работать на МФ. Поэтому IBM все что возможно для этого делает, я думаю.
Когда пользователь официально покупает zOS, то он его покупает для IBM mainframe, купленный у них же. Каждый IBM МФ имеет связь с IBM Control Center, вообщем то для того чтобы сообщать в IBM o проблемах hardware. Эта связь не обязательнa для работы, можно ее и не включать - все будет работать. Каждый месяц я создаю репорт IBM-вским тулзом и aплоадаю его на IBM сайт. Для чего? IBM анализирует report на предмет насколько пользователь загружал мф. И по их критериям цена за софт на мф может быть уменьшена. Дискоунт такой. Наш клиент, на сколько мне известно, имeет такой (разныЙ) дискаунт каждый месяц. IBM может также посоветовать сделать постоянный downgrade capacity model если увидит что мы сильно недогружаем наш мф.

[Palych]

В PL/SQL нет threadов. Это радикально упрощает управлению памятью. Поэтому и не нужны 100500 вариантов GC.

ну как нет, session под виндой это тред, такой же как у жава долго играющий и не пойми сколько потребующий памяти.

Дело не в том сколько памяти и как долго будет использоваться, а в том как узнать что память больше не нужна.
В случае сессии это очень просто: закончилась сессия - всё что в ней подлежит уничтожению. Вот если бы можно было создавать новые threadы - тогда картина была бы другая.

То есть - сначала все данные перекачиваем в кеш БД. Потом - те же самые данные перекидываем в кеш AS. И все равно данные надо передавать по сети.
А если все разместить на одной машине и обращаться к базе через общую память - разве не сэкономим кучу ресурсов?

экономии не случится. во первых хибернейт кеш на AS снизит кол-во запросов к базе, во вторых у базы будет заметно крупней буферный кеш, sort area и т.п. что радикально изменит sql планы и снизит ио на диски. и еще раз, слазить в память соседней машины операция более дешевая, чем слазить себе на HDD.
льно запросить.

Заметьте что Вы меряете экономию по сравнению с неиспользованием кеша, а не со сверх быстрым доступом к базе. К тому же не рассматриваете экономию памяти как экономию, ибо память берётся из тумбочки, никогда не кончается и ничего не стоит.
Но в целом я согласен: экономии не получится. Потому что этого никто не будет делать. Компьютерные решения вошли в эпоху устоявшихся решений и Canon Driven Design. Поэтому решения с мейнфреймов никогда не будут портированы на писишные сервера. Как в притче о богаче и Лазаре: "и сверх всего того между нами и вами утверждена великая пропасть, так что хотящие перейти отсюда к вам не могут, также и оттуда к нам не переходят."

[voyager3]

кстати, а почему hipersockets а не hypersockets?

Рискну предположить, что игра на созвучии HIghPERformance sockets.

[zVlad]

кстати, а почему hipersockets а не hypersockets?

Рискну предположить, что игра на созвучии HIghPERformance sockets.

Мне понравилось. Наконец то запомню какую букву писать, а то всякий раз после перерыва приходилось смотреть документацию.

Кстати из документа:

HiperSockets™ is a System z® hardware feature that provides high performance internal communications ....

[iDesperado]

Дело не в том сколько памяти и как долго будет использоваться, а в том как узнать что память больше не нужна.
В случае сессии это очень просто: закончилась сессия - всё что в ней подлежит уничтожению. Вот если бы можно было создавать новые threadы - тогда картина была бы другая.

вы видимо не сталкивались с базами данных. сложность именно определить сколько выделить сессии, т.к. что в древних система с oracle forms, что в современных за connection pools сессии живут днями и годами и при этом решают задачи в течении своей жизни очень разные задачи. в случае с connection pools годами и еще и для разных пользователей.

Заметьте что Вы меряете экономию по сравнению с неиспользованием кеша, а не со сверх быстрым доступом к базе. К тому же не рассматриваете экономию памяти как экономию, ибо память берётся из тумбочки, никогда не кончается и ничего не стоит.

я сравниваю 1 и 2 сервера, где ничего не стоящая память забита под завязку. в железках с ораклом память всегда ставится по максимуму, т.к. на фоне лицензий оракла планки памяти не вытягивают и на 2% стоимости всей системы.

Но в целом я согласен: экономии не получится. Потому что этого никто не будет делать. Компьютерные решения вошли в эпоху устоявшихся решений и Canon Driven Design. Поэтому решения с мейнфреймов никогда не будут портированы на писишные сервера. Как в притче о богаче и Лазаре: "и сверх всего того между нами и вами утверждена великая пропасть, так что хотящие перейти отсюда к вам не могут, также и оттуда к нам не переходят."

это старость. как видим, даже на примере влада - нагрузку db2 с не самого маленького МФ, эксплуатация которого прожирает сотни тысяч в год перенесут на 16 vcpu, менее трети от современного x86 процессора. именно vcpu, т.к. азур все мерят в vcpu, а не cores. очевидно, что оставшаяся нагрузка легко покроется остающиемися 2/3 процессора. азуру такой сервачек и $30к вероятно не стоит, т.к. облака машинки собирают совсем из ширпотреба, даже не уровня леново.

[Bobeg]

а azure это паблик клауд с виртуальным прайват клаудом на паблике?

[iDesperado]

а azure это паблик клауд с виртуальным прайват клаудом на паблике?

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

[Bobeg]

это хорошая годная опция, одобряю.

[zVlad]

а azure это паблик клауд с виртуальным прайват клаудом на паблике?

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

Вот примерно это в нашем случае перехода с весьма слабенького мф и происходит. Много миллионный бюджет на переход уже давно трещит по швам. Никаких виртуальных cpu для Oracle который заменит DB2 нет и не будет. Дай бог им с реальными поднять нагрузку нашего клиента с его приложением. A ASs будет больше десятка и oни тоже не пальцем деланые. Сейчас ASs сидят на том же МФ в той же системе что и DB2.

[iDesperado]

Вот примерно это в нашем случае перехода с весьма слабенького мф и происходит. Много миллионный бюджет на переход уже давно трещит по швам. Никаких виртуальных cpu для Oracle который заменит DB2 нет и не будет. Дай бог им с реальными поднять нагрузку нашего клиента с его приложением. A ASs будет больше десятка и oни тоже не пальцем деланые. Сейчас ASs сидят на том же МФ в той же системе что и DB2.

по факту сейчас сидит [censored] не понимающая то что дети в 7-8 лет уже устойчиво отличают. влад, в 7-8 лет. vcpu это hardware thread, а не нечто что ты с виртуальными машинами связываешь.

[Palych]

вы видимо не сталкивались с базами данных. сложность именно определить сколько выделить сессии, т.к. что в древних система с oracle forms, что в современных за connection pools сессии живут днями и годами и при этом решают задачи в течении своей жизни очень разные задачи. в случае с connection pools годами и еще и для разных пользователей.

Про это действительно не знал. Помню только что в OCI (который на C) сессии не связаны с соединениями.
Получается что на стороне Oracle проблема та же что на стороне Java: непонятно сколько памяти нужно, поэтому выделяем сколько есть.

Заметьте что Вы меряете экономию по сравнению с неиспользованием кеша, а не со сверх быстрым доступом к базе. К тому же не рассматриваете экономию памяти как экономию, ибо память берётся из тумбочки, никогда не кончается и ничего не стоит.

я сравниваю 1 и 2 сервера, где ничего не стоящая память забита под завязку. в железках с ораклом память всегда ставится по максимуму, т.к. на фоне лицензий оракла планки памяти не вытягивают и на 2% стоимости всей системы.

Я согласен, я не говорил что память не является (пока) дорогим ресурсом. Просто констатировал факт.

Но в целом я согласен: экономии не получится. Потому что этого никто не будет делать. Компьютерные решения вошли в эпоху устоявшихся решений и Canon Driven Design. Поэтому решения с мейнфреймов никогда не будут портированы на писишные сервера. Как в притче о богаче и Лазаре: "и сверх всего того между нами и вами утверждена великая пропасть, так что хотящие перейти отсюда к вам не могут, также и оттуда к нам не переходят."

это старость. как видим, даже на примере влада - нагрузку db2 с не самого маленького МФ, эксплуатация которого прожирает сотни тысяч в год перенесут на 16 vcpu, менее трети от современного x86 процессора. именно vcpu, т.к. азур все мерят в vcpu, а не cores. очевидно, что оставшаяся нагрузка легко покроется остающиемися 2/3 процессора. азуру такой сервачек и $30к вероятно не стоит, т.к. облака машинки собирают совсем из ширпотреба, даже не уровня леново.

Я не говорю что подход сложившейся на МФ лучше или хуже чем в современных облачных кластерах.
Они сильно разные, и эта разница почти всегда игнорируется при планировании миграции путём лихой кавалерийской атаки. Поэтому миграции постоянно срываются.
Пример с объединением AS & DB был призван показать как в принципе можно применить подходы MF на другой стороне.
И с тем что я старею, точнее дряхлею и деградирую не по годам, тоже не поспоришь.

[zVlad]

....
Я не говорю что подход сложившейся на МФ лучше или хуже чем в современных облачных кластерах.
Они сильно разные, и эта разница почти всегда игнорируется при планировании миграции путём лихой кавалерийской атаки. Поэтому миграции постоянно срываются.
Пример с объединением AS & DB был призван показать как в принципе можно применить подходы MF на другой стороне.
И с тем что я старею, точнее дряхлею и деградирую не по годам, тоже не поспоришь.

Подходы на МФ и в "современных облачных кластерах" отличаются главным образом тем что последниe легко имплементируются (слезы и сопли о финансах оставим пока в стороне) на первых, а вот первые на второх никак.
Я не про переписывание и перетряхивание приложений полностью как это просиходит в нашем случае, а про то чтобы "взять" "как есть" и перенести с "современных облачных кластерах" (у нас кстати кластер пока не планируются - набор серверов с load balance между ASs с одной БД). Вот сейчас уйдут oни на Azure, а если захотаыт то смогут все один к одному (server by server) скопировать на МФ - LinuxONE и выполнять пользуясь всеми, или почти всеми, прелястями МФ. Например HiperSockets между партициями или между VM под zVM. Возможно они обойдутся тогда 1 (одним) АS на одном LPAR (ну пусть двумя, да хоть тремя), и одним Oracle на другом LPAR. Все. Больше ничего не надо для того ядра приложения что сейчас на МФ и что перетаскивают на кучу серверв в Azure.

[Bobeg]

помоему ажур только усложняет все дело.
проще было бы обойтись без ажура простым и понятным блейд фармом.
попытки излишне секономить как правило выливаются в дичайшие траты.

[Boriskin]

помоему ажур только усложняет все дело.
проще было бы обойтись без ажура простым и понятным блейд фармом.
попытки излишне секономить как правило выливаются в дичайшие траты.

Чем дальше - тем меньше людей и компаний хотят связываться с владением собственным железом и всем связанным гимором по его поддержке, ремонту и списанию. Арендуем инфраструктуру и не болит голова у дятла.

[iDesperado]

Про это действительно не знал. Помню только что в OCI (который на C) сессии не связаны с соединениями.

я работал с oci на пхп в 90х, oci_connect() на каждый вызов создавал сессию и завершал при завершении скрипта, oci_pconnect() создавал пул и оракловые сессии держал годами. вы с чем-то путаете.

Пример с объединением AS & DB был призван показать как в принципе можно применить подходы MF на другой стороне.

подход МФ это филигранная управление ресурсами - которая не может ничего противопоставить дешевизне и навороченности софта на x86. как бы там филигранно МФ не управлял ресурсами - 256 гб у одного лишь оракла порвут db2 на МФ, где на все апликухи 32 гб.

помоему ажур только усложняет все дело.
проще было бы обойтись без ажура простым и понятным блейд фармом.
попытки излишне секономить как правило выливаются в дичайшие траты.

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

Вот сейчас уйдут oни на Azure, а если захотаыт то смогут все один к одному (server by server) скопировать на МФ - LinuxONE и выполнять пользуясь всеми, или почти всеми, прелястями МФ.

только оракл это 256 гб, а сколько памяти планируется на те 17 апликейшен серверов ? ведь явно порядка 2 ТБ. никто в здравом уме не будет возвращаться на МФ, только активация терабайтов памяти зашкалит стоимость владение до шестизначных цифр.

[zVlad]

помоему ажур только усложняет все дело.
проще было бы обойтись без ажура простым и понятным блейд фармом.
попытки излишне секономить как правило выливаются в дичайшие траты.

Azure это и есть - блейд фарм. Только для самых "продвинутых" и "взрослых" там vcpu.

[Bobeg]

а чего ж оно не работает тогда?

[zVlad]

По моим ощущениям от этого треда - мир ИБМ это какой-то вообще отдельный мир. Интересный, эксайтинг но совсем чуждый.

Чуждый только потому что, в данном случае Вы, мало что о нем знаете. Вот для меня, коренного мэйнфрэймщика, Ваш мир ИТ очень даже свой и понятный. И не тодько потому что я лет пять (в 90-е) занимался программиованием и администрированием на ПК, но и потому что многие элементы Вашего мира имеются у меня на МФ. Unix, tcp/ip, websphere, java, ssh, sftp, SMB, NFS, IpSec
.... Вот сейчас и Docker появился, правда работать с ним мне видно не судьба. Виртуалные машины, кстати, на мф появились в начале 70-х, Linux появился на мф в начале 00-х и я с ним работал плотно пару лет. Работал я с Линукс на х86, как админ WebSphere потому что имел уже опыт с WS на мф.
Все очень даже не чуждо. Жаль у многих не мф-щиков сформирован комплекс против мф, и совсем нет знаний о мф, а вот ибм сделал все чтобы молодежи было удобно работать с мф в смысле их представлений о работе через gui, а не так как привыкли мы - ветераны - через 3270 терминал.

[Bobeg]

В юниксах большая часть работы делается через ssh вообще-то, рассердился я и даже пнул стол.

[zVlad]

...
только оракл это 256 гб, а сколько памяти планируется на те 17 апликейшен серверов ? ведь явно порядка 2 ТБ. никто в здравом уме не будет возвращаться на МФ, только активация терабайтов памяти зашкалит стоимость владение до шестизначных цифр.

Я не знаю сколько на тех 11 ASs памяти, много конечно. На МФ 2 TБ просто не понадобится. И здесь сработает как раз принцип co-location и auto balancing. У тех 11 серверов есть еще пара-тройка load balancers, верно? У всех них есть ОС развернутая полностью, в полный рост, всеми перьями нахохлившиеся, у каждого свой набор библиотек и всего прочего барахла что нужно только для того чтобы запuскать приложение. На МФ с этим всем справится 1(один) instance WebSphere в той же zOS где и DB2 будет. DB2 то у нас, как и будет в Azure Oracle, одна.
Нам еще до cut-over полгода, но уже давно на митингах одна из главных тем - патчи на ASs. jlog4 недавно был. Патчили несколько дней наверное. От вендора приходят патчи. На МФ года 3 три тишь и гладь и божья благодать. Все жужит, проблем нет у клиента нет никаких. Там в том кино будет: "- У нас несчастные случаи были? - Да пока нет. - Будут."
A Вы все про деньги бубните который год. До Вас так и ине доходит что цена ИТ решений это не цена железа и даже уже не цена базового софта, а совсем другие цены. Более того цена на Орацле, всем известно, мягкоо говоря высокая, в нашем же случае тот Oracle на который мы переходит уже сравнялсы по цене с цено мф.
А Вы все сводите к разговорам про vcpu. Булшит.

[zVlad]

В юниксах большая часть работы делается через ssh вообще-то, рассердился я и даже пнул стол.

А для zOS IBM написали GUI почти не всею деятельность сыстемного администратора. Я ими не пользуюсь. Я пользуюсь 3270 для MVS и частично уних v zOS, и "ssh". 3270 и сш это две большие разницы. 3270 почти GUI но не без кича. Есть вариант называется 3270UI - еще ближе к привычным по Windows GUI-ям.
Работа с МФ как железом давно уже, с начала 00-х, это чисто GUI локально (HMC называетыса - PC стоит рядом с МФ. Сейчас дисплей и клава - это U2 (кажется так называется) вставка в стандартную стойку дая центер) и через IE, Chrom, etc... удаленно.

[iDesperado]

У всех них есть ОС развернутая полностью, в полный рост, всеми перьями нахохлившиеся, у каждого свой набор библиотек и всего прочего барахла что нужно только для того чтобы запuскать приложение. На МФ с этим всем справится 1(один) instance WebSphere в той же zOS где и DB2 будет. DB2 то у нас, как и будет в Azure Oracle, одна.

да влад. ты прав. надо прямо в понедельник выходить с этим предложением к коллегам. коллеги конечно с опытом, но явно не подозревают, что WebSphere умеет запускать несколько аппликух. надо прямо так и говорить, коллеги, это глупо разносить систему на дев, uat, пре-прод и прод, нет нужды разносить по разным регионам копии. это лишние траты на виртуальные машины и ненужные балансеры - все яйца следует сложить в одну корзину, мы же сто раз так делали на МФ и они вымерли. коллеги, давайте же повторим этот успех легендарной платформе !

[zVlad]

У всех них есть ОС развернутая полностью, в полный рост, всеми перьями нахохлившиеся, у каждого свой набор библиотек и всего прочего барахла что нужно только для того чтобы запuскать приложение. На МФ с этим всем справится 1(один) instance WebSphere в той же zOS где и DB2 будет. DB2 то у нас, как и будет в Azure Oracle, одна.

да влад. ты прав. надо прямо в понедельник выходить с этим предложением к коллегам. коллеги конечно с опытом, но явно не подозревают, что WebSphere умеет запускать несколько аппликух. надо прямо так и говорить, коллеги, это глупо разносить систему на дев, uat, пре-прод и прод, нет нужды разносить по разным регионам копии. это лишние траты на виртуальные машины и ненужные балансеры - все яйца следует сложить в одну корзину, мы же сто раз так делали на МФ и они вымерли. коллеги, давайте же повторим этот успех легендарной платформе !

Мне тебя жалко, друг. Убогость зашкаливает. Ворчливость лишь бы поворчать перетекает все края.
Ну да ладно, живи как знаешь. Об одном прошу - не комментируй моих постов. Мне есть с кем общаться. Общаться с тобой нет ниакого ни интереса ни желания.
Всего хорошего.