העברה לנתבי NGINX ולמאזני עומסים

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X.
מידע

במהלך אוגוסט וספטמבר 2015, נעביר את הנתבים ומאזן העומסים שלנו לענן של Apigee Edge אל NGINX (שנקראה בעבר "Engine X"). NGINX, שרת אינטרנט בקוד פתוח, מספק ביצועים טובים עוד יותר ובו-זמניות גבוה יותר מאשר מאזני העומסים והנתבים הקיימים שלנו.

מה המשמעות מבחינת לקוחות הענן שלנו

השורה התחתונה היא שהשינוי הזה צריך להיות שקוף, ולא נדרשת שום פעולה מצידכם, חוץ מאשר לאמת שהמערכות שלכם עובדות כצפוי. בהמשך מופיעים תיאורים של הצעדים שננקוט וגם תשובות לכמה שאלות נפוצות.

שלב 1 – עדכון תוכנה

אנחנו נשדרג את כל הנתבים לנתב החדש שמבוסס על NGINX. אנחנו ננצל את מודל הפריסה ההדרגתית כדי לוודא שהשירותים לא יושפעו מהפעילות הזאת.

שלב 2 – מסירים את רמת מאזן העומסים בסביבות ללא ייצור

נתב NGINX החדש מטפל בפונקציונליות של איזון העומסים, וקודם כל נתחיל בתהליך של הסרת הרמה הקיימת של מאזן העומסים בסביבה ללא ייצור. מאזני העומסים בסביבת הייצור יישארו כפי שהם ולא ישתנו במהלך השלב הזה. לפני ההסרה של מאזני העומסים הקיימים, ננקוט גישה מקיפה כדי לוודא שתעבורת הנתונים פועלת כצפוי. לא נדרשת כל פעולה מצידכם כדי להשלים את השלב הזה. עם זאת, עליכם לדווח על כל בעיה ל-Apigee, ואנחנו נעבוד איתכם כדי לפתור אותן לפני שנמשיך בשלב 3.

שלב 3 – הסרה של רמת מאזן העומסים בסביבות ייצור

אחרי שתשלימו בהצלחה את שלב 2, נקבע מספר חלונות תחזוקה להסרת שכבת מאזן העומסים בסביבות הייצור באמצעות אותה הגישה שהוזכרה בשלב 2, כדי להבטיח שהתנועה של API בזמן הריצה תמשיך לפעול כצפוי.

שינויים בפונקציונליות של המוצר

ריכזנו כאן כמה שינויים בפונקציונליות של המוצר אחרי המעבר ל-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 יוסרו מאזן העומסים וכתובות ה-IP שמשויכות אליו ויהיו השלכות ברשימת ההיתרים. כתוצאה מכך, אנחנו נתאם איתכם קשר במהלך השלבים האלה כדי להבטיח שהמעבר יהיה חלק, על ידי מתן קבוצה חדשה של כתובות IP שאפשר לגשת אליהן.
האם זה ישפיע על ההגבלות לכתובות IP שחלות על שרתי המקור שלנו?
לא נדרשים שינויים, בהנחה ששרתי המקור הם שרתי היעד של נקודת הקצה (שרתים שנקראו מתוך חבילת שרת ה-proxy). השינוי הזה נמצא בצד הצפון של Apigee או בנקודת תעבורת הנתונים הנכנסת אל Apigee.
האם יידרש שינוי ב-CNAME הקיים?
לא. רשומות CNAME קיימות ימשיכו לפעול כצפוי.
העברת אישורי SSL תהיה מכאיבה. איך תטפל בזה?
אם משתמשים ב-SSL, השלב הראשוני לא ישפיע על תצורת ה-SSL הקיימת. עם זאת, נצטרך לתאם איתך פעולה כדי לוודא ש-SSL מוגדר כראוי בנתב החדש לפני שנמשיך בשלבים 2 ו-3.
מה קורה אם האפליקציה/הלקוח לא תומכים ב-SNI?
שלבים 2 ו-3 יימשכו עד שהתמיכה ב-SNI תאושר.
האם יהיה זמן השבתה?
אנחנו לא צופים זמן השבתה. השינויים ייושמו באמצעות מודל הפריסה הרגיל שלנו במהלך חלונות הגרסאות הקיימים.