LTO-4テープ書き込みソーススループットのニーズ

LTO-4テープ書き込みソーススループットのニーズ

テープ バックアップ レジメンを開始し、十分な方法で (120 MB 以上のターゲットを維持) テープ ドライブにデータを流し続けたいと考えていますが、テープへの書き込み時以外はアイドル状態になる専用のソース ドライブ/アレイなしでそれを実現する方法がわかりません。特定のドライブのドキュメントには、必要な最小スループットは記載されていません。

環境

  • Linux Debian は、mt と tar を使用して、リカバリ レコード付きの RAR アーカイブをテープにバックアップします。各アーカイブのサイズは約 1 GB ~ 300 GB です。
  • 外部 SFF ケーブル経由の SAS 経由の Q​​uantum TC-42BN テープ ドライブ上の LTO-4 テープ
  • サーバーはファイルのバックアップのみに使用され、ネットワーク サービスやファイル提供には使用されません。
  • 昼夜を問わず断続的にデータの読み取り/書き込みが行われる MD RAID アレイ。

テープ書き込み中にソース アレイに大量の読み取り/書き込み (スケジュールされたバックアップから) が行われると、一時的であってもテープへのスループットが大幅に低下します。そのため、ソース アレイ/テープ書き込みスループットに関するいくつかの質問があります。

  1. テープ書き込み中にソースのスループットが 10 ~ 20 MB/秒 (またはそれ以下) まで継続的に低下すると問題になると思いますか?
  2. バックアップがスケジュールされていないことが保証されているソースが必要ですか? 基本的に、バックアップ用に 1 つ、アーカイブとテープ書き込み用に 1 つ、合計 2 つのアレイが必要ですか?
  3. テープへの書き込みを他のすべてよりも優先できるドライブ/アレイの QOS はありますか?
  4. LTO-4 テープ ドライブはスロットルしますが、LTO-4 で維持すべき共通のスループット下限値はありますか、それともドライブごとに大きく異なりますか? 再度、ドキュメントには最大設計速度と「可変速度転送」について記載されていますが、どのように可変かについては記載されていません。
  5. このソース スループットの式で何かを見落としているのでしょうか、それとも根拠のない心配をしているのでしょうか。

アップデート:

私は、コンシューマー SATA の 4 ドライブ RAID 6 からテープに tar が書き込まれている間に、アレイから 30MB/s 程度の速度で読み取る 600GB アーカイブ ジョブによる単一の I/O ストリームで負荷を最小限に抑えることにしました。ドライブのリスニングでテープは明らかに遅くなりましたが、データやシューシャインがなくなるようには見えませんでした。これは、スケジュールされたフル バックアップ中に状況が追いつくことを期待できないことを示しています。ハードウェア構成ただし、テープへの書き込み中に、負荷の少ない I/O ジョブを処理することはできます。

注目すべきは、LOT4テープは56回のエンドツーエンドパスを実行する必要があるため、数秒間停止して速度を落とし、その後逆方向に「進む」前に、約14GBのチャンクで書き込みを行うということです。これは、私が経験したように、低いスループットでもドライブにデータを「供給」し続けるのに役立ったと思います。先を読むそして非同期書き込みに設定されたスティニット.def.

もう一つの注意点は、「dd if=/dev/st0 of=/dev/null」の読み取りでは107MB/sしか得られなかったことです。これは、実際の最大有効スループットであると考えられます。これドライブの速度は 120 MB/秒ではありません。 ドライブは現在専用のSAS PCIe HBA上にあり、他のPCIeカードはインストールされていません。

その間、私は Disk2Tape バッファとして 1TB RAID0 をセットアップし、これを実現するためにサーバーに別のディスクを追加する必要がありました。

私は、テープドライブに何らかのQOSを実行し、テープへの書き込みを最優先に設定してアレイを簡素化し、ハードウェアの寄生コストを削減する方法を見つけたいと思っています。しかし、当面は、スケジュールされたジョブがアレイにどのような影響を与えても継続的な書き込みを確実に実行したい場合、専用の disk2tape バッファーを使用しない方法は見つかりません。

答え1

バッファは、次のことを行うのに役立つ小さくて便利なツールですmaintain sustained data flow to the tape drive。ほとんどの Linux ディストリビューションで利用できます。

mbuffer - I/O 操作をバッファリングし、スループット レートを表示します。マルチスレッドで、ネットワーク接続をサポートし、標準バッファよりも多くのオプションを提供します。


オンザフライのマルチスレッド圧縮の使用例:

tar cvf - /backupdir | lbzip2 | mbuffer -m 4G -L -P 80 > /dev/st0

  1. tarファイルアーカイブにファイルを追加し始める
  2. (オプション) すべてのCPUコアを使用するためにlbzip2で圧縮する
  3. メモリバッファの充填を開始する
  4. 80%まで満たされたら、テープドライブにデータを送信し始めます。

バッファパラメータの説明:

  • -m 4 4GB のメモリ バッファ サイズ。必要な場合や使用可能な場合は、より大きなバッファを使用します。
  • -L メモリにロック(オプション)
  • -P 80バッファの 80% が満たされた後にテープへの書き込みを開始します。テープ ドライブが書き込みを開始するまでに時間がかかり、その時点でおそらく 100% まで満たされるため、100 を設定する必要はありません。

この例では、バッファが容量の 80% までいっぱいになると、テープへのデータの送信が開始され、mbuffer はアーカイブ ストリームを受信し続けます。

アーカイブ処理が遅く、mbuffer がテープ ドライブに追いつくほどの速度でデータを受信して​​いない場合、0% に達するとテープ ドライブへのデータ送信が停止します。メモリ バッファが 80% まで満たされると、テープ ドライブへのデータ送信が開始され、記録はフル スピードで続行されます。

この方法により、テープの「靴磨き」が最小限に抑えられ、テープ ドライブは常にストリームを維持するために必要な最大速度でデータを取得します。

また、mbuffer を逆方向に使用して、テープ ドライブからバックアップ データを読み取り、ストリームをより低速のメディアに保存したり、ネットワーク経由で送信したりすることもできます。

答え2

私が見つけたマニュアル30.5 MB/秒から 120 MB/秒までの可変速度を約 7 MB/秒刻みでリストします。

さらに、LTO ドライブは適切なサイズのバッファを使用してデータ ストリームを均等化し、速度調整のインジケーターを提供するため、読み取り速度が大幅に変化したり非常に低速でない限り、バックヒッチは最小限に抑えられます。

ある程度まともなアレイ上のデータと大きなファイルであれば、120 MB/秒でも大した問題にはなりません (ファイルシステムが極度に断片化されていない限り)。当社のテープ バッファーは、約 270 MB/秒を維持できる RAID 0 の 2 つの (低速の) 4 TB ドライブを使用していますが、テープへの書き込み中はバッファーに書き込みません。

関連情報