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

6. Прозрачность транзакций (transactiontransparency) даёт возможность позволить системе добиваться непротиворечивости, при этом легко скрывая выполнение согласования в группе ресурсов. В последующем, транзакции включа­ют запросы к службам (к примеру, доступ к файлам и вызов функций), по­зволяющие изменять имеющееся состояние системы. Следовательно, можно сделать вывод, что транзакции часто требуют создания контрольных точек, либо выполнения репликации в це­лях обеспечения реализации иных задач в распределённых системах. Прозрачность транзакций весьма удачно позволяет скрывать от пользователя детальные моментыэксплуатации этих служб;

1. Прозрачность миграции (migrationtransparency);
2. Прозрачность изме­нения местоположения (relocationtranspa-rency).

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

Концепция прозрачности, как видно из табл. 1., применима к различным показательным аспектам распределённых систем.

Таблица 1.

Различные формы прозрачности в распределённых системах

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

Основываясь на данном примере, это же происходит и в глобальной распределённой системе, которая соединяет процесс в Сан-Франциско с процессомк примеру в Амстердаме, будьте уверены, вам не удастся скрыть тот факт, что мать-природа супротив иной логике не позволяет пересылать сообщения от одного процесса к другому быстрее чем за 35 мс. Руководствуясь практикой,данные показывают, что при использовании компьютерных сетей на это реально требуется несколько сотен миллисекунд. А сама скорость передачи сигнала ограничивается не столько скоростью света, сколько скоростью самой работы промежуточных переключателей.

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

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

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

2.2. Открытость

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

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

Будучи правильно обозначенным, определение интерфейса допускает возможность совместной работы произвольного процесса, нуждающегося в таком интерфейсе, с другим произвольным процессом, предоставляющим этот интерфейс. Определение интерфейса также позволяет двум независимым группам создать абсолютно разные реализации этого интерфейса для двух различных распределённых систем, которые будут работать абсолютно идентично. Правильное определение самодостаточно и нейтрально. «Самодостаточно» означает то, что в нём имеется всё необходимое для реализации интерфейса. Однако, многие определения интерфейсов сделаны самодостаточными не до конца, поскольку разработчикам необходимо включать в них специфические детали реализации. Важно отметить, что спецификация не определяет внешний вид реализации, она должна быть нейтральной. Самодостаточность и нейтральность являются особой необходимостью для обеспечения переносимости и способности к взаимодействию. Способность к взаимодействию (interoperability)характеризует, насколько две реализации систем или компонентов от разных производителей в состоянии совместно работать, полагаясь только на то, что службы каждой из них, соответствуют общему стандарту. Переносимость (portability)характеризует то, насколько приложение, разработанное для распределённой системы 1, может без изменений выполняться в распределённой системе 2, реализуя по возможности те же, что и в 1 интерфейсы.

2.3. Гибкость

Следующая важная характеристика открытых распределённых систем — это гибкость.

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

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

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

Необходимость изменений в распределённых системах часто связана с тем, что компонент не оптимальным образом соответствует нуждам конкретного пользователя или приложения. На данном примере, рассмотрим кэширование в WorldWideWeb. Браузеры обычно позволяют пользователям адаптировать правила кэширования под их нужды путем определения размера кэша, а также того, должен ли кэшируемый документ проверяться на соответствие постоянно или только один раз за сеанс. Однако пользователь лишён возможности воздействовать на другие параметры кэширования, такие как длительность сохранения документа в кэше или очередность удаления документов из кэша при его переполнении данных. Также невозможно создавать правила кэширования на основе содержимогодокумента. Приведём имеющийся пример: пользователь может пожелать кэшировать железнодорожные расписания, которые редко изменяются, но никогда — информациюпоступившую о пробках на улицах города.

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

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

Масштабируемость - это одна из наиболее значимых задач при проектировании распределённых систем.

Масштабируемость,оно жерасширяемость (scalability), указывает на способность распределённой сис­темы увеличиваться в масштабах (данная возможность подключения к системе дополни­тельных компонентов) без возможности влиять на саму работу уже существующих ныне приложений и пользователей.Масштабируемость функционально рассматривается по отношению к размеру (подключение возможных дополнительных пользователей и иных ресурсов), по отношению к географическому положению (пространственное расположение пользователей и ресурсов), а так же к административному устройству (управление в административно независимых организациях). Возникающие проблемы масштабируемости обычно связаны с «узкими» местами по обслуживанию (иными словами это один сервер для множества клиентов), далее по данным (один файл с общей информацией), и по алгоритмам (централизованный алгоритм и перегрузка в коммуникационной сети).

Применение в работе децентрализованных алгоритмов придаёт распределённой системе следующие характерные черты:

- никто не обладает полной информацией о системе;

- решения принимаются на основе локальной информации;

- сбой в одном месте не вызывает нарушения работы алгоритма;

- существования единого времени в использовании системы не требуется.

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

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

Таблица 2.

Примеры ограничений масштабируемости