Computing power comparison: mainframe versus Intel Xeon

[Dmitry67]

Ты меня не понял, Дима. Я про презентацию о современном ИТ. Там же у вас, в Питере, есть кафедры ИТ-шные и они что-то студентам преподают. Что знают то и преподают, по видимому. А я бы рассказал о том чего они не знают. И не только не знают в универе, но и среди питерских ИТ-шников вне универа, их тоже можно было бы привлечь. У меня были контакты в Питере, но в 80-е годы.

Здесь я помочь не могу, так как совершенно вне унмверситетских кругов.

Но если будете читать в Питере лекцию - приду)

Однако рекомендую начать со статьи на хабре или geektimes, прозондируйте почву, прочтете комментарии

[zVlad]

Почитай, Дима, про горизонтальное масштабирование в ракетостроении, про Королевскую ракету Н-1 для лунного проекта. Ракета может быть и получилась бы, но уж больно трудно было научить ее летать.

Кстати (off topic), сейчас почитал - Falcon Heavy имеет примерно столько же двигателей как в H1 (27 vs. 30).
Ещё одну советскую космическую идею злые буржуины украли и воплотили...

Совершенно верно, это могло работать и идея была не плохая, но тогдашние датчики и системы управления не могли обеспечивать стабильности и синхронности. А нынче могут.

[zVlad]

...
Но если будете читать в Питере лекцию - приду)

Однако рекомендую начать со статьи на хабре или geektimes, прозондируйте почву, прочтете комментарии

Обязательно.
Спасибо за совет.

[mskmel]

У нас сидит порядка 10 000 и все используют мф. z/OS по секьюрити позволяет собирать любую статистику.

Например, можете ли вы глядя на свои логи генерить realtime alerts:
"Логин юзера ХХХ в ДБ2 из-под юзера YYY в Win, который вошёл в Win remote desktop не из Канады?".
"Наличие коннекта в non-prod DB2 при наличии коннекта того же юзера в prod MS SQL"
На МФ просто нет этой информации, он знает только о самом себе, но ничего не знает об окружающем мире.

Вопрос: когда это будет на серверах x86? Ведь мощности то х86 серверов действительно достигли гигантских величин и никакая из известных ОС явно не в состоянии эффективно эти мощности загружать.

Не понятна эта фраза. Нагрузка от самой ОС ничтожна относительно нагрузки приложения, будь то БД или batch или app server.
Именно приложения не имеют проблем загрузить любую машину под 100%, с этим и борются создавая распределённые системы - database sharding или много-много узлов для app server.
И загрузить на 100% это чаще ввод\вывод и память, а совсем не CPU, MIPS за которые вы платите.

Само собой напрашивается возможность делить мощный х86 на набор независимых, логических х86 партиций со своим OS в них.
Что мешает этому быть!

Партиции есть у Superdome X - "HPE Superdome X offers scalability that surpasses the market, flexibility through HPE nPARs"
Основная причина - это уже мало кому надо. Изоляция на уровне VM, судя по всему, всех удовлетворяет. Лично Superdome X не видел.

[zVlad]

У нас сидит порядка 10 000 и все используют мф. z/OS по секьюрити позволяет собирать любую статистику.

Например, можете ли вы глядя на свои логи генерить realtime alerts:
"Логин юзера ХХХ в ДБ2 из-под юзера YYY в Win, который вошёл в Win remote desktop не из Канады?".
"Наличие коннекта в non-prod DB2 при наличии коннекта того же юзера в prod MS SQL"
На МФ просто нет этой информации, он знает только о самом себе, но ничего не знает об окружающем мире.

....

Если ты все знaешь то зачем спрашиваешь?

Вот пример из моего текущего SYSLOG:

Code: Select all

DSNT375I  -DB09 PLAN=P9GPASS WITH 208
        CORRELATION-ID=<...>
        CONNECTION-ID=<...>
        LUW-ID=NET.DB09LU.D3C974AB9B51=117021
        THREAD-INFO=<userid1>:*:*:*
        IS DEADLOCKED WITH PLAN=P9GPASS WITH
        CORRELATION-ID=<....>
        CONNECTION-ID=<...>
        LUW-ID=NET.DB09LU.D3C974A5FF44=116944
        THREAD-INFO=<userID2>:*:*:*
        ON MEMBER DB09

Вот этот вот фрагмент: LUW-ID=NET.DB09LU.D3C974AB9B51=117021 может быть использован чтбы протрассировать пользователя с именем <userID1> дo того компьютера с которого он попал на мф.
Любое изменение в DB2 из журнала изменений имеет информацию с кототой тоже можно "добраться" до истоков. Есть end-to-end мониторы.

Как то к нам в систему пытались залогониться подбором паролей. Я смог протрассировать IP адресс, порт и время попыток до Citrix сервера. Мы передали нашу информацию в суппорт этого Citrix сервера, но они ответили что данных для дальнейшей трасировки у них нет.

Так что не надо бы торопиться с выводами уважаемый, mskmel, надо дожидаться ответов.

[zVlad]

...

Вопрос: когда это будет на серверах x86? Ведь мощности то х86 серверов действительно достигли гигантских величин и никакая из известных ОС явно не в состоянии эффективно эти мощности загружать.

Не понятна эта фраза. Нагрузка от самой ОС ничтожна относительно нагрузки приложения, будь то БД или batch или app server.
Именно приложения не имеют проблем загрузить любую машину под 100%, с этим и борются создавая распределённые системы - database sharding или много-много узлов для app server.
...

Я и не сомневался что это (да и многие другие фразы) окажутся не понятными.
Речь идет о том что для эффективной загрузки больших мощностей требутся много разнообразной работы. Но этого мало, надо еще чтобы ОС могла эту работу эффективно, оперативно и гибко перераспределять между имеющимися ресурсами CPU, памяти и ввода-вывода. Гибко в предыдущей фразе означает автоматически, динамически т.е. на основании измерений результатов управления. На сегодня такой механизм имеется только в z/OS в его SRM (System Resource Manger), который собственно управляет, и WLM (Work Load Manager), который измеряет результаты управления и динамически меняет параметры управления в SRM. Кстати, рекомендую поискать на интернете какую-нибудь брошюрку с картинками про z/OS WLM и самому в этом убедиться. Такие брошюрки и не однa, на интернете есть. Не получится - дай знать, помогу.

Приложения конечно же могут загрузить любую машину, спору нет. Например, можно запустить задачку-числодробилку да еще и такую что она на по всем корам раcползется и эта задача "убьет" все остаьное на сервере. Или другая задача с интенсивным вводом-выводом. Будете устанавливать приоритеты? Какой из этих задач дадите приоритет выше? Той что считает? тогда та что с вводом-выводом никогда не увидит CPU. Или наоборот?
Поэтому на х86 существует правило: один сервер-один сервис. Более того сервис делают не на одиночной сервере, а на кластере серверов (собственно ты сам о том же говоришь). Поэтому "Superdome X " " уже мало кому надо". Виртуальные машины хорошо работают у StrangeR, т.е. в девелопменте, a в Production где большие об'емы и высокие нагрузки, работают кластеры на реальных серверах. И изоляция в виртуальных машинах не такая уж и хорошая в свете meltdown и Spectre чтобы о них не говорили и как бы не хорохорились.

[mskmel]

Как то к нам в систему пытались залогониться подбором паролей. Я смог протрассировать IP адресс, порт и время попыток до Citrix сервера.

Нет, не надо трассы снимать. Это у вас пара ДБ2 и несколько сот юзеров, а бывает что только БД тысячи. Надо в реалтайме генерить алерт. Сразу как только система, а не Вы, увидели подбор паролей или подозрительный логин. Подозрительный вплоть до: "Этот юзер обычно входит с хоста ХХХ, а тут вошел с хоста YYY".

Умножаем проблему на 100к+ юзеров и 10к хостов. Не забывая что логин это не единственное действие которое может совершить юзер.

[Dmitry67]

Виртуальные машины хорошо работают у StrangeR, т.е. в девелопменте, a в
Production где большие об'емы и высокие нагрузки, работают кластеры на реальных серверах

PSX_20180124_191611.jpg

Влад, пожалуйста, хватит фантазировать
Например у нас фирма 99% virtual.
Физические сервера только несколько вспомогательных серверов
Я не говорю уже о AWS

[mskmel]

Речь идет о том что для эффективной загрузки больших мощностей требутся много разнообразной работы.

Увы, не требуется вычислительных ресурсов почти. IO and CPU scheduler почти не заметны на фоне остальной нагрузки.
У Вас реальный опыт high load или в теории? У вас когда-нибудь было на МФ 7ТБ новых данных в день, а 70ТБ? Да, Вы думаете, что ваш МФ столько сможет. Но было ли лично у Вас?

Будете устанавливать приоритеты? Какой из этих задач дадите приоритет выше? Той что считает? тогда та что с вводом-выводом никогда не увидит CPU. Или наоборот?

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

Поэтому на х86 существует правило: один сервер-один сервис
...
Production где большие об'емы и высокие нагрузки, работают кластеры на реальных серверах.

Срочно выйти из пещеры! Обосновать bare metall сейчас крайне тяжело... кластеры собираются на VM.

[Flash-04]

Секьюрити логи, если только вы не отслеживаете каждый шаг движения всего и везде, не могут давать 7TB в день даже если в конторе сидит 100 тысяч человек.

Вот когда вы поймёте что очень даже могут, мы сможем продолжить беседу.
Просто логи Web Proxy дают очень очень до фига. Сами по себе authentication logs не очень информативны когда нужно проследить всю цепочку. Добавьте до кучи DNS логи. Зачем? Через DNS замечательно идёт передача данных наружу.

[zVlad]

Как то к нам в систему пытались залогониться подбором паролей. Я смог протрассировать IP адресс, порт и время попыток до Citrix сервера.

Нет, не надо трассы снимать. Это у вас пара ДБ2 и несколько сот юзеров, а бывает что только БД тысячи. Надо в реалтайме генерить алерт. Сразу как только система, а не Вы, увидели подбор паролей или подозрительный логин. Подозрительный вплоть до: "Этот юзер обычно входит с хоста ХХХ, а тут вошел с хоста YYY".

Умножаем проблему на 100к+ юзеров и 10к хостов. Не забывая что логин это не единственное действие которое может совершить юзер.

Если бы это случалось у нас часто и было бы критично то создать такой alert и запрограмировать какие угодно, реальные, действия для меня было бы делом очень небольшого времени.
А учитывая что с использованием мф мы можем обходится меньшим количеством хостов для, я уверен, сопостaвимых по обьему в любых единицах измерения работ то это было бы сделало легче и надежнее. У вас из-за одного лишь количecтва единиц обслуживания (хостов) проблемы тяжелеют до неперемосимости. Вы конечно станете спорить, но я постоянно общаюсь с нашим team lead Wintel серверов и знаю об этом не по наслышке, а из первых рук.

[Flash-04]

Влад, не кол-во хвостов, а кол-во людей.

[mskmel]

Если бы это случалось у нас часто и было бы критично то создать такой alert и запрограмировать какие угодно, реальные, действия для меня было бы делом очень небольшого времени.

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

[mskmel]

Добавьте до кучи DNS логи. Зачем? Через DNS замечательно идёт передача данных наружу.

Не палите контору. 99% IT-ков об этом не знают

[zVlad]

Секьюрити логи, если только вы не отслеживаете каждый шаг движения всего и везде, не могут давать 7TB в день даже если в конторе сидит 100 тысяч человек.

Вот когда вы поймёте что очень даже могут, мы сможем продолжить беседу.
Просто логи Web Proxy дают очень очень до фига. Сами по себе authentication logs не очень информативны когда нужно проследить всю цепочку. Добавьте до кучи DNS логи. Зачем? Через DNS замечательно идёт передача данных наружу.

Не надо задирать нос, Flash-04. То что там где и с чем я работаю не создают такие потоки данных вовсе не означает что я не могу себе представить что это такое. Более того, я уверен, что для этих потоков можно придумать некоторые меры чтобы необходимости их все сохранять не было бы. Но естественно не зная всего я ничего сказать не могу, и ты этим пользуешься. Не честно.
Вот скажи честно, ты эти все логи видел, сколько можно в этих логах выбросить без каких-либо последствий для чего угодно?
У меня тоже генериться туева хуча сообщений в SYSLOG и хранится аж 30 дней, но это все используется в ничтожных количествах, а можно и вообще было не хранить если на самые тем более что самое важное отражается в нескольких разных местах.
Короче разговор ни о чем. Со Splunk я ознакомился, их желание обрабатывать данные с МФ понятно - это дает им дополнительные точки роста. Но с моей точки зрения мф-щика все это лишь излишняя суета.

[zVlad]

Если бы это случалось у нас часто и было бы критично то создать такой alert и запрограмировать какие угодно, реальные, действия для меня было бы делом очень небольшого времени.

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

С чего ты взял что нет? Ведь я же писал что все изменения в базе RACF хранятся с 2006 года. Ты наверное хочешь сказать о попытках доступа к защищенным ресурсам? Наверное на них интерeсно было бы смотреть, но в нашем случае это пустая трата времени потому что можно хоть сколько пытаться получaть доступ к ресурсу, но если он защищен то доступа не получишь никак. С другой стороны если доступ к ресурсу разрешен то факт доступа тоже становится малоинтересным. Если мы не хотим чтобы тот или иний юзер логинился в систему когда ему вздумается то мы можем в RACF, каждому юзеру, прописать его график работы и RACF его не пустит вне этого графика.
Данные к которым у юзера есть доступ уйдут хоть зааудируйся, хоть замониторься. Если же доступа нет, то данные в направлении того у кого его нет не уйдут, точка. Что еще может быть? Ты хочешь сказать что у вас утекают данные к тем у кого нет доступа к ним? Мне очень вас жаль. Меняйте вашу систему, которая это позволяет. Не хотите менять, нравится вам движуха когда надо перелапачивать терабйты чтобы найти утечку? Флаг вам в руки и всяческих успехов в этом. Только не надо наводить тень на плетень тогда.
Что еще я не сказал про аудит в твоем понимании? Скажи и я скажу как с этим "бороться" на мф можно. Я не раз встречался с аудиторами секьюрити в прошлом. Если они понимали что такое RACF и z/OS, а они это понимали иначе бы их не послали ко мне, то разговор у нас всегда был довольно короток. Покажи то, покажите это, все спасибо - вопросов больше нет работайте дальше. И в тоже время я знаю такие вопиющие факты нарушений требований секьюрити у нас что туши свет. Причем узнал я о них не из алерт-ов каких-то не из логов или обработки терабайтов информации, а совсем иначе, и более того это узнать было бы невозможно ни алерт-ами ни аудитом, ничем.

[zVlad]

Влад, не кол-во хвостов, а кол-во людей.

И хостов тоже. Посмотри сам внимательней.
Как всегда тебя придется тянуть за язык. Колись, как количество людей влияет на тяжесть работы секьюрити? Если все что надо защищено надежно и это обозримо, то копание в логах превращается в бессмысленное занятие, верно? Если нет,то это означает что не все и ненадежно защищено.
У нас вот на х86 серверах если надавить то можно получить админ права (и давят и получают с одобрения наших секретчиков и секретчиков нашего клиента), или если есть друг в Wintel, то он тебе может дать эти права. Потом правда пробежит некий script и удалит твой аккоунт из "administrators" груп, но если что надо то все уже будет сделано. У вас есть такая дырочка? Как вы с ней боретесь? А на мф необходимость иметь "admin" доступ нужна ровно одному человеку на всю организацию каких бы она не была размеров. У всех остальных доступ только пользовательский.

Надеюсь и ты тоже наконец поймешь что возможно такое что секьюрити железная без необходимости генерировать 7 TB в день и копаться в них до морковкинного заговления и находить что данные то уже спи..дили. Дили-дили трали-вали....

[zVlad]

...
Срочно выйти из пещеры! Обосновать bare metall сейчас крайне тяжело... кластеры собираются на VM.

Ссылочку кинь пожалуйста на те "VM" и кластера из них? У меня сегодня нет в офисе моего друга из Wintel, а то бы я его допросил.

[StrangerR]

Ааа а мужики то и не знают... Наши продакшен базы все на виртуалках, и что важнее, крупные кастомеры все практически рисуют будущее только на виртуалках в облаках...

Желающие bare metal посылаются в пешее эротическое уже лет 5 как.. Никто еще оттуда не вернулся...

Виртуальные машины хорошо работают у StrangeR, т.е. в девелопменте, a в
Production где большие об'емы и высокие нагрузки, работают кластеры на реальных серверах

PSX_20180124_191611.jpg

Влад, пожалуйста, хватит фантазировать
Например у нас фирма 99% virtual.
Физические сервера только несколько вспомогательных серверов
Я не говорю уже о AWS

[mskmel]

...
Срочно выйти из пещеры! Обосновать bare metall сейчас крайне тяжело... кластеры собираются на VM.

Ссылочку кинь пожалуйста на те "VM" и кластера из них? У меня сегодня нет в офисе моего друга из Wintel, а то бы я его допросил.

Exadata это от трёх физических серверов, на них поднятны виртуалки объединённые в RAC. Она так по умолчанию идёт.

[mskmel]

Если бы это случалось у нас часто и было бы критично то создать такой alert и запрограмировать какие угодно, реальные, действия для меня было бы делом очень небольшого времени.

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

С чего ты взял что нет?

Вы не поняли. Юзер ХХХ на ДБ2 защищён, но юзер YYY украл пороль юзера ХХХ и вынес ваши данные. Вы об этом не узнали. Все логины были правильные, но юзер YYY не должен был знать пароль ХХХ. Как украл - не важно, пусть утюгом выпытал.
Т.е. вы сейчас подобные сценарии даже не анализируете.

[zVlad]

Если бы это случалось у нас часто и было бы критично то создать такой alert и запрограмировать какие угодно, реальные, действия для меня было бы делом очень небольшого времени.

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

С чего ты взял что нет?

Вы не поняли. Юзер ХХХ на ДБ2 защищён, но юзер YYY украл пороль юзера ХХХ и вынес ваши данные. Вы об этом не узнали. Все логины были правильные, но юзер YYY не должен был знать пароль ХХХ. Как украл - не важно, пусть утюгом выпытал.
Т.е. вы сейчас подобные сценарии даже не анализируете.

Давай уже на ты.
А юзер YYY, по твоему, определяeтся по тому что он с паролем и именем юзера XXX логинился со своего desktop-а в офисе? Так что ли? Я могу с любого десктопа в нашем (и Вашем) офисе залогиниться, тоже с моего десктопа может залогиниться кто угодно.
Или на свой десктоп он логинится со своими YYY, а в DB2 с XXX?
Расскажи как ты эту ситуацию разрулить думаешь причем в реальном масштабе времени, а не потом когда-нибудь.

[zVlad]

...
Срочно выйти из пещеры! Обосновать bare metall сейчас крайне тяжело... кластеры собираются на VM.

Ссылочку кинь пожалуйста на те "VM" и кластера из них? У меня сегодня нет в офисе моего друга из Wintel, а то бы я его допросил.

Exadata это от трёх физических серверов, на них поднятны виртуалки объединённые в RAC. Она так по умолчанию идёт.

Не понял. Три физических сервера, а сколько виртуалок то на них? Три?

Я полагаю ты не про Exadata должен был бы сказать. А ссылочка то где?

Я допускаую что сервера типа тех что Хеон с 80 корами и 1 TB RAM могут быть с, например, VMWare и даже Production нагрузку нести. Но, наверняка, с условием что, например, мы ставим не больше 3х, 5ти виртуалок, закрепляем за ними по столько и столько кор, память чтобы не сильно выпирала за 1 TB и т.п.. Так это тогда эмуляция LPAR получается, о которых я говорил утром.

[mskmel]

...
Срочно выйти из пещеры! Обосновать bare metall сейчас крайне тяжело... кластеры собираются на VM.

Ссылочку кинь пожалуйста на те "VM" и кластера из них? У меня сегодня нет в офисе моего друга из Wintel, а то бы я его допросил.

Exadata это от трёх физических серверов, на них поднятны виртуалки объединённые в RAC. Она так по умолчанию идёт.

Не понял. Три физических сервера, а сколько виртуалок то на них? Три?

Минимум 3, это же очевидно
Ссылка на что? http://www.oracle.com/technetwork/datab ... 795225.pdf

[flip_flop]

Мне не осилить столько много букав. Но по поводу LPAR:
In first part of 2010 year, Fujitsu announced availability of its x86 64 PRIMEQUEST line of servers, which support LPARs.
In second part of 2011 year, Hitachi has announced availability of CB2000 and CB320 blade systems, which support LPAR on x86 64 hardware.

Другой вопрос- а так ли это критично/важно?
---
Общее впечатление о дискусссии от главного и единственного оппонента - "пора выходить из пещеры" и "перестать фантазировать" о х86. zVlad, ты только не обижайся, просто ты не в теме о х86.

Ответов от меня не будет до воскресенья.