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

Apigee Edge दस्तावेज़ देखा जा रहा है.
Apigee X दस्तावेज़ पर जाएं.
जानकारी

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

हमारे क्लाउड ग्राहकों के लिए इसके क्या मायने हैं

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

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

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

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

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

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

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

प्रॉडक्ट के काम करने के तरीके में बदलाव

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

बहिष्कृत

नीचे दी गई प्रॉपर्टी, प्रॉक्सीEndpoints में अब काम नहीं करती हैं:

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

इस सुविधा को बंद करने के बारे में जानने के लिए, यह कम्यूनिटी लेख देखें: https://community.apigee.com/questions/16134/proxy-endpoint-http-allow-method-properties-not-wo.html.

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

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

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