- •Общие задачи рис: обеспечение доступа к ресурсам, прозрачность, открытость, масштабируемость. Системы промежуточного уровня.
- •Синхронизация в рис: постановка задачи. Вычисление времени на локальном компьютере.
- •Принципы применения ntp/sntp-серверов точного времени.
- •Алгоритмы взаимного исключения: постановка задачи, централизованный алгоритм, распределенный алгоритм, алгоритм кольцевого маркера.
- •Реализация распределенной транзакции в субд Oracle 12c.
- •Репликация: определение, основные понятия, непротиворечивость реплик, параллельный доступ к реплике, плотная непротиворечивость, синхронная и асинхронная репликации.
- •Распространение обновлений
- •Протоколы распределения обновлений репликации: целевая (unicasting) и групповая (multicasting) рассылки, эпидемические протоколы, антиэнтпропия.
- •Надежность рис: доступность, безотказность, безопасность, ремонтопригодность. Способы достижения надежности рис.
- •Безопасность в рис: конфиденциальность, целостность, угрозы, аутентификация, авторизация, аудит, доверенная вычислительная база. Правила и механизмы защиты рис.
- •Парадигмы построения рис. Распределенные системы объектов. Реализации распределенных систем объектов. Основные принципы построение рис на платформе corba.
Принципы применения ntp/sntp-серверов точного времени.
NTP-серверы работают в иерархической сети, каждый уровень иерархии называется ярусом (stratum). Ярус 0 представлен эталонными часами. За эталон берется сигнал GPS (Global Positioning System) или службы ACTS (Automated Computer Time Service). На нулевом ярусе NTP-серверы не работают.
NTP-серверы яруса 1 получают данные о времени от эталонных часов. NTP-серверы яруса 2 синхронизируются с серверами яруса 1. Всего может быть до 15 ярусов.
NTP-серверы и NTP-клиенты получают данные о времени от серверов яруса 1, хотя на практике NTP-клиентам лучше не делать этого, поскольку тысячи индивидуальных клиентских запросов окажутся слишком большой нагрузкой для серверов яруса 1. Лучше настроить локальный NTP-сервер, который ваши клиенты будут использовать для получения информации о времени.
Иерархическая структура протокола NTP является отказоустойчивой и избыточной. Рассмотрим пример его работы. Два NTP-сервера яруса 2 синхронизируются с шестью различными серверами яруса 1, каждый — по независимому каналу. Внутренние узлы синхронизируются с внутренними NTP-серверами. Два NTP-сервера яруса 2 координируют время друг с другом. В случае отказа линии связи с сервером яруса 1 или с одним из серверов уровня 2 избыточный сервер уровня 2 берет на себя процесс синхронизации.
Аналогично узлы и устройства яруса 3 могут использовать любой из серверов яруса 2. Что еще более важно, так это то, что наличие избыточной сети серверов NTP гарантирует постоянную доступность серверов времени. Синхронизируясь с несколькими серверами точного времени, NTP использует данные всех источников, чтобы высчитать наиболее точное временя.
Стоит отметить, что протокол NTP не устанавливает время в чистом виде. Он корректирует локальные часы с использованием временного смещения, разницы между временем на NTP-сервере и локальных часах. Серверы и клиенты NTP настраивают свои часы, синхронизируясь с текущим временем постепенно либо единовременно.
Глобальное состояние РИС. Согласованное и несогласованное глобальные состояния. Алгоритм формирования глобального состояния РИС. Проверка завершения распределенного вычисления. Алгоритмы голосования: постановка задачи, алгоритм забияки.
Мультиагентные системы: 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]; если координатор не отвечает, то запускается процесс голосования.
Алгоритм забияки: пример
