Цитата(COVD @ 13.10.2011, 03:59  ) |
| И если супернод "умирает", то его обязанности переходят к другому ноду. |
хм.. идея
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > распределение "работы" между вычислительными едини |
| Автор: boostcoder 13.10.2011, 03:23 |
| всем привет. имеется сеть вычислительных единиц состоящая из равноправных узлов/нодов. каждый нод сети представляет собой вычислительную единицу предоставляющую некоторые элементарные операции. сервис - группа нодов объединенных по предназначению. так, к примеру, математические функции: add, sub, div, mul, образуют математический сервис. каждый нод сети может одновременно являться пользователем других сервисов/нодов. к примеру, нод предоставляющий операцию mul может реализовывать ее при помощи нода предоставляющего операцию add. все ноды сети "знают" о всех остальных нодах/сервисах. к примеру, если пользователь сети хочет работать с сервисом предоставляющим add, ему необходимо знать "контактные" данные математического сервиса. в сети, может быть более одного нода предоставляющего одинаковые функции. в сети не может быть одинаковых сервисов. вопрос: как в такой сети распределять нагрузку между нодами если имеются одинаковые ноды? в сети сервера нет. все ноды равноправны. к примеру, есть два нода предоставляющих операцию add. и есть два пользователя математического сервиса активно использующие add. кто и как должен распределять запросы пользователей? спасибо. |
| Автор: boostcoder 13.10.2011, 03:39 |
| лучшей, мне кажется идея, изменить архитектуру сети так, чтоб была возможность назначать супернод, при конфигурации сети. в таком случае, юзер будет подключаться именно к нему, и он(супернод) будет выполнять своего рода роль сервера. возможно есть еще какие-то предложения? |
| Автор: COVD 13.10.2011, 03:59 |
| И если супернод "умирает", то его обязанности переходят к другому ноду. Так работает вычислительный grid. |
| Автор: boostcoder 13.10.2011, 04:14 | ||
хм.. идея |
| Автор: fish9370 13.10.2011, 09:57 | ||||
тогда уже лучше чтобы супернод назначался не при конфигурации, а путем переговоров/голосования.. в случае смерти супернода, просто запускается повторный процесс выбора супернода.. |
| Автор: Artemon 13.10.2011, 12:26 |
| А сеть какого типа ? Если физическая архитектура сети не сложная, то можно сделать чтобы каждый нод широковещательными UDP пакетами рассылал свою нагрузку. И соответствено перед тем как подключиться к одному из двух одинаковых нодов, выбирается нод с меньшей нагрузкой. В этом случае надобность в суперноде отпадает. |
| Автор: boostcoder 13.10.2011, 12:30 | ||||||
какими данными предлагаешь обмениваться? пропускной способностью сети? временем пинга? конфигурацией железа?
это понятно. не понятно то, каким образом пользователи сети узнаю о том что супернод изменился. Добавлено через 1 минуту и 19 секунд
не получится. ноды могут располагаться в других сетях/подсетях, и просто в интернете. |
| Автор: bsa 13.10.2011, 12:43 | ||||
Кстати, если у супернода все соединения с остальными нодами рвутся, то он должен стать обычным нодом. Возможен альтернативный вариант: 1. каждый нод считает себя супернодом, если не имеет связей с другими нодами 2. при установке связи одного нода с другим они обмениваются информацией о супернодах. Если суперноды разные, то каждый нод посылает (если, конечно, он сам не является супер) своему суперноду информацию, что обнаружен другой супернод. В итоге суперноды сами между собой проводят перевыборы и о результатах сообщают все заинтересованным нодам. |
| Автор: fish9370 13.10.2011, 12:58 | ||||
ну поскольку каждый нод должен что-то считать, то я бы начал с выбора самой производительной железки (процессор, память, дисковая подсистема), затем по пропускной способности сети, по количеству хопов, по временым задержкам, по доступности (статистические данные).. сюда же можно включить выбор по ОС, предположим, что тесты показывают большую производительность в линуксе при одинаковом железе.. по географическому признаку.. по старшенству ip-адреса (если речь о локалке, при прочих равных) и т.д.
в централизованой системе, без возможности широковещательного сообщения - никак.. |
| Автор: boostcoder 13.10.2011, 12:59 | ||||||||
у меня есть две мысли по этому поводу: 1. при архитектуре сети без супернода(так как сейчас), пользователи подключаются к любому одному ноду. 2. при архитектуре сети с супернодом, пользователи подключаются именно к нему. осталось понять все моменты второго пункта.
логично.
вроде как это лучший вариант... Добавлено через 2 минуты и 3 секунды
uptime нужно обязательно учесть. ибо супернодом может стать нод, который только что появился в сети. и который так же внезапно может пропасть. какой смысл его назначать супернодом. |
| Автор: fish9370 13.10.2011, 13:08 |
| нехватает описания процедуры поиска нодов в сети.. широковещалка в интернете не работает.. могут потребоваться дополнительные корневые (опорные) ноды.. |
| Автор: boostcoder 13.10.2011, 13:16 | ||
ноды не ищут себеподобных. нод, для того чтоб стать частью сервиса, знает о расположении любого одного нода того сервиса. при подключении к нему, происходит рассылка его данных по остальным нодам этого сервиса. |
| Автор: fish9370 13.10.2011, 13:35 | ||
| это многое упрощает, но возникает вопрос надежности.. будет ли эта цепь замкнутой? что будет в случае утраты одного из нодов? как будут передоваться уведомления, от нода к ноду или через супернод?
при такой схеме желательно, чтобы нод знал как минимум двух нодов, образуя двунаправленный список.. |
| Автор: boostcoder 13.10.2011, 13:42 | ||||||||
что конкретно имеется ввиду?
как только один из нодов опознает пропажу какого-либо нода, он изымет информацию о нем из своей базы, и сообщит об этом всем остальным нодам.
от нода к ноду.
на данный момент, каждый нод знает все обо всех нодах. возможно, это является избыточным... но пока не устоялась структура и принципы организации сети, эта информация не мешает. |
| Автор: fish9370 13.10.2011, 13:46 | ||
тогда вопросов больше нет.. |
| Автор: bsa 13.10.2011, 18:08 | ||
есть у этого варианта недостаток - запаришься реализовывать.  |