Введение

Примеры распределенных систем

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

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

С одной стороны, Интернет является ярким примером системы, построенной по архитектуре P2P (о ней речь пойдет ниже), - все узлы в нем независимы. С другой стороны, если мы поднимемся на уровень сервисов, то увидим примеры практически всех известных архитектур.

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

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

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

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

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

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

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

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

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

Предъявляемые требования

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

Открытость

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

Безопасность

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

• конфиденциальность (обеспечение защиты от несанкционированного доступа в систему);
• целостность (обеспечение целостности и сохранности данных);
• доступность (обеспечение защиты при параллельном доступе к ресурсам).

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

Важной проблемой при проектировании распределенного приложения является задача обеспечения качества обслуживания ( Quality of Service ). Под качеством обслуживания обычно понимают некие соглашения по выполнению запросов клиента (например, запрос должен обрабатываться не позднее, чем через 2 секунды после получения и т.д.). Жестким нарушением качества обслуживания является ситуация отказа в обслуживании ( Denial of Service ) - она может возникнуть, если злоумышленник бомбардирует сервер запросами, которые тот не успевает обрабатывать. Решение этой проблемы в общем виде может быть очень сложным, однако существуют рекомендации, позволяющие обходить ее в большинстве случаев. Другой важной проблемой безопасности является использование мобильного кода (кода, пришедшего по сети и исполняемого локально). Здесь решение состоит в применении интерпретируемого кода и виртуальных машин.

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

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

• использование ресурсов не должно расти быстрее, чем О(n), где n - количество пользователей;
• время поиска по структурам данных не должно расти быстрее, чем O(log(d)), где d - количество данных.

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

Обработка ошибок

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

Параллельность

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

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

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

Прозрачность

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

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

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

Управляемость

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