- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Правильно ли я понимаю алгоритм работы Failover IP:
2 сервера: один основной, второй резервный.
Скрипт на резервном сервере раз в секунду проверяет доступность основного. При недоступности - делаются дополнительные проверки (например, 2 проверки с таймаутом в 3 сек) и отправляется запрос на переключение IP на себя.
1. Верно?
2. Возможна ли ситуация с ложным срабатыванием и переключением? Например, если проблемы с каналом на резервном (проверяющим) сервере. Как учесть?
"Failover IP"
где вы это вычитали?
обычно так трактуют возможность менять маршрутизацию, простыми словами переключать на другой сервер/устройство.
вы можете сделать скрипт это уже к Failover не относиться.
и проверять нужно из вне....
где вы это вычитали?
http://wiki.hetzner.de/index.php/Failover/ru
1. Да
2. Да. Использовать третий сервер.
1. Да
2. Да. Использовать третий сервер.
Так. А если падает третий сервер и первый, то что тогда, искать четвертый?
Можно и вторым проверять. Если второй упадет, ну и ладно, первый то работает. А если упадет первый, то второй сделает все, что нужно.
А если упадет и первый и второй, ну что поделаешь, тут и третий и четвертый сервер не помогут.
Просто я не думаю, что ТС рассматривает вариант с добавлением слейв серверов. Иначе это уже серьезный кластер получается, который явно не таким образом строит свою отказоустойчивость и балансировку.
Так. А если падает третий сервер и первый, то что тогда, искать четвертый?
Нет, если падает 2 сервера из 3, то возможны только 2 варианта:
1) Произошла потеря связности. Первый сервер не обнаружил двух, а два не обнаружили первого. В этом случае активным будет тот сервер, который имеет связь с другим. Сервер, который потерял связность - теряет кворум и перестает обслуживать.
2) Действительно упали 2 сервера из 3. Тогда нужно руками восстанавливать все это дело, ибо в связке 3 сервера мы имеем право уронить только один.
Третий сервер можно взять на том же hetzner в виде их VPS - будет стоить +5$/мес, это не большие деньги.
Третий сервер можно взять на том же hetzner в виде их VPS - будет стоить +5$/мес, это не большие деньги.
Тогда алгоритм такой?
1. VPS и запасной сервер циклически делают ежесекундный опрос основного сервера (таймаут 3 секунды).
2. При ошибке (в т.ч. таймаут) запасной сервер делает дополнительную проверку доступности.
3.1. Если ошибка не повторилась - возврат к п.1.
3.2. Если ошибка повторилась - запросить последний статус проверки у VPS:
3.2.1. VPS не вернул ответ: делаем еще одну попытку, и если опять неудачная - предполагаем проблемы с сетью на запасном сервере: сервер не меняем, уведомление на мобильный /если получится, т.к. проблемы с сетью :)/ и возврат к п.1.
3.2.2. VPS вернул ответ, но результат последней проверки "без ошибки" - предполагаем проблемы с каналом между основным и запасным сервером(?): сервер не меняем, уведомление на мобильный и возврат к п.1.
3.2.3. VPS вернул ответ и результат последней проверки "ошибка": ПЕРЕКЛЮЧИТЬ сервер.
Все учел?
Тогда алгоритм такой?
Посмотрите гугл на "keepalived hetzner" - keepalived как раз сам алгоритм и реализует.
---------- Добавлено 25.03.2016 в 23:46 ----------
2. Возможна ли ситуация с ложным срабатыванием и переключением? Например, если проблемы с каналом на резервном (проверяющим) сервере. Как учесть?
Поставьте etcd на все три сервера, он выберет лидера при крахе.
---------- Добавлено 26.03.2016 в 01:40 ----------
А лучше всего поставьте HAProxy + keepalived
Посмотрите гугл на "keepalived hetzner" - keepalived как раз сам алгоритм и реализует.
Нашел только тему от 2008 года "Караул, Хетцнер перестал поддерживать высокую доступность". https://www.howtoforge.com/community/threads/hetzner-to-stop-support-for-high-availability-setups.19988/
Что ожидаемо.
Алгоритм то реализует, но с API hetzner эта обвязка не заработает.
Все эти реализации отказоустойчивости рассчитаны на работу в нормальной сети, где IP в одном локальном сегменте. А тут надо чтобы вызывалось API и ip волшебным образом переключался. Тут нужна модификация обычной схемы.
Еще, кстати, вашу тему нашел (на упавшем в данный момент сервере) http://www.pilat66.ru/proxmox-i-hetzner.html
Так что именно вы имели ввиду ?
Нашел только тему от 2008 года "Караул, Хетцнер перестал поддерживать высокую доступность". https://www.howtoforge.com/community/threads/hetzner-to-stop-support-for-high-availability-setups.19988/
Что ожидаемо.
Алгоритм то реализует, но с API hetzner эта обвязка не заработает.
Все эти реализации отказоустойчивости рассчитаны на работу в нормальной сети, где IP в одном локальном сегменте. А тут надо чтобы вызывалось API и ip волшебным образом переключался. Тут нужна модификация обычной схемы.
Еще, кстати, вашу тему нашел (на упавшем в данный момент сервере) http://www.pilat66.ru/proxmox-i-hetzner.html
Так что именно вы имели ввиду ?
Я вчера первым делом наткнулся на https://github.com/ahes/hetzner-api-failover - похоже как раз на примочку к keepalived.
За упавший сервер спасибо. Настрою монит - что-то часто стал он падать.
Поставил второй сервер и подключил Failover IP на Хетзнере.
Выполнение команды переключения занимает 24-36 секунд.
Использовал свое решение:
При недоступности в течение 10 секунд (или 5 проверок каждые 2 секунды) - идет дополнительная проверка через дополнительный внешний третий сервер (уже был у меня под другие проекты, при недоступности этого - его дублируют еще два VPS).
Т.е. максимальное время простоя менее минуты.
Назад возвращается автоматически при 10 положительных проверках подряд.
Особенность Failover IP на Хетзнере:
если на моем сервере есть дополнительные IP - на них не переключать не дает, только на основной IP сервера.