物理サーバーを別の利用者へ渡すとき、前のOSが起動しなくなったことと、前の利用者のデータが消えたことは同じではありません。パーティションなどを識別する情報だけを消しても、データそのものが残る場合があります。
ベアメタルの配備を管理するOpenStack Ironicには、次の利用に備えてノードを整える「クリーニング」があります。ディスク消去もその一部ですが、選ぶ処理によって消す範囲、使う装置機能、失敗したときの進み方が変わります。ここでは2025.1系列の公式文書とIronic Python Agentの実装をもとに、その違いを見ていきます。実際の導入版や独自ドライバーで、同じ動作になるとは限りません。［1］［3］
簡単にまとめると？
- メタデータ消去は再配備の準備を短時間で進められますが、ユーザーデータ全体の消去とは区別が必要です。
erase_devicesは装置の消去機能や上書きを使います。erase_devices_expressでは、同じサーバー内でもドライブによって消去方法が異なり得ます。- 再利用前には、終了状態に加えて対象ドライブ、実行された処理、失敗後の代替処理を確認します。手動クリーニングの完了だけでは、配備可能な状態へ進みません。
クリーニングは、次のOSを書き込む前の準備
Ironicの自動クリーニングは、有効にしている場合、初めてノードを配備可能にするときや、使い終わったハードウェアを次のワークロードへ回すときに行われます。ディスク消去だけでなく、ハードウェアやドライバーに応じた複数のステップを順に実行する仕組みです。OSイメージを書き込む配備処理そのものとは分かれています。［1］［2］
この違いは、標準の消去順序を見ると分かりやすくなります。文書では、クリーニングの早い段階でerase_devices_metadataを実行し、以前のワークロードへ戻って起動しないようにします。その後にerase_devicesでデータを消去する構成が説明されています。先に起動の手掛かりを取り除く処理と、残るデータを消す処理には、それぞれ役割があります。erase_devices_expressは既定では無効です。［1］
三つの処理は、消す範囲と代替方法が違う
| 処理 | 主な動作 | 再利用時に見落とせない点 |
|---|---|---|
erase_devices_metadata |
ストレージのメタデータを消去する。 | データの全ビットを消す処理ではなく、復元できる可能性が残る。 |
erase_devices |
対応するハードウェア消去を優先し、条件に応じてshredによる上書きを行う。 |
機能の非対応と実行エラーを区別する。エラー後の上書き継続には設定条件がある。 |
erase_devices_express |
対応するNVMeではハードウェア消去を試み、それ以外ではメタデータ消去へ進む。 | 終了が速くても、全ドライブが同じ消去水準になったとは限らない。 |
メタデータ消去が短く済みやすいのは、全データ領域を書き直す処理ではないためです。Ironicの文書は、その目安を秒から分、erase_devicesは装置の高速な消去機能を使えなければ時間から日単位になり得る、と説明しています。これは文書上の幅であり、特定のドライブで計測した結果ではありません。容量だけでなく、実際に選ばれた消去方式が待ち時間を左右します。［1］
たとえば、以前のOSを使わずに次のOSを配備する準備と、別の利用者が以前のデータへアクセスできないようにする要求では、確かめたいことが異なります。前者の準備が終わったことを、後者の要求を満たした証拠に読み替えないことが、方式を選ぶ出発点になります。
暗号消去は、全領域への上書きと同じ動作ではない
erase_devicesという名前から、必ず全領域を何度も上書きすると考えると、実際の処理を見誤ります。NVMeの例では、Agentが装置の機能情報を読み、Format NVMに対応しているか、暗号消去に対応しているかを確認します。2025.1の標準実装は、暗号消去に対応していればses=2、対応していなければユーザーデータ消去のses=1を選びます。［3］［4］
sesはSecure Erase Settings、つまり要求する消去の種類です。nvme-cliの公式説明では、暗号消去は暗号鍵を削除することでユーザーデータを暗号的に消去する方式です。ユーザーデータ消去は、消去後の値が必ずゼロになるという指定ではありません。また、すべてのユーザーデータが暗号化されていれば、装置はユーザーデータ消去の要求に対して暗号消去を行うこともできます。［5］
そのため、「終了が速かったからメタデータだけを消した」「全体をゼロで埋めなければ消去ではない」と、時間や見た目だけで判断することもできません。一方、Ironicが対応機能を選択した事実だけで、あらゆる装置の実装や消去結果を実証したことにはなりません。必要なのは、対象の装置と機能、選ばれた処理、その成功・失敗を結びつけることです。
「使えない」と「実行して失敗した」を分ける
通常のerase_devicesでは、ハードウェア消去が失敗したあとに上書きへ切り替えるかを、deploy.continue_if_disk_secure_erase_failsで制御します。2025.1の設定文書では既定値はFalseで、NVMeまたはATAのsecure eraseが失敗すればクリーニングも失敗します。Trueならshredを呼び出して継続を試みます。これは、消去に失敗してもそのまま次へ進めてよい、という設定ではありません。［4］
さらに、Agentの標準実装では、ATA消去機能が非対応として返る経路と、対応機能の実行中にエラーになる経路が分かれています。非対応で別の方式を試せる場合には上書きへ進みますが、実行エラーを捕捉した場合には上記の継続設定を確認します。上書き自体も成功しなければ失敗です。「ハードウェア消去をしなかった」という結果だけでは、どちらの経路だったかは分かりません。［3］
erase_devices_expressの代替処理は、これとは異なります。この版の標準実装では、NVMeのハードウェア消去で特定の消去エラーが発生した場合も捕捉し、メタデータ消去を試みます。メタデータ消去にも失敗すれば、エラーを集めて処理を失敗させます。通常の消去が失敗後に上書きを試す条件と、expressがメタデータ消去へ切り替わる条件を、一つの設定として扱うことはできません。［3］
NVMeとHDDが混在すると、同じ終了にも違いが残る
例として、対応NVMeと一般的なHDDを搭載したサーバーで、express方式を使う場合を考えます。NVMeではハードウェア消去が成功し、HDDではメタデータだけを消去して、ステップ全体が成功する構成はあり得ます。公式文書もこの混在構成をexpressの用途として挙げています。ここで共通なのは短時間のクリーニングを目指す方針であり、全ドライブでユーザーデータを同じ方法で消したことではありません。［1］
もし運用上の要求が「どのドライブも、前の利用者のデータを復元できない状態にして渡す」であれば、HDDに対するメタデータ消去だけでは、その要求を満たしたとは判断できません。逆に、必要な消去水準を別の工程で満たす環境などでは、再配備の準備を短くする価値を検討できます。ただし、それは要求と実施工程を対応させた判断であり、expressという名前だけで決まるものではありません。
完了状態と実行内容を一緒に確かめる
Ironicの状態にも区別があります。cleaningはステップの実行やその準備中です。clean waitでは、処理用のramdiskの起動や、ノード内で実行するステップの終了を待っています。どちらも、次の利用に配備できるavailableとは異なります。［2］
自動クリーニングを経て配備可能にする場合は、正常完了後にavailableへ進みます。一方、運用者が指定した手動クリーニングは、manageableから開始し、終了後もmanageableへ戻ります。手動処理が完了しただけで、すぐに次のワークロードを配置できる状態になったわけではありません。［1］［2］
失敗してclean failedになった場合、clean stepの実行中の失敗ではmaintenance modeにも入り、Ironicによる操作を抑えます。文書は、保守モードを解除する前に、装置の損傷や動作中の処理がないことを確認するよう説明しています。ノードをmanageableへ戻して原因を調べ、修復後に再び配備可能にする流れでは、自動クリーニングを最初から実行して、正常完了後にavailableへ進みます。［1］
実行中または失敗したステップは、ノードのdriver_internal_infoにあるclean_stepsと、conductorやAgentのログが手掛かりになります。運用で残す記録としては、ノードの最終状態だけでなく、対象ドライブ、選ばれた方式、代替処理の有無と結果を組にするのが有用です。これは消去方式を比較するための確認観点であり、特定機器の消去試験を行った結果ではありません。［1］［3］
クリーニングの待ち時間を短くする判断では、何を省いたのか、装置の機能で何を置き換えたのかを区別すると、速度とデータの扱いを同じ基準で比較できます。再利用の準備ができた状態と、必要な範囲のデータ消去ができた根拠を、両方そろえて次の利用へ渡すことが大切です。
参考資料
- OpenStack Ironic — Node cleaning（2025.1系列）。Storage cleaning options、Manual cleaning、FAQ、Troubleshooting。
- OpenStack Ironic — Bare Metal State Machine（2025.1系列）。Enrollment and Preparation、Deploy and Undeploy。
- Ironic Python Agent — ironic_python_agent.hardware（2025.1系列の実装表示）。GenericHardwareManagerのerase_block_device、erase_devices_express、_ata_erase、_nvme_erase、_shred_block_device。
- OpenStack Ironic — Configuration Options（2025.1系列）。deployの消去設定。
- linux-nvme / nvme-cli — nvme-format(1)。Secure Erase Settingsの意味を補足。Ironicの動作条件は上記2025.1資料に限定。資料確認日：2026年10月12日。