কিভাবে Badoo প্রতি সেকেন্ডে 200k ছবি পাঠানোর ক্ষমতা অর্জন করেছে

আধুনিক ওয়েব মিডিয়া বিষয়বস্তু ছাড়া প্রায় অকল্পনীয়: প্রায় প্রতিটি ঠাকুরমার একটি স্মার্টফোন আছে, প্রত্যেকেই সামাজিক নেটওয়ার্কে রয়েছে এবং রক্ষণাবেক্ষণের ডাউনটাইম কোম্পানিগুলির জন্য ব্যয়বহুল। এখানে কোম্পানির গল্পের একটি প্রতিলিপি badoo কিভাবে তিনি একটি হার্ডওয়্যার সমাধান ব্যবহার করে ফটো ডেলিভারি সংগঠিত করেছেন, প্রক্রিয়াটিতে তিনি কোন কার্যকারিতা সমস্যার সম্মুখীন হয়েছেন, সেগুলি কী কারণে হয়েছে এবং সমস্ত স্তরে ত্রুটি সহনশীলতা নিশ্চিত করার সময় Nginx-এর উপর ভিত্তি করে একটি সফ্টওয়্যার সমাধান ব্যবহার করে কীভাবে এই সমস্যাগুলি সমাধান করা হয়েছিল (видео) আমরা ওলেগের গল্পের লেখকদের ধন্যবাদ জানাই সানিস এফিমোভা এবং আলেকজান্দ্রা ডিমোভা, যারা সম্মেলনে তাদের অভিজ্ঞতা শেয়ার করেছেন আপটাইম দিন 4.

— আসুন আমরা কীভাবে ফটোগুলি সংরক্ষণ এবং ক্যাশে করি সে সম্পর্কে একটি ছোট্ট ভূমিকা দিয়ে শুরু করি। আমাদের একটি স্তর রয়েছে যেখানে আমরা সেগুলি সংরক্ষণ করি এবং একটি স্তর যেখানে আমরা ফটো ক্যাশে করি। একই সময়ে, যদি আমরা একটি উচ্চ ট্রিক রেট অর্জন করতে চাই এবং স্টোরেজের লোড কমাতে চাই, তবে এটি আমাদের জন্য গুরুত্বপূর্ণ যে একজন পৃথক ব্যবহারকারীর প্রতিটি ফটো একটি ক্যাশিং সার্ভারে থাকে। অন্যথায়, আমাদের যত বেশি সার্ভার আছে আমাদের তত গুণ বেশি ডিস্ক ইনস্টল করতে হবে। আমাদের ট্রিক রেট প্রায় 99%, অর্থাৎ, আমরা আমাদের স্টোরেজের লোড 100 গুণ কমিয়ে দিচ্ছি, এবং এটি করার জন্য, 10 বছর আগে, যখন এই সমস্ত তৈরি করা হচ্ছিল, আমাদের 50টি সার্ভার ছিল। তদনুসারে, এই ফটোগুলি পরিবেশন করার জন্য, আমাদের মূলত 50টি বাহ্যিক ডোমেনের প্রয়োজন যা এই সার্ভারগুলি পরিবেশন করে৷

স্বাভাবিকভাবেই, প্রশ্নটি অবিলম্বে উত্থাপিত হয়েছিল: যদি আমাদের একটি সার্ভার ডাউন হয়ে যায় এবং অনুপলব্ধ হয়ে যায়, তাহলে আমরা ট্র্যাফিকের কোন অংশটি হারাবো? আমরা বাজারে কী ছিল তা দেখেছি এবং একটি হার্ডওয়্যার কেনার সিদ্ধান্ত নিয়েছি যাতে এটি আমাদের সমস্ত সমস্যার সমাধান করে। পছন্দটি F5-নেটওয়ার্ক কোম্পানির সমাধানের উপর পড়ে (যা, যাইহোক, সম্প্রতি NGINX, Inc কিনেছে): BIG-IP লোকাল ট্রাফিক ম্যানেজার।

এই টুকরো হার্ডওয়্যার (LTM) কি করে: এটি একটি আয়রন রাউটার যা এর বাহ্যিক পোর্টগুলির আয়রন রিডান্ডেন্সি তৈরি করে এবং আপনাকে নেটওয়ার্ক টপোলজির উপর ভিত্তি করে কিছু সেটিংসে ট্র্যাফিক রুট করতে দেয় এবং স্বাস্থ্য পরীক্ষা করে। এটি আমাদের কাছে গুরুত্বপূর্ণ ছিল যে এই হার্ডওয়্যারটি প্রোগ্রাম করা যেতে পারে। তদনুসারে, আমরা একটি নির্দিষ্ট ক্যাশে থেকে একটি নির্দিষ্ট ব্যবহারকারীর ফটোগ্রাফগুলি কীভাবে পরিবেশন করা হয়েছিল তার যুক্তি বর্ণনা করতে পারি। এটা কিসের মতো দেখতে? হার্ডওয়্যারের একটি অংশ রয়েছে যা একটি ডোমেনে, একটি আইপিতে ইন্টারনেট দেখে, এসএসএল অফলোড করে, HTTP অনুরোধগুলি পার্স করে, IRule থেকে একটি ক্যাশে নম্বর নির্বাচন করে, কোথায় যেতে হবে এবং ট্রাফিককে সেখানে যেতে দেয়৷ একই সময়ে, এটি স্বাস্থ্য পরীক্ষা করে, এবং কিছু মেশিন অনুপলব্ধ হওয়ার ক্ষেত্রে, সেই সময়ে আমরা এটি তৈরি করেছি যাতে ট্র্যাফিক একটি ব্যাকআপ সার্ভারে যায়। কনফিগারেশনের দৃষ্টিকোণ থেকে, অবশ্যই কিছু সূক্ষ্মতা রয়েছে, তবে সাধারণভাবে সবকিছুই বেশ সহজ: আমরা একটি কার্ড নিবন্ধন করি, নেটওয়ার্কে আমাদের আইপিতে একটি নির্দিষ্ট সংখ্যার চিঠিপত্র, আমরা বলি যে আমরা পোর্ট 80 এ শুনব। এবং 443, আমরা বলি যে যদি সার্ভারটি অনুপলব্ধ হয়, তাহলে আপনাকে ট্রাফিক পাঠাতে হবে ব্যাকআপে, এই ক্ষেত্রে 35 তম, এবং আমরা এই আর্কিটেকচারটি কীভাবে বিচ্ছিন্ন করা উচিত তার একটি গুচ্ছ যুক্তি বর্ণনা করি। একমাত্র সমস্যা ছিল যে ভাষাটিতে হার্ডওয়্যারটি প্রোগ্রাম করা হয়েছিল তা ছিল Tcl। যদি কেউ এটা মনে রাখে... এই ভাষাটি প্রোগ্রামিং-এর জন্য সুবিধাজনক ভাষার চেয়ে শুধুমাত্র লেখার জন্য বেশি:

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

কিন্তু…

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

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

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

অর্থাৎ, আমরা সমস্যার উৎস চিহ্নিত করেছি, বাধা চিহ্নিত করেছি। আমরা কী করব তা সিদ্ধান্ত নেওয়া বাকি।

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

যেহেতু টাস্কটি "যত তাড়াতাড়ি সম্ভব কিছু করুন এবং আমাদের কাছে থাকা হার্ডওয়্যার ব্যবহার করে" এর মতো শোনাচ্ছিল, প্রথম জিনিসটি আমরা ভেবেছিলাম কেবলমাত্র সামনে থেকে খুব শক্তিশালী নয় এমন কিছু মেশিন সরিয়ে দেওয়া, সেখানে Nginx বসানো, যার সাথে আমরা জানি কিভাবে আমরা জানি। কাজ করুন এবং হার্ডওয়্যার ব্যবহার করার মতো একই যুক্তি প্রয়োগ করার চেষ্টা করুন। অর্থাৎ, আসলে, আমরা আমাদের হার্ডওয়্যার ছেড়ে দিয়েছি, আরও 4টি সার্ভার ইনস্টল করেছি যা আমাদের কনফিগার করতে হয়েছিল, তাদের জন্য বাহ্যিক ডোমেন তৈরি করেছি, যেমনটি 10 ​​বছর আগে ছিল... এই মেশিনগুলি পড়ে গেলে আমরা কিছুটা প্রাপ্যতা হারিয়ে ফেলি, কিন্তু এখনও কম, তারা স্থানীয়ভাবে আমাদের ব্যবহারকারীদের সমস্যার সমাধান করেছে।

তদনুসারে, যুক্তিটি একই থাকে: আমরা Nginx ইনস্টল করি, এটি SSL-অফলোড করতে পারে, আমরা কোনওভাবে রাউটিং লজিক প্রোগ্রাম করতে পারি, কনফিগারে স্বাস্থ্য পরীক্ষা করতে পারি এবং আমাদের আগে যে যুক্তিটি ছিল তা কেবল নকল করতে পারি।

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

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

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

এটি এড়াতে, আমরা দুটি জিনিস করেছি:

ক) তারা এনজিনক্সকে ম্যানুয়ালি এটি করতে নিষেধ করেছে - এবং দুর্ভাগ্যবশত, এটি করার একমাত্র উপায় হল সর্বাধিক ব্যর্থ সেটিংস সেট করা।

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

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

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

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

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

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

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

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

এই অভ্যাস মত চেহারা কি? কোন একটি সার্ভার ব্যর্থ হলে কি হবে? মাস্টার অদৃশ্য হওয়ার সাথে সাথে আমাদের ব্যাকআপ বিজ্ঞাপন পাওয়া বন্ধ করে দেয় এবং স্বয়ংক্রিয়ভাবে মাস্টার হয়ে যায়। কিছু সময় পরে, আমরা মাস্টারটি মেরামত করেছি, রিবুট করেছি, Keepalived উত্থাপন করেছি - বিজ্ঞাপনগুলি ব্যাকআপের চেয়ে বেশি অগ্রাধিকার দিয়ে আসে এবং ব্যাকআপ স্বয়ংক্রিয়ভাবে ফিরে আসে, আইপি ঠিকানাগুলি সরিয়ে দেয়, কোনও ম্যানুয়াল অ্যাকশন করার দরকার নেই৷

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

বিশেষ কি? - ইনকামিং এবং আউটগোয়িং ট্রাফিকের মধ্যে বিশাল পার্থক্য। আগত ট্রাফিক খুব ছোট, বহির্গামী ট্র্যাফিক খুব বড়:

আপনি যদি এই গ্রাফগুলি দেখেন তবে আপনি দেখতে পাবেন যে এই মুহুর্তে পরিচালক প্রতি সেকেন্ডে প্রায় 200 এমবি রিসিভ করছেন, এটি একটি খুব সাধারণ দিন। আমরা প্রতি সেকেন্ডে 4,500 MB ফেরত দেই, আমাদের অনুপাত প্রায় 1/22। এটি ইতিমধ্যেই স্পষ্ট যে 22টি কর্মী সার্ভারে সম্পূর্ণরূপে বহির্গামী ট্র্যাফিক প্রদান করতে, আমাদের শুধুমাত্র একটি প্রয়োজন যে এই সংযোগটি গ্রহণ করে। এখানেই সরাসরি রাউটিং অ্যালগরিদম আমাদের সাহায্যে আসে।

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

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

আমরা মাঝখানে কোথাও থামলাম: আমাদের কাছে একটি নির্দিষ্ট স্থানে একটি https অনুরোধ রয়েছে, স্ক্রিপ্টটি বলা হয়, যদি এটি 200 তম প্রতিক্রিয়া সহ প্রতিক্রিয়া জানায়, আমরা বিশ্বাস করি যে এই সার্ভারের সাথে সবকিছু ঠিক আছে, এটি জীবিত এবং বেশ চালু করা যেতে পারে সহজে

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

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

সুতরাং, মোটামুটি সহজ উপায়ে, অল্প সংখ্যক সার্ভারের সাহায্যে, আমরা বাহ্যিক ত্রুটি সহনশীলতার সমস্যার সমাধান করেছি।

যা বলা বাকি আছে তা হল এই সব অবশ্যই নজরদারি করা দরকার। আলাদাভাবে, এটি লক্ষ করা উচিত যে Keepalivede, সফ্টওয়্যার হিসাবে অনেক দিন আগে লেখা, এটি নিরীক্ষণ করার জন্য অনেক উপায় রয়েছে, উভয়ই DBus, SMTP, SNMP এবং স্ট্যান্ডার্ড Zabbix এর মাধ্যমে চেক ব্যবহার করে। এছাড়াও, তিনি নিজেই জানেন কিভাবে প্রায় প্রতিটি হাঁচির জন্য চিঠি লিখতে হয়, এবং সত্যি কথা বলতে, কিছু সময়ে আমরা এটি বন্ধ করার কথাও ভেবেছিলাম, কারণ তিনি প্রতিটি আইপি সংযোগের জন্য যেকোন ট্র্যাফিক সুইচিং, সুইচ অন করার জন্য প্রচুর চিঠি লেখেন, এবং তাই অবশ্যই, যদি প্রচুর সার্ভার থাকে তবে আপনি এই অক্ষরগুলি দিয়ে নিজেকে অভিভূত করতে পারেন। আমরা স্ট্যান্ডার্ড পদ্ধতি ব্যবহার করে ফটো রাউটারগুলিতে nginx নিরীক্ষণ করি, এবং হার্ডওয়্যার মনিটরিং চলে যায় নি। আমরা অবশ্যই, আরও দুটি বিষয়ে পরামর্শ দেব: প্রথমত, বাহ্যিক স্বাস্থ্য-পরীক্ষা এবং উপলব্ধতা, কারণ সবকিছু কাজ করলেও, বাস্তবে, বহিরাগত সরবরাহকারীদের সমস্যা বা আরও জটিল কিছুর কারণে ব্যবহারকারীরা সম্ভবত ফটোগুলি পান না। এটি সর্বদা অন্য নেটওয়ার্কে কোথাও রাখা মূল্যবান, অ্যামাজনে বা অন্য কোথাও, একটি পৃথক মেশিন যা আপনার সার্ভারগুলিকে বাইরে থেকে পিং করতে পারে এবং এটি অসঙ্গতি সনাক্তকরণ ব্যবহার করেও মূল্যবান, যারা জানেন কীভাবে কৌশলী মেশিন লার্নিং করতে হয়, বা সহজ পর্যবেক্ষণ, অন্তত ট্র্যাক করার জন্য অনুরোধগুলি তীব্রভাবে হ্রাস পেয়েছে, বা, বিপরীতে, বৃদ্ধি পেয়েছে। এটি দরকারীও হতে পারে।

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

আমরা কি শেষ করেছিলাম? 2018 সালের জানুয়ারির ছুটির সময় আমাদের একটি সমস্যা হয়েছিল। প্রথম ছয় মাসে যখন আমরা এই স্কিমটি চালু করেছি, LTM থেকে সমস্ত ট্র্যাফিক সরানোর জন্য আমরা এটিকে সমস্ত ট্র্যাফিকের জন্য প্রসারিত করেছি, আমরা শুধুমাত্র একটি ডেটা সেন্টারে 40 গিগাবিট থেকে 60 গিগাবিট পর্যন্ত ট্র্যাফিক বৃদ্ধি করেছি এবং একই সময়ে পুরো 2018 বছর প্রতি সেকেন্ডে প্রায় তিনগুণ বেশি ছবি পাঠাতে সক্ষম হয়েছে।

উত্স: www.habr.com