將 Apigee Edge 4.53.00 或 4.53.01 更新至 4.54.00

Apigee 支援直接從 4.53.00 或 4.53.01 版升級 Edge for Private Cloud 至 4.54.00 版。本頁說明如何執行這類升級。

如需相容升級路徑的總覽,請參閱 Edge for Private Cloud 版本升級相容性矩陣。

誰可以執行更新

執行更新作業的使用者應與原先安裝 Edge 的使用者相同,或以 root 身分執行。

安裝 Edge RPM 後,任何人都可以進行設定。

必須更新哪些元件

您必須更新所有 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 和 21。

  • 4.54.00 版的新版 Edge UI:瞭解如何改用新版 Edge UI 做為預設管理介面,以及如何移除傳統版 UI (edge-ui)。詳情請參閱「新版 Edge UI」。

  • 4.54.00 版的 Apigee SSO:瞭解更新後的 SSO 架構和驗證設定變更。詳情請參閱「Apigee SSO」。

  • 4.54.00 版中的 Nginx 1.30:查看 Edge 路由器上的 Nginx 1.30.x 自動升級、潛在執行階段影響和緩解步驟。詳情請參閱「Nginx 1.30 異動」。

升級必備條件

升級 Apigee Edge 前,請確認符合下列必要條件:

  • 查看版本資訊和新功能

    開始升級程序前,請務必詳閱並瞭解 Edge for Private Cloud 版本資訊中詳述的所有新功能、行為異動和淘汰項目。

  • 升級期間自動探索 Java 二進位檔並共存:使用標準套件管理工具 (例如 yum) 或標準位置 (例如 /usr/lib/jvm 或 update-alternatives) 安裝 Java。您不需要在系統 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 重新啟用。

自動套用資源設定

如果您曾透過編輯 /opt/apigee/customer/application 中的 .properties 檔案來設定任何屬性,更新後會保留這些值。

升級路由器和訊息處理器

逐一升級資料中心內的所有路由器和訊息處理器節點:

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

升級管理伺服器

逐一升級各資料中心的所有管理伺服器節點:

/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 部署拓撲:單一伺服器、主動-被動和主動-主動 (多主節點)。

準備和安裝 (所有 LDAP 伺服器)

升級至新版 Edge UI 和 Apigee SSO (如已安裝)

在 Apigee Edge for Private Cloud 4.54.00 中,傳統版 UI (edge-ui) 已移除,並由新版 Edge UI (edge-management-ui) 取代。視您的設定是否已安裝並使用 Apigee 單一登入 (SSO) 而定,請按照下列其中一個選項操作:

升級至 Qpid 10.0.1

這種方法可確保 Edge 執行階段環境不會停機,並盡可能減少用於分析的執行階段資料遺失。

如要就地升級至 Qpid,且不需停機,請按照下列步驟操作:

  1. 選擇一個 Qpid 節點開始。

  2. 停止節點上的 Qpid 訊息代理程式:

    apigee-service apigee-qpidd stop
  3. 套用防火牆,封鎖所有訊息處理器在代理程式通訊埠 5672 的傳入流量。您可以在 Qpid 節點執行個體或其他外部防火牆/網路元件層級套用這個防火牆。

    建議您對所有訊息處理器 IP 位址執行相同步驟。舉例來說,如要使用 IPTables 捨棄從訊息處理器 IP 位址傳送至通訊埠 5672 上 Qpid 節點的要求,可以使用下列指令:

    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 位址傳送至通訊埠 5672 上 Qpid 節點的要求。如果您使用 iptables 新增防火牆,可以使用下列指令移除防火牆,並列出現有設定:

    iptables -F
    iptables -L
  10. 使用網頁監控功能,確認 Qpid 佇列是否收到訊息:

    http://QPID_NODE_IP:8090
  11. 針對每個 Qpid 節點重複執行步驟 1 至 9。

升級至 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 的 1 節點和 2 節點設定中,用於原型設計和測試的拓撲只有一個 Postgres 節點。您可以直接更新這些 Postgres 節點,不必建立新的 Postgres 節點。

  • 如果您按照 Apigee 的建議,為 Postgres 節點使用網路儲存空間,就不必安裝新的 Postgres 節點。在下列程序中,您可以略過指定安裝和停用新 Postgres 待命節點的步驟。開始更新程序前,請先為 Postgres 使用的資料儲存庫建立網路快照。這樣一來,如果更新期間發生任何錯誤,而您必須復原,就可以從該快照還原 Postgres 節點。

安裝新的 Postgres 待命節點

這項程序會在新的節點上建立 Postgres 待命伺服器。請務必為「現有」Edge 版本 (4.53.00 或 4.53.01) 安裝新的 Postgres 待命伺服器,而非 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 是目前 Postgres 待命伺服器的 IP 位址,new_standby_ip 則是新待命節點的 IP 位址。

  2. 在 Postgres 主要節點上重新啟動 apigee-postgresql:

    /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. 按照「安裝 Edge apigee-setup 公用程式」一文中的說明停用 SELinux。

    3. 根據目前的 Edge 版本,下載並執行 Bootstrap 指令碼:

      • 如果您目前使用的是 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

        安裝 Edge apigee-service 公用程式和依附元件:

        bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
      • 如果您目前使用的是 Edge 4.53.01:

        將 Edge bootstrap_4.53.01.sh 檔案下載到 /tmp/bootstrap_4.53.01.sh:

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

        安裝 Edge apigee-service 公用程式和依附元件:

        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. 在新的待命節點上執行下列指令,確認該節點為待命節點:

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

執行 Postgres 就地升級

初步步驟

在主要主機和待命主機上執行下列步驟,更新 apigee-postgresql 的 max_locks_per_transaction 屬性,然後再就地升級至 Postgres:

  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. 從主要主機和待命主機的 /opt/apigee/customer/application/postgresql.properties 檔案中移除 conf/postgresql.conf+max_locks_per_transaction=30000 行。這行程式碼是在前置步驟中新增。

    完成這項程序後,待命執行個體就會成功啟動。

停用 Postgres 節點

更新完成後,請停用新的待命節點:

  1. 確認 Postgres 正在運作:

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

    如果 Postgres 未執行,請啟動:

    /opt/apigee/apigee-service/bin/apigee-all start
  2. 在新的待命節點上執行下列 curl 指令,取得新待命節點的 UUID:

    curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

    輸出內容結尾應會顯示節點的 UUID,格式如下:

    "type" : [ "postgres-server" ],
    "uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
  3. 在新待命節點上執行下列指令,停止新待命節點:

    /opt/apigee/apigee-service/bin/apigee-all stop
  4. 在 Postgres 主要節點上,編輯 /opt/apigee/customer/application/postgresql.properties,從 conf_pg_hba_replication.connection 移除新的待命節點:

    conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust
  5. 在 Postgres 主要節點上重新啟動 apigee-postgresql:

    /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. 在管理伺服器節點上發出下列 Edge Management API 呼叫,從 ZooKeeper 刪除待命節點的 UUID:

    curl -u sysAdminEmail:password -X DELETE http://ms_IP:8080/v1/servers/new_standby_uuid

Postgres 升級後的步驟

Postgres 進行重大升級後,內部的統計資料會遭到清除。Postgres 查詢規劃器會運用這些統計資料,找出最合適的索引和路徑來執行查詢。

Postgres 會在執行查詢和 autovacuum daemon 時,逐步重建統計資料。不過,在統計資料重建完成前,查詢速度可能會變慢。

如要解決這個問題,請在主要 Postgres 節點上,對資料庫中的所有資料表執行 ANALYZE。或者,您也可以一次對幾個資料表執行 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 的 Deployment 作業),以及 Apigee 基礎架構變更 (例如新增或移除訊息處理器等)。按照下列程序升級 ZooKeeper 時,Apigee 的執行階段 API 應該不會受到影響 (除非這些執行階段 API 呼叫 Management API)。

概略來說,升級程序包含備份每個節點。接著升級所有觀察者和追蹤者,最後升級領導者節點。

備份

備份 ZooKeeper 的所有節點,以便在需要復原時使用。請注意,復原作業會將 ZooKeeper 還原至備份時的狀態。

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

如果您使用虛擬機器且具備相關功能,也可以建立 VM 快照或備份,以便在必要時還原或復原。

找出領導者、追隨者和觀察者

  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 行中,您應該會看到觀察者、領導者或追隨者 (即非領導者的投票者),具體取決於節點設定。

  1. 在每個 ZooKeeper 節點上重複步驟 1 和 2。

升級觀察器和追蹤器節點上的 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 基礎架構變更,例如新增或移除訊息處理器等。

確認已選出新的領導者

按照上方「找出領導者、追隨者和觀察者 」一節的步驟操作,確認現有領導者停止後,追隨者是否選出新的領導者。請注意,選出的領導者可能與目前的領導者位於不同的資料中心。

升級領導者

按照上述「在觀察器和追蹤器節點上升級 ZooKeeper」一節中的步驟操作。

舊的領導者節點也升級後,請確認叢集健康狀態,並確保有領導者節點。

升級至 Cassandra 5.0.8

Apigee Edge for Private Cloud 4.54.00 將 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 時,才能復原至先前的 Cassandra 版本。

  4. 時效性:雖然您可以暫停一小段時間 (建議幾小時) 來驗證功能,但不能無限期維持混合版本狀態。這是因為非統一的 Cassandra 叢集 (節點版本不同) 有作業限制。

  5. 全面測試:Apigee 強烈建議您在升級下一個資料中心前,全面測試效能和功能。所有資料中心都升級後,就無法復原至舊版。

復原查核點程序

單一復原檢查點:所有元件都升級至 4.54.00 後,只有在至少一個 Cassandra 資料中心繼續執行舊版本時,才能復原 Cassandra。最後一個 Cassandra 資料中心升級後,Edge for Private Cloud 4.54.00 的升級作業即完成,且無法復原。

範例

假設有一個雙資料中心 (DC) 叢集:

  1. 初始狀態:兩個資料中心的 Cassandra 節點都採用 4.0.X 版。所有其他節點都位於 Edge for Private Cloud 4.54.00 版。假設每個 DC 有三個 Cassandra 節點。

  2. 升級 DC-1:逐一升級 DC-1 中的三個 Cassandra 節點。

  3. 暫停並驗證:暫停作業,確保叢集 (尤其是 DC-1) 正常運作 (檢查效能和功能)。您可以使用 DC-2 中的 Cassandra 節點復原至初始狀態。請注意,由於混合版本 Cassandra 叢集的限制,這項暫停作業必須是暫時性的。

  4. 升級 DC-2:升級 DC-2 中剩餘的三個 Cassandra 節點。DC-2 中的所有 Cassandra 節點都成功升級後,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 支援。您無法透過 Java 8 執行 Cassandra 5.0.X 或其 nodetool 公用程式。請確認每個 Cassandra 節點都已安裝 Java 17,並將 Java 17 設為預設 Java 版本,再執行 Cassandra 升級步驟,以便使用 Java 17 執行 nodetool 指令:

    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. 確認在 Edge for Private Cloud 4.53.00 (或 4.53.01) 中,Cassandra 4.0.X 的初始升級作業已完成下列步驟。

    • 上次升級期間,每個 Cassandra 節點都執行了 post_upgrade 指令

    • 在先前的升級作業中,系統已對整個 Cassandra 叢集執行 drop_old_tables 指令。

如果您不確定在使用 Edge for Private Cloud 4.53.00 (或 4.53.01) 時,是否已在 Cassandra 4.0.X 執行 post_upgrade 和 drop_old_tables 指令,可以先重新執行這些指令,再嘗試升級至 4.54.00。

步驟 1:準備升級

除了您通常會建立的標準檔案 (例如用於啟用元件升級的 Apigee 標準設定檔) 之外,您還需要執行下列步驟。

  1. 使用 Apigee 備份 Cassandra。

  2. 建立 Cassandra 節點的 VM 快照 (如果可行)。

  3. 如果尚未設定,請確認所有 Edge for Private Cloud 元件 (包括 Management Server、訊息處理器、Router、Qpid 和 Postgres) 都能透過通訊埠 9042 存取 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 節點上執行下列 post_upgrade 指令:

    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade
  5. 在 Cassandra 節點上執行下列 cleanup_old_index 指令:

    /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,請按照下列步驟操作:

復原更新

如果更新失敗,您可以嘗試修正問題,然後再次執行 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 設定都會在同一個節點上顯示路由器和訊息處理器。

  4. 讓路由器恢復連線。

  5. 對其餘路由器重複步驟 2 到 4。

  6. 繼續更新安裝作業中的其餘機器。

請在更新前後留意下列事項:

使用靜音設定檔

您必須將自動設定檔傳遞至更新指令。雖然自動設定檔與您用來安裝 Edge for Private Cloud 4.53.00 或 4.53.01 的檔案大致相似,但您可能需要變更 UI 和 SSO 等元件,詳情請參閱「升級至新版 Edge UI 和 Apigee SSO (如已安裝)」。

在具備外部網際網路連線的節點上更新至 4.54.00

請按照下列程序更新節點上的 Edge 元件:

  1. 如果有的話,請停用任何設定為在 Cassandra 上執行修復作業的 cron 工作,直到更新完成為止。

  2. 以 root 身分登入節點,安裝 Edge RPM。

    注意:雖然 RPM 安裝需要根層級存取權,但您可以在沒有根層級存取權的情況下執行 Edge 設定。

  3. 按照「安裝 Edge apigee-setup 公用程式」一文中的說明停用 SELinux。

  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. 執行下列指令,安裝 Edge 4.54.00 apigee-service 公用程式和依附元件:

      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 UI 以外的所有 Edge 元件:管理伺服器、訊息處理器、路由器、QPID 伺服器、Postgres 伺服器

        • ldap:OpenLDAP

        • ue:新版 Edge UI

        • qpid:Apigee Qpid

        • ps:Apigee Postgresql

        • zk:ZooKeeper

        • cs:Cassandra

      • configFile 是您在 4.53.00 (或) 4.53.01 安裝期間,用來定義 Edge 元件的設定檔。

      您可以將 component 設為「all」,對所有元件執行 update.sh,但前提是您必須具備 Edge all-in-one (AIO) 安裝設定檔。例如:

      /opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
    7. 在所有執行新版 Edge UI 元件的節點上,重新啟動這些元件 (如果尚未這麼做):

      /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 檔案複製到節點,然後從 .tar 檔案更新 Edge。

  • 在本機存放區的節點上安裝網路伺服器,讓其他節點可以存取。Apigee 提供 Nginx 網路伺服器,您也可以使用自己的網路伺服器。

如要從本機 4.54.00 存放區更新:

  1. 按照「安裝 Edge apigee-setup 公用程式」中的「建立本機 Apigee 存放區」一節,建立本機 4.54.00 存放區。

  2. 使用下列任一方法,在目標節點上安裝 apigee-service:

    • 方法 1:從 .tar 檔案安裝 apigee-service

      1. 在本機存放區所在的節點上,使用下列指令將本機存放區封裝成名為 /opt/apigee/data/apigee-mirror/apigee-4.54.00.tar.gz 的單一 .tar 檔案:

        /opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
      2. 將 .tar 檔案複製到要更新 Edge 的節點。例如,將其複製到新節點上的 /tmp 目錄。

      3. 在新節點上,將檔案解壓縮至 /tmp 目錄:

        tar -xzf apigee-4.54.00.tar.gz

        這個指令會在包含 .tar 檔案的目錄中,建立名為 repos 的新目錄。例如 /tmp/repos。

      4. 從 /tmp/repos 安裝 Edge apigee-service 公用程式和依附元件:

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

        請注意,您在這個指令中加入了 repos 目錄的路徑。

    • 方法 2:使用 Nginx 網路伺服器安裝 apigee-service

      1. 按照「安裝 Edge apigee-setup 公用程式」一文中的「使用 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 UI 以外的所有 Edge 元件:管理伺服器、訊息處理器、路由器、QPID 伺服器、Postgres 伺服器

      • ldap:OpenLDAP

      • ue:新版 Edge UI

      • qpid:Apigee Qpid

      • ps:Apigee Postgresql

      • zk:ZooKeeper

      • cs:Cassandra

    • configFile 是您在 4.53.00 (或) 4.53.01 安裝期間,用來定義 Edge 元件的設定檔。

      注意:設定檔必須可供「apigee」使用者讀取。如要變更擁有者,請使用下列指令:

      chown apigee:apigee configFile

    您可以將 component 設為「all」,對所有元件執行 update.sh,但前提是您必須具備 Edge all-in-one (AIO) 安裝設定檔。例如:

    /opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
  7. 如果尚未重新啟動所有執行 UI 元件的節點,請重新啟動:

    /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. 在所有資料中心升級 UI 和 Apigee SSO (如有安裝):

    1. 如果未安裝 apigee-sso:請按照「選項 1:升級 UI (不含 Apigee SSO)」一節的說明,升級至新版 Edge UI。

    2. 如果已安裝 apigee-sso:請按照「選項 2:升級 UI (使用 Apigee SSO)」一節的步驟,升級至新版 Edge UI 和 Apigee SSO。

  5. 按照 Qpid 的特殊步驟,升級所有資料中心的所有 Qpid 和 edge-qpid-server 元件。

  6. 按照 Postgres 的特殊步驟,升級所有資料中心的所有 Postgresql 和 edge-postgres-server 元件

  7. 按照 Zookeeper 升級的特殊步驟,升級所有資料中心的所有 Zookeeper 元件。

  8. 按照升級 Cassandra 的特殊步驟,升級所有資料中心的所有 Cassandra 元件。

  9. 您不需要另外更新營利功能。指定 -c edge 選項時,系統會更新這個值。

1 節點獨立升級

如要將 1 節點獨立設定升級至 4.54.00:

從 Edge for Private Cloud 4.53.00 升級時,必須先按照從 4.53.00 升級至 4.54.00 的步驟升級 LDAP,再開始升級所有元件。

  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. 更新機器 1 上的 Edge 元件:

    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  2. 在機器 1 上更新 LDAP:

    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  3. 在機器 1 上更新新版 Edge UI:

    /opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
  4. 更新機器 2 上的 Edge 元件:

    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  5. 在機器 2 上更新 Qpid:

    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  6. 更新機器 2 上的 Postgres:

    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  7. 在機器 1 上更新 Cassandra 和 ZooKeeper:

    /opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile
  8. (如果您已安裝 apigee-adminapi) 在機器 1 上更新 apigee-adminapi 公用程式:

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

5 節點升級

更新下列元件,以便安裝 5 個節點:

如需 Edge 拓撲和節點編號清單,請參閱「安裝拓撲」。

  1. 更新機器 2、3、1 上的 Edge 元件:

    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  2. 在機器 1 上更新 LDAP:

    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  3. 在機器 1 中更新新版 Edge UI:

    /opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
  4. 更新機器 4、5 上的 Edge 元件:

    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  5. 在機器 4、5 上更新 Qpid:

    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  6. 在機器 4、5 上更新 Postgres:

    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  7. 在機器 1、2 和 3 上更新 Cassandra 和 ZooKeeper:

    /opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile
  8. (如果您已安裝 apigee-adminapi) 在機器 1 上更新 apigee-adminapi 公用程式:

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

9 節點叢集升級

更新下列元件,以便安裝 9 節點叢集:

如需 Edge 拓撲和節點編號清單,請參閱「安裝拓撲」。

  1. 依序更新機器 4、5 和 1 (路由器、訊息處理器和管理伺服器) 上的 Edge 元件:

    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  2. 在機器 1 上更新 LDAP:

    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  3. 在機器 1 中更新新版 Edge UI:

    /opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
  4. 依序更新機器 6、7、8 和 9 上的 Edge 元件:

    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  5. 在機器 6 和 7 上更新 Qpid:

    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  6. 在機器 8 上更新 Postgres:

    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  7. 在機器 9 上更新 Postgres:

    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  8. 在機器 1、2 和 3 上更新 Cassandra 和 ZooKeeper:

    /opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile
  9. (如果您已安裝 apigee-adminapi) 在機器 1 上更新 apigee-adminapi 公用程式:

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

13 節點叢集升級

如要安裝 13 節點叢集,請更新下列元件:

如需 Edge 拓撲和節點編號清單,請參閱「安裝拓撲」。

  1. 依序更新機器 10、11、6 和 7 上的 Edge 元件:

    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  2. 在機器 4 和 5 上更新 LDAP:

    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  3. 在機器 6、7 中更新新版 Edge UI:

    /opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
  4. 依序更新機器 12、13、8 和 9 上的 Edge 元件:

    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  5. 更新機器 12 和 13 上的 Qpid:

    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  6. 在機器 8 上更新 Postgres:

    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  7. 在機器 9 上更新 Postgres:

    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  8. 在機器 1、2 和 3 上更新 Cassandra 和 ZooKeeper:

    /opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile
  9. (如果您已安裝 apigee-adminapi) 在機器 6 和 7 上更新 apigee-adminapi 公用程式:

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

12 節點叢集升級

如要安裝 12 節點叢集,請更新下列元件:

如需 Edge 拓撲和節點編號清單,請參閱「安裝拓撲」。

  1. 更新 Edge (路由器和訊息處理器) 元件:

    • 在資料中心 1 的機器 2、3 上:

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
    • 在資料中心 2 的機器 8、9 上:

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  2. 更新 Edge (Management Server) 元件:

    • 在資料中心 1 的機器 1 上:

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
    • 在資料中心 2 的機器 7 上:

      /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
    • 資料中心 2 的機器 7:

      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  4. 更新 New Edge UI 元件:

    • 在資料中心 1 的機器 1 上:

      /opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
    • 在資料中心 2 的機器 7 上:

      /opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
  5. 更新 Edge 元件:

    • 資料中心 1 的機器 4、5、6:

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
    • 資料中心 2 的機器 10、11、12:

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  6. 更新 qpidd:

    • 資料中心 1 的機器 4、5:

      /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
    • 資料中心 2 的機器 10、11:

      /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  7. 更新 Postgres:

    • 資料中心 1 的機器 6:

      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
    • 資料中心 2 的機器 12:

      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  8. 更新 Cassandra 和 ZooKeeper:

    • 資料中心 1 的機器 1、2 和 3:

      /opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile
    • 在資料中心 2 的機器 7、8 和 9 上:

      /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
    • 資料中心 2 的機器 7:

      /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