Можно ли создать виртуальное ядро в Linux, если имеется кластер ARM?
К восьми портовому коммутатору я подключил 1 провод от роутера, 1 провод к ноутбуку, и 6 проводов к Orange Pi Zero Plus, на которых стоят процессоры Alwinner H5, 4 ядра по 1,44 ггц. Задаюсь вопросом о снятии нагрузки с ноутбука под управлением Linux. Когда речь заходит о кластеризации, то возникает вопрос, как перенести выполняющиеся задачи на эти микрокомпьютеры. Все сетевые интерфейсы 1Gb/s.
Я понимаю, что кластеры используют под определенные задачи, когда есть вебсервис, который много считает к примеру. Дело в том, что я не хочу привязывать ноутбук к одному месту. Но когда я дома - хочу подключать провод и снимать нагрузку с процессора, может быть с озу. Если научить linux обращаться по правильному адресу и перенаправить поток данных на обработку в кластер. Что выгоднее для процессора ноутбука, самому посчитать, или же передать на обработку в кластер. Я так подумал, у кластера получается 6*4=24 ядра по 1,44ггц, у моего ноутбука 2 ядра по 1,5ггц без Intel HT. Можно избавиться от тяжелых процессов если управлять задачами. К примеру мой локальный сервер видит нагрузку всех ARM linux'ов и запускает обработку на свободных. Но сделать это как - еще не понял. Хотелось бы понять, как линукс понимает что у него 2ядра, или 2 ядра и 4 потока, как он понимает, что у него 2 intel xeon на одной плате, можно ли в то же самое место монтировать ядра из ARM?
Мне очень интересно ваше мнение по этому поводу, буду рад любым идеям, что можно предпринять .
кластеризация на уровне ядра без поддержки со стороны приложения будет сложной и геморной. для домашнего ноута овчинка получится платиновой.
есть наработки в кластеризации на уровне програмного обспечения. это проще и ровнее. тот же distcc
Хотелось бы не ядро модифицировать, а программу ставить, что бы любой ноутбук так мог, если у него есть кластер)) Тема то интересная, согласитесь)
без поддержки со стороны приложения
Что значит со стороны? Можно одну машинку из кластера заставить мониторить остальных, и предоставлять сервис управления для ноутбука по локальной сети. Собственно саму программу поставить, которая будет ждать сигнала кластера. Когда он появится - отправлять задачи туда.
Проблема в том, что бы выдернуть из подсистемы задачи, подсистема ядра общается с пользователем, создает пространство ядра. Если ядро компилированное, то ядра не заложены в монолитном ядре. Они где то в конфиге подсистемы?
Вот и вопрос, подсунуть бы туда ядрышки от ARM под видом x86
Кластеризация - это весьма многообразная и нетривиальная наука. Если многопроцессорные/многоядерные системы уже стали банальностью - то кластеризация "ещё не устаканилась".
Есть вариант кластеризации, подражающий многопроцессорынм/многоядерным системам:
На каждом компьютере (компьютер при этом называется "нода", т.е. член кластера)) запущено своё собственное ядро с поддержкой кластеризации. Эти ядра регулярно обмениваются между собой на предмет сравнения очередей исполняемых задач (процессов). Если выясняется существенный дисбаланс приоритетов (это долго объяснять, пока пропустим подробности), то ядра затевают перенос задач с одной ноды на другую для выравнивания очередей. При этом надо перенести исполняемый код, данные задачи и управляющие структуры ядра, связанные с этой задачей (например, дескрипторы открытых файлов). Перенос задачи на новую ноду - это тяжёлая работа, так что её затевают если дисбаланс ну очень уж сильный. (Перенос задач между ядрами - тоже затевают пореже; там это проще, то тоже желательно делать это пореже.)
Перенос задачи на новую ноду возможен только если там одинаковые процессоры (либо - если код задачи интерпретируемый; например, байт-код JVM).
Как правило, многопоточные задачи не распределяют на несколько нод. Ибо потоки часто обмениваются данными через память - а синхронизировать память между нодами слишком дорого.
Но есть и иной тип кластеризации:
На каждой ноде есть программный код, откомпилированный под неё. Программа (которую компилировали под разные ноды) написана так, что она умеет связываться с копиями на остальных нодах (откуда она знает список нод - это вообще отдельная тема) и перераспределять работу. Т.е. исходная задача д.б. оформлена как обработка большого массива данных; причём данные разбиты на куски, которые можно обрабатывать независимо. И вот разные куски данных перераспределяются между нодами.
Например, брутфорс-подбор пароля - как раз такая задача, котрую можно раскидать на разные ноды с процессорами разных архитектур. Там вообще нет сложных потоков данных - есть огромный массив исходных данных в виде "все возможные пароли", и эти данные легко разделить на полностью независимые блоки.
Кажется, я достаточно загрузил Вас. Дальше разговаривать надо после того, как Вы уточните - что за тяжёлые задачи Вы хотите распараллелить.
Работать будет только на тех задачах которые вы реализуете.
Из описания вы хотите какой-то магии с разгрузкой ноута от его задач, так работать не будет.
Ядра с других машин нельзя никак "монтировать".
Кластер, это несколько машин объединенных одной задачей и ПО которое распределяет конкретную задачу.
Так же полезно будет знать следующую таблицу: https://gist.github.com/jboner/2841832
Issue, вам стоит изучить устройство ОС, возможно пройти курсы администраторов системы.
Так же следует ознакомится с кластерными решениями. Почитайте про galera, hadoop, spark, glusterfs.
Все ваши вопросы от незнания устройства системы.
>Если ничего не делать, то работать точно не будет.
Я бы сказал, это и не следует делать.
>Необходимо именно ядро? нельзя поставить какого нибудь демона, что бы команды ждал?
Это было ваша идея, все можно сделать, стоит ли овчинка выдели, вот главный вопрос.
>Да, у меня они объеденены одной задачей - распределить конкретно процессы по кластеру.
Тогда вы не верно сформулировали задачу и ваши пожелания или метод изложения запутывает читающего.
Конкретизируйте задачу.
Ну во-первых, 1,5ггц на х86 и 1,5ггц на arm - две большие разницы, х86 будет быстрее. Хотя на задачах, которые хорошо параллелятся действительно можно выиграть за счет суммарного количества ядер.
Во-вторых, даже если Вы придумаете как и напишите патч к ядру линукс, чтоб в определенных условиях некоторые процессы вместо запуска отправлялись по сети, то все равно, arm процессор не сможет выполнить код скомпилированный под x86_64.
Ну и немного чисто теории. Выдвину одну интересную гипотезу, проверять которую не рационально если сравнить трудозатраты и выхлоп.
Можно написать некий гипервизор, который будет работать на голом железе наших апельсинок (малинок, бананок) и предоставлять их ресурсы некоей сетевой виртуальной машине, которая работая одновременно на нескольких машинах будет виртуализировать их как одну многоядерную. В принцип даже можно будет эмулировать х86, хотя это будет довольно медленно, хотя может оказаться и вполне не заметно на фоне сетевых задержек при обращении в память.
А вот поверх этой виртуальной машины уже можно будет запустить хоть линукс, хоть фряху, и даже винду, если все же решим х86 эмулировать.
Можете проспонсировать сию теорию, найду ребят которые за годик другой реализуют прототип этой идеи.
даже если Вы придумаете как и напишите патч к ядру линукс
Значит нужен патч к ядру а не к подсистеме ядра?
чтоб в определенных условиях некоторые процессы вместо запуска отправлялись по сети
Если кластер подключен, то все задачи запускать распределенно, что бы задачи друг у друга ресурсы не забирали.
arm процессор не сможет выполнить код скомпилированный под x86_64.
Именно это я ихотел сформулировать)) Но что тут можно сделать?
найду ребят которые за годик другой реализуют прототип этой идеи.
Ребята не нужны. Мне интересно самому с этим поработать.
Можно написать некий гипервизор, который будет работать на голом железе наших апельсинок
Пожалуйста, расскажите подробнее, я не понял, как на голом железе. Имете ввиду gpio сообщение, или прошивку загрузчика, что бы сделать это одним устройством? Не понимаю пока что.
Ну в общем случае Вы тут одной подсистемой не отделаетесь, ибо помимо запуска и выполнения процессы еще и с окружающим миром взаимодействуют.
Если кластер подключен, то все задачи запускать распределенно, что бы задачи друг у друга ресурсы не забирали.
А по какому принципу будем распределять задачи? Тут нужно соблюсти баланс, чтоб и IPC не тормозило и все задачи на 1 инстанс не свалились.
Именно это я ихотел сформулировать)) Но что тут можно сделать?
Или транслировать код непосредственно перед запуском (что создаст доп нагрузку), или эмулировать другую архитектуру через виртуализацию (опять оверхед)
Ребята не нужны. Мне интересно самому с этим поработать.
Дерзайте. Только сначала еще много чего изучить придется.
Пожалуйста, расскажите подробнее, я не понял, как на голом железе. Имете ввиду gpio сообщение, или прошивку загрузчика, что бы сделать это одним устройством? Не понимаю пока что.
С d-bus, с файловой системой, с вводом-выводом, с другими процесами
по минимальной нагрузке на ядро или цп.
И как мы ее будем определять? Просто round-robin'ом раскидать процессы по инстансам не получится, тормоза от ожидания удаленных ресурсов перевесят выигрыш от распределенности
Allwinner H5 - 4-х ядерный 64-битный процессор. Можно ли использовать эти 64 бита?
Allwinner - это arm архитектура, Intel - x86, даже если оба 64 битные, набор команд, набор регитсров и еще куча всего отличается в корне. Да даже на базовом уровне, arm - это RISC, а x86 - CISC
Читая статьи наткнулся на hyper-v, а потом на xen - видимо он мне и нужен?
hyper-v - работает в ядре винды
xen - в ядре linux
1й точно нет, со вторым можно покопать в сторону работы с "сетевой vm"
в любом случаи, такие vm в готовом виде мне не известны, вероятно придется писать свою, что отнюдь не простая задача
