ศูนย์ข้อมูลหลายแห่งและทราฟฟิก HTTP: DNS Round Robin เป็นวิธีเดียวที่จะประกันความล้มเหลวได้ทันที

ดูเหมือนว่าระเบียน A หลายรายการที่ชี้ไปยังโดเมนเดียวกันนั้นเกือบจะถูกนำไปใช้เพื่อนำ DNS Round Robin มาใช้เป็นเทคนิคการปรับสมดุลภาระราคาถูก

คำเตือนปกติสำหรับ DNS RR คือมันไม่ดีสำหรับความพร้อมใช้งานสูง เมื่อ 1 IP ล่มลูกค้าจะยังคงใช้งานต่อไปอีกหลายนาที

โหลดบาลานเซอร์มักแนะนำให้เป็นตัวเลือกที่ดีกว่า

การอ้างสิทธิ์ทั้งสองนั้นไม่เป็นความจริงโดยสมบูรณ์:

1. เมื่อปริมาณการใช้งานเป็น HTTP เบราว์เซอร์ HTML ส่วนใหญ่จะสามารถลองระเบียน A ถัดไปโดยอัตโนมัติหากรายการก่อนหน้าไม่ทำงานโดยไม่ต้องค้นหา DNS ใหม่ อ่านที่นี่บทที่ 3.1และที่นี่

2. เมื่อศูนย์ข้อมูลหลายแห่งมีส่วนเกี่ยวข้อง DNS RR เป็นตัวเลือกเดียวในการกระจายปริมาณการใช้งานทั่วทั้งศูนย์

ดังนั้นจริงหรือที่ศูนย์ข้อมูลหลายแห่งและทราฟฟิก HTTP การใช้ DNS RR เป็นวิธีเดียวที่จะรับประกันความล้มเหลวได้ทันทีเมื่อศูนย์ข้อมูลแห่งใดแห่งหนึ่งล่ม

ขอบคุณ

วาเลนติโน่

แก้ไข:

• นอกหลักสูตรแต่ละศูนย์ข้อมูลจะมี Load Balancer ในพื้นที่พร้อมด้วย hot spare
• มันตกลงที่จะเสียสละความสัมพันธ์เซสชันสำหรับความล้มเหลวทันที
• AFAIK วิธีเดียวที่ DNS จะแนะนำศูนย์ข้อมูลแทนอีกวิธีหนึ่งคือการตอบกลับด้วยเฉพาะ IP (หรือ IP) ที่เชื่อมโยงกับศูนย์ข้อมูลนั้น หากศูนย์ข้อมูลไม่สามารถเข้าถึงได้ IP เหล่านั้นทั้งหมดจะไม่สามารถเข้าถึงได้ ซึ่งหมายความว่าแม้ว่าเบราว์เซอร์ HTML สมาร์ทสามารถลองบันทึก A อื่นได้ทันทีความพยายามทั้งหมดจะล้มเหลวจนกว่ารายการแคชในเครื่องจะหมดอายุและการค้นหา DNS ใหม่เสร็จสิ้นการดึงข้อมูล IP ที่ใช้งานได้ใหม่ (ฉันถือว่า DNS แนะนำให้ ศูนย์ข้อมูลใหม่เมื่อล้มเหลว) ดังนั้น "สมาร์ท DNS" จึงไม่สามารถรับประกันความล้มเหลวได้ทันที
• ในทางกลับกัน DNS round-robin อนุญาตให้ทำได้ เมื่อศูนย์ข้อมูลหนึ่งล้มเหลวเบราว์เซอร์ HTML อัจฉริยะ (ส่วนใหญ่) จะลองบันทึก A ที่เก็บไว้ในแคชใหม่ทันทีที่กระโดดไปยังศูนย์ข้อมูลอื่น (ที่ใช้งานได้) ดังนั้น DNS round-robin ไม่รับรองความสัมพันธ์ของเซสชันหรือ RTT ที่ต่ำที่สุด แต่ดูเหมือนจะเป็นวิธีเดียวที่จะรับประกันความล้มเหลวได้ทันทีเมื่อไคลเอนต์เป็นเบราว์เซอร์ HTML ที่ "ฉลาด"

แก้ไข 2:

• บางคนแนะนำ TCP Anycast เป็นวิธีการแก้ปัญหาที่ชัดเจน ในบทความนี้ (บทที่ 6) อธิบายว่า Anycast fail-over เกี่ยวข้องกับการบรรจบกันของ BGP ด้วยเหตุนี้ Anycast จึงสามารถใช้เวลาตั้งแต่ 15 นาทีถึง 20 วินาทีเพื่อให้เสร็จสมบูรณ์ เป็นไปได้ 20 วินาทีบนเครือข่ายที่ทอพอโลยีถูกปรับให้เหมาะสมสำหรับสิ่งนี้ อาจเป็นเพียงผู้ให้บริการ CDN เท่านั้นที่สามารถให้สิทธิ์การดูแลระบบที่ล้มเหลวได้อย่างรวดเร็ว

แก้ไข 3: *

• ฉันค้นหา DNS และ traceroutes (บางทีผู้เชี่ยวชาญบางคนสามารถตรวจสอบอีกครั้ง) และ:
  • CDN เดียวที่ใช้ TCP Anycast ดูเหมือนว่าจะเป็น CacheFly ตัวดำเนินการอื่นเช่นเครือข่าย CDN และ BitGravity ใช้ CacheFly ดูเหมือนว่าขอบของพวกเขาไม่สามารถใช้เป็นพร็อกซีย้อนกลับ ดังนั้นจึงไม่สามารถใช้เพื่อมอบการเฟลโอเวอร์ทันที
  • Akamai และ LimeLight ดูเหมือนว่าจะใช้ DNS ที่รับรู้ทางภูมิศาสตร์ แต่! พวกเขากลับมาหลายระเบียน A จาก traceroutes ดูเหมือนว่า IP ที่ส่งคืนอยู่ในศูนย์ข้อมูลเดียวกัน ดังนั้นฉันจึงสับสนกับวิธีที่พวกเขาสามารถเสนอ SLA ได้ 100% เมื่อศูนย์ข้อมูลแห่งหนึ่งล่ม

เมื่อฉันใช้คำว่า "DNS Round Robin" โดยทั่วไปแล้วฉันหมายถึงในแง่ของ "เทคนิคการทำโหลดบาลานซ์ราคาถูก" ตามที่ OP อธิบาย

แต่นั่นไม่ใช่วิธีเดียวที่ DNS สามารถใช้สำหรับความพร้อมใช้งานสูงทั่วโลก ส่วนใหญ่มันเป็นเรื่องยากสำหรับคนที่มีภูมิหลัง (เทคโนโลยี) ที่แตกต่างกันในการสื่อสารที่ดี

เทคนิคการปรับสมดุลภาระที่ดีที่สุด (หากไม่มีปัญหา)โดยทั่วไปถือว่าเป็น:

1. Anycast'ed เครือข่ายทั่วโลกของเซิร์ฟเวอร์ DNS 'อัจฉริยะ'
2. และชุดข้อมูลทั่วโลกที่กระจายออกไปดาต้าเซ็นเตอร์
3. โดยที่ DNS แต่ละโหนดใช้ Split Horizon DNS
4. และการตรวจสอบความพร้อมใช้งานและการรับส่งข้อมูลมีอยู่ในโหนด DNS 'อัจฉริยะ' ในบางรูปแบบ
5. เพื่อให้คำขอของผู้ใช้ DNS ไหลไปยังเซิร์ฟเวอร์ DNS ที่ใกล้ที่สุดผ่านทาง IP Anycast ,
6. และเซิร์ฟเวอร์ DNSนี้มอบชุดระเบียน A / TTL ต่ำให้แก่ศูนย์ข้อมูลที่ใกล้ที่สุด / ดีที่สุดสำหรับผู้ใช้ปลายทางนี้ผ่านทาง DNS 'split'

การใช้ anycast สำหรับ DNS นั้นใช้ได้เนื่องจากการตอบสนอง DNS นั้นไร้สัญชาติและสั้นมาก ดังนั้นหากเส้นทาง BGP เปลี่ยนไปจึงไม่น่าจะขัดขวางการสืบค้น DNS

Anycast ไม่เหมาะสำหรับการสนทนา HTTP ที่ยาวและรัฐดังนั้นระบบนี้ใช้ DNS horizon แบบแยก เซสชัน HTTP ระหว่างไคลเอนต์และเซิร์ฟเวอร์จะถูกเก็บไว้ในดาต้าเซ็นเตอร์เดียว โดยทั่วไปแล้วจะไม่สามารถล้มเหลวไปยังดาต้าเซ็นเตอร์อื่นได้โดยไม่ต้องหยุดเซสชัน

ตามที่ฉันระบุด้วย "set of A Records" สิ่งที่ฉันจะเรียกว่า 'DNS Round Robin' สามารถใช้ร่วมกับการตั้งค่าด้านบนได้ โดยทั่วไปจะใช้เพื่อกระจายปริมาณการรับส่งข้อมูลบน load balancer ที่มีความพร้อมใช้งานสูงหลายแห่งในแต่ละดาต้าเซ็นเตอร์ (เพื่อให้คุณได้รับความซ้ำซ้อนที่ดีขึ้นใช้ load balancer ที่เล็กกว่า / ราคาถูกกว่า

ดังนั้นจริงหรือที่ศูนย์ข้อมูลหลายแห่งและทราฟฟิก HTTP การใช้ DNS RR เป็นวิธีเดียวที่จะรับประกันความพร้อมใช้งานสูง

ไม่มันไม่เป็นความจริงถ้า 'DNS Round Robin' เราหมายถึงการส่งเรคคอร์ด A หลายโดเมนให้กับโดเมน แต่มันเป็นความจริงที่การใช้ DNS อย่างชาญฉลาดเป็นองค์ประกอบที่สำคัญในระบบความพร้อมใช้งานระดับสูงทั่วโลก ข้างต้นแสดงให้เห็นถึงวิธีการหนึ่งที่พบได้บ่อยที่สุด

แก้ไข:กระดาษของ Google "การย้ายเกินกว่าข้อมูลเส้นทางแบบครบวงจรเพื่อเพิ่มประสิทธิภาพ CDN"ดูเหมือนว่าฉันจะทันสมัยในการกระจายโหลดทั่วโลกสำหรับประสิทธิภาพของผู้ใช้ปลายทางที่ดีที่สุด

แก้ไข 2:ฉันอ่านบทความ"ทำไมต้องอิง DNS .. GSLB .. ไม่ทำงาน"ที่ OP เชื่อมโยงกับและเป็นภาพรวมที่ดี - ฉันแนะนำให้ดูที่นี่ อ่านจากด้านบน

ในส่วน "การแก้ปัญหาแคชของเบราว์เซอร์" จะสนับสนุนการตอบสนอง DNS ด้วยหลายระเบียน A ที่ชี้ไปที่หลายศูนย์ข้อมูลซึ่งเป็นทางออกเดียวที่เป็นไปได้สำหรับการล้มเหลวทันที

ในส่วน "รดน้ำมัน" ใกล้กับด้านล่างมันจะขยายออกไปอย่างชัดเจนว่าการส่งเร็กคอร์ด A หลายอันนั้นไม่ถูกตรวจสอบหากพวกเขาชี้ไปที่ดาต้าเซ็นเตอร์ในหลายทวีปเนื่องจากไคลเอนต์จะเชื่อมต่อแบบสุ่มและบ่อยครั้ง DC ในทวีปอื่น ดังนั้นเพื่อให้การทำงานนี้เป็นไปได้ดีจำเป็นต้องมีศูนย์ข้อมูลหลายแห่งในแต่ละทวีป

นี่คือวิธีการแก้ปัญหาที่แตกต่างจากขั้นตอนที่ 1 ของฉัน - 6. ฉันไม่สามารถให้คำตอบที่สมบูรณ์แบบในนี้ผมคิดว่าเป็นผู้เชี่ยวชาญ DNS จากชอบของ Akamai หรือ Google เป็นสิ่งจำเป็นมากเพราะนี้เดือดลงไปปฏิบัติความรู้เกี่ยวกับ ข้อ จำกัด ของแคช DNS และเบราว์เซอร์ที่ปรับใช้ในปัจจุบัน AFAIK ขั้นตอนที่ 1-6 ของฉันคือสิ่งที่ Akamai ทำกับ DNS ของพวกเขา (ทุกคนสามารถยืนยันได้หรือไม่)

ความรู้สึกของฉัน - มาจากการทำงานเป็น PM บนพอร์ทัลเบราว์เซอร์มือถือ (โทรศัพท์มือถือ) - นั่นคือความหลากหลายและระดับของการแตกหักโดยรวมของเบราว์เซอร์ออกมามีอย่างไม่น่าเชื่อ โดยส่วนตัวฉันจะไม่เชื่อถือโซลูชัน HA ที่ต้องการให้ผู้ใช้ปลายทาง 'ทำสิ่งที่ถูกต้อง'; ดังนั้นฉันเชื่อว่าการล้มเหลวทันทีทั่วโลกโดยไม่หยุดเซสชันไม่สามารถทำได้ในวันนี้

ฉันคิดว่าขั้นตอนที่ 1-6 ข้างต้นของฉันดีที่สุดที่มีอยู่ในเทคโนโลยีสินค้าโภคภัณฑ์ การแก้ปัญหานี้ไม่ได้ล้มเหลวทันที

ฉันชอบผู้เชี่ยวชาญ DNS คนใดคนหนึ่งจาก Akamai, Google และอื่น ๆ เพื่อพิสูจน์ว่าฉันผิด :-)

คำถามของคุณคือ: "DNS Round Robin เป็นวิธีการเดียวที่จะประกันความล้มเหลวได้ทันทีหรือไม่"

คำตอบคือ: "DNS Round Robin ไม่เคยเป็นวิธีที่ถูกต้องในการรับรองความล้มเหลวทันที"

(อย่างน้อยก็ไม่ได้อยู่คนเดียว)

วิธีที่ถูกต้องในการบรรลุความล้มเหลวทันทีคือการใช้การกำหนดเส้นทาง BGP4 เพื่อให้ทั้งสองเว็บไซต์ใช้ที่อยู่ IP เดียวกัน การใช้สิ่งนี้เทคโนโลยีการกำหนดเส้นทางหลักของอินเทอร์เน็ตถูกใช้เพื่อกำหนดเส้นทางการร้องขอไปยังศูนย์ข้อมูลที่ถูกต้องแทนที่จะใช้เทคโนโลยีการระบุที่อยู่หลักของอินเทอร์เน็ต

ในการกำหนดค่าที่ง่ายที่สุดจะมีเพียงการล้มเหลวเท่านั้น นอกจากนี้ยังสามารถนำมาใช้เพื่อให้ Anycast กับข้อแม้ว่าโปรโตคอลบน TCP จะล้มเหลวในขณะที่สลับไปมาหากมีความไม่แน่นอนในการกำหนดเส้นทาง

ดังนั้นจริงหรือที่ศูนย์ข้อมูลหลายแห่งและทราฟฟิก HTTP การใช้ DNS RR เป็นวิธีเดียวที่จะรับประกันความพร้อมใช้งานสูง

เห็นได้ชัดว่ามันเป็นข้ออ้างที่ผิดพลาด - คุณต้องดูที่ Google, Akamai, Yahoo, เพื่อดูว่าพวกเขาไม่ได้ใช้การตอบกลับแบบกลม [*] เป็นวิธีการแก้ปัญหาเพียงอย่างเดียว (บางคนอาจใช้มันในบางส่วน .)

มีตัวเลือกที่เป็นไปได้มากมาย แต่ขึ้นอยู่กับข้อ จำกัด อื่น ๆ ที่คุณมีกับบริการ / แอปพลิเคชันของคุณตามที่คุณเลือก

เป็นไปได้ที่จะใช้เทคนิค round-robin บนวิธีเซิร์ฟเวอร์ที่ใช้งานง่ายและไม่ต้องกังวลเกี่ยวกับความล้มเหลวของเซิร์ฟเวอร์ถ้าคุณจัดการกับ 'IP over-over' ของที่อยู่ IP (แต่ส่วนใหญ่เลือกใช้เทคนิคการโหลดบาลานซ์, ที่อยู่ IP เดียวและล้มเหลวระหว่างโหลดบาลานซ์)

บางทีคุณอาจต้องการคำขอทั้งหมดสำหรับเซสชันเดียวเพื่อไปยังเซิร์ฟเวอร์เดียวกัน แต่คุณต้องการให้คำขอกระจายไปทั่วคลัสเตอร์เซิร์ฟเวอร์ภูมิภาคที่แตกต่างกันหรือไม่ Round robin ไม่เหมาะสมสำหรับสิ่งนั้น: คุณต้องทำอะไรบางอย่างเพื่อให้แน่ใจว่าไคลเอนต์ที่ได้รับเข้าถึงฟิสิคัลเซิร์ฟเวอร์คลัสเตอร์เดียวกันทุกครั้ง (ยกเว้นเมื่อเกิด 'ข้อยกเว้น' เช่นเซิร์ฟเวอร์ล้มเหลว) พวกเขาอาจได้รับที่อยู่ IP ที่สอดคล้องกันจากแบบสอบถาม DNS หรือส่งไปยังเซิร์ฟเวอร์ฟิสิคัลคลัสเตอร์เดียวกัน วิธีแก้ปัญหาสำหรับที่รวม DNS "load balancer" ที่ใช้ในเชิงพาณิชย์และไม่ใช่เชิงพาณิชย์ต่างๆหรือ (หากคุณมีการควบคุมเครือข่ายของคุณมากขึ้น) โฆษณาเครือข่าย BGP คุณสามารถจัดการเซิร์ฟเวอร์ชื่อโดเมนของคุณเองเพื่อให้คำตอบที่แตกต่างกันโดยสิ้นเชิง (แต่เนื่องจากคำขอ DNS สามารถส่งไปทั่วสถานที่คุณจะได้รับ '

[* ฉันจะใช้ "round-robin" เพราะ 'RR' ในคำศัพท์ DNS หมายถึง "resource resource"]

การสังเกตที่ดีมากสำหรับคุณ vmiazzo +1 !! ฉันติดอยู่ตรงที่คุณอยู่ .. งงงันกับวิธีที่ CDN ทำเวทมนตร์ของพวกเขา

ต่อไปนี้เป็นสิ่งที่ฉันคาดเดาเกี่ยวกับวิธีที่ CDN ใช้งานเครือข่าย:

• ใช้ Anycast DNS (กล่าวถึงโดย Jesper Mortensen) เพื่อรับศูนย์ข้อมูลที่ใกล้ที่สุด
• พวกเขาใช้เครือข่ายท้องถิ่นที่ครอบคลุมศูนย์ข้อมูลต่าง ๆ ซึ่งอนุญาตให้พวกเขาทำบางสิ่งบางอย่างเช่นCARPบนโฮสต์ของพวกเขาข้ามศูนย์ข้อมูลต่าง ๆ

หรือ

• พวกเขาจ้างเกตเวย์ Load Balancing พิธีสารเกี่ยวกับเราเตอร์ของพวกเขาหรือฮอตสแตนบาย Router Protocol (HSRP) ซึ่งจัดการกับดาต้าเซ็นเตอร์ดับ
• เหตุผลที่พวกเขามีหลาย IP เพื่อให้ลูกค้าจะลองอีกครั้งและเมื่อลูกค้าลองอีกครั้งเส้นทางเส้นทางอาจมีการเปลี่ยนแปลง

ในขณะนี้วิธีแก้ปัญหาทำงานได้สำหรับฉัน: - DNS คืนค่าหลาย IP เช่น:

www -> CNAME www1 , www1 A -> 123.123.123.1
www -> CNAME www2 , www2 A -> 123.123.123.1 
www -> CNAME www3 , www3 A -> 123.123.123.1 
                    www3 A -> 8.4.56.7 <--- reverse proxy

• จุดเข้าใช้งานล่าสุดไปยังพร็อกซีย้อนกลับที่ amazon cloud ซึ่งผ่านไปยังเซิร์ฟเวอร์ที่พร้อมใช้งานอย่างชาญฉลาด (หรือให้ไว้ใต้หน้าการบำรุงรักษา)

Reverse proxy ยังคงได้รับผลกระทบ

ทำไม RFC 2782 (ใช้เช่นเดียวกับ MX / ลำดับความสำคัญสำหรับบริการเช่น http, imap, ... ) ไม่ได้ใช้งานในเบราว์เซอร์ชนิดใด? สิ่งที่จะง่ายขึ้น ... มีข้อผิดพลาดเกี่ยวกับเปิดเป็นเวลาสิบปีใน Mozilla !!! เพราะมันจะเป็นจุดสิ้นสุดของอุตสาหกรรมเครื่องถ่วงโหลดเชิงพาณิชย์ ฉันผิดหวังมากเกี่ยวกับเรื่องนี้

2 - คุณสามารถทำได้ด้วยAnycastโดยใช้Quagga

(แม้ว่าจะมีข้อมูลบางส่วนที่ Anycast ไม่ดีกับ TCP ก็มี บริษัท ใหญ่ ๆ หลายแห่งที่ใช้มันเช่น CacheFly)

ฉันสงสัยว่ามีผู้ตอบคำถามเหล่านี้กี่คนที่ใช้เครือข่ายเซิร์ฟเวอร์ขนาดใหญ่ทั่วโลก Google ใช้ round robin และ บริษัท ของฉันใช้มันมาหลายปีแล้ว มันสามารถทำงานได้ค่อนข้างดีโดยมีข้อ จำกัด บางประการ ใช่มันจะต้องมีการเสริมด้วยมาตรการอื่น ๆ

คีย์จริงคือยินดีที่จะยอมรับอาการสะอึกหรือสองถ้าเซิร์ฟเวอร์ล้มเหลว เมื่อฉันดึงปลั๊กบนเซิร์ฟเวอร์หากเบราว์เซอร์พยายามเข้าถึงเซิร์ฟเวอร์นั้นจะมีความล่าช้าประมาณหนึ่งนาทีขณะที่เบราว์เซอร์รู้ว่าที่อยู่ IP ไม่ทำงาน แต่มันจะไปยังเซิร์ฟเวอร์อื่นอย่างรวดเร็ว

มันใช้งานได้ดีและคนที่อ้างว่าทำให้เกิดปัญหามากมายไม่รู้ว่าพวกเขากำลังพูดถึงอะไร มันแค่ต้องการการออกแบบที่เหมาะสม

ล้มเหลวครับ HA ที่ดีที่สุดใช้ทรัพยากรทั้งหมดตลอดเวลา

ฉันทำงานกับ HA มาตั้งแต่ปี 1986 ฉันได้ผ่านการฝึกอบรมอย่างกว้างขวางเพื่อสร้างระบบ failover และฉันก็ไม่ใช่แฟนของ failover

นอกจากนี้ RR ยังทำงานเพื่อกระจายโหลดแม้ว่าจะอยู่เฉยๆมากกว่าที่จะกระตือรือร้น บันทึกเซิร์ฟเวอร์ของเราแสดงเปอร์เซ็นต์การรับส่งข้อมูลที่เหมาะสมในแต่ละเซิร์ฟเวอร์อย่างชัดเจน - ด้วยเหตุผล

อีกทางเลือกที่ง่ายมากคือใช้ต่ำ (ต่ำตามความต้องการของคุณ) TTL ในระเบียน DNS A หรือ CNAME และอัปเดตระเบียนนี้เพื่อเลือก IP ที่จะใช้

เรามี 2 ISP และบริการสาธารณะหลายแห่งและเราใช้วิธีนี้อย่างประสบความสำเร็จสำหรับความพร้อมใช้งานสูงจาก 3 ปี

ประแจหนึ่งในงานคือผู้ให้บริการอินเทอร์เน็ตจำนวนหนึ่งมีโปรแกรมกำหนดค่าตัวแก้ไขที่ไม่ดีซึ่งจะบันทึกแคชสำหรับช่วงเวลาที่กำหนดและละเว้นการตั้งค่า TTL อย่างสมบูรณ์ มันไม่ควรเป็นเช่นนั้นและไม่มีข้อแก้ตัวสำหรับมัน แต่น่าเศร้าจากประสบการณ์ของฉันในการโยกย้ายเว็บไซต์และบริการมากมายที่เกิดขึ้น

TCP Anycast มีความเสถียรมากและ CacheFly (ตั้งแต่ปี 2002) Prolexic และ BitGravity ใช้อย่างน้อยที่สุด มีการนำเสนอที่ดีเกี่ยวกับ TCP Anycast เสร็จแล้วที่ NANOG 37: http://198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf

บันทึกหลายระเบียนเป็นวิธีเดียวที่จะกำจัดจุดเดียวที่เป็นไปได้ของความล้มเหลว โซลูชันอื่นใดบังคับให้คำขอขาเข้าทั้งหมดผ่านอุปกรณ์เดียวระหว่างเซิร์ฟเวอร์และไคลเอนต์

ดังนั้นเพื่อความซ้ำซ้อนอย่างแท้จริงจึงเป็นสิ่งจำเป็น นั่นคือเหตุผลที่ google ทำหรือใครก็ตามที่ต้องการความมั่นใจในการให้บริการอย่างต่อเนื่อง

มันค่อนข้างชัดเจนว่าทำไมในกรณีนี้ ... หลายระเบียน A เป็นวิธีเดียวในการย้ายจุดที่ส่งคำขอไปยังเบราว์เซอร์ไคลเอ็นต์ วิธีการอื่น ๆ จะอาศัยจุดเดียวระหว่างเบราว์เซอร์ไคลเอ็นต์และเซิร์ฟเวอร์ที่อาจเกิดความล้มเหลวทำให้บริการของคุณแย่ลง โดยการใช้เรกคอร์ด A จุดความล้มเหลวจุดเดียวเท่านั้นจากไคลเอนต์ไปยังเซิร์ฟเวอร์กลายเป็นไคลเอนต์เอง

หากคุณไม่มีการตั้งค่าระเบียน A หลายรายการคุณกำลังขอเวลาหยุดทำงาน ...

เห็นได้ชัดว่าวิธีการนี้ไม่สามารถใช้กับการทำโหลดบาลานซ์ได้