Интеграция разнородного оборудования, содержащего свои локальные базы данных, в единую вычислительную сеть привела к необходимости решения задачи поддержки логической целостности данных, распределенных в сети такого рода. В статье содержится описание механизма асинхронного тиражирования данных для поддержки целостности распределенной гетерогенной базы данных, а также ряд практических рекомендаций по интеграции разнородного оборудования в единую вычислительную сеть.
1. Введение
В настоящее время существует множество СУБД, например Ingres, Sybase, Oracle, Informix и др. [1, 6, 11-14], обеспечивающих поддержку логической целостности распределенной базы данных.
Как правило, выделяют два различных механизма поддержки целостности распределенной базы данных, а именно двухфазная фиксация транзакции и асинхронное тиражирование данных [1, 6, 11, 14, 15]. Вышеупомянутые СУБД можно использовать без расширений, если оборудование, являющееся узлами сети, поддержано производителями СУБД. Будем называть такое оборудование поддерживаемым.
На практике часто возникает необходимость использования специального оборудования, например телефонных коммутаторов [4], которые, с одной стороны, являются неотъемлемым компонентом сети, а с другой стороны - не поддержаны производителями СУБД. Возникает необходимость разработки компонента программного обеспечения (СУБД), совместимого с поставляемыми СУБД и позволяющего в то же время интегрировать специальное оборудование вместе с поддерживаемым в единую сеть.
В данной работе предлагается один из возможных подходов к реализации механизма поддержки логической целостности распределенной базы данных, физически хранимой на поддерживаемом и специализированном оборудовании одновременно. Будем называть такую базу данных гетерогенной распределенной базой данных.
Опыт реализации системы управления гетерогенной распределенной базой данных показал, что специализированное оборудование может быть интегрировано в сеть только с использованием дополнительного оборудования, а именно: каждый узел сети со специализированным оборудованием должен представлять собой аппаратный комплекс, состоящий из специализированного оборудования, которое содержит локальную базу данных, и компьютера, который обладает возможностью изменения информации в базе данных специализированного оборудования и, кроме того, содержит интерфейс, обеспечивающий связь данного комплекса с другими узлами сети. Реализованный таким образом узел будем называть активной парой. В качестве примера активной пары можно привести следующую архитектуру: Unix-сервер и коммутатор [4], связанные через последовательные порты ввода/вывода. Напомним, что поддерживаемые узлы состоят из одного сервера. Таким образом, узел может быть реализован либо как активная пара, либо как сервер.
2. Специализированное/поддерживаемое оборудование
Как уже было отмечено выше, оборудование, являющееся узлами сети, может быть поддержано производителями СУБД. В качестве примера приведем традиционный Unix-сервер, на котором установлена СУБД CA-OpenIngres.
Представим теперь, что этот сервер считывает данные, например из последовательного порта ввода/вывода, которые поступают в этот порт с какого-то датчика. В этом случае датчик выступает в роли источника информации, которая, например, должна быть использована в ряде физически удаленных от этого датчика мест в целях принятия решений.
Достаточно очевидно, что датчик является неотъемлемым компонентом сети, а средства интеграции его в эту сеть не реализованы разработчиками упоминавшихся ранее СУБД [1, 6, 11-14]. Отсутствие уже реализованных средств может быть объяснено достаточно узкой областью применения датчиков в коммерческих системах, а также широкой номенклатурой такого рода оборудования. Датчик - наиболее простой пример специализированного оборудования. Пример существенно более сложного оборудования - телефонный коммутатор [4].
В телефонной сети коммутатор является, пожалуй, самым сложным и наиболее важным компонентом. Он выполняет основные функции по маршрутизации телефонных звонков. Телефонный коммутатор сам по себе является специализированным компьютером, имеющим свою собственную операционную систему, СУБД и специальный язык - интерфейс между коммутатором и пользователем. СУБД, которая находится на коммутаторе, содержит информацию, в частности, о полномочиях доступа абонентов телефонной сети к ресурсам коммутатора, например, информацию о том, может ли абонент с заданным номером телефона выполнять международные звонки, может ли он воспользоваться конференц-связью, т.е. таким режимом, при котором абонент, звонящий из Москвы, может одновременно разговаривать с абонентами, один из которых физически находится в Вашингтоне, а другой в Торонто.
Информация, содержащаяся в базе данных телефонного коммутатора, используется коммутатором в режиме реального времени. Жесткие ограничения на время доступа к информации накладывают особые требования на применяемое аппаратное и программное обеспечение, т.к. коммутатор должен иметь возможность определить полномочия доступа абонента к ресурсам коммутатора в то время, когда тот выполняет набор номера на своем телефонном аппарате. Упомянутые выше ограничения приводят к тому, что в качестве СУБД на такого рода оборудовании используется уникальное программное обеспечение, которое нигде больше не применяется.
Информация, необходимая коммутатору для определения прав доступа, заносится в его базу данных операторами коммутатора.
Если основная задача коммутатора состоит в маршрутизации звонков, то основной задачей компании, эксплуатирующей этот коммутатор, является определение прав доступа абонентов к ресурсам коммутатора, регистрация соответствующей информации в базе данных коммутатора и, безусловно, начисление платы за предоставленные услуги.
Для расчета платы, которую необходимо начислить абоненту, используются специализированные бухгалтерские системы, которые содержат свои собственные базы данных. Принципиально, эта плата может быть начислена корректно только в том случае, если информация, хранимая в базе данных бухгалтерской системы, синхронизирована с информацией, содержащейся в базе данных коммутатора.
Предположим, что существует возможность изменения как программного, так и аппаратного обеспечения коммутатора, для того чтобы, в конечном счете, предоставить заданный уровень синхронизации в состоянии всех баз данных. Такая модификация коммутатора будет фактически означать выполнение вертикального масштабирования коммутатора.
Выполнение вертикального масштабирования любого оборудования оправдано только в том случае, если такого рода модификация повлечет за собой улучшение функциональных характеристик используемого комплекса. Если используемая бухгалтерская система является уникальной, то такая доработка будет уникальной для данной компании, которая эксплуатирует этот коммутатор. Даже если подобная доработка принципиально возможна, то она приведет к резкому возрастанию эксплуатационных расходов на использование коммутатора, т.к. техническая поддержка будет осуществляться для одного коммутатора, а чем ниже тираж, тем выше стоимость.
Кроме вертикального масштабирования также можно выполнить и горизонтальное масштабирование. В этом случае не придется выполнять какие бы то ни было модификации коммутатора, т.е. стоимость его эксплуатации не изменится, а надо будет использовать дополнительный компьютер, обладающий, с одной стороны, интерфейсом к коммутатору, а с другой - к базе данных бухгалтерской системы. Необходимо отметить, что вне зависимости от того, какое программное обеспечение предполагается применять на вспомогательном компьютере, придется разрабатывать программы, осуществляющие обмен данными со специализированным оборудованием. Особенности функционирования такого рода системы будут рассмотрены ниже.
3. Способы поддержки целостности распределенной базы данных
Рассмотрим упомянутые ранее способы поддержки целостности распределенной базы данных.
Механизм двухфазной фиксации транзакции состоит в последовательном прохождении базы данных в процессе выполнения транзакции через два этапа. Первый этап (первая фаза) - выполнение синхронизированного захвата всех объектов данных, к которым имело место обращение от имени транзакции. Объекты данных захватываются на всех серверах. На втором этапе (во второй фазе) либо происходят все изменения на всех серверах, либо, в случае хотя бы одной ошибки, происходит откат к состоянию, в котором находилась база данных до выполнения первого этапа [1].
Механизм двухфазной фиксации транзакции содержит ряд недостатков: захват всех необходимых данных на всех серверах может надолго заблокировать доступ к данным; кроме того, использование в структуре сети координирующего узла связано с дополнительной "опасностью", поскольку выход его из строя приведет к блокировке данных, затронутых транзакцией, до тех пор, пока он не будет восстановлен.
Суть механизма асинхронного тиражирования данных состоит в том, что обработка данных выполняется локально, а распределенные данные копируются на тот сервер, где они должны использоваться. При таком методе поддержки логической целостности распределенной базы данных имеет место некоторая рассинхронизация состояния локальных баз данных во времени, т.е. изменение состояния одной локальной базы данных отстает от изменения другой локальной базы данных во времени.
Асинхронность обмена данными в целом ряде случаев вполне допустима, и при этом удается обойти, в частности, проблему ограниченной пропускной способности глобальной сети. Если один из серверов системы, требующих обновления тиражируемых данных, выходит из строя, то система продолжает работать с остальными, при этом обновление данных на сервере после его ремонта произойдет автоматически, т.е. ошибка на одном узле глобальной сети не повлияет на работу остальных узлов.
Опыт реализации прикладной системы, работающей в аппаратной среде коммутируемых телефонных линий связи, показал, что механизм асинхронного тиражирования данных предпочтительнее, поскольку подобного рода линии связи обладают невысокой надежностью и при значительном их числе механизм двухфазной фиксации транзакции практически не реализуем, т.к. все оборудование одновременно в работоспособном состоянии почти никогда не находится.
4. Механизм асинхронного тиражирования данных
В настоящей работе рассматривается один из возможных алгоритмов реализации механизма асинхронного тиражирования данных в тех случаях, когда нельзя использовать средства, описанные и уже реализованные, например в таких программных продуктах, как Sybase System 10 или OpenIngres/Replicator. В основном такие проблемы возникают, когда одним (или более) узлом сети является активная пара, в состав которой входит специализированное оборудование.
В такой постановке задачи использование вышеперечисленных средств может быть нецелесообразно, т.к. стоимость оборудования для эффективного применения этих механизмов, а также стоимость различных лицензий на программное обеспечение может оказаться выше, чем в предлагаемом решении.
4.1. Терминология
В настоящей работе под термином элементарная операция над объектом понимается такая программная функция, которая обладает следующими свойствами.
1. Объект может находиться в одном из двух состояний:
а) до начала выполнения элементарной операции;
b) после завершения выполнения элементарной операции.
2. Если операция не завершена, то объект, над которым выполнялась операция, вне зависимости от того, были ли предыдущие незавершенные попытки выполнить операцию или нет, перейдет в состояние b после выполнения операции.
Примером элементарной операции являются операции переименования файла или блокировки на запись всего файла. Файл не может быть переименован наполовину. Он имеет либо старое имя, либо новое. При этом результат не зависит от того, в который раз выполняется эта операция.
Элементарные операции, в свою очередь, могут быть компонентами элементарных операций более высокого уровня. В настоящей работе не делается акцент на уровень элементарной операции, т.к. это несущественно с точки зрения решаемой задачи.
Под базой данных источника будем понимать локальную базу данных, расположенную на одном из узлов вычислительной сети, и такую, что после внесения в эту базу данных некоторых изменений возникает необходимость отразить эти изменения на оставшихся (всех или не всех) узлах.
Под базой данных приемника будем понимать локальную базу данных, расположенную на одном из узлов вычислительной сети, такую, что после внесения в базу данных источника каких-либо изменений возникает необходимость произвести соответствующие изменения в базе данных этого узла.
Далее мы будем называть источником узел, содержащий базу данных источника, а приемником - узел, содержащий базу данных приемника.
В терминологии архитектуры клиент-сервер [2] в качестве клиента будет выступать источник, а в качестве сервера - приемник.
Единичным циклом тиражирования будем называть всю технологическую последовательность, которую проходят источник и приемник с момента возникновения необходимости произвести изменение данных в приемнике и до выполнения этих изменений.
Приемник и источник, как, впрочем, сервер и клиент, могут меняться ролями, но при выполнении единичного цикла тиражирования базы данных приемник и источник не меняются ролями.
4.2. Общие вопросы тиражирования
При построении системы асинхронного тиражирования данных необходимо решить ряд вопросов, таких как "что тиражировать", "когда тиражировать" и "куда тиражировать" [11].
Для обеспечения совместной работы нескольких узлов тиражировать необходимо информацию, содержащую конечную цель единичного цикла тиражирования, и информацию, относящуюся к этому циклу, которая доступна в источнике. Представление данных унифицировано [5] для всех активных пар. При выборе формата представления данных необходимо учитывать специфику языков модификации данных в различных узлах. В терминологии СУБД конечная цель единичного цикла тиражирования является целью выполнения единичной транзакции над базой данных.
Поскольку настоящая работа посвящена механизму асинхронного тиражирования данных, то вопрос "когда тиражировать" в данном случае имеет достаточно простой ответ: по достижению определенного момента времени. Этот момент времени может быть задан администратором базы данных на основании эмпирических наблюдений за системой. Время выполнения очередных циклов тиражирования выбирается, исходя из частоты возникновения необходимости выполнить единичный цикл тиражирования, ограничения на допустимое время рассинхронизации состояний источника и приемника, объема данных, передаваемых в единичном цикле тиражирования, и максимально допустимой загрузки коммуникационных ресурсов, а также на основании прочей имеющейся информации.
4.3. Надежность механизма
В настоящее время существует несколько определений понятия надежности. В частности, под надежностью программного продукта понимается вероятность того, что этот продукт будет работать согласно документации [16]. Так, например, если операционная система вместо операции копирования файла будет выполнять его переименование, и это в явном виде описано в документации, то операционная система будет надежна (т.к. она абсолютно предсказуема), но некорректна.
В настоящей работе под термином надежность механизма асинхронного тиражирования понимается вероятность того, что единичный цикл тиражирования выполнится за конечное время при условии, что среда передачи данных будет находиться в работоспособном состоянии в течение времени, необходимого для выполнения этого цикла, вне зависимости от того, в каком состоянии находилась до этого среда передачи данных.
При реализации механизма асинхронного тиражирования данных автору настоящей работы пришлось столкнуться с проблемой обеспечения его надежности.
Поскольку источник и приемники были связаны глобальной сетью, которая представляла собой дешевые коммутируемые телефонные линии связи, постольку вероятность возникновения ошибки при выполнении сетевой операции была достаточно велика.
При реализации механизма программное обеспечение как сервера-источника, так и сервера-приемника строилось по принципу реализации элементарной операции. При этом элементарной операцией наивысшего порядка являлась операция, реализующая единичный цикл тиражирования.
До того как описывать схему механизма тиражирования данных, необходимо упомянуть те программные средства, которые были использованы. Как сервер, содержащий базу данных источника, так и сервер, управляющий базой данных приемника, работали под управлением операционной системы SCO Unix System V/386 Release 3.2v4.2 для IBM/AT [9, 10], в качестве СУБД использовалась Ingres, а для реализации транспортного уровня применялся следующий стек протоколов - PPP - TCP/IP - RCMD (RCP) [3, 7, 8].
4.4. Представление данных единичного цикла тиражирования
Данные для единичного цикла тиражирования представляли собой один файл, сформированный по описанным выше правилам.
В процессе прохождения элементарных операций единичного цикла тиражирования имя файла изменялось. В случае возникновения любого рода сбоя, который не приводил к разрушению файловой системы, файл сохранялся на диске. Его имя однозначно отражало последнюю выполненную элементарную операцию. Такой достаточно простой способ организации данных позволял, используя только лишь стандартные средства, поддерживаемые любой операционной системой, возобновить цикл тиражирования с прерванного места.
4.5. Передача файлов
В процессе реализации прикладной системы были рассмотрены два различных способа организации передачи данных между узлами, в зависимости от роли инициатора передачи в единичном цикле тиражирования.
Поскольку рассматривается механизм асинхронного тиражирования данных, то, вне зависимости от роли инициатора передачи данных, инициатор должен осуществлять циклический опрос либо своей локальной директории, либо парного узла. В зависимости от того, насколько стационарен процесс выполнения единичных циклов тиражирования, предпочтение в инициации процесса передачи файлов может быть отдано как источнику, так и приемнику. Поскольку в реализованной системе процесс выполнения единичных циклов тиражирования был принципиально нестационарен, то исходя из этого было достаточно очевидно, что минимизации нагрузки на сетевые ресурсы следует ожидать в том случае, когда инициатором передачи данных является источник. Однако для общности в статье рассматриваются схемы построения систем как с инициатором-источником, так и с инициатором-приемником.
4.5.1. Инициатор-источник
Процесс передачи файлов был построен в виде элементарной операции, реализуемой двумя асинхронными компонентами. Первый компонент создавал файлы, второй занимался их передачей.
Только после корректного завершения работы первого компонента второму становились доступны файлы, созданные первым. Второй компонент, в свою очередь, был построен таким образом, что файлы, передаваемые им в приемник, становились логически доступны последнему только в случае корректного перемещения файлов из источника в приемник.
4.5.2. Инициатор-приемник
Несмотря на то что минимизации нагрузки на сетевые ресурсы следует ожидать в том случае, когда инициатором единичного цикла тиражирования является источник, в некоторых случаях бывает целесообразно использовать приемник в качестве инициатора. Такие случаи возникают, если периодичность потребности выполнить единичный цикл тиражирования может быть определена достаточно точно, т.е. процесс занесения данных в источник является стационарным. Ни в каком другом случае использование приемника в качестве инициатора не является оправданным.
Если можно определить моменты времени, в которые необходимо выполнять пересылку данных, то при той же нагрузке на сетевые ресурсы, как и в случае с инициатором-источником (т.к. холостой опрос будет практически отсутствовать), администратор приемника получает дополнительную возможность выявления проблем, связанных с сетевыми ресурсами, а также с функционированием источника. Процесс занесения данных в источник может быть стационарным, например, в следующем случае: источником является активная пара, одним из компонентов которой является специализированный компьютер, который считывает показания датчиков в строго определенные моменты времени. В этом случае отсутствие данных может идентифицировать, в частности, выход датчика из строя.
Безусловно, процесс передачи файлов, как и в предыдущем случае, необходимо строить в виде элементарной операции и реализовать его следует точно так же в виде двух асинхронных компонентов. Отличие же состоит в том, что первый компонент, который работает в источнике, создает файлы, а второй, т.е. процесс, работающий в приемнике, занимается их передачей.
При выборе узла, который должен стать инициатором единичного цикла тиражирования, основное внимание необходимо уделять стационарности обновления базы данных источника. Как уже было отмечено выше, в силу того, что в реализованной системе процесс обновления базы данных источника был по своей природе нестационарен, инициатором был выбран источник.
4.6. Рассинхронизация и потеря производительности
Ниже приводятся некоторые количественные характеристики для системы класса менеджера распределенной базы данных, реализованной в соответствии с описанной выше моделью. Система содержала два узла, один из которых был традиционным Unix-сервером, а второй - активной парой, в состав которой входил вспомогательный Unix-сервер и телефонный коммутатор [4].
При реализации системы с инициатором-приемником циклический опрос удаленного компьютера инициировался каждые 2 минуты. При этом общая производительность программно-аппаратного комплекса сервера базы данных источника снижалась не более чем на 2 процента.
Транзакция состояла в выполнении двух циклов тиражирования: одного с источником в виде Unix-сервера, а другого с источником в виде активной пары. Поскольку обмен с коммутатором не превышал 1 минуты, то максимальное время рассинхронизации ограничивалось 5 минутами.
Максимальные задержки времени выполнения единичного цикла тиражирования возникали при обмене данными между узлами.
При построении системы с инициатором-источником циклический опрос локальной директории инициировался каждые 20 секунд. При этом общая производительность программно-аппаратного комплекса сервера базы данных источника снижалась не более чем на 2 процента, т.к. в основном это был "холостой" опрос.
Время обмена с коммутатором не превышало 1 минуты, как и в приведенных ранее цифрах, т.к. эта операция абсолютно инвариантна схеме организации передачи файлов.
При реализации менеджера распределенной базы данных автору, при сохранении нагрузки на операционную систему, удалось сократить максимальное время рассинхронизации более чем в 2 раза при использовании схемы с инициатором-источником, по сравнению со схемой с инициатором-приемником. Кроме того, относительно небольшое количество транзакций, затрагивающих распределенную базу данных (не более 25 в день), позволило снизить нагрузку на сетевые ресурсы более чем в 50 раз.
Из сказанного выше следует, что максимальное время рассинхронизации ограничивалось 2 минутами, причем максимальные задержки времени выполнения единичного цикла тиражирования возникали при обмене данными между вспомогательным Unix-сервером и коммутатором.
5. Заключение
Вопросы, связанные с поддержкой логической целостности распределенных баз данных, возникли очень давно. Более 20 лет назад магнитные ленты использовались для передачи данных из одного офиса в другой, и тем самым, фактически, решались задачи обеспечения логической целостности распределенной базы данных. Время рассинхронизации могло составлять несколько дней, но это вполне устраивало пользователей. С развитием различных технологий требования к системам накладывали все более жесткие ограничения на максимально допустимое время рассинхронизации, а также на надежность механизмов обеспечения целостности данных. Реализовано немало коммерческих продуктов [1, 6, 11, 14, 15], которые специально ориентированы на поддержку логической целостности распределенных баз данных. Казалось бы, что все проблемы решены, но это далеко не так.
Использование уже реализованных средств может быть затруднено, а иногда и совсем невозможно, если хотя бы одна локальная база данных, которая входит в состав распределенной базы данных, расположена на специализированном оборудовании, особенности которого обсуждались выше. Разработанная технология, которая описана в данной статье, позволяет интегрировать в единую вычислительную сеть разнообразное оборудование и обеспечить логическую целостность данных, распределенных в такой сети.
Литература
- Alex Moissis. SYBASE ReplicationServer. A Practical Architecture for Distributing and Sharing Corporate Information. - SYBASE Corp.
- Douglas E. Comer, David L. Stevens. Internetworking with TCP/IP, Volume III. - Prentice-Hall, 1993.
- Richard Stevens. UNIX Network Programming. - Prentice-Hall, 1990.
- EMX OPERATIONS MANUAL, Man/Machine Interface and Subscriber management, Book 1. - Motorola, Inc., 1992.
- Ross D.T., Goodenough J.B.,Irvine C.A. Software engineering: process, principles and goals. - Computer, 1975, v. 8, #5, pp. 17-27.
- Ладыженский Г.М., Барон Г.Г. Ingres - современные тенденции в архитектуре сервера базы данных. - Открытые системы, осень 1993.
- Clark D.D., Jacobson V., Romkey J.L., Salwen H. An Analysis of TCP Processing Overhead. - IEEE Communications Magazine, vol. 27, no. 6, pp. 23-29, June 1989.
- Richard Stevens. Advanced Programming in the UNIX Environment. - Addison-Wesley Publishing Company, 1993.
- SCO Open Desctop/Open Server System Administrator"s Reference. - The Santa Cruz Operation, Inc., 1993.
- SCO Open Desctop/Open Server Network Programmer"s Guide and Reference. - The Santa Cruz Operation, Inc., 1993.
- Ленгрен Е. Автоматическая репликация данных. Открытые системы сегодня, # 12, 2 сентября 1994.
- Date C. J. A guide to INGRES. - Addison-Wesley, 1989.
- Марк Ривкин. Распределенные системы обработки данных на основе СУБД Oracle. - DBMS/Russian Edition, май 1995.
- Барон Г.Г., Ладыженский Г.М. Технология тиражирования данных в распределенных системах. - Открытые системы, весна 1994.
- Ладыженский Г.М. CA-OpenIngres как Открытая система. - СУБД # 1, 1995.
- Майерс Г. Надежность программного обеспечения. - М.: Мир, 1980, стр. 9-20.