Кластер из трёх ПК

Добрый день форумчане. Кто-нибудь собирал класстер? Можете посоветовать какой-нибудь вэб-сайт по руководству либо книжку.
Как я понимаю.
Они будут работать как одно целое так.
Три системных блока соеденнены кабелем витой пары через маршрутизатор либо коммутатор. Один монитор подключени только к одному системному блоку. Три одинаковые ОС.

0

Usaga, я просто предположил.

0

Всё упирается в то, что не может код исполняться в одном месте, а ОЗУ с данными в другом. Задержки по сети дают такую прибавку к пенсии... уменьшению производительности, что ну его нафиг И не может код один свой поток кинуть на один комп, 2 других на другой, а основная пачка потоков - на 3-м. Это только MPI делает и то для спецпрограмм.

0

Сообщение от Usaga специально для этого написанное ПО

Не понимаю как это ПО работать будет. Разделит задачи на три если три компьютера в класстере?

0

Да. Я так и писал, хоть я и не Усага

0

Ildar2026, просто так объединить три ПК, чтобы юзать их как один в угоду увеличения производительности, в Ваше случае, втрое - не получится. Объединить то Вы их объедините, но Ваш генератор паролей на этом кластере не взлетит, ибо, как сказали выше, запускаемый софт должен быть соответствующим, а именно, поддерживающий параллельные вычисления, например, рендеринг в 3D-программах (Blender, After Effects), научные вычисления (MATLAB, R, Python с библиотеками Dask, Ray), и т.п.
ПО для кластера:
BOINC — для распределенных вычислений.
Ansible или SaltStack — для управления множеством узлов.
Beowulf Cluster — популярное решение для HPC.
Более того, для производительного кластера старые машины, конфигурацию которых Вы указать не удосужились, явно не подойдут.
Из старого и маломощного железа единственный кластер, который рентабельно поднимать, это отказоустойчивый, пруфы указал выше.

1

Сообщение от Maks как один в угоду увеличения производительности,

Так-то иногда даже данные быстрее по сети влетают, чем с локального носителя.
Железный мозг примерно такое сравнение с SSD видит

Сводная таблица скоростей (от медленного к быстрому) Интерфейс / Кабель Скорость в битах Скорость в байтах (файлы) Сравнение с SSD SATA Сетевой кабель 1G (Gigabit) 1 Гбит/с ~115 МБ/с Медленнее в 4.5 раза Сетевой кабель 2.5G 2.5 Гбит/с ~290 МБ/с Медленнее в 2 раза Сетевой кабель 5G 5 Гбит/с ~570 МБ/с Примерно равны SSD SATA III (Накопитель) 6 Гбит/с (лимит) ~550 МБ/с (факт) Эталон Сетевой кабель 10G 10 Гбит/с ~1150 МБ/с Быстрее в 2 раза

1

Сообщение от ft4l Так-то иногда даже данные быстрее по сети влетают, чем с локального носителя

Производительность всегда упирается в самый слабый узел: летает по сети, значит, споткнется о скорость HDD, и наоборот, летает по SSD, упрется в скорость сетевого интерфейса.
Локалка на 10 Гбит/с имеет смысл при хорошо производительном рейд-массиве с соответствующими накопителями, СХД, или упомянутым выше высокопроизводительном кластере для какой-нибудь вычислительной программы.

1

Сообщение от Maks Python с библиотеками Dask

На пайтоне имеется возможность написать программу для параллельного вычисления.
То есть как я понимаю одну задачу одновременно параллельно, если 3 то на три поделется и будут вычислять?
Пример. crunch на линокс.
8 цифр сгенерировать.
на одном 3 цифры на другом 3 и на третьем 2 потом как это сложится и один файл получится с 8 цифрами.
1 комп 2 комп 3 комп
000 000 00 000 000 03 000 000 06
000 000 01 000 000 04 000 000 07
000 000 02 000 000 05 000 000 08
000 000 09 и так далее

Как то объеденить
И получится файл
С цифрами
00000001
00000002
00000003
00000004
00000005
00000006
И так далее.
То есть это пайтон как то может язык программирования.

0

Сообщение от Ildar2026 crunch на линокс

Вынужден Вас огорчить: утилита Crunch на Линукс (а не линокс) не поддерживает параллельные вычисления, а стало быть, положить на кластер Вы его не сможете.

0

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

Все верно, кроме вот этого.

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

Другое дело, что по итогам темы я совершенно уверен и в том, что ТС это не надо, и, увы, в том, что все равно не осилит.

0

Сообщение от ft4l Так-то иногда даже данные быстрее по сети влетают, чем с локального носителя. Железный мозг примерно такое сравнение с SSD видит

Проблема тут ещё и не в скорости как таковой, а в объёмах передаваемого и задержках. Речь же не о копировании файлов, а копировании ОЗУ! ЦПУ быстро работает только с ОЗУ, а если данные будут передаваться из ОЗУ одного ЦПУ в ОЗУ другого ЦПУ, то это катастрофа! Не даром же в ЦПУ уже 3 уровня кэша влепили, блок прогнозирования обращений уже превышает размером блок питания (шучу, конечно ). NUMA в SMP из-за этоже придумали - чтобы ЦПУ имел на СВОЕЙ шине СВОИ банки ОЗУ, а не соседа по материнской плате.

Тут только или планировщик процессы раскидывает по кластеру целиком или ПО отдаёт части вычислений опять же целиком, чтобы ОЗУ не гонялось туда-сюда.

1

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

0

Сообщение от kumehtar Сервер раскидывает по клиентам задачи

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

1

0

Сообщение от kumehtar Типо: на один комп вешаем сервер, к нему коннектим сколько там надо клиентов. Сервер раскидывает по клиентам задачи, получает результаты, собирает их в требуемый вид и выдаёт вам.

В этом случае получится кластер с единой точкой отказа в виде сервера, т.е. это классический вариант кластера "мастер‑слейв". Например, у меня в конторе собран кластер из трех серверов AD: один FSMO и два обычных AD - это вариант кластера "мульти-мастер", т.е. даже если хозяин схемы упадет (FSMO), то лес не рухнет и продолжит работать, правда в этом случае возникнет необходимость сделать захват ролей FSMO любым из двух оставшихся серверов, но всё же.

0

Maks, о да) Давайте нагонять жести)

Тот же RabbitMQ можно реплицировать, чтобы кворум был, если мастер рухнет. И повех ещё кубик накатать (Kubernetes) для большей красоты)

0

Usaga, всё зависит от софта, однако на практике я нередко сталкивался и продолжаю сталкиваться с ситуациями, когда мастер (сервер) какого-нибудь софта падает, а клиентские части кластера выдают только то, что у них сохранилось в буфере, на данный момент в администрируемой мною конторе так работает софт заказчика с СУБД PostgreSQL.

1

Сообщение от Maks я нередко сталкивался и продолжаю сталкиваться с ситуациями, когда мастер (сервер) какого-нибудь софта падает, а клиентские части кластера выдают только то, что у них сохранилось в буфере

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

0

kumehtar, логи тут непричем, в данном случае вопрос именно про реализацию, в том же мед.учреждении, тоде кластер, но если основной сервак, который установлен в другой локации, отваливается (например, из-за отключения интернета), всё, софт перестает работать, причем никаких ошибок, просто пустые значения в таблице. Ну ладно спец.софт, вернем к кластеру AD: FSMO находится в моей локации, если я переведу сервер AD в филиале, который находится в респ.Башкортостан, в RODC(только чтение), то при потере связи их сервак встанет колом, политики перестанут работать, нарушится доступ к сетевым шарам и т.п.

0

Сообщение от Maks логи тут непричем, в данном случае вопрос именно про реализацию

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

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

0