ネットワ クネットワーク仮想化基盤における サービス機能の構 …nv/nv201207-03-kitatsuji.pdf · – ネットワーク仮想化基盤の要件 – サービス構成機能の要件
PEX2014 仮想基盤の可能性を引き出すvSphere
41
© 2014 VMware Inc. All rights reserved. 仮仮仮仮仮仮仮仮仮仮仮仮仮仮仮仮仮 ” VMware vSphere” 仮仮仮仮仮仮仮仮仮仮仮 仮仮仮仮仮仮仮仮仮仮仮仮仮仮 仮仮仮仮仮仮仮仮仮仮 vCAP DCA/DCD 仮仮仮仮
Transcript of PEX2014 仮想基盤の可能性を引き出すvSphere
© 2014 VMware Inc. All rights reserved.
仮想基盤の可能性を最大限に引き出す
” VMware vSphere”
ヴイエムウェア株式会社システムエンジニアリング本部
システムズエンジニア vCAP DCA/DCD
中村朝之
CONFIDENTIAL 2
パートナー様から提案に関するフィードバック( 少しネガティブなご意見 )
• VMware 提案は難しい… . （テクノロジーやライセンス）• 他社と機能差はないので色を出しづらい… .
( 想像してみてください）どちらの提案がいいですか？
CONFIDENTIAL
VMware ESXVMware ESXRead lock
VMware ESXVMware ESXi VMware ESXVMware ESXRead lock
VMware ESXVMware ESXi
VMware ESXVMware ESXRead lock
VMware ESXVMware ESXi VMware ESXVMware ESXRead lock
VMware ESXVMware ESXi VMware ESXVMware ESXRead lock
VMware ESXVMware ESXi
仮想基盤の”特徴 = 共有”を踏まえ、より目的に沿った基盤を構築する
VMware ESXVMware ESXRead lock
VMware ESXVMware ESXi
本日の内容
仮想基盤の特徴を踏まえ、未来を語る– サーバ編– ストレージ編– ネットワーク編
仮想マシン増加を想像する
仮想基盤 = 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 ManagementStandard 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 つのパラメータ
CONFIDENTIAL 13
DRS の発動するタイミング ～「 PowerOn 」と「運用中」～
選べる３つの自動化レベル
手動： “推奨”のみ表示、承認後仮想マシンが移行 どの ESXi で仮想マシンを動かす方がいいか？教えてくれるが管理
者が「承認」するまでは PowerOn 時の配置、再配置は行われない
一部自動化： 仮想マシン PowerOn のみ自動に展開 運用中の再配置は管理者が承認するまでは再配置されないが、仮想
マシン PowerOn 時は自動に配置
全自動： 仮想マシン PowerON も再配置も全自動 仮想マシン PowerOn 時、再配置を全て自動的に実施♪
どのくらい偏りが発生したら仮想マシンを再配置？
14
より積極的に仮想マシンを移行
• 優先順位１ESXi をメンテナンスモードにする時のみ DRS が発動
• 優先順位 3普段あまり動いてほしくないが、予想外の仮想マシンの負荷に対して有効
優先順位 1 優先順位 5
• 優先順位 5クラスタリソースを万遍なく使用したい用途向け
CONFIDENTIAL 15
動画で見てみましょう
16
他にもまだある、 DRS のメリット ～移行先を限定してラインセンス代を節約～
CONFIDENTIAL
アプリ A 用のクラスタ
アプリ B 用のクラスタ
アプリ C 用の
クラスタ
OS
APP
OS
APP
OS
APPOS
APP
OS
APP
OS
APPOS
APP
OS
APP
アプリ A,B,C 用のクラスタ
OS
APP
OS
APP
OS
APPOS
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 ESXi001110010100
110001101101
101100101100
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
VM VM VM VM VM VM VM VM VM
VMware ESX VMware ESX VMware ESXi001110010100
110001101101
101100101100
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
VM VM VM VM VM VM VM VM VM
VMware ESX VMware ESX VMware ESXi001110010100
110001101101
Read lock
VMware ESX VMware ESXiVMware ESXi
IO
IO 競合時、特定の仮想マシンを優先
急な IO 増にも対応
貴重なストレージリソースに対して、 Hypervisor 側
でコントロールできる仕組
み！
25CONFIDENTIAL
• 仮想マシンを増やすと、ストレージ部分がまずボトルネック• LUN/Volume を増やしてしまい管理対象が増えてしまう• ストレージはぶっちゃけよくわからない… .
お客様のお悩み～ストレージ～編
仮想基盤特有のボトルネック要因を管理者の手間なく予防 / コントロール♪
IO IO x3
次世代を見据えた仮想化基盤
【再掲】仮想マシン増加を考えてみる
仮想基盤 = HW を占有ではなく“共有”している– サーバ / ストレージ / ネットワークの負荷 UP
CONFIDENTIAL 28
仮想化基盤の次のステップ
サーバ統合の次のステップ
仮想環境でボトルネックになる、ストレージ
OK ！
OK ！
となると、次は･･･？次はネットワークです！
お客様のお悩み• ESXi 拡張時、 VLAN 変更時のポートグループの設定• 物理 NIC をさらに有効的に使いたい• 最近使うことが増えてきた 10G NIC の帯域を有効に使いた
い
CONFIDENTIAL
29
仮想スイッチの増加 ＝ エッジスイッチ の増加
ESXi
仮想 SW1
PG1VLANX
PG2VLANY
仮想 SW2
PG3VLANX
PG4VLANY
累計エッジスイッチ x
2PortG x4
ESXi
仮想 SW1
PG1VLANX
PG2VLANY
仮想 SW2
PG3VLANX
PG4VLANY
累計エッジスイッチ x
4PortG x8
ESXi
仮想 SW1
PG1VLANX
PG2VLANY
仮想 SW2
PG3VLANX
PG4VLANY
累計エッジスイッチ x
6PortG x12
ESXi
仮想 SW1
PG1VLANX
PG2VLANY
仮想 SW2
PG3VLANX
PG4VLANY
累計エッジスイッチ x
8PortG x16
VLAN 変更時はエッジスイッチ、PG の数だけ設定変更する… .
CONFIDENTIAL
エッジスイッチ は最小限、管理はシンプルに vDS活用法 #1
ESXi
PG1 PG2
ESXi ESXi ESXi
分散仮想 SW1 （ vDS ）PG1
VLAN XPG2
VLAN Y
累計エッジスイッチ
x 8PortG x16
累計エッジスイッチ x 1
PortG x 2VMwarevCenter Server
拡張されても「設定と管理のタスクは増大しない」
CONFIDENTIAL
10G NIC の帯域を、柔軟に使い切るための NIOC
10G の NIC 、使い切れていますか？ vDS活用法 #2
VM100
vMotion
50Mgt50
FT50
NFS50
iSCSI50
トラフィック
• 通信の種類ごとに、 [ 制限 ] と [ シェア ] を設定できる
• サーバのリソースプールと同じように、 ネットワークリソースプールを設定可能！
CONFIDENTIAL 32
物理 NIC の動的な負荷分散 vDS活用法 #3主なロードバランシング方法• ポートベース• MACベース• IPハッシュ
• 物理 NIC の負荷に応じた分散負荷状況に応じたバランシング
1G と 10G が混在するような場合には特に有効
ESXi
APP
OS
APP
OSSC
APP
OS
vSwitch
CONFIDENTIAL 33
今、急速に vDS の普及が進んでいます
ｖ DS
この 2年で30%→65%
お客様のフェーズに合わせたスイッチ構成
分散仮想スイッチ NSX
分散仮想スイッチ分散仮想スイッチ
仮想スイッチ
少数のサーバ レベルの管理を楽に
NW リソースも物理構成に依存
「複数台」における サーバレベルで管理を楽に
NW リソースを仮想化し、柔軟に割り当て
「すべての」 サーバレベルでネットワークを管理
物理ネットワーク構成に依存しない NW を設計
実案件における事例
36
仮想マシンを 150VM から 450VM まで増やしてみる
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とりあえず、ハードを減らし可用性も持ちたい
仮想マシンが増えるにあたり管理の負荷は変えず、物理リソースを有効的に使用
外部クラウドサービスとどう連携していくか？？
VMware ESXVMware ESXRead lock
VMware ESXVMware ESXi VMware ESXVMware ESXRead lock
VMware ESXVMware ESXi
Thank you!
