Сервисы IRC с поддержкой отработки отказа?
Я запускаю один сервер (назовем его "сервер A") IRC "сеть", и благодаря щедрости некоторых друзей мне дали второй сервер ("сервер B"), на котором я могу запустить IRCd, чтобы обеспечить резервирование в случае сбоя сервера A. Это нормально, я могу настроить циклический DNS со связанными серверами. Проблема у меня в том, что делать с услугами? Кто-нибудь знает, как заставить службы "сбой" в случае сбоя сервера? Например, сервер A запускает службы, но внезапно падает. Сервер B обнаруживает это и запускает собственную копию сервисов (в идеале с той же конфигурацией и данными, что и сервисы на Сервере B)
Одно решение, которое приходит на ум, - это написать бота, который работает на каждом сервере, который периодически сидит в канале, проверяя, находится ли бот с другого сервера в канале. Если это так, то все хорошо. Если нет, то переход на другой ресурс. Я бы предпочел не кодировать это сам, хотя
В настоящее время мы используем сервисы Unreal IRCd и Anope в Linux
3 ответа
Короткий ответ: Вы не можете с Anope (или любой другой системой услуг, о которой я знаю)
Длинный ответ: Ваша идея хороша, и вам, возможно, не придется писать код с нуля - вы, вероятно, можете взять существующий код шаблона для простых ботов IRC (например, в Python); им также не обязательно регулярно опрашивать других ботов, а просто обрабатывать сообщения соединения / части / выхода. Вам, конечно, придется каким-то образом иметь дело с различными условиями гонки (например, netsplits, проблемы с доступом к базе данных и т. Д.)
Ближе всего к отказоустойчивости вы можете получить без кодирования пользовательских сервисов (не тривиальная задача). это установка служб на несколько других учетных записей, из которых вы уже запускаете IRCd в своей сети, и crontab скрипт rsync для распространения базы данных служб на другие машины. Таким образом, если пакетные службы включены, вы можете запускать службы с другого компьютера и при этом иметь относительно текущие базы данных.
Crontab не так сложен в изучении, как и rsync, и намного быстрее, чем программирование нестандартного решения.
Лучше всего этот метод работает со всеми существующими пакетами услуг, которые используют единую базу данных.
Основываясь на том, что сказал @IRCGuru. Можно также настроить переход DNS для каждого сервера, к которому осуществляется доступ viva region.irc.yourirc.net. Оба метода хорошо работают в среде, которую вы описываете, и если кто-то работает в среде виртуальной машины.
Используя версию vm, вы можете просто раскрутить второй экземпляр вашего сервера и перенаправить входящий порт с одного на другой или даже распределить нагрузку между ними, при этом оба они будут внутренне соединяться друг с другом, чтобы предотвратить разрывы каналов в ваших каналах.