Файл: Определение и задачи распределительной системы.pdf

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

Другой вариант - организация операционной системы в виде двух частей:

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

Схема организации операционной системы на основе микроядра приведена ниже:

Рисунок 7

TODO: Достоинства и недостатки микрояденных систем.

Примеры микроядерных операционных систем:

• AIX
• Mac OS X (Mach 3.0)
• OpenVMS
• Minix

Мультипроцессорные операционные системы

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

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

Семафор может быть представлен как целое число, поддерживающее две операции - инкремент и декремент. При этом операция декремента на семафоре, имеющем нулевое значение блокируется до того момента, пока не произойдет инкремент этого семафора (как правило другим процессом). Операции над семафорами являются атомарными, т.е. во время операции над семафором ни один другой процесс не может получить доступ к этому семафору.

Монитор представляет собой конструкцию языка программирования, напоминяющую обьект в обьектно-ориентированных языках. Монитор содержит переменные и процедуры, причем доступ к процедурам может осуществляться только путем вызова соответствующих процедур. И в каждый момент времени выполнение процедуры доступно только одному процессу, т.е. если один процесс выполняет какую-либо процедуру монитора, то второй процесс будет заблокирован при попытке вызова процедуры монитора (той-же самой или другой) до тех пор, пока первый процесс не закончит выполнение процедуры. Реализация мониторов чаще всего строится на базе специальных семафоров, которые могут принимать значения 0 или 1. Такие семафоры носят название мьютекс (mutex, mutual exclusion) и с ними ассоциируются две операции - lock и unlock. Также мониторы применяются для организации такого примитива синхронизации как условные переменные - специальные переменные с двумя доступными операциями: wait (ждать события) и signal (породить событие).

Мультикомпьютерные операционные системы

Мультикомпьютерные операционные системы обладают гораздо более разнообразной структурой и значительно сложнее, чем мультипроцессорные. Единственно возможным видом связи между компонентами системы является передача сообщений (нет общей памяти). Типичная организация мультикомпьютерной операционной системы представлена на рисунке:

Рисунок 8

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

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

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

Системы с распределенной разделяемой памятью

Существует большое число разработок, направленных на решение вопроса эмуляции совместно используемой памяти на мультикомпьютерных системах. Один из распространненных подходов - задействовать виртуальную память каждого отдельного узла для поддержки общего виртуального адресного пространства - распределенная разделяемая память (Distributed Shared Memory, DSM) со страничной организацией.

В системе с DSM адресное пространство разделено на страницы (типичный размер - 4 Кб, 8Кб), распределеные по всем узлам системы. Когда процессор адресуется к памяти, которая не является локальной, происходит прерывание, операционная система перемещает страницу в локальную память и перезапускает выполнение инструкции, вызвавшей прерывание.

Рисунок 9

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

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

Также при построении DSM систем важно правильно выбрать размер страниц памяти, используемых системой. Затраты на передачу страницы по сети в первую очередь определяюся затратами на подготовку к передаче, а не размером страницы. Таким образом можно повысить производительность увеличив размер страницы. олднако при этом увеличивается вероятность того, что страница памяти будет содержать данные двух различных процессов, выпорлняющихся на разных узлах. В результате операционная система будет вынуждена постоянни пересылать эту страницу он узла к узлу:

Рисунок 10

Глава 3. Примеры распределительных систем и распределительные базы данных

3.1 Применение распределенных базы данных

Распределённые базы данных (РБД) — совокупность логически взаимосвязанных баз данных, распределённых в компьютерной сети.

РБД состоит из набора узлов, связанных коммуникационной сетью, в которой:

а) каждый узел — это полноценная СУБД сама по себе;

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

Каждый узел сам по себе является системой базы данных. Любой пользователь может выполнить операции над данными на своём локальном узле точно так же, как если бы этот узел вовсе не входил в распределённую систему. Распределённую систему баз данных можно рассматривать как партнёрство между отдельными локальными СУБД на отдельных локальных узлах.^[18]

Фундаментальный принцип создания распределённых баз данных («правило 0»): Для пользователя распределённая система должна выглядеть так же, как нераспределённая система.

Фундаментальный принцип имеет следствием определённые дополнительные правила или цели. Таких целей всего двенадцать:

1.Локальная независимость. Узлы в распределённой системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом.

2.Отсутствие опоры на центральный узел. Локальная независимость предполагает, что все узлы в распределённой системе должны рассматриваться как равные. Поэтому не должно быть никаких обращений к «центральному» или «главному» узлу с целью получения некоторого централизованного сервиса.

3.Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности.

4.Независимость от расположения. Пользователи не должны знать, где именно данные хранятся физически и должны поступать так, как если бы все данные хранились на их собственном локальном узле.

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

6.Независимость от репликации. Система поддерживает репликацию данных, если данная хранимая переменная-отношение — или в общем случае данный фрагмент данной хранимой переменной-отношения — может быть представлена несколькими отдельными копиями или репликами, которые хранятся на нескольких отдельных узлах.^[19]

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

8.Управление распределёнными транзакциями. Существует 2 главных аспекта управления транзакциями: управление восстановлением и управление параллельностью обработки. Что касается управления восстановлением, то чтобы обеспечить атомарность транзакции в распределённой среде, система должна гарантировать, что все множество относящихся к данной транзакции агентов (агент — процесс, который выполняется для данной транзакции на отдельном узле) или зафиксировало свои результаты, или выполнило откат. Что касается управления параллельностью, то оно в большинстве распределённых систем базируется на механизме блокирования, точно так, как и в нераспределённых системах.

9.Аппаратная независимость. Желательно иметь возможность запускать одну и ту же СУБД на различных аппаратных платформах и, более того, добиться, чтобы различные машины участвовали в работе распределённой системы как равноправные партнёры.

10.Независимость от операционной системы. Возможность функционирования СУБД под различными операционными системами.

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

12.Независимость от типа СУБД. Необходимо, чтобы экземпляры СУБД на различных узлах все вместе поддерживали один и тот же интерфейс, и совсем необязательно, чтобы это были копии одной и той же версии СУБД [6].

Основная задача систем управления распределенными базами данных состоит в обеспечении средства интеграции локальных баз данных, располагающихся в некоторых узлах вычислительной сети, с тем, чтобы пользователь, работающий в любом узле сети, имел доступ ко всем этим базам данных как к единой базе данных. ^[20]

Возможны однородные и неоднородные распределенные базы данных. В однородном случае каждая локальная база данных управляется одной и той же СУБД. В неоднородной системе локальные базы данных могут относиться даже к разным моделям данных.

Помимо вышеназванных типов распределенных баз данных можно выделить следующие:

1) Распределённые Базы Данных

2) Мультибазы данных с глобальной схемой. Система Мультибаз данных - это распределённая система, которая служит внешним интерфейсом для доступа ко множеству локальных СУБД или структурируется, как глобальный уровень над локальными СУБД.

3) Федеративные базы данных. В отличие от мультибаз не располагают глобальной схемой, к которой обращаются все приложения. Вместо этого поддерживается локальная схема импорта-экспорта данных. На каждом узле поддерживается частичная глобальная схема, описывающая информацию тех удалённых источников, данные с которых необходимы для функционирования.

4) Мультибазы с общим языком доступа - распределённые среды управления с технологией "клиент-сервер"

5) Интероперабельные системы - это системы, в которых сами приложения, выполняемые в среде той или иной СУБД, ответственны за интерфейсы между различными средами приложения, независимо от того, являются они однородными или неоднородными. Системы ориентированы главным образом на обмен данными. Дальнейшее развитие этих систем является объектно-ориентированные БД.