עדכון של 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, צריך לוודא שעומדים בדרישות המוקדמות הבאות:

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

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

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

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

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

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

# 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 של מעבדי הבקשות. לדוגמה, כדי להשתמש ב-IPTables כדי לבטל (DROP) בקשות שמגיעות מכתובות IP של מעבד הבקשות לצומת Qpid ביציאה 5672, אפשר להשתמש בפקודה כמו זו:

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

4. מפעילים מחדש את ה-broker של 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:

        מורידים את הקובץ bootstrap_4.53.00.sh של Edge אל /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 בצומת של Management Server:

   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 בכל אחד מהצמתים של הצופים והעוקבים באופן הבא:

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.

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

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

/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, כולל Management Server, ‏ מעבד בקשות, ‏ Router, ‏ 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. מריצים את הפקודה 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 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 נכשל.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    2. הופכים את מעבד הבקשות ללא נגיש.

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

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

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

• בצומתי Router בודדים:

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

  • אחרי העדכון, מגדירים את הנתב כך שיהיה נגיש.

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

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

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

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

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

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

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

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

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

   הערה: למרות שהתקנת 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. מורידים את קובץ bootstrap_4.54.00.sh של Edge אל /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, תתבקשו להזין אותו.

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

        • ‫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 מקומי" במאמר התקנת כלי השירות apigee-setup של Edge.

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" במאמר התקנת כלי השירות apigee-setup של Edge.

     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. משדרגים את ממשק המשתמש ואת מודול ה-SSO ב-Apigee (אם הוא מותקן) בכל מרכזי הנתונים:

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

   2. אם apigee-sso מותקן: פועלים לפי אפשרות 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