elmeracmeee
Goto Top

Performance-Einbruch RAID

Hallo,
Ich bin gerade auf der Ursachensuche bei einem langsamen, lokalen RAID.

Server ist ein Fujitsu RX2540M1, Windows 2016, Dual-Socket CPU, 256 GB RAM, 2x Dualport 10GB NIC, PRAID EP400i, 16x1,2 TB SAS Disks.
Das System wurde mal als ESXi Host angeschafft und dient nun als Veeam Backup Server – daher die üppige Ausstattung.
Firmware und Treiber sind auf dem neuesten Stand.

Bei einem Test-Backup einer großen VM (ca 1TB) auf das lokale Repository (12 Disks im RAID6) startet das Backup mit ca. 1,1 GB/s und bricht dann nach ca. 120 GB auf 130 MB/s ein. Dies ist reproduzierbar.
Auf die eigentlichen / externen Backup-Repositories läuft das Backup konstant zwischen 600 und 800 MB/s.
Daher kann ich eigentlich alle anderen Komponenten ausschließen.

Schalte ich die RAID-Volumes von Write-Back auf Write-Trough, so startet das Backup mit nur ca. 400 MB/s und bricht dann auch wieder auf ca. 120 MB/s ein.

Bei Verwendung unter VMWare ist dies nie aufgefallen bzw. nie so getestet worden.
Bei einem ähnlichen Hardware System komme ich konstant auf ca 900MB/s schreibend. Da ist allerdings ESXi noch dazwischen.

Hat jemand eine Idee woher dieser Performance Einbruch kommen kann?

Die 1,1 GB/s sollen nicht das Ziel sein und war mehr als ich erwartet hätte. Allerdings auf die 700 MB/s sollte man hier schon kommen. Oder?
Danke und Gruß

Content-Key: 665415

Url: https://administrator.de/contentid/665415

Ausgedruckt am: 28.03.2024 um 15:03 Uhr

Mitglied: Grinskeks
Grinskeks 06.04.2021 um 10:33:45 Uhr
Goto Top
Moin,

der Veeam Job zeigt immer auch potentielle Bottlenecks an:
Veeam bottleneck

Wird hier ein Bottleneck genannt, würde ich diesem nachgehen.

Ansonsten kann die Rohleistung des lokalen Raid kalkuliert werden.

Raid Calculator


Gruß
Grinskeks
Mitglied: aqui
aqui 06.04.2021 aktualisiert um 10:48:04 Uhr
Goto Top
Rein nur auf die Netz Infrastruktur gerichtet:
  • Jumbo Framing auf allen aktivierten NICs UND auch am Switchport aktiviert ? (Muss bei 10G Links!)
  • Passiert die Sicherung rein im Layer 2 oder über eine geroutete Verbindung ?
  • Gibt es einen Medienbruch von 10G auf 1G ?
Letztere beiden Punkte in Bezug auf das "Buffer Bloating" Problem bezogen.
Mitglied: tech-flare
tech-flare 06.04.2021 aktualisiert um 11:13:13 Uhr
Goto Top
Zitat von @ElmerAcmeee:

Hallo,
Hallo

Ich bin gerade auf der Ursachensuche bei einem langsamen, lokalen RAID.

Server ist ein Fujitsu RX2540M1, Windows 2016, Dual-Socket CPU, 256 GB RAM, 2x Dualport 10GB NIC, PRAID EP400i, 16x1,2 TB SAS Disks.
Das System wurde mal als ESXi Host angeschafft und dient nun als Veeam Backup Server – daher die üppige Ausstattung.
Firmware und Treiber sind auf dem neuesten Stand.

Ich habe genau den baugleichen Server 2 x für 2 Veeam Repos hier.

Bei einem Test-Backup einer großen VM (ca 1TB) auf das lokale Repository (12 Disks im RAID6) startet das Backup mit ca. 1,1 GB/s und bricht
Was für SAS Disk sind das? 15k? 10k? 7,2k?

Hat jemand eine Idee woher dieser Performance Einbruch kommen kann?
Ist dieser Server der Veeam Server selbst, oder nur ein Backup Proxy oder ein Backup Repo?

Was wird letztendlich hier gesichert? Und von wo? Wie erfolgt der Zugriff zu Vmware? Per Direct SAN oder per NBD?

Läuft alles auf Jumbo Frames wie @aqui bereits gefragt hat?

Du kannst dir DiskSpd von aka.ms/diskspd laden und dann mal einen Lokalen Speedtest für Inc. Backups starten.

Siehe dazu Veeam Veeam kb2014
Active full or forward incremental
diskspd.exe -c25G -b512K -w100 -Sh -d600 D:\testfile.dat
-w100 indicates 100% writes and 0% reads. Sequential I/O is used by default.

Gruß
Mitglied: ElmerAcmeee
ElmerAcmeee 06.04.2021 um 11:22:01 Uhr
Goto Top
Hallo,
Bottelneck ist laut Veeam das Target > also das RAID.
Der RAID Calculator sagt ca 366MB/s > wobei ich das nicht verstehe, da mit Cache der Stream mit 1,1 GB/s beginnt und ohne mit 400 MB/s.
Der Server ist nur mit 2x10G im Teaming angebunden. Fallback auf 1G gibt es nicht.
Auf die anderen Repositories läuft es schneller. Daher dürfte es kein Netzwerkproblem sein.
Kein Routing. Ist alles im selben VLAN.

Jumbo Frames prüfe ich noch...
Aber würde das dann so einbrechen? Hätte vermutet, dass das dann direkt problemeatisch ist und nicht erst nach über 100GB
Danke und Gruß
Mitglied: ElmerAcmeee
ElmerAcmeee 06.04.2021 um 11:31:53 Uhr
Goto Top
Hallo,
Zitat von @tech-flare:
Was für SAS Disk sind das? 15k? 10k? 7,2k?

10k SAS Disks

Ist dieser Server der Veeam Server selbst, oder nur ein Backup Proxy oder ein Backup Repo?

Ist der einzige Veeam Server, also mehr oder weniger Oll In One.
Die eigentlichen Repositories sind zwei Dedup Appliances
Das Full-Backup läuft hier nachts mit ca 2x 700 - 800 MB/s

Was wird letztendlich hier gesichert? Und von wo? Wie erfolgt der Zugriff zu Vmware? Per Direct SAN oder per NBD?

Eine Windows VM mit 980GB Daten.
Per SAN Mode. Storage ist ein FullFlash Array.
Anbindung geht über dedizierte 2x10G in einem eignen iSCSI VLAN

Läuft alles auf Jumbo Frames wie @aqui bereits gefragt hat?

muss ich noch prüfen

Du kannst dir DiskSpd von aka.ms/diskspd laden und dann mal einen Lokalen Speedtest für Inc. Backups starten.

Siehe dazu Veeam Veeam kb2014
Active full or forward incremental
> diskspd.exe -c25G -b512K -w100 -Sh -d600 D:\testfile.dat
> -w100 indicates 100% writes and 0% reads. Sequential I/O is used by default.

teste ich dann auch mal
Mitglied: tech-flare
tech-flare 06.04.2021 um 11:55:57 Uhr
Goto Top
Der Server ist nur mit 2x10G im Teaming angebunden. Fallback auf 1G gibt es nicht.
Switch dazwischen?

Jumbo Frames prüfe ich noch...
beachte, dass du Jumbo Frames bei Windows pro Schnittstelle einstellen muss...
Mitglied: ElmerAcmeee
ElmerAcmeee 06.04.2021 um 12:41:13 Uhr
Goto Top
Hallo,

Switch dazwischen?
Die betroffenen Systeme hängen an den gleichen beiden "Backbone" Switchen.

beachte, dass du Jumbo Frames bei Windows pro Schnittstelle einstellen muss...
Danke für den Hinweis.

Ich mache zunächst mit den Disk Speed Tests weiter. Aktuell läuft noch ein produktives Backup, sodass ich das abwarten muss.

Warum würdet ihr den Switch/Netzwerk als Fehlerquelle nicht ausschließen wollen?

Veeam zeigt als Bottelneck das Target an, also das lokal verbaute RAID.
Und das Backup auf die externen Netzwerk Repositories läuft ja schnell durch. Diese sind auch per 10G angebunden.
D.h. das Lesen vom Storage ist der identische Weg.
Danke und Gruß
Mitglied: em-pie
em-pie 06.04.2021 um 13:23:43 Uhr
Goto Top
Moin,

sicherst du die VM als VM oder sicherst du innerhalb der VM mit dem Agent?
Also zapft VEEAM den ESXi an oder hast du das Gast-OS angebunden?

Ist es ein Full oder Inkrementelles Backup?

Gruß
em-pie
Mitglied: tech-flare
tech-flare 06.04.2021 aktualisiert um 13:25:54 Uhr
Goto Top
Also zapft VEEAM den ESXi an oder hast du das Gast-OS angebunden?
Er sichert per SAN Access. Somit zapft Veeam direkt das Storage an. Dies ist die schnellste Variante von Veeam.

Gruß
Gruß
Mitglied: em-pie
em-pie 06.04.2021 aktualisiert um 13:44:23 Uhr
Goto Top
mea culpa,
das "SAN-Mode" hab ich überlesen -.-
Danke dir, @tech-flare

@to
hast du parallel mal den Leistungsmonitor unter Windows gestartet, um zu sehen, ob tatsächlich das RAID ausgelastst ist.
vielleicht kannst du auch am RAID selbst die Auslastung sehen - kenne die Fujitsu-Kisten nicht wirklich...

Gruß
Mitglied: aqui
aqui 06.04.2021 um 14:45:14 Uhr
Goto Top
Die betroffenen Systeme hängen an den gleichen beiden "Backbone" Switchen.
Beantwortet ja leider nicht die Fragen zum Infrastruktur Setup an sich...aber egal !
Warum würdet ihr den Switch/Netzwerk als Fehlerquelle nicht ausschließen wollen?
Medienbrüche z.B. wenn deine 10G Port 10G Base T Ports sind die niemals eine feste Bandbreite negotiation sondern oft nur Bruchteile davon. 10G Base T ist KEIN verlässliches Medium um Server anzubinden ! Das ist nur DAC/Twinax oder LWL !
Ebenso Problematiken der Switchhardware. Billige 10G Consumer Switches sind fast alle überbucht, schaffen also keine 10G Wirespeed und schon gar nicht bei kleinen Paketen wie sie i.d.R bei SMB/CIFS vorkommen sofern das zur Sicherung verwendet wird. Alles eben geraten...
Genau da kann es dann zu Buffer Bloats kommen im TCP die in dem geschilderten Verhalten enden.
Auch ob Jumbos durchgängig im Layer 2 definiert sind keine Aussage. Auch nicht ob das ein gerouteter Link ist oder rein Layer 2....aber egal. face-sad
OK, die Netz Infrastruktur ist ja auch nur ein Punkt von vielen. Aber diese sollte man wenigstens ausschliessen können.
Mitglied: ElmerAcmeee
ElmerAcmeee 06.04.2021 um 16:17:20 Uhr
Goto Top
Hallo,
Danke für die Unterstüzung.
Hier noch weitere Infos:

Zitat von @aqui:

Die betroffenen Systeme hängen an den gleichen beiden "Backbone" Switchen.
Beantwortet ja leider nicht die Fragen zum Infrastruktur Setup an sich...aber egal !
2x Cisco Nexus 9000, 100G interconnect,
Anbindung der Systeme: je redundant 10G SFP+, OM3 LWL max 5m,

Genau da kann es dann zu Buffer Bloats kommen im TCP die in dem geschilderten Verhalten enden.
Würde dies nicht schon nach ein paar Sekunden auftreten und nicht erst nach Minuten und über 100 GB

Auch ob Jumbos durchgängig im Layer 2 definiert sind keine Aussage.
richtig, dass muss ich noch prüfen

Auch nicht ob das ein gerouteter Link ist oder rein Layer 2....aber egal. face-sad
Kein Routing. Ist alles im selben VLAN.

OK, die Netz Infrastruktur ist ja auch nur ein Punkt von vielen. Aber diese sollte man wenigstens ausschliessen können.
Würde ich ja, durch das Ausschlussprinzip.
Nur das Backup auf die lokalen Platten verhält sich so.
K
Mitglied: ElmerAcmeee
ElmerAcmeee 06.04.2021 um 16:21:05 Uhr
Goto Top
Hallo,

Zitat von @ElmerAcmeee:
Du kannst dir DiskSpd von aka.ms/diskspd laden und dann mal einen Lokalen Speedtest für Inc. Backups starten.

Siehe dazu Veeam Veeam kb2014
Active full or forward incremental
>> diskspd.exe -c25G -b512K -w100 -Sh -d600 D:\testfile.dat
>> -w100 indicates 100% writes and 0% reads. Sequential I/O is used by default.

Ergebnis:
Write IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 31879331840 | 60805 | 50.67 | 101.34 | e:\test\testfile.dat (25GiB)
total: 31879331840 | 60805 | 50.67 | 101.34

Hast du Referenzwerte?
Danke und Gruß
Mitglied: Grinskeks
Grinskeks 06.04.2021 um 17:44:40 Uhr
Goto Top
Der RAID Calculator sagt ca. 366MB/s > wobei ich das nicht verstehe, da mit Cache der Stream mit 1,1 GB/s beginnt und ohne mit 400 MB/s.

Das kommt daher, dass die Performance immer eine Momentan-Aufnahme über den bisherigen zeitlichen Verlauf ist. Am Anfang ist der cache evtl. prall mit nutzbaren Daten gefüllt und es findet bereits vor der zeitlichen Messung eine Vorbereitung der Daten statt, daher gibt es zum Start einen vermeintlich relativ hohen Durchsatz.

Nur über den kompletten Zeitraum lässt sich der tatsächliche durchschnittliche Durchsatz sinnvoll interpretieren.
Der Einbruch auf 130MB/s ist schon irgendwie verdächtig nahe 1 Gbit/s.

Wie geht's dem Raid denn sonst so? Sind die Platten sind noch alle frisch oder gibt es Anzeichen drohender Defekte?
Man könnte beispielsweise über storcli die Smart-Attribute auslesen.

Falls die Platten ok sind: Lässt sich das Verhalten auch mit anderen VMs nachstellen? Tritt das Verhalten immer nach der gleichen übertragenen Datenmenge ein?

Gruß
Grinskeks
Mitglied: tech-flare
tech-flare 06.04.2021 um 21:02:00 Uhr
Goto Top
Zitat von @ElmerAcmeee:
Ergebnis:
Write IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 31879331840 | 60805 | 50.67 | 101.34 | e:\test\testfile.dat (25GiB)
total: 31879331840 | 60805 | 50.67 | 101.34

Hast du Referenzwerte?
Jetzt nicht im Kopf, aber für SAS Platten finde ich den Wert jetzt nicht wirklich gut.

Ich lasse morgen mal einen Test auf einem Raid 60 (16 Bay) und Raid 6 SAS 7,2k laufen und übermittel dir die Daten.
Mitglied: ElmerAcmeee
ElmerAcmeee 07.04.2021 um 07:06:10 Uhr
Goto Top
Moin,
Zitat von @Grinskeks:
Nur über den kompletten Zeitraum lässt sich der tatsächliche durchschnittliche Durchsatz sinnvoll interpretieren.
Der Einbruch auf 130MB/s ist schon irgendwie verdächtig nahe 1 Gbit/s.
Laut Netzwerk- und Festplattenauslastung im Performancemonitor fängt der wirklich mit 1GB/s an.
130MB/s ist deutlich über 1Gbit/s wenn man den ganzen Overhead mitbetrachtet.

Wie geht's dem Raid denn sonst so? Sind die Platten sind noch alle frisch oder gibt es Anzeichen drohender Defekte?
Laut iRMC ist alles super

Man könnte beispielsweise über storcli die Smart-Attribute auslesen.
StorCli kenn ich noch nicht. Mache mich dazu dann heute mal schlau.

Falls die Platten ok sind: Lässt sich das Verhalten auch mit anderen VMs nachstellen? Tritt das Verhalten immer nach der gleichen übertragenen Datenmenge ein?
Teste ich heute nochmals und versuche den genauen Zeitpunkt zu ermitteln

DANKE!
Mitglied: ElmerAcmeee
ElmerAcmeee 07.04.2021 um 09:49:52 Uhr
Goto Top
Hallo,
ein Update von meiner Seite:
Einige Zahlen habe ich wohl sehr falsch interpretiert und muss daher auch einige Aussagen zurück nehmen.
SORRY dafür!

Die 1GB/s kommen nach neuester Erkenntnis daher, dass sowhl in den RAM als auch auf die Platte geschrieben wird.
Veeam zeigt als Druchsatz den Netzwerkdurchsatz an.
Im Windows Resource Monitor ist mir irgendwann aufgefallen, dass die Werte von Netzwerk und Disk weit auseinander driften aber sich auch wieder annähern.
Z.B.
Netzwerkdurchsatz = 1GB/s wärend Disk schreiben = 200 MB/s
oder:
Netzwerkdurchsatz = 10 MB/s wärend Disk schreiben = 190 MB/s
Wärend dieser Werte steigt und fällt der "Modified" RAM.
Da die Kiste 256 GB RAM hat, wurde wohl die hälfte als Puffer genutzt. Daher auch die 1.1GB/s am Anfang, also mit maximaler Auslastung der NIC zu 90% in den RAM geschrieben.

Damit ergibt sich dann die Schreibperformance aus der Laufzeit und Datenmenge.
In unserem Fall ca 250MB/s, was ich noch als deutlich zu langsam erachte...
Danke und Gruß
Mitglied: ElmerAcmeee
ElmerAcmeee 07.04.2021 um 10:52:04 Uhr
Goto Top
Hallo

Ich lasse morgen mal einen Test auf einem Raid 60 (16 Bay) und Raid 6 SAS 7,2k laufen und übermittel dir die Daten.

Durch das letzte Firmware Update des RAID Controllers war wohl für das Volume der Diskcache disabled.
Nun komme ich auf diese Werte:
Write IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 56803459072 | 108344 | 90.29 | 180.57 | e:\test\testfile.dat (25GiB)
total: 56803459072 | 108344 | 90.29 | 180.57

Unter Veeam erreiche ich damit laut Resource Monitor nun 250MB/s
Mitglied: tech-flare
tech-flare 07.04.2021 um 11:31:52 Uhr
Goto Top
Da die Kiste 256 GB RAM hat, wurde wohl die hälfte als Puffer genutzt. Daher auch die 1.1GB/s am Anfang, also mit maximaler Auslastung der NIC zu 90% in den RAM geschrieben.
Das ergibt Sinn. Der eine Veeam Proxy hat hier 64GB Ram. Ich beobachte das mal.
Mitglied: tech-flare
tech-flare 07.04.2021 um 11:52:58 Uhr
Goto Top
Zitat von @ElmerAcmeee:

Hallo

Ich lasse morgen mal einen Test auf einem Raid 60 (16 Bay) und Raid 6 SAS 7,2k laufen und übermittel dir die Daten.

Durch das letzte Firmware Update des RAID Controllers war wohl für das Volume der Diskcache disabled.
Nun komme ich auf diese Werte:
Write IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 56803459072 | 108344 | 90.29 | 180.57 | e:\test\testfile.dat (25GiB)
total: 56803459072 | 108344 | 90.29 | 180.57

Unter Veeam erreiche ich damit laut Resource Monitor nun 250MB/s


So sieht es bei mir auf dem RX2540M1 aus.

Raid60, 7,2k SATA HDD

Total IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 243658129408 | 464741 | 387.28 | 774.57 | Q:\testfile.dat (25GiB)
total: 243658129408 | 464741 | 387.28 | 774.57
Mitglied: ElmerAcmeee
ElmerAcmeee 07.04.2021 um 13:01:40 Uhr
Goto Top
Hallo,
Zitat von @tech-flare:

So sieht es bei mir auf dem RX2540M1 aus.

Raid60, 7,2k SATA HDD

Total IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 243658129408 | 464741 | 387.28 | 774.57 | Q:\testfile.dat (25GiB)
total: 243658129408 | 464741 | 387.28 | 774.57

Ich muss gestehen, von RAID60 habe ich bislang noch nie gehört...
Mein erster Google-Treffer sagt: Nachteil: sehr langsame Schreibgeschwindigkeit
hmmm, und trotzdem schneller als mein SAS 10k Volume.
Ich glaube ich werde aus dem RAID6 mal ein RAID10 machen, oder was der Controller sonst noch so hergibt.
Trotzdem werde ich das Gefühl nicht los, dass es eigentlich jetzt schon deutlich schneller sein sollte...

Ich werde berichten..
Danke und Gruß
Mitglied: tech-flare
tech-flare 07.04.2021 aktualisiert um 13:05:16 Uhr
Goto Top
Zitat von @ElmerAcmeee:

Hallo,
Zitat von @tech-flare:

So sieht es bei mir auf dem RX2540M1 aus.

Raid60, 7,2k SATA HDD

Total IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 243658129408 | 464741 | 387.28 | 774.57 | Q:\testfile.dat (25GiB)
total: 243658129408 | 464741 | 387.28 | 774.57

Ich muss gestehen, von RAID60 habe ich bislang noch nie gehört...
Mein erster Google-Treffer sagt: Nachteil: sehr langsame Schreibgeschwindigkeit
Raid 6 ist eine Kombination aus Raid 6+0.

Somit schneller als Raid6 ;) Lohnt sich aber erst bei einer bestimmten Anzahl an Platten.

hmmm, und trotzdem schneller als mein SAS 10k Volume.
Ich glaube ich werde aus dem RAID6 mal ein RAID10 machen, oder was der Controller sonst noch so hergibt.
Raid 10 ist die schnellste Möglichkeit. Jedoch verlierst du da die Hälfte an Kapazität..

Trotzdem werde ich das Gefühl nicht los, dass es eigentlich jetzt schon deutlich schneller sein sollte...
Ja. Es ist definitiv zu langsam.
Mitglied: Grinskeks
Grinskeks 07.04.2021 um 15:12:37 Uhr
Goto Top
Trotzdem werde ich das Gefühl nicht los, dass es eigentlich jetzt schon deutlich schneller sein sollte...

Wenn das Raid neu gemacht werden kann, schau dir doch mal die Stripe Size an und optimiere diese für den konkreten Anwendungsfall.

Dein Veeam hat beispielsweise 512 KB Blöcke mit standard compression ( 1 MB local target / Faktor 2 Kompression ca.)
Je näher deine Stripe Size an der Veeam Größe ist, desto weniger Blöcke musst du schreiben - im Idealfall ohne Verlust

Im Filesystem kann man die Block Size dann auch entsprechend erhöhen.

Beispiel:

Stripe Size 64 KB , Veeam Block mit 512 KB = 8 I/O um den Block zu schreiben.
Stripe Size 128 KB , Veeam Block mit 512 KB = 4 I/O um den Block zu schreiben.

Gruß
Grinskeks
Mitglied: ElmerAcmeee
ElmerAcmeee 08.04.2021 um 11:54:25 Uhr
Goto Top
Hallo,
so, RAID10 wurde neu erstellt mit 1MB Stripe Size und allen Cache Optionen aktiviert.
Neues DiskSpeed Ergenis:

Write IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 496465608704 | 946933 | 789.10 | 1578.20 | e:\perftest\testfile.dat (25GiB)
total: 496465608704 | 946933 | 789.10 | 1578.20

Das sieht doch mal recht ordentlich aus.

Alledings verhält sich Veeam nun anders.
Anstelle direkt, wie gestern, mit den 1GB/s los zu laufen und einen teil in den RAM zu schreiben, geht es jetzt direkt auf die Platte mit ca 380MB/s.
Ursache davon ist nun, dass das Storage zu langsam wäre. Bottleneck 99% Source. ???
Aber das ist nun wieder eine andere Baustelle...

Das eigentliche Problem habe ich nun Dank eurer Hilfe beheben können.
Somit, besten Dank!