У нас есть сервер, который получает некоторые данные, действует как TCP-клиент, каким-то образом их обрабатывает и обслуживает обработанные данные клиентам, действуя как TCP-сервер. Он также хранит эти данные на диске и может обслуживать их из файлов вместо потока в реальном времени.
Проблема в том, что эта услуга должна быть доступна в режиме 24x7, без перерывов. На данный момент это достигается за счет наличия двух серверов, один из которых выполняет функцию горячего резервирования - клиенты поддерживают соединения с обоими серверами, и если что-то происходит с основным сервером, они просто переключаются на резервный. Хотя это решение работает уже около 15 лет, оно неудобно и накладывает на клиентов много логики аварийного переключения.
В последнее время люди начали говорить об использовании кластера для обеспечения доступности этой службы, но как бы я ни старался, я просто не могу найти никаких решений для кластеризации, которые позволили бы прозрачное переключение TCP-соединения при сбое, чтобы никто не заметил, что что-то случилось с сервером . Вокруг есть несколько исследовательских работ, но мне не удалось найти рабочих реализаций. Вот как, я думаю, это должно работать:
Оба сервера получают данные по TCP. В идеале он должен выглядеть как единое соединение с «внешним» миром для экономии полосы пропускания и, что более важно, для обеспечения того, чтобы оба сервера получали идентичные потоки данных.
Когда клиент подключается к IP-адресу кластера, он получает обработанные данные в одном подключении, но оба сервера должны видеть это подключение и предоставлять данные, просто только один из потоков действительно достигает клиента, резервный идет к Так сказать / dev / null.
Когда сервер выходит из строя (он не передает никаких данных в течение некоторого времени, скажем, 5 секунд), клиент должен продолжать получать тот же поток в пределах того же соединения. Это должно происходить довольно быстро, поэтому общая задержка потоковой передачи не превышает 10 секунд.
Здесь главное - надежность. Следующим шагом будет быстрое переключение. Решения Linux с открытым исходным кодом предпочтительны, но если существуют коммерческие и / или почти идеальные решения, отличные от Linux, я хотел бы знать и о них. Также вполне приемлемы решения, которые налагают множество ограничений или требуют модификации программного обеспечения серверных приложений.
Вы должны посмотреть HAProxy. HAProxy обычно запускается в режиме HTTP, но он также может обрабатывать необработанные TCP-соединения. Он поддерживает балансировку нагрузки между серверами и может использовать Heartbeat для определения того, не работает ли экземпляр.
Если ваша установка должна быть полностью прозрачной (серверы получают исходные IP-адреса, а не IP-адреса сервера HAProxy), вам, возможно, придется исправить ядро Linux для TProxy или найти дистрибутив Linux, который поддерживает TProxy внутри ядра или как модуль.
Это лучшее решение с открытым исходным кодом. Если вам нужно что-то более комплексное, вам следует обратить внимание на коммерческие предложения, такие как Citrix Netscaler для F5 BigIP.
Вы можете получить докторскую степень по этому вопросу - это чрезвычайно сложная проблема. Или вы можете воспользоваться простым подходом и исправить протокол, чтобы не было столь резкого отношения к сбоям соединения. SMTP - достойная модель, позволяющая избежать большинства форм потери данных из-за сбоев.