NFV基盤のOpenStack更新～9世代バージョンアップへの挑戦～

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 1. ドコモのネットワーク仮想化基盤の概要 1/2 ドコモでは2016年以来、ETSI ISG NFV規格に準拠した仮想化基盤を構築し、コアネットワークシステムを収容・運⽤ Data Centers 27 Clusters 100 Servers 11,000＋ Virtual Network Function 20＋ Virtual Machines 200,000＋ VNF VM VM VM VM 4

Slide 6

Slide 6 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 1. ドコモのネットワーク仮想化基盤の概要 2/2 • OpenStack, KVMベースのIaaS基盤上で様々なアプリケーションを運⽤ • 一部のアプリケーションについてはContainer on VMの形式でデプロイ • 全国に約100のクラスタが存在 KVM+qemu VM VM APL APL VM Container APL 5 ︓各地域やデータセンタに配置された独⽴した OpenStack Clusterを指す

Slide 7

Slide 7 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 2. ネットワーク仮想化基盤導入・VersionUPの歴史 6 これまでに3回のVersion UPを実施 • 2016年導⼊からIcehouse・Mitakaを経てVictoriaへ更改中 • 現在は初の複数世代バージョンアップ＆サービス無中断に挑戦中 Icehouse導⼊ Icehouse→Mitaka更改再構築⽅式 ※初の複数世代UP Mitaka→Mitaka更改ローリングアップグレード⽅式 ※初のサービス無中断 Mitaka→Victoria更改ローリングアップグレード⽅式 ※初の複数世代UP＆サービス無中断 2016年 2017年 2019年 2023年 OpenStackはバージョンがaから始まり、アルファベット順である今回

Slide 8

Slide 8 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 2. ネットワーク仮想化基盤導入・VersionUPの歴史 1/4 7 2016年に初期導入 • 2つのOpenStack RegionにvEPCをデプロイ。 • ベアメタルのEPCとプール構成を組むことで、問題発生時のサービス影響を極小化。 Icehouse vEPC （ベンダA） vEPC （ベンダB） Icehouse EPC （ベンダA） EPC （ベンダA） EPC （ベンダA） EPC （ベンダA） EPC （ベンダA） EPC （ベンダB）

Slide 9

Slide 9 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 2. ネットワーク仮想化基盤導入・VersionUPの歴史 2/4 8 2017年に初のVersionUP • Openstack Icehouse -> Mitaka にVersionUP • 小規模なのでサービスを止めたうえで再インストールする手法を選択。4世代のバージョンアップ Icehouse vEPC EPC （ベンダA） EPC （ベンダA） EPC Mitaka vEPC EPC （ベンダA） EPC （ベンダA） EPC Mitaka vEPC EPC （ベンダA） EPC （ベンダA） EPC ターミネーション再インストール再インスタンシエーション

Slide 10

Slide 10 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 2. ネットワーク仮想化基盤導入・VersionUPの歴史 3/4 9 2019年に再びVersionUP • 導⼊から3年経過し、運⽤規模が⼤きくなっていた。 DC︓9 OpenStack Cluster︓33 サーバ台数︓4000台 • サービスを止めずにVersionUPする手法に挑戦。 Mitaka vEPC Mitaka Mitaka vEPC Mitaka Mitaka vEPC vEPC Mitaka vEPC VM移動アップグレードアップグレード

Slide 11

Slide 11 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 2. ネットワーク仮想化基盤導入・VersionUPの歴史 4/4 10 2023年に再々度VersionUP • 導⼊から6年経過し、運⽤規模が更に⼤きくなっていた。 DC︓24 OpenStack Cluster︓75 サーバ台数︓9000台 • 前回同様サービスを止めずにVersionUPする手法に挑戦ローリングアップグレードでOpenStackをMitakaからVictoriaへ更改。9世代バージョンアップ Mitaka vEPC Mitaka Victoria vEPC Mitaka vEPC vEPC vEPC 9世代Skipに挑戦 Victoria Victoria

Slide 12

Slide 12 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 Controller 3. ローリングアップグレードの⽅式（同世代やN+1世代へ）1/4 11 Compute Gen N vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC vEPC Controller Compute Gen N＋1 vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC vEPC N世代で運用中 ControllerをN＋1世代へ更改

Slide 13

Slide 13 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 Controller 3. ローリングアップグレードの⽅式（同世代やN+1世代へ）2/4 12 Compute vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC Controller Compute Gen N＋1 vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC vEPC Gen N＋1 vEPC vEPC VMヒーリング Compute更改

Slide 14

Slide 14 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 3. ローリングアップグレードの⽅式（同世代やN+1世代へ）3/4 13 Controller Compute Gen N＋1 vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC vEPC Controller Compute Gen N＋1 vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC vEPC vEPC vEPC 再度VMヒーリング再度Compute更改

Slide 15

Slide 15 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 3. ローリングアップグレードの⽅式（同世代やN+1世代へ）4/4 14 Controller Compute Gen N＋1 vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC vEPC Controller Gen N＋1 vEPC vEPC vEPC vEPC Compute HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC 順番にVMヒーリング・更改バージョンアップ完了

Slide 16

Slide 16 text

Slide 17

Slide 17 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 4. Openstack複数世代Skipのローリングアップグレードにおける課題 16 複数世代Skipしてしまうと・・・  根本的にOpenStackとしてローリングアップグレードが提供されていない 1. Controllerのアップグレードをどうするか・・ 2. 構造が変わっているデータベースの移⾏をどうするか・・・ 3. 新世代Controllerから旧世代Computeを制御出来ないがどうするか・・・  世代が新しくなりすぎるとAPI差分が大きい 4. 使っていたAPI VersionがDeleteされたり、オプションパラメータが増えたり減ったりしている・・

Slide 18

Slide 18 text

Slide 19

Slide 19 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 先に述べたように稼働中のOpenStackををそのままアップグレードすることが出来ない為、独自にアップグレードを方式を考える必要があった。以下のどちらの道を選ぶかは⼤きな判断ポイントであったが、ドコモでは案②を選択した。 ※サービス継続性を重視案①旧世代Controllerを止めて新世代Controllerをインストールする案②新世代Controllerを追加で新設する 18 4-1. アップグレード⽅式 Compute Controller Gen N Compute Controller Gen N Compute Controller Gen N＋9 Compute Controller Gen N Compute Controller Gen N Controller Gen N＋9 Compute Controller Gen N＋9 Compute Controller Gen N＋9 案① 案② 採用

Slide 20

Slide 20 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 4-1. アップグレード⽅式 19 Controller Compute Gen N vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC vEPC Controller Compute Gen N＋9 vEPC HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC vEPC Controller Gen N HostOS OpenStack Agent Mitakaで運用中新Controllerデプロイ

Slide 21

Slide 21 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 20 Controller Compute Gen N＋9 vEPC HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC vEPC Controller Gen N HostOS OpenStack Agent Controller Compute Gen N＋9 vEPC HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC Controller Gen N HostOS OpenStack Agent DB Migration OpenStack Agent OpenStack Agent 4-1. アップグレード⽅式 vEPC DBマイグレーション互換性Agentインストール

Slide 22

Slide 22 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 21 Controller Gen N＋9 Controller Gen N Controller Compute Gen N＋9 HostOS OpenStack Agent HostOS OpenStack Agent Controller Gen N HostOS OpenStack Agent OpenStack Agent vEPC vEPC OpenStack Agent OpenStack Agent vEPC vEPC vEPC vEPC vEPC vEPC vEPC vEPC Compute HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent 4-1. アップグレード⽅式 VMヒーリング（互換Agent活用） Compute更改

Slide 23

Slide 23 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 22 Controller Gen N＋9 Controller Gen N Controller Gen N＋9 HostOS OpenStack Agent Controller Gen N HostOS OpenStack Agent OpenStack Agent vEPC vEPC vEPC vEPC vEPC vEPC Compute HostOS OpenStack Agent HostOS OpenStack Agent Compute HostOS OpenStack Agent vEPC vEPC vEPC vEPC HostOS OpenStack Agent 4-1. アップグレード⽅式順次VMヒーリング・更改バージョンアップ完了（旧Controller撤去）

Slide 24

Slide 24 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 Controllerノードを一時的に2世代デプロイする方式を選択し、そのうえで旧世代からデータベースを移⾏した。データベースの移⾏においては、世代間のスキーマ構成差分を踏まえた変換が必要な点や移⾏中は運⽤中のデータベースが更新されないように運⽤制限を掛ける必要がありました。 4-2. データベース移⾏ 23 Controller Gen N Controller Gen N＋9 Controller Gen N Controller Gen N＋9 Controller Gen N DB Migration アップグレード未サポート 2世代デプロイ・DBマイグレ

Slide 25

Slide 25 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 Compute Compute 4-3. 互換Agent 24 新旧世代間でControllerノードとComputeノードのサービスがサポートされておらずローリングアップグレードの肝となるVM移動が出来ない。これに対し、旧世代のCompute上に新世代のControllerから制御出来る互換Agent開発、インストールすることでVM移動を可能とした。 vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC Controller Gen N＋9 vEPC vEPC vEPC vEPC VM削除 VM作成 Compute Compute vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC Controller Gen N＋9 vEPC vEPC vEPC vEPC VM作成 OpenStack Agent OpenStack Agent VM削除互換Agent無し互換Agentあり

Slide 26

Slide 26 text

Slide 27

Slide 27 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 4-4. API差分への対応 26 OpenStack Mitaka OSS NFVO VNFM(A) VNFM(C) VNFM(B) VNFM(D) • 本課題は複数世代Skipならではの課題という訳ではありませんが、世代差が広がるほど遭遇する可能性が高くなると思われます。 • 一般的にAPIを発⾏するオペレーション、もしくはシステム側で新たなAPIに対応するのが基本ですが、ドコモの仮想化基盤は下図のようにAPIを発⾏するのは全てシステムで自動化されています。

Slide 28

Slide 28 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 4-4. API差分への対応 27 OpenStack Mitaka OSS NFVO VNFM (A) VNFM (C) VNFM (B) VNFM (D) OpenStack Victoria OSS NFVO API-GW VNFM (A) VNFM (C) VNFM (B) VNFM (D) その為、新たなAPIやパラメータに対応する為には複数の上位システムで追従開発が必要になります。これは開発期間やコストの観点で最適とは言えない状況であったため、ドコモでは下図の⽤にOpenStack側で世代間のAPI差分吸収するGWシステムを開発することで開発期間やコストの最適化に取り組みました。上位システム対応 OpenStack対応開発開発開発開発開発開発

Slide 29

Slide 29 text

Slide 30

Slide 30 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 29 APIを発⾏しているシステム(≒サプライヤ)自⾝が発⾏しているAPI、パラメータを開示できない問題に直面した。 OpenStackからのResponseを参照する動作仕様も不明というケースもあり、机上確認、実機からダンプデータを取得する等で上流⼯程での確認には限りがあり、仕様・設計上の完全性は求めるべくもなかった・・「7割程度の精度の設計」「実機対向試験は問題が出ることが前提」の方針で取り組んだ。 4-4. API差分への対応 OpenStack Victoria OSS NFVO API-GW VNFM (A) VNFM (C) VNFM (B) VNFM (D) ︓IF仕様の開示可能かつ規定済 ︓IF仕様の開示不可 ︓収容VNF種が多く、APIの網羅性懸念あり

Slide 31

Slide 31 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 4. Openstack複数世代Skipのローリングアップグレードにおける課題 30 複数世代Skipしてしまうと・・・  根本的にOpenStackとしてローリングアップグレードが提供されていない 1. Controllerのアップグレードをどうするか →Controllerを増設する⽅式で解決 2. 構造が変わっているデータベースの移⾏をどうするか →運用制限を掛けながらデータ移⾏ 3. 新世代Controllerから旧世代Computeを制御出来ないがどうするか →互換Agentを開発  世代が新しくなりすぎるとAPI差分が大きい 4. 使っていたAPI VersionがDeleteされたり、オプションパラメータが増えたり減ったりしている・・ →後⽅互換性を提供するGWを開発することで解決

Slide 32

Slide 32 text

Slide 33

Slide 33 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 5-1. アップグレード手順と所要期間 32 複数世代Skip更改では自動化プログラムを導⼊したが、更改日数は2.5倍。更改途中に発生する故障サーバ対応は75日（想定外に⻑期化）日数実績日数計画複数世代Skipの更改日数実績同世代/N+1世代の更改 # - 6 新世代Controller新設 1 5 1 データベース移⾏（1回目）★ 2 1 自動VM制御停止 1 自動VM制御停止 3 4 4 上位システムとの通信を閉塞★ 2 上位システムとの通信を閉塞 4 互換Agentのインストール★ Controllerのアップグレード 5 新世代Controllerへサービス切り替え★ 6 1 1 上位システムとの通信を開放★ 1 上位システムとの通信を開放 7 自動VM制御再開★ 自動VM制御再開 8 15 7 Computeのローリングアップグレード★ 3 Storageのアップグレード 9 5 5 Storageのアップグレード★ 5 Computeのローリングアップグレード★ 10 30 25 Total 12 Total 75 - 故障サーバ対応（まばらに発生） ★は自動化計4カ月

Slide 34

Slide 34 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 クラスタ 5-2. 故障サーバ対応の発⽣理由と更改停止箇所 33 • クラスタ内に故障サーバが存在すると更改不可となる箇所が存在する • 更改前、及び更改中に故障サーバは 0台にしないといけない故障サーバによる更改停止箇所複数世代Skipの更改 # 〇新世代Controller新設 1 - データベース移⾏（1回目） 2 - 自動VM制御停止 3 - 上位システムとの通信を閉塞 4 〇互換Agentのインストール 5 - 新世代Controllerへサービス切り替え 6 - 上位システムとの通信を開放 7 - 自動VM制御再開 8 〇 Computeのローリングアップグレード 9 〇 Storageのアップグレード 10 Controller Compute HostOS HostOS HostOS 物理故障 STOP クラスタ内で物理故障サーバが存在すると更改⼯程ストップ

Slide 35

Slide 35 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 5-3. 更改前︓故障サーバ0化計画 34 更改開始に向けて故障サーバが存在していると更改を実施することができない 2カ月前から事前準備として故障サーバの交換を⾏い、更改前には故障サーバを0台の状態にしている（更改しようと思ったらサーバが故障することも・・・涙）事前準備更改クラスタを更改 Contoller、Compute、Storageのバージョンアップ計画的に故障交換クラスタを更改 Controller、Compute、Storageのバージョンアップ計画的に故障交換計7クラスタ（871台）を並⾏で更改計7クラスタでの故障サーバを0台へ Nカ月 N＋4カ月 N-2カ月実績として34台の故障対応を実施 ※全体としては75クラスタ。約9000台

Slide 36

Slide 36 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 5-4. 更改中︓故障サーバ対応の流れ 35 更改中にもサーバの故障が発生することはある。その際は更改⼯程を中断し、故障サーバを①クラスタから取り除く対応、または②故障サーバを交換する対応が必要になってくる・・・A 更改の自動化プログラムとOpenStack状態をあわせ、⼯程を再開する・・・B クラスタ（更改中） Controller Compute HostOS HostOS HostOS Compute HostOS HostOS 更改後更改前対処必要 HostOS HostOS HostOS 物理故障 HostOS HostOS ①故障サーバの減設 ②新規サーバと交換故障新品日数項目 75日故障サーバ対応 40日故障サーバ減設、交換・・・A 35日自動化復旧、自動化エラー・・・B

Slide 37

Slide 37 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 5-4. 更改中︓故障サーバ対応の手順・・・A 36 対策② サーバ故障交換対策① クラスタから減設 • リソース変化なし • リソース減 • 更改中の増設機能は実装無しクラスタリソース（クオリティ） • 物理的なサーバの故障交換が必要 • 1回あたり10営業日（解析、交換部品確認、作業調整、現地交換、組み込み、事後作業） • クラスタからの切り離しが必要 • 1回あたり2.5営業日作業時間（スピード） • クラスタリソースは減らないが、2週間更改⼯程が停止 • 即時更改⼯程に復帰できるが、クラスタリソースが減少 • 使いどころを⾒極める必要がある総評早く更改に復帰したいから対策①を実施したいでもクラスタのリソースが・・・増設できれば・・・更改⼯程へ迅速に復旧するために、故障サーバを切り離ししたい（対策①）。しかし、一度切り離すとリソース増加手段がないため、安易には実施できない「クラスタのリソース」「更改⼯程の進捗」「作業稼働」を考慮して、都度どちらの案で対応するかを判断する

Slide 38

Slide 38 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 5-4. 更改中︓故障サーバ対応の改善策・・・A 37 更改⼯程の特定箇所での増設可否の検証を⾏い、対策①の減設を主として対応する方針に変更予定効果︓スピード＆クオリティを向上故障サーバ対応要否複数世代Skipの更改 # 〇新世代Controller新設 1 - データベース移⾏（1回目） 2 - 自動VM制御停止 3 増設ポイント - 上位システムとの通信を閉塞 4 〇互換Agentのインストール 5 - 新世代Controllerへサービス切り替え 6 - 上位システムとの通信を開放 7 - 自動VM制御再開 8 増設ポイント〇 Computeのローリングアップグレード 9 増設ポイント〇 Storageのアップグレード 10 対策① クラスタから減設 • リソース減 • 更改中の増設機能は実装無しクラスタリソース（クオリティ） • クラスタからの切り離しが必要 • 1回あたり2.5営業日作業時間（スピード） • 更改⼯程までではなく増設ポイントまでリソース調整が必要 • 減設のハードルを低減可能総評追加追加追加

Slide 39

Slide 39 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 5-5. 更改中︓故障サーバ対応の状態戻し・・・B 38 更改中に故障サーバが発生するとOpenStackと自動化プログラムの状態が不一致になる。状態を一致させるために、手動での更改や更改情報を自動化プログラムに反映する必要があるエラー発生時は手動で正常状態に戻す作業が⼤変。特にナレッジが無い時は原因解析や対応手法の確⽴に時間がかかる状態A 状態B 状態C 正常時故障発⽣時 OpenStack 更改自動化プログラム A→B B→C 状態A 状態B 状態C OpenStack 更改自動化プログラム A→B B→C 故障発生手動で更改後、内容を自動化プログラムへ反映 .iniや.yml情報を更新しなければ︕ コマンドをポチポチ

Slide 40

Slide 40 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 5. 商用展開で判明した故障サーバ発⽣における今後の対応 39 複数バージョンアップでオリジナル更改を柔軟性が乏しい自動化していくと・・・  故障サーバ台数を0にしないと更改自動プログラムを実⾏できない 1. 更改開始する前までにクラスタ内の故障サーバ台数を0にする必要がある →2カ月前から計画的に故障サーバ対応を実施 2. 更改中に故障が発生したら、更改を中断して故障対応する必要がある →クラスタからの減設、または故障交換を実施 →工程の特定箇所で増設可否を検証中。今後は減設メインで対応を実施 →故障時に、OpenStackと自動化プログラムの状態合わせを実施（ナレッジをためる）

Slide 41

Slide 41 text

Slide 42

Slide 42 text

©2025 DOCOMO, INC. ALL Rights Reserved. /41 議論ポイント 41 OpenStack更改はどのように実施するのがよさそうですか︖ • ローリングアップグレードやBlue/Greenを活⽤し、どれくらいの期間でバージョンアップするのか︖ • ローリングアップグレードする場合、OpenStackはN＋2世代以内でバージョンアップするのか︖ 一気に複数世代のバージョンアップするのか︖ • 故障等の異常・準正常に対して、柔軟に対応可能なアップグレード方式や実装を追い求める方向性は妥当なのか︖ • OpenStack更改にあたりどのような苦労点があったのか︖ ＃他に将来に向けた課題で気になる点あれば、議論したいです＜ドコモ側状況＞ • ローリングアップグレード方式で9世代のバージョンアップを実施。 • 新規手順の開発や故障対応での更改期間⻑期化に苦労している