2013,all rights reserved by NetCommerce & applied marketing 仮想化とSDx 2013,all rights reserved by NetCommerce & applied marketing

仮想化とは

仮想化の基本 物理システム 仮想システム 物理的資源の削減 ソフトウエア管理への移行 OS 仮想化ソフトウェア OS OS OS 仮想マシン サーバー OS アプリケーション ミドルウェア 物理マシン 仮想化ソフトウェア ハイパーバイザー 仮想システム アプリケーション ミドルウェア アプリケーション ミドルウェア アプリケーション ミドルウェア OS OS OS 物理マシン サーバー 物理マシン サーバー 物理マシン サーバー 物理的資源の削減 物理マシンの台数を減らすことができる ソフトウエア管理への移行 システム資源の調達や構成の変更をソフトウエア の設定作業として行える

物理マシン 仮想化ついての一般的理解 仮想マシン 仮想化ソフトウェア Hypervisor Physical Machine 独立した3台のマシン として扱うことができる 仮想マシン Virtual Machine 仮想化ソフトウェア Hypervisor 物理マシン Physical Machine メモリ ストレージ CPU

Software-defined Environmentとは IT基盤をすべて ソフトウェアで制御 できるようにする技術 ネットワーク 仮　想 リソース Software-Defined Environment 物　理 リソース ネットワーク リソース・プール

Software-defined Environmentとは スピードとアジリティ システム・リソースの調達や構成の変更を物理作業を伴わず柔軟・迅速にできる 機器構成の変更や障害による影響の最小化 物理リソース（リソース・プール）での構成変更や障害による影響を回避、または、局所化できる 運用の自動化 物理的な作業を伴わずソフトウェアの設定を変えることで、システム全体の構成変更や運用管理ができる 仮想リソース 必要とするリソースを 物理構成に関わらず 柔軟に調達・変更可能 ネットワーク ネットワークの仮想化 ボトルネック！ Software-defined Networking の登場で全リソースで SD化に見通し 　ソフトウエア Software-defined 物　理 リソース ネットワーク リソース・プール

IT基盤をすべてソフトウェアで動的に定義し、管理できるようにすること 仮想化の目指す「あるべき姿」 IT基盤をすべてソフトウェアで動的に定義し、管理できるようにすること VM Ｃ２ LV５ LV６ Ｘ1 仮装ネットワーク　3 ネットワーク上 のリソースを 単一リソース・ プールとして 利用 ユーザー・ビュー データセンター　Ⅰ データセンター　Ⅱ VM A1 VM A2 VM B1 VM B2 VM C1 VM C2 VM Ｘ1 VM Ｘ2 VM Ｙ1 VM Ｙ2 物理サーバー 物理サーバー 物理サーバー 物理サーバー 物理サーバー LV0 LV1 LV2 LV3 LV4 LV5 LV6 LV7 LV8 LV9 物理 ボリューム 物理 ボリューム 物理 ボリューム 物理 ボリューム 物理 ボリューム 物理 ボリューム 物理 ボリューム 物理 ボリューム ストレージ・プール ストレージ・プール 仮想ネットワーク1 仮装ネットワーク2 仮装ネットワーク3 仮装ネットワーク4 LAN WAN LAN

(OpenStack,CloudStack ・・・) コレ一枚でわかる　「クラウドOS」 パブリック クラウド 垂直統合機 IBM PureSystems HP CloudSystem Matrix 仮想マシン 仮想ストレージ 運用管理 システム　　 仮想ネットワーク クラウドOS (OpenStack,CloudStack ・・・) セルフ･サービス ポータル API システム資源管理 サーバー 仮想化 ストレージ 仮想化 ネットワーク 仮想化

コレ一枚でわかる 「クラウドOS」 Open Source Software Proprietary vCloud Amazon互換API・マルチVM 独自API・個別VM vCloud

仮想化 と クラウド と SDE (Software-Defined Environment) コスト削減 俊敏性の向上 ビジネス・スピードの加速 リソースの 動的配置・配分 による柔軟性の向上 運用や調達の自動化によるTCOの削減 リソースの分割によるシステム資源の効率的活用 仮想化 クラウド Software-Defined

SDN(Software-Defined Networking) 仮想化とは／仮想化の種類と構成 仮想化 クライアントの仮想化 ストレージの仮想化 ネットワークの仮想化 デスクトップの仮想化 アプリケーションの仮想化 サーバーの仮想化 仮想LAN(VLAN) SDN(Software-Defined Networking) ブロック・レベルの仮想化 ファイル・レベルの仮想化 画面転送方式 ストリーミング方式 アプリケーション方式

VDI Virtual Desktop Infrastructure 仮想化とは／仮想化の種類　１ サーバーの仮想化 仮想化ソフトウェア ＣＰＵ メモリ プロセッサー SW ネットワーク クライアント 画面 サーバー デスクトップの仮想化 ＯＳ KB マウス VDI　Virtual Desktop Infrastructure クライアント クライアント クライアント ネットワーク サーバー ＯＳ サーバー SW SW SW サーバー サーバー サーバー ＣＰＵ ＣＰＵ ＣＰＵ メモリ メモリ メモリ 仮想化ソフトウェア ハイパーバイザー プロセッサー ＣＰＵ メモリ

仮想化とは／仮想化の種類 2 アプリケーションの仮想化 （画面転送方式） ネットワーク サーバー アプリケーションの仮想化 仮想化とは／仮想化の種類　2 アプリケーションの仮想化 （画面転送方式） ネットワーク クライアント サーバー アプリケーションの仮想化 （ストリーミング方式） 実行環境 アプリ ケーション 配信管理機能 ファイル・サーバー ランタイム DLL設定 OSサービス レジストリ設定 クライアント クライアント クライアント 画面 画面 画面 KB KB KB マウス マウス マウス ネットワーク サーバー アプリ アプリ アプリ クライアント クライアント クライアント ＣＰＵ ＣＰＵ ＣＰＵ メモリ メモリ メモリ 仮想化ソフトウェア プロセッサー ＣＰＵ メモリ

仮想化とは／仮想化の種類 3 クライアントの仮想化 クライアントの仮想化 （ハイパーバイザー方式） （アプリケーション方式） クライアント 仮想化とは／仮想化の種類　3 クライアントの仮想化 （アプリケーション方式） クライアントの仮想化 （ハイパーバイザー方式） 仮想化ソフトウェア ＣＰＵ メモリ プロセッサー クライアント ミドルウェア アプリケーション ＯＳ クライアント アプリケーション アプリケーション ミドルウェア ミドルウェア ＯＳ （ゲストＯＳ） 仮想化 ソフトウェア オペレーティング・システム （ホストＯＳ） プロセッサー ＣＰＵ メモリ

仮想化とは／仮想化の種類 ４ ストレージの仮想化 ネットワーク ストレージの仮想化 ネットワーク サーバー／スイッチ プロセッサー SAN 仮想化とは／仮想化の種類　４ ストレージの仮想化 （ブロックレベルの仮想化） ネットワーク コンピューター ストレージの仮想化 （ファイルレベルの仮想化） ストレージ コンピューター コンピューター コンピューター ネットワーク SAN Storage Area Network サーバー／スイッチ ストレージ ストレージ ストレージ NAS Network Attached Stor. 仮想化ソフトウェア プロセッサー ストレージ

物理的な構成にかかわらずネットワーク構成を自由に定義できる 仮想化とは／仮想化の種類　5 ネットワークの仮想化 （仮想LAN／VLAN） スイッチA スイッチB スイッチ スイッチ スイッチ VLAN01 VLAN02 VLAN03 物理的なネットワーク構成 論理的なネットワーク構成 物理的な構成にかかわらずネットワーク構成を自由に定義できる 新しいネットワークの仮想化 SDN

仮想化のメリット と課題

２０～３０% サーバーの仮想化／必要性（１） 物理的資源の削減 スペース活用の効率化 消費電力の削減 サーバーの稼働率向上 サーバー 集約 一般的な企業のサーバー稼働率 ２０～３０% スペース活用の効率化 設置スペースが削減され、土地や建物に関わるコストを削減できる 消費電力の削減 サーバーの冷却に必要な空調装置、サーバー本体の電力消費・CO2を削減できる サーバーの稼働率向上 購入するサーバー台数を、減らすことができる サーバー 集約

サーバーの仮想化／必要性（２） ソフトウェア的管理への移行 システムを簡単に稼動、複製できる ダイナミックなリソースの割り当て 定義ファイルを追加すれば、仮想マシンの追加が可能 システムを簡単に稼動、複製できる ハードウェアの導入作業が不要、ファイルの追加、設定だけでシステムが稼動 ダイナミックなリソースの割り当て 必要に応じて、システム・リソースの割当てを即座に、また、ダイナミックに変更できる 移行への柔軟な対応 業務を停止させずにシステムを移行することができる 障害に伴うシステムの停止を回避 複数の仮想マシンを同時に稼動させることで、ひとつが停止しても代替仮想マシンが機能していれば、停止を免れる ソフトウェア的管理への移行 仮想 マシン 定義 ファイル SYSTEM-A CPU:XXXXX DISK:XXXX SYSTEM-B CPU:XXXXX DISK:XXXX SYSTEM-C CPU:XXXXX DISK:XXXX 定義ファイルを変更 すれば仮想マシン の構成変更が可能 仮想化ソフトウェア メモリ ストレージ CPU ＩＴシステム・リソース

サーバーの仮想化／必要性（２） 物理 マシン 物理 マシン High Availability VMA VM B High Availability VM A B VM Z VM Y 物理 マシン 仮想化ソフトウェア Hart Beat (死活状況) をモニター 仮想化ソフトウェア 物理 マシン A B Y Z ライブ・マイグレーション(Live Migration) システムを停止させずに仮想マシンを移動させる技術 物理マシンの障害による システム停止の回避 メンテナンスに伴う システム停止の回避 負荷の最適配分のための 無停止での仮想マシンの移動

BCP対策 / 仮想マシン・レプリケーション VM A VM B 物理 マシン 仮想化ソフトウェア データ AP クラウド基盤へのレプリケーション 仮想マシン・イメージ のレプリケーション データの レプリケーション AP AP VM A VM B ネットワーク VM A VM B 物理 マシン 仮想化ソフトウェア データ AP 個別基盤へのレプリケーション 仮想化ソフトウェア 物理 マシン データ

サーバーの仮想化／課題 サーバー・スプロール ポリシー管理 ストレージ設計 ネットワーク ストレージ 未使用の仮想マシンの乱立。管理の複雑化とシステム資源の圧迫。運用ルール、管理方法により対応。 ポリシー管理 サーバーとネットワークが物理的に対応している場合は、ポリシーも管理しやすいが、それぞれが仮想化し追加や変更が頻繁に起こる場合、対応が複雑化。クラウドOSや自動化ツールにより対応。 仮想 マシン 仮想 マシン 仮想 マシン 仮想 マシン 仮想 マシン 仮想 マシン サーバー サーバー 　物理システムを前提としたシステム設計とは考慮点が異なる点が多い。 　フラッシュ・ストレージ、SDN、クラウドOSなど仮想化環境を最適化できるテクノロジーの活用を組み合わせた構築が必要。 ネットワーク ストレージ ストレージ設計 ライブマイグレーション、ストレージ共有、ランダムアクセスの増大によりI/0ボトルネックが発生しやすくなる。フラッシュ・ストレージなどI/Oの高速化やボトルネックの生じにくい設計により対応。

Software Defined Network SDN Software Defined Network

仮想化とは／サーバーの仮想化とネットワークの関係 【構築する側の視点：物理構成】 アプリ OS NIC 物理スイッチ （L2スイッチ） LAN 物理ネットワーク マシン 【運用する側の視点：論理構成】 L2スイッチの カスケード接続 物理マシン 仮想マシン 仮想マシン 仮想マシン アプリ アプリ アプリ OS OS OS 仮想NIC 仮想NIC 仮想NIC 仮想スイッチ 仮想化ソフト 物理NIC 物理スイッチ LAN 物理ネットワーク

ネットワークの課題 VM A VM B VM C VM C VM D VM E 物理スイッチ（L2） サーバー仮想化に関する課題 仮想サーバーの 予測できない増殖 物理サーバー間の 仮想サーバーの移動 物理サーバー１ 物理サーバー2 ライブマイグレーション VM A VM B VM C VM C VM D VM E 仮想スイッチ 仮想スイッチ CのVLANを削除 CのVLANを追加 物理スイッチ（L2） Cの移動に伴いVLANの設定変更 サーバー仮想化に関する課題 ESG “Ahead of the curve” event

VLAN （仮想LAN） ネットワークの課題 既存のプロトコルでは対処できない これまでのネットワーク仮想化の手段 VLAN （仮想LAN） 既存のプロトコルでは対処できない スイッチの設定を手動で行わなくてはならない 仮想マシンのVLANをまたがる移動、 ネットワーク機器の追加、QoSの設定など ひとつのVLANで最大2000個程度が限界 論理的には4096個の構成が可能 しかし、性能の劣化等により2000程度が限界 仮想化したサーバーの動的な変更に ネットワーク構成の変更を自動的に追従できない クラウドや仮想化の普及により求められる 大規模・複雑な構成のネットワークに対応できない 異なるVLANをまたがるライブマイグレーションはできない 帯域の増加に対応できない プロトコルやコマンドがメーカー独自の個別使用であり、異なるメーカー機器の混在した環境での一元管理・自動化は困難 Software-Defined Networking　(SDN) ネットワークの構成や機能の設定をソフトウェアによってプログラマブルに行える仕組み 　　　　　　　　　　　　　　　　　　　SDNを実現するためのプロトコル

仕様を一旦凍結し、アカデミック・フェーズからビジネス・フェーズへ 新たな取り組み 　　　　　　　　　　　　　　　　　　　SDNを実現するためのプロトコル Open Network Foundation　　since 2011 Board Members as of 07.Feb.12 2012年4月　 OpenFlow 1.3 リリース 仕様を一旦凍結し、アカデミック・フェーズからビジネス・フェーズへ

仕組み 従来のIPネットワーク OpenFlowプロトコル Dプレーン Cプレーン Cプレーン Cプレーン Cプレーン Dプレーン 管理者 Dプレーン データ転送機能 OpenFlow スイッチ Cプレーン ネットワーク経路制御機能 アプリケーション プログラム OpenFlowコントローラー Flow Table API OpenFlowプロトコル 管理者 ホート番号 送信元IPアドレス 送信先IPアドレス VLAN ID MPLSラベル ・・・ スイッチ スイッチ スイッチ Cプレーン ネットワーク 経路制御機能 Cプレーン ネットワーク 経路制御機能 Cプレーン ネットワーク 経路制御機能 独自ネットワーク 制御機能 独自ネットワーク 制御機能 独自ネットワーク 制御機能 Dプレーン データ転送機能 Dプレーン データ転送機能 Dプレーン データ転送機能

仕組み 従来のIPネットワーク 管理者 管理者 API アプリケーション Cプレーン 経路制御機能 Cプレーン 経路制御機能 Cプレーン Flow Table Dプレーン データ転送機能 Dプレーン データ転送機能 Dプレーン データ転送機能 Dプレーン データ転送機能 Cプレーン 経路制御機能 Cプレーン 経路制御機能 Dプレーン データ転送機能 Dプレーン データ転送機能 Dプレーン データ転送機能 Dプレーン データ転送機能 パケット転送機能と制御機能が一体化 経路制御情報は自己学習するが固定的 機器ベンダー個別の各種制御機能を利用 パケット転送機能と制御機能を分離 コントローラがスイッチの挙動を一括制御 制御機能はOSS化され独自改変が可能

仕組み Network Network VM A VM B VM C VM C VM B VM A VM A VM B VM C 物理ネットワーク VM A VM B VM C VM C VM B VM A OpenFlow スイッチ OpenFlow スイッチ OpenFlow スイッチ OpenFlow スイッチ OpenFlow スイッチ OpenFlow スイッチ Network VM A VM B VM C ロード バランサー ファイヤー ウォール Network 論理ネットワーク

スイッチ毎にベンダー独自規格のコマンドで手動設定 仕組み 従来のネットワーク 特定のベンダーに依存したプロトコル 業界標準のオープンなプロトコル ユーザー独自の設定変更や機能追加は困難 ユーザーが独自に機能の 追加・変更は可能 全体を管理するコントローラーから プログラムで自動かつ一斉に設定 業界標準のプロトコルとプログラム による運用管理スキルが必要 スイッチ毎にベンダー独自規格のコマンドで手動設定 それぞれのプロトコルに特化した 高度な運用管理スキルが必要 迅速・柔軟・自由 構成管理・変更の自動化 稼働状況や運用にあわせた アプリケーション・プログラム による構成管理・設定 　　　　　　ネットワーク機器のコモディティ化 (ベンダーロックインからの解放)

OpenStackへの組み込み Nova Amazon EC2のようなコンピュートサービス機能。仮想ハイパーバイザ経由で仮想マシンを管理 OpenFlow Nova Amazon EC2のようなコンピュートサービス機能。仮想ハイパーバイザ経由で仮想マシンを管理 Glance 仮想マシンイメージのカタログサービス。イメージをストレージに保存 Swift Amazon S3のようなオブジェクトストレージ機能 Keystone クラウドの各サービスに対してシングルサインオンを実現するための認証サービス Horizon クラウドのダッシュボードを提供するサービス Quantum ネットワーク管理機能や仮想ネットワークの機能を提供 Cinder Amazon EBSのようなブロックデバイスのストレージを提供

方式の違い オーバーレイ方式 ホップ・バイ・ホップ方式 トンネル コントローラー OpenFlow コントローラー 従来型 ネットワーク機器 スイッチ OpenFlow スイッチ 従来型 ネットワーク機器 従来型 ネットワーク機器 OpenFlow スイッチ OpenFlow スイッチ トンネル制御型 スイッチ トンネル制御型 スイッチ OpenFlow スイッチ OpenFlow スイッチ VM VM VM VM VM VM VM VM VMルーピングによる仮想ネットワーク 既存機器への導入が容易 ネットワーク経路・帯域制御は不可 広大なネットワークでのVM間制御が容易 NW機能とVMによるマルチテナントNWを実現 全てOpenFlowスイッチで構成することが必要 ネットワーク経路・帯域制御は可能 仮想インフラ基盤のシステム単位管理が可能

適用範囲と必要性 クラウド・プロバイダー 大規模データセンター 企業内ネットワーク SDN対象 の領域外 仮想マシン数 運用管理負担 迅速なNW構成変更への対応 IaaS運用の自動化・統合管理 VLAN ID(Max 4096)の制限解消 企業内ネットワーク 運用コストの削減 ネットワークの可視化 柔軟な構成変更 SDN対象 の領域外 既存設備との併存も考えなければならず、ネットワーク新設の場合を除きメリットを見出しにくい 運用管理負担

特徴のまとめ ネットワークの簡素化・自動化、柔軟かつ迅速な設定変更、ネットワークリソースの有効活用が可能 提供サービスへの容易な機能追加 Software-Defined Network（５）OpenFlowの導入メリット (著者: 林雅之) http://blogs.itmedia.co.jp/business20/2012/08/software-define-d1d3.html ネットワークの簡素化・自動化、柔軟かつ迅速な設定変更、ネットワークリソースの有効活用が可能 OpenFlowは、OpenFlowコントローラーが経路制御を一元的に行え、複数のネットワーク機器の設定を一元管理できる。 ネットワーク管理者は、コントローラーにフレームの処理を自由にプログラムで記述することで、物理ネットワーク環境を意識することなく既存プロトコルの制限にとらわれずに、ネットワークの物理、論理環境の迅速な設定変更が可能。 ネットワークのリソースのプール化も実現し、ネットワーク機器の機能や帯域、ファイアウォールやロードバランサのようなアプライアンスなどのリソースをサービスとして扱うことができる。 VLANを使わずに論理ネットワークごとに異なる機能やポリシーの割り当てや、機能やポリシーを動的に変化させることができるため、VLANの上限数を気にすることなく、柔軟なネットワーク制御が可能となる。 仮想サーバーの移動に合わせて、VLANなどの設定を変更することなく、ネットワーク経路が自動的に切り替わるライブマイグレーションの自動化も実現可能となる。 提供サービスへの容易な機能追加 ネットワークをプログラムで制御できるようになるため、サービス提供事業者が自社サービスに必要な機能が追加することができる。 OpenFlowコントローラーのAPIやSDKが公開されているため、自社に必要なネットワークを制御する機能をプログラムとして追加し、ネットワーク全体として利用することができる。 構築・運用コストの低減 ネットワーク機器のコモディティ化が進むことで機器コストの低減を図ることができ、ネットワークの簡素化の柔軟な設定変更によりネットワークのリソースの有効活用と自動化が進むことでネットワーク機器の設定、運用・監視などの稼動とコストの削減にもつながる。 新サービス投入の短縮化と差別化 ベンダーの開発ロードマップを待つことなく、自社に必要な機能は自社で追加実装していくことが可能で、市中製品の仕様に縛られずに、新機能の早期実現と差別化されたサービスの提供が可能となる。

コレ一枚でわかるOpenFlowの特徴と課題 期待されるメリット 特徴 一般的な企業に適用する場合の課題 スケール・アウト 従来はネットワーク機器のスケールアップでしか処理能力を拡張できない。OpenFlowはスイッチを追加することで対応できる。 一般的な企業ではダイナミックなノードの追加や移動はそれほど行われない。また、従来型スイッチも相当の能力を有し不足するとことはない。 集中制御 従来はネットワーク機器ごとに設定しなければならない。OpenFlowではネットワークを全体として一元管理できる。 既存のNWと併存する場合、新規OpenFlowのNWと二重管理が必要。また、既存と新規をつなぐGWも必要となり管理が三重化。結局、管理が複雑になる。 経路制御 フロー単位で制御できる。負荷に合わせた制御や機器交換を無停止でできるなどの利便性も高い。 既存機器との併存では、このメリットを活かせない。また、構成が複雑な場合、OpenFlowではダイナミック・ルーティングができずルート切り替えが手動となり運用が複雑になる。 ネットワークの可視化 物理構成と仮想構成が分離され、物理構成に依存することなくダイナミックに構成の変更や管理ができる。 従来は物理構成しかなく、構成管理やトラブルへの対応は直感的に対応できた。トラブルに当たり物理か論理かの切り分けも難しくなり、これまでのスキルが活かしにくい。 ライブ マイグレーション 従来は同じVLAN(サブネット)内でしか移動できなかった。OpenFlowでは移動の制約がない。 仮想サーバーが少ない場合はメリットは享受できない。また、一般的な企業内で頻繁にライブマイグレーションが行われることは少なく、メリットになりにくい。 現状では既存環境との併存前提ではOpenFlowへの移行に課題 成熟度が低く、従来可能だったきめ細かな対応ができないことも多い 複数データセンターを持つ大規模クラウド事業者や 全く新規に構築する場合はメリット

仮想化を取り巻く 新しい取り組み

ストレージの仮想化を補完する技術：シンプロビジョニング（１） 一般的な仮想化は、物理ストレージの構成を仮想化し、論理ボリュームを構成できるが、容量は仮想化できない。 そのため、将来必要となる容量をあらかじめ用意しておく必要がある。 結果として、余分なストレージを購入し、稼動させておかなければならない。 10TB 10TB 実データ2TB 実データ2TB 10TB 未使用領域 8TB 未使用領域 8TB 物理ストレージ 論理ボリューム 新システム稼働時には、将来のデータ量増加を予想（容量設計）、数年後でも容量に余裕があるストレージ装置を用意。しかし、新システムの稼働当初は全容量の“一部”しか使われない。残りの膨大なディスク・スペースは、その時点では不要。 ストレージの導入後も、ストレージの使用率が50％を超えるようなことはあまりない。データが増加しようがしまいが，一般にストレージの使用率は，平均すると3割程度。 ボリューム容量を後から拡大するのは運用負荷がかかるため、“保険”として容量に余裕を持たせておくのが一般的 使いもしない大量のディスクを購入、設置、動作させている

ストレージの仮想化を補完する技術：シンプロビジョニング（２） 一般的な仮想化 10TB 実データ 2TB 3TB 5TB 未使用領域 0TB 必要に応じて追加 論理ボリューム 物理ストレージ シンプロビジョニング 容量を仮想化 10TB 10TB 10TB 実データ 実データ 実データ 2TB 3TB 5TB 論理ボリューム 物理ストレージ 実データ 10TB 未使用領域 20TB 未使用でも割り当てた以上、全容量を用意しておく必要がある 30TB ボリュームの仮想化

ストレージの仮想化を補完する技術：シンプロビジョニング（３） アプリケーションやユーザーからは、10TBのボリュームに見える。 実データが、2TBの場合は、物理ストレージは、2TB分用意すればいい。 実データが増大した場合、その増大分のみ物理ストレージを追加すればいい。 実データ 2TB 2TB 10TB 追加 2TB 2TB 物理ストレージ 論理ボリューム ボリュームの“容量”を仮想化してキャパシティ・プランニング（容量設計）を不要とする技術 仮想領域の容量が不足した場合だけ、物理ストレージを追加すればいい。 ストレージ使用量を予測する手間が省け、無駄なストレージの導入を防ぐことができる。 ストレージの容量設計を省略 ストレージの利用効率を向上 コスト削減と省電力

ストレージの仮想化を補完する技術：重複排除（１） データをストレージに保存する際、重複部分を自動的に検出・削除する技術 新たに保存したデータをストレージ内の既存データと比較 重複部分を指定されたバイト数単位で調べる 重複部分があれば書き込まない コスト・メリット： ストレージ導入の初期コスト削減 ストレージ容量のアップグレード間隔の拡大 管理メリット： ストレージ装置ごとに格納できるデータ量の増加 オンラインのデータ保存期間の長期化 ビジネス・ドキュメントを世代管理している場合、ほとんどが重複データ 社内メールにドキュメントのファイルを添付して複数の宛先に送信した場合、宛先の数だけ重複データ

ストレージの仮想化を補完する技術：重複排除（２） ストレージ容量を効率化する技術 圧縮 頻繁にアクセスするデータを読み書きする場合、データの圧縮・復元によって性能が損なわれるおそれもある バックアップやアーカイブの用途ならばパフォーマンスの面でもほぼ問題はない 重複排除 頻繁にアクセスするデータでも性能は安定。 容量の削減率が高い(数分の一から数十／数百分の一) ファイル１ 既存ファイル A B A B A B C D C E ファイル１と２として、ブロックに緋も付けて保存 C E 書き込むべき ブロックが、同じかどうかを比較 D F ファイル２ A B E F

ストレージの仮想化と補完する技術との関係 論理ボリューム 容量の仮想化 シンプロビジョニング ボリュームの仮想化 一般的な仮想化 データ容量の削減 重複排除 物理ストレージ

補足資料

Software Defined Network 仮想化とは／仮想化の種類と関係 データセンター サーバー の仮想化 デスクトップ の仮想化 ストレージの仮想化 ブロック・レベル SAN ファイル・レベル NAS Software Defined Network OpenFlow VXLAN etc ネットワークの仮想化 サーバー エンド・ユーザー デスクトップ／ノートPC クライアントの仮想化 アプリケーション 方式 ハイパーバイザー ネイティブな 実行環境 アプリケーションの仮想化

デスクトップの仮想化 データセンターのサーバー上にクライアントの仮想マシンを稼働させ、 ネットワークを介して、その入出力のみをデスクトップ・デバイス上で実行させる ハードウェア オペレーティング システム デスクトップの仮想化 VDI Virtual Desktop Infrastructure ［クライアント・デバイス］ 画面表示 キーボード 操作 マウス ユーザーＢ アプリケーションの仮想化 との組み合わせ センター・サーバー ［コネクション・ブローカー］ クライアントデバイスから接続要求を ユーザーに応じて仮想マシンを割り当 ユーザーＡ ユーザーＢ デスクトップ デスクトップ アプリケーション アプリケーション オペレーティング システム オペレーティング システム 仮想マシン 仮想マシン ［仮想デスクトップ・マシン］ 仮想化ソフトウェア ［仮想インフラストラクチャー］

Citrix Provisioning Serverなど デスクトップの仮想化／方式 ネットブート方式 （シンクライアント方式） HDDが搭載されていない端末（シンクライアント）のメモリ上にOSやアプリケーションのイメージを、ネットワークを経由してブートする。 ブートに必要な最低限の機能は不揮発性のメモリーに書き込まれていて自分のログイン名、パスワードを入力するとOSが端末のメモリにブートされる。 端末にはデータが保存されず、アプリケーションをインストールしても電源オフ後は自動的に元の状態に戻るため、セキュアな環境が構築できる。 その一方で、USBメモリなどの周辺機器の使用は一般的なPCと同様にできる。 サーバー クライアントOS クライアントOS ディスクI/O Citrix Provisioning Serverなど クライアントOSとアプリケーションのメモリーにロード サーバーOS メモリー メモリー 仮想PC方式 物理サーバ上に複数のクライアントOSを仮想化して、端末からOSにアクセスすることで業務を行う。 使用するPCはOSの導入されたPCで、サーバー上のクライアントOSの画面と入出力操作のみをユーザーが使用できる。 クライアントOSはユーザー個別に用意され、担当している業務によってインストールするアプリケーションを柔軟に変更することができる。 PC側の電源オフ後も、それまでの実行環境はサーバー側に保存される。そのため、使用するPC環境が変わっても、それまでの業務を継続できる。 その一方で、USBメモリなどの周辺機器の使用は制限されており、データの持ち出しができない。 サーバー ディスクI/O クライアントOS クライアントOS Citrix Xen Desktop など 画面とマウス&KBの入出力のみ転送 画面　と I/O 画面 と I/O クライアントOS クライアントOS

デスクトップの仮想化／メリット ユーザー システム管理者 データを持ち歩かず自分のデスクトップ環境が利用可能 パッチの管理が不要 ネットワークが使用できる環境であれば、いつでもどこでも自分のデスクトップ環境を使用することができる。データが保存されている端末を持ち歩かないため、同時に情報漏洩などのリスクを低減。 パッチの管理が不要 一般的なPCの場合、アプリケーションやデータがローカルに保存されているため、IT管理者側から見ると管理することが容易ではない。一方、デスクトップ仮想化はアプリケーションやデータが保存されているストレージはサーバ側に集中しているため、ユーザは特に管理をしなくともIT管理者側で自動的に適用して貰えるというメリットがある システム管理者 ユーザーの増減に柔軟対応と管理工数の削減 新入社員や退職者、部署異動に伴うPCの入れ替えや新規導入にともなうアプリケーションの導入、設定登録、物理的な受け渡し、 、以前のデータ消去やOSの再インストール作業などの作業、既存PCを初期化などが不要。社員は自分のIDとパスワードさえわかっていれば、端末側で特別な設定をせずとも自分のデスクトップ環境へアクセス可能。 セキュリティポリシーの統一と徹底 バージョン管理やパッチの適用をサーバで一括して実行、セキュリティポリシーを統一。PCを運用する場合、管理者が一元的にパッチ配信などを管理している場合でも、オフラインの端末には適用することができず、セキュリティポリシーを統一することが難しい。しかし、OSやソフトウェアのイメージは全てサーバ側に存在するため、ユーザーが帰宅後で自動的にパッチを適用することも可能。 情報漏洩などのセキュリティ対策に有効 データがサーバ側に保存。端末には必要最低限の設定が保存されているものの、万が一盗難や紛失にあった場合でも情報漏洩に繋がるようなデータは基本的に保存されていない。物理的なマシンからの漏洩リスクは大きく減少する。

物理的なストレージ デバイスに論理的な構成を提供する技術 ストレージの仮想化（１） 物理的なストレージ デバイスに論理的な構成を提供する技術 ブロックレベルの仮想化 スイッチ FCやiSCSIなどの高速接続 ブロック単位（物理Ｉ／Ｏの単位） ストレージの効率的利用が目的 同一のＯＳで利用 ＳＡＮ（Storage Area Network）ストレージ専用の高速ネットワークで接続 狭　義 ストレージの仮想化 ファイルレベルの仮想化 ＬＡＮ ファイル・サーバー ファイル単位 ファイルの共有が目的 異なるOSでも相互に利用 LANを介した接続 ＮＡＳ（Network Attached Storage） Windows Linux

仮想化の種類／ストレージの仮想化（２） ブロックレベルの仮想化 ファイルレベルの仮想化 仮想化機能 専用・占有 ローカル・ディスクと同様のブロック（HDD上の物理的な位置に相当）　Ｉ/Ｏに対応する技術。 ローカル・ディスクと同様に高速な （FCプロトコル、iSCSIプロトコル）Ｉ/Ｏに対応する。 複数のストレージデバイス上に散在するブロックをまとめて単一の論理ボリュームとし、サーバやアプリケーションから利用可能にする。 各サーバからは、通常のファイルシステムを通じて、専用の仮想ボリューム（論理ボリューム）としてアクセスできる。 仮想化機能を持つ装置／ソフト 仮想化機能 ファイル単位で複数のサーバから共有する技術 LANに直接接続される。 NFSやCIFSといったファイル転送プロトコルを利用する。 サーバOSのファイルシステムの違いを吸収する仕組みや同時アクセスの排他制御などの仕組みを備え、サーバのOSが異なっていても同一ファイルシステムでファイルを共用できる。 ファイルレベルの仮想化 共用・共有

物理的なネットワークに複数の論理的なネットワーク構成を構築する技術 仮想化の種類／ネットワークの仮想化（１） 物理的なネットワークに複数の論理的なネットワーク構成を構築する技術 【通常のネットワーク】 【仮想化されたネットワーク】 物理NIC ネットワーク VLAN 仮想FW 仮想負荷分散 装置（VLB） 仮想VPN ゲートウェイ 仮想侵入防御 装置（VIPS） レイヤー３ スイッチ シャーシ型 LANスイッチ 物理リンク／ケーブル接続 論理リンク／VLAN接続 仮想スイッチ 仮想マシン ネットワーク ルーター ネットワーク機器の仮想化 ファイヤー ウォール ファイヤー ウォール LANスイッチ VPN ゲートウェイ 負荷分散装置 侵入防御装置 ネットワーク接続の仮想化 LANスイッチ LANスイッチ サーバー サーバー （現用系列） （予備系列）

仮想化の種類／ネットワークの仮想化（２） 通常のネットワークでは、構成を変更するために、ケーブルを抜き差しを伴う物理的な接続の変更が必要。 ネットワーク接続を仮想化する 　仮想LAN（VLAN：Virtual LAN） と言われる技術。スイッチに接続された機器を特定のグループに分け、個別のLANを構築できる。仮想マシンが稼働する環境では、物理NIC（Network Interface Card）やスイッチなども仮想的なものを利用できる。そのため機器の用意やケーブル接続が不要となり、ソフトウエア的な設定変更で対応可能。物理的な接続変更を必要としないため、ケーブル断線や接続ミスなどのトラブル発生を防ぎ、トラブル時の障害の切り分けも容易となる。 ネットワーク機器を仮想化する 　シャーシ型LANスイッチ（ファイアウォール機能、負荷分散機能、侵入防御機能や負荷分散機能などモジュール単位で導入できるレイヤー３スイッチ）を用い、ネットワークだけではなく、ネットワーク機器も仮想化する技術。サーバーやネットワークの構成を変更しても新たに機器を追加する必要がなく、必要なネットワーク機能の追加や接続の手間を削減できる。また、設置場所や消費電力の低減というメリットも期待できる。

サーバーのハードウェア・コストが低下しているにもかかわらず サーバーの仮想化が、求められる背景 サイトが分散し バックアップや 運用監視などの 管理負担が増大 稼働率の格差があり ハードウェアが 有効活用されていない サーポート切れのOSや パッケージが そのまま稼動している 【部門サーバーの課題】 個々のサーバーの 稼働率が低く CPU資源が 有効活用されていない サーバーの稼動や 空調設備にひつような 電力消費が増大している スペース占有面積が 増大している 【データセンター･サーバーの課題】 アプリケーション 部門単位で 個別にサーバー を導入 物理的な サーバー 台数が 急激に増大 陳腐化したサーバー を拡張して使うよりも 新しいサーバーを 購入した方が 安上がり サーバーのハードウェア・コストが低下しているにもかかわらず 運用管理負担やシステム・リスクが増大 X86(IA)系サーバー コストパフォーマンス 劇的な向上 TCAは低下しても TCOは、増大!

仮想システムの構築と運用／仮想システムの料金体系 仮想マシン単位 仮想化ソフトウェア CPU-1 CPU-2 CPU-3 CPU-4 OS ソフトウェア （4CPUライセンス） 仮想マシン 物理サーバー 物理サーバー単位 物理サーバーが搭載するCPU（コア）数分のライセンス料金 物理サーバー 仮想マシン 仮想マシン ソフトウェア （２CPUライセンス） ソフトウェア （２CPUライセンス） OS OS 仮想化ソフトウェア CPU-1 CPU-2 CPU-3 CPU-4 仮想マシンに割り当てるCPU（コア）数分のライセンス料金 初期料金を安いが仮想マシン+ソフトを 追加すると料金が発生する 初期料金は高いが仮想マシン+ソフトを 追加しても料金が発生しない 無料のオープン・ソース・ソフトウェアで構築する

サーバーの仮想化が生まれてきた歴史的背景 TCA 取得コスト TCA：Total Cost of Acquisition システムの購入に初期導入作業にかかわるコスト メインフレーム 購入価格は、高価 会社に一台／数台 １９６０年代 プロセッサーの種類の多様化 互換性に課題 一層の価格低下圧力 仮想システムの採用：１９６７年～ 背景：高価なため複数台の購入は困難 目的：業務目的や部門毎の専用システムとして使い勝手のよいシステムを提供するため オフコン・ミニコン 購入価格は、比較的安価 部門に一台／数台 １９８０年代 オープン・システム 購入価格は、極めて安価 部門／個人に一台 １９９０年代 部門サーバーや個人使用のＰＣが普及 コンピューターの台数が増大 運用管理コストの増大が課題 オープン・システムへの対応 価格低下の圧力 ミッション・クリティカル・ニーズへの対応 クラウド・システム 購入せずサービスとして使用 共有／運用の自動化 ２０１０年代 仮想システムの採用：２０００年～ 背景：システム台数の増加でＴＣＯ、ＴＣＡが増大 目的：複数のシステムを統合化し、台数を減らすことで、ＴＣＯ、ＴＣＡを削減すること TCO 所有コスト TCO：Total Cost of Ownership　TCAに加え所有することにともなう運用管理、保守作業にかかわるコスト

Flash,Air,Silverlight,HTML5 デスクトップの仮想化／歴史的背景 表現力 使いやすさ クライアントの表現方法とコストの変遷 クラウド コンピューティング デスクトップの仮想化 アプリケーションの仮想化 1995年～ リッチインターネット・クライアント Flash,Air,Silverlight,HTML5 ２００５年～ クライアント・サーバーシステム クライアントＰＣにプログラム 表現力向上／運用コスト増大 １９８５年～ Ｗｅｂシステム プラウザ／クライアントＰＣ 画像も、使いやすさ向上 １９９５年～ オフコン・ミニコン キャラクター端末 文字のみの表示 １９８０年～ メインフレーム キャラクター端末 文字のみの表示 １９６０年～ コスト

補足：サーバーの仮想化における課題（１） 【1】 物理システムの軽視 【2】 アプリケーション・パフォーマンスの低下 　仮想化は、比較的少ない物理システムで多くの処理を実行しようという考え方。しかしながら、それはハードウェアの優先順位を引き下げるということを意味するものではない。 　それどころか、仮想ワークロードをサポートするにはどのような物理リソースが必要か、またそれらのハードウェア・リソースを監視するには何が必要か、といったことを慎重に検討しておかないと、トラブルに見舞われることにもなりかねない。 【2】 アプリケーション・パフォーマンスの低下 　仮想化が急速な広がりを見せていることは間違いないが、一方で、仮想環境に対応していないアプリケーションもまだ少なくない。 　例えば、アプリケーション・ベンダーの一部に仮想サーバ上でアプリケーションをサポートする意思が無い場合や、導入した仮想化ソフトウェアに制約がある場合など。 【3】 セキュリティの複雑化 　仮想環境を構築すると、ハードウェアとソフトウェアのリンクが外れる。システムの柔軟さやダイナミックさを得るためにはそれが重要なのだが、インフラの安全性を確保するうえでは、それが混乱の原因になる。 　この（ハードとソフトの）分断により、ネットワーク・セキュリティ・アプライアンスの向こう側で何が起きているかが見えなくなる。また、サーバ環境は、より流動的かつ複雑になる。最終的に、セキュリティはハードウェアによってもたらされていた安定性を失い、あらゆるタイプのセキュリティ・ソフトウェアが、さまざまな脆弱性を指摘するようになる。 　さらに、仮想化はプロビジョニングやパッチングなどのプロセスを能率化するが、同時にITプロフェッショナルが考えもしなかった複雑さをもたらす。また、これまでになかったような脆弱性が潜む可能性のある（仮想マシン管理）レイヤにも、パッチを適用する必要が出てくるだろう。安全な環境を維持する作業やコンプライアンスのドキュメント化といった、仮想化技術のレイヤが追加されることで、事態はよりいっそう複雑になる。 【4】 標準化の迷路 　仮想化技術は急激に進化しているが、標準化や互換性の確保に向けた動きは遅い。そのあたりを十分に考慮しておかないと、特定ベンダーのアプローチにしばられてしまって、技術が成熟したときに、他のアプローチへ容易にシフトできなくなるおそれがある。 【Computerworld.jpより抜粋・要約　/　http://www.computerworld.jp/topics/vt/63071-1.html 】

補足：サーバーの仮想化における課題（２） 【5】 仮想化スプロール 【6】 ライセンス料金体系 【7】 ストレージの増加 　もともと仮想化は、物理サーバを統合して電力消費や放熱を抑えるための技術だった。しかし、多くのユーザー企業が注目したのは、むしろ、仮想マシンが簡単に作成できるということ、そしてそれにより、物理デバイスを削減しながら管理可能な仮想システムを大幅に増やせるということであった。しかし、その結果として仮想マシンのスパイラル、無分別な増殖が危惧される。 【6】 ライセンス料金体系 　アプリケーションを大型の仮想化したサーバで実行したくても、ライセンスがマシンの物理プロセッサ・コアに対して適用される体系になっている場合、アプリケーションを2ウェイ・サーバから4ウェイ仮想化サーバへ移行すると、ライセンス料は増加する。 【7】 ストレージの増加 　企業が十分使用に堪えうるストレージ・アレイを導入したとしても、仮想化ソフトウエアの負荷を十分に考慮していないとすれば、結果として、そのアレイは過度のスループット、過度のI/O。 　ストレージ問題は仮想環境のプラニング時に最優先で検討すべき事項。SANストレージは、事業継続性や災害復旧、アップタイム/パフォーマンス最適化のための負荷シフト、さらにはホストに対するゲストのスケーリングなどに、きわめて重要な役割を果たす。従って、ローカル・サーバのハードディスクからOS、ソフトウェア、データをSANキャパシティへシフトすると、ストレージの総量は急激に増大する。明確な階層型ストレージ戦略がなければ、高価なSANストレージがあっという間に食い尽くされてしまう。 【8】 仮想マシンの移動 　“（仮想マシンを）移動するときは、同じハードウェアが必要。インテルとAMDのシステムの間でVMware仮想マシンを移動することはできない。 　同社のVMotion技術を利用すれば、実行中のアプリケーションを一方の物理マシンから他方の物理マシンに移動することは可能。しかし、その場合、双方のマシンのプロセッサは同一でなければならない。つまり、AMDからAMDへ、あるいはXeonからXeonへの移動であれば可能。 　別のプロセッサへの移動ができないのは、プロセッサ・アーキテクチャや特定のインストラクションの差異が障壁となっている」（ラグラム氏）からであり、この問題を解決するには、長期的な取り組みが必要になる。 【Computerworld.jpより抜粋・要約　/　http://www.computerworld.jp/topics/vt/63071-1.html 】

仮想システムの構築と運用／計画・運用のプロセス ○×事業所 △□支社 本　社 自社データ・センター ロケーションの集約 ブレード・サーバー化 サーバーの集約 仮想化 　　　　移行・集約 現状調査・計画 システム資産把握 モニタリング 運用状況把握 ワークロード収集 仮想化対象の確認 仮想システムの規模 ワークロードの分散 統合効果の測定 　　　　運用の自動化 　　　　運用の標準化 仮想システム管理 ライフサイクル管理 課金管理 プロビジョニング管理 リソース状況管理 ワークロード管理 自動リソース割り当て スケジューリング ワークフロー管理 自動修復・防衛

補足：サーバーの仮想化を実現する手順 目的 ツール 事前調査 と分析 計画策定 運用管理環境 の標準化 物理的集約 サーバー の仮想化 投資対効果の最大化 運用管理の簡素化 運用の簡素化 稼働状況把握の容易化 サーバー台数の削減 サーバー稼働率の向上 目的 VMware Capacity Planner（VMwareのシステムサイジングツール）やIBM Consolidation Discovery and Analysis Tool：CDAT（ネットワーク上にある利用されていないサーバを検出するツール）など ブレード・サーバー 統合ストレージ(NASやSAN) 仮想化ソフトウェア ツール ■　事前調査 現状調査、要件確認、統合対象となるサーバの特定などを実施。 ■　データ収集　 ツールを使用してデータを収集。 ■　データ分析 収集したデータを元にユーザ環境サーバの時間帯による負荷率などを判断。 事前調査 と分析 ■　構成計画 物理統合・仮想化の検討、サーバの配置検討などの構成を検討。 ■　スケジュール策定 業務計画を考慮したスケジュールを策定。 計画策定 ■　標準化 管理に関する標準化と運用ルールの策定。 ■　効果目標設定 効果目標設定とそれにあわせた効果測定基準の設定。 運用管理環境 の標準化 ■　物理的集約 分散配置されているサーバーを一箇所に集約。 ■　管理の集中 運用管理ツールによる監視と管理の一元化。 物理的集約 ■　状況把握 稼働状況、共有状況の把握。 ■　仮想化 状況、標準化ルールに基づき、仮想化による集約を実施。 サーバー の仮想化

補足：ストレージの仮想化を実現する４つの方式 ブロックレベルの仮想化 ホストベース アプリケーションサーバなどいわゆるホスト側にエージェント（専用アプリケーション）を導入し、仮想化処理を行う方式 ネットワークベース サーバ側のネットワークとストレージ側のネットワーク（SAN）の間に、ストレージ仮想化製品を接続する方式 スイッチベース ストレージ仮想化機能が組み込まれたSANスイッチ自体で仮想化処理を行う方式 アレイベース ディスクアレイのコントローラーに仮想化機能を持たせた方式

補足：ホストベース方式 メリット： 異種混合のストレージ環境に対応。 アプリケーションサーバなどのホスト側にエージェント（仮想化のためのアプリケーション・プログラム）を導入し、仮想化処理を行う方式 ホスト側で論理的なボリュームの統合・割り当てを行い、それを基に物理的なストレージの各ボリュームにデータを格納。論理ボリュームと物理ボリュームのマッピングなどストレージ仮想化に必要な処理がホスト側で行われる。 シマンテック：Veritas Storage Foundationなど 仮想化機能 仮想化機能 仮想化機能 メリット： 異種混合のストレージ環境に対応。 既存のシステム構成、特にSAN（Storage Area Network）に対する物理的な影響度が低い。 デメリット： ストレージ仮想化製品がホスト・サーバのプラットフォームをサポートしていることが絶対条件。従って、既存のサーバ環境によっては導入が困難な場合がある。 各サーバにエージェントを導入する必要があるため、サーバへの負荷が懸念されるケースでは、問題。 各サーバ単位でボリュームのマッピング処理を行うため、大量のサーバで分散処理を行っているようなシステムでは、管理が煩雑。 スイッチ スイッチ

補足：ネットワークベース方式：インバウンド方式 サーバ側のネットワークとストレージ側のネットワーク（SAN）の間に、ストレージ仮想化製品を接続する方式 【インバウンド方式】 サーバとストレージの間の通信経路上に、ストレージ仮想化製品を接続する方式。サーバ側からのトラフィックが全てストレージ仮想化製品を経由。サーバとストレージの間でやりとりされるデータをストレージ仮想化製品がすべて直接処理。 日本アイ・ビー・エム：IBM System Storage SAN （SVC） ネットアップ：V3000、V3100シリーズ、V6000シリーズ ファルコンストア・ジャパン：FalconStor NSS データコア・ソフトウェア：SANsymphony、SANmelody メリット： 共有や排他などのデータアクセス制御が行いやすい。 スナップショットやリモートコピーなどを容易。 デメリット： ストレージ仮想化製品のデータ処理能力がシステム全体のスループットに大きく影響を及ぼす。 冗長性や処理能力を確保するため仮想化装置（もしくは専用サーバ）を2台設置する構成が一般的。 採用を検討する際にはあらかじめパフォーマンスやスケーラビリティに関する要件を明確にした上で、かつ実際に実環境で検証してみる必要がある。 スループット向上策として冗長化構成を取ることが一般的。最低でもサーバを2台（2ライセンス）購入。 スイッチ 仮想化機能 スイッチ

補足：ネットワークベース方式:アウト・オブ・バウンド方式 サーバ側のネットワークとストレージ側のネットワーク（SAN）の間に、ストレージ仮想化製品を接続する方式 【アウトバウンド方式】 SANのスイッチにストレージ仮想化製品を接続。サーバとストレージの間で流れるトラフィックのうち、仮想化処理に必要な制御データのみがストレージ仮想化製品で処理され、そのほかのデータはサーバとストレージの間で直接やりとりされる。 EMCジャパン：Invista LSIロジック：StoreAge SVM メリット： インバンド方式で課題となるスループットへの影響がほとんどない。 デメリット： 対応するSANスイッチの種類が特定されている場合が多く、導入に当たっては既存のSANスイッチをリプレースしなければならない可能性が高い。 製品によってはサーバ上にエージェントソフトウェアを導入しなければならないこともある。 ストレージアレイ側で提供されているフラッシュコピーやミラーリングといった機能が利用できなくなる場合もある。 スイッチ 仮想化機能 スイッチ

ストレージ仮想化機能が組み込まれたSANスイッチ自体で仮想化処理を行う方式 補足：スイッチベース方式 ストレージ仮想化機能が組み込まれたSANスイッチ自体で仮想化処理を行う方式 ストレージ仮想化機能を搭載したスイッチを利用する。 富士通：ETERNUS VS900 メリット： 導入時のシステム構成の変更はスイッチ機器の交換のみとなり、既存環境への影響を最小限にとどめられる。 デメリット: スイッチベンダーもしくはスイッチベンダーと仮想化ソフトウェアベンダーが共同で製品化するのが一般的であり、ストレージベンダーとの連携がスムーズに行われないことが多い。 スイッチとストレージの組み合わせによっては、ストレージが提供するレプリケーションやデータ保護などの機能を利用できない場合がある。 スイッチ スイッチ 仮想化機能

ディスクアレイのコントローラーに仮想化機能を持たせた方式 補足：アレイベース方式 ディスクアレイのコントローラーに仮想化機能を持たせた方式 ディスクアレイと一体で提供されることから、実質的には仮想化コントローラーとディスクアレイを同一ベンダーのものに統一して導入するケースが一般的。通常は、ディスクアレイ製品の拡張機能であり、ディスクアレイと共通のプラットフォーム上に仮想化コントローラーが実装されている。 日立製作所：Hitachi Universal Storage Platform メリット： レプリケーションなどディスクアレイが提供する機能を最大限に活用できる。 ストレージ仮想化製品だけでなくストレージアレイも新規に購入することを検討している場合 ストレージ仮想化製品を提供するベンダーの製品でストレージ環境をすべて統一したい場合 デメリット： 他社ストレージアレイを含め統一的に管理することが難しい。 ストレージ仮想化製品だけでなくディスクアレイも含まれることから、価格水準がほかの製品よりも高い。 スイッチ スイッチ 仮想化機能 仮想化機能 仮想化機能

デスクトップの仮想化 データセンターのサーバー上にクライアントの仮想マシンを稼働させ、ネットワークを介して、その入出力のみをデスクトップ・デバイス上で実行させる技術 ハードウェア オペレーティング システム 画面表示 キーボード 操作 マウス ユーザーＢ デスクトップの仮想化 VDI Virtual Desktop Infrastructure ［クライアント・デバイス］ センター・サーバー オペレーティング システム アプリケーションの仮想化 との組み合わせ 画面表示 キーボード 操作 マウス ユーザーＢ ［コネクション・ブローカー］ クライアントデバイスから接続要求を ユーザーに応じて仮想マシンを割り当 ユーザーＡ ユーザーＢ アプリケーション アプリケーション ハードウェア デスクトップ デスクトップ オペレーティング システム オペレーティング システム 仮想マシン 仮想マシン ［仮想デスクトップ・マシン］ 仮想化ソフトウェア ［仮想インフラストラクチャー］