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

אתם צופים במסמכי העזרה של Apigee Edge.
כניסה למסמכי העזרה של Apigee X.
info

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

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

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

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