Comments 11
Почему keepalived, а не, скажем, pacemaker? Меня, честно говоря, пугает кипэлайв хотя бы тем, что он не устойчив к ситуации разделения сети между обоими участниками (они без внешнего арбитра не смогут определить кто из них обоих работающих «главный»). И коли уж такая история — перекидывание трафика можно через тот же bgp сделать.
Ещё не рассказано что там за история с дампом слепка памяти. Это чудесный CRIU от Виртуоззо?
автоматически и мгновенно,
Ну, Вы же инженеры — что значит — мгновенно? Физически это попросту невозможно. Значит, есть какое-то минимальное время переключения. Микросекунды, секунды. В худшем случае. Да, это может сглаживаться особенностями самого протокола TCP и быть незаметно для клиента. Но точно не «мгновенно»
Это чудесный CRIU от Виртуоззо?
В FreeBSD и OpenBSD есть специальный функционал, для синхронизации состояний соединений, чтобы при передаче трафика между нодами statefull firewall оставался работоспособным. ОЧЕНЬ хочется верить, что здесь подобный механизм, поскольку просто перекачивать кучи говнища из кучи и стеков из экземпляра в экземпляр — верный путь вырастить какое нибудь чудовище в этой чаше Петри…
Ну, вряд ли у коллег BSD… Скорее Linux ))) со всеми вытекающими.
Кстати, очень интересно как в рамках ISO 8583 решается проблема целостности и консистентности. Скажем, развалилось взаимодействие между обоими ДЦ, запись о транзакции попала только в один из двух. Потом этот ДЦ "сгорел" или случилось что угодно. Клиент же отметку о том, что транзакция успешна не получил (т.е. мы выбиваемся из модели "есть подтверждение", "есть отказ", а сваливаемся именно, что в неопределенность). Что произойдет? Я вообще с трудом верю в надежность eventually consistent систем, но вот сама природа физики такова, что изменения в среде не могут распространяться мгновенно.
Вопрос на самом деле не праздный. Тут, с финансами, права на ошибку нет....
Это зависит от того какая транзакция. Там разные случаи бывают, например в случае покупки если клиент ответ не получил, он на всякий случай засылает отмену этой транзакции (несколько раз если нужно) и делает уже новую транзакцию.
В разных других случаях клиент повторяет и повторяет транзакцию, пока не получит ответ
Но, к слову, никогда не было требования что бы прикладная сессия (обмен в рамках одного перевода) была в рамках одного TCP/IP.
А вот требование для участников имеющих более одного активного соединения «С какой нодой начали операцию перевода — туда же нужно посылать все сообщения в рамках перевода» осталось?
В рамках этого протокола ответ всегда доставляется в то же соединение по которому был получен запрос.
Для каждой операции не создается отдельная сессия. У банка все время установлена активная 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)
Впрочем, это темы наверное уже не для общей переписки, хотя вопросы очень общие.
Но, в задачах/заявках очень тяжело с НСПК общаться и такие вопросы задавать бессмысленно. Не поймут/проигнорируют вопрос…
Спасибо за ваш комментарий, но он скорее о Системе быстрых платежей, которая обрабатывает запросы по ISO20022. В ней как раз и используются запросы и идентификаторы платежей, о которых вы говорите. В этой статье я рассказываю про обработку авторизационного трафика по пластиковым картам. Он осуществляется в непрерывной TCP сессии по прикладному протоколу ISO8583.
Обновление фронтальных систем НСПК без прерывания сервиса