हमारे शहर के नेटवर्क में 30 हजार से अधिक ग्राहक हैं। बाहरी चैनलों की कुल मात्रा 3 से अधिक गीगाबिट है। और उल्लिखित लेख में दी गई सलाह, हम कुछ साल पहले पारित कर चुके हैं। इस प्रकार, मैं इस विषय को अधिक विस्तृत रूप से विस्तारित करना चाहता हूं और चर्चा के तहत मुद्दे के ढांचे के भीतर अपने सर्वोत्तम अभ्यासों को पाठकों के साथ साझा करना चाहता हूं।
नोट में राउटर / ट्यूनिंग और एनएटी-सर्वर पर चलने वाले लिनक्स की ट्यूनिंग, साथ ही साथ इंटरप्ट के वितरण के बारे में कुछ स्पष्टीकरण दिए गए हैं।
बीच में आता है
अलग-अलग कर्नेल में नेटवर्क कार्ड को फेंकना बहुत ही पहली बात है जो एक सिस्टम एडमिनिस्ट्रेटर का सामना एक लिनक्स राउटर पर बढ़ते लोड के साथ होता है। इस लेख में, विषय पर्याप्त विवरण में कवर किया गया है - इसलिए, हम इस मुद्दे पर लंबे समय तक नहीं रहेंगे।
मैं सिर्फ नोट करना चाहता हूं:
- यदि आप मैन्युअल रूप से इंटरप्ट को फेंकते हैं, तो आपको असंबद्धता सेवा को रोकने की आवश्यकता है। यह सेवा विशेष रूप से प्रोसेसर कोर के बीच स्वचालित रूप से व्यवधान को नियंत्रित करने के लिए डिज़ाइन की गई है। यदि आप मैन्युअल रूप से यह काम करते हैं, तो सेवा को रोकना बेहतर है;
- "स्टार्टअप" (उदाहरण के लिए, /etc/rc.local) के लिए उपयुक्त परिवर्तन करना न भूलें - क्योंकि सर्वर के पुनरारंभ होने के बाद, सभी व्यवधानों को फिर से एक कोर पर vkuchnu वितरित किया जाएगा;
- सर्वर को पुनरारंभ करने के बाद, नेटवर्क कार्ड प्राप्त कर सकते हैं (और सबसे अधिक संभावना है, यह मामला होगा) नए इंटरप्ट नंबर। इसलिए, /etc/rc.local में अपने हाथों से विशिष्ट रुकावट संख्याओं को दर्ज नहीं करना बेहतर है - लेकिन सहायक स्क्रिप्ट की सहायता से स्वचालित करने के लिए कि किस नेटवर्क व्यवधान की मान्यता ली गई है।
रूटर
मूल लेख में, वाक्यांश है "यदि सर्वर केवल एक राउटर के साथ काम करता है, तो टीसीपी स्टैक को ट्यूनिंग करना वास्तव में मायने नहीं रखता है।" यह कथन मौलिक रूप से असत्य है। बेशक, छोटे प्रवाह पर ट्यूनिंग एक बड़ी भूमिका नहीं निभाता है। हालांकि, यदि आपके पास एक बड़ा नेटवर्क और संबंधित लोड है, तो आपको नेटवर्क स्टैक की ट्यूनिंग करनी होगी।
सबसे पहले, अगर गीगाबिट्स आपके नेटवर्क पर "चलते हैं", तो यह आपके सर्वर और स्विच पर एमटीयू पर आपका ध्यान देने के लिए समझ में आता है। संक्षेप में, एमटीयू एक पैकेट का आयतन है जिसे विखंडन का सहारा लिए बिना नेटवर्क पर प्रसारित किया जा सकता है। यानी विखंडन के बिना आपका एक राउटर दूसरे को कितनी जानकारी हस्तांतरित कर सकता है। नेटवर्क पर प्रेषित डेटा की मात्रा में उल्लेखनीय वृद्धि के साथ, यह अक्सर बड़ी डेटा के पैकेट को प्रसारित करने के लिए बहुत अधिक कुशल होता है जो अक्सर छोटे डेटा पैकेट भेजते हैं।
लिनक्स पर MTU बढ़ाएँ
/sbin/ifconfig eth0 mtu 9000
स्विच पर MTU बढ़ाएं
स्विचिंग उपकरण पर, इसे आमतौर पर जंबो-फ्रेम कहा जाएगा। विशेष रूप से सिस्को उत्प्रेरक 3750 के लिए
3750(config)# system mtu jumbo 9000
3750(config)# exit
3750# reload
नोट: स्विच को फिर से रिबूट करना होगा। वैसे, mtu जंबो चिंता केवल गीगाबिट लिंक - 100-एमबीपीएस ऐसी कमांड को प्रभावित नहीं करती है।
लिनक्स पर स्थानांतरण कतार बढ़ाएँ
/sbin/ifconfig eth0 txqueuelen 10000
डिफ़ॉल्ट रूप से, मान 1000 है। गीगाबिट लिंक के लिए, इसे 10000 सेट करने की सिफारिश की गई है। संक्षेप में, यह स्थानांतरण बफर का आकार है। जब बफ़र को इस सीमा मान से भर दिया जाता है, तो डेटा नेटवर्क में प्रसारित होता है।
ध्यान रखें कि यदि आप एमटीयू आकार को हार्डवेयर के टुकड़े के इंटरफेस पर बदलते हैं, तो आपको इसके पड़ोसी के इंटरफेस पर भी ऐसा ही करना होगा। यही है, यदि आपने लिनक्स राउटर के इंटरफेस पर एमटीयू को 9000 तक बढ़ाया है, तो आपको स्विच पोर्ट पर जंबो-फ्रेम को सक्षम करना होगा जिसमें यह राउटर शामिल है। अन्यथा, नेटवर्क काम करेगा, लेकिन यह बहुत बुरा है: पैकेट "एक के माध्यम से" नेटवर्क से गुजरेंगे।
परिणाम
इन सभी परिवर्तनों के परिणामस्वरूप, नेटवर्क में "पिंग्स" में वृद्धि होगी - लेकिन समग्र थ्रूपुट में काफी वृद्धि होगी, और सक्रिय उपकरणों पर भार घट जाएगा।
NAT सर्वर
ऑपरेशन NAT (नेटवर्क एड्रेस ट्रांसलेशन) सबसे महंगा (संसाधन-गहन के अर्थ में) में से एक है। इसलिए, यदि आपके पास एक बड़ा नेटवर्क है, तो आप NAT सर्वर को ट्यून किए बिना नहीं कर सकते।
मॉनिटर किए गए कनेक्शनों में वृद्धि
अपने कार्य को पूरा करने के लिए, NAT सर्वर को इसके माध्यम से गुजरने वाले सभी कनेक्शनों को "याद रखना" चाहिए। चाहे वह पिंग हो या किसी का ICQ, NAT सर्वर इन सभी सत्रों को "याद रखता है" और उन्हें एक विशेष तालिका में अपनी मेमोरी में ट्रैक करता है। जब कोई सत्र बंद होता है, तो तालिका से इसके बारे में जानकारी हटा दी जाती है। इस तालिका का आकार निश्चित है। यही कारण है कि यदि सर्वर के माध्यम से बहुत अधिक ट्रैफ़िक है, लेकिन तालिका का आकार पर्याप्त नहीं है, तो NAT सर्वर पैकेट "ब्रेक" शुरू करता है, सत्रों को तोड़ता है, इंटरनेट भयानक रुकावट के साथ काम करना शुरू कर देता है, और कभी-कभी एसएसएच के माध्यम से एनएटी सर्वर तक पहुंचना भी असंभव हो जाता है ।
ऐसे भयावहता को रोकने के लिए, तालिका के आकार को पर्याप्त रूप से बढ़ाना आवश्यक है - NAT के माध्यम से गुजरने वाले यातायात के अनुसार:
/sbin/sysctl -w net.netfilter.nf_conntrack_max=524288
यह दृढ़ता से अनुशंसा की जाती है कि आप इतने बड़े मूल्य को सेट न करें यदि आपके NAT सर्वर में 1 गीगाबाइट से कम रैम है।
आप वर्तमान मूल्य को इस तरह देख सकते हैं:
/sbin/sysctl net.netfilter.nf_conntrack_max
आप देख सकते हैं कि कनेक्शन ट्रैकिंग टेबल पहले से कितनी भरी हुई है, जैसे:
/sbin/sysctl net.netfilter.nf_conntrack_count
हैश टेबल का आकार बढ़ाना
हैश तालिका जिसमें कॉनट्रैक रिकॉर्ड की सूची संग्रहीत की जाती है, आनुपातिक रूप से बढ़ाई जानी चाहिए।
echo 65536 > /sys/module/nf_conntrack/parameters/hashsize
नियम सरल है: hashsize = nf_conntrack_max / 8
घटते समय का मान
जैसा कि आप याद करते हैं, एक NAT सर्वर केवल लाइव सत्र की निगरानी करता है जो इसके माध्यम से गुजरता है। जब कोई सत्र बंद होता है, तो इसके बारे में जानकारी हटा दी जाती है ताकि तालिका अतिप्रवाह न हो। सत्र की जानकारी भी टाइमआउट द्वारा हटा दी जाती है। यही है, अगर एक्सचेंज कनेक्शन के भीतर लंबे समय तक कोई ट्रैफ़िक नहीं है, तो यह बंद है और इसके बारे में जानकारी भी NAT मेमोरी से हटा दी जाती है।
हालाँकि, डिफ़ॉल्ट रूप से, टाइमआउट मान काफी बड़ा है। इसलिए, बड़े ट्रैफ़िक प्रवाह के साथ, भले ही आप nf_conntrack_max को सीमा तक खींचते हैं, फिर भी आप जल्दी से टेबल ओवरफ्लो और कनेक्शन टूटने का जोखिम उठाते हैं।
ऐसा होने से रोकने के लिए, आपको नेट सर्वर पर कनेक्शन निगरानी टाइमआउट को सही ढंग से सेट करना होगा।
वर्तमान मूल्यों को देखा जा सकता है, उदाहरण के लिए, इस तरह:
sysctl -a | grep conntrack | grep timeout
नतीजतन, आप कुछ इस तरह से देखेंगे:
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_events_retry_timeout = 15
ये सेकंड में टाइमआउट मान हैं। जैसा कि आप देख सकते हैं, net.netfilter.nf_conntrack_generic_timeout का मान 600 (10 मिनट) है। यानी NAT सर्वर मेमोरी सेशन की जानकारी तब तक रखेगा जब तक कि वह हर 10 मिनट में कम से कम एक बार इसके माध्यम से नहीं चलता।
पहली नज़र में, यह ठीक है - लेकिन वास्तव में यह बहुत, बहुत अधिक है।
यदि आप net.netfilter.nf_conntrack_tcp_timeout_established - को देखते हैं, तो आपको वहां का मूल्य 432000 दिखाई देगा। दूसरे शब्दों में, आपका NAT सर्वर एक साधारण टीसीपी सत्र की निगरानी करेगा जब तक कि हर 5 दिन में कम से कम एक बार कुछ पैकेट इसके माध्यम से नहीं आए। !)।
और भी सरल भाषा में बोलना, ऐसे NAT-DDOS सर्वर को सरल से आसान बनाता है: इसकी NAT तालिका (nf_conntrack_max पैरामीटर) सरल बाढ़ के साथ धमाके से भरी है - परिणामस्वरूप, यह डिस्कनेक्ट हो जाएगा और सबसे खराब स्थिति में जल्दी से एक ब्लैक होल में बदल जाएगा ।
टाइमआउट मान 30-120 सेकंड के भीतर सेट करने की सिफारिश की जाती है। यह ग्राहकों के सामान्य काम के लिए काफी पर्याप्त है, और यह NAT तालिका की समय पर सफाई के लिए काफी है, इसके अतिप्रवाह को समाप्त करता है।
और /etc/rc.local और /etc/sysctl.conf में संबंधित परिवर्तन लिखना न भूलें
परिणाम
ट्यूनिंग के बाद, आपको पूरी तरह से व्यवहार्य और उत्पादक NAT सर्वर मिलेगा। बेशक, यह केवल एक "बुनियादी" ट्यूनिंग है - हमने स्पर्श नहीं किया, उदाहरण के लिए, कोर ट्यूनिंग, आदि। बातें। हालांकि, ज्यादातर मामलों में, यहां तक कि इस तरह की सरल क्रियाएं पर्याप्त रूप से बड़े नेटवर्क के सामान्य संचालन के लिए पर्याप्त होंगी। जैसा कि मैंने कहा, हमारे नेटवर्क में 30 हज़ार से अधिक ग्राहक हैं, जिनके ट्रैफ़िक को 4 NAT-सर्वर द्वारा संसाधित किया जाता है।
निम्नलिखित मुद्दों में:
- उच्च प्रवाह और उच्च प्रदर्शन शेपर;
- बड़ी धाराओं और उच्च प्रदर्शन फ़ायरवॉल।