Как стать автором
Обновить

Телепортируем процесс на другой компьютер! 

Время на прочтение 12 мин
Количество просмотров 14K
Всего голосов 53: ↑53 и ↓0 +53
Комментарии 12

Комментарии 12

Вспоминается ныне мертвое решение Kerrighed — это как раз запуск одного линукса сразу на кластере из N писюков, соединенных по Ethernet

Обратите внимание. по ETHERNET. Ради устранения задержек, ребята весь IP стек выкинули к такой-то матери.

Никакого UDP, Кармак вас упаси. Только RDMA, только хардкор.

Теперь о проблемах. Если взять суровую монолитную вычислительную программу, которая написана под многопоточку (я брал традиционный LAPACK и считал GMRES) на одной машине и попытаться запустить ее вот на таком чуде (делал такие опыты с kerrighed), то задержки в канале связи (особенно, если это не InfiniBand или PCI-E) убьют, к сожалению все удовольствие.

В то же время, программа, написанная с учетом топологии кластера (OpenMP + OpenMPI) работала быстрее — просто потому, что разработчик знал, когда у него данные близко, а когда — на кудыкиных горах.

Иниересно, а попробовать завести это все на 10G Ethernet…
Вообще, учитывая что у нас есть сегодня — сомнительная штуковина. Есть уже и процы на кучи потоков, и памяти можно очень много — мы научились размазывать по контейнерам нагрузку…
Может быть интересно только как бюджетное решение на старом хламе которого с избытком завалялось, но нужно код приложения переписывать...

ЕМНИП, для подобных задач 10G это "фу, кака". В кластерах под вычисления используют инфинибенд ради сильно меньшего летенси.

Я примерно о том же и писал — с 2010 мы ушли далеко.
Но, если брать проект "как есть" — он заточен под Ethernet (см выше) и логично попробовать его на более быстром варианте последнего.


А так, да — инфиник, бездисковые ноды или оркестрация уже давно заняли нишу.

Я, к сожалению, довольно далек от системного программирования. Поэтому, не могли бы вы объяснить что там происходит с памятью? В случае локального fork() все «просто» за счет copy-on-write. А если процесс только что загрузил в память полтора гига какой-нибудь модели для обсчета? Мы гоним все это по сети на другой сервер? А в случае кластера — на кучу других серверов? Еще и по UDP?

Черт, это перевод… Я поначалу подумал что это автор пишет…
Я не мог понять, почему она такая глупая и простая, намного проще, чем любой API для удалённой работы, и почему компьютерные системы, кажется, не способны на такое.

Никто этого еще не придумал потому что задача по сложности эквивалентна синхронизации состояния в распределенных базах данных (а это просто огромная и сложная область да еще с кучей фундаментальных ограничений). Вот как вы собрались работать с шаред-состоянием в этих телепроцессах на разных машинах? У вас не то что там проблемы с многопоточностью как в обычных потоках — у вас появятся куда более серьезные проблемы консистентности из-за того что будет отсутствовать даже банальный атомарный бродкаст (который уже обеспечивается кеш-когерентностью самого процессора фундаментально упрощая проблемы многопоточного программирования). В итоге вам придется начинать все с нуля и алгоритмов вроде paxos-а или raft-а и погрузиться во все тяжкие распределенных систем и транзакционности.

Кстати, примерно так работает YT в Яндексе :)

Уважаю.


Самое интересное в этой теме — как CRIU что-то делает на стороне сохраняемого процесса. ptrace? Нет, медленно, неудобно. Они через ptrace подкладывают в процесс паразита (так в коде и называется), который слушает сокет и выполняет команды из него. А он уже что угодно делает.

Когда-то, давным-давно, использовали dcc, дистанционній cc, когла компы были слабые, и обновить на генту файерфокс было задачей на несколько часов (компиляция) был изобретен dcc, суть в том что добавлешь список IP (естественно надо было еще настроить доступ) и на удаленном компе компилировалось часть исходников, разпаралеливая процесс.

Чем то напомнило )

Criu звучит круто, но по факту оно не работает. По крайней мере на чем-то более-менее серьезном.
Это очень крутой пример того, что могут (могли) ребята из Виртуоззо. Но точно не надо тащить в прод

Ну хорошо бы еще, чтобы ЯП и компилятор был задизайнен под такую среду. Возможно какие-нибудь виртуальные потоки с более высокоуровневыми состояниями.
Мне кажется, что автору было бы проще реализовать миграцию процесса туда-сюда вместо fork().
Зарегистрируйтесь на Хабре , чтобы оставить комментарий