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

решается с помощью сервера 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-адресов.

2.8 Проектирование структуры базы данных

Построим информационную модель системы расчета с абонентами.

В ходе исследования существующей схемы расчетов были выявлены следующие

основные сущности:

. Клиент (абонент, владелец телефона)

. Услуга

. Подразделение

. Начисление

. Телефонный разговор, подлежащий повременной тарификации

. Начисление за повременные разговоры (за один день)

. Оплата

. Категория клиента

. Проведенные расчеты

IDEF1X-диаграмма взаимодействия между этими сущностями представлена в

Приложении 6.

После нормализации данных и разрешения связей «многие ко многим» путем

введения граничных сущностей диаграмма принимает вид, указанный в

Приложении 6. Кроме того, для сущностей «Подразделение» и «Категория

абонента» введена обратная неидентифицирующая связь для иерархического

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

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

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

поддерживаться механизм регистрации изменений относятся:

. Клиент (владелец телефона)

. Услуга

. Подразделение

. Начисление

. Постоянное начисление

. Категория клиента

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

представленная на рис.2.5.

[pic]

Рис.2.5. Структура данных для поддержки механизма регистрации изменений

Суть данной модели такова:

1. Каждая сущность характеризуется набором состояний, изменяющихся во

времени.

2. Каждое состояние характеризуется набором атрибутов сущности, а также

датой начала и датой окончания состояния.

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

актуальной датой.

4. Дочерние таблицы ссылаются на сущность по её внешнему ключу.

5. При смене состояния внешний ключ не меняется.

Целостность данных обеспечивается с помощью триггеров на сервере.

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

подсистем:

. Картотека абонентов

. Начисления

. Повременный учет

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

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

SQL-скрипт для генерации базы данных представлен в Приложении 1.

2.9 Схема репликации данных

Тиражирование данных в системе построено по схеме с одним сервером

подписки (центральный сервер) и множеством серверов репликации (районы).

[pic]

Рис.2.6. Организация репликации данных.

Данные на центральном сервере доступны только для чтения чтобы

избежать конфликтов по модификации записи.

[pic]

Рис.2.7. Подробная схема репликации данных.

Схема репликации приведена на рис.2.7. Рассмотрим процесс передачи

изменений подробнее:

1. При изменении данных в реплицируемой таблице новые данные через

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

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

записи.

2. При возникновении в базе определенного события (например при большом

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

времени коммуникационный сервис запускает процесс репликации.

3. Процесс репликации устанавливает соединение с сервером подписки и

начинает синхронизацию данных.

4. Сервер подписки принимает измененную запись и модифицирует

соответствующим образом таблицу на своей стороне.

5. Если в процессе изменения записи был сгенерирован новый ключ, то он

передается на сервер репликации.

6. Сервер репликации заменяет первичный ключ реплицируемой записи на

ключ, возвращаемый с сервера подписки и удаляет соответствующую

запись из журнала изменений.

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

протокол двухфазной фиксации транзакций (Two-phase commit transactions),

что позволяет застраховаться от ошибок.

При синхронизации данных подобным методом процесс репликации может

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

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

очень плохих каналах связи.

2.10 Проектирование коммуникационного сервера

2.10.1 Постановка задачи

Для решения задач репликации, резервного копирования, удаленного

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

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

пользователей. Основные требования, предъявляемые к коммуникационному

серверу таковы:

1. Так как информационная система носит распределенный характер, а

также учитывая отсутствие квалифицированных кадров в местах

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

конфигурирования системы.

2. Для облегчения задач администрирования необходимо как можно более

полно автоматизировать выполнение наиболее часто встречающихся

задач, таких как резервное копирование данных и репликация.

3. Учитывая необходимость дальнейшего расширения системы необходимо

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

коммуникационного сервера.

4. Учитывая разнородность сети необходимо обеспечить возможность

подключения пользователей по нескольким протоколам: TCP/IP, Named

Pipes, IPX/SPX, NetBIOS.

2.10.2 Архитектура коммуникационного сервера

Учитывая специфику платформы Windows NT коммуникационный сервер

построен по архитектуре системного сервиса (System Service). Для разработки

коммуникационного сервера применялась среда разработчика Microsoft

Developer Studio 4.2/Visual C++ Enterprise Edition.

Архитектура сервера представлена в Приложении 2.

Для обеспечения наращиваемости системы проведено разделение

функциональности сервера на две части:

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

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

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

. Пользовательские задачи - обеспечивают реплицирование, резервное

копирование, синхронизацию картотек, съем данных с аппаратуры

повременного учета.

Пользовательские задачи реализованы в виде многопоточных DLL. Каждая

пользовательская задача должна обеспечивать две точки входа:

. void TaskProc(void) - основной поток - реализует необходимую

функциональность.

. void Terminate(void) - функция для принудительного останова задачи

(например при останове сервера)

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

(ключ HKEY_LOCAL_MACHINE\SOFTWARE\Svyazinform\CommService\Tasks, рис.2.8).

[pic]

Рис.2.8. Конфигурация задач коммуникационного сервера в реестре

Windows NT.

Ядро cервера построено по многопоточной архитектуре и включает в себя

следующие модули:

. Модуль инициализации - основная точка входа сервиса - регистрирует

сервис в диспетчере сервисов.

. Модуль управления сервисом - реализует функции запуска и останова

сервера.

. Планировщик задач - осуществляет запуск пользовательских задач в

заданное время.

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

пользователей, а также отвечает за удаленное конфигурирование

системы.

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

сервера в системный журнал событий.

2.10.3 Вспомогательное программное обеспечение

Для установки коммуникационного сервиса разработана программа,

регистрирующая сервис в системе и создающая необходимые ключи в реестре

Windows NT. Исходный код программы представлен в Приложении 4.

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

системного реестра. Исходный текст программы представлен в Приложении 5.

Для удаленного конфигурирования пользовательских задач разработано

клиентское приложение «Менеджер задач коммуникационного сервера».

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

(именами модулей и временем запуска). Главное окно программы представлено

на рис.2.9.

[pic]

Рис.2.9. Главное окно программы конфигурирования коммуникационного сервера.

Разработка программы велась с помощью пакета Microsoft Visual C++ 4.2.

Механизм реализации этой программы выходит за рамки данного дипломного

проекта.

3. Технико-экономическое обоснование

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

автоматизации расчетов с абонентами АО «Связьинформ» РМ.

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

экономический эффект от научно-исследовательских разработок, ограничимся

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

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

3.1 План выполнения дипломного проекта

В соответствие с темой дипломного проекта определяются этапы НИР и их

содержание. Этапы НИР необходимо максимально детализировать.

Таб.4.1. Этапы НИР.

|№ |Этап и содержание работы |Длительность|Трудоемкость|Исполнитель |

|n/n| |цикла, дн. |в % от общей| |

| | | |трудоемкости| |

|1 |2 |3 |4 |5 |

|1 |Постановка задачи и |5 |3,1 |И1, Р, Д |

| |составление технического | | | |

| |задания | | | |

|2 |Составление плана и |1 |0,7 |Д, Р |

| |календарного графика работы| | | |

|3 |Подбор и изучение |14 |10,55 |Д, Р |

| |технической документации и | | | |

| |литературы | | | |

|4 |Написание вводной части и |5 |4,35 |Д |

| |литературного обзора | | | |

|5 |Информационное |28 |20,25 |Д, Р |

| |моделирование системы | | | |

|6 |Разработка |12 |6,28 |Д |

| |коммуникационного сервера | | | |

|7 |Отладка коммуникационного |18 |8,35 |Д, Р |

| |сервера | | | |

|1 |2 |3 |4 |5 |

|8 |Написание теоретической |15 |14,07 |Д, Р |

| |части работы | | | |

|9 |Выводы по теоретической |2 |2,1 |Д, Р |

| |части проекта | | | |

|10 |Подбор данных и расчет |4 |2,85 |Д, К1 |

| |экономической части проекта| | | |

|11 |Анализ проделанной работы |2 |1,65 |Д |

|12 |Составление пояснительной |12 |8,4 |Д |

| |записки к дипломному | | | |

| |проекту | | | |

|13 |Оформление графической |12 |10,75 |Д |

| |части работы | | | |

|14 |Оформление приложений к |5 |3,025 |Д |

| |дипломному проекту | | | |

|15 |Сдача работы на отзыв |2 |1,65 |Д |

| |руководителю | | | |

|16 |Сдача работы на |2 |1,2 |Д |

| |рецензирование | | | |

|17 |Сдача дипломного проекта на|1 |0,725 |Д |

| |кафедру | | | |

| |ИТОГО: |140 |100 | |

Примечание: Д-дипломник;

И1-инженер-консультант

Р-руководитель

К1-консультант по экономической части

Трудоемкость выполнения НИР определяется по сумме этапов и видов

работ, оцениваемых экспертным путем в человеко-днях и носит вероятностный

характер, так как зависит от множества трудно учитываемых факторов.

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

Ожидаемая продолжительность работ рассчитывается по формуле:

[pic]

где Tmin - оптимистическая оценка времени разработки, исходящая из

наиболее благоприятных условий её выполнения;

Т н.в. - наиболее вероятная продолжительность выполнения

работы при

нормальных, чаще всего встречающихся условиях;

Т max - максимальное время выполнения работы при наиболее

неблагоприятных условиях её выполнения;

Одновременно с расчетом величины Тож. Определяют дисперсию (разброс)

по формуле:

[pic]

Дисперсия определяет степень неопределенности выполнения работы за

ожидаемое время Тож.

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

Таб.4.2. Продолжительность работ.

|№ |Этап и содержание работы |Tmin |Tн.в.|Tmax |Tож |Di |

|n/n| | | | | | |

|1 |2 |3 |4 |5 |6 |7 |

|1 |Постановка задачи и |3 |5 |7 |5 |0,44 |

| |составление технического | | | | | |

| |задания | | | | | |

|2 |Составление плана и |1 |1 |2 |1,167 |0,03 |

| |календарного графика работы | | | | | |

|3 |Подбор и изучение технической |12 |14 |16 |14 |0,44 |

| |документации и литературы | | | | | |

|4 |Написание вводной части и |3 |5 |7 |5 |0,44 |

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11