Failover আর disaster recovery — backup, RPO-RTO আর multi-region

১ · বিপর্যয় কাকে বলে — ছয় রকম বিপদ, ছয় রকম প্রতিরক্ষা

পর্ব ৫-এ (Availability আর reliability) দেখেছেন, redundancy দিয়ে ছোট আর ঘনঘন ব্যর্থতা — একটি সার্ভার, একটি ডিস্ক — নিজে থেকেই সামলানো যায়। এই পর্বের প্রশ্ন বড় আর বিরল ঘটনা নিয়ে: পুরো data center অন্ধকার, কেউ ভুল করে production-এর টেবিল মুছে ফেলল, বা চুরি যাওয়া চাবি দিয়ে কেউ সব ডেটা encrypt করে দিল। এমন ঘটনার পর সেবা আর ডেটা গ্রহণযোগ্য সময়ে, গ্রহণযোগ্য ক্ষতিতে ফিরিয়ে আনার পরিকল্পনা, ব্যবস্থা আর অনুশীলনকে বলে disaster recovery (DR).

তৃতীয় থেকে পঞ্চম সারিতে replica প্রায় অকেজো, কারণ replication-এর কাজই সব বদল দ্রুত সবখানে পৌঁছানো — ভালো-মন্দ আলাদা না করে। বড় ডেটা-হারানোর অনেক ঘটনা আসে মানুষ আর software থেকে; পর্ব ৫-এর ভাবনার প্রশ্নে ২০১৭ সালের GitLab-এর ঘটনা এর পরিচিত উদাহরণ।

২ · RPO আর RTO — ব্যবসার ক্ষতি থেকে দুটি সংখ্যা

DR পরিকল্পনার শুরু প্রযুক্তি দিয়ে নয়, দুটি প্রশ্ন দিয়ে। প্রথম, বিপর্যয়ের পর সর্বোচ্চ কত সময়ের সাম্প্রতিক ডেটা হারানো চলে? এর লক্ষ্যই RPO (Recovery Point Objective). দ্বিতীয়, বিপর্যয় থেকে সেবা আবার চালু হওয়া পর্যন্ত সর্বোচ্চ কত সময় চলে? এটি RTO (Recovery Time Objective).

দুটিই লক্ষ্য; মহড়ায় বা আসল ঘটনায় মাপা প্রকৃত মানকে কেউ কেউ RPA আর RTA (actual) বলেন। কাগজে ১ ঘণ্টা, মহড়ায় ৯ ঘণ্টা — এই ফাঁক ধরাই মহড়ার কাজ (অংশ ৪)।

সংখ্যা আসে ক্ষতির হিসাব থেকে

প্রতিটি সুবিধার জন্য আলাদা করে ভাবুন: এক ঘণ্টা বন্ধ থাকলে কী ক্ষতি — টাকা, আস্থা, আইনি দায়? এক ঘণ্টার লেখা হারালে কী ক্ষতি — আবার তৈরি করা যায়, নাকি চিরতরে গেল? এই বিশ্লেষণকে বলে business impact analysis. একটি কাল্পনিক mobile banking সেবায় উত্তরগুলো এমন হতে পারে (সংখ্যা উদাহরণ মাত্র):

শিক্ষা দুটি। এক, “পুরো সিস্টেমের RPO” প্রায়ই ভুল প্রশ্ন — অংশভেদে আলাদা স্তর (tier) রাখলে খরচ অনেক কমে। দুই, RPO শূন্যের কাছে নিতে লেখাটি client-কে “সফল” বলার আগেই অন্য জায়গায় পৌঁছাতে হয় — synchronous replication, যার দাম প্রতিটি লেখায় latency (অংশ ৭)।

RTO-কে ধাপে ভাঙুন

RTO একটি সংখ্যা নয়, কয়েকটি ধাপের যোগফল: টের পাওয়া (MTTD) + সিদ্ধান্ত নেওয়া + নতুন যন্ত্র বা পরিবেশ তৈরি + ডেটা restore + log replay + যাচাই + traffic সরানো। নিচের হিসাবযন্ত্রে একটি ৫ TB database-এর চারটি কৌশল তুলনা করা হয়েছে। সব সংখ্যা ধরা যাক — নিজের মাপ বসিয়ে চালান।

// Worst-case data loss (RPO) and recovery time (RTO) for four strategies.
// Every number below is an assumption for a 5 TB database, not a product figure.
const TB = 1e12, GB = 1e9, MB = 1e6;
const DATA = 5 * TB;                       // size of the full backup
const SPEED = 400 * MB;                    // restore: download + decompress + write, bytes/s
const hrs = (bytes, speed = SPEED) => bytes / speed / 3600;
const base = 0.25 + 0.5 + 0.5 + 0.1;       // detect + decide + verify + traffic shift (h)
const S = [                                // every = backup interval, ship = time until the copy is safe (h)
  { name: "A daily full",          every: 24,   ship: 2,    build: 1,  restore: hrs(DATA) },
  { name: "B full + hourly incr",  every: 1,    ship: 0.25, build: 1,
    restore: hrs(DATA) + 23 * (hrs(4 * GB) + 3 / 60) },   // 23 incrementals, 3 min overhead each
  { name: "C full + WAL archive",  every: 1/60, ship: 1/60, build: 1,
    restore: hrs(DATA) + hrs(300 * GB, 100 * MB) },        // replay up to 24 h of WAL at 100 MB/s
  { name: "D async replica",       every: 0,    ship: 5/3600, build: 0.25, restore: 0.1 }, // scale up + promote
];
const fmt = h => h >= 1 ? h.toFixed(2) + " h" : h * 60 >= 1 ? (h * 60).toFixed(1) + " min" : (h * 3600).toFixed(0) + " s";
console.log("strategy               worst data loss   recovery time");
for (const s of S) {
  const loss = s.every + s.ship;           // disaster just before the next copy is safe
  const rto = base + s.build + s.restore;
  console.log(s.name.padEnd(23) + fmt(loss).padEnd(18) + fmt(rto));
}
console.log("\nrestoring 5 TB at different effective speeds:");
for (const mbps of [100, 400, 1000, 4000]) console.log(String(mbps).padStart(5) + " MB/s -> " + fmt(hrs(DATA, mbps * MB)));

strategy               worst data loss   recovery time
A daily full           26.00 h           5.82 h
B full + hourly incr   1.25 h            7.04 h
C full + WAL archive   2.0 min           6.66 h
D async replica        5 s               1.70 h

restoring 5 TB at different effective speeds:
  100 MB/s -> 13.89 h
  400 MB/s -> 3.47 h
 1000 MB/s -> 1.39 h
 4000 MB/s -> 20.8 min

৩ · Backup-এর নকশা — full, incremental, differential, snapshot আর point-in-time

Database-স্তরের খুঁটিনাটি — logical বনাম physical backup, pg_dump, base backup — DBMS কোর্সের Backup, replication আর high availability পর্বে, আর WAL থেকে crash-এর পর ফেরা Recovery পর্বে। এখানে সিস্টেমের চোখে দেখব: কোন ধরন কত লম্বা restore-চেইন বানায়, আর কী কী backup লাগে।

অনেক backup ব্যবস্থা পুরোনো full-এর সাথে incremental-গুলো পেছনে মিলিয়ে নতুন একটি “synthetic full” বানিয়ে রাখে, যাতে চেইন ছোট থাকে আর production-এ আবার পুরো কপির ভার না পড়ে।

Snapshot কি backup?

Cloud disk বা storage array-এর snapshot সেকেন্ডে নেওয়া যায়, কারণ সাধারণত তা copy-on-write — শুধু পরে বদলানো block আলাদা রাখে। দ্রুত ফেরার জন্য চমৎকার। কিন্তু snapshot প্রায়ই একই storage, একই account আর একই region-এর ওপর নির্ভর করে; storage নষ্ট হলে বা account-এর অধিকারধারী মুছলে snapshot-ও যায়। তাই নিয়ম: snapshot ততক্ষণ backup নয়, যতক্ষণ না তা স্বাধীন জায়গায় কপি হয়েছে। আর চলমান database-এর disk snapshot সাধারণত “crash-consistent” — হঠাৎ বিদ্যুৎ গেলে disk যেমন থাকত; একাধিক disk বা সার্ভিসের snapshot একই মুহূর্তের হবে, তার নিশ্চয়তা আলাদা করে দিতে হয়।

Point-in-time recovery — ঠিক ভুলের আগের মুহূর্তে ফেরা

ভিত্তি backup-এর সাথে database-এর পরিবর্তনের log — PostgreSQL-এর WAL বা MySQL-এর binlog — অবিরাম আলাদা storage-এ পাঠাতে থাকলে (continuous archiving) যেকোনো মুহূর্তে ফেরা যায়: backup restore করে log-কে ঠিক কাঙ্ক্ষিত সময় পর্যন্ত replay. একে বলে point-in-time recovery (PITR). নিচে একটি কাল্পনিক অনলাইন দোকানের ভুল DELETE থেকে ফেরা দেখুন।

ব্যবহারিক কনফিগ কেমন দেখায়, তার একটি উদাহরণ — PostgreSQL-এ restore-এর সময় কোথায় থামবেন তা বলা যায় সময়, transaction id বা LSN দিয়ে; MySQL-এ একই কাজ হয় mysqlbinlog-এর থামার সময় বা অবস্থান দিয়ে। খুঁটিনাটি সংস্করণভেদে আলাদা, অফিসিয়াল ডকুমেন্টেশন মিলিয়ে নিন।

restore_command = 'cp /restore/wal/%f %p'   # fetch WAL segments from the archive
recovery_target_xid = '88412'               # id of the bad transaction
recovery_target_inclusive = false           # stop just BEFORE that transaction
recovery_target_action = 'pause'            # pause: verify first, open later
# MySQL idea: mysqlbinlog --stop-position=... (or --stop-datetime=...)

Database-ই সব নয় — আর কী backup লাগে

• Object storage: ছবি, ফাইল, export — versioning আর অন্য account-এ কপি (পর্ব ২৬); “এগারো nine durability” ভুল DELETE ঠেকায় না।
• Infrastructure-এর বর্ণনা: সার্ভার, network আর permission-এর config কোডে লেখা থাকলে (infrastructure as code) নতুন region-এ পরিবেশ ঘণ্টায় বানানো যায়, হাতে বানাতে দিন লাগে।
• Secrets আর encryption key: চাবি হারালে encrypted backup অর্থহীন — চাবির আলাদা নিরাপদ কপি লাগে (পর্ব ৫২)।
• DNS zone, certificate, container image, CI/CD config — এগুলো ছাড়া restore করা ডেটা কাজে আসে না।
• Queue আর stream: retention শেষে message মুছে যায় — Kafka-ধাঁচের log backup নয় (পর্ব ৩৩)।

৪ · “যে backup restore করে দেখেননি, তা backup নয়” — 3-2-1, immutable কপি আর মহড়া

3-2-1 নিয়ম

বহুল প্রচলিত 3-2-1 নিয়ম (আলোকচিত্রী Peter Krogh-এর নামে পরিচিত): ডেটার অন্তত ৩টি কপি (মূলটিসহ), ২ রকম আলাদা storage-এ, যার ১টি অন্য জায়গায়। Cloud-এ “অন্য জায়গা” মানে অন্য region আর অন্য account — একই account-এর অধিকারধারী বা তাঁর চুরি যাওয়া চাবি সব কপিই মুছতে পারে। অনেক নির্দেশিকা এখন 3-2-1-1-0 বলে: আরও ১টি কপি immutable বা offline, আর restore-যাচাইয়ে ০টি ত্রুটি; নামটি সর্বজনীন মান নয়, ধারণাটি কাজের।

বদলানো যায় না এমন কপি

Immutable backup এমন কপি, যা নির্দিষ্ট মেয়াদ পর্যন্ত কেউ — admin-ও — বদলাতে বা মুছতে পারে না; অনেক object store-এ এর জন্য object lock বা WORM (write once, read many) সুবিধা থাকে, নিয়ম প্রদানকারীভেদে আলাদা। আরও এক ধাপ air-gapped কপি — network থেকে বিচ্ছিন্ন, যেমন আলাদা রাখা tape. প্রতিরক্ষার নিয়ম সরল: backup লেখা আর মোছার অধিকার আলাদা হাতে; backup account-এ বহু-স্তরের যাচাই; মোছার অনুরোধে বিলম্ব আর সতর্কবার্তা। Ransomware আর চুরি যাওয়া credential থেকে সুরক্ষার বিস্তারিত পর্ব ৫২-এ।

Encryption আর retention

Backup-এ থাকে পুরো ডেটা, তাই চুরি হলে ক্ষতিও পুরো। Backup পাঠানোর পথে TLS আর রাখার জায়গায় encryption at rest দুটিই লাগে; চাবি থাকে আলাদা key management ব্যবস্থায়, নিয়মিত key rotation-সহ। সতর্কতা: চাবি যদি শুধু বিকল region-এই থাকে, অন্য region-এর backup খোলাই যাবে না।

Retention দুই দিক থেকে টানে। ছোট হলে নীরব corruption ধরা পড়ার আগেই শেষ ভালো কপি মুছে যায় — ভুল যদি তিন সপ্তাহ পরে ধরা পড়ে, সাত দিনের retention কোনো কাজে আসে না। লম্বা হলে খরচ বাড়ে, আর ব্যক্তিগত তথ্য মোছার আইনি দায় মানা কঠিন হয় — তাই কেউ কেউ crypto-shredding ব্যবহার করেন। প্রচলিত একটি ধাঁচ (grandfather-father-son): ৭টি দৈনিক, ৪টি সাপ্তাহিক আর ১২টি মাসিক কপি।

Restore-মহড়া — আসল পরীক্ষা

Backup job “সফল” লিখলেই কিছু প্রমাণ হয় না: ফাইলটি হয়তো ফাঁকা, হয়তো ভুল database-এর, হয়তো চাবি হারিয়েছে, হয়তো restore-এর script পুরোনো সংস্করণের। তাই restore drill নিয়মিত আর স্বয়ংক্রিয় হওয়া উচিত:

1. নির্দিষ্ট সময় পরপর (ধরুন সাপ্তাহিক) সাম্প্রতিক backup একটি বিচ্ছিন্ন পরিবেশে restore.
2. সারির সংখ্যা, checksum আর অ্যাপের স্বয়ংক্রিয় পরীক্ষা।
3. প্রতিটি ধাপের সময় মেপে আসল RTO-RPO লেখা, লক্ষ্যের সাথে তুলনা।
4. Backup না হলে, আকার হঠাৎ কমলে বা মহড়া ব্যর্থ হলে alert.
5. বছরে কয়েকবার সেই মাপের restore, যা আসলে লাগতে পারে — একটি টেবিল, একজন গ্রাহক, পুরো region.

৫ · Failover — টের পাওয়া থেকে failback পর্যন্ত

Backup অতীতে ফেরায়; failover বর্তমানকে বাঁচায় — বিকল অংশের কাজ একটি প্রস্তুত বিকল্পের হাতে তুলে দিয়ে। একটি database জোড়ার failover-এর সময়রেখা পর্ব ৫-এ দেখেছেন, আর replication-এর ভেতরে leader বদল পর্ব ২২-এ। এখানে মাপ বড়: পুরো একটি region.

স্বয়ংক্রিয় না মানুষের সিদ্ধান্ত?

একটি availability zone হারালে failover সাধারণত স্বয়ংক্রিয় — দূরত্ব কম, synchronous কপি সম্ভব, ভুলের দামও কম। Region-স্তরে অনেক দল ইচ্ছা করে মানুষকে সিদ্ধান্তে রাখে: ভুল করে region ছাড়লে async কপির শেষ কয়েক সেকেন্ডের লেখা হারায়, cache ঠান্ডা হয়, অন্য region-এ হঠাৎ দ্বিগুণ ভিড় আসে। তবে “মানুষ” মানে অনির্দিষ্ট আলোচনা নয় — আগে থেকে লেখা মানদণ্ড (ধরুন “error rate ১৫ মিনিট ধরে ৫০%-এর বেশি”) আর এক ক্লিকে চালানো যায় এমন প্রক্রিয়া।

• টের পাওয়া: এক জায়গার health check যথেষ্ট নয় — সেই জায়গার network-ও বিকল হতে পারে। কয়েকটি এলাকার probe আর ব্যবহারকারীর আসল error rate মিলিয়ে সিদ্ধান্ত; gray failure আর failure detector-এর trade-off পর্ব ৪৪-এ।
• পুরোনো primary-কে থামানো: বিকল মনে হওয়া region হয়তো শুধু বিচ্ছিন্ন; সে লেখা নিতে থাকলে split-brain. তাই promote-এর আগে fencing: পুরোনোটির লেখার অধিকার কাটা, আর প্রতিটি লেখায় বাড়তে থাকা fencing token বা epoch যাচাই (পর্ব ৪৩)। কে primary, তা নিজেই consensus-এর প্রশ্ন (পর্ব ৪২)।
• ডেটার হিসাব: region পেরোনো কপি সাধারণত asynchronous, তাই promote-এর মুহূর্তের replication lag-ই সেই ঘটনার আসল RPO. পুরোনো primary-র না-কপি-হওয়া লেখাগুলো ফেলে না দিয়ে পরে মেলানোর জন্য আলাদা রাখতে হয়।

দুটি region সমান মাপের হলে failback না করাও একটি বৈধ পছন্দ — খ-ই নতুন primary থাকে, ক হয় নতুন standby. প্রতিবার ফেরত যাওয়া মানে আরেকটি ঝুঁকির কাজ।

৬ · DR কৌশলের সিঁড়ি — backup & restore থেকে multi-site active-active

Cloud প্রদানকারীদের DR নির্দেশিকায় (যেমন AWS-এর প্রকাশিত DR whitepaper) চারটি কৌশলের নাম বহুল প্রচলিত। অন্য বই বা প্রতিষ্ঠানে একই ধারণা cold, warm আর hot site নামেও পাবেন; সীমারেখা সবখানে একরকম নয়।

// Four DR strategies. Assumed EXTRA monthly cost (primary region = 100 units),
// worst-case RPO and RTO in minutes. Change them to your own numbers.
const S = [
  { name: "backup & restore", cost: 5,   rpo: 75,   rto: 420 },  // copies in another region only
  { name: "pilot light",      cost: 20,  rpo: 1,    rto: 60  },  // DB replica on, app servers off
  { name: "warm standby",     cost: 45,  rpo: 0.2,  rto: 15  },  // full stack at ~25% size
  { name: "active-active",    cost: 110, rpo: 0.05, rto: 2   },  // two full regions + cross-region traffic
];
console.log("strategy          +cost/month  RPO(min)  RTO(min)");
for (const s of S) console.log(s.name.padEnd(18) + String(s.cost).padStart(8) +
  String(s.rpo).padStart(12) + String(s.rto).padStart(10));

const need = [                             // [label, max RPO, max RTO] in minutes
  ["monthly reports", 1440, 1440], ["online shop", 15, 240],
  ["ticket booking", 1, 30], ["payments", 1 / 6, 5], ["zero loss, 1 min", 0, 1],
];
console.log("\nrequirement        RPO<=     RTO<=   cheapest that meets it");
for (const [label, rpo, rto] of need) {
  const ok = S.filter(s => s.rpo <= rpo && s.rto <= rto).sort((a, b) => a.cost - b.cost);
  const pick = ok.length ? ok[0].name + " (+" + ok[0].cost + ")" : "none: needs synchronous replication";
  console.log(label.padEnd(19) + String(+rpo.toFixed(2)).padEnd(10) + String(rto).padEnd(8) + pick);
}

// Business view: expected yearly cost = 12 x DR cost + p(disaster) x (downtime + lost data)
const p = 0.1;                             // one region-scale disaster every ~10 years (assumed)
for (const [biz, perHourDown, perHourData] of [["reporting tool", 2, 1], ["payment service", 400, 3000]]) {
  const tot = S.map(s => [s.name, 12 * s.cost + p * (perHourDown * s.rto + perHourData * s.rpo) / 60]);
  tot.sort((a, b) => a[1] - b[1]);
  console.log("\n" + biz + ": " + tot.map(([n, v]) => n + " " + v.toFixed(0)).join(" | "));
}

strategy          +cost/month  RPO(min)  RTO(min)
backup & restore         5          75       420
pilot light             20           1        60
warm standby            45         0.2        15
active-active          110        0.05         2

requirement        RPO<=     RTO<=   cheapest that meets it
monthly reports    1440      1440    backup & restore (+5)
online shop        15        240     pilot light (+20)
ticket booking     1         30      warm standby (+45)
payments           0.17      5       active-active (+110)
zero loss, 1 min   0         1       none: needs synchronous replication

reporting tool: backup & restore 62 | pilot light 240 | warm standby 540 | active-active 1320

payment service: pilot light 285 | warm standby 551 | backup & restore 715 | active-active 1322

৭ · Multi-AZ, multi-region আর global traffic routing

Multi-AZ বনাম multi-region

Multi-AZ নকশায় একই region-এর কয়েকটি zone-এ কপি থাকে। Zone-গুলো কাছাকাছি (round trip প্রায়ই এক-দুই millisecond-এর ঘরে, প্রদানকারীভেদে আলাদা), তাই synchronous replication চলে — zone হারালেও লেখা হারায় না, failover স্বয়ংক্রিয়। বেশিরভাগ hardware আর ভবন-স্তরের বিপদ এতেই ঢাকা পড়ে। Multi-region ঢাকে region-ব্যাপী বিভ্রাট আর প্রাকৃতিক দুর্যোগ, কিন্তু round trip কয়েক দশ থেকে শত millisecond. তখন বাছাই দুটি: asynchronous কপি (RPO শূন্য নয়), নয়তো synchronous কপি আর প্রতিটি লেখায় সেই latency — পর্ব ৪০-এর PACELC-এর latency বনাম consistency-র দর-কষাকষি। সাথে আসে data residency: আইন অনুযায়ী কিছু ডেটা দেশের বাইরে রাখা না-ও চলতে পারে।

Active-passive বনাম active-active — একাধিক region-এ

ছবির নকশাটি active-passive: সব লেখা এক region-এ — সহজ, conflict নেই, কিন্তু দূরের ব্যবহারকারীর প্রতিটি লেখায় latency, আর standby প্রায় অলস। Active-active-এ দুই region-ই লেখা নেয়, তাই একই ডেটা দুই জায়গায় একসাথে বদলাতে পারে। প্রচলিত তিন পথ: (১) প্রতিটি ব্যবহারকারী বা key-এর একটি “বাড়ির” region — conflict এড়ানো; (২) দুই দিকেই লেখা নিয়ে পরে conflict resolution বা CRDT (দুটিই পর্ব ৪৬-এ); (৩) region পেরোনো consensus — consistency থাকে, প্রতিটি লেখায় latency যায় (পর্ব ৪০, ৪২)। আর capacity: যেকোনো একটি region পুরো ভার নিতে হলে স্বাভাবিক দিনে প্রতিটি ৫০%-এর কম ব্যস্ত থাকবে, নইলে failover-এর মুহূর্তে বাকিটি ভিড়ে ভেঙে পড়ে (পর্ব ১৮)।

Global traffic routing — DNS আর anycast

ব্যবহারকারীকে কোন region-এ পাঠাবেন, সেই কাজ global load balancing-এর (পর্ব ১৪)। সবচেয়ে প্রচলিত পথ DNS failover: health check বিকল region দেখলে DNS উত্তর থেকে তাকে সরায়। এর গতি বাঁধা TTL-এ — resolver আগের উত্তর মেয়াদ পর্যন্ত মনে রাখে (সবচেয়ে খারাপ ক্ষেত্রের হিসাব পর্ব ৭-এ)। কিন্তু সবাই TTL মানে না: কিছু resolver খুব ছোট TTL বাড়িয়ে নেয়, কিছু client নিজের মতো বেশি সময় রাখে, আর খোলা keep-alive connection ভাঙার আগে DNS আবার জিজ্ঞেসই করে না (আচরণ সংস্করণভেদে আলাদা)। নিচের simulator-এ ২,০০০টি resolver; ৯০% TTL মানে, ৭% ছোট TTL বাড়িয়ে অন্তত ৩০০ সেকেন্ড রাখে, ৩% দুই ঘণ্টা রাখে — এই অনুপাত শেখার জন্য ধরা, মাপা নয়।

// DNS failover: share of users still sent to the dead region, for three TTLs.
function rng(seed) {                                   // mulberry32: seeded, repeatable
  return () => { seed = seed + 0x6D2B79F5 | 0;
    let t = Math.imul(seed ^ seed >>> 15, 1 | seed);
    t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
    return ((t ^ t >>> 14) >>> 0) / 4294967296; };
}
const CHANGE = 60;                         // s: health check notices + DNS record now points to region B
const T = [0, 60, 120, 300, 900, 3600, 7200];
console.log("TTL    " + T.map(t => (t + "s").padStart(7)).join(""));
for (const TTL of [60, 300, 3600]) {
  const rand = rng(51);                    // same resolver population for every TTL
  let total = 0; const stuck = T.map(() => 0);
  for (let r = 0; r < 2000; r++) {
    const users = 1 + Math.floor(rand() * 100);        // users behind this resolver
    const kind = rand();                   // 90% obey TTL, 7% raise it to >= 300 s, 3% keep 2 h
    const hold = kind < 0.90 ? TTL : kind < 0.97 ? Math.max(TTL, 300) : 7200;
    let expiry = hold * (1 - rand());      // cached the old answer some time ago
    while (expiry < CHANGE) expiry += hold;  // re-asked before the change: got the OLD IP again
    total += users;
    T.forEach((t, i) => { if (t < expiry) stuck[i] += users; });
  }
  console.log(String(TTL).padEnd(7) + stuck.map(s => (100 * s / total).toFixed(1).padStart(6) + "%").join(""));
}

TTL         0s    60s   120s   300s   900s  3600s  7200s
60      100.0% 100.0%   9.2%   4.9%   3.2%   2.3%   0.0%
300     100.0% 100.0%  81.6%  22.6%   3.2%   2.3%   0.0%
3600    100.0% 100.0%  98.8%  94.4%  77.1%   3.7%   0.0%

সেই ব্যবস্থার একটি anycast: একই IP ঠিকানা কয়েকটি জায়গা থেকে BGP-তে ঘোষণা হয়, routing ব্যবহারকারীকে কাছেরটিতে নেয়। একটি জায়গা ঘোষণা তুলে নিলে routing নিজেই বাকিগুলোতে সরে — DNS cache-এর প্রশ্নই নেই। Routing স্থির হতে সাধারণত সেকেন্ড থেকে কয়েক মিনিট লাগে (নেটওয়ার্কভেদে আলাদা), আর চলমান TCP connection ভেঙে যেতে পারে। তাই অনেক নকশায় সামনে থাকে anycast-এর edge বা global load balancer, যা পেছনে health check দেখে region বাছে — পর্ব ১৭-এর CDN-এর মতো।

কোন নকশায় বছরে কত downtime?

একই কাল্পনিক ঘটনাপ্রবাহে তিন নকশা: single-AZ, multi-AZ (এক region-এর তিন zone), আর দুই region-এর প্রতিটিতে multi-AZ, অর্থাৎ multi-region. ধরা যাক: zone-বিভ্রাট বছরে ০.৫ বার (গড়ে ৩ ঘণ্টা), region-ব্যাপী বিভ্রাট ০.০৫ বার (গড়ে ৪ ঘণ্টা), সবখানে পৌঁছানো খারাপ deploy ২ বার (গড়ে ৩০ মিনিট)। Zone failover ২ মিনিট, region failover ১৫ মিনিট, আর ১০% ক্ষেত্রে region failover নিজেই ব্যর্থ।

// Yearly downtime of three layouts under the same (assumed) incidents. 20,000 simulated years.
function rng(seed) {                                   // mulberry32: seeded, repeatable
  return () => { seed = seed + 0x6D2B79F5 | 0;
    let t = Math.imul(seed ^ seed >>> 15, 1 | seed);
    t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
    return ((t ^ t >>> 14) >>> 0) / 4294967296; };
}
const rand = rng(51);
const count = rate => { let k = 0, s = -Math.log(1 - rand()); while (s < rate) { k++; s -= Math.log(1 - rand()); } return k; };
const dur = mean => -mean * Math.log(1 - rand());     // random duration with this average (h)
const ZONE = [0.5, 3], REGION = [0.05, 4], DEPLOY = [2, 0.5];   // [per year, mean hours]
const AZ_FO = 2 / 60, REGION_FO = 15 / 60, FO_FAILS = 0.1;      // failover times (h), failover failure
const names = ["single-AZ", "multi-AZ", "multi-region"], Y = 20000, down = names.map(() => []);
for (let y = 0; y < Y; y++) {
  const d = [0, 0, 0];
  for (let i = count(ZONE[0]); i > 0; i--) { const x = dur(ZONE[1]);
    d[0] += x; d[1] += Math.min(x, AZ_FO); d[2] += Math.min(x, AZ_FO); }
  for (let i = count(REGION[0]); i > 0; i--) { const x = dur(REGION[1]);
    d[0] += x; d[1] += x; d[2] += rand() < FO_FAILS ? x : Math.min(x, REGION_FO); }
  for (let i = count(DEPLOY[0]); i > 0; i--) { const x = dur(DEPLOY[1]);
    d[0] += x; d[1] += x; d[2] += x; }                // a bad push hits every copy
  d.forEach((v, k) => down[k].push(v));
}
console.log("layout        mean h/yr  availability  worst 5% of years >=");
names.forEach((n, k) => {
  const a = down[k].sort((p, q) => p - q), mean = a.reduce((s, v) => s + v, 0) / Y;
  console.log(n.padEnd(14) + mean.toFixed(2).padStart(8) + (100 * (1 - mean / 8760)).toFixed(3).padStart(13) + "%" +
    (a[Math.floor(0.95 * Y)].toFixed(1) + " h").padStart(12));
});

layout        mean h/yr  availability  worst 5% of years >=
single-AZ         2.72       99.969%       9.7 h
multi-AZ          1.21       99.986%       3.6 h
multi-region      1.05       99.988%       3.0 h

৮ · Blast radius, cell আর static stability

আগের simulator-এর শিক্ষা এখানে নকশা হয়ে আসে: সবচেয়ে বড় ঝুঁকি প্রায়ই সেই ঘটনা, যা সব কপিতে একসাথে পৌঁছায় (correlated failure, পর্ব ৫)। প্রতিরক্ষার লক্ষ্য তাই blast radius ছোট রাখা — একটি ভুল যেন একসাথে অল্প অংশকে ছোঁয়।

Cell-ভিত্তিক নকশা

Cell-based architecture-এ পুরো সেবাকে কয়েকটি স্বাধীন, সম্পূর্ণ কপিতে (cell) ভাগ করা হয় — প্রতিটির নিজের app, cache আর database, প্রতিটি নির্দিষ্ট একদল ব্যবহারকারীর। সামনে খুব পাতলা একটি router শুধু বলে “এই ব্যবহারকারী কোন cell-এর”। নতুন সংস্করণ প্রথমে একটি cell-এ যায়; ভুল থাকলে ক্ষতি সেই cell-এর ব্যবহারকারীদের মধ্যে সীমিত। ঢাকার যানজটের ভাষায়: এক মোড়ে সব গাড়ি আটকানোর বদলে অনেক আলাদা রাস্তা — একটিতে দুর্ঘটনা হলে বাকিগুলো চলে। দাম: router সবার পথে বসে, তাই তাকে সবচেয়ে সরল রাখতে হয়; আর একাধিক cell ছোঁয়া কাজ (আরেক cell-এর কাউকে টাকা পাঠানো) জটিল হয়।

Static stability — বিপদের দিনে নতুন কিছু না চাওয়া

বিপর্যয়ের দিন সবচেয়ে অনির্ভরযোগ্য কাজ হলো পরিবর্তন করা: নতুন সার্ভার চাওয়া, config বদলানো, DNS-এ লেখা। এগুলো চলে cloud-এর পরিচালনা-ব্যবস্থার API দিয়ে, যা ব্যবহারকারীর অনুরোধ বহনকারী অংশের চেয়ে আলাদা, আর বড় বিভ্রাটে নিজেই ধীর বা অচল হতে পারে — হাজারো গ্রাহক একসাথে একই region-এ যন্ত্র চাইছেন। Static stability ধারণাটির (Amazon-এর প্রকাশিত Builders’ Library-র একটি প্রবন্ধে বিস্তারিত) মূল কথা: কোনো অংশ বিকল হলে বাকি সিস্টেম কোনো পরিবর্তন না করেই চলতে থাকবে। যেমন, তিন zone-এর প্রতিটিতে আগে থেকেই এত capacity যে একটি zone গেলে বাকি দুটিই যথেষ্ট — autoscaling-এর ওপর নির্ভর নয়। একই কারণে DR-এর জন্য দরকারি capacity অনেকে আগে থেকে reserve রাখেন।

৯ · DR পরীক্ষা — runbook, game day আর incident command

পরীক্ষা না করা DR পরিকল্পনা একটি অনুমান মাত্র। প্রস্তুতির তিনটি হাতিয়ার:

মহড়ার উদ্দেশ্য সাফল্য দেখানো নয়, ফাঁক খোঁজা: runbook-এ বাদ পড়া ধাপ, মেয়াদোত্তীর্ণ চাবি, ছোট পড়া quota, কেউ না জানা নির্ভরতা। শেষে আসল RTO-RPO লিখে লক্ষ্যের সাথে তুলনা, আর ফাঁকগুলো কাজের তালিকায়। ইচ্ছা করে নিয়ন্ত্রিত ব্যর্থতা ঘটিয়ে সহনশীলতা যাচাইয়ের চর্চাকে বলে chaos engineering — ছোট মাপে, পর্যবেক্ষণসহ, থামানোর বোতাম হাতে রেখে।

১০ · AI-এর যুগে DR পরিকল্পনা যাচাই

“আমার অ্যাপের জন্য একটি disaster recovery plan লিখে দাও” বললে AI কয়েক সেকেন্ডে সুন্দর শিরোনামে ভরা একটি দলিল দেবে। কিন্তু DR-এর প্রশ্নে কিছু ভুল AI প্রায় নিয়ম করে করে:

AI-এর দেওয়া DR পরিকল্পনা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি অংশের RPO আর RTO লেখা আছে, আর বাছাই করা কৌশল সেগুলো সত্যিই মেটায় কি না নিজে মিলিয়েছি
• Restore-এর সময় আকার ÷ গতি দিয়ে নিজে হিসাব করেছি; একক (TB, Tb, MB/s, Mbps) মিলিয়েছি, মানুষের ধাপ যোগ করেছি
• ভুল DELETE, corruption আর ransomware-এর জন্য PITR, আলাদা account আর immutable কপি আছে; replication-কে backup ধরা হয়নি
• Failover-এ fencing, epoch আর না-কপি-হওয়া লেখার ব্যবস্থা আছে; failback আলাদা পরিকল্পিত কাজ হিসেবে লেখা
• Restore আর failover-এর নির্ভরতা (identity, চাবি, DNS, runbook-এর জায়গা) বিকল region-এর বাইরে; একটি ছোট মহড়া বা simulation চালিয়ে সময় মেপেছি