RADIUS सर्वर हाई एवेलेबिलिटी: Active-Active बनाम Active-Passive

# RADIUS सर्वर हाई एवेलेबिलिटी: Active-Active vs Active-Passive ## Purple Technical Briefing — पॉडकास्ट स्क्रिप्ट (~10 मिनट) --- **भाग 1 — परिचय और संदर्भ (लगभग 1 मिनट)** Purple Technical Briefing में आपका स्वागत है। मैं आपका होस्ट हूँ, और आज हम एंटरप्राइज WiFi चलाने वाले किसी भी संगठन के लिए सबसे महत्वपूर्ण इन्फ्रास्ट्रक्चर निर्णयों में से एक पर चर्चा कर रहे हैं: RADIUS सर्वर हाई एवेलेबिलिटी। यदि आप एक नेटवर्क आर्किटेक्ट या IT निदेशक हैं जो किसी होटल समूह, रिटेल श्रृंखला, स्टेडियम या सार्वजनिक क्षेत्र की सुविधा में ऑथेंटिकेशन इन्फ्रास्ट्रक्चर के लिए जिम्मेदार हैं, तो यह ब्रीफिंग आपको सही निर्णय लेने के लिए आवश्यक फ्रेमवर्क और विशिष्ट तकनीकी विवरण देगी — और उन गलतियों से बचने में मदद करेगी जो सबसे खराब समय पर ऑथेंटिकेशन आउटेज का कारण बनती हैं। आइए मैं आपको इसकी पृष्ठभूमि बताता हूँ। RADIUS — रिमोट ऑथेंटिकेशन डायल-इन यूजर सर्विस — आपके नेटवर्क का गेटकीपर है। हर बार जब कोई कर्मचारी 802.1X के माध्यम से कनेक्ट होता है, या कोई अतिथि आपके कैप्टिव पोर्टल के माध्यम से ऑथेंटिकेट होता है, तो RADIUS क्रेडेंशियल की जांच करने और एक्सेस को अधिकृत करने वाला इंजन होता है। यह IEEE 802.1X और WPA3 enterprise डिप्लॉयमेंट की रीढ़ है। और अधिकांश IT सेवाओं के विपरीत जो विफल होने पर धीरे-धीरे खराब होती हैं, RADIUS बाइनरी है: या तो यह काम करता है, या कोई भी नेटवर्क पर नहीं आ पाता है। यही विषमता हाई एवेलेबिलिटी को इतना महत्वपूर्ण बनाती है। --- **भाग 2 — तकनीकी गहन विश्लेषण (लगभग 5 मिनट)** आइए बुनियादी बातों से शुरू करते हैं। RADIUS UDP पर काम करता है — आमतौर पर ऑथेंटिकेशन के लिए पोर्ट 1812 और अकाउंटिंग के लिए 1813। UDP की स्टेटलेस प्रकृति वास्तव में HA डिज़ाइन के लिए एक फायदा है: क्योंकि प्रत्येक ऑथेंटिकेशन अनुरोध आत्मनिर्भर होता है, इसलिए क्लस्टर का कोई भी सर्वर पहले क्या हुआ था यह जाने बिना किसी भी अनुरोध को संभाल सकता है। यह वह आर्किटेक्चरल विशेषता है जो Active-Active डिप्लॉयमेंट को इतना शानदार बनाती है। अब, दो प्राथमिक हाई-एवेलेबिलिटी मॉडल हैं जिन्हें आपको समझना होगा। **Active-Passive** पारंपरिक दृष्टिकोण है। आपके पास एक प्राइमरी RADIUS सर्वर होता है जो सभी ऑथेंटिकेशन ट्रैफ़िक को संभालता है, और एक सेकेंडरी सर्वर स्टैंडबाय में रहता है, जो रेप्लिकेटेड डेटा प्राप्त करता है लेकिन अनुरोधों को प्रोसेस नहीं करता है। जब प्राइमरी विफल हो जाता है, तो नेटवर्क एक्सेस डिवाइस — आपका एक्सेस पॉइंट, आपका स्विच, आपका VPN गेटवे — विफलता का पता लगाता है और ट्रैफ़िक को सेकेंडरी पर रीडायरेक्ट करता है। उस फ़ेलओवर में कितना समय लगता है? यहीं पर विशिष्ट विवरण मायने रखते हैं। NAS एक RADIUS अनुरोध भेजता है और प्रतीक्षा करता है। डिफ़ॉल्ट पैकेट टाइमआउट आमतौर पर दो सेकंड होता है। उसके बाद, यह पुनः प्रयास करता है — आमतौर पर प्रति सर्वर तीन प्रयास। दो सर्वर कॉन्फ़िगर होने के साथ, आप एक अच्छी तरह से ट्यून किए गए डिप्लॉयमेंट में लगभग छह से बारह सेकंड का अधिकतम फ़ेलओवर डिटेक्शन समय देख रहे हैं। तीन सर्वर और डिफ़ॉल्ट टाइमर वाले सबसे खराब स्थिति में, यह अठारह सेकंड तक बढ़ सकता है। चेक-इन के समय कनेक्ट करने का प्रयास करने वाले होटल के मेहमान के लिए, या लेनदेन को प्रोसेस करने का प्रयास करने वाले रिटेल सहयोगी के लिए, यह एक दर्दनाक समय सीमा है। **Active-Active** अधिक परिष्कृत दृष्टिकोण है, और अधिकांश एंटरप्राइज डिप्लॉयमेंट के लिए यह सही है। दोनों — या सभी — RADIUS सर्वर एक साथ ऑथेंटिकेशन अनुरोधों को प्रोसेस कर रहे होते हैं। ट्रैफ़िक को या तो राउंड-रॉबिन रोटेशन द्वारा या एक समर्पित लोड बैलेंसर द्वारा क्लस्टर में वितरित किया जाता है। जब एक नोड विफल हो जाता है, तो शेष नोड्स तुरंत उसके ट्रैफ़िक को संभाल लेते हैं। इसमें कोई फ़ेलओवर डिटेक्शन देरी नहीं होती है क्योंकि पारंपरिक अर्थों में कोई फ़ेलओवर नहीं होता है: लोड बैलेंसर बस अस्वस्थ नोड पर अनुरोध भेजना बंद कर देता है, जो आमतौर पर हेल्थ-चेक अंतराल के आधार पर एक से दो सेकंड के भीतर होता है। प्रदर्शन के लाभ कई गुना बढ़ जाते हैं। एक बड़े स्थान पर — जैसे कि 60,000 सीटों वाले स्टेडियम या किसी बड़ी प्रदर्शनी की मेजबानी करने वाले सम्मेलन केंद्र में — जब दरवाजे खुलते हैं या सेशन ब्रेक होता है, तो आप हजारों एक साथ ऑथेंटिकेशन अनुरोध देख सकते हैं। एक सिंगल RADIUS सर्वर, यहाँ तक कि एक अच्छी तरह से निर्दिष्ट सर्वर भी, एक बाधा (bottleneck) बन सकता है। एक Active-Active क्लस्टर हॉरिजॉन्टली स्केल करता है: एक और नोड जोड़ें और आप आनुपातिक क्षमता जोड़ते हैं। अब, आइए डेटाबेस परत के बारे में बात करते हैं, क्योंकि यहीं पर कई डिप्लॉयमेंट मुश्किल में पड़ जाते हैं। RADIUS ऑथेंटिकेशन स्वयं काफी हद तक स्टेटलेस है — सर्वर एक निर्देशिका (directory) के खिलाफ क्रेडेंशियल की जांच करता है और Accept या Reject लौटाता है। लेकिन RADIUS अकाउंटिंग स्टेटफुल है: यह सेशन की शुरुआत, अंतरिम अपडेट और सेशन रोकने की घटनाओं को ट्रैक करता है। यदि आप बिलिंग, अनुपालन लॉगिंग या सेशन प्रबंधन के लिए अकाउंटिंग का उपयोग कर रहे हैं, तो आपको वह डेटा सभी नोड्स में सुसंगत होना चाहिए। मानक दृष्टिकोण आपके RADIUS क्लस्टर को एक रेप्लिकेटेड डेटाबेस के साथ बैकअप प्रदान करना है। FreeRADIUS, दुनिया का सबसे व्यापक रूप से डिप्लॉय किया गया ओपन-सोर्स RADIUS सर्वर, MySQL और MariaDB के साथ एकीकृत होता है। Active-Active डिप्लॉयमेंट के लिए, आपके पास दो मुख्य विकल्प हैं: MySQL NDB Cluster, जो सब-सेकंड फ़ेलओवर के साथ सिंक्रोनस मल्टी-मास्टर रेप्लिकेशन प्रदान करता है, या Galera Cluster, जो थोड़े सरल परिचालन प्रबंधन के साथ समान सिंक्रोनस रेप्लिकेशन प्रदान करता है। दोनों नोड विफलता पर डेटा हानि के जोखिम को समाप्त करते हैं। एसिंक्रोनस रेप्लिकेशन — मानक MySQL प्राइमरी-रेप्लिका — सस्ता है लेकिन एक रेप्लिकेशन लैग (देरी) पैदा करता है जिसके परिणामस्वरूप यदि बदलावों के रेप्लिकेट होने से पहले प्राइमरी विफल हो जाता है, तो अकाउंटिंग रिकॉर्ड खो सकते हैं। मुझे भौगोलिक वितरण के प्रश्न पर बात करने दें, क्योंकि यह मल्टी-साइट ऑपरेटरों के लिए तेजी से प्रासंगिक हो रहा है। यदि आप 200 स्टोर वाली एक रिटेल श्रृंखला चला रहे हैं, या कई देशों में संपत्तियों वाला एक होटल समूह चला रहे हैं, तो सवाल केवल यह नहीं है कि "मैं अपने RADIUS सर्वर को रिडंडेंट कैसे बनाऊं?" — बल्कि यह है कि "मेरे RADIUS सर्वर मेरे एक्सेस पॉइंट्स के सापेक्ष कहाँ स्थित होने चाहिए?" किसी दूरस्थ साइट से केंद्रीय डेटा सेंटर में ऑथेंटिकेशन ट्रैफ़िक को वापस ले जाने (backhauling) से WAN लेटेंसी बढ़ती है और WAN लिंक पर सिंगल पॉइंट ऑफ़ फेल्योर पैदा होता है। यदि वह लिंक डाउन हो जाता है, तो दूरस्थ साइट किसी को भी ऑथेंटिकेट नहीं कर सकती है, चाहे आपका केंद्रीय RADIUS क्लस्टर कितना भी रिडंडेंट क्यों न हो। इसका समाधान या तो प्रत्येक साइट पर स्थानीय RADIUS इंस्टेंस डिप्लॉय करना है — जो महत्वपूर्ण परिचालन ओवरहेड पैदा करता है — या भौगोलिक रूप से वितरित एज नोड्स के साथ क्लाउड RADIUS सेवा का उपयोग करना है। Cloud RADIUS प्लेटफॉर्म आर्किटेक्चरल स्तर पर HA समस्या का समाधान करते हैं। आपके द्वारा रिडंडेंट इन्फ्रास्ट्रक्चर बनाने और प्रबंधित करने के बजाय, प्रदाता कई एवेलेबिलिटी ज़ोन और क्षेत्रों में RADIUS संचालित करता है। नोड्स के बीच फ़ेलओवर स्वचालित रूप से होता है, आमतौर पर एक सेकंड से भी कम समय में, क्योंकि यह NAS रीट्राय टाइमर के बजाय प्लेटफॉर्म के आंतरिक लोड बैलेंसिंग द्वारा नियंत्रित किया जाता है। एंटरप्राइज क्लाउड RADIUS प्रदाताओं से SLA प्रतिबद्धताएं आमतौर पर 99.99% अपटाइम होती हैं — यानी प्रति वर्ष 53 मिनट से भी कम का डाउनटाइम। यहाँ एक महत्वपूर्ण अनुपालन (compliance) आयाम भी है। PCI-DSS को कार्डधारक डेटा वातावरण के लिए मजबूत ऑथेंटिकेशन नियंत्रणों की आवश्यकता होती है। GDPR ऑथेंटिकेशन लॉग को व्यक्तिगत डेटा के रूप में मानता है, जिसके लिए उचित हैंडलिंग और डेटा रेजिडेंसी नियंत्रण की आवश्यकता होती है। Cloud RADIUS प्रदाता आमतौर पर SOC 2 Type II प्रमाणपत्र रखते हैं और क्षेत्रीय डेटा रेजिडेंसी विकल्पों के साथ GDPR डेटा प्रोसेसिंग समझौते प्रदान करते हैं। ऑन-प्रिमाइसेस डिप्लॉयमेंट आपको डेटा स्थान पर पूर्ण नियंत्रण देते हैं, जो NHS डेटा गवर्नेंस फ्रेमवर्क के तहत स्वास्थ्य सेवा के वातावरण में, या डेटा संप्रभुता आवश्यकताओं वाले सरकारी सुविधाओं में मायने रखता है। --- **भाग 3 — कार्यान्वयन सिफारिशें और कमियां (लगभग 2 मिनट)** आइए मैं आपको दो वास्तविक दुनिया के परिदृश्यों के माध्यम से ले चलता हूँ जो व्यवहार में इन सिद्धांतों को स्पष्ट करते हैं। पहला: छह देशों में 45 संपत्तियों वाला एक यूरोपीय होटल समूह। उनकी तीन इंजीनियरों की IT टीम प्रत्येक संपत्ति पर वर्चुअल मशीनों पर FreeRADIUS चला रही थी — पैच, निगरानी और रखरखाव के लिए 45 अलग-अलग इंस्टेंस। जब एक संपत्ति पर TLS सर्टिफिकेट समाप्त हो गया, तो इसके कारण एक बड़े सम्मेलन के दौरान अतिथि WiFi पूरी तरह से बंद हो गया। इसके समाधान के लिए एक इंजीनियर को रिमोट से लॉग इन करना पड़ा और मैन्युअल रूप से सर्टिफिकेट को रिन्यू करना पड़ा — एक ऐसी प्रक्रिया जिसमें 40 मिनट लगे जबकि मेहमान कनेक्ट होने में असमर्थ थे। केंद्रीकृत नीति प्रबंधन के साथ क्लाउड RADIUS सेवा पर माइग्रेट करने के बाद, टीम ने प्रति-साइट रखरखाव को पूरी तरह से समाप्त कर दिया। सर्टिफिकेट रोटेशन स्वचालित हो गया। तीनों इंजीनियरों ने पहले RADIUS संचालन पर खर्च किए गए अपने समय का लगभग 40 प्रतिशत वापस पा लिया। इससे भी महत्वपूर्ण बात यह है कि कई क्लाउड क्षेत्रों में प्लेटफॉर्म के Active-Active आर्किटेक्चर का मतलब था कि एक सिंगल नोड विफलता — जो पहले एक साइट आउटेज का कारण बनती थी — अब एक गैर-घटना (non-event) बन गई। दूसरा परिदृश्य: एक राष्ट्रीय खेल स्टेडियम जो एक बड़े कार्यक्रम के लिए 60,000 प्रशंसकों की मेजबानी कर रहा है। नेटवर्क टीम ने एक प्राइमरी सर्वर और एक हॉट स्टैंडबाय के साथ Active-Passive RADIUS कॉन्फ़िगरेशन डिप्लॉय किया था। एक प्री-इवेंट लोड टेस्ट के दौरान, उन्होंने पाया कि गेट खुलने पर ऑथेंटिकेशन उछाल के दौरान प्राइमरी सर्वर संतृप्त (saturated) हो रहा था — प्रति मिनट 8,000 ऑथेंटिकेशन अनुरोधों को प्रोसेस कर रहा था। जब प्राइमरी संघर्ष कर रहा था, तब पैसिव सेकेंडरी निष्क्रिय बैठा था। समाधान दोनों सर्वरों पर राउंड-रॉबिन लोड बैलेंसिंग का उपयोग करने के लिए NAS उपकरणों को पुन: कॉन्फ़िगर करना था, जिससे डिप्लॉयमेंट प्रभावी रूप से Active-Active में बदल गया। ऑथेंटिकेशन थ्रूपुट तुरंत दोगुना हो गया। उन्होंने चरम लोड के लिए हेडरूम प्रदान करने के लिए एक तीसरा सर्वर भी जोड़ा, और अकाउंटिंग डेटाबेस के लिए Galera Cluster रेप्लिकेशन कॉन्फ़िगर किया। इसका परिणाम एक ऐसा डिप्लॉयमेंट था जो बिना किसी उपयोगकर्ता-दृश्य प्रभाव के किसी भी सिंगल नोड के नुकसान को सहन कर सकता था। अब, कमियों की बात करते हैं। सबसे आम गलती सेकेंडरी RADIUS सर्वर को "सेट एंड फॉरगेट" बैकअप के रूप में मानना है। कॉन्फ़िगरेशन ड्रिफ्ट होते हैं। जब प्राइमरी ठीक चल रहा होता है, तो सेकेंडरी पर सर्टिफिकेट समाप्त हो जाते हैं। जब प्राइमरी अंततः विफल हो जाता है और सेकेंडरी कार्यभार संभालता है, तो वह भी विफल हो जाता है — एक पूरी तरह से अलग कारण से। इसका समाधान सरल है: नियमित रूप से, कम से कम त्रैमासिक (quarterly), अपने फ़ेलओवर का परीक्षण करें और दोनों नोड्स को प्रोडक्शन सिस्टम के रूप में मानें। दूसरी कमी डेटाबेस रेप्लिकेशन लैग (देरी) की उपेक्षा करना है। यदि आप एसिंक्रोनस रेप्लिकेशन का उपयोग कर रहे हैं और आपका प्राइमरी डेटाबेस नोड विफल हो जाता है, तो आप उन सेशन के लिए अकाउंटिंग रिकॉर्ड खो सकते हैं जो विफलता के क्षण में सक्रिय थे। PCI-DSS अनुपालन के लिए, यह एक गंभीर कमी है। किसी भी ऐसे डिप्लॉयमेंट के लिए सिंक्रोनस रेप्लिकेशन — Galera या MySQL NDB Cluster — का उपयोग करें जहाँ अकाउंटिंग डेटा अखंडता एक अनुपालन आवश्यकता है। --- **भाग 4 — रैपिड-फायर प्रश्नोत्तर (लगभग 1 मिनट)** आइए मैं उन सवालों के जवाब दूं जो मैं नेटवर्क आर्किटेक्ट्स से सबसे अक्सर सुनता हूँ। "न्यूनतम व्यवहार्य (minimum viable) HA कॉन्फ़िगरेशन क्या है?" Active-Passive फ़ेलओवर, साझा गुप्त सिंक्रोनाइज़ेशन (shared secret synchronisation), और एक रेप्लिकेटेड डेटाबेस बैकएंड के साथ दो RADIUS सर्वर। यह आपका न्यूनतम स्तर है। 500 से अधिक समवर्ती उपयोगकर्ताओं के लिए, Active-Active पर जाएं। "क्या मैं RADIUS के लिए हार्डवेयर लोड बैलेंसर का उपयोग कर सकता हूँ?" हाँ, लेकिन RADIUS UDP का उपयोग करता है, और कई लोड बैलेंसर TCP के लिए अनुकूलित होते हैं। सुनिश्चित करें कि आपका लोड बैलेंसर हेल्थ चेक के साथ UDP लोड बैलेंसिंग का समर्थन करता है। HAProxy Enterprise में एक समर्पित RADIUS UDP मॉड्यूल है। F5 BIG-IP इसे मूल रूप से (natively) संभालता है। "मैं एक HA क्लस्टर में EAP सर्टिफिकेट ट्रस्ट को कैसे संभालूं?" सभी नोड्स को समान सर्वर सर्टिफिकेट, या कम से कम एक ही CA चेन से सर्टिफिकेट प्रस्तुत करने चाहिए। क्लाइंट EAP-TLS और PEAP हैंडशेक के दौरान सर्वर सर्टिफिकेट को सत्यापित करते हैं — यदि नोड्स अलग-अलग सर्टिफिकेट प्रस्तुत करते हैं, तो आप फ़ेलओवर के बाद ऑथेंटिकेशन विफलताएं देखेंगे। "क्या क्लाउड RADIUS ऑन-प्रिमाइसेस Active Directory के साथ काम करता है?" हाँ, एक लाइटवेट कनेक्टर या LDAP प्रॉक्सी के माध्यम से जो आपके स्थानीय AD को सीधे इंटरनेट पर उजागर किए बिना क्वेरी करता है। हाइब्रिड वातावरण के लिए यह मानक एकीकरण पैटर्न है। --- **भाग 5 — सारांश और अगले कदम (लगभग 1 मिनट)** आइए मैं उन प्रमुख निर्णयों के साथ समाप्त करूँ जो आपको लेने की आवश्यकता है। यदि आप बुनियादी ढांचे के प्रबंधन के लिए एक स्थिर टीम के साथ एक ही साइट पर 500 से कम समवर्ती उपयोगकर्ताओं को चला रहे हैं, तो एक अच्छी तरह से परीक्षण की गई फ़ेलओवर प्रक्रिया के साथ Active-Passive एक उचित विकल्प है। इसे सरल रखें, नियमित रूप से इसका परीक्षण करें, और सिंक्रोनस डेटाबेस रेप्लिकेशन का उपयोग करें। यदि आप एक एस्टेट, एक हाई-डेंसिटी वाला स्थान चला रहे हैं, या यदि आपकी टीम की बैंडविड्थ सीमित है, तो Active-Active सही आर्किटेक्चर है — और क्लाउड RADIUS स्वयं इन्फ्रास्ट्रक्चर का निर्माण किए बिना वहां पहुंचने का सबसे तेज़ रास्ता है। आप जो भी मॉडल चुनें, सिद्धांत समान हैं: डुप्लिकेट करने के बजाय वितरित करें, फ़ेलओवर निर्णयों को स्वचालित करें, और अपनी विफलता परिदृश्यों का परीक्षण इससे पहले करें कि वे आपका परीक्षण करें। पैमाने पर RADIUS ऑथेंटिकेशन को संभालने के Purple के प्लेटफॉर्म के बारे में अधिक जानने के लिए — जिसमें 802.1X, WPA3 enterprise, और Guest WiFi पोर्टल्स के साथ एकीकरण शामिल है — purple.ai पर जाएं। अगली बार तक के लिए विदा। --- *स्क्रिप्ट का अंत। 150 शब्द प्रति मिनट की दर से अनुमानित पढ़ने का समय: 10 मिनट।*