通信キャリアにおける最近のOpenStackの活用事例-公開版

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

© 2024 KDDI 4 日本OpenStackユーザ会第47回勉強会 OpenStackを利用したシステム音声サービス全般第2世代第3世代音声サービスモバイルコアシステムその他機能のエンハンスメント (IPv6化、モバイルコア要件の取り込み) 完全内製での構築特定システム第1世代音声サービスの追加、サーバの共通化内製での運用巻き取りバージョンアップの内製対応完了(OpenStack/Ceph) OpenStack Queens RHOSP 13 OpenStack Train RHOSP 16.1 OpenStack Wallaby RHOSP 17.1 第2世代まではモバイル系はシステム毎にOpenStackなどを利用 A用基盤 B用基盤 C用基盤一貫してRed Hat社のOpenStack ディストリビューションを選択

Slide 6

Slide 6 text

© 2024 KDDI 5 日本OpenStackユーザ会第47回勉強会 JANOG 49 過去の発表での取り組みのご紹介第1世代（運用中）第2世代（運用中） OpenStack NFV基盤のバージョンアップと運用改善を内製対応した話（KDDI編）@CODT2022(2022/07) KDDI固定電話ネットワーク、NFV化の5年間の道のり @ JANOG49(2022/02) JANOG 53 CODT2022 第3世代（構築中）次世代OpenStack NFV基盤の検証 @JANOG53(2024/01)

Slide 7

Slide 7 text

© 2024 KDDI 6 日本OpenStackユーザ会第47回勉強会 ◼ 通信事業者におけるOpenStackを含めたプライベートクラウドの利用方法は大きく３つ主に通信システムを対象としたクラウドを見ています通信システム 5GC LTE IMS クラウドシステム ITシステム Web 課金監視クラウドシステム法人のお客様クラウドシステム社内利用お客様へ提供 • 一般的なIT要件 • テナントシステムは比較的小規模 • 特殊なネットワーク用要件が多い (CPU pin/SR-IOV) • テナントシステムが比較的大規模 • 一般的なIT要件 • SLAの高い法人のお客様への提供

Slide 8

Slide 8 text

© 2024 KDDI 7 日本OpenStackユーザ会第47回勉強会 NFVとはネットワーク仮想化/NFV （Network Function Virtualization）狭い意味でのNFV (ETSI-NFV) 通信キャリアが使用する（しか使用しない）ネットワーク機能(EPCやIMS）を仮想化環境（OpenStack/KVMであることが多い）で動かし、サービスを提供すること。広い意味でのNFV 仮想ルータや仮想ファイアウォールなどを含むネットワーク装置（と認識されているものならなんでも）を仮想環境で動かすこと。

Slide 9

Slide 9 text

© 2024 KDDI 8 日本OpenStackユーザ会第47回勉強会 NFV/ネットワーク仮想化のむつかしさ仮想化以前にソフトウェア処理は大変 67.2 nsec = 10Gbps/64B NW機能 NIC NIC • ルータ/FIBのチェックとEthernet MAC書き換え • NAT/IPヘッダの書き換え • FW/ポリシーチェックとルールの適用 • etc パケットプロセッシング 6.72 nsec = 100Gbps/64B

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© 2024 KDDI 10 日本OpenStackユーザ会第47回勉強会私たちのプライベートクラウドが目指している方向性脱「仮想化基盤」、「プライベートクラウド」化システム開発の効率化スキルやアセットの共有効率的なファシリティ利用パブリッククラウドとの連携利用者プライベートクラウドをKDDIで広く利用していくことで生じるメリット Excelの申請書管理者側の作業待ち・承認待ち AZごとの独立性を高め、障害影響を局所化 • 共通的なインフラ・プラットフォームとして利便性を向上させセルフサービスやポータルによる利用者自身での自己完結。 • クラウドっぽい考え方によるアベイラビリティの向上

Slide 12

Slide 12 text

© 2024 KDDI 11 日本OpenStackユーザ会第47回勉強会内製化の採用 • SIでの構築物を引き継いでの開発/増設/運用の内製化 • SIerを利用しない内製での開発・構築 • 一般的なSIerでの請負 2016年～2021年 2021年～2023年 2023年～現在音声サービス全般第2世代第3世代音声サービスモバイルコアシステムその他特定システム第1世代 OpenStack Queens RHOSP 13 OpenStack Train RHOSP 16.1 OpenStack Wallaby RHOSP 17.1 なかなかにむつかしい領域で…品質・コスト・納期それぞれで内製化が近道だと思い内製化してます

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© 2024 KDDI 13 日本OpenStackユーザ会第47回勉強会 ◼ オープンソースである事 ⚫ カスタマイズ性が高い • 自分たちのニーズに合わせて機能の追加 • ソースコードへの改造だけではなく製品や構成の組み合わせなども自由度が高い ⚫ インターネット上で情報が見つかる • とりあえずネットで調べれば何かしら情報が出てくる心理的安全性 • 問題発生時も最悪ソースコードを見れば解決できる ⚫ コミュニティが活発 (他とは比較して・・・) なぜOpenStackを選んでいるか

Slide 15

Slide 15 text

© 2024 KDDI 14 日本OpenStackユーザ会第47回勉強会 ⚫ KDDIではビジネス的な判断でコアな機能については製品版OSSを選択どのOpenStackを選択したか OSS-Upstream版 OSS製品版：(e.g. Red Hat) プロプライエタリ製品構成・使い方組み合わせや使い方自由ある程度組合せや使い方が自由ある程度パターンを制限パターンを制限サポートコミュニティサポート、セルフサポートベンダーサポートベンダーサポート修正反映 Upstreamで実施、フォークして自ら実施ベンダーで実施（原則Upstreamファースト）ベンダーで実施お値段 - 💸💸 💸💸💸 ※お値段については雰囲気での比較です。見積もりを取って比較しましょう！品質の要件キャリアグレード、総務省報告対象体制面の制限 OSS開発できるようなソフトウェアエンジニアを多く抱えていない NEPとの相互接続性 5G-Coreを提供するようなNEPベンダが動作をサポートしている ⚫ OpenStackを利用する上での選択肢

Slide 16

Slide 16 text

© 2024 KDDI 15 日本OpenStackユーザ会第47回勉強会 ◼ Red Hat OpenStack Platformを採用 ⚫ https://www.redhat.com/en/about/press-releases/kddi- corporation-selects-red-hat-lay-open-foundation-5g-services- and-more ◼ そもそも製品版にあまり選択肢がない ⚫ あとはCanonical(ubuntu)くらい。。？ ◼ OpenShiftやCeph等の他の製品OSSでもRed Hatを採用しており、互換性やサポートが充実どういうOpenStackを使っているか

Slide 17

Slide 17 text

© 2024 KDDI 16 日本OpenStackユーザ会第47回勉強会 OpenStackの全体構成バックボーンネットワークグローバルリージョン認証機能ダッシュボード DNSaaS 東日本リージョン2 認証機能仮想サーバ仮想ネットワーク仮想ボリュームその他‥ 東日本リージョン1 認証機能仮想サーバ仮想ネットワーク仮想ボリュームその他‥ 西日本リージョン1 西日本リージョン2 ◼ 各リージョンごとにOpenStackクラスタをデプロイ ⚫ 全体を連携して利用できるようにグローバルリージョンを設定し認証機能やDNSaaSなどといった機能やダッシュボードを提供

Slide 18

Slide 18 text

© 2024 KDDI 17 日本OpenStackユーザ会第47回勉強会利用しているOpenStackのコンポーネント通常リージョン Storage Cinder backend/ Swift 互換Object グローバルリージョンデプロイ用デプロイ用 LBaaS VNFM DNSaaS 主にOpenStackのメジャーなサービスのみをデプロイ CinderのバックエンドやSwift互換のオブジェクトストレージはCephで提供

Slide 19

Slide 19 text

© 2024 KDDI 18 日本OpenStackユーザ会第47回勉強会 OpenStackの全体構成 ◼ 5-Stage ClosトポロジーのDC NWを採用 ◼ ServerのNICは 100G NIC x4(SR-IOV用途等を含む) ◼ 影響範囲の局所化・生存性向上を考え、AZやAZ内リソースを分割 az-b az-a (～300台程度) Server Server Server Ceph Server Server Server Ceph Server Server Server Ceph Server Server Server Ceph Leaf switch Leaf switch Leaf switch Leaf switch Leaf switch Leaf switch Leaf switch Leaf switch Super spine switch Super spine switch Super spine switch Spine switch Spine switch Spine switch Server Server Server Ceph Server Server Server Ceph Leaf switch Leaf switch Leaf switch Leaf switch Spine switch Spine switch Spine switch Group1(～100台程度) Group2 Group1 Group2 ※絵の記載の数量はイメージであり、実際の数量とは異なります

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© 2024 KDDI 20 日本OpenStackユーザ会第47回勉強会認証基盤のマルチリージョン連携(1/2) 課題 ▸ 一貫性のあるユーザ体験価値のためにマルチリージョンを連携して利用できるようにしたい ▸ Red Hat OpenStack Platform(RHOSP)としてマルチリージョンでのインテグレーションのベストプラクティス、サポートがなく、「独立した」OpenStackを作成することしかできない。大阪 OpenStack 東京 OpenStack 中央配置型案 ID Name ZZZ UserA ID Name AAA UserA ▸ ユーザは認証情報やAPIやGUIのエンドポイントを利用するリージョン毎に使い分ける必要がある API endpoint GUI endpoint API endpoint GUI endpoint 大阪 OpenStack 東京 OpenStack ▸ 認証情報を中央集権的に一か所のリージョンで管理する方式 ▸ 認証をつかさどるOpenStackがSPOF となり障害の影響が全体に波及する Global OpenStack ID Name AAA UserA API endpoint GUI endpoint 今までの構成分散型案大阪 OpenStack 東京 OpenStack ▸ すべてのRegionで同様の機能が提供できる分散型 ▸ SPOFを嫌う場合はローカルを参照しても利用できるようにする Global OpenStack API endpoint GUI endpoint API endpoint GUI endpoint API endpoint GUI endpoint ID Name AAA UserA ID Name AAA UserA ID Name AAA UserA

Slide 22

Slide 22 text

© 2024 KDDI 21 日本OpenStackユーザ会第47回勉強会認証基盤のマルチリージョン連携(2/2) 解決方法 ▸ 各OpenStackを独立したOpenStackクラスタとしてデプロイ・管理 ▸ 各OpenStackのKeystoneはAPIのトークン発行用の鍵情報を共有 ▸ 「ユーザやプロジェクトのUUID」を同一の値で作ることで同じ鍵を使っての認証が可能 ▸ このためユーザは単一Keystoneに問い合わせるだけでトークン発行、APIカタログ入手ができるようになるため各リージョンの存在を意識する必要がなくなるトークンの検証トークンの発行トークンください（認証情報）トークン発行：AAA 一覧ください(トークン付き) 一覧をどうぞユーザ情報を知らなくていい扱わなくていいユーザA ユーザB Keystone (中央サイト) Novaとか (ローカルサイト) 🔑 🔒 🔒 🔒 Keystone (ローカルサイト) 🔑

Slide 23

Slide 23 text

© 2024 KDDI 22 日本OpenStackユーザ会第47回勉強会ネットワーク仮想化(1/2) 課題 ▸ データセンタNWで利用できる VLAN数に制限があるためVLAN数の削減が必要 ▸ データセンターNW側での設定変更や追加に時間・コストがかかる。 ▸ OpenStackでのNWの作成とデータセンターNWの設定の連携がむつかしい今回採用した仮想ルータを利用した方式 OpenStack テナントリソース vRT VM VM VRF-ABC 10.2.34.0/25 OpenStack Admin リソース VRF-ABC(to 10.0.0.0/8) RT DCNW vRT Overlay OpenStack テナントリソース VM VM 192.168.0.0/25 VRF-ABC(to 10.0.0.0/8) RT DCNW VLAN 今までの構成 L 2 DCNWとOpenStack の間の接続がL2接続 L 3 仮想ルータを境界に配置し DCNWとBGP等で接続 L 3 IaaSテナントともBGP等で接続しNWの作成時に外部 NWに対して作成したNWを自動で広報

Slide 24

Slide 24 text

© 2024 KDDI 23 日本OpenStackユーザ会第47回勉強会ネットワーク仮想化(2/2) OpenStack テナントリソース vRT VM VM VRF-ABC 10.2.34.0/25 OpenStack Admin リソース VRF-ABC(to 10.0.0.0/8) RT DCNW vRT Overlay Shadow リソース仮想ルータ仮想マシン仮想NW Neutron Plugin Ansible Config Plugin Ansible Playbook Neutron API 1.仮想リソース作成 2.設定の生成と投入解決方法 ▸ 仮想ルータを導入し、仮想ルータをOpenStackとインテグレーション（オリジナル機能） ▸ ユーザは通常のNeutronによる仮想ルータと同じ使用感でより高機能・ハイスペックな仮想ルータを利用できる

Slide 25

Slide 25 text

© 2024 KDDI 24 日本OpenStackユーザ会第47回勉強会 IPv6化（1/2）歴史的経緯により社内に多数存在するIPv4面。様々な設備やシステム間での統合上の足かせになりがちなため、このタイミングでIPv6化していく方針で取りくみ Servers Servers Private Cloud Leaf SW Leaf SW Leaf SW Spine SW Spine SW Spine SW Leaf SW Servers DCI Servers Private Cloud Leaf SW Leaf SW Spine SW Spine SW Leaf SW Servers DCI 基本的な統合先をIPv6にする物理的なハードウェアやネットワークを極力シンプル化複雑さはすべてクラウド上(ソフトウェア)に寄せる IPv6 IPv6 IPv6 IPv4 for VRF-A IPv4 for VRF-B IPv4 for VRF-C Servers Servers Private Cloud Leaf SW Leaf SW Leaf SW Spine SW Spine SW Spine SW Leaf SW Servers DCI Servers Private Cloud Leaf SW Leaf SW Spine SW Spine SW Leaf SW Servers DCI IPv4のアドレス空間が被っており VRFの設定が各所で必要 VRF統合は不可能様々なレイヤーで複雑な処理を実施 IPv4 for VRF-A IPv4 for VRF-B IPv4 for VRF-C IPv4 for VRF-A IPv4 for VRF-B IPv4 for VRF-C IPv4 for VRF-A IPv4 for VRF-B IPv4 for VRF-C IPv4 for VRF-A IPv4 for VRF-B IPv4 for VRF-C IPv4 for VRF-A IPv4 for VRF-B IPv4 for VRF-C

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© 2024 KDDI 27 日本OpenStackユーザ会第47回勉強会スキルが必要（楽しいけど） OpenStack含めたオープンソース活用で求められる力 ▸ 専門性 OSS、仮想化など幅広い領域への理解 ▸ 課題解決力無数にある解法の選択 ▸ 変化への追従技術トレンドおよび技術背景への理解インフラ技術のオープン化は避けられない道…外部に頼れる技術者はそう多くはないため、自らスキルを獲得していく必要がある

Slide 29

Slide 29 text

© 2024 KDDI 28 日本OpenStackユーザ会第47回勉強会 ◼ OpenStack(オープンソースソフトウェア)としてはできることでも、製品版のプロダクト(ダウンストリーム)ではサポートできることは限られる ◼ さらに製品版でサポートできるが、製品の持つ標準インストールツールからそれらが完全に適用できるわけではない製品版OSSでの苦労点 ▸ またOSSでできないことは製品版ではできない(=D) ▸ 製品版はOSSに機能が実装されてから実装される ▸ Upstream firstという考え方 ▸ OSSのダウンストリームとアップストリームの間には、どうしてもタイムラグも発生する（テストや安定化のため） C=OpenStackでできること B=製品ベンダでサポートできること A=製品でデプロイできること D=OpenStackでできないこと製品版を使う上においても Upstreamをきちんと把握し、何ができてできないか、必要に応じて機能実装の依頼をしていく必要がある（そうしないとずっと機能が入らない）

Slide 30

Slide 30 text

© 2024 KDDI 29 日本OpenStackユーザ会第47回勉強会 ◼ 安定しているML2/OVSではなくML2/OVNの選択 ⚫ OSSベンダ側が開発リソースをK8sともプロダクトを共通化できるOVNにシフト ⚫ ML2/OVSの機能で十分満足していたが…渋々ML2/OVNを採用製品版OSSでの苦労点 https://speakerdeck.com/orimanabu/ovn- kubernetes-introduction-ja-2023-01-27?slide=5 自社都合だけでは技術選択ができない＋無理に選択するとVer. up やサポートで禍根を残す

Slide 31

Slide 31 text

© 2024 KDDI 30 日本OpenStackユーザ会第47回勉強会 ◼ OSS製品が対応する方法に常に従うこと ⚫ 自己流のカスタマイズをすると予期せぬ設定ファイルの書き換えなどが起こる製品版OSSでの苦労点インストーラインストーラも OSSソフトウェア ①インストーラが Config生成 ②手動で編集初期インストールしばらくたって… インストーラ Upgradeするなど ②手動で編集したファイルが先祖返りする設定ファイルの変更等もインストーラを経由すべし

Slide 32

Slide 32 text

© 2024 KDDI 31 日本OpenStackユーザ会第47回勉強会 ◼ ラージスケールでのデプロイに時間がかかる ⚫ 標準的な構成でかつ台数が少ない場合はすぐ終わる処理も・・・ ⚫ 諸々の細かなパラメータの取り込みのために複雑化すると・・・ ◼ 複雑な自動化が組み込まれており独自に改変することがむつかしい製品版OSSでの苦労点+ラージスケールインストーラインストーラ 30分 10時間数十台数百台

Slide 33

Slide 33 text

© 2024 KDDI 32 日本OpenStackユーザ会第47回勉強会テナントサポート課題① OpenStackは使うだけでもむつかしい。適切に利用したりOpenStackの機能を理解して設計することも大変課題② QAなどが多くプライベートクラウド提供者側に負荷が集中する Articles Docs テナント提供者 QA • 知らない！ • わからない！ • 教えて！ • 質問が多い！ • 大量のテナント • 人的リソース不足 • 改善活動に手が回らない • OpenStackに関する知識や経験が不足 • 適切な利用・設計ができないドキュメンテーションの拡充や頻出問い合わせや依頼に対する自動化対応などなど

Slide 34

Slide 34 text

Slide 35

Slide 35 text

© 2024 KDDI 34 日本OpenStackユーザ会第47回勉強会 ◼ KDDIではRed Hat製品を利用しながらも、SIや周辺機能の開発を内製化してます ◼ 通信分野における独特のチューニングや冗長化設計などは醍醐味の一つ ⚫ 検閲により削除されました ◼ 相応の技術力も求められるますがOpenStackはOSSなこともあり内部まで見れることでトラブル解決や修正対応も早くできる（ことが多い） ◼ 皆さんでOpenStack使って盛り上げましょう！！内製化していろいろやってます！興味ある人がいればお声がけください！もう少し詳しい構成を聞いてみたいどんな仕事か聞いてみたい Cephってどうですか‥？内製化ってどうですか？

Slide 36

Slide 36 text

No content