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

[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]

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

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