Три года назад у одного из наших заказчиков — крупнейшего российского банка — появилась задача перенастроить платёжный сервис для ГИС ГМП (штрафы, пошлины и налоги), ГИС ЖКХ, а также запросы начислений (подписки). Выбор решений на рынке был невелик, поскольку нам нужно было подобрать продукт с готовыми комплектами ППО и СУБД, сертифицированный ФСБ России и ФСТЭК России. Перебрав несколько вариантов, мы остановились на комплексном Open Source решении от российских компаний ID Systems и Red Soft. Плюсом также было использование одним из департаментов банка аналогичного пакета, только с другими адаптерами СМЭВ.

Узкое горлышко

Вначале решение работало стабильно, и обновления релизов не занимали много времени. Первым «звоночком», который прозвучал в процессе эксплуатации, стал объём счётчика транзакций в СУБД версии 2.6.0.13370. Поскольку использовалась версия 32-bit и его объём составлял 2^32-1, а количество запросов начислений клиентов измерялось в миллионах, мы могли легко упереться в максимум, что повлекло бы остановку софта. Мы не стали полагаться на волю случая и решили протестировать сброс счётчика. В Red Data Base (RDB) он делается следующими командами:

  1. Переводим базу в режим read_only: ..rdb\bin\gfix -mode read_only -user логин -password пароль {путь_до_БД}.fdb

  2. Далее выполняем бэкап/рестор командами:

    1. backup: ..rdb\bin\gbak -b -v -g -nod -user логин -password пароль {путь_до_БД}.fdb {путь_до_каталога_бекапа}.fbk

    2. restore: ..rdb \bin\gbak -c -v -n -user логин -password пароль {путь_до_резервной_копии_БД}.fbk {путь_до_новой_БД}.fdb

  3. После этого переводим базу обратно в обычный режим: ..rdb\bin\gfix -mode read_write -user логин -password пароль {путь_до_БД}.fdb

Проделав один раз эту операцию, мы не обнаружили заметного простоя, поскольку БД на тот момент была небольшого размера. Однако, наблюдая за ежемесячным приростом её объёма, мы решили действовать проактивно: создать архивную БД и обновить СУБД до версии 64-bit.

С настройкой архивной БД проблем не возникло. Основная суть — обычный перенос данных из исходной БД в архивную, с последующим удалением перенесённых данных из исходной (рис. 1)

Рис.1. Принцип работы запросов в схеме с архивной БД
Рис.1. Принцип работы запросов в схеме с архивной БД

А вот в задаче по обновлению СУБД RDB с версии 2.6.0.13370 до версии 3.0.9-rc.4 нас ждала «приятная неожиданность»: время резервного копирования и восстановления вместо максимально допустимых для финансовой организации трёх часов составило 14!

Самыми «долгоиграющими» пунктами простоя были backup СУБД на версии 2.6.0.13370, а также создание БД версии 3.0.9-rc.4 на основе восстановленной. Фактически резервное копирование второго поколения СУБД делается в один поток, что увеличивает время операций backup и restore.

В зависимости от размера базы данных время выполнения этих задач варьировалось. Так, для БД размером 140 Гб backup составлял около 4 часов, restore — 7 часов. Получается, что если суммировать остальные пункты процесса обновления софта, ориентировочный downtime платежного сервиса составляет не менее 14 часов.

Безусловно, такой простой для платежных сервисов — это полное фиаско, и для заказчика это неприемлемо.

Выход — в совместном подходе

Этот баг обнаружил руководитель группы администрирования банковских систем «Инфосистемы Джет», о чём тут же сообщил инженерам ID Systems. Надо отдать им должное — ребята отнеслись к этому с пониманием, активно помогали в решении ситуации на стороне вендора и совместными усилиями устранили баг.

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

Рис.2. Нагрузочные тестирования
Рис.2. Нагрузочные тестирования

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

  1. Подготовить новый сервер с уже обновлённой до версии 3.0.9-rc.4 СУБД и новую базу данных, соответственно. Развернуть на нём по факту дубль «боевого» сервера, с предварительным переносом всех настроек ППО, включая адаптеры подключений к СМЭВ, планировщики задач и СКЗИ.

  2. Запланировать ночные работы по переключению функционала в регламентное окно, выделенное заказчиком.

  3. Отключить ППО на основном сервере и сменить его имя.

  4. Новому серверу дать имя и IP-адрес основного.

  5. Запустить софт на новом.

В результате тестирования необходимый функционал работал безотказно, а downtime переключения составил всего 35 минут, что, безусловно, удовлетворило заказчика. Бинго! Поэтому мы совместно с инженерами ID Systems его и реализовали.

Более того, остальные работы, заложенные в план перехода, мы смогли делать не в режиме «ошпаренной кошки»:

  1. С бывшей «боевой» базы данных перенести оставшиеся данные в архивную БД.

  2. Обновить на старом сервере версию СУБД и применить изменения для «архивной» БД.

  3. И, наконец, перенести «архивную» БД на новый «боевой сервер» с применением технологии архивного ядра.

Мы понимаем, что идеальных продуктов не существует, зато в нашем случае получилась «идеальная команда» — системный интегратор плюс вендор, которые быстро подключились и смогли решить нестандартную ситуацию заказчика. Кстати, на всех этапах перехода сервис клиента работал бесперебойно.

Комментарии (3)


  1. Isiirk
    23.05.2022 10:54
    +4

    "...140 Гб backup составлял около 4 часов, restore — 7 часов..." - это катастрофа... не буду судить о данной БД, ничего о ней не знаю, но сравнивая с популярными продуктами это разница на порядок как минимум


    1. yason2
      25.05.2022 14:46

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

      А что произойдёт, если потребуется развернуть бекап? 7 часов простоя? Как такое решение можно использовать?


  1. roman_simakov
    23.05.2022 16:08

    Бэкап/рестор можно запустить в пайпе. Для конвертации это очень хорошо. Позволяет ограничить время временем бОльшей операции. Начиная с 3.0.8 появилась возможность использования множества ядер для выполнения бэкапа и рестора, что кратно должно сократить время.

    Много полезного есть на канале https://www.youtube.com/c/RedDatabase