Всем привет.
Имеется 2 сервера ( или цепочка серверов ) : основной и резервный , разделенные географически
В случае отказа основного , резервный должен взять на себя обслуживание клиентов.
Вопрос :
1. Какой посоветуете протокол взаимодействия между серверами для обеспечения перехода основного на резервный ( и наоборот , если основной восстановился )
2. Какую посоветуете архитектуру , так , чтобы данный переход был прозрачен для клиентов
Спасибо
Здравствуйте, Alex34, Вы писали:
A>Всем привет.
A>Имеется 2 сервера ( или цепочка серверов ) : основной и резервный , разделенные географически
A>В случае отказа основного , резервный должен взять на себя обслуживание клиентов.
A>Вопрос :
A>1. Какой посоветуете протокол взаимодействия между серверами для обеспечения перехода основного на резервный ( и наоборот , если основной восстановился )
A>2. Какую посоветуете архитектуру , так , чтобы данный переход был прозрачен для клиентов
A>Спасибо
Есть протокол VRRP для работы с виртуальным IP. Под Linux для работы с ним есть keepalived, под другими платформами тоже есть инструменты.
Клиент должен подключаться к виртуальному IP. При переезде виртуального IP на другой хост соединение с сервером оборвётся и надо будет переподключиться.
Но для того, что бы кроме переподключения ничего больше не потребовалось, нужно ещё, что бы сервера между собой данные синхронизировали. Если используется БД для хранения данных, то посмотри, какие возможности есть в СУБД для репликации.
Часто в таких случаях используют 4 хоста — 2 балансировщика и 2 сервера, обрабатывающих данные.
Балансировщик 1 Сервер 1
+---+ +---+
| | ---------------------->| |
+---+ +----->+---+
^ \ /
Клиент / \ /
+---+ / \ /
| | --> Virtual IP \ /
+---+ \ \ /
\ +---------+
v / \
Балансировщик 2 / \ Сервер 2
+---+ -------+ +---->+---+
| | ---------------------->| |
+---+ +---+
В этом случае главным вопросом будет сохранение данных сессии на сервере. Для этого можно посмотреть в сторону какой-нибудь In-memory DB с возможностью репликации данных между хостами.
