Добрый день.
Я работаю над приложением, которое должно хорошо масштабироваться горизонтально. При этом, я хочу добиться того, что-бы развертывание и настройка моей системы были очень простыми. Желательно, что-бы конфигурирование вообще не требовалось. Предполагается, что все будет работать в рамках одного датацентра, все узлы будут в одной подсети или вообще на одной машине. Поэтому, я думаю сделать так: приложение состоит их одинаковых нодов, каждый нод, после старта начинает рассылку multicast пакетов, а также их чтение. Пакет содержит ip-адрес нода, а также служебную информацию. Помимо этого, пакет рассылается не открытым текстом, он зашифрован и подписан (secret key у всех нодов один и тот же). В общем, это должно привести к тому, что каждый узел будет знать обо всех остальных узлах.
Каждый узел — однопоточное приложение(по большей части, в один момент времени выполняется один запрос, но узел держит много подключений), после запуска читает данные с диска и больше туда не лезет. В дальнейшем, весь ввод/вывод, это обмен данными с клиентом а данные хранятся в памяти и меняются очень редко(такова специфика задачи), для того, что-бы использовать все процессоры можно запустить на машине несколько копий приложения, так я хочу избавиться от возможных проблем с многопоточностью.
Запрос выполняется следующим образом, клиент подключается к одному из узлов(сервер выбирается тупо, по round robin, правда я пока не решил, откуда он может получить список адресов, по которым можно подключаться, к тому же, я еще не знаю, будет подключение постоянным или нет), отправляет запрос. Этот запрос пушится другим узлам, которые выполняют обработку, и отправляют исходному узлу результаты. Исходный узел собирает их и отправляет результат клиенту. В общем, что-то вроде map reduce.
Не нравится мне то, что данная схема плохо масштабируется, в общей сложности нам потребуется N*N соединений между нодами. Быть может стоит ввести мастер ноды, к которым будут подключаться клиенты и которые будут просить данные у простых нодов и выполнять reduce стадию запроса. Но это усложнит конфигурацию.
Хочется добиться самоорганизации, что-бы избавиться от явного описания связей между нодами. Как быть?

Здравствуйте, Аноним, Вы писали:

А>Добрый день.
А>Я работаю над приложением, которое должно хорошо масштабироваться горизонтально. При этом, я хочу добиться того, что-бы развертывание и настройка моей системы были очень простыми. Желательно, что-бы конфигурирование вообще не требовалось. Предполагается, что все будет работать в рамках одного датацентра, все узлы будут в одной подсети или вообще на одной машине. Поэтому, я думаю сделать так: приложение состоит их одинаковых нодов, каждый нод, после старта начинает рассылку multicast пакетов, а также их чтение. Пакет содержит ip-адрес нода, а также служебную информацию. Помимо этого, пакет рассылается не открытым текстом, он зашифрован и подписан (secret key у всех нодов один и тот же). В общем, это должно привести к тому, что каждый узел будет знать обо всех остальных узлах.
А>Каждый узел — однопоточное приложение(по большей части, в один момент времени выполняется один запрос, но узел держит много подключений), после запуска читает данные с диска и больше туда не лезет. В дальнейшем, весь ввод/вывод, это обмен данными с клиентом а данные хранятся в памяти и меняются очень редко(такова специфика задачи), для того, что-бы использовать все процессоры можно запустить на машине несколько копий приложения, так я хочу избавиться от возможных проблем с многопоточностью.
А>Запрос выполняется следующим образом, клиент подключается к одному из узлов(сервер выбирается тупо, по round robin, правда я пока не решил, откуда он может получить список адресов, по которым можно подключаться, к тому же, я еще не знаю, будет подключение постоянным или нет), отправляет запрос. Этот запрос пушится другим узлам, которые выполняют обработку, и отправляют исходному узлу результаты. Исходный узел собирает их и отправляет результат клиенту. В общем, что-то вроде map reduce.
А>Не нравится мне то, что данная схема плохо масштабируется, в общей сложности нам потребуется N*N соединений между нодами. Быть может стоит ввести мастер ноды, к которым будут подключаться клиенты и которые будут просить данные у простых нодов и выполнять reduce стадию запроса. Но это усложнит конфигурацию.
А>Хочется добиться самоорганизации, что-бы избавиться от явного описания связей между нодами. Как быть?

Поглядите в сторону Erlang.

Здравствуйте, <Аноним>, Вы писали:

А>Хочется добиться самоорганизации, что-бы избавиться от явного описания связей между нодами. Как быть?
Вероятно, почитать про кластеры балансировки сетевой нагрузки. Но там узлы (прикладное ПО, работающее на физическом сервере) не знают друг о друге; просто совсем непонятно по сообщению, зачем вашим узлам знать друг о друге.

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

R>Здравствуйте, <Аноним>, Вы писали:

А>>Хочется добиться самоорганизации, что-бы избавиться от явного описания связей между нодами. Как быть?
R>Вероятно, почитать про кластеры балансировки сетевой нагрузки. Но там узлы (прикладное ПО, работающее на физическом сервере) не знают друг о друге; просто совсем непонятно по сообщению, зачем вашим узлам знать друг о друге.

Им и не нужно знать. Попробую описать задачу. Есть большой набор данных, он делится между узлами, каждый из них может обрабатывать только свою часть. О других ему ничего не нужно знать. Для выполнения запроса, нужно, что-бы каждый узел выполнил часть работы, а затем собрать их этих частей единый результат. Разделить данные и выполнить запрос на одном сервере я могу, а разбить это все на части — нет. Можно конечно использовать hadoop + zookeeper, но это как мне кажется overkill. Все ноды будут выполнять только одну задачу и знать им особо ничего не нужно.

Здравствуйте, <Аноним>, Вы писали:

А>Им и не нужно знать. Попробую описать задачу. Есть большой набор данных, он делится между узлами, каждый из них может обрабатывать только свою часть. О других ему ничего не нужно знать. Для выполнения запроса, нужно, что-бы каждый узел выполнил часть работы, а затем собрать их этих частей единый результат. Разделить данные и выполнить запрос на одном сервере я могу, а разбить это все на части — нет. Можно конечно использовать hadoop + zookeeper, но это как мне кажется overkill. Все ноды будут выполнять только одну задачу и знать им особо ничего не нужно.
В такой постановке мой совет выше не в дугу.

Здравствуйте, Аноним, Вы писали:

А>Хочется добиться самоорганизации, что-бы избавиться от явного описания связей между нодами. Как быть?

Взгляните на http://www.hazelcast.com/(самое простое), http://www.terracotta.org/, http://www.gridgain.com/. Это java. Или что-то подобное по ключевым словам distributed cache, data grid. Там должен быть реализован автоматический поиск нодов через мультикаст и их синхронизация.

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

M>Здравствуйте, Аноним, Вы писали:

А>>Хочется добиться самоорганизации, что-бы избавиться от явного описания связей между нодами. Как быть?

M>Взгляните на http://www.hazelcast.com/(самое простое), http://www.terracotta.org/, http://www.gridgain.com/. Это java. Или что-то подобное по ключевым словам distributed cache, data grid. Там должен быть реализован автоматический поиск нодов через мультикаст и их синхронизация.

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

Здравствуйте, Мишень-сан, Вы писали:

МС>Поглядите в сторону Erlang.

Проект написан на С++ и использует 0MQ, erlang слишком тормоз для нас да и особых преимуществ от его использования не будет, так как все будет строиться на простых как 5копеек, одно-поточных узлах/нодах. Основной цикл программы будет читать очередное сообщение из сокета, делать "особую магию" с тем, что узел хранит в памяти и отдавать результат приемнику. Ни асинхронности, ни многопоточности там не будет(по крайней мере в явном виде, 0MQ, внутри себя, использует многопоточность), это сознательный выбор