Transcript フロー処理やネットワーク機能の処理負荷を考慮した

フロー処理やネットワーク機能の処理負荷を
考慮したVSEリソース割当ての最適化
〇村松 真† 川島 龍太† 齋藤 彰一† 松尾 啓志†
中山 裕貴†† 林 經正††
† 名古屋工業大学大学院
†† 株式会社ボスコテクノロジーズ
2015/04/22
CQ研究会
研究背景
• クラウドコンピューティングサービスの普及
 データセンタの需要が増加
› 膨大な数の物理サーバとストレージを管理
• マルチテナント方式を採用
 物理サーバ上に様々なテナントの仮想マシン(VM)を集約
› 各テナントに独立した仮想環境を提供
› 物理サーバの台数を削減
 オーバレイプロトコルによる仮想ネットワークの構築
› 既存のデータセンタネットワーク上で構築可能
1
マルチテナント方式の構成
User A
Virtual
Router
User B
VM
Tunneling Header
Packet Format
Decapsulate
Virtual
Switch
Physical Server
User A
User B
User A
User B
VM
VM
VM
VM
仮想ネットワークの性能向上が重要
Virtual
Switch
Physical Server
Virtual
Switch
Encapsulate
Traditional
Datacenter Network
Physical Server
2
仮想ネットワーク性能向上のアプローチ
• トンネリングプロトコルの改善
• ハードウェアスイッチ
 CPU負荷の低減、通信の高速化
特定のハードウェア機能が必要となり
ベンダロックインに陥る可能性がある
• ホスト内処理の受信処理負荷に着目
特定のハードウェア機能を利用せず
ホスト内受信処理のCPUリソース割当て方法の最適化
3
シングルキューNICにおける問題点
• 特定のCPUコアに受信処理負荷が集中
VM1
vhost
net1
vhost
net2
VM2
VM3
Core
#5
Core
#6
vhost
net3
vSwitch
Tunnel
Protocol
SoftIRQ
Driver
Core
#1
Core
#2
Core
#3
Core
#4
HardIRQ
CPU
Single Queue NIC
4
Receive Side Scaling (RSS)
VM1
vhost
net1
vhost
net2
vSwitch
vSwitch
vSwitch
Tunnel
Tunnel
Tunnel
Protocol
Protocol
Protocol
Driver
Driver
Driver
Core
#1
Core
#2
Core
#3
VM2
VM3
Core
#5
Core
#6
vhost
net3
Core
#4
CPU
Q1
Q2
Q3
Q4
Q5
Q6
IP address/Port
hashing
Hash Function
RSS-NIC
5
Receive Side Scaling (RSS)
VM2
VM1
vhost
net2
vhost
net1
VM3
仮想ルータ
vhost
net3
vSwitch
仮想ネットワーク全体
の性能に影響を与える
Tunnel
Protocol
Driver
Core
#1
Core
#2
Core
#3
Core
#4
Core
#5
Core
#6
CPU
Q1
Q2
Q3
Q4
Q5
Q6
IP address/Port
hashing
Hash Function
RSS-NIC
6
提案手法：Virtual Switch Extension (VSE)†
VM1
vhost
net1
vhost
net2
VM2
VM3
vhost
net3
Flow Table
Match
Actions
vSwitch
vSwitch
vSwitch
VM1 flow
SoftIRQ : 1-
Tunnel
Tunnel
Tunnel
VM2 flow
SoftIRQ : 2-
Protocol
Protocol
Protocol
VM3 flow
SoftIRQ : 3-
...
...
VSE
Driver
Core
#1
Core
#2
Core
#3
Core
#4
.
.
.
Core
#5
Core
#6
CPU
† “VSE: Virtual Switch Extension for Adaptive CPU Core Assignment in Softirq” 2014 IEEE 6th International Conference on
Cloud Computing Technology and Science (CloudCom), Shin Muramatsu et al.
7
提案手法：Virtual Switch Extension (VSE)†
VM1
vhost
net1
vhost
net2
VM2
VM3
vhost
net3
Flow Table
Match
Actions
vSwitch
vSwitch
VM1 flow
SoftIRQ : 1
Tunnel
Tunnel
VM2 flow
SoftIRQ : 1
Protocol
Protocol
VM3 flow
SoftIRQ : 2
...
...
VSE
Driver
Core
#1
Core
#2
Core
#3
Core
#4
.
.
.
Core
#5
Core
#6
CPU
† “VSE: Virtual Switch Extension for Adaptive CPU Core Assignment in Softirq” 2014 IEEE 6th International Conference on
Cloud Computing Technology and Science (CloudCom), Shin Muramatsu et al.
8
従来評価との相違点
従来評価
• フロー処理負荷が非常に高い
環境における評価のみ
 VXLAN over IPsec
本研究
• フロー処理負荷が比較的低負荷
な環境における評価
 VXLAN
• 低負荷なフロー処理における評価項目
 VSE処理オーバヘッド
 フロー/VMのCPUコア衝突
より一般的なケースでの通信性能への影響を評価
9
VSEにおける処理
ソフト割り込み先変更
フローテーブルのルックアップ処理
ハードウェア割込先CPUコアと
別のCPUコアへソフトウェア割込
線型検索によるエントリ検索
Flow Table
VSE
Driver
Driver
Core
#1
Core
#2
Core
#3
Core
#4
Match
Actions
VM1 flow
SoftIRQ : -
VM2 flow
SoftIRQ : -
VM3 flow
SoftIRQ : -
...
...
Core
#5
Core
#6
CPU
10
評価環境
• ネットワーク環境
Physical Server
OpenvSwitch
VSE
40 Gb Ethernet
Port 1 Port 2
Optixia†
Ethernet
Generating
• UDP Flow
• 74 bytes
• 10 seconds
Packet Flow
in_port=1,
actions=output:2
• マシン仕様
Physical Server
OS
CentOS 6.6 (2.6.32)
CPU
Intel Core i7 (6 core)
Memory
16G bytes
Buffer
4M bytes
Network
40GBASE-SR4
Driver
MellanoxConnect-X(R)-3
vSwitch
OpenvSwitch 2.3.0
† Optixia XM2 “http://www.ixiacom.jp/sites/default/files/content/support/library/datasheets/ja_optixiaxm2.pdf”
11
評価結果：ソフトウェア割り込み先変更の影響
VSE
Driver
Core
#1
Core
#2
Default
35
パイプライン化
Driver
Core
#1
Core
#2
VSE
ソフトウェア割り込み先変更による
影響は無視可能
30
Packet Loss [%]
25
20
15
10
5
0
1000
1100
1200
1300
1400
1500
1600
1700
Transmission Rate [Kpps]
1800
1900
2000
12
評価結果：エントリ数の影響
• 送信レートを1700Kppsに固定
 マッチするエントリを末尾に設定
VM数は物理CPUコア数と同じ30～50台程度
100
90
設定可能なエントリ数は50程度でも問題ない
80
Packet Loss [%]
70
60
50
40
30
20
10
0
50
100
150
200
The Number of Entries
250
300
13
従来評価との相違点
従来評価
• フロー処理負荷が非常に高い
環境における評価のみ
 VXLAN over IPsec
本研究
• フロー処理負荷が比較的低負荷
な環境における評価
 VXLAN
• 低負荷なフロー処理における評価項目
 VSE処理オーバヘッド
 フロー/VMのCPUコア衝突
物理CPUコア数に対してVM数とフロー数の合計が大きい
優先フローのためにどの処理を
別のCPUコア上で行うべきか検討
14
CPUリソース割当てモデル
VM
VM
vhostnet
vhostnet
Packet
Prc.
Packet
Prc.
Driver
Core
#1
Driver
Core
#2
Core
#3
Core
#4
Core
#1
Model A
Core
#2
Core
#3
Model B
VM
VM
vhostnet
vhostnet
Packet
Prc.
Packet
Prc.
Driver
Core
#1
Core
#4
Driver
Core
#2
Core
#3
Model C
Core
#4
Core
#1
Core
#2
Core
#3
Model D
Core
#4
15
評価環境
• ネットワーク環境
VM
• 65535 bytes
• 100s
VM
Iperf
client
Virtual
Switch
Virtual
Switch
VXLAN
Physical Server 1
• マシン仕様
Iperf
server
TCP communication
40 Gb Ethernet
Physical Server 1
Physical Server 2
Physical Server 2
VM
OS
CentOS 6.6 (2.6.32)
Ubuntu 14.04
CPU
Intel Core i7 (6 core)
1 core
Memory
16G bytes
2G bytes
Buffer
4M bytes
4M bytes
Network
40GBASE-SR4
-
Driver
MellanoxConnect-X(R)-3
virtio (MTU:1450)
vSwitch
OpenvSwitch 2.3.0
-
16
8000
1.0
7000
0.9
Context Switch [Normalized]
Throughput [Mbps]
評価結果
6000
5000
4000
3000
2000
1000
0
Model A
Model B
Model C
Model D
Packet
Prc.
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0.0
Model A
Model B
コンテキストスイッチ
が最小限に抑えられる
VM
vhostnet
0.8
Model C
Model D
VM
キューにパケットを
溜め込む
コンテキストスイッチが
頻発
Packet
vhostnet
Prc.
Driver
Driver
優先フローに対してモデルC及びDを適用することが望ましい
Core
#1
Core
#2
Core
#3
Model B
Core
#4
Core
#1
Core
#2
Core
#3
Model C
Core
#4
17
優先フローの性能評価
• 評価環境
VM1
VM3
VM5
VM7
Iperf
client
Iperf
client
Iperf
client
Iperf
client
TCP communication
Virtual
Switch
VM2
VM4
VM6
VM8
Iperf
server
Iperf
server
Iperf
server
Iperf
server
Virtual
Switch
VXLAN
Physical Server 1
40 Gb Ethernet
Physical Server 2
• ベンチマーク：Iperf
Protocol
TCP (Tunnel : VXLAN)
Packet Size
65535 bytes
Flow Duration Time
30 s
Flow Generation Time
15 times
Flow Generation Rules
Common for all patterns
18
優先フローの性能評価
• 評価パターン
RSS
VSE (SoftIRQ)
VM2
VM4
vhost
net2
Core
#1
VM6
vhost
net4
Core
#2
Core
#3
VM8
vhost
net6
Core
#4
Core
#5
VM2
vhost
net8
Core
#6
VM4
vhost
net2
Core
#1
vhost
net4
Core
#2
HardIRQ
VM6
Core
#3
HardIRQ
VM8
vhost
net6
Core
#4
vhost
net8
Core
#5
SoftIRQ
2, 4, 6
VSE (Model C)
VM2
vhost
net2
Core
#1
VM4
vhost
net4
Core
#2
HardIRQ
SoftIRQ
8
Model C
VM6
VM8
vhost
net6
Core
#3
SoftIRQ
2, 4, 6
Core
#6
vhost
net8
Core
#4
Core
#5
SoftIRQ
8
Core
#6
19
評価結果
RSS
VM2
8000
VM4
VM6
VSE (SoftIRQ)
VM8
8000
VM4
VM6
VM8
Throughput [Mbps]
7000
6000
5000
4000
3000
2000
6000
5000
4000
3000
OSのスケジューリングにより
コンテキストスイッチ発生
2000
1000
フロー/VM衝突
1000
0
0
30
60
90 120 150 180 210 240 270 300 330 360 390 420 450
30
60
90 120 150 180 210 240 270 300 330 360 390 420 450
time [s]
time [s]
VSE (Model C)
VMとの衝突により低下
8000
Throughput [Mbps]
Total Ave.
VM2
VM4
VM6
VM8
7000
VM8 Ave.
Throughput [Mbps]
Throughput [Mbps]
7000
VM2
6000
5000
RSS
11934
4873フロー処理が集中するコア５へ
VSE (SoftIRQ)
13515
VMがスケジューリングされなかった
6027
モデルCを適用したことにより
VSE (Model C)
13181
6055
4000
3000
安定
2000
フロー処理負荷が低い場合においてもモデルを適用することにより
1000
常に高スループットかつ安定した通信性能を提供することが可能
0
30
60
90 120 150 180 210 240 270 300 330 360 390 420 450
time [s]
20
まとめと今後の課題
• まとめ
 VSE処理オーバヘッドによる通信性能への影響を評価
› VSE処理オーバヘッドは無視可能
› VSEに設定可能なエントリ数は10～50
 CPUリソース割当てモデルを提案
› フロー処理負荷が低負荷である場合においてもVSEは優先フロー
に対しモデルを適用することで通信性能が向上かつ安定
• 今後の課題
 各パケット処理における詳細なサービス時間の評価
 送信処理を考慮した場合のモデルの検討
21