वेब प्रोजेक्ट फ़ाइलों की टेराबाइट्स - स्टोर और शेयर

सभी को नमस्कार!

हाल ही में, एक दिलचस्प प्रवृत्ति को रेखांकित किया गया है - अनंत के लिए वेब परियोजनाओं का तेजी से "सूजन"। कई लोकप्रिय साइटों के डेटा की मात्रा तेजी से और तेजी से बढ़ रही है, उन्हें कहीं न कहीं डालने की आवश्यकता है, यह बैकअप के लिए प्रभावी है (यह मजेदार होगा यदि 500T पर फाइलें खो जाती हैं :-)), और निश्चित रूप से यह ग्राहकों को वितरित करने के लिए अति-त्वरित है ताकि हर कोई डाउनलोड, डाउनलोड कर सके। डाउनलोड ... उच्च गति पर।

सिस्टम एडमिनिस्ट्रेटर के लिए, फाइलों के ऐसे वॉल्यूम का एक दुर्लभ, दैनिक बैकअप का काम भी आत्महत्या के विचारों को उद्घाटित करता है, और वेब प्रोजेक्ट मैनेजर 6 घंटे के लिए डेटा सेंटर की आगामी रोकथाम के बारे में सोचकर ठंडे पसीना में उठता है (फ़ाइलों को एक डेटा सेंटर से दूसरे में स्थानांतरित करने के लिए, आपको ट्रंक लोड करने की आवश्यकता है कार Winchesters :-))।

स्मार्ट सहकर्मी आपको NetApp से किसी एक समाधान को खरीदने की सलाह देते हैं, लेकिन यह अफ़सोस की बात है कि परियोजना का बजट 1000 गुना कम है, यह एक स्टार्टअप है ... हम क्या करेंगे?

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

हाईलाड अलमारी एक्सेस

यदि आप कभी भी हाईलाड सम्मेलन में भाग लेते हैं, तो आप शायद जानते हैं कि प्रवेश द्वार पर आपको इस सवाल का जवाब देना चाहिए - वे अपाचे के सामने निगनेक्स क्यों डालते हैं? अन्यथा, अलमारी से आगे जाने का कोई रास्ता नहीं है ;-)

यह सही है, nginx या एक समान रिवर्स प्रॉक्सी आपको फ़ाइलों को कुशलतापूर्वक वितरित करने की अनुमति देता है, विशेष रूप से धीमी गति से चैनलों पर, सर्वर पर लोड को कम करने और समग्र वेब अनुप्रयोग प्रदर्शन को बढ़ाने के लिए: nginx फ़ाइलों का एक गुच्छा वितरित करता है, एपाचे या php-fpm प्रक्रिया अनुरोधों को अनुप्रयोग सर्वर पर वितरित करता है।

ऐसे वेब एप्लिकेशन तब तक अच्छी तरह से रहते हैं, जब तक कि फ़ाइल का आकार बढ़ न जाए, दसियों गीगाबाइट का हो जाता है - जब कई सौ क्लाइंट एक ही समय में सर्वर से फाइल डाउनलोड करना शुरू करते हैं, और रैम - डिस्क, और फिर RAID में फ़ाइलों को कैश करने के लिए पर्याप्त मेमोरी नहीं है, बस मर जाएगा।

स्थैतिक सर्वर

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

वे कुछ इस तरह करते हैं:

• www.mysite.ru
• img.mysite.ru
• js.mysite.ru
• css.mysite.ru
• download.mysite.ru
• आदि

अलग-अलग डोमेन से स्टेटिक्स को अधिक प्रभावी ढंग से वितरित करने के लिए, उन्हें एक अलग सर्वर (एस) स्टैटिक्स में जमा किया जाता है:

इस सर्वर पर nginx कैशिंग मोड और "फास्ट" RAID का उपयोग करना उपयोगी है (ताकि डिस्क को इसके "घुटनों" पर सेट करने के लिए अधिक क्लाइंट की आवश्यकता हो)।

सीडीएन - वितरण

इस स्तर पर, वेब प्रोजेक्ट के आयोजकों को यह समझ में आने लगता है कि बहुत तेजी से डिस्क या यहां तक ​​कि सैन से उनके डेटा सेंटर से वितरण हमेशा प्रभावी नहीं होता है:

• एक मूल्यवान ग्राहक ने व्लादिवोस्तोक से मॉस्को सर्वर से फ़ाइल डाउनलोड करना शुरू किया, और शहर से नहीं, बल्कि उसकी नौका की तरफ से। बेशक चैनल संकीर्ण हो गया।
• एक आपदा थी और क्लीनर ने गलती से स्थैतिक वितरण सर्वर से पावर कॉर्ड खींच लिया, जिससे नए वितरण को डाउनलोड करने वाले 10,000 क्लाइंट टूट गए। खैर, या डेटा सेंटर में, और यह "अज्ञात" है जब रोकथाम समाप्त हो जाएगी - या बल्कि, दो डीजल जनरेटर में से तीन की एक साथ विफलता का कारण खोजने के लिए काम करते हैं।
• इसके विपरीत, ग्राहकों की ऐसी आमद हो सकती है कि सर्वर क्षमता एक ही समय में इतना स्थिर वितरित करने के लिए पर्याप्त नहीं थी, या चैनल पहले से ही सीमा पर लोड थे।

सामान्य तौर पर, हर कोई समझता है कि आपको क्लाइंट के जितना संभव हो उतना करीब होना चाहिए और क्लाइंट को उतना ही स्थिर देना चाहिए जितना वह उच्चतम संभव गति से चाहता है, और न कि हम अपने सर्वर (एस) से कितना दे सकते हैं।
हाल ही में, CDN तकनीक ने इन समस्याओं को प्रभावी ढंग से हल करना शुरू कर दिया है।

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

स्टैटिक्स के वितरण का "वर्टिकल" स्केलिंग

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

क्या आप निम्नलिखित के बारे में सोचने से डरते हैं:

• फ़ाइल स्टोरेज पर डिस्क उखड़ जाएगी (raid10 एक बार में इसके साथ मिरर किए गए डिस्क के एक जोड़े को ले जाकर मर सकती है और ऐसा बहुत कम होता है) और आपको दो से तीन सप्ताह के भीतर बैकअप से फाइलें प्राप्त करनी होंगी।
• डेटा सेंटर ने अंततः डीजल जनरेटर की संख्या की गणना करने का तरीका सीखा, लेकिन सुबह आप इस संदेश से प्रसन्न थे कि डिस्क बिखरी हुई थी, और सॉफ़्टवेयर त्रुटि के परिणामस्वरूप आपके बैकअप को अपूरणीय रूप से नुकसान हुआ था (यह अमेज़ॅन में एक बार हमारे साथ हुआ था)।
• एक विज्ञापन अभियान चलेगा और सुदूर पूर्व या यूरोप से ग्राहकों की आमद शुरू हो जाएगी - और आप इतने सारे स्टैटिक्स के प्रभावी वितरण का सामना नहीं कर पाएंगे।

वैसे भी, आप पहले से ही बुनियादी ढांचे में बहुत पैसा लगा चुके हैं, लेकिन जोखिम, और काफी वाले, बने हुए हैं। किसी तरह बेईमानी से हासिल किया।

सर्किल और पहिए - वितरित फ़ाइल सिस्टम

इस समय, बाएं गोलार्ध, जो तर्क के लिए जिम्मेदार है, कई के लिए बंद हो जाता है और रहस्यमय राक्षसी समाधानों के लिए तैयार होता है - कई डेटा केंद्रों में उनकी वितरित फ़ाइल प्रणाली को तैनात करने के लिए। शायद एक बड़े बजट वाली परियोजना के लिए, यह रास्ता होगा ...

फिर आपको अपने दम पर इस सभी अर्थव्यवस्था का प्रबंधन करना होगा, जिसे स्पष्ट रूप से पूरे ऑपरेशन विभाग की उपस्थिति की आवश्यकता होगी :-)

वर्चुअल फाइल सिस्टम

सबसे प्रभावी और सबसे महत्वपूर्ण बात, सस्ते समाधानों में से एक है, जाने-माने क्लाउड प्रदाताओं की क्षमताओं का उपयोग करना, जो बहुत स्वादिष्ट, विशेष रूप से बड़ी मात्रा में डेटा, कीमतों के साथ क्लाउड में आपकी फ़ाइलों की असीमित मात्रा को बहुत अधिक विश्वसनीयता (विशाल ड्रॉपबॉक्स) के साथ संग्रहीत करने का एक तरीका है। । भौगोलिक रूप से विभाजित कई डेटा केंद्रों में ऊपर बताए गए वितरित फ़ाइल सिस्टम, अत्यधिक विश्वसनीय और स्थित उनकी सुविधाओं पर आयोजित प्रदाता, भौगोलिक रूप से विभाजित हैं। इसके अलावा, इन सेवाओं को आमतौर पर इस प्रदाता के सीडीएन नेटवर्क में कसकर एकीकृत किया जाता है। यानी आप न केवल सुविधाजनक रूप से और सस्ते में अपनी फ़ाइलों को संग्रहीत करेंगे, बल्कि क्लाइंट के लिए उन्हें यथासंभव सुविधाजनक रूप से वितरित कर सकते हैं।

बात छोटी है - आपको अपने वेब प्रोजेक्ट पर एक लेयर या वर्चुअल फाइल सिस्टम (या क्लाउड डिस्क का एनालॉग) को कॉन्फ़िगर करने की आवश्यकता है। नि: शुल्क समाधान के बीच, FUSE- उपकरण (लिनक्स के लिए) जैसे कि s3fs को प्रतिष्ठित किया जा सकता है।

हालाँकि, वर्तमान वेब एप्लिकेशन को व्यावसायिक दृष्टिकोण से इस सस्ती और बहुत प्रभावी तकनीक में स्थानांतरित करने के लिए, आपको मौजूदा कोड और एप्लिकेशन लॉजिक में कई बदलाव करने की आवश्यकता है।

मॉड्यूल "क्लाउड स्टोरेज" प्लेटफॉर्म "1C-बिट्रिक्स"

हमारे उत्पाद में, हमने वेब परियोजनाओं के उपरोक्त मामलों का सावधानीपूर्वक विश्लेषण किया है, जो ग्राहकों को फ़ाइलों को जल्दी से वितरित करने की आवश्यकता है, और कभी-कभी फ़ाइलें - टेराबाइट्स या अधिक, और क्लाउड स्टोरेज मॉड्यूल में इन सुविधाओं को बॉक्स से बाहर लागू किया।

मुझे ईमानदारी से पसंद है कि आप सिस्टम के अलग-अलग मॉड्यूल के डेटा को स्टोर कर सकते हैं ... विभिन्न क्लाउड स्टोरेज में :-)। यह वास्तव में आपकी फ़ाइल भंडारण में विविधता लाता है। आप ग्राहक के पते या प्रकार के आधार पर उन्हें बिखेर सकते हैं। या सूचना के प्रकार से - कोई व्यक्ति प्रभावी रूप से प्रकाश स्टेटिक्स देता है, कोई भारी सामग्री।

परिणाम

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

लेख में, हमने किसी भी आकार के वेब समाधानों पर फ़ाइल वितरण के आयोजन के मुख्य चरणों और सिद्धांतों की जांच की, पेशेवरों और विपक्षों का वजन किया, और यह देखा कि यह 1C-Bitrix मंच में कैसे लागू किया गया है। इस तथ्य को देखते हुए कि वेब परियोजनाओं द्वारा वितरित जानकारी की मात्रा तेजी से बढ़ रही है, यह ज्ञान प्रासंगिक है और निश्चित रूप से वेब एप्लिकेशन आर्किटेक्ट और प्रोजेक्ट मैनेजर दोनों के लिए उपयोगी होगा।

और निश्चित रूप से मैं सभी को हमारी बिट्रिक्स 24 क्लाउड सेवा में आमंत्रित करता हूं, जिसमें हम ऊपर वर्णित तकनीकों का सक्रिय रूप से उपयोग करते हैं। सभी को शुभकामनाएँ!