Win2016 Failovercluster und SMB3

Hi,
wir haben bei uns ein komisches Verhalten.

Setup:
Mehrere Windows Failovercluster mit Win2016. In diesen Clustern laufen mehrere Fileserver-Rollen.
Die Cluster funktionieren ohne Probleme. Wir haben keine Probleme damit, dass die Clusterknoten fälschlicherweise erkennen würden, dass ein anderer Knoten angeblich offline sei und dann ein Failover versuchen und deshalb eine Freigabe offline wäre. Ich erwähne das, weil fast alle Hinweise, welche ich im Web bei der Suche gefunden habe, dieses als Grundlage nehmen.
Die FS-Rollen an sich funktionieren auch. Zugriff auf Shares funktioniert. HA auch (Transparent Failover). Die Rollen können ohne Probleme zwischen den Knoten verschoben werden.

Nun ist aufgefallen, dass Clients mit SMB3 (also Win8.1, Win2012R2 aufwärts) beim Öffnen einer Freigabe von diesen Clustern mit dem Explorer eine Kunstpause einlegen. Diese liegt so bei 1-2 min. Erst dann öffnet sich das Explorerfenster mit dem Inhalt der Freigabe.
Wenn man die Freigabe in einer CMD mit dem Dir-Befehl auflistet, dann gibt es diese Verzögerung nicht. Egal in welcher Reihenfolge man das testet: erst Explorer, dann CMD, oder umgekehrt.
Es betrifft nicht nur Freigaben der FS-Rollen sondern auch die administrativen Freigaben der Clusterknoten an sich, z.b. \\knoten1\c$
Von SMB2-Clients aus, z.B. Win208R2-Server, tritt dieser Effekt beim Zugriff auf die selben Freigaben mit dem selben Domänenkonto nicht auf.

Wenn man am SMB3-Client den Explorer mit einer Freigabe dieser Cluster startet, dann erscheint das Fenster erst nach 1-2 min. Wenn es aber einmal geöffnet ist, dann kann man ratzfatz in dieser Freigabe arbeiten. Verzeichnisse wechseln, Dateien öffnen usw.
Schließt man das Fenster und startet ein neues mit dieser Freigabe, dann wartet man wieder, bis es endlich geöffnet wird.

Kennt jemand dieses Verhalten oder könnte es mal nachstellen?

E.

Edit:
Beim Zugriff auf Freigaben anderer Fileserver mit Win2016, welche keine Failovercluster sind, also "normale" Fileserver, gibt es dieses Verhalten nicht.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 392061

Url: https://administrator.de/forum/win2016-failovercluster-und-smb3-392061.html

Ausgedruckt am: 13.04.2025 um 10:04 Uhr

16 Kommentare

Neuester Kommentar

Moin.

Nachstellen wird hier nichts. Aber: bist Du sicher, dass SMBv3 überhaupt erzwungen ist und verwendet wird?
Edit: Keine Zugriff auf Freigaben, wenn SMB2 und SMB1 deaktiviert sind listet Befehle zum Prüfen.

Hallo.

Es gibt doch seit irgendeiner Windows-Version (weiß nicht mehr genau, seit welcher, vielleicht schon seit XP?) dieses Zugriffs- und Kopierverhalten über den Explorer, daß sämtliche Dateien, auf die zugegriffen und/oder die geöffnet und/oder kopiert/vorschoben werden, eine Indexierung nach Multimedia-Tags vorgenommen wird, was jeglichem Zugriff oder auch Kopieraktionen über Explorer eine Bill-Gates-Gedächtnispause beschert hat. Ich weiß nicht, was sich bei SMB3 protokollseitig geändert hat, aber Deine Beobachtung, daß das mit dem DIR-Befehl aus einer cmd nicht passiert, hat mich genau daran erinnert.

Hier ein (vielleicht) ähnliches Beispiel:

https://answers.microsoft.com/de-de/windows/forum/all/unter-windows-10-l ...

Viele Grüße

von

departure69

Erzwungen nein.
Meines Wissens verwenden die SMB-Clients immer die höchstverfügbare Version, welche sie beim Aufbau der Verbindung aushandeln.
Aktiviert ist SMB3 auf beiden Seiten.

Am Server: Get-SmbServerConfiguration

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
AnnounceComment                 :
AnnounceServer                  : False
AsynchronousCredits             : 512
AuditSmb1Access                 : False
AutoDisconnectTimeout           : 15
AutoShareServer                 : True
AutoShareWorkstation            : True
CachedOpenLimit                 : 10
DurableHandleV2TimeoutInSeconds : 180
EnableAuthenticateUserSharing   : False
EnableDownlevelTimewarp         : False
EnableForcedLogoff              : True
EnableLeasing                   : True
EnableMultiChannel              : True
EnableOplocks                   : True
EnableSecuritySignature         : False
EnableSMB1Protocol              : True
EnableSMB2Protocol              : True
EnableStrictNameChecking        : True
EncryptData                     : False
IrpStackSize                    : 15
KeepAliveTime                   : 2
MaxChannelPerSession            : 32
MaxMpxCount                     : 50
MaxSessionPerConnection         : 16384
MaxThreadsPerQueue              : 20
MaxWorkItems                    : 1
NullSessionPipes                :
NullSessionShares               :
OplockBreakWait                 : 35
PendingClientTimeoutInSeconds   : 120
RejectUnencryptedAccess         : True
RequireSecuritySignature        : False
ServerHidden                    : True
Smb2CreditsMax                  : 8192
Smb2CreditsMin                  : 512
SmbServerNameHardeningLevel     : 0
TreatHostAsStableStorage        : False
ValidateAliasNotCircular        : True
ValidateShareScope              : True
ValidateShareScopeNotAliased    : True
ValidateTargetName              : True

Am Client: Get-SmbClientConfiguration

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
ConnectionCountPerRssNetworkInterface : 4
DirectoryCacheEntriesMax              : 16
DirectoryCacheEntrySizeMax            : 65536
DirectoryCacheLifetime                : 10
DormantFileLimit                      : 1023
EnableBandwidthThrottling             : True
EnableByteRangeLockingOnReadOnlyFiles : True
EnableInsecureGuestLogons             : True
EnableLargeMtu                        : True
EnableLoadBalanceScaleOut             : True
EnableMultiChannel                    : True
EnableSecuritySignature               : True
ExtendedSessionTimeout                : 1000
FileInfoCacheEntriesMax               : 64
FileInfoCacheLifetime                 : 10
FileNotFoundCacheEntriesMax           : 128
FileNotFoundCacheLifetime             : 5
KeepConn                              : 600
MaxCmds                               : 50
MaximumConnectionCountPerServer       : 32
OplocksDisabled                       : False
RequireSecuritySignature              : False
SessionTimeout                        : 60
UseOpportunisticLocking               : True
WindowSizeThreshold                   : 1

Meinen Edit hattest Du gesehen?

Zitat von @DerWoWusste:
Meinen Edit hattest Du gesehen?

Nein.

Get-SmbConnection liefert "Dialect 3.1.1"

@departure69
Keine Verzögerungen bei Dateiaktionen aus dem Explorer heraus, wenn er denn erst einmal gestartet ist.

Siehe mein Edit in der Frage.

Ist vielleicht ne komplett blöde ich Idee, aber ich hatte mal ein Problem das sich genau so geäußert hat, aber mit komplett anderen Hintergrund.

Versuch am Client der Probleme macht mal "net stop CscService" Stoppt die Offlinedateien.
Das Testen dauert ja nur 2 Minuten, vielleicht hilft es ja.

Zitat von @UnbekannterNR1:
Versuch am Client der Probleme macht mal "net stop CscService" Stoppt die Offlinedateien.
Das Testen dauert ja nur 2 Minuten, vielleicht hilft es ja.

Danke für den Ansatz, aber das kann ich ausschließen. Erstens sind ja mehrere Clients betroffen und zweitens auch Terminalserver unter Win2016 dabei, bei welchen die Offlinefiles komplett deaktiviert sind.

Ist bei Euch evtl. das sog. "SMB-Signing" (da wird der Datenverkehr bei SMB-Zugriffen signiert) im Einsatz? Dies kann Performanceprobleme verursachen, es gibt dazu aber Optimierungsmethoden, die die Performance wieder verbessern.

Zitat von @departure69:
Ist bei Euch evtl. das sog. "SMB-Signing" (da wird der Datenverkehr bei SMB-Zugriffen signiert) im Einsatz? Dies kann Performanceprobleme verursachen, es gibt dazu aber Optimierungsmethoden, die die Performance wieder verbessern.

Für die Cluster-Knoten gibt es diesbzgl. keine abweichenden Einstellung.

Bin jetzt etwas ratlos.
Fakt ist:

Client meldet bei Get-SMBConnection --> "Dialect 3.1.1" - Das heißt SMB3 ?

Fakt ist aber auch:

Wenn ich am Client mit Wireshark aufzeichne, dann sehe ich, dass Client und Server nur SMB2 aushandeln. Oder kann Wireshark in v2.6.4 kein SMB3 anzeigen?

Oh man, und gleich hinterher ....

Das "Problem" hat sich erledigt. Ist aber trotzdem ganz interessant ...

Einer alten Gewohnheit folgend habe ich die Freigaben aus einer CMD mit "start \\server\freigabe" aufgerufen.
Wenn ich das so mache, dann kommt es zu dieser Kunstpause.

Wenn ich direkt über
Start --> Ausführen --> \\server\freigabe --> enter
gehe, dann geht das ratzfatz.

Gut, jetzt habe ich mich 2 Tage selbst beschäftigt ...

Darauf gekommen bin ich, als ich bei einem weiteren Versuch während dieser Pause Strg+C gedrückt hatte. Dabei kam in der CMD sofort das Prompt und das Explorerfenster öffnete. Reproduzierbar.

Ja, heißt SMBv3. Wireshark zeigt das wohl nur so an, da SMB3 sehr eng verbandelt ist mit 2, siehe https://lists.samba.org/archive/samba/2014-February/178743.html

LOL! Oh Mann. Na, dann kannst Du ja froh ins Wochenende

Und noch eine Sache hat sich geklärt (durch Wireshark).

Ich schrieb im Edit, dass es nur bei FS im Failovercluster auftritt.

Jain. Beim Verbinden mit dem "normalen" Fileserver hatte ich den kurzen Namen verwendet. Dabei hat der Client über IPv6 aufgelöst. Damit gings sofort. Bei Eingabe des FQDN (unser DNS-Server hat nur A-Records für IPv4) oder bei direkter Angabe der IPv4-Adresse trat die Pause sofort wieder auf. (Wie oben schon erwähnt: Alles aus der CMD heraus.)

Interessant bleibt trotzdem: