4月 24, 2019
arcserve UDP 6.5を使った仮想化基盤の必要計算機資源の概要はベンダサイトにある程度情報があるのだが、実例が少ないので最近の案件の参考情報を。
A)サブシステム、または小規模の基幹システムを想定。
仮想化基盤上の仮想マシンが10台以下（バックアップ対象のディスク2TB以下）であれば、概ね以下の構成で良い。この程度であれば重複排除をonで運用すれば必要ディスクも節約できる。
バックアップ物理サーバ1台（4-6cores , 24GB Memory , 最低RAID 10 2TBx4 または RAID 5 1TB x 8程度でサーバのディスクベイに合わせて）
RPS,BackUp Proxy,Consoleを全て稼働させる。
バックアップジョブ起動はarcserve UDPの内蔵スケジューラを使用。
B)中規模以上の基幹システム、または基幹システムに加えてサブシステムも統合した仮想化基盤を想定。
仮想化基盤上の仮想マシンが30台程度（バックアップ対象のディスク10TB以上）の規模になると、システムデザインを練る必要がある。
具体的に見てみよう。
1)BackUp Proxyは仮想化ホスト上の仮想マシンにする。
BackUp ProxyはESXiとRPSとを仲介してバックアップ対象のディスクのデータを読み出す機能を担当する。
NECのサイトに詳しい（他のソフトウエアだが...）が上記A)では仮想化ホスト、バックアップサーバ（RPS兼BackUp Proxy）間の転送はNBD方式になり、これはディスクの中身がLAN上に流れるので、概ね1GByte/min程度のバックアップ速度になる。
一方、BackUp Proxyをバックアップ対象と同一の仮想化基盤上の仮想マシンとすると、バックアップ対象のvmdkがBackUp Proxyへ接続されれ（Hot Add）重複排除や圧縮処理はBackUp Proxyで処理される。この結果、小容量になったデータのみがLAN経由でバックアップサーバ（RPS）へ流れる。この構成では10GByte/min以上のバックアップ速度が得られ、バックアップ対象が大容量時は是非検討するべきである。
2)BackUp Proxyに必要な計算機資源容量
BackUp Proxyはどの程度の仮想マシンとして構成すれば良いのか。当方の事例では8vCPU(intel Silver 4114)、16GB Memoryとかなり大きい構成が必要であった。バックアップ設定は重複排除on（32KByte ブロックサイズ）、圧縮最大、4多重（初期設定）としている。
メモリ不足になるとバックアップがクラッシュするので余裕が必要である。
3)Consoleはバックアップ起動方式によって配置を検討する
Consoleはスケジューラ、web interface、CLIの機能を提供する。バックアップ起動がarc serve UDPの内蔵スケジューラであれば配置はRPSと同一の物理サーバ上に搭載で良い。
しかしながら、ジョブスケジューラで起動する場合は注意が必要である。
多コアの物理サーバ上でRPSと同居するとジョブスケジューラの費用が嵩む。それであれば、ゲストOSライセンス費用が増えるが個別にConsoleを小さな仮想マシンとして用意した方が良い。
Console自体はCPU負荷が少ないため、独立して仮想マシンとして配置するのであれば1-2vCPU , 6GB-8GB Memoryで十分である。これであればジョブスケジューラの費用も少なくて済む。
4)RPSに必要な計算機資源容量
RPSは独立した物理サーバとして構成するが、CPU負荷が高いBackUp Proxyを分離すると概ね1socket 4coresの構成で十分の様だ。
ハッシュMemoryはarcserve UDPのツール（arcserve UDPをインストールする必要がある....）で計算できるが、あくまでも「ハッシュメモリ」だけの容量計算であるので、OSやRPS自体のメモリとして+4〜8GB程度は追加しておきたい。
大容量バックアップではブロックサイズを標準の16KByteから32KByteへ変更した方が良い。実運用に入ってデータが溜まってメモリ不足になるとRPSが読み出し専用になるので、無理をしない方が良い。代わりに圧縮を標準から最大に変更すればディスク使用量は抑えられる。
