Структура сервера базы данных.

 

В заключение рассмотрим физическую организацию сервера базы данных. Как правило, он включает следующие компоненты:

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

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

подсистема планирования выполнения запросов Данный модуль должен составить такой план выполения запроса, чтобы он был обработан наиболее быстро. Для этого анализируются условия выборок и соединений, устанавливается порядок их выполнения. Пусть, например, надо извлечь одного сотрудника из списка работников, в качестве критерия поиска задаются его имя и фамилия. Возможны два плана выполнения запроса: (1) вначале делается выборка всех сотрудников с данным именем, из нее извлекаются записи, содержащие данную фамилию; (2) - наоборот, вначале делается выборка по фамилии, затем по имени. Поскольку множество имен, как правило, меньше множества фамилий, во втором случае запрос будет обработан быстрее, т.к. на втором этапе здесь мы получим меньшую выборку. Планировщики запросов ведущих СУБД отслеживают информацию о распределении значений в таблицах. План выполнения запроса включается в его откомпилированный код.

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

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

 

2.6 Организация взаимодействия между серверами

 

 

2.6.1 Выбор модели распределенной базы данных

 

 

  Так как для обмена данными между серверами предполагается

использовать медленные асинхронные каналы связи, а также учитывая большое

количество серверов в данной информационной системе использован механизм

репликации данных. Недостатки этого механизма,  такие как задержка

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

 

2.6.2 Модель взаимодействия

 

 

Для организации репликации данных и удаленного администрирования

серверов в районах необходимо предусмотреть средства взаимодействия между

серверами. При анализе процесса взаимодействия серверов можно выделить

следующие компоненты системы:

. Процесс-клиент (сервер 1)

. Среда передачи данных

. Процесс-сервер (сервер 2)

 

В этой схеме в каждый конкретный момент времени в качестве клиента

выступает один из взаимодействующих серверов. Таким образом, на каждом из

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

взаимодействие с удаленным узлом сети. В Windows NT в качестве такого

процесса может выступать специально разработанный сервис операционной

системы (system service). Он должен «уметь» обслуживать подключения

удаленных клиентов, а также при необходимости сам выступать в роли клиента.

Кроме того, на него можно возложить функции удаленного администрирования и

резервного копирования данных.

  Для организации обмена информацией в общем случае необходимо

разработать протокол этого обмена, что само по себе является достаточно

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

различных транспортных протоколов (TCP/IP, NetBIOS, IPX/SPX), что

выливается в многократное дублирование программного кода. Для решения этой

задачи использован слой вызова удаленных процедур Microsoft RPC (Microsoft

Remote Procedure Call).

 

 

2.6.3 Использование слоя RPC для распределенной обработки данных на

платформе Windows NT

 

 

В соответствие с моделью RPC любой сервер может рассматриваться как

сервер вычислений, т.е. он может предоставлять свои вычислительные мощности

клиентам. Рабочая станция может послать запрос серверу на выполнение

определенных вычислений и возврат результатов. Используя RPC, клиент не

только использует файлы и принтеры сервера, но и разделяет его центральный

процессор с другими компьютерами в сети.

Слой Microsoft RPC - только часть стандарта среды для распределенных

вычислений, названной OSF (Open Software Foundation), разработанной группой

компаний для определения компонентов сетевой среды, которая поддерживает

распределенные вычисления.

 

2.6.4 Компоненты Microsoft RPC

 

 

Microsoft RPC включает следующие основные компоненты:

 

. Компилятор MIDL (Microsoft IDL)

   . Библиотеки времени выполнения и заголовочные файлы.

. Модули транспортного интерфейса

. Сервис разрешения имен

. Сервис поддержки конечной точки

 

В модели PRC можно формально определить интерфейс для удаленной

процедуры, используя язык, специально разработанный для этой цели. Этот

язык – IDL (Interface Definition Language - язык определения интерфейсов).

Диалект языка, реализованный фирмой Microsoft, назван MIDL (Microsoft IDL).

После создания интерфейса его описание обрабатывается компилятором

MIDL. MIDL компилятор генерирует «заглушки» (stubs), которые транслируют

вызовы локальных процедур в вызовы процедур, находящихся на сервере.

«Заглушка» -- это процедура-заполнитель, которая делает вызовы библиотечных

функций RPC для управления вызовами удаленных процедур. Применение заглушек

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

Клиентская программа вызывает их как локальные процедуры, весь код,

который передает данные по сети и принимает результаты, генерируется MIDL

компилятором и невидим для разработчика.

 

 

2.6.5 Механизм работы RPC

 

 

RPC позволяет клиенту напрямую вызывать процедуры, находящиеся в

программе на удаленном сервере. Клиент и сервер имеют различные адресные

пространства; так, каждый имеет свою собственную память, в которой

распределены данные, используемые процедурами. Следующий рисунок

иллюстрирует архитектуру RPC:

 

[pic]

 

                   Рис.2.3. Механизм работы RPC.

 

Как показано на рис.2.3, клиентское приложение вызывает локальную

заглушку вместо кода, непосредственно реализующего необходимую процедуру.

Заглушка компилируется и линкуется с клиентским приложением. Заглушка

клиента выполняет следующие действия:

 

. Запрашивает необходимые параметры из адресного пространства клиента

. Переводит параметры в стандартную форму представления данных в сети

   (NDR - standard network data representation)

. Вызывает необходимые функции из библиотеки времени выполнения RPC

   для отсылки запроса с параметрами на сервер.

 

Заглушка сервера выполняет следующие шаги:

 

. Библиотека времени выполнения RPC принимает запрос и вызывает

    процедуру заглушки сервера

. Заглушка сервера принимает параметра из буфера и конвертирует их из

   формата NDR в формат, процедуры сервера.

. Заглушка вызывает необходимую процедуру на сервере.

 

Удаленная процедура выполняется, генерирует выходные параметры и

возвращаемое значение. Когда процедура завершена, следующие шаги возвращают

данные клиенту:

 

. Удаленная процедура возвращает данные заглушке сервера

. Заглушка сервера конвертирует возвращаемые параметры в формат NDR и

   возвращает их функции библиотеки времени выполнения RPC

. Библиотечные функции передают данные через сеть на клиентский

   компьютер

 

Клиент завершает процесс принятием данных из сети и их возвратом

вызывающей функции:

 

. Клиентская библиотека времени выполнения RPC принимает значения,

   возвращаемые удаленной процедурой и возвращает их заглушке

. Заглушка клиента конвертирует данные из формата NDR в формат,

   используемый клиентским приложением

. Приложение клиента продолжает свою работу.

 

Для Microsoft Windows и Windows NT библиотеки времени выполнения

используются двумя путями: как статическая библиотека, линкуемая в

приложение; и библиотека, реализованная как DLL.

Серверное приложение содержит вызовы библиотеки времени выполнения

сервера, которая регистрирует интерфейсы сервера и позволяет серверу

принимать вызовы удаленных процедур. Серверное приложение также содержит

специфичные для каждого приложения процедуры, которые вызываются с клиента.

Таким образом, реализовав коммуникационный сервис на базе слоя RPC,

можно существенно сэкономить время на разработке протоколов обмена

информацией, а также получить систему, работающую по любым транспортным

протоколам.

 

2.6.6 Организация логического канала передачи данных

 

 

  Другой компонент модели - среда передачи данных может быть

реализована несколькими способами. В простейшем случае она может быть

построена на базе асинхронных каналов связи с использованием протоколов PPP

(Point to Point Protocol), а также на базе существующих сетей X.25. На

системный сервис можно также возложить ответственность за установление

логического канала между серверами.

В случае каналов X.25 для установления соединения используется

специальная каналообразующая аппаратура (коммутаторы X.25).

Решением начального уровня может служить удаленный доступ по протоколу

PPP (Point to Point Protocol). Организация удаленного доступа по

асинхронным каналам связи по протоколу PPP рассмотрена ниже.

 

 

2.7 Организация доступа удаленных пользователей

 

 

2.7.1 Необходимость удаленного доступа

 

 

При реализации данной системы экономически целесообразно устанавливать

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

абонентов достаточно велико. Для районов с малым числом абонентов наилучшим

решением является использование сервера баз данных ближайшего РУС. Для

этого необходимо организовать доступ операторов к территориально удаленному

серверу. Средой передачи данных в этом случае являются телефонные линии,

протоколом передачи на сетевом уровне - PPP (или SLIP).

 

2.7.2 Использование слоя RAS для удаленного доступа на платформе

 

Windows NT

 

 

На платформе Windows NT задача удаленного доступа по протоколу PPP

решается с помощью сервера RAS (Remote Access Server - сервер удаленного

доступа). Сервер RAS - это процесс, который принимает и обрабатывает

запросы клиентов на подключение через асинхронные линии и передачу данных.

Схема взаимодействия удаленного клиента с сервером RAS приведена на

рис.2.4.

 

[pic]

 

      Рис.2.4. Схема удаленного доступа с использованием RAS.

 

В качестве транспортного протокола могут использоваться протоколы

TCP/IP, IPX/SPX, NetBIOS. Подключение клиента через сервер удаленного

доступа абсолютно прозрачно, т.е. клиент может работать с удаленными

серверами так, как если бы он находился в локальной сети.

В системе Windows NT существует программный интерфейс приложений

(Application Program Interface), который позволяет установить логический

канал с удаленной сетью по асинхронному соединению. Он носит название RAS

API (Remote Access Service API).

Сервис удаленного доступа (RAS) позволяет удаленным пользователям

получить доступ к одному или нескольким RAS серверам также, как и по

локальной сети.

 Win32 RAS позволяет RAS-клиенту установить соединение, получить

информацию о существующих соединениях и завершить соединение. Связь

осуществляется по протоколам PPP или SLIP. В качестве транспортного

протокола могут быть использованы стеки TCP/IP, IPX/SPX и NetBIOS.

 

В Windows существуют стандартные программы для связи через RAS, таким

образом для работы с удаленной базой данных можно использовать стандартные

средства Windows.

 

2.7.3 Обеспечение информационной безопасности при удаленном доступе

 

 

Учитывая то, что информация на серверах баз данных носит коммерческий

характер, особую роль играет вопрос её защиты от несанкционированного

доступа. Система Windows NT имеет сертификат соответствия уровню

безопасности C2 Министерства обороны США. Данный уровень безопасности

предполагает обязательную идентификацию пользователей системы для

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

сеть также требует соответствующих привилегий, кроме того, все попытки

удаленного доступа обязательно фиксируются в журнале событий. В систему

Windows NT встроена возможность шифрования трафика в каналах передачи

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

каналах связи, не получает доступа к жизненно важным данным (пароли и имена

пользователей, финансовая информация).

Одним из способов ограничения доступа удаленных пользователей к

ресурсам сети является использования так называемых серверов-барьеров

(FireWalls) на стыке внутренней и внешней (какой в данном случае является

удаленный пользователь) сетей. В данном случае можно гибко регулировать

права удаленного пользователя на доступ к отдельным компьютерам в сети.

Кроме того, серверы-барьеры скрывают топологию сети от внешнего

пользователя. На платформе Windows NT функции сервера-барьера выполняет

продукт Microsoft Proxy Server. Одним из побочных эффектов использования

этого класса продуктов является экономия IP-адресов.