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

[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?

[zVlad]

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

Нет, не так. Во-первых, почему Вы не читаете что я написал и если плохо написал не идете по ссылке? Во-вторых, из 12 ядер (если хотите буду пользиваться Вашей терминологией) 4 ядра это SAP (читайте выше), 4 ядра это GP CPU (тоже выше обяснялось), одно ядро - zIIP (для Java workload). Тотал 9, Right? И три "ядра" не активироваНЫ!!!!
4+4+1+3= ?
Ну а что Вы то хотели сказать?

[zVlad]

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

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

Exactly!!!

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

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

Ну а что Вы то хотели сказать?

Что если пользоваться моей терминологией то под cores подразумеваются вычислительны ядра общего назначения.
У процессоров Intel, AMD может быть тоже куча других вспомогательных ядер, например в графической подсистеме, но их обычно не смешивают с cores.

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

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

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

[alex_127]

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

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

и так 10000000 раз в секунду. packet rate - он не бесконечный и не всегда определяется физической скоростью интерфейса.

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

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

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

и так 10000000 раз в секунду. packet rate - он не бесконечный и не всегда определяется физической скоростью интерфейса.

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

[Palych]

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

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

Просто зима, полагаете вы? — Полагаю...

Вот так и строим системы: полагаем, предполагаем...

[voyager3]

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

Ответ писался в контексте обсуждения целесообразности использования мейнфрейма ради того, чтобы приложение и БД крутились на одной машине. Современные сети позволяют не только разнести приложение и БД, но даже отдельные компоненты БД на отдельные "обычные" машины.
Про RDMA - скорее как косвенное подтверждение: экономить время на обработку пакетов обычным сетевым стеком имеет смысл, когда сеть достаточно быстрая, чтобы время обработки было заметно на фоне времени отклика сети.

[zVlad]

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

Ну а что Вы то хотели сказать?

Что если пользоваться моей терминологией то под cores подразумеваются вычислительны ядра общего назначения.
У процессоров Intel, AMD может быть тоже куча других вспомогательных ядер, например в графической подсистеме, но их обычно не смешивают с cores.

И в МФ не смешивают. Просто есть CPU (я буду называть их так как называется) разных назначений. Назначение их определяется конфигурированием сaмой IBM перед продажей и по запросу о переконфигурировании. CPU активируются столько сколько попросил заказчик. И того типа какой попросил заказчик. SAP активириется IBM по их соображением, но вероятно тоже можно что-то попросить.
Высчислительными с точки зрения выполнения кода системы и прикладных програм являются в zOS: GP, zIIP, zAAP. Вычислительными длая zVM/Linux - IFL. Невычоислительными (служебными): SAP, ICF. Есть еще криптокарты (типа видео карты) про них рець не идет. Есть OSA, FICON карты на них тоже очень даже могут быть процессоры.
Количество PUs (процессор по Вашему, с 6 CPU для zBC12) определяется суммой потребных CPUs. Да могут оказаться не все CPU активированы, болле того активированные GP CPU (только GP) могут работать с разной производительностью.
Величной описывающей производительность является не количество CPU и не тактовая частота, а MSU - Millions of Service Units. Плата за софтваре требующий GP CPU (zOS, CICS, DB2, и т.п.) определяется не количеством CPU, а значением MSUs. Одно и то же значение MSU можно получить на разном количестве активных CPU. У нас их 4 (performance model - O04), MSU = 125. Примерно такую же производительность мы могли бы иметь с моделями: L06(125), QO3(123), T02(122), MO5(121), и наконец Z01(133). Т.е. нам бы (теоритически) хватило одного активированного CPU на мaксималь[ной производительности. Но мы естественно учитывали мультизадачность. Возможно L06 был бы лучшим вариантом. Эти вопросы решаются не на моем уровне, а на уровне нашего клиента - МФ они владеют и покупают. В действительности думаю им так советует IBM. С точки зрения финансов за софт все эти варианты эквивалентны. За железо было бы дешевле Q03 потому что для нее достаточно иметь один PU.

Ну а что все таки Вaс смущает что Вы раз за разом возвращаетеся к вопросу o "cores" "процессор"?

Да, МФ и сервера на Intel, AMD это разные вещи. Термины похожи, но суть далеко не одна и таже. Потому их и различают. У нас приближается торжественный момент - переход с МФ на Azure. Вендор приложения один и тот же, функционально приложение одно и тоже, данные одни и теже, команда ползователей одна и таже. Уникальный будет эксперимент. Было написано это приложение на zOS, CICS, Cobol, DB2. Переписано на Linux, WildFly, Java, Oracle.
Уже созданы десятки серверов в Azure. Один сервер БД (я о нем говорил), 11 AS. еще будут failover (на МФ этого нет), будет DR (на МФ для этого использовался второй МФ с другим Production приложением на другой локации.
В этот выходной буду качать данные из Production DB2 в Oracle. Cut-over намечeн на июль. Это будет эпохальное событие. Бюджет уже трещит по швам, десятки лимонов потрачены. На вчерашнем митинге говорили о 17 серверах которые еще надо создать в Azure. Штук 20 уже есть походу. Под каждый инстанс (Prod, Dev, QA, Trainig). МФ один пока справляется до всем этим набором (БД и AS). Разве это не круто? Вот решил кто-то под продуцтион зарядить сервер с 16 cpu(cores), 256GB, 32TB дисков. Тоже самое под QA, примерно тоже под Dev (их уже два), Training, Sandbox. Под каждый! А сеичас это все на одном МФ с 4 CPU(cores) 32GB, и 10 TB дисков.

[zVlad]

Вот какие страсти оказывается кипели вокруг попыток использовать zOS на емуляторах (Herciles, это из Вики статьи про него) IBM mainframes (zSeries):

In 2009, Roger Bowler founded TurboHercules SAS, based in France, to commercialize the Hercules technology. In July 2009, TurboHercules SAS asked IBM to license z/OS to its customers for use on systems sold by TurboHercules. IBM declined the company's request.[7] In March 2010, TurboHercules SAS filed a complaint with European Commission regulators, alleging that IBM infringed EU antitrust rules through its alleged tying of mainframe hardware to its mainframe operating system, and the EC opened a preliminary investigation.[8] In November 2010, TurboHercules announced that it had received an investment from Microsoft Corporation.[9] In September 2011, EC regulators closed their investigation without action.[10]

[zVlad]

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

Ответ писался в контексте обсуждения целесообразности использования мейнфрейма ради того, чтобы приложение и БД крутились на одной машине. Современные сети позволяют не только разнести приложение и БД, но даже отдельные компоненты БД на отдельные "обычные" машины.
Про RDMA - скорее как косвенное подтверждение: экономить время на обработку пакетов обычным сетевым стеком имеет смысл, когда сеть достаточно быстрая, чтобы время обработки было заметно на фоне времени отклика сети.

Заинтреговали вы меня вашим RDMA. Стал смотреть как к этому относится МФ и zOS. Оказывается хорошо, и давно. Строго говоря эту тему - комуникация между хостами - на МФ решается тремя путями: 1. Через OSA карт. 2. Через память между LPARs на одном и том же МФ - HiperSockets, и 3. Через IBM System z RoCE Express через протокол RDMA, называемый в zOS SMC-R ( Shared Memory Communications – Remote Direct Memory Access (RDMA)).
Я использую первые два, для второго у нас не та версия системы (нужен zOS 2.1) и нет железа.

Понятно что поскольку HiperSockets использует память той же машины, то задержки сети полностью исключены. Таким образом для обмена между LPARs на том же МФ это самый скоростной путь. Кроме того код HiperSockets выполняется не на GP CPU, a на zIIP (это дешевле).
Те кто использует MF (LinuxONE) только с Linux-ами могут продолжать строить распределенные решения и использовать по сути удаленный прямой доступ к памяти давно извсетным и доступным на МФ HiperSockets.
Поэтому RDMA (SMC-R) на МФ доступен только через zOS, для связи систем на разных МФ "over a 10GbE Layer 2 LAN". Для связи zOSs на одном МФ используется HiperSockets.

Вот что пишут в одной статье про сравнение performance SMC-R с OSA:

IBM z/OS SMC-R Performance Considerations
December 2013
..........
.....The question of
how SMC-R compares to TCP/IP over HiperSockets also comes up frequently,
despite the fact that these are inherently different technologies. HiperSockets
focuses on optimized communications within a System z CPC, whereas SMCR enables optimized communications across System z CPCs. While not discussed in detail in this document, internal IBM benchmarks have shown that
SMC-R begins to approach the same levels of low network latency that Hiper-
Sockets offers. However, SMC-R is more CPU efficient <умолчали про zIIP - zVlad>, especially when larger
payloads are involved in the traffic patterns. In contrast, HiperSockets does offer a network bandwidth advantage, since it is not constrained by the physical
network bandwidth limitations that are present in physical networks such as
10GbE. Also note that there are several other key (non-performance-related)
differences in the two technologies that also should be considered such as:
1. SMC-R is restricted to TCP workloads (HiperSockets supports all protocols)
2. SMC-R is a point-to-point solution (HiperSockets provides Broadcast
and multi-cast support)
3. SMC-R requires RoCE hardware (HiperSockets does not require any
additional hardware). In some environments this (internal communication) aspect is considered more secure.
4. SMC-R virtualization (sharing) capability lags HiperSockets virtualization capability.

[iDesperado]

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

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

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

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

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

там под капотом spark, у которого полноценный оптимизатор + lazy вычисления. строит план, смотрит на источник что прочесть надо. у него там есть свое понятие партиции, он знает сколько какие источники в сколько его партиций вычитать можно, а партиции он может обрабатывать в параллель. видимо на этих данных можно решить сколько executors было бы оптимально запросить.

[Bobeg]

Дайошь эмулятор zOS для клауда!

[Bobeg]

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

[zVlad]

Дайошь эмулятор zOS для клауда!

Клауд загнется эмидировать 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, на разных мф, в разных дата центрах.

[Bobeg]

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

Это Вы о чем? ИБМ дал миру ИТ все базовые нове термины и принципы работы. Это кокуренты ИБМ начали придумывать новые термины чтобы отвадить молодеж от ИБМ.
В данном случае ИБМ дал название своему продукту созданому на основе стандарта. Могли бы легко обойтись и без стандарта. Как Вы надеюсь поняли на мф давено уже используется 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?

[Flash-04]

Значит уже кто-то подгреб этот термин.

[Amirko]

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

[Bobeg]

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