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

日本OpenStackユーザ会 第47回勉強会

OpenStack再入門

2. 18:45 - 19:15

Transcript

1. © 2024 KDDI 0 日本OpenStackユーザ会 第47回勉強会 日本OpenStackユーザ会 第47回勉強会 2024/3/6 KDDI株式会社 技術統括本部 ネットワーク開発本部 通信キャリアにおける最近のOpenStackの活用事例
2. © 2024 KDDI 1 日本OpenStackユーザ会 第47回勉強会 自己紹介 ネットワーク開発本部 共通プラットフォーム技術部 松本 良輔 仕事内容： - IaaS Ceph担当 - PaaS OpenShift担当 OpenStackメインじゃないですが、よろしくお願いします！
3. © 2024 KDDI 2 日本OpenStackユーザ会 第47回勉強会 自己紹介 ネットワーク開発本部 シニアエキスパート職 辻 広志 仕事内容： - OpenStack / Ceph / K8s NFV周り全般なんでも屋 - 困ったときの対応要員 クラフトビールが燃料の関西人のNFV芸人です。
4. © 2024 KDDI 3 日本OpenStackユーザ会 第47回勉強会 どんな使い方をしているのかの紹介 （ネットワーク領域での活用例）
5. © 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 ディストリビューションを選択
6. © 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)
7. © 2024 KDDI 6 日本OpenStackユーザ会 第47回勉強会 ◼ 通信事業者におけるOpenStackを含めた プライベートクラウドの利用方法は大きく３つ 主に通信システムを対象としたクラウドを見ています 通信システム 5GC LTE IMS クラウドシステム ITシステム Web 課金 監視 クラウドシステム 法人のお客様 クラウドシステム 社内利用 お客様へ提供 • 一般的なIT要件 • テナントシステムは 比較的小規模 • 特殊なネットワーク用 要件が多い (CPU pin/SR-IOV) • テナントシステムが 比較的大規模 • 一般的なIT要件 • SLAの高い法人の お客様への提供
8. © 2024 KDDI 7 日本OpenStackユーザ会 第47回勉強会 NFVとは ネットワーク仮想化/NFV （Network Function Virtualization） 狭い意味でのNFV (ETSI-NFV) 通信キャリアが使用する（しか使用しない） ネットワーク機能(EPCやIMS） を仮想化環境（OpenStack/KVMであることが多い）で動かし、 サービスを提供すること。 広い意味でのNFV 仮想ルータや仮想ファイアウォールなどを含むネットワーク装置 （と認識されているものならなんでも）を仮想環境で動かすこと。
9. © 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
10. © 2024 KDDI 9 日本OpenStackユーザ会 第47回勉強会 NFVで利用する黒魔術たち 計算リソースの最適化 VM リソース リソース VM VM 占有 ネットワーク処理の効率化 仮想化 スタック VM HW バイパス • CPU Pinning • Hugepages • DPDK • SR-IOV このような技術をいろいろと活用しながらネットワーク機能を提供しています
11. © 2024 KDDI 10 日本OpenStackユーザ会 第47回勉強会 私たちのプライベートクラウドが目指している方向性 脱「仮想化基盤」、「プライベートクラウド」化 システム開発の効率化 スキルやアセットの共有 効率的なファシリティ利用 パブリッククラウドとの連携 利用者 プライベートクラウドをKDDIで広く 利用していくことで生じるメリット Excelの申請書 管理者側の作業待ち・承認待ち AZごとの独立性を高め、障害影響 を局所化 • 共通的なインフラ・プラットフォームとし て利便性を向上させセルフサービスやポー タルによる利用者自身での自己完結。 • クラウドっぽい考え方によるアベイラビリ ティの向上
12. © 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 なかなかにむつかしい領域で…品質・コスト・納期それぞれで 内製化が近道だと思い内製化してます
13. © 2024 KDDI 12 日本OpenStackユーザ会 第47回勉強会 OpenStackの使い方の紹介 （構成やデプロイしているコンポーネントなど）
14. © 2024 KDDI 13 日本OpenStackユーザ会 第47回勉強会 ◼ オープンソースである事 ⚫ カスタマイズ性が高い • 自分たちのニーズに合わせて機能の追加 • ソースコードへの改造だけではなく製品や構成の組み合わせなども 自由度が高い ⚫ インターネット上で情報が見つかる • とりあえずネットで調べれば何かしら情報が出てくる心理的安全性 • 問題発生時も最悪ソースコードを見れば解決できる ⚫ コミュニティが活発 (他とは比較して・・・) なぜOpenStackを選んでいるか
15. © 2024 KDDI 14 日本OpenStackユーザ会 第47回勉強会 ⚫ KDDIではビジネス的な判断でコアな機能については製品版OSSを選択 どのOpenStackを選択したか OSS-Upstream版 OSS製品版：(e.g. Red Hat) プロプライエタリ製品 構成・使い方 組み合わせや使い方自由 ある程度組合せや使い方が自由 ある程度パターンを制限 パターンを制限 サポート コミュニティサポート、 セルフサポート ベンダーサポート ベンダーサポート 修正反映 Upstreamで実施、 フォークして自ら実施 ベンダーで実施 （原則Upstreamファースト） ベンダーで実施 お値段 - 💸💸 💸💸💸 ※お値段については雰囲気での比較です。見積もりを取って比較しましょう！ 品質の要件 キャリアグレード、総務省報告対象 体制面の制限 OSS開発できるようなソフトウェアエンジニアを多く抱えていない NEPとの相互接続性 5G-Coreを提供するようなNEPベンダが動作をサポートしている ⚫ OpenStackを利用する上での選択肢
16. © 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を使っているか
17. © 2024 KDDI 16 日本OpenStackユーザ会 第47回勉強会 OpenStackの全体構成 バックボーン ネットワーク グローバルリージョン 認証機能 ダッシュボード DNSaaS 東日本リージョン2 認証機能 仮想サーバ 仮想ネットワーク 仮想ボリューム その他‥ 東日本リージョン1 認証機能 仮想サーバ 仮想ネットワーク 仮想ボリューム その他‥ 西日本リージョン1 西日本リージョン2 ◼ 各リージョンごとにOpenStackクラスタをデプロイ ⚫ 全体を連携して利用できるようにグローバルリージョンを設定し 認証機能やDNSaaSなどといった機能やダッシュボードを提供
18. © 2024 KDDI 17 日本OpenStackユーザ会 第47回勉強会 利用しているOpenStackのコンポーネント 通常リージョン Storage Cinder backend/ Swift 互換Object グローバルリージョン デプロイ用 デプロイ用 LBaaS VNFM DNSaaS 主にOpenStackのメジャーなサービスのみをデプロイ CinderのバックエンドやSwift互換のオブジェクトストレージはCephで提供
19. © 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 ※絵の記載の数量はイメージであり、実際の数量とは異なります
20. © 2024 KDDI 19 日本OpenStackユーザ会 第47回勉強会 技術的な新たなチャレンジの紹介
21. © 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
22. © 2024 KDDI 21 日本OpenStackユーザ会 第47回勉強会 認証基盤のマルチリージョン連携(2/2) 解決方法 ▸ 各OpenStackを独立したOpenStackクラスタとしてデプロイ・管理 ▸ 各OpenStackのKeystoneはAPIのトークン発行用の鍵情報を共有 ▸ 「ユーザやプロジェクトのUUID」を同一の値で作ることで同じ鍵を使っての認証が可能 ▸ このためユーザは単一Keystoneに問い合わせるだけでトークン発行、APIカタログ入手ができる ようになるため各リージョンの存在を意識する必要がなくなる トークンの検証 トークンの発行 トークンください（認証情報） トークン発行：AAA 一覧ください(トークン付き) 一覧をどうぞ ユーザ情報を知らなくていい 扱わなくていい ユーザA ユーザB Keystone (中央サイト) Novaとか (ローカルサイト) 🔑 🔒 🔒 🔒 Keystone (ローカルサイト) 🔑
23. © 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を 自動で広報
24. © 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による仮想ルータと同じ使用感でより 高機能・ハイスペックな仮想ルータを利用できる
25. © 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
26. © 2024 KDDI 25 日本OpenStackユーザ会 第47回勉強会 IPv6化（2/2） いろいろな苦労はあるものの…、 OpenStackはIPv6だけでもちゃんと動きます ◼ DHCPv6およびそれに付随する技術でトラブルは主に発生 ⚫ デフォルトゲートウェイの扱いが特にハマりやすし ⚫ PXE/iPXE ⚫ BGP＋RA JANOG 53 詳しくはJANOG53の資料で
27. © 2024 KDDI 26 日本OpenStackユーザ会 第47回勉強会 OpenStackやっていく上でのむつかしさなど
28. © 2024 KDDI 27 日本OpenStackユーザ会 第47回勉強会 スキルが必要（楽しいけど） OpenStack含めたオープンソース活用で求められる力 ▸ 専門性 OSS、仮想化など幅広い領域への理解 ▸ 課題解決力 無数にある解法の選択 ▸ 変化への追従 技術トレンドおよび技術背景への理解 インフラ技術のオープン化は避けられない道…外部に頼れる技術者はそ う多くはないため、自らスキルを獲得していく必要がある
29. © 2024 KDDI 28 日本OpenStackユーザ会 第47回勉強会 ◼ OpenStack(オープンソースソフトウェア)としてはできることでも、 製品版のプロダクト(ダウンストリーム)ではサポートできることは限られる ◼ さらに製品版でサポートできるが、製品の持つ標準インストールツールから それらが完全に適用できるわけではない 製品版OSSでの苦労点 ▸ またOSSでできないことは製品版ではできない(=D) ▸ 製品版はOSSに機能が実装されてから実装される ▸ Upstream firstという考え方 ▸ OSSのダウンストリームとアップストリームの間には、 どうしてもタイムラグも発生する（テストや安定化のため） C=OpenStackでできること B=製品ベンダでサポートできること A=製品で デプロイできること D=OpenStackでできないこと 製品版を使う上においても Upstreamをきちんと把握し、何ができてできないか、 必要に応じて機能実装の依頼をしていく必要がある（そうしないとずっと機能が入らない）
30. © 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 やサポートで禍根を残す
31. © 2024 KDDI 30 日本OpenStackユーザ会 第47回勉強会 ◼ OSS製品が対応する方法に常に従うこと ⚫ 自己流のカスタマイズをすると予期せぬ設定ファイルの書き換えなどが起こる 製品版OSSでの苦労点 インストーラ インストーラも OSSソフトウェア ①インストーラが Config生成 ②手動で編集 初期インストール しばらくたって… インストーラ Upgradeするなど ②手動で編集したファイル が先祖返りする 設定ファイルの変更等も インストーラを経由すべし
32. © 2024 KDDI 31 日本OpenStackユーザ会 第47回勉強会 ◼ ラージスケールでのデプロイに時間がかかる ⚫ 標準的な構成でかつ台数が少ない場合はすぐ終わる処理も・・・ ⚫ 諸々の細かなパラメータの取り込みのために複雑化すると・・・ ◼ 複雑な自動化が組み込まれており独自に改変することがむつかしい 製品版OSSでの苦労点+ラージスケール インストーラ インストーラ 30分 10時間 数十台 数百台
33. © 2024 KDDI 32 日本OpenStackユーザ会 第47回勉強会 テナントサポート 課題① OpenStackは使うだけでもむつかしい。 適切に利用したりOpenStackの機能を理解して設計することも大変 課題② QAなどが多くプライベートクラウド提供者側に負荷が集中する Articles Docs テナント 提供者 QA • 知らない！ • わからない！ • 教えて！ • 質問が多い！ • 大量のテナント • 人的リソース不足 • 改善活動に手が回らない • OpenStackに関する 知識や経験が不足 • 適切な利用・設計ができない ドキュメンテーションの拡充や頻出問い合わせや依頼に対する自動化対応などなど
34. © 2024 KDDI 33 日本OpenStackユーザ会 第47回勉強会 まとめ
35. © 2024 KDDI 34 日本OpenStackユーザ会 第47回勉強会 ◼ KDDIではRed Hat製品を利用しながらも、SIや周辺機能の開発を内製化してます ◼ 通信分野における独特のチューニングや冗長化設計などは醍醐味の一つ ⚫ 検閲により削除されました ◼ 相応の技術力も求められるますがOpenStackはOSSなこともあり内部まで 見れることでトラブル解決や修正対応も早くできる（ことが多い） ◼ 皆さんでOpenStack使って盛り上げましょう！！ 内製化していろいろやってます！ 興味ある人がいればお声がけください！ もう少し詳しい構成を 聞いてみたい どんな仕事か 聞いてみたい Cephってどうですか‥？ 内製化ってどうですか？