Habr पोस्टमार्टम रिपोर्ट: यो एक पत्रिका मा खसे

ग्रीष्म 2019 को पहिलो महिनाको अन्त्य र दोस्रो महिनाको शुरुवात गाह्रो भयो र विश्वव्यापी आईटी सेवाहरूमा धेरै प्रमुख गिरावटहरूले चिन्ह लगाइयो। उल्लेखनीय मध्येमा: क्लाउडफ्लेयर पूर्वाधारमा भएका दुई गम्भीर घटनाहरू (पहिलो - संयुक्त राज्य अमेरिकाका केही ISPs को तर्फबाट BGP तर्फ कुटिल हात र लापरवाही मनोवृत्ति; दोस्रो - CF को कुटिल तैनाती संग, जसले CF प्रयोग गर्ने सबैलाई प्रभावित गर्यो। , र यी धेरै उल्लेखनीय सेवाहरू हुन्) र Facebook CDN पूर्वाधारको अस्थिर सञ्चालन (इन्स्टाग्राम र व्हाट्सएप सहित सबै FB उत्पादनहरू प्रभावित)। विश्वव्यापी पृष्ठभूमिमा हाम्रो आउटेज धेरै कम देखिए तापनि हामीले वितरणमा पनि फस्नुपर्‍यो। कसैले कालो हेलिकप्टर र "सार्वभौम" षड्यन्त्रमा तान्न थालिसकेको छ, त्यसैले हामी हाम्रो घटनाको सार्वजनिक पोस्टमार्टम जारी गर्दैछौं।

03.07.2019, 16: 05
आन्तरिक नेटवर्क जडानमा ब्रेकडाउन जस्तै स्रोतहरूसँग समस्याहरू रेकर्ड हुन थाले। सबै कुरा पूर्ण रूपमा जाँच नगरी, तिनीहरूले डाटालाइन तर्फ बाह्य च्यानलको कार्यसम्पादनमा गल्ती गर्न थाले, किनकि यो स्पष्ट भयो कि समस्या इन्टरनेट (NAT) मा आन्तरिक नेटवर्कको पहुँचको साथ थियो, BGP सत्रलाई डाटालाइनमा राख्ने बिन्दुमा।

03.07.2019, 16: 35
यो स्पष्ट भयो कि नेटवर्क ठेगाना अनुवाद र साइटको स्थानीय नेटवर्कबाट इन्टरनेट (NAT) मा पहुँच प्रदान गर्ने उपकरणहरू असफल भएको थियो। उपकरण रिबुट गर्ने प्रयासले केहि पनि नेतृत्व गरेन, प्राविधिक समर्थनबाट प्रतिक्रिया प्राप्त गर्नु अघि जडान व्यवस्थित गर्न वैकल्पिक विकल्पहरूको खोजी सुरु भयो, अनुभवबाट, यो सम्भवतः मद्दत नगर्ने थियो।

समस्या केही हदसम्म बढेको तथ्यले गर्दा यो उपकरणले ग्राहक VPN कर्मचारीहरूको आगमन जडानहरू बन्द गर्यो, र रिमोट रिकभरी कार्यहरू पूरा गर्न अझ गाह्रो भयो।

03.07.2019, 16: 40
हामीले पहिले नै अवस्थित ब्याकअप NAT योजनालाई पुनर्जीवित गर्ने प्रयास गर्यौं जुन पहिले राम्रोसँग काम गरेको थियो। तर यो स्पष्ट भयो कि धेरै नेटवर्क नवीकरणहरूले यस योजनालाई लगभग पूर्ण रूपमा निष्क्रिय बनाएको छ, किनकि यसको पुनर्स्थापनाले, राम्रोमा, काम गर्न सक्दैन, वा, सबैभन्दा खराबमा, पहिले नै काम गरिरहेको कुरालाई तोड्न सक्छ।

हामीले ब्याकबोन सेवा गर्ने नयाँ राउटरहरूको सेटमा ट्राफिक स्थानान्तरण गर्न केही विचारहरूमा काम गर्न थाल्यौं, तर तिनीहरू कोर नेटवर्कमा मार्गहरूको वितरणको विशेषताहरूको कारणले काम गर्न नसकिने देखिन्थ्यो।

03.07.2019, 17: 05
एकै समयमा, नाम सर्भरहरूमा नाम रिजोल्युसन मेकानिजममा समस्या पहिचान गरिएको थियो, जसले अनुप्रयोगहरूमा अन्तिम बिन्दुहरू समाधान गर्न त्रुटिहरू निम्त्यायो, र तिनीहरूले द्रुत रूपमा महत्वपूर्ण सेवाहरूको रेकर्डको साथ होस्ट फाइलहरू भर्न थाले।

03.07.2019, 17: 27
Habr को सीमित कार्यक्षमता पुनर्स्थापित गरिएको छ।

03.07.2019, 17: 43
तर अन्तमा, सीमा राउटरहरू मध्ये एक मार्फत ट्राफिक व्यवस्थित गर्नको लागि एक अपेक्षाकृत सुरक्षित समाधान फेला पर्‍यो, जुन चाँडै स्थापना गरिएको थियो। इन्टरनेट जडान पुनर्स्थापित गरिएको छ।

अर्को केही मिनेटमा, अनुगमन एजेन्टहरूको कार्यक्षमता पुनर्स्थापनाको बारेमा अनुगमन प्रणालीहरूबाट धेरै सूचनाहरू आए, तर नाम सर्भरहरू (dns) मा नाम रिजोल्युसन मेकानिजम बिग्रिएको कारण केही सेवाहरू अपरिवर्तनीय भए।

03.07.2019, 17: 52
NS पुन: सुरु भयो र क्यास खाली गरियो। समाधान पुनर्स्थापित भएको छ।

03.07.2019, 17: 55
MK, Freelansim र Toaster बाहेक सबै सेवाहरू काम गर्न थाले।

03.07.2019, 18: 02
MK र Freelansim काम गर्न थाले।

03.07.2019, 18: 07
डाटालाइनको साथ निर्दोष BGP सत्र फिर्ता गरियो।

03.07.2019, 18: 25
तिनीहरूले स्रोतहरूसँग समस्याहरू रेकर्ड गर्न थाले, जुन NAT पूलको बाह्य ठेगानामा परिवर्तन र धेरै सेवाहरूको acl मा यसको अनुपस्थितिको कारण थियो, जुन तुरुन्तै सच्याइयो। टोस्टरले तुरुन्तै काम गर्न थाल्यो।

03.07.2019, 20: 30
हामीले टेलिग्राम बटहरूसँग सम्बन्धित त्रुटिहरू देख्यौं। यो बाहिरियो कि तिनीहरूले बाह्य ठेगाना acl (प्रोक्सी सर्भर) को एक जोडी मा दर्ता गर्न बिर्सनुभयो, जुन तुरुन्तै सच्याइयो।

निष्कर्ष

• उपकरण, जसले पहिले यसको उपयुक्तताको बारेमा शंकाहरू रोपेको थियो, असफल भयो। त्यहाँ कामबाट हटाउने योजनाहरू थिए, किनकि यसले नेटवर्कको विकासमा हस्तक्षेप गर्यो र अनुकूलता समस्याहरू थियो, तर एकै समयमा यसले महत्त्वपूर्ण कार्य गर्यो, त्यसैले कुनै पनि प्रतिस्थापन सेवाहरू अवरोध नगरी प्राविधिक रूपमा गाह्रो थियो। अब तपाईं अगाडि बढ्न सक्नुहुन्छ।
• DNS मुद्दालाई NAT नेटवर्कको बाहिर नयाँ ब्याकबोन नेटवर्कको नजिक सारेर बेवास्ता गर्न सकिन्छ र अझै पनि अनुवाद बिना ग्रे नेटवर्कमा पूर्ण जडान छ (जुन घटना अघिको योजना थियो)।
• तपाईंले RDBMS क्लस्टरहरू जम्मा गर्दा डोमेन नामहरू प्रयोग गर्नु हुँदैन, किनकि पारदर्शी रूपमा IP ठेगाना परिवर्तन गर्ने सुविधा विशेष आवश्यक छैन, किनकि त्यस्ता हेरफेरहरूलाई अझै पनि क्लस्टरको पुनर्निर्माण आवश्यक छ। यो निर्णय ऐतिहासिक कारणहरूद्वारा र सबैभन्दा पहिले, RDBMS कन्फिगरेसनहरूमा नामद्वारा अन्तिम बिन्दुहरूको स्पष्टताद्वारा निर्देशित गरिएको थियो। सामान्यतया, एक क्लासिक जाल।
• सिद्धान्तमा, "रुनेटको सार्वभौमिकता" सँग तुलनात्मक अभ्यासहरू सञ्चालन गरिएको छ; स्वायत्त अस्तित्वको क्षमताहरूलाई बलियो बनाउने सन्दर्भमा सोच्नको लागि केहि छ।

स्रोत: www.habr.com