Как создать одну виртуальную машину использующую несколько серверов?

Question

[Дмитрий]

Начал разбираться с кластеризацией, но не могу найти нужную информацию. Везде пишется как создать кластер и поделить ресурсы одного "железного устройства" на несколько виртуальных машин, и при наличии дополнительного железа повысить отказоустойчивость. Но мне нужно наоборот. Есть два сервера по 16 ядер. Мне нужно на них создать одну виртуальную машину и условно в диспетчере задач увидеть 32 ядра, которые будут реальными (а не как в описаниях 64 виртуальных на 8 физических), и которые могут быть задействованы любым многопоточным приложением. Такое существует?
Вопрос о "накладных" расходах сейчас не вопрос. И вариант "ручной" отправки задач на отдельные узлы кластера не вариант.
Т.е. существует что-то вроде программной NUMA только не между процессорами, а между отдельными серверами?

Comments

[сергей кузьмин]

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

[Денис _______________]

Краткий ликбез что можно и нельзя
https://webznam.ru/blog/obedinit_dva_kompjutera/20...
По каждому возможному виду подзадачи придется искать ПО или писать ПО. Определенные вычисления дробить по разным ПК это возможно, но вот сделать универсальный ПК для любых задач из многих других - нельзя.

Answer 1

[rPman]

Виртуализация не позволяет объединять мощности!

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

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

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

Comments

[Дмитрий]

Пичалька.
Возможно вы знакомы с питоном и можете подсказать в какую сторону лучше копать для использования кластерных вычислений?
Хотелось бы не что-то "навороченное" и ультра функциональное, а что-то типа
- подключить ноду 1.2.3.
- запустить процедуру с таикм-то листом параметров задействую ноды.
что-то типа обычного Pool в мультипроцессинге, но с задействованием нод.
У меня просто время выполнения потока где-то 2-3 секунды и "накладные расходы" не сильно беспокоят.

[rPman]

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

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

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

Если же изначально правильно в базу писать сложно/лень, и привыкли плоские логи писать, или вообще в stdout печатать поток мыслей, то делайте это в каком либо машиночитаемой формате, хоть тот же json, его и человек поймет и анализировать скриптами проще чем разгребать просто текст

[Дмитрий]

Вопрос как раз в том, как проще разделить задачу, какими именно средствами, в моём случае в питоне.
Я надеялся, что возможно создавать какую-то виртуальную среду, которая способная объединять ресурсы... но к сожалению. После того, как вы меня "разочаровали"и покопав глубже в сторону кластерных вычислений понял, что меня спасёт только MPI4PY. Конечно, получается сложнее, чем я рассчитывал, но вроде не ужас-ужас. Будем курить мануалы. ))

[rPman]

Я не понимаю что тебе не понятно, не нужно никуда 'копать', никаких фреймворков не надо. Есть задача, она делится на части? Значит дели и запускай, например указав номер части задачи как аргумент к процессу. Запускай на разных нодах с помощью ssh

[Дмитрий]

Кто такой ssh? ))) ... шутка.
Мне нужно "разогнать" вычисления конкретно на питоне. У меня есть свободное "железо". Я надеялся, что это всё можно собрать влёгкую в одну виртуальную машину, но оказалось, что нет. Т.к. я жёстко привязан к питону, то мне определённо нужна библиотека, которая поддерживает распределённые вычисления. В частности это оказался mpi4py. Эта библиотека немного замороченная, и я думал вдруг вы знакомы с питоном и знаете более простой способ организовать на питоне распределённые вычисления. Похоже питон для вас это слишком "ламерское" и вы работаете более глобально, поэтому вопрос снимается. ))
Реально спасибо за первоначальный ответ.

[rPman]

Mpi, это фактически авторазворот циклов с копированием памяти туда сюда, без учёта специфики задачи.

Автоматизация маловероятно даст максимум Оптима... Будет много накладных расходов. Если готовы платить железом за 'лень разобраться', то почему нет

[Дмитрий]

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

[rPman]

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

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

Правильная реализация подразумевает контроль над тем, как делить задачу, какие данные на какие ноды заливать, как считать (считать можно распределив вычисление ОДНОЙ матрицы сразу на все ноды, либо, при наличии такой возможности от задачи, эта информация есть только у разработчика, ты попробуешь распределить вычисление заливая на каждую ноду свою матрицу)... скорее всего никакая автоматизация правильно это не сделает.

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

[Дмитрий]

Похоже вы не в курсе кто такой MPI. )) Это стандартизированный API для обмена данными в распределённых вычислениях. mpi4py это адаптация этого стандарта для питона. Его используют на суперкомпьютерах. В частности на "Ломоносов" и "Ломоносов2". Собственно на их примерах кода я и пытаюсь сейчас разобраться как оно работает.
И да, там можно как зафигачить всю матрицу на все ноды эхом, так и разделить её на части по количеству нод и разослать "кусочками", а потом так же из кусочков собрать целый ответ.
Так же у MPI есть и реализации для других языков программирования, в том числе и Си.

Answer 2

[Drno]

Нет.
Запускайте 2 копии процесса и разделяйте задачи