API7 Enterprise 3.2.9 में नया क्या है: अपग्रेडेड हेल्थ चेक कॉन्फ़िगरेशन

नई स्वास्थ्य जांच सुविधाओं का परिचय

API7 Enterprise के संस्करण 3.2.9 में, स्वास्थ्य जांच के लिए कॉन्फ़िगरेशन इंटरैक्शन अनुभव को व्यापक रूप से अनुकूलित किया गया है।

1. पहले बिखरे हुए कॉन्फ़िगरेशन आइटम्स को तार्किक रूप से एकत्रित किया गया है, जैसे कि प्रोब सेटिंग्स, और स्वस्थ और अस्वस्थ नोड्स को निर्धारित करने के मानदंड, जिससे वे अधिक संरचित हो गए हैं।

2. कुछ अमूर्त कॉन्फ़िगरेशन आइटम नामों को अधिक सहज और सिमेंटिक अभिव्यक्तियों में बदल दिया गया है, जिससे उपयोगकर्ता सीधे रिक्त स्थान भरने के प्रारूप में संबंधित पैरामीटर्स दर्ज कर सकते हैं, और इस प्रकार कॉन्फ़िगरेशन के व्यावहारिक प्रभावों को स्पष्ट रूप से समझ सकते हैं।

3. अपस्ट्रीम नोड्स और स्वास्थ्य जांच प्रक्रिया के कॉन्फ़िगरेशन के दौरान, अधिक प्रॉम्प्ट संदेश जोड़े गए हैं ताकि उपयोगकर्ताओं को अपस्ट्रीम नोड्स और स्वास्थ्य जांच के बीच के अंतर्निहित संबंध को बेहतर ढंग से समझने में मदद मिल सके, और इस प्रकार कॉन्फ़िगरेशन कार्यों को आसानी से पूरा किया जा सके।

स्वास्थ्य जांच की मूल अवधारणाएं

API7 Enterprise में, अपस्ट्रीम नोड्स की प्राथमिकता सेटिंग लोड बैलेंसिंग और स्वास्थ्य जांच के तंत्र से निकटता से जुड़ी हुई है। जब उपयोगकर्ता गेटवे के लिए विभिन्न प्राथमिकताओं वाले कई अपस्ट्रीम नोड्स कॉन्फ़िगर करते हैं, तो गेटवे लोड बैलेंसिंग के दौरान सर्वोच्च प्राथमिकता वाले नोड्स को प्राथमिकता देता है। इसका मतलब है कि जब तक सर्वोच्च प्राथमिकता वाले नोड्स स्वस्थ रहते हैं, गेटवे ट्रैफ़िक को इन नोड्स पर रूट करता रहेगा।

केवल तब जब सभी सर्वोच्च प्राथमिकता वाले नोड्स स्वास्थ्य जांच में विफल होने के कारण अनुपलब्ध माने जाते हैं, तो गेटवे स्वचालित रूप से डिग्रेड हो जाता है, और ट्रैफ़िक को अगले सर्वोच्च प्राथमिकता वाले अपस्ट्रीम नोड्स पर रीडायरेक्ट करता है। यह डिज़ाइन ट्रैफ़िक के कुशल उपयोग और उच्च सिस्टम उपलब्धता सुनिश्चित करता है।

यह ध्यान देने योग्य है कि यदि सेवा में कई प्राथमिकता स्तरों के अपस्ट्रीम नोड्स कॉन्फ़िगर किए गए हैं, लेकिन स्वास्थ्य जांच फ़ंक्शन अक्षम है, तो सभी क्लाइंट अनुरोध हमेशा सर्वोच्च प्राथमिकता वाले नोड्स पर रूट किए जाएंगे, चाहे उनकी वास्तविक स्वास्थ्य स्थिति कुछ भी हो।

स्वास्थ्य जांच के लिए कॉन्फ़िगरेशन विधियाँ

प्रोब कॉन्फ़िगरेशन

एक प्रोब अपस्ट्रीम नोड्स की जीवंतता और सेवा स्थिति का पता लगाने के लिए उपयोग किया जाता है। APISIX में, प्रोब एक "इंस्पेक्टर" की तरह है जो नियमित रूप से दरवाज़ा खटखटाता है ताकि यह जांच सके कि अपस्ट्रीम सेवा ठीक से काम कर रही है या नहीं। यदि इसे कोई समस्या मिलती है या सेवा "अनुपलब्ध" है, तो यह APISIX को सूचित करता है: "यह सेवा वर्तमान में अनुपलब्ध है, इसलिए यहां अनुरोध भेजने से रोकें।" यह "दरवाज़ा खटखटाने" की प्रक्रिया प्रोब के माध्यम से की जाती है।

प्रोब में मुख्य रूप से निम्नलिखित कॉन्फ़िगरेशन आइटम शामिल हैं:

• प्रोब स्कीम: स्वास्थ्य जांच प्रोब द्वारा उपयोग किया जाने वाला प्रोटोकॉल प्रकार, जो TCP, HTTP, और HTTPS का समर्थन करता है।

• समवर्तीता: यह कॉन्फ़िगरेशन आइटम आपको समवर्ती स्वास्थ्य जांच अनुरोधों की संख्या सेट करने की अनुमति देता है। दूसरे शब्दों में, यह वह संख्या है जिसके साथ आप एक साथ "दरवाज़ा खटखटाना" चाहते हैं ताकि अपस्ट्रीम सेवाओं की प्रतिक्रियाशीलता की जांच की जा सके। समवर्तीता को समायोजित करके, आप वास्तविक दुनिया के परिदृश्यों में संभावित समवर्ती अनुरोधों का अनुकरण कर सकते हैं, और इस प्रकार अपस्ट्रीम सेवाओं के प्रदर्शन और स्थिरता का बेहतर मूल्यांकन कर सकते हैं।

• होस्ट: जांचे जाने वाले अपस्ट्रीम सर्वर का होस्ट पता निर्दिष्ट करता है। यह यह निर्धारित करने जैसा है कि किस घर का "दरवाज़ा खटखटाना" है।

• पोर्ट: अपस्ट्रीम सेवा का पोर्ट नंबर। यह प्रोब के दौरान यह जानने जैसा है कि किस दरवाज़े पर खटखटाना है।

• पथ: यदि आप HTTP प्रोब का उपयोग कर रहे हैं, तो यह कॉन्फ़िगरेशन आइटम उस URL पथ को निर्दिष्ट करता है जिसे आप एक्सेस करना चाहते हैं। यह प्रोब को यह बताने जैसा है कि एक बार अंदर जाने के बाद सही कमरे की जांच करें।

स्वस्थ नोड्स निर्धारित करने के मानदंड

स्वस्थ नोड्स निर्धारित करने के संबंध में, सिस्टम उपयोगकर्ता द्वारा सेट किए गए अंतराल (सेकंड में) पर पहले से अस्वस्थ चिह्नित नोड्स की नियमित रूप से जांच करता है ताकि किसी भी क्षणिक नोड असामान्यताओं का समय पर पता लगाया जा सके और उनका उचित प्रबंधन किया जा सके।

यदि प्रोब TCP प्रोटोकॉल का उपयोग करता है, तो नोड को स्वस्थ माना जाता है जब प्रोब उपयोगकर्ता द्वारा सेट की गई संख्या में अपस्ट्रीम नोड से सफलतापूर्वक कनेक्ट हो जाता है।

यदि प्रोब HTTP/HTTPS प्रोटोकॉल का उपयोग करता है, तो सिस्टम नोड को स्वस्थ मानता है केवल तब जब यह नोड से निर्दिष्ट स्थिति कोड (जैसे 200 और 302) के साथ लगातार प्रोब अनुरोध प्राप्त करता है। इसका मतलब है कि नोड को केवल तब ठीक से काम कर रहा माना जाता है जब यह लगातार इन विशिष्ट स्थिति कोड्स को वापस करता है।

अस्वस्थ नोड्स निर्धारित करने के मानदंड

अस्वस्थ नोड्स निर्धारित करने के संबंध में, कॉन्फ़िगरेशन विधि स्वस्थ नोड्स निर्धारित करने के समान है। सिस्टम उपयोगकर्ता द्वारा सेट किए गए अंतराल पर स्वस्थ चिह्नित नोड्स की नियमित रूप से जांच करता है। एक बार ये नोड्स पूर्वनिर्धारित अस्वस्थ स्थितियों को पूरा करते हैं, तो उन्हें फिर से अस्वस्थ के रूप में वर्गीकृत किया जाता है।

स्वस्थ नोड्स निर्धारित करने से थोड़ा अलग, अस्वस्थ नोड्स निर्धारित करने की प्रक्रिया के दौरान एक अतिरिक्त कॉन्फ़िगरेशन आइटम, क्लाइंट अनुरोध सत्यापन, जोड़ा गया है। जब यह सुविधा सक्षम होती है, तो गेटवे न केवल प्रोब के निरीक्षण परिणामों पर निर्भर करता है, बल्कि क्लाइंट्स से अनुरोधों और अपस्ट्रीम सेवाओं की वास्तविक प्रतिक्रियाओं का गहराई से अवलोकन और विश्लेषण भी करता है। इन डेटा और उपयोगकर्ता-परिभाषित निर्णय मानदंडों के आधार पर, गेटवे अपस्ट्रीम सेवाओं की चल रही स्थिति का अधिक सटीक मूल्यांकन कर सकता है।

स्वास्थ्य जांच के लिए सर्वोत्तम प्रथाएं

उपयुक्त प्रोब प्रकार का चयन

• TCP प्रोब: उन परिदृश्यों के लिए उपयुक्त है जहां केवल यह पुष्टि करने की आवश्यकता होती है कि सेवा पोर्ट खुला और पहुंच योग्य है। उदाहरण के लिए, एक डेटाबेस सेवा को केवल पोर्ट खोलने की पुष्टि करने के लिए TCP प्रोब की आवश्यकता हो सकती है।

• HTTP/HTTPS प्रोब: उन परिदृश्यों के लिए अधिक उपयुक्त है जहां न केवल नेटवर्क कनेक्शन सामान्य होने की पुष्टि करने की आवश्यकता होती है, बल्कि यह भी कि सेवा अनुरोधों को सही ढंग से संभाल सकती है। उदाहरण के लिए, एक वेब सर्वर या API सेवा के लिए, हमें यह सुनिश्चित करने की आवश्यकता होती है कि यह न केवल कनेक्शन प्राप्त कर सकता है, बल्कि सही पृष्ठ या डेटा भी वापस कर सकता है।

स्वास्थ्य जांच के लिए उचित कॉन्फ़िगरेशन पैरामीटर्स

स्वास्थ्य जांच कॉन्फ़िगर करते समय, कई महत्वपूर्ण पैरामीटर्स पर ध्यान दें:

• जांच अंतराल: यह बहुत छोटा नहीं होना चाहिए ताकि अनावश्यक ओवरहेड से बचा जा सके या बहुत लंबा नहीं होना चाहिए ताकि समस्याओं के मामले में धीमी प्रतिक्रिया से बचा जा सके। उदाहरण के लिए, एक उच्च ट्रैफ़िक वाली ई-कॉमर्स वेबसाइट के लिए, हर 30 सेकंड में जांच करना एक अपेक्षाकृत उचित विकल्प है। यह अंतराल न तो सिस्टम संसाधनों को अत्यधिक खपत करता है और न ही वेबसाइट पर समस्याओं का पता लगाने और उन्हें संभालने में देरी करता है।

  बेशक, यह अंतराल पूर्ण नहीं है, और वेबसाइट की वास्तविक स्थिति के आधार पर समायोजन करने की आवश्यकता होती है। उदाहरण के लिए, यदि वेबसाइट ट्रैफ़िक में महत्वपूर्ण उतार-चढ़ाव का अनुभव करती है या विशिष्ट अवधियों (जैसे प्रचार अभियानों के दौरान) में ट्रैफ़िक में वृद्धि होती है, तो इन परिवर्तनों को समायोजित करने के लिए जांच अंतराल को समायोजित करने की आवश्यकता हो सकती है।

• टाइमआउट: सेवा प्रतिक्रिया के लिए प्रोब द्वारा प्रतीक्षा का समय। यदि सेवा इस समय के भीतर प्रतिक्रिया नहीं देती है, तो प्रोब सेवा को अस्वस्थ मानता है। यह मान सेवा की वास्तविक प्रतिक्रिया समय के अनुसार सेट किया जाना चाहिए।

• पुनः प्रयास संख्या: सेवा को अस्वस्थ मानने से पहले प्रोब द्वारा कनेक्ट करने का प्रयास करने की संख्या। यह मान मध्यम होना चाहिए ताकि गलत निर्णय से बचा जा सके।

व्यवसाय के आधार पर रणनीतियों को समायोजित करना

स्वास्थ्य जांच रणनीतियों को वास्तविक व्यवसाय स्थिति के आधार पर समायोजित किया जाना चाहिए। यदि एक सेवा विशिष्ट समय अवधियों के दौरान आमतौर पर उच्च लोड का अनुभव करती है, तो इन अवधियों के दौरान स्वास्थ्य जांच अंतराल को बढ़ाया जा सकता है या पुनः प्रयास संख्या को कम किया जा सकता है ताकि सेवा पर अतिरिक्त दबाव से बचा जा सके।

उचित रूप से क्लाइंट अनुरोध सत्यापन सक्षम करना

क्लाइंट अनुरोध सत्यापन वास्तविक व्यवसाय अनुरोधों के आधार पर सेवा स्थिति का प्रभावी ढंग से निर्धारण कर सकता है, विशेष रूप से व्यवसाय तर्क से निकटता से जुड़े मुद्दों की पहचान करने के लिए। हालांकि, यह हर व्यवसाय परिदृश्य के लिए उपयुक्त नहीं हो सकता है।

1. कम ट्रैफ़िक वाली सेवाएं: यदि सेवा ट्रैफ़िक कम है, तो क्लाइंट अनुरोधों पर आधारित निष्क्रिय स्वास्थ्य जांच सेवा स्थिति का सटीक मूल्यांकन करने के लिए पर्याप्त डेटा पॉइंट्स प्रदान नहीं कर सकती है। ऐसे मामलों में, सक्रिय प्रोब जांच पर निर्भर होना अधिक विश्वसनीय हो सकता है।

2. उच्च-समवर्ती वातावरण में प्रदर्शन विचार: निष्क्रिय स्वास्थ्य जांच के लिए प्रत्येक क्लाइंट अनुरोध की निगरानी और प्रसंस्करण की आवश्यकता होती है, जो उच्च-समवर्ती वातावरण में अतिरिक्त प्रदर्शन ओवरहेड बढ़ा सकता है। यदि प्रदर्शन प्राथमिक चिंता है और सेवा को अन्य माध्यमों से पर्याप्त रूप से निगरानी किया गया है, तो निष्क्रिय स्वास्थ्य जांच को बंद करने पर विचार किया जा सकता है।

3. अन्य निगरानी प्रणालियों का अस्तित्व: यदि उद्यम में पहले से ही परिपक्व निगरानी प्रणालियां तैनात की गई हैं, जो सेवा स्थिति को वास्तविक समय में पकड़ने और विश्लेषण करने में सक्षम हैं, तो निष्क्रिय स्वास्थ्य जांच अनावश्यक हो सकती है ताकि डेटा अतिरिक्तता और अतिरिक्त जटिलता से बचा जा सके।

निष्कर्ष

स्वास्थ्य जांच API गेटवे की उच्च उपलब्धता सुनिश्चित करने का एक महत्वपूर्ण पहलू है। API7 Enterprise के संस्करण 3.2.9 में, हमने स्वास्थ्य जांच के इंटरैक्टिव कॉन्फ़िगरेशन को व्यापक रूप से अनुकूलित किया है, जिससे संचालन सरल हो गया है और उपयोगकर्ता अनुभव बेहतर हुआ है।

प्रोब को उचित रूप से कॉन्फ़िगर करके, स्वस्थ और अस्वस्थ नोड्स के लिए मानदंड सेट करके, और वास्तविक व्यवसाय आवश्यकताओं के आधार पर रणनीतियों को समायोजित करके, उपयोगकर्ता अपस्ट्रीम सेवाओं की स्थिति को अधिक प्रभावी ढंग से निगरानी कर सकते हैं, यह सुनिश्चित करते हुए कि ट्रैफ़िक हमेशा स्वस्थ नोड्स पर रूट किया जाता है। यह न केवल सिस्टम की स्थिरता और उपलब्धता को बढ़ाता है, बल्कि यह भी सुनिश्चित करता है कि उपयोगकर्ता अनुरोधों को समय पर और सटीक प्रतिक्रिया मिलती है।