LTO-4テープ書き込みソーススループットのニーズ
私はテープバックアップレジメンを開始し、データが十分な方法でテープドライブに流れるようにしたい（120 + MBのターゲットを維持）が、そうでないときにアイドル状態になる専用のソースドライブ/アレイなしでそれを行う方法を理解できない。テープを書く。特定のドライブのドキュメントには、最小スループットは必要ないと記載されています。
環境
- Linux Debianがmt＆tarを使用してテープに書き込み、RARアーカイブをリカバリレコードでバックアップします。各サイズは約1GB〜300GBです。
- QuantumTC-42BNテープドライブ上のLTO-4テープSAS over external SFF Cable
- サーバーはファイルのバックアップにのみ使用され、ネットワークサービスやファイルサービングは使用されません。
- データが断続的に読み取り/書き込みされるMDRAIDアレイは、昼夜を問わず急増します。
テープの書き込み中にソースアレイに（スケジュールされたバックアップからの）重要な読み取り/書き込みがある場合、テープへのスループットは一時的であっても劇的に低下します。したがって、ソースアレイ/テープの書き込みスループットを中心としたいくつかの質問：
- テープ書き込み中にソースのスループットが10〜20MB /秒（またはそれ以下）未満に持続的に低下することが問題になると思いますか？
- バックアップがスケジュールされていないことを保証するソースを用意する必要がありますか？基本的に最低2つのアレイ。 1つはバックアップ用、もう1つはアーカイブとテープ書き込み用ですか？
- テープの書き込みを他のすべてよりも優先できるドライブ/アレイのQOSはありますか？
- LTO-4テープドライブはスロットルを駆動しますが、LTO-4で維持する一般的なスループットの下限はありますか、それともドライブごとに大きく異なりますか？ 繰り返しになりますが、ドキュメントには最大設計速度と「可変速度転送」が記載されていますが、どのように可変であるかについては記載されていません。
- このソーススループットの方程式に何かが欠けているのでしょうか、それとも根拠のない心配がありますか？
更新：
コンシューマーSATAを搭載した4ドライブRAID6からテープにtarが書き込まれている間、アレイから約30MB /秒で600GBのアーカイブジョブを読み取ることで、単一のI/Oストリームで最小限の負担をかけることにしました。ドライブをリッスンすることで、テープのクロールは確実に遅くなりましたが、データが不足したり、靴磨きが不足したりすることはありませんでした。これは、ハードウェア構成の完全なスケジュールバックアップ中に物事が追いつくことを期待しないように指示しますが、書き込み中に負担の少ないI/Oジョブを処理できますテープに。
注意点として、LOT4テープは56のエンドツーエンドパスを実行する必要があるため、数秒間停止して速度を落とし、反対方向に「進む」前に、最大14GBのチャンクに効果的に書き込みます。これは、先読みおよび非同期書き込みがあるため、ドライブにデータを低スループットで「供給」するのに役立ったと思います。 stinit.def。に設定
もう1つの注意点は、「dd if =/dev/st0 of =/dev/null」の読み取りでは、107MB/sの結果しか生成されなかったことです。これは、thisドライブの実際の最大実効スループットであり、120 MB/sではないと思います。 ドライブは現在専用のSAS PCIe HBAにあり、他のPCIeカードはインストールされていません
それまでの間、1TB RAID0をDisk2Tapeバッファーとしてセットアップし、これを実現するためにサーバーに別のディスクを追加する必要がありました。
テープドライブに対して何らかのQOSを実行し、テープへの書き込みを最優先に設定して、アレイを簡素化し、寄生ハードウェアのコストを削減できるようにしたいと思っていますしかし、それまでの間、私はスケジュールされたジョブがアレイにヒットした場合でも継続的な書き込みを保証したい場合は、専用のdisk2tapeバッファーを使用しないようにする方法がわかりません。
mbufferは、maintain sustained data flow to the tape driveを行うのに役立つ小さくて便利なツールです。ほとんどのLinuxディストリビューションで利用できます。
mbuffer-I/O操作をバッファリングし、スループットレートを表示します。マルチスレッドであり、ネットワーク接続をサポートし、標準のバッファよりも多くのオプションを提供します。
オンザフライでのマルチスレッド圧縮の使用例：
tar cvf-/backupdir | lbzip2 | mbuffer -m 4G -L -P 80>/dev/st0
- tarファイルアーカイブへのファイルの追加を開始します
- （オプション）すべてのCPUコアを使用するには、lbzip2で圧縮します
- メモリバッファの充填を開始します
- 80％に達したら、テープドライブへのデータの送信を開始します
mbufferパラメータの説明：
-m 44GBのメモリバッファサイズ。必要または利用可能な場合は、より大きなバッファーを使用します。-Lメモリにロックされています（オプション）-P 80バッファの80％がいっぱいになった後、テープへの書き込みを開始します。テープドライブが書き込みを開始するまでに時間がかかるため、100を入力する必要はありません。おそらく、それまでに100％までいっぱいになります。
この例では、バッファが容量の80％までいっぱいになると、テープへのデータの送信を開始し、mbufferは引き続きアーカイブストリームを受信します。
アーカイブプロセスが遅く、mbufferがテープドライブに追いつくのに十分な速度でデータを受信していない場合、データが0％に達すると、テープドライブへのデータの送信を停止します。メモリバッファが80％までいっぱいになると、テープドライブへのデータの送信が開始され、記録はフルスピードで続行されます。
このようにして、テープの「靴磨き」が最小限に抑えられ、テープドライブは常にストリームを維持するために必要な最大速度でデータを取得します。
Mbufferを逆方向に使用して、テープドライブからバックアップデータを読み取り、ストリームを低速のメディアに保存したり、ネットワーク経由で送信したりすることもできます。
私が見つけた手動 は、30.5から120 MB/sまでの可変速度を約7MB/sの増分でリストします。
さらに、LTOドライブは、適度なサイズのバッファを使用してデータストリームを均等化し、速度調整のインジケータを提供します。したがって、読み取り速度が大きく変動したり、非常に遅い場合を除いて、バックヒッチングは最小限に抑える必要があります。
ややまともな配列と大きなファイルのデータでは、120 MB/sはそれほど問題にはならないはずです（ファイルシステムが高度に断片化されていない限り）。私たちのテープバッファは、RAID 0で2つの（遅い）4 TBドライブを使用します。これは、約270 MB/sを維持できますが、テープの書き込み中はバッファに書き込みません。