技術的なことをメインにいろいろ書いてくサイトです
NetAppシミュレータの古いバージョンは圧縮ありのOVAファイルで提供されている。
これをvSphere 7.0環境で使おうとすると、圧縮されているので使えない、と拒否される。
変換ツールを使ってもよいのだが、手動でも変換できる
OVAファイルは中にovfファイルとvmdkファイルが入っているだけのtarファイルなので、7zipなどのツールを使って展開できる。
vsphere 7.0ではvmdk.gzは使えないので、これも展開する
OVFファイルの中身はXMLファイルとなっていて、元の中身は、vmdk.gzのファイルを指定している。
これを展開後のファイル名とファイルサイズに置き換える
また「ovf:compression=”gzip”」という記述も削除する
こうやって出来たOVFファイルとVMDKファイルを複数指定してvSphereで読み込ませる。
読み込ませる下記の様な形で「５ファイル」という表示になる
記述に問題なければOVFテンプレートのデプロイが継続できる。
ONTAP 8.x 7-modeではボリューム単位でしかsnapmirrorができませんでしたが、ONTAP 9.5では、SVM DRという機能を使ってSVMの機能ごとsnapmirrorできるようになっています。
ONTAP 8.3時代の分かりやすい絵「SVMのディザスタ リカバリの設定」
ONTAP 9.xのドキュメント「SnapMirror SVMレプリケーションの概要」
参考になる日本語資料「ETERNUS AX series、ETERNUS HX series ONTAP 9 用SnapMirror 構成およびベストプラクティスガイド」「ETERNUS AX/HX series データ保護パワー ガイド」(出典)
下記の環境であるとした場合のコマンド実行例を書く。
送り元となるクラスタ名 netapp001c
送り元となるSVM名 netapp001
受け側となるクラスタ名 netapp002c
受け側となるSVM名 netapp001-dr
GUIなどでクラスタピアを設定
コマンドだとcluster peerコマンドで実施。
netapp001c::> cluster peer create -peer-addrs 相手のintercluster IP
Notice: Use a generated passphrase or choose a passphrase of 8 or more
characters. To ensure the authenticity of the peering relationship, use
a phrase or sequence of characters that would be hard to guess.
Enter the passphrase:
Confirm the passphrase:
Notice: Now use the same passphrase in the "cluster peer create" command in the
other cluster.
netapp001c::>
netapp002c::> cluster peer create -peer-addrs 相手のintercluster IP
Notice: Use a generated passphrase or choose a passphrase of 8 or more
characters. To ensure the authenticity of the peering relationship, use
a phrase or sequence of characters that would be hard to guess.
Enter the passphrase:
Confirm the passphrase:
netapp002c::>
それぞれで同じパスフレーズを入力していれば「cluster peer show」で見た時に「Availability:Available」となる
netapp002c::> cluster peer show
Peer Cluster Name Cluster Serial Number Availability Authentication
------------------------- --------------------- -------------- --------------
netapp001c 1-80-000008 Available ok
netapp002c::>
受け側NetApp上で、受け側となるSVM(ピアSVM)を、dp-destinationというタイプで作成。
まずは、受け側に作られているSVMを確認するため「vserver show」を実行
netapp002c::> vserver show
Admin Operational Root
Vserver Type Subtype State State Volume Aggregate
----------- ------- ---------- ---------- ----------- ---------- ----------
netapp002 data default running running netapp002tm netapp002c_
p_root 01_NL_SAS_1
netapp002c admin - - - - -
netapp002c-01
node - - - - -
netapp002c-02
node - - - - -
4 entries were displayed.
netapp002c::>
ピアSVMを「vserver create -vserver netapp001-dr -subtype dp-destination」で作成し、「vserver show」で作成されたことを確認
netapp002c::> vserver create -vserver netapp001-dr -subtype dp-destination
[Job 937] Job succeeded:
Vserver creation completed.
netapp002c::>
netapp002c::> vserver show
Admin Operational Root
Vserver Type Subtype State State Volume Aggregate
----------- ------- ---------- ---------- ----------- ---------- ----------
netapp001-dr data dp-destination stopped - -
running
netapp002 data default running running netapp002tm netapp002c_
p_root 01_NL_SAS_1
netapp002c admin - - - - -
netapp002c-01
node - - - - -
netapp002c-02
node - - - - -
5 entries were displayed.
netapp002c::>
作成したピアSVM netapp001-drは「stopped」状態となっている。
受け側NetApp上で、送り元SVMとのSVM peerを作成
「vserver peer create -vserver 受け側SVM -peer-vserver 送り元SVM -applications snapmirror -peer-cluster 送り元NetAppクラスタ」を実行
netapp002c::> vserver peer create -vserver netapp001-dr -peer-vserver netapp001 -applications snapmirror -peer-cluster netapp001c
Info: [Job 938] 'vserver peer create' job queued
netapp002c::>
実行後、「vserver peer show」を実行し、作成の状況を確認。
netapp002c::> vserver peer show
Peer Peer Peering Remote
Vserver Vserver State Peer Cluster Applications Vserver
----------- ----------- ------------ ----------------- -------------- ---------
netapp001-dr netapp001 initializing netapp001c snapmirror netapp001
netapp002c::>
しばらく待つとPeer Stateが「initiated」に変化
netapp002c::> vserver peer show
Peer Peer Peering Remote
Vserver Vserver State Peer Cluster Applications Vserver
----------- ----------- ------------ ----------------- -------------- ---------
netapp001-dr netapp001 initiated netapp001c snapmirror netapp001
netapp002c::>
送り元NetApp上で、受け側からのSVM peer要求を受諾。
まずは「vserver peer show」で状況を確認
netapp001c::> vserver peer show
Peer Peer Peering Remote
Vserver Vserver State Peer Cluster Applications Vserver
----------- ----------- ------------ ----------------- -------------- ---------
netapp001 netapp001-dr pending netapp002c snapmirror netapp001-dr
netapp001c::>
Peer Stateが「pending」となっていることを確認。
pending状態を「vserver peer accept -vserver 送り元SVM -peer-vserver 受け側SVM」を実行して受諾。
netapp001c::> vserver peer accept -vserver netapp001 -peer-vserver netapp001-dr
Info: [Job 922] 'vserver peer accept' job queued
netapp001c::>
netapp001c::> vserver peer show
Peer Peer Peering Remote
Vserver Vserver State Peer Cluster Applications Vserver
----------- ----------- ------------ ----------------- -------------- ---------
netapp001 netapp001-dr peered netapp002c snapmirror netapp001-dr
netapp001c::>
Peer Stateが「peered」に変わったら受諾処理が完了です。（処理中はpendingのままです）
受け側NetApp上で、SVM peerが成立したことを確認
netapp002c::> vserver peer show
Peer Peer Peering Remote
Vserver Vserver State Peer Cluster Applications Vserver
----------- ----------- ------------ ----------------- -------------- ---------
netapp001-dr netapp001 peered netapp001c snapmirror netapp001
netapp002c::>
まず、現状のsnapmirrorの状態を送り元と受け側で確認しておく。
netapp001c::> snapmirror show
This table is currently empty.
netapp001c::>
netapp002c::> snapmirror show
This table is currently empty.
netapp002c::>
snapmirrorの作成は、受け側NetApp上で実行する。
「snapmirror create -source-vserver 送り元SVM -destination-vserver 受け側SVM -type DP -policy DPDefault -schedule hourly -identity-preserve true」と実行する。
-schedule hourly というのは１時間ごとに同期を取る、という設定となる。このスケジュールを別のものにすることもできる。
netapp002c::> snapmirror create -source-vserver netapp001 -destination-vserver netapp001-dr -type DP -policy DPDefault -schedule hourly -identity-preserve true
netapp002c::>
作成後、「snapmirror show」を実行すると下記の様に、「Mirror State:Uninitialzied」「Relationship Status: Idle」で表示される。
netapp002c::> snapmirror show
Progress
Source Destination Mirror Relationship Total Last
Path Type Path State Status Progress Healthy Updated
----------- ---- ------------ ------- -------------- --------- ------- --------
netapp001: XDP netapp001-dr: Uninitialized
Idle - true -
netapp002c::>
受け側NetApp上でsnapmirrorの初期化を開始する。
「snapmirror initialize -destination-path 受け側SVM:」を実行する。
netapp002c::> snapmirror initialize -destination-path netapp001-dr:
netapp002c::>
実行後、snapmirror showで実行し、「Relationship Status: Transferring」になっていることを確認。
netapp002c::> snapmirror show
Progress
Source Destination Mirror Relationship Total Last
Path Type Path State Status Progress Healthy Updated
----------- ---- ------------ ------- -------------- --------- ------- --------
netapp001: XDP netapp001-dr: Uninitialized
Transferring - true -
netapp002c::>
ボリュームを含めてすべてのデータ転送が終わると「Mirror State: Snapmirrored」「Relationship Status: Idle」に変化します。
netapp002c::> snapmirror show
Progress
Source Destination Mirror Relationship Total Last
Path Type Path State Status Progress Healthy Updated
----------- ---- ------------ ------- -------------- --------- ------- --------
netapp001: XDP netapp001-dr: Snapmirrored
Idle - true -
netapp002c::>
2022/04/01追記
送り元ONTAP 8.3.2上のSVM share52、受け側ONTAP 9.9.1上のSVM share61-dr という状態でコマンドを実行してみるとどうなるのかを確認してみた。
netapp991::> snapmirror create -source-vserver share52 -destination-vserver share61-dr -type DP -policy DPDefault -schedule hourly -identity-preserve true
Error: command failed: The "DATA_ONTAP.9.2.0" capability is not enabled on
cluster "source".
netapp991::>
逆に見ると、ONTAP 9.2.0というフラグがあれば動くのか？
Backup ExecでNetAppのNDMPバックアップを行おうとしたときに0x20500106(542114054)というエラーになるという問題が発生した。
技術的詳細をみてみてもよく分からない。
該当の共有を確認すると日本語のディレクトリがある。
そして、NetApp上でボリュームの言語を確認するとja_JP.PCK_v2とUTF-8以外を使用している。
nas01c::> volume show -fields language
vserver volume language
--------- ------ --------
＜略＞
svm1 testlang2
ja_JP.PCK_v2
nas01c::>
では、日本語ではなく英数のディレクトリ名に変更
Backup Exec上で問題なく開くことができるようになった。
とりあえず、ボリュームの言語設定の問題であることは判明。
検索すると「How to enable Unicode or UTF-8 Language Support for the NDMP Option」というBackup Exec 11時代の古い記述を発見
ここに書かれている HKEY_LOCAL_MACHINE\SOFTWARE\Veritas\Backup Exec For Windows\Backup Exec\NDMP の UseUTF8の値は「0」であり、UTF-8じゃないボリュームという設定になっているように見える。
この値の変更は、NDMPアクセスをするごとに反映されるようでBackupExecサービスやサーバ再起動は不要だった。
が・・・今回のja_JP.PCK_v2ボリューム上の日本語ディレクトリ問題には対処できなかった。
では、この値変更はBackupExec 21.0で不要かというとそうではなくて、ja_JP.UTF-8ボリュームだと日本語ディレクトリが文字化けで表示される、という問題が発生している。
これが「UseUTF8」の値を「1」に設定することで文字化けが解消されることは確認できた。
さて、本題に戻って、ja_JP.PCK_v2ボリューム上に日本語ディレクトリがある場合にエラーとなる件の対処方法があるかです。
とりあえずボリューム名をクリックするとバックアップ選択はされ、バックアップも完了できました。(レジストリ UseUTF8は0で実施)
リストアを選択すると、きちんと日本語で表示されています。
共有内のファイルを削除してリストアしてみると、正常にリストアされました。
しかし、「実験」だけをリストアしようとするとエラーとなりました。
というわけで、ja_JP.PCK_v2上に日本語ディレクトリがあっても、ボリューム全体をバックアップするのであれば問題無く動作する。
リストア時も全体であればリストアが成功するが、日本語ディレクトリは個別に指定するリストアは失敗する、という動作となりました。
ちなみにja_JP.UTF-8ボリューム上の日本語ディレクトリは文字化けでした。(レジストリUseUTF8は0)
文字化けしている状態であっても、文字化けディレクトリだけを指定してリストアすると正常にリストアできていました。(レジストリUseUTF8は0)
逆にレジストリUseUTF8を1にしてバックアップしたものはリストアできるか検証
ja_JP.UTF-8ボリューム上の日本語は表示できているが、ja_JP.PCK_v2ボリューム上は文字化けています。
リストアジョブを実行してみると成功します。
ja_JP.UTF-8ボリュームではファイル名も問題無くリストアできています。
ja_JP.PCK2_v2の方は文字化けでリストアされています。
ややこしいことにディレクトリ内のファイルについては文字化けせずにリストアされています。
おそらく、指定した階層についてだけ影響があり、それ以下の階層についてはNetApp側で処理されるため元のファイル名のままリストアできたものと想定されます。
NetApp ONTAP 9.xでNDMPバックアップを取得する際に必要な設定項目についての覚え書き
公式のマニュアル:SVMを対象としたNDMPの設定 と FlexVolのSVMを対象としたNDMPモードの管理
以前は各物理ノードがNDMPを受け付けていたものが、現在はNetAppの管理Storage VM(クラスタ)がNDMPの命令を受け付けるようになっている。
まず、現状有効になっているかを「vserver services ndmp status」を実行して確認する。
ontap-select-cluster::> vserver services ndmp status
This table is currently empty.
ontap-select-cluster::>
有効にするには「vserver services ndmp on -vserver 管理SVM名」を実行する
ontap-select-cluster::> vserver services ndmp on -vserver ontap-select-cluster
ontap-select-cluster::>
有効になったことを「vserver services ndmp show」を実行して確認する。
ontap-select-cluster::> vserver services ndmp show
VServer Enabled Authentication type
------------- --------- -------------------
ontap-select-cluster
true challenge
svm0 false challenge
2 entries were displayed.
ontap-select-cluster::>
NDMPアクセス用のユーザを、NetAppのローカルユーザとして作成する。
下記の例では「backupadmin」というユーザを作成している。「role:backup」という権限で作成することが重要です。
なお、ここで指定するパスワードをそのままNDMPバックアップ時に指定するわけではありません。
ontap-select-cluster::> security login create -user-or-group-name backupadmin -application ssh -authmethod password -role backup
Please enter a password for user 'backupadmin':
Please enter it again:
ontap-select-cluster::>
NDMPバックアップ時に使用するパスワードは、自動生成のパスワードになります。
「vserver services ndmp generate-password -vserver 管理SVM名 -user ユーザ名」でパスワードを確認します。なお、ユーザ作成時のパスワードを元に生成しているので、generate-passwordを実行するたびにパスワードが変わるということはありません。
ontap-select-cluster::> vserver services ndmp generate-password -vserver ontap-select-cluster -user backupadmin
Vserver: ontap-select-cluster
User: backupadmin
Password: qG5CqQHYxw9fE57g
ontap-select-cluster::>
NDMPバックアップは、ネットワークインタフェースのroleがinterclusterであるものを使用します。
現状のinterclusterを確認するには「network interface show -role intercluster」を実行します
ontap-select-cluster::> network interface show -role intercluster
There are no entries matching your query.
ontap-select-cluster::>
存在しない場合は、新規で作成するか、既存のLIFを流用するための設定を行います。
流用する場合は公式マニュアルの「LIFの設定」をみていろいろやります。（面倒くさいはず）
作成する際は、「-home-node」と「-home-port」で主として使用する物理ノードとネットワークポートを指定します。
ontap-select-cluster::> network interface create -vserver ontap-select-cluster -lif cluster_intercluster -role intercluster -service-policy default-intercluster -address 172.17.44.109 -netmask 255.255.0.0 -home-node ontap-select-node -home-port e0a
ontap-select-cluster::>
作成されたことを「network interface show -role intercluster」を実行して確認します。
ontap-select-cluster::> network interface show -role intercluster
Logical Status Network Current Current Is
Vserver Interface Admin/Oper Address/Mask Node Port Home
----------- ---------- ---------- ------------------ ------------- ------- ----
ontap-select-cluster
cluster_intercluster
up/up 172.17.44.109/16 ontap-select-node
e0a true
ontap-select-cluster::>
「vserver show -ins」で表示される「Allowed Protocols」「Disallowed Protocols」の扱い
物理ノードに対するNDMPが有効になっていないか？「system service ndmp show」で「Enabled:false」を確認
対象となるSVMと、必要となるロールの違い:SVMを対象としたNDMPモードでのユーザ認証
Storage Virtual Machine（SVM）を対象としたNDMPモードでは、NDMPユーザ認証がロールベース アクセス制御と統合されます。SVMのコンテキストでは、NDMPユーザのロールは
vsadminまたはvsadmin-backupのどちらかである必要があります。クラスタのコンテキストでは、NDMPユーザのロールはadminまたはbackupのどちらかである必要があります。
SVMのfirewall policy設定でinterclusterのポリシーでNDMPが許可されているか「system services firewall policy show -policy intercluster」
NetApp NDMP設定の詳細確認「vserver services ndmp show -ins」の「Preferred Interface Role」に書かれているroleのインタフェースがNDMPに使用できる
NDMPバックアップ中の進行状況確認を行う場合「vserver services ndmp status -fields data-state,data-operation,data-bytes-processed,mover-bytes-moved,mover-bytes-left-to-read,data-path」あたりを実行？
netapp9101::> vserver services ndmp status -fields data-state,data-operation,data-bytes-processed,mover-bytes-moved,mover-bytes-left-to-read,data-path
vserver session-id data-state data-operation data-bytes-processed mover-bytes-moved mover-bytes-left-to-read data-path
---------- ---------- ---------- -------------- -------------------- ----------------- ------------------------ ---------
netapp9101 1000:26573 IDLE NOACTION 0 0 0 NA
netapp9101 1000:26718 ACTIVE BACKUP 6694621184 0 0 /svm0/shares
netapp9101 1000:26726 IDLE NOACTION 0 0 0 NA
netapp9101 1000:26730 IDLE NOACTION 0 0 0 NA
netapp9101 1000:26736 IDLE NOACTION 0 0 0 NA
netapp9101 1000:26745 IDLE NOACTION 0 0 0 NA
6 entries were displayed.
netapp9101::>
mover-bytes-moved と mover-bytes-left-to-read はテープ直結時じゃないと値がでない？
firewallなどで止められているか確認する際に、お互いのポート番号確認するのであれば「vserver services ndmp status -fields data-state,data-operation,data-bytes-processed,data-path,client-port,client-addr,data-con-addr,data-con-port」
netapp9101::> vserver services ndmp status -fields data-state,data-operation,data-bytes-processed,data-path,client-port,client-addr,data-con-addr,data-con-port
vserver session-id data-state data-operation data-con-addr data-con-port data-bytes-processed client-addr client-port data-path
---------- ---------- ---------- -------------- ------------- ------------- -------------------- ------------- ----------- ---------
netapp9101 1000:26573 IDLE NOACTION 0 0 172.17.44.172 55903 NA
netapp9101 1000:26718 ACTIVE BACKUP 172.17.44.172 56036 14100891648 172.17.44.172 55988 /svm0/shares
netapp9101 1000:26726 IDLE NOACTION 0 0 172.17.44.172 56044 NA
netapp9101 1000:26730 IDLE NOACTION 0 0 172.17.44.172 56077 NA
netapp9101 1000:26736 IDLE NOACTION 0 0 172.17.44.172 56116 NA
netapp9101 1000:26745 IDLE NOACTION 0 0 172.17.44.172 56156 NA
6 entries were displayed.
netapp9101::>
NDMPに使用するユーザに対してroleを割り当てた場合、適切な権限を設定していない場合下記のメッセージで失敗する
ontap91::> vserver ndmpd generate-password -vserver ontap91 -user backupadmin
Error: show failed: Cannot get password for user "backupadmin".
ontap91::>
これはroleに”vserver services ndmp”を”all”で設定していない場合に発生する
直接アクセスできないネットワークにあるNFSサーバをNFSでマウントすることはできないか試行錯誤してみた。
普通にCentOS7やSolaris11からやってみたところ、NFSマウントした領域のNFS exportでの公開はnfsd側から「Cannot export /mnt, possibly unsupported filesystem or fsid= required」とか、「Invalid filesystem」とか言われて設定できない。
これはuser-spaceで動作するnfsdを使えば回避できるんじゃないかと探してみた結果、unfs3というものを発見。ソースコードは https://github.com/unfs3/unfs3
Linux,FreeBSD,Solaris,AIX,Irix,MacOSXで動く以外に、Windows上でも制限ありで動作するとのこと。
Windows上で動かした場合は、unfsdが使用するWindowsユーザを１つ割り当てる形になるので、NFS経由のアクセスは全てそのWindowsユーザがアクセスしている、という扱いになるようだ。
あと、このunfs3はNFS ver3のみ使え、NFS v4やNFS v2でのアクセスには対応していない。また、NFS v3でもREADDIRPLUS(属性付きディレクトリの読み取り)周りは実装していないとのこと。
READDIRPLUSはOracle/Solarisのドキュメントによればlsコマンドなどでディレクトリ内のファイル一覧を表示させる動作を高速化するためのものなので、まぁ、なくてもなんとかなる感じのもの。
属性付きディレクトリの読み取り
NFS バージョン 3 では、READDIRPLUS と呼ばれる操作があります。たとえば、ls や ls -l などの、大部分の READDIR が READDIRPLUS コールとして発行されます。バージョン 3 で ls -l コマンドを実行すると、ディレクトリ内の名前リストと共に、ファイルハンドルと属性が返されます。バージョン 2 では、名前が最初に返され、ファイルハンドルと属性を取得するには、続いてサーバーを呼び出す必要があります。
バージョン 3 の READDIRPLUS 操作の利点は、ファイルごとに GETATTR 要求を送信する必要がないため時間が短縮され、ls と ls -l の速度が同程度になることです。
要件は満たせそうなので、とりあえずテスト用CentOS7環境でunfs3を動作させてみる。
環境をインストール
# yum install git
# yum groupinstall "開発ツール"
まず、ソースコードの入手
$ git clone https://github.com/unfs3/unfs3.git
READMEにあるとおりbootstrap&configureを実行
$ cd unfs3/unfs3
$ ./bootstrap
$ ./configure
そしてmake
$ make
for i in Config ; do (cd $i && make all) || exit; done
make[1]: ディレクトリ `/root/unfs3/Config' に入ります
gcc -g -O2 -Wall -W -I.. -I. -I.. -c -o lex.yy.o lex.yy.c
gcc -g -O2 -Wall -W -I.. -I. -I.. -c -o y.tab.o y.tab.c
ar crs lib.a lex.yy.o y.tab.o
make[1]: ディレクトリ `/root/unfs3/Config' から出ます
gcc -g -O2 -Wall -W -D_GNU_SOURCE -I. -c -o afsgettimes.o afsgettimes.c
gcc -g -O2 -Wall -W -D_GNU_SOURCE -I. -c -o afssupport.o afssupport.c
gcc -g -O2 -Wall -W -D_GNU_SOURCE -I. -c -o attr.o attr.c
attr.c: 関数 ‘get_free_bad_dir_entry’ 内:
attr.c:550:5: エラー: ‘for’ ループ初期化宣言は C99 モード内でのみ許可されてい ます
for (int i = 0;i < BAD_DIR_CACHE_SIZE;i++) {
^
attr.c:550:5: 備考: オプション -std=c99 または -std=gnu99 をコードコンパイル時に使用してください
attr.c: 関数 ‘find_bad_dir_entry’ 内:
attr.c:573:5: エラー: ‘for’ ループ初期化宣言は C99 モード内でのみ許可されてい ます
for (int i = 0;i < BAD_DIR_CACHE_SIZE;i++) {
^
make: *** [attr.o] エラー 1
$
エラーとなってしまいます。
これはコンパイル時のオプションに「-std=c99」を指定するようにして解決
$ export CPPFLAGS="-std=c99";./configure
$ make
＜略＞
$
普通にmake installすると/usr/local以下にインストールされます。
# make install
/usr/bin/install -c -d /usr/local/sbin
/usr/bin/install -c -d /usr/local/share/man/man7
/usr/bin/install -c -d /usr/local/share/man/man8
/usr/bin/install -c unfsd /usr/local/sbin/unfsd
/usr/bin/install -c -m 644 ./Extras/tags.7 /usr/local/share/man/man7/tags.7
/usr/bin/install -c -m 644 ./unfsd.8 /usr/local/share/man/man8/unfsd.8
#
NFSで公開するディレクトリの設定は、普通のnfsdと同じく /etc/exports ファイルを使用。「-e」オプションで別のファイルを指定することも可能です。
注意点としては、Linuxだとホスト名指定に「*」とnetgroupが使用できず、ログに「unfsd[20479]: syntax error in ‘/etc/exports’, exporting nothing」といった出力が出てしまうという点です。
「*」については「0.0.0.0/0」で代替できます。
/etc/exports ファイルを編集した場合、変更にはexportfsコマンドは使用できません。
unfsdに対してHUPシグナルを送ることで反映されます。(kill -HUP unfsdのPID)
unfsdの起動は「/usr/local/sbin/unfsd」の実行、停止はunfsdへのTERMシグナル送信(kill -TERM unfsdのPID)です。