एक साधारण लोड-बैलेंसर / फेलओवर'ए आईपी सेवाओं की अवधारणा

एक तकनीकी समस्या को हल करने की प्रक्रिया में, कई मशीनों पर लोड को वितरित करने के लिए एक सार्वभौमिक तरीके का विचार, सैद्धांतिक रूप से किसी भी सेवा जिसे आईपी द्वारा एक्सेस किया जा सकता है, का जन्म हुआ था।

शायद अगली बाइक, लेकिन इससे पहले नहीं आई थी। यदि यह विचार व्यवहार्य हो जाता है, तो शायद किसी को यह पता चलता है - तो यह बर्बाद नहीं होगा, दुर्भाग्य से, खुद के लिए कोई समय नहीं है, हालांकि मैं वास्तव में इसे आज़माना चाहता हूं। यदि यह पहले से ही कहीं लागू हो चुका है, तो मैं आपसे सख्ती से न्याय नहीं करने के लिए कहता हूं: मैंने इसे स्वयं नहीं खोजा है, लेकिन अब मुझे लंबी खोज के लिए ज्यादा समय नहीं है।

तो संक्षेप में:
1. nsswitch.conf में मेजबानों के लिए हम अपनी लाइब्रेरी से पहले फाइल और डीएनएस रजिस्टर करते हैं। ताकि / etc / मेजबान और DNS में, सिस्टम तभी दिखता है जब हमारी लाइब्रेरी NSS_STATUS_UNAVAIL लौटाती है।
2. हम अपनी लाइब्रेरी को सिर्फ एक int gethostbyname_r (...) फ़ंक्शन के साथ बनाते हैं (इसे लागू करने के तरीके के विवरण के लिए, यहां देखें: www.gnu.org/s/hello/manual/libc/Name-Service-Swn.html#Name-Service-Switch) )। फ़ंक्शन यह देखने के लिए देखता है कि क्या अनुरोधित नाम साझा मेमोरी में है, यदि वह ऐसा करता है, तो वह वहां से आईपी पता लौटाता है और 1 से साझा मेमोरी में इस नाम का उपयोग करने के लिए काउंटर बढ़ाता है। यदि साझा मेमोरी में ऐसा कोई नाम नहीं है, तो यह NSS_STATUS -UNAVAIL लौटाता है।
3. यदि लाइब्रेरी ने NSS_STATUS_UNAVAIL लौटा दिया है - तो सिस्टम नियमित रूप से (/ etc / मेजबान, DNS) में IP के नाम को आगे भी हल करता रहेगा।
4. किसी भी भाषा में जो एक मल्टीकास्ट सॉकेट खोल सकता है और साझा मेमोरी और नामित सॉकेट के साथ काम कर सकता है, एक छोटी सेवा लिखी जाती है:
4.1 सेवाओं के बारे में जानकारी के साथ इसके कॉन्फ़िगरेशन (प्रारंभिक कॉन्फ़िगरेशन) को पढ़ता है, इसे "प्रारंभिक" चिह्नित मल्टीकास्ट समूह में स्थानांतरित करता है और इसे साझा मेमोरी में रखता है।
4.2 एक मल्टीकास्ट समूह के अन्य सदस्यों से आने वाली हर चीज को साझा मेमोरी में लोड किया जाता है (या डिलीट किया जाता है, डिलीट होता है)। यदि यह "प्रारंभिक" चिह्नित है, तो प्रारंभिक कॉन्फ़िगरेशन के जवाब में ज्ञात परिवर्तन भेजें।
4.3 सॉकेट के माध्यम से कुछ कमांड को सुनता है, साझा मेमोरी से किसी चीज़ को जोड़ने / हटाने / हटाने और मल्टीकास्ट समूह में डुप्लिकेट करने के परिणामस्वरूप।
4.4 वैकल्पिक: जब काउंटरर्स साझा मेमोरी में एक निश्चित मूल्य तक पहुंचते हैं, तो मेजबान इसे वहां से हटा देता है, मल्टीकास्ट समूह में कमांड को डुप्लिकेट करता है।
5. हर किसी को एक निश्चित सेवा का उपयोग करने की आवश्यकता है जो इसे नाम से जोड़ता है - पुस्तकालय इसे तुरंत साझा मेमोरी से देगा।

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

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

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

आपको क्या लगता है?