Komisches DFS-R Verhalten

[daabm 1.356]

vor 4 Stunden schrieb goat82:

Fullbackup wird dann auf Server B gefahren, weil dort keine Zugriffe/Änderungen sind.

 

Wenn DFSR funktionieren würde, sind da genau so viele Änderungen wie auf Server a. Das Konzept hinkt... Aber das steht ja oben schon oft genug.

Und wenn Du nicht so verliebt in "deine" Lösung wärst, könnten wir hier sogar über Alternativen reden

[goat82 2]

Hi Daabm,

das Konzept war vor 15 Jahren sicher angemessen.

Nun sind die Daten halt mehr als angewachsen und das ganze wurde mehr als Stiefmütterlich behandelt.

Der Grund liegt an den fehlenden Resourcen. Nun kann man natürlich meckern und die Ferrilösung anbieten, aber ich kann beim besten Willen auf die Schnelle kein Ferari herzaubern.

 

Es handelt sich um ein produktives System und um keine Spielewiese. Selbst wenn ein Storage Replica oder anderes umgesetzt werden würde, müsste ich zuvor die Datenkonsistenz von Server A und B wiederherstellen. Die Daten sind von beiden Server in Zugriff (>400 User). Ich kann hier auch nicht einfach mal rumspielen, Replikationspartner oder Freigaben löschen und das Ganze auf die Harte Tour gerade biegen bis ein angemessenes, natürlich besseres Konzept angewendet werden kann.

 

Daher möchte ich erstmal die Daten von Server A und B auf einen Stand bringen (am liebsten via DFS wenn es vernünpftig und performant laufen würde), Server B vom Zugriff und von den Replikationsgruppen entfernen und dann ein neues, sauberes Konzept erstellen und umsetzen mit den MIttel die da sind. Hier nehme ich gerne Rat und Vorschläge an und behare nicht auf das alte und langsame DFS-R. Ein gespiegeltes Rechenzentrum, Vsphere Cluster oder ähnliches steht aber nicht zur Verfügung. Ebenso ist primäre Aufgabe die Datenkonsistenz wiederherzustellen auch wenn ich nicht denke das dies mit DFSR erreicht werden kann, weil es einfach zu viele Daten sind. (Delta ist nur 400GB und nur ca. 0,5Mio Daten aber das reicht anscheinend DFS-R um den Dienst zu verweigern. Ich werde mal versuchen am Wochenende mit Robocopy die Daten von Server A auf Server B zu kopieren in der Hoffnung, das DFS-R dann wieder auf die Beine kommt damit man das ganze endlich vernünftig angehen kann.

 

 

[NilsK 2.939]

Moin,

 

@goat82, nimm es mir nicht übel, aber du widersprichst dir selbst und du bist auf dem besten Weg, dein Problem zu verschärfen.

 

Gerade wenn dieses gilt:

 

vor einer Stunde schrieb goat82:

Es handelt sich um ein produktives System und um keine Spielewiese.

 

dann verbietet es sich, an einem bekanntermaßen instabilen System herumzureparieren. Insbesondere wenn bekannt und bestätigt ist, dass das System für die Art von Anforderungen gar nicht gedacht und geeignet ist. Du bist von allen hier im Thread der einzige, der deine Umgebung kennt, aber alles, was du bislang gesagt hast, deutet darauf hin, dass das System unzuverlässig ist und du mit jedem Versuch, wieder etwas hinzubiegen, das Risiko des Datenverlusts und des Produktionsausfalls vergrößerst.

 

Aus der "Ferne", sprich hier in diesem Forum, kann es nur eine Empfehlung geben: Sorge dafür, dass du wenigstens eine funktionierende Datensicherung hast. Setze die Anwender in Kenntnis, dass das System aktuell nicht wie erwartet funktioniert. Schränke die Zugriffe auf das nicht ordentlich laufende System auf das absolute Minimum ein. Hol dir jemanden ins Haus, mit dem du zügig ein neues System entwirfst und aufbaust.

 

Gruß, Nils

 

[daabm 1.356]

vor einer Stunde schrieb goat82:

das Konzept war vor 15 Jahren sicher angemessen.

 

Nein, das war damals schon falsch. Es gibt einen Grund, daß Windows-Fileservices im RZ-Betrieb quasi bedeutungslos sind. Besorg Dir 2 Syno/QNap/Netapp/whatever und schieb das Zeug auf Storage, der für sowas gedacht ist.

[zahni 554]

Bei über 400 Usern sollte auch ausreichend Budget da sein, um hier angemessen funktionierende Lösungen zu implementieren.

[goat82 2]

Also so langsam glaube ich ist alles auf einem guten Weg. DFS läuft nun seit 3 Tagen zwar mit jede Menge Warnungen, siehe unten, aber es läuft.

Es dauert eben Tage bis die Backlogs abgearbeitet sind. Ich habe es nur hinbekommen indem ich das NTFS Journal erhöht habe. Hier war noch 512MB eingestellt, eindeutig zu wenig für x Millionen Daten. Zudem habe ich einzelne Replikationsgruppen nach und nach auf eine höhere Statinggröße gezogen. Dies konnte ich nicht gleichzeitig machen, da die Backlogs und Konflikte im DFSPrivate Ordner sich angesammelt haben und so wäre mir die Disc vollgelaufen - Ein Todesstoß von hinten , sozusagen.

Ich hoffe, dass nun alle Ordner abgearbeitet werden und es nun hoffentlich eine Zeit lang läuft. Spätestens nach 10 Tagen ist aber wieder die DFS Datenbank zerschossen und ich muss 7h ein chkdsk machen. Mal sehen ob es nun besser läuft. Wenn ja, habe ich Zeit die gemachten Fehler zu korrigieren.

 

Es existiert natürlich ein funktionelles Backup, welches aber nicht performt, denn der Restore der 25 TB dauert >24h.

Ein Chkdsk /F dauert ca. 5-7h

 

Bevor man an ein Konzept geht muss man erst mal reverse engeneering machen und das alles sauber analysieren und dokumentieren. Es gibt hunterte GPOs, login Scripte usw. die da reinwursteln. Natürlich würde ich niemals so viele Daten auf einem Volume und auch niemals mit DFS-R synchronisieren aber hier ist bzw. war es immer so.

Ich würde im ersten Schritt, wenn die Daten via DFS-R hoffentlich synchron sind erstmal die direkten Freigabeberechtigungen von Server B nehmen, dann läuft DFS-R sicherlich auch mit weniger Konflikten. Dann kann man schauen was möglich ist.  Aufgrund den Broadcom Vmware Mondpreisen überdenken ja auch viele Ihre Infrastruktur oder schauen sich andere Anbieter an. In diesem Fall ist es auch gerechtfertigt, da es ein Stand Alone ESX ist mit nur 3 Vms ist (File, DNS,DHCP). Hier würde sich ggf. eine Windowsmaschine / Cluster/Storage Replica / Andere Lösung mit dem anderen Stand alone Host anbieten.

Die Vorteile von ESX (Snapshots, HA, Vmotion usw.) wurden auf diesen beiden Stand alone ESXi nie genutzt.

 

 

The DFS Replication version vector size has exceeded acceptable limits.

The DFS Replication version vector size has reached back to the acceptable limits. 

)

bearbeitet 4. September von goat82

[daabm 1.356]

Was haben GPOs und Loginskripte mit einem vermurksten Verfügbarkeitskonzept für einen Fileservice zu tun? Wenn Du nur erzählen willst, was Du für Probleme hast und wie Du sie löst, bist Du hier mittelfristig falsch.

[cj_berlin 1.323]

vor 10 Stunden schrieb goat82:

Die Vorteile von ESX (Snapshots, HA, Vmotion usw.) wurden auf diesen beiden Stand alone ESXi nie genutzt.

Snapshots haben in Produktion nichts verloren, die würde ich auf gar keinen Fall zu Vorteilen zählen  Wenn ich 10 Euro für jede VM kriegen würde, die durch Snapshots den Datastore vollgeschrieben hat, könnte ich ein sehr langes Sabbatical machen.

 

HA braucht Shared Storage, und da ist man bei der nächsten Ebene von Single Point of Failure. Wenn hochverfügbares Storage nicht ohenhin ein Teil des Gesamtkonzeptes ist, brauchst Du HA keine Träne nachzuweinen.

 

Der Preis für vMotion ist der Betrieb von vCenter. (Für HA wird es zwar auch benötigt, aber nur zum Konfigurieren, funktionieren tut's dann auch ohne). Könnte ein Overkill sein, wenn keiner an Bord ist, der sich dafür zuständig fühlt.

[zahni 554]

Nur als Ergänzung: Snapshots kann man zur Datensicherung nutzen, die macht man dann aber auf dem Storage. Guter Storage kann die performanceneutral bereitstellen und er bietet dann auch noch weitere Sicherungsmöglichkeiten kann. VM-Snapshot kosten immer Performance, besonders, wenn man mehr als eine Instanz hat. Die kann man  nutzen, aber nur für Wartungsaufgaben, z.B. leichtes Rollback bei Software-Updates.

 

[goat82 2]

Ich kenne wirklich keinen Betrieb der eine VMwareumgebung hat und keine VM Snapshots einsetzt. Insbesonde vor wichtigen, kritischen Softwareupdates oder sonstigen Installationen.

Diese Revertmöglichkeit mit einem Rollback in Sekunden bietet glaube ich kein anderes System, von demher ein absoluter Pluspunkt.

Klar ist ein Snapshot kein Backup und ein ESX, Storage und Vcenter gehört immer überwacht und bestenfalls redundant ausgelegt, wenn es das Budget hergibt. Und logisch kosten Snapshots immer performance und sind unflexibel, da man die VM nicht ändern kann, wenn Snapshots existieren. Bei uns werden Snapshots automatisch gelöscht wenn Sie älter als 2 Wochen sind, zumindest im Vcenter. Auch ich kenne das Problem mit vollem Storage oder ESX durch Snapshot, hatte ich auch schon 3-4mal erlebt aber hier sehe ich das als keinen Fehler an auch kein Nachteil am System VM oder "Snapshot" sondern eben ein Fehler des Admins wenn er den Speicher oder seine Aufgaben nicht im Auge hat. Alles Theorie und Praxis, der Rest ist Lehrgeld.

 

@Daabm. GPO und Logonscripte haben mit DFS miteinander zu tun, zumindest in meinem Fall. Wenn Gpos und Logonscripte auf Freigaben auf Server B zeigen welcher via DFS-R auf Server A repliziert wird. 60% der User aber diese GPO nicht haben und per Namespacereferal auf Server A gehen ist logisch das es unpassend ist die Daten auf beiden Servern im doofsten Fall gleichzeitig zu laden und hin und herreplizieren und wenn dann noch gleichzeitig ein Backup streiklen sollte auf einem Server ist der Datenverlust und das Geschrei groß.........  Ich bin hier um Lösungen zu erfragen, mehr nicht. Das die derzeitige Umgebung höchst unprofessionell und strittig ist ist, weiß ich ja selbst Gibt es nun eine gute Alternative ?

[NilsK 2.939]

Moin,

 

Dir sind mehrere Ansätze genannt worden, wie du zu einer Lösung kommen kannst. Mehr gibt es hier aktuell nicht zu sagen. 

 

Gruß, Nils

[zahni 554]

Am 6.9.2024 um 22:27 schrieb goat82:

Ich kenne wirklich keinen Betrieb der eine VMwareumgebung hat und keine VM Snapshots einsetzt. Insbesonde vor wichtigen, kritischen Softwareupdates oder sonstigen Installationen.

Diese Revertmöglichkeit mit einem Rollback in Sekunden bietet glaube ich kein anderes System, von demher ein absoluter Pluspunkt.

Ja, dafür sind sie da. Und wenn man fertig ist, löscht man sie und lässt sie nicht dauerhaft bestehen.

Eine Ausnahme ist VMWare Horizon. Das ist aber ein anderes Thema.