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

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

2. Управление каталогом (В распределенной системе системный каталог включает не только обычные для каталога данные, касающиеся базовых переменных отношения, представлений, ограничений целостности, полномочий и т.д., но также содержит всю необходимую управляющую информацию, которая позволит системе обеспечить независимость от размещения, фрагментации и репликации. Возникает вопрос: «Где и как должен храниться сам каталог?». Имеется несколько перечисленных ниже возможностей.

1) Централизованное хранение. Единственный общий каталог хранится на отдельном центральном узле.

2) Полная репликация. Общий каталог целиком хранится на каждом узле.

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

4) Сочетание подходов 1 и 3. На каждом узле поддерживается свой локальный каталог, как предусмотрено в подходе 3. Кроме того, отдельный центральный узел сопровождает объединенную копию всех этих локальных каталогов, как предусмотрено в подходе 1.).

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

1) Одна копия для каждого реплицируемого объекта устанавливается как первичная копия, а все оставшиеся копии – как вторичные.

2) Первичные копии различных объектов находятся на различных узлах (поэтому данная схема также является распределенной).

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

4. Управление восстановлением (Управление восстановлением в распределенных системах обычно базируется на протоколе двухфазной фиксации транзакций (или некоторых его вариантах). Двухфазная фиксация транзакций требуется в любой среде, где отдельная транзакция может взаимодействовать с несколькими автономными диспетчерами ресурсов. Однако в распределенных системах ее использование приобретает особую важность, поскольку рассматриваемые диспетчеры ресурсов, т.е. локальные СУБД, функционируют на отдельных узлах и поэтому в значительной мере автономны. Рассмотрим некоторые особенности этого процесса, описанные ниже.

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

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

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

5. Управление параллельностью (управление параллельным доступом в большинстве распределенных систем строится на использовании механизма блокировки, т.е. точно так, как и в большинстве нераспределенных систем. Однако в распределенных системах запросы на проверку, установку и отмену блокировки становятся сообщениями (если считать, что рассматриваемый объект расположен на удаленном узле), а сообщения создают дополнительные издержки. Рассмотрим, например, транзакцию t обновления объекта, для которого существуют дубликаты на n удаленных узлах. Если каждый узел отвечает за блокировку объектов, которые на нем хранятся (как предполагается в соответствии с принципом локальной независимости), то непосредственная реализация будет требовать по крайней мере 5n таких сообщений:

· n запросов на блокировку;

· n разрешений на блокировку;

· n сообщений об обновлении;

· n подтверждений;

· n запросов на снятие блокировки.

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

Для решения проблемы обычно выбирается стратегия первичной копии. Для данного объекта А все операции блокировки будет обрабатывать узел, содержащий его первичную копию (напомним, что первичные копии различных объектов будут в общем случае размещаться на разных узлах). При использовании этой стратегии набор всех копий объекта с точки зрения блокировки можно рассматривать как единый объект, а общее количество сообщений будет сокращено с 5n до 2n+3 (один запрос блокировки, одно разрешение блокировки, n обновлений, n подтверждений и один запрос на снятие блокировки). Но обратите внимание на то, что это решение влечет за собой серьезную потерю независимости – транзакция может теперь не завершиться, если первичная копия окажется недоступной, даже если в транзакции выполнялось лишь чтение и локальная копия была доступна. Таким образом, у стратегии первичной копии есть нежелательный побочный эффект – снижение уровня производительности и доступности как для выборки, так и для обновления.)

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

1) Агент транзакции Т2 на узле X ожидает, пока агент транзакции Т1 на узле X освободит блокировку.

2) Агент транзакции T1 на узле X ожидает, пока агент транзакции Т1 на узле Y завершит транзакцию.

3) Агент транзакции Т1 на узле Y ожидает, пока агент транзакции Т2 на узле У освободит блокировку.

4) Агент транзакции Т2 на узле Y ожидает, пока агент транзакции Т2 на узле X завершит транзакцию. Налицо явная взаимоблокировка.

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

3. Системы «клиент-сервер». Двухуровневые модели «клиент-сервер»: модель файлового сервера, модель удаленного доступа к данным, модель сервера баз данных. Трехуровневая модель сервера приложений.

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

Основной принцип технологии "клиент-сервер" заключается в разделении функций приложения на три группы:

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

Поэтому, в любом приложении выделяются следующие компоненты:

• компонент представления данных
• прикладной компонент
• компонент управления ресурсом

Связь между компонентами осуществляется по определенным правилам, которые называют "протокол взаимодействия".