डेटा सेंटर से भागना: कैसे हमने तत्काल साइट को दूसरे डेटा सेंटर में स्थानांतरित कर दिया

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

स्रोत डेटा

• प्रोजेक्ट 10 सर्वर का उपयोग करता है जो एक ही डेटा सेंटर में हैं। Nginx, PHP, MySQL के साथ सर्वर। एक पूर्ण मेल सर्वर और उल्लेख के योग्य किसी भी अन्य सेवाओं के बिना;
• साइट पर प्रति दिन 3.5 मिलियन से अधिक पृष्ठ दृश्य हैं;
• छवि अनुरोधों को छोड़कर, प्रति दिन 12 मिलियन से अधिक अनुरोध उनमें से 1/4 PHP में जाते हैं;
• छवियों को छोड़कर, नगनेक्स से प्रति दिन 250 जीबी से अधिक यातायात;
• डेटा सेंटर में सर्वर रिकवरी के लिए प्रारंभिक समय सीमा कुछ दिनों से अधिक है।

विफलता के समय, हमारे पास था:

1. एक बैकअप सर्वर;
2. साइट का अनुकूलित संस्करण। हमने कभी-कभी बैकअप के लिए साइट की जाँच की;
3. MySQL प्रतिकृति का उपयोग कर डेटाबेस की प्रतियां;
4. फाइलों की प्रतियां। निगरानी अंतराल, निगरानी के अनुसार, 20 मिनट से अधिक नहीं था;
5. कॉन्फ़िगर किया गया SOA DNS ज़ोन रिकॉर्ड , जो लगभग सभी उपयोगकर्ताओं को DNS ज़ोन सेटिंग्स को बदलने के लिए लगभग एक घंटे की अनुमति देता है।

समस्याओं और समाधान

विफलता के बाद, हमने दो दिशाओं में जाने का फैसला किया:

• साइट को मौजूदा रीड-ओनली सर्वर पर पुनर्स्थापित करना, सब कुछ और "हमेशा के लिए" कैशिंग;
• साइट को पूर्ण रूप से पुनर्स्थापित करने के लिए किसी अन्य डेटा केंद्र में नए सर्वर का आदेश दें।

इस प्रकार, जब हम सर्वर प्राप्त करते हैं, तो साइट खोज परिणामों में अपना स्थान नहीं खोती है, और आगंतुक टिप्पणियों को छोड़ने, लॉग इन आदि की क्षमता के बिना सामग्री देख सकते हैं।

हमने एक ही बार में मुख्य सर्वर या कई सर्वरों की विफलता मान ली। लेकिन उन्हें लगा कि लंबी अवधि के लिए सभी 10 सर्वरों के बिना रहने की संभावना नहीं है। यहाँ वह है जिसे हमने ध्यान में नहीं रखा:

1. बैकअप सर्वर के कार्य विन्यास को मुख्य सर्वर पर नियमित रूप से अपडेट नहीं किया गया था, हालांकि ये सभी रिपॉजिटरी में संग्रहीत हैं। परिणामस्वरूप, हमें त्रुटियों के साथ URL का हिस्सा मिला, और कुछ पृष्ठ कैश नहीं हुए थे;
2. कैश। आगंतुकों को 10 के बजाय कैश के बिना 1-एन सर्वर पर जाने देना उसके लिए "घातक" है। विशेष रूप से पिछले पैराग्राफ के साथ संयोजन में;
3. स्विच करने की प्रक्रिया में, यह पता चल सकता है कि प्रोजेक्ट स्वयं केवल पढ़ने के लिए तैयार नहीं है। वे पृष्ठ जो पहले से कैश में हैं, उन्हें ठीक करने की आवश्यकता है, और डेवलपर्स ठीक करने के बाद कैश को साफ करने की आवश्यकता है। किसी भी मामले में इस तरह की कठिनाई के साथ बनाए गए पूरे कैश को हटाने के लिए सहमत नहीं हैं। हर मिनट अधिक से अधिक उपयोगकर्ताओं को एक नया आईपी मिलता है, और साइट पर आगंतुकों की संख्या केवल बढ़ रही है। डीएनएस को बदलने के एक घंटे बाद, कैशे को साफ करना;
4. हमें एक डेटा सेंटर नहीं मिला जहां आप प्रति दिन एक से अधिक शक्तिशाली समर्पित सर्वर प्राप्त कर सकें। यहां तक ​​कि अगर आपके पास सभी बैकअप हैं, तो भी आप पहले से साइट को पूरी तरह से बहाल करना शुरू नहीं कर पाएंगे, अगर आप पहले से इस बात का ध्यान नहीं रखते हैं।

यह सब पहले से किया जा सकता था, और हमें इस तथ्य पर कार्रवाई करने के लिए मजबूर किया गया था।

पहले पैराग्राफ में, समाधान के लिए लॉग का विश्लेषण किया गया था और कॉन्फ़िगरेशन फ़ाइलों को केवल-पढ़ने के लिए मोड के लिए संपादित किया गया था। अर्थात्:

• उन्होंने उपयोगकर्ताओं को लॉग इन करने में असमर्थता के बारे में एक सांस्कृतिक संदेश दिया;
• नगीनक्स स्तर पर रिकॉर्ड पर टिप्पणी और अन्य कार्रवाइयाँ, उपयोगकर्ताओं को PHP में न आने देना;
• आवश्यक स्थानों में 503 का इस्तेमाल किया, साथ ही error_page 503 = /trouble.html ;
• अन्य सभी पृष्ठों को कैश करने के लिए बग भी तय किए गए।

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

हमारे मामले में, यह इस तरह दिखता था:

fastcgi_pass unix:/var/run/php-fpm/fpm-all.sock; if ( $remote_addr = 8.8.8.8 ) { #if ( $remote_addr ~ (8.8.8.8|127.0.0.1) ) { #       fastcgi_pass unix:/var/run/php-fpm/fpm-private.sock; #   #set $nocache 1; #fastcgi_cache_bypass $nocache; } 

8.8.8.8 के बजाय हम अपने आईपी को प्रतिस्थापित करते हैं।

इसके अलावा, हमारे पास दो PHP-FPM पूल थे : fpm-private - हमारे लिए, fpm-all - बाकी के लिए। कैश को अपडेट करने के लिए, fastcgi_cache_bypass निर्देश का उपयोग किया गया था।
कैश बनाने के लिए, हमने wr -r -l0 -np - example.com चलाया । कैश को अपडेट करने के लिए, हमने $ nocache के साथ लाइनों को अनइंस्टॉल किया। इस प्रकार, हमें अपने आईपी से आवश्यक होने पर कैश उत्पन्न करने और इसे अपडेट करने की क्षमता के साथ खुद के लिए एक कार्य स्थल मिला। कई घंटों के ऑपरेशन के बाद, पहले से ही कई टन गीगाबाइट कैश थे।

हम सर्वर सेटिंग्स के अनुकूलन के मुद्दे पर लगभग नहीं छूते हैं, ऐसे विषयों को अलग-अलग लेखों में अच्छी तरह से वर्णित किया गया है। इस मामले में, डेटाबेस क्वेरीज़ केवल-पढ़ने के लिए थीं, इसलिए MySQL अनुकूलन सरल था - डेटाबेस एक अड़चन नहीं था। सभी कनेक्शनों को संभालने के लिए टाइमआउट और बफ़र्स को समायोजित करने के लिए निगनेक्स को कॉन्फ़िगर करना कम हुआ। नेटवर्क पर एक अच्छा लोड था, क्योंकि अब छवियों को अपलोड करने के लिए एक अतिरिक्त सर्वर नहीं था। कमजोर बिंदु PHP था। बड़ी कैश उत्पन्न करने के बाद भी, कुछ पेज 20 सेकंड के लिए उत्पन्न हुए थे, क्योंकि PHP-FPM में एक कतार थी।

अंतिम बिंदु के बारे में - नए सर्वर की खोज। हम जल्दी से इस मुद्दे को हल करने में सक्षम नहीं थे। डेटा केंद्र केवल अधिकतम कोर i3-i7 विशेषताओं के साथ सर्वर प्रदान कर सकते हैं, और 1-2 दिनों के लिए 8GB रैम, और अधिक शक्तिशाली सर्वरों को भी लंबे समय तक इंतजार करना पड़ता है, साथ ही अनुबंधों को समाप्त करने और सर्वरों के लिए भुगतान करने का समय। हमें एक डेटा सेंटर मिला जिसके साथ हम 3 दिनों में हॉट रिज़र्व के लिए 4 शक्तिशाली सर्वर प्राप्त करने पर सहमत हुए। अब ये सर्वर साइट के लिए काम करने के लिए पर्याप्त हैं, बिना कुछ भारी मॉड्यूल के जो हमारे लिए महत्वपूर्ण नहीं हैं। यदि आवश्यक हो तो अब हम दूसरे डेटा सेंटर में काम कर सकते हैं।

बैकअप सर्वर की समस्या का समाधान प्राथमिक के साथ समस्याओं के मामले में अतिरिक्त सर्वर के संभावित प्रावधान पर बैकअप डेटा केंद्र के साथ एक प्रारंभिक समझौता हो सकता है। आप समझदार भी कर सकते हैं और साइट को एक से अधिक डेटा सेंटर में स्केल कर सकते हैं, जो अब हम करते हैं।

परिणाम

1. आप बैकअप के बिना नहीं रह सकते हैं, आपको उन्हें नियमित रूप से निगरानी, ​​हाथों और कुछ भी के साथ जांचना चाहिए। कोई अतिरिक्त सावधानी नहीं है;
2. बैकअप सर्वर का सत्यापन पूर्ण रूप से होना चाहिए। हमारे मामले में, पर्याप्त लोड परीक्षण नहीं था, फिर से क्योंकि हमने एक समान स्थिति की उम्मीद नहीं की थी;
3. यदि आपके पास केवल एक बैकअप सर्वर है, तो इसे तुरंत कॉन्फ़िगर करें ताकि यह वास्तविक लोड के तहत सीमित मोड में भी काम करे;
4. प्रोजेक्ट टीम या आर्किटेक्ट और एडमिनिस्ट्रेटर के साथ सबसे अधिक संभावना वाली स्थिति को मॉडल करने के लिए समय लें - डेटा सेंटर में एक विस्फोट, आग, अन्य परिस्थितियां, जब आप अचानक सर्वर तक पहुंच खो देते हैं। विश्लेषण और, परिणामस्वरूप, ऐसे मामले का दस्तावेज़ीकरण, साथ ही उनके संचालन के परीक्षण के साथ कॉन्फ़िगरेशन फ़ाइलों की तैयारी, अधिकांश संभावित विफलताओं को ठीक कर देगा। फिर अगर कोई यूएफओ आपके सर्वर पर आता है, तो आप यह नहीं कहेंगे कि आपने इसकी उम्मीद नहीं की थी, और आप इस परियोजना को बहाल कर सकते हैं :);
5. हमारे मामले में, साइट एक घंटे से अधिक समय तक पूरी तरह से अनुपलब्ध थी। कुछ और घंटे काम में रुकावट थे। ऐसी स्थिति के लिए तैयार करना आपको पहले आगंतुकों से मिलने के लिए कैश उत्पन्न करने के लिए डीएनएस रिकॉर्ड को अपडेट करते समय एक घंटा बिताने की अनुमति देगा, और भविष्य में, लोड के तहत कसकर नीचे न जाएं।

हमारे मामले में, डेटा सेंटर ने एक दिन बाद काम थोड़ा अधिक बहाल किया। यह देखते हुए कि हम रीड-ओनली मोड में काम कर रहे थे, कोई डेटा वापस ट्रांसफर नहीं करना था। सर्वरों की जांच करने के बाद, हमने डोमेन को वापस स्थानांतरित कर दिया।

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