עדכון של Apigee Edge 4.52.02 או 4.53.00 לגרסה 4.53.01

‫Apigee תומך בשדרוג Edge for Private Cloud ישירות מגרסה 4.52.02 או 4.53.00 לגרסה 4.53.01. בדף הזה מוסבר איך לבצע שדרוגים כאלה.

סקירה כללית של נתיבי שדרוג תואמים זמינה בטבלת התאימות לשדרוג של מהדורות Edge for Private Cloud.

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

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

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

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

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

עדכון הדרישות המוקדמות

סקירת השינויים ב-Edge for Private Cloud 4.53.01

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

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

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

  • מוודאים ש-Edge פועל
    כדי לוודא ש-Edge פועל במהלך תהליך העדכון, משתמשים בפקודה: 
    /opt/apigee/apigee-service/bin/apigee-all status
  • אימות הדרישות המוקדמות של Cassandra

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

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

    ב-Edge for Private Cloud 4.53.01, מפתחות ואישורים של ספק הזהויות שמשמשים ברכיב apigee-sso מוגדרים עכשיו באמצעות מאגר מפתחות. תצטרכו לייצא את המפתח והאישור שבהם השתמשתם בעבר אל keystore. לפני שמעדכנים את רכיב ה-SSO, צריך לפעול לפי השלבים המפורטים בקטע השלבים לעדכון Apigee SSO מגרסאות ישנות יותר.

  • דרישות Python
    לפני שמנסים לבצע את השדרוג, מוודאים שגרסה Python 3 מותקנת בכל הצמתים, כולל צמתי Cassandra.

אילו שלבים מיוחדים צריך לבצע כדי לשדרג

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

גרסה נוכחית תוכנה שנדרשים שלבים מיוחדים כדי לשדרג אותה לגרסה 4.53.01
4.52.02 ‫LDAP, ‏ Cassandra, ‏ Zookeeper, ‏ Postgres
4.53.00 ‫LDAP, ‏ Zookeeper, ‏ Postgres

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

הפצה אוטומטית של הגדרות הנכס

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

נדרש שדרוג ל-OpenLDAP 2.6

בהמשך מפורטות ההוראות לשדרוג שירות ה-LDAP הבסיסי של Apigee Edge לענן פרטי מ-OpenLDAP 2.4 מדור קודם ל-OpenLDAP 2.6. השדרוג הזה הוא דרישה מחייבת לעדכון לגרסה 4.53.01 ומעלה של Apigee Edge for Private Cloud. השדרוג הזה רלוונטי לכל טופולוגיות הפריסה של Apigee LDAP: שרת יחיד, פעיל-סביל ופעיל-פעיל (multi-master).

דרישות מוקדמות ושיקולים

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

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

הכנה והתקנה (כל שרתי ה-LDAP)

השלבים בקטע הזה (שלב 2 עד שלב 5) זהים לכל טופולוגיות הפריסה של LDAP. צריך לבצע את הפעולות האלה בכל שרת שבו מותקן הרכיב apigee-openldap, בלי קשר לתפקיד שלו.

  1. לפני שממשיכים בשדרוג LDAP, חשוב להקפיד לכבות את כל edge-management-server ואת edge-ui. 
    apigee-service edge-management-server stop
apigee-service edge-ui stop

  2. גיבוי נתוני LDAP קיימים

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

    • מריצים את פקודת הגיבוי. הפעולה הזו יוצרת ארכיון גיבוי עם חותמת זמן בספרייה /opt/apigee/backup/openldap. 
      apigee-service apigee-openldap backup
    • קבלת המספר הכולל של הרשומות: צריך לתעד את מספר הרשומות בספרייה לצורך אימות אחרי השדרוג (מספר הרשומות צריך להיות זהה בכל שרתי ה-LDAP). זוהי בדיקה ראשונית. 
      # Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \
-D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l

  3. הפסקת LDAP וניקוי ספריות נתונים

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

    • מפסיקים את שירות ה-LDAP. 
      apigee-service apigee-openldap stop
    • מסירים לצמיתות את ספריות הנתונים וההגדרות הישנות של LDAP. 
      rm -rf /opt/apigee/data/apigee-openldap/*

  4. התקנה והגדרה של גרסת ה-LDAP החדשה

    בכל שרתי ה-LDAP, משתמשים בסקריפטים הרגילים של Apigee כדי להוריד ולהתקין את הגרסה החדשה של הרכיב.

    • מתקינים את רכיב ה-LDAP החדש: סקריפט העדכון קורא את קובץ ההגדרות ומתקין את חבילת apigee-openldap החדשה. 
      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f /opt/silent.conf
    • מאמתים את גרסת ה-LDAP החדשה: אחרי שההתקנה מסתיימת, טוענים מחדש את הפרופיל ומוודאים שגרסת ה-LDAP החדשה הותקנה בצורה תקינה. 
      source ~/.bash_profile
ldapsearch -VV
Expected output:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.6.7

  5. הפסקת LDAP בכל השרתים לפני שחזור הנתונים

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

    apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/ldap/*

  6. שחזור נתוני LDAP

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

    1. זיהוי השרת הפעיל הראשון לשחזור

      • להגדרה של שרת יחיד: זהו שרת ה-LDAP היחיד שלכם. אפשר להמשיך ישירות לשלב הבא.
      • בהגדרות פעיל-סביל ופעיל-פעיל: מריצים את פקודת האבחון הבאה בכל שרת LDAP: 
        grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*\ldif
Note:
-If this command returns output, the server is a passive server.
-If it returns no output, the server is the active server.

    2. שחזור נתוני הגיבוי

      לפני שממשיכים, בודקים שוב ששלב 5 הושלם בהצלחה בכל שרתי ה-LDAP.

      • בשרת הפעיל הראשון שזיהיתם למעלה, עוברים לספריית הגיבוי. 
        cd /opt/apigee/backup/openldap
      • מריצים את הפקודה restore. מומלץ מאוד לציין את חותמת הזמן המדויקת של הגיבוי משלב 2 כדי למנוע שחזור של גרסה לא רצויה או ישנה יותר. 
        # To restore a specific backup (recommended):
apigee-service apigee-openldap restore 2025.08.11,23.34.00

# To restore the latest available backup by default:
apigee-service apigee-openldap restore
      • אחרי שתהליך השחזור מסתיים בהצלחה, מפעילים את שירות ה-LDAP בשרת הפעיל הראשון. 
        apigee-service apigee-openldap start

  7. הפעלת שרתי LDAP שנותרו

    אם יש לכם הגדרה של כמה שרתים, בכל אחד משרתי ה-LDAP, מפעילים את השירות: 

    apigee-service apigee-openldap start

  8. אימות סופי

    השלב האחרון הוא לוודא שהשדרוג בוצע בהצלחה ושהנתונים עקביים בכל אשכול ה-LDAP.

    • מריצים את פקודת האימות בכל שרתי ה-LDAP. מספר הרשומות צריך להיות זהה בכל השרתים, ולהתאים למספר שרשמתם בשלב 2.
      • # Note: Replace 'YOUR_PASSWORD' with your LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \
-D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
    • אחרי שמוודאים שהנתונים נכונים ועקביים, השדרוג של LDAP הושלם. עכשיו אפשר להמשיך ולהפעיל את edge-management-server, את edge-ui ואת כל הרכיבים התלויים האחרים, בהתאם לנוהל השדרוג הרגיל של הארגון.

נדרש שדרוג ל-Cassandra 4.0.18

‫Apigee Edge for Private Cloud 4.53.01 כולל שדרוג של Cassandra לגרסה 4.0.18.

שדרוגים וחזרה לגרסה קודמת

  • השדרוג מ-Cassandra 3.11.X ל-Cassandra 4.0.X הוא תהליך פשוט. ‫Cassandra 4.0.X, שפורסמה עם Edge for Private Cloud 4.53.00, תואמת לרכיבי זמן הריצה והניהול של Private Cloud 4.52.02.
  • אי אפשר לבצע ישירות שחזור במקום מ-Cassandra 4.0.X ל-3.11.X. חזרה לגרסה קודמת באמצעות רפליקות או גיבויים היא הליך מורכב, והיא עלולה לגרום להשבתה או לאובדן נתונים. עדיף לפתור בעיות ולשדרג ל-Cassandra 4.0.X מאשר לבטל את השדרוג.
  • חשוב להכיר את תהליכי החזרה לגרסה הקודמת לפני שמנסים לבצע את השדרוג. חשוב להבין את הניואנסים של החזרה לגרסה קודמת במהלך השדרוג כדי לוודא שיש נתיבי חזרה מתאימים.

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

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

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

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

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

  • החזרה לגרסה קודמת תלויה בכך שלפחות מרכז נתונים אחד מריץ את הגרסה הישנה יותר של Cassandra‏ (3.11.X).
  • אם כל אשכול Cassandra שודרג לגרסה 4.0.X, אסור לחזור לגרסה 3.11.X של Cassandra. צריך להמשיך להשתמש בגרסה החדשה יותר של Cassandra עם הרכיבים האחרים של Private Cloud 4.53.00 או 4.52.02.
  1. משדרגים מרכז נתונים אחד של Cassandra בכל פעם: מתחילים בשדרוג של צמתי Cassandra בנפרד בתוך מרכז נתונים יחיד. משלימים את השדרוגים של כל צמתי Cassandra במרכז נתונים אחד לפני שמתקדמים לשדרוג הבא.
  2. השהיה ואימות: אחרי שמשדרגים מרכז נתונים אחד, צריך להשהות את התהליך כדי לוודא שקלאסטר הענן הפרטי, ובמיוחד מרכז הנתונים ששודרג, פועל בצורה תקינה.
  3. חשוב לזכור: אפשר לחזור לגרסה הקודמת של Cassandra רק אם יש לכם לפחות מרכז נתונים אחד שעדיין פועלת בו הגרסה הישנה.
  4. רגיש לזמן: אפשר להשהות את המעבר לפרק זמן קצר (מומלץ לכמה שעות) כדי לאמת את הפונקציונליות, אבל אי אפשר להישאר במצב של גרסה מעורבת לזמן בלתי מוגבל. הסיבה לכך היא שלקלאסטר Cassandra לא אחיד (עם צמתים בגרסאות שונות) יש מגבלות תפעוליות.
  5. בדיקה יסודית: מומלץ מאוד לבצע בדיקה מקיפה של הביצועים והפונקציונליות לפני שמשדרגים את מרכז הנתונים הבא. אחרי שכל מרכזי הנתונים ישודרגו, לא תהיה אפשרות לחזור לגרסה הקודמת.
חזרה לגרסה קודמת כתהליך עם שתי נקודות ביקורת
  1. נקודת ביקורת 1: המצב ההתחלתי, שבו כל הרכיבים הם בגרסה 4.52.02. אפשר לבצע חזרה מלאה לגרסה הקודמת כל עוד לפחות מרכז נתונים אחד של Cassandra נשאר בגרסה הקודמת.
  2. נקודת ביקורת 2: אחרי שכל צמתי Cassandra בכל מרכזי הנתונים מתעדכנים. אפשר לחזור למצב הזה, אבל אי אפשר לחזור לנקודת הבדיקה 1.
דוגמה

נניח שיש לכם קלאסטר עם שני מרכזי נתונים (DC):

  1. מצב התחלתי: צמתי Cassandra בשני מרכזי הנתונים הם בגרסה 3.11.X. כל שאר הצמתים נמצאים ב-Edge for Private Cloud בגרסה 4.52.02. נניח שיש שלושה צמתים של Cassandra בכל מרכז נתונים.
  2. שדרוג DC-1: משדרגים את שלושת צמתי Cassandra ב-DC-1 אחד אחרי השני.
  3. השהיה ואימות: מבצעים השהיה כדי לוודא שהאשכול, ובמיוחד DC-1, פועל בצורה תקינה (בודקים את הביצועים והפונקציונליות). אפשר לחזור למצב הראשוני באמצעות צמתי Cassandra ב-DC-2. חשוב לזכור שההשהיה הזו חייבת להיות זמנית בגלל המגבלות של אשכול Cassandra עם גרסאות מעורבות.
  4. שדרוג DC-2: משדרגים את שלושת צמתי Cassandra שנותרו ב-DC-2. הנקודה הזו הופכת לנקודת הבדיקה החדשה לחזרה לגרסה קודמת.
  5. שדרוג רכיבים אחרים: משדרגים את הצמתים של הניהול, זמן הריצה והניתוח כרגיל בכל מרכזי הנתונים, צומת אחד ומרכז נתונים אחד בכל פעם. אם מתעוררות בעיות, אפשר לחזור למצב של שלב 4.

דרישות מוקדמות לשדרוג Cassandra

צריך להריץ את Cassandra 3.11.16 עם Edge for Private Cloud 4.52.02 ולוודא את הדברים הבאים:
  1. האשכול כולו פועל באופן מלא עם Cassandra 3.11.16.
  2. אסטרטגיית הדחיסה מוגדרת ל-LeveledCompactionStrategy (דרישה מוקדמת לשדרוג לגרסה 4.52.02).

  3. צריך לוודא שכל אחד מהשלבים הבאים הושלם כחלק מהשדרוג הראשוני של Cassandra 3.11 ב-Edge for Private Cloud מגרסה 4.52.02.

    • הפקודה post_upgrade הופעלה בכל צומת של Cassandra במהלך השדרוג הקודם
    • הפקודה drop_old_tables הופעלה באשכול Cassandra כולו במהלך השדרוג הקודם.

אם אתם לא בטוחים שהפקודות post_upgrade ו-drop_old_tables הופעלו ב-Cassandra 3.11 בזמן השימוש ב-Edge for Private Cloud 4.52.02, אתם יכולים להפעיל אותן מחדש בבטחה לפני שתנסו לשדרג ל-4.53.01.

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

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

  1. גיבוי של Cassandra באמצעות Apigee.
  2. יוצרים תמונות מצב של מכונות וירטואליות של צמתי Cassandra (אם אפשר).
  3. מוודאים שאפשר לגשת ליציאה 9042 מכל הרכיבים של Edge for Private Cloud, כולל Management Server,‏ מעבד בקשות,‏ Router,‏ Qpid ו-Postgres, לצמתי Cassandra אם הם עדיין לא הוגדרו. מידע נוסף זמין במאמר בנושא דרישות לגבי יציאות.

שלב 2: משדרגים את כל צמתי Cassandra

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

אחרי שמשדרגים את כל צמתי Cassandra במרכז נתונים, מחכים פרק זמן מסוים (בין 30 דקות לכמה שעות) לפני שממשיכים עם הצמתים במרכז הנתונים הבא. במהלך הזמן הזה, חשוב לבדוק היטב את מרכז הנתונים שעודכן ולוודא שמדדי הפונקציונליות והביצועים של אשכול Apigee תקינים. השלב הזה חשוב מאוד כדי להבטיח את היציבות של מרכז הנתונים שבו Cassandra שודרג לגרסה 4.0.X, בזמן ששאר רכיבי Apigee נשארים בגרסה 4.52.02.

  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
  3. הפלט שיתקבל יהיה דומה לזה: 
    Cassandra version is verified - [cqlsh 6.0.0 | Cassandra 4.0.18 | CQL spec 3.4.5 | Native protocol v5] 
Metadata is verified
  4. מריצים את הפקודה post_upgrade הבאה בצומת Cassandra: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade
  5. מריצים את הפקודה cleanup_old_index הבאה בצומת Cassandra: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra cleanup_old_index
  6. מריצים את הפקודות הבאות של nodetool כדי לבנות מחדש את האינדקסים בצומת Cassandra: 
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms api_products api_products_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_api_products_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_end_user app_end_user_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_family_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_type_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms maps maps_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_consumer_key_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_consumer_key_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_request_token_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_client_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_refresh_token_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_client_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_company_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_developer_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index cache cache_entries cache_entries_cache_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_operation_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_requesturi_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_responsecode_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_timestamp_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_user_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_active_rev
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_index_template
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_method_template
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_latest_rev
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_active
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_latest
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rel_ver
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_res_path
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_res_path
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_entity
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template_auth au_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index dek keys usecase_index
     אם אתם משתמשים במונטיזציה, מריצים גם את הפקודות הבאות של בנייה מחדש של אינדקסים שקשורות למרחבי מפתחות של מונטיזציה: 
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_created_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_updated_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_created_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_currency_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_dev_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_limit_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_prod_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_reason_code_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_sub_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_company_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_created_at_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_developer_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_lastmodified_at_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_env_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_job_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_class_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_group_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus org_triggers org_triggers_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_group_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_suite_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_to_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_org_id_idx

שלב 3: שדרוג כל צמתי הניהול

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

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

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

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

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

שלב 5: שדרוג כל הרכיבים שנותרו ב-Edge for Private Cloud 4.53.01

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

נדרש שדרוג ל-Zookeeper 3.8.4

הגרסה הזו של Edge for Private Cloud כוללת שדרוג ל-Zookeeper 3.8.4. כחלק מהשדרוג הזה, כל הנתונים של Zookeeper יועברו ל-Zookeeper 3.8.4.

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

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

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

יצירת גיבוי

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

  /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper backup

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

זיהוי המנהיג, העוקבים והצופים

הערה: בדוגמאות של הפקודות שבהמשך נעשה שימוש בכלי nc כדי לשלוח נתונים ל-Zookeeper. אפשר גם להשתמש בכלי עזר חלופיים כדי לשלוח נתונים ל-Zookeeper.

  1. אם הוא לא מותקן בצומת ZooKeeper, מתקינים את nc: 
      sudo yum install nc
  2. מריצים את פקודת ה-nc הבאה בצומת, כאשר 2181 הוא יציאת ZooKeeper: 
      echo stat | nc localhost 2181

    הפלט אמור להיראות כך:

      Zookeeper version: 3.8.4-5a02a05eddb59aee6ac762f7ea82e92a68eb9c0f, built on 2022-02-25 08:49 UTC
  Clients:
   /0:0:0:0:0:0:0:1:41246[0](queued=0,recved=1,sent=0)
  
  Latency min/avg/max: 0/0.2518/41
  Received: 647228
  Sent: 647339
  Connections: 4
  Outstanding: 0
  Zxid: 0x400018b15
  Mode: follower
  Node count: 100597

    בשורה Mode של הפלט עבור הצמתים, אמור להופיע observer,‏ leader או follower (כלומר, מצביע שלא נבחר להיות המוביל), בהתאם להגדרת הצומת. הערה: בהתקנה עצמאית של Edge עם צומת ZooKeeper יחיד, הערך של Mode מוגדר כ-standalone.

  3. חוזרים על שלבים 1 ו-2 בכל צומת של ZooKeeper.

שדרוג Zookeeper בצמתי הצופה והעוקב

משדרגים את Zookeeper בכל אחד מהצמתים של observer ו-follower באופן הבא:

  1. מורידים ומריצים את bootstrap של Edge for Private Cloud 4.53.01, כמו שמתואר במאמר עדכון לגרסה 4.53.01 בצומת עם חיבור חיצוני לאינטרנט. התהליך ישתנה בהתאם לשאלה אם לצומת יש חיבור חיצוני לאינטרנט או אם מבצעים התקנה במצב אופליין.
  2. משדרגים את הרכיב Zookeeper: 
      /opt/apigee/apigee-setup/bin/update.sh -c zk -f <silent-config-file>
     הערה: אם הצמתים האלה כוללים רכיבים אחרים (כמו Cassandra), אפשר לשדרג אותם עכשיו (כמו בפרופיל cs,zk) או לשדרג את הרכיבים האחרים מאוחר יותר. ‫Apigee ממליצה לשדרג קודם רק את Zookeeper ולוודא שהאשכול פועל בצורה תקינה לפני שמשדרגים רכיבים אחרים.
  3. חוזרים על השלבים שלמעלה בכל אחד מהצמתים של Zookeeper observer ו-follower.

השבתת המנהיג

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

  /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop

שימו לב: במהלך האירוע הזה, לפני שנבחר מנהיג חדש, יכול להיות שיהיו עיכובים רגעיים או כשלים בכתיבה ב-Zookeeper. הדבר עלול להשפיע על פעולות שכותבות ל-Zookeeper, כמו פעולות פריסה של שרתי proxy או שינויים בתשתית של Apigee, כמו הוספה או הסרה של מעבדי הודעות וכו'.

מוודאים שהלידר החדש נבחר

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

שדרוג של בכיר בארגון

פועלים לפי אותם השלבים שמפורטים בקטע שדרוג Zookeeper בצמתי הצופה והעוקב שלמעלה.

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

שדרוג Nginx 1.26 ב-Edge-Router

אם משדרגים ל-Edge for Private Cloud 4.53.01 מגרסאות קודמות, תוכנת Nginx לא משודרגת אוטומטית לגרסה האחרונה (1.26.x). השינוי הזה נועד למנוע תופעות לוואי לא מכוונות בזמן הריצה כתוצאה מהשינויים שמפורטים במאמר Nginx 1.26 changes in Apigee Edge 4.53.01. אחרי האימות בסביבות נמוכות יותר, אפשר לשדרג את Nginx מגרסה 1.20.x לגרסה 1.26.x באופן ידני. כדי לשדרג באופן ידני:

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

    /opt/apigee/apigee-service/bin/apigee-service edge-router version

  2. בדיקה ואימות של גרסת Nginx שפועלת כרגע

    /opt/nginx/sbin/nginx -V

    אם אתם משתמשים בגרסה ישנה יותר של Nginx, אתם יכולים לפעול לפי השלבים הבאים כדי לשדרג את Nginx לגרסה 1.26.X בצומת הנתב.

  3. הפסקת התהליך של נתב קצה בצומת הנתב

    /opt/apigee/apigee-service/bin/apigee-service edge-router stop

  4. שדרוג תוכנת nginx בצומת הנתב

    dnf update apigee-nginx

  5. בודקים שגרסת Nginx עודכנה

    /opt/nginx/sbin/nginx -V

  6. הפעלת תהליך הנתב בצומת

    /opt/apigee/apigee-service/bin/apigee-service edge-router start

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

נדרש שדרוג ל-Postgres 17

הגרסה הזו של Edge כוללת שדרוג ל-Postgres 17. כחלק מהשדרוג הזה, כל נתוני Postgres מועברים ל-Postgres 17.

ברוב מערכות הייצור של Edge נעשה שימוש בשני צמתי Postgres שהוגדרו לשכפול master-standby. במהלך תהליך העדכון, בזמן שהצמתים של Postgres מושבתים לצורך העדכון, נתוני הניתוח עדיין נכתבים לצמתים של Qpid. אחרי שהצמתים של Postgres מתעדכנים וחוזרים למצב אונליין, נתוני הניתוח נדחפים לצמתים של Postgres.

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

  • אם אתם משתמשים באחסון נתונים מקומי לצמתי Postgres, אתם צריכים להתקין צומת חדש של Postgres במצב המתנה למשך השדרוג. אחרי שהשדרוג יסתיים, תוכלו להוציא משימוש את צומת ה-Postgres החדש במצב המתנה.

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

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

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

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

התקנה של צומת חדש במצב המתנה של Postgres

התהליך הזה יוצר שרת Postgres במצב המתנה בצומת חדש. חשוב לוודא שמתקינים שרת Postgres חדש במצב המתנה לגרסה הקיימת של Edge (4.52.02 או 4.53.00), ולא לגרסה 4.53.01.

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

כדי ליצור צומת המתנה חדש של Postgres:

  1. בשרת ה-Postgres הראשי הנוכחי, עורכים את הקובץ /opt/apigee/customer/application/postgresql.properties כדי להגדיר את האסימון הבא. אם הקובץ לא קיים, יוצרים אותו: 
    conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust\ \nhost replication apigee new_standby_ip/32 trust

    כאשר existing_standby_ip היא כתובת ה-IP של שרת הגיבוי הנוכחי של Postgres ו-new_standby_ip היא כתובת ה-IP של צומת הגיבוי החדש.

  2. מפעילים מחדש את apigee-postgresql ב-Postgres master: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
  3. בודקים שהצומת החדש למצב המתנה נוסף על ידי צפייה בקובץ /opt/apigee/apigee-postgresql/conf/pg_hba.conf בשרת הראשי. אתם אמורים לראות את השורות הבאות בקובץ: 
    host replication apigee existing_standby_ip/32 trust
host replication apigee new_standby_ip/32 trust
  4. מתקינים את שרת ההמתנה החדש של Postgres:
    1. עורכים את קובץ ההגדרות שבו השתמשתם כדי להתקין את הגרסה הנוכחית של Edge, ומציינים את הפרטים הבאים: 
      # IP address of the current master:
PG_MASTER=192.168.56.103
# IP address of the new standby node
PG_STANDBY=192.168.56.102
    2. משביתים את SELinux כמו שמתואר במאמר התקנת כלי השירות apigee-setup של Edge.

    3. אם אתם משתמשים כרגע ב-Edge 4.52.02:

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

      אם אתם משתמשים כרגע ב-Edge 4.53.00:

      1. מורידים את הקובץ Edge bootstrap_4.53.00.sh אל /tmp/bootstrap_4.53.00.sh : 
        curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh
      2. מתקינים את כלי השירות apigee-service של Edge ואת יחסי התלות שלו: 
        sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
    4. משתמשים ב-apigee-service כדי להתקין את כלי השירות apigee-setup: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
    5. מתקינים את Postgres: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
    6. בצומת ההמתנה החדש, מריצים את הפקודה הבאה: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

      מוודאים שהוא במצב המתנה.

ביצוע שדרוג במקום של Postgres

הערה: צריך לבצע את השלב המקדים הבא לפני שמבצעים שדרוג במקום של Postgres.

שלב מקדים

לפני שמבצעים שדרוג במקום ל-Postgres, מבצעים את השלבים הבאים גם במארח הראשי וגם במארח ההמתנה, כדי לעדכן את המאפיין max_locks_per_transaction ב-apigee-postgresql:

  1. אם הקובץ לא קיים, יוצרים את הקובץ /opt/apigee/customer/application/postgresql.properties.
  2. שינוי הבעלות על הקובץ הזה לapigee: 
    sudo chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
  3. מוסיפים את המאפיין הבא לקובץ: 
    conf/postgresql.conf+max_locks_per_transaction=30000
  4. הגדרה של apigee-postgresql: 
    apigee-service apigee-postgresql configure
  5. הפעלה מחדש של apigee-postgresql: 
    apigee-service apigee-postgresql restart

ביצוע שדרוג במקום

כדי לבצע שדרוג במקום ל-Postgres 17, פועלים לפי השלבים הבאים:

  1. שדרוג postgres במארח הראשי 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f /opt/silent.conf
  2. מריצים את פקודת ההגדרה במחשב המארח הראשי: 
    apigee-service apigee-postgresql setup -f /opt/silent.conf
  3. מריצים את פקודת ההגדרה במארח הראשי: 
    apigee-service apigee-postgresql configure
  4. מפעילים מחדש את המארח הראשי: 
    apigee-service apigee-postgresql restart
  5. מגדירים אותו כמאסטר: 
    apigee-service apigee-postgresql setup-replication-on-master -f /opt/silent.conf
  6. מוודאים שהמארח הראשי התחיל את הפגישה: 
    apigee-service apigee-postgresql wait_for_ready
  7. כדי להפסיק את מצב ההמתנה: 
    apigee-service apigee-postgresql stop
  8. משדרגים את הגיבוי.

    הערה: אם השלב הזה נכשל או מציג שגיאה, אפשר להתעלם ממנו. ‫update.sh ינסה להפעיל את שרת ההמתנה עם הגדרה שגויה. אם התקנת Postgres משודרגת לגרסה 17, אפשר להתעלם מהשגיאה.

    /opt/apigee/apigee-setup/bin/update.sh -c ps -f /opt/silent.conf
  9. מוודאים שהמצב 'המתנה' הופסק: 
    apigee-service apigee-postgresql stop
  10. מסירים את הגדרת הגיבוי הישנה: 
    rm -rf /opt/apigee/data/apigee-postgresql/
  11. מגדירים שכפול בשרת ההמתנה: 
    apigee-service apigee-postgresql setup-replication-on-standby -f /opt/silent.conf
  12. מסירים את השורה conf/postgresql.conf+max_locks_per_transaction=30000 מהקובץ /opt/apigee/customer/application/postgresql.properties במארח הראשי ובמארח ההמתנה. השורה הזו נוספה בשלב המקדים.

אחרי שתשלימו את התהליך הזה, מצב ההמתנה יתחיל בהצלחה.

הוצאה משימוש של צומת Postgres

אחרי שהעדכון מסתיים, מוציאים משימוש את צומת ההמתנה החדש:

  1. מוודאים ש-Postgres פועל: 
    /opt/apigee/apigee-service/bin/apigee-all status

    אם Postgres לא פועל, מפעילים אותו: 

    /opt/apigee/apigee-service/bin/apigee-all start
  2. מריצים את הפקודה curl הבאה בצומת ההמתנה החדש כדי לקבל את ה-UUID שלו: 
    curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

    בסוף הפלט אמור להופיע ה-UUID של הצומת, בפורמט הבא: 

    "type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
  3. מפסיקים את צומת ההמתנה החדש על ידי הרצת הפקודה הבאה בצומת ההמתנה החדש: 
    /opt/apigee/apigee-service/bin/apigee-all stop
  4. בצומת הראשי של Postgres, עורכים את /opt/apigee/customer/application/postgresql.properties כדי להסיר את צומת ההמתנה החדש מ-conf_pg_hba_replication.connection: 
    conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust
  5. מפעילים מחדש את apigee-postgresql ב-Postgres master: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
  6. כדי לוודא שהוסר צומת חדש במצב המתנה, מעיינים בקובץ /opt/apigee/apigee-postgresql/conf/pg_hba.conf בשרת הראשי. בקובץ הזה אמורה להופיע רק השורה הבאה: 
    host replication apigee existing_standby_ip/32 trust
  7. מוחקים את ה-UUID של צומת ההמתנה מ-ZooKeeper על ידי ביצוע קריאה ל-Edge Management API בצומת של שרת הניהול: 
    curl -u sysAdminEmail:password -X DELETE http://ms_IP:8080/v1/servers/new_standby_uuid

השלבים אחרי השדרוג ל-Postgres

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

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

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

שלבים לעדכון Apigee SSO מגרסאות ישנות יותר

ב-Edge for Private Cloud 4.53.01, המפתחות והאישורים של ספק הזהויות שמשמשים ברכיב apigee-sso מוגדרים עכשיו דרך מאגר מפתחות. תצטרכו לייצא את המפתח והאישור שבהם השתמשתם קודם למאגר מפתחות, להגדיר אותו ואז להמשיך בעדכון ה-SSO כרגיל.

  1. מזהים את המפתח והאישור הקיימים שמשמשים להגדרת ספק הזהויות:

    1. מאחזרים את האישור על ידי חיפוש הערך של SSO_SAML_SERVICE_PROVIDER_CERTIFICATE בקובץ התצורה של התקנת ה-SSO או על ידי שליחת שאילתה לרכיב apigee-sso לגבי conf_login_service_provider_certificate.

      מריצים את הפקודה הבאה בצומת ה-SSO כדי לשלוח שאילתה אל apigee-sso לגבי הנתיב של אישור ה-IDP. בודקים את הערך בשורה האחרונה של הפלט. 

      apigee-service apigee-sso configure -search conf_login_service_provider_certificate

    2. מאחזרים את המפתח על ידי חיפוש הערך של SSO_SAML_SERVICE_PROVIDER_KEY בקובץ ההגדרות של התקנת ה-SSO או על ידי שליחת שאילתה לרכיב apigee-sso לגבי conf_login_service_provider_key.

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

      apigee-service apigee-sso configure -search conf_login_service_provider_key
  2. מייצאים את המפתח והאישור ל-keystore:
    1. מייצאים את המפתח והאישור אל PKCS12 keystore: 
      sudo openssl pkcs12 -export -clcerts -in <certificate_path> -inkey <key_path> -out <keystore_path> -name <alias>

      פרמטרים:

      • ‫certificate_path: הנתיב לקובץ האישור שאוחזר בשלב 1.א.
      • ‫key_path: הנתיב לקובץ המפתח הפרטי שאוחזר בשלב 1.ב.
      • ‫keystore_path: הנתיב למאגר המפתחות שנוצר לאחרונה ומכיל את האישור והמפתח הפרטי.
      • ‫alias: הכינוי שמשמש לזוג המפתחות והאישורים במאגר המפתחות.

      פרטים נוספים מופיעים במאמרי העזרה של OpenSSL.

    2. (אופציונלי) מייצאים את המפתח והאישור מ-PKCS12 למאגר מפתחות JKS: 
      sudo keytool -importkeystore -srckeystore <PKCS12_keystore_path> -srcstoretype PKCS12 -destkeystore <destination_keystore_path> -deststoretype JKS -alias <alias>

      פרמטרים:

      • ‫PKCS12_keystore_path: הנתיב למאגר המפתחות PKCS12 שנוצר בשלב 2א, שמכיל את האישור והמפתח.
      • ‫destination_keystore_path: הנתיב למאגר המפתחות החדש בפורמט JKS שאליו ייוצאו האישור והמפתח.
      • ‫alias: שם הכינוי שמשמש לזוג המפתחות והאישורים במאגר המפתחות JKS.

      3. פרטים נוספים מופיעים במאמרי העזרה של keytool.

  3. משנים את הבעלים של קובץ מאגר המפתחות של הפלט למשתמש 'apigee': 
    sudo chown apigee:apigee <keystore_file>
  4. מוסיפים את המאפיינים הבאים ב קובץ ההגדרות של Apigee SSO ומעדכנים אותם עם הנתיב לקובץ מאגר המפתחות, הסיסמה, סוג מאגר המפתחות והכינוי: 
    # Path to the keystore file
SSO_SAML_SERVICE_PROVIDER_KEYSTORE_PATH=${APIGEE_ROOT}/apigee-sso/source/conf/keystore.jks

# Keystore password
SSO_SAML_SERVICE_PROVIDER_KEYSTORE_PASSWORD=Secret123  # Password for accessing the keystore

# Keystore type
SSO_SAML_SERVICE_PROVIDER_KEYSTORE_TYPE=JKS  # Type of keystore, e.g., JKS, PKCS12

# Alias within keystore that stores the key and certificate
SSO_SAML_SERVICE_PROVIDER_KEYSTORE_ALIAS=service-provider-cert
  5. מעדכנים את תוכנת Apigee SSO בצומת ה-SSO כרגיל באמצעות הפקודה הבאה: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f /opt/silent.conf

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

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

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

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

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

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

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

כדי לעדכן את Apigee mTLS , פועלים לפי השלבים הבאים:

חזרה לגרסה קודמת של עדכון

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

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

רישום מידע על עדכונים

כברירת מחדל, כלי השירות 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 מוצגים Router ומעבד בקשות באותו הצומת.
  4. מוודאים שאפשר להגיע לנתב.
  5. חוזרים על שלבים 2 עד 4 בשביל שאר הנתבים.
  6. ממשיכים את העדכון בכל המחשבים הנותרים בהתקנה.

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

שימוש בקובץ תצורה שקט

צריך להעביר קובץ תצורה שקט לפקודת העדכון. קובץ התצורה השקט צריך להיות אותו קובץ שבו השתמשתם כדי להתקין את Edge for Private Cloud 4.52.02 או 4.53.00.

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

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

  1. אם יש משימות cron שמוגדרות לבצע פעולת תיקון ב-Cassandra, צריך להשבית אותן עד לסיום העדכון.
  2. מתחברים לצומת כמשתמש root כדי להתקין את חבילות ה-RPM של Edge.
  3. משביתים את SELinux כמו שמתואר במאמר התקנה של כלי השירות apigee-setup של Edge.
  4. אם אתם מתקינים ב-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

  5. אם אתם משתמשים כרגע בגרסה Edge 4.52.02 או 4.53.00:

    1. מורידים את קובץ Edge bootstrap_4.53.01.sh אל /tmp/bootstrap_4.53.01.sh: 
      curl https://software.apigee.com/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh
    2. מריצים את הפקודה הבאה כדי להתקין את כלי השירות Edge 4.53.01 apigee-service ואת יחסי התלות: 
      sudo bash /tmp/bootstrap_4.53.01.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.52.02 או 4.53.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 UI בכל הצמתים שבהם הם פועלים: 
      /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
    8. כדי לבדוק את העדכון, מריצים את כלי השירות apigee-validate בשרת הניהול, כמו שמתואר במאמר בדיקת ההתקנה.

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

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

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

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

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

כדי לעדכן ממאגר מקומי בגרסה 4.53.01:

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

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

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

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

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

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

    3. בצומת המרוחק, מתקינים את כלי השירות Edge apigee-setup ואת יחסי התלות: 
      sudo bash /tmp/bootstrap_4.53.01.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 חוץ מממשק המשתמש של Edge: שרת הניהול, מעבד ההודעות, הנתב, שרת QPID, שרת Postgres
      • ‫ldap: OpenLDAP
      • ‫ps: postgresql
      • qpid: qpidd
      • ‫sso: Apigee SSO (אם התקנתם SSO)
      • ue ממשק משתמש חדש של Edge
      • ‫ui: ממשק משתמש קלאסי של Edge
      • zk: Zookeeper
    • ‫configFile הוא אותו קובץ תצורה שבו השתמשתם כדי להגדיר את רכיבי Edge במהלך ההתקנה של גרסה 4.52.02 או 4.53.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.53.01.

סדר העדכון של המכונה

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

  • חובה לעדכן את כל צמתי ה-LDAP לפני עדכון של רכיבים אחרים. כדי לשדרג את LDAP, צריך לפעול לפי שלבים מיוחדים.
  • צריך לעדכן את כל הצמתים של Cassandra ו-ZooKeeper. אם אתם משדרגים מגרסה 4.52.02, עליכם לפעול לפי השלבים המיוחדים לשדרוג Cassandra. תצטרכו לבצע את השלבים המיוחדים לשדרוג Zookeeper לגרסה 4.52.02 או 4.53.00.
  • כדי לעדכן את כל שרתי הניהול, המעבדים של הנתבים וההודעות, צריך לשדרג אותם באמצעות האפשרות ‎-c edge.
  • צריך לשדרג את כל צמתי Postgres לפי השלבים המיוחדים לשדרוג Postgres.
  • צריך לעדכן את הרכיבים edge-qpid-server ו-edge-postgres-server בכל מרכזי הנתונים.
  • חובה לשדרג את כל צמתי Qpid.
  • צריך לשדרג את הצמתים של ממשק המשתמש של Edge, וגם לשדרג את הצמתים של ממשק המשתמש החדש של Edge ואת הצמתים של הכניסה היחידה(אם רלוונטי).
  • אין שלב נפרד לעדכון המונטיזציה. הוא מתעדכן כשמציינים את האפשרות -c edge.

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

כדי לשדרג הגדרה של Standalone עם צומת אחד לגרסה 4.53.01:

  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

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

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

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

  1. מעדכנים את LDAP במחשב 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. מעדכנים את Cassandra ואת ZooKeeper במכונה 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. מעדכנים את רכיבי Edge במכונה 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. מעדכנים את Postgres במכונה 2: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. מעדכנים את רכיבי Edge במכונה 1: 
    /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 UI במכונה 1: 
    /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

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

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

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

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

      3. ‫sso_config_file הוא קובץ ההגדרות שיצרתם כשהתקנתם את ה-SSO.

  10. מפעילים מחדש את הרכיב של ממשק המשתמש החדש של Edge‏ (edge-management-ui) או של ממשק המשתמש הקלאסי של Edge‏ (edge-ui) במכונות 1 ו-7: 
    /opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart

להגדרה לא סטנדרטית

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

  1. LDAP
  2. Cassandra
  3. מטפל בבעלי חיים
  4. שרת ניהול
  5. מעבד בקשות
  6. נתב
  7. Postgres
  8. ‫Edge, כלומר פרופיל ‎-c edge בכל הצמתים בסדר הבא: צמתים עם שרת Qpid,‏ שרת Edge Postgres.
  9. qpidd
  10. ממשק המשתמש של Edge (קלאסי או חדש)
  11. apigee-adminapi
  12. Apigee SSO

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