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

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

[zVlad]

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

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

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

Ты говоришь о каких дисках? Локальных, тех что в серваке? Или тех что в SAN, NAS?
У мэйнфрэйм никогда не было локальных дисков (несколько лет назад правда появились SSD локальные, но только для страничного обмена, для больших страниц виртуальной памяти).
Диски всегда были .... нет не SAN и не NAS, но внешние и их производили и производят все кто производит диски вообще, включая саму IBM, конечно. Представляют они из себя стойки поболее самих мэйнфрэйм и значительно, в которых есть серваки и куча физичекских носителей на которых организованы RAID-5, например. В этих же стойках SAN и/или NAS для Windows/Unix/Linux серверов находятся тоже. Каналы МФ и прочих серваков к этим стойкам дисков физически разные и не совместимы по протоколам.
Перед возвращением дисков мы их инициализируем так что прочитать с них ничего не получится. Есть у нас такие средства.

[Dmitry67]

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

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

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

Ты говоришь о каких дисках? Локальных, тех что в серваке? Или тех что в SAN, NAS?
У мэйнфрэйм никогда не было локальных дисков (несколько лет назад правда появились SSD локальные, но только для страничного обмена, для больших страниц виртуальной памяти).
Диски всегда были .... нет не SAN и не NAS, но внешние и их производили и производят все кто производит диски вообще, включая саму IBM, конечно. Представляют они из себя стойки поболее самих мэйнфрэйм и значительно, в которых есть серваки и куча физичекских носителей на которых организованы RAID-5, например. В этих же стойках SAN и/или NAS для Windows/Unix/Linux серверов находятся тоже. Каналы МФ и прочих серваков к этим стойкам дисков физически разные и не совместимы по протоколам.
Перед возвращением дисков мы их инициализируем так что прочитать с них ничего не получится. Есть у нас такие средства.

О.любых дисках
Разумеется, большинство в SAN/NAS
Но у нас считается что любой формат плох
Кто его знает, нутро современных SSD (надеюсь у вас давно не осталось старых вращающихся?)
Поэтому только физическое уничтожение

[Dmitry67]

. Тем на менее ты говоришь о виртуальных корах шесть штук (пусть в среднем, но это все равно значит что количество ограничено) на виртуалку. А если окажется что виртуалка "задыхается" на своих шести/десяти/двух корах, а все остальные 994/990/998 ничем на загружены?

Windows давно поддерживает hot cpu plug in. Метрик и алертов полно. Но я бы не хотел чтобы виртуалки расширились на автомате. Может это просто runaway?

[zVlad]

...
Разумеется, большинство в SAN/NAS
Но у нас считается что любой формат плох
Кто его знает, нутро современных SSD (надеюсь у вас давно не осталось старых вращающихся?)
Поэтому только физическое уничтожение

Нет, у нас "старые", вращающиеся. SSD было бы слишком дорого для нашего клиента. Мы даже у IBM диски не берем, даже вращающиеся - опять же, дорого. Зато у нас однопроцессорный мэйнфрэйм есть, за поллимона. И я не иронизирую, это себя окупает, я имею в виду МФ.

[zVlad]

...Но я бы не хотел чтобы виртуалки расширились на автомате. Может это просто runaway?

Это очень зависит от интелекта того менеджера ресурсов, который будет "подбрасывать" дровишки.
LPAR - менеджер ресурсов на МФ для партиций (не виртуалок) может назначенное количество процов партиции сократить в определенных условиях (запарковать).
Все должно быть под контролем естественно, как по добавлению так и сокращению ресурсов виртуалки и/или партиции. Есть такое средство Intelligent Resource Director. Доступен только с zOS. Почитай:

https://en.m.wikipedia.org/wiki/Intelli ... e_Director

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

[Dmitry67]

...
Разумеется, большинство в SAN/NAS
Но у нас считается что любой формат плох
Кто его знает, нутро современных SSD (надеюсь у вас давно не осталось старых вращающихся?)
Поэтому только физическое уничтожение

Нет, у нас "старые", вращающиеся. SSD было бы слишком дорого для нашего клиента. Мы даже у IBM диски не берем, даже вращающиеся - опять же, дорого. Зато у нас однопроцессорный мэйнфрэйм есть, за поллимона. И я не иронизирую, это себя окупает, я имею в виду МФ.

А можно подтолкнуть сторедж просто.третьей стороны, типа NetApp, EMC итд?

[zVlad]

...
А можно подтолкнуть сторедж просто.третьей стороны, типа NetApp, EMC итд?

У нас ЕМС как раз и "подталкивается" (what ever you mean). Ленты магнитные у нас были заменены на виртуальные, на "вращающихся" дисках от ЕМС.

[StrangerR]

Перед возвращением дисков мы их инициализируем так что прочитать с них ничего не получится. Есть у нас такие средства.

Нда. У нас такое даже наш слабенький аудит не прошло бы... Инициализировать (даже форматировать) вообще то недостаточно.

[StrangerR]

...
Разумеется, большинство в SAN/NAS
Но у нас считается что любой формат плох
Кто его знает, нутро современных SSD (надеюсь у вас давно не осталось старых вращающихся?)
Поэтому только физическое уничтожение

Нет, у нас "старые", вращающиеся. SSD было бы слишком дорого для нашего клиента. Мы даже у IBM диски не берем, даже вращающиеся - опять же, дорого. Зато у нас однопроцессорный мэйнфрэйм есть, за поллимона. И я не иронизирую, это себя окупает, я имею в виду МФ.

Ну я и говорю, дикие цены. Ставим дешевую стойку от HP, MSA2040, две полки, одну дисками по 6TB в RAID6 другую SSD в RAID10, получаем двух тировую (архив и пефоменс) SAN за всего то каких то тысяч 80 (и то за счет 25 SSD дисков - 800 GB SAN grade - $2000 за штуку). И это low level, есть и повыше.

(И получаем сразу 60 TB из которых горячие блоки на 10 живут на SSD.)

[zVlad]

.....Метрик и алертов полно.

Кстати об алертах.
В нашем офисе кроме меня еще один русскоговорящий есть. Мы с ним пьем кофе, обедаем, гулять ходим. Он тим лид по Wintel сервакам. У него 12 человек и пара тысяч серверов. Есть ESX-ы, и Hyper-V, и в облако их микрософтовское тащит не подетски.
Так вот список основных его проблем, которые мы то и дело обсуждаем:

- alerts. Они внедрили систему новомодную которая следит за кучей параметров на серваках и выдает автоматом тикеты. Вот приходит Иван утром, а у него в очереди тысяча тикетов о том что была загрузка CPU на том или другом сервере больше 60%. И вот ему на все надо ответить, закрыть тикет как минимум.

- asset refresh. Постоянно идет работа по замене старого на новое. Это только на первый глаз тривиальная работа, но в ней столько ньюансов что идет эта работа очень медленно. Попытки агрегирования ресурсов в стойки унифицированные тоже мало помогает. Старые приложения, которые в новых средах/версиях не хотят работать и никто не может понять почему. И т.п.

- как отбиться от пользователей клиента и наших разработчиков от требований дать administrator rights на тот или иной сервер. Последняя история была рассказана (причем после долгого его разговора по телефону на эту тему с кем-то после которого от него пар валил и пена хлопьями сыпалась. Весь офис обратил на это внимание) о том что когда то был запрошен administrator на некий сервак, предоставлен, но клиент этим не пользовался. Недавно решил таки попользоваться и оказалось что админа у его профиля нет, и он просит это восстановить и дать тоже на другой сервер.
Вот основные проблемы их группы в 12 человек. И я рядом сижу один, мэйнфрэйм жужит, проблем нет, и жужать будет еще два года, даже после моего ухода на пенсию.

12 * С$200 000 = С$2 400 000 в год. Наши мэйнфрэйм дешевле стоят на пять лет.