যখন লিনাক্স কনট্র্যাক আর আপনার বন্ধু থাকে না

সংযোগ ট্র্যাকিং ("কনট্র্যাক") হল লিনাক্স কার্নেল নেটওয়ার্কিং স্ট্যাকের একটি মূল বৈশিষ্ট্য। এটি কার্নেলকে সমস্ত যৌক্তিক নেটওয়ার্ক সংযোগ বা প্রবাহের ট্র্যাক রাখতে এবং এর ফলে প্রতিটি ফ্লো তৈরি করে এমন সমস্ত প্যাকেট সনাক্ত করতে দেয় যাতে সেগুলি ক্রমানুসারে একসাথে প্রক্রিয়া করা যায়।

Conntrack একটি গুরুত্বপূর্ণ কার্নেল বৈশিষ্ট্য যা কিছু মৌলিক ক্ষেত্রে ব্যবহৃত হয়:

• NAT কনট্র্যাকের তথ্যের উপর নির্ভর করে তাই এটি একই স্ট্রিম থেকে সমস্ত প্যাকেটকে সমানভাবে ব্যবহার করতে পারে। উদাহরণস্বরূপ, যখন একটি পড একটি Kubernetes পরিষেবা অ্যাক্সেস করে, তখন kube-proxy লোড ব্যালেন্সার NAT ব্যবহার করে ক্লাস্টারের মধ্যে একটি নির্দিষ্ট পডে ট্র্যাফিক পরিচালনা করতে। কনট্র্যাক রেকর্ড করে যে একটি প্রদত্ত সংযোগের জন্য, আইপি পরিষেবার সমস্ত প্যাকেট একই পডে পাঠাতে হবে, এবং ব্যাকএন্ড পড দ্বারা ফিরে আসা প্যাকেটগুলি অবশ্যই সেই পডে NAT করতে হবে যেখান থেকে অনুরোধ এসেছে৷
• ক্যালিকোর মতো রাষ্ট্রীয় ফায়ারওয়ালগুলি কানেক্টট্র্যাক থেকে হোয়াইটলিস্ট "প্রতিক্রিয়া" ট্র্যাফিকের তথ্যের উপর নির্ভর করে। এটি আপনাকে একটি নেটওয়ার্ক নীতি লিখতে দেয় যা বলে যে "আমার পডকে যেকোনো দূরবর্তী আইপি ঠিকানার সাথে সংযোগ করতে অনুমতি দিন" স্পষ্টভাবে প্রতিক্রিয়া ট্র্যাফিকের অনুমতি দেওয়ার জন্য একটি নীতি লিখতে হবে না। (এটি ছাড়া, আপনাকে অনেক কম নিরাপদ "যেকোন আইপি থেকে আমার পডে প্যাকেটের অনুমতি দিন" নিয়ম যোগ করতে হবে।)

উপরন্তু, কনট্র্যাক সাধারণত সিস্টেমের কর্মক্ষমতা উন্নত করে (সিপিইউ খরচ এবং প্যাকেট লেটেন্সি কমিয়ে) যেহেতু একটি স্ট্রীমের প্রথম প্যাকেট
এটির সাথে কী করতে হবে তা নির্ধারণ করতে পুরো নেটওয়ার্ক স্ট্যাকের মধ্য দিয়ে যেতে হবে। পোস্ট দেখুন"কুবে-প্রক্সি মোডের তুলনা" এটি কিভাবে কাজ করে তার একটি উদাহরণ দেখতে।

যাইহোক, কনট্র্যাকের সীমাবদ্ধতা আছে...

তাই যেখানে সব ভুল হয়ে যেতে হয়নি?

কনট্র্যাক টেবিলের একটি কনফিগারযোগ্য সর্বাধিক আকার রয়েছে এবং এটি পূর্ণ হলে, সংযোগগুলি সাধারণত প্রত্যাখ্যান বা বাদ দেওয়া শুরু করে। বেশিরভাগ অ্যাপ্লিকেশনের ট্র্যাফিক পরিচালনা করার জন্য টেবিলে পর্যাপ্ত ফাঁকা জায়গা রয়েছে এবং এটি কখনই সমস্যা হয়ে উঠবে না। যাইহোক, কিছু পরিস্থিতিতে আপনি conntrack টেবিল ব্যবহার বিবেচনা করতে চাইতে পারেন:

• সবচেয়ে সুস্পষ্ট ক্ষেত্রে যদি আপনার সার্ভার একযোগে সক্রিয় সংযোগগুলির একটি অত্যন্ত বড় সংখ্যা পরিচালনা করে। উদাহরণস্বরূপ, যদি আপনার কনট্র্যাক টেবিলটি 128k এন্ট্রির জন্য কনফিগার করা হয়, কিন্তু আপনার কাছে > 128k সমবর্তী সংযোগ থাকে, তাহলে আপনি অবশ্যই একটি সমস্যায় পড়বেন!
• একটি সামান্য কম সুস্পষ্ট ক্ষেত্রে: যদি আপনার সার্ভার প্রতি সেকেন্ডে একটি খুব বড় সংখ্যক সংযোগ প্রক্রিয়া করে। সংযোগগুলি স্বল্পস্থায়ী হলেও, কিছু সময়ের জন্য (ডিফল্টরূপে 120s) লিনাক্স দ্বারা তাদের পর্যবেক্ষণ করা অব্যাহত থাকে। উদাহরণস্বরূপ, যদি আপনার কনট্র্যাক টেবিলটি 128k এন্ট্রির জন্য কনফিগার করা থাকে এবং আপনি প্রতি সেকেন্ডে 1100টি সংযোগ পরিচালনা করার চেষ্টা করছেন, তাহলে সংযোগগুলি খুব স্বল্পস্থায়ী হলেও সেগুলি কনট্র্যাক টেবিলের আকারকে অতিক্রম করবে (128k/120s = 1092 সংযোগ/ s)।

এই বিভাগগুলির মধ্যে পড়ে এমন বেশ কয়েকটি বিশেষ ধরণের অ্যাপ রয়েছে। অতিরিক্তভাবে, আপনার যদি অনেক খারাপ অভিনেতা থাকে, তবে আপনার সার্ভারের কনট্র্যাক টেবিলটি প্রচুর অর্ধ-খোলা সংযোগ দিয়ে পূরণ করা পরিষেবা অস্বীকার (DOS) আক্রমণের অংশ হিসাবে ব্যবহার করা যেতে পারে। উভয় ক্ষেত্রেই, কনট্র্যাক আপনার সিস্টেমে একটি সীমাবদ্ধ বাধা হয়ে উঠতে পারে। কিছু ক্ষেত্রে, কনট্র্যাক টেবিলের পরামিতিগুলি সামঞ্জস্য করা আপনার প্রয়োজন মেটানোর জন্য যথেষ্ট হতে পারে - আকার বাড়িয়ে বা কনট্র্যাক টাইমআউট হ্রাস করে (কিন্তু আপনি যদি এটি ভুল করেন তবে আপনি অনেক সমস্যায় পড়বেন)। অন্যান্য ক্ষেত্রে আক্রমনাত্মক ট্র্যাফিকের জন্য কনট্র্যাক বাইপাস করা প্রয়োজন।

বাস্তব উদাহরণ

একটি সুনির্দিষ্ট উদাহরণ দেওয়া যাক: একটি বড় SaaS প্রদানকারীর সাথে আমরা কাজ করেছি হোস্টে (ভার্চুয়াল মেশিন নয়) অনেকগুলি মেমক্যাশ সার্ভার রয়েছে, যার প্রতিটি প্রতি সেকেন্ডে 50K+ স্বল্প-মেয়াদী সংযোগগুলি প্রক্রিয়া করেছে৷

তারা কন্ট্রাক কনফিগারেশন নিয়ে পরীক্ষা-নিরীক্ষা করে, টেবিলের আকার বাড়ায় এবং ট্র্যাকিং টাইম কমিয়ে দেয়, কিন্তু কনফিগারেশনটি অবিশ্বস্ত ছিল, RAM খরচ উল্লেখযোগ্যভাবে বেড়ে গিয়েছিল, যা একটি সমস্যা ছিল (GBytes-এর ক্রম অনুসারে!), এবং সংযোগগুলি এত ছোট ছিল যে conntrack করেনি। এর স্বাভাবিক কর্মক্ষমতা সুবিধা তৈরি করুন (কমিত খরচ CPU বা প্যাকেট লেটেন্সি)।

তারা বিকল্প হিসেবে ক্যালিকোর দিকে ঝুঁকেছে। ক্যালিকো নেটওয়ার্ক নীতিগুলি আপনাকে নির্দিষ্ট ধরণের ট্র্যাফিকের জন্য কনট্র্যাক ব্যবহার না করার অনুমতি দেয় (doNotTrack নীতি বিকল্প ব্যবহার করে)। এটি তাদের প্রয়োজনীয় কর্মক্ষমতার স্তর এবং ক্যালিকো দ্বারা প্রদত্ত নিরাপত্তার অতিরিক্ত স্তর দিয়েছে।

কনট্র্যাক বাইপাস করতে আপনাকে কোন দৈর্ঘ্যে যেতে হবে?

• ট্র্যাক করবেন না নেটওয়ার্ক নীতিগুলি সাধারণত প্রতিসম হওয়া উচিত৷ SaaS প্রদানকারীর ক্ষেত্রে: তাদের অ্যাপ্লিকেশনগুলি সুরক্ষিত অঞ্চলের মধ্যে চলেছিল এবং তাই, নেটওয়ার্ক নীতি ব্যবহার করে, তারা মেমক্যাশে অ্যাক্সেসের অনুমতি দেওয়া অন্যান্য নির্দিষ্ট অ্যাপ্লিকেশন থেকে ট্র্যাফিককে সাদা তালিকাভুক্ত করতে পারে।
• ডো-নট-ট্র্যাক নীতি সংযোগের দিক বিবেচনা করে না। এইভাবে, যদি মেমক্যাশেড সার্ভারটি হ্যাক করা হয়, আপনি তাত্ত্বিকভাবে মেমক্যাশেড ক্লায়েন্টগুলির সাথে সংযোগ করার চেষ্টা করতে পারেন, যতক্ষণ না এটি সঠিক উত্স পোর্ট ব্যবহার করে। যাইহোক, আপনি যদি আপনার মেমক্যাশেড ক্লায়েন্টদের জন্য নেটওয়ার্ক নীতি সঠিকভাবে সংজ্ঞায়িত করে থাকেন, তাহলে এই সংযোগ প্রচেষ্টাগুলি ক্লায়েন্টের পক্ষ থেকে প্রত্যাখ্যান করা হবে।
• ডু-নট-ট্র্যাক নীতিটি প্রতিটি প্যাকেটে প্রয়োগ করা হয়, স্বাভাবিক নীতির বিপরীতে, যা শুধুমাত্র একটি প্রবাহের প্রথম প্যাকেটে প্রয়োগ করা হয়। এটি প্রতি প্যাকেটের সিপিইউ খরচ বাড়াতে পারে কারণ প্রতিটি প্যাকেটের জন্য নীতি অবশ্যই প্রয়োগ করতে হবে। কিন্তু স্বল্পস্থায়ী সংযোগের জন্য, এই খরচ কনট্র্যাক প্রক্রিয়াকরণের জন্য সম্পদ খরচ হ্রাস দ্বারা ভারসাম্যপূর্ণ। উদাহরণস্বরূপ, একটি SaaS প্রদানকারীর ক্ষেত্রে, প্রতিটি সংযোগের জন্য প্যাকেটের সংখ্যা খুব কম ছিল, তাই প্রতিটি প্যাকেটে নীতি প্রয়োগ করার সময় অতিরিক্ত CPU খরচ ন্যায়সঙ্গত ছিল।

পরীক্ষা শুরু করা যাক

আমরা একটি মেমক্যাশেড সার্ভার এবং একাধিক মেমক্যাশেড ক্লায়েন্ট পড দিয়ে রিমোট নোডগুলিতে পরীক্ষা চালিয়েছি, তাই আমরা প্রতি সেকেন্ডে খুব বড় সংখ্যক সংযোগ চালাতে পারি। মেমক্যাশেড সার্ভার পড সহ সার্ভারের কনট্র্যাক টেবিলে 8টি কোর এবং 512k এন্ট্রি ছিল (হোস্টের জন্য মানক কনফিগার করা টেবিলের আকার)।
আমরা এর মধ্যে পারফরম্যান্সের পার্থক্য পরিমাপ করেছি: নেটওয়ার্ক নীতি নেই; নিয়মিত ক্যালিকো নীতি সহ; এবং ক্যালিকো ডু-নট-ট্র্যাক নীতি।

প্রথম পরীক্ষার জন্য, আমরা প্রতি সেকেন্ডে সংযোগের সংখ্যা 4.000 সেট করেছি, যাতে আমরা CPU খরচের পার্থক্যের উপর ফোকাস করতে পারি। নো পলিসি এবং রেগুলার পলিসির মধ্যে কোন উল্লেখযোগ্য পার্থক্য ছিল না, কিন্তু ডু-নট-ট্র্যাক সিপিইউ খরচ প্রায় 20% বৃদ্ধি পেয়েছে:

দ্বিতীয় পরীক্ষায়, আমাদের ক্লায়েন্টরা যতগুলি সংযোগ তৈরি করতে পারে আমরা ততগুলি সংযোগ চালু করেছি এবং প্রতি সেকেন্ডে সর্বাধিক সংখ্যক সংযোগ পরিমাপ করেছি যা আমাদের মেমক্যাশ সার্ভার পরিচালনা করতে পারে। প্রত্যাশিত হিসাবে, "কোন নীতি নেই" এবং "নিয়মিত নীতি" উভয় ক্ষেত্রেই প্রতি সেকেন্ডে 4,000 এর বেশি সংযোগের কনট্র্যাক সীমা পৌঁছেছে (512k/120s = 4,369 সংযোগ/s)। ডু-নট-ট্র্যাক নীতির মাধ্যমে, আমাদের ক্লায়েন্টরা প্রতি সেকেন্ডে 60,000টি সংযোগ পাঠাতেন কোনো সমস্যা ছাড়াই। আমরা নিশ্চিত যে আমরা আরও ক্লায়েন্ট যোগ করার মাধ্যমে এই সংখ্যা বাড়াতে পারব, কিন্তু আমরা মনে করি এই সংখ্যাগুলি ইতিমধ্যেই এই নিবন্ধের বিষয়টি বোঝানোর জন্য যথেষ্ট!

উপসংহার

Conntrack একটি গুরুত্বপূর্ণ কার্নেল বৈশিষ্ট্য। সে তার কাজ নিখুঁতভাবে করে। এটি প্রায়শই মূল সিস্টেম উপাদান দ্বারা ব্যবহৃত হয়। যাইহোক, কিছু নির্দিষ্ট পরিস্থিতিতে, কনট্র্যাকের কারণে যানজট স্বাভাবিক সুবিধার চেয়ে বেশি। এই পরিস্থিতিতে, ক্যালিকো নেটওয়ার্ক নীতিগুলি নেটওয়ার্ক নিরাপত্তা বাড়ানোর সময় কনট্র্যাকের ব্যবহার বেছে বেছে অক্ষম করতে ব্যবহার করা যেতে পারে। অন্যান্য সমস্ত ট্রাফিকের জন্য, কনট্র্যাক আপনার বন্ধু হতে চলেছে!

এছাড়াও আমাদের ব্লগে অন্যান্য নিবন্ধ পড়ুন:

• Nginx এর জন্য গতিশীল মডিউল তৈরি করা
• Hashicorp কনসাল এর Kubernetes অনুমোদনের ভূমিকা
• কুবারনেটে স্টেটফুল ব্যাকআপ
• বিপুল সংখ্যক ভিন্নধর্মী ওয়েব প্রকল্পের ব্যাকআপ
• রেডমাইনের জন্য টেলিগ্রাম বট। কীভাবে নিজের এবং অন্যদের জীবনকে সহজ করা যায়

উত্স: www.habr.com