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

[flip_flop]

.... догоняет (или догнал ?) процессоры верхнего сегмента серверов и процессоры мейнфреймов для задач датацентров. ...

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

Ха, так я же приводил мой восторг по этому поводу -пролистайте назад пару страниц. Каждый год общаюсь с коллегами на конференциях. Но как я уже писал выше - ЦПУ модуль - не один процессор, а очень дорогая "склейка" из 6 процессоров з196 и 2-х вынесенных чипов еДРАМ кэшей четвертого уровня, сидящих на очень технологичной и дорогой керамике. Да, впечатляет. Но очень дорого и этому модулю соответствует не один зион а скорее плата из 6 зионов с памятью. Сам по себе з196 процессор тоже вполне хорош и сидящий уже на чипе еДРАМ как кеш третьего уровня тоже вполне ничего себе. Этот чип очень долго и очень дорого проектировался, о цене его я не знаю . Но и нынешние зионы вполне ничего как ширпотреб и для [HPC] и для датацентров. И именно на них а не на МФ (и только для МФ ) процессоре поставлены рекорды по ЦПУ производительности (наравне с подобными но тоже очень дорогими процессорами серверов верхнего сегмента), хотя именно для МФ и с учетом уровней кэша и полосы пропускания з196, вернее модуль на его основе, очень хорош, но очень очень дорог. Да, по отдельным технологическим параметрам тоже на з196 облизываюсь

П.С. и давайте оставим в покое Итаниум, мы здесь о демократических альтернативах.

П.П.С. А насчет ЦПУ производительности все очень просто - идете на [spec.org] и смотрите [cpu2006 results] всех времен и народов. CINT - десятки первых мест зионы, CFP- то же самое, по [throughput/CPU rates] - первые четыре места на системах с [IBM Power], четвертое место - зион (а недавно и рядом не стояло). Систем с новыми зионами еще в списках нет, по ссылке на первой странице они уходят в отрыв и ставят новые рекорды. з196 там нет. Примерно та же история для [tpc-c]. Ну да, неправильные тестбенчи, согласен.
Да, по тактовой частоте з196 лидирует - выше 5 ГГц. Отдельные зионы идут с > 4 ГГц. Но по производительности важна не столько частота сколько архитектура, поэтому надо смотреть на суммарную производительность по тестам. Потом - использование параллельных ядер и потоков с поддержкой ширпотребовских компилляторов - [x86_64] здесь лидируют по числу ядер и по числу потоков по сравнению с з196. Вкратце - оба чипа хороши, нет между ними бездны. Но один закрыт, узкоспециализированный и дорогой (нет - ужасно дорогой), второй поддерживает открытые стандарты, широкого потребления и дешевый.

[StrangerR]

Не надо о покойниках. Разве что почтить его минутой молчания - хороший был парень...

П.С. и давайте оставим в покое Итаниум, мы здесь о демократических альтернативах.
.

[StrangerR]

,....
1. Понимаете, Влад, я прекрасно вижу о чем вы. И во многом вы правы - если нужно вытянуть супер-пупер скорость из отдельной одинокой железки и неважно по какой цене - то мейнфрейм великая вещь. Я очень на многое там облизываюсь.
.....
2. Еще проблема всех МФ - мне нужно обычно плодить сситемы - продакшен, стейджинг, QA, девеломпент там, девеломпент в Китае. Плодить МФ никакиих денег не хватит, пускать всех на один МФ - секьюрити с ума сойдут.

1. Прокомментируйте назначение вот этого $30 000 000-ного чуда:

http://tpc.org/results/individual_resul ... 120210.pdf

2. И ответьте, пожалуйста, Вы когда обращаетесь к zVlad-у Вы кого имеете в виду? Я спрашиваю потому что я уже тысячу раз писал, в том числе дискутируя с Вами лично, что на одном МФ может находится весь перечень систем, на одном МФ, их не надо столько сколько Вам нужно логических систем. Так обстоят дела там где я работаю. Я не надеюсь что Вы и сейчас это поймете.

Я понимаю что вы заменяете мою стойку с интеллами и с двумя сотнями виртуалок на ней одной стойкой с мейнфреймом. Проблема в том что я не могу смешивать на одной железке некоторые вещи, НЕ МОГУ В ПРИНЦИПЕ. Не имею права крутить какой то девелопмент на ресурсах которые используются продакшеном. Должен иметь ДР сайт в другом месте. Из Китая медленно работать со стойкой в США, нужно иметь систему локально в Китае. В начале проекта могу потратить от силы $5000 тысяч на железо, не более. И так далее. А мне предлагают РАЗОВО купить большую железяку в надежде что ее хватит на 5 лет вперед. Я этого сделать не могу, и проблема не техническая а бизнес - финансовая. И именно последняя и убивает мейнфрейм.

И вместо стойки на которой написан МейнФрейм у меня будет стойка в которую запихнуты свитчи, серверы, SAN системы, каждая не более 3U в размере, и которая начнется с 3 серверов а кончится полностью забитым раком. И когда она кончится я возможно уже перейду с DELL на HP и с EqualLogics на NetApp. Я не привязан к одному вендору и не должен делать вложения ЗАРАНЕЕ. А имею полную гибкость. Через 3 года я выкину 10 старых железок и заменю на 10 новых. Уже может и фирмы ДЕЛЛ не будет, мне это не помешает. А с МФ я буду сидеть и грустить (через 3 года) потому что денег еще на один МФ никто не даст а этот окажется хуже ноутбука у нашего начальника... проходили уже несколько раз и больше не хотим.

[iDesperado]

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

а вы не пробовали послушать, что вам говорят оппоненты ? ведь по и/о вам не раз и не два разжевывали, что при том же бюджете, что и МФ на x86 можно обеспечить на порядок более производительную и/о. на порядок, не менее. при ширпотребных ценах на x86 в и/о субсистеме будет минимум в 20 раз больше шпинделей, это преимущество ничем МФ не покроет, т.к. x86 будет иметь те же 6 Gb карточки только в разы большее их кол-во, но при этом еще и в несколько раз больше памяти под кеши

[iDesperado]

Примерно та же история для [tpc-c]. Ну да, неправильные тестбенчи, согласен.

есть вполне правильный tpc-e, мало того есть совсем правильный sap-sd, где еще 12 лет назад МФ достаточно активно участвовал, но как только писюки приблизились - табу.

[zVlad]

Уже начиная с z9 имеется возможность использовать столько ресурсов (MIPS) сколько реально нужно и платить только за использованные MIPS.

Где почитать?
....

Не уверен что это лучшее, но это первое что подвернулось:

http://www.redbooks.ibm.com/redpapers/pdfs/redp4416.pdf

[zVlad]

....
Да, по тактовой частоте з196 лидирует - выше 5 ГГц. Отдельные зионы идут с > 4 ГГц. Но по производительности важна не столько частота сколько архитектура, поэтому надо смотреть на суммарную производительность по тестам. Потом - использование параллельных ядер и потоков с поддержкой ширпотребовских компилляторов - [x86_64] здесь лидируют по числу ядер и по числу потоков по сравнению с з196. Вкратце - оба чипа хороши, нет между ними бездны. Но один закрыт, узкоспециализированный и дорогой (нет - ужасно дорогой), второй поддерживает открытые стандарты, широкого потребления и дешевый.

Во-первых, а где Вы видели такой параметр "число потоков" для процессора МФ.

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

[zVlad]

,....
.....
2. Еще проблема всех МФ - мне нужно обычно плодить сситемы - продакшен, стейджинг, ЪА, девеломпент там, девеломпент в Китае. Плодить МФ никакиих денег не хватит, пускать всех на один МФ - секьюрити с ума сойдут.

....
2. И ответьте, пожалуйста, Вы когда обращаетесь к зВлад-у Вы кого имеете в виду? Я спрашиваю потому что я уже тысячу раз писал, в том числе дискутируя с Вами лично, что на одном МФ может находится весь перечень систем, на одном МФ, их не надо столько сколько Вам нужно логических систем. Так обстоят дела там где я работаю. Я не надеюсь что Вы и сейчас это поймете.

Я понимаю что вы заменяете мою стойку с интеллами и с двумя сотнями виртуалок на ней одной стойкой с мейнфреймом. Проблема в том что я не могу смешивать на одной железке некоторые вещи, НЕ МОГУ В ПРИНЦИПЕ. Не имею права крутить какой то девелопмент на ресурсах которые используются продакшеном. Должен иметь ДР сайт в другом месте. Из Китая медленно работать со стойкой в США, нужно иметь систему локально в Китае. В начале проекта могу потратить от силы $5000 тысяч на железо, не более. И так далее. А мне предлагают РАЗОВО купить большую железяку в надежде что ее хватит на 5 лет вперед. Я этого сделать не могу, и проблема не техническая а бизнес - финансовая. И именно последняя и убивает мейнфрейм.

И вместо стойки на которой написан МейнФрейм у меня будет стойка в которую запихнуты свитчи, серверы, САН системы, каждая не более 3У в размере, и которая начнется с 3 серверов а кончится полностью забитым раком. И когда она кончится я возможно уже перейду с ДЕЛЛ на ХП и с ЭуалЛогищ на НетАпп. Я не привязан к одному вендору и не должен делать вложения ЗАРАНЕЕ. А имею полную гибкость. Через 3 года я выкину 10 старых железок и заменю на 10 новых. Уже может и фирмы ДЕЛЛ не будет, мне это не помешает. А с МФ я буду сидеть и грустить (через 3 года) потому что денег еще на один МФ никто не даст а этот окажется хуже ноутбука у нашего начальника... проходили уже несколько раз и больше не хотим.

Оставим ДР в покое. Здесь по определению не может быть одной железки в одном месте.
Разобравшись с ДР продолжим - Вы не можете "смешивать на одной железке некоторые вещи", не можете в принципе именно и только потому что известные Вам железки этого в принципе не позволяют. Известные Вам железки не умеют аккуратно и грамотно делить ресурсы между системами так что продакшн может прекрасно сидеть на одной машине со всеми, кроме ДР, инстансами.

Снова с сожалением должен констатировать что Вы спорите со мной даже не читая (или не понимая, или не желая понять) того что я здесь рассказываю про МФ. Так у нас конечно ничего хорошего не получится, впрочем как обычно. Это я о гибкости. Тем не менее, к тому что я уже сказал про гибкость собственно МФ, можно добавить что работать с МФ можно начинать (но только для девелопмента) на эмуляторах, которые базируются на ПК, т.е. достаточно дешевы. Но лучший вариант - это удаленная работа с оплатой в точности тех ресурсов, которые потреблены - такие услуги предоставляются. Удаленная работа с МФ существенно отличается от удаленной работы с, например, Windows. Работать с МФ и из Китая можно без проблем. Хотя что такое нынче удаленная работа?

[Dmitry67]

Разобравшись с ДР продолжим - Вы не можете "смешивать на одной железке некоторые вещи", не можете в принципе именно и только потому что известные Вам железки этого в принципе не позволяют. Известные Вам железки не умеют аккуратно и грамотно делить ресурсы между системами так что продакшн может прекрасно сидеть на одной машине со всеми, кроме ДР, инстансами.

Железки то как раз позволяют
То же WMware.
А вот policy не позволяют
То есть причина не техническая

[zVlad]

Разобравшись с ДР продолжим - Вы не можете "смешивать на одной железке некоторые вещи", не можете в принципе именно и только потому что известные Вам железки этого в принципе не позволяют. Известные Вам железки не умеют аккуратно и грамотно делить ресурсы между системами так что продакшн может прекрасно сидеть на одной машине со всеми, кроме ДР, инстансами.

Железки то как раз позволяют
То же VMware.
А вот полицы не позволяют
То есть причина не техническая

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

[zVlad]

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

а вы не пробовали послушать, что вам говорят оппоненты ? ведь по и/о вам не раз и не два разжевывали, что при том же бюджете, что и МФ на х86 можно обеспечить на порядок более производительную и/о. на порядок, не менее. при ширпотребных ценах на х86 в и/о субсистеме будет минимум в 20 раз больше шпинделей, это преимущество ничем МФ не покроет, т.к. х86 будет иметь те же 6 Гб карточки только в разы большее их кол-во, но при этом еще и в несколько раз больше памяти под кеши

Может Вы все таки расскажите реальную историю о вводе-выводе х86? Про разы и сколько их. Ну и по видимому Вы в курсе параметров МФ, раз делаете выводы. Расскажите и про ввод-вывод МФ в цифрах. Наполните Ваши доклады содержанием. Трескотню заявлений про разы я уже наслушался вдоволь, мне бы хотелось увидеть эти разы.

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

[Dmitry67]

Что именно позволяет VMware? Вы можете привести пример когда под VMware стояли бы и продакшн и девелопмент? Нет не можете. Поэтому и существуют такие полиси.

zVlad, не говорите чушь о том чего не знаете
VMware прекрасно организует 'песочницы' которые не мешают друг другу совершенно. То есть положить в один Datacenter и даже server PROD, QA и DEV не представляет никаких проблем. И они мешать друг другу не будут.

Причины разделения лежат совершенно не в технической плоскости.
Вы их на самом деле не понимаете?

[zVlad]

Что именно позволяет ВМшаре? Вы можете привести пример когда под ВМшаре стояли бы и продакшн и девелопмент? Нет не можете. Поэтому и существуют такие полиси.

зВлад, не говорите чушь о том чего не знаете
ВМшаре прекрасно организует ьпесочницыь которые не мешают друг другу совершенно. То есть положить в один Датацентер и даже сервер ПРОД, ЪА и ДЕВ не представляет никаких проблем. И они мешать друг другу не будут.

Причины разделения лежат совершенно не в технической плоскости.
Вы их на самом деле не понимаете?

ОК, не понимаю. Обьясните.

[Dmitry67]

1. Религиозные.
Например когда я работал в одной фирме, то данные клиентов A и B размещали на разных SQL servers. Хотя достаточно было создать две базы на одном. Почему? Потому что самый главный шеф все технические аргументы игнорировал - типа, умники из IT говорят, а береженого Бог бережет. То же самое и с PROD, QA, DEV - положено так, и все

2. Policy
Например, мы все upgrades обязаны вначале обкатывать на DEV/QA, прежде чем пихать их в PROD. если для upgrades самих виртуалок это все равно, где они, то upgrade самого VMware ESX server понятно, requires downtime. И по этой причине мы должны вначале его испытать на кошках.

3. Соображения удобства
A. Удобно по разному реагировать на Alerts от QA/DEV datacenter и PROD. например, от PROD вставать среди ночи, от DEV- нет.
B. Удобно иметь облегченную конфигурацию для DEV/QA, свободную от Disaster Recovery replication, с иной частотой backups итд
C. Удобно в DEV/QA ставить более старые Blades, с меньшей производительностью, перетягивая из PROD устаревшие
Вообще, учитывая, что ESX datacenter состоит из 5-10 (у нас) физических серверов то непонятно, зачем их искусственно объединять в один когда можно оставить DEV/QA

[iDesperado]

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

как вы себе представляете разговор о и/о в отрыве от кол-ва шпинделей, чуть ли не важнейшей характиристики современного и/о ?
мой поинт в том, что сегодня я на бюджет МФ легко могу поставить десяток стоек забитых десятками тысяч HDD и размазать например базу данных по всей этой массе HDD, в то время как бюджет МФ не позволит набить МФ и 10% от этого. при этом 4-сокета x86 будет иметь минимум 4 раза больше памяти, которая будет отведена на кеш и заметно снизит потребности в и/о, на фоне МФ.

[zVlad]

1. Религиозные.
Например когда я работал в одной фирме, то данные клиентов А и Б размещали на разных СЪЛ серверс. Хотя достаточно было создать две базы на одном. Почему? Потому что самый главный шеф все технические аргументы игнорировал - типа, умники из ИТ говорят, а береженого Бог бережет. То же самое и с ПРОД, ЪА, ДЕВ - положено так, и все

2. Полицы
Например, мы все упградес обязаны вначале обкатывать на ДЕВ/ЪА, прежде чем пихать их в ПРОД. если для упградес самих виртуалок это все равно, где они, то упграде самого ВМшаре ЕСХ сервер понятно, рэуирес дошнтиме. И по этой причине мы должны вначале его испытать на кошках.

3. Соображения удобства
А. Удобно по разному реагировать на Алертс от ЪА/ДЕВ датацентер и ПРОД. например, от ПРОД вставать среди ночи, от ДЕВ- нет.
Б. Удобно иметь облегченную конфигурацию для ДЕВ/ЪА, свободную от Дисастер Рецоверы реплицатион, с иной частотой бацкупс итд
Ц. Удобно в ДЕВ/ЪА ставить более старые Бладес, с меньшей производительностью, перетягивая из ПРОД устаревшие
Вообще, учитывая, что ЕСХ датацентер состоит из 5-10 (у нас) физических серверов то непонятно, зачем их искусственно объединять в один когда можно оставить ДЕВ/ЪА

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

2. Этот пункт говорит что технических возмозностей VMware не достаточно чтобы надежно ранить и Прод и других на одном боксе. В случае МФ мы имеем LPAR, а не VM. Но этого нет на Ваших железках и это технический недостаток из которого следует полиси запрещающее такие эксперименты. Вот мы и пришли не к политическому, а техническому обьяснению почему "низзя".

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

Теперь Вы, Дима, поняли Вашу ошибку?

[Dmitry67]

1. Директора принимают решения иначе. И мнения технических спецов для них далеко не самое главное. У вас недавно был целый плач Ярославны по этому поводу.
2. Мы можете сделать major upgrade МФ не останавливая виртуалок на ней?
3. Полиси идет не от МФ или VMware, а тот какого нибудь ISO или договора с клиентом.
Теперь вы поняли свою ошибку?

[zVlad]

1. Директора принимают решения иначе. И мнения технических спецов для них далеко не самое главное. У вас недавно был целый плач Ярославны по этому поводу.
2. Мы можете сделать майор упграде МФ не останавливая виртуалок на ней?
3. Полиси идет не от МФ или ВМшаре, а тот какого нибудь ИСО или договора с клиентом.
Теперь вы поняли свою ошибку?

1. Плачь был совершенно по иному чем мы сейчас говорим поводу. Поэтому не надо ля-ля.
2. Аналогом Вашему апгрэйду VMware будет апгрэйт микрокода MF, который делается на МФ (у нас) дважды в год без остановки партиций (мы не используем ВМ).
3. И что Вы считаете что у всех использующих МФ другие ИСО или клиенты? Наш клиент возможно имеет полиси не ранить прод под VMware, но это не мешает ему ранить Прод на одном МФ с девелопмент в разных LPAR.

О какой моей ошибке Вы говорите, Дима? Как насчет Ваших ошибок?

[zVlad]

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

как вы себе представляете разговор о и/о в отрыве от кол-ва шпинделей, чуть ли не важнейшей характиристики современного и/о ?
мой поинт в том, что сегодня я на бюджет МФ легко могу поставить десяток стоек забитых десятками тысяч HDD и размазать например базу данных по всей этой массе HDD, в то время как бюджет МФ не позволит набить МФ и 10% от этого. при этом 4-сокета х86 будет иметь минимум 4 раза больше памяти, которая будет отведена на кеш и заметно снизит потребности в и/о, на фоне МФ.

Минуточку. Вы что считаете что HDD "набиваются" в МФ?

Давайте оставим бюджет пока в стороне, давайте разберемся с производительностью ввода-вывода.

[iDesperado]

Минуточку. Вы что считаете что HDD "набиваются" в МФ?

нет, не считаю. я считаю, что HDD набиваются ровно в такие же стойки, что и мой x86, только стоек этих и соответственно FC карточек на x86 окажется заметно больше за те же деньги.

Давайте оставим бюджет пока в стороне, давайте разберемся с производительностью ввода-вывода.

давайте не давайте. именно бюджет обеспечит x86 безоговорочную победу, просто потому, что x86 в рамках того же бюджета позволит обеспечить в 10 раз больше шпинделей.

[StrangerR]

Что именно позволяет VMware? Вы можете привести пример когда под VMware стояли бы и продакшн и девелопмент?

Вам показать?? Стоят.

Но - в данном проекте это допустимо. А в другом недопустимо. Тогда я физических их разнесу, благо стоек с интелом немерянно и ткнуть еще один интел сервер если вдруг нужно - это где то +$1500 добавить.

[StrangerR]

Что именно позволяет ВМшаре? Вы можете привести пример когда под ВМшаре стояли бы и продакшн и девелопмент? Нет не можете. Поэтому и существуют такие полиси.

зВлад, не говорите чушь о том чего не знаете
ВМшаре прекрасно организует ьпесочницыь которые не мешают друг другу совершенно. То есть положить в один Датацентер и даже сервер ПРОД, ЪА и ДЕВ не представляет никаких проблем. И они мешать друг другу не будут.

Причины разделения лежат совершенно не в технической плоскости.
Вы их на самом деле не понимаете?

ОК, не понимаю. Обьясните.

Клиентская полиси требует полной изоляции продакшена от других проектов. То есть каждый кусок железа кроме сетевого свитча должен работать только на продакшен данного клиента. К примеру.

[Zombie416]

1. Прокомментируйте назначение вот этого $30 000 000-ного чуда:

http://tpc.org/results/individual_resul ... 120210.pdf

Ну там же написано. $30M - это 27 штук серверов, не один. В каждом из которых по 4 процессора (в каждом из которых уйма ядер и потоков) и 512GB RAM. Из которых собственно сервер, без дисков, "всего лишь" $200k. Притом что это ни разу не демократичный x86 ящик из Dell-а.

Назначение - продемонстрировать возможности

[zVlad]

Минуточку. Вы что считаете что ХДД "набиваются" в МФ?

1. нет, не считаю. я считаю, что ХДД набиваются ровно в такие же стойки, что и мой х86, только стоек этих и соответственно ФЦ карточек на х86 окажется заметно больше за те же деньги.

Давайте оставим бюджет пока в стороне, давайте разберемся с производительностью ввода-вывода.

2. давайте не давайте. именно бюджет обеспечит х86 безоговорочную победу, просто потому, что х86 в рамках того же бюджета позволит обеспечить в 10 раз больше шпинделей.

1. Все таки, Вы можете хоть на минуту забыть про деньги и Ваш самый сильный и единственный аргумент? Вы можете просто ответить сколько FC карточек может быть у одного х86 сервера? Если Вам не понятно что такое один сервер добавлю это то на чем загружена одна система: Windows или Linux или VMWare.

2. Вот это и хотелось бы увидеть, но пока Вы упорно не представляете данных, а мне искать эти данные за Вас в лом.

[Zombie416]

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

На единицу чего? Производительности? Тогда этот тезис справедлив вообще для любого компьютера.