Демократизация мейнфреймов

[StrangerR]

Только вот такое же по мощности сооружение просто на одном делловском блайд сервере стоило бы в 10 раз меньше, и чем активировать - деактивировать, просто изначально было бы втрое больше мощности. А при нужде было бы куплено еще несколько блейдов, вставлено (навсегда) и снова проблема забыта.

Тем более все это по жизни будет виртуальным, как правило, а там в облаке есть и свои балансеры и свои репликаторы, и куда дешевле чем MF. А главное, тут я просто поменяю блейды через пару лет или поставлю еще одну такую же коробку, а ваш MF по мощности сравняется с ноутбуком моей жены за это же время... только дико дорогим и большим...

А потом с вашим МФ вылезут еще одни грабли. Вот нам понадобилось вдруг разработать кусок софта. Офис у нас есть в Риге. Берем туда экспортируем десяток VM, там создаем енвайренмент, они разрабатывают, при нужде покупают там две - три говнодавки для ускорения (серверов как грязи), присылают нам. Мы ставим. А если бы был мейнфрейм - мне бы его пришлось реплицировать с помошью нулль транспортировки, потому как нужен в дата центре потом нужен в стейджинге потом нужен у разработчиков... А через три года что со всем этим железом делать, вообще неясно.

Поэтому - в баню. На джанк ярд. И делается все на дешевых массовых серверах - до 2 процессоров (в продакшене можно до 4), 32 гига памяти (в продакшене можно 128), iSCSI SAN (в продакшене если очень будет нужно будет FC но по жизни не нужно оказалось), и есть копия в стейджинге (а заодно она же и DR) и у девелоперов (столько сколько нужно). И через 5 лет все это легко апгрейдится, и денег на саппорт каждый год не просит (не считая SAN системы в продакшене). И ничуть не менее надежно чем оный MF.

А, не заметил, DR значит.... а у вас MF уже и в DR узле стоит? И уже все реплицирует сам по себе?? Или все таки для DR надо еще один такой же бегемотик добавить, за немерянно $$$? Потому как при начальной закупке выбить бюджет на DR вообще из области фантастики, он обычно потом появляется. И что вы будете делать когда этот MF устареет?

[crypto5]

Из этого следует что эта тема на Интел платформе нова и далека от совершенства достигнутого на МФ. Умиление вызывает деление сервера на ячейки кратные четырем процессорам с ихней памятью, и изменение конфигурации соответственно единицами в четыре процессора и видимо их памяти:
...
А при выходе процессора из строя замена не крадется у менее приоритетной партиции, а из пула резервных процессоров.

1. Сколько чего там в ячейке, 4 процессора, 1 процессор, 1 ядро процессора - в отрыве от цены врядли имеет значение. И есть подозрение что на интеле 4 процессора, со всей ихней памятью, будут все равно в разы дешевле чем один МФ процессор.

2. Ну а то что в 99.99(9)% случаев когда все процессоры исправны их все можно и задействовать ( вместо того чтобы часть из купить, зарезервировать и надеяться что когда надо будет они включатся ) - это скорее достоинство, а не недостаток, не так ли? Если уж говорить о совершенстве.

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

1. Без сомнения будет дешевле. Но вот передо мной реальная альтернатива стоит. C одной стороны мы имеем восемь продакшн Интел серверов балансируемых двумя CICSO балансерами, плюс джентельменский набор из девелопмент, QA, трэйниг, etc... да конечно DR solution. А с другой стороны это все может лечь на МФ которому надо добавить один-два zIIP, и гегтара 4-8 мэмори.

А куда в случае МФ девелопмент, qa, training волшебным образом исчезают? И почему в случае МФ не нужен DR?

[StrangerR]

А в случае MF никому не светит еще один MF и потому он становится и жнец и на трубе дудец... все в него суется пока CTO не поймет что чем совать все в раздувшийся как удав MF проще купить три DELL R710, к ним Vmware essential за 495, разработать и отладить приложение, потом в продакшен поставить еще три - пять таких же DELL и забыть об этом кошмаре по имени MF навсегда. А у девелоперов и так говна на котором разрабатывать можно хватит, им даже и покупать ничего не придется...

[Zombie416]

C одной стороны мы имеем восемь продакшн Интел серверов балансируемых двумя CICSO балансерами, плюс джентельменский набор из девелопмент, QA, трэйниг, etc... да конечно DR solution. А с другой стороны это все может лечь на МФ которому надо добавить один-два zIIP, и гегтара 4-8 мэмори. Что по Вашему будет дороже? Сравните лишь людские ресурсы, площадь и электроэнергию, прирост которых в случае МФ будет равен нулю и Вы все поймете сами.

Ну какой вопрос, такой ответ. Если для всего того что делают аж 8 production серверов потребуется максимум 4-8GB RAM (в отличие от виртуальных гигагерцев байты - величина одинаковая что у Intel-а, что у МФ), то можно спросить какого года выпуска эти сервера? Можно предположить что дешевле будет купить 4х ядерный лаптоп с RAID SSD, поставить на него Hyper-V или VMWare, засунуть в сейф и на этом и закончить. Cвободные ресурсы лаптопа отдать SETI@NET, а на освободившемся месте открыть Starbucks.

Ну а что резервные CPU "не покупаются", и что производительность от количества CPU не зависит, как и измерение производительности в MIPS-ах, и прочие чудеса обсуждавшиеся в предущих темах, это все понятно. Все это слова и рекламные буклеты, цифр позволяющих сравнить апельсины ну хотя бы с яблоками, нет и близко.

Но речь все же была о том что времена меняются. И если, скажем, лет 5 назад можно было уверенно сказать: детский сад этот ваш x86, насуете вы в него памяти, загнется один DIMM там, и все, плакали все ваши процессы и машины виртуальные; хотите надежности - платите на несколько порядков больше, покупайте МФ, или Itanium хотя бы. Но сегодня уже иначе, разница перестала быть есть-нету, а стала лучше-хуже, и это при эээ... существенной разнице в цене.

Притом что от коллизий вроде фукусимы все равно спасенья нет: даже МФ при отсутствии электроэнергии работает недолго. Пусть и в 100500 раз, на целых 32 микросекунды дольше чем x86, но все равно недолго

[Abappy]

Но речь все же была о том что времена меняются.

я этих слов ждал .
Естественно никто не совершенен, и я тоже могу ошибаться. Но если я не сильно ошибаюсь, то к 2014-15 будет "принято" иметь несколько терабайт оперативной памяти _на_базу_данных_ (то-бишь если надо дублировать - умножаем на два, для девелопмента ещё .. для QA - копия и т.д. ). В x86 архитектуре думаю IBM это сделает ( наряду с HP и т.п. ) .. и будут сервера с 4 и больше терабайтами оперативки на плату ... а вот как с этим будет дело обстоять в МФ ?

[zVlad]

C одной стороны мы имеем восемь продакшн Интел серверов балансируемых двумя CICSO балансерами, плюс джентельменский набор из девелопмент, QA, трэйниг, etc... да конечно DR solution. А с другой стороны это все может лечь на МФ которому надо добавить один-два zIIP, и гегтара 4-8 мэмори. Что по Вашему будет дороже? Сравните лишь людские ресурсы, площадь и электроэнергию, прирост которых в случае МФ будет равен нулю и Вы все поймете сами.

Ну какой вопрос, такой ответ. Если для всего того что делают аж 8 production серверов потребуется максимум 4-8GB RAM (в отличие от виртуальных гигагерцев байты - величина одинаковая что у Intel-а, что у МФ), то можно спросить какого года выпуска эти сервера? Можно предположить что дешевле будет купить 4х ядерный лаптоп с RAID SSD, поставить на него Hyper-V или VMWare, засунуть в сейф и на этом и закончить. Cвободные ресурсы лаптопа отдать SETI@NET, а на освободившемся месте открыть Starbucks.

Ну а что резервные CPU "не покупаются", и что производительность от количества CPU не зависит, как и измерение производительности в MIPS-ах, и прочие чудеса обсуждавшиеся в предущих темах, это все понятно. Все это слова и рекламные буклеты, цифр позволяющих сравнить апельсины ну хотя бы с яблоками, нет и близко.

Но речь все же была о том что времена меняются. И если, скажем, лет 5 назад можно было уверенно сказать: детский сад этот ваш x86, насуете вы в него памяти, загнется один DIMM там, и все, плакали все ваши процессы и машины виртуальные; хотите надежности - платите на несколько порядков больше, покупайте МФ, или Itanium хотя бы. Но сегодня уже иначе, разница перестала быть есть-нету, а стала лучше-хуже, и это при эээ... существенной разнице в цене.

Притом что от коллизий вроде фукусимы все равно спасенья нет: даже МФ при отсутствии электроэнергии работает недолго. Пусть и в 100500 раз, на целых 32 микросекунды дольше чем x86, но все равно недолго

Вот у формумчал все как-то здорово на словах получается. Сервера дешевые и нужно их один-два чтобы заменить МФ. А вот на практике почему то совсем не так дела обстоят. Те восемь серверов достаточно свежие. Почему их восемь, я не знаю. Когда принималось решение ставить это на сервера, а не на мэйнфрэйм оценки конечно были гораздо более скромные, но в итоге все пришло к тому что есть.
Что касательно памяти, то на МФ ее нужно меньше просто потому что веб сервер будет один, а не восемь как в случае Интел серверов и следовательно эти дополнительные 4-8 гектаров - это память для пользователей главным образом.
Производительность может быть одинаковой при разном количестве CPU потому что у CPU МФ есть так называемые subcapacity level. На одном из наших МФ пять CPU, а MIPS около 1000, на другом три CPU а MIPS меньше сто, в то же время в случае DR мы с первого МФ уходим на второй "разгоняя" его за несколько секунд до более чем 1500 MIPS. Хотите верти хотите проверьте. Речь идет о моделях z10-E10 Q05 и z10-E10 A03, которая в случае DR становиться Z03. Поищите на Google по этим ключевым словам и Вы сами увидите что это так. Софтвэр лисенз зависит от MIPS, но не от количества CPU.
Касаемо Ваших абстрактных рассуждений о ценах я еще раз повторю поинт. Сравните вариант когда предлагается оттяпать кусок системы с МФ и бросить его на не-МФ, создавая при этом всю необходимую в реальной жизни инфраструктуру - Dev, QA, Training и DR, а также порой разные Baseline, Sandbox-ы с тем что это все остается на слегка умощненном МФ, занимающим ту же площадь, потребляющим тут же электроэнергию с тем же персоналом. Что будет дешевле.

[zVlad]

....
1. Без сомнения будет дешевле. Но вот передо мной реальная альтернатива стоит. C одной стороны мы имеем восемь продакшн Интел серверов балансируемых двумя CICSO балансерами, плюс джентельменский набор из девелопмент, QA, трэйниг, etc... да конечно DR solution. А с другой стороны это все может лечь на МФ которому надо добавить один-два zIIP, и гегтара 4-8 мэмори.

А куда в случае МФ девелопмент, qa, training волшебным образом исчезают? И почему в случае МФ не нужен DR?

У нас dev, qa, baseline, sandbox и training все находятся в одном имэдже системы в одном LPAR на том же МФ что и продакшн. Это физически один бокс и две системы на нем (можно и третью запусть и четвертую - ресурсы позволяют, позволяют еще и потому что партиции на МФ обычно делять одни и те же CPU. На нашем пяти процессорном МФ оба LPAR используют все пять CPU).
DR solution предусмотрен на второй МФ где тоже крутятся продакшн и девелопмент другого приложения, который много менее мощный, нов случае DR будет сделать даже мощнее чем первый МФ. Я об этом писал выше. Диски с одного сайта на другой зеркалируются, и в случае DR нужно лишь загрузить ситему на DR МФ с зеркалированных дисков. Каждый год по осени проходит транировка и тест DR, каждый год успешно.

[zVlad]

Только вот такое же по мощности сооружение просто на одном делловском блайд сервере стоило бы в 10 раз меньше, и чем активировать - деактивировать, просто изначально было бы втрое больше мощности. А при нужде было бы куплено еще несколько блейдов, вставлено (навсегда) и снова проблема забыта.

...

Точно также, по-видимому, рассуждал один из наших клиентов, ушедший с МФ на AIX сервера почти три года назад. Стоимость этого "ухода" оценивается в $50 000 000. Люди которые саппортали приложение этого клиента на МФ, саппортают его и на AIX и постоянно стонут и плачут: до того им процессы на AIX кажутся неудобными, трудоемкими и ненадежными по сравнению с МФ-скими. Это то что они мне говорят, это не я придумал - я вооще к AIX не имею в данном случае никакого отношения.
Увы, за три года ни одна проблема не ушла, а вновь и вновь воспроизводится. До перехода этот клиент года три ни цента в МФ не вкладывал (переходил так сказать), но все работало стабильно на минимальных вложениях в саппорт.
Так что как говорится свежо питание, да сериться с трудом.

[Zombie416]

Что касательно памяти, то на МФ ее нужно меньше просто потому что веб сервер будет один, а не восемь как в случае Интел серверов и следовательно эти дополнительные 4-8 гектаров - это память для пользователей главным образом.

Не понимаю, ни "просто потому", ни "следовательно". Еще раз, что мешает взять все эти сервера и засунуть в один физический, причем весьма недорогой, сервер. И таки сделать один веб сервер, а не 8. Нагрузки, судя по тому что вы пишете, особой нет.

Производительность может быть одинаковой при разном количестве CPU потому что у CPU МФ есть так называемые subcapacity level. На одном из наших МФ пять CPU, а MIPS около 1000, на другом три CPU а MIPS меньше сто, в то же время в случае DR мы с первого МФ уходим на второй "разгоняя" его за несколько секунд до более чем 1500 MIPS. Хотите верти хотите проверьте. Речь идет о моделях z10-E10 Q05 и z10-E10 A03, которая в случае DR становиться Z03. Поищите на Google по этим ключевым словам и Вы сами увидите что это так. Софтвэр лисенз зависит от MIPS, но не от количества CPU.

Это все не технические вещи, а попугаи от IBM sales. Их сравнивать можно с самими собой только. Licensing от чего угодно может зависеть, от количества пользователей до ядер в процессорах, но на производительность самих процессоров он не влияет.

И оказывается для DR на MФ надо всего-то иметь второй МФ.

Сравните вариант когда предлагается оттяпать кусок системы с МФ и бросить его на не-МФ, создавая при этом всю необходимую в реальной жизни инфраструктуру - Dev, QA, Training и DR, а также порой разные Baseline, Sandbox-ы с тем что это все остается на слегка умощненном МФ, занимающим ту же площадь, потребляющим тут же электроэнергию с тем же персоналом. Что будет дешевле.

Ну дык в один голос же и пишут: без конкретики, rule of thumb, дешевле будет эти 8 серверов засунуть в 1 физический ящик. Причем, если ваша оценка верна и для всего этого требуется 4-8GB RAM, то с точки зрения производительности хватит и современного workstation-лаптопа. В качестве DR - второй лаптоп. Скорость процессора в MIPS-ах, и частота в мегагерцах, будет динамически варьироваться тоже, в широких пределах (на порядок). Причем почти бесплатно, только пару дополнительных центов в день на электроэнергию придется платить при полной загрузке.

Насчет персонала это как повезет, а площади и электроэнергии вся эта "могучая система" будет потреблять меньше чем один процессорный модуль от МФ. В разы меньше.

[zVlad]

....
А потом с вашим МФ вылезут еще одни грабли. Вот нам понадобилось вдруг разработать кусок софта. Офис у нас есть в Риге. Берем туда экспортируем десяток VM, там создаем енвайренмент, они разрабатывают, при нужде покупают там две - три говнодавки для ускорения (серверов как грязи), присылают нам. Мы ставим. А если бы был мейнфрейм - мне бы его пришлось реплицировать с помошью нулль транспортировки, потому как нужен в дата центре потом нужен в стейджинге потом нужен у разработчиков... А через три года что со всем этим железом делать, вообще неясно.
...

У Вас очень бедное воображение, ограниченное теми железками и их возможностями, с которыми Вам нравиться работать просто по причине не знания альтернатив. Это лирика так сказать.
А реальность такова что можно хоть в Челябинске создать группу разработчиков и предоставить им доступ в систему на МФ в Торонто с таким же точно качеством как если бы они работали в Торонто.
Но Ваше воображение порождает только совершенно не нужную "репликацию с помощью нуль транспортировки" (что это за зверь?), совершенно не нужные грабли, точнее вилы, которыми Вы сами себя пугаете. Но это не более чем Ваш личный выбор, к реальной ситуации с МФ не имеющий никакого отношения, т.е. высосаный из пальца.

[StrangerR]

Но речь все же была о том что времена меняются.

я этих слов ждал .
Естественно никто не совершенен, и я тоже могу ошибаться. Но если я не сильно ошибаюсь, то к 2014-15 будет "принято" иметь несколько терабайт оперативной памяти _на_базу_данных_ (то-бишь если надо дублировать - умножаем на два, для девелопмента ещё .. для QA - копия и т.д. ). В x86 архитектуре думаю IBM это сделает ( наряду с HP и т.п. ) .. и будут сервера с 4 и больше терабайтами оперативки на плату ... а вот как с этим будет дело обстоять в МФ ?

Зачем вам (и нам) терабайты памяти на базу данных? Чем их забивать то? Флеши становятся быстрее, появляется вторичная память на флеше, и на хрена столько оперативки? База на SATA, кэш на флеше, гигов 64 - 128 оперативки - и практически любые запросы удовлетворены... А терабайты памяти - во первых, в них СУБД будет сама неделю данные искать, во вторых, их еще неделю будет с дисков считывать.. увеличение буферов вовсе не всегда ускоряет базу, бывает и наоборот... Пока тенденция идет на переход к 3 уровням - оперативка, флеш, диски (SATA). И при этом терабайты памяти на систему нафиг не требуются никому.

[StrangerR]

....
А потом с вашим МФ вылезут еще одни грабли. Вот нам понадобилось вдруг разработать кусок софта. Офис у нас есть в Риге. Берем туда экспортируем десяток VM, там создаем енвайренмент, они разрабатывают, при нужде покупают там две - три говнодавки для ускорения (серверов как грязи), присылают нам. Мы ставим. А если бы был мейнфрейм - мне бы его пришлось реплицировать с помошью нулль транспортировки, потому как нужен в дата центре потом нужен в стейджинге потом нужен у разработчиков... А через три года что со всем этим железом делать, вообще неясно.
...

У Вас очень бедное воображение, ограниченное теми железками и их возможностями, с которыми Вам нравиться работать просто по причине не знания альтернатив. Это лирика так сказать.
А реальность такова что можно хоть в Челябинске создать группу разработчиков и предоставить им доступ в систему на МФ в Торонто с таким же точно качеством как если бы они работали в Торонто.
Но Ваше воображение порождает только совершенно не нужную "репликацию с помощью нуль транспортировки" (что это за зверь?), совершенно не нужные грабли, точнее вилы, которыми Вы сами себя пугаете. Но это не более чем Ваш личный выбор, к реальной ситуации с МФ не имеющий никакого отношения, т.е. высосаный из пальца.

Я знаю что МОЖНО. Я знаю что ИБМ рентует вам мощности под девелоперов. Но я также видел во что все это выливается - это реально, по жизни, сыр в мышеловке который бесплатным не бывает. И в конечном итоге кончается все сносом оных мэйнфреймов в джанк ярд. И кстати, а оптику из Челябинска до Торонто вы уже проложили, и с 150 - 200 мсек задержками на RTT разобрались - уже поставили TCP ускорители и прочие недешевые железяки чтобы удаленно работать? (У нас кстати есть проекты по обслуживанию мейнфреймов в США из России, так что я представляю всю гемморность оной задачи удаленного доступа. Не говоря уж о прочих проблемах, иногда в том числе и юридических).

(И видел я все это. И с Тандемом сталкивался. И с кучей мейнфреймов. И по выставке ходил вокруг нынешних ИБМ овсских творений. Да, красиво. Но как деньги посчитаешь - понимаешь что нахрен не нужно...)

[zVlad]

....
А, не заметил, DR значит.... а у вас MF уже и в DR узле стоит? И уже все реплицирует сам по себе?? Или все таки для DR надо еще один такой же бегемотик добавить, за немерянно $$$? Потому как при начальной закупке выбить бюджет на DR вообще из области фантастики, он обычно потом появляется. И что вы будете делать когда этот MF устареет?

Про DR я уже объяснил выше. DR сайт есть, но в тоже время его как бы и нет, на DR МФ продакшн система и соответствующий dev.... выполняется (для которого в свою очередь первый МФ является DR сайтом). Диски взаимно зеркалируются. Оба МФ имеют в нормальном режиме ровно столько MIPS сколько нужно без учета DR. $$$$ минимально возможные тратятся, в основном на диски.

[Abappy]

Пока тенденция идет на переход к 3 уровням - оперативка, флеш, диски (SATA). И при этом терабайты памяти на систему нафиг не требуются никому.

Это Вы ещё в 2009 году живёте, а на дворе уже 2011

http://www.v3.co.uk/print_article/v3-uk ... -analytics

[StrangerR]

А главное - проблема MF - нужны очень большие начальные вложения. После чего ВОЗМОЖНО удастся обойтись без оных. Но возможно и не удастся - скажем задача не потянула на вашей СУБД и вам приходится покупать Oracle DB machine v2 (которая делает большинство современых мейнфреймов с базой как бык овцу) - а у вас УЖЕ деньги потрачены. Или вам нужна другая ОС - скажем у вас вдруг куча прикладух приехала для Windows 2005, или для MS SQL или для MySQL. В случае использования обычных серверов - легко можно, особенно с учетом Vmware ESX/ESXi, все раскидать как вам нужно, или докупить то что нужно. А в случае MF - все, приехали, деньги уже огромные потрачены и если вдруг нужно еще небольшой центр поставить в третьем месте - вы в ловушке. При сегодняшней динамике изменений - это полная безнадега, угадать так чтобы отбить деньги потраченные на MF. Потому и говорим что им место на Junk Yard и нигде более.