Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
RIS.docx
Скачиваний:
1
Добавлен:
01.07.2025
Размер:
3 Мб
Скачать
☆
  1. Принципы применения ntp/sntp-серверов точного времени.

  2. NTP-серверы работают в иерархической сети, каждый уровень иерархии называется ярусом (stratum). Ярус 0 представлен эталонными часами. За эталон берется сигнал GPS (Global Positioning System) или службы ACTS (Automated Computer Time Service). На нулевом ярусе NTP-серверы не работают.

  3. NTP-серверы яруса 1 получают данные о времени от эталонных часов. NTP-серверы яруса 2 синхронизируются с серверами яруса 1. Всего может быть до 15 ярусов.

  4. NTP-серверы и NTP-клиенты получают данные о времени от серверов яруса 1, хотя на практике NTP-клиентам лучше не делать этого, поскольку тысячи индивидуальных клиентских запросов окажутся слишком большой нагрузкой для серверов яруса 1. Лучше настроить локальный NTP-сервер, который ваши клиенты будут использовать для получения информации о времени.

  5. Иерархическая структура протокола NTP является отказоустойчивой и избыточной. Рассмотрим пример его работы. Два NTP-сервера яруса 2 синхронизируются с шестью различными серверами яруса 1, каждый — по независимому каналу. Внутренние узлы синхронизируются с внутренними NTP-серверами. Два NTP-сервера яруса 2 координируют время друг с другом. В случае отказа линии связи с сервером яруса 1 или с одним из серверов уровня 2 избыточный сервер уровня 2 берет на себя процесс синхронизации.

  6. Аналогично узлы и устройства яруса 3 могут использовать любой из серверов яруса 2. Что еще более важно, так это то, что наличие избыточной сети серверов NTP гарантирует постоянную доступность серверов времени. Синхронизируясь с несколькими серверами точного времени, NTP использует данные всех источников, чтобы высчитать наиболее точное временя.

  7. Стоит отметить, что протокол NTP не устанавливает время в чистом виде. Он корректирует локальные часы с использованием временного смещения, разницы между временем на NTP-сервере и локальных часах. Серверы и клиенты NTP настраивают свои часы, синхронизируясь с текущим временем постепенно либо единовременно.

  8. Глобальное состояние РИС. Согласованное и несогласованное глобальные состояния. Алгоритм формирования глобального состояния РИС. Проверка завершения распределенного вычисления. Алгоритмы голосования: постановка задачи, алгоритм забияки.

Мультиагентные системы: ERP, Глобальные электрические системы (электричество нельзя накопить, электростанцию нельзя остановить).

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

Глобальное состояние распределенной системы:

I: P1[send:{m1}, receive:{}],

P2[send:{}, receive:{}],

P3[send:{m2}, receive:{}]

II: P1[send:{m3}, receive:{m2, m5}],

P2[send:{m4, m5, m6}, receive:{m1}],

P3[send:{}, receive:{m3, m4}]

III: P1[send:{m1,m3}, receive:{m2}],

P2[send:{m4, m5}, receive:{m1}],

P3[send:{m2}, receive:{}]

IV: P1[send:{m1,m3}, receive:{m5}],

P2[send:{m4}, receive:{m1}],

P3[send:{m2}, receive:{}]

Алгоритм формирования глобального состояния: все узлы связаны однонаправленными каналами, по которым они могут отправлять сообщения.

Сообщение: D[K,P] – информация (P) пересылаемая между узлами, имеет уникальный идентификатор (K).

Инициатор: узел, запрашивающий глобальное состояние.

Маркер: служебное сообщение M[S,V,I] – запрос на получение глобального состояния, содержащее уникальные идентификаторы состояния (S) и инициатора (I) и версию состояния(V).

Локальное состояние: L[M, send, receive] состояние узла (идентификаторы принятых (receive) и отправленных(send) сообщений), вычисляется относительно предыдущего локального состояния, идентифицируется маркером M[S,V,I], вызвавшим его формирование.

Инициатор: фиксирует свое локальное состояния и оправляет маркер M[S,V,I] во все исходящие каналы.

Узел: получает маркер M[S,V,I], если нет локального состояния с идентификатором S, то формирует его; если есть локальное состояние, то формирует локальное состояние относительно предыдущего с идентификатором M[S,V,I]; отправляет маркер, во все выходные узлы; отправляет инициатору локальное состояние.

Проверка завершения распределенного вычисления: сообщения раздают задания на вычисления узлу, сообщение считается полученным (может быть зафиксированным в локальном состоянии, если оно обработано (вычислено)).

Continue[M] – ответ на маркер M[S,V,I], требующий, повторного запроса локального состояния.

Ready[M] – ответ на маркер M[S,V,I], указывающий на завершение вычислений в узле.

Узел: получает маркер M[S,V,I], если с предыдущего состояния не поступали сообщения, формирует локальное состояние и оправляется маркер M[S,V,I] во все выходные узлы; если сообщения поступали, то возвращает отправившему маркер узлу Continue[M].

Узел: если возвращается Ready[M] со всех выходных узлов, в узел приславший маркер оправляется ответ Ready[M].

Узел: если возвращается Continue[M] с выходного канала, в соответствующий узел снова отправляется маркер M[S,V,I].

Инициатор: если получил Ready[M] со всех узлов, то распределенное вычисление завершилось, если из некоторых узлов пришло Continue[M], то повторная отправка M[S,V,I].

Инициатор: может быть несколько с разными идентификаторами и идентификаторами маркеров.

Распределенная система: работа не приостанавливается.

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

Координатор: компонент (узел) распределенной системы, имеющий специальное назначение (инициатор, арбитр, хранитель централизованной информации). Пример: арбитр BIOS over TCP/IP (хранение таблицы символических имен компютеров).

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

Алгоритм забияки (bully algorithm): выбор процесса с самым большим идентификатором.

Алгоритм забияки: любой из узлов (инициатор), обнаруживших, что координатор не отвечает, запускает голосование.

Алгоритм забияки: если узел-инициатор имеет самый большой идентификатор, то он объявляет себя координатором и рассылает всем сообщение ICoordinator[I], где I-собственный идентификатор.

Алгоритм забияки: узел-инициатор отправляет всем другим узлам с большими, чем у него идентификаторами сообщение Vote[I], где I-собственный идентификатор.

Алгоритм забияки: если узел получает сообщение Vote[I], то он отвечает отправителю сообщением IReady[I], где I-собственный идентификатор и отправляет всем узлам с большими, чем у него идентификаторами, сообщение Vote[I].

Алгоритм забияки: если узел-инициатор, не получает ни одного ответа IReady[I] на отправленное Vote[I], то он объявляет себя координатором и рассылает всем сообщение ICoordinator[I].

Алгоритм забияки: вновь подключившийся узел, ищет координатора, опрашивая все узлы сообщением GetCoordinator[I], где I-собственный идентификатор и ждет ответа ICoordinator[I]; если координатор не отвечает, то запускается процесс голосования.

Алгоритм забияки: пример

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]