रेल + देरी नौकरियां: एसएसएच कनेक्शन पूल

Question

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

Net:SSH.start(hostname, username, :password => pass) do |ssh| 
    ssh.exec!(command) 
end 

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

मुझे क्या चाहिए: कहीं भी संग्रहीत कनेक्शन खोले हैं और प्रत्येक कार्यकर्ता द्वारा पुन: उपयोग किया जाता है। ताकि प्रत्येक कार्यकर्ता किसी भी तरह और फिर कनेक्शन प्राप्त सिर्फ

ssh.exec!(command) 

चलाने मैं क्या प्रयास किया है:

• फ़ाइल/डेटाबेस में कनेक्शन भंडारण/कैश के रूप में वे serializable नहीं हैं संभव नहीं लग रहा है
• ने प्रारंभिकरण के तहत तत्काल वैश्विक चर के साथ सिंगलटन कक्षा का उपयोग करने का प्रयास किया है। हालांकि वर्ग कार्यकर्ता प्रत्येक कार्यकर्ता के लिए अलग है (बाद में पाया गया है कि वैश्विक चर एक विकल्प नहीं हो सकता है)।

क्या इसे हल करने का कोई तरीका है? कोई अन्य विचार? धन्यवाद!!

Answer 1

पहले कुछ मूल बातें; एक एसएसएच कनेक्शन इसके कोर पर एक दूरस्थ मशीन के लिए एक निम्न स्तरीय सॉकेट कनेक्शन है। प्रक्रियाओं के बीच सॉकेट (आसानी से) साझा नहीं किया जा सकता है। इसलिए कई प्रक्रियाओं पर चलने वाली चीजें एक ही एसएसएच कनेक्शन साझा नहीं कर सकती हैं।

अगला आपको यह जानने की आवश्यकता है कि आपके वर्तमान सेटअप में कौन से हिस्से अलग प्रक्रियाओं में चल रहे हैं। हमें क्या मिलता है:

1. रेल अधिकांश मामलों में प्रक्रिया-आधारित है: अलग-अलग प्रक्रियाएं अलग-अलग प्रक्रियाओं पर चलती हैं। तो रेल ऐप में एसएसएच कनेक्शन भंडारण एक विश्वसनीय समाधान नहीं है।

2. देरी नौकरी, जहां तक ​​मुझे पता है, प्रक्रिया-आधारित भी है। एक मास्टर प्रक्रिया प्रत्येक नौकरी को संभालने के लिए दास प्रक्रियाओं को लॉन्च करती है। इसलिए डीजे इस उद्देश्य के लिए भी काम नहीं करता है।

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

व्यक्तिगत रूप से मैं सिर्फ एक साधारण थ्रेडेड रूबी डिमन प्रक्रिया को कोड करता हूं जो इस कार्य को संभालता है। यदि आप सीधे सॉकेट प्रोग्रामिंग से निपटना नहीं चाहते हैं तो आप संचार और प्रसंस्करण को संभालने के लिए EventMachine जैसे कुछ का उपयोग कर सकते हैं।

आप EventMachine या सॉकेट प्रोग्रामिंग के साथ सहज नहीं हैं, तो आप कुछ संदेश प्रणाली पर RabbitMQ, या ZeroMQ की तरह लग रही के साथ अपने क्लाइंट और सर्वर बनाने के लिए कर सकता है।

मुझे ActiveMessaging नामक रेल के लिए कुछ भी मिला, हालांकि मुझे यकीन नहीं है कि यह प्रोजेक्ट वर्तमान और कैसे काम कर रहा है।

लेकिन जैसा कि मैंने कहा, मुझे लगता है कि सबसे सरल कार्यान्वयन सिर्फ एक सॉकेट डिमन प्रक्रिया है जो पृष्ठभूमि में चलता है और खुले एसएसएच कनेक्शन का ट्रैक रखता है, और उसके बाद आपके रेल ऐप से कमांड सुनता है।

अगर आप इस तरह कुछ लागू करते हैं तो भी सुरक्षा विचारों को ध्यान में रखना याद रखें। अन्यथा आप अपने डेमॉन प्रक्रिया के माध्यम से आसानी से किसी भी एसएसएच को अपनी सभी दूरस्थ मशीनों तक पहुंच सकते हैं।

संपादित

एक भी सरल विचार:

बस एक डेमॉन प्रक्रिया समय-समय पर अपने रेल app से एक डेटाबेस तालिका से आदेश को पढ़ने के लिए है। फिर यह डिमन इन आदेशों को इस "नौकरी कतार" तालिका में जो भी पाता है उसके आधार पर निष्पादित कर सकता है। इस तरह से आपको सॉकेट संचार से निपटने की ज़रूरत नहीं है, इस समाधान के साथ कि यह समाधान एक मतदान समाधान है।