Oracle ホワイトペーパー 2011 年 12 月 Oracle Virtual Desktop Infrastructure: ホスト型仮想デスクトップ設計提案

(1)

Oracle ホワイト・ペーパー 2011 年 12 月

Oracle Virtual Desktop Infrastructure:

ホスト型仮想デスクトップ設計提案

(2)

はじめに_{... 2} 設計目標_{... 3} アーキテクチャの概要_{... 5} 論理アーキテクチャ_{... 5} 容量プランニング_{... 7} 仮想化階層のサイズ_{... 7} セッション・レイヤーのサイズ調整 ... 8 ストレージ・レイヤーのサイズ調整 ... 9 ネットワークのサイズ変更 ... 10 ビルディング・ブロック ... 11 ネットワーク構成_{... 12} ストレージ・サーバー・ネットワーク構成_{... 12} 仮想サーバー・ネットワーク構成_{... 13} セッション管理サーバー・ネットワーク構成_{... 13} クライアント・ネットワーク構成_{... 13} ソフトウェアの構成 ... 14 ストレージ構成 ... 14 VDI 構成 ... 14 Windows デスクトップ構成 ... 14 高可用性 ... 15 結論_{... 16}

(3)

2

はじめに

エンタープライズ・デスクトップの配信では、長年にわたって

Windows PC

がその主な媒体としての地位を占め続けています。しかし、最近ではいく

つかの要因が絡み合いそれに代わる将来有望な製品が見られるようになっ

てきています。その要因には、サーバー・パフォーマンスの向上、ネット

ワーク化されたストレージの容量およびスループットの増加、ネットワー

クの高速化、そして、仮想化テクノロジーの到来などが挙げられます。

このデスクトップ配信の新手法は、「仮想デスクトップ・インフラストラ

クチャ」と呼ばれ、以下のような特長があります。

 デスクトップ・インフラストラクチャのセキュリティーを向上し、機密データを確実に保護する。  物的財産であるデスクトップ（デスクトップ・リアルエステート）の実行にかかる経費を削減できる。  必要としている社員にIT サービスをより迅速に配信できる。  社員が自分のデバイスを使用できる。

Oracle Virtual Desktop Infrastructure ソフトウェアは、サーバー上の仮想デ

スクトップを幅広いデバイスに対して配信するように設計されたデータ・

センター・テクノロジーです。管理された安全なユビキタス・アクセスを

提供する必要がある大規模な組織またはクラウド・コンピューティング・

ベンダー用に設計されています。

このペーパーでは、

Windows 7 の仮想デスクトップをオラクルのテクノロ

ジーを使用して、

500 人、1000 人、および 1500 人のユーザーに対してホ

ストし、配信するための技術提案について説明します。高レベルのアーキ

テクチャ、容量プランニング、設計決定、さらに最終的なパフォーマンス

最適化の提案について考察します。

(4)

設計目標

まず、設計の目標を見てみましょう。このペーパーの主な目的は、ターゲットであるWindows 7 の標準的なオペレーティング環境をユーザーの集団に対して配信する仮想デスクトップ・インフラストラクチャのデプロイを設計することにあります。ターゲットであるデスクトップの仕様は以下のとおりです。作業負荷の説明仮想ハードウェア 1 GB RAM 1 vCPU 64 MB ビデオ・アダプターRAM USB 2.0

Intel High Definition Audio オペレーティング・システム Windows 7（32 ビット）

アプリケーション・セットオラクルのエンタープライズ・アプリケーション（Siebel CRM、E-Business Suite など）

その他の設計目標

アプリケーションの互換性のための設計

仮想デスクトップは、次の2 つの方法で提供できます。

 完全なPC 仮想化 – Oracle VM VirtualBox、VMware Infrastructure 3、vSphere、 Windows Server 2008 R2 の Microsoft Hyper-V テクノロジーなどの仮想テクノロジーを使用します。

 ユーザー・セッションの仮想化 – Microsoft Remote Desktop Services （Windows Server 2008 R2 搭載）または Microsoft Terminal Services （Windows Server 2003 搭載）を使用します。

Oracle Virtual Desktop Infrastructure は、この両方の方法をサポートしていますが、このペーパーでは、Windows 7 仮想デスクトップを配信するために Oracle Virtual Desktop Infrastructure に搭載されているOracle VM VirtualBox を使用します。Windows 7 PC の完全なハードウェア環境を仮想化すると、単純にユーザー・セッションを仮想化するよりも多くのリソースを必要とする場合がありますが、完全なアプリケーションの互換性を保証する本当のWindows デスクトップをそのまま提供できます。拡張性のための設計デプロイを拡張するために追加し組み合わせることができる500 ユーザーのビルディング・ブロックを基に設計します。高可用性のための設計デスクトップPC と比較すると、ユーザーのデスクトップ環境をデータ・センターに移動することによって、データ・センター・クラスのハードウェアから継承される一定の堅牢さが得られます。ただし、障害回復性のあるシステムを設計することでポイントごとに発生する可能性のある供給停止に対応する必要があります。

(5)

4 レイヤー要件ストレージディスク障害に対する対策ストレージ・コントローラの障害に対する対策サーバー階層サーバー傷害に対応ネットワーク化スイッチ故障に対する対策セキュリティのための設計ここでは、ユーザーが企業ネットワークの内外のどこからでも作業できるシステムを提供することを目指しています。したがって、クライアントが実行されるフロントエンド・ネットワークと仮想デスクトップが実行されるバックエンド・ネットワークを区別する必要があります。均一性のための設計サーバー・ハードウェアの仕様では、標準的な素材を採用する必要があります。これによって、データ・センターの経費削減が達成されます。また、必要に応じて、管理者がサーバー・ハードウェアの目的を変更するための柔軟性も得ることができます。パフォーマンスのための設計仮想デスクトップの全体的なパフォーマンスに影響する要素には、使用可能なサーバー・メモリ、使用可能なサーバー・コア数、ストレージが配信できるIOPS 数、およびすべてのコンポーネントをまとめているネットワークの速度が挙げられます。次の表に、異なるユーザー・プロファイルごとの要件を示します。ユーザー1 人あたりの WINDOWS 7 デスクトップ・リソース メモリ VMS/コア VMS/スピンドル IOPS/ユーザー パワー・ユーザー 2048 6 10 20 知識労働者 1536 9 20 10 タスク実行者 1024 12 40 5

(6)

アーキテクチャの概要

論理アーキテクチャ

Oracle Virtual Desktop Infrastructure には、次の論理アーキテクチャがあります。

各階層の役割は次のとおりです。仮想デスクトップ・インフラストラクチャ・デプロイのメイン・コンポーネント機能的なコンポーネント役割クライアントユーザーが選択したクライアント・デバイス上で実行するコンポーネントです。このコンポーネントは、リモート仮想デスクトップを使用した表示とユーザー・インタラクションを行います。このコンポーネントは、既存のハードウェア（PC、Mac、iPad など）上で実行されるアプリケーション、またはSun Ray Clients のような専用デバイスである場合があります。セッション・マネージャこのレイヤーによってユーザーが仮想デスクトップに接続されます。このレイヤーでは、次の処理が行われます。  ユーザー認証  ユーザーに対する仮想デスクトップの割り当て  仮想デスクトップ・ライフサイクルの統合  仮想デスクトップへのリモート・アクセスの提供  管理ツールおよびサービスストレージ階層仮想化階層セッション管理階層クライアント階層データ・センター

(7)

6

このペーパーでは、オラクル社の次のテクノロジーを使用します。

レイヤー

クライアント Sun Ray Clients、Windows PC、Mac OS X、Apple iPad などのタブレット・デバイス

セッション管理階層 Sun x86 Servers で実行中の Oracle Virtual Desktop Infrastructure 仮想化階層 Sun x86 Servers で実行中の Oracle VM VirtualBox ストレージ階層 Sun ZFS Storage アプライアンスデスクトップ仮想化プラットフォーム仮想デスクトップ・オペレーティング・システムが実行されるプラットフォーム。デスクトップの配信には、次を使用できます。  仮想マシン・テクノロジー（VM を使用した Windows 7 の実行など）

 仮想ユーザー・セッション（Remote Desktop Services を使用した Windows Server 2008 など）ストレージシステムのストレージ要件を管理するレイヤー。次に対してストレージが必要となります。  仮想マシンの仮想ハード・ドライブ  パーソナル・ハード・ドライブ  テンプレートおよびスナップショット  中断された仮想マシンの保存されたステータス

(8)

容量プランニング

仮想化階層のサイズ

仮想化に必要な総メモリ量の計算

Oracle VM VirtualBox には、VDI デプロイで約 1024MB という基本メモリ要件があります。さらに、VM のサイズに応じたデスクトップごとの要件が存在します。ハイパーバイザーのハウスキーピングには、VM メモリ・サイズの 20%のガイドラインとするのが安全です。これらの数値から、500 ユーザーのビルディング・ブロック用のメモリ要件は次のように計算できます。必要となるメモリ = 1024MB + デスクトップの数 × VM のメモリサイズ × 1.2 必要となるメモリ = 1024MB + 500 × 1024MB × 1.2 必要となるメモリ = ~600GB 仮想化に必要な総_{CPU の計算} 必要となる総CPU の計算時に鍵となるリソースは、ハイパーバイザーがゲスト・スレッドのスケジュールに使用できるコアの数です。経験として、最新のサーバーCPU アーキテクチャを使用するとコアあたり10～15 台の仮想マシン (VM) 程度であれば簡単に処理できるため、500 ユーザーの CPU 要件の計算は次のようになります。必要となるコア数 = 仮想マシンの数 ÷ 12 必要となるコア数 = 500 ÷ 12 必要となるコア数 = ~40 コア仮想化のためのハードウェア選択ここでサーバーを選択する必要がありますが、計算されたRAM と CPU 特性を併せ持つサーバーを選択する必要があります。選択に影響を及ぼす要素には、発熱、容量、消費電力考察、組込み済みNIC 機能とともに、サーバーの致命的な障害の影響に対する姿勢などのさらに戦略的な要因があります。たとえば、小規模なサーバーが多数ある場合、ノードごとにより多くのデスクトップをホストしている大規模なサーバーが尐数ある場合より実行中のユーザーへの影響は低くなります。この設計では、Oracle Sun X4170 M2 サーバーの製品群を使用することにしました。この製品群は、容量効率の高い1 ラック・ユニットの高さですが、書き込み時には最大 144GB RAM までデータを投入でき、最高 12 個までの Intel CPU コアを使用できます。この n+1 障害回復モデルでは、別のノードの障害に応じるためにサーバーを 1 台余分に追加する必要があります。

この構成には、以下が必要となります。

Sun Fire X4170 M2 (Intel Xeon X5675)（144 GB/6 コア×2 基）

必要なシステム数 = Max ((RAM 合計 ÷ システムあたりの RAM),(総コア数/システムあたりのコア数)) + 1 必要となるシステム数 = Max ((600/144),(40/12)) + 1

(9)

8

セッション・レイヤーのサイズ調整

本番環境でのデプロイは、1 台のプライマリ Oracle Virtual Desktop Infrastructure ホストと、冗長性とスループットのための最低でも1 台のセカンダリ・ホストで構成されます。 Oracle Virtual Desktop Infrastructure サーバーは、Oracle Virtual Desktop Infrastructure データ用の埋め込みMySQL Server データベースをホストし、クライアントとデスクトップの間の情報をルーティングします。また、デスクトップをクライアントに配信するブローカー機能も提供します。

プライマリOracle Virtual Desktop Infrastructure サーバーには、基本としてデュアルコア CPU および 2 GB のメモリが必要です。デスクトップを実行する Oracle Virtual Desktop Infrastructure サーバー（プライマリまたはセカンダリ）には、実行中のデスクトップの数を均等に拡張するリソースが必要となります。この (n+1) 障害回復モデルでは、別のノードの障害に応じるためにサーバーを1 台余分に追加する必要があります。セッション管理レイヤーに必要な総_{CPU の計算} 内部観測から、コアあたり約50 セッションとわかります。したがって、セッション管理レイヤーで500 ユーザーに必要となる CPU は、次のように計算できます。必要となるコア数 = デスクトップの数 ÷ 50 必要となるコア数 = 500 ÷ 50 必要となるコア数 = 10 セッション管理レイヤーに必要な総メモリ量の計算内部観測から、各仮想デスクトップ・セッションに約32MB のメモリが必要となることがわかっています。500 ユーザーのセッション管理に必要な総メモリは次のように計算できます。必要となるRAM = デスクトップの数 × 32MB (+2GB（プライマリの場合））必要となるRAM = 500 × 32MB (+2GB（プライマリの場合）) 必要となるRAM = 20GB (+2GB（プライマリの場合）) セッション管理レイヤーのためのハードウェア選択この階層でも、Oracle Sun X4170 M2 サーバーの製品群を使用することにしました。リソース要件はそれほど高くなくデュアル4 コア・サーバーを使用することもできますが、均一な設計目標を満たすために、仮想サーバー・レイヤーと同じモデルを使用することをお勧めします。ただし、完全に挿入済みのメモリ構成は必要ありません。上記のように、障害回復のために、(n+1) モデルを使用します。このモデルでは、別のノードの障害に応じるためにサーバーを1 台余分に追加する必要があります。この構成には、以下が必要となります。

Sun Fire X4170 M2 (Intel Xeon X5675)（48 GB/6 コア×2 基）

必要となるシステム数 = Max ((RAM 合計 ÷ システムあたりの RAM),(総コア数/システムあたりのコア数)) + 1 必要となるシステム数 = Max ((34GB/48GB),(20/12)) +1

(10)

ストレージ・レイヤーのサイズ調整ストレージ・レイヤーには、仮想ハード・ドライブ（デスクトップのC:ドライブ）を保持する役割があります。Windows 7 の設計には、ローカルおよび専用のディスク・リソースがあります。したがって、良好なユーザー・エクスペリエンスを提供するには、VDI システムの IO 機能が非常に重要な役割を果たします。上記のパフォーマンス要件から、定常状態のWindows 7 のデスクトップごとに 5～10 の IOPS を配信する必要があることがわかります。また、ブート時またはログイン時のような利用要求のピークに対応できるようなシステムにする必要があります。たとえば、 Windows 7 の完全なブート・シーケンスには約 20,000 IOPS が必要です。

最新のSAS または SATA ディスクは、60～200 IOPS を個別に配信できるため、スピンドレスの数を単純に増加することが必要を満たすための一番簡単な方法です。ただし、 1 TB SSD の読み取りキャッシュを導入することでも 250 IOPS を得ることができます。 500 デスクトップ用のストレージ IOPS の計算 IOPS 必要となるIOPS = デスクトップの数 × 10 必要となるディスク = 5000 ÷ 250 ディスク数 = ~20 10 IOPS/ユーザーを想定 250 IOPS の想定 15,000rpm ディスク配信 ~175-210 IOPS + 1TB SSD 読み取りキャッシュまた、通信でビットを取得する必要があります。これは、通常iSCSI プロトコルを介して取得されます。iSCSI トラフィックのエンコードとデコードによるボトルネックを回避し、加速論理を促進するための処理能力を得るために、ストレージ・コントローラ、またはヘッドが適切なサイズに調整されているようにする必要があります。使用可能な帯域幅も十分に確保することも必要です。追加のストレージ・パラメータの計算属性式論拠計算処理能力コアの数 = 使用中の仮想ディスクの数 ÷ 200 コアの数 = 500 ÷ 200 コアの数 = 2.5 実験の結果、2 CPU および CPU あたり 4 つのコアのあるCPU デュアルヘッド（アクティブ/アクティブ）7320 ストレージは、 3200 (2 × 2 × 4 × 200 = 3200) の仮想ディスクまでに使用できることが分かっています。メモリ・サイズ最高48GB RAM の追加推奨コントローラに余分に配備された空メモリ容量をディスク・キャッシュとして使用してアクセス時間を削減できます。帯域幅平均ネットワーク帯域幅 [Mb/s] = 使用中の仮想ディスクの数 × 0.032 Mb/s 1 ギガビットのイーサネット・インタフェースのある7320 アプライアンスでは、 31250 までの仮想ディスクを使用できます (1000 ÷ 0.032)。ピーク・ネットワーク帯域幅 [Mb/s] = 使用中の仮想ディスクの数 × 40 Mb/s 1 ギガビットのイーサネット・インタフェースのある7320 ストレージでは、 25 までの仮想ディスクを使用できます (1000 ÷ 40)。ディスク容量ディスク容量 [GB] = デスクトップの数 × 仮想ディスクのサイズ [GB] 7320 は、最大 192 TB までのロー・ディスク容量を配信できます。

(11)

10 ストレージ・レイヤーのためのハードウェア選択

この階層には、500 人のユーザー用に、最高 24 ディスクまで収納できる 1 ディスク・シェルフのSun ZFS Storage 7320 Appliance を選択しました。最大のパフォーマンスを引き出すために、最大のメモリ構成とSSD 読み取りキャッシュ・オプションをお勧めします。

この構成には、以下が必要となります。

Sun ZFS Storage 7320 (Intel Xeon 2.4 GHz)（72 GB/4 コア×2 基）コントローラの数 = 2（障害回復性とスループットのため）必要となるシェルフの数 = 20 ÷ 24 必要となるシェルフの数_{= 1} 500 ユーザーを追加するごとに、ディスクのシェルフを 1 つ追加することで単純にスピンドルを追加できます。ネットワークのサイズ変更ネットワークがボトルネックにならないようにするため、および2 台のスイッチを使用するネットワークの高可用性の目標達成のために、8 つの 1GbE NIC を使用してストレージ・コントローラとセッション管理サーバーを構成することをお勧めします。仮想サーバーが必要とするのは、4 つのオンボード NIC のみです。後述のネットワーク構成を参照してください。

(12)

ビルディング・ブロック

上記の計算では、500 ユーザーのビルディング・ブロックを使用した以下のモデルに到達します。略語階層モデル CPU タイプネットワークメモリディスクラック装置 VCS VDI コア・サーバー X4170 M2 6 コア×2 基 X5675 8 NIC 48GB 2 1 VVS VDI 仮想サーバー X4170 M2 6 コア×2 基 X5675 4 NIC 144GB 2 1 SCS ストレージ制御サーバー 7320 4 コア×2 基デフォルト 8 NIC 72GB 2+2 SSD 2 (HA) SET ストレージ拡張トレイディスク・シェルフなしなしなしなし 300GB × 24 4 これをさらに簡素化するために、コンポーネントを以下のようなバンドルにグループ化できます。スターター・バンドルには、高可用性を達成するために(n+1)台のサーバーが導入されています。これらのバンドルを、さらに大きなデプロイを構築するために組み合わせられます。たとえば、500、1000、1500 ユーザー用のラックは以下のようになります。 500 ユーザー用ラック構成 ユニット数前面図用途 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 VDI 12 VDI 11 仮想化 10 仮想化 9 仮想化 8 仮想化 7 仮想化 6 ストレージ・ヘッド 5 ストレージ・ヘッド 4 ディスク・シェルフ 3 2 1 1000 ユーザー用ラック構成 ユニット数前面図用途 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 VDI 21 VDI 20 VDI 19 仮想化 18 仮想化 17 仮想化 16 仮想化 15 仮想化 14 仮想化 13 仮想化 12 仮想化 11 仮想化 10 ストレージ・ヘッド 9 ストレージ・ヘッド 8 ディスク・シェルフ 7 6 5 4 ディスク・シェルフ 3 2 1 1500 ユーザー用ラック構成 ユニット数前面図用途 42 41 40 39 38 37 36 35 34 33 32 31 VDI 30 VDI 29 VDI 28 VDI 27 仮想化 26 仮想化 25 仮想化 24 仮想化 23 仮想化 22 仮想化 21 仮想化 20 仮想化 19 仮想化 18 仮想化 17 仮想化 16 仮想化 15 仮想化 14 ストレージ・ヘッド 13 ストレージ・ヘッド 12 ディスク・シェルフ 11 10 9 8 ディスク・シェルフ 7 6 5 4 ディスク・シェルフ 3 2 1 バンドルユーザー数 VCS VVS SCS SET スターター・バンドル 500 2 5 1 1 拡張バンドル 500 1 4 0 1

(13)

12

ネットワーク構成

完全な障害回復機能を持つアーキテクチャという要件を実現するために、スイッチを通して異なるレイヤー間でトラフィックを確実に振り分けるようにする2 つのスイッチが必要となります。フロントエンド・ネットワークとバックエンド・ネットワークを区別するという要件を実現する必要もあります。バックエンド・ネットワーク上のデバイスは、2 つのストレージ・ヘッド、仮想化ホスト、およびセッション管理サーバーで構成されます。フロントエンド・ネットワークまたは外部ネットワーク上のデバイスは、セッション管理サーバーとなります。これによって、クライアントがデバイスとVM に対してネットワークを提供する仮想サーバー上のNIC に接続できるようになります。ストレージ・サーバー・ネットワーク構成 2 つのストレージ・コントローラーは、アクティブ/アクティブ構成でセットアップされている必要があります。つまり、両方のヘッドがアクティブにデータを供給する一方、いずれかのヘッドに障害が発生した場合には、正常に動作しているヘッドが障害を発生したヘッドのID を引き取り、そのヘッドに代わってデータを供給し続ける必要があります。このセットアップでは、フェイルオーバーに備えて、各ヘッドには4 つのアクティブな基幹ギガビット・ポートと4 つのパッシブなギガビット・ポートがあります。したがって、合計でストレージでは毎秒8 ギガビットのデータが送信されます。これは、千人の同時実行中のユーザーがいる場合、ユーザーあたりの毎秒のデータ送信量は1 メガバイトとなります。ストレージ階層仮想化階層セッション管理階層クライアント階層フロントエンド・ネットワークバックエンド・ネットワーク

(14)

仮想サーバー・ネットワーク構成仮想サーバーには、VM で実行中の Windows デスクトップのストレージ、RDP トラフィック、および外部ネットワークにアクセスするための4 つのネットワーク・ポートがあります。これらのポートは、バックエンド・ネットワークでフェイルオーバー機能用にIPMP グループの 2 ポートを、外部ネットワーク上で同様に 2 ポートを使用して構成できます。各仮想ホストは、最高125 ユーザーまで、つまり、1 ユーザーあたり毎秒 6 メガバイト送信できるようサイズ調整されています。これで、ストレージ・トラフィックと表示トラフィック (RDP) またはデータ・トラフィック (USB) を簡単にカバーできるはずです。セッション管理サーバー・ネットワーク構成セッション管理サーバーは、500 ユーザー用にサイズ調整されています。各サーバーは、各スイッチに対して2 つの基幹ポート(LACP)を使用して構成されたデータセンター・ネットワーク内の4 つのポートを使用して接続されます。これによって、1 ユーザーあたり毎秒約2 メガバイトの容量が確保できます。このほとんどが RDP トラフィックとUSB トラフィックで使用され、管理トラフィックで使用されるのはわずかな部分となります。セッション管理サーバーは、ALP に基づいたクライアント通信用に外部ネットワーク内でも4 ポートで構成されています。ここでも、すべての送受信トラフィックを簡単に処理できる、ユーザーあたり毎秒2 メガバイトの送信が使用可能となります。クライアント・ネットワーク構成

Windows PC、Mac、Linux、または iPad 上の Oracle Virtual Desktop Client を Sun Ray Clients 上のネットワークで使用するための設定は非常に簡単です。多くの場合、クライアントをネットワークにプラグインするだけでサーバーによって自動的にクライアントが検出されます。また、特定のサーバー・アドレスを接続先として使用することもできます。

(15)

14

ソフトウェアの構成

ストレージ構成

ストレージ階層の設定方法の詳細については、Oracle Virtual Desktop Infrastructure のドキュメント、ZFS Storage アプライアンスのマニュアル、および次のリンクにあるホワイト・ペーパー『How to Deploy a Sun ZFS Storage Appliance in an Oracle Virtual Desktop Infrastructure』を参照してください。

http://www.oracle.com/technetwork/articles/servers-storage-admin/zfssa-oracle-vdi-398526.html

VDI 構成

Oracle Virtual Desktop Infrastructure ソフトウェアは、セッション・ブローカーと仮想化ソフトウェアで構成されています。セットアップは、直感的でシンプルです。ソフトウェア・スタックのほとんどの構成はOracle Virtual Desktop Infrastructure 管理ソフトウェアのみから行えます。「デスクトップ・プロバイダー」と呼ばれるリソース（仮想ホストとストレージ・サーバー）の設定、仮想マシンのテンプレートとしての設定、レプリケーションとプールへのグループ化、プールと仮想デスクトップのユーザーおよびグループへの割り当てなどのタスクが含まれています。詳細については、Oracle Virtual Desktop Infrastructure の管理ガイドを参照してください。 Windows デスクトップ構成ターゲットとなるWindows 7 デスクトップ用のテンプレートをインポートする前に、 VDI デプロイのための VM を効率化することをお勧めします。ブロックの整列仮想ディスク内でストレージ・デバイスのディスク・ブロック・バウンダリを使用してディスク・ブロックを整列することによって、複数のディスク・アクセス操作を単純な読み取りまたは書き込み操作に変更できます。Windows の仮想ディスク・ブロックの整列を調整する方法については、Oracle Virtual Desktop Infrastructure のドキュメントを参照してください。

表示パフォーマンスの最適化

デスクトップ背景、スクリーン・セーバー、マウス・ポインターなどのWindows デスクトップの特定の設定の応答性は、Windows VM 内で調整を行うことで改善できます。詳細については、Oracle Virtual Desktop Infrastructure のドキュメントを参照してください。

Windows サービス Windows サービスの中には、次のような VDI デプロイに悪影響を及ぼすサービスがあります。それらのサービスは無効にする必要があります。  Windows 7 では、SuperFetch というサービスが使用されます。このサービスは、ローカルPC ではパフォーマンスが向上しますが、ディスクを集中的に使用するため、 VDI アーキテクチャでは全体としてのパフォーマンスに影響します。  Windows サーチ・サービス。  ウィルス検出のプロシージャは、注意深く行い、営業時間内には実行しないようにする必要があります。

(16)

高可用性

ここで推奨されたデプロイを積み重ねることが障害回復の設計目標にどのように影響するかを見直す必要があります。高可用性の設計とは、次のような事態を克服できる設計であることを意味します。障害影響ディスク障害影響なし。ストレージ・コントローラの障害 2 基目のコントローラによる引継ぎ。スイッチの故障スイッチが修理されるまでスループットに一時的な影響が及ぶが、システムは動作し続ける。仮想サーバーの障害既存のセッションへの接続が切断される。ユーザーがログインし直すと新しいセッションが開始される。セッション管理サーバーの障害障害が発生しているサーバーに接続しているユーザーは、ログインし直す必要があり、ログインし直すと異なるセッション管理サーバー経由にルートされる。既存の Windows セッションではデータ消失は発生しない。 (n+1)のアプローチは、サービスの質に影響が及ばないことを意味。プライマリが障害を起こすと、セカンダリが引き継ぐ。クライアントの障害ユーザーは他のクライアントからデータをまったく消失することなく再接続が可能。

(17)

16

結論

このペーパーでは、Windows ユーザー用の仮想デスクトップ・インフラストラクチャのデプロイのサイズを決定し構築する方法を説明しました。高レベルのアーキテクチャ、容量プランニングについて説明するとともに、拡張性、可用性、セキュリティ、パフォーマンスに基づいた設計決定について説明しました。

Oracle Virtual Desktop Infrastructure は、次のように「完全でオープンかつ統合された製品」を目指して設計されています。

「完全」は、完全な仮想デスクトップ・ソリューションをお届けするためのすべてのコンポーネントがOracle Virtual Desktop Infrastructure で提供できることを意味しています。お客様には単純にデスクトップの輝かしいイメージをお話いただくだけです。それ以外は、異なる階層で実行するサーバーやストレージ・ハードウェアからデータ・センター・デスクトップにアクセスするためのクライアント・デバイスに至るまで、すべてをオラクルがお引き受けします。

「オープン」は、Oracle Virtual Desktop Infrastructure が上記のような様々な階層でのコンポーネントの選択肢をサポートしていることを意味しています。たとえば、お客様がすでにお使いのハードウェア、仮想化ソフトウェア、ストレージ・システムを使用することをご希望の場合にも対応できます。 「統合された」は、オラクルのスタック・コンポーネントを使用することを選択した場合、最良のエクスペリエンスをお届けできる製品にするために設計されている最適化を利用できることを意味します。完全なVDI ソリューションでは、VDI ソフトウェアのデプロイに加え、サーバー・ハードウェア、ストレージ・ハードウェア、およびネットワーク・テクノロジを統合する必要があります。オラクルは、ソフトウェアとハードウェアが連動するように設計された完全なスタックをお届けできる唯一のVDI ベンダーです。

(18)

Oracle Virtual Desktop Infrastructure: ホスト型仮想デスクトップ設計提案 2011 年 12 月 Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問い合わせ窓口: 電話: +1.650.506.7000 ファックス: +1.650.506.7200 oracle.com

Copyright © 2011, Oracle and/or its affiliates. All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、口述による明示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合性についての黙示的な保証や条件を含み、いかなる他の保証や条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否定し、本文書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。 Oracle および Java は、米国 Oracle およびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。 Intel および Intel Xeon は、米国 Intel Corporation およびその子会社、関連会社の商標または登録商標です。すべての SPARC 商標は、許可を受けて使用されており、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMD のロゴ、および AMD Opteron のロゴは、Advanced Micro Devices の商標または登録商標です。UNIX は、X/Open Company, Ltd. 0611 を介して使用許諾された登録商標です。

Oracle ホワイト ペーパー 2011 年 12 月 Oracle Virtual Desktop Infrastructure: ホスト型仮想デスクトップ設計提案