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

[voyager3]

Уже давно задержки при передаче по сети на разумные расстояния пренебрежимо малы по сравнению с тормозами диска. Недаром RDMA всерьёз стали использовать. Есть, конечно мудрецы, у которых БД в Цюрихе, а приложение в Лондоне, и связаны они через бомж-провайдера, но, как говорится, при большом желании можно и бескостные части тела сломать.

[Bobeg]

а по поводу процессоров в меинфрейме з15, я почитал. горячий процессор. 500 ватт. но 5.2 гигагерца. 12 коров. каждая кора может ранать два треда ексекьюшена.
очень много кеша на каждой коре. гораздо больше чем на наших привычных амд интелах.
ну и типа в одной коробочке з15 хранит четыре таких штуковины. а коробочек может быть много. скажем 16 процессинг юнитов у простого сингл фрейм компутера.
192 коров на одном фрейме.

лютый киск. странные инструкции которых нет в обычных процессорах типа как децимал инструкции, компрессионные инструкции.

Вы ничего не сказали о каналах ввода-вывода, OSAs, криптокарты, SSD, и другие допустройства, которые тоже там есть и у всех у них есть свои процессоры и память.

я об этом низнаю ничего. я хотел просто понять чем в принципе процессоры мейнфрейма отличаются от обычных зионов и амд.
теперь узнал. весьма интересно.

[Bobeg]

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

[zVlad]

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

Поверьте мне классность МФ вовсе не в этом. Редко когда у IBM заказывают МФ с такими сумашхедшхими количествами кор. В большенстве случаев хватает меньше.
Классность МФ в zOS и в том что на нем можно выполнять большие фермы Linux, no Linux всех прелестей МФ использовать не может потому что МФ заточен под zOS, a zOS заточен под МФ. Это связка, тесная связка. Они вместе и одновременно растут. Linux лишь теоритически может использовать все возможности МФ, но для этого ему придется стать zOS, в том смысле чтобы обеспечить функциональность zOS и качества. А зачем? Уже есть один. Частично создана возмозность использовать больше МФ - через zCX (Dockers).

[Bobeg]

то есть Вы, зВлад, против применения линукса на мейнфрейме, потому что вы больше любите зОС, я правильно понимаю?

[zVlad]

то есть Вы, зВлад, против применения линукса на мейнфрейме, потому что вы больше любите зОС, я правильно понимаю?

Не совсем. Дело вовсе не в любви к zOS(MVS). В 80-е, начале 90-х и до конца я был фанатом VM (zVM). MVS я понимал через призму опыта работы с OS/360, SVS, TKS BOS, т.е систем до MVS. Ничего хорошего из того опыта сказать было невозможно. Системы те были ненадежными, капризными, тяжелыми. TKS был лучшим в этом смысле. Германская штучка. VM по сравнению с ними - бабочка, и пуля одновременно. Под VM же я гонял аналог старых ОС с элементами MVS на виртуальных машинах и считал что это лучшее для приложений требующих эту систему. Такк оно было на самом деле, но это были не те масштабы где MVS нужен и оправдан.
В MVS многое из тех систем было сохранено (JES2, TSO, VTAM, VSAM,...), но и добавлено (DFSMS, TCP/IP, ...). DB2 for MVS! Но это уже совсем другая, как оказалась, систем. Узнал я об этом только после 2006 года когда стал работать системным программиста zOS и прошел кучу IBM курсов по ней. Ну и конечно непосредственная работа, решение проблем, наблюдение внесли свою лепту в, если хотите, любовь к zOS.
Почитайте статью на Вики про MVS. Обратити особое внимание на сердства восстановления и контроля выполнения. Это базовые принципы которых нет нигде. С памятью MVS работает не так как принято в системах на Intel. Work Load Manager (WLM) наконец. Фактически MVS это виртуальные машины для MVS. Есть сходство с Docker = (примерно, похоже) JES2, плюс сам MVS. И Unix = zOS.

[Bobeg]

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

[alex_127]

Уже давно задержки при передаче по сети на разумные расстояния пренебрежимо малы по сравнению с тормозами диска. Недаром RDMA всерьёз стали использовать. Есть, конечно мудрецы, у которых БД в Цюрихе, а приложение в Лондоне, и связаны они через бомж-провайдера, но, как говорится, при большом желании можно и бескостные части тела сломать.

у вас в посте противоречие между строчками. а еще со скоростью света, которую так просто не отменить.

[voyager3]

у вас в посте противоречие между строчками. а еще со скоростью света, которую так просто не отменить.

Вы, наверное, не вчитались. У самих же диски отдельно, вычислительная часть отдельно.

[Мальчик-Одуванчик]

Но, даже без теоритических обоснований только для БД с мф подготовили 16 cpu, 256 GB и не факт что хватит.

так и не отличает cpu от cores

Я правильно понял что в имеющемся у zVlad мэйнфрейме стоит 4 шестиядерных проца и только 32 гига памяти?

У меня на дешевейшей китайской материнке, специально сделанной для выводящихся из эксплуатации оптеронов, стоит 32 гига памяти. Но даже на 16 ядер как-то маловато.
Я там как раз докеры пускаю, изображающие несколько компов.

Нет, Вы поняли не правильно. Читать здесь (в начале 3-ей страницы если лень читать все):

https://www.ibm.com/downloads/cas/A8NB3NRZ

Поменьше слушайту гопоту форумскую.

"The H06 and H13 are designed with up to 6 and 13 configurable cores."

Вы написали что у Вас в конфигурации 4 процессора (H06 или H13?)

Или Вы имели ввиду один процессор с 4 ядрами?

[alex_127]

у вас в посте противоречие между строчками. а еще со скоростью света, которую так просто не отменить.

Вы, наверное, не вчитались. У самих же диски отдельно, вычислительная часть отдельно.

- RDMA используют когда производительность сети + задержки хоста на процессинг заметны - то есть как альтернативу "простой" системе где зовут send/recv.
- задержка сети cross-region за исключением очень близких регионов больше hard-drive latency
- задержка сети in-region cross-az больше SSD latency

"У самих же диски отдельно, вычислительная часть отдельно " - Можно говорить о системах и что они позволяют а можно об их компонентах.

[zVlad]

Но, даже без теоритических обоснований только для БД с мф подготовили 16 cpu, 256 GB и не факт что хватит.

так и не отличает cpu от cores

Я правильно понял что в имеющемся у zVlad мэйнфрейме стоит 4 шестиядерных проца и только 32 гига памяти?

У меня на дешевейшей китайской материнке, специально сделанной для выводящихся из эксплуатации оптеронов, стоит 32 гига памяти. Но даже на 16 ядер как-то маловато.
Я там как раз докеры пускаю, изображающие несколько компов.

Нет, Вы поняли не правильно. Читать здесь (в начале 3-ей страницы если лень читать все):

https://www.ibm.com/downloads/cas/A8NB3NRZ

Поменьше слушайту гопоту форумскую.

"The H06 and H13 are designed with up to 6 and 13 configurable cores."

Вы написали что у Вас в конфигурации 4 процессора (H06 или H13?)

Или Вы имели ввиду один процессор с 4 ядрами?

H06. IBM на маинфраме использует "CPU" так как это всегда использовалось. И тогда когда CPU был как правило один и сейчас когда на чипе удается размещать много CPU. Термин "core" использоется в рекламных листовках для широкой публики. Мы. маьйфрэймщики не конфузимся тем фактом что на чипе. В рамках МФ термин "core" нигде не используется. Используется только CPU и это никогда не чип с многоми "cores".

Кроме H06(H13) - называется configuration model, в семйстве zBC12 их две - есть еще перформанце модел, который состоит из буквы и числа - количество активных GP CPU (GP - General Purpose). Наша performance model - O04, максимальная model для H06 - Z06. Кроме GP CPU можно иметь ряд других CPU и их может быть как правило тоже от 0 до 6. Говорить "один процессор с 4 ядрами" не имеет смысла потому что на чипе zBC12 шесть ... пусть будет "cores" или ядра. Сколько таких чипов в нашем МФ я так сходу и не скажу, походу два. T.e. 12... "cores"/ядер. Чипов может быть от одного до шести. T.e. 6x6=36. Поэтому фраза ""The H06 and H13 are designed with up to 6 and 13 configurable cores."" фактически означаеть 6 или 13 GP CPU. Но кроме GP CPU могут активированны zIIP(есть у нас один такой, но это в основном для Java, a Java у нас нет), zAAPs, IFLs, ICFs, дополнительные SAP (I/O subsystems) у нас их четыре, но они не видимы ни системе ни программам.

Кстати "чип" еще называется PU - Processing Unit. Точнее чип (с "cores", называемых IBM "CPU")- основной элемент PU.
Так что все очень просто. Согласитесь?

P.S. Vsyu texnicheskuyu informaciyu o zBC12 mozhno najti zdes':

https://www.ibm.com/common/ssi/ShowDoc. ... ml&lang=en

Напомню, в этом году IBM аннонсирует "z16".

[Мальчик-Одуванчик]

То есть два шестиядерных процессора, один из которых отключен, а у другого активировано только четыре ядра?

[Palych]

ну проблем все же сильно меньше чем таким же анонизмом заниматься в бд. вот сколько надо выделить пользовательским процессам в бд с их pl/sql кодом ? там то вообще памятью не дают управлять. в реале получается в pl/sql ты вообще никак не управляешь и только страдаешь, а в жава у тебя 100500 вариантов GC и offheap если хочется совсем вручную порулить.

В PL/SQL нет threadов. Это радикально упрощает управлению памятью. Поэтому и не нужны 100500 вариантов GC.
Когда давили web threads в JS - передачу параметров туда сделали как в удаленные сервисы, в виде строк.
В rust придумали хитрую систему передачи владения между потоками.
В java ничего такого нет. Это сильно облегчает жизнь разработчикам, и сделало jvm популярнее битлов.
Но в то же время при сборки мусора кучу времени приходится тратить чтобы определить можно это выбросить или нет.

а разделяют AS от бд зачастую потому как перфоменс кратно вырастает за счет памяти. на двух серверах в двое больше памяти, у AS кеш, у базы сильно больше кеш. достать данные из кеша дб по нетворку в сотни более быстрая операция, чем юлозить головками HDD в рамках одного сервера. т.е. на двух серверах гораздо больше шансов засунуть активную часть данных в память и снизить на порядок требования к i/o.

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

А вообще-то я говорил об истории этого решения. Когда начали разделять AS и DB - память серверов считалась мегабайтами.

[Palych]

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

это уже работает. запускаю джобу - датабрикс видит, херасе, 10Тб перемалоть, добавляет в кластер на лету дополнительно 8 нод. после расчета эти 8 выключает.

Речь вообще-то шла об OLTP, но у меня вопрос: как датабрикс решает что нужно добавить 8 нод, а не 2, не 16?