Ещё одна священная война: mainframes vs x86 servers

[KP580BE51]

в то же время легко заметить что Intel/AMD постоянно что-то делают революционное

Постоянно это как часто?
Назовите несколько примеров.

AMD - Гипертранспорт. Ну и вообще - PCI-E, SATA итд.

[Flash-04]

1. 386, Pentium, Core 2
2. PCI, Express
3. x64 (тут AMD был первым)
и т.д.

[flip_flop]

Виртуализация была последним большим преимуществом МФ перед х86/х64 серверс.

Вперед в прошлое - какая виртуализация (в каком контексте) снимает это преимущество МФ?

Сборник вопросов от чайника в виртуализации:

I Виртуализация со стороны пользователя
1) Многозадачность - почему недостаточно просто ее ?
2) Наличие нескольких образов одной и тоже ОС - надо ли и насколько важно?
3) Наличие нескольких разных ОС - насколько важно в контексте главного вопроса о "добивании МФ" (как пользователь лаптопа я бы хотел полноценного эффективного использования паралельно Линукса и Виндовса - тут нер вопросов)

II Виртуализация ресурсов ИО
4) представление физического интерфейса ИО его виртуальным образом (как для агрегации /много физических в один виртуальный/ так и для расшаривания /один физический в много виртуальных/) - насколько важно ?
5) виртуальная подмена одного типа ИО другим типом ИО (подстройка универсального физического ИО под разные виртуальные ИО) - насколько важно в контексте общей победы?

[Flash-04]

I Виртуализация со стороны пользователя
1) Многозадачность - почему недостаточно просто ее ?

я вижу только одну причину - практика показала что безопасность предоставляемая Unix/Windows (а это основная часть серверов доступная наружу) недостаточна. Если происходит вторжение хакера на сервер (особенно с правами админа) то все до чего дотянулся - его. Поэтому имеет смысл разнести критично важные приложения (SQL и Web сервер) на разные физические сервера. То же самое можно получить используя виртуальные серверы.

[oshibka_residenta]

Сейчас есть отдельно память, отдельно процы. А что если делать их вместе в виде таких active cells: проц, небольшая память она же кеш, + энергонезависимая копия той же памяти

Во-первых: идеи чего-то "небольшого" обычно быстро загибаются. Помните NetPC with 8MB memory, в которые так и не влез Corel Office?
Зачем искусственно ограничивать размер памяти, когда она дешевле грязи узге? В чём проблема "Большой" памяти?

Такие cells объединяются в гриды с миллионами элементов и неким аналогом общей шины.
...
Команда идет на все процы такой базы. Осталось подождать пару миллисекунд, какой проц поднимет руку - я нашел

Вот здесь неписано как все организовать, чтобы такой select работал
http://www.usenix.org/publications/libr ... n/dean.pdf

По поводу физического соединения ето, насколько я понимаю, глядя на Goole jobs hardware, будет/есть switched fiberoptics network. В ближайшем будущем на дешевых 10G оптических компонентах и собственной разработки switches.

[Palych]

Сейчас есть отдельно память, отдельно процы. А что если делать их вместе в виде таких active cells: проц, небольшая память она же кеш, + энергонезависимая копия той же памяти

Во-первых: идеи чего-то "небольшого" обычно быстро загибаются. Помните NetPC with 8MB memory, в которые так и не влез Corel Office?
Зачем искусственно ограничивать размер памяти, когда она дешевле грязи узге? В чём проблема "Большой" памяти?

Все относительно. Процессор - 10 баксов. Гигабайт памяти - 50 баксов. + ?? баксов флеш на гиг. Итого получаем баксов за 200 модуль. (что-то дорого получилось)
Берем 100 таких модулей, получаем такой вот карманный суперкомпютер, который сможет провести банальный и тупой поиск в 200 гигабайтах память за
1*2^30/(100*10^6)/4=2.684секунды

Если цель - перебрать память, тогда нет вопросов.
А сесли - найти данные, тогда:
- Что если искомый кусок не помещается в модуль?
- Что если он чуть больше половины памяти модуля? Оставим половины памяти неиспользуемой?

Во-вторых: Каким образом будем физически соединять миллионы элементов?

Звездой?

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

В третьих - как быть с разными хитрыми update?

Ну уж это совсем легко делается.

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

[KP580BE51]

Если цель - перебрать память, тогда нет вопросов.
А сесли - найти данные, тогда:
- Что если искомый кусок не помещается в модуль?
- Что если он чуть больше половины памяти модуля? Оставим половины памяти неиспользуемой?

Как обычно. Хеши итд.

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

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

[zVlad]

Виртуализация была последним большим преимуществом МФ перед х86/х64 серверс.

Вперед в прошлое - какая виртуализация (в каком контексте) снимает это преимущество МФ?

Сборник вопросов от чайника в виртуализации:

....

Порой на вопросы чайников оветить бывает сложно. Лучше когда чайник хоть какое-то представление о предмете уже имеет и задает релевантные вопросы.

Представьте себе любое реальное устройство, например, броненосец "Потемкин". И теперь представьте себе что мы можем создавать некие модели броненосца, которые не только могут сообщать нам образ реального броненосца, но и как настоящий броненосец могут вращать винтами, и стрелять из пушек. На количество моделей ограничений нет, но вот сумарная их мощность не может превышать мощность реального броненосца.
Примерно так в первом приближении и следует воспринимать виртуализацию реального компьютера - как создание набора действующих функциональных аналогов, на каждом из которых можно выполнять какую угодно ОС этого же реального компьютера. ОСы виртуальных машин при этом остаются реальными, в большинстве случаев даже не "чуствующие" что они на ВМ, а не на реальном компьютере. Точнее они как раз на реальном компьютере и выполняются, просто в некоторые моменты их выполнение прерывается и некоторые фуенкции реального компьютера эмулируются программно.

[KP580BE51]

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

Притянуто за уши: в то время как один виртуальный броненосец может стоять в сухом доке. другой вполне может палить из пушек во всю мощь реального сервера.

[zVlad]

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

Притянуто за уши: в то время как один виртуальный броненосец может стоять в сухом доке. другой вполне может палить из пушек во всю мощь реального сервера.

Зачем же сразу ругаться? Именно так оно и есть. Более того любой виртуальный броненосец (ВБ) может пулять из любой пушки реального, но в одно и тоже время может пулять из одной и той же пушки только один ВБ.
У реального броненосца может быть несколько винтов, ВБ делять винты таким образом что, например, конкретный винт делает несколько оборотов для одного ВБ, затем для другого и т.д..

[zVlad]

А вот у меня такой вопрос есть к архитектуре сервера на базе x86. Возможно ли чтобы у разных виртуальных адресных пространств были такие страницы, или сегменты памяти, которые бы отображались на одни и те же физические страницы (сегменты).
Только пожалуйста не говорите просто "да, имеется" (если конечно имеется. Дайте свое понимание этого механизма.
В системах на МФ (в z/OS или z/VM) это широко используется когда участки виртуальной памяти разных процессос (ВМ) на самом деле представленны одной и той же физической копией.

[flip_flop]

Виртуализация была последним большим преимуществом МФ перед х86/х64 серверс.

Вперед в прошлое - какая виртуализация (в каком контексте) снимает это преимущество МФ?

Сборник вопросов от чайника в виртуализации:

....

Порой на вопросы чайников оветить бывает сложно. Лучше когда чайник хоть какое-то представление о предмете уже имеет и задает релевантные вопросы.

А просто ответить на вопросы нельзя? Вместо сентенций и обычных упреков в такой чайниковости что дальше некуда

Вопросы по виртуализации ИО (в контексте виртуализации ресурсов, не ВМ) Вы тоже считаете нерелевантными? Что-то меня самого гложат смутные сомнения о компетентности самопровозглашенных мудрых гуру от МФ...

dB13 - может ответите по делу?

Последую я мудрому (по настоящему мудрому) примеру Тенгиза, пожалуй ...

[KP580BE51]

А вот у меня такой вопрос есть к архитектуре сервера на базе x86. Возможно ли чтобы у разных виртуальных адресных пространств были такие страницы, или сегменты памяти, которые бы отображались на одни и те же физические страницы (сегменты).
Только пожалуйста не говорите просто "да, имеется" (если конечно имеется. Дайте свое понимание этого механизма.
В системах на МФ (в z/OS или z/VM) это широко используется когда участки виртуальной памяти разных процессос (ВМ) на самом деле представленны одной и той же физической копией.

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

[zVlad]

Виртуализация была последним большим преимуществом МФ перед х86/х64 серверс.

Вперед в прошлое - какая виртуализация (в каком контексте) снимает это преимущество МФ?

Сборник вопросов от чайника в виртуализации:

....

Порой на вопросы чайников оветить бывает сложно. Лучше когда чайник хоть какое-то представление о предмете уже имеет и задает релевантные вопросы.

А просто ответить на вопросы нельзя? Вместо сентенций и обычных упреков в такой чайниковости что дальше некуда

Вопросы по виртуализации ИО (в контексте виртуализации ресурсов, не ВМ) Вы тоже считаете нерелевантными? Что-то меня самого гложат смутные сомнения о компетентности самопровозглашенных мудрых гуру от МФ...

dB13 - может ответите по делу?

Последую я мудрому (по настоящему мудрому) примеру Тенгиза, пожалуй ...

Да Вы не обижайтесь. Вовсе не все вопросы заданые Вами так уж трудны для ответа. Скорее они сформулированны не в терминологии и принципов виртуализации. Поэтому и не легко на них отвечать. Тем более кликая по клавиатуре. Вот если бы это была настоящая беседа. Но ведь и тогда любой на моем месте попытался бы дать введение в тему. Может уже введение ответило бы на часть вопров.
Кстати (перечив снова Ваши вопросы), Вы практически в каждом вопросе спрашиваете "насколько это важно?" Но ведь это, виртуализация, не просто так высосана из пальца, ведь были какаие задачи потребности для удовлетворения которых и была "придумана" виртуализация. Как можно ответить насколько это важно не говоря о целях виртуализации?

[zVlad]

А вот у меня такой вопрос есть к архитектуре сервера на базе x86. Возможно ли чтобы у разных виртуальных адресных пространств были такие страницы, или сегменты памяти, которые бы отображались на одни и те же физические страницы (сегменты).
Только пожалуйста не говорите просто "да, имеется" (если конечно имеется. Дайте свое понимание этого механизма.
В системах на МФ (в z/OS или z/VM) это широко используется когда участки виртуальной памяти разных процессос (ВМ) на самом деле представленны одной и той же физической копией.

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

Вот такие ответы меня как раз и не устраивают. Под таким "тоже самое" могут на самом деле скрываться совершенно разные вещи. У меня сейчас нет времени писать как это делается на МФ. Вот если бы Вы добавили несколько фраз о том как это делается на x86, то это было бы здорово.