ปัญหาเกี่ยวกับ DNS EC2 Elastic Load Balancer และการกำหนดเส้นทาง


19

เรากำลังพยายามเรียกใช้การตั้งค่าที่ค่อนข้างตรงไปตรงมาใน Amazon EC2 - เซิร์ฟเวอร์ HTTP หลายตัวที่อยู่ด้านหลัง Amazon Elastic Load Balancer (ELB)

โดเมนของเรามีการจัดการใน Route53 และเรามีระเบียน CNAME ตั้งค่าให้ชี้ไปที่ ELB

เราประสบปัญหาบางอย่างที่บางส่วน แต่ไม่ทั้งหมดที่ตั้งไม่สามารถเชื่อมต่อกับตัวโหลดบาลานซ์ได้ ดูเหมือนว่านี่อาจเป็นการแก้ไขชื่อโดเมนของ ELB

ฝ่ายสนับสนุนของอเมซอนแนะนำเราว่า Elastic IP พื้นฐานของ load balancer เปลี่ยนไปและปัญหาคือเซิร์ฟเวอร์ DNS ของ ISP บางรายไม่รองรับ TTL เราไม่พอใจกับคำอธิบายนี้เนื่องจากเราจำลองปัญหาโดยใช้เซิร์ฟเวอร์ DNS ของ Amazon จากอินสแตนซ์ EC2 เช่นเดียวกับผู้ให้บริการอินเทอร์เน็ตในประเทศออสเตรเลียและผ่านทางเซิร์ฟเวอร์ DNS ของ Google ( 8.8.8.8)

อเมซอนยังยืนยันว่าในช่วงเวลาที่เราสังเกตเห็นเวลาจากบางสถานที่การรับส่งข้อมูลผ่าน ELB ลดลงอย่างมีนัยสำคัญ - ดังนั้นปัญหาไม่ได้อยู่ที่ปลายทางของเรา

น่าสนใจโดเมนดูเหมือนจะแก้ไข IP ที่ถูกต้องบนเซิร์ฟเวอร์ที่ไม่สามารถเชื่อมต่อได้ แต่ความพยายามในการสร้างการเชื่อมต่อ TCP ล้มเหลว

อินสแตนซ์ทั้งหมดที่แนบกับ ELB นั้นแข็งแรงตลอดเวลา พวกเขาทั้งหมด

ไม่มีใครรู้วิธีที่เราจะไปเกี่ยวกับการวินิจฉัยปัญหานี้อย่างลึกซึ้งยิ่งขึ้น? มีใครเคยประสบปัญหานี้กับ Elastic Load Balancer อีกหรือไม่

ขอบคุณ


ฉันควรเพิ่มเป็นบันทึกย่ออื่น - แม้ว่านี่อาจดูเหมือนว่าเกี่ยวข้องกับ DNS หรือการกำหนดเส้นทางเท่าที่เราสามารถบอกได้ว่าโดเมนของเราแก้ไข EIP ที่ถูกต้องเสมอ - การเรียกใช้hostยูทิลิตี้นี้จะแก้ไขที่อยู่เดียวกันบนระบบ เราทำไม่ได้
Cera

คำตอบ:


21

ฉันพบคำถามนี้ในขณะที่ Googling สำหรับวิธีการวินิจฉัย Amazon Elastic Load Balancers (ELB) และฉันต้องการตอบคำถามนี้ให้กับคนอื่น ๆ เช่นฉันที่มีปัญหานี้โดยไม่ได้รับคำแนะนำมากนัก

คุณสมบัติของ ELB

ELBs มีคุณสมบัติที่น่าสนใจ ตัวอย่างเช่น

  • ELB ประกอบด้วยโหนดตั้งแต่ 1 โหนดขึ้นไป
  • โหนดเหล่านี้ถูกเผยแพร่เป็นเรคคอร์ด A สำหรับชื่อ ELB
  • โหนดเหล่านี้สามารถล้มเหลวหรือถูกปิดและการเชื่อมต่อจะไม่ถูกปิดอย่างสง่างาม
  • มันมักจะต้องมีความสัมพันธ์ที่ดีกับการสนับสนุนของ Amazon ($$$) เพื่อให้คนที่จะขุดปัญหา ELB

หมายเหตุ: คุณสมบัติที่น่าสนใจอีกประการหนึ่ง แต่มีความเกี่ยวข้องน้อยกว่าเล็กน้อยคือ ELB ไม่ได้รับการออกแบบมาเพื่อรองรับปริมาณการใช้ข้อมูลที่เพิ่มขึ้นอย่างฉับพลัน โดยทั่วไปแล้วพวกเขาต้องการการจราจรหนาแน่น 15 นาทีก่อนที่พวกเขาจะขยายขนาดหรือพวกเขาสามารถอุ่นเครื่องล่วงหน้าตามคำขอผ่านทางตั๋วสนับสนุน

การแก้ไขปัญหา ELB (ด้วยตนเอง)

อัปเดต: 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ก็ใช้งานได้เช่นกัน นอกจากนี้เส้นทาง 53 สามารถส่งคืนข้อมูลสูงสุด 4KB ที่ยังคงใช้งาน 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 โดยไม่ต้องเชื่อมต่อกับแบ็กเอนด์ของคุณ หนึ่งในคุณสมบัติสุดท้ายและความจริงที่รู้จักกันน้อยเกี่ยวกับ ELBs:

  • ขนาดสูงสุดของวิธีการร้องขอ (verb) ที่สามารถส่งผ่าน 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 เป็นคดีที่สมเหตุสมผลว่ามีบางอย่างผิดปกติ

หวังว่านี่จะช่วยได้!


1
ขอบคุณสำหรับคำตอบที่ดี ตอนแรกเราพบว่าส่วนใหญ่ผ่านการลองผิดลองถูก แต่นี่เป็นการอ้างอิงที่สะดวก
Cera

7

การแก้ไขนั้นง่ายมาก: ใช้AเรกCNAMEคอร์ดแทน a ใน Route53

ในคอนโซลการจัดการ AWS เลือก "ระเบียน" จากนั้นย้ายปุ่มตัวเลือก "นามแฝง" ไปที่ "ใช่" จากนั้นเลือก ELB ของคุณจากเมนูแบบเลื่อนลง


1
ฉันไม่เข้าใจเหตุผลเบื้องหลังการแก้ไขนี้ เอกสารของ Amazon สำหรับ ELB โดยเฉพาะกล่าวว่าCNAMEควรใช้บันทึก อะไรจะเป็นประโยชน์ของAบันทึก / สิ่งที่เปลี่ยนแปลงที่นี่?
Cera

3
คุณต้องใช้ CNAME หาก DNS ของคุณโฮสต์ที่อื่นที่ไม่ใช่ Route53 แต่การสร้างชื่อแทนระเบียนเป็นคุณลักษณะเฉพาะของ Route53 และมีวัตถุประสงค์เพื่อแก้ไขปัญหาที่แน่นอนที่คุณพบ เอกสาร Route53อธิบายในเชิงลึกมากขึ้น
jamieb

@jamieb คุณสามารถให้ลิงค์ไปยังเอกสารชิ้นนั้นได้หรือไม่?
จนถึง

1
มันเรียกว่า "Alias ​​Target" ซึ่งตรงข้ามกับบันทึก A docs.aws.amazon.com/Route53/latest/DeveloperGuide/…
Jonny07

0

มีโซลูชันที่เป็นไปได้บางอย่างที่คุณสามารถลองได้ในฟอรัมนักพัฒนา AWS นี้ https://forums.aws.amazon.com/message.jspa?messageID=387552

ตัวอย่างเช่น:

แก้ไขที่มีศักยภาพ # 1

เรามีปัญหาที่คล้ายกันเมื่อเราย้ายไปที่ ELB เราแก้ไขปัญหานี้โดยการลดชื่อของ ELB ของเราเป็นตัวละครตัวเดียว แม้แต่ชื่อถ่าน 2 ตัวสำหรับ ELB ก็ทำให้เกิดปัญหาแบบสุ่มกับการแก้ปัญหา DNS ของเครือข่าย

ชื่อ DNS ของ ELB ของคุณควรเป็น -> X.9chars> .us-east-1.elb.amazonaws.com

แก้ไขที่มีศักยภาพ # 2

ฉันเป็นโปสเตอร์ดั้งเดิม ขอขอบคุณสำหรับการตอบสนองทุก. เราสามารถลดความถี่ที่เราประสบปัญหา DNS ด้วยการตั้งค่า TTL ที่สูงมาก (ดังนั้นพวกเขาจะถูกแคชโดยเซิร์ฟเวอร์ที่ไม่ใช่โซลูชั่นเครือข่าย) อย่างไรก็ตามเรายังคงประสบปัญหามากพอที่เราจะไม่สามารถอยู่กับ Network Solutions ได้อีกต่อไป เราคิดว่าจะย้ายไปที่ UltraDNS ตามรายงานที่ดีในการให้บริการ แต่ดูเหมือนว่าเส้นทาง 53 (ซึ่งใช้ UltraDNS ภายใต้ฝาครอบมันจะปรากฏขึ้น) จะถูกกว่าสำหรับเรา ตั้งแต่เปลี่ยนมาใช้ Route 53 เราไม่มีปัญหา DNS อีกต่อไปและชื่อ ELB ของเราก็ดีและยาวเกินไป

มีสิ่งอื่น ๆ ให้ลองในโพสต์นั้น แต่สิ่งเหล่านั้นดูเหมือนจะเป็นผู้นำที่ดีที่สุด


ขอบคุณสำหรับคำแนะนำ น่าเสียดายที่ดูเหมือนว่าปัญหานั้นอยู่ที่การแก้ไข DNS อย่างละเอียดของชื่อโฮสต์สำหรับ ELB ไม่ใช่สำหรับบันทึกของเราที่เป็นชื่อแทน บันทึกของเราจะแก้ไขเป็นชื่อโฮสต์ของ ELB อย่างถูกต้องเสมอ
Cera

การแก้ไขของ @jaimieb แก้ปัญหาได้หรือไม่
slm

ถ้าฉันเข้าใจคุณอย่างถูกต้องปัญหาก็คือคุณมีระเบียน CNAME / ANAME ที่แก้ไขระเบียน CNAME / ANAME ELB และส่วนของคุณแก้ไขได้ดีไม่มีปัญหาด้านประสิทธิภาพ แต่เมื่อคุณได้รับ DNS ของ ELB จะบันทึกปัญหาประสิทธิภาพการทำงาน แสดงขึ้นมา?
slm

@slm - การแก้ไขที่เป็นไปได้ # 1 ไม่ได้ช่วย ฉันขอแนะนำให้ลบออกจากโพสต์
Ursus
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.