سؤال لماذا لا يستحسن تجاوز الفشل في نظام أسماء النطاقات؟


من القراءة ، يبدو أن فشل نظام أسماء النطاقات غير مستحسن فقط لأن DNS لم يتم تصميمه لذلك. ولكن إذا كان لديك اثنين من خوادم الويب على شبكات فرعية مختلفة تستضيف محتوى فائضًا ، فما الطرق الأخرى المتوفرة لضمان توجيه كل حركة المرور إلى الخادم المباشر في حالة سقوط خادم واحد؟

بالنسبة لي يبدو أن فشل نظام أسماء النطاقات هو خيار الفشل الوحيد هنا ، ولكن الإجماع ليس خيارًا جيدًا. ومع ذلك ، فإن خدمات مثل DNSmadeeasy.com توفره ، لذلك يجب أن تكون هناك ميزة لذلك. أي تعليقات؟


166
2017-08-30 17:57


الأصل


نظرة هنا للحصول على مناقشة محدثة حول هذا الموضوع. يتم الآن تجاوز الفشل تلقائيًا بواسطة المتصفحات الحديثة. - GetFree


الأجوبة:


عن طريق 'فشل DNS' أعتبر أنك تقصد DNS Round Robin مع بعض المراقبة ، بمعنى نشر عناوين IP متعددة لاسم مضيف DNS ، وإزالة عنوان ميت عندما تكشف المراقبة أن الخادم معطّل. يمكن أن يكون ذلك قابلاً للتطبيق في المواقع الصغيرة التي لا يتم الاتجار بها.

حسب التصميم ، عندما تقوم بالرد على طلب DNS ، فإنك تقدم أيضًا وقتًا للحياة (TTL) للاستجابة التي تسلمها. بعبارة أخرى ، أنت تخبر ملقمات DNS ومخازن أخرى "يمكنك تخزين هذه الإجابة واستخدامها لمدة × دقائق قبل التحقق مرة أخرى معي". العيوب تأتي من هذا:

  • مع تجاوز فشل نظام أسماء النطاقات ، ستحصل نسبة غير معروفة من المستخدمين على بيانات نظام أسماء النطاقات المخزنة مؤقتًا بكميات متبقية من TTL متبقية. حتى تنتهي صلاحية TTL قد تتصل هذه بالخادم الميت. هناك طرق أسرع لاستكمال تجاوز الفشل من هذا.
  • نظرًا لما سبق ، أنت تميل إلى ضبط مدة TTL منخفضة جدًا ، على سبيل المثال ، 5-10 دقائق. ولكن إعداده أعلى يعطي فائدة أداء (صغيرة جدًا) ، وقد يساعد في نشر DNS بشكل موثوق به حتى إذا كان هناك خلل قصير في حركة مرور الشبكة. لذلك ، فإن استخدام تجاوز الفشل المستند إلى DNS يتعارض مع TTLs عالية ، ولكن TTLs عالية هي جزء من DNS ويمكن أن تكون مفيدة.

تشمل الطرق الأكثر شيوعًا للحصول على وقت تشغيل جيد:

  • وضع خوادم معا على نفس الشبكة المحلية.
  • ضع الشبكة المحلية LAN في مركز البيانات مع مستويات طاقة وشبكة متوفرة بشكل كبير.
  • استخدم موازن تحميل HTTP لنشر التحميل وفشل في فشل الخادم الفردي.
  • احصل على مستوى التكرار / وقت التشغيل المتوقع الذي تحتاجه لجدران الحماية وموازن التحميل والمفاتيح.
  • ضع إستراتيجية اتصال في مكانها لإخفاقات مركز البيانات الكاملة ، والفشل العرضي لخادم / خادم قاعدة بيانات / مورد آخر لا يمكن نسخه بسهولة.

تستخدم أقلية صغيرة جدًا من مواقع الويب إعدادات متعددة مراكز البيانات ، مع "التوازن الجغرافي" بين مراكز البيانات.


93
2017-08-30 18:39



أعتقد أنه يحاول على وجه التحديد إدارة الفشل بين مركزين مختلفين للبيانات (لاحظ التعليقات حول الشبكات الفرعية المختلفة) ، لذا فإن وضع الخوادم معًا / استخدام موازنات التحميل / التكرار الإضافي لن يساعده (بصرف النظر عن مراكز البيانات المتكررة). لا تزال بحاجة إلى إخبار الإنترنت بالذهاب إلى الإنترنت الذي لا يزال مستمراً). - Cian
إضافة anycast إلى إعداد datacenter متعددة ويصبح دليلاً فشل مركز البيانات. - petrus
دخول ويكيبيديا على anycast (en.wikipedia.org/wiki/Anycast) يناقش هذا فيما يتعلق بمرونة خادم الجذر DNS. - dunxd
هجمات DDoS شائعة جدًا الآن يمكن جلب مراكز البيانات بالكامل بلا اتصال (حدث لـ Linode London ومراكز البيانات الأخرى في ديسمبر 2015). لذلك لا ينصح باستخدام نفس المزود ، في نفس مركز البيانات. لذلك ، فإن العديد من مراكز البيانات مع موفرين مختلفين ستكون استراتيجية جيدة ، والتي تعيدنا إلى الفشل في DNS ما لم يكن هناك بديل أفضل. - Laurence Cope
ليس سبب وجود فشل ، لأنك تحتاج إلى الحفاظ على موقعك مباشرة عندما يكون الجهاز معطلا / معطوبة؟ ما هي الفائدة من الفشل عندما تكون في نفس الشبكة التي تتشارك نفس الأجهزة على سبيل المثال؟ أجهزة التوجيه؟ - user2128576


يعمل تجاوز نظام أسماء النطاقات DNS بشكل رائع. لقد قمت باستخدامه لسنوات عديدة لتحويل حركة المرور يدويًا بين مراكز البيانات ، أو تلقائيًا عندما تقوم أنظمة المراقبة باكتشاف الأعطال ، أو مشكلات في الاتصال ، أو الخوادم الزائدة التحميل. عندما ترى السرعة التي تعمل بها ، وحجم حركة المرور في العالم الحقيقي التي يمكن نقلها بسهولة - لن تنظر إلى الوراء أبداً. أستخدم Zabbix لمراقبة جميع أنظمتنا والرسومات البيانية المرئية التي تظهر ما يحدث أثناء وضع تجاوز الفشل في نظام أسماء النطاقات وضع جميع شكوكي وتنتهي. قد يكون هناك بعض مزودي خدمات الإنترنت الخارجين هناك الذين يتجاهلون TTLs ، وهناك بعض المستخدمين ما زالوا موجودين مع المتصفحات القديمة - ولكن عندما تنظر إلى حركة المرور من ملايين من مشاهدات الصفحة في أي يوم عبر مركزي مراكز البيانات وتجري تغييرًا في حركة مرور نظام أسماء النطاقات - حركة المرور المتبقية في يتجاهل TTLs مثير للضحك. فشل DNS هو تقنية متينة.

لم يكن نظام أسماء النطاقات مصممًا لتجاوز الفشل - ولكن تم تصميمه مع TTLs التي تعمل بشكل مذهل لحاجات تجاوز الفشل عندما تقترن بنظام مراقبة صلب. يمكن تعيين TTLs قصيرة جدًا. لقد استخدمت بشكل فعال TTLs من 5 ثوان في الإنتاج لإيجاد حلول سريعة تستند إلى فشل DNS. يجب أن يكون لديك خوادم DNS قادرة على التعامل مع التحميل الإضافي - ولن يتم تسميتها باسم. ومع ذلك ، يناسب powerdns الفاتورة عند إجراء نسخ احتياطي مع قواعد بيانات منسوخة نسخاً متماثلاً على خوادم اسم مكرر. تحتاج أيضًا إلى نظام مراقبة دقيق موزع يمكنك الوثوق به في تكامل تجاوز الفشل التلقائي. يعمل Zabbix بالنسبة لي - يمكنني التحقق من حالات انقطاع الخدمة من أنظمة Zabbix الموزعة على الفور تقريبًا - قم بتحديث سجلات mysql المستخدمة من قبل powerdns على الطاير - وتوفير الفشل الفوري تقريباً أثناء حالات انقطاع التيار الكهربائي والحركة المرورية.

ولكن مهلا - لقد قمت ببناء شركة تقدم خدمات تجاوز الفشل DNS بعد سنوات من جعلها تعمل لصالح الشركات الكبيرة. لذا خذ رأيي بحبوب الملح. إذا كنت ترغب في رؤية بعض الرسوم البيانية لحركة المرور من zabbix للمواقع ذات حجم الصوت المرتفع أثناء الانقطاع - لترى بنفسك مدى كفاءة فشل نظام DNS بنجاح - أرسل لي بريدًا إلكترونيًا يسعدني جدًا مشاركته.


44
2017-10-20 17:17



جواب سيان serverfault.com/a/60562/87017 يتناقض بشكل مباشر مع واحد ..... لذا من هو على حق؟ - Pacerier
من تجربتي أن TTLs قصيرة لا تعمل عبر الإنترنت. قد تقوم بتشغيل خوادم DNS التي تحترم طلبات RFC - ولكن هناك الكثير من الخوادم التي لا توجد. من فضلك لا تفترض أن هذه حجة ضد Round Robin DNS - انظر أيضا إجابة vmiazzo أدناه - لقد قمت بتشغيل المواقع المزدحمة باستخدام RR DNS واختبرته - إنه يعمل. المشاكل الوحيدة التي واجهتها كانت مع بعض عملاء جافا (وليس المتصفحات) التي لم تحاول حتى إعادة الاتصال عند الفشل ناهيك عن تدوير قائمة المضيفات على RST - symcbean
أراهن أن الأشخاص الذين يقولون بأن الفشل في رصد نظام أسماء النطاقات هو أمر رائع ، وأن الأشخاص الذين يقولون أنه يمتص لديهم تجارب مماثلة ، ولكن مع توقعات مختلفة. إن فشل نظام أسماء النطاقات (DNS) ليس سلسًا ، ولكنه يمنع التوقف بشكل كبير. إذا كنت في حاجة إلى وصول سلس تمامًا (لا تفقد طلبًا واحدًا ، حتى أثناء فشل الخادم) ، فربما تحتاج إلى هندسة معمارية أكثر تقدمًا وكلفة. هذا ليس مطلبا للعديد من التطبيقات. - Tom Wilson


تكمن المشكلة في فشل نظام أسماء النطاقات (DNS) في أنه ، في كثير من الحالات ، غير موثوق به. سيتجاهل بعض موفري خدمة الإنترنت TTLs ، ولا يحدث ذلك على الفور حتى إذا كانوا يحترمون TTLs ، وعندما يعود موقعك ، قد يؤدي ذلك إلى بعض الغرابة في الجلسات عندما تنتهي مهلة ذاكرة DNS للمستخدم ، وينتهي الأمر بهم إلى الخادم الآخر.

للأسف ، إنه الخيار الوحيد إلى حد كبير ، ما لم تكن كبيرًا بما يكفي للقيام بتوجيهك الخاص (الخارجي).


31
2017-08-30 18:27



+1 بطيئة وغير موثوق بها - Chris S
انظر أيضا serverfault.com/q/315199/87017 - Pacerier


الرأي السائد هو أنه مع RR RR ، عندما ينخفض ​​عنوان IP ، سيستمر بعض العملاء في استخدام عنوان IP المكسور لدقائق. جاء ذلك في بعض الإجابات السابقة على السؤال ، كما أنه كتب على ويكيبيديا.

على أي حال،

http://crypto.stanford.edu/dns/dns-rebinding.pdf يشرح أنه غير صحيح لمعظم متصفحات HTML الحالية. سوف يحاولوا IP التالي في ثوان.

http://www.tenereillo.com/GSLBPageOfShame.htm يبدو أكثر قوة:

إن استخدام سجلات A المتعددة ليس خدعة للتجارة ، أو ميزة تصورها موردي معدات موازنة الأحمال. تم تصميم بروتوكول DNS مع دعم سجلات A متعددة لهذا السبب بالذات. تطبيقات مثل المتصفحات والوكلاء وخوادم البريد الاستفادة من هذا الجزء من بروتوكول DNS.

ربما يستطيع بعض الخبراء التعليق وتقديم تفسير أكثر وضوحًا لسبب عدم صلاحية RR في نظام أسماء النطاقات لعدم توفره بشكل كبير.

شكر،

فالنتينو

ملاحظة: آسف للارتباط المعطوب ، ولكن ، كمستخدم جديد ، لا أستطيع نشر أكثر من 1


19
2017-09-29 10:06



تم تصميم سجلات A متعددة ، ولكن لموازنة الحمل ، بدلاً من الفشل. سيقوم العملاء بتخزين النتائج مؤقتًا والاستمرار في استخدام المجموعة الكاملة (بما في ذلك عنوان IP المكسور) لبضع دقائق بعد تغيير السجل. - Cian
إذن ، ما هو مكتوب crypto.stanford.edu/dns/dns-rebinding.pdf الفصل 3.1 خاطئة؟ << يربط Internet Explorer 7 ارتباطات DNS لمدة 30 دقيقة. 1 لسوء الحظ ، إذا كان نطاق المهاجم يحتوي على سجلات A متعددة ولن يصبح الخادم الحالي متاحًا ، فسيحاول المتصفح عنوان IP مختلفًا خلال ثانية واحدة. >> - Valentino Miazzo
انتقلت إلى subquestion هنا serverfault.com/questions/69870/... - Valentino Miazzo


لقد قمت بتشغيل تجاوز RR لنظام أسماء النطاقات (DNS RR) على موقع ويب للإنتاج المعتدل ، ولكنه ذو أهمية تجارية (عبر منطقتين جغرافيتين) لسنوات عديدة.

إنه يعمل بشكل جيد ، ولكن هناك على الأقل ثلاث خفايا تعلمت بالطريقة الصعبة.

1) ستفشل المستعرضات من IP غير عامل إلى IP يعمل بعد 30 ثانية (آخر مرة راجعت) إذا كان كلاهما يعتبران نشطين في أي DNS مخبأ متاح لعملائك. هذا هو في الأساس أمر جيد.

ولكن وجود "نصف" للمستخدمين الانتظار 30 ثانية غير مقبول ، لذلك ربما تريد تحديث سجلات TTL الخاصة بك لتكون بضع دقائق ، وليس بضعة أيام أو أسابيع بحيث في حالة انقطاع ، يمكنك بسرعة إزالة الخادم لأسفل من DNS الخاص بك. وقد ألمح آخرون لهذا في ردودهم.

2) في حالة سقوط أحد خوادم الأسماء (أو واحد من منطقتك الجغرافية بالكامل) والذي يخدم نطاق نطاقك المستدير ، وفي حالة انحسار واحد أساسي منها ، أذكر بشكل خفي أنه يمكنك الدخول في مشكلات أخرى تحاول إزالتها خوارزمية downed من DNS إذا لم تقم بتعيين TTA SOA / انتهاء الصلاحية لخادم الأسماء إلى قيمة منخفضة بما فيه الكفاية أيضًا. يمكنني الحصول على التفاصيل الفنية بشكل خاطئ هنا ، ولكن هناك أكثر من إعداد TTL واحد فقط تحتاج إلى الحصول على حق في الدفاع حقًا ضد نقاط الفشل الفردية.

3) إذا قمت بنشر واجهات برمجة تطبيقات ويب ، خدمات REST ، إلخ ، فإن تلك لا تسمى عادةً بواسطة المتصفحات ، وبالتالي في رأيي ، يبدأ تجاوز فشل نظام أسماء النطاقات في إظهار العيوب الحقيقية. قد يكون هذا هو السبب في أن البعض يقول ، على حد تعبيره "لا يوصى به". هنا لماذا أقول ذلك. أولاً ، لا تعد التطبيقات التي تستهلك عناوين URL هذه عادةً متصفحات ، لذا فهي تفتقر إلى خصائص / منطق الفشل 30 ثانية للمتصفحات الشائعة. ثانيًا ، ما إذا كان إدخال نظام أسماء النطاقات الثاني مسمىًا أم لا ، أو حتى إعادة استقصاء DNS يعتمد كثيرًا على تفاصيل البرمجة ذات المستوى المنخفض لمكتبات الشبكات في لغات البرمجة المستخدمة من قِبل عملاء API / REST ، بالإضافة إلى كيفية استدعائهم بواسطة التطبيق العميل API / REST. (تحت غطاء ، هل تستدعي المكتبة get_addr ، ومتى؟ إذا كانت المآخذ معلقة أو مغلقة ، هل يعيد التطبيق فتح مآخذ جديدة؟ هل هناك نوع من منطق الخروج؟ إلخ.)

انها رخيصة ، واختبارها بشكل جيد ، و "يعمل في الغالب". كما هو الحال مع معظم الأشياء ، قد تختلف الأميال الخاصة بك.


11
2018-04-12 01:21



مكتبة غير محاولة على RRs الأخرى لعنوان مقطوع. أشر إلى المطورين في الصفحات اليدوية لـ getaddrinfo () إلخ. - Jasen


هناك مجموعة من الأشخاص الذين يستخدموننا (Dyn) للفشل. إنه نفس السبب الذي يجعل المواقع تقوم إما بصفحة الحالة عندما يكون لديهم وقت توقف عن العمل (فكر في أشياء مثل Fail Whale) من تويتر ... أو ببساطة قم بإعادة توجيه حركة المرور استنادًا إلى TTLs. قد يعتقد بعض الناس أن DNS Failover هو ghetto ... لكننا صممنا بشكل جدي شبكتنا مع تجاوز الفشل من البداية ... بحيث تعمل بشكل جيد وكذلك الأجهزة. لست متأكدًا من كيفية قيام DME بذلك ، ولكن لدينا 3 من أصل 17 من أقرب نقاط PoP الخاصة بنا والتي تم رصدها ، والتي تراقب خادمك من أقرب موقع. عندما يكتشف من اثنين من الثلاثة أنه أسفل ، نقوم ببساطة بإعادة توجيه حركة المرور إلى IP الآخر. وقت التوقف الوحيد هو لتلك التي كانت في ذلك المطلوبة لبقية فترة TTL تلك.

بعض الناس يفضلون استخدام كلا الخادومين دفعة واحدة ... وفي هذه الحالة يمكن أن يفعلوا شيئًا مثل توازن تحميل روبن الدائري ... أو موازنة التحميل على أساس جيو. بالنسبة لأولئك الذين يهتمون بالأداء فعليًا ... سيقوم مدير حركة المرور لدينا في الوقت الفعلي بمراقبة كل خادم ... وإذا كان أحدهم أبطأ ... قم بإعادة توجيه حركة المرور إلى أسرع مسار بناءً على عناوين IP التي تقوم بربطها في أسماء مضيفيك. مرة أخرى ... يعمل هذا بناءً على القيم التي تضعها في واجهة المستخدم / واجهة برمجة التطبيقات / البوابة.

أعتقد أن وجهة نظري هو ... نحن المهندسون DNS الفشل عن قصد. على الرغم من أن نظام أسماء النطاقات لم يتم إعداده لتجاوز الفشل عندما تم إنشاؤه أصلاً ... فقد تم تصميم شبكة DNS الخاصة بنا لتنفيذها من البداية. عادة ما تكون فعالة مثل الأجهزة ... دون استهلاك أو تكلفة الأجهزة. نأمل أن لا يجعلني أعرج سليم لربط الديناميت ... هناك الكثير من الشركات الأخرى التي تفعل ذلك ... أنا أتحدث فقط من وجهة نظر فريقنا. أتمنى أن يساعدك هذا...


9
2018-05-25 19:38



ماذا تقصد ب "يمكن أن تكون بنفس فعالية الأجهزة"؟ ما نوع الأجهزة التي يقوم بها توجيه DNS؟ - mpen
@ ريان ، ماذا تقصد عندما تقول "غيتو"؟ - Pacerier
لهذه الكلمة القاموس الحضري لا يعطي تعاريف مع دلالة إيجابية ، وأنا أفترض أن "حل المتسول" قد يكون ترجمة مناسبة. - Jasen


هناك خيار آخر يتمثل في إعداد خادم اسم 1 في الموقع A وخادم الاسم 2 في الموقع B ، ولكن مع تعيين كل واحد منها بحيث تكون جميع سجلات A في حركة مرور NS1 نقطة إلى عناوين IP للموقع A ، وعلى NS2 تشير جميع السجلات A إلى عناوين IP لـ الموقع B. ثم قم بتعيين TTLs لرقمًا منخفضًا للغاية ، وتأكد من إعداد سجل النطاق في موقع التسجيل لـ NS1 و NS2. وبهذه الطريقة ، سيتم تحميل الرصيد تلقائيًا ، وسيتوقف تشغيل الخادم أو رابطًا واحدًا لموقع ما.

لقد استخدمت هذا النهج بطريقة مختلفة بعض الشيء. لديّ موقع واحد مزود بمزوّدي خدمة الإنترنت واستخدم هذه الطريقة لتوجيه حركة المرور على كل رابط. الآن ، قد تكون صيانة أكثر بعض الشيء مما ترغب في القيام به ... ولكنني تمكنت من إنشاء برنامج بسيط يسحب تلقائيًا سجلات NS1 ، ويقوم بتحديث عناوين IP قياسية لمناطق محددة ، ويدفع هذه المناطق إلى NS2.


5
2017-08-07 05:13



لا تأخذ خوادم الأسماء أكثر من اللازم للنشر؟ إذا قمت بتغيير سجل DNS مع TTL منخفض ، فسوف يعمل على الفور ، ولكن عندما تقوم بتغيير خادم الأسماء فسوف يستغرق الأمر 24 ساعة أو أكثر للنشر ، وبالتالي لا أرى كيف يمكن أن يكون هذا حل تجاوز. - Marco Demaio


البديل هو نظام الفشل القائم على BGP. ليس من السهل إعداده ، ولكن يجب أن يكون دليلاً مضادًا للرصاص. قم بإعداد الموقع A في مكان واحد ، والموقع B في الثانية مع جميع عناوين IP المحلية ، ثم احصل على الفئة C أو مجموعة أخرى من عناوين IP التي تكون محمولة وأعد إعادة التوجيه من عناوين IP المحمولة إلى عناوين IP المحلية.

هناك مزالق ، لكنها أفضل من الحلول المستندة إلى DNS إذا كنت بحاجة إلى مستوى التحكم هذا.


4
2017-08-30 21:40



الحلول المستندة إلى BGP ليست متاحة للجميع على الرغم من ذلك. وأسهل بكثير اختراق طرق مروعة بشكل خاص من DNS. التقلبات والدوارات ، أفترض. - Cian


يتمثل أحد الخيارات لتجاوز الفشل في مراكز البيانات المتعددة في تدريب المستخدمين. نحن نعلن لعملائنا بأننا نوفر خوادم متعددة في مدن متعددة وفي رسائل البريد الإلكتروني الخاصة بنا للاشتراك ، مثل الارتباطات مباشرة بكل "خادم" بحيث يعرف المستخدمون ما إذا كان أحد الخوادم معطلاً يمكنهم استخدام الرابط إلى الخادم الآخر.

هذا يتجاوز تماما مشكلة فشل DNS من خلال الحفاظ على أسماء نطاق متعددة. يتم توجيه المستخدمين الذين يتوجهون إلى www.company.com أو company.com وتسجيل الدخول إلى server1.company.com أو server2.company.com ولديهم خيار الإشارة إلى أي من تلك العلامات إذا لاحظوا أنهم يحصلون على أداء أفضل باستخدام أحدهما أو الآخر . إذا كان أحد ينخفض ​​يتم تدريب المستخدمين للذهاب إلى الخادم الآخر.


3
2017-10-11 22:11



قم بتدريب مستخدميك بهذه الطريقة ... ألا يجعلهم هذا أكثر عرضة للخداع؟ - Pacerier


لقد كنت أستخدم موازنة موقع ويب تستند إلى DNS وتجاوز الفشل خلال السنوات العشر الماضية ، وهناك بعض المشكلات ، ولكن يمكن التخفيف منها. BGP ، على الرغم من التفوق في بعض النواحي ليس حلًا بنسبة 100٪ سواء مع زيادة التعقيد ، أو ربما تكاليف الأجهزة الإضافية ، أو أوقات التقارب ، إلخ ...

لقد وجدت أن الجمع بين موازنة التحميل المحلية (على أساس الشبكة المحلية) ، واستضافة GSLB ، واستضافة المناطق السحابية تعمل بشكل جيد لإغلاق بعض المشكلات المرتبطة عادةً بموازنة تحميل DNS.


2
2017-08-23 01:50