मिलियन पीपीएस प्रति सेकंड - कनेक्टिविटी और बैलेंस

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

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



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

कनेक्टिविटी आरक्षण

जिस परियोजना में मैं शामिल हूं, वह बहुत महत्वपूर्ण है यहां तक ​​कि ग्लिट्स भी। यदि आप RPS 400+ टॉप रनेट प्रोजेक्ट्स को सारांशित करते हैं: यांडेक्स, मेल, रामबलर, पोस्टर, ऑटो, आदि, तो हमारे कुल आरपीएस प्राप्त करें। कुछ बिंदु पर, यह स्पष्ट हो गया कि यदि आप आगे सभी अंडे एक टोकरी (डीसी) में रखते हैं, तो आप बहुत अच्छी तरह से और खूबसूरती से गिर सकते हैं। अगर आपको मास्को में चुबाइस के कश याद हैं - तो आप मुझे समझ सकते हैं। हमने एक सर्वर फ़ार्म को कई DC में फैलाने के मुद्दे का अध्ययन करना शुरू किया। मुख्य सवाल सर्वर को कई डीसी में नहीं फैलाना है जो एक ही रीढ़ से जुड़े नहीं हैं, लेकिन क्लाइंट के लिए एक डीसी से दूसरे में ट्रैफ़िक को जल्दी और मूल रूप से स्विच करना है।



मैं तुरंत ही आरक्षण कर दूंगा: हमारे द्वारा चुना गया कार्यान्वयन तभी संभव है जब हमारे पास अपना न्यूनतम / 23 मास्क हो, आधिकारिक तौर पर RIPE में 2 नेटवर्क में / 24 से कट जाए। ईमानदारी से, मुझे नहीं पता कि यह इस समय कैसे है, लेकिन इससे पहले कि एक ही TTK नेटवर्क के लिए पारगमन पर घोषणाओं के साथ समस्याएं थीं / 24 से कम। हमने उचित हार्डवेयर और EXIST-MAP, NON-EXIST-MAP के साथ काम करने की क्षमता वाले राउटर के रूप में सिस्को एएसआर 1001 को चुना। 2x डीसी के एक उदाहरण पर विचार करें। 2 एएसआर सुरंग को सिर्फ यह जानने के लिए रखते हैं कि दोनों डीसी की कनेक्टिविटी जीवित है। एक डीसी से हम एक वर्ग सी नेटवर्क की घोषणा करते हैं, दूसरे डीसी से - दूसरा नेटवर्क। जैसे ही हम दूसरे डीसी से देखते हैं कि कनेक्टिविटी टूट गई है, हम पहले डीसी से दूसरे नेटवर्क / 24 की घोषणा करने के लिए NON-EXIST-MAP का उपयोग करना शुरू करते हैं। डीसी को भौगोलिक रूप से वितरित करना उचित है - लेकिन यह बजट और रंग पर है।

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

मार्ग परिवर्तन का परीक्षण करते समय, हम एक अप्रिय स्थिति में आ गए: कई के पास अपनी पहुंच के लिए जुनिपर है । अब मैं समझाऊंगा कि यह अप्रिय क्यों है। डिफ़ॉल्ट रूप से, हर 3 मिनट में एक बार मार्ग बदलने की घोषणा की जाती है। हमारे लिए, यह सैकड़ों गीगाबाइट डेटा का नुकसान है। हमने घोषणाओं के समय को कम करने के साथ प्रयोग करना शुरू किया - 20 सेकंड तक सब कुछ ठीक था: घोषणाएं हमारे विशाल मातृभूमि के विभिन्न हिस्सों से पूरी तरह से और तेजी से बढ़ीं, लेकिन इस पैरामीटर को कम करने के बाद हमने डीसी में से एक को खो दिया। जैसा कि यह पता चला, जुनिपर, जिसने 20 सेकंड से कम समय तक एक अपलिंक की सेवा की, को बाढ़ माना जाता है और इसे कम करना संभव नहीं है, ये फर्मवेयर की विशेषताएं हैं। नीचे पंक्ति: 21 सेकंड सबसे इष्टतम पैरामीटर है।

So. वह सब है। 2 डीसी के लिए विफलता, हमने परीक्षण किया - यह काम करता है। रूस में मार्गों को बदलने का वास्तविक समय दूरी और पारगमन के आधार पर 25 से 60 सेकंड तक है। इस स्तर पर, हमारे पास राउटर के साथ 2 नंगे डीसी हैं। चलो दोनों डीसी में भरना शुरू करते हैं।

डीसी के अंदर निरर्थक स्विचिंग



यहाँ मैं संक्षेप में बताऊंगा - DC के अंदर स्विचिंग 2 द्वारा 2: 2 बॉन्ड में होती है, जो वास्तविक आईपी एड्रेस पर काम करता है, वीलन में अलग-अलग स्विचेस में बॉन्ड को देखता है, बॉन्ड में 2 फिजिकल इंटरफेस, वीलन सर्विंग बैकएंड में अलग-अलग स्विच को देखता है। हमने सबसे सरल मोड बॉन्डिंग मोड = 1 को चुना - असफल होने के लिए, हमने बस विभिन्न स्विचों पर बॉन्डिंग के शून्य भागों को बिखेर दिया। सामान्य तौर पर, सरल और अधिक विश्वसनीय । आगे और पीछे भाग लेने वाले प्रत्येक सर्वर पर - 4 भौतिक इंटरफेस। आंकड़ा केवल सामने दिखाता है। स्विच न केवल 10 जी से जुड़े हैं, बल्कि एक बैकअप पावर केबल से भी जुड़े हैं और विभिन्न यूपीएस से जुड़े हैं। मोड = 1 को स्विच के विशेष कॉन्फ़िगरेशन की आवश्यकता नहीं है, जो पूरे बुनियादी ढांचे के प्रबंधन को सरल करता है।

संतुलन



वास्तव में, कोई विशेष विकल्प नहीं थे, आईपीवीएस को डीआर (डायरेक्ट रूटिंग) मोड में चुना गया था। जैसा कि मैंने ऊपर कहा, यह संतुलन विधि कम खर्चीली है। यह नैट की तरह दोनों दिशाओं में डंपिंग कनेक्शन के आकर्षण से वंचित करता है, लेकिन इसके लिए कम संसाधनों की आवश्यकता होती है। नोटरी प्रेमी कहेंगे - ऐसा करना बेहतर नहीं है यदि आपके लिए 100% कनेक्शन रखना महत्वपूर्ण है। आईपीवीएस सेंटोस में मानक है और स्थापना के दौरान विशेष shamanism की आवश्यकता नहीं है। एकमात्र बारीकियों का जो हमने सामना किया - डिफ़ॉल्ट रूप से, आईपीवीएस एक साथ 4096 कनेक्शनों को स्वीकार करने के लिए तैयार है - यह 12 बिट्स है।



एक लाख कनेक्शन को स्वीकार करने के लिए तैयार होने के लिए बैलेंसर के लिए, इस पैरामीटर को 20 बिट तक बढ़ाने की आवश्यकता है। मॉड्यूल प्रबंधन (modprobe.d) में विकल्पों के माध्यम से ऐसा करना संभव नहीं था - ipvsadm ने भी लगातार जोर दिया कि यह 4096 कनेक्शनों की सेवा के लिए तैयार था। मुझे अपने पेन को src में चलाना और मॉड्यूल को फिर से बनाना था। एक छोटी परियोजना के लिए यह इतना महत्वपूर्ण नहीं है, लेकिन यदि आप सैकड़ों हजारों और उच्चतर कनेक्शनों की सेवा करते हैं, तो यह महत्वपूर्ण है।

संतुलन के कई तरीके हैं। सबसे सरल एक - आरआर (राउंड रॉबिन) - आने वाले कनेक्शन को "एक सर्कल में" रियल सर्वर पर भेजें। लेकिन हमने डब्ल्यूएलसी प्रकार को चुना - कनेक्शन नियंत्रण के साथ संतुलित संतुलन। यदि हम रियल सर्वर पर nginx में रखने वाले पैरामीटर के साथ बैलेंसर पर दृढ़ता पैरामीटर को सिंक्रनाइज़ करते हैं, तो हमें कनेक्शन में सद्भाव मिलेगा। उदाहरण के लिए, यदि बैलेंसर पर दृढ़ता 90 सेकंड है, और रियल पर नेग्नेक्स पर रखवाली 120 है, तो हमें निम्नलिखित स्थिति मिलती है: 90 सेकंड के बाद बैलेंसर सभी क्लाइंट को दूसरे रियल में कनेक्शन देगा, और पुराना रियल अभी भी क्लाइंट कनेक्शन रखेगा। अगर हम इस बात को ध्यान में रखते हैं कि 10 हजार ESTABLISHED कनेक्शन के लिए 30 सेकंड की रखवाली के साथ, हमारे पास लगभग 120 हजार TIME_WAIT हैं (यह पूरी तरह से सामान्य है, इगोर सियोसेव और मैंने ईमेल टेक्नोफोरम के किनारे पर विचार किया है, तो यह काफी महत्वपूर्ण है।

अब, संतुलन तकनीक के अनुसार, यह कैसे काम करता है: डोमेन के लिए DNS में हमने जो आईपी पता दर्ज किया है, वह बैलेंसर के बाहरी भौतिक इंटरफ़ेस और रियल सर्वर के लूपबैक के उपनामों पर प्रसारित होता है। नीचे sysctl रियल सर्वर के कॉन्फ़िगरेशन का एक उदाहरण है - वहां आपको arp घोषणाओं को कवर करने की आवश्यकता है और, यदि वांछित है, तो स्रोत रूटिंग, ताकि स्विचिंग आईपी को डुप्लिकेट करने से पागल न हो। मैं पूरे sysctl का वर्णन नहीं करूंगा - यह प्रत्येक परियोजना के लिए पर्याप्त विशिष्ट है - मैं केवल डीआर बारीकियों के लिए आवश्यक पैरामीटर दिखाऊंगा।

बैलेंसरों के लिए:

# Fast port recycling (TIME_WAIT) net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 1 # Local port range maximized net.ipv4.ip_local_port_range = 1024 65535 # Dont allow LB send icmp redirects on local route net.ipv4.conf.eth1.send_redirects = 0 net.ipv4.conf.eth0.send_redirects = 0 net.ipv4.conf.lo.send_redirects = 0 # Dont allow LB to accept icmp redirects on local route net.ipv4.conf.eth1.accept_redirects = 0 net.ipv4.conf.eth0.accept_redirects = 0 net.ipv4.conf.lo.accept_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.accept_redirects = 0 # Do not accept source routing net.ipv4.conf.default.accept_source_route = 0 # Ignore ARP net.ipv4.conf.eth0.arp_ignore = 1 net.ipv4.conf.eth1.arp_ignore = 1 net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.default.arp_ignore = 1 

असली सर्वरों के लिए:

 # sysctl.conf net.ipv4.conf.bond0.arp_ignore = 1 net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.default.arp_ignore = 1 

255.255.255.255 के मास्क के साथ रियल सर्वर पर वास्तविक आईपी के साथ एक उपनाम लूपबैक के लिए राउटर को आपके नेटवर्क की सेवा करने वाले राउटर के आईपी पर पंजीकृत होना चाहिए और इसे बाहर की घोषणा करनी चाहिए, अन्यथा, संतुलन के लिए अनुरोध आएंगे, लेकिन रियल जवाब नहीं देगा। कुछ iproute2 और VIP तालिकाओं के साथ स्मार्ट हैं, लेकिन यह कॉन्फ़िगरेशन को जटिल करता है।

अब गलती सहिष्णुता संतुलन और रियल के बारे में। Keepalived को काफी तार्किक रूप से चुना गया था - IPVS डेवलपर्स स्वयं अपने उत्पाद के साथ संयोजन में इसका उपयोग करने की सलाह देते हैं। नियमित योजना - मास्टर + एसएलएवाई 99% परियोजनाओं के लिए उपयुक्त है, लेकिन यह हमें सूट नहीं करता है, क्योंकि इस समय एक डीसी में 5 बैलेंसर हैं, दूसरे में 3. एक ब्लेड की औसत लागत 120-140 हजार है, इसलिए हमने थोड़ा बचाने का फैसला किया। यदि आप ध्यान से रखे गए विन्यास अनुभाग को देखते हैं जहाँ समूहों का वर्णन किया गया है, तो यह स्पष्ट हो जाएगा कि यदि आप 2 स्वामी पर अलग-अलग समूह सेट करते हैं और दोनों समूहों का 1 मी दास पर वर्णन करते हैं, तो 1 दास योजना के अनुसार 2 स्वामी के लिए काम करेगा, 1 मास्टर बाहर गिर गया, गुलाम ने अपना IP उठाया, लेकिन अगर दूसरा गिर गया, तो दूसरा IP उसी गुलाम द्वारा उठाया जाता है। बेशक, एक माइनस है, जब दोनों स्वामी बाहर निकलते हैं, एक डबल लोड गुलाम पर गिर जाएगा, लेकिन बैलेंसर के लिए यह रियल के विपरीत बहुत महत्वपूर्ण नहीं है।

और एक और छोटी चाल: CHECK रियल सर्वर को कॉन्फाल्ड कॉन्फिग में दिया गया है। यह सरल टीसीपी हो सकता है, यह 200 वीं प्रतिक्रिया को नियंत्रित करने के लिए एक HTTP पृष्ठ को खींच सकता है, लेकिन MISC_CHECK है। टुकड़ा सुविधाजनक और कार्यात्मक है। यदि आप रियल सर्वर पर एक छोटी सी स्क्रिप्ट डालते हैं, तो इससे कोई फर्क नहीं पड़ता कि क्या लिखा गया है, जो आपके तर्क के अनुसार, वर्तमान एलए की गणना करेगा और बैलेंसरों के लिए रियल सर्वर के गतिशील वजन को उत्पन्न करेगा, फिर बैलेंसर पर MISC_AMAMAMIC पैरामीटर का उपयोग करने से आपको वास्तविक वजन में एक गतिशील परिवर्तन प्राप्त होगा।

तैनाती

थोड़ा तैनाती के बारे में। तैनाती सर्वर परिनियोजन का स्वचालन है। यदि आपके पास 2-3-4 सर्वर हैं, तो निश्चित रूप से आपने स्वचालन को तैनात नहीं किया है, लेकिन यदि आपके पास दर्जनों या सैकड़ों हैं, तो यह निश्चित रूप से इसके लायक है, खासकर यदि सर्वर समान कार्यों द्वारा समूहीकृत हैं।
मेरे सामने केवल 2 समूह हैं - ये नंगेक्स के साथ बैलेंसर्स और रियल सर्वर हैं, जो वास्तव में उपयोगकर्ता को सामग्री वितरित करते हैं।

 # file top.sls base: '*': - ssh - nginx - etc 'ccs*': - ccs 'lb*': - lbs 

कई तैनाती प्रणालियां हैं - कठपुतली, प्रमुख ... लेकिन हमने नमक (saltstack.org) को चुना। यह कैसे काम करता है: कॉन्फ़िगरेशन में नमक सर्वर पर, आप सर्वर समूह बनाते हैं और प्रत्येक समूह के लिए आप परिनियोजन योजना चित्रित करते हैं - इसमें सिस्टम उपयोगकर्ता और समूह शामिल होते हैं जो सेवाओं को कार्य करने के लिए आवश्यक होते हैं, कॉन्फ़िगरेशन फ़ाइलें जो सभी सर्वरों पर होनी चाहिए, स्थापित सॉफ़्टवेयर ...

 # file /srv/salt/etc/init.sls /etc/hosts: file: - managed - source: salt://files/hosts /etc/selinux/config: file: - managed - source: salt://files/selinux.config /etc/snmp/snmpd.conf: file: - managed - source: salt://files/snmpd.conf 

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

यह रिपोर्ट का केवल एक हिस्सा है। समय निकालना सुनिश्चित करें और एक वेब फ़ार्म के परीक्षण के तरीकों पर एक अलग लेख लिखें, बिना बूंदों और रेट्रॉन्समिट के नगेंक्स के अधिकतम "निचोड़", सिंथेटिक और उत्पादन परीक्षणों के बीच अंतर।

हाई लोड में गुड लक!