RPO, RTO আর চারটা DR Strategy

এই লেসন শেষে তুমি পারবে

• বলতে পারবে disaster বলতে কী বোঝায় (একটা AZ বা পুরো Region বন্ধ, মানুষের ভুল, ransomware, খারাপ deploy), আর disaster recovery-র তিন ধরন আলাদা করতে পারবে: on-premises থেকে on-premises, on-premises থেকে AWS, আর AWS-এর এক Region থেকে আরেক Region।
• RPO (কতটা ডেটা হারানো চলে, বিপদের মুহূর্ত থেকে পেছনে তাকিয়ে) আর RTO (সিস্টেম কতক্ষণ বন্ধ থাকা চলে, সামনে তাকিয়ে) সংজ্ঞা দিতে পারবে, একটা timeline থেকে দুটোই হিসাব করতে পারবে, আর বুঝিয়ে বলতে পারবে কেন backup ভালো হলে তবেই RPO সত্যি।
• AWS-এর চারটা strategy (Backup and Restore, Pilot Light, Warm Standby, Multi-site Active/Active) বোঝাতে পারবে: প্রতিটার সাধারণ RPO আর RTO, DR Region-এ কী চলে, আর খরচ কেমন।
• Pilot Light আর Warm Standby, আর hot standby আর active/active-এর পার্থক্য ধরতে পারবে, আর “শূন্য” RPO-RTO-র প্রচলিত ভুল ধারণাটা শুধরে দিতে পারবে।
• AWS-এর অংশগুলো জুড়ে একটা DR design বানাতে পারবে: অন্য Region-এ backup আর replication, Route 53 failover, Application Recovery Controller, infrastructure as code, DR Region-এ তৈরি রাখা AMI আর quota, আর নিয়মিত drill।
• পরীক্ষার scenario-র শব্দ (data loss, downtime, cost, mission-critical) পড়ে সেগুলো পূরণ করে এমন সবচেয়ে সস্তা strategy বেছে নিতে পারবে।

#Disaster recovery কেন দরকার

২৩ নম্বর chapter-এ দুটো কাজ, দেখতে আলাদা হলেও প্রশ্ন একটাই: সিস্টেমকে যখন সরতে হয়, তখন ব্যবসার কী হয়? Disaster-এ সরতে হয় বাধ্য হয়ে; migration-এ সরাও নিজের ইচ্ছায়। এই লেসনটা disaster recovery-র পরিকল্পনার অংশ: যে দুটো সংখ্যা দিয়ে DR মাপা হয়, আর সেগুলো পূরণের চারটা চেনা পথ। লেসন ২৩.২-এ আসবে কপি করার service-গুলো (Elastic Disaster Recovery আর AWS Backup), আর ২৩.৩ থেকে ২৩.৫-এ migration।

#Disaster বলতে কী বোঝায়

Disaster হলো এমন যেকোনো ঘটনা, যেটা কোম্পানির কাজ চালিয়ে যাওয়ার ক্ষমতা বা তার টাকাপয়সার ক্ষতি করে। Cloud-এ সাধারণত এগুলো:

• একটা Availability Zone বন্ধ: এক গুচ্ছ data center-এ বিদ্যুৎ, ঠান্ডা রাখার ব্যবস্থা বা network-এর গোলমাল। ঠিকঠাক বানানো Multi-AZ সিস্টেম DR plan ছাড়াই এটা পার করে দেয়।
• পুরো একটা Region সমস্যায়: কম হয়, কিন্তু হয়, আর তখন ওই Region-এর সব service একসাথে ভুগতে পারে।
• মানুষের ভুল: একজন engineer একটা table মুছে ফেলল, production-এ ভুল script চালাল, বা একটা bucket মুছে দিল।
• খারাপ deploy: নতুন release ডেটা নষ্ট করল, বা ভারে ভেঙে পড়ল।
• আক্রমণ: ransomware ডেটা encrypt করে ফেলে বা মুছে দেয়; চুরি হওয়া credential দিয়ে resource ধ্বংস করা হয়।
• On-premises-এ প্রাকৃতিক বা physical ঘটনা: server room-এ পানি ঢোকা, আগুন, লম্বা সময়ের লোডশেডিং।

Disaster recovery (DR) মানে এমন ঘটনার জন্য আগে থেকে তৈরি থাকা আর তা থেকে ফিরে আসা: কতটা ক্ষতি মানা যায় আগেই ঠিক করা, ঠিক জায়গায় ঠিক কপি রাখা, আর ফিরে আসার পথটা অনুশীলন করা।

#Disaster recovery-র তিন ধরন

#High availability আর disaster recovery এক জিনিস না

দুটো কাছাকাছি, কিন্তু আলাদা প্রশ্নের উত্তর দেয়:

• High availability (HA) ছোট, প্রায়ই ঘটে এমন ব্যর্থতার মধ্যেও সিস্টেম চালু রাখে: একটা instance মারা গেল, একটা AZ বন্ধ হলো। Multi-AZ RDS, কয়েকটা AZ জুড়ে Auto Scaling group আর load balancer HA দেয়, একটা Region-এর ভেতরে (লেসন ৭.১ এই পার্থক্যটা নিয়ে সাবধান)।
• DR সামলায় বড়, কদাচিৎ ঘটা ঘটনা: পুরো Region সমস্যায়, ডেটা ধ্বংস বা নষ্ট। মুছে ফেলা table-এর বিরুদ্ধে Multi-AZ কিছুই করে না: standby কয়েক millisecond-এর মধ্যে ওই মোছাটাও কপি করে নেয়।

AWS-এর DR whitepaper সোজাসুজি বলে: ভালোভাবে বানানো, highly available workload-এর জন্য একটা data center হারানো সামলাতে Backup and Restore-ই যথেষ্ট হতে পারে; কিন্তু তোমার কাছে disaster মানে যদি পুরো Region হারানো হয়, বা নিয়ন্ত্রক সংস্থা তা চায়, তাহলে Pilot Light, Warm Standby বা Multi-site-এর দিকে তাকাও।

#RPO আর RTO

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

#RPO: কতটা ডেটা হারানো চলে

Recovery Point Objective (RPO) হলো ব্যবসা সর্বোচ্চ কতটা ডেটা হারাতে রাজি, সময় দিয়ে মাপা। এটা বিপদের মুহূর্ত থেকে পেছনে তাকায়: “আমরা বড়জোর শেষ এক ঘণ্টার order হারাতে পারি।” এটা ঠিক হয় কত ঘনঘন backup নাও, বা কত কাছাকাছি replicate করো, তা দিয়ে।

#RTO: কতক্ষণ বন্ধ থাকা চলে

Recovery Time Objective (RTO) হলো বিপদ থেকে সেবা আবার চালু হওয়া পর্যন্ত ব্যবসা সর্বোচ্চ কতটা সময় মানতে রাজি। এটা বিপদের মুহূর্ত থেকে সামনে তাকায়: “৪ ঘণ্টার মধ্যে customer-রা যেন আবার order দিতে পারে।” এটা ঠিক হয় সিস্টেমের কতটা আগে থেকেই চালু আছে, আর recovery কতটা automated, তা দিয়ে।

  শেষ ভালো backup              বিপদ                 সেবা আবার চালু
        |<------- RPO -------->|<-------- RTO -------->|
           এখানে লেখা ডেটা         সিস্টেম বন্ধ
           হারিয়ে যায়             (টের পাওয়া, সিদ্ধান্ত, recovery)

#একটা অঙ্ক কষে দেখি

একটা shop প্রতি ঘণ্টায়, ঘণ্টার কাঁটা ধরে database-এর backup নেয়, তাই তার RPO ১ ঘণ্টা। বিপদ এল ১০:৫০-এ।

এই টেবিলে দুটো শিক্ষা লুকিয়ে আছে। এক, RPO হলো সবচেয়ে খারাপ অবস্থা, সাধারণত যা হয় তা না। দুই, যে backup-এ ফিরে যাবে সেটা ভালো আর restore করা যায় এমন হলে তবেই RPO সত্যি। যে backup কখনো restore করে দেখোনি, সেটা আশা, recovery point না।

#সংখ্যাগুলো আসে কোথা থেকে

RPO আর RTO ব্যবসার সিদ্ধান্ত, technical না। ব্যবসা বলে এক ঘণ্টা বন্ধ থাকলে বা এক ঘণ্টার ডেটা হারালে কত ক্ষতি (বিক্রি হারানো, জরিমানা, সুনাম), আর IT বলে প্রতিটা স্তরের সুরক্ষার দাম কত। সংখ্যা যত ছোট, খরচ তত বেশি: ২৪ ঘণ্টার RPO-তে রাতে একটা backup-ই যথেষ্ট; কয়েক সেকেন্ডের RPO-তে লাগে অন্য জায়গায় একটা চালু database-এ সারাক্ষণ replication; প্রায় শূন্য RTO-তে লাগে আগে থেকেই পুরো মাপে চালু দ্বিতীয় একটা কপি।

দুটো সংখ্যা মাথায় আলাদা করে রাখো:

• RPO ডেটার প্রশ্ন। নির্ভর করে ডেটা কীভাবে রক্ষা করা হয় তার ওপর: মাঝে মাঝে backup (কয়েক ঘণ্টা), ঘনঘন বা continuous backup (কয়েক মিনিট), continuous replication (কয়েক সেকেন্ড), synchronous replication (শূন্য)।
• RTO বাকি সবকিছুর প্রশ্ন। নির্ভর করে recovery site-এ সিস্টেমের কতটা আগে থেকেই আছে, চালু আর বড় হতে কত সময় লাগে, traffic কত দ্রুত সরে (DNS TTL), আর ধাপগুলো automated কি না, তার ওপর।

একটা design-এ RPO খুব ছোট আর RTO লম্বা হতে পারে (ডেটা প্রতি সেকেন্ডে replicate হয়, কিন্তু DR Region-এ কোনো server নেই), আবার উল্টোটাও হতে পারে।

#এক নজরে চারটা strategy

AWS DR-কে চারটা strategy-তে ভাগ করে, খরচ আর কত তাড়াতাড়ি ফেরা যায় সেই ক্রমে। সময়ের পরিসরগুলো AWS-এর whitepaper Disaster Recovery of Workloads on AWS থেকে নেওয়া।

প্রথম তিনটা active/passive: failover না হওয়া পর্যন্ত user-রা যায় মূল site-এ। চতুর্থটা active/active। Slide-এ একই ক্রম একটা তীর দিয়ে আঁকা, দ্রুত RTO-র দিকে; উল্টো দিক থেকে পড়লে সেটাই বেশি খরচ-এর দিকে তীর।

#Backup and Restore

সবচেয়ে সহজ আর সবচেয়ে সস্তা strategy। নিয়মিত ডেটার backup নাও, আর কপিগুলো এমন জায়গায় রাখো যেখানে বিপদ পৌঁছাতে পারে না। বিপদ এলে environment আবার বানাও আর তাতে ডেটা restore করো।

কীসের backup, আর কোথায় যায়:

• AWS-এর ডেটা: EBS snapshot (লেসন ৫.১), RDS-এর automated backup আর snapshot (লেসন ৭.২), Aurora, DynamoDB, EFS, FSx আর Redshift-এর snapshot, আর versioning ও replication সহ S3-এর ডেটা। এগুলোর বেশিরভাগ এক জায়গা থেকে schedule আর কপি করে AWS Backup (লেসন ২৩.২)।
• On-premises-এর ডেটা AWS-এ: Storage Gateway দিয়ে (লেসন ১২.৩), বা প্রথমবারের বড় কপির জন্য Snowball দিয়ে (লেসন ১২.১), S3-এ, সাথে একটা lifecycle rule যেটা পুরোনো কপি খরচ কমাতে S3 Glacier storage class-এ সরিয়ে দেয় (লেসন ১০.৫)।
• Server নিজেই: instance-গুলোর AMI (লেসন ৪.৩), DR Region-এ কপি করা।
• Infrastructure: network, security group, load balancer আর Auto Scaling group-এর template, যাতে পুরো environment আবার বানানো যায়।

তিনটা নিয়ম note-এ নেই, কিন্তু whitepaper জোর দিয়ে বলে:

1. Backup অন্য Region-এ কপি করো (সম্ভব হলে অন্য account-এও)। বিপদে পড়া Region-এর snapshot ঠিক যখন দরকার তখনই নাগালের বাইরে। ব্যবহার করো copy-snapshot, copy-image, RDS-এর cross-Region automated backup, S3 Cross-Region Replication, বা AWS Backup-এর copy rule।
2. Infrastructure as code (IaC) দিয়ে আবার বানাও: AWS CloudFormation বা Terraform। চাপের মধ্যে হাতে হাতে বানানো ধীর আর ভুলে ভরা; template প্রতিবার হুবহু একই জিনিস বানায় (লেসন ২৫.১)।
3. Restore করে পরীক্ষা করো। যে backup কখনো restore করোনি, সেটা নষ্ট, অসম্পূর্ণ, বা RTO-র মধ্যে restore করার পক্ষে খুব ধীর হতে পারে।

#Pilot Light

গ্যাসের geyser বা পুরোনো ধাঁচের গ্যাসের চুলার কথা ভাবো: একটা ছোট্ট pilot শিখা সারাক্ষণ জ্বলে, আর গ্যাস ছাড়লেই সেখান থেকে পুরো burner দপ করে জ্বলে ওঠে। Pilot Light strategy-তে সিস্টেমের সবচেয়ে জরুরি মূল অংশ, সাধারণত database আর অন্যান্য data store, DR Region-এ সবসময় চালু আর sync করা থাকে। Application server বন্ধ থাকে। বিপদ এলে automation (CloudFormation, একটা Auto Scaling group) চালু ডেটার চারপাশে server চালু করে দেয়।

• DR Region-এ সবসময় চালু: একটা cross-Region read replica (RDS), একটা secondary cluster (Aurora global database), একটা DynamoDB global table replica, replication চালু করা S3 bucket।
• বন্ধ: web আর application server। AWS-এর best practice হলো “বন্ধ” মানে deploy-ই করা নেই: template আর AMI তৈরি, deploy করাটা failover-এর অংশ।
• Failover-এ: database replica-কে writer বানাও (promote), server deploy করে বড় করো, তারপর Route 53 দিয়ে traffic সরাও।
• ফল: RPO কয়েক সেকেন্ড থেকে কয়েক মিনিট (replication), RTO কয়েক দশ মিনিট (server বানাতে, boot করতে আর গরম হতে সময় লাগে)।

Slide দুটো কথা যোগ করে: Pilot Light Backup and Restore-এর খুব কাছাকাছি (environment-এর বেশিরভাগটা তখনও বানাতে হয়), কিন্তু দ্রুত, কারণ জরুরি সিস্টেমগুলো আগে থেকেই চালু। Slide-এ এটা hybrid DR হিসেবে আঁকা: কোম্পানির data center তার database AWS-এর একটা RDS instance-এ (চালু) replicate করে, EC2 instance-গুলো “চালু নেই”, আর failover-এ Route 53 user-দের AWS-এ পাঠায়।

যে তিনটা কারণে বিপদের দিনে Pilot Light ব্যর্থ হয়:

• Quota: DR Region-এর account-এ default service quota থাকে (On-Demand vCPU, load balancer, IP address)। বিপদের আগেই production-এর মাপে বাড়িয়ে রাখো; যে capacity না পেলেই নয়, তার জন্য On-Demand Capacity Reservation নাও।
• পুরোনো image আর template: প্রতিটা release DR Region-এও পৌঁছাতে হবে (AMI, container image, template, configuration, secret)। একটা EC2 Image Builder pipeline প্রতিটা golden AMI দুই Region-এই কপি করতে পারে।
• শুধু ডেটা যথেষ্ট না: replica Region হারানো থেকে বাঁচায়, ভুল script থেকে না। DR Region-এও point-in-time backup রাখো।

AWS Elastic Disaster Recovery আসলে server-এর জন্য service হিসেবে Pilot Light: সারাক্ষণ replicate হওয়া disk আর ছোট, সস্তা replication server একটা staging area-তে রাখে, আর পুরো মাপের server চালু করে শুধু recovery-র সময়। এটা লেসন ২৩.২-এর বিষয়।

#Warm Standby

Warm Standby-তে পুরো production environment-এর একটা ছোট কিন্তু পুরোপুরি কাজ করা কপি DR Region-এ সবসময় চালু থাকে: load balancer, কয়েকটা ছোট application server আর একটা database replica। এটা এখনই আসল traffic সামলাতে পারে, শুধু পুরোটা না। বিপদ এলে একে production-এর মাপে বড় করো (Auto Scaling desired capacity বাড়ায়) আর সব traffic সেখানে সরাও।

• Pilot Light-এর সাথে পার্থক্য: Pilot Light-এ server deploy আর চালু না হওয়া পর্যন্ত একটা request-ও সামলানো যায় না; Warm Standby কম capacity-তে এখনই পারে। Pilot Light-কে চালু করে বড় করতে হয়; Warm Standby-কে শুধু বড় করতে হয়।
• ফল: RPO কয়েক সেকেন্ড (replication), RTO কয়েক মিনিট।
• বাড়তি সুবিধা: কপিটা সবসময় চালু, তাই প্রতিদিন সেখানে অল্প আসল বা test traffic পাঠিয়ে নিশ্চিত থাকা যায় যে এটা কাজ করে।

Slide-এ Warm Standby আঁকা হয়েছে AWS-এ একটা ELB, minimum মাপের একটা EC2 Auto Scaling group আর একটা চালু RDS secondary দিয়ে, যেটা কোম্পানির data center থেকে replicate হয়; failover-এ Route 53 user সরায়, আর Auto Scaling group production-এর মাপে বড় হয়।

দুটো সাবধানতা। এক, Auto Scaling একটা control plane-এর কাজ (configuration বদলানোর API), আর বড় বিপদের সময় control plane data plane-এর চেয়ে কম নির্ভরযোগ্য। AWS-এর whitepaper আগে থেকেই পুরো মাপের, বড় হওয়ার দরকার নেই এমন কপিকে বলে hot standby; অনেক team মাঝামাঝি পথ নেয়: প্রথম ধাক্কার traffic সামলানোর মতো capacity রাখে, বাকিটা পরে বড় করে। দুই, capacity তৈরি হওয়ার আগে কখনো পুরো traffic পাঠিও না: আগে বড় করো, তারপর switch।

#Pilot Light নাকি Warm Standby?

#Multi-site Active/Active আর hot standby

Multi-site active/active-এ পুরো workload production-এর মাপে দুই বা তার বেশি Region-এ একসাথে চলে, আর সবগুলোই user-দের সেবা দেয়। Route 53 (latency, weighted বা geolocation record) বা Global Accelerator user-দের Region-গুলোতে ভাগ করে দেয়; একটা Region বন্ধ হলে তার health check ব্যর্থ হয়, আর বাকিগুলো সাথে সাথে সব traffic নিয়ে নেয়। Application tier-এর কোনো failover-ই নেই, শুধু ডেটার writer একটা হলে তার failover।

• ফল: RPO আর RTO প্রায় শূন্য (whitepaper লেখে “real time”), ওপরের সংশোধনগুলো মেনে।
• খরচ: সবচেয়ে বেশি। সব জায়গায় পুরো capacity, সবসময়, সাথে Region-এর মাঝে data transfer-এর খরচ।
• ডেটার design-ই কঠিন অংশ। Read হয় স্থানীয়ভাবে। Write চলে তিনটার একটা ধাঁচে:
  • Write global: সব write যায় এক Region-এর writer-এ। Aurora global database মানানসই: secondary-রা local read দেয়, write forwarding মাঝে মাঝের write primary-তে পাঠায়, আর primary Region বন্ধ হলে এক মিনিটের কম সময়ে একটা secondary promote হয় (লেসন ৭.৩)।
  • Write local: প্রতিটা Region write নেয়। DynamoDB global table মানানসই, সংঘাত হলে last writer wins (লেসন ১৫.৫)।
  • Write partitioned: প্রতিটা user বা account-এর write-এর জন্য একটা নিজস্ব home Region, যাতে সংঘাতই না হয়।
• Hot standby এর active/passive আত্মীয়: পুরো মাপের কপি, কিন্তু failover-এর আগে কোনো user নেয় না (Route 53 failover routing)। AWS বলে, যারা পুরো দ্বিতীয় environment-এর টাকা দেয়, তাদের বেশিরভাগ সেটা কাজে লাগাতে চায়, তাই active/active-ই বেশি দেখা যায়।

Slide-এ এটা দুবার আঁকা: on-premises আর AWS দুটোই production মাপে active, সামনে Route 53; আর একটা পুরোপুরি AWS-এর multi-Region design, যেখানে Aurora global database (primary আর secondary) আর প্রতিটা Region-এ একটা ELB-এর পেছনে production মাপের Auto Scaling group।

#Strategy বাছাই

প্রতিটা scenario-তে পদ্ধতি একই:

1. RTO খুঁজে বের করো: কতক্ষণ বন্ধ থাকা চলে? কয়েক ঘণ্টা → Backup and Restore। কয়েক দশ মিনিট → Pilot Light। কয়েক মিনিট → Warm Standby। কয়েক সেকেন্ড → Multi-site।
2. RPO খুঁজে বের করো: কতটা ডেটা হারানো চলে? কয়েক ঘণ্টা → মাঝে মাঝে backup-ই যথেষ্ট। কয়েক মিনিট বা সেকেন্ড → continuous replication লাগবে, মানে অন্তত একটা চালু database replica: Pilot Light বা তার ওপরে। শূন্য → synchronous replication।
3. দুটোর মধ্যে যেটা বেশি কড়া, সেটা নাও।
4. দুটোই পূরণ করে এমন strategy-গুলোর মধ্যে সবচেয়ে সস্তাটা বাছো। পরীক্ষা প্রায় সবসময় যোগ করে “most cost-effective”।

Picker-এ কিনারার ঘটনাগুলো চেষ্টা করে দেখো: ঢিলেঢালা RTO কিন্তু কড়া RPO (RPO-ই একটা চালু replica দাবি করে), আর কড়া RTO কিন্তু ছোট budget (plan-এর খরচ মেটে না; ব্যবসাকে বেছে নিতে হবে)।

#AWS-এ DR-এর উপকরণ

Note তিনটা টিপস দেয় (Route 53 failover, global database, IaC); slide যোগ করে backup, high availability, replication, automation আর chaos। নিচে সব এক বাক্সে, সাথে কোন লেসনে কোনটা শেখানো হয়েছে।

#ডেটা: Region-এর মাঝে backup আর replication

Note বলে Aurora global database আর DynamoDB global table “সেকেন্ডের ভগ্নাংশে” replicate করে। এটা সাধারণত হয়, নিশ্চয়তা না: write-এর চাপ বেশি হলে বা network-এ গোলমাল হলে lag বাড়ে, এজন্যই Aurora PostgreSQL-এ একটা managed RPO setting আছে, যেটা কোনো secondary যথেষ্ট কাছে না থাকলে commit থামিয়ে রাখে।

একটা Region-এর ভেতরে slide-এর “high availability” তালিকা (RDS Multi-AZ, ElastiCache Multi-AZ, আর EFS ও S3, যেগুলো আগে থেকেই কয়েকটা AZ জুড়ে থাকে) AZ-এর ব্যর্থতা সামলায়, তাই DR plan মন দিতে পারে Region আর ডেটার বিপদে। Hybrid সংযোগে Direct Connect ব্যর্থ হলে Site-to-Site VPN হলো চেনা বিকল্প পথ (লেসন ২২.৪ আর ২২.৫)।

#Traffic: user-দের DR Region-এ সরানো

• Health check সহ Route 53 failover routing note-এর প্রথম টিপ আর চেনা উত্তর: health check পাস করলে primary record ব্যবহার হয়; ব্যর্থ হলে Route 53 secondary দিয়ে উত্তর দেয়। Check, interval (৩০ বা ১০ সেকেন্ড), threshold আর TTL মিলে failover-এ কত সময় লাগে, সেটা আছে লেসন ৮.৩ আর ৮.৪-এ। Failover record-এ ছোট TTL (৬০ সেকেন্ড) রাখো: যে resolver পুরোনো উত্তর cache করেছে, সেটা মেয়াদ শেষ না হওয়া পর্যন্ত user-দের বন্ধ Region-এই পাঠাতে থাকে।
• Global Accelerator একই static anycast IP address-এর পেছনে Region-এর মাঝে traffic সরায়, DNS cache-এর অপেক্ষা ছাড়াই (লেসন ১১.৪)।
• Application Recovery Controller (ARC)-এর routing control হাতে শুরু করা কিন্তু script করা failover-এর জন্য নির্ভরযোগ্য on/off switch, পাঁচটা Region-এর একটা cluster-এ চলে (লেসন ৮.৪)।

AWS-এর পরামর্শ, failover-এর সময় শুধু data plane-এর কাজ ব্যবহার করো (health check দিয়ে চলা DNS উত্তর, ARC routing control), record edit করা বা resource বানানোর মতো control plane-এর পরিবর্তন না, কারণ control plane-এর availability-র লক্ষ্য কম। AWS এটাও সাবধান করে যে একটা health check alarm-এ automatic Region failover মিথ্যা alarm-এ ক্ষতি করতে পারে, তাই অনেক team failover শুরু করার ভার মানুষকে দেয়, আর তারপরের প্রতিটা ধাপ automated রাখে।

#DR Region-এ infrastructure আর capacity তৈরি রাখা

• Infrastructure as code note-এর তৃতীয় টিপ: CloudFormation (এর stack set একটা template অনেক account আর Region-এ deploy করে) বা Terraform, যাতে recovery মানে একটা deploy, স্মৃতির পরীক্ষা না। Slide Elastic Beanstalk-এর কথাও বলে, যেটা save করা configuration থেকে পুরো একটা environment আবার বানাতে পারে।
• AMI, container image, configuration আর secret প্রতিটা release-এর সাথে DR Region-এ কপি।
• DR Region-এ service quota production-এর মাপে বাড়ানো; যে instance type ছাড়া চলবে না, তার জন্য capacity reservation।
• Key আর permission: recovery-তে যে KMS key (multi-Region key কাজে আসে), IAM role আর certificate লাগবে, সেগুলো DR Region-এ থাকতে হবে (লেসন ২১.২)।

#ছোট ব্যর্থতার জন্য automation

Slide-এর automation-এর তালিকা একটা instance-এর সমস্যাও ধরে: system status check ব্যর্থ হলে একটা CloudWatch alarm EC2 instance-কে নতুন hardware-এ recover করতে পারে (এখনকার বেশিরভাগ instance type default-এই নিজে থেকে recover হয়), বা reboot করতে পারে; EventBridge বা CloudWatch সমস্যার খবর দিলে Lambda function নিজের মতো recovery-র ধাপ চালায়।

#পরীক্ষা: drill, game day আর chaos

যে DR plan কখনো চালানো হয়নি, সেটা অবাক করা সব কারণে ব্যর্থ হয়: মেয়াদ পেরোনো credential, একটা বাদ পড়া route, একটা quota, এমন একটা ধাপ যা শুধু একজনই জানত। DR drill চালাও (ইচ্ছা করে DR Region-এ failover করে আবার ফিরে আসা) আর game day (পুরো team নিয়ে পরিকল্পিত অনুশীলন)। Slide-এর উদাহরণ Netflix-এর “Simian Army”, যার Chaos Monkey এলোমেলোভাবে production instance বন্ধ করে দিত, যাতে engineer-রা এমন সিস্টেম বানাতে বাধ্য হয় যা এটা সামলে নেয়। AWS-এ AWS Fault Injection Service নিয়ন্ত্রিত পরীক্ষা চালায়, যেমন instance বন্ধ করা, database failover করানো বা একটা AZ-এ গোলমাল বাধানো।

#নতুন tool (side note)

#কোথায় কোথায় ভুল হয়

#System design-এ DR

একই কোম্পানির আলাদা সিস্টেম আলাদা strategy নিতে পারে: wallet-এর payment core active/active, অথচ তার marketing site Backup and Restore। প্রতিটা সিস্টেম আলাদা করে শ্রেণিভুক্ত করো, সবকিছুকে সবচেয়ে দামি স্তর দিয়ে দিও না।

#নিজে করে দেখো

এই command-গুলো AWS CLI v2-এর, মূল Region Singapore (ap-southeast-1) আর DR Region Mumbai (ap-south-1)। কপি আর replica-র খরচ আছে; কাজ শেষে মুছে ফেলো।

# ১. Backup and Restore: একটা EBS snapshot আর একটা AMI DR Region-এ কপি (DR Region-এ চালাও)
aws ec2 copy-snapshot --region ap-south-1 \
  --source-region ap-southeast-1 --source-snapshot-id snap-0abcd1234example \
  --description "DR copy of erp-data" --encrypted --kms-key-id alias/dr-ebs
# { "SnapshotId": "snap-0fedc9876example" }

aws ec2 copy-image --region ap-south-1 \
  --source-region ap-southeast-1 --source-image-id ami-0abcd1234example --name erp-web-2026-11-01
# { "ImageId": "ami-0fedc9876example" }

# ২. RDS: automated backup DR Region-এ replicate (সেখানে point-in-time restore)
aws rds start-db-instance-automated-backups-replication --region ap-south-1 \
  --source-db-instance-arn arn:aws:rds:ap-southeast-1:111122223333:db:erp-db \
  --backup-retention-period 7 --kms-key-id alias/dr-rds
# { "DBInstanceAutomatedBackup": { "Status": "pending", "BackupRetentionPeriod": 7, ... } }

# ৩. Pilot Light: সবসময় চালু একটা cross-Region read replica
aws rds create-db-instance-read-replica --region ap-south-1 \
  --db-instance-identifier pharmacy-db-dr \
  --source-db-instance-identifier arn:aws:rds:ap-southeast-1:111122223333:db:pharmacy-db \
  --db-instance-class db.r6g.large --kms-key-id alias/dr-rds
# { "DBInstance": { "DBInstanceIdentifier": "pharmacy-db-dr", "DBInstanceStatus": "creating",
#   "ReadReplicaSourceDBInstanceIdentifier": "arn:aws:rds:ap-southeast-1:111122223333:db:pharmacy-db" } }

# ৪. বিপদের আগেই: DR Region-এর On-Demand vCPU quota দেখো
aws service-quotas get-service-quota --region ap-south-1 \
  --service-code ec2 --quota-code L-1216C47A --query 'Quota.Value'
# 32.0      <- production-এর লাগে ১৯২: বাড়ানোর অনুরোধ এখনই করো, বিপদের দিনে না

# ৫. Failover-এর দিন (Pilot Light): replica promote, web tier deploy, বড় করা
aws rds promote-read-replica --region ap-south-1 --db-instance-identifier pharmacy-db-dr
aws cloudformation deploy --region ap-south-1 --stack-name pharmacy-web-dr \
  --template-file web-tier.yaml --parameter-overrides AmiId=ami-0fedc9876example DesiredCapacity=12
# Waiting for changeset to be created..
# Successfully created/updated stack - pharmacy-web-dr

# ৬. Warm Standby: চালু কপিটা ২ থেকে ২০-এ বড় করো
aws autoscaling update-auto-scaling-group --region ap-south-1 \
  --auto-scaling-group-name results-web-dr --min-size 20 --desired-capacity 20 --max-size 40

# ৭. যে Route 53 health check failover চালায়, সেটা দেখো
aws route53 get-health-check-status --health-check-id 1a2b3c4d-1111-2222-3333-example \
  --query 'HealthCheckObservations[0:3].[Region,StatusReport.Status]' --output text
# ap-southeast-1   Failure: HTTP Status Code 503, Service Unavailable
# eu-west-1        Failure: HTTP Status Code 503, Service Unavailable
# us-east-1        Failure: HTTP Status Code 503, Service Unavailable

# ৮. অথবা পুরো recovery একটা ARC Region switch plan হিসেবে চালাও
aws arc-region-switch start-plan-execution \
  --plan-arn arn:aws:arc-region-switch::111122223333:plan/results-dr:abc123 \
  --target-region ap-south-1 --action activate --mode ungraceful \
  --comment "Singapore impaired, game day 2026-11-01"
# { "executionId": "ap-south-1/0123456789abcdef", "activateRegion": "ap-south-1",
#   "deactivateRegion": "ap-southeast-1", ... }

Console-এ Route 53 → Health checks খুলে প্রতিটা checker Region থেকে status দেখো, আর DR Region-এ Service Quotas খুলে তোমার production যে quota-গুলো ব্যবহার করে সব মিলিয়ে দেখো। তারপর একটা game day-র পরিকল্পনা করো: একটা test application DR Region-এ failover করে আবার ফিরিয়ে আনো, আর প্রতিটা ধাপে আসলে কত সময় লাগল লিখে রাখো। ওই মাপা সংখ্যাটাই তোমার আসল RTO।

#সারসংক্ষেপ

মূল কথাগুলো

• Disaster মানে যা business continuity বা টাকাপয়সার ক্ষতি করে: AZ বা Region বন্ধ, মানুষের ভুল, খারাপ deploy, ransomware, পানিতে ডোবা server room। DR হতে পারে on-prem → on-prem (দামি), on-prem → AWS (hybrid), বা Region → Region।
• RPO = কতটা ডেটা হারানো চলে, বিপদ থেকে পেছনে মাপা (backup কত ঘনঘন, replication)। RTO = কতটা downtime মানা যায়, সামনে মাপা (কতটা আগে থেকেই চালু, automation, TTL)। প্রতি ঘণ্টায় backup, বিপদ ১০:৫০-এ → ৫০ মিনিট গেল, সবচেয়ে খারাপ হলে ৬০। Backup ভালো হলে তবেই RPO সত্যি।
• চারটা strategy, সবচেয়ে সস্তা আর ধীরটা আগে: Backup and Restore (কয়েক ঘণ্টা; কিছুই চালু নেই), Pilot Light (কয়েক দশ মিনিট; data tier চালু, server বন্ধ), Warm Standby (কয়েক মিনিট; সবকিছু ছোট মাপে চালু), Multi-site Active/Active (প্রায় শূন্য; পুরো মাপ, সব Region সেবা দেয়)। Hot standby = পুরো মাপ কিন্তু passive।
• Asynchronous replication-এ Multi-site প্রায় শূন্য, কখনোই একদম শূন্য না; নষ্ট ডেটাও replicate হয়, তাই Multi-site-এরও point-in-time backup লাগে।
• Backup and Restore-এ backup অন্য Region-এ কপি করতে হবে আর IaC দিয়ে আবার বানাতে হবে। Pilot Light-এ DR Region-এ হালনাগাদ AMI আর quota লাগে। Warm Standby-কে পুরো traffic নেওয়ার আগে বড় হতে হবে।
• উপকরণ: Route 53 failover + health check (ছোট TTL), Global Accelerator, ARC routing control আর Region switch; Aurora global database, DynamoDB global table, RDS-এর cross-Region replica আর backup replication, RTC সহ S3 CRR, EBS snapshot আর AMI কপি, AWS Backup; CloudFormation বা Terraform; নিয়মিত drill আর game day; RTO/RPO যাচাইয়ে Resilience Hub।
• পরীক্ষার পদ্ধতি: RTO আর RPO-র শব্দ পড়ো, যেটা বেশি কড়া সেটা নাও, তা পূরণ করে এমন সবচেয়ে সস্তা strategy বাছো।

নিজেকে যাচাই করো: RPO, RTO আর DR strategy৩০টি প্রশ্ন