Veeam がいよいよ、2 つの仮想化プラットフォームに的を絞り始めたので、自分のラボ環境に Microsoft Hyper-V を導入する方法を考えなければならない時期がやってきたと思い、VMware 仮想マシンで Hyper-V を実行できるかどうか知りたいと思いました。Veeam は、例えば、VMware Workstation にネストされたラップトップで稼働するポータブル ラボを使用することにより、ソリューションの提供に大きな成功を収めています。多くの場合、単一のラップトップで、ネストされた ESX サーバー、vCenter、DC、および Veeam アプリケーションを稼働させているので、Hyper-V もその中に含めることができるかどうか知りたいと思いました。

「この記事は、ハウツー ガイドとして、VMware Workstation 8 または ESXi 5 のいずれかで Hyper-V 仮想マシンを実行するためのプロセスをステップ順に説明しています。」

私は長い間、そんなことは不可能だと聞かされていましたが、数か月前、ESXi 5 が発表されれば可能になるという噂を小耳にはさみました。また、Intel Nehalem または Intel Core i7 で稼働する ESXi 5 では、ネストされたハイパーバイザーにさらに 64 ビットの仮想マシンをネストできるということも聞きました。このため、まず、新しいラップトップにしたら、この Intel アーキテクチャ、または同等の AMD をシステムに導入して、それを確認してみることにしました。イベントで使用する予定のアーキテクチャと同じアーキテクチャを持つラボ環境も何とか構築できました。

http://www.vcritical.com/2011/07/vmware-vsphere-can-virtualize-itself/#comment-12442
http://www.virtuallyghetto.com/2011/07/how-to-enable-support-for-nested-64bit.html

やっと試すチャンスがやってきたときには、ESXi は GAステータスに達していました。上記のブログを読んでわかったことは、すばらしい助言はあるが、その指示に従うと、数人が報告しているように、画面はただ真っ黒なままでした。追加の情報を提供したにもかかわらず、何の回答もありません。そこで、別の方法を試してみることにしました。ESXi 5 の代わりに VMware Workstation 8 をインストールすることにしたのです。ネストされた Hyper-V 仮想マシンはやっと稼働するようになりました。このときわかったことは、私が使用しているハードウェアは、ネストする Hyper-V と互換性があるということです。上記のブログ記事では、Hyper-V を稼働させる鍵となるのは、Intel EPT と呼ばれる CPU/BIOS 内の機能であると書かれていました。また、Nehalem/Core i7 があれば、Intel EPT を使用できると書かれていました。ただし、このブログ記事には、BIOS を通じて Intel EPT を有効にする必要があると書かれていました。しかし、私のいずれのシステム BIOS にも、このオプションがありません。

そこで、私は、どうすればうまくいくかをテストしている最中に、スタンドアロンの Hyper-V 製品をインストールする代わりに、Windows 2008 R2 Standard を使用して、Hyper-V をロールとして有効にすることにしました。ただ楽をするためにやったことでしたが、スタンドアロンの Hyper-V 製品もオプションとして問題なく使用できます。

VMware Workstation 8 での Hyper-V 仮想マシンのネスティング

ここで、VMware Workstation 8 で稼働するMicrosoft Hyper-V 仮想マシン（VM）を作成するための手順を以下に示しますが、その後で、VM をESXi 5 で作成する場合の手順も示します。

1. バージョン8 のハードウェアで新しい VM を作成します。
2. 4 GB の RAM および2 x ｖCPU と、Hyper-V の下にネストしたい VM の数に応じて約 80～100 GB のディスク領域を確保します。
3. 多くのインストール ガイドでは、ゲスト OS として VMware ESX オプションを選択するように指示されていますが、それはやめてください。代わりに、Windows 2008 R2 x64 を選択します。
4. 完了したら、Hyper-V 仮想ネットワークとして使用される別の NIC を VM に追加します。
5. [仮想マシン] > [設定]> [プロセッサ] をクリックして、Intel VT-x/EPT 機能を通過するためのオプションをチェックします。
6. VM が Windows 2008 R2 x64 のメディア ISO から起動するように設定します。
7. VM を起動する前に、config ファイル .vmx を編集し、次のパラメーターを追加する必要があります。 hypervisor.cpuid.v0 = “FALSE”
8. 起動し、Windows 2008 R2 x64 をインストールします。
9. インストールが完了したら、サーバー マネージャを開いて、[ロールの追加] をクリックします。
10. [Hyper-V] オプションを選択して、インストールします。この時点で、システムが正常に機能しているかどうか、Intel EPT 機能を通過するかを確認します。そうでなければ、先に進むことはできません。
11. 仮想ネットワークに使用するネットワーク アダプターも選択する必要があります。
12. ここで、Hyper-V をインストールします。再起動が必要です。
13. インストールが完了したら、 サーバー マネージャを開き、Hyper-V までドリルダウンして、ローカル サーバーに接続します。
14. 最後に、VM を作成し、インストールします。完了したら、VM を通常どおり使用できるようになります。ただし、速度は遅くなります。

ESXi 5 での Hyper-V仮想マシンのネスティング

ESXi 5 の場合、一部の手順は VMware の場合と同じですが、同じ作業でも多少面倒になります。

1. まず、ESXi 5 のテック サポート モードにある /etc/vmware/config ファイルに入力する必要があります。私は、vSphere Client のセキュリティ プロファイルを使用して SSH を有効にした後、PuTTY SSHを使用して ESXi システムに入りました。
2. そこから、ネストされたハイパーバイザーを許可するために必要な次のコマンドを実行しました。
   

   # echo 'vhv.allow = "TRUE" ' >> /etc/vmware/config

   コマンドラインでの一重引用符および二重引用符の使用に注意してください。

3. 次に、バージョン 8 のハードウェア、4 GB（または使用可能な空き領域）、2 x vCPU、2 以上のvNIC、および 100 GB の仮想ディスクを使用して仮想マシン（VM）を作成します。
4. 仮想マシンの設定に戻り、[オプション] > [CPU/MMU 仮想化] をクリックして、Intel VT-x/EPT 機能を通過するためのオプションをチェックします。

   コマンドラインを使用してこの 2 行を追加するには、SSH に戻り、Hyper-V の VM をインストールするディレクトリに変更します。

   # echo 'vhv.allow = "TRUE" ' >> /etc/vmware/config

   この例では、config ファイルの名前を Hyper-V.vmx にしました。次のコマンドを入力します。

   # echo 'monitor.virtual_exec = "hardware" ' >> Hyper-V.vmx
   # echo 'hypervisor.cpuid.v0 = "FALSE" ' >> Hyper-V.vmx

5. 仮想マシンの設定に戻り、[オプション] > [CPU/MMU 仮想化] をクリックして、Intel VT-x/EPT 機能を通過するためのオプションをチェックします。
6. 次に [オプション] 領域の [CPUID マスク]で、[詳細] をクリックします。
7. 次の CPU マスク レベル ECXを追加します。---- ---- ---- ---- ---- ---- --H- ----
8. Hyper-V または Windows 2008 R2 をインストールし、Hyper-V のロールを有効にします。
9. 以上で、準備が完了しました。

ヒント

最後に、途中で失敗しないために、Ricky からのヒントをいくつか紹介します。

• システムに OS として Microsoft Hyper-V をインストールした後、再起動が必要です。Hyper-V をインストールした後に再起動すると、ブルー画面になりますが、慌てることはありません。Hyper-V を実際に使用する際にはブルー画面になりません。
• サーバーとラップトップの両方で、システムが Intel EPT 対応の場合、VMware が問題なく Intel EPT を通過するかどうか、および Hyper-V が Intel EPT を見つけるかどうかを確認できるかどうかはわかりません。私の場合、最初に VMware Workstation を試したときに、それがすぐにうまくいったのでわかりました。この問題についてはいろいろ調べましたが、直感としては、Nehalem または Core i7 と Intel VT をサポートするマザーボードを見つけることだと思います。それが賢明でしょう。Intel VT –x2 が必要だとありますが、私は使用していないので（必要だとも思いません）、これは誤解を生みます。ただし、正確な情報を入手できたときには、この投稿を更新します。
• ハイパーバイザーのネスティングは、実行速度が非常に遅くなることを意味しますが、SSD ディスク上のデータストアにネストされたハイパーバイザーをインストールすると、大いに役立ちます。
• 上記の 2 件のブログは、バージョン 4/7 のハードウェアまたはバージョン 8 のハードウェアを使用して VM を作成するための 2 通りの方法について説明しています。私は最初にバージョン 8 のハードウェアを使用しましたが、まったく機能せず、画面はただ真っ黒なままでした。そこで、両方の方法を組み合わせて微調整してみると、無事に機能しました。
• ネストされた Hyper-V マシンが常駐するポート グループは、無作為モードを「同意」に設定する必要があります。
• 一方のブログには、GUI を使用しないで、config ファイルに手動で入力する方が安定性が高いという注意事項が記されています。私もそう思いました。私が、Putty を使用してシェル セッションで config ファイルを変更したのは、そのためです。
• ESXi 5 または VMware Workstation 8 に Hyper-V 仮想マシンをインストールするためのヒントをお持ちではありませんか。ぜひ下記にコメントをお寄せください。

今日は、Update 2の一般公開というVeeam Availability Suite v8（Veeam Backup & ReplicationとVeeam ONEを組み合わせたソリューション）にとって重要な節目の日です。両方の製品が更新されたので、このブログでは、最も重要な機能、すなわちvSphere 6の完全サポート、Veeam ONEの更新、およびVeeam Endpoint Backup FREEのサポートについて知っておかなければならない点について紹介します。

VeeamがvSphere 6を完全にサポート！

以前にvSphere 6 Support is coming soonというタイトルのブログ記事を書いたときに、vSphere 6がまもなくサポートされることを早くお伝えしたいと考えていました。それ以来、QCは、リリース候補のビルドのvSphere 6 RTMコードに対する標準の拡張ストレス テストを精力的にこなし、ついにUpdate 2を一般公開する運びとなりました。

いつもの通り、基本的な互換性だけに甘んじることなく、次の機能や拡張機能を追加することにより、vSphere 6を完全にサポートできるようにしました。現時点で、これらの機能の大半は、他のベンダーから入手することができません。

• VMware Virtual Volumes（VVols）とVMware Virtual SAN 2.0のサポート
• Storage Policy Based Management（SPBM）ポリシーのバックアップとリストア
• フォールト トレラント（Fault Tolerant, FT）VMのバックアップとレプリケーションのサポート
• vSphere 6タグの統合
• Cross-vCenter vMotionの認識
• VVolsへのクイック マイグレーション
• SATA仮想ディスクのホットアド トランスポート モード

ここにリストした機能についてもう少し詳しく説明することにしましょう。VVols、VMware Virtual SAN 2.0およびSATA仮想ディスクのホットアド トランスポート モードは、新しい仮想ディスク開発キット（VDDK）バージョンを使用するだけで簡単に利用できるようになりますが、言及すべき重要な点は、Luca Dell’Oca氏が説明している通り、Veeamの仮想SANのサポートは依然として最先端であるということです。EVO:RAILソリューションおよびEVO:RACKソリューションは、VMware Virtual SANに基づいて構築されているので、このスマートな処理モードは、これらソリューションにとって最も効率的な可用性技術を提供することに留意してください。各ホスト上に仮想Veeamプロキシを立てるだけです。

VMwareのこれらの次世代ストレージ技術を調べると、将来的にStorage Policy-Based Management（SPBM）がvSphere内のVMストレージ要件を管理する方法になることがおわかりいただけるでしょう。Veeamでは、VMポリシーのバックアップとリストアをサポートするので、VMのフル リストア時にVMストレージ ポリシーをリストアすることでき、手動プロセスが削減されます。これは、リカバリ時間に直接影響します。「ポリシーから外れる」VMは、リストアされるVM自体または同じストレージを共有する他のVMの可用性に影響を与える可能性があるため、SPBMポリシーのリストアは重要な機能です。既定では、バックアップされたVMと同一のポリシーがリストアされますが、当然、別の場所にリストアする場合は、必要なポリシーを選択することができます。

Storage Policy-Based Management restores ensure the restored VM gets the same policy, or a new one, it had before the backup.

vSphere 6のサポートの中で私が最も興味深いと思う機能は、Veeam Backup & Replicationでフォールト トレラントVMのバックアップが可能になったことです。数多くのフォールト トレランスの拡張機能のうち、vSphere 6には、APIによりフォールト トレラントVMのスナップショットを採取する機能が組み込まれています（実際には、この種のVMでは、この方法でしかスナップショットを作成することができません）。その機能のおかげで、Veeam Backup & Replicationは、他のVMとまったく同様にフォールト トレラントVMのバックアップとレプリケーションを実行できるようになりました。この機能とvSphere 6に組み込まれた他のフォールト トレランスの拡張機能を組み合わせることで、データセンターでフォールト トレランスを使用する際の残りの障壁が取り除かれ、真の意味で最先端のデータセンターの可用性を最大限に高めることができます。

vSphere 6は、vSphereタグのプログラムによるアクセスと管理を行うための新しいAPIも提供します。リソースの最適化のためにインフラストラクチャを組み合わせる場合、タグは、バックアップ ポリシーを設定するのに実に有効な方法です。Veeamでは既に、vSphere 5タグをサポートしていますが（Luca Dell’Oca氏も、自身のブログでこのサポートについて説明しています）、vSphere 6タグをサポートすることにより、アップグレードした後でも、この非常にフレキシブルでインフラストラクチャ中心のフレームワークに関する高度なバックアップ ポリシーを引き続き構築することができます。

vSphere 6のサポートで重要なもう1つの機能は、ｖCenterを越えたvMotionです。私が記憶している限りでは、Veeam Backup & Replicationは、複数のvCenter Serverシステム間でのVMの保護をサポートしていますが、この新しいVMware機能を追加する上で問題となるのは、VMを別のvCenterに移行すると、VM固有のオブジェクトIDが変更されて、ジョブが明示的に追加されたVMを「見失う」ことです。ｖCenterを越えたvMotionのサポートがクイック マイグレーション機能に追加されたことにより、VMを別のvCenter Serverに移行する場合、バックアップ ジョブまたはレプリケーション ジョブ上の関連付られたエントリは自動的に更新されるので、可用性の要件は引き続き満たされます。

vSphere 6のサポートの中で私が説明しておきたい最後の重要な機能は、VVolへのクイック マイグレーションを実行できるようになったことです。クイック マイグレーションは、Veeam Backup Free Editionにも含まれている機能で、（ネットワーク リンクが信頼できない又は速度が遅い、vMotionがサポートされていない、または対応するVMwareのライセンスがないなどの理由で）vMotionの使用を選択できない場合にVMを移行するための有効な方法です。この機能は、最新のvSphere 6機能を使用して最初から構築された新しいクラスタへの完全なマイグレーションを実行するのにも役立ち、古いクラスタ固有の設計上の問題は一切生じません。

Veeamにとって、vSphere 6の完全なサポートとは、その新機能をフルに活用できること、そしてお客様が、必要とする可用性レベルを維持したまま、データセンターで最新のVMware技術を安心して実行できるようにすることの両方を意味します。Veeamがサポートを早急に宣言せずに、常に数週間もかけて、最終的なプラットフォーム コードに対するプレリリース コードの拡張テストを行うのか疑問に思われるかもしれません。それは、バックアップ（そして、データの保護と可用性）だからです。急いで結果を出すことはできません。早まれば、新たなリスクを生むだけです。次に示すフォーラム スレッドでは、このプロセスの背景についてもう少し詳細に説明しています。Veeamフォーラムの週間ダイジェストを読むか、TwitterでGostevをフォローすると、Gostev氏が、vSphere 6でダイレクトSANアクセス トランスポートの大きなバグが検出されたことについて言及しています。

Gostev tells it like it is.

vSphereは、メジャー リリースのたびに、それまでのリリースと比べて多くの変更が行われます。Veeamが、更新されたすべてのvSphereコンポーネントの新バージョンについて信頼性をテストし、それらがVeeamのソリューションとの間でどのように相互作用するかを確認するのに時間をかけたいと考えるのは、このためです。この理由のために、これまで何年間も、Veeamは、新しいvSphereのリリースのサポートを公表するまで一定の期間を置いてきました（平均でGAから約6週間）。そして、多くの場合、これは大きな成果をもたらします。vSphere 6のVDDK リリース ノートの最新バージョンを読むと、Gotev氏が言及している前述の状況が、運用環境に影響を与える可能性があるので、認識されている最大の問題点として追加されていることがわかります。でも、心配しないでください。Veeamは、VMwareが修正プログラムを提供するまで、Update 2でこのVDDKの問題を修正するためのパッチを適用しているので、（競合他社のソリューションを使用するユーザーとは異なり）SANトランスポートを使用するVeeamユーザーは安心して、vSphere 6にアップグレードすることができます。

言及しておかなければならないもう1つの重要な点は、vSphere 6のサポートを追加しても、広く使用され、VMwareで依然としてサポートされているvSphereの古いバージョンのサポートも維持されるということです。つまり、Update 2でもvSphere 4.0以上がサポートされます。Veeamフォーラムでは、プラットフォームのサポートに関するVeeamの計画とお客様の計画について明確に説明しています。2015年末までにお客様が導入を計画しているバージョンについて今年初めに実施したアンケート結果のフォーラム記事をご覧になったことがありますか。このアンケート結果は、R&Dチームがお客様のご意見を参考にして、サポートする機能やプラットフォームの優先順位を決定するのに役立ちました。次に示すように、回答されたユーザーの多くは（このブログ記事を書いた時点では45%）、2015年末までにvSphere 6の稼働を予定されていますが、Veeamは、自社の要件のために最後の「太った」ESXバージョンをそのまま使用することを選択されたユーザーを途中で放り出すことはできません。

Veeam Endpoint Backup FREEのサポート

間違いなく、Veeamが最近発表した素晴らしい新製品の1つは、Veeam Endpoint Backup FREEです。Update 2では、バックアップをVeeam Backup & Replicationコンソール内で確認できるようになりました。さらに、私は個人的に最も魅力的な機能だと思っていますが、エンドポイントのバックアップをVeeamリポジトリに格納することも可能になりました。これは、データセンター内にクリティカルなエンドポイント デバイスを保有しているか、または仮想化されていないシステムがいくつか残っている組織にとって非常に喜ばしいニュースです。

Update 2を適用したBackup & Replication v8システムのビューと、エンドポイントのバックアップ パーミッションをリポジトリに割り当てる機能を以下に示します。

エンドポイントのサポートには、バックアップされた物理ディスクの内容を様々な仮想ディスク フォーマットにエクスポートする機能、ファイルやアプリケーション アイテムのリストアを実行する機能、およびBackup CopyジョブとBackup to Tapジョブを使用してエンドポイントのバックアップをオフサイトに格納する機能も含まれます。Backup & Replicationの有料版はすべて、Update 2によるエンドポイントのバックアップを受け取ることができます。まだEndpoint Backup FREEをお試しになっていなければ、お試しいただくことを強くお勧めします。エンドポイントのバックアップはシンプルで無料でなければなりません。Veeam Endpoint Backup FREEは、その期待を裏切ることはありません。

Veeam ONE v8 Update 2

Veeam ONE Update 2も入手できるようになりました。これも重要な設定を提供します。Veeam ONEの製品マネージャーであるVitaliy Safarov氏と話をしたときに、私は、今回のアップデートで最も気に入っている機能は何かを彼に質問しました。彼が選んだのは、VVOLsを含めて、vSphere 6のすべての機能を監視するためのサポートでした。可視性がなければ、サポートしなければならない重要な技術を実行することはできないので、vSphere 6の新機能を詳細に表示できることは非常に重要です。Veeam ONEでは、途中で驚くことがないように、必要な情報を表示して、この新しいストレージ プラクティスを実行することができます。

アップデートして使ってみよう！

Veeam Backup & Replication 8.0とVeeam ONE 8.0のUpdate 2に関する参考資料を以下にリストします。また、これらを十分に理解するのに最適なのが、ラスベガスで開催されるVeeamON 2015です。このイベントでは、最新の可用性戦略に重点を置いて、今年予定している拡張内容について説明します。また、新製品および既存の製品についても詳細に説明します。Update 2に関して今すぐ入手できる資料を以下にリストします。

Veeam Endpoint Backup FREE

Veeam Backup & Replication 8.0 Update 2のリリース ノート

Veeam ONE 8.0 Update 2のリリース ノート

VMware vSphere 6の新機能:展開のヒントとアップグレードのベスト プラクティス

Update 2のダウンロード (Veeam Backup & ReplicatioとVeeam ONE)

VeeamON 2015

誰もが抱いている疑問は、「Veeamが次に統合するのは、どのアレイなのか」ということです。Veeamは、このたび、Veeam Availability Suite v9とEMCストレージとの統合を発表することになりました。

この発表は、実際には2つの異なるアレイ ファミリと考えられる多数の構成が含まれるので、重要な出来事だと言えます。EMC VNXとEMC VNXeの両方のアレイ ファミリがサポートされます。さらに、この統合は、ストレージ スナップショット向けVeeam Explorerのリカバリ技術とストレージ スナップショットからのバックアップ機能の両方が含まれるので、非常に強力なものとなります。

ストレージ スナップショットを活用すると、競合他社製品よりも最大20倍までの速い速度でストレージ スナップショットからバックアップを採取できるので、Availability for the Modern Data Centerを実現するには、この方法を選択するのが自然の成り行きです。ストレージ スナップショットからのバックアップと、(Veeam Backup Free Editionに組み込まれている) ストレージ スナップショット向けVeeam Explorerのリストア機能およびデータ センターを組み合わせれば、体制は万全です。

今日の発表は重要な出来事ですが、この発表に至るまでのプロセスを大まかに説明することも同じように重要です。Veeamは、時々、Veeam Forumsで投票を行います。このフォーラムで、“what do you use for primary storage?”またはより最近のものでは、“what version of vSphere do you plan to use by the end of this year?”という質問に対する投票を見たことがあると思いますが、これらは、次の計画に役立つ情報となります。フォーラム、特にこれらの投票結果は、製品管理チームにそのまま送られ、チームでは、お客様からの直接的な意見を十分に検討します。このニーズの把握は、Veeamの将来的な方針を決定する上で非常に重要なことです。ただし、この決定に影響を与える要因は他にもあります。実際、我々はしばしば、Veeam Availability Suiteで次にサポートされるアレイは何かという質問に回答しなければなりません。このプロセスには、3つの指針があることをお話ししたいと思います。

1. アレイには優れたスナップショット エンジンが必要である。簡単に言えば、品質の劣るスナップショット エンジンを基に優れた可用性機能を構築する必要はありません。
2. 市場において十分なシェアを獲得する必要がある。私たちは、使えるソリューションを市場に提供したいと考えています。どんなに優れた技術を構築しても誰も使用しなければ意味がありません。
3. ストレージ ベンダーの協力が必要である。これはビジネス上の試みであり、Veeamは、ストレージとの統合用のストレージ プラグインを開発するために資源を投入しますが、この優れた技術を推進するには、ベンダーの関与が必要です。

それではここで、この優れた技術がEMCストレージとどのように連携するかを見てみることにしましょう。まず、ストレージ スナップショット用Veeam Explorerについて説明しましょう。これがVeeam Backup Free Editionに組み込まれているという事実など、多くの理由から、私は、この機能をとても気に入っています。この統合により、Veeam Backup & Replicationは、VNXアレイおよびVNXeアレイのストレージ スナップショットを読み取ることができます。これは、ストレージ アレイ上のスケジュールを介して、またはVeeam Backup & Replicationのインターフェイス内でセットアップされたスナップショットです。ストレージ スナップショットが作成されたら、それらをブラウズして、強力なリストア オプションを開始することができます。

ストレージ スナップショットをリストアに活用することは実に有用で、最高の目標復旧時間を達成するのに役立ちます。ただし、適切なバックアップを異なるストレージに格納することを推奨します。それは、ストレージ スナップショットからのバックアップを開始する場所です。

ストレージ スナップショットからのバックアップにより、時刻に関係なく、最もビジーなVMさえも含めてどこでもバックアップを採取することができます。ストレージ スナップショットからのバックアップで最初のステップは、アプリケーション認識イメージ処理により、バックアップのためにVMを準備して、VM上でVMwareスナップショットを採取することです。この後、基礎となるストレージ スナップショットが採取され、VMwareスナップショットは直ちに解放されます。面白いのはここからです。Veeamのバックアップ プロキシは、ストレージ スナップショットから直接データを移動します。VMのマウントも、データストアの再署名も必要ありません。ここで、このステップの最も優れた部分は、VMware変更ブロック追跡 (CBT) がVeeamの特許出願中のアプローチによって保持されるという点です。これは、増分バックアップを信じられないほど高速化するのに役立ちます。バックアップが完了すると、ストレージ スナップショットは削除されます。次の図は、ストレージ スナップショットからのバックアップに関わるステップを示しています。

EMCストレージとの統合は、お客様、パートナー各社および見込み客を大満足させることでしょう。Veeam Availability Suite v9は、今年後半にリリースされる予定です。Veeamでは、これまでのメジャー リリースと同様、ベータ版およびプレビューを用意するので、この驚くほど優れた新機能をぜひご自分の目でお確かめください。そのときが来たらVeeam Forumsでお知らせしますが、それまでは、v9リリースの先行通知にサインアップすることができます。

以下に、まもなく登場するこのエキサイティングな新機能の詳細とVeeam Availability Suite v9の詳細に関するリンクをいくつか示します。

Veeam Availability Suite v9のページ

VeeamとEMCストレージとの統合に関する近日開催予定のウェビナー

ストレージ スナップショット用Veeam Explorerの詳細 [currently written to v8 supported arrays]

ストレージ スナップショット用Veeam Explorerの詳細 [currently written to v8 supported arrays]

まもなくリリースされるVeeam® Availability Suite™ v9 には、多数の拡張機能と新機能が組み込まれています。しかし、この新しいリリースで最大の機能拡張の1つは、間違いなく、プライマリ ストレージとバックアップ ストレージの改善でしょう。

Veeamではすでに、ストレージ スナップショット統合でサポートされるストレージ アレイ リストに新しくEMC VNX/VNXeが追加されることを発表しました。しかし、ストレージに関するニュースはこれだけではありません。他にも数多くのニュースがあり、この記事では、その一部について説明します。

これから発表する新機能のうち、最初に挙げる機能は、私が個人的に長い間待ち望んでいたもので、v8で最初のNFSクライアントを統合したときに (NetApp統合の一部として) 実現されるのではないかと思っていました。NFSユーザーは、長い間、仮想化の世界で、少なからず差別を受けているように感じています。バックアップ操作時にVDDK内のNFSストレージに直接アクセスしてデータを読み取ることができないということが、ブロック ストレージのユーザーに「嫉妬する」1つの理由であったことは間違いありません。過去数年間にVMwareバックアップで発生しているNFS固有の問題が解決されても、状況は変わっていません。しかし、v9でついに、Direct SAN処理モードとよく似た機能をNFSにも使用できるようになりました。社内では、この機能をDirect NFSと呼んでいます。これにより、vSphere 6で従来のNFS v3と新しいNFS 4.1の両方がサポートされ、新しいVeeamプロキシはすべて、新しい改善されたNFSクライアントを実行し、VMware vSphereにエクスポーズされるNFS共有に直接アクセスします。NFS共有によって使用可能な単一ファイルの詳細な可視性により、NFSユーザーは、NASアレイから直接VMをバックアップおよびレプリケートすることができ、アクティビティのためにハイパーバイザー レイヤーにまたがる必要がありません。この結果、バックアップは高速化され、運用ワークロードに対する負荷はさらに削減されます。

次に説明する機能はNetApp固有です。v8でNetAppストレージ アレイのサポートを追加したとき、お客様に好評を博した機能の1つは、Veeamの既存のスケジュール機能を使用して、Veeamインターフェイスから直接、NetAppスナップショットのオーケストレーションを行い、SnapMirrorおよびSnapVaultコピーを作成する機能でした。ただし、適切なバックアップを行い、最適な可用性を確保するためにNetAppインフラストラクチャ外部に格納できるのは、プライマリ アレイをソースとして使用する場合に限られます。v9では、NetApp統合にさらに多くの機能が追加され、SnapMirrorおよびSnapVaultからのバックアップが可能になります。これらのNetApp固有の機能を活用することにより、ユーザーは、ローインパクトでストレージベースの (さらに必要に応じて、アプリケーション整合性のある) スナップショットを実行して、これらの復元ポイントを、SnapMirrorまたはSnapVaultを使用するセカンダリNetAppアレイにレプリケートした後、これらのセカンダリ ロケーションから、分離されたバックアップ ストレージに本当の意味でVMをバックアップすることができます。バックアップ操作は、プライマリ ストレージにまったく関係しないので、プライマリ ストレージは最大のパフォーマンスを維持することができます。セカンダリ アレイは、単にコピーの受動的なターゲットであるだけではなく、より有効に使用され、必要なI/Oはすべて、セカンダリ アレイから消費されます。

ストレージ スナップショットについて言えば、最後に説明する機能により、これらがさらに有効に使用されるようになります。これまで、ストレージ スナップショットからのバックアップとVeeam Explorer™ for Storage Snapshotsは、ストレージレベルのスナップショットをバックアップおよびリストアに使用することができました。しかし、Veeamが実行できるジョブの種類は、これらだけではありません。例えば、仮想ラボを考えてください。これは、現在、バックアップからしかVMを実行することができません。仮想ラボは、ほとんどのユース ケースに必要不可欠ですが、On-Demand Sandbox™のユース ケースではパフォーマンスに制限があります。これを解決するために、v9では、On-Demand Sandbox for Storage Snapshotsを導入します。サポートされるアレイ (VMware vSphere上で実行されるHP、NetAppおよびEMC) で既存のストレージ スナップショットを使用することにより、テストやトラブルシューティングのために、数回のクリックだけで、運用環境のコピーを、完全に分離された場所に作成することができます。この技術のユース ケースは数多くありますが、ここでは、1つだけ取り上げます。つまり、わずか数分で、開発者向けに、複数VMの環境を新しく作成し、迅速なストレージ スナップショットを利用して、その環境を文字通り複数回クローン化して、異なるテスト環境を実現し、それらをフルI/Oパフォーマンスで稼働させることができるとすればどうでしょうか。また、最初にバックアップすることなく、これをストレージ アレイから直接実行できることを想像してみてください。もちろん、この新しい機能のユース ケースは、お客様によってそれぞれ異なります。

以上で、今回のストレージ関連のお知らせを終わります。この記事と、EMCストレージ アレイとの統合に関する前回の記事で、すべてのストレージ拡張機能が説明されたとお考えであれば、申し訳ありませんが、これは簡単な広告のようなもので、v9では、ここで説明しきれないほどのさまざまな機能が提供されます。

しかしながら、一日で、これだけのストレージ関連のニュースをお届けすれば十分ではないでしょうか。

変更を行う前に、仮想マシンのポイント·イン·タイム·コピーをすぐに作成する必要があるとしたら、どうしますか。通常、間違いなくスナップショットを取得します。このような場合、確かにスナップショットは有効なソリューションです。数秒で取得することができ、しかも問題が発生した場合には、仮想マシンを以前の状態にすぐに戻すことができます。しかし、スナップショットは同時に、多くの場合、悪影響ももたらします。まず、テストの実行中、スナップショット自体のサイズが増大します。仮想マシンのI/Oのパフォーマンスが劣化するだけでなく、データストアのスペースも過剰に消費されるようになり、さらに、何らかの理由でスナップショットを放置しておくと、深刻な問題が発生することもあります。最後に、大きなスナップショットは、スナップショットのコミット中に過度のデータストアI/OやVMのスタンが発生して、運用ワークロードの可用性に影響を与える可能性もあります。

テスト目的では、Veeam Virtual Labsの機能を使用することを強くお勧めします。ただし、これにより、仮想マシンの保護コピーを素早く作成する必要がなくなるというわけではありません。バックアップは、実行時間の点で、スナップショットとは比べものにならず、しかも日常業務では、例えばVeeamZIPにより保護コピーが作成されるまで、数分はもちろん数時間も待っているわけにはいきません。さらに、その仮想マシンを保存するジョブに多数のVMsが含まれていれば、増分バックアップを実行することさえできません。つまり、1つの仮想マシンを保護するためだけに、すべての仮想マシンのスナップショットを作成し、保存しなければなりません。

一方、Quick Backupは、まさしくこれらの制限を解消するように設計されています。

以下では、Quick Backupが動作する仕組みについて説明します。Quick Backupを開始すると、Veeam Backup & Replicationは、仮想マシンが保存されるバックアップ ファイルに、そのVMだけが保存されるか、または他のVMと一緒に保存されるかに関係なく、そのカタログを検索して、当該仮想マシンの1つ以上の復元ポイントがあるかどうかを確認します。少なくとも1つの利用可能な復元ポイントがあれば、その復元ポイントをQuick Backupの開始点として使用することができます。Quick Backupは、ジョブ内に保存されている可能性のあるすべての仮想マシンのうち、新しいバックアップを作成したい1つまたは複数のVMの増分バックアップを作成します。仮想マシンが複数のバックアップジョブによって保護されている場合には、最新の復元ポイントを含むジョブが選択されます。したがって、結果的に、名前が示す通り、本当に高速のバックアップ操作が実行されます。

Quick Backupによって作成される増分バックアップには、選択された仮想マシンの変更されたブロックのみが含まれます。既存のジョブの設定が使用されるので、作成先のフォルダーやその他のパラメーターについて質問されることはありません。またコマンドが呼び出された後、新しい増分バックアップ ファイルは、そのバックアップ ジョブに使用されるバックアップ レポジトリ フォルダーと同一のフォルダー内に作成されます。最大の利点は、Quick Backupを実行すると、そのジョブの保持ポリシーに影響がないことです。実行中のQuick Backupは、復元ポイントを新たに作成します。さらに、問題のVMは、対応するジョブの保持ポリシー設定で考慮されません。この復元ポイントは、通常の保持ポリシーの処理の一環として、依存する復元ポイントと共に削除されます。

Quick Backupを呼び出すには、2通りの方法があります。最初の方法は、Veeam Backup & Replicationのコンソールを使用します。

仮想マシンのノードをブラウズして、保護したい仮想マシンを選択した後、右クリックして表示されるコンテキストメニューで、[Quick Backup]を選択します。

Web Clientとの統合

Quick Backupをスナップショットの代わりに使用する場合、スナップショット コマンドと同様に簡単にアクセスできる必要があります。そのため、Quick Backupは、Veeamコンソールにオプションとして表示されるだけでなく、VMware vSphere Web Clientから直接使用することもできます。これにより、スナップショットを使用する場合と同様、すべての保護操作は、非常に迅速かつ簡単に実行できます。vSphere Web Clientと統合されるようにVeeamを設定すると (この設定方法については、『ユーザー ガイド』の対応するセクションを参照してください）、関連するVeeamコマンドをWeb Clientから直接使用することができます。

Quick Backupコマンドを起動すると即座に、前述のバックアップ操作が開始し、右側のWeb Clientタスクパネルで進捗状況を直接追跡することができます。

この間、Veeam Backup & Replicationで最適なバックアップジョブが選択され、Quick Backupのソースとして使用されます。

ただし、vSphere Web Clientをそのまま使い続けることができ、Quick Backupが完了するまでの間、他のアクティビティを実行できます。実際、同じ[Tasks (タスク)]エリアに、バックアップが正常に終了したことが報告されます。

以上で、VMの最新の状態を含む新しい復元ポイントが作成されました。前の状態に戻すために使用できる復元ポイントができたので、安心して、仮想マシンを使用することができます。さらに、この仮想マシン上のアクティビティの持続期間全体で、スナップショットがパフォーマンスを低下させたり、データストア上のディスク スペースを消費したりすることはなく、また、後でコミット問題を生じさせることもありません。まさにWin-Winの状態です！

お客様やパートナー様に最も好評を博した拡張機能の1つは、Veeam Explorerでした。これは、広く使用されているアプリケーションの高速リカバリを提供します。この数年の間で、驚くほど使いやすいVeeam Explorerは、MicrosoftのActive Directory、Exchange、SharePointおよびSQL Serverなどのクリティカルなデータセンター アプリケーションに対応してきました。今年後半にリリースされるv9には、新しくVeeam Explorer for Oracleが追加されます。さらに、既存のVeeam Explorerについても、新たにいくつかの大掛かりな機能強化が図られます。

それではまず、Veeam Explorer for Oracleについてご紹介します。Oracleデータベースは、実際に最先端のデータセンターのバックボーンである最もクリティカルなアプリケーションに頻繁に使用されるという独自の特徴を持っています。Veeam Explorer for Oracleは、次の機能を提供します。

• トランザクションレベルのリカバリ
• トランザクション ログのバックアップと再生

既存のVeeam Explorerでおなじみの機能ですが、Oracleデータベースは、サポートされている他のアプリケーションとは全く異なります。このため、Veeam Explorer for Oracleも、他のVeeam Explorerとは異なります。具体的には、このVeeam Explorerは、Windows VMおよびLinux VMで稼働する両方のOracleをサポートし (拍手するのは最後までお待ちください)、Automatic Storage Management (ASM) と完全な互換性があります。

これらのリカバリ オプションで極めて重要なのは、データ消失シナリオに最適な方法でリカバリを行うことができるという点です。例えば、誰かが、データベースのテーブルに格納されているレコードを削除してしまった場合、VM全体を前日の夜のバックアップに復元することは、この状況から抜け出す最善策ではありません。これは、複数のアプリケーションが、異なるデータベース間でそのデータベース サーバーを使用している可能性がある場合に特に言えます。

では、まずトランザクション ログのバックアップと再生について説明しましょう。これは、追加のリカバリ オプションをVeeam Explorer for Oracleで実現するメカニズムです。Microsoft SQL Serverのサポートと同様、トランザクション ログ ファイルをOracleサーバーからバックアップ リポジトリに移行するサブジョブがあり、これのジョブが、追加のリカバリ オプションをVeeam Explorer for Oracleで使用できるようにします。

イメージレベルのバックアップとトランザクション ログのバックアップは、個々のデータベースを、イメージベースのバックアップの時点、またはログ再生により、特定の時点 (分単位)または特定のトランザクションに復元するために使用できます。これは、インスタントVMリカバリ、ファイルレベルのリカバリなどのVeeam Availability Suiteで使用可能な他のすべてのリカバリ オプションに追加されるオプションであることに注意してください。

Veeamは、MicrosoftのActive Directory、Exchange、SharePointおよびSQL Serverに対応するVeeam Explorerについても大きな機能拡張を図ったことも発表しました。これらの拡張機能のうち、特に注目すべき機能をいくつか紹介しましょう。

Veeam Explorer for Active Directory: きめ細かなリカバリは、v9で一新されます。Active Directory統合DNSレコードに加えて、グループ ポリシー オブジェクト (GPO)も復元できるようになります。これは、消失された、または間違って変更されたオブジェクトの復元で発生する深刻な問題を解決します。しかし、このVeeam Explorerで最も強力な拡張機能は、構成パーティション オブジェクトを復元できるようになったことです。これは、VeeamがActive Directoryのエキスパートの新たな関心を引く機能になることでしょう。

Veeam Explorer for Exchange: v9で、この人気の高いVeeam Explorerは、E-Discovery (電子情報開示) タスクに大いに役立つ2つの機能を特徴とします。1つ目は、詳細なエクスポート レポートです。これには、Veeam Explorer for Exchange内で、何がどこからエクスポートされたか、またどんな検索条件が使用されたかを明確に示されています。このレポートは、管理者に送信することができ、エクスポートされたPSTファイルも含まれます。さらに、Veeam Explorer for Exchangeは、検索クエリのエクスポート サイズを推測できるようになります。これは、一部のユーザーにとっては、多数のメールボックスがファイル システムのようなものなので、特に有用です。エクスポートされる特定のクエリ結果がどのくらいの大きさになるかを知ることができます。

Veeam Explorer for SharePoint: Veeam Explorer for SharePointでは、サイト全体、サイト コレクションおよびリスト、アイテム パーミッションの復元がサポートされるようになります。さらに、Veeam Explorer for SharePointは、復元タスクにリモート ステージングSQL Serverを使用できるようになります。これは、Veeam Explorer for SharePointタスクの一部としてSharePointデータベースを「マウント」するために、Veeam Backup & Replicationサーバー上のローカル データベースは使用されないことを意味します。SharePointデータベースが、Veeam Backup & ReplicationコンソールにインストールされたSQL Server Express環境でデフォルトによりサポートできる大きさよりも大きい場合に役立ちます。

Veeam Explorer for SQL Server: このVeeam Explorerに対して最も要求が多いのは、テーブルレベルのリカバリを組み込むことです。このため、v9では、Veeam Explorer for SQL Serverで実現されるきめ細かなリストアが、データベース内の特定のテーブルにも適用できるようになります。さらに、v9のVeeam Explorer for SQL Serverは、リモート ステージングSQL Serverもサポートします。

どのVeeam Explorerも、復元タスクで最高の柔軟性を発揮して、データセンターのアプリケーションの可用性を最大限にするために、最短の目標復旧時間 (RTO) と目標復旧時点 (RTO) を実現することができます。

以下に、まもなく登場するこのエキサイティングな新機能の詳細とVeeam Availability Suite v9の詳細に関するリンクをいくつか示します。

Veeam Availability Suite v9のページ

どんなシステム管理もバックアップを必要とします。この原則は、どんな仮想環境（VMware、Hyper-V、その他何でも）にも当てはまります。つまり、バックアップは非常に重要だということです。

どんな障害シナリオにも効果的に対処できる永遠のルールの1つは、3-2-1バックアップ ルールです。このアプローチは、「いくつのバックアップファイルを保持すべきか？」、「バックアップファイルをどこに格納すべきか？」という2つの重要な質問に答えるのに役立ちます。

3-2-1バックアップ ルールとは、次のことを意味します。

• データのコピーを少なくとも3つは作成する。
• コピーを2つの異なるメヂアに格納する。
• 1つのバックアップ コピーをオフサイトで保管する。

それでは、これらの鉄則を1つずつ詳細に説明しましょう。

1. データのコピーを少なくとも3つは作成する。

「3つのコピー」とは、プライマリ データ以外に少なくとも2つのバックアップを作成しなければならないという意味です。1つのバックアップだけで十分ではないのはなぜでしょうか。オリジナルデータをデバイス1に保存し、そのバックアップをデバイス2に保存しているとしましょう。両方のデバイスは同じ特性を持ち、統計的にそれぞれの障害は独立しています。例えば、デバイス.1の故障率が1/100であれば、両方のデバイスが同時に故障する確率は、次のようになります。

1/100 * 1/100 = 1/10,000

つまり、プライマリ データをデバイス1に保存し、2つのバックアップをそれぞれデバイス2とデバイス3に保存する場合、3つのデバイスすべてが同時に故障する確率は、次のようになります。

1/100 × 1/100 × 1/100 = 1/1,000,000

これが、データの複数のコピーがあれば、災害が発生してもデータを消失する危険性が低減する理由です。

2. コピーを2つの異なるメヂアに格納する。

上記のセクションでは、データのコピーを保存しているすべてのデバイスには、共通する故障原因がないことを前提としていました。しかし、プライマリ データとそのバックアップﾟを同じ場所に保存すると、この前提は明らかに成立しません。例えば、統計的に、同一のRAIDグループ内のディスクは独立していません。さらに、同じストレージでディスク障害が何度も発生することは珍しくありません。

これが、3-2-1ルールで、少なくとも2種類の異なるストレージにデータのコピーを保存することを提案している理由です。例えば、内蔵ハード ディスク ドライブとリムーバブル ストレージ媒体 (テープ、外付けハード ディスク ドライブ、USBドライブ、SDカード、CD、DVD、またはフロッピー ディスク) に保存するか、または設置場所が異なる2台の内蔵ハード ディスク ドライブに保存します。

3. 1つのバックアップ コピーをオフサイトで保管する。

重要なのは、コピーを物理的に分離することです。外付けストレージ デバイスを運用ストレージと同じ場所に設置するのは、賢明な方法ではありません。万一火災が起これば (そうならないように)、すべてのデータを失うことになります。

中小企業の場合、バックアップファイルをクラウドに保管するのが賢い選択かもしれません。また、オフサイト テープも、あらゆる規模の企業で一般的に採用されている方法です。

3-2-1バックアップルール

3-2-1ルールは、非常に一般なルールであり、あらゆる種類のデータ (個人データと企業データ) 、およびあらゆる種類の環境 (物理環境と仮想環境) に有効です。

VMware/Hyper-V環境に対応するVeeamを使用している場合、このルールは「3-2-1-0バックアップ ルール」になります。0は「エラーなし」を意味します。なぜなら、VeeamのSureBackupがすべてのバックアップの復元可能性を自動的に検証するからです。

Veeam Backup & Replication™は、3-2-1バックアップ ルールのすべての要件を満たすのに役立ちます。

• データのコピーを少なくとも3つは作成する。各VMware/Hyper-V仮想マシンについて複数のバックアップを作成するようにBackup Jobsを設定します。
• コピーを2つの異なるメヂアに格納する。テープ、ディスク、およびクラウドなど、ここにリストした媒体にバックアップを格納することができます。
• 1つのバックアップ コピーをオフサイトで保管する。組み込みWANアクセラレーションを使用して、バックアップをオフサイトにより速く転送するようにBackup Copy Jobs（バックアップコピージョブ）を設定するか、またはVeeam Cloud Connectを使用して、サービス プロバイダーのインフラストラクチャにバックアップを転送ます。

あなたは、ご使用の環境に3-2-1ルールを適用していますか？

バックアップストレージは、最先端のデータセンターの可用性戦略にとって必要不可欠な要素であるため、Veeamでは、Veeam Availability Suite v9に、多数の異なるストレージシステム向けの新しい統合オプションを導入しました。バックアップストレージ用にこのような統合オプションを設けることは、企業がデータ消失を回避するのに直接役立ちます。これらの統合は、多数の重複排除ストレージシステムに適用され、重複排除が必要なのは、多くのデータセンターで増え続けているデータ量に対処するためです。それでは、今回発表したこれらの各統合ポイントについて説明しましょう。

HP StoreOnce Catalystとの統合

HP StoreOnce重複排除システムは、多種多様なデータ管理要件 (例えば、データのアーカイブなど) に見事に適合します。HP StoreOnceは、小規模なROBO向けのHP StoreOnce VSA (仮想ストレージアプライアンス) から大企業向けの物理アプライアンスまで幅広い範囲で使用することができ、Veeamのお客様の間で最も多く選択されているストレージです。VeeamでHP StoreOnce Catalystをサポートすることでシステムとのネイティブ統合が可能になり、数々の利点をもたらします。その結果、バックアップと復元のパフォーマンスを向上し、帯域幅の使用量を削減することができます。詳細については、ここをクリックして、以前のブログ記事を参照してください。

EMC Data Domain Boostサポートの機能拡張

Veeamは、Veeam Backup & Replication v8で、Data Domain Boostを介してバックアップと復元のパフォーマンスを向上するために、EMC Data Domainのネイティブサポートを導入しました。v9では、最新の統合機能であるEMC Data Domain Boost 3.0 SDKを提供します。これにより、DD OS 5.6のサポートが可能になるだけでなく、ソース側の重複排除とWAN (ワイドエリアネットワーク) 上で送信中のデータの暗号化のサポートも可能になり、オフサイトのEMC Data Domain重複排除ストレージシステムへのバックアップの速度と安全性を向上することができます。

重複排除アプライアンスを選ばない、サポートの機能拡張

ExaGrid、QuantumアプライアンスまたはWindows Serverの組み込み重複排除を使用している場合、v9には、誰でも使用できる機能が搭載されています。以下の新機能により、すべての重複排除システムで、多くの改善を実現することができます。

第一に、バックアップリポジトリ設定に新しく設けられた「仮想マシン (VM) ごとのバックアップファイルチェーン」オプションにより、企業は、自社の重複排除ストレージの潜在能力と経験をフルに活用して、バックアップパフォーマンスを最大10倍向上することができます。このオプションを選択すると、このリポジトリに対して書き込みを実行するバックアップジョブは、各VMの復元ポイントを、重複排除が施されたバックアップファイルに保存します。これにより、単一ジョブ内の複数の書き込みストリームを使用することができ、並列処理が可能になります。複数のストリームを使用できることにより、バックアップジョブ全体のパフォーマンスが大幅に向上します。簡単に言うと、ほとんどのエンタープライズレベルのバックアップストレージシステムは、入出力 (I/O) スループットの点で、単一の読み取りまたは書き込みストリームだけで飽和状態になることはありません。また、Veeamの組み込みの重複排除がなくても、ストレージデバイス自体の高度な重複排除がその代わりをするので、実際には何の欠点もありません。したがって、win-winの状態です。VMごとのバックアップファイルを次の図に示します。

さらに、Backup CopyジョブでGrandfather-Father-Son (GFS) による完全バックアップをアクティブにするための新しいオプションにより、ローカルバックアップコピーのパフォーマンスを向上し、重複排除アプライアンスに対する負荷を軽減することができます。このオプションを有効にすると、重複排除アプライアンス上でのデータの再構成 (リハイドレーション) 要件が取り除かれて、代わりに、復元ポイント全体がソースバックアップファイルからコピーされます。これにより、Backup Copyのワークロードは、ランダムからストリーミングに効果的に変換され、実際、Veeamによる重複排除アプライアンスのサポートはすべてのストレージに拡張され、どのストレージでもBackup Copyジョブのターゲットとして機能することができます。

最後に、ほとんどの重複ストレージで、インスタントVMリカバリ、ファイルレベルおよびアプリケーションアイテムの復元パフォーマンスを向上できるように、多数の内部最適化を追加しています。Veeamは引き続き、最適なパフォーマンスを得るために、Veeamのリファレンスアーキテクチャに可能な限り従うことを推奨しますが、これらの改善点は、特定の復元シナリオ (例えば、一般的に重複排除ストレージが使用されるオフサイトのバックアップリポジトリからの復元) で役立ち、復元エクスペリエンスを著しく向上します。Active Directory、SQL Server、SharePoint、ExchangeおよびOracle向けのVeeam Explorerだけでなく、ファイルレベルの復元を含む、ランダムなI/Oを必要とするその他の種類の復元も、パフォーマンスが大幅に向上し、きめ細かな復元を以前よりも高速に実行することができます。

個人的な意見として、これらの新しい統合により、実際に、企業は、重複排除に対する投資を最大限に活用できると思います。最高のパフォーマンスと最高の重複排除率を組み合わせようとすると必ず、重複排除が難題になります。しかし、これらの新しい統合は、このような難題を解決するのに大いに役立ちます。この素晴らしい新機能の詳細については、Veeam Availability Suite v9のページを参照してください。

Veeam Availability Suite v9の新しいストレージ統合に関するウェビナーをまもなく開催します。ぜひご登録ください。

今日の大企業にとって、バックアップストレージのIT管理は、増え続けるデータに対処できなければ、膨大な労力と費用を要する課題となります。従来のバックアップソリューションでは、この問題を効率的に解決するのが困難であるため、問題はさらに悪化して、管理負荷が増大し、未使用の無駄なストレージが多すぎるために、バックアップストレージの管理が悩みの種になります。

より効果的な方法が必要です。つまり、大企業において、バックアップストレージの管理を簡素化し、管理に伴うITの作業負荷を大幅に軽減すると同時に、バックアップストレージのハードウェア費用を削減することにより、データ保護の予算に対する影響を軽減する方法です。

Veeamでは、常に技術革新を進めており、今回、バックアップストレージの管理方法に大変革をもたらす素晴らしい新機能を導入しました。   Veeamの新しい無制限のScale-out Backup Repository (スケールアウト バックアップリポジトリ) は、異種ストレージデバイスで構成される単一のスケーラブルなバックアップリポジトリを作成することにより、従来のバックアップストレージ管理の問題を解決します。これは、バックアップストレージをより効率的に管理および使用できるソフトウェア定義の抽象レイヤーを作成して、バックアップストレージとバックアップジョブの管理を徹底的に簡素化します。

その仕組みに関心があれば、続きをお読みください。

現在のバックアップストレージの管理 － IT管理者の頭痛の種

この図は何を示しているかお分かりになりますか。これらはすべてバックアップリポジトリです。これが、多くのユーザーが受け入れなければならない現実です。

なぜこのようなことが起こるのでしょうか。最も一般的な原因は、複数の物理ストレージデバイスがバックアップ先として使用されることにあります (例えば、物理サーバーの内蔵ディスクへのバックアップは、一般的なバックアップストレージソリューションです)。別の原因としては、単にストレージデバイスの最大ボリューム (LUN) サイズに制限があるということが考えられます。いずれにしても、大半のユーザーは、複数のバックアップリポジトリを使用しており、最も規模の小さい環境であっても、最初のバックアップ先はすぐに肥大化してしまい、しかも、それが破棄されることはありません。

こうした状況から、大半のユーザーは、少なくとも、バックアップリポジトリと同じサイズのバックアップジョブを作成する必要があります。ユーザーは、バックアップストレージの容量に見合うジョブを数十個、あるいは数百個も作成することを決して望んでいるわけではなく、ただそうせざるを得ないのです。

さらに、一見しただけではわからないもう1つの問題があります。"Free"のカラムを見てください。大量の無駄なディスク領域があることにお気づきになるでしょう。実際のところ、将来の仮想マシン (VM) の増大を考慮すると現在のジョブの配置を控えめにせざるをえないのです。そうしなければ、ユーザーはおおむね、リポジトリ用のディスク領域の不足に起因するバックアップの失敗や、繰り返されるジョブの再設計に全力を傾けることになります。これを回避するために、まさしく文字通り、追加のバックアップストレージを購入しなければなりません。しかし、既存のストレージ容量の30%以上はただ将来の増大に備えて待機しているだけで、未使用のままです。

使用可能なストレージリソースを最大限に活用するために、バックアップジョブのターゲットとなるバックアップリポジトリをいちいち選択しなければならないのは、面倒ではありませんか。この絶えず続くバックアップジョブの「細かな管理」をきっぱりとやめ、次のバックアップストレージを購入しないで済ませたいとは思いませんか。そのためには、単に既存のストレージをより有効に利用すればいいのです。現状を変えたいとお思いであれば、続きをお読みください。;)

新種のバックアップリポジトリ

自然界と同様、適切なバックアップストレージソリューションを選択することは常に、生き残りをかけた問題です。ユーザーやコンサルタントは、既存の環境に基づいて、特定のシナリオに最適なソリューションを見つけなければなりません。高速なストレージアレイの場合もあれば、大量の復元ポイントを保持できる大容量システムの場合もあります。また、重複排除アプライアンスなども考えられます。

しかし、自然界と比べると、これらのシステムには、ある重要な機能が欠けています。それは、進化です。これらのシステムは通常、いったん選択してしまうと、その動作や特性を変更することはできません。オールフラッシュアレイが重複排除アプライアンスより安くなることは、当面考えられません。また、ディスクアレイが、フラッシュアレイより高速になることはないし、重複排除アプライアンスが、ストレージアレイのようにバックアップファイルからVMを起動できるようになることもありません。どの選択肢もそれぞれ一長一短があり、設計者は、ソリューションを慎重に選択する必要があります。なぜなら、選択するソリューションは高価なものであり、投資を回収できるだけの十分な減価償却期間が必要だからです。当初の選択が間違っていたからと言って、わずか数ヶ月後に別のバックアップストレージに買い替えようと思う人はいません。しかし、誰もが毎年倍増するデータの処理に直面しているこの現代社会において、1年前は適切だった選択が、今は適切であるとは限りません。

企業ユーザーは、データ量の増大に対処しなければなりません。その一方で、コスト、ストレージ容量、バックアップウィンドウ、およびシステム関連の管理コストが厳格に管理されていることを利害関係者に保証する必要があります。これは、簡単なことではありません。Veeamは、Backup Copyジョブとリファレンスアーキテクチャを導入することにより、これらの問題の一部を解決してきました。最も高速のバックアップと復元のために高速で小容量のTier 1ストレージ、バックアップコピーを保存して、限られた予算でできるだけ長く保持するための大きく安価な (TB単価) Tier 1ストレージです。それでも、リポジトリの管理に取り組む必要があります。つまり、最初の選択から、長期にわたるスペース使用量、再利用および廃棄までを管理しなければなりません。

Scale-out Backup Repository (スケールアウト バックアップリポジトリ) は、Veeam Availability Suite v9に新しく導入された非常に優れた機能で、これらの問題を直接解決し、ユーザーにバックアップストレージを管理するための新たな方法を提供します。

スケールアウトレポジトリは、ひと言でいうと、複数の「通常の」リポジトリを単一のプールに統合し、そのプールをバックアップコピーおよびバックアップジョブのターゲットとして使用します。単純な機能に聞こえますが、これはユーザーに多くの新たな素晴らしい機会を提供します。いかがですか。きっと、すでに関心が高まってきたことと思います。

グローバルプール

まず、規模の大小を問わず、企業ユーザーにとって、スペースが不足したらリポジトリを簡単に拡張することができます。ユーザーは、時間がかかり、面倒なバックアップチェーンの再構成 (大企業ユーザーの場合、非常に大がかりになる可能性があります) を行う代わりに、既存のスケールアウトリポジトリに新しいエクステント (つまり、「通常の」バックアップリポジトリ) を追加することができます。既存のバックアップファイルはすべて保存されます。さらに、追加のリポジトリをグループに追加しても、バックアップのターゲットは変わりません。しかも、追加された空きスペースは、すぐに使用できます。

この機能は、たとえVMの数が数千台に及んでも、環境全体を単一のジョブで保護できることを意味します。これは、特にv9で導入される他の優れた機能 (VMごとのバックアップチェーン) と組み合わせた場合に顕著です。多数の大きなエクステントにより、そのジョブのターゲットをスケールアウトリポジトリに指定するだけです。リポジトリ別に容量を管理したり、ジョブサイズのプランニングを何度もやり直したりする必要はありません。

ストレージへの投資を活用

Scale-out Backup Repositoryは、リポジトリと同様に機能する、単なるリポジトリのグループではありません。こういう言い方をすると、別のスケールアウトソリューションのように聞こえるかもしれません。ノードが追加されると、システムは、追加スペースとコンピュータリソースが利用可能になります。これは、Veeamのスケールアウトリポジトリにも当てはまりますが、その機能の説明の一部にすぎません。Veeamはストレージ企業ではありません。ユーザーが機能、パフォーマンス、スペースおよびコストに関するニーズに基づいて選択したストレージを使用するソフトウェアソリューションです。ユーザーは、Scale-out Backup Repositoryのおかげで、異なるストレージシステム (つまり、ローカルまたはDASストレージ、ネットワーク共有、および重複排除ストレージアプライアンスを備えたWindowsまたはLinuxサーバーなど、Veeamによってサポートされるすべてのバックアップ先) を組み合わせて一つにすることができます。小さなチャンクに分割された多数の空きスペースが複数のサーバーまたはファイルに分散していませんか。それらをすべて新しいScale-out Backup Repositoryに追加すれば、その空きスペースをすぐに有効利用することができます。すでにあるスペースを使い果たすまで、新たにストレージを買い足す必要はありません。

しかし、より重要なのは、Scale-out Backup Repositoryは、実際のストレージデバイス上に配置されるソフトウェア定義のストレージ技術であるということです。これは、どんなストレージソリューションでも、そのすべての単一機能が維持されることを意味します。例えば、Scale-out Backup Repositoryを使用する場合でも、重複排除アプライアンス (EMC Data Domain Boost、HP StoreOnce CatalystまたはExaGrid Accelerated Data Mover) を使用することができ、その独自のAPIを活用して、データの大幅な削減とパフォーマンスの向上を実現することができます。もうおわかりでしょう。ご使用の環境で使用可能な、またはこれから取得しようとしているすべての種類のリポジトリを組み合わせて一つにすることができ、その高度な機能もそのまま活用することができます。他の汎用スケールアウトストレージソリューションとは異なり、Veeamでは、ローカルディスクを備えたサーバーに限定されません。

このソリューションも、特定のハードウェアおよびストレージにまったく限定されないというVeeamの最も重要な設計目標を踏襲しています。他のエンタープライズバックアップベンダーが、特定のストレージプラットフォームだけをサポートし、さらに悪いことに、自社製のストレージアプライアンスを購入させたいと考えていれば、ユーザーは、さらに多くのストレージリソース (汎用ストレージではない) を取得せざるを得ません。これに対して、Veeamはまったく異なる方法を採用しています。つまり、データセンターにすでにあるストレージを活用します。既存のリソースを完全に使い果たすまで、新たにストレージを購入する必要はありません。

ストレージ対応の配置

バックアップストレージはさまざまで、Scale-out Backup Repositoryは、これを考慮して設計されています。各エクステントについて、「役割」を割り当てることができます。グループのリポジトリごとに、完全バックアップ、増分バックアップ、またはその両方のどれを受け入れるかを定義します。これは、マウスを数回クリックするだけで行うことができます。ここで、無限の可能性について考えてみましょう。Scale-out Backup Repositoryは、異なる特性を持つ複数のリポジトリを1つのグループにまとめることで、簡単に作成できますが、グループに含まれる特定のストレージデバイスの長所をシームレスに活用するように設定することもできます。

Veeamバックアップに対する変換操作の例を取り上げてみましょう。変換操作が発生すると、2回のI/O操作で、最も古い増分ファイルが完全バックアップファイルにマージされます。多くのローエンドのバックアップストレージシステムは、このランダムI/Oに十分に対応できず、ユーザーは結局、アクティブな完全バックアップを選択することになるので、IOPS (Input/Output operations Per Second：1秒間の入出力回数) が低下するだけでなく、永続的な増分バックアップの利点も失われます。ここで、別の単純なJBOD (Just a ｂunch Of Disks：単なるディスクの束) を最初のリポジトリに追加した場合を考えてみましょう。Scale-out Backup Repositoryは、まったく異なる (しかも効果的な) 方法で機能させることができます。増分バックアップを一方のエクステントに割り当て、完全バックアップを他方のエクステントに割り当てることにより、変換が発生すると、2回のI/O操作のうちの一方のI/O (読み取り) が、増分バックアップを保持しているリポジトリによって実行されるようになり、完全バックアップを保持しているリポジトリに残っているのは、1つのI/O (書き込み) だけになります。フラッシュ、キャッシュ、または他のメカニズムを追加しなくても、Scale-out Backup Repositoryは変換操作のパフォーマンスを直ちに2倍以上向上します。それほど悪くはありませんよね。

では、JBODと同様の小さなクローン群ではなく特殊化されたエクステントの集まりについて考えてみましょう。増分バックアップを高速で取り組むための非常に高速のオールフラッシュアレイと、複数のGFS (Grandfather-Father-Son) 完全バックアップを保持するための汎用の重複排除アプライアンスを組み合わせるとどうなるでしょう。2つのまったく異なるソリューションを組み合わせて、それぞれの能力を最大限に活用すると同時に、それらの制限を取り除くことができます。

どんな種類のストレージでも、最も高度なストレージさえ、あるシナリオには見事に適合できても、別のシナリオでは、誤った投資になる可能性があります。Scale-out Backup Repositoryであれば、ユーザーはストレージを自由に選択することができ、しかも選択可能なストレージの基本的な機能を維持することにより、組み合わせは無限になります。

ストレージクラウド

Scale-out Backup Repositoryによって作成される抽象レイヤーのおかげで、バックアップ管理者は、セルフサービスソリューションの「ストレージクラウドのプロバイダー」になることができ、ユーザーは、独自のバックアップジョブを自由にセットアップすることができます。どのストレージに割り当てるかを考える必要はありません。また、ジョブが特定のリポジトリに収まるように、バックアップジョブのサイズや保持期間を計画するための複雑な計算を行う必要もありません。

代わりに、バックアップ管理者が、単一のスケールアウトリポジトリをセットアップするだけで済みます。この場合、ユーザーは、(たくさんのリポジトリではなく) 1つのリポジトリだけを、セルフサービスで、ジョブのターゲットとして選択することができます。その後、スケールアウトリポジトリは、ポリシーおよび使用可能な空きスペース量に基づいて、使用可能なエクステントの使用を開始します。クラウドのような適切なソリューションと同様、スケールアウトリポジトリでも、責任をプロバイダーと顧客との間で完全に分離することができます。

自然界では、生き残るために進化する必要があります。Veeam Scale-out Backup Repositoryを使用すると、バックアップ先を進化させて、すでに行ったバックアップストレージへの投資を一切無駄にすることなく、変化する社会に合わせて短時間で調整することができます。

私には、信じられないほど素晴らしい機能に思えるのですが、いかがですか。

Veeamでは、Scale-out Backup Repositoryの詳細について学べるウェビナーをまもなく開催します。ぜひご参加ください。

Veeam Backup & Replicationには、インスタントVMリカバリ、VM全体または単一のファイルの復元、およびアプリケーションアイテムの復元などの多数の復元オプションが用意されており、 復元に関するさまざまな問題を解決するのに最適なソリューションです。

仮想ディスクの復元を実行すると、インスタントVMリカバリを使用するかどうかにかかわらず、最終的に、仮想ディスク全体がバックアップストレージから本番環境のストレージに完全にコピーされます。インスタントVMリカバリを使用する場合、これは問題ではありません。仮想マシンがすでに実行しているときに、バックグラウンドで移行が発生したとします。しかし、VMの復元直後に、完全なI/O容量が必要だとしたらどうなるでしょう。

Backup & Replication v8では、クィックロールバック機能によってこれを実現することができます。クィックロールバックは、VM全体またはVMのハードディスクを元の場所に復元する際に選択することができ、 増分復元を実行します。Veeam Backup & Replicationは、仮想ディスク全体を復元する代わりに、必要なブロックだけを復元して、VMを、選択された復元ポイントに保存されている状態に戻します。最後のバックアップ以降に変更されたブロックだけがコピーされます。このため、復元時間が大幅に短縮されます。

変更されたブロックを識別するために、Veeam Backup & Replicationは、増分バックアップの実行に使用されるCBT（Change Block Tracking）テクノロジと同一のテクノロジを使用します。VMwareの場合、Veeam Backup & Replicationは、vSphere APIに対してクエリを実行することで、この情報を取得します。Hyper-Vの場合は、同じ情報を、Veeam独自のCBTエンジンに対してクエリを実行することにより取得します。Veeam Backup & Replicationは、変更された仮想ディスクブロックのリストも、これと同様に取得し、 このリストにより、最後のバックアップ以降に変更され、仮想ディスクに復元しなければならないデータブロックを認識します。

この機能には、多数の用途があります。最も実用的な例の1つは、トロイの木馬に感染した仮想デスクトップからマルウェアを除去する代わりに、クィックロールバックを使用する場合です。復元は数秒で完了しました。

コンソールでは、例えば、仮想マシン全体の復元を開始することができます。ウィザードの[Restore Mode (復元モード)]ステップで、デフォルトの[Restore to the original location (元の位置への復元)]オプションを選択した場合、[Quick rollback (クィックロールバック)]チェックボックスをオンにするだけでクィックロールバックを実行することができます。

ウィザードは、元のVMをシャットダウンし、変更されたブロックだけの復元を開始します。通常のVM全体の復元 (左側) と比較すると、クィックロールバックの利点がひと目でおわかりいただけると思います。

実際に使用されているのは、20GBのVMDKディスクのうち2.2GBです。VM全体の復元では、2.2GBすべてを68秒で復元しました。一方、クィックロールバックは、29MBだけを12秒で復元しました。当然ながら、複数TBの仮想ディスクを使用する本番VMでは、この差がはるかに大きくなります。

前述のとおり、クィックロールバックは、CBT情報を使用します。 ただし、多くの災害シナリオでは、CBTデータに依存することはできません。このため、デフォルトでは、このオプションを無効にしています。クィックロールバックは、VMのゲストOSレベルで問題が発生した後にVMを復元する場合に限り使用すべきです。 問題が、ホストやストレージハードウェアの問題または電源障害に起因する場合、[Quick rollback (クィックロールバック)]オプションを使用しないでください。 このような場合、CBTデータが破損している可能性があり、誤ったブロックを復元したり、仮想マシンのディスクが完全に破損したりする危険性があります。

最後に、クィックロールバックには、いくつかの制限があります。第一に、増分復元を2回続けて実行することはできません。最初の増分復元を実行すると、元のVMのCBTはリセットされます。 増分バックアップを少なくとも1回実行しなければ、増分復元を再度実行することはできません。第二に、VMware環境では、転送モードがネットワークまたは仮想アプライアンスの場合のみ増分復元を実行することができます。この種の復元では、Direct SAN Access転送モードを使用することはできません。

しかしながら、いくつかの制限があるものの、クィックロールバックが非常に役立つ機能であることは確かです。

スナップショットは、どんな仮想化環境でも不可欠な機能で、今さら話題に上らないほど一般的なものになり、私たちは当たり前のように使用しています。
スナップショットを使用すると、各仮想マシンのポイントインタイムコピーを作成し、そのコピーを使用して仮想マシンを特定の時点に復元できるので、まるで時間を制御できているような気がします。 例えば、本番システムでパッチを適用した後、何かが壊れてしまっていることに気づいたことはありませんか。仮想マシンを、パッチを適用する前の状態に戻すことができれば、それ以上簡単なことはありません。このような場合、スナップショットが役立ちます。

しかし、スナップショットを使えば使うほど、マイナスの面もあることが徐々にわかってきます。VMware環境では、スナップショットは、ストレージ内の追加ディスクとして表されます。古いポイントインタイムは、読み取り専用状態で保持されます。スナップショットが使用するスペースには、ストレージアレイのスペースが使用されます。I/Oフローは、2つ以上の異なる仮想ディスクに対して発生するため、仮想マシンのパフォーマンスに影響を与える可能性があります。 スナップショットを仮想マシンに長期間放置することは、最悪な状況を招く原因の1つです。おそらく、Veeam ONEの「アクティブスナップショット」レポートの使用頻度が最も高いのはそのためでしょう。

スナップショットを効果的に制御する方法はあります。しかし、それで十分でしょうか。

隠れたスナップショット

実際には、十分ではありません。

スナップショットは、さまざまな理由から、vCenterにより「消失」してしまうことがあります。これらの消失したスナップショットは、その後、インターフェイスには表示されませんが、実際はまだストレージ内に存在しています。 このため、データストアのスペースはまだ使用されている状態であり、深刻な問題を引き起こす場合があります。

これは、Veeam Backup & Replicationのアクティビティの実行中にも発生する可能性があります。すべてのデータ保護タスクは、仮想マシンのスナップショットから開始されます。Veeamは、このスナップショットにより、仮想ディスクに格納されたデータの正しい静止点を保証することができます。このため、バックアップまたはレプリケーションの開始時に、Veeam Backup & Replicationは、特定の仮想マシンのスナップショットを開始するようにvCenterに要求します。 完了すると、静止された仮想ディスクがコピーされます。ジョブの最後に、Veeamは再度スナップショットを要求します。

問題となるのは、このときです。場合によって、vCenterがスナップショットを正しく削除したと報告しても、スナップショットは実際にはまだ存在します。

スナップショットハンター

このため、Backup & Replicationには専用の機能が導入されています。 これは、バックアップやレプリケーションを実行した後に放置されたままのスタックスナップショットを特定し、削除します。 これをSnapshot Hunterと呼びます。

スナップショットをコミットするアクティビティが完了した直後に、その結果にかかわらず、コミットの成功が報告されます。

Snapshot Hunterは、仮想インフラストラクチャに接続し、仮想マシンが格納されているデータストアの内容を読み取ります。 バックアップ操作の実行中に作成されたスナップショットファイルがまだ残っている場合、そのことがジョブの統計で通知されます。

その後、削除プロセスが開始します。Snapshot Hunterアクティビティには、特定のスケジュールがあります。その仮想マシンの処理が完了した後、スタックスナップショットを削除する最初の試みが実行されます。 スナップショットまたは関係する別のファイルがコミット時に単にロックされる場合もあります。統合は、この問題を即座に解決することができます。

統合アルゴリズムは、次の3つのステップで構成されます。

1. VMware Consolidateによる統合方法
2. 「静止なしのハード統合」 – スナップショットの作成と削除
3. 「静止ありのハード統合」 – スナップショットの作成と休止中のスナップショットの削除

12時間経ってもスナップショットを安全に削除できない場合、Snapshot Hunterは、スタックスナップショットについてユーザーに通知します。Snapshot Hunterの特定のアクティビティをチェックするには、[History (履歴)]タブを開いて、用語"snapshot"を使用して"system"アクティビティをフィルタリングするだけです。

各"VM snapshot consolidation"ジョブは、スタックスナップショットを削除するSnapshot Hunterです。Snapshot Hunterは完全に自動化されるので、何も構成する必要はありません。

Snapshot Hunterは、バックアップまたはレプリケーション後に放置されているスナップショットだけを検索して削除します。さらに、Snapshot Hunterは、Veeam Backup & Replicationに完全に統合されます。例えば、スナップショット数がデータストアあたりの最大数に達すると、少なくとも1つのスナップショットが削除されるのを待ってから、統合処理を実行します。 Snapshot Hunterは、ストレージに対する追加のI/Oを発生しません。

Snapshot Hunterは安全なのでしょうか。Snapshot Hunterは、スナップショットの削除のためにVMwareサポートによって開発された手順に従います。このため、ご使用の環境を損なうことはありません。それどころか、仮想インフラストラクチャの英雄になるかもしれません。

本日、Veeam Availability Suite v9 がリリースされ、ダウンロード可能となったことをお知らせします！この新しいバージョンでは、非常に多くの新機能を提供しますが、本バージョンに関する詳細は、『をご覧ください。このドキュメントは、v9 で提供するすべての機能について詳細にご説明いたします (併せてVeeam ONE v9 の新機能も参照してください)。

概要を把握するだけであれば、次のブログ記事をお読みください。v9 の主な機能について多数のブログが公開されています。

• Veeam Availability Suite v9 で新しく導入される EMC ストレージ スナップショットとの統合
• v9 に新しく導入された Veeam Cloud Connect Replication
• Veeam Availability Suite v9 に多数のストレージ拡張機能を導入！
• Veeam Explorer for Oracle が新登場、既存の Explorer も機能拡張
• v9 の エンタープライズ環境向けの機能拡張：ROBO および テープ
• v9 で HP StoreOnce Catalyst との統合を実現
• Veeam Availability Suite v9 でのバックアップ ストレージとの統合
• Veeam Availability Suite v9ではScale-out Backup Repositoryを無制限に利用可能！

v9 には多数の新機能が導入されていますが、特に注目すべきポイントは、主に以下の二つの機能です。Veeam Cloud Connect Replication と、 Scale-out Backup Repository です。これらの機能はどちらもメジャー リリースにふさわしい拡張です。これらの二つの機能に取り組んだ作業量を考えてみると、開発部門がこれらの機能を完成させたことは、非常に意義のあることです。

Veeam Cloud Connect Replication により、DRaaS は、今までは実現不可能だった新しい市場を切り開くことができるでしょう。これにより、Veeam Cloud  & Service Provider (VCSP) パートナーが、新しい価値あるサービスを提供することで新たなビジネス チャンスの創出につながり、Veeam のユーザー、特に単一のサイトで運用し、真のディザスタ リカバリ ソリューションを求めているユーザーにとっても新たなオプションとして検討できるようになります。Veeam Cloud Connect Replication は、サイト全体または VM のサブセットだけをフェールオーバーする機能により、万一複合的な障害が発生した際にも対応できるようになります。これは、今後数年のうちに、DRaaS 業界の認識を一変させる機能になると確信しています。

Scale-out Backup Repository は、多くのユーザーより求められていたもう 1 つの機能ですが、Veeam はユーザーが予期していない方法で実現しました。単に、簡単に拡張することもできるシンプルなストレージ プールを作成するのではなく、さらに進めて、パフォーマンス・プロファイルを設定できるようにしたのです。つまり、増分バックアップの保持には、SSD のような高速クラスのバックアップ ストレージを使用し、速フル バックアップの処理には、低速層を使用することができます。これにより、増分バックアップがはるかに高速化され、しかも増分バックアップはフル バックアップほど多くの容量を必要としないので、その貴重な SSD スペースを節約することができます。これは、Scale-out Backup Repository の始まりにすぎません。今後のより一層の進化にぜひご注目ください。

最後に、v9 を2015 年中にリリースすると断言していた事実に言及したいと思います。実は、v9 を GA リリースで一般公開しませんでした。v9 のコードは、

2016 年には、Windows Server 2016 のリリースに併せてさらなる別のリリースも予定しています。v9 のリリースでは実現できなかったいくつかの機能追加や機能拡張が行われる予定です。Veeam のブログやソーシャル メディア チャネルのチェックをお忘れなく。最新情報をお届けします。

パブリック クラウドは依然として人気のサービスです。世界中の多くの IT 組織は、既にパブリック クラウドで本番ワークロードを実行しているか、少なくとも、将来の可能性に備えて投資を行っています。この傾向は今後も続くばかりでなく、パブリック クラウドを通じて使用可能なワークロードはますます増えていくでしょう。

コストと管理の両面から、ワークロードをパブリック クラウドで実行することは大企業にとって重要であることは周知の事実です。しかし、現在のところ、本番ワークロードにパブリック クラウドを採用する割合は依然として低く、その原因は、可用性に関する懸念にあります。このようなクラウドでサーバー インスタンスをバックアップできないということは、ビジネスが中断される危険性が非常に高いことを意味します。現在、候補となるソリューションは存在しますが、簡単に使いこなすことができず、しかも高価であったり、非常に多くの IT スタッフのリソースを必要とします。

Veeam は既に  Veeam Endpoint Backup FREE で Microsoft Windows 向けのバックアップ エージェントを提供していますが、パブリック クラウドのワークロードの大半は、Linux で実行されているというのが現実です。

Linux サーバーの可用性を実現するのは、至難の業です。スクリプトやネイティブの機能を利用する無償ソリューションが数多く出回っていますが、これらも非常に手間がかかります。Linux 管理者は、仕事を成し遂げるために奮闘していますが、その努力は、総所有コスト (TCO) が非常に高くなる可能性があることを意味し、必要とされる目標復旧時間 (RTO) および目標復旧時点 (RPO) を達成するために必要不可欠な機能は、まったく使用できません。最後に、Linux 管理者が退職したらどうなるでしょうか。そのソリューションのサポートを継続するにはどうしたらいいでしょうか。

有償のソリューションは、これらの問題に対処しますが、そのほとんどは非常に複雑で、しかも高価です。結果として、ワークロードの大半はまったく保護されないことになります。

Veeamにとって、Veeam Backup for Linux が本当に必要であることは明らかでした。

Veeam Backup for Linux

Veeam Software は、Veeam FastSCP for Microsoft Azure など、パブリック クラウドと情報をやり取りするソリューションを既に提供していますが、このたび、Veeam Backup for Linuxを発表しました。

Veeam Backup for Linux  は、Linux サーバー上で実行するシンプルで無償のエージェントです。これは、個々の Linux クラウド インスタンスまたはオンプレミスの物理 Linux サーバーの可用性を確保するために必要な機能を提供するように設計されています。

ソリューション

Veeam Backup for Linux  は、エージェントベースのソリューションで、ゲスト OS (オペレーティング システム) 内で実行されます。

Veeam のソリューションは、Veeam 独自の変更ブロック追跡 (CBT) ドライバーにより、増分バックアップをサポートします。さらに、Veeam は、LVM (論理ボリューム マネージャー) との互換性を維持しますが、LVM スナップショットは利用しません。その代わりに、独自のボリューム スナップショット プロバイダーが実装されており、LVM スナップショットと同じ制限に縛られることはありません。このため、Veeam は、非常に広範囲のファイル システムでブロックレベルのスナップショットを作成しながら、実際にバックアップしているボリュームではなく、指定されたストレージ デバイスにスナップショット データを保存します。さらに重要な点は、Veeamのソリューションは、Veeam Backup for Linux の組み込み機能のみを使用することで、サーバー ストレージについて一貫性のあるスナップショットを作成することができます。

また、Veeam Backup for Linux は、v1 でほとんどの Debian ベースおよび Red Hat ベースの Linux ディストリビューションをサポートします (サポートされるディストリビューションの正確な数は、リリースが間近になった時点で発表される予定です)。ご心配はいりません。Veeam は、お客様のフィードバックをもとに、今後の更新でサポート範囲を早期に拡大することを目指しています。

• 構成では、サーバー全体からボリュームレベルやファイルレベルまで、幅広いバックアップ オプションを設定できます。このため、サーバー上の特定のファイルやボリュームの復元、またはベアメタル復元によるサーバー全体の復元さえも実行できます。
• 管理者はさらに、プレフリーズ スクリプトおよびポストフリーズ スクリプトを使用できるので、バックアップに備えて、ワークロードをアプリケーションレベルで整合性を維持した状態にすることができます。
• 使用可能な管理オプションとしては、Web ベースの GUI、コマンドライン インターフェイス、および構成ファイルがあります。コマンドラインを使用して作業したいユーザー向けに、Veeam は、最小限ながら有益なコンソール インターフェイスを作成しました。これは、ジョブの進捗およびパフォーマンス統計情報をリアルタイムに提供します。

注：UI はまだ最終版ではないので、変更される可能性があります。

ほとんどの構成でインストールが可能な限りスムーズに進むようにするために、依存関係は最小限に抑えられています。

Veeam Backup for Linux には、SQLite が組み込まれています。これは、ジョブ設定や統計などを保存する軽量のローカル データベース エンジンです。ご心配は無用です。SQLite のフットプリントは非常に小さく、サーバーのリソースをほとんど使用しません。多くの方がご存知のとおり、SQLiteは、Firefox でも内部データベース エンジンとして使用されています。

復元

バックアップは、復元できなければ意味がありません。これは、しばしば我々が口にしていることですが、おそらく、今後はさらに頻繁に言われるようになることでしょう。結局のところ、復元できなければ何のためにデータをバックアップするのでしょうか。Veeam Backup for Linux は、Veeam が提供するRecovery Media を使用することにより、ファイルレベルの復元、ボリュームレベルの復元およびベアメタル復元をサポートします。肝心なのは、失ったデータに対するアクセスを可能な限りすばやくかつ確実に取り戻すことです。

統合

Veeam Backup for Linux は、無償のソリューションですが、Veeam Availability Suite または Veeam Backup & Replication を購入されているユーザーは、既存の Veeam リポジトリをバックアップ先として利用することができます。これにより、リポジトリに対するすべてのバックアップ ジョブの基本的な監視と管理、バックアップ ステータスに関する電子メール通知の受信、バックアップ ファイルの暗号化、バックアップ ファイルのテープへのアーカイブ、またはオフサイト保護のためのクラウドへのコピーを実行することができます。

この統合はさらに、現在 Veeam Endpoint Backup FREE で使用可能な機能と同様に、Veeam Backup & Replication の標準機能であるアイテムレベルの復元にも利用できることを意味します。

結論

Linux のクラウド インスタンスと物理サーバーのバックアップと復元は、簡単な作業ではありません。多くの場合、データは必要なレベルで保護されていません。このため、多くの企業では、クラウドの採用が制限されます。Veeam では、Veeam Backup for Linux (2016年初めに一般公開予定) で、シンプルかつ無償のバックアップ エージェントを提供して、場所を限定することなく、Linux サーバーの保護を可能にします。さらに、ベアメタル復元などの柔軟性に富んだ復元オプションを提供します。また、Veeam Backup & Replication と統合し、機能性をさらに高めることもできます。

Veeam Backup for Linux  のクローズド ベータ バージョンは、2016年初めに先着順に入手できるようになる予定です。ベータ コードへのアクセス申請 - Veeam Backup for Linux beta.

SQL データベースは、ERP や GRM のシステムだけでなく、他の数多くのクリティカルなビジネス アプリケーションにとっても、中核となるものです。SQL データベースのダウンタイムやデータの消失は、従業員の何時間にも及ぶ作業時間を無駄にする財政上の損失、取引の解消や収益の損失を意味します。ダウンタイムが発生しても、データをできるだけ最新の状態まで保護するには、SQL トランザクション ログのバックアップをより頻繁に取得する必要があります。ログをバックアップすることにより、SQL Server の可用性が最大化され、任意の時点へのデータベースの復元が可能になります。

トランザクション ログは、ネイティブの Microsoft ツールまたはサードパーティ製ソリューションのいずれかで処理することができます。ネイティブ ツールには、SQL Server Management Studio、Transact-SQL (T-SQL)、SQL Server Agent ジョブ、SQL Server メンテナンス プラン、および PowerShell スクリプトが含まれます。これらのオプションを使用する方法の詳細については、Microsoft の TechNet および  MSDNを参照してください。

ここでは、Veeam^® を中心に説明します。Veeam Backup & Replication™ (Veeam Availability Suite™ の一部) は、SQL Server 全体のバックアップに加えて、トランザクション ログのバックアップを実行します。これは、SQL Server の一貫したバックアップを作成するために application-aware image processing (アプリケーション整合性イメージ処理) を提供し、ログのバックアップと切り捨てをサポートします。仮想化された SQL Server 2012 および SQL Server 2014 の場合、Veeam は、AlwaysOn 可用性グループもサポートします。

データベースのプロパティは、トランザクションのロギングをサポートする必要があります。SQL Server は、復元モデルを使用してトランザクション ログを制御します。単純復旧モデルでは、トランザクション ログがバックアップされないため、特定時点への復元を実行することはできません。Veeam Backup & Replication は、デフォルトでは、単純モードのデータベースをログ プロセス ジョブから除外します。完全復旧モデルまたは一括ログ復旧モデルのデータベースの場合のみ、その変更がトランザクション ログ ファイルに記録され、特定時点への復元が可能になります。データベースが完全復旧モードまたは一括ログ復旧モードであることを確認してください。

Veeam Backup & Replication では、トランザクション ログのバックアップ ジョブは、SQL Server VM のバックアップ ジョブに含まれるサブタスクです。このため、まず、SQL Server VM のバックアップ ジョブを作成し、設定します。トランザクションレベルで一貫性のある SQL Server のバックアップを作成するには、application-aware image processing (アプリケーション整合性イメージ処理) を有効にします。

[Applications (アプリケーション)] をクリックして、SQL のオプションを設定します。

[Edit (編集)] 設定で、[Process transaction logs with this job (このジョブでトランザクション ログを処理する)] を選択します。

ログ ファイルは、データベースのロードと共にサイズが増大するので、ログ (.LDF) ファイルのサイズを制御するには、トランザクション ログを定期的にバックアップする必要があります。変更の量や頻度によっては、.LDF ファイルがデータベース自体の 2 倍以上の大きさに増大する可能性があります。割り当てられたストレージ スペースが使い果たされると、新しいトランザクションは開始しません。トランザクション ログをバックアップしている場合、ログは切り捨てられ、ストレージ スペースを再利用します。ログのバックアップと切り捨てにより、ストレージ スペースのオーバーフローが防止されます。

[SQL] タブで、希望するトランザクション ログの管理方法を選択します。使用可能なオプションは、ほとんどすべての SQL 要件に対応します。トランザクションの多い SQL Server データベースの場合、DBA は、15 分以下の間隔でトランザクション ログをバックアップします。ログ ファイルには、データベースへの変更のみが含まれるので、短い RPO を簡単に達成することができます。ログのバックアップは、SQL Server の増分バックアップよりもはるかに高速で、本番環境に影響しません。

Veeam Backup & Replication では、トランザクション ログのバックアップ ジョブは、インターバル バックグラウンド プロセスで、定義されたスケジュールに従って、毎回自動的に開始します。

ログのバックアップは、対応する SQL Server VM のバックアップと共に、.VLB ファイルとしてバックアップ リポジトリに保存されます。

Veeam Backup & Replication は、完全なイメージベースの SQL Server VM のバックアップと、増分チェーンおよびログ バックアップ チェーンを提供します。データベースの復元の場合、Veeam Explorer™ for Microsoft SQL を使用することができます。これは、データベースの復元シナリオとして、最新のバックアップ復元ポイントからの復元、ログの復元による特定時点への復元、およびログの復元による特定のトランザクションへの復元をサポートします。この Veeam ブログには、Rick Vanover 氏が書いた Veeam Explorer による SQL データベースの復元 に関する記事が掲載されています。こちらを強くお勧めします。

最後までお読みいただきありがとうございました。いつも通りですが、コメントをお待ちしております。

私は最近、Veeam を使用して VMware VM のレプリケーションを開始するといかに簡単であるか、それによって RTPO (目標復旧時間と目標復旧時点) を最適化できることについて、ブログを掲載しました。今回は、レプリケーションによりネットワークに大きな負荷がかかるという問題をいかにして克服するかについて説明したいと思います。また、使用可能な帯域幅に制限がある場合に、Veeam Backup & Replication v8を使用して WAN 上のレプリケーション トラフィックを削減する方法についても説明したいと思います。

レプリケートはオンサイトか、オフサイトか

必要な vSphere のレプリケーション シナリオは、ビジネス目標によって決定されます。オンサイトでのレプリケーション は高可用性シナリオで、レプリカが同じサイトに保存されます。オフサイトのシナリオは、データのコピーをリモート サイトに保持することにより、本番サイトで問題が発生した場合に重要なデータを保護します。技術上、サイトは、ソース ホストとターゲット ホストの場所によって異なります。オンサイトでのレプリケーションの場合は、ソースとターゲットの両方の ESXi ホストは、同じサイトに配置され、LAN を介して接続される必要があります。オフサイトでのレプリケーションの場合は、1 つ以上の ESXi ホストがオフプレミスで展開され、WAN を介して本番環境のソース ホストに接続されます。

レプリケーションに必要な帯域幅

VMware VM のリモート レプリケーションに要する時間は、まったく同じ VM のバックアップ コピー プロセスに要する時間よりも長くなります。この追加のオーバーヘッドの一因は、レプリケートされた vSphere VM を作成するために VMware data protection の API が使用されることにあります。WAN (または低速の LAN) を介したレプリケーションは、増分のみを転送する場合でも、数時間かかることがあります (1 日に数ギガバイトの変更が行われる非常に大きな Exchange サーバーを想像してみてください)。

vSphere VM をレプリケートするには、どのくらいの帯域幅であれば十分なのかを質問されることがあるかもしれません。求められる帯域幅は、VM、データ量、レイテンシー、レプリケーション可能な時間帯など、複数の要因に依存します。以下に、必要な接続速度を見積もるための基本的なルールを示します。

必要な WAN/LAN (MB) = ([1日の変更量の合計 (MB) / レプリケーション ウィンドウ (時間)] / 3600) × 8

ここでは、Veeam Backup & Replication が、複数のトラフィック最適化オプションを使用してプロセスを高速化することを考慮していないので、この値は実際よりも大きくなることに注意してください。これは、増分のみを処理することで得られる短縮時間の合計になります。

バックアップをソースとして使用

レプリカをバックアップの代わりに使用することはできません。レプリカは、大きな障害が発生したときに重要なデータを保護し、可能な限り最善の SLA を達成するための手段の一つにすぎません。Tier-1 のアプリケーションを最大限に保護するには、両方のオプションを利用する必要があります。すでに VM のバックアップと関連する増分バックアップがある場合、それをリモート レプリカのソースとして使わない手はありません。そうすれば、本番環境でレプリケーションによって生じる負荷を取り除くことができます。これは、最新の Veeam Backup & Replication v8 に導入されているレプリケーションの拡張機能の １ つです。

バックアップからリモート レプリカを作成する場合、何もしなくてもきちんと機能します。Veeam を使用すると常にそうであるように、このプロセスは自動的に実行されます。定期的なレプリケーション ジョブを除いて、この作業のために特別なジョブを実行する必要はありません。ここで唯一ポイントとなるのは、本番環境の稼働中の VM を指定する代わりに、必要な VM バックアップを含むバックアップ リポジトリをデータ ソースとして指定しなければならないという点です。Veeam Backup & Replication は、リポジトリ上のバックアップ チェーンの最新の復元ポイントからすべてのデータを取得して、新しいレプリカ復元ポイントを作成した後、本番ワークロードからレプリケーション トラフィックをオフロードします。こうすることで、特に、通常オフサイトで VM をレプリケートするのに時間がかかる場合、稼働中の VM に対する大量の読み取り I/O (vStorage APIs for Data Protection (VADP) からのスナップショット プロセスを含む) も節約できます。

レプリカ シーディングによるレプリケーション トラフィックの削減

レプリカ シーディングは、初回のレプリケーション データを削減するのに役立ちます。レプリカ シーディングでも、VM のバックアップをレプリカ シードとして使用するので、基本となるメカニズムは、バックアップからのリモート レプリカと非常によく似ています。ただし、レプリカ シーディングの場合、バックアップ ファイルが使用されるのは、初回のレプリケーション ジョブだけです。2回目以降のレプリケーション ジョブでは、VM レプリカの復旧ポイントを作成するために、本番環境の VM からデータを取得します。

VMware VM をターゲット ホストにレプリケートまたはコピーして、VMware VM のシーディング バックアップを準備する必要があります。バックアップ コピーは、グローバルな重複排除、データブロックの検証およびトラフィックの圧縮機能を持つ WAN アクセラレーションをサポートするので、パフォーマンスが向上します。レプリカ シーディングを実行する場合、Veeam Backup & Replication は、バックアップから復元されたデータの状態と本番 VM を同期させ、変更されたデータのみをレプリケートします。

レプリカ マッピングによるレプリケーション トラフィックの最適化

帯域の使用量を最適化するもう 1 つの方法は、レプリカ マッピングです。この機能では、本番 VM を、DR (災害復旧) サイトに既に存在する代替となる VM にマッピングします。これは、たとえば、既存のレプリカを新しいホストやストレージに再配置したときなど、レプリケーション ジョブを再構成または再作成する必要がある場合に役立ちます。共有の WAN/LAN 接続を使用している場合は、レプリケーション ジョブが VMware 環境で利用可能な全帯域幅を使い果たすのを防ぐために、ネットワーク スロットリングのルールを適用することをお勧めします。

構成に関する問題の解決

ネットワーク設定が異なるサブネット間で VMware VM をレプリケートすると、構成について何らかの問題が発生することがあります。デフォルトでは、Veeam Backup & Replication は、オリジナルの VM とそのレプリカは同じネットワーク構成となります。DR のネットワークと本番環境のネットワークは必ずしも一致する必要ななく、それは問題にはなりません。ネットワーク マッピングのカスタム ルールを設定するだけで済みます。Veeam Backup & Replication のもう 1 つの優れた点は、Windows ベースのレプリケートされた VM に対して IP アドレスを割り当てる再設定機能です。

このブログ記事について、コメントをお寄せください。また、VMware のレプリケーションに Veeam Backup & Replication を使用することで得られるトラフィック最適化の結果もぜひお知らせください。

この Veeam ブログでは最新の情報をお届けしていますので、ぜひご覧ください。私の次の記事では、Veeam を使用した、レプリカのフェイルオーバーとフェイルバックの実行など、より最新のトピックを取り上げます。

お役に立つその他の参考資料：

• Veeam ブログ：Replication, backup or both? (レプリケーションかバックアップか、あるいはその両方か)
• Veeam ヘルプ センター：Veeam のレプリケーションに関する技術ドキュメント
• 録画ウェビナー:Software Based WAN Acceleration 101 (ソフトウェア ベースの WAN アクセラレーション 101)
• 録画ウェビナー:Better disaster-recovery planning with Veeam replication enhancements (Veeam のレプリケーション拡張機能による災害復旧計画の改善)

私がこれまで連載してきた特集ブログ記事「レプリケーション 101 シリーズ」の最後を、Veeam Backup & Replication v8 (Veeam Availability Suite v8の一部) で使用可能な VMware VM レプリカからの復元オプションの概要の説明で締めくくりたいと思います。この記事では、計画済みフェイルオーバーやフェイルオーバー プランなど、災害復旧 (DR) の自動化に役立つフェイルオーバーの基礎知識について解説します。この記事をお読みいただくと、クリティカルなアプリケーションを障害やダウンタイムから保護する方法を理解することができます。

VM レプリカへのフェイルオーバー

レプリカのフェイルオーバー とは、損傷または障害の本番 VM を遠隔地にあるレプリカに切り替えることです。レプリケートされた VM は、使用可能な状態で保存されるので、フェイルオーバーにはわずか数秒しかかからず、即座に VM の電源を入れることができます。レプリカは、ソース VM とまったく同じ構成なので、追加の構成を行ったり、余分な設定を適用したりする必要はありません。フェイルオーバーを開始するには、必要な VM のレプリカを右クリックし、[Failover Now (今すぐフェイルオーバー)] を選びます。そうすると、フェイルオーバー ウィザードが開始します。

レプリケーションの保持期間をカスタマイズすることができ、すべての VMware VM レプリカについて最大 28 の復元ポイントを保持することができます。レプリカにフェイルオーバーする時、Veeam Backup & Replication は、デフォルトで最新の復元ポイントを選択します。ただし、それより以前のレプリカをロールバック対象として指定することができます。これは、ソフトウェアの障害等で最新のレプリカ復元ポイントが破損し、以前の破損していない復元ポイントにフェイルオーバーする必要が生じた場合に役立ちます。

次のステップを決定する

フェイルオーバーをコミットすると、VM レプリカが障害状態の本番サーバーに置き換わります。パフォーマンスは、DR サイトの構成によって異なります。低パフォーマンスのストレージまたは帯域幅が不十分な場合、VM レプリカで実行中のアプリケーションが遅くなる可能性があります。このため、Veeam Backup & Replication では、フェイルオーバーは一時的な状態に留め、ユーザーによってプロセス完了する必要があります。DR サイトに十分なリソースがある場合、永久フェイルオーバーを実行することで、ワークロードを恒久的に DR サイトで実行し、本番 VM を完全に置き換えることができます。この場合、Veeam は、すべての対応する復元ポイント (VM スナップショット) を削除し、元の VM をレプリケーション ジョブから除外します。これにより、変更が、レプリカから作成された新しい本番 VM に影響を与えることはありません。

DR サイトに十分なリソースがなく、永久フェイルオーバーを選択できない場合、稼働するレプリカから元の VM に戻ることができます。メイン サイトの問題が解決した時点で、フェイルバック操作を実行します。Veeam Backup & Replication は、レプリカと元の VM の両方で変更を自動的に同期させるので、元の VM にフェイルバックするか、または新しい宛先を選択することができます。フェイルバックでは、フェイルオーバー イベント以降に変更されたデータのみを転送するというインテリジェントな方法でデータが転送されます。これにより、大幅に時間を短縮できます。

依存関係のあるアプリケーションの場合

クリティカルな仮想化アプリケーションの大半は、環境内の他のサービスと相互に依存関係があります。たとえば、Microsoft Exchange、Active Directory および SQL は、ドメイン コントローラー、DNS および DHCP サーバーと相互に依存関係があります。依存関係のあるアプリケーションの可用性は、これらの相互関係によって決まります。大規模な障害が発生した場合、適切なパフォーマンスを確保するために、これらのサーバー グループ全体を復元し、それぞれを適切な順序で起動する必要があります。

Veeam Backup & Replication v8 では、同時または特定の順序で起動する必要がある VM グループに対して、あらかじめ順序を定義するフェイルオーバー プランを作成することができます。緊急時には、保存したフェイルオーバー プランをワンクリックで開始するだけで済みます。さらに、Veeam の Web UI を使用してタブレットからリモートでフェイルオーバー プランを実行することさえできます。Web UI は、Veeam Backup Enterprise Manager コンポーネントをインストールすることにより、使用できます。

フェイルオーバー プランは、フェイルオーバー前とフェイルオーバー後のスクリプトの実行をサポートします。最も一般的なシナリオの場合、スクリプトは、フェイルオーバー後、同じフェイルオーバー プランから別のアプリケーションが起動する前に、アプリケーションを停止または一時停止するのに役立ちます。たとえば、ドメイン コントローラー (DC) を起動する場合、スクリプトを使用して、キュー内の次のアプリケーションを停止させることができるので、先に実行中の DC からハートビートを取得できます。フェイルオーバー プランのフェイルオーバー前およびフェイルオーバー後のスクリプトとしては、BAT、CMD および EXE ファイルを使用できます。

技術的には、フェイルオーバー プランにグループ化されたアプリケーション レプリカへのフェイルオーバーは、通常のフェイルオーバー プロセスと同じ方法で実行されます。つまり、最新の有効な復元ポイントにロールバックし、フェイルオーバーが完了した時点で、永久フェイルオーバーまたはフェイルバック手順を使用して、プロセスを完了させる必要があります。

データセンターの移行および計画済みメンテナンスに VM レプリカを使用する

ハードウェア、ホストまたは VM がいつダウンするかはわかりませんが、データセンターのメンテナンスなどによる計画済みのダウンタイムは事前に把握できます。Veeam Backup & Replication は、計画済みフェイルオーバー シナリオをサポートします。これは、移行やメンテナンス操作を円滑に進め、ユーザーの作業に対する影響を最小限に抑えるのに役立ちます。計画済みフェイルオーバーは、本番 VM を停止する前に、レプリカを使用してワークロードを本番 VM から DR サイトに切り替えます。データは一切消失しません。

動作のしくみ通常通り、必要な本番 VM を新しい場所にレプリケートし、移行やメンテナンスを開始できる状態になったら、計画済みフェイルオーバー ウィザードを実行します。予期しないダウンタイムで実行する通常のフェイルオーバーとは異なり、計画済みフェイルオーバーは、最後のレプリケーション ジョブが実行されて以降に発生したソース サーバーのすべての変更をレプリカに同期させます。ウィザードの実行が完了すると、Veeam Backup & Replication は、レプリカへのフェイルオーバーを実行すると同時に、ソース VM を停止します。

テスト目的で VM レプリカを使用する

クリティカル アプリケーションのパッチ適用、アップグレードおよびソフトウェアの修正は、システム障害を招く危険性があります。このため、常にすべての変更を、本番環境で適用する前にテストする必要があります。Veeam のレプリケーションは、このようなテストを行うのに役立ちます。構成を追加したり、テスト ラボを作成したりする必要はありません。レプリカにフェイルオーバーし、実行中の VM クローンで、必要なテストを実行するか、またはパッチを適用するだけです。完了したら、安全にフェイルオーバー状態を取消し、本番 VM をフェイルオーバー前の状態に戻すことができます。フェイルオーバー状態で発生した VM への変更はすべて破棄され、本番 VM は再び通常モードで動作するようになります。

お役に立つその他の参考資料：

• Veeam ブログ：Replication, backup or both? (レプリケーションかバックアップか、あるいはその両方か)
• Veeam ブログ：Veeamを使用してレプリケーション トラフィックを最適化する方法
• Veeam ヘルプ センター：Veeam のレプリケーションに関する技術ドキュメント
• 録画ウェビナー:SureReplica - レプリカを稼働

はじめに

大量のデータをバックアップする必要がある場合、バックアップに必要なストレージ・コストを最小限に抑えるために、使用するディスク容量を可能な限り削減する必要があります。しかし、ホストベースのイメージレベルのバックアップを実行する場合、これまでの技術では、仮想マシン (VM) イメージ全体をバックアップせざるを得ません。従来のエージェントベースのバックアップであればこれが問題になることはありませんでしたが、ホストベースのバックアップではいくつもの問題が発生します。

たとえば、Veeam ONEを使用してバックアップを分析すると、一部のVMのバックアップが、ゲストOS内の実際の使用量よりも大きいことに気づく場合があります。その結果、バックアップ・リポジトリの使用量が計画よりも増加します。この現象が最も多く見られるのは、削除された後、新しいデータに置き換えられていないデータが大量に存在するファイルサーバーやその他のシステムです。

リポジトリのディスク使用量の増加を招くもう1つの大きな原因が、不要なファイルです。一部のファイルやディレクトリには、本来バックアップする必要がないデータが保存されている場合があります。しかし、イメージレベルのバックアップでは、このようなデータもバックアップせざるを得ません。

「削除済み」は必ずしも物理的に削除されたことを意味しない

最新のファイルシステムでは、多くの場合、削除済みファイルがハードドライブから完全に消去されないことは広く知られています。ファイルは、ファイルシステムのファイル割り当てテーブル (FAT) で (たとえば、NTFSの場合はマスタファイル テーブル (MFT)で) 削除済みのフラグが付けられるだけです。この場合、ファイルのデータは、新しいファイルで上書きされるまでハードドライブ上に存在し続けます。だからこそ、Undeleteなどのツールを使用することができるのです。このようなブロックの内容をリセットするには、Windows SysinternalsのSDeleteなどのツールを使用する必要があります。このツールは、削除済みファイルに属するブロックの内容を0 (ゼロ) で上書きします。この場合、ほとんどのバックアップソリューションは、これらのゼロで埋められたブロックを重複排除または圧縮するので、バックアップのディスクスペースを余分に使用することはありません。ただし、VMが数百台にもおよぶ場合、すべてのVMでSDeleteを定期的に実行するのは時間がかかり、ほとんど実行不可能なので、大半のユーザーは、SDeleteを実行しないで、削除済みファイルに属するブロックがバックアップ内に残ることを容認するしかありません。

SDeleteを使用するもう1つのデメリットは、シンプロビジョニングで作成された仮想ディスクが肥大化するので、SDeleteによる処理後、VMware Storage vMotionなどの技術を使用して、それらを圧縮する必要があるということです。詳細については、VMware KB 2004155を参照してください。

最後に、これらのツールを使用するには、注意が必要です。SDeleteは、ゼロで埋められた非常に大きなファイルを作成し、そのファイルが一時的に、ボリューム上の使用可能な空き容量をすべて消費するので、他の本番アプリケーションに影響しないように十分注意する必要があります。

本来不要なファイルはバックアップしない

当然ながら、バックアップする必要のないファイルやディレクトリもあります。たとえば、アプリケーションログ、アプリケーションキャッシュ、一時エクスポートファイル、個人用ファイルを含むユーザーディレクトリなどがあります。また、特定のオブジェクトをバックアップから除外することを要求するデータ保護規則もあるかもしれません。ただし、これまで、大半のVMバックアップソリューションで不要なデータを除外するには、すべてのVM上の不要なデータを専用の仮想ドライブ (VMDK/VHDX) に手動で移動し、それらのドライブを処理の対象外にする方法しかありません。SDeleteの場合と同様、この方法も、毎日多数のVMが新たに出現する大規模な環境では実現不可能であり、ほとんどのユーザーは、イメージベースのバックアップでは不要なデータもバックアップしなければならないという現実を受け入れるしかありません。

Veeam BitLookerの概要

Veeam BitLookerは、Veeamが特許申請中のデータ削減技術であり、削除済みのファイルブロックや不要なファイルの除外を効率的かつ完全に自動化することができます。これにより、バックアップに必要なストレージ容量とネットワーク帯域幅を大幅に節約できるので、コストも削減することができます。

BitLookerがVeeam Backup & Replicationに導入されたのは数年前のことで、スワップファイルのブロックを処理から除外できるようになりました。各VMはスワップファイルを作成し、そのサイズは通常2GB以上で、毎日変更されることを考えると、これは、かなりの量のデータであり、フルおよび増分バックアップのサイズに大きな影響を与えます。そこで、BitLookerは自動的に、スワップファイルの場所を検出して、対応するVMDKにバックアップするブロックを決定します。この後、これらのブロックは自動的に処理から除外されて、ターゲット先のイメージではゼロで埋められたブロックに置き換えられ、バックアップファイルに保存されることも、レプリカ・イメージに転送されることもありません。その結果、当然データ量は削減されます。

v9のBitLooker

Veeam Backup & Replication v9では、データ削減率をさらに向上するために、BitLookerの機能が大幅に拡張されました。Veeam Backup & Replication v9では、BitLookerは次の3つの機能を提供するようになりました。

• スワップファイルおよびハイバネーションファイルの除外
• 削除済みファイルのブロックの除外
• ユーザー指定のファイルおよびフォルダの除外

v9のBitLookerは、NTFS形式のボリュームのみをサポートします。BitLookerのほとんどの機能は、Veeam Backup & Replication Standardエディションでも使用できますが、ユーザー指定のファイルおよびフォルダを除外するには、Enterpriseエディション以上が必要です。

BitLookerの設定

v9には、BitLookerを制御するためのオプションがいくつか用意されています。最初の2つは、各バックアップおよびレプリケーションジョブの詳細設定で設定することができます。

スワップファイルのブロックを除外するオプションは、これまでのバージョンでも使用できましたが、v9では機能が拡張され、ハイバネーションファイルも除外できるようになりました。

さらに、削除済みファイルブロックを除外できるオプションが新しく追加されました。

古いバージョンからアップグレードするユーザーは、アップグレードしても、既存のジョブに対しては、削除済みファイルブロックの除外がデフォルトでは無効になっているので、既存の動作は変更されないことに注意してください。この除外は、ジョブごとに手動で有効にするか、PowerShellスクリプトを使用して、すべての既存のジョブに対して自動的に有効にすることができます。このスクリプトの詳細については、ここをクリックしてください。

ほとんどの場合、削除済みファイルブロックの除外を有効にしても、バックアップファイルのサイズはそれほど削減されません。これは、大半のサーバーワークロードでは、データは削除されず、必ず新しいデータで上書きされるからです。多くの場合、これは、削除されたデータよりも多くのデータで置き換えられます。世界のデータが2年ごとにほぼ倍増しているのはまさにこのためです。しかし、一部のシナリオでは (たとえば、データの移行を必要とする場合など)、大幅に削減されます。ここをクリックして、すでにご使用のお客様からの報告をご確認ください。

最後に、v9では、BitLookerを使用して、バックアップジョブごとに、特定のファイルやフォルダの除外を設定することができます。今までのオプションとは異なり、この機能は、アプリケーション認識処理ロジックの一部であり、除外は実行中のVMでのみ実行することができます。このため、ファイル除外設定は、ジョブウィザードのゲスト処理ステップの詳細設定で設定することができます。特定のファイルシステムオブジェクトを除外するか、または反対に、特定のオブジェクト以外はバックアップしないことを指定するオプションがあります。

この機能を使用する場合、除外されるファイルの数に応じて、VMの処理時間とデータムーバーが使用するメモリ量の両方が増加することに注意してください。たとえば、10,000個のファイルの除外を処理するのにかかる時間は10秒未満で、必要とする追加RAMはわずか50MBであるとしても、100,000個のファイルを除外するのにかかる時間は2分となり、必要とする追加RAMは約400MBになります。

まとめ

Veeam BitLookerにより、ユーザーは、バックアップのストレージ容量とネットワーク帯域幅の使用量をさらに削減することができます。追加コストは必要ありません。この機能は、わずか数回のクリックだけで有効にすることができ、その直後に実行するバックアップまたはレプリケーションから、データ削減のメリットを享受することができます。

v9でBitLookerを有効にしたら、どんな成果が得られるでしょうか。ぜひ、実際の数字をコメントとしてお知らせください。

ハイパーコンバージドインフラストラクチャは現在、紛れもなくIT分野で注目の話題となっています。顧客は、コンピューティング、ストレージ、管理を含む完全な機能を備えた仮想化インフラストラクチャの構築に関心を寄せています。3月1日、Ciscoはサンディエゴで開催したCisco Partner Summitで新しいハイパーコンバージドソリューション、Hyperflexを発表しました。このソリューションはCisco UCSテクノロジーをベースとして、1つのクラスタ内および1つの管理インスタンス内のノード全体で、仮想化されたSANおよびコンピューティングリソースを活用するユニークな方法を提供します。HX220cおよびHX240cノードでハイパーコンバージドシステムを構築し、動的かつ柔軟に拡張して要件を満たすことができます。

Cisco Hyperflex向けの効率的で拡張性の高いバックアップ

Veeam Availability Suite v9はAlways-On Enterpriseの要件を満たす、可用性とモニタリングを組み合わせたソリューションを提供します。Veeam Backup & Replicationは、災害時やデータ消失時にすべてのアプリケーションおよびデータについて目標復旧時間(RTO)と目標復旧ポイント(RPO)、つまりRTPOを15分未満に短縮します。また、Cisco UCS C240またはC3260で構築される、Ciscoの新しいVeeam向けBackup & Replicationアプライアンスは、Starter、MediumおよびLarge構成から選択可能で、Cisco Hyperflex環境の完全なデータ保護を容易に提供することができます。

Veeamは、以下のような強力で効率的な仮想マシン(VM)バックアップ機能、高速で柔軟な復元機能、および高度なVMレプリケーション機能をCisco Hyperflexに提供します。

高速かつ信頼性の高いイメージベースのバックアップ機能は、エージェントを使用することなく、より短いバックアップウィンドウを実現しバックアップおよびストレージのコストを削減できます。

インスタントVMリカバリは、最も必要とされるシステムの可用性を維持するのに役立ちます。インスタントVMリカバリは、VMをバックアップ ファイルから直接起動することにより、ユーザーを何時間も待たせることなく、VMを本番環境に迅速にリストアします。

Veeam Explorerは、アプリケーションのバックアップを即時に可視化し、個々のアイテムのきめ細かなリカバリを実行する画期的な技術を提供します。

SureBackupは、分離されたVirtual Lab環境でVMを自動的に起動し、すべてのバックアップ、すべてのVMのリカバリ可能性を常に自動的に検証し、一連のテストを実行した後、ユーザーのメールボックスにステータスレポートを送信します。これにより、VMの復元が可能であるかどうかをいつでも知ることができます。

VeeamによるCisco Hyperflexの災害復旧対策

Veeamは高度なイメージベースのVMレプリケーションと合理化された災害復旧(DR)を提供することで、ミッションクリティカルなアプリケーションの可用性を確保します。Veeamはすべてのアプリケーションおよびデータについて15分未満のRTPOを達成します。

さらに、Veeam Backup & ReplicationはレプリケートされたCisco Hyperflex VMおよびデータをセカンダリサイトで活用するための機能も提供しています。

Veeam Availability Suiteについての詳細はVeeamの製品ページをご確認ください。

VeeamとCiscoバックアップアプライアンスの詳細について、ご確認ください。

アプリケーションの可用性を高めるため、どの企業でも、その規模に関係なく、ディサスタリカバリー（DR）のためのセカンダリ・サイトを持つ必要があります。最新のテクノロジーにより、プライマリ・サイトに問題が発生しても、セカンダリ・サイトにおいてワークロードを処理する機能がただちに提供されます。

これまでDRサイトは、さまざまな理由から大規模企業のみを対象としたソリューションでした。ところが、 ディサスタリカバリー・サービス（DRaaS）のような、新たなテクノロジーやサービスのおかげで、DRサイトは企業の規模に関係なくアクセス可能で、コスト効率の高いものとなっています。

仮想化の普及

ディサスタリカバリー・ソリューションが爆発的に拡大した主な要因が仮想化であることは間違いありません。これまで、データとアプリケーションをセカンダリ・サイトにレプリケーションすることは、ストレージ・アレイの機能を利用することでしか実現できず、すべてのソリューションにネイティブのレプリケーション機能が備わっているわけではありませんでした。その上、ストレージ層でのレプリケーションには2つの落とし穴があります。

1. テクノロジーの観点からすると、ストレージ層のレプリケーションでは、両方のサイトで同一モデルまたは同一ブランドのストレージを採用する必要があります。これは、各レプリケーション・テクノロジーが独自のものだからです。このことは、プライマリ・サイトと同じ規模や性能のセカンダリ・サイトを作ることができる大規模組織では問題にはなりません。しかし、中小規模の企業には、プライマリ・サイトとセカンダリ・サイトの両方に同じ予算を投資するための十分な資金やメリットがありません。中小規模企業にはもっとコスト効率の高いソリューションが必要です。
2. ストレージ層でのレプリケーションは、レプリケーション・ポリシーを細かく調節できるだけの粒度がありません。ストレージ・アレイは、ホストするワークロードを考慮していません。データベースとファイル・サーバーの両方が同じ場所に格納されている場合、これらは同じポリシーを用いてレプリケートされます。このため、管理者がワークロードを別々の格納場所に分けない限り、異なるワークロードのために異なるポリシーを作成し、異なるRPOとRTOを取得することは困難です。ただし、ワークロードを別々の格納場所に分けると、追加のオーバーヘッドが発生し、さらなる管理、監視、ITリソースが必要となります。

一方、仮想化は、レプリケーション・サービスのアクセス、構成、使用を容易にし、2つの主要な落とし穴を排除できます。仮想化の場合、管理単位が巨大で扱いにくいストレージ・アレイから柔軟性の高い個別の仮想マシンに変わるため、ワークロードごとに個別のRTOとRPOを定義することができます。IT管理者は、特定のワークロードを優先したり、後回しにしたりできます。たとえば、重要なデータベース・サーバーについてはほぼ連続（15分おき）で、ファイル・サーバーについては1時間ごとまたは1日に1回、セカンダリ・サイトにコピーを作成するというようなレプリケーション・ソリューションを構成できます。仮想化はハードウェア層を抽象化し、より細やかなレプリケーション制御、結果の最適化、より効率的なITリソース利用を可能にします。

セカンド・サイトの必要性

ディサスタリカバリー（DR）は、今日のデータ・センターの可用性を高める重要なソリューションです。そして、DRは仮想化と最新のレプリケーション・テクノロジーを利用し、仮想マシンのレプリカをオフサイトに作成することで可用性を高めます。

しかし、エンド・ユーザーがDRサイトの計画を開始する場合、他の問題に直面します。まず、セカンダリ・サイトを構築、維持するコストが多くの組織にとって課題となります。セカンダリ・サイトでは、自己所有かレンタル（例：共用施設）かを問わず、本番環境の規模に応じて新しくハードウェアとソフトウェアを展開する必要があります。そして、セカンダリ・サイトも構成、管理しなければならず、ITインフラストラクチャに費やす労力が事実上2倍になります。しかも、本番ワークロードはほとんどプライマリ・サイトで実行されるため、セカンダリ・サイトはほとんど使用されません。このため、必要なコストはその価値と比較して高くなり、経営陣にROIをアピールしにくくなります。

これまでは、大規模な企業だけしか専用のセカンダリ・サイトを持つのに必要な予算を確保できませんでした。つまり、大企業は、各サイトの設備やリソースを活用するためのITスタッフがいるオフィスをすでに複数保有していたのです。ただし、今日では大規模な企業であっても、DRサイトを維持しながら、資金や経費を削減する方法を模索しています。

ディサスタリカバリー・サービス（DRaaS）

これは、クラウド・ベースのソリューションが完全に適合する状況の1つであり、DRaaS（Disaster Recovery as a Service）がますます普及している理由です。従量課金制のサービス・プロバイダからリソースを借りることにより、エンド・ユーザーは、日々のDRサイトを設計、展開、管理するコストと負担を負わずに同じ結果（フェールオーバー時に利用できるCPU、RAM、ストレージ、ネットワーキング・リソース）を得られます。DRに専門家を配置しているサービス・プロバイダは、インフラストラクチャの包括的な管理を行います。代わりにサービス・プロバイダは、提供するサービスの品質に関するSLA（Service Level Agreement）を提供します。仮想化のおかげで、サービス・プロバイダは、異なるワークロードに対して別のSLAを提供することも可能です。

これにより、エンド・ユーザーはレプリケーション処理に専念したり、アプリケーションに必要となる、異なるRPO値を計画したり、そしてITニーズではなくビジネスの基準を用いたDR戦略やDRソリューションを定義したりすることが可能となります。

DRaaSの需要が高いのは不思議ではありません。実際に、Google Trendsのグラフを見てわかるとおり、DRaaSの人気が拡大しています。

「Disaster Recovery」という語句で検索した場合、DRのみの需要は縮小傾向にあることがわかります。

これは、顧客が一般的なソリューションを検索しているのではなく、サービス・プロバイダが提供するDRaaSを特に探している兆候を示しています。

おびただしいほどの数のソリューションが市場に提供されているのが印象的です。DRaaSソリューションを求める企業は、企業規模に関係なく、サービスに付随するオプションを注意深く評価する必要があります。一部のオプションについて検討してみましょう。

1.使いやすさ

使いやすさは、DRソリューションでは見過ごされやすい特性です。提供されるテクノロジーの強力な機能に焦点を合わせてしまいがちですが、テクノロジーが複雑すぎて、設定も使用も困難であれば、非常に危険な事態に陥ります。約束されているROIは達成困難になり、ビジネスに付加される価値は限定されます。一方、使いやすいソリューションはテストも採用もすばやく行うことができ、労力も抑えられます。最も重要なことは、エンド・ユーザーは、常にチューニングしたり、問題を解決したりしなくても、サービスを利用している間、「機能する」テクノロジーの恩恵を受けられることです。

その他に見過ごされやすい点として、DRシナリオの間、IT従事者は直面する問題、経験したダウンタイム、そしてすばやい運用再開を求める経営陣からのプレッシャーからストレスを受けることが少なくありません。使いやすいソリューションの場合、セカンダリ・サイトでアプリケーションを再起動するのに必要ないくつかの簡単な手順で済みますが、複雑なソリューションではストレスのかかる状況で問題がさらに複雑化します。

Veeamのクラウド・テクノロジーである、Veeam Cloud Connectを経由したVMレプリケーションは、ユーザーが選択したサービス・プロバイダへの安全で信頼性の高いSSL/TLS接続によって、保護された単一のTCPポート接続で使いやすく設定も簡単です。VPN接続のセットアップや保守は必要ありません。また、ユーザーのファイアウォールで複数のポートを開く必要もありません。レプリケーション管理トラフィック、実際のVMデータ転送、そして、部分フェールオーバー時のVM間通信といった、あらゆる種類のトラフィックに単一のトンネルが使用されます。すべての通信は、単一のトンネルにカプセル化されています。接続が確立されれば、追加でネットワークの設定をする必要はありません。

2.ネットワーク構成について

DRaaSは主にレプリケーション・サービスを提供するために設計されていますが、レプリケーションだけでは十分ではありません。実際に、DRサービスで最も難しいポイントの1つが、レプリケーションではなくネットワーク構成です。アプリケーションには固有のネットワーク設定があり、今日のサービスの多くは、従業員やサプライヤ、顧客が消費するため、インターネットに公開する必要があります。仮想マシンをレプリケートし、DRサイトでそのマシンを稼働させることは比較的簡単ですが、構成が変更された場合にネットワークが正しく設定され、自動的に再プログラムされることを保証するのは容易ではなく、これを保証することが当たり前とされることが少なくありません。DRaaSソリューションを探す場合、エンド・ユーザーはこの領域におけるDRaaSソリューションの機能が明確になるように具体的な質問をする必要があります。透過的な形でプライマリ・サイトとセカンダリ・サイトの間でシームレスにアプリケーションを移動できるかどうかには、フェールオーバー時におけるアプリケーションの再設定にかかる時間を除き、コストはかかりません。

3.セルフサービス

セルフサービスは、どのクラウド・サービスにとっても最重要で、DRaaSも例外ではありません。サービス・プロバイダはどれくらいの数のオペレーションを自動化できるでしょうか。これはサービス・プロバイダにとってのみ重要に思えますが、自動化されたサービスとは、エンド・ユーザーがサブスクリプションの変更をすばやくリクエストしたり、サブスクリプションをDRaaSサービスに合わせてすばやく簡単に調整したりできることを意味します。サービス・プロバイダが変更のリクエストを処理するのに何時間や何日もかかるのであれば、クラウド・サービスを利用する価値はありません。

セルフサービスも、サービス・プロバイダに何かを問い合わせたりしなくても、自身で実行できるオペレーションの数に関係するのは明らかです。最終的に、サービス・プロバイダは基盤となるインフラストラクチャを維持する責任を担いますが、企業のデータとワークロードに関するオペレーションはその企業が担う可能性があります。

これには、単純ですが大きな理由があります。エンド・ユーザーは、サービスをどう設定するか、または必要なときにどう再設定するかを正確に知っています。

ただし、セルフサービスにもフェールオーバー時にダウンタイムを短縮する大きな価値があります。エンド・ユーザーのサイトに何か大きなことが起きた場合、ユーザーは選択したサービス・プロバイダのセルフサービス機能を活用し、サービス・プロバイダのサポート・チケットを開く時間を費やさずに、フェールオーバーをすばやく開始できます。

まとめ

DRaaS（Disaster Recovery as a Service）は人気が拡大しており、多くのサービス・プロバイダが異なるテクノロジーを用いてこのタイプのサービスを提供しています。顧客は、提供されているすべてのソリューションを見るとどれを選択したらよいかわからなくなる可能性がありますが、同じソリューションばかりではなく、提供されるオプションに価値が存在しています。

Veeam Cloud Connect Replicationを使用するサービス・プロバイダはこの記事で取り上げた各利点を保証できます。エンド・ユーザーに必要なのはVeeam Availability Suite v9をインストールまたはアップグレードし、Veeamに対応するDRaaSプロバイダに加入してVeeam Cloud Connectの利用を開始するだけです。

VeeamのDRaaSソリューションの詳細については、下記のリンクを参照してください。

• Veeam Cloud Connect
• VeeamによるDRaaSの定義
• Veeam Cloud Connect Replicationによるクラウドベースのディサスタリカバリー（英語）

あらゆる規模の企業にとって仮想化がすでに新しい標準となっている一方で、依然として、物理的なサーバー・インフラストラクチャも広く使用されています。従来からある物理サーバー・ネットワークを使用し続けることは、コストの浪費なのでしょうか。この記事では、その理由を詳しくお伝えします。

はじめに、物理サーバーがプラットフォームとして順当な選択肢だった頃の状況から見ていきましょう。物理サーバーで構成されたアーキテクチャは非常に明白で、メモリ、ネットワーク、CPU、ストレージといったリソースが各サーバーのハードウェア上に搭載されています。このハードウェアにはサーバー・オペレーティングシステムがロードされ、各種アプリケーションはOSから実行されます。非常にシンプルですね。

仮想インフラストラクチャの場合も、同じ物理サーバーにすべてのリソースが搭載されていますが、サーバー・オペレーティングシステムの代わりに、vSphereやHyper-Vなどのハイパーバイザーがロードされます。仮想マシンを作成するのはこのハイパーバイザー上です。図から分かるとおり、1つひとつのVMに固有の仮想デバイス(仮想CPU、仮想メモリ、仮想ネットワーク・インターフェイスカード、仮想ディスク)が含まれます。この仮想ハードウェアに対して、ゲスト・オペレーティングシステムと従来からあるサーバー・アプリケーションをロードします。

仮想化によるメリットは明白です。サーバーごとに1つのアプリケーションだけをロードするのではなく、複数のゲスト・オペレーティングシステムと少数のアプリケーションを同じ物理ハードウェアで実行できるため、同じコストで非常に多くの成果を得ることができます。

ハードウェアに依存しない、可搬性の高いVM

同じハイパーバイザーが実行されていれば、物理マシンが異なっていても仮想マシンを移行できるのはなぜでしょうか。前述のとおり、仮想マシンにはそれぞれ固有の仮想ハードウェアが含まれています。このため、VM上にロードされるゲスト・オペレーティングシステムが認識するのはこのハードウェア構成だけであり、物理サーバーは認識しません。言い換えると、VMはハードウェアにまったく依存していません。つまり、VMにインストールされたオペレーティング・システムは特定のハードウェアに関連付けられていないため、仮想マシンを別の物理サーバーに移行できるだけでなく、別のデータセンターへも移行できるのです！

このように、VMには完全な可搬性が備わっているため、フラッシュ・ドライブにコピーして、自宅へ持ち帰ってホーム・ラボにレプリケートしたり、友人にプレゼントしたり、顧客に送付したりすることができます。さらに、仮想マシンのレプリケートは、WAN経由やインターネット経由でも実行できます。

その他の仮想マシンのメリット

すでにお話ししたように、仮想化のおもな特長の1つは仮想マシンの可搬性であり、これはハードウェアに依存しないことで実現されています。そのため、VMはどこでも好きな場所に簡単に移行できます。バックアップしたVMを別のサーバーにリストアしたり、フラッシュ・ドライブに保存してホーム・ラボやワークステーションで実行したりするだけでなく、別の場所に持っていくことも可能です。しかし、それだけではありません。ハードウェアに依存しない高い可搬性によって、このほかにも多数の便利な機能が提供されます。

• VMware技術の1つであるvMotionが提供するVMの可搬性およびハードウェアからの独立性により、エンドユーザーに対するダウンタイムなしで、実行中のVMを別のサーバーに移行することができます。
• VMware技術の1つである分散リソース・スケジューラ(DRS)は、リソース消費の面から仮想インフラストラクチャの負荷を分散します。DRSは(vMotionを使用して)実行中のVMを別のホストに移行することで、必要なすべてのリソースが効果的に動作するようにします。
• VMware High Availability (VMHA)は、障害が発生したサーバーから別のサーバーにVMをリストアすることで、瞬時に実行状態に戻すことができるオプションです。
• VMwareの機能である分散電源管理(DPM)は、電力コストの削減に役立ちます。この機能を使うことで、インフラストラクチャが消費する電力を容易に抑制できます。DPMは、仮想インフラストラクチャによるリソース消費が少ない場合、より少数の物理サーバーにVMを統合します。必要ないサーバーはすべて停止されます。
• 仮想化により、障害復旧も大幅に簡素化されます。VMはハードウェアに依存せず、ゲストOSは特定のハードウェアに関連付けられていないため、VM内の仮想インフラストラクチャに障害が発生した場合も、バックアップしたVMを任意のサーバーで実行するだけで復旧が完了します。

しかもこれは氷山の一角にすぎず、従来の物理サーバー・ベースのインフラストラクチャに欠如していた高い機能が、仮想マシンには多数搭載されています。仮想化による優れた新機能を最大限有効に活用するためには、監視、管理、データ保護に正しいツールを使用する必要があります。仮想マシンは物理サーバーとは大きく異なるため、物理サーバー向けのツールは適しておらず、特にバックアップに関してはなおさらです。

引き続き物理ソリューションを必要とするお客様に対しても、Veeamは情報を提供しています。

• Veeam Endpoint Backup FREEは、物理マシン向けのバックアップ製品です。Veeam Forumでは、物理サーバーのリストアやリモートのエンドポイント・バックアップに関して、Veeamエンドポイント・ユーザーによる有益な情報の交換が常に行われています。Veeamのエンドポイント・コミュニティに是非ご参加ください。

The post 仮想マシンと物理サーバーの違い appeared first on Veeam Software オフィシャル ブログ.