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

[zVlad]

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

Это шедевр. Реально. Я распечатаю и повешу на стенку.
Я хотел написать больше, но не буду. Все и так очень даже понятно.

Вы зря смеетесь. В реальной жизни все именно так и происходит. Сисадмин накатил очередной апдейт на ось и в продакшене сразу что-то отвалилось. Причем если отвалилось сразу и по простому - то это еще пол беды. Настоящая Камасутра обычно начинается когда внезапно оказывается что какое-то приложение вдруг начало гнать пургу и выясняется все это только через некоторое время.

В реальной жизни все происходит по разному. А в ваших проблемах виноват не сисадмин. Далеко не сисадмин.

[Palych]

У Вас нет примера script-a?

Честно говоря, ни разу докер руками не трогал.
Поисковик выдал это:
https://docs.docker.com/develop/develop ... practices/

[zVlad]

Начнем подведем итоги.

Вот мой проект резолюции:

Обосновательная часть резолюции:

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

Классический/централизованный - это подход реализуемый в zOS на IBM mainframe. Этот подход предполагает максимальную концентрацию сервисов под управление одной системы или небольшого их количества обединых Parallel Sysplex. Об этом подходе я пока ничего не скажу кроме то что он имеет место быть и уходить не собирается.

Неоклассический/распределенный - это подход главным принципом которого является распределение элементов конфигурации на отдельных, независимых, серверах. Предельное, желаемое, отношение это один сервис - один сервер. Результатом такого подхода оказались операционные системы упрощенного типа. В само деле зачем для простой нагруки городить sophisticated (или точнее созданной для управления сколь угодно сложных конфигураций) OS? И действительно популярные ОС для серверов это простые Unix/Linux. Простые потому что во-первых, даже в настоящее время для серверeрных частей ИТ используются комодити сервера физически не способные нести сложную конфигурацию, или даже простую, но обемную в смысле нагрузки. Для сложных и обемных конфигураций используются совокупность многих комодити серверов. Так делается в облаках. Во-вторых, даже если взять мощный сервер то грузить его сложной конфигурацией не позволяют системы хранения данных *ввод-вывод) и неготовность имеющихся ОС длы управления сложными конфигурациями.
Если посмотреть на эти пороцессы исторически то поначалу, когда сервера были еще маленькими, сложение мощностей нескольких серверов и разделением конфигурации на части (БД, сервер приложений, DNS sервера, domain (AD) и т.п сервера) позволяло поднимать более менее сложные конфигурации. Там где не хватало одного маленького сервера ставили несколько кластеризуясь. Потом мошность серверов выросла в разы за счет подьема тактовой частоты и за счет повышенуя уровня интеграции (эти два направления по разному работают). Тактовая частота давно уже уперлась на комодити серверах в 2.3 GHz (более высокие частоты требуют более дорогих, неприемлимых для комодити, решений), а уровень интеграции пока потихоньку растет, но что с этим делать в комодити серверах не очень понятно. Так или иначе в изначально гармоничной схеме назрел кризис. Минимальноразмерные сервера стали превышать потребности многих отдельных сервисов. На арене появились виртуальные машины и вернули гармонию в сферу ИТ основанную на распределенной обработке. Но как оказалось не надолго. Бороться с некоторыми проблемами даже виртуальные машины оказались не в состоянии.
И появились контейнеры и Docker-ы. Строго говоря сначала появились блокчаэйны, Хадупы и т.п. решения главной особенностью которых было обединения очень больших количеств комодити серверов в одно целое. БОльших чем позволяли кластеры. О них я говорить не буду здесь чтобы не загромождать тему о контейнерах и, кмк, микросервисах.

Продолжение следует.....

[iDesperado]

главную революцию, что принес докер - DSL язык описывающий конфигурацию, именно он убрал прослойку в виде админов и показал, что девелоперы без привлечения админа могут описывать и деплоить кофигурации. мне кажется вся эта идеология infrastructure as code, devops уже позже поперло.

[zVlad]

главную революцию, что принес докер - DSL язык описывающий конфигурацию, именно он убрал прослойку в виде админов и показал, что девелоперы без привлечения админа могут описывать и деплоить кофигурации. мне кажется вся эта идеология infrastructure as code, devops уже позже поперло.

Я много лет вижу сисадминов и DBA на распределенных системах безропотно выполняющих скрипты написанные девелоперами и вдруг оказывается что они были ненужной прослойкой.
В другой стороны действительно если оказывается что сисадмины это слуги девелоперов то нахрен они вообще нужны. Давно уже известно что девелоперы на распределенных системах лучше знают систему (а что там знать? Там все не о системах, а о программах выполняемых на компьютерах - там нет как таковых систем. И опять же получается что сисадмины не нужны.

[KinDzaDza]

В реальной жизни все происходит по разному. А в ваших проблемах виноват не сисадмин. Далеко не сисадмин.

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

[zVlad]

В реальной жизни все происходит по разному. А в ваших проблемах виноват не сисадмин. Далеко не сисадмин.

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

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

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

В реальной жизни все происходит по разному. А в ваших проблемах виноват не сисадмин. Далеко не сисадмин.

"Cистема обеспечения надежности выведет из строя все другие системы."

[iDesperado]

На форуме надо обвсуждать написанное участниками, а не самих участников. Сколько можно эту простую истину повторять?

прости, но с такой головой ты не можешь рассчитывать на то же отношение, что и к прочим участникам.

[Bobeg]

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

Это шедевр. Реально. Я распечатаю и повешу на стенку.
Я хотел написать больше, но не буду. Все и так очень даже понятно.

Вы зря смеетесь. В реальной жизни все именно так и происходит. Сисадмин накатил очередной апдейт на ось и в продакшене сразу что-то отвалилось. Причем если отвалилось сразу и по простому - то это еще пол беды. Настоящая Камасутра обычно начинается когда внезапно оказывается что какое-то приложение вдруг начало гнать пургу и выясняется все это только через некоторое время.

В реальной жизни все происходит по разному. А в ваших проблемах виноват не сисадмин. Далеко не сисадмин.

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

[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 рядом крутиться не сможет.