फ़ेलओवर का परीक्षण और संचालन

जिस disaster recovery plan का कभी test नहीं किया गया हो, वह केवल एक परिकल्पना है। Test failover आपको यह सत्यापित करने देता है कि आपके VMs सही ढंग से boot होते हैं, applications start होती हैं और target region में network connectivity काम करती है — वह भी source environment में कोई बाधा डाले या चल रही replication को प्रभावित किए बिना। कई organisations को अपने DR plans की कमियाँ तभी पता चलती हैं जब वास्तविक disaster आ जाता है, जबकि उसी समय किसी खराब plan से सबसे अधिक नुकसान होता है। अधिकांश regulatory frameworks के लिए नियमित test failovers एक compliance requirement हैं।

ASR तीन प्रकार की failover actions का समर्थन करता है। Test failover एक isolated network में failover किए गए VMs की copies बनाता है (आप target VNet निर्दिष्ट करते हैं), और इससे replication या source environment पर कोई प्रभाव नहीं पड़ता। Planned failover का उपयोग scheduled migrations या maintenance के लिए किया जाता है — यह पहले बाकी बचे changes को sync करता है, फिर source को shut down करके failover करता है। Unplanned failover (वास्तविक disaster के दौरान उपयोग किया जाता है) final sync की प्रतीक्षा किए बिना latest recovery point से तुरंत failover करता है।

Portal में test failover चलाने के लिए: protected item चुनें, Test Failover पर click करें, recovery point चुनें (latest crash-consistent, latest app-consistent या किसी specific point in time का), और target virtual network चुनें (आमतौर पर एक dedicated isolated test VNet)। ASR replica disks का उपयोग करके target region में VM start करता है। Test VM replica के साथ दिखाई देता है, लेकिन पूरी तरह independent होता है — production पर कोई प्रभाव नहीं पड़ता। Testing के बाद, test VMs को delete करने के लिए Cleanup test failover पर click करें।

Failover के दौरान आप ASR की retention window में से एक recovery point चुनते हैं। विकल्प हैं: Latest (lowest RPO) — सबसे वर्तमान crash-consistent recovery point, जिससे data loss न्यूनतम होता है। Latest processed — सबसे हाल में processed point (यह कुछ minutes पीछे हो सकता है)। Latest app-consistent — सबसे हाल का application-consistent recovery point, जो पुराना हो सकता है, लेकिन clean application recovery सुनिश्चित करता है। Custom — किसी incident से पहले की ज्ञात सही स्थिति में लौटने के लिए कोई specific पुराना recovery point।

Recovery plan कई protected VMs को समूहबद्ध करता है और उनके failover का sequence तथा timing निर्धारित करता है। आप निर्दिष्ट कर सकते हैं कि कौन-से VMs पहले boot हों (जैसे application servers से पहले database servers), failover को human validation के लिए रोकने हेतु manual approval gates जोड़ सकते हैं, और pre- तथा post-failover scripts चलाने के लिए Azure Automation runbooks सम्मिलित कर सकते हैं (जैसे DNS records update करना, load balancers configure करना या notifications भेजना)। Recovery plans को test failover के साथ स्वतंत्र रूप से test किया जा सकता है।

Test failover आपको अपना वास्तविक RTO (Recovery Time Objective) मापने का अवसर देता है। Failover शुरू करते समय stopwatch चालू करें और application के पूरी तरह functional होकर users के लिए accessible होने पर उसे रोकें। किसी single VM के लिए सामान्य Azure-to-Azure failover 15–30 minutes में पूरा हो जाता है, लेकिन dependencies वाले multi-tier applications में अधिक समय लग सकता है। अनपेक्षित रूप से समय बढ़ाने वाले सभी steps (जैसे DNS propagation और application warm-up) का documentation करें और अगले test से पहले उन्हें ठीक करें।

planned failover के बाद (जैसे किसी नए region में migrate करने पर), failover को finalise करने के लिए Commit चलाएँ। Commit करने से source से वापस होने वाली replication रुक जाती है और target VMs नए primary के रूप में चिह्नित हो जाते हैं। Commit के बाद आप re-protection सक्षम करके replication की दिशा उलट सकते हैं, जिससे मूल source region नया DR target बन जाता है। इससे incident समाप्त होने के बाद आप मूल region में fail back कर सकते हैं।

Failback किसी disaster या planned migration के बाद workloads को मूल region में वापस लाने की प्रक्रिया है। इसके steps हैं: failover किए गए VMs को re-protect करना (replication की दिशा उलटकर नए primary से मूल region में replication करना), initial sync पूरा होने की प्रतीक्षा करना, और फिर मूल region में वापस planned failover करना। Failback के लिए मूल source infrastructure का अब भी intact होना आवश्यक है — यदि वह नष्ट हो गया हो, तो failback से पहले आपको landing zone फिर से बनानी पड़ सकती है।

Test failover के बाद आपको test VMs और उनसे संबंधित disks को delete करने के लिए portal में Cleanup test failover करना होगा। Cleanup न करने पर test VMs चलते रहते हैं और compute costs बढ़ाते रहते हैं। Cleanup step protected item's test failover status को भी reset करता है, जिससे आप भविष्य में एक और test चला सकते हैं। Cleanup को automate करना (जैसे Automation runbook के माध्यम से test शुरू होने के एक घंटे बाद इसे schedule करना) भूले हुए test VMs को कई दिनों तक चलते रहने से रोकता है।

हर DR test से एक DR drill report तैयार होनी चाहिए, जिसमें ये बातें दर्ज हों: test की गई date और scenario, उपयोग किए गए recovery points, प्राप्त RTO और RPO, खोजी गई समस्याएँ और किए गए remediation actions। यह documentation ISO 27001 और SOC 2 जैसे frameworks की auditor requirements पूरी करती है, जिनमें नियमित DR testing अनिवार्य है। Drill reports को ऐसे secure location में रखें, जहाँ IT और business continuity teams दोनों पहुँच सकें।

Azure Site Recovery का pricing प्रत्येक protected instance के लिए प्रति माह लागू होता है — इस शुल्क में replication service और orchestration दोनों शामिल हैं। Target region में replica managed disks द्वारा उपयोग किए गए storage और replication के दौरान cache storage account के लिए भी शुल्क लिया जाता है। Replication traffic के लिए Azure regions के बीच outbound data transfer पर सामान्य egress rates के अनुसार शुल्क लगता है (Azure Backup के विपरीत, जहाँ paired-region egress निःशुल्क है)। On-premises से Azure replication के लिए, Azure VMs के Windows Server licences में costs कम करने हेतु Azure Hybrid Benefit का उपयोग किया जा सकता है।

इस lesson में आपने सीखा: test failover production को प्रभावित किए बिना isolated network में आपके DR plan की पुष्टि करता है, recovery plans manual gates और automation runbook steps के साथ multi-VM failover का sequence निर्धारित करते हैं, और failback disaster के बाद replication की दिशा उलटकर workloads को मूल region में वापस लाता है। अब हम global content delivery को तेज़ करने के लिए Azure CDN का अन्वेषण करेंगे।