Ver9新機能予告「複数拠点向け機能とテープ機能の強化」Veeam Backup & Replication

投稿日: 2015年8月7日 作成者: climb
このエントリーをはてなブックマークに追加
LINEで送る

Veeam Backup & Replication V9では複数拠点を持つようなエンタープライズ環境やテープへのバックアップをより便利にするような機能が多く実装予定です。

今回はこの中から特徴的なものをご紹介いたします。

ゲストOS静止用プロキシ
Veeamでは負荷分散や複数拠点でのバックアップでも効率的に処理が可能になるよう、プロキシというコンポーネントを実装しています。これにより、一つのVeeamバックアップサーバで、効率的なデータ処理を実現しています。
また、Veeamはエージェントレスなソリューションであるため、このアプリケーション対応のイメージ処理ではVMに対して一時的にランタイムなプロセスをデプロイします。このプロセスはログの切り捨てやインデックス作成といったアプリケーション固有の静止点作成処理を担当しています。
しかし、Ver8まではこのゲストOS上のアプリケーションの整合性まで保証する「アプリケーション対応のイメージ処理」についてはVeeamバックアップサーバから処理を行っており、特にプロキシから処理は行っていません。このVeeamバックアップサーバからの「アプリケーション対応のイメージ処理」はネットワークもしくはVIX APIを使用して、直接ゲストOSに作用していました。この実装自体は完全に機能していますが、保護対象の環境の規模や複雑さにより以下の限界が明らかになりました。

  • スケーラビリティ
    ゲストに対する処理はVeeamバックアップサーバから実施されますが、保護対象のVM数がとても多くなってくると、このゲストに対する処理がバックアップサーバのリソースを圧迫し、ボトルネックとなってしまいます。（同時実行可能なゲストOS処理には上限があり、これを超えてジョブを実行する場合にはタイムアウトします。）
  • 低速なWANリンク
    次の制限は上記に多少関係しています。複数拠点を持つ場合、コンソールとなるVeeamバックアップサーバは多くの場合、本社に配置されています。この場合、VeeamバックアップサーバからのゲストOSに対する処理は低速なWAN回線を介すことになり、これが不安定な場合、バックアップの失敗などが発生します。

1

このように、別拠点にプロキシとリポジトリを用意し、データ処理に関しては、拠点内のローカルでバックアップ、リストアを行っている場合でも、ゲストOSに対する処理に関してはWANを挟んだ処理となっていました。
これを避け、パフォーマンスの向上とスケーラビリティを実現するためにV9では「ゲストOS静止用のプロキシ」を任意のWndowsマシン（既存のプロキシやリポジトリに対しても可能）に割り当てることができます。これにより各拠点での処理を拠点内で実施可能になり、理想的なバックアップを実現できます。
2

このゲストOS静止用のプロキシを使用した場合、低速なWAN回線を介して送信される内容は制御用のコマンドのみとなります。拠点のローカルなゲストOS静止用のプロキシがゲストにランタイムプロセスをアップロードし、VMに対する処理を行います。これにより、Veeamバックアップサーバの負荷は低減し、低速な回線を通過するトラフィックは最小限になります。一つVeeamバックアップサーバが各ゲストOS静止用のプロキシを制御するためにスケーラビリティも大幅に向上します。例えば、500拠点を持つ大規模なユーザを考える場合にも、このゲストOS静止用のプロキシ、既存のデータ処理用のプロキシ、保存先となるリポジトリの役割をそれぞれVeeamバックアップサーバから割り当てるだけで、各拠点での効率的なバックアップを実現しながら、それをVeeamバックアップサーバ単体で管理できます。

また、このゲストOS静止用のプロキシには、もう一つ隠された利点があります。Veeamに登録しているゲストOSのアカウントに高いレベルの権限を与えることができず、ネットワークレスなVIXでの処理が行えないような場合、ネットワーク経由で直接VeeamバックアップサーバからゲストOSに対する処理を実施するのは難しいケースがあります。このような場合に、ゲストOS静止用のプロキシに拠点内のバックアップ用のネットワークと運用ネットワーク両方のNICを搭載したWindowsマシンを指定することでバックアップネットワークから運用ネットワークにフォワードし、通信できます。

マウントサーバ
しかし、データ保護はバックアップだけでは成り立ちません。リポジトリで保存に保存されたデータからファイルレベルリストアする必要があるかもしれません。しかし、ファイルレベルリカバリをVeeamコンソール実施し、オリジナルVMへの直接リストアを行う場合、本社にあるVeeamバックアップサーバがリモートにあるリポジトリから対象ファイルのデータを取得し、それをオリジナルのVMへ送ることになります。
3
ローカル内でこれを行うのなら良いですが、拠点を挟む場合、低速なWAN回線を2回、横断する必要があります。これの既存機能を使用した回避策としてマルチOSのファイルレベルリカバリがありますが、FLR用のヘルパーの仮想アプライアンスを設定する必要があるなど少々手間がかかります。

そこでV9からは新たにマウントサーバ機能が実装されます。この機能はVeeamに登録されているWindowsマシンをバックアップリポジトリにマウント用のサーバとして設定できる機能です。これにより、通常のファイルレベルリカバリの際にも各拠点のWindowsマシンがバックアップデータをマウントし、その中からファイルを取得、オリジナルに転送できます。これにより、ファイルレベルリストアでも拠点内でのみのデータ移動が可能になり、Veeamバックアップサーバからは制御用のコマンドのみ送信されます。またWindowsベースのリポジトリであればそれ自体を使用できます。
4

スタンドアロンなコンソール
「リモート」に関して、V9で追加される重要な機能の一つがスタンドアロンなコンソールです。これはVeeam Backup & Replicationのコンソールのことであり、Veeamの管理者はVeeamバックアップサーバとは別にインストールできるようになります。

例えば、自身のワークステーション上でこのスタンドアロンなコンソールをを使用し、リモートネットワークを介してバックアップサーバの管理が可能になります。これでリモートデスクトップで、バックアップサーバにアクセスし、ユーザがお互いを蹴りあうなどということはなくなります。各オペレータは自分のコンソールを持つことができます。
注目すべき点は、このスタンドアロンなコンソールを実行しているマシンもマウントサーバの役割を持てるという点です。Veeam Explorerといった高度な復旧を行う際に自拠点のバックアップを自拠点内の自身のワークステーションにマウントしそこから各種リストアを行えます。

テープ機能の改善
これだけではなく、V9はテープユーザに対して、最適なサポートを提供するために、多くの改善を提供予定です。その中でも大きな機能追加は単一の物理ライブラリから取り外したメディアプールを作成する機能と複数のライブラリにまたがりデータを保存する機能です。このグローバルメディアプールがテープジョブでメインのターゲットとなることで、パフォーマンスを改善し、管理も容易にできます。
5

グローバルメディアプールをターゲットとしたテープジョブは、ライブラリのフェイルオーバー順序に従い、複数のライブラリ、スタンドアロンドライブを使用します。そしてフェイルオーバーが必要になるイベントが発生した場合に、使用可能なライブラリに切り替わります。
例えば、一つのライブラリでフリーのメディアがなくなった場合、全てのテープドライブが占領されている場合、グローバルメディアプールにより、テープジョブは別のフリーのメディアもしくはテープドライブが利用可能なライブラリに切り替わります。

そのほかの大きな機能追加としては、複数のテープドライブを使用した並列処理です。Ver8までは複数のメディアプールとテープジョブを用意し、手動で並列に動作するようスケジュールする必要がありましたが、V9からは複雑な設定もなくすぐに並列でテープに保存できます。
6

さらに、テープメディアの保持ポリシーにフルバックアップを長期間保持するためのGFS Media Poolも追加されます。GFSメディアプールとして指定したテープには、週、月、四半期、年で保持する個数を指定し、フルバックアップを簡単に保存できます。

関連トピックス

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

 

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。