コスト削減を実現する 仮想化環境の設計セオリー
•
0 likes•998 views
イベント名：日経BP 仮想化フォーラム2009 講師：日本仮想化技術 宮原 日時：2009/4/14 アジェンダ： • 仮想化 最新動向 • 仮想化でコスト削減するには – 現行システムインフラの課題と仮想化 – サーバー仮想化のコスト削減効果 • 仮想化環境の設計手法 – 仮想化環境設計の流れ – 性能を考慮したハードウェア選択 概要： 「仮想化技術でシステム統合すればコストが削減できる」という声を耳にします。しかし、仮想化環境を適切に設計しなければ効果は上がりません。設計には物理サーバーとは異なるセオリーがあります。仮想化環境設計の基本的な流れとポイントについて、弊社の手掛けた最新構築事例を交えて解説します。
Recommended
More Related Content
Similar to コスト削減を実現する 仮想化環境の設計セオリー
Similar to コスト削減を実現する 仮想化環境の設計セオリー (20)
More from VirtualTech Japan Inc.
More from VirtualTech Japan Inc. (20)
Recently uploaded
Recently uploaded (10)
コスト削減を実現する 仮想化環境の設計セオリー
- 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ソースコードレベルサポート 運用保守 3 ベンダーニュートラルなワンストップ・サポートをご提供 最近の主な実績 • パイオニア／パイオニアシェアードサービス様 仮想化環 境構築支援（Xen） • e-ラーニングサービス会社様 サービス提供用仮想化環 境構築支援（VMware ESX） • AP開発会社様 開発用仮想化環境構築支援（Xen） • 食材流通会社様 基幹業務システム用仮想化環境構築 支援（VMware ESXi） • 書籍・雑誌寄稿多数 – 『すべてわかる仮想化大全2009』寄稿 – 『仮想化技術Xen−概念と内部構造』監訳 • 仮想化技術に関する講演多数 – 日経BP主催 仮想化フォーラム2008 特別講演 – 日経BP主催 ITpro EXPO 仮想化Special 基調講演 4
- 3. 3 要するにこういう会社です • 仮想化技術に特化した会社です • 仮想化技術に関する経験が豊富です • 仮想化関連の製品／ソリューションを成熟 させます • 仮想化技術が今後ITの重要なコアインフラ 技術になると確信しています • 仮想化技術をしっかりとサポートします 5 強調したいこと 日本の 仮想化技術の 会社 6
- 4. 4 本日のアジェンダ • 仮想化 最新動向 • 仮想化でコスト削減するには – 現行システムインフラの課題と仮想化 – サーバー仮想化のコスト削減効果 • 仮想化環境の設計手法 – 仮想化環境設計の流れ – 性能を考慮したハードウェア選択 7 仮想化 最新動向
- 5. 5 最新動向サマリー • Citrix XenServerが無償化 – 有償サポートと管理ツール「Citrix Essentials」 で収益を上げるモデルに転換 • Hyper-V 2.0のベータ版がリリース – Live Migrationのサポート • 次期VMwareの機能が明らかになってきた – vCenter Server for Linux – vCenter ConverterのLinux環境P2Vサポート 9 今後の展望 • コスト削減圧力 – 仮想化技術のコモディティ化 – 仮想化ソフトウェア自体の無償化が加速 • クラウド対応 – 小規模から大規模にターゲットが移行 – 基礎技術を押さえておかないとトレンドについ て行けなくなる？ • 省電力化 – ハードウェア対応と合わせて 10
- 6. 6 仮想化でコスト削減するには いろいろなコスト削減 1. 調達コストの削減 ← 分かりやすい – 従来100円だったものが50円で買える 2. ランニングコストの削減 ← 感覚的 – 毎月100円かかっていたものが50円で済む 3. 作業効率の向上 ← 仮想化の当面の目標 – これまで1ヶ月かかった作業が1日で終わる 4. 不可能を可能にする ← システム課題解決 – 予算の制約、技術障壁で不可能だったことが可能になる 12 求められているのはコスト部門としてのITではなく、 ビジネスに貢献するIT
- 7. 7 現行システムインフラの課題 • システムコストの肥大化 → システム拡大に伴うランニングコストの増加 → 非標準化によるコストの非効率 • 加速するビジネス要求に追従できない → システム要求サイクルの短縮、短納期 • システム停止がビジネス損失に直結 → 低コストHA/DRソリューションの不在 13 仮想化を活用した次世代インフラ • 標準化によるコスト削減 → システム環境の標準化 → 管理プロセスの標準化 • 迅速化によるサービスレベルの向上 → オンデマンドのシステム展開 → 余剰リソース活用による高負荷対応システム • 冗長化によるビジネス継続性の確保 → 無停止運用の実現 → 障害に強いシステム 14
- 8. 8 サーバ仮想化のコスト削減効果 項目 詳細 仮想化の効果 ハードウェア CPU・メモリ・ストレージ・I/O ◎ ソフトウェア OS・アプリケーション △ 構築 設定作業など ○ 監視 死活監視・性能監視 ○ 運用 メンテナンス・障害対応 ◎ 設置 データセンター・マシンルーム ◎ 電気 ハードウェア・冷房 ◎ ネットワーク LAN・インターネット △ サーバ仮想化によるコスト削減効果は、項目によっ て異なります 15 仮想化で実現するコスト削減 • 導入コストの削減 – ハードウェアのコストパフォーマンス向上 • 管理コストの適正化 – 管理の標準化と集中化 • 「攻め」のITへの対応 – サービスレベル向上によるビジネスへの貢献 – IT本来の役割であるビジネスコストの削減 – 耐障害性確保によるBCPの実現 16
- 9. 9 仮想化環境の設計手法 仮想化環境設計のポイント • 目的の明確化 – 既存環境移行 ← 現状こちらの方が多い – 新規システム構築 • 何を優先するのか – コスト：導入コスト、ランニングコスト • 導入コストは自然と下がる傾向に – 機能：運用管理、可用性 – 性能：実行速度、処理容量 ←今日の主題 18
- 10. 10 目的の明確化 仮想化移行のプロセス 現状整理 可否判断 計画立案 計画実行 移行先検討 移行方法の 検討 19 「見える化」された目標の例 ハードウェア台数を2分の1に削減 ラック本数 3分の2に削減 システム復旧時間 1時間以内 システムダウンタイム 5分以内 システム寿命 2年延長 20
- 11. 11 設計フェーズ 論理設計 • 要求仕様を論理システムにマッピング • システムを機能単位で捉える 仮想化設計 • 論理システムを仮想化にマッピング • システムを仮想マシン単位で捉える 物理設計 • 仮想システムを物理H/Wにマッピング • システムのサイジングや冗長化など ギリギリまで物理的なことは考えない Point!! 21 システムB システムA 仮想化→物理マッピング VM H/W VM H/W H/W Resource Pool Resource Pool VM VM VM VM Phy M Phy M Phy M Phy M Phy M Phy M P2V移行 リソース要求 リソース提供 複数H/WでResource Poolを 構成することで冗長性を確保 要求リソースが限定的で 冗長性が不要な場合には 単独H/Wで構成 Resource Pool Resource Pool Resource Pool Resource Pool 22
- 12. 12 仮想化物理マッピングの注意点（1） • 最終的な物理設計を行うまで仮想マシンと物理マシ ンの紐付けは行わない • 仮想化環境にとって「位置の透過性」が重要 – 仮想マシンに物理マシン、物理リソースを割り当てるの は仮想化環境の仕事 – 動作させる仮想マシンに対する物理リソースの総量だ けを考慮すればよい – 仮想マシンはリソースプール内の「どこか」で動いてい ると考える – どのH/Wで動いているかは考慮しないでもよい – 障害発生時はリソースプール内で相互にカバーする 23 仮想化物理マッピングの注意点（2） • 仮想マシン・グループにリソースプールを紐 づける – 仮想マシン・グループ＝リソースプール≦物理 マシン群 – 複数マシンで構成したクラスタ上にリソース プールを配置することで自然と冗長化される – リソースプール単位で仮想マシン群を管理 • 本番用リソースプール：最優先・リソース潤沢 • 開発用リソースプール：後回し・リソース限定 24
- 13. 13 冗長化と60%ルール VM1 VM2 VM3 VM4 VM5 VM6 VM2 VM3 VM4 VM5 VM6 VM1 正常稼働時 異常発生時 HA移行 25 設計手順詳細（1） 1. 移行対象サーバーのリストアップ – マシンスペックおよび使用率 – 重要度および負荷率をABCランク分け – 移行不要サーバーは除外 2. 特記事項の確認 – 冗長構成 – スタンバイ構成 など 3. マシングループ毎に仕分け – システムを構成するWeb＋DB＋その他をグルー プ化 26
- 14. 14 サーバーリストの例 27 設計手順詳細（2） 4. グループ毎の要求リソース量を算出 – 既存リソースのリソース使用率調査 – CPUクロック数、メモリ量、ディスク容量、ディスク I/O、ネットワークI/Oなどの積算値 5. ターゲットH/Wによるリソースプールと比較 – リソースプールは最低3台の仮想マシンホストで構 成（冗長構成を考慮した場合） – CPUクロック数、メモリ量の積算値×60%程度 – 不足の場合はリソース追加を検討 – ストレージはパスの帯域幅やディスク本数などで 性能値が左右されるので別途検討が必要 28
- 15. 15 ハードウェアの選定 ハードウェアの選定ポイント • CPUは仮想化しても性能が下がりにくい – マルチコアは4コアが標準になりつつある • メモリ量が仮想マシン収容力を大幅に左右 – 32GB 64GBが当たり前に – RVI、TLBなど仮想化支援技術も標準に • 高速なI/Oの装備が必須 – FCまたは10G Ethernet – Intel VT-d/AMD IOMMUのサポート 30
- 16. 16 CPU使用率の計算方法 • CPUクロック数の世代間性能差に留意 – CPUの性能指標であるクロック数は製品の世 代によって性能が異なる – 実質的なクロック対性能は大きく変わっていな いので、クロック数比で計算してもよい？ CPU コア数 MHz 実質MHz SPECint2000 MHz/SPECint2000 Xeon 3.0GHz(推定) 1 3000 3000 1,429 2.10 Xeon 3.4GHz 1 3400 3400 1,617 2.10 Xeon 3.0GHz 1 3600 3600 1,718 2.10 Xeon 5110(1.6GHz) 2 1600 3200 1712 1.87 Xeon 5160(3GHz) 2 3000 6000 3,025 1.98 31 CPU使用率の計算例 • CPU使用率30%の物理マシンを、ほぼ同性 能・同クロックの仮想マシンホストに移行 – CPU使用率60%まで可能なので、2VMまで収 容可能 収容可能VM目安＝CPUコア数×2 むしろメモリ容量の制約の方が大きい 32 大雑把な計算で言えば
- 17. 17 ブレード or ラックマウント？ • 仮想化環境を組むなら最低3台構成 – RAID 5の考え方と同じ（最低HDD3台） – 60%ルールを基準にCPU、メモリなどを選定 • 4台以上ならブレード？ – 以後の増設計画にも左右される • ブレードの弱点も克服されつつある – HP BL495cではメモリスロット16本、最大 128GBメモリ搭載可能、10Gb Ethernet標準 33 その他サーバ選定のポイント • 高クロックよりもコア数 – CPUロックが減少し、仮想マシンの実行並列 度が高まる → 全体の性能が向上 – 低消費電力型を選択できる → ランニングコス トの削減 • スタンバイサーバは不要 – 物理的な区切りで考えず、全体のリソース容 量で考えること – 60%ルールの徹底 34
- 18. 18 CPUの仮想化 OS OS OS OS OS OS OS OS 仮想CPU割当を減らす 物理CPU数を増やす VM1がCPUリソースを専有 VM切替でVM2がCPUリソース確保 or VM1 VM2 VM1 VM2 35 ネットワーク構成例 仮想マシンホスト 仮想マシンホスト ストレージ ストレージ用 管理用 ライブマイグレーション用 管理端末 クライアントネットワーク 少なくとも4系統は 考える必要がある 36
- 19. 19 ストレージの選定 • 仮想化時のコストインパクト大 • できるだけ高速なストレージを選定 – 必要な速度を推測する – I/Oの性質は？（I/Oブロックサイズの大小） – HDDの台数をできるだけ増やす • 接続方法は？ – FC接続：高速だが気軽ではない – iSCSI接続：小規模向けに人気急上昇 – NFS接続：扱いやすい、意外と高速 37 ストレージ比較表 扱いやすさ 性能 コスト 規模 DAS 簡単 普通 安い 小規模 NAS 普通 やや速い 安い 小 大規模 FC SAN 難しい 速い 高い 中 大規模 iSCSI やや難しい やや速い やや高い 中 大規模 38 大まかな比較（構成によって例外あり） • 性能：FC SAN＞NAS≧iSCSI≧DAS • 扱いやすさ：DAS＞NAS＞iSCSI＞FC SAN
- 20. 20 ストレージの追加機能 • 無停止での容量追加 – ゲストOS側での対応も必要 – ダイレクト接続＋動的ボリューム管理で対応で きるが、仮想マシンの可搬性は低下 • スナップショット – 仮想マシンのバックアップに有効だが、費用対 効果の見極めが肝心 • レプリケーション – DRサイト構築に有用 39 事例のご紹介
- 21. 21 食材流通会社様 事例概要 • 受発注処理用ERPのインフラ新規構築 • USB起動のVMware ESXiを採用 – ディスクレスで低コスト – 障害発生時は手動切り替え • DBサーバー用にFCストレージ – 初期データ量300GB程度 – データの電子保存も考慮 41 要求レベルを少し下げるだけで 数百万円のコスト削減効果 ミドルレンジクラスのストレージを 有効に活用 ERP用ブレード HP c3000 BL460c x 3 VMware ESXi HP EVA 4400 FC接続 管理監視用ブレード BL460c Windows+VMware Server Linux+Hinemos 基本構成 事例 詳細 • 要求レベルを明確化した設計作業 – 仮想化のメリットを100%追求する必要はない – DB中心のシステムなので、性能・無停止・バッ クアップを中心に設計を行う • 可用性設計 – H/W障害発生時の切り替えは手動 – Hinemosを使用してシステム監視 42