OpenStack再入門「ネットワーク編」

日本OpenStackユーザ会 第48回勉強会 発表資料です。

https://openstack-jp.connpass.com/event/317644/

Transcript

1. OpenStack再入門 ネットワーク編 2024/05/24 日本OpenStackユーザ会 第48回勉強会 1
2. 自己紹介 梶波 崇 (Takashi KAJINAMI) kajinamit kajinamit irc: tkajinam@OFTC Distinguished Cloud Engineer @ NTTデータグループ • クラウド基盤に関連した技術の研究開発を担当 • 現在のテーマはConfidential Computing OpenStackを中心にOSSコミュニティにて活動 • Heat(Orchestrationサービス) PTL • Oslo(共通ライブラリ) Release Liaison • Puppet OpenStack(OpenStack構築用のPuppetマニフェスト) PTL • Storlets(オブジェクトストレージ内でのアプリ実行エンジン) PTL PTL = Project Team Lead 2
3. Agenda • VMネットワークの基本 • OpenStackのネットワーク • より高度なネットワーク機能 3
4. VMネットワークの基本 4
5. VMネットワークの要件 • VMの間でネットワーク疎通が可能であること • 同一のハイパーバイザ上のVM • 異なるハイパーバイザ上のVM • 疎通可能な範囲が制御できること • 異なる仮想ネットワークに繋がるVMの間では通信ができないこと • 外部のサービスと接続できること • VMの初期設定に必要な情報が提供できること 5
6. ハイパーバイザ ブリッジ 同一のハイパーバイザ上のVM間の通信 • 仮想マシンはハイパーバイザ上のブリッジ(=仮想スイッチ)に接続し、ブリッジを経由して通信する • ブリッジでVLANを割り当てることで疎通可能なVMを制御する 6 VM VM VM VM Tag: 10 Tag: 20
7. 異なるハイパーバイザ上のVM間の通信 7 ハイパーバイザ ブリッジ VM VM ハイパーバイザ ブリッジ VM VM ハイパーバイザ ブリッジ VM VM ハイパーバイザ ブリッジ VM VM ハイパーバイザ ブリッジ VM VM ハイパーバイザ ブリッジ VM VM (1) Flat (物理) メリット • 構成が単純で通信のオーバーヘッドが小さい • VMと外部との直接通信が実装しやすい デメリット • 通信分離にはインタフェースが複数必要 (2) VLAN メリット • 通信のオーバーヘッドが比較的小さい • VMと外部との直接通信が実装しやすい デメリット • 4096を超えるネットワークは収容できない (3) オーバーレイ (vxlan, geneve) メリット • 多数のネットワークを収容できる デメリット • 通信のオーバーヘッドが大きい • 外部との直接通信は(原則)不可能 Tag: 100 Tag: 101
8. 参考: 通信のオーバーヘッド • VLAＮネットワーク・オーバーレイネットワークではVMからの通信パケットにカプセル化のための情報が追加される • 追加されるデータが長くなると、一般に処理オーバーヘッドが大きくなると考えられる • 特にオーバーレイネットワークはIPヘッダ・UDPヘッダが追加されるので追加データが大きい • 一方で収容可能数は追加データが長くなるにつれて多くなる 8 *1: IPv6の場合はIPヘッダサイズが20byteではなく40byteになり+20byteされる *2: 32bitのType Length Valueによって拡張可能 方式 オーバーヘッド 収容可能数 Flat 0 byte 1 VLAN 4 byte 4,096 (12bit) VXLAN 50*1 byte 16,777,216 (24bit) Geneve 58*1 byte 16,777,216 (24bit) 以上*2
9. VMと外部との通信 9 ハイパーバイザ ブリッジ VM VM 外部サーバ 10.1.0.101/16 ハイパーバイザ ブリッジ VM VM 10.1.0.102/16 10.1.0.201/16 ハイパーバイザ ブリッジ VM VM 外部サーバ 192.168.1.11/24 ハイパーバイザ ブリッジ VM VM 192.168.2.11/24 10.1.0.201/16 10.1.0.11/24 10.1.0.12/24 (1) 直接接続 メリット: • 構成が単純で通信のオーバーヘッドが小さい デメリット: • VMごとに物理ネットワークのIPを消費する (2) NAT(SNAT/DNAT) メリット: • SNATにより複数VMで物理ネットワークIPを共有できる デメリット: • 構成が複雑になりNATのオーバーヘッドが発生する
10. VMの初期設定 • VMは起動時にDHCPによってIP・ルート情報等を取得して ネットワークを設定 • ネットワーク設定完了後、メタデータサーバにアクセスし、初 期設定のための情報を取得する • ホスト名 • SSH公開鍵 • 初期設定スクリプト 等 • VM内での初期設定には一般的にcloud-init等のエージェ ントを利用する 10 VM DHCPサーバ メタデータサーバ IP・ルート情報等取得 cloud-init dhcpクライアント 設定適用 VM設定情報取得 スクリプト ssh公開鍵
11. OpenStackのネットワーク 11
12. VMネットワークの提供方法 • VMネットワークを提供する方法は大きく分けて2つある • Provider Network • 予め管理者が特定のVLAN or flatネットワークを作成しておく • VM作成時には作成済みのに接続する • 外部システムには直接接続する (スイッチでVLAN等を通しておく) VMを外部システムなどと直接通信させたい場合 • Self-service Network • 利用者が任意にネットワークを作成し、VMを接続する • tenant networkはvxlan等によって分離されクラスタ内に閉じる • 外部システムとの接続は仮想ルータを経由する(SNAT/DNAT) VMと外部との接続を制限したい場合 12 VM VM ←外部へ VM VM VM VM ←外部へ VM VM ルータ ルータ 前回資料の再掲
13. Provider Networkのアーキテクチャ • VMはクラスタの外まで延伸されたVLANネットワークあ るいはフラットネットワークに接続 • クラスタ外のネットワーク構成を把握・管理している管理者によっ てあらかじめネットワークを作成しておく • 外部とはVMが接続するサブネット内で直接通信する • 予め管理者がスイッチ・経路の設定を行っておく前提 13 Compute ブリッジ VM Compute ブリッジ VM VM 192.168.0.11/24 192.168.0.12/24 192.168.1.11/24 外部サーバ 外部サーバ 192.168.0.101/24 192.168.1.101/24
14. 外部サーバ 外部サーバ Self-Service Networkのアーキテクチャ • VMはクラスタ内に閉じたオーバーレイネットワークに接 続する • クラスタに閉じたネットワークであるのでユーザが自由に作成可能 • オーバーレイネットワーク以外にVLANネットワークも利用可能 • VMから外部や他サブネットへの通信はルーターによって SNATされる • OpenStack外部ではルータの外部インタフェースのIPが送信元 となる • 外部からVMへの通信はFloating IPを利用しルータ でDNATする • ルータの外部インタフェースにルータ自身のIPに加えてFloating IPが設定される • Floating IPあての通信はFloating IPの割り当て設定に基づ き仮想マシンの実IP宛の通信に変換(DNAT)される 14 Compute ブリッジ VM Network Compute ブリッジ VM ブリッジ VM 192.168.0.1/24 192.168.0.11/24 192.168.0.12/24 10.1.0.11/8 192.168.1.1/24 10.1.0.31/8 192.168.1.11/24 10.2.0.11/8 10.2.0.12/8
15. 外部サーバ L3通信を効率化するための機能 15 Compute VM Network (1) DVR (Distributed Virtual Rouer) • ML2-OVSプラグインの機能(OVNでは標準) • 仮想サブネット間の変換をComputeノードで行う • 後述するDistributed Floating IPの機能も備える (2) Distributed Floating IP • ML2-OVNプラグインの機能 • Floating IPが割り当てられたVMのDNAT/SNAT通 信をComputeノードにて直接行う Compute VM Compute VM Network Compute VM Compute VM Network Compute VM 外部サーバ Compute VM Network Compute VM
16. ホストネットワーク VMネットワーク VM起動後のIP・メタデータ取得 • VMが起動するとまずDHCPによりIPを取得 • IPの取得後、VMからメタデータIPに対してメタデータ 取得をリクエスト • 特殊IP( 169.254.169.264 あるいは fd00:ec2::254) を宛先とするHTTPリクエストを利用する • 特殊IP宛の通信は、DHCPにより提示されるルーティ ング情報によってルータあてに送信される • 以降リクエストはプロキシ用のプロセスにバックエンドで 転送され、最終的にNovaのメタデータAPIから情報 を取得した情報が返却される • リクエスト転送時にID情報を付与してVMを特定できるように する 16 VM DHCPサーバ IP・ルート情報等を要求 IP・ルート情報等を返却 ルータ メタデータIP(169.254.169.254等)宛 にHTTリクエストを送信 neutron-metadata-proxy neutron-metadata-agent リクエストを転送 リクエストを転送 nova-metadata-api リクエストを転送 メタデータ情報を返却 ルータ毎に起動する。 実体はhaproxy 送信元のルータIDを付与 送信元のIP、インスタンスIDや テナントID等を付与 メタデータIP宛通信をルータのインタフェースに 送るルールを挿入
17. ホストネットワーク VMネットワーク VM起動後のIP・メタデータ取得(ルータ無し) • ルータが接続されていない閉鎖ネットワークでは、 metadata-proxyはDHCPサーバ配下に起動する • dhcp-agentの enable_isolated_metadata オプション の設定が必要 • メタデータIP宛のリクエストはDHCPサーバのIPに転 送され、ルータ配下の場合と同様にmetadata- proxyを経由してNovaのメタデータAPIまで転送さ れていく 17 VM DHCPサーバ IP・ルート情報等を要求 IP・ルート情報等を返却 メタデータIP(169.254.169.254等)宛 にHTTリクエストを送信 neutron-metadata-proxy neutron-metadata-agent リクエストを転送 リクエストを転送 nova-metadata-api リクエストを転送 メタデータ情報を返却 DHCPサーバ毎に起動する。 実体はhaproxy 送信元のルータIDを付与 送信元のIP、インスタンスIDや テナントID等を付与 メタデータIP宛通信をDHCPサーバのインタ フェースに送るルールを挿入
18. DHCPサーバ・ルータの実装方法 (ML2-OVS) 18 (1) DHCPサーバ • DHCP機能はdnsmasqを利用 • ネットワークごとにNetwork Namespaceを作成 • Network Namespace内でdnsmasqを動作させる ことでネットワークー分離を実現 • metadata-proxyも同一Namespace内で動作 (2) ルータ • ルータ(SNAT/DNAT)はiptablesで実装 • ルータごとにNetwork Namespaceを実装 • NATルールをNamespace内で定義することで複数の ルータを共存可能にする • metadata-proxyも同一Namespace内で動作 Network dnsmasq dnsmasq q-dhcp namespace q-dhcp namespace Network q-router namespace iptables
19. ML2-OVSプラグインのアーキテクチャ • APIの提供やノードを跨いだ管理(スケジューリング等)はneutron- serverにより行われる • ネットワークに関する情報はDBに保存される • 各プロセスはメッセージキューを経由して通信する • 各サーバでopenvswitch-agentが動作しブリッジやポートを管理 • Networkノードではl3-agent、dhcp-agentが稼働しルータや DHCP、その配下で稼働するmetadata-proxyを管理。 • metadata-agentはl3-agentやdhcp-agentと同一のノードで 稼働し、メタデータ取得機能を提供 19 Compute ブリッジ VM Network Compute ブリッジ VM ブリッジ Controller neutron-server openvswitch-agent openvswitch-agent l3-agent dhcp-agent metadata-agent DHCP サーバ
20. ML2-OVNプラグインのアーキテクチャ • APIの提供やノードを跨いだ管理(スケジューリング等)はneutron- serverにより行われる • ネットワークに関する情報はDBおよびOVN DBに記録される • DBの情報を正としてOVN DBに情報が投入される • OVN DBはNorthbound DB(NBDB)とSouthbound DB(SBDB) により構成される。論理ネットワーク情報をNBDBに格納すると、ovn- northdが論理データパスフローに変換してSBDBに格納する • 各プロセスはOVN DBを経由して通信する • 各サーバでovn-controllerが動作しブリッジやポートに加え、DHCP サーバやルータを管理 • DHCPサーバやルータはOVSのフローで実装 • 専用のovn-metadata-agentを利用し、metadata- proxyの起動やNovaのメタデータAPIへの転送を行う 20 Compute ブリッジ VM Network Compute ブリッジ VM ブリッジ Controller neutron-server NB DB SB DB ovn-controller ovn-controller ovn-northd ovn-metadata-agent
21. セキュリティグループ • 仮想マシンの通信を制御する機能 • ポート単位のファイアウォール • 複数のプロパティを指定してルールを決定する • 通信方向(ingress/egress) • プロトコル(tcp、udp、icmp等) • 通信相手のIP 等 • デフォルトはegressのみ全許可 • 独自のセキュリティグループの作成や、テナントのデフォルトセ キュリティグループのカスタマイズができる • ovsブリッジ内のフローあるいはiptablesにより実装 • iptablesはML-OVSのiptables_hybrid firewall driver が利用する 21 VM $ openstack security group rule list ssh +----+-------------+-----------+-----------+------------+-----------+-----+ | ID | IP Protocol | Ethertype | IP Range | Port Range | Direction | ... | +----+-------------+-----------+-----------+------------+-----------+-----+ | .. | None | IPv6 | ::/0 | | egress | ... | | .. | tcp | IPv4 | 0.0.0.0/0 | 22:22 | ingress | ... | | .. | None | IPv4 | 0.0.0.0/0 | | egress | ... | | .. | icmp | IPv4 | 0.0.0.0/0 | | ingress | ... | +----+-------------+-----------+-----------+------------+-----------+-----+ egress ingress icmp ssh http dns
22. IP/MACアドレスのSpoofing対策 • 仮想マシンがIPアドレスやMACアドレスを詐称すると仮想ネッ トワークの動作が阻害される恐れがある • Neutronにはポートセキュリティ機能があり、ポートに登録され たIPアドレス・MACアドレスに関する通信のみを許可する • 異なるIP・MACアドレスの利用を許可することもできる • Port securityの無効化 (ネットワーク単位・ポート単位) • Allowed address pairの登録 VM内でVIP等を利用する際はこの設定が必要 22 VM MAC: fa:16:3e:bb:f8:fe IP: 192.158.10.11 のポートに対応するインタフェース ブリッジ MAC: fa:16:3e:bb:f8:fe IP: 192.158.10.11 MAC: fa:16:3e:bb:f8:fe IP: 192.158.10.12 MAC: fa:16:3e:bb:f8:fd IP: 192.158.10.11
23. より高度なネットワーク機能 23
24. SR-IOV (Single-Root Input/Output Virtualization) • SR-IOVはPCIeの拡張機能で、物理デバイスを複数の仮想マシンで共有する機能 • OpenStackでは主にネットワーク高速処理のための物理NICの共有に利用される 24 ハイパーバイザ ブリッジ VM VM ハイパーバイザ VM VM ハイパーバイザ 物理NIC(PF) VM VM (1) ブリッジ経由の接続 メリット: • 多数のVMが接続可能 • セキュリティグループに対応 デメリット: • ホストKernelがオーバーヘッドになる (2) NICのパススルー メリット: • ホストKernelのオーバーヘッドがない デメリット: • VMの数だけNICが必要 • セキュリティグループ非対応 (3) SR-IOVの利用 メリット: • ホストKernelのオーバーヘッドがない • 物理NICを複数VMで共有できる デメリット: • 対応NICが限られる • セキュリティグループ非対応 物理NIC 物理NIC 物理NIC VF VF パススルー パススルー
25. OVS-DPDK • DPDK(Data Plane Development Kit)を利用した高速パケット処理を行うOVSの機能 • ホストOSのKernelを経由せず、OVSがNICとVMの間でのパケットの処理・受け渡しを行う 25 Host User Space Host Kernel ドライバ NIC OVS Guest User Space Guest Kernel ドライバ Host User Space Host Kernel NIC OVS Guest User Space Guest Kernel ドライバ PMD OVS(通常) OVSーDPDK
26. NUMAを意識したリソース配置 • 複数CPUを搭載するサーバではメモリやデバイスへのアクセス速度が不均一になる • NUMAノード内のアクセスは速く、NUMAを跨いだアクセスは遅い • 高速なパケット処理を求める場合は、NIC・メモリ・CPUが同一のNUMAノードに収まるように配置する必要がある 26 NUMA 0 NUMA 1 CPU Memory Memory controller I/O Controller NIC CPU I/O Controller NIC Memory Memory controller NIC NIC 速い 遅い
27. ネットワーク QoS (Quality of Service) 27 (1) 最大帯域・パケットレート制限 • 最大の帯域幅あるいはパケットレートを制限する • SDNやSR-IOVに搭載された制限機能を使う • 特定のVMによる帯域等の食いつぶしを防ぐ (2) 最小帯域保証 • 帯域要件に応じてVMを物理インタフェースに割り当て • Placementを利用したVM配置計算を使う • 最大帯域制限と組み合わせてVM・インタフェースごとに最低限の 物理帯域を確保する 参考: https://docs.openstack.org/neutron/latest/admin/config-qos.html Compute ブリッジ VM 10Gbps VM VM VM ≧3Gbps ≧ 3Gbps ≧ 2Gbps VM ≧ 2Gbps ≧ 3Gbps Compute ブリッジ VM VM ・・・ 特定のVMが帯域を 食いつぶし他のVMが 帯域確保できない Compute ブリッジ VM VM ・・・ 最大帯域を制限する ことで帯域をフェアに 配分する
28. Octavia • Load Balancerを提供するサービス • haproxyが動作するインスタンス(Amphora)を起動する • ListenerやMember等の追加・削除に合わせてhaproxyの設定を 更新してリロードする • 複数インスタンスによるActive Standby構成もサポート • Amphoraからハートビートを受信し、反応がない場合は フェイルオーバー(再作成)を実行 • Amphora上のagentとController上のプロセスの通信は 特殊なVMネットワーク(Management network)で行う 28 Compute Amphora VM Controller octavia-api octavia-worker octavia-health-manager amphora-agent ha-proxy VM Amphoraを作成 更新を通知 監視・フェール オーバー 設定更新 management network Client
29. Designate • DNSを提供するサービス • DNSサーバ(BINDやPowerDNS)にレコード等を投入 • designate-workerプロセスがDNSサーバと連携 • designate-mdnsによってDNS NOTIFYを送りまたAXFRリクエスト に応答 • クライアントはDNSサーバに接続しクエリを行う • Neutronと連携してレコードを自動で更新 • Floating IPやインスタンスのポートIPに対応するレコードを投入 • Neutronでのdnsエクステンションの有効化と、ネットワークでの dns_domainの設定が必要 29 Controller designate-api designate-central designate-producer designate-worker designate-mdns DNSサーバ (BIND, PowerDNS, …)
30. Q&A 30
31. 次回以降のネタ • 別テーマのアーキテクチャ概要 • ストレージ、コンピュート、・・・ • アーキテクチャ深堀 • VM作成、Live Migrationなどの処理フローを追ってみる、など • 特定コンポーネント・プラグイン深堀 • ml2 ovnは第46回勉強会のテーマだったのでその他 • インストールツール情報 • コミュニティではOpenStack Ansibleとかkolla-ansibleあたりがメジャーな様子 • NFV入門 • OpenStackにあるNFV向け機能を見てみる • アップストリーム入門 • ハンズオン or 相談会 or もくもく会 • 人材育成・チーム育成 • コミュニティの立ち上げ、ノウハウ蓄積・共有、勉強方法(ドキュメント等?) • ユースケース共有 ご要望(と発表者)お待ちしています 31