এক-ক্লাউড - ওডনোক্লাসনিকিতে ডেটা সেন্টার স্তরের ওএস

আলহা, মানুষ! আমার নাম ওলেগ আনাস্তাসিয়েভ, আমি প্ল্যাটফর্ম দলে ওডনোক্লাসনিকিতে কাজ করি। এবং আমার পাশাপাশি, ওডনোক্লাসনিকিতে প্রচুর হার্ডওয়্যার কাজ করছে। আমাদের 500 হাজারের বেশি সার্ভার সহ প্রায় 8 র্যাক সহ চারটি ডেটা সেন্টার রয়েছে। একটি নির্দিষ্ট সময়ে, আমরা বুঝতে পেরেছি যে একটি নতুন ম্যানেজমেন্ট সিস্টেমের প্রবর্তন আমাদেরকে আরও দক্ষতার সাথে সরঞ্জাম লোড করতে, অ্যাক্সেস ম্যানেজমেন্টকে সহজতর করতে, কম্পিউটিং সংস্থানগুলির (পুনরায়) বন্টন স্বয়ংক্রিয় করতে, নতুন পরিষেবাগুলি চালু করার গতি বাড়াতে এবং প্রতিক্রিয়াগুলির গতি বাড়াতে সাহায্য করবে। বড় আকারের দুর্ঘটনার জন্য।

এটা কি এসেছে?

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

ব্যবহারকারীর অনুরোধগুলি প্রধান পোর্টালের উভয় ফ্রন্টে গৃহীত হয় www.ok.ru, এবং অন্যদের উপর, উদাহরণস্বরূপ মিউজিক API ফ্রন্টে। ব্যবসায়িক যুক্তি প্রক্রিয়া করার জন্য, তারা অ্যাপ্লিকেশন সার্ভারকে কল করে, যা, অনুরোধটি প্রক্রিয়া করার সময়, প্রয়োজনীয় বিশেষ মাইক্রোসার্ভিসগুলিকে কল করে - এক-গ্রাফ (সামাজিক সংযোগের গ্রাফ), ব্যবহারকারী-ক্যাশে (ব্যবহারকারীর প্রোফাইলের ক্যাশে) ইত্যাদি।

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

কেন এমন হল? এই পদ্ধতির বেশ কয়েকটি সুবিধা ছিল:

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

বেশ কয়েকটি প্রতিলিপি সমন্বিত একটি পরিষেবাতে বেশ কয়েকটি সার্ভার বরাদ্দ করা হয় - প্রতিটির জন্য একটি। তারপরে পরিষেবাটির জন্য কম্পিউটিং সংস্থানটি খুব সহজভাবে বরাদ্দ করা হয়: পরিষেবাটির সার্ভারের সংখ্যা, এটি সর্বাধিক পরিমাণ সম্পদ ব্যবহার করতে পারে। এখানে "সহজ" এর অর্থ এই নয় যে এটি ব্যবহার করা সহজ, তবে এই অর্থে যে সম্পদ বরাদ্দ ম্যানুয়ালি করা হয়।

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

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

এই ঘটনাটি বুঝতে পেরে, আমরা কতটা কার্যকরভাবে র্যাকগুলি ব্যবহার করছি তা গণনা করার সিদ্ধান্ত নিয়েছি।
আমরা অর্থনৈতিকভাবে ন্যায়সঙ্গত সার্ভারের থেকে সবচেয়ে শক্তিশালী সার্ভারের দাম নিয়েছি, হিসাব করেছিলাম যে আমরা র্যাকে কতগুলি সার্ভার রাখতে পারি, পুরানো মডেল "এক সার্ভার = একটি কাজ" এর উপর ভিত্তি করে আমরা কতগুলি কাজ চালাব এবং কত কাজ সরঞ্জাম ব্যবহার করতে পারে. তারা গণনা করে চোখের জল ফেলল। দেখা গেল যে র্যাক ব্যবহারে আমাদের দক্ষতা প্রায় 11%। উপসংহারটি সুস্পষ্ট: আমাদের ডেটা সেন্টার ব্যবহার করার দক্ষতা বাড়াতে হবে। মনে হবে যে সমাধানটি সুস্পষ্ট: আপনাকে একবারে একটি সার্ভারে বেশ কয়েকটি কাজ চালাতে হবে। কিন্তু এখান থেকেই শুরু হয় অসুবিধা।

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

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

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

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

প্লাস, ডকারে একটি রেডিমেড রেজিস্ট্রি এবং ইমেজ ট্যাগিং আমাদেরকে সংস্করণ করার জন্য এবং প্রোডাকশনে কোড সরবরাহ করার জন্য রেডিমেড আদিম দেয়।

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

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

আপনার 8 হাজার সার্ভার এবং 8-16 হাজার কন্টেইনার থাকলে ম্যানুয়ালি কন্টেইনার বিতরণ করা একটি বিকল্প নয়।

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

স্পষ্টতই, আমাদের একটি নিয়ন্ত্রণ স্তর প্রয়োজন যা স্বয়ংক্রিয়ভাবে এটি করবে।

সুতরাং আমরা একটি সাধারণ এবং বোধগম্য ছবিতে এসেছি যা সমস্ত স্থপতিরা পছন্দ করেন: তিনটি বর্গক্ষেত্র।

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

সম্পদ বণ্টন

এখন আসুন অনেক মিনিয়নের জন্য আরও জটিল সম্পদ বরাদ্দের সমস্যাটি দেখি।

এক-ক্লাউডে একটি কম্পিউটিং সংস্থান হল:

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

তারপরে কিছু পরিষেবার জন্য, উদাহরণস্বরূপ ব্যবহারকারী-ক্যাশের জন্য, আমরা এইভাবে ব্যবহার করা সংস্থানগুলি রেকর্ড করতে পারি: 400 প্রসেসর কোর, 2,5 TB মেমরি, উভয় দিকে 50 Gbit/s ট্র্যাফিক, 6 টি স্পিন্ডলে অবস্থিত HDD স্থানের 100 TB। অথবা এই মত একটি আরো পরিচিত ফর্ম:

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

ব্যবহারকারী-ক্যাশে পরিষেবা সংস্থানগুলি উত্পাদন পরিকাঠামোতে সমস্ত উপলব্ধ সংস্থানের একটি অংশ গ্রহণ করে। অতএব, আমি নিশ্চিত করতে চাই যে হঠাৎ করে, একটি অপারেটরের ত্রুটির কারণে বা না, ব্যবহারকারী-ক্যাশে বরাদ্দের চেয়ে বেশি সংস্থান গ্রহণ করে না। অর্থাৎ আমাদের অবশ্যই সম্পদ সীমিত করতে হবে। কিন্তু আমরা কি কোটা বাঁধতে পারি?

আসুন উপাদানগুলির মিথস্ক্রিয়া সম্পর্কে আমাদের অত্যন্ত সরলীকৃত চিত্রে ফিরে আসি এবং আরও বিশদ সহ এটিকে পুনরায় আঁকুন - যেমন:

যা চোখে পড়ে:

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

আসুন আবার ছবি আঁকুন:

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

অতিরিক্ত লাইনগুলি সরিয়ে, আমরা আমাদের ছবির প্রতিটি নোড একটি চাটুকার আকারে লিখতে পারি: group1.web.front, api.music.front, user-cache.cache.

এভাবেই আমরা "হায়ারার্কিক্যাল কিউ" ধারণায় আসি। এটির "group1.web.front" এর মতো একটি নাম রয়েছে। সংস্থান এবং ব্যবহারকারীর অধিকারের জন্য একটি কোটা এটিকে বরাদ্দ করা হয়েছে। আমরা DevOps-এর ব্যক্তিকে সারিতে একটি পরিষেবা পাঠানোর অধিকার দেব, এবং এই ধরনের একজন কর্মচারী সারিতে কিছু চালু করতে পারে, এবং OpsDev-এর ব্যক্তির কাছে প্রশাসক অধিকার থাকবে, এবং এখন তিনি সারি পরিচালনা করতে পারবেন, সেখানে লোক নিয়োগ করতে পারবেন, এই লোকদের অধিকার দিন ইত্যাদি। যদি সারির কম্পিউটিং কোটা একবারে সমস্ত পরিষেবা কার্যকর করার জন্য যথেষ্ট না হয়, তাহলে সেগুলি ক্রমানুসারে কার্যকর করা হবে, এইভাবে সারি নিজেই গঠন করবে।

এর পরিষেবাগুলি ঘনিষ্ঠভাবে দেখে নেওয়া যাক। একটি পরিষেবার একটি সম্পূর্ণ যোগ্য নাম রয়েছে, যা সর্বদা সারির নাম অন্তর্ভুক্ত করে। তাহলে সামনের ওয়েব সার্ভিসের নাম থাকবে ok-web.group1.web.front. এবং এটি অ্যাক্সেস করা অ্যাপ্লিকেশন সার্ভার পরিষেবা বলা হবে ok-app.group1.web.front. প্রতিটি পরিষেবার একটি ম্যানিফেস্ট রয়েছে, যা নির্দিষ্ট মেশিনে স্থাপনের জন্য সমস্ত প্রয়োজনীয় তথ্য নির্দিষ্ট করে: এই কাজটি কতগুলি সংস্থান গ্রহণ করে, এটির জন্য কী কনফিগারেশন প্রয়োজন, কতগুলি প্রতিলিপি থাকা উচিত, এই পরিষেবাটির ব্যর্থতাগুলি পরিচালনা করার বৈশিষ্ট্যগুলি। এবং পরিষেবাটি সরাসরি মেশিনে স্থাপন করার পরে, এর উদাহরণগুলি উপস্থিত হয়। তাদের দ্ব্যর্থহীনভাবে নামকরণ করা হয়েছে - উদাহরণ নম্বর এবং পরিষেবার নাম হিসাবে: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

এটি খুব সুবিধাজনক: শুধুমাত্র চলমান পাত্রের নাম দেখে, আমরা অবিলম্বে অনেক কিছু খুঁজে পেতে পারি।

এখন আসুন এই দৃষ্টান্তগুলি আসলে কী সম্পাদন করে তা ঘনিষ্ঠভাবে দেখে নেওয়া যাক: কার্যগুলি৷

টাস্ক আইসোলেশন ক্লাস

ঠিক আছে (এবং, সম্ভবত, সর্বত্র) সমস্ত কাজকে গ্রুপে ভাগ করা যেতে পারে:

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

আসুন দেখি কিভাবে এই ধরনের কাজগুলি সম্পদ ব্যবহার করে, উদাহরণস্বরূপ, কেন্দ্রীয় প্রসেসর।

স্বল্প বিলম্বের কাজ। এই ধরনের কাজের একটি সিপিইউ খরচ প্যাটার্ন এর অনুরূপ থাকবে:

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

এই ধরনের কাজের জন্য ন্যূনতম বিলম্বের গ্যারান্টি দেওয়ার জন্য, আমাদের অবশ্যই এটি ব্যবহার করা সর্বাধিক সম্পদ গ্রহণ করতে হবে এবং মিনিয়নে প্রয়োজনীয় সংখ্যক কোর সংরক্ষণ করতে হবে (যে মেশিনটি কাজটি সম্পাদন করবে)। তারপরে আমাদের সমস্যার জন্য সংরক্ষণের সূত্রটি নিম্নরূপ হবে:

alloc: cpu = 4 (max)

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

গণনার কাজ। তাদের প্যাটার্ন সামান্য ভিন্ন হবে:

এই ধরনের কাজের জন্য গড় CPU সম্পদ খরচ বেশ বেশি। প্রায়শই আমরা একটি গণনার কাজ একটি নির্দিষ্ট সময়ের মধ্যে সম্পূর্ণ করতে চাই, তাই আমাদের এটির প্রয়োজনীয় ন্যূনতম সংখ্যক প্রসেসর সংরক্ষণ করতে হবে যাতে সমগ্র গণনা একটি গ্রহণযোগ্য সময়ে সম্পন্ন হয়। এর রিজার্ভেশন সূত্রটি দেখতে এইরকম হবে:

alloc: cpu = [1,*)

"অনুগ্রহ করে এটি একটি মিনিয়নের উপর রাখুন যেখানে অন্তত একটি বিনামূল্যে কোর আছে, এবং তারপর যতগুলি আছে, এটি সবকিছু গ্রাস করবে।"

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

কিন্তু কিভাবে যে কি?

প্রথমে, চলুন prod এবং এর alloc দেখুন: cpu = 4. আমাদের চারটি কোর সংরক্ষণ করতে হবে। ডকার রানে এটি দুটি উপায়ে করা যেতে পারে:

• বিকল্প ব্যবহার করে --cpuset=1-4, অর্থাৎ টাস্কের জন্য মেশিনে চারটি নির্দিষ্ট কোর বরাদ্দ করুন।
• ব্যবহার করতে --cpuquota=400_000 --cpuperiod=100_000, প্রসেসর সময়ের জন্য একটি কোটা বরাদ্দ করুন, অর্থাৎ নির্দেশ করুন যে প্রতি 100 ms রিয়েল টাইমে টাস্কটি 400 ms এর বেশি প্রসেসর সময় নেয় না। একই চারটি কোর পাওয়া যায়।

কিন্তু এই পদ্ধতিগুলির মধ্যে কোনটি উপযুক্ত?

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

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

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

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

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

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

কিন্তু আপনি জাভাতে প্রোগ্রাম না করলেও, chrt কমান্ড ব্যবহার করে একই জিনিস করা যেতে পারে:

chrt -i 0 $pid

আসুন স্বচ্ছতার জন্য আমাদের সমস্ত বিচ্ছিন্নতা স্তরগুলিকে একটি টেবিলে সংক্ষিপ্ত করা যাক:

অন্তরণ শ্রেণি
Alloc উদাহরণ
ডকার রান অপশন
sched_setscheduler chrt*

শঙ্কু
cpu = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

দল
CPU = [1, *)
--cpushares=1024
SCHED_BATCH

অলস
CPU= [2, *)
--cpushares=2048
SCHED_IDLE

*আপনি যদি একটি পাত্রের ভিতর থেকে chrt করছেন, তাহলে আপনার sys_nice ক্ষমতার প্রয়োজন হতে পারে, কারণ ডিফল্টরূপে ডকার কন্টেইনার শুরু করার সময় এই ক্ষমতাটি সরিয়ে দেয়।

তবে কাজগুলি কেবল প্রসেসরই নয়, ট্র্যাফিকও গ্রাস করে, যা প্রসেসর সংস্থানগুলির ভুল বরাদ্দের চেয়েও নেটওয়ার্ক টাস্কের বিলম্বকে প্রভাবিত করে। অতএব, আমরা স্বাভাবিকভাবেই ট্রাফিকের জন্য ঠিক একই ছবি পেতে চাই। অর্থাৎ, যখন একটি প্রোড টাস্ক নেটওয়ার্কে কিছু প্যাকেট পাঠায়, তখন আমরা সর্বোচ্চ গতি সীমিত করি (সূত্র alloc: lan=[*,500mbps) ), যা দিয়ে প্রোড এটি করতে পারে। এবং ব্যাচের জন্য আমরা কেবলমাত্র সর্বনিম্ন থ্রুপুট গ্যারান্টি দিই, তবে সর্বাধিক সীমাবদ্ধ করি না (সূত্র alloc: lan=[10Mbps,*) ) এই ক্ষেত্রে, প্রোড ট্র্যাফিককে ব্যাচের কাজগুলির চেয়ে অগ্রাধিকার দেওয়া উচিত।
এখানে ডকারের কোনো আদিম নেই যা আমরা ব্যবহার করতে পারি। কিন্তু এটা আমাদের সাহায্য আসে লিনাক্স ট্রাফিক কন্ট্রোল. শৃঙ্খলার সাহায্যে আমরা কাঙ্খিত ফলাফল অর্জন করতে পেরেছি হায়ারার্কিক্যাল ফেয়ার সার্ভিস কার্ভ. এর সাহায্যে, আমরা দুটি শ্রেণীর ট্রাফিককে আলাদা করি: উচ্চ-অগ্রাধিকার প্রোড এবং নিম্ন-অগ্রাধিকার ব্যাচ/অলস। ফলস্বরূপ, বহির্গামী ট্র্যাফিকের কনফিগারেশনটি এইরকম:

এখানে 1:0 হল hsfc ডিসিপ্লিনের "রুট qdisc"; 1:1 - 8 Gbit/s এর মোট ব্যান্ডউইথ সীমা সহ hsfc চাইল্ড ক্লাস, যার অধীনে সমস্ত কন্টেইনারের চাইল্ড ক্লাস রাখা হয়; 1:2 - hsfc চাইল্ড ক্লাস একটি "গতিশীল" সীমা সহ সমস্ত ব্যাচ এবং নিষ্ক্রিয় কাজের জন্য সাধারণ, যা নীচে আলোচনা করা হয়েছে৷ অবশিষ্ট hsfc চাইল্ড ক্লাসগুলি বর্তমানে চলমান প্রোড কন্টেইনারগুলির জন্য নিবেদিত ক্লাস যা তাদের ম্যানিফেস্টের সাথে সামঞ্জস্যপূর্ণ - 450 এবং 400 Mbit/s। প্রতিটি hsfc ক্লাসে একটি qdisc queue fq বা fq_codel বরাদ্দ করা হয়, লিনাক্স কার্নেল সংস্করণের উপর নির্ভর করে, ট্র্যাফিক বিস্ফোরণের সময় প্যাকেটের ক্ষতি এড়াতে।

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

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

ইনকামিং এবং আউটগোয়িং ট্র্যাফিকের জন্য ব্যান্ডগুলি স্বাধীনভাবে সংজ্ঞায়িত করা হয়। এবং নতুন মান অনুযায়ী, miniond অ-অগ্রাধিকার শ্রেণী সীমা 1:2 পুনরায় কনফিগার করে।

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

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

অতিরিক্ত লাইনগুলি আবার সরিয়ে দিয়ে, আমরা সম্পূর্ণ পরিষেবার নামের শেষে টাস্ক আইসোলেশন ক্লাস যোগ করে আমাদের পরিষেবার নাম ফ্ল্যাটার লিখতে পারি: web.front.prod, catalog.music.batch, transformer.music.idle.

এবং এখন, পরিষেবাটির নাম দেখে, আমরা বুঝতে পারি যে এটি কী ফাংশন সম্পাদন করে তা নয়, এর বিচ্ছিন্নতা শ্রেণী, যার অর্থ এটির সমালোচনা ইত্যাদি।

সবকিছু দুর্দান্ত, তবে একটি তিক্ত সত্য রয়েছে। একটি মেশিনে চলমান কাজগুলি সম্পূর্ণরূপে বিচ্ছিন্ন করা অসম্ভব।

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

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

উপরন্তু, আমরা এখনও পর্যন্ত শুধুমাত্র TCP ট্রাফিককে অগ্রাধিকার দেওয়ার সমস্যা সমাধান করতে পেরেছি: hsfc পদ্ধতি UDP-এর জন্য কাজ করে না। এমনকি TCP ট্র্যাফিকের ক্ষেত্রেও, যদি ব্যাচ টাস্কটি প্রচুর ট্র্যাফিক তৈরি করে, এটি প্রোড টাস্কের বিলম্বে প্রায় 10% বৃদ্ধি দেয়।

দোষ সহনশীলতা

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

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

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

একটি সম্পূর্ণ মিনিয়ন অনুপলব্ধ হলে আপনি কি করতে পারেন?

স্পষ্টতই, অন্য মেশিনে ধারক চালান। এখানে আকর্ষণীয় অংশ হল কন্টেইনারে বরাদ্দ করা আইপি ঠিকানা(গুলি) এর সাথে কী ঘটে।

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

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

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

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

পরবর্তীকালে, এই ঠিকানাগুলি পরিবর্তিত হয় না: এগুলি একবার বরাদ্দ করা হয় এবং উত্পাদনে পরিষেবার সারা জীবন ধরে বিদ্যমান থাকে। IP ঠিকানাগুলি নেটওয়ার্ক জুড়ে কন্টেইনার অনুসরণ করে। যদি ধারকটি অন্য মিনিয়নে স্থানান্তরিত হয়, তবে ঠিকানাটি এটি অনুসরণ করবে।

সুতরাং, আইপি ঠিকানাগুলির তালিকায় একটি পরিষেবার নামের ম্যাপিং খুব কমই পরিবর্তিত হয়। আপনি যদি নিবন্ধের শুরুতে উল্লেখ করা পরিষেবার উদাহরণগুলির নামগুলি আবার দেখেন (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), আমরা লক্ষ্য করব যে তারা DNS-এ ব্যবহৃত FQDN-এর সাথে সাদৃশ্যপূর্ণ। এটা ঠিক, পরিষেবার উদাহরণগুলির নাম তাদের IP ঠিকানায় ম্যাপ করতে, আমরা DNS প্রোটোকল ব্যবহার করি। অধিকন্তু, এই DNS সমস্ত কন্টেইনারের সমস্ত সংরক্ষিত IP ঠিকানা ফেরত দেয় - চলমান এবং বন্ধ উভয়ই (আসুন তিনটি প্রতিলিপি ব্যবহার করা হয়েছে, এবং আমাদের সেখানে পাঁচটি ঠিকানা সংরক্ষিত আছে - পাঁচটিই ফেরত দেওয়া হবে)। ক্লায়েন্টরা, এই তথ্যটি পেয়ে, পাঁচটি প্রতিলিপির সাথে একটি সংযোগ স্থাপন করার চেষ্টা করবে - এবং এইভাবে যেগুলি কাজ করছে তা নির্ধারণ করবে। প্রাপ্যতা নির্ধারণের জন্য এই বিকল্পটি অনেক বেশি নির্ভরযোগ্য; এটি DNS বা পরিষেবা আবিষ্কারের সাথে জড়িত নয়, যার অর্থ এই সিস্টেমগুলির তথ্যের প্রাসঙ্গিকতা এবং ত্রুটি সহনশীলতা নিশ্চিত করার ক্ষেত্রে সমাধান করা কোন কঠিন সমস্যা নেই। তদুপরি, সমালোচনামূলক পরিষেবাগুলিতে যার উপর পুরো পোর্টালের ক্রিয়াকলাপ নির্ভর করে, আমরা মোটেই DNS ব্যবহার করতে পারি না, তবে কনফিগারেশনে কেবল আইপি ঠিকানাগুলি প্রবেশ করাতে পারি।

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

ধরা যাক এক-ক্লাউড মাস্টার মিনিয়ন এম 1 কে চালানোর জন্য কমান্ড দেয় 1.ok-web.group1.web.front.prod ঠিকানা 1.1.1.1 সহ। একটি মিনিয়নে কাজ করে পাখি, যা বিশেষ সার্ভারে এই ঠিকানার বিজ্ঞাপন দেয় রুট প্রতিফলক. পরবর্তীতে নেটওয়ার্ক হার্ডওয়্যারের সাথে একটি BGP সেশন আছে, যেখানে M1.1.1.1-এ ঠিকানা 1 এর রুট অনুবাদ করা হয়েছে। লিনাক্স ব্যবহার করে পাত্রের ভিতরে M1 রুট প্যাকেট। তিনটি রুট প্রতিফলক সার্ভার রয়েছে, যেহেতু এটি এক-ক্লাউড অবকাঠামোর একটি অত্যন্ত গুরুত্বপূর্ণ অংশ - সেগুলি ছাড়া, এক-ক্লাউডে নেটওয়ার্ক কাজ করবে না। আমরা এগুলিকে বিভিন্ন র্যাকে রাখি, যদি সম্ভব হয় ডেটা সেন্টারের বিভিন্ন কক্ষে অবস্থিত, একই সময়ে তিনটি ব্যর্থ হওয়ার সম্ভাবনা কমাতে।

আসুন এখন ধরে নিই যে ওয়ান-ক্লাউড মাস্টার এবং M1 মিনিয়নের মধ্যে সংযোগটি হারিয়ে গেছে। ওয়ান-ক্লাউড মাস্টার এখন এই অনুমানে কাজ করবে যে M1 সম্পূর্ণভাবে ব্যর্থ হয়েছে। অর্থাৎ এটি M2 মিনিয়নকে লঞ্চ করার কমান্ড দেবে web.group1.web.front.prod একই ঠিকানা সহ 1.1.1.1। এখন আমাদের নেটওয়ার্কে 1.1.1.1-এর জন্য দুটি বিরোধপূর্ণ রুট রয়েছে: M1 এবং M2-এ। এই ধরনের দ্বন্দ্ব সমাধানের জন্য, আমরা মাল্টি এক্সিট ডিসক্রিমিনেটর ব্যবহার করি, যা BGP ঘোষণায় উল্লেখ করা আছে। এটি এমন একটি সংখ্যা যা বিজ্ঞাপিত রুটের ওজন দেখায়। বিরোধপূর্ণ রুটের মধ্যে, নিম্ন MED মান সহ রুট নির্বাচন করা হবে। এক-ক্লাউড মাস্টার কনটেইনার আইপি ঠিকানাগুলির একটি অবিচ্ছেদ্য অংশ হিসাবে MED সমর্থন করে। প্রথমবারের মতো, ঠিকানাটি যথেষ্ট বড় MED = 1 দিয়ে লেখা হয়েছে। এই ধরনের জরুরি কন্টেইনার স্থানান্তরের পরিস্থিতিতে, মাস্টার MED কমিয়ে দেয় এবং M000 ইতিমধ্যেই MED = এর সাথে 000 ঠিকানার বিজ্ঞাপন দেওয়ার জন্য কমান্ড পাবে। 2. এম 1.1.1.1 এ চলমান উদাহরণটি এই ক্ষেত্রেই থাকবে কোন সংযোগ নেই, এবং তার পরবর্তী ভাগ্য আমাদের খুব কমই আগ্রহী যতক্ষণ না মাস্টারের সাথে সংযোগ পুনরুদ্ধার করা হয়, যখন তাকে পুরানো নেওয়ার মতো বন্ধ করা হবে।

দুর্ঘটনা

সমস্ত ডেটা সেন্টার ম্যানেজমেন্ট সিস্টেম সর্বদা ছোটখাটো ব্যর্থতা গ্রহণযোগ্যভাবে পরিচালনা করে। কন্টেইনার ওভারফ্লো প্রায় সর্বত্র আদর্শ।

চলুন দেখে নেওয়া যাক কিভাবে আমরা একটি ডাটা সেন্টারের এক বা একাধিক কক্ষে পাওয়ার ব্যর্থতার মতো জরুরী পরিস্থিতি মোকাবেলা করি।

ডেটা সেন্টার ম্যানেজমেন্ট সিস্টেমের জন্য দুর্ঘটনার অর্থ কী? প্রথমত, এটি অনেক মেশিনের একটি বিশাল এক-সময়ের ব্যর্থতা, এবং নিয়ন্ত্রণ ব্যবস্থাকে একই সময়ে অনেকগুলি পাত্র স্থানান্তর করতে হবে। কিন্তু যদি বিপর্যয়টি খুব বড় আকারের হয়, তবে এটি ঘটতে পারে যে সমস্ত কাজ অন্য মিনিয়নগুলিতে পুনরায় বরাদ্দ করা যাবে না, কারণ ডেটা সেন্টারের সংস্থান ক্ষমতা লোডের 100% নীচে নেমে যায়।

প্রায়শই দুর্ঘটনা নিয়ন্ত্রণ স্তরের ব্যর্থতার দ্বারা অনুষঙ্গী হয়। এটি তার সরঞ্জামগুলির ব্যর্থতার কারণে ঘটতে পারে, তবে প্রায়শই দুর্ঘটনাগুলি পরীক্ষা করা হয় না এবং বর্ধিত লোডের কারণে নিয়ন্ত্রণ স্তর নিজেই পড়ে যায়।

আপনি এই সব সম্পর্কে কি করতে পারেন?

ব্যাপক স্থানান্তর বলতে বোঝায় যে পরিকাঠামোতে প্রচুর সংখ্যক কার্যকলাপ, স্থানান্তর এবং স্থাপনা ঘটছে। প্রতিটি মাইগ্রেশনের জন্য মিনিয়নদের কাছে কন্টেইনার ইমেজ বিতরণ এবং আনপ্যাক করতে, কন্টেইনারগুলি চালু করা এবং শুরু করা ইত্যাদির জন্য কিছু সময় লাগতে পারে৷ তাই, কম গুরুত্বপূর্ণগুলির আগে আরও গুরুত্বপূর্ণ কাজগুলি চালু করা বাঞ্ছনীয়৷

আসুন আমরা পরিচিত পরিষেবাগুলির শ্রেণিবিন্যাসটি আবার দেখি এবং আমরা কোন কাজগুলি প্রথমে চালাতে চাই তা নির্ধারণ করার চেষ্টা করি৷

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

প্রোডে আমরা উচ্চতর অগ্রাধিকার বরাদ্দ করি, 0; ব্যাচে - একটু কম, 100; নিষ্ক্রিয় - এমনকি কম, 200। অগ্রাধিকারগুলি শ্রেণিবদ্ধভাবে প্রয়োগ করা হয়। শ্রেণিবিন্যাসের নীচের সমস্ত কাজগুলির একটি অনুরূপ অগ্রাধিকার থাকবে৷ যদি আমরা চাই যে প্রোডের ভিতরের ক্যাশেগুলি ফ্রন্টএন্ডের আগে চালু করা হোক, তাহলে আমরা ক্যাশে = 0 এবং সামনের সাবকিউ = 1-কে অগ্রাধিকার প্রদান করি। উদাহরণস্বরূপ, আমরা প্রধান পোর্টালটি প্রথমে ফ্রন্ট থেকে চালু করতে চাই এবং শুধুমাত্র মিউজিক ফ্রন্টে তারপর, তারপরে আমরা পরেরটির জন্য একটি নিম্ন অগ্রাধিকার নির্ধারণ করতে পারি - 10।

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

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

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

পুরো ডিসি দুর্ঘটনা

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

এবং কাউকে #লাইভ টুইট করা থেকে বিরত রাখতে আমরা এটিই করি।

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

এই পদ্ধতিটি শুধুমাত্র শারীরিক ব্যর্থতা থেকে রক্ষা করে না, তবে অপারেটর ত্রুটি থেকেও রক্ষা করতে পারে।

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

ফলাফল

এক-মেঘের স্বতন্ত্র বৈশিষ্ট্য:

• পরিষেবা এবং কন্টেইনারগুলির জন্য অনুক্রমিক এবং ভিজ্যুয়াল নামকরণ স্কিম, যা আপনাকে কাজটি কী, এটি কী সম্পর্কিত এবং এটি কীভাবে কাজ করে এবং এর জন্য কারা দায়ী তা খুব দ্রুত খুঁজে বের করতে দেয়।
• আমরা আমাদের আবেদন প্রোড- এবং ব্যাচ-কে একত্রিত করার কৌশলমেশিন শেয়ারিং এর দক্ষতা উন্নত করতে minions উপর কাজ. cpuset এর পরিবর্তে আমরা CPU কোটা, শেয়ার, CPU শিডিউলার নীতি এবং Linux QoS ব্যবহার করি।
• একই মেশিনে চলমান পাত্রে সম্পূর্ণরূপে বিচ্ছিন্ন করা সম্ভব ছিল না, তবে তাদের পারস্পরিক প্রভাব 20% এর মধ্যে রয়ে গেছে।
• একটি অনুক্রমের মধ্যে পরিষেবাগুলি সংগঠিত করা স্বয়ংক্রিয় দুর্যোগ পুনরুদ্ধার ব্যবহার করে সাহায্য করে৷ স্থান নির্ধারণ এবং অগ্রাধিকার অগ্রাধিকার.

FAQ

আমরা কেন রেডিমেড সমাধান নিলাম না?

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

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

যারা শেষ লাইনগুলি পড়েছেন, আপনার ধৈর্য এবং মনোযোগের জন্য আপনাকে ধন্যবাদ!

উত্স: www.habr.com