साझा करें

Roblox क्लाउड पर नेटवर्क पैकेट हानि और विलंबता निगरानी

द्वारा प्रवीण पोनाकान्ति

प्रकाशित 8 अप्रैल 2021

Roblox नेटवर्क इंजीनियरिंग टीम दुनिया भर में फैले डेटा सेंटर और पॉइंट ऑफ प्रेजेंस (POP) साइटों के साथ एक बड़े, तेजी से बढ़ते नेटवर्क का रखरखाव करती है। Roblox प्लेटफ़ॉर्म पर एक बेहतरीन उपयोगकर्ता अनुभव प्रदान करना इस नेटवर्क के प्रदर्शन और विश्वसनीयता पर निर्भर करता है। नेटवर्क ऑपरेटरों के लिए नेटवर्क में समस्याओं का निवारण और पता लगाना, और नेटवर्क प्रदर्शन में दृश्यता रखना महत्वपूर्ण है। नेटवर्क निगरानी आम तौर पर डिवाइस के आँकड़े, त्रुटि मीट्रिक, और syslogs को समय-समय पर एकत्र करके और उन्हें एक टाइम सीरीज़ या लॉग डेटाबेस में संग्रहीत करके प्राप्त की जाती है। डेटा को SNMP, Netconf, Rest APIs, या स्ट्रीमिंग टेलीमेट्री जैसे मानक प्रोटोकॉल का उपयोग करके पुश या पुल मॉडल के साथ एकत्र किया जाता है।

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

किसी नेटवर्क की सक्रिय रूप से निगरानी करने का एक शानदार तरीका, नीचे दिए गए आंकड़ों में दर्शाए अनुसार, एक मेष के पार नियमित रूप से संश्लेषित प्रोब प्रसारित करना है।

उत्पादन रुकावटों का निवारण करते समय, नेटवर्क ऑपरेटरों से अक्सर ऐसे प्रश्न पूछे जाते हैं, जैसे, "क्या नेटवर्क पैकेट ड्रॉप कर रहा है?" या "क्या कोई चल रही नेटवर्क खराबी सेवा कनेक्टिविटी को प्रभावित कर रही है?" ऐतिहासिक पैकेट लॉस और लेटेंसी डेटा तक पहुंच के बिना इस प्रकार के प्रश्न का उत्तर देने के लिए, उन्हें नेटवर्क के भीतर लिंक और नोड्स के एक बड़े सेट की जांच करनी होगी।

एक विश्वसनीय और स्केलेबल नेटवर्क मेष मॉनिटरिंग सिस्टम का डिज़ाइन

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

हम नेटवर्क का परीक्षण किससे करते हैं?

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

हम कहाँ से प्रोब करते हैं?

एक बड़ी समग्र प्रोब दर प्राप्त करने और बड़ी संख्या में नेटवर्क पथों को कवर करने का एक तरीका यह है कि प्रोब प्रसारित करने के लिए यथासंभव अधिक से अधिक कंप्यूट नोड्स का उपयोग किया जाए। इसके दो फायदे हैं: यह उन सिस्टमों पर लोड वितरित करने में मदद करता है जो प्रोब उत्पन्न कर रहे हैं, और यह उन्हें ले जाने वाले नेटवर्क पोर्ट की संख्या बढ़ाता है। हालाँकि, इसके लिए एक ऐसे एजेंट की आवश्यकता होती है जो बहुत स्थिर हो और होस्ट सिस्टम के संसाधनों पर यथासंभव पतला हो। साथ ही, एजेंट को होस्ट सिस्टम पर सीपीयू, मेमोरी, या I/O उपयोग में उतार-चढ़ाव से प्रभावित हुए बिना, कई पथों पर पैकेट हानि और विलंबता को सटीक रूप से मापने में सक्षम होना चाहिए। एजेंट को हल्के और उच्च-प्रदर्शन वाले होने के बीच इस नाजुक संतुलन को लगातार बनाए रखना होता है।

हम नेटवर्क हानि और विलंबता को कैसे मापते हैं?

यह एकल प्रोब स्ट्रीम पर एक तुच्छ गणना लग सकती है, हालांकि, बड़े पैमाने पर कुछ चुनौतियाँ उत्पन्न होती हैं जो तुरंत स्पष्ट नहीं होती हैं। इतने बड़े मेष को स्केल करने के लिए, एजेंट को एक साथ कई स्ट्रीम पर टाइमस्टैम्प के साथ तेज़ और सटीक ट्रांसमिट (Tx) और रिसीव (Rx) पैकेट काउंट की गणना करने की आवश्यकता होती है। यह महत्वपूर्ण है कि नेटवर्क लॉस मेट्रिक्स में वे पैकेट शामिल न हों जो एजेंट चलाने वाले होस्ट पर तब खो जाते हैं जब उसका CPU व्यस्त होता है या उसके नेटवर्क बफ़र्स ओवरफ़्लो हो जाते हैं। नेटवर्क लेटेंसी की गणना उस कुल समय के साथ की जानी चाहिए जब प्रोब्स वायर या मध्यवर्ती नेटवर्क नोड्स पर थे, जबकि I/O बफ़र्स में प्रतीक्षा करने में और एजेंट प्रक्रिया के OS शेड्यूलिंग के लिए लंबित रहने में बिताए गए समय को बाहर रखा गया हो।

Roblox का Ping Mesh सिस्टम

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

हमने अपने सिस्टम के सभी घटकों को लागू करने के लिए Go का चयन किया और इसने न्यूनतम सिस्टम संसाधनों का उपयोग करते हुए उच्च स्तर का प्रदर्शन हासिल करने में मदद की।
हमारे एजेंट अत्यधिक स्थिर हैं और उत्पादन होस्ट्स की एक विस्तृत श्रृंखला पर चल सकते हैं, जिसमें वे होस्ट भी शामिल हैं जो Roblox प्लेटफ़ॉर्म पर ट्रैफ़िक, कैशिंग और एप्लिकेशन सर्वर जैसी महत्वपूर्ण सेवाएँ प्रदान कर रहे हैं।
एजेंट को लिनक्स sendmmsg() और recvmmsg() सिस्टम कॉल्स पर Go रैपर फ़ंक्शंस के साथ पैकेट I/O ऑपरेशंस को बैच करने के लिए अनुकूलित किया गया है, जो इसे कम ओवरहेड के साथ उच्च दर पर प्रोब प्रसारित करने में सक्षम बनाता है। हमारी डिप्लॉयमेंट में हर एजेंट एक साथ 100 अन्य होस्ट्स तक 100 पैकेट प्रति सेकंड (PPS) की दर से प्रोब प्रसारित करता है। एजेंट प्रत्येक गंतव्य पर हर सेकंड पैकेट बर्स्ट प्रसारित करता है।
प्रोब प्रत्येक गंतव्य पर आईपी हेडर में विभिन्न प्रकार-की-सेवा (TOS) फ़ील्ड मान ले जाते हैं और नेटवर्क पर पैकेट हानि और विलंबता के लिए अलग से उनकी गणना की जाती है। प्रत्येक पैकेट बर्स्ट में हर दूसरे गंतव्य के लिए कई TOS मानों का मिश्रण शामिल होता है। यह विभिन्न गुणवत्ता-की-सेवा (QoS) वर्गों के लिए नेटवर्क प्रदर्शन की निगरानी करने में मदद करता है।
एजेंट प्रत्येक प्रोब पथ पर प्रति मिनट 6000 पैकेट में से 1 जितनी कम नेटवर्क ड्रॉप का पता लगा सकता है। नेटवर्क के कोर या एज में 1 सेकंड से कम समय तक रहने वाले पैकेट लॉस का पता लगाया जा सकता है, जैसे कि BGP फ्लैप के दौरान।
जब त्रुटियाँ ड्रॉप के लिए जिम्मेदार होती हैं, तो प्रोब पैकेट ड्रॉप चार्ट नेटवर्क डिवाइस इंटरफ़ेस त्रुटि दरों की नकल करते हैं। हम नेटवर्क में ट्रैफ़िक ब्लैक-होलिंग बग्स का पता लगाने में सक्षम हुए हैं, जिन्हें ढूँढना मुश्किल होता है।
एजेंट नेटवर्क लेटेंसी माप में उच्च सटीकता प्राप्त करने के लिए NIC कर्नेल रीड टाइमस्टैम्प का उपयोग करते हैं। होस्ट OS शेड्यूलिंग लेटेंसी और नेटवर्क क्लॉक ड्रिफ्ट को बाहर रखते हुए, 50–100 माइक्रोसेकंड की एक सुसंगत राउंड ट्रिप इनट्रा-साइट लेटेंसी को मापा जा सकता है।
कम सीपीयू उपयोग और मेमोरी फ़ुटप्रिंट। एजेंट पीक ट्रांसमिट और रिसीव दरों (प्रत्येक 5 kpps) पर एक सिंगल कोर का 25% से कम उपयोग करता है। तैनात किए गए अधिकांश एजेंट एक कोर का केवल लगभग 5% उपयोग करते हैं। एजेंट के Tx और Rx पैकेट बफ़र्स और काउंटर्स को प्रबंधित करने के लिए केवल 10MB हीप मेमोरी की आवश्यकता होती है। जब नेटवर्क बढ़ता है तो हम सीमाओं को समायोजित करके या अतिरिक्त एजेंट जोड़कर वर्टिकली या हॉरिजॉन्टली स्केल कर सकते हैं।
जब होस्ट सिस्टम तनाव में होता है, तब एजेंट पर शायद ही कोई प्रभाव पड़ता है। हमें सटीक परिणाम तब भी मिले हैं जब कई मौकों पर होस्ट CPU लोड 99% तक पहुँच गया था।
प्रत्येक एजेंट के स्वास्थ्य की निगरानी के लिए टेलीमेट्री एकत्र की जाती है। एजेंट समस्याग्रस्त स्थितियों की पहचान कर सकते हैं, जैसे जब होस्ट सिस्टम रिबूट होता है, जब एजेंट प्रक्रिया पुनः आरंभ होती है, या जब सॉकेट बफ़र्स के ओवरफ़्लो होने के कारण पैकेट ड्रॉप हो जाते हैं।

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

हमने अपनी पहली तैनाती में 150 एजेंट्स के साथ शुरुआत की, और अब सफलतापूर्वक 10 गुना विस्तार कर लिया है। यह मेष हमारी बैकबोन को कवर करता है जो दुनिया भर में फैले 25 साइटों को आपस में जोड़ता है। हमारे एक प्राथमिक डेटा सेंटर साइट पर हमारे पास 200+ रैक को कवर करने वाला एक इनट्रा-साइट मेष है, जिसमें लगभग 33,000 स्ट्रीम हैं जो 1.65 Mpps प्रोब दर तक समेकित होती हैं। प्रत्येक रैक को अन्य रैक से 5–10 kpps के प्रोब प्राप्त होते हैं। शेड्यूलर एप्लिकेशन सभी साइटों में हमारे सभी एजेंट्स के बीच 35,000 से अधिक लक्ष्यों की गणना करता है और उन्हें समान रूप से वितरित करता है।

डेटा संग्रह और दृश्यीकरण

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

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

उपरोक्त पैकेट हानि केवल 1 सेकंड तक चली और यह पॉड स्विचों पर उन लिंक में से एक पर हुए BGP सत्र रीसेट के साथ मेल खाती है, जो उन रैक को फैब्रिक के बाकी हिस्सों से जोड़ते हैं।

कुछ घंटों के दौरान हमारे परीक्षण प्रोब्स द्वारा डेटा सेंटर साइट पर एक विशिष्ट रैक में मापा गया पैकेट हानि। यह ग्राहकों को प्रभावित नहीं कर रहा था और नेटवर्क लिंक के स्वचालित ड्रेन होने के लिए निर्धारित सीमा से नीचे था।

उस चार्ट की तुलना रैक के TOR स्विच और फैब्रिक स्विच के बीच लिंक पर इंटरफ़ेस त्रुटि दरों से करें, इससे पहले कि वह ड्रेन हो गया हो।

DC फैब्रिक के भीतर एक स्विच पर लाइन कार्ड की विफलता के दौरान अल्पकालिक लेकिन भारी पैकेट ड्रॉप्स।

पृष्ठभूमि नेटवर्क में विशिष्ट स्ट्रीम्स पर अलग-अलग मौकों पर ट्रैफ़िक ब्लैक-होलिंग।

डीसी के भीतर ट्रैफ़िक ब्लैक-होलिंग केवल एक विशिष्ट रैक और गंतव्य आईपी के बीच

सारांश और अगले कदम

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

हमारी प्रणाली रॉब्लॉक्स क्लाउड नेटवर्क की समग्र विश्वसनीयता के बारे में भी जानकारी प्रदान कर सकती है। हमारे एक प्रमुख डेटा सेंटर साइट पर, हमारे पास प्रति मिनट 100 मिलियन से अधिक प्रोब हैं जो नेटवर्क की स्थिति की निगरानी करते हैं और हम शायद ही कभी प्रति मिनट 50 से अधिक पैकेट हानि की गिनती तक पहुँचते हैं। यह हमारे डेटा सेंटर नेटवर्क से लगभग 6 9's (99.9999%) की विश्वसनीयता का संकेत देता है। अक्सर, 100 मिलियन पैकेट में से किसी भी पैकेट के ड्रॉप होने पर ध्यान नहीं जाता है। जब पैकेट की एक बड़ी मात्रा खो जाती है, तो यह सिस्टम इस बारे में जानकारी प्रदान करता है कि पैकेट ड्रॉप कहाँ और कितनी देर तक हुआ। एक स्वचालित-सुधार इंजन नेटवर्क को स्वयं ठीक कर लेता है और उपयोगकर्ता ट्रैफ़िक को नेटवर्क में एक अलग रास्ते से पुनर्निर्देशित करके उसे और अधिक ड्रॉप होने से बचाता है। Roblox में नेटवर्किंग टीम ने एक अत्यंत विश्वसनीय क्लाउड नेटवर्क बनाया है।

भविष्य में, हम डिवाइस टेलीमेट्री, सिस्लग, और अन्य डेटा सेट से डेटा को सहसंबंधित करने के लिए एक एनालिटिक्स इंजन का उपयोग करने का इरादा रखते हैं। फिर हम यह पता लगाने में मदद के लिए कि नेटवर्क की खराबी कहाँ हुई, उसे पिंग मेष डेटा से तुलना करने की योजना बनाते हैं। जैसे-जैसे रॉब्लॉक्स का क्लाउड नेटवर्क विस्तार और विकास करता रहेगा, हम IPv6 और जंबो फ्रेम को शामिल करने के लिए अपने प्रोबिंग तंत्र को बेहतर बनाने की योजना बनाते हैं, साथ ही इंटर-साइट कवरेज बढ़ाने के लिए और एजेंट जोड़ने की योजना बनाते हैं।

प्रवीन पोनाकान्ति रोब्लॉक्स में एक प्रिंसिपल इंजीनियर हैं जो ट्रैफ़िक और नेटवर्क इंफ्रास्ट्रक्चर पर काम करते हैं। उन्होंने बड़े पैमाने के क्लाउड प्लेटफ़ॉर्म पर नेटवर्क मॉनिटरिंग और अलर्टिंग सेवाओं के साथ-साथ डेटा सेंटर नेटवर्किंग गियर पर सिस्टम सॉफ़्टवेयर के विकास का नेतृत्व किया है। उन्होंने सांता क्लारा विश्वविद्यालय से कंप्यूटर इंजीनियरिंग में मास्टर डिग्री प्राप्त की है।

न तो रॉब्लॉक्स कॉर्पोरेशन और न ही यह ब्लॉग किसी कंपनी या सेवा का समर्थन या अनुमोदन करता है। साथ ही, इस ब्लॉग में निहित जानकारी की सटीकता, विश्वसनीयता या पूर्णता के संबंध में कोई गारंटी या वादा नहीं किया जाता है।

नवीनतम

अधिक परिणाम