35
Windows Server 2025 friert komplett nach Reboot und Zugriff auf iSCSI-Target ein
Umgebung: Windows Server 2025 (Build 26100.3476).
Hallo,
Hergang:
vor gut einem Monat wurde ein neuer Backupserver für unsere Umgebung installiert. Das hat ein Systemhaus vorgenommen.
Dieses wurde in ein separates VLAN gepackt und die Verbindung zwischen diesem und dem Storage (ISCSI) noch mal in ein eigenes.
C: läuft auf M.2 SSD und das ISCSI-Target bindet das 480TB Storage an.
Per Firewall und in den Switchen ist das alles so eingerichtet, dass es nicht aufs Internet zugreifen kann, sicher ist sicher.
Hat alles einen Monat lang super funktioniert mit wirklich sehr guter performance und war sehr zuverlässig.
Nun hatte durch einen Vorfall, bei dem wir viele Systeme wiederherstellen mussten, auch dieser Server einen Fehler und musste neu gestartet werden. Das war der erste Neustart, einen Monat nach Inbetriebnahme des Servers.
Problem:
Danach kam es dazu, dass immer, wenn auf das iSCSI-Target zugegriffen wird, dies zwar (mehr schlecht als recht) funktioniert, der Server dann aber offenbar irgendeinen Deadlock hat, also man sieht nich ganz wenige Frames für den Anfang und dann friert die Sitzung komplett ein. Selbst die Uhrzeit aktualisiert sich nicht mehr. Der Ping auf das System antwortet aber noch.
Es bleibt nicht einmal ein sauberer Reboot über die management-Oberfläche des zugrunde liegenden Terra-Servers.
Einzig ein Power-cycle bzw. force shutdown funktioniert.
Sowohl der Zugriff von Veeam aus als auch aus dem Dateisystem lösen das aus. Deaktiviere ich den Microsoft ISCSI-Dienst, bleibt das Target selbstverständlich im System unsichtbar aber der Server läuft problemlos weiter, seit mehr als einem Tag.
Ein Versuch, die Remotedesktopverbindung neu aufzubauen scheitert ebenfalls, es kommt nicht einmal eine Passwortabfrage. Am Gerät selbst komme ich auch mit Tastatur nicht zu einem Loginscreen. Teils reagiert nicht einmal NumLock.
Wenn der TaskManager während des Einfrierens läuft, sieht man als letzten Frame den Prozess: System (NT Kernel & System) mit 12 K Memory bei 33% CPU Load rödeln. GesamtCPU-Load: ca. 100%.
Verbaut ist ein Xeon E-356G @ 3,2 GHz (6C,12T) und 32 GB RAM.
Vielleicht hilft das noch bei der Einordnung.
Aus den Event views sehe ich nicht viel während dieser Phasen.
Vielmehr scheint er währenddessen so ziemlich gar nichts zu loggen. Nächstes Ereignis ist dann mit großem Zeitabstand mit dem Poswercycle zu verzeichnen.
Frage:
Kennt jemand dieses Verhalten oder weiß, wie man es löst?
Grüße und danke im Voraus.
Mondragor
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672774
Url: https://administrator.de/forum/windows-server-2025-friert-komplett-nach-reboot-und-zugriff-auf-iscsi-target-ein-672774.html
Ausgedruckt am: 29.05.2025 um 05:05 Uhr
35 Kommentare
Neuester Kommentar
Moin,
da fehlen leider so ziemlich alle wichtigen Informationen. Welche und wie viele NICs ? Wird teaming benutzt ?
Der Backupserver erscheint mir auch reichlich schwach mit der asbach Rocket Lake CPU und nur 32GB Ram, bei 480TB würd ich ja mehr als nur ne Handvoll Jobs erwarten
da fehlen leider so ziemlich alle wichtigen Informationen. Welche und wie viele NICs ? Wird teaming benutzt ?
Der Backupserver erscheint mir auch reichlich schwach mit der asbach Rocket Lake CPU und nur 32GB Ram, bei 480TB würd ich ja mehr als nur ne Handvoll Jobs erwarten
pebcak7123 07.05.2025 um 17:02:45 Uhr
Moin,
da fehlen leider so ziemlich alle wichtigen Informationen. Welche und wie viele NICs ? Wird teaming benutzt ?
Der Backupserver erscheint mir auch reichlich schwach mit der asbach Rocket Lake CPU und nur 32GB Ram, bei 480TB würd ich ja mehr als nur ne Handvoll Jobs erwarten
Moin,
da fehlen leider so ziemlich alle wichtigen Informationen. Welche und wie viele NICs ? Wird teaming benutzt ?
Der Backupserver erscheint mir auch reichlich schwach mit der asbach Rocket Lake CPU und nur 32GB Ram, bei 480TB würd ich ja mehr als nur ne Handvoll Jobs erwarten
Auch hier wieder: Wie man eine Frage richtig stellt!
Liest man die Hilfe nicht?
Gruss Penny.
Zitat von @pebcak7123:
Moin,
da fehlen leider so ziemlich alle wichtigen Informationen. Welche und wie viele NICs ? Wird teaming benutzt ?
Der Backupserver erscheint mir auch reichlich schwach mit der asbach Rocket Lake CPU und nur 32GB Ram, bei 480TB würd ich ja mehr als nur ne Handvoll Jobs erwarten
Moin,
da fehlen leider so ziemlich alle wichtigen Informationen. Welche und wie viele NICs ? Wird teaming benutzt ?
Der Backupserver erscheint mir auch reichlich schwach mit der asbach Rocket Lake CPU und nur 32GB Ram, bei 480TB würd ich ja mehr als nur ne Handvoll Jobs erwarten
Der Server hat 2 x 10 GBit RJ45 (Intel 210), wobei einer quasi in das Intranet schaut, die andere die Verbindung zum Storage gewährleistet.
Da beide NICs in verschiedene VLANs schauen, kein Teaming, LAG oder dergleichen.
Es macht nicht eben die Anzahl der Jobs als eher der Datenumfang je Fullbackup.
Wie gesagt, es schrieb mit teils über 1 Gigabyte je Sekunde, alles gut soweit. Also Performance passte immer.
Software ist Veeam B&R Standardversion, die man halt damals zur Essentials Plus von VMWare dazu geholt hat. Neueste Version...
Wenn Du noch was konkretes wissen musst, frag halt...
Die 480 TB sind halt, um auch für die Zukunft noch Reserven zu haben, bei einem entsprechenden Vorhaltekonzept. Aktuelle Datenmenge ist ca. 40 TB je Vollsicherung. Größte Server sind Gut 18 und 12.4 TB pro Job.
Ich habe extra dazu geschrieben, dass die Lösung dazu von einem Systemhaus bereitgestellt wurde. Ich finde es müßig, jetzt über solche Einzelheiten zu befinden, wenn ich schreibe, dass es für unser Dafürhalten gut und performant lief, bis zum Neustart. Bitte akzeptiere das als Realität. Das denke ich mir nicht aus.
Grüße
Mondragor
Zitat von @Penny.Cilin:
Auch hier wieder: Wie man eine Frage richtig stellt!
Liest man die Hilfe nicht?
Gruss Penny.
pebcak7123 07.05.2025 um 17:02:45 Uhr
Moin,
da fehlen leider so ziemlich alle wichtigen Informationen. Welche und wie viele NICs ? Wird teaming benutzt ?
Der Backupserver erscheint mir auch reichlich schwach mit der asbach Rocket Lake CPU und nur 32GB Ram, bei 480TB würd ich ja mehr als nur ne Handvoll Jobs erwarten
Moin,
da fehlen leider so ziemlich alle wichtigen Informationen. Welche und wie viele NICs ? Wird teaming benutzt ?
Der Backupserver erscheint mir auch reichlich schwach mit der asbach Rocket Lake CPU und nur 32GB Ram, bei 480TB würd ich ja mehr als nur ne Handvoll Jobs erwarten
Auch hier wieder: Wie man eine Frage richtig stellt!
Liest man die Hilfe nicht?
Gruss Penny.
Hallo, auch Du bist herzlich eingeladen, mir konkrete Fragen zu stellen.
Zusammengefasst, wenn ich den ISCSI-initiator nicht aktiv habe, läufts. Wenn er aktiv ist und sich das Storage verbindet, muss nur ein Zugriff stattfinden, damit das System in ca. 30 - 90 Sekunden das beschriebene Verhalten zeigt.
Ich mag mich irren, aber meines Erachtens ist egal, was damit gebackupt wird, welche Software das Backup schreibt oder wo ich geboren bin. Es ist einfach dieser Unterschied, der ausmacht, ob das System einfriert oder nicht, egal, welche Anwendung auf das damit eingebundene "Laufwerk" letztendlich zugreift.
So stellt sich das Problem für mich dar und daher weiß ich nicht, welche Information Euch fehlt. Einen Link dazu zu posten, wie man eine Frage stellt, hilft mir da leider nicht, weil ich denke, dass ich mir Mühe gegeben habe, die von mir bereits gewonnenen Erkenntnisse soweit einzuflechten, sodass (meines Erachtens) überflüssige Informationen nicht unbedingt noch rein müssen.
Wenn dann etwas konkretes fehlt, bitte nachfragen. Ich gebe mir Mühe, entsprechend nachzuliefern.
Was mir bisher jedoch noch nie weiter geholfen hat, sind Leute, die aus Prinzip genau solche Kommentare schreiben, ohne je im Verlauf "wieder" irgendetwas Hilfreiches beizutragen.
Warum verschwendet man seine Lebenszeit damit, so einen Kommentar zu posten?
Nichts davon nimmt auch nur einen Funken an Bezug auf die Informationen, die ich bereits geliefert habe, konkretisiert, was angeblich fehlt oder nimmt Bezug die Frage, die ich gestellt habe.
Grüße
Mondragor
Hallo,
sinnvolle nächste Schritte wären, das Volume auf einem alternativen Rechner/OS zu mounten und jeweils abzuschichten, ob schon das Einhängen der Disk oder erst des Volumes zum Problem führt. Wahrscheinlich liegt halt ein Dateisystemfehler vor, der beim Parsing des Dateisystems zu dem Crash führt.
Den könnte man prinzipiell an der eingehängten Disk diagnostizieren, oder auch Daten mit alternativen Parsern wiederherstellen. Aber bei einem Backup-Ziel ist es an sich naheliegender, in einem solchen Fall das Volume neu aufzubauen und die Backups nachzuholen.
Grüße
Richard
sinnvolle nächste Schritte wären, das Volume auf einem alternativen Rechner/OS zu mounten und jeweils abzuschichten, ob schon das Einhängen der Disk oder erst des Volumes zum Problem führt. Wahrscheinlich liegt halt ein Dateisystemfehler vor, der beim Parsing des Dateisystems zu dem Crash führt.
Den könnte man prinzipiell an der eingehängten Disk diagnostizieren, oder auch Daten mit alternativen Parsern wiederherstellen. Aber bei einem Backup-Ziel ist es an sich naheliegender, in einem solchen Fall das Volume neu aufzubauen und die Backups nachzuholen.
Grüße
Richard
Moin,
Vorweg: iSCSI ist ein Thema, bei dem ich nur weiß, wie man es schreibt und dass es auf EthernetFrames basiert
Zergliedere das Problem:
Hast du mal alle Veeam-Dienste deaktiviert, die Kiste neu gestartet und dann das iSCSI-Target wieder verbunden? Wenn das stabil läuft: kannst du gesichert per Explorer drauf arbeiten?
Wenn es stabil läuft: VEEAM in den Fokus holen. Welche Version setzt du ein? 12.3.1?
Wenn der Explorer-Zugriff auch schon scheitert: mal am Target eine weitere LUN angelegt und die gemounted?
Wurden im Rahmen des Reboots Updates (Windows) installiert?
Wie verhält sich ein anderer Initiator (wie oben schon beschrieben)…
Am Rande: sehr gewagt, VEEAM/ Windows nur mit einem Bein an das Target anzubinden. Werden Daten geschrieben und während dessen bricht dir die Verbindung (physisch) weg, kann das zu Datensalat führen. Mit einer Mehrport-Verbindung (MPIO) fährst du besser Ist es im übrigen eine DualPort-Karte oder zwei Single? Oder sind die onBoard?
Noch ne Frage: ist die NIC direkt mit dem Target verbunden oder hängt da noch ein Switch zwischen?
Vorweg: iSCSI ist ein Thema, bei dem ich nur weiß, wie man es schreibt und dass es auf EthernetFrames basiert
Zergliedere das Problem:
Hast du mal alle Veeam-Dienste deaktiviert, die Kiste neu gestartet und dann das iSCSI-Target wieder verbunden? Wenn das stabil läuft: kannst du gesichert per Explorer drauf arbeiten?
Wenn es stabil läuft: VEEAM in den Fokus holen. Welche Version setzt du ein? 12.3.1?
Wenn der Explorer-Zugriff auch schon scheitert: mal am Target eine weitere LUN angelegt und die gemounted?
Wurden im Rahmen des Reboots Updates (Windows) installiert?
Wie verhält sich ein anderer Initiator (wie oben schon beschrieben)…
Am Rande: sehr gewagt, VEEAM/ Windows nur mit einem Bein an das Target anzubinden. Werden Daten geschrieben und während dessen bricht dir die Verbindung (physisch) weg, kann das zu Datensalat führen. Mit einer Mehrport-Verbindung (MPIO) fährst du besser
Ist es im übrigen eine DualPort-Karte oder zwei Single? Oder sind die onBoard?Noch ne Frage: ist die NIC direkt mit dem Target verbunden oder hängt da noch ein Switch zwischen?
Moin,
Deiner Beschreibung nach hängt zwischen Server und Storage ein Switch. Verbinde doch einmal testweise den Server direkt mit dem Storage. Bleibt der Fehler, kannst Du Dir die Fehlersuche am Switch im Grunde sparen.
Ansonsten:
Das mal so als spontane Ideen
Gruß
Deiner Beschreibung nach hängt zwischen Server und Storage ein Switch. Verbinde doch einmal testweise den Server direkt mit dem Storage. Bleibt der Fehler, kannst Du Dir die Fehlersuche am Switch im Grunde sparen.
Ansonsten:
- Verwendet Ihr Jumbo Frames?
- Ping läuft, OK. Aber hast Du auch einen Dauerping mit -f laufen lassen? Bei Jumbo Frames bspw. ping -f 8972. Paketverluste? Oder gar ein Hinweis auf Fragmentierung?
- Flow Control aktiv und an den entscheidenden Stellen entsprechend konfiguriert?
- Intel Netzwerkkarte, NVM stimmt mit Treiberversion Intel ProSet überein?
- Da RJ45, Kabelspezifikation reicht für 10Gbit aus? Testweise Kabeltausch?
- Ihr habt das iSCSI-Target hoffentlich nicht mit ReFS formatiert?
Das mal so als spontane Ideen
Gruß
1
Wegen was für einem Fehler musste der Server denn neu gestartet werden ? Danach scheinen ja die Probleme angefangen zu haben.
Wurde schon mal neu installiert ? Für die Intel i210 gabs vorletzte Woche neue Treiber, wurden die evtl aktualisiert ?
Mal versucht sich wenn der hängt sich falls möglich über powershell draufzuschalten ?
Wenn Windows-Logs nichts aussagen was sagen die Logs vom Baseband Management ?
Wurde schon mal neu installiert ? Für die Intel i210 gabs vorletzte Woche neue Treiber, wurden die evtl aktualisiert ?
Mal versucht sich wenn der hängt sich falls möglich über powershell draufzuschalten ?
Wenn Windows-Logs nichts aussagen was sagen die Logs vom Baseband Management ?
Moin @Coreknabe,
meine Kristallkugel sagt mir, dass du damit ...
... wahrscheinlich schon ins schwarze getroffen hast.
Denn Veeam mault schon seit Jahren ein Backup-Target an, wenn es mit NTFS formatiert ist und weist darauf hin, dass man dieses mit ReFS formatieren sollte. 😬
Was jedoch total bescheuert ist, da ReFS über iSCSI und vor allem bei derart grossen LUN's, überhaupt nicht stabil läuft. 😔
Gruss Alex
meine Kristallkugel sagt mir, dass du damit ...
* Ihr habt das iSCSI-Target hoffentlich nicht mit ReFS formatiert?
... wahrscheinlich schon ins schwarze getroffen hast.
Denn Veeam mault schon seit Jahren ein Backup-Target an, wenn es mit NTFS formatiert ist und weist darauf hin, dass man dieses mit ReFS formatieren sollte. 😬
Was jedoch total bescheuert ist, da ReFS über iSCSI und vor allem bei derart grossen LUN's, überhaupt nicht stabil läuft. 😔
Gruss Alex
Moin @Mondragor,
ich mach es kurz, aber leider nicht schmerzlos.
Wenn das was @Coreknabe betreffend ReFS schon erwähnt hat zutrifft, sprich, wenn du die iSCSI LUN tatsächlich mit ReFS formatiert hast und oder das Systemhaus, was am Ende des Tages auch vollkommen egal ist, da hier die Schuld definitiv bei Microsoft und auch bei Veeam liegt, dann habe ich für dich eine schlechte Nachricht, denn die Wahrscheinlichkeit, dass dir das ReFS um die Ohren geflogen ist, liegt meiner eigenen Erfahrung nach leider bei > 99%.
Denn genau das was du beschreibst, ist uns selbst schon vor mehreren Jahren bei einem Kunden passiert. 😭
Bei diesem hatten wir auch ein ~ 250 TB grosse iSCSI-LUN an Veeam drangehängt und hatten diese dann auch mit ReFS formatiert, weil es Veeam damals schon "empfohlen" hat. Diese ReFS formatierte LUN ist dann jedoch innerhalb von einem Jahren zwei Mal komplett um die Ohren geflogen, mit ähnlichen Effekten wie bei dir. Danach wurde die LUN mit NTFS und einer Block-Size von 64K formatiert und seitdem läuft diese nun seit einigen Jahren ohne Probleme.
Gruss Alex
ich mach es kurz, aber leider nicht schmerzlos.
Wenn das was @Coreknabe betreffend ReFS schon erwähnt hat zutrifft, sprich, wenn du die iSCSI LUN tatsächlich mit ReFS formatiert hast und oder das Systemhaus, was am Ende des Tages auch vollkommen egal ist, da hier die Schuld definitiv bei Microsoft und auch bei Veeam liegt, dann habe ich für dich eine schlechte Nachricht, denn die Wahrscheinlichkeit, dass dir das ReFS um die Ohren geflogen ist, liegt meiner eigenen Erfahrung nach leider bei > 99%.
Denn genau das was du beschreibst, ist uns selbst schon vor mehreren Jahren bei einem Kunden passiert. 😭
Bei diesem hatten wir auch ein ~ 250 TB grosse iSCSI-LUN an Veeam drangehängt und hatten diese dann auch mit ReFS formatiert, weil es Veeam damals schon "empfohlen" hat. Diese ReFS formatierte LUN ist dann jedoch innerhalb von einem Jahren zwei Mal komplett um die Ohren geflogen, mit ähnlichen Effekten wie bei dir. Danach wurde die LUN mit NTFS und einer Block-Size von 64K formatiert und seitdem läuft diese nun seit einigen Jahren ohne Probleme.
Gruss Alex
Moin @Mondragor,
ich glaube, du solltest dir das ...
https://www.borncity.com/blog/2025/04/02/windows-server-2019-2025-maerz- ...
... und auch das ...
https://www.veeam.com/kb2792
... mal etwas genauer durchlesen. 😬
Insbesondere denn folgenden Hinweis von Veeam ...
... finde ich schon sehr spannend.
Denn bei der Einrichtung selbst, weist Veeam einfach nur darauf hin, dass es anstelle eines NTFS formatierten Volume, lieber ein ReFS formatiertes Volume hätte, ohne auch nur eine Silbe über die damit auch verbundenen Risiken zu erwähnen. 😔
Gruss Alex
ich glaube, du solltest dir das ...
https://www.borncity.com/blog/2025/04/02/windows-server-2019-2025-maerz- ...
... und auch das ...
https://www.veeam.com/kb2792
... mal etwas genauer durchlesen. 😬
Insbesondere denn folgenden Hinweis von Veeam ...
... finde ich schon sehr spannend.
Denn bei der Einrichtung selbst, weist Veeam einfach nur darauf hin, dass es anstelle eines NTFS formatierten Volume, lieber ein ReFS formatiertes Volume hätte, ohne auch nur eine Silbe über die damit auch verbundenen Risiken zu erwähnen. 😔
Gruss Alex
1
Moin,
@mysticfox
Man beachte hier auch die Historie. Erst von Veeam empfohlen und propagiert, dann verschämt in KB-Einträgen versteckt, dass das keine gute Idee ist, als Krönung erfolgt IMMER NOCH (aktuelle Version 12.3.1) eine Warnung in Veeam. Hammer...
Dazu muss man sagen, ich hatte hier auch diverse Dinge zum Thema iSCSI gepostet, wenn man sich drauf einlässt, der Datendurchsatz ist mit ReFS tatsächlich fast doppelt so hoch, wie mit NTFS! Zumindest habe ich das nach einigen kurzen Tests so beobachtet. Wenn man also vorher nicht recherchiert hat und sich auf die Veeam-Warnung verlässt, wird die Begeisterung bis zum ersten Einschlag anhalten...
Aber das sind alles Spekulationen, solange der TO sich hier nicht mehr äußert
Gruß
@mysticfox
Denn Veeam mault schon seit Jahren ein Backup-Target an, wenn es mit NTFS formatiert ist und weist darauf hin, dass man dieses mit ReFS formatieren sollte.
Man beachte hier auch die Historie. Erst von Veeam empfohlen und propagiert, dann verschämt in KB-Einträgen versteckt, dass das keine gute Idee ist, als Krönung erfolgt IMMER NOCH (aktuelle Version 12.3.1) eine Warnung in Veeam. Hammer...
Dazu muss man sagen, ich hatte hier auch diverse Dinge zum Thema iSCSI gepostet, wenn man sich drauf einlässt, der Datendurchsatz ist mit ReFS tatsächlich fast doppelt so hoch, wie mit NTFS! Zumindest habe ich das nach einigen kurzen Tests so beobachtet. Wenn man also vorher nicht recherchiert hat und sich auf die Veeam-Warnung verlässt, wird die Begeisterung bis zum ersten Einschlag anhalten...
Aber das sind alles Spekulationen, solange der TO sich hier nicht mehr äußert
Gruß
Moin @Coreknabe,
das wird es seit ~2016 bis heute immer noch.
https://www.veeam.com/blog/advanced-refs-integration-coming-veeam-availa ...
https://www.veeam.com/resources/wp-availability-suite-advanced-refs-inte ...
https://www.veeam.com/resources/videos/storage-best-practices-recorded-d ...
😔
Interessant finde ich dem ersten Link auch die folgende Aussage.
Sprich, hier steckt meiner Ansicht nach eigentlich schon ein Hinweis, dass ReFS nur für DAS oder S2D geeignet ist.
By the way, die Backups mit auf das produktive S2D abzulegen, ist fürchte ich auch nicht wirklich eine sehr kluge Idee und ein extra S2D nur für Backups zu implementieren, ist meiner Ansicht nach fast noch bescheuerter. 😔
Somit bleibt nur noch DAS übrig, wobei auch hier kein RAID-Kontroller dazwischen stecken sollte, da sich diese auch gerne mit ReFS beissen. 🙃
Somit bleibt für ReFS nur noch ein einzelnes Laufwerk, was direkt per SAS oder PCIe am Veeam Server dranhängt als mögliches Backupziel übrig und diese Konstellation, ist eher alles andere als alltagstypisch.
Tja, vielleicht verstehst du nun etwas besser, warum ich mir in letzter Zeit, insbesondere die Software Hersteller besonders gerne vorknöpfe. 😉
Ja, ReFS bringt bei gewissen Dingen durchaus einen Zugewinn, aber nicht wirklich in jeder Umgebung und es hat vor allem auch enorme Nachteile, vor allem was dessen Stabilität angeht.
Darüber spricht jedoch so gut wie kein Hersteller, zumindest nicht besonders offen.
Einer meiner ersten Artikel die ich hier geschrieben habe, war übrigens dieser …
Warum ihr keine ReFS Formatierung für CSVs verwenden solltet, die von einem SAN bereitgestellt werden
… hier.
Und es hat am Ende des Tages über 2 Jahre gedauert, bis Microsoft die entsprechende Dokus so überarbeitet hat, dass in diesen ReFS nicht mehr pauschal auch für CSV’s empfohlen wird. 😔
Ich fürchte, der TO ist wahrscheinlich schon dabei seinen Diensleister wegen dem ReFS zu kloppen. 😬
Gruss Alex
Man beachte hier auch die Historie. Erst von Veeam empfohlen und propagiert
das wird es seit ~2016 bis heute immer noch.
https://www.veeam.com/blog/advanced-refs-integration-coming-veeam-availa ...
https://www.veeam.com/resources/wp-availability-suite-advanced-refs-inte ...
https://www.veeam.com/resources/videos/storage-best-practices-recorded-d ...
😔
Interessant finde ich dem ersten Link auch die folgende Aussage.
„The advanced ReFS integration supports ReFS volumes on internal, direct-attached storage (DAS) and Storage Spaces — both classic and Storage Spaces Direct (S2D).“
Sprich, hier steckt meiner Ansicht nach eigentlich schon ein Hinweis, dass ReFS nur für DAS oder S2D geeignet ist.
By the way, die Backups mit auf das produktive S2D abzulegen, ist fürchte ich auch nicht wirklich eine sehr kluge Idee und ein extra S2D nur für Backups zu implementieren, ist meiner Ansicht nach fast noch bescheuerter. 😔
Somit bleibt nur noch DAS übrig, wobei auch hier kein RAID-Kontroller dazwischen stecken sollte, da sich diese auch gerne mit ReFS beissen. 🙃
Somit bleibt für ReFS nur noch ein einzelnes Laufwerk, was direkt per SAS oder PCIe am Veeam Server dranhängt als mögliches Backupziel übrig und diese Konstellation, ist eher alles andere als alltagstypisch.
dann verschämt in KB-Einträgen versteckt, dass das keine gute Idee ist, als Krönung erfolgt IMMER NOCH (aktuelle Version 12.3.1) eine Warnung in Veeam. Hammer...
Tja, vielleicht verstehst du nun etwas besser, warum ich mir in letzter Zeit, insbesondere die Software Hersteller besonders gerne vorknöpfe. 😉
Dazu muss man sagen, ich hatte hier auch diverse Dinge zum Thema iSCSI gepostet, wenn man sich drauf einlässt, der Datendurchsatz ist mit ReFS tatsächlich fast doppelt so hoch, wie mit NTFS! Zumindest habe ich das nach einigen kurzen Tests so beobachtet. Wenn man also vorher nicht recherchiert hat und sich auf die Veeam-Warnung verlässt, wird die Begeisterung bis zum ersten Einschlag anhalten...
Ja, ReFS bringt bei gewissen Dingen durchaus einen Zugewinn, aber nicht wirklich in jeder Umgebung und es hat vor allem auch enorme Nachteile, vor allem was dessen Stabilität angeht.
Darüber spricht jedoch so gut wie kein Hersteller, zumindest nicht besonders offen.
Einer meiner ersten Artikel die ich hier geschrieben habe, war übrigens dieser …
Warum ihr keine ReFS Formatierung für CSVs verwenden solltet, die von einem SAN bereitgestellt werden
… hier.
Und es hat am Ende des Tages über 2 Jahre gedauert, bis Microsoft die entsprechende Dokus so überarbeitet hat, dass in diesen ReFS nicht mehr pauschal auch für CSV’s empfohlen wird. 😔
Aber das sind alles Spekulationen, solange der TO sich hier nicht mehr äußert
Ich fürchte, der TO ist wahrscheinlich schon dabei seinen Diensleister wegen dem ReFS zu kloppen. 😬
Gruss Alex
Ja, das Dateisystem ist ReFS, was bei der Größe schon "fast nicht mehr anders geht"... und weils Veeam halt empfiehlt.
Aber das Problem war hier - zumindest in unserem Fall - offenbar der Windows Defender.
Am Anfang war das iSCSI-Target ja noch unbeschrieben und daher wohl auch nicht das Problem, dass der aktiv war.
Nach dem Reboot einen Monat später sah das aber anders aus, 60 TB belegt und der hat dann offenbar den RAM vollgeballert und alle Prozesse "blockiert", die darauf zugreifen wollten. Ob der Defender vorher kein Problem hatte, weil beim Booten das Volume noch nicht eingebunden war oder es zwar da aber leer war, weiß ich nicht.
Wir haben also für den Defender den Ausschluss des Laufwerksbuchstaben des iSCSI-targets mit ReFS eingetragen, Neustart - alles wieder gut. RAM ist nur zu 25% belegt, alles läuft flüssig, keine Aussetzer oder Freezes mehr. Veeam schreibt und liest wieder auch im Bereich von >1 GByte/s.
Ob sich der Defender nun am ReFS stört oder an der Größe / Menge der darauf befindlichen Daten, ist mir mehr oder minder Bums.
Der Rechner darf nur für Updates ins Internet schauen, danach wird das über die Firewall wieder geschlossen.
Die Rückrichtung ist ohnehin ausgeschlossen. Somit sehe ich eher keinen Anlass, warum die Veeam-Backups vom Defender durchsucht werden sollten.
Da steht was vom Veeam Agent. Ich denke das ist der Windows Endpoint Backup Agent, der da gemeint ist, also dass der Probleme hat, ReFS als Quelle zu handhaben, kann mich aber irren.
Das neueste Windows Update ist jetzt installiert und nächste Woche kommt ja wieder ein neues. Die Meldungen aus März sind dann vielleicht auch wieder hinfällig, zumal es ohnehin ein anderes Problem gab mit ISCSI beim Booten ... Aber das sollte glaube ich ab dem April-Update schon gelöst gewesen sein...
Aber unser Server bootet von SSD.
Ich gehe davon aus, dass das Problem erstmal gelöst ist. Werde aber Tipps bezüglich ReFS im Hinterkopf behalten, falls da nochmal trotz des Ausschlusses vom Defender ein ähnlich gelagertes Problem auftreten sollte.
Danke nochmal an alle, die sich Mühe gegeben haben, mir zu helfen.
Grüße
Mondragor
Aber das Problem war hier - zumindest in unserem Fall - offenbar der Windows Defender.
Am Anfang war das iSCSI-Target ja noch unbeschrieben und daher wohl auch nicht das Problem, dass der aktiv war.
Nach dem Reboot einen Monat später sah das aber anders aus, 60 TB belegt und der hat dann offenbar den RAM vollgeballert und alle Prozesse "blockiert", die darauf zugreifen wollten. Ob der Defender vorher kein Problem hatte, weil beim Booten das Volume noch nicht eingebunden war oder es zwar da aber leer war, weiß ich nicht.
Wir haben also für den Defender den Ausschluss des Laufwerksbuchstaben des iSCSI-targets mit ReFS eingetragen, Neustart - alles wieder gut. RAM ist nur zu 25% belegt, alles läuft flüssig, keine Aussetzer oder Freezes mehr. Veeam schreibt und liest wieder auch im Bereich von >1 GByte/s.
Ob sich der Defender nun am ReFS stört oder an der Größe / Menge der darauf befindlichen Daten, ist mir mehr oder minder Bums.
Der Rechner darf nur für Updates ins Internet schauen, danach wird das über die Firewall wieder geschlossen.
Die Rückrichtung ist ohnehin ausgeschlossen. Somit sehe ich eher keinen Anlass, warum die Veeam-Backups vom Defender durchsucht werden sollten.
MysticFoxDE 08.05.2025 aktualisiert um 09:46:59 Uhr
Markiere als 'Lösung'
Goto Top
Moin @Mondragor,
ich glaube, du solltest dir das ...
https://www.borncity.com/blog/2025/04/02/windows-server-2019-2025-maerz- ...
Markiere als 'Lösung'
Goto Top
Moin @Mondragor,
ich glaube, du solltest dir das ...
https://www.borncity.com/blog/2025/04/02/windows-server-2019-2025-maerz- ...
Da steht was vom Veeam Agent. Ich denke das ist der Windows Endpoint Backup Agent, der da gemeint ist, also dass der Probleme hat, ReFS als Quelle zu handhaben, kann mich aber irren.
Das neueste Windows Update ist jetzt installiert und nächste Woche kommt ja wieder ein neues. Die Meldungen aus März sind dann vielleicht auch wieder hinfällig, zumal es ohnehin ein anderes Problem gab mit ISCSI beim Booten ... Aber das sollte glaube ich ab dem April-Update schon gelöst gewesen sein...
Aber unser Server bootet von SSD.
Ich gehe davon aus, dass das Problem erstmal gelöst ist. Werde aber Tipps bezüglich ReFS im Hinterkopf behalten, falls da nochmal trotz des Ausschlusses vom Defender ein ähnlich gelagertes Problem auftreten sollte.
Danke nochmal an alle, die sich Mühe gegeben haben, mir zu helfen.
Grüße
Mondragor
Moin,
gutgemeinter Rat: Solange Du noch die Möglichkeit hast, verwende NTFS! Ansonsten, Trauergeschichten gibt es im Netz mehr als genug, läufst Du Gefahr, dass Deine Daten von gleich auf jetzt weg sind.
Gruß
gutgemeinter Rat: Solange Du noch die Möglichkeit hast, verwende NTFS! Ansonsten, Trauergeschichten gibt es im Netz mehr als genug, läufst Du Gefahr, dass Deine Daten von gleich auf jetzt weg sind.
Gruß
1
Wir schauen uns das nochmal an. Danke für den Hinweis.
Grüße
Mondragor
Grüße
Mondragor
Moin @Mondragor,
wie du aber gemäss des folgenden und bereits erwähnten Veeam-Artikels …
https://www.veeam.com/kb2792
… sehen kannst, ist ReFS auch seitens Veeam, nicht wirklich für dein Setup geeignet. 😔
Und auch in der folgenden Doku von Microsoft …
https://learn.microsoft.com/en-us/windows-server/storage/refs/refs-overv ...
… wird der Einsatz von ReFS bei iSCSI-Targets, …
… nur bedingt empfohlen.
OK, der mit dem Defender ist auch gut. 🙃
Du solltest die Ausnahme jedoch nicht nur für das Backup-Target konfigurieren, sondern auch für …
https://community.veeam.com/blogs-and-podcasts-57/updated-av-exclusions- ...
… diverse weitere Verzeichnisse/Dateierweiterungen. 😉
Bei uns, respektive, bei dem entsprechenden Kunden, sind die ReFS formatierten LUN’s auch erst um die Ohren geflogen, als > 150 TB an Daten auf diesen gespeichert waren, sprich, auch erst nach einigen Monaten. 😔
Zudem hatte der Kunde in der Zeit wo das Backup-Ziel noch auf ReFS war, auch extrem viele Probleme mit den Backupjobs selber, weil diese nicht immer sauber durchgelaufen sind. Immer wieder musste ein Full-Backup von Hand erstellt werden, damit die Jobs wieder von alleine durchlaufen.😭
Gruss Alex
Ja, das Dateisystem ist ReFS, was bei der Größe schon "fast nicht mehr anders geht"... und weils Veeam halt empfiehlt.
wie du aber gemäss des folgenden und bereits erwähnten Veeam-Artikels …
https://www.veeam.com/kb2792
… sehen kannst, ist ReFS auch seitens Veeam, nicht wirklich für dein Setup geeignet. 😔
Und auch in der folgenden Doku von Microsoft …
https://learn.microsoft.com/en-us/windows-server/storage/refs/refs-overv ...
… wird der Einsatz von ReFS bei iSCSI-Targets, …
… nur bedingt empfohlen.
Aber das Problem war hier - zumindest in unserem Fall - offenbar der Windows Defender.
OK, der mit dem Defender ist auch gut. 🙃
Du solltest die Ausnahme jedoch nicht nur für das Backup-Target konfigurieren, sondern auch für …
https://community.veeam.com/blogs-and-podcasts-57/updated-av-exclusions- ...
… diverse weitere Verzeichnisse/Dateierweiterungen. 😉
Ich gehe davon aus, dass das Problem erstmal gelöst ist. Werde aber Tipps bezüglich ReFS im Hinterkopf behalten, falls da nochmal trotz des Ausschlusses vom Defender ein ähnlich gelagertes Problem auftreten sollte.
Bei uns, respektive, bei dem entsprechenden Kunden, sind die ReFS formatierten LUN’s auch erst um die Ohren geflogen, als > 150 TB an Daten auf diesen gespeichert waren, sprich, auch erst nach einigen Monaten. 😔
Zudem hatte der Kunde in der Zeit wo das Backup-Ziel noch auf ReFS war, auch extrem viele Probleme mit den Backupjobs selber, weil diese nicht immer sauber durchgelaufen sind. Immer wieder musste ein Full-Backup von Hand erstellt werden, damit die Jobs wieder von alleine durchlaufen.😭
Gruss Alex
Allgemein abraten von ReFS würde ich jetzt nicht. Wichtig ist eben, dass die darunterliegende Hardware ReFS unterstützt, bzw. es sich um zertifizierte Hardware handelt. Und das ist weniger ein Veeam Thema, sondern liegt bei Microsoft und den Hardware Herstellern. Deswegen auch die Hinweise im KB Artikel oder im Helpcenter:
Wenn die Hardware passt, dann würde ich wegen den Vorteilen von Fast Clone ReFS immer NTFS vorziehen.
Das Microsoft aber des öfteren durch Updates Probleme gemacht hat würde ich nicht abstreiten. Das letzte Thema wurde ja bereits oben verlinkt und trifft nicht exklusiv den Veeam Agent sondern auch alle anderen Lösungen (und vermutlich jede Software die ReFS Features nutzt).
Was ich jetzt eventuell überlesen habe, welches iSCSI Storage Ihr einsetzt?
Bezüglich dem Windows Defender und auch allen anderen Security Lösungen sollten die Ausnahmen entsprechend gesetzt werden. Ohne diese kann es zu Performance- und Stabilitäts-Problemen, bis hin zu defekten Backup Files kommen.
https://www.veeam.com/kb1999
All ReFS supported configurations must use Windows Server Catalog certified hardware. For other requirements, limitations and known issues, see this Veeam KB article.
Wenn die Hardware passt, dann würde ich wegen den Vorteilen von Fast Clone ReFS immer NTFS vorziehen.
Das Microsoft aber des öfteren durch Updates Probleme gemacht hat würde ich nicht abstreiten. Das letzte Thema wurde ja bereits oben verlinkt und trifft nicht exklusiv den Veeam Agent sondern auch alle anderen Lösungen (und vermutlich jede Software die ReFS Features nutzt).
Was ich jetzt eventuell überlesen habe, welches iSCSI Storage Ihr einsetzt?
Bezüglich dem Windows Defender und auch allen anderen Security Lösungen sollten die Ausnahmen entsprechend gesetzt werden. Ohne diese kann es zu Performance- und Stabilitäts-Problemen, bis hin zu defekten Backup Files kommen.
https://www.veeam.com/kb1999
1
Moin @regnor,
eher nur bei Microsoft, weil sie ReFS ohne grossartige Rücksprache mit der Hardware-Welt geboren haben. 😔
Und externe SAN's oder NAS Geräte, können die seid ihrem S2D-Tripp, eh nicht mehr wirklich gut leiden.
Ja, aber dann gilt immer noch das ...
... hier. 🙃
Gruss Alex
Allgemein abraten von ReFS würde ich jetzt nicht. Wichtig ist eben, dass die darunterliegende Hardware ReFS unterstützt, bzw. es sich um zertifizierte Hardware handelt. Und das ist weniger ein Veeam Thema, sondern liegt bei Microsoft und den Hardware Herstellern.
eher nur bei Microsoft, weil sie ReFS ohne grossartige Rücksprache mit der Hardware-Welt geboren haben. 😔
Und externe SAN's oder NAS Geräte, können die seid ihrem S2D-Tripp, eh nicht mehr wirklich gut leiden.
All ReFS supported configurations must use Windows Server Catalog certified hardware. For other requirements, limitations and known issues, see this Veeam KB article.
Ja, aber dann gilt immer noch das ...
For SANs, if features such as thin provisioning, TRIM/UNMAP, or Offloaded Data Transfer (ODX) are required, NTFS must be used.
... hier. 🙃
Gruss Alex
Das Storage ist ein QSAN XS3324D mit SFP+
Jeder Controller ist mit 2 Modulen verbunden.
Switch ist ein Aruba 5406R zl2 mit 2 SFP+-Modulen
von denen jeder Controller auf jedes dieser Module je 1 Verbindung hat.
Diese sind dann je QSAN-Controller zu LAG zusammengefasst.
Die Verbindung Backup-Server ist mit Cat6a-Kabel auf den selben Switch
mit 10 GBit RJ45.
Durch VLans schauen die beiden NICs in verschiedene Netze, einmal zum
Abrufen der Daten aus der VMWare und einmal zum Schrieben auf das Target.
Die HDDs sind 24 TB SAS HDDs im Raid 6.
Habe ich noch was vergessen??
Grüße
Mondragor
Jeder Controller ist mit 2 Modulen verbunden.
Switch ist ein Aruba 5406R zl2 mit 2 SFP+-Modulen
von denen jeder Controller auf jedes dieser Module je 1 Verbindung hat.
Diese sind dann je QSAN-Controller zu LAG zusammengefasst.
Die Verbindung Backup-Server ist mit Cat6a-Kabel auf den selben Switch
mit 10 GBit RJ45.
Durch VLans schauen die beiden NICs in verschiedene Netze, einmal zum
Abrufen der Daten aus der VMWare und einmal zum Schrieben auf das Target.
Die HDDs sind 24 TB SAS HDDs im Raid 6.
Habe ich noch was vergessen??
Grüße
Mondragor
Moin @Mondragor,
OK, ein QSAN, sieht auch nicht schlecht aus, zumindest auf dem Papier.
https://www.qsan.com/data/dl_files/qs_ds_XS3300_(en).pdf
Und auf diesem sehe ich, dass das Ding seinen Speicherplatz ja auch per SMB bereitstellen,
sprich auch ein NAS sein kann. 😁
Wenn ja, dann empfehle ich dir eher, das Backup-Repository per SMB mit Multichannel anzubinden,
das hat sich zumindest bei den Systemen unserer Kunden (Hyper-V + Veeam), sich als die besserer Lösung erwiesen. 😉
Bitte sicherstellen, dass auf den Ports über die insbesondere der iSCSI-Datenverkehr läuft, Flow-Controll aktiviert ist, auch auf den entsprechenden NIC's der Server.
Aber Vorsicht, wenn du FC aktivierst oder deaktivierst, geht der entsprechende Port kurz down!
Das würde ich so nicht machen, sondern eher über MPIO bündeln.
👍
Machen wir auch sehr ähnlich, nur mit dem Unterschied, dass wir keine QSAN's, sondern die folgenden ...
https://www.infortrend.com/de/products/families/gs/3000
... "Unified" SAN's verwenden, die übrigens auf nur 4HE's bis zu 90 3,5" Bay's bereitstellen können.
Gruss Alex
Das Storage ist ein QSAN XS3324D mit SFP+
Jeder Controller ist mit 2 Modulen verbunden.
Jeder Controller ist mit 2 Modulen verbunden.
OK, ein QSAN, sieht auch nicht schlecht aus, zumindest auf dem Papier.
https://www.qsan.com/data/dl_files/qs_ds_XS3300_(en).pdf
Und auf diesem sehe ich, dass das Ding seinen Speicherplatz ja auch per SMB bereitstellen,
sprich auch ein NAS sein kann. 😁
Wenn ja, dann empfehle ich dir eher, das Backup-Repository per SMB mit Multichannel anzubinden,
das hat sich zumindest bei den Systemen unserer Kunden (Hyper-V + Veeam), sich als die besserer Lösung erwiesen. 😉
Switch ist ein Aruba 5406R zl2 mit 2 SFP+-Modulen
Bitte sicherstellen, dass auf den Ports über die insbesondere der iSCSI-Datenverkehr läuft, Flow-Controll aktiviert ist, auch auf den entsprechenden NIC's der Server.
Aber Vorsicht, wenn du FC aktivierst oder deaktivierst, geht der entsprechende Port kurz down!
Diese sind dann je QSAN-Controller zu LAG zusammengefasst.
Das würde ich so nicht machen, sondern eher über MPIO bündeln.
Durch VLans schauen die beiden NICs in verschiedene Netze, einmal zum
Abrufen der Daten aus der VMWare und einmal zum Schrieben auf das Target.
Abrufen der Daten aus der VMWare und einmal zum Schrieben auf das Target.
👍
Die HDDs sind 24 TB SAS HDDs im Raid 6.
Machen wir auch sehr ähnlich, nur mit dem Unterschied, dass wir keine QSAN's, sondern die folgenden ...
https://www.infortrend.com/de/products/families/gs/3000
... "Unified" SAN's verwenden, die übrigens auf nur 4HE's bis zu 90 3,5" Bay's bereitstellen können.
Gruss Alex
SMB, NTFS... Bestehende Hard- und Software kann/muss man immer nach Möglichkeit zusammenwürfeln, um es irgendwie zum Laufen zu bekommen. Erklärt aber nicht, warum Kunden von angeblichen "Systemhäusern" so regelmäßig hinter die Fichte geführt werden.
ReFS und Veeam sind jeweils robuste, gut dokumentierte Lösungen. Wenn ich Veeam einsetze, will ich ReFS. Daher brauche ich einen Storage-Stack, der ReFS stabil unterstützt. Erste Wahl Storage-Spaces. Zweite Wahl eine gleichwertiger DAS-Resilienzschicht - schon das unter Verzicht auf die Interoperabilität von Dateisystem/Integritätsschicht und Resilienzschicht. Demenstsprechend dann lange nichts, dann dritte Wahl ein dünnes Sortiment an SANs unter engen Rahmenbedingungen.
Kann man sich also aus technischen Grundlagen herleiten. Muss man aber nicht, man kann einfach stupide den empfohlenen Design-Patterns von Veeam folgen und kommt auch so zu Storage Servern. Letzte Instanz vor DAS: Der Veeam Data Mover.
Das ist ein Kernkonzept dieser Lösung. Vieles andere geht, wenig davon ist sinnvoll, in den meisten Fällen beschneidet es teuer bezahlte Features.
Aber nein, man will ja die Lieblings-Storage-Appliance und iSCSI-Klöppeleien verkaufen, weil man das schon immer so gemacht hat, ohne irgendwas dazuzulernen. Im Zweifel ist der Hersteller schuld, im Einrichtungsassistenten keinen Idiotentest einzubauen, und die misratene Integration darf beim Kunden auf einem Bein weiterhumpeln - zum ursprünglichen Preis, zzgl. der herausfordernden "Entstörung" der vermeintlichen Herstellerversäumnisse natürlich.
ReFS und Veeam sind jeweils robuste, gut dokumentierte Lösungen. Wenn ich Veeam einsetze, will ich ReFS. Daher brauche ich einen Storage-Stack, der ReFS stabil unterstützt. Erste Wahl Storage-Spaces. Zweite Wahl eine gleichwertiger DAS-Resilienzschicht - schon das unter Verzicht auf die Interoperabilität von Dateisystem/Integritätsschicht und Resilienzschicht. Demenstsprechend dann lange nichts, dann dritte Wahl ein dünnes Sortiment an SANs unter engen Rahmenbedingungen.
Kann man sich also aus technischen Grundlagen herleiten. Muss man aber nicht, man kann einfach stupide den empfohlenen Design-Patterns von Veeam folgen und kommt auch so zu Storage Servern. Letzte Instanz vor DAS: Der Veeam Data Mover.
Das ist ein Kernkonzept dieser Lösung. Vieles andere geht, wenig davon ist sinnvoll, in den meisten Fällen beschneidet es teuer bezahlte Features.
Aber nein, man will ja die Lieblings-Storage-Appliance und iSCSI-Klöppeleien verkaufen, weil man das schon immer so gemacht hat, ohne irgendwas dazuzulernen. Im Zweifel ist der Hersteller schuld, im Einrichtungsassistenten keinen Idiotentest einzubauen, und die misratene Integration darf beim Kunden auf einem Bein weiterhumpeln - zum ursprünglichen Preis, zzgl. der herausfordernden "Entstörung" der vermeintlichen Herstellerversäumnisse natürlich.
Moin @c.r.s.,
was Veeam angeht, so trifft deine Aussage durchaus zu, bei ReFS ist das jedoch definitiv nicht der Fall,
vor allem was dessen Dokumentation angeht.
Aha und warum genau, sprich was für ein Wunder erhoffst du dir davon?
Selbst Microsoft, empfiehlt ReFS nur bedingt und setzt bei den Boot-Drives auch noch nach wie vor auf NTFS und selbst beim SQL-Server wird (wieder) ausschliesslich NTFS empfohlen.
Ähm sorry, aber spättestens hier, hast du dich gewaltigst vergriffen.
Denn sowohl das vom TO verwendete QSAN als auch die von mir empfohlenen Infortrend Units, sind im Vergleich zu einem S2D System, welches diese Kapazitäten überhaupt händeln kann, mit vergleisweise sehr maggeren Hardware bestückt. Aber, aus dieser relativ überschaubaren Hardware, schaffen es beide Hersteller eine enorme Leistung herauszukitzeln und im Falle von Infortrend, kann ich dir garantieren, dass diese Leistung auch mindestens bereitgestellt wird. Und das schaffen diese Units unter anderem deshalb, weil deren OS nur auf performante Datenbereitstellung getrimmt ist und nicht noch sonstigen Schnickschnack mit sich schleppen muss.
Also nein, du kannst ein erwachsenes Enterprise-SAN nicht wirklich mit einem S2D System vergleichen,
oder das letztere als gar überlegen darstellen, denn das ist meiner Ansicht und auch Erfahrung nach, schlichtweg Augenwischerei.
Nein, das kann man eben nicht, vor allem wenn man auch noch extra ein S2D System nur als Backup-Storage aufsetzen möchte.
Ja, wir haben die Units früher auch über iSCSI angebunden, aber, wie ich schon geschrieben habe, machen wir das aus diversen Gründen mittlerweile per SMB. Zumindest in Verbindung mit Hyper-V und Veeam, hat sich das als die bisher stabilste und auch performanteste Variante bewiesen.
Sprich, dazulernen können wir schon, dazu muss man sich aber nicht von jeglichem Schnickschnack auch gleich vollständig blenden lassen. 😉
Gruss Alex
ReFS und Veeam sind jeweils robuste, gut dokumentierte Lösungen.
was Veeam angeht, so trifft deine Aussage durchaus zu, bei ReFS ist das jedoch definitiv nicht der Fall,
vor allem was dessen Dokumentation angeht.
Wenn ich Veeam einsetze, will ich ReFS.
Aha und warum genau, sprich was für ein Wunder erhoffst du dir davon?
Daher brauche ich einen Storage-Stack, der ReFS stabil unterstützt.
Selbst Microsoft, empfiehlt ReFS nur bedingt und setzt bei den Boot-Drives auch noch nach wie vor auf NTFS und selbst beim SQL-Server wird (wieder) ausschliesslich NTFS empfohlen.
Erste Wahl Storage-Spaces. Zweite Wahl eine gleichwertiger DAS-Resilienzschicht - schon das unter Verzicht auf die Interoperabilität von Dateisystem/Integritätsschicht und Resilienzschicht. Demenstsprechend dann lange nichts, dann dritte Wahl ein dünnes Sortiment an SANs unter engen Rahmenbedingungen.
Ähm sorry, aber spättestens hier, hast du dich gewaltigst vergriffen.
Denn sowohl das vom TO verwendete QSAN als auch die von mir empfohlenen Infortrend Units, sind im Vergleich zu einem S2D System, welches diese Kapazitäten überhaupt händeln kann, mit vergleisweise sehr maggeren Hardware bestückt. Aber, aus dieser relativ überschaubaren Hardware, schaffen es beide Hersteller eine enorme Leistung herauszukitzeln und im Falle von Infortrend, kann ich dir garantieren, dass diese Leistung auch mindestens bereitgestellt wird. Und das schaffen diese Units unter anderem deshalb, weil deren OS nur auf performante Datenbereitstellung getrimmt ist und nicht noch sonstigen Schnickschnack mit sich schleppen muss.
Also nein, du kannst ein erwachsenes Enterprise-SAN nicht wirklich mit einem S2D System vergleichen,
oder das letztere als gar überlegen darstellen, denn das ist meiner Ansicht und auch Erfahrung nach, schlichtweg Augenwischerei.
Kann man sich also aus technischen Grundlagen herleiten.
Nein, das kann man eben nicht, vor allem wenn man auch noch extra ein S2D System nur als Backup-Storage aufsetzen möchte.
Aber nein, man will ja die Lieblings-Storage-Appliance und iSCSI-Klöppeleien verkaufen, weil man das schon immer so gemacht hat, ohne irgendwas dazuzulernen.
Ja, wir haben die Units früher auch über iSCSI angebunden, aber, wie ich schon geschrieben habe, machen wir das aus diversen Gründen mittlerweile per SMB. Zumindest in Verbindung mit Hyper-V und Veeam, hat sich das als die bisher stabilste und auch performanteste Variante bewiesen.
Sprich, dazulernen können wir schon, dazu muss man sich aber nicht von jeglichem Schnickschnack auch gleich vollständig blenden lassen. 😉
Gruss Alex
Einige Modelle von QSAN sind schon einmal in der Veeam Ready Datenbank gelistet als iSCSI Target; was aber nicht einschließt, dass ReFS unterstützt ist. Gegebenenfalls direkt beim Hersteller nachfragen oder ReFS als "nicht supported" annehmen. Auf NTFS zu wechseln wäre dann die sicherere Variante, aber ansonsten mindestens die Health Checks konfigurieren und 3-2-1 noch mehr beachten.
https://www.veeam.com/partners/alliance-partner-technical-programs.html? ...
@MysticFoxDE: Unterstützen die Infortrend Systeme continuous availability und falls ja, habt ihr das dann für die Shares aktiviert?
https://www.veeam.com/partners/alliance-partner-technical-programs.html? ...
@MysticFoxDE: Unterstützen die Infortrend Systeme continuous availability und falls ja, habt ihr das dann für die Shares aktiviert?
Moin @regnor,
aber selbstverständlich ...
Quelle:
https://www.infortrend.com/global/solutions/ha-service
... . 😉
Auf einer Unit mit zwei Controllern muss man für das HA, respective "continuous availability" selber, nichts extra konfigurieren, hier erfolgt das Failover/Failback vollkommen automatisch.
Die Infortrend GS Units unterstützen sogar "Immutable Backup" ...
https://www.infortrend.com/event2023/202308-gs-g3/202308-backup-solution ...
... . 😁
Gruss Alex
@MysticFoxDE: Unterstützen die Infortrend Systeme continuous availability
aber selbstverständlich ...
Infortrend’s HA (High Availability) service is a powerful solution for storage clusters, enabling enterprises to provide continuous availability for their data and applications. Supported on scale-out unified storage solutions, EonStor GS for enterprises and EonStor GSe for SMB, the HA service ensures uninterrupted operations with site resilience, achieving near-zero Recovery Time Objective (RTO) and zero Recovery Point Objective (RPO). The HA service is utilized in scenarios where data accessibility and system uptime are critical, helping to avoid reputational damages and revenue losses caused by potential disruptions in services.
Quelle:
https://www.infortrend.com/global/solutions/ha-service
... . 😉
und falls ja, habt ihr das dann für die Shares aktiviert?
Auf einer Unit mit zwei Controllern muss man für das HA, respective "continuous availability" selber, nichts extra konfigurieren, hier erfolgt das Failover/Failback vollkommen automatisch.
Die Infortrend GS Units unterstützen sogar "Immutable Backup" ...
https://www.infortrend.com/event2023/202308-gs-g3/202308-backup-solution ...
... . 😁
Gruss Alex
Zitat von @MysticFoxDE:
Aha und warum genau, sprich was für ein Wunder erhoffst du dir davon?
Wenn ich Veeam einsetze, will ich ReFS.
Aha und warum genau, sprich was für ein Wunder erhoffst du dir davon?
Veeam lagert Verwaltungsoperationen an ReFS aus. Das Dateisystem des Repos beeinflusst daher maßgeblich die Dauer der Backup-Jobs, im Ergebnis die mögliche Parallelisierung und damit das Sizing, betriebswirtschaftlich den ROI.
Wenn man es anders sieht, macht man es anders. Es ist nur eine begründete Empfehlung.
Hier sind Fälle dokumentiert, wo es eben nicht anders gemacht wurde, weil das abgewogen und entschieden worden wäre. Die Empfehlung wird in diesen Fällen durchaus umgesetzt, jedoch in einer untauglichen Integration. Erst sobald sich dies zeigt, wird gezwungenermaßen von der Empfehlung abgewichen und auf einen insoweit reduzierten Funktionsumfang umkonfiguriert.
Der Kunde muss damit leben, weil… äh… die Empfehlung des Software-Herstellers falsch ist, genau.
Selbst Microsoft, empfiehlt ReFS nur bedingt und setzt bei den Boot-Drives auch noch nach wie vor auf NTFS und selbst beim SQL-Server wird (wieder) ausschliesslich NTFS empfohlen.
ReFS ist für manches geeignet, für anderes nicht. Verschiedene Technik für verschiedene Anwendungsfälle. Völlig egal, denn hier, d.h. vom Standpunkt der umzusetzenden Backup-Lösung gesehen, ist es geeignet, vom Hersteller ausdrücklich empfohlen und objektiv empfehlenswert.
Denn sowohl das vom TO verwendete QSAN als auch die von mir empfohlenen Infortrend Units, sind im Vergleich zu einem S2D System, welches diese Kapazitäten überhaupt händeln kann, mit vergleisweise sehr maggeren Hardware bestückt...
Storage-Spaces ist nicht gleich S2D, auch das geht am Thema vorbei. Der springende Punkt ist:
ReFS ist ein Verbunddateisystem mit Storage-Spaces als Resilienzschicht. Die andere zentrale Zielsetzung von ReFS neben Resilienz ist Integrität, d.h. unter keinen Umständen falsche Daten zu liefern. Die Resilienzschicht ist die Arbeitsvoraussetzung der Integritätsschicht; speziell Storage-Spaces als durch das Dateisystem steuerbare Resilienzschicht ist Arbeisvoraussetzung hinsichtlich der Datenkorrektur. Ansonsten bleibt nur die Verweigerung der Ausgabe zur Erfüllung des Integritätsparadigmas.
Über diesen Aufbau muss man sich im Klaren sein, wenn man Storage-Spaces als Resilienzschicht ersetzt. Je fragiler der Signalweg zwischen Resilienz- und Integritätsschicht, desto geringer die Verfügbarkeit der Resilienzschicht aus Sicht des Dateisystemtreibers, desto größer die Sollbruchstelle.
Daran können auch SAN-Hersteller im Grundsatz nichts ändern, sondern es eben mitigieren und gegen Fehlerbedingungen testen, validieren. Es bleibt eine Sollbruchstelle, mal größer, mal kleiner, mal mehr oder weniger relevant. Keine Fage, das kann man alles differenziert abwägen und anhand der konkreten Gegebenheiten zu jedem denkbaren Ergebnis kommen.
Es passiert aber offensichtlich nicht, sondern in kompletter Ignoranz der technischen Zusammenhänge werden Sollbruchstellen von der Größe des Grand Canyon eingebaut und dann Legenden gesponnen, wenn die Daten weg sind.
@MysticFoxDE Die Seite hatte ich auch schon gefunden aber war mir dann nicht sicher, ob continuous availability eingesetzt wird oder das im Text als Feature dargestellt wird😅
Gewundert hatte ich mich auch, weil sie zwar als Object und iSCSI Repository in der Veeam Ready gelistet sind, nicht aber als SMB Repository.
Für alle anderen die SMB einsetzen (wollen), ist folgender KB Artikel interessant.
https://www.veeam.com/kb3124
Gewundert hatte ich mich auch, weil sie zwar als Object und iSCSI Repository in der Veeam Ready gelistet sind, nicht aber als SMB Repository.
Für alle anderen die SMB einsetzen (wollen), ist folgender KB Artikel interessant.
https://www.veeam.com/kb3124
Moin @MysticFoxDE,
ich kann dir eins versichern, da wo andere Hersteller gerne übertreiben, mach Infortrend genau das Gegenteil davon,
sprich, sie versprechen eher weniger, als sie anschliessend liefern.
Siehe ...
Infortrend DS4000U - Meine neue Liebe . . . natürlich nur SAN technisch
... und laut Infortrend selber, sollte die Unit eigentlich nur max. 1.000.000 IO/s bringen. 😁
Ist wahrscheinlich seitens Infortrend nicht gemacht worden, weil bisher noch kein Kunde dies verlangt hat. 🙃
Gruss Alex
Die Seite hatte ich auch schon gefunden aber war mir dann nicht sicher, ob continuous availability eingesetzt wird oder das im Text als Feature dargestellt wird. 😅
ich kann dir eins versichern, da wo andere Hersteller gerne übertreiben, mach Infortrend genau das Gegenteil davon,
sprich, sie versprechen eher weniger, als sie anschliessend liefern.
Siehe ...
Infortrend DS4000U - Meine neue Liebe . . . natürlich nur SAN technisch
... und laut Infortrend selber, sollte die Unit eigentlich nur max. 1.000.000 IO/s bringen. 😁
Gewundert hatte ich mich auch, weil sie zwar als Object und iSCSI Repository in der Veeam Ready gelistet sind, nicht aber als SMB Repository.
Ist wahrscheinlich seitens Infortrend nicht gemacht worden, weil bisher noch kein Kunde dies verlangt hat. 🙃
Gruss Alex
Moin @c.r.s.,
ja, das eine ist ein lokales Software-RAID was im Gegensatz zu einem Hardware-RAID schon einen ordentlichen Overhead produziert und das andere ist zusätzlich noch über das Netzwerk verteilt, was die Sache noch schlimmer macht, weil hier noch der Netzwerk-Overhead mit dazukommt. Und ja, ich weiss, den Netzwerkoverhead kann man mit RDMA reduzieren, jedoch nicht komplet eliminieren.
Was den Rest angeht, so habe ich den Worten von Microsoft betreffend ReFS auch mal blind vertraut.
Das Ergebniss war das Folgende ...
Warum ihr keine ReFS Formatierung für CSVs verwenden solltet, die von einem SAN bereitgestellt werden
... sprich, am Ende hat Microsoft dann doch eingesehen, dass ReFS bei CSV die durch ein SAN bereitgestellt werden,
alles andere als eine geile Idee ist, vor allem performancetechnisch.
Sprich, nein, leider ist bei weitem nicht alles ein Wunder was Microsoft gerne als ein solches verhaufen möchte und dazu zählt insbesondere ReFS, aber auch so Dinge wie RSC, was übrigens insbesondere auch für S2D, ein absolutes Performance-Gift ist.
Gruss Alex
Storage-Spaces ist nicht gleich S2D
ja, das eine ist ein lokales Software-RAID was im Gegensatz zu einem Hardware-RAID schon einen ordentlichen Overhead produziert und das andere ist zusätzlich noch über das Netzwerk verteilt, was die Sache noch schlimmer macht, weil hier noch der Netzwerk-Overhead mit dazukommt. Und ja, ich weiss, den Netzwerkoverhead kann man mit RDMA reduzieren, jedoch nicht komplet eliminieren.
Was den Rest angeht, so habe ich den Worten von Microsoft betreffend ReFS auch mal blind vertraut.
Das Ergebniss war das Folgende ...
Warum ihr keine ReFS Formatierung für CSVs verwenden solltet, die von einem SAN bereitgestellt werden
... sprich, am Ende hat Microsoft dann doch eingesehen, dass ReFS bei CSV die durch ein SAN bereitgestellt werden,
alles andere als eine geile Idee ist, vor allem performancetechnisch.
Sprich, nein, leider ist bei weitem nicht alles ein Wunder was Microsoft gerne als ein solches verhaufen möchte und dazu zählt insbesondere ReFS, aber auch so Dinge wie RSC, was übrigens insbesondere auch für S2D, ein absolutes Performance-Gift ist.
Gruss Alex
Okay, also es hat sich leider bestätigt, er hat zwar Freitag noch alle Backups gezogen, die in der VMware lagen, ist dann aber eingefroren (Windows-seitig).
Dementsprechend haben wir auf ein Storage, das noch zur Verfügung stand, ein Full BU geschrieben und das "alte" ReFS-Storage einmal neu mit NTFS und 128 kb Blockgröße formatiert.
Das ließ sich machen, nachdem in der Registry ein Eintrag gesetzt wurde, der das Caching für ReFS auf 0 gesetzt hat, sodass Veeam nach dem Start nicht mehr das System einfrieren lässt.
Der Verbrauch des RAMs ist nun DEUTLICH bescheidener und so kann man arbeiten, denken ich.
Das Voll-BU von dem "Zwischenstorage" wird nun durch Veeam dorthin migriert und darauf kann dann ab heute Abend wieder ein inkrementelles aufgebaut werden, so die Hoffnung...
Vielen Dank für all die Hinweise, zumindest konnte ich mir am Wochenende schon denken, woran es liegt, dass er wieder eingefroren war und war zwar nicht entspannt, aber konnte mir schon mal einen Plan machen, wie damit umzugehen ist.
Grüße
Mondragor
Dementsprechend haben wir auf ein Storage, das noch zur Verfügung stand, ein Full BU geschrieben und das "alte" ReFS-Storage einmal neu mit NTFS und 128 kb Blockgröße formatiert.
Das ließ sich machen, nachdem in der Registry ein Eintrag gesetzt wurde, der das Caching für ReFS auf 0 gesetzt hat, sodass Veeam nach dem Start nicht mehr das System einfrieren lässt.
Der Verbrauch des RAMs ist nun DEUTLICH bescheidener und so kann man arbeiten, denken ich.
Das Voll-BU von dem "Zwischenstorage" wird nun durch Veeam dorthin migriert und darauf kann dann ab heute Abend wieder ein inkrementelles aufgebaut werden, so die Hoffnung...
Vielen Dank für all die Hinweise, zumindest konnte ich mir am Wochenende schon denken, woran es liegt, dass er wieder eingefroren war und war zwar nicht entspannt, aber konnte mir schon mal einen Plan machen, wie damit umzugehen ist.
Grüße
Mondragor
4
Moin,
@Mondragor
Vielen Dank, dass Du hier noch ein Feedback postest, ist (leider) nicht selbstverständlich!
Drücke die Daumen, dass alles klappt!
Gruß
@Mondragor
Vielen Dank, dass Du hier noch ein Feedback postest, ist (leider) nicht selbstverständlich!
Drücke die Daumen, dass alles klappt!
Gruß
Moin @Mondragor,
ähm, Moment, das bedeutet ja, dass du die iSCSI LUN direkt als CSV an die Hyper-V Nodes angebunden hast. 😬
Aha und wie genau ist diese an den Veeam Server angebunden?
Das ist übrigens keine wirklich gute Idee, denn die iSCSI LUN sollte eher am Veeam Server dran hängen und nicht direkt am HV-Cluster.
Gruss Alex
Das ließ sich machen, nachdem in der Registry ein Eintrag gesetzt wurde, der das Caching für ReFS auf 0 gesetzt hat, sodass Veeam nach dem Start nicht mehr das System einfrieren lässt.
ähm, Moment, das bedeutet ja, dass du die iSCSI LUN direkt als CSV an die Hyper-V Nodes angebunden hast. 😬
Aha und wie genau ist diese an den Veeam Server angebunden?
Das ist übrigens keine wirklich gute Idee, denn die iSCSI LUN sollte eher am Veeam Server dran hängen und nicht direkt am HV-Cluster.
Gruss Alex
Das ließ sich machen, nachdem in der Registry ein Eintrag gesetzt wurde, der das Caching für ReFS auf 0 gesetzt hat, sodass Veeam nach dem Start nicht mehr das System einfrieren lässt.
ähm, Moment, das bedeutet ja, dass du die iSCSI LUN direkt als CSV an die Hyper-V Nodes angebunden hast. 😬
Nein, das ist ein Missverständnis. Wir haben in der Registry des VEEAM-Servers einen Registry-Wert gesetzt, der zuvor noch nicht bestand. Genau gesagt war es wohl in der "HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\" das DWORD "FileCacheLimitPercent", das wir auf 0 festgelegt haben.
Insofern war meine Aussage "Caching für ReFS" auf 0 gesetzt nicht richtig, sorry dafür.
Aber jedenfalls ist eben dieses Caching durch VEEAM das, was in der Konstellation die Maschine hat einfrieren lassen.
Davon abgesehen nutzen wir VMware. Der VEEAM-Server und das Backup-Ziel hängen im selben VLAN, die VMware hat darauf keinen direkten Zugriff.
Grüße
Mondragor
Moin @Mondragor,
ja, das sehe ich jetzt auch und du hast ja auch mehrfach VMware geschrieben ... keine Ahnung wie ich da auf Hyper-V rübergekommen bin. 🙃
😯 ... das wiederum sieht sehr interessant aus, denn es hat mich schon immer genervt, dass der Veeam Server beim Sichern den RAM mit dem zwischencachen zu sehr vollballert.
Hast du die Einstellung so belassen?
Wenn ja, hat sich das irgendwie auf deine Sicherungsperformance/Sicherungszeit ausgewirkt?
👍👍👍
Gruss Alex
Nein, das ist ein Missverständnis.
ja, das sehe ich jetzt auch und du hast ja auch mehrfach VMware geschrieben ... keine Ahnung wie ich da auf Hyper-V rübergekommen bin. 🙃
Wir haben in der Registry des VEEAM-Servers einen Registry-Wert gesetzt, der zuvor noch nicht bestand. Genau gesagt war es wohl in der "HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\" das DWORD "FileCacheLimitPercent", das wir auf 0 festgelegt haben.
Insofern war meine Aussage "Caching für ReFS" auf 0 gesetzt nicht richtig, sorry dafür.
Insofern war meine Aussage "Caching für ReFS" auf 0 gesetzt nicht richtig, sorry dafür.
😯 ... das wiederum sieht sehr interessant aus, denn es hat mich schon immer genervt, dass der Veeam Server beim Sichern den RAM mit dem zwischencachen zu sehr vollballert.
Hast du die Einstellung so belassen?
Wenn ja, hat sich das irgendwie auf deine Sicherungsperformance/Sicherungszeit ausgewirkt?
Davon abgesehen nutzen wir VMware. Der VEEAM-Server und das Backup-Ziel hängen im selben VLAN, die VMware hat darauf keinen direkten Zugriff.
👍👍👍
Gruss Alex
Hi @MysticFoxDE oder Alex, wenn's beliebt,
wir haben den Registryeintrag so belassen, meine ich, kann mich am Montag auch noch einmal vergewissern.
Würde Dir das Ergebnis dann am Montag mitteilen.
Nachtrag: Der Registry-Eintrag steht nach wie vor auf 0.
Aber die RAM-Last ist jetzt echt gechillt, auch wenn er schiebt und sichert. Das ist ein Riesenunterschied. Der ist in der Regel unter 10 GB RAM-Last. Drum gehe ich mal davon aus, dass er nicht cachet (schreibt man das so in denglisch?).
Flashcenhals dürften momentan die 2.5" HDDs sein, die zu 25 Stück das Raid 6 der (meisten) VMware VMs bilden.
Meines Erachtens hat sich an der Geschwindigkeit beim Sichern nicht maßgeblich geändert. Ein inkrementelles Backup aller VMs in 4 Klassen (SQL selbst, SQL dependent, SQL independent und eine ohne ApplicationAware...) dauert zusammen keine Stunde mehr. FullBackup der insgesamt ca. 21 TB dauert eine knappe "Nacht". Größte VM mit 12.4 TB ist in 7:54 Stunden durch.
SQL Full hat eine höchstgeschwindigkeit von > 1 GByte/s (lässt sich halt gut komprimieren).
Der Rest so zwischen 500 und 800 je nach Größe und Datenbeschaffenheit.
Wenn man bedenkt, dass die meisten VMs noch auf 2.5" HDDs liegen, finde ich das mehr als ordentlich.
Was das Caching betrifft, würde ich annehmen, dass das v.a. dann interessant wird, wenn das Ziel mit dem Schreiben nicht hinterher kommt. Aber bei uns ist die Quelle mit 10 GBit an einer Nic angebunden und das Ziel auf der anderen Nic ebenfalls. Lesen ist momentan von 25 x 2,5" HDD Raid6 und schreiben auf 24 x 3.5" HDD Raid6. Später dann von SSD auf HDD.
Da teste ich dann noch einmal, aber momentan veranlasst mich erst einmal nix, den Cache wieder einzuschalten.
Was noch hinzu kommen wird, ist die Migration der Produktionsdaten von einem Helios Fileserver auf einen Windows Dateiserver. Das geht dann komplett auf SSDs im Raid 6. Dafür fällt das Raid6 mit SSDs der aktuellen Helios-Fileserver-Konfig als neues Ziel der anderen VMware VMs an. Dann ist alles produktive auf SSDs im Raid6 und die Backups und Replications auf recht performanten HDDs.
So sieht erst einmal der Fahrplan aus...
Grüße
Mondragor
wir haben den Registryeintrag so belassen, meine ich, kann mich am Montag auch noch einmal vergewissern.
Würde Dir das Ergebnis dann am Montag mitteilen.
Nachtrag: Der Registry-Eintrag steht nach wie vor auf 0.
Aber die RAM-Last ist jetzt echt gechillt, auch wenn er schiebt und sichert. Das ist ein Riesenunterschied. Der ist in der Regel unter 10 GB RAM-Last. Drum gehe ich mal davon aus, dass er nicht cachet (schreibt man das so in denglisch?).
Flashcenhals dürften momentan die 2.5" HDDs sein, die zu 25 Stück das Raid 6 der (meisten) VMware VMs bilden.
Meines Erachtens hat sich an der Geschwindigkeit beim Sichern nicht maßgeblich geändert. Ein inkrementelles Backup aller VMs in 4 Klassen (SQL selbst, SQL dependent, SQL independent und eine ohne ApplicationAware...) dauert zusammen keine Stunde mehr. FullBackup der insgesamt ca. 21 TB dauert eine knappe "Nacht". Größte VM mit 12.4 TB ist in 7:54 Stunden durch.
SQL Full hat eine höchstgeschwindigkeit von > 1 GByte/s (lässt sich halt gut komprimieren).
Der Rest so zwischen 500 und 800 je nach Größe und Datenbeschaffenheit.
Wenn man bedenkt, dass die meisten VMs noch auf 2.5" HDDs liegen, finde ich das mehr als ordentlich.
Was das Caching betrifft, würde ich annehmen, dass das v.a. dann interessant wird, wenn das Ziel mit dem Schreiben nicht hinterher kommt. Aber bei uns ist die Quelle mit 10 GBit an einer Nic angebunden und das Ziel auf der anderen Nic ebenfalls. Lesen ist momentan von 25 x 2,5" HDD Raid6 und schreiben auf 24 x 3.5" HDD Raid6. Später dann von SSD auf HDD.
Da teste ich dann noch einmal, aber momentan veranlasst mich erst einmal nix, den Cache wieder einzuschalten.
Was noch hinzu kommen wird, ist die Migration der Produktionsdaten von einem Helios Fileserver auf einen Windows Dateiserver. Das geht dann komplett auf SSDs im Raid 6. Dafür fällt das Raid6 mit SSDs der aktuellen Helios-Fileserver-Konfig als neues Ziel der anderen VMware VMs an. Dann ist alles produktive auf SSDs im Raid6 und die Backups und Replications auf recht performanten HDDs.
So sieht erst einmal der Fahrplan aus...
Grüße
Mondragor
1
