Мы пытаемся выполнить довольно простую настройку на Amazon EC2 - несколько HTTP-серверов находятся за Amazon Elastic Load Balancer (ELB).

Наш домен управляется в Route53, и у нас есть запись CNAME, настроенная для указания на ELB.

У нас возникли некоторые проблемы, когда некоторые (но не все) местоположения периодически не могут подключиться к балансировщику нагрузки; кажется, что это может быть разрешением доменного имени ELB.

Служба поддержки Amazon сообщила нам, что базовый Elastic IP балансировщика нагрузки изменился, и проблема в том, что DNS-серверы некоторых интернет-провайдеров не соблюдают TTL. Мы не удовлетворены этим объяснением, потому что мы повторили проблему, используя собственные DNS-серверы Amazon из экземпляра EC2, а также локальных интернет-провайдеров в Австралии и через DNS-сервер Google ( 8.8.8.8).

Amazon также подтвердил, что в период, когда мы замечали время простоя из некоторых мест, трафик, проходящий через ELB, значительно снизился - поэтому проблема не в наших конечных точках.

Интересно, что домен, по-видимому, разрешает правильный IP-адрес на серверах, которые не могут подключиться, но попытка установить соединение TCP не удалась.

Все экземпляры, прикрепленные к ELB, всегда были здоровыми. Они все

Кто-нибудь знает, как мы можем диагностировать эту проблему более глубоко? Кто-нибудь еще испытывал эту проблему с Elastic Load Balancer?

Благодарность,

Во время поиска в Google я нашел этот вопрос о том, как диагностировать Amazon Elastic Load Balancers (ELB), и я хочу ответить на него всем, кто, как я, столкнулся с этой проблемой без особых указаний.

ELB Properties

У ELB есть некоторые интересные свойства. Например:

• ELB состоят из 1 или более узлов
• Эти узлы публикуются как записи A для имени ELB
• Эти узлы могут выйти из строя или быть закрыты, и соединения не будут закрыты изящно
• Часто требуется хорошая связь с поддержкой Amazon ($$$), чтобы кто-то мог разобраться с проблемами ELB

ПРИМЕЧАНИЕ. Еще одно интересное свойство, но чуть менее уместное, заключается в том, что ELB не были предназначены для обработки внезапных всплесков трафика. Как правило, им требуется 15 минут интенсивного трафика, прежде чем они будут расширяться, или они могут быть предварительно подогреты по запросу через билет поддержки

Устранение неполадок ELB (вручную)

Обновление: с тех пор AWS перенес все ELB для использования маршрута 53 для DNS. Кроме того, все ELB теперь имеют all.$elb_nameзапись, которая будет возвращать полный список узлов для ELB. Например, если ваше имя ELB elb-123456789.us-east-1.elb.amazonaws.com, то вы получите полный список узлов, выполнив что-то вроде dig all.elb-123456789.us-east-1.elb.amazonaws.com. Для узлов IPv6 all.ipv6.$elb_nameтоже работает. Кроме того, Маршрут 53 может возвращать до 4 КБ данных, все еще используя UDP, поэтому использование +tcpфлага может быть необязательным.

Зная это, вы можете сделать небольшое устранение неполадок самостоятельно. Сначала разрешите имя ELB в список узлов (как записи A):

$ dig @ns-942.amazon.com +tcp elb-123456789.us-east-1.elb.amazonaws.com ANY

Этот tcpфлаг предлагается, поскольку ваш ELB может иметь слишком много записей, чтобы поместиться внутри одного пакета UDP. Мне также сказали, но я лично не подтвердил, что Amazon покажет только 6 узлов, если вы не выполните ANYзапрос. Выполнение этой команды даст вам вывод, который выглядит примерно так (обрезано для краткости):

;; ANSWER SECTION:
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN SOA ns-942.amazon.com. root.amazon.com. 1376719867 3600 900 7776000 60
elb-123456789.us-east-1.elb.amazonaws.com. 600 IN NS ns-942.amazon.com.
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN A 54.243.63.96
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN A 23.21.73.53

Теперь для каждой Aзаписи используйте, например, curlдля проверки соединения с ELB. Конечно, вы также хотите изолировать свой тест только от ELB без подключения к бэкэндам. Последнее свойство и малоизвестный факт об элементах ELB:

• Максимальный размер метода запроса (глагола), который может быть отправлен через ELB, составляет 127 символов . Если больше, то ELB ответит HTTP 405 - Метод не разрешен .

Это означает, что мы можем использовать это поведение для проверки только того, что ELB отвечает:

$ curl -X $(python -c 'print "A" * 128') -i http://ip.of.individual.node
HTTP/1.1 405 METHOD_NOT_ALLOWED
Content-Length: 0
Connection: Close

Если вы видите, HTTP/1.1 405 METHOD_NOT_ALLOWEDто ELB отвечает успешно. Вы также можете настроить тайм-ауты curl на приемлемые для вас значения.

Устранение неполадок ELB с использованием elbping

Конечно, делать это может быть довольно утомительно, поэтому я создал инструмент для автоматизации, который называется elbping . Он доступен как рубиновый драгоценный камень, поэтому, если у вас есть rubygems, вы можете установить его, просто выполнив:

$ gem install elbping

Теперь вы можете запустить:

$ elbping -c 4 http://elb-123456789.us-east-1.elb.amazonaws.com
Response from 54.243.63.96: code=405 time=210 ms
Response from 23.21.73.53: code=405 time=189 ms
Response from 54.243.63.96: code=405 time=191 ms
Response from 23.21.73.53: code=405 time=188 ms
Response from 54.243.63.96: code=405 time=190 ms
Response from 23.21.73.53: code=405 time=192 ms
Response from 54.243.63.96: code=405 time=187 ms
Response from 23.21.73.53: code=405 time=189 ms
--- 54.243.63.96 statistics ---
4 requests, 4 responses, 0% loss
min/avg/max = 187/163/210 ms
--- 23.21.73.53 statistics ---
4 requests, 4 responses, 0% loss
min/avg/max = 188/189/192 ms
--- total statistics ---
8 requests, 8 responses, 0% loss
min/avg/max = 188/189/192 ms

Помните, если вы видите, code=405это означает, что ELB отвечает.

Следующие шаги

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

Надеюсь это поможет!

Исправление на самом деле простое: используйте Aзапись, а не CNAMEв Route53.

В консоли управления AWS выберите «Запись», а затем установите переключатель «Псевдоним» на «Да». Затем выберите свой ELB из выпадающего меню.

Есть несколько потенциальных решений, которые вы можете попробовать на этом форуме разработчиков AWS. https://forums.aws.amazon.com/message.jspa?messageID=387552 .

Например:

потенциальное решение № 1

У нас была похожая проблема, когда мы перешли на ELB, мы решили эту проблему, сократив имя нашего ELB до одного символа. Даже двухсимвольное имя для ELB вызывало случайные проблемы с сетевыми решениями DNS-разрешений.

DNS-имя вашего ELB должно быть примерно таким -> X. <9chars> .us-east-1.elb.amazonaws.com

потенциальное решение № 2

Я оригинальный постер. Спасибо за все ответы. Мы смогли уменьшить частоту, с которой у нас возникали проблемы с DNS, установив очень высокий TTL (чтобы они кэшировались серверами, не входящими в Network Solutions). Однако у нас все еще было достаточно проблем, и мы просто не могли больше оставаться с Network Solutions. Мы думали о переходе на UltraDNS, основываясь на хороших отчетах об услуге, но казалось, что Маршрут 53 (который использует UltraDNS под прикрытием) будет для нас дешевле. После перехода на маршрут 53 у нас больше нет проблем с DNS, и наши имена ELB также могут быть хорошими и длинными.

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