Nova schedulerのcustom filterをつくってみた / Writing my own custom filters in Nova

2025年6月19日の日本OpenStackユーザ会 第52回勉強会で発表した「Nova schedulerのcustom filterをつくってみた」の講演資料です。
詳細: https://openstack-jp.connpass.com/event/356594/

Transcript

1. Nova scheduler の custom filter をつくってみた NTTコミュニケーションズ プラットフォーム‧サービス本部 クラウド&ネットワーク部 井⼝ 和真 日本OpenStackユーザ会 第52回勉強会 2025年6月19日
2. 2 ⾃⼰紹介 井⼝ 和真 Kazuma Inokuchi / @inox-ee(or @inox__ee) 職歴 • 2023年03⽉ 修⼠課程(情報理⼯学)修了 • 2023年04⽉ 株式会社NTTコミュニケーションズ ⼊社 • 部署：SDPF(Smart Data Platform)仮想サーバの開発/運⽤ • 業務：Compute Node ver.up (OS/Kernel, Middleware, etc.) 社内はslackがメインなので、 実はアイコンのほうが馴染み深かったり
3. 3 本セッションのお品書き テーマ：Nova の custom filter 実装を通じて得られた⾟さ、学びについて 1. 触れて、試して、 OpenStack を知る a. novaから⾒えるもの、⾒えないもの 2. ⾝近な業務課題こそ、カスタム機能のお試しは絶好の使い所 a. 「⼩さく始めて⼤きく育てる」
4. 5 カスタム Nova filter 実装の経緯
5. 6 z NW装置 NW基盤 z ユーザーリソース VM Hypervisor Internet Colocation Storage Virtual Server コンピュート イメージ 高可用性 ブロック ストレージ テスト IaaS 基盤のウラガワ VSチームの担当 IaaS機能の開発：仮想サーバ(VS)
6. 7 背景：Compute Node の ver. up プロジェクト CPv2(旧) から CPv3(新) へ：Compute Node の OS/Kernel/仮想化 ver.up Applications Data Runtime Middleware Guest OS Virtualization Host OS Hardware NW/Storage IaaS屋の
 責任範囲
 VM
 VM
 CPv2
 CPv3
 ユーザ
 開発
 差分なし
 HW/OS/Kernel/QEMU/…

7. 9 課題：「新旧混在」 vs シナリオ試験 (前提 … 検証環境では、⼀定期間 新旧 ver. が混在する状態で試験を実施) 「シナリオ試験 = ユーザーの動作を模したリグレッション試験」 において、以下の⽭盾が⽣じる • ユーザー観点 ← 従来の Nova scheduler はこちら  → VM 互換 = 新旧いずれに搭載するかは関⼼の外 • 開発+QA観点  → 各Compute Node(※)を別々の検証項⽬として検証 (※) OSだけでなく⼀部HWも隠蔽しているため、Compute Node のパターンは多岐に渡る   e.g. パターンA = α社製サーバー × Ubuntu パターンB = β社製サーバー × RHEL ユーザ
 開発
 差分なし
 HW/OS/Kernel/QEMU/…
 両観点の期待値を
 同時に満たしたい

8. 11 課題：これまでの運⽤ ⼿動で閉塞/開放( openstack compute service set )を操作。さすがに⾯倒… QAチーム
 開発
 パターンAを検証します
 (パターンA以外を閉塞…)
 QAチーム
 パターンAに
 VM作成できました
 QAチーム
 開発
 パターンBを検証します
 (パターンB以外を閉塞…)
 QAチーム
 パターンBに
 VM作成できました

9. 12 提案：カスタム nova filter の作成    を nova filter で代⽤できないだろうか？ QAチーム
 開発
 パターンAを検証します
 (パターンA以外を閉塞…) 
 QAチーム
 パターンAに
 VM作成できました
 QAチーム
 開発
 パターンBを検証します
 (パターンB以外を閉塞…) 
 QAチーム
 パターンBに
 VM作成できました
 …

10. 13 提案：今回のゴール 主機能：Compute Node の HW/OS に基づく VM スケジューリング 要 件： • 検証フローの改善  検証時のデプロイにおける⼿作業を撲滅する。 • 低コスト  検証環境に閉じる。リーズナブルな解決を。 • シナリオ試験への影響極⼩化  検証結果が変更差分に従属してはならない。 • 今後への布⽯  今回の経験を、将来の商⽤フィルタ開発に活かす。
11. 14 Nova scheduler の仕組み
12. 15 機能 VM がどのホストやノードで起動されるべきかを決定 スケジューリングプロセス 1. Prefilters  スケジューリングの初期段階 2. Filters  ホストのリクエスト適合or不適合を検査 3. Weighers  通過したホスト内で重み付け Nova Scheduler とは Compute schedulers — nova 31.1.0.dev114 documentation より
13. 17 実装案の検討
14. 18 実装⽅針検討 商⽤影響 実装コスト 試験影響 (Filter の利⽤)  Image property の付与 ✅（※1） ✅ ❌（※1） ❌  Flavor extra_spec の付与 ✅（※1） ✅ ❌（※1） ❌  Placement Traits による制御 ✅（※1） ❌（※2） ❌（※1） ❌  既存 Filter の活⽤ ✅ ✅ ✅ → ❌（※3） ✅  カスタム Filter の実装 ✅ ✅ ✅ ✅  Middleware の実装 ✅ ❌ ✅ ❌
15. 19 実装⽅針検討(備考) 商⽤影響 試験影響 Image property の付与 ✅（※1） ❌（※1） Flavor extra_specs の付与 ✅（※1） ❌（※1） Placement Traits による制御 ✅（※1） ❌（※1） 実装コスト  Placement Traits による制御 ❌（※2） ※1：各案の試験影響 検証専⽤ Image / Flavor の作成により環境の分割は可能だが、 (課⾦システムにも影響する)Image / Flavor のリリース観点で 極⼒ 商⽤ / 結合試験環境差分を低減したいため、却下。 ※2：Traits の実装コスト CPU命令セット等の情報をリソースプロバイダに設定。 Rocky 以降フレーバーやイメージとの紐づけが可。 Queens ver. の現環境では⼗分に機能を活⽤できず…😭
16. 20 ※3：既存 Filter 利⽤の頓挫 「Anchor となるServerGroup & VMを作成し、  各Compute Node に配置すれば擬似的にスケジュール出来る！」 …と喜んだのは束の間、 ServerGroup API policy (os_compute_api:os-server-groups )を ユーザに開放しておらず、今回は差分評価のレバレッジも少なかったため、案としては却下。 実装⽅針検討(備考) 試験影響  既存 Filter の活⽤ ✅ → ❌(※3) 本資料作成中に気づいたが、 
 もしかしたら SameHostFilter でも
 機能要件を満たせたのでは…(小声) 
 📝ServerGroupAffinityFilter 　：あるグループに属するインスタンスを同⼀ホストに配置する Filter
17. 21 custom filter 実装
18. 22 公式ドキュメントに Filter の実装⽅法が記載されている📝 1. nova.scheduler.filters.BaseHostFilter を継承 2. コアロジックとなる host_passes 関数を実装 a. 引数：2 つの主要な引数を受け取る i. HostState オブジェクト ：候補となるホストの現在の状態と属性 ii. RequestSpec オブジェクト ：インスタンスのリクエストに関する詳細情報 b. 戻り値：判定結果である boolean を返す i. 与えられた host_state が request_spec に記述された VMの要件を満たす場合 True を返し、 そうでない場合 False を返す Writing Your Own Filter nova/scheduler/filters/all_hosts_filter.py
19. 23 実装概要 機能 対象のCompute NodeのHW/OSに基づき、VMを指定HVにlaunchする ⽬標 1. HostState から HW/OS 情報を取得 ① 2. RequestSpec から指定する HW/OS の組み合わせを取得 ② 3. ① ② が等価なら True / そうでないなら False を返す
20. 24 ① ホスト情報を取得：HostState オブジェクト HostState オブジェクトの中⾝を覗くも… 意外と(?) OS の情報が⾒つからず。 _update_from_compute_node(compute) └─ nova.objects.ComputeNode 　└─ _from_db_object(...) 　　└─ nova.db.main.api 　　　└─ _compute_node_select(...) 　　　　└─ models.ComputeNode 　　　　　└─ compute_nodes テーブル 定義 pdbで実際のオブジェクトを見る 型定義されていないため 
 実行時オブジェクトを見に行かないと 
 中身が分からないのも地味に一苦労… 

21. 25 ① ホスト情報を取得：Aggregate で代⽤ Aggregate は HostState から取得可能 📝 チームの慣例：Compute Node とイメージ/Flavor の紐づけのみに利⽤  原  義 ：任意の特性に基づいてパーティショニングするメカニズム[1] → Aggregate を⽤いて Compute Node に tag 付けすることで、   擬似的に HW/OS 情報を取得可能に。 [1] Host aggregates — nova 31.1.0.dev138 documentation
22. 26 ② リクエスト側：RequestSpec オブジェクト RequestSpec オブジェクトの中⾝を覗くも… API実⾏時にユーザが投げることができる情報はほぼ以下のみ • scheduler_hints • Flavor (商⽤影響を加味して却下) GUI(※)では前者を指定出来ないため、 metadata から指定する⽅法を検討する ※ シナリオ試験はGUI＆APIを併⽤。   与えられる情報は metadata しか選択肢はほぼ無い。 定義 pdbで実際のオブジェクトを見る Filterは様々なリクエスト上で 
 用いられるためか、 
 ロジックが冪等かつステートレスな 
 実装になっていることを痛感。 
 (create or resize のような情報も無い) 

23. 27 ② リクエスト側：HW/OS の組を指定 以下の⽅法で cp_variant (=HW/OSの組) を付与 📝 • scheduler_hints 　設計思想通りであるため、実装可 • instance metadata  API call 数に気をつけて(※次ページ)実装 上記より取得した値②を、Compute Node の値①と同値であるか評価 → 最終的な custom nova filter の host_passes 関数へ実装 フローチャート(by Claude Sonnet 4) 実装を単一のfilterに閉じたため、 
 検証環境用nova.confに追記すれば即適用 ✅
 商用nova.confはノータッチなので安心。 

24. 28 [余談] metadata 取得を“うまく”実装する 1 VM あたりの Filter 計算量 = O(n) (n = ホスト数) 📝 簡易的なキャッシュも実装し、1 API call per リクエストを⽬指す • 構造： request_id と metadata をキーとする辞書型 • 機構：LRU(Least Recently Used)。基本 FIFO が期待される。 (nova-scheduler.log より) L1：前段の AggregateInstanceExtraSpecsFilter のログ L2：Fetch は１回のみ L3：CustomComputeVariantFilter (今回実装)のログ L4：Filter 結果
25. 29 custom filter 実装をふり返る
26. 30 効果 導⼊効果 シナリオ試験開始以降、実施⽅法に関する問い合わせは0件 → ⼿作業 & コミュニケーションコストの削減により、定量 & 定性的効果は共に良好 技術的効果 custom filter 実装のノウハウ獲得 • nova から⾒える世界、⾒えない世界(e.g. HV → nova.objects.ComputeNode クラス) • 公式 docs のガイド (特に最新版) • [余談] ユニットテストは AI Agent の強さが発揮された 今後の課題 • デバッグ⼿法 … 今回は pdb デバッガでコツコツ実⾏。将来的にはプロファイラも。 • 動的型 … オブジェクトの中⾝が実⾏時にしか分からない 😢
27. 31 まとめ • まずは触って、試して、 OpenStack を知ろう ◦ 今回の学び = novaから⾒えるもの、⾒えないもの • ⾝近な業務課題を通じて、カスタマイズの機会を増やす ◦ 「重要だが緊急ではない」課題解決は、AI Agent が更に後押し ◦ 「⼩さく始めて⼤きく育てる」 → OpenStack + 独⾃のビジネス要件を実装し、サービス向上へ ◦ ゆくゆくは Upstream 版の Contribution チャンスとしても