仮想化環境の設計手法～基礎編～

Size: px

Start display at page:

Download "仮想化環境の設計手法～基礎編～"

やすもりかやぬま
6 years ago
Views:

1 仮想化環境の設計手法基礎編日本仮想化技術株式会社代表取締役社長兼 CEO 宮原徹 h

2 本日のアジェンダ仮想化環境の設計手法ハードウェアの選定省電力サーバーの検討ストレージの選定ベンチマークによる性能検証 2

3 仮想化環境の設計手法

4 仮想化環境設計のポイント目的の明確化既存環境移行現状こちらの方が多い新規システム構築何を優先するのかコスト : 導入コストランニングコスト機能 : 運用管理可用性性能 : 実行速度処理容量 4

5 仮想化マイグレーションのプロセスマイグレーション先検討目的の明確化現状整理可否判断計画立案計画実行マイグレーション方法の検討 5

6 見える化された目標の例システム寿命 2 年延長ハードウェア台数を2 分の1に削減ラック本数 3 分の2に削減システムダウンタイム 5 分以内システム復旧時間 1 時間以内 6

7 設計フェーズ要求仕様を論理システムにマッピング論理設計システムを機能単位で捉える仮想化設計物理設計論理システムを仮想化にマッピングシステムを仮想マシン単位で捉える仮想システムを物理 H/Wにマッピングシステムのサイジングや冗長化など Point!! ギリギリまで物理的なことは考えない 7

8 仮想化物理マッピングシステムA システムB Phy Phy Phy Phy Phy Phy M M M M M M VM VM VM VM VM VM P2V 移行リソース要求 Resource Resource Pool Resource Pool Pool Resource Resource Pool Resource Pool Pool リソース提供 H/W H/W H/W 複数 H/W で Resource Pool を構成することで冗長性を確保要求リソースが限定的で冗長性が不要な場合には単独 H/WでRPを構成 8

9 仮想化物理マッピングの注意点 (1) リソースプールは N 台のH/Wで構成される最低 3 台で構成するのが冗長化の観点から望ましい冗長性を排除するのであれば 1 台での構成も可能同一 H/W 上に複数のリソースプールを作成することも可能最終的な物理設計を行うまで仮想マシンと物理マシンの紐付けは行わない仮想化環境にとって位置の透過性が重要仮想マシンはリソースプール内のどこかで動いていると考えるどのH/Wで動いているかは考慮しない障害発生時はリソースプール内で相互にカバーする 9

10 仮想化物理マッピングの注意点 (2) 仮想マシングループにリソースプールを紐づけるリソースプール= 仮想マシングループ複数マシンで構成したクラスタ内にリソーススプールを配置することで自然と冗長化されるリソースプール単位で仮想マシン群を管理本番用リソースプール : 最優先リソース潤沢開発用リソースプール : 後回しリソース限定 10

11 設計手順詳細 (1) 1. 移行対象サーバーのリストアップマシンスペックおよび使用率重要度および負荷率をABCランク分け移行不要サーバーは除外 2. 特記事項の確認冗長構成スタンバイ構成など 3. マシングループ毎に仕分けシステムを構成するWeb+DB+その他をグループ化 11

12 サーバーリストの例 12

13 設計手順詳細 (2) 4. グループ毎の要求リソース量を算出 CPU クロック数メモリ量ディスク容量ディスク I/O ネットワーク I/O などの積算値 5. ターゲット H/W によるリソースプールと比較リソースプールは最低 3 台の仮想マシンホストで構成 ( 冗長構成を考慮した場合 ) CPU クロック数メモリ量の積算値 60% 程度不足の場合はリソース追加を検討ストレージはパスの帯域幅やディスク本数などで性能値が左右されるので別途検討が必要 13

14 ハードウェアの選定

15 仮想化環境の性能要因ハードウェア CPU: コア数クロック速度仮想化支援技術メモリ : 容量速度 VM への割当量 I/O: 帯域デバイス速度仮想化支援技術ソフトウェア VMM 種別 : ホスト OS 型ハイパーバイザー型内部構造 : ドライバモデルスケジューラーその他 :OS アプリケーションデータ量 15

16 ハードウェアの選定ポイント CPU は仮想化しても性能が下がりにくいマルチコアは 4 コアが標準になりつつあるメモリ量が仮想マシン収容力を大幅に左右 32GB 64GB が当たり前に RVI TLBなど仮想化支援技術も標準に高速な I/O の装備が必須 FC または 10G Ethernett Intel VT-d/AMD IOMMU のサポート 16

17 60% ルールル正常稼働時 VM2 VM4 VM6 VM1 VM3 VM5 異常発生時 HA 移行 VM1 VM4 VM3 VM2 VM6 VM5 17

18 CPU 使用率の計算方法 CPU クロック数の世代間性能差に留意 CPU の性能指標であるクロック数は製品の世代によって性能が異なる実質的なクロック対性能は大きく変わっていないのでクロック数比で計算してもよい? CPU コア数 MHz 実質 MHz SPECint2000 MHz/SPECint2000 Xeon 3.0GHz( 推定 ) , Xeon 3.4GHz , Xeon 3.0GHz , Xeon 5110(1.6GHz) Xeon5160(3GHz) ,

19 CPU 使用率の計算例 CPU 使用率 30% の物理マシンをほぼ同性能同クロックの仮想マシンホストに移行 CPU 使用率 60% まで可能なので 2VMまで収容可能収容可能 VM 目安 =CPU コア数 2 むしろメモリ容量の制約の方が大きい 19

20 ブレード or ラックマウント? 仮想化環境を組むなら最低 3 台構成 RAID 5 の考え方と同じ ( 最低 HDD3 台 ) 60% ルールを基準に CPU メモリなどを選定 4 台以上ならブレード? 以後の増設計画にも左右されるブレードの弱点も克服されつつある HP BL495c ではメモリスロット 16 本最大 128GBメモリ搭載可能 10Gb Ethernet 標準 20

21 その他サーバ選定のポイント高クロックよりもコア数 CPU ロックが減少し仮想マシンの実行並列度が高まる全体の性能が向上低消費電力型を選択できるランニングコストの削減スタンバイサーバは不要バは不要物理的な区切りで考えず全体のリソース容量で考えること 60% ルールの徹底ルの徹底 21

22 CPU の仮想化 VM1 VM2 VM1 VM2 OS OS OS OS VM1 が CPU リソースを専有 VM 切替で VM2 が CPU リソース確保 OS OS OS OS or 仮想 CPU 割当を減らす 22 物理 CPU 数を増やす

23 ネットワーク構成例クライアントネットワーク少なくとも 4 系統は考える必要がある仮想マシンホスト仮想マシンホストライブマイグレーション用イグレ管理用ストレージ用管理端末 23 ストレージ

24 省電力型サーバーの検討

25 省電力型サーバー CPUが省電力型クロック数はやや抑えめメモリも省電力 FB-DIMM は消費電力が高かった今後は消費電力が低いDDR2/DDR3に移行ハードディスクを搭載しない USBメモリやSANからのブート低消費電力なSSDの利用発熱が少ないので冷却も楽になる 25

26 参考消費電力計算結果比較 BL460c BL460c G5 BL460c G6 CPU L5410 L5430 L GHz 2.33GHz 2.66GHz メモリ 32GB 32GB 48GB/32GB アイドル時消費電力 (W) /2464 比率 100% 85%(-15%) 82%(-18%)/70%(- 30%) 100% 稼働時消費電力 /3998 (W) 比率 100% 89%(-11%) 84%(-16%)/76%(- 24%) Intel Xeon 5500 番台で消費電力を 16% 18% 削減しつつメモリを1.5 倍搭載可能消費電力 / クロック /1.8 26

27 参考実機計測 BL460c:E5405(2.0GHz) 2P8C 低消費電力型ではないローエンドモデル BL460c G6:L5520(2.26GHz) 2P8C メモリ 12GB/SAS 36GB 15krpm SFFx2/FC 最大消費電力 BL460c BL460c G6 比率 224W 135W 60.3% 最小消費電 162W 79W 48.8% 8% 力最大 x16 台 3584W 2160W -1424W 低消費電力型への変更が非常に有効 27

28 参考既存環境移行を計算既存環境を以下のように仮定 Xeon 3GHz x 2 コア利用率 20% 程度 3000MHz x 2 x 0.2=1200MHz メモリ 2GB 搭載 5500 番台既存環境新規 / 既存 CPU 18080MHz 1200MHz 16.1 台メモリ 48GB 49152MB 2048MB 24.0 台メモリ 24GB 24576MB 2048MB 12.0 台 10VM 20VM 程度搭載可能と考えられる 28

29 参考 Intel と AMD を比較する以下の仕様で Word Press の動作性能比較 Intel Xeon X5570(2.93GHz x 4 コア )x2 プロセッサ ( 合計 8コア ) AMD Opteron 2435(2.6GHz x 6 コア )x2 プロセッサ ( 合計 12コア ) 24GB メモリ +FC ストレージ VM:1CPU 1GB CentOS 5.3 消費電力も比較 29

30 参考性能比較両 CPUがほぼ同性能 ( 差が4% 程度 ) CPUコア数 = 仮想 CPU 合計数が最も良い結果となっている Opteron の 8VM は見かけは少ないが全体の CPU 使用率は68% 程度で余力あり (4コア余り) Opteron 2435 (2.6GHz) Xeon X5570 (2.93GHz HT On) Xeon X5570 (2.93GHz HT Off) 8VM % 6% % * 96.2% 12VM * 100% % % 16VM % * 99.3% % 30

31 参考消費電力比較ベンチマーク時の最大消費電力で比較 Opteron は Xeon に対して 16% から 18% 消費電力が低い Hyper Threading が性能向上に対する消費電力の効率があまり良くない (3.8%:9.4%) Opteron 2435 (2.6GHz) Xeon X5570 (2.93GHz HT On) Xeon X5570 (2.93GHz HT Off) 8VM 200W 87.3% 259W 113.1% 1% 253W* 110.5% 12VM 229W* 100% 272W 118.8% 258W 112.7% 16VM 229W 100% 279W* 121.8% 255W 111.4% 31

32 提案例消費電力削減効果消費電力を 3 分の 1 に削減できます仮想化移行を行うことで年間約 127 万円 5 年間で約 635 万円の電気代削減効果が見込まれます 1kWh=24.13 円で計算しています消費電力年間電気代既存環境 9000W 1,902,409 移行環境 3000W 634,136 削減効果 33% に削減 1,268,273/ 年を削減消費電力は概算値です 32

33 仮想化のためのハード選びとりあえず低消費電力型クロック数よりもコア数メモリ多め消費電力を事前に計算しておくこと消費電力はサーバー増強時のことも考慮しておくこと 33

34 ストレージの選定

35 ストレージの選定高速なストレージの選定どの程度の速度が必要か I/O の性質は?(I/O ブロックサイズの大小 ) HDD の台数接続方法は? FC 接続 : 高速だが気軽ではない iscsi 接続 : 小規模向けに人気急上昇 NFS 接続 : 扱いやすい意外と高速 35

36 iscsi とは SCSIコマンドをTCP/IPでやり取りする仕組み iscsiイニシエーターからiscsiターゲットに接続 SCSI ディスク (/dev/sd?) として参照可能 iscsi ターゲットが参照可能なものファイル LVMの論理ボリュームディスクのパーティション (/dev/???) ファイル仮想マシン参照 iscsi イニシエータ接続 iscsi ターゲット LVM ボリューム 36 参照ディスク

37 ストレージ比較表扱いやすさ性能コスト規模 DAS 簡単普通安い小規模 NAS 普通やや速い安い小大規模 FC SAN 難しい速い高い中大規模 iscsi やや難しいやや速いやや高い中大規模大まかな比較 ( 構成によって例外あり ) 性能 :FC SAN>NAS iscsi DAS 扱いやすさ :DAS>NAS>iSCSI>FC SAN 37

38 ストレージの追加機能無停止での容量追加ゲスト OS 側での対応も必要ダイレクト接続 + 動的ボリューム管理で対応できるが仮想マシンの可搬性は低下スナップショット仮想マシンのバックアップに有効だが費用対効果の見極めが肝心レプリケーション DR サイト構築に有用 38

39 クラウド的ストレージは? クラウド= 分散と捉えるとそこまで必要とするシステムが企業系は少ない低コストな自家製汎用ノードによる分散ストレージよりもベンダー保守を選択今後はアリかもしれない? key-value 型やMapReduceなどよりも RDBMS など標準的な DB を選択特化型の仕組みなので別セグメントの話? 39

40 ベンチマークによる性能検証

41 ベンチマークとは処理速度の測定作業あるハードウェアドウェアソフトウェアの処理速度を知りたい比較したいある処理に必要となるハードウェアソフトウェアを知りたい測定対象 CPU ストレージネットワークメモリソフトウェアの処理速度 41

42 仮想化で使えるベンチマーク VMmark VMwareの開発したベンチマーク DB やWb Web など複数の VM を 1 セット ( タイル ) にしてハードウェアのキャパシティを測定 SPEC* 業界標準のベンチマークを多数提供 Iometer ディスクI/Oを測定するベンチマーク ab(apache Bench) Apache の性能測定用他にも多数 42

43 仮想化ベンチマークの注意点ベンチマーク負荷作業は外部から仮想マシン内では時間測定が不正確内部で実行する場合でも時間は外部から実行時に取得するキャッシュバッファの影響を考慮レイヤーが 1 段増えることで構造が変わりキャッシュが増える場合もある= 見かけ上の性能が物理サーバーを超える場合がある扱うデータ量や VM 数が増えればキャッシュが効かなくなり性能低下を起こす場合もある 43

44 参考 :Xen+NFS を使用した DB ベンチマーク結果

45 検証環境 ML350 G5 x 2 台 Xeon 5150(2.66GHz/Dual Core) x 1プロセッサ 16GB メモリ RAID 0(SAS HDDx8/128MBキャッシュ ) ギガビットイーサネット仮想マシン 1 仮想 CPU 2GB メモリ PostgreSQL pgbench(tpc-b 相当のDB ベンチマーク ) 45

46 ストレージ環境 NFS サーバーにて RAID 0 ディスクを構築 Linux の LVM にて LV を 2 つ作成 LV は 10GB サイズ LV-1 は VM-1 に RAW デバイス接続 LV-2 は ext3 で初期化後 NFS でエクスポートオプション :rw,sync,no_root_squash,no_wdelay VM-2 でLV-2 領域をマウントオプション : 無しまたは rsize=8192,wsize=8192 仮想ディスクファイル (8GB) を作成 46

47 ベンチマーク環境模式図 pgbench pgbench PostgreSQL mount NFS マウント nfsd PostgreSQL Linux Linux Linux Linux VM-2 Domain 0 Domain 0 VM-1 仮想ディスク接続 Xen Xen RAW デバイス接続 VD-2 VD-2 LV-2 LV-2 LV-1 /var/lib/xen/images にマウント LVM RAID 0 HD DD HD DD HD DD HD DD HD DD HD DD HD DD HD DD 外部仮想マシンホストストレージ 47

48 ベンチマーク作業 pgbenchを使用 TPC-B 相当のトランザクション SELECT,UPDATE,INSERT 検索 (SELECT) のみも実行可能今回の実行条件スケール :20(2,000,000,, 行 / 約 300MB) クライアント数 :20( スケールと合わせる ) トランザクション数 :1000 最初の5 回の結果は破棄し 6 回 10 回のうちの上下 1 件ずつを取り除いた3 回の平均値を取得 48

49 pgbench のトランザクションン SQL 以下のSQL を1つのトランザクションとして実行 1. BEGIN; 2. UPDATE accounts SET abalance = abalance + :delta WHERE aid = :aid; 3. SELECT abalance FROM accounts WHERE aid = :aid; 4. UPDATE tellers SET tbalance = tbalance + :delta WHERE tid = :tid; 5. UPDATE branches SET bbalance = bbalance + :delta WHERE bid = :bid; 6. INSERT INTO history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP); 7. END; 49

50 検索更新処理結果 50

51 検索のみ処理結果 51

52 結果の考察 NFSを使用した場合検索更新処理ではローカルディスクの 65% 程度の性能 NFSブロックサイズを8KBにするとローカルの 70% まで性能向上 (5% アップ ) 検索のみ処理の場合顕著な性能差が認められないため UPDATEおよびINSERT 処理のオーバーヘッドによる性能劣化と考えられる 52

53 NFS サーバーキャッシュの影響 NFSサーバーの利用するキャッシュの影響を測定 NFSサーバーの搭載するメモリを16GBから512MBに変更し同同一内容を測定システム起動時でキャッシュバッファが130MB 程度 VM-2の仮想ディスクサイズは8GB DBサイズが300MBのためキャッシュにすべてが乗り切らなくなる NFSサーバーキャッシュが不足している場合キャッシュが不足している場合検索更新処理ではローカルディスクの17% まで性能劣化検索処理はキャッシュ容量が少なくてもあまり影響を受けないが性能ピークへの到達に時間がかかる PostgreSQL のローカルバッファやインデックスが影響? 53

54 検索更新でのキャッシュの影響の影響 54

55 検索のみ処理の結果推移 55

56 考察検索主体のDBでは NFSをストレージとして使用しても性能劣化は少ない NFSストレージのキャッシュが少ない場合でもローカルバッファやインデックスの効果が認められる検索更新の DB では NFS をストレージとして使用すると性能劣化が認められる今回の条件では 30% 程度の劣化 NFSサーバーのキャッシュ容量が不足すると性能劣化の度合いが激しくなる仮想マシン数が増えると NFSサーバーのキャッシュ容量が不足する可能性があるので注意 56

57 参考 SSD は速いか? A. SSD は良さそうだ高速なランダムアクセス低消費電力低発熱 B. SSD 導入は時期尚早? まだ実績が少ないまだまだドライブ単価が高い書き換え回数上限への懸念 57

58 参考 TPC-B ベンチマーク結果 58

59 参考 TPC-B ベンチマーク結果 59

60 参考ベンチマーク実行環境 SAS ディスク : GB 15krpm 2 台 SSD:Intel X25-E(SLC) 32GB 2 台 RAIDコントローラーのキャッシュは Off ディスク内蔵のキャッシュをOn/Offし測定 FC SAN:HP MSA1000 SCSI 146GB 10krpm 14 台によるRAID 5 コントローラーに 512MBキャッシュ Cache Off:R50%/W50% Cache On:R0%/W100% PostgreSQL によるベンチマーク pgbench -c 20 -t 回実行し 11 回 20 回の平均値を記録 60

61 まとめ分散が多いクラウド的な技術の中では仮想化は集中的なお話リソース競合が発生しない限り性能設計は比較的容易ボトルネックが I/O 部分に発生しやすい事前ベンチマークで性能値を測定するのが重要 61

62 お問い合わせ先仮想化環境を構築したいがどこに相談すればいいの? まずは我々にご相談ください日本仮想化技術株式会社

090801OSC新潟.ppt

090801OSC新潟.ppt 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 1 P2V Xen 3 4 2 6 3 7 2 21 32 5 1 8 4 H/W Point!! 9 A B Phy M Phy M Phy M Phy