Przywracanie Apigee Edge w wersji 4.53.01

Jeśli podczas aktualizacji do Edge 4.53.01 wystąpi błąd, możesz cofnąć zmianę komponentu, który go spowodował, a potem ponownie spróbować przeprowadzić aktualizację.

Możesz przywrócić Edge w wersji 4.53.01 do dowolnej z tych wersji głównych:

  • Wersja 4.53.00
  • Wersja 4.52.02

Cofnięcie wersji polega na cofnięciu wszystkich komponentów, które mogły zostać uaktualnione. Dodatkowo w zależności od wersji, od której zaczynasz, przed wycofaniem niektórych komponentów oprogramowania może być konieczne wykonanie specjalnych czynności. W poniższej tabeli znajdziesz listę różnych komponentów oprogramowania, w przypadku których podczas wycofywania zmian mogą być potrzebne specjalne działania:

Przywróć wersję Specjalne uwagi dotyczące oprogramowania
4.53.00 Zookeeper, Postgres, LDAP
4.52.02 Zookeeper, Cassandra, Postgres, LDAP

Oto scenariusz, w którym możesz chcieć cofnąć zmiany:

Przywróć poprzednią wersję główną lub pomocniczą. Na przykład z 4.53.01 na 4.53.00.

Więcej informacji znajdziesz w artykule Proces wydawania wersji Apigee Edge.

Kolejność wycofywania

Przywracanie poprzedniej wersji komponentów powinno odbywać się w odwrotnej kolejności niż uaktualnianie, z wyjątkiem serwerów zarządzających, które należy przywrócić po bazie danych Cassandra. Typowa ogólna kolejność wycofywania zmian w przypadku chmury prywatnej w wersji 4.53.01 wygląda tak:

  1. Wycofaj Qpid, inne komponenty związane z analityką i Postgres.
  2. Przywracanie routerów i procesorów wiadomości
  3. Cofanie zmian w przypadku Cassandra i Zookeeper
  4. Serwer zarządzania wycofywaniem
  5. Przywracanie LDAP

Załóżmy na przykład, że cały klaster Cassandra, wszystkie serwery zarządzające i kilka modułów RMP zostało uaktualnionych z wersji 4.52.02 do wersji 4.53.01 i chcesz przywrócić poprzednią wersję. W takim przypadku:

  • Cofanie wszystkich RMP pojedynczo
  • Przywracanie całego klastra Cassandra za pomocą kopii zapasowych
  • Przywracanie węzłów serwera zarządzania brzegowego pojedynczo

Kto może cofnąć zmiany

Użytkownik, który przywraca poprzednią wersję, powinien być tym samym użytkownikiem, który pierwotnie zaktualizował Edge, lub użytkownikiem działającym jako root.

Domyślnie komponenty Edge działają jako użytkownik „apigee”. W niektórych przypadkach komponenty Edge mogą być uruchamiane przez różnych użytkowników. Jeśli np. router musi mieć dostęp do portów uprzywilejowanych, takich jak porty poniżej 1000, musisz uruchomić go jako roota lub jako użytkownika z dostępem do tych portów. Możesz też uruchomić jeden komponent jako jeden użytkownik, a inny komponent jako inny użytkownik.

Komponenty ze wspólnym kodem

Te komponenty Edge korzystają ze wspólnego kodu. Dlatego, aby wycofać dowolny z tych komponentów na węźle, musisz wycofać wszystkie komponenty znajdujące się na tym węźle.

  • edge-management-server (serwer zarządzający)
  • edge-message-processor (procesor komunikatów)
  • edge-router (router)
  • edge-postgres-server (serwer Postgres)
  • edge-qpid-server (serwer Qpid)

Jeśli na przykład na węźle masz zainstalowane serwer zarządzający, router i procesor wiadomości, aby cofnąć zmiany w jednym z nich, musisz cofnąć zmiany we wszystkich trzech.

Wycofanie zmian w Cassandrze

Gdy na konkretnym węźle przeprowadzana jest główna aktualizacja Cassandry, modyfikuje ona schemat danych przechowywanych na tym węźle. W związku z tym bezpośrednie przywrócenie w miejscu nie jest możliwe.

Scenariusze wycofywania

Cassandra 4.0.X, dostępna w Edge for Private Cloud 4.53.01, jest zgodna z innymi komponentami Private Cloud 4.52.02.

W tabeli poniżej znajdziesz podsumowanie różnych strategii wycofywania zmian, których możesz użyć:

Scenariusz Strategia wycofywania
Pojedyncze centrum danych, niektóre węzły Cassandra zostały uaktualnione Korzystanie z kopii zapasowych
Pojedyncze centrum danych, wszystkie węzły Cassandra uaktualnione Nie przywracaj poprzedniej wersji Cassandra. Inne komponenty można przywrócić.
Pojedyncze centrum danych, wszystkie węzły (Cassandra i inne) uaktualnione Nie przywracaj poprzedniej wersji Cassandra. Inne komponenty można przywrócić.
Wiele centrów danych, niektóre węzły w jednym centrum danych zostały zaktualizowane Odtwórz z istniejącego DC
Wiele centrów danych, wszystkie węzły Cassandra w niektórych centrach danych zostały uaktualnione Odtwórz z istniejącego DC
Wiele centrów danych, węzły Cassandra ostatniego centrum danych są uaktualniane Spróbuj dokończyć uaktualnianie. Jeśli to niemożliwe, przywróć 1 centrum danych z kopii zapasowej. Odbuduj pozostałe kontrolery domeny z wycofanego kontrolera domeny.
Wiele centrów danych, wszystkie węzły Cassandra zaktualizowane Nie przywracaj poprzedniej wersji Cassandra. Inne komponenty można przywrócić.
Wiele centrów danych, wszystkie węzły (Cassandra i inne) zaktualizowane Nie przywracaj poprzedniej wersji Cassandra. Inne komponenty można przywrócić.

Uwagi ogólne

Jeśli rozważasz wycofanie zmian, pamiętaj o tych kwestiach:

  • Cofanie zmian w komponentach środowiska wykonawczego lub zarządzania: jeśli chcesz cofnąć zmiany w komponentach takich jak edge-management-server, edge-message-processor lub dowolny komponent inny niż Cassandra do wersji chmury prywatnej 4.52.02, nie cofaj zmian w Cassandrze. Cassandra dostarczana z chmurą prywatną w wersji 4.53.00 jest zgodna ze wszystkimi komponentami Edge for Private Cloud w wersji 4.52.02, które nie są komponentami Cassandra. Możesz wycofać komponenty inne niż Cassandra, korzystając z metodologii podanej tutaj, podczas gdy Cassandra pozostanie w wersji 4.0.13.
  • Wycofanie zmian po uaktualnieniu całego klastra Cassandra do wersji 4.0.X: jeśli cały klaster Cassandra zostanie uaktualniony do wersji 4.0.X w ramach uaktualnienia do wersji 4.53.00 chmury prywatnej, zalecamy kontynuowanie konfiguracji tego klastra i NIE wycofywanie zmian w Cassandrze. Komponenty takie jak edge-management-server, edge-message-processor, edge-router itp. w wersji 4.52.02 chmury prywatnej są zgodne z Cassandrą w wersji 4.0.X.
  • Cofanie zmian w Cassandrze podczas jej uaktualniania: jeśli podczas uaktualniania Cassandry napotkasz problemy, możesz rozważyć cofnięcie zmian. Strategie wycofywania zmian wymienione w tym artykule można stosować w zależności od stanu, w jakim znajduje się proces uaktualniania.
  • Cofanie zmian za pomocą kopii zapasowych: kopie zapasowe utworzone w Cassandrze 4.0.X nie są zgodne z kopiami zapasowymi Cassandry 3.11.X. Aby cofnąć zmiany w Cassandrze za pomocą przywracania kopii zapasowej, przed rozpoczęciem uaktualniania musisz utworzyć kopie zapasowe Cassandry 3.11.X.

Przywracanie Cassandra za pomocą ponownego tworzenia

Wymagania wstępne

  • Używasz klastra Edge for Private Cloud w wersji 4.52.02 w wielu centrach danych.
  • Uaktualniasz bazę danych Cassandra z wersji 3.11.X do 4.0.X i napotykasz problemy.
  • W klastrze masz co najmniej 1 w pełni funkcjonalne centrum danych, które nadal działa w starszej wersji Cassandry (Cassandra 3.11.X).

Ta procedura opiera się na przesyłaniu strumieniowym danych z istniejącego centrum danych. Może to zająć sporo czasu, w zależności od ilości danych przechowywanych w Cassandrze. Podczas wycofywania zmian musisz być gotowy na przekierowanie ruchu środowiska wykonawczego z tego centrum danych.

Najważniejsze kroki

  1. Wybierz jedno centrum danych (częściowo lub w pełni zaktualizowane), do którego chcesz przywrócić poprzednią wersję. Przekierowywanie ruchu w czasie działania do innego działającego centrum danych.
  2. Określ węzeł początkowy w centrum danych i zacznij od jednego z węzłów początkowych.
  3. Zatrzymaj, odinstaluj i wyczyść węzeł Cassandra.
  4. Zainstaluj starszą wersję Cassandra na węźle i skonfiguruj ją w razie potrzeby.
  5. Usuń dodatkowe konfiguracje dodane wcześniej.
  6. Powtórz powyższe kroki w przypadku wszystkich węzłów początkowych w centrum danych, jeden po drugim.
  7. Powtórz powyższe kroki w przypadku wszystkich pozostałych węzłów Cassandra w centrum danych, jeden po drugim.
  8. Odtwórz węzły z istniejącego, działającego centrum danych, jeden po drugim.
  9. Uruchom ponownie wszystkie komponenty edge-* w centrum danych, które są połączone z Cassandrą.
  10. Przeprowadź test i przekieruj ruch z powrotem do tego centrum danych.
  11. Powtórz te czynności w przypadku każdego centrum danych, po kolei.

Szczegółowe instrukcje

  1. Wybierz jedno centrum danych, w którym wszystkie lub niektóre węzły Cassandra zostaną uaktualnione. Przekieruj cały ruch związany z proxy w czasie działania i ruch związany z zarządzaniem z tego centrum danych, gdy węzły Cassandra w tym centrum danych są wycofywane. Sprawdź, czy wszystkie węzły Cassandra są w stanie UN (Up/Normal), gdy na węzłach zostanie wykonane polecenie nodetool ring. Jeśli niektóre węzły nie działają, rozwiąż problem i przywróć je przed kontynuowaniem.

    Zobacz ten przykład:

    /opt/apigee/apigee-cassandra/bin/nodetool status
Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC1-1IP1  456.41 KiB  1            100.0%            78fc4ddd-2ed9-4a8c-98a2-63a38c2f1920  ra-1
UN  DC1-1IP2  870.93 KiB  1            100.0%            160db01a-64ab-43a7-b9ea-3b7f8f66d52b  ra-1
UN  DC1-1IP3  824.08 KiB  1            100.0%            21d61543-d59e-403a-bf5d-bfe7f664baa6  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC2-1IP1   802.08 KiB  1            100.0%            583e0576-336d-4ce7-9729-2ae74e0abde2  ra-1
UN  DC2-1IP2   844.4 KiB   1            100.0%            fef794d5-f4c2-4a4e-bb05-9adaeb4aea4b  ra-1
UN  DC2-1IP3   878.12 KiB  1            100.0%            3894b3d9-1f5a-444d-83db-7b1e338bbfc9  ra-1

    Aby sprawdzić bieżący stan całego klastra, możesz uruchomić na węzłach polecenie nodetool describecluster. Na przykład poniżej przedstawiamy instancję klastra z 2 centrami danych, w którym wszystkie węzły DC-1 działają w wersji 4 Cassandry, a wszystkie węzły DC-2 – w wersji 3:

    # On nodes where Cassandra is upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]

Stats for all nodes:
    Live: 6
    Joining: 0
    Moving: 0
    Leaving: 0
    Unreachable: 0

Data Centers:
    dc-1 #Nodes: 3 #Down: 0
    dc-2 #Nodes: 3 #Down: 0

Database versions:
    4.0.13: [DC-1-IP1:7000, DC-1-IP2:7000, DC-1-IP3:7000]
    3.11.16: [DC-2-IP1:7000, DC-2-IP2:7000, DC-2-IP3:7000]

Keyspaces:
    system_schema -> Replication class: LocalStrategy {}
    system -> Replication class: LocalStrategy {}
    auth -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    cache -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    devconnect -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    dek -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    user_settings -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apprepo -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    kms -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    identityzone -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    audit -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    analytics -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    keyvaluemap -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    counter -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apimodel_v2 -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    system_distributed -> Replication class: SimpleStrategy {replication_factor=3}
    system_traces -> Replication class: SimpleStrategy {replication_factor=2}
    system_auth -> Replication class: SimpleStrategy {replication_factor=1}

# On nodes where Cassandra is not upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]
  2. Określ węzły początkowe w centrum danych: zapoznaj się z sekcją Jak określić węzły początkowe w dodatku. Wykonaj poniższe czynności na jednym z węzłów początkowych:
  3. Zatrzymaj, odinstaluj i wyczyść dane z węzła Cassandra. Wybierz pierwszy węzeł początkowy w Cassandrze w wersji 4 w tym centrum danych. Przestań. 
    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe out Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra
  4. Zainstaluj na węźle starsze oprogramowanie Cassandra i skonfiguruj niektóre ustawienia. Uruchom plik bootstrap Edge for Private Cloud 4.52.02. 
    5. # Download bootstrap of 4.52.02
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u uName:pWord

# Execute bootstrap of 4.52.02
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
  5. Utwórz lub edytuj plik /opt/apigee/customer/application/cassandra.properties.
  6. Dodaj do pliku te wiersze: ipOfNode to adres IP węzła, którego Cassandra używa do komunikacji z innymi węzłami Cassandra: 
    conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
  7. Sprawdź, czy plik jest własnością użytkownika apigee i czy ma on do niego dostęp do odczytu: 
    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  8. Zainstaluj i skonfiguruj Cassandrę:
    9. # Install cassandra version 3.11.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install
# Setup cassandra while passing standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile
# Ensure Cassandra version is correct and service is running
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status
  9. Sprawdź, czy węzeł został uruchomiony. Sprawdź to polecenie w tym węźle i innych węzłach w klastrze. Węzeł powinien zgłosić stan „UN” (Up/Normal): 
    /opt/apigee/apigee-cassandra/bin/nodetool status
  10. Usuń z pliku /opt/apigee/customer/application/cassandra.properties dodatkowe konfiguracje dodane wcześniej.
  11. Powtórz kroki od 3 do 10 na wszystkich węzłach początkowych Cassandry w centrum danych, jeden po drugim.
  12. Powtórz kroki 3–10 na wszystkich pozostałych węzłach Cassandra w centrum danych, jeden po drugim.
  13. Odtwórz wszystkie węzły w centrum danych z centrum danych, w którym działa starsza wersja Cassandry. Wykonaj ten krok na każdym węźle z osobna: 
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>

    Ta procedura może zająć trochę czasu. W razie potrzeby możesz dostosować streamingthroughput. Sprawdź nodetool netstats, aby poznać stan zakończenia operacji.

  14. (Opcjonalnie) Jeśli dane nie są odbudowywane, wykonaj polecenie naprawy w węźle Cassandra. 
    /opt/apigee/apigee-cassandra/bin/nodetool -h node-IP repair -pr
  15. Uruchom ponownie wszystkie komponenty edge-* w centrum danych, jeden po drugim: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  16. Sprawdź i przekieruj ruch z powrotem do tego centrum danych. Przeprowadź w tym centrum danych weryfikację ruchu w czasie działania i interfejsów API do zarządzania, a następnie zacznij przekierowywać do niego ruch serwera proxy i interfejsu API do zarządzania.
  17. Powtórz powyższe kroki dla każdego centrum danych, w którym chcesz cofnąć zmiany.

Przywracanie bazy danych Cassandra za pomocą kopii zapasowej

Wymagania wstępne

  1. Uaktualniasz bazę danych Cassandra z wersji 3.11.X do 4.0.X i napotykasz problemy.
  2. Masz kopie zapasowe węzła, który chcesz przywrócić. Kopia zapasowa została utworzona przed próbą uaktualnienia z wersji 3.11.X do 4.0.X.

Kroki

  1. Wybierz węzeł, do którego chcesz przywrócić poprzednią wersję. Jeśli przywracasz wszystkie węzły w centrum danych za pomocą kopii zapasowych, zacznij od węzłów początkowych. W dodatku znajdziesz sekcję „Jak identyfikować węzły początkowe”.

  2. Zatrzymaj, odinstaluj i wyczyść węzeł Cassandra:

    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra

  3. Zainstaluj starsze oprogramowanie Cassandra na węźle i skonfiguruj je:

    • Uruchom plik bootstrap dla Edge for Private Cloud w wersji 4.52.02:
      • # Download bootstrap for 4.52.02
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u ‘uName:pWord’

# Execute bootstrap for 4.52.02
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
    • Utwórz lub edytuj plik /opt/apigee/customer/application/cassandra.properties:
      • conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
    • Sprawdź, czy plik należy do użytkownika apigee i czy można go odczytać:
      • chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    • Zainstaluj i skonfiguruj Cassandrę:
      • # Install Cassandra version 3.11.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install

# Set up Cassandra with the standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile

# Verify Cassandra version and check service status
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status

    Sprawdź, czy węzeł został uruchomiony. Sprawdź to polecenie w tym węźle i innych węzłach w klastrze. Węzły powinny zgłaszać, że ten węzeł jest w stanie „UN”:

    /opt/apigee/apigee-cassandra/bin/nodetool status

  4. Zatrzymaj usługę Cassandra i przywróć kopię zapasową. Więcej informacji znajdziesz w dokumentacji dotyczącej tworzenia i przywracania kopii zapasowych:

    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Wipe the data directory in preparation for restore
rm -rf /opt/apigee/data/apigee-cassandra/data

# Restore the backup taken before the upgrade attempt
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backupFile

  5. Po przywróceniu kopii zapasowej usuń dodatkowe konfiguracje:

    Usuń z pliku /opt/apigee/customer/application/cassandra.properties konfigurację dodaną wcześniej.

  6. Uruchom usługę Cassandra w węźle:

    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start

  7. Powtórz te czynności na każdym węźle Cassandra, który chcesz przywrócić za pomocą kopii zapasowych, po kolei.

  8. Po przywróceniu wszystkich węzłów Cassandra uruchom ponownie wszystkie komponenty edge-* jeden po drugim:

    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart

Optymalizacje kopii zapasowej (opcja zaawansowana)

Podczas przywracania kopii zapasowych możesz zminimalizować (lub wyeliminować) utratę danych, jeśli masz dostępne repliki zawierające najnowsze dane. Jeśli repliki są dostępne, po przywróceniu kopii zapasowej uruchom naprawę węzła, który został przywrócony.

Dodatek

Jak identyfikować węzły początkowe

Na dowolnym węźle Cassandra w centrum danych uruchom to polecenie:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure -search conf_cassandra_seeds

Polecenie wygeneruje wiele wierszy. Sprawdź ostatni wiersz danych wyjściowych. Adresy IP wymienione w ostatnim wierszu to węzły początkowe. W przykładzie poniżej adresy IP węzłów początkowych to DC-1-IP1, DC-1-IP2, DC-2-IP1 i DC-2-IP2:

Found key conf_cassandra_seeds, with value, "127.0.0.1", in /opt/apigee/apigee-cassandra/token/default.properties

Found key conf_cassandra_seeds, with value, 127.0.0.1, in /opt/apigee/apigee-cassandra/token/application/cassandra.properties

Found key conf_cassandra_seeds, with value, "DC-1-IP1, DC-1-IP2, DC-2-IP1, DC-2-IP2", in /opt/apigee/token/application/cassandra.properties
apigee-configutil: apigee-cassandra: # OK

Cofanie aktualizacji Zookeepera do wersji 3.8.4

Przywróć

W przypadku konieczności wycofania zmian:

  1. Najpierw cofnij zmiany u obserwujących i osób obserwujących.
  2. Pobierz i uruchom program rozruchowy wersji, do której chcesz wrócić – 4.52.02 lub 4.53.00. 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 w trybie offline.
  3. Zatrzymaj Zookeepera, jeśli działa na węźle: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop
  4. Odinstaluj istniejący serwer Zookeeper: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper uninstall
  5. Zainstaluj Zookeepera w zwykły sposób: 
      /opt/apigee/apigee-setup/bin/setup.sh -p zk -f <silent-config-file>
  6. Po przywróceniu wszystkich węzłów podrzędnych i obserwatorów przywróć węzeł główny, wykonując kroki 2–5 na węźle głównym.
  7. Po przywróceniu wszystkich węzłów sprawdź stan klastra i upewnij się, że w klastrze jest węzeł lidera.

Przywróć kopię zapasową

Zapoznaj się z sekcją Przywracanie z kopii zapasowej. Pamiętaj, że kopie zapasowe Zookeepera utworzone w starszych wersjach Edge for Private Cloud, takich jak 4.52.02 lub 4.53.00, powinny być zgodne z wersją Zookeepera w Edge for Private Cloud 4.53.01.

Cofanie aktualizacji Postgres 17

Jeśli wersja 4.53.01 została zainstalowana z wersji 4.52.02 lub 4.53.00, musisz wycofać aktualizację Postgresa oraz komponenty Edge.

Aby cofnąć aktualizację Postgresa podczas aktualizowania Postgresa w konfiguracji master-standby:

  • Promuj nowy węzeł rezerwowy, aby stał się węzłem głównym Postgres. Nowa instancja główna Postgres będzie w tej samej wersji co poprzednia instalacja Edge.
  • Skonfiguruj stary węzeł rezerwowy jako węzeł rezerwowy nowego węzła głównego. Stary węzeł rezerwowy będzie miał tę samą wersję co poprzednia instalacja Edge.
  • Zarejestruj nowe węzły główne i węzły rezerwowe w grupach analitycznych i konsumenckich.

Po zakończeniu wycofywania stary węzeł główny nie będzie już potrzebny. Następnie możesz wyłączyć stary węzeł główny.

Zanim zaczniesz

Zanim przywrócisz Postgresa 17 do wersji 14, wykonaj te czynności na nowym i starym hostach rezerwowych, aby zaktualizować właściwość max_locks_per_transaction na apigee-postgresql:

  1. Jeśli nie ma pliku /opt/apigee/customer/application/postgresql.properties, utwórz go.
  2. Zmień własność tego pliku na apigee: 
    sudo 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
  1. Sprawdź, czy nowy węzeł Postgres w trybie gotowości jest uruchomiony: 
    /opt/apigee/apigee-service/bin/apigee-all status

    Jeśli Postgres nie jest uruchomiony, uruchom go:

    /opt/apigee/apigee-service/bin/apigee-all start
  2. Sprawdź, czy Postgres jest zatrzymany na starym węźle głównym i starym węźle rezerwowym: 
    /opt/apigee/apigee-service/bin/apigee-all status

    Jeśli Postgres jest uruchomiony, zatrzymaj go: 

    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop  
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop
  3. Jeśli jest zainstalowany, uruchom Qpid na starym węźle rezerwowym: 
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
  4. Promuj nowy węzeł rezerwowy jako węzeł główny Postgres:
    1. Promuj nowy węzeł rezerwowy, aby stał się nowym węzłem głównym: 
      apigee-service apigee-postgresql promote-standby-to-master old_master_IP

      Gdy pojawi się prośba, wpisz hasło Postgres użytkownika „apigee”, które domyślnie ma wartość „postgres”.

    2. Edytuj plik konfiguracyjny, którego użyto do zainstalowania bieżącej wersji Edge, aby określić: 
      # IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
    3. Skonfiguruj nowy element nadrzędny:
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFile
  5. Jeśli stary węzeł rezerwowy został już uaktualniony do nowszej wersji, musisz najpierw przywrócić starszą wersję oprogramowania Apigee na tym węźle. Jeśli na starym węźle rezerwowym nadal masz starszą wersję, możesz pominąć ten krok i przejść do kroku 6.
    1. Zatrzymaj Postgres na starym węźle rezerwowym: 
      apigee-service apigee-postgresql stop
apigee-service edge-postgres-server stop
    2. Odinstaluj Postgres ze starego węzła rezerwowego: 
      apigee-service apigee-postgresql uninstall
apigee-service edge-postgres-server uninstall
    3. Usuń katalog danych Postgres ze starego węzła rezerwowego: 
      cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
    4. Pobierz i uruchom starszą wersję programu bootstrap (odpowiadającą wersji Apigee, do której chcesz wrócić) na starym węźle rezerwowym. Konkretne czynności mogą się różnić w zależności od tego, czy instalacja jest przeprowadzana przez internet, czy offline. Uruchomienie starszej wersji programu Apigee bootstrap spowoduje skonfigurowanie repozytoriów yum ze starszą wersją danych Apigee.
    5. Skonfiguruj komponenty Postgres na starym węźle rezerwowym: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
    6. Sprawdź, czy komponenty Postgres na starym węźle rezerwowym zostały przywrócone do starszej wersji: 
      apigee-service apigee-postgresql version
apigee-service edge-postgres-server version
  6. Odbuduj stary węzeł rezerwowy:
    1. Edytuj plik konfiguracyjny, którego użyto do zainstalowania bieżącej wersji Edge, aby określić: 
      # IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
    2. Usuń katalog danych na starym węźle rezerwowym: 
      cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
    3. Zmień konfigurację starego węzła rezerwowego, aby był węzłem rezerwowym nowego węzła głównego: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
    4. Sprawdź, czy Postgres działa na starym węźle rezerwowym: 
      /opt/apigee/apigee-service/bin/apigee-all status

      Jeśli Postgres nie jest uruchomiony, uruchom go:

      /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server start
  7. Sprawdź, czy nowy węzeł rezerwowy został dodany, wyświetlając plik /opt/apigee/apigee-postgresql/conf/pg_hba.conf na nowym węźle głównym.
  8. Aby wyświetlić bieżące informacje o analityce i grupie konsumenckiej, uruchom to polecenie na serwerze zarządzającym: 
    curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

    To polecenie zwraca nazwę grupy analitycznej w polu name i nazwę grupy odbiorców w polu name w sekcji consumer-groups. Zwraca też identyfikatory UUID starych węzłów głównych i rezerwowych Postgres w polu postgres-server i w polu datastores. Powinny się wyświetlić dane wyjściowe w formacie: 

    {
  "name" : "axgroup-001",
  "properties" : {
  },
  "scopes" : [ "VALIDATE~test", "sgilson~prod" ],
  "uuids" : {
    "qpid-server" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
    "postgres-server" : [
      "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256"
    ]
  },
  "consumer-groups" : [ {
    "name" : "consumer-group-001",
    "consumers" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
    "datastores" :
      [ "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256" ],
      "properties" : {     }
    }
  ],
  "data-processors" : {
  }
}
  9. Pobierz adres UUID starego węzła głównego, uruchamiając to polecenie curl na starym węźle głównym: 
    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"
  10. Powtórz poprzedni krok, aby uzyskać adresy IP starego węzła rezerwowego i nowego węzła głównego.
  11. Usuń stare węzły główne i rezerwowe z grupy odbiorców: 
    curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/datastores/masterUUID,standbyUUID" -v

    gdzie axgroup-001 i consumer-group-001 to domyślne nazwy grup analitycznych i konsumenckich. masterUUID,standbyUUID są w tej samej kolejności, w jakiej pojawiły się powyżej, gdy wyświetlałeś(-aś) aktualne informacje o analityce i grupach konsumentów. Może być konieczne podanie ich jako standbyUUID,masterUUID.

    Właściwość datastores dla consumer-groups powinna być teraz pusta.

  12. Usuń stare węzły główne i węzły rezerwowe z grupy analitycznej: 
    curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v

    Właściwość postgres-server w sekcji uuids powinna być teraz pusta.

  13. Zarejestruj nowe węzły główne i rezerwowe PG w grupach analitycznych i konsumenckich:
    curl -u sysAdminEmail:password -X POST -H "Content-Type: application/json" -d ''
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v
curl -u sysAdminEmail:password -X POST -H "Content-Type:application/json" -d ''
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/datastores?uuid=masterUUID,standbyUUID" -v
  14. Sprawdź grupę w Statystykach: 
    curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

    W grupie analitycznej i grupie odbiorców powinny być widoczne identyfikatory UUID nowych węzłów głównych i węzłów rezerwowych.

  15. Ponownie uruchom serwer zarządzania Edge: 
    /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
  16. Ponownie uruchom wszystkie serwery Qpid: 
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
  17. Ponownie uruchom wszystkie serwery Postgres: 
    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  18. Sprawdź stan replikacji, wykonując na obu serwerach te skrypty: Aby zapewnić prawidłową replikację, system powinien wyświetlać identyczne wyniki na obu serwerach:

    Na nowym serwerze głównym uruchom:

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

    Sprawdź, czy jest to master. Na starym węźle rezerwowym: 

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

    Sprawdź, czy jest w trybie gotowości.

  19. Powtórz poprzedni krok po wysłaniu kilku żądań do interfejsu API, aby upewnić się, że węzły są zsynchronizowane.
  20. Wyłącz starego głównego węzła Postgresa, wykonując procedurę opisaną w artykule Wyłączanie węzła Postgres.

    Możesz też odinstalować Qpid na starym węźle głównym i zainstalować go na nowym węźle głównym. Po odinstalowaniu Qpid możesz wycofać stary węzeł główny.

Cofanie aktualizacji LDAP 2.6

W tej sekcji znajdziesz szczegółowy przewodnik krok po kroku dotyczący przywracania poprzedniej wersji LDAP. Wycofanie zmian musi zostać przeprowadzone w całym klastrze LDAP i jest możliwe tylko przy użyciu prawidłowej kopii zapasowej LDAP sprzed uaktualnienia.

Głównym celem jest przywrócenie całego klastra LDAP do spójnego stanu z znanej, dobrej kopii zapasowej. Ta procedura jest taka sama we wszystkich scenariuszach: pojedynczy serwer, aktywny-aktywny i aktywny-pasywny.

Wymagania wstępne i kwestie do rozważenia

  • Niezgodność kopii zapasowej: użyj kopii zapasowej ze starszej wersji LDAP 2.4, która była używana w Edge for Private Cloud w wersji 4.52.02 lub 4.53.00. Kopia zapasowa musi zostać utworzona przed podjęciem próby uaktualnienia. Kopie zapasowe utworzone po uaktualnieniu są niezgodne i nie można ich używać.
  • Przerwa w działaniu interfejsu Management API: podczas wycofywania LDAP interfejsy Management API będą niedostępne, co może mieć wpływ na zadania administracyjne. Zanim przejdziesz dalej z wycofywaniem LDAP, wyłącz wszystkie serwery zarządzania brzegowego i interfejsy brzegowe.
  • Ryzyko utraty danych: kontynuowanie bez prawidłowej, zgodnej kopii zapasowej wiąże się z ryzykiem nieodwracalnej utraty danych.
  • Prawidłowa kopia zapasowa: wymagana jest prawidłowa kopia zapasowa LDAP sprzed uaktualnienia.

Procedura wycofania

  1. Zanim przejdziesz dalej z uaktualnianiem LDAP, wyłącz wszystkie serwery zarządzania brzegowego i interfejs brzegowy. 
    apigee-service edge-management-server stop
apigee-service edge-ui stop
  2. Utwórz kopię zapasową istniejących danych LDAP (przed zatrzymaniem LDAP)

    Uzyskaj łączną liczbę rekordów ze wszystkich serwerów LDAP. (Liczba rekordów powinna być taka sama na wszystkich serwerach LDAP).

          # 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. Zatrzymywanie i odinstalowywanie nowego LDAP w wersji 2.6

    Zatrzymaj usługę apigee-openldap i usuń jej katalogi konfiguracji i danych. Aby zapewnić spójność, tę czynność należy wykonać na wszystkich serwerach LDAP, po jednym węźle w klastrze.

    apigee-service apigee-openldap stop
apigee-service apigee-openldap uninstall
rm -rf /opt/apigee/data/apigee-openldap/*
  4. Zainstaluj starszą wersję LDAP 2.4
    • Zainstaluj starą wersję LDAP: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ld -f /opt/silent.conf
    • Sprawdź wersję LDAP: 
      source ~/.bash_profile
ldapsearch -VV

#Expected output:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.46
    • Powtórz powyższe kroki na każdym węźle LDAP, po kolei
  5. Usuwanie danych resztkowych

    Na wszystkich serwerach LDAP po kolei zatrzymaj nowo zainstalowaną usługę i wyczyść jej katalog danych, aby przygotować się do przywrócenia z kopii zapasowej.

    apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/*
  6. Przywracanie danych LDAP

    W przypadku konfiguracji na jednym serwerze możesz przejść bezpośrednio do kroku 5b. W przypadku konfiguracji wielu serwerów przejdź do kroku 5a.

    1. Określanie aktywnego serwera LDAP

      Przed przywróceniem danych LDAP zidentyfikuj aktywny serwer (dostawcę), uruchamiając to polecenie.

      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. Przywróć dane LDAP (przed przywróceniem upewnij się, że krok 4 został wykonany na wszystkich serwerach).
      • Na pojedynczym i aktywnym serwerze LDAP (określonym w kroku 5a) przywróć kopię zapasową. 
        cd /opt/apigee/backup/openldap

# To restore a specific backup, provide the timestamp as shown below:
apigee-service apigee-openldap restore 2025.07.28,13.59.00
# Note: If no timestamp is provided, the latest available backup will be restored by default.
apigee-service apigee-openldap restore

# It is recommended to specify the backup explicitly to avoid restoring an unintended version.
      • Uruchom usługę apigee-openldap. 
        apigee-service apigee-openldap start
  7. Uruchamianie pozostałych serwerów LDAP

    Jeśli masz konfigurację z wieloma serwerami, na każdym z serwerów LDAP uruchom usługę:

    apigee-service apigee-openldap start
  8. Weryfikacja końcowa
    • Ostatnim krokiem jest sprawdzenie, czy wycofanie zmian zakończyło się powodzeniem i czy dane są spójne w całym klastrze LDAP.
    • Uruchom polecenie weryfikacji na wszystkich serwerach LDAP. Liczba rekordów powinna być identyczna na wszystkich serwerach i musi być zgodna z liczbą zarejestrowaną w kroku 1. 
      # 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
    • Gdy potwierdzisz, że dane są prawidłowe i spójne, przywracanie LDAP zostanie zakończone. Możesz teraz uruchomić edge-management-server, edge-ui i inne komponenty zależne zgodnie ze standardową procedurą aktualizacji w Twojej organizacji.

Cofanie do poprzedniej wersji głównej lub pomocniczej

Aby przywrócić poprzednią wersję główną lub pomocniczą, wykonaj te czynności na każdym węźle, który hostuje komponent:

  1. Pobierz plik bootstrap.sh dla wersji, do której chcesz wrócić:

    • Aby przywrócić wersję 4.52.02, pobierz bootstrap_4.52.02.sh
  2. Zatrzymaj komponent, aby przywrócić poprzednią wersję:
    1. Aby wycofać dowolny z komponentów ze wspólnym kodem w węźle, musisz zatrzymać wszystkie komponenty, jak pokazano w tym przykładzie: 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-router stop
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor stop
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop
    2. Aby wycofać inny komponent na węźle, zatrzymaj tylko ten komponent: 
      /opt/apigee/apigee-service/bin/apigee-service component stop
  3. Jeśli wycofujesz Monetization, odinstaluj ją ze wszystkich serwerów zarządzania i węzłów Message Processor: 
    /opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
  4. Odinstaluj komponent, aby przywrócić poprzednią wersję węzła:
    1. Aby wycofać dowolny z komponentów ze wspólnym kodem na węźle, musisz odinstalować je wszystkie, odinstalowując grupę komponentów edge-gateway i apigee-cassandra-client, jak pokazano w tym przykładzie: 
      /opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
       
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall
    2. Aby wycofać Nginx, wykonaj te czynności: 
      ###Find the apigee-nginx RPM 
rpm -qa | grep -i "apigee-nginx"

###Remove the apigee-nginx RPM
dnf remove apigee-nginx-1.26.x
    3. Aby wycofać zmiany w dowolnym innym komponencie na węźle, odinstaluj tylko ten komponent, jak pokazano w tym przykładzie: 
      /opt/apigee/apigee-service/bin/apigee-service component uninstall

      Gdzie component to nazwa komponentu.

    4. Aby wycofać zmiany w routerze brzegowym, musisz usunąć zawartość pliku /opt/nginx/conf.d oraz odinstalować grupę komponentów edge-gateway: 
      cd /opt/nginx/conf.d
rm -rf *
  5. Odinstaluj apigee-setup w wersji 4.53.01: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
  6. Zainstaluj wersję 4.52.02 narzędzia apigee-service i jego zależności. W tym przykładzie instalowana jest wersja 4.52.02 aplikacji apigee-service: 
    sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

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

    Jeśli wystąpi błąd, upewnij się, że w kroku 1 pobrano plik bootstrap.sh.

  7. Zainstaluj apigee-setup: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  8. Zainstaluj starszą wersję komponentu: 
    /opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile

    gdzie component to komponent do zainstalowania, a configFile to plik konfiguracji starszej wersji.

  9. Jeśli wycofujesz Qpid, wyczyść iptables: 
    sudo iptables -F
  10. Powtórz ten proces dla każdego węzła, który hostuje komponent, do którego chcesz przywrócić poprzednią wersję.

Wycofywanie zmian mTLS

Aby wycofać aktualizację mTLS, wykonaj te czynności na wszystkich hostach:

  1. Zatrzymaj Apigee: 
    apigee-all stop
  2. Zatrzymywanie mTLS: 
    apigee-service apigee-mtls uninstall
  3. Ponownie zainstaluj mTLS: 
    apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf