待機は家庭用VPNボックスがほぼ生涯を過ごす状態なので、測る価値があるのはまさにこの状態です。同じマシンは、トンネルが上がっている間も接続に応答し、ファイルを配信し、バックアップを終える必要があり、この三つの仕事は異なる方向に引っ張ります。静けさ、低消費電力、常時到達可能は別々の性質であり、仕様書はそのどれも説明しません。以下の確認を順番に進めれば、ハードウェアの判断が半年後の作り直しになるのを防げます。

部品ではなく役割から始める

誰も見ていない間にボックスが行うべき仕事をすべて書き出します。WireGuardやOpenVPNのゲートウェイ、ファイル共有、バックアップ先、インデックス作業では定常コストが異なり、四つすべてを担うマシンは最初の一つだけを担うマシンよりはるかに高い下限を持ちます。待機消費電力はその下限の平均ではなく合計です。だからこそ、どちらも低消費電力と称される二台のボックスが同じ部屋で三倍違うことがあります。

データがトンネルと同じホストに住むかどうかを早く決めることが、他のすべてを制約します。ホストを分ければ待機消費は二つになりますが、ストレージが眠っている間もゲートウェイは起きたままで、一つのホストなら消費も障害ドメインも一つです。どちらも間違いではありませんが、部品リストができる前に答えを書き留める必要があります。

三つの状態でボックス全体を測る

コンセントと電源の間の壁用メーターが、変換損失もディスクの回転も忘れていたUSB機器も含むため、ここで唯一正直な計測器です。三つの数値を記録します:トンネルを上げて他に何も動かさない待機、実際のリモート転送中の同じボックス、定時バックアップ中のボックスです。

ソフトウェアのカウンターは壁用メーターの読みを説明する助けになりますが、代わりにはなりません。RAPLインターフェースはパッケージとメモリドメインのエネルギーを報告しますが、電源の損失とUSB経由で接続されたものは除外されます。

read -r a < /sys/class/powercap/intel-rapl:0/energy_uj; sleep 60; read -r b < /sys/class/powercap/intel-rapl:0/energy_uj
awk -v a="$a" -v b="$b" 'BEGIN{printf "package average: %.1f W\n", (b-a)/60/1000000}'

騒音も同じ扱いが必要です。ファンレスのケースは一つの発生源を除きますが、ハードディスク、電源、コイル鳴きは残るので、ログインプロンプトではなくバックアップ中に耳を澄ませてください。温度も同じ回に含まれます:持続負荷の下でセンサーを読み、静かにするために熱保護を決して無効にしないでください。

ワットを比較できる年に変える

連続消費電力は一回の掛け算でエネルギーに変わり、一度計算しておけば年間コストが驚きになりません。一年を通した11 Wの平均の例は次のように計算されます。

awk 'BEGIN{printf "%.1f kWh/year at 11 W\n", 11*24*365/1000}'

この数値は算術であり、あなたのボックスの測定値ではなく、掛ける料金のほうが数ワットより大きく答えを動かします。この計算が役立つのは二つの設計の比較で、待機6 Wのゲートウェイと15 Wのゲートウェイの比較は値段をつけられる判断です。プロセッサーの定格ワット数は、負荷時のパッケージを表すものであって休止中のシステムを表すのではないため、その数値ではありません。壁用メーターの平均を現地の料金とともに使い、結果を推定値として示してください。

スリープを許すか決める

スリープは最も多くのエネルギーを節約し、最も多くの前提を壊します。眠っているホストは自分を起こすはずの受信接続を受け付けられず、クライアントのkeepaliveもそれを変えないため、同じLAN上で常時稼働する機器だけがwake-on-LANパケットを送れます。

トンネルがどの時間帯でも到達可能でなければならないなら、スリープはポリシーで無効と扱い、それを構築メモに書いてください。対象をマスクするのは乱暴ですが明示的で、習慣よりもパッケージ更新に耐えます。

systemctl status sleep.target suspend.target
sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
systemd-inhibit --list

Wake-on-LANは静かに失敗するので、そのメモに専用の行が必要です。この機能はファームウェアで有効にする必要があり、一部のインターフェースでしか動かず、パケットを送るには既に起きている機器が必要です。依存する前に、旅行の後ではなくテストしてください。

実際に受ける負荷の下で証明する

最後の確認は人が飛ばすもので、想定した負荷を実行し、一時間ボックスを観察します。リモート転送、バックアップ、インデックス再構築を同時に行えば、冷却、リンク、ストレージが選んだ役割の組み合わせを支えられるか分かります。

uptime
sensors | grep -E 'Core|Package|fan'
ss -s

上り帯域は通常プロセッサーよりずっと早くリモートのスループットを制限するため、同じ時間帯にアクセス回線も見てください。トンネルがCPUで暗号化できる量のほんの一部で飽和するなら、より速いチップは何も買いません。

関連記事