Problème sync + Endpoints et blockstamp sur deux noeuds avec clé identique

Support Duniter-v1
1

Bonjour à tous,

J’ai actuellement deux nœuds membres en 1.8.1 duniter.lucho14.website et duniter2.lucho14.website

J’ai souvent des problèmes de fork qui ne se résolvent pas (presque tous les 2 jours), des blocs de chaque chemin étant marqués comme invalide. J’ai déjà resynchro, réinstallé from scratch etc … et rien n’y fait. De mémoire le problème est apparu avec la mise en route du second nœud, je n’ai pas souvenir d’avoir autant de problème avec un seul nœud.
Par ailleurs, mes nœuds ont souvent 2 ou 3 bloc d’écarts

En regardant, l’interface web de monitoring des nœuds, il n’est pas rare de voir aucune connexion (entrante et sortante), j’ai essayer d’augmenter le nombre de connexions possibles mais le problème perdure. (initialement à 3 suite aux conseils vu dans un billet pour ne pas saturer le réseau)

Suite à la lecture de ce billet : miner-des-blocs - cles-partagees n’ai-je pas un problème du genre avec la diffusion des endpoints ?

J’ai l’impression que mes nœuds n’arrête pas de mettre à jour leurs endpoints, le bloc associé n’arrête pas de s’incrémenter (quelques heures après le démarrage des nœuds le numéro de bloc est identique sur les deux nœuds mais ce n’est pas le cas au départ). A l’heure actuelle, les endpoints de l’un sont bien synchronisés sur l’autre (ca met plusieurs heures), mais les « blockstamp » continuent de s’incrémenter. Est-ce un comportement normal ?
N.B : il n’y a actuellement qu’un endpoint BMAS de déclaré.

J’ai aussi souvent des problèmes de « freeze » des nœuds, ceux-ci ne répondent pas pendant plusieurs secondes puis répondent à nouveau (que ce soit sur l’interface web de monitoring ou sur l’interface BMA) je n’ai rien vu de particulier dans les logs.

Quelqu’un aurait une solution ?

1 Like
2

Commence par éteindre le second nœud, pour voir si le premier nœud fonctionne correctement.

Une fois assuré du bon fonctionnement du premier nœud (sur une semaine par exemple), tu pourras relancer le second et observer les problèmes potentiels.

2 Likes
3

Yes, je vais retester au cas où. Le second nœud est coupé et j’ai basculé mon monitoring sur g1.duniter.org

1 Like
4

Oui le mécanisme de peer partagé mis en place par cgeek à l’époque de BMA pose de plus en plus de problèmes.
Moi aussi j’avais plusieurs nœuds avec la même clé et j’ai arrêté pour les mêmes raisons.

Je compte supprimer ce mécanisme de peer partagé pour la nouvelle couche réseau DUNPv2, en attendant, faut éviter le multi-nœud.

2 Likes
5

Je ne suis donc pas fou :sweat_smile:

Les blockstamps continus de s’incrémenter et j’ai encore les endpoints du nœud arrêté. Si ca ne va pas mieux ce soir en rentrant, je supprimerai les EP manuellement et au pire on verra avec une réinstallation toute propre.

6

@bpresles Peut-tu faire une explication pour les geeks pour expliquer comment tu fais pour avoir un nœud qui fonctionne sans jamais avoir de problèmes.
Parce dire aux gens connectez vous aux nœuds de Bertrand n’est pas une solution.

7

Le problème est vraiment sur du multi-nœud.
Depuis que j’ai coupé le second ca va beaucoup mieux, je n’ai quasiment plus de retard sur la blockchain au pire un bloc pour quelques minutes alors qu’en plus le nœud est à moitié en vrac : timeout sur les connexion entrante ?! et les blockstamps qui s’emballent toujours.

Je vais réinstaller entièrement le nœud ce soir, sur un nouveau container tout neuf.

8

Je confirme, une réinstallation est tout fonctionne beaucoup mieux, j’ai bien des connexions entrantes sans timeout maintenant plus de desynchro tout roule.

Par contre j’ai toujours une incrémentation des blockstamps. C’est normal qu’un nœud publie une nouvelle fiche de pair régulièrement alors qu’il n’y a pas de changement ?

1 Like
9

Oui c’est une feature

1 Like
10

Hello,

Besoin d’un coup de main :pray: j’ai toujours des problèmes avec mon nœud.

Comme expliqué dans un autre sujet, j’ai mis en place un monitoring sur les différents endpoints de mon nœud afin d’essayer de diagnostiquer les problèmes de timeout que j’ai.

Je l’ai changé d’host pour voir mais ce n’est pas mieux, ca n’a pas l’air d’être un problème matériel…
(mon nœud est sur un container LXC sur un cluster Proxmox)

Par ailleurs, en bossant sur le script pour checker les endpoints ws2p des différents nœuds (voir les échanges avec @elois du sujet cité ci-dessus), j’ai refait propre et j’utilise DuniterPy. Quand je fais un
network.get_available_nodes()
en utilisant mon nœud, je n’ai que mon nœud en réponse. Alors qu’en utilisant un autre nœud j’ai bien tous le réseau.
En regardant ce que fais la fonction, le problème viendrait de ws2p_head qui ne renvoi qu’un élément chez moi alors que chez les autres c’est plein.

Tout est peut-être lié ^^

Bref, je ne sais plus quoi faire si quelqu’un à une idée…

Mon fichier de config au cas ou : conf.json et les logs (level: trace)

11

Je ne suis encore que débutant sur la conf de noeud duniter, mais il y a des choses qui me choquent dans ton fichier de conf, au niveau des ports pour le BMA. Tu as :

 "endpoints": [
  "BMAS duniter.lucho14.website 443"
 ],
 "port": "9220",
 "remoteport": "9220",

Le port 9220 est dédié à l’interface web. Il ne devrait donc rien avoir à faire là. À titre de comparaison voici ce que j’ai pour mon fichier :

  "endpoints": [],
  "port": 10901,
  "remoteport": 443,

Mais puisqu’il s’agit de BMA, je suis probablement hors sujet sur la question initiale qui est relative au WS2P…

2 Likes
12

Si je ne dis pas de bêtises
La config « remoteport » est pour le endpoint standard ‹ BASIC_MERKLE_API › qui est bien sur le port 9220 chez moi.

Derrière j’utilise un proxy apache sur le port 443 afin de faire du BMAS c’est pour cela que je l’annonce dans les endpoints.

13

OK, si c’est voulu comme ça, pourquoi pas. C’est juste déroutant de voir le port de l’interface web utilisé à la place du port par défaut pour BMA (10901). Je ne suis pas certain non plus de l’intérêt de maintenir un endpoint BMA quand tu as un BMAS.

1 Like
14

Tu n’as pas tord :), je crois que ça date de mes débuts, je cherchais des Tuto et j’ai du mélanger les ports… depuis j’ai gardé comme ça :smiley:

15

Non le remote port doit être le port utilisé par l’extérieur pour te contacter, pas le port interne, donc ça devrait valoir 443.

16

Sauf s’il veut absolument BMA et BMAS. Mais dans ce cas il me semblerait plus logique d’utiliser le port 80 afin qu’il passe aussi par le reverse proxy.

17

Si c’est bien pour BMA et non BMAS c’est bien 9220 en interne et externe (niveau config routeur).

Si je passe le remoteport en 443, ca désactive BMA et considère que c’est du BMAS ?

18

Non pas spécialement BMA, je le gardais pour « compatibilité », si il n’est pas nécessaire ça va dégager.

La config chez moi est un peu compliqué niveau reverse proxy comme il faut du 443 en remote port…

Le 443 arrive sur un synology qui redirige les différents domaines la où il faut. Et du coup redirige aussi duniter. Mais comme ca ne gère pas les redirection en fonction d’un path (cas du /ws2p par exemple) ca rebondit sur un apache dédié pour duniter… donc double proxy pour ce qui est sur le 443 :sweat_smile:

Mais je ne pense pas que le problème général de mon nœud vienne des ports utilisés. Je vais toute fois utiliser les ports habituels et dégager BMA. Heu on fait comment our dégager BMA ? remoteport en 443 ca suffit ?

19

Ça ne sert à rien d’avoir deux endpoints BMA. Garde que celui qui est sécurisé.

Oui déclarer un remote port en 443 est censé suffire, si d’anciens endpoint non pertinent persiste tu peux les virer avec l’option --remep :slight_smile:

20

Effectivement le remote port en 443 suffit. Par contre, le endpoint généré automatiquement pour BMAS contient l’host et l’ip. Comment est utilisé l’ip ? Car si c’est l’ip qui est utilisé et non l’host, ca n’arrivera jamais jusqu’à duniter à cause du premier proxy.
Ce qui m’oblige à utiliser un port différent que le 443