Questa pagina è stata tradotta dall'API Cloud Translation.

Eseguire il rollback di Apigee Edge 4.53.01

Se si verifica un errore durante un aggiornamento a Edge 4.53.01, puoi eseguire il rollback del componente che ha causato l'errore e riprovare l'aggiornamento.

Puoi eseguire il rollback di Edge 4.53.01 a una delle seguenti versioni principali:

Versione 4.53.00
Versione 4.52.02

Il rollback di una versione comporta il rollback di ogni componente che potresti aver aggiornato. Inoltre, a seconda della versione da cui hai iniziato, potresti dover considerare passaggi speciali prima di eseguire il rollback di determinati componenti software. La tabella seguente elenca i vari componenti software per i quali potrebbero essere necessari passaggi speciali durante il rollback:

Esegui il rollback alla versione	Considerazione speciale per il software
4.53.00	Zookeeper, Postgres, LDAP
4.52.02	Zookeeper, Cassandra, Postgres, LDAP

Ecco lo scenario in cui potresti voler eseguire un rollback:

Esegui il rollback a una release principale o secondaria precedente. Ad esempio, da 4.53.01 a 4.53.00.

Per maggiori informazioni, consulta la sezione Procedura di rilascio di Apigee Edge.

Ordine di rollback

Il rollback dei componenti deve essere eseguito nell'ordine inverso rispetto all'upgrade, ad eccezione dei server di gestione, per i quali il rollback deve essere eseguito dopo Cassandra. Un tipico ordine generale di rollback per Private Cloud 4.53.01 sarà simile al seguente:

Esegui il rollback di Qpid, di altri componenti correlati ad Analytics e di Postgres.
Esegui il rollback dei router e dei processori di messaggi
Rollback di Cassandra, Zookeeper
Esegui il rollback del server di gestione
Rollback LDAP

Ad esempio, supponiamo di aver eseguito l'upgrade dell'intero cluster Cassandra, di tutti i server di gestione e di alcuni RMP alla versione 4.53.01 dalla versione 4.52.02 e di voler eseguire il rollback. In questo caso, dovresti:

Esegui il rollback di tutti gli RMP uno alla volta
Eseguire il rollback dell'intero cluster Cassandra utilizzando i backup
Esegui il rollback dei nodi del server Edge Management uno alla volta

Chi può eseguire un rollback

L'utente che esegue il rollback deve essere lo stesso che ha aggiornato originariamente Edge o un utente che esegue l'accesso come root.

Per impostazione predefinita, i componenti Edge vengono eseguiti come utente "apigee". In alcuni casi, potresti eseguire i componenti Edge come utenti diversi. Ad esempio, se il router deve accedere a porte privilegiate, come quelle inferiori a 1000, devi eseguirlo come root o come utente con accesso a queste porte. In alternativa, potresti eseguire un componente come un utente e un altro componente come un altro utente.

Componenti con codice comune

I seguenti componenti di Edge condividono un codice comune. Pertanto, per eseguire il rollback di uno qualsiasi di questi componenti su un nodo, devi eseguire il rollback di tutti i componenti presenti sul nodo.

edge-management-server (server di gestione)
edge-message-processor (processore di messaggi)
edge-router (router)
edge-postgres-server (server Postgres)
edge-qpid-server (Qpid Server)

Ad esempio, se hai installato Management Server, Router e Message Processor sul nodo, per eseguire il rollback di uno di questi tre componenti devi eseguire il rollback di tutti e tre.

Rollback di Cassandra

Quando viene eseguito un upgrade principale di Cassandra su un nodo specifico, Cassandra modifica lo schema dei dati archiviati su quel nodo. Di conseguenza, un rollback diretto sul posto non è fattibile.

Scenari di rollback

Cassandra 4.0.X, disponibile con Edge for Private Cloud 4.53.01, è compatibile con altri componenti di Private Cloud 4.52.02.

Consulta la tabella seguente per un riepilogo delle varie strategie di rollback che puoi utilizzare:

Scenario	Strategia di rollback
Singolo DC, alcuni nodi Cassandra di cui è stato eseguito l'upgrade	Utilizzare i backup
Singolo DC, tutti i nodi Cassandra aggiornati	Non eseguire il rollback di Cassandra. È possibile eseguire il rollback di altri componenti.
Singolo DC, tutti i nodi (Cassandra e altri) aggiornati	Non eseguire il rollback di Cassandra. È possibile eseguire il rollback di altri componenti.
Più DC, alcuni nodi in una DC di cui è stato eseguito l'upgrade	Ricostruire a partire da una CD esistente
Più data center, tutti i nodi Cassandra in alcuni data center sono stati aggiornati	Ricostruire a partire da una CD esistente
Più nodi Cassandra DC, DC di cui è in corso l'upgrade	Prova a completare l'upgrade. Se non è fattibile, esegui il rollback di un controller di dominio utilizzando il backup. Ricostruisci le CD rimanenti dalla CD di cui è stato eseguito il rollback.
Più data center, tutti i nodi Cassandra aggiornati	Non eseguire il rollback di Cassandra. È possibile eseguire il rollback di altri componenti.
Più data center, tutti i nodi (Cassandra e altri) sono stati aggiornati	Non eseguire il rollback di Cassandra. È possibile eseguire il rollback di altri componenti.

Considerazioni generali

Quando valuti un rollback, tieni presente quanto segue:

Rollback dei componenti di runtime o di gestione:se vuoi eseguire il rollback di componenti come edge-management-server, edge-message-processor o qualsiasi componente non Cassandra alla versione 4.52.02 di Private Cloud, ti consigliamo di NON eseguire il rollback di Cassandra. Cassandra fornito con Private Cloud 4.53.00 è compatibile con tutti i componenti non Cassandra di Edge per Private Cloud 4.52.02. Puoi eseguire il rollback dei componenti non Cassandra utilizzando la metodologia elencata qui, mentre Cassandra rimane alla versione 4.0.13.
Rollback dopo l'upgrade dell'intero cluster Cassandra alla versione 4.0.X: se l'intero cluster Cassandra viene aggiornato alla versione 4.0.X nell'ambito dell'upgrade a Private Cloud versione 4.53.00, ti consigliamo di continuare con la configurazione del cluster e di NON eseguire il rollback di Cassandra. Componenti come edge-management-server, edge-message-processor, edge-router e così via della versione 4.52.02 di Private Cloud sono compatibili con Cassandra versione 4.0.X.
Rollback di Cassandra durante l'upgrade di Cassandra:se riscontri problemi durante l'upgrade di Cassandra, potresti prendere in considerazione un rollback. Le strategie di rollback elencate in questo articolo possono essere seguite in base allo stato in cui ti trovi durante la procedura di upgrade.
Rollback utilizzando i backup:i backup eseguiti da Cassandra 4.0.X non sono compatibili con i backup di Cassandra 3.11.X. Per eseguire il rollback di Cassandra utilizzando il ripristino del backup, devi eseguire i backup di Cassandra 3.11.X prima di tentare l'upgrade.

Eseguire il rollback di Cassandra utilizzando la ricompilazione

Prerequisiti

Stai gestendo un cluster Edge for Private Cloud 4.52.02 in più data center.
Stai eseguendo l'upgrade di Cassandra dalla versione 3.11.X alla 4.0.X e hai riscontrato problemi durante l'upgrade.
Nel cluster è presente almeno un data center completamente funzionante che esegue ancora la versione precedente di Cassandra (Cassandra 3.11.X).

Questa procedura si basa sullo streaming di dati da un data center esistente. Potrebbe richiedere molto tempo, a seconda della quantità di dati archiviati in Cassandra. Devi prepararti a deviare il traffico di runtime da questo data center durante il rollback.

Passaggi di alto livello

Seleziona un data center (aggiornato parzialmente o completamente) di cui vuoi eseguire il rollback. Devia il traffico di runtime verso un altro data center funzionante.
Identifica il nodo seed nel data center e inizia con uno dei nodi seed.
Arresta, disinstalla e pulisci il nodo Cassandra.
Installa la versione precedente di Cassandra sul nodo e configurala in base alle esigenze.
Rimuovi le configurazioni aggiuntive aggiunte in precedenza.
Ripeti i passaggi precedenti per tutti i nodi seed nel data center, uno alla volta.
Ripeti i passaggi precedenti per tutti i nodi Cassandra rimanenti nel data center, uno alla volta.
Ricostruisci i nodi dal data center funzionale esistente, uno alla volta.
Riavvia tutti i componenti edge-* nel data center connessi a Cassandra.
Testa e reindirizza il traffico a questo data center.
Ripeti i passaggi per ogni data center, uno alla volta.

Procedura dettagliata

Scegli un data center in cui vengono eseguiti l'upgrade di tutti o di alcuni nodi Cassandra. Devia tutto il traffico proxy di runtime e il traffico di gestione da questo data center mentre viene eseguito il rollback dei nodi Cassandra in questo data center. Assicurati che tutti i nodi Cassandra siano nello stato UN (Up/Normal) quando il comando nodetool ring viene eseguito sui nodi. Se alcuni nodi non sono attivi, risolvi il problema e riattivali prima di continuare.

Vedi il seguente esempio:

/opt/apigee/apigee-cassandra/bin/nodetool status
Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC1-1IP1  456.41 KiB  1            100.0%            78fc4ddd-2ed9-4a8c-98a2-63a38c2f1920  ra-1
UN  DC1-1IP2  870.93 KiB  1            100.0%            160db01a-64ab-43a7-b9ea-3b7f8f66d52b  ra-1
UN  DC1-1IP3  824.08 KiB  1            100.0%            21d61543-d59e-403a-bf5d-bfe7f664baa6  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC2-1IP1   802.08 KiB  1            100.0%            583e0576-336d-4ce7-9729-2ae74e0abde2  ra-1
UN  DC2-1IP2   844.4 KiB   1            100.0%            fef794d5-f4c2-4a4e-bb05-9adaeb4aea4b  ra-1
UN  DC2-1IP3   878.12 KiB  1            100.0%            3894b3d9-1f5a-444d-83db-7b1e338bbfc9  ra-1

Puoi eseguire nodetool describecluster sui nodi per comprendere lo stato attuale dell'intero cluster. Ad esempio, di seguito è riportata un'istanza di un cluster a due data center in cui tutti i nodi DC-1 utilizzano Cassandra versione 4, mentre tutti i nodi DC-2 utilizzano Cassandra versione 3:

# On nodes where Cassandra is upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]

Stats for all nodes:
    Live: 6
    Joining: 0
    Moving: 0
    Leaving: 0
    Unreachable: 0

Data Centers:
    dc-1 #Nodes: 3 #Down: 0
    dc-2 #Nodes: 3 #Down: 0

Database versions:
    4.0.13: [DC-1-IP1:7000, DC-1-IP2:7000, DC-1-IP3:7000]
    3.11.16: [DC-2-IP1:7000, DC-2-IP2:7000, DC-2-IP3:7000]

Keyspaces:
    system_schema -> Replication class: LocalStrategy {}
    system -> Replication class: LocalStrategy {}
    auth -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    cache -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    devconnect -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    dek -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    user_settings -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apprepo -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    kms -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    identityzone -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    audit -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    analytics -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    keyvaluemap -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    counter -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apimodel_v2 -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    system_distributed -> Replication class: SimpleStrategy {replication_factor=3}
    system_traces -> Replication class: SimpleStrategy {replication_factor=2}
    system_auth -> Replication class: SimpleStrategy {replication_factor=1}

# On nodes where Cassandra is not upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]

Identifica i nodi seed nel data center:consulta la sezione Come identificare i nodi seed nell'appendice. Esegui i passaggi riportati di seguito su uno dei nodi seed:

Interrompi, disinstalla e pulisci i dati dal nodo di Cassandra. Scegli il primo nodo seed nella versione 4 di Cassandra in questo data center. Smettila.

# Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe out Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra

Installa il software Cassandra precedente sul nodo e imposta alcune configurazioni. Esegui il file di bootstrap di Edge for Private Cloud 4.52.02.

# Download bootstrap of 4.52.02
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u uName:pWord

# Execute bootstrap of 4.52.02
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

Crea o modifica il file /opt/apigee/customer/application/cassandra.properties.
Aggiungi i seguenti contenuti al file. ipOfNode è l'indirizzo IP del nodo che Cassandra utilizza per comunicare con gli altri nodi Cassandra:
```
conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
```
Assicurati che il file sia di proprietà dell'utente Apigee e che possa essere letto:
```
chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
```
Installa e configura Cassandra:

# Install cassandra version 3.11.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install
# Setup cassandra while passing standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile
# Ensure Cassandra version is correct and service is running
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status

Verifica che il nodo sia stato avviato. Controlla il seguente comando su questo nodo e sugli altri nodi del cluster. Il nodo deve segnalare lo stato "UN" (Up/Normal):
```
/opt/apigee/apigee-cassandra/bin/nodetool status
```
Rimuovi le configurazioni aggiuntive aggiunte in precedenza dal file /opt/apigee/customer/application/cassandra.properties.
Ripeti i passaggi da 3 a 10 su tutti i nodi seed Cassandra nel data center, uno alla volta.
Ripeti i passaggi da 3 a 10 su tutti i nodi Cassandra rimanenti nel data center, uno alla volta.
Ricostruisci tutti i nodi nel data center da un data center che esegue la versione precedente di Cassandra. Esegui questo passaggio un nodo alla volta:
```
/opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>
```
Questa procedura potrebbe richiedere del tempo. Se necessario, puoi modificare streamingthroughput. Controlla nodetool netstats per lo stato del completamento dell'operazione.
(Facoltativo) Esegui il comando di riparazione nel nodo Cassandra se i dati non vengono ricreati.
```
/opt/apigee/apigee-cassandra/bin/nodetool -h node-IP repair -pr
```

Riavvia tutti i componenti edge-* nel data center, uno alla volta:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart

Convalida e reindirizza il traffico a questo data center. Esegui alcune convalide per il traffico di runtime e le API di gestione in questo data center e inizia a reindirizzare il traffico del proxy e delle API di gestione.
Ripeti i passaggi precedenti per ogni data center di cui vuoi eseguire il rollback.

Eseguire il rollback di Cassandra utilizzando il backup

Prerequisiti

Stai eseguendo l'upgrade di Cassandra dalla versione 3.11.X alla 4.0.X e hai riscontrato problemi durante l'upgrade.
Hai backup per il nodo di cui stai eseguendo il rollback. Il backup è stato eseguito prima del tentativo di upgrade dalla versione 3.11.X alla 4.0.X.

Passaggi

Seleziona un nodo di cui vuoi eseguire il rollback. Se esegui il rollback di tutti i nodi in un data center utilizzando i backup, inizia con i nodi seed. Consulta la sezione "Come identificare i nodi seed" nell'appendice.

Arresta, disinstalla e pulisci il nodo Cassandra:

# Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra

Installa il software Cassandra precedente sul nodo e configuralo:

Esegui il file di bootstrap per Edge for Private Cloud 4.52.02:

# Download bootstrap for 4.52.02
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u ‘uName:pWord’

# Execute bootstrap for 4.52.02
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

Crea o modifica il file /opt/apigee/customer/application/cassandra.properties:

conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true

Assicurati che il file sia di proprietà dell'utente Apigee e sia leggibile:

chown apigee:apigee /opt/apigee/customer/application/cassandra.properties

Installa e configura Cassandra:

# Install Cassandra version 3.11.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install

# Set up Cassandra with the standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile

# Verify Cassandra version and check service status
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status

Verifica che il nodo sia stato avviato. Controlla il seguente comando su questo nodo e sugli altri nodi del cluster. I nodi devono segnalare che questo nodo si trova nello stato "UN":

/opt/apigee/apigee-cassandra/bin/nodetool status

Arresta il servizio Cassandra e ripristina il backup. Per ulteriori dettagli, consulta la documentazione su backup e ripristino:

# Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Wipe the data directory in preparation for restore
rm -rf /opt/apigee/data/apigee-cassandra/data

# Restore the backup taken before the upgrade attempt
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backupFile

Una volta ripristinato il backup, rimuovi le configurazioni aggiuntive:

Rimuovi la configurazione aggiunta in precedenza dal file /opt/apigee/customer/application/cassandra.properties.

Avvia il servizio Cassandra sul nodo:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start

Ripeti i passaggi su ogni nodo Cassandra di cui vuoi eseguire il rollback utilizzando i backup, uno alla volta.

Una volta ripristinati tutti i nodi Cassandra, riavvia tutti i componenti edge-* uno alla volta:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart

Ottimizzazioni del backup (opzione avanzata)

Puoi ridurre al minimo (o eliminare) la perdita di dati durante il ripristino dei backup se sono disponibili repliche che contengono i dati più recenti. Se sono disponibili repliche, dopo aver ripristinato il backup, esegui una riparazione sul nodo ripristinato.

Appendice

Come identificare i nodi seed

Su qualsiasi nodo Cassandra in un data center, esegui questo comando:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure -search conf_cassandra_seeds

Il comando restituirà più righe. Cerca l'ultima riga dell'output. Gli indirizzi IP elencati nell'ultima riga sono i nodi seed. Nell'esempio seguente, DC-1-IP1, DC-1-IP2, DC-2-IP1 e DC-2-IP2 sono gli IP dei nodi seed:

Found key conf_cassandra_seeds, with value, "127.0.0.1", in /opt/apigee/apigee-cassandra/token/default.properties

Found key conf_cassandra_seeds, with value, 127.0.0.1, in /opt/apigee/apigee-cassandra/token/application/cassandra.properties

Found key conf_cassandra_seeds, with value, "DC-1-IP1, DC-1-IP2, DC-2-IP1, DC-2-IP2", in /opt/apigee/token/application/cassandra.properties
apigee-configutil: apigee-cassandra: # OK

Esegui il rollback dell'aggiornamento di Zookeeper 3.8.4

Esegui il rollback

Nel caso in cui sia necessario un rollback:

Esegui prima i passaggi di rollback su osservatori e follower.
Scarica ed esegui il bootstrap della versione a cui stai eseguendo il rollback, ovvero 4.52.02 o 4.53.00. La procedura varia probabilmente a seconda che il nodo abbia una connessione a internet esterna o che tu stia seguendo l'installazione offline.

Arresta Zookeeper se è in esecuzione sul nodo:

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

Disinstalla Zookeeper esistente:

  /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper uninstall

Installa Zookeeper come di consueto:

  /opt/apigee/apigee-setup/bin/setup.sh -p zk -f <silent-config-file>

Una volta eseguito il rollback di tutti i follower e gli osservatori, esegui il rollback del nodo leader seguendo i passaggi da 2 a 5 sul nodo leader.
Dopo il rollback di tutti i nodi, verifica l'integrità del cluster e assicurati che nel cluster sia presente un nodo leader.

Ripristina backup

Consulta Ripristino da un backup. Tieni presente che i backup di Zookeeper eseguiti da versioni precedenti di Edge for Private Cloud, come 4.52.02 o 4.53.00, devono essere compatibili con la versione di Zookeeper in Edge for Private Cloud 4.53.01

Esegui il rollback dell'aggiornamento di Postgres 17

Se hai eseguito l'upgrade alla versione 4.53.01 dalla versione 4.52.02 o 4.53.00, devi eseguire il rollback dell'aggiornamento di Postgres oltre ai componenti Edge.

Per eseguire il rollback dell'aggiornamento di Postgres durante l'aggiornamento di Postgres in una configurazione master-standby:

Promuovi il nuovo nodo di standby per farlo diventare il master Postgres. Il nuovo master Postgres avrà la stessa versione dell'installazione Edge precedente.
Configura il vecchio nodo di standby in modo che sia un nodo di standby del nuovo master. Il vecchio nodo di standby avrà la stessa versione dell'installazione precedente di Edge.
Registra i nuovi nodi master e di standby con i gruppi di analisi e consumer.

Al termine del rollback, il vecchio nodo master non sarà più necessario. A questo punto puoi ritirare il vecchio nodo master.

Prima di iniziare

Prima di eseguire il rollback di Postgres 17 alla versione 14, esegui i seguenti passaggi sia sul nuovo host di standby sia su quello precedente per aggiornare la proprietà max_locks_per_transaction su apigee-postgresql:

Se non è presente, crea il file /opt/apigee/customer/application/postgresql.properties.

Modifica la proprietà di questo file in apigee:

sudo chown apigee:apigee /opt/apigee/customer/application/postgresql.properties

Aggiungi la seguente proprietà al file:

conf/postgresql.conf+max_locks_per_transaction=30000

Configura apigee-postgresql:

apigee-service apigee-postgresql configure

Riavvia apigee-postgresql:

apigee-service apigee-postgresql restart

Assicurati che il nuovo nodo Postgres di standby 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
```

Assicurati che Postgres sia arrestato sul vecchio nodo master e sul vecchio nodo di standby:

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

Se Postgres è in esecuzione, arrestalo:

/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop  
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop

Se è installato, avvia Qpid sul vecchio nodo di standby:
```
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
```
Nota: in molte configurazioni, il vecchio nodo di standby ospiterà solo Postgres, ma non Qpid.
Promuovi il nuovo nodo in standby come master Postgres:
1. Promuovi il nuovo nodo di standby a nuovo master:
```
apigee-service apigee-postgresql promote-standby-to-master old_master_IP
```
  Se richiesto, inserisci la password di Postgres per l'utente "apigee", che per impostazione predefinita è "postgres".
2. Modifica il file di configurazione che hai utilizzato per installare la versione attuale di Edge per specificare quanto segue:
```
# IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
```
3. Configura il nuovo master:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFile
```
Se hai già eseguito l'upgrade del vecchio nodo di standby alla versione più recente, devi prima eseguire il downgrade del software Apigee sul vecchio nodo di standby. Se hai ancora la versione precedente sul vecchio nodo di standby, puoi saltare questo passaggio e continuare con il passaggio 6.
1. Arresta Postgres sul vecchio nodo di standby:
```
apigee-service apigee-postgresql stop
apigee-service edge-postgres-server stop
```
2. Disinstalla Postgres dal vecchio nodo di standby:
```
apigee-service apigee-postgresql uninstall
apigee-service edge-postgres-server uninstall
```
3. Elimina la directory dei dati Postgres dal vecchio nodo di standby:
```
cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
```
4. Scarica ed esegui il bootstrap della versione precedente (per la versione di Apigee a cui stai eseguendo il rollback) sul vecchio nodo di standby. I passaggi esatti possono variare a seconda che tu stia utilizzando l'installazione basata su internet o offline. L'esecuzione del bootstrap di Apigee della versione precedente configurerà i repository yum con i dati di Apigee della versione precedente.
5. Configura i componenti Postgres sul vecchio nodo di standby:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
```
6. Controlla e verifica che i componenti Postgres sul vecchio nodo di standby sia stato eseguito il rollback alla versione precedente:
```
apigee-service apigee-postgresql version
apigee-service edge-postgres-server version
```

Nota: assicurati di rimuovere l'rpm postgresql17-libs-17.4-1PGDG se ancora esistente.

Ricostruisci il vecchio nodo di standby:
1. Modifica il file di configurazione che hai utilizzato per installare la versione attuale di Edge per specificare quanto segue:
```
# IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
```
2. Rimuovi la directory dei dati sul vecchio nodo di standby:
```
cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
```
3. Riconfigura il vecchio nodo di standby in modo che diventi un nodo di standby del nuovo master:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
```
4. Assicurati che Postgres sia in esecuzione sul vecchio nodo di standby:
```
/opt/apigee/apigee-service/bin/apigee-all status
```
  Se Postgres non è in esecuzione, avvialo:
```
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server start
```
Verifica che il nuovo nodo di standby sia stato aggiunto visualizzando il file /opt/apigee/apigee-postgresql/conf/pg_hba.conf sul nuovo master.

Visualizza le informazioni correnti su Analytics e sul gruppo di consumatori eseguendo questo comando sul server di gestione:

curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

Questo comando restituisce il nome del gruppo di analisi nel campo name e il nome del gruppo di consumatori nel campo name in consumer-groups. Restituisce anche gli UUID dei nodi master e di standby Postgres precedenti nei campi postgres-server e datastores. Dovresti vedere un output nel formato:

{
  "name" : "axgroup-001",
  "properties" : {
  },
  "scopes" : [ "VALIDATE~test", "sgilson~prod" ],
  "uuids" : {
    "qpid-server" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
    "postgres-server" : [
      "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256"
    ]
  },
  "consumer-groups" : [ {
    "name" : "consumer-group-001",
    "consumers" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
    "datastores" :
      [ "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256" ],
      "properties" : {     }
    }
  ],
  "data-processors" : {
  }
}

Recupera l'indirizzo UUID del vecchio master eseguendo il seguente comando curl sul vecchio nodo master:
```
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"
```
Nota: il servizio edge-postgres-server deve essere in esecuzione. Se il server Postgres non è in esecuzione, puoi eseguire il seguente comando sul server di gestione per determinare l'UUID:
```
curl -u sysAdminEmail:password http://ms_IP:8080/v1/servers?pod=analytics
```
L'output di questo comando elenca l'UUID per l'indirizzo IP di ogni nodo PostgreSQL.
Ripeti il passaggio precedente per ottenere gli indirizzi IP del vecchio nodo di standby e del nuovo master.
Rimuovi i nodi master e di standby precedenti dal gruppo di consumer:
```
curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/datastores/masterUUID,standbyUUID" -v
```
dove axgroup-001 e consumer-group-001 sono i nomi predefiniti dei gruppi di analisi e di consumatori. masterUUID,standbyUUID sono nello stesso ordine in cui sono apparsi sopra quando hai visualizzato le informazioni attuali su analisi e gruppo di consumatori. Potresti doverli specificare come standbyUUID,masterUUID.

La proprietà datastores per consumer-groups ora dovrebbe essere vuota.

Rimuovi i vecchi nodi master e di standby dal gruppo di analisi:

curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v

La proprietà postgres-server in uuids ora dovrebbe essere vuota.

Registra i nuovi nodi master e di standby PG con i gruppi di analisi e di consumatori:

curl -u sysAdminEmail:password -X POST -H "Content-Type: application/json" -d ''
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v
curl -u sysAdminEmail:password -X POST -H "Content-Type:application/json" -d ''
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/datastores?uuid=masterUUID,standbyUUID" -v

Convalida il gruppo di analisi:
```
curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax
```
Dovresti vedere gli UUID dei nuovi nodi master e di standby elencati nel gruppo di analisi e nel gruppo di consumer.

Riavvia il server di gestione edge:

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

Riavvia tutti i server Qpid:

/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart

Riavvia tutti i server Postgres:

/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart

Verifica lo stato della replica eseguendo i seguenti script su entrambi i server. Il sistema dovrebbe mostrare risultati identici su entrambi i server per garantire una replica riuscita:
Sul nuovo master, esegui:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
```
Verifica che sia il master. Sul vecchio nodo di riserva:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby
```
Verifica che sia in standby.
Ripeti il passaggio precedente dopo aver effettuato diverse richieste API per assicurarti che i nodi siano sincronizzati.
Ritira il vecchio master Postgres utilizzando la procedura descritta in Ritiro di un nodo Postgres.
Nota: se il vecchio nodo master eseguiva Qpid, puoi lasciare il server attivo per eseguire Qpid. Assicurati che sia in esecuzione. In caso contrario, avvialo:
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-server start
```
In alternativa, puoi disinstallare Qpid dal vecchio master e installarlo sul nuovo nodo master. Dopo aver disinstallato Qpid, puoi ritirare il vecchio nodo master.

Esegui il rollback dell'aggiornamento LDAP 2.6

Questa sezione fornisce una guida completa e passo passo per eseguire il rollback di un'installazione LDAP a una versione LDAP precedente. Il rollback deve essere eseguito sull'intero cluster LDAP ed è possibile solo utilizzando un backup LDAP pre-upgrade valido.

L'obiettivo principale è ripristinare l'intero cluster LDAP a uno stato coerente da un backup noto e valido. Questa procedura è la stessa per tutti gli scenari: singolo server, attivo/attivo e attivo/passivo.

Prerequisiti e considerazioni

Incompatibilità del backup:utilizza un backup della versione LDAP 2.4 precedente che stavi eseguendo con Edge for Private Cloud 4.52.02 o 4.53.00. Questo backup deve essere stato eseguito prima del tentativo di upgrade. I backup eseguiti dopo l'upgrade sono incompatibili e non possono essere utilizzati.
Tempo di inattività dell'API Management:durante il rollback LDAP, le API Management non saranno disponibili, il che potrebbe influire sulle attività amministrative. Assicurati di arrestare tutti i server di gestione edge e l'interfaccia utente edge prima di procedere con il rollback LDAP.
Rischio di perdita di dati: se procedi senza un backup valido e compatibile, rischi di perdere i dati in modo irreversibile.
Backup valido:è necessario un backup LDAP valido precedente all'upgrade.

Procedura di rollback

Prima di procedere con l'upgrade di LDAP, assicurati di arrestare tutti i server di gestione edge e l'interfaccia utente edge.
```
apigee-service edge-management-server stop
apigee-service edge-ui stop
```

Eseguire il backup dei dati LDAP esistenti (prima di interrompere LDAP)

Ottieni il conteggio totale dei record per riferimento da tutti i server LDAP. Il conteggio dei record deve corrispondere a tutti i server LDAP.

      # 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

Interrompere e disinstallare il nuovo LDAP 2.6
Interrompi il servizio apigee-openldap ed elimina le directory di configurazione e dati. Questa operazione deve essere eseguita su tutti i server LDAP, un nodo alla volta nel cluster per garantire la coerenza.
```
apigee-service apigee-openldap stop
apigee-service apigee-openldap uninstall
rm -rf /opt/apigee/data/apigee-openldap/*
```
Installa la vecchia versione di LDAP 2.4
- Installa la vecchia versione di LDAP:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ld -f /opt/silent.conf
```
- Convalida la versione di LDAP:
```
source ~/.bash_profile
ldapsearch -VV

#Expected output:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.46
```
- Ripeti i passaggi precedenti su ogni nodo LDAP, uno alla volta
Pulire i dati residui
Su tutti i server LDAP, uno alla volta, arresta il servizio appena installato e pulisci la directory dei dati per prepararti al ripristino dal backup.
```
apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/*
```

Ripristinare i dati LDAP

Per la configurazione a server singolo, puoi passare direttamente al passaggio 5b. Per la configurazione di più server, procedi con il passaggio 5a.

Identificare il server LDAP attivo

Prima di ripristinare i dati LDAP, identifica il server (provider) attivo eseguendo questo comando.

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.

Ripristina i dati LDAP (assicurati che il passaggio 4 sia completato su tutti i server prima del ripristino).

Sul server LDAP singolo e attivo (determinato nel passaggio 5a), ripristina il backup.

cd /opt/apigee/backup/openldap

# To restore a specific backup, provide the timestamp as shown below:
apigee-service apigee-openldap restore 2025.07.28,13.59.00
# Note: If no timestamp is provided, the latest available backup will be restored by default.
apigee-service apigee-openldap restore

# It is recommended to specify the backup explicitly to avoid restoring an unintended version.

Avvia il servizio apigee-openldap.
```
apigee-service apigee-openldap start
```

Avviare i server LDAP rimanenti
Se hai una configurazione multi-server, avvia il servizio su ciascuno dei server LDAP:
```
apigee-service apigee-openldap start
```
Nota:non è necessario ripristinare manualmente i dati su questi server peer. All'avvio, si connetteranno al primo server (che ora contiene i dati ripristinati) e sincronizzeranno automaticamente l'intera directory tramite la replica.
Convalida finale
- Il passaggio finale consiste nel verificare che il rollback 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 1.
```
# 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
```
- Una volta confermato che i dati sono corretti e coerenti, il rollback LDAP è completato. Ora puoi procedere con l'avvio di edge-management-server, edge-ui e di qualsiasi altro componente dipendente in base alla procedura di upgrade standard della tua organizzazione.

Eseguire il rollback a una release principale o secondaria precedente

Per eseguire il rollback a una release principale o secondaria precedente, esegui le seguenti operazioni su ogni nodo che ospita il componente:

Scarica il file bootstrap.sh per la versione a cui vuoi eseguire il rollback:
- Per eseguire il rollback alla versione 4.52.02, scarica bootstrap_4.52.02.sh

Arresta il componente per eseguire il rollback:

Per eseguire il rollback di uno dei componenti con codice comune sul nodo, devi arrestarli tutti, come mostrato nell'esempio seguente:

/opt/apigee/apigee-service/bin/apigee-service edge-management-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-router stop
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor stop
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop

Per eseguire il rollback di qualsiasi altro componente sul nodo, arresta solo quel componente:
```
/opt/apigee/apigee-service/bin/apigee-service component stop
```

Se esegui il rollback della monetizzazione, disinstallala da tutti i nodi del server di gestione e del processore di messaggi:
```
/opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
```
Disinstalla il componente per eseguire il rollback sul nodo:
1. Per eseguire il rollback di uno dei componenti con codice comune sul nodo, devi disinstallarli tutti disinstallando il gruppo di componenti edge-gateway e apigee-cassandra-client, come mostrato nell'esempio seguente:
```
/opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
```
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall
```
2. Per eseguire il rollback di Nginx come indicato di seguito:
```
###Find the apigee-nginx RPM 
rpm -qa | grep -i "apigee-nginx"

###Remove the apigee-nginx RPM
dnf remove apigee-nginx-1.26.x
```
3. Per eseguire il rollback di qualsiasi altro componente sul nodo, disinstalla solo quel componente, come mostrato nell'esempio seguente:
```
/opt/apigee/apigee-service/bin/apigee-service component uninstall
```
  Dove component è il nome del componente.
4. Per eseguire il rollback dell'Edge Router, devi eliminare i contenuti del file /opt/nginx/conf.d oltre a disinstallare il gruppo di componenti edge-gateway:
```
cd /opt/nginx/conf.d
rm -rf *
```

Disinstalla la versione 4.53.01 di apigee-setup:

/opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall

Installa la versione 4.52.02 dell'utilità apigee-service e le relative dipendenze. L'esempio seguente installa la versione 4.52.02 di apigee-service:
```
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
```
dove uName e pWord sono il nome utente e la password che hai ricevuto da Apigee. Se ometti pWord, ti verrà chiesto di inserirlo.

Se ricevi un errore, assicurati di aver scaricato il file bootstrap.sh nel passaggio 1.

Installa apigee-setup:

/opt/apigee/apigee-service/bin/apigee-service apigee-setup install

Installa la versione precedente del componente:
```
/opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile
```
Dove component è il componente da installare e configFile è il file di configurazione per la versione precedente.
Se esegui il rollback di Qpid, svuota iptables:
```
sudo iptables -F
```
Ripeti questa procedura per ogni nodo che ospita il componente di cui stai eseguendo il rollback.

Esegui il rollback di mTLS

Per eseguire il rollback dell'aggiornamento mTLS, segui questi passaggi su tutti gli host:

Arresta Apigee:
```
apigee-all stop
```
Interrompi mTLS:
```
apigee-service apigee-mtls uninstall
```

Reinstalla mTLS:

apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf