Amazon route 53 с ha-proxy

Question

Я использую маршрут амазонки 53 для маршрутизации запроса DNS на балансировщик нагрузки. Для балансировки нагрузки я использую ha-proxy load balancer route 53, который направляет запрос на ha-proxy.

Здесь, на маршруте 53, я дал вес 33.33% трем балансирам нагрузки. Предположим, когда клиент отправляет запрос на маршрут 53, проложите запрос на первый сервер ha-proxy и установили соединение tcp.

Вопрос в том, когда клиент делает второй запрос, куда он идет? Возможно ли, что второй запрос отправляется на первый сервер, на котором установлено соединение tcp?

Существует три сервера, указанные в изображении, а также есть маршрут-53 клиент делает запрос на га-прокси с использованием маршрута-53 DNS взвешенным.

Answer 1

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

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

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

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

Сценарий:

У вас есть несколько HAproxy серверов, режим TCP, оканчивающиеся TLS и балансировочные запросы к фоновым серверам с помощью leastconn так, что внутренний сервер с наименьшим числом подключений получит следующий входящий подключение.

Анализ:

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

Обоснование:

Это не имеет значения, какой прокси-клиент подключается к. Возврат всех адресов возвращает их в случайном порядке, и клиент будет произвольно использовать один.

Каждый прокси-сервер сохраняет свой собственный счет количества подключений к каждому внутреннему контенту и всегда будет отправлять соединения в зависимости от того, какой из задних концов имеет наименьшее количество соединений с его точки зрения. Он не должен знать о количестве подключений, принадлежащих другим прокси, потому что каждый прокси независимо гарантирует, что одинаковое количество соединений отправляется на каждый серверный сервер. Таким образом, при максимальном спросе количество подключений, отправленных каждому серверному серверу каждым прокси-сервером, будет одинаковым, +/- 1, в пределах каждого прокси-сервера и идентичным между прокси-серверами, подчиненными только случайности DNS ...и дисбаланс на лицевой стороне отменяет себя, потому что, если один IP-адрес получает больше трафика, чем другие, это означает только количество подключений к . Все обратные ссылки из этого прокси-сервера превышают число других, но независимо от этого числа, он будет +/- 1 при максимальной нагрузке - и распределение при максимальной нагрузке должно быть единственной реальной проблемой, которую вы испытываете.

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