Optimierung d. Geschwindigkeit v. Backups

[Ingo S]

Hallo zusammen

Wir haben auf einigen Systemem sehr viele ziemlich kleine Dateien die wir regelmäßig sichern müssen. Diese liegen auf VMs in Ceph. Da Ceph bei solchen sehr kleinen Dateien und vielen Zugriffen sehr langsam ist, dauert die Sicherung auf Band trotz einer relativ kleinen Datenmenge mehrere Stunden. Da wir unsere Sicherung auch aus Platzgründen neu aufstellen müssen haben wir uns ein neues Konzept ausgedacht mit dem wir das lösen wollen.

Die Idee ist, einen Backup-Server zu erstellen, der genug Speicherplatz hat, um die zu sichernden Daten zwischen zu speichern. Die große Menge kleiner Dateien wird dabei jeweils Sonntags in einem frischen tar-Archiv gelagert. Täglich wird dann jeweils das tar Archiv mit den neuen oder geänderten Dateien aktualisiert, bis das tar-Archiv am nächsten Sonntag wieder durch ein frisches ersetzt wird.
Von diesem Zwischenspeicher aus soll dann täglich die Datensicherung erfolgen. Dadurch können wir die kleinen Dateien als großen Blob sichern.

Bei der Hardware müssen wir ein wenig aufs Budget achten. Daher soll der Speicher aus normalen Consumer SSDs bestehen, die wir an einem "SSD-fähigen" HBA anschließen. Den Storage würde ich dann mit Btrfs oder mit ZFS als Software RAID5 bauen.

Hat jemand Anregungen zu diesem Konzept? Ideen wie man das besser machen kann? Irgendwelche Katastrophen in Sicht, an die wir gerade nicht denken?
Außerdem:

• Brauche ich für so ein Software RAID5 eine Menge CPU Power?
• Welcher HBA eignet sich für sowas? TRIM muss ja durchgereicht werden etc. und bei den einschlägigen Herstellern finde ich deren Werbe Bla Bla irgendwie verwirrend.

Vielleicht kann mir jemand ein paar Tipps geben auf was ich da achten muss.

 

[Lephisto]

Consumer ssd für Server sind keine gute Idee. Wenigstens PLP sollten sie können, ansonsten sind die Tränen nach einem Stromausfall groß.

Zudem habe ich nicht ganz verstanden warum die SSD im Backup Server das Backup schneller machen sollen wenn das ceph von dem die Daten kommen schon zu langsam ist?

 

[Ingo S]

Also die SSDs sollen lediglich als Puffer dienen. Die ursprünglichen Daten bleiben ja da wo sie sind und das Backup läuft ja dann auf Band. Bei einem Stromausfall während des Backupjobs, der so lange dauert das die USV nicht ausreicht, würde das Backup sowieso fehlschlagen, bzw. wir würden dann sowieso die Server sauber runterfahren.

Der eigentliche Trick der das ganze schneller machen soll ist, quasi das Vollbackup Sonntags zu erstellen und unter der Woche nur noch die geänderten Dateien im Archiv zu aktualisieren. Dadurch fällt weniger IO an, weil weniger Dateien betroffen sind. Das eigentliche Backup kann dann an einem beliebigen Zeitpunkt jeden Tages laufen weil wir die Daten nur noch vom Backup Cache holen statt vom Live System.
Außerdem wird sich die zu sichernde Datenmenge etwa um das 4-5 Fache erhöhen und das aktuelle Backup braucht bereits jetzt etwa 9h für etwas über 1TB. Das liegt aber meiner Meinung nach nicht am Bandlaufwerk, sondern eher an den Quellen und an der Vielzahl der Dateien. Ich glaube nicht das LTO5 bei 35MB/s seine Grenze erreicht.

Außerdem suche ich gerade nach einer Möglichkeit die Dateizugriffe beim Erstellen des tar Archivs zu parallelisieren, da die Performance von Ceph stark mit Parallelisierung skaliert. Leider liest tar selbst Dateien grundsätzlich nur seriell. Daher werde wohl irgendwie ein Konstrukt bauen müssen das eine Dateiliste erstellt und diese dann irgendwie in Chunks einteilt, die parallel ge-tar-ed werden können.

Vielleicht verrennen wir uns hier im Büro aber auch irgendwie.
Wie optimiert ihr Backups von Verzeichnissen mit hunderttausenden von Dateien (Office Dokumente, PDFs etc.) ?

 

[Lephisto]

Eine USV hilft Dir auch nicht bei einem Netzteilproblem zB. PLP ist unbedingtes muss. So viel teurer sind die DC SSDs tatsächlich auch nicht, daß ich das riskieren würde.

Was nicht so ganz klar ist - das Ceph läuft derzeit auf HDD's?

Ich backuppe in zwei Strategien. Einmal "klassisch" mit Bacula und Filedaemon, mit all seinen bekannte schwächen und performanceproblemen bei unfassbar vielen kleinen Files, und zweitens mache ich zweimal täglich RBD Snapshots. Das geht richtig richtig schnell und dient in erster Linie DR zwecken und soll keinen Ersatz für ein traditionelles Backup darstellen. Wenn du das Ceph auf SSD's laufen hast, sollte es eigentlich auch kein Performanceproblem geben.

 

[Ingo S]

Eine USV hilft Dir auch nicht bei einem Netzteilproblem zB. PLP ist unbedingtes muss. So viel teurer sind die DC SSDs tatsächlich auch nicht, daß ich das riskieren würde.

Hmm also ich sehe das Problem nicht. Wenn der Backup-Server abraucht weil das Netzteil oder was Anderes platzt, dann fällt für den Tag halt das Backup aus. Es sind davon weder Produktivdaten, noch die Daten die von den vorigen Sicherungen auf Band liegen betroffen. Es findet also daher kein Datenverlust statt. Es ist ja nur ein Cache.

Was nicht so ganz klar ist - das Ceph läuft derzeit auf HDD's?

Ja Ceph läuft auf 32 HDDs. Pro Server haben wir eine Intel P4800X als "Cache".
Wir wollen langfristig auf SSD only umsteigen, allerdings haben wir etwa 106TB und das mit SSDs abzubilden übersteigt das Budget bei weitem. Die Performance im normalen Betrieb ist nicht überragend, aber ausreichend.

 

[Ingo S]

Ich habe mal den Thread Titel angepasst, weil sich im Laufe meiner Untersuchung ein paar neue Gegebenheiten herauskristallisiert haben.

Ich habe untersucht, wie sich unser Backup eigentlich verhält. Welche Dinge besonders viel Zeit brauchen etc.
Dabei ist folgendes Phänomen zutage getreten:

• Wir haben einen bestehenden Hardware Backup-Server mit Windows. Mache ich ein Backup via SMB von Datenbankfiles, die auf einer VM mit Ceph Storage liegen, läuft das mit etwa 32MB/s
• Kopiere ich die gleichen Daten via SMB einfach auf das lokale Dateisystem des Backup-Servers klappt das mit etwa 55MB/s
• Mache ich ein Backup auf Band von der lokalen Kopie der Daten, wird das Backup mit etwa 53MB/s auf Band geschrieben.
• Mache ich ein Backup der gleichen Dateien von unserem NAS Server via Samba erreiche ich auch nur 32MB/s

Schlussfolgerung:

• Das Bandlaufwerk inkl. SAS/SATAIII Controller sind kein Bottleneck bei 32MB/s (Das wäre auch ziemlich irre...)
• Das CEPH allein ist kein Bottleneck bei 32MB/s
• Die Kombination aus Bandlaufwerk, SMB und CEPH limitiert die Sicherung auf 32MB/s

Die Frage ist, wie finde ich raus, warum diese Kombination so langsam ist?
Außerdem kommt mir 50-60MB/s beim sequentiellen Lesen von Ceph doch arg langsam vor.

Ceph: 4 Nodes a 8x 4TB +jeweils 1x SSD P4800X als WAL/DB Cache
1 Node hat einen HBA 9400-8i als SAS Controller
3 Nodes haben einen LSI MegaRAID SAS 9271-8i als Controller (stammt noch von vor der Einführung von Ceph)

Bandlaufwerk:
SATAIII/SAS Controller -> LSI SAS2 2008 Falcon
Laufwerk: Quantum LTO5 Ultrium

Ich vermute, das die eher geringe Geschwindigkeit von Ceph was mit den RAID Controllern zu tun hat. Ich kann nur schlecht einfach auf Verdacht 3 neue HBA kaufen und hoffen das es dann schneller wird. Ich brauche irgendwie einen Ansatz um das zu verifizieren...

 

[Lephisto]

Benutzt du bei den 3 nodes mit Raidcontroller dann ein logical volume als single OSD? Das könnte dann etwas damit zu tun haben.

Ansonsten würde ich hier in IOPS denken, weniger in MB/s. Was sagt denn die Latency im OSd Dashboard?

Ich glaube auch nicht, daß ein spinning rust backup storage das problem sein kann, weil es ja nur sequentielles schreiben ist, wenn du ein tar baust. Das müsste problemlos >100MB/s sequential write abkönnen.

 

[Ingo S]

Der Raid Controller erlaubt mir nicht, Festplatten einzeln direkt durchzuleiten. Die Anleitung sagt, für Single Disks soll man RAID0 nehmen und dem VD nur die eine Disk zuweisen. Ich habe also auf jedem dieser Hosts 8 VDs mit jeweils einer Disk. Anders gehts leider mit den Controllern nicht.

Die Latency sagt bei allen Hosts mit RAID Controller irgendwas zwischen 0 und 3. Sicher gibt der RaidController da nur eine blöde quasi angabe raus, oder die vom Cache.
Auf dem Host mit HBA schwankt die Latency je nach Last zwischen 10-250, selten auch mal 400. Aber dann ist übel was los im Ceph, z.B. ein rebalance und man spürt das die Performance gesunken ist.
Bei einigen VMs habe ich im Monitoring iowait mit drin. Wenn da ein Rebalance reinhaut sehe ich das am steigenden IO Wait in den VMs. Wenn ich das Backup fahre passiert da aber absolut gar nichts. Es ist nicht so das die Performance da spürbar leiden würde weil das Ceph ausgelastet ist.

Achso, Rebalancing klappt übrigens mit den richtigen Einstellungen durchaus mit 800-1000MB/s.

Hier ist auch erstmal Lesen das Problem. Die Read Rate im Ceph ist eben mit um die 50-60MB echt niedrig. Bei großen Dateien ist das ja nachmeinem Verständnis sequentiell und die Blockgröße ist nicht klein, im Gegensatz zu kleinen txt Dateien oder PDFs etc.
Wenn ich Daten von einer VM auf Ceph zum Beispiel auf ein NAS ziehe, ist etwa in dem Bereich 50-60MB/s Schluss. Das NAS kann aber Problemlos 600-700MB/s schlucken, das habe ich ausprobiert, ist mit 10GBit angebunden, die Ceph Nodes auch.

Ich würde eigentlich gerne die Controller tauschen. Das geht aber nicht, solange ich nicht einen guten Grund zur Annahme habe das das die Ursache ist.

Achso, Edit hat angerufen:
So sehen die Disks auf den Raid Controllern dann aus:

root@vm-6:~# /opt/MegaRAID/storcli/storcli64 /c0/v1 show
Controller = 0
Status = Success
Description = None


Virtual Drives :
==============

-------------------------------------------------------------
DG/VD TYPE  State Access Consist Cache Cac sCC     Size Name
-------------------------------------------------------------
1/1   RAID0 Optl  RW     Yes     RWBC  -   ON  3.637 TB     
-------------------------------------------------------------

 

[hackmann]

allo,

ich finde dass Thema supper interessant.

Als ich mit ZFS anfing, hatte ich mal auf einer VM einen Samba-Server eingerichtet.
Unter Proxmox einen pool /daten/samba erstellt.

Dieser pool wurde in der vm als Datenablage für den Samba zur Verfügung gestellt "sdb" per Storage.

Auf dem Samba Server "VM" musste der Sambadienst gestoppt werden, dann einen Snapshot "vom Proxmox Server auf /daten/samba".

Also hatte ich immer einen Snapshot von den ganzen Daten "sdb" per Snapshot.

Dass dauert nichtmal 2 Sekunden!

Ob raw oder qcow2 pro pool, muss der admin entscheiden.
Da ich ja auch diese mounten kann!.

-----------------------------------

Wobei auch Samba mit ZFS spricht "vorherige Version" wiederherstellen, dass klappt auch sehr gut, ungefähr so wie bei Windows 2012 R2 Schhattenkopie.

Mal abgesehen von der ganzen Hardware, grosse Firmem machen jeden Tag ein FULL Backup, da der restore nicht so lange dauert.

Bacula vs Bareos findest du nichts besseres.

Mich wundert es, dass soviele Anfragen kommen, was die Performance angeht, wo doch alles heut zu Tage gelöst werden kann.

Leider kommen solche Anfragen nicht auf den Punkt.

Was will ich?+

Opensource oder die Software Einkaufen?

Was ist in der Zukunft geplant?

Welche Daten müssen gesichert werden?

Cloud:

Seafile oder Nextcloud mit oder ohne DYNDNS für den HOMESERVER.

Ganz wichtig, als VM DEBIAN oder UBUNTU, Debian hat bei der NETINSTALL sehr viele Vorteile, welche? konnte ich hier noch nicht Lesen.

Alles im allem ist Proxmox sehr gut, wobei ich bei bei einem Hyper-V Server auf meiner Workstation eine SSH per RDP laufen lassen konnte auf eine RDP Adesse per localhost.

gruss jochen

 

[Lephisto]

Naja, ich würde schon erstmal die quellen uniform machen, dH überall HBA rein. IOPS auf Quellseite sollten echt nicht das problem sein. Evtl ist es dann schon gelöst. Auf Zielseite schreibst Du eh nur sequentiell, aber wenn Du hier noch ein bottleneck vermutest, kannst du das kannst ja einfach mal gegen irgendeinen rechner mit SSD schreiben lassen..

Der Raid Controller erlaubt mir nicht, Festplatten einzeln direkt durchzuleiten. Die Anleitung sagt, für Single Disks soll man RAID0 nehmen und dem VD nur die eine Disk zuweisen. Ich habe also auf jedem dieser Hosts 8 VDs mit jeweils einer Disk. Anders gehts leider mit den Controllern nicht.

Die Latency sagt bei allen Hosts mit RAID Controller irgendwas zwischen 0 und 3. Sicher gibt der RaidController da nur eine blöde quasi angabe raus, oder die vom Cache.
Auf dem Host mit HBA schwankt die Latency je nach Last zwischen 10-250, selten auch mal 400. Aber dann ist übel was los im Ceph, z.B. ein rebalance und man spürt das die Performance gesunken ist.
Bei einigen VMs habe ich im Monitoring iowait mit drin. Wenn da ein Rebalance reinhaut sehe ich das am steigenden IO Wait in den VMs. Wenn ich das Backup fahre passiert da aber absolut gar nichts. Es ist nicht so das die Performance da spürbar leiden würde weil das Ceph ausgelastet ist.

Achso, Rebalancing klappt übrigens mit den richtigen Einstellungen durchaus mit 800-1000MB/s.

Hier ist auch erstmal Lesen das Problem. Die Read Rate im Ceph ist eben mit um die 50-60MB echt niedrig. Bei großen Dateien ist das ja nachmeinem Verständnis sequentiell und die Blockgröße ist nicht klein, im Gegensatz zu kleinen txt Dateien oder PDFs etc.
Wenn ich Daten von einer VM auf Ceph zum Beispiel auf ein NAS ziehe, ist etwa in dem Bereich 50-60MB/s Schluss. Das NAS kann aber Problemlos 600-700MB/s schlucken, das habe ich ausprobiert, ist mit 10GBit angebunden, die Ceph Nodes auch.

Ich würde eigentlich gerne die Controller tauschen. Das geht aber nicht, solange ich nicht einen guten Grund zur Annahme habe das das die Ursache ist.

Achso, Edit hat angerufen:
So sehen die Disks auf den Raid Controllern dann aus:

root@vm-6:~# /opt/MegaRAID/storcli/storcli64 /c0/v1 show
Controller = 0
Status = Success
Description = None


Virtual Drives :
==============

-------------------------------------------------------------
DG/VD TYPE  State Access Consist Cache Cac sCC     Size Name
-------------------------------------------------------------
1/1   RAID0 Optl  RW     Yes     RWBC  -   ON  3.637 TB    
-------------------------------------------------------------