Aktualizowanie Apigee Edge z wersji 4.53.00 lub 4.53.01 do wersji 4.54.00

Apigee obsługuje uaktualnianie Edge dla chmury prywatnej bezpośrednio z wersji 4.53.00 lub 4.53.01 do wersji 4.54.00. Na tej stronie dowiesz się, jak przeprowadzić takie uaktualnienia.

Przegląd zgodnych ścieżek uaktualniania znajdziesz w macierzy zgodności uaktualniania w przypadku wersji Edge dla chmury prywatnej.

Kto może przeprowadzić aktualizację

Osoba przeprowadzająca aktualizację powinna być tą samą osobą, która pierwotnie zainstalowała Edge, lub osobą działającą jako użytkownik root.

Po zainstalowaniu pakietów RPM Edge każdy może je skonfigurować.

Które komponenty musisz zaktualizować

Musisz zaktualizować wszystkie komponenty Edge. Edge nie obsługuje konfiguracji zawierającej komponenty z wielu wersji.

Materiały do przeczytania przed spotkaniem

W tych tematach znajdziesz ważne informacje o zmianach wprowadzonych w Edge dla chmury prywatnej w wersji 4.54.00:

• Zmiany w wersji 4.54.00: sprawdź zmiany w TLS i wywołaniu Java, które wymagają przygotowania przed uaktualnieniem. Więcej informacji znajdziesz w sekcji Zmiany w wersji 4.54.00.

• Architektura środowiska wykonawczego Dual-Java (Java 17 i Java 21): od wersji 4.54.00 Edge dla chmury prywatnej nie obsługuje już Javy 8 i uruchamia komponenty w Javie 17 lub Javie 21. Więcej informacji znajdziesz w artykule Zmiany w wersji 4.54.00.

• Brak automatycznej instalacji Javy podczas uruchamiania: Edge dla chmury prywatnej 4.54.00 ma możliwość wykrywania instalacji Javy i sprawdzania, czy masz zainstalowane wersje Java 17 i 21.

• Nowy interfejs Edge w wersji 4.54.00: dowiedz się więcej o przejściu na nowy interfejs Edge jako domyślny interfejs zarządzania i usunięciu klasycznego interfejsu (edge-ui). Więcej informacji znajdziesz w artykule o nowym interfejsie Edge.

• SSO w Apigee w wersji 4.54.00: poznaj zaktualizowaną architekturę SSO i zmiany w konfiguracji uwierzytelniania. Więcej informacji znajdziesz w artykule SSO w Apigee.

• Nginx 1.30 w wersji 4.54.00: zapoznaj się z automatyczną aktualizacją Nginx do wersji 1.30.x na routerach brzegowych, potencjalnym wpływem na czas działania i działaniami ograniczającymi. Więcej informacji znajdziesz w artykule o zmianach w Nginx 1.30.

Wymagania wstępne dotyczące uaktualnienia

Przed uaktualnieniem Apigee Edge sprawdź, czy spełniasz te wymagania wstępne:

• Sprawdź informacje o wersji i nowe funkcje

  Zanim rozpoczniesz proces uaktualniania, dokładnie zapoznaj się ze wszystkimi nowymi funkcjami, zmianami w działaniu i wycofanymi funkcjami opisanymi w informacjach o wersji Edge dla chmury prywatnej 4.54.00.

• Automatyczne wykrywanie i współistnienie plików binarnych Javy podczas uaktualniania: zainstaluj Javę za pomocą standardowych menedżerów pakietów (takich jak yum) lub standardowych lokalizacji (takich jak /usr/lib/jvm lub update-alternatives). Nie musisz konfigurować obu wersji jednocześnie w ścieżce systemowej. Nie odinstalowuj Javy 8 przed uaktualnieniem. Zainstaluj Javę 8 obok Javy 17 i Javy 21, aby istniejące usługi Edge dla chmury prywatnej w wersji 4.53.xx działały bez przerw do czasu ich zaktualizowania.

• Tworzenie kopii zapasowej wszystkich węzłów

  Ze względów bezpieczeństwa przed aktualizacją zalecamy wykonanie pełnej kopii zapasowej wszystkich węzłów. Aby wykonać kopię zapasową, postępuj zgodnie z procedurą dla bieżącej wersji Edge. Dzięki temu będziesz mieć plan awaryjny na wypadek, gdyby aktualizacja do nowej wersji nie działała prawidłowo. Więcej informacji o kopiach zapasowych znajdziesz w artykule Tworzenie i przywracanie kopii zapasowej.

• Kopia zapasowa pliku konfiguracji instalacji dyskretnej

  Upewnij się, że kopie zapasowe plików konfiguracji instalacji dyskretnej Edge dla chmury prywatnej w wersji 4.53.00 lub 4.53.01 są przechowywane, aby w razie potrzeby ułatwić przywrócenie poprzedniej wersji.

• Sprawdź, czy Edge jest uruchomiony

  Upewnij się, że Edge działa podczas procesu aktualizacji, używając polecenia:

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

• Weryfikacja wymagań wstępnych dotyczących bazy danych Cassandra

  Jeśli wcześniej uaktualniono starszą wersję Edge dla chmury prywatnej do wersji 4.53.00 (lub) 4.53.01 i teraz planujesz uaktualnienie do wersji 4.54.00, upewnij się, że wykonano wymagane kroki po uaktualnieniu Cassandra. Te kroki są opisane w dokumentacji dotyczącej uaktualnienia do wersji 4.53.00 (lub) 4.53.01, a także w sekcji Wymagania wstępne dotyczące uaktualnienia Cassandry. Jeśli nie masz pewności, czy te czynności zostały wykonane podczas poprzedniego uaktualnienia, wykonaj je ponownie przed przejściem na wersję 4.54.00.

• Zatrzymaj apigee-monit: jeśli apigee-monit działa w węźle, zatrzymaj go za pomocą polecenia /opt/apigee/apigee-service/bin/apigee-service apigee-monit stop przed uaktualnieniem. Zapobiega to automatycznemu ponownemu uruchamianiu komponentów przez apigee-monit podczas ich uaktualniania. Po zakończeniu uaktualnienia włącz go ponownie za pomocą polecenia apigee-service apigee-monit start.

Automatyczne propagowanie ustawień usługi

Jeśli ustawiono jakieś właściwości przez edycję plików .properties w /opt/apigee/customer/application, te wartości zostaną zachowane podczas aktualizacji.

Uaktualnianie routera i procesora komunikatów

Uaktualnij wszystkie węzły routerów i procesorów komunikatów we wszystkich centrach danych, jeden po drugim:

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

Uaktualnianie serwera zarządzania

Uaktualnij wszystkie węzły serwera zarządzania w centrach danych, jeden po drugim:

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

Przejście na OpenLDAP 2.6.10

W Edge dla chmury prywatnej w wersji 4.54.00 wprowadzono OpenLDAP 2.6.10. To uaktualnienie dotyczy wszystkich topologii wdrożenia Apigee OpenLDAP: z jednym serwerem, aktywno-pasywnych i aktywno-aktywnych (z wieloma serwerami głównymi).

Przygotowanie i instalacja (wszystkie serwery LDAP)

Uaktualnianie do nowego interfejsu Edge i SSO w Apigee (jeśli jest zainstalowane)

W Apigee Edge dla chmury prywatnej 4.54.00 klasyczny interfejs użytkownika (edge-ui) został usunięty i zastąpiony przez nowy interfejs Edge (edge-management-ui). W zależności od tego, czy w Twojej konfiguracji jest zainstalowane i używane logowanie jednokrotne Apigee, wykonaj jedną z 2 opcji poniżej:

# 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

Uaktualnienie do Qpid 10.0.1

Ta metoda gwarantuje, że nie będzie przerw w działaniu środowiska wykonawczego Edge, i minimalizuje utratę danych środowiska wykonawczego, jeśli takie dane zostały pozyskane na potrzeby analizy.

Aby przeprowadzić uaktualnienie do Qpid bez przestojów:

1. Wybierz jeden węzeł Qpid, od którego chcesz zacząć.

2. Zatrzymaj brokera Qpid w węźle:

   apigee-service apigee-qpidd stop

3. Zablokuj ruch przychodzący na porcie brokera 5672 ze wszystkich procesorów komunikatów, stosując zaporę sieciową. Możesz zastosować tę zaporę sieciową na poziomie instancji węzła Qpid lub innego zewnętrznego komponentu zapory sieciowej lub sieci.

   Zalecamy wykonanie tego samego kroku w przypadku wszystkich adresów IP procesorów komunikatów. Aby na przykład za pomocą IPTables odrzucić żądania przychodzące z adresów IP procesora komunikatów do węzła Qpid na porcie 5672, możesz użyć takiego polecenia:

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

4. Uruchom ponownie brokera Qpid, aby opróżnić istniejące wiadomości, jeśli takie są:

   apigee-service apigee-qpidd start

5. Sprawdź, czy istniejące kolejki są puste:

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

   Jeśli wiadomości utknęły w kolejce niedostarczonych komunikatów (DLQ) (ax-q-axgroup-001-consumer-group-001-dl), opróżnij ją, wykonując czynności opisane w sekcji dotyczącej rozwiązywania problemów z danymi analitycznymi, które utknęły w kolejce niedostarczonych komunikatów.

6. Po sprawdzeniu, czy kolejki zostały opróżnione w starym węźle, zatrzymaj apigee-qpidd:

   apigee-service apigee-qpidd stop

7. Uaktualnij Qpid w węźle:

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

8. Uruchom ponownie edge-qpid-server:

   apigee-service edge-qpid-server restart

9. Usuń regułę zapory sieciowej zastosowaną w kroku 3.

   Wykonaj tę samą czynność usuwania w przypadku wszystkich adresów IP procesora wiadomości, do których zastosowano zaporę sieciową. Po usunięciu zapór sieciowych żądania wysyłane z adresów IP procesora komunikatów do węzła Qpid na porcie 5672 będą akceptowane. Jeśli do dodania zapory sieciowej użyto narzędzia iptables, możesz usunąć zaporę i wyświetlić listę istniejących ustawień, używając poleceń takich jak:

   iptables -F
   iptables -L

10. Użyj monitorowania sieci, aby sprawdzić, czy kolejki Qpid otrzymują wiadomości:

    http://QPID_NODE_IP:8090

11. Powtórz kroki od 1 do 9 dla każdego węzła Qpid.

Uaktualnienie do Postgres 18.6

Ta wersja Edge obejmuje uaktualnienie do Postgres 18.6. W ramach tego uaktualnienia wszystkie dane Postgres są przenoszone do Postgres 18.6.

Większość systemów produkcyjnych Edge korzysta z 2 węzłów Postgres skonfigurowanych do replikacji podstawowej i rezerwowej. Podczas procesu aktualizacji, gdy węzły Postgres są wyłączone na potrzeby aktualizacji, dane analityczne są nadal zapisywane w węzłach Qpid. Po zaktualizowaniu węzłów Postgres i przywróceniu ich do trybu online dane analityczne są przesyłane do tych węzłów.

Sposób aktualizacji Postgres zależy od tego, jak skonfigurowano magazyn danych dla węzłów Postgres:

• Jeśli używasz lokalnego magazynu danych dla węzłów Postgres , na czas uaktualnienia musisz zainstalować nowy węzeł Postgres w trybie gotowości. Po zakończeniu uaktualnienia możesz wycofać nowy węzeł rezerwowy Postgres. Dodatkowy węzeł rezerwowy Postgres jest wymagany, jeśli z jakiegoś powodu musisz wycofać aktualizację. Jeśli musisz wycofać aktualizację, po wycofaniu nowy węzeł rezerwowy Postgres stanie się podstawowym węzłem Postgres. Dlatego podczas instalowania nowego węzła rezerwowego Postgres powinien on znajdować się na węźle, który spełnia wszystkie wymagania sprzętowe serwera Postgres, zgodnie z definicją w wymaganiach instalacji Edge.

  W konfiguracji Edge z 1 lub 2 węzłami, czyli w topologiach używanych do prototypowania i testowania, masz tylko 1 węzeł Postgres. Możesz bezpośrednio aktualizować te węzły Postgres bez konieczności tworzenia nowego węzła Postgres.

• Jeśli używasz pamięci sieciowej dla węzłów Postgres , zgodnie z zaleceniami Apigee, nie musisz instalować nowego węzła Postgres. W poniższych procedurach możesz pominąć kroki, które określają instalację, a następnie wycofanie nowego węzła rezerwowego Postgres. Zanim rozpoczniesz proces aktualizacji, zrób migawkę sieciową magazynu danych używanego przez Postgres. Jeśli podczas aktualizacji wystąpią błędy i konieczne będzie przywrócenie poprzedniej wersji, możesz przywrócić węzeł Postgres z tego zrzutu.

Instalowanie nowego węzła rezerwowego Postgres

Ta procedura tworzy serwer rezerwowy Postgres na nowym węźle. Pamiętaj, aby zainstalować nowy serwer rezerwowy Postgres dla istniejącej wersji Edge (4.53.00 lub 4.53.01), a nie dla wersji 4.54.00.

Aby przeprowadzić instalację, użyj tego samego pliku konfiguracyjnego, którego użyto do zainstalowania bieżącej wersji Edge.

Aby utworzyć nowy węzeł rezerwowy Postgres:

1. W bieżącej instancji głównej Postgres zmodyfikuj plik /opt/apigee/customer/application/postgresql.properties, aby ustawić ten token. Jeśli ten plik nie istnieje, utwórz go:

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

   gdzie existing_standby_ip to adres IP bieżącego serwera rezerwowego Postgres, a new_standby_ip to adres IP nowego węzła rezerwowego.

2. Ponownie uruchom apigee-postgresql na podstawowym serwerze Postgres:

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

3. Sprawdź, czy nowy węzeł rezerwowy został dodany, wyświetlając plik /opt/apigee/apigee-postgresql/conf/pg_hba.conf na węźle podstawowym. W pliku powinny znajdować się te wiersze:

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

4. Zainstaluj nowy serwer rezerwowy Postgres:

   1. Zmodyfikuj plik konfiguracyjny, którego użyto do zainstalowania bieżącej wersji Edge, aby określić te elementy:

      # 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. Wyłącz SELinux zgodnie z opisem w artykule Instalowanie narzędzia apigee-setup w Edge.

   3. Pobierz i uruchom skrypt wczytywania na podstawie bieżącej wersji Edge:

      • Jeśli obecnie używasz Edge 4.53.00:

        Pobierz plik Edge bootstrap_4.53.00.sh do /tmp/bootstrap_4.53.00.sh:

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

        Zainstaluj narzędzie Edge apigee-service i zależności:

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

      • Jeśli korzystasz obecnie z Edge w wersji 4.53.01:

        Pobierz plik Edge bootstrap_4.53.01.sh do /tmp/bootstrap_4.53.01.sh:

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

        Zainstaluj narzędzie Edge apigee-service i zależności:

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

   4. Użyj apigee-service, aby zainstalować narzędzie apigee-setup:

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

   5. Zainstaluj Postgres:

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

   6. W nowym węźle rezerwowym uruchom to polecenie i sprawdź, czy jest on rezerwowy:

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

Przeprowadzanie uaktualnienia Postgres na miejscu

Krok wstępny

Zanim przeprowadzisz uaktualnienie Postgres na miejscu, wykonaj te czynności na hoście podstawowym i rezerwowym, aby zaktualizować właściwość max_locks_per_transaction w apigee-postgresql:

1. Jeśli nie ma takiego pliku, utwórz go w lokalizacji /opt/apigee/customer/application/postgresql.properties .

2. Zmień własność tego pliku na apigee :

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

3. Dodaj do pliku tę właściwość:

   conf/postgresql.conf+max_locks_per_transaction=30000

4. Skonfiguruj apigee-postgresql :

   apigee-service apigee-postgresql configure

5. Uruchom ponownie apigee-postgresql :

   apigee-service apigee-postgresql restart

Przeprowadzanie uaktualnienia na miejscu

Aby przeprowadzić uaktualnienie do Postgres 18, wykonaj te czynności:

1. Uaktualnij bazę danych PostgreSQL na hoście głównym

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

2. Uruchom polecenie konfiguracji na hoście podstawowym:

   apigee-service apigee-postgresql setup -f configFile

3. Uruchom polecenie konfiguracji na hoście głównym:

   apigee-service apigee-postgresql configure

4. Ponownie uruchom hosta podstawowego:

   apigee-service apigee-postgresql restart

5. Skonfiguruj go jako główny:

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

6. Sprawdź, czy główny gospodarz rozpoczął spotkanie:

   apigee-service apigee-postgresql wait_for_ready

7. Zatrzymaj tryb gotowości:

   apigee-service apigee-postgresql stop

8. Uaktualnij instancję rezerwową.

   Uwaga: jeśli ten krok zakończy się błędem lub niepowodzeniem, możesz go zignorować. update.sh spróbuje uruchomić serwer rezerwowy z nieprawidłową konfiguracją. Jeśli instalacja Postgres zostanie uaktualniona do wersji 18, błąd można zignorować.

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

9. Sprawdź, czy tryb gotowości został zatrzymany:

   apigee-service apigee-postgresql stop

10. Usuń starą konfigurację gotowości:

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

11. Skonfiguruj replikację na serwerze rezerwowym:

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

12. Usuń wiersz conf/postgresql.conf+max_locks_per_transaction=30000 z pliku /opt/apigee/customer/application/postgresql.properties na hoście podstawowym i rezerwowym. Ten wiersz został dodany w kroku wstępnym .

    Po wykonaniu tej procedury tryb gotowości uruchomi się prawidłowo.

Wycofanie węzła Postgres

Po zakończeniu aktualizacji wycofaj nowy węzeł rezerwowy:

1. Upewnij się, że Postgres działa:

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

   Jeśli Postgres nie działa, uruchom go:

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

2. Pobierz identyfikator UUID nowego węzła rezerwowego, uruchamiając w nim to polecenie curl:

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

   Na końcu danych wyjściowych powinien pojawić się identyfikator UUID węzła w formacie:

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

3. Zatrzymaj nowy węzeł rezerwowy, uruchamiając to polecenie na nowym węźle rezerwowym:

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

4. Na podstawowym węźle Postgresa zmień /opt/apigee/customer/application/postgresql.properties, aby usunąć nowy węzeł rezerwowy z conf_pg_hba_replication.connection:

   conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust

5. Ponownie uruchom apigee-postgresql na podstawowym serwerze Postgres:

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

6. Sprawdź, czy nowy węzeł rezerwowy został usunięty, wyświetlając plik /opt/apigee/apigee-postgresql/conf/pg_hba.conf w węźle podstawowym. W tym pliku powinien być widoczny tylko ten wiersz:

   host replication apigee existing_standby_ip/32 trust

7. Usuń identyfikator UUID węzła rezerwowego z ZooKeeper, wykonując to wywołanie interfejsu Edge Management API w węźle serwera zarządzania:

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

Czynności po uaktualnieniu Postgres

Po uaktualnieniu Postgres do wersji głównej wewnętrzne statystyki Postgres są usuwane. Te statystyki pomagają planerowi zapytań Postgres w wykorzystaniu najbardziej optymalnych indeksów i ścieżek do wykonywania zapytań.

PostgreSQL może stopniowo odbudowywać statystyki w miarę wykonywania zapytań i działania demona autovacuum. Jednak dopóki statystyki nie zostaną odbudowane, zapytania mogą być powolne.

Aby rozwiązać ten problem, wykonaj polecenie ANALYZE we wszystkich tabelach w bazie danych w głównym węźle Postgres. Możesz też uruchomić polecenie ANALYZE dla kilku tabel naraz.

Uaktualnianie do wersji ZooKeeper 3.8.5

Ta wersja Edge dla chmury prywatnej zawiera uaktualnienie do ZooKeeper 3.8.5. W ramach tej aktualizacji wszystkie dane ZooKeeper zostaną przeniesione do ZooKeeper 3.8.5.

Zanim uaktualnisz ZooKeeper, przeczytaj przewodnik po konserwacji ZooKeeper. Większość systemów produkcyjnych Edge korzysta z klastra węzłów ZooKeeper rozproszonych w wielu centrach danych. Niektóre z tych węzłów są skonfigurowane jako głosujący, którzy uczestniczą w wyborze lidera ZooKeeper, a pozostałe są skonfigurowane jako obserwatorzy. Więcej informacji znajdziesz w artykule Informacje o liderach, obserwujących, głosujących i obserwatorach. Węzły głosujące wybierają lidera, po czym same stają się obserwatorami.

Podczas procesu aktualizacji może wystąpić chwilowe opóźnienie lub błąd zapisu w ZooKeeper, gdy węzeł lidera zostanie wyłączony. Może to mieć wpływ na operacje zarządzania, które zapisują dane w ZooKeeper, takie jak wdrażanie serwera proxy, oraz zmiany w infrastrukturze Apigee, takie jak dodawanie lub usuwanie procesora wiadomości itp. Podczas uaktualniania ZooKeeper zgodnie z poniższą procedurą nie powinno to mieć wpływu na interfejsy API środowiska wykonawczego Apigee (chyba że te interfejsy API środowiska wykonawczego wywołują interfejsy API zarządzania).

Ogólnie proces uaktualniania obejmuje utworzenie kopii zapasowej każdego węzła. Następnie uaktualniane są wszystkie węzły obserwujące i śledzące, a na koniec węzeł lidera.

Tworzenie kopii zapasowej

Utwórz kopię zapasową wszystkich węzłów ZooKeeper, aby użyć jej w razie konieczności wycofania zmian. Pamiętaj, że przywrócenie spowoduje przywrócenie ZooKeeper do stanu, w którym utworzono kopię zapasową.

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

Jeśli używasz maszyn wirtualnych i masz taką możliwość, możesz też tworzyć ich migawki lub kopie zapasowe, aby w razie potrzeby przywrócić je lub cofnąć zmiany.

Identyfikowanie lidera, obserwujących i obserwatorów

1. Jeśli nie jest zainstalowane na węźle ZooKeeper, zainstaluj nc:

   yum install nc

2. Uruchom na węźle to polecenie nc, gdzie 2181 to port ZooKeeper:

   echo stat | nc localhost 2181

   Powinny pojawić się dane wyjściowe podobne do tych:

   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

   W wierszu Mode danych wyjściowych węzłów powinien być widoczny obserwator, lider lub obserwujący (czyli węzeł głosujący, który nie jest liderem) w zależności od konfiguracji węzła.

1. Powtórz kroki 1 i 2 na każdym węźle ZooKeeper.

Uaktualnianie ZooKeepera w węzłach obserwatora i obserwującego

Uaktualnij ZooKeeper na każdym węźle obserwatora i obserwującego w następujący sposób:

1. Pobierz i uruchom bootstrap Edge dla chmury prywatnej w wersji 4.54.00, jak opisano w sekcji Aktualizacja do wersji 4.54.00 na węźle z zewnętrznym połączeniem internetowym . Proces ten może się różnić w zależności od tego, czy węzeł ma zewnętrzne połączenie z internetem, czy instalacja jest przeprowadzana offline.

2. Uaktualnij komponent ZooKeeper:

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

   Uwaga: jeśli na tych węzłach są zainstalowane inne komponenty (np. Cassandra), możesz je teraz zaktualizować (np. za pomocą profilu zk,cs) lub zrobić to później. Apigee zaleca, aby najpierw uaktualnić ZooKeepera i upewnić się, że klaster działa prawidłowo, zanim uaktualnisz inne komponenty.

3. Powtórz powyższe kroki na każdym węźle obserwatora i obserwującego ZooKeeper.

Wyłączanie lidera

Po uaktualnieniu wszystkich węzłów obserwatora i obserwującego wyłącz lidera. Na węźle oznaczonym jako węzeł główny uruchom to polecenie:

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

Pamiętaj, że podczas tego zdarzenia, zanim zostanie wybrany nowy lider, mogą wystąpić chwilowe opóźnienia lub błędy zapisu w ZooKeeper. Może to mieć wpływ na operacje, które zapisują dane w ZooKeeper, takie jak wdrażanie serwerów proxy lub zmiany w infrastrukturze Apigee, np. dodawanie lub usuwanie procesorów komunikatów.

Sprawdzanie, czy nowy lider został wybrany

Wykonaj czynności opisane w sekcji Identyfikowanie lidera, obserwatorów i naśladowców powyżej, aby sprawdzić, czy po zatrzymaniu obecnego lidera został wybrany nowy lider spośród naśladowców. Pamiętaj, że lider mógł zostać wybrany w innym centrum danych niż obecny lider.

Osoba odpowiedzialna za organizację procesu nauczania

Wykonaj te same czynności co w sekcji Uaktualnianie ZooKeepera na węzłach obserwatora i obserwującego powyżej.

Po uaktualnieniu starego węzła lidera sprawdź stan klastra i upewnij się, że istnieje węzeł lidera.

Uaktualnianie do wersji Cassandra 5.0.8

Apigee Edge dla chmury prywatnej w wersji 4.54.00 zawiera uaktualnienie bazy danych Cassandra do wersji 5.0.8.

Uaktualnienia i wycofywanie

• Uaktualnianie z Cassandra 4.0.X do Cassandra 5.0.X to proces ciągły.

• Bezpośrednie przywrócenie wersji 4.0.X z wersji 5.0.X nie jest możliwe. Wycofanie zmian przy użyciu replik lub kopii zapasowych jest złożoną procedurą i może wiązać się z przestojem lub utratą danych. Rozwiązywanie problemów i przechodzenie na wyższą wersję Cassandry (5.0.X) jest lepsze niż przywracanie poprzedniej wersji.

• Przed próbą uaktualnienia należy zapoznać się z procedurami przywracania. Uwzględnienie niuansów wycofywania zmian podczas uaktualniania ma kluczowe znaczenie dla zapewnienia dostępności odpowiednich ścieżek wycofywania zmian.

Jedno centrum danych

Uaktualnienie Cassandry z wersji 4.0.X do 5.0.X w jednym centrum danych jest bezproblemowe, ale wycofanie zmian jest skomplikowane i może spowodować przestoje oraz utratę danych. W przypadku obciążeń produkcyjnych zdecydowanie zalecamy dodanie nowego centrum danych z co najmniej węzłami Cassandra dostępnymi w nowym centrum danych przed rozpoczęciem uaktualniania. Umożliwi to przywrócenie Cassandry bez utraty danych i zakłóceń w ruchu interfejsu API. Po zakończeniu uaktualnienia to dodatkowe centrum danych można wycofać z eksploatacji.

Jeśli dodanie nowego centrum danych nie jest możliwe, ale nadal chcesz mieć możliwość wycofania zmian, do przywrócenia Cassandry 4.0.X będą potrzebne kopie zapasowe. Ta metoda wiąże się jednak z przerwą w działaniu i utratą danych.

Wiele centrów danych

Korzystanie z wielu centrów danych z Edge dla chmury prywatnej w wersji 4.53.00 lub 4.53.01 zapewnia większą elastyczność w przypadku wycofywania zmian podczas uaktualniania do Edge dla chmury prywatnej w wersji 4.54.00.

• Wycofanie zmian wymaga co najmniej 1 centrum danych z wcześniejszą wersją Cassandry (4.0.X).

Zalecana metodologia uaktualniania

1. Uaktualniaj po jednym centrum danych Cassandra: zacznij od uaktualnienia poszczególnych węzłów Cassandra w jednym centrum danych. Zanim przejdziesz do następnego centrum danych, zakończ uaktualnianie wszystkich węzłów Cassandra w jednym centrum danych.

2. Wstrzymanie i weryfikacja: po uaktualnieniu jednego centrum danych wstrzymaj działanie, aby upewnić się, że klaster chmury prywatnej, a zwłaszcza uaktualnione centrum danych, działa prawidłowo.

3. Pamiętaj: możesz przywrócić poprzednią wersję Cassandry tylko wtedy, gdy masz co najmniej 1 centrum danych, w którym nadal działa starsza wersja.

4. Ważne: możesz wstrzymać proces na krótki czas (zalecamy kilka godzin), aby sprawdzić działanie, ale nie możesz pozostawać w stanie mieszanych wersji przez czas nieokreślony. Wynika to z faktu, że niejednolity klaster Cassandra (z węzłami w różnych wersjach) ma ograniczenia operacyjne.

5. Dokładne testowanie: przed uaktualnieniem kolejnego centrum danych Apigee zdecydowanie zaleca przeprowadzenie kompleksowych testów wydajności i funkcjonalności. Po uaktualnieniu wszystkich centrów danych nie można przywrócić wcześniejszej wersji.

Proces punktu kontrolnego wycofania

Pojedynczy punkt kontrolny wycofania: gdy wszystkie komponenty zostaną uaktualnione do wersji 4.54.00, wycofanie Cassandry będzie możliwe tylko wtedy, gdy co najmniej 1 centrum danych Cassandry będzie nadal korzystać ze starszej wersji. Po uaktualnieniu ostatniego centrum danych Cassandra uaktualnienie Edge dla chmury prywatnej do wersji 4.54.00 zostanie zakończone i nie będzie już można przywrócić poprzedniej wersji.

Przykład

Rozważ klaster z 2 centrami danych:

1. Stan początkowy: węzły Cassandra w obu centrach danych są w wersji 4.0.X. Wszystkie pozostałe węzły korzystają z Edge dla chmury prywatnej w wersji 4.54.00. Załóżmy, że w każdym centrum danych są 3 węzły Cassandra.

2. Uaktualnij DC-1: uaktualnij po kolei 3 węzły Cassandra w DC-1.

3. Wstrzymaj i sprawdź: wstrzymaj, aby upewnić się, że klaster, zwłaszcza DC-1, działa prawidłowo (sprawdź wydajność i funkcjonalność). Możesz przywrócić stan początkowy, korzystając z węzłów Cassandra w DC-2. Pamiętaj, że ze względu na ograniczenia klastra Cassandra z różnymi wersjami wstrzymanie musi być tymczasowe.

4. Uaktualnij DC-2: uaktualnij pozostałe 3 węzły Cassandra w DC-2. Gdy wszystkie węzły Cassandra w DC-2 zostaną uaktualnione, uaktualnianie Edge dla chmury prywatnej 4.54.00 zostanie zakończone.

Wymagania wstępne dotyczące uaktualnienia systemu Cassandra

Powinna być uruchomiona wersja Cassandra 4.0.X z Edge dla chmury prywatnej 4.53.00 lub 4.53.01. Upewnij się, że:

1. Ustaw Java 17 jako domyślną wersję Javy na serwerze: Cassandra 5.0.X usuwa obsługę Javy 8. Nie można uruchomić Cassandry 5.0.X ani narzędzia nodetool z Java 8. Przed wykonaniem czynności związanych z uaktualnieniem Cassandry upewnij się, że na każdym węźle Cassandry jest zainstalowana Java 17 i ustaw ją jako domyślną wersję, aby polecenia nodetool były wykonywane przy użyciu Javy 17:

   alternatives --set java JAVA_17_PATH/bin/java

   Sprawdź, czy aktywna domyślna wersja Javy to Java 17:

   java -version

2. Cały klaster działa i jest w pełni funkcjonalny z Cassandrą w wersji 4.0.X.

3. Strategia kompaktowania jest ustawiona na LeveledCompactionStrategy (warunek wstępny uaktualnienia do wersji 4.53.00 lub 4.53.01).

4. Sprawdź, czy każdy z tych kroków został wykonany w ramach wstępnej aktualizacji systemu Cassandra 4.0.X w Edge dla chmury prywatnej w wersji 4.53.00 lub 4.53.01.

   • Podczas poprzedniego uaktualnienia na każdym węźle Cassandra zostało wykonane polecenie post_upgrade

   • Podczas poprzedniego uaktualnienia polecenie drop_old_tables zostało wykonane w całym klastrze Cassandra.

Jeśli nie masz pewności, czy polecenia post_upgrade i drop_old_tables zostały wykonane w Cassandra 4.0.X podczas korzystania z Edge dla chmury prywatnej w wersji 4.53.00 (lub) 4.53.01, możesz je bezpiecznie uruchomić ponownie przed próbą uaktualnienia do wersji 4.54.00.

Krok 1. Przygotuj się do uaktualnienia

Poniższe kroki stanowią uzupełnienie standardowych plików, które zwykle tworzysz, takich jak standardowy plik konfiguracji Apigee, który umożliwia uaktualnianie komponentów.

1. Tworzenie kopii zapasowej Cassandra za pomocą Apigee.

2. Zrób zrzuty maszyn wirtualnych węzłów Cassandra (jeśli to możliwe).

3. Upewnij się, że port 9042 jest dostępny ze wszystkich komponentów Edge dla chmury prywatnej, w tym serwera zarządzania, procesora komunikatów, routera, Qpid i Postgres, do węzłów Cassandra, jeśli nie został jeszcze skonfigurowany. Więcej informacji znajdziesz w wymaganiach dotyczących portów.

Krok 2. Uaktualnij wszystkie węzły Cassandra

Wszystkie węzły Cassandra należy aktualizować pojedynczo w każdym centrum danych, po jednym centrum danych naraz. Pomiędzy uaktualnieniami węzłów w centrum danych odczekaj kilka minut, aby upewnić się, że zaktualizowany węzeł został w pełni uruchomiony i dołączył do klastra, zanim przejdziesz do uaktualniania kolejnego węzła w tym samym centrum danych.

Po uaktualnieniu wszystkich węzłów Cassandra w centrum danych odczekaj trochę czasu (od 30 minut do kilku godzin), zanim przejdziesz do węzłów w następnym centrum danych. W tym czasie dokładnie sprawdź zaktualizowane centrum danych i upewnij się, że wskaźniki funkcjonalności i wydajności klastra Apigee są nienaruszone. Ten krok jest kluczowy, aby zapewnić stabilność centrum danych, w którym Cassandra została uaktualniona do wersji 5.0.X, a pozostałe komponenty Apigee do wersji 4.54.00.

1. Aby uaktualnić węzeł Cassandra, uruchom to polecenie:

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

2. Po zaktualizowaniu węzła uruchom w nim to polecenie, aby przeprowadzić weryfikację przed przejściem dalej:

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

3. Powyższe polecenie wygeneruje dane wyjściowe podobne do tych:

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

4. Uruchom na węźle Cassandra to polecenie post_upgrade:

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

5. Uruchom to polecenie cleanup_old_index na węźle Cassandra:

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

6. Uruchom te polecenia nodetool, aby ponownie utworzyć indeksy w węźle Cassandra:

/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

Jeśli korzystasz z zarabiania, uruchom też te polecenia ponownego tworzenia indeksów związane z przestrzeniami kluczy zarabiania:

/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

Aktualizacja za pomocą Apigee mTLS

Aby zaktualizować Apigee mTLS , wykonaj te czynności:

• Odinstaluj Apigee mTLS .

• Ponowna instalacja Apigee mTLS

Cofanie aktualizacji

Jeśli aktualizacja się nie powiedzie, możesz spróbować rozwiązać problem, a następnie ponownie wykonać polecenie update.sh. Aktualizację możesz uruchamiać wielokrotnie. Będzie ona kontynuowana od miejsca, w którym została ostatnio przerwana.

Jeśli błąd wymaga przywrócenia poprzedniej wersji, szczegółowe instrukcje znajdziesz w sekcji Przywracanie wersji 4.54.00.

Rejestrowanie informacji o aktualizacji

Domyślnie narzędzie update.sh zapisuje informacje dziennika w:

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

Jeśli osoba, która uruchamia narzędzie update.sh, nie ma dostępu do tego katalogu, dziennik jest zapisywany w katalogu /tmp jako plik o nazwie update_username.log.

Jeśli ta osoba nie ma dostępu do /tmp, narzędzie update.sh nie zadziała.

Aktualizacja bez przestojów

Aktualizacja bez przestojów, czyli aktualizacja krocząca, umożliwia zaktualizowanie instalacji Edge bez wyłączania Edge.

Aktualizacja bez przestojów jest możliwa tylko w przypadku konfiguracji z co najmniej 5 węzłami.

Kluczem do uaktualnienia bez przestojów jest usunięcie z systemu równoważenia obciążenia każdego routera, po jednym naraz. Następnie zaktualizuj router i inne komponenty na tym samym komputerze co router, a potem dodaj router z powrotem do systemu równoważenia obciążenia.

1. Zaktualizuj maszyny w kolejności odpowiedniej dla Twojej instalacji, zgodnie z opisem w sekcji Kolejność aktualizacji maszyn .

2. Gdy nadejdzie czas na aktualizację routerów, wybierz dowolny router i ustaw go jako nieosiągalny, jak opisano w artykule Włączanie i wyłączanie osiągalności serwera (procesora komunikatów lub routera) .

3. Zaktualizuj wybrany router i wszystkie inne komponenty Edge na tym samym komputerze co router. Wszystkie konfiguracje Edge pokazują router i procesor komunikatów w tym samym węźle.

4. Spraw, aby router był ponownie dostępny.

5. Powtórz kroki 2–4 w przypadku pozostałych routerów.

6. Kontynuuj aktualizację na pozostałych maszynach w instalacji.

Przed aktualizacją i po niej wykonaj te czynności:

• W przypadku połączonego węzła Router i procesor komunikatów:

  • Przed aktualizacją wykonaj te czynności:

    1. Ustaw router jako nieosiągalny.

    2. Spraw, aby procesor komunikatów był niedostępny.

  • Po aktualizacji wykonaj te czynności:

    1. Udostępnij procesor komunikatów.

    2. Udostępnij router.

• Na pojedynczych węzłach routera:

  • Przed aktualizacją spraw, aby router był niedostępny.

  • Po aktualizacji udostępnij router.

• Na węzłach z jednym procesorem komunikatów:

  • Przed aktualizacją spraw, aby procesor komunikatów był niedostępny.

  • Po aktualizacji udostępnij procesor komunikatów.

Używanie pliku konfiguracji instalacji dyskretnej

Do polecenia aktualizacji musisz przekazać plik konfiguracji cichej. Plik konfiguracji cichej jest w większości podobny do tego, którego używasz do instalowania Edge dla chmury prywatnej w wersji 4.53.00 lub 4.53.01, ale w przypadku komponentów takich jak interfejs i SSO w Apigee może być konieczne wprowadzenie zmian zgodnie z opisem w sekcji Uaktualnianie do nowego interfejsu Edge i SSO w Apigee (jeśli są zainstalowane).

Aktualizacja do wersji 4.54.00 na węźle z zewnętrznym połączeniem internetowym

Aby zaktualizować komponenty Edge na węźle, wykonaj te czynności:

1. Jeśli są skonfigurowane jakieś zadania cron, które wykonują operację naprawy w Cassandra, wyłącz je do czasu zakończenia aktualizacji.

2. Aby zainstalować pakiety RPM Edge, zaloguj się na węźle jako użytkownik root.

   Uwaga: instalacja RPM wymaga dostępu do konta root, ale konfigurację Edge można przeprowadzić bez niego.

3. Wyłącz SELinux zgodnie z opisem w artykule Instalowanie narzędzia Edge apigee-setup .

4. Jeśli instalujesz na AWS , wykonaj te polecenia yum-configure-manager:

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

5. Jeśli obecnie korzystasz z Edge dla chmury prywatnej w wersji 4.53.00 lub 4.53.01:

   1. Pobierz plik Edge bootstrap_4.54.00.sh do /tmp/bootstrap_4.54.00.sh :

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

   2. Zainstaluj narzędzie Edge 4.54.00 apigee-service i zależności, wykonując to polecenie:

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

      gdzie uName:pWord to nazwa użytkownika i hasło otrzymane od Apigee. Jeśli pominiesz pWord, pojawi się prośba o jego podanie.

      Domyślnie instalator sprawdza, czy masz zainstalowane środowisko Java 17 i 21.

   3. Użyj apigee-service, aby zaktualizować narzędzie apigee-setup, jak pokazano w tym przykładzie:

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

   4. Zaktualizuj narzędzie apigee-validate na serwerze zarządzania, jak pokazano w tym przykładzie:

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

   5. Zaktualizuj narzędzie apigee-provision na serwerze zarządzania, jak pokazano w tym przykładzie:

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

   6. Uruchom narzędzie update na węzłach, wykonując to polecenie:

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

      Wykonaj te czynności w kolejności opisanej w sekcji Kolejność aktualizacji maszyn.

      Gdzie:

      • component to komponent Edge, który chcesz zaktualizować. Możliwe wartości:

        • edge : wszystkie komponenty Edge z wyjątkiem nowego interfejsu Edge: serwer zarządzania, procesor komunikatów, router, serwer QPID, serwer Postgres

        • ldap : OpenLDAP

        • ue : nowy interfejs Edge

        • qpid : Apigee Qpid

        • ps : Apigee Postgresql

        • zk : ZooKeeper

        • cs : Cassandra

      • configFile to ten sam plik konfiguracji, którego użyto do zdefiniowania komponentów Edge podczas instalacji w wersji 4.53.00 lub 4.53.01.

      Możesz uruchomić update.sh we wszystkich komponentach, ustawiając component na „all”, ale tylko wtedy, gdy masz profil instalacji Edge All-in-One (AIO). Na przykład:

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

   7. Jeśli jeszcze tego nie zrobiono, uruchom ponownie komponenty interfejsu New Edge na wszystkich węzłach, na których są one uruchomione:

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

   8. Przetestuj aktualizację, uruchamiając narzędzie apigee-validate na serwerze zarządzającym zgodnie z opisem w sekcji Testowanie instalacji.

Jeśli później zdecydujesz się wycofać aktualizację, wykonaj procedurę opisaną w sekcji Wycofywanie wersji 4.54.00.

Aktualizacja do wersji 4.54.00 z lokalnego repozytorium

Jeśli węzły brzegowe znajdują się za zaporą sieciową lub w inny sposób nie mają dostępu do repozytorium Apigee przez internet, możesz przeprowadzić aktualizację z lokalnego repozytorium lub kopii repozytorium Apigee.

Po utworzeniu lokalnego repozytorium Edge masz 2 opcje aktualizowania Edge z lokalnego repozytorium:

• Utwórz plik .tar repozytorium, skopiuj go na węzeł, a następnie zaktualizuj Edge z tego pliku.

• Zainstaluj serwer WWW w węźle z lokalnym repozytorium, aby inne węzły miały do niego dostęp. Apigee udostępnia serwer WWW Nginx, ale możesz też użyć własnego serwera WWW.

Aby zaktualizować repozytorium lokalne 4.54.00:

1. Utwórz lokalne repozytorium 4.54.00 zgodnie z opisem w sekcji „Tworzenie lokalnego repozytorium Apigee” w artykule Instalowanie narzędzia apigee-setup w Edge.

2. Zainstaluj apigee-service na węzłach docelowych, korzystając z jednej z tych metod:

   • Opcja 1. Zainstaluj apigee-service z pliku .tar

     1. Na węźle z lokalnym repozytorium użyj tego polecenia, aby spakować lokalne repozytorium do jednego pliku TAR o nazwie /opt/apigee/data/apigee-mirror/apigee-4.54.00.tar.gz:

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

     2. Skopiuj plik .tar do węzła, w którym chcesz zaktualizować Edge. Na przykład skopiuj go do katalogu /tmp na nowym węźle.

     3. Na nowym węźle rozpakuj plik do katalogu /tmp:

        tar -xzf apigee-4.54.00.tar.gz

        To polecenie tworzy nowy katalog o nazwie repos w katalogu zawierającym plik .tar. Na przykład /tmp/repos.

     4. Zainstaluj narzędzie Edge apigee-service i zależności z /tmp/repos:

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

        Zwróć uwagę, że w tym poleceniu podajesz ścieżkę do katalogu repozytoriów.

   • Opcja 2. Instalowanie apigee-service przy użyciu serwera WWW Nginx

     1. Skonfiguruj serwer WWW Nginx zgodnie z opisem w sekcji „Instalowanie z repozytorium przy użyciu serwera WWW Nginx” w artykule Instalowanie narzędzia apigee-setup w Edge.

     2. Na węźle zdalnym pobierz plik Edge bootstrap_4.54.00.sh do /tmp/bootstrap_4.54.00.sh:

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

        Gdzie uName:pWord to nazwa użytkownika i hasło ustawione wcześniej dla repozytorium, a remoteRepo to adres IP lub nazwa DNS węzła repozytorium.

     3. Na węźle zdalnym zainstaluj narzędzie Edge apigee-service i zależności:

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

        gdzie uName:pWord to nazwa użytkownika i hasło do repozytorium.

3. Użyj polecenia apigee-service, aby zaktualizować narzędzie apigee-setup, jak pokazano w tym przykładzie:

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

4. Zaktualizuj narzędzie apigee-validate na serwerze zarządzania, jak pokazano w tym przykładzie:

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

5. Zaktualizuj narzędzie apigee-provision na serwerze zarządzania, jak pokazano w tym przykładzie:

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

6. Uruchom narzędzie update na węzłach w kolejności opisanej w sekcji Kolejność aktualizacji maszyn:

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

   Gdzie:

   • component to komponent Edge, który chcesz zaktualizować. Możliwe wartości:

     • edge : wszystkie komponenty Edge z wyjątkiem nowego interfejsu Edge: serwer zarządzania, procesor komunikatów, router, serwer QPID, serwer Postgres

     • ldap : OpenLDAP

     • ue : nowy interfejs Edge

     • qpid : Apigee Qpid

     • ps : Apigee Postgresql

     • zk : ZooKeeper

     • cs : Cassandra

   • configFile to ten sam plik konfiguracji, który został użyty do zdefiniowania komponentów Edge podczas instalacji wersji 4.53.00 (lub) 4.53.01.

     Uwaga: plik konfiguracji musi być czytelny dla użytkownika „apigee”. Aby zmienić właściciela, użyj tego polecenia:

     chown apigee:apigee configFile

   Możesz uruchomić update.sh we wszystkich komponentach, ustawiając component na „all”, ale tylko wtedy, gdy masz profil instalacji Edge All-in-One (AIO). Na przykład:

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

7. Jeśli jeszcze nie zostało to zrobione, uruchom ponownie komponenty interfejsu na wszystkich węzłach, na których są uruchomione:

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

8. Przetestuj aktualizację, uruchamiając narzędzie apigee-validate na serwerze zarządzania, zgodnie z opisem w sekcji Testowanie instalacji.

Jeśli później zdecydujesz się wycofać aktualizację, wykonaj procedurę opisaną w sekcji Wycofywanie wersji 4.54.00.

Kolejność aktualizacji maszyn

Kolejność aktualizowania maszyn w instalacji Edge jest ważna. Uaktualnij komponenty w podanej niżej kolejności.

1. Uaktualnij wszystkie węzły routera i procesora komunikatów we wszystkich centrach danych, korzystając z opcji -c edge.

2. Uaktualnij wszystkie węzły serwera zarządzającego we wszystkich centrach danych za pomocą opcji -c edge.

3. Uaktualnij wszystkie węzły LDAP we wszystkich centrach danych. Jeśli uaktualniasz Edge dla chmury prywatnej z wersji 4.53.00, musisz wykonać dodatkowe czynności, aby przeprowadzić uaktualnienie LDAP.

4. Zaktualizuj interfejs użytkownika i SSO w Apigee (jeśli jest zainstalowane) we wszystkich centrach danych:

   1. Jeśli apigee-sso nie jest zainstalowany: aby przejść na nowy interfejs Edge, wykonaj czynności opisane w Opcji 1. Uaktualnij interfejs (bez SSO w Apigee).

   2. Jeśli zainstalowano apigee-sso: postępuj zgodnie z instrukcjami w Opcji 2. Uaktualnij interfejs (z SSO w Apigee), aby uaktualnić interfejs New Edge i SSO w Apigee.

5. Zaktualizuj wszystkie komponenty Qpid i edge-qpid-server we wszystkich centrach danych, wykonując specjalne czynności dotyczące Qpid.

6. Uaktualnij wszystkie komponenty Postgresql i edge-postgres-server we wszystkich centrach danych, wykonując specjalne czynności dotyczące Postgres.

7. Zaktualizuj wszystkie komponenty ZooKeeper we wszystkich centrach danych, wykonując specjalne czynności związane z aktualizacją ZooKeeper.

8. Zaktualizuj wszystkie komponenty Cassandra we wszystkich centrach danych, wykonując specjalne czynności związane z uaktualnieniem Cassandra.

9. Nie ma osobnego kroku aktualizacji zarabiania. Jest aktualizowany, gdy określisz opcję -c edge.

Samodzielna licencja na 1 węzeł

Aby uaktualnić samodzielną konfigurację z 1 węzłem do wersji 4.54.00:

W przypadku uaktualniania z Edge dla chmury prywatnej w wersji 4.53.00 należy najpierw uaktualnić LDAP, wykonując czynności uaktualniania z wersji 4.53.00 do wersji 4.54.00, a następnie rozpocząć uaktualnianie wszystkich komponentów.

1. Zaktualizuj wszystkie komponenty:

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

2. (Jeśli masz zainstalowane narzędzie apigee-adminapi) Zaktualizuj narzędzie apigee-adminapi:

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

Samodzielna licencja na 2 węzły

Zaktualizuj te komponenty w przypadku samodzielnej instalacji z 2 węzłami:

Listę topologii Edge i numery węzłów znajdziesz w artykule Topologie instalacji.

1. Zaktualizuj komponenty Edge na maszynie 1:

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

2. Zaktualizuj LDAP na maszynie 1:

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

3. Zaktualizuj nowy interfejs Edge na komputerze 1:

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

4. Zaktualizuj komponenty Edge na maszynie 2:

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

5. Zaktualizuj Qpid na komputerze 2:

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

6. Zaktualizuj Postgres na maszynie 2:

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

7. Zaktualizuj systemy Cassandra i ZooKeeper na maszynie 1:

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

8. (Jeśli masz zainstalowaną wersję apigee-adminapi) Zaktualizuj narzędzie apigee-adminapi na komputerze 1:

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

Uaktualnienie 5 węzłów

Zaktualizuj te komponenty w przypadku instalacji 5-węzłowej:

Listę topologii Edge i numery węzłów znajdziesz w artykule Topologie instalacji.

1. Zaktualizuj komponenty Edge na maszynach 2, 3 i 1:

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

2. Zaktualizuj LDAP na komputerze 1:

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

3. Zaktualizuj nowy interfejs Edge na komputerze 1:

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

4. Zaktualizuj komponenty Edge na maszynach 4 i 5:

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

5. Zaktualizuj Qpid na maszynach 4 i 5:

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

6. Zaktualizuj Postgres na maszynach 4 i 5:

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

7. Zaktualizuj system Cassandra i ZooKeeper na maszynach 1, 2 i 3:

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

8. (Jeśli zainstalowano apigee-adminapi) Zaktualizuj narzędzie apigee-adminapi na komputerze 1:

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

Uaktualnianie klastra 9-węzłowego

Zaktualizuj te komponenty w przypadku instalacji klastrowej z 9 węzłami:

Listę topologii Edge i numery węzłów znajdziesz w artykule Topologie instalacji.

1. Zaktualizuj komponenty Edge na maszynach 4, 5 i 1 (router, procesor komunikatów i serwer zarządzania) w tej kolejności:

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

2. Zaktualizuj LDAP na komputerze 1:

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

3. Zaktualizuj nowy interfejs Edge na komputerze 1:

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

4. Zaktualizuj komponenty Edge na maszynach 6, 7, 8 i 9 w tej kolejności:

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

5. Zaktualizuj Qpid na maszynach 6 i 7:

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

6. Zaktualizuj Postgres na maszynie 8:

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

7. Zaktualizuj Postgres na maszynie 9:

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

8. Zaktualizuj system Cassandra i ZooKeeper na maszynach 1, 2 i 3:

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

9. (Jeśli zainstalowano apigee-adminapi) Zaktualizuj narzędzie apigee-adminapi na komputerze 1:

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

Uaktualnianie klastra składającego się z 13 węzłów

Zaktualizuj te komponenty w przypadku instalacji klastrowej z 13 węzłami:

Listę topologii Edge i numery węzłów znajdziesz w artykule Topologie instalacji.

1. Zaktualizuj komponenty Edge na maszynach 10, 11, 6 i 7 w tej kolejności:

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

2. Zaktualizuj LDAP na maszynach 4 i 5:

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

3. Zaktualizuj nowy interfejs Edge na maszynach 6 i 7:

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

4. Zaktualizuj komponenty Edge na maszynach 12, 13, 8 i 9 w tej kolejności:

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

5. Zaktualizuj Qpid na maszynach 12 i 13:

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

6. Aktualizacja Postgresa na maszynie 8:

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

7. Zaktualizuj Postgres na maszynie 9:

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

8. Zaktualizuj system Cassandra i ZooKeeper na maszynach 1, 2 i 3:

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

9. (Jeśli zainstalowano apigee-adminapi) Zaktualizuj narzędzie apigee-adminapi na maszynach 6 i 7:

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

Uaktualnienie klastra z 12 węzłami

Zaktualizuj te komponenty w przypadku instalacji klastrowej z 12 węzłami:

Listę topologii Edge i numery węzłów znajdziesz w artykule Topologie instalacji.

1. Zaktualizuj komponenty Edge (router i procesor komunikatów):

   • Na maszynach 2 i 3 w centrum danych 1:

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

   • Na maszynach 8 i 9 w centrum danych 2:

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

2. Zaktualizuj komponenty Edge (serwera zarządzającego):

   • Na maszynie 1 w centrum danych 1:

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

   • Na maszynie 7 w centrum danych 2:

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

3. Zaktualizuj LDAP:

   • Maszyna 1 w centrum danych 1:

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

   • Maszyna 7 w centrum danych 2:

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

4. Zaktualizuj komponenty interfejsu New Edge:

   • Na maszynie 1 w centrum danych 1:

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

   • Na maszynie 7 w centrum danych 2:

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

5. Zaktualizuj komponenty Edge:

   • Maszyny 4, 5 i 6 w centrum danych 1:

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

   • Maszyny 10, 11 i 12 w centrum danych 2:

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

6. Aktualizacja qpidd:

   • Maszyny 4 i 5 w centrum danych 1:

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

   • Maszyny 10 i 11 w centrum danych 2:

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

7. Aktualizowanie Postgres:

   • Maszyna 6 w centrum danych 1:

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

   • Maszyna 12 w centrum danych 2:

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

8. Zaktualizuj Cassandrę i ZooKeepera:

   • Maszyny 1, 2 i 3 w centrum danych 1:

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

   • Na komputerach 7, 8 i 9 w centrum danych 2:

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

9. (Jeśli masz zainstalowane narzędzie apigee-adminapi) Zaktualizuj narzędzie apigee-adminapi:

   • Maszyna 1 w centrum danych 1:

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

   • Maszyna 7 w centrum danych 2:

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

Konfiguracja niestandardowa

Jeśli masz konfigurację niestandardową, zaktualizuj komponenty Edge w tej kolejności:

1. Router

2. procesor komunikatów

3. Serwer zarządzania

4. LDAP

5. interfejs (klasyczny lub nowy),

6. SSO (jeśli dotyczy)

7. Qpid i edge-qpid-server

8. Postgres i edge-postgres-server

9. ZooKeeper

10. Cassandra

11. apigee-adminapi