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

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

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

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

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

- ни одна из машин не обладает полной информацией о состоянии применимой системы;

- машины принимают решения на основе локально информационных данных;

- возникший сбой на одной машине не вызывает нарушения рабочего алгоритма;

- не требуется предположения о существовании единого времени.

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

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

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

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

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

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

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

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

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

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

Рис 2.

Разница между проверкой формы по мере заполнения на сервере (а) и на клиента (б)

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

Рис. 3.

Пример разделения пространства DNS – имён на зоны

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

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

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

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