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