📞 🦌 🚹 भार के तहत कठपुतली 🤘🏼 👨🏽‍🚒 🚱

कठपुतली एक काफी सुविधाजनक विन्यास प्रबंधन उपकरण है। वास्तव में, यह एक प्रणाली है जो आपको मशीनों और सेवाओं के बड़े बेड़े के कॉन्फ़िगरेशन और प्रबंधन को स्वचालित करने की अनुमति देती है।

सिस्टम के बारे में बहुत सारी बुनियादी जानकारी है, जिसमें हैबे भी शामिल है: यहां , यहां और यहां । हमने प्यूपेट का उपयोग करने के लिए एक लेख में कई "व्यंजनों" को इकट्ठा करने की कोशिश की, जो कि वास्तव में भारी भार के तहत हैं - जो कि "शर्त स्थितियों" में हैं।

क्या चर्चा होगी:

कठपुतली: शैक्षिक कार्यक्रम;
क्लस्टरिंग, स्केलिंग;
अतुल्यकालिक Storeconfigs;
रिपोर्ट का संग्रह;
डेटा का विश्लेषण।

तुरंत आरक्षण करें कि यह लेख हाईलाड ++ 2012 सम्मेलन में एंटोन ट्यूरेत्स्की की रिपोर्ट के मद्देनजर लिखा गया था। कुछ दिनों में, हमारे "व्यंजनों" को अतिरिक्त विवरण और उदाहरणों के साथ उखाड़ फेंका गया।

भार में लौटते हुए, यह ध्यान दिया जाना चाहिए कि Badoo में वे वास्तव में उच्च हैं:

2000 से अधिक सर्वर;
मैनिफ़ेस्ट में 30,000 से अधिक लाइनें (अंग्रेजी प्रकट , इस मामले में, प्रबंधन सर्वर के लिए कॉन्फ़िगरेशन फ़ाइल);
200 से अधिक सर्वर जो हर 3 मिनट में कठपुतली मास्टर कॉन्फ़िगरेशन का अनुरोध करते हैं;
एक ही समय अवधि में रिपोर्ट भेजने वाले 200 से अधिक सर्वर।

यह कैसे काम करता है

कठपुतली स्वयं एक क्लाइंट-सर्वर अनुप्रयोग है। कठपुतली के मामले में, ग्राहक कनेक्शन शुरू करता है; इस स्थिति में, यह नोड (संलग्न नोड ) है जिस पर आप कॉन्फ़िगरेशन को तैनात करना चाहते हैं।

चरण 1: विन्यास के बदले में तथ्य

ग्राहक खुद के बारे में तथ्य एकत्रित करता है, पपेट एप्लिकेशन की अंतर्निहित निर्भरता, उपयोगिता उपयोगिता का उपयोग करता है, फिर उन्हें सर्वर पर सामान्य HTTP पोस्ट अनुरोध के साथ भेजता है और उनकी प्रतिक्रिया की प्रतीक्षा करता है।

चरण 2: प्रसंस्करण और प्रतिक्रिया

सर्वर क्लाइंट से एक डंप प्राप्त करता है और कैटलॉग को संकलित करता है। उसी समय, यह सर्वर पर उपलब्ध प्रकट में सूचना से आगे बढ़ता है, लेकिन ग्राहक से प्राप्त तथ्यों को भी ध्यान में रखता है। क्लाइंट को कैटलॉग भेजा जाता है।

चरण 3: कैटलॉग को लागू करना और परिणामों की रिपोर्ट करना

सर्वर से डायरेक्टरी प्राप्त करने के बाद, क्लाइंट सिस्टम में बदलाव करता है। निष्पादन के परिणाम HTTP POST अनुरोध का उपयोग कर सर्वर को सूचित किए जाते हैं।

चरण 4: रिपोर्ट एकत्र करना और संग्रहीत करना

क्लाइंट द्वारा सभी नियमों को पूरा करने के बाद, रिपोर्ट को सहेजा जाना चाहिए। कठपुतली इसके लिए अपने स्वयं के विकास और तीसरे पक्ष के कलेक्टरों दोनों का उपयोग करने का सुझाव देती है। हम कोशिश करते हैं!

आधार पैकेज स्थापित करें और निम्न चित्र प्राप्त करें:

पहली नज़र में, सब कुछ ठीक है - सेट और काम। हालांकि, समय के साथ, तस्वीर कम हर्षित हो जाती है। क्लाइंट की संख्या बढ़ जाती है, सिस्टम एडमिनिस्ट्रेटर मैनिफ़ेस्टोस लिखते हैं, जिसके परिणामस्वरूप कोड को संकलित करने और प्रत्येक क्लाइंट को संसाधित करने में लगने वाला समय बढ़ता है।

और एक निश्चित क्षण में तस्वीर बहुत उदास हो जाती है।

पहली बात जो मन में आती है वह है सर्वर पर कठपुतली मास्टर प्रक्रियाओं की संख्या बढ़ाना। हां, ठीक है क्योंकि कठपुतली को पता नहीं है कि यह मूल पैकेज में कैसे किया जाता है, और यह गुठली को "धब्बा" नहीं करता है।

क्या निर्माता द्वारा प्रस्तावित कोई समाधान है? बेशक, लेकिन विभिन्न कारणों से, वे हमारी शर्तों में लागू नहीं थे।

अपाचे + mod_passenger क्यों नहीं? कुछ कारणों से, हमारी कंपनी Apache वेब सर्वर का उपयोग बिल्कुल नहीं करती है।

Nginx + यात्री क्यों नहीं? हम उपयोग करने वाले nginx असेंबली में एक अतिरिक्त मॉड्यूल की आवश्यकता से बचने के लिए।

फिर क्या?

गेंडा से मिलें

यूनिकॉर्न क्यों?

यहाँ, हमारी राय में, इसके फायदे:

लिनक्स कर्नेल स्तर संतुलन
उनके वातावरण में सभी प्रक्रियाओं को शुरू करना;
नंगेक्स-शैली कनेक्शन के नुकसान के बिना अपडेट;
कई इंटरफेस पर सुनने की क्षमता;
PHP-FPM के साथ समानताएं, लेकिन रूबी के लिए।

यूनिकॉर्न चुनने का एक और कारण स्थापना और कॉन्फ़िगरेशन में आसानी थी।

worker_processes 12 working_directory "/etc/puppet" listen '0.0.0.0:3000', :backlog => 512 preload_app true timeout 120 pid "/var/run/puppet/puppetmaster_unicorn.pid" if GC.respond_to?(:copy_on_write_friendly=) GC.copy_on_write_friendly = true end before_fork do |server, worker| old_pid = "#{server.config[:pid]}.oldbin" if File.exists?(old_pid) && server.pid != old_pid begin Process.kill("QUIT", File.read(old_pid).to_i) rescue Errno::ENOENT, Errno::ESRCH end end end

तो अच्छी खबर: हम कई प्रक्रियाओं को चलाने की क्षमता रखते हैं। लेकिन एक बुरा एक है: प्रक्रियाओं का प्रबंधन करना अधिक कठिन हो गया है। डरावना नहीं है - इस स्थिति के लिए एक "नुस्खा" है।

"गॉड वी ट्रस्ट"

ईश्वर एक प्रक्रिया निगरानी ढांचा है। यह स्थापित करना आसान है और रूबी में पपेट की तरह ही लिखा गया है।

हमारे मामले में, भगवान विभिन्न कठपुतली मास्टर प्रक्रिया का प्रबंधन करते हैं:

उत्पादन का वातावरण;
पर्यावरण का परीक्षण;
कठपुतली सीए।

अनुकूलन के साथ कोई विशेष समस्याएँ नहीं हैं। यह * .god फ़ाइलों को संसाधित करने के लिए निर्देशिका / etc / god / में एक कॉन्फ़िगरेशन फ़ाइल बनाने के लिए पर्याप्त है।

 God.watch do |w| w.name = "puppetmaster" w.interval = 30.seconds w.pid_file = "/var/run/puppet/puppetmaster_unicorn.pid" w.start = "cd /etc/puppet && /usr/bin/unicorn -c /etc/puppet/unicorn.conf -D" w.stop = "kill -QUIT `cat #{w.pid_file}`" w.restart = "kill -USR2 `cat #{w.pid_file}`" w.start_grace = 10.seconds w.restart_grace = 10.seconds w.uid = "puppet" w.gid = "puppet" w.behavior(:clean_pid_file) w.start_if do |start| start.condition(:process_running) do |c| c.interval = 5.seconds c.running = false end end end

कृपया ध्यान दें कि हमने अलग उदाहरण में कठपुतली सीए को आवंटित किया है। यह विशेष रूप से किया जाता है ताकि सभी ग्राहक अपने प्रमाणपत्रों को सत्यापित करने और प्राप्त करने के लिए एक ही स्रोत का उपयोग करें। थोड़ी देर बाद हम आपको बताएंगे कि इसे कैसे प्राप्त किया जाए।

संतुलन

जैसा कि पहले ही उल्लेख किया गया है, क्लाइंट और सर्वर के बीच सूचनाओं के आदान-प्रदान की पूरी प्रक्रिया HTTP के माध्यम से होती है, जिसका अर्थ है कि कुछ भी हमें सरल HTTP-संतुलन स्थापित करने से रोकता नहीं है, nginx का सहारा ले रहा है।

अपस्ट्रीम बनाएं:

 upstream puppetmaster_unicorn { server 127.0.0.1:3000 fail_timeout=0; server server2:3000 fail_timeout=0; } #    puppet master ( , production-) upstream puppetca { server 127.0.0.1:3000 fail_timeout=0; } #  Puppet CA

हम प्राप्तकर्ताओं के अनुरोधों को पुनर्निर्देशित करते हैं:

कठपुतली सीए

 location ^~ /production/certificate/ca { proxy_pass http://puppetca; } location ^~ /production/certificate { proxy_pass http://puppetca; } location ^~ /production/certificate_revocation_list/ca { proxy_pass http://puppetca; }

कठपुतली गुरु

 location / { proxy_pass http://puppetmaster_unicorn; proxy_redirect off; }

अंतरिम परिणामों को संक्षेप में प्रस्तुत करना। इसलिए, उपरोक्त क्रियाएं हमें अनुमति देती हैं:

कई प्रक्रियाएं चलाएं;
प्रक्रियाओं के प्रक्षेपण का प्रबंधन;
लोड को संतुलित करें।

स्केलिंग के बारे में क्या?

कठपुतली मास्टर सर्वर की तकनीकी क्षमताएं असीमित नहीं हैं, और यदि इस पर लोड अत्यंत अनुमत हो जाता है, तो स्केलर का सवाल उठता है।

इस समस्या को निम्नानुसार हल किया गया है:

हमारे कठपुतली सर्वर के लिए RPM पैकेज हमारे भंडार में संग्रहीत किया जाता है;
सभी अभिव्यक्तियाँ, साथ ही ईश्वर और यूनिकॉर्न के लिए विन्यास, हमारे गिट भंडार में हैं।

दूसरा सर्वर शुरू करने के लिए, हमें केवल:

आधार प्रणाली रखो;
कठपुतली-सर्वर, यूनिकॉर्न, भगवान स्थापित करें;
क्लोन गैट भंडार;
मशीन को अपस्ट्रीम में जोड़ें।

हमारी "ट्यूनिंग" वहाँ समाप्त नहीं होती है, इसलिए फिर से सिद्धांत पर वापस आती है।

Storeconfigs: क्या और क्यों?

यदि कोई ग्राहक हमें अपने बारे में एक रिपोर्ट और तथ्य भेजता है, तो इस जानकारी को संग्रहीत क्यों नहीं किया जाता है?

यह हमें Storeconfigs - कठपुतली-सर्वर विकल्प में मदद करेगा, जो आपको डेटाबेस में प्रासंगिक ग्राहक जानकारी को बचाने की अनुमति देता है। सिस्टम क्लाइंट से नवीनतम डेटा की तुलना मौजूदा डेटा से करता है। Storeconfigs निम्नलिखित रिपॉजिटरी का समर्थन करता है: SQLite, MySQL, PostgreSQL। हम MySQL का उपयोग करते हैं।

हमारे मामले में, कई ग्राहक प्रत्येक तीन मिनट में कॉन्फ़िगरेशन उठाते हैं, लगभग उसी रिपोर्ट को भेजा जाता है। परिणामस्वरूप, हमें MySQL पर लिखने के लिए पहले से ही बड़ी कतारें मिल जाती हैं। लेकिन हमें अभी भी डेटाबेस से डेटा लेना है।

इस समस्या को निम्नलिखित समाधान मिला:

Apache ActiveMQ का उपयोग करने से हमें क्लाइंट से संदेश सीधे डेटाबेस में नहीं भेजने की अनुमति मिलती है, बल्कि संदेश कतार के माध्यम से उन्हें पास करने की अनुमति मिलती है।

परिणामस्वरूप, हमारे पास:

क्लाइंट पर कठपुतली-प्रक्रिया का तेजी से निष्पादन, क्योंकि जब आप सर्वर को एक रिपोर्ट भेजने की कोशिश करते हैं, तो यह तुरंत "ओके" हो जाता है (कतार में एक संदेश डालना डेटाबेस से इसे लिखने की तुलना में आसान है);
MySQL पर लोड को कम करना (कठपुतली कतार प्रक्रिया डेटाबेस पर एसिंक्रोनस रूप से डेटा लिखती है)।

कठपुतली-सर्वर को कॉन्फ़िगर करने के लिए, विन्यास में निम्नलिखित पंक्तियों को जोड़ना आवश्यक था:

 [main] async_storeconfigs = true queue_type = stomp queue_source = stomp://ACTIVEMQ_address:61613 dbadapter = mysql dbuser = secretuser dbpassword = secretpassword dbserver = mysql-server

और कठपुतली कतार प्रक्रिया शुरू करने के बारे में मत भूलना।

वर्णित सेटिंग्स के लिए धन्यवाद, कठपुतली स्मार्ट और अच्छी तरह से सर्वर पर काम करती है, लेकिन नियमित रूप से इसकी गतिविधि की निगरानी करना अच्छा होगा। यह पपेट रिपोर्ट के बारे में सोचने का समय है।

अमानक रिपोर्टिंग

हमें डिफ़ॉल्ट रूप से क्या प्रदान किया जाता है:

http;
tagmai;
लॉग इन करने
rrdgraph;
दुकान।

काश, विकल्पों में से कोई भी हमें एक ही कारण से पूरी तरह से और पूरी तरह से अनुकूल नहीं करता - उच्च गुणवत्ता वाले दृश्य घटक की कमी। दुर्भाग्य से, या शायद सौभाग्य से, उस समय मानक कठपुतली डैशबोर्ड हमें बहुत उबाऊ लग रहा था।

इसलिए, हमने फोरमैन का विकल्प चुना, जिसने हमें सबसे आवश्यक के साथ अच्छे आरेखों से प्रसन्न किया।

बाईं ओर की तस्वीर में, हम देखते हैं कि प्रत्येक प्रकार के संसाधन का उपयोग करने में कितना समय लगता है। 360 डिग्री के लिए, क्लाइंट पर पूर्ण निष्पादन समय लिया जाता है।

दाईं ओर की तस्वीर स्थिति के साथ घटनाओं की संख्या प्रदर्शित करती है। इस उदाहरण में, केवल एक सेवा शुरू की गई थी, इस तथ्य के कारण 10 से अधिक घटनाओं को छोड़ दिया गया था कि उनकी वर्तमान स्थिति पूरी तरह से संदर्भ एक से मेल खाती है।

और अंतिम सिफारिश: संस्करण 3.0.0 में अपग्रेड करें

अपडेट के बाद ग्राफ स्पष्ट रूप से समय का लाभ दिखाता है। सही है, डेवलपर्स ने वादा किया था कि उत्पादकता में 50% की वृद्धि नहीं हुई है, लेकिन वृद्धि काफी ध्यान देने योग्य थी। घोषणा पत्र ( संदेश देखें) को संपादित करने के बाद, हमने अभी भी वादा किया 50% हासिल किया है, इसलिए हमारे प्रयासों ने पूरी तरह से भुगतान किया।

अंत में, हम कह सकते हैं कि उचित विन्यास के साथ, कठपुतली गंभीर भार से निपटने में सक्षम है और 2000 सर्वरों के लिए विन्यास प्रबंधन इसकी पहुंच के भीतर काफी है।

एंटोन [ बनूक्का ] तुर्की, सिस्टम प्रशासक
badoo

भार के तहत कठपुतली