Высокая доступность / отказоустойчивость приложения Java с постоянными сокетами TCP-сервера

Я пытаюсь найти правильные элементы для реализации высокодоступной и отказоустойчивой настройки для серверного приложения на основе Java (netty). В идеале TCP-соединения были бы активны в течение месяцев, если не лет (они используются в обмене данными между серверами), и должны были бы отключаться только в том случае, если удаленный сервер отключился или из-за неконтролируемой сетевой проблемы. Цель состоит в том, чтобы не было единой точки отказа.

Данные в соединениях сокетов очень похожи на структуры данных protobuf. Это не HTTP.

До сих пор я смотрел на keepalived и HAProxy, но, похоже, ни один из них не позволяет перенаправить / переключить постоянный сеанс TCP на другой внутренний сервер без отключения внешнего сеанса.

Я пытаюсь понять, что будет работать в системах FE1 и BE1, как показано ниже;

        |        VIP         |
   +----+----+          +----+----+
   |   FE1   | <-VRRP-> |   FE2   |
   +----+----+          +----+----+
        |                    |               
        |                    |
  ------+---+------------+---+----------                                
            |            | 
        +---+---+    +---+---+
        |  BE1A |    |  BE1B |
        +---+---+    +---+---+
            |            |       
            +------------+
            |            | 
            |            |
        +---+---+    +---+---+
        |  BE2A |    |  BE2B |
        +---+---+    +---+---+

Внешние серверы подключаются через VIP к активной системе внешнего интерфейса (FE), которая затем устанавливает TCP-соединение с активной внутренней системой 1 (BE1). Или если это делает TCP-прокси; подключается к обеим системам BE1 и отправляет трафик в одну систему.

Серверы BE1 запускают настраиваемое приложение Java, которое обеспечивает, чтобы запросы и ответы попадали в соответствующую систему BE2. Это может быть изменено любым способом для обработки соединения / потока от серверов FE, если это необходимо.

Я ищу, если одна из систем BE1 выходит из строя (намеренно или нет), это сервер FE перенаправляет / повторно устанавливает соединение с другой системой BE1 без какого-либо отключения от подключения к внешнему VIP с удаленного сервера. . Т.е. прозрачная отработка отказа постоянного TCP-соединения.

Как упоминалось ранее, я посмотрел на keepalived / HAProxy, и, насколько я могу судить, они не будут работать - если только я не пропустил для них плагин / мод, который мог бы помочь.

Какие существуют варианты того, что может работать на слое FE? или есть что-то, что может работать на уровне BE1, которое может обрабатывать отказоустойчивость и уведомлять java о перемещении / возобновлении сокета в альтернативной системе (т.е. может ли LVS или tcpcp использоваться с java - я не нашел много разговоров о Это).

Спасибо!


java tcp high-availability failover haproxy
person Doswell    schedule 22.11.2013    source источник
comment
По какой причине вы хотите, чтобы соединение не прерывалось? Я думаю, вы слишком усложняете. Лучше, если клиенты просто повторно подключатся, если соединение не удастся, а затем будут перенаправлены на новый сервер. Помимо разрыва соединения, существует так много сетевых проблем, о которых вы все равно должны подумать. Что делать, если сервер BE2 работает, но возвращает ошибки. Или если он истекает? Похоже, что вам нужно, чтобы FE1 был полноценным TCP-прокси. Если он пересылает сообщение и терпит неудачу, он может попытаться переслать его на другой сервер.   -  person Dave    schedule 24.11.2013
comment
@Dave Итак, если нам нужно проводить обслуживание или обновлять серверные системы, это может быть прозрачно. Некоторые клиенты не замечают никаких отключений и сразу же подключаются повторно, однако другие не подключаются повторно, и при любом отключении требуются отчеты об инцидентах (независимо от того, было ли это отключение на 100 мс). Протокол обрабатывает тайм-ауты, сообщения поддержки активности приложений и проблемы, поэтому, если сообщение не удается, оно обрабатывается между внешним сервером и FE2.   -  person Doswell    schedule 26.11.2013
comment
Я пришел к выводу, что у большинства крупных клиентов (и тех, которые больше жалуются) есть несколько подключений (они просматривают их в связке, поэтому при наличии одного подключения они в порядке), которые я могу сбалансировать между BE1. Таким образом, мы могли отключить одну систему FE1, и соединения сместились бы на другую, когда она будет восстановлена, нам просто нужно будет отбросить отказавшие соединения в системе FE1, чтобы восстановить их. Так что в целом это сработает. Может просто быть более вовлеченным, чем нужно.   -  person Doswell    schedule 26.11.2013
comment
Значит, вам нужны FE1 и FE2 в качестве прокси. Клиентское соединение завершается на FE1 и FE2. Программное обеспечение на FE1 и 2 достаточно умен, чтобы, если BE * отключится, он снова подключится к другому. В этом случае серверы FE не могут быть каким-то универсальным прокси, а должны понимать ваш протокол.   -  person Dave    schedule 26.11.2013

Ответы (1)


arrow_upward
0
arrow_downward

Я пытаюсь достичь этого, я видел, как этот подход работает с Websphere MQ, когда вы добавляете приложение в контроллер аварийного переключения. Преимуществами являются:

  • Вы просто знаете один IP-адрес
  • вам не нужно кодировать переключение на клиенте

С наилучшими пожеланиями. Леонель дос Аньос

person user3116739    schedule 13.08.2015