研究背景 クラウドコンピューティングサービスの普及 ユーザ数の増加に伴う問題 マルチテナント方式の採用 データセンタの需要が増加

Presentation on theme: "研究背景 クラウドコンピューティングサービスの普及 ユーザ数の増加に伴う問題 マルチテナント方式の採用 データセンタの需要が増加"— Presentation transcript:

0 優先度を考慮した仮想スイッチにおける トンネル処理の負荷分散手法の検討
○村松 真† 川島 龍太† 齋藤 彰一† 松尾 啓志† †名古屋工業大学 名古屋工業大学大学院 創成シミュレーション工学専攻 2014/07/18 NV研究会

1 研究背景 クラウドコンピューティングサービスの普及 ユーザ数の増加に伴う問題 マルチテナント方式の採用 データセンタの需要が増加
膨大な数の物理サーバとストレージを管理 ユーザ数の増加に伴う問題 物理サーバの台数が増加 マルチテナント方式の採用 物理サーバ上に複数の仮想サーバを集約し仮想環境を提供 物理サーバの台数を削減 オーバレイプロトコルによる仮想ネットワークの構築 既存のデータセンタのネットワークが利用可能

2 エッジ・オーバレイ方式への移行が進められている
マルチテナント方式の構成 仮想ネットワークを識別 Controller Tunnel Header VM packet OpenFlow Channel OpenFlow Channel User1 User2 VM VM VM VM Security QoS etc Virtual Switch Virtual Switch Tunneling エッジ・オーバレイ方式への移行が進められている Network Driver Network Driver Traditional Datacenter Network

3 (IP Defragment/Decrypto)
エッジ・オーバレイ方式における問題点 ソフトウェアで高度なパケット処理 受信側ホストの仮想スイッチの処理が特定のコアに集中 仮想スイッチのパケット処理の負荷が大 (IP Defragment/Decrypto) softirq Hardware IRQ Driver kernel core1 NIC queue Packet Processing core2 core3 VM core4 VM パケット処理の負荷が大きい場合に 受信処理を行うコアを分散する機構が必要

4 Receive Side Scaling(RSS)†
Driver kernel core1 RSS Q1 Packet Processing core2 Q2 Packet Processing core3 Q3 Pakcet Processing VM core4 性能低下 Q4 VM hash function indirection table queue number hash function ETH IP TCP/UDP Payload indirection table フローを識別してパケット処理を行うコアを 選択する必要がある 入力できるフィールドはIP、TCP/UDPのみ queue number †“Receive-side scaling enhancements in windows server 2008” Nov Internet Draft.

5 予備評価：パケット処理の負荷が高いフロー衝突
トンネリングプロトコル VXLAN + AES暗号化（高負荷の例） ベンチマーク Iperf(UDP) パケットサイズが大きくなるにつれて 負荷が大きくなり処理しきれずに破棄 VMが必要とするCPUリソースが奪われ VMのパケット処理が低下 衝突時にスループットが低下

6 従来モデルにおける問題点 機械的にフローの割り込み先コアを決定 スループットの低下につながる フローの割り込み先コアが衝突
仮想スイッチのパケット処理が特定のコアに集中 VMが動作しているコアに割り込む 負荷が高いコアなど スループットの低下につながる

7 提案手法：概要 パケット処理を行うCPUコアを適応的に決定 VS-extendでフローのsoftirq先を制御
コントローラが分散処理の対象となるフローを設定 指定したフローを負荷の低いコアで処理 優先度を付加し、物理ホストの負荷が高い場合においても 優先フローの性能を向上 ソフトウェアベースで実装 ベンダロックインを回避

8 提案手法：全体像 VS-extend VS-extend Flow Table Core Table Traditional
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 Virtual Switch Match Actions OpenFlow 1.0, VM_ID IRQ ... Network Driver VS-extend Network Driver VS-extend Core Table Core number Status core1 load, VM_ID ... CPU cores Hardware assists Traditional Datacenter Network

9 提案手法：Virtual Switch(VS)-extend
Controller カプセル化されていても VMのフローを識別可能 softirq先コア Flow Table Match Actions vm_nw_src= IRQ:core1 vm_nw_src= IRQ:--- .... Match Actions vm_nw_src= IRQ:core1 vm_nw_src= IRQ:--- .... Match Actions vm_nw_src= IRQ:core1 vm_nw_src= IRQ:core2 .... Match Actions vm_nw_src= IRQ:core1 vm_nw_src= .... Match Actions .... 低負荷なコアへ変更 CPUコアの負荷 VMの実行コア Core Table Core Number Status core1 load=20 core2 load=100 core3 load=5, VM_ID=1 core4 load=5, VM_ID=2 Core Number Status core1 load=50 core2 load=0 core3 load=5, VM_ID=1 core4 load=5, VM_ID=2 Core Number Status core1 load=50 core2 load=0 core3 load=5, VM_ID=1 core4 load=5, VM_ID=2 Virtual Switch Network Driver VS-extend 高負荷　 CPU負荷及びVMの実行コアに応じて パケット処理を分散 vm_nw_src=

10 提案手法：Flow Tableにおけるエントリマッチ
通常フロー OpenFlow 1.0に基づいたエントリマッチ ETH ETH IP IP TCP/UDP TCP/UDP Payload トンネルフロー カプセル化されているパケットヘッダでエントリマッチ ETH IP Tunnel Tunnel VM ETH VM ETH VM IP VM IP VM TCP/UDP VM TCP/UDP Payload 内部にVMのパケットヘッダが存在することがわかる

11 VMのパケットヘッダでフローを識別できない
カプセル化における問題点 VMのパケットヘッダでマッチエントリが行えない VM MTU ETH Tunnel (+IPsec) IP VM ETH VM IP IN IP VM TCP/UDP Payload PM MTU IPsec ETH Tunnel (+IPsec) IP VM ETH VM IP VM TCP/UDP Payload VMのパケットヘッダでフローを識別できない 新たにフローを識別する識別子が必要

12 VM IDを参照することで同一コアで処理が可能
提案手法：特定フローの識別方法 IPヘッダのToSフィールドのセマンティクスを変更 version, hdr_len tot_len ToS IP address ID etc Priority (1bit) VM ID (7bits) 優先フロー 宛先VMのフロー IN IP ETH Tunnel (+IPsec) IP VM ETH VM IP IN IP VM TCP/UDP Payload VM IDでフローを識別 ETH Tunnel (+IPsec) IP VM ETH VM IP VM TCP/UDP Payload IP IP VM IDを参照することで同一コアで処理が可能

13 提案手法：Priorityを利用したフロー処理
優先したいテナントの性能低下を防ぐ 優先的に低負荷かつVMが動作していないコアを選択 負荷の低いコアへsoftirqを行う Priority flow 50%以上 Driver kernel core1 VS-extend Priority Flow1 RSS Q1 Packet Processing core2 Q2 Packet Processing core3 Q3 VM Flow2 core4 Q4 VM 優先フローのパフォーマンス低下を防ぐ

14 実装(1/2) Receive Packet Steering(RPS)の実装を活用 ハッシュ値で決定されたコアに対しsoftirqを行う
Driver core3 kernel core1 VS-extend RPS RSS Q1 core2 Q2 core3 Q3 Packet Processing VM VM core4 Q4 VM ハッシュ値を用いてフローのsoftirq先を決定 ドライバ内でフローのsoftirq先を制御 RSSと同様に フローとVMの衝突が発生

15 実装(2/2) 既存のLinuxカーネルの実装を変更する必要がない ハッシュ:100 Driver kernel core2
VS-extend RPS RSS Q1 core2 Q2 Packet Processing core3 Q3 VM core4 Q4 VM ドライバから操作することで フローのsoftirq先を制御可能 sock flow table sock flow tableに ハッシュ値とコア番号を格納 hash core 100 2 ... hash core ... 以降のパケットはハッシュ値を 書き換え同一コアにsoftirqを行う Flow Tableにsoftirq先とともに ハッシュ値も格納する 既存のLinuxカーネルの実装を変更する必要がない RPS処理中に参照される

16 評価 評価環境 マシン性能 core1 core2 Physical Server1 Physical Server2 VM OS
Iperf Server VM1 … 40 GEther network Physical Server2 Virtual Switch VXLAN + AES core2 VM2 Client Physical Server1 マシン性能 Physical Server1 Physical Server2 VM OS CentOS 6.5(2.6.32) ubuntu-server 12.04 CPU Core i7 (4core) Core i5 (4core) 1core Memory 16Gbytes 2Gbytes Buffer 4Mbytes Network 40GBASE-SR4 - Driver MellanoxConnetX(R)-3 virtio

17 受信側VMのスループット 評価モデル Iperfクライアントの設定 モデル 機能 ハードウェア割り込み先コア default
RSS/RPS無効 core4 rss RSS機能有効 core1~4 proposal 提案手法(+RSS) 静的に設定 Match Actions VM ID=1 IRQ:3, rxhash:1000 VM ID=2 IRQ:4, rxhash:2000 Iperfクライアントの設定 プロトコル UDP パケットサイズ 64，1400，8192bytes フロー持続時間 1分 フロー生成回数 20回 フロー生成規則 全モデル共通

18 受信側VMのスループット：評価結果 欠落率を大幅に削減 致命的な欠落率 Flow Tableを適切に設定することで
packet loss VM1 VM2 default 51% 52% rss 95% 43% proposal 14% フラグメントパケットもsoftirq先を同一コアに選択 フラグメントパケットの割り込み フローの割り込み先が衝突 割り込み先コアおよびVMとの衝突 欠落率を大幅に削減 致命的な欠落率 パケット処理を分散 Flow Tableを適切に設定することで 負荷を分散しスループットが向上 エッジ・オーバレイ方式のネットワークにおいて有効

19 優先フローのスループット 評価モデル Iperfクライアントの設定 モデル 機能 ハードウェア割り込み先コア rss RSS機能有効
core0 Iperf Server VM1 … 40 GEther network Physical Server2 Virtual Switch VXLAN + AES core1 VM2 Client Physical Server1 モデル 機能 ハードウェア割り込み先コア rss RSS機能有効 core1~3 proposal 提案手法(+RSS) 優先フロー 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回 フロー生成規則 全モデル共通

20 優先フローのスループット：評価結果 CPU負荷が高い物理ホストにおいて 優先フローの性能を向上させる場合に有用

21 まとめと今後の課題 まとめ 今後の課題 ソフトウェア的なアプローチによって仮想スイッチの負荷を分散する手法を提案
VS-extendのFlow Tableが適切に設定されている場合に、 スループットが向上 優先度を設定した場合に、優先フローのスループットが他のフローより向上 今後の課題 コントローラと仮想スイッチ間のプロトコルの実装 CPU負荷に応じた動的なFlow Tableの設定 VS-extendをドライバ外に実装