Айтишники на пенсии

[flip_flop]

zVlad и _adda_, спасибо за объяснения. Насколько я понял, главное преимущество МФ и z/OS в том что обмен данными между процессами (IPC) выполняется гораздо быстрее, чем в сети построенной из Linux/x86. Ну что же, это действительно важно для распределенных приложений в сети, которые нельзя запихнуть в один узел из-за гигантской памяти. Но нынче размер памяти растет очень быстро, как и число CPU. Если делать обмен данными между процессами внутри одного узла (не в сети) с разделенной памятью, то он будет достаточно быстрым. Еще лучше если внутри одного процесса. Единственная большая проблема - скорость доступа к оперативной памяти от всех этих бесчисленных CPU. Как только эту проблему решат (то что ее решат у меня сомнений нет) то преимущество МФ будет потеряно, правильно?

Noztradamus,

Это было сравнение одного и того же МФ - в первом случае с zOS, во втором - с Linux. В тестах Java EE MF нет, совсем нет, как и в других тестах. Побеждают там оракловские спарки и оракловские серверы на Xeon. И на х86 серверах можно использовать вплоть до 64 ТБ разделяемой памяти, что не так и мало: в статье от адды была память порядка 30 ГБ, у меня на десктопе 64 ГБ стоит.

Просто для ясности.

[adda_]

И будет круто, пока интернет провайдер на полдня не отключит интернет, а у клиента бизнес 24х7 и на кону жизни людей.

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

Пользователи нашего клиента имеют доступ к своей ИТ (не только МФ) не по интернет-у. Кстати, были времена когда интернет был бизнесом IBM. Global Network называлось:

http://www.internetnews.com/bus-news/ar ... illion.htm

Я именно это и имел ввиду. Когда вместь локальных сетей и собственных серверов (не важно на какой платформе) все тащат в облако ибо круто.

[mskmel]

.. Персонала сильно больше чем под МФ, его проще найти и заменить при случае.

Персонала и надо гораздо больше чем с МФ. A персонал бесплатным не бывает. Это тоже учитывать надо.
Двенадцать Windows сервер admins обслуживают у нас 900 виртуальных Wintel серверов. Одной из основных, ongoing, работ у них является assets refresh (они постоянно что-то обновляют, постоянно апплают патчи на системы).

12х900 при 24х7 доступных людях это гуманно, они также смогут и 12х5000. Это всего 2-3 человека в одну смену.
12 при 24х7 это не по 200к\год каждый, а сильно дешевле. Обновления накатывать гении в США\Канаде не нужны, вполне справятся подаваны с 1-3мя годами опыта в более дешёвых странах.

Сравните со мной одним управляющимся с двумя МФ и 4 + 2 DR системами на них.

А вот потянули бы Вы 100-200 МФ? И неужели настолько неважная система, что готовы принять риск недоступности единственного админа? Понятно что Вы on-call, но пока позвонили, пока проснулся, пока подсоединился... глядишь уже час-полтора как всё лежит, а еще ничего чинить и не начинали! "Такого ни разу не было", потому что повезло, потому что МФ всего два. Было бы 200, то раз в неделю-две что-то бы лежало...

[sfbaguy1]

zVlad и _adda_, спасибо за объяснения. Насколько я понял, главное преимущество МФ и z/OS в том что обмен данными между процессами (IPC) выполняется гораздо быстрее, чем в сети построенной из Linux/x86. Ну что же, это действительно важно для распределенных приложений в сети, которые нельзя запихнуть в один узел из-за гигантской памяти.

Это обычные преимущества вертикально шкалируемой системы.
Таких как сановские спарк сервера например. Вместо распределенного
приложения на такой системе можно сделать огромное монолитное приложение. И работать оно будет намного быстрее за счет отсутствия синхронизации по сети. Все через общую память. Несомненый ништяк.
Есть одна проблема- цена такого решения и его
апгрейда. Поэтому в большинстве случаев победил подход
с горизонтальным шкалированием (распределенные приложения на большом количестве маленьких систем).

[mskmel]

Когда вместь локальных сетей и собственных серверов (не важно на какой платформе) все тащат в облако ибо круто.

Ибо заустали! То recall на эту детальку, то FW на этих железках обновлять, то тут память заглючила, то тут сеть в разнос пошла. Не говоря о хронических проблемах целых партий серверов, как вам задачка: "На 400 серверах поставленных в первом полугодии 2016 глючные БП, надо поменять их все!" А серверы уже работают на разных приложениях, в разных ДЦ по всей стране, у каждого приложения свой жизненный цикл, свой обслуживающий персонал. Только замена закончилась: "Ой! БП что мы поставили тоже глючные, надо бы поменять!". Эта песня хороша - начинай сначала. Или: "На это CNA нет FW валидированной с этой версией Линух и одновременно валидированной FC switch"? Я не железячник, но два месяца играл в пинг-понг с RH-Brocade-HP, пока не поставили обычные HBA... И это не один сервер, а десятки.

Низкоуровневые проблемы с инфраструктурой создают огромное количество проблем, которые никому не приносят радости. Серверы уже давно в lease, так что они уже "не свои". Даже при контрактах с вендорами нужны толпы народа, которые будут вендоров без остановки пинать, организовывать, согласовывать, следить за работами по замене\обновлению. В такой ситуации клауд выглядит как волшебное лекарство - один вендор, который если что виноват. Он сам разбирается со своими десятками тысяч серверов. А для Клиента это выглядит как один большой сдаваемый в аренду калькулятор с прогнозируемым OPEX...

[mskmel]

Завтра - в переносном смысле. Все переписать тоже не один год занимает.

Переписывать возможно и не надо. Недавно мигрировали VAX VMS с кучей кода на Коболе. Есть вполне работающий эмулятор VAX VMS под винду, есть vCobol. На всё про всё ушло полгода и несколько десятков тысяч на софт и людей. Вместо нескольких шкафов получили несколько юнитов стойке, в разы быстрее и дешевле.

Если используются какой-то специализированный z\OS софт, то надо искать альтернативы, они должны быть! Потому как смигрировавших значительно больше чем оставшихся. Есть спрос - есть предложение. Тут важнее воля руководства и толковые, инициативные специалисты.

Удачи!

[kyk]

....

можешь ведь когда захочешь

[Nostradamus]

Это было сравнение одного и того же МФ - в первом случае с zOS, во втором - с Linux. В тестах Java EE MF нет, совсем нет, как и в других тестах. Побеждают там оракловские спарки и оракловские серверы на Xeon. И на х86 серверах можно использовать вплоть до 64 ТБ разделяемой памяти, что не так и мало: в статье от адды была память порядка 30 ГБ, у меня на десктопе 64 ГБ стоит.

Я понимаю что сравнение было МФ с МФ. Но если zOS работает существенно быстрее чем Linux на одном и том же железе, то она явно будет еще быстрее по сравнению с Linux/x86 (ну или Linux/Xeon для более правильного сравнения). Хотя прямых бенчмарков можно и не найти.

[flip_flop]

Это было сравнение одного и того же МФ - в первом случае с zOS, во втором - с Linux. В тестах Java EE MF нет, совсем нет, как и в других тестах. Побеждают там оракловские спарки и оракловские серверы на Xeon. И на х86 серверах можно использовать вплоть до 64 ТБ разделяемой памяти, что не так и мало: в статье от адды была память порядка 30 ГБ, у меня на десктопе 64 ГБ стоит.

Я понимаю что сравнение было МФ с МФ. Но если zOS работает существенно быстрее чем Linux на одном и том же железе, то она явно будет еще быстрее по сравнению с Linux/x86 (ну или Linux/Xeon для более правильного сравнения). Хотя прямых бенчмарков можно и не найти.

Насчет "явно быстрее по сравнению с Linux/Xeon" - совсем не уверен. Тем более если сделать IPC через память, как указывали выше. Для Xeon-ов есть бенчмарки именно по Java EE. Для МФ - ничего нет, совсем. Кроме того, Linux на МФ не совсем еквивалентен Линуксу на  Xeon, нет?

[zVlad]

.. Персонала сильно больше чем под МФ, его проще найти и заменить при случае.

Персонала и надо гораздо больше чем с МФ. A персонал бесплатным не бывает. Это тоже учитывать надо.
Двенадцать Windows сервер admins обслуживают у нас 900 виртуальных Wintel серверов. Одной из основных, ongoing, работ у них является assets refresh (они постоянно что-то обновляют, постоянно апплают патчи на системы).

12х900 при 24х7 доступных людях это гуманно, они также смогут и 12х5000. Это всего 2-3 человека в одну смену.
12 при 24х7 это не по 200к\год каждый, а сильно дешевле. Обновления накатывать гении в США\Канаде не нужны, вполне справятся подаваны с 1-3мя годами опыта в более дешёвых странах.

...

Вы учитываете только ту зарплату что платит емплоыер работнику. А есть еще дополнительные расходы на работника. Сказав $200К я на самом деле занизил расходы на работника. У нас есть орлы которые в год больше $200K na overtime делают.
Наши 12 с 900 серверами работают в одну смену плюс on-call и их не хватает порой. Они конечно не упахиваются, так как канадцы и при том юнионайзед.

[zVlad]

....

Сравните со мной одним управляющимся с двумя МФ и 4 + 2 DR системами на них.

А вот потянули бы Вы 100-200 МФ? И неужели настолько неважная система, что готовы принять риск недоступности единственного админа? Понятно что Вы on-call, но пока позвонили, пока проснулся, пока подсоединился... глядишь уже час-полтора как всё лежит, а еще ничего чинить и не начинали! "Такого ни разу не было", потому что повезло, потому что МФ всего два. Было бы 200, то раз в неделю-две что-то бы лежало...

Система очень важная. Серцевина ИТ клиента. Риски низки не потому что есть или нет бэкап у меня, а потому что система очень надежная. 100-200 МФ в принципе не нужно ни одному бизнесу, точнее нет такого бизнеса которому бы понабилось столько МФ, нет такой нагрузки вычислительной. У ИБМ по всему миру не больше 50 МФ. Более того в мире нет (ну может есть один) ни одного МФ сконфигурированного на полную мощность (141 CPU на сегодня). Трудно представить нагрузку, которую такой МФ может потянуть.
За 17+ лет наши (их было 3 когда я пришел) МФ ни разу не лежали. Был blackout в Торонто, но это blackout. За 17 лет не припомню ни одного on-call чтобы система была недоступна. Самое страшно это backup on tape failure, и replication for reporting. Меня вообще очень, очень редко вызванивают. Знакомый админ на Юникс ненавидит on-calls потому что его будят всякий раз. А я на on-call давно уже 365 дней в году и неважно в Мехике я, или в России, или на озере в Маскоке водки напился. Другой знакомый admin на Windows каждый раз как мы едем на озеро хоть раз но ночью сисдит с laptop-ом и что-то там колдует.

[Nostradamus]

Linux на МФ не совсем еквивалентен Линуксу на  Xeon, нет?

Вполне возможно, скорость работы приложений Linux зависит от оптимизации ядра и компилятора к железу. Если Linux не оптимизирован к МФ (а я подозреваю что это так потому что это не mainstream) то Linux/Xeon должен быть гораздо быстрее чем Linux на МФ.

[zVlad]

zVlad и _adda_, спасибо за объяснения. Насколько я понял, главное преимущество МФ и z/OS в том что обмен данными между процессами (IPC) выполняется гораздо быстрее, чем в сети построенной из Linux/x86. Ну что же, это действительно важно для распределенных приложений в сети, которые нельзя запихнуть в один узел из-за гигантской памяти.

Это обычные преимущества вертикально шкалируемой системы.
Таких как сановские спарк сервера например. Вместо распределенного
приложения на такой системе можно сделать огромное монолитное приложение. И работать оно будет намного быстрее за счет отсутствия синхронизации по сети. Все через общую память. Несомненый ништяк.
Есть одна проблема- цена такого решения и его
апгрейда. Поэтому в большинстве случаев победил подход
с горизонтальным шкалированием (распределенные приложения на большом количестве маленьких систем).

Good point. На одном МФ таких "огромное монолитное приложение" можно иметь много и апгрэйды при этом легки и нетрудоемки.
С другой стороны горизонтальное шкалирование не снимает проблем апгрэйдов и очень не удобно для DR recovery. У горизонтального шкалирования много минусов, а причина его одна: не достаточно мощности все выполнять на одном узле. Т.е. этот способ от безисходности применяется. МФ эту задачу решает наилучшим из известного образом.

[zVlad]

zVlad и _adda_, спасибо за объяснения. Насколько я понял, главное преимущество МФ и z/OS в том что обмен данными между процессами (IPC) выполняется гораздо быстрее, чем в сети построенной из Linux/x86. Ну что же, это действительно важно для распределенных приложений в сети, которые нельзя запихнуть в один узел из-за гигантской памяти. Но нынче размер памяти растет очень быстро, как и число CPU. Если делать обмен данными между процессами внутри одного узла (не в сети) с разделенной памятью, то он будет достаточно быстрым. Еще лучше если внутри одного процесса. Единственная большая проблема - скорость доступа к оперативной памяти от всех этих бесчисленных CPU. Как только эту проблему решат (то что ее решат у меня сомнений нет) то преимущество МФ будет потеряно, правильно?

Я бы не сказал что это главное преимущество МФ: обмен через память вместо сети. Есть и другие, а это скорее следствие того что ОС з/ОС так устроена что чем больше "процессов/задач" выполняется на одном МФ (пусть даже в разных партициях/экземплярах ОС, которых на МФ всегда много) тем еффективнее используются ресурсы и тем в итоге их меньше надо.
Гонка за количеством CPU и скоростью доступа в память это не про МФ, от слова вообще. Один из наших МФ имеет 1(один) CPU сконфигурированный на самую низкую проиводительноcть (уровень 1 из 26) и на нем в 3(трех) партициях выпоняется три z/OS: 1)Production s pol'zovatelyami, 2)Dev/QA с програмистами, и 3)мой Sandbox со мной. До недавнего времeни была еще одна партиция/система, четвертая, но я приложения из нее перенес в ту где Dev/QA. Кроме того это МФ (1 CPU) является DR site для Production другого приложения. Но в случае DR он делается за секунды треxCPU-шным с 26-м уровнем (верхним) производительности и становится достаточно мощным чтобы принять Production нагрузку s 4-x CPU-шного МФ.

Не все, далеко не все проблемы могут быть решены увеличением количества CPU и скорости доступа в память. Наоборот, те подходы о которых Вы говорите будут только усугублять проблему: чем больше CPU тем больше ресурсов требуется только на управление ими. Кроме того не все задачи допускают распаралеливание. На МФ есть такой механизм который "parkuet" CPU когда слысла в их бОльшем количестве нет. Тем самым сокращаются накладные расходы на их управление. HiperDispatch https://en.wikipedia.org/wiki/HiperDispatch называется.

Тем не менее я допускаю что все преимущества МФ могут быть достигнуты или даже превзойдены, но... если будет создана система равная МФ. Это примерна таже проблема как с искусственным интелектом: его можно достичь, если сделав искусственного человека. Но они уже созданы, они есть, и МФ, и человек. И они не стоят на месте, наоборот, совершенствуются непрерывно. Хотите за этим гоняться?