本シリーズの2回目となる今回の記事では、VMwareバックアップ・プロキシについて取り上げます。VMwareバックアップ・プロキシはバックアップ・インフラストラクチャの真の主力機能であるため、多くの読者の皆様が興味を持たれることでしょう。
VMwareバックアップ・プロキシのベスト・プラクティス
最初の質問は、「プロキシを何台準備すればいいのか。」ということでしょう。普及しているロジックでは、配置されるプロキシが多いほど、パフォーマンスと配分効率が向上するとされています。しかし、バックアップによるI/O負荷 が掛かる点に気をつける必要があります。そうしなければ、プロキシによるプライマリ・ストレージに対するパフォーマンス低下のリスクが生じます。反対に、小規模の環境では、リポジトリの基本的なスロットリングや接続数制限により、プロキシによるデータ転送が制限されることがあります。以下の図は、プロパティ内のリポジトリの制御設定を示しています（リポジトリについては本シリーズの次回の記事でより詳しく取り上げます）。
VMwareバックアップ・プロキシのCPUとRAMの使用量はバックアップ・ジョブ内の圧縮設定に大きく左右されます。一般的に言えば、バックアップ・ジョブで設定されているデフォルトの圧縮レベル（最適）の設定を維持するか、またはプロキシにリソースを追加できるようにしておくことをおすすめします。また、レプリケーション・ジョブのターゲットとなるプロキシでRAMの使用量を確認しておくことも重要です。
転送モードについて
転送モードといえば、リストア専用として、クラスタごとに1つのセカンダリ・ホットアド・プロキシを用意するのもよいアイデアです。これは、リストアを行う必要がある際に、同時にバックアップも実行する可能性があることを考えると、非常に重要なことです。バックアップ用に必要なプロキシの数を策定したものの、同時にリストアを行わなければならない場合、そのタスクを行うためにより多くのリソースと接続が必要になりますが、リストアを行うためにバックアップ・ジョブを中止したり遅延させたりはしたくないためです。
転送モードに関して、Veeam VMwareバックアップ・プロキシには次の4つの選択肢があります。
- 自動
- ダイレクト・ストレージ・アクセス
- 仮想アプライアンス（ホットアド）
- ネットワーク（NBD）
ダイレクト・ストレージ・アクセス転送モード
プロキシがデータを転送する方法は、プロキシのプロパティを設定し、その後、各ジョブで1つまたは複数のプロキシを使用するように設定することができます。ダイレクト・ストレージ・アクセスではDirect SANアクセスまたはVeeam独自のDirect NFSアクセスが使用されるため、一般的には、ダイレクト・ストレージ・アクセスが推奨されます。プロキシに関するVMwareのDirect SANアクセスのヒントを次にいくつか示します。
| 利点 | 欠点 | 注意点 |
| 最速のバックアップおよび完全なVMリストア（ストレージ・スナップショットからのバックアップを除く）。 | ファイバー・チャネル接続に物理のバックアップ・プロキシ・サーバーが必要であり、仮想化の取り組みに反する。ただし、iSCSI SANではVMがサポートされる。 | バックアップ・プロキシのローカル管理者権限を自分のままにしておく。 |
| ホストと本番ネットワークへの影響がゼロ。専用のバックアップ・プロキシがSAN経由でデータを直接取得し、バックアップのトラフィックはSANファブリックに分離される。 | 初心者には設定が難しく、構築は容易ではない。よくある失敗は、MPIOのセットアップ、HBAの誤動作、最適化されていないRAIDキャッシュなど。 | ボリュームの再署名に対する懸念（ほとんど発生しないし、Veeamのセットアップでは予防措置が講じられている）VMFS LUNをバックアップ・プロキシに読み取り専用として表示する。 |
| 直接のデータ・パスにより、最も高い信頼性を備える。 | Thin Disk構成のバックアップからのリストアが、Thick Diskに変換される（但し、リストア時にホットアド構成のプロキシを使用する事で、Thin Diskでのリストアは可能） | まだボリュームの再署名に懸念がある場合、グループ・ポリシーでディスク管理スナップインを無効にすることにより誤操作を防止。 |
Direct SANアクセスのその他のベスト・プラクティスには以下が含まれます。
- 少ないCPUで多くのプロキシを持つか、多くのCPUで少ないプロキシを持つか選択する場合、物理的なフットプリントが削減されるため、多くのCPUで少ないプロキシを選んでください
- 新しいストレージ・プロビジョニング・プロセスの一環として、すべての新しいLUNをバックアップ・プロキシにゾーン毎に追加することに留意してください。そうしないと、バックアップ・ジョブが別のモードにフェール・オーバーします。
- データストアを手動でプロキシに割り当ててください。
- ストレージ・スナップショットからのバックアップまたはDirect NFSを使用できる場合は、Direct SANアクセスを使用しないでください。
- Direct SAN経由でリストアする場合、ストレージ・レベルでシン・プロビジョニングの実行中はシック・ディスクを使用してください。
- MPIOソフトウェアを更新してください（MPIOを無効にするとパフォーマンスが向上する可能性があります）。
- プロキシやホスト全体で、ファームウェアとドライバを更新してください。
- ご利用環境の最適なRAIDコントローラ・キャッシュ設定を指定してください。
- iSCSIを使用している場合は、ネットワーク・パフォーマンスを向上するために、こちらのVeeam Forumをご確認してください（VddkPreReadBufferSizeDWORD値および Netshの調整）。
ストレージ・スナップショットからのバックアップに対応していないNFS環境の場合でも、Direct SANアクセスを使用してください。Direct SANアクセスは高度に最適化され、VeeamのNFSクライアントの真の2世代目と言えます（Direct SANアクセスは2014年のNetApp統合によって実際に「誕生」しました）。
ホットアド転送モード
ホットアド転送モード（仮想アプライアンス・モードとしても知られる）は、プロキシが仮想化されている場合にのみ利用できます。セットアップが簡単という特徴のほか、Veeamバックアップに対して、以下のような特質も備えます。
| 利点 | 欠点 |
|---|---|
| バックアップのための高速な直接ストレージにアクセスできるが、ESXi I/Oスタックを経由する。 | プロキシがvSphereクラスタ上のリソースを消費する（vSphereライセンスの追加を含む）。 |
| 従来型の高速な完全VMリストアを提供する。 | ホットアド・プロセスは、実行時の構成変更により起動が遅く（VM毎に1～2分）、それが累積することがある。 |
| vSphereのあらゆるタイプのストレージをサポートする。 |
バックアップ・プロキシ・サーバー自体の仮想マシンをバックアップする場合、その仮想マシンについてはCBTが無効になる。（通常のバックアップ対象の仮想マシンについては、CBTは引き続き利用可能） |
| 既存のWindows VMをプロキシとして使用し、ライセンスを節約することができる。 | スナップショットの統合が必要であったり、非表示のスナップショットの最大の原因である。 |
| 仮想化率100%に役立ち、オールインワン型インストールの優れた選択肢（ROBO）となる。 |
NFS環境ではホット・リムーブ時に無応答となる確率が増加する。
|
ローカル・ストレージ・クラスタのホットアド・プロキシにおいて、最高のパフォーマンスを得るには、ホストごとに1つのプロキシが推奨されます（ホットアドはオプションとして利用できます）。共有ストレージ・システムを使用中の場合、クラスタ内に少なくとも1つのプロキシがあることが推奨されます。
ネットワーク転送モード
ネットワーク・モードは、どんな状況でも動作するため、非常に万能なモードと言えます。上述のそれぞれのモードのように、ネットワーク・モードにも考慮すべき特性があります。ネットワーク・モードの利点と欠点は以下のとおりです。
| 利点 | 欠点 |
|---|---|
| 最も簡単なセットアップ。実際にはセットアップは不要。何もしなくても、きちんと機能する。 | ESXi管理インターフェイスを利用する。 |
| 物理マシンと仮想マシン共にインストールをサポートする。 | 管理トラフィックに影響する可能性がわずかにある。 |
| データ転送の初期化を高速に行えるため、わずかな変更率でVMをバックアップするのに理想的。 | 管理インターフェイスはvSphereが制御。 |
| 仮想化率100%を実現。 | 特にNFSの場合、1Gbイーサネット上では非常に遅い。 |
| 10Gbイーサネットのネットワーク上ではかなり高速になることもある。 | バックアップおよびリストアの場合、通常は最高10～20MB/秒。 |
バックアップとリストアに関するネットワーク・モード転送のヒントは、ほかにも多くあります。最も有用なヒントは以下のとおりです。
- 一般的に、ネットワーク・モードは10GBイーサネットでの使用が推奨されています。
- 小規模のサイトや変更率の低い静的なデータ・セットに最適です。
- ジョブ内で特定のプロキシを指定し、予期しないプロキシが選択されないようにすることができます。
- ジョブのプロキシ・セットアップにおいて、ILB（内部負荷分散）ロジックの転送モードに留意してください。ネットワーク・モードを使用するように明示的に設定されたプロキシの優先度は一番低くなります。
- ネットワーク・モード（特に1Gbを経由）で、プロキシの設定を（前のヒントのように）完全なVMおよびフル・ディスクのリストアとしてホットアド・プロキシに固定するのは適切ではありません。
以上が、v9のプロキシの最も重要なベスト・プラクティスをまとめたものです。本シリーズのさらなるブログ記事をお楽しみに。追加の記事が投稿されるまでの間、このブログ記事を補完するため、いくつか記事をご紹介します。