Содержание к диссертации
Введение
Глава 1. Задачи эксплуатационного управления телекоммуникационными сетями 12
1 1. Эволюция систем технической эксплуатации ТфОП 12
1.2. Актуальные аспекты проблематики NGOSS 22
1.3. Эволюция технологий баз данных 29
1.4. Распределенные базы данных 33
1.5 Текущее состояние, цель и задачи исследования 36
Выводы главы 1 41
Глава 2. Математическая модель баз данных эксплуатационного управления сетью связи 42
2.1 Функциональная модель 42
2.2. Принцип централизованной базы данных 48
2.3. Реплицированные базы данных для приложений OSS 52
2.4. Подход к построению моделей централизованной и реплицированных баз данных OSS 56
2.5. Вероятностно-временные характеристики архитектуры баз данных с полной репликацией 60
2.6. Вероятностно-временные характеристики архитектуры централизованной базы данных 69
Выводы главы 2
Глава 3. Анализ баз данных с частичной репликацией 73
3.1. Качественный анализ моделей централизованной и полностью реплицированных баз данных 73
3.2. Анализ вероятностно-временные характеристики баз данных с частичной репликацией 74
3.3. Численные результаты расчета вероятностно-временных характеристик баз данных 79
3.4. Анализ вероятностно-временных характеристик на последовательных этапах развертывания баз данных 88
3.5. Эволюционный алгоритм развертывания баз данных эксплуатационного управления сетью связи 90
Выводы главы 3 97
Глава 4. Инженерные принципы построения распределенных баз данных эксплуатационного управления сетью связи 98
4.1. Внедрение сетевых баз данных технического учета 98
4.2. Проблема упорядочения информации 104
4.3. Проблема ввода информации в базы данных эксплуатационного управления сетью связи 105
4.4. Соответствие концепции NGOSS 109
4.5. Принципы построения распределенных баз данных для технического учета 111
4.6. Апробация методов построения баз данных эксплуатационного управления сетью связи 117
Выводы главы 4 118
Заключение 119
Литература 122
Список сокращений 137
- Эволюция систем технической эксплуатации ТфОП
- Подход к построению моделей централизованной и реплицированных баз данных OSS
- Численные результаты расчета вероятностно-временных характеристик баз данных
- Принципы построения распределенных баз данных для технического учета
Введение к работе
Актуальность темы. Возникновение мультисервисных сетей связи, совпавшее по времени с началом либерализации телекоммуникационного рынка в 1990-е годы, привело к заметному усложнению систем эксплуатационного управления и к возникновению специализированных компаний – разработчиков отдельных систем технического учета (Inventory) и подготовки/предоставления услуги (Service Provisioning), а также других компонентов OSS (Operation Support System), чьи продукты сегодня работают у Операторов связи по всему миру. Более того, по мере усложнения компонентов OSS и их территориального и функционального распределения увеличиваются и затраты на интеграцию этих компонентов в единую информационную систему Оператора. Основой такой интеграции OSS становятся системы баз данных эксплуатационного управления, во взаимодействии с которыми функционируют другие модули OSS/BSS (Operation Support System/Business Support System).
В связи с этим возникла потребность научного анализа методов и моделей построения баз данных услуг, ресурсов и других активов Оператора, как и потребность решения методологических и технических вопросов построения эффективной сетевой архитектуры баз данных. Одной из составных частей этого анализа является настоящая диссертация.
Развитию теории управления сетями связи и централизации технической эксплуатации ТфОП посвящено множество работ, среди которых следует выделить полученные в недавнем прошлом результаты ученых – сотрудников ЛОНИИС, включая Л.Б. Маримонта, В.Л. Морева, Я.Г. Кобленца, и работы последнего времени, проводимые также в Санкт-Петербурге, но уже в СПбГУТ им. проф. М.А. Бонч-Бруевича под руководством проф. А.А. Костина, работы проф. В.А. Нетеса, исследования, проводимые в ИППИ РАН, ЦНИИС, МТУСИ. Имеются близкие к тематике этой диссертации результаты теории баз данных, рекомендующие рассматривать в качестве целевой функции максимизацию доступа к локальным базам данных, оптимизацию построения распределенных баз данных с целью сокращения времени поиска при ограниченном объеме памяти. Однако от намерения использовать эти существующие наработки пришлось отказаться из-за того, что ограничение объема памяти перестает играть сколь-нибудь существенную роль при проектировании сетевой архитектуры баз данных OSS. C другой стороны, начинают приобретать все большее значение ВВХ – вероятностно-временные характеристики OSS в реальном времени.
В недавнем прошлом работу системы Service Provisioning и, тем более, Inventory вряд ли можно было отнести к работе в реальном времени. Процессы технического учета касались прежде всего оборудования Оператора связи, которое вводилось в базы данных преимущественно вручную и, поэтому, выполнялись, в лучшем случае, в квазиреальном масштабе времени. Это и сегодня так в отношении традиционных телефонных услуг. Но для современных телекоммуникационных технологий конвергенции мобильной и фиксированной связи дело обстоит совсем не так: измеряемые в сотнях, а то и в десятках миллисекунд задержки для Service Provisioning новых инфокоммуникационных услуг определяют выполнение или невыполнение SLA (Service Level Agreement), а следовательно – эффективность функционирования сети Оператора связи и его конкурентоспособность на сегодняшнем и завтрашнем телекоммуникационном рынке.
В диссертационной работе рассматриваются модели баз данных OSS/BSS, их вероятностно-временные характеристики и стратегия построения эффективной сетевой архитектуры репликационных баз данных эксплуатационного управления сети связи при работе в реальном времени.
Объектом исследования являются сетевые базы данных эксплуатационного управления в OSS/BSS Оператора связи.
Предмет исследования – вероятностно-временные характеристики (ВВХ) разных сетевых архитектур баз данных эксплуатационного управления Оператора связи, влияющих на качество обслуживания абонентов.
Цель работы и задачи исследования. Цель работы заключается в разработке модели баз данных для поддержки эксплуатационного управления сетями связи, в исследовании ВВХ и стратегии построения сетевой архитектуры репликационных баз данных OSS сети связи.
Отсюда вытекает актуальность следующих решаемых в диссертационной работе задач, соответствующих сформулированной выше цели исследования:
1. Формализовать подходы к архитектуре баз данных OSS/BSS с учетом географического и функционального распределения источников обращений к ним в сети связи.
2. Разработать математическую модель для трех вариантов архитектуры баз данных OSS/BSS – централизованной, репликационной и частично репликационной.
3. Получить аналитические оценки ВВХ обслуживания обращений (запросов и обновлений) к централизованной базе данных OSS/BSS.
4. Получить аналитические оценки ВВХ обслуживания обращений к репликационным базам данных OSS/BSS.
5. Получить аналитические оценки ВВХ обслуживания обращений к частично репликационным базам данных OSS/BSS.
6. Выполнить сравнительный анализ ВВХ трех разных вариантов архитектуры баз данных OSS/BSS.
7. Разработать рекомендации по выбору эффективной стратегии организации баз данных OSS/BSS и провести экспериментальную проверку эти рекомендаций.
Методы исследования. В качестве основных методов анализа в диссертационной работе выбраны методы теории массового обслуживания, математические методы исследования операций.
Достоверность результатов. Достоверность результатов подтверждается корректной постановкой задачи, применением строгого математического аппарата, формулировок выводов, адекватностью применяемых моделей баз данных и результатами экспериментальной проверки базирующихся на этих моделях инженерных решений.
Научная новизна. Научная новизна диссертационной работы заключается в формализованном подходе к архитектурам баз данных OSS/BSS с учетом географического и функционального распределения источников обращений к ним, в разработке математических моделей для трех вариантов архитектуры баз данных OSS/BSS; в получении аналитических оценок ВВХ обслуживания обращений к трем разным вариантам архитектуры баз данных OSS/BSS; в инженерных рекомендациях по синтезу эффективной стратегии организации баз данных OSS/BSS.
Личный вклад. Все результаты, составляющие содержание диссертационной работы, получены автором самостоятельно.
Практическая ценность и реализация результатов работы. Результаты, полученные в диссертационной работе, могут быть использованы проектными организациями при разработке проектов баз данных OSS/BSS телекоммуникационных сетей; межрегиональными компаниями ОАО «Связьинвест» и другими Операторами связи при организации, модификации существующей архитектуры баз данных или при выборе интегрированных систем OSS/BSS, научно-техническими центрами, занимающимися разработкой подсистем OSS/BSS.
Апробация работы. Основные результаты работы докладывались, обсуждались и были одобрены на ежегодных научно-технических конференциях аспирантов СПбГУТ им. проф. М.А. Бонч-Бруевича в 2004 – 2009 годах, на заседаниях кафедры систем коммутации и распределения информации, на постоянно действующем научном семинаре по телетрафику под руководством проф. Г.Г. Яновского, на ежегодных научно-технических конференциях профессорско–преподавательского состава, научных сотрудников и аспирантов СпбГУТ им. проф. М.А. Бонч-Бруевича в 2005 – 2009 годах.
Публикации. По теме диссертации опубликовано 8 печатных работ, в том числе, 4 статьи в журналах из перечня, рекомендованного ВАК РФ для публикации результатов диссертационных исследований.
Основные положения, выносимые на защиту:
математическая модель централизованной базы данных технического учета,
математическая модель репликационной базы данных технического учета,
математическая модель частично репликационной базы данных OSS/BSS,
аналитические оценки ВВХ обслуживания обращений к трем разным вариантам архитектуры баз данных OSS/BSS,
рекомендации по синтезу эффективной стратегии организации баз данных OSS/BSS.
Структура и объем работы. Диссертационная работа состоит из введения, четырех глав, заключения, списка литературы и приложений. Работа содержит 137 страниц машинописного текста, 18 рисунков и 3 таблицы. Список литературы включает в себя 148 наименований.
Эволюция систем технической эксплуатации ТфОП
Проблемам технической эксплуатации телефонных сетей общего пользования (ТфОП) ровно столько же лет, сколько самим ТфОП. Не имея возможности изложить здесь полную историю эволюции систем и средств эксплуатации ТфОП (включая значительный объем исследований и множество защищенных диссертаций по централизации технической эксплуатации в 70-х и 80-х годах прошлого века), ограничимся лишь последними двадцатью годами [17].
За эти двадцать лет эксплуатационное управление в отрасли телекоммуникаций претерпело действительно революционные изменения. Прежде всего, они связаны с более широким применением информационных технологий [26]. Это и не удивительно, т.к. само развитие телекоммуникационной отрасли, все более и более ориентированной на новые инфокоммуникационные услуги в сфере обработки и передачи информации и новые способы связи, определило и радикальное изменение принципов и подходов к организации технической эксплуатации телекоммуникационных сетей [18]. Этим радикальным изменениям немало поспособствовали и усиливающаяся все эти годы конкуренция на телекоммуникационном рынке, все более высокие требования пользователей к многообразию, функциональным возможностям и качеству телекоммуникационных услуг [28].
Начало радикальных изменений в технической эксплуатации датируется 1980-ми годами. На смену устаревшим ручным способам инсталляции и технической эксплуатации оборудования телефонных сетей пришла механизация. Одной из первых таких систем была CAROT (Centralized Automatic Reporting on Trunks), заменившая средства ручного тестирования и предоставившая средства для быстрого устранения неисправностей.
Необходимость уменьшения стоимости технического обслуживания на границе 1980-х и 1990-х годов привела к этапу автоматизации, когда на основе микропроцессоров начали автоматизировать многие функции обслуживающего персонала. Примером, иллюстрирующим этот этап, может служить разработка систем эксплуатации на базе архитектуры SNA (System Network Architecture) компании ЮМ.
В 90-х годах прошлого века появились клиент-серверные технологии технической эксплуатации, распределённые системы управления и особо интересные в контексте этой диссертационной работы интегрированные базы данных технической эксплуатации. Важным фактором в развитии средств распределённого управления сетями связи явились создание объектно-ориентированной модели агент-менеджер и разработка информационных моделей управления ресурсами [25]. Первоначально разные производители сетевого оборудования реализовывали эти принципы каждый по-своему, что стимулировало разработку общесетевых стандартов эксплуатационного управления сетью электросвязи. Вопросами стандартизации в области технической эксплуатации телекоммуникаций занимаются несколько различных организаций. В контексте диссертационной работы из них следует выделить Сектор стандартизации электросвязи Международного союза электросвяи ITU (International Telecommunication Union - Telecommunication Sector) и Европейский интститу стандартизации в телекоммуникациях ETSI. Кроме официальных организаций, существует еще ряд промышленных консорциумов и некоммерческих объединений, которые занимаются разработкой альтернативных документов и соглашений, регламентирующих принципы и технологии построения систем эксплуатационного управления телекоммуникационными сетями и услугами. К числу альтернативных структур можно отнести TMForum, Eurescom, OMG и др. Наиболее весомый вклад в дело дальнейшего развития технологий управления вносит TMForum (TMF). Об этой организации речь пойдет несколько ниже, а пока обратимся к официальным стандартизующим органам. Лидирующие позиции в тройке "официальных" организаций занимает ITU. Именно ITU выдвинул в свое время идею технологии TMN (Telecommunications Management Network), которая, несмотря на довольно серьезную критику, остается жизнеспособной по сегодняшний день [35].
В диссертационной работе автор ориентируется [88, 113, 100] на важнейшие для целей этого исследования серии рекомендации ITU по TMN:
М.ЗООО series: TMN Overall Principles and Framework,
M.3100 series: TMN Models and Object Definitions,
M.3200 series: TMN Management Services,
M.3400 series: Management Functions supporting TMN Services,
M.3050 series: Enhanced Telecom Operations Map,
M.3060 series: NGN principles and architecture, а также на некоторые другие рекомендации, учитываемые в материалах главы 4 диссертационной работы - на рекомендацию М.60 Section2: TMN Terminology & Definitions, на рекомендацию G.7718, G.7718.1 ASON control plane management, на рекомендацию G.774: SDH Management Information Model for the Network Element View и на документы рабочей группы TISPAN Европейского института ETSI стандартизации в области телекоммуникаций TS 08006: Vision for NGN OSS и DTS 08007: NGN OSS architecture for Rl.
Упрощенно логическая организация TMN обычно изображается в виде пирамиды, представленной на рис. 1.1 и имеющей пять основных уровнен.
Уровень сетевых элементов NEL (Network Element Layer) является интерфейсным между базой данных управляющей информации МЮ (о которой чуть ниже), находящейся на конкретном устройстве, и остальной инфраструктурой TMN. К этому уровню относятся адаптеры QA и сетевые элементы NE.
Уровень эксплуатационного управления элементами EML (Element Management Layer) соответствует средствам управления ЕМ (Element Manager), контролирующим работу отдельных групп сетевых элементов. На этом уровне реализуются функции решения задач управления оборудованием разных производителей. Уровень EML включает в себя также устройства адаптации MD, взаимодействующие с системой поддержки работоспособности OSS (Operations Support System) через интерфейс Q3.
Т.к. здесь мы начинаем подробнее обсуждать один из наиболее распространенных в диссертационной работе термин OSS, дадим его общее определение: «Система поддержки работоспособности OSS — это общая централизованная система технической эксплуатации, которая основана на единой технологии управления системами связи, включающей в себя информационные системы эксплуатации, процессы управления эксплуатацией систем и людей, которые взаимодействуют с системами в рамках бизнес-процессов». Как раз входящим в OSS согласно этому определению информационным системам - базам данных - и посвящаются основные исследования диссертационной работы. Но прежде продолжим рассмотрение TMN.
Уровень эксплуатационного управления сетью NML (Network Management Layer) формирует представление телекоммуникационной сети в целом на основе информации об отдельных сетевых элементах, которую он получает от систем управления EML предыдущего уровня через интерфейс Q3. Вся специфика управления собственно сетью сосредоточена на этом уровне, а потому именно здесь осуществляется контроль взаимодействия ее элементов (сетевых элементов, адаптеров, медиаторов), отслеживается нагрузка каналов и узлов сети. Кроме того, на уровне NML выполняется контроль работоспособности сети в целом и производится анализ возникающих неисправностей.
Уровень эксплуатационного управления сетевыми услугами SML (Service Management Layer) охватывает те параметры функционирования сети, с которыми сталкиваются в своей работе пользователи. В соответствии с общими принципами TMN на этом уровне используется информация, поступающая с NML, однако непосредственное управление сетевыми элементами не осуществляется. Примерами функций, относящихся к управлению сетевыми услугами, являются контроль качества обслуживания и выполнения соглашений об уровне обслуживания, биллинг, взаимодействие с другими системами OSS.
Подход к построению моделей централизованной и реплицированных баз данных OSS
Так как основная цель исследования состоит в том, чтобы сравнить вероятностно-временные характеристики (ВВХ) архитектуры централизованной БД и архитектуры полностью и частично реплицированных баз данных, далее будем учитывать четыре компонента этих версий архитектуры:
центральная база данных (ЦБД) в центральном регионе,
реплицированные базы данных (РБД) в других регионах (филиалах, функциональных областях),
двунаправленные каналы обмена данными, соединяющие ЦБД и РБД,
задержки обслуживания запросов (обращений и обновлений).
Такой укрупненный подход остается применимым, когда для моделей необходимых компонентов используются разные дисциплины обслуживания очередей. Например, в зависимости от используемых компьютеров баз данных и от особенностей их работы, в структуре могут быть приняты модели организации очередей самых разных уровней сложности.
Рассмотрим обращения непосредственно из центрального региона, помеченные как G-обращения. Они, как и генерированные в центральном регионе обновления, пересыпаются в ЦБД для обработки. Кроме того, в архитектуре с полной репликацией ЦБД всегда содержит (пусть частично) данные обо всех объектах, независимо от того, находятся ли они в центральном или в периферийном регионе. Поэтому после обработки G-обрагцений, база ЦБД посылает ответы запрашивавшим подсистемам OSS центрального региона.
В схеме с частичной репликацией, однако, G-обраіцения, касающиеся объектов других регионов, часто не обнаруживают обновленных данных в ЦБД. Тогда ЦБД пересылает эти обращения по каналу передачи данных в соответствующую РБД, которая обрабатывает полученные G-обращения и посылает ответы через канал передачи данных обратно в подсистемы OSS центрального региона.
Теперь рассмотрим обращения из других, отличных от центрального, регионов, помеченные как F-обращения. В схемах с полной и с частичной репликацией F-обращения и обновления, генерированные в периферийных регионах с номерами 2, 3, ... (здесь и далее номер 1 оставим для центрального региона), сначала поступают в соответствующую этому периферийному региону РБД. Если F-обращение обнаруживает необходимую запись об объекте, РБД может обработать обращение и послать ответ прямо в обратившееся приложение OSS, находящееся в периферийном регионе. Однако если необходимая запись не найдена, РБД посылает не удавшееся F- обращение по каналу передачи данных в ЦБД. В свою очередь, ЦБД обрабатывает неудачные F-обращения, и посылает ответы через канал передачи данных обратно в приложение OSS, находящееся в периферийном регионе.
Как упоминалось выше и, в частности, в разделе 2.3, у приложений OSS в периферийном регионе есть два возможных метода регистрации объектов в базе данных. В обоих методах сообщения регистрации, включая информацию о новом объекте и другие данные, рассматриваются как обновления. В первом случае их сначала обрабатывает РБД, и затем - ЦБД. Во втором случае репликационные данные вводятся в РБД путем загрузки, т.е. копия всей записи о новом объекте загружается в РБД после того, как соответствующее обновление обработано ЦБД.
Для того чтобы идентифицировать ключевые переменные и получить возможность сравнивнить вероятностно-временные характеристики решшкационной и централизованной архитектуры базы данных, необходимо сделать еще следующие вполне естественные допущения:
каждая из ЦБД и РБД имеет один процессор, отвечающий за обработку как обращений, так и обновлений; его моделью является очередь к единственному серверу БД, где обращения и обновления обрабатываются по принципу "первым пришел, первым обслужен" (FIFO);
при создании репликационных записей в РБД методом загрузки время дополнительной обработки данных в процессорах баз ЦБД и РБД предполагается незначительным, поскольку при загрузке используется, главным образом, прямой доступ к памяти или доступ к диску;
моделью канала передачи данных в каждом направлении служит очередь к единственному обслуживающему прибору. Запросы обращения и обновления, а также загружаемые записи этот прибор обслуживает в соответствии с дисциплиной FIFO;
очереди к процессорам и к каналам передачи данных рассматриваются как независимые очереди М/G/l, т.е. все значения времени обработки и передачи данных имеют экспоненциальные распределения с идентичными значениями математического ожидания;
предполагается, что при каждом взаимодействии с базой данных приложение OSS или другой источник обращений требует доступа к записи о соответствующем объекте в среднем Mq раз, т.е. количество обращений, приходящихся на одно взаимодействие, является случайной величиной с математическим ожиданием Mq.
Для схемы с частичной репликацией добавим еще два следующих дополнительных допущения (которые подробнее объясним позже):
только при одном из Mq обращений требуется доступ к часто изменяемым данным;
обновляться будут только часто изменяемые данные (такие, например, как "резервированная полоса пропускания"), а обновление не часто обновляемых данных (например, адрес абонента) происходит только во время регистрации.
Чтобы анализировать рабочие характеристики схем централизованных и репликационных баз данных, необходимо определить ключевые параметры.
Во избежание громоздкой аналитической модели первоначальный анализ выполняется здесь всего для двух регионов, например, для географических образований - центральный регион и периферийный регион3. Затем показывается, как можно этот анализ обобщить на реальные сети МРК с числом регионов, большим двух. С учетом вышесказанного вводятся следующие обозначения:
Р - доля приложений OSS, которые требуют доступа к БД не своего региона (т.е. оценка вероятности того, что в регионе 2 потребуется взаимодействие с записью БД региона 1), а также доля всех обновлений базы данных OSS, инициированных объектами, которые находятся вне центрального региона,
cg- доля запросов, инициированных в регионе 2 и требующих обращения к объекту, запись о котором хранится в ЦБД, с - доля запросов инициированных в регионе 2 и требующих обращения к объекту, запись о котором в настоящее время находятся в РБД, F - отношение интенсивности потока обращений к БД к интенсивности потока обновлений записей в БД, т.е. среднее число обращений к БД, приходящихся на одно обновление содержимого БД. Fr - отношение интенсивности потока обращений к БД к интенсивности потока регистрации новых записей в БД, т.е. среднее число обращений к БД, приходящихся на одну новую запись в БД, Mq - среднее число обращений к базе данных при одном запросе взаимодействия
Численные результаты расчета вероятностно-временных характеристик баз данных
Как уже отмечалось в главе 2, чтобы обеспечить корректное сравнение вероятностно-временных характеристик архитектуры централизованной базы данных и баз данных с репликацией, нагрузка сервера рс для централизованной базы данных принята равной 0.9 при разных значениях интенсивности потоков обращений и обновлений, которые создаются в центральном регионе и за его пределами, варьируемых в соответствии с другими параметрами. Для простоты в этом расчете принимается c/=cg. Кроме того, предполагается, что продолжительность обработки обращений и обновлений распределена экспоненциально со средними значениями Tq = 8 мс и Ти = 16 мс, соответственно. Если не будет указано иное, средняя длина сообщений обращения и обновления (а также ответа на обращение) равна 80 байтам, а средняя длина записи для загрузки - 2 Кб. Скорость передачи битов по каналу предполагается стандартной и равной 64 Кбит/с в каждом направлении. Значения времени передачи по каналу сообщений обращения к базе данных, обновления и загружаемых записей предполагаются распределенными экспоненциально со средними значениями Sq=Su=10 мс, и Sd=253 мс. Эти значения определяются длинами сообщений и скоростью передачи по каналу. Задержка распространения сигнала равна 50 мс.
Вышеупомянутые значения продолжительности обработки в базах данных и длины сообщения основаны на измерениях параметров в базах данных OSS платформы Аргус, установленных в сетях ряда филиалов МРК, к чему мы вернемся в главе 4 диссертационной работы.
Сначала удобнее рассмотреть результаты сравнения централизованной и полностью реплицированных баз данных, так как эти результаты не зависят от значения Мд. Средние значения времени ответа на обращения как функции доли обращений из периферийного региона (то есть С/ и cg, поскольку они, как предполагается, являются равными) для полностью реплицированной и для централизованной баз данных изображены на рисунке 3.1. Параметр Fu выбран равным 10. Таким образом, в среднем, совершается 10 обращений к РБД между двумя последовательными обновлениями ее содержимого. На рис. 3.1 показаны графики для одного значения доли записей в базе данных, нужных в работе приложений OSS вне своего региона, т.е. параметра Р = 0.1.
Доля запросов, генерируемых в периферийном регионе Рис. 3,1. Время ответа на обращение npnFu =10 Из графиков на рис.3.1 вытекает, что пока хоть какая-то часть запросов поступает из периферийном региона, т.е. когда доля запросов, генерируемых в периферийном регионе, больше 0, полностью реплицированная база данных демонстрирует среднее значение времени ответа на обращение ниже, чем централизованная база данных.
Более того, когда большинство обращений поступает из периферийного региона, т.е. доля запросов, генерируемых в периферийном регионе, приближается к 1, чрезмерное количество сообщений с обращением может вызвать перегрузку канала передачи данных во входящем направлении (от РБД к ЦБД), приводя к недопустимому увеличению задержки в случае централизованной базы данных, что может потребовать дополнительного числа каналов, т.е. увеличения ресурсов сети передачи данных, обслуживающей OSS/BSS. Реплицированные базы данных такой опасности не подвержены.
Как можно было ожидать интуитивно, время ответа на обращение к базе данных с репликацией уменьшается при увеличении параметра Р. На рис. 3.2 показаны результаты тех же расчетов, что и на рис. 3.1, но уже для двух значений Р=0.5иР=0.9.
Продолжим использовать те же самые параметры трафика и сравним значения среднего времени ответа для баз данных всех трех типов. Проведем сравнение всех трех схем при разных значениях Мд - математического ожидания количества обращений к записи о соответствующем объекте БД при каждом взаимодействии с базой данных приложения OSS или другого источника обращений. Как и раньше, примем, что средняя длина сообщения равна 50 байтам. Средние значения времени ответа на обращение как функция доли запросов, поступающих из периферийного региона, для централизованной БД, а также для полностью и частично реплицированных баз данных показаны на рисунках 3.3 — 3.5, уже при Fu-l и при трех разных значенияхР =0.1, 0.5 и 0.9, соответственно.
Сначала следует отметить, что время ответа на обращение к централизованной БД и к БД с полной репликацией не зависит от числа Mq обращений, приходящихся на один запрос. Это обусловлено методом анализа, который предусматривает, что рс фиксировано, так что интенсивность обращений и обновлений не изменяются с Mq. С другой стороны, когда Mq в схеме с частичной репликацией увеличивается, время ответа снижается. Это имеет место потому, что при увеличении Mq ЦБД может успешно обработать больше обращений, снижая, таким образом, нагрузку РБД и канала передачи данных в исходящем направлении. Во-вторых, когда большинство запросов инициировано в периферийном регионе, чрезмерное количество сообщений обращения может перегрузить канал передачи данных во входящем направлении, вызвав таким образом большое увеличение задержки для централизованной базы данных.
Важно то, что когда Р является относительно небольшим, например, Р=0.1, как на рис.3.3, или больше, то схема с частичной репликацией демонстрирует среднее значение времени ответа на обращение ниже, чем схема с централизованной и с полностью решшцированной БД. Однако при увеличении Р схема с частичной репликацией не всегда функционирует так же успешно, как схема с полной репликацией. Как показано на рисунке 3.5, при большом Р и малом Mq, когда большинство запросов инициировано в центральном регионе, по-видимому, сначала будут выполняться двойные обращения к ЦБД, а затем - к РБД, так что задержка получения нужных данных возрастет.
Численные результаты, полученные для больших значений Fu, также показывают, что схема с полной репликацией работает лучше, чем схема с частичной репликацией, но уже при незначительном увеличении Р, когда объекты редко появляются или удаляются, т.е. когда Fu гораздо больше 1 (рис. 3.1 -3.2.).
Теперь перейдем к итоговому рисунку 3.6, где показано сравнение среднего времени реакции на обновление для трех схем. Сделаем это «для чистоты эксперимента» при Fu \, как это было на рис. 3.3-3.5.
Принципы построения распределенных баз данных для технического учета
В преобладающих сегодня базах данных OSS/BSS не все данные хранятся централизованно; они распределены по сети узлов, удаленных географически, но связанных коммуникационными линиями. Каждый узел имеет свою собственную базу данных; кроме того, он может обращаться к данным, хранящимся в других узлах.
Решгацированные и частично реплицированные базы данных предусматривают наличие нескольких узлов, каждый из которых работает с локальной базой данных в тех видах деятельности, где требуются только локальные данные. Кроме того, каждый узел может обрабатывать транзакции, для которых необходимы данные, хранящиеся в других узлах. Для этого требуется, чтобы разные узлы могли передавать данные друг другу. Коммуникационные линии, обеспечивающие необходимые возможности обмена данными, называются соединениями. Структура соединений образует базовую архитектуру реплицированных и частично реплицированных баз данных.
Приложение взаимодействует с базами данных OSS/BSS, запуская программы, которые в математических моделях глав 2 и 3 назывались обращениями или просто заявками, а на уровне реализации обычно называются транзакциями. Транзакция в таких системах больше не сводится к одному процессу, контролируемому одним программным модулем; она может вызывать несколько процессов в разных узлах, контролируемых независимыми программными модулями. Тогда каждый из процессов, взаимодействующих внутри транзакции, называется агентом. Транзакция, состоящая из одного агента, называется локальной транзакцией. Транзакция, для которой необходимы несколько агентов, называется глобальной транзакцией.
Каждый агент может обращаться прямо только к данным, которые контролирует его локальное программное обеспечение. Доступ к данным других узлов требует взаимодействия с агентами этих узлов. Агент, начинающий транзакцию, называется инициирующим агентом. С целью доступа к нужным данным инициирующий агент может требовать активизации агентов других узлов. Будучи активизированными, два или более агента могут обмениваться сообщениями. Транзакции обращаются к записям операциями read (читать) и write (записать). Read (х) дает текущее значение х. Write(x) вводит новое значение, заменяя им текущее значение х. Транзакция передает команды чтения и записи в базы данных и выполняет конечный ввод и вывод.
Ниже в этом разделе мы обсудим некоторые виды стратегии и цели, общие для большинства реализаций реплицированных и частично реплицированных баз данных. К ним относятся неявность адресации, которая позволяет пользователю обращаться к данным, не зная и не интересуясь, на каком именно узле они расположены.
Неявность тиражирования связана с тем, что если существует более одной копии данных, то при извлечении данных необходимо выбирать одну копию, а при внесении изменений в данные необходимо обновлять все копии. Выбор одной копии при извлечении данных и обеспечение обновления всех копий зачастую оказывается тяжелой задачей для пользователей.
Репликация (тиражирование) данных означает, что система поддерживает несколько одинаковых копий реляционной таблицы R, каждая из которых хранится в своем узле. Обычно тиражирование применяется с целью повышения доступности данных: когда одна копия недоступна из-за отказа узла, необходима возможность обратиться к другой копии. Репликации (тиражирование) могут также повысить рабочие характеристики системы при обычных условиях, поскольку транзакция с большей вероятностью обнаружит данные в локальном узле. Издержкой является необходимость дополнительного объема памяти и поддержания согласованности данных разных копий. Обновление локальной копии происходит с дополнительной задержкой, связанной с необходимостью обновлять остальные копии. Формально говоря, преимущества тиражирования таковы:
если в одном из узлов, имеющих таблицу R, возникает отказ, таблицу можно извлечь из другого узла, и система может продолжать любой процесс, в котором участвует R. Таким образом, повышается надежность хранения данных;
если большинство обращений к R требует только чтения таблицы, то несколько узлов могут обрабатывать запросы, затрагивающие R, параллельно. Чем больше копий R в сети, тем выше вероятность того, что запрос может работать без передачи данных из других узлов. Это снижает затраты и время выполнения.
Принципиальный недостаток состоит в том, что система должна обеспечивать идентичность всех копий R. Таким образом, когда происходит обновление R, это обновление должно распространяться на все копии; соответственно, растет задержка. Для баз данных с тиражированными данными возможно, как минимум, два варианта реализации. В одном из них поддерживается централизованная база данных, а копии частей базы данных выделяются для локального использования. Такая избыточность может оправдываться уменьшением затрат на передачу данных, хранящихся локально. Надежность также повышается, так как данные, потерянные в одном узле, могут быть восстановлены при помощи данных другого узла.
Исходя из практического опыта ОАО «Уралсвязьинформ», реплицированные базы данных должны использоваться в соответствии принципами, которые получены из результатов главы 3:
1. Данные должны храниться как можно ближе к местам их использования. Если фрагмент применяется в нескольких узлах, может оказаться целесообразным разместить в этих узлах его копии;
2. Для повышения надежности данных, т.е. уменьшения риска утраты данные должны быть реплицированы;
3. Следует учитывать доступность и стоимость устройств хранения данных, имеющихся в каждом из узлов системы. Рекомендуется использовать более дешевые устройства массовой памяти. Этот принцип должен быть согласован с первым;
4. Следует минимизировать стоимость выполнения в системе удаленных запросов. Затраты на выборку будут минимальны при обеспечении максимальной локализации данных, т.е. тогда, когда каждый узел будет иметь собственную копию необходимых ему данных. Однако при обновлении копируемых данных внесенные изменения потребуется распространить на все узлы, имеющие копию обновления, что увеличит затраты на передачу данных.
Первый принцип построения баз данных является ключевым, т.к. правильное выделение локальных копий повлияет на общую производительность системы технического учета и определит требования к каналам (т.е. их стоимость), соединяющим распределенные базы данных. В этом параграфе опишем способ распределения локальных файлов, взятый из работы [80] и соответствующий математическим моделям глав 2 и 3. Целевая функция этого метода — функция максимизации локального доступа при условии ограничений памяти. Это реалистичная постановка вопроса, так как помещение дополнительной таблицы в узел не приводит к значительным издержкам до тех пор, пока имеется свободный объем памяти. С другой стороны, расширение объема памяти считается задачей, выходящей за рамки сиюминутных вопросов. Увеличение объема памяти может, однако, потребоваться при расширении OSS/BSS в перспективе. Это не влияет на наши побуждения и анализ.
