富士通のNetApp型番メモ 2021/07/07版

富士通はETERNUS NRシリーズとしてNetApp FASシリーズを取り扱っていた。

2020年に「ETERNUS AX/HXシリーズ」に改名したが、元のNetApp型番と違う番号がついており、よくわからなくなってしまった。

(これまではFAS 2720A→NR F2720という感じで分かりやすかった)

ETERNUS AX/ETERNUS HX series 製品変遷FUJITSU Storage ETERNUS AX series, HX series 製品比較表NetApp Fusionで「New ASA, AFF and FAS Manual Design」で出てくるプロダクトを比較しつつこんな感じかな、というのが下記

正しいかどうかは未確認

ETERNUX AX1100
 拡張Shelf不許可の廉価版AX2100?
 CPU/メモリスペックは2CPU8コア/64GB

ETERNUS AX2100 = AFF A220A? AFF A250A?
 CPU/メモリスペックはAX2100/HX2100/2200で同じ2CPU12コア/64GB
ETERNUS AX2200 = FAS500fA
 NVMe/FCにも対応
 拡張Shelf NS224とあわせてNVMe SSD SED専用
 220V電源専用
 CPU/メモリスペックは2CPU12コア/128GB
ETERNUS AX4100 = AFF A400A
 NVMe/FCにも対応
 CPU/メモリスペックは2CPU10コア/256GB

ETERNUS HX2100 = FAS2720A
 コントローラ内蔵が3.5インチHDD
 CPU/メモリスペックはAX2100/HX2100/2200で同じ2CPU12コア/64GB
ETERNUS HX2200 = FAS2750A
 コントローラ内蔵が2.5インチHDD
 CPU/メモリスペックはAX2100/HX2100/2200で同じ2CPU12コア/64GB
ETERNUS HX6100 = FAS8300A?
 CPU/メモリスペックは2CPU10コア/256GB


富士通が提供する日本語資料

ETNERNUS AX/HX Series ホワイトペーパー
ETNERNUS AX/HX Series マニュアル

ETERNUS AX series、ETERNUS HX series データ移行情報 相互接続性について」という文書内でNetApp製FAS、ETERNUS NRと、ETRERNUS AX/HXに機能差異があるような記載が・・・
ライセンス内容の差異だといいんだけど


2021/10/20追記

HX2100実機が来た

NR1000F時代はNetAppそのままだったものが、富士通カスタマイズでの提供になりました。Lenovo/IBM版と同じような提供形態になりましたね。

NetApp純正だとONTAP 9.8P11が出ていますが、富士通からは9.8P3での提供でした。(SupportDeskサイトでのアップデートは未提供)

初期パスワードについてはNR1000F時代から引き続き「password0」でした。また、ライセンスはライセンスコードを印字したシートが付属です。また、ライセンスは入力された状態で起動します。

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: todoroki110, 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ログインを許可する

Windows Server 2019のストレージ移行サービスは評価版メディアには含まれていない

Windows Server 2019には、Windows Admin Centerと組み合わせて使うストレージ移行サービス(Storage Migration Service)というのが存在している。

これを使うと、稼働しているWindows ServerによるSMBファイルサーバを別の物理サーバ上に移動させることができるようだ。

試してみようとWindows Server 2019評価版をダウンロードしてきて試そうとすると、「役割と機能の追加」の「機能」にあるはずの「ストレージ移行サービス(Storage Migration Service)」が見当たらない。

翻訳の問題で「Windows Server 移行ツール」のことをさしているのかな?と試してみてもWindows Admin Centerで表示されない。

いろいろあれこれ試してみた結果、「Storage Migration Service known issues」に評価版メディアには含まれていないので製品版メディアなどでインストールして、アクティベーションをかけないで使ってね、という対応策が記載されているのを発見。

で、製品版Windows Server 2019メディアでインストールしなおしてみると、確かに「Storage Migration Service」がありました。

「Storage Migration Service」にチェックを入れると、「Storage Migration Service Proxy」と「Storage Migration Service Tools」にもチェックが入りました。

これで追加したあとは、Windows Admin Centerにてきちんと「記憶域の移行サービス」が表示されました。

なお、移行先ファイルサーバのWindows Server 2019が評価版である場合もこの制限に抵触するようで、移行サービスの実行中に移行先ファイルサーバにSMS-Proxyをインストールするはずの項目から先に進まない、という状況になりました。

このため、Windows Server 2019でテストする場合は製品版をアクティベーション無しで利用した方がよさそうです。


2021/10/15追記

Windows Server 2022だと評価版でも使用できました。

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追記

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

microSDのアプリケーションクラス/ビデオクラスによる速度の違い実測

SD/SDHC/SDXCカードには速度に関する仕様がいくつかある。

以前は「スピードクラス」だけをうたっていたが、これだけだと実際にはある細かい性能差が表現できていないので「ビデオスピードクラス」というのと「アプリケーションクラス」というものが追加されている。

で・・・ラズパイでOS起動ディスクとして使う場合に何がいいのか、という話である。

Windows 10 on ARMの起動ディスクを作成し、初回起動するのにどれくらい時間がかかるかを確認してみた。

関連「microSDのA1/A2,V10/V30に差が出るか?

製品名クラス容量WoR書き込みお住まいの
地域選択
デスクトップ
表示
SanDisk Extreme ProU3/A2/V3064GB37分18分5分
SanDisk Extreme(金色)U3/A2/V3064GB28分16分5分
Lexar 633xU3/A1/V3064GB27分16分5分
SanDisk HIGH ENDURANCE(白)U3/V3032GB33分18分6分
KIOXIA EXCERIA PLUS(紫)U3/V3032GB32分17分5分
SanDisk Extreme ProU3/A1/V3032GB43分19分5分
Lexar 633xU1/A1/V1032GB30分17分6分
SanDisk UltraU1/A132GB33分17分5分
KIOXIA EXCERIA HIGH ENDURANCE(黄緑)U132GB31分  
Samsung EVO PlusU132GB74分35分8分

最近のmicroSDであればおもったより差がでない

モバイルバージョンを終了