Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Фронтальные офисные (ФО) системы – одни из основных 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-консоль управления МУПС. В ней отображен список банков, имеющих подключение к нам, статус их коннекции. Мы в удобном интерфейсе можем наблюдать, установлено ли подключение только на транспортном уровне, или имеется подключение на прикладном. Также мы видим, к какой именно ноде (А или В) подключен банк. По клику мыши мы можем переносить соединения выбранного банка или всех сразу между нодами А и В. При этом участник не видит для себя никаких разрывов и пропадания авторизационного трафика.
Заключение
Созданный комплекс МУПС/ПУПС позволил решить ряд существенных вопросов компании по управлению прикладными соединениями банков с компанией:
все работы на ФО остаются незамеченными для участников, не происходит разрыва соединений и потери транзакций;
при проблеме на ноде ФО, перевод трафика на резерв осуществляется автоматически и мгновенно, банк также не видит разрыва соединения;
дежурные службы и администраторы ФО получили удобный и наглядный инструмент для управления соединениями. Вывод ноды из работы для обновления ОС, замены железных компонент также не замечается участником и не приводит к транзакционным потерям.
