Cloister → सरल OTP क्लस्टर व्यवस्थापन

लगभग हरेक सफल व्यावसायिक अनुप्रयोगले ढिलो वा पछि एक चरणमा प्रवेश गर्दछ जहाँ तेर्सो स्केलिंग आवश्यक हुन्छ। धेरै अवस्थामा, तपाईं केवल नयाँ उदाहरण सुरु गर्न र लोड औसत घटाउन सक्नुहुन्छ। तर त्यहाँ पनि कम मामूली केसहरू छन् जहाँ हामीले विभिन्न नोडहरू एकअर्काको बारेमा जान्न र कामको भारलाई सावधानीपूर्वक वितरण गर्ने सुनिश्चित गर्न आवश्यक छ।

यो धेरै भाग्यशाली बाहिर भयो एरलाlang, जुन हामीले यसको सुखद सिन्ट्याक्स र यसको वरिपरि हाइपको लागि रोज्यौं, पहिलो-कक्षा छ वितरण प्रणालीहरूको लागि समर्थन। सिद्धान्तमा, यो पूर्णतया तुच्छ सुनिन्छ:

विभिन्न नोडहरूमा प्रक्रियाहरू, साथै लिङ्कहरू र मोनिटरहरू बीचको सन्देश पारदर्शी छ […]

व्यवहारमा, सबै कुरा अलि बढी जटिल छ। वितरण गरियो एरलाlang जब "कन्टेनर" को अर्थ ढुवानीको लागि ठूलो फलामको बक्स हो, र "डकर" केवल लामो शोरम्यानको पर्यायवाची शब्द थियो। IN IP4 त्यहाँ धेरै अव्यवस्थित ठेगानाहरू थिए, नेटवर्क ब्रेकहरू सामान्यतया केबल चपाउने मुसाको कारणले भएको थियो, र उत्पादन प्रणालीको औसत अपटाइम दशकहरूमा मापन गरिएको थियो।

अब हामी सबै अविश्वसनीय रूपमा आत्मनिर्भर, प्याकेज गरिएको, र वितरित वितरित छौं एरलाlang एक वातावरणमा जहाँ गतिशील IP ठेगानाहरू उत्कृष्ट अनियमितताको सिद्धान्तमा हस्तान्तरण गरिन्छ, र नोडहरू देखा पर्न र शेड्यूलरको बायाँ हिलको लहरमा गायब हुन सक्छन्। वितरण गरिएको प्रत्येक परियोजनामा ​​बॉयलरप्लेट कोडको ढेरबाट बच्न एरलाlangप्रतिकूल वातावरणसँग लड्न मद्दत चाहिन्छ।

भन्नु: मलाई थाहा छ कि त्यहाँ छ libcluster। यो साँच्चै राम्रो छ, यसमा एक हजार भन्दा बढी ताराहरू छन्, लेखक समुदायमा प्रसिद्ध छ, र त्यो सबै। यदि यो प्याकेजले क्लस्टर बनाउन र कायम राख्नका लागि प्रस्ताव गरेको विधिहरू तपाईंको लागि पर्याप्त छन् भने, म तपाईंको लागि खुसी छु। दुर्भाग्यवश, मलाई धेरै चाहिन्छ। म सेटअपलाई विस्तृत रूपमा नियन्त्रण गर्न चाहन्छु र क्लस्टर पुनर्गठनको थिएटरमा बाहिरी दर्शक बन्न चाहन्न।

आवश्यकताहरू

मलाई व्यक्तिगत रूपमा एउटा पुस्तकालय चाहिन्छ जसले क्लस्टरको व्यवस्थापन लिन्छ र निम्न गुणहरू हुनेछ:

• नोडहरूको हार्ड-कोड गरिएको सूची र सेवाहरू मार्फत गतिशील खोज दुवैको साथ पारदर्शी कार्य एरलाlang;
• प्रत्येक टोपोलोजी परिवर्तनको लागि पूर्ण रूपमा कार्यात्मक कलब्याक (नोड त्यहाँ, नोड यहाँ, नेटवर्क अस्थिरता, विभाजन);
• लामो र छोटो नामहरूको साथ क्लस्टर सुरु गर्नको लागि पारदर्शी इन्टरफेस, जस्तै :nonode@nohost;
• डकर समर्थन बाकस बाहिर, पूर्वाधार कोड लेख्न बिना।

पछिल्लोको मतलब मैले स्थानीय रूपमा एप्लिकेसन परीक्षण गरेपछि :nonode@nohost, वा प्रयोग गरेर कृत्रिम रूपमा वितरित वातावरणमा test_cluster_task, म मात्र दौडन चाहन्छु docker-compose up --scale my_app=3 र हेर्नुहोस् कि यसले कसरी कुनै कोड परिवर्तन बिना डकरमा तीनवटा उदाहरणहरू कार्यान्वयन गर्दछ। म पनि जस्तै निर्भर अनुप्रयोगहरू चाहन्छु mnesia - जब टोपोलोजी परिवर्तन हुन्छ, पर्दा पछाडि तिनीहरूले एप्लिकेसनबाट कुनै अतिरिक्त किक बिना क्लस्टर लाइभ पुन: निर्माण गर्छन्।

क्लस्टर क्लस्टरलाई समर्थन गर्नेदेखि कफी बनाउने सबै कुरामा सक्षम पुस्तकालय बन्ने उद्देश्य थिएन। यो चाँदीको गोली होइन जसले सबै सम्भावित केसहरूलाई समेट्ने लक्ष्य राख्छ, वा यस अर्थमा एक शैक्षिक रूपमा पूर्ण समाधान हो कि सिद्धान्तकारहरू CS यस अवधिमा राख्नुहोस्। यो पुस्तकालय एकदम स्पष्ट उद्देश्य पूरा गर्न डिजाइन गरिएको हो, तर यसको धेरै ठूलो काम पूर्ण रूपमा गर्न। यो लक्ष्य स्थानीय विकास वातावरण र प्रतिकूल कन्टेनरहरूले भरिएको वितरित लोचदार वातावरण बीच पूर्ण पारदर्शिता प्रदान गर्न हुनेछ।

छनौट गरिएको दृष्टिकोण

क्लस्टर एप्लिकेसनको रूपमा चलाउनको लागि इरादा राखिएको छ, यद्यपि उन्नत प्रयोगकर्ताहरूले सीधा दौडिएर म्यानुअल रूपमा क्लस्टरको असेंबली र मर्मतका साथ काम गर्न सक्छन्। Cloister.Manager लक्षित अनुप्रयोगको सुपरवाइजर रूखमा।

एप्लिकेसनको रूपमा चलाउँदा, पुस्तकालयमा भर पर्छ config, जसबाट यसले निम्न आधारभूत मानहरू पढ्छ:

config :cloister,
  otp_app: :my_app,
  sentry: :"cloister.local", # or ~w|n1@foo n2@bar|a
  consensus: 3,              # number of nodes to consider
                             #    the cluster is up
  listener: MyApp.Listener   # listener to be called when
                             #    the ring has changed

माथिका प्यारामिटरहरू शाब्दिक रूपमा निम्न हुन्: क्लस्टर OTP अनुप्रयोगको लागि प्रयोग गरिन्छ :my_app, उपयोगहरु Erlang सेवा खोज नोडहरू जडान गर्न, कम्तिमा तीन, र MyApp.Listener मोड्युल (लागू गर्दै @behaviour Cloister.Listener) टोपोलोजी परिवर्तनहरू बारे सूचनाहरू प्राप्त गर्न कन्फिगर गरिएको छ। पूर्ण कन्फिगरेसनको विस्तृत विवरण फेला पार्न सकिन्छ कागजात.

यो कन्फिगरेसन संग, अनुप्रयोग क्लस्टर हुनेछ चरणहरूमा प्रक्षेपण, सहमति नपुगेसम्म मुख्य एप्लिकेसन सुरु गर्ने प्रक्रियालाई ढिलाइ गर्दै (माथिको उदाहरणमा जस्तै तीन नोडहरू जडान र जडान भएका छन्।) यसले मुख्य अनुप्रयोगलाई यो सुरु गर्दा, क्लस्टर पहिले नै उपलब्ध छ भनी अनुमान गर्ने अवसर दिन्छ। जब टोपोलोजी परिवर्तन हुन्छ (त्यहाँ धेरै हुनेछन्, किनभने नोडहरू पूर्ण रूपमा सिंक्रोनस रूपमा सुरु हुँदैन), ह्यान्डलरलाई बोलाइनेछ। MyApp.Listener.on_state_change/2। हामीले स्टेटस म्यासेज प्राप्त गर्दा धेरै जसो समय हामी कुनै कार्य गर्छौं %Cloister.Monitor{status: :up}, जसको अर्थ हो: "नमस्ते, क्लस्टर भेला भयो।"

अधिकतर अवस्थामा, स्थापना consensus: 3 इष्टतम छ किनभने हामीले थप नोडहरू जडान हुने अपेक्षा गरे पनि, कलब्याक मार्फत जानेछ status: :rehashing → status: :up कुनै नयाँ थपिएको वा हटाइएको नोडमा।

विकास मोडमा सुरु गर्दा, तपाईंले मात्र सेट गर्न आवश्यक छ consensus: 1 и क्लस्टर उसले देख्दा खुसीसाथ क्लस्टर असेंबलीको प्रतीक्षा छोड्नेछ :nonode@nohost, वा :node@host, वा :[email protected] - नोड कसरी कन्फिगर गरिएको थियो भन्ने आधारमा (:none | :shortnames | :longnames).

वितरित आवेदन व्यवस्थापन

भ्याकुममा नभएका वितरित अनुप्रयोगहरूमा सामान्यतया वितरित निर्भरताहरू समावेश हुन्छन्, जस्तै mnesia। हामीलाई उही कलब्याकबाट तिनीहरूको पुन: कन्फिगरेसन ह्यान्डल गर्न सजिलो छ on_state_change/2। यहाँ, उदाहरणका लागि, कसरी पुन: कन्फिगर गर्ने विस्तृत विवरण छ mnesia मा उडान मा कागजात क्लस्टर.

प्रयोग को मुख्य लाभ क्लस्टर यो हो कि यसले टोपोलोजी परिवर्तन पछि क्लस्टर पुन: निर्माण गर्न सबै आवश्यक कार्यहरू गर्दछ हुड मुनि। एप्लिकेसन पहिले नै तयार गरिएको वितरण गरिएको वातावरणमा चल्छ, सबै नोडहरू जडान भएका छन्, चाहे हामीलाई IP ठेगानाहरू र त्यसैले नोडको नामहरू पहिले नै थाहा भए तापनि, वा तिनीहरू गतिशील रूपमा तोकिएको/परिवर्तन गरिएको छ। यसका लागि बिल्कुल कुनै विशेष डकर कन्फिगरेसन सेटिङहरू आवश्यक पर्दैन र एप्लिकेसन विकासकर्ताको दृष्टिकोणबाट, वितरित वातावरणमा चल्ने वा स्थानीयमा चल्ने बीचमा कुनै भिन्नता छैन। :nonode@nohost। तपाईं यस बारे थप पढ्न सक्नुहुन्छ कागजात.

यद्यपि टोपोलोजी परिवर्तनहरूको जटिल ह्यान्डलिङ अनुकूलन कार्यान्वयन मार्फत सम्भव छ MyApp.Listener, त्यहाँ सधैं किनारा केसहरू हुन सक्छ जहाँ यी पुस्तकालय सीमितताहरू र कन्फिगरेसन पूर्वाग्रहहरू कार्यान्वयनको आधारशिला साबित हुन्छन्। यो ठीक छ, केवल माथि लिनुहोस् libcluster, जुन अधिक सामान्य-उद्देश्य हो, वा निम्न-स्तर क्लस्टर आफैंलाई ह्यान्डल गर्नुहोस्। यस कोड पुस्तकालयको लक्ष्य प्रत्येक सम्भावित परिदृश्यलाई कभर गर्नु होइन, तर अनावश्यक पीडा र जटिल प्रतिलिपि-पेस्ट बिना सबैभन्दा सामान्य परिदृश्य प्रयोग गर्नु हो।

नोट: यस बिन्दुमा मूलमा "ह्याप्पी क्लस्टरिंग!" वाक्यांश थियो, र यान्डेक्स, जसको साथ म अनुवाद गर्छु (म आफैं शब्दकोशहरू मार्फत जानु पर्दैन), मलाई "ह्याप्पी क्लस्टरिंग!" विकल्प प्रस्ताव गर्‍यो। विशेष गरी वर्तमान भूराजनीतिक अवस्थाको प्रकाशमा यो भन्दा राम्रो अनुवादको कल्पना गर्न सम्भव छैन।

स्रोत: www.habr.com