High Availability ও Fault Tolerance-এর নকশা
High Availability and Fault Tolerance
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Availability ও fault tolerance আলাদা করা
- Redundant application এবং dependency design করা
- Failover-এর capacity ও correctness পরীক্ষা
সমস্যা দিয়ে শুরু
দুটি Laravel web server আছে, তাই team ভাবছে দোকান সবসময় সচল। কিন্তু session প্রথম server-এর local disk-এ এবং database একটিই। একটি server হারালে user logout হন; database হারালে দুটিই বন্ধ। Replica সংখ্যা দেখে availability বিচার করা যায় না। Critical user journey কোন dependency chain পেরোয়, সেখানে failover এবং spare capacity আছে কি না দেখতে হয়।
সহজ করে বুঝি
High availability system-কে নির্ধারিত সময়ে ব্যবহারযোগ্য রাখার লক্ষ্য। Fault tolerance নির্দিষ্ট failure চলাকালেও service বজায় রাখার ক্ষমতা। Redundancy, health-based routing, independent placement এবং state recovery একসঙ্গে লাগে। Stateless web সহজে replace হয়; session, database এবং queue state-এর আলাদা strategy দরকার। Failover চলাকালে lost connection বা interrupted request হতে পারে; financial operation-এ retry correctness design করতে হয়।
পরিচিত একটি উপমা
দুটি দোকানের counter থাকলেও বিদ্যুৎ meter একটি হলে meter নষ্টে দুটিই থামে। আলাদা কর্মী redundancy, কিন্তু common supply-এর alternative না থাকলে পুরো দোকান fault tolerant হয় না। Backup counter চালানোর মতো লোক এবং stock-ও প্রস্তুত থাকতে হবে।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD L[Health aware load balancer] --> A[Web zone A] L --> B[Web zone B] A --> S[Shared session service] B --> S A --> D[(Database primary)] B --> D D --> R[(Standby and failover)]
Balancer ready web instance বেছে নেয়। Shared session থাকলে request অন্য instance-এ গেলেও identity state মেলে। Database standby primary failure-এ promotion candidate হতে পারে; replication mode অনুযায়ী data loss ও delay বদলায়। Diagram-এর প্রতিটি shared service নিজের availability plan চায়। একটি zone হারালে বাকি zone total required load বহন করতে পারবে কি না পরীক্ষা করুন।
PHP ও Laravel-এ প্রয়োগ
Laravel config/session.php-এর driver fragment। Database session migration applied, table indexed এবং connection highly available বলে ধরে নেওয়া যাবে না; এটি কেবল local file dependency সরায়। Redis driver-ও নেওয়া যায়, তবে তার durability ও failure behavior বুঝতে হবে।
return [
'driver' => env('SESSION_DRIVER', 'database'),
'lifetime' => 120,
'encrypt' => true,
'secure' => true,
'http_only' => true,
'same_site' => 'lax',
];সুবিধা, সীমাবদ্ধতা ও trade-off
Redundancy downtime কমাতে পারে কিন্তু cost, coordination ও operational complexity বাড়ায়। Synchronous replication data-loss window কমাতে পারে, write latency বা partition-time availability-এর trade-off থাকে। Failover automation দ্রুত, কিন্তু false positive promotion split brain ঘটাতে পারে। Simpler manual recovery যথেষ্ট কি না business recovery objective দিয়ে সিদ্ধান্ত নিন।
সাধারণ ভুল
- এক database-এর উপর দশ web replica বসিয়ে full redundancy দাবি করা।
- Failover-এর পরে database writer কে হবে না ঠিক করা।
- বাকি replica যথেষ্ট capacity রাখে কি না না মাপা।
আরও একটু গভীরে
Failure matrix লিখুন: process crash, host outage, zone outage, dependency slowness এবং operator mistake। প্রতিটিতে detection, mitigation, data risk ও recovery time আলাদা। Health check খুব sensitive হলে healthy capacity-ও সরিয়ে cascade ঘটাতে পারে। Payment retry-তে idempotency key ও unknown outcome reconciliation রাখুন। Availability report infrastructure uptime নয়, user-visible success দিয়ে পরিমাপ করা ভালো।
মনে রাখুন
সচলতা replica count নয়; state, capacity, failure domain ও tested failover-এর সম্মিলিত ফল।
নিজে চেষ্টা করুন
Staging-এ একটি web replica বন্ধ করে authenticated checkout চালান। এরপর database failover rehearsal plan লিখুন; actual write test, duplicate prevention এবং recovery সময় কীভাবে যাচাই করবেন নির্ধারণ করুন।
নিজের বোঝা যাচাই করুন
1. দুটি web server যথেষ্ট?
না। Shared database, session, queue এবং routing failure-ও user journey থামাতে পারে। পুরো dependency chain দেখতে হবে।
2. Fault tolerance সীমাহীন?
না। নির্দিষ্ট failure model-এর মধ্যে দাবি করা যায়। এক zone failure সহ্য করা region failure সহ্য করার সমান নয়।
3. Shared session কি HA দেয়?
Local file coupling কমায়; shared session service নিজে available হতে হবে। নতুন dependency-এর failure behaviorও পরীক্ষা করুন।
4. Failover-এ retry নিরাপদ?
সব operation-এ নয়। Previous outcome অজানা থাকতে পারে; idempotency ও reconciliation দরকার।
5. Spare capacity কেন?
এক replica বা zone হারালে বাকি capacity-তে load বাড়ে। Headroom না থাকলে redundancy কাগজে থাকে, বাস্তবে overload হয়।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।