Computing power comparison: mainframe versus Intel Xeon

[Dmitry67]

и их недогруз не есть хорошо.

Недогруз...
Все таки МФ калечит сознание

90_full.jpg

[Flash-04]

Влад, какой недогруз на серверах которые суть виртуализируюшие сервера? Нет такой проблемы.

[Flash-04]

Кстати, Дмитрий, а что там с загонянием Oracle в VM? Я помню был период когда нам крайне не рекомендовали пихать БД в VM, но у нас был очень busy экземпляр. Вроде уже переросли эту проблему?

[zVlad]

Влад, какой недогруз на серверах которые суть виртуализируюшие сервера? Нет такой проблемы.

Виртуализация это не волшебная палочка. На МФ это давно уже переросли и преодолели. Все стоит на реальных ресурсах сколько бы поклонов слову "виртуализация" мы бы не отбивали, которые могут быть либо эффективно загружены либо недогружены. Третье это загруженность бессмысленной работой, в частности виртуализацией, издержки которой выполняются на реальных ресурсах.
P.S. Погода то какая мерзкая, а? В субботу лечу в Punta Cana.

[Flash-04]

Погода ужасная. Приятного отдыха

Влад, тебе не кажется что ты какую то бессмысленную фразу выдал про "реальные ресурсы"?

[Dmitry67]

Кстати, Дмитрий, а что там с загонянием Oracle в VM? Я помню был период когда нам крайне не рекомендовали пихать БД в VM, но у нас был очень busy экземпляр. Вроде уже переросли эту проблему?

У нас эта проблема решилась сама - тот продукт, для которого был реален нужен оракл, сдулся.

[zVlad]

Погода ужасная. Приятного отдыха

Влад, тебе не кажется что ты какую то бессмысленную фразу выдал про "реальные ресурсы"?

Что в этом безсмысленного? Обьясни. Я не любитель гадать за других.

[Flash-04]

Что в этом безсмысленного? Обьясни. Я не любитель гадать за других.

а пожалуйста:

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

что ты хотел этим сказать? что у мейнфрейма всегда загрузка CPU - 100%, и I/O - 100%? если нет, то мейнфрем "не загружен"? Так что ли?

Виртуализация как раз и позволяет более эффективно использовать ресурсы hardware, вроде с этим трудно спорить. Конечно будут накладные расходы, но они есть везде. Учитывая что hardware виртуализация есть в x86/x64 (правда последние новости про meltdown и прочаа несколько подкосил), то не очень понятно против чего боремся?

[Flash-04]

Кстати, Дмитрий, а что там с загонянием Oracle в VM? Я помню был период когда нам крайне не рекомендовали пихать БД в VM, но у нас был очень busy экземпляр. Вроде уже переросли эту проблему?

У нас эта проблема решилась сама - тот продукт, для которого был реален нужен оракл, сдулся.

ну да, классика то есть проблема таки была? самое забавное что у нас именно так и решилось - вендор продукта отказался от Oracle и сделал своё БД ядро (правда на MySQL) которое было менее жадным до I/O.

[StrangerR]

Кстати, Дмитрий, а что там с загонянием Oracle в VM? Я помню был период когда нам крайне не рекомендовали пихать БД в VM, но у нас был очень busy экземпляр. Вроде уже переросли эту проблему?

Проблема была только с крабораком ой RAC кластером.

[zVlad]

Что в этом безсмысленного? Обьясни. Я не любитель гадать за других.

а пожалуйста:

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

что ты хотел этим сказать? что у мейнфрейма всегда загрузка CPU - 100%, и I/O - 100%? если нет, то мейнфрем "не загружен"? Так что ли?

...

В принципе я видел отчеты по загрузке мф с горизонтальной линией на уровне 100%. Этот мф считал электрические биллы тебе, мне и всем кто потребляет электроэнергию GTA, а может и всего Онтарио. Его мощность и объем работ так были подогнаны друг под друга, это был самый нижний уровень, модель z9 BC-А01. Процесс чисто пакетный, сеть заданий с условиями и временами выполнения.
Есть вариант capacity-on-demand, когда раз в 4 часа мощность мф меняется в зависимости от статистики нагрузки, т.е. подстраивается под необходимую.
Более реалистичным и эффективным я считаю ситуацию когда на мф дается комплексная нагрузка (смесь) разбитая грубо по партициями со своими смесями грубо дополняюшими друг друга: OLTP с несколькими уровнями SLA, разными степенями важности и параметрами целевых критериев, набор пакетных работ с разными целевыми параметрами времени завершения вплодь до остсутсивия таковых, т.е. без требований у времени завершения, или в терминах WLM discretionary goal. Эти партиции вяжутся в Sysplex с IDR, т.е. параметры партиций могут меняться в зависимости от достижения целей все service classes во всех партициях.
Вот таким только способом можно удерживать загрузку близко с 100% и не только мф но и на любых других платформах, но я знаю что средства о которых я сказал с той функциональностью что я имею в виду есть только на мф, только с z/OS и только в Parallel Sysplex. z/VM такими способностями обладает в гораздо меньшей степени.

[zVlad]

.....
Виртуализация как раз и позволяет более эффективно использовать ресурсы hardware, вроде с этим трудно спорить. Конечно будут накладные расходы, но они есть везде. Учитывая что hardware виртуализация есть в x86/x64 (правда последние новости про meltdown и прочаа несколько подкосил), то не очень понятно против чего боремся?

Я тоже так считал и был в этом уверен пока не изучил достаточно и не поработал с z/OS. Кстати это справедливо для любой платформы, не только мф и z/OS.
Дело в том что распределяя ресурсы между виртуальными машинами мы мало знаем о том что происходит с процессами управляемыми OS виртуальной машины. Т.е. сделать процесс управления адаптивным к состоянию и нуждам процессов внутри машины не возможно, нет информации. Другое дело когда пишится менеджер ресурсов на уровне управления конечных процессов, то в зависимости от заданых целей можно распорядиться ресурсами более эффективно и достичь поставленных целей управления. Для этого еще надо иметь развитую систему квалификации работ, показателей целей и уметь из измерять чтобы сравнивать с задаными. Все это пока есть только в z/OS. Поэтому у вас, на х86, приходится молиться виртуализации, а у нас достаточно грамотно прописать требования SLA в полиси WLM, и следить за PI - Performance Index - для классов сервиса. Значение PI = 1, означает что WLM достиг заданой цели, меньше единицы - перевыполнил, больше единицы - недовыполнил. На основании этого делается перенастройка сервис классов, увеличиваются/уменьшаются те или иные элементы мф: CPU, RAM, I/O Channels.

[Dmitry67]

Есть вариант capacity-on-demand, когда раз в 4 часа мощность мф меняется в зависимости от статистики нагрузки, т.е. подстраивается под необходимую.

Только сейчас я сообразил, какой же это абсурд.

То есть мы вначале хвастаемся, что реальная мощь МФ придушена и используется 1/10 (не помню сколько уже говорилось), потом хвастаемся что загрузка (у этого кусочка) 100% и нет "недогруза". Простите, у вас простой 9/10 машины!

Вы в огромном грузовике отгородили шторкой маленький кусочек, и забиваете его под потолок, и хвалитесь что у вас порожних рейсов нет )))

[iDesperado]

Вы в огромном грузовике отгородили шторкой маленький кусочек, и забиваете его под потолок, и хвалитесь что у вас порожних рейсов нет )))

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

[zVlad]

Есть вариант capacity-on-demand, когда раз в 4 часа мощность мф меняется в зависимости от статистики нагрузки, т.е. подстраивается под необходимую.

Только сейчас я сообразил, какой же это абсурд.

То есть мы вначале хвастаемся, что реальная мощь МФ придушена и используется 1/10 (не помню сколько уже говорилось), потом хвастаемся что загрузка (у этого кусочка) 100% и нет "недогруза". Простите, у вас простой 9/10 машины!

Вы в огромном грузовике отгородили шторкой маленький кусочек, и забиваете его под потолок, и хвалитесь что у вас порожних рейсов нет )))

Никто ничем не хвастался. Я миллион раз говорил что говорю то что есть и если до некоторых долго доходит то я не виноват.
Ты, Дима, верно подметил то о чем я многократно говорил. Но не торопись называть неосознанное абсурдом.
Действительно количество оборудования в стойку мф вставляется гораздо более более крупными кусками (configuration models) чем имеетcя уровней мощности (performance models). В нашем мф с performance model A01 мощность составляет 1/20 одного кора. На самом деле там не менее 6 коров находится, и памяти там больше 32GB что мы можем использовать системами на нем. Это большая глупость, но не абсурд.
Цена за софт на мф с классической нагрузкой - z/OS определяется количеством активизированных MIPS. Наш А01 кроме того что это DR site для основного приложения используется под продакшн систему с базой данных CA-IDMS. Цена за эту бд определяется 50 MIPS-ми мф на котором она у нас используется. Мы могли бы выполнять эту бд на втором нашем мф с 1000 MIPS, но тогда цена за CA-IDMS была бы, условно, в 20 раз больше. Это тоже глупость, но уже вендора который не хочет принимать во внимание что их бд можно выполнять в партиции с 50 MIPS, на мф с 1000 MIPS.
Причем физические конфигурации обоих наших мф абсолютно одинаковые. Performance model на них могла бы быть максимально -Z06 c 4958 MIPS, памяти можно было бы активировать в разы больше (мы заплатили за активированную память), карт ввода-вывода и карт для криптографии (которых у нас нет) тоже можно было бы в разы больше напихать. Короче реальная мощность наших мф в десятки раз вышечем то что оплатили и говоря о 100% нагрузки, около которой мы болтаемся несколько пиковых часов в день, исключая выходные, это лишь про то что в наших мф активированно.

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