Apigee Edge 4.53.00 oder 4.53.01 auf 4.54.00 aktualisieren

Apigee unterstützt das Upgrade von Edge for Private Cloud direkt von Version 4.53.00 oder 4.53.01 auf Version 4.54.00. Auf dieser Seite wird beschrieben, wie Sie solche Upgrades durchführen.

Eine Übersicht über kompatible Upgradepfade finden Sie in der Upgrade-Kompatibilitätsmatrix für Edge for Private Cloud-Releases.

Wer kann das Update durchführen?

Die Person, die das Update ausführt, sollte dieselbe Person sein, die Edge ursprünglich installiert hat, oder eine Person, die als Root ausgeführt wird.

Nachdem Sie die Edge-RPMs installiert haben, kann sie jeder konfigurieren.

Welche Komponenten müssen Sie aktualisieren?

Sie müssen alle Edge-Komponenten aktualisieren. Edge unterstützt keine Einrichtung, die Komponenten aus mehreren Versionen enthält.

Vorbereitende Materialien

In den folgenden Themen finden Sie wichtige Informationen zu den Änderungen, die in Edge for Private Cloud 4.54.00 eingeführt wurden:

• Änderungen in Version 4.54.00:Sehen Sie sich die Änderungen bei TLS und Java Callout an, die Vorbereitungen vor dem Upgrade erfordern. Weitere Informationen finden Sie unter Änderungen in 4.54.00.

• Dual-Java-Laufzeitarchitektur (Java 17 und Java 21): Ab Version 4.54.00 wird Java 8 in Edge for Private Cloud nicht mehr unterstützt. Komponenten werden entweder mit Java 17 oder Java 21 ausgeführt. Weitere Informationen finden Sie unter Änderungen in 4.54.00.

• Keine automatische Java-Installation während des Bootstraps: Edge for Private Cloud 4.54.00 kann Java-Installationen erkennen und prüft, ob sowohl Java 17 als auch Java 21 installiert sind.

• Neue Edge-UI in 4.54.00: Informationen zum Übergang zur neuen Edge-UI als Standardverwaltungsoberfläche und zum Entfernen der klassischen UI (edge-ui). Weitere Informationen finden Sie unter Neue Edge-Benutzeroberfläche.

• Apigee SSO in Version 4.54.00:Hier finden Sie Informationen zur aktualisierten SSO-Architektur und zu Konfigurationsänderungen für die Authentifizierung. Weitere Informationen finden Sie unter Apigee-SSO.

• Nginx 1.30 in 4.54.00:Hier finden Sie Informationen zum automatischen Upgrade auf Nginx 1.30.x auf Edge-Routern, zu möglichen Auswirkungen auf die Laufzeit und zu Maßnahmen zur Risikominderung. Weitere Informationen finden Sie unter Nginx 1.30 Changes.

Voraussetzungen für das Upgrade

Prüfen Sie vor dem Upgrade von Apigee Edge, ob die folgenden Voraussetzungen erfüllt sind:

• Versionshinweise und neue Funktionen

  Lesen Sie sich alle neuen Funktionen, Verhaltensänderungen und Einstellungen, die in den Edge for Private Cloud-Versionshinweisen für Version 4.54.00 beschrieben sind, sorgfältig durch, bevor Sie mit dem Upgrade beginnen.

• Automatische Erkennung und Koexistenz von Java-Binärdateien während des Upgrades: Installieren Sie Java mit Standardpaketmanagern (z. B. yum) oder an Standardspeicherorten (z. B. /usr/lib/jvm oder update-alternatives). Sie müssen nicht beide Versionen gleichzeitig im Systempfad konfigurieren. Deinstallieren Sie Java 8 nicht vor dem Upgrade. Lassen Sie Java 8 neben Java 17 und Java 21 installiert, damit vorhandene Edge for Private Cloud 4.53.xx-Dienste bis zu ihrer Aktualisierung ohne Unterbrechung weiter ausgeführt werden.

• Alle Knoten sichern

  Wir empfehlen, vor dem Aktualisieren aus Sicherheitsgründen ein vollständiges Backup aller Knoten durchzuführen. Führen Sie die Sicherung gemäß dem Verfahren für Ihre aktuelle Edge-Version durch. So haben Sie einen Plan B, falls das Update auf eine neue Version nicht richtig funktioniert. Weitere Informationen zur Sicherung finden Sie unter Sichern und Wiederherstellen.

• Backup der Konfigurationsdatei für die automatische Konfiguration

  Achten Sie darauf, dass Sicherungskopien der Konfigurationsdateien für die unbeaufsichtigte Installation für Edge for Private Cloud 4.53.00 oder 4.53.01 aufbewahrt werden, um bei Bedarf ein Rollback zu ermöglichen.

• Prüfen, ob Edge ausgeführt wird

  Prüfen Sie mit dem folgenden Befehl, ob Edge während des Aktualisierungsvorgangs ausgeführt wird:

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

• Cassandra-Voraussetzungen prüfen

  Wenn Sie zuvor ein Upgrade von einer älteren Version von Edge for Private Cloud auf Version 4.53.00 oder 4.53.01 durchgeführt haben und jetzt ein Upgrade auf Version 4.54.00 planen, müssen Sie die erforderlichen Schritte nach dem Upgrade für Cassandra ausführen. Diese Schritte sind in der Upgrade-Dokumentation für Version 4.53.00 oder 4.53.01 beschrieben und werden auch unter Voraussetzungen für das Cassandra-Upgrade erwähnt. Wenn Sie sich nicht sicher sind, ob diese Schritte beim vorherigen Upgrade ausgeführt wurden, führen Sie sie noch einmal aus, bevor Sie mit dem Upgrade auf Version 4.54.00 fortfahren.

• apigee-monit beenden: Wenn apigee-monit auf dem Knoten ausgeführt wird, beenden Sie es vor dem Upgrade mit /opt/apigee/apigee-service/bin/apigee-service apigee-monit stop. Dadurch wird verhindert, dass apigee-monit Komponenten während des Upgrades automatisch neu startet. Aktivieren Sie es nach Abschluss des Upgrades mit „apigee-service apigee-monit start“ wieder.

Automatische Übernahme von Property-Einstellungen

Wenn Sie Attribute durch Bearbeiten von .properties-Dateien in /opt/apigee/customer/application festgelegt haben, werden diese Werte beim Update beibehalten.

Router und Message Processor aktualisieren

Aktualisieren Sie alle Router- und Message Processor-Knoten in den Rechenzentren nacheinander:

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

Verwaltungsserver aktualisieren

Führen Sie ein Upgrade aller Management Server-Knoten in allen Rechenzentren nacheinander durch:

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

Upgrade auf OpenLDAP 2.6.10

Mit Edge for Private Cloud 4.54.00 wird OpenLDAP 2.6.10 eingeführt. Dieses Upgrade gilt für alle Apigee OpenLDAP-Bereitstellungstopologien: Einzelserver, Aktiv/Passiv und Aktiv/Aktiv (Multi-Master).

Vorbereitung und Installation (alle LDAP-Server)

Upgrade auf die neue Edge-Benutzeroberfläche und Apigee-SSO (falls installiert)

In Apigee Edge for Private Cloud 4.54.00 wird die klassische Benutzeroberfläche (edge-ui) entfernt und durch die neue Edge-Benutzeroberfläche (edge-management-ui) ersetzt. Je nachdem, ob Apigee Single Sign-On (SSO) in Ihrer Einrichtung installiert ist und verwendet wird, folgen Sie einer der beiden folgenden Optionen:

# Authentication mode for New Edge UI (Basic Authentication - No Apigee SSO)
AUTH_MODE=basic

# Access configuration for the New Edge UI
MANAGEMENT_UI_PORT=3001
MANAGEMENT_UI_APP_ENV=OPDK
MANAGEMENT_UI_IP=MANAGEMENT_UI_NODE_IP #Replace MANAGEMENT_UI_NODE_IP with the IP address or hostname of the UI node.
MANAGEMENT_UI_SCHEME=http

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

apigee-service apigee-sso stop

/opt/apigee/apigee-service/bin/apigee-service apigee-openldap setup-sso -f configFile

/opt/apigee/apigee-service/bin/apigee-service edge-management-ui configure-sso -f configFile

apigee-service apigee-sso uninstall

Upgrade auf Qpid 10.0.1

Mit dieser Methode wird sichergestellt, dass es keine Ausfallzeiten für Ihre Edge-Laufzeitumgebung gibt. Außerdem wird der Verlust von Laufzeitdaten, die für Analysen erfasst wurden, minimiert.

So führen Sie ein direktes Upgrade auf Qpid ohne Ausfallzeit durch:

1. Wählen Sie einen Qpid-Knoten aus, mit dem Sie beginnen möchten.

2. Beenden Sie den Qpid-Broker auf dem Knoten:

   apigee-service apigee-qpidd stop

3. Blockieren Sie eingehenden Traffic auf Broker-Port 5672 von allen Message Processors, indem Sie eine Firewall anwenden. Sie können diese Firewall auf der Ebene der Qpid-Knoteninstanz oder einer anderen externen Firewall-/Netzwerkkomponente anwenden.

   Wir empfehlen, diesen Schritt für alle IP-Adressen des Message Processors auszuführen. Wenn Sie beispielsweise Anfragen von Message Processor-IP-Adressen an den Qpid-Knoten auf Port 5672 mit IPTables ablehnen möchten, können Sie einen Befehl wie diesen verwenden:

   iptables -A INPUT -p tcp --dport 5672 -s MESSAGE_PROCESSOR_IP -j DROP

4. Starten Sie den Qpid-Broker noch einmal, um vorhandene Nachrichten zu leeren:

   apigee-service apigee-qpidd start

5. Prüfen Sie, ob die vorhandenen Warteschlangen leer sind:

   /opt/apigee/apigee-qpidd/bin/qpid-stat -q

   Wenn Nachrichten in der Dead-Letter-Warteschlange (DLQ) (ax-q-axgroup-001-consumer-group-001-dl) feststecken, leeren Sie die Warteschlange mit den Schritten zum Beheben von Analysedaten, die in der Dead-Letter-Warteschlange feststecken.

6. Nachdem Sie überprüft haben, dass die Warteschlangen auf dem alten Knoten leer sind, beenden Sie apigee-qpidd:

   apigee-service apigee-qpidd stop

7. Führen Sie ein Upgrade von Qpid auf dem Knoten durch:

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

8. Starten Sie edge-qpid-server neu:

   apigee-service edge-qpid-server restart

9. Entfernen Sie die in Schritt 3 angewendete Firewallregel.

   Führen Sie denselben Entfernungsschritt für alle Message Processor-IP-Adressen aus, auf die die Firewall angewendet wurde. Sobald die Firewalls entfernt wurden, werden Anfragen von Message Processor-IP-Adressen an den Qpid-Knoten an Port 5672 akzeptiert. Wenn Sie die Firewall mit iptables hinzugefügt haben, können Sie sie mit Befehlen wie den folgenden entfernen und die vorhandenen Einstellungen auflisten:

   iptables -F
   iptables -L

10. Prüfen Sie mithilfe des Webmonitorings, ob die Qpid-Warteschlangen Nachrichten empfangen:

    http://QPID_NODE_IP:8090

11. Wiederholen Sie die Schritte 1 bis 9 für jeden Qpid-Knoten.

Upgrade auf Postgres 18.6

Diese Version von Edge enthält ein Upgrade auf Postgres 18.6. Im Rahmen dieses Upgrades werden alle Postgres-Daten zu Postgres 18.6 migriert.

Die meisten Edge-Produktionssysteme verwenden zwei Postgres-Knoten, die für die Primär-Standby-Replikation konfiguriert sind. Während des Aktualisierungsvorgangs, wenn die Postgres-Knoten für die Aktualisierung inaktiv sind, werden Analysedaten weiterhin auf die Qpid-Knoten geschrieben. Nachdem die Postgres-Knoten aktualisiert wurden und wieder online sind, werden Analysedaten an die Postgres-Knoten gesendet.

Wie Sie das Postgres-Update ausführen, hängt davon ab, wie Sie den Datenspeicher für Ihre Postgres-Knoten konfiguriert haben:

• Wenn Sie einen lokalen Datenspeicher für Ihre Postgres-Knoten verwenden , müssen Sie für die Dauer des Upgrades einen neuen Postgres-Standby-Knoten installieren. Nach Abschluss des Upgrades können Sie den neuen Postgres-Standby-Knoten außer Betrieb nehmen. Der zusätzliche Postgres-Standby-Knoten ist erforderlich, wenn Sie das Update aus irgendeinem Grund zurücksetzen müssen. Wenn Sie das Update zurücksetzen müssen, wird der neue Postgres-Stand-by-Knoten nach dem Rollback zum primären Postgres-Knoten. Wenn Sie den neuen Postgres-Standby-Knoten installieren, sollte er sich daher auf einem Knoten befinden, der alle Hardwareanforderungen eines Postgres-Servers erfüllt, wie in den Installationsanforderungen für Edge definiert.

  In einer 1-Knoten- und 2-Knoten-Konfiguration von Edge, die für Prototyping und Tests verwendet wird, haben Sie nur einen einzigen Postgres-Knoten. Sie können diese Postgres-Knoten direkt aktualisieren, ohne einen neuen Postgres-Knoten erstellen zu müssen.

• Wenn Sie Netzwerkspeicher für Ihre Postgres-Knoten verwenden , wie von Apigee empfohlen, müssen Sie keinen neuen Postgres-Knoten installieren. In den folgenden Verfahren können Sie die Schritte überspringen, in denen die Installation und spätere Außerbetriebnahme eines neuen Postgres-Standby-Knotens beschrieben wird. Erstellen Sie vor dem Aktualisieren einen Netzwerk-Snapshot des von Postgres verwendeten Datenspeichers. Wenn dann während des Updates Fehler auftreten und Sie ein Rollback ausführen müssen, können Sie den Postgres-Knoten aus diesem Snapshot wiederherstellen.

Neuen Postgres-Standby-Knoten installieren

Mit diesem Verfahren wird ein Postgres-Standby-Server auf einem neuen Knoten erstellt. Installieren Sie einen neuen Postgres-Standby-Server für Ihre bestehende Edge-Version (4.53.00 oder 4.53.01), nicht für Version 4.54.00.

Verwenden Sie für die Installation dieselbe Konfigurationsdatei, die Sie auch für die Installation Ihrer aktuellen Edge-Version verwendet haben.

So erstellen Sie einen neuen Postgres-Standby-Knoten:

1. Bearbeiten Sie auf der aktuellen Postgres-Primärinstanz die Datei /opt/apigee/customer/application/postgresql.properties, um das folgende Token festzulegen. Wenn die Datei nicht vorhanden ist, erstellen Sie sie:

   conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust\ \nhost replication apigee new_standby_ip/32 trust

   Dabei ist existing_standby_ip die IP-Adresse des aktuellen Postgres-Standby-Servers und new_standby_ip die IP-Adresse des neuen Standby-Knotens.

2. Starten Sie apigee-postgresql auf dem primären Postgres-Server neu:

   /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

3. Prüfen Sie, ob der neue Standby-Knoten hinzugefügt wurde, indem Sie die Datei /opt/apigee/apigee-postgresql/conf/pg_hba.conf auf dem primären Knoten aufrufen. In dieser Datei sollten die folgenden Zeilen enthalten sein:

   host replication apigee existing_standby_ip/32 trust
   host replication apigee new_standby_ip/32 trust

4. Installieren Sie den neuen Postgres-Standby-Server:

   1. Bearbeiten Sie die Konfigurationsdatei, die Sie zur Installation Ihrer aktuellen Edge-Version verwendet haben, um Folgendes anzugeben:

      # IP address of the current primary(master):
      PG_MASTER=PG_MASTER_NODE_IP
      # IP address of the new standby node
      PG_STANDBY=PG_STANDBY_NODE_IP

   2. Deaktivieren Sie SELinux, wie unter Das Edge-Einrichtungsprogramm apigee-setup installieren beschrieben.

   3. Laden Sie das Bootstrap-Script für Ihre aktuelle Edge-Version herunter und führen Sie es aus:

      • Wenn Sie derzeit Edge 4.53.00 verwenden:

        Laden Sie die Edge-Datei bootstrap_4.53.00.sh in /tmp/bootstrap_4.53.00.sh herunter:

        curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh

        Installieren Sie das Edge apigee-service-Dienstprogramm und die Abhängigkeiten:

        bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord

      • Wenn Sie derzeit Edge 4.53.01 verwenden:

        Laden Sie die Edge-Datei bootstrap_4.53.01.sh in /tmp/bootstrap_4.53.01.sh herunter:

        curl https://software.apigee.com/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh

        Installieren Sie das Edge apigee-service-Dienstprogramm und die Abhängigkeiten:

        bash /tmp/bootstrap_4.53.01.sh apigeeuser=uName apigeepassword=pWord

   4. Verwenden Sie apigee-service, um das apigee-setup-Dienstprogramm zu installieren:

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

   5. Postgres installieren:

      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile

   6. Führen Sie auf dem neuen Stand-by-Knoten den folgenden Befehl aus und prüfen Sie, ob es sich um den Stand-by handelt:

      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

Direktes Upgrade von Postgres durchführen

Vorläufiger Schritt

Führen Sie vor einem In-Place-Upgrade auf Postgres die folgenden Schritte sowohl auf dem primären Host als auch auf dem Standby-Host aus, um das Attribut max_locks_per_transaction in apigee-postgresql zu aktualisieren:

1. Wenn sie nicht vorhanden ist, erstellen Sie die Datei /opt/apigee/customer/application/postgresql.properties .

2. Ändern Sie die Eigentümerschaft dieser Datei in „apigee“:

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

3. Fügen Sie der Datei das folgende Attribut hinzu:

   conf/postgresql.conf+max_locks_per_transaction=30000

4. Konfigurieren Sie apigee-postgresql :

   apigee-service apigee-postgresql configure

5. Starten Sie apigee-postgresql neu :

   apigee-service apigee-postgresql restart

Direktes Upgrade ausführen

So führen Sie ein direktes Upgrade auf Postgres 18 durch:

1. Postgres auf dem primären Host aktualisieren

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

2. Führen Sie den Einrichtungsbefehl auf dem primären Host aus:

   apigee-service apigee-postgresql setup -f configFile

3. Führen Sie den Konfigurationsbefehl auf dem primären Host aus:

   apigee-service apigee-postgresql configure

4. Starten Sie den primären Host neu:

   apigee-service apigee-postgresql restart

5. So konfigurieren Sie es als primäres Konto:

   apigee-service apigee-postgresql setup-replication-on-master -f configFile

6. Prüfen Sie, ob der primäre Host gestartet wurde:

   apigee-service apigee-postgresql wait_for_ready

7. Stand-by-Modus beenden:

   apigee-service apigee-postgresql stop

8. Führen Sie ein Upgrade des Stand-by-Systems durch.

   Hinweis: Wenn dieser Schritt fehlschlägt, kann er ignoriert werden. update.sh versucht, den Stand-by-Server mit einer falschen Konfiguration zu starten. Wenn die Postgres-Installation auf Version 18 aktualisiert wurde, kann der Fehler ignoriert werden.

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

9. Prüfe, ob der Standby-Modus beendet wurde:

   apigee-service apigee-postgresql stop

10. Entfernen Sie die alte Standby-Konfiguration:

    rm -rf /opt/apigee/data/apigee-postgresql/

11. Richten Sie die Replikation auf dem Standby-Server ein:

    apigee-service apigee-postgresql setup-replication-on-standby -f configFile

12. Entfernen Sie die Zeile conf/postgresql.conf+max_locks_per_transaction=30000 aus der Datei /opt/apigee/customer/application/postgresql.properties sowohl auf dem primären Host als auch auf dem Standby-Host. Diese Zeile wurde im vorläufigen Schritt hinzugefügt .

    Nach Abschluss dieses Vorgangs wird die Stand-by-Datenbank erfolgreich gestartet.

Postgres-Knoten außer Betrieb nehmen

Nehmen Sie nach Abschluss des Updates den neuen Standby-Knoten außer Betrieb:

1. Prüfen Sie, ob Postgres ausgeführt wird:

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

   Wenn Postgres nicht ausgeführt wird, starten Sie es:

   /opt/apigee/apigee-service/bin/apigee-all start

2. Rufen Sie die UUID des neuen Stand-by-Knotens ab, indem Sie den folgenden curl-Befehl auf dem neuen Stand-by-Knoten ausführen:

   curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

   Am Ende der Ausgabe sollte die UUID des Knotens in folgendem Format angezeigt werden:

   "type" : [ "postgres-server" ],
   "uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"

3. Beenden Sie den neuen Standby-Knoten, indem Sie den folgenden Befehl auf dem neuen Standby-Knoten ausführen:

   /opt/apigee/apigee-service/bin/apigee-all stop

4. Bearbeiten Sie auf dem primären Postgres-Knoten /opt/apigee/customer/application/postgresql.properties, um den neuen Standby-Knoten aus conf_pg_hba_replication.connection zu entfernen:

   conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust

5. Starten Sie apigee-postgresql auf dem primären Postgres-Server neu:

   /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

6. Prüfen Sie, ob der neue Standby-Knoten entfernt wurde. Sehen Sie sich dazu die Datei /opt/apigee/apigee-postgresql/conf/pg_hba.conf auf dem primären Knoten an. In dieser Datei sollte nur die folgende Zeile angezeigt werden:

   host replication apigee existing_standby_ip/32 trust

7. Löschen Sie die UUID des Standby-Knotens aus ZooKeeper, indem Sie den folgenden Edge Management API-Aufruf auf dem Management Server-Knoten ausführen:

   curl -u sysAdminEmail:password -X DELETE http://ms_IP:8080/v1/servers/new_standby_uuid

Schritte nach dem Upgrade für Postgres

Nach einem größeren Postgres-Upgrade werden die internen Statistiken von Postgres gelöscht. Diese Statistiken helfen dem Postgres-Abfrageplaner, die optimalen Indexe und Pfade für die Ausführung von Abfragen zu verwenden.

Postgres kann seine Statistiken im Laufe der Zeit nach und nach neu erstellen, wenn Abfragen ausgeführt werden und der Autovacuum-Daemon ausgeführt wird. Bis die Statistiken neu erstellt wurden, können Ihre Abfragen jedoch langsam sein.

Führen Sie ANALYZE für alle Tabellen in der Datenbank auf dem primären Postgres-Knoten aus, um dieses Problem zu beheben. Alternativ können Sie ANALYZE für jeweils einige Tabellen ausführen.

Upgrade auf ZooKeeper 3.8.5

Diese Version von Edge for Private Cloud enthält ein Upgrade auf ZooKeeper 3.8.5. Im Rahmen dieses Upgrades werden alle ZooKeeper-Daten zu ZooKeeper 3.8.5 migriert.

Lesen Sie vor dem Upgrade von ZooKeeper die Anleitung zur ZooKeeper-Wartung. Die meisten Edge-Produktionssysteme verwenden einen Cluster von ZooKeeper-Knoten, die auf mehrere Rechenzentren verteilt sind. Einige dieser Knoten sind als Wähler konfiguriert, die an der ZooKeeper-Leader-Wahl teilnehmen, die restlichen als Beobachter. Weitere Informationen finden Sie unter Führungskräfte, Follower, Wähler und Beobachter. Die Voter-Knoten wählen einen Leader, woraufhin die Voter-Knoten selbst zu Followern werden.

Während des Aktualisierungsvorgangs kann es zu einer vorübergehenden Verzögerung oder einem Schreibfehler in ZooKeeper kommen, wenn der Leader-Knoten heruntergefahren wird. Dies kann sich auf Verwaltungsvorgänge auswirken, die in ZooKeeper schreiben, z. B. die Bereitstellung eines Proxys, und auf Änderungen an der Apigee-Infrastruktur, z. B. das Hinzufügen oder Entfernen eines Message Processors. Bei der Aktualisierung von ZooKeeper gemäß der folgenden Anleitung sollte es keine Auswirkungen auf die Laufzeit-APIs von Apigee geben, es sei denn, diese Laufzeit-APIs rufen Verwaltungs-APIs auf.

Im Großen und Ganzen umfasst der Upgradeprozess das Erstellen einer Sicherung jedes Knotens. Anschließend werden alle Beobachter und Follower und schließlich der Leader-Knoten aktualisiert.

Sicherung erstellen

Erstellen Sie eine Sicherung aller ZooKeeper-Knoten, falls ein Rollback erforderlich ist. Beachten Sie, dass ZooKeeper durch ein Rollback in den Zustand zurückversetzt wird, in dem es sich zum Zeitpunkt der Sicherung befand.

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

Wenn Sie virtuelle Maschinen verwenden und die Möglichkeit dazu haben, können Sie auch VM-Snapshots oder -Backups für die Wiederherstellung oder das Rollback (falls erforderlich) erstellen.

Leader, Follower und Beobachter identifizieren

1. Wenn es nicht auf dem ZooKeeper-Knoten installiert ist, installieren Sie nc:

   yum install nc

2. Führen Sie den folgenden nc-Befehl auf dem Knoten aus. Dabei ist 2181 der ZooKeeper-Port:

   echo stat | nc localhost 2181

   Die Ausgabe sollte etwa so aussehen:

   Zookeeper version: 3.8.5-19f1842d4b6ee1f82cc8b05284959b26c6ae507d, built on 2025-09-03 21:35 UTC
   Clients:
    /[0:0:0:0:0:0:0:1]:40696[0](queued=0,recved=1,sent=0)
   
   Latency min/avg/max: 3/4.3333/6
   Received: 4
   Sent: 3
   Connections: 1
   Outstanding: 0
   Zxid: 0x500000005
   Mode: follower

   In der Zeile Mode der Ausgabe für die Knoten sollte je nach Knotenkonfiguration „observer“, „leader“ oder „follower“ (also ein Voter, der nicht der Leader ist) angezeigt werden.

1. Wiederholen Sie die Schritte 1 und 2 auf jedem ZooKeeper-Knoten.

ZooKeeper auf den Beobachter- und Follower-Knoten aktualisieren

Führen Sie auf jedem der Observer- und Follower-Knoten ein Upgrade von ZooKeeper durch:

1. Laden Sie den Bootstrap von Edge for Private Cloud 4.54.00 herunter und führen Sie ihn aus, wie unter Auf Version 4.54.00 auf einem Knoten mit externer Internetverbindung aktualisieren beschrieben. Der Vorgang variiert wahrscheinlich je nachdem, ob der Knoten eine externe Internetverbindung hat oder ob Sie eine Offline-Installation durchführen.

2. Aktualisieren Sie die ZooKeeper-Komponente:

   /opt/apigee/apigee-setup/bin/update.sh -c zk -f silent-config-file

   Hinweis: Wenn auf diesen Knoten andere Komponenten installiert sind (z. B. Cassandra), können Sie diese jetzt auch aktualisieren (z. B. mit dem Profil „zk,cs“) oder die anderen Komponenten später aktualisieren. Apigee empfiehlt, zuerst nur ZooKeeper zu aktualisieren und zu prüfen, ob Ihr Cluster ordnungsgemäß funktioniert, bevor Sie andere Komponenten aktualisieren.

3. Wiederholen Sie die oben genannten Schritte auf jedem ZooKeeper-Beobachter- und ‑Follower-Knoten.

Führenden ausschalten

Nachdem alle Beobachter- und Follower-Knoten aktualisiert wurden, fahren Sie den Leader herunter. Führen Sie auf dem als Leader identifizierten Knoten den folgenden Befehl aus:

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

Während dieser Veranstaltung kann es in ZooKeeper zu vorübergehenden Verzögerungen oder Schreibfehlern kommen, bevor ein neuer Leader gewählt wird. Dies kann sich auf Vorgänge auswirken, die in ZooKeeper schreiben, z. B. die Bereitstellungsaktion von Proxys oder Änderungen an der Apigee-Infrastruktur, z. B. das Hinzufügen oder Entfernen von Message Processors.

Prüfen, ob der neue Leader gewählt wurde

Prüfen Sie anhand der Schritte im Abschnitt Leader, Follower und Beobachter identifizieren oben, ob ein neuer Leader aus den Followern ausgewählt wurde, nachdem der vorhandene Leader beendet wurde. Beachten Sie, dass der Leader in einem anderen Rechenzentrum als der aktuelle Leader gewählt worden sein könnte.

Upgrade-Leader

Führen Sie dieselben Schritte wie oben unter ZooKeeper auf den Observer- und Follower-Knoten aktualisieren beschrieben aus.

Nachdem auch der alte Leader-Knoten aktualisiert wurde, prüfen Sie den Clusterzustand und stellen Sie sicher, dass ein Leader-Knoten vorhanden ist.

Upgrade auf Cassandra 5.0.8

Apigee Edge for Private Cloud 4.54.00 enthält ein Upgrade von Cassandra auf Version 5.0.8.

Upgrades und Rollback

• Das Upgrade von Cassandra 4.0.X auf Cassandra 5.0.X ist ein fortlaufender Prozess.

• Ein direktes In-Place-Rollback von Cassandra 5.0.X auf 4.0.X ist nicht möglich. Das Rollback mithilfe von Replikaten oder Sicherungen ist ein komplexes Verfahren und kann zu Ausfallzeiten und/oder Datenverlust führen. Es ist besser, Probleme zu beheben und ein Upgrade auf Cassandra 5.0.X durchzuführen, als ein Rollback auszuführen.

• Es ist wichtig, sich mit den Rollback-Verfahren vertraut zu machen, bevor Sie das Upgrade durchführen. Die Berücksichtigung der Nuancen des Rollbacks während des Upgrades ist entscheidend, um sicherzustellen, dass geeignete Rollback-Pfade verfügbar sind.

Einzelnes Rechenzentrum

Das Upgrade von Cassandra von 4.0.X auf 5.0.X innerhalb eines einzelnen Rechenzentrums ist nahtlos. Das Rollback ist jedoch komplex und kann zu Ausfallzeiten und Datenverlust führen. Für Produktionsarbeitslasten wird dringend empfohlen, vor dem Upgrade ein neues Rechenzentrum hinzuzufügen, in dem mindestens Cassandra-Knoten verfügbar sind. So können Sie Cassandra zurücksetzen, ohne dass Daten verloren gehen oder der API-Traffic unterbrochen wird. Dieses zusätzliche Rechenzentrum kann nach Abschluss des Upgrades außer Betrieb genommen werden.

Wenn das Hinzufügen eines neuen Rechenzentrums nicht möglich ist, aber dennoch ein Rollback gewünscht wird, sind Sicherungen erforderlich, um Cassandra 4.0.X wiederherzustellen. Diese Methode ist jedoch wahrscheinlich mit Ausfallzeiten und Datenverlust verbunden.

Mehrere Rechenzentren

Der Betrieb mehrerer Rechenzentren mit Edge for Private Cloud 4.53.00 (oder) 4.53.01 bietet mehr Flexibilität für Rollbacks während des Upgrades auf Edge for Private Cloud 4.54.00.

• Für Rollbacks ist mindestens ein Rechenzentrum erforderlich, in dem die frühere Cassandra-Version (4.0.X) ausgeführt wird.

Empfohlene Upgrademethode

1. Ein Cassandra-Rechenzentrum nach dem anderen aktualisieren: Beginnen Sie damit, Cassandra-Knoten einzeln in einem einzelnen Rechenzentrum zu aktualisieren. Führen Sie Upgrades für alle Cassandra-Knoten in einem Rechenzentrum durch, bevor Sie mit dem nächsten fortfahren.

2. Pausieren und validieren: Pausieren Sie nach dem Upgrade eines Rechenzentrums, um sicherzustellen, dass Ihr Private Cloud-Cluster, insbesondere das aktualisierte Rechenzentrum, ordnungsgemäß funktioniert.

3. Hinweis: Sie können nur dann ein Rollback auf die vorherige Cassandra-Version durchführen, wenn mindestens ein Rechenzentrum noch die ältere Version ausführt.

4. Zeitkritisch: Sie können die Migration für kurze Zeit pausieren (empfohlen werden einige Stunden), um die Funktionalität zu prüfen. Sie können jedoch nicht unbegrenzt in einem Zustand mit gemischten Versionen bleiben. Dies liegt daran, dass ein nicht einheitlicher Cassandra-Cluster (mit Knoten in verschiedenen Versionen) betriebliche Einschränkungen hat.

5. Gründliche Tests: Apigee empfiehlt dringend, die Leistung und Funktionalität umfassend zu testen, bevor Sie das nächste Rechenzentrum aktualisieren. Sobald alle Rechenzentren aktualisiert wurden, ist ein Rollback auf die frühere Version nicht mehr möglich.

Rollback-Prüfpunktprozess

Einzelner Rollback-Checkpoint:Wenn alle Komponenten auf Version 4.54.00 aktualisiert wurden, ist ein Cassandra-Rollback nur möglich, wenn in mindestens einem Cassandra-Rechenzentrum weiterhin die ältere Version ausgeführt wird. Sobald das letzte Cassandra-Rechenzentrum aktualisiert wurde, ist das Upgrade auf Edge for Private Cloud 4.54.00 abgeschlossen und ein Rollback ist nicht mehr möglich.

Beispiel

Betrachten Sie einen Cluster mit zwei Rechenzentren:

1. Ausgangszustand:Cassandra-Knoten in beiden Rechenzentren haben Version 4.0.X. Alle anderen Knoten haben die Edge for Private Cloud-Version 4.54.00. Angenommen, es gibt drei Cassandra-Knoten pro DC.

2. Upgrade von DC-1: Führen Sie ein Upgrade der drei Cassandra-Knoten in DC-1 nacheinander durch.

3. Pausieren und validieren: Pausieren Sie, um zu prüfen, ob der Cluster, insbesondere DC-1, ordnungsgemäß funktioniert (Leistung und Funktionalität prüfen). Sie können mit den Cassandra-Knoten in DC-2 ein Rollback auf den ursprünglichen Zustand durchführen. Denken Sie daran, dass diese Pause aufgrund der Einschränkungen eines Cassandra-Clusters mit gemischten Versionen nur vorübergehend sein darf.

4. DC-2 aktualisieren: Aktualisieren Sie die verbleibenden drei Cassandra-Knoten in DC-2. Sobald alle Cassandra-Knoten in DC-2 erfolgreich aktualisiert wurden, ist das Upgrade auf Edge for Private Cloud 4.54.00 abgeschlossen.

Voraussetzungen für das Cassandra-Upgrade

Sie sollten Cassandra 4.0.X mit Edge for Private Cloud 4.53.00 oder 4.53.01 ausführen und Folgendes sicherstellen:

1. Java 17 als Standard-Java-Version auf dem Server festlegen: In Cassandra 5.0.X wird die Unterstützung für Java 8 entfernt. Sie können Cassandra 5.0.X oder das nodetool-Dienstprogramm nicht mit Java 8 ausführen. Achten Sie darauf, dass Java 17 auf jedem Cassandra-Knoten installiert ist, und legen Sie Java 17 als Standard-Java-Version fest, bevor Sie die Cassandra-Upgradeschritte ausführen, damit nodetool-Befehle mit Java 17 ausgeführt werden:

   alternatives --set java JAVA_17_PATH/bin/java

   Prüfen Sie, ob die aktive Standard-Java-Version Java 17 ist:

   java -version

2. Der gesamte Cluster ist betriebsbereit und mit Cassandra 4.0.X voll funktionsfähig.

3. Die Komprimierungsstrategie ist auf LeveledCompactionStrategy festgelegt (eine Voraussetzung für das Upgrade auf Version 4.53.00 oder 4.53.01).

4. Prüfen Sie, ob jeder der folgenden Schritte im Rahmen des ursprünglichen Upgrades von Cassandra 4.0.X in Edge for Private Cloud 4.53.00 oder 4.53.01 ausgeführt wurde.

   • Der Befehl post_upgrade wurde während des vorherigen Upgrades auf jedem Cassandra-Knoten ausgeführt.

   • Der Befehl drop_old_tables wurde während des vorherigen Upgrades auf dem gesamten Cassandra-Cluster ausgeführt.

Wenn Sie nicht sicher sind, ob die Befehle post_upgrade und drop_old_tables in Cassandra 4.0.X ausgeführt wurden, während Sie Edge for Private Cloud 4.53.00 oder 4.53.01 verwendet haben, können Sie sie bedenkenlos noch einmal ausführen, bevor Sie das Upgrade auf 4.54.00 versuchen.

Schritt 1: Auf Upgrade vorbereiten

Die folgenden Schritte sind zusätzlich zu den Standarddateien erforderlich, die Sie normalerweise erstellen, z. B. die Standardkonfigurationsdatei von Apigee zum Aktivieren von Komponentenupgrades.

1. Cassandra mit Apigee sichern.

2. Erstellen Sie VM-Snapshots von Cassandra-Knoten (falls möglich).

3. Prüfen Sie, ob der Port 9042 von allen Edge for Private Cloud-Komponenten, einschließlich Management Server, Message Processor, Router, Qpid und Postgres, auf Cassandra-Knoten zugreifen kann, falls dies noch nicht konfiguriert ist. Weitere Informationen finden Sie unter Portanforderungen.

Schritt 2: Alle Cassandra-Knoten aktualisieren

Alle Cassandra-Knoten sollten in jedem Rechenzentrum einzeln aktualisiert werden, jeweils ein Rechenzentrum nach dem anderen. Warten Sie zwischen Upgrades von Knoten in einem Rechenzentrum einige Minuten, bis ein aktualisierter Knoten vollständig gestartet und dem Cluster beigetreten ist, bevor Sie mit dem Upgrade eines anderen Knotens im selben Rechenzentrum fortfahren.

Warten Sie nach dem Upgrade aller Cassandra-Knoten in einem Rechenzentrum einige Zeit (30 Minuten bis einige Stunden), bevor Sie mit den Knoten im nächsten Rechenzentrum fortfahren. Prüfen Sie in dieser Zeit das aktualisierte Rechenzentrum gründlich und achten Sie darauf, dass die Funktions- und Leistungsmesswerte Ihres Apigee-Clusters intakt sind. Dieser Schritt ist entscheidend, um die Stabilität des Rechenzentrums zu gewährleisten, in dem Cassandra auf Version 5.0.X aktualisiert wurde, während die restlichen Apigee-Komponenten auf 4.54.00 aktualisiert wurden.

1. Führen Sie den folgenden Befehl aus, um ein Upgrade für einen Cassandra-Knoten durchzuführen:

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

2. Nachdem ein Knoten aktualisiert wurde, führen Sie den folgenden Befehl auf dem Knoten aus, um einige Validierungen durchzuführen, bevor Sie fortfahren:

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

3. Die Ausgabe sieht in etwa so aus:

   Cassandra version is verified - [cqlsh 6.2.0 | Cassandra 5.0.8 | CQL spec 3.4.7 | Native protocol v5]
   Metadata is verified

4. Führen Sie den folgenden post_upgrade-Befehl auf dem Cassandra-Knoten aus:

   /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade

5. Führen Sie den folgenden cleanup_old_index-Befehl auf dem Cassandra-Knoten aus:

   /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra cleanup_old_index

6. Führen Sie die folgenden nodetool-Befehle aus, um die Indexe auf dem Cassandra-Knoten neu zu erstellen:

/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms api_products api_products_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_api_products_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_end_user app_end_user_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_family_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_type_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms maps maps_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_company_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_developer_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_active_rev
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_index_template
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_method_template
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_latest_rev
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_active
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_latest
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rel_ver
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_res_path
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_res_path
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_entity
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template_auth au_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index dek keys usecase_index
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_operation_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_requesturi_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_responsecode_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_timestamp_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_user_idx    
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index cache cache_entries cache_entries_cache_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_consumer_key_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_consumer_key_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_request_token_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_client_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_refresh_token_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_client_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_organization_name_idx

Wenn Sie die Monetarisierung verwenden, führen Sie auch die folgenden Befehle zum Neuerstellen von Indexen für Monetarisierungs-Keyspaces aus:

/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_created_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_updated_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_created_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_currency_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_dev_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_limit_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_prod_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_reason_code_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_sub_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_company_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_created_at_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_developer_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_lastmodified_at_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_env_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_job_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_class_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_group_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus org_triggers org_triggers_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_group_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_suite_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_to_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_org_id_idx

Mit Apigee mTLS aktualisieren

So aktualisieren Sie Apigee mTLS:

• Apigee mTLS deinstallieren

• Apigee mTLS neu installieren

Aktualisierung rückgängig machen

Wenn die Aktualisierung fehlschlägt, können Sie versuchen, das Problem zu beheben, und dann update.sh noch einmal ausführen. Sie können das Update mehrmals ausführen. Es wird dann jeweils an der Stelle fortgesetzt, an der es zuletzt unterbrochen wurde.

Wenn Sie das Update auf die vorherige Version zurücksetzen müssen, finden Sie eine detaillierte Anleitung unter Rollback auf Version 4.54.00.

Informationen zum Aktualisieren des Loggings

Standardmäßig schreibt das Dienstprogramm update.sh Loginformationen in:

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

Wenn die Person, die das update.sh-Dienstprogramm ausführt, keinen Zugriff auf dieses Verzeichnis hat, wird das Log als Datei mit dem Namen update_username.log in das Verzeichnis /tmp geschrieben.

Wenn die Person keinen Zugriff auf /tmp hat, schlägt das update.sh-Tool fehl.

Aktualisierung ohne Ausfallzeiten

Mit einem Update ohne Ausfallzeiten oder Rolling Update können Sie Ihre Edge-Installation aktualisieren, ohne Edge herunterzufahren.

Ein Update ohne Ausfallzeit ist nur mit einer Konfiguration mit mindestens fünf Knoten möglich.

Der Schlüssel zu einem Upgrade ohne Ausfallzeiten besteht darin, jeden Router einzeln aus dem Load Balancer zu entfernen. Aktualisieren Sie dann den Router und alle anderen Komponenten auf demselben Computer wie der Router und fügen Sie den Router dann wieder dem Load Balancer hinzu.

1. Aktualisieren Sie die Maschinen in der richtigen Reihenfolge für Ihre Installation, wie unter Reihenfolge der Maschinenaktualisierung beschrieben .

2. Wenn es an der Zeit ist, die Router zu aktualisieren, wählen Sie einen beliebigen Router aus und machen Sie ihn unerreichbar, wie unter Erreichbarkeit des Servers (Message Processor/Router) aktivieren/deaktivieren beschrieben .

3. Aktualisieren Sie den ausgewählten Router und alle anderen Edge-Komponenten auf derselben Maschine wie den Router. In allen Edge-Konfigurationen werden ein Router und ein Message Processor auf demselben Knoten angezeigt.

4. Sorgen Sie dafür, dass der Router wieder erreichbar ist.

5. Wiederhole die Schritte 2 bis 4 für die verbleibenden Router.

6. Setzen Sie das Update für alle verbleibenden Computer in Ihrer Installation fort.

Beachten Sie Folgendes vor und nach dem Update:

• Auf einem kombinierten Router- und Message Processor-Knoten:

  • Führen Sie vor dem Update die folgenden Schritte aus:

    1. Router nicht erreichbar machen

    2. Message Processor nicht erreichbar machen.

  • Nach der Aktualisierung:

    1. Message Processor erreichbar machen

    2. Router erreichbar machen

• Auf einzelnen Router-Knoten:

  • Trennen Sie den Router vom Stromnetz, bevor Sie ihn aktualisieren.

  • Machen Sie den Router nach der Aktualisierung erreichbar.

• Auf einzelnen Message Processor-Knoten:

  • Machen Sie den Message Processor vor dem Update nicht erreichbar.

  • Sorgen Sie nach dem Update dafür, dass der Message Processor erreichbar ist.

Konfigurationsdatei für die unbeaufsichtigte Installation verwenden

Sie müssen eine Konfigurationsdatei für die unbeaufsichtigte Installation an den Aktualisierungsbefehl übergeben. Die Konfigurationsdatei für die automatische Installation ähnelt größtenteils der Datei, die Sie für die Installation von Edge for Private Cloud 4.53.00 oder 4.53.01 verwendet haben. Möglicherweise müssen Sie jedoch Änderungen für Komponenten wie die Benutzeroberfläche und SSO vornehmen, wie unter Upgrade auf die neue Edge-Benutzeroberfläche und Apigee-SSO (falls installiert) beschrieben.

Auf Version 4.54.00 auf einem Knoten mit externer Internetverbindung aktualisieren

Gehen Sie so vor, um die Edge-Komponenten auf einem Knoten zu aktualisieren:

1. Deaktivieren Sie alle cron-Jobs, die für die Ausführung eines Reparaturvorgangs für Cassandra konfiguriert sind, bis das Update abgeschlossen ist.

2. Melden Sie sich als Root bei Ihrem Knoten an, um die Edge-RPMs zu installieren.

   Hinweis: Für die RPM-Installation ist zwar Root-Zugriff erforderlich, die Edge-Konfiguration kann jedoch ohne Root-Zugriff erfolgen.

3. Deaktivieren Sie SELinux, wie unter Das Edge-Einrichtungsprogramm „apigee-setup“ installieren beschrieben .

4. Wenn Sie die Installation auf AWS durchführen , führen Sie die folgenden yum-configure-manager-Befehle aus:

   yum update rh-amazon-rhui-client.noarch
   yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

5. Wenn Sie derzeit Edge for Private Cloud 4.53.00 oder 4.53.01 verwenden:

   1. Laden Sie die Edge-bootstrap_4.54.00.sh-Datei in /tmp/bootstrap_4.54.00.sh herunter :

      curl https://software.apigee.com/bootstrap_4.54.00.sh -o /tmp/bootstrap_4.54.00.sh

   2. Installieren Sie das Dienstprogramm apigee-service für Edge 4.54.00 und die Abhängigkeiten mit dem folgenden Befehl:

      bash /tmp/bootstrap_4.54.00.sh apigeeuser=uName apigeepassword=pWord

      Dabei sind uName:pWord der Nutzername und das Passwort, die Sie von Apigee erhalten haben. Wenn Sie pWord weglassen, werden Sie aufgefordert, es einzugeben.

      Standardmäßig prüft das Installationsprogramm, ob Java 17 und 21 installiert sind.

   3. Verwenden Sie apigee-service, um das Dienstprogramm apigee-setup zu aktualisieren, wie im folgenden Beispiel gezeigt:

      /opt/apigee/apigee-service/bin/apigee-service apigee-setup update

   4. Aktualisieren Sie das Dienstprogramm apigee-validate auf dem Management Server, wie im folgenden Beispiel gezeigt:

      /opt/apigee/apigee-service/bin/apigee-service apigee-validate update

   5. Aktualisieren Sie das Dienstprogramm apigee-provision auf dem Management Server, wie im folgenden Beispiel gezeigt:

      /opt/apigee/apigee-service/bin/apigee-service apigee-provision update

   6. Führen Sie das Dienstprogramm update auf Ihren Knoten mit dem folgenden Befehl aus:

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

      Gehen Sie dabei in der unter Reihenfolge der Maschinenaktualisierung beschriebenen Reihenfolge vor.

      Wobei:

      • component ist die Edge-Komponente, die aktualisiert werden soll. Zulässige Werte:

        • edge : Alle Edge-Komponenten außer der neuen Edge-Benutzeroberfläche: Management Server, Message Processor, Router, QPID Server, Postgres Server

        • ldap : OpenLDAP

        • ue : Neue Edge-Benutzeroberfläche

        • qpid : Apigee Qpid

        • ps : Apigee Postgresql

        • zk : ZooKeeper

        • cs : Cassandra

      • configFile ist dieselbe Konfigurationsdatei, die Sie bei der Installation von 4.53.00 (oder) 4.53.01 zum Definieren Ihrer Edge-Komponenten verwendet haben.

      Sie können update.sh für alle Komponenten ausführen, indem Sie component auf „all“ setzen. Dies ist jedoch nur möglich, wenn Sie ein Edge-All-in-One-Installationsprofil (AIO) haben. Beispiel:

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

   7. Starten Sie die Komponenten der New Edge-Benutzeroberfläche auf allen Knoten neu, auf denen sie ausgeführt werden, falls Sie dies noch nicht getan haben:

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

   8. Testen Sie das Update, indem Sie das Dienstprogramm apigee-validate auf dem Verwaltungsserver ausführen, wie unter Installation testen beschrieben.

Wenn Sie das Update später zurücksetzen möchten, folgen Sie der Anleitung unter Version 4.54.00 zurücksetzen.

Update auf 4.54.00 aus einem lokalen Repository

Wenn sich Ihre Edge-Knoten hinter einer Firewall befinden oder auf andere Weise nicht über das Internet auf das Apigee-Repository zugreifen können, können Sie das Update über ein lokales Repository oder einen Spiegel des Apigee-Repositorys ausführen.

Nachdem Sie ein lokales Edge-Repository erstellt haben, haben Sie zwei Möglichkeiten, Edge über das lokale Repository zu aktualisieren:

• Erstellen Sie eine TAR-Datei des Repositorys, kopieren Sie die TAR-Datei auf einen Knoten und aktualisieren Sie dann Edge aus der TAR-Datei.

• Installieren Sie einen Webserver auf dem Knoten mit dem lokalen Repository, damit andere Knoten darauf zugreifen können. Apigee stellt den Nginx-Webserver zur Verfügung. Sie können aber auch Ihren eigenen Webserver verwenden.

So aktualisieren Sie von einem lokalen 4.54.00-Repository:

1. Erstellen Sie ein lokales 4.54.00-Repository, wie unter Installieren des Edge-Dienstprogramms „apigee-setup“ im Abschnitt „Lokales Apigee-Repository erstellen“ beschrieben.

2. Installieren Sie apigee-service auf den Zielknoten mit einer der folgenden Methoden:

   • Option 1: apigee-service aus einer TAR-Datei installieren

     1. Verwenden Sie auf dem Knoten mit dem lokalen Repository den folgenden Befehl, um das lokale Repository in einer einzelnen TAR-Datei mit dem Namen /opt/apigee/data/apigee-mirror/apigee-4.54.00.tar.gz zu packen:

        /opt/apigee/apigee-service/bin/apigee-service apigee-mirror package

     2. Kopieren Sie die TAR-Datei auf den Knoten, auf dem Sie Edge aktualisieren möchten. Kopieren Sie sie beispielsweise in das Verzeichnis /tmp auf dem neuen Knoten.

     3. Entpacken Sie die Datei auf dem neuen Knoten in das Verzeichnis /tmp:

        tar -xzf apigee-4.54.00.tar.gz

        Mit diesem Befehl wird ein neues Verzeichnis mit dem Namen „repos“ in dem Verzeichnis erstellt, das die TAR-Datei enthält. Beispiel: /tmp/repos

     4. Installieren Sie das Edge-apigee-service-Dienstprogramm und die Abhängigkeiten aus /tmp/repos:

        bash /tmp/repos/bootstrap_4.54.00.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos

        Beachten Sie, dass Sie in diesem Befehl den Pfad zum Verzeichnis „repos“ angeben.

   • Option 2: apigee-service mit dem Nginx-Webserver installieren

     1. Konfigurieren Sie den Nginx-Webserver wie unter Edge-apigee-setup-Dienstprogramm installieren im Abschnitt „Über das Repository mit dem Nginx-Webserver installieren“ beschrieben.

     2. Laden Sie auf dem Remote-Knoten die Edge-Datei bootstrap_4.54.00.sh in /tmp/bootstrap_4.54.00.sh herunter:

        /usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.54.00.sh -o /tmp/bootstrap_4.54.00.sh

        Dabei sind uName:pWord der Nutzername und das Passwort, die Sie zuvor für das Repository festgelegt haben, und remoteRepo ist die IP-Adresse oder der DNS-Name des Repository-Knotens.

     3. Installieren Sie auf dem Remote-Knoten das Edge-Dienstprogramm apigee-service und die Abhängigkeiten:

        bash /tmp/bootstrap_4.54.00.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://

        Dabei sind uName:pWord der Nutzername und das Passwort für das Repository.

3. Verwenden Sie apigee-service, um das apigee-setup-Dienstprogramm zu aktualisieren, wie im folgenden Beispiel gezeigt:

   /opt/apigee/apigee-service/bin/apigee-service apigee-setup update

4. Aktualisieren Sie das Dienstprogramm apigee-validate auf dem Management Server, wie im folgenden Beispiel gezeigt:

   /opt/apigee/apigee-service/bin/apigee-service apigee-validate update

5. Aktualisieren Sie das Dienstprogramm apigee-provision auf dem Management Server, wie im folgenden Beispiel gezeigt:

   /opt/apigee/apigee-service/bin/apigee-service apigee-provision update

6. Führen Sie das Dienstprogramm update auf Ihren Knoten in der unter Reihenfolge der Maschinenaktualisierung beschriebenen Reihenfolge aus:

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

   Wobei:

   • component ist die zu aktualisierende Edge-Komponente. Zulässige Werte:

     • edge : Alle Edge-Komponenten außer der neuen Edge-Benutzeroberfläche: Management Server, Message Processor, Router, QPID Server, Postgres Server

     • ldap : OpenLDAP

     • ue : Neue Edge-Benutzeroberfläche

     • qpid : Apigee Qpid

     • ps : Apigee Postgresql

     • zk : ZooKeeper

     • cs : Cassandra

   • configFile ist dieselbe Konfigurationsdatei, die Sie bei der Installation von 4.53.00 (oder) 4.53.01 zum Definieren Ihrer Edge-Komponenten verwendet haben.

     Hinweis: Die Konfigurationsdatei muss vom Nutzer „apigee“ gelesen werden können. Verwenden Sie den folgenden Befehl, um den Inhaber zu ändern:

     chown apigee:apigee configFile

   Sie können update.sh für alle Komponenten ausführen, indem Sie component auf „all“ setzen. Dies ist jedoch nur möglich, wenn Sie ein Edge-All-in-One-Installationsprofil (AIO) haben. Beispiel:

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

7. Starten Sie die UI-Komponenten auf allen Knoten, auf denen sie ausgeführt werden, neu, falls noch nicht geschehen:

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

8. Testen Sie das Update, indem Sie das apigee-validate-Dienstprogramm auf dem Verwaltungsserver ausführen, wie unter Installation testen beschrieben.

Wenn Sie das Update später zurücksetzen möchten, folgen Sie der Anleitung unter Version 4.54.00 zurücksetzen.

Reihenfolge der Maschinenaktualisierung

Die Reihenfolge, in der Sie die Maschinen in einer Edge-Installation aktualisieren, ist wichtig. Führen Sie ein Upgrade Ihrer Komponenten in der folgenden Reihenfolge durch.

1. Aktualisieren Sie alle Router- und Message Processor-Knoten in allen Rechenzentren mit der Option -c edge.

2. Aktualisieren Sie alle Management Server-Knoten in allen Rechenzentren mit der Option -c edge.

3. Führen Sie ein Upgrade aller LDAP-Knoten in allen Rechenzentren durch. Wenn Sie ein Upgrade von Edge for Private Cloud 4.53.00 durchführen, müssen Sie zusätzliche Schritte ausführen, um spezielle Schritte des LDAP-Upgrades auszuführen.

4. Aktualisieren Sie die Benutzeroberfläche und Apigee-SSO (falls installiert) in allen Rechenzentren:

   1. Wenn apigee-sso nicht installiert ist:Folgen Sie der Anleitung unter Option 1: Upgrade der Benutzeroberfläche (ohne Apigee SSO), um ein Upgrade auf die neue Edge-Benutzeroberfläche durchzuführen.

   2. Wenn apigee-sso installiert ist: Folgen Sie Option 2: Upgrade der Benutzeroberfläche (mit Apigee-SSO), um ein Upgrade auf die neue Edge-Benutzeroberfläche und Apigee-SSO durchzuführen.

5. Führen Sie für alle Qpid- und edge-qpid-Serverkomponenten in allen Rechenzentren ein Upgrade durch. Folgen Sie dazu der speziellen Qpid-Anleitung.

6. Aktualisieren Sie alle Postgresql- und edge-postgres-server-Komponenten in allen Rechenzentren gemäß den speziellen Postgres-Schritten.

7. Führen Sie ein Upgrade aller Zookeeper-Komponenten in allen Rechenzentren durch. Folgen Sie dazu der speziellen Anleitung für Zookeeper-Upgrades.

8. Führen Sie ein Upgrade aller Cassandra-Komponenten in allen Rechenzentren durch. Folgen Sie dazu den speziellen Schritten für das Cassandra-Upgrade.

9. Es gibt keinen separaten Schritt zum Aktualisieren der Monetarisierung. Er wird aktualisiert, wenn Sie die Option -c edge angeben.

Eigenständiges Upgrade mit einem Knoten

So aktualisieren Sie eine Standalone-Konfiguration mit einem Knoten auf Version 4.54.00:

Wenn Sie ein Upgrade von Edge for Private Cloud 4.53.00 durchführen, muss LDAP zuerst aktualisiert werden. Folgen Sie dazu der Anleitung für das Upgrade von 4.53.00 auf 4.54.00, bevor Sie mit dem Upgrade aller Komponenten beginnen.

1. Alle Komponenten aktualisieren:

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

2. Wenn Sie apigee-adminapi installiert haben, aktualisieren Sie das apigee-adminapi-Dienstprogramm:

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

Eigenständiges Upgrade mit zwei Knoten

Aktualisieren Sie die folgenden Komponenten für eine eigenständige Installation mit zwei Knoten:

Eine Liste der Edge-Topologien und Knotennummern finden Sie unter Installationstopologien.

1. Aktualisieren Sie die Edge-Komponenten auf Maschine 1:

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

2. LDAP auf Maschine 1 aktualisieren:

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

3. Aktualisieren Sie die New Edge-Benutzeroberfläche auf Maschine 1:

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

4. Aktualisieren Sie die Edge-Komponenten auf Maschine 2:

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

5. Aktualisieren Sie Qpid auf Maschine 2:

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

6. Aktualisieren Sie Postgres auf Maschine 2:

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

7. Aktualisieren Sie Cassandra und ZooKeeper auf Maschine 1:

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

8. Wenn Sie apigee-adminapi installiert haben, aktualisieren Sie das apigee-adminapi-Dienstprogramm auf Maschine 1:

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

Upgrade mit 5 Knoten

Aktualisieren Sie die folgenden Komponenten für eine Installation mit 5 Knoten:

Eine Liste der Edge-Topologien und Knotennummern finden Sie unter Installationstopologien.

1. Aktualisieren Sie die Edge-Komponenten auf Maschine 2, 3 und 1:

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

2. LDAP auf Maschine 1 aktualisieren:

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

3. Aktualisieren Sie die neue Edge-Benutzeroberfläche auf Computer 1:

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

4. Edge-Komponenten auf Maschine 4 und 5 aktualisieren:

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

5. Qpid auf Maschine 4 und 5 aktualisieren:

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

6. Aktualisieren Sie Postgres auf Maschine 4 und 5:

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

7. Aktualisieren Sie Cassandra und ZooKeeper auf den Maschinen 1, 2 und 3:

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

8. Wenn Sie apigee-adminapi installiert haben, aktualisieren Sie das apigee-adminapi-Dienstprogramm auf Maschine 1:

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

Upgrade mit 9 Knoten

Aktualisieren Sie die folgenden Komponenten für eine Clusterinstallation mit 9 Knoten:

Eine Liste der Edge-Topologien und Knotennummern finden Sie unter Installationstopologien.

1. Aktualisieren Sie die Edge-Komponenten auf den Computern 4, 5 und 1 (Router, Message Processor und Management Server) in dieser Reihenfolge:

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

2. Aktualisieren Sie LDAP auf Maschine 1:

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

3. Aktualisieren Sie die neue Edge-Benutzeroberfläche auf Maschine 1:

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

4. Aktualisieren Sie die Edge-Komponenten auf den Maschinen 6, 7, 8 und 9 in dieser Reihenfolge:

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

5. Qpid auf den Maschinen 6 und 7 aktualisieren:

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

6. Aktualisieren Sie Postgres auf Maschine 8:

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

7. Aktualisieren Sie Postgres auf Maschine 9:

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

8. Aktualisieren Sie Cassandra und ZooKeeper auf den Maschinen 1, 2 und 3:

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

9. Wenn Sie apigee-adminapi installiert haben, aktualisieren Sie das apigee-adminapi-Dienstprogramm auf Maschine 1:

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

Cluster-Upgrade mit 13 Knoten

Aktualisieren Sie die folgenden Komponenten für eine Clusterinstallation mit 13 Knoten:

Eine Liste der Edge-Topologien und Knotennummern finden Sie unter Installationstopologien.

1. Aktualisieren Sie die Edge-Komponenten auf den Computern 10, 11, 6 und 7 in dieser Reihenfolge:

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

2. Aktualisieren Sie LDAP auf Maschine 4 und 5:

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

3. Aktualisieren Sie die neue Edge-Benutzeroberfläche auf den Computern 6 und 7:

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

4. Aktualisieren Sie die Edge-Komponenten auf den Computern 12, 13, 8 und 9 in dieser Reihenfolge:

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

5. Qpid auf den Maschinen 12 und 13 aktualisieren:

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

6. Postgres auf Maschine 8 aktualisieren:

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

7. Aktualisieren Sie Postgres auf Maschine 9:

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

8. Aktualisieren Sie Cassandra und ZooKeeper auf den Computern 1, 2 und 3:

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

9. (Wenn Sie apigee-adminapi installiert haben) Aktualisieren Sie das Dienstprogramm „apigee-adminapi“ auf den Computern 6 und 7:

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

Upgrade für Cluster mit 12 Knoten

Aktualisieren Sie die folgenden Komponenten für eine Installation mit 12 Knoten:

Eine Liste der Edge-Topologien und Knotennummern finden Sie unter Installationstopologien.

1. Edge-Komponenten (Router und Message Processor) aktualisieren:

   • Auf den Maschinen 2 und 3 in Rechenzentrum 1:

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

   • Auf den Maschinen 8 und 9 in Rechenzentrum 2:

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

2. Aktualisieren Sie die Edge-Komponenten (Management Server):

   • Auf Maschine 1 in Rechenzentrum 1:

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

   • Auf Maschine 7 in Rechenzentrum 2:

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

3. LDAP aktualisieren:

   • Maschine 1 in Rechenzentrum 1:

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

   • Maschine 7 in Rechenzentrum 2:

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

4. Komponenten der neuen Edge-Benutzeroberfläche aktualisieren:

   • Auf Maschine 1 in Rechenzentrum 1:

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

   • Auf Maschine 7 in Rechenzentrum 2:

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

5. Edge-Komponenten aktualisieren:

   • Maschinen 4, 5 und 6 in Rechenzentrum 1:

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

   • Maschinen 10, 11 und 12 in Rechenzentrum 2:

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

6. Aktualisieren Sie qpidd:

   • Maschinen 4 und 5 in Rechenzentrum 1:

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

   • Maschinen 10 und 11 in Rechenzentrum 2:

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

7. Postgres aktualisieren:

   • Maschine 6 in Rechenzentrum 1:

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

   • Maschine 12 in Rechenzentrum 2:

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

8. Aktualisieren Sie Cassandra und ZooKeeper:

   • Maschinen 1, 2 und 3 in Rechenzentrum 1:

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

   • Auf den Maschinen 7, 8 und 9 in Rechenzentrum 2:

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

9. Wenn Sie apigee-adminapi installiert haben, aktualisieren Sie das apigee-adminapi-Dienstprogramm:

   • Maschine 1 in Rechenzentrum 1:

     /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

   • Maschine 7 in Rechenzentrum 2:

     /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

Für eine nicht standardmäßige Konfiguration

Wenn Sie eine nicht standardmäßige Konfiguration haben, aktualisieren Sie die Edge-Komponenten in der folgenden Reihenfolge:

1. Router

2. Message Processor

3. Verwaltungsserver

4. LDAP

5. Benutzeroberfläche (entweder klassische oder neue Benutzeroberfläche)

6. SSO (falls zutreffend)

7. Qpid und edge-qpid-server

8. Postgres und edge-postgres-server

9. ZooKeeper

10. Cassandra

11. apigee-adminapi