Arcserve UDP コンソール/エージェント/復旧ポイントサーバの構成例

Arcserve UDP コンポーネントの紹介

Arcserve UDP の基本コンポーネントは以下の3つです。

まずは各コンポーネントを順に紹介していきます。なお、動作要件については UDP7.0 のメモリのみ記載します。

Arcserve UDP エージェント

動作要件：2GB以上

これは、「バックアップ処理を実行する」コンポーネントです。

ただ、エージェントにも関わらず、管理サーバがなくてもスケジュール設定もでき、バックアップやリストアができます。

1台や2台程度のサーバをバックアップする程度であれば、これでエージェントだけで十分かもしれません。

「Arcserve UDP 機能紹介 ～ (1) 全体像とコンポーネントについて ～ | それ、レプリケーションでよろしく。UDPともども。」 より引用

Arcserve UDP コンソール

動作要件：8GB以上

名前の通り、バックアップ運用の統合管理をする場合に利用します。

複数のエージェントをまとめて管理する画面を提供し、スケジュールの設定やレポートの作成まで行います。

「Arcserve UDP 機能紹介 ～ (1) 全体像とコンポーネントについて ～ | それ、レプリケーションでよろしく。UDPともども。」 より引用

復旧ポイントサーバ（RPS）

動作要件：8GB以上

このコンポーネントはバックアップデータの保管庫（データストア）を提供します。

これまでarcserve D2Dにはなかったコンポーネントで、エージェントから受け取ったバックアップデータを指定の場所に書き出す処理を代行します。（他社製品などではメディアサーバという呼ばれ方をしてるかもしれませんね。

「Arcserve UDP 機能紹介 ～ (1) 全体像とコンポーネントについて ～ | それ、レプリケーションでよろしく。UDPともども。」 より引用

復旧ポイントサーバを用意する一番の理由は「重複排除」です。ローカルディスク/共有フォルダにバックアップする場合、重複排除が効かないのでバックアップデータが肥大化します。

よくある構成

Arcserve UDP のよくある構成例を紹介します。

復旧ポイントサーバを使うパターン

①の構成について

①は基本コンポーネントを全て分けるパターンです。

コンソールと復旧ポイントサーバは１台に同居させることが多い（②の構成）ですが、例えばメモリが足りなくて復旧ポイントサーバとコンソールを１台にまとめることが出来ない場合や、コンソールサーバのバックアップを取得したい場合などに①の構成になったりします。

②の構成について

一番よくあるパターンかと思います。コンソールと復旧ポイントサーバを同居させる構成です。

このパターンで注意しなくてはならないのは大量のメモリが必要と言うことです。

それぞれ最低動作要件が8GB以上ですので、最低16GB以上 Arcserve UDP 用のメモリを確保しなくてはなりません。

復旧ポイントサーバの特徴である重複排除を行うにはそれ以上のメモリサイズが必要ですので、更に厳しくなってきます。

③の構成について

あまり見ないパターンです。復旧ポイントサーバのリソースに余裕が無く、コンソール用のサーバも用意できない場合にはこうなります。

もし2～3台程度のエージェントであれば、そもそもコンソールは必要ないかと思います。

ローカルディスク/共有フォルダを使うパターン

①②③の構成について

基本的には復旧ポイントサーバがただのNASなどになっただけです。

バックアップ先が復旧ポイントサーバとしての動作要件を満たせない、または重複排除の必要がないくらい容量に余裕がある場合はこのような構成になります。

バックアッププロキシサーバ

バックアッププロキシサーバとは、仮想基盤のエージェントレスバックアップにおいてハイパーバイザとコンソールサーバ間を連携させるためのプロキシ（中継）機能を提供するサーバです。

エージェントレスバックアップにおいては、UDP エージェントはバックアップ プロキシとして使用されます。

通常、バックアッププロキシとコンソールは同一サーバに導入します。

構成でいうと、「コンソール/バックアッププロキシ/復旧ポイントサーバ」という構成が最も多いかと思います。

まあ、エージェントレスバックアップに必要なんだなぁ程度に覚えておくと今度捗るかもしれません。