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

Узлом называется любое аппаратное устройство в распределенной системе.

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

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

Сервис – это сетевая сущность, предоставляющая определенные функциональные возможности [5, стр. 10,11].

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

1.4 Классификация распределенных систем

Классифицировать распределенные системы можно по различным признакам. По количеству элементов в системе различают распределенные системы:

-Кластеры -   несколько вычислительных узлов (не превышает несколько десятков), объединенных с помощью быстрой технологии передачи данных и с установленным специальным программным обеспечением. Компьютерные кластеры в настоящее время получили большое распространение. Видимо, это связано, в первую очередь с тем, что из-за постоянного снижения цен на оборудование и появление в последнее время соответствующего системного программного обеспечения технология создания кластеров стала общедоступной. [9, стр. 6]

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

- Глобальные распределенные системы – с количеством элементов более тысячи. В ней участвуют несколько отдельных организаций, географически удаленных друг от друга, которые предоставляют друг другу свои ресурсы по определенным правилам и с определенными протоколами взаимодействия[6, стр.32]. 

В своем труде Таненбаум проведем также разделение распределенных компьютерных систем на гомогенные (homogeneous) и гетерогенные (heterogeneous). Это разделение приме­няется исключительно к мультикомпьютерным системам.

Для гомогенных мультикомпьютерных систем характерна одна соединяющая компьютеры сеть, ис­пользующая единую технологию. В этих системах, известных под названием системиых сетей {System Area Networks, SAN), узлы монтируются в большой стойке и соединяются единой, обычно высо­коскоростной сетью.

Гомоген­ные мультикомпьютерные системы нередко используются в качестве параллельных (работающих с одной задачей), в точности как мультипроцессорные. Наибольшее число существующих в настоящее время распределенных систем по­строено по схеме гетерогенных мультикомпьютерных. Это означает, что компью­теры, являющиеся частями этой системы, могут быть крайне разнообразны, например, по типу процессора, размеру памяти и производительности каналов ввода-вывода [1, стр. 39-44].

По типу предоставляемых ресурсов различают:

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

- Распределенные информационные системы, которые предназначены для обработки больших объемов информации, но не требуют больших вычислительных ресурсов [6, стр. 32].

- Семантический Грид, производящая централизованное удаленное предоставление ресурсов (как вычислительных мощностей, так и информационных систем), необходимых для решения различного рода вычислительных задач [5, стр. 131].

1.5 Механизм реализации распределенной обработки данных

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

Существует несколько распространенных моделей взаимодействия в распределенных системах. Первой моделью является удаленный вызов процедур (Remote Procedure Call, RPC). Этот механизм нацелен на сокрытие большей части проблем передачи сообщений и идеален для приложений архитектуры клиент- сервер [1, стр. 81].

Суть этого метода заключается в том, чтобы сделать вызов удаленной процедуры по возможности выглядящим так же, как и вызов локальной процедуры. При запуске процесса вызывающий процесс приостанавливается, а на другом компьютере происходит выполнение вызванной процедуры. Информация от вызывающего процесса передается через параметры и возвращается к нему в виде результата выполнения процедуры. Пользователь не заметит, что вызываемая процедура находилась на другой машине. Таким образом, с помощью удаленного вызова процедур получается добиться прозрачности [1, стр. 93,94].

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

На машине сервера запускается процесс выполнения вызванной процедуры,

поступающая информация помещаются принимающей аппаратурой либо во встроенный буфер, либо в оперативную память. Когда удаленный сервер получает сообщение, он видит его как прямое обращение к локальной процедуре, выполняет вызов и предает его серверной заглушке. Она в свою очередь компонует результаты в сообщение для клиента и вызывает операционную систему сервера. После выполнения процедуры сервер передает результаты операционной системе клиента. Операционная система клиента принимает сообщение и передает его клиентскому стабу, который выводится из ожидания, извлекает результаты из сообщения и передает их клиенту [5, стр.52-54].

Достоинство этого метода заключается в том, что и клиент, и сервер не знают об удаленности вызова и промежуточных действиях [3, стр.26].

Удаленные вызовы процедур стали фактическим стандартом для связи в распре­ деленных системах. Популярность этой модели объясняется ее несомненной простотой [1, стр.103].

Более усовершенствованным вариантом модели удаленного вызова процедур является вид удаленного обращения к методам (Remote Method Invocation, RMI), которое основано на представлении распределенных объектов [1, стр.81].

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

Основное различие между RMI и RPC состоит в том, что RMI поддерживает внутрисистемные ссылки на объекты. Кроме того, отпадает необходимость в клиентских и серверных заглушках общего назначения. Вместо них мы можем использовать значительно более удобные в ра­боте и специфические для объектов посредники (англ. proxy), или реализацию интерфейса удаленного объекта [5, стр. 55].

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

После образования посредника (proxy), объекты находятся на сервере и предоставляют необходимые интерфейсы. Вызывающий процесс на обращение к методу попадает в серверный каркас, или скелетон (skeleton), который по своим функциям напоминает серверную заглушку в RPC. Каркас связывается с экземпляром удаленного объекта. Если объект физически распределен по нескольким вычислительным машинам, то это скрывается от клиентов за интерфейсами объектов [5, стр.55,56].

Механизм удаленного обращения к методам имеет ряд достоинств. На основе RMI было создано множество реализаций, значительно облегчивших создание объектно-ориентированных распределенных приложений [3, стр.40].

Еще одной моделью взаимодействия является ориентированный на сообщения промежуточный уровень (Message-Oriented Middleware, MOM) или системы очередей сообщений [1, стр. 81].

Потребность в этой модели возникает, когда нет уверенности в том, что принимающая сторона во время выполнения запроса работает. Клиенты взаимодействуют, обмениваясь структурированными наборами данных - сообщениями. Такие системы предоставляют возможность промежуточного хранения сообщений, не требуя активности во время передачи, но от отправителя, ни от получателя [3, стр. 44,45].

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

Однако существуют формы взаимодействия, в которых временные характе­ристики имеют решающее значение, например мультимедийных системах, когда недостает поддержки передачи непрерывных потоков, таких как аудио или видео. Для обмена критичной ко времени передачи информацией распределенные сис­темы обычно предоставляют поддержку потоков данных (data streams, или про­ сто streams) [1, стр.149].

Выводы по 1 главе:

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

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

Существует несколько механизмов взаимодействия между процессами в распределенной системе. Из них наиболее широко известны такие модели, как удален­ный вызов процедур (RPC), удаленное обращение к ме­тодам (RMI), ориентированный на сообщения про­межуточный уровень (MOM) и потоки данных (streams). Каждая из моделей имеет свои достоинства и ориентирована на разный способ доступа к данным и характеристику передаваемых данных.

Глава 2. Основные задачи распределенной системы

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

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

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

Еще одной важной задачей является обеспечение открытости системы, то есть обеспечение слаженной работы произвольных процессов, а также обеспечение гибкости, то есть легкость конфигурирования системы, состоящей из различных компонентов, возможно от разных производителей [1, стр.30] . Открытость гарантирует расширяемость системы и возможность повторного использования.

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

Также распределенная система должна выполнять задачу отказоустойчивости, когда система продолжает функционировать после выхода из строя одного из ее компонентов [2, стр.13].