Файл: Учебнопрактическое пособие Владимир 2021.pdf

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

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

14 пределенной системы. Действительно, полностью скрыть распреде- ление процессов и ресурсов вряд ли удастся. Из-за ограничения в скорости передачи сигнала, задержка на обращение к ресурсам, тер- риториально удаленным от клиента, всегда будет больше, чем к ре- сурсам, расположенным поблизости. Поэтому не каждая система в состоянии или даже должна пытаться скрывать все свои особенности от пользователя. Обычно, это утверждение выражается в поиске компромисса между прозрачностью распределенной системы и ее производительностью.
Например, если для повышения отказоустойчивости в системе присутствуют географически распределенные копии ресурса, то под- держка их идентичного состояния для обеспечения прозрачности ре- пликации потребует гораздо большего времени выполнения каждой операции обновления. Другими словами, каждая операция обновле- ния должна будет распространиться на все реплики до того, как будет разрешена следующая операция с данным ресурсом. Или, например, многие приложения предпринимают несколько последовательных попыток связаться с сервером, пытаясь скрыть его временную недо- ступность, тем самым замедляя работу системы. Однако, в некоторых случаях, например, если на самом деле сервер вышел из строя, было бы разумнее сразу уведомить пользователя о недоступности ресурса.
Открытость
Согласно определению, принятому комитетом IEEE POSIX
1003.0, открытая система – это система, реализующая открытые спе- цификации (стандарты) на интерфейсы, службы и поддерживаемые форматы данных, достаточные для того, чтобы обеспечить:

Возможность переноса разработанного прикладного про- граммного обеспечения на широкий диапазон систем с минимальны- ми изменениями (мобильность приложений, переносимость);

совместную работу (взаимодействие) с другими приклад- ными приложениями на локальных и удаленных платформах (инте- роперабельность, способность к взаимодействию);

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

16 заций одной и той же службы, которые с точки зрения внешних про- цессов будут работать абсолютно одинаково. Как следствие, несколь- ко реализаций программных компонентов (возможно, от различных производителей) могут взаимодействовать и работать совместно, об- разуя единую распределенную систему. Таким образом, достигается свойство интероперабельности или, другими словами, способности к взаимодействию. Более того, в этом случае прикладное приложение, разработанное для распределенной системы A, может без изменений выполняться в распределенной системе B, реализующей те же интер- фейсы, что и А. То есть достигается свойство переносимости.
Еще одно важное преимущество заключается в том, что откры- тая распределенная система потенциально может быть образована из разнородного аппаратного и программного обеспечения (опять-таки, возможно, от разных производителей). При этом добавление новых компонентов или замена существующих может осуществляться отно- сительно легко, не затрагивая других компонентов. На аппаратном уровне это выражается в способности простого подключения к си- стеме дополнительных компьютеров или замены существующих на более мощные. На программном – в возможности простого внедре- ния новых служб или новых реализаций уже существующих. Други- ми словами, важным свойством открытой распределенной системы является расширяемость.
Масштабируемость
В общем случае масштабируемость определяют, как способ- ность вычислительной системы эффективно справляться с увеличе- нием числа пользователей или поддерживаемых ресурсов без потери производительности и без увеличения административной нагрузки на ее управление. При этом систему называют масштабируемой, если она способна увеличивать свою производительность при добавлении новых аппаратных средств. Другими словами, под масштабируемо- стью понимают способность системы расти вместе с ростом нагрузки на нее.

17
Масштабируемость является важным свойством вычислитель- ных систем, если им может потребоваться работать под большой нагрузкой, поскольку означает, что вам не придется начинать с нуля и создавать абсолютно новую информационную систему. Если у вас есть масштабируемая система, то, скорее всего, вам удастся сохра- нить то же самое программное обеспечение, попросту нарастив аппа- ратную часть.
Для распределенных систем обычно выделяют несколько пара- метров, характеризующих их масштаб: количество пользователей и количество компонентов, составляющих систему, степень территори- альной отдаленности сетевых компьютеров системы друг от друга и количество административных организаций, обслуживающих части распределенной системы. Поэтому масштабируемость распределен- ных систем также определяют по соответствующим направлениям:

Нагрузочная масштабируемость. Способность системы увеличивать свою производительность при увеличении нагрузки пу- тем замены существующих аппаратных компонентов на более мощ- ные или путем добавления новых аппаратных средств. При этом пер- вый случай увеличения производительности каждого компонента си- стемы с целью повышения общей производительности называют вер- тикальным масштабированием, а второй, выражающийся в увеличе- нии количества сетевых компьютеров (серверов) распределенной си- стемы – горизонтальным масштабированием.

Географическая масштабируемость. Способность системы сохранять свои основные характеристики, такие как производитель- ность, простота и удобство использования, при территориальном раз- несении ее компонентов от более локального взаимного расположе- ния до более распределенного.

Административная масштабируемость. Характеризует простоту управления системой при увеличении количества админи- стративно независимых организаций, обслуживающих части одной распределенной системы.
Построение масштабируемых систем подразумевает решение широкого круга задач и часто сталкивается с ограничениями реализо-

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

19 шей масштабируемости следует применять распределенные алгорит- мы, предусматривающие параллельное выполнение частей одного и того же алгоритма независимыми процессами.
В отличие от централизованных алгоритмов, распределенные алгоритмы обладают следующими свойствами, которые на самом де- ле значительно усложняют их проектирование и реализацию:

Отсутствие знания глобального состояния. Как уже было сказано, централизованные алгоритмы обладают полной информаци- ей о состоянии всей системы и определяют следующие действия, ис- ходя из ее текущего состояния. В свою очередь, каждый процесс, ре- ализующий часть распределенного алгоритма, имеет непосредствен- ный доступ только к своему состоянию, но не к глобальному состоя- нию всей системы. Соответственно, процессы принимают решения только на основе своей локальной информации. Следует отметить, что информацию о состоянии других процессов в распределенной си- стеме каждый процесс может получить только из пришедших сооб- щений, и эта информация может оказаться устаревшей на момент по- лучения. Аналогичная ситуация имеет место в астрономии: знания об изучаемом объекте (звезде / галактике) формируются на основании светового и прочего электромагнитного излучения, и это излучение дает представление о состоянии объекта в прошлом. Например, зна- ния об объекте, находящемся на расстоянии пяти тысяч световых лет, являются устаревшими на пять тысяч лет.

Отсутствие общего единого времени. События, составля- ющие ход выполнения централизованного алгоритма полностью упо- рядочены: для любой пары событий можно с уверенностью утвер- ждать, что одно из них произошло раньше другого. При выполнении распределенного алгоритма вследствие отсутствия единого для всех процессов времени, события нельзя считать полностью упорядочен- ными: для некоторых пар событий мы можем утверждать, какое из них произошло раньше другого, для других – нет.

Отсутствие детерминизма. Централизованный алгоритм чаще всего определяется как строго детерминированная последова- тельность действий, описывающая процесс преобразования объекта

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

21 двухточечным. В свою очередь, связь в локальных сетях является вы- соконадежной и подразумевает использование широковещательных сообщений, что значительно упрощает разработку распределенных приложений. Например, если процессу требуется обнаружить адрес другого процесса, предоставляющего определенную службу, в ло- кальных сетях ему достаточно разослать широковещательное сооб- щение с просьбой для искомого процесса откликнуться на него. Все процессы получают и обрабатывают это сообщение. Но только про- цесс, предоставляющий требуемую службу, отвечает на полученную просьбу, указывая свой адрес в ответном сообщении. Очевидно, по- добное взаимодействие перегружает сеть, и использовать его в гло- бальных сетях нереально.
Технологии масштабирования.
В большинстве случаев сложности масштабирования проявля- ются в проблемах с эффективностью функционирования распреде- ленных систем, вызванных ограниченной производительностью ее отдельных компонентов: серверов и сетевых соединений. Существу- ют несколько основных технологий, позволяющих уменьшить нагрузку на каждый компонент распределенной системы. К таким технологиям обычно относят распространение, репликацию и кэши- рование.
Распространение предполагает разбиение множества поддержи- ваемых ресурсов на части с последующим разнесением этих частей по компонентам системы. Простым примером распространения мо- жет служить распределенная файловая система при условии, что каж- дый файловый сервер обслуживает свой набор файлов из общего ад- ресного пространства. Другим примером может являться уже упоми- навшаяся служба доменных имен DNS, в которой все пространство
DNS-имен разбивается на зоны, и имена каждой зоны обслуживаются отдельным DNS-сервером.
Важную роль для обеспечения масштабируемости играют ре- пликация и кэширование. Репликация не только повышает доступ-