Commvault バックアップのLinuxクライアントをインストールする場合の設定


2024/01/23現在 のLinuxクライアントとして設定する場合の要点

「gzip」と「tar」コマンドが利用できること。使えない場合は、パッケージをインストールする。

RHEL8/RHEL9系の最小インストールの場合、tarコマンドが使えないので注意。

クライアント側のFirewall設定は ポート 8400 をあけておくこと。

ポート8400を使った通信は、CommServeだけではなく、MediaAgentからも行われるので、IPアドレス制限をかける場合は注意すること。

なお、ポート8400をあけていなくても、クライアント上で起動したCommvaultのエージェントからCommServeなどへの通信が行えるが、内部的にリトライエラーを繰り返した代替策となるため処理に時間がかかるので推奨はしない。


2023/10/10現在

Commvault 2022E(11.28)でLinuxクライアントをインストールする場合のメモ

System Requirements for Linux File System」には特に必要なパッケージについての記載は、RHEL/CentOS 7.1環境でnet-toolsをインストールしておくこと、以外の記載はない。

AlmaLinux 8.8の最小インストール環境で net-toolsが含まれていない状態ですが、この状態でCommvault 11.28.56環境でインストールを試みたところ、net-toolsがない状態でもインストールは成功しました。

また、tarコマンド、gzipコマンドについては必須ですが、Linuxの設定状況によってはtarコマンドがインストールされていないことがあるのでが「tarコマンドがない」的なエラーはでないで失敗するので、原因が分かりにくいです。(エラーでた後に該当Linuxサにログインすると /opt/seed/ にファイルが転送されています。/opt/seed/cvpkgadd を実行してみると、tarコマンドがない、というエラーがでるので、ようやくわかります)

エラーコード: [68:184]

説明: Failed to install File System Core Package on client.
Source: linuxserver110, Process: DistributeSoftware

firewallについてはポートを開けない状態でもうまく動作する場合がおおかったですが、Media Agent/Virtual Server設定などを行った際には、ポートを開けておかないと動作が安定しませんでした。

加えて、インストールしてそのまま使うだけであればfirewall設定をしないままでも通信に成功し、バックアップの取得も可能でしたが、一度再起動すると接続が確立しない状態となりましたので、ポートは開けておくべきです。

また、VMware Proxy/Access Nodeとした場合、 https アクセスも必要であったようでしたので下記の例ではport 8400と、port 443(https)を追加しています。
MAの場合は追加で port 50000-50020 とかしておいた方がよさそうです。

普通のLinuxクライアントとして使う場合は port 8400だけで大丈夫でしょう。

# firewall-cmd --permanent --zone=public --add-port=8400/tcp
success
# firewall-cmd --permanent --zone=public --add-service=https
success
# firewall-cmd --reload
success
# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources:
  services: cockpit dhcpv6-client https ssh
  ports: 8400/tcp 
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
#

また、Linux仮想マシン内の個別ファイルをリストアする際に利用するFREL仮想マシン(File Recovery Enablers for Linux)は、通常のLinux MediaAgent+Virtual Server構成では使えません。

追加設定として「Converting a Linux MediaAgent to a File Recovery Enabler (FREL)」にある設定を行う必要があります。

また、FRELは/opt/commvault/CVBLK 以下にあるコンパイル済みのkernel module cvblk を使用します。ここに該当のkernelバージョンのモジュールがない場合はFRELに昇格できません。

また、VSAとして使う場合に、Commvault環境を一時的なNFSサーバとしてvSphere環境からデータストアとしてマウントし、バックアップされているvmdkファイルを使う、という3dnfs serviceを使う場合は、追加でNFS v3で必要なポート設定をする必要があります。

こちらについては面倒なので「Additional Port Requirements for 3dnfs Services」を参照のこと…というか、そこまでやるならfirewallをoffにした方が早いですけどね。FREL仮想マシンはfirewall offですし。

2023/10/18追記

Commvault 2023E(11.32)環境にテスト環境を作った
(1)CommServe単独サーバ Windows
(2)MediaAgent+重複排除のバックアップ保存領域 Windows
(3)IndexServer Windows
(4)VSA/FREL Linuxサーバ

(1),(2),(3)のWindowsサーバで共通のfirewall設定「Windows Management Instrumentation (DCOM受信)」「Windows Management Instrumentation (WMI受信)」「ファイルとプリンターの共有」を有効化と、Commvaultがインストール時に自動作成するルールの有効化

Linux仮想マシン内の単独ファイルをリストアするためにブラウズする際は、(2)から(4)のport 8403に対して通信が発生し、(4)側で8403を開けていないと失敗した

(1)CommServeは動作中のcvfwd.log を見ると、8400~8403 を開けておいた方が接続が早そう。

(2)MAは8400,8403 をあけた方が良い。NDMPバックアップを保存する場合は10000と50000-50050 とMAのネットワークルート設定のインカミングに50000-50050を追加


2021/5/24 に書いたもの

CommvaultバックアップのLinuxクライアントをインストールする際にうまく行かずに悩んだ点が発生したのでメモ書き。

Linux File System Agent: System Requirements」には下記のような記述があるが、実際にはRHEL/CentOS 7.1以外でも発生する問題である。

Net-tools Package
On Red Hat Enterprise Linux/CentOS 7.1 computers, make sure to install the net-tools package.

それどころか、RHEL8/CentOS8などでは、tarパッケージが最小インストールではインストールされなくなっているため、インストールに失敗する。(vSphere環境上にインストールする場合、open-vm-toolsの必須パッケージとしてtarがインストールされるため気がつきにくい)

今回、RHEL8.3, AlmaLinux 8.3, Rocky Linux 8.3, openEuler 21.03, CentOS 7, Ubuntu 18.04にインストールした結果、必要だったものは以下であった。

・必須のコマンド
tar, netstat, gzip コマンド
・上記が含まれるパッケージ(RHEL系の場合)
tar net-tools

また、firewalld/iptablesによる通信制限がかけられている場合、下記を実行してポートをあけた方が良い。

ただ、あけなくてもバックアップできる場合もある。

現状を確認「firewall-cmd –list-all」

[root@centos8 ~]# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources:
  services: dhcpv6-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
[root@centos8 ~]#

Commvault用にポート8400をあける設定

[root@centos8 ~]# firewall-cmd --permanent --zone=public --add-port=8400/tcp
success
[root@centos8 ~]#

設定の反映

[root@centos8 ~]# firewall-cmd --reload
success
[root@centos8 ~]#

反映されたことを確認

[root@centos8 ~]# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources:
  services: dhcpv6-client ssh
  ports: 8400/tcp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
[root@centos8 ~]#

また、rootユーザでのログインが禁止されている場合は、以下の4つの手段のどれかを使う

その1) 予め各Linuxサーバの/etc/sudoers ファイルにインストール用ユーザを設定してリモートインストールを行う「Adding sudo Users with Root Privileges on a UNIX Client

その2) 各LinuxサーバにLinuxクライアントパッケージを転送してrootユーザでインストールを行う「Installing Commvault Locally on UNIX, Linux, and Macintosh Computers Using the Installation Package

その3) 各LinuxサーバにLinuxクライアントパッケージを転送して一般ユーザ+sudoでインストールを行う「Installation of UNIX Agents by a Non-Root User

その4) 各Linuxサーバでrootログインを許可する

Commvaultの自働スケジュールの動きを確認した


CommVaultにはフルバックアップと増分バックアップをバックアップサーバ上で論理合成して新しいフルバックアップにする、という合成バックアップ(Synthetic Full)という仕組みがある。

V11SP16より前までは増分バックアップを実行した後に続けて合成処理を行う、というスケジュールを作成することができたが、2021年の現在ではそのようなスケジュールを作成することはできず、増分とは別に合成バックアップ用のスケジュールを作成する必要がある。(参考)

問題となるのは増分バックアップの終了時間にあわせて合成バックアップを実行する、ということが難しい、ということ。

単純に増分を毎日0:00開始、合成フルバックアップを日曜12:00開始、とかに設定した場合、増分バックアップに12時間以上かかり、日曜12時もバックアップ中であった場合、同名のスケジュールが動作しているので合成処理がスキップされてしまうことになる。

ドキュメントをみると「自働」スケジュールを設定することを推奨されており、「週1回合成フルを実行する」としたい場合は「自働 7日」というスケジュールを実行することで、7日に1回実行されることになるようだ。

7日で検証すると時間がかかりすぎるので「自働 2日」を設定して検証してみた。

開始終了
合成フル2021/3/24 18:522021/3/24 19:00自働2日というスケジュールを18時半過ぎに設定
増分2021/3/25 3:002021/3/25 3:01
増分2021/3/26 3:002021/3/26 3:01
合成フル2021/3/26 19:172021/3/26 19:24前回の実行終了から48時間+17分で実行された
増分2021/3/27 3:002021/3/27 3:02
増分2021/3/28 3:002021/3/28 3:01
合成フル2021/3/28 19:432021/3/28 19:49前回の実行終了から48時間+19分で実行された
増分2021/3/29 3:002021/3/29 3:02
増分2021/3/29 20:102021/3/29 20:11開始時刻を20:10変更
合成フル2021/3/30 20:082021/3/30 20:14前回の実行終了から48時間+19分で実行された
増分2021/3/30 20:132021/3/30 20:18開始時刻を20:10したが、合成フルが動作していたので遅延?

実行するたびに時間が後ろにずれていくのが気になる・・・

この17分~19分はどこから来ているのかな?とスケジュール設定画面を見直してみると、「ファイルまたはログのアクティビティ検出頻度 0時間15分」という変更ができない項目がある。

これは、15分間隔で自動バックアップを実行するべきか判断する、ということになるんだろうか?

だとすればこの動きも納得かな、と


2021/04/05追記

合成バックアップが実施される予定の時間帯にシステムが停止していた場合、どうなるかを確認したところ、システム起動後に合成バックアップが実行されました。

Commvault バックアップのWindowsクライアントをPUSHインストールする時のWindows Firewall 設定


Commvaultバックアップは、CommServeからPUSH操作によりWindowsクライアントへのCommvault エージェントのインストールを実施することができる。

その場合に必要なWindows Firewallの除外設定についてのメモ

公式のドキュメント「Prerequisites for Installations Using the CommCell Console」に記載されているが、実際のWindows Firewallテンプレートの記述とあわせていないのでわかりにくい。

試した限りでは「受信の規則」にある下記の3つの既存設定を「規則の有効化」するでいけた

・Windows Management Instrumentaion (DCOM受信)

・ Windows Management Instrumentaion (WMI受信)

・ファイルとプリンターの共有 (SMB 受信)

なお、ping応答もできるようにしたい場合は追加で「ファイルとプリンターの共有 (エコー要求 – ICMPv4 受信)」も有効化する(CommvaultのPUSHインストールにとっては不要)

インストールできるかの確認には、CommServeから「wmic /node:ホスト名 process get」と実行して対象ホストのプロセス一覧が取得出来れば、WMI動作としては問題ない感じです。

なお、CommVaultエージェントインストールにより、「CommVault_Process_1_????」といったルールが大量に登録される。

これは C:\Program Files\CommVault\Simpana\Base\AddFWExclusions.bat にて設定されたルールとなる。

— 2019/08/26追記 —

なんかこの設定だけだとうまくいかない

Visual C++ 2015-2019再頒布可能パッケージがインストールされていない場合に、リモートインストールが失敗することもある模様。


2021/09/03追記

Windows Server 2022でリモートインストールを試したところ、今回も同様に「Windows Management Instrumentaion (DCOM受信)」「Windows Management Instrumentaion (WMI受信)」「ファイルとプリンターの共有 (SMB 受信)」の3つの有効化でリモートインストールが可能になりました。