AERODISK ইঞ্জিন: দুর্যোগ পুনরুদ্ধার। পার্ট 2. মেট্রোক্লাস্টার

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

যথারীতি, প্রথমে তত্ত্ব

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

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

এটা কী কাজ করে?

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

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

তদনুসারে, মেট্রোক্লাস্টার বা প্রশাসক দায়িত্ব পরিষেবার 99তম স্তরের একজন অমর প্রশাসকের অনুপস্থিতিতে আরটিও সমস্ত সিস্টেমের পরিবর্তনের সময়ের সমষ্টির সমান হবে এবং প্রশাসকের কাজ শুরু করার নিশ্চয়তা দেওয়া সর্বাধিক সময়ের সমান হবে। স্টোরেজ সিস্টেম এবং সম্পর্কিত সিস্টেমের সাথে।

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

এটা কিভাবে কাজ করে?

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

• পদার্থবিদ্যা হিসাবে অপটিক্যাল ফাইবার, 10 গিগাবিট ইথারনেট (বা উচ্চতর);
• ডেটা সেন্টারের মধ্যে দূরত্ব 40 কিলোমিটারের বেশি নয়;
• ডেটা সেন্টারের মধ্যে অপটিক্যাল চ্যানেল বিলম্ব (স্টোরেজ সিস্টেমের মধ্যে) 5 মিলিসেকেন্ড পর্যন্ত (অনুকূলভাবে 2)।

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

সুতরাং, স্টোরেজ সিস্টেমের মধ্যে ডেটা স্থানান্তর করতে একটি সিঙ্ক্রোনাস প্রতিরূপ ব্যবহার করা হয় এবং কীভাবে প্রতিলিপিগুলি স্বয়ংক্রিয়ভাবে স্যুইচ করে এবং সবচেয়ে গুরুত্বপূর্ণভাবে, কীভাবে বিভক্ত-মস্তিষ্ক এড়ানো যায়? এটি করার জন্য, একটি উচ্চ স্তরে, একটি অতিরিক্ত সত্তা ব্যবহার করা হয় - একটি সালিস।

একজন সালিস কিভাবে কাজ করে এবং তার কাজ কি?

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

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

একটি খুব গুরুত্বপূর্ণ পয়েন্ট. আরবিট্রেটরকে সর্বদা এমন একটি সাইটে থাকতে হবে যেখানে স্টোরেজ সিস্টেমগুলি অবস্থিত তার থেকে আলাদা, অর্থাৎ, ডাটা সেন্টার 1-এ নয়, যেখানে স্টোরেজ সিস্টেম 1 ইনস্টল করা আছে, না ডেটা সেন্টার 2-এ, যেখানে স্টোরেজ সিস্টেম 2 ইনস্টল করা আছে।

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

এখন সালিশের কাজের বিবরণে ডুব দেওয়া যাক।

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

আরও বিশদে সালিসের কাজের যুক্তি দেখি।

ধাপ 1: অনুপলব্ধতা নির্ধারণ করুন. একটি স্টোরেজ সিস্টেম ব্যর্থতার ঘটনা হল একই স্টোরেজ সিস্টেমের উভয় কন্ট্রোলার থেকে 5 সেকেন্ডের মধ্যে পিংয়ের অনুপস্থিতি।

ধাপ 2. স্যুইচিং পদ্ধতি শুরু করুন। আরবিটার উপলব্ধি করার পরে যে স্টোরেজ সিস্টেমগুলির মধ্যে একটি অনুপলব্ধ, তিনি "মৃত" স্টোরেজ সিস্টেমটি সত্যিই মৃত কিনা তা নিশ্চিত করার জন্য "লাইভ" স্টোরেজ সিস্টেমের কাছে একটি অনুরোধ পাঠান।

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

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

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

সময় ধাপ 2 আনুমানিক 5 - 10 সেকেন্ড সময় নেয়, এইভাবে, অনুপলব্ধতা (5 সেকেন্ড) নির্ধারণের জন্য প্রয়োজনীয় সময় বিবেচনা করে, দুর্ঘটনার 10 - 15 সেকেন্ডের মধ্যে, পতিত স্টোরেজ সিস্টেম থেকে LUNগুলি লাইভের সাথে কাজ করার জন্য স্বয়ংক্রিয়ভাবে উপলব্ধ হবে। সংরক্ষণ ব্যবস্থা.

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

এক সেকেন্ড অপেক্ষা করুন, দেখা যাচ্ছে যে মেট্রোক্লাস্টারের সাথে সবকিছু যদি এত ভাল হয় তবে কেন আমাদের নিয়মিত প্রতিলিপির প্রয়োজন হবে?

বাস্তবে, সবকিছু এত সহজ নয়।

আসুন মেট্রোক্লাস্টারের সুবিধা এবং অসুবিধাগুলি বিবেচনা করি

সুতরাং, আমরা বুঝতে পেরেছি যে প্রচলিত প্রতিলিপির তুলনায় মেট্রোক্লাস্টারের সুস্পষ্ট সুবিধাগুলি হল:

• সম্পূর্ণ অটোমেশন, দুর্যোগের ক্ষেত্রে ন্যূনতম পুনরুদ্ধারের সময় নিশ্চিত করা;
• এখানেই শেষ :-).

এবং এখন, মনোযোগ, অসুবিধাগুলি:

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

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

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

এই বিভাগটি মেট্রোক্লাস্টার ডিজাইনের জন্য একটি বিস্তৃত নির্দেশিকা বলে দাবি করে না, তবে আপনি যদি এই ধরনের একটি সিস্টেম তৈরি করার সিদ্ধান্ত নেন তবে শুধুমাত্র মূল দিকনির্দেশগুলি দেখায়। অতএব, বাস্তবে একটি মেট্রোক্লাস্টার বাস্তবায়ন করার সময়, পরামর্শের জন্য স্টোরেজ সিস্টেম প্রস্তুতকারক (অর্থাৎ আমাদের) এবং অন্যান্য সম্পর্কিত সিস্টেমগুলিকে জড়িত করতে ভুলবেন না।

ভেন্যু

উপরে উল্লিখিত হিসাবে, একটি মেট্রোক্লাস্টারের জন্য ন্যূনতম তিনটি সাইট প্রয়োজন। দুটি ডেটা সেন্টার যেখানে স্টোরেজ সিস্টেম এবং সম্পর্কিত সিস্টেমগুলি কাজ করবে, সেইসাথে একটি তৃতীয় সাইট যেখানে সালিস কাজ করবে।

ডেটা সেন্টারের মধ্যে প্রস্তাবিত দূরত্ব 40 কিলোমিটারের বেশি নয়। একটি বড় দূরত্ব অতিরিক্ত বিলম্বের কারণ হতে পারে, যা একটি মেট্রোক্লাস্টারের ক্ষেত্রে অত্যন্ত অনাকাঙ্ক্ষিত। আসুন আমরা আপনাকে মনে করিয়ে দিই যে বিলম্বগুলি 5 মিলিসেকেন্ড পর্যন্ত হওয়া উচিত, যদিও এটি 2 এর মধ্যে রাখার পরামর্শ দেওয়া হয়।

পরিকল্পনা প্রক্রিয়ার সময়ও বিলম্ব পরীক্ষা করার পরামর্শ দেওয়া হয়। ডেটা সেন্টারের মধ্যে অপটিক্যাল ফাইবার সরবরাহ করে এমন যেকোনো কম-বেশি প্রাপ্তবয়স্ক সরবরাহকারী বেশ দ্রুত একটি গুণমান পরীক্ষা সংগঠিত করতে পারে।

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

সুইচিং এবং নেটওয়ার্কিং

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

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

অবশ্যই, প্রতিটি হোস্টকে একটি অপটিক্যাল কর্ড দিয়ে অন্য ডেটা সেন্টারের সাথে সংযোগ করার দরকার নেই; কোন পোর্ট বা কর্ড যথেষ্ট হবে না। এই সমস্ত সংযোগগুলি অবশ্যই ইথারনেট 10G+ বা FibreChannel 8G+ সুইচগুলির মাধ্যমে করা উচিত (FC শুধুমাত্র IO-এর জন্য হোস্ট এবং স্টোরেজ সিস্টেমগুলিকে সংযুক্ত করার জন্য, প্রতিলিপি চ্যানেলটি বর্তমানে শুধুমাত্র IP (ইথারনেট 10G+) এর মাধ্যমে উপলব্ধ।

এখন নেটওয়ার্ক টপোলজি সম্পর্কে কয়েকটি শব্দ। একটি গুরুত্বপূর্ণ পয়েন্ট হল সাবনেটের সঠিক কনফিগারেশন। নিম্নলিখিত ধরণের ট্র্যাফিকের জন্য অবিলম্বে বেশ কয়েকটি সাবনেট সংজ্ঞায়িত করা প্রয়োজন:

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

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

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

আরবিটার কনফিগারেশন

আরবিটারকে অবশ্যই ICMP এবং SSH প্রোটোকলের মাধ্যমে স্টোরেজ সিস্টেমের সমস্ত ব্যবস্থাপনা ইন্টারফেসে অ্যাক্সেস প্রদান করতে হবে। আপনার আরবিটারের ব্যর্থতার কথাও ভাবা উচিত। এখানে একটি nuance আছে.

আরবিটার ফেইলওভার অত্যন্ত আকাঙ্খিত, কিন্তু প্রয়োজনীয় নয়। রেফারি ভুল সময়ে ক্রাশ হলে কি হবে?

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

এই থেকে অনুসরণ কি? আপনি যদি সত্যিই একটি ন্যূনতম RTO নিশ্চিত করতে চান, তাহলে আপনাকে নিশ্চিত করতে হবে যে আরবিটার দোষ-সহনশীল। এই জন্য দুটি বিকল্প আছে:

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

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

সমাধান আর্কিটেকচার

উপরের প্রয়োজনীয়তাগুলি বিবেচনা করে, আমরা নিম্নলিখিত সাধারণ সমাধান আর্কিটেকচার পাই।

গুরুতর ওভারলোড এড়াতে LUN দুটি সাইটে সমানভাবে বিতরণ করা উচিত। একই সময়ে, উভয় ডেটা সেন্টারে সাইজ করার সময়, আপনার শুধুমাত্র দ্বিগুণ ভলিউম অন্তর্ভুক্ত করা উচিত নয় (যা একই সাথে দুটি স্টোরেজ সিস্টেমে ডেটা সঞ্চয় করার জন্য প্রয়োজনীয়), তবে অ্যাপ্লিকেশনের অবক্ষয় রোধ করার জন্য IOPS এবং MB/s-এ দ্বিগুণ কর্মক্ষমতাও অন্তর্ভুক্ত করা উচিত। ডেটা সেন্টারগুলির একটির ব্যর্থতার ঘটনা।

আলাদাভাবে, আমরা লক্ষ করি যে আকার নির্ধারণের সঠিক পদ্ধতির সাথে (অর্থাৎ, যদি আমরা IOPS এবং MB/s এর সঠিক উপরের সীমা প্রদান করেছি, সেইসাথে প্রয়োজনীয় CPU এবং RAM সংস্থানগুলি প্রদান করেছি), যদি স্টোরেজ সিস্টেমগুলির মধ্যে একটি মেট্রো ক্লাস্টার ব্যর্থ হয়, একটি স্টোরেজ সিস্টেমে অস্থায়ী কাজ করার শর্তে কর্মক্ষমতাতে গুরুতর ড্রপ হবে না।

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

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

একটি মেট্রোক্লাস্টার স্থাপন করা হচ্ছে

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

একটি প্রতিরূপের জন্য ভার্চুয়াল আইপি (ভিআইপি) কনফিগার করার সময়, আপনাকে মেট্রোক্লাস্টারের জন্য ভিআইপি প্রকার নির্বাচন করা উচিত।

আমরা দুটি LUN-এর জন্য দুটি প্রতিলিপি লিঙ্ক তৈরি করেছি এবং সেগুলিকে দুটি স্টোরেজ সিস্টেমে বিতরণ করেছি: স্টোরেজ সিস্টেম 1-এ LUN TEST প্রাইমারি (METRO লিঙ্ক), LUN TEST2 প্রাইমারি স্টোরেজ সিস্টেম 2 (METRO2 লিঙ্ক)।

তাদের জন্য, আমরা দুটি অভিন্ন লক্ষ্যমাত্রা কনফিগার করেছি (আমাদের ক্ষেত্রে iSCSI, কিন্তু FCও সমর্থিত, সেটআপ যুক্তি একই)।

স্টোরেজ সিস্টেম 1:

স্টোরেজ সিস্টেম 2:

প্রতিলিপি সংযোগের জন্য, প্রতিটি স্টোরেজ সিস্টেমে ম্যাপিং করা হয়েছিল।

স্টোরেজ সিস্টেম 1:

স্টোরেজ সিস্টেম 2:

আমরা মাল্টিপাথ সেট আপ করেছি এবং এটি হোস্টের কাছে উপস্থাপন করেছি।

একটি সালিস স্থাপন

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

রিমোট রেপ্লিকেশন>> মেট্রোক্লাস্টার (যেকোন কন্ট্রোলারে)>> "কনফিগার" বোতাম বিভাগে।

আমরা আরবিটারের আইপি, পাশাপাশি দুটি রিমোট স্টোরেজ কন্ট্রোলারের নিয়ন্ত্রণ ইন্টারফেস প্রবেশ করি।

এর পরে, আপনাকে সমস্ত পরিষেবা সক্ষম করতে হবে ("সবকিছু পুনরায় চালু করুন" বোতাম)। ভবিষ্যতে পুনরায় কনফিগার করা হলে, সেটিংস কার্যকর করার জন্য পরিষেবাগুলি পুনরায় চালু করতে হবে৷

আমরা পরীক্ষা করি যে সমস্ত পরিষেবা চলছে।

এটি মেট্রোক্লাস্টার সেটআপ সম্পূর্ণ করে।

ক্রাশ পরীক্ষা

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

এটি করার জন্য, আমরা একটি স্টোরেজ সিস্টেমের সম্পূর্ণ ব্যর্থতা অনুকরণ করি এর উভয় কন্ট্রোলারকে শারীরিকভাবে বন্ধ করে, প্রথমে একটি বড় ফাইল LUN-এ অনুলিপি করা শুরু করে, যা অন্য স্টোরেজ সিস্টেমে সক্রিয় করা আবশ্যক।

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

ঠিক 10 সেকেন্ড পরে (উভয় স্ক্রিনশটে দৃশ্যমান), মেট্রো প্রতিলিপি সংযোগ (যেটি ব্যর্থ স্টোরেজ সিস্টেমে প্রাথমিক ছিল) স্বয়ংক্রিয়ভাবে কার্যকরী স্টোরেজ সিস্টেমে প্রাথমিক হয়ে ওঠে। বিদ্যমান ম্যাপিং ব্যবহার করে, LUN TEST হোস্টের কাছে উপলব্ধ ছিল, রেকর্ডিংটি কিছুটা কমে গেছে (প্রতিশ্রুত 10 শতাংশের মধ্যে), কিন্তু বাধা দেওয়া হয়নি।

পরীক্ষা সফলভাবে সম্পন্ন হয়েছে.

রায়

AERODISK ইঞ্জিন এন-সিরিজ স্টোরেজ সিস্টেমে মেট্রোক্লাস্টারের বর্তমান বাস্তবায়ন সম্পূর্ণরূপে সমস্যাগুলি সমাধান করার অনুমতি দেয় যেখানে এটি আইটি পরিষেবাগুলির জন্য ডাউনটাইম দূর করা বা হ্রাস করা এবং ন্যূনতম শ্রম খরচ সহ তাদের অপারেশন 24/7/365 নিশ্চিত করা প্রয়োজন৷

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

আপনাকে ধন্যবাদ, আমরা একটি ফলপ্রসূ আলোচনার জন্য উন্মুখ।

উত্স: www.habr.com