Aggiorna Apigee Edge 4.52.02 o 4.53.00 alla versione 4.53.01

Apigee supporta l'upgrade di Edge for Private Cloud direttamente dalla versione 4.52.02 o 4.53.00 alla versione 4.53.01. Questa pagina descrive come eseguire questi upgrade.

Per una panoramica dei percorsi di upgrade compatibili, consulta la matrice di compatibilità degli upgrade per le release di Edge for Private Cloud.

Chi può eseguire l'aggiornamento

La persona che esegue l'aggiornamento deve essere la stessa che ha installato originariamente Edge o una persona che esegue l'accesso come root.

Dopo aver installato gli RPM di Edge, chiunque può configurarli.

Quali componenti devi aggiornare

Devi aggiornare tutti i componenti di Edge. Edge non supporta una configurazione che contiene componenti di più versioni.

Aggiorna i prerequisiti

Esamina le modifiche in Edge for Private Cloud 4.53.01

In questa versione sono stati risolti diversi problemi di sicurezza. Sebbene questi miglioramenti della sicurezza siano essenziali, introducono alcune modifiche che non sono compatibili con le versioni precedenti. Ciò significa che l'upgrade richiederà passaggi aggiuntivi per garantire che non si verifichino interruzioni durante o dopo l'upgrade. Per ulteriori informazioni, esamina attentamente questo argomento durante l'upgrade alla versione 4.53.01 dalle versioni precedenti di private cloud.

Prima di eseguire l'upgrade di Apigee Edge, assicurati che siano soddisfatti i seguenti prerequisiti:

  • Esegui il backup di tutti i nodi
    Prima di eseguire l'aggiornamento, ti consigliamo di eseguire un backup completo di tutti i nodi per motivi di sicurezza. Per eseguire il backup, utilizza la procedura per la tua versione attuale di Edge.

    In questo modo, avrai un piano di backup nel caso in cui l'aggiornamento a una nuova versione non funzioni correttamente. Per ulteriori informazioni sul backup, vedi Backup e ripristino.

  • Assicurati che Edge sia in esecuzione
    Assicurati che Edge sia in esecuzione durante il processo di aggiornamento utilizzando il comando: 
    /opt/apigee/apigee-service/bin/apigee-all status
  • Verifica i prerequisiti di Cassandra

    Se in precedenza hai eseguito l'upgrade da una versione precedente di Edge for Private Cloud alla versione 4.52.02 e ora prevedi di eseguire l'upgrade alla versione 4.53.01, assicurati di aver completato i passaggi post-upgrade richiesti per Cassandra. Questi passaggi sono descritti nella documentazione di upgrade alla versione 4.52.02 e sono menzionati anche nella sezione Prerequisiti per l'upgrade di Cassandra. Se non hai la certezza che questi passaggi siano stati completati durante l'upgrade precedente, completali di nuovo prima di procedere con l'upgrade alla versione 4.53.01.

  • Configurazione di chiavi e certificati IdP in Edge for Private Cloud 4.53.01

    In Edge for Private Cloud 4.53.01, le chiavi e i certificati IDP utilizzati nel componente apigee-sso vengono ora configurati tramite un archivio chiavi. Dovrai esportare la chiave e il certificato che hai utilizzato in precedenza in un keystore. Segui i passaggi descritti nella sezione Passaggi per l'aggiornamento di Apigee SSO dalle versioni precedenti per i passaggi dettagliati prima di aggiornare il componente SSO.

  • Requisiti di Python
    Assicurati che su tutti i nodi, inclusi quelli Cassandra, sia installato Python 3 prima di tentare l'upgrade.

Quali passaggi speciali considerare per l'upgrade

Per eseguire l'upgrade a Edge for Private Cloud 4.53.01, valuta la possibilità di eseguire passaggi specifici per l'upgrade di determinati software. I passaggi necessari dipendono dalla versione attuale. Consulta la tabella riportata di seguito per i vari software che richiedono passaggi supplementari e segui le istruzioni dettagliate per ciascuno. Dopo aver completato le attività necessarie, torna alla procedura di upgrade principale per continuare il processo di upgrade.

Versione corrente Software che richiede passaggi speciali per l'upgrade alla versione 4.53.01
4.52.02 LDAP, Cassandra, Zookeeper, Postgres
4.53.00 LDAP, Zookeeper, Postgres

Dopo aver eseguito i passaggi necessari in base alla tua versione, torna alla procedura di upgrade principale per continuare.

Propagazione automatica delle impostazioni della proprietà

Se hai impostato delle proprietà modificando i file .properties in /opt/apigee/customer/application, questi valori vengono conservati dall'aggiornamento.

Upgrade obbligatorio a OpenLDAP 2.6

Di seguito è riportata la procedura passo passo per l'upgrade del servizio LDAP sottostante di Apigee Edge per Private Cloud dalla versione legacy OpenLDAP 2.4 a OpenLDAP 2.6. Questo upgrade è un requisito obbligatorio per l'aggiornamento ad Apigee Edge for Private Cloud versione 4.53.01 e successive. Questo upgrade è applicabile a tutte le topologie di deployment LDAP di Apigee: single-server, active-passive e active-active (multi-master).

Prerequisiti e considerazioni

  • Tieni presente che durante la procedura di upgrade LDAP, le API di gestione e, di conseguenza, l'interfaccia utente Apigee non saranno disponibili in tutte le regioni. Tutte le attività amministrative, come la gestione di utenti, ruoli, app e organizzazioni, non andranno a buon fine e dovranno essere sospese. L'elaborazione del traffico proxy API non subirà modifiche. Prima di procedere con l'upgrade di LDAP, assicurati di arrestare tutti i server di gestione edge e l'interfaccia utente edge.

  • Il backup è fondamentale:un backup completo e convalidato dei dati LDAP esistenti è imprescindibile. Se procedi senza un backup valido, si verificherà una perdita irreversibile di dati. Il backup deve essere avviato mentre il servizio LDAP è ancora in esecuzione per acquisire uno snapshot coerente e puntuale dei dati LDAP. Il backup è necessario per eseguire l'upgrade vero e proprio. Senza backup, non potrai eseguire l'upgrade né il rollback, poiché i passaggi di upgrade prevedono l'eliminazione dei dati LDAP.

Preparazione e installazione (tutti i server LDAP)

I passaggi di questa sezione (dal passaggio 2 al passaggio 5) sono identici per tutte le topologie di deployment LDAP. Queste azioni devono essere eseguite su ogni server in cui è installato il componente apigee-openldap, indipendentemente dal suo ruolo.

  1. Prima di procedere con l'upgrade di LDAP, assicurati di spegnere tutti i server di gestione perimetrale e edge-ui. 
    apigee-service edge-management-server stop
apigee-service edge-ui stop

  2. Eseguire il backup dei dati LDAP esistenti

    Prima di apportare modifiche, esegui un backup completo dei dati LDAP attuali da tutti i server LDAP. In questo modo viene creato un punto di ripristino sicuro.

    • Esegui il comando di backup. Questa azione crea un archivio di backup con timestamp nella directory /opt/apigee/backup/openldap. 
      apigee-service apigee-openldap backup
    • Ottieni il conteggio totale dei record:acquisisci il numero di record nella directory per la convalida post-upgrade (il conteggio dei record deve corrispondere su tutti i server LDAP). Questo è un controllo di integrità. 
      # Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \
-D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l

  3. Arrestare LDAP e pulire le directory dei dati

    Questo passaggio deve essere eseguito su tutti i server LDAP. È obbligatorio a causa della modifica della versione principale e delle differenze strutturali sottostanti. Una directory pulita garantisce che non ci siano conflitti. Quando tutti i server LDAP vengono arrestati, inizierà l'interruzione delle API Management e dell'UI.

    • Arresta il servizio LDAP. 
      apigee-service apigee-openldap stop
    • Rimuovi definitivamente le directory di configurazione e i vecchi dati LDAP. 
      rm -rf /opt/apigee/data/apigee-openldap/*

  4. Installare e configurare la nuova versione di LDAP

    Su tutti i server LDAP, utilizza gli script Apigee standard per scaricare e installare la nuova versione del componente.

    • Installa il nuovo componente LDAP:lo script di aggiornamento legge il file di configurazione e installa il nuovo pacchetto apigee-openldap. 
      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f /opt/silent.conf
    • Convalida la nuova versione di LDAP:al termine dell'installazione, ricarica il profilo e verifica che la nuova versione di LDAP sia installata correttamente. 
      source ~/.bash_profile
ldapsearch -VV
Expected output:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.6.7

  5. Interrompere LDAP su tutti i server prima del ripristino dei dati

    Si tratta di un passaggio di sincronizzazione fondamentale. Prima di ripristinare il backup, devi assicurarti che il servizio LDAP appena installato sia arrestato su tutti i server. Su ogni server LDAP, esegui i seguenti comandi: 

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

  6. Ripristinare i dati LDAP

    La strategia consiste nel ripristinare il backup sul primo server attivo. Questo server fungerà quindi da fonte attendibile, replicando i dati ai suoi peer in una configurazione multi-server.

    1. Identificare il primo server attivo per il ripristino

      • Per la configurazione a server singolo:questo è l'unico server LDAP. Puoi procedere direttamente al passaggio successivo.
      • Per le configurazioni active-passive e active-active:esegui il seguente comando di diagnostica su ogni server LDAP: 
        grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*\ldif
Note:
-If this command returns output, the server is a passive server.
-If it returns no output, the server is the active server.

    2. Ripristinare i dati di backup

      Prima di procedere, verifica che il passaggio 5 sia stato completato correttamente su tutti i server LDAP.

      • Sul primo server attivo che hai identificato sopra, vai alla directory di backup. 
        cd /opt/apigee/backup/openldap
      • Esegui il comando restore. Ti consigliamo vivamente di specificare l'ora esatta del backup del passaggio 2 per evitare di ripristinare una versione precedente o non intenzionale. 
        # To restore a specific backup (recommended):
apigee-service apigee-openldap restore 2025.08.11,23.34.00

# To restore the latest available backup by default:
apigee-service apigee-openldap restore
      • Una volta completato correttamente il processo di ripristino, avvia il servizio LDAP sul primo server attivo. 
        apigee-service apigee-openldap start

  7. Avviare i server LDAP rimanenti

    Se hai una configurazione multi-server, avvia il servizio su ciascuno dei server LDAP: 

    apigee-service apigee-openldap start

  8. Convalida finale

    Il passaggio finale consiste nel verificare che l'upgrade sia riuscito e che i dati siano coerenti nell'intero cluster LDAP.

    • Esegui il comando di convalida su tutti i server LDAP. Il conteggio dei record deve essere identico su tutti i server e deve corrispondere al conteggio acquisito nel passaggio 2.
      • # Note: Replace 'YOUR_PASSWORD' with your LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \
-D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
    • Una volta verificato che i dati siano corretti e coerenti, l'upgrade di LDAP è completato. Ora puoi procedere con l'avvio di edge-management-server e edge-ui e di qualsiasi altro componente dipendente in base alla procedura di upgrade standard della tua organizzazione.

Aggiornamento obbligatorio a Cassandra 4.0.18

Apigee Edge for Private Cloud 4.53.01 include un upgrade di Cassandra alla versione 4.0.18.

Upgrade e rollback

  • L'upgrade da Cassandra 3.11.X a Cassandra 4.0.X è un processo semplice. Cassandra 4.0.X, rilasciato con Edge for Private Cloud 4.53.00, è compatibile con i componenti di runtime e di gestione di Private Cloud 4.52.02.
  • Il rollback diretto in loco da Cassandra 4.0.X a 3.11.X non è possibile. Il rollback utilizzando le repliche o i backup è una procedura complessa e potrebbe comportare tempi di inattività e/o perdita di dati. La risoluzione dei problemi e l'upgrade a Cassandra 4.0.X sono preferibili al rollback.
  • È importante acquisire familiarità con le procedure di rollback prima di tentare l'upgrade. Considerare le sfumature del rollback durante l'upgrade è fondamentale per garantire la disponibilità di percorsi di rollback appropriati.

Singolo data center

L'upgrade di Cassandra dalla versione 3.11.X alla 4.0.X all'interno di un singolo data center è semplice, ma il rollback è complesso e potrebbe comportare tempi di inattività e perdita di dati. Per i carichi di lavoro di produzione, è consigliabile aggiungere un nuovo data center con almeno nodi Cassandra disponibili nel nuovo data center prima di avviare l'upgrade. In questo modo, potrai eseguire il rollback di Cassandra senza incorrere in perdite di dati o interruzioni del traffico API. Questo data center aggiuntivo può essere ritirato una volta terminato l'upgrade o raggiunto il punto di controllo 2.

Se l'aggiunta di un nuovo data center non è fattibile, ma è comunque necessaria la funzionalità di rollback, i backup saranno necessari per il ripristino di Cassandra 3.11.X. Tuttavia, questo metodo comporta probabilmente tempi di inattività e perdita di dati.

Più data center

L'utilizzo di più data center con Edge per il cloud privato 4.52.02 offre maggiore flessibilità per i rollback durante l'upgrade a Edge per il cloud privato 4.53.00.

  • I rollback dipendono dalla presenza di almeno un data center che esegue la versione precedente di Cassandra (3.11.X).
  • Se l'intero cluster Cassandra viene aggiornato alla versione 4.0.X, non devi eseguire il rollback alla versione 3.11.X di Cassandra. Devi continuare a utilizzare la versione più recente di Cassandra con gli altri componenti di Private Cloud 4.53.00 o 4.52.02.
  1. Esegui l'upgrade di un data center Cassandra alla volta:inizia eseguendo l'upgrade dei nodi Cassandra singolarmente all'interno di un singolo data center. Completa gli upgrade di tutti i nodi Cassandra in un data center prima di procedere con il successivo.
  2. Metti in pausa e convalida:dopo l'upgrade di un data center, metti in pausa per assicurarti che il cluster Private Cloud, in particolare il data center di cui è stato eseguito l'upgrade, funzioni correttamente.
  3. Ricorda:puoi eseguire il rollback alla versione precedente di Cassandra solo se almeno un data center esegue ancora la versione precedente.
  4. Sensibile al tempo:anche se puoi mettere in pausa per un breve periodo (consigliamo qualche ora) per convalidare la funzionalità, non puoi rimanere in uno stato di versione mista a tempo indeterminato. Ciò è dovuto al fatto che un cluster Cassandra non uniforme (con nodi su versioni diverse) presenta limitazioni operative.
  5. Test approfonditi:Apigee consiglia vivamente di eseguire test completi di prestazioni e funzionalità prima di eseguire l'upgrade del data center successivo. Una volta eseguito l'upgrade di tutti i data center, il rollback alla versione precedente è impossibile.
Rollback come procedura a due checkpoint
  1. Checkpoint 1:lo stato iniziale, con tutti i componenti alla versione 4.52.02. Il rollback completo è possibile finché almeno un data center Cassandra rimane nella versione precedente.
  2. Checkpoint 2: dopo l'aggiornamento di tutti i nodi Cassandra in tutti i data center. Puoi eseguire il rollback a questo stato, ma non puoi ripristinare il checkpoint 1.
Esempio

Considera un cluster a due data center:

  1. Stato iniziale:i nodi Cassandra in entrambi i DC sono alla versione 3.11.X. Tutti gli altri nodi utilizzano Edge for Private Cloud versione 4.52.02. Supponi tre nodi Cassandra per DC.
  2. Upgrade DC-1: esegui l'upgrade dei tre nodi Cassandra in DC-1 uno alla volta.
  3. Metti in pausa e convalida:metti in pausa per assicurarti che il cluster, in particolare DC-1, funzioni correttamente (controlla prestazioni e funzionalità). Puoi eseguire il rollback allo stato iniziale utilizzando i nodi Cassandra in DC-2. Ricorda che questa pausa deve essere temporanea a causa delle limitazioni di un cluster Cassandra con versioni miste.
  4. Upgrade DC-2: esegui l'upgrade dei tre nodi Cassandra rimanenti in DC-2. Questo diventa il nuovo checkpoint di rollback.
  5. Esegui l'upgrade di altri componenti:esegui l'upgrade dei nodi di gestione, runtime e analisi come di consueto in tutti i data center, un nodo e un data center alla volta. Se si verificano problemi, puoi eseguire il rollback allo stato del passaggio 4.

Prerequisiti per l'upgrade di Cassandra

Devi eseguire Cassandra 3.11.16 con Edge per Private Cloud 4.52.02 e assicurarti che:
  1. L'intero cluster è operativo e completamente funzionante con Cassandra 3.11.16.
  2. La strategia di compattazione è impostata su LeveledCompactionStrategy (un prerequisito per l'upgrade alla versione 4.52.02).

  3. Verifica che ogni passaggio riportato di seguito sia stato completato nell'ambito dell'upgrade iniziale di Cassandra 3.11 in Edge for Private Cloud 4.52.02.

    • Il comando post_upgrade è stato eseguito su ogni nodo Cassandra durante l'upgrade precedente
    • Il comando drop_old_tables è stato eseguito sull'intero cluster Cassandra durante l'upgrade precedente.

Se non hai la certezza che i comandi post_upgrade e drop_old_tables siano stati eseguiti su Cassandra 3.11 durante l'utilizzo di Edge for Private Cloud 4.52.02, puoi eseguirli di nuovo in sicurezza prima di tentare l'upgrade alla versione 4.53.01.

Passaggio 1: preparati all'upgrade

I passaggi riportati di seguito si aggiungono ai file standard che in genere crei, ad esempio il file di configurazione standard di Apigee per l'attivazione degli upgrade dei componenti.

  1. Esegui il backup di Cassandra utilizzando Apigee.
  2. Acquisisci snapshot VM dei nodi Cassandra (se fattibile).
  3. Assicurati che la porta 9042 sia accessibile da tutti i componenti di Edge per il cloud privato, inclusi Management Server, Message Processor, Router, Qpid e Postgres, ai nodi Cassandra, se non è già configurata. Per ulteriori informazioni, consulta i requisiti relativi alle porte.

Passaggio 2: esegui l'upgrade di tutti i nodi Cassandra

Tutti i nodi Cassandra devono essere aggiornati uno alla volta in ogni data center, un data center alla volta. Tra gli upgrade dei nodi all'interno di un data center, attendi alcuni minuti per assicurarti che un nodo aggiornato sia stato avviato completamente e si sia unito al cluster prima di procedere con l'upgrade di un altro nodo nello stesso data center.

Dopo aver eseguito l'upgrade di tutti i nodi Cassandra all'interno di un data center, attendi un po' di tempo (da 30 minuti a qualche ora) prima di procedere con i nodi nel data center successivo. Durante questo periodo, esamina attentamente il data center aggiornato e assicurati che le metriche funzionali e di rendimento del cluster Apigee siano intatte. Questo passaggio è fondamentale per garantire la stabilità del data center in cui Cassandra è stato aggiornato alla versione 4.0.X, mentre il resto dei componenti Apigee rimane alla versione 4.52.02.

  1. Per eseguire l'upgrade di un nodo Cassandra, esegui questo comando: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
  2. Una volta aggiornato un nodo, esegui questo comando sul nodo per eseguire alcune convalide prima di procedere: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra validate_upgrade -f configFile
  3. L'output sarà simile a questo: 
    Cassandra version is verified - [cqlsh 6.0.0 | Cassandra 4.0.18 | CQL spec 3.4.5 | Native protocol v5] 
Metadata is verified
  4. Esegui questo comando post_upgrade sul nodo Cassandra: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade
  5. Esegui i seguenti comandi nodetool per ricostruire gli indici sul nodo Cassandra: 
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms api_products api_products_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_api_products_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_end_user app_end_user_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_family_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_type_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms maps maps_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_consumer_key_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_consumer_key_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_request_token_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_client_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_refresh_token_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_client_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_company_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_developer_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index cache cache_entries cache_entries_cache_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_operation_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_requesturi_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_responsecode_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_timestamp_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_user_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_active_rev
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_index_template
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_method_template
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_latest_rev
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_active
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_latest
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rel_ver
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_res_path
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_res_path
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_entity
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template_auth au_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index dek keys usecase_index
     Se utilizzi la monetizzazione, esegui anche i seguenti comandi di ricompilazione degli indici relativi agli spazi delle chiavi di monetizzazione: 
    /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

Passaggio 3: esegui l'upgrade di tutti i nodi di gestione

Esegui l'upgrade di tutti i nodi di gestione in tutte le regioni uno alla volta:

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

Passaggio 4: esegui l'upgrade di tutti i nodi Runtime

Esegui l'upgrade di tutti i nodi Router e Message Processor in tutte le regioni uno alla volta:

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

Passaggio 5: esegui l'upgrade di tutti i componenti Edge for Private Cloud 4.53.01 rimanenti

Esegui l'upgrade di tutti i nodi edge-qpid-server e edge-postgres-server rimanenti in tutte le regioni uno alla volta.

Upgrade obbligatorio a Zookeeper 3.8.4

Questa release di Edge for Private Cloud include un upgrade a Zookeeper 3.8.4. Nell'ambito di questo upgrade, tutti i dati di Zookeeper verranno migrati a Zookeeper 3.8.4.

Prima di eseguire l'upgrade di Zookeeper, leggi la guida alla manutenzione di Zookeeper. La maggior parte dei sistemi di produzione Edge utilizza un cluster di nodi Zookeeper distribuiti in più data center. Alcuni di questi nodi sono configurati come votanti che partecipano all'elezione del leader di ZooKeeper, mentre gli altri sono configurati come osservatori. Per ulteriori dettagli, consulta la sezione Informazioni su leader, follower, votanti e osservatori. I nodi votanti eleggono un leader, dopodiché diventano follower.

Durante il processo di aggiornamento, potrebbe verificarsi un ritardo momentaneo o un errore di scrittura in Zookeeper quando il nodo leader viene arrestato. Ciò potrebbe influire sulle operazioni di gestione che scrivono in Zookeeper, come l'operazione di deployment di un proxy e le modifiche all'infrastruttura Apigee, come l'aggiunta o la rimozione di un processore di messaggi e così via. Non dovrebbero esserci impatti sulle API di runtime di Apigee (a meno che queste API di runtime non chiamino API di gestione) durante l'upgrade di Zookeeper seguendo la procedura riportata di seguito.

A livello generale, la procedura di upgrade prevede l'esecuzione di un backup di ogni nodo. Seguono l'upgrade di tutti gli osservatori e follower e infine l'upgrade del nodo leader.

Eseguire un backup

Esegui un backup di tutti i nodi di Zookeeper da utilizzare nel caso in cui sia necessario un rollback. Tieni presente che un rollback ripristinerà Zookeeper allo stato in cui si trovava al momento del backup. Nota:qualsiasi deployment o modifica dell'infrastruttura in Apigee dopo l'esecuzione del backup (le cui informazioni sono archiviate in Zookeeper) andrà persa durante il ripristino. 

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

Se utilizzi macchine virtuali e hai la possibilità, puoi anche eseguire snapshot o backup delle VM per il ripristino o il rollback (se necessario).

Identificare il leader, i follower e gli osservatori

Nota:i comandi di esempio riportati di seguito utilizzano l'utilità nc per inviare dati a Zookeeper. Puoi utilizzare anche utilità alternative per inviare dati a Zookeeper.

  1. Se non è installato sul nodo ZooKeeper, installa nc: 
      sudo yum install nc
  2. Esegui il seguente comando nc sul nodo, dove 2181 è la porta ZooKeeper: 
      echo stat | nc localhost 2181

    Dovresti vedere un output simile al seguente:

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

    Nella riga Mode dell'output per i nodi, dovresti visualizzare observer, leader o follower (ovvero un votante che non è il leader) a seconda della configurazione del nodo. Nota:in un'installazione autonoma di Edge con un singolo nodo ZooKeeper, Mode è impostato su autonomo.

  3. Ripeti i passaggi 1 e 2 su ogni nodo ZooKeeper.

Esegui l'upgrade di Zookeeper sui nodi osservatore e follower

Esegui l'upgrade di Zookeeper su ciascuno dei nodi osservatore e follower nel seguente modo:

  1. Scarica ed esegui il bootstrap di Edge per Private Cloud 4.53.01, come descritto in Aggiorna alla versione 4.53.01 su un nodo con una connessione internet esterna. La procedura probabilmente varia a seconda che il nodo abbia una connessione a internet esterna o che tu stia eseguendo un'installazione offline.
  2. Esegui l'upgrade del componente Zookeeper: 
      /opt/apigee/apigee-setup/bin/update.sh -c zk -f <silent-config-file>
     Nota:se questi nodi hanno installato altri componenti (ad esempio Cassandra), puoi eseguire l'upgrade anche di questi ora (come con il profilo cs,zk) oppure puoi eseguire l'upgrade degli altri componenti in un secondo momento. Apigee consiglia di eseguire l'upgrade di Zookeeper solo prima e assicurarsi che il cluster funzioni correttamente prima di eseguire l'upgrade di altri componenti.
  3. Ripeti i passaggi precedenti su ciascun nodo osservatore e follower di Zookeeper.

Arresta il leader

Una volta eseguito l'upgrade di tutti i nodi osservatore e follower, spegni il nodo leader. Sul nodo identificato come leader, esegui il comando seguente: 

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

Tieni presente che durante questo evento, prima dell'elezione di un nuovo leader, potrebbero verificarsi ritardi momentanei o errori di scrittura in Zookeeper. Ciò potrebbe influire sulle operazioni di scrittura in Zookeeper, come l'azione di deployment dei proxy o le modifiche all'infrastruttura Apigee, ad esempio l'aggiunta o la rimozione di processori di messaggi e così via.

Verifica che il nuovo leader sia eletto

Segui i passaggi descritti nella sezione Identificare il leader, i follower e gli osservatori sopra riportata per verificare che sia stato eletto un nuovo leader tra i follower una volta interrotto il leader esistente. Tieni presente che il leader potrebbe essere stato eletto in un data center diverso da quello attuale.

Esegui l'upgrade del leader

Segui gli stessi passaggi descritti nella sezione Aggiornamento di Zookeeper sui nodi osservatore e follower riportata sopra.

Una volta eseguito l'upgrade anche del vecchio nodo leader, verifica l'integrità del cluster e assicurati che sia presente un nodo leader.

Upgrade di Nginx 1.26 in Edge-Router

L'upgrade a Edge for Private Cloud 4.53.01 dalle versioni precedenti non esegue automaticamente l'upgrade del software Nginx all'ultima versione (1.26.x). Questo per evitare effetti collaterali di runtime accidentali a seguito delle modifiche documentate in Modifiche di Nginx 1.26 in Apigee Edge 4.53.01. Puoi eseguire manualmente l'upgrade di Nginx dalla versione 1.20.x alla 1.26.x dopo la verifica negli ambienti di livello inferiore. Per eseguire l'upgrade manualmente:

  1. Assicurati che sul nodo edge-router sia installato il software 4.53.01 più recente

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

  2. Controllare e verificare la versione di Nginx attualmente in esecuzione

    /opt/nginx/sbin/nginx -V

    Se utilizzi una versione precedente di Nginx, puoi seguire i passaggi riportati di seguito per eseguire l'upgrade di Nginx alla versione 1.26.X sul nodo del router.

  3. Arresta il processo del router edge sul nodo del router

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

  4. Esegui l'upgrade del software nginx sul nodo del router

    dnf update apigee-nginx

  5. Verifica che la versione di Nginx sia stata aggiornata

    /opt/nginx/sbin/nginx -V

  6. Avviare il processo del router sul nodo

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

  7. Ripeti la procedura su ogni nodo del router, uno alla volta.

Upgrade obbligatorio a Postgres 17

Questa release di Edge include un upgrade a Postgres 17. Nell'ambito di questo upgrade, tutti i dati di Postgres vengono migrati a Postgres 17.

La maggior parte dei sistemi di produzione Edge utilizza due nodi Postgres configurati per la replica master-standby. Durante il processo di aggiornamento, mentre i nodi Postgres sono inattivi per l'aggiornamento, i dati di analisi vengono comunque scritti nei nodi Qpid. Una volta aggiornati e di nuovo online, i nodi Postgres, i dati di analisi vengono poi inviati ai nodi Postgres.

Il modo in cui esegui l'aggiornamento di Postgres dipende da come hai configurato l'archiviazione dei dati per i nodi Postgres:

  • Se utilizzi l'archiviazione locale dei dati per i nodi Postgres, devi installare un nuovo nodo di standby Postgres per la durata dell'upgrade. Al termine dell'upgrade, puoi ritirare il nuovo nodo di standby Postgres.

    Il nodo di standby Postgres aggiuntivo è necessario se devi eseguire il rollback dell'aggiornamento per qualsiasi motivo. Se devi eseguire il rollback dell'aggiornamento, il nuovo nodo di standby Postgres diventa il nodo Postgres master dopo il rollback. Pertanto, quando installi il nuovo nodo di standby Postgres, deve trovarsi su un nodo che soddisfi tutti i requisiti hardware di un server Postgres, come definito nei requisiti di installazione di Edge.

    In una configurazione a 1 e 2 nodi di Edge, topologie utilizzate per la prototipazione e i test, hai un solo nodo Postgres. Puoi aggiornare questi nodi Postgres direttamente senza doverne creare uno nuovo.

  • Se utilizzi l'archiviazione di rete per i nodi Postgres, come consigliato da Apigee, non devi installare un nuovo nodo Postgres. Nelle procedure riportate di seguito, puoi saltare i passaggi che specificano di installare e ritirare in un secondo momento un nuovo nodo di standby Postgres.

    Prima di iniziare la procedura di aggiornamento, acquisisci uno snapshot di rete dell'archivio dati utilizzato da PostgreSQL. In questo modo, se si verificano errori durante l'aggiornamento e sei costretto a eseguire un rollback, puoi ripristinare il nodo Postgres dallo snapshot.

Installazione di un nuovo nodo di standby Postgres

Questa procedura crea un server di standby Postgres su un nuovo nodo. Assicurati di installare un nuovo server di standby Postgres per la tua versione esistente di Edge (4.52.02 o 4.53.00), non per la versione 4.53.01.

Per eseguire l'installazione, utilizza lo stesso file di configurazione che hai utilizzato per installare la versione attuale di Edge.

Per creare un nuovo nodo di standby Postgres:

  1. Sul master Postgres attuale, modifica il file /opt/apigee/customer/application/postgresql.properties per impostare il seguente token. Se il file non esiste, crealo: 
    conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust\ \nhost replication apigee new_standby_ip/32 trust

    dove existing_standby_ip è l'indirizzo IP del server di standby Postgres attuale e new_standby_ip è l'indirizzo IP del nuovo nodo di standby.

  2. Riavvia apigee-postgresql sul master Postgres: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
  3. Verifica che il nuovo nodo di standby sia stato aggiunto visualizzando il file /opt/apigee/apigee-postgresql/conf/pg_hba.conf sul master. Dovresti vedere le seguenti righe nel file: 
    host replication apigee existing_standby_ip/32 trust
host replication apigee new_standby_ip/32 trust
  4. Installa il nuovo server di standby Postgres:
    1. Modifica il file di configurazione che hai utilizzato per installare la versione attuale di Edge per specificare quanto segue: 
      # IP address of the current master:
PG_MASTER=192.168.56.103
# IP address of the new standby node
PG_STANDBY=192.168.56.102
    2. Disattiva SELinux come descritto in Installare l'utilità apigee-setup di Edge.

    3. Se attualmente utilizzi Edge 4.52.02:

      1. Scarica il file Edge bootstrap_4.52.02.sh in /tmp/bootstrap_4.52.02.sh : 
        curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.51.00.sh
      2. Installa l'utilità e le dipendenze di Edge apigee-service: 
        sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

      Se attualmente utilizzi Edge 4.53.00:

      1. Scarica il file Edge bootstrap_4.53.00.sh in /tmp/bootstrap_4.53.00.sh : 
        curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh
      2. Installa l'utilità e le dipendenze di Edge apigee-service: 
        sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
    4. Utilizza apigee-service per installare l'utilità apigee-setup: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
    5. Installa Postgres: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
    6. Sul nuovo nodo di standby, esegui questo comando: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

      Verifica che sia in standby.

Esecuzione di un upgrade in loco di Postgres

Nota:devi eseguire il seguente passaggio preliminare prima di eseguire un upgrade sul posto di Postgres.

Passaggio preliminare

Prima di eseguire un upgrade in loco a Postgres, esegui i seguenti passaggi sia sull'host master che su quello di standby per aggiornare la proprietà max_locks_per_transaction su apigee-postgresql:

  1. Se non è presente, crea il file /opt/apigee/customer/application/postgresql.properties.
  2. Trasferisci la proprietà di questo file a apigee: 
    sudo chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
  3. Aggiungi la seguente proprietà al file: 
    conf/postgresql.conf+max_locks_per_transaction=30000
  4. Configura apigee-postgresql: 
    apigee-service apigee-postgresql configure
  5. Riavvia apigee-postgresql: 
    apigee-service apigee-postgresql restart

Esegui l'upgrade in loco

Per eseguire un upgrade in loco a Postgres 17:

  1. Esegui l'upgrade di PostgreSQL sull'host master 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f /opt/silent.conf
  2. Esegui il comando di configurazione sull'host master: 
    apigee-service apigee-postgresql setup -f /opt/silent.conf
  3. Esegui il comando di configurazione sull'host master: 
    apigee-service apigee-postgresql configure
  4. Riavvia l'host master: 
    apigee-service apigee-postgresql restart
  5. Configuralo come master: 
    apigee-service apigee-postgresql setup-replication-on-master -f /opt/silent.conf
  6. Assicurati che l'host master sia stato avviato: 
    apigee-service apigee-postgresql wait_for_ready
  7. Interrompi la modalità standby: 
    apigee-service apigee-postgresql stop
  8. Esegui l'upgrade della modalità standby.

    Nota:se questo passaggio genera un errore o non va a buon fine, può essere ignorato. update.sh tenterà di avviare il server di standby con una configurazione errata. Se l'installazione di Postgres viene aggiornata alla versione 17, l'errore può essere ignorato.

    /opt/apigee/apigee-setup/bin/update.sh -c ps -f /opt/silent.conf
  9. Assicurati che la modalità standby sia interrotta: 
    apigee-service apigee-postgresql stop
  10. Rimuovi la vecchia configurazione di standby: 
    rm -rf /opt/apigee/data/apigee-postgresql/
  11. Configura la replica sul server di standby: 
    apigee-service apigee-postgresql setup-replication-on-standby -f /opt/silent.conf
  12. Rimuovi la riga conf/postgresql.conf+max_locks_per_transaction=30000 dal file /opt/apigee/customer/application/postgresql.properties sia sull'host master che su quello di standby. Questa riga è stata aggiunta nel passaggio preliminare.

Al termine di questa procedura, la modalità standby verrà avviata correttamente.

Ritiro di un nodo Postgres

Al termine dell'aggiornamento, ritira il nuovo nodo di standby:

  1. Assicurati che Postgres sia in esecuzione: 
    /opt/apigee/apigee-service/bin/apigee-all status

    Se Postgres non è in esecuzione, avvialo: 

    /opt/apigee/apigee-service/bin/apigee-all start
  2. Recupera l'UUID del nuovo nodo di standby eseguendo il seguente comando curl sul nuovo nodo di standby: 
    curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

    Dovresti vedere l'UUID del nodo alla fine dell'output, nel formato: 

    "type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
  3. Arresta il nuovo nodo di standby eseguendo questo comando sul nuovo nodo di standby: 
    /opt/apigee/apigee-service/bin/apigee-all stop
  4. Sul nodo master Postgres, modifica /opt/apigee/customer/application/postgresql.properties per rimuovere il nuovo nodo di standby da conf_pg_hba_replication.connection: 
    conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust
  5. Riavvia apigee-postgresql sul master Postgres: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
  6. Verifica che il nuovo nodo di standby sia stato rimosso visualizzando il file /opt/apigee/apigee-postgresql/conf/pg_hba.conf sul master. Dovresti vedere solo la seguente riga nel file: 
    host replication apigee existing_standby_ip/32 trust
  7. Elimina l'UUID del nodo di standby da ZooKeeper effettuando la seguente chiamata API di gestione Edge sul nodo del server di gestione: 
    curl -u sysAdminEmail:password -X DELETE http://ms_IP:8080/v1/servers/new_standby_uuid

Passaggi post-upgrade per Postgres

Dopo un upgrade principale di Postgres, le statistiche interne di Postgres vengono cancellate. Queste statistiche aiutano lo strumento di pianificazione delle query Postgres a utilizzare gli indici e i percorsi più ottimali per eseguire le query.

PostgreSQL può ricostruire gradualmente le statistiche nel tempo man mano che le query vengono eseguite e quando viene eseguito il daemon autovacuum. Tuttavia, finché le statistiche non vengono ricreate, le query potrebbero essere lente.

Per risolvere il problema, esegui ANALYZE su tutte le tabelle del database nel nodo master Postgres. In alternativa, puoi eseguire ANALYZE per alcune tabelle alla volta.

Passaggi per aggiornare Apigee SSO dalle versioni precedenti

In Edge for Private Cloud 4.53.01, le chiavi e i certificati IDP utilizzati nel componente apigee-sso vengono ora configurati tramite un archivio chiavi. Dovrai esportare la chiave e il certificato utilizzati in precedenza in un keystore, configurarlo e poi procedere con l'aggiornamento SSO come di consueto.

  1. Identifica la chiave e il certificato esistenti utilizzati per configurare l'IdP:

    1. Recupera il certificato cercando il valore di SSO_SAML_SERVICE_PROVIDER_CERTIFICATE nel file di configurazione dell'installazione SSO o eseguendo una query sul componente apigee-sso per conf_login_service_provider_certificate.

      Utilizza il seguente comando sul nodo SSO per eseguire query su apigee-sso per il percorso del certificato IDP. Nell'output, cerca il valore nell'ultima riga. 

      apigee-service apigee-sso configure -search conf_login_service_provider_certificate

    2. Recupera la chiave cercando il valore di SSO_SAML_SERVICE_PROVIDER_KEY nel file di configurazione dell'installazione SSO o eseguendo una query sul componente apigee-sso per conf_login_service_provider_key.

      Utilizza il seguente comando sul nodo SSO per eseguire query su apigee-sso per il percorso della chiave IDP. Nell'output, cerca il valore nell'ultima riga.

      apigee-service apigee-sso configure -search conf_login_service_provider_key
  2. Esporta la chiave e il certificato in un keystore:
    1. Esporta la chiave e il certificato in un keystore PKCS12: 
      sudo openssl pkcs12 -export -clcerts -in <certificate_path> -inkey <key_path> -out <keystore_path> -name <alias>

      Parametri:

      • certificate_path: il percorso del file del certificato recuperato nel passaggio 1.a.
      • key_path: percorso del file della chiave privata recuperato nel passaggio 1.b.
      • keystore_path: il percorso del keystore appena creato contenente il certificato e la chiave privata.
      • alias: Alias utilizzato per la coppia di chiave e certificato all'interno dell'archivio chiavi.

      Per ulteriori dettagli, consulta la documentazione di OpenSSL.

    2. (Facoltativo) Esporta la chiave e il certificato da PKCS12 a un keystore JKS: 
      sudo keytool -importkeystore -srckeystore <PKCS12_keystore_path> -srcstoretype PKCS12 -destkeystore <destination_keystore_path> -deststoretype JKS -alias <alias>

      Parametri:

      • PKCS12_keystore_path: percorso del keystore PKCS12 creato nel passaggio 2.a, contenente il certificato e la chiave.
      • destination_keystore_path: percorso del nuovo keystore JKS in cui verranno esportati il certificato e la chiave.
      • alias: alias utilizzato per la coppia di chiave e certificato all'interno dell'archivio chiavi JKS.

      3. Per ulteriori dettagli, consulta la documentazione di keytool.

  3. Cambia il proprietario del file keystore di output in "apigee": 
    sudo chown apigee:apigee <keystore_file>
  4. Aggiungi le seguenti proprietà nel file di configurazione di Apigee SSO e aggiornale con il percorso del file keystore, la password, il tipo di keystore e l'alias: 
    # Path to the keystore file
SSO_SAML_SERVICE_PROVIDER_KEYSTORE_PATH=${APIGEE_ROOT}/apigee-sso/source/conf/keystore.jks

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

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

# Alias within keystore that stores the key and certificate
SSO_SAML_SERVICE_PROVIDER_KEYSTORE_ALIAS=service-provider-cert
  5. Aggiorna il software Apigee SSO sul nodo SSO come di consueto utilizzando il seguente comando: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f /opt/silent.conf

Nuova UI di Edge

Questa sezione elenca le considerazioni relative all'interfaccia utente perimetrale. Per maggiori informazioni, consulta La nuova UI Edge per Private Cloud.

Installare l'interfaccia utente Edge

Dopo aver completato l'installazione iniziale, Apigee consiglia di installare l'interfaccia utente Edge, che è un'interfaccia utente avanzata per sviluppatori e amministratori di Apigee Edge for Private Cloud.

Tieni presente che la UI di Edge richiede la disattivazione dell'autenticazione di base e l'utilizzo di un IDP come SAML o LDAP.

Per saperne di più, consulta Installare la nuova UI Edge.

Aggiornamento con Apigee mTLS

Per aggiornare Apigee mTLS , segui questi passaggi:

Eseguire il rollback di un aggiornamento

In caso di errore di aggiornamento, puoi provare a correggere il problema ed eseguire di nuovo update.sh. Puoi eseguire l'aggiornamento più volte e questo continua da dove era stato interrotto.

Se l'errore richiede il rollback dell'aggiornamento alla versione precedente, consulta Eseguire il rollback della versione 4.53.01 per istruzioni dettagliate.

Informazioni sull'aggiornamento del logging

Per impostazione predefinita, l'utilità update.sh scrive le informazioni di log in:

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

Se la persona che esegue l'utilità update.sh non ha accesso a questa directory, scrive il log nella directory /tmp come file denominato update_username.log.

Se la persona non ha accesso a /tmp, l'utilità update.sh non funziona.

Aggiornamento senza tempi di inattività

Un aggiornamento senza tempi di inattività, o aggiornamento in sequenza, ti consente di aggiornare l'installazione di Edge senza interrompere il funzionamento di Edge.

L'aggiornamento senza tempi di inattività è possibile solo con una configurazione a 5 nodi o più.

La chiave per l'upgrade senza tempi di inattività è rimuovere ogni router, uno alla volta, dal bilanciatore del carico. Quindi aggiorna il router e gli altri componenti sulla stessa macchina del router e poi aggiungi di nuovo il router al bilanciatore del carico.

  1. Aggiorna le macchine nell'ordine corretto per l'installazione, come descritto in Ordine di aggiornamento delle macchine.
  2. Quando è il momento di aggiornare i router, seleziona un router qualsiasi e rendilo irraggiungibile, come descritto in Attivazione/Disattivazione dell'accessibilità del server (Message Processor/Router).
  3. Aggiorna il router selezionato e tutti gli altri componenti Edge sulla stessa macchina del router. Tutte le configurazioni Edge mostrano un router e un processore di messaggi sullo stesso nodo.
  4. Rendi di nuovo raggiungibile il router.
  5. Ripeti i passaggi da 2 a 4 per i router rimanenti.
  6. Continua l'aggiornamento per le macchine rimanenti nell'installazione.

Prima e dopo l'aggiornamento, occupati di quanto segue:

Utilizzare un file di configurazione invisibile

Devi trasmettere un file di configurazione non interattivo al comando di aggiornamento. Il file di configurazione non interattiva deve essere lo stesso che hai utilizzato per installare Edge for Private Cloud 4.52.02 o 4.53.00.

Aggiorna alla versione 4.53.01 su un nodo con una connessione a internet esterna

Per aggiornare i componenti Edge su un nodo, segui questa procedura:

  1. Se presenti, disattiva tutti i job cron configurati per eseguire un'operazione di riparazione su Cassandra fino al completamento dell'aggiornamento.
  2. Accedi al nodo come root per installare gli RPM Edge.
  3. Disattiva SELinux come descritto in Installare l'utilità apigee-setup di Edge.
  4. Se esegui l'installazione su AWS, esegui i seguenti comandi yum-configure-manager: 
    yum update rh-amazon-rhui-client.noarch
sudo yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

  5. Se attualmente utilizzi Edge 4.52.02 o 4.53.00:

    1. Scarica il file bootstrap_4.53.01.sh di Edge in /tmp/bootstrap_4.53.01.sh: 
      curl https://software.apigee.com/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh
    2. Installa l'utilità Edge 4.53.01 apigee-service e le dipendenze eseguendo il seguente comando: 
      sudo bash /tmp/bootstrap_4.53.01.sh apigeeuser=uName apigeepassword=pWord

      dove uName:pWord sono il nome utente e la password che hai ricevuto da Apigee. Se ometti pWord, ti verrà chiesto di inserirlo.

      Per impostazione predefinita, il programma di installazione verifica che sia installato Java 1.8. In caso contrario, il programma di installazione lo installa per te.

      Utilizza l'opzione JAVA_FIX per specificare come gestire l'installazione di Java. JAVA_FIX accetta i seguenti valori:

      • I: installa OpenJDK 1.8 (impostazione predefinita).
      • C: continua senza installare Java.
      • Q: Esci. Per questa opzione, devi installare Java autonomamente.
    3. Utilizza apigee-service per aggiornare l'utilità apigee-setup, come mostrato nell'esempio seguente: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-setup update
    4. Aggiorna l'utilità apigee-validate sul server di gestione, come mostrato nell'esempio seguente: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-validate update
    5. Aggiorna l'utilità apigee-provision sul server di gestione, come mostrato nell'esempio seguente: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-provision update
    6. Esegui l'utilità update sui nodi eseguendo questo comando: 
      /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

      Esegui questa operazione nell'ordine descritto in Ordine di aggiornamento della macchina.

      Dove:

      • component è il componente Edge da aggiornare. I valori possibili includono:
        • cs: Cassandra
        • edge: Tutti i componenti Edge, tranne la UI Edge: Management Server, Message Processor, Router, QPID Server, Postgres Server
        • ldap: OpenLDAP
        • ps: postgresql
        • qpid: qpidd
        • sso: Apigee SSO (se hai installato SSO)
        • ue: nuova UI di Edge
        • ui: UI di Edge classica
        • zk: Zookeeper
      • configFile è lo stesso file di configurazione che hai utilizzato per definire i componenti Edge durante l'installazione della versione 4.52.02 o 4.53.00.

      Puoi eseguire update.sh su tutti i componenti impostando component su "all", ma solo se hai un profilo di installazione all-in-one (AIO) di Edge. Ad esempio:

      /opt/apigee/apigee-setup/bin/update.sh -c all -f ./sa_silent_config
    7. Riavvia i componenti dell'interfaccia utente Edge su tutti i nodi che li eseguono, se non l'hai già fatto: 
      /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
    8. Testa l'aggiornamento eseguendo l'utilità apigee-validate sul server di gestione, come descritto in Testa l'installazione.

Se in seguito decidi di eseguire il rollback dell'aggiornamento, utilizza la procedura descritta in Eseguire il rollback della versione 4.53.01.

Aggiornamento alla versione 4.53.01 da un repository locale

Se i nodi Edge si trovano dietro un firewall o è loro vietato in altro modo l'accesso al repository Apigee su internet, puoi eseguire l'aggiornamento da un repository locale o da un mirror del repository Apigee.

Dopo aver creato un repository Edge locale, hai due opzioni per aggiornare Edge dal repository locale:

  • Crea un file .tar del repository, copialo in un nodo e poi aggiorna Edge dal file .tar.
  • Installa un server web sul nodo con il repository locale in modo che gli altri nodi possano accedervi. Apigee fornisce il server web Nginx da utilizzare oppure puoi utilizzare il tuo server web.

Per eseguire l'aggiornamento da un repository locale 4.53.01:

  1. Crea un repository locale 4.53.01 come descritto in "Crea un repository Apigee locale" in Installa l'utilità apigee-setup di Edge.
  2. Per installare apigee-service da un file .tar:
    1. Sul nodo con il repository locale, utilizza il seguente comando per creare il pacchetto del repository locale in un unico file .tar denominato /opt/apigee/data/apigee-mirror/apigee-4.53.01.tar.gz: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
    2. Copia il file .tar nel nodo in cui vuoi aggiornare Edge. Ad esempio, copialo nella directory /tmp sul nuovo nodo.
    3. Sul nuovo nodo, decomprimi il file nella directory /tmp: 
      tar -xzf apigee-4.53.01.tar.gz

      Questo comando crea una nuova directory denominata repos nella directory contenente il file .tar. Ad esempio /tmp/repos.

    4. Installa l'utilità e le dipendenze Edge apigee-service da /tmp/repos: 
      sudo bash /tmp/repos/bootstrap_4.53.01.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos

      Tieni presente che in questo comando includi il percorso della directory dei repository.

  3. Per installare apigee-service utilizzando il server web Nginx:
    1. Configura il server web Nginx come descritto in "Installazione dal repository utilizzando il server web Nginx" in Installare l'utilità apigee-setup di Edge.
    2. Sul nodo remoto, scarica il file Edge bootstrap_4.53.01.sh in /tmp/bootstrap_4.53.01.sh: 
      /usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh

      dove uName:pWord sono il nome utente e la password impostati in precedenza per il repository e remoteRepo è l'indirizzo IP o il nome DNS del nodo del repository.

    3. Sul nodo remoto, installa l'utilità e le dipendenze Edge apigee-setup: 
      sudo bash /tmp/bootstrap_4.53.01.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://

      dove uName:pWord sono il nome utente e la password del repository.

  4. Utilizza apigee-service per aggiornare l'utilità apigee-setup, come mostrato nell'esempio seguente: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup update
  5. Aggiorna l'utilità apigee-validate sul server di gestione, come mostrato nell'esempio seguente: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-validate update
  6. Aggiorna l'utilità apigee-provision sul server di gestione, come mostrato nell'esempio seguente: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-provision update
  7. Esegui l'utilità update sui nodi nell'ordine descritto in Ordine di aggiornamento della macchina: 
    /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

    Dove:

    • component è il componente Edge da aggiornare. In genere, aggiorni i seguenti componenti:
      • cs: Cassandra
      • edge: Tutti i componenti Edge, tranne la UI Edge: Management Server, Message Processor, Router, QPID Server, Postgres Server
      • ldap: OpenLDAP
      • ps: postgresql
      • qpid: qpidd
      • sso: Apigee SSO (se hai installato SSO)
      • ue Nuova UI di Edge
      • ui: UI di Edge classica
      • zk: Zookeeper
    • configFile è lo stesso file di configurazione che hai utilizzato per definire i componenti Edge durante l'installazione della versione 4.52.02 o 4.53.00.

    Puoi eseguire update.sh su tutti i componenti impostando component su "all", ma solo se hai un profilo di installazione all-in-one (AIO) di Edge. Ad esempio:

    /opt/apigee/apigee-setup/bin/update.sh -c all -f /tmp/sa_silent_config
  8. Se non l'hai ancora fatto, riavvia i componenti UI su tutti i nodi che li eseguono: 
    /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
  9. Testa l'aggiornamento eseguendo l'utilità apigee-validate sul server di gestione, come descritto in Testare l'installazione.

Se in seguito decidi di eseguire il rollback dell'aggiornamento, utilizza la procedura descritta in Eseguire il rollback della versione 4.53.01.

Ordine di aggiornamento della macchina

L'ordine in cui aggiorni le macchine in un'installazione Edge è importante:

  • Devi aggiornare tutti i nodi LDAP prima di aggiornare qualsiasi altro componente. Per eseguire l'upgrade di LDAP, devi seguire passaggi speciali.
  • Devi aggiornare tutti i nodi Cassandra e ZooKeeper. Se esegui l'upgrade dalla versione 4.52.02, segui i passaggi speciali per eseguire l'upgrade di Cassandra. Per eseguire l'upgrade di Zookeeper per le versioni 4.52.02 o 4.53.00, devi seguire passaggi speciali.
  • Per aggiornare tutti i server di gestione e i processori di router e messaggi, devi utilizzare l'opzione -c edge.
  • Devi eseguire l'upgrade di tutti i nodi Postgres seguendo i passaggi speciali per l'upgrade di Postgres.
  • Devi aggiornare i componenti edge-qpid-server e edge-postgres-server in tutti i data center.
  • Devi eseguire l'upgrade di tutti i nodi Qpid.
  • Devi eseguire l'upgrade dei nodi dell'interfaccia utente Edge e anche dei nodi della nuova UI Edge e SSO(se applicabile).
  • Non esiste un passaggio separato per aggiornare la monetizzazione. Viene aggiornato quando specifichi l'opzione edge -c.

Upgrade autonomo a 1 nodo

Per eseguire l'upgrade di una configurazione standalone a 1 nodo alla versione 4.53.01:

  1. Aggiorna tutti i componenti: 
    /opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
  2. (Se hai installato apigee-adminapi) Aggiorna l'utilità apigee-adminapi: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

Upgrade autonomo a 2 nodi

Aggiorna i seguenti componenti per un'installazione autonoma a 2 nodi:

Consulta Topologie di installazione per l'elenco delle topologie Edge e dei numeri di nodi.

  1. Aggiorna LDAP sulla macchina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. Aggiorna Cassandra e ZooKeeper sulla macchina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. Aggiorna i componenti Edge sulla macchina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. Aggiorna Postgres sulla macchina 2: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. Aggiorna i componenti Edge sulla macchina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  6. Aggiorna Qpid sulla macchina 2: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  7. Aggiorna la UI sulla macchina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
  8. (Se hai installato apigee-adminapi) Aggiornamento dell'utilità apigee-adminapi sulla macchina 1: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  9. (Se hai installato Apigee SSO) Aggiorna Apigee SSO sulla macchina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    dove sso_config_file è il file di configurazione che hai creato quando hai installato SSO.

  10. Riavvia il componente Edge UI sul computer 1: 
    /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

Upgrade di 5 nodi

Aggiorna i seguenti componenti per un'installazione a 5 nodi:

Consulta Topologie di installazione per l'elenco delle topologie Edge e dei numeri di nodi.

  1. Aggiorna LDAP sulla macchina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. Aggiorna Cassandra e ZooKeeper sulle macchine 1, 2 e 3: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. Aggiorna i componenti Edge sulle macchine 1, 2 e 3: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. Aggiorna Postgres sulla macchina 4: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. Aggiorna Postgres sulla macchina 5: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  6. Aggiorna i componenti Edge sulle macchine 4 e 5: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. Aggiorna Qpid sulla macchina 4: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. Aggiorna Qpid sulla macchina 5: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  9. Aggiorna l'interfaccia utente di Edge:
    • UI classica:se utilizzi la UI classica, aggiorna il componente ui sulla macchina 1, come mostrato nell'esempio seguente: 
      /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
    • Nuova UI Edge: se hai installato la nuova UI Edge, aggiorna il componente ue sulla macchina appropriata (potrebbe non essere la macchina 1): 
      /opt/apigee/apigee-setup/bin/update.sh -c ue -f /opt/silent.conf
  10. (Se hai installato apigee-adminapi) Aggiornamento dell'utilità apigee-adminapi sulla macchina 1: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  11. (Se hai installato Apigee SSO) Aggiorna Apigee SSO sulla macchina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    dove sso_config_file è il file di configurazione che hai creato quando hai installato SSO.

  12. Riavvia il componente UI:
    • Interfaccia utente classica:se utilizzi l'interfaccia utente classica, riavvia il componente edge-ui sulla macchina 1, come mostrato nell'esempio seguente: 
      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart
    • Nuova UI Edge: se hai installato la nuova UI Edge, riavvia il componente edge-management-ui sulla macchina appropriata (potrebbe non essere la macchina 1): 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

Upgrade cluster a 9 nodi

Aggiorna i seguenti componenti per un'installazione in cluster a 9 nodi:

Consulta Topologie di installazione per l'elenco delle topologie Edge e dei numeri di nodi.

  1. Aggiorna LDAP sulla macchina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. Aggiorna Cassandra e ZooKeeper sulle macchine 1, 2 e 3: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. Aggiorna i componenti Edge sulle macchine 1, 4 e 5 (server di gestione, processore di messaggi, router) in questo ordine: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. Aggiorna Postgres sulla macchina 8: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. Aggiorna Postgres sulla macchina 9: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  6. Aggiorna i componenti Edge sulle macchine 6, 7, 8 e 9 in questo ordine: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. Aggiorna Qpid sulle macchine 6 e 7: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. Aggiorna la nuova UI (ue) o la UI classica (ui) sulla macchina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  9. (Se hai installato apigee-adminapi) Aggiorna l'utilità apigee-adminapi sul computer 1: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  10. (Se hai installato Apigee SSO) Aggiorna Apigee SSO sulla macchina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    dove sso_config_file è il file di configurazione che hai creato quando hai installato SSO.

  11. Riavvia il componente UI:
    • Interfaccia utente classica:se utilizzi l'interfaccia utente classica, riavvia il componente edge-ui sul computer 1, come mostrato nell'esempio seguente: 
      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart
    • Nuova UI Edge: se hai installato la nuova UI Edge, riavvia il componente edge-management-ui sulla macchina appropriata (potrebbe non essere la macchina 1): 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

Upgrade cluster a 13 nodi

Aggiorna i seguenti componenti per un'installazione in cluster a 13 nodi:

Consulta Topologie di installazione per l'elenco delle topologie Edge e dei numeri di nodi.

  1. Aggiorna LDAP sulle macchine 4 e 5: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. Aggiorna Cassandra e ZooKeeper sulle macchine 1, 2 e 3: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. Aggiorna i componenti Edge sulle macchine 6, 7, 10 e 11 in questo ordine: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. Aggiorna Postgres sulla macchina 8: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. Aggiorna Postgres sulla macchina 9: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  6. Aggiorna i componenti Edge sulle macchine 12, 13, 8 e 9 in questo ordine: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. Aggiorna Qpid sulle macchine 12 e 13: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. Aggiorna la nuova UI (ue) o la UI classica (ui) sulle macchine 6 e 7: 
    /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  9. (Se hai installato apigee-adminapi) È stato aggiornato l'utilità apigee-adminapi sui computer 6 e 7: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  10. (Se hai installato Apigee SSO) Aggiorna Apigee SSO sulle macchine 6 e 7: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    dove sso_config_file è il file di configurazione che hai creato quando hai installato SSO.

  11. Riavvia il componente UI:
    • Interfaccia utente classica:se utilizzi l'interfaccia utente classica, riavvia il componente edge-ui sulle macchine 6 e 7, come mostrato nell'esempio seguente: 
      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart
    • Nuova UI di Edge: se hai installato la nuova UI di Edge, riavvia il componente edge-management-ui sui computer 6 e 7: 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

Upgrade cluster a 12 nodi

Aggiorna i seguenti componenti per un'installazione in cluster a 12 nodi:

Consulta Topologie di installazione per l'elenco delle topologie Edge e dei numeri di nodi.

  1. Aggiorna LDAP:
    1. Macchina 1 nel data center 1 
      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
    2. Macchina 7 nel data center 2 
      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. Aggiorna Cassandra e ZooKeeper:
    1. Macchine 1, 2 e 3 nel data center 1: 
      /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
    2. Sulle macchine 7, 8 e 9 nel data center 2: 
      /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. Aggiorna i componenti di Edge:
    1. Sulle macchine 1, 2 e 3 nel data center 1: 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
    2. Sulle macchine 7, 8 e 9 nel data center 2 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. Aggiorna Postgres:
    1. Macchina 6 nel data center 1 
      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
    2. Macchina 12 nel data center 2 
      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. Aggiorna i componenti di Edge:
    1. Macchine 4, 5, 6 nel data center 1 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
    2. Macchine 10, 11, 12 nel data center 2 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  6. Aggiorna qpidd:
    1. Macchine 4 e 5 nel data center 1
      1. Aggiornamento di qpidd sulla macchina 4: 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
      2. Aggiornamento di qpidd sulla macchina 5: 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
    2. Macchine 10, 11 nel data center 2
      1. Aggiornamento qpidd sulla macchina 10: 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
      2. Aggiornamento di qpidd sulla macchina 11: 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  7. Aggiorna la nuova UI (ue) o la UI classica (ui):
    1. Macchina 1 nel data center 1: 
      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
    2. Macchina 7 nel data center 2: 
      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  8. (Se hai installato apigee-adminapi) È stato aggiornato l'utilità apigee-adminapi:
    1. Macchina 1 nel data center 1: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
    2. Macchina 7 nel data center 2: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  9. (Se hai installato Apigee SSO) Aggiorna Apigee SSO:
    1. Macchina 1 nel data center 1: 
      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
    2. Macchina 7 nel data center 2: 
      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

      3. dove sso_config_file è il file di configurazione che hai creato quando hai installato SSO.

  10. Riavvia il nuovo componente dell'interfaccia utente di Edge (edge-management-ui) o dell'interfaccia utente classica di Edge (edge-ui) sulle macchine 1 e 7: 
    /opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart

Per una configurazione non standard

Se hai una configurazione non standard, aggiorna i componenti Edge nel seguente ordine:

  1. LDAP
  2. Cassandra
  3. Zookeeper
  4. Server di gestione
  5. processore di messaggi
  6. Router
  7. Postgres
  8. Edge, ovvero il profilo "-c edge" su tutti i nodi nell'ordine: nodi con server Qpid, server Edge Postgres.
  9. qpidd
  10. UI Edge (classica o nuova)
  11. apigee-adminapi
  12. SSO Apigee

Al termine dell'aggiornamento, assicurati di riavviare il componente Edge UI su tutte le macchine che lo eseguono.