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

[zVlad]

Как же помню этот пример. А Вы можете назвать платформы и системе которые могут выстоять сбой "выгорание" процессора и замену выгоревшего резервным без остановки процесса в целом

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

Технические устройства всегда будут выходить из строя, сколько бы Вы усилий в их надежность не вкладывали бы.

[zVlad]

Или иначе, назовите систему в которой можно онлайн изменять количество процессоров, их производительность, размер памяти, количество физических партиций. Сможете найти такую не МФ систему приведите уж и цену.

В Итаниум это было давно, нынче можно и в х86. Нехалем ЕХ вполне поддерживает Хот-сшап/Хот-адд ЦПУ и памяти, имеет Мачине Чецк Арчитецтуре (МЦА), и все это поддерживается даже Шиндошс-ом ( Датацентер Едитион - хттп://шшш.мицрософт.цом/шиндошссервер2008/ен/ус/2008-дц.аспх ). 4х процессорные сервера начинаются где-то с 20к (прям на Делл.цом), ОС еще тысяч 10.

То что Вы привели не более чем рекламный флайер. Я нашел, если Вы не возражаете. вот это:

http://www.itaniumsolutions.org/resourc ... soft_intel

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

For workload-based or fault-based repartitioning, a policy threshold is hit which causes the automatic repartitioning to be initiated. In the example above, this might occur if the processors on the business critical server have hit 90% utilization or if one of the cells in the business critical server were to hit a threshold of either memory or processor errors (reported to the service processor through the Itanium MCA - Machine Check Architecture). These would cause the GlobalMaster to notify Windows Server 2008 that a hot add (workload) or hot replace (fault) needs to occur. In the case of a hot replace, the service processor would replace the failing cell with a cell from a less critical server, for example, the development server. Windows Server's Dynamic Hardware Partitioning would then "move" the critical applications environment over to the "new" cell, with no disruption to the running applications. (The development server, since it is losing resources, would need to be restarted on its reduced resources.)

Time-based repartitioning, while not quite as dynamic, offers additional flexibility. It is often used when processing workloads change, for example, daytime versus nighttime processing, or regular daily operation versus month-end. In time-based processing, generally all servers are shut down, the cells are reconfigured, and the systems are restarted.

На МФ процессора могут совместно использоваться всеми партициями. Кратность - один процессор. Память "пилится" независимо от процессоров, т.к. вся она одинакова доступна любому процессору. А при выходе процессора из строя замена не крадется у менее приоритетной партиции, а из пула резервных процессоров.

[zVlad]

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

коротка же у вас память ...
хттп://шшш.данскебанк.цом/ен-ук/пресс/Н ... 0403а.аспх

Почему же я прекрасно помню этот случай. Мне только не понятно что Вы хотите сказать напоминая о нем в данном контексте.

[Zombie416]

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

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

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

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

[zVlad]

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

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

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

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

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

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

3. Совершенно верно. Но вот нам на время понадобился дополнительный CPU (zIIP). Без добавления физических элементов и без прерывания работы каких-либо систем на этом МФ нам такая возможность была предоставленна, и буквально вчера истек срок и этот дополнительный CPU был деактивирован опять же без прерывания работы систем на МФ. Мы за это ни копейки не платили.

[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 и нигде более.

[zVlad]

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

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

....

Я не знаю, я с этим не работаю. Поначалу севреров было меньше и пару раз из-за этой компаненты вся система была недоступно. Поэтому, возможно, пришли к такой структуре. Скорее всего нагрузки на эти 8 серверов особой нет. Это Java интерфейс (GUI можно сказать) к приложению (база данных и сервер транзакций) на одном МФ, о котором я уже не раз говорил здесь.

[StrangerR]

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

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

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

Ничего подобного. Как раз это из 2009 года. Не нужны такие бегемоты сегодня. Оракл кстати прекрасно показал и то что SAS диски быстро в прошлое уходят.

(Хотя сдуру то все можно, да и СУБД есть _база в памяти_. Но зачем бы все это? Ну да и ради бога - в современные обычные серверы ставится немерянно памяти, без всяких там мейнфреймов, если уж вам очень хочется.)

[Abappy]

Ничего подобного. Как раз это из 2009 года. Не нужны такие бегемоты сегодня. Оракл кстати прекрасно показал и то что SAS диски быстро в прошлое уходят.

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

(Хотя сдуру то все можно, да и СУБД есть _база в памяти_. Но зачем бы все это?

Как зачем .. чтоб работало быстро

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

так и я о том, что _без_ мейнфреймов это можно .. а вот можно ли с мейнфреймами ?

[zVlad]

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

Я ждал этого бреда. Спасибо.
Конечно МФ не стоит покупать чтобы крутить бухгалтерию фирмы из десяти человек, может и для ста МФ не нужен. Но есть и более крупные кампании, ИТ которых на Интелах стоят многие миллионы. И вот в этом секторе МФ становится очень даже конкурентен. Что касаемо скалабилити, то нет платформы сопоставимой по этому параметру с МФ. Я имею в виду не распределенные системы, не блэйды, а централизованные системы.

А что это за бред: "скажем задача не потянула на вашей СУБД и вам приходится покупать Oracle DB machine v2"? Что Вы этим хотели сказать?

[zVlad]

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

А Вы знаете как можно создать DR сайт из воздуха? Поделитесь, очень интересно. Вы не заметили что этот второй МФ у нас несет свою продакшн систему?