ऐपफ़ैब्रिक रिडंडेंसी

Question

हमने अभी 2 सर्वरों के एक ऐपफ़ैब्रिक क्लस्टर का परीक्षण किया जहां हमने "लीड" सर्वर हटा दिया। दूसरे सर्वर त्रुटि के साथ यह करने के लिए किसी भी अनुरोध पर टाइमआउट:

Microsoft.ApplicationServer.Caching.DataCacheException: ErrorCode<ERRCA0017>:SubStatus<ES0006>: There is a temporary failure. Please retry later. (One or more specified Cache servers are unavailable, which could be caused by busy network or servers. Ensure that security permission has been granted for this client account on the cluster and that the AppFabric Caching Service is allowed through the firewall on all cache hosts. Retry later.)

practive में इसका मतलब है कि अगर क्लस्टर में एक सर्वर नीचे चला जाता है तो वे सभी नीचे जाना। (ध्यान दें कि हम विंडोज क्लस्टर का उपयोग नहीं कर रहे हैं, केवल एक दूसरे को कई ऐपफैब्रिक कैश सर्वर जोड़ रहे हैं।)

मुझे एक सर्वर बंद होने पर भी ऑपरेटिंग जारी रखने के लिए क्लस्टर की आवश्यकता है। मैं यह कैसे करु?

(मुझे पता है इस सवाल का serverfault borderlining है, लेकिन डेवलपर्स इस पता होना चाहिए imho।)

Answer 1

आप एक ही सर्वर क्रैश जीवित रहने के लिए कैश के लिए कम से कम तीन नेतृत्व सर्वर पर AppFabric कैश स्थापित करने के लिए होगा। दस्तावेज़ बताते हैं कि क्लस्टर केवल तभी नीचे जायेगा जब लीड सर्वर के "बहुमत" नीचे जाते हैं, लेकिन ठीक प्रिंट में, वे बताते हैं कि 2 में से 1 बहुमत का गठन करता है। मैंने सत्यापित किया है कि एक तीन लीड-नोड क्लस्टर से सर्वर को निकालने के रूप में काम करता है।

Answer 2

विशिष्ट वितरित सिस्टम अवधारणा। एक कलाकार में होने के लिए लिखने या पढ़ने के लिए कोरम के लिए आपको 2 एफ + 1 सर्वर होना चाहिए जहां एफ सर्वर विफल होने की संख्या है। मुझे लगता है कि ऐपफैब्रिक या सीपी (सीएपी प्रमेय में) आम सहमति आधारित सिस्टम को क्लस्टर के काम के लिए ऐसा करने की ज़रूरत है।

--Sai

Answer 3

यही वास्तव में AppFabric वास्तुकला के साथ एक समस्या है और यह नहीं बल्कि "लीड-मेजबान" की अवधारणा के संदर्भ में भ्रामक है। विचार यह है कि अधिकांश लीड होस्ट चलाना चाहिए ताकि क्लस्टर बना रहता है और चल रहा हो। तो यदि आपके पास तीन सर्वर थे तो आपको कम से कम दो लीड होस्ट एक दूसरे के साथ लगातार संवाद करना और सर्वर संसाधनों को खाना होगा और यदि दोनों नीचे जाएं तो पूरा क्लस्टर विफल हो जाएगा। विचार यह है कि एक पीयर-टू-पीयर आर्किटेक्चर होना है जहां सभी सर्वर सहकर्मियों के रूप में कार्य करते हैं, जिसका अर्थ है कि क्लस्टर के नीचे दो सर्वर नीचे जाने के बावजूद काम नहीं करते हैं। NCache का प्रयास करें:

http://www.alachisoft.com/ncache/