Как собрать кластер из компьютеров
Обновлено: 03.07.2024
В общем, друзья, подумал я тут намедни: а что это у меня старый системник стоит, пыль собирает? А не задействовать ли его ресуры во благо великих свершений и не объединить ли его с ноутбуком в один чудесный, прекрасный. кластер?!
Идея странная, но по-своему завораживающая: это ж если научиться вот так спокойно (или относительно спокойно) соединять несколько компов, да не простой сетью локальной, а превращая их в гибриды, превосходящие по производительности каждый из отдельно взятых компонентов системы, можно добиться превосходной эффективности, запуская "тяжеленные" программы и выполняя обширнейшие вычисления.
Конечно, подобные вещи давно практикуются в различных институтах и лабораториях, но идея иметь аналогичную технику дома кажется безумно притягательной. На этом основании вопрос - есть ли среди форумчан люди, могущие подсказать или желающие принять некоторое участие в этой затее? Составленную в результате эксперимента инструкцию можно будет прилепить на сайт, и тогда любой киберпанк исполнит свое домашнее компьютерное извращение.
Кстати сказать, отыскались первые, так сказать, источники (если кому-то будет интересно):
Не уверен, но может возникнуть такая проблема как конфликт железа. железячники не рекомендуют совмещать даже две плашки оперативной памяти разных фирм-производителей. Для кластеров, обычно, используется совместимое железно, дабы не было глюков и можно было достичь максимального быстродействия. Но, в целом-то, я в этом не разбираюсь, так что могу быть не правым в этом вопросе, да. Хотя я совсем в этом не понимаю. Не уверен, но может возникнуть такая проблема как конфликт железа. железячники не рекомендуют совмещать даже две плашки оперативной памяти разных фирм-производителей. Для кластеров, обычно, используется совместимое железно, дабы не было глюков и можно было достичь максимального быстродействия. Но, в целом-то, я в этом не разбираюсь, так что могу быть не правым в этом вопросе, да. Хотя я совсем в этом не понимаю.Дело в том, что по первой из прилепленных выше ссылок довольно сильно обнадежили:
" Сразу скажу, что кластер Beowulf - гетерогенная структура. В него могут входить самые разнообазные по параметрам компьютеры, построенные на различных аппаратных платформах, например Intel Pentium различных версий, Alpha, RISC-процессоры, Transmeta, 32-х и 64-х битовые процессоры. Более того, на компьютерах в кластере могут быть установлены самые различные системы: Linux, Windows, OS/2 WARP. Нашей целью будет построение кластера с минимальными усилиями. Поэтому, если вы хотите заниматься делом (сиречь научной работой), а не повышать свой профессионализм в области информационных технологий, о возможной гетерогенности кластера я предлагаю забыть. Будем считать, что аппаратная платформа комьютеров нашего будущего кластера однообразна.
Что касается различия в параметрах (быстродействие, память, . ) у компьютеров, входящих в кластер, то это допустимо. Но в этом случае, вам придется учитывать эти различия при написании параллельных программ, распределяя объем счета в зависимости от возможности каждого отдельного компьютера. В противном случае кластер будет работать как система, состоящая из машин с минимальными рабочими параметрами".
Но замечание насчет железа кажется мне очень разумным - я надеюсь, что авторы того сайта еще вернутся к этому вопросу.
Хар-ки компьютеров:
2.40 Ghz | 2.27 Ghz - оба двухядерные, от intel
4 Gb RAM- одинаково
512 Mb GPU - одинаково, от nvidia
Dell|Asus
Для того, для чего вы хотите - никак не создать.
Кластер - это даже согласно статье из Википедии, которую вы приводите - это слабо связанная вычислительная система.
Попробую объяснить, используя аналогию.
Вы считаете, что компьютеры можно объединять также, как можно объединять усилия людей, наполняющих бочку водой, таская ее ведрами. Один человек наполнит за час, два - за полчаса, и так далее. Но это процесс, который распараллеливается элементарно.
А на самом деле, кластер работает подобно команде сценаристов, которые пишут сценарий сериала из двадцати серий, работая удаленно по бумажной почте: сначала главный сценарист придумывает персонажей и общий сюжет, записывает это, потом ему нужно разбить его на серии и отослать каждому из сценаристов, указав, какую серию тому нужно прописать в подробностях. Если бы он писал все сам, ему бы понадобилось по неделе на серию, итого - двадцать недель. А съемки можно начинать, когда готова первая серия (через неделю). Поскольку съемки одной серии занимают три дня, съемочная группа будет простаивать четыре дня из каждой недели, пока не будет готова следующая серия (деньги во время простоя тоже расходуются, хотя ничего не производится). Съемки будут, таким образом, завершены через 20*7+3=143 дня.
Наемным сценаристам тоже нужно по неделе на написании серий, но начальная работа главного сценариста тоже занимает неделю, плюс - три дня на доставку "каркаса сценария" наемным сценаристам, три дня на доставку сценария серий обратно, еще пять дней на проверку и исправление нестыковок. Итог - начинать съемки можно только через 25 дней, а не через семь, но продолжать их можно уже непрерывно. Съемки будут завершены через 25+3*20=85 дней.
Ровно как здесь нельзя ускорить процесс еще больше, заставив больше сценаристов писать по половине серии (потому что при этом растет сложность стыковки кусков сюжета, которые написаны разными людьми, потому им придется переписываться, теряя время), так и пытаясь запустить на кластере условную игру, придется просадить кучу времени на медленное общение узлов между собой по сети.
Чтобы всё "летало" в реальном времени в игре, вам нужен один мощный компьютер с многоядерным процессором, мощной видеокартой и быстрой шиной, которая всех их объединяет. А собрать кластер из сотни древних ноутов на медленном Ethernet и получить производительность в сто раз больше в играх - это фантастика из дурацких фильмов про хакеров.
Если у вас есть 32 старых однопроцессорных компьютера, нужно лишь найти способ, как заставить их работать сообща. Другими словами — собрать из них кластер. Да, у них всего по одному процессорному ядру, но все вместе они смогут сделать больше, чем одна двухъядерная машина. Как это сделать, рассказано в статье Т. Лемана (Tom Lehmann) «Как создать высокопроизводительный вычислительный кластер на Linux». В статье приведен обзор пакета Rocks — Linux-дистрибутива для развертывания, управления и поддержки высокопроизводительного вычислительного кластера.
> но все вместе они смогут сделать больше, чем одна двухъядерная машина
проще сдать весь этот хлам на металлолом и купить четырехъядерную машину
>Если у вас есть 32 старых однопроцессорных компьютера
А я-то думал куда мне деть мои 32 старых компа.
Т.е. 32 компа немногим лучше, чем одна двухядерная машина?
> Т.е. 32 компа немногим лучше, чем одна двухядерная машина?
Скорее хуже, если нет своей АЭС.
/me пошел делать кластер из 133 и 166 машинок
у нас в европе элекричество дорогое. так что лесом эту хрень
лучше купить один мощный комп.
А счет за киловатт-часы кто будет оплачивать?
Это развёртывать можно разве что в университетах, где тачки одинаковые.
> Если у вас есть 32 старых однопроцессорных компьютера
Возможно Вы серьезно больны.
Боюсь серверные двухканальные сетевухи будут стоить дороже этого хлама, а на обычных делать смысла нет -- пересылки всё сожрут.
> лучше купить один мощный комп.
А лучше 32 мощных компа :)
> Боюсь серверные двухканальные сетевухи будут стоить дороже этого хлама, а на обычных делать смысла нет -- пересылки всё сожрут.
Именно поэтому по ссылке упоминается InfiniBand.
Вот тут тоже про кластеры.
Это главная? Или толксы?
>Если у вас есть 32 старых однопроцессорных компьютера
Поменяйте их на один новый
>Да, у них всего по одному ядру, но все вместе они смогут сделать больше, чем одна двухъядерная машина.
Потребить электричества уж точно. А без должного распараллеливания нужных процессов такой кластер будет совершенно бесполезен.
чОрт, у меня есть только всего один старый комп. Я смогу сделать из него кластер, который обделает все 10-ядерные ксеноны.
Хм, интересная статья, не знал что есть готовые дистрибутивы заточенные под это.
А о том, как приготовить офигический ужин на двоих из 7 протухших сарделек там не пишут?
а почему вы интересуетесь?
Пишут как сделать ужин, а протухшие или свежие сардельки туда резать - Вам решать :D
А по делу мне кажется что статья вполне ничего. Как ознакомительная по кластерным дистрам. Кстати, Beowulf-подобные решения вполне могут быть востребованы в тех же универах для обучения. У нас было такое дело что пришел новый класс, старый так тоже вполне себе ничего был. Там оптероны 4-процовые стояли. И их "утилизировали" подобным способом.
> чОрт, у меня есть только всего один старый комп. Я смогу сделать из него кластер, который обделает все 10-ядерные ксеноны.
и питцот галагенок
всё, бегу докупать ещё 31 однопроцессорный комп, и я буду круче чем сосед со своим 2 ядерным ноутбуком. вот я его натяну! ( а электричество.. это уже мелочи.. главное куда деть эти 32 компа?)
только сегодня думал что надо почитать про кластеры линуксовые ^_^
>Если у вас есть 32 старых однопроцессорных компьютер
Слово "старых" явно лишнее в названии статьи.
Действительно хорошая статья. Призадумался о том, чтобы реализовать описанную схему в университете.
О! У меня! У меня есть!!1111111 Вся кладовка в офисе ими завалена (на полном серьёзе, раньше юзались как ТК, потом перешли на ТК от HP) - выбросить жалко, применить некуда.
Интересно, если их все в кластер собрать - на них tomboy пойдёт?
>Если у вас есть 32 старых однопроцессорных компьютера
Самая идея совершенно бредовая, но очень типичная для нищебродского отечественного IT. Дело-то ведь не в том, чтобы сэкономить за счёт использования кластера - да Боже упаси, эксплуатация скоренько сожрёт денег больше, чем любой Гаргантюа с Пантагрюэлем вместе взятые, - НЕТ, дело в том, чтобы уложиться в текущий бюджет, чтобы, например, обучение начальника каким-нибудь основам CRM/BPM не пошло прахом из-за покупки нового дорогого мощного сервера. Народ в организациях просто боиться тратиться единовременно на крупные суммы. Лучше вот 10 раз по 30 рублей, чем один раз аж 100 капиталовыложить! И все прекрасно понимают, что кластер из хлама - это бесполезно и бесцельно, впустую потраченное время специалистов (которое тоже чего-то ПО ИДЕЕ должно бы стоить), это неоправданно высокие затраты электроэнергии, это на порядки более геморройные и менее диагностируемые проблемы с железом, это место в серверной в конце-концов (и оно тоже денег стоит), но ё-моё, вы ж посмотрите, господин гавнюк, то мы бы купили IBM P-серии (кошмарно дорогой, аж два ваших отпуска в Европе!), а так - мы такие умные, погладщьте нас по головке и увеличьте фонд на обучение, уйму денег вам сэкономим, старую серверную рухлядь соберём в ультрамодное словечко - HA-кластер (НА - это, правда, не высокодоступный значит, это просто наше русское классическое НА ) и будем круче яиц, сваренных в крутую на процессорах этих 32-х машинок. УРА! Все счастливы, углекислый газ выделяется, парниковый эффект усиливается, скоро все будем жить на Канарах или хотя бы просто на острове посреди Мирового Океана - все вместе, начальнека, все вместе, в тесноте, да не в обиде.
как пел Евгений Гудзь, "серебряные зайцы водят хоровод". теперь я знаю, он про гленду ;)
Нифигасе высер. А если я четыре сервака на кореквадах в кластер хочу, чтоб аппсервер мог не 3000 а 10000 соединений одновременных обслуживать? А тестироваться/практиковаться на чём?
Спасибо, Виктор Алексеевич. Хорошая, годная статья.
Я бы переименовал в "Как собрать обогреватель".
В принципе лето заканчивается, скоро будет актуально.
Виндовый ботнет и то выглядит перспективнее для всяких расчетов, чем старая рухлядь (еще и 32 шутки). И тише будет.
Чтобы аппсервер мог больше соединений обслуживать, прежде всего замените аппсервер на бэкенды, написанные на C и веб-фронтенды на Perl! Java-сервера приложений 80% времени своей работы тупо жрут процессорное время и память. Дай какой-нибудь веб-сфере сказать "Hello, world!", она и на это потратит столько же тактов, сколько в каком-нибудь 1970-ом году тртилось на расчёт полёта космической ракеты. У меня как у ASM-програмиста подобные вещи ничего, кроме отвращения, не вызывают. Ну и собственно очень редко узким местом является именно процессор, гораздо чаще это всё-таки ввод-вывод, ну а коли у вас все ноды кластера наверняка будут подключены к одной полке и делить одно на всех внешнее ethernet-подключение, то о каком трёхкратном росте производительности может идти речь?
>Чтобы аппсервер мог больше соединений обслуживать, прежде всего замените аппсервер на бэкенды, написанные на C и веб-фронтенды на Perl!
А потом выйдите на улицу на перекур и узнайте, что Землю сто лет назад захватили серо-зеленые жабокрылы.
32 * 300 Watt одной машины
9kWat хорошенький обогреватель, всё равно аля <Как из 32 студентов инженеров первоеурсников сделать 1 крутого админа>
Вычислительный кластер – это набор соединенных между собой компьютеров (серверов), которые работают вместе и могут рассматриваться как единая система. В отличие от грид-вычислений, все узлы компьютерного кластера выполняют одну и ту же задачу и управляются одной системой управления.
Серверы кластера обычно соединяются между собой по быстродействующей локальной сети, причем на каждом из серверов работает собственный экземпляр операционной системы. В большинстве случаев все вычислительные узлы кластера используют одинаковое оборудование и одну и ту же операционную систему. Однако в некоторых инсталляциях, например, с использованием платформы приложений для организации кластеров OSCAR (Open Source Cluster Application Resources), могут использоваться различные операционные системы или разное серверное оборудование.
Кластеры обычно развертываются для большей производительности и доступности, чем то, что можно получить от одного компьютера, пусть даже очень мощного. Часто такое решение более экономично, чем отдельные компьютеры.
Компоненты кластера
Вычислительные кластеры обычно состоят из следующих компонентов:
- узел доступа;
- вычислительные узлы;
- файловый сервер;
- файловая или объектная СХД с общим доступом;
- локальная сеть LAN.
Виды кластеров
Различают следующие основные виды кластеров:
- кластеры высокой доступности (High-availability clusters, HA);
- кластеры с балансировкой нагрузки (Load balancing clusters);
- высокопроизводительные кластеры (High performance computing clusters, HPC).
Кластеры высокой доступности
Кластеры высокой доступности НА (high-availability cluster) известны также как отказоустойчивые (failover) кластеры, построенные по схеме сети с большой избыточностью (redundancy). Они применяются для критических серверных приложений, например сервера баз данных. Компьютерный кластер может называться НА-кластером, если он обеспечивает доступность приложений не менее, чем «пять девяток», т. е. приложение должно быть доступно (uptime) в течение 99,999 % времени за год.
Чрезвычайно высокая доступность в НА-кластерах достигается за счет использования специального программного обеспечения и аппаратных решений со схемами обнаружения отказов, а также благодаря работе по подготовке к отказам.
ПО для НА-кластеров обычно заблаговременно конфигурирует узел на резервном сервере и запускает на нем приложение в фоновом режиме так, чтобы основной экземпляр приложения мог немедленно переключиться на свою реплику на резервном компьютере при отказе основного.
НА-кластеры обычно используются для терминальных серверов, серверов баз данных, почтовых серверов, а также для серверов общего доступа к файлам. Они могут быть развернуты как на одном местоположении («серверной ферме»), так и в географически разнесенных местоположениях.
Но не следует думать, что технология кластера высокой доступности, или вообще кластеризация, могут служить заменой резервному копированию (backup), а также решениям катастрофоустойчивости (disaster recovery).
Кластеры с балансировкой нагрузки
Балансировка нагрузки – это эффективное распределение входящего сетевого трафика в группе (кластере) серверов.
Современные веб-сайты должны одновременно обслуживать сотни тысяч и даже миллионы запросов от пользователей или клиентов и не слишком задерживать их в получении контента: текста, видео или данных приложений. Чем больше серверов будут обслуживать эти запросы, тем лучше будет качество воспринимаемого сервиса для клиентов. Однако может возникнуть ситуация, когда одни серверы сайта будут работать с перегрузкой, а другие будут почти простаивать.
Балансировщик нагрузки направляет запросы клиентов равномерно на все серверы кластера, которые способны ответить на те или иные запросы. Таким образом, балансировщик максимизирует процент использования вычислительной емкости, а также обеспечивает то, что ни один сервер не оказывается перегруженным, вызывая общую деградацию производительности кластера.
Если какой-то сервер отказывает, то балансировщик перенаправляет трафик на оставшиеся серверы. Когда новый сервер добавляется к группе (кластеру), то балансировщик автоматически перераспределяет нагрузку на всех серверах с учетом вновь вступившего в работу.
Таким образом, балансировщик нагрузки выполняет следующие функции:
- Распределяет запросы клиентов и нагрузку сети эффективным образом в во всем кластере серверов.
- Обеспечивает высокую доступность и надежность посылкой запросов только на те серверы, которые находятся в режиме онлайн.
- Обеспечивает гибкость, добавляя или удаляя серверы по мере надобности.
Работа балансировщика нагрузки
Алгоритмы балансировки нагрузки
Различные алгоритмы балансировки предназначены для разных целей и достижения разных выгод. Можно назвать следующие алгоритмы балансировки:
- Round Robin – запросы распределяются по кластеру серверов последовательно.
- Least Connections – новый запрос посылается на сервер с наименьшим числом подключений клиентов, однако при этом учитывается и вычислительная мощность каждого сервера.
- Least Time – запросы посылаются на сервер, выбираемый по формуле, которая комбинирует быстроту ответа и наименьшее число активных запросов.
- Hash – распределяет запросы на основании определяемого пользователем ключа, например, IP-адреса клиента или URL запрашиваемого сайта.
- Random with Two Choices – выбираются два сервера по методу произвольного выбора и затем запрос посылается на один из них, который выбирается по критерию наименьшего числа подключений.
Программная и аппаратная балансировка нагрузки
Балансировщики нагрузки бывают двух типов: программные и аппаратные. Программные балансировщики можно установить на любой сервер достаточной для задачи емкости. Поставщики аппаратных балансировщиков просто загружают соответствующее программное обеспечение балансировки нагрузки на серверы со специализированными процессорами. Программные балансировщики менее дорогие и более гибкие. Можно также использовать облачные решения сервисов балансировки нагрузки, такие как AWS EC2.
Высокопроизводительные кластеры (HPC)
Высокопроизводительные вычисления HPC (High-performance computing) – это способность обрабатывать данные и выполнять сложные расчеты с высокой скоростью. Это понятие весьма относительное. Например, обычный лэптоп с тактовой частотой процессора в 3 ГГц может производить 3 миллиарда вычислений в секунду. Для обычного человека это очень большая скорость вычислений, однако она меркнет перед решениями HPC, которые могут выполнять квадриллионы вычислений в секунду.
Одно из наиболее известных решений HPC – это суперкомпьютер. Он содержит тысячи вычислительных узлов, которые работают вместе над одной или несколькими задачами, что называется параллельными вычислениями.
HPC очень важны для прогресса в научных, промышленных и общественных областях.
Такие технологии, как интернет вещей IoT (Internet of Things), искусственный интеллект AI (artificial intelligence), и аддитивное производство (3D imaging), требуют значительных объемов обработки данных, которые экспоненциально растут со временем. Для таких приложений, как живой стриминг спортивных событий в высоком разрешении, отслеживание зарождающихся тайфунов, тестирование новых продуктов, анализ финансовых рынков, – способность быстро обрабатывать большие объемы данных является критической.
Чтобы создать HPC-кластер, необходимо объединить много мощных компьютеров при помощи высокоскоростной сети с широкой полосой пропускания. В этом кластере на многих узлах одновременно работают приложения и алгоритмы, быстро выполняющие различные задачи.
Чтобы поддерживать высокую скорость вычислений, каждый компонент сети должен работать синхронно с другими. Например, компонент системы хранения должен быть способен записывать и извлекать данные так, чтобы не задерживать вычислительный узел. Точно так же и сеть должна быстро передавать данные между компонентами НРС-кластера. Если один компонент будет подтормаживать, он снизит производительность работы всего кластера.
Существует много технических решений построения НРС-кластера для тех или иных приложений. Однако типовая архитектура НРС-кластера выглядит примерно так, как показано на рисунке ниже.
Примеры реализации вычислительного кластера
В лаборатории вычислительного интеллекта создан вычислительный кластер для решения сложных задач анализа данных, моделирования и оптимизации процессов и систем.
Кластер представляет собой сеть из 11 машин с распределенной файловой системой NFS. Общее число ядер CPU в кластере – 61, из них высокопроизводительных – 48. Максимальное число параллельных высокоуровневых задач (потоков) – 109. Общее число ядер графического процессора CUDA GPU – 1920 (NVidia GTX 1070 DDR5 8Gb).
На оборудовании кластера успешно решены задачи анализа больших данных (Big Data): задача распознавания сигнала от процессов рождения суперсимметричных частиц, задача классификации кристаллических структур по данным порошковой дифракции, задача распределения нагрузки электросетей путем определения выработки электроэнергии тепловыми и гидроэлектростанциями с целью минимизации расходов, задача поиска оптимального расположения массива кольцевых антенн и другие задачи.
Архитектура вычислительного кластера
Другой вычислительный НРС-кластер дает возможность выполнять расчеты в любой области физики и проводить многодисциплинарные исследования.
Графические результаты расчета реактивного двигателя, полученные на НРС-клатере (источник: БГТУ «ВОЕНМЕХ»)
На рисунке показана визуализация результатов расчета реактивного двигателя, зависимость скорости расчетов и эффективности вычислений от количества ядер процессора.
Для управления узлом кластера существует небольшой набор команд, среди которых:mosctl - контроль над узлом. Позволяет изменять параметры узла - такие, как block, stay, lstay, delay и т.д
Давайте рассмотрим несколько параметров этой утилиты:
stay - позволяет останавливать миграцию процессов на другие узлы с текущей машины. Отменяется параметром nostay или -stay
lstay - запрещает только локальным процессам миграцию, а процессы с других машин могут продолжать это делать. Отменяется параметром nolstay или -lstay.
block - запрещает удаленным/гостевым процессам выполнятся на этом узле. Отменяется параметром noblock или -block.
bring - возвращает обратно все процессы с текущего узла выполняемые на других машинах кластера. Этот параметр может не срабатывать, пока мигрировавший процесс не получит прерывание от системы.
setdelay устанавливает время, после которого процесс начинает мигрировать.
Ведь согласитесь - в случае, если время выполнения процесса меньше секунды смысл переносить его на другие машины сети исчезает. Именно это время и выставляется утилитой mosctl с параметром setdecay. Пример:
mosctl setdecay 1 500 200
устанавливает время перехода на другие узлы 500 миллисекунд в случае, если процесс запущен как slow и 200 милисекунд для fast процессов. Обратите внимание, что параметр slow всегда должен быть больше или равен параметру fast.
mosrun - запускает приложение в кластере. например mosrun -e -j5 make запустит make на 5-ом узле кластера, при этом все его дочерние процессы будут также выполнятся на 5-ом узле. Правда здесь есть один нюанс, при чем довольно существенный:
в случае, если дочерние процессы выполняются быстрее чем установленная утилитой mosctl задержка (delay) то процесс не будет мигрировать на другие узлы кластера. у mosrun еще довольно много различных интересных параметров, но подробно узнать
о них вы сможете из руководства по этой утилите. (man mosrun)
mon - как мы уже знаем, это монитор кластера, который в псевдографическом виде отображает загрузку каждого рабочего узла вашего кластера, количество свободной и занятой памяти узлов и выдает много другой, не менее интересной информации.
mtop - модифицированная для использования на узлах кластера версия команды top. Отображает на экране динамическую информацию о процессах, запущенных на данном узле, и узлах, куда мигрировали ваши процессы.
mps - тоже модифицированная версия команды ps. Добавлено еще одно поле - номер узла, на который мигрировал процесс.
Вот на мой взгляд и все основные утилиты. На самом деле конешно можно обойтись даже без них. Например используя для контроля над кластером /proc/mosix.
Там кроме того, что можно найти основную информацию о настройках узла, процессах запущенных с других узлов и т.д.,а также поменять часть параметров.
Давайте рассмотрим один из примеров:
Допустим, что у нас в кластере работают две машины (два узла), один из которых с номером 1 (366 Celeron), другой - с номером 5(PIII450). Экспериментировать мы будем на 5-ом узле. 1-й узел в это время простаивал. ;-)
Итак, запускаем на 5-м узле утилиту crark для подбора пароля к rar архиву.Если кто из вас пробовал работать с подобными утилитами, то он должен знать, что процесс подбора пароля "кушает" до 99 процентов процессора. Ну что же - после запуска мы наблюдаем, что процесс остается на этом, 5-ом узле. Разумно - ведь именно у этого узла производительность превышает 1-й узел почти в два раза.
Далее мы просто запустили сборку kde 2.0. Смотрим таблицу процессов и видим, что crark успешно мигрировал на 1-й узел, освободив процессор и память (да, да - память точно также освобождается) для make. А как только make закончил свою работу - crark вернулся обратно, на родной ему 5-й узел.
Интересный эффект получается, если crark запускать на более медленном 1-м узле.
Там мы наблюдаем практически противоположный результат - процесс сразу-же мигрирует на 5-й, более быстрый узел. При этом он возвращается обратно, когда хозяин пятого компьютера начинает какие-то действия с системой. Давайте в конце разберемся, зачем и как мы можем использовать кластер в своей повседневной жизни.
Для начала нужно раз и навсегда запомнить - кластер выгоден только в том случае, когда в вашей сети есть энное количество машин, которые частенько простаивают и вы хотите использовать их ресурсы например для сборки KDE или для любых серьезных процессов. Ведь благодаря кластеру из 10 машин можно одновременно
компилировать до 10 тяжелых программ на том-же C++. Или подбирать какой-то пароль,
не прекращая ни на секунду этого процесса независимо от нагрузки на ваш компьютер.
Да и вообще - это просто интересно ;-).
В заключение хочу сказать, что в этой статье не рассмотрены все возможности MOSIX, т.к. я просто до них еще не добрался. Если доберусь - ждите продолжения. :-)
Читайте также: