何が「ベスト」プラクティスなのかを決めようとすると、たくさんのことを考慮する必要があります。確実にわかっているのは、Gostev氏のプレゼンテーション「VT-466 VMware Backup Best Practices: 2015 Edition」には、耳を傾けるべきものがあるということです。これはVeeamON 2014および2015で最も人気のあるセッションの1つでしたし、2017年版ではどのような内容になるか、待ち切れない思いです。
そこで、昨年のこのセッションからいくつか主要なポイントをこのブログ・シリーズで公開し、VeeamON 2017に向けて知識の共有と向上に役立てることにしました。また、Veeam Availability Suite v9.5に関する今後の発表にはvSphere環境の可用性を向上する新しい機能が含まれますのでご期待ください。
Veeamバックアップ・サーバーのベスト・プラクティス
Veeam Backup & Replicationをインストールするバックアップ・サーバーは、主要な役割を果たします。この重要なコンポーネントを快適に使用するためのヒントをいくつかご紹介します。VMware環境におけるバックアップ・サーバーのベスト・プラクティスのいくつかを以下に示します。
- バックアップ・サーバー上のプロキシおよびリポジトリの役割を無効にする。非常に小規模な環境ではそれらの役割を兼ねることも有効ですが、規模を問わず、バックアップ・サーバーには、実際のバックアップ処理をさせるのでなく、ジョブや他のコンポーネントの管理をさせるようにします。
- v9より1つのバックアップ・サーバーあたり100ジョブという制限を解除。これにより、1台のバックアップ・サーバーに多数のジョブや設定を集中管理させることが可能になります。
- サーバーあたり2-3,000台までのVM管理が適切。ハード面でもソフト面でも制限はありませんが、1つのコンソールで管理可能なVM数は、最大2-3,000台までの規模になります。ただし、サイト数、セキュリティ・ゾーン数、ビジネス要件の数など、技術以外の他の要因でより多くのサーバーが導入されることもあります。
- バックアップ・サーバーには十分なメモリを割り当てる。これらの要件はVeeamヘルプ・センターに記載されています。覚えておくべき重要事項は、RAMは4GBがベースで、1つの同時ジョブごとに500MB RAMを追加します。さらに、バックアップ・サーバー上で他のサービス（プロキシ、リポジトリ、WANアクセラレータなど）が実行される場合、それらメモリ要件も追加してください。
Veeamバックアップ・サーバーのインストール先は物理マシンか仮想マシンか。
物理バックアップ・サーバーにするか仮想バックアップ・サーバーにするかの判断には多くの議論があります。ここでも、どちらか一方をお勧めすることは非常に困難です。Veeamバックアップ・サーバーの物理と仮想それぞれの利点を以下に示します。
| 物理サーバーの利点 | 仮想サーバーの利点 |
| あらゆる災害復旧（DR）ソリューションにおけるベスト・プラクティス：DRシステムがシステムに依存するのはよくありません。システムを保護し、復旧するためのものだからです。 | 100%仮想化されたデータセンターを実現します（あるいはそれに近いものを実現します）。 |
| 構成情報のバックアップまたはリモートSQLサーバーを使用してデータを保護します。 | より多くの保護オプション：VeeamではVM（バックアップ・サーバーVM自体）をバックアップまたはレプリケートできます。 |
| Veeam Endpoint Backup FREEをインストールしてVeeamバックアップ・サーバーを保護します（完全なバックアップ・イメージが必要な場合）。 | DR計画を入念に考え、徹底的に検証できます。 |
vSphere Clusterが1つだけの場合、これまでは物理のVeeamバックアップ・サーバーをお勧めしてきました。上の理由に加えて、物理バックアップ・サーバー（プロキシ、リポジトリなどを含む）の利点は、バックアップ中のvSphere DRSの影響による「負荷の偏り」を回避できることです。実際のバックアップを実行するには大量のCPUやRAMが必要になる可能性があるため、CPUやRAMの観点から他に影響を及ぼすことなく実行し、不必要なvMotionを回避できるなら、それはメリットになります。
複数のvSphereクラスタから成る環境では、自身で自身のクラスタ環境を管理するのではない限り、仮想化されたバックアップ・サーバーは有効な選択肢になります。例えば、ある仮想化されたバックアップ・サーバーがクラスタAをバックアップしている場合、クラスタB上で稼動する必要があるということです。言い換えると、クラスタBにある仮想化されたバックアップ・サーバーはクラスタAのバックアップを管理できます。
バックアップ・サーバーの依存関係
バックアップ・サーバーをどこに配置するかは最高水準の可用性を実現するという点から決定するのと同様に、適切な依存関係についても同じことが言えます。依存関係に起因する問題点を避けるためのベスト・プラクティスを以下に示します。
- 依存関係についてよく検討する。VMware環境をよく調査し、リストア時に必要なものが欠如しないようにします。また、予測できない依存関係を識別するには、他人に意見を求めてみます。
- DR検証の実行。言うまでもなく、Veeam Availability Orchestratorをリリースする計画がありますが、そうではなく、異なる場所でバックアップ・サーバーを使用してみると、不足する項目に気付かされます。
- ローカル・アカウント。Active Directoryが存在しない環境でリストア作業を行う場合は選択肢となります。
- SQL認証。上と同様の理由で、Active Directoryが存在しない場合、バックアップ・サーバーのデータベースをホスティングするSQL Serverにアクセスできないことがあります。
- ワークグループかドメインか選択。保護対象のセキュリティとインフラストラクチャの観点から、完全に分離されたActive Directoryの「管理ドメイン」が存在する場合、そのドメイン・アカウントを使用することをお勧めします（前述の2つのポイントを含む）。Active Directoryドメインが1つだけで、それをVeeamがバックアップしている場合、バックアップ・サーバーのVeeam構成に対してワークグループ資格証明を使用するのがより適切です。そうしないとドメインが依存関係になるからです。
- 再び物理サーバーと仮想サーバーの議論について。上記の点を検討することで依存関係が明らかになることがあります。また、物理サーバーの選択が幅広い同意を得られるのはそのためです。
バックアップ・サーバー配置のベスト・プラクティス
複数のバックアップや特にレプリカを使用する環境では、バックアップ・サーバーの配置場所について数多くの要因が関係します。一般に、バックアップ・サーバーは、バックアップ対象のVMと同じサイトに配置することをお勧めします（特にvCenter Serverがそのサイトにある場合）。それは、WAN経由のvCenter通信は遅くなる場合があるからです。
災害復旧に関しては、本番サイトにバックアップ・サーバーがあるのが適切です。これは、DR実行時はレプリカにフェール・オーバーすることを意味し、レプリケートされたVMの目標復旧時間（RTO）は非常に短くなります。フェール・オーバーを管理する2台目のバックアップ・サーバーがDRサイトにあればさらに適切です（後述）。
レプリケーションを使用する場合、バックアップ・サーバーをDRサイトに配置し、このサーバーにレプリケーション・ジョブを管理させることをお勧めします（ただし、ここでも要件と依存関係に注意してください）。これにより、本番サイトが停止した場合でも、確実にワンクリック・フェール・オーバーが可能になります。さらに、レプリカの目標復旧ポイント（RPO）は実質バックアップより短くならないため、RPOには影響がありません。
もう一点、本番サイトでバックアップ・サーバーを仮想化する場合、他のあらゆるVMと同様に、DRサイトにレプリケートできることに注意してください。バックアップ・ファイルそのものが心配な場合は、バックアップ・コピー・ジョブが役に立ちます。それについてはこのシリーズの別の記事で取り扱います。
これからもこの記事のシリーズにご注目ください。それまでの間、このブログを補うのに役立つ情報を次にご紹介します。
関連するその他の製品・ソリューションはこちら
VMware、Hyper-Vなどの環境に不可欠な無償のバックアップソリューション「Veeam Backup & Replication Community Edition」。製品概要や新機能、エディション比較はこちら。
高速かつ安全な方法で、仮想マシンや物理ワークロードをクラウドにバックアップし、レプリケート、リストアすることができる「Veeam Cloud Connect」。製品概要や成功事例はこちら。
バックアップを含むAWS内での重要なデータの移行、管理、保護、復元を支援する「Veeam for Amazon Web Services」。製品概要やビデオガイド、 成功事例などはこちら。
