2013-09-17 4 views
0

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

Краткое описание моего проекта:

Существует АНИ для отправки (через SSH) рабочих мест для научных кластеров вычислений. API - это абстракция для различных поставщиков очереди научных заданий. http://saga-project.github.io/saga-python/ Мой проект в основном касается создания графического интерфейса для этого API с django.

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

API все еще находится в разработке, а некоторые из функций не полностью закончены. Существует функция проверки состояния удаленного выполнения задания (запуск, завершение и т. Д.), Но поддержка обратного вызова для изменений состояния не готова. Здесь я думаю, что сельдерей может быть уместным. У меня была бы одна или несколько периодических задач, контролирующих состояние работы.

Любые советы о том, как действовать, пожалуйста? Нет сельдерея вообще? сельдерей для всего? сельдерей только для работы?

ответ

2

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

Каждый узел кластера работает с очень маленьким сервером python, который принимает идентификатор db своего назначенного задания. Затем он вызывается на главный (http) сервер для запроса необходимых ему данных и, наконец, отправляет данные по завершении. В моем случае отдельным узлам не нужно сообщать друг другу, а время выполнения каждой задачи очень велико (часы). Это делает задержки, введенные центральным управлением и опросом, незначительными.

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

Сельдерей не умеет управлять приоритетами или восстанавливать утраченные задачи (больше оснований для централизованного контроля).

Спасибо, что обратили мое внимание на SAGA. Я смотрю на это сейчас, чтобы понять, полезно ли это для меня.

1

Сельдерей полезен для выполнения задач, которые слишком дороги для выполнения в обработчике HTTP-запроса (т. Е. В представлении Django). Подумайте о том, чтобы сделать HTTP-запрос из представления Django на какой-либо удаленный веб-сервер и подумать о задержках, возможных тайм-аутах, времени для передачи данных и т. Д. Также имеет смысл ставить в очередь задачи с интенсивным вычислением, требующие много времени для выполнения фона с помощью Celery.

Мы можем только догадываться, что должен делать веб-интерфейс для API. Однако Сельдерей очень хорошо подходит для запросов в очереди на научные вычислительные кластеры. Он также позволяет отслеживать состояние фоновой задачи и ее результаты.

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

+1

привет, спасибо за ответ. Очереди в кластерах не являются очередями сельдерея. Они являются независимыми реализациями, и API соединяется через SSH и управляет этими очередями из командной строки. Мои рабочие процессы не будут действительно выполнять какую-либо реальную работу, они фактически будут управлять очередями очередей «реальных» (удаленных в кластерах). –

+0

Я думаю, мне также понадобится механизм кэширования ssh-соединений. Просто покажите пример [здесь] (http://docs.celeryproject.org/en/latest/userguide/tasks.html#instantiation), и это действительно кажется действительно подходящим. –

Смежные вопросы