イベント名：ITpro EXPO 2010 講師：日本仮想化技術 宮原 日時：2010/10/18 アジェンダ： • 仮想化アップデート – 最近の仮想化動向は? • 仮想化環境の構成設計 – CPUやメモリ、ストレージなどの選定は? – KVMのベンチマーク結果紹介 • 仮想化環境における運用管理 – 仮想化環境での運用管理の課題 概要： 評価段階から本格的な導入段階へと入り始めた仮想化技術。コモディティ化に伴い、無償のハイパーバイザーの活用も視野に入ってきました。製品・技術の進化、ノウハウの蓄積により、性能や信頼性も確保しやすくなっています。 仮想化導入の実践テクニックを、数多くの案件を手掛けた経験から解説します。

1. 1
ここで差がつく「仮想化導入」
性能、信頼性、コストの最新トレンド
日本仮想化技術株式会社
代表取締役社長兼CEO 宮原 徹
miyahara@VirtualTech.jp
日本仮想化技術株式会社 概要
• 社名：日本仮想化技術株式会社
– 英語名：VirtualTech Japan Inc.
– 略称：日本仮想化技術／VTJ
• 設立：2006年12月
• 資本金：14,250,000円
• 本社：東京都渋谷区渋谷1-1-10
• 取締役：宮原 徹（代表取締役社長兼CEO）
• 伊藤 宏通（取締役CTO）
• スタッフ：8名（うち、5.5名が仮想化技術専門エンジニアです）
• URL：http://VirtualTech.jp/
• 仮想化技術に関する研究および開発
– 仮想化技術に関する各種調査
– 仮想化技術に関連したソフトウェアの開発
– 仮想化技術を導入したシステムの構築
2
ベンダーニュートラルな
独立系仮想化技術の
エキスパート集団

2. 2
導入
仮想化環境構築をトータルサポート
設計
• 設計
– サーバ、ストレージからネットワークまでアプリ
ケーションまで考慮した設計
– キャパシティプランニング（ベンチマーク）
• 導入
– 仮想化ソリューションパッケージの提供
– 仮想化統合（P2Vレガシーマイグレーション）
• 運用保守
– エンジニア教育
– 技術サポートの提供
– Xen/KVMソースコードレベルサポート
運用保守
3
ベンダーニュートラルなワンストップ・サポートをご提供
本日のアジェンダ
• 仮想化アップデート
– 最近の仮想化動向は？
• 仮想化環境の構成設計
– CPUやメモリ、ストレージなどの選定は？
– KVMのベンチマーク結果紹介
• 仮想化環境における運用管理
– 仮想化環境での運用管理の課題
4

3. 3
仮想化アップデート
5
最近のハイパーバイザーの状況
• VMware vSphere 4.1に
– VMotionがStandardでも利用可能に
• Citrix XenServerが5.6に
– 管理ツールXenCenterが使いやすくなった
• KVMはじわじわっと
– 採用を検討するユーザーが増えてきた
• Hyper-V 2.0 SP1が見えてきた
– Dynamic Memoryによるメモリオーバーコミット
メントのサポート
6

4. 4
最近の仮想化導入の傾向
• ハイパーバイザーの低コスト化
– 小規模であれば無償版でも可能
– 既存導入ユーザーの更なるコスト削減要請
• 規模の拡大
– ホスト数、VM数共に拡大傾向
– リソース不足や運用管理が課題に
• クラウドサービスとの棲み分けは？
– 現在のCSPの顧客はソーシャルアプリ系中心
7
仮想化環境の構成設計
8

5. 5
仮想化環境のための構成設計
• マルチコア化したCPUに合わせた最適化
• サーバ単体性能よりもサーバ台数で冗長
化
– 無停止運用、HA構成を実現
• ネットワークは役割別に設計
• ストレージはコスト、容量、速度、耐障害性
のバランスを
– バックアップリカバリも考慮して
9
CPU利用状況の最適化
• 仮想CPUの割当数だけ物理CPUをロック
– ロックされている間、他の仮想マシンは物理CPU
を使用できない
– 物理CPU割り当ては時分割で強制的なので、仮
想CPUがIdleでもロックは発生する
• ロックを回避し、スループットを向上
– 仮想CPU割当数を減らす
– 物理CPU数を増やす（2コア→4コア→6コア→12コ
ア） → 後ほどベンチマークにて解説
• NUMA構成の特性に注意
10

6. 6
CPUの仮想化
11
OS OS
OS OS
OS OS
OS OS
仮想CPU割当を減らす
物理CPU数を増やす
VM1がCPUリソースを専有
VM切替でVM2がCPUリソース確保
or
VM1
VM2
VM1
VM2
NUMA構成と仮想化
• 大きく速い仮想マシンを作るときの注意点
– その仮想マシンのCPUはどこにありますか？
– その仮想マシンのメモリはどこにありますか？
• SMP構成とNUMA構成は異なる
12
CPU
CPU
メモリ
CPU
CPU
メモリ
メモリ
SMP構成
NUMA構成

7. 7
• メモリアクセス速度の低下による性能劣化
– 別のプロセッサに接続されたメモリへのアクセ
スは大幅に遅延する
– 仮想CPUが別々のプロセッサに割り当てられ
るとメモリアクセスが大幅に速度低下
NUMA構成の注意点
13
CPU
CPU
メモリ
メモリ
同一NUMAノードなので高速
CPU
CPU
メモリ
メモリ
NUMAノードが別なので性能劣化
無停止や耐障害性設計
• HA構成による耐障害性の向上
– 基本的な設計はこのレベル
– 物理サーバーは3台1組構成を基本に
• ライブマイグレーションで無停止システム
– ハードウェアのシャットダウンを伴うメンテナン
スもシステムを無停止で実施可能
• ストレージの冗長化も
– データバックアップをしっかりと行う
14

8. 8
障害に強いシステムの実現
• Server Aに障害は発
生した場合
1. Server Aに障害発生
2. VM1をServer Bで再
起動（システムは共有
ストレージ上に）
3. Server A復旧後、
VM1をServer Aに復
帰
15
VM1
VM2
Server A
Server B
VM1
VM2
Server A
Server B
VM1
Server A
Server B
VM2
ライブ
マイグレーション
1.
2.
3.
数分程度
無停止運用の実現
• Server Aをハードウェ
ア的に停止してメンテ
ナンスしたい場合
1. VM1をServer Bにライ
ブマイグレーション（シ
ステムは無停止）
2. Server Aを停止し、メ
ンテナンス
3. VM1をServer Aに復
帰
16
VM1
VM2
Server A
Server B
ライブ
マイグレーション
VM1
VM2
Server A
Server B
VM1
Server A
Server B
停止メンテナンス
VM2
ライブ
マイグレーション
1.
2.
3.

9. 9
ネットワーク構成例
17
仮想マシンホスト
仮想マシンホスト
ストレージ
ストレージ用
管理用
ライブマイグレーション用
管理端末
クライアントネットワーク
少なくとも4系統は
考える必要がある
10GbE・FCoE・CNA
• 10G Ethernet標準搭載サーバーの増加
• 今後、iSCSIやFCoEのHBAを兼ねたCNA
搭載製品が標準に
– CNA：Converged Network Adaptor
18
Brocade社製品
QLogic社製品

10. 10
参考）KVM+Netperfによる
10GbEネットワーク性能検証
検証環境
• 仮想ホスト: HP DL360 G7
– オンボードNIC：NC382i 1Gb Ethernet
– 増設NIC：Intel X520 10Gb Ethernet
• ロードジェネレータ: HP DL380 G6
– Intel Xeon X5520 (2.6GHz×4物理CPUコア)
– 24GBメモリ（DDR3 Registered ECC）
– オンボードNIC：NC382i 1Gb Ethernet
– 増設NIC：Intel X520 10Gb Ethernet
• 2台のマシンはケーブルで直結

11. 11
検証環境構築および検証内容
• 検証環境構築
– Fedora 13(64ビット版)を導入し、Linux KVMによ
る仮想化環境を構築
• カーネルはkernel-2.6.33.6-147.fc13.x86_64
– 仮想マシンのゲストOSにFedora 13を導入
– 10Gb Ethernet用のチューニングを実施（後述）
• Netperfベンチマーク
– Netperf 2.4.5を導入
– ロードジェネレータから仮想マシンに対する通信
速度を5回計測し、2 4回目の平均値を採用
21
netperf –H IPアドレス -l 30 !
結果一覧表（HT Off）
vCPU数
送信
受信
1Gb Ethernet
10Gb Ethernet
4仮想CPU
1VM
物理(DL380 G6)
940
6302
物理(DL380 G6)
1VM
938
8648
物理(DL380 G6)
2VM
941
9837
物理(DL380 G6)
3VM
942
9873
物理(DL380 G6)
6VM
942
9880
物理(DL380 G6)
9VM
942
9886
2仮想CPU
物理(DL380 G6)
1VM
939
6886
1仮想CPU
物理(DL380 G6)
1VM
939
8901
物理
物理(DL360 G7)
物理(DL380 G6)
941
9890
物理(DL380 G6)
物理(DL360 G7)
941
9895
遅い

12. 12
結果一覧表（HT On）
vCPU数
送信
受信
1Gb Ethernet
10Gb Ethernet
4仮想CPU
1VM
物理(DL380 G6)
923
6388
物理(DL380 G6)
1VM
939
6652
物理(DL380 G6)
2VM
941
9827
物理(DL380 G6)
3VM
941
9868
物理(DL380 G6)
6VM
942
9889
物理(DL380 G6)
9VM
943
9887
2仮想CPU
物理(DL380 G6)
1VM
(省略)
(省略)
1仮想CPU
物理(DL380 G6)
1VM
(省略)
(省略)
物理
物理(DL360 G7)
物理(DL380 G6)
941
9899
物理(DL380 G6)
物理(DL360 G7)
941
9895
遅い
Netperf 結果グラフ

13. 13
参考）10Gb Ethernetの
パフォーマンスチューニング
パフォーマンスチューニング概要
• デフォルトの状態では10Gb Ethernetの性
能は十分に引き出せない
– 3 5Gbps程度に留まる
• 次のパラメータ・設定を変更することで、パ
フォーマンスが改善された
– MTUの変更
– カーネルパラメータの調整
– NICの設定変更

14. 14
MTUの変更
• デフォルトの1500から9000に変更
• /etc/sysconfig/network-scripts/ifcfg-ethXに
「MTU=9000」を記述
カーネルパラメータの調整
1. sysctlコマンドで設定
2. /etc/grub.conf のkernel行に設定追加
# sysctl -w net.ipv4.tcp_window_scaling=1!
# sysctl -w net.ipv4.tcp_rmem="4096 873800 1747600"!
# sysctl -w net.ipv4.tcp_wmem="4096 873800 1747600"!
# sysctl -w net.ipv4.tcp_mem="2048000 2048000 2048000"!
# sysctl -w net.core.rmem_default=873800!
# sysctl -w net.core.wmem_default=873800!
# sysctl -w net.core.rmem_max=1747600!
# sysctl -w net.core.wmem_max=1747600!
# sysctl -w net.core.optmem_max=20480
intel_iommu=off

15. 15
NICに対する設定
• ethtoolコマンドで設定
– ethtoolパッケージをインストール
• GRO：Generic Receive Offload
• LRO：Large Receive Offload
• これらのパラメータのOn/Offはチップ種別
等、ケースバイケースで実施
# ethtool -A ethX autoneg off rx off tx off!
# ethtool -K ethX gro off!
# ethtool -K ethX lro off!
※HWRSCが有効の場合、このパラメータを指定しても無視される
仮想化環境における
ストレージの重要性
30

16. 16
ストレージ選定
容量
耐障害性
速度
31
ストレージ選定時の考慮点
• 容量
– 今後の増加率の予測も合わせて行う
– 無停止増設可能か
• 速度
– 使用アプリケーションの読み書き特性を考慮
– SSDの活用、階層化ストレージ
• 耐障害性
– 単一障害点の排除
– バックアップリカバリも含めて検討
• ローカルストレージの活用
– 共有の必要がなければ、ローカルの方が高速の場合も
– システムとデータの分離
32

17. 17
ストレージで考慮すべき機能
• バックアップリカバリー
– スナップショットとのバックアップ連動
– リモートバックアップとDR
• ストレージ統合
– 複数ストレージの論理集約
– 統合管理
– 冗長性排除
– 階層化
33
構成設計 まとめ
• 元々のサーバーの利用率や性能が低け
れば、性能設計は緩めでも良い
• 集約率と耐障害性は反比例するので、バ
ランスを考えて
• ボトルネックはI/O、特にストレージ
– HDD台数追加やSSDの利用を考慮
– 今後は10GbEによるネットワーク構成も
34

18. 18
仮想化環境における運用管理
35
仮想化運用管理の基本
• 可能な限り既存の運用管理手法を踏襲
– 仮想化だからといって特別なことは無い
– 仮想化することでマシン層とOS層の間に
標準化の線引きが行える
– 仮想化レイヤーの監視が増える
36
←サービス監視
←OS監視
←仮想化監視
←ハードウェア監視

19. 19
仮想化環境における性能監視
• 死活監視だけでなく性能監視も重要
– ボトルネックの早期発見・早期対応
• リソース利用量の60%ルールの徹底
– リソース総容量に対する水準線を決めておく
– リソース利用量が水準線を越えたらリソース
追加を検討
• リソースの逐次強化
– リソース量を順次増やしていくビジネスプロセ
ス（稟議書→決済）への変革が必要
37
仮想マシン管理の注意点
• 仮想マシンの構成変更が容易
– メモリ量などすぐに変えられてしまう
– リソース使用量の急激な変動に繋がる
• 仮想マシンの追加が容易
– リソース使用量の急激な増加に繋がる
– 当初想定していた以上のリソース不足
38
構成・変更管理とリソース容量調整が重要

20. 20
仮想化以外の管理
• システムやミドルウェアの構成管理
– 仮想マシン毎の分離度が高いため、個別のコ
ントロールは行いやすい
– 仮想マシンの数が多いと、構成・変更管理が
煩雑になる
• ストレージの管理
– スナップショットは便利だが、ストレージ性能が
低下するので注意
39
まとめ
• 仮想化すること自体が当たり前
– 「仮想化できるかどうか」ではなく「仮想化するが、
ここは仮想化しない方がいい」という発想
• スモールスタートでOK
– 拡張性が仮想化の最大のメリット
• 性能要求には慎重に対応
– 事前のベンチマークが重要
• 運用管理もセットで考える
– 仮想化だから特別というわけではないが、いくつ
かのポイントには注意
40

21. 21
お問い合わせ先
「仮想化環境を構築したいが、どこに相談すればいいの？」
まずは我々にご相談ください
http://VirtualTech.jp/
sales@VirtualTech.jp
050-7571-0584
41