October 2008 October 2008
仮想化: Windows Server 2008 Hyper-V の概要
Hyper-V を導入すると、仮想化は IT 環境にとってさらに魅力的なソリューションになります。この記事では、現在の仮想化市場について概説し、Hyper-V によって仮想化の管理容易性、信頼性、およびセキュリティがどのように強化されるかについて説明します。 Rajiv Arunkundram
仮想化: VMM 2008 を使用して仮想環境を管理する
System Center Virtual Machine Manager では、仮想インフラストラクチャを管理するための統合型インターフェイスが提供されます。最新バージョンでは、Windows Server 2008 Hyper-V と VMware バーチャル マシンのサポートが追加されています。この記事では、VMM の新機能を紹介し、VMM を使用して管理作業を一元化する方法を概説します。 Edwin Yuen
仮想化: Microsoft Application Virtualization の概要
Microsoft Application Virtualization (App-V) を使用すると、組織内のクライアント システムに、仮想化されたデスクトップを提供できます。これにより、システム管理が単純化され、社員が特定のデスクトップに縛られずに作業できるようになります。この記事では、App-V の機能と組織への展開方法について詳しく説明します。 Anthony Kinney
仮想化: Hyper-V の高可用性を実現する
サーバーを少数の物理コンピュータに統合すると、大きなメリットを得ることができますが、システムの可用性を高めるように計画を立てることは非常に重要です。この記事では、Windows Server 2008 フェールオーバー クラスタリングを使用して、Hyper-V 仮想マシンの可用性を高める方法について説明します。 Steven Ekren
仮想化: サーバー仮想化に関するバックアップと障害復旧
仮想化は障害復旧に大きな変化をもたらします。この記事では、マイクロソフトの仮想化プラットフォームを DR 計画に組み込む方法を説明し、Windows Server 2008 Hyper-V に関するバックアップと復元のオプションおよび考慮事項を紹介します。 Adam Fazio
仮想化: 仮想インフラストラクチャを計画するための必携ツール
インフラストラクチャを仮想化する準備はできていますか。Microsoft Assessment and Planning Toolkit は、ネットワーク全体のインフラストラクチャを評価するためのツールです。このツールを使用すると、IT インフラストラクチャの状態をより正確に把握し、仮想化などのさまざまなテクノロジにシステムをアップグレードまたは移行できるかどうかを確認できます。 Jay Sauls and Baldwin Ng
Columns
編集長から: 仮想 (化された) 世界: | レター: 読者の皆さんからの声: | Toolbox: IT プロフェッショナル向けの新製品:
SQL に関する Q&A: サイズの大きいトランザクション ログ、修復を使用するタイミングなど: 今月の記事では、Paul Randal がバックアップと復元に関する質問に回答し、ログ配布とデータベース ミラーリングの相違点について取り上げ、修復機能は最終手段として使用する必要がある理由について説明します。Paul S. Randal | ユーティリティ スポットライト: Offline Virtual Machine Servicing Tool: オフラインで保存されている仮想マシン (VM) は、安全でセキュリティ基準を満たしている状態を保つために必要な更新プログラムを自動的に受信することができません。このような VM は、IT 環境全体にリスクをもたらす可能性があります。この記事では、無償の Offline Virtual Machine Servicing Tool を使用して仮想マシンの更新プロセスを自動化する方法について説明します。Peter Skjøtt Larsen and Suveen Kumar Reddy Vuppala | Windows PowerShell: プロファイルの力: 要件に合った作業環境で Windows PowerShell を起動したいと思ったことはありますか。この記事では、Don Jones が、プロファイルを使用して Windows PowerShell シェルをカスタマイズする方法について説明します。Don Jones
Hey, Scripting Guy!: 有名な最後の言葉: Scripting Guys がソクラテスについて語り、XML ファイルのクエリに関するトピックを再び取り上げます。ただし今回の XML ファイルは、子ノードを使用せずに、その他のプロパティ値が属性として構成されるように構造化されています。The Microsoft Scripting Guys | デスクトップ ファイル: Windows 展開サービスをカスタマイズする: この記事では、Wes Miller が、組織のニーズに合わせて Windows 展開サービスをカスタマイズして構成する方法を紹介します。Wes Miller | セキュリティ ウォッチ: セキュリティに関する 10 の鉄則再考 : 第 1 部: 「セキュリティに関する 10 の鉄則」が最初に公開されてから約 8 年が経ち、それから多くの変化が起こりました。今月から Jesper Johansson が 3 部シリーズを開始し、今日の視点から、これらの鉄則がまだ有効であるかどうかを分析します。Jesper M. Johansson
フィールド ノート: High-Capacity Color Bar Code: Gavin Jancke は、色と三角形を使用する新しいバー コードを開発しました。このバー コードには、従来の白黒のバー コードよりもはるかに大容量のデータを格納できます。この記事では、その High-Capacity Color Bar Code について詳しく説明します。Gavin Jancke | Windows 秘話: 効率よりも苦労を: この記事では、Raymond Chen がバグとエラーの歪んだ関係について解説し、プログラマは結果を出すだけでなく苦労することが重要である理由を説明します。Raymond Chen


仮想化
Windows Server 2008 Hyper-V の概要
Rajiv Arunkundram
概要 :
  • 仮想化とは
  • 3 つの仮想化アーキテクチャ
  • マイクロカーネル ハイパーバイザとモノリシック ハイパーバイザの比較
  • Hyper-V がもたらす効果

目次
サーバー仮想化市場
サーバーの仮想化のしくみ
仮想化ソリューションの種類
Windows ハイパーバイザ
親パーティション
デバイス共有アーキテクチャ
統合コンポーネント
Hyper-V の機能セット
スケーラビリティ
高可用性
セキュリティ
管理容易性
まとめ
最近、仮想化はずいぶん話題になっており、こうした議論のほとんどはサーバーの仮想化に関するものです。これは、業界において最も魅力的な動きの 1 つであり、IT システムを展開する方法のパラダイムを今後数年間で変化させる可能性を秘めた動きでもあります。ただし、サーバーの仮想化は、サーバーやシステムの利用に関する IT 管理者やアーキテクトの考え方を変化させるだけでなく、ますます動的になっていくことが確実な環境を管理するために使用されるプロセスやツールにも、影響を与えるでしょう。
仮想化が登場してからかなりの期間がたちましたが、仮想化テクノロジはまだ進化を続けています。実際、いまだに "仮想化" という言葉自体の意味するものは人によって異なります。ただし、広い意味では、仮想化とはテクノロジ スタックの 1 つの層をその次の層から分離する (たとえば、サーバーから記憶域を分離する、アプリケーションから OS を分離する) ことです。さまざまな層を分離すると、統合を行ったり、管理容易性を強化したりできるようになります。
概念としては、仮想化は、記憶域、ネットワーク、サーバー、アプリケーション、およびアクセスに適用されます。記憶域とネットワークに関して言えば、仮想化の目的は、リソースのプール全体を 1 つのエンティティとして扱うことができるように、また、リソースのプール全体が 1 つのエンティティとして機能するように、さまざまなデバイスを統合することです。たとえば、2 TB の記憶装置 20 個の代わりに、40 TB の記憶域ソリューション 1 つを構成できます。ただし、記憶域とネットワーク以外のコンポーネントに関して言えば、仮想化は逆向きに機能し、仮想化によって 1 つのシステムを複数のシステムであるかのように扱うことができます。この最も一般的な例が、サーバーの仮想化です。サーバーの仮想化を行うと、複数の OS インスタンスや環境を 1 台のサーバーでホストできます。
マイクロソフトは、デスクトップからデータセンターに至るまでのさまざまなレベルで仮想化に取り組み、サーバーの仮想化、アプリケーションの仮想化、プレゼンテーションの仮想化、およびデスクトップの仮想化を対象としたソリューションを提供してきました。これらすべてに共通する特徴は、Microsoft System Center を使用して管理することです。この記事では、サーバー仮想化コンポーネントに重点を置いて説明します。特に、Windows Server 2008 の主要な機能である Hyper-V が動的なデータセンターでどのように役立つかについて詳しく説明します。

サーバー仮想化市場
まず、現在何が存在し、市場全体がどこに向かっているのかを確認しておくのは、意味のあることだと思います。数値は調査によって異なりますが、一部のアナリストは、現在販売されているすべての物理サーバーの 5 ～ 9% が仮想化ホストとして使用されていると推定しています。皆さんはこれを、市場に出回っているシステムのかなりの部分だとお考えになるかもしれません。市場には、毎年 900 万台を超える物理サーバーが出荷されています。でも、確かなことが 1 つあります。それは、仮想化に詳しくなり、仮想化を導入しようとしているユーザーが増えているので、まだ市場が拡大される可能性が大きく残されていることです。
仮想化がどのような環境で導入されているのかを確認しておくことは重要です。もちろん、大企業は、先頭に立ってテストや早期の導入を行ってきました。ただし、仮想化を展開している中小企業も存在します。仮想化の導入は、ビジネス アプリケーションや管理から Web や電子メールに至るまで、さまざまな種類のワークロードに及んでいます。
では、なぜ仮想化は現在これほどまでに流行しているのでしょうか。これにはいくつかの要因がありますが、その中でもタイミングという要因が占める割合は少なくありません。いくつかの主要な産業要因が重なり、仮想化の導入増加が促進されました。これらの要因には、64 ビット コンピューティングへの移行、マルチコア プロセッサ、システムのより効率的な利用を目指した持続可能なコンピューティングの推進などがあります。
システムの規模ははるかに大きくなっており、システムの能力を最大限に利用するには仮想化のようなテクノロジが必要になっています。システムが利用できるレベルを超えた処理能力を生み出すという点で、主要なテクノロジ (およびムーアの法則) が常に重要な役割を果たしてきたのは事実ですが、現在は、環境に与える影響、必要な電力、および冷却コストへの意識も以前より高くなっています。
これらすべての要因、および仮想化を導入すると投資収益率 (ROI) が向上するというわかりやすい理由によって、大規模な企業と小規模な企業の両方で仮想化の導入が促進されるでしょう。そして私たち IT プロフェッショナルは、すべての主要企業が今後数年間にわたってこのテクノロジへの投資を継続し、機能を強化することを期待できます。

サーバーの仮想化のしくみ
大まかに言えば、サーバーの仮想化を使用すると、1 つの物理デバイスに、提供される ID やアプリケーション スタックなどが異なる複数の OS 環境 (異なる OS どうしでも可) をインストール (さらに同時に実行) できます。Hyper-V は、信頼性が高くスケーラブルなプラットフォーム機能を提供する、次世代の 64 ビット ハイパーバイザ ベースの仮想化テクノロジです。System Center と組み合わせると、物理リソースと仮想リソースの両方に対応した 1 組の統合型管理ツールとなります。
これらすべての機能によって、コストの削減、システムのより効率的な利用、インフラストラクチャの最適化、および企業での新しいサーバーの迅速な準備が実現されます。Hyper-V のアーキテクチャに関する理解を深めていただくために、まずは、異なる種類の仮想化ソリューションについて見ていきましょう。

仮想化ソリューションの種類
サーバーの仮想化に使用される一般的なアーキテクチャは、基本的に 3 つあります (図 1 参照)。根本的な違いは、仮想化層と物理ハードウェアの関係に関する違いです。仮想化層は、ここでは仮想マシン モニタ (VMM。Virtual Machine Manager と混同しないように注意してください) と呼ばれるソフトウェアの層を示します。同じハードウェア リソースを基盤として使用する複数の分離されたインスタンスを作成できるのは、この層が存在するためです。
図 1 仮想化の 3 つのアーキテクチャ (画像をクリックすると拡大表示されます)
タイプ 2 VMM アーキテクチャの良い例は、Java 仮想マシンです。このアーキテクチャにおける仮想化の目的は、プロセスがホスト システムに依存することなく一連の処理を実行できるランタイム環境を作成することです。この場合、プロセスごとに分離が行われるので、OS との依存関係を気にすることなく 1 つのアプリケーションを別々の OS で実行できます。サーバーの仮想化は、このカテゴリには分類されません。
タイプ 1 VMM とハイブリッド VMM は、現在最も目にすることが多い、幅広く使用されている 2 つのアプローチです。ハイブリッド VMM では、VMM がホスト OS と並列に実行され、仮想マシンを最上位に作成するための基盤となります。ハイブリッド VMM の例は、Microsoft Virtual Server、Microsoft Virtual PC、VMware Workstation、および VMware Player です。このようなソリューションは、仮想マシンをあまり実行しないクライアント シナリオには適していますが、ハイブリッド VMM はオーバーヘッドの大幅な増加を引き起こすので、リソースを大量に消費するワークロードには適していません。
タイプ 1 VMM アーキテクチャでは、VMM 層はハードウェアのすぐ上の層で実行されます。これは、よくハイパーバイザ層と呼ばれます。このアーキテクチャは、もともとは 1960 年代に IBM によってメインフレーム システム用に設計されましたが、最近では、Windows Server 2008 Hyper-V などのさまざまなソリューションが提供され、x86 プラットフォームや x64 プラットフォームでも使用できるようになりました。
ハイパーバイザがファームウェアの一部として組み込まれたソリューションも提供されています。ただし、これはパッケージ化という単なるオプションで、基盤となるテクノロジは変わりません。
タイプ 1 VMM について考えると、基本的に、ハイパーバイザ ソリューションを設計するための主な 2 つの方法は、マイクロカーネルとモノリシックです。図 2 に示すように、これら 2 つのアプローチはどちらも、ハイパーバイザが物理ハードウェアに直接インストールされる真のタイプ 1 VMM です。
図 2 ハイパーバイザ ソリューションの 2 つの設計方法 (画像をクリックすると拡大表示されます)
モノリシック ハイパーバイザのアプローチでは、ハイパーバイザ (VMM) がホストされる 1 つの層に、必要なコンポーネントのほとんど (カーネル、デバイス ドライバ、I/O スタックなど) が含まれています。これは、VMware ESX や従来のメインフレーム システムなどのソリューションで使用されるアプローチです。
マイクロカーネルのアプローチでは、主要タスクであるパーティションの分離とメモリの管理のみを実行する、非常に軽量な専用のハイパーバイザが使用されます。この層には、I/O スタックやデバイス ドライバは含まれません。これは、Hyper-V で使用されるアプローチです。このアーキテクチャでは、仮想化スタックとハードウェアに固有のデバイス ドライバが、親パーティションと呼ばれる専用のパーティションに格納されます。

Windows ハイパーバイザ
複数の OS 間の分離は、仮想プロセッサ、仮想メモリ、仮想タイマ、および仮想割り込みコントローラを作成することによって実現されます。OS は、対応する物理リソースを使用する場合と同じように、これらの仮想リソースを使用します。
Hyper-V の一部である Windows ハイパーバイザは、次のタスクを実行します。
  • 論理パーティションを作成します。
  • ゲスト OS で使用されるメモリとプロセッサのスケジュールを管理します。
  • 入出力を仮想化してパーティション間の通信を行うためのメカニズムを提供します。
  • メモリ アクセスに関する規則を適用します。
  • CPU 使用率に関するポリシーを適用します。
  • ハイパーコールと呼ばれる単純なプログラマティック インターフェイスを公開します。
Windows ハイパーバイザでは、マイクロカーネルのアプローチが使用されるので、サイズはかなり小さく、1 MB 未満になります。このようにサイズを最小限に抑えることによって、システム全体のセキュリティを強化できます。
Hyper-V を実行するための要件の 1 つは、Intel VT テクノロジまたは AMD-V テクノロジが実装された x64 システムです。x64 テクノロジを使用すると、アクセスできるアドレス空間の範囲が広がるだけでなく、より多くのメモリが搭載されたシステムをサポートできるようになります。また、1 つのホスト システムで実行できる仮想マシンの数が増加します。Intel VT と AMD-V はハードウェアに依存する仮想化ソリューションで、非常に高度な特権が与えられた層をリング アーキテクチャ内で提供します。これらのテクノロジは、ハイパーバイザの実行環境をシステムの残りの部分から分離するのに役立ちます。また、エミュレーションのパフォーマンスを大幅に低下させることなく、変更されていないゲスト OS を Hyper-V で実行できます。

親パーティション
Hyper-V は、1 つの親パーティションで構成されます。これは基本的に、特殊なアクセスまたは特権アクセスが許可された仮想マシンです。これは、ハードウェア リソースに直接アクセスできる唯一の仮想マシンです。その他の仮想マシン (ゲスト パーティションと呼ばれます) はすべて、親パーティションを経由してデバイスにアクセスします。
ユーザーが親パーティションの存在を意識することはほとんどありません。Hyper-V のインストールを開始するには、まず Windows Server 2008 x64 Edition を物理システムにインストールする必要があります。次に、サーバー マネージャを起動し、Hyper-V の役割を有効にして、システムを再起動する必要があります。システムが再起動したら、まず Windows ハイパーバイザが読み込まれ、次にスタックの残りの部分が親パーティションに変換されます。
親パーティションは、キーボード、マウス、ビデオ ディスプレイなど、ホスト サーバーに接続されているデバイスの所有権を持ちますが、ハイパーバイザによって使用されるタイマや割り込みコントローラを直接制御することはできません。
親パーティションには、仮想化環境のあらゆる側面の管理を容易にする Windows Management Instrumentation (WMI) プロバイダ、および子パーティションの代わりにハードウェア関連のタスクを実行する仮想化スタックが含まれます。また、ホスト システムのハードウェアに必要な独立系ハードウェア ベンダ (IHV) のドライバもすべて含まれており、Windows Server 2008 x64 エディション用に作成されたドライバはすべて親パーティションでも適切に動作します。

デバイス共有アーキテクチャ
Hyper-V の革新的なアーキテクチャ コンポーネントの 1 つは、エミュレートされた統合デバイスを各ゲスト OS でサポートする新しいデバイス共有アーキテクチャです。デバイスのエミュレーションは、旧世代のハードウェア用に設計されたデバイス ドライバを使用する旧バージョンの OS をサポートするのに非常に役立ちます。たとえば、Hyper-V では Intel 21140 ネットワーク アダプタ (多くの旧バージョンの OS が出荷されていた当時は、DEC 21140 ネットワーク アダプタと呼ばれていました) をエミュレートできます。
一般に、デバイスのエミュレーションは低速で、容易に強化できず、スケーラビリティも高くありません。それでもエミュレーションは重要です。エミュレーションを使用すると、ほとんどの x86 OS を Hyper-V 上で実行できるようになるからです。現在、仮想化は、テストと開発を主な対象としたニッチ テクノロジから、運用環境向けの非常に重要なテクノロジに移行しているので、ユーザーは、より大規模なワークロードを実行するために、より高いパフォーマンスを必要としています。そして、エミュレートされたデバイスでは、この高まる要求を満たすことができなくなっています。
これに代わる解決策は、Hyper-V 統合デバイスを使用することです。統合デバイスは、物理デバイスに直接マップされた仮想デバイスです。エミュレートされたデバイスとは異なり、統合デバイスはレガシ ハードウェアをエミュレートしません。Hyper-V のハードウェア共有モデルを使用すると、サポートされるゲスト OS は、対応する物理デバイスが存在しない可能性がある統合デバイスと直接対話できます。これらの OS は、仮想サービス クライアント (VSC) を使用します。VSC は、ゲスト OS 内のデバイス ドライバとして機能します。
VSC は、親パーティションの仮想サービス プロバイダ (VSP) にアクセスするときに、物理ハードウェアに直接アクセスせず、VMBus (高速なメモリ内バス) を使用します。続いて、親パーティションの VSP が、基盤となる物理ハードウェアへのアクセスを管理します (図 3 参照)。統合デバイスの重要なメリットは、VMBus を使用したときのパフォーマンスが、仮想化されていないハードウェア デバイスのパフォーマンスに近いことです。
図 3 VSC は VMBus を使用して VSP にアクセスし、続いて VSP が基盤となる物理ハードウェアへのアクセスを管理する (画像をクリックすると拡大表示されます)

統合コンポーネント
Hyper-V は、1 台のコンピュータで実行されるさまざまなインスタンス間の強力な境界を提供するように構築されています。Hyper-V では、ゲスト OS とホスト OS との間の対話を可能にしたり、サポートされるゲスト OS に追加機能を提供したりするために、統合コンポーネントが提供されます。
Hyper-V の統合コンポーネントでは、次の機能がサポートされます。
  • 時刻の同期
  • ボリューム シャドウ コピー サービス (VSS)
  • ハートビート機能
  • ゲストのシャットダウン
  • キーと値のペアの交換 (ゲスト OS のレジストリにアクセスするために使用します)
  • OS の特定
Hyper-V の機能セット
言うまでもないことですが、仮想化プラットフォームの動作が物理サーバーの動作に近くなるほど、組織では仮想ワークロードを展開および使用しやすくなります。私の考えでは、仮想化プラットフォームのさまざまな機能は 4 つの主要な領域に分類できます。
現在提供されているハイパーバイザ ベースの仮想化ソリューションのほとんどは、機能面ではよく似ています。今後は、総保有コスト (TCO) や使いやすさなどが主要な差別化要因となることが予想されます。また、引き続き管理ソリューションへの投資が行われ、"動的な IT 環境" 構想の実現に向かって管理ソリューションは進歩するでしょう。動的な IT 環境では、インフラストラクチャが柔軟にビジネス要件に対応でき、モデルやポリシーによって自動化や管理の強化が促進されます。

スケーラビリティ
Hyper-V では、マイクロカーネル ハイパーバイザ アーキテクチャを使用することにより、CPU のオーバーヘッドが抑えられるので、ワークロードの仮想化に使用できる CPU 時間が増加します。また、仮想マシンで強力な機能やハードウェア (マルチコア テクノロジ、ディスク アクセスの強化、メモリの増加など) を利用できるので、仮想化プラットフォームのスケーラビリティとパフォーマンスが向上します。
Hyper-V を Windows Server 2008 のその他の機能と組み合わせることにより、ほとんどのワークロード (32 ビット ワークロードと 64 ビット ワークロードを含む) を 1 つのシステム上に集約できます。また、Hyper-V を使用すると、64 ビット テクノロジの導入と、既に環境全体で使用されている 32 ビット ワークロードのサポートの継続を両立させることができます。
64 ビットのホスト システムと、ハードウェアに依存する仮想化が必要であるという Hyper-V の仕様により、ホスト システムは大きなメモリ リソースのプールにアクセスできます。Hyper-V は、ホストで最大 1 TB のメモリをサポートでき、仮想マシンごとに最大 64 GB のメモリをサポートできます。これは、Exchange Server や SQL Server など、メモリを大量に消費するワークロードの仮想化を考えているユーザーにとっては重要です。
また、Hyper-V は、ホスト システムで最大 16 個の論理プロセッサをサポートしているので、2 つまたは 4 つのソケットを持つほとんどの一般的なマルチコア システムに拡張できます。マルチプロセッサ機能を必要とする (または利用する) ワークロードをサポートするために、最大 4 つの仮想プロセッサが搭載された仮想マシンを作成することもできます。
Hyper-V を使用してサーバーを統合すると、統合されたサーバーでは、VLAN、ネットワーク アドレス変換 (NAT)、ネットワーク アクセス保護 (NAP) ポリシー (検疫) などの堅牢なネットワーク サポートも利用できるようになります。また、Hyper-V は Windows Server 2008 の機能なので、Windows Server の他の機能 (BitLocker や Windows PowerShell など) と適切に連携します。

高可用性
高可用性は、Hyper-V とホストのクラスタリング機能が連携することによって、ビジネスの継続性と障害回復に関する要件に対処できるシナリオです。ビジネスの継続性とは、予定されたダウンタイムと予定外のダウンタイムの両方を最小限に抑える能力のことです。これらのダウンタイムには、メンテナンスやバックアップなどの日常的な作業に費やされる時間や、予期せぬ停電も含まれます。
障害回復は、ビジネスの継続性を構成する重要な要素です。自然災害や悪意のある攻撃だけでなく、構成上の単純な問題 (ソフトウェアの競合など) が発生した場合でも、管理者が問題を解決してデータを復元するまで、サービスやアプリケーションが正常に動作しなくなることがあります。信頼性の高いビジネスおよび障害回復戦略とは、データの損失を最小限に抑え、強力なリモート管理機能を提供できる戦略です。
高可用性について考えるときは、予定されたダウンタイム、予定外のダウンタイム、およびバックアップという 3 つのカテゴリを検討する必要があります。通常、予定されたダウンタイムによる影響は回避する必要があります。その理由は、仮想マシンをホスト システムから別の場所に移動して、ハードウェアのメンテナンスを行ったり、ホスト システムや仮想化プラットフォームに更新プログラムを適用したり (再起動が必要となる可能性があります) する必要があるからです。
ほとんどの組織では、予定されたメンテナンス時間帯が設けられています。ここで本当に期待されるのは、メンテナンスでホスト システムがダウンしている間に仮想マシンを使用できない時間を最小限に抑えるか、その時間をなくすことです。Quick Migration (クイック移行) 機能を使用すると、実行中の仮想マシンをある物理ノードから別の物理ノードにわずか数秒で移行できます。そのため、元のホストのメンテナンス中も、仮想マシンを運用環境で使用し続けることができます。メンテナンスが完了したら、Quick Migration を使用して、仮想マシンを元のホスト システムに戻すことができます。
予定外のダウンタイムとは、不測のダウンタイムのことです。たとえば、自然災害や、単純にだれかが間違って電源コードを抜いたことによってサーバーがダウンした場合が考えられます。信じられないかもしれませんが、私は長年の間に、Tech•Ed、VMworld、およびその他のカンファレンスで、多くの管理者から、同僚がサーバーの電源を間違って切ってしまったという体験談を聞きました。
Hyper-V を使用すると、さまざまなホスト システムから成るホスト クラスタを設定し、すべての仮想マシンをクラスタ リソースとして構成できます。これにより、いずれかのホストで障害が発生した場合、別のシステムにフェールオーバーできるようになります。また、Windows Server 2008 のマルチサイト クラスタリング機能を使用すると、プライマリ データセンターで障害が発生した場合にさまざまな仮想マシンをリモート データセンターに回復できるように、地理的に分散したクラスタを設定できます。
これは、すべてのブランチ オフィスを保護する場合にも役立ちます。Hyper-V で予定外のダウンタイムがサポートされるメリットの 1 つは、ゲスト OS への依存が発生しないことです。つまり、高可用性のメリットを Linux 仮想マシンや旧バージョンの Windows Server でも得ることができ、それらのシステムも同様に保護および回復できます。
予定外のダウンタイムについて考えるときは、回復によって得られる効果がシステムの電源を切って再起動した場合と同等であること、つまり回復を行うと状態情報がすべて失われることに注意してください。これが問題となるかどうかは、仮想マシンで実行するワークロードによって決まります。バックアップを高可用性と関連付けて考えることが重要なのは、そのためです。
Hyper-V を使用すると、仮想マシンの実行中に、各仮想マシンのバックアップを作成したり、VSS を使用して、VSS に対応したすべての仮想マシンの一貫性のあるバックアップを作成したりできます。VSS を使用すると、予定外のダウンタイムが発生した場合に状態を容易に回復できる継続的なバックアップ計画を用意できるだけでなく、運用環境のワークロードの可用性に影響を与えずに、指定された間隔でバックアップが実行されるように設定できます。Hyper-V を使用した高可用性ソリューションの詳細については、今月号の TechNet Magazine で Steven Ekren が執筆した記事「Hyper-V の高可用性を実現する」(technet.microsoft.com/magazine/cc837977) を参照してください。

マイクロカーネル ハイパーバイザ アーキテクチャは、攻撃を受ける確率を最小限に抑え、セキュリティを強化するように設計されています。Hyper-V が Server Core の役割として実装されている場合は特に、攻撃を受ける確率が低下し、セキュリティが強化されます。Server Core は、Windows Server 2008 のインストール オプションです。ハイパーバイザにはデバイス ドライバやサードパーティ製のコードが含まれないので、より軽量で安定性が高く、セキュリティで保護された仮想マシンの実行基盤が提供されます。また、Hyper-V を使用すると、Active Directory 統合によって強力な役割ベースのセキュリティが提供されます。そのうえ、Hyper-V を使用すると、仮想マシンでハードウェア レベルのセキュリティ機能 (NX ビット (execute disable bit) など) を使用できるので、仮想マシンのセキュリティをさらに強化できます。
Hyper-V は、他の Windows Server コンポーネントと同様に、セキュリティ開発ライフサイクル (SDL) を通じて開発されており、Hyper-V を高度なセキュリティで保護された仮想化プラットフォームにするために、脅威のモデル化と分析が幅広く行われています。Hyper-V を展開するときは、Windows Server 2008 の展開に関するベスト プラクティスと、Hyper-V の展開に関するベスト プラクティスに従います。また、計画には Active Directory だけでなく、ウイルス対策ソリューションとマルウェア対策ソリューションも含めます。さらに、委任された管理機能を使用して、Hyper-V ホストに対する管理者のアクセス特権を適切に使用します。

管理容易性
サーバーのちょっとした分散が、仮想マシンの大規模な分散という問題を引き起こすことはよくあります。これは、仮想マシンの展開が非常に容易であることが原因で発生するリスクです。また、仮想マシンのモビリティが向上したので、ユーザーには、さまざまな仮想マシンが実行されている場所を正確に把握したり、仮想マシンのセキュリティ コンテキストを追跡したりする責任が新たに課せられています。
さいわい、Hyper-V を使用すると、仮想環境用に別の管理インフラストラクチャを作成する必要がなくなります。Hyper-V は、マイクロソフトの管理ツール、System Center Virtual Machine Manager、Microsoft System Center Operations Manager、およびサードパーティ製の管理ツールと統合されます。そのため、すべての物理リソースと仮想リソースを 1 つのコンソールから管理できます。System Center Virtual Machine Manager 2008 の詳細については、今月号の TechNet Magazine で Edwin Yuen が執筆した記事「VMM 2008 を使用して仮想環境を管理する」(technet.microsoft.com/magazine/cc836456) を参照してください。また、Windows PowerShell のサポートにより、容易にタスクを自動化できます。
Hyper-V を使用すると、仮想マシンで、ハードウェアをかつてないほど効率的に利用できます。また、Windows Hardware Quality Lab (WHQL) 認定ドライバをすべて親パーティションで実行できるので、広範なドライバやデバイスに互換性が提供され、環境内で実行されるさまざまなドライバの管理が容易になります。

まとめ
前述のとおり、管理は開発と差別化が発生する主要な領域となることが予想されます。今後、この領域で多くの取り組みが行われるのは間違いないでしょう。全体的に考えて、仮想化がより中心的な役割を果たすようになってきた今は、非常におもしろい時代です。まだ Hyper-V を試したことがない場合や、Hyper-V の詳細を確認するには、microsoft.com/Hyper-V を参照してください。
Rajiv Arunkundram は、マイクロソフトでシニア プロダクト マネージャを務めており、Windows Server マーケティング部門でサーバーの仮想化に関する業務に携わっています。Rajiv の主な仕事は、顧客やパートナーがマイクロソフトの仮想化戦略と仮想化ソリューションを技術的およびビジネス的な観点から理解できるよう支援することです。


仮想化
VMM 2008 を使用して仮想環境を管理する
Edwin Yuen

この記事は、Virtual Machine Manager 2008 のプレリリース版に基づいています。ここに記載されているすべての情報は、変更される場合があります。
概要 :
  • VMware VM のサポート
  • Windows PowerShell ベースのスクリプト作成と自動化
  • 統合、一元管理
  • インストール手順

目次
Virtual Machine Manager 2008 の概要
System Center との統合
Virtual Machine Manager 2008 のインストール
VMware ESX ホストの追加
VMotion による移行
まとめ
昨年、マイクロソフトは System Center Virtual Machine Manager 2007 を発表しました。この製品は、Microsoft Virtual Server 2005 を実行する仮想インフラストラクチャを管理するための統合型インターフェイスを提供する新しいソリューションです。そしてこのたび、新しい Windows Server 2008 Hyper-V ハイパーバイザのリリースに合わせて、Virtual Machine Manager (VMM) の新バージョンがリリースされました。System Center Virtual Machine Manager 2008 では、Microsoft Virtual Server 2005 と Windows Server 2008 Hyper-V を管理できるだけでなく、サポートが拡大されて VMware Infrastructure 3 (ESX/ESXi) サーバーにも対応しています。VMM では、マイクロソフトのシステムと VMware システムを含む仮想インフラストラクチャ全体を操作できる統合型の管理インターフェイスが提供されます。
VMM は、テンプレートや構成済みの VM を使用した迅速なバーチャル マシン (VM) 展開、物理-バーチャル (P2V) 変換、仮想インフラストラクチャ オブジェクトの一元的なライブラリだけでなく、VMware バーチャル マシン (VMX 構成ファイルおよび VMDK 仮想ディスク) から Hyper-V VM へのバーチャル-バーチャル (V2V) 変換も含む従来の仮想化作業をすべてサポートしています。さらに、他の System Center ファミリとの統合によって、物理システムと仮想システムの一元管理を実現しています。
この記事では、VMM 2008、および IT 管理者が利用できる VMM の新機能について説明します。その後、VMM のインストール要件とインストール手順について説明します。また、VMM 2008 のいくつかの新機能の使用方法について詳しく説明します。

Virtual Machine Manager 2008 の概要
System Center Virtual Machine Manager 2008 は、Microsoft Virtual Server 2005 R2 SP1、Windows Server 2008 Hyper-V、Microsoft Hyper-V Server 2008、および VMware Infrastructure 3 (ESX/ESXi) サーバーの下で実行されるバーチャル マシンの一元管理機能をエンタープライズ レベルで提供するスタンドアロン アプリケーションです。VMM は他の System Center 製品と連携することで、物理インフラストラクチャと仮想インフラストラクチャの管理をエンド ツー エンドで提供します。図 1 は、Virtual Machine Manager のアーキテクチャを示しています。
図 1 System Center Virtual Machine Manager 2008 のアーキテクチャ (画像をクリックすると拡大表示されます)
VMM 2007 をご存知の方はお気付きになると思いますが、VMM 2008 では VMM システム用のインターフェイスが大幅に増加しています (図 1 参照)。左上にある四角形は VMM 2008 を、右上にある四角形は System Center Operations Manager 2007 を、下の部分は管理対象のシステムとインターフェイスを表しています。また、赤い四角形は管理サーバーを、青い四角形はシステム入力を、緑の四角形は管理対象のホスト システムを、黄色の四角形はこれらのホスト システムの管理対象オブジェクトを示しています。
左上にある赤い四角形は、Virtual Machine Manager 2008 サーバー サービスを表しています。その上には、管理者コンソール、Windows PowerShell インターフェイス、およびユーザー アクセスを委任できるセルフサービス Web ポータルという 3 種類のサービス インターフェイスが位置しています。Windows PowerShell は、VMM サーバーへのあらゆるアクセスの基盤となります。VMM 管理者コンソールは、完全に Windows PowerShell を基に構築されているため、VMM サーバー サービスによって実行される Windows PowerShell スクリプトを簡単に作成できます。つまり、VMM 2008 のパブリック API は Windows PowerShell であるため、どのようなプログラムでも Windows PowerShell を使用して VMM を活用できます。これを示す良い例は、Citrix の XenDesktop Desktop Delivery Controller と Virtual Machine Manager との統合です。これは Windows PowerShell のみを使用して実現できます。
VMM を支えるのは、SQL Server 2005 または SQL Server 2008 データベース (完全インストールか、他のデータベースが利用できない場合は SQL Server Express Edition) です。図では Operations Manager と Virtual Machine Manager の両方から SQL Server に向かって矢印が描かれていますが、この 2 つのプログラムがデータベースを共有するわけではありません。単に、同じバージョンの SQL Server 上で実行されるということです。Virtual Machine Manager と Operations Manager の統合は、VMM で提供されるコネクタによって実現されます。このコネクタを使用すると、VMM と OpsMgr でデータを共有できるため、仮想化に関する情報を OpsMgr に格納し、OpsMgr のデータを VMM で利用できます。
図の下半分は、管理対象のホストを表しています。VMM 2008 でも、VMM 2007 の場合と同様に、Virtual Server 2005 R2 SP1 バーチャル マシン ホストと一元的なライブラリ共有が管理されます。VMM では、このライブラリ共有は特殊なファイル ストアやサーバーではないことに注意してください。これは、VMM によって管理される Windows ファイル共有にすぎません。このライブラリは VMM から管理することも、単純にファイル共有からファイルをコピーおよび削除して、VMM で自動的に変更を検出することもできます。また、複数のライブラリを作成できるため、一連の委任サーバーやリモート オフィスのサーバーがある場合に役立ちます。
VMM 2008 の新機能として、Hyper-V および ESX ハイパーバイザの管理機能があります。Hyper-V ホストの管理は Windows リモート管理 (WinRM) および Windows Management Instrumentation (WMI) インターフェイスを使用して行います。実際、Hyper-V ホストになる可能性があるホストが追加されると、Windows Server 2008 で Hyper-V の役割が有効になっていない場合、VMM は管理者に代わって自動的にこの役割を有効にすることができます。この機能は、Windows Server 2003 システムの Virtual Server ホストになる可能性があるホストにも提供されます。
VMware VI3 ESX ホストの管理は、実際には VMware VirtualCenter サーバーを介して行います。VMM 2008 は、VirtualCenter Web サービス API を介して VirtualCenter と連携します。したがって、VMware の管理には VirtualCenter サーバーが必要ですが、エンタープライズ レベルの VMware には、ほとんどの場合 VirtualCenter サーバーが少なくとも 1 つ含まれます。VMM 2008 のみで提供される機能としては、複数の VirtualCenter サーバーを管理できる機能があります。VMM では複数の VirtualCenter サーバーを追加できるため、管理者は VMware インフラストラクチャ全体を集約して、これまでは不可能であったエンタープライズ レベルの一元管理を実現できます。
System Center ファミリ製品の 1 つである VMM では、管理者コンソールに System Center や Outlook のようなインターフェイスを使用します。VMM 管理者コンソールは MMC スナップインではなく、Microsoft .NET Framework を使用して構築されたまったく新しいアプリケーションで、Windows PowerShell 1.0 を基盤としています。実際、前述のとおり、管理者コンソール上で操作を行うと、関連する Windows PowerShell コマンドが呼び出されます。つまり、この UI は実際には Windows PowerShell を使用しています。管理者コンソール上で実行されるコマンドや関数は、Windows PowerShell でコマンド ラインを使用して実行することもできます。
管理者コンソールの各ウィザードには、実行するコマンドに関連付けられた Windows PowerShell スクリプトを表示する [スクリプトの表示] ボタンも用意されています。この機能は、Windows PowerShell の VMM に関連する部分について学習するときに役立ちます。VMM 2008 の新機能として、[スクリプトの表示] ではスクリプトをメモ帳で開いて、VMM から直接簡単にスクリプトを編集できるようになりました。編集したスクリプトを簡単に保存し、VMM 2008 で提供されるもう 1 つの新機能である VMM ライブラリから再利用することもできます。VMM 2007 のコマンドレットは VMM 2008 向けに更新され、VMware サーバーのサポートが追加されました。1 つのコマンドレットを複数の仮想化プラットフォームにまたがって使用できます。たとえば、New-VM などのコマンドレットをマイクロソフトのシステムと VMware システムの両方で使用できます。したがって、IT 管理者は 1 つのコマンドレット セットのみを使用して、Virtual Server、Hyper-V、および VMware ESX ホストを管理できます。
IT 管理者は、Virtual Machine Manager 2008 を使用すると以下の 3 つの重要なメリットを得ることができます。
  • リソースを最大限に活用できる。
  • 敏捷性を向上させることができる。
  • 既存のスキルを活用できる。
さまざまな機能がこれらのメリットの実現を後押ししています。まず、VMM を使用すると、ハイパーバイザに関係なく仮想インフラストラクチャ全体の管理を統合できるため、リソースを最大限に活用できます。VMM 2008 では、マイクロソフトのシステムと VMware システムを統合し、すべてのホストとバーチャル マシンを 1 つの場所で確認できます (図 2 参照)。また、ホスト、オペレーティング システム、所有者、追加日時などのパラメータを使用してフィルタを適用し、該当するシステムを確認することもできます。
図 2 マイクロソフトと VMware の一元管理を実現する VMM コンソール (画像をクリックすると拡大表示されます)
VMM では、P2V や V2V などの変換を使用した簡単なサーバー統合により、システム リソースを最大限に活用できます。P2V を使用すると、再インストールを行うことなく、既存の物理コンピュータをバーチャル マシンに統合できます。これは特に、ハードウェアの使用率が低いコンピュータを変換する場合に役立ちます。あまり使用されていない複数のコンピュータを 1 つの物理ハードウェアにまとめることによって、リソースを最大限に活用できます。P2V は VMM に組み込まれている機能で、追加のソフトウェアやサーバーを必要としません。VMM 2008 では、Windows Vista、Windows Server 2008、x64 ホストなど、より多くの物理システムのサポートが追加されています。VMM の P2V 機能は、Microsoft Assessment and Planning (MAP) ツールなど、サーバー統合の候補を特定できるプランニング ツールと併用すると非常に便利です (詳細については、今月の TechNet Magazine で Baldwin Ng と Jay Sauls が執筆した記事を参照してください)。
VMware の VMDK 形式のバーチャル マシンが既に存在する場合、V2V を使用して既存の VMDK を VHD 形式に変換できます。これはオフライン処理になるため、V2V プロセスで実際の VMDK ファイルが VHD に変換される間、VMware VM はシャットダウンされている必要があります。また、P2V 機能を使用して、実行中の VMware VM を変換することもできます。少しややこしいかもしれませんが、バーチャル マシンはまず何よりもコンピュータであり、それを前提に仮想化が実現されることを理解する必要があります。すべてのシステムは VM を実行中のコンピュータであると見なしますが、これは VMM の P2V 機能も同様です。このため、仮想化ソフトウェアを実行している VM をマイクロソフトの VHD に変換できます。
VMM は、いくつかの機能を通じて、IT 管理者に優れた敏捷性を提供します。VMM によって提供される主な機能の 1 つは、ホスト間での VM の移行です。この機能は、高可用性とサーバーの最適な状態を維持するのに役立ちます。Hyper-V ホストに関しては、VMM 2008 ではわずか数秒のダウンタイムの間に Hyper-V 間で VM を移行できる Quick Migration (クイック移行) がサポートされます。これには Windows Server 2008 クラスタと共有記憶域が必要ですが、VMM を使用すると管理と構成を簡単に行うことができます。
VMware ESX ホストに関しては、VMM 2008 では VMware VMotion もサポートされます。これは、ユーザーにダウンタイムを意識させることなく VM を移行できる VMware の機能です。これには、VMotion 対応の VMware ESX ホストと、Quick Migration のようなクラスタおよび SAN バックエンドが必要です。この記事では後ほど、VMM 2008 から VMotion を使用する手順について説明します。
また、VMM 2008 では既存の Virtual Server 2005 VM を Hyper-V ホストに移行できます。移行に必要なすべてのアップグレードと変換は、自動的に実行されます。
VMM では、変換を基に展開を行う場合も、新規展開を行う場合も、上記の移行を含むあらゆる VM 展開の一環として、ホストへの VM の展開に Intelligent Placement (インテリジェント配置) という処理を使用します。また、VMM は Intelligent Placement を使用して、VMM が管理しているすべてのバーチャル マシンを照会し、各ホスト上で利用できるリソースの状況に関するいくつかのパラメータを取得して、これらを考慮したうえで VM を展開できる推奨ホストの一覧を返します。図 3 に示すように、Intelligent Placement はマイクロソフトのホストと VMware ホスト、およびそれらの記憶域構成をサポートします。VMM 2008 の Intelligent Placement は、プラットフォームの種類も、構成の種類も認識します。したがって、正しいホスト プラットフォームであると見なされるホストのみが推奨されます。たとえば、高可用性が必要な場合はクラスタ化されているホストのみ、x64 VM には x64 対応ホストのみが推奨されます。
図 3 すべての利用可能なホストを分析する Intelligent Placement (画像をクリックすると拡大表示されます)

System Center との統合
VMM 2008 の重要な機能の 1 つは、System Center Operations Manager 2007 との統合です。VMM 2007 でも Operations Manager との統合がある程度実現されましたが、VMM 2008 にはこの統合機能を大幅に強化する、Operations Manager 用の製品コネクタが付属しています。VMM では、Operations Manager との統合、および Performance and Resource Optimization (パフォーマンスとリソースの最適化、PRO) という新機能を使用して、統合された Operations Manager のレポートを管理者コンソールから確認できます。
VMM 2008 では、PRO を使用して PRO ヒントという警告を作成できるだけでなく、Operations Manager の監視パラメータを基に、自動化された対応処理を実行することもできます。図 4 にいくつかの PRO ヒントの例を示します。VMM 2008 で PRO に対応した管理パック (PRO パック) を使用すると、ホスト、ハイパーバイザ、ハードウェア、さらにはワークロードに基づくパフォーマンス パラメータを基に、VM の移行や新規作成などの自動化された操作を実行できます。
図 4 仮想アーキテクチャで発生する問題の警告や対応処理を提供する PRO ヒント (画像をクリックすると拡大表示されます)

Virtual Machine Manager 2008 のインストール
System Center VMM 2008 のインストールを実行するには、いくつかの前提条件と新しいシステム要件を満たす必要があります。まず、VMM 2008 サーバーには Windows Server 2008 x64 が必要です。VMM 2008 サーバーは、Windows Server 2003 または x86 バージョンの Windows Server 2008 にはインストールできません。ただし、管理者コンソールやその他のコンポーネントは Windows Server 2003 および Windows XP または Windows Vista (コンソールのみ) にインストールでき、インストールの要件と手順は VMM 2007 と同じです。
また、VMM 2008 は Active Directory ドメインにインストールする必要があります。これは、VMM のセキュリティ モデルに準拠するために必要です。VMM 2008 では、境界ネットワークの (ドメインに参加していない) ホストの管理もサポートされます。これには、VMM 2008 の新機能である、ドメインに参加していないシステムの P2V も含まれます。インストール プラットフォームに Windows Server 2008 を使用するメリットの 1 つは、VMM の前提条件となるコンポーネント (.NET Framework 3.0、WinRM、および Windows PowerShell 1.0) が既に組み込まれていることです。さらに、VMM 2008 には Windows 自動インストール キット (WAIK) 3.0 が必要です。ただし、VMM 2008 インストーラにはこのインストール ファイルが含まれています。
運用環境では、各 VMM コンポーネントを別々の運用サーバーにインストールすることをお勧めしますが、ここでは 1 台のサーバーにインストールする場合の手順を説明します。VMM をインストールするサーバーのハードウェア構成として推奨されるのは、x64 ベースのサーバーに 2.8 GHz 以上の CPU と 2 GB 以上の RAM が搭載された構成です。ここでは、1 台のサーバーに VMM をインストールし、ローカルの SQL Server データベースを使用するため、7 GB のハード ディスク領域が必要です。リモート データベースを使用する場合は、1 GB あれば VMM をインストールできます。ローカルにライブラリをインストールする場合は、さらに 80 GB のディスク領域を確保することをお勧めします。
前述のとおり、VMM は Windows Server 2008 x64 上で動作します。その他のソフトウェア要件は、セルフサービス ポータルの場合、.NET Framework 3.0、Windows PowerShell 1.0、WinRM、および IIS 6.0 以降です。Microsoft MSXML 6.0 パーサーも必要ですが、これは .NET Framework 3.0 に含まれています。
VMM のインストールを開始すると、5 種類のオプションが表示されます。これらは、Virtual Machine Manager サーバー、管理者コンソール、セルフサービス ポータル、ローカル エージェント、および Operations Manager 管理パックを構成するオプションです。前述のとおり、ここではすべてのコンポーネントを 1 台のコンピュータにインストールします。まず、VMM サーバーからインストールします。セットアップが開始されると、最初の画面でシステム要件が確認されます。
前述の要件に加えて、コンピュータがドメインに参加している必要があります。VMM サーバーをインストールすると、自動的に組み込みの機能が有効になるため、手動でそれらの機能を有効にする必要はありません。
インストーラを起動したら、Windows Update オプションを使用して、VMM 2008 が最新の状態であるかどうかを確認することをお勧めします。その後、主に SQL データベースのインストールに関するオプションがインストーラによって確認されます。この例では、SQL Server 2005 Express Edition を使用します。
次に、一元管理するライブラリの場所を指定するよう求められます。ここでは、VMM サーバー上のローカル ディレクトリを指定することも (このディレクトリに共有が作成されます)、既存のファイル共有を指定することもできます。既定の場所は、C:\ProgramData\Virtual Machine Manager Library Files です。
次の手順では、ポートを割り当てます。ここでは、管理者コンソールから主要な VMM サーバー サービスへの接続に使用するポート (既定では 8100)、WinRM が管理機能の実行に使用するポート (既定では 80)、およびバックグラウンド インテリジェント転送サービス (BITS) がバーチャル マシン ホストへのファイルの移動に使用するポート (既定では 443) を構成します。これらの情報をすべて入力し終わると、概要ページが表示され、Virtual Machine Manager サーバーのインストールを完了できます。
次は、管理者コンソールをインストールします。管理者コンソールのシステム要件は、VMM サーバーと同様です。インストール ディレクトリ以外に提供される唯一の構成オプションは、VMM サーバー サービスへの接続に使用する通信ポートの確認です。このポートには、VMM サーバーのインストール時に構成したように、8100 を指定する必要があります。
インストールの最後に、管理者コンソールのデスクトップ ショートカットを作成するオプションと、セットアップの終了時に管理者コンソールを起動するオプションが表示されます。どちらのオプションも選択することをお勧めします。初めて管理者コンソールを起動すると、サーバーに接続するよう求められます。1 台のサーバーにインストールする場合、正しい接続先はポート 8100 の localhost です。そのまま Enter キーを押してコンソールを起動します。
最後に、このサーバーにセルフサービス ポータルをインストールします。このポータルの前提条件は、IIS 6.0 または 7.0、.NET Framework 3.0、および Windows PowerShell 1.0 です (Windows PowerShell が必要な理由は、セルフサービス ポータルが、Windows PowerShell を使用する、主要な VMM サービスへの別のインターフェイスであるためです)。Windows Server 2008 の場合は、VMM 2008 のインストールを開始する前に、IIS の役割を有効にする必要があります。そのときに、以下に示す IIS の役割サービスを必ず有効にしてください。
  • HTTP 基本機能 (静的コンテンツ、既定のドキュメント、ディレクトリの参照、HTTP エラー)
  • アプリケーション開発 (ASP.NET、.NET 拡張機能、ISAPI 拡張機能、ISAPI フィルタ)
  • セキュリティ (要求のフィルタリング)
  • IIS 6 と互換性のある管理
これらの役割サービスが有効になると、前提条件の確認に合格し、インストールが続行されます。インストール中に提供される構成オプションは、セルフサービス ポータルによって使用されるポートに関するオプションのみです。最初のオプションは主要な VMM サービスに接続するためのポートで、管理者コンソールの場合と同様に 8100 を指定します。2 番目は、ポータルの実行に使用するポートです。既定ではポート 80 ですが、このポートは多くの構成で既に使用されています。既に使用されている場合、VMM インストーラによって警告メッセージが表示されます。必要に応じて、このポートを使用されていないポート (8080 など) に変更してください。その後、"Microsoft System Center Virtual Machine Manager 2008 Self-Service Portal Home" (Microsoft System Center Virtual Machine Manager 2008 セルフサービス ポータル ホーム) という Web サイトが作成されます。この構成は、サーバー マネージャから変更できます。
IIS のインストールが完了したら、Internet Explorer で localhost:8080 を参照してこの Web サイトを開くことができます。Web サイトを開くときに認証が要求される場合、その原因は Internet Explorer のセキュリティ設定にあります。セルフサービス ポータルは、Internet Explorer のイントラネット コンテキストで実行する必要があります。そのため、Internet Explorer のイントラネット サイトの一覧に VMM サーバーを追加することが必要になる場合があります。これらの構成が完了したら、VMM 2008 でセルフサービスに対応した VM を作成して使用できます。

VMware ESX ホストを追加する
VMM 2008 には多くの新機能がありますが、最も期待されている機能は、VMware ESX ホストの管理のサポートであることはほぼ間違いありません。このサポートが追加されたことにより、大半の企業の IT 部門で、VMM を使用して仮想インフラストラクチャを管理できるようになりました。
ESX ホストを Virtual Machine Manager 2008 に追加するプロセスは、非常に簡単です。前述のとおり、VMM 2008 では VirtualCenter サーバーを使用して VMware を管理します。VirtualCenter サーバーのバージョンは 2.0.1 または 2.5 である必要があります。VMware ESX サーバーを管理コンソールに追加するには、操作ウィンドウの右上にある [VMware VirtualCenter Server の追加] を使用して VirtualCenter サーバーを追加します。
ウィザードが起動したら、VirtualCenter サーバーのコンピュータ名と、VirtualCenter サーバーの管理アカウントを入力します。VMM によって、VirtualCenter の既存のホスト グループ構造も含め、ESX ホストが VMM インターフェイスに追加されます。この作業には数分間かかる可能性がありますが、VMM の [ジョブ] メニューから進行状況を監視できます。
すべてのサーバーがインポートされたら、VirtualCenter の場合と同じ VMware ESX ホスト サーバー構造が VMM 上に表示されます。別の VirtualCenter サーバーを追加するには、このプロセスを繰り返します。ホスト構造が VMM に追加されたら、VMware 以外のサーバーを同じサーバー構造に追加できます。もちろん、VMware 以外のサーバーは VirtualCenter には表示されません。
VMM 2008 では VirtualCenter を使用して ESX ホストを管理しますが、V2V、状態の保存、ESX ホストからの VM の複製などの機能を使用する場合は、VMM 2008 から ESX ホストに直接アクセスできる必要があります。したがって、VirtualCenter サーバーを VMM に追加した後のホストには、[OK (制限あり)] という状態が表示されます。すべての管理機能を有効にするには、VMM で各 ESX ホストのプロパティ ページを表示し、適切なホストの資格情報を指定して直接サーバーを管理できるようにします。

VMotion による移行
Virtual Machine Manager 2008 における VMware の管理について話すときに、必ず質問されることがあります。それは、"VMM では VMotion やその他の VirtualCenter の機能を実行できるか" という質問です。VMM では VMware の管理に VirtualCenter を使用するため、この質問の答えは "はい" となります。
機能的には、VMM は VMotion を他の移行機能と同様に扱います。VMotion を開始するには、まず移行する VM を選択し、VMM の右側にある操作ウィンドウから [バーチャル マシンの移行] を選択します。選択すると、その VM 用の Intelligent Placement ウィンドウが表示され、移行先ホストの候補と、その転送の種類として [ライブ] が表示されます (図 5 参照)。Intelligent Placement は、各 VM に適した移行先ホストの選択に役立ちます。これは、Hyper-V ホストを使用して Quick Migration を実行するプロセスと同じです。
図 5 Intelligent Placement を使用する VMotion (画像をクリックすると拡大表示されます)
VM の移行先ホスト (ここでは cqaesxi003.contoso.com) を選択し、[次へ] をクリックします。最後の概要ウィンドウ (図 6 参照) に、指定した操作が表示されます。
図 6 VMotion の概要ウィンドウ (画像をクリックすると拡大表示されます)
前述のとおり、VMM の各ウィザードには [スクリプトの表示] ボタンがあり、これを使用すると任意のジョブの Windows PowerShell スクリプトをメモ帳に表示できます。これにより、VMM 2008 が Windows PowerShell をどのように使用して VMware を操作しているかどうかを確認できます。ここでの操作のスクリプトは、次のとおりです。
$VM = Get-VM -VMMServer localhost -Name "MyVM" |
  where {$_.VMHost.Name -eq "cqaesxi003.contoso.com"}
$VMHost = Get-VMHost -VMMServer localhost |   where {$_.Name -eq "cqaesxi003.contoso.com"}
Move-VM -VM $VM -VMHost $VMHost –RunAsynchronously
これらの簡単なコマンドによって、このシステムの VMotion が実行されます。この記事の例では、VM MyVM を VMware サーバー cqaesxi003.contoso.com からサーバー cqaesxi001.contoso.com に移行しています。最初のコマンドでは、VMotion を使用してバーチャル マシンを移行することを指定しています。ご覧のとおり、このコマンド ラインではバーチャル マシンの値を変数 $VM に代入しています。
$VM = Get-VM -VMMServer localhost -Name "MyVM" |
  where {$_.VMHost.Name -eq " cqaesxi003.contoso.com"}
2 番目のコマンドでは、VM の移行先となる ESX ホスト システムを指定しています。このコマンド ラインでは、変数 $VMHost を ESX ホスト cqaesxi003.contoso.com に割り当てています。
$VMHost = Get-VMHost -VMMServer localhost | where
  {$_.Name -eq " cqaesxi003.contoso.com"}
最後に Move-VM コマンドを使用して、実際に VM を移行しています。Move-VM の完全なコマンド ラインとパラメータは、以下のとおりです。
Move-VM [-VM] [<String VM>] -VMHost [<String Host>]
  [-JobGroup <Guid>] [-JobVariable <String>] [-Path
  <String>] [-PROTipID] [-RunAsynchronously]
  [-StartVMOnTarget <Boolean>] [-UseLAN <Boolean>]
  [<CommonParameters>]
Virtual Machine Manager の異種管理の考え方を踏まえると、このコマンドはベンダまたはソフトウェア固有のコマンドではないことがおわかりいただけると思います。VMotion を完了するには、次のコマンドを実行します。
Move-VM -VM $VM -VMHost $VMHost –RunAsynchronously
このコマンドでは、$VM に格納されている VM に対して Move-VM を実行することによって、この VM を $VMHost に格納されているホスト システムに移行し、ジョブを非同期で実行するよう VMM に指示しています。ジョブが開始されると、VMM のジョブ ウィンドウからプロセス全体を監視できるようになります。また、この基本コマンドは、Hyper-V クラスタでの Quick Migration にも使用できるほか、LAN ベースの転送を使用する非クラスタ ホストにも使用できます。
ここまで見てきたとおり、System Center Virtual Machine Manager 2008 では、Virtual Machine Manager 2007 の優れた機能が強化され、新しい管理プラットフォームと新機能が追加されています。この記事で紹介した、インストール手順といくつかの機能に関する説明から、VMM 2008 で複数のハイパーバイザの管理をいかに簡単に行うことができるかをご理解いただければさいわいです。
VMM 2008 は、マイクロソフトと VMware の物理システムと仮想システムの両方を統合することで、統合型の仮想化管理ソフトウェアとして機能することを目的としています。この Virtual Machine Manager の新しいバージョンを使用すると、VMware 管理者、Microsoft Virtual Server 2005 管理者、および新しい Hyper-V の管理者すべてが、単一のツール、単一のスクリプト インターフェイス、そして最も重要とされる、仮想インフラストラクチャの単一の管理プロセスを使用できます。

Edwin Yuen は、System Center Virtual Machine Manager の Windows 企業管理部門に所属するテクニカル プロダクト マネージャです。Edwin は、2006 年 7 月の Softricity 社の買収によって、同社からマイクロソフトに移籍しました。また、民間企業と連邦機関の両方で 13 年間技術コンサルティングを担当した経験があり、ジョンズ ホプキンス大学の電気工学士号も取得しています。


仮想化
Microsoft Application Virtualization の概要
Anthony Kinney

この記事は、App-V のプレリリース版に基づいています。ここに記載されているすべての情報は、変更される場合があります。
概要 :
  • App-V のアーキテクチャ
  • 仮想アプリケーションを管理する
  • App-V のシーケンサを使用する
  • App-V と Configuration Manager を統合する

目次
App-V のアーキテクチャ
App-V のフル インフラストラクチャのしくみ
仮想アプリケーションを更新する
シーケンス処理
Version 4.5
Microsoft Application Virtualization 4.5 (別名 App-V) は、私にとって本当に身内のような存在です。以前 SoftGrid と呼ばれていた App-V は私と共に、その SoftGrid を開発した会社である Softricity の買収に伴い、マイクロソフトにやってきました。買収以降、多くの変更が加えられたため、TechNet Magazine でこの記事を執筆する機会が与えられたことを非常に嬉しく思っています。
App-V を理解する最も良い方法は、まずエンタープライズ管理という点で IT プロフェッショナルが直面している課題について話し合うことです。現在のビジネス デスクトップは、アプリケーションで溢れています。アプリケーションをインストールする前に、時間をかけて回帰テストを行い、そのアプリケーションとシステムにインストールされている他のアプリケーションが共存できるかどうか、およびそのアプリケーションが他のアプリケーションの動作に影響を与えないかどうかを確認する必要があります。また、アプリケーションを運用する前に、一連の展開プロセスを行う必要があります。アプリケーションを利用できるのは、基本的にそれがインストールされている場所に限られるため、ユーザーは特定のコンピュータに縛られることになります。これにより、OS やアプリケーションの移行、セキュリティの更新、障害回復計画など、複雑で重要性の高いプロジェクトの複雑さがさらに増します。
App-V によって、そのような状況が一変します。App-V を使用したデスクトップ管理は、複雑で時間がかかり、リソースを消費する一連の手順ではなく、より簡単で自動化されたプロセスです。このため、より簡単にアプリケーションの展開、修正プログラムの適用、更新、および運用停止を行い、より良い結果を得ることができます。
App-V を使用すると、ユーザーはどのデスクトップからでもアプリケーションにアクセスできます。アプリケーションは必要に応じて配信され、実際にローカルにインストールされているかのように動作します。したがって、アプリケーションのコンポーネントをインストールしたり、ホスト デバイスを変更したりする必要はありません。
このような仮想化の使用によって、IT プロフェッショナルのデスクトップ管理が大幅に変わります。ホスト デバイスを変更せずに、仮想化アプリケーションを実行することで、次のようなさまざまなメリットを得ることができます。
  • アプリケーションの競合が減少します。
  • アプリケーションをより短時間で簡単に更新できます。
  • 同じアプリケーションの複数のバージョンを同時に実行できます。
  • ユーザーがオンラインでもオフラインでも柔軟にアプリケーションを使用できます。
  • アプリケーション間の回帰テストが減少します。

App-V のアーキテクチャ
ここでは、App-V プラットフォームで実際にどのような処理が実行されるかについて説明します。このプラットフォームは、いくつかの主要なコンポーネントから構成されます。これらは、シーケンサ、データベース、クライアント、管理サーバー、ストリーミング サーバー、および管理コンソールです (図 1 参照)。
図 1 App-V 環境のレイアウト (画像をクリックすると拡大表示されます)
App-V システムの中心となるのは、App-V クライアントです。ターミナル サーバー クライアントとデスクトップ クライアントの 2 種類を使用できます。どちらの場合でも、すべてのデスクトップと、仮想アプリケーションを展開するターミナル サーバーにクライアントをインストールする必要があります。クライアントに必要なディスク領域は比較的少量です。クライアントによってドライバがインストールされます。また、クライアントには、タスク トレイのインジケータとして表示されるユーザー ランタイム コンポーネントが用意されています。
クライアントは App-V Management Server から仮想アプリケーションの一覧を取得し、利用可能な仮想アプリケーションを表示します。また、これらのアプリケーションの起動 (ユーザーによって起動された場合) と、クライアント側キャッシュの管理を行います。さらに、仮想ランタイム環境の作成を管理し、各環境が専用の仮想バブル内で実行されるようにします。この仮想環境には、仮想レジストリ、仮想ファイル システム、仮想サービス マネージャなど、いくつかのコンポーネントが含まれます。
App-V 4.5 には、フル インフラストラクチャ、ライトウェイト インフラストラクチャ、スタンドアロン モードという 3 種類のインフラストラクチャ展開オプションが用意されています。フル インストラクチャを展開すると、バックエンドには App-V Management Server と App-V Streaming Server (後ほど説明しますが、これは新しいコンポーネントです) が含まれます。App-V Management Server は、一元管理された仮想アプリケーションをホストおよび配信するほか、修正プログラムや更新プログラムが適用された場合に仮想アプリケーションを更新します。
この管理サーバーは、SQL Server を基盤として使用し、App-V データベースをホストします。このデータベースには、仮想アプリケーションの構成と設定が格納されます。仮想アプリケーションの準備とアクセス許可の管理を行う場合は、一元管理ツールとして Active Directory グループを使用することをお勧めします。
App-V プラットフォームでは、設定と構成を管理する目的で、IIS がインストールされていれば同じサーバー上に読み込むことができる Microsoft .NET Framework Web サービスが提供されます。この Web サービスは、Microsoft 管理コンソール (MMC) スナップインである App-V 管理コンソールと App-V データベースとの間のパイプ役として機能します。このコンソールを使用して、仮想アプリケーションの公開や管理、Active Directory グループの割り当て、サーバー設定の管理、仮想化アプリケーションの使用状況に関するレポートの実行を行うことができます (図 2 参照)。
図 2 管理コンソール (画像をクリックすると拡大表示されます)
ライトウェイト インフラストラクチャには、アクティブ アップグレードやパッケージ アップグレードなどのストリーミング機能を提供する App-V Streaming Server が含まれます。このオプションでは、Active Directory や SQL Server は必要ありません。また、デスクトップ構成サービス、ライセンス機能、およびメータリング機能も提供されません。ただし、ライトウェイト インフラストラクチャでは、ストリーミング機能を System Center Configuration Manager (SCCM) やその他のサードパーティ製のエンタープライズ ソフトウェア開発 (ESD) ソリューションに追加できます。
スタンドアロン モードでは、App-V のシーケンサによって、仮想アプリケーションの追加を自動化する MSI ファイルが作成されます (図 3 参照)。この MSI ファイルにはメタデータが含まれ、このデータを使用すると、どの ESD システムでも MSI ファイルを認識し、仮想化アプリケーションを制御できます。このモードでは、クライアントをスタンドアロン モードにする必要があります。このため、仮想アプリケーションの更新に使用できるのは、MSI ベースの更新のみです。また、スタンドアロン モードではストリーミングを利用できません。このモードを使用すると、App-V の分離機能を使用できます。
図 3 App-V のシーケンサ (画像をクリックすると拡大表示されます)
MSI ファイルは非常に柔軟性が高く、1 台の App-V クライアントで完全に独立して実行できるため、サーバー コンポーネントをまったく必要としません。つまり、手動での展開、ディスクを使用した展開、または従来の展開ツールを使用した展開が可能です。
App-V 4.5 では、ストリーミング プロトコルとして HTTP と HTTPS がサポートされるため、特にセキュリティで保護されたワイド エリア ネットワーク (WAN) 環境とインターネットを介したストリーミングのパフォーマンスが向上します。

App-V のフル インフラストラクチャのしくみ
いずれかのクライアント (App-V ターミナル サービス クライアントまたはデスクトップ クライアント) がインストールされているデバイスにユーザーがログオンすると、現在のユーザーに割り当てられているアプリケーションの一覧がクライアントからサーバーに要求されます。サーバーは、Active Directory と通信してそのユーザーが属しているグループを特定し、アプリケーションの一覧をクライアントに返します。クライアントは、このユーザーに割り当てられている仮想アプリケーションのアドバタイズを作成します。
この公開プロセスでは、以下に示すいくつかの操作が実行されます。
  • 構成ファイルがコピーされます。
  • デスクトップ アイコンが作成されます。
  • [送る] リンクが作成されます。
  • [スタート] メニューのフォルダが作成されます。
  • ファイルの種類が構成されます。
このプロセスは非常に短時間で完了するだけでなく、視覚的な変更を発生させることなく、ユーザーが予期したとおりの外観を維持します。これは最も重要なことです。仮想アプリケーションはローカルにインストールされているかのように動作しますが、もちろんホスト コンピュータが変更されることはありません。アイコンは、プログラム ファイルのディレクトリにある実行可能ファイルを参照するのではなく、App-V クライアントを参照します。App-V クライアントは、ランチャー ファイル (OSD ファイル) を利用して構成を再現します。
このプロセスは、従来のソフトウェア展開と異なり、何もインストールされないため、ネットワークへの影響がほとんど発生しないことに注意してください。これは、特に移動ユーザーが存在する環境で非常に役立ちます。その理由は、ユーザーがアプリケーションを使用できても、そのアプリケーションが起動されるまで実際には何も配信されないためです。また、この提供方法によって、App-V のオンデマンド機能と移動アプリケーション機能が実現されます。
ユーザーが仮想アプリケーションを起動すると、クライアントが、ローカル コンピュータに保存されている OSD 構成ファイルを読み取ります。このファイルには、アプリケーションが格納されている App-V 管理サーバーとの通信時にクライアントが使用するプロトコルが指定されます。
適切なサーバーが、初期起動しきい値 (通常はアプリケーション全体の 20 ～ 40% です) に該当するデータをストリーミング配信してクライアントに応答します。この起動しきい値 (もう一度言いますが、アプリケーション全体の 20 ～ 40% のみです) に該当するデータがすべて配信されると、仮想アプリケーションを実行できるようになります。
ストリーミングはまさに、App-V によって導入されたパラダイム シフトを構成する重要な要素の 1 つです。必要な分のみを配信することで、貴重なネットワーク帯域幅を無駄にすることなくアプリケーションを実行できます。クライアントに配信されるすべてのデータは、デバイス上のローカル キャッシュ ファイルに格納され、2 回目以降の起動時には、そのローカル キャッシュからアプリケーションが起動されるため、余分なネットワーク トラフィックが発生しません。
仮想アプリケーションのストリーミングが完了すると、クライアントはアプリケーションがローカル コンピュータを変更しないように、分離された環境を構築します (つまり、そのアプリケーションを実行した痕跡がクライアント側に残りません)。ただし、クライアントは、ファイルの保存および編集時には、仮想アプリケーションによるローカル ファイル システムへのアクセスを許可します。また、ユーザーがローカル システムに対する適切な特権を与えられていれば、仮想アプリケーションとローカル サービス (印刷など) の対話も許可します。仮想アプリケーションがローカル システムのファイルとレジストリに変更を加えた場合、その変更は仮想化環境にリダイレクトされるため、ホスト デバイスが変更されることはありません。
まだ使用されていない機能は、アプリケーションの実行中に必要に応じて配信され、それ以降の使用に備えてキャッシュに格納されます。この動作のメリットは、ユーザーが必要とするコンポーネントのみが初期起動時に読み込まれるため、不要な機能によってネットワーク リソースが消費されないことです (新しいバージョンでは、クライアント側のキャッシュ機能が強化され、キャッシュの使用率と、バックグラウンドで実行されるストリーミングの効率が向上します)。
Microsoft Office Word を例に考えてみましょう。スペル チェックはほぼすべてのユーザーが使用するため (悔しいですが、私はこの機能がなければこの記事を書くことができません)、初期起動時に配信される機能に含まれます。ですが、Word のヘルプ機能についてはどうでしょうか。この機能を使用するユーザーはそれほど多くないので、初期起動時に配信する必要はありません。この機能は、ユーザーがアクセスした時点で初めて配信されます。
ユーザーが作業を完了してアプリケーションを終了すると、クライアントは仮想環境を破棄した後、この環境を維持して次回の起動時に再構築できるように、すべてのユーザー設定をユーザー固有の領域に格納します。ストリーミング配信された量にかかわらず、そのアプリケーションの配信済みデータはローカル キャッシュに格納され、次回の起動時に利用されます。また、別のユーザーが同じホスト システムにログオンし、同じ仮想アプリケーションを起動した場合は、既にキャッシュに格納されているアプリケーションが利用されます。
仮想アプリケーションのアドバタイズを削除するには、該当する Active Directory グループからユーザーを削除します。また、デスクトップから完全に仮想アプリケーションをアンインストールするには、キャッシュの内容を消去します。アプリケーションが実際にローカルにインストールされることはないので、"この共有コンポーネントを削除しますか" というわずらわしいメッセージが表示されることはありません。
仮想アプリケーションがキャッシュに格納されていても、すべてのユーザーがこのキャッシュにアクセスできるわけではありません。ローカルにインストールされたアプリケーションの実行可能ファイルは、権限のないユーザーでも検索または参照できますが、仮想アプリケーションの存在を示すデータは、Active Directory グループによって明示的に権限がユーザーに与えられていない限り、仮想的にも物理的にも参照できません。

仮想アプリケーションを更新する
更新はシーケンサを使用して行います。アプリケーションに変更が加えられ、更新プログラムが追加されると、App-V 管理サーバー上で、そのバージョンが前のバージョンのすぐ隣に配置されます。サーバーは、クライアントの次回の起動時に、変更が加えられたことを通知します。前のバージョンが使用中である場合は、その仮想アプリケーションが終了するまで、ユーザーは引き続きそのバージョンを利用できます。次回の起動時に、更新されたデータのみがクライアントにストリーミング配信され、キャッシュに読み込まれます。その結果、更新されたバージョンのアプリケーションが提供されます。
たとえば、1,000 人のユーザーが Word 2000 を実行しているとします。管理者は、Word 2000 (word2K.sft) を Word 2000 SP3 に更新する必要があるため、word2K.sft ファイルをシーケンス ステーションにコピーし、シーケンサで [Open for Package Upgrade] (開いてパッケージをアップグレードする) を選択します。[Open for Package Upgrade] を選択すると、パッケージの最新の状態から処理を開始できます。管理者は、仮想アプリケーション内で DLL のコピー、更新プログラムの実行、または修正プログラムの実行を行い、Word 2000 を SP3 に更新します。処理が完了したら、この更新されたパッケージを保存します。
シーケンサは、自動的に新しいファイル名 word2K_2.sft を割り当てることで、ファイル名の重複を避けると同時に、それがシーケンス処理を実行するバージョンであることを示します。この新しいパッケージは、App-V 管理サーバー上で古いパッケージと同じディレクトリに格納されます。したがって、Word 2000 (word2K.sft) と Word 2000 SP3 (word2K_2.sft) は同じディレクトリに格納されます。その後、管理者は App-V の管理コンソールを使用して、これら 2 つの SFT ファイルを関連付けます。
クライアント側で、SP3 が適用されていない Word 2000 を使用しているユーザーは、問題なく作業を続行できます。管理者がこの関連付けを行った後で Word 2000 を新たに起動したユーザーには、変更が検出されたことを示すメッセージが表示されます。続いて、word2K.sft と word2K_2.sft の差分に該当するデータのみがクライアントにストリーミング配信され、自動的に Word 2000 が SP3 に更新されます。
仮想アプリケーションは動的な性質を持つため、ロールバックも非常に簡単です。必要な操作は、App-V の管理コンソールに戻り、新しく追加したバージョンを削除することだけです。その結果、再起動時にクライアントが以前のバージョンへのロールバックを実行します。クライアントは、パッケージのデータが重複しないように自動的にキャッシュを削除し、適切な SFT ファイルを再度ストリーミングによって受信します。これは、従来のソフトウェア展開ツールを使用して物理的にインストールされたアプリケーションの更新プログラムをロールバックするときに必要な処理を考えると、適正なトレードオフであると言えます。

App-V のメリットを実現するには、仮想アプリケーション パッケージを作成する必要があります。ここで活躍するのが App-V のシーケンサです。従来のソフトウェア展開ツール用のスクリプトまたはパッケージの作成に関する知識や経験があれば、シーケンス処理への移行時に役立ちます (ただし、シーケンス処理は、それ自体で 1 つの記事になるほどのトピックであることをお伝えしておかなければなりません)。
ほとんどのソフトウェア展開ソリューションは、各コンピュータでアプリケーションのインストールや更新を実行しなくても済むように、スクリプトを使用して、そのアプリケーションのインストール処理をキャプチャし、その処理を他のコンピュータ上で再現します。一般的なソフトウェア展開ツールは、アプリケーションがインストールされた後、パッケージに関する処理を何も実行しません。このため、アプリケーションで必要になる可能性がある項目をインストールしたり、他のスクリプトを実行したり、必要なアプリケーションの構成を手動で行ったりする必要があります。
App-V の根本的な変更点は、シーケンス処理によって、既にインストールされているアプリケーションのイメージが生成され、その依存関係に関する処理や構成が行われることです。この処理は、App-V クライアントが、自身を実行しているデバイスに変更を加えることなく実行できます。
シーケンサは、さまざまなファイルを生成します。最も重要なファイルは、アプリケーションのすべての資産、依存関係、および構成情報を含む SFT ファイルです。場合によっては、複数のアプリケーションが含まれることもあり、その場合は当然サイズが非常に大きくなります。圧縮オプションもいくつか用意されていますが、それらを使用するには、ネットワークとデバイスのパフォーマンスに関する詳しい知識が不可欠です。シーケンサが作成するアイコン ファイル (.ico) は、仮想アプリケーションのアドバタイズに使用され、そのアプリケーションがローカルにインストールされているかのような動作を提供する役割を果たします。
OSD ファイルも非常に重要であり、その利用方法は無限です。既定では、これは App-V クライアントに仮想アプリケーションの起動方法を指示する XML ファイルです。OSD ファイルを変更して、仮想アプリケーションの起動方法と実行方法を構成および制御することもできます。シーケンス処理の管理者向けガイドや、シーケンス処理のベスト プラクティスに関するドキュメントを読み、OSD ファイルを通じて利用できるプロパティや値について確認することを強くお勧めします。
新しい manifest.xml ファイルには、パッケージ ベースの構成情報が格納されます。このファイルは、サードパーティ製の ESD ソリューションや MSI 展開との統合に使用できます。シーケンサは、仮想アプリケーション パッケージの MSI ファイルを生成することもできます。このファイルを使用して、仮想アプリケーションをスタンドアロン (サーバーを使用しない) クライアントに読み込んだり、ESD システムから提供したりできます。
シーケンサ自体はウィザード ベースのツールであり、パッケージの作成者は、この手順に従ってアプリケーションをインストールし、それを仮想アプリケーションに変換できます (図 4 参照)。まず、パッケージの既定のプロパティを構成します。OSD ファイルに格納されるこれらのプロパティには、パッケージ名やコメントが含まれます。詳細設定では、ストリーミング配信元のサーバー、コンテンツ ディレクトリ、パッケージでサポートされるオペレーティング システムを指定できます。
図 4 シーケンス処理ウィザード (画像をクリックすると拡大表示されます)
2 番目の手順は、アプリケーションのインストール、構成、およびテストです。インストール中、シーケンサは、ファイル システム、レジストリ、およびシステムも含め、ローカル システムに加えられるすべての変更をキャプチャします。また、このウィザードには、Windows Update との統合を行うためのユーティリティなど、いくつかのユーティリティが用意されています。
次は、ファイルの種類の関連付けを構成し、ショートカットの配置先を指定します。通常は、[スタート] メニュー、デスクトップ、およびクイック起動バーに配置されますが、独自の場所を作成することもできます。
続いて、アプリケーションを起動し、初期起動しきい値を構成する必要があります。ここで、アプリケーションを起動するために App-V がクライアントに配信する必要がある、アプリケーションの初期コンポーネントを定義します。
この初期コード (通常は機能ブロック 1 (FB1) と呼ばれます) を構成するには、アプリケーションを起動し、ユーザーが必要とする最も一般的な機能を使用します。たとえば、Word を起動し、スペル チェックを実行します。この作業中にアプリケーションから呼び出された DLL、ファイル、またはレジストリ キーが自動的に FB1 に割り当てられます。この時点で使用されなかったファイル、設定、またはコンポーネントは FB2 に追加されます。その後、アプリケーションが使用されると、クライアントは、FB1 の範囲を示す SFT ファイルのマップを受け取ります。このマップには、アプリケーションで必要になった場合にクライアントがファイルを取得できるように、FB2 に含まれているその他のファイルの場所に関する情報も含まれます。
このシーケンス処理の最後の手順では、すべての設定が適切に構成されているかどうかを確認します。SFT の内容を表すダイアログ ボックス (図 5 参照) が表示され、ここでパッケージの作成者は、パッケージに対する最終的な追加や変更を行うことができます。
図 5 最終的なパッケージの確認と調整 (画像をクリックすると拡大表示されます)

Version 4.5
2 年間の開発期間を経て、App-V 4.5 は今年後半にリリースされる予定です。これはマイクロソフトからリリースされる初めてのバージョンであり、進化したアプリケーションの仮想化が提供されます。このバージョンでは、仮想アプリケーションの動的な対話、スケーラビリティの強化、マイクロソフト製品としての機能要件とセキュリティ要件へのより厳密な準拠など、いくつかの重要な機能強化が施されています。
仮想アプリケーションの動的な対話によって、仮想化されたアプリケーション間の対話が実現されます。この対話は、Dynamic Suite Composition (DSC) と呼ばれます。DSC は、複数のアプリケーションを同じパッケージに追加する機能に代わるものではなく、仮想アプリケーション間で共有される依存関係、ミドルウェア、およびプラグインを統合するための新しい手段を提供します。
管理者は、相互に対話する仮想アプリケーションを指定できます。たとえば、同じバージョンの Java を必要とする 5 種類の Web アプリケーションがあるとします。App-V 4.1 では、この同じバージョンの Java を 5 つの異なるパッケージにそれぞれ追加する必要があります。また、このバージョンの Java に修正プログラムを適用する必要があるとします。管理者は、これら 5 種類のパッケージすべてに修正プログラムを適用する必要があります。DSC を使用すると、一度 Java のパッケージを作成し、これを 5 種類すべての Web アプリケーションが使用するパッケージとして構成できます。したがって、Java に修正プログラムを適用するときも、この Java パッケージに修正プログラムを適用するだけで済みます。
このシナリオは、ミドルウェアやプラグインにも当てはまります。その他のシナリオについては、リリースが近づき、最終的な機能の追加が完了するころに、ブログで紹介する予定です。
スケーラビリティの強化は、ストリーミングとバックエンド インフラストラクチャの両方に関係しています。バックエンド コンポーネントは、クラスタとフェールオーバーに関するシナリオをサポートするように変更されました。また、WAN および LAN 上でストリーミングを使用しやすくなりました。これらの強化は、いくつかの重要な機能が追加されたことによって実現されます。
まず 1 つは、新しい Streaming Server コンポーネントです。このコンポーネントによって、Active Directory と SQL Server というバックエンド インフラストラクチャを必要としないストリーミングが実現されます。バックエンドの複雑な要件を考慮することなく、オンデマンドでの配信や、パッケージの一元的な更新など、優れた機能をすべて利用できます。このコンポーネントは、ブランチ オフィスのシナリオや、サードパーティ製の ESD ソリューションとの統合時に広く使用されることが予想されます。
App-V クライアントにも、いくつかの機能強化が施されています。たとえば、クライアントはすべての使用情報をローカルに格納し、クライアント システムがネットワークに接続しているかどうかに関係なく、この情報を追跡できるようになりました。クライアント キャッシュも拡張および強化され、ディスク容量が制限されたシナリオでのパフォーマンスが向上しました。また、英語以外のアプリケーションのシーケンス処理、英語以外のオペレーティング システムでの App-V の実行、および他言語へのローカライズもサポートされます。

App-V と Configuration Manager を統合する
App-V 4.5 で提供される機能強化と新機能の多くは、App-V と SCCM 2007 R2 の統合を目的としています。前述のとおり、仮想化とストリーミングは、従来のソフトウェア展開ツールで提供されていないアプリケーションの配信機能を提供します。これは、App-V がこれらのツールに置き換わる製品ではなく、これらのツールを補完して拡張できることを意味しています。
この統合によって、SCCM で提供されるスケーラビリティ、レポート作成機能、デバイスの認識機能、WAN 機能、および App-V で提供されるストリーミング機能と分離機能をすべて利用できます。これら 2 種類のテクノロジが統合されることでメリットを得ることができる領域を以下に示します。
アプリケーションの配信 : SCCM R2 と統合された App-V では、オンデマンドでの配信、移動アプリケーション、初期起動しきい値、クライアント PC を変更せずにアプリケーションを展開できる機能など、すべての機能がサポートされます。
更新 : SCCM 配布ポイント (DP) を使用して、パッケージが更新された場合に、仮想アプリケーションの変更分のみを展開できます。このため、1 回のクリックで、複数の仮想アプリケーションを一括で以前のバージョンに戻すことができます。
管理 : Version R2 では、新しい仮想アプリケーションのアドバタイズ ウィザードが導入されます。これにより、仮想アプリケーションだけでなく、従来のソフトウェア パッケージとアドバタイズの展開を 1 つのコンソールから実行できるようになります。
パッケージの作成 : App-V と SCCM を統合するときに、アプリケーションのパッケージを再度作成する必要がなくなります。アプリケーションの初期シーケンス処理は、SCCM の外部で App-V のシーケンスを使用して実行されますが、既存のパッケージは SCCM を使用して更新できます。
ライセンス : SCCM の既存のツールを使用し、仮想アプリケーションをライセンスとメータリングの目的で追跡できます。
BITS : SCCM では、業界標準の BITS プロトコルを使用して App-V に仮想アプリケーションを展開するための新しい手段が提供されます。SCCM DP を使用したストリーミングも可能ですが、ストリーミングが仮想アプリケーションを展開するための理想的な手段ではない場合もあります。SCCM を使用して展開を行う場合、2 種類の方法を選択できます。標準のストリーミングを使用するか、BITS のサービスの品質 (QoS) 機能を使用して、よりきめ細かに制御された形式で展開を行います。これは、ユーザーが仮想アプリケーションを起動する前にキャッシュをあらかじめ読み込む必要がある場合にも役立ちます。
コンピュータの展開 : SCCM では、仮想アプリケーションを特定のコンピュータに展開できるだけでなく、ユーザーに基づいた App-V プラットフォームの対象化も引き続きサポートされます。これは、仮想アプリケーションをラップトップ、キオスク、およびラボのコンピュータに展開するときに役立ちます。また、指定されたユーザーではなくデバイスに基づいてソフトウェアのライセンスが付与されている場合は、この機能をライセンスの管理に役立てることができます。
スケーラビリティ : 多くの機能が重複した 2 種類のツールを展開する必要が生じることはよくあります。SCCM で提供されるスケーラビリティと WAN 機能が、APP-V で提供される分離およびストリーミング機能に統合されることで、複雑さを増すことなく、管理と展開の両方に対応した単一のツールとして既存の SCCM を使用できます。

Anthony Kinney は、Microsoft Desktop Optimization Pack 担当のテクニカル セールス プロフェッショナルです。Anthony は、2006 年の Softricity 社の買収によって、同社からマイクロソフトに移籍しました。Softricity では、SoftGrid (現 App-V) の導入用トレーニング プログラムを執筆および作成していました。連絡先は Anthony.kinney@microsoft.com (英語のみ) です。


仮想化
Hyper-V の高可用性を実現する
Steven Ekren
概要 :
  • Hyper-V を使用してサーバーを統合する
  • 仮想マシンの高可用性を確保する
  • Windows Server 2008 フェールオーバーを構成する

目次
高可用性
ホストとゲスト
ゲストの可用性
VM の可用性を高める
前提条件
HA のチュートリアル
考慮事項
サーバーの仮想化は企業の IT 部門に大きな影響を与えます。これを実現するのが、Hyper-V と Windows Server 2008 です。サーバーを少数の物理コンピュータに統合すると、リソースとコストを大幅に節約できますが、計画プロセスでは 2 つの重要な要素について考慮する必要があります。1 つ目は、ソフトウェアの可用性に関するユーザーの期待がますます高まっていることです。これらのソフトウェアには、基幹業務 (LOB) アプリケーションと、メッセージング プラットフォームやコラボレーション プラットフォームなどのツールが含まれます。2 つ目は、サーバーで問題や障害が発生すると、運用にきわめて大きな影響を与える可能性があることです。Windows Server 2008 と Hyper-V によって提供されるソリューションを実装すると、仮想マシン (VM) の高可用性 (HA) だけでなく、VM の内部でホストされるワークロードの HA も実現できます。

高可用性
可用性は、作業を行うためにユーザーがシステムにアクセスできるかどうかを示します。高可用性は、運用の継続性を確保できるように設計および実装されるので、ユーザーが常にシステムにアクセスできることが強く期待されます。
Hyper-V の高可用性は、Windows Server 2008 フェールオーバー クラスタ機能を使用して実現されます。高可用性は、予定されたダウンタイムと予定外のダウンタイムの両方の影響を受けます。フェールオーバー クラスタリングを使用すると、こうした状況における仮想マシンの可用性が大幅に向上する可能性があります。
仮想マシンは、フェールオーバー クラスタによって管理できます。また、仮想マシンの内部でフェールオーバー クラスタを使用して、VM でホストされるワークロードを監視および移行できます。この 2 つの構成シナリオについては後ほど詳しく説明しますが、この記事では主に、仮想マシンの管理について説明します。この記事を読み始める前に、補足記事「知っておくと役立つ Hyper-V 用語」に目を通すことをお勧めします。

ホストとゲスト
Hyper-V システムでは複数のオペレーティング システムが実行されるので、どのレイヤや OS について説明しているかを明確にすることが難しくなる可能性があります。そのため、この記事では、"ゲスト" という言葉を使用して、子パーティションで実行される Hyper-V VM 内の OS と環境を表し、"ホスト" という言葉を使用して、Hyper-V 親パーティションの OS で管理される物理コンピュータを表します。
ホストの可用性を高めることにより、サーバーの統合によって生じる可能性がある、"1 つにすべてを賭ける" シナリオに付随する問題に対処できます。Hyper-V 子パーティション (仮想マシンまたはゲスト) の状態を監視し、子パーティションをクラスタのノード間で移行できるように、Hyper-V 親パーティション (ホスト) 上で Windows Server 2008 フェールオーバー クラスタを構成できます。このように構成すると、次に示す重要なメリットを得ることができます。
  • Hyper-V と VM を実行している物理コンピュータを更新、変更、または再起動する必要がある場合、クラスタの他のノードに VM を移行できます。その後、物理コンピュータが使用可能な状態になったら、その VM を元のノードに移行できます。
  • Hyper-V と VM を実行している物理コンピュータで障害が発生するか (マザーボードの障害が予想されます)、物理コンピュータのパフォーマンスが大幅に低下した場合、Windows フェールオーバー クラスタの他のメンバが VM の所有権を引き継ぎ、VM を自動的にオンラインにします。
  • VM で障害が発生した場合、その VM を同じ Hyper-V サーバーで再起動することも、別の Hyper-V サーバーに移行することもできます。この障害は Windows Server フェールオーバー クラスタによって検出されるので、VM のリソース プロパティの設定に基づいて、自動的に回復ステップが実行されます。検出と回復は自動的に行われるので、ダウンタイムが最小限に抑えられます。
図 1 は、このような状況で行われる処理を表しています。まず、ホスト A に配置されている VM2 がホスト B に移行されます。この移行時に、SAN 記憶域の LUN 2 を所有するノードが、ホスト A からホスト B に変更されることに注意してください。高可用性ソリューションで可用性の要件を満たすには、VM の配置先を慎重に検討する必要があります。検討する必要があるのは、容量とパフォーマンスの両方です。
図 1 新しいホストに移行される仮想マシンとその記憶域 (画像をクリックすると拡大表示されます)
ノードには、すべての VM をホストでき、x 個のノードで障害が発生したり、x 個のノードがクラスタから除外されても問題なく動作できるだけの容量が必要です (x は、失われてもクラスタが機能し続け、すべての VM をホストできるノードの数を表しています)。容量を判断するとき、通常は VM をホストしないいくつかのノードを予備として確保しておくことを選択できます。また、すべてのノード間で VM を分散することで、x 個のノードで障害が発生した場合でも、正常に所有権を引き継いで VM を起動できるだけの容量をノードごとに確保できます。
日常のパフォーマンスを向上させるために、クラスタのすべてのノード間で VM を分散することが望ましい場合があります。予備のノードが確保されていて、これらのノードで VM をホストしない場合、VM をホストするノードで使用されるリソースが増加し、VM と管理パーティションのパフォーマンスが低下することがあります。ノード間で VM を分散すると、各ノードの負荷が減少し、VM と管理パーティションのパフォーマンスが向上する可能性がありますが、容量計画は困難になることがあります。System Center Virtual Machine Manager 2008 などの管理用ソフトウェアを使用すると、ノードの障害や VM の配置に関する容量を計算できるので、役立つ場合があります。

ゲストの可用性
ゲストの可用性は、VM の内部で実行されるワークロードの可用性を高めることに重点を置きます。一般的なワークロードには、ファイル サーバーとプリント サーバー、IIS、LOB アプリケーションなどがあります。VM の内部で実行されるワークロードの高可用性に関する要件や解決策は、スタンドアロン サーバーの場合とほぼ同じように分析できます。この解決策は、特定のワークロードに依存します。
一部のワークロードの高可用性は、Windows ネットワーク負荷分散 (NLB) によって実現されます。NLB を使用すると、複数のサーバーを、共通のネットワーク名を持つプールの一部にすることができます。その仮想ネットワーク名を使用してクライアントが接続要求を行い、NLB クラスタのいずれかのノードへの接続が確立されます。NLB クラスタリングを使用する一般的なシナリオは、IIS を使用した Web ファームの構築です。この Web ファームでは、各システムに IIS がインストールされ、各システムで同じ Web ページと同じデータへのアクセスが提供されます。NLB を使用すると、負荷分散を提供できるだけでなく、サーバーで問題が発生した場合やメンテナンスを行う場合に、該当するサーバーをメンバから除外することもできるので、高可用性が実現されます。Hyper-V VM で Windows Server 2008 (または NLB を含むそれ以前のバージョンの Windows Server) が実行されている場合、そのゲストを、同じまたは別の Hyper-V ホスト上に配置されたその他のゲストが構成する NLB クラスタのメンバにすることができます。
Windows Server 2008 を実行しているゲストでは、Windows フェールオーバー クラスタ機能を使用して、ワークロードの高可用性を実現できます。ゲストの内部で Windows フェールオーバー クラスタリング (ゲスト クラスタリング) を使用すると、次に示すいくつかのメリットがあります。
ワークロードの正常性監視 Windows フェールオーバー クラスタでは、クラスタに関連付けられたリソース DLL を呼び出すリソース モニタが提供されます。各リソースには、そのリソースによって管理されるアプリケーションまたはサービスをテストして、正しく動作しているかどうかを確認する、正常性の監視機能が備わっています。こうした確認は、一般に isAlive チェックや looksAlive チェックと呼ばれます。リソースでこれらの呼び出しが 1 つでも失敗すると、そのリソース自体で障害が発生します。リソースのプロパティがどのように構成されているかによって、サービスやアプリケーションが再起動したり、Windows フェールオーバー クラスタの別のノードに移行したりすることがあります。
仮想マシンのメンテナンス VM の構成を変更する必要がある場合、あるいは OS やソフトウェアを更新または変更する必要がある場合は、クラスタの別のノードにワークロードを移行し、VM をシャットダウンまたは更新できます。こうすることで、エンド ユーザーの中断を最小限に抑えることができます。
ホスト マシンのメンテナンス Hyper-V VM をホストしている物理コンピュータでメンテナンスやソフトウェアの更新を行う必要があり、Windows フェールオーバー クラスタの他のメンバが別の Hyper-V ホスト上に配置されている場合、VM のワークロードをクラスタの別のノードに移行して VM をシャットダウンすることで、物理サーバーの変更や再起動に対処できます。
仮想マシンまたはホスト マシンでの障害 Hyper-V 物理ホストまたは仮想マシン ゲストで障害が発生した場合、Windows フェールオーバー クラスタの他のノードによって、そのクラスタ メンバが応答せず、クラスタから除外されたことが検出されます。その後、正常に動作しているノードによって、障害が発生した VM で実行されていたアプリケーションやサービスがオンラインに切り替えられます。

知っておくと役立つ Hyper-V 用語
以下に、高可用性 Hyper-V システム (ホスト クラスタ) の構成要素または機能を定義するのに役立つ用語の一覧を示します。
親パーティション ハイパーバイザ サーバー上で実行されるすべてのオペレーティング システムに、RAM、CPU、その他のシステム コンポーネントなどのハードウェア リソースが割り当てられます。Hyper-V では、ハイパーバイザとシステム リソースの構成を管理するパーティションのことを、親パーティションと呼びます。Hyper-V の役割を構成し、サーバーを再起動すると、そのシステムのネイティブ OS であった Windows Server 2008 インスタンスが、Hyper-V サーバーの親パーティションの OS になります。
子パーティション Hyper-V サーバー上の分離された環境。ゲスト オペレーティング システムを保持し、そのオペレーティング システムにハードウェア リソースを提供するように構成されます。
Hyper-V ホスト 親パーティションの内部で実行される Hyper-V とオペレーティング システムをホストする物理サーバー。
Hyper-V 仮想マシン Hyper-V の構成情報と、Hyper-V 子パーティションを起動および実行するために使用されるデータ。子パーティションを作成するための構成情報と、そのデータを含む VHD ファイルまたはパススルー ディスクが含まれます。
パススルー ディスク Hyper-V ゲスト専用に割り当てられた物理ディスクとしてディスクの管理に表示される記憶域デバイス。Hyper-V ゲストによってマウントされ、ローカルに接続された記憶域デバイスと同じように使用されます。
仮想ハード ディスク (VHD) Hyper-V 子パーティションによって接続されるファイル。記憶域デバイス (ディスク) としてオペレーティング システムに公開されます。.vhd ファイルは、親パーティションによってマウントされる記憶域デバイスに格納され、直接接続型記憶域デバイスにすることも、SAN、NAS、SMB などを経由して接続される記憶域にすることもできます。
VM の可用性を高める
高可用性を確保するために仮想マシンを構成する作業は、フェールオーバー クラスタ管理で HA Role Wizard (HA の役割ウィザード) を実行するのと同じくらい簡単です。Hyper-V 仮想マシンを高可用性仮想マシンとして管理する場合は、いくつかの重要な構成要素について考慮する必要があります。いくつかの重要な概念と、一般的な前提条件を見ていきましょう。
フェールオーバー クラスタ ノード フェールオーバー クラスタの一部である各物理サーバーは、ノードと呼ばれます。ホスト クラスタリングの場合、フェールオーバー クラスタ サービスは、Hyper-V システムの親パーティション上の Windows Server 2008 で実行されます。このため、同じ物理サーバー上の子パーティションで実行されている VM を高可用性仮想マシンとして構成できます。HA として構成された仮想マシンは、フェールオーバー クラスタ管理コンソールにリソースとして表示されます。
HA 記憶域 高可用性仮想マシンは、仮想ハード ディスク (VHD)、パススルー ディスク、および差分ディスクを使用するように構成できます。フェールオーバー クラスタ ノード間で仮想マシンを移行できるようにするには、VM をホストするすべてのノードからアクセスでき、フェールオーバー クラスタ サービスによって管理される記憶域 (ディスクの管理にディスクとして表示される領域) が必要です。パススルー ディスクをディスク リソースとしてフェールオーバー クラスタに追加し、VHD ファイルを、ディスク リソースとしてフェールオーバー クラスタに追加されるディスクに配置する必要があります。
仮想マシン リソース 仮想マシンを表す、フェールオーバー クラスタ リソースの種類。仮想マシン リソースがオンラインになると、Hyper-V によって子パーティションが作成され、仮想マシンの OS が起動します。仮想マシン リソースのオフライン機能によって、ホストされていたノードの Hyper-V から VM が削除され、Hyper-V ホストから子パーティションが削除されます。仮想マシンがシャットダウン、停止、または保存された状態に復元されると、このリソースはオフライン状態になります。
仮想マシン構成リソース VM の構成情報を管理するために使用される、フェールオーバー クラスタ リソースの種類。仮想マシンごとに、1 つの仮想マシン構成リソースが存在します。このリソースのプロパティには、Hyper-V ホストに仮想マシンを追加するために必要なすべての情報を含む構成ファイルへのパスが記録されています。仮想マシン リソースを起動するには、構成ファイルにアクセスできる必要があります。構成は個々のリソースで管理されるので、VM がオフラインのときでも、VM リソースの構成を変更できます。
仮想マシン サービスとアプリケーション グループ フェールオーバー クラスタリングによってサービスやアプリケーションの可用性を高めるには、1 つのフェールオーバー クラスタ ノードで複数のリソースをホストする必要があります。これらのリソースは、常に同じノード上に存在して適切に相互運用できるように、Windows Server 2008 フェールオーバー クラスタで "サービスまたはアプリケーション" と呼ばれる 1 つのグループにまとめられます。VM の仮想マシン リソースと仮想マシン構成リソースは、必ず同じサービスまたはアプリケーション グループにまとめられます。サービスまたはアプリケーション グループには、VHD や構成ファイルが格納された 1 つ以上の物理ディスク (または他の種類の記憶域) リソース、またはパススルー ディスクが含まれることもあります。
リソースの依存関係 仮想マシン構成リソースをオンラインにしてから仮想マシン リソースをオンラインに (起動) すること、および仮想マシン リソースをオフラインにしてから仮想マシン構成リソースをオフラインに (停止) することは重要です。仮想マシン リソースが仮想マシン構成リソースに依存するように仮想マシン リソースのプロパティを設定すると、確実にこの順序でオンラインとオフラインが切り替わります。仮想マシン構成リソースまたは仮想マシン リソースのファイルが格納された記憶域リソースが存在する場合は、格納されているリソースをその記憶域リソースに依存させる必要があります。たとえば、仮想マシンでディスク G: とディスク H: に格納されている VHD ファイルを使用する場合は、仮想マシン リソースを、構成ファイル リソースと、ディスク G: およびディスク H: のリソースに依存させる必要があります。

前提条件
Windows Server 2008 フェールオーバー クラスタ機能を使用して Hyper-V 仮想マシンの可用性を高めるには、以下に示す 3 つの前提条件を満たす必要があります。
  1. クラスタのノードごとに、Windows Server 2008 フェールオーバー クラスタ機能を構成する必要があります。フェールオーバー クラスタの構成と管理の詳細については、補足記事「Hyper-V の関連情報」を参照してください。
  2. Hyper-V の役割をインストールする必要があります。Hyper-V の更新プログラムをインストールし、フェールオーバー クラスタのノードごとに役割を構成する必要があります (これについても、補足記事「Hyper-V の関連情報」を参照してください)。Hyper-V には、Hyper-V サーバー コンポーネントをインストールする更新パッケージと、Hyper-V 管理コンソールをインストールする更新パッケージが用意されています。Hyper-V サーバー コンポーネント用の更新プログラムをインストールした後は、サーバー マネージャまたは ServerManagerCMD を使用して役割を追加できます。
  3. 仮想マシンで共有記憶域を使用できるようにする必要があります。共有記憶域は、組み込みの物理ディスク リソースの種類としてフェールオーバー クラスタで管理するか、サードパーティ製のソリューションを使用して管理できます。もちろん、使用するサードパーティ製のソリューションでは、Windows Server 2008 フェールオーバー クラスタがサポートされている必要があります。

HA のチュートリアル
では、高可用性ソリューションの構成方法を見ていきましょう。最初の手順は、仮想マシンの構成です。Hyper-V の役割がインストールされているフェールオーバー クラスタのいずれかのノードで、Hyper-V マネージャを使用して仮想マシンを構成します (図 2 参照)。新しい VM を手動で構成して使用することも、既存の VM をインポートすることもできます。VHD は、Windows Server 2008 フェールオーバー クラスタによって管理され、現在 VM を構成しているノード上でオンラインになっているディスクに格納されている必要があります。
図 2 仮想マシンの構成 (画像をクリックすると拡大表示されます)
ここで、仮想マシンを停止状態にします。これを行うには、仮想マシンをシャットダウンまたは無効にするか、状態を保存します。停止状態になっていない仮想マシンは、フェールオーバー クラスタによって管理されるように構成できません。
Windows Server 2008 フェールオーバー クラスタの役割を実行している任意のサーバー、またはリモート サーバー管理ツール (RSAT) を実行している Windows Vista クライアントで、フェールオーバー クラスタ管理コンソール (図 3 参照) を開きます。[クラスタの管理] を選択してノードまたはクラスタ名を選択するか、コンソールを実行しているノードでクラスタに接続するオプションを選択して、フェールオーバー クラスタに接続します。
図 3 フェールオーバー クラスタ管理コンソールに表示された仮想マシン (画像をクリックすると拡大表示されます)
フェールオーバー クラスタ管理コンソールで、[サービスまたはアプリケーションの構成] を選択します。これにより、高可用性ウィザードが起動します。このウィザードでは、サービス、アプリケーション、または仮想マシンを、フェールオーバー クラスタによって管理されるように構成できます。ウィザードの [サービスまたはアプリケーションの選択] ページで、[仮想マシン] を選択し、[次へ] をクリックします。
[仮想マシンの選択] ページには、フェールオーバー クラスタのいずれかのノードで構成されているすべての仮想マシンが表示されます。仮想マシンを選択し、[次へ] をクリックします。ウィザードの [確認] ページに、すべての警告とエラーが表示されます。ここでは、仮想マシンを HA リソースとして構成できるかどうか、およびノードで仮想マシンをホストできるかどうかを検証するために、仮想マシンの構成が確認されます。[次へ] をクリックすると、仮想マシンが高可用性リソースとしてフェールオーバー クラスタに追加されます。
概要ページには、仮想マシンを高可用性リソースとして追加した結果に関する情報が表示されます。この情報には警告も含まれます。[レポートの表示] をクリックすると、仮想マシンの可用性を高めるために実行されたタスクの詳細、およびすべての警告とエラーを確認できます。最後に、[完了] をクリックして高可用性ウィザードを終了します。
図 3 のウィンドウが示すように、フェールオーバー クラスタ管理コンソールの左側のウィンドウにある、クラスタ名と [サービスまたはアプリケーション] の下に、"Virtual Machine(x)" (仮想マシン (x)) という既定の名前でオブジェクトが表示されます。ツリー構造内の仮想マシンを選択すると、サービスまたはアプリケーション グループに属しているリソースが、コンソールの中央のウィンドウに表示されます。その他の仮想マシンのファイルが、選択した仮想マシンのファイルと同じ記憶域に格納されている場合、その仮想マシンも選択した仮想マシンのグループに追加されます。グループに追加された仮想マシンごとに、仮想マシン リソースと仮想マシン構成リソースが表示されます。
サービスまたはアプリケーション グループの情報ウィンドウには、グループの状態、警告、優先する所有者、および現在の所有者に関する情報が表示されます。[所有者] ノードは、現在仮想マシンが構成または実行されているノードです。[Move Virtual Machine(s) to another node] (仮想マシンを別のノードに移行) を選択して、仮想マシンをオフラインにし、別のノードでオンラインにします。一般的なベスト プラクティスとしては、フェールオーバー クラスタ内で、VM をホストできる各ノードに VM を移行することによって、その移行が成功し、VM が起動および実行されるかどうかを確認します。

Hyper-V の関連情報
  • Windows Server 2008 のリリース バージョンのハイパー V テクノロジの更新プログラムについて
  • Hyper-V ステップ バイ ステップ ガイド : Hyper-V とフェールオーバー クラスタリングをテストする
  • Windows Server 2008 フェールオーバー クラスタリングの概要 (Chuck Timon 著、TechNet Magazine 2008 年 7 月号)
  • NLB ホストが Windows Server 2008 Hyper-V 仮想マシンで期待どおりに収束されない
  • Win2008 クラスタ Web キャスト
  • Windows Server 2008 フェールオーバー クラスタに関するマイクロソフト サポート ポリシー
考慮事項
仮想マシンを高可用性リソースとして構成する場合は、以下に示すいくつかの重要点に留意してください。
記憶域 複数の仮想マシンの VHD ファイルが同じ共有ディスクに格納されている場合、それらの仮想マシンは、同じディスク上の異なるボリュームに存在していても、同じサービスまたはアプリケーション グループに追加されます。ディスクを共有するメリットの 1 つは、共有記憶域の空き領域をさらに有効活用できるようになることです。
ただし、そうすると、1 台の仮想マシンが移行されると、その移行が仮想マシンに関する問題からの自動回復によるものであっても、管理者が決めた処理であっても、必ずグループ内のすべての仮想マシンが移行されることになります。
ドライブ文字と GUID ドライブ文字を割り当てずにボリュームを作成できます。仮想マシンでは、ドライブ文字が割り当てられていないボリュームを使用でき、これらのボリュームはフェールオーバー クラスタで管理できます。ディスク リソースのボリュームで、ドライブ文字ではなく GUID が使用される場合は、その GUID がクラスタの管理に表示されます。仮想マシンを作成し、その VHD のパスを指定するときは、パスに含まれる GUID と、ボリュームのクラスタの管理に表示される GUID を一致させることが非常に重要です。一致しない場合、フェールオーバー クラスタの他のノードで、仮想マシンが正常に起動しない (オンラインにならない) ことがあります。
GUID が一致しなくなる状況はいくつかあります。あるボリュームを複数のノード上でオンラインにした後、それらのノードをフェールオーバー クラスタで管理されるディスク リソースとして追加すると、各ノードでそのボリュームに異なる GUID が割り当てられる可能性があります。また、単一ノード上でも、1 つのボリュームに複数の GUID が割り当てられる場合があります。あるディスクを物理ディスク リソースとしてフェールオーバー クラスタに追加すると、そのディスクをオンラインにするノードで使用されているボリューム GUID が、ディスク リソースのプロパティに記録されます。
ディスク リソースがオンラインになると、これらのボリューム GUID がノードに追加されます。これにより、フェールオーバー クラスタによってボリューム用に記録された特定の GUID が、そのディスクをオンラインにするどのノードでも有効なパスになります。このノードには、同じボリュームに関連付けられた他の GUID が割り当てられることもあります。そのため、ユーザーは、そのノード上にあるボリュームの有効な GUID を確認できても、その GUID は、他のノード上にあるボリューム用にフェールオーバー クラスタで使用される GUID とは異なります。この問題の兆候としては、仮想マシン リソース (通常は構成リソース) をオンラインにすることができず、パスが無効であることを示すエラー メッセージが表示されます。エラー メッセージに含まれるパスは、そのボリューム用にクラスタで管理される GUID ではありません。
マウント ポイント ドライブ文字を割り当てたり、GUID を使用したりせずに、別のボリュームのフォルダにマウントされるボリュームを Hyper-V やフェールオーバー クラスタで使用できます。マウントされるボリュームと、マウント ポイントをホストするボリュームは、どちらも同じフェールオーバー クラスタ ノード上に存在する必要があるので、マウント ポイントの一部であるディスクはすべて、同じフェールオーバー クラスタ サービスまたはアプリケーション グループに含まれている必要があります。
ボリュームが同じディスク上に存在する場合、当然問題はありませんが、異なるディスク上に存在する場合は、間違いなく問題となります。また、マウントされるボリュームと、マウント ポイントのホストはどちらも、フェールオーバー クラスタで管理するように構成された共有記憶域である必要があります。これも当然のことですが、言及しておく価値があると判断しました。
差分ディスク 差分ディスクの一部であるすべての VHD ファイルは、それらの差分ディスクを使用する VM と同じサービスまたはアプリケーション グループの共有記憶域に格納される必要があります。差分ディスクの最も単純な構成には、2 つの VHD が関与します。一方の VHD は親で、この VHD には基盤として使用される一連のデータが含まれます。もう一方の VHD は、その親に関連付けられた子です。
差分ディスクを初めて使用すると、親ディスクと同じ構成が提供されます。データが親 VHD に格納されている場合は、その親 VHD からデータが読み取られます。書き込みはすべて子 VHD で発生します。データが子 VHD に格納されている場合、そのデータの読み取りでは子 VHD が参照されます。
子 VHD が共有記憶域に格納されていても、親 VHD が同じグループの共有記憶域に格納されていないか、ローカルに接続された記憶域デバイスに格納されている場合は、VM を別のノードに移行しても起動 (オンラインに) できません。高可用性ウィザードでは、VM がこの点で正しく構成されているかどうかが確認され、問題が検出された場合はエラー メッセージが表示されます。ただし、VM の構成が変更された場合の要件にも注意が必要です。

Steven Ekren は、Windows Server フェールオーバー クラスタおよび高可用性チームのシニア プログラム マネージャです。マイクロソフトのサポート部門に 12 年間在籍し、企業ユーザーが Windows Server フェールオーバー クラスタと、Windows Hyper-V、System Center Virtual Machine Manager、Microsoft Virtual Server、Microsoft Virtual PC などの仮想化テクノロジを実装し、問題を解決する作業をサポートしてきました。


仮想化
サーバー仮想化に関するバックアップと障害復旧
Adam Fazio
概要 :
  • 障害復旧計画の考慮事項
  • 障害復旧の高可用性ソリューション
  • Windows Server バックアップを使用したバックアップと復元

目次
障害復旧計画の基本事項
障害復旧と仮想化
物理-バーチャル変換
仮想マシン スナップショット
Hyper-V のバックアップ
Windows Server バックアップ
WSB による VM のバックアップ
考慮事項
WSB による VM の復元
Data Protection Manager
スクリプトによるバックアップ
DiskShadow
まとめ
サーバー仮想化テクノロジが進化し、業界での普及が進むにつれて、組織では、「インフラストラクチャにかかるコストの削減と IT 敏捷性の向上」という仮想化を正当化する最も一般的な理由を超えたところにあるメリットを認識するようになりました。その新たな開拓分野は、仮想化プラットフォームを障害復旧 (DR) 戦略を強化する手段として使用することです。
IT 業界において DR への備えが常に話題に上るのはなぜかというと、1 時間のダウンタイムにより企業は平均 80,000 ～ 90,000 ドルの損失を被り、壊滅的なデータ損失を被った企業が、その後、長期間存続することはまれである、という調査結果が出ているからです。この記事では、マイクロソフトの仮想化プラットフォームを使用した DR の概要を説明し、Windows Server 2008 Hyper-V に関するバックアップと復元のオプションおよび考慮事項を紹介します。

障害復旧計画の基本事項
DR は、停電時に重要なサービスを復元するプロセスで、すべての企業の事業継続計画に含まれているべきものです (事業継続計画とは、このような障害発生時および発生後に企業がどのようにして存続するかを定義するものです)。このような計画は、DR の構想に必要不可欠です。
一部のベンダが提供する DR 自動化テクノロジの中には、そのテクノロジを使用すると、十分に準備を行った詳細な計画を立てる必要がなくなったり、その作業が簡略されたりすると謳っているものがあります。自動化により復旧にかかる時間が短縮され、人の手を必要とする作業が軽減されるのは事実です。ですが、公共広告に耳を傾けてください。テクノロジだけでは災害を軽減することはできません。人とプロセスもテクノロジと同じくらい大切です。
事実、DR の計画段階で発生する制限事項と目的を知らなければ、適切なテクノロジを選択するのは不可能だと言っても過言ではありません。DR の計画全般について説明するのは、この記事の範囲を超えていますが、これらの要素は、適切なテクノロジと実装を選定するうえで重要であることは強調しておきたいと思います。では、DR 計画でテクノロジを選定する際の重要な要因のいくつかを簡単に紹介しましょう。
サービスの定義と優先順位保護するサービス全体で何を定義していて、そのサービスが組織においてどの程度重要であるかを定義します。図 1 は、一般的な DR 計画に含まれる可能性の高い企業向けサービスの一覧です。
図 1 サービスの定義と優先順位の例
サービス | 主要コンポーネント | 依存関係 | 業務用途 | SLA
パブリック Web サイト | ネットワーク ロード バランサ、Web サーバー 3 台、データベース サーバー 2 台 | DNS、ネットワーク、ファイアウォール、ディレクトリ、SAN (記憶域ネットワーク) 記憶域 | 製品購買、受注管理、電子商取引、カスタマ サポート ポータル、企業情報 | 99.99%
財務システム | データベース サーバー 2 台、アプリケーション サーバー 1 台 | DNS、ネットワーク | 法律と規定により記録することが定められている企業収益の記録 | 99.99%
電子メール システム | 電子メール サーバー 3 台、Web サーバー 1 台 | DNS、ネットワーク、ファイアウォール、ディレクトリ | 社内のコミュニケーション、カスタマ サポート | 99.5%
サービスを定義したら、各システムと依存関係について、どのような DR 戦略を採用するのかを判断する作業に取りかかることができます。すべてのサービスと依存関係を洗い出して初めて、すべてのミッション クリティカルなサービスに 1 つの DR ソリューションを使用するのはコストが非常に高く、かつ複雑になるため、DR の機能をいくつかのレベルに分けて考える必要があることが判明する場合もあります。
サービス レベル アグリーメント (SLA) SLA は、サービス プロバイダ (IT) とユーザー (組織) 間で締結された、特定のサービスの可用性目標値を規定した合意事項または契約です。SLA は、非常に長いものもあれば、簡潔なものもあります。たとえば、「本電子メール システムでは、通常業務時間帯において 99.95% の可用性を保証し、通常業務時間外において 98% の可用性を保証します。ただし、毎月の定期メンテナンス時間帯は除くものとします。」というような感じです。通常、SLA は複数の段階に分かれており、この段階に IT サービスを当てはめて、定期的に測定することになっています。
運用レベル アグリーメント (OLA) OLA では、ある特定の SLA をサポートするために協力している複数の IT グループ間で成された合意事項を記載したものです。これには、各グループがサービスを提供するプロセスやサービスの提供にかかる時間などが含まれます。SLA の目標値が 99.99% のミッション クリティカルな Web サイトを所有している場合に、そのサイトのコンテンツを格納しているデータベースの SLA が 95% しかないとします。OLA は、この不一致を解明して、IT チームが同じ目標に向かって作業を進められるように調整する役割を果たします。
目標復旧時点 (RPO) と目標復旧時間 (RTO) RTO は、サービスが利用できなくなってから、連続性が失われるまでの時間を定義するもので、RPO は、企業にとって許容範囲と見なされるデータ損失のレベルを定義します。つまり、毎月定期的に測定しているサービスの SLA が 99% である場合、そのサービスの RTO は 7 時間 18 分であると言えます。たとえば、この RTO を 24 時間という RPO と組み合わせると、バックアップの技法とスケジュールを的確に定義できます。
データの保持に関するポリシー組織におけるデータの保持に関するポリシーでは、バックアップを保管する期間と場所を明確に定義しています。通常、このようなポリシーは法律上や規則上の要件を満たすために作成されています。
データの分類データの性質も考慮する必要があります。データを分類すると、すべてのデータで DR について同じレベルで考慮する必要はないということがすぐにわかります。たとえば、単独のデータベースの可用性の要件は、ディレクトリのレプリカを保持している 3 台のドメイン コントローラを伴う Active Directory の可用性の要件とは異なります。同様に、ファイル サーバーのデータを復元する手順は、CRM のデータを復元する手順とは大きく異なる可能性があります。
障害シナリオ復元手順、業務に与える影響、関連コストはシナリオによって異なるため、対応する必要があるすべてのシナリオを定義することが重要です。ご使用の環境の DR 計画を策定する際には、次のような考えられるすべてのシナリオを検討してから、実際に対応するシナリオを決めることをお勧めします。
  • サイト全体のデータ損失
  • 特定のデータセンターのデータ損失
  • 特定のシステムのデータ損失 (オペレーティング システムまたはハードウェア障害)
  • データの損失 (データの削除または破損)
  • 重要な依存関係の損失
サイト全体のデータ損失と単一システムのデータ損失では、損失を回復する際の考慮事項が大きく異なるのは明らかです。また、SLA に基づいてしきい値を定義することもできます。たとえば、ISP ネットワークの大規模な停電によりサイト全体がオフラインになったとします。この停電により利用できなくなっているサービスの SLA で、サービスの復元に 8 時間、データの復元に 48 時間かかると明記されている場合は、実際にデータを復元することなく、バックアップ サイトにサービスをフェールオーバーさせるのが得策です。というのも、運用サイトへのフェールバックは比較的短時間で行えるからです。
やれやれ。結構な量の情報を提供しましたが、まだ仮想化テクノロジについては何も説明していません。ですが、計画の重要性をあなどらないでください。計画のドキュメントを作成することなく DR を実装することは、「DR に対する期待」でしかありません。

障害復旧と仮想化
DR 計画の基本事項について説明したので、今度は、DR 計画に仮想化を組み込むとどうなるのかについて説明しましょう。仮想化テクノロジを導入したサーバーを使用している多くの企業は、サービスを分単位という短時間で復旧できると報告しているのに対して、物理サーバーを使用している企業では、サービスの復旧に数日から数週間の時間がかかると報告されています。現在、サーバー オペレーティング システム全体は、基になる物理的なハードウェアから切り離された単なる一連のファイルでしかないため、復旧性を考慮する際には、これまでになかった選択肢が使用できるようになりました。
「DR の目的の一部またはすべては、高可用性 (HA) ソリューションで実現できる」というのが、現時点での一般的な見解です。この見解の背後には、物理的に離れている場所にクラスタ ノードがあり、サイト間でデータを同期している場合、障害発生時には、パッシブ ノードで運用を再開して、ほぼリアルタイムで障害から復旧できることがあります。
これは事実ですが、先ほど紹介した障害シナリオを思い出すと、これがすべてのシナリオに適しているわけでないことは一目瞭然です。すべての障害シナリオに備えるには、複数のテクノロジを組み合わせる必要があり、通常は、なんらかの定期的なバックアップを実行することも必要となります。HA を使用しても、すべての停電から保護したり、バックアップ戦略が完全に不要になったりするわけではありません。
Hyper-V を使用する HA では、復旧性を実現するうえで重要な記憶域層の計画を入念に立てる必要があります。たとえば、共有の記憶域を持つ 2 ノードの Hyper-V クラスタでは、記憶域のサブシステムとデータが単一障害点になり得ます。また、これは、クラスタ ノードが別のデータセンターにある場合も同様です。
共有の記憶域を持たない 2 ノードの Hyper-V クラスタでは、他方のノードで記憶域またはデータの損失が発生しても、その状況に対応できます。ただし、これには、記憶域を同期するレプリケーション テクノロジが必要になり、構成が複雑になります (図 2 参照)。
図 2 複数サイトにまたがる Hyper-V クラスタ (画像をクリックすると拡大表示されます)
データのレプリケーションと同期に関しては非常に興味深い進展が見られますが、現在、マイクロソフトがこの分野で提供しているものはありません。Windows Server 2008 の「フェールオーバー クラスタリング – マルチサイト クラスタリング」(microsoft.com/windowsserver2008/en/us/clustering-multisite.aspx) では、一見の価値があるパートナーを紹介しています。また、Windows Server カタログ (windowsservercatalog.com) では、Windows Server 2008 での使用が認定されているレプリケーション テクノロジを提供している記憶域ベンダを紹介していますので、こちらも参考資料としてご覧ください。
ご覧のとおり、ご使用の環境での使用を検討する対象となる HA と記憶域の構成は多数あります。ですから、ビジネス要件を定義し、その要件に基づいて技術的な要件を定義する必要があります。この順序が逆であるのはよくありません。

物理-バーチャル変換
仮想化により類のない復旧の機敏性が提供されるのは明らかですが、仮想化の候補として適切ではない物理システムについてはどうでしょうか。System Center Virtual Machine Manager (SCVMM) には、実行中の Windows サーバーの物理-バーチャル (P2V) 変換を実行する機能が備わっています。この機能を使用すると、物理的なソース サーバーの完全なレプリカであるブート可能な Hyper-V バーチャル マシン (VM) を作成できます。この VM は、敷地や国境を越えて、仮想化の対象となった物理コンピュータと同様にレプリケートすることが可能で、同程度の時間で復旧することができます。
このアプローチは、従来のベアメタル復元と異なり、復旧場所では、運用環境と同数の同じ種類の物理システムは必要ありません。ですから、障害の影響度合いに応じて、復旧に使用するハードウェアを複数のシステムで使用したり、拡張したりすることができます。
SCVMM には、P2V 変換に対応したスケジューラは用意されていませんが、GUI は完全に Windows PowerShell ベースで実行されるので、New-P2V コマンドレットを使用して簡単にスクリプトを作成できます。実際、SCVMM の全ウィザードでは、ジョブの実行に使用するスクリプトが提供されるので、ご使用の環境のテスト P2V からコードをコピーして、ジョブの自動化を図ることができます。図 3 は、サンプル コードです。ご使用の環境で SCVMM の P2V ウィザードを実行して、一意でカスタマイズ可能な Windows PowerShell スクリプトを作成できます。
図 3 SCVMM の P2V ウィザードで生成されたコード
$Credential = get-credential

New-MachineConfig -VMMServer <VMM SERVER> -SourceComputerName "<SOURCE P2V SERVER>"
-Credential $Credential -RunAsynchronously

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -SourceNetworkConnectionID "00:14:D1:3C:66:2F"
-PhysicalAddress "00:14:D1:3C:66:2F" -PhysicalAddressType Static -VirtualNetwork "External"
-MachineConfig $MachineConfig

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -VolumeDeviceID "C" -Dynamic -IDE -Bus 0 -LUN 0 -MachineConfig $MachineConfig

$Credential = get-credential
$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -Credential $Credential -VMMServer <VMM SERVER> -VMHost $VMHost -Path
"C:\ProgramData\Microsoft\Windows\Hyper-V" -Owner "DOMAIN\username" -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -Trigger -Name "<SOURCE P2V SERVER>" -MachineConfig
$MachineConfig -CPUCount 1 -MemoryMB 512 -RunAsSystem -StartAction NeverAutoTurnOnVM
-UseHardwareAssistedVirtualization $false -StopAction SaveVM

仮想マシン スナップショット
VM スナップショットは、厳密にはバックアップではありませんが、差分ディスクと VM 構成ファイルを使用して、ある特定の時点の状態に戻せるようにするものです。VM 内でデータを誤って削除したことが原因で障害が発生した場合、VM はスナップショットにロール バックして、データの破損を元に戻すことができるので、VM は DR 機能と見なすことができます (ボリューム シャドウ コピー サービス (VSS) のスナップショットについては、後で説明します)。

Hyper-V のバックアップ
ホスト ベースのバックアップサーバー仮想化における興味深いメリットの 1 つは、仮想化システムを個別にバックアップする必要がないことです。現在、このようなシステムは、単にホストのファイル システム上に存在するファイルでしかないので、このファイルのバックアップを作成すれば作業完了と言いたいところですが、必ずしもそうではありません。このようなシステムも、メモリ内データ、ディスク上のデータ、システム構成ファイル、および開いているファイルで構成された実行中のコンピュータなので、考慮しなければならないことがあります。では、このような動的な要素を考慮しながらバックアップ データの整合性を確保するにはどうしたら良いでしょうか。
Windows Server のバックアップ機能は、Windows Server 2003 で VSS が登場したときに大きな進歩を遂げました。VSS では、VSS ライタが開いているファイルやアプリケーションのバックアップを使用する際に使用する拡張可能な API の標準セットを提供します (VSS ライタは、整合性のあるシャドウ コピーを提供するのに役立つアプリケーションやサービスにあるフックです)。VSS サービス、プロバイダ、およびライタにより、バックアップ アプリケーションでは、アプリケーションが認識できて、かつ適切に処理できる形でボリュームの特定時点のコピーを迅速に作成できます。
Hyper-V には、独自の VSS ライタが用意されています。このライタを使用するとソフトウェア ベンダは、魅力的なバックアップ ソリューションを作成できます。また、このライタを使用すると、バックアップ アプリケーションでは、実行中の VM のホスト ベースの VSS バックアップを作成することができます。VM で実行されているオペレーティング システムに Hyper-V の統合コンポーネントと VSS サービスがインストールされている場合、ゲスト システムとして実行されているときと同じようにホスト ベースのバックアップが作成されます (このコンポーネントとサービスは、Windows XP SP1 と Windows Server 2003 以降で使用できます)。このバックアップは、実行中の VM に対して行われ、データの整合性は維持されます (図 4 参照)。
図 4 VSS によるバックアップ (画像をクリックすると拡大表示されます)
ただし、ゲスト オペレーティング システムで統合コンポーネントまたは VSS がサポートされていない場合、バックアップ処理では、ゲスト コンピュータが保存された状態であることと、ホスト ベースの VSS スナップショットが特定の時点への復旧に使用できる VM データ ファイルから作成したものであることが必要になります。また、保存された状態の VSS スナップショットが原因で、VM ではダウンタイムが発生します (通常、ダウンタイムは 5 ～ 10 分程度です)。これは、VSS のコピー データに対してテープへの完全バックアップが行われることにより生じるものです。
ゲスト ベースのバックアップ物理的な環境では、サーバーやアプリケーションは個別にバックアップを作成する必要があります。また、このようなバックアップは、当然、仮想化されたデータセンターでも問題なく機能します。仮想化されたデータセンターで VM のバックアップを作成するときにも、同じようなことを考慮する必要があります。たとえば、ネットワーク ベースのバックアップではネットワーク キャパシティの要件を考慮したり、バックアップの時間帯にはシステムのパフォーマンスへの影響を考慮したりする必要があります。ゲスト ベースのバックアップでは、ホスト システムに搭載されていて、すべてのゲストが使用する仮想ネットワークにバインドされた専用の物理 NIC を使用することもできます。

Windows Server バックアップ
Windows Server 2008 には、ホスト ベースまたはゲスト ベースの Hyper-V VM のバックアップを作成するのに使用できる VSS 対応の Windows Server バックアップ (WSB) 機能が用意されています。VSS に完全に対応しているので、実行中の VM のホスト ベースのバックアップを作成することができます。言うまでもありませんが、これは非常に望ましいことです。
ただし、統合コンポーネントがインストールされていない VM では VSS は使用できません。このような場合に使用できるオプションは 2 つあります。1 つは、統合コンポーネントがインストールされていない VM のバックアップに WSB を使用することが可能です。この場合、VM の状態が保存され、バックアップ処理で VM の仮想ディスクと構成ファイルが取得されます。
ただし、この方法は Exchange Server などのアプリケーションには適していません。というのも、アプリケーションでは、バックアップが実行されたことが認識されないため、アプリケーションのログが、切り捨てられず、そのまま維持されるからです。また、VM ではダウンタイムが発生します (ダウンタイムの時間はバックアップにかかる時間によって異なります)。
もう 1 つのオプションとしては、NTBackup または WSB のどちらかを使用して、物理コンピュータの場合と同様に、VM 内からバックアップを実行できます (使用するツールは、VM で実行されている OS によって異なります)。次は、統合コンポーネントがインストールされていて、WSB がサポートされているゲスト OS で WSB を使用する方法をご紹介しましょう。

WSB による VM のバックアップ
Hyper-V では、WSB で使用するように VSS ライタが自動的に登録されることはありません。WSB で Hyper-V のバックアップがサポートされるようにするには、図 5 に示すレジストリ キーとレジストリ値を手動で追加する必要があります。このレジストリ キーと値は、コマンド ラインで次の構文を使用して追加できます。
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}"
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /v
  "Application Identifier" /t REG_SZ /d Hyper-v
図 5 Hyper-V の VSS ライタを登録するレジストリ キーとレジストリ値
パス | レジストリ キー/値 | 種類
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE} | キー | n/a
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}\Application Identifier | 値 | REG_SZ (Hyper-V など)
WSB ではバックアップの実行時に、このキーと値を検索するので再起動は必要ありません。エントリが設定されたかどうかは、次のコマンドを実行して確認できます。
reg query "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /s
では、次は WSB のインストール方法を紹介しましょう。[スタート] ボタンをクリックし、[サーバー マネージャ] をクリックします。左側のウィンドウで [機能] をクリックし、右側のウィンドウで [機能の追加] をクリックします。[機能の選択] ページで [Windows Server バックアップの機能] を展開し [Windows Server バックアップ] チェック ボックスと [コマンドライン ツール] チェック ボックスをオンにします。それから、以下の手順に従います。
  1. [スタート] ボタンをクリックし、[管理ツール] をクリックし、[Windows Server バックアップ] をクリックします。
  2. リモート ホストのバックアップを作成する場合は、[別のコンピュータへ接続] を選択して、Hyper-V ホストを指定します。
  3. [バックアップ (1 回限り)] または [バックアップ スケジュール] のどちらかを選択します。
  4. [バックアップの構成の選択] ページで、[サーバー全体] または [カスタム] を選択します。[カスタム] を選択した場合は、バックアップを作成する VM に関連したデータを含む全ボリュームを指定する必要があります (これには、VM 構成データ、仮想ディスク、スナップショットが含まれます)。
  5. バックアップの保存先を選択します。
  6. [VSS 完全バックアップ] または [VSS コピー バックアップ] のどちらかを選択します。VM のバックアップが実行されていないホスト ベースのバックアップでは、[VSS 完全バックアップ] を選択します。
  7. 詳細を確認したら、[バックアップ] を選択します。
考慮事項
  • VM に関連している全ボリュームのバックアップを作成する必要があります。これには、仮想ハード ディスク (VHD)、VM 構成ファイル、およびスナップショットが含まれます。
  • バックアップ スケジュールを作成している場合は、WSB 専用にフォーマットして使用する専用のローカル ボリュームを使用する必要があります。1 回限りのバックアップを作成している場合は、非専用のローカル ボリューム、リムーバブル デバイス、またはネットワーク共有にバックアップを保存できます。
  • バックアップ対象の VM に統合コンポーネントがインストールされていない場合、WSB では、バックアップ データの整合性を確保するために実行中の VM の状態が保存されます。
  • バックアップが完了したら、バックアップ セットは、移植して、任意の Hyper-V ホストで使用できます。
WSB による VM の復元
WSB には個別のファイルを復元する機能が備わっていますが、この機能では VSS を使用しないため、バックアップ時に VM が実行されていると復元時に整合性が失われることがあります。実行中の VM を復元するには、ボリューム全体を復元する必要があります。
これを行うには、[スタート] ボタンをクリックし、[管理ツール] をクリックして、[Windows Server バックアップ] をクリックします。次に、[操作] ウィンドウで [回復] を選択します。データの復元元となるサーバー (WSB バックアップ データが保存されているサーバー) を選択し、復元元となるデータを選択します。この時点で回復の種類を選択します。
ここでは状況に応じてオプションを選択します。ホスト全体で障害が発生した場合など VM 全体 (VM 構成ファイル、スナップショット、仮想ディスクを含む) を復元する場合は、[Application Restore] (アプリケーションの復元) を選択して、[Hyper-V] を選択します (図 6 参照)。この場合は、個別のファイルを復元するオプションは表示されません。バックアップ セットに含まれているものすべてを復元する必要があります。この操作により、既存の Hyper-V やバックアップ以降に変更された VM 構成データが上書きされることはありません。
図 6 Hyper-V バックアップの復元 (画像をクリックすると拡大表示されます)
VHD だけが必要で、VM の構成データとスナップショットに問題がない場合は、[ファイルおよびフォルダ] を選択して、復元する VHD ファイルを選択できます。この処理では VSS ライタを使用しません。VM のバックアップは、このことを考慮して、VM の状態を保存した状態で、作成されている必要があります。
システム全体に及ぶ障害とデータ損失が発生し、Windows Server 2008 オペレーティング システムとそこで実行されている全 VM を含む Hyper-V ホスト自体を復元する必要がある場合は、Windows 回復環境を起動して、そこから復元を行う必要があります。このような復元は、Windows Server 2008 セットアップ ディスクまたは事前に構成されたディスク パーティションから実行できます。

Data Protection Manager
ここまでは、無料で使用できて安定性のある組み込みの WSB を使用して、Hyper-V ホストとゲストをバックアップおよび復元する手順と考慮事項を紹介しました。しかし、WSB は、企業レベルで使用するデータ保護ソリューションではありません。WSB が適していない場合は、Data Protection Manager (DPM) 2007 SP1 が適しています。現時点で 2008 年後半にリリースが予定されている DPM 2007 SP1 では、Hyper-V がサポートされ、次のような魅力的な機能が提供される予定です。
  • すべての Hyper-V のホストとゲストに対応した単一の管理コンソール。
  • VSS ベースのスナップショットをキャプチャする継続的なデータ保護 (最大 15 分間隔で、変更された部分のみのスナップショットをキャプチャします)。
  • Hyper-V クラスタの認識。VM がクラスタ ノード間を移動してもバックアップで VM を追跡できます。
  • DMP サーバーから DPM サーバーへのレプリケーション。
  • ディスク メディアとテープ メディアのサポート (ディスク間、ディスクからテープ、D2D2T (Disk to Disk to Tape) のバックアップがサポートされます)。
  • 全データに対応したバックアップと復元機能。対応データには、Hyper-V のホストとゲスト、実行中ゲストのエージェントレスな VSS のバックアップ、個別の VM の復元、フェールオーバー クラスタのデータ、SQL Server、Exchange Server、SharePoint、Hyper-V、Virtual Server など、そのクラスで最高レベルのアプリケーション固有の機能などがあります。
  • バックアップ前およびバックアップ後のスクリプトによる処理。
現在、サードパーティ製のソリューションを使用している場合は、アプリケーションの更新プログラムに注意してみてください。多くのベンダでは、Hyper-V ホスト ベースのソリューションを市場に提供することに積極的に取り組んでいます。

スクリプトによるバックアップ
WSB には、WBadmin.exe という名前のコマンド ライン インターフェイスと、スクリプトで使用する一連の Windwos PowerShell コマンドレットが用意されています。これらを使用する際にも、ここまでに説明したバックアップの規則が適用され、レジストリを編集して Hyper-V の VSS ライタを手動で登録する必要があります。
図 7 に、WBAdmin で使用できるコマンドの一部を示します。WBAdmin の詳細については、go.microsoft.com/fwlink/?LinkId=124380 を参照してください。おわかりのように、WBAdmin には、バックアップ ポリシー自体を構成するものはありません。しかし、これらの設定は Windows PowerShell スナップインを使用して管理できます。このスナップインが登録されているかどうかは、次のコマンドを実行して確認できます。
Get-PSSnapin -Registered
図 7 WBAdmin のコマンド
WBAdmin のコマンド | 説明
ENABLE BACKUP | スケジュールされた毎日のバックアップを変更または有効にします。
DISABLE BACKUP | スケジュールされた毎日のバックアップの実行を無効にします。
START BACKUP | バックアップを実行します。
STOP JOB | 現在実行中のバックアップまたは復元を停止します。
GET VERSIONS | 特定の場所にある復元可能なバックアップの詳細情報を一覧表示します。
GET ITEMS | バックアップに含まれている項目を一覧表示します。
START RECOVERY | 復元を実行します。
GET STATUS | 現在実行中のジョブの状態を一覧表示します。
GET DISKS | 現在オンラインのディスクを一覧表示します。
START SYSTEMSTATERECOVERY | システム状態の回復を実行します。
START SYSTEMSTATEBACKUP | システム状態のバックアップを実行します。
DELETE SYSTEMSTATEBACKUP | システム状態のバックアップを削除します。
次のコマンドを使用して、windows.serverBackup という名前のスナップインを読み込めます。
Add-PSSnapin windows.serverBackup
このスナップインを読み込むと、WSB に対応した Windows PowerShell コマンドレット (図 8 参照) を使用できるようになります。各コマンドレットの詳しい説明を表示するには、次のコマンドを実行します。
Get-Command -PSSnapin windows.serverBackup | select name | get-help –full
図 8 Windows Server バックアップのコマンドレット
コマンドレット | 説明
Add-WBBackupTarget | バックアップ ポリシーにバックアップ先を追加します。
Add-WBVolume | バックアップ ポリシーにボリュームを追加します。
Get-WBBackupTarget | ポリシーからバックアップ先を取得します。
Get-WBDisk | すべてのディスクを取得します。
Get-WBPolicy | 現在のバックアップ ポリシーを取得します。
Get-WBSchedule | ポリシーからバックアップ スケジュールを取得します。
Get-WBSummary | バックアップの履歴と概要を取得します。
Get-WBVolume | すべてのボリュームを取得します。
New-WBBackupTarget | 新しいバックアップ先を作成します。
New-WBPolicy | 新しい空のポリシーを作成します。
Remove-WBBackupTarget | バックアップ ポリシーからバックアップ先を削除します。
Remove-WBPolicy | バックアップ ポリシーを削除します。
Remove-WBVolume | バックアップ ポリシーからボリュームを削除します。
Set-WBPolicy | WBPolicy オブジェクトを保存して、スケジュールされたバックアップを作成します。
Set-WBSchedule | バックアップ ポリシーにスケジュールを設定します。

Windows Server 2008 には、WSB 以外に、Hyper-V の VSS ライタを使用して、柔軟にスクリプトを作成するのに役立つ DiskShadow.exe という名前のユーティリティが用意されています。DiskShadow.exe を使用すると、シャドウ コピーを作成して、ドライブとしてマウントできるので、管理者は、WSB よりも選択的にバックアップを作成できます。DiskShadow では、Windows PowerShell パイプラインの入力が受け付られないので、DiskShadow にはスクリプト経由でコマンドを渡す必要があることを覚えておく必要があります。これには、次のようなスクリプトを使用します。
Delete Shadows Volume C:
Set Context Persistent
Begin Backup
Writer Verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
Add Volume C: ALIAS MyShadow
Create
End Backup
Expose %MyShadow% X:
Exit
このスクリプトでは、まずドライブ C の既存のシャドウ コピーを削除し、その後、DiskShadow の実行後にもシャドウ コピーが存続できるようにしています。次に、トランザクション ブロックを作成して、なんらかのステップでエラーが発生すると、この処理自体がエラーになるようにしています。このブロックでは、DiskShadow は Hyper-V のライタが読み込まれていることと、ドライブ C がバックアップするドライブの一覧に追加されていることを確認します。
ドライブ C には、ドライブを識別するための GUID が割り当てられ、この GUID は MyShadow という名前の環境変数に格納されます。この処理が完了すると、シャドウ コピーが作成されます。
バックアップは、MyShadow 環境変数を使用して、ドライブ X として公開されます。ドライブ X 上にあるデータに対してはさまざまな処理を行えます。また、DiskShadow で「Unexpose X:」というコマンドを実行すると、ドライブ X を削除できます。
ただし、現時点では、DiskShadow を使用してバックアップを作成した Hyper-V VM の復元は手動で行う必要があります (VM を再度作成する必要があったり、スナップショットが維持されないなどの問題があります)。いくつかの明らかなデメリットがありますが、データは保護されます。
まとめ
DR は、一見すると終わりがない困難な作業になることがあります。しかし、サーバー仮想化は、テクノロジと低価格な導入コストという 2 つの面から新しい可能性をもたらしました。マイクロソフトは、仮想化だけではなく、エコシステムを提供します。サーバー仮想化プラットフォームと System Center ファミリ製品により、DR など、複雑化の一途を辿る組織が直面している難題に対応するより総合的なソリューションを提供します。
この記事の執筆にご協力いただいた James O'Neill 氏に感謝します。

Adam Fazio は、約 2 年前からマイクロソフト コンサルティング サービスに従事しており、現在は米国政府のとある事務所に駐在しています。IT 業界でのキャリアは 10 年以上で、Fortune 100 の企業でのさまざまなインフラストラクチャ プロジェクトやデータセンターの運用から、インターネットの開設まで、さまざまな事業に従事してきました。現在は、マイクロソフトが世界規模で展開している Virtual Rapid Deployment Program のテクニカル エスカレーション リードを務めています。


仮想化
仮想インフラストラクチャを計画するための必携ツール
Jay Sauls、Baldwin Ng
概要 :
  • コストを抑える
  • コンピュータのインベントリを実行する
  • CPU、ディスク I/O、およびネットワーク使用率を確認する

目次
ツールの概要
環境の現状を把握する
現在の使用率を確認する
サーバーの推奨配置構成
仮想マシンの構成
配置に関する制約
オプションを検討する
要件
まとめ
仮想化は新しいテクノロジではありませんが、1960 年代に IBM が開発した最初のプラットフォーム仮想化をはるかに越えて、さまざまな新しい領域へと急速な広がりを見せています。この急速な成長の理由は、仮想化テクノロジが、データセンターのコストと IT の運用全体にかかるコストを抑えるうえで役立つ可能性があるからです。エネルギー コストが上昇し、組織内のさまざまな部分で IT サービスを求める声が高まる中で、運用コストを抑えながら、必要なサーバーの拡張を進めることに悪戦苦闘している管理者もいるでしょう。そのような場合に、仮想化が役立ちます。マイクロソフトをはじめとするソフトウェア ベンダは、サーバー、デスクトップ、アプリケーションの仮想化など、仮想リソースのより広範な利用を可能にする新しいテクノロジの開発を進めています。
この記事では、仮想化プロジェクトを支援するツールセットである Microsoft Assessment and Planning Toolkit (MAP) について説明します。MAP は Microsoft Solution Accelerator ファミリ製品の 1 つです。ソリューション アクセラレータとは、簡単に言うと、ほぼすべての IT プロジェクトで必要になる自動化ツールとガイダンスをまとめたものです。ソリューション アクセラレータは、デスクトップからサーバー、および物理環境から仮想環境にいたるまで、IT インフラストラクチャの計画、導入、運用を積極的に進めるのに役立つ、信頼性の高い無償のリソースです。
業界の専門家が共同で設計し、実際の顧客環境でテストされたソリューション アクセラレータでは、管理者がわざわざ頭を悩ますことなく、高いパフォーマンスを実現し、異種製品で構成される IT インフラストラクチャを構築できるよう、規範となる適切なガイダンスと自動化機能が提供されます。これらのリソースは、あらゆる規模の企業で重要な課題となるインフラストラクチャの評価と計画、仮想化、コミュニケーションとコラボレーション、セキュリティと法令遵守などに対応しています。

ツールの概要
新しくリリースされた MAP Toolkit 3.1 (図 1 参照) は、サーバーとデスクトップに関する基本情報をすばやく把握するのに役立つ、ネットワーク全体のインフラストラクチャを評価するためのツールです。このツールを使用して、Hyper-V、Microsoft Application Virtualization、Windows Server 2008、Windows Vista、Office 2007、SQL Server などのテクノロジにサーバーとデスクトップをアップグレードまたは移行する準備ができているかどうかを確認できます。
図 1 Microsoft Assessment and Planning Toolkit 3.1 (画像をクリックすると拡大表示されます)
MAP によって対応状況に関する評価レポートと提案が自動的に生成されるため、MAP を使用しなかった場合にユーザーが手動で実行しなければならなかった作業の多くを省略できます (図 2 参照)。MAP Toolkit 3.1 は、サーバー シナリオとデスクトップ シナリオの両方をサポートしているため、デスクトップ コンピュータを Windows Vista にアップグレードできるかどうかを評価したり、Microsoft Application Virtualization の展開計画を立てたりする場合などに使用できます。
図 2 自動生成された移行に関する提案の例 (画像をクリックすると拡大表示されます)
サーバーの仮想化を計画するときに有力な候補となる物理コンピュータを特定するうえで役立つ重要な機能が 3 つ提供されます。これらは、サーバーのインベントリ、パフォーマンス メトリックの収集、および仮想化の推奨配置構成です。次に、これらの機能を使用して現在の環境の状態を詳しく把握し、仮想化への移行を計画する方法について説明します。

環境の現状を把握する
大規模な企業の多くは、System Center Operations Manager など、なんらかのサーバー管理インフラストラクチャを導入しています。ただし、それらの中には、それほど積極的に管理されていない環境もあります。自社の環境にどのようなサーバーが導入されているか、またはそれらのサーバーでどのようなプログラムが実行されているかをあまりよく理解していない場合、サーバー インベントリ機能を使用すると、そのような状況を正確に把握できます。サーバー インベントリは、Active Directory や IP アドレス範囲のスキャンを行うか、単純にフラット ファイルからコンピュータの一覧をインポートすることで、環境内のコンピュータを検出できます。また、複数の検出方法 (Active Directory と IP アドレス スキャンなど) を組み合わせて使用することで、Active Directory に登録される必要があるが、まだ登録されていないコンピュータを検出することもできます (図 3 参照)。
図 3 コンピュータの検出方法の選択 (画像をクリックすると拡大表示されます)
コンピュータが検出されると、MAP Toolkit 3.1 は各コンピュータに接続し、Windows Management Instrumentation (WMI) を使用して 50 種類を超えるデータの取得を試みます。このデータを基に、数種類のレポートを生成できます。仮想化を使用したサーバー統合に最も役立つレポートは、[Migrate specific roles and services to Windows Server 2008] (特定の役割とサービスを Windows Server 2008 に移行する) を選択したときに作成されるレポートです。
今すぐ Windows Server 2008 への移行を行わない場合でも、このシナリオで作成される 2 種類のレポートは、環境内にあるハードウェアの種類 (プロセッサの種類と速度、ディスクのサイズ、搭載されているメモリなど)、および各サーバーに割り当てられているソフトウェアの役割 (DNS サーバー、ドメイン コントローラ、ターミナル サービス) を確認するうえで非常に役立ちます。
これらのレポートは Microsoft Excel ブック形式で作成されるため、Excel の並べ替え機能やフィルタ機能を使用して、環境内のどのコンピュータが仮想化の候補になるかを簡単かつ正確に特定できます。
サーバー インベントリ レポートでは、仮想化するサーバーを選択するときに検討できるいくつかの属性に関するデータが提供されます。たとえば、Hyper-V 仮想化プラットフォームでサポートされる OS が、仮想化するコンピュータで実行されているかどうかを確認するとします。サーバー インベントリの処理によって作成された WS2008HardwareAssessment Excel ブックの [Server Inventory] (サーバー インベントリ) タブにある [Current Operating System and Service Pack] (現在のオペレーティング システムとサービス パック) 列を確認して、アップグレードが必要な可能性のあるシステムを見つけることができます。

現在の使用率を確認する
仮想化の候補を特定するために行う次の手順は、物理コンピュータがどの程度使用されているかを測定することです。MAP Toolkit 3.1 の Performance Metrics Wizard (パフォーマンス メトリック ウィザード) (図 4 参照) を使用すると、仮想化の候補として識別した一連のコンピュータのパフォーマンス カウンタを記録できます。CPU、ディスク I/O、およびネットワークの使用率がすべて、後で確認できるようにキャプチャされます。
図 4 Performance Metrics Wizard (画像をクリックすると拡大表示されます)
このウィザードは、かなりの長期間 (最高 1 か月) にわたってコンピュータを監視することを目的としており、使用方法をある程度柔軟に選択できます。環境内で使用率が最も高くなる時間帯 (たとえば、週に 1 回実行するバッチ処理の時間帯) を既に把握している場合は、その時間帯に合わせて、数時間のみこのウィザードを実行するように設定できます。使用率が最も高くなる時間帯を把握していない場合や、使用率がピークを迎える時間帯が異なる多くのコンピュータを監視する場合は、数日間または数週間にわたってコンピュータのデータを記録するようにウィザードを設定できます。これで、より多くのデータから使用率のピークを自動的に特定できます。
以前収集したインベントリ情報を基に、Excel の並べ替え機能とフィルタ機能を使用して、監視するコンピュータの一覧を作成します。Performance Metrics Wizard では、この一覧を、1 行に 1 台のコンピュータ名が入力されたフラット ファイルとして取り込むことができます。コンピュータ名の一覧を、Excel からコピーし、メモ帳で開かれた空白の新しいテキスト ファイルに貼り付け、このファイルを保存します。指示が表示されたら、このファイルをウィザードにインポートし、パフォーマンス メトリックを収集する期間の終了時刻を設定します。ウィザードがデータ収集モードになり、指定したコンピュータから 5 分おきにパフォーマンス カウンタが収集されます。
Performance Metrics Wizard の処理が完了すると、監視されたすべてのコンピュータと、複数のカテゴリ (CPU、物理ディスク、論理ディスク、およびネットワーク) の使用率を示すパフォーマンス メトリックがすべて記載された詳細な Excel レポートが作成されます。この情報を使用し、仮想化の候補として検討するコンピュータをさらに絞り込むことができます。
使用率がきわめて低いコンピュータを特定し、このようなコンピュータを仮想マシン (VM) として 1 台のホストに統合したり、上記の情報とインベントリ データを組み合わせて、高い可用性が要求されるミッション クリティカルなサービスを提供しているコンピュータを特定したりできます。また、仮想化を使用して、高い可用性が要求される環境に高度な障害回復機能を提供することもできます。分析が完了したら、最後の手順に進み、仮想マシンの推奨配置構成を生成します。

サーバーの推奨配置構成
Server Virtualization and Consolidation Wizard (サーバーの仮想化および統合ウィザード) を使用すると、仮想ホスト コンピュータの仮の構成 (CPU、ネットワーク、ディスク サブシステム、およびメモリ) を指定できます。このウィザードでは、Performance Metrics Wizard によって収集されたパフォーマンス データを使用して、VM ゲストと VM ホストの適切なマッピングを算出し、ピーク時の過剰な使用率を回避して、各ホストが適切に使用されるようにします。
Server Virtualization and Consolidation Wizard の処理が完了すると、ゲスト VM と物理ホストのマッピング案が記載された詳細な Excel スプレッドシートが作成されます。このレポートでは、VM とホストごとに、予想されるディスク I/O、ネットワーク I/O、および CPU 使用率が提供されます。この対応付け処理の実行中、ゲスト VM が物理ホスト コンピュータに追加されるときに、使用されるリソースの量が既存のホスト コンピュータの許容量に達した場合、新しいホスト コンピュータが割り当てられます。新しいホストが割り当てられるたびに、その理由を示すメッセージが表示されます。
いくつかのホストで同じメッセージが表示される場合は、別のホスト構成で Placement Wizard (配置ウィザード) を再度実行して、各ホストに割り当てられるゲスト数を増やしてください。たとえば、いくつかのホストでメモリの容量が上限に達したことを示すメッセージが表示される場合は、ウィザードを再度実行して、より多くの RAM を使用するようにホスト構成を指定できます。これにより、各ホストに割り当てることができるゲスト数が増加します。

仮想マシンの構成
Server Virtualization and Consolidation Wizard の各ページでは、VM ホスト コンピュータの容量モデルを作成するときに使用される、仮のコンピュータ構成の主な要素を構成できます。Virtual Server 2005 R2 と Hyper-V の両方のモデルが用意されているため、ウィザードの最初のページで、どちらの仮想化テクノロジを使用するかを指定します (図 5 参照)。
図 5 推奨配置構成に使用する仮想化テクノロジの選択 (画像をクリックすると拡大表示されます)
CPU の構成ページでは、AMD と Intel から提供されているいくつかの CPU ファミリに対応したモデルが提供されます。使用している CPU に対応したモデルが提供されない場合は、最も近いものを選択します。このページでは、物理プロセッサ数、コア数、およびコアあたりのハイパースレッド数を構成できます。仮想化プラットフォームに Hyper-V を選択した場合は、選択肢として 64 ビット CPU のみが表示されます (図 6 参照)。
図 6 ホストの CPU の構成 (画像をクリックすると拡大表示されます)
ウィザードの 3 ページ目では、ディスク サブシステム (ディスク ドライブ数と RAID テクノロジ) を構成して、ホスト上で利用可能なディスク領域の合計と、ディスク サブシステムのスループット値を計算できます。スループット値は、インターフェイス テクノロジと、選択されたディスクの信頼性とパフォーマンス モニタ (RPM) の速度に基づいて自動的に提供されます。
MAP Toolkit 3.1 では、記憶域ネットワーク (SAN) とネットワーク接続ストレージ (NAS) ディスク ソリューションのモデリングは直接サポートされません。おおよその構成を推測するには、SCSI ディスク テクノロジを選択し、使用している SAN の構成に近い RAID レベルと、その構成に近い速度のディスクを指定します。計画を開始するときに役立てるために、ここで実際の構成に近い推測値を得る必要があります。

配置に関する制約
仮想化されたゲスト コンピュータを物理ホストにマップするときは、以下の 6 つのことを考慮して、ホスト コンピュータの残りの容量でゲストを割り当てることができるかどうかを評価します。
  • CPU 使用率
  • ネットワーク I/O の使用率
  • ディスク サブシステム I/O の使用率
  • メモリ
  • ディスク容量
  • 指定した仮想テクノロジでのゲスト OS のサポート状況
CPU、ネットワーク、およびディスク サブシステムの使用率に関する制約は、かなり単純です。仮想ゲストの候補である物理コンピュータ上で計測された使用率が、仮想ホスト コンピュータ上でこれに相当する使用率に変換された後、ホストの既存の使用率に追加されます。ホストに割り当てられ、そのホストのリソースを使用するすべてのゲストの最終的な使用率の合計がしきい値の制限に満たない場合は、ゲストがそのホストに割り当てられます。しきい値を超える場合、そのゲストは割り当てられず、代わりに他のゲストを割り当てることができるかどうかが確認されます。
たとえば、CPU 使用率が 32% の 1.2 GHz Pentium 4 CPU が搭載されたコンピュータのパフォーマンス メトリックを収集したとします。クアッドコアの Intel Xeon 5300 シリーズの CPU を搭載した仮想ホストを構成する場合、ゲスト コンピュータの候補で計測された元の CPU 使用率から、ホスト コンピュータ上でこれに相当する予想使用率が推測されます。ホスト CPU のアーキテクチャが新しく、クロック速度も異なり、コア数も多いため、この新しく推測された使用率は、計測された元の値よりも低くなります。
逆に、ゲストの CPU よりも性能の低い CPU が搭載されたホスト コンピュータを構成する場合、このホストの予想使用率は高くなります。いずれの場合も、新しく推測された CPU 使用率を使用して、ゲストがホストに割り当てられた場合のホスト コンピュータ全体の使用率が計算されます。
メモリとディスク領域の使用率がどのように決定されるかについても、簡単に説明しておきましょう。各仮想ゲストの候補に搭載されている物理メモリの合計量が、ホスト コンピュータ上で予約されます。さらに、少量のメモリ (512 MB) がホスト自体のために予約されます。ホストのメモリがすべて、割り当てられたゲストとホストのオーバーヘッドによって消費されている場合、そのホスト コンピュータにそれ以上仮想ゲストを割り当てることはできません。
ディスク領域も同様に処理されます。各仮想ゲストの候補で提供される物理ディスク領域の合計サイズが、ホスト コンピュータ上で予約されます。さらに、50 GB のディスク領域が仮想ホスト用に予約されます。ホストに割り当てられたすべてのゲストによって使用されるディスク領域の合計と、ホスト自体のために予約された領域を加算したサイズが、ホスト構成で指定されているサイズに達すると、それ以上ゲストを割り当てることはできなくなります。
選択した仮想化プラットフォームを基に、ゲスト コンピュータ上で実行される OS が実際にその仮想化プラットフォームによってサポートされるかどうかが確認されます。たとえば、Virtual Server 2005 R2 では 64 ビット OS を実行するゲストがサポートされないため、仮想化テクノロジとして Virtual Server 2005 R2 を選択した場合、64 ビット OS は配置されません。

オプションを検討する
Server Virtualization and Consolidation Wizard を複数回実行することで、仮想ホスト コンピュータ用に異なるハードウェアを選択した場合の結果を簡単に比較できます。ウィザードを実行するたびに、異なる CPU、ディスク、メモリを選択して、各環境に最適であると考えられる組み合わせを見つけることができます。
サーバー統合に関する Excel ブックの [Consolidation Recommendations] (統合に関する推奨事項) タブで [Last Placement Failed Reason] (最後の配置が失敗した理由) 列を確認します。この列に記載されている理由から、特定のホストにこれ以上ゲスト コンピュータを割り当てることができなかった理由に関するヒントをつかむことができます。ゲストのメモリ使用率がホストで利用可能なメモリ量を超えていることなど、複数のホストの理由が一致している場合は、ホスト構成のメモリ量を増やすと、必要なホスト数の合計を減らすことができる可能性があります。

要件
MAP Toolkit 3.1 のメリットの 1 つは、インベントリの実行対象であるコンピュータにソフトウェアをインストールする必要がないことです。すべての操作はリモートで実行されます。ただし、すべての処理が適切に実行されるようにするには、いくつかのことを考慮する必要があります。
Inventory Wizard (インベントリ ウィザード) と Performance Metrics Wizard の処理を完了するには、対象のコンピュータ上でいくつかの TCP ポートを開き、MAP Toolkit がインストールされているコンピュータからこれらのポートにアクセスできる必要があります。入門ガイドに詳細な説明が記載されていますが、簡単に紹介すると、認証用、DCOM 用、および WMI 用のポートが、インベントリの実行対象であるコンピュータ上で開かれている必要があります。MAP Toolkit 3.1 を実行するコンピュータとインベントリの実行対象であるコンピュータとの間のネットワークにファイアウォールがインストールされている場合、このトラフィックを許可するように、これらのファイアウォールを構成する必要があります。
MAP Toolkit 3.1 は、最高で 100,000 台のコンピュータから構成される環境のインベントリを実行し、最高で一度に 3,000 台のコンピュータからパフォーマンス メトリックを収集できるように設計されています。既定では、このツールによって、SQL Server 2005 Express Edition の専用インスタンスがインストールされます。SQL Server Express では、データベース ファイルのサイズが 4 GB に制限されているため、この構成では、SQL Server Express で適用されるファイル サイズの制限内に収まる約 20,000 台のコンピュータのインベントリしか実行できません。より多くのコンピュータを対象としたインベントリを実行するには、いくつかの既定の構成を変更する必要があります。
より規模の大きい環境で作業するには、SQL Server 2005 Standard Edition など、SQL Server の完全なバージョンを使用する必要があります。MAP Toolkit をインストールする前に、SQL Server 2005 の新しいインスタンスをインストールして、このインスタンスに "MAPS" という名前を付けてください。その後、同じコンピュータ上で通常どおり MAP Toolkit インストーラを実行します。MAP Toolkit には、SQL Server のローカル インスタンスが必要です。MAP Toolkit のインストーラは、SQL Server Express Edition をインストールせずに、自動的に SQL Server のローカル "MAPS" インスタンスを検出し、これに MAP Toolkit をインストールします。
さらに規模の大きい環境では、スケールアウト機能を使用できます。この機能を使用すると、MAP Toolkit がインストールされている複数のヘルパ コンピュータが連携して大規模なインベントリを実行し、すべてのデータをまとめて 1 つの一元管理データベースに格納できます。この構成でも、4 GB というファイル サイズの制限を回避するために、SQL Server Standard Edition を使用する必要があります。
この構成で MAP Toolkit をインストールする方法、およびこのモードでデータベース接続文字列を適切に編集する方法の詳細については、入門ガイドを参照してください。スケールアウト機能は、MAP Toolkit がインストールされるコンピュータ以外のコンピュータに SQL Server を配置する場合にも使用できます。

まとめ
Microsoft Assessment and Planning Toolkit のようなソリューション アクセラレータは、IT プロジェクトにおける面倒な作業をユーザーの代わりに担当してくれます。多くのユーザーは MAP Toolkit を使用することで、Hyper-V の展開作業に伴う IT に関する計画に必要とされる膨大な時間を節約できました。皆さんもこのツールを試してみてはいかがでしょうか。
必要に応じて、Microsoft Assessment and Planning Toolkit を microsoft.com/map から無償でダウンロードできます。その他の仮想化ソリューション アクセラレータを microsoft.com/vsa から入手することもできます。また、MAP Toolkit チームのブログ (blogs.technet.com/mapblog) で、その他のヒントを確認したり、デモ ビデオを視聴したりできます。

Jay Sauls は、マイクロソフトのソリューション アクセラレータ グループのシニア プログラム マネージャを務めており、Windows Vista Hardware Assessment や Microsoft Assessment and Planning Toolkit などの設計および導入ツールを担当しています。これまでは、Microsoft Commerce Server、Microsoft BizTalk、System Center Capacity Planner など、他のマイクロソフト製品チームの業務に携わっていました。

Baldwin Ng は、マイクロソフトのソリューション アクセラレータ コア エンジニアリング チームのシニア プログラム マネージャを務めています。現在携わっているプロジェクトは、Microsoft Assessment and Planning Toolkit と仮想化ソリューション アクセラレータです。マイクロソフト、Corbis、Alltel などで、IT、電子商取引、ワイヤレス インターネット サービス分野の製品管理と製品開発を 16 年にわたって経験しています。彼のブログ blogs.technet.com/MAPBLOG には、新しい記事が頻繁に追加されています。


編集長から 仮想 (化された) 世界
Joshua Hoffman

仮想化は特に目新しいものではありません。今月の編集後記の冒頭を飾るには、もう少し熱のこもった言葉を使うべきかもしれませんが、これは真実です。仮想化の概念 (基盤となるハードウェア リソースからオペレーティング システムを分離するという考え方) は、IBM の CP/CMS オペレーティング システムが登場した 1967 年から存在します。この概念はすっかり定着しているかもしれませんが、過去 40 年強の間に多くの変化が起こりました。
そして 2008 年になり、コンピュータの仮想化は転機を迎えています。コストの削減、管理の単純化、および持続可能なコンピューティングに関する手法の確立が必要になると共に、より強力なマルチコア プロセッサと新しいハイパーバイザ テクノロジが登場したことによって、仮想化がメイン ステージに躍り出るときがやってきました。これが今月号の TechNet Magazine のテーマです。今月号の TechNet Magazine では、Windows Server 2008 で提供される魅力的な新しい Hyper-V プラットフォーム、仮想環境を管理するためのツール、仮想アプリケーションの展開手法などについて詳しく説明した記事を紹介します。
ここからはもっと個人的な話になりますが、悪名高い Microsoft Scripting Guys として寄稿編集者を務めてきた Greg Stemp と Jean Ross に、TechNet Magazine の全スタッフを代表して感謝の意を表します。皆さんは、Microsoft Scripting Guys が実際は、片手に試験管を持ち、もう片方の手にスクリプトを持ってマイクロソフトの建物内を走り回っている、白衣を着た非常に頭の大きい小柄な人ではないことにショックを受けたかもしれません。このような人ではなく、Greg と Jean が過去 3 年間にわたって TechNet Magazine の Hey, Scripting Guy! コラムを執筆してきました。そして、2 人が執筆したコラムは世界中で高く評価されています。Hey, Scripting Guy! コラムは TechNet Magazine の中で最も人気のあるコラムとなっただけでなく、これまでに賞を獲得したり、数えきれないほどの称賛や読者からの電子メールをいただいたりもしています。
こうした理由や、他の多くの理由 (中でも特筆すべきは、私たちが 2 人を愛していることです) から、私たち TechNet Magazine のスタッフは、Greg と Jean に今月で別れを告げなければならないことを悲しく思っています。だれにでも当然起こることですが、Greg と Jean は今よりも良い環境に移ります。でもさいわいなことに、2 人は今後もレドモンドにあるマイクロソフトの建物内を歩き回って、マイクロソフト ユーザーのためにその才能を分け与えてくれます。私たちは 2 人の今後の成功を祈ると共に、2 人の言葉がいつか再び TechNet Magazine のページを飾ることを切に願っています。
当面は、私たちが次世代の Scripting Guys を探している間、Scripting Guys の卒業生というりっぱな経歴を持つ Dean Tsaltas が、一時的に Hey, Scripting Guy! の執筆を担当することを快諾してくれました。Dean は来月号の TechNet Magazine で、Windows Management Instrumentation について詳しく説明します。どうぞお見逃しなく。—Joshua Hoffman

次のマイクロソフト技術支援スタッフに心より感謝します。Karri Alexion-Tiernan、Carmen Asher、Scott Culp、Steve Ekren、Trina Gorman、Michael Michael、Mike Mitchell、Michael Murgolo、Rob Polly、Dan Reger、Jez Sadler、Bill Scheidel、Bryon Surace、Jim Truher


レター 読者の皆さんからの声

SQL データベースの管理
2008 年 8 月号の「SQL Server: 効果的なデータベース メンテナンスのヒント」(technet.microsoft.com/magazine/cc671165) は称賛に値する記事です。SQL Server というアプリケーションの正常な動作を確保し、確実にバックアップを行うことが任務である私たち "不本意な DBA" 向けの記事が、ついに SQL セクションに掲載されました。
そして、その直後のページには「Windows の管理 : サーバーのパフォーマンスを測定する」(technet.microsoft.com/magazine/cc718984) という記事が続いています。これはすばらしい内容でした。インターネット上の資料では問題を解決できなかったときのために、これら 2 つの記事を本誌から切り抜いて保管してあります。今後、これらを頻繁に読み返すことになるでしょう。これからも楽しみにしています。
2 つの記事をお楽しみいただけたようで何よりです。私たちの提供しているコンテンツがお役に立っていることを耳にするのは嬉しい限りです。大げさな賞賛の言葉もありがたくお受けしますが、それ以外のご意見も大歓迎です。今後掲載してほしいトピックがありましたら、お気軽にご連絡ください。皆さんからのご意見をお待ちしています。
—Joshua Hoffman (編集長)

ImageX と Windows PE
ImageX と Windows PE を使用した古いオペレーティング システムの展開に関するコラム (2008 年 2 月号の「Windows XP と Windows PE 2.0 によるデュアル ブート」、technet.microsoft.com/magazine/cc194422) を拝見しました。昨年、ImageX と Windows PE が役に立つ可能性があることに気付き、それまで会社で使用していたイメージング ツール (Acronis Snap Deploy) の代わりにそれらを使用するようになりました。半年ほど前に、望みどおりすべてうまく機能するようになったので、現在は ImageX 以外のイメージング ツールを使用していません。
その後、「Windows XP と Windows PE 2.0 によるデュアル ブート」を拝見したところ、bootsect.exe /n52 オプションの追加に関するアドバイスが記載されていました。このオプションについて耳にしたのは初めてです。イメージを適用する前に行う操作は、DiskPart と付属のスクリプト (commands.txt) を使用してハード ドライブのデータを消去することだけです。今のところ、この方法で問題が発生したことはありませんが、今後問題が発生する可能性はあるでしょうか。
当初は DiskPart コマンドを使用する必要がありましたが、この記事が掲載された後、そのコマンドはもう不要になったことをチームのメンバから教わりました。このコマンドが不要になった理由は、ブート コード _now_ のロジックで新しい形式のブート マネージャ コードが検索され、見つからなかった場合は、失敗する前に NTLDR が試行されるからです。このため、このコマンドを使用しなくてもまったく問題ありません。
—Wes Miller (コラムニスト、「デスクトップ ファイル」担当)

テスト イメージ環境
ImageX ツールを使用したイメージの実装と、Windows 展開サービス (WDS) を使用したマルチキャストの有効化に関する「デスクトップ ファイル」コラム (「Windows XP と Windows PE 2.0 によるデュアル ブート」) を拝見しました。テスト環境を実装するにあたって、必要なツールを正確に把握したいと考えています。マルチキャストを実装するために、Windows Server 2008 をインストールする必要はあるでしょうか。また、ミラー イメージを実装する場合は、ImageX を使用して Deployment 4 をインストールすればよいでしょうか。それとも Windows 自動インストール キット (WAIK) と WDS をインストールした方がよいでしょうか。
WDS を使用してマルチキャストを利用するには、Windows Server 2008 をインストールする必要があります。Windows Server 2003 ではマルチキャスト コンポーネントを (今後も含めて) 利用できません。
マルチキャストを使用する場合、Deployment 4 は必要ありませんが、Windows Server 2008 と、Windows Server 2008 用 WAIK の製品版を入手する必要があります。WAIK の製品版で初めて、Windows PE へのマルチキャストに必要なコンポーネントが追加されました。
—Wes Miller

WDS マルチキャスト
ImageX を使用して、コンピュータへの (およびコンピュータからの) イメージの複製を実行しようとしたのですが、すぐに問題に直面しました。それは、ImageX でマルチキャスト転送がサポートされていないことです。WDS サーバーでマルチキャスト転送を使用して同じ処理を実行しようと思いますが、それは可能でしょうか。Wdsmcast コマンドを使用するとうまくいくのではないかと思います。どのイメージをダウンロードするかを WDS クライアントから WDS サーバーに通知するにはどうすればよいでしょうか。
確かに、ImageX 自体はマルチキャストを処理できません。このため、Wdsmcast (Windows Server 2008 WAIK に収録されています) を使用して、接続先の転送を (サーバー上でその転送を開始した後に) 指定する必要があります。ホワイト ペーパー「トランスポート サーバーを使用する」(technet.microsoft.com/library/cc725964) には、Wdsmcast を使用して接続を確立する方法に関する適切な情報が記載されています。「Wdsmcast.exe を使用して名前空間にクライアント サーバーを接続する方法」セクションを参照してください。
—Wes Miller

連絡先 質問やコメントがありましたら、tnmag@microsoft.com (英語のみ) 宛てに電子メールをお送りいただくか、私たちのブログ フォーラム (blogs.technet.com/tnmag) をご覧ください。


ツールボックス IT プロフェッショナル向けの新製品
Greg Steen

すべての価格は 2008 年 8 月 19 日時点のものであり、変更される可能性があります。このコラムに記載されている見解は、執筆者の個人的な見解であり、必ずしもマイクロソフトの見解を反映するものではありません。

アプリケーションを携帯する
PortableApps.com
PortableApps.com
IT プロフェッショナルの皆さんは、あるコンピュータから別のコンピュータに何度も移動することがあると思います。こんなとき、標準的なアプリケーション、ツール、およびドキュメント セットがすぐ手の届くところにあればいいのに、と思うこともあるでしょう。このようなニーズを満たす優れた方法の 1 つは、PortableApps.com で提供されているようなランチャー プラットフォームを使用して作業を開始することです。PortableApps.com では、無償かつオープンソースの PortableApps.com Platform に加えて、USB フラッシュ ドライブ、メモリ カード、ポータブル ハード ドライブ、またはデジタル音楽プレーヤーから単独で実行できる、多数のポータブル アプリケーションが提供されています。
この Web サイトでは、PortableApps.com Suite という製品も提供されています。この便利なダウンロード パッケージでは、一連の利用可能なポータブル アプリケーションと基本プラットフォームが、すべて 1 つのインストーラにまとめられています。PortableApps.com Suite には 2 つのバージョンがあります。Suite Light には、Mozilla Firefox、Mozilla Thunderbird、Mozilla Sunbird、ウイルス対策ソフトウェアの ClamWin、インスタント メッセージング アプリケーションの Pidgin、PDF リーダーの Sumatra PDF、パスワード管理ソフトウェアの KeePass、ワードプロセッサの AbiWord、オーディオ プレーヤー、およびいくつかの単純なゲームが含まれています。Suite Standard には、これらすべてのアプリケーションに加えて、OpenOffice.org オフィス スイート (Writer、Calc、Impress、Base、および Draw) が含まれています。
さらに、この Web サイトでは、多くのオープン ソース アプリケーションの "ポータブル" 版が公開されています。たとえば、FTP アプリケーションの FileZilla、telnet および SSH 接続アプリケーションの PuTTY、SFTP および SCP アプリケーションの WinSCP、簡単なメモ作成ツールの PNotes と Task Coach、アーカイブ アプリケーションの 7-Zip、コマンド プロンプト、ファイルを削除する Eraser、CD/DVD を作成する InfraRecorder、ディスクの内容を視覚化する WinDirStat、ファイルを検証する winMd5Sum、ファイルやディレクトリを比較する WinMerge などがあります (この「ツールボックス」コラムを普段から読んでいる方なら、以前の記事でこれらのアプリケーションの多くが紹介されていることにお気付きでしょう)。
また、非常に活発なユーザー コミュニティもあります。このコミュニティでは、WinPCap や Wireshark といったネットワーク ユーティリティのポータブル版が開発されています (これら 2 つのユーティリティは、管理作業やトラブルシューティング作業で非常に役立ちます)。フォーラムでは、どのアプリケーションのポータブル版を開発するかについて提案する場も提供されます。
これらのアプリケーションは、使用する記憶装置以外に影響を与えない、自己完結型のアプリケーションです。レジストリに書き込んだり、他のディスクへのアクセスが必要になった場合は、終了時にすべてのデータが実行前の状態に回復されます。これらのアプリケーションは、それぞれ専用のインストーラにラップされた状態で提供されるので、PortableApps.com Platform を使用しなくても実行できます。ただし、この点を除いても、PortableApps.com Platform の機能は非常に魅力的であり、PortableApps.com Suite は、カスタマイズされた携帯可能な環境を初めて使用する場合に最適なパッケージです。
PortableApps.com Platform は自動再生されるように構成されているので、USB フラッシュ ドライブやポータブル ドライブを Windows ホスト コンピュータに挿入すると、このプラットフォーム アプリケーションを実行するためのオプションが表示されます。プラットフォームを起動すると、システム トレイ アイコンが表示されます。このアイコンをクリックすると、Windows の [スタート] メニューに似たメニューが表示されます。このアプリケーション ランチャーでは、すべてのポータブル アプリケーションへのリンク、ポータブル デバイス上のドキュメント フォルダへのリンク、ドライブの空き容量の表示、ドライブ上のドキュメントのバックアップ ユーティリティ、検索ツール、および新しいポータブル アプリケーションをインストールするためのリンクが提供されます。インターフェイスをカスタマイズしたり、30 を超える言語からインターフェイス言語を選択したりすることもできます。
プラットフォームをしばらく操作すると、アプリケーションを変更してポータブル版を開発する方法に興味を持つかもしれません。PortableApps.com には Portable App Development (ポータブル アプリケーション開発) フォーラムがあるので、そこでさらに詳しい情報を得ることができます。総合的に考えて、これはポータブル パッケージに含まれた非常に優れたツール セットであると言えます。

価格 : 無償
PortableApps によって実現されるツールの携帯

リモート システムのトラブルシューティングを行う
TeamViewer
teamviewer.com
アプリケーションに関する問題のトラブルシューティングや、製品のデモとチュートリアルを提供する場合、または単にユーザーの質問を理解しようとする場合、問題のコンピュータが目の前にあるのが一番です。ただし、多くの場合、それは不可能です。次善の策は、実際に現場にいなくても "現場にいられる" ツールを使用することです。TeamViewer GmbH の TeamViewer には、まさにこのような機能が備わっています。
このユーティリティのインストール プロセスは単純なので、すぐにリモート コンピュータに接続できます。TeamViewer でサポートされる基本的な操作モードは 4 つあります。Remote Support (リモート サポート) モードでは、リモート コンピュータを制御して、トラブルシューティング、操作や保守の支援、およびユーザーへの作業の説明を行うことができます。Presentation (プレゼンテーション) モードを使用すると、自分のデスクトップをリモート ユーザーのシステム上で表示し、作業のデモやプレゼンテーションを行うことができます。File Transfer (ファイル転送) というモードもあります。このモードでは、実際にデスクトップを共有することなく、2 台のコンピュータ間でファイルを転送できます。最後の VPN モードを使用すると、自分とホスト コンピュータとの間で一時的な仮想プライベート ネットワークを作成できます (このモードでは、TeamViewer VPN アダプタに関するインストール オプションが使用されます)。
セキュリティの面では、RSA によるキー交換、および 256 ビット AES によるセッション エンコードが使用されます。キー交換を使用することで、"介入者" (TeamViewer のルーティング サーバーなど) によるデータ ストリームの傍受を回避できます。さらに、サポート コンピュータのセッションに接続すると (サポート コンピュータとは、セッションをホストするコンピュータです)、セッション ID とパスワードが生成され、リモート ユーザーはこれらを入力しなければ接続できません。操作するユーザーがいないコンピュータに接続する場合 (サーバーを管理する場合など) でも、TeamViewer にはシステム サービスとしてインストールするオプションが用意されているので、簡単にファイルの転送、リモート制御機能の使用、VPN の作成、さらにはリモート コンピュータの再起動を行うことができます。
このアプリケーションを使用してサポートやプレゼンテーションを行う場合に特に役立つもう 1 つの優れた機能は、TeamViewer QuickSupport モジュール (Customer モジュール) です。これは比較的小さい実行可能ファイルで、リモート コンピュータにソフトウェアをインストールしたり、インストール権限を与えたりする必要なく実行できます。エンド ユーザーが実行可能ファイルをダブルクリックし、セッション ID とパスワードを入力するだけで、簡単にセッションをそのユーザーのコンピュータに接続できます。
TeamViewer では、非常に便利な構成オプションがいくつか提供されます。画面上で共有する色の数を最適化したり、リモート コンピュータの壁紙を非表示にしたり、Windows Vista Aero グラスの有効化を維持したりできます。また、セッションの全体的な品質と速度の設定を調整できます。加えて、リモート制御、ファイル転送、VPN 接続、リモートでのキーボードとマウスによる入力、ローカル ホストとリモート ホストとの間の制御の切り替え、リモート画面の表示など、さまざまな機能を有効にするかどうかを制御できます。
さらに、セッションを記録して、後からそれらを再生または監査できます。セキュリティ構成などの理由から、TeamViewer のサーバーを経由せずにルーティングを行う場合は、LAN 接続のみを使用してルーティングを行うように TeamViewer を構成することもできます。
Premium エディション (サポート コンピュータへのインストール回数が制限されません) には、CD や USB フラッシュ ドライブにインストールしてツールを持ち運ぶことができる Portable エディションが付属しています。また、Premium エディションには TeamViewer Manager も付属しています。TeamViewer Manager は、セッションの詳細をログに記録したり、接続先コンピュータの詳細を保存したりできるので、顧客の管理、および顧客への報告や請求に役立ちます。TeamViewer は Mac OS X でも使用でき、複数のプラットフォームにまたがったアクセスがサポートされるので、Mac に接続しながら Windows コンピュータを使用できます。

価格 : 商用でない場合は無償、Business エディションはサポート コンピュータへのインストール 1 回につき 699 ドルから、Premium エディションは 1,399 ドル (サポート コンピュータへのインストール回数は無制限です)
TeamViewer を使用したリモート システムへの接続

ブック レビュー
End-to-End Network Security: Defense-in-Depth
今日のネットワーク セキュリティでは、事前対応型のテクノロジを複数の層に組み込むことで、障害が発生するリスクを削減し、ネットワーク インフラストラクチャの内外から攻撃を受ける可能性を制限しています。Omar Santos が執筆した『End-to-End Network Security: Defense-in-Depth』(Cisco Press、2007 年) は、複雑化の一途をたどるネットワーク保護について理解するのに役立ちます。
この書籍では、明らかに Cisco 社の製品を好んで取り上げていますが、一般的なセキュリティ情報も紹介されており、インフラストラクチャのセキュリティに関心があるすべてのネットワーク管理者やシステム管理者向けの優れた参考資料であると言えます。
この書籍ではまず、ファイアウォールや VPN から、侵入検出/防止システム (IDS/IPS) や ID 管理まで、ネットワーク セキュリティに関するテクノロジの概要を説明します。続いて、セキュリティ障害に対処するために使用する 6 段階の方法について詳しく説明します。これらの段階は、準備、(セキュリティの脅威の) 特定、(セキュリティの脅威の) 分類、原因究明、対処、および事後分析です。
次に、この書籍では、IDS/IPS、NAC、AAA、SNMP、Syslog、VLAN など、さまざまなデバイスやツールを使用した、事前対応型のセキュリティ フレームワークについて説明します。続いて Cisco の多層防御型手法に話題を移し、ワイヤレス ネットワーク、IP テレフォニー、データ センターのセキュリティ、および IPv6 セキュリティについて説明します。これは、主に Cisco のソリューションがネットワーク セキュリティのこのような分野に関連しているためです。最後に、この書籍では 3 つのケース スタディを紹介し、実際の小規模、中規模、および大規模企業向けのセキュリティ ソリューションについて説明します。

価格 : 49.50 ドル (直販)

デバイス ID を調査する
PCIDatabase.com
PCIDatabase.com
システムを更新しようとしたときに、"PCI デバイス" としか説明されていない不明なデバイスが 1 つか 2 つ見つかり、コンピュータのカバーを外して懐中電灯であちこち照らさなければ、ドライバの入手方法もデバイスの種類もわからなかったことはありませんか。また、既知のデバイスの基盤となっているチップセットがどのようなものであるかを確認しようとしたことはありませんか。このような作業に役立つ無償サービスの 1 つが、PCIDatabase.com です。
ユーザーによってサポートされるこのデータベースを使用すると、製造元、デバイス名、およびデバイス ID で検索を実行し、詳細情報を調べることができます。製造元やデバイス ID を確認するには、デバイス マネージャを開き、目的のデバイスを右クリックして [プロパティ] をクリックし、[詳細] タブ、ドロップダウン リストの一覧の [ハードウェア ID] の順にクリックするだけです。"VEN_" (製造元)、および "DEV_" (デバイス) という文字列の後に、いくつかの 16 進数値が続く一連の文字列が表示されます。
この Web サイトでは、便利なリソースへのリンクが多数紹介されており、検索したデバイスで利用できるドライバがあるかどうかを確認できます (もちろん、製造元の Web サイトを確認することもお忘れなく)。
PCIDatabase.com には、もう 1 つ優れた機能があります。特定の製造元を参照すると、本社の所在地、電話番号、該当する Web サイト、問い合わせ先、PCI デバイスの製造元を示す 16 進数の ID、およびサイトで認識しているその製造元のすべてのデバイスの一覧が表示されます。この Web サイトはユーザーによって支えられており、皆さんからの情報提供を求めています。

価格 : 無償
図 4 製造元とデバイスの情報を入手できる PCIDatabase.com (画像をクリックすると拡大表示されます)

資産を監査し、インベントリを作成する
CCS Network Inventory
crowcanyon.com
自分の席を離れずに、クライアント コンピュータにインストールされているプログラムを確認できれば、時間を大幅に節約できます。そして現実的に考えて、このような資産を随時追跡することは、皆さんの仕事の一部です。Crow Canyon Systems の CCS Network Inventory ソリューションは、このような作業に役立ちます。
このアプリケーションは、エージェントを使用しないインベントリ作成および監査ツールであり、LAN をスキャンしてワークステーションを検出し、ハードウェア、ソフトウェア、サービス、およびユーザーに関する情報を収集します。CCS Network Inventory ではリモート エージェントを使用しないので、実行コンテキストには、RPC、コンピュータ ブラウザ サービス、リモート レジストリ サービス、ファイルとプリンタの共有、およびインベントリに含めるコンピュータ上の ADMIN$ 共有へのアクセスが必要です (これは、エージェントを使用しない他の大部分のインベントリ製品と同様です)。
CCS Network Inventory では、クエリに別の資格情報を使用できるので、複数のドメインにまたがってスキャンを実行する場合に役立ちます。このアプリケーションをインストールすると、IP アドレスの範囲をスキャンする、Windows ネットワークを検出する、コンピュータの一覧をインポートする、インベントリに含める Windows ワークステーションの一覧を手動で指定するといった操作を行うことができます。
CCS Network Inventory によって何が監査されるかという観点から説明すると、このアプリケーションではソフトウェアの詳細情報が収集されます。たとえば、インストールされているアプリケーション、適用されている修正プログラム、インストールされている OS とサービス パック、およびインストールされているフォントの情報が収集されます。コンピュータの構成については、実行されているサービスやその他のプロセス、共有されているフォルダ、ドライブの割り当て、環境変数、ユーザー アカウント、スケジュールされたタスク、スタートアップ コマンド、および実行されているネットワーク プロトコルを確認できます。ハードウェアについては、接続されているモニタ、プリンタ、ハード ディスク (およびそのサイズとパーティション)、CD ドライブと DVD ドライブの情報、プロセッサ、メモリなどの詳細情報を確認できます。また、カスタム スキャンを構成して、レジストリ値、ファイル数 (mp3 を最も多く所有しているユーザーを確認する場合など)、およびドライブの空き容量を確認できます。
これらの情報はすべてアプリケーション独自のデータベースに保存され、このデータを使用してレポートを作成できます。CCS Network Inventory には、組み込みのレポートが多数用意されており、監査や報告用にデータを視覚化して転送できます。必要なデータが組み込みのレポートやクエリの情報に含まれていない場合は、組み込みの SQL Query Builder ツールを使用することにより、さらに詳細なクエリを実行してデータを取得できます。
変化を確認できるよう、定期的に環境のスナップショットを作成することをお勧めします。CCS Network Inventory では、2 つの情報データベース インスタンスを比較することで、このような変化を確認できます。たとえば、現在のスキャンを 1 年前に実行されたスキャンと比較して、Windows Vista に移行したワークステーションの数、過去 1 年間で更新されたハードウェア コンポーネントの数、または警告を受けた後もサポートされていないソフトウェアを実行し続けているユーザーの数を確認できます。
この記事の執筆時点では、CCS Network Inventory で Windows Server 2008 は完全にはサポートされていませんが、他のバージョンの Windows (Windows Vista まで) はサポートされています。

価格 : 25 ノードまで 235 ドルから
CCS Network Inventory を使用したリモート資産の管理

ツールボックスにご意見、ご要望をお送りください ここで取り上げてほしいお勧めのツールやユーティリティがございましたら筆者 tntools@microsoft.com まで英語でご連絡ください。

Greg Steen は技術プロフェッショナルであり、企業家でもあります。また、新製品のファンとも言えます。より簡単な操作、品質保証、および開発に役立つ IT プロフェッショナルのための新しいツールを日夜追い求めています。


SQL に関する Q&A サイズの大きいトランザクション ログ、修復を使用するタイミングなど
Paul S. Randal

質問 バックアップ中に奇妙な動作が発生するのですが、この動作について教えてください。62 GB の運用データベースを頻繁にバックアップして、アプリケーション開発者が使用するデータを更新しています。その際には、古いバックアップを削除してから、新しいバックアップを復元しています。復元したバックアップのサイズは運用データベースのサイズと同じなのでデータは同じだと思うのですが、復元処理にはバックアップ処理の数倍の時間がかかります。何が起こっているのでしょうか。バックアップより復元にかかる時間の方がかなり長くなる理由を教えてください。
回答 奇妙なことが起こっているわけではありません。状況にもよりますが、これは一般に予測される動作です。バックアップと復元にかかる時間に違いが生じるのは、それぞれの処理で実行する必要がある手順に違いがあるからです。
データベースのバックアップでは、2 つの手順を実行します。基本的には、次のように、データベースの入出力データを読み取って、バックアップ デバイスに書き込んでいるだけです。
バックアップ手順 1. データ ファイルに保存されている全データを読み取って、バックアップ デバイスに書き込みます。
バックアップ手順 2. トランザクション ログを読み取って、バックアップ デバイスに書き込みます。
必要とされるトランザクション ログの量は状況によって大きく異なりますが、実際に必要となるのは復元したデータベースを特定の時点の運用データベースと一貫性のある状態に回復するのに必要とされる量です (詳細については、sqlskills.com/blogs/paul/2008/01/31/MoreOnHowMuchTransactionLogAFullBackupIncludes.aspx のブログ記事を参照してください)。
一方、データベースの復元では、最大 4 つの手順が実行されます。これらの手順で行う処理は、単なる入出力の読み取り/書き込みよりも複雑です。
復元手順 1. データベース ファイルがない場合は、作成します。
復元手順 2. バックアップからすべてのデータとトランザクション ログを読み取って、該当データベース ファイルに書き込みます。
復元手順 3. トランザクション ログに記載されている復旧の再実行フェーズを実行します。
復元手順 4. トランザクション ログに記載されている復旧の元に戻すフェーズを実行します。
バックアップの 2 つの手順にかかる時間は、復元手順 2. にかかる時間とだいたい同じです (ただし、ハードウェアが類似していて、サーバーでユーザーによる操作が行われていないことが条件となります)。データ ファイルのサイズが大きく、ゼロで初期化する必要がある場合は、復元の手順 1. に時間がかかることがあります (これは、SQL Server 2000 で発生する動作で、SQL Server 2005 では既定の動作となっています)。
手順 1. の処理に時間がかかるのを回避するため、復元を開始する前に既存のファイルを削除しないでください。または、瞬時初期化を有効にして、ファイルが高速に作成されるようにします (詳細については、msdn.microsoft.com/library/ms175935.aspx を参照してください)。
復元の手順 3. と手順 4. では、復元したデータベースで復旧処理を実行して、トランザクションの整合性を確保しています。これは、データベースのクラッシュ復旧で行われるのと同じ処理です。復旧にかかる時間は、処理する必要があるトランザクション ログの量に左右されます。たとえば、バックアップを作成しているときに、実行時間が非常に長いトランザクションがアクティブになっていた場合は、そのトランザクションの全トランザクション ログがバックアップに含まれ、そのトランザクションで行われた一連の操作のロール バックが必要になります。

質問 運用データベースの冗長なコピーを用意するために、ログ配布かデータベース ミラーリングのどちらかを使用することを検討しています。懸念事項は、サーバー間で送信する必要があるトランザクション ログの量で、特に、毎晩行っているインデックスの再構築操作のトランザクション ログの量が心配です。ミラーリングでは、トランザクション ログではなく実際の再構築コマンドが送信され、ミラー サーバーで再構築が行われると聞きましたが、これは本当ですか。それが本当なら、一括ログ復旧モデルを使用するログ配布よりも、ミラーリングの方が優れた解決策になりますよね。
回答 あなたが聞いたことは事実ではありません。データベース ミラーリングでは、プリンシパル データベースのトランザクション ログ レコードがミラー サーバーに送信され、ログ レコードがミラー データベースで再生されます。変換やフィルタ処理などが行われることはなく、ミラー データベースで T-SQL コマンドが妨害されることもありません。
データベース ミラーリングでは、完全復旧モデルしかサポートされていないので、インデックスの再構築操作では常に完全なログ記録が行われます。また、関連するインデックスのサイズによっては、大量のトランザクション ログが生成されることがあります。その結果、プリンシパル データベース上のログ ファイルのサイズが大きくなり、ログ レコードをミラー サーバーに送信するのに必要なネットワーク帯域幅が増加します。
データベース ミラーリングはリアルタイムのログ配布と考えることができます (実際に、この名前は SQL Server 2005 の開発初期段階で、この機能名として使用されていました)。一方、ログ配布では、プライマリ データベースのトランザクション ログのバックアップがセカンダリ サーバーに定期的に配布され、セカンダリ データベースで復元されます。
ログ配布では、完全復旧モデルと一括ログ復旧モデルがサポートされています。ログの配布先データベースでインデックスの再構築操作に完全復旧モデルが使用される場合は、ミラー データベースで生成されるのと同じ量のトランザクション ログが生成されます。ただし、ログ配布を使用したデータベースのシナリオでは、データが継続的に送信されるのではなく、ログ バックアップ (または一連のログ バックアップ) が冗長なデータベースに送信されます。
インデックスの再構築中に、ログの配布先データベースで一括ログ復旧モデルが使用される場合は、最低限の量のトランザクション ログだけが生成されます。ただし、最低限のログが生成されたインデックスの再構築操作で変更した、すべてのデータ ファイルのエクステントは、次回のトランザクション ログのバックアップにも含まれます。つまり、一括ログ復旧モデルを使用した場合のインデックスの再構築をカバーするログ バックアップのサイズは、完全復旧モデルを使用した場合のインデックスの再構築をカバーするログ バックアップのサイズとほぼ同じになります。
冗長なデータベースに送信する必要がある情報の量は、ミラー データベースでのインデックスの再構築とログの配布先データベースでのインデックスの再構築のどちらもほぼ同じです。この 2 つの間で異なるのは、情報が送信される方法 (継続的に送信するか、一括で送信するか) だけです。
この 2 つの手法のどちらかを選択する場合には、他にも考慮する必要がある要因がたくさんあります (要因が多すぎるため、1 回の SQL に関する Q&A コラムでは説明できませんが)。どちらの手法を使用するかを決める前に、これらのあらゆる要因がどの程度ご自分の要件を満たしているか (許容できるデータ損失の限度やダウンタイムなど) を確認する必要があります。

質問 SQL Server 2005 を実行していますが、データベースの 1 つのトランザクション ログのサイズが増加し続けています。このデータベースは完全復旧モードで、トランザクション ログのバックアップを行っています。この方法を使用すれば、トランザクション ログのサイズが増加しなくなると思っていたのですが、どんな問題が起こっているのでしょうか。
回答 ご指摘のとおり、完全復旧モードでトランザクション ログのバックアップを作成することは重要です。ただし、トランザクション ログのサイズを増加させる要因は他にもあります。最終的には、何がトランザクション ログを必要としているのか (具体的には、トランザクション ログをアクティブにすることを必要としているのか) によって決まります。トランザクション ログのバックアップがないこと以外で、この問題を発生させる他の一般的な要因としては、レプリケーション、データベース ミラーリング、およびアクティブなトランザクションがあります。
レプリケーションでは、トランザクション ログ レコードを非同期に読み取って、トランザクションを読み込み、別のディストリビューション データベースにレプリケートします。レプリケーション ログ リーダーのタスクで読み取られていないトランザクション ログ レコードは解放することができません。ワークロードで大量のトランザクション ログ レコードが生成される場合に、レプリケーション ログ リーダーを実行する頻度の間隔を長く設定していると、多くのレコードが蓄積され、トランザクション ログのサイズが増加することがあります。
非同期のデータベース ミラーリングを実行している場合は、プリンシパル サーバーからミラー サーバーに送信されていない、トランザクション ログ レコードのバックログが作成されることがあります (データベース ミラーリングの送信キューと呼ばれます)。トランザクション ログ レコードは、正常に送信されるまで解放することができません。トランザクション ログ レコードの生成率が高く、ネットワークの帯域幅が制限されている場合 (または、その他のハードウェアの問題がある場合) は、バックログのサイズが非常に大きくなり、トランザクション ログのサイズが増加することがあります。
最後に、ユーザーが (BEGIN TRAN ステートメントを使用するなどして) 明示的なトランザクションを開始して、(DDL ステートメントや挿入操作、更新操作、削除操作などにより) なんらかの変更を行う場合は、ユーザーがトランザクションをコミットまたはロールバックするまで、生成されたトランザクション ログ レコードを保持しておく必要があります。つまり、トランザクション ログを指定して解放することができないため、その後、他のトランザクションで生成されたトランザクション ログ レコードも解放することができないということになります。たとえば、ユーザーがトランザクションを完了せずに帰宅した場合は、生成されるトランザクション ログ レコードが増加しますが解放できないので、トランザクション ログのサイズが増加し続けます。
トランザクション ログを解放できない理由は、次のように sys.databases システム カタログ ビューに対してクエリを実行して、log_reuse_wait_desc 列を調べることで確認できます。
SELECT name AS [Database],
  log_reuse_wait_desc AS [Reason]
FROM master.sys.databases;
原因がアクティブなトランザクションにあることが判明した場合は、DBCC OPENTRAN ステートメントを使用して、そのトランザクションに関する詳細な情報を取得できます。
DBCC OPENTRAN ('dbname')

質問 REPAIR_ALLOW_DATA_LOSS はデータの破損から回復する最終手段として使用し、通常は、バックアップからデータを復元する必要があると聞きました。SQL Server 2005 の修復オプションを使用すべきではない理由と、そのように危険な機能が製品に組み込まれている理由を教えてください。
回答 最初にお知らせしておきますが、実は私が SQL Server 2005 の修復機能を記述しました。REPAIR_ALLOW_DATA_LOSS (これ以降は単純に「修復」と呼びます) の問題点は、そのしくみが明らかになっていないことです。「修復オプション」という名前は、これを実行することによってデータベースのデータが失われる可能性があることを示唆するために採用されました。通常、この機能では、破損した構造を削除し、データベース内で削除した構造を参照していたもの、または削除した構造で参照されていたものをすべて修復することによって、破損したデータベース構造を修復します。修復は、データベースの構造を一貫性のある状態に戻す最終手段として用意されたもので、ユーザー データを保存することを目的とした機能ではありません。ユーザー データを削除するためにわざわざ使用する機能でも、ユーザー データを保存するために無理に使用する機能でもありません。
これは、修復方法としては頼りないと思うかもしれませんが、修復オプションを使用しなければならないような状況では、破損を修復する最も迅速で信頼できる手段となります。障害復旧時に最も重要になるのは速さですが、もちろん正確さも要求されます。あらゆる状況で迅速かつ正確に機能することが保証される、これより複雑な修復アルゴリズムを設計することはほぼ不可能です。たとえば、修復のコードでは、2 つのインデックスに同じページまたはエクステントが割り当てられた場合の問題を解決するための複雑なアルゴリズムが採用されていますが、アルゴリズムの処理内容のほとんどは修復と修正です。
ですが、修復については、注意しなければならない問題がいくつかあります。
  • 修復では、破損した構造を削除するときに外部キー制約が考慮されません。そのため、別のテーブルとの外部キーのリレーションシップがあるテーブルからレコードが削除される場合があります。このような状況が発生したかどうかを判断するには、修復を実行した後で DBCC CHECKCONSTRAINTS を実行する以外に方法はありません。
  • 修復では、アプリケーション レベルで定義された固有のビジネス ロジックやデータのリレーションシップが考慮されない (できない) ため、削除されたデータによって、このようなロジックやリレーションシップが破損する場合があります。これについても、破損しているかどうかを判断するには、アプリケーションに組み込まれているカスタムの整合性チェックを実行する以外に方法はありません。
  • 一部の修復操作はレプリケートできません。ピア ツー ピア トポロジのパブリッシャまたはノードで修復を実行すると、トポロジ内で不整合が発生する場合があります。この不整合は手動で修正する必要があります。
このような理由から、破損を修復する場合は、修復オプションではなく、バックアップを使用することをお勧めします。しかし、データベースが破損した場合にバックアップがなく、しかしデータベースを迅速にオンラインに復旧する方法が必要である、という状況が生じる可能性は常にあるため、SQL Server 2005 では修復オプションを用意しました。

質問 最近、転職した先の会社でデータベース管理者として働いていて、いくつかのアプリケーションとそのバックエンド データベースを担当しています。その中の 1 つのアプリケーションに、更新時のパフォーマンスが非常に低いものがあります。調査した結果、そのアプリケーションで使用しているテーブルに、膨大な数のインデックスが作成されていることが判明しました。周囲の人に聞き込み調査を行ったところ、前任のデータベース管理者には、各テーブル列にインデックスを追加し、さらに、そのいくつかを組み合わせる癖があったようです。これらのインデックスがすべて必要だとは思えません。削除しても問題がないインデックスを見分ける方法はありますか。実行しているのは SQL Server 2005 です。
回答 ご指摘のとおり、多数のインデックスがパフォーマンス低下の主な原因になっていることは間違いありません。というのも、テーブルで行が挿入、更新、または削除されるたびに、すべての非クラスタ化インデックスで対応する操作が行われる必要があるからです。その結果、入出力、CPU 使用率、およびトランザクション ログの量に関して、かなりのオーバーヘッドが生じます。
SQL Server 2000 では、プロファイルを使用してクエリ プランを確認することが、使用されているインデックスを特定する唯一の方法でした。SQL Server 2005 では、インデックスの使用状況を追跡する sys.dm_db_index_usage_stats という新しい動的管理ビュー (DMV) が提供されています。
DMV では、インデックスが作成されているデータベースが起動してから、インデックスが使用されるたびに、インデックスが作成されたことと、それがどのように使用されたのかを追跡します。SQL Server を終了すると、すべてのデータベースの統計が失われ、データベースを閉じるかデタッチすると、そのデータベースの統計が失われます。考え方としては、統計出力に含まれていないインデックスは、データベースが起動している間に使用されなかったということになります。
長期にわたってインデックスの使用状況を追跡する簡単な手法は、DMV の出力の定期的なスナップショットを作成し、そのスナップショットを比較することです。忘れられがちなことですが、ビジネス サイクル全体でインデックスの使用状況を追跡する必要があります。ある特定の日にスナップショットを作成した場合、使用されていないインデックスがいくつかあるかもしれません。ですが、たとえば、月末のレポート処理を桁違いに速く実行するために、それらのインデックスが使用されている場合、それらのインデックスは削除すべきではないでしょう。ビジネス サイクルを通じて使用されていないインデックスは、空きディスク領域を増やし、パフォーマンスを向上するために、削除して差し支えないでしょう。
私のブログ記事では、DMV の定期的なスナップショットを作成する際に使用できるいくつかの単純なコードを紹介しています。詳細については、sqlskills.com/blogs/paul/2007/10/05/IndexesFromEveryAngleHowCanYouTellIfAnIndexIsBeingUsed.aspx を参照してください。

Paul S. Randal は SQLskills.com の代表取締役であり、SQL Server MVP でもあります。また、『DBCC CHECKDB/repair for SQL Server 2005』を執筆し、SQL Server 2008 の開発時にはコア ストレージ エンジンを担当していました。Paul は障害回復、高可用性、およびデータベース メンテナンスの専門家であり、カンファレンスで定期的に発表を行っています。彼のブログは SQLskills.com/blogs/paul で公開されています。


ユーティリティ スポットライト Offline Virtual Machine Servicing Tool
Peter Skjøtt Larsen、Suveen Kumar Reddy Vuppala

目次
セキュリティに関する悪夢
内部的な処理
サービス インフラストラクチャ
ツールを使用する
今後について
コンピュータのワークロードを仮想化するということは、仮想マシン (VM) を使用して、基盤となるハードウェアからワークロードを分離することです。現代の IT 部門では、次のような多くの状況で VM が役に立つと考えられています。
ワークロードの切り替え : VM を使用すると、使用上のニーズが変化した場合に、それに応じてハードウェアを変更することなく、複数の構成のワークロード処理能力を簡単に増減できます。
アプリケーションの開発とテスト : 各構成専用のハードウェアを用意することなく、アプリケーションがサポートする必要がある各構成を代表する複数の VM を作成できます。
ソフトウェアのアップグレード : VM を使用すると、1 つのハードウェア上で、以前のバージョンのソフトウェア パッケージをオフラインにしているときに新しいバージョンをオンラインにすることができます。
ソフトウェアの配布 : テスト済みパッケージに一貫性のあるソフトウェアが連携している基幹業務アプリケーションの配布単位として、VM を使用できます。

セキュリティに関する悪夢
VM を使用するメリットの 1 つは、VM イメージとしてオフライン状態で保存できることです。そして、必要なときに、このような VM をオンラインにして、これに相当する物理コンピュータを展開するよりもはるかにすばやく展開することができます。
しかし、増加し続けるコンピューティング環境をオフライン状態で保持していると、メンテナンス上の課題が発生します。多くのソフトウェア更新メカニズムでは、更新プログラムを確認したり自動的に更新プログラムを受信したりするには、システムがオンラインである必要があります。
オンラインでないときの VM は、コンピュータに格納されている単なるファイルでしかないので、更新メカニズムが作用することはありません。したがって、数か月間オフラインになっていた VM がオンライン状態になると、ネットワークにとって脅威となる場合があります。また、このような VM にとってネットワークが脅威となる場合もあります。
問題は、OS の更新プログラムが適用されていないということだけではありません。古くなったアプリケーションやウイルス プロファイルによって、VM が脆弱になったり各企業のセキュリティ基準を満たさなくなったりする場合があります。
ユーザーがオフラインの VM を最新の状態に保てるようにするため、マイクロソフト ソリューション アクセラレータ チームは Offline Virtual Machine Servicing Tool を作成しました。このツールは、System Center Configuration Manager (SCCM) 2007、Windows Server Update Services (WSUS) 3.0、および System Center Virtual Machine Manager (VMM) 2007 と連携して、保存されている VM の更新プロセスを適切に行います。図 1 は、このツールの概念図と、このツールとさまざまな外部コンポーネントとの関係を示しています。
図 1 Offline Virtual Machine Servicing Tool のしくみ (画像をクリックすると拡大表示されます)
VM に更新プログラムを適用できるようにするため、このツールでは VMM を使用して一時的に VM をメンテナンス ホストに展開します。通常、メンテナンス ホストには、複数の VM を同時に実行するのに必要な CPU やメモリが搭載されているので、このツールでは複数の VM をまとめて処理することができます。
メンテナンス ホスト上で VM がアクティブになったら、SCCM または WSUS によって必要な更新プログラムを VM に適用することができます。更新プログラムが適用されると、このツールでは VMM を使用して VM をオフライン状態に戻します (このツールでサポートされているのは、VMM によって管理されている VM のみであることに注意してください)。

内部的な処理
Offline Virtual Machine Servicing Tool では、VM の更新プロセスを適切に処理するために Windows Workflow Foundation (WF) を使用しています。このプロセスでは、適切な更新管理システムの選択から始まって、該当 VM に適した次に使用可能なメンテナンス ホストの選択、更新プログラムが適用されたことの確認、例外の処理に至るまで、多くの判断を行う必要があります。
Windows WF ベースのソリューションを使用することにより、開発チームは非常に柔軟にプロセスを変更したり進化させたりすることができました。また、ニーズに合わせて調整できる堅牢なソリューションがユーザーに提供されます。プロセスの重大な局面で、更新前および更新後の組み込みのワークフロー手順を使用してカスタマイズを行うことができます。
このツールは、Windows PowerShell を使用してワークフローより下のレベルで個々のタスクを実装し、VMM によって提供される Windows PowerShell API とうまく対応します。また、Microsoft .NET Framework ベースの UI は外観や使い勝手が System Center 製品と似ているので、初めての方でも問題なくお使いいただけます。

サービス インフラストラクチャ
サービス インフラストラクチャの基本原則の 1 つは、更新プロセス中に VM が保護されるようにネットワーク セキュリティを構成することです。このツールのバージョン 1.0 では、VMM や更新システム (WSUS または SCCM) が接続している仮想プライベート ネットワーク (VPN) を使用して VM を保護していました。VMM ライブラリに最適なインフラストラクチャは、ファイバ チャネル接続の記憶域ネットワーク (SAN) です。これを使用すると、VM イメージをメンテナンス ホストに高速転送することができます。
すべての VM が、Active Directory と DNS を使用する、同じドメインのメンバである必要があります。VMM、WSUS、SCCM、VMM ライブラリのそれぞれに別々のサーバーを使用することもできますが、小規模な環境では複数の仮想サーバーを組み合わせて使用することもできます。言うまでもないことですが、メンテナンス ホストは物理サーバーである必要があります。

ツールを使用する
サービス インフラストラクチャをセットアップしたら、ツールを起動する前に、いくつかの設定が適切に構成されていることを確認する必要があります。処理対象の VM がすべて VMM で管理されていること、各 VM に適切な更新クライアントがインストールされていること、WSUS または SCCM で、必要な更新プログラム パッケージが構成されていることを確認します。VMM でメンテナンス ホストのグループが構成されていることを確認するのは、必須ではありません。
設定を確認したら、Offline Virtual Machine Servicing Tool を起動します。このツールでも、いくつかの構成手順を実行する必要があります。VMM サーバーと、適切な WSUS サーバーまたは SCCM サーバーを指定し、使用するメンテナンス ホストのグループ (メンテナンス ホストのグループを構成している場合) とそのグループのどのメンテナンス ホストを使用するかを指定する必要があります (図 2 参照)。管理する VM のグループを構成することもできますが、これは必須ではありません。
図 2 Offline Virtual Machine Servicing Tool を構成する (画像をクリックすると拡大表示されます)
ツールを構成したら、サービス ジョブを作成します。サービス ジョブには、特定の VM を管理するのにツールで必要となる情報がすべて含まれています。この情報には、WSUS と SCCM のどちらを更新プロセスに使用するか、VMM サーバーの場所と WSUS サーバーまたは SCCM サーバーの場所、管理する VM の ID、更新プロセスに使用するネットワークの種類 (および必要に応じて ID)、使用するメンテナンス ホストの ID などがあります。また、VM、VMM サーバー、および WSUS サーバーまたは SCCM サーバーへのアクセスに必要なアカウント資格情報、サービス ジョブの実行スケジュール (すぐに実行する、または特定の日時に実行する) などの情報もサービス ジョブに含まれています。
サービス ジョブを特定の日時に実行するよう指定すると、Windows タスク スケジューラによってジョブが実行されます。サービス ジョブの実行時に、Offline Virtual Machine Servicing Tool では、VM ごとに次の一連の手順を実行します。
  • VMM ライブラリから次の VM を選択します。
  • 最適なメンテナンス ホストを VMM に照会します。
  • VM をメンテナンス ホストに展開します。
  • VM が適切なネットワークに接続するようにします。
  • VM を起動します。
  • 適切な更新クライアントが VM にインストールされていることを確認します。
  • 更新プロセスを起動します。
  • 更新プロセスが完了するのを待ちます。
  • VM をシャットダウンします。
  • VM を VMM ライブラリに再び保存します。
VM のライブラリを更新するのにかかる時間は、メンテナンス ホストの数と処理能力、VMM ライブラリの記憶域のアクセス速度、および更新の種類によって大幅に異なります。

今後について
現在のバージョン (1.0) の Offline Virtual Machine Servicing Tool では、VM をネットワークから保護する非常に魅力的な方法であるネットワーク アクセス保護 (NAP) がサポートされていないことに注意してください。また、Windows Server 2008 の Hyper-V テクノロジはサポートされておらず、クライアント OS として Windows Server 2008 を使用することもサポートされていません。
新しいバージョンの SCCM、WSUS、および VMM が間もなく提供される予定です。また、Offline Virtual Machine Servicing Tool のバージョン 2.0 では、こうした新しいバージョンや Hyper-V がサポートされ、クライアント OS として Windows Server 2008 を使用することもサポートされる予定です。また、ネットワーク分離を実現するために NAP もサポートされる予定です。Offline Virtual Machine Servicing Tool は、technet.microsoft.com/cc501231 からダウンロードできます。

Peter SkjØtt Larsen は、マイクロソフトでシニア プロダクト マネージャを務めています。マイクロソフトに入社する前は、電気通信運用ソフトウェア システムの設計と開発、およびワイヤレス サービスの標準化と開発に携わっていました。
Suveen Kumar Reddy Vuppala は、マイクロソフトでシニア ソフトウェア開発エンジニアを務めています。以前はリアルタイム監視ツールの設計と開発に携わっており、過去 7 年間にわたってマイクロソフトの展開ソリューションの設計と開発に携わってきました。


Windows PowerShell プロファイルの力
Don Jones

目次
シェル、ホスト、およびプロファイル
プロファイルを使用する
カスタム コンソールを作成する
プロファイルに関するその他のテクニック
プロファイルに関する注意点
このコラムを定期的に読んでいらっしゃる皆さんは、Windows PowerShell でプロファイルのシステムがサポートされていることを既にご存知でしょう。基本的に、これらは .ps1 というファイル名拡張子が付いたシェル スクリプトで、シェルが実行されるときに自動的に実行されます。プロファイルでは、たとえばカスタム エイリアスを定義するためのすばらしい方法が提供されます。シェルを実行するたびにプロファイルによってエイリアスが自動的に定義され、シェルの使用中にいつでもエイリアスを使用できるように、プロファイルを構成できます。
Windows PowerShell では、次の 4 種類のプロファイルが定義されます。
  • すべてのシェルとコンピュータのすべてのユーザーに適用されるプロファイル。
  • すべてのユーザーと Microsoft PowerShell シェルに適用されるプロファイル。
  • 現在のユーザーとすべてのシェルに適用されるプロファイル。
  • 現在のユーザーと Microsoft PowerShell シェルに適用されるプロファイル。
"すべてのシェル" という概念は少し紛らわしいかもしれません。この用語は、Windows PowerShell の初期の開発コンセプトに基づいていますが、このコンセプトは実際に最終的な製品にはなりませんでした。今日では、おそらく "すべてのホスト" という表現の方が適切です。

ビデオ
このビデオでは、Don Jones がプロファイルを作成して Windows PowerShell シェルをカスタマイズする方法について説明しています。

シェル、ホスト、およびプロファイル
ご存知のように、Windows PowerShell 自体は Microsoft .NET Framework アセンブリの集合です。ここでは、シェルのこの部分を Windows PowerShell エンジンと呼びたいと思います。というのも、ここには皆さんが一般的に Windows PowerShell であると考えている機能が含まれているからです。ただし、ユーザーがこのエンジンと対話できる方法は組み込まれていません。ユーザーが実際にシェルを使用するには、ホスト アプリケーション (つまりホスト) によってエンジンが読み込まれる必要があります。
皆さんがこれまで実行してきた powershell.exe アプリケーションも、このようなホストの 1 つです。Windows PowerShell 2.0 Community Technology Preview (CTP) に含まれている gpowershell.exe アプリケーションは、また別のホストです。ホストとシェルの関係は、私がここで述べたほど単純なものではありませんが、皆さんがご覧になる動作は、私の簡単な説明で理解していただけると思います。
テキスト ベースのコマンド ライン インターフェイスを使用してシェルと対話する場合に、powershell.exe ホストを使用する可能性が高いことを理解しておくことは重要です。このことは、別のアプリケーション (Exchange 管理シェルなど) によってインストールされたショートカットを使用してシェルを起動した場合にも当てはまります。Exchange 管理シェルは、別のシェルやホスト アプリケーションではなく、一連のスナップインとスクリプトをあらかじめ読み込むように指定したショートカットによって起動される、標準的な powershell.exe ホストです。これらのスナップインにより、シェル内で Exchange の管理機能を使用できるようになります。ただし、使用するのは同じシェルです。
Windows Vista の場合、powershell.exe ホストのプロファイルは以下の場所にあります。
  • %windir%\system32\WindowsPowerShell\v1.0\profile.ps1 コンピュータのすべてのユーザーとすべてのシェルに適用されるプロファイル。
  • %windir%\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1 コンピュータのすべてのユーザーと Microsoft.PowerShell シェルに適用されるプロファイル。
  • %UserProfile%\Documents\WindowsPowerShell\profile.ps1 現在のユーザーとすべてのシェルに適用されるプロファイル。
  • %UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 現在のユーザーと Microsoft.PowerShell シェルに適用されるプロファイル。
これらのプロファイルは既定で作成されるわけではなく、明示的に作成した場合のみ、上記の場所に格納されます。
各ホスト アプリケーションは、適切なプロファイルを読み込んで実行します。特定のホスト アプリケーションによって、どのプロファイルも読み込まないことが "決定" された場合、実際にそのアプリケーションでプロファイルを読み込む必要はありません。プロファイルは Windows PowerShell エンジンによって自動的に実行されるわけではありません。
上記の動作を完全に把握する最も簡単な方法は、シェルを開いて「$profile」と入力し、Enter キーを押すことです。これで、シェルが使用しようとしている "主要な" プロファイル (ユーザーごとに用意される、シェル固有のプロファイル) の完全なパスがわかります。その後、そのスクリプトを作成または変更すれば、シェルが起動するたびにプロファイルが実行されるようになります。

プロファイルを使用する
プロファイルを使用する一般的な方法の 1 つは、既に述べたように、カスタム エイリアスを定義することです。また、カスタムの PSDrive を追加することもできます (これらは基本的に割り当て済みのドライブで、完全に Windows PowerShell 内に存在します)。あまり一般的でない使用方法は、環境内で使用しているソフトウェア製品に基づいて、必要な任意の管理タスクを実行できるスーパー シェルのようなものを作成することです。実際にスーパー シェルの概念について説明するには、まずその背景について少し説明する必要があります。
Windows PowerShell を作成しているマイクロソフト内の製品グループは、Microsoft 管理コンソール (MMC) を含む、その他の主要な管理テクノロジの多くを担当しています。MMC のしくみは、Windows PowerShell とよく似ています。mmc.exe を実行すると、最初にあまり役立たない空のコンソールが起動します。機能的なコンソールを作成するには、MMC スナップインを追加します。
要件に合わせてコンソールを構成したら、.msc 形式でコンソールをファイルに保存します。この保存したコンソール ファイルを使用して、カスタム コンソールをいつでも簡単に再読み込みできます。
多くの管理者は、カスタムの MMC コンソールを作成するのではなく、自分たちが管理する製品と共にインストールされるコンソールを使用します。たとえば、Exchange Server では、Exchange Server スナップインのみを含むコンソールが作成されます。Active Directory ユーザーとコンピュータは、あらかじめ作成されるもう 1 つのコンソールで、単一のスナップインが含まれています。
Windows PowerShell のしくみもほぼ同じです。Exchange Server 2007 の管理ツールと共にインストールされる Exchange 管理シェルのアイコンは、実際には powershell.exe へのショートカットで、コンソール ファイルを読み込む命令が含まれています。シェルのコンソール ファイルには .psc1 ファイル名拡張子が付いていて、あらかじめ読み込まれるスナップインの一覧が含まれています (MMC によってあらかじめ読み込まれるスナップインの一覧が .msc ファイルに含まれているのと非常によく似ています)。ただし、あらかじめ作成されるこのようなシェル コンソールの使用にこだわる必要はありません。MMC の場合と同じようにカスタム コンソールを作成し、そのカスタム コンソールを使用してすべての管理タスクを実行できます。プロファイルは、これを可能にするうえで重要な役割を果たします。

カスタム コンソールを作成する
カスタム コンソールを作成するには、まず使用する各スナップインの完全名を検索する必要があります。まず、必要なすべての管理ツールがコンピュータにインストールされていることを確認します。その後、Windows PowerShell で Get-PSSnapin –registered を実行します。これで、登録されているがまだ読み込まれていないすべての使用可能なスナップインが一覧表示されます。続いて、適切な Windows PowerShell プロファイルを作成または編集します。Add-PSSnapin コマンドを追加して、常に使用するスナップインをそれぞれ読み込みます。これには、Exchange Server、System Center 製品、サードパーティ製のスナップイン (たとえば PowerShell Community Extensions) などがあります。プロファイルを保存して (Windows PowerShell の実行ポリシーで要求されている場合は、プロファイルをデジタル署名します)、シェルを閉じます。もう一度シェルを開くと、プロファイルに列挙されたすべてのスナップインが自動的に読み込まれます。
もう 1 つの手法は、(Add-PSSnapin とスナップインの名前を使用して) すべてのスナップインをシェルに読み込むことです。その後、Export-Console を実行して、現在使用しているすべてのスナップインを含む .psc1 コンソール ファイルを作成します。この .psc1 コンソール ファイルを使用して、PSConsoleFile パラメータとカスタムの .psc1 ファイルが指定された、Windows PowerShell の新しいショートカットを作成できます。その後、ショートカットがコンソールを使用して、指定されたすべてのスナップインを自動的に読み込みます。

プロファイルに関するその他のテクニック
私は自分で作成した Windows PowerShell プロファイルを使用して、シェルが起動するたびに、他にもさまざまな役立つタスクを実行しています。次に、私のシステムでシェルが起動したときに実行されるいくつかの処理を示します。
  1. Get-Credential を実行してドメインの管理者アカウントの資格情報を取得し、$cred という変数に結果を格納します。これにより、シェル全体で $cred を使用できるようになります。次に、$cred をさまざまなコマンドレット (Get-WMIObject コマンドレットなど) の credential パラメータに渡します。$cred にはパスワードが格納されるので、パスワードの入力を求められることなく、これらのコマンドレットを使用できます。
  2. Cd C:\ を実行して、シェルがコンピュータの C: ドライブのルートで開始されるようにします。
  3. New-Alias of Out-File を実行して、"of" という名前のエイリアスを作成します。これは、"Out-File" の代わりに "of" を使用できるようにするためです。短いエイリアスが定義されていると非常に便利なので、私はこの手法をよく使用します。
シェルの HKLM: ドライブにテスト キーを作成します。HKLM はレジストリの HKEY_LOCAL_MACHINE の部分を表しています。エラーが発生した場合は、昇格した権限を使用せずにシェルが起動されます。通常、私が行う作業では、昇格した権限が必要です。エラーが発生するかどうかによって、重要な作業に取りかかる前に、昇格した権限を持っているかどうかを簡単に確認できます。
Ping-Address という名前のカスタム関数を定義します。この関数は、コンピュータ名または IP アドレスを受け取り、そのコンピュータが ping に応答するかどうかに基づいて True または False を返します。私が行う作業ではこの関数をよく使用するので、プロファイル内でこの関数を定義してシェル全体で使用できるようにしています。

今月のコマンドレット : Get-WmiObject
洞察力のある方は、私が以前に取り上げたものと同じコマンドレットを紹介していることに気付いたかもしれませんが、今回は、このコマンドレットで提供されるすばらしい仕掛けについて説明します。管理者はよく次のような手法を使用して、テキスト ファイルに名前が記載されている複数のコンピュータから Windows Management Instrumentation (WMI) に関する情報を取得しようとします。
Get-Content c:\computers.txt | ForEach-Object
  { Get-WmiObject Win32_Service –comp $_ }
この手法は正しく機能しますが、必ずしもこの手法を使用する必要はありません。その理由は、Get-WmiObject を使用すれば、–computerName パラメータに指定したコンピュータ名の配列を受け取ることができるからです。この同じ効果を得るには、次の手法を使用します。
Get-WmiObject Win32_Service –comp (Get-Content
  c:\computers.txt)
Get-Content コマンドをかっこ内に入れると、シェルによって強制的にこのコマンドが実行され、結果 (コンピュータ名の配列) が –computerName パラメータに格納されます。
プロファイルに関する注意点
Microsoft.PowerShell プロファイルやすべてのシェルに適用されるプロファイルを読み込むアプリケーションは、powershell.exe だけではありません。SAPIEN Technologies の PrimalScript、Quest Software の PowerGUI、ShellTools の PowerShell Plus など、Windows PowerShell のサポートを提供している多くの統合開発環境 (IDE) でも、これらと同じプロファイルを読み込んで、powershell.exe ホストと同じような操作を行うことができます。
多くのスナップインを読み込む、サイズの大きいプロファイルを使用すると、アプリケーションの起動に時間がかかる可能性があります。その理由は、アプリケーションをホストする準備が整うまでに、Windows PowerShell エンジンによって多くの命令が実行されるためです。実際、実行するプロファイルのスクリプトが非常に多い場合は、powershell.exe でも起動に時間がかかります。
複数のスナップインが、同じ名前を持つコマンドレットを定義している場合も、競合が発生する可能性があります。たとえば、2 つのスナップインで Get-User という名前のコマンドレットが定義されている場合は、ユーザーがコマンドレットの完全修飾名を使用して必要なコマンドレットを指定するまで、Windows PowerShell ではどちらのコマンドレットも実行されません。スナップインの名前は非常に長くなることがあるので、この完全修飾名はわかりにくくなる可能性があります。通常、この問題が発生したら、私はこれら 2 つのスナップインを同時に読み込むことをあきらめます。代わりに、プロファイルでよく使用するスナップインだけを読み込み、もう 1 つのスナップインを読み込んで使用する必要がある場合は、別の "新しい" シェルを使用します。
Windows PowerShell のプロファイルでは、多くの便利な機能がシェルに提供されます。ただし、マルウェアによって故意に編集された場合、プロファイルは大規模な損害を引き起こす可能性があることも忘れないでください。プロファイルを保護するには、プロファイルにデジタル署名し、AllSigned 実行ポリシーを使用するよう Windows PowerShell を構成するか、プロファイルの NTFS ファイルに設定されているアクセス許可をすべて変更して、通常のユーザー アカウントではそれらのファイルを変更できないようにします。

Don Jones は、『Windows PowerShell: TFM』と『VBScript, WMI, and ADSI Unleashed』の著者です。連絡先については、PowerShellCommunity.org を参照してください。


Hey, Scripting Guy! 有名な最後の言葉
Microsoft Scripting Guys

有名なギリシャの哲学者であるソクラテス (編集者が生まれる直前の紀元前 399 年に亡くなりました) についておそらく最もよく知られているのは、「吟味されない人生など、生きる価値がない」と述べたことです。この格言は、ほとんどの人が知っています。ただし、驚いたことに、最近 Scripting Guys は、ソクラテスが「吟味されない人生など、生きる価値がない」とは述べていなかったことを知りました。実は、この格言は何百年も前の中世の書記による誤訳だったのです。ソクラテスが実際に言ったのは、次のような言葉でした。「吟味されない XML ファイルなど、持っている価値がない」
これで本当に意味のある哲学的な格言になりましたね。最近は、XML がますます普及しています。Scripting Guys のテスト コンピュータを簡単に検索してみたところ、さまざまなシステムやアプリケーションに使用されている XML ファイルが 500 個以上も見つかりました。
言うまでもありませんが、多くの非常に重要なデータが XML 形式で保存されるようになっています。それはそれで問題ありません。もちろん、そのデータが吟味されていればの話ですが。残念ながらほとんどの場合、多くの人は、XML ファイルを吟味する方法を知らないというだけの理由で、データを吟味していません。特に、クエリを実行してこのような XML ファイルを検索する方法は知られていません。
注 ギリシャの哲学者についてあまりご存じない方のために説明すると、ソクラテスはあちこちでさまざまな物事について語ることを非常に好みましたが、あちこちでさまざまなことを行うのはそれほど好きではありませんでした。実際、ソクラテスの妻のクサンティッペは、彼のことを「役立たずの怠け者」と呼びました。Scripting Guys がソクラテスを大好きな理由がわかったでしょう。
もちろん、このコラムの読者の中には次のように思う方もいらっしゃるでしょう。「ちょっと待って。Scripting Guys は少し前のコラム (technet.microsoft.com/magazine/cc162506 で公開されている「車を追いかけるのと、XML を追求するのと」) で XML ファイルの検索について説明したはずなのに、どうしてまたこのトピックを取り上げるんだろう。Scripting Guys は、同じコラムを何度も繰り返し執筆するほど怠け者なんだろうか」
信じられないかもしれませんが、私たちはそれに輪を掛けた怠け者です。でも、それは私たちがこのトピックを再び取り上げた最大の理由ではありません。以前のコラムでは、図 1 のコードのような構造を持つ XML ファイルの操作方法を説明しました。このファイルでは、それぞれのプロパティ値が 1 つのノードを表しています。
図 1. ノードのみを使用した XML ファイル
<?xml version='1.0'?>
  <INVENTORY>
    <COMPUTER>
      <os>Windows XP</os>
      <department>Human Resources
      </department>
      <name>atl-ws-001</name>
    </COMPUTER>
    <COMPUTER>
      <os>Windows XP</os>
      <department>Finance</department>
      <name>atl-ws-002</name>
    </COMPUTER>
    <COMPUTER>
      <os>Windows Vista</os>
      <department>Finance</department>
      <name>atl-ws-003</name>
    </COMPUTER>
  </INVENTORY>
これ自体はすばらしいことですが、すぐにお便りでご指摘いただいたとおり、XML ファイルを構造化する方法は他にもあります。上記の例では、ファイル内のコンピュータごとにノードがあります。また、それらのノードごとに多くの子ノード (os、department、および name) があります。ただし、それぞれのノードに子ノードがない XML ファイルを作成することもできます。その他のプロパティ値は属性として構成されます。たとえば、図 2 のようなファイルです。
図 2. 属性を使用した XML ファイル
<?xml version='1.0'?>
  <HARDWARE>
      <COMPUTER os="Windows XP" department="Human Resources">atl-ws-001</COMPUTER>
      <COMPUTER os="Windows XP" department="Finance">atl-ws-002</COMPUTER>
      <COMPUTER os="Windows Server 2003" department="IT">atl-fs-003</COMPUTER>
      <COMPUTER os="Windows Vista" department="IT">atl-ws-004</COMPUTER>
      <COMPUTER os="Windows Vista" department="Human Resources">atl-ws-005</COMPUTER>
      <COMPUTER os="Windows Vista" department="Finance">atl-ws-006</COMPUTER>
      <COMPUTER os="Windows XP" department="Sales">atl-ws-007</COMPUTER>
      <COMPUTER os="Windows Server 2008" department="IT">atl-fs-008</COMPUTER>
      <COMPUTER os="Windows XP" department="Human Resources">atl-ws-009</COMPUTER>
      <COMPUTER os="Windows Vista" department="Sales">atl-ws-010</COMPUTER>
  </HARDWARE>
このことは問題になるでしょうか。実は、問題になります。ずっと前、はるか昔の号で紹介したスクリプトでは、図 2 のような構造の XML ファイルを処理できません。それは確実です。皆さんの多くはこの種類の XML ファイルを読み取ることができる必要があるので、これは間違いなく問題になります。
質問してくださればよかったのに。質問して、私たちが最終的にこの問題を解決するまで 1 年半待つだけでよかったのです。
説明を続ける前に、この XML ファイルを詳しく見てみましょう。このファイルには、HARDWARE という名前のプライマリ ノードがあり、個々のコンピュータはすべて HARDWARE の子ノードとして存在しています。さらに、これらのノードにはそれぞれ 2 つの属性があります。その属性は、os (コンピュータにインストールされているオペレーティング システムの名前を格納するために使用されます) と department (コンピュータを所有している部門の名前を格納するために使用されます) です。
たとえば、Windows XP を実行しているすべてのコンピュータの一覧を取得するとしましょう。スクリプトを使用してこの処理を実行できるでしょうか。もちろん、できます。
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("HARDWARE.xml")

Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER[@os='Windows XP']")

For Each objNode in colNodes
  Wscript.Echo objNode.Text
Next
このスクリプトの内容を説明しましょう。まず、Microsoft.XMLDOM オブジェクトのインスタンスを作成します。名前のとおり、これは XML ファイルを操作するために使用するオブジェクトです。このオブジェクトを作成したら、次は Async プロパティを False に設定します。これで、非同期ではなく同期を取ってドキュメントを読み込むことがスクリプトに伝えられます。なぜスクリプトがこれを気にするのでしょうか。正直言って、気にはしないでしょう。スクリプトは (Scripting Guys と同様) 生物ではありませんからね。
ただし、皆さんは気にする必要があります。非同期にドキュメントを読み込むと、ドキュメントが完全に読み込まれていない場合でもスクリプトは続行されます。これは適切ではありませんね。まだ存在しないドキュメントを使用して作業しようとしたときに発生する可能性がある問題を想像してみてください。同期を取って XML ファイルを読み込むと、ファイルが完全に読み込まれてからスクリプトが続行されます。
偶然にも、次の処理は XML ファイルの読み込みです。これを行うには、Load メソッドを呼び出して C:\Scripts\HARDWARE.xml ファイルを開きます。続いて、次のコードを実行します。
Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER[@os='Windows XP']")
ここでは SelectNodes メソッドを使用して、XML ファイルに対してクエリを実行し、取得する XML ノードをスクリプトに指示しています。構文に注目してください。確かに、少し変わった構文です。
まず、XML ファイル内のパスを指定する必要があります。今回の XML ファイルには、最も上のレベルに HARDWARE という名前のノードがあり、続いて第 2 レベルに COMPUTER という名前の一連のノードがあります。第 2 レベルにあるこれらのノードは、それぞれ XML データ ファイルの 1 つのレコードを表しています。selectNodes クエリの冒頭が次のようになっているのはこのためです。
//HARDWARE/COMPUTER
ここで、次の構文に続きます。
[@os='Windows XP']
クエリのこの部分は、標準的な SQL クエリの WHERE 句とよく似ています。SQL の場合、次のようなデータベース クエリを使用して、Windows XP オペレーティング システムを実行しているすべてのコンピュータの一覧を取得できます。
SELECT Name FROM Hardware
    WHERE OS = 'Windows XP'
SelectNodes メソッドの場合も、これと同様の処理を行います。つまり、os 属性 (@os) が Windows XP であるすべてのコンピュータの一覧を取得するよう要求しています。さらに、WHERE 句であることを示すために、句全体を角かっこで囲んでいます。
注 このようなクエリを、XPath クエリと呼びます。XPath の詳細については、msdn.microsoft.com/library/ms256115.aspx を参照してください。
既に述べたように、この構文は少々変わっていますが、うまく機能します。では、財務部門が所有しているすべてのコンピュータの一覧を取得する場合はどうでしょうか。簡単です。selectNodes メソッドの呼び出しは、次のようになります。
Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER" & _
   "[@department='Finance']")
ここでも、WHERE 句を角かっこで囲み、属性名 (department) の前にアットマーク (@) を追加してから、目的の値を指定しています。
簡単でしょう。
selectNodes メソッドを呼び出したら、コンピュータ名をエコー バックできます。これを行うには、次のように、返された値のコレクションに対して繰り返し処理を実行し、Text プロパティをエコー バックするだけです。
For Each objNode in colNodes
  Wscript.Echo objNode.Text
Next
では、どのような情報が返されるのでしょうか。正直に言って、間違いなく次のような情報が返されます。
atl-ws-001
atl-ws-002
atl-ws-007
atl-ws-009
つまり、Windows XP を現在も実行しているすべてのコンピュータの名前が返されます。
ちなみに、取得できるのはコンピュータ名だけではありません。コンピュータ名は各ノードの "既定" 値なので、Text プロパティを参照すると返される値がコンピュータ名になっているだけです。
代わりに、返される属性値を厳密に指定することもできます。たとえば、修正された次の For Each ループをご覧ください。
For Each objNode in colNodes
    Wscript.Echo objNode.Text
    Wscript.Echo objNode.Attributes. _
      getNamedItem("department").Text
    Wscript.Echo
Next
ご覧のとおり、このループでも Text プロパティの値をエコー バックしていますが、次のコード行も追加しています。
Wscript.Echo objNode.Attributes. _
  getNamedItem("department").Text
この場合、getNamedItem メソッドを使用して department 属性の値を取得し、続いてその属性の Text プロパティをエコー バックします。このようにして、画面にエコー バックする属性値 (およびエコー バックしない属性値) を指定できます (Wscript.Echo コマンドを追加してレコードの間に空白行を表示していることにも注目してください)。このスクリプトを実行すると、次のような情報が返されます。
atl-ws-001
Human Resources

atl-ws-002
Finance

atl-ws-007
Sales

atl-ws-009
Human Resources
もちろん、必要に応じてさらに複雑なクエリも記述できます。たとえば、Windows XP または Windows Vista を実行しているすべてのコンピュータの一覧が必要であるとします。SQL の場合、この処理は OR クエリを記述して実行します。そして、XML ファイルに対してクエリを実行する場合も、まったく同じことを行います。
Set colNodes=xmlDoc.selectNodes _
    ("//HARDWARE/COMPUTER" & _
     "[@os='Windows XP' or " & _
     "@os='Windows Vista']")
上記のスクリプトでは、どのような処理を実行しているのでしょうか。1 組の角かっこの中に 2 つの条件 (@os='Windows XP'、または @os='Windows Vista') が指定されています。このように変更するだけで、図 3 のようなレポートが返されます。
図 3. OR クエリの結果
atl-ws-001
Human Resources

atl-ws-002
Finance

atl-ws-004
IT

atl-ws-005
Human Resources

atl-ws-006
Finance

atl-ws-007
Sales

atl-ws-009
Human Resources

atl-ws-010
Sales
XML ファイルを再確認すると、Windows XP または Windows Vista を実行しているコンピュータが出力に含まれていることがわかります。Windows Server 2003 または Windows Server 2008 を実行しているコンピュータは含まれていません。含まれていても困りますが。
質問ですか、どうぞ。財務部門が所有している Windows XP コンピュータだけを返すクエリなど、より対象が限定されたクエリを記述する方法はあるか、ですね。ご想像のとおり、簡単です。次のような AND クエリを記述するだけで実行できます。
Set colNodes=xmlDoc.selectNodes _
    ("//HARDWARE/COMPUTER" & _
     "[@os='Windows XP' and " & _
     "@department='Finance']")
この処理を実行すると、次のようなデータセットが返されます。
atl-ws-002
Finance
なぜレポートの項目が 1 つだけなのでしょうか。そのとおりです。財務部門には Windows XP を実行しているコンピュータが 1 台しかないからです。
皆さんがこのような XML ファイルを操作するうえで、上記の説明がお役に立つことを願っています。こっそり他の種類の XML ファイルが存在していた場合は、健闘を祈ります。
今月のコラムを有名な格言で始めたので、同じような調子でコラムを終えるのがふさわしいと思います。そこで、皇帝ヴィルヘルム 2 世の次の言葉で締めくくります。Scripting Guys はこの言葉を大切にしています。「ここに、予はプロイセン王位、およびそれに伴うドイツ帝国の帝位を主張する権利を、永久に放棄する」
Dr. Scripto のスクリプト パズル
パズルを解く能力だけでなく、スクリプト作成スキルもテストする月に 1 度の課題です。

2008 年 10 月 : VBScript の穴埋め
このパズルを解くには、各行に VBScript 関数の名前を当てはめるだけです。完成したら青いマス目の文字を解読して、関数名をもう 1 つ見つけてください。

解答 :
Dr. Scripto のスクリプト パズル
解答 : 2008 年 10 月 : VBScript の穴埋め

Scripting Guys の Greg Stemp と Jean Ross は、マイクロソフトに勤務しています。


デスクトップ ファイル Windows 展開サービスをカスタマイズする
Wes Miller

目次
既存テクノロジの代わりに使用する
WDS を使用した展開プロセス
ネットワーク ブート プログラム
WDS PXE プロバイダ
TFTP デーモン
ブート構成データ ストア
Windows PE
トランスポート サーバー
カスタム マルチキャスト
まとめ
この記事では、3 か月にわたって Windows 展開サービス (WDS) を紹介してきました。初回は WDS の誕生について、2 回目では概要を紹介し、3 回目では WDSUtil やマルチキャストなど、いくつかの高度なトピックについて紹介しました。このシリーズの最終回となる今月の記事では、組織のニーズに合わせて WDS をカスタマイズするポイントとその方法を紹介します。マイクロソフトが提供する多くのツールには、ユーザーが構成できる要素が組み込まれています。ですが、重要なのは、そのツールがニーズを満たすかどうか、そのシナリオでツールを使用するにはツールをカスタマイズする必要があるかどうかを判別することです。

既存テクノロジの代わりに使用する
最近、読者の皆さんから「x (既存の展開テクノロジ) を使用していますが、その代わりに WDS を使用することはできますか。また、WDS には x に対応したパリティ機能はありますか。」という質問がよく寄せられます。Automated Deployment Services (ADS) の廃止により、「大容量サーバーを迅速に展開または再準備するのに WDS を使用できるのか」ということが最大関心事項の 1 つになっています。
WDS は、ADS に完全に対応した後継テクノロジとしてデザインされたものではありません。実際、完全に対応した後継テクノロジとして見なすには、いくつかの主要コンポーネントが不足しています。ですが、少し手を加えれば、WDS を ADS の後継テクノロジとして使用することは可能です。同様に、既定の構成を使用した場合に、WDS の動作がご使用の環境に適していなければ、WDS の多くのコンポーネントは別のテクノロジに置き換えることができます。それに伴う作業の複雑さと作業量は、対象のコンポーネントと代替テクノロジによって異なります。次は、WDS を使用した展開について見てみましょう。カスタマイズできるコンポーネントを紹介し、カスタマイズする方法を説明します。

WDS を使用した展開プロセス
図 1 は、WDS を使用した展開プロセスのコンポーネントの一覧です。このプロセスの各ステップは、カスタマイズすることができます。各ステップには、私の個人的な見解に基づいて色付けをしました。これは各ステップを代替テクノロジに置き換えたり、カスタマイズしたりする作業の複雑さ (通常は、開発スキルの難易度) を示しています。青色が濃いほど、そのステップをカスタマイズする難易度は高くなります。
図 1 WDS のカスタマイズ難易度
各ステップをカスタマイズする際の実際の難易度は、チームのスキル (開発スキルまたはスクリプト作成スキル) と WDS、Windows Imaging Format (WIM)、Active Directory、統合する必要がある他のテクノロジ (SQL、ADSI など) に関する理解度に左右されます。今度は、各ステップをカスタマイズする方法やカスタマイズに使用するテクノロジを詳しく見てみましょう。

ネットワーク ブート プログラム
WDS で提供されているネットワーク ブート プログラム (NBP) の代わりにカスタム NBP を使用しなければならないことはまれですが、カスタム NBP を作成することは可能です。WDS には、ヘッドレス システム (通常、サーバー) や F12 キーの入力を必要としたり必要としなかったりするシステムなどで使用できる NBP が同梱されています。このような NBP は、WDSUtil を使用して Active Directory にプレステージするか、または Startrom.com をプレステージされていない全システムに使用する NBP に置換することができます (たとえば、すべてのシステムがヘッドレスである場合や F12 キーの入力を必要としない場合などです)。
残念ながら、カスタム NBP の作成方法に関する資料はあまり多く提供されていません (参考情報については、msdn.microsoft.com/library/bb870970.aspx を参照してください)。また、NBP は、非常に小規模な 16 ビットの実行可能プログラムですが、厳しい制限があり、開発には特殊なプログラミング スキルが必要です。ですから、非常な特殊な要件を満たす必要があり、かつ開発チームにカスタム NBP の開発に必要なスキルを持ったメンバがいる場合を除き、通常、WDS で提供されている既存の NBP を使用することをお勧めします。

WDS PXE プロバイダ
リモート インストール サービス (RIS) に関しては、ユーザーから、クライアント システム情報の管理に Active Directory 以外のデータ ソースを使用することを希望するフィードバックが多く寄せられており、その多くは SQL Server を使用したいというものでした。WDS には、Pre-Boot eXecution Environment (PXE) プロバイダに対応したプラグ可能なインフラストラクチャが備わっています。つまり、WDS では、(開発作業は必要になりますが) PXE 情報を格納するデータ ソースとして、Active Directory 以外のテクノロジを使用できるということです。
WDS には、Active Directory を使用するプロバイダが用意されていますが、System Center Configuration Manager (SCCM) が WDS に統合されるようになり、SCCM では独自のプロバイダが実装されています。カスタム プロバイダを記述する方法に関する資料は非常に少なく、サンプル コードもあまり提供されていません (ただし、Windows SDK では、いくつかの資料とサンプルを提供しています)。そのため、カスタム プロバイダを記述するのは、控え目な方には向かない作業です。繰り返しになりますが、このブート プロセスに関して非常に特殊な要件がない限り、カスタム PXE プロバイダを作成することはお勧めしません。

TFTP デーモン
WDS が登場するまで、独自の簡易ファイル転送プロトコル デーモン (TFTPD) を使用しているユーザーは多数存在していました。ですが、PXE サーバーは適切に連動しないため、1 台の PXE サーバーを使用せざるを得ないというのが現状でした。
私の経験上、これは、既存の TFTPD (通常、Linux ベースの TFTPD) を使用して、他の OS を起動するように誘導するということでした。RIS で採用されていた初期のインフラストラクチャでは、これを行うことはできませんでした。ですが、RAMDisk によるブートが一般的に使用されるようになると、これが可能になりました。また、WDS ベースのブート イメージを使用して、このような処理を行うことも依然として可能です。
ここで注意点が 1 つあります。それは、TFTPD を使用するということは、マイクロソフトが技術的なサポートを提供していない分野に足を踏み入れていて、診断が困難な問題がほぼ確実に発生するということです。また、WDS で提供されている強化された TFTPD を使用すると、パフォーマンスが低下する可能性があります。理想的には、既存のサーバーを現状に合わせて調整するのではなく、WDS に用意されている TFTPD を使用し、PXE タイムアウト、プレステージ、ネットワーク エッジを使用して、どのクライアントがどの PXE サーバーからブートするのかを定義することをお勧めします。

ブート構成データ ストア
RIS では、ブート レベルでブートするものを指定することはできず、OSChooser を使用して、オプション (セットアップ、Windows PE (Windows プレインストール環境)、その他) を選択する必要がありました。WDS では、ネットワーク ブートで完全な OS ローダーを使用しているので、クライアントに提供しているブート構成データ (BCD) ストアのカスタマイズがサポートされます。各アーキテクチャの既定の BCD は、RemoteInstall\Boot\<arch>\Default.bcd に格納されています。<arch> の部分は、ブートするシステムのアーキテクチャ名になります。
この BCD はクライアントごとにカスタマイズすることが可能で、クライアントはカスタマイズした BCD を使用してブートできます。たとえば、セットアップを開始する BCD エントリ、Windows 回復環境 (RinRE) を実行する BCD エントリ、およびメモリ テストを実行する BCD エントリを作成することが可能です。また、完全に自動化されたセットアップ用の BCD エントリを既定のエントリとして指定し、手動セットアップ用の (セットアップ動作をカスタマイズする) BCD エントリをユーザーが選択できるオプションとして提供することもできます (詳細については、「Bcdedit を使用して BCD ストアを変更する方法」(go.microsoft.com/fwlink/?LinkId=115267) を参照してください)。

もちろん、WDS による複雑な処理の大半は Windows PE で行われます。ですから、ニーズに合わせて Windows PE をカスタマイズすることは、カスタム設定を実現するうえで重要です。WDS には、セットアップ向けの非常に汎用性の高いテンプレートが用意されています。このテンプレートでは完全なセットアップ エクスペリエンスが提供されます。ただし、展開のニーズによっては、このテンプレートが適さないことがあります。その場合は、独自の Windows PE ブート イメージを作成できます。では、この作業について最初から見ていきましょう。
BCD を使用すると、使用するイメージを指定できるだけでなく、Active Directory でコンピュータのコンピュータ アカウント オブジェクト (MAO) をカスタマイズして、イメージを指定することもできます。RIS では、特定の MAO 属性に各項目 (使用する Startrom と無人セットアップ用の .SIF ファイル) が格納されていました。WDS では、このような情報は、netBootMirrorDataFile という名前のエントリに名前と値の組み合わせとして格納されます。たとえば、特定のコンピュータで使用するブート イメージと無人セットアップ ファイルは、このエントリに格納されます。このエントリは、名前と値の組み合わせがセミコロンで区切られた形式で記載されます。ブート イメージと無人セットアップ ファイルを変更する場合は、それぞれ BootImage および UnattendFilePath というエントリを変更します。
もちろん、既存のセットアップ エクスペリエンスを一切使用せずに、独自のセットアップ エクスペリエンスを提供したい場合もあるでしょう。また、より詳細な構成を行ったり、さらに自動化したり、SQL Server によって自動的に作成されるビルドが必要になったりする場合もあるでしょう。さらには、初期の RIS と Windows PE を使用していたときのユーザーと同様に、セットアップ用に独自のフロント エンドを構築することを必要とする方もいるでしょう。どのようなセットアップ エクスペリエンスを提供する場合でも、以下の作業が必要になります。
  • 各コンピュータまたは各ユーザーの情報を取得する。この情報はユーザー入力、SQL Server、テキスト ファイルなどから入手できます。
  • セットアップ イメージをクライアント システムにコピーして適用する。この作業は、セットアップを直接使用するか、ImageX を使用してネットワーク共有のイメージを適用するか、またはマルチキャストを使用して (単に ImageX を使用してイメージをコピーして適用) 実行できます。
  • セットアップを完了するための無人セットアップ ファイルを提供します (使用するファイルは展開する Windows のバージョンによって異なりますが、Unattend.xml や sysprep.inf です)。
  • セットアップ後に行う移行手順を自動化する (Windows Server 2008 の場合は、役割を適用する手順を自動化する必要があります)。
ADS では、繰り返し実行できる手順を複数台のコンピュータに割り当てられるようにするタスク シーケンスという概念が導入されました。ADS は、Windows XP での使用を想定してデザインされておらず、Windows XP はサポートされていないので、Windows XP の展開に ADS を使用することはできませんでした。しかし、ADS のタスク シーケンスは、単なる構造化されたスクリプトなので、カスタム セットアップ プロセスを使用して同じ手順を実行することができます。
私は、長期にわたって Microsoft SQL Server を好んで使用してきたので (SQL Server 6.5 から使用しています)、この構造の実現に SQL Server を使用することにしました。もちろん、これには Windows PE のビルドに SQL Server の機能を追加する必要があります。また、独自の GUI (HTML アプリケーション (HTA) またはコンパイル済みの実行可能ファイル) を記述するか、Windows Script Host (WSH) を使用して、コマンドラインのみの必要最低限のセットアップ エクスペリエンスを実現できます。HTA や WSH を使用する場合にも、これらを Windows PE に追加する必要があります。
独自のセットアップ エクスペリエンスのデザインの難易度は、皆さんがお持ちのスキルと想像力によって大きく異なります。SQL Server と WSH または HTA のどちらかだけを使用して定義した非常にすばらしいシステムは実在します。また、これらのスキルは比較的習得しやすいものです。ただし、このシリーズの記事で説明した次のような制限事項に留意することが非常に重要です。
  • Windows PE では、Windows on Windows (WOW) サブシステムがサポートされていないので、サポートするアーキテクチャごとにコンパイルする必要があります。
  • x64 版または IA64 版の Windows PE を使用して展開する必要がある場合、Visual Basic 6.0 は使用できません。
  • Visual Studio 2005 または Visual Studio 2008 を使用してアプリケーションを作成することは可能ですが、Windows PE では、どのバージョンの Microsoft .NET Framework もサポートされていないので、Visual C++ アンマネージ アプリケーションを作成する必要があります。
  • .NET Framework を使用できなければ、Windows PowerShell を使用して自動化を実現することもできません。
もちろん、独自のセットアップ エクスペリエンスを実現するために、WDS でサードパーティ製のイメージ作成ユーティリティを使用することも可能です。大半の展開シナリオには WIM 形式と ImageX を使用して対応できると思いますが、ある特定の要件を満たすのに既存のイメージ作成ツールが適している場合もあります。
同様に、特定のシナリオでは、特殊なパーティション分割が必要な場合もあります。たとえば、BitLocker を使用して Windows Vista を展開していたり、Windows XP システムを構築していて、別のボリュームにプロファイル データを格納していたり、Windows Server システムを展開していて、同じディスク上にある別のボリュームにログを記録したりする場合などが、これに該当します。このような処理を行うには、DiskPart を自動化する必要があります。これは以前のバージョンと同様に、実行する必要があるコマンドと DiskPart を終了するための exit コマンドが最後に記載された任意のファイル形式のスクリプトを DiskPart に渡すことで行えます。
カスタム セットアップ エクスペリエンスを構築するということは、基本的にセットアップ実行可能ファイルを再構築する (少なくとも、その機能を再現する) ことになり、相当量のデザインと構築作業が伴うため、気が弱い方には向かない作業です。実際の作業の難易度は、どの程度の機能を組み込み、そのセットアップを何で (HTA、WSH、コンパイル済みのプログラミング言語) 構築するかによって異なります。

トランスポート サーバー
Active Directory など、WDS の組み込み機能の大半を使用していなかったり、独自の完全なカスタム ソリューションを構築している場合は、トランスポート サーバーを使用すると、面倒な要件を発生させることなく、ニーズを満たせることがあります。図 2 の表に、WDS のトランスポート サーバーの役割に含まれているものを示します (この表は、「トランスポート サーバーを使用する」(go.microsoft.com/fwlink/?LinkID=115298) からの引用です)。
図 2 展開サーバーとトランスポート サーバー
 | 展開サーバー | トランスポート サーバー
サーバー要件 | 環境内に Active Directory ドメイン サービス (ADDS)、動的ホスト構成プロトコル (DHCP)、ドメイン ネーム システム (DNS) が必要です。 | 環境内に他のサーバーは必要ありません。
PXE | 既定の PXE プロバイダで PXE ブートをサポートします。 | PXE プロバイダはインストールされていないので、カスタム PXE プロバイダを作成する必要があります。
イメージ サーバー | Windows 展開サービス イメージ サーバーが用意されています。 | Windows 展開サービス イメージ サーバーは用意されていません。
転送方法 | ユニキャストとマルチキャストの両方がサポートされます。 | マルチキャストのみがサポートされます。
管理ツール | Windows 展開サービスの MMC スナップインか WDSUtil コマンド ライン ツールのどちらかを使用して管理します。 | WDSUtil コマンド ライン ツールのみを使用して管理します。
クライアント コンピュータのアプリケーション | Windows 展開サービス クライアント (基本的には Setup.exe とサポート ファイル)、Wdsmcast.exe (Windows AIK に収録されています)、またはカスタム マルチキャスト アプリケーションを使用します。 | Wdsmcast.exe またはカスタム アプリケーションのどちらかのみを使用します。
トランスポート サーバーの実装が困難であると言うのは、このサーバーの役割自体が複雑だからではありません。この役割自体は簡単に展開できます (図 3 参照)。追加の作業が必要で困難なのはトランスポート サーバーに関連するカスタム セットアップの実装です。トランスポート サーバーの役割を適切に使用すると、WDS の役割に組み込まれている使いやすさが失われます。
図 3 トランスポート サーバーはカスタム展開シナリオに適している場合がある (画像をクリックすると拡大表示されます)

カスタム マルチキャスト
トランスポート サーバーの役割を使用しているかどうかに関係なく、複数のシステムを展開している場合には、マルチキャストを使用すると役に立つことがあります (ただし、この役割を使用している場合は特にマルチキャストが役立ちます)。ADS では、強力なマルチキャスト機能がサポートされていました。WDS をマルチキャストと組み合わせて使用すると、この機能を再現できます。WDS 自体でも、マルチキャストをサポートしていますが、独自のカスタム ソリューションを作成している場合は、先月ご紹介したように WDSMCast を使用してマルチキャストを使用できます (図 4 参照)。ただし、展開するイメージ ファイルは、転送して適用する必要があることに注意してください。通常、これは、ローカル ディスクに、イメージを格納して適用するのに十分な領域を確保する必要があるということになります。
図 4 WDSMCast の実行 (画像をクリックすると拡大表示されます)

まとめ
WDS は単独で使用した場合にも、多くの組織のニーズを満たせる優れた機能を提供します。ですが、WDS の境界を越えた独自のソリューションを作成する必要がある場合は、それも可能です。その障害となるのは、あなたの想像力、スケジュール、そしてスキルだけです。

Wes Miller は、テキサス州オースティンにある CoreTrace 社 (CoreTrace.com) のシニア テクニカル プロダクト マネージャです。以前は Winternals Software 社に勤務し、その後はマイクロソフトでプログラム マネージャとして働いていました。Wes の連絡先は、technet@getwired.com (英語のみ) です。


セキュリティ ウォッチ セキュリティに関する 10 の鉄則再考 : 第 1 部
Jesper M. Johansson

Scott Culp は、2000 年に「セキュリティに関する 10 の鉄則」というエッセイを公開しました。これは、セキュリティに関して私がこれまでに読んだ中で、最も優れたエッセイの 1 つです。彼が提供した情報は、いまだに情報セキュリティに関するすべての作業の基礎になっているので、まだ読んでいない方は、Web 上で (または印刷して) 一読することをお勧めします。このエッセイは、microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx で公開されています。
このエッセイには、さまざまな反応が寄せられました。一部の人々は、これはマイクロソフトが多くの深刻な問題の解決を避けるための方法である、と皮肉たっぷりに批評しました。また、これはセキュリティに関する最も基本的な項目が含まれた文章であると考え、その重要性の高さから、好き勝手に盗用する人々もいました。最も興味深い反応の 1 つは、edgeblog.net/2006/10-new-immutable-laws-of-it-security で公開されているような一覧を人々が独自に作成する気になったことです。
このエッセイが公開されてから 8 年の間に、セキュリティ分野ではさまざまなことが起こりました。注意すべき重要なワームは、ほぼすべて明らかになりました。また、世界は (組織犯罪や政治的要素を含む) 情報戦争に突入しました。さまざまな新しい単語や語句が一般的な用語になりました。たとえば、フィッシング、ファーミング、ボットネット、スパイウェア、クロスサイト リクエスト偽造攻撃などが挙げられます。また、Windows 上で動作する非常に巧みないくつかのルートキットが作成されました。さらに、セキュリティを強く意識した新しいオペレーティング システムが発表される一方で、依然としてセキュリティがほとんど無視されたオペレーティング システムも存在しました。
ソーシャル エンジニアリングは、主要な脅威へと進化しました。9,400 万人のクレジット カード番号を流出させた大手小売業者など、データの漏洩も、よくニュースの話題として登場するようになりました (そして、人々は現在でもそのような店舗でショッピングをしています)。米国および英国政府は、西欧諸国に住む非常に多くの人々の個人情報を誤って適切でない場所に配置しました (そして、人々は現在でもこれらの政府に個人情報を提供しています)。セキュリティ ショーも、私たちの生活、および空港に非常に多く入り込んでいます。
私は、今こそセキュリティに関する鉄則の見方を変えるべきだと思います。今世紀の初頭に起こったあらゆる変化を考えて、それでもなお、これらの鉄則が絶対であると主張できるでしょうか。それが可能であれば、つまりこれまでの 8 年間生き残ってきたのであれば、これらの鉄則は今後 10 年間生き残ると言ってもよいでしょう。
この 3 部シリーズでは、10 の鉄則それぞれを批判的に分析します。今月は鉄則 1 ～ 3 を取り上げます。そして来月は、鉄則 4 ～ 7 を取り上げます。最終回では、鉄則 8 ～ 10 を取り上げ、2000 年にこれらの鉄則が初めて公開されてから現在までに起こったことを踏まえて、妥当だと思われる考え方と見解を提供します。
鉄則 1: 悪意のある攻撃者の誘惑に乗って、攻撃者のプログラムをあなたのコンピュータで実行した場合、もはやそれはあなたのコンピュータではない
この鉄則は実質的に、コンピュータで実行されるすべてのソフトウェアが、そのコンピュータを制御する可能性があることを示しています。これらの鉄則が初めて公開されたときにマイクロソフトから提供されていた最新のオペレーティング システムは、Windows 98、Windows Me、および Windows NT 4.0 でした。現在私たちが使用しているのは、Windows Vista や Windows Server 2008 です。
Windows 98 と Windows Me では、実行するすべてのソフトウェアがコンピュータを完全に制御していました。Windows NT 4.0 は、信頼性の高いセキュリティ モデルに基づいて構築されましたが、管理者として実行すると、事実上その分離レベルは Windows 98 と Windows Me と同じレベルまで低下しました。Windows NT 4.0 を管理者以外のアカウントで実行することもできますが、非常に骨の折れる作業だったので、その方式を採用した組織はごくわずか (両手で足りるほど) でした。
Windows NT 4.0 を管理者以外のアカウントで実行したとしても、鉄則が公開された当時、鉄則 1 は有効であると言えたでしょうか。答えはイエスです。まず、Windows NT 4.0 には非常に多くの重大な欠点がありました。たとえば、特にカーネル オブジェクト上やレジストリ内で厳しく制限することもできたアクセス許可がありました。また、まだ見つかっていなくても、専門家が登場を予測した攻撃の種類が数多くありました。たとえば 1999 年、ユーザーは、昇格したユーザーとして対話型デスクトップでプロセスを実行するとコンピュータが攻撃を受ける可能性があることを認識していませんでした。2002 年に Chris Paget がシャッター攻撃に関するホワイト ペーパーを公開 (seclists.org/bugtraq/2002/Aug/0102.html) して初めて、これが一般的な知識になりました。
鉄則 1 が考案されたとき、マイクロソフトはシャッター攻撃の出現を予測していたでしょうか。実はそれほど確固とした予測が立っていたわけではありません。マイクロソフトが認識していたのは、ある単純な事実のみです。それは、コンピュータ上で実行されるアプリケーションがそのコンピュータを完全に制御できないようにする真のセキュリティ境界は、ほとんど存在しないことです。
Windows Vista と Windows Server 2008 の 2 つは、Windows NT 4.0 とは完全に異なるオペレーティング システムです。これらのオペレーティング システムによって、鉄則 1 の説得力は弱まるでしょうか。また、他にこの鉄則に該当するオペレーティング システムは存在するでしょうか。この答えは場合によって変わります。確かに、新しいオペレーティング システムでは、より強力なセキュリティ境界が提供され、2000 年には、適切なセキュリティ境界を提供するいくつかのオペレーティング システムが、実験に基づいて作成されました。ただし、現在提供されているのは、それらのセキュリティ境界のうちのごくわずかに過ぎません。たとえば、Microsoft .NET Framework のコード アクセス セキュリティはセキュリティ境界です。このセキュリティ境界は、サンドボックス内で実行されるコードが、基盤となるオペレーティング システムに影響を与えないように設計されています。
Internet Explorer の Iframe では、また別のセキュリティ境界が提供されます。ただし、Iframe はオペレーティング システム自体へのアクセスには影響を与えず、Web ページ コンテンツ間のアクセスにのみ影響を与えます。Internet Explorer の保護モード (図 1 参照) は、オペレーティング システム レベルのセキュリティ境界です。保護モードの目的は、ブラウザ内で実行されるコードが、基盤となるオペレーティング システムに影響を与えないようにし、さらにそれをユーザーの操作なしで実現することです。他にもいくつかのセキュリティ境界があります。たとえば、標準ユーザー アカウントは、ユーザー アカウントが他のユーザーや基盤となるオペレーティング システムに影響を与えないことを目的としたセキュリティ境界です。
図 1 Internet Explorer 7 でセキュリティ境界として使用される保護モード (画像をクリックすると拡大表示されます)
"セキュリティ境界" という言葉が何を意味するかを理解することは非常に重要です。これは、攻撃を受けない無期限の分離を提供することが保証された、絶対に壊れない壁を意味しているわけではありません。本当の意味は、マイクロソフトなどのソフトウェア ベンダが、セキュリティ更新プログラムを使用して、攻撃を受けた境界を修正する責任を負っていることです。ソフトウェアには常にバグが存在し、必ずユーザーは、その後もさらに多くのバグを発見し続けるので、ソフトウェア ベンダは修正プログラムの開発を続けることになります。やがて、ベンダによってソフトウェアが強化され、最初に存在した脆弱性も解決されます。このことから、鉄則 1 は現在でも有効であると考えることができます。
ただし、もう 1 つ重要なことを検討する必要があります。先ほど "ユーザーの操作なしで" という表現を使用しました。鉄則 1 は、ソフトウェアの欠点や脆弱性について述べた鉄則ではありません。人々の中に潜む脆弱性について述べているのです。鍵となるフレーズは "説得する" です。悪意のある人物が、特定のプログラムを実行するようユーザーを説得できる場合、おそらくその人物は、昇格した特権が (仕様に従って) プログラムに与えられるコンテキストでそのプログラムを実行するようそのユーザーを説得することもできます。
そのユーザーが管理者特権を持っていなくても、おそらくそれは問題になりません。標準ユーザーでも、多くの重要な情報にアクセスできます。たとえば、銀行関連のファイル、ラブレター、写真、ビデオ、企業の機密データなどがあります。これらのデータはすべて、攻撃者に興味を与える可能性があり、すべて昇格した特権なしで参照できます。コンピュータ上で情報を管理するという観点から考えると、悪意のあるプログラムを実行することによって、そのコンピュータ上で行うすべての操作内容が攻撃者の手に渡ります。このため、"コンピュータ" の定義が "コンピュータ上で管理しているデータ" である場合、特権に関する話題は無視し、鉄則 1 は有効であると結論付けることができます。
コンピュータの定義に関する細かいことを抜きにしても、鉄則 1 は時の試練に耐えたと思います。鉄則 1 で重要なのは、コンピュータを操作するユーザーが、そのコンピュータ上で実行するソフトウェアに責任を持つ必要があることです。悪意のあるドライバやビデオ コーデックをインストールした場合、それは犯罪者がそのコンピュータを完全に制御できるようになったことを意味します。
ソフトウェア ベンダは、誤ってコンピュータが攻撃されるのを防ぐためにさまざまな対策を施しています (それがセキュリティ境界の意義です) が、通常、悪意のあるソフトウェアを意図的に実行すると、それらの保護対策がすべて突破されてしまいます。これが、管理タスクを実行できるアクセス許可をユーザーに与えないようにするだけでなく、ユーザーを教育することも重要である理由です。したがって、鉄則 1 は今日でも有効であると言って間違いありませんが、場合によってはコンピュータに関する皆さんの定義を少し変えていただく必要があります。
鉄則 2: 悪意のある攻撃者があなたのコンピュータのオペレーティング システムを改ざんした場合、もはやそれはあなたのコンピュータではない
表面上、これは非常にわかりやすい鉄則であるように思われます。当然のことですが、悪意のある人物にコンピュータのオペレーティング システムを改ざんされた場合、そのコンピュータを信頼することはできなくなります。ただし、コンピューティングに関する要件が進化するに従って、オペレーティング システムが持つ意味も変わりました。何年も前に、私は『The Blackwell Encyclopedia of Management』(managementencyclopedia.com) に掲載されている "オペレーティング システム" の項目を執筆しました。その定義には、"オペレーティング システムは入力および出力デバイスへのアクセス、ハードウェアへのアクセスなどを管理する" というようなことを書いたと思います。その百科事典を実際に見たことはなく、私が提出した元の原稿も歴史の中に失われてしまいましたが、これだけは確かです。私は、オペレーティング システムにソリティアやタブレット入力システム、およびビデオ トランスコーダが含まれていると書いた覚えはありません。
コンピューティングがますます複雑になるにつれ、オペレーティング システムでもさらに多くの機能がサポートされるようになっています。さらに問題はややこしくなり、OEM が独自の追加ソフトウェア一式を含めることもよくあります。このような追加ソフトウェアは、若干役立つものからまったく役立たないものまで、さまざまです。また、これらのソフトウェアによって提供される機能が、コア オペレーティング システムに組み込まれている機能と重複することもあります。
たとえば、Windows Server 2008 Enterprise Edition の既定のインストールでは、5 GB を超えるディスク領域が使用されます。Windows Vista Ultimate Edition には、58,000 個を超えるファイルが含まれており、これらの合計容量は 10 GB を超えます。また、オペレーティング システムを構成するファイルの他にも、構成設定などの数千個のファイルがあり、さらにデーモンやサービスもあります。
これらの一部またはすべてがオペレーティング システムを構成しています。"オペレーティング システム" は、すべてのファイル、すべての構成設定、およびすべてのサービスを含む総称です。これらのファイルや構成設定によって作成されるすべてのランタイム オブジェクト (セマフォ、名前付きパイプ、RPC エンドポイント) も含まれます。システム時刻などの非常に抽象的な構造体や、イベント ログの内容などの特定の種類に分類されるデータも、オペレーティング システムの一部と見なされます。
オペレーティング システムの成長と進化の過程を考えると、これらのファイルのいずれかを変更することがコンピュータの信頼性を低下させると本当に言えるでしょうか。単純に考えると、答えはノーです。たとえば、Windows Vista に付属している edlin.exe を例に考えてみましょう。これは MS-DOS で使用されていた、旧式のライン エディタです。絶対とは言えませんが、Windows Vista がリリースされてから、このオペレーティング システムのすべてのインストール済みコピーの中で、edlin.exe が呼び出されたのは 2 回のみです。グランデ サイズのトリプル ショット モカを賭けてもいいでしょう。その 2 回はどちらも、私がこのファイルの構文を思い出そうとした、約 3 分前に実行されました。だれも使用しない edlin.exe やその他のファイルを変更したからといって、それが本当にコンピュータがもはや自分のものではなくなることを意味するのでしょうか。
edlin.exe がオペレーティング システムの一部であることは明らかですが、そのファイルをだれも実行しなければ、ファイルを変更してもコンピュータは攻撃を受けないのではないでしょうか。もちろん攻撃は受けません。オペレーティング システムでまったく使用されない部分を変更しても、コンピュータは攻撃を受けません。また、オペレーティング システムでまったく使用されない部分は数多くあります。
ただし、複雑に考えると、先ほどの質問の答えはイエスになります。単純にだれかがファイルを実行したかどうかという事実から、コンピュータが攻撃を受けるかどうかを判断することはできません。問題はもう少し複雑です。edlin.exe のアクセス制御リスト (ACL) を見てみましょう (図 2 参照)。
図 2 非常に制限が厳しい edlin.exe の ACL (画像をクリックすると拡大表示されます)
edlin.exe の ACL では、非常に厳しい制限が適用されます。この実行可能ファイルを変更する権限が与えられているのは、TrustedInstaller サービスのみです。これは非常に重要なことであり、コンピュータ上でこのファイルを変更する悪意のある人物に間接的な影響が与えられます。edlin.exe が変更されると、それはもう持ち主のコンピュータではなくなります。ここで鍵となるのは、悪意のあるユーザーが edlin.exe を変更できるという事実です。悪意のあるユーザーは、このファイルを変更できればどのファイルでも変更できるので、持ち主はコンピュータ上のどのファイルも信頼できなくなります。
オペレーティング システムは自分自身を保護します。サービスは不正な変更から保護されます。構成設定も不正な変更から保護されます。ディスク上のファイルも不正な変更から保護されます。オペレーティング システムによって使用されるセマフォや RPC エンドポイントも不正な変更から保護されます。攻撃者は、これらの保護されたオブジェクトのいずれかを変更できれば、すべてのオブジェクトを変更でき、おそらく既にいくつかの変更を完了しています。
このことは重要です。いくつかの鉄則にもありますが、何かを行うことでコンピュータが攻撃を受けるのではなく、だれかが何かを行うことが "できる" かどうかが重要なのです。この点を見落としてはいけません。コンピュータ セキュリティのあらゆる側面において、実際に行われる操作よりも、その操作を行うことができるという事実の方がはるかに重要であることを覚えておいてください。
コンピュータがインターネットに接続されており、何か月も修正プログラムを適用していない場合、まだそのコンピュータを信頼できるでしょうか。できませんね。そのコンピュータは攻撃を受けていると見なす必要があります。攻撃を受けている可能性があるシステムの構成要素はすべて信頼できません (5 年前に執筆した、technet.microsoft.com/library/cc512587 で公開されている「ハッキングされたらどうするか」でも同じことを書きました)。高度なスキルを持つ攻撃者を相手にした場合、システムが攻撃されていても、それを示す兆候が一切現れない可能性があります。つまり、システムが完全に正常であるように見える場合があるということです。
当然、鉄則 2 は今日でも有効です。攻撃者がコンピュータ上で保護されているオブジェクトを変更できる場合、それはもはや持ち主のコンピュータではありません。重要なのはそれらのオブジェクトが実際に攻撃を受けたかどうかではなく、それらのオブジェクトを変更できるかどうかであることを忘れないでください。
鉄則 3: 悪意のある攻撃者があなたのコンピュータに対して物理的なアクセスを無制限に行える場合、もはやそれはあなたのコンピュータではない
2000 年当時、この鉄則は重要でした。多くの人々は、システムに物理的にアクセスできることによって何が可能になるかを十分に理解していませんでした。実際、十分な知識を持っている必要がある政府機関も、この基本的なポイントを理解していない場合がありました。当時のセキュリティ ガイダンスでは、[Allow shut down without logon] (ログオンなしでのシャットダウンを許可する) オプションを無効に設定することが推奨されていました。このオプションを有効に設定すると、ログオン画面の [シャットダウン] ボタンがグレー表示されます。このオプションが実装された背景には、どのユーザーがシステムをシャットダウンしたかに関する監査記録がないので、ユーザーがコンピュータをシャットダウンするときにはまずログオンする必要があるという理論がありました。
欠陥のある考え方に関する事例研究として考えてみましょう。ログオン画面の [シャットダウン] ボタンにアクセスするには、実際にコンソールの前に座る必要があります。そして、コンソールの前に座っていれば、本当にコンピュータの電源を切りたくなったときに、コンピュータの前面に付いている大きな丸いボタンを使用するか、最悪の場合は電源コードを抜けば、システムの電源は切れます。監査記録は残りません。
Windows 2000 には、[Allow undock without logon] (ログオンなしの装着解除を許可する) というセキュリティ設定がありました。このオプションはまだ Windows Vista で提供されています (図 3 参照)。原理は同じで、ドッキング ステーションからラップトップを取り外すには、まずシステムにログオンする必要があります。
図 3 装着したまま盗まれることに対処できないオプション (画像をクリックすると拡大表示されます)
この設定がセキュリティにもたらす実際の価値は、非常にあいまいです。この設定の背景には、だれでもラップトップのある場所まで歩いていって、そのラップトップの装着を解除できれば、簡単にそのコンピュータを盗むことができるという理論があったと思います。私がラップトップを盗むと言っているわけではなく、そうしようと思えば、この保護対策によって阻止されることなく盗むことができると言っているのです。おそらく、単純にラップトップとドッキング ステーションを 1 つのセットとして一緒に持ち去るでしょう。ネットワーク ケーブルと電源コードも盗んでいくでしょうね。無意味なセキュリティ強化とはまさにこのことです。
Petter Nordahl-Hagen が作成した Offline NT Password & Registry Editor は、物理的なアクセスに関する議論の核心を突きました。彼が作成したのは、NTFS ボリュームへの読み取りおよび書き込みアクセスを可能にする、実験に基づいて作成された NTFS ファイル システム ドライバを含む単純な Linux ブート ディスクです。このブート ディスク上のソフトウェアは、ローカル コンピュータのレジストリをマウントし、Administrator アカウントの新しいパスワードをソフトウェア資産管理 (SAM) ハイブに書き込みます。必要なのは、システムへの物理的なアクセスと、1、2 分の時間のみでした。
このようなツールこそが、最初に鉄則 3 が考案された理由です。実際に、Nordahl-Hagen のツールは多くのデモで使用されました。残念ながら、大部分の観衆には、このポイントがうまく伝わりませんでした。私も個人的にいくつかのデモでこのツールを使用しましたが、「このようなツールを知っているユーザーがいないことをどのようにして確認すればよいですか」、「この問題を解決するためにマイクロソフトが実施している対策を教えてください」といった質問に疲れてしまったので、使用することを止めました。IT 業界に属する驚くほど多くの人々が、物理的なアクセスがどのような対策でも打ち破ってしまうことを受け入れたり、理解しようとしませんでした。
物理的なアクセスが可能な環境では、鉄則 3 が非常に重要なメッセージとなりますが、批評家はこれを容赦なく批判しました。この鉄則は、マイクロソフトが物理的なアクセスに関するあらゆる問題の解決を放棄するための試みであるとして愚弄されました。実際、鉄則 3 は、Offline NT Password & Registry Editor によるハッキングなどの脆弱性の報告を退けるために使用されたことが何回かあります。ただし、物理的にアクセスできる攻撃者からシステムを保護する方法は、本当に 1 つしかありません。それは、確実にどの構成要素にもアクセスできないようにすることです。
この点は、鉄則 3 という鎧の弱点となる可能性があります。10 の鉄則が公開されてから、ディスク全体を暗号化するテクノロジが適切な解決策となりました。ハード ディスク全体の暗号化、より正確に言えばフル ボリューム暗号化を使用すると、ボリューム (他のオペレーティング システムではパーティションとして知られています) 全体を暗号化できます。そこで、ブート ボリューム (つまり、オペレーティング システムが格納されているボリューム) 全体を暗号化した場合でも、鉄則 3 は有効であるかという疑問が浮かび上がります。
この答えはおそらく今後変わることはありません。まず、復号化キーを別の場所に保存する必要があります。最も単純なキーの保存場所は、BitLocker の既定の選択肢でもある、コンピュータのトラステッド プラットフォーム モジュール チップです。この操作を行った場合、コンピュータは自動的に起動します。一度コンピュータが起動すると、コンピュータをいつでも物理的に制御できる、機知に富んだ資金豊富な攻撃者であれば、さまざまな方法を使用してそのコンピュータを攻撃できます。コンピュータが任意のネットワークに接続される可能性もあるので、ネットワーク関連の方法によってシステムが攻撃されることも考えられます。
たとえば、攻撃者は USB フラッシュ ドライブなどのダイレクト メモリ アクセス (DMA) デバイスを使用して、メモリからの読み取りやメモリへの書き込みを行う場合があります。コンピュータが一度起動すれば、物理的にそのコンピュータにアクセスできる攻撃者に関しては、すべての防御策が意味を成さなくなります。
復号化キーがコンピュータ自体に格納されていない場合、そのコンピュータが攻撃を受けるかどうかは、攻撃者がそれらのキーを入手または推測できるかどうかによって決まります。コンピュータの起動に PIN コードが使用される場合、そのコードを推測するために攻撃者が行う作業は比較的少なくて済みます。復号化キーが、USB フラッシュ ドライブやワンタイム パスワード フォブなどの別のハードウェア デバイスに保存されていたり、そのデバイスから抽出されたりする場合、攻撃者はそのデバイスにアクセスできる必要があります。これらのキーを入手する方法もあれば、キーにアクセスできるユーザーに大きなデメリットを与える方法もあるので、コンピュータの起動にかなり複雑な作業が必要になる可能性があります。
鉄則 3 を少し異なる見方で、"攻撃者が物理的にコンピュータにアクセスできる場合、そのコンピュータは盗まれた可能性があるので、戻ってくることは考えにくい" と解釈することもできます。その観点から考えると、それはもはや持ち主のコンピュータではありません。また、コンピュータ上のデータにアクセスできるかどうかは、攻撃者にとって問題にならない場合があります。ただし、これは厳密に言うと、鉄則 3 の精神に反しています。この鉄則は、攻撃者がコンピュータ自体だけではなく、そのコンピュータ上のデータにもアクセスできることを前提としています。
総合的に考えて、鉄則 3 はまだ有効であると言えます。今日提供されている特定のテクノロジは、物理的なアクセスを利用する攻撃者からの保護に非常に役立ち、その結果、保護対策が実装されたコンピュータ上のデータにアクセスできる攻撃者の数が最小限に抑えられています。とはいえ、実際に攻撃を成功させる攻撃者の数は、常に攻撃者の能力によって決まります。また、新しいテクノロジが、10 の鉄則の多くにある程度まで対処しています。ただし依然として、システムに物理的にアクセスできれば、(今までよりも複雑な作業が必要になりますが) そのシステムに侵入できます。
これまでのところ、セキュリティに関する 10 の鉄則は、技術の進歩と時間の流れに対して、優れた柔軟性を見せています。最初の 3 つの中では、鉄則 3 が最もその立場を追われる可能性がありますが、これが適用される状況もまだあります。また、これは最も利用しやすい堅牢な緩和策を提供する鉄則でもあります。TechNet Magazine の次回とその次の回でも、このトピックについて取り上げ、鉄則 4 ～ 10 がまだ有効であるかを判断します。

Jesper M. Johansson は、セキュリティ ソフトウェアの開発に取り組むソフトウェア アーキテクトで、TechNet Magazine の編集にも携わっています。管理情報システムの博士号を持ち、セキュリティ分野で 20 年以上の経験があります。また、エンタープライズ セキュリティの Microsoft Most Valuable Professional (MVP) でもあります。最新の著書には、『Windows Server 2008 Security Resource Kit』があります。


フィールド ノート High-Capacity Color Bar Code
Gavin Jancke

バー コードはだれもがよく知っており、注目されることはほとんどありません。日常生活の中で本当によく目にするもので、食品のパッケージから出荷ラベルまで至るところに付いています。1974 年に小売業界で登場した最初の 1D バー コードは、さまざまな幅の縦棒で構成され、12 桁の数字が格納されていました。コンピュータの性能が向上するにつれて、バー コードは進化しました。80 年代後半には白黒の 2D バー コード (マトリックス コード) が開発され、ほんの数桁だったデータ容量が数百バイトにまで増加しました。
2003 年に、私は Microsoft Research のプロジェクトとして、偽造を防止する生態認証カードの作成に着手しました。このカードには、氏名や年齢などの暗号化テキストだけでなく、指紋や虹彩スキャンのテンプレートも保存する必要がありました。既存の白黒のバー コードはその ID カード自体に入らないサイズだったので、必要なすべてのデータを保存するには、明らかに新しいアプローチが必要でした。
白黒の 2D バー コードの標準では、記号ごとに 1 ビットの情報を格納していましたが、このプロジェクトでは、記号ごとに 2 ビット以上の情報を格納する方法を見つけ出す必要がありました。これについては、白黒以外の色を使用することで、格納するデータの量を 2 ビットまたは 3 ビットに増やすことができました。2 ビットのデータでは 4 色、3 ビットのデータでは 8 色を使用します。
また、記号の形をいくつか試して、どの形を使用すれば、それらが緻密に組み合わされ、スキャン時に登録内容を損なうことがないかを確認しました。最初は、六角形がかなり見込みがあるように思えましたが、六角形は混ざり合ってしまうため、コンピュータがそれらを正確に認識できませんでした。
最終的に、記号の形は三角形に落ち着きました。三角形は、圧縮された空間でうまく組み合わされ、さらにそれぞれの ID がはっきり区別できる形として保持されるからです。複数の色の三角形を組み合わせて使用することで、密度を 3D に上げることができました。
このプロジェクトでは、多くの可変要素に対処する必要がありました。色の扱いに関する最も大きな課題の 1 つは、さまざまな印刷性能と光の状態が存在することでした。色は人間 (少なくとも色覚障害を持っていない人) の目では簡単に識別できるかもしれませんが、コンピュータはその違いをそれほど明確に識別できません。
ソフトウェアによる正確な色の読み取りが可能であることを確認するために、いくつかの異なるアプローチを使用しました。アプローチの 1 つとして、ほぼ見分けることができない非常に小さなパレットをバー コードの中に作成しました。このパレットには、実際のバー コード内に存在する基本色が含まれています。このアプローチによって、特定の赤などの構成要素を厳密に指定できる調整メカニズムが提供されました。また、色空間理論を利用して色をグループに分類する、カスタマイズされた簡易型の色クラスタ アルゴリズムなどの高度な技法も試しました。どちらのアプローチも同じくらい適切に機能し、お互いを補完しました。
このプロジェクトの目標の 1 つは、携帯電話でのバー コードの読み取りを実現するプログラムを記述することでした。携帯電話の場合、光不足や、ピントの合わない単焦点レンズについて考慮する必要がありました。さらなる課題は、このコンピュータの画像を携帯電話の CPU (整数ベースの比較的速度が遅いもの) ですべて読み取ることだったので、チームはできるだけ少ない数のピクセルにアクセスしてイメージ内のバー コードを検出する方法について、確固とした理論を見つけ出す必要がありました。スキャンは、十分な光があってピントが合う LCD パネルから、光が足りずピントが合わない物理的な印刷物まで、さまざまな読み取り品質に対して適切に機能する必要がありました。
最終的なアルゴリズムでは、実際のフレーム レート (200 Mhz の CPU で約 10 ミリ秒) より高速な、リアルタイムのカメラ ビデオ フレームでバー コード イメージを解読します。イメージ内で、最小のデータ ペイロードとして使用でき、さらにバー コードを検出できる最小ピクセル数は、約 45 ピクセルです。
さまざまな条件下でこの作業をすべて行いましたが、改良に 2 年以上かかりました。最近、このテクノロジのライセンスがサードパーティに付与されました。今年の後半には、このテクノロジを利用したすばらしいアプリケーションが登場することでしょう。
Gavin Jancke は Microsoft Research でエンジニアリングの責任者を務めており、先進開発グループ チームと Web エクスペリエンス チームを管理しています。以前は、プロダクト サポート エンジニアや SQL Server のソフトウェア エンジニアとして勤務し、Bill Gates の技術諮問スタッフも務めました。


Windows 秘話 効率よりも苦労を
Raymond Chen

ソフトウェア開発者にとって、Windows エラー報告を使用する大きなメリットの 1 つは、プログラムでどのようにエラーが発生したのかについての実情報を入手できることです。このようなエラー報告は、winqual.microsoft.com にオンライン登録したすべてのソフトウェア ベンダに公開されています。ラボを使用してさまざまな種類のテストを実行することは可能ですが、ラボの条件と実環境の条件が同じになることはありません。この差異により、ラボで行ったテストで発生しなかったバグが実環境で発生して、顧客を怒らせる事態を招くことがあります。
数年前、あるプログラマから次のような話を聞きました。彼は、開発に携わっている製品の信頼性チームから作業を依頼されました。このチームは、特定のコンポーネントがクラッシュしたり、ハングしたりする主要原因に対応する必要がありました。何度か話し合いを重ねた結果、彼とこのチームは、このような障害を半数に削減するという目標を掲げることに合意しました。Windows エラー報告で収集された、そのコンポーネントの少なくとも 50% のクラッシュやハングの原因になるバグを修正するつもりでした。
ご存じのとおり、エラーの発生頻度はエラーによって異なります。めったに発生しないものもあれば、よく発生するものもあり、(相対的に言うと) 非常によく発生するものもあります。エンジニアリングでは、さまざまなものを天秤に掛ける必要があります。時間、お金、知力という限られたリソースを与えられ、最大の効果を得られるところにリソースを割り当てる必要があります。ここではクラッシュとハングの数を減らすことを目標としていたので、Windows エラー報告で報告された最も一般的なエラーを調査し、根本的な原因を特定して、このような一般的なエラーに対応することが、堅実なアプローチでした。
Windows エラー報告では実環境で発生したプログラム エラー情報が提供される (画像をクリックすると拡大表示されます)
このプログラマがエラー報告のデータを詳しく調査したところ、ある 5 種類のクラッシュとハングがエラー報告の 60% 以上を占めていることがわかりました。この 5 つのエラーの原因となっているバグを修正することができたら、目標とする 50% を大幅に上回る 40% までクラッシュとハングの数を減らすことができます。
マイクロソフトが独自に Windows エラー報告データを分析した結果によると、Windows のクラッシュとハングの経験則は、「バグの 20% がエラーの 80% の原因である」というパレート原理を見事に反映したものであることがわかりました。また、「たった 1% のバグが 50% のエラーの原因になっている」という驚くべき事実も判明しました。すべてのバグが同じように発生しているわけではありませんが、発生頻度にこれほど開きがあるのことには、とても驚きました。
この 5 つのエラーについて調査を進めたところ、このプログラマは、すべてのエラーの根本的な原因が同じであることに気が付きました。これらのクラッシュやハングは、同じバグが違う形で現れていただけでした。ですから、品質保証チームと協力して、このバグの修正方法を考案してテストし、次の修正プログラムに含める作業に取り掛かりました。1 つのバグの修正で、このコンポーネントの理論上のエラー発生率は即座に 40% にまで落ちました。こうして、彼の任務は 1 つの非常に簡単なコードの修正で完了しました。
この話を聞いたとき、そのコンポーネントのエラー分布曲線の勾配が Windows のものよりも急であったことに驚きました。つまり、すべてのクラッシュとハングの半数以上が 1 つのバグが原因で発生していたということです。このようにコードを明確に理解することは、Windows エラー報告のようなものによって集められたデータなしでは、成し得なかったでしょう。
信頼性チームがこのように非常に短時間で目標を達成したことに有頂天になると思われるかもしれません。何しろ、取り決めた目標は、1 つの修正を行うことでたったの 2 週間で達成されたのですから。しかし、信頼性チームは激怒しました。
「これは 2 か月かかるはずだったのに、こんなに早く終わるなんて受け入れられません。簡単すぎたみたいですね。」どうやら信頼性チームは、このプログラマが、効率的に作業を進めるのではなく、もっと苦労することを望んでいたようです。
Raymond Chen は自分の Web サイト「The Old New Thing」および同じタイトルの書籍で、Windows の歴史と Win32 プログラミングについて扱っています。彼が持っている服の 20% が、彼の洗濯物の 80% の原因となっています。