עדכון של Apigee Edge 4.51.00 או 4.52.00 או 4.52.01 ל-4.52.02

ב-Apigee יש תמיכה בשדרוג של Edge for Private Cloud ישירות מגרסה 4.51.00,‏ 4.52.00 או 4.52.01 לגרסה 4.52.02. בדף הזה נסביר איך לבצע שדרוגים כאלה.

מי יכול לבצע את העדכון

האדם שמפעיל את העדכון צריך להיות זהה לאדם שהתקין את Edge במקור, או אדם שמפעיל את העדכון בתור root.

אחרי שתתקינו את ה-RPM של Edge, כל אחד יוכל להגדיר אותם.

אילו רכיבים צריך לעדכן

צריך לעדכן את כל הרכיבים של Edge. ב-Edge אין תמיכה בהגדרה שמכילה רכיבים מכמה גרסאות.

עדכון התנאים המוקדמים

לפני שמשדרגים את Apigee Edge, צריך לוודא את הדרישות המוקדמות הבאות:

  • גיבוי של כל הצמתים
    מטעמי בטיחות, מומלץ לבצע גיבוי מלא של כל הצמתים לפני שמבצעים את העדכון. כדי לבצע את הגיבוי, פועלים לפי השלבים המתאימים לגרסה הנוכחית של Edge.

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

  • מוודאים ש-Edge פועל
    מוודאים ש-Edge פועל במהלך תהליך העדכון באמצעות הפקודה: 
    /opt/apigee/apigee-service/bin/apigee-all status
  • מוודאים ש-Cassandra Compaction Strategy היא LeveledCompactionStrategy
    בהתאם לגרסה הנוכחית, מבצעים את השינויים הנדרשים בשיטת הדחיסה של Cassandra. פועלים לפי השלבים הבאים ולאחר מכן חוזרים לתהליך השדרוג הראשי:

אילו שלבים מיוחדים כדאי להביא בחשבון במהלך השדרוג

כדי לשדרג ל-Edge for Private Cloud 4.52.02, מומלץ לבצע שלבים ספציפיים לשדרוג תוכנות מסוימות. השלבים הנדרשים משתנים בהתאם לגרסה הנוכחית שלכם. בטבלה שבהמשך מפורטות תוכנות שונות שצריך לבצע בהן שלבים נוספים, ופירוט ההוראות לכל אחת מהן. אחרי השלמת המשימות הנדרשות, חוזרים לתהליך השדרוג הראשי כדי להמשיך בתהליך השדרוג.

גרסה נוכחית תוכנות שצריך לבצע שלבים מיוחדים כדי לשדרג אותן לגרסה 4.52.02
4.52.01 Cassandra
4.52.00 Zookeeper, ‏ Cassandra, ‏ Qpid
4.51.00 Zookeeper, ‏ Postgres, ‏ Cassandra, ‏ Qpid

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

העברה אוטומטית של הגדרות הנכס

אם הגדרתם מאפיינים כלשהם על ידי עריכת קבצים מסוג .properties ב-/opt/apigee/customer/application, הערכים האלה יישמרו אחרי העדכון.

שדרוג ל-Zookeeper 3.8.3

Edge for Private Cloud 4.52.02 לא כולל שדרוג של Zookeeper. עם זאת, אם אתם משדרגים מגרסה ישנה יותר מ-4.52.01, עליכם לפעול לפי השלבים לשדרוג של Zookeeper שמפורטים בהמשך.

  • אם אתם משדרגים מ-Edge for Private Cloud בגרסאות 4.51.00 או 4.52.00, עליכם לפעול לפי השלבים שמפורטים במאמר הדרישה לשדרוג ל-Zookeeper 3.8.3 כדי לשדרג את Zookeeper.
  • אם אתם משדרגים מ-Edge for Private Cloud בגרסה 4.52.01, אתם כבר אמורים להשתמש ב-Zookeeper בגרסה 3.8.3, ואין צורך לבצע שלבים מיוחדים לשדרוג של Zookeeper.

שדרוג ל-Postgres 14

  • אם משדרגים מ-Edge for Private Cloud 4.51.00 ל-4.52.02, צריך לפעול לפי השלבים לשדרוג Postgres, למרות ש-Edge for Private Cloud 4.52.02 לא כולל שדרוג של Postgres. כדי לשדרג מ-Edge for Private Cloud 4.51.00 ל-4.52.02, נדרשים שלבים נוספים לשדרוג של Postgres. אפשר לעיין בקטע שדרוג נדרש ל-Postgres 14.
  • אם משדרגים מ-Edge for Private Cloud 4.52.00 או 4.52.01 ל-4.52.02, אין צורך לבצע שלבי שדרוג נוספים של Postgres.

שדרוג ל-Cassandra 3.11.16

הגרסה 4.52.02 של Apigee Edge for Private Cloud כוללת שדרוג של Cassandra לגרסה 3.11.16. Cassandra הוא רכיב קריטי ב-Apigee, והשדרוג הזה כולל גם עדכונים לתוכנת הנהג ברכיבי ניהול וזמן ריצה שונים שמשמשים לשליחת שאילתות ולכתיבה ב-Cassandra.

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

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

פורטל המפתחים – תיעוד ממשקי API

בפורטל למפתחים של Apigee Drupal יש תכונות שונות לתיעוד ממשקי ה-API. מומלץ להפסיק להשתמש בפורטל למפתחים שמבוסס על Drupal 7, אבל אם אתם עדיין משתמשים בו ומנצלים את התכונה SmartDocs, המסמך שימוש בממשקי ה-API של SmartDocs רלוונטי לכם. אם אתם משתמשים בגרסאות חדשות יותר של פורטל המפתחים, לא תהיה השפעה על מסמכי התיעוד של ה-API במהלך השדרוג.

כשמשדרגים את Apigee לגרסה 4.52.02, מודלים של ממשקי API שנוצרו באמצעות התכונה SmartDocs בפורטל למפתחים של Drupal 7 לא מועברים לגרסה החדשה באופן אוטומטי. עליכם לייצא באופן ידני כל מודל באמצעות פורטל המפתחים ולייבא אותו שוב אחרי השלמת השדרוג.

המונחים שבשימוש בהמשך

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

ניהול: ניהול כולל את האדמין של מערכת Apigee Edge. הפעולות האלה כוללות, בין היתר, פריסות, שינויים באפליקציות, במוצרים, בשרתים ייעודיים, במאגרי מפתחות וכו'. כל ממשקי ה-API לניהול (והלקוחות שלהם, כמו ממשק המשתמש של Apigee ופורטל המפתחים) נכללים בהיקף הזה.

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

בכל שלב בהמשך מתואר המצב של סביבת זמן הריצה והניהול במהלך השלבים השונים של תהליך השדרוג.

שדרוג אסטרטגיות

כמה מרכזי נתונים

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

מרכז נתונים יחיד

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

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

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

  • ממשקי API בסביבת זמן ריצה שמריצים רענון של טוקני OAuth
  • ממשקי API בסביבת זמן ריצה באמצעות מדיניות של ישות גישה
  • ממשקי API לניהול שמציגים אפליקציות למפתחים
  • ממשקי API לניהול של מוצרי הרשימה

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

ביטול שינויים – רמה גבוהה

  • ההשפעה במהלך החזרה למצב הקודם

    חזרה לאחור מ-Cassandra 3.11.x ל-2.1.x משפיעה גם על תעבורת הנתונים בסביבת זמן הריצה וגם על תעבורת הנתונים לניהול בתוך מרכז הנתונים (DC) שבו מתבצעת החזרה לאחור. בנוסף, יכול להיות שיהיו שיבושים בממשקי API מסוימים לניהול בכל מרכזי הנתונים, ללא קשר למרכז הנתונים שבו מתבצע החזרה לאחור.

  • שימוש בגישה של ביטול שינויים ב-DC לפי DC

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

  • החזרה לאחור של אשכולות ששודרגו חלקית

    אם מרכז נתונים אחד לפחות ממשיך לפעול באופן מלא בגרסה הישנה יותר של Cassandra‏ (2.1.22), אפשר לבצע חזרה לגרסה הקודמת של מרכזי נתונים משודרגים אחרים על ידי ביצוע בנייה מחדש ממרכז הנתונים של Cassandra 2.1.X שפועל באופן מלא.

  • החזרה לאחור ברמת האשכול

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

  • שיקולים לפני השדרוג

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

ביטול שינויים באשכולות עם מרכז נתונים יחיד

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

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

אם אין אפשרות להוסיף מרכז נתונים חדש אבל עדיין נדרשת יכולת חזרה לאחור, חשוב לוודא שמתבצעים גיבויים מהימנים לפני השדרוג. אפשר לשחזר את Cassandra 2.1.x מגיבויים, אבל הגישה הזו עשויה לגרום לזמן השבתה של השירות ולאובדן נתונים פוטנציאלי.

ביטול שינויים באשכול עם כמה מרכזי נתונים

החזרה לאחור של מספר מרכזי נתונים מתבצעת לפי גישה של מרכז נתונים אחר מרכז נתונים (DC-by-DC). בגישה הזו, התנועה ממרכז הנתונים שבו מתבצע החזרה לאחור מנותבת למרכזי נתונים פונקציונליים אחרים, כדי להבטיח תהליך מבודד ומבוקר של החזרה לאחור ב-Cassandra, ב-Management Server וב-Runtime nodes, וכך למנוע שיבושים בתעבורת הנתונים.

פרטים נוספים זמינים בקטע החזרה לאחור של עדכון Cassandra 3.11.16.

שלב 0: מצב ההתחלה

  • הרכיבים של Zookeeper, ‏ Postgres ו-LDAP כבר שודרגו לגרסה 4.52.02. האשכולות של Edge לענן פרטי יציבים ועובדים. אם תהיה צורך בחזרה לגרסה הקודמת, האשכולות יחזרו למצב הזה.
  • Cassandra ב-Apigee פועלת בגרסה 2.1.22.
  • רכיבי קצה:
    • שרת ניהול שמתקשר עם Cassandra באמצעות פרוטוקול thrift ישן יותר.
    • שרתי זמן ריצה (מעבדי הודעות ונתבים) שמתקשרים עם Cassandra דרך פרוטוקול thrift ישן יותר.
מצב זמן הריצה בשלב הזה סטטוס הניהול בשלב הזה
זמן ריצה פעיל במלואו הניהול פועל במלואו

שלב 1: הכנה לשדרוג

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

  1. שינוי Cassandra כך שתשתמש ב-LeveledCompactionStrategy.
  2. גיבוי של Cassandra באמצעות Apigee
  3. יוצרים קובצי snapshot של צמתים של Cassandra ב-VM (אם אפשר).
  4. יוצרים קובץ תצורה לשדרוג של Cassandra בכל צומת של Cassandra ב-/opt/apigee/apigee-cassandra/cass_upgrade.conf עם התוכן הבא: 
    # IP Address of node
HOSTIP=10.0.0.1

# Username for running Cassandra queries. Optional. Can be skipped if you have not enabled Cassandra authentication.
CASS_USERNAME=<cassuser>

# Password for running Cassandra queries. Optional. Can be skipped if you have not enabled Cassandra authentication.
CASS_PASSWORD=<casspass>

# Port for connecting to Cassandra via thrift. Optional. Defaults to 9160 if skipped.
CASS_PORT=9160

# Port for connecting to Cassandra via CQL. Optional. Defaults to 9042 if skipped.
CASS_CQL_PORT=9042

# Directory to be used by Cassandra upgrade scripts. Optional. Defaults to /tmp/cass_upgrade_scripts if skipped.
# Note that if upgrade is successful, this directory is deleted via root user - so provide a directory accordingly.
CASS_TMP_DIR=/tmp/cass_upgrade_scripts
    אם לא ניתן ליצור את הקובץ ב-/opt/apigee/apigee-cassandra/cass_upgrade.conf, יוצרים את הקובץ /opt/silent.conf עם אותו תוכן בכל צומת של Cassandra.
  5. אם אתם משתמשים בתכונה SmartDocs של פורטל הפיתוח של Apigee Drupal 7, יוצאים כל אחד מהמודלים על ידי הורדה שלהם בפורמט JSON מממשק המשתמש של פורטל הפיתוח. אחרי העדכון של שרתי הניהול, צריך לייבא את המודלים האלה בחזרה ל-Apigee.
  6. אם עוד לא עשיתם זאת, עליכם לוודא שאפשר לגשת ליציאות 9160 ו-9042 מכל רכיבי Edge לצמתים של Cassandra. מידע נוסף זמין במאמר דרישות לגבי יציאות.

שלב 2: מפנים את התנועה מחוץ למרכז הנתונים הראשון

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

שלב 3: משדרגים את כל צמתים של Cassandra במרכז הנתונים הראשון

  1. משדרגים את כל צמתים של Cassandra במרכז הנתונים, אחד אחרי השני. מריצים את הפקודות הבאות בכל צומת בנפרד: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
  2. אחרי שמעדכנים צומת, מריצים את הפקודה הבאה בצומת כדי להריץ כמה בדיקות אימות לפני שממשיכים: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra validate_upgrade -f configFile
     הקוד שלמעלה יניב פלט שנראה בערך כך: 
    Cassandra version is verified - [cqlsh 5.0.1 | Cassandra 3.11.16 | CQL spec 3.4.4 | Native protocol v3] Metadata is verified
  3. אחרי שהשדרוג מסתיים, מריצים את הפקודה post_upgrade בכל צומת של Cassandra בנפרד: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade
מצב זמן הריצה בשלב הזה סטטוס הניהול בשלב הזה
  • תנועה בזמן ריצה חסומה במרכזי נתונים שעוברים שדרוג
  • זמן ריצה פונקציונלי במלואו במרכזי נתונים אחרים

שלב 4: שדרוג כל צמתים הניהול במרכז הנתונים הראשון

משדרגים את כל צמתים הניהול במרכז הנתונים:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
מצב זמן הריצה בשלב הזה סטטוס הניהול בשלב הזה
  • תנועה בזמן ריצה חסומה במרכזי נתונים שעוברים שדרוג
  • זמן ריצה פעיל במלואו

שלב 5: משדרגים את כל צמתים בסביבת זמן הריצה במרכז הנתונים הראשון

משדרגים את כל צמתי הנתב ומעבד ההודעות במרכז הנתונים, אחד אחרי השני:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
מצב זמן הריצה בשלב הזה סטטוס הניהול בשלב הזה
  • תנועה בזמן ריצה חסומה במרכזי נתונים שעוברים שדרוג
  • זמן ריצה פונקציונלי במלואו במרכזי נתונים אחרים

שלב 6: מפנים את התנועה חזרה למרכז הנתונים הראשון

  • אחרי שמשדרגים את מרכז הנתונים הראשון עם Cassandra, רכיבי זמן ריצה ושרת ניהול, מפעילים מחדש את תעבורת זמן הריצה והניהול למרכז הנתונים הראשון.
  • מוודאים שתנועת זמן הריצה והניהול מתבצעת בהצלחה בין מרכזי הנתונים.

שלב 7: שדרוג של מרכזי נתונים אחרים

חוזרים על שלב 1 עד שלב 6 במרכזי הנתונים הנותרים, אחד אחרי השני, על ידי הפניה אוטומטית של תעבורת הנתונים הרחק ממרכזי הנתונים האלה, עדכון תוכנת Apigee והפעלה מחדש של תעבורת הנתונים במרכזי הנתונים האלה.

שלב 8: מפעילים מחדש את שלב השדרוג בכל צמתים הניהול

מריצים מחדש את פקודת השדרוג הבאה בכל צמתים הניהול במרכזי הנתונים:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

שלב 9 – [אופציונלי] מייבאים מסמכים חכמים שיוצאו בעבר

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

צריך לעשות זאת רק אם אתם משתמשים בפורטל למפתחים שמבוסס על Drupal 7 ומשתמשים בתכונה smartdocs.

מצב זמן הריצה בשלב הזה סטטוס הניהול בשלב הזה
זמן ריצה פעיל במלואו הניהול פועל במלואו

שלב 10 – השמטת טבלאות שלא בשימוש

מריצים את הפקודה הבאה כדי להסיר מאשכול Cassandra טבלאות ישנות שלא בשימוש. עד להרצה של הפקודה הזו, לא תוכלו להשתמש בתכונות מסוימות של Cassandra (למשל, הגדרת אימות חדש – מנגנוני האימות הישנים ימשיכו לפעול). אפשר להריץ את הפקודה הזו רק בצומת אחד באשכול

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra drop_old_tables -f configFile

שלב 11 – שדרוג כל שאר הרכיבים של Edge ורכיבים אחרים ל-Private Cloud 4.52.02

משדרגים את כל שאר הצמתים מסוג edge-qpid-server ו-edge-postgres-server בכל האזורים, אחד אחרי השני.

בשלב הזה, אם אתם משדרגים מגרסאות ישנות יותר מ-Edge for Private Cloud 4.52.01, עליכם לבצע את השלבים הבאים כדי לשדרג את Qpid ו-Postgres בהתאמה, ולשדרג את שאר הרכיבים לפי השלבים האלה.

שדרוג ל-Qpid J-Broker

למרות שגרסה 4.52.02 של Edge for Private Cloud לא כוללת שדרוג ל-Qpid, אם אתם משדרגים מגרסאות ישנות יותר מ-4.52.01, עליכם לפעול לפי השלבים לשדרוג QPID.

  • אם משדרגים מ-Edge for Private Cloud 4.51.00 או 4.52.00 ל-4.52.02, צריך לבצע שלבים נוספים לשדרוג של Qpid. אם אתם משדרגים מגרסה 4.51.00 או 4.52.00 לגרסה 4.52.02, יש לעיין בקטע שדרוג Qpid.
  • אם אתם משדרגים מ-Edge for Private Cloud 4.52.01 ל-4.52.02, כבר אמורה להיות לכם גרסה עדכנית של Qpid Broker, ואין צורך לבצע שלבים נוספים של Qpidupgrade.

ממשק המשתמש החדש של Edge

בקטע הזה מפורטים שיקולים לגבי ממשק המשתמש של Edge. מידע נוסף זמין במאמר ממשק המשתמש החדש של Edge לענן פרטי.

התקנת ממשק המשתמש של Edge

אחרי השלמת ההתקנה הראשונית, מומלץ להתקין את ממשק המשתמש של Edge, שהוא ממשק משתמש משופר למפתחים ולמנהלים של Apigee Edge לענן פרטי.

חשוב לזכור שבממשק המשתמש של Edge צריך להשבית את האימות הבסיסי ולהשתמש ב-IDP כמו SAML או LDAP.

מידע נוסף זמין במאמר התקנה של ממשק המשתמש החדש של Edge.

עדכון ממשק המשתמש של Edge

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

עדכון באמצעות Apigee mTLS

כדי לעדכן את Apigee mTLS:

ביטול עדכון

אם העדכון נכשל, אפשר לנסות לתקן את הבעיה ואז להריץ שוב את update.sh. אפשר להריץ את העדכון כמה פעמים, והוא ימשיך מהנקודה שבה הפסיק בפעם האחרונה.

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

רישום ביומן של פרטי העדכון

כברירת מחדל, הכלי update.sh כותב את פרטי היומן אל:

/opt/apigee/var/log/apigee-setup/update.log

אם למשתמש שמפעיל את השירות update.sh אין גישה לספרייה הזו, יופיע יומן בספרייה /tmp בתור קובץ בשם update_username.log.

אם אין לכם גישה ל-/tmp, השירות update.sh ייכשל.

עדכון ללא זמן השבתה

עדכון ללא זמן השבתה, או עדכון מתגלגל, מאפשר לכם לעדכן את התקנת Edge בלי להשבית את Edge.

עדכון ללא זמן השבתה אפשרי רק עם הגדרה של 5 צמתים ומעלה.

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

  1. מעדכנים את המכונות בסדר הנכון להתקנה, כפי שמתואר בקטע סדר העדכון של המכונות.
  2. כשמגיע הזמן לעדכן את הנתב, בוחרים נתב כלשהו ומוודאים שהוא לא נגיש, כפי שמתואר בקטע הפעלה/השבתה של נגישות השרת (מעבד ההודעות/הנתב).
  3. מעדכנים את הנתב שנבחר ואת כל שאר רכיבי Edge באותה מכונה שבה נמצא הנתב. בכל הגדרות Edge מוצגים נתב ומעבד הודעות באותו צומת.
  4. מאפשרים גישה מחדש לנתב.
  5. חוזרים על שלבים 2 עד 4 בשאר הנתבים.
  6. ממשיכים את העדכון בכל המכונות הנותרות בהתקנה.

לפני ואחרי העדכון, חשוב לבצע את הפעולות הבאות:

שימוש בקובץ תצורה ללא הודעות

צריך להעביר קובץ תצורה ללא תגובה לפקודת העדכון. קובץ התצורה להתקנה שקטה צריך להיות זהה לקובץ שבו השתמשתם כדי להתקין את Edge 4.50.00 או 4.51.00.

עדכון לגרסה 4.52.02 בצומת עם חיבור חיצוני לאינטרנט

כדי לעדכן את רכיבי Edge בצומת, מבצעים את השלבים הבאים:

  1. אם יש כאלה, משביתים את כל משימות cron שמוגדרות לבצע פעולת תיקון ב-Cassandra עד לסיום העדכון.
  2. מתחברים לצומת בתור root כדי להתקין את קובצי ה-RPM של Edge.
  3. מתקינים את yum-utils ואת yum-plugin-priorities: 
    sudo yum install yum-utils
sudo yum install yum-plugin-priorities
  4. משביתים את SELinux כפי שמתואר במאמר התקנת הכלי apigee-setup ב-Edge.
  5. אם מתקינים ב-Oracle 7.x, מריצים את הפקודה הבאה: 
    sudo yum-config-manager --enable ol7_optional_latest
  6. אם מתקינים ב-AWS, מריצים את הפקודות הבאות ב-yum-configure-manager: 
    yum update rh-amazon-rhui-client.noarch
sudo yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

  7. אם אתם משתמשים כרגע ב-Edge 4.51.00:

    1. מורידים את הקובץ bootstrap_4.52.02.sh של Edge אל /tmp/bootstrap_4.52.02.sh: 
      curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh
    2. כדי להתקין את השירות apigee-service ואת יחסי התלות של Edge 4.52.02, מריצים את הפקודה הבאה: 
      sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

      כאשר uName:pWord הם שם המשתמש והסיסמה שקיבלת מ-Apigee. אם pWord לא יצוין, תופיע בקשה להזין אותו.

      כברירת מחדל, מנהל ההתקנה בודק אם Java 1.8 מותקנת. אם לא תעשו זאת, מנהל ההתקנה יטפל בזה בשבילכם.

      אפשר להשתמש באפשרות JAVA_FIX כדי לציין איך לטפל בהתקנה של Java. הערכים האפשריים של JAVA_FIX הם:

      • I: התקנה של OpenJDK 1.8 (ברירת המחדל).
      • C: המשך ללא התקנת Java.
      • Q: יציאה. כדי להשתמש באפשרות הזו, צריך להתקין את Java בעצמכם.
    3. משתמשים בפקודה apigee-service כדי לעדכן את השירות apigee-setup, כפי שמתואר בדוגמה הבאה: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-setup update
    4. מעדכנים את השירות apigee-validate בשרת הניהול, כפי שמתואר בדוגמה הבאה: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-validate update
    5. מעדכנים את השירות apigee-provision בשרת הניהול, כפי שמתואר בדוגמה הבאה: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-provision update
    6. מריצים את הכלי update בצמתים באמצעות הפקודה הבאה: 
      /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

      מבצעים זאת לפי הסדר שמתואר בקטע סדר העדכון של המכונה.

      כאשר:

      • component הוא רכיב Edge שרוצים לעדכן. הערכים האפשריים כוללים:
        • cs: Cassandra
        • edge: כל רכיבי Edge מלבד ממשק המשתמש של Edge: שרת ניהול, מעבד הודעות, נתב, שרת Qpid, שרת Postgres
        • ldap: OpenLDAP
        • ps: postgresql
        • qpid: qpidd
        • sso: Apigee SSO (אם התקנתם SSO)
        • ue: ממשק המשתמש החדש של Edge
        • ui: ממשק המשתמש הקלאסי של Edge
        • zk: Zookeeper
      • configFile הוא אותו קובץ תצורה שבו השתמשתם כדי להגדיר את הרכיבים של Edge במהלך ההתקנה של גרסת 4.50.00 או 4.51.00.

      אפשר להריץ את update.sh לכל הרכיבים על ידי הגדרת component ל-'all', אבל רק אם יש לכם פרופיל התקנה של Edge all-in-one (AIO). לדוגמה:

      /opt/apigee/apigee-setup/bin/update.sh -c all -f ./sa_silent_config
    7. מפעילים מחדש את רכיבי ממשק המשתמש של Edge בכל הצמתים שבהם הם פועלים, אם עדיין לא עשיתם זאת: 
      /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
    8. בודקים את העדכון על ידי הפעלת הכלי apigee-validate בשרת הניהול, כפי שמתואר בקטע בדיקת ההתקנה.

אם תחליטו לחזור לגרסה הקודמת של העדכון, תוכלו להיעזר בהוראות להחזרת הגרסה הקודמת 4.52.02.

עדכון לגרסה 4.52.02 ממאגר מקומי

אם צמתים של Edge נמצאים מאחורי חומת אש, או שאין להם גישה למאגר Apigee דרך האינטרנט מסיבה אחרת, אפשר לבצע את העדכון ממאגר מקומי או ממראה של מאגר Apigee.#heading

אחרי שיוצרים מאגר מקומי של Edge, יש שתי אפשרויות לעדכון Edge מהמאגר המקומי:

  • יוצרים קובץ ‎ .tar של המאגר, מעתיקים את קובץ ה-‎ .tar לצומת ומעדכנים את Edge מהקובץ ‎.tar.
  • מתקינים שרת אינטרנט בצומת עם המאגר המקומי כדי שצמתים אחרים יוכלו לגשת אליו. Apigee מספקת את שרת האינטרנט Nginx לשימוש, או שאפשר להשתמש בשרת אינטרנט משלכם.

כדי לעדכן ממאגר מקומי של 4.52.02:

  1. יוצרים מאגר מקומי של 4.52.02 כפי שמתואר בקטע 'יצירת מאגר מקומי של Apigee' במאמר התקנת הכלי apigee-setup של Edge.
  2. כדי להתקין את apigee-service מקובץ ‎ .tar:
    1. בצומת שבו נמצא המאגר המקומי, משתמשים בפקודה הבאה כדי לארוז את המאגר המקומי בקובץ ‎ .tar אחד בשם /opt/apigee/data/apigee-mirror/apigee-4.52.02.tar.gz: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
    2. מעתיקים את קובץ ה-tar .‎ לצומת שבו רוצים לעדכן את Edge. לדוגמה, מעתיקים אותו לספרייה /tmp בצומת החדש.
    3. בצומת החדש, מפרקים את הקובץ לספרייה /tmp: 
      tar -xzf apigee-4.52.02.tar.gz

      הפקודה הזו יוצרת ספרייה חדשה בשם repos בספרייה שמכילה את הקובץ ‎ .tar. לדוגמה /tmp/repos.

    4. מתקינים את השירות apigee-service ואת יחסי התלות שלו ב-Edge מ-/tmp/repos: 
      sudo bash /tmp/repos/bootstrap_4.52.02.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos

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

  3. כדי להתקין את apigee-service באמצעות שרת האינטרנט Nginx:
    1. מגדירים את שרת האינטרנט Nginx כפי שמתואר בקטע 'התקנה מהמאגר באמצעות שרת האינטרנט Nginx' במאמר התקנה של הכלי apigee-setup ל-Edge.
    2. בצומת המרוחק, מורידים את הקובץ bootstrap_4.52.02.sh של Edge אל /tmp/bootstrap_4.52.02.sh: 
      /usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh

      כאשר uName:pWord הם שם המשתמש והסיסמה שהגדרתם בעבר למאגר, ו-remoteRepo היא כתובת ה-IP או שם ה-DNS של צומת המאגר.

    3. בצומת המרוחק, מתקינים את הכלי apigee-setup של Edge ואת יחסי התלות: 
      sudo bash /tmp/bootstrap_4.52.02.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://

      כאשר uName:pWord הם שם המשתמש והסיסמה של המאגר.

  4. משתמשים בפקודה apigee-service כדי לעדכן את השירות apigee-setup, כפי שמתואר בדוגמה הבאה: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup update
  5. מעדכנים את השירות apigee-validate בשרת הניהול, כפי שמתואר בדוגמה הבאה: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-validate update
  6. מעדכנים את השירות apigee-provision בשרת הניהול, כפי שמתואר בדוגמה הבאה: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-provision update
  7. מריצים את הכלי update בצמתים לפי הסדר שמתואר בקטע סדר העדכון של המכונות: 
    /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

    כאשר:

    • component הוא רכיב Edge שרוצים לעדכן. בדרך כלל מעדכנים את הרכיבים הבאים:
      • cs: Cassandra
      • edge: כל רכיבי הקצה מלבד ממשק המשתמש של Edge: שרת ניהול, מעבד הודעות, נתב, שרת Qpid ושרת Postgres
      • ldap: OpenLDAP
      • ps: postgresql
      • qpid: qpidd
      • sso: Apigee SSO (אם התקנתם SSO)
      • ue ממשק המשתמש החדש של Edge
      • ui: ממשק המשתמש הקלאסי של Edge
      • zk: Zookeeper
    • configFile הוא אותו קובץ תצורה שבו השתמשתם כדי להגדיר את רכיבי Edge במהלך ההתקנה של גרסת 4.50.00 או 4.51.00.

    אפשר להריץ את update.sh לכל הרכיבים על ידי הגדרת component ל-'all', אבל רק אם יש לכם פרופיל התקנה של Edge all-in-one (AIO). לדוגמה:

    /opt/apigee/apigee-setup/bin/update.sh -c all -f /tmp/sa_silent_config
  8. מפעילים מחדש את רכיבי ממשק המשתמש בכל הצמתים שבהם הם פועלים, אם עדיין לא עשיתם זאת: 
    /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
  9. בודקים את העדכון על ידי הפעלת הכלי apigee-validate בשרת הניהול, כפי שמתואר בקטע בדיקת ההתקנה.

אם תחליטו לחזור לגרסה הקודמת של העדכון, תוכלו להיעזר בהוראות להחזרת הגרסה הקודמת 4.52.02.

סדר העדכון של המכונה – שדרוג מ-4.51.00 (או) 4.52.00 (או) 4.52.01

חשוב להקפיד על הסדר שבו מעדכנים את המכונות בהתקנה של Edge:

  • צריך לעדכן את כל צמתים של ZooKeeper במרכזי הנתונים לפני שמשדרגים את כל שאר הרכיבים. אם משדרגים מ-Edge Private Cloud 4.51.00 או מ-4.52.00, צריך לבצע גם שלבים נוספים כדי לשדרג את zookeeper.
  • צריך לעדכן את Postgresql בכל מרכזי הנתונים. אם אתם משדרגים מ-Edge Private Cloud 4.51.00, תצטרכו לבצע גם שלבים נוספים כדי לשדרג את postgres.
  • צריך לעדכן את צמתים ה-LDAP בכל מרכזי הנתונים.
  • צריך לעדכן את כל הצמתים של Cassandra, ‏ שרת הניהול, מעבד ההודעות והנתב, מרכז נתונים אחד בכל פעם, עד שכל מרכזי הנתונים ישודרגו.
  • צריך לעדכן את הרכיבים edge-qpid-server ו-edge-postgres-server בכל מרכזי הנתונים.
  • צריך לשדרג את צמתים של Qpid בכל מרכזי הנתונים. אם אתם משדרגים מ-Edge Private Cloud 4.51.00 או מ-4.52.00, תצטרכו לבצע גם שלבים נוספים כדי לשדרג את Qpid.
  • עדכון של ממשק המשתמש של Edge וממשק המשתמש החדש של Edge, צמתים של SSO בכל מרכזי הנתונים.
  • אין שלב נפרד לעדכון המונטיזציה. הוא מתעדכן כשמציינים את האפשרות -c edge.

שדרוג עצמאי של צומת אחד

כדי לשדרג הגדרה עצמאית של צומת אחד לגרסה 4.52.02:
  1. מעדכנים את כל הרכיבים: 
    /opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
  2. (אם התקנתם את apigee-adminapi) עדכנו את השירות apigee-adminapi: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

שדרוג של שני צמתים בנפרד

מעדכנים את הרכיבים הבאים להתקנה עצמאית של שני צמתים:

בטופולוגיות התקנה מופיעה רשימה של טופולוגיות Edge ומספרי צמתים.

  1. מעדכנים את Zookeeper במכונה 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
  2. מעדכנים את Postgres במכונה 2: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  3. מעדכנים את LDAP במכונה 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  4. מעדכנים את Cassandra במכונה 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
  5. מעדכנים את רכיבי Edge במכונה 1 ובמכונה 2: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  6. מעדכנים את Qpid במכונה 2: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  7. מעדכנים את ממשק המשתמש במכונה 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
  8. (אם התקנתם את apigee-adminapi) מעדכנים את השירות apigee-adminapi במכונה 1: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  9. (אם התקנתם את Apigee SSO) מעדכנים את Apigee SSO במכונה 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    כאשר sso_config_file הוא קובץ התצורה שיצרתם כשהתקנתם את SSO.

  10. מפעילים מחדש את הרכיב של ממשק המשתמש של Edge במכונה 1: 
    /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

שדרוג של 5 צמתים

מעדכנים את הרכיבים הבאים להתקנה עם 5 צמתים:

בטופולוגיות התקנה מופיעה רשימה של טופולוגיות Edge ומספרי צמתים.

  1. מעדכנים את ZooKeeper במכונות 1, 2 ו-3: 
    /opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
  2. מעדכנים את Postgres במכונה 4: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  3. מעדכנים את Postgres במכונה 5: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  4. מעדכנים את LDAP במכונה 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  5. מעדכנים את Cassandra במכונות 1, 2 ו-3: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
  6. מעדכנים את רכיבי Edge במכונות 1, 2, 3, 4 ו-5: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. מעדכנים את Qpid במכונה 4: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. מעדכנים את Qpid במכונה 5: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  9. עדכון ממשק המשתמש של Edge:
    • ממשק משתמש קלאסי: אם אתם משתמשים בממשק המשתמש הקלאסי, צריך לעדכן את הרכיב ui במכונה 1, כפי שמתואר בדוגמה הבאה: 
      /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
    • ממשק המשתמש החדש של Edge: אם התקנתם את ממשק המשתמש החדש של Edge, עליכם לעדכן את הרכיב ue במכונה המתאימה (לא בהכרח מכונה 1): 
      /opt/apigee/apigee-setup/bin/update.sh -c ue -f /opt/silent.conf
  10. (אם התקנתם את apigee-adminapi) מעדכנים את השירות apigee-adminapi במכונה 1: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  11. (אם התקנתם את Apigee SSO) מעדכנים את Apigee SSO במכונה 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    כאשר sso_config_file הוא קובץ התצורה שיצרתם כשהתקנתם את SSO.

  12. מפעילים מחדש את רכיב ממשק המשתמש:
    • ממשק משתמש קלאסי: אם אתם משתמשים בממשק המשתמש הקלאסי, צריך להפעיל מחדש את הרכיב edge-ui במכונה 1, כפי שמתואר בדוגמה הבאה: 
      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart
    • ממשק המשתמש החדש של Edge: אם התקנתם את ממשק המשתמש החדש של Edge, צריך להפעיל מחדש את הרכיב edge-management-ui במכונה המתאימה (יכול להיות שזו לא מכונה 1): 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

שדרוג של אשכול עם 9 צמתים

מעדכנים את הרכיבים הבאים בהתקנה של אשכול עם 9 צמתים:

בטופולוגיות התקנה מופיעה רשימה של טופולוגיות Edge ומספרי צמתים.

  1. מעדכנים את ZooKeeper במכונות 1, 2 ו-3: 
    /opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
  2. מעדכנים את Postgres במכונה 8: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  3. מעדכנים את Postgres במכונה 9: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  4. מעדכנים את LDAP במכונה 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  5. מעדכנים את Cassandra במכונות 1, 2 ו-3: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
  6. מעדכנים את רכיבי Edge במכונות 1, 4, 5, 6, 7, 8 ו-9 לפי הסדר הזה: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. מעדכנים את Qpid במכונות 6 ו-7: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. מעדכנים את ממשק המשתמש החדש (ue) או את ממשק המשתמש הקלאסי (ui) במכונה 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  9. (אם התקנתם את apigee-adminapi) מעדכנים את הכלי apigee-adminapi במכונה 1: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  10. (אם התקנתם את Apigee SSO) מעדכנים את Apigee SSO במכונה 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    כאשר sso_config_file הוא קובץ התצורה שיצרתם כשהתקנתם את SSO.

  11. מפעילים מחדש את רכיב ממשק המשתמש:
    • ממשק משתמש קלאסי: אם אתם משתמשים בממשק המשתמש הקלאסי, צריך להפעיל מחדש את הרכיב edge-ui במכונה 1, כפי שמתואר בדוגמה הבאה: 
      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart
    • ממשק המשתמש החדש של Edge: אם התקנתם את ממשק המשתמש החדש של Edge, צריך להפעיל מחדש את הרכיב edge-management-ui במכונה המתאימה (יכול להיות שזו לא מכונה 1): 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

שדרוג של אשכול עם 13 צמתים

מעדכנים את הרכיבים הבאים להתקנה באשכול של 13 צמתים:

בטופולוגיות התקנה מופיעה רשימה של טופולוגיות Edge ומספרי צמתים.

  1. מעדכנים את ZooKeeper במכונות 1, 2 ו-3: 
    /opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
  2. מעדכנים את Postgres במכונה 8: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  3. מעדכנים את Postgres במכונה 9: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  4. מעדכנים את LDAP במכונות 4 ו-5: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  5. מעדכנים את Cassandra במכונות 1, 2 ו-3: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
  6. מעדכנים את רכיבי Edge במכונות 6, 7, 10, 11, 12, 13, 8 ו-9 לפי הסדר הזה: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. מעדכנים את Qpid במכונות 12 ו-13: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. מעדכנים את ממשק המשתמש החדש (ue) או את ממשק המשתמש הקלאסי (ui) במכונות 6 ו-7: 
    /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  9. (אם התקנתם את apigee-adminapi) מעדכנים את השירות apigee-adminapi במכונות 6 ו-7: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  10. (אם התקנתם את Apigee SSO) מעדכנים את Apigee SSO במכונות 6 ו-7: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    כאשר sso_config_file הוא קובץ התצורה שיצרתם כשהתקנתם את SSO.

  11. מפעילים מחדש את רכיב ממשק המשתמש:
    • ממשק משתמש קלאסי: אם אתם משתמשים בממשק המשתמש הקלאסי, צריך להפעיל מחדש את הרכיב edge-ui במכונות 6 ו-7, כפי שמתואר בדוגמה הבאה: 
      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart
    • ממשק המשתמש החדש של Edge: אם התקנתם את ממשק המשתמש החדש של Edge, צריך להפעיל מחדש את הרכיב edge-management-ui במכונות 6 ו-7: 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

שדרוג של אשכול עם 12 צמתים

מעדכנים את הרכיבים הבאים להתקנה באשכול של 12 צמתים:

בטופולוגיות התקנה מופיעה רשימה של טופולוגיות Edge ומספרי צמתים.

  1. מעדכנים את ZooKeeper במכונות 1,‏ 2,‏ 3,‏ 7,‏ 8 ו-9 בשני מרכזי הנתונים:

    /opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
  2. מעדכנים את Postgres במכונות 6 ו-12 בשני מרכזי הנתונים: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  3. מעדכנים את LDAP במכונות 1 ו-7 בשני שרתי ה-DC: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

  4. חסימה של התנועה ב-DC-1 ולוודא שכל התנועה מנותבת מחדש ל-DC-2 אחר

  5. עדכון Cassandra במכונות 1,2,3 ב-DC-1: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
  6. מעדכנים את שרת הניהול במכונה 1 ב-DC-1: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. מעדכנים את הנתב ואת מעבד ההודעות במכונות 2 ו-3 ב-DC-1: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  8. ביטול החסימה של התנועה ב-DC-1 ואימות של DC-1, והמשך התהליך ב-DC-2 על ידי חסימה של התנועה ב-DC-2 והפניית התנועה ל-DC-1
  9. מעדכנים את Cassandra במכונות 7,‏ 8 ו-9 ב-DC-2: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
  10. מעדכנים את שרת הניהול במכונה 7 ב-DC-2: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  11. מעדכנים את הנתב ואת מעבד ההודעות במכונות 8 ו-9 ב-DC-2: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  12. מבטלים את החסימה של התנועה ב-DC-2, וכעת שני מרכזי הנתונים יטפלו בתנועה
  13. מריצים מחדש את פקודת העדכון בכל שרת הניהול במרכזי הנתונים במכונות 1 ו-7: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  14. מעדכנים את edge-qpid-server ואת edge-postgres-server במכונות 4,‏ 5,‏ 6,‏ 10,‏ 11 ו-12 בשני מרכזי הנתונים: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  15. מעדכנים את Qpid במכונות 4,‏ 5,‏ 10 ו-11 בשני מרכזי הנתונים: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  16. מעדכנים את ממשק המשתמש החדש (ue) או את ממשק המשתמש הקלאסי (ui) בשני מרכזי הנתונים: 
    /opt/apigee/apigee-setup/bin/update.sh -c  [ui|ue] -f configFile
  17. (אם התקנתם את apigee-adminapi) מעדכנים את apigee-adminapi בשני המרכזים לעיבוד נתונים: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  18. (אם התקנתם את Apigee SSO) מעדכנים את צמתים של Apigee SSO בשני מרכזי הנתונים: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f configFile
  19. מפעילים מחדש את רכיב ממשק המשתמש החדש של Edge‏ (edge-management-ui) או את רכיב ממשק המשתמש הקלאסי של Edge‏ (edge-ui) בשני מרכזי הנתונים: 
    /opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart