जब Linux conttrack अब आपका मित्र नहीं है

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

कॉनट्रैक एक महत्वपूर्ण कर्नेल सुविधा है जिसका उपयोग कुछ बुनियादी मामलों में किया जाता है:

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

इसके अतिरिक्त, कॉनट्रैक आम तौर पर सिस्टम प्रदर्शन में सुधार करता है (सीपीयू खपत और पैकेट विलंबता को कम करके) क्योंकि स्ट्रीम में केवल पहला पैकेट होता है
इसके साथ क्या करना है यह निर्धारित करने के लिए पूरे नेटवर्क स्टैक का अध्ययन करना होगा। पोस्ट देखें"क्यूब-प्रॉक्सी मोड की तुलना"यह कैसे काम करता है इसका एक उदाहरण देखने के लिए।

हालाँकि, कॉनट्रैक की अपनी सीमाएँ हैं...

तो यह सब गलत कहां हुआ?

कॉनट्रैक तालिका में एक कॉन्फ़िगर करने योग्य अधिकतम आकार होता है, और यदि यह पूर्ण हो जाता है, तो कनेक्शन आमतौर पर अस्वीकार या गिराए जाने लगते हैं। अधिकांश एप्लिकेशन के ट्रैफ़िक को संभालने के लिए तालिका में पर्याप्त खाली स्थान है, और यह कभी भी समस्या नहीं बनेगी। हालाँकि, ऐसे कुछ परिदृश्य हैं जिनमें आप कॉनट्रैक तालिका का उपयोग करने पर विचार करना चाह सकते हैं:

• सबसे स्पष्ट मामला यह है कि यदि आपका सर्वर बहुत बड़ी संख्या में समवर्ती सक्रिय कनेक्शनों को संभालता है। उदाहरण के लिए, यदि आपकी कॉनट्रैक तालिका 128k प्रविष्टियों के लिए कॉन्फ़िगर की गई है, लेकिन आपके पास >128k समवर्ती कनेक्शन हैं, तो आप निश्चित रूप से एक समस्या में पड़ जाएंगे!
• थोड़ा कम स्पष्ट मामला: यदि आपका सर्वर प्रति सेकंड बहुत बड़ी संख्या में कनेक्शन संसाधित करता है। भले ही कनेक्शन अल्पकालिक हों, कुछ समय (डिफ़ॉल्ट रूप से 120 सेकंड) के लिए लिनक्स द्वारा उनकी निगरानी की जाती रहती है। उदाहरण के लिए, यदि आपकी कॉनट्रैक तालिका 128k प्रविष्टियों के लिए कॉन्फ़िगर की गई है और आप प्रति सेकंड 1100 कनेक्शनों को संभालने का प्रयास कर रहे हैं, तो वे कॉनट्रैक तालिका के आकार से अधिक हो जाएंगे, भले ही कनेक्शन बहुत अल्पकालिक हों (128k/120s = 1092 कनेक्शन/ एस)।

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

वास्तविक उदाहरण

आइए एक विशिष्ट उदाहरण दें: एक बड़े SaaS प्रदाता जिसके साथ हमने काम किया था, उसके पास होस्ट्स (वर्चुअल मशीन नहीं) पर कई मेमकैच्ड सर्वर थे, जिनमें से प्रत्येक प्रति सेकंड 50K+ अल्पकालिक कनेक्शन संसाधित करता था।

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

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

कॉनट्रैक को बायपास करने के लिए आपको कितनी दूर तक जाना होगा?

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

आइए परीक्षण शुरू करें

हमने एक पॉड पर मेमकैच्ड सर्वर और रिमोट नोड्स पर चलने वाले कई मेमकैच्ड क्लाइंट पॉड के साथ परीक्षण चलाया, ताकि हम प्रति सेकंड बहुत बड़ी संख्या में कनेक्शन चला सकें। मेम्केच्ड सर्वर पॉड वाले सर्वर में कॉनट्रैक तालिका (होस्ट के लिए मानक कॉन्फ़िगर तालिका आकार) में 8 कोर और 512k प्रविष्टियाँ थीं।
हमने निम्न के बीच प्रदर्शन अंतर मापा: कोई नेटवर्क नीति नहीं; नियमित केलिको नीति के साथ; और केलिको की ट्रैक न करने की नीति।

पहले परीक्षण के लिए, हमने कनेक्शन की संख्या 4.000 प्रति सेकंड निर्धारित की, ताकि हम सीपीयू खपत में अंतर पर ध्यान केंद्रित कर सकें। नो पॉलिसी और नियमित पॉलिसी के बीच कोई महत्वपूर्ण अंतर नहीं थे, लेकिन सीपीयू खपत में लगभग 20% की वृद्धि हुई है:

दूसरे परीक्षण में, हमने उतने कनेक्शन लॉन्च किए जितने हमारे ग्राहक उत्पन्न कर सकते थे और प्रति सेकंड कनेक्शन की अधिकतम संख्या मापी जिसे हमारा मेम्केच्ड सर्वर संभाल सकता था। जैसा कि अपेक्षित था, "कोई नीति नहीं" और "नियमित नीति" दोनों मामले प्रति सेकंड 4,000 से अधिक कनेक्शन (512k / 120s = 4,369 कनेक्शन/सेकेंड) की संपर्क सीमा तक पहुंच गए। ट्रैक न करें नीति के साथ, हमारे ग्राहकों ने बिना किसी समस्या के प्रति सेकंड 60,000 कनेक्शन भेजे। हमें यकीन है कि हम और अधिक ग्राहक जोड़कर इस संख्या को बढ़ा सकते हैं, लेकिन हमें लगता है कि ये संख्याएँ इस लेख के उद्देश्य को स्पष्ट करने के लिए पहले से ही पर्याप्त हैं!

निष्कर्ष

कॉनट्रैक एक महत्वपूर्ण कर्नेल सुविधा है। वह अपना काम बखूबी करता है. इसका उपयोग अक्सर प्रमुख सिस्टम घटकों द्वारा किया जाता है। हालाँकि, कुछ विशिष्ट परिदृश्यों में, कॉनट्रैक के कारण होने वाली भीड़ इसके द्वारा प्रदान किए जाने वाले सामान्य लाभों से अधिक होती है। इस परिदृश्य में, केलिको नेटवर्क नीतियों का उपयोग नेटवर्क सुरक्षा बढ़ाते हुए कॉनट्रैक के उपयोग को चुनिंदा रूप से अक्षम करने के लिए किया जा सकता है। अन्य सभी ट्रैफ़िक के लिए, कॉनट्रैक आपका मित्र बना रहेगा!

हमारे ब्लॉग पर अन्य लेख भी पढ़ें:

• Nginx के लिए गतिशील मॉड्यूल का निर्माण
• हाशिकॉर्प कॉन्सल के कुबेरनेट्स प्राधिकरण का परिचय
• कुबेरनेट्स में स्टेटफुल बैकअप
• बड़ी संख्या में विविध वेब परियोजनाओं का बैकअप
• Redmine के लिए टेलीग्राम बॉट। अपने और दूसरों के जीवन को सरल कैसे बनाएं?

स्रोत: www.habr.com