Apigee Edge 4.52.02 oder 4.53.00 auf 4.53.01 aktualisieren

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

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

Wer kann das Update durchführen?

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

Nachdem Sie die Edge-RPMs installiert haben, kann jeder sie 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.

Voraussetzungen aktualisieren

In dieser Version wurden mehrere Sicherheitsprobleme behoben. Diese Sicherheitsverbesserungen sind zwar unerlässlich, führen aber zu einigen Änderungen, die nicht abwärtskompatibel sind. Das bedeutet, dass für das Upgrade zusätzliche Schritte erforderlich sind, um Unterbrechungen während oder nach dem Upgrade zu vermeiden. Weitere Informationen finden Sie in diesem Thema.

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

• Alle Knoten sichern
  Vor dem Update empfehlen wir, aus Sicherheitsgründen ein vollständiges Back-up aller Knoten durchzuführen. Verwenden Sie das Verfahren für Ihre aktuelle Version von Edge, um die Sicherung durchzuführen.

  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.

• Sicherstellen, dass Edge ausgeführt wird
  Achten Sie darauf, dass Edge während des Aktualisierungsvorgangs ausgeführt wird. Verwenden Sie dazu den folgenden Befehl:

  /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.52.02 durchgeführt haben und jetzt ein Upgrade auf Version 4.53.01 planen, müssen Sie die erforderlichen Schritte nach dem Upgrade für Cassandra ausführen. Diese Schritte sind in der Dokumentation zum Upgrade auf Version 4.52.02 beschrieben und werden auch unter Voraussetzungen für das Cassandra-Upgrade erwähnt. Wenn Sie sich nicht sicher sind, ob diese Schritte während des vorherigen Upgrades ausgeführt wurden, führen Sie sie noch einmal aus, bevor Sie mit dem Upgrade auf Version 4.53.01 fortfahren.

• IDP-Schlüssel und ‑Zertifikate in Edge for Private Cloud 4.53.01 konfigurieren
  

  In Edge for Private Cloud 4.53.01 werden IDP-Schlüssel und -Zertifikate, die in der apigee-sso-Komponente verwendet werden, jetzt über einen Keystore konfiguriert. Sie müssen den zuvor verwendeten Schlüssel und das Zertifikat in einen Keystore exportieren. Folgen Sie der Anleitung im Abschnitt Schritte zum Aktualisieren von Apigee SSO von älteren Versionen, bevor Sie die SSO-Komponente aktualisieren.

• Python-Anforderungen
  Achten Sie darauf, dass auf allen Knoten, einschließlich Cassandra-Knoten, Python 3 installiert ist, bevor Sie das Upgrade versuchen.

Besondere Schritte, die bei der Umstellung zu beachten sind

Wenn Sie ein Upgrade auf Edge for Private Cloud 4.53.01 durchführen möchten, müssen Sie möglicherweise bestimmte Software aktualisieren. Die erforderlichen Schritte hängen von Ihrer aktuellen Version ab. In der folgenden Tabelle finden Sie die verschiedenen Softwareprodukte, für die zusätzliche Schritte erforderlich sind. Folgen Sie der detaillierten Anleitung für jedes Produkt. Kehren Sie nach Abschluss der erforderlichen Aufgaben zum Hauptverfahren für das Upgrade zurück, um das Upgrade fortzusetzen.

Kehren Sie nach Ausführung der erforderlichen Schritte für Ihre Version zum Hauptverfahren für das Upgrade zurück, um fortzufahren.

Automatische Übertragung von Property-Einstellungen

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

Erforderliches Upgrade auf OpenLDAP 2.6

Hier finden Sie eine detaillierte Anleitung für das Upgrade des zugrunde liegenden LDAP-Dienstes von Apigee Edge for Private Cloud von OpenLDAP 2.4 auf OpenLDAP 2.6. Dieses Upgrade ist eine obligatorische Voraussetzung für das Update auf Apigee Edge for Private Cloud-Version 4.53.01 und höher. Dieses Upgrade gilt für alle Apigee LDAP-Bereitstellungstopologien: Einzelserver, Aktiv/Passiv und Aktiv/Aktiv (Multi-Master).

Voraussetzungen und wichtige Aspekte

• Während des LDAP-Upgrades sind Verwaltungs-APIs und damit auch die Apigee-Benutzeroberfläche in allen Regionen nicht verfügbar. Alle Verwaltungsaufgaben, z. B. das Verwalten von Nutzern, Rollen, Apps und Organisationen, schlagen fehl und sollten pausiert werden. Die Verarbeitung Ihres API-Proxy-Traffics ist davon nicht betroffen. Fahren Sie alle Edge-Verwaltungsserver und die Edge-UI herunter, bevor Sie mit dem LDAP-Upgrade fortfahren.

• Sicherung ist entscheidend:Eine vollständige und validierte Sicherung Ihrer vorhandenen LDAP-Daten ist unerlässlich. Wenn Sie ohne gültige Sicherung fortfahren, kann dies zu einem unwiderruflichen Datenverlust führen. Die Sicherung muss gestartet werden, während der LDAP-Dienst noch ausgeführt wird, um einen konsistenten Snapshot der LDAP-Daten zu einem bestimmten Zeitpunkt zu erfassen. Eine Sicherung ist für das eigentliche Upgrade erforderlich. Ohne Sicherung können Sie das Upgrade weder ausführen noch ein Rollback durchführen, da bei den Upgradeschritten LDAP-Daten gelöscht werden.

Vorbereitung und Installation (alle LDAP-Server)

Die Schritte in diesem Abschnitt (Schritt 2 bis Schritt 5) sind für alle LDAP-Bereitstellungstopologien identisch. Diese Aktionen müssen auf jedem Server ausgeführt werden, auf dem die apigee-openldap-Komponente installiert ist, unabhängig von ihrer Rolle.

1. Schalten Sie alle edge-management-server und edge-ui aus, bevor Sie mit dem LDAP-Upgrade fortfahren.

   apigee-service edge-management-server stop
   apigee-service edge-ui stop

2. Vorhandene LDAP-Daten sichern

   Bevor Sie Änderungen vornehmen, erstellen Sie eine vollständige Sicherung der aktuellen LDAP-Daten von allen LDAP-Servern. Dadurch wird ein sicherer Wiederherstellungspunkt erstellt.

   • Führen Sie den Sicherungsbefehl aus. Dadurch wird ein Sicherungsarchiv mit Zeitstempel im Verzeichnis /opt/apigee/backup/openldap erstellt.

     apigee-service apigee-openldap backup

   • Gesamtzahl der Datensätze abrufen:Erfassen Sie die Anzahl der Datensätze in Ihrem Verzeichnis für die Validierung nach dem Upgrade. Die Anzahl der Datensätze sollte auf allen LDAP-Servern übereinstimmen. Dies ist eine Plausibilitätsprüfung.

     # Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
     ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \
     -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l

3. LDAP beenden und Datenverzeichnisse bereinigen

   Dieser Schritt muss auf allen LDAP-Servern ausgeführt werden. Dies ist aufgrund der Änderung der Hauptversion und der zugrunde liegenden strukturellen Unterschiede erforderlich. Ein sauberes Verzeichnis sorgt dafür, dass es keine Konflikte gibt. Wenn alle LDAP-Server beendet sind, kommt es zu Störungen bei den Management-APIs und der Benutzeroberfläche.

   • Beenden Sie den LDAP-Dienst.

     apigee-service apigee-openldap stop

   • Entfernen Sie die alten LDAP-Daten- und Konfigurationsverzeichnisse endgültig.

     rm -rf /opt/apigee/data/apigee-openldap/*

4. Neue LDAP-Version installieren und konfigurieren

   Verwenden Sie auf allen LDAP-Servern die Standard-Apigee-Skripts, um die neue Komponentenversion herunterzuladen und zu installieren.

   • Neue LDAP-Komponente installieren:Das Aktualisierungsskript liest Ihre Konfigurationsdatei und installiert das neue apigee-openldap-Paket.

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

   • Neue LDAP-Version validieren:Laden Sie das Profil nach Abschluss der Installation neu und prüfen Sie, ob die neue LDAP-Version korrekt installiert wurde.

     source ~/.bash_profile
     ldapsearch -VV
     Expected output:
     ldapsearch: @(#) $OpenLDAP: ldapsearch 2.6.7

5. LDAP auf allen Servern vor der Datenwiederherstellung beenden

   Dies ist ein wichtiger Synchronisierungsschritt. Bevor Sie die Sicherung wiederherstellen, muss der neu installierte LDAP-Dienst auf allen Servern beendet werden. Führen Sie auf jedem LDAP-Server die folgenden Befehle aus:

   apigee-service apigee-openldap stop
   rm -rf /opt/apigee/data/apigee-openldap/ldap/*

6. LDAP-Daten wiederherstellen

   Die Strategie besteht darin, die Sicherung auf dem ersten aktiven Server wiederherzustellen. Dieser Server fungiert dann als „Source of Truth“ und repliziert die Daten in einer Multi-Server-Einrichtung auf seine Peers.

   1. Ersten aktiven Server für die Wiederherstellung ermitteln

      • Bei Einrichtung mit einem einzelnen Server:Dies ist Ihr einziger LDAP-Server. Sie können direkt mit dem nächsten Schritt fortfahren.
      • Für Active-Passive- und Active-Active-Einrichtungen:Führen Sie den folgenden Diagnosebefehl auf jedem LDAP-Server aus:

        grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*\ldif
        Note:
        -If this command returns output, the server is a passive server.
        -If it returns no output, the server is the active server.

   2. Sicherungsdaten wiederherstellen

      Prüfen Sie noch einmal, ob Schritt 5 auf allen LDAP-Servern erfolgreich abgeschlossen wurde, bevor Sie fortfahren.

      • Rufen Sie auf dem ersten aktiven Server, den Sie oben identifiziert haben, das Sicherungsverzeichnis auf.

        cd /opt/apigee/backup/openldap

      • Führen Sie den Befehl restore aus. Es wird dringend empfohlen, den genauen Sicherungszeitstempel aus Schritt 2 anzugeben, um zu verhindern, dass eine unbeabsichtigte oder ältere Version wiederhergestellt wird.

        # To restore a specific backup (recommended):
        apigee-service apigee-openldap restore 2025.08.11,23.34.00
        
        # To restore the latest available backup by default:
        apigee-service apigee-openldap restore

      • Starten Sie nach Abschluss der Wiederherstellung den LDAP-Dienst auf dem ersten aktiven Server.

        apigee-service apigee-openldap start

7. Verbleibende LDAP-Server starten

   Wenn Sie mehrere Server haben, starten Sie den Dienst auf jedem der LDAP-Server:

   apigee-service apigee-openldap start

8. Endgültige Validierung

   Im letzten Schritt wird geprüft, ob das Upgrade erfolgreich war und die Daten im gesamten LDAP-Cluster konsistent sind.

   • Führen Sie den Validierungsbefehl auf allen LDAP-Servern aus. Die Anzahl der Datensätze sollte auf allen Servern identisch sein und mit der Anzahl übereinstimmen, die Sie in Schritt 2 erfasst haben.

   # Note: Replace 'YOUR_PASSWORD' with your LDAP manager password.
   ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \
   -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l

   • Wenn Sie bestätigt haben, dass die Daten korrekt und konsistent sind, ist das LDAP-Upgrade abgeschlossen. Sie können jetzt den edge-management-server, die Edge-UI und alle anderen abhängigen Komponenten gemäß dem Standard-Upgradeverfahren Ihrer Organisation starten.

Erforderliches Upgrade auf Cassandra 4.0.18

Apigee Edge for Private Cloud 4.53.01 enthält ein Upgrade von Cassandra auf Version 4.0.18.

Upgrades und Rollback

• Das Upgrade von Cassandra 3.11.X auf Cassandra 4.0.X ist ein reibungsloser Prozess. Cassandra 4.0.X, das mit Edge for Private Cloud 4.53.00 veröffentlicht wurde, ist mit den Laufzeit- und Verwaltungskomponenten von Private Cloud 4.52.02 kompatibel.
• Ein direktes In-Place-Rollback von Cassandra 4.0.X auf 3.11.X ist nicht möglich. Das Zurücksetzen mithilfe von Replikaten oder Sicherungen ist ein komplexes Verfahren, das zu Ausfallzeiten und/oder Datenverlust führen kann. Es ist besser, Probleme zu beheben und auf Cassandra 4.0.X zu aktualisieren, als ein Rollback durchzuführen.
• Es ist wichtig, dass Sie sich mit den Rollback-Verfahren vertraut machen, bevor Sie das Upgrade durchführen. Die Nuancen des Rollbacks während des Upgrades sind entscheidend, um sicherzustellen, dass geeignete Rollback-Pfade verfügbar sind.

Einzelnes Rechenzentrum

Das Upgrade von Cassandra von 3.11.X auf 4.0.X innerhalb eines einzelnen Rechenzentrums erfolgt nahtlos. Das Rollback ist jedoch komplex und kann zu Ausfallzeiten und Datenverlust führen. Für Produktionsarbeitslasten wird dringend empfohlen, ein neues Rechenzentrum hinzuzufügen, in dem mindestens Cassandra-Knoten verfügbar sind, bevor Sie das Upgrade starten. Dadurch kann Cassandra zurückgesetzt werden, ohne dass Daten verloren gehen oder Ihr API-Traffic unterbrochen wird. Dieses zusätzliche Rechenzentrum kann außer Betrieb genommen werden, sobald das Upgrade abgeschlossen oder Prüfpunkt 2 erreicht ist.

Wenn das Hinzufügen eines neuen Rechenzentrums nicht möglich ist, aber die Möglichkeit zum Rollback weiterhin gewünscht wird, sind Sicherungen für die Wiederherstellung von Cassandra 3.11.X erforderlich. Diese Methode führt jedoch wahrscheinlich sowohl zu Ausfallzeiten als auch zu Datenverlust.

Mehrere Rechenzentren

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

• Rollbacks sind nur möglich, wenn in mindestens einem Rechenzentrum die ältere Cassandra-Version (3.11.X) ausgeführt wird.
• Wenn Ihr gesamter Cassandra-Cluster auf 4.0.X aktualisiert wurde, dürfen Sie kein Rollback auf Cassandra 3.11.X durchführen. Sie müssen die neuere Cassandra-Version weiterhin mit den anderen Komponenten von Private Cloud 4.53.00 oder 4.52.02 verwenden.

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 aller Cassandra-Knoten in einem Rechenzentrum durch, bevor Sie mit dem nächsten fortfahren.
2. Pausieren und validieren:Nachdem Sie ein Rechenzentrum aktualisiert haben, pausieren Sie, um sicherzustellen, dass Ihr Private Cloud-Cluster, insbesondere das aktualisierte Rechenzentrum, ordnungsgemäß funktioniert.
3. Wichtig:Sie können nur dann ein Rollback auf die vorherige Cassandra-Version durchführen, wenn in mindestens einem Rechenzentrum noch die ältere Version ausgeführt wird.
4. Zeitkritisch:Sie können die Pause für einen kurzen Zeitraum (einige Stunden werden empfohlen) nutzen, um die Funktionalität zu prüfen. Sie können jedoch nicht auf unbestimmte Zeit in einem Zustand mit gemischten Versionen verbleiben. Das 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 gründlich 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 als Prozess mit zwei Prüfpunkten

1. Checkpoint 1:Der Ausgangszustand mit allen Komponenten in Version 4.52.02. Ein vollständiges Rollback ist möglich, solange mindestens ein Cassandra-Rechenzentrum mit der älteren Version vorhanden ist.
2. Checkpoint 2:Nachdem alle Cassandra-Knoten in allen Rechenzentren aktualisiert wurden. Sie können ein Rollback zu diesem Zustand durchführen, aber nicht zu Checkpoint 1.

Beispiel

Betrachten Sie einen Cluster mit zwei Rechenzentren:

1. Ausgangszustand:Cassandra-Knoten in beiden DCs haben Version 3.11.X. Alle anderen Knoten haben die Version 4.52.02 von Edge for Private Cloud. Angenommen, es gibt drei Cassandra-Knoten pro DC.
2. DC-1 aktualisieren:Aktualisieren Sie die drei Cassandra-Knoten in DC-1 einzeln.
3. Pausieren und validieren:Pausieren Sie, um sicherzustellen, dass der Cluster, insbesondere DC-1, ordnungsgemäß funktioniert (Leistung und Funktionalität prüfen). Sie können den ursprünglichen Zustand mit den Cassandra-Knoten in DC-2 wiederherstellen. Denken Sie daran, dass diese Pause aufgrund der Einschränkungen eines Cassandra-Clusters mit gemischten Versionen nur vorübergehend sein darf.
4. Upgrade von DC-2 durchführen:Führen Sie ein Upgrade der verbleibenden drei Cassandra-Knoten in DC-2 durch. Dies wird Ihr neuer Rollback-Checkpoint.
5. Andere Komponenten aktualisieren:Aktualisieren Sie Verwaltungs-, Laufzeit- und Analytikknoten wie gewohnt in allen Rechenzentren, jeweils einen Knoten und ein Rechenzentrum nach dem anderen. Wenn Probleme auftreten, können Sie ein Rollback auf den Zustand von Schritt 4 vornehmen.

Voraussetzungen für das Cassandra-Upgrade

1. Der gesamte Cluster ist betriebsbereit und mit Cassandra 3.11.16 voll funktionsfähig.
2. Die Kompaktierungsstrategie ist auf LeveledCompactionStrategy festgelegt (eine Voraussetzung für das Upgrade auf Version 4.52.02).

3. Prüfen Sie, ob jeder der folgenden Schritte im Rahmen des ursprünglichen Upgrades von Cassandra 3.11 in Edge for Private Cloud 4.52.02 abgeschlossen 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 für den gesamten Cassandra-Cluster ausgeführt.

Wenn Sie sich nicht sicher sind, ob die Befehle post_upgrade und drop_old_tables in Cassandra 3.11 ausgeführt wurden, als Sie Edge for Private Cloud 4.52.02 verwendet haben, können Sie sie vor dem Upgrade auf 4.53.01 noch einmal ausführen.

Schritt 1: Upgrade vorbereiten

Die folgenden Schritte ergänzen die Standarddateien, die Sie normalerweise erstellen, z. B. die Standardkonfigurationsdatei von Apigee zum Aktivieren von Komponentenupgrades.

1. Sichern Sie Cassandra mit Apigee.
2. Erstellen Sie VM-Snapshots von Cassandra-Knoten (falls möglich).
3. Achten Sie darauf, dass 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, damit 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 stellen Sie sicher, dass die Funktions- und Leistungsmesswerte Ihres Apigee-Clusters intakt sind. Dieser Schritt ist entscheidend für die Stabilität des Rechenzentrums, in dem Cassandra auf Version 4.0.X aktualisiert wurde, während die restlichen Apigee-Komponenten auf Version 4.52.02 verbleiben.

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.0.0 | Cassandra 4.0.18 | CQL spec 3.4.5 | 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 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 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
   /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 cache cache_entries cache_entries_cache_name_idx
   /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 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

   Wenn Sie Monetarisierung verwenden, führen Sie auch die folgenden Indexe neu erstellen-Befehle für die 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

Schritt 3: Alle Managementknoten aktualisieren

Führen Sie für alle Managementknoten in allen Regionen nacheinander ein Upgrade durch:

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

Schritt 4: Alle Runtime-Knoten aktualisieren

Führen Sie für alle Router- und Message Processor-Knoten in allen Regionen ein Upgrade durch:

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

Schritt 5: Alle verbleibenden Edge for Private Cloud 4.53.01-Komponenten aktualisieren

Führen Sie für alle verbleibenden edge-qpid-server- und edge-postgres-server-Knoten in allen Regionen ein Upgrade durch.

Erforderliches Upgrade auf Zookeeper 3.8.4

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

Bevor Sie Zookeeper aktualisieren, lesen Sie den Wartungsleitfaden für Zookeeper. 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 Leiter, Follower, Wähler und Beobachter. Die Voter-Knoten wählen einen Leader aus, danach werden sie selbst zu Followern.

Während des Updates 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. Laufzeit-APIs von Apigee sollten während des Upgrades von Zookeeper gemäß der folgenden Anleitung nicht beeinträchtigt werden (es sei denn, diese Laufzeit-APIs rufen Verwaltungs-APIs auf).

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

Sicherung erstellen

Sichern Sie alle Knoten von ZooKeeper für den Fall, dass ein Rollback erforderlich ist. Bei einem Rollback wird Zookeeper in den Zustand zurückversetzt, den es zum Zeitpunkt der Sicherung hatte. Hinweis:Alle Bereitstellungen oder Infrastrukturänderungen in Apigee seit der Sicherung (deren Informationen in Zookeeper gespeichert sind) gehen bei der Wiederherstellung verloren.

  /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 ‑Sicherungen für die Wiederherstellung oder das Rollback erstellen (falls erforderlich).

Führungskräfte, Follower und Beobachter identifizieren

Hinweis:In den folgenden Beispielbefehlen wird das nc-Dienstprogramm verwendet, um Daten an ZooKeeper zu senden. Sie können auch alternative Dienstprogramme verwenden, um Daten an ZooKeeper zu senden.

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

     sudo 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.4-5a02a05eddb59aee6ac762f7ea82e92a68eb9c0f, built on 2022-02-25 08:49 UTC
     Clients:
      /0:0:0:0:0:0:0:1:41246[0](queued=0,recved=1,sent=0)
     
     Latency min/avg/max: 0/0.2518/41
     Received: 647228
     Sent: 647339
     Connections: 4
     Outstanding: 0
     Zxid: 0x400018b15
     Mode: follower
     Node count: 100597

   In der Zeile Mode der Ausgabe für die Knoten sollte je nach Knotenkonfiguration „observer“, „leader“ oder „follower“ (ein Wähler, der nicht der Leader ist) angezeigt werden. Hinweis:Bei einer eigenständigen Installation von Edge mit einem einzelnen ZooKeeper-Knoten wird Mode auf „standalone“ gesetzt.

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

Zookeeper auf den Observer- 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.53.01 herunter und führen Sie ihn aus, wie unter Auf Version 4.53.01 auf einem Knoten mit externer Internetverbindung aktualisieren beschrieben. Das Verfahren hängt wahrscheinlich davon ab, ob der Knoten eine externe Internetverbindung hat oder ob Sie eine Offline-Installation durchführen.
2. Zookeeper-Komponente aktualisieren:

     /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 „cs,zk“). Sie können die anderen Komponenten aber auch später aktualisieren. Apigee empfiehlt, zuerst nur Zookeeper zu aktualisieren und sicherzustellen, dass Ihr Cluster ordnungsgemäß funktioniert, bevor Sie andere Komponenten aktualisieren.
3. Wiederholen Sie die obigen Schritte für jeden Zookeeper-Beobachter- und ‑Follower-Knoten.

Führungsperson entfernen

Wenn alle Observer- und Follower-Knoten aktualisiert wurden, fahren Sie den Leader herunter. Führen Sie auf dem Knoten, der als Leader identifiziert wurde, den folgenden Befehl aus:

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

Während dieses Ereignisses 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 Bereitstellung 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 obigen Abschnitt Leader, Follower und Beobachter identifizieren, ob ein neuer Leader aus den Followern ausgewählt wurde, nachdem der vorhandene Leader beendet wurde. Der Leader könnte in einem anderen Rechenzentrum als der aktuelle Leader gewählt worden sein.

Beste Variante bereitstellen

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

Sobald auch der alte Leaderknoten aktualisiert wurde, prüfen Sie den Clusterstatus und stellen Sie sicher, dass es einen Leaderknoten gibt.

Nginx 1.26-Upgrade im Edge-Router

Beim Upgrade auf Edge for Private Cloud 4.53.01 von früheren Versionen wird die Nginx-Software nicht automatisch auf die neueste Version (1.26.x) aktualisiert. So werden unbeabsichtigte Laufzeitnebenwirkungen aufgrund der Änderungen in Nginx 1.26 in Apigee Edge 4.53.01 verhindert. Sie können Nginx nach der Überprüfung in niedrigeren Umgebungen manuell von Version 1.20.x auf Version 1.26.x aktualisieren. So führen Sie das Upgrade manuell durch:

1. Prüfen, ob auf dem Edge-Router-Knoten die aktuelle Softwareversion 4.53.01 installiert ist

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

2. Prüfen und bestätigen Sie die Nginx-Version, die Sie derzeit verwenden.

   /opt/nginx/sbin/nginx -V

   Wenn Sie eine ältere Version von Nginx verwenden, können Sie Nginx auf dem Routerknoten mit den folgenden Schritten auf Version 1.26.X aktualisieren.

3. Edge-Router-Prozess auf dem Routerknoten beenden

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

4. Nginx-Software auf dem Routerknoten aktualisieren

   dnf update apigee-nginx

5. Prüfen, ob die Nginx-Version aktualisiert wurde

   /opt/nginx/sbin/nginx -V

6. Routerprozess auf dem Knoten starten

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

7. Wiederhole den Vorgang für jeden Routerknoten einzeln.

Erforderliches Upgrade auf Postgres 17

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

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

Die Art und Weise, wie Sie das Postgres-Update durchführen, hängt davon ab, wie Sie die Datenspeicherung für Ihre Postgres-Knoten konfiguriert haben:

• Wenn Sie die lokale Datenspeicherung 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-Standby-Knoten nach dem Rollback zum Master-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 einzelnen 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 ein neuer Postgres-Standby-Knoten installiert und später außer Betrieb genommen wird.

  Bevor Sie mit der Aktualisierung beginnen, erstellen Sie einen Netzwerk-Snapshot des von Postgres verwendeten Datenspeichers. Wenn dann während des Updates Fehler auftreten und Sie ein Rollback durchführen müssen, können Sie den Postgres-Knoten aus diesem Snapshot wiederherstellen.

Neuen Postgres-Standbyknoten installieren

Mit diesem Verfahren wird ein Postgres-Standby-Server auf einem neuen Knoten erstellt. Achten Sie darauf, dass Sie einen neuen Postgres-Standby-Server für Ihre vorhandene Edge-Version (4.52.02 oder 4.53.00) und nicht für Version 4.53.01 installieren.

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

So erstellen Sie einen neuen Postgres-Standby-Knoten:

1. Bearbeiten Sie auf dem aktuellen Postgres-Master die Datei /opt/apigee/customer/application/postgresql.properties, um das folgende Token festzulegen. Wenn diese 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 Postgres-Master 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 Master ansehen. In dieser Datei sollten die folgenden Zeilen angezeigt werden:

   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 zum Installieren Ihrer aktuellen Version von Edge verwendet haben, um Folgendes anzugeben:

      # IP address of the current master:
      PG_MASTER=192.168.56.103
      # IP address of the new standby node
      PG_STANDBY=192.168.56.102

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

   3. Wenn Sie derzeit Edge 4.52.02 verwenden:

      1. Laden Sie die Datei „bootstrap_4.52.02.sh“ für Edge in das Verzeichnis /tmp/bootstrap_4.52.02.sh herunter:

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

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

         sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

      Wenn Sie derzeit Edge 4.53.00 verwenden:

      1. Laden Sie die Datei „bootstrap_4.53.00.sh“ für Edge 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

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

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

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

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

   5. Installieren Sie Postgres:

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

   6. Führen Sie auf dem neuen Standby-Knoten den folgenden Befehl aus:

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

      Prüfen Sie, ob es sich um den Standby-Modus handelt.

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 Master- als auch auf dem Standby-Host aus, um die max_locks_per_transaction-Property in apigee-postgresql zu aktualisieren:

1. Erstellen Sie die Datei /opt/apigee/customer/application/postgresql.properties, falls sie nicht vorhanden ist.
2. Ändern Sie die Eigentümerschaft dieser Datei in apigee:

   sudo 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 In-Place-Upgrade auf Postgres 17 durch:

1. Postgres auf dem Master-Host aktualisieren

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

2. Führen Sie den Einrichtungsbefehl auf dem Master-Host aus:

   apigee-service apigee-postgresql setup -f /opt/silent.conf

3. Führen Sie den Konfigurationsbefehl auf dem Masterhost aus:

   apigee-service apigee-postgresql configure

4. Starten Sie den Masterhost neu:

   apigee-service apigee-postgresql restart

5. Konfigurieren Sie sie als Master:

   apigee-service apigee-postgresql setup-replication-on-master -f /opt/silent.conf

6. Prüfen Sie, ob der Master-Host gestartet wurde:

   apigee-service apigee-postgresql wait_for_ready

7. Standby beenden:

   apigee-service apigee-postgresql stop

8. Führen Sie ein Upgrade des Standby-Modus durch.

   Hinweis:Wenn bei diesem Schritt Fehler auftreten, können Sie sie ignorieren. update.sh versucht, den Standby-Server mit einer falschen Konfiguration zu starten. Wenn die Postgres-Installation auf Version 17 aktualisiert wird, kann der Fehler ignoriert werden.

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

9. Prüfen Sie, 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. Replikation auf dem Standby-Server einrichten:

    apigee-service apigee-postgresql setup-replication-on-standby -f /opt/silent.conf

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

Nach Abschluss dieses Vorgangs wird der Standby-Modus erfolgreich gestartet.

Postgres-Knoten außer Betrieb nehmen

Nach Abschluss des Updates können Sie den neuen Standby-Knoten außer Betrieb nehmen:

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 Standby-Knotens ab, indem Sie den folgenden curl-Befehl auf dem neuen Standby-Knoten ausführen:

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

   Am Ende der Ausgabe sollte die UUID des Knotens im folgenden Format angezeigt werden:

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

3. Stoppen 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 Postgres-Masterknoten /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 Postgres-Master 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 Master 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 zum Ausführen 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.

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

Schritte zum Aktualisieren von Apigee SSO von älteren Versionen

In Edge for Private Cloud 4.53.01 werden die IDP-Schlüssel und -Zertifikate, die in der apigee-sso-Komponente verwendet werden, jetzt über einen Keystore konfiguriert. Sie müssen den zuvor verwendeten Schlüssel und das Zertifikat in einen Keystore exportieren, ihn konfigurieren und dann wie gewohnt mit der SSO-Aktualisierung fortfahren.

1. Ermitteln Sie den vorhandenen Schlüssel und das vorhandene Zertifikat, die zum Konfigurieren des Identitätsanbieters verwendet werden:

   1. Rufen Sie das Zertifikat ab, indem Sie den Wert von SSO_SAML_SERVICE_PROVIDER_CERTIFICATE in der Konfigurationsdatei für die SSO-Installation nachschlagen oder die apigee-sso-Komponente nach conf_login_service_provider_certificate abfragen.

      Verwenden Sie den folgenden Befehl auf dem SSO-Knoten, um apigee-sso nach dem IDP-Zertifikatspfad zu fragen. Suchen Sie in der Ausgabe nach dem Wert in der letzten Zeile.

      apigee-service apigee-sso configure -search conf_login_service_provider_certificate

   2. Rufen Sie den Schlüssel ab, indem Sie den Wert von SSO_SAML_SERVICE_PROVIDER_KEY in der SSO-Installationskonfigurationsdatei nachschlagen oder die apigee-sso-Komponente nach conf_login_service_provider_key abfragen.

      Verwenden Sie den folgenden Befehl auf dem SSO-Knoten, um apigee-sso nach dem IDP-Schlüsselpfad zu fragen. Suchen Sie in der Ausgabe nach dem Wert in der letzten Zeile.

      apigee-service apigee-sso configure -search conf_login_service_provider_key

2. Exportieren Sie den Schlüssel und das Zertifikat in einen Schlüsselspeicher:
   1. Exportieren Sie den Schlüssel und das Zertifikat in einen PKCS12-Schlüsselspeicher:

      sudo openssl pkcs12 -export -clcerts -in <certificate_path> -inkey <key_path> -out <keystore_path> -name <alias>

      Parameter:

      • certificate_path: Pfad zur Zertifikatsdatei, die in Schritt 1a abgerufen wurde.
      • key_path: Pfad zur privaten Schlüsseldatei, die in Schritt 1b abgerufen wurde.
      • keystore_path: Pfad zum neu erstellten Keystore mit dem Zertifikat und dem privaten Schlüssel.
      • alias: Alias, der für das Schlüssel- und Zertifikatspaar im Schlüsselspeicher verwendet wird.

      Weitere Informationen finden Sie in der OpenSSL-Dokumentation.

   2. Optional: Exportieren Sie den Schlüssel und das Zertifikat aus PKCS12 in einen JKS-Schlüsselspeicher:

      sudo keytool -importkeystore -srckeystore <PKCS12_keystore_path> -srcstoretype PKCS12 -destkeystore <destination_keystore_path> -deststoretype JKS -alias <alias>

      Parameter:

      • PKCS12_keystore_path: Pfad zum in Schritt 2a erstellten PKCS12-Schlüsselspeicher, der das Zertifikat und den Schlüssel enthält.
      • destination_keystore_path: Pfad zum neuen JKS-Keystore, in den das Zertifikat und der Schlüssel exportiert werden.
      • alias: Alias, der für das Schlüssel- und Zertifikatspaar im JKS-Keystore verwendet wird.

   Weitere Informationen finden Sie in der keytool-Dokumentation.

3. Ändern Sie den Eigentümer der Ausgabeschlüsselspeicherdatei in den Nutzer „apigee“:

   sudo chown apigee:apigee <keystore_file>

4. Fügen Sie die folgenden Attribute in die Apigee SSO-Konfigurationsdatei ein und aktualisieren Sie sie mit dem Pfad der Schlüsselspeicherdatei, dem Passwort, dem Schlüsselspeichertyp und dem Alias:

   # Path to the keystore file
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_PATH=${APIGEE_ROOT}/apigee-sso/source/conf/keystore.jks
   
   # Keystore password
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_PASSWORD=Secret123  # Password for accessing the keystore
   
   # Keystore type
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_TYPE=JKS  # Type of keystore, e.g., JKS, PKCS12
   
   # Alias within keystore that stores the key and certificate
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_ALIAS=service-provider-cert 

5. Aktualisieren Sie die Apigee SSO-Software auf dem SSO-Knoten wie gewohnt mit dem folgenden Befehl:

   /opt/apigee/apigee-setup/bin/update.sh -c sso -f /opt/silent.conf

Neue Edge-Benutzeroberfläche

In diesem Abschnitt werden Aspekte der Edge-UI aufgeführt. Weitere Informationen finden Sie unter Die neue Edge-Benutzeroberfläche für Private Cloud.

Edge-Benutzeroberfläche installieren

Nach der Erstinstallation empfiehlt Apigee, die Edge-UI zu installieren. Das ist eine verbesserte Benutzeroberfläche für Entwickler und Administratoren von Apigee Edge for Private Cloud.

Hinweis: Für die Edge-Benutzeroberfläche müssen Sie die Standardauthentifizierung deaktivieren und einen IDP wie SAML oder LDAP verwenden.

Weitere Informationen finden Sie unter Neue Edge-Benutzeroberfläche installieren.

Update mit Apigee mTLS

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 jeweils dort fortgesetzt, wo 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.53.01.

Informationen zu Aktualisierungen protokollieren

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-Dienstprogramm 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 für Upgrades 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 demselben Computer wie den Router. In allen Edge-Konfigurationen sind ein Router und ein Message Processor auf demselben Knoten zu sehen.
4. Sorge 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 vor und nach dem Update Folgendes:

• Auf einem kombinierten Router- und Nachrichtenprozessorknoten:
  • Führen Sie vor dem Update die folgenden Schritte aus:
    1. Machen Sie den Router unerreichbar.
    2. Machen Sie den Message Processor unerreichbar.
  • Nach dem Update führen Sie die folgenden Schritte aus:
    1. Sorgen Sie dafür, dass der Message Processor erreichbar ist.
    2. Sorgen Sie dafür, dass der Router erreichbar ist.
• Auf einzelnen Routerknoten:
  • Machen Sie den Router vor dem Update unerreichbar.
  • Sorge nach dem Update dafür, dass der Router erreichbar ist.
• Auf einzelnen Message Processor-Knoten:
  • Machen Sie den Message Processor vor dem Update unerreichbar.
  • Sorgen Sie nach dem Update dafür, dass der Message Processor erreichbar ist.

Konfigurationsdatei für die unbeaufsichtigte Installation verwenden

Sie müssen dem Update-Befehl eine Konfigurationsdatei im Silent-Modus übergeben. Die stille Konfigurationsdatei sollte dieselbe sein, die Sie für die Installation von Edge for Private Cloud 4.52.02 oder 4.53.00 verwendet haben.

Auf Version 4.53.01 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 Durchführung eines Reparaturvorgangs in Cassandra konfiguriert sind, bis das Update abgeschlossen ist.
2. Melden Sie sich als Root bei Ihrem Knoten an, um die Edge-RPMs zu installieren.
3. Deaktivieren Sie SELinux wie unter Das Edge-Einrichtungsprogramm apigee-setup installieren beschrieben.
4. Wenn Sie die Installation in AWS vornehmen, führen Sie die folgenden yum-configure-manager-Befehle aus:

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

5. Wenn Sie derzeit Edge 4.52.02 oder 4.53.00 verwenden:

   1. 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

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

      sudo bash /tmp/bootstrap_4.53.01.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, sie einzugeben.

      Standardmäßig prüft das Installationsprogramm, ob Java 1.8 installiert ist. Andernfalls wird sie vom Installationsprogramm installiert.

      Mit der Option JAVA_FIX können Sie angeben, wie die Java-Installation behandelt werden soll. JAVA_FIX kann folgende Werte haben:

      • I: OpenJDK 1.8 installieren (Standard).
      • C: Ohne Installation von Java fortfahren.
      • Q: Beenden. Bei dieser Option müssen Sie Java selbst installieren.
   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 apigee-validate-Dienstprogramm auf dem Management Server, wie im folgenden Beispiel gezeigt:

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

   5. Aktualisieren Sie das apigee-provision-Dienstprogramm 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 Reihenfolge vor, die unter Reihenfolge der Maschinenaktualisierung beschrieben ist.

      Wobei:

      • component ist die Edge-Komponente, die aktualisiert werden soll. Zulässige Werte:
        • cs: Cassandra
        • edge: Alle Edge-Komponenten mit Ausnahme der Edge-Benutzeroberfläche: Management Server, Message Processor, Router, QPID Server, Postgres Server
        • ldap: OpenLDAP
        • ps: postgresql
        • qpid: qpidd
        • sso: Apigee-SSO (wenn Sie SSO installiert haben)
        • ue: Neue Edge-Benutzeroberfläche
        • ui: Klassische Edge-UI
        • zk: Zookeeper
      • configFile ist dieselbe Konfigurationsdatei, die Sie bei der Installation von Version 4.52.02 oder 4.53.00 verwendet haben, um Ihre Edge-Komponenten zu definieren.

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

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

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

      /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart

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

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

Auf Version 4.53.01 aus einem lokalen Repository aktualisieren

Wenn sich Ihre Edge-Knoten hinter einer Firewall befinden oder auf andere Weise daran gehindert werden, über das Internet auf das Apigee-Repository zuzugreifen, können Sie das Update über ein lokales Repository oder einen Spiegel des Apigee-Repository 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 Edge dann über die .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 aus einem lokalen Repository der Version 4.53.01:

1. Erstellen Sie ein lokales Repo der Version 4.53.01, wie unter Lokales Apigee-Repository erstellen beschrieben.
2. So installieren Sie „apigee-service“ aus einer TAR-Datei:
   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.53.01.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.53.01.tar.gz

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

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

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

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

3. So installieren Sie apigee-service mit dem Nginx-Webserver:
   1. Konfigurieren Sie den Nginx-Webserver, wie unter Edge-Einrichtungsprogramm installieren im Abschnitt „Über das Repository mit dem Nginx-Webserver installieren“ beschrieben.
   2. Laden Sie auf dem Remote-Knoten die Edge-Datei bootstrap_4.53.01.sh in /tmp/bootstrap_4.53.01.sh herunter:

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

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

   3. Installieren Sie auf dem Remote-Knoten das Edge-apigee-setup-Dienstprogramm und die zugehörigen Abhängigkeiten:

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

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

4. 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 

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

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

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

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

7. Führen Sie das update-Dienstprogramm auf Ihren Knoten in der Reihenfolge aus, die unter Reihenfolge der Maschinenaktualisierung beschrieben ist:

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

   Wobei:

   • component ist die Edge-Komponente, die aktualisiert werden soll. Normalerweise aktualisieren Sie die folgenden Komponenten:
     • cs: Cassandra
     • edge: Alle Edge-Komponenten mit Ausnahme der Edge-Benutzeroberfläche: Management Server, Message Processor, Router, QPID Server, Postgres Server
     • ldap: OpenLDAP
     • ps: postgresql
     • qpid: qpidd
     • sso: Apigee-SSO (wenn Sie SSO installiert haben)
     • ue Neue Edge-Benutzeroberfläche
     • ui: Klassische Edge-UI
     • zk: Zookeeper
   • configFile ist dieselbe Konfigurationsdatei, die Sie bei der Installation von Version 4.52.02 oder 4.53.00 verwendet haben, um Ihre Edge-Komponenten zu definieren.

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

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

8. 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|edge-ui] restart

9. Testen Sie das Update, indem Sie das apigee-validate-Dienstprogramm auf dem Management Server ausführen, wie in Installation testen beschrieben.

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

Reihenfolge der Maschinenupdates

Die Reihenfolge, in der Sie die Maschinen in einer Edge-Installation aktualisieren, ist wichtig:

• Sie müssen alle LDAP-Knoten aktualisieren, bevor Sie andere Komponenten aktualisieren. Für das Upgrade von LDAP sind spezielle Schritte erforderlich.
• Sie müssen alle Cassandra- und ZooKeeper-Knoten aktualisieren. Wenn Sie ein Upgrade von Version 4.52.02 durchführen, folgen Sie der speziellen Anleitung zum Aktualisieren von Cassandra. Für die Versionen 4.52.02 und 4.53.00 müssen Sie die speziellen Schritte zum Upgraden von ZooKeeper ausführen.
• Sie müssen alle Management-Server und Router & Message Processors mit der Option „-c edge“ aktualisieren.
• Sie müssen alle Postgres-Knoten gemäß den speziellen Schritten für das Upgrade von Postgres aktualisieren.
• Sie müssen die Komponenten „edge-qpid-server“ und „edge-postgres-server“ in allen Rechenzentren aktualisieren.
• Sie müssen alle Qpid-Knoten aktualisieren.
• Sie müssen Edge-UI-Knoten und gegebenenfalls auch die Knoten für die neue Edge-UI und SSO aktualisieren.
• Es gibt keinen separaten Schritt zum Aktualisieren der Monetarisierung. Sie wird aktualisiert, wenn Sie die Edge-Option -c angeben.

Eigenständiges Upgrade mit einem Knoten

So führen Sie ein Upgrade einer Standalone-Konfiguration mit einem Knoten auf Version 4.53.01 durch:

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 2 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. LDAP auf Computer 1 aktualisieren:

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

2. Aktualisieren Sie Cassandra und ZooKeeper auf Maschine 1:

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

3. Edge-Komponenten auf Computer 1 aktualisieren:

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

4. Aktualisieren Sie Postgres auf Computer 2:

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

5. Edge-Komponenten auf Computer 1 aktualisieren:

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

6. Qpid auf Maschine 2 aktualisieren:

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

7. Aktualisieren Sie die Benutzeroberfläche auf Computer 1:

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

8. (Wenn Sie apigee-adminapi installiert haben) Das apigee-adminapi-Dienstprogramm auf Computer 1 wurde aktualisiert:

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

9. (Wenn Sie Apigee SSO installiert haben): Apigee SSO auf Computer 1 aktualisieren:

   /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

   Dabei ist sso_config_file die Konfigurationsdatei, die Sie bei der Installation von SSO erstellt haben.

10. Starten Sie die Edge-UI-Komponente auf Maschine 1 neu:

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

5-Knoten-Upgrade

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

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

1. LDAP auf Computer 1 aktualisieren:

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

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

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

3. Edge-Komponenten auf Maschine 1, 2 und 3 aktualisieren:

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

4. Aktualisieren Sie Postgres auf Maschine 4:

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

5. Postgres auf Maschine 5 aktualisieren:

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

6. Edge-Komponenten auf Computer 4 und 5 aktualisieren:

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

7. Qpid auf Maschine 4 aktualisieren:

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

8. Qpid auf Maschine 5 aktualisieren:

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

9. Aktualisieren Sie die Edge-Benutzeroberfläche:
   • Klassische Benutzeroberfläche:Wenn Sie die klassische Benutzeroberfläche verwenden, aktualisieren Sie die Komponente ui auf Computer 1, wie im folgenden Beispiel gezeigt:

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

   • Neue Edge-Benutzeroberfläche:Wenn Sie die neue Edge-Benutzeroberfläche installiert haben, aktualisieren Sie die ue-Komponente auf dem entsprechenden Computer (möglicherweise nicht Computer 1):

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

10. (Wenn Sie apigee-adminapi installiert haben) Das apigee-adminapi-Dienstprogramm auf Computer 1 wurde aktualisiert:

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

11. (Wenn Sie Apigee SSO installiert haben): Apigee SSO auf Computer 1 aktualisieren:

    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    Dabei ist sso_config_file die Konfigurationsdatei, die Sie bei der Installation von SSO erstellt haben.

12. Starten Sie die UI-Komponente neu:
    • Klassische Benutzeroberfläche:Wenn Sie die klassische Benutzeroberfläche verwenden, starten Sie die edge-ui-Komponente auf Computer 1 neu, wie im folgenden Beispiel gezeigt:

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

    • Neue Edge-Benutzeroberfläche:Wenn Sie die neue Edge-Benutzeroberfläche installiert haben, starten Sie die edge-management-ui-Komponente auf dem entsprechenden Computer neu (möglicherweise nicht Computer 1):

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

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. LDAP auf Computer 1 aktualisieren:

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

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

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

3. Aktualisieren Sie die Edge-Komponenten auf den Computern 1, 4 und 5 (Verwaltungsserver, Nachrichtenprozessor, Router) in dieser Reihenfolge:

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

4. Postgres auf Maschine 8 aktualisieren:

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

5. Postgres auf Maschine 9 aktualisieren:

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

6. 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

7. Qpid auf den Maschinen 6 und 7 aktualisieren:

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

8. Aktualisieren Sie entweder die neue Benutzeroberfläche (ue) oder die klassische Benutzeroberfläche (ui) auf Computer 1:

   /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile

9. (Wenn Sie apigee-adminapi installiert haben) Aktualisieren Sie das apigee-adminapi-Dienstprogramm auf Computer 1:

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

10. (Wenn Sie Apigee SSO installiert haben): Apigee SSO auf Computer 1 aktualisieren:

    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    Dabei ist sso_config_file die Konfigurationsdatei, die Sie bei der Installation von SSO erstellt haben.

11. Starten Sie die UI-Komponente neu:
    • Klassische Benutzeroberfläche:Wenn Sie die klassische Benutzeroberfläche verwenden, starten Sie die edge-ui-Komponente auf Computer 1 neu, wie im folgenden Beispiel gezeigt:

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

    • Neue Edge-Benutzeroberfläche:Wenn Sie die neue Edge-Benutzeroberfläche installiert haben, starten Sie die edge-management-ui-Komponente auf dem entsprechenden Computer neu (möglicherweise nicht Computer 1):

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

Clusterupgrade 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 LDAP auf Maschine 4 und 5:

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

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

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

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

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

4. Postgres auf Maschine 8 aktualisieren:

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

5. Postgres auf Maschine 9 aktualisieren:

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

6. 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

7. Qpid auf den Maschinen 12 und 13 aktualisieren:

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

8. Aktualisieren Sie entweder die neue Benutzeroberfläche (ue) oder die klassische Benutzeroberfläche (ui) auf den Maschinen 6 und 7:

   /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile

9. (Wenn Sie apigee-adminapi installiert haben) Das apigee-adminapi-Dienstprogramm auf den Computern 6 und 7 wurde aktualisiert:

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

10. (Wenn Sie Apigee SSO installiert haben): Aktualisieren Sie Apigee SSO auf den Maschinen 6 und 7:

    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    Dabei ist sso_config_file die Konfigurationsdatei, die Sie bei der Installation von SSO erstellt haben.

11. Starten Sie die UI-Komponente neu:
    • Klassische Benutzeroberfläche:Wenn Sie die klassische Benutzeroberfläche verwenden, starten Sie die edge-ui-Komponente auf den Maschinen 6 und 7 neu, wie im folgenden Beispiel gezeigt:

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

    • Neue Edge-Benutzeroberfläche:Wenn Sie die neue Edge-Benutzeroberfläche installiert haben, starten Sie die edge-management-ui-Komponente auf den Computern 6 und 7 neu:

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

Clusterupgrade 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. LDAP aktualisieren:
   1. Maschine 1 in Rechenzentrum 1

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

   2. Maschine 7 in Rechenzentrum 2

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

2. Aktualisieren Sie Cassandra und ZooKeeper:
   1. Maschinen 1, 2 und 3 in Rechenzentrum 1:

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

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

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

3. Edge-Komponenten aktualisieren:
   1. Auf den Maschinen 1, 2 und 3 in Rechenzentrum 1:

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

   2. Auf den Maschinen 7, 8 und 9 in Rechenzentrum 2

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

4. Postgres aktualisieren:
   1. Maschine 6 in Rechenzentrum 1

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

   2. Maschine 12 in Rechenzentrum 2

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

5. Edge-Komponenten aktualisieren:
   1. Maschinen 4, 5 und 6 in Rechenzentrum 1

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

   2. Maschinen 10, 11 und 12 in Rechenzentrum 2

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

6. Aktualisieren Sie qpidd:
   1. Maschinen 4 und 5 in Rechenzentrum 1
      1. qpidd auf Maschine 4 aktualisieren:

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

      2. So aktualisieren Sie qpidd auf Maschine 5:

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

   2. Maschinen 10 und 11 in Rechenzentrum 2
      1. Aktualisiere qpidd auf Maschine 10:

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

      2. Aktualisiere qpidd auf Maschine 11:

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

7. Aktualisieren Sie entweder die neue Benutzeroberfläche (ue) oder die klassische Benutzeroberfläche (ui):
   1. Maschine 1 in Rechenzentrum 1:

      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile

   2. Maschine 7 in Rechenzentrum 2:

      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile

8. (Wenn Sie apigee-adminapi installiert haben): Das apigee-adminapi-Dienstprogramm wurde aktualisiert:
   1. Maschine 1 in Rechenzentrum 1:

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

   2. Maschine 7 in Rechenzentrum 2:

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

9. (Wenn Sie Apigee SSO installiert haben): Apigee SSO aktualisieren:
   1. Maschine 1 in Rechenzentrum 1:

      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

   2. Maschine 7 in Rechenzentrum 2:

      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

   Dabei ist sso_config_file die Konfigurationsdatei, die Sie bei der Installation von SSO erstellt haben.

10. Starten Sie die neue Edge-Benutzeroberfläche (edge-management-ui) oder die klassische Edge-Benutzeroberfläche (edge-ui) auf den Computern 1 und 7 neu:

    /opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart

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. LDAP
2. Cassandra
3. Zookeeper
4. Verwaltungsserver
5. Message Processor
6. Router
7. Postgres
8. „Edge“ bedeutet das Profil „-c edge“ auf allen Knoten in der Reihenfolge: Knoten mit Qpid-Server, Edge-Postgres-Server.
9. qpidd
10. Edge-Benutzeroberfläche (klassisch oder neu)
11. apigee-adminapi
12. Apigee SSO

Nachdem Sie das Update abgeschlossen haben, müssen Sie die Edge-UI-Komponente auf allen Computern, auf denen sie ausgeführt wird, neu starten.