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

[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 сайт из воздуха? Поделитесь, очень интересно. Вы не заметили что этот второй МФ у нас несет свою продакшн систему?

[Abappy]

Я имею в виду не распределенные системы, не блэйды, а централизованные системы.

zVlad - так я в этой теме уже давно интересуюсь - СКОЛЬКО памяти можно поставить в "централизованный" МФ .. максимум "в одну штуку" ?

[StrangerR]

К сожалению это не бред.

Нет, мне самому многое у IBM нравится, и я не сторонник смены лошадей на переправе. Если уже сделаны вложения, задачи хорошо определяемы и предсказуемы, то оно отличное решение. Тем более что они там предлагают и виртуализацию и _чего только там нет_. Но нужно понимать что выхлоп на $1 будет много ниже чем на дешевых классических серверах (2 CPU, 16 - 256 GB memory, внешний FC или iSCSI/10GB диски) исключая случай когда вы почти ВСЕ сумеете на этот MF засунуть.

Поэтому и уходят они со сцены. При всех своих плюсах. Ненадежно (надежность MF все таки не очень из за огромной сложности) и ОЧЕНЬ просто ОЧЕНЬ дорого. Причем дорого СРАЗУ. А компании сейчас деньги экономят, да и вообще норовят прикладухи засунуть в приватные облака (не у себя на кампусе вообще) и изничтожить как можно больше IT расходов. А это абсолютно ортогонально идее MF.

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

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

А вы посмотрите параметры скажем Oracle DB machine v1 - для Warehouse задач. Аналогов по производительности попросту не существует. И вот скажем окажется у вас что приложение требует именно такого решения (а это -
- умные стойки памяти Exadata которые делают сами нижнюю часть работы с базой данных /поиск по таблице или индексу/
- кластер (RAC) соединенный через Infiniband (2 x 40 Gbit)
- узлы самой базы (RAC) сделанные на основе опять таки стандартных 2 процессорных серверов.

ВСе в совокупности имеет вообще фантастические параметры по скорости (хотя и не дешево) если задача подходит. Для OLTP была сделана Oracle DB машина v2 но тут я не знаю насколько они ее разогнали - массового использования еще не было. Суть же в том, что зачастую может оказатсья что вам нужно ДРУГОЕ железо - а вы уже все деньги потратили, и ага...

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

[zVlad]

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

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

Моя оценка строится на том что ядро нашего приложения (база данных ~ 1TB и аппликейшн сервер) располагаются на 12 GB в настоящее время. То что сейчас располагается на 8-ми серверах (с немалыми GB каждый) - это интерфэй к ядру. Интерфэйс не может требовать больше ресурсов чем ядро системы, просто потому что что совершенно разные объемы обрабатываемых данных. Вот и получается 4-8 GB. 4 GB нераспределенной памяти у нас на МФ уже есть. Еще нужен, по моим оценкам один zIIP.

С Вами хорошо мечтать, наверное. Реальность наша иная, и дата центр наш 90% состоит имеенно из не-МФ серверов, в то время как на МФ находится ядро ИТ клиента от которого питаются данными многие приложения на тех серверах.

[zVlad]

Я имею в виду не распределенные системы, не блэйды, а централизованные системы.

zVlad - так я в этой теме уже давно интересуюсь - СКОЛЬКО памяти можно поставить в "централизованный" МФ .. максимум "в одну штуку" ?

Не понимаю зачем Вам это. Я точной цифры не помню, но полагаю что реально бокса с таким количеством памяти никто не заказывал у ИБМ.
Впрочем сходил на сайт ИБМ. Это 3056 GB в одном боксе.

[Abappy]

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

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

[Zombie416]

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

Ну дык и на двух Intel серверах вы бы сделали ровно тоже самое.

Вопрос в другом: чем принципиально отличается МФ от мощного x86 сервера сегодня. 5-10 лет назад отличался, даже в элементарных вопросах аппаратной надежности. Но вот именно сегодня? Кроме цены, сомнительной производительности МФ (в которой IBM-у очевидно похвастаться нечем, иначе бы непременно похвастались и бенчмарки бы на каждом столбе висели), особенностей лицензирования и совместимости с legacy софтом? Подключать-отключать процессоры, память и I/O, как и переживать аппаратные проблемы x86 уже научился, причем все это поддерживается вполне обычными и распространенными ОС.

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

[Abappy]

Не понимаю зачем Вам это. Я точной цифры не помню, но полагаю что реально бокса с таким количеством памяти никто не заказывал у ИБМ.
Впрочем сходил на сайт ИБМ. Это 3056 GB в одном боксе.

Спасибо. Некоторое время на этом прожить можно ... так-что не всё потеряно. А мне было интересно именно из-за того, что warehous-ы о которых так много говорилось выше - переезжают в память

[flip_flop]

Ну надо же - сегодняшние достижения (все от той же замечательной фирмы) в виде 2 ТБ на условную плату (сдвоенный модуль) с двумя процессорами (инфо на первой странице) уже мало. Надо четыре .

Кстати, иерархических уровней памяти гораздо больше, если рассматривать уровни кэша. Ну да ладно, детали.

zVlad - вы путаете процессорные модули [CPU] с процессорами как таковыми. В модулях сидит шесть z196 процессоров, два вынесенных кэша на eDRAM, все это соединено внутренним интерконнектом, сидит на офигенной керамике вместо дешевого пластика, как в ширтпотребе, ну и так далее. Очень неплохо с инженерной точки зрения, кстати, но очень дорого. И, кстати, этот модуль должен по законам физики потреблять какую - никакую энергию. Так же как и память. А мы присутствовали при рождении еще одного мифа о МФ (кстати, каламбур, МФ как миф ) - добавляем в МФ еще один супер модуль (вместе с памятью) и энергопотребление системы (по zVlad-у} остается ровно то же как и до модернизации, из чего следует что в МФ новые модули энергию не потребляут Понятно, запал полемики, но все-таки - миф

[StrangerR]

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

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

О да! Особенно если учесть криворукость их писателей, и то что писателя не достанешь - приходится мирится с тем что есть. С вашей базой я бы сразу предлоложил что нужно 4 аппликейшен сервера и на каждом гигов по 32 памяти... у вас там такие ресурсы на MF есть или как? И сколько будет это стоит если докупать (если я докуплю такое в свои сервера - думетя что уложусь в пару тысяч на все про все... а сколько стоит 1 диммка памяти для вашего монстра?)

[crypto5]

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

Что касаемо скалабилити, то нет платформы сопоставимой по этому параметру с МФ. Я имею в виду не распределенные системы, не блэйды, а централизованные системы.

И тут мы возвращаемся к тестам tpc, в которых МФ почему то стесняются учавствовать