Система для распределенных вычислений

Вы когда-нибудь видели стойки серверов в крупных дата-центрах? Замечательное зрелище, правда? Прохладный воздух из промышленных вентиляторов, шум и жужжание процессоров и винчей на сотни, тысячи гигабайт памяти. Летом мне посчастливилось проходить практику в одном из таких дата-центров, в котором я занимался разработкой ПО для кластера. Дни шли, практика закончилась, руководители уехали, а идея осталась. Идея создания системы для распределенных вычислений на базе кластера.

Для начала, я полез в Google посмотреть, наверняка есть уже такие системы и я просто-напросто делаю велосипед. Оказывается в сети есть куча проектов, которые предлагают скачать свой клиент, поставить у себя на машине и вносить свой вклад в исследования внеземных цивилизаций, например. Но эти проекты мне не подходят. Я искал в свободном доступе инструмент с помощью которого было бы возможно запустить в локальной сети распределенную вычислительную сеть. Если Вы знаете где можно достать такой инструмент, или, вообще, знаете о таких разработках, поделитесь пожалуйста. Мне попалась одна такая система. Наши коллеги из МГУ создали Xcom. Если коротко, это система для решения распределенных задач с использованием локальной сети. Но она мне не понравилась, и я объясню почему. Во-первых она написана на Java, а Java это байт-код, мой руководитель хотел что бы система была с нативным кодом. Во-вторых и последних, а как же идея? Собственно на этом мои поиски и закончились. И было решено писать такую систему в рамках бакалаврской работы, часть которой уже написана.

Ниже я расскажу немного о том, из чего должна состоять такая система, на мой взгляд.

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

Так что если вы когда-нибудь захотите написать что-нибудь подобное смотрите через что Вам придется пройти.

1. Написание библиотеки
   • Протокол связи, это функции отвечающие за подключение клиентов к серверу, все что касается bind listen accept connect и т.д. должно находиться здесь.
   • Протокол обмена сообщениями, это то, что называется Messaging Layer на буржуйском. Тут мы оговариваем функции, которые описывают правила, по которым ведут диалог клиентское и серверное приложение.
   • Планировщик входных данных, нужно будет продумать и написать логику распределения данных по вычислительным узлам. И следить что бы были обработаны все данные. Тут возникает небольшая проблема, допустим у нас есть 10 подключенных вычислительных узлов все обрабатывают данные. Неожиданно 5 из этих узлов падают, свет допустим отрубили, нужно добиться того, чтобы данные, которые обрабатывали эти узлы, все равно прошли обработку на других узлах.
   • Планировщик выходных данных, тут нужно будет продумать в каком виде и как представлять результаты вычислений, ведь в зависимости от задачи и представление результатов может быть разным.
   • Клиентская часть, функция запуска клиента.
   • Серверная часть, функция запуска сервера.
2. Серверное приложение.
3. Клиентское приложение.

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