Фронтальные офисные (ФО) системы – одни из основных Mission Critical систем, эксплуатируемых в НСПК сегодня. Они отвечают за обработку и маршрутизацию авторизационных запросов между Банком-эквайрером и Банком-эмитентом. Именно через них производят обмен данными банки пока вы проводите операцию по карте. Через ФО проходит до 60 миллионов авторизаций в сутки, при этом в пике они обрабатывают 1800 TPS(transaction per second).
Меня зовут Пашин Вадим, в НСПК я руковожу управлением фронт-офисных решений и сегодня я хочу поделиться опытом внедрения системы управления соединениями банков.
ФО обладают достаточно сложной архитектурой и имеют 4-кратное резервирование каждого сервера.
Мы используем 2 ЦОД для георезервирования. В каждом ЦОД расположены ноды, принимающие соединения и обрабатывающие трафик от банков. Каждая нода обслуживает часть банков. Имеются следующие резервирования – нода, обслуживающая трафик участников (нода А), имеет копию внутри ЦОД (нода В), а также копии этих двух нод существуют и в другом ЦОД.
Существует 3 типа подключения участников:
Участник имеет одно активное соединение к 1 ЦОД (Active-Passive);
Участник имеет два активных соединения к 2 ЦОД (Active-Active);
Участник имеет четыре активных соединения к 2 ЦОД (4 Active).
Как и любые другие IT-системы, ФО требуют периодических обновлений. Мы разделяем обновления на следующие типы:
Релиз;
Hotfix.
Релиз рождается в рамках 2-недельных спринтов и может содержать в себе следующие изменения:
Business features – внедрение новой бизнес-функциональности в платежную систему. Например, такие сервисы как «Покупка с выдачей наличных», возможность использования новых Wallet providers (Mir Pay,Samsung pay, etc.);
Technical features – внедрение технических изменений, упрощающих сопровождение системы, повышающих ее скорость работы, переход на новые технические решения;
Bug fixing – устранение багов, не оказывающих влияния на бизнес компании.
Изменения в виде hotfix могут устанавливаться между релизами и предназначены для исправления ситуаций, когда есть влияние на бизнес компании, и часть трафика не может быть корректно обслужена. При этом это могут быть не только ошибки в нашей системе – бывает, что после установки новых версий системы на стороне банка возникают ошибки в обработке его трафика, так как некоторые поля авторизационного протокола участник заполняет неверно. Если участник не может оперативно решить проблему, то мы производим, если это возможно, корректировку ошибок на нашей стороне ��о того момента, как банк решит проблему на своей стороне.
Как правило, все изменения в виде релиза или hotfix требуют полной остановки приложений, отвечающих за обработку трафика на ноде. Это требуется для дистрибуции новых библиотек, перезапуска приложений, а также контроля по логам и через систему мониторинга, что ошибок при старте не образовалось, и модули ФО запущены в полном составе. Но мы не можем останавливать обработку трафика от банков, так как их клиенты не могут ждать у кассы и/или банкоматов, когда мы завершим обновление, и они смогут совершить покупку или снять наличные. Также мы стремимся к доступности нашего сервиса в 99,999%.
Обновление происходит следующим образом:
Остановка приклада на резервных нодах В, где нет трафика от участников.
Обновление ФО на нодах В.
Перевод трафика с активных нод А на обновленные ноды В путем остановки нод А.
Контроль правильности обработки трафика, отсутствия возросших отказов, ошибок в логах.
Обновление нод А.
Ноды В теперь становятся активными, а ноды А резервными.
Участники обмениваются авторизационными сообщениями по прикладному протоколу, основанному на ISO 8583. Он описывает формат финансовых сообщений и процесс передачи системами, обрабатывающими данные банковских платежных карт. Транспортным протоколом выступает TCP/IP. Участник имеет только два IP для подключения (по одному на каждый ЦОД) и не знает, на какую ноду (А или В) уходит его трафик. Раньше мы использовали так называемый балансировщик, который проверял доступность ноды А при установке соединения со стороны банка. В случае ее доступности, устанавливалось соединение с нодой А, при недоступности ноды А, происходило установление соединения с нодой В.
Схема с балансировщиком имела следующий вид:
Использование балансировщиков было удобным и простым для сопровождения, при выключении нод происходило переустановление сессий на резервные ноды, однако опыт эксплуатации выявил следующие недостатки:
доступность ноды определяется балансировщиком только во время установления сессии от банка;
невозможность проведения обновлений ФО без разрывов соединений. Чтобы перевести трафик на резервные ноды В, происходит разрыв всех соедин��ний, и всему рынку необходимо заново устанавливать свои сессии. Так как после установления сессий на транспортном уровне необходимо также установление прикладного уровня. Большинство банков умеют восстанавливать свои соединения в автоматическом режиме, но разные ПО банков это делают с разной скоростью. Неизбежно происходят потери авторизаций на время переключения. Это негативно влияет на нашу доступность.
в случае некорректной обработки трафика на нодах В во время обновления, обратное переключение на ноды А требует времени.
Мы стремимся к доступности 99,999% для наших ФО, поэтому в компании было принято решение и запущен проект разработки нового комплекса по управлению трафиком участника. К нему предъявлялись следующие требования:
возможность быстрого ручного или автоматического переключения трафика между нодами А и В;
переключение между нодами не должно порождать разрыв существующей TCP‑сессии с банками;
отказоустойчивость. Новый модуль должен быть зарезервирован, его падение также не должно вызывать разрыва TCP-сессии с банками;
удобный графический web-интерфейс управления с разграничением доступов.
В итоге мы получили новую подсистему управления соединениями с участниками – МУПС/ПУПС.
Схема подключения преобразилась следующим образом:
Название система получила от имени двух модулей, из которых она состоит:
ПУПС – Прокси управления прикладными соединениями;
МУПС – Модуль управления прикладными соединениями.
Мы вывели точки терминации трафика от банков из ЦОД в точки обмена трафиком М9 и М10, где располагается наше коммуникационное оборудование. Оборудование для реализации нового умного балансировщика мы также расположили на этих площадках.
В каждой точке обмена трафиком М9/М10 мы расположили по активной и резервной паре МУПС/ПУПС. Перейдем к описанию этих компонент и принципа работы нового комплекса. Серверы с этими парами объединены в VRRP-кластер с помощью keepalived и делят между собой один виртуальный IP.
ПУПС отвечает за TCP-взаимодействие узла балансировки с процессинговым ПО банков. Реализуе�� механизм репликации и прозрачного восстановления TCP-соединений с организацией-участником на случай штатного переключения:
принимает TCP-соединения;
инициирует обмен данными между МУПС, ПУПС и банком;
отправляет и получает прикладные сообщения;
обрабатывает управляющие соединения между МУПС и ПУПС;
восстанавливает TCP-подключения и обеспечивает переключение между основными и резервными МУПС/ПУПС.
МУПС, второй компонент системы, предназначен для:
поддержания соединений с нодами ФО;
управления соединениями банков (включить/выключить, подключиться к ноде А или ноде B);
оборачивания сообщения ISO 8583 (авторизационная информация от банка) в свой протокол взаимодействия МУПС и ноды ФО;
получения сообщений от ноды ФО, разворачивания сообщения ISO 8583 и отправка в ПУПС;
подачи команды ПУПС о миграции на резервный сервер.
Одна из самых важных функций МУПС, ради чего он создавался, это переключение обработки трафика на резервную ноду ФО и обратно без разрыва соединения с банком-участником. Это работает благодаря тому, что МУПС стоит между ПУПС, который "держит" соединение с банком, и ФО, который обрабатывает трафик. МУПС управляет тем, куда именно этот трафик направляется в данный момент, и по команде от администратора осуществляет незаметное для банка и безопасное для обработки операций переключение между серверами.
Происходит это следующим образом:
фронтальные модули по команде от МУПС переходят в состояние синхронизации
активный модуль, который в данный момент обрабатывает операции, загружает контексты in-flight операций (для которых он ожидает, но ещё не получил ответных сообщений от банка) из своей памяти в общий in-memory data grid
резервный модуль забирает к себе эти контексты
по завершении выгрузки МУПС деактивирует активный модуль и передаёт на резервный его новый статус и ряд runtime-параметров, с которым работал прошлый активный модуль
с этого момента МУПС начинает направлять трафик от участника на новый активный модуль
Для передачи данных и управления МУПС используется два соединения. Первое – это Data-соединение. Используется для передачи данных по авторизациям от банка (ISO8583) в ФО и обратно. Второе соединение – это Control-соединение. Используется для обмена управляющими сообщениями между ПУПС и МУПС. В управляющем соединении используются команды для проверки жива ли активная пара МУПС/ПУПС – команда heartbeat, а также ряд команд для осуществления переезда соединений на резервную пару МУПС/ПУПС в рамках площадки.
В узле балансировки активный ПУПС взаимодействует только с МУПС, установленном на том же сервере, что и ПУПС.
Если сигналы heartbeat от МУПС отсутствуют в течение заданного времени, ПУПС на активном узле начинает процедуру активации второго узла в кластере (при его доступности), а затем деактивируется.
Процесс миграции с основного сервера на резервный сервер происходит следующим образом:
ПУПС на основном сервере устанавливает флаг готовности к миграции;
на основном сервере создается дамп процесса, далее ПУПС переносит его образ на резервный сервер, а также устанавливает флаг готовности к миграции и восстановлению на резервном сервере;
ПУПС на резервном сервере при обнаружении образа переносит правила iptables и увеличивает приоритет Keepalived на узле, тем самым запускается процедура переноса IP-адреса;
после переноса IP-адреса Keepalived на резервном сервере из образа восстанавливается работающий процесс. Также восстанавливается приоритет самого Keepalived.
Таким образом, обеспечивается отказоустойчивость пары МУПС/ПУПС в рамках одной площадки.
Взаимодействие МУПС и ноды ФО происходит по собственному протоколу. В протоколе передается как платежная информация, так и проверяется доступность нод ФО с помощью heartbeat, а также может передаваться ряд команд, необходимых для переезда трафика на неактивные ноды ФО. Очень важно: при переезде из активной ноды необходимо получить всю платежную информацию и передать ее уже в резервную ноду B. Наличие постоянных heartbeat между МУПС и нодами ФО позволяет в автоматическом режиме диагностировать проблему с нодой и осуществлять мгновенные переводы трафика участника на резервную ноду без разрыва соединения с участником.
В основном работа администраторов системы происходит через WEB-консоль управления МУПС. В ней отображен список банков, имеющих подключение к нам, статус их коннекции. Мы в удобном интерфейсе можем наблюдать, установлено ли подключение только на транспортном уровне, или имеется подключение на прикладном. Также мы видим, к какой именно ноде (А или В) подключен банк. По клику мыши мы можем переносить соединени�� выбранного банка или всех сразу между нодами А и В. При этом участник не видит для себя никаких разрывов и пропадания авторизационного трафика.
Заключение
Созданный комплекс МУПС/ПУПС позволил решить ряд существенных вопросов компании по управлению прикладными соединениями банков с компанией:
все работы на ФО остаются незамеченными для участников, не происходит разрыва соединений и потери транзакций;
при проблеме на ноде ФО, перевод трафика на резерв осуществляется автоматически и мгновенно, банк также не видит разрыва соединения;
дежурные службы и администраторы ФО получили удобный и наглядный инструмент для управления соединениями. Вывод ноды из работы для обновления ОС, замены железных компонент также не замечается участником и не приводит к транзакционным потерям.
