20426

Определение распределенной системы

Доклад

Информатика, кибернетика и программирование

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

Русский

2013-07-25

210 KB

0 чел.

1.1. Определение распределенной системы

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

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

Скорость роста, наблюдавшаяся в компьютерных технологиях в последние полвека, действительно потрясает. Ей нет прецедентов в других отраслях. От машин, стоивших 100 миллионов долларов и выполнявших одну команду в секунду, мы пришли к машинам, стоящим 1000 долларов и выполняющим 10 миллионов команд в секунду. Разница в соотношении цена/производительность достигла порядка 1012. Если бы автомобили за этот период совершенствовались такими же темпами, «роллс-ройс» сейчас стоил бы один доллар и проходил миллиард миль на одном галлоне бензина (к сожалению, к нему потребовалось бы 200-страничноеруководство по открыванию дверей).

Второй из новинок было изобретение высокоскоростных компьютерных сетей. Локальные сети (Local - Area Networks, LAN) соединяют сотни компьютеров, находящихся в здании, таким образом, что машины в состоянии обмениваться небольшими порциями информации за несколько микросекунд. Большие массивы данных передаются с машины на машину со скоростью от 10 до 1000 Мбит/с. Глобальные сети (Wide - Area Networks , WAN) позволяют миллионам машин во всем мире обмениваться информацией со скоростями, варьирующимися от 64 кбит/с (килобит в секунду) до гигабит в секунду.

В результате развития этих технологий сегодня не просто возможно, но и дос таточно легко можно собрать компьютерную систему, состоящую из множества компьютеров, соединенных высокоскоростной сетью. Она обычно называется компьютерной сетью, или распределенной системой (distributed system), в отличие от предшествовавших ей централизованных (centralized systems), или одно процессорных (single - processor systems), систем, состоявших из одного компьютера, его периферии и, возможно, нескольких удаленных терминалов.

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

Распределенная система — это набор независимых компьютеров, представляющийся их пользователям единой объединенной системой.

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

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

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

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

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

В качестве последнего примера рассмотрим World Wide Web. Web предоставляет простую, целостную и единообразную модель распределенных документов. Чтобы увидеть документ, пользователю достаточно активизировать ссылку. После этого документ появляется на экране. В теории (но определенно не в текущей практике) нет необходимости знать, с какого сервера доставляется документ, достаточно лишь информации о том, где он расположен. Публикация документа очень проста: вы должны только задать ему уникальное имя в форме унифицированного указателя ресурса (Uniform Resource Locator, URL), которое ссылается на локальный файл с содержимым документа. Если бы Всемирная паутина представлялась своим пользователям гигантской централизованной системой документооборота, она также могла бы считаться распределенной системой. К сожалению, этот момент еще не наступил. Так, пользователи сознают, что документы находятся в различных местах и распределены по различным серверам.

1.2. Задачи распределенных систем

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

1.2.1. Соединение пользователей с ресурсами

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

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

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

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

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

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

Прозрачность в распределенных системах

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

Таблица 1.1. Различные формы прозрачности в распределенных системах

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

Описание

Доступ

Скрывается разница в представлении данных и доступе к ресурсам

Местоположение

Скрывается местоположение ресурса

Перенос

Скрывается факт перемещения ресурса в другое место

Смена местоположения

Скрывается факт перемещения ресурса в процессе обработки в другое место

Репликация

Скрывается факт репликации ресурса

Параллельный доступ

Скрывается факт возможного совместного использования ресурса несколькими конкурирующими пользователями

Отказ

Скрывается отказ и восстановление ресурса

Сохранность

Скрывается, хранится ресурс (программный) на диске или находится в оперативной памяти

Прозрачность доступа (access transparency) призвана скрыть разницу в представлении данных и в способах доступа пользователя к ресурсам. Так, при пересылке целого числа с рабочей станции на базе процессора Intel на Sun SPARC необходимо принять во внимание, что процессоры Intel оперируют с числами формата «младший — последним» (то есть первым передается старший байт), а процессор SPARC использует формат «старший — последним» (то есть первым передается младший байт). Также в данных могут присутствовать и другие несоответствия. Например, распределенная система может содержать компьютеры с различными операционными системами, каждая из которых имеет собственные ограничения на способ представления имен файлов. Разница в ограничениях на способ представления имен файлов, так же как и собственно работа с ними, должны быть скрыты от пользователей и приложений.

Важная группа типов прозрачности связана с местоположением ресурсов. Прозрачность местоположения (location transparency) призвана скрыть от пользователя, где именно физически расположен в системе нужный ему ресурс. Важную роль в реализации прозрачности местоположения играет именование. Так, прозрачность местоположения может быть достигнута путем присвоения ресурсам только логических имен, то есть таких имен, в которых не содержится закодированных сведений о местоположении ресурса. Примером такого имени может быть URL: http://~wiv.prenhall.com/index.html, в котором не содержится никакой информации о реальном местоположении главного web-сервера издательства Prentice Hall. URL также не дает никакой информации о том, находился ли файл index.html в указанном месте постоянно или оказался там недавно. О распределенных системах, в которых смена местоположения ресурсов не влияет на доступ к ним, говорят как об обеспечивающих прозрачность переноса (mig-ration transparency). Более серьезна ситуация, когда местоположение ресурсов может измениться в процессе их использования, причем пользователь или приложение ничего не заметят. В этом случае говорят, что система поддерживает прозрачность смены местоположения (relocation transparency). Примером могут служить мобильные пользователи, работающие с беспроводным переносным компьютером и не отключающиеся (даже временно) от сети при перемещении с места на место.

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

Мы часто упоминаем, что главная цель распределенных систем — обеспечить совместное использование ресурсов. Во многих случаях совместное использование ресурсов достигается посредством кооперации, например в случае коммуникаций. Однако существует множество примеров настоящего совместного использования ресурсов. Например, два независимых пользователя могут сохранять свои файлы на одном файловом сервере или работать с одной и той же таблицей в совместно используемой базе данных. Следует отметить, что в таких случаях ни один из пользователей не имеет никакого понятия о том, что тот же ресурс задействован другим пользователем. Это явление называется прозрачностью параллельного доступа (concurrency transparency). Отметим, что подобный параллельный доступ к совместно используемому ресурсу сохраняет этот ресурс в непротиворечивом состоянии. Непротиворечивость может быть обеспечена механизмом блокировок, когда пользователи, каждый по очереди, получают исключительные права на запрашиваемый ресурс. Более изощренный вариант — использование транзакций, однако, механизм транзакций в распределенных системах труднореализуем.

Популярное альтернативное определение распределенных систем, принадлежащее Лесли Лампорт (Leslie Lamport), выглядит так: «Вы понимаете, что у вас есть эта штука, поскольку при поломке компьютера вам никогда не предлагают приостановить работу». Это определение указывает еще на одну важную сторону распределенных систем: прозрачность отказов. Прозрачность отказов (failure transparency) означает, что пользователя никогда не уведомляют о том, что ресурс (о котором он мог никогда и не слышать) не в состоянии правильно работать и что система далее восстановилась после этого повреждения. Маскировка сбоев — это одна из сложнейших проблем в распределенных системах и столь же необходимая их часть. Основная трудность состоит в маскировке проблем, возникающих в связи с невозможностью отличить неработоспособные ресурсы от ресурсов с очень медленным доступом. Так, контактируя с перегруженным web-сервером, браузер выжидает положенное время, а затем сообщает о недоступности страницы. При этом пользователь не должен думать, что сервер и правда не работает.

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

Степень прозрачности

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

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

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

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

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

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

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

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

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

Отделение правил от механизмов

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

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

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

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

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

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

Проблемы масштабируемости

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

Таблица 1.2. Примеры ограничений масштабируемости

Концепция

Пример

Централизованные службы

Один сервер на всех пользователей

Централизованные данные

Единый телефонный справочник, доступный в режиме подключения

Централизованные алгоритмы

Организация маршрутизации на основе полной информации

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

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

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

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

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

Первые три свойства поясняют то, о чем мы только что говорили. Последнее, вероятно, менее очевидно, но не менее важно. Любой алгоритм, начинающийся со слов: «Ровно в 12:00:00 все машины должны определить размер своих входных очередей», работать не будет, поскольку невозможно синхронизировать все часы на свете. Алгоритмы должны принимать во внимание отсутствие полной синхронизации таймеров. Чем больше система, тем большим будет и рассогласование. В одной локальной сети путем определенных усилий можно добиться, чтобы рассинхронизация всех часов не превышала нескольких миллисекунд, но сделать это в масштабе страны или множества стран? Вы, должно быть, шутите.

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

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

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

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

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

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

Технологии масштабирования

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

Сокрытие времени ожидания связи применяется в случае географического масштабирования. Основная идея проста: постараться по возможности избежать ожидания ответа на запрос от удаленного сервера. Например, если была запрошена служба удаленной машины, альтернативой ожиданию ответа от сервера будет осуществление на запрашивающей стороне других возможных действий. В сущности, это означает разработку запрашивающего приложения в расчете на использование исключительно асинхронной связи (asynchronous communication). Когда будет получен ответ, приложение прервет свою работу и вызовет специальный обработчик для завершения отправленного ранее запроса. Асинхронная связь часто используется в системах пакетной обработки и параллельных приложениях, в которых во время ожидания одной задачей завершения связи предполагается выполнение других более или менее независимых задач. Для осуществления запроса может быть запущен новый управляющий поток выполнения. Хотя он будет блокирован на время ожидания ответа, другие потоки процесса продолжат свое выполнение.

Однако многие приложения не в состоянии эффективно использовать асинхронную связь. Например, когда в интерактивном приложении пользователь посылает запрос, он обычно не в состоянии делать ничего более умного, чем просто ждать ответа. В этих случаях наилучшим решением будет сократить необходимый объем взаимодействия, например, переместив часть вычислений, обычно выполняемых на сервере, на клиента, процесс которого запрашивает службу. Стандартный случай применения этого подхода — доступ к базам данных с использованием форм. Обычно заполнение формы сопровождается посылкой отдельного сообщения на каждое поле и ожиданием подтверждения приема от сервера, как показано на рис. 1.2, а. Сервер, например, может перед приемом введенного значения проверить его на синтаксические ошибки. Более успешное решение состоит в том, чтобы перенести код для заполнения формы и, возможно, проверки введенных данных на клиента, чтобы он мог послать серверу целиком заполненную форму (рис. 1.2, б). Такой подход — перенос кода на клиента — в настоящее время широко поддерживается в Web посредством Java -апплетов.

Следующая важная технология масштабирования — распределение (distribution). Распределение предполагает разбиение компонентов на мелкие части и последующее разнесение этих частей по системе. Хорошим примером распределения является система доменных имен Интернета (DNS). Пространство DNS имен организовано иерархически, в виде дерева доменов (domains), которые разбиты на неперекрывающиеся зоны (zones), как показано на рис. 1.3. Имена каждой зоны обрабатываются одним сервером имен. Не углубляясь чересчур в детали, можно считать, что каждое доменное имя является именем хоста в Интернете и ассоциируется с сетевым адресом этого хоста. В основном интерпретация имени означает получение сетевого адреса соответствующего хоста. Рассмотрим, к примеру, имя nl . vu . cs . flits . Для интерпретации этого имени оно сначала передается на сервер зоны Z 1 (рис. 1.3), который возвращает адрес сервера зоны Z 2, который, вероятно, сможет обработать остаток имени, vu . cs . flits . Сервер зоны Z 2 вернет адрес сервера зоны Z 3 , который способен обработать последнюю часть имени и вернуть адрес соответствующего хоста.

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

В качестве другого примера рассмотрим World Wide Web . Для большинства пользователей Web представляется гигантской информационной системой документооборота, в которой каждый документ имеет свое уникальное имя — URL .

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

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

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

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

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


 

А также другие работы, которые могут Вас заинтересовать

81230. Разработка учебно-методических комплексов и внедрение их в учебный процесс 38.74 KB
  Модель электронного учебного курса ЭУК. ЭУК применяются в различных целях: для обеспечения самостоятельной работы обучаемых по овладению новым материалом реализации дифференцированного подхода к организации учебной деятельности контроля качества обучения и т. В первую очередь при проектировании ЭУК необходимо заложить в него технологические характеристики позволяющие впоследствии сделать учебновоспитательный процесс максимально эффективным. Выступая в качестве автоматизированной обучающей системы ЭУК должен выполнять следующие функции:...
81231. Предпрофильные и профильные курсы как средство дифференциации обучения информатике в общеобразовательной школе 35.83 KB
  В нормативном плане возможность реализации дифференциации в изучении информатики обеспечена рядом документов министерства образования РФ. Рекомендован переход к непрерывному изучению информатики в средней общеобразовательной школе предусматривающий три отмеченных выше этапа: пропедевтический базовый и дифференцированный. Общие цели и задачи профильнодифференцированных курсов информатики таковы: Способствовать учету интересов каждого из учащихся; Учитывать направленность допрофессиональной подготовки; Формировать основы научного...
81232. Методика изучения темы «Представление информации и информационные процессы»; подходы к измерению информации; формирование представлений о сущности информационных процессов в системах различной природы 41.47 KB
  Выработать ориентиры в существующих научных взглядах на феномен информации; сформировать умения: определять вид и свойства информации измерять информацию. Различные подходы к определению и измерению информации Подход к определению Подход к измерению в быту сведения сообщения их новизна новизна не измеряется в вычислит.
81233. Методика изучения основ алгоритмизации и начал программирования 36.51 KB
  Изучение учебного материала данного раздела обеспечивает учащимся возможность уяснить смысл понятия алгоритма узнать свойства алгоритма понять возможность автоматизации информационной деятельности человека при исполнении алгоритмов. Изучение понятия алгоритма призвано сформировать у учащихся способность не просто исполнять известные алгоритмы как это делает робот или какойлибо иной автоматисполнитель а осознанно строить алгоритмы. Основные определения Информатика наука об алгоритмах. Исполнителем алгоритма может быть человек животное...
81234. Методические рекомендации по теме «Первое знакомство с компьютером» 44.26 KB
  Функция Человек Компьютер Хранение информации Память Устройства памяти Обработка информации Мышление Процессор Прием информации Органы чувств Устройства ввода Передача информации Речь двигательная система Устройства вывода Устройства компьютера связаны между собой каналами передачи информации. Суть принципа программного управления компьютером сводится к следующим трем положениям: Любая работа выполняется компьютером по программе; Исполняемая программа находится в оперативной памяти; Программа выполняется автоматически. Затем следует...
81235. Методика изучения темы «дисковая ос». Методические рекомендации по изучению темы «Программы-оболочки ОС» 38.31 KB
  Любые операционные системы независимо от типа выполняют три основные функции: управление устройствами компьютера; взаимодействие с пользователем; работа с файлами. Третья функция операционной системы работа с файлами. Первоначальные понятия которые должны быть даны ученикам по данной теме это имя файла тип файла файловая структура логический диск каталог путь к файлу дерево каталогов. Для Windows сообщаете что имя файла может быть длинным до 255 символов и допускает использование русских букв.
81236. Методические рекомендации по организации и проведению практических занятий при изучении темы «Текстовый редактор» 36.45 KB
  Обучить основным приемам работы с текстовым редактором. Рекомендации по организации практической работы на компьютере. Навыки ввода и редактирования текста нужны пользователю не только для работы с текстовым редактором. Ввод и редактирование текстов осуществляется с помощью специальных программ – текстовых редакторов используемых в семействах операционных систем UNIX и MS Windows Семейство ОС Названия редакторов UNIX Emcs Vi TED Str Office Writer MS Windows Блокнот Word WordPd Лексикон Str Office Writer Несмотря на различия все...
81237. Методические рекомендации по организации и проведению практических занятий при изучении темы «Электронные таблицы» 38.16 KB
  Состав электронной таблицы. Прямоугольная область таблицы называется диапазоном ячеек. Каждая ячейка таблицы имеет следующие характеристики: адрес содержимое изображение формат имя примечание комментарий Абсолютная и относительная адресация ячеек.
81238. Методические рекомендации по организации и проведению практических занятий при изучении темы «базы данных» 38.44 KB
  Для сознательной работы с БД на уровне пользователя рекомендуется примерный минимум этих понятий: объект атрибут система связь; структурирование представление и нормализация данных; таблица первичный и внешний ключи; связь между таблицами индексирование поиск выборка и некоторые другие они имеют специфический неочевидный смысл. Обязательный минимум содержания образования по информатике в разделе информационные технологии: Базы данных. Системы управления базами данных.