Мы пытаемся запустить довольно простую настройку на Amazon EC2 - несколько HTTP-серверов, стоящих за Amazon Elastic Load Balancer (ELB).
Наш домен управляется в Route53, и у нас настроена запись CNAME, указывающая на ELB.
Мы столкнулись с некоторыми проблемами, когда некоторые (но не все) местоположения периодически не могли подключиться к балансировщику нагрузки; похоже, что это может быть разрешение доменного имени ELB.
Служба поддержки Amazon сообщила нам, что основной эластичный 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 обладают некоторыми интересными свойствами. Например:
ПРИМЕЧАНИЕ. Еще одно интересное свойство, но немного менее актуальное, заключается в том, что ELB не предназначены для обработки внезапных всплесков трафика. Обычно им требуется 15 минут интенсивного трафика, прежде чем они будут расширяться, или их можно предварительно подогреть по запросу через тикет поддержки
Обновить: С тех пор AWS переместила все ELB на использование Route 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 тоже работает. Кроме того, Route 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 отвечает:
$ 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 на приемлемые для вас значения.
Конечно, это может быть довольно утомительно, поэтому я создал инструмент для автоматизации, который называется эльбинг. Он доступен как рубиновый драгоценный камень, поэтому, если у вас есть 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 выберите «Запись A», а затем переместите переключатель «Псевдоним» в положение «Да». Затем выберите свой ELB из раскрывающегося меню.
На этом форуме разработчиков AWS есть несколько потенциальных решений. https://forums.aws.amazon.com/message.jspa?messageID=387552.
Например:
У нас была аналогичная проблема, когда мы перешли на ELB, мы решили ее, сократив имя нашего ELB до одного символа. Даже имя из двух символов для ELB вызывало случайные проблемы с разрешениями DNS сетевых решений.
DNS-имя вашего ELB должно иметь вид -> X. <9chars> .us-east-1.elb.amazonaws.com
Я оригинальный плакат. Спасибо за все ответы. Мы смогли снизить частоту возникновения проблем с DNS, установив очень высокий TTL (чтобы они кэшировались серверами, не относящимися к сетевым решениям). Однако у нас по-прежнему было достаточно проблем, из-за которых мы просто не могли больше оставаться с Network Solutions. Мы думали о переходе на UltraDNS на основании хороших отчетов о сервисе, но похоже, что Route 53 (который, по-видимому, использует UltraDNS под прикрытием) будет для нас дешевле. После перехода на Route 53 у нас больше нет проблем с DNS, и наши ELB-имена тоже могут быть красивыми и длинными.
В этом посте можно было попробовать и другие вещи, но, похоже, это лучшие зацепки.