Я не очень разбираюсь в администрировании DNS и т. Д., Но знаю о передовых методах программирования приложений.
В настоящее время в моей компании имеется 6 серверов с соответствующими названиями:
Это хорошо.
Однако системный администратор попросил нас обработать эти случайные конечные точки в нашем приложении, это означает, что нам нужно случайным образом выбрать сервер из этого списка.
Мне это выглядит плохо, потому что всякий раз, когда нам нужно добавить сервер, нам нужно отредактировать наше приложение (даже если это просто файл конфигурации), но я думаю, что приложение не должно знать о таких вещах, подобно тому, как объект не должен знать о постоянный сервер.
Я хочу использовать балансировку нагрузки DNS, один домен, указывающий на другой IP
Одна конечная точка: mobile.domain.com
Системный администратор сказал мне, что это плохо или что-то в этом роде, но я убежден, что это лучшее решение, более того, оно позволит позже балансировать нагрузку с помощью геолокации, и это здорово. Между прочим, случайный выбор сервера из списка не помешает серверу отключиться, поскольку случайное значение просто не случайное и не выглядит эффективным для меня.
Спасибо за отзыв, если у вас есть аргументы за и против, я могу использовать :)
Думаю, ваш системный администратор пытался сказать, что использование DNS для балансировки нагрузки неплохо, но неудобно. Вы можете добавить 6 IP в DNS для определенного домена, но становится сложно управлять кластером. Если вы хотите вывести одну из машин из ротации, вам придется отредактировать свою DNS-запись и дождаться ее распространения. С этим можно справиться, установив более низкий TTL, но вы не можете учитывать какие-либо промежуточные преобразователи, которые не следуют протоколу DNS.
Удобнее иметь балансировщик нагрузки и указывать домен на LB и 6 серверов за ним. Это позволяет добавлять / удалять серверы, потому что вам не нужно беспокоиться о времени распространения DNS.
Циклический перебор DNS обычно считается очень недорогим решением для балансировки нагрузки. Это правда, что это требует ручного изменения DNS в случае недоступности сервера. Также верно и то, что вашим изменениям DNS требуется время для распространения (и это зависит от промежуточных преобразователей).
С другой стороны, это очень дешево по сравнению со стоимостью надлежащего балансировщика нагрузки. Есть еще вопрос сложности. Существуют решения с открытым исходным кодом для балансировки нагрузки, но их непросто настроить, и если что-то пойдет не так, вам (или вашим системным администраторам) необходимо иметь опыт, чтобы исправить это. Обновление зоны DNS - сравнительно простое дело.
Если у вас нет ситуации, когда доступность службы является абсолютно важной или невыполнение запросов (из-за задержек DNS) приводит к серьезной потере дохода, лучшим выбором будет циклический перебор DNS.
Чтобы ответить на вопрос о том, какая балансировка нагрузки вам нужна, вам необходимо установить стоимость невыполненных запросов.
В любом случае, внесение изменений в приложение, будь то код или файлы конфигурации, не является хорошей идеей, поскольку это приводит к еще большим задержкам (при распространении изменений приложения).
В то время как то, что Самир и Вольфгангз говорят, верно для кругового алгоритма, они недооценили проблемы с что это действительно бесполезный механизм, и пропустил несколько проблем, которые вызовут у вас неприятности, включая кеширование DNS-клиента и DNS-прокси, а также отсутствие гарантий сохранения порядка на пути от DNS-сервера контента к DNS-клиенту.
Как уже упоминалось, SRV записи ресурсов решают все эти проблемы. Вы получаете приоритет и взвешивание, что кеширование в прокси DNS серверах не разрушает. С ними администраторы могут делать то, что вы, вероятно, захотите сделать в будущем, например, настраивать резервные и основные группы серверов, указывать порядок отката и контролировать веса в рамках одной группы серверов. Написание клиентского кода для выбора сервера для разговора с использованием заданных весов и приоритетов также не представляет особой сложности.
В зависимости от того, кто будет использовать ваши приложения, только вы или мир в целом, вам, возможно, придется зарегистрировать имя своего протокола (используется в SRV доменные имена записей ресурсов) с реестрами, такими как вот этот. Как видите, у других уже есть.
Как также сказал Самир, настоящий балансировщик нагрузки - еще одна, также предпочтительная альтернатива бесполезному циклическому перестановке.