Э. Таненбаум, М. ван Стеен - Распределённые системы (принципы и парадигмы), страница 6

Эти правила формализо­ваны в протоколах. В распределенных системах службы обычно определяютсячерез интерфейсы {interfaces), которые часто описываются при помощи языкаопределения интерфейсов {Interface Definition Language, IDL), Описание интер­фейса на IDL почти исключительно касается српгтаксиса служб. Другими слова­ми, оно точно отражает имена доступных функций, типы параметров, возвращае­мых значений, исключительные ситуации, которые могут быть возбужденыслужбой и т.

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

«Самодостаточно» означает, что в нем име­ется все необходимое для реализации интерфейса. Однако многие определенияинтерфейсов сделаны самодостаточными не до конца, поскольку разработчикамнеобходимо включать в них специфические детали реализации. Важно отметить,что спецификация не определяет внешний вид реализации, она должна бытьнейтральной. Самодостаточность и нейтральность необходимы для обеспеченияпереносимости и способности к взаимодействию [65]. Способность к взаимодей­ствию {interoperability) характеризует, насколько две реализации систем иликомпонентов от разных производителей в состоянии совместно работать, полага­ясь только на то, что службы каждой из них соответствуют общему стандарту.Переносимость {poitability) характеризует то, насколько приложение, разрабо­танное для распределенной системы Л, может без изменений выполняться в рас­пределенной системе В, реализуя те же, что и в Л интерфейсы.Следующая важная характеристика открытых распределенных систем — этогибкость.

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

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

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

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

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

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

Помня это, мы гово-32Глава 1. Введениерим, что масштабируемость — это одна из наиболее важных задач при проектиро­вании распределенных систем.Масштабируемость системы может измеряться по трем различным показате­лям [314]. Во-первых, система может быть масштабируемой по отношению к ееразмеру, что означает легкость подключения к ней дополнительных пользовате­лей и ресурсов. Во-вторых, система может масштабироваться географически, тоесть пользователи и ресурсы могут быть разнесены в пространстве.

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

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

Даже если мы обладаем фактически неограниченным за­пасом по мощности обработки и хранения данных, ресурсы связи с этим серве­ром в конце концов будут исчерпаны и не позволят нам расти дальше.Т а б л и ц а 1 . 2 . Примеры ограничений масштабируемостиКонцепцияПримерЦентрализованные службыОдин сервер на всех пользователейЦентрализованные данныеЕдиный телефонный справочник, доступныйв режиме подключенияЦентрализованные алгоритмыОрганизация маршрутизации на основе полнойинформацииК сожалению, Р1Спользование единственного сервера время от времени неиз­бежно.

Представьте себе службу управления особо конфиденциальной информа­цией, такой как истории болезни, банковские счета, кредиты и т. п. В подобныхслучаях необходимо реализовывать службы на одном сервере в отдельной хоро­шо заш;ищенной комнате и отделять их от других частей распределенной систе­мы посредством специальных сетевых устройств. Копирование информации, со­держащейся на сервере, в другие места для повышения производительностидаже не обсуждается, поскольку это сделает службу менее стойкой к атакам зло­умышленников.Централизация данных так же вредна, как и централизация служб. Как выбудете отслеживать телефонные номера и адреса 50 миллионов человек? Пред-1.2. Задачи33положим, что каждая запись укладывается в 50 символов.

Необходимой емко­стью обладает один 2,5-гигабайтный диск. Но и в этом случае наличие единойбазы данных несомненно вызовет перегрузку входящих и исходящих линий свя­зи. Так, представим себе, как работал бы Интернет, если бы служба доменныхимен (DNS) была бы реализована в виде одной таблицы. DNS обрабатывает ин­формацию с миллионов компьютеров во всем мире и предоставляет службу, не­обходимую для определения местоположения web-серверов. Если бы каждый за­прос на интерпретацию URL передавался бы на этот единственный DNS-сервер,воспользоваться Web не смог бы никто (кстати, предполагается, что эти пробле­мы придется решать снова).И наконец, централизация алгоритмов — это тоже плохо.

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