Diese Seite wurde von der Cloud Translation API übersetzt.

Außerbetriebnahme eines Rechenzentrums

Manchmal müssen Sie ein Rechenzentrum außer Betrieb nehmen. Wenn Sie beispielsweise Ihr Betriebssystem aktualisieren, müssen Sie das neue Betriebssystem in einem neuen Rechenzentrum installieren und das alte Rechenzentrum dann außer Betrieb nehmen. In den folgenden Abschnitten wird ein Beispiel für die Außerbetriebnahme eines Rechenzentrums mit zwei Rechenzentren (dc-1 und dc-2) in einer Clusterinstallation mit 12 Knoten beschrieben:

dc-1 ist das Rechenzentrum, das stillgelegt werden soll.
dc-2 ist ein zweites Rechenzentrum, das im Rahmen der Außerbetriebnahme verwendet wird.

Wenn Sie Ihr Betriebssystem aktualisieren, kann „dc-2“ das Rechenzentrum sein, in dem Sie die neue Version des Betriebssystems installiert haben. Die Installation eines neuen Betriebssystems ist jedoch nicht erforderlich, um ein Rechenzentrum außer Betrieb zu nehmen.

Überlegungen vor der Stilllegung eines Rechenzentrums

Beachten Sie beim Stilllegen eines Rechenzentrums die folgenden Aspekte:

Blockieren Sie den gesamten Laufzeit- und Verwaltungs-Traffic zum stillgelegten Rechenzentrum und leiten Sie ihn zu anderen Rechenzentren um.
Nach der Stilllegung des Rechenzentrums haben Sie weniger Kapazität in Ihrem Apigee-Cluster. Um dies auszugleichen, sollten Sie die Kapazität in den verbleibenden Rechenzentren erhöhen oder nach der Stilllegung weitere Rechenzentren hinzufügen.
Während der Außerbetriebnahme kann es zu einem Verlust von Analysedaten kommen. Das hängt davon ab, welche Analysekomponenten im außer Betrieb genommenen Rechenzentrum installiert sind. Weitere Informationen finden Sie unter Qpid-Knoten hinzufügen oder entfernen.
Bevor Sie ein Rechenzentrum außer Betrieb nehmen, sollten Sie wissen, wie alle Komponenten in allen Rechenzentren konfiguriert sind, insbesondere die SymasLDAP-, ZooKeeper-, Cassandra- und Postgres-Server. Sie sollten auch Sicherungen aller Komponenten und ihrer Konfigurationen erstellen.

Vorbereitung

Verwaltungsserver:Alle Schritte zur Außerbetriebnahme hängen stark vom Verwaltungsserver ab. Wenn Sie nur einen Management Server haben, empfehlen wir, eine neue Management Server-Komponente in einem anderen Rechenzentrum als dc-1 zu installieren, bevor Sie den Management Server in dc-1 außer Betrieb nehmen. Achten Sie darauf, dass immer einer der Management Server verfügbar ist.
Router:Deaktivieren Sie vor der Außerbetriebnahme eines Routers die Erreichbarkeit von Routern, indem Sie den Port 15999 blockieren. Achten Sie darauf, dass kein Laufzeittraffic an die Router weitergeleitet wird, die außer Betrieb genommen werden.
Cassandra und ZooKeeper:In den folgenden Abschnitten wird beschrieben, wie Sie „dc-1“ in einer Einrichtung mit zwei Rechenzentren außer Betrieb nehmen.
Wenn Sie mehr als zwei Rechenzentren haben, müssen Sie alle Verweise auf den stillgelegten Knoten (in diesem Fall „dc-1“) aus allen Dateien für die automatische Konfiguration in allen verbleibenden Rechenzentren entfernen. Entfernen Sie die Hosts für Cassandra-Knoten, die außer Betrieb genommen werden sollen, aus CASS_HOSTS. Die verbleibenden Cassandra-Knoten sollten in der ursprünglichen Reihenfolge von CASS_HOSTS bleiben.
Postgres:Wenn Sie den Postgres-Master außer Betrieb nehmen, müssen Sie einen der verfügbaren Standby-Knoten zum neuen Postgres-Master hochstufen. Der QPID-Server behält zwar einen Puffer in der Warteschlange bei, wenn der Postgres-Master jedoch längere Zeit nicht verfügbar ist, besteht das Risiko, dass Analysedaten verloren gehen.
Achtung:Sie müssen Postgresql-Server gleichzeitig aus der Analytics-Gruppe und der Consumer-Gruppe entfernen und hinzufügen. Wenn zwischen den beiden Schritten eine erhebliche Verzögerung auftritt, gehen möglicherweise einige Analysedaten verloren.
Vorschlag: Der Message Processor hat eine kleine Warteschlange, in der er Analysedaten für kurze Zeit im Arbeitsspeicher speichert. So können Sie Datenverlust vermeiden. Bevor Sie Änderungen an der Analysegruppe vornehmen, blockieren Sie Port 5672 im Rechenzentrum, das Traffic empfängt, und aktivieren Sie diesen Port nach den Änderungen schnell wieder, da sonst die Gefahr eines Datenüberlaufs besteht.

So können Sie beispielsweise den Analyse-Traffic von Message Processors zum Qpid-Server vorübergehend stoppen:
1. Geben Sie den folgenden Befehl ein:
```
iptables -A INPUT -p tcp --destination-port 5672 ! -s `hostname` -i eth0 -j DROP
```
2. Folgen Sie der Anleitung zum Ändern der axgroup.
3. Entfernen Sie die iptable-Regel nach Änderungen an der AX-Gruppe:
```
iptables -F
```

Vorbereitung

Bevor Sie eine Komponente außer Betrieb nehmen, empfehlen wir, ein vollständiges Backup aller Knoten durchzuführen. Verwenden Sie das Verfahren für Ihre aktuelle Edge-Version, um die Sicherung durchzuführen. Weitere Informationen zur Sicherung finden Sie unter Sichern und Wiederherstellen.

Hinweis:Wenn Sie mehrere Cassandra- oder ZooKeeper-Knoten haben, sichern Sie sie einzeln, da der Sicherungsvorgang ZooKeeper vorübergehend herunterfährt.
Prüfen Sie mit dem folgenden Befehl, ob Edge ausgeführt wird, bevor Sie die Außerbetriebnahme durchführen:
```
/opt/apigee/apigee-service/bin/apigee-all status
```
Achten Sie darauf, dass derzeit kein Laufzeittraffic am Rechenzentrum eingeht, das Sie außer Betrieb nehmen.

Reihenfolge der Außerbetriebnahme von Komponenten

Wenn Sie Edge for Private Cloud auf mehreren Knoten installieren, sollten Sie die Edge-Komponenten auf diesen Knoten in der folgenden Reihenfolge außer Betrieb nehmen:

Edge UI (edge-ui)
Management Server (edge-management-server)
Symas LDAP (apigee-openldap)
Router (Edge-Router)
Message Processor (edge-message-processor)
Qpid-Server und Qpidd (edge-qpid-server und apigee-qpidd)
Postgres und PostgreSQL-Datenbank (edge-postgres-server und apigee-postgresql)
ZooKeeper (apigee-zookeeper)
Cassandra (apigee-cassandra)

In den folgenden Abschnitten wird beschrieben, wie Sie die einzelnen Komponenten außer Betrieb nehmen.

Edge-Benutzeroberfläche

Geben Sie die folgenden Befehle ein, um die Edge-UI-Komponente von dc-1 zu beenden und zu deinstallieren:

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

Verwaltungsserver

So nehmen Sie den Verwaltungsserver auf dc-1 außer Betrieb:

Stoppen Sie den Management Server auf dc-1:
```
apigee-service edge-management-server stop
```

Suchen Sie nach der UUID des Management-Servers, der in dc-1 registriert ist:

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

Registrierung des Servertyps aufheben:

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"

Löschen Sie den Server. Hinweis:Wenn auf diesem Server auch andere Komponenten installiert sind, müssen Sie zuerst alle abmelden, bevor Sie die UUID löschen.
```
curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/{UUID}
```

Deinstallieren Sie die Management Server-Komponente auf dc-1:

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

Symas LDAP

In diesem Abschnitt wird erläutert, wie Sie SymasLDAP auf dc-1 außer Betrieb nehmen.

Hinweis:Wenn Sie mehr als zwei Rechenzentren haben, lesen Sie unten den Abschnitt Einrichtungen mit mehr als zwei Rechenzentren.

Führen Sie die folgenden Schritte aus, um SymasLDAP auf dc-1 außer Betrieb zu nehmen:

Sichern Sie den dc-1-SymasLDAP-Knoten, indem Sie der Anleitung unter Sichern folgen.
Brechen Sie die Datenreplikation zwischen den beiden Rechenzentren dc-1 und dc-2 ab, indem Sie die folgenden Schritte in beiden Rechenzentren ausführen.
Hinweis:Wenn Ihre Einrichtung mehr als zwei Rechenzentren umfasst, müssen Sie Folgendes tun:
1. Ermitteln Sie, welcher SymasLDAP-Knoten auf den Knoten repliziert, der außer Betrieb genommen wird.
2. Ändern Sie die Replikation für diesen Knoten so, dass er auf einen anderen Knoten repliziert wird, um den Replikationszyklus zu schließen.
Angenommen, Sie haben drei Rechenzentren, in denen Knoten 1 auf Knoten 2, Knoten 2 auf Knoten 3 und Knoten 3 auf Knoten 1 repliziert wird. Wenn Sie Knoten 1 außer Betrieb nehmen, müssen Sie die Replikation auf Knoten 1 beenden und die Replikation für Knoten 3 so ändern, dass die Daten auf Knoten 2 repliziert werden.
1. Aktuellen Status prüfen:
```
      /opt/symas/bin/ldapsearch -H ldap://{HOST}:{PORT} -LLL -x -b "cn=config" -D "cn=admin,cn=config" -w {credentials} -o ldif-wrap=no 'olcSyncRepl' | grep olcSyncrepl
```
  Die Ausgabe sollte in etwa so aussehen:
```
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. Erstellen Sie eine Datei mit dem Namen break_repl.ldif, die die folgenden Befehle enthält:
```
dn: olcDatabase={2}mdb,cn=config
changetype: modify
delete: olcSyncRepl

dn: olcDatabase={2}mdb,cn=config
changetype: modify
delete: olcMirrorMode
```
3. Führen Sie den Befehl ldapmodify aus:
```
      /opt/symas/bin/ldapmodify -x -w {credentials} -D "cn=admin,cn=config" -H "ldap://{HOST}:{PORT}/" -f path/to/file/break_repl.ldif
```
  Die Ausgabe sollte in etwa so aussehen:
```
modifying entry "olcDatabase={2}mdb,cn=config"
modifying entry "olcDatabase={2}mdb,cn=config"
```
Sie können prüfen, ob dc-2 nicht mehr auf dc-1 repliziert wird, indem Sie einen Eintrag in dc-2 LDAP erstellen und darauf achten, dass er nicht in LDAP von dc-1 angezeigt wird.

Optional können Sie die folgenden Schritte ausführen, um einen schreibgeschützten Nutzer auf dem dc-2-SymasLDAP-Knoten zu erstellen und dann zu prüfen, ob der Nutzer repliziert wird. Der Nutzer wird anschließend gelöscht.
1. Erstellen Sie eine Datei readonly-user.ldif in dc-2 mit folgendem Inhalt:
```
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. Fügen Sie den Nutzer mit dem Befehl „ldapadd“ in dc-2 hinzu:
```
/opt/symas/bin/ldapadd -H ldap://{HOST}:{PORT} -w {credentials} -D "cn=manager,dc=apigee,dc=com" -f path/to/file/readonly-user.ldif
```
  Die Ausgabe sieht etwa so aus:
```
adding new entry "uid=readonly-user,ou=users,ou=global,dc=apigee,dc=com"
```
3. Suchen Sie in dc-1 nach dem Nutzer, um sicherzugehen, dass er nicht repliziert wird. Wenn der Nutzer nicht in dc-1 vorhanden ist, können Sie sicher sein, dass beide LDAPs nicht mehr repliziert werden:
```
/opt/symas/bin/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
```
  Die Ausgabe sollte in etwa so aussehen:
```
No such object (32)
Matched DN: ou=users,ou=global,dc=apigee,dc=com
```
4. Entfernen Sie den zuvor hinzugefügten Nutzer mit Lesezugriff:
```
/opt/symas/bin/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"
```

SymasLDAP in dc-1 beenden:

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

Deinstallieren Sie die SymasLDAP-Komponente auf dc-1:

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

Router

In diesem Abschnitt wird beschrieben, wie Sie einen Router außer Betrieb nehmen. Weitere Informationen zum Entfernen des Routers finden Sie unter Server entfernen.

In den folgenden Schritten wird der Router von dc-1 außer Betrieb genommen. Wenn in dc-1 mehrere Router-Knoten konfiguriert sind, führen Sie die Schritte auf allen Router-Knoten nacheinander aus.

Hinweis:Hier wird davon ausgegangen, dass der Systemdiagnoseport 15999 des Routers in Ihrem Load-Balancer konfiguriert ist und dass das Blockieren des Ports 15999 den Router unerreichbar macht. Möglicherweise benötigen Sie Root-Zugriff, um den Port zu blockieren.

So nimmst du einen Router außer Betrieb:

Deaktivieren Sie die Erreichbarkeit von Routern, indem Sie Port 15999, den Systemdiagnose-Port, blockieren. Achten Sie darauf, dass Laufzeittraffic in diesem Rechenzentrum blockiert wird:
```
iptables -A INPUT -i eth0 -p tcp --dport 15999 -j REJECT
```

Prüfen Sie, ob der Router erreichbar ist:

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

Die Ausgabe sollte in etwa so aussehen:

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

Rufen Sie die UUID des Routers ab, wie unter UUIDs abrufen beschrieben.

Router stoppen:

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

Listen Sie die verfügbaren Gateway-Pods in der Organisation mit dem folgenden Befehl auf:
```
curl -u  <AdminEmailID>:'<AdminPassword>' -X GET "http://{MS_IP}:8080/v1/organizations/{ORG}/pods"
```
Weitere Informationen finden Sie unter Pods.

Heben Sie die Registrierung des Servertyps auf:

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

Registrierung des Servers aufheben:

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

edge-router deinstallieren:
```
/opt/apigee/apigee-service/bin/apigee-service edge-router uninstall
```
Weitere Informationen finden Sie unter Server entfernen.
Löschen Sie die iptables-Regeln, um den blockierten Port 15999 zu aktivieren:
```
iptables -F
```

Message Processor

In diesem Abschnitt wird beschrieben, wie Sie den Message Processor von dc-1 außer Betrieb nehmen. Weitere Informationen zum Entfernen des Message Processors finden Sie unter Server entfernen.

Da wir davon ausgehen, dass dc-1 eine Clusterinstallation mit 12 Knoten hat, sind in dc-1 zwei Message Processor-Knoten konfiguriert. Führen Sie die folgenden Befehle auf beiden Knoten aus.

Rufen Sie die UUIDs der Nachrichtenprozessoren ab, wie unter UUIDs abrufen beschrieben.

Beenden Sie den Nachrichtenprozessor:

apigee-service edge-message-processor stop

Heben Sie die Registrierung des Servertyps auf:

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"

Trennen Sie eine Umgebung vom Message Processor.

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

Heben Sie die Registrierung des Servertyps auf:

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"

Nachrichtenprozessor deinstallieren:

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

Registrierung des Servers aufheben:

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

Qpid-Server und Qpidd

In diesem Abschnitt wird beschrieben, wie Sie Qpid Server (edge-qpid-server) und Qpidd (apigee-qpidd) außer Betrieb nehmen. In dc-1 sind zwei Qpid-Knoten konfiguriert. Sie müssen die folgenden Schritte also für beide Knoten ausführen:

Rufen Sie die UUID für Qpidd ab, wie unter UUIDs abrufen beschrieben.

Beenden Sie edge-qpid-server und apigee-qpidd:

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

Liste der Analyse- und Nutzergruppen abrufen:

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

Entfernen Sie Qpid aus der Nutzergruppe:

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}"

Entfernen Sie Qpid aus der Analysegruppe:

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

Heben Sie die Registrierung des Qpid-Servers für die Edge-Installation auf:

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"

Entfernen Sie den Qpid-Server aus der Edge-Installation:

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

Starten Sie alle „edge-qpid-server“-Komponenten auf allen Knoten neu, damit die Änderung von diesen Komponenten übernommen wird:

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

Deinstallieren Sie edge-qpid-server und apigee-qpidd:

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

Postgres und Postgresql

Das Rechenzentrum, das Sie außer Betrieb nehmen, kann einen Postgres-Master oder einen Postgres-Standby haben. In den folgenden Abschnitten wird beschrieben, wie Sie sie außer Betrieb nehmen:

Postgres-Master außer Betrieb nehmen
Außerbetriebnahme von Postgres-Standby

Achtung:Sie müssen Postgresql-Server gleichzeitig aus der Analytics-Gruppe und der Verbrauchergruppe entfernen und hinzufügen. Wenn zwischen den beiden Schritten eine erhebliche Verzögerung auftritt, gehen möglicherweise einige Analysedaten verloren.

Vorschlag: Der Message Processor hat eine kleine Warteschlange, in der er Analysedaten für kurze Zeit im Arbeitsspeicher speichert. So können Sie Datenverlust vermeiden. Bevor Sie Änderungen an der Analysegruppe vornehmen, blockieren Sie Port 5672 im Rechenzentrum, das Traffic empfängt, und aktivieren Sie diesen Port nach den Änderungen schnell wieder, da sonst die Gefahr eines Datenüberlaufs besteht.

So können Sie beispielsweise den Analyse-Traffic von Message Processors zum Qpid-Server vorübergehend stoppen:

Geben Sie den folgenden Befehl ein:

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

Folgen Sie der Anleitung zum Ändern der axgroup.
Entfernen Sie die iptable-Regel nach Änderungen an der AX-Gruppe:
```
iptables -F
```

Postgres-Master außer Betrieb nehmen

Hinweis:Wenn Sie den Postgres-Master außer Betrieb nehmen, müssen Sie einen der verfügbaren Standby-Knoten zum neuen Postgres-Master hochstufen. Die QPID-Warteschlangen puffern zwar Daten, wenn der Postgres-Master jedoch längere Zeit nicht verfügbar ist, besteht das Risiko, dass Analysedaten verloren gehen.

So nehmen Sie den Postgres-Master außer Betrieb:

Sichern Sie den Postgres-Masterknoten „dc-1“ gemäß der Anleitung in den folgenden Links:
- Back-up und Wiederherstellung
- Sichern
Rufen Sie die UUIDs der Postgres-Server ab, wie unter UUIDs abrufen beschrieben.

Beenden Sie auf dc-1 edge-postgres-server und apigee-postgresql auf dem aktuellen Master:

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

Geben Sie auf dem Standby-Knoten auf dc-2 den folgenden Befehl ein, um ihn zum Masterknoten zu machen:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql promote-standby-to-master <IP of OLD Progress master>
```
Hinweis:Wenn Sie mehr als einen Standby-Postgres-Knoten haben, müssen Sie dem neuen Master Hosteinträge hinzufügen und die Replikationseinstellung für alle verfügbaren Postgres-Standby-Knoten aktualisieren.

So fügen Sie dem neuen Postgres-Master Host-Einträge hinzu: Folgen Sie den Schritten im entsprechenden Abschnitt unten:

Wenn nur noch ein Standby-Knoten vorhanden ist

Angenommen, vor der Außerbetriebnahme waren drei Postgres-Knoten konfiguriert. Sie haben den vorhandenen Master außer Betrieb genommen und einen der verbleibenden Postgres-Standby-Knoten zum Master hochgestuft. Konfigurieren Sie den verbleibenden Standby-Knoten mit den folgenden Schritten:
1. Bearbeiten Sie auf dem neuen Master die Konfigurationsdatei, um Folgendes festzulegen:
```
PG_MASTER=IP_or_DNS_of_new_PG_MASTER
PG_STANDBY=IP_or_DNS_of_PG_STANDBY
```
2. Aktivieren Sie die Replikation auf dem neuen Master:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFIle
```
Wenn mehr als ein Standby-Knoten verbleibt
1. Fügen Sie die folgende Konfiguration in /opt/apigee/customer/application/postgresql.properties hinzu:
```
conf_pg_hba_replication.connection=host replication apigee standby_1_ip/32 trust \n host replication apigee standby_2_ip/32 trust
```
2. Prüfen Sie, ob die Datei „/opt/apigee/customer/application/postgresql.properties“ dem Apigee-Nutzer gehört:
```
chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
```
3. Starten Sie apigee-postgresql neu:
```
apigee-service apigee-postgresql restart
```
4. Prüfen Sie mit dem folgenden Befehl in dc-2, ob der Postgres-Master richtig eingerichtet ist:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
```
5. PostgreSQL-Server aus der Analytics-Gruppe und der Nutzergruppe entfernen und hinzufügen.
  Achtung:Führen Sie die nächsten beiden Schritte zusammen aus, da zwischen den beiden Schritten Analysedaten verloren gehen können.
  1. Entfernen Sie den alten Postgres-Server aus der Analysegruppe. Folgen Sie dazu der Anleitung unter Postgres-Server aus einer Analysegruppe entfernen.
  2. Fügen Sie der Analysegruppe einen neuen Postgres-Server hinzu. Folgen Sie dazu der Anleitung unter Einen vorhandenen Postgres-Server einer Analysegruppe hinzufügen.
6. Heben Sie die Registrierung des alten Postgres-Servers in dc-1 auf:
```
curl -u <AdminEmailID>:<AdminPassword> -X POST http://{MS_IP}:8080/v1/servers \
-d "type=postgres-server®ion=dc-1&pod=analytics&uuid=UUID&action=remove"
      
```
7. Löschen Sie den alten Postgres-Server von dc-1:
```
curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/UUID
```
8. Der alte Postgres-Master kann jetzt außer Betrieb genommen werden. Deinstallieren Sie edge-postgres-server und apigee-postgresql:
```
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server uninstall
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql uninstall
```
Postgres-Standby-Instanz außer Betrieb nehmen

Hinweis:In der Dokumentation für eine Installation mit 12 Knoten im Cluster wird der PostgreSQL-Knoten „dc-1“ als Master angezeigt. In diesem Abschnitt wird jedoch davon ausgegangen, dass der PostgreSQL-Knoten „dc-1“ ein Standby-Knoten und der PostgreSQL-Knoten „dc-2“ der Master ist.

So nehmen Sie den Postgres-Standby-Server außer Betrieb:
1. Rufen Sie die UUIDs der Postgres-Server ab. Folgen Sie dazu der Anleitung unter UUIDs abrufen.
2. Stoppen Sie apigee-postgresql auf dem aktuellen Standby-Knoten 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. PostgreSQL-Server aus der Analytics-Gruppe und der Nutzergruppe entfernen und hinzufügen.
  Achtung:Führen Sie die nächsten beiden Schritte zusammen aus, da zwischen den beiden Schritten Analysedaten verloren gehen können.
  1. Entfernen Sie den alten Postgres-Server aus der Analysegruppe. Folgen Sie dazu der Anleitung unter Postgres-Server aus einer Analysegruppe entfernen.
  2. Fügen Sie der Analysegruppe einen neuen Postgres-Server hinzu. Folgen Sie dazu der Anleitung unter Einen vorhandenen Postgres-Server einer Analysegruppe hinzufügen.
4. Heben Sie die Registrierung des alten Postgres-Servers in dc-1 auf:
```
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. Löschen Sie den alten Postgres-Server von dc-1:
```
curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/UUID
```
6. Der alte Postgres-Master kann jetzt außer Betrieb genommen werden. Deinstallieren Sie edge-postgres-server und apigee-postgresql:
```
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server uninstall
```
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql uninstall
```
ZooKeeper und Cassandra

In diesem Abschnitt wird beschrieben, wie Sie ZooKeeper- und Cassandra-Server in einer Einrichtung mit zwei Rechenzentren außer Betrieb nehmen.

Wenn Sie mehr als zwei Rechenzentren haben, müssen Sie alle Verweise auf den stillgelegten Knoten (in diesem Fall „dc-1“) aus allen Dateien für die automatische Konfiguration in allen verbleibenden Rechenzentren entfernen. Entfernen Sie die Hosts für Cassandra-Knoten, die außer Betrieb genommen werden sollen, aus CASS_HOSTS. Die verbleibenden Cassandra-Knoten sollten in der ursprünglichen Reihenfolge von CASS_HOSTS bleiben.

Hinweis zu ZooKeeper:Sie müssen ein Quorum von Voter-Knoten beibehalten, wenn Sie die Eigenschaft ZK_HOST in der Konfigurationsdatei ändern, damit das ZooKeeper-Ensemble funktionsfähig bleibt. Ihre Konfiguration muss eine ungerade Anzahl von Voter-Knoten enthalten. Weitere Informationen finden Sie unter Wartungsaufgaben für Apache ZooKeeper.

Achtung:Wenn Sie ein Rechenzentrum mit einem Leader-ZooKeeper-Knoten außer Betrieb nehmen, kommt es zu Ausfallzeiten.

So nehmen Sie ZooKeeper- und Cassandra-Server außer Betrieb:
1. Sichern Sie die Cassandra- und ZooKeeper-Knoten von dc-1 gemäß der Anleitung unter den folgenden Links:
  - Back-up und Wiederherstellung
  - Sichern
  Hinweis:Wenn Sie mehrere ZooKeeper-Knoten haben, sichern Sie sie einzeln. Beim Sicherungsvorgang wird ZooKeeper vorübergehend heruntergefahren.
2. Listen Sie die UUIDs der ZooKeeper- und Cassandra-Server im Rechenzentrum auf, in dem die Cassandra-Knoten außer Betrieb genommen werden sollen.
```
apigee-adminapi.sh servers list -r dc-1 -p central -t application-datastore --admin <AdminEmailID> --pwd '<AdminPassword>' --host localhost
```
3. Heben Sie die Registrierung des Servertyps auf:
```
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. Registrierung des Servers aufheben:
```
curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://MS_IP:8080/v1/servers/UUID
```
5. Aktualisieren Sie die Konfigurationsdatei, indem Sie die IPs der außer Betrieb genommenen Knoten aus ZK_HOSTS und CASS_HOSTS entfernen.
  Hinweise:
  - Sie müssen ein Quorum von Knoten mit Wählerfunktion aufrechterhalten, während Sie das Attribut ZK_HOST in der Konfigurationsdatei ändern, damit das ZooKeeper-Ensemble funktionsfähig bleibt. Ihre Konfiguration muss eine ungerade Anzahl von Voter-Knoten enthalten. Weitere Informationen finden Sie unter ZooKeeper und Edge.
  - Entfernen Sie die Hosts für Cassandra-Knoten, die außer Betrieb genommen werden sollen, aus CASS_HOSTS. Die verbleibenden Cassandra-Knoten sollten in der ursprünglichen Reihenfolge von CASS_HOSTS bleiben.
  - ZooKeeper-Beobachtungsknoten nehmen nicht an der Abstimmung teil und werden bei der Bestimmung eines Quorums nicht berücksichtigt.
  Beispiel: Angenommen, Sie haben die IPs $IP1 $IP2 $IP3 in dc-1 und $IP4 $IP5 $IP6 in dc-2 und Sie legen dc-1 still. Entfernen Sie dann die IPs $IP1 $IP2 $IP3 aus den Konfigurationsdateien.
  - Vorhandene Einträge in der Konfigurationsdatei:
```
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”
```
  - Neue Einträge in der Konfigurationsdatei:
```
ZK_HOSTS="$IP4 $IP5 $IP6"
CASS_HOSTS="$IP4:2,1 $IP5:2,1 $IP6:2,1"
```
6. Aktualisieren Sie die Datei für die automatische Konfiguration (die Sie in Schritt e geändert haben) mit den IP-Adressen der entfernten, außer Betrieb genommenen Knoten und führen Sie das Management Server-Profil auf allen Knoten aus, auf denen Management Server gehostet werden:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ms -f updated_config_file
```
7. Aktualisieren Sie die Konfigurationsdatei mit den IP-Adressen der entfernten, außer Betrieb genommenen Knoten und führen Sie das MP-/RMP-Profil auf allen Router- und Message Processor-Knoten aus:
  - Wenn Edge Router und Message Processor auf demselben Knoten konfiguriert sind, geben Sie Folgendes ein:
```
/opt/apigee/apigee-setup/bin/setup.sh -p rmp -f updated_config_file
```
  - Wenn Edge Router und Message Processor auf separaten Knoten konfiguriert sind, geben Sie Folgendes ein:
    
    Für den Router:
```
/opt/apigee/apigee-setup/bin/setup.sh -p r -f updated_config_file
```
    Für den Message Processor:
```
/opt/apigee/apigee-setup/bin/setup.sh -p mp -f updated_config_file
```
8. Konfigurieren Sie alle Qpid-Knoten neu. Die IPs der außer Betrieb genommenen Knoten müssen aus der Antwortdatei entfernt werden:
```
/opt/apigee/apigee-setup/bin/setup.sh -p qs -f updated_config_file
```
9. Konfigurieren Sie alle Postgres-Knoten neu. Die IPs der außer Betrieb genommenen Knoten müssen aus der Antwortdatei entfernt werden:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ps -f updated_config_file
```
10. Ändern Sie den Schlüsselbereich system_auth. Wenn Sie die Cassandra-Authentifizierung auf einem vorhandenen Cassandra-Knoten aktiviert haben, aktualisieren Sie den Replikationsfaktor des system_auth-Schlüsselbereichs, indem Sie den folgenden Befehl ausführen:
```
ALTER KEYSPACE system_auth WITH replication = {'class': 'NetworkTopologyStrategy', 'dc-2': '3'};
```
  Mit diesem Befehl wird der Replikationsfaktor auf '3' festgelegt, was drei Cassandra-Knoten im Cluster entspricht. Ändern Sie diesen Wert nach Bedarf.
  
  Nach Abschluss dieses Schritts sollte die Cassandra-Topologie in keinem der Keyspaces dc-1 enthalten.
11. Nehmen Sie die Cassandra-Knoten in dc-1 einzeln außer Betrieb.
  Hinweis:Auf den außer Betrieb genommenen Knoten ist immer noch Cassandra mit Seed-Informationen des ursprünglichen Clusters installiert. Sollte der Cassandra-Dienst doch noch gestartet werden, treten die außer Betrieb genommenen Knoten dem Clusterring wieder bei. Um dies zu vermeiden, müssen Sie die Cassandra-Komponente nach der Außerbetriebnahme deinstallieren und verhindern, dass außer Betrieb genommene Knoten gestartet werden und dem Cluster wieder beitreten.
  
  Geben Sie den folgenden Befehl ein, um die Cassandra-Knoten außer Betrieb zu nehmen:
```
/opt/apigee/apigee-cassandra/bin/nodetool -h cassIP -u cassandra -pw '<AdminPassword>' decommission
```
  Hinweis:Wenn ein Knoten im Status „Außerbetriebnahme“ hängen bleibt, können Sie ihn mit Cassandra nodetool removenode entfernen. Beispiel:
```
/opt/apigee/apigee-cassandra/bin/nodetool removenode UUID
```
12. Prüfen Sie die Verbindung der Cassandra-Knoten von dc-1 aus mit einem der folgenden Befehle:
```
/opt/apigee/apigee-cassandra/bin/cqlsh cassIP 9042 -u cassandra -p '<AdminPassword>'
```
  Oder sekundärer Bestätigungsbefehl, der auf dem außer Betrieb genommenen Knoten ausgeführt werden soll:
```
/opt/apigee/apigee-cassandra/bin/nodetool netstats
```
  Der obige Befehl sollte Folgendes zurückgeben:
```
Mode: DECOMMISSIONED
```
13. Führen Sie das DS-Profil für alle Cassandra- und ZooKeeper-Knoten in dc-2 aus:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ds -f updated_config_file
```
14. Beenden Sie apigee-cassandra und apigee-zookeeper in dc-1:
```
apigee-service apigee-cassandra stop
apigee-service apigee-zookeeper stop
```
15. Deinstallieren Sie apigee-cassandra und apigee-zookeeper in dc-1:
```
apigee-service apigee-cassandra uninstall
apigee-service apigee-zookeeper uninstall
```
Bindungen aus dc-1 löschen

So löschen Sie die Bindungen aus dc-1:
1. Löschen Sie die Bindungen aus dc-1.
  1. Alle verfügbaren Pods in der Organisation auflisten:
```
curl -v -u  <AdminEmailID>:'<AdminPassword>' -X GET "http://MS_IP:8080/v1/o/ORG/pods"
```
  2. So prüfen Sie, ob alle Bindungen entfernt wurden: Rufen Sie die UUIDs der mit den Pods verknüpften Server ab:
```
curl -v -u  <AdminEmailID>:'<AdminPassword>' \
-X GET "http://MS_IP:8080/v1/regions/dc-1/pods/gateway-1/servers"
```
    Wenn bei diesem Befehl keine UUIDs zurückgegeben werden, wurden durch die vorherigen Schritte alle Bindungen entfernt und Sie können den nächsten Schritt überspringen. Andernfalls fahren Sie mit dem nächsten Schritt fort.
  3. Entfernen Sie alle Serverbindungen für die UUIDs, die Sie im vorherigen Schritt erhalten haben:
```
curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://MS_IP:8080/v1/servers/UUID
```
  4. Trennen Sie die Organisation vom 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. Pods löschen:
```
curl -v -u <AdminEmailID>:'<AdminPassword>' "http://MS_IP:8080/v1/regions/dc-1/pods/gateway-1" -X DELETE
```
3. Löschen Sie die Region.
```
curl -v -u <AdminEmailID>:'<AdminPassword>'  "http://MS_IP:8080/v1/regions/dc-1" -X DELETE
```
Hinweis:Wenn Sie einen der Schritte zum Löschen der Server auslassen, wird im obigen Schritt eine Fehlermeldung zurückgegeben, dass ein bestimmter Server im Pod noch vorhanden ist. Löschen Sie sie daher, indem Sie die unten aufgeführten Schritte zur Fehlerbehebung ausführen und die Typen im curl-Befehl anpassen.

An diesem Punkt haben Sie die Außerbetriebnahme von dc-1 abgeschlossen.

Anhang

Fehlerbehebung

Wenn nach Ausführung der vorherigen Schritte immer noch Server in einigen Pods vorhanden sind, führen Sie die folgenden Schritte aus, um die Registrierung der Server aufzuheben und sie zu löschen. Hinweis:Ändern Sie die Typen und den Pod nach Bedarf.
1. Rufen Sie die UUIDs mit dem folgenden Befehl ab:
```
apigee-adminapi.sh servers list -r dc-1 -p POD -t  --admin <AdminEmailID> --pwd  '<AdminPassword>’ --host localhost
```
2. Registrierung des Servertyps aufheben:
```
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. Löschen Sie die Server einzeln:
```
curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://MP_IP:8080/v1/servers/UUID
```
Validierung

Mit den folgenden Befehlen können Sie die Außerbetriebnahme validieren.

Verwaltungsserver
1. Führen Sie die folgenden Befehle auf den Verwaltungsservern in allen Regionen aus.
```
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
```
2. Führen Sie den folgenden Befehl für alle Komponenten aus, um die Portanforderungen für alle Verwaltungsports zu prüfen.
```
curl -v http://MS_IP:8080/v1/servers/self
```
3. Prüfen Sie die Analytics-Gruppe.
```
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
```

Außerbetriebnahme eines Rechenzentrums

Überlegungen vor der Stilllegung eines Rechenzentrums

Vorbereitung

Vorbereitung

Reihenfolge der Außerbetriebnahme von Komponenten

Edge-Benutzeroberfläche

Verwaltungsserver

Symas LDAP

Router

Message Processor

Qpid-Server und Qpidd

Postgres und Postgresql

Postgres-Master außer Betrieb nehmen

Wenn nur noch ein Standby-Knoten vorhanden ist

Wenn mehr als ein Standby-Knoten verbleibt

Postgres-Standby-Instanz außer Betrieb nehmen

ZooKeeper und Cassandra

Bindungen aus dc-1 löschen

Anhang

Fehlerbehebung

Validierung

Verwaltungsserver

Cassandra-/ZooKeeper-Knoten

Logs