$30 off During Our Annual Pro Sale. View Details »

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

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

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

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

Takashi Kajinami

May 26, 2024
Tweet

More Decks by Takashi Kajinami

Other Decks in Technology

Transcript

  1. 自己紹介 梶波 崇 (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
  2. VMネットワークの要件 • VMの間でネットワーク疎通が可能であること • 同一のハイパーバイザ上のVM • 異なるハイパーバイザ上のVM • 疎通可能な範囲が制御できること •

    異なる仮想ネットワークに繋がるVMの間では通信ができないこと • 外部のサービスと接続できること • VMの初期設定に必要な情報が提供できること 5
  3. 異なるハイパーバイザ上の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
  4. 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のオーバーヘッドが発生する
  5. VMの初期設定 • VMは起動時にDHCPによってIP・ルート情報等を取得して ネットワークを設定 • ネットワーク設定完了後、メタデータサーバにアクセスし、初 期設定のための情報を取得する • ホスト名 •

    SSH公開鍵 • 初期設定スクリプト 等 • VM内での初期設定には一般的にcloud-init等のエージェ ントを利用する 10 VM DHCPサーバ メタデータサーバ IP・ルート情報等取得 cloud-init dhcpクライアント 設定適用 VM設定情報取得 スクリプト ssh公開鍵
  6. 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 ルータ ルータ 前回資料の再掲
  7. 外部サーバ 外部サーバ 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
  8. 外部サーバ 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
  9. ホストネットワーク 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宛通信をルータのインタフェースに 送るルールを挿入
  10. ホストネットワーク 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サーバのインタ フェースに送るルールを挿入
  11. 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
  12. 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 サーバ
  13. 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
  14. セキュリティグループ • 仮想マシンの通信を制御する機能 • ポート単位のファイアウォール • 複数のプロパティを指定してルールを決定する • 通信方向(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
  15. 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
  16. 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 パススルー パススルー
  17. 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
  18. ネットワーク 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 ・・・ 最大帯域を制限する ことで帯域をフェアに 配分する
  19. 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
  20. 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, …)
  21. 次回以降のネタ • 別テーマのアーキテクチャ概要 • ストレージ、コンピュート、・・・ • アーキテクチャ深堀 • VM作成、Live Migrationなどの処理フローを追ってみる、など

    • 特定コンポーネント・プラグイン深堀 • ml2 ovnは第46回勉強会のテーマだったのでその他 • インストールツール情報 • コミュニティではOpenStack Ansibleとかkolla-ansibleあたりがメジャーな様子 • NFV入門 • OpenStackにあるNFV向け機能を見てみる • アップストリーム入門 • ハンズオン or 相談会 or もくもく会 • 人材育成・チーム育成 • コミュニティの立ち上げ、ノウハウ蓄積・共有、勉強方法(ドキュメント等?) • ユースケース共有 ご要望(と発表者)お待ちしています 31