Kursovoy_2_dubl_2 (2)

на преобразование информации при переходе от одного протокола к другому

ина совместимость стандартов [8, c 8].

4)Безопасность. При использовании глобальной сети следует уделять большое внимание разработке программных средств защиты вычислительных узлов от внешних атак.

Становление систем управления базами данных совпало по времени со значительными успехами в развитии технологий распределенных вычислений и параллельной обработки. В результате возникли системы управления распределенными базами данных. Именно эти системы становятся доминирующими инструментами для создания приложений интенсивной обработки данных. В среде распределенных СУБД упрощается решение вопросов, связанных с возрастанием объема баз данных или потребностей обработки. При этом редко возникает необходимость в серьезной перестройке системы; расширение возможностей обычно достигается за счет добавления процессорных мощностей или памяти [8, c 8].

В идеале распределенная СУБД обладает свойством линейной расширяемости и линейного ускорения. Под линейной расширяемостью понимается сохранение того же уровня производительности при увеличении размера базы данных и одновременном пропорциональном увеличении процессорной мощности и объема памяти. Линейное ускорение означает, что с наращиванием процессорной мощности и объема памяти при сохранении прежнего размера базы данных пропорционально возрастает производительность. Причем при расширении системы потребуется минимальная реорганизация существующей базы данных [8, c 9].

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

и рабочих станциях именно по причине более выгодного соотношения

13

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

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

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

сами кластеры соединяются между собой посредством высокоскоростных магистралей [8, c 9].

Все эти причины привели к бурному развитию технологий распределенных баз данных информационных систем. Однако остаются нерешенными некоторые сложные вопросы связанные с данной темой. Один из этих вопросов - динамические процессы в распределенных базах данных.

1.3 Анализ состояния исследуемого вопроса

1.3.1 Объект и предмет исследования

Объектом исследования является распределенная база данных компьютерных информационных систем.

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

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

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

1)каждый узел обладает своими собственными системами баз данных;

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

На рисунке 5 приведен пример распределенной базы данных.

14

Рисунок 5 – Типичная распределенная база данных Система управления распределенной базой данных (РСУБД) – это

программная система, которая обеспечивает управление распределенной базой данных таким образом, чтобы ее распределенность была прозрачна для пользователей [1, c 4].

Эти определения можно дополнить, если рассмотреть также различные характеристики РБД и РСУБД. В 1981г К. Дейт опубликовал свои правила для распределенных баз данных. Ниже приведены эти 12 правил [1, c 4].

1.Локальная автономность. Локальные данные должны находиться под локальным владением и управлением, включая функции безопасности,

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

15

2.Никакой конкретный сервис не должен возлагаться на какой-либо специально выделенный центральный узел. Соблюдение этого правила,

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

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

4.Независимость от местоположения. Пользователи и приложения не обязаны знать о том, где физически располагаются данные.

5.Независимость от фрагментации. Фрагменты (называемые также разделами) данных должны поддерживаться и обрабатываться средствами РСУБД таким образом, чтобы пользователи или приложения могли бы вообще ничего не знать об этом. Более того,

РСУБД должна уметь обходить при обработке запросов фрагменты, не имеющие к ним отношения [1, c 5].

6.Независимость от тиражирования. Те же принципы независимости и прозрачности относятся и к механизму тиражирования.

7.Распределенная обработка запросов. Обработка запросов должна производиться распределенным образом.

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

9.Независимость от оборудования. Одно и то же программное обеспечение РСУБД должно выполняться на различных аппаратных платформах и функционировать в системе в качестве равноправного

16

партнера. На практике достичь этого исключительно сложно,

поскольку многие поставщики поддерживают множество платформ.

Это ограничение преодолевается с помощью модели много-

продуктовых сред.

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

11.Независимость от сети. Узлы могут быть связаны между собой с помощью множества разнообразных сетевых и коммуникационных средств. Многоуровневая модель, присущая многим современным информационным системам (например, семиуровневая модель OSI,

модель TCP/IP, уровни SNA и DECnet), обеспечивает решение этой проблемы не только в среде РБД, но и для информационных систем вообще.

12.Независимость от СУБД. Локальные СУБД должны иметь возможность участвовать в функционировании РСУБД [1, c 5].

1.4 Анализ методов моделирования РБД

РБД стали в настоящее время объектом всестороннего исследования.

При этом наряду с принципами конструирования и организации,

алгоритмами действия большое внимание уделяется методам анализа качества работы РБД, а также исследованию закономерностей их функционирования и взаимосвязи качества работы с особенностями конструктивных и алгоритмических решений [3, c 20].

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

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

17

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

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

связывающие искомые величины с параметрами исследуемых объектов и начальными условиями его изучения. Однако это удается выполнить только для сравнительно простых систем. Для РБД, которая является сложной системой, нам придется идти на упрощения представления реальных явлений, дающие возможность описать их поведение и представить взаимодействия между компонентами распределенной системы. Для построения аналитических моделей имеется мощный математический аппарат (алгебра, функциональный анализ, разностные уравнения, теория вероятностей, математическая статистика, теория массового обслуживания и т.д.) [3, c 21].

Аналитические модели распределенных баз данных предложены в ряде работ изданных в начале 90-х годов. В своей книге Г. Г. Цегелик рассмотрел несколько моделей РБД. Эти модели различаются разными подходами к их построению и выбранными топологиями. Эти модели позволяют оптимизировать распределение объектов РБД по узлам распределенной системы. Однако они построены при некоторых, очень значительных,

упрощениях. Самое существенное из них - это то, что эти модели статичны.

Т.е. они не учитывают влияние динамических процессов в РБД. Это приводит к неточности модели и мы не в состоянии измерить степень этой неточности.

Аналитическую модель также рассматривают А. Г. Мамиконов,

В. В. Кульба и др. Для этой модели характерны те же недостатки что и для

модели, предложенной Г. Г. Цегеликом.

18

Основными методами расчета параметров работы ИС, используемыми в настоящее время, являются методы теории массового обслуживания и,

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

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

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

Также при помощи теории массового обслуживания трудно предусмотреть все специфичные моменты работы реальных РБД. Поэтому для исследования предпочтительней использовать имитационное моделирование [3, c 21].

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

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

При всех преимуществах данного подхода автору неизвестны примеры использования методов имитационного моделирования для расчета параметров функционирования РБД в компьютерных информационных системах [3, c 22].

1.5 Применение имитационного моделирования к разработке

программных средств

При проектировании компьютерных сетей с технологией MPLS

(multiprotocol label switching – многопротокольной коммутации по меткам)

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

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

19

передаче трафика, выбор архитектуры сети по критерию стоимости оборудования. Важным является определение загруженности отдельных узлов или каналов связи сети при заданных ее параметрах, а также исследование поведения трафика разных классов [8, c 276].

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

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

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

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

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

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

Входными данными является модель компьютерной сети с технологиейMPLS, которая состоит из узлов LSR (label switching router –

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

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

(внеплановая, возможная) нагрузка на сеть.

20

Имеется возможность задания плана эксперимента, а именно: задается длительность эксперимента, количество тактов имитации в единицу времени

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

Далее после задания плана эксперимента запускается процесс имитации.

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

Все события, которые имеют место в течение этого промежутка времени,

считаем такими, что произошли одновременно. Таким образом, с точки зрения процесса имитации события, соответствующие определенному промежутку времени, начинаются от его начала, не зависимо от того, в какой момент времени они происходят на самом деле [8, c 276].

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

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

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

«первого» пакета. Эта процедура выполняется до тех пор, пока будет существовать первый пакет, который может быть обработан [8, c 276].

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

пакетов для возможной обработки). Рассмотрим отдельную итерацию.

21

Шаг 1. В начале цикла для параметров элементов модели устанавливаются начальные значения для текущего такта.

Шаг 2. До начала передачи через сеть MPLS пакетов трафика любого вида маршрутизаторы LSR устанавливают соответствие между метками и

FEC (forwarding equivalence class – классом эквивалентности при пересылке)

в своих таблицах.

Шаг 3. При получении данных о привязке меток к FEC каждый маршрутизатор LSR создает запись в таблице LIB (label information base –

информационной базе меток) . При любом новом согласовании привязки меток к FEC записи в таблице обновляются. Таблицы меток, согласно которым каждый пакет направляется по соответствующему LSP (label switched path – коммутируемому по меткам тракту), всегда должны быть заданы до того, как пакет начнет свой путь по сети [8, c 277].

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

Шаг 5. Сеть наполняется пакетами. В соответствии с расписанием событий происходит генерирование пакетов,которые должны быть переданы в сеть на текущем такте [8, c 277].

Шаг 6. Входной маршрутизатор, определив, какому FEC принадлежит принятый им извне пакет, использует таблицу LIB, чтоб отыскать нужную привязку «FEC-метка», и инкапсулирует эту метку способом,

соответствующим технологии на уровне 2.

Шаг 7. Для всех существующих пакетов состояние активности переводится в TRUE (состояние активности говорит о том, что данный пакет еще может быть обработан в течение текущего такта) [8, c 277].

Шаг 8. Пакеты сортируются в порядке их обработки в зависимости от накопленной задержки. Результатом сортировки является очередь пакетов

для обработки. После обработки каждого пакета выполняется повторная

22