「Alonzo」対応に伴う変更作業について
奇抜倶楽部ステークプール管理⼈、YOWZAです。
9⽉13⽇に実施されたAlonzoネットワークへの切り替えに伴い、ステークプール運営者は
システムの変更作業を行う必要がありました。それを実施しないとブロック生成ができなくなり、委任者はステーキング報酬を得られなくなってしまい、大きな迷惑をかけてしまいます。もちろん私が運営している「奇抜倶楽部ステークプール」も変更作業は事前に済ませました。作業自体は難しくはないレベルなのですが、その作業を行ったときに思ったことについて記したいと思います。
みなさんはITILという⾔葉を聞いたことはあるでしょうか？ ITILとは、Information Technology Infrastructure Libraryの頭⽂字を取った単語で、ステークプールのようなIT
サービスを運営する上での教科書みたいなものです。言い換えると、今までに提供されてきたITサービスの成功事例集であり、このITILのプロセスに従うことで安定かつ持続的なサービスが提供できると言われています。
今回のAlonzoへ対応するための変更作業は既存のシステムも稼働させつつ作業を行う必要がありました。そういった場合はITILに沿って考えると、以下の3点に注意すべきです。
- ① トラブルが発⽣したら、その発⽣箇所をすぐに特定すること
- ② システムがダウンしたら、その時間は最⼩にすること
- ③ 今回は変更対象とはならないシステムを特定すること
Alonzo対応への変更作業の具体的な流れ
まず変更作業をいつまでに実施が必要かを確認します。
今回のハードフォークの⽇時は９月１３日の６時ごろでしたので、それまでに全ノード（奇抜倶楽部のステークプールでは、ブロックプロデューサーノードが１台、リレーノード２台）のアプリケーションのバージョンアップを実施します。
次に、ダウンタイムは何分くらい想定され、それを最⼩にするべく考察します。
今回もX-Stakepooloさんのマニュアルを参考にさせていただきました。Alonzoに対応したソースコードをコンピューターで動かすことができる実行ファイルに変換して、古いものを新しいものに置き換えて、ノードを再起動することで変更作業が完了するとのことで、ダウンタイムはこの再起動時間となります。リレーノード２台のうち、どちらかが稼働していれば、ステークプール⾃体はダウンしたことにはならないので、実際のダウンタイムはブロックプロデューサーノードの再起動の時間ということになり、その時間は５分程度と想定しました。５分程度のダウンタイムですが、プール運営に影響を及ぼしません。ステークプール上でのブロック生成は、５日間のエポック期間内に行われます。状況確認用のプログラムで、今ブロック生成しているかどうかは確認できますので、ブロックが生成中でないタイミングでノードを再起動することにより、ステークプール自体に影響を与えず変更作業が完了します。
最後に、今回は変更対象とはならないシステムを特定します。
ステークプールを監視している監視サーバーの設定変更は不要です。しかしスマートコントラクト対応により、各ノードが使⽤するメモリー容量が１．５倍程度に増加するとのことで、各ノードで実施していたトランザクションのメモリープール（トランザクションが確認される前の待機領域）の監視の無効化が推奨されていました。いままでは監視サーバー上でメモリープールの監視を⾏っていたのですが、今回ノード上での監視を無効化にするため、監視サーバーでは数値が表⽰されない状態になります。事前にこういった確認をしておくことで、バージョン・アップ後に、監視サーバーの表⽰に違いが⽣じても、焦って⾒直しをかけるといった⼼配がなくなります。
ということで「奇抜倶楽部ステークプール」では、９⽉３⽇に変更作業を実施しまして、無事バージョン・アップ対応を完了しております。プール運営のシステムに関して何か質問があればお寄せください。
今回はこのへんで失礼します。
奇抜倶楽部の委任もよろしくお願いします！
