Проблеми з DNS-сервером EC2 Elastic Load Balancer і маршрутизацією


19

Ми намагаємося виконати досить просту настройку на 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-з'єднання не вдається.

Всі випадки, приєднані до ЕЛБ, були здоровими в усі часи. Вони всі

Хтось знає, як ми могли б піти на діагностику цієї проблеми глибше? Хто-небудь ще відчував цю проблему з еластичним балансиром навантаження?

Спасибі,


Я хочу додати ще одне зауваження - незважаючи на те, що, здавалося б, потенційно пов'язане з DNS або маршрутизацією, наскільки ми можемо сказати, наш домен завжди вирішує правильний EIP - запуск hostутиліти вирішує ту саму адресу в системах, де ми можемо підключитися, і системах, де ми не можемо.
Цера

Відповіді:


21

Я знайшов це питання під час Гуглінга щодо того, як діагностувати Amazon Elastic Balancers Balancers (ELBs), і я хочу відповісти на нього для всіх інших, як я, у кого виникли ці проблеми без особливих рекомендацій.

Властивості ELB

ELB мають деякі цікаві властивості. Наприклад:

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

ПРИМІТКА. Ще одна цікава властивість, але дещо менш доречна - це те, що ELB не були розроблені для управління раптовими скачками трафіку. Зазвичай вони вимагають 15 хвилин великого руху, перш ніж вони збільшаться, або їх можна попередньо підігріти за запитом за допомогою квитка на підтримку

Виправлення неполадок вручну (вручну)

Оновлення: 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_ALLOWEDELB реагує успішно. Можливо, ви також хочете налаштувати тайм-аути завивки на прийнятні для вас значення.

Усунення несправностей з ELB за допомогою пальців

Звичайно, це може стати досить стомлюючим, тому я створив інструмент для автоматизації цього під назвою зіскочити . Він доступний як дорогоцінний камінь, тому якщо у вас є рубіггеми, його можна встановити, просто виконавши:

$ 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 досить розумним випадком, коли щось не так.

Сподіваюся, це допомагає!


1
Дякую за чудову відповідь. Ми спочатку з'ясували більшу частину цього через спроби та помилки, але це буде зручною посиланням.
Цера

7

Виправлення насправді просте: Використовуйте Aзапис, а не CNAMEв Route53.

На консолі управління AWS виберіть "Запис", а потім перемістіть перемикач із написом "Псевдонім" на "Так". Потім виберіть свій ELB зі спадного меню.


1
Я не розумію обґрунтування цього виправлення. Документація Amazon для ELB спеціально говорить, що CNAMEслід використовувати запис. Яка була б користь від Aзапису / що тут змінюється?
Цера

3
Вам потрібно буде використовувати CNAME, якщо ваш DNS розміщувався в іншому місці, ніж Route53. Але псевдонім запису - це особливість, характерна для Route53 і призначена для вирішення точної проблеми, з якою ви стикаєтесь. Документи Route53 пояснюють це в більшій глибині.
jamieb

@jamieb Чи можете ви надати посилання на цей документ?
До

1
Він називається "Псевдонім Цілі" на відміну від запису A. docs.aws.amazon.com/Route53/latest/DeveloperGuide/…
Jonny07

0

На цьому форумі для розробників 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 дуже високою (щоб вони кешувались серверами немережевих рішень). Однак у нас все ще виникало достатньо проблем, коли ми просто не могли більше залишатися з мережевими рішеннями. Ми думали перейти до UltraDNS на основі хороших звітів про сервіс, але виглядало так, що Route 53 (який використовує UltraDNS під обкладинками, здається) буде для нас дешевшим. З часу переходу на маршрут 53 у нас більше немає проблем з DNS, і наші імена ELB можуть бути приємними і довгими.

На цій посаді можна було спробувати і інші речі, але, здається, найкращі результати.


Дякуємо за пропозиції. На жаль, здається, що проблема полягає лише в дозволі DNS імені хоста для ELB, а не в нашому записі, який його псевдоніми. Наш запис завжди відповідає правильному імені хоста ELB.
Цера

Чи вирішила проблему вирішення проблеми @ jaimieb?
slm

Якщо я правильно вас зрозумів, проблема полягає в тому, що у вас є записи CNAME / ANAME, які вирішуються для запису CNAME / ANAME ELB, і ваша частина вирішує просто чудово, жодних проблем з продуктивністю, але як тільки ви потрапите в DNS ELNS записує проблеми з продуктивністю. з’явитися?
slm

@slm - потенційне виправлення №1 не допомагає. Я рекомендую зняти його з посади.
Урсус
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.