स्कैला + अक्का: मल्टी-मशीन अत्यधिक उपलब्ध क्लस्टर कैसे विकसित करें

Question

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

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

क्या ऐसे कोई उदाहरण हैं जो अक्का के लिए इस प्रकार की हार्डवेयर गलती सहनशीलता दिखाते हैं? या, क्या आपके पास ऐसा करने के अच्छे तरीकों पर कोई विचार है?

अब तक सबसे अच्छा जवाब मैं साथ आने के लिए कर लिया है, Erlang OTP डॉक्स का अध्ययन उन पर ध्यान करते हैं, और यह पता लगाने के लिए कैसे एक साथ अपने सिस्टम डालने के लिए अक्का में उपलब्ध इमारत ब्लॉकों का उपयोग करने की कोशिश करना है।

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

Answer 1

एचए और लोड प्रबंधन स्केलेबिलिटी का एक बहुत ही महत्वपूर्ण पहलू है और AkkaSource वाणिज्यिक पेशकश के हिस्से के रूप में उपलब्ध है।

Answer 2

यदि आप पहले से ही अपने ग्राहकों में कई संभावित होस्ट सूचीबद्ध कर रहे हैं, तो वे प्रभावी ढंग से लोड बैलेंसर्स बन सकते हैं।

आप एक मेजबान सुझाव सेवा प्रदान कर सकते हैं और क्लाइंट को सलाह दे सकते हैं कि उन्हें किस मशीन से कनेक्ट करना चाहिए (वर्तमान लोड के आधार पर, या जो भी हो), तो क्लाइंट तब तक पिन कर सकता है जब कनेक्शन विफल हो जाता है।

यदि मेजबान सुझाव सेवा नहीं है, तो क्लाइंट इसे आंतरिक सूची से यादृच्छिक होस्ट चुन सकता है, जब तक यह कनेक्ट नहीं हो जाता है।

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

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

सुनिश्चित करें कि मेजबानों की आपकी सूची वास्तविक होस्ट नाम है, न कि आईपी, जो आपको अधिक लचीलापन दीर्घकालिक (यानी आप हमेशा "host1.example.com, host2.example.com" करेंगे ... इत्यादि। यदि आप बुनियादी ढांचे को स्थानांतरित करते हैं और आईपी बदलते हैं)।

Answer 3

आप देख सकते हैं कि RedDwarf और यह कांटा DimDwarf बनाया गया है। वे दोनों क्षैतिज रूप से स्केलेबल क्रैश-केवल गेम ऐप सर्वर हैं और डिमडवर्फ़ आंशिक रूप से स्कैला (नई संदेश कार्यक्षमता) में लिखे गए हैं।उनके दृष्टिकोण और वास्तुकला को आपकी आवश्यकताओं से अच्छी तरह मेल खाना चाहिए :)

Answer 4

2 सेंट ..

बजाय विभाजन राज्य भर में

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

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

अक्का का उपयोग करके, हम नोड्स के बीच लगभग मुफ्त में रिमोटिंग प्राप्त करते हैं। इसका मतलब यह है कि जो भी नोड एक अनुरोध को संभालता है जिसे किसी अन्य नोड्स पर एक समग्र/इकाई के साथ बातचीत करने की आवश्यकता हो सकती है, वह रिमोटएक्टरों के साथ ऐसा कर सकती है।

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

शुभकामनाएँ, एंडी