หลีกเลี่ยงการหมดเวลา DNS เมื่อเซิร์ฟเวอร์ dns ล้มเหลว


17

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

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

คำตอบที่ดีที่สุดของฉันน่าจะเป็น "RTFM: tweak /etc/resolv.conf เช่นนี้ ... " แต่ถ้านั่นเป็นตัวเลือกที่ฉันไม่ได้เห็น

ฉันสงสัยว่าคนอื่นจัดการปัญหานี้ได้อย่างไร

ฉันเห็นโซลูชันที่เป็นไปได้ 3 ประเภท:

  • ใช้ linux-ha / Pacemaker และ ips failover (ดังนั้น dns IP VIP จะ "พร้อมเสมอ") อนิจจาเราไม่มีโครงสร้างพื้นฐานการฟันดาบที่ดีและหากไม่มีการฟันดาบเครื่องกระตุ้นหัวใจก็ไม่ได้ผลดีนัก (จากประสบการณ์ของฉัน

  • รันเซิร์ฟเวอร์ dns โลคัลบนแต่ละโหนดและมี resolv.conf ให้ชี้ไปที่ localhost สิ่งนี้ใช้งานได้ แต่มันจะทำให้เรามีบริการมากขึ้นในการตรวจสอบและจัดการ

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

การคัดเลือกนักแสดงดูเหมือนว่าจะทำงานที่ระดับการจัดเส้นทาง ip เท่านั้นและขึ้นอยู่กับการอัพเดทเส้นทางสำหรับความล้มเหลวของเซิร์ฟเวอร์ Multi-casting ดูเหมือนว่าจะเป็นคำตอบที่สมบูรณ์แบบ แต่การเชื่อมโยงไม่รองรับการออกอากาศหรือ multi-casting และ docs ที่ฉันสามารถหาได้ดูเหมือนจะแนะนำว่า multicast dns มุ่งเน้นไปที่การค้นพบบริการและตั้งค่าอัตโนมัติมากกว่าการแก้ไข DNS ปกติ .

ฉันขาดวิธีแก้ปัญหาที่ชัดเจนหรือไม่?


2
ฉันขอแนะนำว่านอกเหนือจากการค้นหาโซลูชันที่คุณขอ (ซึ่งฉันไม่สามารถช่วยคุณได้) คุณควรทำงานกับปัญหาของรูทจริงและแก้ไขปัญหาความน่าเชื่อถือกับเซิร์ฟเวอร์ DNS
John Gardeniers

ปัญหาหลักคือ: ทำไมเซิร์ฟเวอร์ DNS เหล่านี้ถึงลงบ่อยครั้งที่ทำให้คุณกังวลเกี่ยวกับเรื่องนี้? พิจารณาจำลอง DNS ของคุณด้วยบริการพิเศษเช่นBuddyNS เวลาแฝงของคุณจะลดลงอย่างมากและเวลาทำงานจะไม่ทำให้คุณกังวลเกี่ยวกับ /etc/resolv.conf tweaks อีกต่อไป
michele

คำตอบ:


15

คู่ของตัวเลือก ทั้งสองจะกระจายโหลด DNS ไปยังเซิร์ฟเวอร์ DNS ของคุณ

  • ลองใช้options rotateใน resolv.conf สิ่งนี้จะลดผลกระทบของเซิร์ฟเวอร์หลักให้น้อยลง หากเซิร์ฟเวอร์ตัวใดตัวหนึ่งหยุดทำงานจะทำให้การทำงานช้าลง
  • ใช้ลำดับเนมเซิร์ฟเวอร์ต่างกันสำหรับไคลเอนต์ต่าง ๆ สิ่งนี้จะทำให้ไคลเอนต์บางตัวทำงานได้ตามปกติถ้าเซิร์ฟเวอร์ DNS หลักไม่ทำงาน สิ่งนี้จะกระจายผลกระทบของเซิร์ฟเวอร์ DNS ที่ไม่ได้ใช้งานอยู่ทั่ว

options timeout:1 attempts:5ตัวเลือกเหล่านี้สามารถใช้ร่วมกับ เพิ่มความพยายามถ้าคุณลดการหมดเวลาเพื่อให้คุณสามารถจัดการเซิร์ฟเวอร์ภายนอกที่ช้า

ขึ้นอยู่กับการกำหนดค่าเราเตอร์ของคุณคุณอาจจะสามารถกำหนดค่าเซิร์ฟเวอร์ DNS ของคุณให้ใช้ที่อยู่ IP ของเซิร์ฟเวอร์ DNS หลักเมื่อเซิร์ฟเวอร์หยุดทำงาน สามารถใช้ร่วมกับเทคนิคข้างต้น

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


4

ลองดู "man resolv.conf" คุณสามารถเพิ่มตัวเลือกการหมดเวลาใน resolv.conf ค่าเริ่มต้นคือ 5 แต่การเพิ่มต่อไปนี้เพื่อ resolv.conf ควรทำให้มันลดลงเป็น 1 วินาที:

ตัวเลือกการหมดเวลา: 1


หลังจากอ่านย่อหน้าที่สองของคุณฉันได้ลองข้างต้นใน Centos และ Debian VPS หลังจากนำ DNS หลักลงมาตัวแก้ไขจะทำงานตามที่คาดไว้ ใช้ tcpdump ฉันสามารถเห็นตัวแก้ไขพยายามใช้เซิร์ฟเวอร์ตัวแรกจากนั้นลองถัดไป คุณเห็นพฤติกรรมอะไร
Niall Donegan

1
มีสองกรณีการใช้งานขนาดใหญ่สำหรับการแก้ไข: กระบวนการแบบสั้น (เช่นเครื่องมือบรรทัดคำสั่ง) และกระบวนการแบบยาวและการกำหนดค่าตัวแก้ไขแบบเดียวกันต้องทำงานทั้งสองแบบ สำหรับการตั้งค่าช่วงสั้น ๆ (การค้นหาครั้งเดียว) การหมดเวลาสั้น ๆ จะล้มเหลวอย่างรวดเร็ว แต่ถ้าคุณค้นหาที่อยู่ภายนอกที่ไม่สามารถแก้ไขได้ในเวลานั้น: คุณจะไม่พบชื่อเนื่องจากตัวแก้ไขจะละทิ้งการค้นหานั้นหากไม่ได้กลับมาในครั้งที่สอง (ออกจากห้องอื่น ๆ ในการแสดงความคิดเห็นต่อไป)
นีลกฐิน

กระบวนการระยะยาวจะลองการค้นหาหมดเวลาแต่ละครั้งแล้วย้ายไปยังเซิร์ฟเวอร์ถัดไป แต่ดูเหมือนจะไม่แคช "ความตาย" ของเซิร์ฟเวอร์
Neil Katin

3

ซอฟต์แวร์การจัดกลุ่มเช่น heartbeat หรือ pacemaker / corosync คือเพื่อนของคุณที่นี่ ในฐานะที่เป็น exmple เราได้ตั้งค่าเครื่องกระตุ้นหัวใจ / corosync ดังนี้:

  • จับคู่ทุกเซิร์ฟเวอร์กับเซิร์ฟเวอร์อื่น
  • ต่อคู่มี 2 dns vips, โดยปกติจะเป็นหนึ่งในแต่ละ
  • หากการเชื่อมโยงหรือเซิร์ฟเวอร์ล้มเหลว vip จะย้ายไปยังเซิร์ฟเวอร์อื่นภายในมิลลิวินาที

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


3

รันเซิร์ฟเวอร์ dns โลคัลบนแต่ละโหนดและมี resolv.conf ให้ชี้ไปที่ localhost สิ่งนี้ใช้งานได้ แต่มันจะทำให้เรามีบริการมากขึ้นในการตรวจสอบและจัดการ

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

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

เราทำสิ่งนี้มาประมาณ 3 ปีแล้วและฉันไม่เห็นปัญหาใด ๆ ที่เกี่ยวข้องกับความล้มเหลว / การหยุดทำงานของเซิร์ฟเวอร์ dns ที่ทำงานบน localhost


2

หาก nameserver หยุดทำงานเพื่อการบำรุงรักษาเป็นขั้นตอนปกติในการลดการหมดเวลาใน SOA สำหรับโดเมนนั้นล่วงหน้าเพื่อให้เมื่อการบำรุงรักษาเกิดขึ้นการเปลี่ยนแปลง (เช่นการลบระเบียน NS ก่อนการบำรุงรักษาและนำกลับมาหลังจากการบำรุงรักษา ) เผยแพร่อย่างรวดเร็ว โปรดทราบว่านี่เป็นวิธีฝั่งเซิร์ฟเวอร์ - การเปลี่ยนตัวแก้ปัญหาเป็นวิธีฝั่งไคลเอ็นต์และ ... เว้นแต่คุณจะสามารถพูดคุยกับลูกค้าของคุณทุกคนและทำให้พวกเขาทำการปรับเปลี่ยนนี้บนเครื่องของพวกเขา ... อาจจะไม่ แนวทางที่ถูกต้อง ฉันเดาว่าคุณพูดลูกค้าเพียงร้อยรายในดาต้าเซ็นเตอร์โดยใช้เซิร์ฟเวอร์ DNS ภายใน แต่คุณต้องการเปลี่ยนการตั้งค่าสำหรับลูกค้านับร้อยเมื่อคุณสามารถเปลี่ยนโซนได้หรือไม่

ฉันจะบอกคุณว่าควรปรับค่าใดใน SOA แต่ฉันท่องเว็บเพื่อค้นหาข้อมูลที่แน่นอนเมื่อฉันพบคำถามนี้


3
คำตอบนี้เกี่ยวข้องกับ DNS ที่มีสิทธิ์เท่านั้น คำถามนี้เกี่ยวกับการค้นหา DNS แบบเรียกซ้ำที่ทำโดยซอฟต์แวร์ไคลเอ็นต์
Andrew B

1

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


0

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


เรามีโครงสร้างพื้นฐาน DNS ที่ยืดหยุ่นอย่างเป็นธรรม แต่ปีละ 2 หรือ 3 ครั้งเรามีปัญหาเนื่องจากเซิร์ฟเวอร์ dns หยุดทำงาน (หรือรีสตาร์ทหรืออัปเกรดระบบปฏิบัติการหรืออะไรก็ตาม)
Neil Katin

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

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

0

โซลูชันที่เน้นเครือข่ายมากขึ้นจะใช้เซิร์ฟเวอร์ DNS สองเครื่องที่มี IP (เฉพาะ) และการกำหนดเส้นทางAnycastเดียวกัน (ฉันไม่ได้สังเกตคำตอบนี้ในหัวข้อนี้ แต่นั่นคือสิ่งที่ใช้ที่นี่)

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

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