A közelmúltban egy különös problémára sikerült megtalálni a megoldást. Az egyik telephelyünkön az ERP rendszer felhasználói egyik napról a másikra elkezdtek panaszkodni, hogy mindig kidobja őket a rendszer, és hogy naponta hússzor bejelentkezni nem vicces. Persze nem is hozzám került első körben a probléma, megjárta az ERP rendszerünkért felelős outsourcing partnert, és csak utána került a hálózatos csapathoz.
Annyit érdemes tudni az ERP-nkről, hogy egy özönvíz előtti, kb. tizenöt éves Baan verziót (IV) használunk. Az összes Baan szerverünk és adatbázisunk a Global Data Centerünkben van, a szóban forgó telephelyen pedig csak kliensek vannak, így minden ERP-vel kapcsolatos forgalom át kell, hogy menjen a belső WAN-unkon. Ezen kívül pedig volt még két másik tényező is: a kérdéses telephelyen a bérelt vonalat új szolgáltatóhoz vittük, illetve két héttel később belső tűzfal is került a csomagok útjába.
Mivel az adott telephelyen én felügyeltem a bérelt vonal migrációját illetve a tűzfal telepítést, megnyertem a Baan kliensek problémáját is. Az új szolgáltatót, mint problémaforrást viszonylag hamar ki lehetett zárni, hiszen az új vonal üzembe helyezése és a tűzfal telepítése közt eltelt két hétben a Baan kliensek hasítottak, bejelentkeztek reggel, kijelentkeztek délután, nem panaszkodott senki eldobált sessionökre.
Ideiglenes megoldásként a szerveres csapattal összefogva azt a megoldást javasoltuk első körben az adott telephely Baan usereinek, hogy akiket valóban zavar, hogy nem él egész nap a sessionjük, azok használják a Global Data Centerünkben frissen telepített Windows Server 2008 alapú új terminál szerver szolgáltatást, amin fent van a Baan kliens is, kiváló, gyors (LAN) kapcsolatuk lesz az adatbázissal, stb. Közben Baan forgalomra készíttettem az MPLS szolgáltatónkkal QoS-t, hátha... persze ehhez túl sok reményt nem fűztem, de mindenesetre egyértelműen monitorozhatóvá vált, hogy van-e gond az ERP-vel kapcsolatos adatforgalommal az MPLS-ünkben, hát nem volt.
Mondanom sem kell, minden egyéb forgalom tökéletesen rendben volt, nem volt gond a WAN-on keresztül az RDP sessionökkel, CIFS-sel, HTTP-vel, semmivel, csak a Baan4 gyengélkedett. Az adott telephely LAN-jában sem történtek változások, a fizikai réteggel kapcsolatos problémákat (laza patch kábel, vacak optikai kapcsolat LAN gerincen stb.) szintén gyorsan ki lehetett szórni, mint lehetséges problémaforrásokat. Maga a Baan IV kliens program sem egy bonyolult jószág, nincsenek speciális TCP beállításai, amelyek változása esetleg okozhatna hasonló jelenséget. Volt egy zsákutca még a kliensek védelmét ellátó Symantec SEP csomaggal, hátha ott valamilyen félresikerült policy kavar be... de nem, SEP nélkül is hullottak a sessionök, ha magukra hagyták őket a userek.
Időközben a belső tűzfalas projekt futott tovább, és hogy, hogy nem egy másik telephelyen is felmerült ugyanez a gond a Baan kliensekkel nem sokkal az ottani Fortigate tűzfal cluster telepítése után. Innen már viszonylag egyszerű volt a végkövetkeztetést levonni: a Fortigate-eken akadnak fenn a Baan sessionök. Valamiért a Baan IV TCP keepalive kezelése (ha van egyáltalán ilyesmije) nem kerek, és a Fortigate tűzfalak némi inaktivitás után egyszerűen eldobják a sessiont, szegény kliens meg csak áll, és nem érti, hogy ki vette el tőle az ő kis kapcsolatát a szerverhez.
De mit lehet ezzel kezdeni? Van ugyan a FortiOS-ben egy "system session-ttl" parancs, amivel minden (!) TCP és UDP sessionön meg lehet növelni a keepalive értéket, de ezzel ugye viszonylag hamar le lehet térdeltetni a tűzfalat, hiszen annak sem végtelenek az erőforrásai. Kiderült, hogy a FortiOS 4.0-ban viszont már nem csak system szinten, hanem firewall rule-onként lehet TTL-t állítani ("set session-ttl <másodperc>" az adott rule-on belül). Szóval a megoldás mindenhol az lett, hogy a Fortigate-eket frissíteni kell legalább 4.0-ra, majd egy külön rule készült a Baan forgalomra, amelyben a session-ttl értéket be kell lőni 28800-ra (8 óra). A tanulság? A tűzfal még akkor is tud nagy gondot okozni, ha egyébként tisztességgel átengedné a kérdéses forgalmat.
Nincsenek megjegyzések:
Megjegyzés küldése