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

[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, пре-прод и прод, нет нужды разносить по разным регионам копии. это лишние траты на виртуальные машины и ненужные балансеры - все яйца следует сложить в одну корзину, мы же сто раз так делали на МФ и они вымерли. коллеги, давайте же повторим этот успех легендарной платформе !

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