Yandex.Cloud-এ নেটওয়ার্ক লোড ব্যালেন্সার আর্কিটেকচার

হ্যালো, আমি সের্গেই এলানসেভ, আমি বিকাশ করছি নেটওয়ার্ক লোড ব্যালেন্সার Yandex.Cloud-এ। পূর্বে, আমি ইয়ানডেক্স পোর্টালের জন্য L7 ব্যালেন্সার বিকাশের নেতৃত্ব দিয়েছিলাম - সহকর্মীরা রসিকতা করে যে আমি যাই করি না কেন, এটি একটি ব্যালেন্সার হিসাবে পরিণত হয়। আমি হাবরের পাঠকদের বলব কিভাবে একটি ক্লাউড প্ল্যাটফর্মে লোড পরিচালনা করতে হয়, আমরা এই লক্ষ্য অর্জনের জন্য আদর্শ সরঞ্জাম হিসাবে কী দেখি এবং কীভাবে আমরা এই সরঞ্জামটি তৈরির দিকে এগিয়ে যাচ্ছি।

প্রথমে কিছু শর্তাদি পরিচয় করিয়ে দেওয়া যাক:

• ভিআইপি (ভার্চুয়াল আইপি) - ব্যালেন্সার আইপি ঠিকানা
• সার্ভার, ব্যাকএন্ড, উদাহরণ - একটি ভার্চুয়াল মেশিন একটি অ্যাপ্লিকেশন চালাচ্ছে
• RIP (Real IP) - সার্ভারের IP ঠিকানা
• স্বাস্থ্য পরীক্ষা - সার্ভার প্রস্তুতি পরীক্ষা করা
• প্রাপ্যতা অঞ্চল, AZ - একটি ডেটা সেন্টারে বিচ্ছিন্ন পরিকাঠামো
• অঞ্চল - বিভিন্ন AZ এর একটি ইউনিয়ন

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

একটি লোড ব্যালেন্সার প্রায়ই OSI মডেলের প্রোটোকল স্তর দ্বারা শ্রেণীবদ্ধ করা হয় যার উপর এটি চলে। ক্লাউড ব্যালেন্সার টিসিপি স্তরে কাজ করে, যা চতুর্থ স্তর, L4-এর সাথে মিলে যায়।

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

ডেটা প্লেন

ট্রাফিক বর্ডার রাউটার নামক দামী ডিভাইসে শেষ হয়। ত্রুটি সহনশীলতা বাড়ানোর জন্য, এই ধরনের বেশ কয়েকটি ডিভাইস একই সাথে একটি ডেটা সেন্টারে কাজ করে। এরপরে, ট্রাফিক ব্যালেন্সারদের কাছে যায়, যা ক্লায়েন্টদের জন্য BGP-এর মাধ্যমে সমস্ত AZ-কে যেকোনওকাস্ট আইপি ঠিকানা ঘোষণা করে। 

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

কনফিগার প্লেন

 
কনফিগার প্লেনের মূল উপাদান হল API, যার মাধ্যমে ব্যালেন্সারগুলির সাথে মৌলিক ক্রিয়াকলাপগুলি সঞ্চালিত হয়: তৈরি করা, মুছে ফেলা, দৃষ্টান্তগুলির সংমিশ্রণ পরিবর্তন করা, স্বাস্থ্য পরীক্ষার ফলাফল পাওয়া ইত্যাদি। একদিকে, এটি একটি REST API, এবং অন্যদিকে অন্য, ক্লাউডে আমরা প্রায়শই ফ্রেমওয়ার্ক gRPC ব্যবহার করি, তাই আমরা REST কে gRPC-তে "অনুবাদ" করি এবং তারপর শুধুমাত্র gRPC ব্যবহার করি। যেকোন অনুরোধের ফলে ইয়ানডেক্স.ক্লাউড কর্মীদের একটি সাধারণ পুল থেকে অ্যাসিঙ্ক্রোনাস ইমপোটেন্ট টাস্কগুলির একটি সিরিজ তৈরি করা হয়। কাজগুলি এমনভাবে লেখা হয় যে সেগুলি যে কোনও সময় স্থগিত করা যেতে পারে এবং তারপরে পুনরায় চালু করা যেতে পারে। এটি পরিমাপযোগ্যতা, পুনরাবৃত্তিযোগ্যতা এবং অপারেশনের লগিং নিশ্চিত করে।

ফলস্বরূপ, API থেকে টাস্ক ব্যালেন্সার পরিষেবা নিয়ন্ত্রকের কাছে একটি অনুরোধ করবে, যা Go-তে লেখা আছে। এটি ব্যালেন্সার যোগ এবং অপসারণ করতে পারে, ব্যাকএন্ড এবং সেটিংসের রচনা পরিবর্তন করতে পারে। 

পরিষেবাটি Yandex ডেটাবেসে তার অবস্থা সঞ্চয় করে, একটি বিতরণ পরিচালিত ডাটাবেস যা আপনি শীঘ্রই ব্যবহার করতে সক্ষম হবেন। Yandex.Cloud-এ, যেমন আমরা ইতিমধ্যেই বলা, কুকুরের খাদ্য ধারণা প্রযোজ্য: যদি আমরা নিজেরাই আমাদের পরিষেবাগুলি ব্যবহার করি, তাহলে আমাদের ক্লায়েন্টরাও সেগুলি ব্যবহার করতে পেরে খুশি হবে। ইয়ানডেক্স ডাটাবেস এই ধরনের ধারণা বাস্তবায়নের একটি উদাহরণ। আমরা YDB-তে আমাদের সমস্ত ডেটা সঞ্চয় করি, এবং আমাদের ডেটাবেস বজায় রাখা এবং স্কেল করার বিষয়ে চিন্তা করতে হবে না: এই সমস্যাগুলি আমাদের জন্য সমাধান করা হয়েছে, আমরা ডেটাবেসকে পরিষেবা হিসাবে ব্যবহার করি।

ব্যালেন্সার কন্ট্রোলারে ফিরে আসা যাক। এর কাজ হল ব্যালেন্সার সম্পর্কে তথ্য সংরক্ষণ করা এবং ভার্চুয়াল মেশিনের প্রস্তুতি পরীক্ষা করার জন্য স্বাস্থ্য পরীক্ষা নিয়ন্ত্রকের কাছে একটি টাস্ক পাঠানো।

স্বাস্থ্য পরীক্ষা নিয়ন্ত্রক

এটি চেকের নিয়মগুলি পরিবর্তন করার অনুরোধগুলি গ্রহণ করে, সেগুলিকে YDB-তে সংরক্ষণ করে, হেলচেক নোডগুলির মধ্যে কাজগুলি বিতরণ করে এবং ফলাফলগুলিকে একত্রিত করে, যা তারপর ডাটাবেসে সংরক্ষিত হয় এবং লোডব্যালেন্সার কন্ট্রোলারে পাঠানো হয়। এটি, ঘুরে, লোডব্যালেন্সার-নোডে ডেটা প্লেনে ক্লাস্টারের রচনা পরিবর্তন করার জন্য একটি অনুরোধ পাঠায়, যা আমি নীচে আলোচনা করব।

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

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

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

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

পার্থক্য হল যে ক্লায়েন্টরা ভিআইপির কাছে অনুরোধ করে, যখন স্বাস্থ্য পরীক্ষা প্রতিটি পৃথক RIP-কে অনুরোধ করে। এখানে একটি আকর্ষণীয় সমস্যা দেখা দেয়: আমরা আমাদের ব্যবহারকারীদের ধূসর IP নেটওয়ার্কে সংস্থান তৈরি করার সুযোগ দিই। আসুন কল্পনা করি যে দুটি ভিন্ন ক্লাউড মালিক আছেন যারা ব্যালেন্সারের পিছনে তাদের পরিষেবাগুলি লুকিয়ে রেখেছেন। তাদের প্রত্যেকের 10.0.0.1/24 সাবনেটে একই ঠিকানা সহ সম্পদ রয়েছে। আপনি একরকম তাদের আলাদা করতে সক্ষম হতে হবে, এবং এখানে আপনাকে Yandex.Cloud ভার্চুয়াল নেটওয়ার্কের কাঠামোর মধ্যে ডুব দিতে হবে। আরও বিস্তারিত জানতে পারলে ভালো হয় প্রায় থেকে ভিডিও: ক্লাউড ইভেন্ট, এটা এখন আমাদের জন্য গুরুত্বপূর্ণ যে নেটওয়ার্কটি বহু-স্তরযুক্ত এবং এতে টানেল রয়েছে যা সাবনেট আইডি দ্বারা আলাদা করা যায়৷

হেলথচেক নোড তথাকথিত কোয়াসি-আইপিভি6 ঠিকানা ব্যবহার করে ব্যালেন্সারদের সাথে যোগাযোগ করে। একটি আধা-ঠিকানা হল একটি IPv6 ঠিকানা যার একটি IPv4 ঠিকানা এবং ব্যবহারকারীর সাবনেট আইডি এটির ভিতরে এমবেড করা থাকে। ট্র্যাফিক ব্যালেন্সারের কাছে পৌঁছায়, যা এটি থেকে IPv4 সংস্থান ঠিকানা বের করে, IPv6-কে IPv4 দিয়ে প্রতিস্থাপন করে এবং প্যাকেটটি ব্যবহারকারীর নেটওয়ার্কে পাঠায়।

বিপরীত ট্র্যাফিক একইভাবে যায়: ব্যালেন্সার দেখতে পায় যে গন্তব্যটি হেলথচেকারদের থেকে একটি ধূসর নেটওয়ার্ক, এবং IPv4 কে IPv6 তে রূপান্তর করে।

ভিপিপি - ডেটা প্লেনের হৃদয়

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

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

উদাহরণস্বরূপ, ভিপিপি-তে আইপি প্যাকেটগুলির প্রক্রিয়াকরণ নিম্নলিখিত ক্রমে ঘটে: প্রথমে, প্যাকেট শিরোনামগুলি পার্সিং নোডে পার্স করা হয় এবং তারপরে সেগুলি নোডে পাঠানো হয়, যা রাউটিং টেবিল অনুসারে প্যাকেটগুলিকে আরও এগিয়ে দেয়।

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

n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
    vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
    // ...
    while (n_left_from >= 4 && n_left_to_next >= 2)
    {
        // processing multiple packets at once
        u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        // ...
        /* Prefetch next iteration. */
        {
            vlib_buffer_t *p2, *p3;

            p2 = vlib_get_buffer (vm, from[2]);
            p3 = vlib_get_buffer (vm, from[3]);

            vlib_prefetch_buffer_header (p2, LOAD);
            vlib_prefetch_buffer_header (p3, LOAD);

            CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
            CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
        }
        // actually process data
        /* verify speculative enqueues, maybe switch current next frame */
        vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
                to_next, n_left_to_next,
                bi0, bi1, next0, next1);
    }

    while (n_left_from > 0 && n_left_to_next > 0)
    {
        // processing packets by one
    }

    // processed batch
    vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

তাই, হেলথচেক IPv6 নিয়ে VPP-এর সাথে কথা বলে, যা তাদের IPv4-এ পরিণত করে। এটি গ্রাফের একটি নোড দ্বারা করা হয়, যাকে আমরা অ্যালগরিদমিক NAT বলি। বিপরীত ট্র্যাফিকের জন্য (এবং IPv6 থেকে IPv4 রূপান্তর) একই অ্যালগরিদমিক NAT নোড রয়েছে।

ব্যালেন্সার ক্লায়েন্টদের কাছ থেকে সরাসরি ট্র্যাফিক গ্রাফ নোডের মধ্য দিয়ে যায়, যা নিজেই ভারসাম্য সম্পাদন করে। 

প্রথম নোড হল স্টিকি সেশন। এটি হ্যাশ সংরক্ষণ করে 5-টুপল প্রতিষ্ঠিত সেশনের জন্য। 5-টুপলে ক্লায়েন্টের ঠিকানা এবং পোর্ট অন্তর্ভুক্ত থাকে যেখান থেকে তথ্য প্রেরণ করা হয়, ট্র্যাফিক পাওয়ার জন্য উপলব্ধ সংস্থানগুলির ঠিকানা এবং পোর্ট, পাশাপাশি নেটওয়ার্ক প্রোটোকল। 

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

ধারাবাহিক হ্যাশিং

কেন আমরা এটি নির্বাচন করেছি এবং এটি এমনকি কি? প্রথমত, আগের কাজটি বিবেচনা করা যাক - তালিকা থেকে একটি সংস্থান নির্বাচন করা। 

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

ধারাবাহিক হ্যাশিং বর্ণিত সমস্যার সমাধান করে। এই ধারণাটি ব্যাখ্যা করার সবচেয়ে সহজ উপায় হল: কল্পনা করুন যে আপনার কাছে একটি রিং আছে যেখানে আপনি হ্যাশের মাধ্যমে সম্পদ বিতরণ করেন (উদাহরণস্বরূপ, IP:পোর্ট দ্বারা)। একটি সম্পদ নির্বাচন একটি কোণ দ্বারা চাকা বাঁক, যা প্যাকেটের হ্যাশ দ্বারা নির্ধারিত হয়.

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

আমরা ব্যালেন্সার এবং সম্পদের মধ্যে সরাসরি ট্র্যাফিকের কী ঘটে তা দেখেছি। এখন ফিরে আসা ট্রাফিক তাকান. এটি ট্রাফিক চেক করার মতো একই প্যাটার্ন অনুসরণ করে - অ্যালগরিদমিক NAT এর মাধ্যমে, অর্থাৎ ক্লায়েন্ট ট্রাফিকের জন্য বিপরীত NAT 44 এর মাধ্যমে এবং স্বাস্থ্য পরীক্ষা ট্রাফিকের জন্য NAT 46 এর মাধ্যমে। আমরা আমাদের নিজস্ব স্কিম মেনে চলি: আমরা স্বাস্থ্য পরীক্ষা ট্রাফিক এবং প্রকৃত ব্যবহারকারীর ট্রাফিককে একীভূত করি।

লোডব্যালান্সার-নোড এবং একত্রিত উপাদান

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

কি সমস্যা এড়ানো হয়েছে?

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

সমস্যা এবং সমাধান

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

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

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

আমাদের পরিকল্পনা

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

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

উত্স: www.habr.com