Fileserver hat immer wieder Aussetzer (alle Freigaben weg und dann langsam)

[lefg 276]

vor 1 Minute schrieb peterg:

Die Frage bleibt, ob die unplanmäßige Zeitsynchronisation (die Zeit stimmt aber letztendlich dann doch  wieder - siehe meine Beschreibung) der Grund für den Aussetzer ist?

 

Schau ins Ereignisprotokoll! Die unplanmässige Zeitsynchronisation könnte eine sekundäre Folge sein.

[Tektronix 21]

vor 3 Stunden schrieb peterg:

Hallo, danke für die vielen Hinweise. Nachfolgend  meine Antworten.

 

Diese Artikel hatte ich auch schon gefunden. Dort steht aber, dass es die letzte Option sein sollte, da die Logs von einem MS Supportmitarbeiter ausgewertet werden müssen, was natürlich nicht unerhebliche Kosten verursacht.

 

Was gibt es hier für Risiken? Auf dem Fileserver ist auch eine Object Store DB. Wenn ich an der Reparaturmodus von Windows 7 denke, dann funktioniert danach nichts mehr.

 

Aktuell holt der Host die Zeit via CMOS Clock. -> Ändere  ich. VMware Tools sind installiert aber nur die "Statistikprotokollierung".

Zum Zeitpunkt der Aussetzter sind bisher keine Backups, Snapshots o.ä. gelaufen.

 

Zum Zeitpunkt der Aussetzter sind keine der "bestimmten Vorgänge" durchgeführt worden.

Die Aussetzer kommen urplötzlich im laufenden Betreib.

Ich hatte mit Server 2016 noch keine Probleme mit Reparatur des Contentstore. Bei der Windows 10 1709 war es ja so, das man nach Neuinstallation erst mal den Contentstore reparieren konnte.

bearbeitet 8. August 2018 von Tektronix

[Sunny61 809]

vor 4 Stunden schrieb peterg:

 

Kann ich beim nächsten "Aussetzter" mal probieren!

Es heißt Aussetzer, mit nur einem t, Danke. ;)

[peterg 15]

vor 5 Stunden schrieb Sunny61:

Es heißt Aussetzer, mit nur einem t, Danke. ;)

Deutschlehrer? In der Überschrift habe ich es zum Glück hinbekommen.

Ich glaube, dass es trotzdem alle verstanden haben. Vielen Dank!

bearbeitet 8. August 2018 von peterg

[Sunny61 809]

[OT]

Nein, kein Deutschlehrer, aber bei solchen Fehlern kann ich einfach nicht anders. ;) 

 

Es gibt leider zu viele tzt Fehler, deshalb muss ich da immer wieder reingrätschen, ist nichts persönliches. ;)

 

[/ot]

bearbeitet 8. August 2018 von Sunny61

[Tektronix 21]

Moin,

Event ID: 1 The system time has changed to <date:time> from <date:time>.

[peterg 15]

Hallo,

 

ich habe nun mal die betroffnene VM bzgl. VMware-Zeitaktualisierungen gemäß dem VMware Artikel https://kb.vmware.com/s/article/1189 "dicht" gemacht.

Mal sehen was passiert. Ich schaue mir nun auch jeden Tag die Protokolle an, ob irgendwas "verdächtiges" drin ist.

 

Könnten die "Aussetzer" (Lahmlegen des Fileservers) evtl. auch von einem defekten Gerät (Rechner, Switch, ...), Kabel oder Dose kommen?

 

Gruß,

Peter

 

 

bearbeitet 14. August 2018 von peterg

[Nobbyaushb 1.484]

vor 9 Stunden schrieb peterg:

Könnten die "Aussetzer" (Lahmlegen des Fileservers) evtl. auch von einem defekten Gerät (Rechner, Switch, ...), Kabel oder Dose kommen?

 

Moin,

bei Physik hätte ich mit ja geantwortet, bei einer VM eher nicht.

 

Man müsste in dem Fall den Host näher belauchten, was für Hardware ist drin, hat der Probleme auf dem LAN usw.

Sowas ist manchmal scher zu finden.

Wie viele VM laufen auf dem Host, haben andere VM´s auch Probleme?

 

Ansonsten - ist die Datenplatte der VM eine seperate VHDx?

 

Neue VM hochziehen, Shares der vorhandenen VM mit regedit exportieren, virtuelle Platte aus der VM nehmen, umbenennen und runterfahren, die neue VM den Namen der alten VM geben, Platte einbinden, shares importieren, reboot, fertig.

 

[peterg 15]

vor 13 Stunden schrieb Nobbyaushb:

Wie viele VM laufen auf dem Host, haben andere VM´s auch Probleme?

Es sind 2 HP Server  DL380 Gen9 (1 Jahr alt) mit je 3 VMs und ein HP DL 360 Gen9 als Management Server (z.B. für Veeam, ...).  Die anderen VMs haben scheinbar keine Probleme. Hier sind aber auch fast keine Shares angelegt. Über die betroffene VM laufen so gut wie alle produktiven Shares. Ich habe schon überlegt, ob man ein paar Shares zu Test mal auf eine andere VM verschiebt. Wenn wieder ein "Aussetzer" kommt, weiß man dann wenigstens, ob auch eine andere VM betroffen ist. Das könnte man soweit treiben, dass man feststellt, ob beide phsikalischen Server betroffen sind oder nur einer oder dann evtl. auch nur eine VM.

 

vor 13 Stunden schrieb Nobbyaushb:

Ansonsten - ist die Datenplatte der VM eine seperate VHDx?

Ja, jede VM hat eine eigene VHDx-Systempartition mit fester Größe.

 

Gruß,

Peter

[Nobbyaushb 1.484]

vor 2 Minuten schrieb peterg:

Ja, jede VM hat eine eigene VHDx-Systempartition mit fester Größe

Ich meine nicht die OS sonder die Datenplatte - die Daten liegen hoffentlich nicht auf dem OS-Volumen....

[peterg 15]

Die Daten liegen auf einer extra VHDx Partition mit fester Größe. Jede VM hat (wenn benötigt) eine extra Datenplatte. Der Fileserver hat eine Datenplatte mit ca. 4 TB (SAS-Platten der SAN) und eine mit 34 TB (SATA-Platten der SAN). Die 34 TB sind notwendig, da aufgrund von bestimmten Kanal-Berechnungen die temporären Berechnungsdateien mehrere TB groß sein können. Hier wollten wir sehr viel Reserve.

 

Ach ja, die EDV-Firma hat jetzt auch mal jeder VM eine eigene Netzwerkkarte gegeben (jeder Server hat ja 4 Stück 1Gbit onboard). Vorher waren die NICs zusammengefasst (die EDV-Firma meinte so was wie "port provisioning"). Eigentlich würden wir gerne aufgrund der Datensicherung (wegen dem wöchentlichen FullBackup und Stand der Technik) auf 10Gbit umstellen. Aber vorher möchten wir gerne wissen, woher der Fehler kommt.

 

Kann es sein, dass bei 38 Clients Gigabit nicht ausreicht?

bearbeitet 15. August 2018 von peterg

[Nobbyaushb 1.484]

Wie ist das SAN angebunden?

 

Mit den Netzwerkkarten von dem VM´s habe ich noch nicht ganz begriffen.

 

Die HP haben ja per Default 4 Broadcom drin, keine weiteren Karten / Fibrechannel drin?

[peterg 15]

Die SAN ist über Fibrechannel an die beiden HP Server angebunden. Im Netzwerk selbst sind die HP Server nur per Gbit (onboard NICs) angebunden.

bearbeitet 15. August 2018 von peterg

[mulu 11]

Moin,

sicher keine Hilfe bei der Fehlersuche, aber eine Lösung: vielleicht möchtest Du die Shares einfach auf eine andere VM umziehen und sehen, ob das Problem damit behoben ist.

Der VM wirst Du - wenn Du den Fehler nicht findest - sowieso nie wieder über den Weg trauen.

Pragmatischer Weg, um die Störungen in den Griff zu bekommen.

Natürlich keine Lösung, wenn das Problem nicht in der VM sitzt.

Gruß,

mulu

[peterg 15]

vor 5 Stunden schrieb mulu:

sicher keine Hilfe bei der Fehlersuche, aber eine Lösung: vielleicht möchtest Du die Shares einfach auf eine andere VM umziehen und sehen, ob das Problem damit behoben ist.

Hallo mulu, daran habe ich auch schon gedacht - siehe unten

Das wäre der nächste Schritt.

vor 11 Stunden schrieb peterg:

Ich habe schon überlegt, ob man ein paar Shares zu Test mal auf eine andere VM verschiebt. Wenn wieder ein "Aussetzer" kommt, weiß man dann wenigstens, ob auch eine andere VM betroffen ist. Das könnte man soweit treiben, dass man feststellt, ob beide phsikalischen Server betroffen sind oder nur einer oder dann evtl. auch nur eine VM.