দুর্যোগ স্থিতিস্থাপক মেঘ: এটি কিভাবে কাজ করে

হে হাবর!

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

OST সাইটে দুর্যোগ-প্রতিরোধী ক্লাউড স্টোরেজ সিস্টেম।

ভিতরে কি আছে

হুডের নিচে, ক্লাস্টারে একটি VMware ESXi হাইপারভাইজার, দুটি INFINIDAT InfiniBox F2240 স্টোরেজ সিস্টেম, Cisco Nexus নেটওয়ার্ক সরঞ্জাম, পাশাপাশি Brocade SAN সুইচ সহ Cisco UCS সার্ভার রয়েছে৷ ক্লাস্টারটি দুটি সাইটে বিভক্ত - OST এবং NORD, অর্থাৎ প্রতিটি ডেটা সেন্টারে একটি অভিন্ন সরঞ্জাম রয়েছে। আসলে, এটিই এটিকে দুর্যোগ-প্রমাণ করে তোলে।

একটি সাইটের মধ্যে, প্রধান উপাদানগুলিও সদৃশ (হোস্ট, SAN সুইচ, নেটওয়ার্কিং)।
দুটি সাইট ডেডিকেটেড ফাইবার অপটিক রুট দ্বারা সংযুক্ত, এছাড়াও সংরক্ষিত.

স্টোরেজ সিস্টেম সম্পর্কে কয়েকটি শব্দ। আমরা NetApp-এ দুর্যোগ-প্রমাণ ক্লাউডের প্রথম সংস্করণ তৈরি করেছি। এখানে আমরা INFINIDAT বেছে নিয়েছি, এবং এখানে কেন:

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

এখানে আনপ্যাকিং থেকে কিছু ফটো আছে:

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

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

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

ক্লাস্টার ডিজাইনটি এমনভাবে ডিজাইন করা হয়েছে যাতে ক্লায়েন্ট ভার্চুয়াল মেশিন সহ যেকোন ESXi হোস্ট দুটি স্টোরেজ সিস্টেমের যেকোনো একটি অ্যাক্সেস করতে পারে। OST সাইটে স্টোরেজ সিস্টেম ব্যর্থ হলে, ভার্চুয়াল মেশিনগুলি কাজ করতে থাকবে: যে হোস্টগুলিতে তারা চলছে তারা ডেটার জন্য NORD-এ স্টোরেজ সিস্টেম অ্যাক্সেস করবে।

এটি একটি ক্লাস্টারে সংযোগ চিত্রটি দেখতে কেমন।

দুটি সাইটের SAN কাপড়ের মধ্যে একটি ইন্টার-সুইচ লিঙ্ক কনফিগার করার কারণে এটি সম্ভব: ফ্যাব্রিক A OST SAN সুইচটি Fabric A NORD SAN সুইচের সাথে সংযুক্ত এবং একইভাবে Fabric B SAN সুইচগুলির জন্য।

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

ESXi হোস্ট একটি ডিস্ক ডিভাইস (স্টোরেজ ডিভাইস) হিসাবে প্রাথমিক ভলিউম এবং এর প্রতিরূপ দেখে। ESXi হোস্ট থেকে প্রতিটি ডিস্ক ডিভাইসে 24টি পথ রয়েছে:

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

একটি দুর্যোগ-প্রমাণ ক্লাস্টারের স্কিম।

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

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

ক্লায়েন্ট ভার্চুয়াল মেশিনের কি হবে যদি...

প্রতিলিপি লিঙ্ক ব্যর্থ হয়. দুটি সাইটের স্টোরেজ সিস্টেমের মধ্যে প্রতিলিপি বন্ধ হয়ে যায়।
ESXi শুধুমাত্র স্থানীয় ডিস্ক ডিভাইসের সাথে কাজ করবে (অনুকূল পথের মাধ্যমে)।
ভার্চুয়াল মেশিনগুলি কাজ চালিয়ে যাচ্ছে।

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

ভার্চুয়াল মেশিন স্বাভাবিকভাবে কাজ করছে।

সাইটের একটিতে SAN সুইচ ব্যর্থ হয়। ESXi হোস্ট স্টোরেজ সিস্টেমের কিছু পথ হারায়। এই ক্ষেত্রে, যে সাইটে সুইচ ব্যর্থ হয়েছে সেখানে হোস্টরা শুধুমাত্র তাদের একটি HBA-এর মাধ্যমে কাজ করবে।

ভার্চুয়াল মেশিনগুলি স্বাভাবিকভাবে চলতে থাকে।

সাইটগুলির একটিতে সমস্ত SAN সুইচ ব্যর্থ হয়৷ ধরা যাক ওএসটি সাইটে এমন বিপর্যয় ঘটেছে। এই ক্ষেত্রে, এই সাইটের ESXi হোস্টগুলি তাদের ডিস্ক ডিভাইসগুলির সমস্ত পথ হারাবে৷ স্ট্যান্ডার্ড VMware vSphere HA প্রক্রিয়াটি কার্যকর হয়: এটি সর্বোচ্চ 140 সেকেন্ডের মধ্যে NORD-এ OST সাইটের সমস্ত ভার্চুয়াল মেশিন পুনরায় চালু করবে।

NORD সাইট হোস্টে চলমান ভার্চুয়াল মেশিনগুলি স্বাভাবিকভাবে কাজ করছে।

ESXi হোস্ট একটি সাইটে ব্যর্থ হয়। এখানে vSphere HA প্রক্রিয়া আবার কাজ করে: ব্যর্থ হোস্ট থেকে ভার্চুয়াল মেশিন অন্যান্য হোস্টে পুনরায় চালু করা হয় - একই বা দূরবর্তী সাইটে। ভার্চুয়াল মেশিন রিস্টার্টের সময় 1 মিনিট পর্যন্ত।

OST সাইটের সমস্ত ESXi হোস্ট ব্যর্থ হলে, কোন বিকল্প নেই: VMগুলি অন্য একটিতে পুনরায় চালু করা হয়। রিস্টার্টের সময় একই।

স্টোরেজ সিস্টেম এক সাইটে ব্যর্থ হয়. ধরা যাক OST সাইটে স্টোরেজ সিস্টেম ব্যর্থ হয়েছে। তারপরে OST সাইটের ESXi হোস্টরা NORD-এ স্টোরেজ রেপ্লিকাগুলির সাথে কাজ করতে স্যুইচ করে৷ ব্যর্থ স্টোরেজ সিস্টেম পরিষেবাতে ফিরে আসার পরে, জোরপূর্বক প্রতিলিপি ঘটবে এবং ESXi OST হোস্টগুলি আবার স্থানীয় স্টোরেজ সিস্টেম অ্যাক্সেস করা শুরু করবে।

ভার্চুয়াল মেশিনগুলি এই সমস্ত সময় স্বাভাবিকভাবে কাজ করছে।

সাইটগুলির মধ্যে একটি ব্যর্থ হয়। এই ক্ষেত্রে, সমস্ত ভার্চুয়াল মেশিন vSphere HA প্রক্রিয়ার মাধ্যমে ব্যাকআপ সাইটে পুনরায় চালু করা হবে। VM পুনরায় চালু করার সময় 140 সেকেন্ড। এই ক্ষেত্রে, ভার্চুয়াল মেশিনের সমস্ত নেটওয়ার্ক সেটিংস সংরক্ষণ করা হবে এবং এটি নেটওয়ার্কের মাধ্যমে ক্লায়েন্টের কাছে অ্যাক্সেসযোগ্য থাকবে।

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

দুটি ডেটা সেন্টারের উপর ভিত্তি করে একটি দুর্যোগ-প্রতিরোধী ক্লাউড এই ধরনের ব্যর্থতা থেকে রক্ষা করে।

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

উত্স:

1. www.infinidat.com/sites/default/files/resource-pdfs/DS-INFBOX-190331-US_0.pdf
2. support.infinidat.com/hc/en-us/articles/207057109-InfiniBox-best-practices-guides

উত্স: www.habr.com