Raspberry Pi で Astar Node 動かす③

ようやく、アーカイブノードの同期が最新状態に追いついたので、そこまでの様子をレポートします。また、環境の細かい内容についても共有します。

※本投稿はエンジニア向けの内容です。若干テッキ―ですが、Astar Node をラズパイで動かす上でのヒントはあるとおもいます。

なお、①、②がまだの方はそちらからご参照ください。

なんだかんだ、１カ月くらいで最新状態へ

同期開始時がだいたい、356万ブロックくらいで、同期が追いついたときのブロックが、381万ブロック。後述するトラブルで若干すったもんだで止まっていた時もいくらかありましたが、およそ１カ月くらいで最新状態に追いつきました。

今は他のノードと一緒に、おおよそ 12 秒毎に生成やファイナライズされたブロックが同期されています。

各ノード状態については以下の Telemetry が可視化されたサイトで確認できます。

Polkadot Telemetry

※ Telemetry には Prometheus が導入されており実装はスマート且つシンプルです。

環境

利用しているデバイスの情報については、「Raspberry Pi で Astar Node 動かす①」で解説済みですが、それがどこで稼働しているかについては言及していませんでした。

ネットワーク

インターネット回線は、マンション内共有の 1Gbps（実効は数百Mbps）を利用、そこから室内に WiFi を飛ばしています。Raspberry Pi 400 はそれを拾ってアクセスしています。つまり、IPマスカレード 状態で室内から外部のインターネットに出ています。特に変わった環境ではありません。

※ルーターの個別の設定（ポートフォワーディング等）は不要。

留意点やトラブルへの対処

同期中に様々確認した、現象の報告と対処等を以下に共有します。
というのも途中で何度も、ネットワーク断や、ハングアップをして連続した稼働ができなかったため、都度対処をしました。

※あくまで自分の環境およびデバイスにおいての観測と対処である点はご注意ください。

１，”brcmfmac: brcmf_sdio_hdparse: seq 218: max tx seq number error”

これ自体は、WiFi のドライバ（Broadcom）から発せられているものです。すぐに通信が止まるようなことはないのですが、一定の間隔で出た後にネットワーク断になりました。
発生条件の正確なものについては把握できていませんが、RasPi をリブート後はしばらくでなくなることができているため、ワークアラウンドとしてはそのように対処しています。

２，”IPv6: MLD: clamping QRV from 1 to 2!”

これは稼働において大きな影響のあるものではなさそうでしたが、”気持ちが悪い”のと、切り分けのために不要な処理は止めるように以下のように設定をしました。
※IPv6 および マルチキャストへの対応

% sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
% sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
% sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=1

% sudo sysctl -w net.ipv6.mld_qrv=1

これにより、このメッセージは解消しています。

３，astar-collator[19678]: 2023-05-31 09:23:17 [Parachain] :x: Error while dialing /dns/telemetry.polkadot.io/tcp/443/x-parity-wss/%2Fsubmit%2F: Custom { kind: Other, error: Timeout }"

たまに、astar-collator で確認されるエラーです。これは Telemetry との通信エラーであり、ノードの本質的な処理を妨げるものではありません。

よって、このエラーは同期の動作に対しては無視できます。

４，定常的に、swap file が利用されている

このモデルのラズパイではリソースが厳しいのでしょう。同期開始後 4GB メモリはあっという間に食いつぶし、定常的に大体数百～ 1.XGB 程度スワップファイルを使っています。まだ、ファイルスワップが SSD 上で作成されているから耐えられているものの、HDD ではかなり影響がでてることでしょう。

通常システムにおいては”スワップ使ったら負け”なので、普通はこの状態は許容しません。

そして、ハングアップギリギリの手前の時は、だいたいスワップファイルもサチっている（食いつぶされている）状態であったのを確認しています。

チューニング

特に、１，４の現象に関してはシステムの高負荷が原因となっている可能性があります。高負荷状態ではOSやソフトウェアが通常の動作が行えないことはよくあります。
いくらか負荷を軽減させるため、Peer の数を減らすことにしました。

astar-collator はデフォルトで INとOUT合わせて 40 Peer が起動するようになっています。これを IN=10,OUT=1 で設定し直し、ノードを再起動しました。

＜ /etc/systemd/system/astar.service ＞

[Unit]
Description=Astar Archive node

[Service]
User=astar
Group=astar

ExecStart=/usr/local/bin/astar-collator \
--pruning archive \
--rpc-cors all \
--name NODE_NAME \
--chain astar \
--base-path /var/lib/astar \
--rpc-external \
--ws-external \
--enable-evm-rpc \
--ws-max-connections 3000 \
--in-peers 10 \
--out-peers 1 \
--telemetry-url 'wss://telemetry.polkadot.io/submit/ 0' \

Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target\

※変更後 daemon-reload して、systemctl restart を実施

しかしながら、これによる変化はあまりなく、抜本的な解決にはなっていません。ネットワーク通信断やハングアップは、１～３日稼働において発生しています。ワークアラウンドとしては都度現象検出後、再起動することで回避しています。

トラブルへ理解

ノード起動開始後から、ノードが最新状態に追いつくまでは、基本的に負荷が高い状態が続きます（マラソンでいえば、先に走っている人に猛ダッシュして追いつこうとしているような状態）。
よって、ネットワーク断とハングアップを引き起こす要因は過負荷が影響している可能性は高いと考えており、これは現状の Raspberry Pi 400 においては致し方ないという事になるかも・・・。

今後

そんな中、エラーをチェックし、リソース状況などをモニタリングし、対処を様々考えながら、ついに最新のブロックの状態の同期まで追いつきました。これにより「追いつくスピード」というのは Raspberry Pi は出さなくてもよいため、負荷状況としては少し落ち着くのではと思います。

予想はしていましたが実際、同期中は CPU 温度が、56°～59° だったものが、最新状態に追いついた後は、50°～51° と明らかに熱が下がっています。

この後、連続してどこまで稼働できるかをモニタリングしていこうと思います。アップデートがあれば続報を書いていきます。

ともあれ、他の百数十ある Astar Node と一緒に自分の目の前にあるラズパイが同期をしている様をみるのは、なんとも静かな達成感と爽快感があります。

以上です。

参考

Prometheus + Grafana によるモニタリング。やはりメモリはオーバーロード気味。。。

https://docs.astar.network/docs/nodes/collator/secure_setup_guide/node_monitoring/