8
SQL Server 2008 R2 Abbrüche am Client
Hallo Zusammen,
in einer unserer neuen Infrastrukturen gibt es seit neuestem immer das Problem, dass Clients die Verbindung zum SQL Server mit folgender Fehlermeldung verlieren:
Grundsätzlich sind die Server mit VMWare virtualisiert - es greifen zu Spitzenzeiten ca 20 Clients auf die DB zu, wobei das DB-Programm relativ "klein" ist und nur wenige Zeichen übertragen werden. Der Server 2008 R2 ist mit 64 GB RAM ausgestattet und hostet nur 2 SQL Datenbanken. Die RAM Auslastung ist aber auch zu Spitzenzeiten nur bei etwa 20 GB.
Die Infrastruktur würde ich eher ausschließen, da auch RTP Pakete fehlerfrei durchs Netzwerk gehen. Ansonsten gibt es keinerlei Engpässe oder Verbindungsabbrüche. Die jeweiligen Abteilungen sind in VLANs aufgeteilt, wobei auch Server / VoIP etc. in separaten VLANs sitzen.
Vom vorigen Admin wurde der Server mit 6 Netzwerkkarten an einen Switch Stack aus 2 Switchen angebunden - zur Redundanz. Ich vermute dass die Abbrüche daher kommen, dass kein Trunk (EtherChannel) eingerichtet wurde. Ich habe mir die ESX Konfig angesehen, wobei auch hier nur 2 Netzwerkkarten konfiguriert sind (die anderen 4 Stecken nur zum Spaß auf dem Switch) - diese 2 sind aber eben ohne EtherChannel auf einen vSwitch konfiguriert. Auf dem ESX Host laufen 4 VMs, diese teilen sich dann nur die beiden NICs. Kann es sein dass der Datenfluss somit willkürlich verteilt über die Leitungen geht und der SQL so manche Anfragen nicht mehr sauber zuordnen kann?
Meint ihr das Problem könnte daher kommen oder fällt euch noch was ein, was ich testen / ausschließen kann?
Grüße
MasterPhil
in einer unserer neuen Infrastrukturen gibt es seit neuestem immer das Problem, dass Clients die Verbindung zum SQL Server mit folgender Fehlermeldung verlieren:
Grundsätzlich sind die Server mit VMWare virtualisiert - es greifen zu Spitzenzeiten ca 20 Clients auf die DB zu, wobei das DB-Programm relativ "klein" ist und nur wenige Zeichen übertragen werden. Der Server 2008 R2 ist mit 64 GB RAM ausgestattet und hostet nur 2 SQL Datenbanken. Die RAM Auslastung ist aber auch zu Spitzenzeiten nur bei etwa 20 GB.
Die Infrastruktur würde ich eher ausschließen, da auch RTP Pakete fehlerfrei durchs Netzwerk gehen. Ansonsten gibt es keinerlei Engpässe oder Verbindungsabbrüche. Die jeweiligen Abteilungen sind in VLANs aufgeteilt, wobei auch Server / VoIP etc. in separaten VLANs sitzen.
Vom vorigen Admin wurde der Server mit 6 Netzwerkkarten an einen Switch Stack aus 2 Switchen angebunden - zur Redundanz. Ich vermute dass die Abbrüche daher kommen, dass kein Trunk (EtherChannel) eingerichtet wurde. Ich habe mir die ESX Konfig angesehen, wobei auch hier nur 2 Netzwerkkarten konfiguriert sind (die anderen 4 Stecken nur zum Spaß auf dem Switch) - diese 2 sind aber eben ohne EtherChannel auf einen vSwitch konfiguriert. Auf dem ESX Host laufen 4 VMs, diese teilen sich dann nur die beiden NICs. Kann es sein dass der Datenfluss somit willkürlich verteilt über die Leitungen geht und der SQL so manche Anfragen nicht mehr sauber zuordnen kann?
Meint ihr das Problem könnte daher kommen oder fällt euch noch was ein, was ich testen / ausschließen kann?
Grüße
MasterPhil
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 346548
Url: https://administrator.de/forum/sql-server-2008-r2-abbrueche-am-client-346548.html
Ausgedruckt am: 31.12.2024 um 20:12 Uhr
8 Kommentare
Neuester Kommentar
Moin,
sowas hatten wir vor gefühlten 100 Jahren auch mal, ich kann mich dunkel daran erinnern, dass damals entweder eine der HDD defekt war oder was am "Netzwerk" war. Ich würde mal an den HDDs ansetzen und mich zu Netzwerk durchhangeln, sprich im SQL Konfigurationsmanager die Netzwerkprotokolle und -ports prüfen, ggfs. unbenötigte Protokolle abschalten usw.
Und das ggfs. auch beim ESXi, wobei auch ein Switch hier diesen Ärger machen könnte.
Reagiert der Server beim Fehler auf ein Ping, kannst Du das prüfen?
Kannst Du den Fehler reproduzieren oder auch einzelne Clients eingrenzen?
Gruss
sowas hatten wir vor gefühlten 100 Jahren auch mal, ich kann mich dunkel daran erinnern, dass damals entweder eine der HDD defekt war oder was am "Netzwerk" war. Ich würde mal an den HDDs ansetzen und mich zu Netzwerk durchhangeln, sprich im SQL Konfigurationsmanager die Netzwerkprotokolle und -ports prüfen, ggfs. unbenötigte Protokolle abschalten usw.
Und das ggfs. auch beim ESXi, wobei auch ein Switch hier diesen Ärger machen könnte.
Reagiert der Server beim Fehler auf ein Ping, kannst Du das prüfen?
Kannst Du den Fehler reproduzieren oder auch einzelne Clients eingrenzen?
Gruss
beim ESXi, wobei auch ein Switch hier diesen Ärger machen könnte.
Hier läuft sowieso ein uralter Netzwerktreiber E1000, das stell ich dann im Zuge von EtherChannel auf VMXNET3 um...
Reagiert der Server beim Fehler auf ein Ping, kannst Du das prüfen?
Ping hab ich schon getestet - der Server ist immer erreichbar, auch Dateitransfer zu unterschiedlichen Uhrzeiten funktioniert ohne Probleme. Der DC ist auch dort virtualisiert, hier kommt es auch zu keinen Abbrüchen.
Kannst Du den Fehler reproduzieren oder auch einzelne Clients eingrenzen?
Das ganze tritt willkürlich in verschiedenen Abteilungen auf.
Hat hier noch jemand einen Tipp für mich? Der Adapter an den VMs steht nun auf VMXNET3, den vSwitch habe ich auf Lastausgleich "Anhand des IP Hashes routen", Failback ist deaktiviert. Trotzdem kommt es auf den SQL Servern teilweise in Software zu timeouts. Die zeitkritischen RTP Pakete gehen sowei fehlerfrei durchs Netz. In der Telefonie gibt es keine Abbrüche.
Moin,
Kannst du auf einer einem Referenz-Maschine einen (Win)MTR auf den SQL-Server starten? Es geht darum um evtl. Paketverluste zu erkennen.
Im Ereignisprotokoll des Clients bzw. im Protkoll des SQL-Servers wird nichts aufälliges protokolliert?!
Sind Server und Clients in selben Netzwerk IP-Adressbereich (z.B. 192.168.0.x/24) oder gibt es dazwischen noch ein Gateway/Firewall?
Gruß
Dani
Das ganze tritt willkürlich in verschiedenen Abteilungen auf.
Okay, aber in welchen Zeitabständen? Einmal an Tag oder täglich 3-4 Mal?Der Adapter an den VMs steht nun auf VMXNET3
Sehr gut.Grundsätzlich sind die Server mit VMWare virtualisiert
Welche ESXi Version setzt du ein und sind alle Patches installiert bzw. welchen Build nutzt du aktuell?SQL Server 2008 R2
Welche Edition und auch hier alle Service Packs installiert?Auf dem ESX Host laufen 4 VMs, diese teilen sich dann nur die beiden NICs.
Wenn es von der Auslastung her geht, würde ich temporär nur eine Netzwerkkarte mit dem Switch verbinden und bei allen anderen das Netzwerkkabel abziehen.Kannst du auf einer einem Referenz-Maschine einen (Win)MTR auf den SQL-Server starten? Es geht darum um evtl. Paketverluste zu erkennen.
Im Ereignisprotokoll des Clients bzw. im Protkoll des SQL-Servers wird nichts aufälliges protokolliert?!
Sind Server und Clients in selben Netzwerk IP-Adressbereich (z.B. 192.168.0.x/24) oder gibt es dazwischen noch ein Gateway/Firewall?
Gruß
Dani
Moin.
Das Phänomen hatten wir auch mal - prüf' mal deine Namensauflösung im Netz, also NetBIOS und DNS, passt da alles?
Welchen AV setzt ihr ein? Kannst du sicherstellen, dass der nicht "versehentlich" zuschlägt?
Cheers,
jsysde
Das Phänomen hatten wir auch mal - prüf' mal deine Namensauflösung im Netz, also NetBIOS und DNS, passt da alles?
Welchen AV setzt ihr ein? Kannst du sicherstellen, dass der nicht "versehentlich" zuschlägt?
Cheers,
jsysde
Moin,
Gruß,
Dani
Welchen AV setzt ihr ein? Kannst du sicherstellen, dass der nicht "versehentlich" zuschlägt?
gutes Stichwort... nicht vergessen die Außnahmen nach Microsoft Best Practice zu konfigurieren.Gruß,
Dani
Okay, aber in welchen Zeitabständen? Einmal an Tag oder täglich 3-4 Mal?
Unterschiedlich - manchmal einmal, manchmal mehrfach und auch an unterschiedlichen Rechnern...
Welche ESXi Version setzt du ein und sind alle Patches installiert bzw. welchen Build nutzt du aktuell?
Die ESXi Version ist 6.5, aber nicht der aktuellste Patchstand, den müsste ich noch nachziehen. Das Problem besteht aber schon seit 6.X
Welche Edition und auch hier alle Service Packs installiert?
Ja, soweit alles auf dem aktuellsten Stand.
Kannst du auf einer einem Referenz-Maschine einen (Win)MTR auf den SQL-Server starten? Es geht darum um evtl. Paketverluste zu erkennen.
Im Ereignisprotokoll des Clients bzw. im Protkoll des SQL-Servers wird nichts aufälliges protokolliert?!
Im Ereignisprotokoll des Clients bzw. im Protkoll des SQL-Servers wird nichts aufälliges protokolliert?!
Kann ich hier mit Wireshark und einem MirrorPort am Switch messen? Sehe ich da Paketverluste?
Sind Server und Clients in selben Netzwerk IP-Adressbereich (z.B. 192.168.0.x/24) oder gibt es dazwischen noch ein Gateway/Firewall?
Die Clients sind in unterschiedlichen VLANs, Routing übernimmt der gestackte Core-Switch. Bei VoIP (RTP) Paketen kommt es zu keinen Aussetzern - die Pakete sind ja auch eher zeitkritisch. Das Netz an sich läuft auch flüssig, die Auswertung der Switche war OK, Messungen im Netz waren auch OK. Es sind wirklich nur die SQL Aussetzer....
Ich weiß nicht wie sensibel der SQL ist, sprich wie viele Paketverluste z. B. der verkraftet. Der Mitarbeiter bekommt es immer dann mit, wenn die Software mit der o.g. Meldung crasht...
Moin,
Gruß,
Dani
Unterschiedlich - manchmal einmal, manchmal mehrfach und auch an unterschiedlichen Rechnern...
hast du die Möglichkeit temporär einen Rechner in das selbe Subnetz in dem der Microsoft SQL-Server steht, zu hängen? Nur um Routing und evtl. Firewalls auszuschließen. Die ESXi Version ist 6.5, aber nicht der aktuellste Patchstand, den müsste ich noch nachziehen. Das Problem besteht aber schon seit 6.X
Wie ist der ESXi-Server mit dem jeweiligen Switch verbunden? Wie sind die Netzwerkkarten in VMWare bezüglich NIC-Gruppierung konfiguriert? Wie sind die Ports auf dem Switch konfiguriert?Kann ich hier mit Wireshark und einem MirrorPort am Switch messen? Sehe ich da Paketverluste?
Gute Frage, so tief bin ich nicht drin. WinMTR wäre schnell und einfache Möglichkeit Paketverluste aufzudecken.Gruß,
Dani
