एनएसडी डीएनएस सर्वर पर स्विच करने का अनुभव

2007 में वापस, जब Ukrnames अभी भी छोटा था और इसके पहले कदम उठाए, ज्यादातर काम प्रोग्रामर द्वारा किया गया था। उन्होंने एक डोमेन प्रबंधन प्रणाली विकसित की, और इसका परीक्षण किया, और उन सर्वरों का प्रशासन किया जहां यह सब काम किया।

और जहाँ डोमेन हैं, वहाँ DNS है। और DNS सर्वर बनाने का सबसे आसान तरीका क्या है? सर्वव्यापी बाँध रखो। हां, BIND आसान नहीं है, लेकिन MySQL के साथ दोस्त बनाने के लिए DLZ पैच के साथ।

साल बीत गए, सिस्टम ने काम किया, सर्वर कैपेसिटी बढ़ी। और हमेशा की तरह, काम करते समय - स्पर्श न करें। तो यह सब जारी रहेगा अगर लोड अगले 8-कोर सर्वर के खिलाफ आराम करने के लिए शुरू नहीं हुआ।

इस बिंदु पर, मुझे एक मजबूत निर्णय लेने और DNS सर्वरों की एक नई प्रणाली का निर्माण करना था, बजाय एक बार फिर से अतुलनीय BIND + DLZ के लिए हार्डवेयर को अपग्रेड करना।

और फिर परी कथा समाप्त हो गई, और व्यवस्थापक के कठोर सप्ताह शुरू हो गए।

हमारे पास क्या है?

यह आवश्यक है कि जिस सेवा के लिए Ukrnames मुफ्त में डोमेन के लिए प्रदान करता है, अर्थात् "प्रबंधित DNS"।

फिलहाल, यह सेवा एक लाख से अधिक डोमेन के लिए उपयोग की जाती है। डोमेन विविध हैं, क्रमशः अलग-अलग उपस्थिति के साथ, लोड डोमेन की संख्या पर निर्भर नहीं करता है।

Xeon X3430, 8Gb DDR3, 2x500Gb SATA RAID1 के विन्यास के साथ सेवा 3 DNS सर्वर द्वारा दी जाती है। सर्वर MySQL के साथ संयोजन में BIND + DLZ पैच का उपयोग करते हैं। डेटाबेस डोमेन ज़ोन के लिए वर्तमान में सक्रिय भंडारण सर्वर के दास के रूप में काम करता है।

अपने आप समस्याओं की तलाश ... सिर

• उच्च भार, 100% सर्वर क्षमता का उपयोग किया जाता है। आधा MySQL में है, दूसरा आधा BIND में है।
• DLZ पैच पहले से पुराना है और विकसित नहीं हो रहा है। अंतहीन BIND के नए संस्करणों के लिए एक पैच रीमेक करना सबसे अच्छा तरीका नहीं है।
• अन्य समाधानों का उपयोग करते समय, पुराने डेटाबेस की समस्या उत्पन्न होती है, जिसे शुरू में बिना किसी विशेष जांच के भरा गया था। बहुत सारा कचरा, ढेर सारे रिकॉर्ड जो आरएफसी के अनुरूप नहीं हैं। कोई भी कॉर्पसेंट डीएनएस उन्हें स्वीकार नहीं करेगा।

टैम्बोरिन को उजागर करें

MySQL और NSD (फाइलों पर काम) के साथ PowerDNS को मौजूदा विविधता से चुना गया था।
पुराने BIND और इन दो impostors के लिए एक प्रतियोगिता बनाने का निर्णय लिया गया।

हम PowerDNS को देखते हैं

पहली नज़र में, एक डीएनएस सर्वर लेने के लिए सबसे तार्किक विकल्प है, जो बॉक्स से बाहर एक MySQL डेटाबेस के साथ काम कर सकता है और इसे मौजूदा डेटाबेस से बाँध सकता है।

व्यवहार में, यह पता चला कि मौजूदा डेटाबेस के साथ और पावरडएनएस की आवश्यकता के साथ, कई बल्कि अप्रिय मतभेद पाए गए थे।

नतीजतन, कार्यान्वयन के लिए, या तो डेटाबेस की संरचना को बदलना आवश्यक था, और इससे पूरे सिस्टम के कोड में बदलाव होगा। या तो बैसाखी का निर्माण, अर्थात् एक प्रक्रिया या दृश्य।

प्रतियोगिता के लिए, दूसरा विकल्प चुना गया था, क्योंकि मुख्य प्रणाली को छूना असंभव था।

एनएसडी महसूस कर रहा है

विकिपीडिया द्वारा देखते हुए, एनएसडी सफलतापूर्वक 3 रूट सर्वर पर चलता है।

NSD की एक विशेषता यह है कि यह सभी क्षेत्रों को अपने आंतरिक डेटाबेस प्रारूप में संकलित करता है, और फिर इसे पूरी तरह से RAM में लोड करता है।

डेवलपर की साइट में रैम की खपत की गणना करने के लिए एक उपकरण है । हमारे मामले में, यह लगभग 367 एमबी निकला, जो स्वीकार्य परिणाम से अधिक था।

हम एक टैम्बोरिन चार्ज करते हैं

एक उपयोगिता लिखी गई थी जो डीएनएस सर्वर को 50 थ्रेड्स में अनुरोध भेजती है। डोमेन को किसी मौजूदा डेटाबेस से यादृच्छिक रूप से चुना गया था, रिकॉर्ड के प्रकार भी बेतरतीब ढंग से बदल गए।

PowerDNS के लिए, एक दृश्य लिखा गया था जो वांछित प्रारूप में डेटा लौटाता है। परीक्षण के दौरान, यह अनुकूलन के लिए 3 बार फिर से लिखा गया था।

NSD के लिए, मेरे पसंदीदा Google Go पर लिखा गया था, एक कनवर्टर उपयोगिता जो पूरे डेटाबेस का नमूना लेती थी और डेटाबेस को आंतरिक NSD प्रारूप में इकट्ठा करती थी।

दोनों ही मामलों में, RFC के साथ सभी विसंगतियों को पाचन योग्य रूप में परिवर्तित करने के लिए तार्किक फिल्टर का उपयोग किया गया था।

आधार को दीर्घकालिक मलबे से भी साफ किया गया था। बिना मुहावरे के भाव नहीं हो सकते थे। मैंने कभी नहीं सोचा होगा कि इसे डीएनएस में रिकॉर्ड किया जा सकता है। CNAME रिकॉर्ड में URL और MX में पासवर्ड वाले ईमेल थे। जाहिर है, शुरू में, प्रोग्रामर भी उपयोगकर्ताओं पर विश्वास करते थे, और रिकॉर्ड के लिए सामान्य फिल्टर नहीं बनाते थे।

हम नाचते हैं

बदले में, प्रत्येक प्रतिभागी के लिए एक परीक्षा आयोजित की गई थी। परीक्षण की अवधि 10 मिनट है। एक मिनट में, अंतिम मिनट के लिए औसत प्रतिक्रिया समय और प्रतिशत में वर्तमान प्रोसेसर लोड बचाया जाता है। परीक्षण को एक मशीन पर उसी विन्यास के साथ किया गया था, जैसा कि युद्ध डीएनएस सर्वर।

PowerDNS को MySQL के प्रश्नों की संख्या को कम करने के लिए SOA को स्वतंत्र रूप से जेनरेट करने के लिए कॉन्फ़िगर किया गया था, 1 मिनट के लिए रिकॉर्ड कैश भी शामिल था।
एनएसडी ने एक मानक विन्यास में, 4 थ्रेड्स में काम किया।

परिणाम

BIND + DLZ ने खुद को हमेशा की तरह दिखाया, बहुत बड़ा रिस्पांस टाइम, स्पेस लोड।

PowerDNS ने अच्छा प्रदर्शन दिखाया, साथ ही BIND ने मुख्य डेमॉन और MySQL को लगभग 50 से 50 लोड दिया। और वह एक नेता होगा यदि परीक्षण में एनएसडी नहीं था ...

प्रतिक्रिया समय:




सीपीयू लोड:




एनएसडी के साथ परीक्षण 3 बार दोहराया गया था, जैसा कि लगातार लग रहा था कि कुछ गलत है, और यह नहीं हो सकता है।

परिणाम

वास्तव में परिणाम खुद ही पता चलता है।

MySQL में लॉजिक एक कमजोर बिंदु है। प्राप्तकर्ता पर पहले से ही इस तरह के डेटा को संसाधित करना और यथासंभव कुछ अनुरोध करना बेहतर है।

DNS के लिए, यह ठीक है अगर डेटा आधे घंटे से अधिक अपडेट नहीं किया जाता है। कनवर्टर की उपयोगिता 7 सेकंड में पूरी होती है और एक मिनट के अपडेट के लिए अनुमति देता है।

अब हमारे पास सर्वरों पर चलने वाली एनएसडी है और हम जल्द ही हार्डवेयर को अपग्रेड करने के बारे में नहीं सोचते हैं, सिवाय ड्राइव को बदलने के बारे में और हाल ही में।