स्टेटफुल सेवाओं के लिए मल्टी-AZ पैटर्न

स्थिति-युक्त सेवाएँ—डेटाबेस, कैश और फ़ाइल सिस्टम—उच्च उपलब्धता वाली बनाना सबसे कठिन घटक हैं, क्योंकि इनमें ऐसा डेटा होता है जिसे विफलताओं के बाद भी सुरक्षित रहना चाहिए। यदि एकल-AZ डेटाबेस विफल हो जाता है, तो आपका पूरा एप्लिकेशन अपना डेटा स्टोर खो देता है। AWS का समाधान Multi-AZ परिनियोजन है, जिसमें सेवा दूसरे Availability Zone में एक समकालिक या लगभग समकालिक प्रतिकृति बनाए रखती है, जो प्राथमिक के विफल होने पर तेज़ी से कार्यभार सँभाल सकती है।

RDS Multi-AZ अलग AZ में एक समकालिक स्टैंडबाय प्रतिकृति बनाए रखता है। प्राथमिक पर किया गया प्रत्येक लेखन सफल होने की पुष्टि से पहले समकालिक रूप से दोहराया जाता है—इसका अर्थ है शून्य डेटा हानि (RPO=0), लेकिन लेखन विलंबता में थोड़ी वृद्धि। प्राथमिक विफल होने पर RDS 60-120 सेकंड में DNS एंडपॉइंट को स्टैंडबाय की ओर इंगित करने के लिए स्वचालित रूप से अपडेट कर देता है। आपके एप्लिकेशन को केवल उसी एंडपॉइंट से दोबारा कनेक्ट करना होता है—कोड में किसी बदलाव की आवश्यकता नहीं होती।

Amazon Aurora साझा वितरित स्टोरेज लेयर के माध्यम से Multi-AZ को और बेहतर बनाता है, जो डेटा को तीन AZs में छह प्रतियों के रूप में स्वचालित रूप से दोहराती है। Aurora इंस्टेंस स्टेटलेस होते हैं — वे इसी साझा स्टोरेज से डेटा पढ़ते और उसमें लिखते हैं। जब प्राथमिक Aurora Writer विफल हो जाता है, तो किसी अन्य AZ में मौजूद Read Replica को 30 सेकंड से कम समय में Writer बना दिया जाता है। यह RDS Multi-AZ Failover से तेज़ है, और बिना स्पष्ट Standby Replication के भी डेटा सभी AZs में हमेशा सुसंगत रहता है।

ElastiCache for Redis, Replication Groups के माध्यम से Multi-AZ का समर्थन करता है। एक Primary Node लिखने की प्रक्रिया स्वीकार करता है और उसे अन्य AZs में मौजूद Read Replicas में Asynchronous तरीके से दोहराता है। Primary के विफल होने पर ElastiCache स्वचालित रूप से किसी Replica को Primary बना देता है। Redis के Cluster Mode Enabled में डेटा को कई Node Groups में बाँटा जाता है और प्रत्येक समूह में अपना Primary तथा AZs में फैले Replicas होते हैं — इससे HA और क्षैतिज स्केलिंग, दोनों मिलते हैं।

Amazon Elastic File System (EFS) स्वाभाविक रूप से Multi-AZ है — यह एक क्षेत्रीय सेवा है, जो किसी Region के भीतर कई AZs में डेटा को अतिरिक्त प्रतियों के साथ संग्रहीत करती है। आप प्रत्येक AZ के Subnet में Mount Targets बनाते हैं और किसी भी AZ में मौजूद EC2 इंस्टेंस अपने स्थानीय Mount Target के माध्यम से File System को Mount कर सकते हैं। Multi-AZ के लिए किसी मैन्युअल कॉन्फ़िगरेशन की आवश्यकता नहीं होती। EFS साझा POSIX File Storage उपलब्ध कराता है, जिसे AZs में मौजूद कई इंस्टेंस एक साथ एक्सेस कर सकते हैं।

Elastic Load Balancers स्वयं Multi-AZ होते हैं — ALB और NLB आपके द्वारा निर्दिष्ट प्रत्येक AZ में Load Balancer Nodes तैनात करते हैं। Cross-Zone Load Balancing Enabled होने पर (ALB के लिए यह डिफ़ॉल्ट है), प्रत्येक Load Balancer Node केवल अपने AZ में ही नहीं, बल्कि सभी AZs में पंजीकृत सभी Targets के बीच ट्रैफ़िक समान रूप से वितरित करता है। इससे यह सुनिश्चित होता है कि किसी एक AZ के सभी इंस्टेंस विफल हो जाने पर भी Load Balancer शेष AZs में मौजूद इंस्टेंस के माध्यम से ट्रैफ़िक प्रदान करता रहे।

एक सामान्य गलती यह है कि एक ही AZ में एक NAT Gateway तैनात किया जाए और अन्य AZs के Private Subnets का रूट उसी से होकर निर्धारित किया जाए। यदि वह AZ विफल हो जाता है, तो सभी Private Instances इंटरनेट एक्सेस खो देते हैं। सही Multi-AZ पैटर्न यह है कि प्रत्येक AZ में एक NAT Gateway तैनात किया जाए और प्रत्येक AZ की Private Route Table को इस प्रकार कॉन्फ़िगर किया जाए कि वह 0.0.0.0/0 को अपने NAT Gateway के माध्यम से रूट करे। इससे NAT Gateway Cross-AZ SPOF नहीं रहता और Cross-AZ डेटा ट्रांसफ़र की लागत भी घटती है।

DynamoDB पूरी तरह प्रबंधित सेवा है, जो किसी Region के भीतर तीन AZs में डेटा को स्वचालित रूप से दोहराती है — आपको Multi-AZ को मैन्युअल रूप से कॉन्फ़िगर करने की आवश्यकता नहीं होती। सफलता लौटाने से पहले प्रत्येक Write को तीनों AZs में स्थायी रूप से संग्रहीत किया जाता है। DynamoDB, बिना किसी अतिरिक्त सेटअप के, AZ स्तर पर प्रभावी रूप से Fault-Tolerant है। इसी कारण जब परीक्षा के प्रश्न में कम से कम परिचालन प्रयास के साथ High Availability पर ज़ोर दिया जाता है, तो DynamoDB को अक्सर अनुशंसित Database विकल्प माना जाता है।

RDS Multi-AZ Failover के दौरान, स्थायी Database Connections बनाए रखने वाले Applications को Endpoint बदलने पर विफलताओं का सामना करना पड़ सकता है। RDS Proxy आपके Application और RDS के बीच कार्य करता है और Database Connections का एक Pool बनाए रखता है। Failover के दौरान RDS Proxy स्वचालित रूप से नए Primary पर अनुरोध भेजता है — Proxy Endpoint का उपयोग करने वाले Applications के लिए Failover का प्रभाव 60–120 सेकंड से घटकर 30 सेकंड से कम हो जाता है। RDS Proxy उन Lambda Functions के लिए भी उपयोगी है, जो बहुत-से कम-अवधि वाले Connections बनाते हैं।

Multi-AZ पैटर्न चुनने के लिए Replication Modes को समझना अत्यंत महत्वपूर्ण है। Synchronous Replication (RDS Multi-AZ, EFS) यह सुनिश्चित करता है कि RPO=0 हो, क्योंकि सफलता की पुष्टि से पहले प्रत्येक Write दोनों AZs में पूरा हो जाता है। इसका प्रतिफल थोड़ा अधिक Write Latency है। Asynchronous Replication (ElastiCache Redis Replicas, RDS Read Replicas) कम Write Latency प्रदान करता है, लेकिन थोड़े Replication Lag को स्वीकार करता है — अर्थात यदि Replication पूरी होने से पहले Primary विफल हो जाए, तो कुछ डेटा खो सकता है।

आपको अपने RTO संबंधी अनुमानों को मान्य करने के लिए नियमित रूप से Multi-AZ Failover का परीक्षण करना चाहिए। RDS के लिए आप Console के Reboot with Failover विकल्प या CLI का उपयोग करके Failover Trigger कर सकते हैं। FailedSQLServerAgentJobsCount Metric के लिए CloudWatch को Monitor करें और अपने Application Logs देखकर पुष्टि करें कि Application सफलतापूर्वक फिर से Connect हो गया है। वास्तविक Failover अवधि का दस्तावेज़ बनाएँ — यह आपके Instance Class और Workload के आधार पर AWS के दस्तावेज़ में दिए गए समय से अलग हो सकती है।

इस Lesson में आपने सीखा: RDS Multi-AZ, Automatic DNS Failover के साथ Synchronous Replication का उपयोग करता है, Aurora तेज़ Failover के लिए तीन AZs में साझा Storage Layer का उपयोग करता है, और EFS तथा DynamoDB बिना मैन्युअल Configuration के स्वाभाविक रूप से Multi-AZ होते हैं। Cross-AZ SPOFs से बचने के लिए प्रत्येक AZ में एक NAT Gateway तैनात करें। आगे हम Multi-Region Active-Active और Active-Passive पैटर्न का अध्ययन करेंगे।