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

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

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

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

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

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

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

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

חומרי קריאה מקדימה

בנושאים הבאים מופיע מידע חשוב על השינויים שהוצגו ב-Edge for Private Cloud 4.54.00:

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

• ארכיטקטורת סביבת זמן ריצה כפולה של Java‏ (Java 17 ו-Java 21): החל מגרסה 4.54.00, ב-Edge for Private Cloud אין יותר תמיכה ב-Java 8, והרכיבים פועלים ב-Java 17 או ב-Java 21. מידע נוסף זמין במאמר שינויים בגרסה 4.54.00.

• אין התקנת Java אוטומטית במהלך האתחול: ל-Edge for Private Cloud 4.54.00 יש יכולת לגלות התקנות של Java ולאמת שיש לכם גם Java 17 וגם Java 21.

• ממשק משתמש חדש של Edge בגרסה 4.54.00: מידע על המעבר לממשק המשתמש החדש של Edge כממשק הניהול שמוגדר כברירת מחדל, ועל ההסרה של ממשק המשתמש הקלאסי (edge-ui). מידע נוסף זמין במאמר ממשק המשתמש החדש של Edge.

• ‫מודול SSO ב-Apigee בגרסה 4.54.00: הסבר על השינויים בארכיטקטורה ובהגדרות של ה-SSO המעודכן לצורך אימות. מידע נוסף זמין במאמר מודול SSO ב-Apigee.

• ‫Nginx 1.30 בגרסה 4.54.00: מידע על השדרוג האוטומטי של Nginx 1.30.x בנתבי Edge, על ההשפעות האפשריות בזמן הריצה ועל שלבי המיטיגציה. מידע נוסף זמין במאמר Nginx 1.30 Changes.

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

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

• עיון בנתוני הגרסה ובתכונות החדשות

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

• גילוי אוטומטי של קובצי Java בינאריים ודו-קיום במהלך השדרוג: מתקינים את Java באמצעות מנהלי חבילות סטנדרטיים (כמו yum) או מיקומים סטנדרטיים (כמו ‎ /usr/lib/jvm או update-alternatives). אין צורך להגדיר את שתי הגרסאות ב-PATH של המערכת בו-זמנית. אל תסירו את Java 8 לפני השדרוג. חשוב להשאיר את Java 8 מותקנת לצד Java 17 ו-Java 21 כדי שהשירותים הקיימים של Edge for Private Cloud 4.53.xx ימשיכו לפעול ללא הפרעה עד לעדכון שלהם.

• גיבוי כל הצמתים

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

• גיבוי של קובץ תצורה שקט

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

• מוודאים ש-Edge פועל

  כדי לוודא ש-Edge פועל במהלך תהליך העדכון, משתמשים בפקודה:

  /opt/apigee/apigee-service/bin/apigee-all status

• אימות הדרישות המוקדמות של Cassandra

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

• עוצרים את apigee-monit: אם apigee-monit פועל בצומת, צריך לעצור אותו באמצעות הפקודה /opt/apigee/apigee-service/bin/apigee-service apigee-monit stop לפני השדרוג. כך מונעים הפעלה מחדש אוטומטית של רכיבים על ידי apigee-monit בזמן השדרוג שלהם. אחרי שהשדרוג מסתיים, מפעילים אותו מחדש באמצעות apigee-service apigee-monit start.

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

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

שדרוג של נתב ומעבד הודעות

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

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

שדרוג שרת הניהול

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

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

שדרוג ל-OpenLDAP 2.6.10

ב-Edge for Private Cloud 4.54.00 מוצג OpenLDAP 2.6.10. השדרוג הזה חל על כל טופולוגיות הפריסה של Apigee OpenLDAP: שרת יחיד, פעיל-סביל ופעיל-פעיל (multi-master).

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

שדרוג לממשק המשתמש החדש של Edge ול-SSO ב-Apigee (אם הוא מותקן)

ב-Apigee Edge for Private Cloud 4.54.00, ממשק המשתמש הקלאסי (edge-ui) הוסר והוחלף בממשק המשתמש החדש של Edge‏ (edge-management-ui). בהתאם לשאלה אם הכניסה היחידה (SSO) של Apigee מותקנת ומשמשת בהגדרה שלכם, צריך לפעול לפי אחת משתי האפשרויות הבאות:

# Authentication mode for New Edge UI (Basic Authentication - No Apigee SSO)
AUTH_MODE=basic

# Access configuration for the New Edge UI
MANAGEMENT_UI_PORT=3001
MANAGEMENT_UI_APP_ENV=OPDK
MANAGEMENT_UI_IP=MANAGEMENT_UI_NODE_IP #Replace MANAGEMENT_UI_NODE_IP with the IP address or hostname of the UI node.
MANAGEMENT_UI_SCHEME=http

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

apigee-service apigee-sso stop

/opt/apigee/apigee-service/bin/apigee-service apigee-openldap setup-sso -f configFile

/opt/apigee/apigee-service/bin/apigee-service edge-management-ui configure-sso -f configFile

apigee-service apigee-sso uninstall

שדרוג ל-Qpid 10.0.1

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

כדי לבצע שדרוג במקום ל-Qpid ללא זמן השבתה:

1. בוחרים צומת Qpid אחד כדי להתחיל.

2. עוצרים את ה-broker של Qpid בצומת:

   apigee-service apigee-qpidd stop

3. חסימת תנועה נכנסת ביציאת הברוקר 5672 מכל מעבדי ההודעות באמצעות הפעלת חומת אש. אפשר להחיל את חומת האש הזו ברמת המכונה של צומת Qpid או ברכיב חיצוני אחר של חומת אש או רשת.

   מומלץ לבצע את אותו שלב לכל כתובות ה-IP של מעבדי הבקשות. לדוגמה, כדי להשליך בקשות שמגיעות מכתובות IP של מעבד הודעות לצומת Qpid ביציאה 5672 באמצעות IPTables, אפשר להשתמש בפקודה כזו:

   iptables -A INPUT -p tcp --dport 5672 -s MESSAGE_PROCESSOR_IP -j DROP

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

   apigee-service apigee-qpidd start

5. בודקים שהתורים הקיימים ריקים:

   /opt/apigee/apigee-qpidd/bin/qpid-stat -q

   אם ההודעות תקועות בתור של הודעות שלא ניתן להעביר (DLQ) (ax-q-axgroup-001-consumer-group-001-dl), צריך לנקז את התור באמצעות השלבים לפתרון בעיות שקשורות לנתוני ניתוח שתקועים בתור של הודעות שלא ניתן להעביר.

6. אחרי שמוודאים שהתורים התרוקנו בצומת הישן, מפסיקים את apigee-qpidd:

   apigee-service apigee-qpidd stop

7. משדרגים את Qpid בצומת:

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

8. הפעלה מחדש של edge-qpid-server:

   apigee-service edge-qpid-server restart

9. מסירים את הכלל של חומת האש שהוחל בשלב 3.

   מבצעים את אותו שלב הסרה לכל כתובות ה-IP של מעבדי הבקשות שחומת האש הוחלה עליהן. אחרי הסרת חומות האש, יתקבלו בקשות שמגיעות מכתובות IP של מעבדי בקשות לצומת Qpid ביציאה 5672. אם השתמשתם ב-iptables כדי להוסיף את חומת האש, כדי להסיר את חומת האש ולראות את ההגדרות הקיימות, אתם יכולים להשתמש בפקודות כמו אלה:

   iptables -F
   iptables -L

10. כדי לוודא שההודעות מתקבלות בתורים של Qpid, משתמשים בניטור אינטרנט:

    http://QPID_NODE_IP:8090

11. חוזרים על שלבים 1 עד 9 לכל צומת Qpid.

שדרוג ל-Postgres 18.6

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

ברוב מערכות הייצור של Edge נעשה שימוש בשני צמתי Postgres שהוגדרו לשכפול ראשי-משני. במהלך תהליך העדכון, כשצומתי 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.53.00 או 4.53.01), ולא לגרסה 4.54.00.

כדי לבצע את ההתקנה, משתמשים באותו קובץ תצורה ששימש להתקנת הגרסה הנוכחית של 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 הראשי:

   /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 primary(master):
      PG_MASTER=PG_MASTER_NODE_IP
      # IP address of the new standby node
      PG_STANDBY=PG_STANDBY_NODE_IP

   2. משביתים את SELinux כמו שמתואר במאמר התקנת כלי השירות apigee-setup של Edge.

   3. מורידים ומריצים את סקריפט האתחול בהתאם לגרסה הנוכחית של Edge:

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

        מורידים את קובץ 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

        מתקינים את כלי השירות apigee-service של Edge ואת יחסי התלות שלו:

        bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord

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

        מורידים את הקובץ bootstrap_4.53.01.sh של Edge אל /tmp/bootstrap_4.53.01.sh:

        curl https://software.apigee.com/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh

        מתקינים את הכלי apigee-service של Edge ואת יחסי התלות:

        bash /tmp/bootstrap_4.53.01.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. בצומת הגיבוי החדש, מריצים את הפקודה הבאה ומוודאים שהוא מוגדר כ-standby:

      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

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

שלב מקדים

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

1. אם הוא לא קיים, יוצרים את הקובץ ‎ /opt/apigee/customer/application/postgresql.properties .

2. משנים את הבעלות על הקובץ ל-apigee :

   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 18:

1. שדרוג postgres במארח הראשי

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

2. מריצים את פקודת ההגדרה במארח הראשי:

   apigee-service apigee-postgresql setup -f configFile

3. מריצים את פקודת ההגדרה במארח הראשי:

   apigee-service apigee-postgresql configure

4. מפעילים מחדש את המארח הראשי:

   apigee-service apigee-postgresql restart

5. מגדירים אותו כאמצעי התשלום הראשי:

   apigee-service apigee-postgresql setup-replication-on-master -f configFile

6. מוודאים שהמארח הראשי התחיל את הפגישה:

   apigee-service apigee-postgresql wait_for_ready

7. כדי להפסיק את מצב ההמתנה:

   apigee-service apigee-postgresql stop

8. משדרגים את המכשיר במצב המתנה.

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

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

9. מוודאים שהמצב המתנה הופסק:

   apigee-service apigee-postgresql stop

10. מסירים את ההגדרה הישנה של הגיבוי:

    rm -rf /opt/apigee/data/apigee-postgresql/

11. מגדירים שכפול בשרת ההמתנה:

    apigee-service apigee-postgresql setup-replication-on-standby -f configFile

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. כדי לקבל את ה-UUID של צומת הגיבוי החדש, מריצים את פקודת ה-curl הבאה בצומת הגיבוי החדש:

   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 הראשי:

   /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 לכמה טבלאות בכל פעם.

שדרוג ל-ZooKeeper 3.8.5

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

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

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

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

יצירת גיבוי

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

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

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

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

1. אם הוא לא מותקן בצומת ZooKeeper, מתקינים את nc:

   yum install nc

2. מריצים את פקודת nc הבאה בצומת, כאשר 2181 הוא יציאת ZooKeeper:

   echo stat | nc localhost 2181

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

   Zookeeper version: 3.8.5-19f1842d4b6ee1f82cc8b05284959b26c6ae507d, built on 2025-09-03 21:35 UTC
   Clients:
    /[0:0:0:0:0:0:0:1]:40696[0](queued=0,recved=1,sent=0)
   
   Latency min/avg/max: 3/4.3333/6
   Received: 4
   Sent: 3
   Connections: 1
   Outstanding: 0
   Zxid: 0x500000005
   Mode: follower

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

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

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

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

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

2. משדרגים את הרכיב ZooKeeper:

   /opt/apigee/apigee-setup/bin/update.sh -c zk -f silent-config-file

   הערה: אם בצמתים האלה מותקנים רכיבים אחרים (כמו Cassandra), אפשר לשדרג גם אותם עכשיו (כמו בפרופיל zk,cs) או לשדרג את הרכיבים האחרים מאוחר יותר. ב-Apigee ממליצים לשדרג קודם רק את ZooKeeper ולוודא שהאשכול פועל כמו שצריך לפני שמשדרגים רכיבים אחרים.

3. חוזרים על השלבים שלמעלה בכל צומת של צופה ושל עוקב ב-ZooKeeper.

כיבוי המכשיר הראשי

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

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

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

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

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

שדרוג המנהל

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

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

שדרוג ל-Cassandra 5.0.8

גרסה 4.54.00 של Apigee Edge for Private Cloud כוללת שדרוג של Cassandra לגרסה 5.0.8.

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

• השדרוג מ-Cassandra 4.0.X ל-Cassandra 5.0.X הוא תהליך הדרגתי.

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

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

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

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

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

מספר מרכזי נתונים

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

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

שיטת השדרוג המומלצת

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

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

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

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

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

תהליך של נקודת ביקורת לחזרה למצב קודם

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

דוגמה

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

1. מצב התחלתי: צמתי Cassandra בשני מרכזי הנתונים הם בגרסה 4.0.X. כל שאר הצמתים הם בגרסה 4.54.00 של Edge for Private Cloud. נניח שיש שלושה צומתי Cassandra לכל מרכז נתונים.

2. שדרוג DC-1: משדרגים את שלושת צמתי Cassandra ב-DC-1 אחד אחרי השני.

3. השהיה ואימות: השהיה כדי לוודא שהאשכול, במיוחד DC-1, פועל בצורה תקינה (בדיקת הביצועים והפונקציונליות). אתם יכולים לחזור למצב הראשוני באמצעות צומתי Cassandra ב-DC-2. חשוב לזכור שההשהיה הזו חייבת להיות זמנית בגלל המגבלות של אשכול Cassandra עם גרסאות מעורבות.

4. שדרוג DC-2: משדרגים את שלושת צמתי Cassandra שנותרו ב-DC-2. אחרי שכל צומתי Cassandra ב-DC-2 שודרגו, השדרוג של Edge for Private Cloud 4.54.00 הושלם.

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

אתם צריכים להשתמש ב-Cassandra 4.0.X עם Edge for Private Cloud 4.53.00 (או) 4.53.01 ולוודא את הדברים הבאים:

1. מגדירים את Java 17 כגרסת ברירת המחדל של Java בשרת: ב-Cassandra 5.0.X אין תמיכה ב-Java 8. אי אפשר להריץ את Cassandra 5.0.X או את כלי השירות nodetool שלה עם Java 8. לפני שמפעילים את שלבי השדרוג של Cassandra, צריך לוודא ש-Java 17 מותקנת בכל צומת של Cassandra ולהגדיר את Java 17 כגרסת ברירת המחדל של Java, כדי שפקודות nodetool יופעלו באמצעות Java 17:

   alternatives --set java JAVA_17_PATH/bin/java

   מוודאים שגרסת ברירת המחדל הפעילה של Java היא Java 17:

   java -version

2. האשכול כולו פועל באופן מלא עם Cassandra 4.0.X.

3. אסטרטגיית הדחיסה מוגדרת ל-LeveledCompactionStrategy (תנאי מוקדם לשדרוג לגרסה 4.53.00 או 4.53.01).

4. מוודאים שכל אחד מהשלבים הבאים הושלם כחלק מהשדרוג הראשוני של Cassandra 4.0.X ב-Edge for Private Cloud בגרסה 4.53.00 (או) 4.53.01.

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

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

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

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

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

1. גיבוי Cassandra באמצעות Apigee.

2. יוצרים תמונות מצב של מכונות וירטואליות של צומתי Cassandra (אם אפשר).

3. אם עדיין לא הגדרתם את יציאה 9042, ודאו שהיא נגישה מכל הרכיבים של Edge for Private Cloud, כולל שרת הניהול, מעבד ההודעות, הנתב, Qpid ו-Postgres, לצמתים של Cassandra. מידע נוסף זמין בקטע דרישות לגבי יציאות.

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

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

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

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.2.0 | Cassandra 5.0.8 | CQL spec 3.4.7 | Native protocol v5]
   Metadata is verified

4. מריצים את הפקודה הבאה אחרי השדרוג בצומת 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 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 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 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 cache cache_entries cache_entries_cache_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 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

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

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

• הסרת Apigee mTLS .

• התקנה מחדש של Apigee mTLS .

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

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

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

4. צריך לוודא שהנתב זמין שוב.

5. חוזרים על שלבים 2 עד 4 בשאר הנתבים.

6. ממשיכים את העדכון בכל המחשבים שנותרו בהתקנה.

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

• בצומת משולב של נתב ומעבד בקשות:

  • לפני העדכון – מבצעים את הפעולות הבאות:

    1. הגדרת הנתב כלא נגיש.

    2. לוודא שמעבד ההודעות לא נגיש.

  • אחרי העדכון – מבצעים את הפעולות הבאות:

    1. הגדרת הגישה למעבד הבקשות.

    2. הגדרת הנתב כנגיש.

• בצמתי נתב יחידים:

  • לפני העדכון, צריך להגדיר את הנתב כלא נגיש.

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

• בצמתים של מעבד הודעות יחיד:

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

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

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

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

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

כדי לעדכן את רכיבי Edge בצומת:

1. אם יש משימות cron שמוגדרות לבצע פעולת תיקון ב-Cassandra, צריך להשבית אותן עד לסיום העדכון.

2. מתחברים לצומת בתור root כדי להתקין את חבילות ה-RPM של Edge.

   הערה: התקנת RPM דורשת גישת root, אבל אפשר לבצע הגדרה של Edge בלי גישת root.

3. משביתים את SELinux כמו שמתואר במאמר התקנת כלי השירות apigee-setup של Edge .

4. אם אתם מתקינים ב-AWS , מריצים את הפקודות הבאות של yum-configure-manager:

   yum update rh-amazon-rhui-client.noarch
   yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

5. אם אתם משתמשים כרגע ב-Edge for Private Cloud בגרסה 4.53.00 או 4.53.01:

   1. מורידים את קובץ Edge bootstrap_4.54.00.sh אל /tmp/bootstrap_4.54.00.sh :

      curl https://software.apigee.com/bootstrap_4.54.00.sh -o /tmp/bootstrap_4.54.00.sh

   2. מתקינים את כלי השירות apigee-service של Edge 4.54.00 ואת יחסי התלות שלו באמצעות הפקודה הבאה:

      bash /tmp/bootstrap_4.54.00.sh apigeeuser=uName apigeepassword=pWord

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

      כברירת מחדל, תוכנת ההתקנה בודקת אם גרסאות Java 17 ו-21 מותקנות.

   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 שרוצים לעדכן. הערכים האפשריים כוללים:

        • ‫edge : כל רכיבי Edge מלבד ממשק המשתמש החדש של Edge: שרת הניהול, מעבד ההודעות, הנתב, שרת QPID, שרת Postgres

        • ‫ldap : OpenLDAP

        • ‫ue : ממשק משתמש חדש של Edge

        • ‫qpid : Apigee Qpid

        • ps : Apigee Postgresql

        • ‫zk : ZooKeeper

        • cs : Cassandra

      • ‫configFile הוא אותו קובץ תצורה שבו השתמשתם כדי להגדיר את רכיבי Edge במהלך ההתקנה של גרסה 4.53.00 (או) 4.53.01.

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

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

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

      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

   8. כדי לבדוק את העדכון, מריצים את הכלי apigee-validate בשרת הניהול, כמו שמתואר בקטע בדיקת ההתקנה.

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

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

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

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

• יוצרים קובץ ‎ .tar של המאגר, מעתיקים את קובץ ה-‎ .tar לצומת ואז מעדכנים את Edge מקובץ ה-‎ .tar.

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

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

1. יוצרים מאגר מקומי בגרסה 4.54.00 כמו שמתואר במאמר בנושא יצירת מאגר Apigee מקומי בקטע התקנת כלי ההגדרה של Edge apigee-setup.

2. מתקינים את apigee-service בצומתי היעד באחת מהשיטות הבאות:

   • אפשרות 1: התקנה של apigee-service מקובץ ‎ .tar

     1. בצומת עם המאגר המקומי, משתמשים בפקודה הבאה כדי לארוז את המאגר המקומי לקובץ ‎ .tar יחיד בשם /opt/apigee/data/apigee-mirror/apigee-4.54.00.tar.gz:

        /opt/apigee/apigee-service/bin/apigee-service apigee-mirror package

     2. מעתיקים את קובץ ה-‎ .tar לצומת שבו רוצים לעדכן את Edge. לדוגמה, מעתיקים אותו לספרייה /tmp בצומת החדש.

     3. בצומת החדש, מבטלים את הדחיסה של הקובץ בספרייה /tmp:

        tar -xzf apigee-4.54.00.tar.gz

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

     4. מתקינים את כלי השירות apigee-service של Edge ואת יחסי התלות מ-/tmp/repos:

        bash /tmp/repos/bootstrap_4.54.00.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos

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

   • אפשרות 2: התקנת apigee-service באמצעות שרת האינטרנט Nginx

     1. מגדירים את שרת האינטרנט Nginx כמו שמתואר במאמר בנושא התקנה ממאגר באמצעות שרת האינטרנט Nginx.

     2. בצומת המרוחק, מורידים את קובץ ה-Edge bootstrap_4.54.00.sh אל /tmp/bootstrap_4.54.00.sh:

        /usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.54.00.sh -o /tmp/bootstrap_4.54.00.sh

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

     3. בצומת המרוחק, מתקינים את כלי השירות Edge apigee-service ואת יחסי התלות:

        bash /tmp/bootstrap_4.54.00.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://

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

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 שרוצים לעדכן. הערכים האפשריים כוללים:

     • ‫edge : כל רכיבי Edge מלבד ממשק המשתמש החדש של Edge: שרת הניהול, מעבד ההודעות, הנתב, שרת QPID, שרת Postgres

     • ‫ldap : OpenLDAP

     • ‫ue : ממשק משתמש חדש של Edge

     • ‫qpid : Apigee Qpid

     • ps : Apigee Postgresql

     • ‫zk : ZooKeeper

     • ‫cs : Cassandra

   • ‫configFile הוא אותו קובץ תצורה שבו השתמשתם כדי להגדיר את רכיבי Edge במהלך ההתקנה של גרסה 4.53.00 (או) 4.53.01.

     הערה: קובץ התצורה צריך להיות קריא למשתמש apigee. כדי לשנות את הבעלים, משתמשים בפקודה הבאה:

     chown apigee:apigee configFile

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

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

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

   /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

8. כדי לבדוק את העדכון, מריצים את הכלי apigee-validate בשרת הניהול, כמו שמתואר בקטע בדיקת ההתקנה.

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

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

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

1. משדרגים את כל צומתי הנתבים ומעבדי ההודעות בכל מרכזי הנתונים באמצעות האפשרות -c edge.

2. משדרגים את כל הצמתים של שרת הניהול בכל מרכזי הנתונים באמצעות האפשרות -c edge.

3. משדרגים את כל צומתי ה-LDAP בכל מרכזי הנתונים. אם אתם משדרגים מ-Edge for Private Cloud 4.53.00, תצטרכו לבצע שלבים מיוחדים לשדרוג LDAP

4. שדרוג ממשק המשתמש ו-Apigee SSO (אם הוא מותקן) בכל מרכזי הנתונים:

   1. אם מודול SSO ב-Apigee לא מותקן: פועלים לפי אפשרות 1: שדרוג ממשק המשתמש (בלי מודול SSO ב-Apigee) כדי לשדרג לממשק המשתמש החדש של Edge.

   2. אם מודול SSO ב-Apigee מותקן: פועלים לפי אפשרות 2: שדרוג ממשק המשתמש (עם מודול SSO ב-Apigee) כדי לשדרג לממשק המשתמש החדש של Edge ולמודול SSO ב-Apigee.

5. משדרגים את כל רכיבי Qpid ו-edge-qpid-server בכל מרכזי הנתונים לפי השלבים המיוחדים של Qpid.

6. משדרגים את כל הרכיבים של Postgresql ו-edge-postgres-server בכל מרכזי הנתונים, לפי השלבים המיוחדים של Postgres.

7. משדרגים את כל רכיבי Zookeeper בכל מרכזי הנתונים לפי השלבים המיוחדים לשדרוג Zookeeper.

8. משדרגים את כל הרכיבים של Cassandra בכל מרכזי הנתונים לפי השלבים המיוחדים לשדרוג Cassandra.

9. אין שלב נפרד לעדכון המונטיזציה. הוא מתעדכן כשמציינים את האפשרות -c edge.

שדרוג של צומת אחד שנרכש בנפרד

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

כשמשדרגים מ-Edge for Private Cloud 4.53.00, צריך קודם לשדרג את LDAP לפי השלבים לשדרוג מ-4.53.00 ל-4.54.00, ורק אז להתחיל לשדרג את כל הרכיבים.

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. מעדכנים את הרכיבים של Edge במכונה 1:

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

2. מעדכנים את LDAP במחשב 1:

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

3. מעדכנים את ממשק המשתמש החדש של Edge במכונה 1:

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

4. מעדכנים את הרכיבים של Edge במכונה 2:

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

5. מעדכנים את Qpid במכונה 2:

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

6. מעדכנים את Postgres במכונה 2:

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

7. מעדכנים את Cassandra ו-ZooKeeper במכונה 1:

   /opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

8. (אם התקנתם את apigee-adminapi) מעדכנים את כלי השירות apigee-adminapi במכונה 1:

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

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

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

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

1. מעדכנים את הרכיבים של Edge במכונות 2, 3, 1:

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

2. עדכון LDAP במכונה 1:

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

3. מעדכנים את ממשק המשתמש החדש של Edge במכונה 1:

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

4. מעדכנים את רכיבי Edge במכונות 4 ו-5:

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

5. מעדכנים את Qpid במכונות 4 ו-5:

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

6. מעדכנים את Postgres במכונות 4 ו-5:

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

7. מעדכנים את Cassandra ואת ZooKeeper במכונות 1, 2 ו-3:

   /opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

8. (אם התקנתם את apigee-adminapi) מעדכנים את כלי השירות apigee-adminapi במכונה 1:

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

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

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

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

1. מעדכנים את רכיבי Edge במכונות 4, 5 ו-1 (router,‏ message-processor ו-management-server) בסדר הזה:

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

2. מעדכנים את LDAP במחשב 1:

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

3. מעדכנים את ממשק המשתמש החדש של Edge במכונה 1:

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

4. מעדכנים את רכיבי Edge במכונות 6, 7, 8 ו-9 לפי הסדר הזה:

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

5. מעדכנים את Qpid במכונות 6 ו-7:

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

6. מעדכנים את Postgres במכונה 8:

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

7. עדכון Postgres במכונה 9:

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

8. מעדכנים את Cassandra ו-ZooKeeper במכונות 1, 2 ו-3:

   /opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

9. (אם התקנתם את apigee-adminapi) מעדכנים את כלי השירות apigee-adminapi במכונה 1:

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

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

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

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

1. מעדכנים את הרכיבים של Edge במכונות 10, 11, 6 ו-7 בסדר הזה:

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

2. מעדכנים את LDAP במכונות 4 ו-5:

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

3. מעדכנים את ממשק המשתמש החדש של Edge במכונות 6 ו-7:

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

4. מעדכנים את רכיבי Edge במכונות 12, 13, 8 ו-9 בסדר הזה:

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

5. מעדכנים את Qpid במכונות 12 ו-13:

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

6. עדכון Postgres במכונה 8:

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

7. עדכון Postgres במכונה 9:

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

8. מעדכנים את Cassandra ואת ZooKeeper במכונות 1, 2 ו-3:

   /opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

9. (אם התקנתם את apigee-adminapi) מעדכנים את כלי השירות apigee-adminapi במכונות 6 ו-7:

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

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

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

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

1. מעדכנים את הרכיבים של Edge (נתב ומעבד בקשות):

   • במכונות 2 ו-3 במרכז הנתונים 1:

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

   • במכונות 8 ו-9 במרכז נתונים 2:

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

2. מעדכנים את הרכיבים של Edge (שרת הניהול):

   • במכונה 1 במרכז הנתונים 1:

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

   • במכונה 7 במרכז הנתונים 2:

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

3. עדכון LDAP:

   • מכונה 1 במרכז נתונים 1:

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

   • מכונה 7 במרכז נתונים 2:

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

4. מעדכנים את הרכיבים של ממשק המשתמש החדש של Edge:

   • במכונה 1 במרכז הנתונים 1:

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

   • במכונה 7 במרכז נתונים 2:

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

5. מעדכנים את רכיבי Edge:

   • מכונות 4, 5 ו-6 במרכז הנתונים 1:

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

   • מכונות 10, 11, 12 במרכז נתונים 2:

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

6. עדכון qpidd:

   • מכונות 4 ו-5 במרכז הנתונים 1:

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

   • מכונות 10 ו-11 במרכז נתונים 2:

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

7. עדכון Postgres:

   • מכונה 6 במרכז נתונים 1:

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

   • מכונה 12 במרכז נתונים 2:

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

8. מעדכנים את Cassandra ו-ZooKeeper:

   • מכונות 1, 2 ו-3 במרכז נתונים 1:

     /opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

   • במכונות 7, 8 ו-9 במרכז נתונים 2:

     /opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

9. (אם התקנתם את apigee-adminapi) מעדכנים את כלי השירות apigee-adminapi:

   • מכונה 1 במרכז נתונים 1:

     /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

   • מכונה 7 במרכז הנתונים 2:

     /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

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

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

1. נתב

2. מעבד בקשות

3. שרת ניהול

4. LDAP

5. ממשק המשתמש (הקלאסי או החדש)

6. SSO (אם רלוונטי)

7. ‫Qpid ו-edge-qpid-server

8. ‫Postgres ו-edge-postgres-server

9. ZooKeeper

10. Cassandra

11. apigee-adminapi