web-dev-qa-db-ja.com

NetAppFilerのNDMP復元が遅い

これはFAS22408.2P37モードです

バックアップソフトウェア:EMC Networker 8.1

NDMPは、vFiler内で構成および実行されます。

バックアップから始めましょう。 Networkerのバックアップコマンドは次のとおりです。

nsrndmp_save -T dump

-M(DSA)を指定することもできますが、ここでは暗黙的だと思います。

アプリケーション情報は次のとおりです(新しいクライアントを使用してNetworkerでNDMPクライアントを再作成しただけですWizard安全のために):

USE_TBB_IF_AVAILABLE=Y
DIRECT=Y
BUTYPE=dump
HIST=Y
UPDATE=Y

完全バックアップは多かれ少なかれワイヤスピードで実行されます

> sysstat -x 5
CPU    NFS   CIFS   HTTP   Total     Net   kB/s    Disk   kB/s    Tape   kB/s  Cache  Cache    CP  CP  Disk   OTHER    FCP  iSCSI     FCP   kB/s   iSCSI   kB/s
                                       in    out    read  write    read  write    age    hit  time  ty  util                            in    out      in    out
29%      0      0      0       1     485  94867   98060     11       0      0     0s    91%    0%  -    90%       1      0      0       0      0       0      0
31%      0      0      0       1     502  97711  101518    490       0      0     0s    89%   13%  T    90%       1      0      0       0      0       0      0
32%      0      0      0      57     530 103167  107344    251       0      0     0s    89%    5%  Zf   88%      57      0      0       0      0       0      0
30%      0      0      0      41     552 107049  110286    222       0      0     0s    89%    7%  :    87%      41      0      0       0      0       0      0

ただし、テープから復元する場合、平均で約10MB /秒しか得られません。テープへのバックアップは他に何も実行されていないときに行われたため、問題はデータがテープ上でインターリーブされることではありません。

Networkerからのコマンドと出力は次のとおりです(空のボリュームへの復元):

# nsrndmp_recover -S 1760972238 -m /vol/vfprod_xtest /vol/vfprod_x
42795:nsrndmp_recover: Performing recover from Non-NDMP type of device
85183:nsrndmp_recover: DSA is listening for an NDMP data connection on: 1.2.4.5, port = 8745
42690:nsrndmp_recover: Performing non-DAR Recovery..
86724:nsrdsa_recover: DSA listening at: Host 'backupserv', IP address '1.2.4.5', port '8745'.
42937:nsrdsa_recover: Performing Immediate recover
42940:nsrdsa_recover: Reading Data...
42617:nsrndmp_recover: NDMP Service Log: RESTORE: Dump came from a SnapLock volume.
42617:nsrndmp_recover: NDMP Service Log: RESTORE: Incremental restores to SnapLock volumes are not supported.
All files will be correctly restored, but subsequent restores
of incremental backups will not recreate the file system as
it appeared during the final incremental backup.
42617:nsrndmp_recover: NDMP Service Log: RESTORE: ./.etc/gid_map: cannot create file: Read-only file system
42617:nsrndmp_recover: NDMP Service Log: RESTORE: Sat Feb  8 14:52:25 2014: Writing data to files.
42617:nsrndmp_recover: NDMP Service Log: RESTORE: Sat Feb  8 14:56:43 2014 : We have read 3361690 KB from the backup.
42617:nsrndmp_recover: NDMP Service Log: RESTORE: Sat Feb  8 15:01:43 2014 : We have read 7053433 KB from the backup.
42617:nsrndmp_recover: NDMP Service Log: RESTORE: Sat Feb  8 15:06:43 2014 : We have read 10908694 KB from the backup.
42617:nsrndmp_recover: NDMP Service Log: RESTORE: failed to find the file
42617:nsrndmp_recover: NDMP Service Log: RESTORE: Sat Feb  8 15:11:22 2014: Restoring NT ACLs.
42617:nsrndmp_recover: NDMP Service Log: RESTORE: RESTORE IS DONE
42942:nsrdsa_recover: Reading data...DONE.
42927:nsrndmp_recover: Successfully done

復元中のファイラーの統計は次のとおりです

>sysstat -x 5
CPU    NFS   CIFS   HTTP   Total     Net   kB/s    Disk   kB/s    Tape   kB/s  Cache  Cache    CP  CP  Disk   OTHER    FCP  iSCSI     FCP   kB/s   iSCSI   kB/s
                                       in    out    read  write    read  write    age    hit  time  ty  util                            in    out      in    out
91%      0      0      0      35   15364    143    5369  20946       0      0     0s    98%   56%  H    55%      35      0      0       0      0       0      0
91%      0      0      0      20   14668    126    5135  20617       0      0    59s    98%   56%  H    56%      20      0      0       0      0       0      0
91%      2      0      0       3   14407    119    5685  20954       0      0     1     98%   53%  H    52%       1      0      0       0      0       0      0
91%      0      0      0       1   15564    154    5454  20711       0      0     1     98%   56%  Hf   53%       1      0      0       0      0       0      0
91%      0      0      0       2   14447    121    6502  14358       0      0     1     98%   42%  Hf   56%       2      0      0       0      0       0      0
...
92%      6      0      0       6   19503    245    4696  15072       0      0     1     98%   46%  :    56%       0      0      0       0      0       0      0
93%      0      0      0       3   18902    253    7667  13669       0      0     0s    98%   22%  Hf   63%       3      0      0       0      0       0      0
91%      6      0      0       7   18099    216    1957  32432       0      0     0s    97%  100%  :f   45%       1      0      0       0      0       0      0
91%      6      0      0       6   16111    153    4427  23419       0      0     0s    98%   55%  :    56%       0      0      0       0      0       0      0
92%      7      0      0       7   15629    156    8155      0       0      0     1     98%    0%  -    68%       0      0      0       0      0       0      0
91%      0      0      0       3   14226    125    4427  32453       0      0     1     99%   79%  Hf   53%       3      0      0       0      0       0      0
94%      6      0      0       6   32264    594     744  38453       0      0     2     97%  100%  :f   45%       0      0      0       0      0       0      0
92%      6      0      0       6   14781    127    9846     59       0      0     2     98%    7%  Hn   61%       0      0      0       0      0       0      0
90%      6      0      0      63   11546     57    2073  42592       0      0     2     99%  100%  :f   50%      57      0      0       0      0       0      0

CPU使用率は、ディスク使用率が高いバックアップと比較して高いようです。

2つのファイラー間で同じことを行うと、平均で約40MB /秒になります。

na1> ndmpcopy -sa root:xx -da root:xx /vol/vfprod_x/fs1 na2:/vol/test/xtest
Ndmpcopy: Starting copy [ 1 ] ...
Ndmpcopy: na1: Notify: Connection established
Ndmpcopy: na2: Notify: Connection established
Ndmpcopy: na1: Connect: Authentication successful
Ndmpcopy: na2: Connect: Authentication successful
Ndmpcopy: na1: Log: DUMP: creating "/vol/vfprod_x/../snapshot_for_backup.10825" snapshot.
Ndmpcopy: na1: Log: DUMP: Dumping from a SnapLock volume
Ndmpcopy: na1: Log: DUMP: Using subtree dump
Ndmpcopy: na1: Log: DUMP: Date of this level 0 dump: Sat Feb  8 15:23:04 2014.
Ndmpcopy: na1: Log: DUMP: Date of last level 0 dump: the Epoch.
Ndmpcopy: na1: Log: DUMP: Dumping /vol/vfprod_x/fs1 to NDMP connection
Ndmpcopy: na1: Log: DUMP: mapping (Pass I)[regular files]
Ndmpcopy: na1: Log: DUMP: mapping (Pass II)[directories]
Ndmpcopy: na2: Log: RESTORE: Dump came from a SnapLock volume.
Ndmpcopy: na1: Log: DUMP: estimated 16178315 KB.
Ndmpcopy: na1: Log: DUMP: dumping (Pass III) [directories]
Ndmpcopy: na1: Log: DUMP: dumping (Pass IV) [regular files]
Ndmpcopy: na2: Log: RESTORE: Sat Feb  8 15:23:12 2014: Begin level 0 restore
Ndmpcopy: na2: Log: RESTORE: Sat Feb  8 15:23:12 2014: Reading directories from the backup
Ndmpcopy: na2: Log: RESTORE: Sat Feb  8 15:23:13 2014: Creating files and directories.
Ndmpcopy: na2: Log: RESTORE: Sat Feb  8 15:23:31 2014: Writing data to files.
Ndmpcopy: na1: Log: DUMP: Sat Feb  8 15:28:11 2014 : We have written 12577964 KB.
Ndmpcopy: na2: Log: RESTORE: Sat Feb  8 15:28:11 2014 : We have read 12575988 KB from the backup.
Ndmpcopy: na1: Log: ACL_START is '16565304320'
Ndmpcopy: na1: Log: DUMP: dumping (Pass V) [ACLs]
Ndmpcopy: na1: Log: DUMP: 16177066 KB
Ndmpcopy: na1: Log: DUMP: DUMP IS DONE
Ndmpcopy: na2: Log: RESTORE: Sat Feb  8 15:29:36 2014: Restoring NT ACLs.
Ndmpcopy: na1: Log: DUMP: Deleting "/vol/vfprod_x/../snapshot_for_backup.10825" snapshot.
Ndmpcopy: na1: Log: DUMP_DATE is '5686836680'
Ndmpcopy: na1: Notify: dump successful
Ndmpcopy: na2: Log: RESTORE: RESTORE IS DONE
Ndmpcopy: na2: Notify: restore successful
Ndmpcopy: Transfer successful [ 0 hours, 6 minutes, 41 seconds ]
Ndmpcopy: Done

https://communities.netapp.com/thread/1589 で提案されているように、オプションndmpd.tcpnodelay.enable onも試してみましたが、効果はありませんでした。

ファイラーを10GbEカードで購入したので、ファイラーは少なくとも実際に配信できる可能性がありますが、現時点ではそれが実現するかどうかはわかりません。

テストに使用したボリュームは、基盤となる10x 7200rpm SATAディスク(8個使用可能、ダブルパリティ)を備えたスナップロックアグリゲートにあります。

このシナリオでは、大量のデータを復元する必要がある日は、数TBを復元するのに十分な時間ではないため、地獄になります...

誰か役に立つアイデアがありますか?

ありがとう。


UPDATE#1

NDMPとは無関係ですが、私は10MB/sをほぼ常に読んでいるので、 ここ このスクリプトを使用して取得したパフォーマンス統計です。

#!/bin/sh
#
if [ -z $1 ]; then
echo " "
echo "I need a filer target"
echo "An example syntax"
echo " $0 filer01.msg.dcn"
echo " "
exit 0
fi

SSH="ssh -i /root/.ssh/id_rsa-netapp"

FILER=$1
#
DATAFILE="${FILER}_$(date +%Y%m%d%H%M)"
echo "" >> $DATAFILE
date >> $DATAFILE
echo "------------------------------" >> $DATAFILE
$SSH $FILER 'priv set -q diag; statit -b' 2>/dev/null
echo "Starting statit sample" >> $DATAFILE
$SSH $FILER 'priv set -q diag; nfsstat -z' 2>/dev/null
echo "Zeroing nfsstat" >> $DATAFILE
$SSH $FILER 'priv set -q diag; nfs_hist -z' 2>/dev/null
echo "Zeroing nfs_hist" >> $DATAFILE
$SSH $FILER 'priv set -q diag; wafl_susp -z' 2>/dev/null
echo "Zeroing wafl_susp" >> $DATAFILE
$SSH $FILER 'sysstat -xs -c 30 1' >> $DATAFILE

# And we wait...

$SSH $FILER 'priv set -q diag; statit -en' >> $DATAFILE 2>/dev/null
$SSH $FILER 'priv set -q diag; nfsstat -d' >> $DATAFILE
$SSH $FILER 'priv set -q diag; nfs_hist' >> $DATAFILE
$SSH $FILER 'priv set -q diag; wafl_susp -w' >> $DATAFILE

echo " ** " >> $DATAFILE

出力は here にあります。

このファイラーには768MBのNVRAMがあり、作業中のアグリゲートにはRAID-5に10個の7200rpmSATAディスクがあることに注意してください。


UPDATE#26月10日

前の例でなぜこれほど多くの最高水準点に達したのかはわかりませんが、今のところ、サポートの助けを借りて次のことを発見しました。

  • ファイラーは常にディスクをスクラブしているため、10MB /秒の読み取りは正常のようです。
  • コントローラのフェイルオーバーを無効にすると(cf disable)、NDMPの復元(つまり書き込み)が5倍以上の速度(50-100MB/s)で進行します。これは予想されることです。

それでも、なぜ彼らが最大で10Gカードを販売したのかはわかりません。 100MB/sですが、これからも続けます。特に、私が理解している限り、WAFLは常にすべてのディスクを使用して、可能な限り多くのスピンドルに書き込みを分散します。このファイラーは、「BSAS」だけであるにもかかわらず、約20個のディスクを使用します。

1
Marki

上記の出力の最も興味深い部分は、ダンプ中に収集されたsystatです。ペグされたCPUが表示されますが、systat -x CPU出力は、コアごとの平均ではなく、最も高いペグされたCPUのみを表示するため、誤解を招く可能性があります。しかし、他にも興味深いことがあります。私たちはほぼ常にCPを実行しており、それらはH CP(最高水準点)です。これは、ディスクにコミットされるNVRAM内のデータが最高水準点を超えたことを示します。したがって、NVRAMデータをディスクにフラッシュしようとするクライアント要求をブロックします。しかし、複雑なことに、私たちが行っているのは約20〜25MB /秒で、CPは毎秒発生しており、完了するまでに3秒かかることもあります。その数学はチェックアウトしません。 HAパートナーごとのNVRAMサイズが2240で何であるかはわかりませんが、ヘッドあたり少なくとも256MBであり、おそらくそれよりも大きいことはわかっています。 25MB /秒では、最高水準点に達するのに8〜10秒かかります。とにかくその前にコミットしますが、これはここで見ているものではありません。

上記のすべての出力は、ファイラーが舞台裏で何か他のことをしていることを示唆しています。 systat -mを掘り下げて、どのドメインが最もアクティブであるかを確認することをお勧めします。それがカフナであり、1つのコアが100%で固定されている場合、WAFLのボトルネックにぶつかる可能性があります。発生している可能性のあるその他のバックグラウンド処理(sisジョブ、snap *ジョブなど)も評価します。

自分で追跡できない場合は、perfstatを収集しながら問題を再現し、NetAppサポートに連絡してください。

1
Adam Drew

まず、2240はローエンドRAMを備えたローエンドシステムの1つです。私が信じる「H」CPタイプは「最高水準点」であり、その後も「f」が表示されます。これは、CPが書き込みを終了する前にNVMEMの1/2が満たされていることを意味します。

結論として、書き込みパフォーマンスは、a)システム内のNVMEM/NVRAMの量と、システムがディスクにブラストアウトできるスピンドルの数を組み合わせて、書き込みキャッシュをできるだけ早くクリアすることによって制限されます。

ここにあるsysstatは、常にCPにいることを示しているため、スピンドルにバインドされている可能性が高いことを示しているように見えます。 「statit-b」(1分待つ)と「statit-e」の出力を投稿した場合は、確実です。最初に「privsetadvanced」を確認してください。

0
Glenn Dekhayser

Systat-mをチェックしてください。そのファイラーは別のことをしています。そうしないと、わずか20m/sのIOでCPチェックポイントにそれほど速く到達できませんでした。テスト中にバックグラウンドで何かが実行されているか、ある種の奇妙なバグが発生しています。

パフォーマンスチームの人たちはこのようなものが大好きです。 ndmpの実行中にperfstatをキャプチャし、技術的なperfケースを開きます。

0
Aszurom