RDP, Citrix, Hyper-V og problemer med programvare

[HDSoftware]

Folkens, vi har en kunde som kjører programmene våre hos en ASP som bruker Citrix (så vidt jeg vet). Innimellom, og ganske ofte får brukeren problemer med SQL connection og får feilmeldinger, bl.a. denne "Connection forcibly closed by remote host". Etter at denne meldingen kommer må programmene våre restartes for da er all komunikasjon med SQL serveren nede. Jeg har google litt og funnet masse rundt Chimney og slikt. Server parken er Windows Server 2008 og alt er virtualisert. Om SQL serveren og app serveren går på samme host vet jeg ikke noe om. Men det som er rart er at det kun er denne ASP leverandøren som opplever dette, det vil si, kundene vi har på denne ASP leverandøren. Vi har kontaktet de andre ASP leverandørene vi bruker og ingen andre rapporterer noe om dette. ASP leverandøren som opplever dette hevder ganske bombastisk at de ikke har problemer og vi blir således stillt i et dårlig lys ovenfor kunden vår.

 

Jeg trenger noe input her for å komme til bunns i saken. Kanskje greier vi å programmere oss rundt problemet hvis vi vet hva det er.

 

Alle tips er hjertelig velkomne...

[sogndal94]

Eg er ikkje så kjendt med Citrix, men i Hyper-v clusteret (SCVMM) vår måtte vi sette opp ei fast vMacadresse på eindel servertensestar. Kansje det er slik med citrix og.

[HDSoftware]

Eg er ikkje så kjendt med Citrix, men i Hyper-v clusteret (SCVMM) vår måtte vi sette opp ei fast vMacadresse på eindel servertensestar. Kansje det er slik med citrix og.

Takker for tipset. Notert og tas med i vurdering.

[xClaymanx]

Hadde tidligere problemer med SQL connection selv om jeg hadde opprettet regler for å slippe igjennom trafikk i brannmur. Endte til slutt opp med å slå av windows domene brannmur.

Har du din påslått/avslått?

[HDSoftware]

Det vet jeg ikke fordi dette er en ASP som vår kunde leier hos. Meg jeg tar det med i vurderingen. Takker for tipset. Hva slags problemer hadde du?

[xClaymanx]

De problemene jeg slet mest med var at jeg ikke fikk koble til korrekt database via sql management studio. Listen var kjempetreg. Deretter hadde jeg også problemer med at den nektet meg å finne databasen overhodet.

disablet til slutt brannmuren i frustrasjon, og da ordnet problemet seg for min del.

[HDSoftware]

De problemene jeg slet mest med var at jeg ikke fikk koble til korrekt database via sql management studio. Listen var kjempetreg. Deretter hadde jeg også problemer med at den nektet meg å finne databasen overhodet.

disablet til slutt brannmuren i frustrasjon, og da ordnet problemet seg for min del.

Ok. Takker for input.

[conundrum]

Folkens, vi har en kunde som kjører programmene våre hos en ASP som bruker Citrix (så vidt jeg vet). Innimellom, og ganske ofte får brukeren problemer med SQL connection og får feilmeldinger, bl.a. denne "Connection forcibly closed by remote host". Etter at denne meldingen kommer må programmene våre restartes for da er all komunikasjon med SQL serveren nede. Jeg har google litt og funnet masse rundt Chimney og slikt. Server parken er Windows Server 2008 og alt er virtualisert. Om SQL serveren og app serveren går på samme host vet jeg ikke noe om.

 

Feilmeldingen sier tydelig at problemet ligger mellom applikasjonen og den bakenforliggende SQL-serveren, og det ser veldig ut som et nettverksproblem. Kommunikasjonen blir brutt, og spørsmålet er hvorfor. TCP Reset (RST), timeout grunnet kommunikasjonssvikt, ressursmangel, bortsall av tjeneste på serversiden eller noe helt annet?

 

Siden dette tydeligvis er en 3-tier-applikasjon, bør du først og fremst finne ut hvorvidt databasen og applikasjonsserveren kjører på ulike (virtuelle) maskiner, noe jeg vil tippe at de gjør. FInn ut hvor dataene går for å komme fra den ene serveren til den andre, og vær spesielt obs. på routere, brannmurer eller IDS/IPS-programvare som ASP-leverandøren muligens kjører på serverne.

 

Hvis det er snakk om ressursmangel (tom for sockets) på applikasjonsserveren, bør du kunne se spor av dette i event-loggen (System). RST-pakker fra SQL-serveren bør du kunne filtrere med Wireshark eller Network Monitor; slike pakker skal man normalt ikke se overhodet.

 

En timeout grunnet en brannmur/router/noe annet bør du kunne fremprovosere ved å åpne et kommandovindu på app-serveren og starte en osql-sesjon mot den aktuelle instansen/databasen. I et ikke-NATet lokalnett bør ikke en slik sesjon få timeout selv etter 5-10 minutter.

 

At de bruker Citrix har nesten garantert ikke noe å si. Det er bare en veldig fancy mekanisme for å koble til en desktop og styre applikasjoner og skrivere; når man først er pålogget og applikasjonen starter, kunne man like gjerne vært koblet til med RDP eller for den saks skyld TeamViewer. Samme for Hyper-V; med unntak av spesialdriverne for paravirtualisert maskinvare ("falske" diskkontrollere, skjermkort og nettverkskort) er miljøet eksakt det samme. (OK, ett hederlig unntak: De virtuelle switchene kan forsåvidt gi problemer man ellers ikke ville hatt, noe jeg også har opplevd med nettopp Hyper-V.)

 

Du kan absolutt være inne på noe med TCP Chimney Offload (spesielt dersom applikasjonen det er snakk om, kanskje er Microsoft Dynamics?), men det er ikke noe ved denne offload-funksjonen som i seg selv burde forårsake problemer, bortsett fra dersom man også har et underliggende infrastrukturproblem som får forbindelser til å bli brutt eller gå i timeout.

 

Kanskje du kan prøve å få en driftsansvarlig hos ASP-leverandøren til å deaktivere TCP Chimney med netsh interface tcp set global chimney=disabled og eventuelt også deaktivere "SynAttackProtect" (som burde være overflødig i de fleste lukkede datasentre) ved å opprette en DWORD-verdi med dette navnet i registeret under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters, og gi den verdien "0". Sistnevnte vil tre i kraft etter en omstart. Hvis dette skulle vise seg å hjelpe, har de en feil i selve infrastrukturen som dektivering av disse funksjonene tjener til å maskere.

[HDSoftware]

 

Folkens, vi har en kunde som kjører programmene våre hos en ASP som bruker Citrix (så vidt jeg vet). Innimellom, og ganske ofte får brukeren problemer med SQL connection og får feilmeldinger, bl.a. denne "Connection forcibly closed by remote host". Etter at denne meldingen kommer må programmene våre restartes for da er all komunikasjon med SQL serveren nede. Jeg har google litt og funnet masse rundt Chimney og slikt. Server parken er Windows Server 2008 og alt er virtualisert. Om SQL serveren og app serveren går på samme host vet jeg ikke noe om.

 

Feilmeldingen sier tydelig at problemet ligger mellom applikasjonen og den bakenforliggende SQL-serveren, og det ser veldig ut som et nettverksproblem. Kommunikasjonen blir brutt, og spørsmålet er hvorfor. TCP Reset (RST), timeout grunnet kommunikasjonssvikt, ressursmangel, bortsall av tjeneste på serversiden eller noe helt annet?

 

Siden dette tydeligvis er en 3-tier-applikasjon, bør du først og fremst finne ut hvorvidt databasen og applikasjonsserveren kjører på ulike (virtuelle) maskiner, noe jeg vil tippe at de gjør. FInn ut hvor dataene går for å komme fra den ene serveren til den andre, og vær spesielt obs. på routere, brannmurer eller IDS/IPS-programvare som ASP-leverandøren muligens kjører på serverne.

 

Hvis det er snakk om ressursmangel (tom for sockets) på applikasjonsserveren, bør du kunne se spor av dette i event-loggen (System). RST-pakker fra SQL-serveren bør du kunne filtrere med Wireshark eller Network Monitor; slike pakker skal man normalt ikke se overhodet.

 

En timeout grunnet en brannmur/router/noe annet bør du kunne fremprovosere ved å åpne et kommandovindu på app-serveren og starte en osql-sesjon mot den aktuelle instansen/databasen. I et ikke-NATet lokalnett bør ikke en slik sesjon få timeout selv etter 5-10 minutter.

 

At de bruker Citrix har nesten garantert ikke noe å si. Det er bare en veldig fancy mekanisme for å koble til en desktop og styre applikasjoner og skrivere; når man først er pålogget og applikasjonen starter, kunne man like gjerne vært koblet til med RDP eller for den saks skyld TeamViewer. Samme for Hyper-V; med unntak av spesialdriverne for paravirtualisert maskinvare ("falske" diskkontrollere, skjermkort og nettverkskort) er miljøet eksakt det samme. (OK, ett hederlig unntak: De virtuelle switchene kan forsåvidt gi problemer man ellers ikke ville hatt, noe jeg også har opplevd med nettopp Hyper-V.)

 

Du kan absolutt være inne på noe med TCP Chimney Offload (spesielt dersom applikasjonen det er snakk om, kanskje er Microsoft Dynamics?), men det er ikke noe ved denne offload-funksjonen som i seg selv burde forårsake problemer, bortsett fra dersom man også har et underliggende infrastrukturproblem som får forbindelser til å bli brutt eller gå i timeout.

 

Kanskje du kan prøve å få en driftsansvarlig hos ASP-leverandøren til å deaktivere TCP Chimney med netsh interface tcp set global chimney=disabled og eventuelt også deaktivere "SynAttackProtect" (som burde være overflødig i de fleste lukkede datasentre) ved å opprette en DWORD-verdi med dette navnet i registeret under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters, og gi den verdien "0". Sistnevnte vil tre i kraft etter en omstart. Hvis dette skulle vise seg å hjelpe, har de en feil i selve infrastrukturen som dektivering av disse funksjonene tjener til å maskere.

 

Hjertelig takk for godt svar. Dette var av høy interesse og dette skal vi undersøke nærmere.