Azure Service Fabric विश्वसनीय संग्रह और मेमोरी

Question

मान लें कि मैं 5 डी 1 कक्षा (1 कोर, 3.5 जीबी रैम, 50 जीबी एसएसडी) वीएम पर एक सेवा फैब्रिक क्लस्टर चला रहा हूं। और यह कि मैं इस क्लस्टर पर एक विश्वसनीय और एक राज्यव्यापी 2 विश्वसनीय सेवाएं चला रहा हूं। आइए मान लें कि प्रतिलिपि लक्ष्य 3.

1. मेरी विश्वसनीय संग्रह कितनी गणना कर सकता है इसकी गणना कैसे करें?

2. मान लें कि मैं एक या अधिक राज्य सेवा प्रदान करता हूं। चूंकि मैं वास्तव में नहीं जानता कि फ्रेमवर्क सेवाओं को कैसे वितरित करता है, मुझे सबसे रूढ़िवादी दृष्टिकोण लेने की आवश्यकता है और मान लीजिए कि एक नोड एक ही नोड पर मेरी सभी राज्यिक सेवाओं को चला सकता है और उनकी संचयी स्मृति को रैम के नीचे उपलब्ध होना चाहिए एकल मशीन?

Answer 1

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

1) आम तौर पर किसी दिए गए मशीन पर संग्रह उपलब्ध स्मृति की मात्रा या नोड पर उपलब्ध डिस्क स्थान की मात्रा से घिरा होता है, जो भी कम हो। आज हम संग्रह में सभी डेटा को स्मृति में रखते हैं और इसे डिस्क पर भी जारी रखते हैं। इसलिए क्लस्टर में आपके संग्रह की अधिकतम राशि आमतौर पर (क्लस्टर में उपलब्ध स्मृति की मात्रा)/(लक्ष्य प्रतिकृति सेट आकार) है।

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

चलो एक और उदाहरण लें। आइए मान लें कि यह आपके उदाहरण के समान ही है, इस मामले को छोड़कर आप विभाजित होने के लिए राज्य सेवा को स्थापित करते हैं। आइए मान लें कि आपने 5 की विभाजन संख्या चुनी है। तो अब प्रत्येक नोड पर आपके पास प्राथमिक विभाजन और 2 विभाजनों को अन्य विभाजन से लिया गया है। इस मामले में प्रत्येक विभाजन केवल अधिकतम 1.16 जीबी राज्य धारण करने में सक्षम होगा, लेकिन अब कुल मिलाकर आप क्लस्टर में 5.83 जीबी राज्य पैक कर सकते हैं (क्योंकि सभी नोड्स का अब पूरी तरह से उपयोग किया जा सकता है)। संयोग से, गणित कार्यों को साबित करने के लिए, यह है (क्लस्टर में 3.5 नोड प्रति नोड * 5 नोड्स) [17.5]/(लक्ष्य प्रतिकृति सेट आकार 3) = 5.83।

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

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

ध्यान दें कि यह अधिकतम संभव खपत है, और सेवा के बाहर कोई उपभोग नहीं मानता है। इसे अपने अधिकतम के रूप में लेना उचित नहीं है। आप इसे कई कारणों से कम करना चाहते हैं, लेकिन सबसे व्यावहारिक कारण यह सुनिश्चित करना है कि क्लस्टर में पर्याप्त उपलब्ध क्षमता के उन्नयन और असफलताओं की उपस्थिति में। उदाहरण के तौर पर, मान लीजिए कि आपके पास 5 अपग्रेड डोमेन और 5 दोष डोमेन हैं। अब मान लें कि एक गलती डोमेन के लायक नोड्स विफल रहता है जबकि आपके पास अपग्रेड डोमेन में अपग्रेड हो रहा है। इसका मतलब है कि आपकी क्लस्टर क्षमता का 40% से थोड़ा कम हो सकता है, और आप शायद शेष नोड्स को जारी रखने के लिए पर्याप्त जगह छोड़ना चाहते हैं। इसका मतलब यह है कि यदि आपका क्लस्टर पहले 5.83 जीबी राज्य (हमारी पूर्व गणनाओं से) पकड़ सकता है, तो वास्तव में आप शायद इसमें 3.5 जीबी से अधिक राज्य नहीं डालना चाहते हैं क्योंकि अधिक से अधिक सेवा सक्षम नहीं हो सकती है 100% स्वस्थ होने के लिए (ध्यान दें कि हम तुरंत प्रतिस्थापन प्रतिकृतियां नहीं बनाते हैं इसलिए इस मामले में भाग लेने से पहले नोड्स को आपके प्रतिकृति रीस्टार्ट WaitDuration के लिए नीचे जाना होगा)। मेट्रिक्स, क्षमता, बफर क्षमता के बारे में अधिक जानकारी है (जिसे आप यह सुनिश्चित करने के लिए उपयोग कर सकते हैं कि विफलता मामलों के लिए नोड्स पर कमरा छोड़ा गया हो) और गलती और अपग्रेड डोमेन this article में शामिल हैं।

कुछ और चीजें हैं जो व्यावहारिक रूप से उस राज्य की मात्रा को सीमित कर देगी जिसे आप स्टोर करने में सक्षम होंगे। आप कई चीजें करना चाहेंगे:

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

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

मुझे पता है कि यह एक लंबा जवाब रहा है, लेकिन मुझे आशा है कि आपको यह सहायक और पूर्ण मिलेगा।