Все процессы представлены в виде сбалансированного двоичного дерева. Каждый процесс имеет очередь запросов от себя и соседних процессов (1-го, 2-х или 3-х) и указатель в направлении владельца маркера.
Вход в критическую секцию
Если есть маркер, то процесс выполняет КС.
Если нет маркера, то процесс:
1) помещает свой запрос в очередь запросов
2) посылает сообщение «ЗАПРОС» в направлении владельца маркера и ждет сообщений.
Поведение процесса при приеме сообщений
Процесс, не находящийся внутри КС должен реагировать на сообщения двух видов -«МАРКЕР» и «ЗАПРОС».
А) Пришло сообщение «МАРКЕР»
М1. Взять 1-ый запрос из очереди и послать маркер его автору (концептуально, возможно себе);
М2. Поменять значение указателя в сторону маркера;
М3. Исключить запрос из очереди;
М4. Если в очереди остались запросы, то послать сообщение «ЗАПРОС» в сторону маркера.
Б) Пришло сообщение «ЗАПРОС».
1. Поместить запрос в очередь
2. Если нет маркера, то послать сообщение «ЗАПРОС» в сторону маркера, иначе (если есть маркер) - перейти на пункт М1.
Выход из критической секции
Если очередь запросов пуста, то при выходе ничего не делается, иначе - перейти к пункту М1.
Децентрализованный алгоритм на основе временных меток.
Алгоритм носит имя Ricart-Agrawala и является улучшением алгоритма, который предлжил Lamport.
Требуется глобальное упорядочение всех событий в системе по времени.
Вход в критическую секцию
Когда процесс желает войти в критическую секцию, он посылает всем процессам сообщение-запрос, содержащее имя критической секции, номер процесса и текущее время.
После посылки запроса процесс ждет, пока все дадут ему разрешение. После получения от всех разрешения, он входит в критическую секцию.
Поведение процесса при приеме запроса
Когда процесс получает сообщение-запрос, в зависимости от своего состояния по отношению к указанной критической секции он действует одним из следующих способов.
Название алгоритма |
TR |
SD |
MS/CS (LL) |
MS/CS (HL) |
Централизованный |
2T |
2T |
3 |
3 |
Круговой маркерный |
||||
Древовидный маркерный |
||||
Децентрализованный с временными метками |
NT |
T |
2(N-1) |
2(N-1) |
Широковещательный маркерный |
Распределенная система обычно имеет два существенно отличающихся компонента - непосредственно файловый сервис и сервис директорий.
5.1.1 Интерфейс файлового сервера
Для любой файловой системы первый фундаментальный вопрос - что такое файл. Во многих системах, таких как UNIX и MS-DOS, файл - не интерпретируемая последовательность байтов. На многих централизованных ЭВМ (IBM/370) файл представляется как последовательность записей, которую можно специфицировать ее номером или содержимым некоторого поля (ключом). Так, как большинство распределенных систем базируются на использовании среды UNIX и MS-DOS, то они используют первый вариант понятия файла.
Файл может иметь атрибуты (информация о файле, не являющаяся его частью). Типичные атрибуты - владелец, размер, дата создания и права доступа.
Важный аспект файловой модели - могут ли файлы модифицироваться после создания. Обычно могут, но есть системы с неизменяемыми файлами. Такие файлы освобождают разработчиков от многих проблем при кэшировании и размножении.
Защита обеспечивается теми же механизмами, что и в однопроцессорных ЭВМ - мандатами и списками прав доступа. Мандат - своего рода билет, выданный пользователю для каждого файла с указанием прав доступа. Список прав доступа задает для каждого файла список пользователей с их правами. Простейшая схема с правами доступа - UNIX схема, в которой различают три типа доступа (чтение, запись, выполнение), и три типа пользователей (владелец, члены его группы, и прочие).
Файловый сервис может базироваться на одной из двух моделей - модели загрузки/разгрузки
и модели удаленного доступа. В первом случае файл передается между клиентом (памятью или дисками) и сервером целиком, а во втором файл сервис обеспечивает множество операций (открытие, закрытие, чтение и запись части файла, сдвиг указателя, проверку и изменение атрибутов, и т.п.). Первый подход требует большого объема памяти у клиента, затрат на перемещение ненужных частей файла.
При втором подходе файловая система функционирует на сервере, клиент может не иметь дисков и большого объема памяти.
5.1.2 Интерфейс сервера директорий.
Обеспечивает операции создания и удаления директорий, именования и переименования файлов, перемещение файлов из одной директории в другую.
Определяет алфавит и синтаксис имен. Для спецификации типа информации в файле используется часть имени (расширение) либо явный атрибут.
Все распределенные системы позволяют директориям содержать поддиректории - такая файловая система называется иерархической. Некоторые системы позволяют создавать указатели или ссылки на произвольные директории, которые можно помещать в директорию. При этом можно строить не только деревья, но и произвольные графы (разница между ними очень важна для распределенных систем, поскольку в случае графа удаление связи может привести к появлению недостижимых поддеревьев. Обнаруживать такие поддеревья в распределенных системах очень трудно).
Ключевое решение при конструировании распределенной файловой системы - должны или не должны машины (или процессы) одинаково видеть иерархию директорий. Тесно связано с этим решением наличие единой корневой директории (можно иметь такую директорию с поддиректориями для каждого сервера).
Прозрачность именования.
Две формы прозрачности именования различают - прозрачность расположения (/server/d1/f1) и прозрачность миграции (когда изменение расположения файла не требует изменения имени).
Имеются три подхода к именованию:
· машина + путь;
· монтирование удаленных файловых систем в локальную иерархию файлов;
· единственное пространство имен, которое выглядит одинаково на всех машинах.
Последний подход необходим для достижения того, чтобы распределенная система выглядела как единый компьютер, однако он сложен и требует тщательного проектирования.
Синхронная фиксация упрощает восстановление, но связана с большими накладными расходами:
(1) Дополнительные служебные сообщения для реализации алгоритма.
(2) Синхронизационная задержка - нельзя посылать неслужебные сообщения во время работы алгоритма.
Если отказы редки, то указанные потери совсем не оправданы.
Фиксация может производиться асинхронно. В этом случае множество контрольных точек может быть неконсистентным. При откате происходит поиск подходящего консистентного множества путем поочередного отката каждого процесса в ту точку, в которой зафиксированы все посланные им и полученные другими сообщения (для ликвидации сообщений-сирот). Алгоритм опирается на наличие в стабильной памяти для каждого процесса журнала, отслеживающего номера посланных и полученных им сообщений, а также на некоторые предположения об организации взаимодействия процессов, необходимые для исключения «эффекта домино» (например, организация приложения по схеме сообщение-реакция-ответ).
7.2. Отказоустойчивость.
Изложенные выше методы восстановления после отказов для некоторых систем непригодны (управляющие системы, транзакции в on-line режиме) из-за прерывания нормального функционирования.
Чтобы избежать эти неприятности, создают системы, устойчивые к отказам. Такие системы либо маскируют отказы, либо ведут себя в случае отказа заранее определенным образом (пример - изменения, вносимые транзакцией в базу данных, становятся невидимыми при отказе).
Два механизма широко используются при обеспечении отказоустойчивости - протоколы голосования и протоколы принятия коллективного решения.
Протоколы голосования служат для маскирования отказов (выбирается правильный результат, полученный всеми исправными исполнителями).
Протоколы принятия коллективного решения подразделяются на два класса. Во-первых, протоколы принятия единого решения, в которых все исполнители являются исправными и должны либо все принять, либо все не принять заранее предусмотренное решение. Примерами такого решения являются решение о завершении итерационного цикла при достижении всеми необходимой точности, решение о реакции на отказ (этот протокол уже знаком нам - он использовался для принятия решения об откате всех процессов к контрольным точкам).
Во-вторых, протоколы принятия согласованных решений на основе полученных друг от друга данных. При этом необходимо всем исправным исполнителям получить достоверные данные от остальных исправных исполнителей, а данные от неисправных исполнителей проигнорировать.
Ключевой подход для обеспечения отказоустойчивости - избыточность (оборудования, процессов, данных).
7.2.1. Использование режима «горячего резерва» (второй пилот, резервное ПО).
Проблема переключения на резервный исполнитель.
7.2.2. Использование активного размножения.
Наглядный пример - тройное дублирование аппаратуры в бортовых компьютерах и голосование при принятии решения.
Другие примеры – размножение страниц в DSM и размножение файлов в распределенных файловых системах. При этом очень важным моментом является наличие механизма неделимых широковещательных рассылок сообщений (они должны приходить всем в одном порядке).
Алгоритмы голосования.
Общая схема использования голосования при размножении файлов может быть представлена следующим образом.
Файл может модифицироваться разными процессами только последовательно, а читаться всеми одновременно (протокол писателей-читателей). Все модификации файла нумеруются и каждая копия файла характеризуется номером версии – количеством ее модификаций. Каждой копии приписано некоторое количество голосов Vi. Пусть общее количество приписанных всем копиям голосов равно V. Определяется кворум записи Vw и кворум чтения Vr так, что
Vw > V/2 и Vw +Vr > V
Для записи требуется запросить разрешение у всех серверов и получить соответствующее количество (Vw) голосов от тех из них, кто владеет текущей версией копии (при получении разрешения процесс одновременно с количеством приписанных копии голосов получает и ее номер версии). Если его копия устарела (имеет меньший номер версии, чем максимальный из полученных номеров), то до модификации копии ее надо обновить.
Кворум записи выбран так, что два процесса не смогут одновременно получить разрешение на запись.
Выполнив модификацию, процесс рассылает ее всем владельцам текущей версии файла.
Для чтения достаточно получить необходимое число голосов (Vr) от любых серверов. Кворум чтения выбран так, что хотя бы один из тех серверов, от которых получено разрешение, является владельцем текущей копии файла. Необходимо отметить, что при одновременном запросе разрешений на запись несколькими процессами, возможна ситуация, когда голоса разделятся и ни один из процессов не получит кворума. Для выхода из таких ситуаций процессы должны по истечению тайм-аута отказаться от своего запроса (сообщить об этом всем серверам, приславшим им разрешения), а затем повторить запрос.
Описанная схема базируется на статическом распределении голосов. Различие в голосах, приписанных разным серверам, позволяет учесть их особенности (надежность, эффективность). Еще большую гибкость предоставляет метод динамического перераспределения голосов.
Для того, чтобы выход из строя некоторых серверов не привел к ситуации, когда невозможно получить кворум, применяется механизм изменения состава голосующих.
Протоколы принятия единого решения
Необходимо отметить, что в условиях отсутствия надежных коммуникаций (с ограниченным временем задержки) не может быть алгоритма достижения единого решения. Рассмотрим известную «проблему двух армий».
Армия зеленых численностью 5000 воинов располагается в долине.
Две армии синих численностью по 3000 воинов находятся далеко друг от друга в горах, окружающих долину. Если две армии синих одновременно атакуют зеленых, то они победят. Если же в сражение вступит только одна армия синих, то она будет полностью разбита.
Предположим, что командир 1-ой синей армии генерал Александр посылает (с посыльным) сообщение командиру 2-ой синей армии генералу Михаилу «Я имею план - давай атаковать завтра на рассвете». Посыльный возвращается к Александру с ответом Михаила - «Отличная идея, Саша. Увидимся завтра на рассвете». Александр приказывает воинам готовиться к атаке на рассвете.
Однако, чуть позже Александр вдруг осознает, что Михаил не знает о возвращении посыльного и поэтому может не отважиться на атаку. Тогда он отправляет посыльного к Михаилу чтобы подтвердить, что его (Михаила) сообщение получено Александром и атака должна состояться.
Посыльный прибыл к Михаилу, но теперь тот боится, что не зная о прибытии посыльного Александр может не решиться на атаку. И т.д. Ясно, что генералы никогда не достигнут согласия.
Предположим, что такой протокол согласия c конечным числом сообщений существует. Удалив избыточные последние сообщения, получим минимальный протокол. Самое последнее сообщение является существенным (поскольку протокол минимальный). Если это сообщение не дойдет по назначению, то войны не будет. Но тот, кто посылал это сообщение, не знает, дошло ли оно. Следовательно, он не может считать протокол завершенным и не может принять решение об атаке. Даже с надежными процессорами (генералами), принятие единого решения невозможно при ненадежных коммуникациях.
Теперь предположим, что коммуникации надежны, а процессоры нет.
Классический пример протокола принятия согласованных решений
- задача «Византийских генералов».
В этой задаче армия зеленых находится в долине, а n синих генералов возглавляют свои армии, расположенные в горах. Связь осуществляется по телефону и является надежной, но из n генералов m являются предателями. Предатели активно пытаются воспрепятствовать согласию лояльных генералов.
Согласие в данном случае заключается в следующем. Каждый генерал знает, сколько воинов находится под его командой. Ставится цель, чтобы все лояльные генералы узнали численности всех лояльных армий, т.е. каждый из них получил один и тот же вектор длины n, в котором i-ый элемент либо содержит численность i-ой армии (если ее командир лоялен) либо не определен (если командир предатель).
Соответствующий рекурсивный алгоритм был предложен в 1982 г. (Lamport).
Проиллюстрируем его для случая n=4 и m=1. В этом случае алгоритм осуществляется в 4 шага.
1 шаг. Каждый генерал посылает всем остальным сообщение, в котором указывает численность своей армии. Лояльные генералы указывают истинное количество, а предатели могут указывать различные числа в разных сообщениях. Генерал-1 указал 1 (одна тысяча воинов), генерал-2 указал 2, генерал-3 указал трем остальным генералам соответственно x,y,z, а генерал-4 указал 4.
2-ой шаг. Каждый формирует свой вектор из имеющейся информации.
Получается:
vect1 (1,2,x,4)
vect2 (1,2,y,4)
vect3 (1,2,3,4)
vect4 (1,2,z,4)
3-ий шаг. Каждый посылает свой вектор всем остальным (генерал-3 посылает опять произвольные значения).
Генералы получают следующие вектора:
g1 |
g2 |
g3 |
g4 |
(1,2,y,4) |
(1,2,x,4) |
(1,2,x,4) |
(1,2,x,4) |
(a,b,c,d) |
(e,f,g,h) |
(1,2,y,4) |
(1,2,y,4) |
(1,2,z.4) |
(1,2,z.4) |
(1,2,z.4) |
(i,j,k.l) |
2. Доступ к синхронизационным переменным запрещен (задерживается), пока не выполнены все предыдущие операции записи;
3. Доступ к данным (запись, чтение) запрещен, пока не выполнены все предыдущие обращения к синхронизационным переменным.
Первое правило определяет, что все процессы «видят» обращения к синхронизационным переменным в определенном (одном и том же) порядке .
Второе правило гарантирует, что выполнение процессором операции обращения к синхронизационной переменной возможно только после «выталкивания» конвейера (полного завершения выполнения на всех процессорах всех предыдущих операций записи переменных, выданных данным процессором). Третье правило определяет, что при обращении к обычным (не синхронизационным) переменным на чтение или запись, все предыдущие обращения к синхронизационным переменным должны быть выполнены полностью. Выполнив синхронизацию перед обращением к общей переменной, процесс может быть уверен, что получит правильное значение этой переменной.
a) Пример допустимой последовательности событий.
P1: |
W(x)1 |
W(x)2 |
S |
|||
P2: |
R(x)1 |
R(x)2 |
S |
|||
P3: |
R(x)2 |
R(x)1 |
S |
б) Пример недопустимой последовательности событий.
P1: |
W(x)1 |
W(x)2 |
S |
||
P2: |
S |
R(x)1 |
В отличие от предыдущих моделей консистентности, модель слабой консистентности ориентирована на консистентность групповых операций чтения/записи. Эта модель наиболее эффективна для приложений, в которых отдельные (изолированные) обращения к общим переменным встречаются довольно редко.
Большинство систем используют ту или иную форму двухуровневого именования. Файлы (и другие объекты) имеют символические имена для пользователей, но могут также иметь внутренние двоичные имена для использования самой системой. Например, в операции открыть файл пользователь задает символическое имя, а в ответ получает двоичное имя, которое и использует во всех других операциях с данным файлом.
Способы формирования двоичных имен различаются в разных системах:
· если имеется несколько не ссылающихся друг на друга серверов (директории не содержат ссылок на объекты других серверов), то двоичное имя может быть то же самое, что и в ОС UNIX;
· имя может указывать на сервер и файл;
· в качестве двоичных имен при просмотре символьных имен возвращаются мандаты, содержащие помимо прав доступа либо физический номер машины с сервером, либо сетевой адрес сервера, а также номер файла.
В ответ на символьное имя некоторые системы могут возвращать несколько двоичных имен (для файла и его дублей), что позволяет повысить надежность работы с файлом.
5.1.3 Семантика разделения файлов.
UNIX-семантика.
Естественная семантика однопроцессорной ЭВМ - если за операцией записи следует чтение, то результат определяется последней из предшествующих операций записи. В распределенной системе такой семантики достичь легко только в том случае, когда имеется один файл-сервер, а клиенты не имеют кэшей. При наличии кэшей семантика нарушается. Надо либо сразу все изменения в кэшах отражать в файлах, либо менять семантику разделения файлов.
Еще одна проблема - трудно сохранить семантику общего указателя файла (в UNIX он общий для открывшего файл процесса и его дочерних процессов) - для процессов на разных ЭВМ трудно иметь общий указатель.
Неизменяемые файлы - очень радикальный подход к изменению семантики разделения файлов.
Только две операции - создать и читать. Можно заменить новым файлом старый - т.е.
можно менять директории. Если один процесс читает файл, а другой его подменяет, то можно позволить первому процессу доработать со старым файлом в то время, как другие процессы могут уже работать с новым.
Семантика сессий.
Изменения открытого файла видны только тому процессу (или машине), который производит эти изменения, а лишь после закрытия файла становятся видны другим процессам (или машинам). Что происходит, если два процесса одновременно работали с одним файлом - либо результат будет определяться процессом, последним закрывшим файл, либо можно только утверждать, что один из двух вариантов файла станет текущим.
Транзакции.
Процесс выдает операцию «НАЧАЛО ТРАНЗАКЦИИ», сообщая тем самым, что последующие операции должны выполняться без вмешательства других процессов. Затем выдает последовательность чтений и записей, заканчивающуюся операцией «КОНЕЦ ТРАНЗАКЦИИ». Если несколько транзакций стартуют в одно и то же время, то система гарантирует, что результат будет таким, каким бы он был в случае последовательного выполнения транзакций (в неопределенном порядке). Пример - банковские операции.
Можно избежать подтверждения получения сервером сообщения-запроса от клиента, если ответ сервера должен последовать скоро.
Для обеспечения коллективных коммуникаций введены следующие функции:
· барьер для всех членов группы (BARRIER);
· передача сообщения всем членам группы от одного (BROADCAST);
· сбор данных от всех членов группы для одного (GATHER);
· рассылка данных всем членам группы от одного (SCATTER);
· сбор данных от всех членов группы для всех (ALLGATHER);
· рассылка данных всем членам группы от всех (ALLTOALL);
· глобальные операции (сумма, максимум, и т.п.), когда результат сообщается всем членам группы или только одному. При этом пользователь может сам определить глобальную операцию - функцию;
Схема перемещения данных между 4 процессами
Данные
Pr-0 | A0 | A0 | |||||||||||||||||||||||
Pr-1 | BROADCAST | A0 | |||||||||||||||||||||||
Pr-2 | è | A0 | |||||||||||||||||||||||
Pr-3 | A0 | ||||||||||||||||||||||||
Pr-0 | A0 | A1 | A2 | A3 | SCATTER | A0 | |||||||||||||
Pr-1 | è | A1 | |||||||||||||||||
Pr-2 | GATHER | A2 | |||||||||||||||||
Pr-3 | ç | A3 |
Pr-0 | A0 | B0 | C0 | D0 | A0 | ||||||||||||||||||||
Pr-1 | A0 | B0 | C0 | D0 | ALLGATHER | B0 | |||||||||||||||||||
Pr-2 | A0 | B0 | C0 | D0 | ç | C0 | |||||||||||||||||||
Pr-3 | A0 | B0 | C0 | D0 | D0 |
Pr-0 |
A0 |
A1 |
A2 |
A3 |
A0 |
B0 |
C0 |
D0 |
||||
Pr-1 |
B0 |
B1 |
B2 |
B3 |
ALLTOALL |
A1 |
B1 |
C1 |
D1 |
|||
Pr-2 |
C0 |
C1 |
C2 |
C3 |
è |
A2 |
B2 |
C2 |
D2 |
|||
Pr-3 |
D0 |
D1 |
D2 |
D3 |
A3 |
B3 |
C3 |
D3 |
Все компьютеры в распределенной системе связаны между собой коммуникационной сетью. Коммуникационные сети подразделяются на широкомасштабные (Wide Area Networks, WANs) и локальные (Local Area Networks, LANs).
Широкомасштабные сети
WAN состоит из коммуникационных ЭВМ, связанных между собой коммуникационными линиями (телефонные линии, радиолинии, спутниковые каналы, оптоволокно) и обеспечивающих транспортировку сообщений.
Обычно используется техника store-and-forward, когда ссобщения передаются из одного компьютера в следующий с промежуточной буферизацией.
Коммутация линий (телефонные разговоры) требует резервирования линий на время всего сеанса общения двух устройств.
Пакетная коммутация основана на разбиении сообщений в пункте отправления на порции (пакеты), посылке пакетов по адресу назначения, и сборке сообщения из пакетов в пункте назначения. При этом линии используются эффективнее, сообщения могут передаваться быстрее, но требуется работа по разбиению и сборке сообщений, а также возможны задержки (для передачи речи или музыки такой метод не годится).
Семиуровневая модель ISO
ISO OSI (International Standards Organizations»s Reference Model of Open Systems Interconnection) организует коммуникационные протоколы в виде семи уровней и специфицирует функции каждого уровня.
Локальные сети.
Особенности LAN:
· географическая область охвата невелика (здание или несколько зданий);
· высокая скорость передачи (10-100 Mbps);
· малая вероятность ошибок передачи.
Свойственные многоуровневой модели ISO OSI накладные расходы являются причиной того, что в LAN применяются более простые протоколы.
Описанные выше трудности показывают, что глобальная контрольная точка, состоящая из произвольной совокупности локальных контрольных точек, не обеспечивает восстановления взаимодействующих процессов.
Для распределенных систем запоминание согласованного глобального состояния является серьезной теоретической проблемой.
Множество контрольных точек называется строго консистентным, если во время его фиксации никаких обменов между процессами не было. Оно соответствует понятию строго консистентного глобального состояния, когда все посланные сообщения получены и нет никаких сообщений в каналах связи. Множество контрольных точек называется консистентным, если для любой зафиксированной операции приема сообщения, соответствующая операция посылки также зафиксирована (нет сообщений-сирот).
Простой метод фиксации консистентного множества контрольных точек - фиксация локальной контрольной точки после каждой операции посылки сообщения. При этом посылка сообщения и фиксация должны быть единой неделимой операцией (транзакцией). Множество последних локальных контрольных точек является консистентным (но не строго консистентным).
Чтобы избежать потерь сообщений при восстановлении с использованием консистентного множества контрольных точек необходимо повторить отправку тех сообщений, квитанции о получении которых стали недействительными в результате отката. Используя временные метки сообщений можно распознавать сообщения-призраки и избежать бесконечного восстановления.
7.1.5. Синхронная фиксация контрольных точек и восстановление.
Ниже описываются алгоритмы создания консистентного множества контрольных точек и использования их для восстановления без опасности бесконечного зацикливания.
Алгоритм создания консистентного множества контрольных точек.
К распределенной системе алгоритм предъявляет следующие требования.
(1) Процессы взаимодействуют посредством посылки сообщений через коммуникационные каналы.
(2) Каналы работают по алгоритму FIFO. Коммуникационные протоколы точка-точка гарантируют невозможность пропажи сообщений из-за ошибок коммуникаций или отката к контрольной точке. (Другой способ обеспечения этого - использование стабильной памяти для журнала посылаемых сообщений и фиксации идентификатора последнего полученного по каналу сообщения).
Эта консистентность представляет собой еще один пример модели консистентности, которая ориентирована на использование критических секций. Также, как и в предыдущей модели, эта модель консистентности требует от программистов (или компиляторов) использование механизма захвата/освобождения для выполнения критических секций. Однако, в этой модели требуется, чтобы каждая общая переменная была связана с некоторой синхронизационной переменной (типа семафора или события), при этом, если доступ к элементам массива, или различным отдельным переменным, может производиться независимо (параллельно), то эти элементы массива (общие переменные) должны быть связаны с разными синхронизационными переменными. Таким образом, вводится связь между синхронизационными переменными и общими переменными, которые они охраняют.
Кроме того, критические секции, охраняемые одной синхронизационной переменной могут быть двух типов:
· секция с монопольным доступом (для модификации переменных);
· секция с немонопольным доступом (для чтения переменных).
Рассмотрим использование синхронизационных переменных.
Каждая синхронизационная переменная имеет временного владельца - последний процесс, захвативший доступ к этой переменной. Этот владелец может в цикле выполнять критическую секцию не посылая при этом сообщений другим процессорам. Процесс, который в данный момент не является владельцем синхронизационной переменной, но требующий ее захвата, должен послать запрос текущему владельцу этой переменной для получения значения этой переменной и права собственности на
синхронизационную переменную. Разрешена ситуация, когда синхронизационная переменная имеет несколько владельцев, но только в том случае, если связанные с этой переменной общие данные используются только для чтения.
Ниже приведены формальные правила, определяющие модель консистентности по входу:
(1) Процесс не может захватить синхронизационную переменную до того, пока не обновлены все переменные этого процесса, охраняемые захватываемой синхронизационной переменной;
Консистентность |
Описание |
Строгая |
Упорядочение всех доступов к разделяемым данным по абсолютному времени |
Последовательная |
Все процессы видят все записи разделяемых данных в одном и том же порядке |
Причинная |
Все процессы видят все причинно-связанные записи данных в одном и том же порядке |
Процессорная |
PRAM-консистентность + когерентность памяти |
PRAM |
Все процессоры видят записи любого процессора в одном и том же порядке |
Консистентность |
Описание |
Слабая |
Разделяемые данные можно считать консистентными только после выполнения синхронизации |
По выходу |
Разделяемые данные становятся консистентными после выхода из критической секции |
По входу |
Связанные с критической секцией разделяемые данные становятся консистентными при входе в нее |
В системе со слабой консистентностью возникает проблема при обращении к синхронизационной переменной: система не имеет информации о цели этого обращения - или процесс завершил модификацию общей переменной, или готовится прочитать значение общей переменной. Для более эффективной реализации модели консистентности система должна различать две ситуации: вход в критическую секцию и выход из нее.
В модели консистентности по выходу введены специальные функции обращения к синхронизационным переменным:
(1) ACQUIRE - захват синхронизационной переменной, информирует систему о входе в критическую секцию;
(2) RELEASE - освобождение синхронизационной переменной, определяет завершение критической секции.
Захват и освобождение используется для организации доступа не ко всем общим переменным, а только к тем, которые защищаются данной синхронизационной переменной. Такие общие переменные называют защищенными переменными.
Пример допустимой последовательности событий для модели с консистентностью по выходу. (Acq(L) - захват синхронизационной переменной L; Rel(L) - освобождение синхронизационной переменной).
P1: |
Acq(L) |
W(x)1 |
W(x)2 |
Rel(L) |
||||
P2: |
Acq(L) |
R(x)2 |
Rel(L) |
|||||
P3: |
R(x)1 |
Следующие правила определяют требования к модели консистентности по выходу:
(1) До выполнения обращения к общей переменной, должны быть полностью выполнены все предыдущие захваты синхронизационных переменных данным процессором.
(2) Перед освобождением синхронизационной переменной должны быть закончены все операции чтения/записи, выполнявшиеся процессором прежде.
(3) Реализация операций захвата и освобождения синхронизационной переменной должны удовлетворять требованиям процессорной консистентности (последовательная консистентность не требуется).
При выполнении всех этих требований и использовании методов захвата и освобождения, результат выполнения программы будет таким же, как при выполнении этой программы в системе с последовательной моделью консистентности.
Существует модификация консистентности по выходу - «ленивая». В отличие от описанной («энергичной») консистентности по выходу, она не требует выталкивания всех модифицированных данных при выходе из критической секции. Вместо этого, при запросе входа в критическую секцию процессу передаются текущие значения защищенных разделяемых данных (например, от процесса, который последним находился в критической секции, охраняемой этой синхронизационной переменной). При повторных входах в критическую секцию того же самого процесса не требуется никаких обменов сообщениями.
1) Сообщения точка-точка (если известно, кто потребитель).
2) Если неизвестно, кто потребитель, то:
· сообщения широковещательные;
· сообщения в ответ на запрос.
3) Если неизвестно, кто потребляет и кто производит, то:
· сообщения и запросы через координатора:
· широковещательный запрос.
(Message Passing Interface Forum, May 5, 1994
http://www.mpi-forum.org)
(1) Цели:
·
Создать интерфейс прикладного программирования (не только для компиляторов или библиотек реализации систем);
· Обеспечить возможность эффективных коммуникаций (избежать копирования из памяти в память, позволить совмещение вычислений и коммуникаций или разгрузку на коммуникационный процессор там, где он есть);
· Разрешить расширения для использования в гетерогенной среде;
· Исходить из надежности коммуникаций (пользователь не должен бороться с коммуникационными сбоями - это дело коммуникационных подсистем нижнего уровня);
· Определить интерфейс, который бы не слишком отличался от используемых в настоящее время, таких как PVM, Express, P4, и пр.;
· Определить интерфейс, который мог бы быстро быть реализован на многих продаваемых платформах без серьезной переделки нижележащего коммуникационного и системного ПО.
**************************************************************
(2) Что включено в MPI ?
· Коммуникации точка-точка;
· Коллективные операции;
· Группы процессов;
· Коммуникационные контексты;
· Простой способ создания процессов для модели SPMD (одна программа используется для обработки разных данных на разных процессорах);
· Топология процессов.
**************************************************************
(3) Что не включено в MPI ?
· Явные операции с разделяемой памятью и явная поддержка нитей (процессов с общей памятью);
· Операции, которые требуют больше поддержки от операционных систем, чем действующие в настоящее время стандарты на ОС (например, получение сообщений через механизм прерываний, активные сообщения);
Отказом системы называется поведение системы, не удовлетворяющее ее спецификациям. Последствия отказа могут быть различными.
Отказ системы может быть вызван отказом (неверным срабатыванием) каких-то ее компонентов (процессор, память, устройства ввода/вывода, линии связи, или программное обеспечение).
Отказ компонента может быть вызван ошибками при конструировании, при производстве или программировании. Он может быть также вызван физическим повреждением, изнашиванием оборудования, некорректными входными данными, ошибками оператора, и многими другими причинами.
Отказы могут быть случайными, периодическими или постоянными.
Случайные отказы (сбои) при повторении операции исчезают.
Причиной такого сбоя может служить, например, электромагнитная помеха от проезжающего мимо трамвая. Другой пример - редкая ситуация в последовательности обращений к операционной системе от разных задач.
Периодические отказы повторяются часто в течение какого-то времени, а затем могут долго не происходить. Примеры - плохой контакт, некорректная работа ОС после обработки аварийного завершения задачи.
Постоянные (устойчивые) отказы не прекращаются до устранения их причины - разрушения диска, выхода из строя микросхемы или ошибки в программе.
Отказы по характеру своего проявления подразделяются на «византийские» (система активна и может проявлять себя по-разному, даже злонамеренно) и «пропажа признаков жизни» (частичная или полная). Первые распознать гораздо сложнее, чем вторые. Свое название они получили по имени Византийской империи (330-1453 гг.), где расцветали конспирация, интриги и обман.
Для обеспечения надежного решения задач в условиях отказов системы применяются два принципиально различающихся подхода - восстановление решения после отказа системы (или ее компонента) и предотвращение отказа системы (отказоустойчивость).
7.1. Восстановление после отказа.
Восстановление может быть прямым (без возврата к прошлому состоянию) и возвратное.
Прямое восстановление основано на своевременном обнаружении сбоя и ликвидации его последствий путем приведения некорректного состояния системы в корректное.
Такое восстановление возможно только для определенного набора заранее предусмотренных сбоев.
При возвратном восстановлении происходит возврат процесса (или системы) из некорректного состояния в некоторое из предшествующих корректных состояний. При этом возникают следующие проблемы.
(1) Потери производительности, вызванные запоминанием состояний, восстановлением запомненного состояния и повторением ранее выполненной работы, могут быть слишком высоки.
(2) Нет гарантии, что сбой снова не повторится после восстановления.
(3) Для некоторых компонентов системы восстановление в предшествующее состояние может быть невозможно (торговый автомат).
Тем не менее этот подход является более универсальным и применяется гораздо чаще первого. Дальнейшее рассмотрение будет ограничено только данным подходом.
Для восстановления состояния в традиционных ЭВМ применяются два метода (и их комбинация), основанные на промежуточной фиксации состояния либо ведении журнала выполняемых операций. Они различаются объемом запоминаемой информацией и временем, требуемым для восстановления.
Применение подобных методов в распределенных системах наталкивается на следующие трудности.
SEND, RECEIVE (адресат/отправитель, [тэг,] адрес памяти, длина)
адресация - физический/логический номер процессора, уникальный идентификатор динамически создаваемого процесса, служба имен (сервер имен или широковещание - broadcasting).
Обычно пересылка в соседний компьютер требует три копирования - из памяти процесса-отправителя в буфер ОС на своем компьютере, пересылка между буферами ОС, копирование в память процесса-получателя.
Блокирующие операции send (до освобождения памяти с данными или до завершения фактической передачи) и неблокирующие.
Буферизуемые и небуферизуемые (rendezvous или с потерей информации при отсутствии receive).
Надежные и ненадежные.
Операционные системы распределенных вычислительных систем (распределенные ОС).
(Крюков В.А.)
Распределенная система - совокупность независимых компьютеров, которая представляется пользователю единым компьютером (metacomputer), использование которого не намного сложнее, чем использование персональной ЭВМ.
Введение в ОС однопроцессорных ЭВМ.
Два взгляда:
· менеджер ресурсов;
· один слой в множестве слоев абстрактных машин.
Представление ОС как менеджера ресурсов
Управление файлами | |||||
Управление процессами | Управление памятью | Управление устройствами | |||
Процессоры | Память | Устройства |
Представление ОС как абстрактной машины
Абстрактная машина | |||||
Интерфейс пользователя | Интерфейс программы | ||||
Языки управления заданиями Командные языки Окна, меню, пиктограммы | Система команд | Системные вызовы Процессы Память Файлы Информационные функции |
Место ОС среди ПО
Прикладное ПО (отдельные приложения, пакеты прикладных программ, информационные системы, САПР) | |
Системное ПО (ОС + системы программирования, СУБД, графические библиотеки, сервисные программы) |
История ОС.
1940-е и 1950-е
"Персональные ЭВМ" - "пультовый режим"
Библиотека программ ввода-вывода, служебная программа.
Середина 1950-х
Пакетная обработка. Однопрограммный и мультипрограммный режимы.
Инструкция оператору -> паспорт задачи (простейший язык управления заданиями).
Требования к аппаратуре:
· защита памяти;
· прерывания;
· привилегированный режим;
· таймер.
Как обеспечить мультипрограммный режим без таких механизмов.
Середина 1960-х
Режим разделения времени.
Терминалы, квантование, свопинг, страничная и сегментная организация.
1970-е
Многопроцессорные ЭВМ, многомашинные комплексы, сети ЭВМ
Сетевая ОС |
Распределенная ОС |
ОС мульти процессора |
|
Компьютерная система выглядит как виртуальная однопроцессорная ЭВМ |
НЕТ |
ДА |
ДА |
Одна и та же ОС выполняется на всех процессорах |
НЕТ |
ДА |
ДА |
Сколько копий ОС имеется в памяти |
N |
N |
1 |
Как осуществляются коммуникации |
Разделяемые файлы |
Сообщения |
Разделяемая память |
Требуется ли согласованный сетевой протокол |
ДА |
ДА |
НЕТ |
Имеется ли единая очередь выполняющихся процессов |
НЕТ |
НЕТ |
ДА |
Имеется хорошо определенная семантика разделения файлов |
Обычно НЕТ |
ДА |
ДА |
Прозрачность расположения |
Пользователь не должен знать, где расположены ресурсы |
Прозрачность миграции |
Ресурсы могут перемещаться без изменения их имен |
Прозрачность размножения |
Пользователь не должен знать, сколько копий существует |
Прозрачность конкуренции |
Множество пользователей разделяет ресурсы автоматически |
Прозрачность параллелизма |
Работа может выполняться параллельно без участия пользователя |
Планирование процессоров очень сильно влияет на производительность мультипроцессорной системы. Можно выделить следующие главные причины деградации производительности:
1) Накладные расходы на переключение процессора. Они определяются не только переключениями контекстов процессов, но и (при переключении на процессы другого приложения) перемещениями страниц виртуальной памяти, а также порчей кэша (информация в кэше другому приложению не нужна и будет заменена).
2) Переключение на другой процесс в тот момент, когда текущий процесс выполнял критическую секцию, а другие процессы активно ожидают входа в критическую секцию. В этом случае потери будут велики (хотя вероятность прерывания выполнения коротких критических секций мала).
Применяются следующие стратегии борьбы с деградацией производительности.
1) Совместное планирование, при котором все процессы одного приложения (неблокированные) одновременно выбираются на процессоры и одновременно снимаются с них (для сокращения переключений контекста).
2) Планирование, при котором находящиеся в критической секции процессы не прерываются, а активно ожидающие входа в критическую секцию процессы не выбираются до тех пор, пока вход в секцию не освободится.
3) Процессы планируются на те процессоры, на которых они выполнялись в момент их снятия (для борьбы с порчей кэша). При этом может нарушаться балансировка загрузки процессоров.
4) Планирование с учетом "советов" программы (во время ее выполнения). В ОС Mach имеется два класса таких советов (hints) - указания (разной степени категоричности) о снятии текущего процесса с процессора, а также указания о том процессе, который должен быть выбран взамен текущего.
Предположим, что контрольные точки x1 и y1 зафиксированы для восстановления процессов X и Y, соответственно.
Если процесс Y сломается после получения сообщения m, и оба процесса будут восстановлены (x1,y1), то сообщение m будет потеряно (его потеря будет неотличима от потери в канале).
7.1.3. Проблема бесконечного восстановления.
Процесс Y сломался до получения сообщения n1 от X. Когда Y
вернулся в состояние y1, в нем не оказалось записи о посылке сообщения m1. Поэтому X должен вернуться в состояние x1.
После отката Y посылает m2 и принимает n1 (сообщение-призрак). Процесс X после отката к x1 посылает n2 и принимает m2. Однако X после отката уже не имеет записи о посылке n1. Поэтому Y должен повторно откатиться к y1. Теперь X должен откатиться к x1, поскольку он принял m2, о посылке которого в Y нет записи. Эта ситуация будет повторяться бесконечно.
Процесс - это выполнение программы. Компоненты процесса - выполняющаяся программа, ее данные, ее ресурсы (например, память), и состояние выполнения.
Традиционно, процесс имеет собственное адресное пространство и его состояние характеризуется следующей информацией:
· таблицы страниц (или сегментов);
· дескрипторы файлов;
· заказы на ввод-вывод;
· регистры;
· и т.п.
Большой объем этой информации делает дорогими операции создания процессов, их переключение.
Потребность в легковесных процессах, нитях (threads) возникла еще на однопроцессорных ЭВМ (физические процессы или их моделирование, совмещение обменов и счета), но для использования достоинств многопроцессорных ЭВМ с общей памятью они просто необходимы.
Процессы могут быть независимыми, которые не требуют какой-либо синхронизации и обмена информацией (но могут конкурировать за ресурсы), либо взаимодействующими.
2.2. Взаимодействие процессов
Если приложение реализовано в виде множества процессов (или нитей), то эти процессы (нити) могут взаимодействовать двумя основными способами:
· посредством разделения памяти (оперативной или внешней)
· посредством передачи сообщений
При взаимодействии через общую память процессы должны синхронизовать свое выполнение.
Различают два вида синхронизации - взаимное исключение критических интервалов и координация процессов.
Критические секции. Недетерминизм, race condition (условия гонок).
Процесс p1 выполняет оператор I = I+J,
а процесс p2 - оператор I = I-K
машинные коды выглядят так:
Load R1,I Load R1,I
Load R2,J Load R2,K
Add R1,R2 Sub R1,R2
Store R1,I Store R1,I
Результат зависит от порядка выполнения этих команд.
Требуется взаимное исключение критических интервалов.
5 Распределенные файловые системы
Две главные цели.
Сетевая прозрачность.
Самая важная цель - обеспечить те же самые возможности доступа к файлам, распределенным по сети ЭВМ, которые обеспечиваются в системах разделения времени на централизованных ЭВМ.
Высокая доступность.
Другая важная цель - обеспечение высокой доступности. Ошибки систем или осуществление операций копирования и сопровождения не должны приводить к недоступности файлов.
Понятие файлового сервиса и файлового сервера.
Файловый сервис - это то, что файловая система предоставляет своим клиентам, т.е. интерфейс с файловой системой.
Файловый сервер - это процесс, который реализует файловый сервис.
Пользователь не должен знать, сколько файловых серверов имеется и где они расположены.
Так, как файловый сервер обычно является обычным пользовательским процессом, то в системе могут быть различные файловые серверы, предоставляющие различный сервис (например, UNIX файл сервис и MS-DOS файл сервис).
Выше были рассмотрены аспекты распределенных файловых систем, которые видны пользователю. Ниже рассматриваются реализационные аспекты.
5.2.1 Использование файлов.
Приступая к реализации очень важно понимать, как система будет использоваться. Приведем результаты некоторых исследований использования файлов (статических и динамических) в университетах. Очень важно оценивать представительность исследуемых данных.
a)
большинство файлов имеют размер менее 10К. (Следует перекачивать целиком).
b) чтение встречается гораздо чаще записи. (Кэширование).
c) чтение и запись последовательны, произвольный доступ редок.
(Упреждающее кэширование, чтение с запасом, выталкивание после записи следует группировать).
d) большинство файлов имеют короткое время жизни. (Создавать файл в клиенте и держать его там до уничтожения).
e) мало файлов разделяются (кэширование в клиенте и семантика сессий).
f) существуют различные классы файлов с разными свойствами.
(Следует иметь в системе разные механизмы для разных классов).
5.2.2 Структура системы.
Есть ли разница между клиентами и серверами? Имеются системы, где все машины имеют одно и то же ПО и любая машина может предоставлять файловый сервис. Есть системы, в которых серверы являются обычными пользовательскими процессами и могут быть сконфигурированы для работы на одной машине с клиентами или на разных. Есть системы, в которых клиенты и серверы являются фундаментально разными машинами с точки зрения аппаратуры или ПО (требуют различных ОС, например).
Второй вопрос - должны ли быть файловый сервер и сервер директорий отдельными серверами или быть объединенными в один сервер. Разделение позволяет иметь разные серверы директорий (UNIX, MS-DOS) и один файловый сервер. Объединение позволяет сократить коммуникационные издержки.
В случае разделения серверов и при наличии разных серверов директорий для различных поддеревьев возникает следующая проблема.
Если первый вызванный сервер будет поочередно обращаться ко всем следующим, то возникают большие коммуникационные расходы. Если же первый сервер передает остаток имени второму, а тот третьему, и т.д., то это не позволяет использовать RPC.
Возможный выход - использование кэша подсказок. Однако в этом случае при получении от сервера директорий устаревшего двоичного имени клиент должен быть готов получить отказ от файлового сервера и повторно обращаться к серверу директорий (клиент может не быть конечным пользователем!).
Последний важный вопрос - должны ли серверы хранить информацию о клиентах.
Серверы с состоянием. Достоинства.
a) Короче сообщения (двоичные имена используют таблицу открытых файлов).
b) выше эффективность (информация об открытых файлах может храниться в оперативной памяти).
c) блоки информации могут читаться с упреждением.
d) убедиться в достоверности запроса легче, если есть состояние (например, хранить номер последнего запроса).
e) возможна операция захвата файла.
Серверы без состояния. Достоинства.
a) устойчивость к ошибкам.
b) не требуется операций ОТКРЫТЬ/ЗАКРЫТЬ.
c) не требуется память для таблиц.
d) нет ограничений на число открытых файлов.
e) нет проблем при крахе клиента.
5.2.3 Кэширование.
В системе клиент-сервер с памятью и дисками есть четыре потенциальных места для хранения файлов или их частей.
Во-первых, хранение файлов на дисках сервера. Нет проблемы консистентности, так как только одна копия файла существует. Главная проблема - эффективность, поскольку для обмена с файлом требуется передача информации в обе стороны и обмен с диском.
Во-вторых, кэширование в памяти сервера. Две проблемы - помещать в кэш файлы целиком или блоки диска, и как осуществлять выталкивание из кэша.
Коммуникационные издержки остаются.
Избавиться от коммуникаций позволяет кэширование в машине клиента.
В третьих, кэширование на диске клиента.
Оно может не дать преимуществ перед кэшированием в памяти сервера, а сложность повышается значительно.
Поэтому рассмотрим подробнее четвертый вариант - организацию кэширования в памяти клиента. При этом имеется три различных способа:
a) кэширование в каждом процессе. (Хорошо, если c файлом активно работает один процесс - многократно открывает и закрывает файл, читает и пишет, например в случае процесса базы данных).
b) кэширование в ядре. (Накладные расходы на обращение к ядру).
c) кэш-менеджер в виде отдельного процесса. (Ядро освобождается от функций файловой системы, но на пользовательском уровне трудно эффективно использовать память, особенно в случае виртуальной памяти. Возможна фиксация страниц, чтобы избежать обменов с диском).
Оценить выбор того или иного способа можно только при учете характера приложений и данных о быстродействии процессоров, памятей, дисков и сети.
Консистентность кэшей.
Кэширование в клиенте создает серьезную проблему - сложность поддержания кэшей в согласованном состоянии.
Алгоритм со сквозной записью.
Этот алгоритм, при котором модифицируемые данные пишутся в кэш и сразу же посылаются серверу, не является решением проблемы. При его использовании в мультипроцессорах все кэши “подслушивали” шину, через которую там осуществляются все “сквозные” записи в память, и сразу же обновляли находящиеся в них данные. В распределенной системе такое “подслушивание” невозможно, а требуется перед использованием данных из кэша проверять, не устарела ли информация в кэше. Кроме того, запись вызывает коммуникационные расходы.
Алгоритм с отложенной записью. Через регулярные промежутки времени все модифицированные блоки пишутся в файл (так на традиционных ЭВМ работает OC UNIX). Эффективность выше, но семантика непонятна пользователю.
Алгоритм записи в файл при закрытии файла. Реализует семантику сессий. Такой алгоритм, на первый взгляд, кажется очень неудачным для ситуаций, когда несколько процессов одновременно открыли один файл и модифицировали его.
Однако, аналогичная картина происходит и на традиционной ЭВМ, когда два процесса на одной ЭВМ открывают файл, читают его, модифицируют в своей памяти и пишут назад в файл.
Алгоритм централизованного управления. Можно выдержать семантику UNIX, но не эффективно, ненадежно, и плохо масштабируется.
5.2.4 Размножение.
Система может предоставлять такой сервис, как поддержание для указанных файлов нескольких копий на различных серверах. Главные цели:
1) Повысить надежность.
2) Повысить доступность (крах одного сервера не вызывает недоступность размноженных файлов.
3) Распределить нагрузку на несколько серверов.
Имеются три схемы реализации размножения:
a) Явное размножение (непрозрачно). В ответ на открытие файла пользователю выдаются несколько двоичных имен, которые он должен использовать для явного дублирования операций с файлами.
b) «Ленивое» размножение. Сначала копия создается на одном сервере, а затем он сам автоматически создает (в свободное время) дополнительные копии и обеспечивает их поддержание.
c) Симметричное размножение. Все операции одновременно вызываются в нескольких серверах и одновременно выполняются.
Протоколы коррекции.
Просто посылка сообщений с операцией коррекции каждой копии является не очень хорошим решением, поскольку в случае аварий некоторые копии могут остаться не скорректированными. Имеются два алгоритма, которые решают эту проблему.
(1) Метод размножения главной копии. Один сервер объявляется главным, а остальные - подчиненными. Все изменения файла посылаются главному серверу. Он сначала корректирует свою локальную копию, а затем рассылает подчиненным серверам указания о коррекции. Чтение файла может выполнять любой сервер. Для защиты от рассогласования копий в случае краха главного сервера до завершения им рассылки всех указаний о коррекции, главный сервер до выполнения коррекции своей копии запоминает в стабильной памяти задание на коррекцию.
Слабость - выход из строя главного сервера не позволяет выполнять коррекции.
(2) Метод голосования. Идея - запрашивать чтение и запись файла у многих серверов (запись - у всех!). Запрос может получить одобрение у половины серверов плюс один. При этом должно быть согласие относительно номера текущей версии файла. Этот номер увеличивается на единицу с каждой коррекцией файла. Можно использовать различные значения для кворума чтения (Nr) и кворума записи (Nw). При этом должно выполняться соотношение Nr+Nw>N. Поскольку чтение является более частой операцией, то естественно взять Nr=1. Однако в этом случае для кворума записи потребуются все серверы.
5.2.5 Пример: Sun Microsystem’s Network File System (NFS).
Изначально реализована Sun Microsystem в 1985 году для использования на своих рабочих станций на базе UNIX. В настоящее время поддерживается также другими фирмами для UNIX и других ОС (включая MS-DOS). Интересны следующие аспекты NFS - архитектура, протоколы и реализация.
Архитектура NFS.
Позволяет иметь произвольное множество клиентов и серверов на произвольных ЭВМ локальной или широкомасштабной сети.
Каждый сервер экспортирует некоторое число своих директорий для доступа к ним удаленных клиентов. При этом экспортируются директории со всеми своими поддиректориями, т.е. фактически поддеревья. Список экспортируемых директорий хранится в специальном файле, что позволяет при загрузке сервера автоматически их экспортировать.
Клиент получает доступ к экспортированным директориям путем их монтирования. Если клиент не имеет дисков, то может монтировать директории в свою корневую директорию.
Если несколько клиентов одновременно смонтировали одну и ту же директорию, то они могут разделять файлы в общей директории без каких либо дополнительных усилий. Простота - достоинство NFS.
Протоколы NFS.
Поскольку одна из целей NFS - поддержка гетерогенных систем, клиенты и серверы могут работать на разных ЭВМ с различной архитектурой и различными ОС.
Поэтому необходимо иметь строгие протоколы их взаимодействия. NFS имеет два таких протокола.
Первый протокол поддерживает монтирование. Клиент может послать серверу составное имя директории (имя пути) и попросить разрешения на ее монтирование. Куда будет монтировать директорию клиент для сервера значения не имеет и поэтому не сообщается ему. Если путь задан корректно и директория определена как экпортируемая, то сервер возвращает клиенту дескриптор директории. Дескриптор содержит поля, уникально идентифицирующие тип ЭВМ, диск, номер i-вершины (понятие ОС UNIX) для данной директории, а также информацию о правах доступа к ней. Этот дескриптор используется клиентом в последующих операциях с директорией.
Многие клиенты монтируют требуемые удаленные директории автоматически при запуске (используя командную процедуру shell-интерпретатора ОС UNIX).
Версия ОС UNIX, разработанная Sun (Solaris), имеет свой специальный режим автоматического монтирования. С каждой локальной директорией можно связать множество удаленных директорий. Когда открывается файл, отсутствующий в локальной директории, ОС посылает запросы всем серверам (владеющим указанными директориями). Кто ответит первым, директория того и будет смонтирована. Такой подход обеспечивает и надежность, и эффективность (кто свободнее, тот раньше и ответит). При этом подразумевается, что все альтернативные директории идентичны. Поскольку NFS не поддерживает размножение файлов или директорий, то такой режим автоматического монтирования в основном используется для директорий с кодами программ или других редко изменяемых файлов.
Второй протокол - для доступа к директориям и файлам. Клиенты посылают сообщения, чтобы манипулировать директориями, читать и писать файлы. Можно получить атрибуты файла. Поддерживается большинство системных вызовов ОС UNIX, исключая OPEN и CLOSE. Для получения дескриптора файла по его символическому имени используется операция LOOKUP, отличающаяся от открытия файла тем, что никаких внутренних таблиц не создается.
Таким образом, серверы в NFS не имеют состояния (stateless). Поэтому для захвата файла используется специальный механизм.
NFS использует механизм защиты UNIX. В первых версиях все запросы содержали идентификатор пользователя и его группы (для проверки прав доступа). Несколько лет эксплуатации системы показали слабость такого подхода. Теперь используется криптографический механизм с открытыми ключами для проверки законности каждого запроса и ответа. Данные не шифруются.
Все ключи, используемые для контроля доступа, поддерживаются специальным сервисом (и серверами) - сетевым информационным сервисом (NIS). Храня пары (ключ, значение), сервис обеспечивает выдачу значения кода при правильном подтверждении ключей. Кроме того, он обеспечивает отображение имен машин на их сетевые адреса, и другие отображения. NIS-серверы используют схему главный -подчиненные для реализации размножения («ленивое» размножение).
Реализация NFS.
|
|
|||||||
|
P1: W(x)1 |
P1: W(x)1 |
--------------------------------> t |
-----------------------------------> t |
P2: R(x)1 |
P2: R(x)0 R(x)1 |
а) |
б) |
P1: |
W(x)1 |
W(y)1 |
||||
P2: |
W(z)1 |
|||||
P3: |
R(x)0 |
R(y)0 |
R(z)1 |
R(y)0 |
||
P4: |
R(x)0 |
R(y)1 |
R(z)1 |
R(x)1 |
P1: |
W(x)1 |
W(y)1 |
||||
P2: |
W(z)1 |
|||||
P3: |
R(x)0 |
R(y)1 |
R(z)0 |
R(y)1 |
||
P4: |
R(x)1 |
R(y)1 |
R(z)0 |
R(x)1 |
P1: |
W(x)1 |
W(y)1 |
||||
P2: |
W(z)1 |
|||||
P3: |
R(x)0 |
R(y)0 |
R(z)1 |
R(y)0 |
||
P4: |
R(x)0 |
R(y)1 |
R(z)0 |
R(x)1 |
P1: |
W(x)1 |
W(y)1 |
||||
P2: |
W(z)1 |
|||||
P3: |
R(x)1 |
R(y)0 |
R(z)1 |
R(y)1 |
||
P4: |
R(x)0 |
R(y)1 |
R(z)1 |
R(x)0 |
P1: |
W(x)1 |
||||
P2: |
R(x)1 |
W(x)2 |
|||
P3: |
R(x)2 |
R(x)1 |
|||
P4: |
R(x)1 |
R(x)2 |
P1: |
W(x)1 |
W(x)3 |
||||
P2: |
R(x)1 |
W(x)2 |
||||
P3: |
R(x)1 |
R(x)3 |
R(x)2 |
|||
P4: |
R(x)1 |
R(x)2 |
R(X)3 |
P1: |
W(x)1 |
||||
P2: |
R(x)1 |
W(x)2 |
|||
P3: |
R(x)1 |
R(x)2 |
|||
P4: |
R(x)2 |
R(x)1 |
Процесс P1 |
Процесс P2 |
.......... |
.......... |
a = 1; |
b = 1; |
if (b==0) kill (P2); |
if (a==0) kill (P1); |
.......... |
.......... |
Развивает MPI в следующих направлениях:
·
Динамическое создание и уничтожение процессов (важно для работы в сетях ЭВМ).
· Односторонние коммуникации и средства синхронизации для организации взаимодействия процессов через общую память (для эффективной работы на системах с непосредственным доступом процессоров к памяти других процессоров).
· Параллельные операции ввода-вывода (для эффективного использования существующих возможностей параллельного доступа многих процессоров к различным дисковым устройствам).
4 Синхронизация в распределенных системах
Обычно децентрализованные алгоритмы имеют следующие свойства:
(1) Относящаяся к делу информация распределена среди множества ЭВМ.
(2) Процессы принимают решение на основе только локальной информации.
(3) Не должно быть единственной критической точки, выход из строя которой приводил бы к краху алгоритма.
(4) Не существует общих часов или другого источника точного глобального времени.
Первые три пункта все говорят о недопустимости сбора всей информации для принятия решения в одно место. Обеспечение синхронизации без централизации требует подходов, отличных от используемых в традиционных ОС.
Последний пункт также очень важен - в распределенных системах достигнуть согласия относительно времени совсем непросто. Важность наличия единого времени можно оценить на примере программы make в ОС UNIX.
Главные теоретические проблемы - отсутствие глобальных часов и невозможность зафиксировать глобальное состояние (для анализа ситуации - обнаружения дедлоков, для организации промежуточного запоминания).
Аппаратные часы (скорее таймер - счетчик временных сигналов и регистр с начальным значением счетчика) основаны на кварцевом генераторе и могут в разных ЭВМ различаться по частоте.
В 1978 году Lamport показал, что синхронизация времени возможна, и предложил алгоритм для такой синхронизации. При этом он указал, что абсолютной синхронизации не требуется. Если два процесса не взаимодействуют, то единого времени им не требуется. Кроме того, в большинстве случаев согласованное время может не иметь ничего общего с астрономическим временем, которое объявляется по радио. В таких случаях можно говорить о логических часах.
Для синхронизации логических часов Lamport определил отношение «произошло до». Выражение a-->b читается как «a произошло до b» и означает, что все процессы согласны, что сначала произошло событие «a», а затем «b». Это отношение может в двух случаях быть очевидным:
(1) Если оба события произошли в одном процессе.
(2) Если событие «a» есть операция SEND в одном процессе, а событие «b» - прием этого сообщения другим процессом.
Отношение --> является транзитивным.
Если два события «x» и «y» случились в различных процессах, которые не обмениваются сообщениями, то отношения x-->y и y-->x являются неверными, а эти события называют одновременными.
Введем логическое время С таким образом, что если a-->b, то C(a) < C(b)
Алгоритм:
(1) Часы Ci увеличивают свое значение с каждым событием в процессе Pi:
Ci = Ci + d (d > 0, обычно равно 1)
(2) Если событие «a» есть посылка сообщения «m» процессом Pi, тогда в это сообщение вписывается временная метка tm=Ci(a). В момент получения этого сообщения процессом Pj его время корректируется следующим образом:
Cj = max(Cj,tm+d)
Поясним на примере, как осуществляется эта коррекция.
Логическое время без коррекции. Логическое время с коррекцией.
0 |
0 |
0 |
0 |
0 |
0 |
|||||
6 |
>-- |
8 |
10 |
6 |
>-- |
8 |
10 |
|||
12 |
à |
16 |
20 |
12 |
à |
16 |
20 |
|||
18 |
24 |
>-- |
30 |
18 |
24 |
>-- |
30 |
|||
24 |
32 |
à |
40 |
24 |
32 |
à |
40 |
|||
30 |
40 |
50 |
30 |
40 |
50 |
|||||
36 |
48 |
-< |
60 |
36 |
48 |
-< |
60 |
|||
42 |
56 |
ç |
70 |
42 |
61 |
ç |
70 |
|||
48 |
-< |
64 |
80 |
48 |
-< |
69 |
80 |
|||
54 |
ç |
72 |
90 |
70 |
ç |
77 |
90 |
|||
60 |
80 |
100 |
76 |
85 |
100 |
На рисунке показаны три процесса (X,Y,Z), взаимодействующие через сообщения. Вертикальные черточки показывают на временной оси моменты запоминания состояния процесса для восстановления в случае отказа. Стрелочки соответствуют сообщениям и показывают моменты их отправления и получения.
Если процесс X сломается, то он может быть восстановлен с состояния x3 без какого-либо воздействия на другие процессы.
Предположим, что процесс Y сломался после посылки сообщения m и был возвращен в состояние y2. В этом случае получение сообщения m зафиксировано в x3, а его посылка не отмечена в y2. Такая ситуация, возникшая из-за несогласованности глобального состояния, не должна допускаться (пример - сообщение содержит сумму, переводимую с одного счета на другой). Сообщение m в таком случае называется сообщением-сиротой. Процесс X должен быть возвращен в предыдущее состояние x2 и конфликт будет ликвидирован.
Предположим теперь, что процесс Z сломается и будет восстановлен в состояние z2. Это приведет к откату процесса Y в y1, а затем и процессов X и Z в начальные состояния x1 и y1. Этот эффект известен как эффект домино.
Send, receive - подход ввода/вывода
Более естественный подход, применяемый в централизованных ЭВМ - вызов процедур.
Birrell and Nelson (1984) (независимо и раньше - Илюшин А.И.,1978) предложили позволить вызывающей программе находиться на другой ЭВМ.
MPP с распределенной памятью может рассматриваться как частный случай локальной сети. Решетка транспьютеров, в которой каждый транспьютер параллельно с вычислениями может обмениваться одновременно по 8 каналам с 4 соседями, является хорошим примером, для которого будут формулироваться различные экзаменационные задачи.
Время передачи сообщения между двумя узлами транспьютерной матрицы (характеристики аппаратуры - время старта передачи Ts, время передачи одного байта информации соседнему узлу Tb, процессорные операции, включая чтение из памяти и запись в память считаются бесконечно быстрыми). За время Ts+ Tb транспьютер может передать 1 байт информации своим четырем соседям и принять от них 4 байта информации (по одному байту от каждого).
Конвейеризация и параллельное использование нескольких маршрутов.
Многие распределенные алгоритмы требуют, чтобы один из процессов выполнял функции координатора, инициатора или некоторую другую специальную роль. Выбор такого специального процесса будем называть выбором координатора. При этом очень часто бывает не важно, какой именно процесс будет выбран. Можно считать, что обычно выбирается процесс с самым большим уникальным номером. Могут применяться разные алгоритмы, имеющие одну цель - если процедура выборов началась, то она должна закончиться согласием всех процессов относительно нового координатора.
Алгоритм «задиры».
Если процесс обнаружит, что координатор очень долго не отвечает, то инициирует выборы. Процесс P проводит выборы следующим образом:
1) P посылает сообщение «ВЫБОРЫ» всем процессам с большими чем у него номерами.
2) Если нет ни одного ответа, то P считается победителем и становится координатором.
3) Если один из процессов с большим номером ответит, то он берет на себя проведение выборов. Участие процесса P в выборах заканчивается.
В любой момент процесс может получить сообщение «ВЫБОРЫ» от одного из коллег с меньшим номером. В этом случае он посылает ответ «OK», чтобы сообщить, что он жив и берет проведение выборов на себя, а затем начинает выборы (если к этому моменту он уже их не вел). Следовательно, все процессы прекратят выборы, кроме одного - нового координатора. Он извещает всех о своей победе и вступлении в должность сообщением «КООРДИНАТОР».
Если процесс выключился из работы, а затем захотел восстановить свое участие, то он проводит выборы (отсюда и название алгоритма).
Круговой алгоритм.
Алгоритм основан на использовании кольца (физического или логического), но без маркера. Каждый процесс знает следующего за ним в круговом списке. Когда процесс обнаруживает отсутствие координатора, он посылает следующему за ним процессу сообщение «ВЫБОРЫ» со своим номером. Если следующий процесс не отвечает, то сообщение посылается процессу, следующему за ним, и т.д., пока не найдется работающий процесс. Каждый работающий процесс добавляет в список работающих свой номер и переправляет сообщение дальше по кругу. Когда процесс обнаружит в списке свой собственный номер (круг пройден), он меняет тип сообщения на «КООРДИНАТОР» и оно проходит по кругу, извещая всех о списке работающих и координаторе (процессе с наибольшим номером в списке). После прохождения круга сообщение удаляется.
Централизованный алгоритм.
Все процессы запрашивают у координатора разрешение на вход в критическую секцию и ждут этого разрешения. Координатор обслуживает запросы в порядке поступления. Получив разрешение процесс входит в критическую секцию. При выходе из нее он сообщает об этом координатору. Количество сообщений на одно прохождение критической секции - 3.
Недостатки алгоритма - обычные недостатки централизованного алгоритма (крах координатора или его перегрузка сообщениями).
Алгоритм с круговым маркером.
Все процессы составляют логическое кольцо, когда каждый знает, кто следует за ним. По кольцу циркулирует маркер, дающий право на вход в критическую секцию. Получив маркер (посредством сообщения точка-точка) процесс либо входит в критическую секцию (если он ждал разрешения) либо переправляет маркер дальше. После выхода из критической секции маркер переправляется дальше, повторный вход в секцию при том же маркере не разрешается.
Проблемы.
Если маркер потеряется, то его надо регенерировать. Обнаружить потерю тяжело (время прихода неизвестно).
Если какой-то процесс перестанет функционировать, то алгоритм не работает. Однако восстановление проще, чем в других случаях. Наличие квитанций позволит обнаружить такой процесс в момент передачи маркера (если поломка произошла вне критического интервала). Переставший функционировать процесс должен быть исключен из логического кольца, для этого придется каждому знать текущую конфигурацию кольца.