NGINX राऊटर और लोड बैलेंसर पर माइग्रेशन

यहां Apigee Edge से जुड़े दस्तावेज़ देखे जा रहे हैं.
Apigee X
से जुड़े दस्तावेज़ पर जाएं.
info

अगस्त और सितंबर 2015 के दौरान, हम अपने Apigee Edge क्लाउड राऊटर और लोड बैलेंसर को NGINX (जिसे "इंजन X" कहा जाता है) पर माइग्रेट कर रहे हैं. ओपन-सोर्स वेब सर्वर NGINX, हमारे मौजूदा लोड बैलेंसर और राऊटर की तुलना में बेहतर परफ़ॉर्मेंस और ज़्यादा कंकरेंसी देता है.

क्लाउड के हमारे ग्राहकों पर इन बदलावों का क्या असर होगा

असल में, इस बदलाव के बारे में आपको पता नहीं चलेगा. साथ ही, आपको यह पुष्टि करने के अलावा कोई कार्रवाई नहीं करनी होगी कि आपके सिस्टम उम्मीद के मुताबिक काम कर रहे हैं. यहां, हम जो कदम उठाने वाले हैं उनके बारे में बताया गया है. साथ ही, अक्सर पूछे जाने वाले कुछ सवालों के जवाब भी दिए गए हैं.

पहला चरण - सॉफ़्टवेयर अपडेट करना

हम सभी राऊटर को NGINX पर आधारित नए राऊटर पर अपग्रेड करेंगे. इसके लिए, हम चरणबद्ध तरीके से डिप्लॉयमेंट मॉडल का इस्तेमाल करेंगे, ताकि यह पक्का किया जा सके कि इस गतिविधि की वजह से सेवाओं पर कोई असर न पड़े.

दूसरा चरण - नॉन-प्रोडक्शन एनवायरमेंट में लोड बैलेंसर टियर को हटाना

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

तीसरा चरण - प्रोडक्शन एनवायरमेंट में लोड बैलेंसर टियर को हटाना

दूसरे चरण के सफलतापूर्वक पूरा होने के बाद, हम प्रोडक्शन एनवायरमेंट में लोड बैलेंसर टियर को हटाने के लिए, रखरखाव की कुछ विंडो तय करेंगे . इसके लिए, हम दूसरे चरण में बताए गए तरीके का इस्तेमाल करेंगे , ताकि यह पक्का किया जा सके कि रनटाइम एपीआई ट्रैफ़िक उम्मीद के मुताबिक काम करता रहे.

प्रॉडक्ट की सुविधाओं में बदलाव

NGINX पर स्विच करने के बाद, प्रॉडक्ट की सुविधाओं में कुछ बदलाव किए गए हैं. इनके बारे में यहां बताया गया है.

बहिष्कृत

ProxyEndpoints में अब इन प्रॉपर्टी का इस्तेमाल नहीं किया जा सकेगा:

  • allow.http10
  • allow.http11
  • allow.http.method.*
  • allow.POST.without.content.length
  • allow.PUT.without.content.length

इस बदलाव के बारे में ज़्यादा जानने के लिए, कम्यूनिटी का यह लेख पढ़ें: Proxy Endpoint HTTP allow method properties not working.

अक्सर पूछे जाने वाले सवाल

यहां, NGINX पर माइग्रेट करने के बारे में अक्सर पूछे जाने वाले कुछ सवालों के जवाब दिए गए हैं.

क्या इससे सार्वजनिक आईपी पते बदल सकते हैं? हमारे कुछ व्यापारी, सिर्फ़ उन आईपी पतों से ऐक्सेस की अनुमति देते हैं जिनके बारे में उन्हें पता है. अगर ये आईपी पते बदल जाते हैं, तो व्यापारियों का फ़्लो रुक जाता है.
पहले चरण के दौरान, इसका जवाब ‘नहीं’ है. ऐसा इसलिए, क्योंकि हम मौजूदा लोड बैलेंसर में कोई बदलाव नहीं कर रहे हैं. इससे ट्रैफ़िक को मैनेज करने वाले किसी भी आईपी पते में सीधे तौर पर कोई बदलाव नहीं होगा. हालांकि, Amazon Web Services (AWS) की लोड बैलेंसिंग सेवा की प्रकृति को देखते हुए, सामान्य स्केलिंग के नियम लागू होते हैं, इसका मतलब है कि स्केलिंग लॉजिक (मौजूदा सुविधा) के तहत, आईपी पते बदल सकते हैं. इसलिए, हम Apigee Edge प्रॉडक्ट सुइट के साथ, नॉर्थबाउंड की अनुमति वाली सूची के कॉन्फ़िगरेशन लागू करने की सलाह नहीं देते. दूसरे और तीसरे चरण के दौरान, लोड बैलेंसर और उससे जुड़े आईपी पतों को हटाने के बाद, अनुमति वाली सूची पर असर पड़ेगा. इसलिए, इन चरणों के दौरान, हम आपके साथ मिलकर काम करेंगे, ताकि आपको ऐक्सेस की अनुमति देने के लिए, आईपी पतों का नया सेट उपलब्ध कराकर, यह पक्का किया जा सके कि माइग्रेशन की प्रोसेस आसानी से पूरी हो.
क्या इससे हमारे ऑरिजिन सर्वर पर लागू आईपी पाबंदियों पर असर पड़ेगा?
किसी बदलाव की ज़रूरत नहीं है. हालांकि, यह मान लिया जाता है कि ऑरिजिन सर्वर, टारगेट एंडपॉइंट सर्वर हैं. इन्हें प्रॉक्सी बंडल से कॉल किया जाता है. यह बदलाव, Apigee के नॉर्थबाउंड साइड या Apigee में इनग्रेस पॉइंट पर किया गया है.
क्या हमें अपने मौजूदा CNAME में बदलाव करना होगा?
नहीं. मौजूदा CNAME एंट्री, उम्मीद के मुताबिक काम करती रहेंगी.
एसएसएल सर्टिफ़िकेट को माइग्रेट करना मुश्किल होगा. आप इसे कैसे मैनेज करेंगे यह?
अगर आप एसएसएल का इस्तेमाल कर रहे हैं, तो शुरुआती चरण में मौजूदा एसएसएल कॉन्फ़िगरेशन पर कोई असर नहीं पड़ेगा. हालांकि, दूसरे और तीसरे चरण पर जाने से पहले, हमें आपके साथ मिलकर काम करना होगा, ताकि यह पक्का किया जा सके कि नए राऊटर पर एसएसएल को सही तरीके से सेट अप किया गया हो.
अगर मेरा ऐप्लिकेशन/क्लाइंट, एसएनआई के साथ काम नहीं करता, तो क्या होगा?
एसएनआई के साथ काम करने की पुष्टि होने तक, दूसरा और तीसरा चरण पूरा नहीं किया जाएगा.
क्या कोई डाउनटाइम होगा?
हमें किसी डाउनटाइम की उम्मीद नहीं है. बदलावों को, रिलीज़ की मौजूदा विंडो के दौरान, हमारे स्टैंडर्ड डिप्लॉयमेंट मॉडल का इस्तेमाल करके लागू किया जाएगा.