Обновление фронтальных систем НСПК без прерывания сервиса

    Фронтальные офисные (ФО) системы – одни из основных 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%.

    Обновление происходит следующим образом:

    1. Остановка приклада на резервных нодах В, где нет трафика от участников.

    2. Обновление ФО на нодах В.

    3. Перевод трафика с активных нод А на обновленные ноды В путем остановки нод А.

    4. Контроль правильности обработки трафика, отсутствия возросших отказов, ошибок в логах.

    5. Обновление нод А.

    6. Ноды В теперь становятся активными, а ноды А резервными. 

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

    Заключение

    Созданный комплекс МУПС/ПУПС позволил решить ряд существенных вопросов компании по управлению прикладными соединениями банков с компанией:

    • все работы на ФО остаются незамеченными для участников, не происходит разрыва соединений и потери транзакций;

    • при проблеме на ноде ФО, перевод трафика на резерв осуществляется автоматически и мгновенно, банк также не видит разрыва соединения;

    • дежурные службы и администраторы ФО получили удобный и наглядный инструмент для управления соединениями. Вывод ноды из работы для обновления ОС, замены железных компонент также не замечается участником и не приводит к транзакционным потерям.

    Комментарии 11

      0

      Почему keepalived, а не, скажем, pacemaker? Меня, честно говоря, пугает кипэлайв хотя бы тем, что он не устойчив к ситуации разделения сети между обоими участниками (они без внешнего арбитра не смогут определить кто из них обоих работающих «главный»). И коли уж такая история — перекидывание трафика можно через тот же bgp сделать.
      Ещё не рассказано что там за история с дампом слепка памяти. Это чудесный CRIU от Виртуоззо?


      автоматически и мгновенно,

      Ну, Вы же инженеры — что значит — мгновенно? Физически это попросту невозможно. Значит, есть какое-то минимальное время переключения. Микросекунды, секунды. В худшем случае. Да, это может сглаживаться особенностями самого протокола TCP и быть незаметно для клиента. Но точно не «мгновенно»

        +1
        Это чудесный CRIU от Виртуоззо?

        В FreeBSD и OpenBSD есть специальный функционал, для синхронизации состояний соединений, чтобы при передаче трафика между нодами statefull firewall оставался работоспособным. ОЧЕНЬ хочется верить, что здесь подобный механизм, поскольку просто перекачивать кучи говнища из кучи и стеков из экземпляра в экземпляр — верный путь вырастить какое нибудь чудовище в этой чаше Петри…
          0

          Ну, вряд ли у коллег BSD… Скорее Linux ))) со всеми вытекающими.


          Кстати, очень интересно как в рамках ISO 8583 решается проблема целостности и консистентности. Скажем, развалилось взаимодействие между обоими ДЦ, запись о транзакции попала только в один из двух. Потом этот ДЦ "сгорел" или случилось что угодно. Клиент же отметку о том, что транзакция успешна не получил (т.е. мы выбиваемся из модели "есть подтверждение", "есть отказ", а сваливаемся именно, что в неопределенность). Что произойдет? Я вообще с трудом верю в надежность eventually consistent систем, но вот сама природа физики такова, что изменения в среде не могут распространяться мгновенно.
          Вопрос на самом деле не праздный. Тут, с финансами, права на ошибку нет....

            +1

            Это зависит от того какая транзакция. Там разные случаи бывают, например в случае покупки если клиент ответ не получил, он на всякий случай засылает отмену этой транзакции (несколько раз если нужно) и делает уже новую транзакцию.
            В разных других случаях клиент повторяет и повторяет транзакцию, пока не получит ответ

              0
              Если ответ не получен, то наша система автоматически формирует отмену и доставляет ее до момента, пока не будет получен ответ на отмену.
              0
              В нашей архитектуре нет необходимости второму ЦОДу узнавать о том, в каком статусе транзакция проходит на первом. Транзакция может завершиться только в том же соединении, что и инициировалась. Цоды могут работать независимо в балансировке.
          +1
          Активный переброс через транспортный уровень (TCP/IP) это замечательно…
          Но, к слову, никогда не было требования что бы прикладная сессия (обмен в рамках одного перевода) была в рамках одного TCP/IP.

          А вот требование для участников имеющих более одного активного соединения «С какой нодой начали операцию перевода — туда же нужно посылать все сообщения в рамках перевода» осталось?
            0
            Для каждой операции не создается отдельная сессия. У банка все время установлена активная TCP сессия поверх которой идет платежи по ISO8583.

            В рамках этого протокола ответ всегда доставляется в то же соединение по которому был получен запрос.
              +1
              Для каждой операции не создается отдельная сессия. У банка все время установлена активная TCP сессия поверх которой идет платежи по ISO8583.

              Хм… Это как?
              Гарантировано, что один HTTP(s) запрос/ответ XML в рамках одной TCP/IP сессии. Это же класcический HTTP.

              И такого требования (непрерывная TCP/IP сессия в рамках прикладного обмена при выполнении перевода от C01, скажем, до C11) я не припомню в спецификациях (и не делали).

              То, что практически все библиотеки HTTP клиента, умеет кэшировать и переиспользовать TCP/IP сессии для посылки HTTP это фича, а не гарантия непрерывности TCP/IP сессии.
              Да и прокси то же имеет право переустанавливать TCP/IP в разных HTTP запросах…

              Фраза про «Для каждой операции не создается отдельная сессия.» насторожила! Это требование которое мы пропустили?

              В рамках этого протокола ответ всегда доставляется в то же соединение по которому был получен запрос.

              Это то понятно. По другому и не сработает в рамках одного запрос/ответ.

              Меня больше интересовал случай «две ноды в активном режиме» и сохранение требования «с какой нодой (ЦОД) начали работать в рамках одного перевода — туда же должны посылаться ВСЕ запросы данного перевода». Т.е. если послали прикладной запрос C01 в ноду 1, то и все остальное запросы данного перевода посылаем туда же.

              Это требование довольно сильно ограничивает варианты схем балансировки нагрузки.
              Вот и вопрос: «ограничение осталось?»
              Из описания и картинок, мне показалось, что ограничение осталось. Но хотел уточнить.

              То, что все запросы в ноду в рамках одного перевода должны посылаться в рамках одного TCP/IP соединения — такого требования нет (да и не может быть при использовании HTTP)

              Впрочем, это темы наверное уже не для общей переписки, хотя вопросы очень общие.

              Но, в задачах/заявках очень тяжело с НСПК общаться и такие вопросы задавать бессмысленно. Не поймут/проигнорируют вопрос…
                +2

                Спасибо за ваш комментарий, но он скорее о Системе быстрых платежей, которая обрабатывает запросы по ISO20022. В ней как раз и используются запросы и идентификаторы платежей, о которых вы говорите. В этой статье я рассказываю про обработку авторизационного трафика по пластиковым картам. Он осуществляется в непрерывной TCP сессии по прикладному протоколу ISO8583.

                  0
                  ой. извините… вроде бы читал же (ISO8583), а не увидел.

                  У кого что болит… У меня сейчас болит СБП.
                  С интеграцией с НСПК по ISO8583 проблем никогда не было. И особых вопросов по этой теме нет.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое