Система репликации на основе базы данных Berkeley
Введение
В 1998 г. в ОАО "ИНЭУМ" была завершена разработка и начата поставка управляющего вычислительного комплекса СМ 1820М. Характерными особенностями семейства средств СМ1820М являются:
- архитектура, совместимая с IBM PC на всех уровнях иерархии;
- интерфейс CompactPCI со скоростью 132/ 264 Мбит/с;
- унифицированное конструктивное исполнение плат, модулей, стоек и тумб в стандарте Евромеханика, широко распространенном в мире;
- инвариантность к номенклатуре продукции и средствами CompactPCI и системному ПО различных фирм-производителей;
- отсутствие средств вентиляции благодаря специальному исполнению конструкции, что резко повышает эксплуатационную надежность;
- полное соответствие международным стандартам открытых систем;
- использование современной отечественной и зарубежной элементной базы.
В качестве базового общесистемного ПО в СМ1820М.ВУ применяются как ОС класса Windows NT/2000, так и UNIX-подобных системы QNX и Linux. Подробно результаты разработки ПТК СМ1820М освещены в работе [1]. В настоящий момент существует проблема организации обработки и передачи данных технологического процесса. Одним из направлений работ в этой области является создание встраиваемой распределенной базы данных.
Распределенные системы
Благодаря развитию технологий сегодня достаточно легко можно собрать компьютерную систему, состоящую из множества разнообразных устройств, соединенных высокоскоростной сетью. Такую систему называются компьютерной сетью или распределенной системой. В литературе можно найти различные формальные определения распределенных систем [2]. В данной работе будет достаточно следующей характеристики:
--------------------------------------------------------------------------------
Распределенная система -- это набор независимых компьютеров, представляющийся пользователям единой системой.
--------------------------------------------------------------------------------
В этом определении оговариваются два момента. Первый относится к аппаратуре: все машины в сети автономны. Второй касается программного обеспечения: пользователь работает с единой системой.
Первая из важных характеристик распределенных систем состоит в том, что для пользователя скрыты различия между компьютерами и способы их взаимодействия в сети. Другой важной характеристикой распределенных систем является способ, при помощи которого пользователи и приложения единообразно работают, независимо от того, где и когда происходит их взаимодействие.
Распределенные системы должны также относительно легко поддаваться расширению и масштабированию. Распределенные системы обычно существуют постоянно, однако, некоторые компоненты могут временно выходить из строя, либо отключаться для профилактического обслуживания. Возможно добавления частей для обеспечения поддержки новых пользователей или приложений. Все изменения происходящие с структурой системы, должны быть незаметны для пользователя и приложений.
Основная задача распределенной системы -- облегчить пользователям доступ к удаленным ресурсам и обеспечить совместное их использование, если необходимо регулируя этот процесс. Ресурсы могут быть виртуальными -- например файлы, однако, традиционно они могут включать в себя принтеры, компьютеры, устройства хранения данных. Одно из очевидных преимуществ для совместного использования ресурсов -- экономичность. Соединение пользователей, ресурсов также облегчает кооперацию и обмен информацией.
Распределенные базы данных
Система распределенных баз данных (БД) состоит из набора узлов (sites), связанных коммуникационной сетью, в которой:
Каждый узел это автономная база данных.
Любые запросы на чтение данных обрабатываются прозрачно для пользователя.
Система поддерживает репликацию, если данные могут быть представлены несколькими отдельными копиями или репликами, которые хранятся на отдельных узлах. Репликация используется для решения двух задач. Во-первых для обеспечения высокой производительности, поскольку приложение сможет работать со своей локальной копией, вместо того, чтобы отсылать запросы к удаленными узлам. Во-вторых репликация может обеспечить высокую степень доступности данных, поскольку любая реплицируемая запись остается доступной для обработки (по крайней мере для выборки данных), пока хотя бы одна реплика в системе остается доступной. Главным недостатком репликации является то, что если реплицируемый объект обновляется, то и все его копии должны быть обновлены. В работе К. Дж. Дейта [3, 20.4] предложены решения данной проблемы.
База данных Berkeley
БД Berkeley (Berkeley DB -- www.sleepycat.com) встроенная система баз данных, которую можно использовать в приложениях, нуждающихся в высокопроизводительном механизме хранения и извлечения пар ключ-значение, поддерживающем одновременный доступ [8]. Программный продукт распространяется в виде библиотеки, которая может быть подключена к коду приложения. Функции библиотеки доступны через ряд программных интерфейсов, в том числе для языков Си, C++, Java, Perl, Python и Tcl. Berkeley DB можно подключать к коду приложения динамически или статически. Встраиваемость в данном случае означает, что база данных представляет собой программную библиотеку, которая находится в адресном пространстве пользовательской программы. Данная архитектура позволяет избежать расходов присущих приложениям использующим систему взаимодействия процессов (IPC), а также исключает необходимость в инсталляции/настройки БД и её администрирование.
Sleepycat распространяет БД Berkeley, как программный продукт с открытым кодом. Компания предусматривает лицензионные отчисления за определенные виды использования ПО, а также взимает плату за поддержку и услуги. Свободно доступно через Интернет руководство программиста и руководство пользователя. Интерфейсы к основным языкам программирования документированы. Многие дистрибутивы GNU/Linux, содержат Berkeley DB. Благодаря доступности искодных текстов, библиотеку БД можно оптимизировать для конкретной задачи на этопе компиляции.
Одним из достоинств БД Berkeley является поддержка, так называемых, ACID транзакций (Atomicity -- атомарность, Consistency -- согласованность, Isolation -- изолированность, Durability -- долговечность). Транзакция (transaction) -- это единица работы, обычно включающая несколько операций базы данных [3].
БД Berkeley предоставляет праграммисту протой и эффективный интерфейс для манипулирования данными. Возможны операции вставки, удаления, замены данных, выборка данных по ключу, выборка диапозона значений. Возможно использование вторичных ключей. Баблиотекой БД Berkeley поддерживается операция естественного объединения (natural join) на основе вторичных индексов.
В качестве основного хранилища БД используют файловую систему операционной системы (ОС), но возможно размещение данных только в оперативной памяти.
БД поддерживается четыре метода доступа к данным [8]:
B+tree;
Extended Linear Hashing (Hash);
Persistent Queues (Queue);
Fixed- or Variable-length Records (Recno);
БД Berkeley способна работать с базами данных объемом до 256 терабайт с ограничением 4 гигабайта на запись (здесь и далее ограничения указаны для версии 4.3.21). При этом объем сегмента исполняемого кода библиотеки базы данных в зависимости от конфигурации и операционной системы может быть не более 400 килобайт. Размер разделяемой памяти используемой для кэширования данных настраивается от 20 килобайт. Большинство параметров БД можно настраивать во время работы приложения через простые интерфесы.
Библиотека БД Berkeley поддерживает возможность многопользовательского доступа к базам данных. Ее можно подключить к коду автономных приложений, к набору совместно работающих приложений или к серверам, обрабатывающим клиентские запросы и выполняющим в соответствии с ними операции над базами данных.
Важно понимать, чем БД Berkeley не является. Berkeley не сервер баз данных, обрабатывающий запросы, поступающие по сети. Это также не SQL-ядро, выполняющее запросы. Не является Berkeley DB и реляционной или объектно-ориентированной СУБД.
Все перечисленные системы можно построить поверх БД Berkeley, которая сама по себе является всего лишь встраиваемым механизмом баз данных. Разработчики преследовали цель сделать его переносимым, компактным, быстрым и надежным. Далее в таблице приведено сравнение особенностей реляционных БД и Berkeley.
| БД Berkeley | Реляционные БД | |
| архитектуры клиент/сервер | ||
| Архитектура | Встраивается в | Отдельное |
| приложение | приложение сервер | |
| Методы доступа | Быстрые локальные | Дорогостоящие |
| к данным | вызовы функций | операции передачи |
| запросов между | ||
| приложениями | ||
| Администрирование | Не требуется | Требуется участие |
| администратора | ||
| баз данных | ||
| Масштабируемость | Терабайты данных, | Терабайты данных, |
| доступ к данным | доступ к данным | |
| тысячи пользователей | тысячи пользователей | |
| одновременно | одновременно | |
| Настраиваемость | Неиспользуемые подсистемы | Как правило, сложная |
| можно отключить | система настроек |
Система репликации базы данных Berkeley
Определение
БД Berkeley предоставляет прикладному программисту средства для создания приложений высокой доступности (Highly Available applications) на основе репликации данных.
Высокая доступность (High Availability) подразумевает решение, способное продолжать функционировать либо восстанавливать функционирование после возникновения большинства ошибок без вмешательства оператора. Отличие высокодоступных систем от систем устойчивых к сбоям (Fault Tolerant) заключается в том, что высокодоступные решения могут иметь одно или несколько отличий от систем устойчивых к сбоям:
- процесс восстановления после обнаружения неисправности может занять некоторое время, вместо того, чтобы произойти немедленно;
- некоторые компоненты, вероятность выхода из строя которых маловероятна, могут быть не продублированы;
- характеристики системы после окончания процесса восстановления могут ухудшаться;
Группа репликации БД Berkeley состоит из независимо сконфигурированных приложений. В группе репликации может быть одно приложение мастер и несколько клиентских приложений. Приложение мастер (далее в тексте мастер) поддерживает запись и чтение базы данных; клиентские приложения (далее в тексте клиенты) могут осуществлять только чтение базы данных. При выходе из строя мастера, клиент может стать мастером, при определенных ограничениях. Приложения входящие в группу репликации могут находиться как на разных узлах сети, так и на одном сервере. Единственным ограничением для размещения приложений -- на всех распределенных узлах должен быть одинаковый порядок байт (endianness) центральных процессорных устройств. Ожидается, что это ограничение будет снято в следующих версиях базы данных Berkeley. Любое приложение, участник группы репликации, может содержать любое число, ограниченное системными настройками, независимых параллельных задач (процессов или потоков) работающих конкурентно с средой базы данных. Любое число задач, входящих в состав мастера может производить операции чтения и записи данных. Любое число задач, входящих в состав клиентского приложения может запрашивать данные из базы данных.
Приложение может быть создано с учетом различных требований к непротиворечивости данных. Приложение может работать в синхронном режиме, это означает что реплики (локальные копии) базы данных гарантированно будут находиться в полном соответствии с последними изменениями данных подтвержденными транзакциями. При использовании такой модели непротиворечивости следует ожидать низкую производительность распределенного приложения. Для повышения производительности можно пожертвовать синхронным режимом и позволить клиентской части базы данных обновляться через заданные приложением интервалы времени.
База данных Berkeley предоставляет необходимую инфраструктуру для создания среды репликации, но приложение должно обеспечить работу следующих важных компонентов:
- Приложение должно предоставить коммуникационную инфраструктуру. Приложение может использовать любой способ обмена данными (например -- RPC, TCP/IP, системные очереди сообщений или почтовые голуби).
- Приложение отвечает за однозначное именование всех участников группы репликации. В системе репликации для однозначного определения участника группы используется уникальный номер (ID) и приложение должно по ID однозначно определять канал коммуникации с другими участниками.
- Приложение отвечает за мониторинг статуса мастер и клиентов, и обнаружение недоступного или вышедшего из строя участника группы.
- Приложение, если требуется, может предоставить средства защиты данных. Например приложение может шифровать записи в базе данных или использовать зашифрованный коммуникационный канал. Уровень зашиты данных целиком определяется потребностями приложения.
Идентификатор участника репликации
Каждый участник группы репликации должен иметь уникальные номера для идентификации себя и других участников группы. Номер может не быть "глобальным" для всей группы. Например если есть три узла в группе репликации -- А, Б и В, то участник А может присвоить номера 1 и 2 узлам Б и В соответственно, в то время как узел Б может присвоить номера 301 и 302 узлам А и В.
Приоритеты
Каждый участник группы репликации должен иметь приоритет. Приоритет учитывается при определении участника группы репликации, который станет новым мастером, в случае если произойдет сбой в работе существующего мастера и он перестанет функционировать. Приоритет может быть задан любым положительным целым число. В группе репликации могут присутствовать участники с одинаковым приоритетом. Участник группы с нулевым приоритетом не может быть выбран мастером. Мастер выбирается на основание сравнения журнала транзакций. Клиент, содержащий самые последнии обновления становится мастером. Если таких клиентов несколько, тогда сравниваются их приоритеты и тот из них, чей приоритет выше становится мастером. Если приоритеты также совпадают, выбор мастера среди этих клиентов происходит случайным образом.
Выборы мастера
Приложение определяет когда нужно начать выборы мастера. Участник группы может начать выбор мастера в любой момент времени. Клиент должен начать выборы, когда мастер группы ему неизвестен или когда была обнаружена поломка мастера.
Клиент может выиграть выборы если в группе репликации нет мастера и журнал транзакций клиента содержит самые свежие записи. В случае, когда журналы транзакций нескольких клиентов эквивалентны, для выбора используются приоритеты. Клиент ставший мастером должен выполнить все необходимые действия для перехода в новый режим работы.
Приложение должно указывать при проведении выборов, какое минимальное число участников группы репликации необходимо для того, чтобы был определен победитель. Инженеры Berkley рекомендуют использовать формулу , где - число узлов в группе. Если заданное число меньше простого большинства, то участник группы репликации, который начал выборы, получает предупреждение.
Выборы мастера проводяться прозрачно для приложения, но используя механизм приоритетов можно ограничить круг возможных победителей явно указав клиентов из числа которых может быть выбран новый мастер.
Пример реализация системы репликации
В рамках работы проводимой автором в ИНЭУМе (Институт Электронных Управляющих Машин), было спроектировано и реализовано приложение с поддержкой репликации данных. БД используется для хранения хронологической и оперативной информации о состоянии дискретных и аналоговых входов. Приложение предназначено для получение аналоговых и дискретных значений от модулей производства ИНЭУМа и распределения полученных данных в группе репликации. В качества ядра приложения используется БД Berkeley. Инициатором обновлений реплик является мастер группы репликации БД. Мастер последовательно считывает значения с модуля и если обнаруживает изменение контролируемых параметров, записывает в базу данных новые значения. Система репликации БД производит распределение новых данных на все узлы в группе. Клиент имеет возможность получить сообщение о том, что его локальная реплика была обновлена и обработать новые данные.
Библиотека методов доступа к БД встроена в приложение и, как следствие, нет необходимости в сложных настройках и последующем обслуживании сервера БД. Для использования во встраиваемых системах важны такие свойства БД Berkeley, как высокая скорость доступа к данным и нетребовательность к системным ресурсам. Конкурентный доступ к данным нескольких процессов (задач опроса модулей УСО) обеспечивается средствами БД Berkeley. Модульная структура ПО позволяет легко производить модификации в зависимости от типа задачи. Опрос модулей производится несколькими параллельными задачами.
Для приложения не существует ограничения на число групп репликации. Например, физический узел в сети может являться клиентом в одной группе и одновременно мастером другой группы. Каждое приложение входящие в группу репликации может работать в режиме мастера или клиента. Переключение из режима клиента в режим мастера может произойти при соблюдение условий описанных выше ( см. 4.4). Способы переключений приложения из режима мастера описан в [5].
Существуют несколько вариантов считывания контролируемых параметров:
- Приложение работающее в режиме мастера может считывать данные через последовательные порты ввода/вывода. Получение данных может производиться параллельно несколькими задачами. В приложение встроена поддержка интерфейса RS-485.
- Приложение мастер может выполняться на промышленном контроллере и читать данные непосредственно с модулей расположенных локально [7].
Коммуникационная инфраструктура приложения реализована поверх TCP (Transmission Control Protocol) сокетов. Приходящие запросы приложение обрабатывает последовательно в одной задаче с использованием системного механизма мультиплексирования ввода, предоставляемого функцией select [4]. Одна задача предназначена для выполнения административных функций: предотвращение взаимных блокировок транзакций (deadlocks) и фиксация текущего состояния журнала транзакций -- прохождение так называемых контрольных точек (checkpoints) [5].
Приложение может работать под управлением следующих операционных систем:
- GNU/Linux. Распространяемый Фондом Свободного Програмного Обеспечения набор системных и прикладных инструментов с ядром Linux [6]. Существует адаптированный вариант приложения для PC совместимых промышленных контроллеров. Приложение может работать в режимах мастера и клиента. Для подтверждения своего работоспособного состояния мастер:
- посылает "пульсы" клиентским узлам. Если клиент не получает "пульс" от мастера в течении определенного интервала времени он начинает проведение выборов в группе.
- синхронизирует свое выполнение с сторожевым таймером. Возможно использование программного сторожевого таймера.
- MS Windows 2000/NT. Приложение может работать в режиме клиента. Предусмотрена интеграция с программными продуктами класса SCADA/HMI, например SIEMENS Simatic WinCC.
Литература.
- Шкамарда А.Н., Бабанов И.И., Гревцев В.В., Глухов В.И., Каневский В.Г., Нифонтов Ю.В., Страшун Ю.П. Комплексы технических средств СМ 1820М// Автоматизация в промышленности. 2003. 10.
- Тененбаум Э. М. ван Стеен. Распределенные системы. Принципы и парадигмы. - С.Пб. Питер. 2003.
- К. Дж. Дейт. Введение в системы баз данных, 7-е издание. - М. Издательский дом "Вильямс". 2001.
- У. Стивенс. UNIX: Разработка сетевых приложений. - С.Пб. Питер. 2003
- Berkeley DB Programmer's Tutorial and Reference Guide . v. 4.3.21. www.sleepycat.com.
- Карев А.А. Использование ОС Linux в управлении промышленными объектами// Автоматизация и современные технологии. 2003. 9.
- Карев А.А. Использование Web-технологий во встраиваемых приложениях// Автоматизация в промышленности. 2004. 2.
- Олсон М., Бостик К., Зельтцер М. Berkeley DB//Открытые системы. www.osp.ru. 2000. 11.
Система репликации на основе базы данных BerkeleyПриводится краткое описание базы данных Berkeley. Основная часть посвящена подсистеме репликации данных. Дается определение распределенных систем, распределенных баз данных. Перечислены отличия распределенных баз данных от централизованных и проблемы реализации распределенных баз данных. Дается описание репликации данных. Предлагается использование базы данных Berkeley для решения задач репликации в гетерогенных мультикомпьютерных системах.