LINUX.ORG.RU
ФорумAdmin

Вопрос по организации кластера над docker'ом

 , ,


1

3

Коллективный разум LOR-а, подскажи, каким инструментом решать следующую задачу:

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

Также имеется сетка на N узлов, на которых мы можем производить вычислениях.

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

В качестве инструмента для запуска операций предполагается использовать docker, и обработчики операций будут представлены образами docker-а. Даные для обработки будут доступны как тома. То есть, для выполнения операции «скомпилируй мне бинарный пакет для дебиана из вот этого исходного пакета» мы запускаем контейнер из образа «сборщик пакетов для дебиана» и подсовываем ему тома данных, откуда он возьмёт исходный и куда положит бинарный.

Контейнеры не предполагаются долговременно запущенными, т.е. они не сервисы. Контейнер сделал дело - умер и удалился. Для следующей операции будут поднят новый контейнер.

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

Перемещено leave из development

Deleted

поднимаешь swarm или докер в swarm-mode и задача сводится к предыдущей. ну с оговорками - придется потрахаться с настройкой overlay сети

Deleted
()
Ответ на: комментарий от Deleted

Хм. Я так понимаю, swarm за меня не будет балансировать нагрузку и перезапускать контейнер на другом узле, если узел отвалился? Или я неправильно понимаю?

Deleted
()
Ответ на: комментарий от Deleted

он для управления из docker cli, да он будет деплоить новый контейнер на ноду которая меньше загружена и т.п., но как ты себе представляешь магию вроде:

перезапускать контейнер на другом узле, если узел отвалился?

Ась?

Deleted
()
Ответ на: комментарий от Deleted

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

Вот и мне это интересно. Чисто технически, это не более чем пинг по таймауту.

На уровне архитектуры наш контейнер можно рассматривать как Unix-процесс (то, что он на удалённой машине, - клиентский код не знает). Т.е. мы делаем docker run и ждём пока процесс завершится с некоторым состоянием.

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

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

Deleted
()
Ответ на: комментарий от Deleted

Чисто технически, это не более чем пинг по таймауту.

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

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

Про абстракции http://russian.joelonsoftware.com/articles/leakyabstractions.html

Даже если забить на следы работы контейнера (что он там должен накомпилировать) то тебе надо обеспечить одинаковую доступность ресурсов, затем вывести точный критерий недоступности ноды - если там своп кончается то она тебе отвечать например перестанет, а когда oom грохнет что надо то у тебя окажется два запущенных контейнера и еще куча нюансов, например нетсплит - когда нода не упала а продолжает работать но недоступна

Deleted
()
Ответ на: комментарий от Deleted

Это стандартная задача по организации HA ведь. Немножко магии конечно, но ничего нереального.

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

alpha ★★★★★
()
Ответ на: комментарий от Deleted

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

во-первых, критерий может быть неточным

во-вторых, https://en.wikipedia.org/wiki/Heartbeat_(computing)

alpha ★★★★★
()
Ответ на: комментарий от Deleted

это был коммент про критерий неработоспособности ноды

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

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

alpha ★★★★★
()

Hadoop?

То что ты собираешься делать и Docker, это как машину зимой покупать только потому что на ней шипованные шины.

BigAlex ★★★
()
Ответ на: комментарий от alpha

В рамках этой аналогии, это когда у тебя 24 друга, которых ты хочешь примерно одновременно развести по домам на «абстрактной» машине.

BigAlex ★★★
()
Ответ на: комментарий от alpha

это был коммент про критерий неработоспособности ноды

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

Если у меня например результаты выполнения задачи собирает центральный мастер,

Вариантов уйма, но это требует чтобы контейнер был не тупой или хранилище, ТС - описывает как тупые контейнеры и файлопомойка, и хочет чтобы все работало.

Deleted
()

вообще выглядит как эталонное применение для kubernetes.

ugoday ★★★★★
()
Ответ на: комментарий от Deleted

описанный мной случай с нехваткой памяти твой способ не покрывает

Это общая идея, а при реализации я могу для проверки какой-то отклик от сервиса проверять. Да хоть грепать логи по out of memory error.

это требует чтобы контейнер был не тупой или хранилище, ТС - описывает как тупые контейнеры и файлопомойка

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

alpha ★★★★★
()
Ответ на: комментарий от Deleted

Задачу не читам?

Имеются наборы данных, над которыми требуется выполнять наборы хорошо распараллеливаемых операций. Чтобы было более понятно...

BigAlex ★★★
()
Ответ на: комментарий от BigAlex

Зачем ты мне пишешь что не читаешь задачу?

Вот для слепых цитирую:

выполнения операции «скомпилируй мне бинарный пакет для дебиана из вот этого исходного пакета»

Deleted
()
Ответ на: комментарий от alpha

а при реализации я могу для проверки какой-то отклик от сервиса проверять.

тогда называй вещи своими именами не heartbeat а health check, и не забудь что он требует не только провеки ноды но и контейнера (вдруг он там дедлок поймал?)

Любой дженкинс с этим справляется.

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

Deleted
()
Ответ на: комментарий от Deleted

Когда пакеты в один реп собираются, там вообще распараллеливания нет. Потому что метаданные перегенерить надо.

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

alpha ★★★★★
()
Ответ на: комментарий от alpha

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

Deleted
()

mesos + marathon как раз для этого

Shtsh ★★★★
()
Ответ на: комментарий от Deleted

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

У контейнера только два финальных состояния: либо «я закончил, вот данные», либо «я закончил с ошибкой, вот лог». Т.е., с точки зрения концептуальной, это даже одно финальное состояние.

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

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

Еммае, как, скажи как heartbeart тебе поможет не допустить работы двух конкурирующих контейнеров?

Да хрен с ними, пусть работают. Контейнер результат своей работы предоставляет клиентскому коду атомарно. Если клиенту результат не нужен (он его уже забрал из другого контейнера), то результат сметается в мусор вместе с контейнером.

Deleted
()
Ответ на: комментарий от BigAlex

То что ты собираешься делать и Docker, это как машину зимой покупать только потому что на ней шипованные шины.

Конкретно Docker уже используется как способ развёртывания ПО, так что Docker естественно был отправной мыслью при размышлении над задачей.

Deleted
()

В общем, насколько я понял, ключевые слова для гуглежа - kubernetes и mesos+marathon.

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

Deleted
()

HTCondor

А теперь ответь на вопрос: «Причём тут docker?»

Если твоя задача распределить выполнение заданий между N узлами, для которых нет необходимости тесной взаимосвязи (aka MPI), то посмотри в сторону High-throughput computing. А вот будут ли они запускать контейнер или готовое приложение уже второстепенно.

Хорошим средством для этого является HTCondor.

AlexVR ★★★★★
()
Ответ на: комментарий от Deleted

Контейнер результат своей работы предоставляет клиентскому коду атомарно.

вот это вот стоило сразу написать

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.