4.17.05 Przywracanie poprzedniej wersji

Edge for Private Cloud wer. 4.17.05

W przypadku błędu podczas aktualizacji do Edge 4.17.05 możesz przywrócić komponent, który spowodował błąd, a następnie ponowić próbę aktualizacji. Jeśli na przykład aktualizacja do Postgres 9.4 nie powiedzie się, możesz wycofać zmiany tylko w węzłach Postgres i spróbować ponownie.

Są 2 sytuacje, w których warto przeprowadzić przywrócenie:

  1. Przywróć starszą wersję. Na przykład od 4.17.05 do 4.17.01.
  2. Przywrócenie starszej wersji w tej samej wersji.

Wykonaj poniższą procedurę, by przywrócić zmiany w obu scenariuszach.

Kto może przywracać zmiany

Użytkownik wykonujący przywrócenie musi być taki sam jak użytkownik, który pierwotnie zaktualizował Edge, lub użytkownik root.

Domyślnie komponenty Edge są uruchamiane jako użytkownik „apigee”. W niektórych przypadkach komponenty Edge mogą być używane jako różni użytkownicy. Jeśli na przykład router musi mieć dostęp do portów z podwyższonymi uprawnieniami, takich jak te poniżej 1000, musisz uruchomić router jako użytkownik root lub jako użytkownik z dostępem do tych portów. Możesz też uruchomić jeden komponent jako jeden użytkownik, a drugi jako inny użytkownik.

Komponenty, które można wycofać

Podczas przywracania wcześniejszej wersji pamiętaj o tych warunkach:

  • Pięć wymienionych poniżej komponentów Edge ma ten sam kod. Dlatego, aby wycofać dowolny z 5 komponentów w węźle, musisz wycofać dowolny z pięciu zainstalowanych w nim komponentów. Jeśli na przykład w węźle są zainstalowane serwer zarządzania, router i procesor wiadomości, to aby przywrócić dowolny z nich, musisz przywrócić wszystkie 3 elementy.
    5 komponentów, które korzystają z tego samego kodu:
    • Serwer zarządzania
    • Router
    • procesor komunikatów
    • Serwer Qpid
    • Serwer Postgres
  • Jeśli przeprowadzasz aktualizację z wersji Edge 4.16.01, nie przywracaj wersji Cassandra. Ta wersja Edge zawiera zaktualizowaną wersję Cassandra. Jeśli przywrócisz komponenty, pozostaw Cassandra w wersji 4.17.05.

Od 4.17.05

Ta sekcja zawiera procedurę przywracania Edge 4.17.05 do poprzedniej wersji. Ta sekcja jest podzielona na 2 części:

  • Jeśli aktualizujesz tylko z wersji 4.16.01 lub 4.16.05 – przywrócenie aktualizacji Postgres do wersji 9.4
    Ostatnim etapem każdej procedury aktualizacji z wersji 4.16.01 lub 4.16.05 jest zaktualizowanie węzłów Postgres do wersji 9.4. Jeśli aktualizacja się nie powiedzie, możesz ją przywrócić, korzystając z tej procedury.
  • Przywracanie wszystkich innych komponentów Edge
    Skorzystaj z tej procedury, aby przywrócić wszystkie pozostałe komponenty Edge.

Aby wycofać aktualizację Postgres 9.4

Aby wycofać aktualizację Postgres podczas aktualizowania Postgres w konfiguracji gotowości, wykonaj te czynności:

  • Awansuj nowy węzeł gotowości na status mastera Postgres. Nowy master Postgres będzie w tej samej wersji co poprzednia instalacja Edge.
  • Skonfiguruj stary węzeł gotowości jako węzeł gotowości dla nowego węzła głównego. Stary węzeł gotowości będzie w tej samej wersji co poprzednia instalacja Edge.
  • Zarejestruj nowe węzły główne i zapasowe w grupach analitycznych i konsumentów.

Po zakończeniu przywracania stary węzeł nadrzędny nie będzie już potrzebny. Możesz wtedy wyłączyć stary węzeł nadrzędny.

  1. Sprawdź, czy nowy węzeł gotowości Postgres 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. Upewnij się, że usługa Postgres jest zatrzymana na starym węźle głównym i starym węźle gotowości:
    > /opt/apigee/apigee-service/bin/apigee-all status

    Jeśli Postgres jest uruchomiony, zatrzymaj go:
    > /opt/apigee/apigee-service/bin/apigee-serviceedge-postgres-server stopge/optge serviceedge-postgres-server stopge/optge
  3. Jeśli zainstalowano, uruchom Qpid w starym węźle gotowości:
    > /opt/apigee/apigee-service/bin/apigee-service Edge-qpid-server start

    Uwaga: w wielu konfiguracjach stary węzeł gotowości będzie hostował tylko Postgres, ale nie Qpid.
  4. Awansuj nowy węzeł gotowości jako węzeł główny Postgres:
    1. Wyznacz nowy węzeł gotowości na nowy węzeł główny:
      > apigee-service apigee-postgresql promotion-standby-to-master new_standby_IP

      Jeśli pojawi się prośba, wpisz hasło Postgres dla użytkownika „apigee”. Wartość domyślna to „postgres”.
    2. Edytuj plik konfiguracyjny użyty do zainstalowania bieżącej wersji Edge, aby określić:
      # adres IP nowego mastera:
      PG_MASTER=new_standby_IP
      # adres IP starego węzła gotowości
      PG_STANDBY=old_standby_IP
    3. Skonfiguruj nowego mastera:
      > /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFile
  5. Ponownie utwórz stary węzeł gotowości:
    1. Edytuj plik konfiguracyjny użyty do zainstalowania bieżącej wersji Edge, aby podać następujące informacje:
      # adres IP nowego mastera:
      PG_MASTER=new_standby_IP
      # adres IP starego węzła gotowości
      PG_STANDBY=old_standby_IP
    2. Usuń katalog danych w starym węźle gotowości:
      > cd /opt/apigee/data/apigee-postgresql/pgdata
      > rm -rf *
    3. Ponownie skonfiguruj stary węzeł gotowości, aby był węzłem gotowości nowego mastera:
      > /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
    4. Upewnij się, że w starym węźle gotowości działa Postgres:
      > /opt/apigee/apigee-service/bin/apigee-all status

      Jeśli nie jest uruchomiony, uruchom go:
      > /opt/apigee/apigee-service/bin/apigee-serviceedge-postgres-server start
  6. Sprawdź, czy został dodany nowy węzeł gotowości, wyświetlając plik /opt/apigee/apigee-postgresql/conf/pg_hba.conf w nowym masterze.
  7. Aby wyświetlić bieżące statystyki i informacje o grupach klientów, uruchom następujące polecenie na serwerze zarządzania:
    > curl -u sysAdminEmail:password http://<ms_IP>:8080/v1/analytics/groups/ax

    To polecenie zwraca nazwę grupy Analytics w polu name, a w polu name (nazwa grupy klienta) Zwraca też identyfikatory UUID starego węzła głównego Postgres i węzłów gotowości w polach postgres-server i datastores.


















  8. Uzyskaj adres UUID starego mastera, uruchamiając w starym węźle głównym:
    > curl -u sysAdminEmail:password:8084/v1/servers/self


    Na końcu adresu wyjściowego powinien być widoczny identyfikator UUID e-serwera6” egr18.


    Jeśli serwer Postgres nie jest uruchomiony, możesz uruchomić na nim to polecenie, aby określić identyfikator UUID:
    > curl -u sysAdminEmail:password http://<ms_IP>:8080/v1/servers?pod=analytics

    W wynikach tego polecenia wyświetlany jest identyfikator UUID każdego węzła adresu IP Postres.
  9. Powtórz poprzedni krok, aby uzyskać adresy IP starego węzła gotowości i nowego węzła głównego.
  10. Usuń stare węzły główne i zapasowe z grupy klientów:
    > curl -u sysAdminEmail:password -X DELETE "http://<ms_IP>:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001consumer-group-001/consumer-group-001/consumer-group.

    Atrybuty masterUUID,standbyUUID są podane w takiej samej kolejności, w jakiej pojawiły się powyżej podczas wyświetlania bieżących statystyk i informacji o grupie konsumentów. Konieczne może być określenie ich w formacie standbyUUID,masterUUID.

    Właściwość datastores właściwości consumer-groups powinna być teraz pusta.
  11. Usuń z grupy Analytics stare węzły główne i zapasowe:
    > curl -u sysAdminEmail:password -X DELETE "http://<ms_IP>:8080/v1/analytics/groups/ax/axgroup-001/postservers?underuid=masterUUID,standbymasterUUID

  12. Zarejestruj nowe węzły główne i gotowe PG w grupach Analytics i konsumentów:
    > curl -u sysAdminEmail:password -X POST -H "Content-Type: application/json" -d '' "http://<ms_IP>:8080/v1/analytics/groups/IP:server0?axgroup

  13. Zweryfikuj grupę statystyk:
    > curl -u sysAdminEmail:password http://<ms_IP>:8080/v1/analytics/groups/ax

    Powinny się wyświetlić identyfikatory UUID nowych węzłów głównych i gotowości znajdujących się w grupie analityki i w grupie konsumentów.
  14. Ponownie uruchom serwer zarządzania brzegowymi:
    > /opt/apigee/apigee-service/bin/apigee-service Edge-management-server restart
  15. Uruchom ponownie wszystkie serwery Qpid:
    > /opt/apigee/apigee-service/bin/apigee-service Edge-qpid-server restart
  16. Uruchom ponownie wszystkie serwery Postgres:
    > /opt/apigee/apigee-service/bin/apigee-service Edge-postgres-server restart
  17. Sprawdź stan replikacji, uruchamiając te skrypty na obu serwerach. Aby zapewnić prawidłową replikację, system powinien wyświetlić identyczne wyniki na obu serwerach:

    Na nowym masterze uruchom:
    > /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master

    Potwierdź, że jest to serwer główny.

    W starym węźle gotowości:
    > /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

    Sprawdź, czy wskazuje on tryb gotowości.
  18. Po wykonaniu kilku żądań do interfejsu API powtórz poprzedni krok, aby upewnić się, że węzły są zsynchronizowane.
  19. Usuń starego mastera Postgres, wykonując procedurę aktualizacji Apigee Edge z wersji 4.16.01/4.16.05 do wersji 4.17.05.

    Uwaga: jeśli stary węzeł nadrzędny uruchamiał Qpid, możesz pozostawić ten serwer bez zmian, aby uruchomić Qpid. Upewnij się, że działa. Jeśli nie, uruchom go:
    > /opt/apigee/apigee-service/bin/apigee-service Edge-management-server start

    Możesz też odinstalować Qpid ze starego mastera i zainstalować Qpid w nowym węźle nadrzędnym, jak opisano poniżej. Po odinstalowaniu Qpid możesz wyłączyć stary węzeł główny.

Odinstaluj Qpid ze starego mastera i zainstaluj Qpid na nowym

Wykonaj te czynności, aby odinstalować Qpid ze starego mastera i zainstalować go w nowym:

  1. Zablokuj dostęp procesorom wiadomości do portu Qpid 5672 w starym masterze, uruchamiając to polecenie we wszystkich procesorach wiadomości:
    > iptables -A OUTPUT -p tcp -d 10.233.147.20 --dport 5672 -j DROP
  2. Sprawdź, czy kolejka wiadomości Qpid jest pusta, uruchamiając poniższe polecenie. Nie możesz odinstalować Qpid, dopóki nie przetworzy on wszystkich oczekujących wiadomości:
    > qpid-stat -q

    To polecenie wyświetla tabelę zawierającą liczbę zdarzeń msg, msgIn i msgOut. Wszystkie wiadomości zostaną przetworzone, gdy: msg=0 i msgIn=msgOut.
  3. Ustal identyfikator UUID serwera Qpid na starym masterze, uruchamiając następujące polecenie na starym masterze. Zapisz te informacje na później:
    > curl -u sysAdminEmail:password http://<adres_IP_węzła>::8083/v1/servers/self
  4. Zatrzymaj Qpid w starym masterze:
    > /opt/apigee/apigee-service/bin/apigee-service Edge-qpid-server stop
    > /opt/apigee/apigee-service/bin/apigee-service apigee-qpidd stop
  5. Odinstaluj serwer Qpid:
    > /opt/apigee/apigee-service/bin/apigee-serviceedge-qpid-server zapisz
    > /opt/apigee/apigee-service/bin/apigee-service apigee-qpiddrób
  6. Usuń stary serwer Qpid z grup Analytics i grup indywidualnych:
    > curl -u sysAdminEmail:password -X DELETE -H "Content-Type: application/json" -d '' "http://<ms_IP>:8080/v1/analytics/groups/ax/axgroup-001<adres_IP>:8080/v1/analytics/groups/ax/axgroup-001

  7. Usuń stary serwer Qpid z Zookeeper:
    > curl -u sysAdminEmail:password -X DELETE http://<ms_IP>:8080/v1/servers/qpid_UUID
  8. Zainstaluj Qpid w nowym masterze:
    > /opt/apigee/apigee-setup/bin/setup.sh -p qs -f configFile
  9. Określ identyfikator UUID serwera Qpid w nowym masterze, uruchamiając na nim poniższe polecenie. Zapisz te informacje na później:
    > curl -u sysAdminEmail:password http://<adres_IP_węzła>::8083/v1/servers/self
  10. Zarejestruj nowy serwer Qpid w grupach Analytics i konsumenckich:
    > curl -u sysAdminEmail:password -X POST -H "Content-Type: application/json" -d '' "http://<ms_IP>:8080/v1/analytics/groups/groups/axType/axgroup-00?

  11. Uruchom ponownie wszystkie procesory wiadomości:
    > /opt/apigee/apigee-service/bin/apigee-service Edge-message-processor restart
  12. Na nowym serwerze Qpid uruchom to polecenie, aby sprawdzić, czy utworzono kolejki:
    > qpid-stat -q

    Sprawdź, czy panel msg, msgIn i msgOut jest aktualizowany, gdy serwer Qpid przetwarza wiadomości.

Aby przywrócić poszczególne komponenty z wersji 4.17.05

W ramach procesu przywracania musisz pobrać plik bootstrap.sh dla bieżącej wersji Edge:

  • Aby wrócić do wersji 4.17.01, pobierz plik bootstrap_4.17.01.sh
  • Jeśli chcesz wrócić do wersji 4.16.09, pobierz plik bootstrap_4.16.09.sh
  • Aby wrócić do wersji 4.16.05, pobierz plik bootstrap_4.16.05.sh
  • Jeśli chcesz wrócić do wersji 4.16.01, pobierz plik bootstrap.sh

W przypadku każdego węzła hostującego komponent, który ma zostać przywrócony:

  1. Zatrzymaj komponent, który chcesz przywrócić:
    1. Jeśli przywracasz jeden z tych komponentów w węźle, musisz zatrzymać go wszystkie: serwer zarządzania, router, procesor wiadomości, serwer Qpid lub serwer Postgres:
      • > apigee-service streaming-management-server stop
      • > apigee-service usługa brzegowa zatrzymania
      • > apigee-service Edge-message-processor stop
      • > apigee-service Edge-qpid-server stop
      • > apigee-service Edge-postgres-server stop
    2. Jeśli przywracasz inny komponent w węźle, zatrzymaj tylko ten komponent:
      • > apigee-service comp stop
  2. Jeśli wycofujesz funkcję Monetization, odinstaluj ją ze wszystkich węzłów serwera zarządzania i procesora wiadomości:
    > apigee-service Edge-mint-gateway odinstaluj
  3. Aby przywrócić poprzednią wersję węzła, odinstaluj komponent:
    1. Jeśli przywracasz którykolwiek z tych komponentów w węźle, odinstaluj je wszystkie: Serwer zarządzania, Router, Procesor wiadomości, Serwer Qpid lub Postgres Server:
      > apigee-service brzegowa brama brzegowa
    2. Jeśli przywracasz dowolny inny komponent w węźle, odinstaluj tylko ten:
      > apigee-service comp odinstaluj
    3. Jeśli przywracasz router do poprzedniej wersji, musisz usunąć zawartość pliku /opt/nginx/conf.d:
      > cd /opt/nginx/conf.d
      > rm -rf *
  4. Aby przywrócić komponent:
    1. Odinstaluj wersję apigee-setup w wersji 4.17.05:
      > /opt/apigee/apigee-service/bin/apigee-service apigee-setup zapisz
    2. Pobierz plik bootstrap.sh dla wersji 4.16.01, 4.16.05, 4.16.09 lub 4.17.01:

      Na przykład w przypadku wersji 4.16.09:
      > curl https://software.apigee.com/bootstrap_4.16.sh/bootstrap_4.16.09.
    3. Zainstaluj narzędzie oraz jego zależności w wersjach 4.16.01, 4.16.05 lub 4.16.09 apigee-service.

      Na przykład w przypadku 4.16.09:
      > sudo bash /tmp/bootstrap_4.16.09.sh apigeeuser=uName apigeepassword=pWord

      gdzie uName i pWord to te dane, które pochodzą z Apigeepassword. i pWord. Jeśli pominiesz parametr pWord, pojawi się prośba o jego podanie.
    4. Zainstaluj wersję 4.16.01, 4.16.05, lub 4.16.09 apigee-setup:
      > /opt/apigee/apigee-service/bin/apigee-service apigee-setup setup
    5. Zainstaluj wersję 4.16.01, 4.16.05, 4.16.09 lub 4.17.01 komponentu:
      > /opt/apigee/apigee-setup/bin/setup.sh -p comp -f configFile, 4.16.09, a config0.6 to plik konfiguracji4, a komp.6., gdzie komp.6.

    6. Jeśli przywracasz Qpid, wyczyść iptables:
      > sudo iptables -F
  5. Aby przywrócić komponent do określonej wersji 4.17.05:
    1. Pobierz konkretną wersję komponentu:
      > /opt/apigee/apigee-service/bin/apigee-service/bin/apigee-service comp-version zainstaluj

      gdzie comp-version to komponent i wersja do zainstalowania. Na przykład:
      > /opt/apigee/apigee-service/bin/apigee-serviceedge-ui-4.17.05-0.0.3749 zainstaluj

      Jeśli używasz duplikatu internetowego repozytorium Apigee, możesz sprawdzić dostępne wersje komponentu, używając tego polecenia:
      > yum-show example lists
      umieszczono na liście przykładów yum

    2. Zainstaluj komponent apigee-setup:
      > /opt/apigee/apigee-setup/bin/setup.sh -p comp -f configFile

      Na przykład:
      > /opt/apigee/apigee-setup/bin/how-setup.sh -p Uwaga: jeśli używasz tylko interfejsu
      podczas instalacji,
      Uwaga: jeśli używasz interfejsu instalowania tego komponentu,

Jeśli podczas przywracania wcześniejszej wersji wystąpią problemy, skontaktuj się z zespołem pomocy Apigee.