なぜ家庭用NASのHDDはアイドル時にスタンバイから頻繁に起動するのですか？

ホームNASのHDDは、ストレージスタックがプラッターが停止している間に完了できないコマンドを送信するとスタンバイから起動します。トリガーはファイル転送である必要はありません。ディレクトリの検索、データベースのコミット、ヘルスクエリ、またはスケジュールされた検証がドライブを動作状態に戻すのに十分な場合があります。

これが、誰も使っていないのにNASが忙しそうに聞こえる理由です。人間の非活動はシステムのフロントエンドを表しますが、HDDのスタンバイはリクエストが物理デバイスに到達するかどうかに依存します。これら2つの「アイドル」の定義が異なると、繰り返されるスピンアップは説明がつかないように見えますが、各起動イベントには特定のI/O原因があります。

ドライブはコマンドキューがメディアを必要とするときに起動する

スタンバイ状態では、機械式HDDは回転を停止していますが、ホストに応答することは可能です。hdparmで文書化されたATA電源制御は、スタンバイをアクティブまたはアイドル状態と区別し、ディスク活動の不在に基づくタイマーを説明しています。

一度メディア上のセクターが必要になると、ドライブはスピンドルを加速し、回転を安定させ、コマンドを完了する前に準備を整えなければなりません。聞こえる起動音と一時的な応答遅延はその機械的な遷移から生じます。ネットワークトラフィックは、最終的にスリーピングディスクに到達するストレージI/Oを生成する場合にのみ重要です。

人間のアイドル時間はブロックデバイスのアイドル時間を意味しない

ダッシュボードはアクティブユーザーがいないと報告していても、オペレーティングシステムはバッファリングされたデータのフラッシュ、タイムスタンプの更新、ログのローテーション、アプリケーション状態のコミットを続けています。これらの操作はスループットグラフからは消えるほど小さいかもしれませんが、HDDは起動前に最小ファイルサイズの閾値を適用しません。

メモリキャッシュは一部の読み取りを隠すことができますが、すべての操作を無期限に吸収することはできません。キャッシュミスは要求されたブロックを取得しなければならず、ダーティメモリは最終的に永続ストレージに書き込まれます。そのI/OがHDDに到達するかどうかは、ファイルの配置、キャッシュの状態、ファイルシステムの動作、およびプールに接続されたサービスに依存します。

スリーピングHDDに一般的に到達する3つのバックグラウンドパス

バックグラウンドの動作は、機械式ストレージ上の実際のパスに接続されて初めて有用な証拠となります。同じスピンアップ音でも、3種類の異なる作業から発生し、それぞれ異なるタイミングパターンを残します。

スケジュールされた起動は定期的なウェイク間隔を生み出す

タイマーは、ホームNASのインターフェースが静かに見えても、バックアップ検証、クリーンアップ、同期、データベースメンテナンス、または他のサービスを開始することがあります。systemdタイマーモデルは、カレンダーまたは単調なスケジュールから関連サービスを起動します。ほぼ同じ間隔でウェイクするドライブは、イベントをランダムとみなす前にシステムタイマーやアプリケーションスケジュールと比較する必要があります。

永続的なアプリケーション状態がイベントを書き込みに変える

ホームオートメーションの履歴、認証記録、DNS統計、コンテナログ、メトリクスデータベースは、通常は見えないイベントをディスク書き込みに変換することがあります。サービスはユーザーを待ちながら状態変化を記録している場合があります。ジャーナル、データベース、一時ディレクトリ、またはコンテナボリュームのいずれかがHDDプール上にある場合、小さなコミットがスタンバイを終了させることがあります。

検出とメンテナンスは保存データを再訪する

メディアの検出、サムネイルチェック、検索インデックス作成、スナップショットのクリーンアップ、ファイルシステムのスクラブ、バックアップ検証は、それぞれ異なる理由で既存のストレージを再訪します。名前やメタデータをスキャンするものもあれば、ファイルの内容やアレイブロックを読み取る必要があるものもあります。出力は小さいかもしれませんが、入力経路は1台以上のドライブが準備状態になることを要求する場合があります。

数キロバイトで完全な機械的スピンアップが発生することがある

ウェイクコストは要求されたデータ量ではなく、ドライブの状態によって決まります。キャッシュされていないメタデータブロック1つの読み取りや大きなビデオの先頭部分の読み取りは、どちらもスタンバイ中のHDDを最初にスピンさせる必要があります。小さなリクエストは遷移後すぐに完了することがあり、機械的には明らかでも帯域幅の統計ではほとんど見えないイベントを残します。

この不一致は、転送速度のグラフがウェイク検出に適していない理由を説明しています。これらは持続的な毎秒バイト数を強調しますが、スピンアップは短いリクエスト1回で引き起こされることがあります。スタンバイ動作を診断する際には、I/Oカウント、コマンドのタイミング、および最初にアクセスされたブロックの方がピークスループットよりも有益です。

ヘルスモニタリングはワークロードの一部になることがあります

監視サービスはスケジュールに従って温度、識別情報、エラーカウンター、自己診断情報を要求することがあります。結果はコマンドと完全な接続経路に依存します。直接接続されたSATAデバイス、HBA、RAIDコントローラー、USBブリッジは電源状態のチェックを同じ方法で保持しないかもしれません。

smartctlマニュアルはスタンバイ対応のノーチェックモードを定義しており、選択された低電力状態のデバイスに対してクエリを停止できます。このオプションが存在するのは、観察が自動的に受動的でないためです。ポーリングサービスは単にヘルスデータを収集するだけだから無害と仮定せず、起動源としてテストすべきです。

ストレージのトポロジーが起動するドライブの数を決定します

ファイル要求は個々のHDDに到達する前にファイルシステムとストレージプールに到達します。メタデータの位置、ストライピング、パリティ、ミラーリング、割り当てにより、1つの論理操作が複数のメンバーに関わることがあります。したがって、起動するドライブの数は実際のI/Oパスの特性であり、単にファイルサイズや共有名によるものではありません。

すべてのアレイ要求がすべてのディスクを起こすと仮定するのも不正確です。キャッシュされたメタデータが検索を満たすこともあり、ファイルを独立してアドレス指定可能なメンバーに保持するレイアウトはアクティブなセットを制限できます。正しい境界は、イベント中にどのデバイスがコマンドを受け取るかを観察することで決まります。

HDDスタンバイはSATAリンクの省電力ではありません

同じサーバー内で複数の電源管理機構が同時に動作しても、同じ物理状態を示すとは限りません。HDDスタンバイはドライブの機構に関するものであり、SATAリンクの電源管理はホストとデバイス間の接続に関するもので、システムスリープはより広範なコンポーネントの活動状態を変化させます。Linuxカーネルのlibataリンク電源管理のドキュメントでは、インターフェースの電源ポリシーをドライブのスタンバイとは別に扱っています。

スタンバイの行だけがプラッターの再起動というおなじみの音を直接説明します。SATAリンクの低電力状態はディスクが回転を続ける間にインターフェースの電力を節約しますが、リンク電力設定だけではHDDのハイバネーションが発生したかどうかは確認できません。

ウェイクの頻度はI/Oとスタンバイのタイミングに依存します。

繰り返されるスピンアップは、2つの独立した間隔が重なることによってよく起こります。ドライブが10分の静寂後にスタンバイに入るが、サービスが15分ごとにプールにアクセスする場合、各サービス実行が別々のウェイクを引き起こす可能性があります。同じサービスでも、ディスクがリクエスト到着時にまだ回転していれば機械的な遷移は少なくなります。

長いタイムアウトは基礎となるI/Oを排除するわけではなく、分離されたリクエストが1つのスピニング期間内に発生するか複数のスタンバイサイクルにまたがるかを変えます。したがって、有用な比較はデバイス要求間の実際のギャップと設定されたスタンバイ遅延、さらにドライブメーカーがサポートする電源管理およびスタートストップ仕様の組み合わせです。

ドライブに到達する最初のリクエストを追跡します。

原因となるイベントは遷移に関連する最初のコマンドであり、その後に最も高い総スループットを示すサービスではありません。ウェイク時間を記録し、それを予定された起動、クライアント接続、アプリケーションログ、デバイスレベルのI/Oと照合します。Linuxのblktraceインターフェースはブロック層のリクエストイベントを記録し、特定のデバイスでアクティビティが発生したかどうかを確認できます。

• HDDが単に静かになっただけでなく、スタンバイに入ったことを確認します。
• 最初のデバイス要求とそのタイムスタンプを記録します。
• タイムスタンプをタイマー、メンテナンスウィンドウ、クライアントの再接続と比較します。
• アクセスされたファイルまたはボリュームをそのサービスにマッピングします。
• 複数の設定を一度に変更する前に観察を繰り返してください。

繰り返されるスケジュールはタイマー駆動の作業を示唆し、クライアントの再接続に関連するイベントは共有の検出やアプリケーションアクセスを示します。ウェイクに対応するサービスログがなく、ブロックトレースに現れる場合、次のステップはリクエストを送信したプロセスまたは上位のストレージ層を特定することです。

アクティブ状態とコールドデータを分離してウェイクアップを減らす

アプリケーションのデータベース、ログ、インデックス、一時ファイルはSSDストレージに配置できるため、頻繁な小さな操作がHDDプールに到達しません。これはアクティブな書き込みパス全体が移動した場合にのみ機能します。ジャーナル、キャッシュディレクトリ、またはメタデータストアのいずれかを機械式ボリュームに残すと、元のウェイクパターンが維持される可能性があります。

読み取りキャッシュとライトバックキャッシュには異なる制限があります：キャッシュされていない読み取りは依然としてプールに到達し、汚れたキャッシュデータは最終的にフラッシュされなければなりません。目的は永久的なスリープを約束することではなく、ストレージ配置とスタンバイタイミングをワークロードに合わせることです。これらの状態選択は、個々のスピンアップの原因を特定せずに24時間365日NASの電力消費にも影響します。

よくある質問

どんなネットワークパケットでもスタンバイ中のNAS HDDをウェイクさせますか？

いいえ。パケットはメモリ、SSD上のサービス、またはネットワークスタックで処理され、HDDに触れずに済むことがあります。ドライブがウェイクするのは、リクエストの処理がスリープ中のデバイスやそれを含むストレージレイアウトにI/Oを必要とする場合のみです。

HDDをスリープ状態に保つためにSMART監視を無効にすべきですか？

自動的には防ぎません。ドライブの健康データは依然として重要であり、ウェイク動作は正確なクエリとコントローラパスに依存します。まずモニターがスタンバイ対応の電源チェックを使用しているか、ポーリング時間が観測されたウェイクイベントと一致しているかをテストしてください。

長いスタンバイタイマーは繰り返しのスピンアップを防ぎますか？

バックグラウンドリクエストが新しいタイムアウトより頻繁に到着する場合、個別のスピンサイクルを減らすことはできますが、それらのリクエストを完全に除去するわけではありません。まずI/O間隔を測定し、その後ワークロードとドライブの公称動作限界を反映したタイムアウトを選択してください。

SSDキャッシュはHDDプールのスリープ状態を保証しますか？

いいえ。キャッシュミス、ライトバックフラッシュ、アレイのメンテナンス、メタデータアクセス、およびキャッシュされていないスキャンは依然としてHDDに到達する可能性があります。アクティブなアプリケーション状態のための専用SSD層は通常、より明確な境界を作りますが、その結果はブロックデバイス層で確認する必要があります。