:strip_icc():strip_exif()/u/64489/hoogtevorst.jpg?f=community)
Op het werk hier zit ik met een probleem waar ik zo langzamerhand een beetje moedeloos van aan het worden ben.
Wij hebben ongeveer een computer of 50. Grofweg de helft van deze computers hebben een redirected Desktop, Mijn documenten map en Roaming AppData. Er wordt hier nooit van werkplek gewisseld dus een volledig roaming profile is niet nodig. Het enige wat belangrijk is, is dat belangrijke data van de werkstations gebackupped wordt en met deze opstelling gaat dat prima
Het probleem waar ik mee zit is dat sommige werkstations geregeld in de offline modus springen. Niet in de slow-link, maar echt in de offline modus. In het logboek is dan event 9 te zien van Offline files. Dat ziet er ongeveer zo uit:
Om na een minuutje weer up te komen. Meldingen van gebruikers komen nooit op dezelfde tijden. Het is altijd één user die op dat specifieke moment weer dit probleem heeft. Niet specifiek één persoon, maar na een paar uur is het weer iemand anders, maar het is er altijd één Op de switches zijn op dat moment geen errors te zien. Geen link die verbroken is, geen errors op de lijnen, niets..
Een oplossing leek even in zocht toen ik bij een aantal gebruikers verbinding liet maken met de FQDN van de server in plaats van de NetBIOS naam. Helaas ging het vandaag toch weer fout. Weer eenzelfde melding in het logboek en een vastlopende Word. De betreffende PC is een HP Pro 3500 MT. Deze is verbonden met een D-Link DGS-1210-24. Hiervoor hing er een switch van Allied Telesys en die gaf hetzelfde probleem, daar ligt het dus niet aan.
Deze DGS-1210-24 is verbonden met een HP ProCurve 1810-48G. Deze heeft weer een 4 poorts trunk met een HP 1910-48G (LACP). Op deze switch zitten onze vSphere hosts aangesloten.
De hosts zijn een tweetal HP DL380 G6 met beiden een Xeon E5640 met beiden 64GB RAM. Op deze hosts draait vSphere 5.5 in een HA cluster. Shared Storage wordt geleverd door een HP P2000 G3 iSCSI. Deze is gevuld met 24 schijven van elk 500 GB groot (6G 7.2K SAS MHL). Dit SAN is weer verdeeld in twee RAID arrays (beiden RAID 50). Disk 1 beslaat 12 schijven, disk 2 10 schijven. De resterende 2 schijven zijn Global Hot Spares Tussen beide vSphere hosts en het SAN liggen vier UTP kabels verdeeld over twee onboard netwerk adapters en een PCIe adapter (chips zijn van Broadcom en worden ondersteund door VMware). Via Round Robin wordt de load over deze links verdeeld.
Tussen de hosts en de switch is static link aggregation geconfigureerd. Dit is niet ideaal maar met onze Essentials Plus licentie wordt het helaas niet beter
Probleem
Dat Windows 7 clients zo nu en dan aangeven dat de verbinding met sommige paden (shares) is verbroken. Om het nog iets complexer te maken: users hebben de beschikking over 4 netwerkschijven en 3 redirected folders. Als er een disconnect plaats vind dan gaat het meestal niet over al deze paden. Dan liggen er twee of drie uit.
Troubleshooting
- Schijven en mappen geredirect met behulp van de FQDN naam i.p.v. NETBIOS. Dit lijkt te helpen maar nog steeds treden er zo nu en dan disconnects op.
- Packet Loss. PingPlotter geeft na een periode van een paar dagen aan dat er geen enkel pakketje verloren is geraakt of zelfs maar vertraagd is. De hoogste gemeten tijd bedroeg zo'n 3ms. Dat is natuurlijk niks..
- Drukte op de server. De Disk Queue van zowel read/write komt (overdag) zelden boven de 1 uit. Ik meet dit met behulp van Zabbix en die meet - toegegeven - niet real-time. Toch lijkt het mij hoogst onwaarschijnlijk dat er geen enkele piek gemeten zou worden in een periode van enkele weken als hier het probleem zou liggen (tijdens kantooruren).. 's Nachts liggen deze waarden wel een stuk hoger door back-ups, maar dat is niet zo gek.
- In de logbestanden van VMware is weinig bijzonders te vinden. 's Nachts zie ik wel eens een melding voorbij komen dat de performance van het SAN 'drastisch is afgenomen', maar dat komt omdat er nogal wat data wordt gebackupped.
- Slechte bekabeling? Dit moet ik nog volledig uitsluiten door extra tests, maar het lijkt me sterk omdat het probleem zo extreem weinig voorkomt (relatief gezien). Bij slechte bekabeling zou ik veel meer problemen verwachten, en belangrijker, errors in de logs van de switches.
- Fouten in het SAN? Hier is niets van te vinden in de management interface.
- Analatic en debug log van Offline Files bekeken maar dit log produceert geen nuttige informatie.
Wij maken ook gebruik van een ERP pakket van een niet nader te noemen leverancier. Bij sommige users wil dit pakket nog wel eens spontaan vastlopen. Volgens de leverancier komt dit omdat een request naar de server soms 'niet beantwoord' wordt. Dan ga ik aan packet loss denken? Toch kan ik dit op geen enkele manier reproduceren.
De fileserver draait overigens op Server 2008 (x86). Deze heeft twee virtuele schijven; een op array 1 en de ander op array 2. Het lijkt niet zo te zijn dat shares op een van beide array's vaker wegvallen dan de op de andere.
Iemand enig idee wat een eventuele vervolgstap zou kunnen zijn?
Toevoeging:
Ik zie dat ik dit niet in de OP had gezet, waarvoor mijn excuses.
Wij hebben ongeveer een computer of 50. Grofweg de helft van deze computers hebben een redirected Desktop, Mijn documenten map en Roaming AppData. Er wordt hier nooit van werkplek gewisseld dus een volledig roaming profile is niet nodig. Het enige wat belangrijk is, is dat belangrijke data van de werkstations gebackupped wordt en met deze opstelling gaat dat prima
Het probleem waar ik mee zit is dat sommige werkstations geregeld in de offline modus springen. Niet in de slow-link, maar echt in de offline modus. In het logboek is dan event 9 te zien van Offline files. Dat ziet er ongeveer zo uit:
code:
1
2
| Path disconnected. \\server\map |
Om na een minuutje weer up te komen. Meldingen van gebruikers komen nooit op dezelfde tijden. Het is altijd één user die op dat specifieke moment weer dit probleem heeft. Niet specifiek één persoon, maar na een paar uur is het weer iemand anders, maar het is er altijd één
Op de switches zijn op dat moment geen errors te zien. Geen link die verbroken is, geen errors op de lijnen, niets..Een oplossing leek even in zocht toen ik bij een aantal gebruikers verbinding liet maken met de FQDN van de server in plaats van de NetBIOS naam. Helaas ging het vandaag toch weer fout. Weer eenzelfde melding in het logboek en een vastlopende Word. De betreffende PC is een HP Pro 3500 MT. Deze is verbonden met een D-Link DGS-1210-24. Hiervoor hing er een switch van Allied Telesys en die gaf hetzelfde probleem, daar ligt het dus niet aan.
Deze DGS-1210-24 is verbonden met een HP ProCurve 1810-48G. Deze heeft weer een 4 poorts trunk met een HP 1910-48G (LACP). Op deze switch zitten onze vSphere hosts aangesloten.
De hosts zijn een tweetal HP DL380 G6 met beiden een Xeon E5640 met beiden 64GB RAM. Op deze hosts draait vSphere 5.5 in een HA cluster. Shared Storage wordt geleverd door een HP P2000 G3 iSCSI. Deze is gevuld met 24 schijven van elk 500 GB groot (6G 7.2K SAS MHL). Dit SAN is weer verdeeld in twee RAID arrays (beiden RAID 50). Disk 1 beslaat 12 schijven, disk 2 10 schijven. De resterende 2 schijven zijn Global Hot Spares
Tussen beide vSphere hosts en het SAN liggen vier UTP kabels verdeeld over twee onboard netwerk adapters en een PCIe adapter (chips zijn van Broadcom en worden ondersteund door VMware). Via Round Robin wordt de load over deze links verdeeld.Tussen de hosts en de switch is static link aggregation geconfigureerd. Dit is niet ideaal maar met onze Essentials Plus licentie wordt het helaas niet beter
Probleem
Dat Windows 7 clients zo nu en dan aangeven dat de verbinding met sommige paden (shares) is verbroken. Om het nog iets complexer te maken: users hebben de beschikking over 4 netwerkschijven en 3 redirected folders. Als er een disconnect plaats vind dan gaat het meestal niet over al deze paden. Dan liggen er twee of drie uit.
Troubleshooting
- Schijven en mappen geredirect met behulp van de FQDN naam i.p.v. NETBIOS. Dit lijkt te helpen maar nog steeds treden er zo nu en dan disconnects op.
- Packet Loss. PingPlotter geeft na een periode van een paar dagen aan dat er geen enkel pakketje verloren is geraakt of zelfs maar vertraagd is. De hoogste gemeten tijd bedroeg zo'n 3ms. Dat is natuurlijk niks..
- Drukte op de server. De Disk Queue van zowel read/write komt (overdag) zelden boven de 1 uit. Ik meet dit met behulp van Zabbix en die meet - toegegeven - niet real-time. Toch lijkt het mij hoogst onwaarschijnlijk dat er geen enkele piek gemeten zou worden in een periode van enkele weken als hier het probleem zou liggen (tijdens kantooruren).. 's Nachts liggen deze waarden wel een stuk hoger door back-ups, maar dat is niet zo gek.
- In de logbestanden van VMware is weinig bijzonders te vinden. 's Nachts zie ik wel eens een melding voorbij komen dat de performance van het SAN 'drastisch is afgenomen', maar dat komt omdat er nogal wat data wordt gebackupped.
- Slechte bekabeling? Dit moet ik nog volledig uitsluiten door extra tests, maar het lijkt me sterk omdat het probleem zo extreem weinig voorkomt (relatief gezien). Bij slechte bekabeling zou ik veel meer problemen verwachten, en belangrijker, errors in de logs van de switches.
- Fouten in het SAN? Hier is niets van te vinden in de management interface.
- Analatic en debug log van Offline Files bekeken maar dit log produceert geen nuttige informatie.
Wij maken ook gebruik van een ERP pakket van een niet nader te noemen leverancier. Bij sommige users wil dit pakket nog wel eens spontaan vastlopen. Volgens de leverancier komt dit omdat een request naar de server soms 'niet beantwoord' wordt. Dan ga ik aan packet loss denken? Toch kan ik dit op geen enkele manier reproduceren.
De fileserver draait overigens op Server 2008 (x86). Deze heeft twee virtuele schijven; een op array 1 en de ander op array 2. Het lijkt niet zo te zijn dat shares op een van beide array's vaker wegvallen dan de op de andere.
Iemand enig idee wat een eventuele vervolgstap zou kunnen zijn?
Toevoeging:
Omdat zonder Offline Files het hele bureaublad in een klap leeg is en ook niet meer terugkomt. Het probleem ligt dus waarschijnlijk niet aan Offline Files. Offline Files stelt ons alleen in staat om te 'recoveren' van deze error na enkele minuten. Een klassiek geval van symptoonbestrijding dus
Ik zie dat ik dit niet in de OP had gezet, waarvoor mijn excuses.
[ Voor 6% gewijzigd door Glashelder op 07-02-2014 10:01 ]
PV 4915wp op oost, 2680 wp op west, 1900 wp op zuid. pvoutput - AUX 8 kW bi bloc
:strip_icc():strip_exif()/u/4167/bacall8.jpg?f=community)
/u/113601/crop5e3f183d640f8_cropped.png?f=community)
Toevallig is dit de enige user in het hele pand die van begin tot eind met CAT6 is verbonden.