Всем привет!
Прошу поделится опытом как реализовывать отказоустойчивость сервера accel в режиме ipoe.
Сейчас тестируем схему работы vlan на коммутатор.
1) Хотим обеспечить отказоустойчивость сервера по физике (если с железом проблемы или с питанием).
2) Хотим обеспечить работоспособность при отказе радиуса или БД(радиус и БД находятся на разных серверах и соединены по TCP).
Если никто не решат таких задач прошу поделится своими соображениями как можно проверять удаленно работоспособность accel-ppp, желательно онлайн(запущен ли демон, существуют ли сессии и т.п.).
Отказоустойчивый кластер
Re: Отказоустойчивый кластер
В accel-ppp присутствует возможность использовать 2 радиус сервера.
Работоспособность сервера можно проверить по snmp, предварительно скомпилировав accel-ppp с snmp.
Работоспособность сервера можно проверить по snmp, предварительно скомпилировав accel-ppp с snmp.
Re: Отказоустойчивый кластер
rob, ты в итоге как нибудь решил вопрос с реализацией отказоустойчивого accel?
dimka88, теоритически можно ли имея 2-3 одинаковых сервера объединить их в один кластер и при поднятии сессии на одном сервере, поднимать ее же и на всех остальных? Таким образом мы можем на коммутаторах настроить следование трафика через все 3 сервера одновременно, но если один из серверов вышел из строя, слать трафик через оставшиеся 2.
dimka88, теоритически можно ли имея 2-3 одинаковых сервера объединить их в один кластер и при поднятии сессии на одном сервере, поднимать ее же и на всех остальных? Таким образом мы можем на коммутаторах настроить следование трафика через все 3 сервера одновременно, но если один из серверов вышел из строя, слать трафик через оставшиеся 2.
Re: Отказоустойчивый кластер
Автор проекта когда-то начинал реализацию accel c DPDK и вроде были мысли реализовать подобное, на чем остановилось и будет ли подобная реализация - кроме него никто не ответит.dimka88, теоритически можно ли имея 2-3 одинаковых сервера объединить их в один кластер и при поднятии сессии на одном сервере, поднимать ее же и на всех остальных? Таким образом мы можем на коммутаторах настроить следование трафика через все 3 сервера одновременно, но если один из серверов вышел из строя, слать трафик через оставшиеся 2.
В теории возможно все, но у accel-ppp еще нет функционала синхронизации между серверами. Но есть балансировка с DHCP примитивным резервированием, при схеме l2+dhcp.
Re: Отказоустойчивый кластер
Я присматриваюсь к conntrack, который может достаточно хорошо подойти к этой задаче. Глубоко не копал, однако по описанию похоже что должно помочь.
Re: Отказоустойчивый кластер
Одного клиента должен обслуживать один сервер, при падении сервера клиент должен переключится автоматом без малейшего простоя сервиса?
Re: Отказоустойчивый кластер
Я думаю что если простой будет в 2-3 пинга, то это ничего страшного.
Т.к. если мы говорим о pppoe или pptp соединениях, то не хочется просить клиента переподключиться в случае падения сервера. Было бы отлично чтоб эта сессия была уже открыта на другом сервере, а мы в свою очередь просто бы перевели весь трафик этого клиента на другой сервер. Пусть и с потерей пары пакетов.
Т.к. если мы говорим о pppoe или pptp соединениях, то не хочется просить клиента переподключиться в случае падения сервера. Было бы отлично чтоб эта сессия была уже открыта на другом сервере, а мы в свою очередь просто бы перевели весь трафик этого клиента на другой сервер. Пусть и с потерей пары пакетов.
Re: Отказоустойчивый кластер
Что касается реализации. То если бы была возможность поднять сессии клиентов вручную, скриптами. То можно было бы поставить какой либо "контроллер" на такую группу серверов, который бы при выходе из строя одного сервера, мигрировал бы поднятые сессии одного сервера на другой.
Re: Отказоустойчивый кластер
Вот насчет туннелей думаю дела будут обстоять сложнее. Не уверен что такое возможно реализовать, но могу ошибаться, так как Dmitriy готовил для чего то backup.
Re: Отказоустойчивый кластер
backup? А где можно про него почитать?
Может Dmitriy присоединится к этой теме, было бы интересно услышать его мнение так же.
Может Dmitriy присоединится к этой теме, было бы интересно услышать его мнение так же.