У меня есть ситуация, когда у нас есть сервер в удаленном месте. Его подключение к Интернету (например, по ip 1.1.1.1) может быть нестабильным, поэтому у нас есть резервное соединение от другого провайдера (скажем, через ip 2.2.2.2). Первый провайдер намного более экономичен, но когда он выйдет из строя, мы хотели бы подключиться к этому серверу через второго провайдера, который будет взимать плату за использование полосы пропускания. Второй провайдер намного надежнее, но намного дороже.
Мне нужна DNS-запись для удаленного сервера, которая обычно указывает на 1.1.1.1, но может быть изменена на 2.2.2.2 в качестве альтернативы, когда соединение не работает, или каким-либо другим способом направить клиентов в городе на этот удаленный сервер, который идет через любое соединение надежно и незаметно для клиента.
Как я могу подойти к этому?
Кажется, что это можно решить на уровне DNS, но не с помощью какой-либо известной мне технологии. Что еще может сработать?
Мне нужна DNS-запись для удаленного сервера, которая обычно указывает на 1.1.1.1, но может быть изменена на 2.2.2.2 в качестве альтернативы, когда соединение не работает.
Нет, вам нужно средство для соединения двух соединений. Однако это система агрегации входящих каналов, которая обрабатывается маршрутами BGP на каждом отдельном ISP. Я не знаю, как поставить одну точку над другой, однако я не являюсь беспрецедентным экспертом в этой точной схеме. Для меня не будет ничего удивительного, если у ненадежного интернет-провайдера возникнут некоторые обходные маневры относительно рекламы маршрутов BGP, которые позволяют иметь один IP-адрес, который, по сути, перемещается между двумя соединениями.
Это не та проблема, которую DNS может решить (легко или надежно *). Пусть DNS будет DNS, который представляет собой простую систему хранения и поиска информации о парах ключ-значение. И прежде чем вы спросите, Round robin вам тоже не поможет. знак равно
* Хорошо, хорошо, да, вы можете делать некоторые вещи, отдаленно напоминающие балансировку входящих ссылок с помощью DNS. Это зло и включает в себя задержки распространения как часть вашего SLA, а также полагается на администраторов DNS, чтобы не вмешиваться в значения TTL ваших записей, что не является безопасной ставкой. Я даже не собираюсь объяснять здесь отказоустойчивость DNS (или, как я называю это «искусственное переключение DNS»), потому что я не думаю, что это особенно надежно / профессионально, но я свяжусь с ним, и если ссылка умирает для людей в будущее, нет никакого вреда, потому что ... это зло. НЕ ГОВОРИТЕ, Я НЕ ПРЕДУПРЕЖДАЛ ВАС.
Создайте имя хоста для этой службы. Иметь запись A для этого имени хоста, указывающую на 1.1.1.1. Создайте запись SOA, определяющую очень короткие времена TTL, обновления и истечения срока действия, чтобы изменения в записи A вносились быстро.
Наблюдайте за основной ссылкой и, если она не работает, публикуйте новую запись A, указывающую на 2.2.2.2.
В качестве более продвинутой версии этого решения используйте инструмент мониторинга, чтобы отслеживать две ссылки и автоматически менять местами соответствующую запись DNS в зависимости от стабильности сервера.
Как это работает, зависит от технологического стека, используемого в вашем DNS-сервере, но если вы используете свой DNS на сервере Unix или Linux, вы можете использовать инструмент мониторинга, такой как Nagios, для обмена файлами зон на основе результатов сценария мониторинга.
Мое предложение - автоматическое переключение DNS при отказе. Таким образом, вы можете отправлять трафик в любой центр обработки данных, в который вы хотите его отправить, и если по какой-либо причине (проблема с сетью или сбой HW) вы автоматически переключитесь на другой центр обработки данных. Ты можешь видеть http://www.dnsmadeeasy.com/services/dns-failover-system-monitoring/ Например.
Вы всегда можете выполнить аварийное переключение DNS, но на самом деле вам следует выполнить некоторую балансировку нагрузки нижестоящего уровня. Восстановление после сбоя рискованно, и это не совсем то, для чего был разработан DNS. По мере распространения нового адреса будет определенное время простоя. И вам понадобится сервер, который просто бездействует.
Если вы реализовали какую-то балансировку нагрузки, тогда оба сервера могли бы обслуживать трафик, и в случае отказа одного из них трафик автоматически перешел бы на другой.