Распределенные системы

Классификация. Следует выделить два класса систем распределенной обработки и системы распределенных данных:

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

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

Для распределенных баз данных свойственны следующие ха­рактеристики:

• база данных — это логически связанные, разделяемые на некоторое количество фрагментов данные;

• фрагменты распределяются по разным узлам, которые свя­заны между собой сетевыми соединениями;

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

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

Основные условия и требования к распределенной обработке данных:

• прозрачность относительно расположения данных (СУБД должна представлять все данные так, как если бы они были локальными);

• гетерогенность системы (СУБД должна работать с данны­ми, которые хранятся в системах с различной архитектурой и производительностью);

• прозрачность относительно сети (СУБД должна одинаково работать в условиях разнородных сетей);

• поддержка распределенных запросов (пользователь должен иметь возможность объединять данные из любых баз, даже если они размещены в разных системах);

• поддержка распределенных изменений (пользователь дол­жен иметь возможность изменять данные в любых базах, на доступ к которым у него есть права, даже если эти базы размещены в разных системах);

• поддержка распределенных транзакций (СУБД должна вы­полнять транзакции, выходящие за рамки одной вычисли­тельной системы, и поддерживать целостность распределенной БД даже при возникновении отказов как в отдель­ных системах, так и в сети);

• безопасность (СУБД должна обеспечивать защиту всей рас­пределенной БД от несанкционированного доступа);

• универсальность доступа (СУБД должна обеспечивать еди­ную методику доступа ко всем данным).

Поясним некоторые из этих требований:

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

Любой пользователь или любая прикладная программа опе­рирует с одной или несколькими базами данных. В том случае, когда прикладная программа и сервер БД выполняются на од­ном и том же узле, проблемы расположения не возникает. Для получения доступа к базе данных пользователю или программе достаточно указать имя базы, например: SQL Dbname.

Однако в том случае, когда прикладная программа запуска­ется на локальном узле, а база данных находится на удаленном, возникает проблема идентификации удаленного узла. Для того чтобы получить доступ к базе данных на удаленном узле, необ­ходимо указать имя удаленного узла и имя базы данных. Если использовать жестко фиксированное имя узла в паре «имя_узла, имя_БД», то прикладная программа становится за­висимой от расположения БД. Например, обращение к БД «host: stock», где первый компонент — имя узла, будет зависимым от расположения.

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

Прозрачность сети. Клиент и сервер взаимодействуют по сети с конкретной топологией; для поддержки взаимодействия всегда используется определенный протокол. Следовательно, оно должно быть организовано таким образом, чтобы обеспечивать независимость как от используемого сетевого аппаратного обеспечения, так и от протоколов сетевого обмена. Чтобы обеспечить прозрачный доступ пользователей и программ к удаленным данным в сети, объединяющей разнородные компьютеры, коммуникационный сервер должен поддерживать как можно r лее широкий диапазон сетевых протоколов (TCP/IP, DECnet SNA, SPX/IPX, NetBIOS, AppleTalk и др.).

Автоматическое преобразование форматов данных. Как толь ко несколько компьютеров различных моделей под управлением различных операционных систем соединяются в сеть, сразу воз­никает вопрос о согласовании форматов представления данных Действительно, в сети могут быть компьютеры, отличающиеся разрядностью (16-, 32- и 64-разрядные процессоры), порядком следования байт в слове, представлением чисел с плавающей точкой и т. д. Задача коммуникационного сервера состоит в том чтобы на уровне обмена данными обеспечить согласование фор­матов между удаленным и локальным узлами с тем, чтобы дан­ные, извлеченные сервером из базы на удаленном узле и пере­данные по сети, были правильно истолкованы прикладной про­граммой на локальном узле.

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

Однако ни одна из существующих СУБД не дос­тигает этого идеала вследствие следующих практических проблем:

• низкая и несбалансированная производительность сетей передачи данных, что в распределенных транзакциях силь­но снижает общую производительность обработки;

• обеспечение целостности данных в распределенных тран­закциях базируется на принципе «все или ничего» и требу­ет специального протокола двухфазного завершения тран­закций, что приводит к длительной блокировке изменяе­мых данных;

• необходимо обеспечить совместимость данных стандартно­го типа, для хранения которых в разных системах исполь­зуются разные физические форматы и кодировки;

• трудности выбора схемы размещения системных каталогов. Если каталог будет храниться в одной системе, то удален­ный доступ будет замедлен. Если будет размножен, то из­менения придется распространять и синхронизировать;

• необходимо обеспечить совместимость СУБД разных типов и поставщиков;

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