Построение отказоустойчивых узлов доступа к данным ДЗЗ в системах мониторинга

В настоящее время в ИКИ РАН создано и эксплуатируется большое количество информационных сервисов, обеспечивающих работу с данными ДЗЗ. Сервисы обеспечивают данными не только проведение научных исследований различными коллективами и институтами, но и решение достаточно критичных прикладных задач на регулярной основе, таких как мониторинг пожаров и угроз, возникающих от них, мониторинг пепловых выбросов вулканов и другие. Отказы в работоспособности сервисов, включая работу процессов пополнения данных, при решении таких задач могут привести к негативным последствиям. Поэтому, задача обеспечения отказоустойчивости разрабатываемых сервисов является в настоящее время одной из приоритетных при разработке конкретных систем спутникового мониторинга.

Рисунок 3.2.3.1 — Схема традиционной информационной системы предоставления данных.

Традиционно ИС, предоставляющие пользователям доступ к данным ДЗЗ, состоят из двух основных компонент (см. рисунок 3.2.3.1.): web-сервера с расположенными на нём интерфейсами, а также сервера хранения данных (СХД) с находящейся на нём СУБД. Несмотря на то, что некоторые сбои могут быть исправлены в течение относительно непродолжительного промежутка времени при отказе любой из компонент системы пользователь какое-то время не сможет получить доступ к интересующим его актуальным данным ДЗЗ, что крайне нежелательно для многих систем оперативного мониторинга.

Основными и наиболее часто встречающимися нештатными ситуациями на вычислительных узлах, поддерживающих работоспособность сервисов доступа к данным ДЗЗ, приводящими к отказам при работе являются:

• выход из строя любого из серверов ИС;
• сбои в работе БД, например, ошибки доступа или даже потеря части данных;
• ошибки при запросах к интерфейсам предоставления данных;
• перегрузка БД или web-сервера запросами.

Для предотвращения наступления большинства из указанного списка ситуаций подходит дублирование узлов и/или входящих в эти узлы компонент, чтобы выход из строя одного из них не влиял на работу системы в целом. Для этого была разработана схема построения отказоустойчивой системы, в которой несколько узлов предоставления данных связываются по сети при помощи специального web-сервера Nginx. Этот сервер контролирует доступность узлов и отсутствие ошибок получения результата пользователем совместно с использованием утилиты ProxySQL, которая выполняет аналогичные функции для СУБД MySQL/MariaDB. Использование обоих механизмов позволяет значительно повысить общий уровень защиты ИС от падения в результате сбоев, так как дублирование только одной из двух основных входящих компонент – web-сервера или СУБД – всё равно сохраняет достаточно высокую вероятность появления сбойных ситуаций.

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

 
Рисунок 3.2.3.2 — Схема построения отказоустойчивой ИС предоставления данных.

На рисунке 3.2.3.2. приводится схема кластера доступа к данным ДЗЗ, построенного с использованием представленных технологий в ходе реализации системы работы с данными ДЗЗ в интересах ОАО «РЖД». Он состоит из двух узлов – основного и резервного, работающих в паре, при осуществлении доступа через единый интерфейс, на котором настроен web-сервер Nginx, выполняющий несколько основных функций:

• распределение всех поступающих запросов равномерно или согласно определённой весовой зависимости на входящие в кластер узлы;
• контроль доступа к этим узлам с их автоматическим отключением при появлении ошибок получения данных пользователями.

Для отказоустойчивой работы серверов баз данных используется механизм репликации, при котором производится тиражирование изменений данных с главного сервера БД на одном или нескольких зависимых серверах, далее главный сервер будем называть мастером, а зависимые – репликами. При этом все внесённые на мастер сервере изменения повторяются на репликах, но не наоборот, что является одной из причин необходимости выполнения всех запросов на изменение данных исключительно на мастере. Внесение изменений на репликах, в свою очередь, помимо расхождения данных на разных БД дополнительно порождает ситуацию возможного возникновения конфликта с пришедшими с мастера данными, из-за чего процесс репликации полностью нарушается. Репликация даёт:

• производительность и масштабируемость – один сервер может не справляться с нагрузкой, вызываемой большим количеством одновременных операций чтения и записи. Дополнительно стоит отметить, что требующие длительного времени выполнения SQL-запросы можно выполнять на одной из реплик без серьёзного влияния на скорость всей ИС;
• отказоустойчивость – в случае отказа реплики, все запросы можно переключить на мастер, и, наоборот, с последующей сменой ролей в паре мастер-реплика;
• резервирование данных – можно периодически безопасно останавливать реплику для создания резервных копий данных, что невозможно при функционировании только мастера.  
• Утилита ProxySQL является достаточно гибким инструментом для настройки балансировки SQL-запросов между группой БД, которая выполняет по сути те же функции, что и Nginx, а именно:
• распределение всех входящих SQL-запросов равномерно или согласно определённым правилам на включённые в кластер БД;
•  контроль доступа к БД с их автоматическим отключением при появлении ошибок доступа

В рамках настройки этой утилиты производится определение серверов БД, их групп, а также списка MySQL-пользователей, которые имеют права доступа, запросы которых будут проходить через ProxySQL. Также необходимо определить правила распределения SQL-запросов. При этом важно отметить, что запросы распределяются не по конкретным ранее заданным серверам, а по указанным для них группам (hostgroup). Также есть возможность задать несколько групп БД, например, группа БД для операций чтения и группа БД для операций записи, что определяется правами соответствующих группам пользователей и правилами распределения запросов для этих пользователям. Это важный момент при построении отказоустойчивых схем, включающих репликацию, что позволяет избежать основного конфликта между репликой и мастером.

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

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