17
DPM2019 mit MBS und Refs wird immer langsamer !
Hallo zusammen,
ich habe hier einen Backup-Server mit Server 2019 Std. .
Darauf läuft seit neuem DPM2019 und ich habe testweise das soooo angeprisene MBS direkt mal getestet und ein ReFs Speicherpool laut Anleitung
Hinzufügen von Modern Backup Storage zu DPM
erstellt.
Es sollen hier "lediglich" etwa knapp 4TB an Daten kurzfristig tgl. gesichert werden und dann später langfristig auf BAND (LTO6 / LTO7).
Alles in Allem ist mein Problem eigentlich ganz schnell erklärt:
1. die Erstellung des Replikates dauerte auf dem ReFs Volume um Welten länger als auf einem popeligen NTFS Volume, welches ich vorher in Versionen unter DPM2019 hatte
2. seit ich ReFs einsetze ist der ganze Server sowas von am Kriechen
3. die Sicherung aufs Band über eine reine 10GB FibreChanel Karte ist auf Diskette schneller (seit 95h sichert er noch immer eine Sicherung aufs Band) die Daten holt er sich ja vom ReFs Volume.
(siehe Bild).
Das kann ich echt nciht glauben und es berichten so einige über das Phänomen.
Gibt es da etwas zu Schrauben oder muss ich noch irgendetwas beachten ?
Gruß
Enrico
ich habe hier einen Backup-Server mit Server 2019 Std. .
Darauf läuft seit neuem DPM2019 und ich habe testweise das soooo angeprisene MBS direkt mal getestet und ein ReFs Speicherpool laut Anleitung
Hinzufügen von Modern Backup Storage zu DPM
erstellt.
Es sollen hier "lediglich" etwa knapp 4TB an Daten kurzfristig tgl. gesichert werden und dann später langfristig auf BAND (LTO6 / LTO7).
Alles in Allem ist mein Problem eigentlich ganz schnell erklärt:
1. die Erstellung des Replikates dauerte auf dem ReFs Volume um Welten länger als auf einem popeligen NTFS Volume, welches ich vorher in Versionen unter DPM2019 hatte
2. seit ich ReFs einsetze ist der ganze Server sowas von am Kriechen
3. die Sicherung aufs Band über eine reine 10GB FibreChanel Karte ist auf Diskette schneller (seit 95h sichert er noch immer eine Sicherung aufs Band) die Daten holt er sich ja vom ReFs Volume.
(siehe Bild).
Das kann ich echt nciht glauben und es berichten so einige über das Phänomen.
Gibt es da etwas zu Schrauben oder muss ich noch irgendetwas beachten ?
Gruß
Enrico
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 576281
Url: https://administrator.de/forum/dpm2019-mit-mbs-und-refs-wird-immer-langsamer-576281.html
Ausgedruckt am: 23.12.2024 um 03:12 Uhr
17 Kommentare
Neuester Kommentar
Moin Enrico,
ist ein bei Microsoft bekannter Fehler und meines Wissens gibt es noch keine Abhilfe.
Workaround: DPM2019 komplett neu unter Server 2012 R2 aufsetzen (einzige Möglichkeit z. Zt. ReFs zu umgehen).
VG
Marcel
ist ein bei Microsoft bekannter Fehler und meines Wissens gibt es noch keine Abhilfe.
Workaround: DPM2019 komplett neu unter Server 2012 R2 aufsetzen (einzige Möglichkeit z. Zt. ReFs zu umgehen).
VG
Marcel
Hi Marcel,
ohhh nein echt jetzt ?
Wieso verkauft MS denn so nen halbfertigen Dreck ?
Das Problem ist, dass ich jetzt alle Replicate neu machen kann, wenn ich zurückschwenke.
Ein vorheriuges nochmaliges wegsichern der Replicate ist nicht machbar (etwas um die 45TB).
Das ist ja echt wieder typisch MS -> hauptsache schon seit ewigen Zeiten mit DPM2016 schon das doch so schnelle und leistungsstarke MBS anpreisen.
Danke Dir trotzdem für deine Mühe und den Input.
VG
Enrico
ohhh nein echt jetzt ?
Wieso verkauft MS denn so nen halbfertigen Dreck ?
Das Problem ist, dass ich jetzt alle Replicate neu machen kann, wenn ich zurückschwenke.
Ein vorheriuges nochmaliges wegsichern der Replicate ist nicht machbar (etwas um die 45TB).
Das ist ja echt wieder typisch MS -> hauptsache schon seit ewigen Zeiten mit DPM2016 schon das doch so schnelle und leistungsstarke MBS anpreisen.
Danke Dir trotzdem für deine Mühe und den Input.
VG
Enrico
N'Abend.
Ja, da glänzt MS nicht wirklich, der DPM war schon immer eher das "Stiefkind", was die (Weiter-)Entwicklung angeht.
Ich habe mir hiermit beholfen:
https://charbelnemnom.com/2016/10/how-to-reduce-dpm-2016-storage-consump ...
Den Teil für DeDup weglassen und nur den Weg nachvollziehen, wie er die Speicherpools für DPM anlegt. Das hat den Performance-Knoten mit ReFS zum einen Teil gelöst. Der andere Teil war (und ist) die brachiale Aufstockung des RAMs auf dem DPM-Server (2016 lief mit 16GB, 2019 erst mal 128GB halbwegs rund).
Und dann gibt's da noch nen lesenswerten Thread im TechNet:
https://social.technet.microsoft.com/Forums/en-US/7e4e4da4-1168-46cd-900 ...
Cheers,
jsysde
Ja, da glänzt MS nicht wirklich, der DPM war schon immer eher das "Stiefkind", was die (Weiter-)Entwicklung angeht.
Ich habe mir hiermit beholfen:
https://charbelnemnom.com/2016/10/how-to-reduce-dpm-2016-storage-consump ...
Den Teil für DeDup weglassen und nur den Weg nachvollziehen, wie er die Speicherpools für DPM anlegt. Das hat den Performance-Knoten mit ReFS zum einen Teil gelöst. Der andere Teil war (und ist) die brachiale Aufstockung des RAMs auf dem DPM-Server (2016 lief mit 16GB, 2019 erst mal 128GB halbwegs rund).
Und dann gibt's da noch nen lesenswerten Thread im TechNet:
https://social.technet.microsoft.com/Forums/en-US/7e4e4da4-1168-46cd-900 ...
Cheers,
jsysde
Hi,
erstmal danke für deinen Tipp.
Allerdings bezieht sich der Workaround ja auf einen virtuellen DPM-Server.
Bei mir ist das alles lokal mit 65TB SAS/SATA Platten und davon etwa 2% SSD und der Rest WD-RED.
Des weiteren lässt sich der Code von der Seite nicht kopieren...voll ärgerlich.
Meinst Du das klappt auch auf einer physischen Maschine so ?
Gruß
Enrico
erstmal danke für deinen Tipp.
Allerdings bezieht sich der Workaround ja auf einen virtuellen DPM-Server.
Bei mir ist das alles lokal mit 65TB SAS/SATA Platten und davon etwa 2% SSD und der Rest WD-RED.
Des weiteren lässt sich der Code von der Seite nicht kopieren...voll ärgerlich.
Meinst Du das klappt auch auf einer physischen Maschine so ?
Gruß
Enrico
N'Abend.
Ich wünsche viel Erfolg - und starke Nerven....
Cheers,
jsysde
Zitat von @eb1980:
[...]Des weiteren lässt sich der Code von der Seite nicht kopieren...voll ärgerlich.
Jupp. Nervt. Pro-Tipp: Quelltext der Seite anzeigen lassen.... [...]Des weiteren lässt sich der Code von der Seite nicht kopieren...voll ärgerlich.
[...]Meinst Du das klappt auch auf einer physischen Maschine so ?
Tut es. Der oben beschriebene DPM war (oder ist noch? Ich arbeite nicht mehr in dem Unternehmen) auch eine physikalische (da hing auch gleich die Tape Library dran).Ich wünsche viel Erfolg - und starke Nerven....
Cheers,
jsysde
Mega danke.
Ich bastel derzeit noch die Powershell bissl um. Brauche ja mehr als 12TB und verschiedene Volumes .
Na ich werde berichten.
LG und schönes WE
Ich bastel derzeit noch die Powershell bissl um. Brauche ja mehr als 12TB und verschiedene Volumes .
Na ich werde berichten.
LG und schönes WE
Hi,
da bin ich wieder.
Also hab es jetzt alles genauso gemacht und das Ende vom Lied ist, dass es nix gebracht hat.
Schreiben und Lesen auf den ReFs ist sowas von grottenlahm, dass ich die Popeligen 40TB an Daten nicht mal an einem Wochenende geschrieben resp. auf Band gesichert bekomme.
Selbst die Replica Erstellung einer SQL-DB von 12TB hat von Freitag bis heute morgen 9 Uhr gebraucht.
Klar habe ich natürlich mehrere Schutzgruppen mit Exchange, SQL etc. welche alle bedient werden wollen.
Am schlimmsten sit die Performance, wenn sich Sicherungen überschneiden.
Dan geht gar nix mehr an Schreiben und Lesen.
Das ist echt zum Kotzen.
Hast Du einen Tip für mich, wie ich wieder ruhigen Gewissens schlafen kann?
Ich habe bisher keine vernünftige Sicherung für den Safe.
Nur einige Wiederherstellungspunkte auf Platte.
Das ist fatal und einen Ausfall will ich mir gar nicht erst ausmalen.
LG
Enrico
da bin ich wieder.
Also hab es jetzt alles genauso gemacht und das Ende vom Lied ist, dass es nix gebracht hat.
Schreiben und Lesen auf den ReFs ist sowas von grottenlahm, dass ich die Popeligen 40TB an Daten nicht mal an einem Wochenende geschrieben resp. auf Band gesichert bekomme.
Selbst die Replica Erstellung einer SQL-DB von 12TB hat von Freitag bis heute morgen 9 Uhr gebraucht.
Klar habe ich natürlich mehrere Schutzgruppen mit Exchange, SQL etc. welche alle bedient werden wollen.
Am schlimmsten sit die Performance, wenn sich Sicherungen überschneiden.
Dan geht gar nix mehr an Schreiben und Lesen.
Das ist echt zum Kotzen.
Hast Du einen Tip für mich, wie ich wieder ruhigen Gewissens schlafen kann?
Ich habe bisher keine vernünftige Sicherung für den Safe.
Nur einige Wiederherstellungspunkte auf Platte.
Das ist fatal und einen Ausfall will ich mir gar nicht erst ausmalen.
LG
Enrico
Mahlzeit.
Wie viel RAM hat dein DPM-Server?
S. mein Post weiter oben - ich musste von 16GB auf 128GB raufgehen, damit ReFS einigermaßen mitgespielt hat.
Hast du dir die möglichen Paramter und Registry-Settings aus dem TechNet-Artikel angeschaut?
Ich weiß, das ist ne Menge Arbeit und viel Trial-and-Error - aber leider der einzige Weg (wenn du bei DPM bleiben willst).
Cheers,
jsysde
Wie viel RAM hat dein DPM-Server?
S. mein Post weiter oben - ich musste von 16GB auf 128GB raufgehen, damit ReFS einigermaßen mitgespielt hat.
Hast du dir die möglichen Paramter und Registry-Settings aus dem TechNet-Artikel angeschaut?
Ich weiß, das ist ne Menge Arbeit und viel Trial-and-Error - aber leider der einzige Weg (wenn du bei DPM bleiben willst).
Cheers,
jsysde
Derzeit habe ich noch 32GB und die Ausbaustufe ist bei 64GB erreicht.
Hab schon neuen Speicher geordert.
Muss warten bis es ankommt.
Die Registry-Werte (mehr probieren und hoffen) habe ich gesetzt.
Kann aber kaum den Server neu starten, weil immer wieder was läuft und damit die Replikate inkonsistent werden und eine Konsistenzprüfung dauert mitunter 10 x länger als ein Replikat neu zu erstellen.
Es kann aber doch nicht sein, dass ein bisschen mehr Speicher gleich einen Quantensprung auslöst.
Oder ?
Zumal ja der Leistungsmonitor nicht gerade anfängt zu rauchen.
hmm nuja ich warte mal ab was der neue Speicher bringt.
Danke erstmal
Hab schon neuen Speicher geordert.
Muss warten bis es ankommt.
Die Registry-Werte (mehr probieren und hoffen) habe ich gesetzt.
Kann aber kaum den Server neu starten, weil immer wieder was läuft und damit die Replikate inkonsistent werden und eine Konsistenzprüfung dauert mitunter 10 x länger als ein Replikat neu zu erstellen.
Es kann aber doch nicht sein, dass ein bisschen mehr Speicher gleich einen Quantensprung auslöst.
Oder ?
Zumal ja der Leistungsmonitor nicht gerade anfängt zu rauchen.
hmm nuja ich warte mal ab was der neue Speicher bringt.
Danke erstmal
N'Abend.
ReFS braucht anscheinend deutlich mehr RAM als MS offiziell empfiehlt, insbesondere wenn man riesige Datenmengen im TB-Bereich damit verwaltet. Als ich die Firma verlassen habe, war der Zustand zumindest soweit stabil, dass die ~90TB Disk-2-Disk-Storage auf den per iSCSI verbundenen Synology-NAS (drei Stück) schnell und zuverlässig vom DPM angesprochen werden konnten. Ich hatte seinerzeit mehrere 18TB große LUNs auf die Synologys verteilt per MPIO angebunden, auf jeder LUN 16TB große Storage Spaces Volumes nach dem Muster von Charbel.
Wie gesagt, der DPM lief in der 2012er-Version mit 16GB RAM deutlich schneller und stabiler, aber ich musste (zumindest einen unserer DPMs) auf 2016 hochziehen, damit der SharePoint 2016 gesichert werden konnte. Mehr Infos kann ich dir leider nicht mehr liefern, ich hab' da keinen Kontakt und Einblick mehr.
Cheers,
jsysde
Zitat von @eb1980:
[...]Es kann aber doch nicht sein, dass ein bisschen mehr Speicher gleich einen Quantensprung auslöst.
Ich kann dir dafür auch keine plausible, technische Erklärung mehr liefern. Ich habe seit >12 Monaten nicht mehr produktiv mit DPM zu tun (hab den Job gewechselt). Aber auch andere Kollegen (inkl. zwei, drei MVPs und DPM-Gurus) haben mit dem gleichen Problem gekämpft und es mit der Aufrüstung auf eigentlich lächerlich viel RAM zumindest teilweise umgangen.[...]Es kann aber doch nicht sein, dass ein bisschen mehr Speicher gleich einen Quantensprung auslöst.
ReFS braucht anscheinend deutlich mehr RAM als MS offiziell empfiehlt, insbesondere wenn man riesige Datenmengen im TB-Bereich damit verwaltet. Als ich die Firma verlassen habe, war der Zustand zumindest soweit stabil, dass die ~90TB Disk-2-Disk-Storage auf den per iSCSI verbundenen Synology-NAS (drei Stück) schnell und zuverlässig vom DPM angesprochen werden konnten. Ich hatte seinerzeit mehrere 18TB große LUNs auf die Synologys verteilt per MPIO angebunden, auf jeder LUN 16TB große Storage Spaces Volumes nach dem Muster von Charbel.
Wie gesagt, der DPM lief in der 2012er-Version mit 16GB RAM deutlich schneller und stabiler, aber ich musste (zumindest einen unserer DPMs) auf 2016 hochziehen, damit der SharePoint 2016 gesichert werden konnte. Mehr Infos kann ich dir leider nicht mehr liefern, ich hab' da keinen Kontakt und Einblick mehr.
Cheers,
jsysde
Hey,
Ich danke dir trotzdem für die Zeit,welche du mir gewidmet hast.
Heute ist der Speicher angekommen.
Leider kann ich nicht mehr als 64GB verbauen, da das Board nicht mehr verträgt.
Ich werd mich morgen dran setzen und berichten.
Was mir auffällt ist das eine konsistenzprüfung mehr als 4x so lang braucht wie die Erstellung des Replikates selbst.
Voll unlogisch aber nuja.
LG und schönen Abend
Enrico
Ich danke dir trotzdem für die Zeit,welche du mir gewidmet hast.
Heute ist der Speicher angekommen.
Leider kann ich nicht mehr als 64GB verbauen, da das Board nicht mehr verträgt.
Ich werd mich morgen dran setzen und berichten.
Was mir auffällt ist das eine konsistenzprüfung mehr als 4x so lang braucht wie die Erstellung des Replikates selbst.
Voll unlogisch aber nuja.
LG und schönen Abend
Enrico
Mahlzeit.
Erstellen eines Replikats (initiales Backup) bedeutet: Einfach mal alles 1:1 kopieren. Basta. Reines Lesen hier, Schreiben dort.
Konsistenzprüfung: Vergleich der laufenden Maschine(n) mit _allen!_ bis dato gemachten/vorhandenen Backups. Mal hier lesen, mal dort lesen, Delta bilden, abgleichen.
Dass das ^^ länger dauert als ein reiner Kopiervorgang ist imho sogar sehr logisch.
Cheers,
jsysde
Zitat von @eb1980:
[...]Was mir auffällt ist das eine konsistenzprüfung mehr als 4x so lang braucht wie die Erstellung des Replikates selbst.
Voll unlogisch aber nuja.
Was ist daran unlogisch?[...]Was mir auffällt ist das eine konsistenzprüfung mehr als 4x so lang braucht wie die Erstellung des Replikates selbst.
Voll unlogisch aber nuja.
Erstellen eines Replikats (initiales Backup) bedeutet: Einfach mal alles 1:1 kopieren. Basta. Reines Lesen hier, Schreiben dort.
Konsistenzprüfung: Vergleich der laufenden Maschine(n) mit _allen!_ bis dato gemachten/vorhandenen Backups. Mal hier lesen, mal dort lesen, Delta bilden, abgleichen.
Dass das ^^ länger dauert als ein reiner Kopiervorgang ist imho sogar sehr logisch.
Cheers,
jsysde
Hmm ja jetzt wo du es sagst ergibt das sinn.
Holz vorm Kopf.
Trotzdem komme ich nicht weiter.
Meine Bandsicherung von der Disk (Refs) auf eine Quantum Scalar i3 mit LTO7 Bändern, welche via FibreChanel angebunden ist, hat jetzt in 8h geradezu 1,1TB einer 12,5TB SQL Datenbank geschafft. Bis das fertig ist, wenn DPM nicht dann schon anfängt die Wiederherstellungspunkte zu löschen, haben sich zahlreiche weitere langfristige Sicherungen angesammelt, welche nie und nimmer zu schaffen sind.
Gibt es nicht eine DPM-Server OS Konstellation, welche astrein funktioniert?
LG
Enrico
Holz vorm Kopf.
Trotzdem komme ich nicht weiter.
Meine Bandsicherung von der Disk (Refs) auf eine Quantum Scalar i3 mit LTO7 Bändern, welche via FibreChanel angebunden ist, hat jetzt in 8h geradezu 1,1TB einer 12,5TB SQL Datenbank geschafft. Bis das fertig ist, wenn DPM nicht dann schon anfängt die Wiederherstellungspunkte zu löschen, haben sich zahlreiche weitere langfristige Sicherungen angesammelt, welche nie und nimmer zu schaffen sind.
Gibt es nicht eine DPM-Server OS Konstellation, welche astrein funktioniert?
LG
Enrico
N'Abend.
Wenn du die gefunden hast, kannst du die ultimative Lösung sicherlich gewinnbringend an den Mann bringen.
Was mir grad noch einfällt: Wie groß ist denn deine DPM-Datenbank? Und wo liegt, auf der gleichen Maschine oder im Netz/auf nem anderen Server? Wie ist das Logging eingestellt für die DB (ich würde hier "simple" empfehlen und dann die Logs verkleinern)?
Wenn dich das alles nicht weiter bringt bleibt nur der Call bei Microsoft oder ein Hilferuf an einen der Gurus wie Robert Hedblom & Co.
Cheers,
jsysde
Wenn du die gefunden hast, kannst du die ultimative Lösung sicherlich gewinnbringend an den Mann bringen.
Was mir grad noch einfällt: Wie groß ist denn deine DPM-Datenbank? Und wo liegt, auf der gleichen Maschine oder im Netz/auf nem anderen Server? Wie ist das Logging eingestellt für die DB (ich würde hier "simple" empfehlen und dann die Logs verkleinern)?
Wenn dich das alles nicht weiter bringt bleibt nur der Call bei Microsoft oder ein Hilferuf an einen der Gurus wie Robert Hedblom & Co.
Cheers,
jsysde
Hi,
also die DB ist 9.154,56 MB groß, liegt auf dem selben Server wie der DPM und die Wiederherstellung ist auf "einfach" gesetzt.
Es ist einfach nur zum Haare ausreißen.
Sei es lesen oder schreiben.
Der DPM kriecht nur so vor sich hin.
Ich hätte bei Server 2012 und DPM 2012 bleiben sollen.
Habe mich von den Versprechungen seitens MS beirren lassen und auf ReFs (MBS) verführen lassen.
Danke Dir aber für deine Mühen
Gruß
Enrico
also die DB ist 9.154,56 MB groß, liegt auf dem selben Server wie der DPM und die Wiederherstellung ist auf "einfach" gesetzt.
Es ist einfach nur zum Haare ausreißen.
Sei es lesen oder schreiben.
Der DPM kriecht nur so vor sich hin.
Ich hätte bei Server 2012 und DPM 2012 bleiben sollen.
Habe mich von den Versprechungen seitens MS beirren lassen und auf ReFs (MBS) verführen lassen.
Danke Dir aber für deine Mühen
Gruß
Enrico
Hallo,
also alles in allem ist es nicht wirklich besser geworden was den Durchsatz angeht.
Aber liegt wohl auch daran, dass wir hier jeden Tag um die 27TB auf Band sichern und ich denke hier müssen wir anders planen.
Mir schwebt dann vor tgl. auf Datenträger (kurzfristig) und dann nur am WE langfristig aufs Band sowie an Monatsenden.
Anders kann das glaub ich auch keine HDD hinbekommen mit Lesen und schreiben zugleich an aéinem Tag.
Danke trotzdem für die Hilfe
also alles in allem ist es nicht wirklich besser geworden was den Durchsatz angeht.
Aber liegt wohl auch daran, dass wir hier jeden Tag um die 27TB auf Band sichern und ich denke hier müssen wir anders planen.
Mir schwebt dann vor tgl. auf Datenträger (kurzfristig) und dann nur am WE langfristig aufs Band sowie an Monatsenden.
Anders kann das glaub ich auch keine HDD hinbekommen mit Lesen und schreiben zugleich an aéinem Tag.
Danke trotzdem für die Hilfe
N'Abend.
Hält man sich an die Anleitung von Charbel läuft es am Ende des Tages tatsächlich sehr flott und zuverlässig (und eliminiert einige lästige Unarten von NTFS-Volumes). Eine Empfehlung an die breite Masse ist das aber sicherlich nicht.
Cheers,
jsysde
Zitat von @eb1980:
Ich hätte bei Server 2012 und DPM 2012 bleiben sollen.
Habe mich von den Versprechungen seitens MS beirren lassen und auf ReFs (MBS) verführen lassen.
Das kommt ganz drauf an, was du sichern willst/musst - manche Produkte (z.B. SharePoint 2019) bekommst du mit DPM 2012 nicht gesichert. Und die Versprechungen von MS keine "leeren" Versprechungen: ReFS ist tatsächlich deutlich schneller - wenn man die Voraussetzungen alle erfüllt und das ist die eigentliche Krux. Leider lässt sich jedes Volume "mal eben" mit ReFS formatieren.Ich hätte bei Server 2012 und DPM 2012 bleiben sollen.
Habe mich von den Versprechungen seitens MS beirren lassen und auf ReFs (MBS) verführen lassen.
Hält man sich an die Anleitung von Charbel läuft es am Ende des Tages tatsächlich sehr flott und zuverlässig (und eliminiert einige lästige Unarten von NTFS-Volumes). Eine Empfehlung an die breite Masse ist das aber sicherlich nicht.
Cheers,
jsysde
