उच्च लोड के तहत ठीक धुन ओपनस्टैक

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

कोर पर भार: यह था

नेट

कुछ उदाहरणों में हम ड्यूलस्टैक का उपयोग करते हैं। यह तब होता है जब वर्चुअल मशीन एक ही बार में दो पते प्राप्त करती है - IPv4 और IPv6। सबसे पहले, हमने यह सुनिश्चित किया कि "फ्लोटिंग" v4 एड्रेस को NAT के माध्यम से आंतरिक नेटवर्क में असाइन किया गया था, और मशीन को BGP के माध्यम से v6 प्राप्त हुआ, लेकिन इसके साथ कुछ समस्याएं हैं।

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

फिर भी NAT परियोजनाओं के बीच पहुंच को सामान्य बनाने की अनुमति नहीं देता है। सभी परियोजनाओं के अपने-अपने सबनेट हैं, फ्लोटिंग आईपी लगातार पलायन करते हैं, और एनएटी के साथ इसे प्रबंधित करना बिल्कुल असंभव हो जाता है। कुछ स्थापनाएं NAT 1 में 1 का उपयोग करने के बारे में बात करती हैं (आंतरिक पता बाहरी से अलग नहीं होता है), लेकिन यह अभी भी बाहरी सेवाओं के साथ बातचीत की श्रृंखला में अनावश्यक लिंक छोड़ता है। हम इस निष्कर्ष पर पहुंचे कि हमारे लिए सबसे अच्छा विकल्प बीजीपी नेटवर्क है।

बेहतर सरल है

हमने विभिन्न स्वचालन साधनों की कोशिश की, लेकिन Ansible पर बस गए। यह एक अच्छा उपकरण है, लेकिन इसकी मानक कार्यक्षमता (यहां तक ​​कि अतिरिक्त मॉड्यूल को ध्यान में रखते हुए) कुछ कठिन परिस्थितियों में पर्याप्त नहीं हो सकती है।

उदाहरण के लिए, Ansible मॉड्यूल के माध्यम से, आप निर्दिष्ट नहीं कर सकते हैं कि किस सबनेट पते को आवंटित किया जाना है। यही है, आप एक नेटवर्क निर्दिष्ट कर सकते हैं, लेकिन आप एक विशिष्ट पता पूल सेट नहीं कर सकते। फ्लोटिंग IP बनाने वाला शेल कमांड यहां मदद करेगा:

openstack floating ip create -c floating_ip_address -f value -project \ {{ project name }} —subnet private-v4 CLOUD_NET 

गुम कार्यक्षमता का एक और उदाहरण: ड्यूलस्टैक के कारण, हम v4 और v6 के लिए दो पोर्ट के साथ एक राउटर ठीक से नहीं बना सकते हैं यह वह जगह है जहाँ एक बैश स्क्रिप्ट काम आती है:

 #! /bin/bash # $1 - router_name # $2 - router_project # $3 - router_network # echo "${@:4}" - private subnet lists FIXED4_SUBNET="subnet-bgp-nexthop-v4" FIXED6_SUBNET="subnet-bgp-nexthop-v6" openstack --os-project-name $2 router show $1 if [ $? -eq 0 ] then echo "router is exist" exit 0 fi openstack --os-project-name $2 router create --project $2 $1 for subnet in "${@:4}"; do openstack --os-project-name $2 router add subnet $1 $subnet done openstack --os-project-name $2 router set $1 --external-gateway $3 --fixed-ip subnet=$FIXED4_SUBNET --fixed-ip subnet=$FIXED6_SUBNET 

स्क्रिप्ट राउटर बनाता है, इसमें v4 और v6 सबनेट जोड़ता है, और एक बाहरी गेटवे असाइन करता है।

पुन: प्रयास करें

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

ऊपर दिए गए सभी टिप्स वास्तव में टेराफॉर्म, पपेट, और कुछ और के साथ बहुत अच्छा काम करते हैं।

हर चीज की अपनी जगह है

कोई भी बड़ी सेवा (ओपनस्टैक कोई अपवाद नहीं है) कई छोटी सेवाओं को जोड़ती है जो एक-दूसरे के काम में हस्तक्षेप कर सकती हैं। यहाँ एक उदाहरण है।

नेटवर्क एजेंट न्यूट्रॉन-एल 2-एजेंट ओपनस्टैक में नेटवर्क कनेक्टिविटी के लिए जिम्मेदार है। यदि सभी अन्य एजेंट नियंत्रकों पर आंशिक रूप से हैं, तो एल 2, बारीकियों के कारण, हर जगह मौजूद है।

इसी तरह से हमारा बुनियादी ढांचा बहुत शुरुआत में देखा गया, जब तक कि योजनाओं की संख्या 50 से अधिक नहीं हो गई

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

नोड्स की गणना करने के लिए स्थानांतरित एजेंट

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

तीसरा पुनरावृति। चयनित नोड्स दिखाई दिए।

हमने नेटवर्क नोड्स को अलग करने के लिए एजेंटों को सोचा और स्थानांतरित किया। अब केवल वर्चुअल मशीन के लिए सेवाएं कंप्यूट नोड्स पर बनी हुई हैं, सभी एजेंट नेटवर्क नोड पर काम करते हैं, और केवल bgp एजेंट जो v6 नेटवर्क के साथ काम करते हैं, वे नियंत्रकों पर बने रहते हैं (क्योंकि एक bgp एजेंट केवल एक प्रकार के नेटवर्क की सेवा कर सकता है)। L2 हर जगह बना रहा, क्योंकि इसके बिना, जैसा कि हमने ऊपर लिखा है, नेटवर्क पर कोई कनेक्टिविटी नहीं होगी।

सब कुछ मिश्रित होने से पहले गणना नोड्स का लोड ग्राफ। यह लगभग 60% था, लेकिन भार बेहद कम हो गया

नेटवर्क एजेंटों से पहले सॉफ्टरैक पर लोड ने गणना नोड्स को हटा दिया। 3 कोर लोडेड रहे। उस समय, हमने सोचा कि यह सामान्य है

प्रलेखन के रूप में कोड

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

टाइमआउट के बारे में

एक बार जब हमने देखा कि न्यूट्रॉन ओपन वीस्विच को पांच सेकंड में फिट नहीं करते हैं और टाइमआउट में आते हैं।

 127.0.0.1:29696: no response to inactivity probe after 10 seconds, disconnecting neutron.agent.ovsdb.native.commands TimeoutException: Commands [DbSetCommand(table=Port, col_values=(('tag', 11),), record=qtoq69a81c6-e2)] exceeded timeout 5 seconds 

बेशक, हमने मान लिया था कि कहीं न कहीं यह तय है। हमने कॉन्फिग, डॉक्यूमेंटेशन और डिबेट पैकेज में देखा, लेकिन पहले तो उन्हें कुछ भी नहीं मिला। नतीजतन, खोज परिणामों के पांचवें पृष्ठ पर वांछित सेटिंग का विवरण मिला - हमने फिर से कोड को देखा और सही स्थान पाया। सेटिंग यह है:

 ovs_vsctl_timeout = 30 

हमने इसे 30 सेकंड के लिए सेट किया (यह 5 था), और सब कुछ थोड़ा बेहतर काम करना शुरू कर दिया।

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

 ovs-vsctl set Controller "br-int" inactivity_probe=30000 

नेटवर्क स्टैक सेटिंग्स के बारे में

हमें नेटवर्क स्टैक में आम तौर पर स्वीकृत सेटिंग्स से भी थोड़ा दूर जाना था, जिसका उपयोग हम अपने अन्य सर्वर पर करते हैं।

यहां ARP रिकॉर्ड को तालिका में संग्रहीत करने में कितना समय लगता है, इसकी सेटिंग यहां दी गई है:

 net.ipv4.neigh.default.base_reachable_time = 60 net.ipv4.neigh.default.gc_stale_time=60 

डिफ़ॉल्ट मान 1 दिन है। सामान्य तौर पर, एक योजना कुछ हफ्तों तक रह सकती है, लेकिन एक दिन के लिए, योजनाओं को 4-6 बार फिर से बनाया जा सकता है, जबकि मैक पते और आईपी पते का पत्राचार लगातार बदल रहा है। ताकि कचरा जमा न हो, हम एक मिनट का समय निर्धारित करते हैं।

 net.ipv4.conf.default.arp_notify = 1 net.nf_conntrack_max = 1000000 (default 262144) net.netfilter.nf_conntrack_max = 1000000 (default 262144) 

इसके अलावा, हमने नेटवर्क इंटरफ़ेस बढ़ाते समय ARP नोटिफिकेशन भेजने के लिए मजबूर किया। हमने कॉनट्रैक टेबल को भी बढ़ाया, क्योंकि NAT और फ्लोटिंग आईपी का उपयोग करते समय, हमारे पास डिफ़ॉल्ट मान नहीं था। एक मिलियन (262 144 में डिफ़ॉल्ट के साथ) तक बढ़ गया, सब कुछ और भी बेहतर हो गया।

हम खुले vSwitch के मैक तालिका के आकार को सही करते हैं:

 ovs-vsctl set bridge bt-int other-config:mac-table-size=50000 (default 2048) 

सभी सेटिंग्स के बाद, 40% लोड लगभग शून्य में बदल गया

RX-प्रवाह के हैश

सभी कतारों और प्रोसेसर थ्रेड्स के बीच udp ट्रैफ़िक के प्रसंस्करण को वितरित करने के लिए, हमने rx-flow-hash को शामिल किया। इंटेल नेटवर्क कार्ड पर, i40e ड्राइवर में, यह विकल्प डिफ़ॉल्ट रूप से अक्षम है। हमारे बुनियादी ढांचे में 72 कोर के साथ हाइपरविजर हैं, और यदि केवल एक ही व्यस्त है, तो यह बहुत इष्टतम नहीं है।

यह इस तरह किया जाता है:

 ethtool -N eno50 rx-flow-hash udp4 sdfn 

एक महत्वपूर्ण निष्कर्ष: आप सब कुछ सब पर कॉन्फ़िगर कर सकते हैं। डिफ़ॉल्ट कॉन्फ़िगरेशन कुछ बिंदु पर फिट होगा (जैसा कि हमने किया था), लेकिन टाइमआउट के साथ समस्या ने इसे खोजना आवश्यक बना दिया। और यह सामान्य है।

सुरक्षा नियम

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

इसके साथ ही, खड़ा करने का समय 20-40 मिनट से, सबसे अच्छा, एक घंटे तक बढ़ गया।

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

स्रोत - docs.openstack.org

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

परिणाम

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

वह सब है। प्रश्न पूछें, मेरे सहयोगियों और मैं हमारे अनुभव का जवाब देने और साझा करने के लिए तैयार हैं।