Акела промахнулся! В смысле, Интел обосрался

[zVlad]

Вопрос не в администрировании, а в разработке софта на коболе, который скорее всего используется в Visa. Не думаю что выпускники ВУЗов горят желанием учить этот архаизм.

...

Тим лид наших программистов на Коболе -молодой парень, тридцать с небольшим. У него в команде есть люди проработавшие лет по пятьнадцать-двадцать, пришедших посла ВУЗ-а.
У них хорошие зарплаты, бенефиты, пенсия. Они свою работу не променяют на другую без такой зарплаты, бенефитов и пенсии. Люди вообще не для того и не потому работают что их работа связана с какой-то определенной платформой или языков. Так у них получается. И я не думаю что кто-либо вот так, как Вам кажется, решает что, нет, с Коболом я ни в коем разе дружить не буду. Я таких людей себе не представляю.
Я лично на Коболе никогда не писал, для меня есть два языка на которых я пишу программы по работе: REXX и Assembler. Был бы у нас PL/I я бы писал на нем, но у нас его нет. На PC я писал на SmallTalk.

[zVlad]

...

Когда начинается переход на Java, то не понятно зачем надо WAS в наши то дни...

А что, интересно, в наши то дни надо когда начинается переход на Java? Jboss? WildFly?
И вообще, что дает перевод работающих программ в точно такие же только написанные на другом языке? Если что-то придет на смену Java, Вы снова будете все заново переписывать?

[Dmitry67]

.

IBM посчитали 32 IFLs ~= 240 х86. Если приложение использует 2400 ядер х86, то надо 320IFLs (столько в один Z и не влезет ведь) и где-то 24TB памяти. Стоит это будет 10ки М$, на х86 это до 1М$ влезет и даже скорее всего поместится в одну стойку с парой свитчей.

У Вас есть перед глазами приложение на х86 с 2400 ядрами?

Наш комплекс включает около 600vm в среднем 6 коров то есть 3600 коров. Впрочем, виртуальных. Физических около 1000, могу немного ошибиться, пишу по памяти

[Dmitry67]

Кстати, у нас все железо обязательно меняется раз в три года

Вот! И это правильно!

Влад, а какого года у вас железо?

Походу вопрос ко мне. По разному было. И через два года меняли и через три. Сейчас у нас пятилетний контракт. Железо мэйнфрэйм лизуется, не покупается.
Последнее время популярен upgrade, когда из предыдущего карты ввода-вывода переносятся в новый. Экономия, понимаешь.

zBC12 у нас, 2013 год.

А data storages тоже в лизе?

[zVlad]

.

IBM посчитали 32 IFLs ~= 240 х86. Если приложение использует 2400 ядер х86, то надо 320IFLs (столько в один Z и не влезет ведь) и где-то 24TB памяти. Стоит это будет 10ки М$, на х86 это до 1М$ влезет и даже скорее всего поместится в одну стойку с парой свитчей.

У Вас есть перед глазами приложение на х86 с 2400 ядрами?

Наш комплекс включает около 600vm в среднем 6 коров то есть 3600 коров. Впрочем, виртуальных. Физических около 1000, могу немного ошибиться, пишу по памяти

IBM заявляет 8000 виртуалок на одном z14.
Я не раз рассказывал о своем прошлом (80е, 90е годы) опыте работы с VM/SP, или СВМ ЕС. Компьютеры тогда были однокоровыми памяти у них было 1 MB, 4 MB, максимум на чем я работал до 1995 года была пара IBM 4381 R14, двухпроцессорные, 32 МB. Количество виртуалок на одной VM измерялось десятками. Это были и своеобразные персональные вм, и вм баз данных (SQL/DS - 1993 год), и виртуалки для пакетной обработки.
На основании этого опыта я могу сказать что количество виртуалок ни о чем не говорит, а говорить о 6 коров на виртуалку это значит вообще не понимать что такое среда виртуальных машин и как она должна работать. У нас на нашей МФ нет виртуализации, но есть партиции физические и всем этим партициям доступны все четыра кора одновременно. Можно было дать 3 кора одной партиции и 1 другой, но это глупо потому что неизвестно когда и сколько ресурсов понадобится той или иной партиции.
А ты, Дима, говоришь 6 коров на виртуалку и говоришь тотал 3600. У вас что все виртуалки все время грузят каждая свои 6 коров на 100%? Конечно же нет. Тогда что ты этим хотел сказать?

[zVlad]

......
А data storages тоже в лизе?

Не знаю, может быть. Storage другая команда занимается.

[Dmitry67]

.

IBM посчитали 32 IFLs ~= 240 х86. Если приложение использует 2400 ядер х86, то надо 320IFLs (столько в один Z и не влезет ведь) и где-то 24TB памяти. Стоит это будет 10ки М$, на х86 это до 1М$ влезет и даже скорее всего поместится в одну стойку с парой свитчей.

У Вас есть перед глазами приложение на х86 с 2400 ядрами?

Наш комплекс включает около 600vm в среднем 6 коров то есть 3600 коров. Впрочем, виртуальных. Физических около 1000, могу немного ошибиться, пишу по памяти

IBM заявляет 8000 виртуалок на одном z14.
Я не раз рассказывал о своем прошлом (80е, 90е годы) опыте работы с VM/SP, или СВМ ЕС. Компьютеры тогда были однокоровыми памяти у них было 1 MB, 4 MB, максимум на чем я работал до 1995 года была пара IBM 4381 R14, двухпроцессорные, 32 МB. Количество виртуалок на одной VM измерялось десятками. Это были и своеобразные персональные вм, и вм баз данных (SQL/DS - 1993 год), и виртуалки для пакетной обработки.
На основании этого опыта я могу сказать что количество виртуалок ни о чем ее говорит, а говорить о 6 коров на виртуалку это значит вообще не понимать что такое среда виртуальных машин и как она должна ралотать. У нас на нашей МФ нет виртуализации есть партиции физические и всем этим партициям доступны все четыра кора одновременно. Можно былр дать 3 одной партиции и 1 другой, но это глупо потому что неизвестно когда и сколько ресурсов понадобится той или иной партиции.
А ты, Дима, говоришь 6 коров на виртуалку и говоришь тотал 3600. У вас что все виртуалки все время грузят каждая свои 6 коров на 100%? Конечно же нет. Тогда что ты этим хотел сказать?

Именно поэтому у нас физических коров около 1000, а виртуальных 3600. Потому что у нас утилизация небольшая.

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

8000 виртуалок - ни о чем не говорит. Нашинковать мелко можно везде

Теперь расскажите о том, почему из банальной информации что в среднем у нас 6 виртуальных коров на виртуалку вы делаете вывод, что я вообще не понимаю что такое виртуальные машины? Только пожалуста, не надо так надувать щеки

[Dmitry67]

......
А data storages тоже в лизе?

Не знаю, может быть. Storage другая команда занимается.

Просто это странно. У нас отработавшие диски должны уничтожаться. Физически. Хотя наверное сам контроллер может быть в лизе

[mskmel]

У Вас есть перед глазами приложение на х86 с 2400 ядрами?

Вот честно не хочется мериться у кого больше
Потому коротко: Да. 2400 это совсем небольшая величина. Производительность примерно одной стойки. Один ДЦ много стоек. ДЦ тоже много.

[mskmel]

я не думаю что кто-либо вот так, как Вам кажется, решает что, нет, с Коболом я ни в коем разе дружить не буду. Я таких людей себе не представляю.

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

[мухобой]

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

Всего 4 ядра на всю большую машину или я чего-то не понял?

[zVlad]

...

Именно поэтому у нас физических коров около 1000, а виртуальных 3600. Потому что у нас утилизация небольшая.

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

8000 виртуалок - ни о чем не говорит. Нашинковать мелко можно везде

Теперь расскажите о том, почему из банальной информации что в среднем у нас 6 виртуальных коров на виртуалку вы делаете вывод, что я вообще не понимаю что такое виртуальные машины? Только пожалуста, не надо так надувать щеки

ОК, извиняюсь, проглядел немного твою мысль, поспешил. Тем на менее ты говоришь о виртуальных корах шесть штук (пусть в среднем, но это все равно значит что количество ограничено) на виртуалку. А если окажется что виртуалка "задыхается" на своих шести/десяти/двух корах, а все остальные 994/990/998 ничем на загружены? Другие метрики должны быть и механизмы динамического выделения того количества виртуальных коров сколько позволяет общая загрузка и сколько требуется конкретной ВМ. На х86 таких гибких, интелектуальных менеджеров ресурсов нет, поэтому и пихают коры в стойки тысячами, десятками тысяч, сотнями - нехай подавятся, коры то эти дешевые.
Я не хотел тебя обидеть и вообщем то уважаю тебя, Дима. Но я представляю с чем ты работаешь. Вот эти ваши 1000 физических коров насколько реально загружены пусть даже в пиковые часы? Можешь сказать?
8000 IBM-ские тоже ни о чем не говорят, согласен, это чистый маркетинг. Я могу лишь сказать то что знаю об ограничении количества виртуалок под одним zVM - в 80е годы ограничение по ним было примерно 32 000.

[StrangerR]

Таким образом, объектом атаки является микроархитектура процессора, и саму атаку в софте не починить.

[/quote]

Не совсем. Ту атаку которая читает память ядра и физическую удавить легко - нефиг меппить юзеру память ядра. Это кстати уже сделано в линуксе и изначально так и есть в VMware гипервизоре, точнее должно быть. А вот ту, что читает за пределами своего массива в своем адресном пространстве, так не починить. Там идея простая.

Делаем (я очень по памяти пишу, есть подробная бумага, там пример поточнее):

if ( x < array1_size) {
y = array1[x];
z = array2[y];
}

Тренируем процессор чтобы он привык что тело ифа всегда выполняется. Суем x за пределами массива1. Процессор по привычке выполнит тело ифа для значения x за пределами. Потом опомнится и откатит, но элемент массива 2 уже в кэше, и проверив какой именно элемент попал в кэш, можно определить значение array1[x].

Ну и аналог есть со свитчами, причем там еще хитрее - тренировка делается на ДРУГОМ выражении, потом идем на свое, процессор берет предсказание с предыдущих выполнений СОВСЕМ ДРУГОГО и выполняет ваш блок с нужным вам (затренированным в процессор) значением...

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

[StrangerR]

Это учитывая стоимость переноса - возможно. А так ни один дурак сегодня и смотреть не будет на такие решения если с нуля.

Интересно, а на чем бы сейчас стали делать систему, подобную Visa? При том что eventual data consistency - неприемлемо.

Оракл ДБ машина. А фронт енды на обычных серверах. Возможно даже в приватном облаке.

[StrangerR]

.

IBM посчитали 32 IFLs ~= 240 х86. Если приложение использует 2400 ядер х86, то надо 320IFLs (столько в один Z и не влезет ведь) и где-то 24TB памяти. Стоит это будет 10ки М$, на х86 это до 1М$ влезет и даже скорее всего поместится в одну стойку с парой свитчей.

У Вас есть перед глазами приложение на х86 с 2400 ядрами?

Гмм. У меня в облаке за 6000 ядер в VM-ках (давно не глядел в репорты). При том что стоимость оного облака в сумме около 1M или даже меньше... Памяти там счас не помню но примерно 10 - 20 TB.