Wycofanie Centrum danych

Czasami może być konieczne wycofanie centrum danych. Jeśli na przykład uaktualniasz system operacyjny, musisz zainstalować nowy system operacyjny w nowym centrum danych, a potem wyłączyć stare centrum danych. W sekcjach poniżej znajdziesz przykład wycofywania centrum danych, w którym znajdują się 2 centra danych (dc-1 i dc-2) w 12-węzłowej instalacji klastrowej:

  • dc-1 to centrum danych, które ma zostać wycofane.
  • dc-2 to drugie centrum danych, które jest używane w procedurze wycofania.

Jeśli uaktualniasz system operacyjny, dc-2 może być centrum danych, w którym zainstalowano nową wersję systemu operacyjnego. Jednak instalacja nowego systemu operacyjnego nie jest wymagana do wycofania centrum danych.

Co należy wziąć pod uwagę przed wycofaniem centrum danych

Podczas wycofywania centrum danych pamiętaj o tych kwestiach:

  • Zablokuj cały ruch związany ze środowiskiem wykonawczym i zarządzaniem do wycofywanego centrum danych i przekieruj go do innych centrów danych.
  • Po wycofaniu centrum danych pojemność klastra Apigee zostanie zmniejszona. Aby to zrekompensować, rozważ zwiększenie pojemności pozostałych centrów danych lub dodanie centrów danych po wycofaniu.
  • Podczas procesu wycofywania może dojść do utraty danych analitycznych w zależności od tego, które komponenty analityczne są zainstalowane w wycofywanym centrum danych. Więcej informacji znajdziesz w artykule Dodawanie i usuwanie węzłów Qpid.
  • Zanim wycofasz centrum danych, musisz dowiedzieć się, jak są skonfigurowane wszystkie komponenty we wszystkich centrach danych, zwłaszcza serwery SymasLDAP, ZooKeeper, Cassandra i Postgres. Warto też utworzyć kopie zapasowe wszystkich komponentów i ich konfiguracji.

Zanim rozpoczniesz

  • Serwer zarządzania: wszystkie kroki wycofania są w dużym stopniu zależne od serwera zarządzania. Jeśli masz tylko jeden dostępny serwer zarządzania, zalecamy zainstalowanie nowego komponentu serwera zarządzania w centrum danych innym niż dc-1 przed wycofaniem serwera zarządzania w dc-1 i upewnienie się, że jeden z serwerów zarządzania jest zawsze dostępny.
  • Router: Przed wycofaniem routera z użytku wyłącz jego dostępność blokując port 15999. Upewnij się, że ruch w czasie działania nie jest kierowany do wycofywanych routerów.
  • Cassandra i ZooKeeper: W sekcjach poniżej opisano, jak wycofać dc-1 w konfiguracji z 2 centrami danych.

    Jeśli masz więcej niż 2 centra danych, usuń wszystkie odwołania do wycofywanego węzła (w tym przypadku dc-1) ze wszystkich plików konfiguracji cichej we wszystkich pozostałych centrach danych. W przypadku węzłów Cassandra, które mają zostać wycofane, usuń te hosty z CASS_HOSTS. Pozostałe węzły Cassandra powinny zachować pierwotną kolejność CASS_HOSTS.

  • PostgreSQL: jeśli wycofasz z użycia główny serwer PostgreSQL, promuj jeden z dostępnych węzłów rezerwowych jako nowy główny serwer PostgreSQL. Serwer QPID przechowuje bufor w kolejce, ale jeśli serwer główny Postgres jest niedostępny przez dłuższy czas, możesz utracić dane analityczne.

Wymagania wstępne

  • Przed wycofaniem dowolnego komponentu zalecamy utworzenie pełnej kopii zapasowej wszystkich węzłów. Aby utworzyć kopię zapasową, wykonaj procedurę dla bieżącej wersji Edge. Więcej informacji o kopiach zapasowych znajdziesz w artykule Tworzenie i przywracanie kopii zapasowych.

  • Przed wycofaniem upewnij się, że Edge działa, używając polecenia: 
    /opt/apigee/apigee-service/bin/apigee-all status
  • Upewnij się, że do wycofywanego centrum danych nie dociera obecnie żaden ruch w czasie działania.

Kolejność wycofywania komponentów

Jeśli instalujesz Edge dla chmury prywatnej na wielu węzłach, musisz wycofać komponenty Edge na tych węzłach w tej kolejności:

  1. Nowy interfejs Edge (edge-management-ui i edge-management-ui-static)
  2. Serwer zarządzania (edge-management-server)
  3. Symas LDAP (apigee-openldap)
  4. Router (router brzegowy)
  5. Procesor komunikatów (edge-message-processor)
  6. Serwer Qpid i Qpidd (edge-qpid-server i apigee-qpidd)
  7. Postgres i baza danych PostgreSQL (edge-postgres-server i apigee-postgresql)
  8. ZooKeeper (apigee-zookeeper)
  9. Cassandra (apigee-cassandra)

W sekcjach poniżej znajdziesz informacje o tym, jak wycofać poszczególne komponenty.

Nowy interfejs Edge

Aby zatrzymać i odinstalować komponenty nowego interfejsu Edge w dc-1, wpisz te polecenia:

/opt/apigee/apigee-service/bin/apigee-service edge-management-ui stop
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui uninstall
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui-static uninstall

Serwer zarządzania

Aby wycofać serwer zarządzający na dc-1, wykonaj te czynności:

  1. Zatrzymaj serwer zarządzania na dc-1: 
    apigee-service edge-management-server stop
  2. Znajdź identyfikator UUID serwera zarządzania zarejestrowanego w dc-1: 
    curl -u <AdminEmailID>:'<AdminPassword>' -X GET “http://{MS_IP}:8080/v1/servers?pod=central&region=dc-1&type=management-server”
  3. Wyrejestrowywanie typu serwera: 
    curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://{MS_IP}:8080/v1/servers -d "type=management-server&region=dc-1&pod=central&uuid=UUID&action=remove"
  4. Usuń serwer. Uwaga: jeśli na tym serwerze są zainstalowane inne komponenty, przed usunięciem identyfikatora UUID wyrejestruj je wszystkie. 
    curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/{UUID}
  5. Odinstaluj komponent serwera zarządzania na dc-1: 
    /opt/apigee/apigee-service/bin/apigee-service edge-management-server uninstall

Symas LDAP

Z tej sekcji dowiesz się, jak wycofać SymasLDAP na serwerze dc-1.

Uwaga: jeśli masz więcej niż 2 centra danych, zapoznaj się z sekcją Konfiguracje z więcej niż 2 centrami danych poniżej.

Aby wycofać SymasLDAP na dc-1, wykonaj te czynności:

  1. Utwórz kopię zapasową węzła dc-1 SymasLDAP, wykonując czynności opisane w artykule Jak utworzyć kopię zapasową.

  2. Przerwij replikację danych między 2 centrami danych, dc-1 i dc-2, wykonując te czynności w obu centrach danych.

    1. Sprawdź obecny stan: 
            /opt/symas/bin/ldapsearch -H ldap://{HOST}:{PORT} -LLL -x -b "cn=config" -D "cn=admin,cn=config" -w {credentials} -o ldif-wrap=no 'olcSyncRepl' | grep olcSyncrepl

      Dane wyjściowe powinny być podobne do tych: 

      olcSyncrepl: {0}rid=001 provider=ldap://{HOST}:{PORT}/ binddn="cn=manager,dc=apigee,dc=com" bindmethod=simple credentials={credentials} searchbase="dc=apigee,dc=com" attrs="*,+" type=refreshAndPersist retry="60 1 300 12 7200 +" timeout=1
    2. Utwórz plik break_repl.ldif zawierający te polecenia: 
      dn: olcDatabase={2}mdb,cn=config
changetype: modify
delete: olcSyncRepl

dn: olcDatabase={2}mdb,cn=config
changetype: modify
delete: olcMirrorMode
    3. Uruchom polecenie ldapmodify: 
            /opt/symas/bin/ldapmodify -x -w {credentials} -D "cn=admin,cn=config" -H "ldap://{HOST}:{PORT}/" -f path/to/file/break_repl.ldif

      Dane wyjściowe powinny być podobne do tych: 

      modifying entry "olcDatabase={2}mdb,cn=config"
modifying entry "olcDatabase={2}mdb,cn=config"

  3. Możesz sprawdzić, czy dc-2 nie replikuje już do dc-1, tworząc wpis w LDAP dc-2 i upewniając się, że nie pojawia się on w LDAP dc-1.

    Opcjonalnie możesz wykonać poniższe czynności, aby utworzyć użytkownika z dostępem tylko do odczytu w węźle dc-2 SymasLDAP, a następnie sprawdzić, czy użytkownik został zreplikowany. Użytkownik zostanie następnie usunięty.

    1. Utwórz plik readonly-user.ldif w dc-2 z tą zawartością: 
      dn: uid=readonly-user,ou=users,ou=global,dc=apigee,dc=com
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: top
cn: readonly-user
sn: readonly-user
userPassword: {testPassword}
    2. Dodaj użytkownika za pomocą polecenia `ldapadd` na serwerze dc-2: 
      /opt/symas/bin/ldapadd -H ldap://{HOST}:{PORT} -w {credentials} -D "cn=manager,dc=apigee,dc=com" -f path/to/file/readonly-user.ldif

      Dane wyjściowe będą podobne do tych: 

      adding new entry "uid=readonly-user,ou=users,ou=global,dc=apigee,dc=com"
    3. Wyszukaj użytkownika w dc-1, aby upewnić się, że nie został zreplikowany. Jeśli użytkownik nie jest obecny w dc-1, będziesz mieć pewność, że oba serwery LDAP nie są już replikowane: 
      /opt/symas/bin/ldapsearch -H ldap://{HOST}:{PORT} -x -w {credentials} -D "cn=manager,dc=apigee,dc=com" -b uid=readonly-user,ou=users,ou=global,dc=apigee,dc=com -LLL

      Dane wyjściowe powinny być podobne do tych:

      No such object (32)
Matched DN: ou=users,ou=global,dc=apigee,dc=com
    4. Usuń dodanego wcześniej użytkownika z dostępem tylko do odczytu: 
      /opt/symas/bin/ldapdelete -v -H ldap://{HOST}:{PORT} -w {credentials} -D "cn=manager,dc=apigee,dc=com" "uid=readonly-user,ou=users,ou=global,dc=apigee,dc=com"
  4. Zatrzymaj SymasLDAP na serwerze dc-1: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-openldap stop
  5. Odinstaluj komponent SymasLDAP na dc-1: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-openldap uninstall

Router

Z tej sekcji dowiesz się, jak wycofać router. Więcej informacji o usuwaniu routera znajdziesz w artykule Usuwanie serwera.

Poniższe kroki powodują wycofanie routera z dc-1. Jeśli w dc-1 skonfigurowano kilka węzłów routera, wykonaj te czynności we wszystkich węzłach routera po kolei.

Uwaga: zakładamy, że port kontroli stanu routera 15999 jest skonfigurowany w systemie równoważenia obciążenia i że zablokowanie portu 15999 spowoduje, że router będzie nieosiągalny. Aby zablokować port, możesz potrzebować dostępu do roota.

Aby wycofać router z użycia, wykonaj te czynności:

  1. Wyłącz osiągalność routerów, blokując port 15999, czyli port kontroli stanu. Sprawdź, czy ruch w czasie działania jest blokowany w tym centrum danych:

    iptables -A INPUT -i eth0 -p tcp --dport 15999 -j REJECT

  2. Sprawdź, czy router jest osiągalny:

    curl -vvv -X GET http://{ROUTER_IP}:15999/v1/servers/self/reachable

    Dane wyjściowe powinny być podobne do tych: 

    About to connect() to 10.126.0.160 port 15999 (#0)
Trying 10.126.0.160...
Connection refused
Failed connect to 10.126.0.160:15999; Connection refused
Closing connection 0
curl: (7) Failed connect to 10.126.0.160:15999; Connection refused
  3. Pobierz identyfikator UUID routera zgodnie z opisem w sekcji Pobieranie identyfikatorów UUID.
  4. Zatrzymaj router: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router stop
  5. Wyświetl listę dostępnych podów bramy w organizacji za pomocą tego polecenia: 
    curl -u  <AdminEmailID>:'<AdminPassword>' -X GET "http://{MS_IP}:8080/v1/organizations/{ORG}/pods"

    Zobacz Informacje o podach.

  6. Wyrejestruj typ serwera: 
    curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://{MS_IP}:8080/v1/servers -d "type=router&region=dc-1&pod=gateway-1&uuid=UUID&action=remove"
  7. Wyrejestruj serwer: 
    curl -u <AdminEmailID>:'<AdminPassword>’ -X DELETE http://{MS_IP}:8080/v1/servers/UUID
  8. Odinstaluj edge-router: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router uninstall
     Zobacz Usuwanie serwera.
  9. Wyczyść reguły iptables, aby włączyć zablokowany port 15999: 
    iptables -F

procesor komunikatów

W tej sekcji opisano, jak wycofać procesor komunikatów z dc-1. Więcej informacji o usuwaniu procesora komunikatów znajdziesz w artykule Usuwanie serwera.

Ponieważ zakładamy, że dc-1 ma 12-węzłową instalację klastrową, w dc-1 skonfigurowane są 2 węzły procesora komunikatów. Uruchom te polecenia na obu węzłach.

  1. Pobierz identyfikatory UUID procesorów komunikatów zgodnie z opisem w sekcji Pobieranie identyfikatorów UUID.
  2. Zatrzymaj procesor komunikatów: 
    apigee-service edge-message-processor stop
  3. Wyrejestruj typ serwera: 
    curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://{MS_IP}:8080/v1/servers -d "type=message-processor&region=dc-1&pod=gateway-1&uuid=UUID&action=remove"
  4. Odłącz środowisko od procesora komunikatów. 
    curl -H "Content-Type:application/x-www-form-urlencoded" <AdminEmailID>:'<AdminPassword>’  \
-X POST http://{MS_IP}:8080/v1/organizations/{ORG}/environments/{ENV}/servers \
-d "action=remove&uuid=UUID"
  5. Wyrejestruj typ serwera: 
    curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://{MS_IP}:8080/v1/servers -d "type=message-processor&region=dc-1&pod=gateway-1&uuid=UUID&action=remove"
  6. Odinstaluj procesor komunikatów: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor uninstall
  7. Wyrejestruj serwer: 
    curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/UUID

Serwer Qpid i Qpidd

W tej sekcji opisano, jak wycofać serwer Qpid (edge-qpid-server) i Qpidd (apigee-qpidd). W dc-1 skonfigurowane są 2 węzły Qpid, więc musisz wykonać te czynności w przypadku obu węzłów:

  1. Pobierz identyfikator UUID dla Qpidd zgodnie z opisem w sekcji Pobieranie identyfikatorów UUID.
  2. Zatrzymaj edge-qpid-server i apigee-qpidd: 
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server stop
/opt/apigee/apigee-service/bin/apigee-service apigee-qpidd stop
  3. Uzyskaj listę grup Analytics i grup konsumentów: 
    curl -u <AdminEmailID>:'<AdminPassword>' -X GET http://{MS_IP}:8080/v1/analytics/groups/ax
  4. Usuń Qpid z grupy konsumentów: 
    curl -u <AdminEmailID>:'<AdminPassword>' -H "Content-Type: application/json"  -X DELETE \ "http://{MS_IP}:8080/v1/analytics/groups/ax/{ax_group}/consumer-groups/{consumer_group}/consumers/{QPID_UUID}"
  5. Usuń Qpid z grupy Analytics: 
    curl -v -u <AdminEmailID>:'<AdminPassword>' \
-X DELETE "http://{MS_IP}:8080/v1/analytics/groups/ax/{ax_group}/servers?uuid={QPID_UUID}&type=qpid-server"
  6. Wyrejestruj serwer Qpid z instalacji Edge: 
    curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://{MS_IP}:8080/v1/servers \
-d "type=qpid-server&region=dc-1&pod=central&uuid={QPID_UUID}&action=remove"
  7. Usuń serwer Qpid z instalacji Edge: 
    curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/UUID
  8. Uruchom ponownie wszystkie komponenty edge-qpid-server na wszystkich węzłach, aby mieć pewność, że zmiany zostaną przez nie uwzględnione: 
    $ /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
$ /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server wait_for_ready
  9. Odinstaluj edge-qpid-server i apigee-qpidd: 
    $ /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server uninstall
$ /opt/apigee/apigee-service/bin/apigee-service apigee-qpidd uninstall

Postgres i Postgresql

Wycofywane centrum danych może mieć główną lub zapasową bazę danych Postgres. W sekcjach poniżej znajdziesz informacje o tym, jak je wycofać:

Wycofywanie bazy głównej Postgres

Uwaga: jeśli wycofasz węzeł główny Postgres, pamiętaj, aby promować jeden z dostępnych węzłów rezerwowych jako nowy węzeł główny Postgres. Chociaż kolejki QPID buforują dane, jeśli usługa Postgres master jest niedostępna przez dłuższy czas, ryzykujesz utratę danych analitycznych.

Aby wycofać bazę danych Postgres:

  1. Utwórz kopię zapasową głównego węzła Postgres dc-1, postępując zgodnie z instrukcjami podanymi w tych linkach:
  2. Pobierz identyfikatory UUID serwerów Postgres zgodnie z opisem w sekcji Pobieranie identyfikatorów UUID.
  3. Na dc-1 zatrzymaj edge-postgres-server i apigee-postgresql na bieżącej instancji głównej: 
    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop
  4. W węźle rezerwowym w dc-2 wpisz to polecenie, aby ustawić go jako węzeł główny: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql promote-standby-to-master <IP of OLD Progress master>

    Uwaga: jeśli masz więcej niż 1 rezerwowy węzeł Postgres, musisz dodać wpisy hosta w nowym węźle głównym i zaktualizować ustawienie replikacji dla wszystkich dostępnych rezerwowych węzłów Postgres.

    Aby dodać wpisy hosta do nowego serwera nadrzędnego Postgres, wykonaj czynności opisane w odpowiedniej sekcji poniżej:

    Jeśli pozostał tylko jeden węzeł rezerwowy

    Załóżmy na przykład, że przed wycofaniem skonfigurowano 3 węzły Postgres. Dotychczasowy węzeł główny został wycofany, a jeden z pozostałych węzłów rezerwowych postgres został awansowany na węzeł główny. Skonfiguruj pozostały węzeł rezerwowy, wykonując te czynności:

    1. Na nowym serwerze głównym zmodyfikuj plik konfiguracji, aby ustawić: 
      PG_MASTER=IP_or_DNS_of_new_PG_MASTER
PG_STANDBY=IP_or_DNS_of_PG_STANDBY
    2. Włącz replikację na nowym serwerze głównym: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFIle

    Jeśli pozostał więcej niż 1 węzeł rezerwowy

    1. Dodaj tę konfigurację w /opt/apigee/customer/application/postgresql.properties: 
      conf_pg_hba_replication.connection=host replication apigee standby_1_ip/32 trust \n host replication apigee standby_2_ip/32 trust
    2. Sprawdź, czy plik /opt/apigee/customer/application/postgresql.properties należy do użytkownika apigee: 
      chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
    3. Uruchom ponownie apigee-postgresql: 
      apigee-service apigee-postgresql restart

      4. Aby zaktualizować ustawienia replikacji na węźle rezerwowym:

      1. Zmodyfikuj plik konfiguracji /opt/silent.conf i zaktualizuj pole PG_MASTER, podając adres IP nowego serwera głównego Postgres.
      2. Usuń stare dane Postgres za pomocą tego polecenia: 
        rm -rf /opt/apigee/data/apigee-postgresql/
      3. Skonfiguruj replikację na węźle rezerwowym: 
        /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
    4. Sprawdź, czy baza danych Postgres master jest prawidłowo skonfigurowana, wpisując w dc-2 to polecenie: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
    5. Usuń i dodaj serwery Postgresql z grupy analitycznej i grupy konsumentów.
      1. Usuń stary serwer Postgres z grupy Analytics, postępując zgodnie z instrukcjami podanymi w artykule Usuwanie serwera Postgres z grupy Analytics.
      2. Dodaj nowy serwer Postgres do grupy analitycznej, postępując zgodnie z instrukcjami w artykule Dodawanie istniejącego serwera Postgres do grupy analitycznej.
    6. Wyrejestruj stary serwer postgres z dc-1: 
      curl -u <AdminEmailID>:<AdminPassword> -X POST http://{MS_IP}:8080/v1/servers \
-d "type=postgres-server®ion=dc-1&pod=analytics&uuid=UUID&action=remove"
    7. Usuń stary serwer postgres z dc-1: 
      curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/UUID
    8. Stary serwer główny Postgres można teraz bezpiecznie wyłączyć. Odinstaluj edge-postgres-server i apigee-postgresql: 
      /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server uninstall
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql uninstall

    Wyłączanie trybu gotowości Postgres

    Uwaga: dokumentacja instalacji klastrowej z 12 węzłami pokazuje węzeł postgresql dc-1 jako węzeł główny, ale dla wygody w tej sekcji przyjęto, że węzeł postgresql dc-1 jest węzłem rezerwowym, a węzeł postgresql dc-2 jest węzłem głównym.

    Aby wycofać Postgres w trybie gotowości, wykonaj te czynności:

    1. Uzyskaj identyfikatory UUID serwerów Postgres, postępując zgodnie z instrukcjami podanymi w sekcji Uzyskiwanie identyfikatorów UUID.
    2. Zatrzymaj apigee-postgresql w bieżącym węźle rezerwowym w dc-1: 
      /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop
    3. Usuń serwery PostgreSQL z grupy Analytics i grupy konsumentów oraz dodaj je do nich.
      1. Usuń stary serwer Postgres z grupy analitycznej zgodnie z instrukcjami podanymi w artykule Usuwanie serwera Postgres z grupy analitycznej.
      2. Dodaj nowy serwer Postgres do grupy analitycznej, postępując zgodnie z instrukcjami w artykule Dodawanie istniejącego serwera Postgres do grupy analitycznej.
    4. Wyrejestruj stary serwer Postgres z dc-1: 
      curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://{MS_IP}:8080/v1/servers \
-d "type=postgres-server&region=dc-1&pod=analytics&uuid=UUID&action=remove"
    5. Usuń stary serwer postgres z dc-1: 
      curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://{MS_IP}:8080/v1/servers/UUID
    6. Można teraz bezpiecznie wycofać starą instancję główną Postgres. Odinstaluj edge-postgres-server i apigee-postgresql: 
      /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server uninstall
       
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql uninstall

    ZooKeeper i Cassandra

    W tej sekcji opisujemy, jak wycofać serwery ZooKeeper i Cassandra w konfiguracji z 2 centrami danych.

    Jeśli masz więcej niż 2 centra danych, usuń wszystkie odwołania do wycofywanego węzła (w tym przypadku dc-1) ze wszystkich plików konfiguracji cichej we wszystkich pozostałych centrach danych. W przypadku węzłów Cassandra, które mają zostać wycofane, usuń te hosty z CASS_HOSTS. Pozostałe węzły Cassandra powinny pozostać w pierwotnej kolejności CASS_HOSTS.

    Uwaga dotycząca ZooKeeper: podczas modyfikowania właściwości ZK_HOST w pliku konfiguracyjnym musisz zachować kworum węzłów głosujących, aby zapewnić prawidłowe działanie zespołu ZooKeeper. W konfiguracji musi być nieparzysta liczba węzłów głosujących. Więcej informacji znajdziesz w artykule o zadaniach konserwacyjnych Apache ZooKeeper.

    Aby wycofać serwery ZooKeeper i Cassandra:

    1. Utwórz kopię zapasową węzłów Cassandra i ZooKeeper w dc-1, postępując zgodnie z instrukcjami podanymi w tych linkach:

    2. Wymień identyfikatory UUID serwerów ZooKeeper i Cassandra w centrum danych, w którym węzły Cassandra mają zostać wycofane.

      apigee-adminapi.sh servers list -r dc-1 -p central -t application-datastore --admin <AdminEmailID> --pwd '<AdminPassword>' --host localhost
    3. Wyrejestruj typ serwera: 
      curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://MS_IP:8080/v1/servers -d "type=cache-datastore&type=user-settings-datastore&type=scheduler-datastore&type=audit-datastore&type=apimodel-datastore&type=application-datastore&type=edgenotification-datastore&type=identityzone-datastore&type=user-settings-datastore&type=auth-datastore&region=dc-1&pod=central&uuid=UUID&action=remove"
    4. Wyrejestruj serwer: 
      curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://MS_IP:8080/v1/servers/UUID
    5. Zaktualizuj plik konfiguracji, usuwając z niego adresy IP wycofanych węzłów z ZK_HOSTS i CASS_HOSTS.

      Przykład: załóżmy, że masz adresy IP $IP1 $IP2 $IP3 w dc-1 i $IP4 $IP5 $IP6 w dc-2 i wycofujesz dc-1. Następnie usuń adresy IP $IP1 $IP2 $IP3 z plików konfiguracyjnych.

      • Istniejące wpisy w pliku konfiguracji: 
        ZK_HOSTS="$IP1 $IP2 $IP3 $IP4 $IP5 $IP6"
CASS_HOSTS="$IP1:1,1 $IP2:1,1 $IP3:1,1, $IP4:2,1 $IP5:2,1 $IP6:2,1”
      • Nowe wpisy w pliku konfiguracji: 
        ZK_HOSTS="$IP4 $IP5 $IP6"
CASS_HOSTS="$IP4:2,1 $IP5:2,1 $IP6:2,1"
    6. Zaktualizuj plik konfiguracji instalacji dyskretnej (zmodyfikowany w kroku e), podając adresy IP usuniętych węzłów, i uruchom profil serwera zarządzania na wszystkich węzłach, na których znajdują się serwery zarządzania: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ms -f updated_config_file
    7. Zaktualizuj plik konfiguracji, dodając adresy IP usuniętych węzłów, i uruchom profil MP/RMP na wszystkich węzłach routera i procesora komunikatów:
      • Jeśli router Edge i procesor komunikatów są skonfigurowane w tym samym węźle, wpisz: 
        /opt/apigee/apigee-setup/bin/setup.sh -p rmp -f updated_config_file

      • Jeśli router Edge i procesor komunikatów są skonfigurowane na osobnych węzłach, wpisz:

        W przypadku routera:

        /opt/apigee/apigee-setup/bin/setup.sh -p r -f updated_config_file

        W przypadku procesora komunikatów:

        /opt/apigee/apigee-setup/bin/setup.sh -p mp -f updated_config_file
    8. Ponownie skonfiguruj wszystkie węzły Qpid, usuwając z pliku odpowiedzi adresy IP wycofanych węzłów: 
      /opt/apigee/apigee-setup/bin/setup.sh -p qs -f updated_config_file
    9. Ponownie skonfiguruj wszystkie węzły Postgres, usuwając z pliku odpowiedzi adresy IP wycofanych węzłów: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f updated_config_file
    10. Zmień przestrzeń kluczy system_auth. Jeśli masz włączone uwierzytelnianie Cassandra w istniejącym węźle Cassandra, zaktualizuj współczynnik replikacji przestrzeni kluczy system_auth, uruchamiając to polecenie: 
      ALTER KEYSPACE system_auth WITH replication = {'class': 'NetworkTopologyStrategy', 'dc-2': '3'};

      To polecenie ustawia współczynnik replikacji na '3', co oznacza 3 węzły Cassandra w klastrze. W razie potrzeby zmień tę wartość.

      Po wykonaniu tego kroku topologia Cassandra nie powinna zawierać dc-1 w żadnej z przestrzeni kluczy.

    11. Wycofaj węzły Cassandra w dc-1, jeden po drugim.

      Aby wycofać węzły Cassandra, wpisz to polecenie: 

      /opt/apigee/apigee-cassandra/bin/nodetool -h cassIP -u cassandra -pw '<AdminPassword>' decommission
    12. Sprawdź połączenie węzłów Cassandra z dc-1 za pomocą jednego z tych poleceń: 
      /opt/apigee/apigee-cassandra/bin/cqlsh cassIP 9042 -u cassandra -p '<AdminPassword>'

      Możesz też uruchomić na wycofanym węźle dodatkowe polecenie weryfikacji: 

      /opt/apigee/apigee-cassandra/bin/nodetool netstats

      Powyższe polecenie powinno zwrócić: 

      Mode: DECOMMISSIONED
    13. Uruchom profil DS dla wszystkich węzłów Cassandra i ZooKeeper w dc-2: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ds -f updated_config_file
    14. Zatrzymaj apigee-cassandra i apigee-zookeeper w dc-1: 
      apigee-service apigee-cassandra stop
apigee-service apigee-zookeeper stop
    15. Odinstaluj apigee-cassandra i apigee-zookeeper w dc-1: 
      apigee-service apigee-cassandra uninstall
apigee-service apigee-zookeeper uninstall

    Usuwanie powiązań z dc-1

    Aby usunąć powiązania z dc-1, wykonaj te czynności:

    1. Usuń powiązania z dc-1.
      1. Wyświetl listę wszystkich dostępnych zasobników w organizacji: 
        curl -v -u  <AdminEmailID>:'<AdminPassword>' -X GET "http://MS_IP:8080/v1/o/ORG/pods"
      2. Aby sprawdzić, czy wszystkie powiązania zostały usunięte, pobierz identyfikatory UUID serwerów powiązanych z podami: 
        curl -v -u  <AdminEmailID>:'<AdminPassword>' \
-X GET "http://MS_IP:8080/v1/regions/dc-1/pods/gateway-1/servers"

        Jeśli to polecenie nie zwróci żadnych identyfikatorów UUID, oznacza to, że poprzednie kroki usunęły wszystkie powiązania i możesz pominąć następny krok. W przeciwnym razie przejdź do następnego kroku.

      3. Usuń wszystkie powiązania serwera dla identyfikatorów UUID uzyskanych w poprzednim kroku: 
        curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://MS_IP:8080/v1/servers/UUID
      4. Odłącz organizację od poda: 
        curl -v -u  <AdminEmailID>:'<AdminPassword>'  "http://MS_IP:8080/v1/o/ORG/pods" -d "action=remove&region=dc-1&pod=gateway-1" -H "Content-Type: application/x-www-form-urlencoded" -X POST
    2. Usuń pody: 
      curl -v -u <AdminEmailID>:'<AdminPassword>' "http://MS_IP:8080/v1/regions/dc-1/pods/gateway-1" -X DELETE
    3. Usuń region. 
      curl -v -u <AdminEmailID>:'<AdminPassword>'  "http://MS_IP:8080/v1/regions/dc-1" -X DELETE

    W tym momencie proces wycofywania serwera dc-1 został zakończony.

    Dodatek

    Rozwiązywanie problemów

    Jeśli po wykonaniu poprzednich czynności w niektórych podach nadal są serwery, wykonaj te czynności, aby wyrejestrować i usunąć serwery. Uwaga: w razie potrzeby zmień typy i pody.

    1. Pobierz identyfikatory UUID za pomocą tego polecenia: 
      apigee-adminapi.sh servers list -r dc-1 -p POD -t  --admin <AdminEmailID> --pwd  '<AdminPassword>’ --host localhost
    2. Typ serwera wyrejestrowania: 
      curl -u <AdminEmailID>:'<AdminPassword>' -X POST http://MP_IP:8080/v1/servers -d "type=TYPE=REGION=dc-1&pod=POD&uuid=UUID&action=remove"
    3. Usuń serwery pojedynczo: 
      curl -u <AdminEmailID>:'<AdminPassword>' -X DELETE http://MP_IP:8080/v1/servers/UUID

    Walidacja

    Aby sprawdzić wycofanie, użyj tych poleceń.

    Serwer zarządzania

    1. Uruchom te polecenia na serwerach zarządzających we wszystkich regionach. 
      curl -v -u  <AdminEmailID>:'<AdminPassword>' http://MS_IP:8080/v1/servers?pod=central&region=dc-1
curl -v -u  <AdminEmailID>:'<AdminPassword>' http://MS_IP:8080/v1/servers?pod=gateway&region=dc-1
curl -v -u  <AdminEmailID>:'<AdminPassword>' http://MS_IP:8080/v1/servers?pod=analytics&region=dc-1
    2. Uruchom to polecenie na wszystkich komponentach, aby sprawdzić wymagania dotyczące wszystkich portów zarządzania. 
      curl -v http://MS_IP:8080/v1/servers/self
    3. Sprawdź grupę analityczną. 
      curl -v  -u  <AdminEmailID>:'<AdminPassword>' http://MS_IP:8080/v1/o/ORG/e/ENV/provisioning/axstatus
curl -v  -u  <AdminEmailID>:'<AdminPassword>' http://MS_IP:8080/v1/analytics/groups/ax

      4. Węzły Cassandra/ZooKeeper

      1. Na wszystkich węzłach Cassandra wpisz: 
        /opt/apigee/apigee-cassandra/bin/nodetool -h <host> statusthrift

        Spowoduje to zwrócenie stanu running lub not running dla tego konkretnego węzła.

      2. W jednym węźle wpisz: 
        /opt/apigee/apigee-cassandra/bin/nodetool -h <host> ring
         /opt/apigee/apigee-cassandra/bin/nodetool -h <host> status

        Powyższe polecenia zwrócą informacje o aktywnym centrum danych.

      3. Na węzłach ZooKeeper najpierw wpisz: 
        echo ruok | nc <host> 2181

        To polecenie zwraca imok.

        Następnie wpisz:

        echo stat | nc <host> 2181 | grep Mode

        Wartość Mode zwrócona przez powyższe polecenie będzie jedną z tych wartości: observer, leader lub follower.

      4. W jednym węźle ZooKeeper uruchom: 
        /opt/apigee/apigee-zookeeper/contrib/zk-tree.sh >> /tmp/zk-tree.out.txt
      5. Na węźle głównym Postgres uruchom: 
        /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master

        Sprawdź, czy w odpowiedzi jest informacja, że węzeł jest węzłem głównym.

      6. Na węźle rezerwowym uruchom: 
        /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

        Sprawdź, czy odpowiedź potwierdza, że węzeł jest w trybie gotowości.

      7. Zaloguj się w bazie danych PostgreSQL za pomocą tego polecenia: 
        psql -h localhost -d apigee -U postgres

        Gdy pojawi się prośba, wpisz hasło użytkownika postgres (domyślnie: postgres).

        Następnie uruchom to zapytanie, aby sprawdzić maksymalną wartość client_received_start_timestamp:

        SELECT max(client_received_start_timestamp) FROM "analytics"."$org.$env.fact" LIMIT 1;

      Logi

      Sprawdź logi komponentów, aby upewnić się, że nie ma błędów.