Computing power comparison: mainframe versus Intel Xeon

[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. Она так по умолчанию идёт.