🥇দুর্যোগ-সহনশীল ক্লাউড: এটি কীভাবে কাজ করে

হে হাবর!

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

OST সাইটে দুর্যোগ-সহনশীল ক্লাউড স্টোরেজ।

ভিতরে কি আছে

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

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

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

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

জিনিসপত্র খোলার কিছু ছবি এখানে দেওয়া হলো:

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

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

এই সব ক্ষেত্রে ক্লায়েন্ট ভার্চুয়াল মেশিনগুলো চলতে থাকে, এবং তার কারণ নিচে দেওয়া হলো।

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

একটি ক্লাস্টারের সংযোগ ডায়াগ্রামটি দেখতে এইরকম হয়।

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

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

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

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

দুর্যোগ-সহনশীল ক্লাস্টারের পরিকল্পনা।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

উত্স:

উত্স: www.habr.com