เหตุใดจึงไม่แนะนำให้ DNS ล้มเหลว

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

สำหรับฉันดูเหมือนว่า DNS failover เป็นตัวเลือกเดียวที่ล้มเหลวที่นี่ แต่ฉันทามติว่ามันไม่ใช่ตัวเลือกที่ดี แต่บริการอย่าง DNSmadeeasy.com ก็ให้บริการดังนั้นจะต้องมีการทำบุญ มีคำแนะนำอะไรมั้ย?

โดย 'DNS failover' ฉันหมายความว่าคุณหมายถึง DNS Round Robin รวมกับการตรวจสอบบางอย่างเช่นการเผยแพร่ที่อยู่ IP หลายรายการสำหรับชื่อโฮสต์ DNS และลบที่อยู่ที่ไม่ทำงานเมื่อตรวจสอบว่าเซิร์ฟเวอร์หยุดทำงาน สิ่งนี้สามารถใช้งานได้กับเว็บไซต์ขนาดเล็กที่มีการดูแลการแสดงโฆษณาน้อยกว่า

จากการออกแบบเมื่อคุณตอบคำขอ DNS คุณจะต้องระบุ Time To Live (TTL) สำหรับการตอบกลับที่คุณส่ง พูดอีกอย่างก็คือคุณกำลังบอกเซิร์ฟเวอร์ DNS และแคชอื่น ๆ "คุณอาจเก็บคำตอบนี้ไว้และใช้เป็นเวลา x นาทีก่อนที่จะกลับมาตรวจสอบกับฉัน" ข้อเสียมาจากสิ่งนี้:

• ด้วย DNS failover เปอร์เซ็นต์ที่ไม่รู้จักของผู้ใช้ของคุณจะทำให้ข้อมูล DNS ของคุณถูกแคชด้วยจำนวน TTL ที่แตกต่างกัน จนกว่า TTL จะหมดอายุสิ่งเหล่านี้อาจเชื่อมต่อกับเซิร์ฟเวอร์ที่ไม่ทำงาน มีวิธีการที่ล้มเหลวได้เร็วกว่านี้
• เนื่องจากข้างต้นคุณมีแนวโน้มที่จะตั้งค่า TTL ค่อนข้างต่ำพูด 5-10 นาที แต่การตั้งค่าที่สูงกว่าจะให้ประโยชน์ด้านประสิทธิภาพ (เล็กมาก) และอาจช่วยให้การเผยแพร่ DNS ของคุณทำงานได้อย่างน่าเชื่อถือแม้ว่าจะมีข้อผิดพลาดสั้น ๆ ในปริมาณการใช้เครือข่าย ดังนั้นการใช้ความล้มเหลวที่ขึ้นกับ DNS จะเทียบกับ TTL สูง แต่ TTL สูงนั้นเป็นส่วนหนึ่งของ DNS และอาจมีประโยชน์

วิธีการทั่วไปที่ใช้เวลามากในการทำ uptime นั้น ได้แก่ :

• วางเซิร์ฟเวอร์เข้าด้วยกันใน LAN เดียวกัน
• วาง LAN ในดาต้าเซ็นเตอร์ด้วยพลังงานและแผนเครือข่ายที่พร้อมใช้งานสูง
• ใช้ HTTP load balancer เพื่อกระจายโหลดและล้มเหลวบนแต่ละเซิร์ฟเวอร์ที่ล้มเหลว
• รับระดับความซ้ำซ้อน / สถานะการออนไลน์ที่คุณต้องการสำหรับไฟร์วอลล์ตัวโหลดบาลานซ์และสวิตช์
• มีกลยุทธ์การสื่อสารสำหรับความล้มเหลวของดาต้าเซ็นเตอร์แบบเต็มและความล้มเหลวเป็นครั้งคราวของเซิร์ฟเวอร์สวิตช์ / ฐานข้อมูล / ทรัพยากรอื่น ๆ ที่ไม่สามารถสะท้อนได้อย่างง่ายดาย

เว็บไซต์เล็ก ๆ น้อย ๆ จำนวนมากใช้การตั้งค่าหลายดาต้าเซ็นเตอร์พร้อม 'สมดุลทางภูมิศาสตร์' ระหว่างดาต้าเซ็นเตอร์

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

DNS ไม่ได้ออกแบบมาสำหรับ failover - แต่ได้รับการออกแบบด้วย TTL ที่ทำงานได้อย่างน่าอัศจรรย์สำหรับความต้องการของ failover เมื่อรวมเข้ากับระบบตรวจสอบที่มั่นคง สามารถตั้งค่า TTL ได้สั้นมาก ฉันใช้ TTLs อย่างมีประสิทธิภาพ 5 วินาทีในการผลิตเพื่อลดปัญหา DNS ที่ล้มเหลวอย่างรวดเร็ว คุณต้องมีเซิร์ฟเวอร์ DNS ที่สามารถจัดการโหลดพิเศษได้และชื่อจะไม่ตัดทิ้ง อย่างไรก็ตาม powerdns เหมาะกับการเรียกเก็บเงินเมื่อสำรองข้อมูลด้วยฐานข้อมูลที่จำลองแบบ mysql บนเซิร์ฟเวอร์ชื่อที่ซ้ำซ้อน คุณต้องมีระบบการตรวจสอบแบบกระจายแบบกระจายที่คุณสามารถเชื่อถือได้สำหรับการรวมการเฟลโอเวอร์อัตโนมัติ Zabbix ใช้งานได้สำหรับฉัน - ฉันสามารถตรวจสอบการขาดหายไปของระบบ Zabbix แบบกระจายหลาย ๆ เครื่องได้ในทันที - อัปเดตระเบียน mysql ที่ใช้โดย powerdns ได้ทันที - และมอบการล้มเหลวทันทีในช่วงที่ไฟดับและการจราจรติดขัด

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

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

น่าเสียดายที่มันเป็นตัวเลือกเดียวที่ค่อนข้างดีเว้นแต่คุณจะมีขนาดใหญ่พอที่จะกำหนดเส้นทางของคุณเอง (ภายนอก)

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

อย่างไรก็ตาม,

http://crypto.stanford.edu/dns/dns-rebinding.pdfอธิบายว่ามันไม่เป็นความจริงสำหรับเบราว์เซอร์ HTML ส่วนใหญ่ในปัจจุบัน พวกเขาจะลอง IP ต่อไปในไม่กี่วินาที

http://www.tenereillo.com/GSLBPageOfShame.htmดูเหมือนจะแข็งแกร่งยิ่งขึ้น:

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

บางทีผู้เชี่ยวชาญบางคนสามารถแสดงความคิดเห็นและให้คำอธิบายที่ชัดเจนยิ่งขึ้นว่าทำไม DNS RR ถึงไม่ดีสำหรับความพร้อมใช้งานสูง

ขอบคุณ

วาเลนติโน่

PS: ขอโทษสำหรับลิงค์เสีย แต่ในฐานะผู้ใช้ใหม่ฉันไม่สามารถโพสต์มากกว่า 1

ฉันใช้ล้มเหลวของ DNS RR ในเว็บไซต์ที่มีการดูแลการแสดงโฆษณาปานกลาง แต่มีความสำคัญต่อธุรกิจ (ในสองภูมิภาค) เป็นเวลาหลายปี

มันใช้งานได้ดี แต่มีอย่างน้อยสาม subtleties ฉันเรียนรู้วิธีที่ยาก

1) เบราว์เซอร์จะล้มเหลวจาก IP ที่ไม่ทำงานไปเป็น IP ที่ทำงานหลังจาก 30 วินาที (ครั้งสุดท้ายที่ฉันตรวจสอบ) หากทั้งสองพิจารณาว่ามีการใช้งานใน DNS แคชใด ๆ ที่มีให้กับลูกค้าของคุณ นี่เป็นสิ่งที่ดี

แต่การมี "ครึ่ง" ผู้ใช้ของคุณรอ 30 วินาทีไม่เป็นที่ยอมรับดังนั้นคุณอาจต้องการอัปเดตระเบียน TTL ของคุณเป็นเวลาไม่กี่นาทีไม่ใช่ไม่กี่วันหรือสัปดาห์เพื่อให้ในกรณีที่ไฟดับคุณสามารถลบเซิร์ฟเวอร์ลงได้อย่างรวดเร็ว จาก DNS ของคุณ คนอื่น ๆ พูดพาดพิงถึงสิ่งนี้ในการตอบสนองของพวกเขา

2) หากหนึ่งในเซิร์ฟเวอร์ชื่อของคุณ (หรือหนึ่งในสองพื้นที่ทางภูมิศาสตร์ของคุณทั้งหมด) ลงซึ่งให้บริการโดเมน round-robin ของคุณและถ้าหนึ่งในหลักของพวกเขาลงไปฉันจำได้ยากว่าคุณสามารถพบกับปัญหาอื่น ๆ downs nameserver จาก DNS ถ้าคุณยังไม่ได้ตั้งค่า SOA TTL / expiration ของคุณสำหรับ nameserver ให้มีค่าต่ำพอสมควรเช่นกัน ฉันอาจมีรายละเอียดทางเทคนิคผิดที่นี่ แต่มีมากกว่าหนึ่งการตั้งค่า TTL ที่คุณต้องได้รับสิทธิในการป้องกันความล้มเหลวจุดเดียวจริงๆ

3) หากคุณเผยแพร่เว็บ API บริการ REST และอื่น ๆ โดยทั่วไปเบราว์เซอร์จะไม่ถูกเรียกใช้ดังนั้นในความเห็นของฉัน DNS failover เริ่มแสดงข้อบกพร่องที่แท้จริง นี่อาจเป็นสาเหตุที่บางคนพูดตามที่คุณวางไว้ "ไม่แนะนำ" นี่คือเหตุผลที่ฉันพูดอย่างนั้น ก่อนอื่นแอปที่ใช้ URL เหล่านั้นไม่ใช่เบราว์เซอร์ดังนั้นจึงไม่มีคุณสมบัติ / ตรรกะการเข้าแทนที่ 30 วินาทีของเบราว์เซอร์ทั่วไป ข้อที่สองไม่ว่าจะมีการเรียกใช้รายการ DNS ที่สองหรือไม่ก็ตามและถึงแม้ DNS จะถูกโพลใหม่นั้นขึ้นอยู่กับรายละเอียดการเขียนโปรแกรมระดับต่ำของไลบรารีเครือข่ายในภาษาการเขียนโปรแกรมที่ใช้โดยไคลเอนต์ API / REST เหล่านี้ แอปไคลเอ็นต์ API / REST (ภายใต้ที่ครอบคลุมไลบรารีจะเรียก get_addr และเมื่อใดถ้าซ็อกเก็ตหยุดทำงานหรือปิดแอปจะเปิดซ็อกเก็ตใหม่อีกครั้งหรือไม่มีตรรกะการหมดเวลาบ้างหรือไม่ ฯลฯ )

มันถูกทดสอบอย่างดีและ "ส่วนใหญ่ใช้งานได้" ไมล์สะสมของคุณอาจแตกต่างกันไป

มีคนจำนวนมากที่ใช้เรา (Dyn) สำหรับความล้มเหลว มันเป็นเหตุผลเดียวกันที่เว็บไซต์สามารถทำหน้าสถานะเมื่อพวกเขามีเวลาหยุดทำงาน (ลองนึกถึงสิ่งต่างๆเช่น Twitter's Fail Whale) ... หรือเพียงแค่เปลี่ยนเส้นทางการเข้าชมตาม TTL บางคนอาจคิดว่า DNS Failover เป็นสลัม ... แต่เราออกแบบเครือข่ายของเราอย่างจริงจังโดยมี failover ตั้งแต่เริ่มต้น ... เพื่อให้สามารถทำงานได้เป็นอย่างดีรวมถึงฮาร์ดแวร์ ฉันไม่แน่ใจว่า DME ทำได้อย่างไร แต่เรามี 3 ใน 17 ของ PoPs ที่ได้รับการออกอากาศที่ใกล้เคียงที่สุดของเราตรวจสอบเซิร์ฟเวอร์ของคุณจากตำแหน่งที่ใกล้เคียงที่สุด เมื่อตรวจพบจากสองในสามข้อที่ว่าลงเราก็เปลี่ยนเส้นทางการรับส่งข้อมูลไปยัง IP อื่น ๆ การหยุดทำงานเพียงครั้งเดียวสำหรับช่วงเวลาที่เหลือของช่วง TTL นั้น

บางคนชอบที่จะใช้เซิร์ฟเวอร์ทั้งสองในครั้งเดียว ... และในกรณีนั้นสามารถทำอะไรบางอย่างเช่นการทำโหลดบาลานซ์รอบ ๆ โรบิน ... หรือการทำโหลดบาลานซ์แบบอิงภูมิศาสตร์ สำหรับผู้ที่ใส่ใจในประสิทธิภาพจริง ๆ ... ผู้จัดการจราจรแบบเรียลไทม์ของเราจะตรวจสอบแต่ละเซิร์ฟเวอร์ ... และหากช้ากว่านั้น ... เปลี่ยนเส้นทางการรับส่งข้อมูลไปยังเซิร์ฟเวอร์ที่เร็วที่สุดโดยอิงจาก IP ที่คุณลิงก์ในชื่อโฮสต์ของคุณ อีกครั้ง ... มันใช้งานได้ตามค่าที่คุณใส่ใน UI / API / Portal ของเรา

ฉันเดาว่าประเด็นของฉันคือ ... เราออกแบบ DNS failover ตามวัตถุประสงค์ ในขณะที่ DNS ไม่ได้ถูกสร้างขึ้นเพื่อล้มเหลวเมื่อแรกเริ่มสร้างขึ้น ... เครือข่าย DNS ของเราได้รับการออกแบบให้ใช้งานได้ตั้งแต่เริ่มต้น โดยปกติจะมีประสิทธิภาพเท่ากับฮาร์ดแวร์โดยไม่คิดค่าเสื่อมราคาหรือราคาฮาร์ดแวร์ หวังว่าจะไม่ทำให้ฉันฟังไม่ออกสำหรับการเสียบ Dyn ... มี บริษัท อื่นอีกมากมายที่ทำ ... ฉันแค่พูดจากมุมมองของทีมเรา หวังว่านี่จะช่วย ...

อีกทางเลือกหนึ่งคือการตั้งค่าเซิร์ฟเวอร์ชื่อ 1 ในตำแหน่งที่ตั้ง A และเซิร์ฟเวอร์ชื่อ 2 ในตำแหน่งที่ตั้ง B แต่ตั้งค่าแต่ละรายการเพื่อให้ระเบียน A ทั้งหมดบนการรับส่งข้อมูลจุด NS1 ไปยัง IPs สำหรับตำแหน่งที่ตั้ง A และระเบียน NS A ทั้งหมดชี้ไปที่ IP location B จากนั้นตั้งค่า TTL ของคุณสำหรับจำนวนที่น้อยมากและตรวจสอบให้แน่ใจว่าระเบียนโดเมนของคุณที่ บริษัท จดทะเบียนได้รับการตั้งค่าสำหรับ NS1 และ NS2 ด้วยวิธีนี้มันจะโหลดยอดคงเหลือโดยอัตโนมัติและล้มเหลวหากเซิร์ฟเวอร์หนึ่งเครื่องหรือลิงก์หนึ่งลิงก์ไปยังตำแหน่งหนึ่งหยุดทำงาน

ฉันใช้วิธีนี้ในวิธีที่แตกต่างออกไปเล็กน้อย ฉันมีที่ตั้งหนึ่งแห่งที่มี ISP สองแห่งและใช้วิธีนี้เพื่อควบคุมปริมาณการใช้งานผ่านแต่ละลิงก์ ตอนนี้อาจเป็นการบำรุงรักษามากกว่าที่คุณต้องการ ... แต่ฉันสามารถสร้างซอฟต์แวร์ง่ายๆที่ดึงระเบียน NS1 โดยอัตโนมัติอัปเดตที่อยู่ IP ของระเบียนสำหรับโซนที่เลือกและผลักดันโซนเหล่านั้นไปที่ NS2

ทางเลือกคือระบบที่ล้มเหลวของ BGP การตั้งค่าไม่ใช่เรื่องง่าย แต่ควรเป็นเครื่องพิสูจน์กระสุน ตั้งค่าไซต์ A ในสถานที่เดียวไซต์ B ในหนึ่งวินาทีพร้อมด้วยที่อยู่ IP ท้องถิ่นจากนั้นรับคลาส C หรือบล็อกอื่น ๆ ของ ip ที่พกพาได้และตั้งค่าการเปลี่ยนเส้นทางจาก IP แบบพกพาไปยัง IP ท้องถิ่นของ

มีข้อผิดพลาด แต่จะดีกว่าโซลูชันที่ใช้ DNS หากคุณต้องการระดับการควบคุมนั้น

ทางเลือกหนึ่งสำหรับความล้มเหลวของศูนย์ข้อมูลหลายประการคือการฝึกอบรมผู้ใช้ของคุณ เราโฆษณาให้กับลูกค้าของเราที่เราให้บริการเซิร์ฟเวอร์หลายแห่งในหลายเมืองและในอีเมลลงทะเบียนของเราและรวมถึงการเชื่อมโยงโดยตรงไปยัง "เซิร์ฟเวอร์" แต่ละเครื่องเพื่อให้ผู้ใช้ทราบว่าเซิร์ฟเวอร์หนึ่งล่มพวกเขาสามารถใช้ลิงก์ไปยังเซิร์ฟเวอร์อื่น ๆ

ทั้งหมดนี้ข้ามปัญหาของ DNS failover เพียงแค่ดูแลชื่อโดเมนหลายชื่อ ผู้ใช้ที่ไปที่ www.company.com หรือ company.com และเข้าสู่ระบบได้โดยตรงไปยัง server1.company.com หรือ server2.company.com และมีตัวเลือกในการคั่นหน้าอย่างใดอย่างหนึ่งหากพวกเขาสังเกตเห็นว่าพวกเขาได้รับประสิทธิภาพที่ดีขึ้นโดยใช้อย่างใดอย่างหนึ่ง . หากผู้ใช้คนหนึ่งถูกฝึกหัดให้ไปที่เซิร์ฟเวอร์อื่น

ฉันใช้การปรับสมดุลไซต์และการล้มเหลวตาม DNS ในช่วงสิบปีที่ผ่านมาและมีปัญหาบางอย่าง แต่สิ่งเหล่านั้นสามารถลดลงได้ BGP ในขณะที่เหนือกว่าในบางวิธีไม่ได้เป็นโซลูชันที่ 100% ทั้งที่มีความซับซ้อนเพิ่มขึ้นอาจเป็นค่าใช้จ่ายฮาร์ดแวร์เพิ่มเติมเวลาที่บรรจบกัน ฯลฯ

ฉันพบว่าการรวมการโหลดบาลานซ์ในพื้นที่ (ตาม LAN), GSLB และการโฮสต์โซนบนคลาวด์ทำงานได้ค่อนข้างดีในการปิดปัญหาบางประการที่เกี่ยวข้องกับการโหลดบาลานซ์ DNS

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

หากคุณเป็น บริษัท ข้ามชาติที่มีงบประมาณไม่ จำกัด ในช่วงเวลาการใช้งานใช่ฮาร์ดแวร์ตัวโหลดบาลานซ์ของ GSLB และดาต้าเซ็นเตอร์ระดับ 1 นั้นยอดเยี่ยม แต่ DNS ของคุณยังต้องรวดเร็วและมั่นคง ดังที่คุณหลายคนรู้ว่า DNS เป็นสิ่งสำคัญสำหรับโครงสร้างพื้นฐานอื่น ๆ นอกเหนือจากชื่อโดเมนเองมันเป็นบริการระดับต่ำสุดที่ทุกส่วนอื่น ๆ ของการปรากฏตัวทางออนไลน์ของคุณดำเนินต่อไป เริ่มต้นจากผู้รับจดทะเบียนโดเมนที่มั่นคง DNS เป็นสิ่งสำคัญอย่างยิ่งที่จะไม่ทำให้โดเมนของคุณหมดอายุ DNS หยุดทำงานนั่นหมายความว่าลักษณะการออนไลน์ทั้งหมดขององค์กรของคุณก็ลดลงเช่นกัน!

เมื่อใช้ DNS Failover ประเด็นสำคัญอื่น ๆ คือการตรวจสอบเซิร์ฟเวอร์ (ควรระบุสถานที่ทางภูมิศาสตร์หลายแห่งเพื่อตรวจสอบและควรตรวจสอบหลายครั้ง (อย่างน้อย 3) เพื่อหลีกเลี่ยงผลบวกปลอม) และจัดการระเบียน DNS อย่างถูกต้อง TTL ต่ำและตัวเลือกบางอย่างที่มีความล้มเหลวสามารถทำให้กระบวนการนี้ราบรื่นและทำให้คุณไม่ตื่นขึ้นมาถึงเพจเจอร์กลางดึกถ้าคุณเป็นผู้ดูแลระบบ

โดยรวมแล้ว DNS Failover ใช้งานได้จริงและมีราคาไม่แพงมาก ในกรณีส่วนใหญ่จากเราหรือผู้ให้บริการ DNS ที่ได้รับการจัดการส่วนใหญ่คุณจะได้รับ Anycast DNS พร้อมกับการตรวจสอบสถานะเซิร์ฟเวอร์และการล้มเหลวสำหรับค่าใช้จ่ายส่วนหนึ่งของตัวเลือกฮาร์ดแวร์

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

"และทำไมคุณถึงใช้โอกาสนี้กับสภาพแวดล้อมการผลิตส่วนใหญ่ (แม้ว่าจะดีกว่าไม่มีอะไร)"

ที่จริงแล้ว "ดีกว่าไม่มีอะไร" จะแสดงได้ดีกว่าเป็น "ตัวเลือกเดียว" เมื่อการแสดงตนมีความหลากหลายทางภูมิศาสตร์ ตัวโหลดบาลานซ์ฮาร์ดแวร์ยอดเยี่ยมสำหรับจุดที่มีอยู่จุดเดียว แต่จุดที่มีจุดเดียวนั้นก็เป็นจุดที่ล้มเหลวเพียงจุดเดียว

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

การล้มเหลวที่ใช้ Dns นั้นเกิดจากความล่าช้าจำนวนหนึ่ง ไม่มีทางรอบมัน แต่ก็ยังคงเป็นวิธีเดียวที่ใช้งานได้ในการจัดการ failover ในสถานการณ์แบบหลายป๊อป เป็นตัวเลือกเดียวมันเกินกว่า "ดีกว่าไม่มีอะไร"

ทุกวันนี้เครื่องโหลดบาลานซ์ระดับโลกที่ดีใช้งานได้โดยใช้เทคนิคและทำงานได้ดี ตรวจสอบตัวอย่าง Azure Traffic Manager https://azure.microsoft.com/en-us/services/traffic-manager/

หากคุณต้องการเรียนรู้เพิ่มเติมอ่านบันทึกแอปพลิเคชันที่

http://edgedirector.com

มันครอบคลุม: failover, load balancing ทั่วโลกและโฮสต์ของเรื่องที่เกี่ยวข้อง

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

คำตอบสั้น ๆ : มันใช้งานได้ แต่คุณต้องเข้าใจข้อ จำกัด

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

ฉันอยากจะแนะนำให้คุณ A เลือกดาต้าเซ็นเตอร์ที่ multihomed ด้วยตัวเอง AS หรือ B โฮสต์เซิร์ฟเวอร์ชื่อของคุณในระบบคลาวด์สาธารณะ เป็นไปได้ยากมากที่ EC2 หรือ HP หรือ IBM จะลดลง แค่ความคิด ในขณะที่ DNS ทำงานเป็นตัวแก้ไขมันเป็นเพียงการแก้ไขการออกแบบที่ไม่ดีในรากฐานเครือข่ายในกรณีนี้

ตัวเลือกอื่นขึ้นอยู่กับสภาพแวดล้อมของคุณคือการใช้การรวมกันกับ IPSLA, PBR และ FHRP เพื่อให้บรรลุความต้องการสำรองของคุณ