مهاجرت به روترها و بار متعادل کننده های NGINX

شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات

در سراسر آگوست و سپتامبر 2015، ما مسیریاب‌های ابری Apigee Edge و متعادل‌کننده‌های بار را به NGINX (تلفظ "Engine X") منتقل می‌کنیم. NGINX، یک وب سرور منبع باز، حتی عملکرد بهتر و همزمانی بالاتری نسبت به متعادل کننده های بار و روترهای موجود ما ارائه می دهد.

این برای مشتریان ابری ما چه معنایی دارد

نکته اصلی این است که این تغییر باید برای شما شفاف باشد و نیازی به هیچ اقدامی از جانب شما ندارد، به جز تأیید اینکه سیستم شما مطابق انتظار کار می کند. در ادامه مراحلی را که انجام خواهیم داد، همراه با پاسخ به برخی از سوالات متداول شرح داده شده است.

مرحله 1 - به روز رسانی نرم افزار

ما همه روترها را با استفاده از مدل استقرار مرحله‌ای خود به روتر جدید مبتنی بر NGINX ارتقا می‌دهیم تا اطمینان حاصل شود که سرویس‌ها در نتیجه این فعالیت تحت تأثیر قرار نمی‌گیرند.

مرحله 2 - لایه متعادل کننده بار را در محیط های غیر تولیدی بردارید

با روتر جدید NGINX که عملکرد متعادل کننده بار را مدیریت می کند، ابتدا روند حذف لایه متعادل کننده بار موجود در محیط(های) غیر تولیدی شما را آغاز می کنیم. متعادل کننده های بار تولید در این مرحله دست نخورده و بدون تغییر باقی می مانند. قبل از حذف متعادل کننده های بار موجود، ما یک رویکرد جامع برای اطمینان از اینکه ترافیک همانطور که انتظار می رود کار می کند، اتخاذ خواهیم کرد. برای تکمیل این مرحله هیچ اقدامی از طرف شما لازم نیست. با این حال، شما باید هر گونه مشکلی را به Apigee گزارش دهید، و ما قبل از ادامه مرحله 3 برای حل مشکلات با شما همکاری خواهیم کرد.

مرحله 3 - لایه متعادل کننده بار را در محیط های تولیدی بردارید

پس از تکمیل موفقیت‌آمیز مرحله 2، مجموعه‌ای از پنجره‌های تعمیر و نگهداری را برای حذف لایه متعادل‌کننده بار در محیط(های) تولید با استفاده از همان رویکرد ذکر شده در مرحله 2 تعیین می‌کنیم تا اطمینان حاصل کنیم که ترافیک API در زمان اجرا همانطور که انتظار می‌رود کار می‌کند.

تغییرات در عملکرد محصول

در اینجا برخی از تغییرات در عملکرد محصول با سوئیچ به NGINX آورده شده است.

منسوخ شده است

ویژگی‌های زیر دیگر در ProxyEndpoints پشتیبانی نمی‌شوند:

  • اجازه دهید.http10
  • اجازه دهید.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 های ارائه دهنده ترافیک را تغییر نمی دهد. با این حال، با توجه به ماهیت سرویس متعادل کننده بار سرویس های وب آمازون (AWS)، قوانین مقیاس بندی معمولی اعمال می شود، به این معنی که IP ها ممکن است به عنوان بخشی از منطق مقیاس بندی آن (عملکرد موجود) تغییر کنند. به همین دلیل است که ما اجرای تنظیمات فهرست مجاز Northbound را با مجموعه محصول Apigee Edge توصیه نمی کنیم. در طی مراحل 2 و 3، پیامدهای لیست مجاز با حذف متعادل کننده بار و آدرس های IP مرتبط با آن وجود دارد. در نتیجه، ما در طی این مراحل از نزدیک با شما هماهنگ می‌کنیم تا با ارائه مجموعه‌ای از آدرس‌های IP جدید که امکان دسترسی به آن‌ها را فراهم می‌کند، انتقال همواری را تضمین کنیم.
آیا این بر محدودیت های IP که در سرورهای اصلی خود داریم تأثیر می گذارد؟
هیچ تغییری لازم نیست، با فرض اینکه سرورهای مبدا سرورهای نقطه پایانی هدف هستند (سرورهایی که از بسته پروکسی فراخوانی می شوند). این تغییر در سمت شمال Apigee یا نقطه ورود به Apigee است.
آیا CNAME موجود ما نیاز به تغییر دارد؟
خیر. ورودی های CNAME موجود همانطور که انتظار می رود به کار خود ادامه می دهند.
انتقال گواهی SSL دردناک خواهد بود. چگونه می خواهید با این موضوع کنار بیایید؟
اگر از SSL استفاده می کنید، مرحله اولیه بر پیکربندی SSL موجود تأثیری نخواهد داشت. با این حال، قبل از ادامه مراحل 2 و 3، باید از نزدیک با شما هماهنگ کنیم تا مطمئن شویم SSL به درستی در روتر جدید تنظیم شده است.
اگر برنامه/کلینت من از SNI پشتیبانی نکند چه؟
مراحل 2 و 3 تا تایید پشتیبانی SNI به تعویق خواهد افتاد.
آیا توقفی وجود خواهد داشت؟
ما انتظار هیچ گونه خرابی نداریم. تغییرات با استفاده از مدل استقرار استاندارد ما در طول پنجره‌های انتشار موجود ما اجرا می‌شوند.
،

شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات

در سراسر آگوست و سپتامبر 2015، ما مسیریاب‌های ابری Apigee Edge و متعادل‌کننده‌های بار را به NGINX (تلفظ "Engine X") منتقل می‌کنیم. NGINX، یک وب سرور منبع باز، حتی عملکرد بهتر و همزمانی بالاتری نسبت به متعادل کننده های بار و روترهای موجود ما ارائه می دهد.

این برای مشتریان ابری ما چه معنایی دارد

نکته اصلی این است که این تغییر باید برای شما شفاف باشد و نیازی به هیچ اقدامی از جانب شما ندارد، به جز تأیید اینکه سیستم شما مطابق انتظار کار می کند. در ادامه مراحلی را که انجام خواهیم داد، همراه با پاسخ به برخی از سوالات متداول شرح داده شده است.

مرحله 1 - به روز رسانی نرم افزار

ما همه روترها را با استفاده از مدل استقرار مرحله‌ای خود به روتر جدید مبتنی بر NGINX ارتقا می‌دهیم تا اطمینان حاصل شود که سرویس‌ها در نتیجه این فعالیت تحت تأثیر قرار نمی‌گیرند.

مرحله 2 - لایه متعادل کننده بار را در محیط های غیر تولیدی بردارید

با روتر جدید NGINX که عملکرد متعادل کننده بار را مدیریت می کند، ابتدا روند حذف لایه متعادل کننده بار موجود در محیط(های) غیر تولیدی شما را آغاز می کنیم. متعادل کننده های بار تولید در این مرحله دست نخورده و بدون تغییر باقی می مانند. قبل از حذف متعادل کننده های بار موجود، ما یک رویکرد جامع برای اطمینان از اینکه ترافیک همانطور که انتظار می رود کار می کند، اتخاذ خواهیم کرد. برای تکمیل این مرحله هیچ اقدامی از طرف شما لازم نیست. با این حال، شما باید هر گونه مشکلی را به Apigee گزارش دهید، و ما قبل از ادامه مرحله 3 برای حل مشکلات با شما همکاری خواهیم کرد.

مرحله 3 - لایه متعادل کننده بار را در محیط های تولیدی بردارید

پس از تکمیل موفقیت‌آمیز مرحله 2، مجموعه‌ای از پنجره‌های تعمیر و نگهداری را برای حذف لایه متعادل‌کننده بار در محیط(های) تولید با استفاده از همان رویکرد ذکر شده در مرحله 2 تعیین می‌کنیم تا اطمینان حاصل کنیم که ترافیک API در زمان اجرا همانطور که انتظار می‌رود کار می‌کند.

تغییرات در عملکرد محصول

در اینجا برخی از تغییرات در عملکرد محصول با سوئیچ به NGINX آورده شده است.

منسوخ شده است

ویژگی‌های زیر دیگر در ProxyEndpoints پشتیبانی نمی‌شوند:

  • اجازه دهید.http10
  • اجازه دهید.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 های ارائه دهنده ترافیک را تغییر نمی دهد. با این حال، با توجه به ماهیت سرویس متعادل کننده بار سرویس های وب آمازون (AWS)، قوانین مقیاس بندی معمولی اعمال می شود، به این معنی که IP ها ممکن است به عنوان بخشی از منطق مقیاس بندی آن (عملکرد موجود) تغییر کنند. به همین دلیل است که ما اجرای تنظیمات فهرست مجاز Northbound را با مجموعه محصول Apigee Edge توصیه نمی کنیم. در طی مراحل 2 و 3، پیامدهای لیست مجاز با حذف متعادل کننده بار و آدرس های IP مرتبط با آن وجود دارد. در نتیجه، ما در طی این مراحل از نزدیک با شما هماهنگ می‌کنیم تا با ارائه مجموعه‌ای از آدرس‌های IP جدید که امکان دسترسی به آن‌ها را فراهم می‌کند، انتقال همواری را تضمین کنیم.
آیا این بر محدودیت های IP که در سرورهای اصلی خود داریم تأثیر می گذارد؟
هیچ تغییری لازم نیست، با فرض اینکه سرورهای مبدا سرورهای نقطه پایانی هدف هستند (سرورهایی که از بسته پروکسی فراخوانی می شوند). این تغییر در سمت شمال Apigee یا نقطه ورود به Apigee است.
آیا CNAME موجود ما نیاز به تغییر دارد؟
خیر. ورودی های CNAME موجود همانطور که انتظار می رود به کار خود ادامه می دهند.
انتقال گواهی SSL دردناک خواهد بود. چگونه می خواهید با این موضوع کنار بیایید؟
اگر از SSL استفاده می کنید، مرحله اولیه بر پیکربندی SSL موجود تأثیری نخواهد داشت. با این حال، قبل از ادامه مراحل 2 و 3، باید از نزدیک با شما هماهنگ کنیم تا مطمئن شویم SSL به درستی در روتر جدید تنظیم شده است.
اگر برنامه/کلینت من از SNI پشتیبانی نکند چه؟
مراحل 2 و 3 تا تایید پشتیبانی SNI به تعویق خواهد افتاد.
آیا توقفی وجود خواهد داشت؟
ما انتظار هیچ گونه خرابی نداریم. تغییرات با استفاده از مدل استقرار استاندارد ما در طول پنجره‌های انتشار موجود ما اجرا می‌شوند.