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

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

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

Основная задача распределенной системы – предоставление пользователям ресурсов. Причин для такого разделения ресурсов множество, но назовем главные:

· экономичность (дешевле разрешить доступ нескольких пользователей к одному принтеру, чем покупать несколько принтеров);

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

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

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

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

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

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

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

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

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

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

Открытость.

Еще одна важная характеристика распределенных систем - открытость. Открытая система - это система, предлагающая набор служб и функций, каждая из которых определяется набором интерфейсов. Интерфейс содержит описание форматов входных данных и получаемых результатов. Например, интерфейс некоторого класса – это описание имен и типов свойств, область допустимых значений. А также описание имен и типов возвращаемых результатов для всех методов. Причем для каждого метода должны быть описаны все параметры: имя, способ передачи, тип, область допустимых значений.

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

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

Еще одна мысль в связи с открытостью. Открытость интересна не только с точки зрения интегрируемости с другими приложениями, но и с точки зрения развития, настраивания и т.п. Рассмотрим пример. Браузеры обычно имеют возможность кэшировать полученную из Интернет информацию. Пользователь может задать размер кэш, время хранения данных в кэш. Но, к сожалению, во всех известных браузерах эти характеристики никак не связаны с характером данных. А ведь одна информация (например, котировка акций) изменяется очень часто, и ее нельзя долго сохранять в кэш. А другая (например, железнодорожное расписание) изменяется редко. То есть требуется расширить возможности браузера. Если браузер реализован как открытая система, то можно его дополнить некоторым модулем, изменяющим ранее заведенный порядок. Если же - нет, то ничего не получится. Иногда такую особенность открытых систем называют: «отделение правила от механизма».

Масштабируемость.

К долгоживущей информационной системе обязательно предъявляется требование масштабируемости (~ изменение размеров), то есть некоторого роста без переписывания всего программного кода и замены всего оборудования.

Система может масштабироваться по трем направлениям: 1) размер (дополнительные пользователи, ресурсы), 2) протяженность в географическом смысле, 3) администрирование (во множестве административно независимых организациях).

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

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

Размер базы данных. С увеличением БД до десятков и сотен гигабайт операции резервирования, восстановления и загрузки станут узким местом.

Сложность транзакций. Разработчики приложений делают их все более «умными», облегчая пользователям работу, давая возможность анализировать данные. Но при этом экспоненциально растет число взаимосвязей данных, вследствие чего, во-первых, растет сложность написания, а потому повышается вероятность ошибок. А, во-вторых, при выполнении такой транзакции системе необходимо переработать большое количество данных, что практически может оказаться невозможным для данной мощности процессора, объема оперативной памяти и т.п. Что в свою очередь требует написания каких-то особых алгоритмов выгрузки данных, кэширования и т.п.

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

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

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

На пути масштабируемости стоят

- централизованные службы,

- централизованные данные,

- централизованные алгоритмы.

Централизованная служба предполагает, что некоторая служба (программа) находится только на одном компьютере. В случае если обращения к этой службе от разных клиентов происходят не часто и не одновременно, то это – вполне приемлемое решение. В противном случае такая служба будет узким местом системы. Для того чтобы централизованная служба вызывала меньше проблем, требуется использовать скоростные линии связи, а компьютер, на котором расположена эта служба, должен быть достаточно быстрым, иметь оперативную память и буферы достаточного объема. Несомненное преимущество такой службы состоит в том, что ее легче обновлять. Если служба представляет собой процесс, требующий для своей работы больших вычислительных ресурсов, то может оказаться гораздо выгоднее обеспечить наличие этих ресурсов только на одном компьютере, а не на множестве клиентов. Но, с другой стороны, часто при крахе централизованной службы система в целом теряет работоспособность.

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

В масштабируемой системе предлагается применять децентрализованные службы. Этого можно достичь двумя путями: либо реплицировав (скопировав) службу на несколько компьютеров, либо (если это возможно) разбив службу на отдельные задачи, разнести соответствующие фрагменты по разным компьютерам. Пример: в достаточно большой локальной сети рекомендуется DHCP сервер (занимающийся выдачей в аренду IP-адресов), хранилище перемещаемых профилей располагать не на контроллере домена, а на отдельном компьютере (конечно же, включенном в нужное время).

Часто централизованная служба связана с централизованными данными. Централизованные данные часто легче защищать (проще устраивать резервное копирование). Но объем таких данных может оказаться настолько большим, что не хватит никаких разумных вычислительных мощностей. В централизованных хранилищах нередко усложняется поиск нужных данных. С одной стороны, время поиска растет при росте хранилища. С другой, в случае централизованного хранилища растет набор признаков – параметров поиска, так как с данными работает большое количество разных задач. Для централизованных данных очень важно делать архивные копии, чтобы снизить возможные потери при поломке централизованного хранилища. Пример централизованных данных – сервер базы данных (MY SQL, MS SQL и т.п.).

Масштабируемая система должна работать с децентрализованными данными. Хороший пример – служба DNS, сопоставляющая символьному имени сетевого ресурса его IP адрес. Архитектура дерева серверов DNS позволяет разделить информацию на фрагменты, каждый из которых поддерживается одним сервером. Между серверами установлена связь и определен протокол их взаимодействия. Обеспечение этой связи – цена применения децентрализованного хранилища. Децентрализованное хранилище обладает некоторым интересным свойством: неодинаковым временем доступа к информации. Для того чтобы сгладить эти различия, то есть с целью ускорения, по крайней мере, повторного доступа к удаленным данным DNS сервера применяют кэширование информации. Но, вы помните, что кэширование приводит к проблеме противоречивости данных. Проблемы, возникающие при децентрализации данных, основная из которых – противоречивость данных на разных компьютерах, рассмотрим чуть позже. Разберем 13 моделей непротиворечивости.

Централизованный алгоритм – тоже плохо для распределенной системы. Алгоритм можно считать централизованным, если для его окончания, то есть для принятия решения, ему требуется полная информация, полученная от непосредственных источников. Вспомним алгоритмы маршрутизации, изученные в курсе «Информационные сети». Рассмотрим в качестве примера централизованного алгоритма «протокол состояния каналов». В этом алгоритме предполагается, что составляющий таблицу маршрутизатор связывается с каждым маршрутизатором. Это приводит к огромному количеству передаваемых служебных пакетов. Этот алгоритм требователен к ресурсам маршрутизатора и к сети, хотя он оказывается слабо чувствителен к исчезновению маршрутизатора. Алгоритм «протокол вектора расстояний» не относится к централизованным алгоритмам, т.к. для принятия решения (построения своей таблицы маршрутизации) маршрутизатору требуется связаться только с соседями. Этот алгоритм гораздо меньше занимает сеть, но может принять неверное решение при исчезновении маршрутизатора (проблема роста расстояния до бесконечности)

Технологии, применяемые при создании масштабируемых систем: скрытие времени ожидания связи, распределение, репликация.

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

Вторая важная технология масштабирования – распределение. Мы уже вспоминали распределенную службу DNS. Важный аспект реализации распределения данных – именование. Проблема состоит в том, что имена должны быть уникальны, то есть требуется тем или иным способом организовать пространства имен. Так же, как и для файлов, у каждого интернет-объекта должно быть уникальное полное имя, включающее имена DNS серверов от объекта до корня DSN.

И, наконец, третья технология – репликация. При репликации все совместно используемые данные или некоторые их части копируются на несколько компьютеров. В результате этого данные можно приблизить к пользователю, уменьшив тем самым время доступа, снизив нагрузку на компьютеры, поддерживающие хранилище. Цена такого решения – необходимость обеспечения непротиворечивости данных. Следует различать репликацию и кэширование. Репликация происходит по инициативе сервера данных (владельца), а кэширование – по инициативе клиента (пользователя).

Если мы имеем дело с кэшированием, то клиент (например, Internet Explorer) должен самостоятельно следить за актуальностью данных. Механизмы, применяемые для этого: а)запросы на обновление данных через определенное время, б) запросы об актуальности (неизменности на сервере). В первом случае может передаваться неизмененное данное, что излишне загружает сеть. А во втором сначала клиент выясняет, изменились ли данные, и только в случае их изменения отправляет запрос на пересылку данных. Очевидно, что если данные изменяются редко, то предпочтительнее использовать второй метод, в противном случае – первый. Теперь – несколько слов о непротиворечивости. В связи с тем, что в распределенной системе могут быть разные клиенты, которым требуется разная степень «свежести» для разных данных, разные данные обладают разным временем обновления и другими характеристиками, а передача данных это – дорогое удовольствие, то в разных случаях потребуются разные методы обеспечения непротиворечивости.

Параллелизм.

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

Существует два общих параллелизма:

При использовании поточного параллелизма (pipeline parallelism) задача разбивается на последовательность шагов. Параллелизм проявляется в одновременном выполнении разных шагов разных задач. Для одной же задачи шаги выполняются последовательно. Результат одного шага посылается на следующий. Пример – промышленные линии сборки. Задача – сборка автомобиля. Подзадачи – прикручивание колес, установка сидений, двигателя и т.п. Если шаг 2 не готов принять результаты шага 1, то полуфабрикаты накапливаются и используются позже. Но вследствие поточного параллелизма по конвейерной линии могут идти несколько машин одновременно.

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

В хороших системах должны работать оба типа параллелизма. Пример – MS SQL Server, в котором распределение данных по дискам приводит к тому, что могут одновременно считываться с дисков части информации – раздельный параллелизм. Кроме того, MS SQL Server использует поточный параллелизм, формируя выборку с упреждением чтения с диска (в этом состоянии может находиться одна задача), обрабатывая данные (в этом состоянии находится вторая задача) и посылая результат приложению (это – состояние третьей задачи).

Microsoft Windows Server является полностью поточной операционной системой. Также она имеет встроенное разделение дисков. Это позволяет распределить логические тома между несколькими физическими. Каждый логический том может быть RAID (избыточный распределенный дисковый массив) или обычным диском. Windows 2000 Server поддерживает физическую и программную реализацию RAID-массивов.

RAID-технологии.

Цель программной или аппаратной реализации RAID массивов – достижение более высокой скорости работы с дисками и/или достижение более высокой надежности работы дисков. Когда имеют дело с физически организованным RAID-массивом, обычно говорят о RAID-контроллере. Такие массивы часто используются на серверных станциях. Начиная с Windows-2000 Microsoft предлагает программную реализацию RAID-массива. Основные принципы программной реализации не отличаются от аппаратной за исключением того, что всюду в качестве носителя может быть использован раздел диска, а не весь физический диск, как это делается в случае аппаратной реализации. Ниже мы не будем делать упор на различия, а разберем сами принципы.

Существует несколько видов RAID.

Самый первый появившийся вид состоит в том, чтобы дать возможность пользователю видеть несколько физических разделов одного или нескольких диска в виде одного логического диска. Такой вид организует достаточно большое адресное пространство, он не предоставляет повышенной надежности и, вообще говоря, скорости. Хотя скорость обращения возрастает в случае одновременного обращения к разным дискам. На физически организованных массивах такого вида может объединяться до 128 дисков.

На следующей схеме изображены три диска, каждый из которых разделен на некоторое количество разделов. Зеленым отмечены фрагменты одного логического диска.

Диск 1

Диск 2

Диск 3

Рисунок 1 – Разделы, объединенные в 1 логический том

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

Диск 1

	Мама раму.
Исходный файл: Мама мыла раму.	Диск 2
	мыла

Рисунок 2 – Запись на RAID-том с чередованием

Следующий вид RAID – зеркальный или теневой том. Здесь также два физических диска объявляются одним логическим. Но основная цель данного вида – повышение надежности. Поэтому запись всего файла идет одновременно на оба носителя. При поломке одного носителя, информация может быть прочитана со второго. Цена надежности – фактически потерянное пространство второго диска.

Диск 1

	Мама мыла раму.
Исходный файл: Мама мыла раму.	Диск 2
	Мама мыла раму.

Рисунок 3 – Запись на RAID-том с зеркалированием

RAID 5 – отказоустойчивая технология хранения, предоставляющая повышенную скорость работы. Здесь диски организованы таким образом, что одновременно идет запись одного фрагмента данных на один носитель, второго – на второй, а на третий носитель записывается их логическая сумма. По используемому пространству RAID 5 эффективнее зеркалирования, а предоставляемое повышение скорости работы делает этот вид наиболее приемлемым.

Поясним работу RAID-5. В этой технологии для хранения данных используются сразу три диска. На первом храним первую половину данных, на втором – вторую, на третьем – результат операции "исключающее ИЛИ" (XOR), примененной к этим двум половинам. В этом случае утеря любой части не критична, т.к. она восстанавливается по двум оставшимся. Деление на части может происходить по-разному. Например, по битам, по блокам. Приведем пример побитного деления. Пусть исходное данное "100111". Серым цветом выделены биты с нечетными номерами. Тогда на первый диск запишется каждый нечетный бит "101", на второй диск запишется каждый четный бит "011", на третий диск – "110". Очевидно, что при утере информации на диске 3, она заново просчитывается по исходным данным, а при утере информации на диске 1 (аналогично на 2) она вычисляется как результат операции: диск 2 XOR диск 3.

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