ทำความเข้าใจ Round Robin DNS
(blog.hyperknot.com)ทำความเข้าใจ Round Robin DNS
-
Round Robin DNS คืออะไร?
- โดยทั่วไปเมื่อให้บริการเว็บไซต์บน VPS มักจะเพิ่ม A record เดียวในแผงควบคุมของผู้ให้บริการ DNS
- ใน Round Robin DNS สามารถกำหนดหลายเซิร์ฟเวอร์ให้กับซับโดเมนเดียวกันเพื่อกระจายโหลดไปยังหลายเซิร์ฟเวอร์ และตรวจจับเซิร์ฟเวอร์ที่ออฟไลน์โดยอัตโนมัติเพื่อเลือกเซิร์ฟเวอร์ที่ออนไลน์ได้
- เป็นโซลูชันที่เรียบง่ายและสวยงามโดยไม่ต้องใช้ load balancer และไม่มีค่าใช้จ่าย
-
ในทางทฤษฎีทำงานอย่างไร?
- ตาม RFC 8305 "Happy Eyeballs" ไคลเอนต์ควรจัดเรียงแอดเดรสก่อนทำการเชื่อมต่อ
- ตรวจสอบว่าเซิร์ฟเวอร์ออนไลน์หรือออฟไลน์ และจัดเรียงเซิร์ฟเวอร์ที่ออนไลน์ตามเวลา ping
-
ในการใช้งานจริงทำงานอย่างไร?
- สร้าง VPS 3 ตัวในสหรัฐอเมริกา ยุโรป และสิงคโปร์ แล้วสร้าง A record แบบ proxy และ non-proxy อย่างละ 3 รายการบน Cloudflare
- แต่ละเซิร์ฟเวอร์ให้บริการรูปภาพสีและชื่อโฮสต์
พฤติกรรมการเลือกเซิร์ฟเวอร์ของไคลเอนต์
-
Chrome
- เลือกแบบสุ่มในทุกตำแหน่ง แต่เมื่อเลือกแล้วจะยึดตำแหน่งนั้นไว้
- จะประเมินใหม่อีกครั้งหลังผ่านไปหลายชั่วโมง
-
Firefox
- คล้ายกับ Chrome คือเลือกแบบสุ่มแล้วคงการเลือกนั้นไว้
-
Safari
- เลือกเซิร์ฟเวอร์ที่ใกล้ที่สุดได้อย่างถูกต้องเสมอ
-
curl
- ในครั้งแรกอาจเลือกไม่ถูกต้อง แต่ในการรันครั้งที่สองจะปรับไปใช้เซิร์ฟเวอร์ที่ใกล้ที่สุด
-
Cloudflare
- เลือกตำแหน่งแบบสุ่มโดยอิงจาก IP ของไคลเอนต์ และคงการเลือกนั้นไว้
พฤติกรรมของไคลเอนต์เมื่อมีบางเซิร์ฟเวอร์ออฟไลน์
- ไคลเอนต์ทั้งหมดตรวจจับเซิร์ฟเวอร์ที่ออฟไลน์และเลือกเซิร์ฟเวอร์สำรอง
- Cloudflare ไม่สามารถตรวจจับเซิร์ฟเวอร์ที่ออฟไลน์ได้ และหากเซิร์ฟเวอร์ที่เลือกออฟไลน์อยู่ก็จะให้บริการในสถานะออฟไลน์นั้น
สิ่งที่ Cloudflare ควรปรับปรุง
- ควรตรวจจับเซิร์ฟเวอร์ที่ออฟไลน์ได้
- ควรมีความสามารถในการเลือกเซิร์ฟเวอร์ที่มี latency ต่ำที่สุด
สรุปโดย GN⁺
- Round Robin DNS เป็นวิธีในการกระจายโหลดไปยังหลายเซิร์ฟเวอร์ และสามารถทำได้อย่างเรียบง่ายโดยไม่ต้องใช้ load balancer
- วิธีที่เบราว์เซอร์และไคลเอนต์เลือกเซิร์ฟเวอร์นั้นแตกต่างกันไป โดยเฉพาะ Safari ที่เลือกเซิร์ฟเวอร์ที่ใกล้ที่สุดได้ดี
- ในกรณีของ Cloudflare มีปัญหาเรื่องไม่สามารถตรวจจับเซิร์ฟเวอร์ที่ออฟไลน์ได้ ซึ่งเป็นจุดที่ควรได้รับการปรับปรุง
- บทความนี้มีประโยชน์ต่อการทำความเข้าใจวิธีการทำงานของ Round Robin DNS และน่าสนใจสำหรับการสำรวจความแตกต่างของอัลกอริทึมการเลือกเซิร์ฟเวอร์
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ได้ขอให้ทีม DNS อธิบายสถานการณ์ปัจจุบันแล้ว และจะแชร์เมื่อได้รับคำตอบ โค้ดมีการเปลี่ยนแปลงบ่อยจึงทำให้ยากที่จะทราบสถานะปัจจุบันอย่างแม่นยำ ปัญหาอาจเกิดจากการคงการเชื่อมต่อระหว่าง IP ของไคลเอนต์กับเซิร์ฟเวอร์แบ็กเอนด์
การทำ DNS load balancing อาจก่อให้เกิดปัญหาที่ซับซ้อน อาจเกิดปัญหาเมื่อไคลเอนต์ HTTP2 ของ golang ใช้ RR DNS บางครั้งไคลเอนต์ไม่พบเซิร์ฟเวอร์ใหม่
MAX_CONNECTION_AGEเพื่อยกเลิกการเชื่อมต่อไคลเอนต์เป็นระยะได้ยังขาดโซลูชันมาตรฐานสำหรับ service discovery การทำ request-based load balancer และใช้ virtual IP เพื่อให้ load balancer ตรวจสอบสถานะอาจเป็นวิธีที่ดีที่สุด
DNS record แบบ SRV เป็นโซลูชันยุคแรกที่สามารถกำหนดลำดับความสำคัญให้ทุกบริการได้ แต่ไม่ได้ถูกใช้ในไคลเอนต์ HTTP ด้วยเหตุผลทางการเมือง มีการเสนอ DNS record แบบ HTTPS และ SVCB แบบใหม่เป็นโซลูชันใหม่สำหรับ load balancing
เมื่อเซิร์ฟเวอร์ออฟไลน์ ไคลเอนต์จะย้ายไปยัง IP ถัดไปหากการเชื่อมต่อถูกปฏิเสธ แต่ในทางปฏิบัติเซิร์ฟเวอร์อาจไม่ตอบสนองหรือเงียบไปหลังเชื่อมต่อ ทำให้ต้องพึ่งพา client timeout
ความน่าเชื่อถือถูกกำหนดที่ฝั่งไคลเอนต์ บางระบบอาจคืนค่า IP address ที่ต่ำที่สุดเสมอจนเกิดปัญหา DNS-RR ไม่ใช่ load balancer และ load balancer เป็นทางออกที่ดีกว่า
มีคนเขียน decoder ด้วย Perl และยืนยันว่าทุกอย่างควรทำด้วย Perl
RR-DNS มีประโยชน์แค่สำหรับ load balancing และไม่ตรวจจับความพร้อมใช้งานของเซิร์ฟเวอร์โดยอัตโนมัติ ต้องเพิ่มความสามารถแบบ smart ให้ไคลเอนต์
เมื่อเซิร์ฟเวอร์ล่ม หากมี IP address ที่กระจายอยู่ทั่วโลก ผู้คนก็ยังเชื่อมต่อได้ต่อไป
ที่ Amazon ในช่วงทศวรรษ 2000 มีการใช้ round-robin DNS สำหรับโฮสต์แบบ on-site ตอนนั้นมันเป็นวิธีทำ load balancing ที่เร็วที่สุด แต่ Wi-Fi เป็นคอขวดที่ใหญ่ที่สุด
มีการพูดถึง Cloudflare Load Balancing แต่ไม่ได้ทดสอบจริง โดย Cloudflare สามารถตรวจจับเซิร์ฟเวอร์ที่ออฟไลน์โดยอัตโนมัติและสลับไปยังเซิร์ฟเวอร์อื่นได้