RADIUS सर्वर हाई अवेलेबिलिटी: एक्टिव-एक्टिव बनाम एक्टिव-पैसिव

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