Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Erreurs de perte de connexion Zookeeper

Vous consultez la documentation Apigee Edge.
Accédez à la documentation Apigee X. info

Problème constaté

Les problèmes de connectivité ZooKeeper peuvent se manifester par différents symptômes, tels que :

Erreurs de déploiement du proxy d'API
Échec des appels de l'API Management avec des erreurs 5XX
Échec du démarrage des routeurs ou des processeurs de messages
Les composants d'analyse signalent une perte de connexion ZooKeeper dans system.logs

Messages d'erreur

Vous trouverez ci-dessous des exemples de messages d'erreur qui peuvent s'afficher en cas de perte de connexion à un ou plusieurs nœuds ZooKeeper.

L'erreur suivante est renvoyée dans les journaux du serveur de gestion lorsqu'un déploiement de proxy d'API échoue en raison d'une perte de connexion ZooKeeper :

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

Au démarrage, les routeurs et les processeurs de messages se connectent à ZooKeeper. En cas de problèmes de connectivité avec ZooKeeper, ces composants ne pourront pas démarrer et l'erreur suivante s'affichera :

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]

L'interface utilisateur Edge peut afficher l'erreur suivante indiquant qu'elle n'a pas pu vérifier l'état de déploiement des proxys d'API :
```
Error Fetching Deployments
Error while checking path existence for path: path
```

Causes possibles

Le tableau suivant répertorie les causes possibles de ce problème :

Cause	Pour
Problème de connectivité réseau entre différents centres de données	Utilisateurs de Cloud privé Edge
Nœud ZooKeeper ne traitant pas les requêtes	Utilisateurs de Cloud privé Edge

Cliquez sur un lien du tableau pour afficher les solutions possibles à cette cause.

Problème de connectivité réseau entre différents centres de données

Diagnostic

Un cluster ZooKeeper peut comporter des nœuds répartis sur plusieurs régions/centres de données, tels que DC-1 et DC-2. La topologie Apigee Edge 2 DC typique comprendra :

Les serveurs ZooKeeper 1, 2 et 3 en tant que votants dans DC-1
ZooKeeper 4 et 5 en tant que votants, et ZooKeeper 6 en tant qu'observateur dans DC-2.

Si la région DC-1 est en panne ou si la connectivité réseau entre DC-1 et DC-2 est interrompue, alors les nœuds ZooKeeper ne peuvent pas élire de nouveau responsable dans DC-2 et ne peuvent pas communiquer avec le nœud responsable. Les observateurs ZooKeeper ne peuvent pas élire de nouveau responsable, et les deux votants restants dans DC-2 ne disposent pas d'un quorum d'au moins trois nœuds votants pour élire un nouveau responsable. Par conséquent, les ZooKeeper de DC-2 ne pourront pas traiter les requêtes. Les nœuds ZooKeeper restants dans DC-2 continueront de boucler en tentant de se reconnecter aux votants ZooKeeper pour trouver le responsable.

Solution

Appliquez les solutions suivantes dans l'ordre spécifié pour résoudre ce problème.

Si vous ne parvenez pas à résoudre le problème après avoir essayé ces solutions, veuillez contacter l'assistance Apigee.

Solution 1

Collaborez avec vos administrateurs réseau pour résoudre le problème de connectivité réseau entre les centres de données.
Lorsque l'ensemble ZooKeeper peut communiquer entre les centres de données et élire un responsable ZooKeeper, les nœuds doivent devenir opérationnels et être en mesure de traiter les requêtes.

Solution 2

Si la réparation de la connectivité réseau prend du temps, vous pouvez contourner le problème en reconfigurant les nœuds ZooKeeper dans la région où ils sont en panne. Par exemple, reconfigurez le cluster ZooKeeper dans DC-2 afin que les trois nœuds ZooKeeper de cette région soient tous des votants et supprimez le server.# dans le zoo.cfg des ZooKeeper de la région DC-1.
1. Dans l'exemple suivant, zoo.cfg configure les nœuds pour deux régions où DC-1 utilise des noms d'hôte us-ea indiquant la région US-East et DC-2 utilise des noms d'hôte us-wo indiquant la région US-West. (REMARQUE : Seules les configurations pertinentes sont affichées) :
```
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
```
  Dans l'exemple ci-dessus, reconfigurez le zoo.cfg comme suit :
```
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. À l'aide du code avec la configuration, créez un fichier /opt/apigee/customer/application/zookeeper.properties avec le contenu suivant :
```
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\
```
Dans l'exemple ci-dessus, les nœuds de la région US-East sont supprimés, et les nœuds de la région US-West sont promus en votants lorsque l'annotation :observer est supprimée.
Sauvegardez /opt/apigee/apigee-zookeeper/conf/zoo.cfg et l'ancien /opt/apigee/customer/application/zookeeper.properties.
Ces fichiers seront utilisés pour restaurer les valeurs par défaut lorsque la connectivité réseau sera rétablie entre les centres de données.
Désactivez la notation de l'observateur pour le nœud de l'observateur. Pour ce faire, ajoutez la configuration suivante en haut de /opt/apigee/customer/application/zookeeper.properties :
```
conf_zoo_peertype=
```
Modifiez le fichier /opt/apigee/data/apigee-zookeeper/data/myid comme suit :
- Pour server.1, remplacez l'entrée dans myid de 4 à 1.
- Pour server.2, remplacez le myid de 5 à 2.
- Pour server.3, remplacez le myid de 6 à 3.
Redémarrez les nœuds ZooKeeper dans la région où vous avez reconfiguré le cluster ZooKeeper.
Répétez la configuration ci-dessus de l'étape 1b à l'étape 5 sur tous les nœuds ZooKeeper de DC-2.
Validez que les nœuds sont opérationnels avec un responsable :
```
$ 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
```
Le résultat de cette commande contiendra une ligne indiquant "mode" suivie de "leader" s'il s'agit du responsable, ou de "follower" s'il s'agit d'un suiveur.

Lorsque le réseau entre les centres de données est rétabli, les modifications de configuration ZooKeeper peuvent être annulées sur les nœuds ZooKeeper de DC-2.

REMARQUE : Une fois la connectivité réseau rétablie et le cluster ZooKeeper devant être rétabli par défaut avec les deux centres de données reconnectés, annulez les modifications apportées aux fichiers /opt/apigee/customer/application/zookeeper.properties et /opt/apigee/data/apigee-zookeeper/data/myid, puis redémarrez ZooKeeper.

Solution 3

Si un ou plusieurs nœuds ZooKeeper du cluster ne sont pas démarrés, redémarrez-les.

Consultez les journaux ZooKeeper pour déterminer pourquoi le nœud ZooKeeper est tombé en panne.

Les journaux ZooKeeper sont disponibles dans le répertoire suivant :

$ 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

Contactez l'assistance Apigee et fournissez les journaux ZooKeeper pour résoudre la cause de l'arrêt éventuel d'un nœud ZooKeeper.

Nœud ZooKeeper ne traitant pas les requêtes

Un nœud ZooKeeper de l'ensemble peut devenir non opérationnel et ne pas pouvoir répondre aux requêtes du client. Les raisons peuvent être multiples :

Le nœud a été arrêté sans être redémarré.
Le nœud a été redémarré sans que le démarrage automatique soit activé.
La charge système sur le nœud a entraîné sa panne ou son dysfonctionnement.

Diagnostic

Exécutez les commandes de vérification de l'état ZooKeeper suivantes sur chacun des nœuds ZooKeeper et vérifiez le résultat :

```
$ echo "ruok" | nc localhost 2181
```
Remarque : REMARQUE : La réponse "imok" est une réponse positive.

Exemple de résultat :
```
$ echo "ruok" | nc localhost 2181
imok
```

echo srvr | nc localhost 2181

Vérifiez le mode pour déterminer si le nœud ZooKeeper est un responsable ou un suiveur.

Exemple de résultat pour un nœud ZooKeeper unique tout-en-un :

$ 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

$ echo mntr | nc localhost 2181

Cette commande répertorie les variables ZooKeeper qui peuvent être utilisées pour vérifier l'état du cluster ZooKeeper.

Exemple de résultat :

$ 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

$ echo stat | nc localhost 2181

Cette commande répertorie les statistiques sur les performances et les clients connectés.

Exemple de résultat :

$ 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

$ echo cons | nc localhost 2181

Cette commande fournit des informations détaillées sur les connexions ZooKeeper.

Exemple de résultat :

$ 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)

Si l'une des trois dernières commandes de vérification de l'état affiche le message suivant :

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

Cela indique qu'un ou plusieurs nœuds ZooKeeper spécifiques ne traitent pas les requêtes.

Consultez les journaux ZooKeeper sur le nœud spécifique et essayez de localiser les erreurs qui entraînent la panne de ZooKeeper. Les journaux ZooKeeper sont disponibles dans le répertoire suivant :

$ 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

Solution

Redémarrez tous les autres nœuds ZooKeeper du cluster un par un.
Réexécutez les commandes de vérification de l'état ZooKeeper sur chaque nœud et vérifiez si vous obtenez le résultat attendu.

Contactez l'assistance Apigee pour résoudre la cause de la charge système si elle persiste ou si les redémarrages ne résolvent pas le problème.