Корпоративный кластер. Мысли вслух

[UUSER]

boinc

На ночь можно загружаться в что-то вроде этого

[SrJ]

Да. Что-то вроде. Только BOINC предполагает, что вы предоставляете свои ресурсы грид-системе решающей не ваши задачи (в основном научные эксперименты). А CHAOS не может работать вместе с пользователем в фоновом режиме.
В статье же речь идет о такой системе, которая сможет работать параллельно с пользователями (учитывая периоды и интенсивность работы каждого, чтобы не мешать) и объединять все простаивающие ресурсы в один пул. Виртуальная машина использующая этот пул сможет выполнять ваши ресурсоемкие задачи (ну а если захотите, то сможет предоставить ресурсы во внешний мир как BOINC).

[Speedimon]

Я думаю такая идея приходила в голову практически каждому. Но потом становится понятно что использовать такой «кластер» можно только под очень узкий круг задач, а софт должен изначально быть написан под такую распределенную систему. Ну да, можно сделать рендер-ферму, считать биткоины или помогать человечеству с BOINC. На этом собственно и всё. Мега-хранилище сделать не получится, клиенты выключаются/перемещаются, вы прийдёте в результате к некому аналогу BranchCache или торрентов. Вычислительная задача — должна быть очень сильно параллелизуемой с независимыми фрагментами вычислений. Память вы не «объедините» по причине того что сеть медленнее и смысла ноль. Виртуалки какие-то размещать — тоже сомнительная затея.

[Karl_Marx]

Согласен, добавлю: большинство задач с точки зрения безопасности страшно отдавать на рабочие машины.

[3vi1_0n3]

Теоретически, у нас есть корпоративный кластер. Он состоит из всех машин в сети предприятия и использует их производительность согласно установленной квоте. Квота может устанавливаться на базе аназиза данных о средней загруженности системы в течении дня/недели/месяца… Затем квота может корректироваться «на лету» если показатель средней загруженности изменится.

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

[SrJ]

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

[3vi1_0n3]

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

[JDima]

Всегда начинайте с задачи, а не с решения. «Задействовать ресурсы» не является задачей.

Мало у какой компании есть задачи, которые целесообразно распределять между рабочими станциями пользователей (за редкими исключениями вроде упомянутого branchcache, но при 150-и машинах надо по-любому ставить выделенный сервер кеширования). Что-нибудь вроде «майнить биткоины»? Ну и много ли намайните в масштабах компании на обычных офисных компьютерах?

Вы не первый, кому приходит в голову «избавиться от простоя клиентских ресурсов». Кто-то ради этого переходит на VDI («нет ресурсов — нет проблемы»). И все понимают, что проще и дешевле будет докупить серверных ресурсов, чем параллелить обработку каких-то данных с огромной избыточностью.

[phprus]

Уязвимым местом всех параллельных вычислительных систем является канал связи между узлами (латентность при обработке и распараллеливании задачи между узлами а также накладные расходы на синхронизацию). Но на данный момент, повторюсь, всё больше и больше корпоративных сетей работают со скоростью 1Гбит/сек, и это не может не радовать.

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

Такой проблемой занимались (не мы). Примером может служить следующая попытка внедрения данного подхода: conf.nsc.ru/MIT-2011/reportview/48789 (Построение распределенных высокопроизводительных систем для геофизических вычислений на рабочих станциях на платформах Condor и Windows HPC Server).

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

[RouR]

Можно откусывать HDD, и хранить не критичные данные, можно придумывать схему резервирования такой информации по разным машинам.
Можно откусывать RAM, позапускав допустим memcache, которые будут нужны под кеш web-серверов.
Сложнее утилизировать CPU (на мой взгляд), делать планировщик задач, ограничивать задаче максимальную нагрузку на машине пользователя, укладываться в требования по быстродействию решения задачи.

[3vi1_0n3]

По HDD можно уже готовую схему использовать. Например такую, которая уже применяется в Openstack Swift.

[KorP]

ИМХО терминальные клиенты для того и придумали, что бы небыло «простаивающих ресурсов».

[SrJ]

Точнее, тонкие клиенты и бездисковые станции подключенные как терминальные клиенты (терминальным клиентом может выступать и обычная рабочая станция). И придумывали их в первую очередь для снижения стоимости решения и уменьшения общего энергопотребления. Тем более, если задача требует ресурсов, то вы их всё равно предоставите, не на клиенте так на сервере.
Но далеко не все компании используют тонкие клиенты и бездисковые станции… И ресурсы действительно простаивают. Это мы с вами, коллега, можем на это глаза закрыть и объяснить это особенностями архитектуры, а вот менеджеры/экономисты задают вопрос: «За что, собственно, мы платим? Даешь рационализацию!»
Речь идет как раз о таких случаях.

[KorP]

Ну это должно решаться на уровне планирования. Если мы знаем что у нас будет отдел менеджеров из 50 человек, логично закупить тонкие клиенты и 1-2 сервера под терминалы, чем покупать 50 рабочих станций (про лицензирование тоже не забываем :)), что изначально уже увеличит стоимость владения на приличную сумму. Все беды от отсутствия планирования. Ну а если понадобятся кому то полноценные станции, для работы с графикой, к примеру (ну там маркетологи или программисты или ещё какие звери), докупить быстренько именно рабочие станции.

[sergeypid]

Кто работал в крупных конторах, слышал об SQL-запросах или отчетах, выполняющихся не один час. Такое часто можно встретить в банках. Такие аналитические запросы к тому же сильно тормозят основную банковскую систему. Так что проблема есть. Может и правда, кто-то придумает продукт. Например, корпоративная база/хранилище реплицируется на офисные машины, и некритичные долгие процессы параллелятся на свободные ресурсы. Там сотни компьютеров с висящим окошком Excel весь день, так что энергию они все равно жрут.

[JDima]

Кто работал в крупных конторах, слышал об SQL-запросах или отчетах, выполняющихся не один час.

А часы они обычно выполняются из-за нехватки IO и/или высокого latency. Если перенести такую базу из SAN на рабочие станции пользователей, то речь пойдет не о часах, а о сутках и неделях. Важнейший момент — быстрое общение с подсистемой хранения.
И, работая в крупной компании, скажу: если запрос выполняется не один час, то это факап. Либо сам запрос косячный, либо массивы просели до недопустимого уровня, диски еле отзываются.
Скажем, я своими глазами видел пятимегабайтный (!) запрос. Чистого текста в нем — 5мб. Если убрать неисчислимое количество пробелов и прочих элементов форматирования, то останется килобайт сто, не меньше. Этот запрос практически убивал СУБД.