デスクトップ仮想化が誕生する以前、DR計画ではエンドポイントデバイスについては最低限しか考慮されなかった。多くの場合、IT部門は、ベンダーが必要に応じて新しいデスクトップを提供できると考えていた。デスクトップには必ずしも業務データが保存されているわけではなかった。そのため、管理者がバックエンドのリソースに注力していたのは無理もないことだ。

　VDIによって状況は一変した。企業がVDIを完全に導入すると、ユーザーは仮想デスクトップ以外の場所から仕事に必要なツールへアクセスできなくなった。そのため企業は、大規模な災害が発生した後に、仮想デスクトップをすぐに稼働できる状態にするDR計画を保持する必要に迫られている。

　災害発生後に仮想デスクトップをすぐに利用できるようにする方法は1つではない。それぞれの方法にはメリットとデメリットがある。また、選択する方法によって実装の難易度やコストも異なる。だが、全ての企業で使える万能な方法はない。そのため、VDIのDRを行う方法を複数調べることをお勧めする。

デスクトップのHyper-V

　1つ目の方法は、あまり一般的に使用されていない。だが、この方法を使用している企業が少なくとも1社存在することは知っている。現在、その企業は仮想デスクトップを米Microsoftの「Hyper-V」でホストしている。そして、仮想デスクトップのバックアップコピーを安全にクラウドに保管している。

　この企業は、ハードウェアベンダーと大規模な災害発生時についてある契約を交わしている。それは、この企業が災害から完全に復旧するまで、ベンダーがデスクトップPCをリースするという内容だった。契約に基づいて、これらのデスクトップPCではMicrosoftの「Windows 8」が実行され、Hyper-Vがインストールされていた。仮想デスクトップのコピーを各PCにプッシュして、ユーザーがHyper-Vを使用して仮想デスクトップを利用できるようにするというのが同社の計画だ。

　この計画を大企業で実現する場合、その作業量は非現実的なほど膨大になるだろう。だが、小さな企業なら有効な選択肢となるであろう。この方法なら、バックエンドインフラに依存することなく、仮想デスクトップを稼働させることができる。

　実質的な唯一の要件は、仮想デスクトップにIPアドレスを割り当てることができるDHCPサーバだ。上述の企業は、この要件に対応するためにワイヤレスルータを使用していた。このルータはデスクトップPCにネットワーク接続とIPアドレスを提供している。

Windows To Go

　もう1つの緊急時の対策は「Windows To Go」を活用することだ。この機能は「Windows 8」で導入された機能である。この機能を使用すると、USBフラッシュドライブからWindowsを起動できる。

　この計画を採用した企業では、災害が発生する前に多数のUSBフラッシュドライブを作成した。これらのUSBフラッシュドライブは、セキュリティが確保されたオフサイトの施設に保存され、災害発生時にはユーザーに配布される。ユーザーはUSBフラッシュドライブから個人所有のPCを起動し、完全な環境がプロビジョニングされた会社のデスクトップにアクセスすることが可能だ。

　残念ながら、Windows 7を運用している企業ではWindows To Goを使用することはできない。だが、Windows To Goの代わりにVHDからブートをすることは可能だ。

　どちらの場合も、USBフラッシュドライブの容量が仮想デスクトップのイメージのサイズを制限することになる。多数のアプリケーションをインストールしてプロビジョニングされたデスクトップは、USBフラッシュドライブで使用するのには適さないかもしれない。

　この方法にはもう1つデメリットがある。それは、この方法が真の効果を発揮するには、USBフラッシュドライブを事前に作成しなければならないことだ。仮想デスクトップのイメージが頻繁に変更されない場合は、大した問題にならないだろう。だが、仮想デスクトップのイメージを定期的に更新する企業にとっては、非実用的な方法になる。

ストレージレプリケーション

　VDIの災害復旧で一般的な方法の1つは、複数のデータセンターをまたぐか、クラウドまで拡張された環境を構築する作業を伴う。その方法は、ベンダーによって大きく異なる。安定性は最も高いが最も高額な選択肢となることが多い。

　基本的に複数のデータセンターをまたぐという概念は、仮想デスクトップが保存されているホストクラスタの範囲を広げて、複数のデータセンターをまたぐようにすることだ。VHDの保存に使用されるストレージデバイスは、別の場所に複製される。こうすると、仮想デスクトップのコピーが2つの場所に保存されることになる。

　理論的には仮想デスクトップをセカンダリデータセンターにフェイルオーバーさせることは可能だ。だが、セカンダリデータセンターに、全く別の仮想デスクトップのプールを作成する方が効率的かもしれない。ただし、別の場所で仮想デスクトップをホストするには、ネットワーク要件の変更が必要になる。

　既存の仮想デスクトップをオフサイトの場所で機能するように再構成するよりも、別の場所で使用するためにプロビジョニングされた仮想デスクトップにユーザーを接続した方が簡単な場合もある。

オフライン仮想デスクトップ

　米VMwareは、モバイルユーザーが仮想デスクトップをチェックアウトしてオフラインで使用できる機能を提供している。理論的には、この機能を災害への備えとして使用することは可能だ。ただし、ハリケーンが接近しているなど、差し迫った災害に関する情報が事前に得られる場合に限られる。

　この方法を使用するデメリットは明確だ。1つは、災害発生後に実装するのは簡単ではない可能性が高いこと。もう1つは、この機能がVMwareの環境でしか使えないことである。

　VDIを導入している企業は、事業継続計画（BCP）の範囲内で仮想デスクトップの問題に対処しなければならない。バックエンドサーバのリソースに接続できる仮想デスクトップをユーザーが持っていなければ、災害発生後にバックエンドサーバのリソースをオンライン状態に復旧しても、あまりメリットはないだろう。