Архитектура серверной части
От: Trrrrr  
Дата: 27.05.13 09:33
Оценка:
Есть у нас проект вычислительный, на сайте человек что-то делает, и приходит заказ через MQ на вычисление на несколько клиентов, каждый запущен на своей машине.
Сейчас их немного 3-4 штуки, эти приложения — обычные консольные приложения под Windows.

Собственно вопрос, рано или поздно их станет 10, потом 100 и тд.

Надо их как-то деплоить, включать, выключать, обновлять, проверять статус, и т.д.

Собственно вопрос, как это все лучше организовать?
Re: Архитектура серверной части
От: Sinix  
Дата: 27.05.13 11:00
Оценка:
Здравствуйте, Trrrrr, Вы писали:

T>Собственно вопрос, как это все лучше организовать?

Я бы смотрел в сторону ботнетов/вычислительных сетей — сервер (сервера) пассивен, выдаёт следующее задание/обновления/график работы по запросу клиента.

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

Если вычислительные задачи каждый раз разные, можно вытащить их в подгружаемые модули и упростить клиента до простого цикла "скачать исполняемый файл-запустить-грохнуть файл-запросить сервер-спать..."
Re: Архитектура серверной части
От: wildwind Россия  
Дата: 27.05.13 12:57
Оценка: 1 (1)
Здравствуйте, Trrrrr, Вы писали:

T>Надо их как-то деплоить, включать, выключать, обновлять, проверять статус, и т.д.

T>Собственно вопрос, как это все лучше организовать?

Ключевые слова: OpenStack, Hadoop.
Re[2]: Архитектура серверной части
От: Trrrrr  
Дата: 27.05.13 13:29
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Trrrrr, Вы писали:


T>>Собственно вопрос, как это все лучше организовать?

S>Я бы смотрел в сторону ботнетов/вычислительных сетей — сервер (сервера) пассивен, выдаёт следующее задание/обновления/график работы по запросу клиента.

S>Клиент сам разруливает все проблемы на локальной машине в зависимости от пожеланий, пришедших с сервера.


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

Комманды более вычислительного характера, поэтому хотелось бы максимальной производительности, как-то запускать модули и выгружать назад не хотелось бы. Зато в этом случае в случае падения, простой клиент никогда не будет падать, что хорошо. Какраз очень сильно боюсь ситуации, когда сервер будет отправлять данные, на которых по какойнибудь причине упадет клиент, тогда он подождет немного и еще пару раз отправляет, так можно случайно много прибить
Хочеться, в общем простого — по запросу узнавать статус клиента. Возможно создам доюп приложение, которое следит за клиентами, а сним уже будет связь, ион если что их будет поднимать и отрубать.
Re[2]: Архитектура серверной части
От: Trrrrr  
Дата: 27.05.13 13:30
Оценка: 1 (1)
Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, Trrrrr, Вы писали:


T>>Надо их как-то деплоить, включать, выключать, обновлять, проверять статус, и т.д.

T>>Собственно вопрос, как это все лучше организовать?

W>Ключевые слова: OpenStack, Hadoop.


Спасибо, буду изучать.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.