Questa pagina è stata tradotta dall'API Cloud Translation.

Ritiro di un data center

A volte può essere necessario dismettere un data center. Ad esempio, se stai eseguendo l'upgrade del sistema operativo, devi installare il nuovo sistema operativo in un nuovo data center e poi eseguire la disattivazione del vecchio data center. Le sezioni seguenti presentano un esempio di ritiro di un data center, in cui esistono due data center, dc-1 e dc-2, 12 nodi installazione in cluster:

dc-1 è il data center che verrà dismesso.
dc-2 è un secondo data center utilizzato nella procedura di ritiro.

Se stai eseguendo l'upgrade del sistema operativo, dc-2 potrebbe essere il data center in cui hai installato la nuova versione del sistema operativo. Tuttavia, non è richiesta l'installazione di un nuovo sistema operativo dismissione di un data center.

Considerazioni prima della disattivazione di un data center

Quando rimuovi un data center, tieni presente quanto segue:

Blocca tutto il traffico di runtime e gestione verso il data center che viene dismesso e di reindirizzamento ad altri data center.
Dopo il ritiro del data center, avrai una capacità ridotta nel tuo cluster Apigee. Per rimediare, valuta la possibilità di aumentare la capacità nei data center rimanenti o di aggiungere data center dopo il ritiro.
Durante la procedura di disattivazione, è possibile che si verifichi una perdita di dati di analisi, a seconda dei componenti di analisi installati nel data center in fase di disattivazione. Puoi visualizzare per maggiori dettagli in Aggiungere o rimuovere Qpid nodi.
Prima di ritirare un data center, è necessario comprendere in che modo tutti i componenti sono configurate in tutti i data center, in particolare OpenLDAP, ZooKeeper, Cassandra, e i server Postgres. Dovresti anche eseguire il backup di tutti i componenti e delle relative configurazioni.

Prima di iniziare

Server di gestione: tutti i passaggi di ritiro sono altamente dipendenti dal server di gestione. Se ne hai uno solo Server di gestione disponibile, consigliamo di installare un nuovo prima del ritiro del componente di Management Server su un data center diverso da dc-1 su dc-1 e assicurati che uno dei server di gestione è sempre disponibile.
Router: Prima di ritirare un router, disattiva la connettività dei router bloccando la porta 15999. Assicurati che nessun runtime il traffico è diretto verso i router in fase di dismissione.
Cassandra e ZooKeeper: Le sezioni seguenti descrivono come ritirare dc-1 in una configurazione in due data center. Se hai più di due data center on-premise, assicurati di rimuovere tutti i riferimenti al nodo che viene dismesso (in questo caso dc-1) da tutti i file di configurazione silenziosi in tutti i data center rimanenti. Per i nodi Cassandra da ritirare, rimuovi gli host da CASS_HOSTS. I nodi Cassandra rimanenti dovrebbero rimanere nell'ordine originale di CASS_HOSTS.
Postgres: se smetti di partecipare al master Postgres, assicurati di promuovere una qualsiasi delle nodi in standby disponibili come nuovo master Postgres. Mentre il server QPID mantiene un buffer nella se il master Postgres non è disponibile per un periodo di tempo più lungo, rischi di perdere i dati di analisi.
Attenzione:devi rimuovere e aggiungere i server Postgresql dall'analisi gruppo di consumatori e gruppo di consumatori contemporaneamente. Potresti perdere alcuni dati di analisi in caso di ritardo significativo tra i due passaggi.
Suggerimento: il processore di messaggi ha una piccola coda in cui conserva di dati di analisi in memoria per un breve periodo di tempo, che puoi utilizzare per evitare la perdita di dati. Prima di apportare modifiche al gruppo di Analytics, bloccare la porta 5672 nel data center che prende il traffico, e di riabilitare rapidamente questa porta dopo aver apportato le modifiche, poiché esiste la possibilità di overflow dei dati.

Ad esempio, per interrompere temporaneamente il traffico di analisi da Processori di messaggi al server Qpid:
1. Invio
```
iptables -A INPUT -p tcp --destination-port 5672 ! -s `hostname` -i eth0 -j DROP
```
2. Segui i passaggi per la modifica del gruppo di assi.
3. Rimuovi la regola iptable dopo le modifiche axgroup:
```
iptables -F
```

Prerequisiti

Prima di ritirare qualsiasi componente, ti consigliamo di eseguire un backup completo nodi. Utilizza la procedura per la versione corrente di Edge per eseguire il backup. Per ulteriori informazioni sul backup, consulta Backup e ripristino.

Nota: se hai più nodi Cassandra o ZooKeeper, esegui il backup uno alla volta, poiché il processo di backup arresta temporaneamente ZooKeeper.
Assicurati che Edge sia attivo e in esecuzione prima del ritiro, utilizzando il comando:
```
/opt/apigee/apigee-service/bin/apigee-all status
```
Assicurati che al momento non arrivi traffico di runtime nel data center che stai ritirando.

Ordine di disattivazione dei componenti

Se installi Edge per il cloud privato su più nodi, devi ritirare i componenti di Edge su questi nodi nel seguente ordine:

UI Edge (UI edge)
Server di gestione (edge-management-server)
OpenLDAP (apigee-openldap)
Router (router perimetrale)
Processore di messaggi (edge-message-processor)
Qpid Server e Qpidd (edge-qpid-server e apigee-qpidd)
Database Postgres e PostgreSQL (edge-postgres-server e apigee-postgresql)
ZooKeeper (apigee-zookeeper)
Cassandra (apigee-cassandra)

Le sezioni seguenti spiegano come ritirare ogni componente.

UI Edge

Per interrompere e disinstallare il componente dell'interfaccia utente di Edge di dc-1, inserisci i seguenti comandi:

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

/opt/apigee/apigee-service/bin/apigee-service edge-ui uninstall

Server di gestione

Per ritirare il server di gestione su dc-1, segui questi passaggi:

Arresta il server di gestione su dc-1:

apigee-service edge-management-server stop

Trova l'UUID del server di gestione registrato in dc-1:

curl -u <AdminEmailID>:'<AdminPassword>' \
-X GET “http://{MS_IP}:8080/v1/servers?pod=central&region=dc-1&type=management-server”

Tipo di scollegamento del server:

curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://{MS_IP}:8080/v1/servers \
-d "type=management-server&region=dc-1&pod=central&uuid=UUID&action=remove"

Elimina il server. Nota: se sul server sono installati anche altri componenti, annulla la registrazione di tutti questi elementi prima di eliminare l'UUID.
```
curl -u <AdminEmailID>:'<AdminPassword> -X DELETE http://{MS_IP}:8080/v1/servers/{UUID}
```

Disinstalla il componente Server di gestione su dc-1:

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

LDAP aperto

Questa sezione spiega come ritirare OpenLDAP su dc-1.

Nota: se hai più di due data center, vedi Configurazioni con più di due data center di seguito.

Per disattivare OpenLDAP su dc-1, segui questi passaggi:

Esegui il backup del nodo OpenLDAP dc-1 seguendo i passaggi descritti in Come eseguire il backup.
Dividi la replica dei dati tra i due data center, dc-1 e dc-2, eseguendo i seguenti passaggi in entrambi i data center.
Nota: se la configurazione ha più di due data center, devi:
1. Identificare il nodo OpenLDAP replicata sul nodo in fase di dismissione.
2. Modifica la replica in modo che il nodo venga replicato su un altro nodo per completare il circolo di replica.
Ad esempio, supponiamo che tu abbia tre data center, in cui il nodo 1 si replica nel nodo 2, il nodo 2 si replica nel nodo 3 e il nodo 3 si replica nel nodo 1. Se stai dismettendo il nodo 1, devi interrompere la replica sul nodo 1 e modificare anche la replica per il nodo 3 in modo che venga eseguita sul nodo 2.
1. Controlla lo stato attuale:
```
ldapsearch -H ldap://{HOST}:{PORT} -LLL -x -b "cn=config" -D "cn=admin,cn=config" -w {credentials} -o ldif-wrap=no 'olcSyncRepl' | grep olcSyncrepl
```
  L'output dovrebbe essere simile al seguente:
```
olcSyncrepl: {0}rid=001 provider=ldap://{HOST}:{PORT}/ binddn="cn=manager,dc=apigee,dc=com" bindmethod=simple credentials={credentials} searchbase="dc=apigee,dc=com" attrs="*,+" type=refreshAndPersist retry="60 1 300 12 7200 +" timeout=1
```
2. Crea un file break_repl.ldif contenente i seguenti comandi:
```
dn: olcDatabase={2}bdb,cn=config
changetype: modify
delete: olcSyncRepl

dn: olcDatabase={2}bdb,cn=config
changetype: modify
delete: olcMirrorMode
```
3. Esegui il comando ldapmodify:
```
ldapmodify -x -w {credentials} -D "cn=admin,cn=config" -H "ldap://{HOST}:{PORT}/" -f path/to/file/break_repl.ldif
```
  L'output dovrebbe essere simile al seguente:
```
modifying entry "olcDatabase={2}bdb,cn=config"
modifying entry "olcDatabase={2}bdb,cn=config"
```
Puoi verificare che dc-2 non sia più replicata su dc-1 creando una voce in LDAP dc-2 e assicurarti che non venga visualizzato in LDAP di dc-1.

Facoltativamente, puoi seguire i passaggi riportati di seguito, che creano un utente di sola lettura in dc-2 al nodo OpenLDAP e quindi verificare se l'utente è replicato o meno. L'utente viene successivamente eliminato.
1. Crea un file readonly-user.ldif in dc-2 con i seguenti contenuti:
```
dn: uid=readonly-user,ou=users,ou=global,dc=apigee,dc=com
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: top
cn: readonly-user
sn: readonly-user
userPassword: {testPassword}
```
2. Aggiungi l'utente con il comando "ldapadd" in dc-2:
```
ldapadd -H ldap://{HOST}:{PORT} -w {credentials} -D "cn=manager,dc=apigee,dc=com" -f path/to/file/readonly-user.ldif
```
  L'output sarà simile a questo:
```
adding new entry "uid=readonly-user,ou=users,ou=global,dc=apigee,dc=com"
```
3. Cerca l'utente in dc-1 per assicurarti che non venga replicato. Se l'utente non è presente in dc-1, sarai sicuro che entrambi gli LDAP non si stanno più replicando:
```
ldapsearch -H ldap://{HOST}:{PORT} -x -w {credentials} -D "cn=manager,dc=apigee,dc=com" -b uid=readonly-user,ou=users,ou=global,dc=apigee,dc=com -LLL
```
  L'output dovrebbe essere simile al seguente:
```
No such object (32)
Matched DN: ou=users,ou=global,dc=apigee,dc=com
```
4. Rimuovi l'utente con autorizzazione di sola lettura aggiunto in precedenza:
```
ldapdelete -v -H ldap://{HOST}:{PORT} -w {credentials} -D "cn=manager,dc=apigee,dc=com" "uid=readonly-user,ou=users,ou=global,dc=apigee,dc=com"
```

Interrompi OpenLDAP in dc-1:

/opt/apigee/apigee-service/bin/apigee-service apigee-openldap stop

Disinstalla il componente OpenLDAP su dc-1:

/opt/apigee/apigee-service/bin/apigee-service apigee-openldap uninstall

Router

Questa sezione spiega come dismettere un router. Consulta Rimuovi un server per ulteriori dettagli sulla rimozione del router.

I passaggi seguenti consentono di disattivare il router da dc-1. Se sono presenti più nodi router configurati in dc-1, esegui la procedura in tutti i nodi del router uno alla volta

Nota: qui si presume che la porta di controllo dell'integrità 15999 del router sia configurata nel bilanciatore del carico e che il blocco della porta 15999 renda il router irraggiungibile. Potrebbe essere necessario l'accesso root per bloccare la porta.

Per ritirare un router, segui questi passaggi:

Disattiva la connettività dei router bloccando la porta 15999, ovvero la porta per il controllo di integrità. Assicurati che il traffico di runtime sia bloccato in questo data center:
```
iptables -A INPUT -i eth0 -p tcp --dport 15999 -j REJECT
```

Verifica che il router sia raggiungibile:

curl -vvv -X GET http://{ROUTER_IP}:15999/v1/servers/self/reachable

L'output dovrebbe essere simile al seguente:

About to connect() to 10.126.0.160 port 15999 (#0)
Trying 10.126.0.160...
Connection refused
Failed connect to 10.126.0.160:15999; Connection refused
Closing connection 0
curl: (7) Failed connect to 10.126.0.160:15999; Connection refused

Recupera l'UUID del router, come descritto in Recupera gli UUID.

Arresta il router:

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

Elenca i pod dei gateway disponibili nell'organizzazione con il seguente comando:
```
curl -u  <AdminEmailID>:<AdminPassword> -X GET "http://{MS_IP}:8080/v1/organizations/{ORG}/pods"
```
Vedi Informazioni sui pod.

Annulla la registrazione del tipo di server:

curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://{MS_IP}:8080/v1/servers \
-d "type=router&amp;region=dc-1&amp;pod=gateway-1&amp;uuid=UUID&amp;action=remove"

Elimina il server:

curl -u <AdminEmailID>:'<AdminPassword>’ -X DELETE http://{MS_IP}:8080/v1/servers/UUID

Disinstalla edge-router:

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

Vedi Rimuovi un server.

Svuotare le regole iptables per attivare la porta bloccata 15999:
```
iptables -F
```

processore di messaggi

Questa sezione descrive come ritirare il processore di messaggi da dc-1. Vedi Rimuovi un server per ulteriori dettagli sulla rimozione del processore di messaggi.

Dal momento che presupponiamo che dc-1 abbia un 12 nodi l'installazione in cluster, sono presenti due nodi del processore di messaggi configurati in dc-1. Esegui la i seguenti comandi in entrambi i nodi.

Ottieni gli UUID dei processori dei messaggi, come descritto in Ottenere gli UUID.

Arresta il processore di messaggi:

apigee-service edge-message-processor stop

Annulla la registrazione del tipo di server:

curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://{MS_IP}:8080/v1/servers  \
-d "type=message-processor&amp;region=dc-1&amp;pod=gateway-1&amp;uuid=UUID&amp;action=remove"/pre>

Disassociate an environment from the Message Processor.

Note: You need to remove the bindings on each org/env that associates the Message Processor UUID.

curl -H "Content-Type:application/x-www-form-urlencoded" -u <AdminEmailID>:''  \
-X POST http://{MS_IP}:8080/v1/organizations/{ORG}/environments/{ENV}/servers \
-d "action=remove&uuid=UUID"

Annulla la registrazione del tipo di server:

curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://MS_IP:8080/v1/servers -d "type=message-processor&region=dc-1&pod=gateway-1&uuid=UUID&action=remove"

Disinstalla il processore di messaggi:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor uninstall

Annullare la registrazione del server:

curl -u <AdminEmailID>:'<AdminPassword> -X DELETE http://{MS_IP}:8080/v1/servers/UUID

Qpid server e Qpidd

Questa sezione spiega come ritirare il server Qpid (edge-qpid-server) e Qpidd (apigee-qpidd). Esistono due nodi Qpid configurati in dc-1, quindi è necessario seguire questi passaggi per entrambi nodi:

Ottieni l'UUID per Qpidd, come descritto in Ottenere gli UUID.

Fermate edge-qpid-server e apigee-qpidd:

/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server stop
/opt/apigee/apigee-service/bin/apigee-service apigee-qpidd stop

Ottieni un elenco di Analytics e di gruppi di consumatori:

curl -u <AdminEmailID>:'<AdminPassword>' -X GET http://{MS_IP}:8080/v1/analytics/groups/ax

Rimuovi Qpid dal gruppo di consumatori:

curl -u <AdminEmailID>:'<AdminPassword>' -H "Content-Type: application/json"  -X DELETE \ "http://{MS_IP}:8080/v1/analytics/groups/ax/{ax_group}/consumer-groups/{consumer_group}/consumers/{QPID_UUID}"

Rimuovi Qpid dal gruppo di analisi:

curl -v -u <AdminEmailID>:'<AdminPassword>' \
-X DELETE "http://{MS_IP}:8080/v1/analytics/groups/ax/{ax_group}/servers?uuid={QPID_UUID}&type=qpid-server"

Annullare la registrazione del server Qpid dall'installazione di Edge:

curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://{MS_IP}:8080/v1/servers \
-d "type=qpid-server&region=dc-1&pod=central&uuid={QPID_UUID}&action=remove"

Rimuovi il server Qpid dall'installazione di Edge:

curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/UUID

Riavvia tutti i componenti edge-qpid-server su tutti i nodi per assicurarti che la modifica venga rilevata da questi componenti:

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

Disinstalla edge-qpid-server e apigee-qpidd:

$ /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server uninstall
$ /opt/apigee/apigee-service/bin/apigee-service apigee-qpidd uninstall

Postgres e Postgresql

Il data center che stai ritirando potrebbe avere un master Postgres o uno standby Postgres. Le seguenti sezioni spiegano come annullarle:

Ritiro del master Postgres
Disattivazione del cluster Postgres standby

Attenzione:devi rimuovere e aggiungere i server Postgresql dall'analisi gruppo di consumatori e gruppo di consumatori contemporaneamente. Potresti perdere alcuni dati di analisi in caso di ritardo significativo tra i due passaggi.

Suggerimento: il processore di messaggi ha una piccola coda in cui conserva di dati di analisi in memoria per un breve periodo di tempo, che puoi utilizzare per evitare la perdita di dati. Prima di apportare modifiche al gruppo di Analytics, bloccare la porta 5672 nel data center che prende il traffico, e di riabilitare rapidamente questa porta dopo aver apportato le modifiche, poiché esiste la possibilità di overflow dei dati.

Ad esempio, per interrompere temporaneamente il traffico di analisi da Processori di messaggi al server Qpid:

Invio

iptables -A INPUT -p tcp --destination-port 5672 ! -s `hostname` -i eth0 -j DROP

Segui la procedura di modifica di axgroup.
Rimuovi la regola iptable dopo le modifiche axgroup:
```
iptables -F
```

Ritiro del master Postgres

Nota: se smetti di partecipare al master Postgres, assicurati di promuovere uno qualsiasi dei nodi in standby disponibili come nuovo master Postgres. Mentre le code QPID eseguono il buffering dei dati, se il master Postgres non è disponibile da molto tempo, rischi di perdere i dati analitici.

Per eseguire il ritiro del master Postgres:

Esegui il backup del nodo master di dc-1 Postgres seguendo le istruzioni nei link seguenti:
- Backup e ripristino
- Come eseguire il backup
Ottieni gli UUID dei server Postgres, come descritto in Ottenere gli UUID.

In dc-1, interrompi edge-postgres-server e apigee-postgresql nello schema corrente:

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

Nel nodo in standby in dc-2, inserisci il comando seguente per renderlo il nodo master:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql promote-standby-to-master <IP of OLD Progress master>
```
Nota: se hai più di un nodo Postgres in standby, devi aggiungere le voci host su il nuovo master e aggiornare l'impostazione di replica per tutti i nodi in standby Postgres disponibili.

Per aggiungere voci host al nuovo master Postgres: segui i passaggi nella sezione appropriata sotto:

Se è rimasto un solo nodo in standby

Ad esempio, supponiamo che prima del ritiro fossero stati configurati tre nodi Postgres. Hai dismesso il master esistente e promosso uno degli altri standby postgres nodi da masterizzare. Configura il nodo in standby rimanente seguendo questi passaggi:
1. Nel nuovo master, modifica la configurazione file da impostare:
```
PG_MASTER=IP_or_DNS_of_new_PG_MASTER
PG_STANDBY=IP_or_DNS_of_PG_STANDBY
```
2. Abilita la replica sul nuovo master:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFIle
```
Se è presente più di un nodo in standby
1. Aggiungi la seguente configurazione in /opt/apigee/customer/application/postgresql.properties:
```
conf_pg_hba_replication.connection=host replication apigee standby_1_ip/32 trust \n host replication apigee standby_2_ip/32 trust
```
2. Assicurati che il file /opt/apigee/customer/application/postgresql.properties sia di proprietà dell'utente apigee:
```
      chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
```
3. Riavvia apigee-postgresql:
```
apigee-service apigee-postgresql restart
```
4. Verifica che il master Postgres sia configurato correttamente inserendo il seguente comando in dc-2:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
```
5. Rimuovi e aggiungi i server Postgresql dal gruppo di analisi e dal gruppo di consumatori.
  Attenzione:esegui i due passaggi successivi insieme, in quanto potrebbe essere presente una perdita di dati di analisi tra le due fasi.
  1. Rimuovi il server Postgres precedente dal gruppo di analisi seguendo le istruzioni riportate in Rimuovere un server Postgres da un gruppo di analisi.
  2. Aggiungi un nuovo server Postgres al gruppo di analisi seguendo le istruzioni riportate in Aggiungere un server Postgres esistente a un gruppo di analisi.
6. Annulla la registrazione del server postgres precedente da dc-1:
```
curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://{MS_IP}:8080/v1/servers \
-d "type=postgres-server&region=dc-1&pod=analytics&uuid=UUID&action=remove"<
```
7. Elimina il vecchio server postgres da dc-1:
```
curl -u >AdminEmailID>:'>AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/UUID
```
8. Ora puoi dismettere il vecchio master Postgres in sicurezza. Disinstalla edge-postgres-server e apigee-postgresql:
```
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server uninstall
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql uninstall
```
Disattivazione standby Postgres

Nota: la documentazione relativa a 12 nodi l'installazione in cluster mostra il nodo postgresql dc-1 come master, ma per comodità, in questa sezione si presume che il nodo postgresql dc-1 sia in standby mentre il nodo postgresql dc-2 è master.

Per disattivare lo standby di Postgres, segui questi passaggi:
1. Recupera gli UUID dei server Postgres, seguendo le istruzioni riportate in Recupera gli UUID.
2. Arresta apigee-postgresql sul nodo di standby attuale in dc-1:
```
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop
```
3. Rimuovi e aggiungi i server Postgresql dal gruppo di analisi e dal gruppo di consumer.
  Attenzione: esegui insieme i due passaggi successivi, poiché potrebbe verificarsi una perdita di dati di analisi tra i due passaggi.
  1. Rimuovi il server Postgres precedente dal gruppo di analisi seguendo le istruzioni riportate in Rimuovere un server Postgres da un gruppo di analisi.
  2. Aggiungi un nuovo server Postgres al gruppo di analisi seguendo le istruzioni riportate in Aggiungere un server Postgres esistente a un gruppo di analisi.
4. Annulla la registrazione del server postgres precedente da dc-1:
```
curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://{MS_IP}:8080/v1/servers \
-d "type=postgres-server&region=dc-1&pod=analytics&uuid=UUID&action=remove"<
```
5. Elimina il vecchio server postgres da dc-1:
```
curl -u >AdminEmailID>:'>AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/UUID
```
6. Ora puoi dismettere il vecchio master Postgres in sicurezza. Disinstalla edge-postgres-server e apigee-postgresql:
```
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server uninstall
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql uninstall
```
ZooKeeper e Cassandra

Questa sezione spiega come ritirare i server ZooKeeper e Cassandra in due data center.

Se hai più di due data center on-premise, assicurati di rimuovere tutti i riferimenti al nodo che viene dismesso (in questo caso dc-1) da tutti i file di configurazione silenziosi in tutti i data center rimanenti. Per i nodi Cassandra che devono essere dismessi, eliminali da CASS_HOSTS. I restanti nodi Cassandra devono rimanere nell'ordine originale di CASS_HOSTS.

Nota su ZooKeeper: devi mantenere un quorum di nodi elettorali mentre modifichi le Proprietà ZK_HOST nel file di configurazione, per assicurarti che l'insieme ZooKeeper rimanga funzionante. Devi avere un numero dispari di nodi elettorali nella tua configurazione. Per ulteriori informazioni, vedi Manutenzione di Apache ZooKeeper per le attività di machine learning.

Attenzione: se dismetti un data center con un leader Nodo ZooKeeper, ci sarà tempo di inattività.

Per ritirare i server ZooKeeper e Cassandra:
1. Esegui il backup dei nodi Cassandra e ZooKeeper dc-1 seguendo le istruzioni nei link seguenti:
  - Backup e ripristino
  - Come eseguire il backup
  Nota: se hai più nodi ZooKeeper, esegui il backup uno alla volta. Il processo di backup arresta temporaneamente ZooKeeper.
2. Elenca gli UUID di ZooKeeper e Cassandra di server nel data center dove si trovano i nodi Cassandra potrebbe essere dismesso.
```
apigee-adminapi.sh servers list -r dc-1 -p central -t application-datastore --admin <AdminEmailID> --pwd '<AdminPassword>' --host localhost
```
3. Annullare la registrazione del tipo di server:
```
curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://MS_IP:8080/v1/servers -d "type=cache-datastore&type=user-settings-datastore&type=scheduler-datastore&type=audit-datastore&type=apimodel-datastore&type=application-datastore&type=edgenotification-datastore&type=identityzone-datastore&type=user-settings-datastore&type=auth-datastore&region=dc-1&pod=central&uuid=UUID&action=remove"
```
4. Annulla la registrazione del server:
```
curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://MS_IP:8080/v1/servers/UUID
```
5. Aggiorna il file di configurazione rimuovendo gli IP dei nodi dismessi ZK_HOSTS e CASS_HOSTS.
  Note:
  - Devi mantenere un quorum di nodi di voto durante la modifica della proprietà ZK_HOST nel file di configurazione, per assicurarti che l'ensemble ZooKeeper rimanga operativo. La tua configurazione deve avere un numero dispari di nodi elettori. Consulta Informazioni su ZooKeeper ed edge.
  - Per i nodi Cassandra da ritirare, rimuovi gli host da CASS_HOSTS. I nodi Cassandra rimanenti dovrebbero rimanere nell'ordine originale di CASS_HOSTS.
  - I nodi osservatori di ZooKeeper non partecipano alle votazioni e non vengono conteggiati quando determinare il quorum.
  Esempio: supponiamo di avere gli IP $IP1 $IP2 $IP3 in dc-1 e $IP4 $IP5 $IP6 in dc-2 stanno ritirando dc-1. Quindi devi rimuovere gli IP $IP1 $IP2 $IP3 dalla di configurazione dei deployment.
  - Voci del file di configurazione esistenti:
```
ZK_HOSTS="$IP1 $IP2 $IP3 $IP4 $IP5 $IP6"
CASS_HOSTS="$IP1:1,1 $IP2:1,1 $IP3:1,1, $IP4:2,1 $IP5:2,1 $IP6:2,1”
```
  - Nuove voci del file di configurazione:
```
ZK_HOSTS="$IP4 $IP5 $IP6"
CASS_HOSTS="$IP4:2,1 $IP5:2,1 $IP6:2,1"
```
6. Aggiorna il file di configurazione invisibile (modificato nel passaggio e) con gli IP dell'amministratore rimosso dismessi ed eseguire il deployment profilo server su tutti i nodi che ospitano i server di gestione:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ms -f updated_config_file
```
7. Aggiorna il file di configurazione con gli IP dei nodi dismessi rimossi ed esegui il profilo MP/RMP su tutti i nodi del router e del processore di messaggi:
  - Se il router perimetrale e il processore di messaggi sono configurati sullo stesso nodo, inserisci:
```
/opt/apigee/apigee-setup/bin/setup.sh -p rmp -f updated_config_file
```
  - Se il router perimetrale e il processore di messaggi sono configurati su nodi separati, inserisci quanto segue:
    
    Per il router:
```
/opt/apigee/apigee-setup/bin/setup.sh -p r -f updated_config_file
```
    Per il processore di messaggi:
```
/opt/apigee/apigee-setup/bin/setup.sh -p mp -f updated_config_file
```
8. Riconfigura tutti i nodi Qpid, rimuovendo gli IP dei nodi dismessi dal file di risposta:
```
/opt/apigee/apigee-setup/bin/setup.sh -p qs -f updated_config_file
```
9. Riconfigura tutti i nodi Postgres, con gli IP dei nodi ritirati rimossi dal file di risposta:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ps -f updated_config_file
```
10. Modifica spazio delle chiavi di system_auth. Se hai abilitato l'autenticazione Cassandra su un modello esistente Nodo Cassandra, aggiorna il fattore di replica dello spazio chiavi system_auth eseguendo l'esecuzione il seguente comando:
```
ALTER KEYSPACE system_auth WITH replication = {'class': 'NetworkTopologyStrategy', 'dc-2': '3'};
```
  Questo comando imposta il fattore di replica su '3', indicando tre nodi Cassandra nel cluster. Modifica questo valore in base alle tue esigenze.
  
  Dopo aver completato questo passaggio, non avere dc-1 in nessuno degli spazi delle chiavi.
11. Esegui la disattivazione dei nodi Cassandra su dc-1, uno alla volta.
  Nota: i nodi ritirati contengono ancora Cassandra con le informazioni di seed del cluster originale. Se per caso dovesse essere presente il servizio Cassandra, i nodi torneranno di nuovo all'anello del cluster. Per evitare che ciò accada, assicurati di disinstallare il componente Cassandra dopo il ritiro e non consentire a ricongiungere i nodi dismessi.
  
  Per ritirare i nodi Cassandra, inserisci il comando seguente:
```
/opt/apigee/apigee-cassandra/bin/nodetool -h cassIP -u cassandra -pw '<AdminPassword>' decommission
```
  Nota: se un nodo rimane bloccato in uno stato di ritiro, puoi utilizzare Cassandra nodetool removenode per rimuoverla. Ad esempio:
```
/opt/apigee/apigee-cassandra/bin/nodetool removenode UUID
```
12. Controlla la connessione dei nodi Cassandra da dc-1 utilizzando uno dei seguenti comandi:
```
/opt/apigee/apigee-cassandra/bin/cqlsh cassIP 9042 -u cassandra -p '<AdminPassword>'
```
  Oppure il comando di verifica secondario da eseguire sul nodo dismesso:
```
/opt/apigee/apigee-cassandra/bin/nodetool netstats
```
  Il comando riportato sopra dovrebbe restituire:
```
Mode: DECOMMISSIONED
```
13. Esegui il profilo DS per tutti i nodi Cassandra e ZooKeeper in dc-2:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ds -f updated_config_file
```
14. Interrompi apigee-cassandra e apigee-zookeeper in dc-1:
```
apigee-service apigee-cassandra stop
apigee-service apigee-zookeeper stop
```
15. Disinstalla apigee-cassandra e apigee-zookeeper in dc-1:
```
apigee-service apigee-cassandra uninstall
apigee-service apigee-zookeeper uninstall
```
Elimina le associazioni da dc-1

Per eliminare le associazioni da dc-1:
1. Elimina le associazioni da dc-1.
  1. Elenca tutti i pod disponibili nell'organizzazione:
```
curl -v -u  <AdminEmailID>:<AdminPassword> -X GET "http://MS_IP:8080/v1/o/ORG/pods"
```
  2. Per verificare se tutte le associazioni sono state rimosse, recupera il UUID dei server associati ai pod:
```
curl -v -u  <AdminEmailID>:<AdminPassword> \
-X GET "http://MS_IP:8080/v1/regions/dc-1/pods/gateway-1/servers"
```
    Se questo comando non restituisce alcun UUID, i passaggi precedenti hanno rimosso tutte le associazioni. e puoi saltare il passaggio successivo. In caso contrario, vai al passaggio successivo.
  3. Rimuovi tutte le associazioni server per gli UUID ottenuti nel passaggio precedente:
```
curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://MS_IP:8080/v1/servers/UUID
```
  4. Annulla l'associazione dell'organizzazione al pod:
```
curl -v -u  <AdminEmailID>:<AdminPassword>  "http://MS_IP:8080/v1/o/ORG/pods" -d "action=remove&region=dc-1&pod=gateway-1" -H "Content-Type: application/x-www-form-urlencoded" -X POST
```
2. Elimina i pod:
```
curl -v -u <AdminEmailID>:<AdminPassword> "http://MS_IP:8080/v1/regions/dc-1/pods/gateway-1" -X DELETE
```
3. Elimina la regione.
```
curl -v -u <AdminEmailID>:<AdminPassword>  "http://MS_IP:8080/v1/regions/dc-1" -X DELETE
```
Nota:se salti uno dei passaggi per eliminare i server, il passaggio precedente restituirà un messaggio di errore che indica che un determinato server nel pod esiste ancora. Pertanto, eliminali seguendo la procedura di risoluzione dei problemi riportata di seguito, personalizzando al contempo i tipi nel comando curl.

A questo punto, hai completato il ritiro di dc-1.

Appendice

Risoluzione dei problemi

Se dopo aver eseguito i passaggi precedenti, in alcuni pod sono ancora presenti server, segui questi passaggi per annullare la registrazione ed eliminare i server. Nota: modifica i tipi e il pod in base alle esigenze.
1. Scarica gli UUID utilizzando il seguente comando:
```
apigee-adminapi.sh servers list -r dc-1 -p POD -t  --admin <AdminEmailID> --pwd  '<AdminPassword>’ --host localhost
```
2. Annulla registrazione del tipo di server:
```
curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://MP_IP:8080/v1/servers -d "type=TYPE=REGION=dc-1&pod=POD&uuid=UUID&action=remove"
```
3. Elimina i server uno alla volta:
```
curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://MP_IP:8080/v1/servers/UUID
```
Convalida

Puoi convalidare il ritiro utilizzando i seguenti comandi.

Server di gestione

Esegui i comandi seguenti dai server di gestione in tutte le regioni.
```
curl -v  -u  <AdminEmailID>:'<AdminPassword>' http://MS_IP:8080/v1/servers?pod=central&region=dc-1
curl -v  -u  <AdminEmailID>:'<AdminPassword>' http://MS_IP:8080/v1/servers?pod=gateway&region=dc-1
curl -v -u  <AdminEmailID>:'<AdminPassword>'  http://MS_IP:8080/v1/servers?pod=analytics&region=dc-1
```
Esegui questo comando su tutti i componenti per verificare i requisiti delle porte per tutta la gestione porte.
```
curl -v http://MS_IP:8080/v1/servers/self
```
Controlla il gruppo di dati e analisi.
```
curl  -v  -u  <AdminEmailID>:'<AdminPassword>' "http://MS_IP:8080}/v1/o/ORG/e/ENV/provisioning/axstatus"
curl -v  -u  <AdminEmailID>:'<AdminPassword>'  http://MS_IP:8080/v1/analytics/groups/ax
```
Nodi Cassandra/ZooKeeper

In tutti i nodi Cassandra inserisci:
```
/opt/apigee/apigee-cassandra/bin/nodetool -h <host> statusthrift
```
Verrà restituito uno stato running o not running per quel particolare nodo.

In un nodo, inserisci:
```
/opt/apigee/apigee-cassandra/bin/nodetool -h <host> ring
```
```
/opt/apigee/apigee-cassandra/bin/nodetool -h <host> status
```
I comandi precedenti restituiranno le informazioni attive relative ai data center.

Nei nodi ZooKeeper, inserisci prima:
```
echo ruok | nc <host> 2181
```
Questo comando restituirà imok.

Inserisci quindi:
```
echo stat | nc <host> 2181 | grep Mode
```
Il valore di Mode restituito dal comando precedente sarà uno dei seguenti: observer, leader o follower.

In un nodo ZooKeeper:
```
/opt/apigee/apigee-zookeeper/contrib/zk-tree.sh >> /tmp/zk-tree.out.txt
```
Sul nodo master di Postgres, esegui:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
```
Verifica che la risposta indichi che il nodo è il nodo master.

Sul nodo in standby:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby
```
Verifica che la risposta indichi che il nodo è in standby.

Accedi al database PostgreSQL utilizzando il comando
```
psql -h localhost -d apigee -U postgres
```
Quando richiesto, inserisci "postgres" password utente come 'postgres'. Seleziona max(client_received_start_timestamp) da Dati e analisi.
”$org.$env.fact” limit 1;
Log

Controlla i log sui componenti per assicurarti che non ci siano errori.

Ritiro di un data center

Considerazioni prima della disattivazione di un data center

Prima di iniziare

Prerequisiti

Ordine di disattivazione dei componenti

UI Edge

Server di gestione

LDAP aperto

Router

processore di messaggi

Qpid server e Qpidd

Postgres e Postgresql

Ritiro del master Postgres

Se è rimasto un solo nodo in standby

Se è presente più di un nodo in standby

Disattivazione standby Postgres

ZooKeeper e Cassandra

Elimina le associazioni da dc-1

Appendice

Risoluzione dei problemi

Convalida

Server di gestione

Nodi Cassandra/ZooKeeper

Log