Các vấn đề với DNS và định tuyến cân bằng tải EC2


19

Chúng tôi đang cố gắng chạy một thiết lập khá đơn giản trên Amazon EC2 - một số máy chủ HTTP ngồi sau Bộ cân bằng tải đàn hồi của Amazon (ELB).

Tên miền của chúng tôi được quản lý trong Route53 và chúng tôi có một bản ghi CNAME được thiết lập để trỏ đến ELB.

Chúng tôi đã gặp một số vấn đề trong đó một số - nhưng không phải tất cả - các vị trí không liên tục không thể kết nối với bộ cân bằng tải; có vẻ như đây có thể là độ phân giải của tên miền của ELB.

Bộ phận hỗ trợ của Amazon đã khuyên chúng tôi rằng IP đàn hồi cơ bản của bộ cân bằng tải đã thay đổi và vấn đề là các máy chủ DNS của một số ISP không tôn trọng TTL. Chúng tôi không hài lòng với lời giải thích này, vì chúng tôi đã sao chép vấn đề bằng cách sử dụng các máy chủ DNS của Amazon từ một phiên bản EC2, cũng như trên các ISP địa phương ở Úc và thông qua máy chủ DNS của Google ( 8.8.8.8).

Amazon cũng xác nhận rằng trong khoảng thời gian chúng tôi nhận thấy thời gian từ một số địa điểm, lưu lượng truy cập đi qua ELB đã giảm đáng kể - vì vậy vấn đề không nằm ở điểm cuối của chúng tôi.

Thật thú vị, tên miền dường như phân giải đúng IP trên các máy chủ không thể kết nối - nhưng nỗ lực thiết lập kết nối TCP không thành công.

Tất cả các trường hợp gắn liền với ELB luôn khỏe mạnh. Tất cả bọn họ

Có ai biết làm thế nào chúng ta có thể đi về chẩn đoán vấn đề này sâu sắc hơn? Có ai khác gặp vấn đề này với Bộ cân bằng tải đàn hồi không?

Cảm ơn,


Tôi nên thêm vào như một lưu ý khác - mặc dù điều này dường như có khả năng liên quan đến DNS hoặc định tuyến, theo như chúng tôi có thể nói rằng miền của chúng tôi luôn giải quyết đúng EIP - chạy hosttiện ích phân giải đến cùng một địa chỉ trên các hệ thống nơi chúng tôi có thể kết nối và hệ thống chúng ta không thể
Cera

Câu trả lời:


21

Tôi đã tìm thấy câu hỏi này trong khi Googling về cách chẩn đoán Cân bằng tải đàn hồi của Amazon (ELBs) và tôi muốn trả lời nó cho bất kỳ ai khác như tôi đã gặp rắc rối này mà không cần hướng dẫn nhiều.

Thuộc tính ELB

ELB có một số tính chất thú vị. Ví dụ:

  • ELB được tạo thành từ 1 hoặc nhiều nút
  • Các nút này được xuất bản dưới dạng bản ghi A cho tên ELB
  • Các nút này có thể bị lỗi hoặc bị tắt và các kết nối sẽ không được đóng một cách duyên dáng
  • Nó thường đòi hỏi một mối quan hệ tốt với sự hỗ trợ của Amazon ($$$) để khiến ai đó đào sâu vào các vấn đề ELB

LƯU Ý: Một thuộc tính thú vị khác nhưng ít phù hợp hơn một chút là ELB không được thiết kế để xử lý lưu lượng truy cập đột ngột. Họ thường yêu cầu 15 phút lưu lượng truy cập lớn trước khi họ tăng quy mô hoặc họ có thể được làm ấm trước theo yêu cầu thông qua một vé hỗ trợ

Xử lý sự cố ELBs (thủ công)

Cập nhật: AWS đã di chuyển tất cả ELB để sử dụng Tuyến 53 cho DNS. Ngoài ra, tất cả các ELB hiện có một all.$elb_namebản ghi sẽ trả về danh sách đầy đủ các nút cho ELB. Ví dụ: nếu tên ELB của bạn là elb-123456789.us-east-1.elb.amazonaws.com, thì bạn sẽ có được danh sách đầy đủ các nút bằng cách thực hiện một cái gì đó như dig all.elb-123456789.us-east-1.elb.amazonaws.com. Đối với các nút IPv6, all.ipv6.$elb_namecũng hoạt động. Ngoài ra, Tuyến 53 có thể trả về tối đa 4KB dữ liệu vẫn sử dụng UDP, do đó sử dụng +tcpcờ có thể không cần thiết.

Biết điều này, bạn có thể tự mình khắc phục một chút sự cố. Đầu tiên, phân giải tên ELB thành danh sách các nút (dưới dạng bản ghi A):

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

Các tcpcờ được đề nghị như ELB của bạn có thể có quá nhiều hồ sơ để bên trong phù hợp của một gói tin UDP duy nhất. Tôi cũng đã nói, nhưng cá nhân tôi chưa xác nhận rằng Amazon sẽ chỉ hiển thị tối đa 6 nút trừ khi bạn thực hiện ANYtruy vấn. Chạy lệnh này sẽ cung cấp cho bạn đầu ra trông giống như thế này (được cắt bớt cho ngắn gọn):

;; 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

Bây giờ, đối với mỗi Abản ghi, hãy sử dụng, ví dụ curlđể kiểm tra kết nối với ELB. Tất nhiên, bạn cũng muốn tách bài kiểm tra của mình thành ELB mà không kết nối với phần phụ trợ của bạn. Một tài sản cuối cùng và thực tế ít được biết đến về ELBs:

  • Kích thước tối đa của phương thức yêu cầu (động từ) có thể được gửi qua ELB là 127 ký tự . Bất kỳ lớn hơn và ELB sẽ trả lời bằng HTTP 405 - Phương pháp không được phép .

Điều này có nghĩa là chúng ta có thể lợi dụng hành vi này để chỉ kiểm tra ELB đang phản hồi:

$ 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

Nếu bạn thấy HTTP/1.1 405 METHOD_NOT_ALLOWEDthì ELB đang phản hồi thành công. Bạn cũng có thể muốn điều chỉnh thời gian chờ của curl thành các giá trị được bạn chấp nhận.

Khắc phục sự cố ELBs bằng cách sử dụng elbping

Tất nhiên, làm điều này có thể trở nên khá tẻ nhạt vì vậy tôi đã xây dựng một công cụ để tự động hóa cái gọi là elbping này . Nó có sẵn như một viên đá quý ruby, vì vậy nếu bạn có rubygems thì bạn có thể cài đặt nó bằng cách thực hiện đơn giản:

$ gem install elbping

Bây giờ bạn có thể chạy:

$ 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

Hãy nhớ rằng, nếu bạn thấy code=405thì điều đó có nghĩa là ELB đang phản hồi.

Bước tiếp theo

Dù bạn chọn phương pháp nào, ít nhất bạn cũng sẽ biết các nút ELB của mình có phản hồi hay không. Được trang bị kiến ​​thức này, bạn có thể chuyển sự tập trung của mình sang xử lý sự cố các phần khác trong ngăn xếp của bạn hoặc có thể đưa ra một trường hợp khá hợp lý để AWS biết rằng có điều gì đó không ổn.

Hi vọng điêu nay co ich!


1
Cảm ơn câu trả lời tuyệt vời. Ban đầu chúng tôi đã tìm ra hầu hết điều này thông qua thử nghiệm và lỗi, nhưng đây sẽ là một tài liệu tham khảo hữu ích.
Cera

7

Cách khắc phục thực sự đơn giản: Sử dụng Abản ghi thay vì CNAMEtrong Route53.

Trong Bảng điều khiển quản lý AWS, chọn "Bản ghi" và sau đó di chuyển nút radio có nhãn "Bí danh" thành "Có". Sau đó chọn ELB của bạn từ menu thả xuống.


1
Tôi không hiểu lý do căn bản đằng sau sửa chữa này. Tài liệu của Amazon cho ELB đặc biệt nói rằng CNAMEnên sử dụng một bản ghi. Điều gì sẽ là lợi ích của một Ahồ sơ / những gì đang thay đổi ở đây?
Cera

3
Bạn sẽ phải sử dụng CNAME nếu DNS của bạn được lưu trữ ở một nơi khác ngoài Route53. Nhưng bí danh kỷ lục là một tính năng dành riêng cho Route53 và nhằm giải quyết vấn đề chính xác mà bạn gặp phải. Các tài liệu Route53 giải thích nó sâu hơn.
jamieb

@jamieb Bạn có thể cung cấp một liên kết đến phần tài liệu đó không?
Đến

1
Nó được gọi là "Mục tiêu bí danh" trái ngược với bản ghi A. docs.aws.amazon.com/Route53/latest/DeveloperGuide/ Kẻ
Jonny07

0

Có một số giải pháp tiềm năng bạn có thể thử trong diễn đàn nhà phát triển AWS này. https://forums.aws.amazon.com/message.jspa?messageID=387552 .

Ví dụ:

sửa chữa tiềm năng # 1

Chúng tôi đã gặp một vấn đề tương tự khi chúng tôi chuyển đến ELB, chúng tôi đã giải quyết vấn đề này bằng cách giảm tên ELB của chúng tôi thành một ký tự. Ngay cả tên 2 char cho ELB cũng gây ra sự cố ngẫu nhiên với độ phân giải DNS của giải pháp mạng.

Tên DNS của ELB của bạn phải giống như -> X. <9chars> .us-winter-1.elb.amazonaws.com

sửa chữa tiềm năng # 2

Tôi là người đăng tải ban đầu. Cảm ơn vì tất cả những phản hồi. Chúng tôi đã có thể giảm tần suất mà chúng tôi gặp phải sự cố DNS bằng cách đặt TTL ở mức rất cao (do đó chúng sẽ được lưu trữ bởi các máy chủ không phải là Giải pháp Mạng). Tuy nhiên, chúng tôi vẫn nhận được đủ các vấn đề khi chúng tôi không thể ở lại với Giải pháp Mạng nữa. Chúng tôi đã nghĩ đến việc chuyển sang UltraDNS dựa trên các báo cáo tốt về dịch vụ, nhưng có vẻ như Tuyến 53 (sử dụng UltraDNS dưới vỏ bọc, nó sẽ xuất hiện) sẽ rẻ hơn đối với chúng tôi. Kể từ khi chuyển sang Tuyến 53, chúng tôi không còn gặp sự cố DNS nào nữa và tên ELB của chúng tôi cũng có thể đẹp và dài.

Có những thứ khác để thử trong bài viết đó nhưng dường như đó là những người dẫn tốt nhất.


Cảm ơn những lời đề nghị. Thật không may, có vẻ như vấn đề hoàn toàn nằm ở độ phân giải DNS của tên máy chủ cho ELB, chứ không phải vì hồ sơ của chúng tôi có bí danh với nó. Hồ sơ của chúng tôi luôn giải quyết đúng tên máy chủ của ELB.
Cera

Đã sửa lỗi @ jaimieb giải quyết vấn đề?
slm

Nếu tôi hiểu đúng về bạn thì vấn đề là bạn có các bản ghi CNAME / ANAME giải quyết ELB bản ghi CNAME / ANAME và phần của bạn đang giải quyết ổn, không có vấn đề về hiệu suất, nhưng khi bạn nhận được DNS của ELB sẽ ghi lại các vấn đề về hiệu suất hiện?
slm

@slm - sửa lỗi tiềm năng # 1 không giúp được gì. Tôi sẽ khuyên bạn nên loại bỏ nó khỏi bài viết.
Ursus
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.