वेब क्लस्टर - वास्तविक दुनिया का अनुभव

प्रणाम, प्यारे साथियों!

यह आलेख इस बात के बारे में है कि हमने समाचार पोर्टल के लिए एक वेब क्लस्टर कैसे लागू किया (प्रति दिन 130 हजार अद्वितीय आगंतुकों की यात्राओं की चोटी के साथ - यह 3 दिनों में 7 टीबी ट्रैफ़िक है - चुनाव और 2 बाद वाले। अब औसत क्लस्टर 35-40 टीबी ट्रैफ़िक को बाहर कर देता है। महीने), कैसे प्रोग्रामर और पत्रकार एक ही कार्य को अलग-अलग तरीकों से समझते हैं, इस बारे में कि आप अलग-अलग तरीकों से एक ही लक्ष्य को कैसे प्राप्त कर सकते हैं।

यह उन लोगों के लिए दिलचस्प होगा जो उपकरण में खगोलीय मात्रा (और टेलीविजन के मानकों द्वारा, आम तौर पर हास्यास्पद मात्रा में निवेश किए बिना) आसानी से स्केलेबल भौगोलिक रूप से वितरित वेब क्लस्टर बनाना चाहते हैं।

मुझे यकीन है कि बाज़ारियों ने उनके नाम से "स्केलेबल वेब क्लस्टर" या "क्षैतिज अनंत स्केलेबल वेब क्लस्टर" शब्दों के साथ ताज़े रिलीज़ किए गए उत्पादों के uber समाधानों को आगे बढ़ाया है, मुझे इससे नफरत होगी।

मुझे यकीन है कि हमारे ग्राहकों के प्रतिद्वंद्वियों ने हमारे द्वारा उपयोग किए गए समाधान की सादगी से आश्चर्यचकित होंगे।



मैं किसी भी PHP, Nginx और Firebird सेटअप ट्यूटोरियल (उत्तरार्द्ध, कड़ाई से बोल रहा हूं, में कॉन्फ़िगर करने के लिए कुछ भी नहीं मिल सकता है) को सामान्य रूप से कॉन्फ़िगर करने के लिए कुछ भी नहीं देता - सब कुछ "बॉक्स से बाहर" के साथ काम करता है) और सामान्य तौर पर मैं सार के बारे में बात करूंगा निर्णय, पीएचपी के किस संस्करण के बारे में बेहतर है।

अनुभवी डिजाइनरों को रुचि होने की संभावना नहीं है - वे पहले से ही सब कुछ जानते हैं, लेकिन जो लोग सिस्टम डिज़ाइन के कठिन क्षेत्र में अपनी यात्रा शुरू कर रहे हैं, उनके लिए "हैलो, वर्ल्ड!" से अधिक कठिन होगा, रचना करने के लिए शायद कुछ होगा - समाधान 2 साल पहले ही मुकाबला मोड में होगा! कोई वास्तु समस्याएं नहीं थीं (हालांकि एक साथ दो तीन नोड्स पर दो हार्ड ड्राइव विफल हो रहे थे, लेकिन किसी ने कुछ भी नहीं देखा - साइटों ने सामान्य से थोड़ा धीमा खोल दिया)।

तो, कुछ शब्द, यह सब कैसे शुरू हुआ। एक बार एक स्वतंत्र पत्रकारों के एक समूह की एक वेबसाइट थी, जो बहुत हद तक एक असली टेलीविजन बनने का सपना देख रहा था (आगे देख रहा हूँ, मैं कहता हूँ कि वे सफल हुए - उन्होंने "लाठी और चुदाई ..." यहाँ - उसके बाद अपना सफल टेलीविजन बनाया। हमारा देश छोटा है, कुछ भी बुरा नहीं होता (और हम इस बारे में खुश हैं), लेकिन हर 4 साल में हम पारंपरिक रूप से संसदीय चुनाव करते हैं। जो पहले से ही पारंपरिक रूप से राष्ट्रपति का चुनाव किसी भी तरह से नहीं करता है। (डरो मत, यहां कोई राजनीति नहीं होगी, यह सिर्फ एक सामान्य समझ के लिए है)।

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

कार्य हमारे लिए निर्धारित किया गया था - समाचार साइटों के लिए एक समाधान का प्रस्ताव करने के लिए जो न केवल 50-100 हजार आगंतुकों को जीवित रखेगा, बल्कि भौगोलिक रूप से दुनिया भर में बिखरेगा और ब्रह्मांड में कहीं भी मोबाइल बंकर से नियंत्रित किया जाएगा। बेशक, क्लस्टर नोड्स का भौगोलिक प्रसार हमारे साथ रहा। परिणामस्वरूप, हमने निम्नलिखित योजना का प्रस्ताव रखा (मेरे पास कोई कलाकार नहीं है, आप मुझे माफ करें):



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

यहां हमें आगंतुकों के साथ मिला (परिणामस्वरूप पोर्टल के प्रत्येक भाग का अपना काउंटर है):



यह योजना आपको किसी भी समय प्रबंधन सर्वर को बदलने की अनुमति देती है, यह क्लस्टर नोड्स की उपलब्धता की आसानी से जांच करती है - अमेज़ॅन ईसी को बैकअप के रूप में भी माना जाता था - इसके अलावा, अमेज़ॅन ईसी का उपयोग कुछ समय के लिए वीडियो स्ट्रीमिंग (लगभग 4 महीने) के लिए भी किया गया था, लेकिन क्योंकि यातायात की उच्च लागत, फिर भी जर्मन हेट्जनर को स्ट्रीमिंग नोड्स को स्थानांतरित करने का निर्णय लिया गया।
घंटे "एक्स" से तुरंत 2 सप्ताह पहले, हमने बैकअप सर्वर लिया और उन्हें तैयार रखा (लेकिन उपयोगकर्ताओं ने उन्हें नहीं देखा, क्योंकि सर्वर को सक्रिय रखने का मुकाबला मोड में उपयोग करने की तुलना में थोड़ा सस्ता है - केवल यातायात के कारण)।

यह सब कैसे काम करता है? बहुत सरल - चुपचाप और घड़ी के आसपास;)।

प्रबंधन सर्वर पर (जैसा कि मैंने पहले ही उल्लेख किया है, पोर्टल में 2 बड़े "अनुभाग" हैं: चित्रों के साथ पाठ के रूप में समाचार और पाठ के रूप में समाचार और वीडियो के रूप में पाचन और वीडियो - 2 सर्वर का उपयोग वास्तविक रूप से किया जाता है, लेकिन सादगी के लिए मैंने एक को चित्रित किया है) सामान्यतः सामग्री प्रबंधन प्रणाली के रूप में जाना जाता है।

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

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

इस प्रकार, हम पोर्टल की एक मास्टर प्रति (अच्छी तरह से, या दो पोर्टल, यदि आपको पसंद है - पाठ और वीडियो) बनाते हैं। स्क्रिप्ट (और साथ ही व्यवस्थापक पैनल) PHP में लिखा गया है और फायरबर्ड के साथ काम करने के लिए ADODB का उपयोग करता है - इसलिए यह ग्राहक के अनुरोध के अनुसार काफी सरलता से पुनर्निर्माण किया जा सकता है *।

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

फायरबर्ड सेटिंग्स में केवल एक चीज जिसे बदलना पड़ा, वह डेटाबेस पेज कैश का आकार था - चूंकि डेटाबेस से कनेक्शन की संख्या बहुत कम है (शायद ही कभी 50-60 एक साथ कनेक्शन), पृष्ठों की संख्या प्रयोगात्मक रूप से 2048 तक बढ़ गई थी (हम क्लासिक विकल्प का उपयोग करते हैं। सुपर आर्किटेक्चर के लिए, इस मूल्य को आसानी से 10 गुना बढ़ाया जा सकता है, क्योंकि एक सामान्य पेज कैश है। फायरबर्ड 3.0 के आगामी संस्करण में, डेवलपर्स एक सामान्य कैश के साथ एक एसएमपी-अनुकूल वास्तुकला का वादा करते हैं, इसलिए इसके लिए बड़े मूल्यों का उपयोग करना संभव होगा। astroek पेज कैश)।

फिर, नियमित रूप से rsync का उपयोग करते हुए, परिवर्तनों में अंतर दर्पणों में बिखरा हुआ है, जो कि नगीनक्स पर आधारित स्टैटिक्स वितरित करने के लिए सामान्य नोड हैं। मुझे लगता है कि यह बताने की आवश्यकता नहीं है कि 12 गीगाबाइट रैम वाला 4-कोर सर्वर अकेले स्टैटिस्टिक वितरित करते समय क्या सक्षम है? ;-)

उसी समय, प्रत्येक नोड के चैनल का 10% (यह सिर्फ 10 या 100 मेगाबिट्स है, विशेष कनेक्शन के आधार पर) सिंक्रनाइज़ेशन के लिए आरक्षित है। तुल्यकालन 2 चरणों में होता है - पहला, "भारी" सामग्री सिंक्रनाइज़ होती है - चित्र और वीडियो, फिर - पाठ (html / xml / js)।

कभी-कभी (जब नियंत्रण सर्वर से दर्पण तक के चैनल लोड किए जाते हैं), आगंतुक को अनलोड किए गए चित्रों और / या वीडियो के रूप में छोटी विसंगतियां दिखाई दे सकती हैं - चूंकि राउंड-रॉबिन डीएनएस का उपयोग किया जाता है, उपयोगकर्ता एक दर्पण से पृष्ठ का पाठ और दूसरे से वीडियो का लिंक प्राप्त कर सकता है। । यह पोर्टल को काम करने से रोकता नहीं है - हमेशा पाठ होता है, और एक तस्वीर या वीडियो को जल्द या बाद में घोषित किया जाएगा।

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

एक नया नोड जोड़ना सरल है - पहले एक नया दर्पण मुख्य प्रतिलिपि के साथ सिंक्रनाइज़ किया जाता है (यह सिंक्रोनाइज़र के संचालन के सामान्य मोड के साथ समानांतर में होता है), फिर रिकॉर्ड को डीएनएस में जोड़ा जाता है और ... कोई भी कुछ भी नोटिस नहीं करता है।

एक नोड को हटाना सरल है - बस DNS से ​​रिकॉर्ड को हटाना। जोड़ने और हटाने स्वचालन के लिए काफी अनुकूल है (यह ठीक है कि हमने उस हिस्से के साथ किया था जो वेब स्ट्रीमिंग के लिए ज़िम्मेदार था Amazom EC पर 1000 मेगाबिट स्ट्रीम के लिए), लेकिन अगर आप अचानक इसे दोहराने का फैसला करते हैं, तो मैं आपको पहले से गणना करने की सलाह देता हूं कि प्राथमिक डेटा सिंक्रोनाइज़ेशन में कितना समय लगता है (हमारे पास यह है) "पोर्टल के हल्के संस्करण" के लिए 2 गीगाबाइट और वीडियो के लिए लगभग 1 टेराबाइट, केवल पिछले कुछ महीनों में संग्रहीत)।

यही कारण है कि हमने कुछ समय बाद अतिरिक्त पूल से नोड्स के गतिशील जोड़ / हटाने को हटा दिया, परियोजना बहुत अधिक सामग्री लेती है और स्क्रिप्ट बहुत अधिक पागल है - उनके साथ हर संचार समस्या के लिए नोड्स हटा दिया।

अलग-अलग, यह समाचार के प्रदर्शन की गणना के बारे में ध्यान देने योग्य है। मुझे यह धारणा मिली कि पत्रकारों के लिए पसंदीदा शगल (रिपोर्ट लिखने / फिल्मांकन के अलावा) किसी विशेष समाचार आइटम के लिए आगंतुकों की संख्या का एक माप है। हमें पत्रकारिता बिरादरी को समझाने के लिए लगभग एक लीटर रक्त और एक किलोमीटर की नसों में खर्च करना पड़ा कि वास्तविक समय में काउंटरों में परिवर्तन प्रदर्शित करना आवश्यक नहीं था।

प्रोग्रामर अच्छी तरह से जानते हैं कि यह पता लगाना असंभव है कि वर्तमान में कितने लोग एक लेख पढ़ रहे हैं, आप केवल सर्वर से लेख अनुरोधों की संख्या की गणना कर सकते हैं, पत्रकारों के लिए ये समान अवधारणाएं हैं। :)

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

यहाँ हम उपयोग किए गए समाधान के लाभ हैं:

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

ठीक है, एक दो मिनट, ताकि सब कुछ इतना बादल रहित न हो:

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

और सचमुच एक छोटा चुटकी अनुभव, जो रोजमर्रा की जिंदगी के ताजा दलिया में विविधता लाएगा।

साइट की एक ऑफ़लाइन प्रतिलिपि संग्रहीत करने के लिए, हम JFS फ़ाइल सिस्टम का उपयोग करते हैं। कई छोटी फ़ाइलों के साथ काम करते समय और बड़ी फ़ाइलों के साथ काम करते समय उसने खुद को बहुत अच्छी तरह से साबित कर दिया (मेरे अनुभव में, केवल XFS लगभग 200-300 जीबी आकार की फ़ाइल को हटा सकता है)।

इसलिए - डिफ़ॉल्ट रूप से, फ़ाइल सिस्टम को डिफ़ॉल्ट सेटिंग्स के साथ माउंट किया गया था। लेकिन समय के साथ हमारे पास बहुत सारी फाइलें थीं, डिस्क संचालन थोड़ा धीमा होने लगा। चूँकि हमें फ़ाइल की अंतिम पहुँच के समय की आवश्यकता नहीं है, इसलिए मैंने FS माउंट विकल्पों में "noatime" विकल्प जोड़ा। यहाँ क्या हुआ - जोड़ने का क्षण, मुझे लगता है कि आप अपने लिए निर्धारित करेंगे:



संक्षेप में दोहराएं - सामान्य मोड में स्थिर संचालन के लिए इसका उपयोग किया जाता है:

• सामग्री वितरण के लिए 3 सर्वर
• "व्यवस्थापक पैनल" के लिए 2 सर्वर
• DNS के लिए 2 सर्वर और अन्य सर्वर के लिए ट्रैकिंग सिस्टम।

क्लस्टर नोड्स भौगोलिक रूप से बिखरे हुए हैं और विभिन्न प्रदाताओं में स्थित हैं।
बड़ी संख्या में आगंतुकों को आकर्षित करने वाली अपेक्षित घटनाओं के मामले में, सामग्री वितरित करने के लिए अतिरिक्त सर्वर जुड़े हुए हैं।

प्रति माह लगभग 40TB ट्रैफ़िक की खपत होती है, सामग्री की कुल मात्रा सिर्फ 1 टेराबाइट से अधिक होती है, वीडियो सामग्री 3 महीने तक संग्रहीत की जाती है।

मुझे खुशी के सवालों के जवाब देने में खुशी होगी।