優先度を考慮した仮想スイッチにおける トンネル処理の負荷分散手法の検討 ○村松 真† 川島 龍太† 齋藤 彰一† 松尾 啓志† †名古屋工業大学 名古屋工業大学大学院 創成シミュレーション工学専攻 2014/07/18 NV研究会 研究背景 クラウドコンピューティングサービスの普及 データセンタの需要が増加 膨大な数の物理サーバとストレージを管理 ユーザ数の増加に伴う問題 物理サーバの台数が増加 マルチテナント方式の採用 物理サーバ上に複数の仮想サーバを集約し仮想環境を提供 物理サーバの台数を削減 オーバレイプロトコルによる仮想ネットワークの構築 既存のデータセンタのネットワークが利用可能 1 マルチテナント方式の構成 仮想ネットワークを識別 Tunnel Header VM packet User1 User2 VM VM User1 VM Security QoS etc User2 VM Security QoS etc Virtual Switch Tunneling Virtual Switch エッジ・オーバレイ方式への移行が進められている Network Driver Tunneling Network Driver Traditional Datacenter Network 2 エッジ・オーバレイ方式における問題点 ソフトウェアで高度なパケット処理 受信側ホストの仮想スイッチの処理が特定のコアに集中 softirq Hardware IRQ Driver 仮想スイッチのパケット処理の負荷が大 (IP Defragment/Decrypto) kernel core1 Packet Processing core2 NIC queue core3 VM core4 VM パケット処理の負荷が大きい場合に 受信処理を行うコアを分散する機構が必要 3 Receive Side Scaling(RSS)† Driver kernel core1 Q1 Packet Processing core2 Q2 Packet Processing Q3 RSS core3 Pakcet Processing Q4 性能低下 VM core4 VM hash function ETH IP TCP/UDP Payload indirection table queue number 入力できるフィールドはIP、 TCP/UDPのみ †“Receive-side scaling enhancements in windows server 2008” Nov. 2008. Internet Draft. 4 予備評価：パケット処理の負荷が高いフロー衝突 トンネリングプロトコル VXLAN + AES暗号化（高負荷の例） ベンチマーク 2-flows 1800 non-collision Iperf(UDP) collision 1000 flow-VM collision 900 1600 800 Throughput(Mbps) 1400 Throughput(Mbps) non-collision 1200 1000 800 600 400 700 600 500 400 300 200 200 100 0 0 64 1400 packet size(bytes) 8192 パケットサイズが大きくなるにつれて 負荷が大きくなり処理しきれずに破棄 64 1400 packet size(bytes) 8192 VMが必要とするCPUリソースが奪われ VMのパケット処理が低下 5 従来モデルにおける問題点 機械的にフローの割り込み先コアを決定 フローの割り込み先コアが衝突 仮想スイッチのパケット処理が特定のコアに集中 VMが動作しているコアに割り込む 負荷が高いコアなど スループットの低下につながる 6 提案手法：概要 パケット処理を行うCPUコアを適応的に決定 VS-extendでフローのsoftirq先を制御 コントローラが分散処理の対象となるフローを設定 指定したフローを負荷の低いコアで処理 優先度を付加し、物理ホストの負荷が高い場合においても 優先フローの性能を向上 ソフトウェアベースで実装 ベンダロックインを回避 7 提案手法：全体像 Controller • Host info(CPU cores, HW assists) • Port info(Tennant, VM ID, Pinning) Tenant, VM ID , Running core VM VM VM VM Flow Table Virtual Switch VS-extend Match Actions OpenFlow 1.0, VM_ID IRQ ... ... Network Driver CPU cores Hardware assists Virtual Switch VS-extend Network Driver Core Table Core number Status core1 load, VM_ID ... ... Traditional Datacenter Network 8 提案手法：Virtual Switch(VS)-extend Controller カプセル化されていても VMのフローを識別可能 Flow Table Match Virtual Switch VS-extend softirq先コア Actions .... vm_nw_src=192.168.0.100 .... IRQ:core1 .... vm_nw_src=192.168.0.200 .... IRQ:--IRQ:core2 IRQ:core1 .... .... 低負荷なコアへ変更 CPUコアの負荷 Core Table Core Number VMの実行コア Status core1 load=50 load=20 core2 load=0 load=100 core3 高負荷 core4 load=5, VM_ID=1 load=5, VM_ID=2 Network Driver CPU負荷及びVMの実行コアに応じて パケット処理を分散 vm_nw_src=192.168.0.200 9 提案手法：Flow Tableにおけるエントリマッチ 通常フロー OpenFlow 1.0に基づいたエントリマッチ ETH IP TCP/UDP Payload トンネルフロー カプセル化されているパケットヘッダでエントリマッチ ETH IP Tunnel VM ETH VM IP VM TCP/UDP Payload 内部にVMのパケットヘッダが存在することがわかる 10 カプセル化における問題点 VMのパケットヘッダでマッチエントリが行えない VM MTU ETH IP Tunnel VM ETH (+IPsec) VM IP INVM IP TCP/UDP Payload PM MTU IPsec ETH IP Tunnel VM ETH (+IPsec) VM IP VMのパケットヘッダでフローを識別できない VM TCP/UDP Payload ETH IP 新たにフローを識別する識別子が必要 11 提案手法：特定フローの識別方法 IPヘッダのToSフィールドのセマンティクスを変更 version, 優先フロー hdr_len tot_len Priority (1bit) ETH IP Tunnel VM ETH (+IPsec) IP address 宛先VMのフロー ToS ID etc VM ID (7bits) VM IP INVM IP TCP/UDP Payload VM IDでフローを識別 ETH IP Tunnel VM ETH (+IPsec) VM IP VM TCP/UDP VM IDを参照することで同一コアで処理が可能 Payload ETH IP 12 提案手法：Priorityを利用したフロー処理 優先したいテナントの性能低下を防ぐ 優先的に低負荷かつVMが動作していないコアを選択 負荷の低いコアへ softirqを行う Priority flow Driver kernel 50%以上 core1 Q1 Priority Flow1 Packet Processing core2 Q3 VS-extend Q2 RSS Flow2 Packet Processing core3 VM core4 Q4 VM 優先フローのパフォーマンス低下を防ぐ 13 実装(1/2) Receive Packet Steering(RPS)の実装を活用 ハッシュ値で決定されたコアに対しsoftirqを行う Driver core3 kernel core1 Q1 Q3 RPS Q2 RSS VS-extend core2 core3 Packet Processing VM core4 Q4 ハッシュ値を用いてフローの softirq先を決定 VM RSSと同様に ドライバ内でフローのsoftirq先を制御 フローとVMの衝突が発生 14 実装(2/2) Driver ハッシュ:100 core2 kernel core1 Q1 core2 RPS Q3 VS-extend Q2 RSS Packet Processing core3 VM core4 Q4 VM ドライバから操作することで フローのsoftirq先を制御可能 sock flow table sock flow tableに 以降のパケットはハッシュ値を ハッシュ値とコア番号を格納 書き換え同一コアにsoftirqを行う hash core 100 ... ... 2 ... ... Flow Tableにsoftirq先とともに ハッシュ値も格納する RPS処理中に参照される 既存のLinuxカーネルの実装を変更する必要がない 15 評価 評価環境 … core1 core2 VM2 VM1 VM1 VM2 Iperf Client Iperf Client Iperf Server Iperf Server Virtual Switch VXLAN + AES … Virtual Switch 40 GEther network Physical Server1 Physical Server2 マシン性能 Physical Server1 OS CPU Physical Server2 CentOS 6.5(2.6.32) Core i7 (4core) Core i5 (4core) VM ubuntu-server 12.04 1core Memory 16Gbytes 2Gbytes Buffer 4Mbytes 4Mbytes Network 40GBASE-SR4 - Driver MellanoxConnetX(R)-3 virtio 16 受信側VMのスループット 評価モデル モデル 機能 ハードウェア割り込み先コア default RSS/RPS無効 core4 rss RSS機能有効 core1~4 proposal 提案手法(+RSS) core1~4 Match 静的に設定 Actions VM ID=1 IRQ:3, rxhash:1000 VM ID=2 IRQ:4, rxhash:2000 Iperfクライアントの設定 プロトコル UDP パケットサイズ 64，1400，8192bytes フロー持続時間 1分 フロー生成回数 20回 フロー生成規則 全モデル共通 17 受信側VMのスループット：評価結果 default 1 40 20 0.5 10 0 0 5 proposal proposal1600 1400bytes packet loss 1200 8192bytes 1500 1000 500 0 0 default core3 rss core4 proposal rss VM1 proposal VM2 51% 52% rss 95% 43% proposal 14% 14% 800 time(m) core2 1 default default 400 フラグメントパケットの割り込み 割り込み先コアおよび 0 VMとの衝突 10 15 20 0 0 core1 Total Throughput(Mbps) rss フラグメントパケットもsoftirq先を 同一コアに選択 30 2000 rss Total Throughput(Mbps) default 64bytes Ratio of softirq per CPU Throughput(Mbps) per CPU of softirq Ratio Total 50 rss フローの割り込み先が衝突 5 10 15 欠落率を大幅に削減 致命的な欠落率 time(m) 20 proposal rss パケット処理を分散 Flow Tableを適切に設定することで 0.5 負荷を分散しスループットが向上 エッジ・オーバレイ方式のネットワークにおいて有効 5 10 15 20 0 time(m) core1 core2 core3 core4 18 優先フローのスループット 評価モデル モデル 機能 ハードウェア割り込み先コア rss RSS機能有効 core1~3 proposal 提案手法(+RSS) core1~3 優先フロー Match Actions VM_ID=1(VM1) IRQ:4, rxhash=10000 VM_ID=2(VM2) IRQ:2, rxhash=20000 VM_ID=3(VM3) IRQ:3, rxhash=30000 Iperfクライアントの設定 プロトコル UDP パケットサイズ 64，1400，8192bytes フロー持続時間 1分 フロー生成回数 20回 フロー生成規則 全モデル共通 19 優先フローのスループット：評価結果 rss 64B proposal 20 15 10 5 0 Throughput(Mbps) rss 1400B proposal 600 400 200 0 vm1 1000 800 Throughput(Mbps) Throughput(Mbps) 25 vm2 vm3 rss 8192B vm1 vm2 vm3 proposal 800 600 400 CPU負荷が高い物理ホストにおいて 優先フローの性能を向上させる場合に有用 200 0 vm1 vm2 vm3 20 まとめと今後の課題 まとめ ソフトウェア的なアプローチによって仮想スイッチの負荷 を分散する手法を提案 VS-extendのFlow Tableが適切に設定されている場合に、 スループットが向上 優先度を設定した場合に、優先フローのスループットが他 のフローより向上 今後の課題 コントローラと仮想スイッチ間のプロトコルの実装 CPU負荷に応じた動的なFlow Tableの設定 VS-extendをドライバ外に実装 21
© Copyright 2024 ExpyDoc
