Błędy utraty połączenia z Zookeeper

Wyświetlasz dokumentację Apigee Edge.
Przejdź do dokumentacji Apigee X.
info

Krótki opis problemu

Problemy z połączeniem z ZooKeeper mogą objawiać się różnymi symptomami, takimi jak:

  1. błędy wdrażania serwera proxy interfejsu API,
  2. nieudane wywołania interfejsu API zarządzania Google Analytics z błędami 5XX,
  3. nieudane uruchomienie routerów lub procesorów wiadomości,
  4. komponenty Analytics zgłaszają utratę połączenia z ZooKeeper w system.logs.

Komunikaty o błędach

Poniżej znajdziesz przykłady komunikatów o błędach, które mogą się pojawić w przypadku utraty połączenia z węzłami ZooKeeper.

  1. Gdy wdrożenie serwera proxy interfejsu API nie powiedzie się z powodu utraty połączenia z ZooKeeper, w logach serwera zarządzania pojawi się ten błąd:
    org: env: main INFO ZOOKEEPER - ZooKeeperServiceImpl.exists() :
    Retry path existence path:
      /regions/dc-1/pods/analytics/servers/692afe93-8010-45c6-b37d-e4e05b6b2eb5/reachable,
      reason: KeeperErrorCode = ConnectionLoss
    org: env: main ERROR ZOOKEEPER - ZooKeeperServiceImpl.exists() :
      Could not detect existence of path:
      /regions/dc-1/pods/analytics/servers/692afe93-8010-45c6-b37d-e4e05b6b2eb5/reachable ,
      reason: KeeperErrorCode = ConnectionLoss
    org: env: main ERROR KERNEL.DEPLOYMENT - ServiceDeployer.startService() :
      ServiceDeployer.deploy() : Got a life cycle exception while starting service
      [ServerRegistrationService, Error while checking path existence for path :
      /regions/dc-1/pods/analytics/servers/692afe93-8010-45c6-b37d-e4e05b6b2eb5/reachable] :
      com.apigee.zookeeper.ZooKeeperException{ code = zookeeper.ErrorCheckingPathExis tence,
      message = Error while checking path existence for path :
      /regions/dc-1/pods/analytics/servers/692afe93-8010-45c6-b37d-e4e05b6b2eb5/reachable,
      associated contexts = []} 2015-03-25 10:22:39,811
    org: env: main ERROR KERNEL - MicroKernel.deployAll() : MicroKernel.deployAll() :
    Error in deploying the deployment : EventService com.apigee.zookeeper.ZooKeeperException:
    Error while checking path existence for path :
      /regions/dc-1/pods/analytics/servers/692afe93-8010-45c6-b37d-e4e05b6b2eb5/reachable
      at com.apigee.zookeeper.impl.ZooKeeperServiceImpl.exists(ZooKeeperServiceImpl.java:339)
      ~[zookeeper-1.0.0.jar:na] at com.apigee.zookeeper.impl.ZooKeeperServiceImpl.exists(
      ZooKeeperServiceImpl.java:323) ~[zookeeper-1.0.0.jar:na] at ... snipped
  2. Podczas uruchamiania routery i procesory wiadomości łączą się z ZooKeeper. Jeśli występują problemy z połączeniem z ZooKeeper, te komponenty nie uruchomią się i pojawi się ten błąd:
    2017-08-01 23:20:00,404  CuratorFramework-0 ERROR o.a.c.f.i.CuratorFrameworkImpl
      - CuratorFrameworkImpl.logError() : Background operation retry gave up
    org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss
      at org.apache.zookeeper.KeeperException.create(KeeperException.java:99) ~[zookeeper-3.4.6.jar:3.4.6-1569965]
      at org.apache.curator.framework.imps.CuratorFrameworkImpl.checkBackgroundRetry(CuratorFrameworkImpl.java:710) [curator-framework-2.5.0.jar:na]
      at org.apache.curator.framework.imps.CuratorFrameworkImpl.performBackgroundOperation(CuratorFrameworkImpl.java:827) [curator-framework-2.5.0.jar:na]
      at org.apache.curator.framework.imps.CuratorFrameworkImpl.backgroundOperationsLoop(CuratorFrameworkImpl.java:793) [curator-framework-2.5.0.jar:na]
      at org.apache.curator.framework.imps.CuratorFrameworkImpl.access$400(CuratorFrameworkImpl.java:57) [curator-framework-2.5.0.jar:na]
      at org.apache.curator.framework.imps.CuratorFrameworkImpl$4.call(CuratorFrameworkImpl.java:275) [curator-framework-2.5.0.jar:na]
      at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_131]
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_131]
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_131]
      at java.lang.Thread.run(Thread.java:748) [na:1.8.0_131]
  3. W interfejsie Edge może się pojawić ten błąd wskazujący, że nie udało się sprawdzić stanu wdrożenia serwerów proxy interfejsu API:
    Error Fetching Deployments
    Error while checking path existence for path: path

Możliwe przyczyny

W tabeli poniżej znajdziesz możliwe przyczyny tego problemu:

Przyczyna Dla
Problem z połączeniem sieciowym w różnych centrach danych Użytkownicy Edge Private Cloud
Węzeł ZooKeeper nie obsługuje żądań Użytkownicy Edge Private Cloud

Kliknij link w tabeli, aby zobaczyć możliwe rozwiązania tego problemu.

Problem z połączeniem sieciowym w różnych centrach danych

Diagnostyka

Klaster ZooKeeper może mieć węzły, które obejmują wiele regionów lub centrów danych, np. DC-1 i DC-2. Typowa topologia Apigee Edge 2 DC będzie zawierać:

  • serwery ZooKeeper 1, 2 i 3 jako węzły głosujące w DC-1;
  • ZooKeeper 4 i 5 jako węzły głosujące oraz ZooKeeper 6 jako węzeł obserwujący w DC-2.

Jeśli region DC-1 przestanie działać lub połączenie sieciowe między DC-1 a DC-2 zostanie przerwane, wówczas węzły ZooKeeper nie będą mogły wybrać nowego lidera w DC-2 i nie będą mogły komunikować się z węzłem lidera. Węzły obserwujące ZooKeeper nie mogą wybrać nowego lidera, a 2 pozostałe węzły głosujące w DC-2 nie mają kworum co najmniej 3 węzłów głosujących, aby wybrać nowego lidera. W związku z tym węzły ZooKeeper w DC-2 nie będą mogły przetwarzać żadnych żądań. Pozostałe węzły ZooKeeper w DC-2 będą nadal próbować połączyć się z węzłami głosującymi ZooKeeper, aby znaleźć lidera.

Rozdzielczość

Aby rozwiązać ten problem, zastosuj te rozwiązania w podanej kolejności.

Jeśli po wypróbowaniu tych rozwiązań nie uda Ci się rozwiązać problemu, skontaktuj się z zespołem pomocy Apigee.

Rozwiązanie 1

  1. Skontaktuj się z administratorami sieci, aby rozwiązać problem z połączeniem sieciowym między centrami danych.
  2. Gdy zespół ZooKeeper będzie mógł komunikować się między centrami danych i wybrać a lidera ZooKeeper, węzły powinny stać się sprawne i móc przetwarzać żądania.

Rozwiązanie 2

  1. Jeśli naprawa połączenia sieciowego zajmie trochę czasu, możesz ponownie skonfigurować węzły ZooKeeper w regionie, w którym nie działają. Na przykład ponownie skonfiguruj klaster ZooKeeper w DC-2, tak aby wszystkie 3 węzły ZooKeeper w tym regionie były węzłami głosującymi, i usuń server.# w zoo.cfg węzłów ZooKeeper z regionu DC-1.
    1. W tym przykładzie zoo.cfg konfiguruje węzły w 2 regionach, w których DC-1 używa us-ea nazw hostów oznaczających region wschodni Stanów Zjednoczonych, a DC-2 używa us-wo nazw hostów oznaczających region zachodni Stanów Zjednoczonych. (UWAGA: wyświetlane są tylko odpowiednie konfiguracje):
      server.1=zk01ea.us-ea.4.apigee.com:2888:3888
      server.2=zk02ea.us-ea.4.apigee.com:2888:3888
      server.3=zk03ea.us-ea.4.apigee.com:2888:3888
      server.4=zk04wo.us-wo.4.apigee.com:2888:3888
      server.5=zk05wo.us-wo.4.apigee.com:2888:3888
      server.6=zk06wo.us-wo.4.apigee.com:2888:3888:observer

      W powyższym przykładzie ponownie skonfiguruj zoo.cfg w ten sposób:

      server.1=zk04wo.us-wo.4.apigee.com:2888:3888
      server.2=zk05wo.us-wo.4.apigee.com:2888:3888
      server.3=zk06wo.us-wo.4.apigee.com:2888:3888
    2. Używając kodu z konfiguracją, utwórz plik /opt/apigee/customer/application/zookeeper.properties z tymi treściami:
      conf_zoo_quorum=server.1=zk04wo.us-wo.4.apigee.com:2888:3888\
      \nserver.2=zk05wo.us-wo.4.apigee.com:2888:3888\
      \nserver.3=zk06wo.us-wo.4.apigee.com:2888:3888\

    W powyższym przykładzie węzły z regionu wschodniego Stanów Zjednoczonych są usuwane, a węzły z regionu zachodniego Stanów Zjednoczonych są promowane na węzły głosujące po usunięciu adnotacji :observer.

  2. Utwórz kopię zapasową pliku /opt/apigee/apigee-zookeeper/conf/zoo.cfg i starego pliku /opt/apigee/customer/application/zookeeper.properties.

    Te pliki będą używane do przywracania ustawień domyślnych, gdy połączenie sieciowe między centrami danych zostanie przywrócone.

  3. Wyłącz adnotację obserwatora dla węzła obserwatora. Aby to zrobić, dodaj tę konfigurację na początku pliku /opt/apigee/customer/application/zookeeper.properties:

    conf_zoo_peertype=
  4. Edytuj plik /opt/apigee/data/apigee-zookeeper/data/myid w ten sposób:

    • W przypadku server.1 zmień wpis w myid z 4 na 1.
    • W przypadku server.2 zmień myid z 5 na 2.
    • W przypadku server.3 zmień myid z 6 na 3.
  5. Uruchom ponownie węzły ZooKeeper w regionie, w którym ponownie skonfigurowano klaster ZooKeeper.
  6. Powtórz powyższą konfigurację od kroku 1b do kroku 5 we wszystkich węzłach ZooKeeper w DC-2.
  7. Sprawdź, czy węzły są uruchomione z liderem:
    $ echo srvr | nc zk04wo.us-wo.4.apigee.com 2181
    > echo srvr | nc zk05wo.us-wo.4.apigee.com 2181
    > echo srvr | nc zk06wo.us-wo.4.apigee.com 2181

    Wynik tego polecenia będzie zawierać wiersz z tekstem „mode” i „leader”, jeśli jest to lider, lub „follower”, jeśli jest to węzeł podrzędny.

    Gdy połączenie sieciowe między centrami danych zostanie przywrócone, zmiany konfiguracji ZooKeeper można cofnąć w węzłach ZooKeeper w DC-2.

Rozwiązanie 3

  1. Jeśli węzeł lub węzły ZooKeeper w klastrze nie zostały uruchomione, uruchom je ponownie.
  2. Sprawdź logi ZooKeeper, aby ustalić, dlaczego węzeł ZooKeeper przestał działać.

    Logi ZooKeeper są dostępne w tym katalogu:

    $ cd /opt/apigee/var/log/apigee-zookeeper
    $ ls -l
    total 188
    -rw-r--r--. 1 apigee apigee   2715 Jul 22 19:51 apigee-zookeeper.log
    -rw-r--r--. 1 apigee apigee  10434 Jul 17 19:51 config.log
    -rw-r--r--. 1 apigee apigee 169640 Aug  1 19:51 zookeeper.log
  3. Skontaktuj się z zespołem pomocy Apigee i prześlij logi ZooKeeper, aby rozwiązać problem z węzłem ZooKeeper, który mógł zostać zatrzymany.

Węzeł ZooKeeper nie obsługuje żądań

Węzeł ZooKeeper w zespole może stać się niesprawny i nie będzie mógł odpowiadać na żądania klientów. Może to być spowodowane tym, że:

  1. węzeł został zatrzymany bez ponownego uruchomienia;
  2. węzeł został ponownie uruchomiony bez włączonego automatycznego uruchamiania;
  3. obciążenie systemu w węźle spowodowało jego awarię lub niesprawność.

Diagnostyka

  1. Uruchom te polecenia sprawdzania stanu ZooKeeper w każdym węźle ZooKeeper i sprawdź dane wyjściowe:
    1. $ echo "ruok" | nc localhost 2181

      Przykładowe dane wyjściowe:

      $ echo "ruok" | nc localhost 2181
      imok
    2. echo srvr | nc localhost 2181

      Sprawdź tryb, aby ustalić, czy węzeł ZooKeeper jest liderem czy węzłem podrzędnym.

      Przykładowe dane wyjściowe dla pojedynczego węzła ZooKeeper typu „wszystko w jednym”:

      $ echo srvr | nc localhost 2181
      ZooKeeper version: 3.4.5-1392090, built on 09/30/2012 17:52 GMT
      Latency min/avg/max: 0/0/88
      Received: 4206601
      Sent: 4206624
      Connections: 8
      Outstanding: 0
      Zxid: 0x745
      Mode: standalone
      Node count: 282
    3. $ echo mntr | nc localhost 2181

      To polecenie wyświetla listę zmiennych ZooKeeper, których można użyć do sprawdzenia stanu klastra ZooKeeper.

      Przykładowe dane wyjściowe:

      $ echo mntr | nc localhost 2181
      zk_version 3.4.5-1392090, built on 09/30/2012 17:52 GMT
      zk_avg_latency 0
      zk_max_latency 88
      zk_min_latency 0
      zk_packets_received     4206750
      zk_packets_sent 4206773
      zk_num_alive_connections 8
      zk_outstanding_requests 0
      zk_server_state standalone
      zk_znode_count 282
      zk_watch_count 194
      zk_ephemerals_count 1
      zk_approximate_data_size 22960
      zk_open_file_descriptor_count 34
      zk_max_file_descriptor_count 4096
    4. $ echo stat | nc localhost 2181

      To polecenie wyświetla statystyki dotyczące wydajności i połączonych klientów.

      Przykładowe dane wyjściowe:

      $ echo stat | nc localhost 2181
      ZooKeeper version: 3.4.5-1392090, built on 09/30/2012 17:52 GMT
      Clients:
       /10.128.0.8:54152[1](queued=0,recved=753379,sent=753385)
       /10.128.0.8:53944[1](queued=0,recved=980269,sent=980278)
       /10.128.0.8:54388[1](queued=0,recved=457094,sent=457094)
       /10.128.0.8:54622[1](queued=0,recved=972938,sent=972938)
       /10.128.0.8:54192[1](queued=0,recved=150843,sent=150843)
       /10.128.0.8:44564[1](queued=0,recved=267332,sent=267333)
       /127.0.0.1:40820[0](queued=0,recved=1,sent=0)
       /10.128.0.8:53960[1](queued=0,recved=150844,sent=150844)
      
      Latency min/avg/max: 0/0/88
      Received: 4206995
      Sent: 4207018
      Connections: 8
      Outstanding: 0
      Zxid: 0x745
      Mode: standalone
      Node count: 282
    5. $ echo cons | nc localhost 2181

      To polecenie zawiera szczegółowe informacje o połączeniach ZooKeeper.

      Przykładowe dane wyjściowe:

      $ echo cons | nc localhost 2181
      /127.0.0.1:40864[0](queued=0,recved=1,sent=0)
      /10.128.0.8:54152[1](queued=0,recved=753400,sent=753406,sid=0x15d521a96d40007,
        lop=PING,est=1500321588647,to=40000,lcxid=0x972e9,lzxid=0x745,lresp=1502334173174,
        llat=0,minlat=0,avglat=0,maxlat=26)
      /10.128.0.8:53944[1](queued=0,recved=980297,sent=980306,sid=0x15d521a96d40005,
        lop=PING,est=1500321544896,to=40000,lcxid=0xce92a,lzxid=0x745,lresp=1502334176055,
        llat=0,minlat=0,avglat=0,maxlat=23)
      /10.128.0.8:54388[1](queued=0,recved=457110,sent=457110,sid=0x15d521a96d4000a,
        lop=PING,est=1500321673852,to=40000,lcxid=0x4dbe3,lzxid=0x745,lresp=1502334174245,
        llat=0,minlat=0,avglat=0,maxlat=22)
      /10.128.0.8:54622[1](queued=0,recved=972967,sent=972967,sid=0x15d521a96d4000b,
        lop=PING,est=1500321890175,to=40000,lcxid=0xccc9d,lzxid=0x745,lresp=1502334182417,
        llat=0,minlat=0,avglat=0,maxlat=88)
      /10.128.0.8:54192[1](queued=0,recved=150848,sent=150848,sid=0x15d521a96d40008,
        lop=PING,est=1500321591985,to=40000,lcxid=0x8,lzxid=0x745,lresp=1502334184475,
        llat=3,minlat=0,avglat=0,maxlat=19)
      /10.128.0.8:44564[1](queued=0,recved=267354,sent=267355,sid=0x15d521a96d4000d,
        lop=PING,est=1501606633426,to=40000,lcxid=0x356e2,lzxid=0x745,lresp=1502334182315,
        llat=0,minlat=0,avglat=0,maxlat=35)
      /10.128.0.8:53960[1](queued=0,recved=150848,sent=150848,sid=0x15d521a96d40006,
        lop=PING,est=1500321547138,to=40000,lcxid=0x5,lzxid=0x745,lresp=1502334177036,
        llat=1,minlat=0,avglat=0,maxlat=20)

      Jeśli którekolwiek z 3 ostatnich poleceń sprawdzania stanu wyświetli ten komunikat:

      $ echo stat | nc localhost 2181
          This ZooKeeper instance is not currently serving requests

      oznacza to, że określony węzeł lub węzły ZooKeeper nie obsługują żądań.

  2. Sprawdź logi ZooKeeper w konkretnym węźle i spróbuj znaleźć błędy powodujące awarię ZooKeeper. Logi ZooKeeper są dostępne w tym katalogu:
    $ cd /opt/apigee/var/log/apigee-zookeeper
    $ ls -l
    total 188
    -rw-r--r--. 1 apigee apigee   2715 Jul 22 19:51 apigee-zookeeper.log
    -rw-r--r--. 1 apigee apigee  10434 Jul 17 19:51 config.log
    -rw-r--r--. 1 apigee apigee 169640 Aug  1 19:51 zookeeper.log

Rozdzielczość

  1. Uruchom ponownie wszystkie inne węzły ZooKeeper w klastrze, jeden po drugim.
  2. Ponownie uruchom polecenia sprawdzania stanu ZooKeeper w każdym węźle i sprawdź, czy uzyskujesz oczekiwane dane wyjściowe.

Jeśli problem z obciążeniem systemu będzie się powtarzać lub ponowne uruchomienie nie rozwiąże problemu, skontaktuj się z zespołem pomocy Apigee.