VMwareおよびHyper-V のバックアップで陥りやすい５つの落とし穴 Greg Shields著 Microsoft社MVP兼VMware vExpert VMwareおよびHyper-Vのバックアップで陥りやすい５つの落とし穴仮想マシンの保護について考えるとき、最初に思い浮かぶことは何だろうか。おそらく、多くのIT担当者にとって、真っ先に思い付くのは、高可用性（high availability, HA）技術だろう。主な仮想プラットフォームベンダーは、独自の形でHAを提供しているが、各社の戦術は異なっていても、その結果は実質的に同じである。つまり、万一仮想ホストが故障した場合、VMが保護される。図1 VMを保護するHA技術 VMwareのvMotionやマイクロソフトのLive MigrationなどのHA技術（図1 を参照）は、近年、マスコミで盛んに取り上げられている。その理由の1つは、これらの技術が解決する実世界の問題である。HAアクティビティを簡素化するための技術も優れていることは間違いない。ほとんどの仮想ホストの障害が明らかにリカバリ可能であることがわかっているので、多くの仮想管理者は、VMが安全だと信じ、夜間はぐっすり眠ることができる。しかし、HA技術は、特定の状況でVMを保護するためには非常に有用であるが、どんな状況でもVMを保護することはできない。HAはホスト障害に対して保護することができ、一部のアプリケーション障害に対しても多少は保護できる。しかし、結局のところ、HAは • データ損失に対して何もしない。 • データの破損に対して何もしない。 • 災害復旧のために何もしない。 2 VMwareおよびHyper-Vのバックアップで陥りやすい５つの落とし穴 VMの故障を引き起こすさまざまな理由実際、HA技術が保護できるシナリオは、VMの故障を引き起こすあらゆる原因に比べればほんのわずかである。少し考えただけでもさまざまな原因が思い浮かび、安心して眠れていた夜は再び落ち着かない夜になるだろう。VMが故障する原因としては、次のものが考えられる。 • データの消失または削除 • アプリケーションオブジェクトの消失または削除 • OSの消失、削除、または破損 • VMオブジェクトの偶発的な削除 • レイヤー間の通信エラーによって生じる破損 • ユーザーのミス • 管理者のミス • 水上データセンターの火災封じ込めシステム（ヒント: これらは不適切である) • その他多数の人災または自然災害 VMを故障させる可能性があるこれらの原因のいくつかは、滑稽に思えるかもしれない。しかし、これらを挙げたのは、VMの動作に対する脅威が内外を問わずいかに多種多様に存在しているかを理解してもらうためである。上記に考えられる故障を列挙したのには、特に注目に値するもう1つの理由がある。VMの中味、すなわちOS、アプリケーション、ファイルだけを保護するのではなく、VM自体の特性の定義も保護するように注意する必要がある。これを仮想プラットフォーム内のVMのオブジェクトと考えることができ、レジストリのエントリまたは VMの属性、およびMoRef ID（instanceUUIDともいう）が含まれる。 VMware vSphere内またはMicrosoft Hyper-V内のいずれを問わず、VMが正しく動作するには、仮想プラットフォームでOSとVMオブジェクトの両方が機能している必要がある。どちらか一方を失えば、VMは動作しない。これは当たり前にように思うかもしれないが、多くのバックアップツールは、仮想化を意識して設計されていない。このような従来型ツールは、VMを構成するファイルを保護することに注意を集中し、プラットフォーム内のVMのメタデータには全く注意を払っていない。不十分なバックアップではフェイルセーフな VMを望むことはできない長年使用してきた同じ古いツールをVMのバックアップにも使用しているとすれば、このような問題を経験したことがあるかもしれない。そのようなツールは、物理コンピュータには十分役立つが、仮想プラットフォームの場合は、一部しか可視化できないので、まったく新しい問題が発生する。 VMを停止させる理由を列挙した長いリストのせいで既に夜眠れなくなっているかもしれないが、不十分なバックアップソリューションが役に立たないことを考え始めたら、そんな不眠症はたいしたことではなくなる。すぐに思い浮かぶのは、次の5 つである。 3 VMwareおよびHyper-Vのバックアップで陥りやすい５つの落とし穴 • データセンターレイヤー全体でデータをキャプチャできない。VMを構成するファイルは、ほんの一部にすぎない。これらのファイルは、サーバーハードウェア、オペレーティングシステム、管理ツールなどの数多くの仮想化されたデータセンタースタックの1つのレイヤーにすぎない。あるレイヤー内のVMのハードディスクは、別のレイヤーの仮想ディスクとして表現され、それ自身がハイパーバイザーまたはストレージデバイスによって異なって処理される可能性がある。仮想化対応のバックアップツールは、データが正しくキャプチャされるように、各レイヤーの影響を認識しなければならない。 • バックアップの整合性を検証できない。検証可能で適切なバックアップを入手できなければ、バックアップがないのも同然である。多くのバックアップツールは、バックアップの整合性を検証できることを示唆しているが、バックアップのデータセットだけでなく、その検証が、バックアップ内部のオペレーティングシステムやアプリケーションに対しても発生する必要があることを認識しておかなければならない。 • 静止化またはVSSができない。仮想化に留意して設計されたバックアップソリューションには、各仮想環境レイヤー全体にわたって静止化状態を監視する追加の監視機能が組み込まれていなければならない。このためには、仮想プラットフォームツール（VMware ToolsまたはHyper-V Integration Components）を確保するだけでなく、Windowsボリュームシャドウコピーサービス（VSS）フレームワークの複雑な動作が適切に活用されなければならない。 • 常が発生したことを通知できない。ほとんどのバックアップツールは、問題が異発生したことを通知できるが、その通知を本当に受け取っているだろうか。受け取っていなければ、収集しているデータが有効なデータではないことはわからない。 • Mの有機的成長を説明できない。最後に、 V そして仮想環境にとって最も重要なことは、バックアップツールを仮想プラットフォームの管理ソリューションにエクスポーズする機能である。仮想化プラットフォームを意識するだけで、仮想マシンを有機的に作成および使用停止するときに適切なVMをキャプチャすることができる。フェイルセーフなVM保護のための5つのヒント確かに、これらは、ITの中で、これまでは一度設定すれば後は任せておけばよかったアクティビティなので、大きな問題になる可能性がある。本能的な反応は、「自分で新しい解決方法を手に入れる」ことである。しかし、必ずしもそうとは言えない場合がある。実際、仮想化向けに構築されたバックアップソリューションは適切な提案であるが、以下の5つのヒントは、状況をさらに一歩前進させるものである。これらは、長年にわたる経験を持つ複数のエキスパートから収集した勧告に基づいて、その解決策を使用して実際にミスを回避できる最善の方法について堅実な助言を与える。危険を覚悟で、これら5つのヒントを無視してもよい。これらは、今日の仮想環境でデータ保護の失敗を招く最も一般的な怠慢の一部に対処するものである。 4 VMwareおよびHyper-Vのバックアップで陥りやすい５つの落とし穴ヒント1: レイヤーを意識するデータセンターレイヤーのことである。前述の通り、仮想化は、VMとそのバックアップストレージを分離するために、両者の間に多数のレイヤーを追加する。実際、分離の数が多いほど、有効である。VMはハイパーバイザーと対話し、ハイパーバイザーはホストサーバーとのインターフェイスを司り、ホストサーバーがVM用のストレージリソースに接続する。これらのレイヤー間の相互作用は、仮想化によってデータセンターに最適なアクティビティが実現されるのを可能にするが、複雑になるため、障害を引き起こす設計ミスの原因となる場合がある。このような設計は誤って、運用データ（VMのディスクファイルなど）と同一の物理ストレージ上にあるバックアップデータをひとまとめにしてしまう。これは、テープバックアップ媒体をディスクベースのバックアップに移行した結果として発生する場合が多い。バックアップデータを、運用VMによって使用されるストレージとは異なる物理ストレージに格納するのがベストプラクティスであるのは言うまでもない。このように分離すれば、運用ストレージの障害がバックアップの消失につながることはない。フェイルセーフ: バックアップストレージとプライマリVMストレージを分離する。ヒント2: バックアップをテストしない自分でテストせず、他の人に頼む。わかりやく言えば、テストには自動化ツールを利用する。バックアップを毎日テストすることを考えると、自動化した方が、コストがかからない。また、重要なアクティビティについては、人間よりも自動化ツールの方が、信頼性が高い。バックアップソリューションを検討するときに重要なのは、ソリューションがサポートできる自動化テストの種類を考慮に入れることである。今日の大半のディスクベースのバックアップツールは、バックアップされた仮想ディスクファイルに対して基本的なデータ整合検証を実行するが、それよりもはるかに重要なことは、バックアップされたVMのアプリケーション、オペレーティングシステム、および仮想化オブジェクト（属性など）が正しくキャプチャされたかどうかを確認する追加チェックである。ディスクベースのバックアップに移行すると、バックアップをさまざまな方法でテストする機能が向上する。テープと異なり、ディスクベースのバックアップは、アクセス性が高い。つまり、ディスクシステムは常にオンライン状態で、ランダムI/Oが可能である。バックアップ用のストレージが、運用ストレージと同じレベルで実行するとは限らないが、ディスクベースのバックアップは、簡単にアクセスして、VMレベル、OSレベル、およびアプリケーションレベルの検証を実行することができる。これらは、Active Directory、Exchangeデータストア、Windows OS、およびSQLデータベースが正常であるかどうかを検証することと同様のチェックである。フェイルセーフ: バックアップには、各バックアップで自動的に発生する総合的な整合性検証機能を組み込む。ヒント3: 静止化状態をプロアクティブに監視する静止化状態のプロアクティブな監視は、VMのバックアップで最も重要な点の1つである。本書ではすでに、仮想化がバックアップアクティビティを複雑化することについて説明した。その結果、バックアップ時の静止化は、データを正確にキャプチャする上で非常に重要なプロセスになる。 5 VMwareおよびHyper-Vのバックアップで陥りやすい５つの落とし穴 Windows環境では、ほとんどのデータ保護ツールは、Windowsボリュームシャドウコピーサービスとの組み合わせで、ツール独自のコンポーネントを活用する。図2で示す通り、このサービスでは、VSSライター、VSSリクエスタ、およびVSS プロバイダの3つの異なる要素を注意深く調整することが必要である。図2: WindowsのバックアップにおけるVSSの役割 Windows環境では、ほとんどのデータ保護ツールは、Windowsボリュームシャドウコピーサービスとの組み合わせで、ツール独自のコンポーネントを活用する。図2で示す通り、このサービスでは、VSSライター、VSSリクエスタ、およびVSS プロバイダの3つの異なる要素を注意深く調整することが必要である。この編成の中で、VSSリクエスタのアクティビティは、通常、バックアップアクティブティを管理するバックアップツールによって処理され、VSSプロバイダと連携してストレージにアクセスし、VSSライターにインストール済みアプリケーションと同期するように指示する。物理コンピュータでは、これらの3つのアクティビティが一致協力して、バックアップを実行する。この3つのいずれかで障害が発生すると、バックアップは完了できず、悪くすれば、バックアップは復元不可能なデータを収集することになる。ソフトウェアまたはハードウェアコンポーネントはVSSフレームワークを共同で利用してバックアップを実行し、VSSが正常な機能を継続できるようにすることが必要不可欠である。物理コンピュータの代わりに仮想マシンを使用する場合、VSSに関するベンダー間の調整はさらに困難になる。図3は、vSphere（左側）またはHyper-V（右側）環境で VSSを使用する場合、3つの要素から成るVSS編成がいかに複雑になるかを示している。vSphereのVSSでは、VSSとVMのインストール済みVMware Toolsの間で調整が必要になる。Hyper-VのVSSでは、仮想ホストのHyper-V VSSライターと各VM内のVSSライターの間で調整のための追加レイヤーが必要になる。 VSSリクエスタはさらに、VSS対応アプリケーションのログ排除処理など、アプリケーションがバックアッププロセスの一部として適切に保守する必要がある。これは、VMのデータ保護を成功させるための重要なコンポーネントの1つである。VSS は、実際、これらすべての相互接続を処理するように設計されているが、仮想環境でもVSSが正常に機能できるようにすること、またVMとそのアプリケーションにも適切に対応することが、ファイルセーフ保護の必要不可欠な要件になる。 6 VMwareおよびHyper-Vのバックアップで陥りやすい５つの落とし穴フェイルセーフ: VSSを使用して適切なアプローチを実行する: 信頼できるが、必ず検証する。ヒント4: 成功を可視化する必要があるこれは最も当たり前に思われることであるが、本書のために情報を提供してくれた専門家チームは、これが、実際には最も忘れられがちな点であると述べている。ヒント4は、非常に単純である。ほとんどのバックアップツールには、バックアップの成功と失敗を通知するためのアラート機能が組み込まれている。電子メールやSNMP アラートなどの簡単なものを使用して、管理者に通知し続ける。これらを有効にする。現行ツールのアラート機能についてはじっくり吟味する必要がある。これらの機能が、成功したバックアップと失敗したバックアップのどちらに対しても有効であるかを確認しなければならない。データ保護が機能しているという肯定的な検証結果は、成功を示す最も重要な指標である。フェイルセーフ: 人が監視するよりも効果的なモニタ機能を使用する。ヒント5: 新しいVMのためのバックアップジョブを新たに追加しないこの冗談がわからなければ、ヒント2を確認するとよい。仮想環境に必要なバックアップツールは、有機的成長を経験している動的な仮想環境をサポートするように設計されたツールである。有機的成長とは、仮想環境（特にプライベートクラウドなどの管理された環境）で発生しがちなVMの絶え間ない作成と使用停止を意味する。簡単に言えば、仮想環境またはプライベートクラウド環境では、自分が新しいVMの作成者ではない可能性がある。作成者ではなく、その保護に対しても責任がない場合、どうすれば、新しく作成されたVMがバックアップスケジュールを必要とするかを知ることができるだろうか。正解は、VMを常に注意深く監視していなければ、または仮想プラットフォーム対応のバックアップツールを使用しなければ、知ることはできない。vSphereおよび Hyper-Vのどちらの場合も、これらのプラットフォームに完全に対応したバックアップツールは、有機的なVMの成長に対応することができる。また、VMのオブジェクトだけでなく、その内容も保護することができる。同的な仮想環境では、VMのあらゆる部分に全面的にフォーカスするには、自動化が必要であり、それは、フェイルセーフなVM保護を確保するために絶対的に必要なものである。フェイルセーフ: バックアップツールが、単なるVMのリストだけでなく、仮想プラットフォームの構成要素（データセンター、フォルダ、クラスタ、その他のオブジェクト）別にバックアップできるようにする。最後にこのように、HAだけがすべてでない。VMのワークロードを保護するには、さまざまなアクティビティが必要であり、それらのアクティビティはさまざまなソリューションを必要とする可能性がある。これまで使用してきた古いバックアップツールの移行を検討中であるか、または VMプラットフォーム専用に構築された最新のバックアップツールに既に移行しているかどうかに関係なく、以上の5つのヒントは、VMのためのフェイルセーフなアプローチを始めるきっかけになるだろう。 7 VMwareおよびHyper-Vのバックアップで陥りやすい５つの落とし穴著者について Greg Shields氏は、Concentrated Technology社の共同経営者兼主席技術者で、Microsoft社のMVP兼VMware vExpertも務めている。また、フリーとして執筆や講演、ITコンサルティングでも活躍している。15年以上にわたり情報技術に携わってきた著者は、システム管理、エンジニアリングおよびアーキテクチャについて豊富な経験を積んでいる。 Veeam Softwareについて Veeam® Softwareは、VMware vSphereおよびMicrosoft Hyper-Vを管理するための革新的なソフトウェアを開発しており、VMware Technology Alliance Partner プログラムのエリート・パートナーおよびマイクロソフト認定ゴールドパートナーとしての認定を取得しています。Veeam Backup & Replication™は、高度な Virtualization-Powered Data Protection™を提供するNo.1のVMバックアップソリューションです。Veeam ONE™は、仮想環境のための強力で使いやすく、手頃な価格のリアルタイムモニタリング、ドキュメンテーション、および管理レポート作成機能を提供します。Veeam nworksは、エンタープライズモニタリングをVMwareにまで拡張するもので、Veeam nworks Management Pack™ for Microsoft System CenterとVeeam nworks Smart Plug-in™ for HP Operations Managerがあります。Veeamは、仮想化コミュニティの活動的なメンバーとして、Backup Academy、四半期ごとのV-index、年1回のVirtualization Data Protection Reportを主催しており、多数の業界イベントにも参加しています。詳細については、www.veeam. com/jp/をご覧ください。 8