Ich möchte mit der Sicherung auf Band beginnen und dafür sorgen, dass die Daten ausreichend (Ziel: 120+MBs) auf das Bandlaufwerk fließen, weiß aber nicht, wie das ohne ein dediziertes Quelllaufwerk/Array geht, das im Leerlauf läuft, wenn keine Bänder geschrieben werden. In der Dokumentation für unser spezielles Laufwerk wird kein erforderlicher Mindestdurchsatz erwähnt.
Umgebung
- Linux Debian schreibt auf Band mit mt & tar und sichert RAR-Archive mit Wiederherstellungsdatensatz, jedes ~1 GB-300 GB groß
- LTO-4-Bänder auf Quantum TC-42BN-Bandlaufwerk über SAS über externes SFF-Kabel
- Der Server wird nur für Dateisicherungen verwendet, keine Netzwerkdienste oder Dateibereitstellung.
- MD-RAID-Arrays, bei denen Daten den ganzen Tag/die ganze Nacht über sporadisch gelesen/geschrieben werden.
Wenn das Quellarray während eines Bandschreibvorgangs erhebliche Lese-/Schreibvorgänge (von geplanten Backups) aufweist, würde der Durchsatz zum Band, wenn auch nur vorübergehend, dramatisch sinken. Daher einige Fragen zum Durchsatz des Quellarrays/Bandschreibvorgangs:
- Ich gehe davon aus, dass ein anhaltender Durchsatzabfall auf unter 10–20 MB/s (oder weniger) auf der Quelle während des Schreibens auf Band ein Problem darstellen würde?
- Muss ich eine Quelle haben, für die garantiert keine Backups geplant sind? Im Wesentlichen mindestens 2 Arrays, eines für Backups und eines für Archive und Bandaufzeichnungen?
- Gibt es eine QOS für Laufwerke/Arrays, die dem Schreiben auf Bänder Vorrang vor allem anderen geben könnte?
- LTO-4-Bandlaufwerke drosseln. Gibt es also eine gemeinsame untere Durchsatzgrenze, die für LTO-4 eingehalten werden muss, oder variiert diese stark je nach Laufwerk? Auch hier wird in der Dokumentation die maximal vorgesehene Geschwindigkeit und „Übertragungen mit variabler Geschwindigkeit“ erwähnt, jedoch nicht, wie variabel diese sind.
- Übersehe ich etwas in dieser Quelle-Durchsatz-Gleichung oder mache ich mir unbegründete Sorgen?
Aktualisieren:
Ich habe mich entschieden, die Dinge minimal zu belasten, indem ich einen einzigen I/O-Stream über einen 600 GB-Archivierungsauftrag verwendete, der mit etwa 30 MB/s vom Array las, während ein Tar von einem 4-Laufwerk-RAID 6 mit Consumer-SATA auf das Band geschrieben wurde. Das Band wurde durch das Abhören des Laufwerks definitiv langsamer, aber es schien NICHT, als ob die Daten oder der Schuhputz ausgingen. Das sagt mir, dass ich NICHT erwarten sollte, dass die Dinge während einer vollständigen geplanten Sicherung fürunsere HardwarekonfigurationEs kann jedoch einen weniger anspruchsvollen E/A-Job beim Schreiben auf Band bewältigen.
Bemerkenswert ist, dass die LOT4-Bänder 56 End-to-End-Durchläufe durchführen müssen, damit sie effektiv in ~14 GB-Blöcken schreiben, bevor sie für einige Sekunden anhalten, um langsamer zu werden und dann in die andere Richtung zu „gehen“. Ich denke, dies hat geholfen, das Laufwerk mit Daten bei geringerem Durchsatz „zu füttern“, da ichlesen Sie weiterUndasynchrones Schreibengesetzt in derstinit.def.
Ein weiterer Hinweis ist, dass das Lesen von "dd if=/dev/st0 of=/dev/null" nur ein Ergebnis von 107 MB/s ergab. Ich würde annehmen, dass dies der tatsächliche maximale effektive Durchsatz vonDasdas Laufwerk und NICHT 120 MB/s. Das Laufwerk befindet sich derzeit auf einem dedizierten SAS-PCIe-HBA, auf dem keine anderen PCIe-Karten installiert sind.
In der Zwischenzeit habe ich ein 1-TB-RAID0 als Disk2Tape-Puffer eingerichtet und musste dem Server eine weitere Festplatte hinzufügen, um dies zu ermöglichen.
Ich würde immer noch gerne einen Weg finden, eine Art QOS für das Bandlaufwerk zu erreichen und das Schreiben auf Band mit höchster Priorität zu versehen, damit wir unsere Arrays vereinfachen und die Kosten für parasitäre Hardware reduzieren können., aber in der Zwischenzeit sehe ich keinen Weg, um einen dedizierten Disk2Tape-Puffer zu umgehen, wenn ich kontinuierliche Schreibvorgänge sicherstellen möchte, unabhängig davon, welche geplanten Jobs auf das Array zugreifen.
Antwort1
Derm-Pufferist ein kleines und praktisches Tool, das Ihnen dabei helfen kann maintain sustained data flow to the tape drive. Es ist auf den meisten Linux-Distributionen verfügbar.
mbuffer - puffert I/O-Operationen und zeigt die Durchsatzrate an. Es ist multithreaded, unterstützt Netzwerkverbindungen und bietet mehr Optionen als der Standardpuffer.
Beispielverwendung mit mehrthreadiger Komprimierung im laufenden Betrieb:
tar cvf - /Sicherungsverzeichnis | lbzip2 | mbuffer -m 4G -L -P 80 > /dev/st0
- Beginnen Sie mit dem Hinzufügen von Dateien zum TAR-Dateiarchiv
- (optional) komprimieren Sie es mit lbzip2, um alle CPU-Kerne zu nutzen
- Beginnen Sie mit dem Füllen des Speicherpuffers
- Sobald es zu 80 % gefüllt ist, beginnen Sie mit dem Senden von Daten an das Bandlaufwerk
m-PufferParameter erklärt:
-m 44 GB Speicherpuffergröße. Verwenden Sie bei Bedarf oder Verfügbarkeit einen größeren Puffer.-Lim Speicher gesperrt (optional)-P 80Beginnen Sie mit dem Schreiben auf das Band, nachdem 80 % des Puffers gefüllt sind. Sie müssen nicht 100 eingeben, da es einige Zeit dauert, bis ein Bandlaufwerk mit dem Schreiben beginnt, und es bis dahin wahrscheinlich zu 100 % gefüllt sein wird.
Sobald der Puffer in diesem Beispiel zu 80 % gefüllt ist, beginnt er mit dem Senden von Daten an das Band und mbuffer empfängt weiterhin den Archivdatenstrom.
Wenn der Archivierungsprozess langsam ist und mbuffer die Daten nicht schnell genug empfangen hat, um mit dem Bandlaufwerk Schritt zu halten, wird er aufhören, Daten an das Bandlaufwerk zu senden, sobald er 0 % erreicht. Sobald der Speicherpuffer zu 80 % gefüllt ist, beginnt er, Daten an das Bandlaufwerk zu senden, und die Aufzeichnung wird mit voller Geschwindigkeit fortgesetzt.
Auf diese Weise wird das „Schuhputzen“ des Bandes auf ein Minimum reduziert und das Bandlaufwerk ruft die Daten immer mit der Höchstgeschwindigkeit ab, die es zum Aufrechterhalten des Datenstroms benötigt.
Sie können mBuffer auch in umgekehrter Richtung verwenden, um Sicherungsdaten von einem Bandlaufwerk zu lesen und den Stream auf einem langsameren Medium zu speichern oder über das Netzwerk zu senden.
Antwort2
DerHandbuch habe ich gefundenlistet variable Geschwindigkeiten von 30,5 bis 120 MB/s in Schritten von ~7 MB/s auf.
Darüber hinaus verwenden LTO-Laufwerke Puffer angemessener Größe, um den Datenstrom auszugleichen und einen Indikator für die Geschwindigkeitsanpassung bereitzustellen. Sofern die Lesegeschwindigkeit also nicht stark schwankt oder sehr niedrig ist, sollte das Backhitching minimal sein.
Bei Daten auf einem einigermaßen ordentlichen Array und großen Dateien sollten 120 MB/s kein großes Problem darstellen (es sei denn, das Dateisystem ist stark fragmentiert). Unser Bandpuffer verwendet zwei (langsame) 4-TB-Laufwerke in RAID 0, die ungefähr 270 MB/s aufrechterhalten können, aber wir schreiben nicht in den Puffer, während Bänder geschrieben werden.