シードボックスホスティング
シードボックスと大容量ストレージ
大容量ストレージのワークロードには、ほとんどの仮想サーバーが誤って扱う3つの要件があります。NVMe並みにスケールしない価格での実容量、使用した瞬間に帯域制限されないネットワークポート、そして保持するデータをチェックサムできるファイルシステムです。VAULTはエンタープライズドライブの前にNVMeキャッシュ層を備えたZFS上に構築されているため、メタデータ操作は高速を維持しつつ、バルクデータは安価なスピンドル上に置かれます。
この構成の理由
ZFSの時間単位スナップショットは自身のスクリプトから保護し、大容量プランの無制限トラフィックは計算を不要にします。アムステルダムとブカレストは、当社の展開エリアで最も安価なトランジットを提供します。
当社がデプロイする構成
サイジング
2つの数字：ライブラリサイズと、そのうちどの程度をホットにシードするか。VAULTは32 TBに達するため、ライブラリから始めて25%を追加します。ZFSはプール使用率が約80%を超えると顕著に劣化します。RAMはARC用であり、メディアでは1 TBあたり1 GBが妥当な目安です。キャッシュしたいのはペイロードではなくメタデータだからです。16 GBで16 TBのライブラリをインデックスし、64 GBでホットセット用のARC領域を残します。2コアでクライアントを処理し、再暗号化やアーカイブ検証にのみ追加します。
シードライブラリのプールレイアウト
シードは多数のファイルにわたる小さな断片のランダム読み取りです。RAIDZ2は使用可能容量を最大化し、vdevごとに約1ディスク分のランダムIOPSを提供します。ミラーは容量を半分にし、IOPSを倍増させます。フロントのNVMeキャッシュを考慮すると、10 TBを超えるライブラリには2つのvdevでのRAIDZ2が通常適切な妥協点です。atime=off、compression=lz4、recordsize=1Mを設定し、sync=standardを維持します。SLOGはここでは役に立ちません。トレント書き込みは非同期だからです。プールの経年化に伴う断片化を監視します。80%以上で維持されたプールでの激しいチャーンは、容量が尽きるずっと前にシーケンシャル読み取りを劣化させます。
無制限トラフィックと、実際に制限が来る場所
無制限のギガビットポートは、飽和状態を維持すれば月に約300 TBを転送します。ほぼ誰もそうしないのは、制限が先に、そして別の場所で発生するからです。ピア数と接続追跡が最初にconntrackテーブル制限に達します。ディスクを非難する前にnf_conntrack_maxとハッシュサイズを上げてください。次に、トレントごとのピース検証が再チェック中にハッシュ計算でCPUを消費します。その後、プールはランダムIOPSを使い果たします。安価な容量は、レイアウトがそれを提供できなければ価値がありません。そのため、ライブラリ全体ではなくアクティブなシードセットを保持するようにNVMeキャッシュをサイズ設定してください。
問題点
- メディアプールでZFS重複排除を有効にする。重複排除テーブルはRAMに永続的に存在し、メディアファイルはほとんど重複せず、後で削除するとデータセット全体を書き直す必要があります。代わりに圧縮を使用し、重複排除はオフにしてください。
- recordsizeを128Kのままにする。大規模なシーケンシャルメディアファイルにはrecordsize=1Mが必要です。間接ブロックが減り、メタデータが減り、シーケンシャルスループットが向上します。データ書き込み前にデータセットに設定してください。新しいブロックにのみ適用されるためです。
- 無制限を無制限のIOPSと見なす。ポートは無制限ですが、プールは違います。一度に1000のトレントをシードするのはランダム読み取りワークロードであり、RAIDZはvdevごとに1ディスク分のIOPSを提供します。
マシンを調整
- ストレージと暗号化 — ZFS with hourly snapshots · €7
- アドレスとトランジット — アップリンクを10 Gbpsにアップグレード · €19
- コントロールパネル — No control panel · 含む