বন্যা হলেও, 1C কাজ করা উচিত! আমরা DR এর ব্যবসার সাথে একমত

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

বর্ণিত গল্পটি কোন ফ্যান্টাসি নয়, 2020 সালের কয়েকটি ঘটনার সম্মিলিত বর্ণনা। বড় কোম্পানিগুলিতে, একটি দুর্যোগ পুনরুদ্ধার পরিকল্পনা, বা দুর্যোগ পুনরুদ্ধার পরিকল্পনা (ডিআরপি), এই ক্ষেত্রে সবসময় হাতের কাছে থাকে। কর্পোরেশনগুলিতে, এটি ব্যবসার ধারাবাহিকতা বিশেষজ্ঞদের দায়িত্ব। তবে মাঝারি এবং ছোট সংস্থাগুলিতে, এই জাতীয় সমস্যাগুলি সমাধান করা আইটি পরিষেবাগুলির উপর পড়ে। আপনাকে ব্যবসার যুক্তি নিজেই বুঝতে হবে, বুঝতে হবে কী ব্যর্থ হতে পারে এবং কোথায়, সুরক্ষা নিয়ে আসা এবং এটি বাস্তবায়ন করা। 

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

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

• আমরা কি রক্ষা করছি?
• আমরা কি থেকে রক্ষা করছি?
• আমরা কতটা রক্ষা করি? 

দ্বিতীয় অংশে, আমরা প্রশ্নের উত্তর দেওয়ার বিকল্পগুলি সম্পর্কে কথা বলব: কীভাবে নিজেকে রক্ষা করবেন। বিভিন্ন গ্রাহকরা কীভাবে তাদের সুরক্ষা তৈরি করে তার উদাহরণ আমি দেব।

আমরা যা রক্ষা করি: গুরুত্বপূর্ণ ব্যবসায়িক ফাংশন সনাক্ত করা 

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

একজন আইটি পেশাদারের বিভিন্ন কারণে এই ধরনের আলোচনায় অসুবিধা হতে পারে:

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

আমি এই মত কথোপকথন গঠন করব: 

1. আমরা ব্যবসায়িকদের বুঝিয়েছি যে দুর্ঘটনা প্রত্যেকের সাথেই ঘটে এবং পুনরুদ্ধারে সময় লাগে। সর্বোত্তম জিনিস হল পরিস্থিতি প্রদর্শন করা, এটি কীভাবে ঘটে এবং কী পরিণতি সম্ভব।
2. আমরা দেখাই যে সবকিছু আইটি পরিষেবার উপর নির্ভর করে না, তবে আপনি আপনার দায়িত্বের ক্ষেত্রে একটি কর্ম পরিকল্পনায় সাহায্য করতে প্রস্তুত।
3. আমরা ব্যবসায়িক গ্রাহককে উত্তর দিতে বলি: যদি সর্বনাশ ঘটে, কোন প্রক্রিয়াটি প্রথমে পুনরুদ্ধার করা উচিত? কারা এতে অংশগ্রহণ করে এবং কিভাবে? 

   ব্যবসার কাছ থেকে একটি সহজ উত্তর প্রয়োজন, উদাহরণস্বরূপ: কল সেন্টারকে 24/7 অ্যাপ্লিকেশন নিবন্ধন চালিয়ে যেতে হবে।

4. আমরা সিস্টেমের এক বা দুজন ব্যবহারকারীকে এই প্রক্রিয়াটি বিস্তারিতভাবে বর্ণনা করতে বলি। 
   আপনার কোম্পানিতে থাকলে সাহায্য করার জন্য একজন বিশ্লেষককে জড়িত করা ভালো।

   শুরুতে, বর্ণনাটি দেখতে এইরকম হতে পারে: কল সেন্টার ফোনের মাধ্যমে, মেল দ্বারা এবং ওয়েবসাইট থেকে বার্তাগুলির মাধ্যমে অনুরোধগুলি গ্রহণ করে৷ তারপরে সে ওয়েব ইন্টারফেসের মাধ্যমে তাদের 1C-তে প্রবেশ করে এবং সেখান থেকে উত্পাদন তাদের এইভাবে নিয়ে যায়।

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

6. আমরা ব্যর্থতার সম্ভাব্য পয়েন্টগুলি খুঁজে বের করি: সিস্টেম নোড যার উপর পরিষেবার কার্যকারিতা নির্ভর করে। আমরা আলাদাভাবে নোডগুলি নোট করি যেগুলি অন্যান্য কোম্পানি দ্বারা সমর্থিত: টেলিকম অপারেটর, হোস্টিং প্রদানকারী, ডেটা সেন্টার ইত্যাদি। এটির মাধ্যমে, আপনি পরবর্তী পদক্ষেপের জন্য ব্যবসায়িক গ্রাহকের কাছে ফিরে যেতে পারেন।

আমরা যা থেকে রক্ষা করি: ঝুঁকি

পরবর্তীতে, আমরা ব্যবসায়িক গ্রাহকের কাছ থেকে জানতে পারি যে কোন ঝুঁকি থেকে আমরা নিজেদের রক্ষা করি। সমস্ত ঝুঁকি দুটি গ্রুপে বিভক্ত করা যেতে পারে: 

• সার্ভিস ডাউনটাইমের কারণে সময়ের ক্ষতি;
• শারীরিক প্রভাব, মানবিক কারণ ইত্যাদির কারণে ডেটা হারানো।

ব্যবসাগুলি ডেটা এবং সময় উভয় হারানোর ভয় পায় - এই সমস্ত অর্থের ক্ষতির দিকে পরিচালিত করে। তাই আবার আমরা প্রতিটি ঝুঁকি গ্রুপের জন্য প্রশ্ন জিজ্ঞাসা করি: 

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

আলোচনার পর, আমরা বুঝতে পারব কিভাবে ব্যর্থতার বিষয়গুলোকে অগ্রাধিকার দিতে হয়। 

আমরা কতটা রক্ষা করি: আরপিও এবং আরটিও 

যখন ব্যর্থতার গুরুত্বপূর্ণ পয়েন্টগুলি পরিষ্কার হয়, তখন আমরা RTO এবং RPO সূচকগুলি গণনা করি। 

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

RPO (পুনরুদ্ধার পয়েন্ট উদ্দেশ্য) - বৈধ তথ্য পুনরুদ্ধার পয়েন্ট. এটি নির্ধারণ করে যে সময় আমরা ডেটা হারাতে পারি। ব্যবসায়িক দৃষ্টিকোণ থেকে, ডেটা হারানোর ফলে জরিমানা হতে পারে, উদাহরণস্বরূপ। এই ধরনের ক্ষতিও টাকায় রূপান্তরিত হতে পারে। 

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

এর একটি নির্দিষ্ট উদাহরণ তাকান. ব্যবহারকারী 1C এ লগ ইন করে, সিস্টেমটি একটি ডাটাবেস ত্রুটির সাথে খোলে। তিনি সিস্টেম অ্যাডমিনিস্ট্রেটরের সাথে যোগাযোগ করেন। ডাটাবেসটি ক্লাউডে অবস্থিত, সিস্টেম অ্যাডমিনিস্ট্রেটর পরিষেবা প্রদানকারীকে সমস্যাটি রিপোর্ট করে। ধরা যাক সমস্ত যোগাযোগ 15 মিনিট সময় নেয়। ক্লাউডে, এই আকারের একটি ডাটাবেস এক ঘন্টার মধ্যে একটি ব্যাকআপ থেকে পুনরুদ্ধার করা হবে, অতএব, পরিষেবা প্রদানকারীর দিকে RTO এক ঘন্টা। তবে এটি ব্যবহারকারীর জন্য চূড়ান্ত সময়সীমা নয়, সমস্যাটি সনাক্ত করতে এতে 15 মিনিট যুক্ত করা হয়েছে। 
 
এর পরে, সিস্টেম অ্যাডমিনিস্ট্রেটরকে ডাটাবেসটি সঠিক কিনা তা পরীক্ষা করতে হবে, এটি 1C এর সাথে সংযুক্ত করুন এবং পরিষেবাগুলি শুরু করুন। এর জন্য আরও এক ঘন্টা প্রয়োজন, যার অর্থ হল প্রশাসকের পক্ষ থেকে RTO ইতিমধ্যে 2 ঘন্টা এবং 15 মিনিট। ব্যবহারকারীর আরও 15 মিনিটের প্রয়োজন: লগ ইন করুন, প্রয়োজনীয় লেনদেনগুলি উপস্থিত হয়েছে কিনা তা পরীক্ষা করুন। এই উদাহরণে 2 ঘন্টা 30 মিনিট হল মোট পরিষেবা পুনরুদ্ধারের সময়।

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

আমরা কিভাবে রক্ষা করি: বিভিন্ন ঝুঁকির জন্য টুল নির্বাচন করা

সমস্ত পয়েন্ট আলোচনা করার পরে, গ্রাহক ইতিমধ্যে ব্যবসার জন্য একটি দুর্ঘটনার খরচ বুঝতে পারে। এখন আপনি টুল নির্বাচন করতে পারেন এবং বাজেট নিয়ে আলোচনা করতে পারেন। ক্লায়েন্ট কেসের উদাহরণ ব্যবহার করে, আমি আপনাকে দেখাব যে আমরা বিভিন্ন কাজের জন্য কী সরঞ্জামগুলি অফার করি। 

আসুন ঝুঁকির প্রথম গ্রুপ দিয়ে শুরু করি: পরিষেবা ডাউনটাইমের কারণে ক্ষতি। এই সমস্যার সমাধান ভাল RTO প্রদান করা উচিত.

1. ক্লাউডে অ্যাপ্লিকেশন হোস্ট করুন 

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

   উদাহরণস্বরূপ, আপনি ক্লাউডে একটি ডাটাবেস সহ একটি ভার্চুয়াল মেশিন হোস্ট করতে পারেন। অ্যাপ্লিকেশনটি একটি প্রতিষ্ঠিত চ্যানেলের মাধ্যমে বা একই ক্লাউড থেকে বাহ্যিকভাবে ডাটাবেসের সাথে সংযুক্ত হবে। ক্লাস্টারের একটি সার্ভারের সাথে সমস্যা দেখা দিলে, VM প্রতিবেশী সার্ভারে 2 মিনিটেরও কম সময়ে পুনরায় চালু হবে। এর পরে, এটিতে DBMS শুরু হবে এবং কয়েক মিনিটের মধ্যে ডাটাবেসটি উপলব্ধ হয়ে যাবে।

   RTO: মিনিটে পরিমাপ করা হয়। এই শর্তাবলী প্রদানকারীর সাথে চুক্তিতে উল্লেখ করা যেতে পারে।
   খরচ: আমরা আপনার আবেদনের জন্য ক্লাউড সম্পদের খরচ গণনা করি। 
   যা থেকে এটি আপনাকে রক্ষা করবে না: প্রদানকারীর সাইটে ব্যাপক ব্যর্থতা থেকে, উদাহরণস্বরূপ, শহর পর্যায়ে দুর্ঘটনার কারণে।

2. অ্যাপ্লিকেশন ক্লাস্টার  

   আপনি যদি RTO উন্নত করতে চান, আপনি পূর্ববর্তী বিকল্পটিকে শক্তিশালী করতে পারেন এবং অবিলম্বে ক্লাউডে একটি ক্লাস্টারযুক্ত অ্যাপ্লিকেশন স্থাপন করতে পারেন।

   আপনি সক্রিয়-প্যাসিভ বা সক্রিয়-সক্রিয় মোডে একটি ক্লাস্টার বাস্তবায়ন করতে পারেন। আমরা বিক্রেতার প্রয়োজনীয়তার উপর ভিত্তি করে বেশ কয়েকটি VM তৈরি করি। বৃহত্তর নির্ভরযোগ্যতার জন্য, আমরা সেগুলিকে বিভিন্ন সার্ভার এবং স্টোরেজ সিস্টেমে বিতরণ করি। ডাটাবেসগুলির একটি সহ সার্ভার ব্যর্থ হলে, ব্যাকআপ নোড কয়েক সেকেন্ডের মধ্যে লোড গ্রহণ করে।

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

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

3. একটি দুর্যোগ-প্রমাণ মেঘ সরান

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

   RTO: 0 এ থাকে।
   খরচ: সবচেয়ে ব্যয়বহুল ক্লাউড বিকল্প। 
   যা থেকে এটি আপনাকে রক্ষা করবে না: এটি ডেটা দুর্নীতির বিরুদ্ধে সাহায্য করবে না, সেইসাথে মানবিক ফ্যাক্টর থেকে, তাই এটি একই সময়ে ব্যাকআপ করার সুপারিশ করা হয়। 

   অনুশীলন থেকে: আমাদের একজন ক্লায়েন্ট একটি ব্যাপক দুর্যোগ পুনরুদ্ধারের পরিকল্পনা তৈরি করেছে। এই কৌশলটি তিনি বেছে নিয়েছেন: 

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

   সপ্তাহে একবার, ক্লায়েন্ট সুরক্ষা পরীক্ষা করে এবং টেপ সহ সমস্ত ব্যাকআপের কার্যকারিতা পরীক্ষা করে। প্রতি বছর কোম্পানিটি সম্পূর্ণ বিপর্যয়-প্রতিরোধী ক্লাউড পরীক্ষা করে। 

4. অন্য সাইটে প্রতিলিপি সংগঠিত 

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

   আরপিও এবং আরটিও: ৫ মিনিট থেকে। 

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

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

বিবেচিত সমস্ত সমাধান উচ্চ প্রাপ্যতা প্রদান করে, কিন্তু র্যানসমওয়্যার ভাইরাস বা দুর্ঘটনাজনিত কর্মচারী ত্রুটির কারণে ডেটা ক্ষতির বিরুদ্ধে রক্ষা করে না। এই ক্ষেত্রে, আমাদের ব্যাকআপের প্রয়োজন হবে যা প্রয়োজনীয় RPO প্রদান করবে।

5. ব্যাকআপ সম্পর্কে ভুলবেন না

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

কঠোরভাবে বলতে গেলে, ব্যাকআপ ডিআর নয়। আর এই কারণে: 

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

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

চূড়ান্ত দুর্যোগ পুনরুদ্ধার পরিকল্পনায় কমপক্ষে 2টি সরঞ্জাম থাকা উচিত:  

• 1-4 বিকল্পগুলির মধ্যে একটি, যা সিস্টেমগুলিকে ব্যর্থতা এবং পতন থেকে রক্ষা করবে।
• ক্ষতি থেকে ডেটা রক্ষা করতে ব্যাকআপ। 

মূল ইন্টারনেট প্রদানকারীর ক্ষয়ক্ষতির ক্ষেত্রে একটি ব্যাকআপ যোগাযোগ চ্যানেলের যত্ন নেওয়াও মূল্যবান। এবং - ভয়েলা! — ন্যূনতম মজুরিতে ডিআর ইতিমধ্যেই প্রস্তুত। 

উত্স: www.habr.com