जेव्हा लिनक्स कॉन्ट्रॅक यापुढे तुमचा मित्र नाही

कनेक्शन ट्रॅकिंग (“कॉन्ट्रॅक”) हे लिनक्स कर्नल नेटवर्किंग स्टॅकचे मुख्य वैशिष्ट्य आहे. हे कर्नलला सर्व तार्किक नेटवर्क कनेक्शन किंवा प्रवाहांचा मागोवा ठेवण्यास अनुमती देते आणि त्याद्वारे प्रत्येक प्रवाह बनवणारे सर्व पॅकेट ओळखतात जेणेकरुन ते अनुक्रमे एकत्रितपणे प्रक्रिया करता येतील.

कॉन्ट्रॅक हे एक महत्त्वाचे कर्नल वैशिष्ट्य आहे जे काही मूलभूत प्रकरणांमध्ये वापरले जाते:

• NAT conntrack कडील माहितीवर अवलंबून असते त्यामुळे ते समान प्रवाहातील सर्व पॅकेटस समान रीतीने हाताळू शकते. उदाहरणार्थ, जेव्हा पॉड कुबर्नेट्स सेवेमध्ये प्रवेश करतो, तेव्हा क्यूबे-प्रॉक्सी लोड बॅलन्सर क्लस्टरमधील विशिष्ट पॉडवर रहदारी निर्देशित करण्यासाठी NAT वापरतो. कॉन्ट्रॅक रेकॉर्ड करतो की दिलेल्या कनेक्शनसाठी, आयपी सेवेतील सर्व पॅकेट त्याच पॉडवर पाठवले जाणे आवश्यक आहे आणि बॅकएंड पॉडद्वारे परत आलेले पॅकेट्स ज्या पॉडमधून विनंती आली आहे त्या पॉडवर परत NAT करणे आवश्यक आहे.
• कॅलिको सारख्या स्टेटफुल फायरवॉल कनेक्टट्रॅकपासून व्हाइटलिस्ट "प्रतिसाद" रहदारीपर्यंतच्या माहितीवर अवलंबून असतात. हे तुम्हाला रिस्पॉन्स ट्रॅफिकला स्पष्टपणे अनुमती देण्यासाठी धोरण न लिहिता "माझ्या पॉडला कोणत्याही रिमोट आयपी पत्त्याशी कनेक्ट करण्याची परवानगी द्या" असे नेटवर्क धोरण लिहू देते. (याशिवाय, तुम्हाला "कोणत्याही IP वरून माझ्या पॉडमध्ये पॅकेट्सना परवानगी द्या" हा कमी सुरक्षित नियम जोडावा लागेल.)

याव्यतिरिक्त, कॉन्ट्रॅक सामान्यत: स्ट्रीममधील पहिल्या पॅकेटपासून सिस्टम कार्यप्रदर्शन (CPU वापर आणि पॅकेट लेटन्सी कमी करून) सुधारते
त्याचे काय करायचे हे निर्धारित करण्यासाठी संपूर्ण नेटवर्क स्टॅकमधून जाणे आवश्यक आहे. पोस्ट पहा "कुबे-प्रॉक्सी मोडची तुलना"ते कसे कार्य करते याचे उदाहरण पाहण्यासाठी.

तथापि, कॉन्ट्रॅकच्या मर्यादा आहेत ...

मग हे सर्व कुठे चुकले?

कॉन्ट्रॅक टेबलमध्ये कॉन्फिगर करता येण्याजोगा कमाल आकार असतो आणि तो पूर्ण भरल्यास, कनेक्शन सहसा नाकारले जाऊ लागतात किंवा सोडले जातात. बहुतेक ऍप्लिकेशन्सची रहदारी हाताळण्यासाठी टेबलमध्ये पुरेशी मोकळी जागा आहे आणि ही कधीही समस्या होणार नाही. तथापि, काही परिस्थिती आहेत ज्यात तुम्ही कॉन्ट्रॅक टेबल वापरण्याचा विचार करू शकता:

• तुमचा सर्व्हर एकाचवेळी सक्रिय कनेक्शन्सची अत्यंत मोठ्या संख्येने हाताळणी करत असल्यास सर्वात स्पष्ट केस आहे. उदाहरणार्थ, जर तुमचे कॉन्ट्रॅक टेबल 128k नोंदींसाठी कॉन्फिगर केले असेल, परंतु तुमच्याकडे > 128k समवर्ती कनेक्शन असतील, तर तुम्हाला नक्कीच समस्या येईल!
• थोडेसे कमी स्पष्ट प्रकरण: जर तुमचा सर्व्हर प्रति सेकंद खूप मोठ्या संख्येने कनेक्शन प्रक्रिया करत असेल. जरी कनेक्‍शन अल्पायुषी असले तरी, काही कालावधीसाठी (120s by default) Linux द्वारे त्यांचे परीक्षण केले जात असते. उदाहरणार्थ, जर तुमचा कॉन्ट्रॅक टेबल 128k एंट्रीसाठी कॉन्फिगर केला असेल आणि तुम्ही प्रति सेकंद 1100 कनेक्शन हाताळण्याचा प्रयत्न करत असाल, तर ते कॉन्ट्रॅक टेबलचा आकार ओलांडतील जरी कनेक्शन फारच अल्पकालीन असतील (128k/120s = 1092 कनेक्शन/से ).

या श्रेणींमध्ये येणारे अनेक विशिष्ट प्रकारचे अॅप्स आहेत. याव्यतिरिक्त, जर तुमच्याकडे खूप वाईट कलाकार असतील, तर तुमच्या सर्व्हरचे कॉन्ट्रॅक टेबल भरपूर अर्ध्या-ओपन कनेक्शनसह भरणे हे सेवा नाकारण्याच्या (DOS) हल्ल्याचा भाग म्हणून वापरले जाऊ शकते. दोन्ही प्रकरणांमध्ये, कॉन्ट्रॅक तुमच्या सिस्टममध्ये मर्यादित अडथळे बनू शकते. काही प्रकरणांमध्ये, कॉन्ट्रॅक टेबल पॅरामीटर्स समायोजित करणे तुमच्या गरजा पूर्ण करण्यासाठी पुरेसे असू शकते - आकार वाढवून किंवा कॉन्ट्रॅक टाइमआउट्स कमी करून (परंतु जर तुम्ही ते चुकीचे केले तर तुम्हाला खूप त्रास होईल). इतर प्रकरणांसाठी आक्रमक रहदारीसाठी कॉन्ट्रॅक बायपास करणे आवश्यक असेल.

खरे उदाहरण

चला एक विशिष्ट उदाहरण देऊ: आम्ही काम केलेल्या एका मोठ्या SaaS प्रदात्याकडे होस्ट्सवर (व्हर्च्युअल मशीन नसून) मेमकॅशेड सर्व्हर आहेत, ज्यापैकी प्रत्येकाने प्रति सेकंद 50K+ अल्प-मुदतीच्या कनेक्शनवर प्रक्रिया केली.

त्यांनी कॉन्ट्रॅक कॉन्फिगरेशनसह प्रयोग केले, टेबलचा आकार वाढवला आणि ट्रॅकिंगची वेळ कमी केली, परंतु कॉन्फिगरेशन अविश्वसनीय होते, रॅमचा वापर लक्षणीय वाढला, जी एक समस्या होती (जीबीबाईट्सच्या क्रमाने!), आणि कनेक्शन इतके लहान होते की कॉन्ट्रॅकने ते केले नाही. त्याचे नेहमीचे कार्यप्रदर्शन लाभ तयार करा (कमी वापर CPU किंवा पॅकेट विलंब).

पर्याय म्हणून ते कॅलिकोकडे वळले. कॅलिको नेटवर्क धोरणे तुम्हाला विशिष्ट प्रकारच्या रहदारीसाठी (doNotTrack धोरण पर्याय वापरून) कॉन्ट्रॅक न वापरण्याची परवानगी देतात. यामुळे त्यांना आवश्यक कार्यप्रदर्शनाची पातळी मिळाली, तसेच कॅलिकोने प्रदान केलेली सुरक्षा अतिरिक्त पातळी दिली.

बायपास कॉन्ट्रॅकसाठी तुम्हाला कोणत्या लांबीपर्यंत जावे लागेल?

• डू-नॉट-ट्रॅक नेटवर्क धोरणे साधारणपणे सममितीय असावीत. SaaS प्रदात्याच्या बाबतीत: त्यांचे ऍप्लिकेशन संरक्षित झोनमध्ये गेले आणि म्हणून, नेटवर्क धोरण वापरून, ते इतर विशिष्ट ऍप्लिकेशन्सच्या रहदारीला श्वेतसूचीबद्ध करू शकतात ज्यांना memcached मध्ये प्रवेश करण्याची परवानगी आहे.
• डू-नॉट-ट्रॅक धोरण कनेक्शनची दिशा विचारात घेत नाही. अशाप्रकारे, जर मेमकॅशेड सर्व्हर हॅक झाला असेल, तर तुम्ही तात्त्विकदृष्ट्या कोणत्याही मेमकॅशेड क्लायंटशी कनेक्ट करण्याचा प्रयत्न करू शकता, जोपर्यंत तो योग्य स्त्रोत पोर्ट वापरत आहे. तथापि, जर तुम्ही तुमच्या मेमकॅशेड क्लायंटसाठी नेटवर्क धोरण योग्यरित्या परिभाषित केले असेल, तर हे कनेक्शन प्रयत्न क्लायंटच्या बाजूने नाकारले जातील.
• डू-नॉट-ट्रॅक धोरण प्रत्येक पॅकेटवर लागू केले जाते, सामान्य धोरणांच्या विरूद्ध, जे फक्त प्रवाहातील पहिल्या पॅकेटवर लागू केले जाते. हे प्रति पॅकेट CPU वापर वाढवू शकते कारण प्रत्येक पॅकेटसाठी पॉलिसी लागू करणे आवश्यक आहे. परंतु अल्पकालीन कनेक्शनसाठी, हा खर्च कॉन्ट्रॅक प्रक्रियेसाठी स्त्रोत वापर कमी करून संतुलित केला जातो. उदाहरणार्थ, SaaS प्रदात्याच्या बाबतीत, प्रत्येक कनेक्शनसाठी पॅकेट्सची संख्या खूपच कमी होती, म्हणून प्रत्येक पॅकेटवर धोरणे लागू करताना अतिरिक्त CPU वापर न्याय्य होता.

चला चाचणी सुरू करूया

आम्ही एकाच पॉडवर मेमकॅशेड सर्व्हरसह चाचणी केली आणि रिमोट नोड्सवर चालणार्‍या एकाधिक मेमकॅशेड क्लायंट पॉड्ससह आम्ही प्रति सेकंद खूप मोठ्या संख्येने कनेक्शन चालवू शकलो. मेमकॅशेड सर्व्हर पॉड असलेल्या सर्व्हरमध्ये कॉन्ट्रॅक टेबलमध्ये 8 कोर आणि 512k नोंदी होत्या (होस्टसाठी मानक कॉन्फिगर केलेले टेबल आकार).
आम्ही यामधील कामगिरी फरक मोजला: नेटवर्क धोरण नाही; नियमित कॅलिको पॉलिसीसह; आणि कॅलिको डू-नॉट-ट्रॅक धोरण.

पहिल्या चाचणीसाठी, आम्ही कनेक्शनची संख्या प्रति सेकंद 4.000 वर सेट केली, जेणेकरून आम्ही CPU वापरातील फरकावर लक्ष केंद्रित करू शकू. नो पॉलिसी आणि रेग्युलर पॉलिसीमध्ये कोणतेही महत्त्वपूर्ण फरक नव्हते, परंतु डू-नॉट-ट्रॅकमुळे CPU वापर सुमारे 20% वाढला:

दुस-या चाचणीमध्ये, आमचे क्लायंट जेवढे कनेक्शन निर्माण करू शकत होते तितके आम्ही लाँच केले आणि आमचे मेमकॅशेड सर्व्हर हाताळू शकतील अशा जास्तीत जास्त कनेक्शनची संख्या प्रति सेकंद मोजली. अपेक्षेप्रमाणे, "कोणतेही धोरण नाही" आणि "नियमित धोरण" प्रकरणे दोन्ही प्रति सेकंद 4,000 पेक्षा जास्त कनेक्शनची कॉन्ट्रॅक मर्यादा गाठली (512k / 120s = 4,369 कनेक्शन/से). डू-नॉट-ट्रॅक धोरणासह, आमच्या क्लायंटने कोणत्याही समस्यांशिवाय प्रति सेकंद 60,000 कनेक्शन पाठवले. आम्हाला खात्री आहे की आम्ही अधिक क्लायंट जोडून ही संख्या वाढवू शकतो, परंतु आम्हाला वाटते की या लेखाचा मुद्दा स्पष्ट करण्यासाठी ही संख्या आधीच पुरेशी आहे!

निष्कर्ष

कॉन्ट्रॅक हे कर्नलचे महत्त्वाचे वैशिष्ट्य आहे. तो त्याचे काम चोख करतो. हे बर्याचदा मुख्य सिस्टम घटकांद्वारे वापरले जाते. तथापि, काही विशिष्ट परिस्थितींमध्ये, कॉन्ट्रॅकमुळे होणारी गर्दी हे प्रदान केलेल्या सामान्य फायद्यांपेक्षा जास्त असते. या परिस्थितीत, कॅलिको नेटवर्क धोरणे नेटवर्क सुरक्षा वाढवताना कॉन्ट्रॅकचा वापर निवडकपणे अक्षम करण्यासाठी वापरली जाऊ शकतात. इतर सर्व ट्रॅफिकसाठी, कॉन्ट्रॅक तुमचा मित्र आहे!

आमच्या ब्लॉगवरील इतर लेख देखील वाचा:

• Nginx साठी डायनॅमिक मॉड्यूल तयार करणे
• Hashicorp Consul च्या Kubernetes Authorization चा परिचय
• Kubernetes मध्ये स्टेटफुल बॅकअप
• मोठ्या संख्येने विषम वेब प्रकल्पांचा बॅकअप
• रेडमाइनसाठी टेलीग्राम बॉट. स्वतःसाठी आणि इतरांसाठी जीवन कसे सोपे करावे

स्त्रोत: www.habr.com