Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Aggiorna Apigee Edge 4.51.00 o 4.52.00 o 4.52.01 a 4.52.02

Apigee supporta l'upgrade di Edge for Private Cloud direttamente dalla versione 4.51.00, 4.52.00 o 4.52.01 alla versione 4.52.02. Questa pagina descrive come eseguire questi upgrade.

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

Prima di eseguire l'upgrade di Apigee Edge, assicurati di soddisfare 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 saperne di più 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
```
Nota:assicurati che la configurazione di edge-management-server nella versione esistente venga eseguita correttamente senza errori. Risolvi eventuali errori nella configurazione di edge-management-server delle versioni precedenti prima di procedere con l'upgrade.
Assicurati che la strategia di compressione di Cassandra sia LeveledCompactionStrategy
A seconda della versione attuale, esegui le modifiche necessarie alla strategia di compressione di Cassandra. Segui i passaggi riportati di seguito e poi torna alla procedura di upgrade principale:
- Se esegui l'upgrade dalla versione 4.51.00, consulta il documento sulla strategia di compattazione di Cassandra per la versione 4.51.00.
- Se esegui l'upgrade dalla versione 4.52.00, consulta il documento sulla strategia di compressione di Cassandra per la versione 4.52.00.
- Se esegui l'upgrade dalla versione 4.52.01, consulta il documento sulla strategia di compattazione di Cassandra per la versione 4.52.01.

Quali passaggi speciali considerare per l'upgrade

Per eseguire l'upgrade a Edge for Private Cloud 4.52.02, valuta la possibilità di eseguire passaggi specifici per l'upgrade di determinati software. I passaggi necessari dipendono dalla versione attuale. Consulta la tabella seguente 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.52.02
4.52.01	Cassandra
4.52.00	Zookeeper, Cassandra, Qpid
4.51.00	Zookeeper, Postgres, Cassandra, Qpid

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 verranno conservati dopo l'aggiornamento.

Esegui l'upgrade a Zookeeper 3.8.3

Edge for Private Cloud 4.52.02 non include un upgrade di Zookeeper. Tuttavia, se esegui l'upgrade da una versione precedente alla 4.52.01, devi seguire i passaggi di upgrade di Zookeeper descritti di seguito.

Se esegui l'upgrade dalle versioni 4.51.00 o 4.52.00 di Edge for Private Cloud, consulta i passaggi descritti in Upgrade obbligatorio a Zookeeper 3.8.3 per eseguire l'upgrade di Zookeeper.
Se esegui l'upgrade dalla versione 4.52.01 di Edge for Private Cloud, dovresti già utilizzare Zookeeper versione 3.8.3 e non devi seguire passaggi speciali per l'upgrade di Zookeeper.

Nota:

L'upgrade da Edge for Private Cloud 4.52.01 a 4.52.02 è semplificato perché Zookeeper e Cassandra si trovano in genere sullo stesso host o sulla stessa macchina virtuale, il che elimina la necessità di procedure di upgrade di Zookeeper separate insieme all'upgrade significativo di Cassandra.

Se Zookeeper richiede un aggiornamento con passaggi specifici, esegui l'upgrade di Zookeeper in tutti i data center aggiornando un nodo alla volta. Una volta aggiornati tutti i nodi Zookeeper a livello globale, esegui l'upgrade di Cassandra un data center alla volta, seguendo la procedura descritta più avanti in questo articolo.

Il seguente comando facilita un upgrade separato di Zookeeper:

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

Per un rollback di Zookeeper, utilizza la procedura standard di rollback di Zookeeper. Se è necessario un rollback per Cassandra o altri componenti, questi componenti devono essere sottoposti a rollback; non è richiesto un rollback di Zookeeper.

Esegui l'upgrade a Postgres 14

Se esegui l'upgrade da Edge for Private Cloud 4.51.00 alla versione 4.52.02, devi seguire i passaggi per l'upgrade di Postgres, anche se Edge for Private Cloud 4.52.02 non include un upgrade di Postgres. L'upgrade da Edge for Private Cloud 4.51.00 alla versione 4.52.02 richiede ulteriori passaggi di upgrade di Postgres. Fai riferimento alla sezione Aggiornamento obbligatorio a Postgres 14.
Se esegui l'upgrade da Edge for Private Cloud 4.52.00 o 4.52.01 alla versione 4.52.02, non sono necessari ulteriori passaggi di upgrade di Postgres.

Esegui l'upgrade a Cassandra 3.11.16

Apigee Edge for Private Cloud 4.52.02 include un upgrade di Cassandra alla versione 3.11.16. Cassandra è un componente fondamentale di Apigee e questo upgrade include anche aggiornamenti al software del driver in vari componenti di runtime e gestione utilizzati per eseguire query e scrivere in Cassandra.

Poiché si tratta di un upgrade importante, sono state necessarie alcune modifiche al modello di dati di Apigee in Cassandra per garantire prestazioni ottimali nelle versioni più recenti. Sebbene queste modifiche siano minime, il processo di upgrade interrompe alcune API di gestione quando viene avviato l'upgrade. Le API di gestione esatte che vengono generalmente interrotte sono elencate nelle sezioni pertinenti di seguito.

Inoltre, la procedura di upgrade causa interruzioni a un insieme più ampio di flussi di proxy di runtime e API di gestione nel data center in fase di upgrade. È fondamentale isolare il traffico di runtime e di gestione dal data center in fase di upgrade per ridurre al minimo le interruzioni. Per saperne di più, leggi le sezioni relative a un singolo data center e a più data center di seguito.

Nota: lo strumento cassandra-cli non è più supportato in Cassandra 3.X e non è disponibile per l'utilizzo.

Portale per gli sviluppatori - Documentazione delle API

Il portale per gli sviluppatori Drupal di Apigee offre varie funzionalità per documentare le tue API. Anche se è consigliabile abbandonare l'utilizzo del portale per sviluppatori basato su Drupal 7, se lo utilizzi ancora e sfrutti la funzionalità SmartDocs, si applica il documento Utilizzo delle API SmartDocs. Se utilizzi versioni più recenti del portale per gli sviluppatori, l'upgrade non avrà alcun impatto sulla documentazione dell'API.

Quando esegui l'upgrade di Apigee alla versione 4.52.02, tutti i modelli API creati utilizzando la funzionalità SmartDocs del portale per sviluppatori Drupal 7 non verranno migrati automaticamente alla versione più recente. Devi esportare manualmente ogni modello utilizzando il portale per gli sviluppatori e importarlo di nuovo dopo aver completato l'upgrade.

Terminologia utilizzata di seguito

Runtime:il runtime comprende la gestione del traffico proxy runtime. Include tutte le operazioni eseguite dai router e dai processori di messaggi per elaborare in modo efficace una richiesta API di runtime per i proxy esistenti. Tuttavia, non include il deployment di nuovi proxy o nuove revisioni dei proxy.

Gestione:la gestione include l'amministrazione del sistema Apigee Edge. Sono inclusi, a titolo esemplificativo, deployment, modifiche di app, prodotti, server di destinazione, keystore e così via. Tutte le API di gestione (e i relativi client, come l'interfaccia utente Apigee e il portale per gli sviluppatori) sono incluse in questo ambito.

Durante questo upgrade, il traffico di runtime e di gestione viene interessato nella regione o nel data center in cui viene eseguito l'aggiornamento. Indipendentemente dal data center in fase di aggiornamento, alcune API di gestione in tutti i data center sono interessate. Questo impatto viene annotato dopo ogni passaggio.

In ogni passaggio riportato di seguito, lo stato di runtime e gestione viene descritto man mano che avanzi nelle varie fasi della procedura di upgrade.

Strategie di upgrade

Più data center

L'upgrade deve essere eseguito un data center alla volta per garantire la continuità del traffico ed evitare tempi di inattività. Prima di eseguire l'upgrade di un controller di dominio, il traffico deve essere reindirizzato ad altri controller di dominio funzionali.

Nota:

Per evitare l'impatto sul traffico durante l'upgrade, segui un approccio data center per data center (DC per DC) reindirizzando temporaneamente il traffico dal data center in fase di upgrade. Ciò garantisce un processo di upgrade controllato per Cassandra, Management Server e nodi di runtime, mantenendo al contempo la disponibilità del servizio.

Per una configurazione con due data center, segui questi passaggi di alto livello:

Reindirizza il traffico da DC-1 a DC-2 e blocca il traffico in entrata a DC-1.
Esegui l'upgrade di DC-1, inclusi Cassandra, Management Server e Runtime components.
Reindirizza il traffico a DC-1 e blocca il traffico in entrata a DC-2.
Esegui l'upgrade di DC-2, inclusi Cassandra, Management Server e componenti di runtime.

Questo processo garantisce una gestione del traffico senza interruzioni durante l'upgrade. Un pattern simile deve essere seguito per le configurazioni con più di due data center, in cui il traffico viene reindirizzato temporaneamente ai data center di cui è stato eseguito l'upgrade completo o di cui non è ancora stato eseguito l'upgrade.

Singolo data center

Per una configurazione a un solo data center, la procedura di upgrade avrà un impatto significativo sul traffico di runtime e su alcune API di gestione. Per una configurazione a un solo data center sono disponibili le seguenti opzioni.

Espandi il cluster Edge for Cloud privato a un data center temporaneo aggiungendo un data center accanto a quello esistente per gestire il traffico durante l'upgrade, poi dismetti uno dei data center al termine della procedura di upgrade.
Se non riesci a eseguire l'espansione a un data center aggiuntivo, preparati al downtime e pianifica l'upgrade durante i periodi di traffico ridotto per ridurre al minimo l'impatto sulle API di gestione e sul traffico di runtime.

È consigliabile espandersi a un data center aggiuntivo per evitare l'impatto sul traffico di runtime e sulle API di gestione. Durante l'upgrade, gli impatti sul data center in fase di upgrade includono, a titolo esemplificativo, le seguenti aree:

API Runtime che aggiornano i token OAuth
API di runtime che utilizzano il criterio dell'entità di accesso
Elenco delle API di gestione delle app per sviluppatori
API di gestione che elencano i prodotti

L'impatto descritto sopra si aggiunge alle API di gestione specifiche che rimarranno non funzionanti in tutti i data center finché non verranno eseguiti gli upgrade. Queste API di gestione sono elencate nei passaggi delle sezioni successive.

Rollback - livello generale

Impatto durante il rollback
Il rollback da Cassandra 3.11.x a 2.1.x influisce sul traffico di runtime e di gestione all'interno del data center (DC) in cui viene eseguito il rollback. Inoltre, alcune API di gestione potrebbero subire interruzioni in tutti i data center, indipendentemente da quale DC venga attualmente eseguito il rollback.
Segui l'approccio di rollback DC per DC
Il rollback deve essere eseguito un data center alla volta per mantenere la continuità del servizio ed evitare tempi di inattività. Prima di avviare il rollback in un data center specifico, assicurati che il traffico dell'applicazione venga reindirizzato a un altro data center completamente operativo.
Rollback del cluster aggiornato parzialmente
Se almeno un data center rimane completamente operativo sulla versione precedente di Cassandra (2.1.22), è possibile eseguire il rollback degli altri data center aggiornati eseguendo una ricompilazione dal data center Cassandra 2.1.X completamente funzionante.
Rollback a livello di cluster
Se è stato eseguito l'upgrade dell'intero cluster Cassandra ed è necessario il rollback, questo deve essere eseguito utilizzando i backup o gli snapshot delle VM. Questo approccio è complesso e probabilmente comporterà tempi di inattività temporanei o perdita di dati.
Considerazioni pre-upgrade
È importante acquisire familiarità con le procedure di rollback prima di tentare l'upgrade. È fondamentale considerare le sfumature del rollback durante l'upgrade per garantire la disponibilità di percorsi di rollback appropriati.

Eseguire il rollback dei cluster con un singolo data center

L'upgrade di Cassandra dalla versione 2.1.x alla 3.11.x può influire in modo significativo sul traffico di runtime e su alcune API di gestione. Questi impatti si verificano anche durante il rollback e potrebbero causare tempi di inattività o perdita di dati.

Per i carichi di lavoro di produzione, è vivamente consigliato di provisionare un nuovo data center prima dell'upgrade. Ciò consente un percorso di rollback più sicuro senza perdita di dati o interruzioni del traffico API. Il data center aggiuntivo può essere ritirato dopo il completamento dell'upgrade.

Se l'aggiunta di un nuovo data center non è fattibile, ma è comunque necessaria la funzionalità di rollback, assicurati di eseguire backup affidabili prima dell'upgrade. Il ripristino di Cassandra 2.1.x dai backup è possibile, ma questo approccio potrebbe comportare tempi di inattività del servizio e potenziale perdita di dati.

Eseguire il rollback dei cluster con più data center

Il rollback di più data center segue un approccio data center per data center. Con questo approccio, il traffico del data center di cui viene eseguito il rollback viene reindirizzato ad altri data center funzionali, garantendo un processo di rollback controllato e isolato per Cassandra, Management Server e nodi di runtime per evitare interruzioni del traffico.

Per maggiori dettagli, consulta la sezione Eseguire il rollback dell'aggiornamento di Cassandra 3.11.16.

Passaggio 0: stato iniziale

I componenti Zookeeper, Postgres e LDAP sono già stati aggiornati alle versioni 4.52.02. Edge per un cluster cloud privato è stabile e funzionante. Se è necessario il rollback, il cluster verrà ripristinato a questo stato.
Cassandra in Apigee in esecuzione con la versione 2.1.22.
Componenti edge:

Il server di gestione comunica con Cassandra tramite il protocollo Thrift precedente.
Server di runtime (processori di messaggi e router) che comunicano con Cassandra tramite il protocollo Thrift precedente.

Stato del runtime in questa fase	Stato della gestione in questa fase
Runtime completamente funzionante	Gestione completamente funzionante

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 attivare gli upgrade dei componenti.

Modifica Cassandra in modo che utilizzi LeveledCompactionStrategy.
Esegui il backup di Cassandra utilizzando Apigee.
Acquisisci snapshot VM dei nodi Cassandra (se fattibile).
Crea un file di configurazione dell'upgrade di Cassandra su ogni nodo Cassandra in /opt/apigee/apigee-cassandra/cass_upgrade.conf con il seguente contenuto:
```
# IP Address of node
HOSTIP=10.0.0.1

# Username for running Cassandra queries. Optional. Can be skipped if you have not enabled Cassandra authentication.
CASS_USERNAME=<cassuser>

# Password for running Cassandra queries. Optional. Can be skipped if you have not enabled Cassandra authentication.
CASS_PASSWORD=<casspass>

# Port for connecting to Cassandra via thrift. Optional. Defaults to 9160 if skipped.
CASS_PORT=9160

# Port for connecting to Cassandra via CQL. Optional. Defaults to 9042 if skipped.
CASS_CQL_PORT=9042

# Directory to be used by Cassandra upgrade scripts. Optional. Defaults to /tmp/cass_upgrade_scripts if skipped.
# Note that if upgrade is successful, this directory is deleted via root user - so provide a directory accordingly.
CASS_TMP_DIR=/tmp/cass_upgrade_scripts
    
```
Se non è possibile creare il file in /opt/apigee/apigee-cassandra/cass_upgrade.conf, crea il file /opt/silent.conf con gli stessi contenuti su ogni nodo Cassandra.
Attenzione:il programma di installazione dell'upgrade di Apigee cercherà il file nelle posizioni elencate sopra. Se il file non è presente in nessuna delle posizioni elencate sopra, l'upgrade non andrà a buon fine e verrà visualizzato un messaggio simile a quello riportato di seguito:
```
could not read env location: '/opt/apigee/apigee-cassandra/cass_upgrade.conf'
file does not exist or cannot be sourced
could not read env location: '/opt/silent.conf'
file does not exist or cannot be sourced
```
In questo caso, l'upgrade non andrà a buon fine, ma è probabile che il servizio Cassandra sul nodo sia in stato di arresto. Puoi avviare il servizio Cassandra come di consueto e riprovare l'upgrade inserendo il file di configurazione in una delle posizioni previste. Inoltre, se il file viene trovato ma le configurazioni fornite non sono corrette (ad esempio, le credenziali Cassandra non sono corrette), l'upgrade non andrà a buon fine e verrà visualizzato un errore come il seguente:
```
Error in PREIN scriptlet in rpm package apigee-cassandra-X.XX.XX-X.X.XXXX.noarch
```
In questo caso, avvia il servizio Cassandra se è stato interrotto quando l'upgrade non è riuscito e riprova l'upgrade dopo aver corretto le configurazioni nel file.
Se utilizzi la funzionalità SmartDocs del portale per sviluppatori Apigee Drupal 7, esporta ciascuno dei tuoi modelli scaricandoli in formato JSON dall'interfaccia utente del portale per sviluppatori. Questi modelli dovranno essere reimportati in Apigee dopo l'aggiornamento dei server di gestione.
Assicurati che le porte 9160 e 9042 siano accessibili da tutti i componenti Edge ai nodi Cassandra, se non sono già presenti. Per saperne di più, consulta i requisiti relativi alle porte.

Passaggio 2: reindirizza il traffico lontano dal primo data center

Blocca il traffico di runtime e di gestione in entrata dal primo data center.
Reindirizza tutto il traffico di runtime e le API di gestione agli altri data center funzionali.
Verifica che il traffico di runtime e di gestione venga gestito correttamente dagli altri data center.

Passaggio 3: esegui l'upgrade di tutti i nodi Cassandra nel primo data center

Esegui l'upgrade di tutti i nodi Cassandra nel data center uno alla volta. Esegui i seguenti comandi su ogni nodo uno alla volta:
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```

Una volta aggiornato un nodo, esegui il seguente comando sul nodo per eseguire alcune convalide prima di procedere:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra validate_upgrade -f configFile

L'output sarà simile a questo:

Cassandra version is verified - [cqlsh 5.0.1 | Cassandra 3.11.16 | CQL spec 3.4.4 | Native protocol v3] Metadata is verified

Esegui il seguente comando post_upgrade su ogni nodo Cassandra uno alla volta dopo il completamento dell'upgrade:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade
```

Stato del runtime in questa fase	Stato della gestione in questa fase
Traffico di runtime bloccato nei data center in fase di upgrade Runtime completamente funzionante su altri data center	Traffico di gestione bloccato sui data center in fase di upgrade. La seguente funzione di gestione viene degradata dopo l'upgrade di Cassandra in altri data center: API di gestione per creare un prodotto API con ambiente API di gestione per aggiornare un prodotto API con l'ambiente API Management per eliminare un'organizzazione

Passaggio 4: esegui l'upgrade di tutti i nodi di gestione nel primo data center

Esegui l'upgrade di tutti i nodi di gestione nel data center:

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

Stato del runtime in questa fase	Stato della gestione in questa fase
Traffico di runtime bloccato nei data center in fase di upgrade Runtime completamente funzionante	Traffico di gestione bloccato sui data center in fase di upgrade. La seguente funzione di gestione viene degradata dopo l'upgrade di Cassandra: API di gestione per creare un prodotto API con ambiente API di gestione per aggiornare un prodotto API con l'ambiente API Management per eliminare un'organizzazione

Passaggio 5: esegui l'upgrade di tutti i nodi di runtime nel primo data center

Esegui l'upgrade di tutti i nodi Router e processore di messaggi nel data center uno alla volta:

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

Stato del runtime in questa fase	Stato della gestione in questa fase
Traffico di runtime bloccato nei data center in fase di upgrade Runtime completamente funzionante su altri data center	Traffico di gestione bloccato sui data center in fase di upgrade. La seguente funzione di gestione viene degradata dopo l'upgrade di Cassandra in altri data center: API di gestione per creare un prodotto API con ambiente API di gestione per aggiornare un prodotto API con l'ambiente API Management per eliminare un'organizzazione

Passaggio 6: reindirizza il traffico al primo data center

Una volta eseguito l'upgrade del primo data center con Cassandra, i componenti di runtime e il server di gestione, riattiva il traffico di runtime e di gestione verso il primo data center.
Assicurati che il traffico di runtime e di gestione vada a buon fine nei vari data center.

Passaggio 7: esegui l'upgrade di altri data center

Ripeti i passaggi da 1 a 6 sugli altri data center, uno alla volta, reindirizzando il traffico lontano da questi data center, aggiornando il software Apigee e riattivando il traffico su questi data center.

Passaggio 8: esegui di nuovo il passaggio di upgrade in tutti i nodi di gestione

Esegui di nuovo il seguente comando di upgrade in tutti i nodi di gestione nei data center:

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

Passaggio 9 - [Facoltativo] Importa gli smartdoc esportati in precedenza

Una volta eseguito l'upgrade di tutti i server di gestione, puoi importare i modelli di documenti intelligenti che hai esportato nel passaggio 1. Puoi decidere di farlo in un secondo momento.

Devi farlo solo se utilizzi un portale per sviluppatori basato su Drupal 7 e la funzionalità Smart Docs.

Stato del runtime in questa fase	Stato della gestione in questa fase
Runtime completamente funzionante	Gestione completamente funzionante

Passaggio 10: elimina le tabelle non utilizzate

Esegui il comando seguente per eliminare le tabelle inutilizzate precedenti dal cluster Cassandra. Finché non viene eseguito, non puoi utilizzare determinate funzionalità di Cassandra (come la configurazione di una nuova autenticazione; i vecchi meccanismi di autenticazione continueranno a funzionare). Questo comando può essere eseguito solo su un nodo del cluster

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra drop_old_tables -f configFile

Passaggio 11: esegui l'upgrade di tutti gli altri componenti Edge rimanenti per Private Cloud 4.52.02

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

A questo punto, se esegui l'upgrade da versioni precedenti a Edge for Private Cloud 4.52.01 come di seguito per eseguire passaggi aggiuntivi per l'upgrade di Qpid e Postgres rispettivamente ed esegui l'upgrade dei componenti rimanenti seguendo questi passaggi.

Esegui l'upgrade a Qpid J-Broker

Anche se Edge for Private Cloud 4.52.02 non include un upgrade a Qpid, se esegui l'upgrade da versioni precedenti alla 4.52.01, devi seguire i passaggi per eseguire l'upgrade di QPID.

Se esegui l'upgrade da Edge for Private Cloud 4.51.00 o 4.52.00 alla versione 4.52.02, è necessario seguire passaggi aggiuntivi per l'upgrade di Qpid. Se esegui l'upgrade dalla versione 4.51.00 o 4.52.00 alla 4.52.02, consulta la sezione Eseguire l'upgrade di Qpid.
Se esegui l'upgrade da Edge for Private Cloud 4.52.01 alla versione 4.52.02, dovresti già utilizzare l'ultima versione di Qpid Broker e non sono necessari ulteriori passaggi di Qpidupgrade.

Nuova UI di Edge

Questa sezione elenca le considerazioni relative all'interfaccia utente Edge. 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 per 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.

Aggiorna l'interfaccia utente di Edge

Per aggiornare il componente UI di Edge, considera la versione di Edge per Private Cloud da cui esegui l'upgrade:

Dalla versione 4.51.00 alla 4.52.00 (con la nuova UI Edge già installata): utilizza le istruzioni di upgrade in questa sezione per il componente edge-management-ui.

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 l'ultima volta.

Se l'errore richiede il rollback dell'aggiornamento alla versione precedente, consulta Eseguire il rollback della versione 4.52.00 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 non hai 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 aggiungi nuovamente il router al bilanciatore del carico.

Aggiorna le macchine nell'ordine corretto per la tua installazione, come descritto in Ordine di aggiornamento delle macchine.
Quando è il momento di aggiornare i router, seleziona un router qualsiasi e rendilo irraggiungibile, come descritto in Attivazione/Disattivazione della connettività del server (processore di messaggi/Router).
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.
Rendere di nuovo raggiungibile il router.
Ripeti i passaggi da 2 a 4 per i router rimanenti.
Continua l'aggiornamento per le macchine rimanenti nell'installazione.

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

Sul nodo combinato Router e processore di messaggi:
- Prima dell'aggiornamento, esegui le seguenti operazioni:
  1. Rendi irraggiungibile il router.
  2. Rendi irraggiungibile il processore di messaggi.
- Dopo l'aggiornamento, esegui le seguenti operazioni:
  1. Rendi raggiungibile il processore di messaggi.
  2. Rendi raggiungibile il router.
Sui singoli nodi del router:
- Prima dell'aggiornamento, rendi il router irraggiungibile.
- Dopo l'aggiornamento, rendi raggiungibile il router.
Sui singoli nodi Message Processor:
- Prima dell'aggiornamento, rendi irraggiungibile il processore di messaggi.
- Dopo l'aggiornamento, rendi raggiungibile il processore di messaggi.

Utilizzare un file di configurazione invisibile

Devi trasmettere un file di configurazione non interattivo al comando di aggiornamento. Il file di configurazione automatica deve essere lo stesso che hai utilizzato per installare Edge 4.50.00 o 4.51.00.

Esegui l'aggiornamento alla versione 4.52.02 su un nodo con una connessione a internet esterna

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

Se presenti, disattiva tutti i job cron configurati per eseguire un'operazione di riparazione su Cassandra fino al completamento dell'aggiornamento.
Accedi al nodo come root per installare gli RPM di Edge.
NOTA: anche se l'installazione di RPM richiede l'accesso root, puoi eseguire la configurazione di Edge senza accesso root.
Installa yum-utils e yum-plugin-priorities:
Nota: se il tuo sistema operativo è RHEL 8.0 - 8.6, salta questo passaggio.
```
sudo yum install yum-utils
sudo yum install yum-plugin-priorities
```
Disattiva SELinux come descritto in Installare l'utilità apigee-setup di Edge.
Se l'installazione viene eseguita su Oracle 7.x, esegui questo comando:
```
sudo yum-config-manager --enable ol7_optional_latest
```

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

Se attualmente utilizzi Edge 4.51.00:
1. Scarica il file bootstrap_4.52.02.sh di Edge in /tmp/bootstrap_4.52.02.sh:
```
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh
```
2. Installa l'utilità Edge 4.52.02 apigee-service e le dipendenze eseguendo il seguente comando:
```
sudo bash /tmp/bootstrap_4.52.02.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 l'interfaccia utente 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.50.00 o 4.51.00.
  Puoi eseguire update.sh su tutti i componenti impostando component su "all", ma solo se hai un profilo di installazione Edge all-in-one (AIO). 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. Verifica l'aggiornamento eseguendo l'utilità apigee-validate sul server di gestione, come descritto in Verificare l'installazione.

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

Aggiornamento alla versione 4.52.02 da un repository locale

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

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.52.02:

Crea un repository locale 4.52.02 come descritto in "Crea un repository Apigee locale" in Installa l'utilità apigee-setup di Edge.
NOTA: se hai già un repository esistente, puoi aggiungervi il repository 4.52.02 come descritto in "Aggiornare un repository Apigee locale" in Installare l'utilità apigee-setup di Edge.
Per installare apigee-service da un file .tar:
1. Sul nodo con il repository locale, utilizza il comando seguente per creare il pacchetto del repository locale in un unico file .tar denominato /opt/apigee/data/apigee-mirror/apigee-4.52.02.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.52.02.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.52.02.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos
```
  Tieni presente che in questo comando includi il percorso della directory dei repository.
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.52.02.sh in /tmp/bootstrap_4.52.02.sh:
```
/usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.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.52.02.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://
```
  dove uName:pWord sono il nome utente e la password del repository.
Utilizza apigee-service per aggiornare l'utilità apigee-setup, come mostrato nell'esempio seguente:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup update 
```
Aggiorna l'utilità apigee-validate sul server di gestione, come mostrato nell'esempio seguente:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
```
Aggiorna l'utilità apigee-provision sul server di gestione, come mostrato nell'esempio seguente:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
```
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 l'interfaccia utente 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.50.00 o 4.51.00.
  NOTA:il file di configurazione deve essere leggibile dall'utente "apigee". Per cambiare il proprietario, utilizza il seguente comando:
```
chown apigee:apigee configFile
```
Puoi eseguire update.sh su tutti i componenti impostando component su "all", ma solo se hai un profilo di installazione Edge all-in-one (AIO). Ad esempio:
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f /tmp/sa_silent_config
```
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
```
Verifica l'aggiornamento eseguendo l'utilità apigee-validate sul server di gestione, come descritto in Verificare l'installazione.

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

Ordine di aggiornamento della macchina: upgrade dalla versione 4.51.00 (o) 4.52.00 (o) 4.52.01

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

Devi aggiornare tutti i nodi ZooKeeper nei data center prima di eseguire l'upgrade di tutti gli altri componenti. Se esegui l'upgrade da Edge Private Cloud 4.51.00 (o) 4.52.00, dovrai anche seguire passaggi aggiuntivi per eseguire l'upgrade di Zookeeper.
Devi aggiornare PostgreSQL in tutti i data center. Se esegui l'upgrade da Edge Private Cloud 4.51.00, dovrai anche seguire passaggi aggiuntivi per eseguire l'upgrade di PostgreSQL.
Devi aggiornare i nodi LDAP in tutti i data center.
Devi aggiornare tutti i nodi Cassandra, Management Server, processore di messaggi e Router, un data center alla volta, finché tutti i data center non vengono aggiornati.
Devi aggiornare i componenti edge-qpid-server e edge-postgres-server in tutti i data center.
Devi eseguire l'upgrade dei nodi Qpid in tutti i data center. Se esegui l'upgrade da Edge Private Cloud 4.51.00 (o) 4.52.00, dovrai anche seguire passaggi aggiuntivi per eseguire l'upgrade di Qpid.
Aggiorna Edge UI e New Edge UI, nodi SSO in tutti i data center.
Non esiste un passaggio separato per aggiornare la monetizzazione. Viene aggiornato quando specifichi l'opzione edge -c.
Nota:dopo aver aggiornato il componente UI di Edge, devi riavviare il servizio UI di Edge, come descritto nelle istruzioni di installazione dell'aggiornamento.

Upgrade autonomo a 1 nodo

Per eseguire l'upgrade di una configurazione autonoma a 1 nodo alla versione 4.52.02:

Aggiorna tutti i componenti:

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

(Se hai installato apigee-adminapi) È stato aggiornato 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.

Aggiorna Zookeeper sulla macchina 1:

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

Aggiorna Postgres sulla macchina 2:

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

Aggiorna LDAP sulla macchina 1:

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

Aggiorna Cassandra sulla macchina 1:

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

Aggiorna i componenti Edge sulle macchine 1 e 2:

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

Aggiorna Qpid sulla macchina 2:

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

Aggiorna la UI sulla macchina 1:

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

(Se hai installato apigee-adminapi) Aggiornamento dell'utilità apigee-adminapi sulla macchina 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(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.

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.

Aggiorna ZooKeeper sulle macchine 1, 2 e 3:

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

Aggiorna Postgres sulla macchina 4:

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

Aggiorna Postgres sulla macchina 5:

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

Aggiorna LDAP sulla macchina 1:

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

Aggiorna Cassandra sulle macchine 1, 2 e 3:

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

Aggiorna i componenti Edge sulle macchine 1, 2, 3, 4, 5:

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

Aggiorna Qpid sulla macchina 4:

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

Aggiorna Qpid sulla macchina 5:

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

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
```
(Se hai installato apigee-adminapi) Aggiornamento dell'utilità apigee-adminapi sulla macchina 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(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.
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 del 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.

Aggiorna ZooKeeper sulle macchine 1, 2 e 3:

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

Aggiorna Postgres sulla macchina 8:

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

Aggiorna Postgres sulla macchina 9:

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

Aggiorna LDAP sulla macchina 1:

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

Aggiorna Cassandra sulle macchine 1, 2 e 3:

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

Aggiorna i componenti Edge sulle macchine 1, 4, 5, 6, 7, 8 e 9 in questo ordine:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Aggiorna Qpid sulle macchine 6 e 7:

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

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
```
(Se hai installato apigee-adminapi) Aggiorna l'utilità apigee-adminapi sul computer 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(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.
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 del 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.

Aggiorna ZooKeeper sulle macchine 1, 2 e 3:

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

Aggiorna Postgres sulla macchina 8:

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

Aggiorna Postgres sulla macchina 9:

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

Aggiorna LDAP sulle macchine 4 e 5:

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

Aggiorna Cassandra sulle macchine 1, 2 e 3:

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

Aggiorna i componenti Edge sulle macchine 6, 7, 10, 11, 12, 13, 8 e 9 in questo ordine:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Aggiorna Qpid sulle macchine 12 e 13:

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

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
```
(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
```
(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.
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 del 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.

Aggiorna ZooKeeper sulle macchine 1,2,3,7,8,9 in entrambi i data center:
```
/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
```
Aggiorna Postgres sulle macchine 6 e 12 in entrambi i data center:
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
Aggiorna LDAP sulle macchine 1 e 7 in entrambi i controller di dominio:
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
Blocca il traffico in DC-1 e assicurati che tutto il traffico venga reindirizzato a DC-2

Aggiorna Aggiorna Cassandra sulla macchina 1,2,3 in DC-1:

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

Aggiorna il server di gestione sulla macchina 1 in DC-1:

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

Aggiorna Router, Message Processor sulle macchine 2 e 3 in DC-1:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
Sblocca il traffico in DC-1, convalida DC-1 e procedi con DC-2 bloccando il traffico in DC-2 e reindirizzandolo a DC-1.

Aggiorna Cassandra sulle macchine 7, 8 e 9 in DC-2:

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

Aggiorna il server di gestione sulla macchina 7 in DC-2:

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

Aggiorna il router e il processore di messaggi sulle macchine 8 e 9 in DC-2:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
Sblocca il traffico in DC-2 e ora entrambi i DC gestiranno il traffico
Esegui di nuovo il comando di aggiornamento in tutti i server di gestione nei data center sulle macchine 1 e 7:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
Aggiorna edge-qpid-server e edge-postgres-server sulle macchine 4,5,6,10,11,12 in entrambi i data center:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
Aggiorna Qpid sulle macchine 4, 5, 10 e 11 in entrambi i data center:
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
Aggiorna la nuova UI (ue) o la UI classica (ui) in entrambi i DC:
```
/opt/apigee/apigee-setup/bin/update.sh -c  [ui|ue] -f configFile
```
(Se hai installato apigee-adminapi) Aggiorna apigee-adminapi in entrambi i data center:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(Se hai installato Apigee SSO) Aggiorna i nodi Apigee SSO in entrambi i data center:
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f configFile
```
Riavvia il nuovo componente dell'interfaccia utente Edge (edge-management-ui) o dell'interfaccia utente Edge classica (edge-ui) in entrambi i data center:
```
/opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart
```