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

[Palych]

В ИТ (Речь идет исключительно о серверной стороне IT) сложилось два подхода для обеспечения поддержки сложных конфигураций.

Надо бы пояснить что такое сложные конфигурации.

[Bobeg]

например такая гадость как мирроред репликейтинг лоад балансед сервер сойдет за сложную конфигурацию?

[Boriskin]

Надо бы пояснить что такое сложные конфигурации.

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

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

[Bobeg]

микросервисная кошкина колыбель.

[Boriskin]

микросервисная кошкина колыбель.

Хорошо, если микро...

[zVlad]

В ИТ (Речь идет исключительно о серверной стороне IT) сложилось два подхода для обеспечения поддержки сложных конфигураций.

Надо бы пояснить что такое сложные конфигурации.

Охотно. Это когда весь stack целого сегмента ИТ выполняется в одной системе. В одной zOS если говорить по МФ-ски. Или в одном Параллел Сисплех если одного МФ не хватает (что трудно представить зная какими можностями может нынче располагать единичный МФ).
Я понимаю что сказаное выше в принципе противоречит всем догмам современной науки о арцхитектуре ИТ. По ней миниму два узла должно быть: AS, and DB.
На МФ уже много лет используется термин: "co-location". Согласно этому термину лучшем решением является помещение AS, and DB на одном сервере. На том же сервере можно расместить и многое другое имеющее или не имеющее отношение к сехменту ИТ. Для чего? Чтобы зполнить неиспользуемые ресурсы как миниму.
Примерно это я имею в виду говоря о сложных конфигурациях. Обычно же сложность решается добавлением серверов, ВМ, контейнеров и т.п..

[zVlad]

например такая гадость как мирроред репликейтинг лоад балансед сервер сойдет за сложную конфигурацию?

На моем МФ сейчас выполняется DB (реплицируемая частично в MS SQL) и пять серверов транзакций. Могли бы, и должны были, также выполняться Вебсервера (WebSphere) нового интерфейса. Но WebSphere были помещены на отдельные несколько AIX серверрав.
Это контрпродуктивно с точки зрения "co-location".
Сейчас на этом МФ в двух разных партициях разделенных по CPU shares на 80 и 20 в целом выполняется три DB2 subsystems, и штук 10 серверов транзакций. 5 Production, Dev, Uat/QA, Training, baseline и sandbox разные. Когда во второй партиции запускается что-нибудь долгоиграющее и отхватывается 20% CPU, to Production с 80% начинаетс загибаться. Причем субективно производительность в меньшей партиции, из-за низкой его загруженность, выглядит выше чем в Production. Ей хватает 20% на все.
Если же сделать одну партицию и обединить все DBs и сервера транзакций под одну систему и назначить класс сервиса Production компонентам выше чем второстепенным, то у Production не возникало бы проблем и второстепенные компоненты могли бы худо-бедно выполняться. А так как сейчас получется что мы не можем запускать никакой долгоиграющей работы во второй партиции, даже если нам не надо выполнять ее быстро, пакетное задание, оно все равно получит все полагающиеся 20% и Production останется с 80%, а нам иногда и 100% маловато, в пиковые часы.
По другому можно было бы обе системы обьединить в Parallel Sysplex и тогда тоже можно было бы управлять ресурсами исходя из совокупной обстановки в разных партициях. Но у нас Sysplex нет согласно кем то когда то придуманой политике. Строго говоря по нашим обемам работы и количестве сервисов и серверов Sysplex - это было бы излишество. Одна zOS со всем этим прекрасно бы справлялась.
Вот и получается что чем больше самых разноображных серверов и сервисов под одноj zOS тем выше коэффициент использования ресурсов и тем прожче управлять их использованием.

Вот такаы иллюстрация сложной конфигурации в моем понимании. Тем кто не читал моих постов о наших МФ сообщаю речь о МФ с 4 CPU на не самой высокой из возможных скоростей и 32 GB RAM. U нашего клиента примерно 10 000 работников многие из которых пользуются этим приложением. Сейчас начинаем мигрировать базу данных на Oracle. Сервер только под базу данных и ничего больше запланирован быть с 16 CPU и 256 GB RAM. Что из этого получится пока никто не знает и знать не сможет до после cut-over на реальную нагрузку.

[Bobeg]

всего 32 гб рама и 4 cpu?
я ковырялся с большим HP сервером с терабайтом рама и 64 процессорами, что выглядит гораздо крупней чем этот мейнфрейм.

я вот чего не понимаю.
чем мейнфрейм отличается в принципе на хардвер уровне
от современного PC-совместимого сервера? вот скажем такого как этот терабайтный HP монстр.

[alex_127]

сейчас придет опять zVlad и расскажет что там даже биты только кошерные.
работал я с писателями DB2 LUW и zOS - люди как люди, одинаковые. много добра что было там in mainframes - hot-add, hot-swap/etc оно либо уменьшилось и есть везде либо сдохли поскольку люди все дороже а железяки все дешевле (вот скажите нафига мне в железе hot-add CPU in cloud? он же не стоит как охулиард в мейнфрейме). И много workloads которые гонялись они очень примитивны по стандартам сегодняшнего дня. Просто другие ожидания у людей - если они начинали с лаптопа или зеленого терминала 40х25.

и терабайт - это не монстр. 10 лет назад тестировал свое добро на 4TB/1280LP (windows, not cluster).

[voyager3]

я вот чего не понимаю.
чем мейнфрейм отличается в принципе на хардвер уровне
от современного PC-совместимого сервера? вот скажем такого как этот терабайтный HP монстр.

Теоретически большей вертикальной масштабируемостью, хотя чудес не бывает. И, опять же теоретически, у него можно всё на ходу поменять, и никто и не заметит. Ни первое, ни второе на фоне современных распределённых систем не сильно и нужно. Ну и от падения целого ВЦ всё равно не спасает.

[Flash-04]

>>. Когда во второй партиции запускается что-нибудь долгоиграющее и отхватывается 20% CPU, to Production с 80% начинаетс загибаться.

Влад, вы же совсем недавно рассказывали что мейнфрейм не убить 100% загрузкой.

[zVlad]

>>. Когда во второй партиции запускается что-нибудь долгоиграющее и отхватывается 20% CPU, to Production с 80% начинаетс загибаться.

Влад, вы же совсем недавно рассказывали что мейнфрейм не убить 100% загрузкой.

А я разве уже сказал что можно убить?
100 процентов происходит каждый день в пиковые часы и если вторая партиция не загружена продолжительной работой, транзакцией продолжительной (это больше 10 минут), то все эти 100 процентов достаются Продакшн и этого хватает. Но если вторая патриция отбирает 20 то остается 80 и это выливается в росте очередей и снижению респонс тайм. Поскольку у нас OLTP приложение, то пользователи начинают роптать, перелогиниваться, перезапускать задания. Т.е. еще больше грузить систему тупыми повторами. Все рано или поздно выполняется, ничего не падает, но дольше. И пользователи получают, например, десять одинаковых распечаток, столько сколько раз сами же и запускали.
Последний раз перезагружали прод 1 ноября 2020.

[zVlad]

всего 32 гб рама и 4 cpu?
я ковырялся с большим HP сервером с терабайтом рама и 64 процессорами, что выглядит гораздо крупней чем этот мейнфрейм.

я вот чего не понимаю.
чем мейнфрейм отличается в принципе на хардвер уровне
от современного PC-совместимого сервера? вот скажем такого как этот терабайтный HP монстр.

Чем то видимо отличается. Я знаю чем и много раз здесь объяснял. Это не просто, поэтому повторятся пока не буду. Но, даже без теоритических обоснований только для БД с мф подготовили 16 cpu, 256 GB и не факт что хватит. А мф не только БД тянет но и сервера транзакций, и cpu те 4 не на самой большой возможной скорости сконфигурированы, хватило бы и двух. На самом деле оного. Можете сами посмотреть на гугле модели zBC12 2828-O04 (примерно 1000 MIPS или PCI) на 4 cpu, и модель zBC12 2828-Z01 (несколько даже больше 1000 MIPS ) на одном cpu! на максимальной скорости (буква Z перед 01, а наш мф с буквой О перед 04)

https://www-01.ibm.com/servers/resource ... ment#zbc12

Это все мф года этак 2013-2014. Не самая последняя редакция мф, предпоследняя - z14, на одном cpu дает больше 1500 MIPS. На одном cpu. В 1.5 раза больше чем наш с 4 cpu.
У z15, текущая редакция мф, будет под 2000 MIPS на срu. Данных о z15 в приведенной выше ссылке нет.

[zVlad]

я вот чего не понимаю.
чем мейнфрейм отличается в принципе на хардвер уровне
от современного PC-совместимого сервера? вот скажем такого как этот терабайтный HP монстр.

Теоретически большей вертикальной масштабируемостью, хотя чудес не бывает. И, опять же теоретически, у него можно всё на ходу поменять, и никто и не заметит. Ни первое, ни второе на фоне современных распределённых систем не сильно и нужно. Ну и от падения целого ВЦ всё равно не спасает.

Распределенные системы давно уже превратились во вредную догму.
Наилучшие решения для disaster recovery даются на мф. Это всем интересующимся известно.
А вот в облаках такой уровень готовности для DR какой у нас есть на мф оказывается сильно дороже. Настолько сильно что даже наш небедный клиент уже подает недвухсмысленные сигналы бедствия по поводу расходов на покидание мф. А до плановой даты еще полгода и мы только начинаем мигрировать продакшн БД.

[Palych]

Это когда весь stack целого сегмента ИТ выполняется в одной системе. В одной zOS если говорить по МФ-ски. Или в одном Параллел Сисплех если одного МФ не хватает (что трудно представить зная какими можностями может нынче располагать единичный МФ).
Я понимаю что сказаное выше в принципе противоречит всем догмам современной науки о арцхитектуре ИТ. По ней миниму два узла должно быть: AS, and DB.
На МФ уже много лет используется термин: "co-location". Согласно этому термину лучшем решением является помещение AS, and DB на одном сервере. На том же сервере можно расместить и многое другое имеющее или не имеющее отношение к сехменту ИТ. Для чего? Чтобы зполнить неиспользуемые ресурсы как миниму.
Примерно это я имею в виду говоря о сложных конфигурациях. Обычно же сложность решается добавлением серверов, ВМ, контейнеров и т.п..

Я согласен что догмат о разделении AS и DB (он кстати не совсем современный, ему лет 20) порождает кучу проблем, зачастую на пустом месте.
Но это не связано со сложностью. Тут две причины: субъективная и объективная.
Во-первых при проектировании любой системы принято считать что она может развиться в глобальную, как минимум - очень большую. И тогда "один сервер уж точно не потянет". А разнести сервера так соблазнительно просто, с давних пор фирма SUN Microsystems выбросила идею "computer is a network"...
В результате всплывают проблемы с задержками, их героически решают перенося часть логики в stored procedures, между DBA и девелоперами идёт перманентная гражданская война за оптимизацию запросов... В общем - все при деле. Никто уже назад не оглядывается, насколько было бы быстрее и проще сделать всё на одном сервере.

Вторая причина: Java. Точнее - подход, который полностью освободил девелоперов от управления памятью, да ещё при наличии потоков, обращающихся к общей памяти параллельно. В результате стало практически невозможно прикинуть сколько памяти нужно приложению. Возникла практика: сколько на сервере есть памяти - столько и даём jvm на которой AS крутится. Естественно никакой DB рядом крутиться не сможет.