MMORPG सर्वर रखरखाव


14

ऐसा लगता है कि अधिकांश mmorpg गेम में कुछ नियमित सर्वर रखरखाव, कुछ हर दिन, कुछ सप्ताह में एक बार होते हैं। ऐसा क्या है जो उन्हें वास्तव में करना है, और यह क्यों आवश्यक है?

यदि आप ऐसी किसी परियोजना से शुरू करते हैं तो आप इससे बचने के लिए क्या कर सकते हैं?

जवाबों:


17

मुझे संदेह है कि वे अपने कोड के नवीनतम संस्करण को तैनात कर रहे हैं, जिसके लिए उन्हें आवेदन को फिर से शुरू करना होगा (और फिर से सक्षम होने से पहले कुछ परीक्षण चलाने की उम्मीद है)। उस दृष्टिकोण से, यह एक StackOverflow समस्या का अधिक और एक ServerFault का कम है।

मुझे लगता है कि हॉट-पैचिंग सिस्टम बनाना संभव है, लेकिन यह आवश्यक रूप से अविश्वसनीय रूप से जटिल होगा। जो मैं समझता हूं, एक MMO सर्वर "एप्लिकेशन" में कई अलग-अलग घटक होते हैं -

  • लॉगिन सर्वर - प्रमाणीकरण को संभालता है और गेमप्ले सर्वर के बीच "हब" के रूप में कार्य करता है। एक बार क्लाइंट इन-गेम होने के बाद वे लॉगिन सर्वर के साथ इंटरैक्ट नहीं करते हैं। ऐसी प्रणाली में आप पैच लागू कर सकते हैं और गेमप्ले में हस्तक्षेप किए बिना लॉगिन सर्वर को पुनः आरंभ कर सकते हैं (हालांकि आपके पास समय की अवधि होगी जहां लोग लॉग इन नहीं कर पाएंगे)।

  • गेमप्ले सर्वर - मशीनों का क्लस्टर तार्किक स्वतंत्र इकाइयों ("दुनिया", आदि) में वर्गीकृत किया गया है। यह माना जाता है कि प्रत्येक गेमप्ले क्लस्टर एक दूसरे से राज्य के अनुरूप करने के लिए किसी प्रकार के आंतरिक संचार प्रोटोकॉल का उपयोग करता है; आप शायद एक ही बार में प्रत्येक क्लस्टर को पैच करने वाले हैं। ऐसा करने का एक संभावित तरीका एक गर्म-विफलता को पैच करना है। फिर आपको दोनों में सक्षम होना चाहिए

    1. क्लाइंट को वार्म फ़ेलओवर से कनेक्ट करने के लिए सिग्नल दें और पुराने क्लस्टर से डिस्कनेक्ट करें।
    2. सभी क्लाइंट ट्रांसफर होने पर राज्य को फेलओवर और आउट-ऑफ-डेट एप्लिकेशन सर्वर के बीच सिंक किया हुआ रखें।
  • डेटाबेस सर्वर - किसी तरह का लगातार डेटास्टोर, जैसे RDBMS। उम्मीद है कि आप डेटास्टोर में अक्सर बदलाव नहीं कर रहे हैं। संभवतः प्रत्येक गेमप्ले सर्वर / क्लस्टर में एक स्वतंत्र डेटास्टोर है। आप एक ही ट्रिक को गर्म फेलओवर के साथ उपयोग करने में सक्षम हो सकते हैं (और गेमप्ले सर्वर को डिस्कनेक्ट करने के लिए कहें, पुराने और फेलओवर डेटाबेस को सिंक करने के लिए प्रतीक्षा करें, फिर फ़ेलओवर को फिर से कनेक्ट करें) लेकिन यह मेरे लिए बहुत जोखिम भरा है।

उपरोक्त सभी मामले पहले से ही जटिल प्रणाली में एक अविश्वसनीय राशि जोड़ते हैं और उन स्थानों का एक गुच्छा पेश करते हैं जहां एक कोड विफलता डेटा हानि या भ्रष्टाचार का कारण बन सकती है।

एक अन्य समाधान एक ऐसी भाषा का उपयोग करना है जिसे 100% अपटाइम के लिए डिज़ाइन किया गया है और जिसमें हॉटपैचिंग रनिंग कोड के लिए अंतर्निहित कैपिटलिटी हैं। एरलैंग एक अच्छा विकल्प ( हॉटपैचिंग उदाहरण ) है, और जावा में समान कार्यक्षमता है


12

किसी और को वास्तव में इस तरह से कुछ चलाने का अनुभव नहीं है? हुह।

ऐसे कई कारण हैं जो कोड और सिस्टम दोनों को पाटते हैं। सबसे पहले, याद रखें कि अधिकांश 'बड़े' MMO इंजनों को कई साल पहले क्रमादेशित किया गया था, और ग्राफिक्स और प्रौद्योगिकी उन्नयन के बावजूद, अभी भी निर्भर करता है कि इनमें से कई सिस्टम 2000 या उसके बाद लिखे गए थे। उदाहरण के लिए, ईव-ऑनलाइन, अभी भी एक विशाल Microsoft SQL सर्वर इंस्टेंस पर चलता है, यही कारण है कि वे हमेशा हार्डवेयर को अपग्रेड करके इसे अधिक से अधिक खींचने की कोशिश कर रहे हैं।

वाह और ईवीई के शुरू होने के बाद से सुधार का एक उदाहरण Google के MapReduce (और यह ओपन-सोर्स कार्यान्वयन, Hadoop) की तरह वितरित कुंजी / मूल्य डेटाबेस में किया गया कार्य है, बहुत तेजी से सकारात्मक प्रतिक्रिया प्रसंस्करण कतार सेवाओं (अमेज़ॅन एसएएसएस), और अन्य " क्लाउड "-ऑर्डिनेटेड टेक्नोलॉजीज।

मुझे ईवीई के साथ सबसे अधिक अनुभव है (मैं एक बैटलसेक्स पुरुष की तुलना में लेज़र लड़का अधिक हूं), इसलिए इन उदाहरणों में से कुछ अधिक ईवीई-उन्मुख हैं।

जहाँ तक सिस्टम कारण चलते हैं:

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

जहाँ तक सॉफ़्टवेयर कारण चलते हैं:

  • गेम्स, जब संचालन करते हैं, तो बहुत से ओएलटीपी का उपयोग करें - जो ऑन लाइन ट्रांजैक्शन प्रोसेसिंग है - डेटाबेस को पढ़ता / लिखता है। हालांकि, कभी-कभी आप एक सारांश रिपोर्ट चाहते हैं ... जैसे कि पिछले 3 वर्षों में आपने कितने विशेष जानवर को मार दिया है। यह एक OLAP रिपोर्ट द्वारा नियंत्रित किया जाता है - यह ऑन लाइन एनालिटिकल प्रोसेसिंग है - जिसमें एक विशाल डेटासेट में बहुत सी पंक्तियों के आधार पर सारांश जानकारी होती है। वास्तव में, गेम उन प्रणालियों को लागू करता है जो पढ़ने के लिए आवश्यक प्रश्नों की संख्या को सीमित करने के लिए कैश बनाने के लिए OLAP का उपयोग करते हैं - यानी, वे एक निश्चित तिथि के रूप में कुल का निर्माण करते हैं, और फिर जब आप सवाल पूछते हैं तो वे सिर्फ पंक्तियों को पढ़ते हैं OLTP स्टोर से जो निश्चित अवधि के बाद की समयावधि को सारांशित करता है। दोनों को मिलाएं, और आप वास्तव में यह निर्धारित कर सकते हैं कि आपका जीवन कितना बेकार हो गया है।
  • उपर्युक्त हॉट-पैचिंग, जिसे मैं एक सॉफ्टवेयर समस्या के रूप में देखता हूं, लेकिन सॉफ्टवेयर डेवलपर्स एक सिस्टम समस्या के रूप में देखते हैं। ;)
  • वस्तुओं के भंडार को फिर से भरना - ईव में, क्षुद्रग्रह बेल्ट को हर रात ताज़ा किया जाता है और कुछ परिसरों को भी पुनर्नवीनीकरण किया जाता है। ऑन-लाइन करते समय यह कुछ हद तक किया जा सकता है, लेकिन कुछ एल्गोरिदम बहुत जटिल हैं और ऑफ-लाइन मोड में किए जाने की आवश्यकता है क्योंकि वे पिछले दिनों की आर्थिक गतिविधि का सारांश देते हुए डेटाबेस को थोड़े समय के लिए घुटनों तक ले आते हैं।

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

यदि आप ध्यान दें, तो ईव का रखरखाव तब होता है जब यह इंग्लैंड में दोपहर है, जहां प्राथमिक डेटासेंटर है।


3

मुझे संदेह है कि बर्फ़ीला तूफ़ान (मैं जिक्र कर रहा हूं कि यह मंगलवार की सुबह है कि आप अपना प्रश्न पोस्ट कर रहे हैं) कुल रखरखाव के लिए उद्धरण हैं; हर सर्वर को काम करने में लंबा समय नहीं लगता है।

हालांकि व्यक्तिगत सर्वरों को अधिक तेज़ी से वापस लाना संभव हो सकता है, लेकिन यह उन खिलाड़ियों के प्रति पक्षपात की भावना को रोकेगा, जिनके दायरे में पहले से गिरावट आई थी। जैसे, वे सब कुछ नीचे रख देते हैं जब तक कि सभी काम पूरा न हो जाए; काम करने के लिए सैकड़ों स्थानों के साथ, वे संभवतः समानांतर में बहुत काम करते हैं, लेकिन अभी भी ऑनलाइन चीजों को वापस लाने से पहले एक अंतिम जांच को क्रमबद्ध करते हैं। यदि आप एक हार्डवेयर अपग्रेड कर रहे हैं, तो संभवतः यह कई डेटा केंद्रों में क्रमबद्ध है जैसा कि उनके पास है।

के रूप में वे रखरखाव क्यों करते हैं, इसमें से कुछ सिर्फ एक प्रदर्शन रिबूट हो सकता है। हालांकि यह बहुत अच्छा होगा यदि इस तरह के रिबूट की आवश्यकता नहीं थी, ऐसा करने की लागत बनाम ऐसा न करने का प्रभाव यहां पर आपकी पसंद को निर्देशित कर सकता है।

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

अंत में, उस बड़े सब्सक्राइबर को ऑनलाइन स्टेटफुल सर्विस मुहैया कराने का मैकेनिक्स कुछ बेहतरीन प्रथाओं को चुनौती देता है, जो कि हम किसी वेबसाइट या अन्य पारंपरिक इंटरनेट-आधारित सेवा के बारे में बात करते समय बता सकते हैं।


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

1

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

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


हालांकि वर्चुअलाइजेशन के साथ अधिक उपलब्ध संसाधनों के साथ हार्डवेयर से भारी लोड किए गए सर्वरों को माइग्रेट करना संभव है कि वे लाइव और स्वचालित रूप से कर सकें ... विशेष रूप से एक गेम में जहां अधिकांश एक्शन लैग को कई मिलीसेकेंड (कभी-कभी सौ से अधिक) में मापा जाता है। लेकिन यह जटिल और महंगा हो सकता है ^ ^
ऑस्कर डुवॉर्न

Oskar, ध्यान रखें कि EVE और WoW के पीछे की मूल तकनीक लगभग 2002 में लिखी गई थी, इससे पहले कि ये तकनीक वास्तव में परिपक्व थीं।
बजे कार्ल काट्ज़के जूल

0

मुमकिन है कि आप कुछ प्रमुख डीबी स्कीमा परिवर्तन जैसे क्लस्टरिंग / लोड-बैलेंसिंग के माध्यम से सौदा नहीं कर सकते हैं।


0

हाल के एक विषय में मुझे कितनी बार लिनक्स सर्वर को रिबूट करना चाहिए एक और अच्छे बिंदु का उल्लेख किया गया था, यह सत्यापित करते हुए कि सब कुछ रिबूट पर या किसी (बड़े) कॉन्फ़िगरेशन परिवर्तन के बाद ठीक से शुरू होता है।


0

हार्डवेयर (या हार्डवेयर प्रतिस्थापन) का एक सरल उन्नयन भी MMORPG गेम द्वारा "सर्वर रखरखाव" के रूप में प्रस्तुत किया गया है। इसलिए तुच्छ हम अक्सर इसके बारे में भूल जाते हैं।


0

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

आप http://www.next-gen.cc पर मेरी साइट देख सकते हैं ।


0

मुझे विश्वास है कि रखरखाव खिड़की भी नियमित हार्डवेयर प्रतिस्थापन के लिए घटकों को विफल करने के लिए प्रतिस्थापन की अनुमति देता है।


आमतौर पर नहीं। वे हार्डवेयर पर कुछ भविष्य कहे जाने वाले मैट्रिक्स चलाएंगे, लेकिन वे आमतौर पर किसी सिस्टम में सभी प्रशंसकों या अन्य 'खर्च करने योग्य' बिट्स को तब तक प्रतिस्थापित नहीं करते हैं जब तक कि यह विफल होने के संकेत नहीं दिखाता है, अर्थात RPM ड्रॉप हो रहे हैं या SMART एक उच्च लेखन त्रुटि गिनती दिखा रहा है।
बजे कार्ल काट्ज़के जूल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.