IPFSのノードをストレージがHDDのVPSで稼働させようとしていたことに気づいたので、急遽スケールアップした話。

はじめに

IPFSのノードを立ち上げたのは良いのですが…

IPFSのノードはかなりメモリを消費する(500MBくらい)ので…

等の策を講じ、さらにcronで週に3回くらいIPFSを再起動させることによりなんとかあまり止まることなく稼働するようにはなりました。

…などど報告しようと思った矢先にまたサーバ全体を巻き込んで止まってしまうという事態が頻発するようになってしまいました。

cronでの再起動を週に3回から1日1回に変更してもサーバ全体を巻き込んで止まってしまうという事態が起こらなくなる… ということはありませんでした。

そこで、IPFSのノードを安定稼働させようと試みているVPS(さくらのVPSです。)のスケールアップを行うことにしましたので、その顛末について書いていきます。

IPFSのノードを安定稼働させようと試みているVPSは石狩リージョンの1Gプランなので、石狩リージョンの2Gのプランにスケールアップすることになります。

1Gプランと2Gプランの金額差は年額にして約8000円です(この記事を最初に書いた時点(2022年6月)の情報です)。

お財布に金額差が激しく突き刺さります。

とはいうものの、メモリ容量及びストレージ容量は2倍になる(CPUのコア数は1.5倍になりますが、ここでは考えないことにします。)にもかかわらず、価格差が2倍を下回っている…と考えればコスパは悪くないようにも見えます。

そこで、スケールアップボタンをポチることにしました。

実際にポチる前にスケールアップ前の状況を確認します。

すると…

(　ﾟдﾟ)

(つд⊂)ｺﾞｼｺﾞｼ

(；ﾟдﾟ)

(つд⊂)ｺﾞｼｺﾞｼ
　　, .
（；ﾟ Дﾟ） …？!

IPFSノードがHDDで動作していることが発覚しました(上図の赤矢印)。

これはいろいろとあやしそうです(単に忘れていただけですが)。

他におかしいところがないかと思い、VPSのリソース情報(今回初めて確認しました。)を確認しました。

すると…

CPUタイムが1秒(=1000msec)で頭打ちになっていることを除けば、ディスクIOも含め特に問題はないように見えます。

調査可能な部分については調べがついたと判断したところで、IPFSのノードが稼働しているサーバを停止し…

今度こそ「スケールアップ」ボタンをポチります。

ストレージはストレージ変更オプションを適用することにより2倍に増量(100GB→200GB)です。

スケールアップ作業自体は「さくらのVPS」でガイドされている方法[1]に従うことで、約15分程度で完了しました。

ストレージが増量されているため、パーティションテーブルを変更しました。

パーティションテーブルの変更はこの記事の「rootパーティションのサイズの拡大」に記載の方法で行いました…

が、しかし…

ストレージのもともとのパーティションテーブルがMBR対応のものであったため、上記の方法でrootパーティションのサイズを変更してその結果を保存するとパーティションテーブルがGPT対応のものに変わってしまうため、そのままではこのストレージからの起動ができなくなります。

かなりつらいです。

そこで、以下の手順でパーティションテーブルをMBR対応のものに戻します。

FedoraのLive ISOをダウンロードします。
手順1でダウンロードしたLive ISOをさくらのVPSのコントロールパネルからアップロードします。
このページ及びこのページの手順に従って、レスキューブートを行います。
ブート後はインストールは行わず、Live ISOで起動します。
Terminalを起動します。
コマンドプロンプトから以下のコマンドを実行し、パーティションテーブルをMBR対応のものに戻します。
以下のコマンドを実行します(“fedora-root”の部分は設定の状況により読み替えます)。
以下のコマンドを実行し、GRUB2を再インストールします(パーティション名はストレージの状況により適宜読み替えます)。
$ /usr/bin/grub2-install /dev/vda
再起動します。