একটি নেটওয়ার্ক যা নিজেকে নিরাময় করে: ফ্লো লেবেলের জাদু এবং লিনাক্স কার্নেলের চারপাশে গোয়েন্দা। ইয়ানডেক্স রিপোর্ট

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

— শুরুতে, আমি তাদের জন্য একটি মোটামুটি বিস্তারিত ভূমিকা দেব যারা একটি আধুনিক ডিসির কাঠামো সম্পর্কে সচেতন নাও হতে পারে।


অনেক নেটওয়ার্ক ইঞ্জিনিয়ারদের জন্য, একটি ডাটা সেন্টার নেটওয়ার্ক শুরু হয়, অবশ্যই, টিওআর সহ, র্যাকের একটি সুইচ সহ। ToR তে সাধারণত দুই ধরনের লিঙ্ক থাকে। ছোটগুলি সার্ভারে যায়, অন্যরা - তাদের মধ্যে N গুণ বেশি - প্রথম স্তরের মেরুদণ্ডের দিকে, অর্থাৎ এর আপলিঙ্কগুলিতে যান৷ আপলিংকগুলিকে সাধারণত সমান হিসাবে বিবেচনা করা হয়, এবং আপলিংকগুলির মধ্যে ট্র্যাফিক 5-টুপলের হ্যাশের উপর ভিত্তি করে ভারসাম্যপূর্ণ হয়, যার মধ্যে রয়েছে প্রোটো, src_ip, dst_ip, src_port, dst_port। এখানে কোন চমক নেই.


পরবর্তী, পরিকল্পনা স্থাপত্য কেমন দেখায়? প্রথম স্তরের কাঁটাগুলি একে অপরের সাথে সংযুক্ত নয়, তবে সুপারস্পাইনের মাধ্যমে সংযুক্ত থাকে। X অক্ষরটি সুপারস্পাইনের জন্য দায়ী হবে; এটি প্রায় একটি ক্রস-সংযোগের মতো।


এবং এটি স্পষ্ট যে, অন্যদিকে, টরি প্রথম স্তরের সমস্ত মেরুদণ্ডের সাথে সংযুক্ত। এই ছবিতে গুরুত্বপূর্ণ কি? যদি আমাদের র্যাকের ভিতরে মিথস্ক্রিয়া থাকে, তবে মিথস্ক্রিয়াটি অবশ্যই ToR এর মাধ্যমে যায়। যদি মিথস্ক্রিয়াটি মডিউলের ভিতরে ঘটে, তবে মিথস্ক্রিয়াটি প্রথম স্তরের মেরুদণ্ডের মাধ্যমে ঘটে। যদি মিথস্ক্রিয়াটি ইন্টারমডুলার হয় - যেমন এখানে, ToR 1 এবং ToR 2 - তাহলে মিথস্ক্রিয়াটি প্রথম এবং দ্বিতীয় উভয় স্তরের মেরুদণ্ডের মধ্য দিয়ে যাবে।


তাত্ত্বিকভাবে, এই জাতীয় স্থাপত্য সহজেই মাপযোগ্য। আমাদের যদি বন্দরের ক্ষমতা, ডেটা সেন্টারে অতিরিক্ত জায়গা এবং প্রি-লেইড ফাইবার থাকে, তাহলে লেনের সংখ্যা সবসময় বাড়ানো যেতে পারে, যার ফলে সিস্টেমের সামগ্রিক ক্ষমতা বৃদ্ধি পায়। এটি কাগজে করা খুব সহজ। জীবনে এমন হবে। তবে আজকের গল্পটি সে সম্পর্কে নয়।


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


আটটি প্লেন রয়েছে, প্রতিটি প্লেনে 32টি সুপারস্পাইন রয়েছে। ফলস্বরূপ, দেখা যাচ্ছে যে মডিউলটির ভিতরে আটটি পথ রয়েছে এবং ইন্টারমডিউল মিথস্ক্রিয়া সহ ইতিমধ্যে তাদের মধ্যে 256টি রয়েছে।

অর্থাৎ, আমরা যদি কুকবুক তৈরি করি, কীভাবে ত্রুটি-সহনশীল ডেটা সেন্টার তৈরি করতে হয় যা নিজেদের নিরাময় করতে হয় তা শেখার চেষ্টা করছি, তাহলে প্ল্যানার আর্কিটেকচার হল সঠিক পছন্দ। এটি স্কেলিং সমস্যা সমাধান করে, এবং তাত্ত্বিকভাবে এটি সহজ। অনেক স্বাধীন পথ আছে। প্রশ্ন থেকে যায়: কিভাবে এই ধরনের একটি স্থাপত্য ব্যর্থতা থেকে বেঁচে থাকে? বিভিন্ন ব্যর্থতা আছে। এবং আমরা এখন এই বিষয়ে আলোচনা করব।


আমাদের সুপারস্পাইনদের একজনকে "অসুস্থ হতে দিন"। এখানে আমি দুই প্লেন স্থাপত্য ফিরে. আমরা উদাহরণ হিসেবে এগুলোর সাথে থাকব কারণ কম চলমান অংশের সাথে কী ঘটছে তা দেখা সহজ হবে। X11 অসুস্থ হতে দিন. ডেটা সেন্টারের ভিতরে থাকা পরিষেবাগুলিকে কীভাবে এটি প্রভাবিত করবে? ব্যর্থতা আসলে কেমন দেখায় তার উপর অনেক কিছু নির্ভর করে।


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


একটি খারাপ পরিস্থিতি হল যদি আমাদের ক্রমাগত ক্ষতি হয় এবং অটোমেশন সমস্যাটি লক্ষ্য করে না। এটি কীভাবে একটি অ্যাপ্লিকেশনকে প্রভাবিত করে তা বোঝার জন্য, TCP কীভাবে কাজ করে তা নিয়ে আলোচনা করতে আমাদের একটু সময় ব্যয় করতে হবে।


আমি আশা করি আমি এই তথ্য দিয়ে কাউকে হতবাক করব না: TCP একটি ট্রান্সমিশন নিশ্চিতকরণ প্রোটোকল। অর্থাৎ, সবচেয়ে সহজ ক্ষেত্রে, প্রেরক দুটি প্যাকেট পাঠান এবং তাদের উপর একটি ক্রমবর্ধমান ack গ্রহণ করেন: "আমি দুটি প্যাকেট পেয়েছি।"


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


আমরা প্যাকেট 3 হারিয়ে ফেললে কি হবে? এই ক্ষেত্রে, প্রাপক 1, 2 এবং 4 প্যাকেট পাবেন। এবং তিনি SACK বিকল্পটি ব্যবহার করে প্রেরককে স্পষ্টভাবে বলবেন: "আপনি জানেন, তিনটি এসেছে, কিন্তু মাঝখানে হারিয়ে গেছে।" তিনি বলেন, "Ack 2, SACK 4।"


এই মুহুর্তে, প্রেরক কোন সমস্যা ছাড়াই হারিয়ে যাওয়া প্যাকেটটির পুনরাবৃত্তি করে।


কিন্তু উইন্ডোতে শেষ প্যাকেট হারিয়ে গেলে, পরিস্থিতি সম্পূর্ণ ভিন্ন দেখাবে।

প্রাপক প্রথম তিনটি প্যাকেট পায় এবং প্রথমে অপেক্ষা করতে শুরু করে। লিনাক্স কার্নেলের TCP স্ট্যাকের কিছু অপ্টিমাইজেশনের জন্য ধন্যবাদ, এটি একটি জোড়া প্যাকেটের জন্য অপেক্ষা করবে যদি না পতাকাগুলি স্পষ্টভাবে নির্দেশ করে যে এটি শেষ প্যাকেট বা অনুরূপ কিছু। এটি বিলম্বিত ACK সময়সীমা শেষ না হওয়া পর্যন্ত অপেক্ষা করবে এবং তারপর প্রথম তিনটি প্যাকেটে একটি স্বীকৃতি পাঠাবে। তবে এখন প্রেরক অপেক্ষা করবে। তিনি জানেন না চতুর্থ প্যাকেজটি হারিয়ে গেছে নাকি আসতে চলেছে। এবং নেটওয়ার্ক ওভারলোড না করার জন্য, এটি প্যাকেটটি হারিয়ে গেছে বা RTO সময়সীমা শেষ হওয়ার জন্য একটি সুস্পষ্ট ইঙ্গিতের জন্য অপেক্ষা করার চেষ্টা করবে।


RTO সময়সীমা কি? এটি TCP স্ট্যাক এবং কিছু ধ্রুবক দ্বারা গণনা করা RTT-এর সর্বাধিক। এটা কি ধরনের ধ্রুবক, আমরা এখন আলোচনা করব।


কিন্তু গুরুত্বপূর্ণ বিষয় হল যদি আমরা আবার দুর্ভাগ্যবান হই এবং চতুর্থ প্যাকেটটি আবার হারিয়ে যায়, তাহলে আরটিও দ্বিগুণ হয়ে যায়। অর্থাৎ, প্রতিটি ব্যর্থ প্রচেষ্টার অর্থ হল সময়সীমা দ্বিগুণ করা।


এখন দেখা যাক এই বেস কি সমান। ডিফল্টরূপে, ন্যূনতম RTO হল 200 ms। এটি ডেটা প্যাকেজের জন্য সর্বনিম্ন RTO। SYN প্যাকেটের জন্য এটি আলাদা, 1 সেকেন্ড। আপনি দেখতে পাচ্ছেন, এমনকি প্যাকেট পুনরায় পাঠানোর প্রথম প্রচেষ্টা ডাটা সেন্টারের ভিতরে RTT থেকে 100 গুণ বেশি সময় নেবে।


এখন আমাদের দৃশ্যকল্পে ফিরে আসা যাক। সেবা দিয়ে কি হচ্ছে? পরিষেবাটি প্যাকেট হারাতে শুরু করে। পরিষেবাটিকে প্রথমে শর্তসাপেক্ষে ভাগ্যবান হতে দিন এবং উইন্ডোর মাঝখানে কিছু হারান, তারপর এটি একটি SACK পায় এবং হারিয়ে যাওয়া প্যাকেটগুলি পুনরায় পাঠায়৷


কিন্তু যদি খারাপ ভাগ্যের পুনরাবৃত্তি হয়, তাহলে আমাদের একটি আরটিও আছে। এখানে গুরুত্বপূর্ণ কি? হ্যাঁ, আমাদের নেটওয়ার্কে অনেক পথ আছে। কিন্তু একটি নির্দিষ্ট TCP সংযোগের TCP ট্র্যাফিক একই ভাঙা স্ট্যাকের মধ্য দিয়ে যেতে থাকবে। প্যাকেটের ক্ষতি, শর্ত থাকে যে আমাদের এই জাদুকরী X11 নিজে থেকে বেরিয়ে না যায়, সমস্যাযুক্ত নয় এমন এলাকায় যানবাহন প্রবাহিত হয় না। আমরা একই ভাঙা স্ট্যাকের মাধ্যমে প্যাকেট সরবরাহ করার চেষ্টা করছি। এটি একটি ক্যাসকেডিং ব্যর্থতার দিকে পরিচালিত করে: একটি ডেটা সেন্টার হল ইন্টারঅ্যাক্টিং অ্যাপ্লিকেশনগুলির একটি সেট, এবং এই সমস্ত অ্যাপ্লিকেশনগুলির কিছু টিসিপি সংযোগ হ্রাস পেতে শুরু করে - কারণ সুপারস্পাইন ডেটা সেন্টারের ভিতরে থাকা সমস্ত অ্যাপ্লিকেশনকে প্রভাবিত করে। প্রবাদটি বলে: আপনি যদি ঘোড়াকে জুতা না দেন তবে ঘোড়াটি খোঁড়া হয়ে গেল; ঘোড়া খোঁড়া হয়ে গেল - রিপোর্ট দেওয়া হয়নি; রিপোর্ট দেওয়া হয়নি - আমরা যুদ্ধ হেরেছি। শুধুমাত্র এখানেই গণনা কয়েক সেকেন্ডের মধ্যে সমস্যাটি উদ্ভূত হওয়ার মুহুর্ত থেকে অবনতির পর্যায়ে যা পরিষেবাগুলি অনুভব করতে শুরু করে। এর মানে হল যে ব্যবহারকারীরা কোথাও কিছু মিস করছেন।


দুটি ক্লাসিক সমাধান রয়েছে যা একে অপরের পরিপূরক। প্রথমটি হ'ল পরিষেবাগুলি যা স্ট্র লাগাতে এবং এইভাবে সমস্যার সমাধান করার চেষ্টা করছে: “আসুন টিসিপি স্ট্যাকের মধ্যে কিছু পরিবর্তন করি৷ আসুন অ্যাপ্লিকেশন স্তরে বা অভ্যন্তরীণ স্বাস্থ্য পরীক্ষা সহ দীর্ঘস্থায়ী টিসিপি সেশনে টাইমআউট করি।" সমস্যা হল এই ধরনের সমাধান: ক) মোটেই স্কেল করবেন না; খ) খুব খারাপভাবে পরীক্ষা করা হয়। অর্থাৎ, এমনকি যদি পরিষেবাটি দুর্ঘটনাক্রমে TCP স্ট্যাকটিকে এমনভাবে কনফিগার করে যা এটিকে আরও ভাল করে তোলে, প্রথমত, এটি সমস্ত অ্যাপ্লিকেশন এবং সমস্ত ডেটা সেন্টারের জন্য প্রযোজ্য হওয়ার সম্ভাবনা কম এবং দ্বিতীয়ত, সম্ভবত, এটি বুঝতে পারবে না যে এটি করা হয়েছে সঠিকভাবে, এবং কি না। যে, এটি কাজ করে, কিন্তু এটি খারাপভাবে কাজ করে এবং স্কেল করে না। আর নেটওয়ার্ক সমস্যা হলে দায় কার? অবশ্যই, এনওসি। NOC কি করে?

অনেক পরিষেবা বিশ্বাস করে যে এনওসি কাজের ক্ষেত্রে এরকম কিছু ঘটে। কিন্তু সত্যি বলতে শুধু তাই নয়।


ক্লাসিক্যাল স্কিমে NOC অনেক মনিটরিং সিস্টেমের উন্নয়নে নিযুক্ত। এই দুটি কালো বক্স এবং সাদা বক্স পর্যবেক্ষণ. ব্ল্যাক বক্স মেরুদণ্ড পর্যবেক্ষণ একটি উদাহরণ সম্পর্কে বলা শেষ নেক্সট হপে আলেকজান্ডার ক্লিমেনকো। যাইহোক, এই পর্যবেক্ষণ কাজ করে. কিন্তু এমনকি আদর্শ মনিটরিং একটি সময় ব্যবধান থাকবে. সাধারণত এটি কয়েক মিনিট। এটি বন্ধ হয়ে যাওয়ার পরে, ডিউটিতে থাকা প্রকৌশলীদের এটির ক্রিয়াকলাপ দুবার পরীক্ষা করার জন্য, সমস্যাটিকে স্থানীয়করণ করতে এবং তারপরে সমস্যাটির জায়গাটি নির্বাপিত করার জন্য সময় প্রয়োজন৷ অর্থাৎ, সর্বোত্তম ক্ষেত্রে, সমস্যাটির চিকিত্সা করতে 5 মিনিট সময় লাগে, সবচেয়ে খারাপ ক্ষেত্রে, 20 মিনিট, যদি তা অবিলম্বে স্পষ্ট না হয় যে ক্ষতি কোথায় হয়। এটা স্পষ্ট যে এই সমস্ত সময় - 5 বা 20 মিনিট - আমাদের পরিষেবাগুলি ক্ষতিগ্রস্থ হবে, যা সম্ভবত ভাল নয়৷


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

কিন্তু এখানে একটি nuance আছে. এটি কী তা বোঝার জন্য, আমাদের থ্রেডগুলি কীভাবে প্রতিষ্ঠিত হয় তা দেখতে হবে।


থ্রেডগুলি ক্রমানুসারে ইনস্টল করা হয়। প্রথম থ্রেড প্রথমে ইনস্টল করা হয়। পরবর্তী থ্রেডগুলি তারপর সেই থ্রেডের মধ্যে ইতিমধ্যেই সম্মত হয়েছে এমন কুকি ব্যবহার করে সেট করা হয়। এবং এখানেই সমস্যা।


সমস্যা হল যে যদি প্রথম থ্রেডটি নিজেকে প্রতিষ্ঠিত না করে তবে দ্বিতীয় এবং তৃতীয় থ্রেডটি কখনই উঠবে না। অর্থাৎ, মাল্টিপাথ TCP প্রথম প্রবাহে একটি SYN প্যাকেটের ক্ষতির সমাধান করে না। এবং যদি SYN হারিয়ে যায়, মাল্টিপাথ টিসিপি নিয়মিত টিসিপিতে পরিণত হয়। এর মানে হল যে ডেটা সেন্টারের পরিবেশে এটি আমাদের কারখানায় ক্ষতির সমস্যা সমাধান করতে এবং ব্যর্থতার ক্ষেত্রে একাধিক পথ ব্যবহার করতে শিখতে সাহায্য করবে না।


কি আমাদের সাহায্য করতে পারে? শিরোনাম থেকে আপনারা কেউ কেউ ইতিমধ্যে অনুমান করেছেন যে আমাদের পরবর্তী গল্পের একটি গুরুত্বপূর্ণ ক্ষেত্র হবে IPv6 ফ্লো লেবেল হেডার ক্ষেত্র। প্রকৃতপক্ষে, এটি একটি ক্ষেত্র যা v6 তে প্রদর্শিত হয়, এটি v4 তে নয়, এটি 20 বিট দখল করে এবং এটির ব্যবহার নিয়ে দীর্ঘদিন ধরে বিতর্ক রয়েছে। এটি খুব আকর্ষণীয় - সেখানে বিরোধ ছিল, RFC এর মধ্যে কিছু স্থির করা হয়েছিল এবং একই সময়ে একটি বাস্তবায়ন লিনাক্স কার্নেলে উপস্থিত হয়েছিল, যা কোথাও নথিভুক্ত করা হয়নি।


আমি আপনাকে আমার সাথে একটু তদন্তে যেতে আমন্ত্রণ জানাচ্ছি। চলুন এক নজরে দেখে নেওয়া যাক গত কয়েক বছর ধরে লিনাক্স কার্নেলে কী ঘটছে।

বছর 2014। একটি বড় এবং সম্মানিত কোম্পানির একজন প্রকৌশলী লিনাক্স কার্নেলের কার্যকারিতাকে সকেট হ্যাশে ফ্লো লেবেল মানের নির্ভরতা যোগ করে। তারা এখানে কি ঠিক করার চেষ্টা করছিল? এটি RFC 6438 এর সাথে সম্পর্কিত, যা নিম্নলিখিত বিষয় নিয়ে আলোচনা করেছে। ডেটা সেন্টারের ভিতরে, IPv4 প্রায়ই IPv6 প্যাকেটে এনক্যাপসুলেট করা হয়, কারণ ফ্যাক্টরিটি নিজেই IPv6, কিন্তু IPv4 অবশ্যই বাইরে দিতে হবে। দীর্ঘ সময় ধরে সুইচগুলির সাথে সমস্যা ছিল যা TCP বা UDP-তে যেতে এবং সেখানে src_ports, dst_ports খুঁজে পেতে দুটি আইপি হেডারের নীচে দেখতে পারেনি। দেখা গেল যে হ্যাশ, যদি আপনি প্রথম দুটি আইপি হেডার তাকান, প্রায় স্থির হয়ে গেছে। এটি এড়াতে, যাতে এই এনক্যাপসুলেটেড ট্র্যাফিকের ভারসাম্য সঠিকভাবে কাজ করে, ফ্লো লেবেল ক্ষেত্রের মানের সাথে 5-টুপল এনক্যাপসুলেটেড প্যাকেটের হ্যাশ যুক্ত করার প্রস্তাব করা হয়েছিল। প্রায় একই জিনিস অন্যান্য এনক্যাপসুলেশন স্কিমের জন্য করা হয়েছিল, UDP-এর জন্য, GRE-এর জন্য, পরবর্তীতে GRE কী ক্ষেত্র ব্যবহার করা হয়েছিল। এক বা অন্য উপায়, এখানে লক্ষ্য পরিষ্কার. এবং অন্তত সেই সময়ে তারা দরকারী ছিল।

2015 সালে, একই সম্মানিত প্রকৌশলীর কাছ থেকে একটি নতুন প্যাচ আসে। তিনি খুব আকর্ষণীয়. এটি নিম্নলিখিত বলে - একটি নেতিবাচক রাউটিং ইভেন্টের ক্ষেত্রে আমরা হ্যাশকে এলোমেলো করে দেব। একটি নেতিবাচক রাউটিং ঘটনা কি? এটি সেই আরটিও যা আমরা আগে আলোচনা করেছি, অর্থাৎ, জানালার লেজ হারানো একটি ঘটনা যা সত্যিই নেতিবাচক। সত্য, এটি যে এটি অনুমান করা তুলনামূলকভাবে কঠিন।

2016, আরেকটি স্বনামধন্য কোম্পানি, এছাড়াও বড়. এটি শেষ ক্রাচগুলিকে বিচ্ছিন্ন করে এবং এটি তৈরি করে যাতে হ্যাশ, যা আমরা আগে এলোমেলো করেছিলাম, এখন প্রতিটি SYN রিট্রান্সমিশনের জন্য এবং প্রতিটি RTO টাইমআউটের পরে পরিবর্তন হয়। এবং এই চিঠিতে, প্রথম এবং শেষবারের মতো, চূড়ান্ত লক্ষ্যটি বলা হয়েছে - লোকসান বা চ্যানেলের যানজটের ক্ষেত্রে ট্র্যাফিককে নরমভাবে পুনরায় রুট করার এবং একাধিক পথ ব্যবহার করার ক্ষমতা রয়েছে তা নিশ্চিত করা। অবশ্যই, এর পরে প্রচুর প্রকাশনা ছিল, আপনি সহজেই সেগুলি খুঁজে পেতে পারেন।

যদিও না, আপনি পারবেন না, কারণ এই বিষয়ে একটিও প্রকাশনা হয়নি। কিন্তু আমরা জানি!

এবং যদি আপনি সম্পূর্ণরূপে বুঝতে না পারেন কি করা হয়েছে, আমি এখন আপনাকে বলব।


কি করা হয়েছিল, লিনাক্স কার্নেলে কোন কার্যকারিতা যুক্ত করা হয়েছিল? প্রতিটি RTO ইভেন্টের পরে txhash একটি এলোমেলো মান পরিবর্তন করে। এটি রাউটিং এর খুব নেতিবাচক ফলাফল। হ্যাশ এই txhash এর উপর নির্ভর করে, এবং ফ্লো লেবেল skb হ্যাশ এর উপর নির্ভর করে। এখানে ফাংশনগুলির কিছু গণনা রয়েছে; সমস্ত বিবরণ এক স্লাইডে স্থাপন করা যাবে না। যদি কেউ কৌতূহলী হয়, আপনি কার্নেল কোডের মাধ্যমে যেতে পারেন এবং চেক করতে পারেন।

এখানে গুরুত্বপূর্ণ কি? প্রতিটি RTO-এর পরে ফ্লো লেবেল ক্ষেত্রের মান একটি এলোমেলো নম্বরে পরিবর্তিত হয়। এটি কীভাবে আমাদের দুর্ভাগ্যজনক TCP স্ট্রিমকে প্রভাবিত করে?


যদি একটি SACK ঘটে, তবে কিছুই পরিবর্তন হবে না কারণ আমরা একটি পরিচিত হারানো প্যাকেট পুনরায় পাঠানোর চেষ্টা করছি৷ এ পর্যন্ত সব ঠিকই.


কিন্তু RTO-এর ক্ষেত্রে, যদি আমরা ToR-এর হ্যাশ ফাংশনে একটি ফ্লো লেবেল যোগ করেছি, তাহলে ট্রাফিক ভিন্ন রুট নিতে পারে। এবং যত বেশি লেন হবে, তত বেশি সুযোগ এটি এমন একটি পথ খুঁজে পাবে যা একটি নির্দিষ্ট ডিভাইসে ব্যর্থতার দ্বারা প্রভাবিত হয় না।


একটি সমস্যা থেকে যায় - আরটিও। অবশ্যই, অন্য রুট আছে, কিন্তু এটিতে অনেক সময় নষ্ট হয়। 200 ms অনেক। একটি সেকেন্ড একেবারে বন্য. পূর্বে, আমি টাইমআউট সম্পর্কে কথা বলেছিলাম যে পরিষেবাগুলি কনফিগার করা হয়েছে। সুতরাং, একটি সেকেন্ড একটি টাইমআউট, যা সাধারণত অ্যাপ্লিকেশন স্তরে পরিষেবা দ্বারা কনফিগার করা হয় এবং এতে পরিষেবাটি তুলনামূলকভাবে সঠিক হবে। তাছাড়া, আমি আবারও বলছি, একটি আধুনিক ডেটা সেন্টারের মধ্যে আসল RTT প্রায় 1 মিলিসেকেন্ড।


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


সত্য, SYN_RTO এর সাথে সবকিছু কিছুটা খারাপ। এটি স্বাভাবিকভাবেই পেরেক দিয়ে আটকানো হয়। কার্নেলের 1 সেকেন্ডের একটি নির্দিষ্ট মান রয়েছে এবং এটিই। আপনি ব্যবহারকারী স্থান থেকে সেখানে পৌঁছাতে পারবেন না। শুধুমাত্র একটি উপায় আছে।


eBPF উদ্ধার করতে আসে। সহজভাবে বলতে গেলে, এগুলি হল ছোট সি প্রোগ্রাম। এগুলো কার্নেল স্ট্যাক এবং টিসিপি স্ট্যাকের এক্সিকিউশনে বিভিন্ন জায়গায় হুকের মধ্যে ঢোকানো যেতে পারে, যার সাহায্যে আপনি অনেক বেশি সংখ্যক সেটিংস পরিবর্তন করতে পারেন। সাধারণভাবে, eBPF একটি দীর্ঘমেয়াদী প্রবণতা। কয়েক ডজন নতুন sysctl প্যারামিটার কাটা এবং আইপি ইউটিলিটি প্রসারিত করার পরিবর্তে, আন্দোলনটি eBPF এর দিকে অগ্রসর হচ্ছে এবং এর কার্যকারিতা প্রসারিত করছে। eBPF ব্যবহার করে, আপনি গতিশীলভাবে যানজট নিয়ন্ত্রণ এবং অন্যান্য বিভিন্ন TCP সেটিংস পরিবর্তন করতে পারেন।


কিন্তু এটা আমাদের জন্য গুরুত্বপূর্ণ যে এটি SYN_RTO মান পরিবর্তন করতে ব্যবহার করা যেতে পারে। তাছাড়া, একটি সর্বজনীনভাবে পোস্ট করা উদাহরণ রয়েছে: https://elixir.bootlin.com/linux/latest/source/samples/bpf/tcp_synrto_kern.c. এখানে কি করা হয়েছে? উদাহরণ কাজ করছে, কিন্তু নিজেই খুব রুক্ষ. এখানে এটা ধরে নেওয়া হয় যে ডেটা সেন্টারের ভিতরে আমরা প্রথম 44 বিট তুলনা করি; যদি তারা মিলে যায়, তাহলে আমরা ডেটা সেন্টারের ভিতরে আছি। এবং এই ক্ষেত্রে আমরা SYN_RTO টাইমআউট মান 4ms এ পরিবর্তন করি। একই কাজ অনেক বেশি মার্জিতভাবে করা যেতে পারে। কিন্তু এই সহজ উদাহরণ দেখায় যে এটি একটি) সম্ভব; খ) অপেক্ষাকৃত সহজ।

আমরা ইতিমধ্যে কি জানি? প্লেন আর্কিটেকচারটি স্কেলিং করার অনুমতি দেয়, এটি আমাদের জন্য অত্যন্ত উপযোগী হতে দেখা যায় যখন আমরা ToR-এ ফ্লো লেবেল সক্ষম করি এবং সমস্যা এলাকার চারপাশে প্রবাহিত করার ক্ষমতা পাই। RTO এবং SYN-RTO মান কমানোর সর্বোত্তম উপায় হল eBPF প্রোগ্রামগুলি ব্যবহার করা। প্রশ্ন থেকে যায়: ভারসাম্য রক্ষার জন্য একটি ফ্লো লেবেল ব্যবহার করা কি নিরাপদ? এবং এখানে একটি nuance আছে.


ধরুন আপনার নেটওয়ার্কে এমন একটি পরিষেবা আছে যা যেকোনো কাস্টে থাকে। দুর্ভাগ্যবশত, যেকোন কাস্ট কী সে সম্পর্কে বিস্তারিত জানার জন্য আমার কাছে সময় নেই, তবে এটি একই IP ঠিকানার মাধ্যমে অ্যাক্সেসযোগ্য বিভিন্ন শারীরিক সার্ভার সহ একটি বিতরণ করা পরিষেবা। এবং এখানে একটি সম্ভাব্য সমস্যা: RTO ইভেন্টটি কেবল তখনই ঘটতে পারে যখন ট্র্যাফিক ফ্যাব্রিকের মধ্য দিয়ে যায়। এটি টিওআর বাফার স্তরেও ঘটতে পারে: যখন একটি ইনকাস্ট ঘটনা ঘটে, তখন হোস্ট যখন কিছু ছড়িয়ে দেয় তখন এটি হোস্টে ঘটতে পারে। যখন একটি RTO ইভেন্ট ঘটে এবং এটি ফ্লো লেবেল পরিবর্তন করে। এই ক্ষেত্রে, ট্রাফিক অন্য যেকোনো কাস্ট উদাহরণে যেতে পারে। ধরা যাক এটি একটি রাষ্ট্রীয় কোনো কাস্ট, এতে একটি সংযোগ অবস্থা রয়েছে - এটি একটি L3 ব্যালেন্সার বা অন্য কোনো পরিষেবা হতে পারে। তারপরে একটি সমস্যা দেখা দেয়, কারণ RTO পরে TCP সংযোগটি সার্ভারে আসে, যা এই TCP সংযোগ সম্পর্কে কিছুই জানে না। এবং যদি আমাদের কোনো কাস্ট সার্ভারের মধ্যে রাষ্ট্রীয় ভাগাভাগি না থাকে, তাহলে এই ধরনের ট্র্যাফিক ড্রপ করা হবে এবং TCP সংযোগ বিচ্ছিন্ন হয়ে যাবে।


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

একভাবে বা অন্যভাবে, আমার কাছে মনে হচ্ছে আমরা পরীক্ষায় এগিয়ে যেতে প্রস্তুত।


যখন আমরা ToR-এ ফ্লো লেবেল সক্ষম করেছিলাম, eBPF এজেন্ট প্রস্তুত করেছিলাম, যা এখন হোস্টে থাকে, আমরা পরবর্তী বড় ব্যর্থতার জন্য অপেক্ষা না করে নিয়ন্ত্রিত বিস্ফোরণ পরিচালনা করার সিদ্ধান্ত নিয়েছিলাম। আমরা টিওআর নিয়েছি, যার চারটি আপলিংক রয়েছে এবং তাদের একটিতে ড্রপ সেট আপ করেছি। তারা একটা নিয়ম আঁকিয়ে বলল- এখন তুমি সব প্যাকেট হারাচ্ছ। আপনি বাম দিকে দেখতে পাচ্ছেন, আমাদের প্রতি-প্যাকেট পর্যবেক্ষণ রয়েছে, যা 75% এ নেমে এসেছে, অর্থাৎ 25% প্যাকেট হারিয়ে গেছে। ডানদিকে এই ToR-এর পিছনে থাকা পরিষেবাগুলির গ্রাফ রয়েছে৷ মূলত, এগুলি হল র্যাকের ভিতরে থাকা সার্ভারগুলির সাথে ইন্টারফেসের ট্র্যাফিক গ্রাফ। আপনি দেখতে পাচ্ছেন, তারা আরও নীচে ডুবে গেছে। কেন তারা নীচে নেমে গেল - 25% দ্বারা নয়, তবে কিছু ক্ষেত্রে 3-4 বার? TCP সংযোগটি দুর্ভাগ্যজনক হলে, এটি ভাঙা জংশনের মাধ্যমে পৌঁছানোর চেষ্টা চালিয়ে যায়। এটি ডিসি-এর অভ্যন্তরে পরিষেবার সাধারণ আচরণের দ্বারা বৃদ্ধি পায় - একটি ব্যবহারকারীর অনুরোধের জন্য, অভ্যন্তরীণ পরিষেবাগুলিতে N অনুরোধগুলি তৈরি হয় এবং প্রতিক্রিয়াটি ব্যবহারকারীর কাছে যাবে যখন সমস্ত ডেটা উত্স প্রতিক্রিয়া জানায়, বা যখন অ্যাপ্লিকেশনটিতে একটি সময়সীমা ঘটে স্তর, যা এখনও কনফিগার করা প্রয়োজন। অর্থাৎ, সবকিছু খুব, খুব খারাপ।


এখন একই পরীক্ষা, কিন্তু প্রবাহ লেবেল মান সক্ষম সঙ্গে. আপনি দেখতে পাচ্ছেন, বাম দিকে আমাদের ব্যাচ পর্যবেক্ষণ একই 25% কমে গেছে। এটি একেবারে সঠিক, কারণ এটি পুনঃপ্রচার সম্পর্কে কিছুই জানে না, এটি প্যাকেট পাঠায় এবং বিতরণ করা এবং হারিয়ে যাওয়া প্যাকেটের সংখ্যার অনুপাত গণনা করে।

এবং ডানদিকে পরিষেবার সময়সূচী রয়েছে। আপনি এখানে একটি সমস্যাযুক্ত জয়েন্টের প্রভাব খুঁজে পাবেন না। সেই একই মিলিসেকেন্ডে, ট্রাফিক সমস্যা এলাকা থেকে বাকি তিনটি আপলিঙ্কে প্রবাহিত হয়েছে যেগুলি সমস্যা দ্বারা প্রভাবিত হয়নি। আমাদের এমন একটি নেটওয়ার্ক রয়েছে যা নিজেকে নিরাময় করে।

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

নেটওয়ার্ক ইঞ্জিনিয়ারদের অবশ্যই একটি ধারণাগত পরিবর্তনের মধ্য দিয়ে যেতে হবে: নেটওয়ার্ক টিওআর দিয়ে নয়, নেটওয়ার্ক ডিভাইস দিয়ে নয়, হোস্ট দিয়ে শুরু হয়। একটি মোটামুটি আকর্ষণীয় উদাহরণ হল কিভাবে আমরা আরটিও পরিবর্তন করতে এবং যেকোনওকাস্ট পরিষেবাগুলির দিকে ফ্লো লেবেল ঠিক করতে উভয়ই eBPF ব্যবহার করি৷

ফ্লো লেবেল মেকানিক্স নিয়ন্ত্রিত প্রশাসনিক বিভাগের মধ্যে অন্যান্য অ্যাপ্লিকেশনের জন্য অবশ্যই উপযুক্ত। এটি ডেটা সেন্টারের মধ্যে ট্রাফিক হতে পারে, অথবা আপনি বহির্গামী ট্র্যাফিক পরিচালনা করার জন্য একটি বিশেষ উপায়ে এই ধরনের মেকানিক্স ব্যবহার করতে পারেন। তবে আমি আপনাকে এই সম্পর্কে বলব, আমি আশা করি, পরের বার। আপনার মনোযোগের জন্য অনেক ধন্যবাদ।

উত্স: www.habr.com