🚴🏾 👰🏼 🌬️ नौ वर्षीय रूटर अनुकूलन 🕺 👩🏼‍🤝‍👩🏻 🖲️

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

नेटवर्क

नेटवर्क खुद 1997 से अस्तित्व में है - यह वह तारीख है जब सभी हॉस्टल को एक एकल नेटवर्क में एकीकृत किया गया था और इंटरनेट तक पहुंच प्राप्त की थी। 2004 तक, कैंपस नेटवर्क पूरी तरह से तांबे पर बनाया गया था, डॉर्मिटरीज़ के बीच एक P270 केबल के साथ लिंक आगे भेजे गए थे (ठीक है, डॉरमेटरीज के बीच की दूरी 350m से अधिक नहीं थी, और लिंक, जब 3c905 कार्ड का उपयोग करते हुए, एक सौ पर गुलाब)। प्रत्येक भवन का अपना सर्वर होता था, जिसमें 3 नेटवर्क कार्ड होते थे। उनमें से दो ने पड़ोसी सर्वरों पर "देखा", तीसरे से जुड़े हॉस्टल के "लोलका"। कुल मिलाकर, सभी छह (और हमारे विश्वविद्यालय में बहुत सारे हॉस्टल थे) एक रिंग में बंद थे, और उनके बीच के मार्ग ओएसपीएफ प्रोटोकॉल का उपयोग करके बनाए गए थे, जिससे लाइन टूटने पर गिरा हुआ लिंक को दरकिनार करके ट्रैफ़िक शुरू करना संभव हो गया था। और अक्सर क्लिपिंग हुई: फिर एक आंधी टूट जाएगी और लिंक टूट जाएगा, फिर बिजली वाले धोखा देंगे। और सर्वरों को स्वयं सेवित करना बहुत सुविधाजनक नहीं था, खासकर जब से वे सभी mottled थे: विभिन्न वर्षों में 486DX4 से (हाँ, 8MB रैम के साथ, 2.0.36 कोर और 3com कार्ड पर, इसने दो 100Mbit लिंक खींचे, हालांकि लोड सीलिंग में था AMD K6-2 और यहां तक कि P4 2.8Ghz के बिना किसी भी आईपीएफवाड के नंगे मार्ग पर।
इस तरह के एक संगठन के नुकसान (आज के मानकों द्वारा बहुत अविश्वसनीय लिंक के अलावा) स्पष्ट हैं: उपयोगकर्ता आधार का प्रबंधन करना बहुत असुविधाजनक है। पते सफेद हैं, उनकी संख्या सीमित है। अनुबंध आईपी "जीवन के लिए", यानी, छात्र की पढ़ाई की पूरी अवधि के लिए बंधा हुआ था। नेटवर्क को खंडों में काटा जाता है, जिनमें से आकार मूल रूप से प्रत्येक छात्रावास में छात्रों की संख्या को ध्यान में रखते हुए बनाया गया था। लेकिन फिर छात्र हॉस्टल से हॉस्टल में चले जाते हैं, तो ऑटोमेशन के संकाय को दार्शनिकों की तुलना में काफी अधिक पते की आवश्यकता होती है - सामान्य तौर पर, डरावनी।
एक्सेस प्रतिबंध मैक-आईपी की एक जोड़ी पर थे, क्योंकि नेटवर्क के "गर्भाधान" के समय, प्रोग्रामर (या यहां तक कि एक टांका लगाने वाले लोहे) के बिना नेटवर्क कार्ड के मैक पते को बदलना बहुत समस्याग्रस्त था, यदि असंभव नहीं है। इसलिए, यह / etc / ethers फ़ाइल को अद्यतित रखने और 99% फ्रीबी प्रेमियों से बचाने के लिए पर्याप्त था। उन दिनों में प्रबंधित स्विच केवल सपना देखा गया था, और उन्हें सब्सक्राइबर उपकरण के रूप में स्थापित करना असंभव था (चूंकि नेटवर्क स्वयं छात्रों के पैसे से 100% विकसित हो रहा था, और छात्र, जैसा कि आप जानते हैं, अमीर नहीं हैं)

सितारा

2004 में, एक अच्छा अवसर निकला: शहर के प्रदाताओं में से एक ने अपने नेटवर्क और कैंपस नेटवर्क के बीच सहानुभूति के बदले में प्रस्तावित किया कि सभी इमारतों को वैकल्पिक रूप से मुफ्त में जोड़ा जाए। खैर, कैसे जुड़ना है - छात्रों का एक पहल समूह प्रकाशिकी की स्थापना में सीधे शामिल था, जबकि प्रदाता की तकनीक केवल इसे पचाती थी। नतीजतन, इस प्रकाशिकी का उपयोग करके, एक अंगूठी नहीं, बल्कि एक स्टार का निर्माण करना संभव था!
और फिर विचार पैदा हुआ था - एक अच्छा सर्वर लगाने के लिए, कई गीगाबिट नेटवर्क कार्ड के साथ, सभी लिंक को एक पुल में जोड़ने के लिए और एक फ्लैट नेटवर्क बनाने के लिए, जो सबनेट में एड्रेस स्पेस कट के साथ सिरदर्द से छुटकारा दिलाएगा, और आपको एक से पहुंच को नियंत्रित करने की अनुमति भी देगा। जगह।
चूंकि पीसीआई बस ऐसे यातायात को पंप नहीं कर सकती है, और मदरबोर्ड पर इतने सारे पीसीआई कनेक्टर की कमी के कारण आवश्यक 6-8 गीगाबिट पोर्ट प्राप्त नहीं किए जा सकते हैं, इसलिए पीसीआई-एक्स 133MZz बस पर 2x इंटेल क्वाड पोर्ट सर्वर एडाप्टर लेने का निर्णय लिया गया था। मुझे सुपरमाइक्रो X6DHE-XG2 मदरबोर्ड को इन नेटवर्क पर ले जाना था क्योंकि तीन पीसीआई-एक्स 133 की उपलब्धता के कारण, ठीक है, इस पर प्रोसेसर, Xeon 3Ghz 2 पीसी (ये वे हैं जो लिगेसी क्सीनन अनुभाग में ark.intel.com पर मिल सकते हैं)
और दूर हम जाते हैं: सर्वर पर RHELAS 2.1 स्थापित है, पुल शुरू हो गया है, नेटवर्क एक बड़े / 22 में एक साथ चिपका हुआ है। और फिर यह पता चला है कि यदि आप नियमों का उपयोग करके सैकड़ों पते के एक जोड़े तक पहुंच को प्रतिबंधित करते हैं:
iptables -A FORWARD -s abcd -j REJECT
फिर सर्वर पर लोड अशोभनीय मूल्यों के लिए उछाल। सर्वर सामना नहीं करता है?

अनुकूलन १

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

 iptables -t mangle -A PREROUTING -m physdev --physdev-in eth1 -m set --set IPMAC_H1 src -j ACCEPT iptables -t mangle -A PREROUTING -m physdev --physdev-in eth2 -m set --set IPMAC_H2 src -j ACCEPT ... iptables -t mangle -A PREROUTING -i br0 -j DROP

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

अनुकूलन 2

नतीजतन, सभी इंटरकॉम्युनिटी और बाहरी ट्रैफ़िक अंततः सर्वर के माध्यम से जाने लगे, यह विचार आया कि यदि ग्राहक डिस्कनेक्ट हो गया है, या आईपी-मैक जोड़ी बेमेल की स्थिति में, उपयोगकर्ता को प्रदर्शित करने के लिए एक निश्चित जानकारी के साथ प्रदर्शित करने के लिए क्यों, वास्तव में। नेटवर्क काम नहीं करता है। ऐसा लग रहा था कि यह मुश्किल नहीं है। DROP पैकेट 80 के पोर्ट में जाने के बजाय, आपको एक MARK पैकेट बनाना था, और फिर स्थानीय वेब सर्वर पर DNAT का उपयोग करके चिह्नित पैकेटों को पुनर्निर्देशित करना था।
पहली समस्या यह निकली कि यदि आप किसी वेब सर्वर पर केवल पैकेज को पुनर्निर्देशित करते हैं, तो 99% मामलों में वेब सर्वर जवाब देता है कि पृष्ठ नहीं मिला। क्योंकि, यदि उपयोगकर्ता ark.intel.com/products/27100 पर गया है, और आपने इसे अपने वेब सर्वर पर दिया है, तो यह संभावना नहीं है कि कोई उत्पाद / 27100 पेज होगा, और सबसे अच्छा आपको 404 त्रुटि मिलेगी। इसलिए, एक साधारण लिखा गया था। सी में डेमन, जिसने कोई अनुरोध जारी किया Location: myserverru
बाद में इस बैसाखी को mod_rewrite के साथ और अधिक सुंदर समाधान के साथ बदल दिया गया।
दूसरी, और सबसे महत्वपूर्ण, समस्या यह थी कि जैसे ही नेट मॉड्यूल को कर्नेल में लोड किया गया था, लोड फिर से कूद गया। बेशक, कंसट्रैक टेबल को दोष देना है, और इतने सारे कनेक्शन और pps के साथ, मौजूदा लोहे ने पीक घंटों के दौरान बाहर नहीं निकाला।
सर्वर सामना नहीं करता है?
सोचना शुरू करो। लक्ष्य काफी दिलचस्प है, लेकिन मौजूदा हार्डवेयर पर काम नहीं करता है। -t raw -j NOTRACK का उपयोग करने में मदद की, लेकिन ज्यादा नहीं। इसका समाधान यह था: NAT पैकेट केंद्रीय राउटर पर नहीं, बल्कि एक पुरानी मशीन पर जो अभी भी बने हुए थे और विभिन्न सेवाओं जैसे पी 2 पी सर्वर, गेम सर्वर, जैबर सर्वर या यहां तक कि केवल बेकार के लिए उपयोग किए जाते थे। इस सर्वर पर लोड में वृद्धि की स्थिति में, सबसे खराब स्थिति में, सब्सक्राइबर को ब्राउज़र विंडो में संदेश नहीं मिलेगा कि उसे डिस्कनेक्ट किया गया था (या उसका आईपी पंजीकृत मैक से मेल नहीं खाता), और यह अन्य नेटवर्क उपयोगकर्ताओं के काम को प्रभावित नहीं करेगा। और NAT के साथ इस सर्वर पर उपयोगकर्ता यातायात देने के लिए, निम्न कमांड का उपयोग किया गया था:
iptables -t mangle -A POSTROUTING -p tcp --dport 80 -j ROUTE --gw abcd
जिसने गेटवे पते को बदल दिया और बाकी चैन को दरकिनार कर पैकेट को आगे भेज दिया।
सामान्य तौर पर, फिल्टर प्रकार की शेष श्रृंखलाओं से गुजरने के बारे में चिंता किए बिना, "आपत्तिजनक" पैकेजों को इस तरह से तृतीय-पक्ष सर्वर पर प्रसंस्करण के लिए भेजना बहुत सुविधाजनक था, लेकिन कर्नेल वास्तुकला में बदलाव के साथ, पैच-ओ-मैटिक से यह पैच असमर्थित हो गया।
समाधान: 0x1 के साथ आवश्यक पैकेट को चिह्नित करें, फिर, आईपी नियम fw का उपयोग करके, पैकेट को "अन्य" रूटिंग टेबल पर भेजें, जहां एकमात्र मार्ग NAT के साथ हमारा सर्वर है

 iptables -t mangle -A PREROUTING -p tcp --dport 80 -j MARK --set-mark 0x1 ip route flush table 100 ip route add via abcd table 100 ip rule add fwmark 0x1 lookup 100

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

अनुकूलन ३

कार्रवाई एक छात्रावास में मेगाबाइट यातायात के दौरान होती है। यानी कैश-फ्री, ऑनलाइन-एक्टिव और आईटी-एडवांस्ड यूजर एनवायरनमेंट में। इसका मतलब यह है कि एक साधारण आईपी-मैक बाइंडिंग पर्याप्त नहीं है, और इंटरनेट ट्रैफ़िक की चोरी के मामले व्यापक होते जा रहे हैं।
एकमात्र समझदार विकल्प vpn है। लेकिन, यह देखते हुए कि उस समय तक कैंपस नेटवर्क आधा दर्जन शहर संचालकों के साथ मुक्त हो चुका था, यह वीपीएन सर्वर के माध्यम से पीयर-टू-पीयर ट्रैफिक चलाने के लिए काम नहीं करेगा, बस इसे बाहर नहीं निकाला जा सकता था। बेशक, एक विधि जो व्यापक हो गई थी: इंटरनेट पर - वीपीएन के माध्यम से, पीयरिंग और लैन तक - मार्गों पर एक बैच फ़ाइल। लेकिन बैच फाइल मुझे बहुत बदसूरत फैसला लग रहा था। हमने RIPv2 के साथ विकल्प पर विचार किया, जो उस समय अधिकांश ऑपरेटिंग सिस्टम में "अंतर्निहित" था, लेकिन घोषणाओं की प्रामाणिकता के साथ एक खुला प्रश्न बना रहा। अतिरिक्त कॉन्फ़िगरेशन के बिना, कोई भी मार्ग भेज सकता है, और तत्कालीन लोकप्रिय WindowXP और इसके "RIP श्रोता" में कोई कॉन्फ़िगरेशन नहीं था।
तब "असममित वीपीएन" का आविष्कार किया गया था। इंटरनेट तक पहुँचने के लिए, क्लाइंट सर्वर में एक यूजरनेम / पासवर्ड के साथ एक सामान्य vpn-pptp कनेक्शन स्थापित करता है, जबकि सेटिंग्स में "रिमोट नेटवर्क पर गेटवे का उपयोग करें" चेकबॉक्स अनचेक करता है। पता 192.0.2.2 सुरंग के क्लाइंट अंत के लिए जारी किया गया था, और सभी ग्राहकों के पास एक ही पता था, और जैसा कि बाद में दिखाया जाएगा, इसका कोई महत्व नहीं था।
वीपीएन सर्वर की तरफ, / etc / ppp / ip-up स्क्रिप्ट को संशोधित किया गया था, जिसे प्रमाणीकरण और इंटरफ़ेस बढ़ाने के बाद निष्पादित किया गया है

 PATH=/sbin:/usr/sbin:/bin:/usr/bin export PATH LOGDEVICE=$6 REALDEVICE=$1 [ -f /etc/sysconfig/network-scripts/ifcfg-${LOGDEVICE} ] && /etc/sysconfig/network-scripts/ifup-post ifcfg-${LOGDEVICE} [ -x /etc/ppp/ip-up.local ] && /etc/ppp/ip-up.local "$@" PEERIP=`/usr/local/bin/getip.pl $PEERNAME` if [ $LOGDEVICE == $PEERIP ] ; then ip ro del $PEERIP table vpn > /dev/null 2>/dev/null& ip ro add $PEERIP dev $IFNAME table 101 else ifconfig $IFNAME down kill $PPPD_PID fi exit 0

वह है, IP पता जिसे PEERNAME वाला उपयोगकर्ता (लॉगिन जिसके साथ वह जुड़ा हुआ है) डेटाबेस से PEERIP चर में डेटाबेस से खींचा जाता है, और यदि यह पता उस IP से मेल खाता है जिससे VPN सर्वर से कनेक्शन (LOGDEVICE) बनाया गया था, तो इस IP पर सभी ट्रैफ़िक को IFNAME इंटरफ़ेस में तालिका 101 के माध्यम से रूट किया गया है। इसके अलावा, तालिका 101 में, डिफ़ॉल्ट गेटवे 2.0.0.1.1 है
नियम से सभी रूट किए गए ट्रैफ़िक को 101 टेबल में लपेटा गया है
ip ru add iif eth0 lookup 101
नतीजतन, हमें पता चलता है कि वीपीएन सर्वर पर आने वाला ट्रैफ़िक, और वीपीएन सर्वर के लिए अगले नहीं (जो कि स्थानीय टेबल पर जाता है, जो डिफ़ॉल्ट रूप से होता है) टेबल 101 पर जाता है। और यह पीपीपी सुरंगों के साथ "फैल" जाता है। और अगर उसे सही नहीं मिला, तो वह बस छोड़ देगा।
प्लेट 101 में परिणाम क्या है (आईपी आर श टा 101) का एक उदाहरण

 [root@vpn ~]# ip route show table 101 abcd dev ppp2 scope link abce dev ppp6 scope link abcf dev ppp1 scope link default via 127.0.0.1 dev lo

अब जो कुछ बचा है वह "इंटरनेट" इंटरफ़ेस से सभी ट्रैफ़िक को सेंट्रल राउटर पर वीपीएन गेटवे तक लपेटने के लिए है, और उपयोगकर्ताओं को वीपीएन से कनेक्ट किए बिना इंटरनेट एक्सेस नहीं होगा। इसके अलावा, बाकी ट्रैफ़िक (पीयर-टू-पीयर) IPoE (यानी, "सामान्य" तरीका) चलाएगा, और वीपीएन सर्वर को लोड नहीं करेगा। जब अतिरिक्त पीयर-टू-पीयर नेटवर्क दिखाई देते हैं, तो उपयोगकर्ता को किसी भी बैट-फाइल को संपादित करने की आवश्यकता नहीं होती है। फिर, कुछ आंतरिक संसाधनों तक पहुंच, कम से कम आईपी, कम से कम बंदरगाहों, वीपीएन के माध्यम से किया जा सकता है, बस पैकेट को वीपीएन सर्वर पर लपेटो।
इस तकनीक का उपयोग करते हुए, एक हमलावर निश्चित रूप से आईपी-मैक को प्रतिस्थापित करके इंटरनेट पर ट्रैफ़िक भेज सकता है, लेकिन कुछ भी वापस नहीं मिल सकता है, क्योंकि vpn सुरंग को नहीं उठाया गया है। क्या लगभग पूरी तरह से प्रतिस्थापन के अर्थ को मारता है - अब आप किसी अन्य के आईपी से "इंटरनेट पर सर्फ" नहीं कर सकते।
क्लाइंट कंप्यूटरों को vpn सुरंग के माध्यम से पैकेट प्राप्त करने में सक्षम होने के लिए, Windows में रजिस्ट्री में IPEnableRouter = 1 कुंजी सेट करना आवश्यक था, और linux में rp_filter = 0। अन्यथा, ओएस ने उन इंटरफेस से प्रतिक्रियाएं स्वीकार नहीं कीं जहां अनुरोध भेजे गए थे।
कार्यान्वयन की लागत लगभग शून्य है, ~ 700 के लिए एक साथ कनेक्शन के लिए वीपीएन ह्वाटलो सर्वर स्तर सेलेरॉन 2Ghz, चूंकि मेगाबाइट टैरिफ के समय इंटरनेट ट्रैफिक पीपीपी के अंदर बहुत बड़ा नहीं था। इसी समय, सहकर्मी से सहकर्मी ट्रैफ़िक कुल 6 Gbit / s तक की गति से चला (S604 पर Xeon के माध्यम से)

संचालित

इस चमत्कार ने लगभग 8 वर्षों तक काम किया। 2006 में, RHELAS 2.1 को ताज़ा रिलीज़ किए गए CentOS 4 से बदल दिया गया। इमारतों में केंद्रीय स्विचों को DES-3028 में बदल दिया गया, DES-1024 ग्राहक-पक्ष बना रहा। DES-3028 पर अभिगम नियंत्रण ठीक से काम नहीं करता था। एसीएल का उपयोग करके पोर्ट के लिए आईपी-मैक को बांधने के लिए, 256 प्रविष्टियां गायब थीं, क्योंकि कुछ छात्रावासों में 300 से अधिक कंप्यूटर थे। उपकरण बदलना एक समस्या बन गई, क्योंकि विश्वविद्यालय ने नेटवर्क को "वैध" कर दिया था, और अब विश्वविद्यालय के कैश डेस्क पर इसके लिए भुगतान करना आवश्यक था, उपकरण वापस करने के लिए कोई पैसा आवंटित नहीं किया गया था, और यदि इसे आवंटित किया गया था, तो यह एक वर्ष बाद, एक प्रतियोगिता के माध्यम से और जब वे खरीद नहीं करेंगे आपको क्या चाहिए, और क्या सस्ता है, या कहां रोलबैक अधिक है)।

सर्वर टूट गया है

और फिर सर्वर टूट गया। बल्कि, मदरबोर्ड जल गया (कार्यशाला से निष्कर्ष के अनुसार - उत्तर पुल की मृत्यु हो गई)। पैसे, कोई पैसा बदलने के लिए कुछ इकट्ठा करने की जरूरत है। यानी यह मुफ्त में अच्छा होगा। और ताकि आप PCI-X नेटवर्क सम्मिलित कर सकें। सौभाग्य से, मेरे दोस्त ने बैंक से लिखे सर्वर को दिया, इसमें सिर्फ पीसीआई-एक्स 133 स्लॉट्स की एक जोड़ी थी। लेकिन मदरबोर्ड सिंगल-प्रोसेसर है, और इसमें एक्सोन नहीं है, लेकिन सॉकेट 478 पेंटियम 4 जी 3 जीज़
स्क्रू, नेटवर्क कार्ड फेंको। हम शुरू करते हैं - यह काम करने लगता है।
लेकिन सॉफ्टिरक दो छद्म-नाभिक के कुल का 90% "खाता है" (प्रोसेसर में एक कोर है, और हाइपरट्रेडिंग सक्षम है), पिंग कूदता है 3000 तक, यहां तक कि कंसोल "मर जाता है" असंभव के लिए।
बुरा बन गया

ऐसा लगता है कि यह यहाँ है, सर्वर पुराना है, यह आराम करने का समय है।

अनुकूलन ४

ऑप्रोफाइल के साथ सशस्त्र, मैं "अतिरिक्त खाँसी" शुरू करता हूं। सामान्य तौर पर, इस सर्वर के साथ "संचार" की प्रक्रिया में ऑप्रोफाइल का उपयोग अक्सर किया जाता था, और एक से अधिक बार यह मदद करता था। उदाहरण के लिए, यहां तक कि ipset का उपयोग करते हुए मैं ipmap का उपयोग करने की कोशिश करता हूं, न कि iphash (यदि संभव हो), क्योंकि ऑप्रोफाइल के साथ आप वास्तव में देख सकते हैं कि प्रदर्शन में कितना अंतर है। मेरे आंकड़ों के अनुसार, इसने परिमाण के दो क्रमों को बदल दिया, अर्थात, यह 200 से 400 बार तक चला गया। इसके अलावा, जब अलग-अलग समय पर ट्रैफ़िक की गणना की जाती है, तो मैंने ipcad-ulog से ipcad-pcap पर स्विच किया, और फिर प्रोफाइलिंग पर ध्यान केंद्रित करते हुए, nflow करने के लिए। मैंने अब तक ipt_NETFLOW का उपयोग नहीं किया, इसलिए उन्होंने "अनलिमिटेड इंटरनेट" की उम्र में प्रवेश किया, और SORM के लिए हमारा नेटफ्लो शीर्ष स्तर प्रदाता वहाँ लिखते हैं या नहीं - इसकी समस्याएं। दरअसल, ऑप्रोफाइल का उपयोग करते हुए, यह पता चला था कि nat चालू होने पर ip_conntrack मुख्य संसाधन खाने वाला था।
सामान्य तौर पर, इस समय ऑप्रोफाइल मुझे बताता है कि 60% प्रोसेसर चक्र e1000 कर्नेल मॉड्यूल (नेटवर्क कार्ड) द्वारा कब्जा कर लिया गया है। वैसे इससे क्या करना है? E1000.txt पर अनुशंसित है

options e1000 RxDescriptors=4096,4096,4096,4096,4096,4096,4096,4096,4096,4096 TxDescriptors=4096,4096,4096,4096,4096,4096,4096,4096,4096,4096 InterruptThrottleRate=3000,3000,3000,3000,3000,3000,3000,3000,3000,3000

2005 में वापस खुदा।
E1000 में किसी भी महत्वपूर्ण परिवर्तन के लिए git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git पर एक त्वरित परिणाम परिणामों का उत्पादन नहीं किया (यानी, निश्चित रूप से परिवर्तन हुए हैं, लेकिन बग या रिक्त स्थान) कोड)। बस मामले में, कर्नेल अभी भी अपडेट किया गया है, लेकिन यह परिणाम नहीं देता है।
कर्नेल में CONFIG_HZ_100=y भी है, बड़े मान के साथ, परिणाम और भी बुरे हैं।
Oprofile यह भी बताता है कि पुल मॉड्यूल चक्रों का एक बड़ा हिस्सा लेता है। और, ऐसा प्रतीत होता है, इसके बिना, कहीं नहीं, क्योंकि आईपी पते कई इमारतों में गड़बड़ी में फैले हुए हैं, और उन्हें खंडों में विभाजित करना संभव नहीं है (एक सर्वर के बिना एक खंड में सब कुछ गठबंधन करने का विकल्प नहीं माना जाता है, क्योंकि नियंत्रण खो गया है)
मैं एक पुल को तोड़ने और प्रॉक्सी_आरपी का उपयोग करने के बारे में सोच रहा हूं। खासकर जब से मैं बाढ़-एफडीबी के साथ डेस -3028 में कीड़े का पता लगाने के बाद लंबे समय से ऐसा करना चाहता था। सिद्धांत रूप में, सभी पतों को फॉर्म में राउटिंग टेबल में लोड करना संभव है:

 ip route add abc1.d1 dev eth1 src 1.2.3.4 ip route add abc1.d2 dev eth1 src 1.2.3.4 ... ip route add abc2.d1 dev eth2 src 1.2.3.4 ip route add abc2.d2 dev eth2 src 1.2.3.4 ...

क्योंकि यह ज्ञात है कि ग्राहक को कहां होना चाहिए (डेटाबेस में संग्रहीत)
लेकिन मैं आईपी-मैक बाइंडिंग को न केवल बिल्डिंग में लागू करना चाहता था, बल्कि बिल्डिंग पर नोड स्विच पोर्ट के लिए भी (मैं दोहराता हूं, DES-1024 प्रकार के अप्रबंधित उपकरण ग्राहकों पर हैं)
और फिर हाथ बाहर निकलने के लिए dhcp-relay और dhcp-snooping से निपटते हैं।
स्विच में शामिल हैं:

 enable dhcp_relay config dhcp_relay option_82 state enable config dhcp_relay option_82 check enable config dhcp_relay option_82 policy replace config dhcp_relay option_82 remote_id default config dhcp_relay add ipif System 10.160.8.1 enable address_binding dhcp_snoop enable address_binding trap_log config address_binding ip_mac ports 1-28 mode acl stop_learning_threshold 500 config address_binding ip_mac ports 1-24 state enable strict allow_zeroip enable forward_dhcppkt enable config address_binding dhcp_snoop max_entry ports 1-24 limit no_limit config filter dhcp_server ports 1-24 state enable config filter dhcp_server ports 25-28 state disable config filter dhcp_server trap_log enable config filter dhcp_server illegal_server_log_suppress_duration 1min

सर्वर पर, मैंने पुल से इंटरफेस हटा दिया, उन पर आईपी पते (आईपी के बिना इंटरफेस) को हटा दिया, arp_proxy सक्षम किया

Isc-dhcp को कॉन्फ़िगर करना

 log-facility local6; ddns-update-style none; authoritative; use-host-decl-names on; default-lease-time 300; max-lease-time 600; get-lease-hostnames on; option domain-name "myserver.ru"; option ntp-servers myntp.ru; option domain-name-servers mydnsp-ip; local-address 10.160.8.1; include "/etc/dhcp-hosts"; #   MAC-IP   "host hostname {hardware ethernet AA:BB:CC:55:92:A4; fixed-address wxyz;}" on release { set ClientIP = binary-to-ascii(10, 8, ".", leased-address); log(info, concat("***** release IP " , ClientIP)); execute("/etc/dhcp/dhcp-release", ClientIP); } on expiry { set ClientIP = binary-to-ascii(10, 8, ".", leased-address); log(info, concat("***** expiry IP " , ClientIP)); execute("/etc/dhcp/dhcp-release", ClientIP); } on commit { if exists agent.remote-id { set ClientIP = binary-to-ascii(10, 8, ".", leased-address); set ClientMac = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6)); set ClientPort = binary-to-ascii(10,8,"",suffix(option agent.circuit-id,1)); set ClientSwitch = binary-to-ascii(16,8,":",substring(option agent.remote-id,2,6)); log(info, concat("***** IP: " , ClientIP, " Mac: ", ClientMac, " Port: ",ClientPort, " Switch: ",ClientSwitch)); execute("/etc/dhcp/dhcp-event", ClientIP, ClientMac, ClientPort, ClientSwitch); } } option space microsoft; #   - option microsoft.disable-netbios-over-tcpip code 1 = unsigned integer 32; if substring(option vendor-class-identifier, 0, 4) = "MSFT" { vendor-option-space microsoft; } shared-network HOSTEL { subnet 10.160.0.0 netmask 255.255.248.0 { range 10.160.0.1 10.160.0.100; #    option routers 10.160.1.1; option microsoft.disable-netbios-over-tcpip 2; } subnet abc0 netmask 255.255.252.0 { option routers abcd; option microsoft.disable-netbios-over-tcpip 2; } subnet 10.160.8.0 netmask 255.255.255.0 { #    dhcp-relay   } }

Dhcp-event फ़ाइल में, Agent.circuit-id, agent.remote-id, IP और MAC को वैधता के लिए जाँच की जाती है, और यदि सब कुछ ठीक है, तो वांछित इंटरफ़ेस के माध्यम से इस पते पर रूट जोड़ा जाता है
आदिम dhcp- घटना उदाहरण:

 #hostel 1 if ($ARGV[3] eq '0:21:91:92:d7:55') { system "/sbin/ip ro add $ARGV[0] dev eth1 src abcd"; } #hostel 2 if ($ARGV[3] eq '0:21:91:92:d4:92') { system "/sbin/ip ro add $ARGV[0] dev eth2 src abcd"; }

केवल $ ARGV [3] को यहाँ चेक किया गया है (अर्थात, Agent.remote-id, या स्विच का MAC जिसके माध्यम से DHCP अनुरोध प्राप्त हुआ था), लेकिन आप सभी अन्य क्षेत्रों को उनके वैध मान प्राप्त करके भी देख सकते हैं, उदाहरण के लिए, डेटाबेस से

नतीजतन, हम प्राप्त करते हैं:
1) एक ग्राहक जो डीएचसीपी के माध्यम से एक पते का अनुरोध नहीं करता था - अपने अप्रबंधित स्विच से परे नहीं जाता है, आईपी-मैक-पोर्ट-बाइंडिंग इसे नहीं होने देता है;
2) एक क्लाइंट जिसका मैक जाना जाता है (डेटाबेस में है), लेकिन अनुरोध पोर्ट या स्विच से मेल नहीं खाता - इस मैक से जुड़ी आईपी प्राप्त करेगा, लेकिन इसके लिए मार्ग जोड़ा नहीं जाएगा, तदनुसार प्रॉक्सी_रप "जवाब" देगा कि पता पहले से ही लिया गया है, और पता तुरंत जारी किया जाएगा;
3) एक ग्राहक जिसका मैक ज्ञात नहीं है, उसे अस्थायी पूल से एक पता प्राप्त होगा। इन पतों से जानकारी के साथ एक पृष्ठ पर पुनर्निर्देशन होता है, यहां आप लॉगिन / पासवर्ड का उपयोग करके अपने मैक को फिर से पंजीकृत कर सकते हैं;
4) और अंत में, क्लाइंट जिसका मैक जाना जाता है, और स्विच और पोर्ट से कनेक्शन से मेल खाता है, वह अपना पता प्राप्त करेगा। Dhcp- स्नूपिंग स्विच पर impb टेबल में डायनेमिक बाइंडिंग जोड़ देगा, सर्वर पूर्व ब्रिज के वांछित इंटरफ़ेस के माध्यम से इस पते पर एक मार्ग जोड़ देगा।

जब लीज़ समाप्त हो जाती है या पता जारी हो जाता है, तो स्क्रिप्ट / etc / dhcp / dhcp-release को कहा जाता है, जिसकी सामग्री बहुत ही आदिम है:

 system "/sbin/ip ro del $ARGV[0]";

एक छोटा सुरक्षा दोष है, विशेष रूप से पैराग्राफ 2 में। यदि आप एक गैर-मानक dhcp-client का उपयोग करते हैं, जो यह जांच नहीं करता है कि क्या dhcp सर्वर द्वारा प्रदान किया गया पता व्यस्त है, तो पता जारी नहीं किया जाएगा। बेशक, उपयोगकर्ता को राउटर से परे बाहरी नेटवर्क तक पहुंच नहीं होगी, क्योंकि सर्वर वांछित इंटरफ़ेस के माध्यम से इस पते पर एक मार्ग नहीं जोड़ेगा, लेकिन स्विच इस मैक-आईपी जोड़ी को अपने पोर्ट पर अनलॉक करेगा।
आप dhcpd.conf में कक्षाओं का उपयोग करके इस दोष को प्राप्त कर सकते हैं, लेकिन यह कॉन्फ़िगरेशन फ़ाइल को महत्वपूर्ण रूप से जटिल करता है और, तदनुसार, हमारे पुराने सर्वर पर लोड बढ़ाता है। क्योंकि प्रत्येक ग्राहक के लिए आपको अपना स्वयं का वर्ग बनाना होगा, क्योंकि इसमें आने के लिए कठिन स्थिति होनी चाहिए, और फिर आपका अपना पूल। हालांकि अभ्यास में प्रयास करने की योजना है कि इससे भार कितना बढ़ेगा।

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

अर्थात्, पुल को डिसाइड करने की इस पूरी प्रक्रिया ने सर्वर पर समग्र भार को लगभग 2 गुना कम कर दिया ! सॉफ्टरिक अब 50-100% नहीं, बल्कि 25-50% है। इसी समय, नेटवर्क तक पहुंच नियंत्रण केवल बेहतर हो गया है।

अनुकूलन ५

अंतिम अनुकूलन के बाद, हालांकि भार काफी कम हो गया, एक अजीब बात देखी गई: आयोवाइट में वृद्धि हुई। इतना नहीं, 0-0.3% से 5-7% तक। यह इस तथ्य को ध्यान में रख रहा है कि इस सर्वर पर व्यावहारिक रूप से कोई डिस्क संचालन नहीं है - यह सिर्फ पैकेट फेंकता है।
iowait

(नीला उपयोगकर्ता समय - कर्नेल संकलन)
iostat ने दिखाया कि 800-820 Blk_wrtn / s में डिस्क पर एक निरंतर लोड है जो
प्रक्रियाओं को खोज सकता है जो लिख सकता है। क्रियान्वयन

 echo 1 > /proc/sys/vm/block_dump

एक अजीब परिणाम दिया: अपराधी थे

 kjournald(483): WRITE block 76480 on md0  md0_raid1(481): WRITE block 154207744 on sdb2 md0_raid1(481): WRITE block 154207744 on sda3

Ext3 मोड में है data=writeback, noatime, और लॉग को छोड़कर, डिस्क पर कुछ भी नहीं लिखा गया है। लेकिन जो लॉग कल लिखे गए थे, वे आज लिखे गए हैं, उनकी मात्रा में वृद्धि नहीं हुई है, अर्थात्, iowait को भी नहीं बढ़ाना था।
मैंने अपने सिर में चरणों के माध्यम से स्क्रॉल करना शुरू कर दिया, मैं क्या कर रहा था और क्या इवाइट को प्रभावित कर सकता था। नतीजतन, मैंने syslog बंद कर दिया - और iowait ~ 0% तक तेजी से गिरा।
अपने संदेशों के साथ अव्यवस्थित संदेशों से dhcp को रोकने के लिए, मैंने उन्हें लॉग-सुविधा स्थानीय 6 पर भेजा, और syslog.conf में लिखा:

 *.info;mail.none;authpriv.none;cron.none;local6.none /var/log/messages local6.info /var/log/dhcpd.log

यह पता चला है कि जब syslog के माध्यम से लिखते हैं, तो प्रत्येक पंक्ति के लिए सिंक किया जाता है। Dhcp सर्वर के लिए बहुत सारे अनुरोध हैं, बहुत सारी घटनाएं उत्पन्न होती हैं जो लॉग में आती हैं, और बहुत से सिंक को कहा जाता है।
पर ठीक करें

 local6.info -/var/log/dhcpd.log

iowait मेरे मामले में 10-100 गुना कम हो गया , 5-7% के बजाय यह 0-0.3%
अनुकूलन परिणाम बन गया :

यह लेख क्यों।
सबसे पहले, शायद कोई इसे अपने लिए उपयोगी समाधान से आकर्षित करेगा। मुझे यहाँ अमेरिका की खोज नहीं हुई, हालाँकि यहाँ वर्णित अधिकांश घटनाएँ पूर्व-गुबन युग में थीं, और "गोलगप्पे बनाने की विधि" से बहुत मदद नहीं मिली, मुझे यह सब अपने सिर से मिला।
दूसरे, हमें लगातार इस तथ्य से निपटना होगा कि कोड को अनुकूलित करने के बजाय, डेवलपर्स कंप्यूटिंग शक्ति को बढ़ाने में लगे हुए हैं, और यह लेख इस तथ्य का उदाहरण हो सकता है कि, यदि आप चाहें, तो आप अपने प्रतीत होने वाले कई बार कोड में त्रुटियों को पा सकते हैं और उनका प्रबंधन कर सकते हैं। । साइट डेवलपर्स के 90% अपनी मशीन पर साइट के काम की जांच करते हैं, इसे उत्पादन में डालते हैं। फिर पूरी चीज लोड के नीचे धीमी हो जाती है। एडमिन सर्वर को छेड़ना। इस मामले में सर्वर का अनुकूलन करके, थोड़ा प्राप्त किया जा सकता है यदि कोड मूल रूप से लिखा गया है न कि बेहतर तरीके से। और एक नया सर्वर खरीदा जाता है, या दूसरा सर्वर और बैलेंसर। फिर बैलेंसर वगैरह की बात। और अंदर का कोड इष्टतम नहीं था, और हमेशा के लिए रहता है। बेशक, मैं समझता हूं कि वर्तमान वास्तविकताओं में, व्यापक क्षमता निर्माण की तुलना में कोड अनुकूलन अधिक महंगा है,लेकिन "होमग्रोन" आईटी विशेषज्ञों की एक बड़ी संख्या के आगमन के साथ, "बुरे कोड" की मात्रा गंभीर हो जाती है।
उदासीन से: मेरे पास एक पुराना लैपटॉप है, P3-866 2001 (पैनासोनिक सीएफ-टी 1 यदि कोई व्यक्ति इस बारे में कुछ कहता है), लेकिन अब इस पर साइटों को देखना भी असंभव है, हालांकि इन साइटों पर 10 साल से अधिक कोई अर्थ नहीं है। मुझे याद है कि ZX- स्पेक्ट्रम पर दिलचस्प खिलौने गेमप्ले के मामले में आज के राक्षसों से नीच नहीं हैं और उन्हें 4 कोर / 4 गिग की आवश्यकता है

नौ वर्षीय रूटर अनुकूलन