النقل إلى أجهزة توجيه NGINX وأجهزة موازنة الحمل

أنت تطّلع على مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X.
info

خلال شهرَي آب (أغسطس) وأيلول (سبتمبر) 2015، سننقل أجهزة توجيه السحابة الإلكترونية وموزّعات الحمولة في Apigee Edge إلى NGINX (يُنطق "إنجين إكس"). يقدّم NGINX، وهو خادم ويب مفتوح المصدر، أداءً أفضل وعدد عمليات متزامنة أكبر من تلك التي يوفّرها موزّعات الحمولة وأجهزة التوجيه الحالية.

تأثير هذا التغيير في عملاء خدمات السحابة الإلكترونية

خلاصة القول هي أنّ هذا التغيير يجب أن يكون واضحًا لك ولا يتطلّب منك سوى التحقّق من أنّ أنظمتك تعمل على النحو المتوقّع. في ما يلي أوصاف للخطوات التي سنتّخذها، بالإضافة إلى إجابات عن بعض الأسئلة الشائعة.

الخطوة 1: تحديث البرامج

سنُجري ترقية لجميع أجهزة التوجيه إلى جهاز التوجيه الجديد المستنِد إلى NGINX من خلال الاستفادة من نموذج النشر على مراحل للمساعدة في ضمان عدم تأثُّر الخدمات نتيجةً لهذا النشاط.

الخطوة 2 - إزالة فئة موازن الحمولة في البيئات غير المخصّصة للإنتاج

مع جهاز توجيه NGINX الجديد الذي يتولّى وظيفة موازنة التحميل، سنبدأ عملية إزالة مستوى موازن التحميل الحالي في البيئات غير المخصّصة للإنتاج أولاً. ستظلّ أدوات توزيع الأحمال في مرحلة الإنتاج سليمة بدون تغيير خلال هذه الخطوة. قبل إزالة أدوات توازن الحمولة الحالية، سنعتمد نهجًا شاملاً لضمان عمل الزيارات على النحو المتوقّع. ليس عليك اتّخاذ أي إجراء لإكمال هذه الخطوة. ومع ذلك، عليك الإبلاغ عن أي مشاكل إلى فريق Apigee، وسنعمل معك لحلّ المشاكل قبل المتابعة إلى الخطوة 3.

الخطوة 3: إزالة فئة موازن الحمولة في بيئات الإنتاج

بعد إكمال الخطوة 2 بنجاح، سنحدّد مجموعة من فترات الصيانة لإزالة مستوى موازن الحمولة في بيئات الإنتاج باستخدام النهج نفسه المذكور في الخطوة 2 لضمان استمرار عمل الزيارات إلى واجهة برمجة التطبيقات في وقت التشغيل على النحو المتوقّع.

التغييرات على وظائف المنتج

في ما يلي بعض التغييرات على وظائف المنتج بعد التبديل إلى 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.

هل من المحتمل أن يؤدي ذلك إلى تغيير عناوين IP العامة؟ يسمح بعض التجّار على وجه التحديد بالوصول من عناوين IP المعروفة، وعند تغييرها، تتوقف عملية التجّار.
خلال الخطوة 1، الإجابة هي "لا" لأنّنا لا نغيّر موزّعات الحمولة الحالية، ما لن يؤدي مباشرةً إلى تغيير أي من عناوين IP التي تعرِض الزيارات. ومع ذلك، نظرًا ل طبيعة خدمة موازنة التحميل في Amazon Web Services (AWS)، تنطبق قواعد التوسيع العادية، ما يعني أنّ عناوين IP قد تتغيّر كجزء من منطق التوسيع (الوظيفة الحالية). لهذا السبب، لا ننصح بتنفيذ إعدادات القائمة المسموح بها للاتصالات الواردة باستخدام مجموعة منتجات Apigee Edge. أثناء الخطوتَين 2 و3، هناك تأثيرات في القائمة المسموح بها عند إزالة UME عناوين IP المرتبطة به. نتيجةً لذلك، سننسق معك عن كثب خلال هذه الخطوات لضمان عملية انتقال سلسة من خلال توفير مجموعة جديدة من عناوين IP التي يمكن للمستخدمين الوصول إليها.
هل سيؤثّر ذلك في قيود عناوين IP التي وضعناها على ملفّات المحتوى الأصلية على خوادمنا؟
ما مِن تغييرات مطلوبة، بافتراض أنّ خوادم المصدر هي خوادم نقاط النهاية المستهدفة (الخوادم التي يتمّ استدعاؤها من حِزمة الخادم الوكيل). يقع هذا التغيير على الجانب الشمالي من Apigee أو نقطة دخول إلى Apigee.
هل سيتطلب تغيير سجلّ CNAME الحالي؟
لا، ستستمرّ إدخالات CNAME الحالية في العمل على النحو المتوقّع.
سيكون نقل شهادة طبقة المقابس الآمنة (SSL) عملية صعبة. كيف ستتعامل مع هذا الأمر؟
إذا كنت تستخدم طبقة المقابس الآمنة (SSL)، لن تؤثّر الخطوة الأولية في إعدادات SSL الحالية. ومع ذلك، سنحتاج إلى التنسيق معك عن كثب لضمان إعداد بروتوكول SSL بشكل صحيح على جهاز التوجيه الجديد قبل المتابعة إلى الخطوتَين 2 و3.
ماذا لو كان تطبيقي أو برنامجي لا يتيح استخدام إشارة اسم الخادم (SNI)؟
سيتم تأجيل الخطوتَين 2 و3 إلى أن يتم تأكيد توفّر SNI.
هل ستكون هناك أي فترة توقف عن العمل؟
لا نتوقّع حدوث أي فترة توقف عن العمل. وسيتم تنفيذ التغييرات باستخدام نموذج النشر المعتاد خلال فترات الإصدار الحالية.