Виртуализация в другую сторону

запускать одну ОС на нескольких хостах

Сама ОС ничего не делает, просто управляет программами и предоставляет им интерфейс к устройствам, так что запускать ее на нескольких хостах смысла нет.

Все суперкомпьютеры так и работают. Когда у тебя несколько десятков тысяч процессоров, хочешь, не хочешь, а придётся их разносить на разные хосты и соединять потом какой-то матерью. А ОС при этом одна.

В принципе нет. ОС на каждом узле суперкомпьютера будет своя. И на каждом узле запущено некоторое ПО, которое уже объединяется некоторым способом для обработки данных.

Очень тяжело сохранить привычные абстракции (потоки, виртуальную память), если часть процесса живёт прямо здесь, а за другой частью нужно стучаться по сети с на много порядков более высокими временами задержки. Видели, как работает система, если забить всю память и залезть в swap?

Попробуйте почитать про Parallel Virtual Machine и Message Passing Interface. Как видите, распределённые программы пишут таким образом, чтобы их части явно обменивались данными.

Начни свой путь с лёгкого гуглинга, вот тебе аббревиатура для затравки: numa

В принципе нет. ОС на каждом узле суперкомпьютера будет своя. И на каждом узле запущено некоторое ПО, которое уже объединяется некоторым способом для обработки данных.

В принципе да. На каждом узле запускается базовая ОС, поверх которой запускается уже кластерная ОС. Кластерная не занимается настройкой сети и чтением SMART, базовая не занимается распределением нагрузки.

Например, в суперкомпьютерах «Ломоносов» и «Ломоносов-2» использовалась/зуется базовая ОС CentOS, а кластерная Clusterx (на базе всё той же CentOS).

Но главное — с точки зрения процесса, запущенного на кластере, все несколько тысяч процессоров управляются одной ОС.

запускать одну ОС на нескольких хостах

ты хотел сказать 1 программу на неск хостах, зачем ось то?

это называется кластер, есть всякие планировщики задач, но и софтину придется под это переписать

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

Я запускал HPC кластер для Ansys, там был свой планировщик из состава Ansys (MPİ). Механика такая: на рабочей станции в Ansys открывается проект, идёт подключение к управляющему сервису, он получае задание на рассчет, раскидывает его части по узлам HPC кластера, запуская решатель на каждом отдельном узле, в каждой конкретной ОС со своей порцией данных. Этот решатель отдает статус и результат в сервис Ansys. По завершению рассчета в Ansys на рабочей станции можно увидеть результат.

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

Т.е. технически это все разные узлы и разные ОС, на которые специальным планировщиком и в специальном ПО раскидывается части данных для обработки.

Т.е. ClusterX - по сути технология распределения вычислительной задачи и ее данных, а не операционная система.

Не путай, пожалуйста.

Обмен идёт по сети.

Как ты это себе представляешь?

Самое главное свойство программ, запущенных на одной машине - общая память. Без общей памяти 100 экземпляров программ на одной машине с х100 производительностью CPU не имеют никакой возможности отличить ситуацию от случая 100 машин исполняющих по 1 экземпляру этих программ с х1 производительностью.

Память бывает энергонезависимая и оперативная.

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

А вот энергонезависимой памятью засада. Она слишком быстрая. У DDR4 скорость 20-25 ГБит/сек. Типичная материнка имеет сетевую карту, работающую на скорости 1 ГБит/сек. Допустим, ты заморочился и обзавёлся 10 ГБит сетевой картой. Это всё ещё в 2 раза меньше.

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

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

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

Короче, это будет адски тормозить, поэтому НЕ НУЖНО.

Тем не менее, многие пытались.

9p

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

Там не будет shared memory в прямом смысле, там скорее будут очереди сообщений и другие подобные штуки, которые уже кластерная ОС будет реализовывать и при необходимости гонять данные по сети. Если в такой ОС будет аналог семафора, он будет гораздо более дорогим нежели в обычной ОС и приложениям будет рекомендоваться обходиться без них по возможности.

И программы будут писаться так, чтобы они могли обрабатывать чанки данных с минимальным обменом между потоками обработки, а потом собирать результат. Это будут не те программы, которые запускаются на одном (пусть даже очень мощном) компьютере.

Я запускал HPC кластер для Ansys, там был свой планировщик из состава Ansys (MPİ).

Ты запускал специализированный кластер. Я также запускал кластер блендера на двенадцати компьютерах по той же схеме — блендер сам себе планировщик.

Но это не будет работать в кластере общего назначения.

Нет никакой отдельной ClusterX операционной системы.

Ну вот, ж*** есть, а слова нету.

Не путай, пожалуйста.

Это ты не путай.

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

В наше время был OpenMPI, но я в написании софта не силён. И да, под суперкомпьютер пишут по-другому.

Считай как хочешь.

неа, это маловозможно, ибо не выгодно. и потому такое не делають. ибо IPC процессов, распиленной на несколько хостов будет очень долгой. поэтому не выгодно.
только одна машина, даже на кучу железных процов ито есть мудреж с NUMA-оптимизацией.
возможен запуск запуск процессов паралельного вычисления на множестве хостов, типа BOINC, но там расчеты сразу предполагают что процессы оторваны друг друга и меж ними будет долгое общения.

Гугли ScaleMP vSMP

ОС – это программный комплекс, предназначенный для абстрагирования пользователя и устройств от конкретных реализаций оборудования. Но технически, в действительности компьютер состоит из нескольких компьютеров, каждый из которых работает автономно, имея связь через различные шины и общую память. Разница в том, что эти компьютеры узкоспециализированные, они не имеют ОС в классическом виде, и выполняют они какую-то одну (как правило) задачу, будь то (де)кодирование звука и изображения или хранение данных на каком-то носителе, или передача данных по какому-то интерфейсу.

Раньше такие ОС были, но популярности не получили.

Из современных проектов в каком-то смысле это делает Kubernetes. Это, конечно, не ОС в классическом её понимании, но общие черты найти можно.

Clusterx

это врятли правомерно называть осью.

запущенных на одной машине - общая память.

Память то общая, но на больших то компах NUMA. А потом в теории может быть и non-cache cohenrent NUMA...

У DDR4 скорость 20-25 ГБит/сек.

Байт/с, к памяти ещё параллельный интерфейс, её скорость в байт в секунду измеряют.

Допустим, ты заморочился и обзавёлся 10 ГБит сетевой картой.

Это несерьёзно! (C), по PCIe нужно соединять, компы же в одной стойке. Вот, допустим, что сейчас можно https://elcomdesign.ru/processors/ispolzuem-ves-potenczial-gpudirect-storage-... осталось научить, чтобы комп часть своих PCIe устройств другом компу передавал :)

То существуют ли проекты, которые позволяют запускать одну ОС на нескольких хостах? Т.е. такая своеобразная виртуализация в другую сторону.

Да. Это называется кластером. Но на каждом узле работает своя ос, а объединяет всё в один мега компьютер система управления кластером.

То существуют ли проекты, которые позволяют запускать одну ОС на нескольких хостах?

Да, есть такие. Последним, с которым мне довелось работать был проект компании Emu Technologies с их thread migration. Они на грани выживания. До них такие машины развивала SGI.

А то, что люди про кластеры пишут, это вообще не об этом. Каждый узел кластера работает под управлением своего OS образа. MPI не помогает разделять ресурсы, он просто передаёт данные от процесса процессу.

Но главное — с точки зрения процесса, запущенного на кластере, все несколько тысяч процессоров управляются одной ОС.

Это не так. Прежде всего каждый процесс привязан к набору процессоров, на котором он выполняется. Мы называем эту привязку CPU affinity. Процессоры всегда принадлежат одному узлу кластера, а не любому узлу.

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

если же имеется в виду как бы «общая память» и «вычислительный ресурс», то в простом варианте такого естественно нет, т.к. это достаточно сложная и проблемная инженерная задача.

на самом деле чаще такую проблематику решают по-другому: подкачка (VSS), деление задачи на последовательно выполняемые шаги, входящие в доступную память и т.д.

откуда вообще взялся такой вопрос? какова задача?

ну тогда уж OpenStack пишите - оно реально может двигать приложения по узлам.

Я выше писал про ScaleMP vSMP, так что про «естественно нет», это ты зря.

Когда-то давно, в двухтысячных оно было. И считалось революционным.

Даже на ЛОР’е про это тред был: vSMP

А потом оказалось, что проще накодить кучу микросервисов, и размазать их по хостам.

ты если цитиурешь, то делай это с сохранением смысла (контекста). а то вырвал из него и получилось что типа я дурачок.

смотри как было у меня:
«то в простом варианте такого естественно нет, т.к. это достаточно сложная и проблемная инженерная задача.»

понимаешь? «в простом варианте»! чел наверняка что-то местечковое имеет в виду, желательно даже без 802.3ae, а ты ему IB внедрять предлагаешь ;-)

В IB нет ничего страшного. Он проще, чем FC.

Карточки копейки стоят, два хоста соединить по IB - вполне местечково.

Оно просто нафиг ненужно. Объединять память и ядра с разных физических машин в одну виртуальную ни разу не выгодно - слишком медленно. По той же причине отпадает прозрачное перемещение запущенных программ между физическими машинами. Эксперименты по разделяемыми между машинами виртуальными страницами памяти, для обмена данными, если ничего не путаю, проводились, но приемуществ, по сравнение с обычным маршалингом и обменом данными по сети не дали. Потому даже если разными машинами будет управлять одна «виртуальная» ос распределённая на разных машинах, то весть обмен данными всё равно будет по сети, а такая ОС просто дополнительно возьмёт на себя лишние обязанности оркестратора, и, вероятно, брокера сообщений. В общем, совершенно бесперспективная и бессмысленная затея…

Интересно, MOSIX в каком-нибудь виде ещё жив?

Я себе это представляю примерно как кубер.

Только вместо оперирования образами oci, можно оперировать наборами syscall, из которых состоят все программы userspace. Таким образом можно было бы запускать несколько экземпляров приложений, на нескольких хостах, маштабироваться, мигрировать и т.п. Понятно что не все задачи подходят под такое использование. Но всё равно это было бы круто.

Жаль что подобных проектов нет в открытом доступе…

«TidalScale — гипервизор наоборот: 16 Тбайт RAM ещё не предел»
https://servernews.ru/1008453