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

[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 называется.

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

[zVlad]

Многие вещи в z/OS принципиально не возможно реализовать в других системах на других платформах потому что они заложены в основе системы и имеют поддержку на аппарaтном уровне.

Если есть более конкретные вопросы, рад будут попытаться ответить.

Можно пару примеров из множества вещей, которые "принципиально не возможно реализовать в других системах на других платформах" ?

Посмотрите Workload Manager for z/OS. Сравните это с WLM for AIX, and Windows System Resource Manager. Это как бы аналоги, но только как бы, хотя WLM for AIX создан IBM. По последнему (Windows SRM) я создавал тему в "Вопросы ИТ" - 253 просмотра ни одного ответа, т.е. этим никто в Windows не пользуется, за ненадобностью, потому что смесь приложений на Windows настолько редкое явление и управлять ресурсами не надо. Не знаю чем богат в этом смысле Linux, полагаю не богат. Это самый очевидный пример, есть много менее очевидных, но не менее значимых. Тот же упоминавшийся выше HiperDispatch. Вообще таких примеров масса.

Посмотрите Parallel Sysplex, Inteledgent Resource Director, которые обьединяет усилия и цели WLM-ов из нескольких z/OS в Parallel Sysplex.
Есть еще интересный и полезный механизм "enclave", который тесно связан с WLM.

[zVlad]

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

Я ни разу ни энтуазист Linux на MF, но он такой же как и везде. Откомпилированный исходный код в системе команд МФ. Если Вам известно что-то другое, поделитесь.

[zVlad]

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

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

Linux на MF (по моим собственным наблюдениям) действительно "тупит". По сравнению с z/OS или zVM. Причина понятна - Linux не в курсе многого чем пользуются "родные" системы МФ, не в курсе в принципе а не потому что те кто писал компилятор для трансляции кода Linux не знали чего-нибудь о MF. Более того zVM не использует многогo что есть на МФ для z/OS. Поэтому вряд ли вообще возможно "образовать" Linux на МФ до уровня даже zVM. Да и не надо это никому.
IBM просто продает МФ для Linux (LinuxONE называется) по гораздо более низкой цене чтобы компенсировать эту "несправедливость" и удержать тех кто использует МФ с Linux.

[mskmel]

100-200 МФ в принципе не нужно ни одному бизнесу, точнее нет такого бизнеса которому бы понабилось столько МФ, нет такой нагрузки вычислительной.

Точнее не один бизнес не переводит из-за цены столько нагрузки на МФ. Есть десятки бизнесов с количеством активных серверов больше 50к, которые думаю с удовольствием бы заменили десятком МФ, но чего-то не меняют

У ИБМ по всему миру не больше 50 МФ.

В интернетах говорят о других цифрах, они больше похожи на правду. 50 - это меньше чем число гос агентств в Штатах, а уж в каждом, уверен, хоть один но затесался А еще банки и прочие ественные монополии (нефтянка, энергетика, газ, вода и т.п.).
https://www.quora.com/IBM-How-many-main ... -use-today

Более того в мире нет (ну может есть один) ни одного МФ сконфигурированного на полную мощность (141 CPU на сегодня). Трудно представить нагрузку, которую такой МФ может потянуть.

Задачи high frequency trading, telco billing, etc.

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

Вот старая презентация по одному из операторов: http://www.oracle.com/technetwork/datab ... 177532.pdf
Это 7 лет назад, как Вы понимаете данных стало не меньше.

There over 50K reports run every month on this DB
Amount Of Data
• 1.5 Billion CDR per Day
• 600 -1000 GB raw data extracted from 20+ source database
• 5 TB Data on file system processed
• Approximately 500 TB Customer data stored in multiple Databases

Еще цифры, тоже старые, но свежее, которые можно найти в публичном доступе: South Korea Telecom, 18TB данных для тарификации в день (это грубо 6млрд CDR), Raw Data 1800 TB в одной БД. У Вас, ЕМНИП, 2ТБ за 10+ лет существования приложения.

Наши 12 с 900 серверами работают в одну смену плюс on-call и их не хватает порой. Они конечно не упахиваются, так как канадцы и при том юнионайзед.

Будет 5000 - будет тоже самое "не хватает порой"

[zVlad]

100-200 МФ в принципе не нужно ни одному бизнесу, точнее нет такого бизнеса которому бы понабилось столько МФ, нет такой нагрузки вычислительной.

Точнее не один бизнес не переводит из-за цены столько нагрузки на МФ. Есть десятки бизнесов с количеством активных серверов больше 50к, которые думаю с удовольствием бы заменили десятком МФ, но чего-то не меняют

...

Я полагаю они просто настолько увлечены увеличением числа их серверов и удержанием всей этой своры в рабочем состоянии что у них нет ни времени ни ресурсов разобраться и спланировать консолидацию на небольшом количестве МФ, которaя только благодаря сокращению единиц даст огромный эффект. Ну и job security никто не отменял и действительно есть дефицит спецов на МФ.

[zVlad]

..

У ИБМ по всему миру не больше 50 МФ.

В интернетах говорят о других цифрах, они больше похожи на правду. 50 - это меньше чем число гос агентств в Штатах, а уж в каждом, уверен, хоть один но затесался А еще банки и прочие ественные монополии (нефтянка, энергетика, газ, вода и т.п.).
https://www.quora.com/IBM-How-many-main ... -use-today

...

Спасибо за ссылку, но я имел в виду те МФ что ИБМ использует для собственных нужд. Скорее всего их больше 50, но я не знаю точно.

Кстати лет десять назад ИБМ начали проект Big Green, вот статейка из тех времен:

http://www.eweek.com/networking/ibm-to- ... mainframes

[mskmel]

Кстати лет десять назад ИБМ начали проект Big Green, вот статейка из тех времен:
http://www.eweek.com/networking/ibm-to- ... mainframes

OK, пара цифр для размышлений. "3,900 Servers onto 33 Mainframes", т.е. ~100 линух серверов менялись на один мейнфрейм, чисто стойка на стойку Не ясно правда какой спецификации мейнфрейм, и физические серверы или виртуальные...

[zVlad]

Кстати лет десять назад ИБМ начали проект Big Green, вот статейка из тех времен:
http://www.eweek.com/networking/ibm-to- ... mainframes

OK, пара цифр для размышлений. "3,900 Servers onto 33 Mainframes", т.е. ~100 линух серверов менялись на один мейнфрейм, чисто стойка на стойку Не ясно правда какой спецификации мейнфрейм, и физические серверы или виртуальные...

То что нет спецификаций это конечно плохо. Там еще есть такие слова:

The consolidation project capitalizes on the ability of a single mainframe to behave as hundreds or thousands of individual servers. This reconfiguration will deploy a mainframes system resources—including processing cycles, networking, storage and memory—to many virtual servers, Anderson said.

Each virtual server functions as would a real, physical machine, Anderson said. The migration aims to use only a portion of the capacity of each mainframe, leaving room for future growth, he said.

[Kolbasoff]

Я вот что вижу: индид на ключевое слово zOS выдает 121 позицию, на AWS 26,472. Нахрена учить молодых студентов zOS? Для общего образования можно посвятить одну лекцию с картинками в цикле общеобразовательных лекций "История Компьютеров - от Бэбиджа до КьюБит". Ничего особенного с точки зрения технологий в МФ нет. Все их решения уже внедрены в серверах и облаке, а которые не внедрены нафик не сдались. МФ сдохли и туда им и дорога. Вместе с телевизорами с кинескопами, ламповыми усилителями, железными зубными пломбами, деревянными оконными рамами и т.д. Учите современным востребованным вещам, задвиньте свои комплексы неудачника подальше от молодежи, особенно российской, у них и так в провинции с доступом к технологиям не очень, а тут вы еще со своим старьем.

[ksi]

Я вот что вижу: индид на ключевое слово zOS выдает 121 позицию, на AWS 26,472. Нахрена учить молодых студентов zOS?

А сантехников нужно еще больше, вы об этом не задумывались ?

Но, например, меня корежило бы копаться в чужих унитазах. Или работать в окружении индусов, а еще хуже - под их началом. Что примерно одно и тоже, если подумать, вот такой я расист

[АццкоМото]

А у меня большие сомнения, что сантехников нужно больше, чем погромистов. Или что в Штатах есть в один момент 26,000 вакансий сантехников. Больше, чем 500 на один штат в среднем. И это сравнение только с ключевым словом AWS.

[Kolbasoff]

А сантехников нужно еще больше, вы об этом не задумывались ?

Но, например, меня корежило бы копаться в чужих унитазах. Или работать в окружении индусов, а еще хуже - под их началом. Что примерно одно и тоже, если подумать, вот такой я расист

Знания МФ в России бесполезны абсолютно, там нет работ на МФ. Работа на МФ в Америке/Канаде может и есть, но наверняка требует допуск, так что для российских студентов это тоже не вариант. Про начальников, что-то героя нашего романа не подеццки плющит от его неиндусских начальников, да так, что он месть замышляет в своих тревожных снах. Ситуация с работами для МФ такая же как и с работами в Академии - рынка труда особо нет, куда попал там и сиди, ни в вверх ни в бок не сдвинуться.

[sfbaguy1]

А у меня большие сомнения, что сантехников нужно больше, чем погромистов. Или что в Штатах есть в один момент 26,000 вакансий сантехников. Больше, чем 500 на один штат в среднем. И это сравнение только с ключевым словом AWS.

Сантехниками раньше называли специалистов по сановским серверам.
Тех самых серверов, что нанесли первый удар по могуществу мейнфреймов. А затем сами стали нишевым продуктом. Убили дракона и сами им стали

[Mark]

Сантехниками раньше называли специалистов по сановским серверам.
Тех самых серверов, что нанесли первый удар по могуществу мейнфреймов. А затем сами стали нишевым продуктом. Убили дракона и сами им стали

Ну Oracle периодически пытается "откопать стюардессу" - но результат каждый раз не очень впечатляет. Очередной mini-cluster on Sparc опять не пошел...

[zVlad]

....
Сантехниками раньше называли специалистов по сановским серверам.
Тех самых серверов, что нанесли первый удар по могуществу мейнфреймов. А затем сами стали нишевым продуктом. Убили дракона и сами им стали

На нашей фирме идет вытеснение Unix-based серверов Wintel-ом. На лицо тенденция вытесния одного другим. Т.е. и Wintel должен будет быть вытеснен. Уместен вопрос что будет вытеснять х86 сервера?

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

Кто хочет может попытаться обосновать что системы на х86 это предел эволюции ИТ.