OpenVPNの通信カウンタとディスクI/O：3つの異なる数値

大きなファイルをトンネルに通すと、インターフェースのカウンタはファイルのサイズだけ増えますが、その数値は同じ量がディスクに届いたことを何も意味しません。この種の議論では三つの異なる測定が比較され、それらは三つの異なる問いに答えます。どれだけの通信がネットワーク層を通過したのか、プロセスがシステムコールを通じて何バイト読み書きしたのか、そしてどれだけの仕事がストレージ層に届いたのか、です。

一つ目と三つ目を比べるのがよくある間違いで、それは実在しないディスク問題か、実際に起きている書き込みを無視した容量計画を生みます。三つは切り分けられ、それぞれに正しい使い方があります。

混同される三つの数値

インターフェースのカウンタは、ネットワーク層で扱われる通信を表します。帯域幅、トンネルの大きさ、通過に料金を付ける課金モデルには、これが正しい数値です。

プロセスの文字カウンタは、パイプ、端末、キャラクタデバイスを含む任意のディスクリプタに対する読み書きの呼び出しで動いたバイト数を表します。システムコールの境界でプロセスがどれだけ忙しいかを問うにはこれが正しい数値であり、ストレージの請求書ではありません。

ストレージのカウンタは、カーネルがブロックデバイスとの間で動かそうとしたバイト数を表し、容量計画にはこれが正しい数値ですが、カーネル自身が会計の限界を文書化している点に注意が必要です。キャッシュされた読み取りはストレージの読み取りにはならず、後で取り消された書き込みは完了したデバイス書き込みにはなりません。

ファイルディスクリプタがディスク書き込みではない理由

ユーザー空間のVPNは、TUN デバイスを通じてカーネルとパケットをやり取りします。これは通常のファイルではなくキャラクタデバイスで、そこから読むとパケットが渡され、そこへ書くとパケットが注入されます。ストレージ用に用意されるファイル内容のページはなく、ファイルシステムのパスも関与しません。

だからこそ、忙しいトンネルはストレージのカウンタがほとんどないまま巨大な文字カウンタを示すことがあります。プロセスは確かにそのバイトを動かしており、カーネルは確かにそのためにディスクを必要としていませんでした。

cat /proc/$(pgrep -n openvpn)/io
ip -s link show tun0

最初の出力は、プロセス開始からの累積として読み、レートとして読まないでください。二つ目は同じ通信のインターフェース側の見え方を与えます。両者の大きな差は想定内であり、リークやキューの滞留、設定ミスを示すものではありません。

バイトは実際どこから来るのか

持続的な出力には独自の予算がある、というのがその答えです。ペイロードではなく操作によって駆動され、冗長なログレベル、頻繁に変わるクライアント一覧、タイトなループで繰り返されるエラーは、トンネルがほとんど運んでいなくてもかなりの書き込みを生みます。

ステータスファイルは一定間隔で書き直されるスナップショットなので、そのコストは間隔と含まれるレコード数に依存します。すべてのクライアントの通信の実行コピーではなく、間隔を短くすると通信量を変えずに書き込み量が変わります。

それらの書き込みを探すときには所有権が重要です。サービスがメッセージをログデーモンに渡しているなら、ジャーナルやログファイルを書くのはそのデーモンであり、バイトは VPN プロセス自身のカウンタではなくデーモンの会計に現れます。VPN プロセスだけを見ても、ディスク活動もその不在も説明できません。

他の寄与者は見落としがちです。起動時の証明書と設定の読み取り、独自のレコードを書くフック、会計プラグイン、クラッシュダンプ、同じホスト上の無関係なワークロードなどがあり、どれもトンネルの通信量と書き込みバイト数を等しく置いて見積もるべきではありません。

各カウンタを正しく読む

比較に意味があるかを決める細部は三つあります。プロセスの同一性は重要で、再起動したサービスはカウンタをリセットします。時間間隔も重要で、累積値と毎秒のグラフは別の測定です。単位も重要で、ログファイルの現在のサイズもまたレートではありません。

grep -E 'rchar|wchar|read_bytes|write_bytes' /proc/$(pgrep -n openvpn)/io
du -sh /var/log/openvpn 2>/dev/null
journalctl --disk-usage

本当のペイロード書き込みを疑うなら、ペイロードを保存することを仕事とする部品、つまりパケットキャプチャのツール、本文をキャッシュするプロキシ、アーカイブするプラグインを探してください。これらは記録を求められた量に応じて増えるストレージ通信を生み、保持とアクセスについての別個のポリシー判断に属します。

正しい数値で容量を計画する

パケット経路はネットワークの数値、つまりスループット、暗号処理、メモリの移動で見積もってください。ストレージは実際に選んだ可観測性の判断、つまりログレベル、保持、ステータス間隔、意図的に有効にしたキャプチャで見積もってください。

この二つの予算を分けておくと、インシデントも読みやすくなります。トンネルの通信が控えめなのにディスクが満杯なら、ログやキャプチャ、あるいは無関係な何かを指し、インターフェースのカウンタは決してそれを説明しません。ログが静かなのに回線が飽和していれば、逆方向を指します。

行う価値のある比較は、同じ種類の測定どうしの比較です。時間をかけたインターフェースのバイト対インターフェースのバイトは経路について教えてくれます。ストレージの書き込み対ストレージ容量は保持について教えてくれます。横断的な比較、通信対ディスクは、意味があるように見えるだけで、決してそうではありません。