Три года назад у одного из наших заказчиков — крупнейшего российского банка — появилась задача перенастроить платёжный сервис для ГИС ГМП (штрафы, пошлины и налоги), ГИС ЖКХ, а также запросы начислений (подписки). Выбор решений на рынке был невелик, поскольку нам нужно было подобрать продукт с готовыми комплектами ППО и СУБД, сертифицированный ФСБ России и ФСТЭК России. Перебрав несколько вариантов, мы остановились на комплексном 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)

А вот в задаче по обновлению СУБД 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).

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

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

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

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

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

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

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

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

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

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

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

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