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

Масштабируемость системы может измеряться по трем различным показате­лям.

• а) Масштабируемость по отношению к размеру системы, что означает легкость подключения к ней дополнительных пользовате­лей и ресурсов.

• б) Географическая масштабируемость, то есть пользователи и ресурсы могут быть разнесены в пространстве.

• в) Масштабируемость в административном смысле, то есть система должна быть проста в управлении при работе во множестве административно независимых организаций.

Одна из важных технологий масштабирования — распределение. Распределение предполагает разбиение компонентов на мелкие части и по­следующее разнесение этих частей по системе.

Хорошим примером распределе­ния является система доменных имен Интернета (DNS). Пространство DNS-имен организовано иерархически, в виде дерева доменов, которые разбиты на неперекрывающиеся зоны,. Имена каждой зо­ны обрабатываются одним сервером имен. Не углубляясь чересчур в детали, можно считать, что каждое доменное имя является именем хоста в Интернете и ассоциируется с сетевым адресом этого хоста. В основном интерпретация имени означает получение сетевого адреса соответствующего хоста. Рассмотрим, к при­меру, имя nl.vu.cs.flits. Для интерпретации этого имени оно сначала передается на сервер зоны Z1, который возвращает адрес сервера зоны Z2, который, вероятно, сможет обработать остаток имени, vu.cs.flits. Сервер зоны Z2 вернет адрес сервера зоны Z3, который способен обработать последнюю часть имени и вер­нуть адрес соответствующего хоста.

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

Модель клиент-сервер

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

Разделение приложений по уровням

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

• уровень пользовательского интерфейса;

• уровень обработки;

• уровень данных.

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

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

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

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

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

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

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

Варианты архитектуры клиент-сервер

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

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

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

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

Иногда серверу может понадобиться работать в качестве клиента. Такая ситуация приводит нас к физически трехзвенной архитектуре.

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

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

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

Репликация — хранение нескольких копий одних и тех же данных.

Данные реплицируются для повышения надежности системы.

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

Другой довод в пользу репликации данных — производительность.

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

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

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

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

Модели непротиворечивости, ориентированные на данные

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

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

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