AERODISK ইঞ্জিন: দুর্যোগ প্রতিরোধ। অংশ 1

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

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

তত্ত্ব একটি বিট

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

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

এই পদ্ধতির সুবিধা:

• সমস্ত স্টোরেজ সিস্টেমে ডেটা সবসময় অভিন্ন

কনস:

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

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

অ্যাসিঙ্ক্রোনাস প্রতিলিপির সুবিধা:

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

কনস:

• বিভিন্ন ডেটা সেন্টারে ডেটা সবসময় অভিন্ন হয় না

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

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

এছাড়াও, প্রায়শই, যখন আমরা স্টোরেজ সিস্টেম ব্যবহার করে প্রতিলিপি সম্পর্কে কথা বলি, অনেকের কাছে একটি যুক্তিসঙ্গত প্রশ্ন থাকে: > "অনেক অ্যাপ্লিকেশনের নিজস্ব প্রতিলিপি সরঞ্জাম রয়েছে, কেন স্টোরেজ সিস্টেমে প্রতিলিপি ব্যবহার করবেন? এটা ভাল না খারাপ?

এখানে কোন সুস্পষ্ট উত্তর নেই, তাই এখানে FOR এবং CONS আর্গুমেন্ট রয়েছে:

স্টোরেজ প্রতিলিপি জন্য আর্গুমেন্ট:

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

স্টোরেজ প্রতিলিপির বিরুদ্ধে আর্গুমেন্ট:

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

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

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

তত্ত্ব দিয়ে সম্পন্ন, এখন অনুশীলন

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

পরিকল্পিতভাবে এটি এই মত দেখায়:

যৌক্তিকভাবে, প্রতিলিপি নিম্নরূপ সংগঠিত হয়:

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

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

অ্যাসিঙ্ক্রোনাস প্রতিলিপির জন্য প্রয়োজনীয়তাগুলি এত গুরুতর নয়। আরও স্পষ্টভাবে, তারা সেখানে নেই। যে কোন কাজ ইথারনেট সংযোগ করবে।

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

প্রতিলিপি যেকোন ইঞ্জিন সিরিজ স্টোরেজ সিস্টেমের (N1, N2, N4) মধ্যে কাজ করতে পারে জুনিয়র সিস্টেম থেকে পুরোনো সিস্টেমে এবং এর বিপরীতে।

উভয় প্রতিলিপি মোডের কার্যকারিতা সম্পূর্ণ অভিন্ন। কি পাওয়া যায় সে সম্পর্কে আরও বিশদ নীচে দেওয়া হল:

• প্রতিলিপি "এক থেকে এক" বা "এক থেকে এক", অর্থাৎ, দুটি ডেটা সেন্টার সহ ক্লাসিক সংস্করণ, প্রধান এবং ব্যাকআপ
• প্রতিলিপি হল "এক থেকে বহু" বা "এক থেকে বহু", অর্থাৎ একটি LUN একসাথে একাধিক স্টোরেজ সিস্টেমে প্রতিলিপি করা যেতে পারে
• সক্রিয়, নিষ্ক্রিয়, এবং "বিপরীত" প্রতিলিপি, যথাক্রমে, সক্রিয়, নিষ্ক্রিয় বা প্রতিলিপির দিক পরিবর্তন করতে
• RDG (Raid Distributed Group) এবং DDP (ডাইনামিক ডিস্ক পুল) পুল উভয়ের জন্যই প্রতিলিপি উপলব্ধ। যাইহোক, একটি RDG পুলের LUN শুধুমাত্র অন্য RDG-তে প্রতিলিপি করা যেতে পারে। ডিডিপির ক্ষেত্রেও তাই।

আরও অনেক ছোট বৈশিষ্ট্য আছে, কিন্তু সেগুলিকে তালিকাভুক্ত করার কোন বিশেষ বিষয় নেই; আমরা সেট আপ করার সাথে সাথে সেগুলি উল্লেখ করব।

প্রতিলিপি সেট আপ করা হচ্ছে

সেটআপ প্রক্রিয়াটি বেশ সহজ এবং তিনটি ধাপ নিয়ে গঠিত।

1. নেটওয়ার্ক সেটআপ
2. স্টোরেজ সেটআপ
3. নিয়ম (সংযোগ) সেট আপ এবং ম্যাপিং

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

নেটওয়ার্ক সংস্থান সেট আপ করা হচ্ছে

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

এর পরে, আমাদের একটি পুল (আমাদের ক্ষেত্রে RDG) এবং প্রতিলিপির জন্য একটি ভার্চুয়াল আইপি (VIP) তৈরি করতে হবে। ভিআইপি হল একটি ভাসমান আইপি ঠিকানা যা স্টোরেজ কন্ট্রোলারের দুটি "ভৌত" ঠিকানার সাথে বাঁধা (যে পোর্টগুলি আমরা এইমাত্র কনফিগার করেছি)৷ এটি প্রধান প্রতিলিপি ইন্টারফেস হবে. আপনি যদি ট্যাগযুক্ত ট্র্যাফিকের সাথে কাজ করতে চান তবে আপনি একটি VIP দিয়ে নয়, কিন্তু একটি VLAN দিয়েও কাজ করতে পারেন।

একটি প্রতিরূপের জন্য একটি VIP তৈরির প্রক্রিয়া I/O (NFS, SMB, iSCSI) এর জন্য একটি VIP তৈরির থেকে খুব বেশি আলাদা নয়। এই ক্ষেত্রে, আমরা একটি নিয়মিত ভিআইপি তৈরি করি (VLAN ছাড়া), তবে এটি প্রতিলিপি করার জন্য নির্দেশ করতে ভুলবেন না (এই পয়েন্টার ছাড়া আমরা পরবর্তী ধাপে নিয়মে VIP যোগ করতে সক্ষম হব না)।

ভিআইপি অবশ্যই আইপি পোর্টগুলির মতো একই সাবনেটে থাকতে হবে যার মধ্যে এটি ভাসছে৷

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

এটি নেটওয়ার্ক অংশের প্রস্তুতি সম্পন্ন করে।

স্টোরেজ সেট আপ করা হচ্ছে

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

পূর্বে তৈরি পুল R02-এ, আপনাকে একটি LUN তৈরি করতে হবে। আসুন এটি তৈরি করি এবং এটিকে LUN1 বলি।

আমাদের একই আকারের দূরবর্তী স্টোরেজ সিস্টেমে একই LUN তৈরি করতে হবে। আমরা বানাই. বিভ্রান্তি এড়াতে, আসুন দূরবর্তী LUN LUN1R কল করি

যদি আমাদের এমন একটি LUN নেওয়ার প্রয়োজন হয় যা ইতিমধ্যেই বিদ্যমান, তাহলে প্রতিলিপি সেট আপ করার সময়, আমাদের হোস্ট থেকে এই উত্পাদনশীল LUN আনমাউন্ট করতে হবে এবং দূরবর্তী স্টোরেজ সিস্টেমে অভিন্ন আকারের একটি খালি LUN তৈরি করতে হবে।

স্টোরেজ সেটআপ সম্পূর্ণ হয়েছে, আসুন একটি প্রতিলিপি নিয়ম তৈরিতে এগিয়ে যাই।

প্রতিলিপি নিয়ম বা প্রতিলিপি লিঙ্ক সেট আপ করা

স্টোরেজ সিস্টেমে LUN তৈরি করার পরে, যা এই মুহূর্তে প্রাথমিক হবে, আমরা স্টোরেজ সিস্টেম 1-এ LUN1-এ স্টোরেজ সিস্টেম 1-এ LUN2R-এর প্রতিলিপি নিয়ম কনফিগার করি।

সেটিংটি "রিমোট রেপ্লিকেশন" মেনুতে তৈরি করা হয়েছে

আসুন একটি নিয়ম তৈরি করি। এটি করার জন্য, আপনাকে প্রতিলিপিটির প্রাপক উল্লেখ করতে হবে। সেখানে আমরা সংযোগের নাম এবং প্রতিলিপির ধরন (সিঙ্ক্রোনাস বা অ্যাসিঙ্ক্রোনাস) সেট করি।

"রিমোট সিস্টেম" ক্ষেত্রে আমরা আমাদের স্টোরেজ সিস্টেম 2 যোগ করি। যোগ করার জন্য, আপনাকে ম্যানেজমেন্ট আইপি স্টোরেজ সিস্টেম (MGR) এবং দূরবর্তী LUN এর নাম ব্যবহার করতে হবে যেখানে আমরা প্রতিলিপি সঞ্চালন করব (আমাদের ক্ষেত্রে, LUN1R)। কন্ট্রোল আইপি শুধুমাত্র একটি সংযোগ যোগ করার পর্যায়ে প্রয়োজন; প্রতিলিপি ট্র্যাফিক তাদের মাধ্যমে প্রেরণ করা হবে না; এর জন্য পূর্বে কনফিগার করা ভিআইপি ব্যবহার করা হবে।

ইতিমধ্যেই এই পর্যায়ে আমরা "এক থেকে বহু" টপোলজির জন্য একাধিক দূরবর্তী সিস্টেম যোগ করতে পারি: নীচের চিত্রের মতো "অ্যাড নোড" বোতামে ক্লিক করুন।

আমাদের ক্ষেত্রে, শুধুমাত্র একটি দূরবর্তী সিস্টেম আছে, তাই আমরা নিজেদেরকে এটিতে সীমাবদ্ধ রাখি।

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

স্টোরেজ সিস্টেম 1. সৃষ্টির পরপরই সুসংগতি শুরু হয়।

স্টোরেজ সিস্টেম 2. আমরা একই নিয়ম দেখতে, কিন্তু সিঙ্ক্রোনাইজেশন ইতিমধ্যে শেষ হয়েছে.

স্টোরেজ সিস্টেম 1-এ LUN1 প্রাথমিক ভূমিকায় রয়েছে, অর্থাৎ এটি সক্রিয়। স্টোরেজ সিস্টেম 1-এ LUN2R সেকেন্ডারির ​​ভূমিকায় রয়েছে, অর্থাৎ, স্টোরেজ সিস্টেম 1 ব্যর্থ হলে এটি স্ট্যান্ডবাইতে থাকে।
এখন আমরা হোস্টের সাথে আমাদের LUN সংযোগ করতে পারি।

আমরা iSCSI এর মাধ্যমে সংযোগ করব, যদিও এটি FC এর মাধ্যমেও করা যেতে পারে। একটি প্রতিলিপিতে iSCSI LUN-এর মাধ্যমে ম্যাপিং সেট আপ করা স্বাভাবিক দৃশ্য থেকে কার্যত আলাদা নয়, তাই আমরা এখানে বিস্তারিতভাবে বিবেচনা করব না। যদি কিছু হয় তবে এই প্রক্রিয়াটি নিবন্ধে বর্ণিত হয়েছে "দ্রুত পদক্ষেপ».

একমাত্র পার্থক্য হল আমরা "প্রতিলিপি ম্যাপিং" মেনুতে ম্যাপিং তৈরি করি

আমরা ম্যাপিং সেট আপ করেছি এবং হোস্টকে LUN দিয়েছি। হোস্ট LUN দেখেছেন।

আমরা এটিকে একটি স্থানীয় ফাইল সিস্টেমে ফর্ম্যাট করি।

এটা, সেটআপ সম্পূর্ণ. পরের পরীক্ষাগুলো আসবে।

পরীক্ষামূলক

আমরা তিনটি প্রধান পরিস্থিতিতে পরীক্ষা করব।

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

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

উভয় স্টোরেজ সিস্টেমে এখন "উপযোগী" ডেটা রয়েছে, আমরা পরীক্ষা শুরু করতে পারি।

শুধু ক্ষেত্রে, এর একটি ফাইলের হ্যাশ যোগ তাকান এবং তাদের লিখুন.

নিয়মিত ভূমিকা স্যুইচিং

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

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

মূল স্টোরেজ সিস্টেমে, রেকর্ডিং বন্ধ হয়ে যায় তা নিশ্চিত করতে আমরা ম্যাপিং অক্ষম করি।

তারপর স্টোরেজ সিস্টেমগুলির একটিতে (এটা কোন ব্যাপার না, প্রধান বা ব্যাকআপে) "রিমোট রেপ্লিকেশন" মেনুতে, আমাদের সংযোগ REPL1 নির্বাচন করুন এবং "ভূমিকা পরিবর্তন করুন" এ ক্লিক করুন।

কয়েক সেকেন্ড পরে, LUN1R (ব্যাকআপ স্টোরেজ সিস্টেম) প্রাথমিক হয়ে যায়।

আমরা স্টোরেজ সিস্টেম1 সহ LUN2R ম্যাপ করি।

এর পরে, আমাদের E: ড্রাইভ স্বয়ংক্রিয়ভাবে হোস্টের সাথে সংযুক্ত হয়, শুধুমাত্র এই সময় এটি LUN1R থেকে "আগত" হয়।

শুধু ক্ষেত্রে, আমরা হ্যাশ যোগ তুলনা.

অভিন্নভাবে। পরিক্ষা উত্তীর্ণ.

ফেইলওভার ডেটা সেন্টার ব্যর্থতা

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

দেখা যাক স্টোরেজ সিস্টেম 1 এ কি হচ্ছে (এই মুহূর্তে ব্যাকআপ এক)।

আমরা দেখি যে প্রাথমিক LUN (LUN1R) অনুপলব্ধ। লগগুলিতে, তথ্য প্যানেলে এবং প্রতিলিপি নিয়মে একটি ত্রুটি বার্তা উপস্থিত হয়েছিল৷ সেই অনুযায়ী, হোস্ট থেকে ডেটা বর্তমানে অনুপলব্ধ।

LUN1-এর ভূমিকা প্রাথমিক-এ পরিবর্তন করুন।

আমি হোস্ট ম্যাপিং করছি.

নিশ্চিত করুন যে ড্রাইভ ই হোস্টে উপস্থিত হয়।

আমরা হ্যাশ চেক.

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

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

এটি কয়েক মিনিটের জন্য লোড হয় এবং তারপর একটি সংক্ষিপ্ত সিঙ্ক্রোনাইজেশনের পরে পরিষেবাতে ফিরে আসে, তবে সেকেন্ডারির ​​ভূমিকায়।

সব ঠিক আছে. স্প্লিট-ব্রেন ঘটেনি। আমরা এটি সম্পর্কে ভেবেছিলাম, এবং সর্বদা পতনের পরে স্টোরেজ সিস্টেমটি সেকেন্ডারির ​​ভূমিকায় উঠে যায়, তা নির্বিশেষে "জীবনে" কী ভূমিকা ছিল। এখন আমরা নিশ্চিতভাবে বলতে পারি যে ডেটা সেন্টারের ব্যর্থতার পরীক্ষা সফল হয়েছিল।

ডেটা সেন্টারের মধ্যে যোগাযোগের চ্যানেলের ব্যর্থতা

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

প্রাইমারিতে আমরা দেখি যে মাধ্যমিকের সাথে কোন সংযোগ নেই।

মাধ্যমিকে আমরা দেখি যে প্রাথমিকের সাথে কোন সংযোগ নেই।

সবকিছু ঠিকঠাক কাজ করে, এবং আমরা মূল স্টোরেজ সিস্টেমে ডেটা লিখতে থাকি, অর্থাৎ, সেগুলি ব্যাকআপের থেকে আলাদা হওয়ার গ্যারান্টি দেওয়া হয়, অর্থাৎ তারা "বিচ্ছিন্ন" হয়েছে।

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

কিছু সময় পরে, সিঙ্ক্রোনাইজেশন সম্পন্ন হয়।

সংযোগটি পুনরুদ্ধার করা হয়েছিল, যোগাযোগের চ্যানেলগুলি হারিয়ে যাওয়ার কারণে কোনও জরুরী পরিস্থিতি তৈরি হয়নি এবং স্যুইচ করার পরে, সিঙ্ক্রোনাইজেশন স্বয়ংক্রিয়ভাবে ঘটেছিল।

তথ্যও

আমরা তত্ত্ব বিশ্লেষণ করেছি - কি প্রয়োজন এবং কেন, কোথায় ভাল এবং কোথায় খারাপ। তারপরে আমরা দুটি স্টোরেজ সিস্টেমের মধ্যে সিঙ্ক্রোনাস প্রতিলিপি সেট আপ করি।

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

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

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

আবার দেখা হবে.

উত্স: www.habr.com