プライベートノードはパブリックノードから切断され続けます

Update 3/21/19コア開発者は、366f64f3df266cf02a06412d6760f73626d0a2bfブランチでのmainnet commitの時点で、以下で説明するこの問題に対処する修正をプッシュしました.

ノードが--private-modeにある設定(ベイクする) フロント(パブリック)ノードに接続する場合は、明示的に設定する必要があります フロントノードがプライベートノードを信頼する(--peer引数を使用) tezos-nodeまたはtezos-nodeまたはRPCの設定ファイル)！そうしないと、 ある時点で、フロントノードが次のことを決定する可能性があります. 新しいものを優先して、プライベートノードから自分自身を切断します ピア.バグは、切断のケースがあったということでした 信頼できるプライベートピア(ノードが優先していたため、実際には表示されません 新しい接続よりも古い接続ですが、それでも).私たちは今それらを保護しました 接続.

基本的に、プライベートノードをパブリックノードのピアとして設定できる新機能があります.これにより、パブリックノード上の新しいピアよりもプライベートノードが優先されます.

元の回答

この問題は最初からありました.この問題は、プライベートノードがパブリックノード内の他のすべてのピアと同じように扱われることに起因します(信頼できるものとして設定する場合でも).基本的に、プライベートノードの優先順位は高くなく、パブリックノードがプライベートノードの「有用性」が他のノードよりも低いと判断する場合があります.つまり、プライベートノードは単なるリーチャーであり、パブリックノードに実際に貢献していないため、パブリックノードがネットワーク内の別のノードのプライベートノードを切断する可能性があります.また、プライベートノードが正しく機能しない、リソースを大量に消費するなど、何らかの理由で「誤動作」した場合、パブリックノードはそれをグレーリストに登録し、プライベートノードからの接続を許可しない可能性があります.信頼できるものとして設定すると、それが軽減されるはずですが！

私たちのほとんどの初期のパン屋は、冗長性(パブリックノード)の数を増やすことでこの問題を解決しているため、切断しても大したことではなく、遅かれ早かれ再接続する必要があります.一般に、これはノードをアップグレードする必要があり、冗長性がないとプロセスが非常に複雑になるため、良い考えだと思います.最近では、初期の頃とは異なり、プライベートノードが切断されることはほとんどありません.私の疑惑は、プライベートノードが「信頼性」を獲得した可能性があるということです.これは、グレーリストに登録されるのとは逆です.

中断のない優先接続を保証できる新機能が追加されるまで、最善の選択肢は、パブリックノードを増やすか、信頼できるノードとして基盤ノード(信頼できる可能性が高い)を追加することだけです. quicksync を試すか、チェーンデータをプライベートノードにコピーして、コピーしないようにすることもできます.プライベートノードをブートストラップする必要があります.同期プロセス中に、必要なリソースが原因で切断される可能性があります.問題は、パブリックノードがノードを切断するのではなく、プライベートノードのワーカーである可能性があります.

Update 3/21/19 Core developers had pushed out a fix as of 366f64f3df266cf02a06412d6760f73626d0a2bf commit on the mainnet branch that addresses this issue that I described below.

In the setting where you have a node in --private-mode (to bake) that connects itself to front (public) nodes, you must explicitly set your front nodes to trust your private node (using --peer argument of tezos-node or the config file of tezos-node or RPCs)! Else, there is a chance that at some point your front nodes decide to disconnect themselves from your private node in favour of a fresh new peer. The bug was that there were cases of disconnection of trusted-private-peers (not really visible because nodes used to favour old connections over new ones but still). we've now shielded those connections.

Essentially, there is a new feature that allows you to set your private node as a peer on your public nodes. That will favor your private node over new peers on your public node.

Original Answer

This problem has been around since the beginning. The problem stems from that the private node is treated the same as every other peer in your public node(even setting one as trusted). Basically it's not prioritizing your private node higher and sometimes your public node may decide that your private node is less "useful" than others. I mean if you think about it, private nodes are just leechers, not really contributing to your public node(s) so your public node might disconnect your private node for another node in the network. Also if your private node somehow "misbehaves" such as not functioning correctly or taking up too much resources, your public node might even graylist it and not allow connections from your private node. Though you would expect setting as trusted should alleviate that!

Most of us early bakers solve this problem by increasing the number of redundancies(public nodes) so when one disconnects it's not a big deal and it should reconnect sooner or later. I think in general, this is a good idea as you'll likely need to upgrade your nodes and having no redundancy will make the process much trickier. These days, I actually find that my private node almost never disconnects unlike the early days. My suspicion is that the private node might have gain "credibility", kind of opposite of being graylisted.

Until a new feature is added that can ensure an undisrupted prioritized connection, your best options are really limited to bringing up more public nodes or adding the foundation nodes(likely trustworthy) as your trusted nodes. One thing you could try is quicksync or copy the chain data to your private node so you don't have to bootstrap your private node. It's possible that during the syncing process, it's getting disconnected due to the resources it's requiring. The problem could be your private node's workers, not your public node disconnecting it.

これはあなたの質問に直接答えるものではありませんが、Kilnには、プライベートノードが接続を失ったときに通知できる機能があります.

プライベートノードを監視するようにKilnを構成する場合は、UIに「最小ピア数」を含めます.プライベートノードのピアがその数を下回ると、通知が届きます.

https://gitlab.com/obsidian.systems/tezos-bake-monitor

While this does not directly answer your question, Kiln has a feature that can notify you when your Private Node loses connections.

When you configure Kiln to monitor the Private Node, include a 'minimum number of peers' in the UI. If your Private Node's peers drop below that number, you'll receive a notification.

https://gitlab.com/obsidian.systems/tezos-bake-monitor