PEX2014 仮想基盤の可能性を引き出すvSphere

© 2014 VMware Inc. All rights reserved.
仮想基盤の可能性を最大限に引き出す
”VMware vSphere”
ヴイエムウェア株式会社
システムエンジニアリング本部
システムズエンジニア vCAP DCA/DCD
中村朝之

パートナー様から提案に関するフィードバック
(少しネガティブなご意見)
CONFIDENTIAL 2
• VMware提案は難しい….（テクノロジーやライセンス）
• 他社と機能差はないので色を出しづらい….

(想像してみてください）どちらの提案がいいですか？
CONFIDENTIAL
VMware ESXVMware ESX
Read
lock
VMware ESXVMware ESXi VMware ESXVMware ESX
Read
lock
VMware ESXVMware ESXi
Read
lock
Read
lock
Read
lock
仮想基盤の”特徴=共有”を踏まえ、
より目的に沿った基盤を構築する
Read
lock

本日の内容
 仮想基盤の特徴を踏まえ、未来を語る
– サーバ編
– ストレージ編
– ネットワーク編

仮想マシン増加を想像する
 仮想基盤= HWを占有ではなく“共有”している
– サーバ/ストレージ/ネットワークの負荷 UP
IO IO x3

お客様のお悩み～サーバ～編
CONFIDENTIAL 6
• 新規でVMを起動する際、どのサーバ(ESXi)で起動するか？
• ESXiメンテナンス時に仮想マシンを適切なESXiに退避したい
• 複数台のESXiのリソースを満遍なく使用したい

ポイントとなる機能
希望価格（CPU 単位、ライセンスのみ）
機能
• 健全性監視とパフォーマンス分析
• 高可用性とフォルトトレランス
• vMotion および Storage vMotion
• ホストプロファイルおよび Auto Deploy
• Storage DRS、Profile-Driven Storage
vCenter Operations Standard でも使用可能な機能
• キャパシティの管理と最適化
• 運用ダッシュボードと根本原因の分析
• Network I/O Control、Storage I/O Control、および SR-IOV
vSphere with Operations Management
Standard Enterprise Enterprise+
• Reliable Memory
• データ保護（バックアップ）と仮想マシンのデータレプリケーション
• vShield Endpoint
• Storage APIs for Array Integration および Storage APIs for Multipathing
• Distributed Resource Scheduler （DRS）および DPM
• Big Data Extensions
• Flash Read Cache
• Distributed Switch
既存の機能
• App HA
新機能
vExpertである富士ソフト山本様も
おススメの機能

サーバの状況を見ながら、自動で負荷分散
自動的に仮想マシンを移動させ、負
荷分散を図る
あるゲストOSの負荷が大きくなり、ホスト
上のリソースが不足
同一ホスト上の他のゲストOSの処理性
能に影響を与えてしまう
一般的なDRSの説明

例えば仮想マシンの配置を考える (1)
仮想マシンの
消費量を計算
個々の物理サーバ
リソースを確認、
仮想マシンを配置
物理サーバの、
メンテナンス時にお
けるVM配置を検討
配置管理シート
を作成
お客様に提出
リソースがひっ迫し
てきたホストを発見
仮想マシンを
移行したい！
配置管理シートで、
どの物理サーバに
移行するか確認
移行後配置管
理シートを更新
柔軟なはずの仮想基盤には、ほど遠い…
初期設計時
 DRSを使わない設計と運用
運用時(リソース消費に偏りがでた場合)

例えば仮想マシンの配置を考える (2)
仮想マシンの
消費量を計算
個々の物理サーバ
リソースを確認、
VMを配置
物理サーバの、
メンテナンス時にお
けるVM配置を検討
配置管理シート
を作成
お客様に提出
リソースがひっ迫し
てきたホストを発見
どのVMを移行
するか検討
配置管理シートで、
どの物理サーバに
移行するか確認
移行後配置管
理シートを更新
初期設計時
運用時(リソース消費に偏りがでた場合)
 想像してみてください DRSのあるなし
仮想マシンの
消費量を計算
仮想マシン消費
量に見合った物
理サーバを準備
基本DRSに
お任せ

CONFIDENTIAL 11
どのくらいの負荷で、仮想マシンが移行？
どのタイミングで仮想マシンが再配置？
全部自動でやってしまう？
その辺がわからないので不安…

１．DRSの発動するタイミング
自動化レベル：
仮想マシン「PowerOn」と「運用中」（クラスタに偏りが出た場合）
2．どのくらい偏りが発生したら仮想マシンを再配置？
移行しきい値：
優先度1～5で設定
押さえておきたい、2つのパラメータ

DRSの発動するタイミング～「PowerOn」と「運用中」～
CONFIDENTIAL 13
選べる３つの自動化レベル
 手動： “推奨”のみ表示、承認後仮想マシンが移行
 どのESXiで仮想マシンを動かす方がいいか？教えてくれるが管理者が
「承認」するまではPowerOn時の配置、再配置は行われない
 一部自動化：仮想マシンPowerOnのみ自動に展開
 運用中の再配置は管理者が承認するまでは再配置されないが、仮想マ
シンPowerOn時は自動に配置
 全自動：仮想マシンPowerONも再配置も全自動
 仮想マシンPowerOn時、再配置を全て自動的に実施♪

どのくらい偏りが発生したら仮想マシンを再配置？
14
より積極的に仮想マシンを移行
• 優先順位１
ESXiをメンテナンス
モードにする時のみ
DRSが発動
• 優先順位3
普段あまり動いてほ
しくないが、予想外の
仮想マシンの負荷に
対して有効
優先順位1 優先順位5
• 優先順位5
クラスタリソースを万
遍なく使用したい用
途向け

動画で見てみましょう
CONFIDENTIAL 15

他にもまだある、DRSのメリット
～移行先を限定してラインセンス代を節約～
CONFIDENTIAL 16
アプリA用のクラスタアプリB用のクラスタアプリC用の
クラスタ
OS
APP
OS
APP
OS
APP
OS
APP
OS
APP
OS
APP
OS
APP
OS
APP
アプリA,B,C用のクラスタ
OS
APP
OS
APP
OS
APP
OS
APP
OS
APP
OS
APP
OS
APP
OS
APP
メンテ用
メンテ用メンテ用メンテ用
１クラスタ内で、移行先
範囲を限定できる
 DRSなし
 DRSあり

お客様のお悩み～サーバ～編
CONFIDENTIAL 17
• 新規でVMを起動する際、どのサーバ(ESXi)で起動するか？
• ESXiメンテナンス時に仮想マシンを適切なESXiに退避したい
• 複数台のESXiのリソースを満遍なく使用したい
Distributed Resource Scheduler….
を説明するとお客様に
ちょっとした“サプライズ”が生まれます♪

ストレージを”共有”する

CONFIDENTIAL 19
• 仮想マシンが増えると、ストレージ部分がまずボトルネック
• LUN/Volumeを増やしてしまい管理対象が増
• ストレージはぶっちゃけよくわからない….
IO IO x3
お客様のお悩み～ストレージ～編

「共有」に適したファイルシステム
 仮想基盤”専用”ファイルシステム＝ VMFS
– 高パフォーマンス
ブロックサイズパススルー
– 拡張性
動的拡張容量 Thin/Thick
– 共有ファイルシステム
安全な排他制御
マルチノード(ESXi) から安全な
アクセス

VMFSの特徴～複数ESXiから安全なファイルシステムアクセス～
 ファイルシステム管理領域保護 = LUN全体の瞬間的なロック
管理領域保護が起きるタイミング
– 仮想マシン電源on/off
– Snapshot取得時
– 仮想マシン作成削除
– vMotion
等…..
課題
仮想マシンが増えていくと…
LUN全体へのロックが多くなることもあり、
仮想マシンの配置や、多くの仮想マシン
展開しづらくなってしまう…..
仮想基盤のメリットが半減(涙) Server 1 locks VMDK.
Server 1 releases LUN.
Other servers can resume I/O.
Normal I/O
VMware ESXVMware ESXi VMware ESXVMware ESXi VMware ESXVMware ESXi0011
1001
0100
1100
0110
1101
1011
0010
1100
Server 1 wants to start a VM and
needs to lock the LUN
VM VM VM VM VM VM VM VM VM

仮想環境における仮想マシン配置は考えない！(VAAI)
 ストレージとvSphereが連携し、“ロック粒度”を最小限に
– 管理領域更新時の操作もLUN全体をロックしない仕組みを提供※
VMware ESX
VMware ESX VMware ESX VMware ESXi0011
1001
0100
1100
0110
1101
1011
0010
1100
Read
lock
Free
Check if
free, and
lock
Success!
Normal I/OServer 1 wants to start a VM,
checks VMDKs for locks.
Server 1 tells storage “If lock still
free, lock it for me”
Servers 2 & 3 can still access the LUN
VMware ESX VMware ESXiVMware ESXi
※Storage APIs for Array Integration
-vSphere Enterprise以上
-ストレージ側におけるFWの対応

更なるストレージIO増に対する“備え”
IO > 100
IOキャパ：100
突発的なIO増加に備え、物理的
なストレージを足す時間もなし….

ストレージIO増に備える～ストレージIOの制御～
VMware ESX
VMware ESX VMware ESX VMware ESXi0011
1001
0100
1100
0110
1101
Read
lock
VMware ESX VMware ESXiVMware ESXi
IO
 IO競合時、特定の仮想マシンを優先
急なIO増にも対応
貴重なストレージリソースに
対して、Hypervisor側で
コントロールできる仕組み！

CONFIDENTIAL
25
• 仮想マシンを増やすと、ストレージ部分がまずボトルネック
• LUN/Volumeを増やしてしまい管理対象が増えてしまう
• ストレージはぶっちゃけよくわからない….
お客様のお悩み～ストレージ～編
仮想基盤特有のボトルネック要因を
管理者の手間なく予防/コントロール♪
IO IO x3

次世代を見据えた仮想化基盤

【再掲】仮想マシン増加を考えてみる
 仮想基盤= HWを占有ではなく“共有”している
– サーバ/ストレージ/ネットワークの負荷 UP

仮想化基盤の次のステップ
CONFIDENTIAL 28
サーバ統合の次のステップ
仮想環境でボトルネックになる、ストレージ
OK！
OK！
となると、次は･･･？次はネットワークです！
お客様のお悩み
• ESXi拡張時、VLAN変更時のポートグループの設定
• 物理NICをさらに有効的に使いたい
• 最近使うことが増えてきた10G NICの帯域を有効に使いたい

CONFIDENTIAL
29
仮想スイッチの増加＝エッジスイッチの増加
ESXi
仮想SW1
PG1
VLANX
PG2
VLANY
仮想SW2
PG3
VLANX
PG4
VLANY
累計
エッジスイッチx 2
PortG x4
ESXi
仮想SW1
PG1
VLANX
PG2
VLANY
仮想SW2
PG3
VLANX
PG4
VLANY
累計
PortG x8
ESXi
仮想SW1
PG1
VLANX
PG2
VLANY
仮想SW2
PG3
VLANX
PG4
VLANY
累計
PortG x12
ESXi
仮想SW1
PG1
VLANX
PG2
VLANY
仮想SW2
PG3
VLANX
PG4
VLANY
累計
PortG x16
VLAN変更時はエッジスイッチ、PG
の数だけ設定変更する….

CONFIDENTIAL
エッジスイッチは最小限、管理はシンプルに vDS活用法#1
ESXi
PG1 PG2
ESXi ESXi ESXi
分散仮想SW1 （vDS）
PG1
VLAN X
PG2
VLAN Y
累計
PortG x16
累計
PortG x 2VMware
vCenter
Server
拡張されても「設定と管理のタスクは増大しない」

CONFIDENTIAL
10G NICの帯域を、柔軟に使い切るためのNIOC
10GのNIC、使い切れていますか？ vDS活用法#2
VM
100
vMotion
50
Mgt
50
FT
50
NFS
50
iSCSI
50
トラフィック
• 通信の種類ごとに、[制限]と[シェア]を設定できる
• サーバのリソースプールと同じように、
ネットワークリソースプールを設定可能！

CONFIDENTIAL 32
物理NICの動的な負荷分散 vDS活用法#3
主なロードバランシング方法
• ポートベース
• MACベース
• IPハッシュ
• 物理NICの負荷に応じた分散
負荷状況に応じたバランシング
1Gと10Gが混在するような場合には特
に有効
ESXi
APP
OS
APP
OS
SC
APP
OS
vSwitch

今、急速にvDSの普及が進んでいます
CONFIDENTIAL 33
ｖDS
この2年で
30%→65%

お客様のフェーズに合わせたスイッチ構成
分散仮想スイッチ NSX
分散仮想スイッチ分散仮想スイッチ
仮想スイッチ
少数のサーバレベ
ルの管理を楽に
NWリソースも
物理構成に依存
「複数台」におけるサー
バレベルで管理を楽に
NWリソースを仮想化し、
柔軟に割り当て
「すべての」サーバレベル
でネットワークを管理
物理ネットワーク構成に
依存しないNWを設計

仮想マシンを150VMから450VMまで増やしてみる
36
150 VM(今)
vSphere Std
既存保有ライセンス 450 VM (将来)
追加投資: 17,486万
追加投資: 7,490万
Ent+
コスト効果
約1億円！！
300 VM(将来)
追加投資: 10,656万
追加投資: 7,300万
Ent+
コスト効果
約3000万円

37
既存維持でのサーバ増設新しい指針での提案効果
＋＋ …
統合率物理：仮想（1：6）
現行と同じS/Wコスト
VM数増加
現行と同じH/Wコスト
ほぼ同一の作業コスト
運用工数の増加
統合率物理：仮想（1：12〜）
S/W追加コストの抑制
VM数増加
H/W増設コストの抑制
自動化による
運用工数削減
Ent+
CPU 使用率
5%
メモリ使用率
40%
CPU 使用率
10%〜
メモリ使用率
80%
VMwareライセンス費
ハード/ソフトのトータル的な話
拡張時も「設定と管理のタスクは増大しない」がポイント

38
共通基盤の規模（VM数）
運用に要する人的リソース
100 300 500
運用負荷が元々軽いので
人員増は不要
運用負荷を
人海戦術でカバー？
 リスク増大
 ROI低下
 リスク軽減
 ROI上昇
0
基盤の運用性を
考慮しない場合
基盤の運用性を
考慮する場合
仮想マシンが増えたらどうなるか？を想像する(人的な話)
拡張時も「設定と管理のタスクは増大しない」がポイント

仮想基盤の特徴を踏まえ、お客様にお伝えする
39
• DRS
• VAAI
• 分散仮想スイッチ
• HA
• FT
• I/O Control
• vMotion
• Storage vMotion
• DRS
リソース効率の向上メンテナンス
基盤運用の簡素化
• 分散仮想スイッチ
• DRS
SLAの維持
限られたリソースを有効活用
することで、仮想マシンあたりの
投資を最小化する
サービスおよび仮想マシン
を止めずにサーバやストレージ
のメンテナンス作業を行える
大規模な基盤を、ミスなく
安定的に運用でき、運用
コストを最小化
仮想マシンに要求された
サービスレベルを基盤の
機能で維持する
仮想基盤
基盤の規模
運用工数
人的リソース
基盤の規模
仮想マシン
あたりコスト
￥コスト Off
￥コスト Off

「次世代」の基盤を見据える
CONFIDENTIAL 40
３年後、５年後のお客様の基盤はどうなってますか？
サーバ統合
vMotionやHA
とりあえず、ハードを減らし
可用性も持ちたい
仮想マシンが増えるにあたり
管理の負荷は変えず、物理リ
ソースを有効的に使用
外部クラウドサービスとどう
連携していくか？？
Read
lock
Read
lock

PEX2014 仮想基盤の可能性を引き出すvSphere

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to PEX2014 仮想基盤の可能性を引き出すvSphere (20)

Recently uploaded (12)

PEX2014 仮想基盤の可能性を引き出すvSphere

Editor's Notes