Введение в облачные и распределенные информационные системы

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

Он дает знать об этом всем мастерам приложений, и мастера приложений перенаправляют свои задачи.

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

И наконец, мастер приложения также периодически пульсирует менеджеру ресурсов.

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

Далее сам менеджер ресурсов может перестать работать.

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

Протокол Gossip

Далее мы рассмотрим класс протоколов, называемый gossip протоколами сплетен или эпидемическими протоколами.

Но сначала начнем с постановки задачи.

Задача, которую gossip пытается решить, называется групповой передачей multicast.

Итак, что такое групповая передача?

Предположим, что у вас есть группа процессов, или группа узлов.

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

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

Это задача многоадресной рассылки.

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

Теперь, многоадресная рассылка отличается от широковещательной трансляции, где у вас есть блок информации, который вы хотите отправить на всю сеть, – многоадресная рассылка более ограничена.

Она работает только внутри определенной группы узлов или группы процессов.

Итак, какие требования для протокола многоадресной рассылки?

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

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

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

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

Обычно IP протокол многоадресной рассылки протокол реализован в маршрутизаторах и коммутаторах.

Однако этот протокол может быть не включен во многих маршрутизаторах и коммутаторах.

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

И одним из самых простых способов многоадресной рассылки является централизованный подход.

У вас есть отправитель, который имеет список получателей, и он просто в цикле for или while отправляет каждому из этих получателей пакет либо UDP User Datagram Protocol, либо TCP Transmission Control Protocol, который содержит информацию.

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

Если отправитель перестанет работать в середине цикла, тогда только половина получателей получит рассылку.