Wycofanie Centrum danych

Czasami może być konieczne wycofanie centrum danych z eksploatacji. Jeśli na przykład aktualizujesz 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 wycofywania.

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

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

Podczas wycofywania centrum danych pamiętaj o tych kwestiach:

  • Zablokuj cały ruch związany z czasem działania i zarządzaniem w wycofywanym centrum danych i przekieruj go do innych centrów danych.
  • Po wycofaniu centrum danych z eksploatacji pojemność klastra Apigee zostanie zmniejszona. Aby to zrekompensować, rozważ zwiększenie pojemności w pozostałych centrach danych lub dodanie nowych centrów danych po wycofaniu z użytku tych, które są obecnie używane.
  • Podczas procesu wycofywania istnieje możliwość 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.
  • Przed wycofaniem centrum danych z eksploatacji musisz poznać konfigurację wszystkich komponentów we wszystkich centrach danych, zwłaszcza serwerów SymasLDAP, ZooKeeper, Cassandra i Postgres. Warto też wykonać kopie zapasowe wszystkich komponentów i ich konfiguracji.

Zanim rozpoczniesz

  • Serwer zarządzania: Wszystkie kroki wycofywania zależą w dużej mierze od serwera zarządzania. Jeśli masz tylko 1 serwer zarządzający, zalecamy zainstalowanie nowego komponentu serwera zarządzającego w centrum danych innym niż dc-1 przed wycofaniem serwera zarządzającego w centrum danych dc-1. Upewnij się, że jeden z serwerów zarządzających jest zawsze dostępny.
  • Router: Przed wycofaniem routera z użytku wyłącz jego dostępność przez zablokowanie portu 15999. Upewnij się, że ruch w czasie działania nie jest kierowany do wycofywanych routerów.
  • Cassandra i ZooKeeper: W sekcjach poniżej opisujemy, jak wycofać z eksploatacji 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 wyłączysz główny węzeł PostgreSQL, promuj jeden z dostępnych węzłów rezerwowych jako nowy główny węzeł 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 z użytku dowolnego komponentu zalecamy wykonanie pełnej kopii zapasowej wszystkich węzłów. Wykonaj kopię zapasową zgodnie z procedurą dla bieżącej wersji Edge. Więcej informacji o kopii zapasowej znajdziesz w artykule Tworzenie i przywracanie kopii zapasowych.

  • Przed wycofaniem z użycia sprawdź, czy Edge działa, używając tego 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 zainstalujesz Edge for Private Cloud na wielu węzłach, musisz wycofać komponenty Edge na tych węzłach w tej kolejności:

  1. Interfejs Edge (edge-ui)
  2. Serwer zarządzający (edge-management-server)
  3. Symas LDAP (apigee-openldap)
  4. Router (router brzegowy)
  5. Procesor wiadomości (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.

Interfejs Edge

Aby zatrzymać i odinstalować komponent interfejsu Edge dc-1, wpisz te polecenia:

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

Serwer zarządzania

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

  1. Zatrzymaj serwer zarządzania na komputerze 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. Wyrejestruj typ 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 komputerze 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 dwoma centrami danych, dc-1 i dc-2, wykonując w obu centrach danych te czynności:

    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ć czynności opisane poniżej, aby utworzyć użytkownika 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 w dc-2 plik readonly-user.ldif o tej 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` w 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 na serwerze dc-1, możesz mieć pewność, że oba protokoły LDAP nie replikują już danych: 
      /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 uprawnieniami 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 serwerze dc-1: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-openldap uninstall

Router

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

Poniższe kroki wycofują router z dc-1. Jeśli w dc-1 skonfigurowano wiele węzłów routera, wykonaj te czynności w każdym z nich po kolei.

Uwaga: w tym przypadku 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 niedostępny. Aby zablokować port, może być potrzebny dostęp do roota.

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

  1. Wyłącz dostępność 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ść iptables reguły, aby włączyć zablokowany port 15999: 
    iptables -F

procesor komunikatów

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

Zakładamy, że dc-1 ma 12-węzłową instalację klastrową, więc w dc-1 skonfigurowane są 2 węzły procesora wiadomości. Wykonaj te polecenia na obu węzłach.

  1. Pobierz identyfikatory UUID procesorów wiadomości zgodnie z opisem w sekcji Pobieranie identyfikatorów UUID.
  2. Zatrzymaj procesor wiadomości: 
    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 wiadomości. 
    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 wiadomości: 
    /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

Z tej sekcji dowiesz się, jak wyłączyć 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 w sposób opisany w artykule 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 analitycznej: 
    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 zmiana zostanie przez nie uwzględniona: 
    $ /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

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

Wyłączanie głównej instancji Postgres

Uwaga: jeśli wycofasz główny serwer Postgres, promuj jeden z dostępnych węzłów rezerwowych jako nowy główny serwer Postgres. Kolejki QPID buforują dane, ale jeśli serwer główny Postgres jest niedostępny przez dłuższy czas, możesz utracić dane analityczne.

Aby wycofać mastera 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 serwerze 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. Na 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 węzeł Postgres w trybie gotowości, musisz dodać wpisy hosta na nowym węźle głównym i zaktualizować ustawienie replikacji dla wszystkich dostępnych węzłów Postgres w trybie gotowości.

    Aby dodać wpisy hosta do nowego głównego serwera Postgres, wykonaj czynności opisane w odpowiedniej sekcji poniżej:

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

    Załóżmy na przykład, że przed wycofaniem z użytku skonfigurowane były 3 węzły Postgres. Istniejący 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 edytuj 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ło 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 jest własnością 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, wpisując adres IP nowego głównego serwera 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. Aby sprawdzić, czy serwer główny Postgres został prawidłowo skonfigurowany, wpisz to polecenie w dc-2: 
      /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 analitycznej, postępując zgodnie z instrukcjami 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.
    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 wycofać. 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 rezerwowej bazy danych Postgres

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

    Aby wycofać rezerwowy serwer Postgres, wykonaj te czynności:

    1. Uzyskaj identyfikatory UUID serwerów Postgres, postępując zgodnie z instrukcjami w sekcji Uzyskiwanie identyfikatorów UUID.
    2. Zatrzymaj apigee-postgresql na 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ń i dodaj serwery Postgresql z grupy analitycznej i grupy konsumentów.
      1. Usuń stary serwer Postgres z grupy analitycznej, postępując zgodnie z instrukcjami 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. Stary serwer główny Postgres można teraz bezpiecznie wycofać. 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 zachować pierwotną kolejność CASS_HOSTS.

    Uwaga dotycząca ZooKeepera: 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 ZooKeepera. W konfiguracji musisz mieć nieparzystą liczbę węzłów głosujących. Więcej informacji znajdziesz w artykule Czynności związane z konserwacją Apache ZooKeeper.

    Aby wycofać serwery ZooKeeper i Cassandra:

    1. Utwórz kopię zapasową węzłów dc-1 Cassandra i ZooKeeper, postępując zgodnie z instrukcjami dostępnymi pod tymi linkami:

    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 ZK_HOSTS i CASS_HOSTS adresy IP wycofanych węzłów.

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

      • 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 cichej instalacji (zmodyfikowany w kroku e) o adresy IP usuniętych węzłów wycofanych z użytku i uruchom profil serwera zarządzającego na wszystkich węzłach hostujących serwery zarządzające: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ms -f updated_config_file
    7. Zaktualizuj plik konfiguracyjny o adresy IP usuniętych węzłów wycofanych z eksploatacji i uruchom profil MP/RMP na wszystkich węzłach routera i procesora wiadomości:
      • Jeśli router brzegowy i procesor wiadomości są skonfigurowane w tym samym węźle, wpisz: 
        /opt/apigee/apigee-setup/bin/setup.sh -p rmp -f updated_config_file

      • Jeśli router brzegowy i procesor wiadomości są skonfigurowane na oddzielnych 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 na istniejącym węźle Cassandra masz włączone uwierzytelnianie Cassandra, zaktualizuj współczynnik replikacji przestrzeni kluczy system_auth, wykonują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 w topologii Cassandry nie powinno być dc-1 w żadnej 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>'

      lub polecenie weryfikacji dodatkowej, które ma zostać uruchomione na wycofanym węźle: 

      /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 klastrze 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

    Usuń powiązania 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 zasobnikami: 
        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, poprzednie kroki usunęły wszystkie powiązania i możesz pominąć następny krok. W przeciwnym razie wykonaj następny krok.

      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 bloku reklamowego: 
        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 kroków w niektórych pulach nadal znajdują się serwery, wykonaj poniższe czynności, aby wyrejestrować i usunąć serwery. Uwaga: w razie potrzeby zmień typy i pod.

    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. Wyrejestruj typ serwera: 
      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

    Weryfikacja

    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 portów zarządzania. 
      curl -v http://MS_IP:8080/v1/servers/self
    3. Sprawdź grupę w Statystykach. 
      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 danego 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. Na jednym węźle ZooKeepera 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ź dzienniki komponentów, aby upewnić się, że nie ma w nich błędów.