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

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

במהלך אוגוסט וספטמבר 2015, אנחנו מעבירים את נתבי הענן ואת מאזני העומסים של Apigee Edge אל NGINX (מבטאים "אנג'ין אקס"). ‫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

כדי לעקוף את ההוצאה משימוש הזו, אפשר לעיין במאמר הקהילה הבא: מאפייני שיטת ההיתר של HTTP בנקודת קצה של שרת proxy לא פועלים.

שאלות נפוצות

ריכזנו כאן תשובות לכמה שאלות נפוצות בנושא המעבר ל-NGINX.

האם יש סיכוי שכתובות ה-IP הציבוריות ישתנו? חלק מהמוכרים שלנו מאפשרים גישה רק מכתובות ה-IP המוכרות, וכשהם משנים את כתובות ה-IP, התהליך של המוכרים נקטע.
במהלך שלב 1, התשובה היא 'לא' כי אנחנו לא נוגעים במאזני העומסים הקיימים, ולכן לא יחול שינוי ישיר באף אחת מכתובות ה-IP שמשרתות את התנועה. עם זאת, בהתחשב באופי של שירות איזון העומסים של Amazon Web Services‏ (AWS), חלים כללי קנה מידה רגילים, כלומר כתובות ה-IP עשויות להשתנות כחלק מהלוגיקה של שינוי קנה המידה (פונקציונליות קיימת). לכן, אנחנו לא ממליצים להטמיע הגדרות של רשימת היתרים צפונית עם חבילת המוצרים Apigee Edge. במהלך שלבים 2 ו-3, יש השלכות על רשימת ההיתרים בעקבות ההסרה של מאזן העומסים וכתובות ה-IP המשויכות אליו. לכן, נתאם איתכם באופן הדוק במהלך השלבים האלה כדי להבטיח מעבר חלק. לשם כך, נספק קבוצה חדשה של כתובות IP שצריך לאפשר להן גישה.
האם השינוי הזה ישפיע על הגבלות ה-IP שהגדרנו בשרתי המקור שלנו?
לא נדרשים שינויים, בהנחה ששרתי המקור הם שרתי נקודות הקצה של היעד (שרתים שמתבצעת אליהם קריאה מחבילת ה-proxy). השינוי הזה מתבצע בצד הצפוני של Apigee או בנקודת הכניסה (ingress) ל-Apigee.
האם יהיה צורך לשנות את רשומת ה-CNAME הקיימת?
לא. רשומות CNAME קיימות ימשיכו לפעול כצפוי.
העברת אישור SSL תהיה מסובכת. איך תטפל בזה?
אם אתם משתמשים ב-SSL, השלב הראשוני לא ישפיע על הגדרת ה-SSL הקיימת. עם זאת, נצטרך לתאם איתך באופן הדוק כדי לוודא ש-SSL מוגדר בצורה תקינה בנתב החדש לפני שנמשיך לשלבים 2 ו-3.
מה קורה אם האפליקציה או הלקוח שלי לא תומכים ב-SNI?
השלבים 2 ו-3 יתעכבו עד לאישור התמיכה ב-SNI.
האם תהיה השבתה כלשהי?
לא צפויים זמני השבתה. השינויים יוטמעו באמצעות מודל הפריסה הרגיל שלנו במהלך חלונות ההפצה הקיימים.