Apigee Edge का दस्तावेज़ देखा जा रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी
हम अगस्त और सितंबर 2015 के दौरान, अपने Apigee Edge क्लाउड राउटर और लोड बैलेंसर को NGINX (उच्चारण "इंजन एक्स") पर माइग्रेट कर रहे हैं. NGINX एक ओपन-सोर्स वेब सर्वर है. यह हमारे मौजूदा लोड बैलेंसर और राउटर की तुलना में बेहतर परफ़ॉर्मेंस और ज़्यादा कंसिस्टेंसी देता है.
हमारे क्लाउड ग्राहकों पर इसका क्या असर होगा
इसका मकसद यह है कि आपको इस बदलाव के बारे में साफ़ तौर पर जानकारी दी जाए. साथ ही, आपको कुछ करने की ज़रूरत नहीं है. बस यह पुष्टि करनी होगी कि आपके सिस्टम उम्मीद के मुताबिक काम कर रहे हैं या नहीं. यहां उन चरणों के बारे में बताया गया है जिन्हें हम अपनाएंगे. साथ ही, अक्सर पूछे जाने वाले कुछ सवालों के जवाब भी दिए गए हैं.
पहला चरण - सॉफ़्टवेयर अपडेट करना
हम सभी राउटर को, धीरे-धीरे डिप्लॉय करने के अपने मॉडल का इस्तेमाल करके, नए NGINX-आधारित राउटर पर अपग्रेड करेंगे. इससे यह पक्का करने में मदद मिलेगी कि इस गतिविधि की वजह से सेवाओं पर कोई असर न पड़े.
दूसरा चरण - प्रोडक्शन एनवायरमेंट के अलावा अन्य एनवायरमेंट में, लोड बैलेंसर टीयर हटाना
लोड बैलेंसिंग की सुविधा को मैनेज करने वाले नए NGINX राउटर की मदद से, हम पहले आपके नॉन-प्रोडक्शन एनवायरमेंट में मौजूद लोड बैलेंसर टीयर को हटाने की प्रोसेस शुरू करेंगे. इस चरण के दौरान, प्रोडक्शन लोड बैलेंसर में कोई बदलाव नहीं होगा. मौजूदा लोड बैलेंसर हटाने से पहले, हम यह पक्का करने के लिए पूरी कोशिश करेंगे कि ट्रैफ़िक उम्मीद के मुताबिक काम कर रहा हो. यह चरण पूरा करने के लिए, आपको कुछ करने की ज़रूरत नहीं है. हालांकि, आपको किसी भी समस्या की शिकायत Apigee से करनी चाहिए. साथ ही, तीसरे चरण पर जाने से पहले, हम समस्याओं को हल करने के लिए आपके साथ मिलकर काम करेंगे.
तीसरा चरण - प्रोडक्शन एनवायरमेंट में लोड बैलेंसर टीयर हटाना
दूसरा चरण पूरा होने के बाद, हम रखरखाव की विंडो का एक सेट तय करेंगे, ताकि प्रोडक्शन एनवायरमेंट में लोड बैलेंसर टीयर को हटाया जा सके. इसके लिए, हम दूसरे चरण में बताए गए तरीके का इस्तेमाल करेंगे. इससे यह पक्का किया जा सकेगा कि रनटाइम एपीआई ट्रैफ़िक उम्मीद के मुताबिक काम करता रहे.
प्रॉडक्ट की सुविधाओं में बदलाव
NGINX पर स्विच करने के बाद, प्रॉडक्ट की सुविधाओं में ये बदलाव हुए हैं.
बहिष्कृत
ProxyEndpoints में अब ये प्रॉपर्टी काम नहीं करतीं:
- 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 एंट्री, उम्मीद के मुताबिक काम करती रहेंगी.
अगर एसएसएल का इस्तेमाल किया जा रहा है, तो शुरुआती चरण से मौजूदा एसएसएल कॉन्फ़िगरेशन पर कोई असर नहीं पड़ेगा. हालांकि, दूसरे और तीसरे चरण पर जाने से पहले, हमें आपके साथ मिलकर यह पक्का करना होगा कि नए राउटर पर एसएसएल ठीक से सेट अप हो गया है.
जब तक एसएनआई की सुविधा के काम करने की पुष्टि नहीं हो जाती, तब तक दूसरे और तीसरे चरण को पूरा नहीं किया जा सकेगा.
हमें डाउनटाइम (सिर्फ़ ज़रूरी सूचनाएं मिलना) होने की कोई उम्मीद नहीं है. ये बदलाव, रिलीज़ की मौजूदा विंडो के दौरान, डिप्लॉयमेंट के हमारे स्टैंडर्ड मॉडल का इस्तेमाल करके लागू किए जाएंगे.