AERODISK VAIR হাইপারকনভারজড সমাধান। ভিত্তি হল ARDFS ফাইল সিস্টেম

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

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

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

Aerodisk স্টোরেজ সিস্টেম সম্পর্কে একটি গল্প? বা কেন আমরা প্রথম স্থানে হাইপারকনভারজেন্স করতে শুরু করেছি?

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

আমরা অনেক ওপেন সোর্স সমাধান চেষ্টা করেছি এবং অবশেষে এই সমস্যার সমাধান করেছি, কিন্তু সমাধানটি খুব জটিল এবং পুনরাবৃত্তি করা কঠিন ছিল। এছাড়াও, এই সমাধানটি "এটি কি কাজ করে? স্পর্শ করবেন না! অতএব, সেই সমস্যাটি সমাধান করার পরে, আমরা আমাদের কাজের ফলাফলকে একটি পূর্ণাঙ্গ পণ্যে রূপান্তরিত করার ধারণাটি আর বিকাশ করিনি।

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

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

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

প্রথম vAIR ধারণা

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

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

আমরা ফাইল সিস্টেমের নাম নিয়ে খুব বেশি মাথা ঘামাইনি এবং সংক্ষিপ্তভাবে এটিকে ARDFS বলেছি (অনুমান করুন এটি কী বোঝায়))

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

ঠিক সেই সময়ের মধ্যে, সমাধানের সাধারণ স্থাপত্য পরিপক্ক হয়েছিল, যা এখনও বড় পরিবর্তনের মধ্য দিয়ে যায়নি।

ARDFS ফাইল সিস্টেমে ডাইভিং

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

স্টোরেজ গঠন

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

ভার্চুয়াল ডিস্ক (ভার্চুয়াল মেশিনের জন্য স্টোরেজ অবজেক্ট) ARDFS পুলের উপরে যোগ করা হয়, যেগুলো 4 মেগাবাইটের আকারের ভার্চুয়াল ব্লক থেকে তৈরি করা হয়। ভার্চুয়াল ডিস্ক সরাসরি ডেটা সঞ্চয় করে। ফল্ট টলারেন্স স্কিম ভার্চুয়াল ডিস্ক লেভেলেও সেট করা আছে।

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

এমন একটি পরিস্থিতিতে যেখানে আপনি সত্যিই RAID চান (উদাহরণস্বরূপ, একটি দৃশ্য যা ছোট ক্লাস্টারে একাধিক ব্যর্থতা সমর্থন করে), স্থানীয় RAID কন্ট্রোলার ব্যবহার করতে এবং প্রসারিত স্টোরেজ এবং উপরে একটি RAIN আর্কিটেকচার তৈরি করা থেকে কিছুই আপনাকে বাধা দেয় না। এই দৃশ্যটি বেশ লাইভ এবং আমাদের দ্বারা সমর্থিত, তাই আমরা এটি সম্পর্কে একটি নিবন্ধে কথা বলব vAIR ব্যবহার করার জন্য সাধারণ পরিস্থিতি সম্পর্কে।

স্টোরেজ ফল্ট টলারেন্স স্কিম

VAIR-এ ভার্চুয়াল ডিস্কের জন্য দুটি ফল্ট টলারেন্স স্কিম থাকতে পারে:

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

নীচে সাধারণ মোডে এবং ব্যর্থতার পরিস্থিতিতে RF-2 এবং RF-3 ডেটা বিতরণের উদাহরণ রয়েছে।

আমাদের কাছে একটি ভার্চুয়াল মেশিন রয়েছে যার ধারণক্ষমতা 8MB অনন্য (উপযোগী) ডেটা, যা 4টি VAIR নোডে চলে৷ এটা স্পষ্ট যে বাস্তবে এটি অসম্ভাব্য যে এত ছোট ভলিউম থাকবে, কিন্তু একটি প্রকল্পের জন্য যা ARDFS অপারেশনের যুক্তি প্রতিফলিত করে, এই উদাহরণটি সবচেয়ে বোধগম্য। AB হল 4MB ভার্চুয়াল ব্লক যাতে অনন্য ভার্চুয়াল মেশিন ডেটা থাকে। RF-2 এই ব্লকগুলির দুটি কপি তৈরি করে যথাক্রমে A1+A2 এবং B1+B2। এই ব্লকগুলি নোড জুড়ে "বিন্যস্ত" হয়, একই নোডে একই ডেটার ছেদ এড়িয়ে, অর্থাৎ, অনুলিপি A1 অনুলিপি A2 এর মতো একই নোডে অবস্থিত হবে না। B1 এবং B2 এর সাথে একই।

যদি নোডগুলির মধ্যে একটি ব্যর্থ হয় (উদাহরণস্বরূপ, নোড নং 3, যাতে B1 এর একটি অনুলিপি রয়েছে), এই অনুলিপিটি স্বয়ংক্রিয়ভাবে নোডে সক্রিয় হয় যেখানে এর অনুলিপিটির কোন অনুলিপি নেই (অর্থাৎ, B2 এর একটি অনুলিপি)।

এইভাবে, ভার্চুয়াল ডিস্ক (এবং VM, সেই অনুযায়ী) RF-2 স্কিমে একটি নোডের ব্যর্থতা থেকে সহজেই বেঁচে থাকতে পারে।

রেপ্লিকেশন স্কিম, সহজ এবং নির্ভরযোগ্য হলেও, RAID1-এর মতো একই সমস্যায় ভুগছে - পর্যাপ্ত ব্যবহারযোগ্য স্থান নয়।

2) ইরেজার কোডিং বা ইরেজার কোডিং ("অপ্রয়োজনীয় কোডিং", "ইরেজার কোডিং" বা "রিডানডেন্সি কোড" নামেও পরিচিত) উপরের সমস্যাটি সমাধান করার জন্য বিদ্যমান। EC একটি রিডানডেন্সি স্কিম যা প্রতিলিপির তুলনায় কম ডিস্কের ওভারহেডের সাথে উচ্চ ডেটা উপলব্ধতা প্রদান করে। এই প্রক্রিয়াটির অপারেটিং নীতিটি RAID 5, 6, 6P এর মতো।

এনকোডিং করার সময়, EC প্রক্রিয়া একটি ভার্চুয়াল ব্লককে (ডিফল্টভাবে 4MB) EC স্কিমের উপর নির্ভর করে কয়েকটি ছোট "ডেটা খণ্ডে" ভাগ করে (উদাহরণস্বরূপ, একটি 2+1 স্কিম প্রতিটি 4MB ব্লককে 2 2MB খণ্ডে ভাগ করে)। এর পরে, এই প্রক্রিয়াটি "ডেটা খণ্ডগুলির" জন্য "প্যারিটি খণ্ড" তৈরি করে যা পূর্বে বিভক্ত অংশগুলির একটির চেয়ে বড় নয়। ডিকোড করার সময়, EC সমগ্র ক্লাস্টার জুড়ে "বেঁচে থাকা" ডেটা পড়ার মাধ্যমে অনুপস্থিত অংশগুলি তৈরি করে।

উদাহরণস্বরূপ, একটি 2 + 1 EC স্কিম সহ একটি ভার্চুয়াল ডিস্ক, 4 টি ক্লাস্টার নোডে প্রয়োগ করা হয়েছে, RF-2 এর মতো ক্লাস্টারে একটি নোডের ব্যর্থতা সহজেই সহ্য করবে। এই ক্ষেত্রে, ওভারহেড খরচ কম হবে, বিশেষত, RF-2 এর জন্য দরকারী ক্ষমতা সহগ 2, এবং EC 2+1 এর জন্য এটি 1,5 হবে।

এটিকে আরও সহজভাবে বর্ণনা করার জন্য, সারমর্মটি হল ভার্চুয়াল ব্লকটি 2-8 ভাগে বিভক্ত (কেন 2 থেকে 8 পর্যন্ত, নীচে দেখুন) "টুকরা", এবং এই টুকরাগুলির জন্য একটি অনুরূপ আয়তনের সমতার "টুকরা" গণনা করা হয়।

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

নীচে একটি উদাহরণ দেওয়া হল, একই 8 MB ভার্চুয়াল মেশিন এবং 4 নোড সহ, কিন্তু একটি EC 2+1 স্কিম সহ৷

ব্লক A এবং B প্রতিটি 2 MB এর দুটি টুকরোতে বিভক্ত (দুটি কারণ 2+1), অর্থাৎ A1+A2 এবং B1+B2। একটি প্রতিরূপের বিপরীতে, A1 A2 এর একটি অনুলিপি নয়, এটি একটি ভার্চুয়াল ব্লক A, দুটি অংশে বিভক্ত, ব্লক B এর সাথে একই। মোট, আমরা 4MB এর দুটি সেট পেয়েছি, যার প্রতিটিতে দুটি টু-এমবি টুকরা রয়েছে। এর পরে, এই সেটগুলির প্রতিটির জন্য, প্যারিটি এক টুকরো (অর্থাৎ 2 এমবি) এর ভলিউম সহ গণনা করা হয়, আমরা একটি অতিরিক্ত + 2 টুকরা প্যারিটি (এপি এবং বিপি) পাই। মোট আমাদের 4×2 ডেটা + 2×2 সমতা রয়েছে।

এর পরে, নোডগুলির মধ্যে টুকরোগুলি "বিছান" করা হয় যাতে ডেটা তাদের সমতার সাথে ছেদ না করে। সেগুলো. A1 এবং A2 AP এর মতো একই নোডে থাকবে না।

একটি নোডের ব্যর্থতার ক্ষেত্রে (উদাহরণস্বরূপ, তৃতীয়টিও), পতিত ব্লক B1 স্বয়ংক্রিয়ভাবে BP প্যারিটি থেকে পুনরুদ্ধার করা হবে, যা নোড নং 2-এ সংরক্ষিত আছে এবং নোড যেখানে আছে সেখানে সক্রিয় করা হবে বি-প্যারিটি নেই, যেমন BP এর টুকরা। এই উদাহরণে, এটি নোড নং 1

আমি নিশ্চিত যে পাঠকের একটি প্রশ্ন আছে:

"আপনি যা বর্ণনা করেছেন তার সবকিছুই প্রতিযোগী এবং ওপেন সোর্স সলিউশন উভয়ের দ্বারাই দীর্ঘদিন প্রয়োগ করা হয়েছে, ARDFS-এ আপনার EC বাস্তবায়নের মধ্যে পার্থক্য কী?"

এবং তারপর ARDFS এর আকর্ষণীয় বৈশিষ্ট্য থাকবে।

নমনীয়তার উপর ফোকাস সহ ইরেজার কোডিং

প্রাথমিকভাবে, আমরা একটি মোটামুটি নমনীয় EC X+Y স্কিম দিয়েছিলাম, যেখানে X হল 2 থেকে 8 পর্যন্ত একটি সংখ্যার সমান, এবং Y হল 1 থেকে 8 পর্যন্ত একটি সংখ্যার সমান, কিন্তু সবসময় X এর থেকে কম বা সমান। এই স্কিমটি প্রদান করা হয়। নমনীয়তার জন্য। ভার্চুয়াল ব্লক ভাগ করা হয়েছে এমন ডেটা পিস (X) সংখ্যা বাড়ানো ওভারহেড খরচ কমাতে দেয়, অর্থাৎ ব্যবহারযোগ্য স্থান বৃদ্ধি করে।
প্যারিটি খণ্ডের সংখ্যা বৃদ্ধি (Y) ভার্চুয়াল ডিস্কের নির্ভরযোগ্যতা বাড়ায়। Y মান যত বড় হবে, ক্লাস্টারে তত বেশি নোড ব্যর্থ হতে পারে। অবশ্যই, প্যারিটি ভলিউম বাড়ানো ব্যবহারযোগ্য ক্ষমতার পরিমাণ হ্রাস করে, তবে এটি নির্ভরযোগ্যতার জন্য একটি মূল্য।

ইসি সার্কিটের উপর পারফরম্যান্সের নির্ভরতা প্রায় সরাসরি: যত বেশি "টুকরা", কর্মক্ষমতা তত কম; এখানে অবশ্যই, একটি সুষম দৃষ্টিভঙ্গি প্রয়োজন।

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

নীচে বেশ কয়েকটি (সমস্ত সম্ভব নয়) RF এবং EC স্কিমগুলির তুলনা করার একটি টেবিল রয়েছে৷

টেবিলটি দেখায় যে এমনকি সবচেয়ে "টেরি" সংমিশ্রণ EC 8+7, যা একই সাথে একটি ক্লাস্টারে 7টি নোডের ক্ষতি করতে দেয়, স্ট্যান্ডার্ড রেপ্লিকেশনের তুলনায় কম ব্যবহারযোগ্য স্থান (1,875 বনাম 2) "খায়" এবং 7 গুণ ভাল সুরক্ষা দেয় , যা এই সুরক্ষা ব্যবস্থাকে করে তোলে, যদিও আরও জটিল, অনেক বেশি আকর্ষণীয় পরিস্থিতিতে যেখানে এটি সীমিত ডিস্ক স্থানের পরিস্থিতিতে সর্বাধিক নির্ভরযোগ্যতা নিশ্চিত করা প্রয়োজন। একই সময়ে, আপনাকে বুঝতে হবে যে প্রতিটি "প্লাস" থেকে X বা Y একটি অতিরিক্ত কর্মক্ষমতা ওভারহেড হবে, তাই নির্ভরযোগ্যতা, সঞ্চয় এবং কর্মক্ষমতার মধ্যে ত্রিভুজটিতে আপনাকে খুব সাবধানে নির্বাচন করতে হবে। এই কারণে, আমরা কোডিং সাইজিং মুছে ফেলার জন্য একটি পৃথক নিবন্ধ উৎসর্গ করব।

ফাইল সিস্টেমের নির্ভরযোগ্যতা এবং স্বায়ত্তশাসন

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

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

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

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

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

কে এই অলৌকিক ঘটনা প্রয়োজন?

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

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

স্টোরেজ সিস্টেম কখন GCS এর চেয়ে ভাল?

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

সত্যিকার অর্থে, স্টোরেজ মার্কেট প্রকৃতপক্ষে হাইপারকনভারজেন্স এবং অনুরূপ সমাধানের দিকে অগ্রসর হচ্ছে, তবে সর্বদা একটি "কিন্তু" থাকে।

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

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

তৃতীয়ত, প্রতি লেখায় 2 মিলিসেকেন্ডের অতিরিক্ত ছোট বিলম্বের একটি সম্পূর্ণরূপে প্রযুক্তিগত সীমাবদ্ধতা রয়েছে (অবশ্যই স্থানীয় ক্যাশে ব্যতীত), যা বিতরণ করা স্টোরেজের খরচ।

ঠিক আছে, আসুন বৃহৎ শারীরিক সার্ভারগুলির ব্যবহার সম্পর্কে ভুলবেন না যা ডিস্ক সাবসিস্টেমের উল্লম্ব স্কেলিং পছন্দ করে।

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

এবং হাইপারকনভার্জড সমাধানগুলি স্টোরেজ সিস্টেমের চেয়ে ভাল কোথায় কাজ করবে?

উপরের পয়েন্টগুলির উপর ভিত্তি করে, তিনটি সুস্পষ্ট উপসংহার টানা যেতে পারে:

1. যেখানে রেকর্ডিংয়ের জন্য অতিরিক্ত 2 মিলিসেকেন্ডের লেটেন্সি, যা ধারাবাহিকভাবে যে কোনও পণ্যে ঘটে (এখন আমরা সিনথেটিক্সের কথা বলছি না, ন্যানোসেকেন্ডগুলি সিন্থেটিক্সে দেখানো যেতে পারে), এটি সমালোচনামূলক নয়, হাইপারকনভারজেন্ট উপযুক্ত।
2. যেখানে বড় ফিজিক্যাল সার্ভার থেকে লোডকে অনেক ছোট ভার্চুয়ালে পরিণত করা যায় এবং নোডের মধ্যে বিতরণ করা যায়, সেখানে হাইপারকনভারজেন্সও ভালো কাজ করবে।
3. যেখানে অনুভূমিক স্কেলিং উল্লম্ব স্কেলিং থেকে একটি উচ্চ অগ্রাধিকার, সেখানেও GCS ঠিকঠাক কাজ করবে।

এই সমাধান কি?

1. সমস্ত স্ট্যান্ডার্ড অবকাঠামো পরিষেবা (ডিরেক্টরি পরিষেবা, মেল, ইডিএমএস, ফাইল সার্ভার, ছোট বা মাঝারি ইআরপি এবং বিআই সিস্টেম ইত্যাদি)। আমরা এটিকে "সাধারণ কম্পিউটিং" বলি।
2. ক্লাউড প্রদানকারীদের অবকাঠামো, যেখানে ক্লায়েন্টদের জন্য একটি বড় সংখ্যক ভার্চুয়াল মেশিনকে দ্রুত এবং মানসম্মতভাবে অনুভূমিকভাবে প্রসারিত করা এবং সহজেই "কাট" করা প্রয়োজন।
3. ভার্চুয়াল ডেস্কটপ অবকাঠামো (ভিডিআই), যেখানে অনেক ছোট ব্যবহারকারী ভার্চুয়াল মেশিন চলে এবং শান্তভাবে একটি অভিন্ন ক্লাস্টারের মধ্যে "ভাসতে থাকে"।
4. শাখা নেটওয়ার্ক, যেখানে প্রতিটি শাখার জন্য একটি মানক, ত্রুটি-সহনশীল, কিন্তু 15-20টি ভার্চুয়াল মেশিনের সস্তা অবকাঠামো প্রয়োজন।
5. যেকোনো বিতরণ করা কম্পিউটিং (উদাহরণস্বরূপ বড় ডেটা পরিষেবা)। যেখানে বোঝা যায় "গভীরতায়" নয়, "প্রস্থে"।
6. পরীক্ষার পরিবেশ যেখানে অতিরিক্ত ছোট বিলম্ব গ্রহণযোগ্য, তবে বাজেটের সীমাবদ্ধতা রয়েছে, কারণ এটি পরীক্ষা।

এই মুহুর্তে, এই কাজগুলির জন্যই আমরা AERODISK vAIR তৈরি করেছি এবং সেগুলির উপরই আমরা ফোকাস করছি (এখন পর্যন্ত সফলভাবে)। সম্ভবত এটি শীঘ্রই পরিবর্তন হবে, কারণ ... পৃথিবী স্থির থাকে না।

তাই…

এটি নিবন্ধগুলির একটি বড় সিরিজের প্রথম অংশটি সম্পূর্ণ করে; পরবর্তী নিবন্ধে আমরা সমাধানের স্থাপত্য এবং ব্যবহৃত উপাদানগুলি সম্পর্কে কথা বলব।

আমরা প্রশ্ন, পরামর্শ এবং গঠনমূলক বিরোধ স্বাগত জানাই.

উত্স: www.habr.com