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

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

Система может масштабироваться по трем направлениям: 1) размер (дополнительные пользователи, ресурсы), 2) протяженность в географическом смысле, 3) администрирование (во множестве административно независимых организациях).

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

Количество пользователей в сети. Если оно удвоится, то, скорее всего, удвоится и нагрузка на сеть и базу данных.

Размер базы данных. С увеличением БД до десятков и сотен гигабайт операции резервирования, восстановления и загрузки станут узким местом.

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

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

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

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

На пути масштабируемости стоят

- централизованные службы,

- централизованные данные,

- централизованные алгоритмы.

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

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

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

Часто централизованная служба связана с централизованными данными. Централизованные данные часто легче защищать (проще устраивать резервное копирование). Но объем таких данных может оказаться настолько большим, что не хватит никаких разумных вычислительных мощностей. В централизованных хранилищах нередко усложняется поиск нужных данных. С одной стороны, время поиска растет при росте хранилища. С другой, в случае централизованного хранилища растет набор признаков – параметров поиска, так как с данными работает большое количество разных задач. Для централизованных данных очень важно делать архивные копии, чтобы снизить возможные потери при поломке централизованного хранилища. Пример централизованных данных – сервер базы данных (MY SQL, MS SQL и т.п.).

Масштабируемая система должна работать с децентрализованными данными. Хороший пример – служба DNS, сопоставляющая символьному имени сетевого ресурса его IP адрес. Архитектура дерева серверов DNS позволяет разделить информацию на фрагменты, каждый из которых поддерживается одним сервером. Между серверами установлена связь и определен протокол их взаимодействия. Обеспечение этой связи – цена применения децентрализованного хранилища. Децентрализованное хранилище обладает некоторым интересным свойством: неодинаковым временем доступа к информации. Для того чтобы сгладить эти различия, то есть с целью ускорения, по крайней мере, повторного доступа к удаленным данным DNS сервера применяют кэширование информации. Но, вы помните, что кэширование приводит к проблеме противоречивости данных. Проблемы, возникающие при децентрализации данных, основная из которых – противоречивость данных на разных компьютерах, рассмотрим чуть позже. Разберем 13 моделей непротиворечивости.

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

Технологии, применяемые при создании масштабируемых систем: скрытие времени ожидания связи, распределение, репликация.

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

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

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

Если мы имеем дело с кэшированием, то клиент (например, Internet Explorer) должен самостоятельно следить за актуальностью данных. Механизмы, применяемые для этого: а)запросы на обновление данных через определенное время, б) запросы об актуальности (неизменности на сервере). В первом случае может передаваться неизмененное данное, что излишне загружает сеть. А во втором сначала клиент выясняет, изменились ли данные, и только в случае их изменения отправляет запрос на пересылку данных. Очевидно, что если данные изменяются редко, то предпочтительнее использовать второй метод, в противном случае – первый. Теперь – несколько слов о непротиворечивости. В связи с тем, что в распределенной системе могут быть разные клиенты, которым требуется разная степень «свежести» для разных данных, разные данные обладают разным временем обновления и другими характеристиками, а передача данных это – дорогое удовольствие, то в разных случаях потребуются разные методы обеспечения непротиворечивости.

Дата добавления: 2013-12-12