Quantum Sea

タグ: OpenStack

  • OpenStack Ironicのディスク消去、速さと消える範囲をどう見分けるか

    OpenStack Ironicのディスク消去、速さと消える範囲をどう見分けるか

    物理サーバーを別の利用者へ渡すとき、前の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］

    三つの処理は、消す範囲と代替方法が違う

    2025.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］

    クリーニングの待ち時間を短くする判断では、何を省いたのか、装置の機能で何を置き換えたのかを区別すると、速度とデータの扱いを同じ基準で比較できます。再利用の準備ができた状態と、必要な範囲のデータ消去ができた根拠を、両方そろえて次の利用へ渡すことが大切です。

    参考資料

    1. OpenStack Ironic — Node cleaning（2025.1系列）。Storage cleaning options、Manual cleaning、FAQ、Troubleshooting。
    2. OpenStack Ironic — Bare Metal State Machine（2025.1系列）。Enrollment and Preparation、Deploy and Undeploy。
    3. Ironic Python Agent — ironic_python_agent.hardware（2025.1系列の実装表示）。GenericHardwareManagerのerase_block_device、erase_devices_express、_ata_erase、_nvme_erase、_shred_block_device。
    4. OpenStack Ironic — Configuration Options（2025.1系列）。deployの消去設定。
    5. linux-nvme / nvme-cli — nvme-format(1)。Secure Erase Settingsの意味を補足。Ironicの動作条件は上記2025.1資料に限定。資料確認日：2026年10月12日。
  • OpenStack・Kubernetes・Cephの役割分担、計算資源・コンテナ・保存先をつなぐ

    OpenStack・Kubernetes・Cephの役割分担、計算資源・コンテナ・保存先をつなぐ

    たとえば、すでにOpenStackでサーバーやストレージを運用しているところへ、AI推論用のコンテナを増やしたいとします。そのとき、基盤を丸ごとKubernetesに置き換える必要はあるのでしょうか。答えを考える鍵は、二つに同じ仕事をさせないことです。

    2026年8月のOCP Korea Tech Dayで、AWS Koreaの講演はOpenStack、Ceph、Kubernetesが共存する三つの接点を示しました。発表の中心は、GPUを載せる計算資源、データを置くストレージ、コンテナの運用をどう組み合わせるか。個々の構成要素は公開されていますが、スライドは三つを組み合わせた特定環境の性能試験ではありません。［1・2］

    簡単にまとめると？

    • OpenStackは計算・通信・保存の資源を用意し、Kubernetesはコンテナの配置や更新を担います。
    • 両方でCephを使っても、同じデータへ自動でアクセスできるわけではありません。
    • EKS Hybrid Nodesは管理プレーンがAWS側にあり、オンプレミスとの安定した接続が必要です。

    OpenStackは資源を用意し、Kubernetesは仕事を配置する

    OpenStackは仮想マシン、ネットワーク、ストレージを払い出す基盤です。必要ならIronicでベアメタルのマシンも扱えます。その上にKubernetesのクラスタを置けば、Kubernetesはコンテナ化したサービスをどのノードで動かし、どう更新するかを管理します。発表は、この上下関係を「OpenStack上のKubernetes」として示しています。［2］

    クラスタを作る接点の一つがCluster API Provider OpenStackです。Cluster APIはKubernetesのクラスタ作成と更新を宣言的に扱う仕組みで、このプロバイダーがOpenStackの資源を使ったクラスタ管理を担います。発表にはMagnumも別の選択肢として並びます。どちらを選ぶかで作成・更新の手順は変わりますが、KubernetesがOpenStackの役割をそのまま引き受けるわけではありません。［2・3］

    保存先はCSI、外への入口は別の接続でつなぐ

    コンテナの中身を作り直しても、学習データや設定を残したい。その保存先をKubernetesから使えるようにするのがCSI（Container Storage Interface）という接続方式です。OpenStackのCinder CSIはブロックストレージを永続ボリュームとして渡し、Manila CSIは共有ファイルシステムを扱います。一方、外部にサービスを公開する負荷分散には、OpenStackのクラウドコントローラーとOctaviaを使う経路があります。保存先と通信の入口は、別々の接続点です。［2・4］

    Cephを保存基盤に選ぶ構成なら、ここにも分かれ道があります。RookはKubernetes上でCephクラスタの配置や運用を助けるオペレーターです。ceph-csiは、CephのRBD（ブロック）やCephFS（共有ファイルシステム）をKubernetesのボリュームとして渡します。CephをOpenStack側でも利用できますが、「両方でCephを使う」だけで同じデータへ自動的にアクセスできるわけではありません。接続先、権限、ネットワーク、データの扱いは構成ごとに決めます。［2・5・6］

    EKS Hybrid Nodesは、管理する場所が異なる

    発表は、既存のオンプレミス資源を使う別の選択肢としてAmazon EKS Hybrid Nodesも挙げています。OpenStack上の仮想マシンやベアメタルをノードに使えますが、Kubernetesの管理プレーンはAWSリージョンにあります。オンプレミスだけで完結するクラスタではなく、AWS側の管理プレーンとノードを結ぶ安定したネットワークが必要です。OpenStack上に自分たちでKubernetesクラスタを管理する構成とは、運用責任と接続の前提が違います。［2・7］

    三つの技術を重ねるとき、まず決めたいのは「何をどこが管理するか」です。サーバーとネットワークを用意する層、コンテナを動かす層、データを残す層。その接点に必要なドライバーと運用主体が見えていれば、既存の基盤を生かしたままAI用の仕事を増やす道筋を描けます。

    AWSを支えるAmazonの事業を知る

    AWSは、Amazon.comの企業向けクラウド事業です。Amazon全体には通販、出店者向けサービス、広告などもあり、それぞれ収益の仕組みが異なります。cyclewaveでは、AWSの位置づけを全社の売上と利益からたどっています。

    Amazon.comの企業解説へ

    参考資料

    2026年9月26日確認。講演スライドと各プロジェクトの公式資料を照合しました。個別構成の性能・費用を測定した記事ではありません。講演動画の質疑は確認対象に含めていません。

    ［1］Open Compute Project「2026 OCP Korea Tech Day」発表一覧。演題、登壇者、資料掲載。

    ［2］AWS Korea「The New Normal of Infrastructure in the AI Era: Accelerating Innovation with Kubernetes」公式掲載スライド。全31頁。基盤の役割はpp.8–11、EKSの配置はp.22。市場予測や導入率、個別企業の節約率は本文に転用していません。

    ［3］Kubernetes Cluster API Provider OpenStack 公式文書。OpenStack上のKubernetesクラスタ作成・管理。

    ［4］Kubernetes Cloud Provider OpenStack。Cinder CSI、Manila CSI、OpenStack Cloud Controller Managerなどの役割。

    ［5］Rook Ceph 公式文書。RookオペレーターによるCephの配置・運用。

    ［6］Ceph「Container Storage Interface」。RBDとCephFSをKubernetesボリュームへ接続するCeph-CSIの役割。

    ［7］AWS「Deploy Amazon EKS clusters across cloud and on-premises environments」。EKS Hybrid Nodesの管理プレーン、ノード配置、接続要件。

  • Open Source ConsultingのOpenStack SLURP更新、中間版を飛ばす6ノード検証

    Open Source ConsultingのOpenStack SLURP更新、中間版を飛ばす6ノード検証

    クラウド基盤の更新は、ボタンを押して終わりにはできません。仮想マシンが動き続けていても、管理画面や新しい仮想マシンの作成まで同じように使えるとは限らないからです。「更新できた」と「利用者に影響がなかった」の間には、いくつもの確認があります。

    2026年8月のOCP Korea Tech Dayで、Open Source ConsultingのShin Hocheol氏は、OpenStackを2025.1 Epoxyから2026.1 Gazpachoへ更新した6ノード環境の検証を紹介しました。発表の価値は「無停止」の一語より、更新前後の状態をどこで確かめたかにあります。［1・2］

    簡単にまとめると？

    • SLURPは隣り合う対象版の間で中間版を飛ばす更新経路で、任意の版を飛ばせる制度ではありません。
    • 発表の6ノード検証では、更新中に監視した仮想マシンのPingとHTTPの切断は0回でした。
    • 通信が続いたことは、管理画面や全API、すべての利用者操作が無影響だった証明ではありません。

    半年ごとの公開、1年ごとの飛び越し

    OpenStackの主要版はおおむね半年ごとに出ます。そのうち一つおきに「SLURP（Skip Level Upgrade Release Process）」と呼ぶ版があり、隣り合うSLURP版の間は中間の版を飛ばす更新経路が支えられています。EpoxyとGazpachoはその組み合わせです。どの版からでも何版でも飛ばせる制度ではありません。古い版から一気に移す場合や、配布ツールごとの制約は別に確かめます。［2：pp.12、17、20］［3］

    発表で使ったKolla-Ansibleは、OpenStackの各サービスをコンテナにまとめ、Ansibleで配置や更新を進める公式プロジェクトです。命令が短いことと、作業全体が単純なことは違います。設定、秘密情報、コンテナ画像、データベース、メッセージキュー基盤のRabbitMQなど、更新の前提は複数の場所に分かれています。［2：pp.18、21］［4］

    まず、戻れる材料をそろえる

    発表資料とKolla-Ansibleの2026.1版の手順を重ねると、準備は四つに分けられます。対象版のリリースノートを読み、設定とデータベースをバックアップする。インベントリと設定・パスワードの差分を合わせる。対象版のコンテナ画像を用意し、prechecks（事前検査）を通す。最後に、更新中と更新後に何を監視するかを決める、という順です。［2：pp.21–26］［4］

    特にRabbitMQの更新経路は、版を見ずに決められません。発表では、EpoxyのRabbitMQ 4.0からGazpacho側へ進む前に4.1を経由する案を示します。一方、2026.1版の公式文書は、条件に合う4.0から4.2への経路も許可例に載せています。「必ず中間版が要る」と固定せず、現在の実装、許可された経路、利用中のキューの状態を照合するのが正確です。［2：p.24］［5］

    「切れなかった」の測り方

    発表者の検証環境は、制御を担うコントローラーノード3台と仮想マシンを動かすコンピュートノード3台の計6台です。2025.1から2026.1への更新中、仮想マシンへのPingとHTTPを連続監視し、この測定では切断を0回と報告しました。更新処理の失敗も0件でした。これは、発表者が示した構成と測定方法に限る良い検証結果です。［2：pp.27–32］

    同じ資料には、管理画面Horizonは完了まで利用が制限され、更新中に仮想マシンを新しく作ったり消したりする操作は勧めない、とあります。PingとHTTPが途切れなかったことは、全API、全アプリケーション、全利用者操作が無影響だった証明ではありません。OpenStackのSLURP方針も、版を飛ばす更新のサポートと、あらゆる環境でのローリング・無停止更新を同一視していません。［2：p.32］［3］

    実運用で目指すのは、宣伝文句としての「無停止」ではなく、どの機能を守り、どこに保守時間を設け、何をもって完了とするかを決めることです。今動いている仮想マシンの通信だけでなく、認証、API、管理画面、新規配置、データベースの状態まで、利用者の動線に沿って測る。そうして初めて、更新の成否を自分たちの環境で言葉にできます。

    登壇企業について

    Open Source Consultingがどんな事業を手がけているかは、cyclewaveの企業解説で紹介しています。

    Open Source Consultingの企業解説へ

    参考資料

    2026年9月23日確認。6ノードの測定結果は発表者の検証環境の結果として扱い、ほかの構成に一般化していません。実際の更新手順は対象版の公式文書と現行設定で再確認が必要です。

    1. OCP「2026 OCP Korea Tech Day」 — 発表一覧。
    2. Shin Hocheol（Open Source Consulting）「Evolution of OpenStack Releases and Kolla-Ansible SLURP Upgrade Strategy」 — pp.17–33に更新案と6ノードの検証。
    3. OpenStack Technical Committee「Release Cadence Adjustment」 — SLURPの支援範囲とローリング更新の限界。
    4. Kolla-Ansible 2026.1「Operating Kolla」 — 事前準備と更新手順。
    5. Kolla-Ansible 2026.1「RabbitMQ」 — 許可経路と事前確認。
  • ETRIのNPUaaS設計、異なるAI半導体をクラウドで共有する

    ETRIのNPUaaS設計、異なるAI半導体をクラウドで共有する

    AI用の半導体を手に入れても、利用者がすぐ使えるとは限りません。モデルに合う装置を探し、ソフトウェアをそろえ、空いている資源を割り当てる。種類の違うNPU（Neural Processing Unit）が混ざれば、その段取りはさらに増えます。2026年のOCP Korea Tech Dayで、韓国の研究機関ETRIは、NPUをクラウドのサービスとして届けるための基盤を示しました。［1・2］

    簡単にまとめると？

    • ETRIは、異なるメーカーのNPUを共通の管理基盤で見つけ、利用者の仕事へ割り当てる設計を示しています。
    • NPUの分割利用や対応モデルは装置・実装ごとに条件があり、掲載された全製品の互換性を保証するものではありません。
    • 段階的な更新と切り戻しを設計しますが、「無停止」は目標であり、すべての構成での実証結果ではありません。

    「装置がある」から「使える」まで

    NPUは、AIの計算を効率よく進めるための専用プロセッサーです。同じNPUという名前でも、メーカーごとにドライバーや開発環境、使えるモデル、メモリーの扱いが違います。研究者や開発者にとって必要なのはチップの一覧だけでなく、仕事を投げたら適切な装置に届き、実行状態を見られる入口です。

    ETRIの資料は、その入口をコンテナと仮想マシンの両方へ広げる構成を描きます。Kubernetesはコンテナの配置を、OpenStackは仮想マシンなどの基盤を受け持ち、その間にサービスの受付、装置の発見と割当て、ストレージやネットワークをつなぐ層を置いています。これは発表資料の設計例であり、すべてのNPUクラウドが同じ構成という意味ではありません。［1］

    メーカーが違っても、運用の入口をそろえる

    資料の図には、異なるメーカーのNPUを見つけ、必要なソフトウェアを入れ、装置の情報を利用者へ渡す部品が並びます。アプリケーションが直接すべての機種差を引き受けるより、基盤側に共通の管理面を置く考え方です。画面に複数の企業名があるからといって、各社のすべての製品やモデルの動作が保証されたわけではありません。［1］

    使える量も一枚岩ではありません。NPUを一つの仕事に丸ごと割り当てる場合と、対応する装置を分割して複数の仕事で使う場合では、隔離や性能の確認方法が変わります。資料には分割・再配置の案が示されていますが、分けられる数や性能は装置と実装の条件付きです。［1］

    更新中も使い続けるには、戻り道が要る

    クラウドではドライバーや装置用の部品を更新し続けます。ETRIは、複数の実行先を段階的に切り替え、問題が出たら元へ戻す流れを図にしています。「Zero-Downtime」という見出しは、この更新設計の目標として読むのが妥当です。すべての構成で停止ゼロを実証した数値は、資料には示されていません。［1］

    さらに資料は、NPUを含むKubernetesの作成画面と、LLMの性能試験ツールの画面を載せています。運用の入口に加え、性能を測る手段も示しています。一方、機種間の優劣やサービス全体の可用性を判断するには、モデル、入力長、バッチ、消費電力、測定回数などをそろえた別の検証が必要です。掲載画面だけで比較順位は付けられません。［1］

    資料の末尾には、openKcloudの公開リポジトリも示されています。ただ、コードが公開されていることと、全機能が実環境で安定して動くことは別です。［1・3］

    この発表の面白さは、NPUを「GPUの代わりの部品」として終わらせない点です。開発者が使い始められるか、更新を戻せるか、分割しても性能を説明できるか。半導体をサービスに変える仕事は、チップの外側にもあります。

    参考資料

    2026年9月23日確認。発表資料は画像主体の17頁で、構成図と画面を原寸で確認しました。講演動画・質疑応答は根拠に含めません。資料の「無停止」は設計図の表現で、全環境の運用実績として扱いません。

    ［1］ETRI / Hyunhwa Choi「NPUaaS: A Redesign of the AI Semiconductor Cloud Service Platform」OCP掲載スライド（17頁。統合基盤p.8、異種装置管理pp.9–10、更新p.11、分割p.12、操作・測定画面pp.13–14）。

    ［2］Open Compute Project「2026 OCP Korea Tech Day」（開催日、登壇者、資料の掲載）。

    ［3］openKcloud公開リポジトリ（発表資料p.16の公開開発先。記事本文の性能・互換性の証拠としては用いていません）。