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

Question

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

Я пытаюсь найти правильные части для реализации высокодоступной и отказоустойчивой установки для серверного приложения на основе C. TCP-соединения в идеале должны быть в течение нескольких дней. Если главный сервер выходит из строя из-за неконтролируемой сетевой проблемы, то резервный сервер будет действовать как главный с подключением TCP к этому серверу.

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

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

Что мне нужно, так это если главный сервер выйдет из строя, то резервный сервер будет обрабатывать все клиенты с TCP-соединениями, не отключая сеанс TCP.

Master и Standby будут иметь виртуальный IP с использованием keepalived.

        |        VIP         |
   +----+----+          +----+----+
   | Master  | <-VRRP-> | Standby |
   +----+----+          +----+----+
        |                    |               
        |                    |
  ------+---+------------+---+----------                                
            |            
        +---+---+    
        |Client |  
        +---+---+    

Какие есть варианты для переключения TCP-соединений или синхронизации сеансов TCP между главным и резервным серверами, на которых работает RHEL7.1. Таким образом, клиент, подключенный, не может знать, выходит ли из строя главный сервер, а резервный сервер стал главным сервером.

Спасибо!

Answer 1

Как уже отмечали другие, настоящее зеркалирование и восстановление после сбоя TCP-соединения не легкое и это то, что нужно делать на уровне ядра. Ни один пользовательский процесс не сможет сделать это за вас.

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

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

Как и другие спрашивали: ты уверен, что тебе это нужно? Я настоятельно рекомендую изменить архитектуру всего приложения таким образом, чтобы клиенты могли справиться с обрывом соединения при повторной попытке. Если это невозможно, рассмотрите общую архитектуру, в которой вероятность сбоя снижается до такой степени, что крайне редкая потеря соединений просто не имеет значения.

Вы пытаетесь достичь 100% безотказной работы для ваших TCP-соединений. Учтите, однако, что это, скорее всего, в любом случае недостижимо, поскольку может произойти сбой любого количества других компонентов (питание, восходящие маршрутизаторы и т. Д.)

Поэтому вам все равно нужно спроектировать это для возможного сбоя.