Oracle-sessie oor VPN verloor? Kyk na die keepalive-lae

Vyf-en-twintig minute se nuttige databasiswerk lewer byna geen uitset nie, en van elke toestel op die pad lyk daardie stroom onaktief. Onaktiewe toestand is presies wat opgeruim word. Die verslag daarna het altyd dieselfde vorm: die navraag het geloop, toe verdwyn die sessie, en die resultaat het nooit opgedaag nie.

Vier kontroles bepaal of ’n stil sessie oorleef, en hulle loop van die socket na buite. Doen hulle in volgorde, want elkeen aanvaar dat die vorige laag sy werk doen.

Watter stroom word stil

Die verbinding wat saak maak, is die een wat die databasisverkeer dra, geïdentifiseer deur sy eie adresse en poorte. Niks anders verfris dit nie. ’n Ping na ’n gateway, ’n tweede SQL-verbinding van dieselfde gasheer en die tonnel se eie hartklop is aparte strome met aparte toestand op elke toestel wat hulle volg.

ss -tio dst 10.60.4.20
sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes

Die socket-lys wys timers en tou-toestand vir die lewende verbinding, wat meer insig gee as ’n bereikbaarheidstoets. Die sysctl-waardes is die kernel-verstekke vir keepalive-gedrag, en die volgende afdeling verduidelik waarom hulle dalk nooit op jou sessie van toepassing is nie. ’n Verstek wat nooit afgaan nie, is nie te onderskei van glad geen verstek nie.

Skryf die adresse, die poorte en die koppelvlak neer wat die verbinding gebruik. Wanneer ’n sessie sterf, is dit daardie besonderhede wat jou toelaat om die regte toestel te vra wat hy gedoen het, eerder as om te vra of die netwerk op was.

Verloop die ledigheidbeleid of beperk dit

Twee beleide lewer dieselfde simptoom en verg teenoorgestelde reaksies. ’n Ledigheidstimeout verwyder toestand wat kwalifiserende verkeer kon verfris het, en ’n keepalive kan dit voorkom. ’n Absolute sessielimiet verwyder die stroom na ’n vaste duur ongeag aktiwiteit, en geen keepalive verander dit nie.

Vra die eienaar van elke tussenstandpunt watter een hy implementeer. ’n Firewall, ’n NAT-toestel, ’n load balancer en ’n wolk-gateway kan almal toestand hou, en hulle hoef nie saam te stem nie. Die nouste een stel die spertyd wat jy moet klop.

Daardie onderskeid sê ook vir jou wanneer om op te hou stel. As die beleid ’n absolute limiet is, is die regte oplossing ’n korter werkeenheid, ’n hervatbare taak of ’n goedgekeurde uitsondering, en die kontrole hieronder sal bloot bevestig dat keepalives geen verskil gemaak het nie.

Die socket-skakelaar agter die Linux-verstekke

Keepalive is per socket opsioneel. Die kernel-verstekke beskryf hoe sondes optree sodra ’n socket die meganisme geaktiveer het, en hulle aktiveer dit nie vir bestaande verbindings nie. ’n Toepassing wat nooit daarom vra nie, kry geen sondes nie, wat die sysctl-waardes ook al sê.

Daarom verander die blote verhoging van die getalle niks vir ’n databasis-kliënt nie. Die kliëntbiblioteek of die toepassing moet die meganisme aktiveer, en waar die stapel kontroles per verbinding bied, wen ’n beperkte instelling bo ’n verandering vir die hele gasheer wat onverwante dienste raak.

Die interval tot die eerste sondering is ook nie ’n navraag-timeout nie. ’n Gesonde verbinding bly stil tussen sondes, en ’n dooie portuur word volgens die sonderingsinterval en -telling herken. Om daardie drie waardes as een timeout te lees, is hoe mense by instellings uitkom wat ’n fout óf veel te laat óf veel te gretig opspoor. Hulle beheer opsporing, nie die toepassing se geduld nie.

EXPIRE_TIME is ’n databasis-instelling, nie ’n netwerk-regstelling nie

Oracle Net bied sy eie lewendigheidsmeganisme, opgestel in die effektiewe profiel vir die proses eerder as in ’n willekeurige lêer wat toevallig ’n soortgelyke naam het. Die waarde word in minute uitgedruk.

SQLNET.EXPIRE_TIME = 5

Die primêre doel daarvan is bediener-kantige opsporing van dooie verbindings, en op platforms wat die verbeterde model ondersteun, stel dit ook die TCP keepalive-gedrag vir daardie verbindings in. Dit is ’n nuttige eienskap: dit beteken die databasislaag kan vir sondes sorg sonder om die kliënttoepassing te vra om te verander.

Die voorbeeldwaarde hierbo is ’n gekoördineerde keuse teen ’n veronderstelde spertyd, nie ’n aanbeveling nie. Die gedokumenteerde algemene leiding is ’n langer interval, en die regte getal hang af van die geïnstalleerde implementering, die sondering-oorhoofse koste wat jy aanvaar en die werklike verfrisreëls op die pad. Sit die instelling in die profiel wat die betrokke proses lees, en bevestig dat die proses dit opgetel het. Oracle dokumenteer die profielliggings en die opsporingsgedrag in sy parameterverwysing.

Toets die stil interval en beplan dan herstel

Laat ’n nuwe toegelate verbinding deur ’n stil tydperk gaan wat langer is as die spertyd wat jy probeer klop, en hou die lewendigheidsverkeer en die toepassing se resultaat dop. Moenie vraginhoud vasvang wat jy nie nodig het nie; timers en verbindingstoestand beantwoord die vraag.

ss -tio dst 10.60.4.20
# after the quiet interval, same command
ls -l "$ORACLE_HOME/network/admin/sqlnet.ora"

As die sessie steeds verdwyn, behoort die spertyd aan ’n toestel wat jy nog nie gevra het nie, of is die beleid ’n absolute limiet. As dit oorleef, teken aan watter laag verander het, sodat die volgende stil bedryf nie die ondersoek herhaal nie.

Besluit laastens wat gebeur wanneer die verbinding wel val, want lewendigheidskontroles verminder die frekwensie en verwyder nooit die moontlikheid nie. Stel die databasisbewerking se aangetekende uitkoms vas voordat jy dit weer indien: die verlies van die antwoord bewys niks oor of die werk vasgelê is nie. Vir enigiets wat die toemaak van ’n skootrekenaar of ’n tonnel-herbegin moet oorleef, is ’n bediener-beheerde taak met ’n duursame resultaat die sterker ontwerp, en ’n keepalive is nie ’n skeduleerder nie.