Эмуляция кластера на ПК

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

Будь мужиком, фигачь докер!

docker run --name ng10 -d -p 7000:80 nginx
docker run --name ng11 -d -p 7001:80 nginx

Здесь запускаются две виртуалки (контейнера) с nginx-ом. Можешь браузером зайти на 7000 и 7001, увидишь hello-world от nginx-а. Собственно, через -p перечисляешь маппинг портов «локальный—порт-на-виртуалке».

Залогиниться можно вот так

 sudo docker exec -i -t ng11 bash

Список контейнеров

docker ps

По этому списку можно найти имя (тот де самый ng11).

Я преследую следующее:

1. Узлы должны быть идентичны. Т.е. если я запускаю программу с 5 процессами, то время выполнения равно t, а если с 10 - t/2, 20 - t/4.
2. Мне нужен мониторинг ресурсов, как минимум время.

1. Узлы всё равно идентичными не будут, какие-то флуктуации производительности в реальности будут (сеть, загрузка, планировщик и т.п.). К слову, на многоядерном процессоре от MPI таки будет прок по производительности. 2. Время отмониторить можно и по отдельным процессам, память тоже.

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

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

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

Меня интересует тестирование производительности. Чтобы я мог запускать разные версии алгоритма, с разным кол-вом узлов и оценивать выхлоп.

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

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

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

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

Да, забыл добавить по теме. Вполне можно использовать контейнеры OpenVZ. Управление довольно простое. Подготовить дистр в контейнере со всеми нужностями вроде настроенного OpenMPI, например. Потом сохранить и запускать скриптом с указанием ip адресов. Получится такая виртуальная сеть из виртуалок. Есть возможность задать для узла внешне многие характеристики, в том числе ip. Что-то в духе (стырено с одного из множества руководств):

# vzctl set 103 --onboot yes --save # добавляем контейнер в автозагрузку после старта хост-системы
# vzctl set 103 --hostname debian7.example.com - save # задаем хостнейм
# vzctl set 103 --save --ipadd 192.168.1.31 # назначаем IP , установка VENET - соединения
# vzctl set 103 --save --nameserver 8.8.8.8 -nameserver 8.8.4.4 # описываем DNS - сервера
# vzctl set 103 --save --cpus 4 # кол-во cpu-ядер
# vzctl set 103 --save --ram 8G # RAM
# vzctl set 103 --save --swap 4G # swap
# vzctl set 103 --save --diskspace 100G # задание размера диска
# vzctl start 103 # запускаем контейнер
# vzctl exec 103 passwd # устанавливаем пароль root-пользователю