Существует ли какой-либо другой способ распределения трафика между балансировщиками нагрузки помимо DNS?

Во-первых, я уже прочитал это: Высокая доступность самих балансировщиков нагрузки

Но этот вопрос не идет достаточно далеко.

Кажется, что балансировка нагрузки DNS - это Только способ распределения трафика между балансировщиками нагрузки. (Помимо использования балансировщика нагрузки, который, очевидно, ничего не делает для распределения нагрузки, если в конце концов все это должно пройти через один сервер)

Это похоже на злоупотребление протоколом DNS. Насколько я понимаю, DNS был разработан для разрешения имен, а не для балансировки нагрузки. Что, если мне нужен более сложный алгоритм балансировки нагрузки помимо циклического перебора? Это единственный способ распределить трафик между балансировщиками нагрузки? Если это не единственный метод, то какие еще существуют методы?

Конечно, похоже, что это работает хорошо и является текущим стандартом для всех крупных компаний, верно?

Нет, DNS — не единственный способ переключения между балансировщиками нагрузки.

Учти это многоуровневый балансировщик нагрузки. Масштабируемость и отказоустойчивость.

• Уровень 7 имеет множество экземпляров, которые предоставляют прокси-сервер с поддержкой приложений для серверных частей. Завершает TCP-соединение и, возможно, TLS. HAProxy, например.
• Уровень 4 перед ним, который последовательно маршрутизирует пакеты. например, поддержка активности с помощью IPVS. Может быть даже без состояния, с подходящим согласованным алгоритмом хеширования.
• Маршрутизаторы ECMP обеспечивают избыточные пути и горизонтальное масштабирование каналов.
• И, наконец, DNS, чтобы пользователи могли искать адреса службы.

Умение возвращать результаты входит в спецификацию DNS, поэтому можно реализовать проверки работоспособности, результаты на основе географического IP-адреса и другие динамические функции. gdnsd — это авторитетный DNS-сервер, который может делать такие вещи.

Однако DNS сильно кэшируется, поэтому меняется медленно. Причудливое непоследовательное поведение клиента также делает циклический перебор DNS непрактичным.Таким образом, DNS может быть ограничен поиском входной двери, правильного региона, где расположены хосты балансировщика нагрузки. Активация среды аварийного восстановления была бы разрушительной, но изменение DNS может сократиться до совершенно отдельной инфраструктуры.

Насколько я понимаю, DNS был разработан для разрешения имен, а не для балансировки нагрузки.

Для обоих, потому что (почти) все записи могут быть установлены, следовательно, для заданного вопроса клиент может получить несколько ответов, а затем может свободно выбирать любой элемент, который он предпочитает.

Вот почему частым шаблоном является циклический выбор ответов, так что клиент выбирает «первый» элемент, но каждый раз он будет другим.

Конечно, клиент может реализовать более разумный алгоритм, особенно для перехода на IPv6 с А и АААА записи, см. RFC 8305 «Happy Eyeballs Version 2: Better Connectivity Using Concurrency», но это больше не балансировка нагрузки.

Так что все зависит от того, какой объем «интеллекта» есть на стороне клиента.

СРВ записи позволяют кодировать как приоритет (отказоустойчивость), так и вес (балансировка нагрузки) для потенциально любого протокола через TCP или UDP, и позволяет больше не жестко кодировать номера портов. К сожалению, браузеры так и не реализовали его. Более новая итерация СВЦБ и HTTPS записи, которые позволяют отчасти то же самое.

Обратите внимание на это на самом деле в текущем черновике:

Записи SRV указывают «вес» для несбалансированной рандомизированной балансировки нагрузки. SVCB поддерживает только сбалансированную рандомизированную балансировку нагрузки, хотя веса могут быть добавлены через будущий SvcParam.

Следующий:

Что, если мне нужен более сложный алгоритм балансировки нагрузки помимо циклического перебора?

Сегодня это означает СРВ записи и некоторый интеллект в приложении (на стороне клиента). Или более умный сервер имен, который изменяет свои ответы в зависимости от внешнего динамического фактора (например, того, что делают CDN).

Основная проблема, с которой сталкивается балансировка нагрузки на уровне DNS, связана с TTL, а также потому, что некоторые резолверы не будут подчиняться слишком маленьким значениям для него.

Вы также должны помнить, что авторитетный сервер имен, у которого есть данные, видит только рекурсивный сервер имен, который клиент использует большую часть времени, а не сам клиент. Так что его выбор ограничен еще и этим.

Самое простое решение в DNS — это просто установить несколько записей одного типа с разными значениями и заставить ваш сервер имен возвращать их все клиентам, когда они запрашивают эту запись ресурса.
Эффект от этого обычно называют циклический DNS и хотя он имеет несколько недостатков, он хорошо поддерживается как DNS-серверами, так и клиентами. Проблемы с использованием этого метода, вероятно, относятся ко всем решениям балансировки нагрузки DNS.

В дополнении к ответ Патрика некоторые DNS-серверы имеют встроенные или прикрученные дополнительные интеллектуальные возможности. Вместо того, чтобы возвращать полный набор всех записей, ответ настраивается. Некоторые алгоритмы:

• Проверка работоспособности может обеспечить отработку отказа, удалив в ответе записи об отказавших узлах и/или используя вместо этого записи резервных серверов.

• Некоторые серверы имен имеют реализацию для предоставления различных наборов информации DNS, обычно выбираемых по исходному адресу DNS-запроса.

  • Более тривиальный вариант использования того, что вызывается, обычно "расщепленный DNS" где запрос от клиентов в кампусе или в корпоративной сети вызовет другой ответ по сравнению с другими.
  • Более продвинутый вариант использования будет "Геоднс" или похожие. Например, веб-сайт может иметь 2 сервера (или кластера за IP-адресом балансировщика нагрузки), один из которых находится во Франции, а другой — в США.С помощью GeoDNS можно создать DNS-запись, для которой клиенты из Европы получат IP-адрес французского сервера, а клиенты из США — американский.

Но помимо решений на основе DNS существует множество других подходов.

• "Любая передача" где один IP-адрес назначения совместно используется серверами/балансировщиками нагрузки в нескольких местах, а маршрутизаторы направляют пакеты, адресованные этому месту назначения, в место, ближайшее к отправителю.

• встроенная логика в приложениях с обнаружением служб и отказоустойчивостью